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. asked 22 Nov ‘12, 14:29  AdrianCrossan edited 26 Feb ‘13, 14:27  grahamb ♦ |
2 Answers:
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. Regards answered 23 Nov '12, 10:41  Kurt Knochner ♦ edited 23 Nov '12, 11:01 |
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  Jasper ♦♦ Thanks, unfortunately I can't check at the moment. The reason I was suspicious is because the sequence numbers were the same or in a similar range for other requests. Also - on the same machine running XP - a similar reuse of a connection to get multiple files for a web page does not cause a jump in sequence number: (22 Nov '12, 16:06) AdrianCrossan 1407 [client] [server] HTTP 927 GET /js/app/... HTTP/1.1 1409 [server] [client] TCP 60 http > dts [ACK] Seq=112189 Ack=2582 Win=10500 Len=0 1427 [server] [client] HTTP 1514 HTTP/1.1 200 OK 1428 [server] [client] HTTP 642 Continuation... 1429 [client] [server] TCP 54 dts > http [ACK] Seq=2582 Ack=114237 Win=65536 Len=0 1434 [server] [client] HTTP 152 Continuation... 1496 [client] [server] TCP 54 dts > http [ACK] Seq=2582 Ack=114335 Win=65438 Len=0 1688 [client] [server] HTTP 994 GET /news/... HTTP/1.1 1689 [server] [client] TCP 60 http > dts [ACK] Seq=114335 Ack=3522 Win=12220 Len=0 (22 Nov '12, 16:07) AdrianCrossan Here's example with actual seq nos. server's seq no. comes out of nowhere! 22709 [client] [server] HTTP 222 GET /... HTTP/1.1 Sequence number: 2886430470 Next sequence number: 2886430638 Acknowledgment number: 2582068127 22710 [server] [client] TCP 60 http > 49437 [ACK] Seq=2565356191 Ack=2886430638 Win=5840 Len=0 22718 [server] [client] TCP 60 [TCP Keep-Alive] http > 49437 [ACK] Seq=2582068126 Ack=2886430638 Win=5840 Len=0 22719 [client] [server] TCP 54 [TCP Keep-Alive ACK] 49437 > http [ACK] Seq=2886430638 Ack=2582068127 Win=65280 Len=0 (23 Nov '12, 01:21) AdrianCrossan can you either post the whole capture file somewhere, or at least the output of the following two commands for that TCP connection?
(23 Nov '12, 01:56) Kurt Knochner ♦ Try these... https://docs.google.com/open?id=0BwugERON4pF8SU1vaHkxeWZyUjQ https://docs.google.com/open?id=0BwugERON4pF8ZWZDUmU3dm1Eblk Thanks (23 Nov '12, 05:01) AdrianCrossan O.K. it shows clearly the "wrong" seq number in relative mode. Either there is something in the packet or it's a bug in Wireshark.
(23 Nov '12, 07:41) Kurt Knochner ♦ Version 1.8.3 (SVN Rev 45256 from /trunk-1.8) https://docs.google.com/open?id=0BwugERON4pF8NnRtaFhFSThyVXM (15KB) Don't think it's a bug in Wireshark; this is having a major impact on the machine's ability to do standard HTTP stuff on the internet. Other stuff is OK, e.g. mail, HTTPS. Cheers. (23 Nov '12, 10:17) AdrianCrossan showing 5 of 7 show 2 more comments |
OK, I'll file a bug report. However, I'm seeing this symptom from lot's of different websites/servers so I suspect an issue at my end.
Cheers
maybe your internet router/firewall? See my update in the answer. There are only 4 bits flipped.
Ah, well spotted. I've been trying different driver versions, but no luck so far. What's frustrating is it has been working, but not not since some update has gone wrong somewhere...
can you:
good luck with your further tests.
Here's an update. I tried both bluetooth and wireless, using my mobile phone as a hotspot. Both worked so I was able to sort out Windows updates, but that didn't resolve it. I got a new router with wireless, expecting to have to use a wifi connection, but the wired connection was fine. Therefore the issue was caused by the old router, which I didn't suspect because it was working originally and other PCs were fine. Not sure what caused it to start playing up, and will probably never know... Anyway this question is now closed! Thanks.