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

Next sequence number calculation in wireshark

0
1

Hello,

I am trying to analyse packets in an ssl stream. Some packets have an additional field in the TCP header [Next Sequence Number : XXXX] which is calculated by wireshark. Would be great if someone could tell me how this calculation is done.

Thanks!

asked 23 Apr '12, 11:10

flyhigh's gravatar image

flyhigh
1121
accept rate: 0%


One Answer:

2

Simple: it takes the current sequence number (specified usually just in front of the "next sequence number" field) and adds the tcp payload length. The easiest way to find the payload length is by looking at the TCP protocol header - at the end, it says "len:".

By the way, the "Next Sequence Number" is also nice to have to determine the acknowledge number for this packet, because it's the same.

answered 23 Apr '12, 12:09

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

edited 23 Apr '12, 12:10

Thanks a lot! Just one more question : How is the stream index calculated in wireshark. I am trying to parse packets in my code, and perform some operations on the packets in the same TCP stream. So I would like to maintain stream numbers to achieve the same.

(23 Apr '12, 13:08) flyhigh
1

SYN-bit can probably tell you more about it, but I think it comes down to this: whenever Wireshark finds a new socket pair (socket being a combination of IP address and TCP port; a pair of it identifying a conversation) it will increase the stream index and assign it to all packets of that conversation.

Some older versions count it up for UDP conversations, too, but AFAIK SYN-bit wanted to change that. It caused too much confusion why there are gaps in the TCP stream numberings. I just forgot if he already did :-)

(23 Apr '12, 13:51) Jasper ♦♦
1

Jasper is correct. When I first implemented the tcp.stream index, I reused a value already available in the code used for conversations (which does include other protocols apart from tcp). This resulted in gaps in the tcp.stream numbering and a lot of confusion.

Since SVN 38056 (July 16, 2011), this has been changed to using separate numbering for tcp.stream values so that the numbering will monotonously increase for each new tcp session.

I don't think this code has made it to the 1.6.x versions, but it is included in the 1.7.x versions and will make it into 1.8.0

(23 Apr '12, 14:04) SYN-bit ♦♦