On Dec 18, 11:20am, "John F. Woods" wrote:
>20:34:20.039148 jared.wormspace.com.1158 > gate2.wormspace.com.ftp-data: P 110224:111400(1176) ack 1 win 8760 (DF)
>20:34:20.040731 jared.wormspace.com.1158 > gate2.wormspace.com.ftp-data: . 111400:112860(1460) ack 1 win 8760 (DF)
>20:34:20.040799 gate2.wormspace.com.ftp-data > jared.wormspace.com.1158: . ack 110224 win 17520 [tos 0x8]
<pause>
>20:34:20.636320 jared.wormspace.com.1158 > gate2.wormspace.com.ftp-data: P 110224:111684(1460) ack 1 win 8760 (DF)
<CLUE>
>20:34:20.636463 gate2.wormspace.com.ftp-data > jared.wormspace.com.1158: . 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.

OK, I kinda see that.  I see no other mention of 111400 in the data stream
besides these two.  Is that a dropped packet?

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

Here's the output of those commands:

<319 gateway /home/allen>% netstat -pip
ip:
        951494 total packets received
        879 bad header checksums
        0 with size smaller than minimum
        0 with data size < data length
        0 with length > max ip packet size
        0 with header length < data size
        0 with data length < header length
        0 with bad options
        617 with incorrect version number
        0 fragments received    0 fragments dropped (dup or out of space)
        0 malformed fragments dropped
        0 fragments dropped after timeout
        0 packets reassembled ok
        724510 packets for this host
        16 packets for unknown/unsupported protocol
        225472 packets forwarded (0 packets fast forwarded)
        0 packets not forwardable
        0 redirects sent
        863657 packets sent from this host
        1 packet sent with fabricated ip header
        0 output packets dropped due to no bufs, etc.
        0 output packets discarded due to no route
        0 output datagrams fragmented
        0 fragments created
        0 datagrams that can't be fragmented
<320 gateway /home/allen>% netstat -ptcp
tcp:
        857840 packets sent
                384960 data packets (528325328 bytes)
                97 data packets (33361 bytes) retransmitted
                314946 ack-only packets (191923 delayed)
                0 URG only packets
                21 window probe packets
                157518 window update packets
                298 control packets
        718821 packets received
                202655 acks (for 528356156 bytes)
                2962 duplicate acks
                0 acks for unsent data
                327282 packets (393414494 bytes) received in-sequence
                2918 completely duplicate packets (3461633 bytes)
                0 old duplicate packets
                29914 packets with some dup. data (37576516 bytes duped)
                158174 out-of-order packets (177879969 bytes)
                11 packets (3105 bytes) of data after window
                5 window probes
                6211 window update packets
                13 packets received after close
                35421 discarded for bad checksums
                1 discarded for bad header offset field
                0 discarded because packet too short
        144 connection requests
        51 connection accepts
        175 connections established (including accepts)
        204 connections closed (including 10 drops)
        20 embryonic connections dropped
        100553 segments updated rtt (of 99685 attempts)
        82 retransmit timeouts
                0 connections dropped by rexmit timeout
        26 persist timeouts (resulting in 0 dropped connections)
        14 keepalive timeouts
                5 keepalive probes sent
                0 connections dropped by keepalive
        141762 correct ACK header predictions
        311964 correct data packet header predictions
        156 PCB hash misses
        50 dropped due to no socket
        0 connections drained due to memory shortage
        1 bad connection attempt
        52 SYN cache entries added
                0 hash collisions
                51 completed
                0 aborted (no space to build PCB)
                1 timed out
                0 dropped due to overflow
                0 dropped due to bucket overflow
                0 dropped due to RST
                0 dropped due to ICMP unreachable
        0 duplicate SYNs received for entries already in the cache
        0 SYNs dropped (no route or no space)

There seems to have been a *heck* of a lot of out-of-order packets...

>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

Wouldn't that affect data going the other way, too?  Downloads to the Win98
box average 900KB/sec.

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

An additional data point -- my Q650, running MacOS 8.1, transfers in both
directions at ~270KB/sec.  At this point, I suspect the most likely answer
is that the Win98 box is breaking it on the way out.  I do have another
enet card (different manuf/model) that I can try in it.

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

The only other hardware I have is a second Q650 running NetBSD, but it's
also -current as of a week or so ago.  I could try sampling on there at
the same time to see if it catches any differences...

Thanks,
~Steve

-- 
Steve Allen - wormey@eskimo.com   http://www.eskimo.com/~wormey/   ICQ 6709819

Faith is the quality that enables you to eat blackberry jam on a picnic
without looking to see whether the seeds move.

Contrary to popular belief, Unix is user friendly.  
It just happens to be selective about who it makes friends with.
	-Kyle Hearn  <kyle@intex.net>

We don't understand the software, and sometimes we don't understand the
hardware, but we can *___see* the blinking lights!