I have a problem with HTTP Keep-Alive connections. Below is a typical example, but it also manifests itself when attempting to browse websites with reasonably complex page structures. These sites can be accessed as expected from other machines connected to the same router/adsl modem, including the one this trace came from when booted into another OS.
The strange aspect is the high relative seq number in packet 53334. It supposedly comes from the server, but I'm not so sure. It must confuse the client, since there is no response and the server starts sending TCP Keep-Alives until the client gives up after 2 minutes and RSTs.
Anyone have an explanation?
Thanks a lot.
The expected next sequence number (calculated from frame #6) should be
However, the sequence number in frame #8 is:
That's totally off the expected value (difference: -16711936)!!
The seq numbers in the following keep-alive frames are as expected:
Conclusion: Either the OS that sent the wrong sequence number has a bug, or something on the way modified the packet.
If you look at the HEX values, you'll see the difference:
As you can see, there are only 4 bits flipped. So, I guess it's a problem with some system on the way (router/firewall/nat device) that flips the bits. It could be your network interface or the driver.
Apparently there is also a bug in Wireshark, as it does not detect the problematic seq number. Please file a bug report at bugs.wireshark.org and supply the capture file. Please add a link to this question.
In my experience you see strange big jumps in sequence numbers like this when you use relative sequence numbers. You should verify this behaviour by turning them off in the TCP protocol preferences. In most cases you see that the sequence numbers behave normally when shown as absolute numbers.
answered 22 Nov '12, 15:10