Re: FTP stalls on tl0 on Challenge S

["Stephen M. Rumble" <rumble%cs.stanford.edu@localhost>]

On Mar 25, 2010, at 4:21 PM, George Harvey wrote:

> I copied the file on to another local NetBSD box (an Ultra 5), did some
> experimenting, and it appears that it's the length that is the
> significant factor. If I add a byte, FTP works, if I remove a byte, FTP
> works, but at exactly 1831 bytes FTP stalls. Apart from that, the
> ThunderLAN card is working fine, I'm running xterm sessions and NFS
> mounts through it no problem. Any ideas what's special about a length
> of 1831?

I can't say I have any good idea of what could be going on, but here are a few 
things to consider:

1) Have you tried other odd-sized files (e.g. add/subtract 2 bytes from the 
affected file)? I can't imagine all odd-length packets are being screwed up, 
but who knows?

2) Have you looked at tcpdump output on the sgimips and server machines? I'm 
wondering whether the second (and final) data packet gets through for the 
remaining bytes, or if something else is amiss.

If you're not sure what to look for, you could run the following during an 
attempted transfer and send me the 'out.cap' dumps:
    "tcpdump -s 0 -w out.cap src sgi.box.ip.address" on the server, and
    "tcpdump -s 0 -w out.cap src sparc.server.ip.address" on the tl0 client 
machine

3) Have you looked at netstat -s? It might be interesting to do 'netstat -s > 
before', run the failing transfer for a few seconds, do 'netstat -s > after' 
and diff the two files. If packets are getting corrupted somehow, bad checksum 
counters should increment.

It might be worth trying this on both the client and server, just in case we're 
screwing up transmitted packets on the tl0 interface.

I probably won't be able to fix anything (my sgi kit is on the wrong coast), 
but I'm curious to get a better idea of what's going on.

Steve