Subject: Re: weird network delays connecting to cable provider's servers...
To: Greg Oster <email@example.com>
From: Bill Sommerfeld <firstname.lastname@example.org>
Date: 04/22/1999 10:31:04
> 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..
-> 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)