All right welcome back to the channel packet heads, and I thought in this video we could take a
closer look at sequence and acknowledgement number analysis. Now i know that this is a tedious topic,
I know it can be confusing. But the more practice you get at, it the better
you're gonna be with analyzing tcp flows with wireshark. So let's go ahead and get into it.
Now as always you can click the link in the description down below,
and that will get you to the trace file that you can use to follow right along. Now sequence
and acknowledgement number analysis - I've talked about these topics separately in different videos,
and you can find those up here. One for sequence numbers and the other for acknowledgement numbers
but what i'd like to do in this video is give you more practice of how to do this practically with
wireshark so go and pop open this example and you can follow right along now this was the same trace
file that i used in a previous video we looked at this when we were analyzing some re-transmissions
but key to understanding those re-transmissions is knowing how
sequence and acknowledgement numbers work so let's go ahead and take a closer look right
here i'm in my tcp basic profile in wireshark that's about to change i'm going to show you
a few adjustments you can make to make sequence number analysis a little bit easier on yourself
but key to this is understanding i have a tcp segment length column here
now in the handshake this is where i can see just this is just empty packets that are accomplishing
the goal of establishing a handshake here i've got sin sin hack act those are two endpoints
talking to one another now in the sin sinaka if i just take a look at the sin i come down here
to sequence number this is where i can see that wireshark is giving me a relative sequence number
basically what it's doing is it's saying okay this big scary looking number here let's just zero
this out just for the purposes of analyzing this thread and let's act as if this number was zero
now why are we going to do that well remember that every byte i send i track that using
sequence numbers if i send you 100 bytes you take the sequence number that i'm using you add 100
and then that now becomes the acknowledgement number that you use coming back to me that's
how i can tell that you got my 100 bytes all right so every byte i send has an associated
sequence number now as human beings we don't do very well with four by huge numbers that look like
this we don't do well starting counting from this number we like to start counting at zero so that's
why wireshark just takes this raw sequence number and zeros it out for us now this sequence number
is useful in some situations we'll make sure to cover that on a separate video but the sequence
number at the start it's nice to look at this as zero now keep in mind the next sequence number in
this direction is going to be 1. i send a ghost byte in the handshake basically the other side is
going to come back and say acknowledge 1 acting as if i had sent a byte of data in that initial
sin you always see that in every tcp handshake we basically exchange a ghost byte with the two sins
well the server comes back and it says all right here's my raw sequence number but wireshark is
going to zero it out for us and it's going to increment it by one so by the time we get
to the ack in the tcp handshake now both sides have exchanged that we're at sequence one in one
direction and sequence one in the other direction now as data gets exchanged in each direction those
sequence numbers are going to begin to increase all right so a value that's really useful to me as
i'm going and doing sequence analysis is obviously the sequence number so the first thing i'm going
to do come down i'm just going to say right click and i'm going to apply this guy as a column also
what's nice to know is my next expected sequence number that's good to have so i'm going to right
click and add that guy as a column and also the acknowledgement number not the raw but the
relative act number i'm going to right click that one and add it as a column
so now i can see up here and you can go and follow me and doing that that's actually great to do for
a tcp analysis profile or maybe you could create a new profile right click profile up there what
you can do is you can have a whole profile that has these columns so that when you're not doing
tcp sequence analysis you don't have your screen so full of these columns so in our case what our
goal is is to do this analysis so we're going to go and leave this alone all right so sequence
number next sequence number acknowledgement number and in fact something else that i can do with
these header values up here if i just want to save myself a little bit of screen real estate
is i can go ahead and right click sequence number i'm just going to say edit column and i'm going
to change the title to seq and then i'm going to be i'm going to use that number value there or
that number symbol and i say okay and you see how that changes the amount of space i need for that
description so i'm just going to pull this over just a hair and i'm just going to do the same
and then find act finally the act number
now that i have these i can buy myself just a little bit more space and let's go ahead and see
how these work together so first let's come down to packet four i'm starting at sequence number one
i send to 14. so when i have 2.14 plus 1 my next expected sequence number in this direction is 215.
the act number is still 1 because the other side hasn't sent me anything yet all right so
within an allotted amount of time an expected amount of time i never see an acknowledgement
all right so what do i do well i retransmit the same 214 bytes starting at sequence number one
215 is my next expected sequence number in this direction at the same time this is the number
that i should expect the other side to act with remember that the other side is going to take
my sequence number add the amount of dip bytes that i've sent and that will be the act number
that they use to come back to me this is how i know that the receiver got those two 14 bytes
they incremented their act number well beautiful that's great but here's a bit of a problem you
notice what happened with a sequence number here in this response coming from the sender we just
jumped up to 40 67. well the last time we saw a number in this direction it should have been one
this sender hasn't sent anything to us we don't see any tcp segment lengths of 4067
or anything that would add up to that because that would be a larger than acceptable frame size but
we don't see bytes that add up to that previous to this instead we just saw a jump to that sequence
number that's why wireshark goes whoa hang on a second tcp previous segment not captured
we missed something here it was supposed to be one and then we just saw this jump so what happened to
those 40 66 bytes well what happens next is you can see that the sender it waits two seconds now
there were probably some retransmissions happening on the other side that we didn't get to see
if you want to see more about why we believe that go ahead and hit this video this is where we break
down those re-transmissions in this trace file but what we're going to do is stick on the topic
of sequence analysis all right so our sequence numbers are 1 in this case so this was the packet
or bytes that we would expect to see but this time we just see 536 now this is a smaller packet size
this is basically the smallest mss that a tcp is going to try to use before it ditches the
connection so it might have tried a larger segment size and it ran into an mtu issue
and then it just last ditch thought you know what i'm going to try to get this thing through
so here's our sequence one so 536 plus one is 537 all right so since this packet made it through the
client then increments its acknowledgement number to 537 we receive this packet from the sender
now notice that this is an empty ack and the client is not incrementing its sequence number
it hasn't sent anything else since that original 214. so that's why we're going to see 215. we're
just going to sit on 215 until the client sends something else meanwhile the other side the server
coming back to us it sends 537 that was the last expected sequence number for us to start on 537
we're sending 536 that's how we arrive at 1073 for the next packet let our eyes go down there
1073 plus 536 1609 fabulous if we come down here to the client it says great i'm good to 1609.
i have successfully received everything up to 1609. i'm good on those two packets
wonderful let's keep going let's go ahead and scroll past this and here we run into another
problem our next expected sequence number was 1609 but here we can see the server it sends 21.45
so here we see another jump in sequence number so this is a gap it's got this large one
it sends it and then the next expected sequence number for this direction should be 26.81 so the
client says okay wait a second pump the brakes i was at 1609 having a great time just loving life
and then you went out of sequence again you jumped ahead and you sent this 536 now maybe the packets
before that this got lost maybe we have a gap here but let's go ahead and take a closer look
if we come down here let's go ahead and take a look at the acknowledgment number in packet 13.
so this is where the acknowledgement number is 1609. that's the sequence number point that we're
good to as a client but notice that we have a sac block that's starting to form so let's go ahead
and go down to options we're gonna expand this and our tcp option what this does is it says okay
i have successfully received 21.45 through 26.81 i'm good i got that 536. but i've got a problem
here because there's a gap between 1609 and 2145. there's 536 bytes that i'm missing
so you sent me packet one two three four five but i only got one two and four five i'm missing this
one that's in the middle all right so that's how the client indicates this to the server
well the server hasn't even gotten this dupe back yet it hasn't gotten that sac block so it just
keeps on sending so it's just thinking life is continuing on no problem 2681 through 32
17 there's a 536 there's another 536 and then finally a 314 so this is 37.53 to
2067. so now we're up to that original point that we started at remember 4067
4067 this is where the server thought that it was good but all of this data went missing likely due
to a too large mtu but if we come down here so there's the 4067 so our data hasn't uh yet all
cleared out yet because we haven't received everything yet but let's check this one out
the next packet down is packet 17. there's 1609 this one fills in the gap of our dupac
all right so our dupac flagged that we had some missing data they gave us that sac block but then
if we take a look here there's a this fills in that sac block that's indicated in packet 13.
now just for me when i take a look at this if i take a look at packet 13
and if i look at the delta times notice that i'm sub millisecond that these packets are
coming in these smaller packets so these guys were already in flight on the way to the client
when the client sent this dupe back so these are basically all sent in sequence just boom
boom boom boom and the client was like oh wait i missed one of them but hang on a second if we
come down here we can see that all of these were sent in succession but it looks like one of these
went out of order right look how fast this was sent this is sub millisecond
so we didn't have enough time for this dupac to get all the way to the sender and then for the
sender to react to that dupac and begin to trans or to know to re-transmit it wouldn't do it after
a single dupak anyway just because something like this can happen where just one goes out of order
so why kick off a re-transmission unless things just went a different path or if they got swapped
in some kind of way from the server back to the client okay so all the data got there
now we can see the client clearing itself out initially it goes all right do back do back
okay and then it goes oh wait a second i did get everything so packet 20 is the
client saying good all right okay i see you i see your server i'm good all the way to 4067.
thumbs up we can just continue off with life now but prior to this the client actually sent
these to other dukebacks it's possible that it was just reacting to packets above our 1609. it
was just saying great um i'm good actually sorry with the dewpak 1609 okay if i take a look at my
left edge right edge down in my my sac block i'm good to fit 37.53 if i take a look at
dupac 3 i'm good all the way to 4067 but hey mr server i'm missing between 1609 and this left edge
it had already received it but it's likely that the tcp was already in the process of acting that
data as it came in it just hadn't gotten around to acting this one yet which we see happen down in
packet 20. so all of our data got there but here's the thing this is kind of interesting as well
we sent out three due packs do pack one do back two do pack three what does that do that's gonna
trigger a re-transmission on the other side if you only get one dupe back with a sack block the
sender's gonna think why don't i just wait to see if you send me any more dukebacks because
maybe some outstanding data went out there and it just got swapped that's exactly what
happened here one came in out of order and the client caught up to acknowledging it but before
that happened we sent three dupaks that's going to trigger a fast re-transmission which is the
whole point of packet 22. the server's like whoa you needed 1609 to 2145 again to plug that hole
it's called spurious this is another part of wireshark fun sequence number analysis it's
called spurious because this packet was already received and already successfully acknowledged
so it's spurious it's not really necessary the data went and we already saw an acknowledgement
for that data so either this was just an extra re-transmission that was not necessary
or it's possible that those acts got lost on the way back to the server
that's also a possibility however just looking at the flow we can see that this was indeed spurious
all right so let's back up a second sequence and acknowledgement numbers it's nice to have
a profile like we have here in wireshark where we can see the sequence number the next sequence
number the acknowledgement number and we can follow these bytes as they flow in each direction
when you're doing sequence and acknowledgement number analysis you just got to slow down just
like we did and just take it pack it by packet watch the flows and that can help you to better
understand and really recreate the event in your own mind so practice practice practice the more
sequence and acknowledgement number analysis you do the easier it gets and the faster you can
use these columns to figure out what happened on the network i hope you enjoyed this video
and videos like these please like share subscribe and of course leave me a comment down below let
me know what you thought and of course i'm gonna see you on another video take care packet heads
you