Subject: Re: ftp transfer speed anomaly
To: Space Case <>
From: John F. Woods <>
List: current-users
Date: 12/18/1998 11:20:13
> Here's an excerpt from the tcpdump (the whole dump is available at

20:34:20.039148 > P 110224:111400(1176) ack 1 win 8760 (DF)
20:34:20.040731 > . 111400:112860(1460) ack 1 win 8760 (DF)
20:34:20.040799 > . ack 110224 win 17520 [tos 0x8]
20:34:20.636320 > P 110224:111684(1460) ack 1 win 8760 (DF)
20:34:20.636463 > . ack 112860 win 14884 [tos 0x8]

gate2 did not acknowledge receiving the data between 110224 and 112860.  jared
waited a decent amount of time, then resent the data.  The same looks like it
is true for the later pauses as well.

If tcpdump saw the data come in, the ethernet hardware presumably received it
OK, so it must have been either IP or TCP that pitched it.  Use "netstat -pip"
and "netstat -ptcp" to figure out which layer is discarding the data, and why.
You might also do a tcpdump including full data so that you can calculate the
checksums on the ignored packets by hand (oh, that's always fun!).

You might have cabling problems that are corrupting packets from the Win98 box,
although that seems less than likely if the Ethernet checksum is OK.  You
might have bad ethernet hardware on the Win98 box that corrupts occasional
packets before the Ethernet checksum is calculated  (which I think happens on
the fly as it is being transmitted, anyway).  Or maybe NetBSD is fouling up
these packets in memory and thus miscalculating the checksum.

If you can get hold of an Ethernet sniffer (or failing that, another Windows
box with a software Ethernet sniffer), you should be able to obtain independant
verification of how those packets look on the wire.  Alternatively, a NetBSD
box running something of radically different vintage than gate2 (to minimize
the likelihood that any packet corrupting bugs will be shared between them)
or a FreeBSD or Linux box could serve as a sniffer.