Amanda-Users

Re: 2.4.2p2 client, 2.4.4p3 server: timeout from amandad...

2006-05-03 10:43:29
Subject: Re: 2.4.2p2 client, 2.4.4p3 server: timeout from amandad...
From: Paul Bijnens <paul.bijnens AT xplanation DOT com>
To: Francis Galiegue <fg AT one2team DOT com>
Date: Wed, 03 May 2006 16:39:33 +0200
On 2006-05-03 15:53, Francis Galiegue wrote:
Le Mercredi 03 Mai 2006 14:48, vous avez écrit :
On 2006-05-03 13:26, Francis Galiegue wrote:

You could run tcpdump or ethereal on the server and client and verify
if indeed the packet is arriving there and with the correct IP-number
(considering the aliases for eth0 can have messed that up).


Well, if it did, I wouldn't have been able to do "small" backups either, would I?

Is there a firewall inbetween, or on one/both of the servers?
You may need to increase the UDP-reply timeout on the firewall (or
disable the firewall).  I believe many firewalls timeout UDP packets
after 180 seconds.


There's a firewall on both. On the client machine, UDP/10080 is let in from the server machine only. On the server machine, UDP/10082 and 10083 are let in from the client only. As to the timeout, I don't see this as a problem since I have an iptables rules that catches "INVALID" packets (as per conntrack definition) and it captures nothing at all...

You're missing the UDP/10080 from client to server...  (after timeout
it is not related or tracked with conntrack).

Actually iptables is one that times out UDP packets after 180 seconds.
That why the ip_conntrack_amanda kernel module has the option to set
that larger with the master_timeout parameter.

Did you try this simple manual test:

Start on the Amanda client:

 $ nc -vv -u -l -p 10080

Next on the Amanda server:

 $ nc -vv -u theclient.example.com 10080

Type something on the server (you should see that text appear on the
client).  Type something on the client (we simulate the ACK that the
clients sends for the firewall).
Now wait 5 minutes and type something on the client again (the final
results packet).  Is it received on the server?  If not, do you notice
a log entry for an INVALID packet ?

(Because port 10080 is probably already in use by (x)inetd, you probably
have to disable amanda udp/10080 on the client temporarily.)



There are other possibilities, solutions. See:

http://wiki.zmanda.com/index.php/Amdump:_results_missing

in amanda 2.4.2p2 the "calcsize" was not yet implemented (it did
exist, but was experimental, I believe).
if the server is 2.4.4xx then you can use "estimate server", even
if the client is old.


From what I've read on the zmanda wiki, estimate server uses data from the
previous runs. But there's no previous run...

BTW I've tried the nc stuff on the wiki page as well: it's definitely not a firewall problem.

"... definitely not..." resembles to some famous last words...
But I could be wrong of course.   The test above will prove that.


--
Paul Bijnens, xplanation Technology Services        Tel  +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM    Fax  +32 16 397.512
http://www.xplanation.com/          email:  Paul.Bijnens AT xplanation DOT com
***********************************************************************
* I think I've got the hang of it now:  exit, ^D, ^C, ^\, ^Z, ^Q, ^^, *
* F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt,  abort,  hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e,  kill -1 $$,  shutdown, *
* init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ...  "Are you sure?"  ...   YES   ...   Phew ...   I'm out          *
***********************************************************************