Wireshark is used to examine TCP sequence and acknowledgment numbers in a live packet capture, showing how sequence values increment based on payload size and how acknowledgments confirm successful delivery.
TCP Sequence Numbers in Wireshark
We're going to use Wireshark to take a look at the sequence numbers. I already captured the data that happened between my demo laptop and my demo Pi, so let's take a look at that.
The first few packets between these two devices, the demo laptop and the demo Pi, are just the establishment of the TCP connection, but we want to bypass that. I'm going to go straight to where it makes the first request. This is packet 11 here in this sequence, the GET command to get the web page for the demo laptop from the demo Pi.
What we're going to do is take a look at the sequence number. To see that, I'm going to open up the TCP connection of this packet and we're going to look at these sequences. As I mentioned before, these are the actual sequences right here. This is the raw data, so if you actually look at the ones and zeros, this is the sequence number. It randomly generates it, which is why we see a very large number here, and then it goes up according to what we're going to discuss.
What we're going to do is just look at the relative sequence number, this one. What they've done is they said, rather than take a look at this really large number right here, we're going to simplify it and present it in a very simple form: we're going to start at one and we're going to count the way up from there. So this is the number that we're going to look at to analyze this data.
We see that this sequence starts at one. Then let's scroll down just a little ways and see what is in the TCP payload. This starts at byte number one — that is the first byte of the TCP payload here — and then it goes all the way up to 428 bytes, so the last byte is the 428th byte. So in our next TCP header, what we're going to see is that it's going to start with 429. And if we scroll up to this top part section again, it says next sequence number 429.
Here again, this is not data that is found in the TCP header, but Wireshark is giving this to us as a way to view into these packets. So once again we're starting with byte one, and this particular packet is delivering from byte one to byte 428, and then the next packet is going to start with 429.
Let's take a look at the next packet. What I'm looking for is the next packet that's coming from 10.1.0.14, which is my demo laptop, and going to 10.1.0.3. If I look at this, packet 14 is the next one that I want to look at. Sure enough, our sequence number is right here. I look down at the payload and this doesn't have payload information. The reason is because there is no payload for this. I'm going to shrink that field right there, and we see that it just ends with the layer 4. It's continuing on this TCP connection, but it's actually not transferring any data, and so there's no payload.
So it makes sense that — where do we have our sequence numbers? I opened the wrong layer here, so I'm going to open this up. If this is sequence number 429 with no payload, then it makes sense that the next expectation, the next sequence number, is going to be 429 again.
Let's take a look at the next packet. We take a look at the next packet and the sequence number once again starts with 429, and the payload is 365. So this is byte to byte 700. Well, let's actually look at it. I'm going to pull up a calculator and we're going to add 429. That comes up with 794, so our next sequence number is going to be 794.
Now let's take a look at our next communication that goes out. It looks like it's this one right here, although that's going to a different address. So the ones between — this is packet 19, and we see the sequence number is 794, which is what we said it would be. And is there a payload? There's no payload here, so the next sequence number will be — excuse me, I actually highlighted the wrong one because it's the same number. This is the sequence number of this; since there's no payload, the next sequence number is 794.
Let's take a look at what it looks like from an acknowledgement standpoint. I'm going to scroll up to the top here, go to our first packet that we looked at, which was where the sequence number was one. This had a payload of 428, so the next sequence number is 429.
Let's look at the return traffic that's coming from the demo Pi. I look at that and it says the acknowledgement number is 429. So what this demo Pi has sent back is: the next time you send me a packet, I'm expecting 429. In this case it makes sense, because there's no traffic that has been dropped. We see all the traffic, everything looks good, and it's expecting 429 as the next sequence.
Then we click on this next communication, which is happening again from the demo Pi to the demo laptop, and it has not changed at all, so we see the acknowledge number.
Then let's take a look at this packet 15, which is going from the demo laptop to the demo Pi. Its sequence number is 429, but it figures the next sequence number is going to be 794 because of that payload. So the acknowledgement number of the return traffic — this is coming from the demo Pi to the demo laptop — is 794. So it's recognizing that that is the next packet.
If this still said, in this case right here, if the last number it had was 429, and if this said the acknowledgement number of 429, it replied back with an acknowledgement number of 429, then the other machine, the demo laptop, would realize that this packet didn't make it to that device. So the demo laptop will recognize it didn't get to the device: I need to resend this. That's how that acknowledgement number works.
TechKnowSurge builds IT and cybersecurity professionals through hands-on, concept-first training built around real understanding — not memorization. Free interactive tools, structured programs, and 25+ years of real-world experience, all in one place.
Explore free tools and programs →