The problem ended up being the autosensing media. I have never run into a
problem with a media autosense before but I think from now on I will try to
set that every time I setup a network card.
Thanks for the Help,
Ryan Williams
----- Original Message -----
From: "John R. Jackson" <[EMAIL PROTECTED]>
To: "Ryan Williams" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, May 01, 2001 6:59 PM
Subject: Re: Strange Amanda Error: sendbackup: index tee cannot write
[Broken pipe]
> >It is a 100meg card set to autoselect between all of the 100 and 10 base
T.
>
> Uh, huh. On Solaris, at least, autoselect is death. No matter what
> you try to do, it will pick wrong and really bad things start to happen.
> We **always** force the issue with an explicit config file entry.
>
> I don't know that's what's happening to you, but it's been a common
> problem.
>
> >The network is a 10baseT. I am not shure if it is full or half duplex.
...
>
> I'm out of my depth here, but I think if the cable is actually 10Mbit,
> duplex does not matter. Only 100Mbit bring duplex into the picture.
>
> >What do you make of that. I dont see anywhere that it says what it is
> >actually set at. ...
>
> Which might make sense if it does not apply because you're really only
> doing 10Mbit.
>
> >> It would also be useful to go to the client and look at
sendbackup*debug
> >> in /tmp/amanda, in particular the start and stop time (first and last
> >> lines).
> >
> >/usr/local/libexec/sendbackup: got input request: DUMP ad0s1e 0
> >1970:1:1:0:0:0 OPTIONS |;bsd-auth;srvcomp-fast;index;
> > parsed request as: program `DUMP' disk `ad0s1e' lev 0 since
1970:1:1:0:0:0
> >opt `|;bsd-auth;srvcomp-fast;index;'
> > waiting for connect on 2622, then 2623, then 2624
> >/usr/local/libexec/sendbackup: timeout on mesg port 2623
> >/usr/local/libexec/sendbackup: timeout on index port 2624
> >sendbackup: pid 79500 finish time Tue May 1 01:47:00 2001
>
> You cut off the first line, but in any case, this indicates something else
> is going on. It says sendbackup on the client got tired (30 seconds)
> of waiting on dumper on the server side to make the connections on
> those ports. The next line after "waiting for connect ..." should have
> been "got all connections".
>
> The sequence of events is:
>
> dumper connects to the amandad port on the client
>
> they do some security stuff (UDP packets) then dumper tells it to
> start sendbackup
>
> sendbackup starts listening on two or three new ports and sends their
> numbers (UDP packet) back to dumper on the server
>
> dumper connects to those ports (TCP) on the client and data starts
> to flow
>
> So either dumper never got the list of ports, or the connections it
> tried to make didn't work. It looks like dumper would log an error if
> the connection failed, which implies sendbackup never saw it.
>
> If you upgrade at least the server to 2.4.2p2, you'll get messages
> like this in the amdump.NN file showing that dumper did its part:
>
> dumper: stream_client: connected to 128.210.10.26.63832
> dumper: stream_client: our side is 0.0.0.0.63834
>
> Upgrading the client would show similar extra detail on that side.
>
> I don't know why this would be happening. Any firewalls or other
> protection between the two machines that would not allow these ports to
> go through? Any help from the FreeBSD folks?
>
> John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
>
