> From the traces I've got (from both my home end, and near
> "other_host"), what's happening is that the IP packet length field
> in the IP packet header is wrong by 4 bytes. (the TCP ACKs have a
> size of 0x28 when they leave my box, but have an (apparent) size of
> 0x2c on the receiveing end.  The IP end seems to pick the next 4
> bytes from whatever buffer it's in when the receving end gets the
> packet, but the TCP layer rejects the packet as the TCP checksums
> (usually) fail!)  Even more interesting is that this is exactly a
> 1-bit error... :-( The problem *only* shows up on the first ACK for
> a given data packet.  The ACK's for the retransmitted data get
> through just fine!!

Not that this is necessarily going on here, but this behavior is
eerily similar to a header compression vs ipflow bug I nailed a while
back. (see PR5560).

This *could* be a bug in the cable modem system in question..

symptoms:

 -> length was wrong on receiving end 
(the length is compressed out, and the layer-2 frame length
less layer-2 headers is used; a sender-side bug caused it to generate
an overly long l2 frame).

 -> only broke first transmission, not 2nd and subsequent.
(because header compression doesn't try to compress retransmissions)

						- Bill