I can't believe that there is some firewall in the way, so I ran ethereal on both ends and came up
with the same set of packets. I have the data part of those packets below. Notice how the last three
pairs of packets are exactly the same. I also noted that the first six packets happened within two
seconds of each other, the next two five minutes later, and the final two packets five minutes after
that.
This leads me to believe that there is no networking problem, but instead the client should be doing
something and getting back to the server within five minutes with (I can only imagine) at least some
acknowledgment that it is working on something on behalf of the server. This doesn't happen, and the
server assumes (rightfully so, since UDP does not guarantee delivery) that the client didn't get the
request, so tries again. After the third attempt the server gives up and emails me the report.
Can someone show me what a "good" set of communication packets looks like? Maybe that will help me
see who's supposed to be doing what next. I have only gotten Amanda working with Windows boxes, so I
have no good working backup system between two Unix boxes to compare this to.
All packets use port 669 on the server and 10080 on the client.
server->client:
Amanda 2.4 REQ HANDLE 000-0003AAF0 SEQ 1085142942.SECURITY USER amanda.SERVICE noop.OPTIONS
features=fffffeff9ffe0f;.
client->server:
Amanda 2.4 ACK HANDLE 000-0003AAF0 SEQ 1085142942.
client->server:
Amanda 2.4 REP HANDLE 000-0003AAF0 SEQ 1085142942.OPTIONS
features=fffffeff9ffe0f;.
server->client:
Amanda 2.4 ACK HANDLE 000-0003AAF0 SEQ 1085142942.
server->client:
Amanda 2.4 REQ HANDLE 000-0003D170 SEQ 1085142943.SECURITY USER amanda.SERVICE sendsize.OPTIONS
features=fffffeff9ffe0f;maxdumps=1;hostname=cc501;.GNUTAR /export/h4 01970:1:1:0:0:0 -1 OPTIONS
|;auth=bsd;compress-best;no-record;.
client->server:
Amanda 2.4 ACK HANDLE 000-0003D170 SEQ 1085142943.
server->client:
Amanda 2.4 REQ HANDLE 000-0003D170 SEQ 1085142943.SECURITY USER amanda.SERVICE sendsize.OPTIONS
features=fffffeff9ffe0f;maxdumps=1;hostname=cc501;.GNUTAR /export/h4 0 1970:1:1:0:0:0 -1 OPTIONS
|;auth=bsd;compress-best;no-record;.
client->server:
Amanda 2.4 ACK HANDLE 000-0003D170 SEQ 1085142943.
server->client:
Amanda 2.4 REQ HANDLE 000-0003D170 SEQ 1085142943.SECURITY USER amanda.SERVICE sendsize.OPTIONS
features=fffffeff9ffe0f;maxdumps=1;hostname=cc501;.GNUTAR /export/h4 0 1970:1:1:0:0:0 -1 OPTIONS
|;auth=bsd;compress-best;no-record;.
client->server:
Amanda 2.4 ACK HANDLE 000-0003D170 SEQ 1085142943.
Eric Siegerman wrote:
On Thu, May 13, 2004 at 11:39:09AM -0400, jlm17 wrote:
amandad: time 1020.909: dgram_recv: timeout after 10 seconds
amandad: time 1020.909: waiting for ack: timeout, retrying
Not sure, but this smells like a firewall getting in the way.
Possibly it's allowing packets from the Amanda server to the
client (else how did amandad get launched in the first place?),
but blocking them the other way. Since the server doesn't see
the client amandad's response, it doesn't ACK it; hence the
complaint from the client.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. erics AT telepres DOT com
| | /
It must be said that they would have sounded better if the singer
wouldn't throw his fellow band members to the ground and toss the
drum kit around during songs.
- Patrick Lenneau
|
