Re: FTP stalls on tl0 on Challenge S

[George Harvey <fr30%dial.pipex.com@localhost>]

On Thu, 25 Mar 2010 23:43:46 -0700
"Stephen M. Rumble" <rumble%cs.stanford.edu@localhost> wrote:

> 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. 

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

Lengths of 1828, 1829, 1830, 1832, 1833 all work, 1831 and 3279 both
stall so it's looking a bit like the bug strikes with lengths of 
(n * 1448) + 383.

I also tried with wget and that stalls in the same place.

> 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.

I've got a wireshark dump which I'll send separately, the final 383
bytes are sent but seem to get lost somewhere at the SGI end.

> 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.

Good call, the bad checksum count does increment. Wireshark says the IP
and TCP checksums are good so that tends to confirm the problem's in
the SGI.

Thanks,
George