Backup Central

I'm sending this now to the amanda-users list, I originally sent it to the linux-kernel ml but the only person who have answered my
mail is Gene Heskett which also recommended me to try here.

I'm using amanda-2.4.4p2 but I have also tried 2.4.5b1-20040510 with the same results.

I have trouble upgrading from 2.6.5 to 2.6.6, I have narrowed it down by trying the different rc releases. Between 2.6.6-rc1 and
2.6.6-rc2 something happens that make my amanda backups fail with the error [bad CONNECT response].

If I do nothing else than boot to 2.6.6-rc1 from rc2 it works so it seems to be somthing with the kernel that is causing the
trouble, but I don't know how to investigate further.

This is the best debug info I've found so far.

Non-working:
root < at > zappa:/var/tmp/amanda# cat sendbackup.20040511223325.debug
sendbackup: debug 1 pid 2463 ruid 0 euid 0: start at Tue May 11 22:33:25 2004
/usr/lib/amanda/sendbackup: version 2.4.4p2
parsed request as: program `GNUTAR'
disk `/boot'
device `/boot'
level 1
since 2004:5:11:10:6:42
options `|;bsd-auth;index;exclude-list=.amanda.excludes;exclude-optional;'
sendbackup: try_socksize: send buffer size is 65536
sendbackup: time 0.003: stream_server: waiting for connection: 0.0.0.0.564
sendbackup: time 0.003: stream_server: waiting for connection: 0.0.0.0.565
sendbackup: time 0.003: stream_server: waiting for connection: 0.0.0.0.566
sendbackup: time 0.008: waiting for connect on 564, then 565, then 566
sendbackup: time 30.003: stream_accept: timeout after 30 seconds
sendbackup: time 30.003: timeout on data port 564
sendbackup: time 59.998: stream_accept: timeout after 30 seconds
sendbackup: time 59.998: timeout on mesg port 565
sendbackup: time 89.994: stream_accept: timeout after 30 seconds
sendbackup: time 89.994: timeout on index port 566
sendbackup: time 89.994: pid 2463 finish time Tue May 11 22:34:55 2004

Working:
root < at > zappa:/var/tmp/amanda# cat /tmp/amanda/sendbackup.20040611030533.debug
sendbackup: debug 1 pid 26091 ruid 0 euid 0: start at Fri Jun 11 03:05:33 2004
/usr/lib/amanda/sendbackup: version 2.4.4p2
parsed request as: program `GNUTAR'
disk `/boot'
device `/boot'
level 0
since 1970:1:1:0:0:0
options `|;bsd-auth;index;exclude-list=.amanda.excludes;exclude-optional;'
sendbackup: try_socksize: send buffer size is 65536
sendbackup: time 0.003: stream_server: waiting for connection: 0.0.0.0.840
sendbackup: time 0.003: stream_server: waiting for connection: 0.0.0.0.841
sendbackup: time 0.003: stream_server: waiting for connection: 0.0.0.0.842
sendbackup: time 0.020: waiting for connect on 840, then 841, then 842
sendbackup: time 0.020: stream_accept: connection from 192.168.20.100.36640
sendbackup: time 0.021: stream_accept: connection from 192.168.20.100.36641
sendbackup: time 0.021: stream_accept: connection from 192.168.20.100.36642
sendbackup: time 0.021: got all connections
sendbackup-gnutar: time 0.023: doing level 0 dump as listed-incremental to /var/lib/amanda/gnutar-lists/zappa.zappa.cx_boot_0.new
sendbackup-gnutar: time 1.495: doing level 0 dump from date: 1970-01-01 0:00:00 GMT
sendbackup: Can't open exclude file '/boot/.amanda.excludes': No such file or directory
sendbackup: time 1.568: spawning /usr/lib/amanda/runtar in pipeline
sendbackup: argument list: gtar --create --file - --directory /boot --one-file-system --listed-incremental
/var/lib/amanda/gnutar-lists/zappa.zappa.cx_boot_0.new --sparse --ignore-failed-read --totals --exclude-from
/tmp/amanda/sendbackup._boot.20040611030535.exclude .
sendbackup-gnutar: time 1.589: /usr/lib/amanda/runtar: pid 26361
sendbackup: time 1.589: started index creator: "/bin/tar -tf - 2>/dev/null | sed -e 's/^\.//'"
sendbackup: time 2.754: 53: size(|): Total bytes written: 10414080 (9.9MB, 8.5MB/s)
sendbackup: time 2.758: index created successfully
sendbackup: time 4.266: pid 26091 finish time Fri Jun 11 03:05:38 2004

Any ideas of how to investigate further? It seems that I'm the only one with this problem beacause I can't find any other posts
about this. Unfortunately I don't have any other computers with tapedrives on them to try and reproduce the problem (although it
seems to be about networking so a tapedrive might not be necessary to investigate further).

Thanks for any help.

Let me know if I need to post more info, don't want to write an unnecessary overly large e-mail.
/Andreas Sundstrom

Hi, Andreas,

on Sonntag, 13. Juni 2004 at 15:04 you wrote to amanda-users:

AS> I have trouble upgrading from 2.6.5 to 2.6.6, I have narrowed
AS> it down by trying the different rc releases. Between 2.6.6-rc1 and
AS> 2.6.6-rc2 something happens that make my amanda backups fail
AS> with the error [bad CONNECT response].

AS> If I do nothing else than boot to 2.6.6-rc1 from rc2 it works
AS> so it seems to be somthing with the kernel that is causing the
AS> trouble, but I don't know how to investigate further.

Why do you want to use 2.6.6-rc2? You want to use 2.6.6, don't you?

I have compiled every single kernel in the 2.6-tree for more than a
year now and tested amanda-2.4.4p2 on it. I have not experienced that
problem but would suggest comparing the kernel-configs.

Take the config of a kernel amanda works with and try to use this
config to compile a fresh 2.6.6 for start.

--

To me it seems that your non-working config just uses different ports
somehow which are blocked ...?

Did you compile amanda under the new kernel? Which options did you
configure it with?

--
best regards,
Stefan

Stefan G. Weichinger
mailto:monitor < at > oops.co.at

Andreas Sundstrom wrote:
I'm sending this now to the amanda-users list, I originally sent it to
the linux-kernel ml but the only person who have answered my mail is
Gene Heskett which also recommended me to try here.

I'm using amanda-2.4.4p2 but I have also tried 2.4.5b1-20040510 with the
same results.

I have trouble upgrading from 2.6.5 to 2.6.6, I have narrowed it down
by trying the different rc releases. Between 2.6.6-rc1 and 2.6.6-rc2
something happens that make my amanda backups fail with the error
[bad CONNECT response].

Is this on the server or on the client or both?



If I do nothing else than boot to 2.6.6-rc1 from rc2 it works so it
seems to be somthing with the kernel that is causing the
trouble, but I don't know how to investigate further.

This is the best debug info I've found so far.

You only send sendbackup. Does it mean that amcheck does not give
any errors?



Non-working:
root < at > zappa:/var/tmp/amanda# cat sendbackup.20040511223325.debug
sendbackup: debug 1 pid 2463 ruid 0 euid 0: start at Tue May 11 22:33:25
2004
/usr/lib/amanda/sendbackup: version 2.4.4p2
parsed request as: program `GNUTAR'
disk `/boot'
device `/boot'
level 1
since 2004:5:11:10:6:42
options
`|;bsd-auth;index;exclude-list=.amanda.excludes;exclude-optional;'
sendbackup: try_socksize: send buffer size is 65536
sendbackup: time 0.003: stream_server: waiting for connection: 0.0.0.0.564
sendbackup: time 0.003: stream_server: waiting for connection: 0.0.0.0.565
sendbackup: time 0.003: stream_server: waiting for connection: 0.0.0.0.566
sendbackup: time 0.008: waiting for connect on 564, then 565, then 566
sendbackup: time 30.003: stream_accept: timeout after 30 seconds
sendbackup: time 30.003: timeout on data port 564
sendbackup: time 59.998: stream_accept: timeout after 30 seconds
sendbackup: time 59.998: timeout on mesg port 565
sendbackup: time 89.994: stream_accept: timeout after 30 seconds
sendbackup: time 89.994: timeout on index port 566
sendbackup: time 89.994: pid 2463 finish time Tue May 11 22:34:55 2004

It seems that there is some networking issue.
Have you ruled out a misconfigured iptables?

Try with to see what happening on the wire with tcpdump.

...

Any ideas of how to investigate further? It seems that I'm the only
one with this problem beacause I can't find any other posts about
this. Unfortunately I don't have any other computers with tapedrives
on them to try and reproduce the problem (although it seems to be
about networking so a tapedrive might not be necessary to investigate
further).

You don't need a tapedrive at all. Read the FILE-HOWTO in the
docs directory to setup virtual tapes. Takes only 5-10 minutes.



Thanks for any help.

Let me know if I need to post more info, don't want to write an
unnecessary overly large e-mail.

You may always mail me personally the complete debugging info, or
packet trace if you like.


/Andreas Sundstrom



--
Paul Bijnens, Xplanation 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.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, :, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, *
* kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ... "Are you sure?" ... YES ... Phew ... I'm out *
***********************************************************************

Stefan G. Weichinger wrote:
Hi, Andreas,

on Sonntag, 13. Juni 2004 at 15:04 you wrote to amanda-users:

AS> I have trouble upgrading from 2.6.5 to 2.6.6, I have narrowed
AS> it down by trying the different rc releases. Between 2.6.6-rc1 and
AS> 2.6.6-rc2 something happens that make my amanda backups fail
AS> with the error [bad CONNECT response].

AS> If I do nothing else than boot to 2.6.6-rc1 from rc2 it works
AS> so it seems to be somthing with the kernel that is causing the
AS> trouble, but I don't know how to investigate further.

Why do you want to use 2.6.6-rc2? You want to use 2.6.6, don't you?
Sure I only tried to narrow down it as much as I could when I reported
it to the linux-kernel ml. I have the same results with 2.6.6 as with
2.6.6-rc2.


I have compiled every single kernel in the 2.6-tree for more than a
year now and tested amanda-2.4.4p2 on it. I have not experienced that
problem but would suggest comparing the kernel-configs.

Take the config of a kernel amanda works with and try to use this
config to compile a fresh 2.6.6 for start.
I have done this, I actually take the working config from 2.6.6-rc1 and
copy it to 2.6.6-rc2 do "make oldconfig" answer no to any questions
about new things (raw table support for iptables)


--

To me it seems that your non-working config just uses different ports
somehow which are blocked ...?
Yes, but I can't understand what goes wrong. I've even flushed my
iptables rules and set default policy to ACCEPT everywhere.


Did you compile amanda under the new kernel? Which options did you
configure it with?
Well, yes without any change in operation. Here is my configure statement:
./configure --prefix=/usr \
--sysconfdir=/etc \
--libexecdir=/usr/lib/amanda \
--localstatedir=/var/lib \
--disable-dependency-tracking \
--with-user=root \
--with-group=root

Thanks for taking your time and let me know if there's more things I can do.

/Andreas

Paul Bijnens wrote:
Andreas Sundstrom wrote:

I'm sending this now to the amanda-users list, I originally sent it to
the linux-kernel ml but the only person who have answered my mail is
Gene Heskett which also recommended me to try here.

I'm using amanda-2.4.4p2 but I have also tried 2.4.5b1-20040510 with
the same results.

I have trouble upgrading from 2.6.5 to 2.6.6, I have narrowed it down
by trying the different rc releases. Between 2.6.6-rc1 and 2.6.6-rc2
something happens that make my amanda backups fail with the error
[bad CONNECT response].


Is this on the server or on the client or both?
both (I mean this is all happening on a local computer with tapedrive
attached)




If I do nothing else than boot to 2.6.6-rc1 from rc2 it works so it
seems to be somthing with the kernel that is causing the
trouble, but I don't know how to investigate further.

This is the best debug info I've found so far.


You only send sendbackup. Does it mean that amcheck does not give
any errors?
Yes, amcheck says that everything is ok.




Non-working:
root < at > zappa:/var/tmp/amanda# cat sendbackup.20040511223325.debug
sendbackup: debug 1 pid 2463 ruid 0 euid 0: start at Tue May 11
22:33:25 2004
/usr/lib/amanda/sendbackup: version 2.4.4p2
parsed request as: program `GNUTAR'
disk `/boot'
device `/boot'
level 1
since 2004:5:11:10:6:42
options
`|;bsd-auth;index;exclude-list=.amanda.excludes;exclude-optional;'
sendbackup: try_socksize: send buffer size is 65536
sendbackup: time 0.003: stream_server: waiting for connection:
0.0.0.0.564
sendbackup: time 0.003: stream_server: waiting for connection:
0.0.0.0.565
sendbackup: time 0.003: stream_server: waiting for connection:
0.0.0.0.566
sendbackup: time 0.008: waiting for connect on 564, then 565, then 566
sendbackup: time 30.003: stream_accept: timeout after 30 seconds
sendbackup: time 30.003: timeout on data port 564
sendbackup: time 59.998: stream_accept: timeout after 30 seconds
sendbackup: time 59.998: timeout on mesg port 565
sendbackup: time 89.994: stream_accept: timeout after 30 seconds
sendbackup: time 89.994: timeout on index port 566
sendbackup: time 89.994: pid 2463 finish time Tue May 11 22:34:55 2004


It seems that there is some networking issue.
Have you ruled out a misconfigured iptables?
Yes, I have flushed the rules and set default policy to ACCEPT everywhere.


Try with to see what happening on the wire with tcpdump.
This I haven't done, might be worth a shot. Don't have time to do this
right now but as soon as I have done it I'll mail the results.


...


Any ideas of how to investigate further? It seems that I'm the only
one with this problem beacause I can't find any other posts about
this. Unfortunately I don't have any other computers with tapedrives
on them to try and reproduce the problem (although it seems to be
about networking so a tapedrive might not be necessary to investigate
further).


You don't need a tapedrive at all. Read the FILE-HOWTO in the
docs directory to setup virtual tapes. Takes only 5-10 minutes.
Ok, then I might be able to reproduce on a faster machine that doesn't
need to be running 24/7




Thanks for any help.

Let me know if I need to post more info, don't want to write an
unnecessary overly large e-mail.


You may always mail me personally the complete debugging info, or
packet trace if you like.
I'll see if I can understand anything from the packet dump if not I
might send them to you for a quick look.

Thanks for your time and keep coming with more good ideas ;)

/Andreas

On Sun, Jun 13, 2004 at 10:41:14PM +0200, Andreas Sundstrom wrote:
--with-user=root \
--with-group=root

A stab in the dark here: these settings seem a bit suspicious.
Normally one doesn't run Amanda as root; it's able to get root
privilege when it needs it (that's what the little runtar and
rundump programs are for). I don't know anything about
2.6-series kernels, but maybe some change snuck in that
interferes with Amanda trying to run as root.

Even if that turns out not to be the source of your 2.6.6
problem, for security reasons I'd suggest running Amanda as some
other user.

--

| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. erics < at > telepres.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

Eric Siegerman wrote:
On Sun, Jun 13, 2004 at 10:41:14PM +0200, Andreas Sundstrom wrote:

--with-user=root \
--with-group=root


A stab in the dark here: these settings seem a bit suspicious.
Normally one doesn't run Amanda as root; it's able to get root
privilege when it needs it (that's what the little runtar and
rundump programs are for). I don't know anything about
2.6-series kernels, but maybe some change snuck in that
interferes with Amanda trying to run as root.

Even if that turns out not to be the source of your 2.6.6
problem, for security reasons I'd suggest running Amanda as some
other user.

I'll give it a shot, I have actually ment to do that anyway, but since
everything has worked flawlessly I didn't bother. But I guess you never
can have to much security anyways.

/Andreas

Quoting Andreas Sundstrom <sunkan < at > zappa.cx>:

Eric Siegerman wrote:
On Sun, Jun 13, 2004 at 10:41:14PM +0200, Andreas Sundstrom wrote:

--with-user=root \
--with-group=root


A stab in the dark here: these settings seem a bit suspicious.
Normally one doesn't run Amanda as root; it's able to get root
privilege when it needs it (that's what the little runtar and
rundump programs are for). I don't know anything about
2.6-series kernels, but maybe some change snuck in that
interferes with Amanda trying to run as root.

Even if that turns out not to be the source of your 2.6.6
problem, for security reasons I'd suggest running Amanda as some
other user.

I'll give it a shot, I have actually ment to do that anyway, but since
everything has worked flawlessly I didn't bother. But I guess you never
can have to much security anyways.

/Andreas



Well, now I have created a user named amanda which has default group membership
disk and is also a member of users. Then I recompiled with user=amanda,
group=disk and installed.

I had som trouble to get it working but I eventually found out that when run
with xinetd this statement is needed "groups = yes".

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.

Thanks for the help and pointers so far everyone.
/Andreas

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.


--
Paul Bijnens, Xplanation 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.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, :, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, *
* kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ... "Are you sure?" ... YES ... Phew ... I'm out *
***********************************************************************

Hi, Andreas,

on Dienstag, 15. Juni 2004 at 09:29 you wrote to amanda-users:

AS> Well, now I have created a user named amanda which has default group membership
AS> disk and is also a member of users. Then I recompiled with user=amanda,
AS> group=disk and installed.

AS> I had som trouble to get it working but I eventually found out that when run
AS> with xinetd this statement is needed "groups = yes".

AS> All went well and the backup finished successful.

Fine ;-)

AS> Then I switched to my
AS> identically compiled 2.6.6-rc2 kernel and it fails with the same error as earlier:
AS> These dumps were to tape dflt10.
AS> The next tape Amanda expects to use is: dflt11.
AS> The next new tape already labelled is: dflt12.

AS> FAILURE AND STRANGE DUMP SUMMARY:
AS> zappa.zapp /imagelib lev 1 FAILED [bad CONNECT response]
AS> zappa.zapp /boot lev 0 FAILED 20040615[could not connect to zappa.zappa.cx]
AS> zappa.zapp /home/sunkan lev 1 FAILED 20040615[could not connect to zappa.zappa.cx]
AS> zappa.zapp /var lev 1 FAILED 20040615[could not connect to zappa.zappa.cx]
AS> zappa.zapp / lev 0 FAILED 20040615[could not connect to zappa.zappa.cx]
AS> zappa.zapp /home/emelie lev 0 FAILED 20040615[could not connect to zappa.zappa.cx]
AS> zappa.zapp /apps lev 0 FAILED [bad CONNECT response]

AS> So I tarred up the /tmp/amanda dir and put it at
AS> ftp://zappa.cx/pub/amanda-zappa.cx.tar.gz if anyone wants to take a look at it.
AS> This is the complete failed session and nothing else.

AS> Thanks for the help and pointers so far everyone.

I think you just run out of tcp-ports. I don't know exactly if that is
kernel-related but you could try to reconfigure amanda with the
options:

--with-tcpportrange=50000,50040 --with-udpportrange=890,899

(Substitute with your preferred port-numbers)

This would specify the range to use and rule out any differences that
might occur in handling this between kernel-releases. I have these
options in my amanda-configure-script for quite a time now and never
hit these problems with any 2.6-kernel.

You could also read the docs/PORT-USAGE document for more infos on
port-handling.

Give it a try and let us know.

--

Apart from that the server-side logs would be interesting but I
suggest that reconfig-run first.

--
best regards,
Stefan

Stefan G. Weichinger
mailto:monitor < at > oops.co.at

Quoting Paul Bijnens <paul.bijnens < at > xplanation.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

Quoting "Stefan G. Weichinger" <monitor < at > oops.co.at>:

Hi, Andreas,

on Dienstag, 15. Juni 2004 at 09:29 you wrote to amanda-users:

AS> Well, now I have created a user named amanda which has default group
membership
AS> disk and is also a member of users. Then I recompiled with user=amanda,
AS> group=disk and installed.

AS> I had som trouble to get it working but I eventually found out that when
run
AS> with xinetd this statement is needed "groups = yes".

AS> All went well and the backup finished successful.

Fine ;-)

AS> Then I switched to my
AS> identically compiled 2.6.6-rc2 kernel and it fails with the same error as
earlier:
AS> These dumps were to tape dflt10.
AS> The next tape Amanda expects to use is: dflt11.
AS> The next new tape already labelled is: dflt12.

AS> FAILURE AND STRANGE DUMP SUMMARY:
AS> zappa.zapp /imagelib lev 1 FAILED [bad CONNECT response]
AS> zappa.zapp /boot lev 0 FAILED 20040615[could not connect to
zappa.zappa.cx]
AS> zappa.zapp /home/sunkan lev 1 FAILED 20040615[could not connect to
zappa.zappa.cx]
AS> zappa.zapp /var lev 1 FAILED 20040615[could not connect to
zappa.zappa.cx]
AS> zappa.zapp / lev 0 FAILED 20040615[could not connect to
zappa.zappa.cx]
AS> zappa.zapp /home/emelie lev 0 FAILED 20040615[could not connect to
zappa.zappa.cx]
AS> zappa.zapp /apps lev 0 FAILED [bad CONNECT response]

AS> So I tarred up the /tmp/amanda dir and put it at
AS> ftp://zappa.cx/pub/amanda-zappa.cx.tar.gz if anyone wants to take a look
at it.
AS> This is the complete failed session and nothing else.

AS> Thanks for the help and pointers so far everyone.

I think you just run out of tcp-ports. I don't know exactly if that is
kernel-related but you could try to reconfigure amanda with the
options:

--with-tcpportrange=50000,50040 --with-udpportrange=890,899

(Substitute with your preferred port-numbers)

This would specify the range to use and rule out any differences that
might occur in handling this between kernel-releases. I have these
options in my amanda-configure-script for quite a time now and never
hit these problems with any 2.6-kernel.

You could also read the docs/PORT-USAGE document for more infos on
port-handling.

Give it a try and let us know.

Compiling now.. will send info later. Thanks for your time.

/Andreas

Quoting "Stefan G. Weichinger" <monitor < at > oops.co.at>:

Hi, Andreas,

on Dienstag, 15. Juni 2004 at 09:29 you wrote to amanda-users:

AS> Well, now I have created a user named amanda which has default group
membership
AS> disk and is also a member of users. Then I recompiled with user=amanda,
AS> group=disk and installed.

AS> I had som trouble to get it working but I eventually found out that when
run
AS> with xinetd this statement is needed "groups = yes".

AS> All went well and the backup finished successful.

Fine ;-)

AS> Then I switched to my
AS> identically compiled 2.6.6-rc2 kernel and it fails with the same error as
earlier:
AS> These dumps were to tape dflt10.
AS> The next tape Amanda expects to use is: dflt11.
AS> The next new tape already labelled is: dflt12.

AS> FAILURE AND STRANGE DUMP SUMMARY:
AS> zappa.zapp /imagelib lev 1 FAILED [bad CONNECT response]
AS> zappa.zapp /boot lev 0 FAILED 20040615[could not connect to
zappa.zappa.cx]
AS> zappa.zapp /home/sunkan lev 1 FAILED 20040615[could not connect to
zappa.zappa.cx]
AS> zappa.zapp /var lev 1 FAILED 20040615[could not connect to
zappa.zappa.cx]
AS> zappa.zapp / lev 0 FAILED 20040615[could not connect to
zappa.zappa.cx]
AS> zappa.zapp /home/emelie lev 0 FAILED 20040615[could not connect to
zappa.zappa.cx]
AS> zappa.zapp /apps lev 0 FAILED [bad CONNECT response]

AS> So I tarred up the /tmp/amanda dir and put it at
AS> ftp://zappa.cx/pub/amanda-zappa.cx.tar.gz if anyone wants to take a look
at it.
AS> This is the complete failed session and nothing else.

AS> Thanks for the help and pointers so far everyone.

I think you just run out of tcp-ports. I don't know exactly if that is
kernel-related but you could try to reconfigure amanda with the
options:

--with-tcpportrange=50000,50040 --with-udpportrange=890,899

(Substitute with your preferred port-numbers)

This would specify the range to use and rule out any differences that
might occur in handling this between kernel-releases. I have these
options in my amanda-configure-script for quite a time now and never
hit these problems with any 2.6-kernel.

You could also read the docs/PORT-USAGE document for more infos on
port-handling.

Give it a try and let us know.

Compiling now.. will send info later. Thanks for your time.

/Andreas

Andreas Sundstrom wrote:

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"?

This works for me on Linux 2.4.22:

sudo tcpdump -i lo -w trace.lo


--
Paul Bijnens, Xplanation 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.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, :, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, *
* kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ... "Are you sure?" ... YES ... Phew ... I'm out *
***********************************************************************

Quoting Paul Bijnens <paul.bijnens < at > xplanation.com>:

Andreas Sundstrom wrote:

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"?

This works for me on Linux 2.4.22:

sudo tcpdump -i lo -w trace.lo

I have now made a dump on the traffic passing through lo during the amdump. I
have also recompiled amanda with these two settings (as another friendly person
suggested): --with-tcpportrange=50000,50040 --with-udpportrange=890,899

The dump is available at ftp://zappa.cx/pub/amanda.pcap

I used this filter in ethereal to get rid of some other stuff that I suppose is
not interesting: "! dns and ! tcp.port == 25"

I'm not that used to looking at packet dumps and I have never looked at a
working amanda dump so have a look and see if it gives you anymore clues about
what is going on.

/Andreas