On Sun, 29 Apr 2007, Jean-Louis Martineau wrote:

The dumper must be installed suid root.

What's in the dumper.<timestamps>.debug file?

-searches through all services in /etc/services, decides most are already
 assigned to another service -

 dumper: connect_port: Skip port 597: Owned by ptcnameservice.
 dumper: connect_port: Skip port 598: Owned by sco-websrvrmg3.
 dumper: connect_port: Skip port 599: Owned by acp.
 dumper: connect_port: Skip port 600: Owned by ipcserver.
 dumper: connect_port: Try  port 601: Available

 note that these aren't actually in use, just defined in /etc/services

-it seems to do this on each connect and quite often will try a port that
 it's already using on another dump job -

 dumper: connect_portrange: connect from 0.0.0.0.601 failed: Address
 already in use
 dumper: connect_portrange: connect to 209.123.46.102.10080 failed:
 Address already in use

-this goes on and on, with the port number increasing until it reaches
 something outside the privileged port range -

 security_stream_seterr(0x8086000, EOF)
 security_stream_close(0x8086000)
 security_stream_seterr(0x806d000, EOF)
 security_stream_close(0x806d000)
 security_stream_seterr(0x807d000, EOF)
 security_stream_close(0x807d000)
 dumper: connect_port: Try  port 1026: Available   -
 dumper: connected to 127.0.0.1.4133
 dumper: our side is 0.0.0.0.1026
 dumper: try_socksize: send buffer size is zu
 security_getdriver(name=bsdtcp) returns 0x480c1380
 security_handleinit(handle=0x805d100, driver=0x480c1380 (BSDTCP))
 security_streaminit(stream=0x8064000, driver=0x480c1380 (BSDTCP))
 dumper: connect_port: Try  port 585: Available   -
 dumper: connect_portrange: connect from 0.0.0.0.585 failed: Address
 already in use
 dumper: connect_portrange: connect to 209.123.46.110.10080 failed:
 Address already in use
 dumper: connect_port: Skip port 512: Owned by exec.
 (repeat - eventually it finds a low port that works)

What do you folks think?

Thanks,

Charles

Jean-Louis

Charles Sprickman wrote:

Any ideas on this one?  Should I just consider it a bug?

I'm not clear at all on why the server is picking a port over 1024, but that does seem to be clearly happening, and then the client is rejecting it (which does seem to be by design). FWIW, I *cannot* reproduce it when firing off one host at a time - only during an actual full run where all hosts are backed up. Perhaps it's trying to do too much in parallel? The server box is not doing anything odd that would eat up priv ports. Additionally the problem did not exist in the old version of amanda we used.

Thanks,

Charles

On Wed, 25 Apr 2007, Charles Sprickman wrote:

Hi all,

This is my last problem for the time being...

Server side reports this (amdump.1):

driver: result time 2126.498 from dumper2: TRY-AGAIN 02-00009 "NAK: host h-74-0-x-28.phlapafg.covad.net: port 1026 not secure"

The IP address there is the amanda server.

Client side reports this (amandad.debug):

security_handleinit(handle=0x8052000, driver=0x28094900 (BSDTCP))
security_streaminit(stream=0x8058000, driver=0x28094900 (BSDTCP))

security_seterror(handle=0x8052000, driver=0x28094900 (BSDTCP) error=host h-74-0-x-28.phlapafg.covad.net: port 1026 not secure) amandad: time 0.002: accept error: host h-74-0-x-28.phlapafg.covad.net: port 1026 not secure

amandad: time 0.002: sending NAK pkt:
<<<<<
ERROR host h-74-0-x-28.phlapafg.covad.net: port 1026 not secure

If I'm reading this right, the client is listening via inetd, it accepts a connection FROM the server, but it does not like that the server is connecting to it from a port above 1024.

The check appears to be in common-src/security-util.c:

       /*
        * Request packets must come from a reserved port
        */
       if (ntohs(rh->peer.sin_port) >= IPPORT_RESERVED) {
           security_seterror(&rh->sech,
               "host %s: port %d not secure", rh->hostname,
               ntohs(rh->peer.sin_port));
           amfree(service);
           amfree(security_line);
           return (-1);
       }

But that doesn't tell me much about what controls what port the server decides to bind to when contacting the client.

I saw a FAQ entry about this error when running amcheck without the suid root bit, but this happens during amdump and amcheck. It seems fairly random.

Any ideas?

Thanks,

Charles