Quoting Paul Bijnens <paul.bijnens AT xplanation DOT com>:

> Andreas Sundstrom wrote:
> 
> > All went well and the backup finished successful. Then I switched to my
> > identically compiled 2.6.6-rc2 kernel and it fails with the same error as
> earlier:
> > These dumps were to tape dflt10.
> > The next tape Amanda expects to use is: dflt11.
> > The next new tape already labelled is: dflt12.
> > 
> > FAILURE AND STRANGE DUMP SUMMARY:
> >   zappa.zapp /imagelib lev 1 FAILED [bad CONNECT response]
> >   zappa.zapp /boot lev 0 FAILED 20040615[could not connect to
> zappa.zappa.cx]
> >   zappa.zapp /home/sunkan lev 1 FAILED 20040615[could not connect to
> zappa.zappa.cx]
> >   zappa.zapp /var lev 1 FAILED 20040615[could not connect to
> zappa.zappa.cx]
> >   zappa.zapp / lev 0 FAILED 20040615[could not connect to zappa.zappa.cx]
> >   zappa.zapp /home/emelie lev 0 FAILED 20040615[could not connect to
> zappa.zappa.cx]
> >   zappa.zapp /apps lev 0 FAILED [bad CONNECT response]
> > 
> > So I tarred up the /tmp/amanda dir and put it at
> > ftp://zappa.cx/pub/amanda-zappa.cx.tar.gz if anyone wants to take a look at
> it.
> > This is the complete failed session and nothing else.
> 
> In /tmp/amanda are mostly client files.  The debug files are all, as
> far as I can see, from the succeeded session.  When failing, the
> client does not even get started somehow, or did I miss that file?
> 
> I miss the amdump.1 and log.2004xxxx file, which are the server side 
> logs (in ~amanda/dflt ).
> 
> But I don't expect something shocking in those files anyway.
> As it seems to be network related, I'm still more interested to know
> if the client had trouble sending the packets, or the server had trouble
> receiving it.  A tcpdump trace of the failing session would be really
> helpful.

I have tarred them up to the file: ftp://zappa.cx/pub/amdump-zappa.cx.tar.gz
have a look if you have time for it.

Also what do you recommend as parameters to tcpdump, it's all running on the
same host does that mean I can sniff on "lo"?

/Andreas