How TCP Sequence Numbers Work - TCP Deep Dive // Hands-On Case Study

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

Channel: Chris Greer

Views: 4,480

Keywords: intro to wireshark, wireshark, tcp/ip analysis, introduction to wireshark, chris greer, free wireshark training, getting started with wireshark, wireshark for beginners, wireshark tutorial, wireshark tutorial 2021, wireshark training, wireshark tips, tcp/ip, tcp vs udp, how tcp works, ccna tcp, network+ tcp, tcp, tcp retransmissions, wireshark case study, packet analysis, tcp acks, tcp acknowledgements

Id: 9xfjN5AR99I

Length: 16min 40sec (1000 seconds)

Published: Tue Nov 30 2021