This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

What’s wrong with this sequence number?

0

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.

51945 17:45:55.607661000 192.168.104.2         [server] TCP      66     51712 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1

51946 17:45:55.608736000 [server] 192.168.104.2 TCP 66 http > 51712 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=1

51947 17:45:55.608855000 192.168.104.2 [server] TCP 54 51712 > http [ACK] Seq=1 Ack=1 Win=65536 Len=0

51948 17:45:55.608973000 192.168.104.2 [server] HTTP 223 HEAD /w8/2/windowsupdate/redir/wuredir.cab?1211221741 HTTP/1.1

51950 17:45:55.609940000 [server] 192.168.104.2 TCP 60 http > 51712 [ACK] Seq=1 Ack=170 Win=5840 Len=0

53332 17:46:47.451217000 [server] 192.168.104.2 HTTP 318 HTTP/1.1 200 OK

53333 17:46:47.456900000 192.168.104.2 [server] HTTP 222 GET /w8/2/windowsupdate/redir/wuredir.cab?1211221741 HTTP/1.1

53334 17:46:47.457671000 [server] 192.168.104.2 TCP 60 http > 51712 [ACK] Seq=4278255625 Ack=338 Win=5840 Len=0

53344 17:46:47.794913000 [server] 192.168.104.2 TCP 60 [TCP Keep-Alive] http > 51712 [ACK] Seq=264 Ack=338 Win=5840 Len=0

53345 17:46:47.794946000 192.168.104.2 [server] TCP 54 [TCP Keep-Alive ACK] 51712 > http [ACK] Seq=338 Ack=265 Win=65280 Len=0

[Several pairs of TCP Keep-Alive/TCP Keep-Alive ACK]

56886 17:48:34.902133000 [server] 192.168.104.2 TCP 60 [TCP Keep-Alive] http > 51712 [ACK] Seq=264 Ack=338 Win=5840 Len=0

56887 17:48:34.902214000 192.168.104.2 [server] TCP 54 [TCP Keep-Alive ACK] 51712 > http [ACK] Seq=338 Ack=265 Win=65280 Len=0

57001 17:48:47.599538000 192.168.104.2 [server] TCP 54 51712 > http [RST, ACK] Seq=338 Ack=265 Win=0 Len=0

asked 22 Nov ‘12, 14:29

AdrianCrossan's gravatar image

AdrianCrossan
6113
accept rate: 0%

edited 26 Feb ‘13, 14:27

grahamb's gravatar image

grahamb ♦
19.8k330206


2 Answers:

0

The expected next sequence number (calculated from frame #6) should be

Next sequence number: 3952704914

However, the sequence number in frame #8 is:

Sequence number: 3935992978

That's totally off the expected value (difference: -16711936)!!

The seq numbers in the following keep-alive frames are as expected:

Sequence number: 3952704913

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:

3952704914 EB997D92 11101011100110010111110110010010
3935992978 EA9A7C92 11101010100110100111110010010010

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
Kurt

answered 23 Nov '12, 10:41

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 23 Nov '12, 11:01

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

(23 Nov '12, 10:49) AdrianCrossan
1

maybe your internet router/firewall? See my update in the answer. There are only 4 bits flipped.

(23 Nov '12, 10:50) Kurt Knochner ♦

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

(23 Nov '12, 11:48) AdrianCrossan

can you:

  • test a different server to eliminate that part
  • change the nic (or try wifi/wlan) to eliminate that part
  • change the cable (sounds weird. It's not ;-))

good luck with your further tests.

(23 Nov '12, 11:59) Kurt Knochner ♦

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.

(01 Dec '12, 08:39) AdrianCrossan

0

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's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

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?

tshark -r input.cap -E separator=, -T fields -e frame.number -e ip.src -e ip.dst -e tcp.len -e tcp.flags -e tcp.seq -e tcp.ack -o tcp.relative_sequence_numbers:FALSE

tshark -r input.cap -E separator=, -T fields -e frame.number -e ip.src -e ip.dst -e tcp.len -e tcp.flags -e tcp.seq -e tcp.ack -o tcp.relative_sequence_numbers:TRUE

(23 Nov '12, 01:56) Kurt Knochner ♦

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.

  • Can you post the real pcap file somewhere?
  • what is your Wireshark version (wireshark -v)?
(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