Hi Carl - I didn't apparently explain well in the first post - tcpdump
is running on the same machine as the ftp client that wedges. Since
tcpdump sees and decodes the packets they are getting to the machine -
just not to the ftp client, like so;
remote ftp server -> DSL circuit -> LM 6.1 box running ftp client and
tcpdump
AFAIK the correctly incrementing relative bytes reported by tcpdump
indicate that the machine is receiving the traffic. It just stops being
handed to the ftp client. If the NIC was wedging tcpdump would not see
the traffic either, or traffic would be hosed. The relative bytes counts
don't indicate this. And other traffic concurrently running out the DSL
circuit stay up (i.e. a ping to the remote ftp server). And ftp control
comes back just fine at the end of the trace.
Since I don't have any other ideas - you've been the only response -
I'll switch NIC's anyway this weekend.
And I didn't think I was that young :) - Kirk
"Carl A. Cook" wrote:
>
> > Carl - no, the ftp transfer hangs happens both as a client and a server.
> > The tcpdump trace in the original post is with the machine as a client.
>
> I meant that particular machine, which served as client in some of your latter
> tests. You indicated it =doesn't= see packets it should at times. And I was
> wondering if the =other= machine you're using (hopefully with similar config)
> works with an outside public server with a large download. This would test
> software.
>
> I'm an old DECTech from before you were born, and the failure under stress, and
> time randomness looks to me like hardware... either your DSL router or NIC.
> --
> Carl A. Cook
> quantumATaugustmailDOTcom
>
> Sign the petition at http://www.libranet.com/petition.html
> Help bring us more Linux Drivers
--
Kirk Grier
[EMAIL PROTECTED], [EMAIL PROTECTED]
http://www.bigfoot.com/~kirk.grier/
805-893-7960 office, 805-571-2601 office fax, 630-982-1198 pers efax
