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

In this video we are going to dive into TCP sequence number analysis. Every Packet Head needs to do this at one point or another. So let's get some practice. In this hands-on video, make sure to download the pcap below so you can follow along as we study a problem that was due to a low network MTU on the path.
---------Download the pcap here----------
packetpioneer.com/wp-content/...
== More On-Demand Training from Chris ==
▶Getting Started with Wireshark - bit.ly/udemywireshark
▶Getting Started with Nmap - bit.ly/udemynmap
== Live Wireshark Training ==
▶TCP/IP Deep Dive Analysis with Wireshark - bit.ly/virtualwireshark
== Private Wireshark Training ==
Let's get in touch - packetpioneer.com/product/pri...
Hope this helps Packet People! Please like, share, subscribe!
Chapters:
0:00 Intro
1:01 Configuring Wireshark

[@karimhamid7460]

The best Wireshark tutorial on the internet, no BS and straight to the point. Thanks Chris!

[@Zerback]

I can't say thank you enough on how important is for people like me, that is just starting on networking world after working in IT +10 years, seeing you and David doing what you do! Thank you !

[@ChrisGreer]

Thanks! I appreciate the comment.

[@dmitrysimbirtsev6685]

Chris keep on going the way you are! Thanks a lot for your great stuff.

[@ChrisGreer]

Thanks, will do!

[@felix5729]

Great explanation. First English speaking KZbinr I have followed.

[@DocFortyThree]

Thank you, Chris. This was very helpful. Your explanation and walk through made it so much easier.

[@victormarquim]

Thank you for this great video! Made it so much easier to understand this topic, which felt really confusing to me at first as newcomer in the field.

[@z0nerider]

Hay Chris, awesome vids man ! pls keep em comming, dont stop !!!! PCAP of performance / drop issues are a nightmare to troubleshoot but you make it soo easy!!!!

[@ChrisGreer]

Thank you!

[@redouaneelouidani1243]

Learning a lot with you. Thank you so much

[@ChrisGreer]

Happy to hear that!

[@nidhinyou]

Thanks Chris! enjoying your videos like a beautiful movie..

[@ericwf1]

This is great information Chris! I've learned so much watching your videos. Thanks very much!

[@ChrisGreer]

My pleasure!

[@juanrebella2589]

Thanks man, appreciate your work. Greetings from Manchester.

[@ShadyNetworker]

Amazing video again, thanks for putting these out!

[@ChrisGreer]

Glad you like them!

[@ShadyNetworker]

@@ChrisGreer TCP analysis is deceptively hard, I found. Even something seemingly simple like ACK numbers can throw you for a loop. At least, that the case for me.

[@267praveen]

Thanks Chris. I recently came across this series and I am glad for that. Its very helpful to dive into the packet analysis dark world 🌎 !!!

[@ChrisGreer]

Thanks for the comment!

[@fthdex]

Currently, I am writing some TCP/IP test cases with raw sockets and your analysis help me a lot to figure out the concept. Thanks for the simplified explanations and good quality videos!

[@ChrisGreer]

Doing my best to keep the content relevant and interesting. Thank you!

[@loveplanes]

Amazing! Thanks for sharing

[@pedrojaviermunozgarcia3721]

Excellent how you break down through thye details!!! Thanks a million man

[@ChrisGreer]

Glad it was helpful!

[@98854arjun]

Thanks Chris for all your teachings. Love from India!!

[@ChrisGreer]

My pleasure! Thanks for the shout out from India.

[@TiborBondor]

Very good explanation.

[@manigandansrinivasan5194]

You are always awesome when explaining difficult topics to make understand easily ... Great mentor ....Keep rocking ...

[@ChrisGreer]

Thank you for the comment!

[@colinrogers9927]

Great explanation sir

[@AbhishekYadav-kc1df]

Awesome explanation !! Thank you so much

[@ChrisGreer]

You are welcome!

[@jjames7206]

Thanks Chris!!! I am getting know TCP better!

[@ChrisGreer]

Great to hear!

[@teddybean9948]

10 out of 10 rating from me. Best explanation ever.

[@georgemilev3244]

Awesome stuff!

[@mcgirishnetwork]

Very useful information for troubleshooting

[@ChrisGreer]

Glad it was helpful!

[@punggukbulan8674]

Thanks Chris to spread this important knowledge..

[@ChrisGreer]

Thank you for the comment!

[@cyber_student]

🔥 🔥 🔥. You are the Truth my guy…

[@mike_on_tech]

Incredible teaching. Thanks so much

[@ChrisGreer]

Thanks for the comment. Very happy to hear it helped.

[@Casperr123]

Great teaching skills Chris, really really great

[@ChrisGreer]

Thanks Peter! I appreciate the feedback.

[@PouriyaJamshidi]

This was fantastic!

[@ChrisGreer]

Thanks for watching!

[@KADAMORIS]

Thank you for all you videos , value contents in the video.

[@ChrisGreer]

Glad you like them!

[@padmanathanvelusamy8580]

Thanks for the videos.. Learning a lot with these..

[@ChrisGreer]

Glad to hear it!

[@jparaujobezerra]

Learning a lot! great!

[@ChrisGreer]

Glad to hear that!

[@TheAychi]

Hi Chris thank you for this fantastic analysis again I dont know if my understanding is correct but i think that Since the server sends the packets #14-17 out of orders that were acknowledged by packets #18-20 Maybe The Packet #22 is a response to the packet #9 when the client asked for the gap and since this packet was already sent (the server flaged it with Superious Transmission).

[@pradnyasy8082]

I am a student and your videos are very helpful to me :)

[@ChrisGreer]

Glad to hear that!

[@asiyaahmad9866]

Chris, amazing video. Thanks a lot! The only concern is that the screen is not very clear. Its a blurred view.

[@malkeetkalera7520]

Thanx for uploading 🙏

[@ChrisGreer]

You are welcome!

[@PraveenRai]

Good one ..will wait for the video where you show us non relative seq number important and use case

[@ChrisGreer]

Great suggestion. Short answer? I use non-relative when I'm in a dual side capture analysis scenario and I need to track a packet through a NAT or a Port Translation. Usually those boxes will leave the original raw seq alone.

[@arifunal85]

Chris thank you for crystal clear informations. I am wondering, if videos have sequence numbers, would it be better?

[@ChrisGreer]

Good suggestion... I will see if I can sort that out.

[@walternakatana7603]

Dear Chris, thank you for your wonderful videos. Just one question, what are some protocols/captures to look for when computers are freezing/hanging when connected to the LAN on the same switch, only one switch in the building with 20+ users.

[@ChrisGreer]

Hmmm.... great question. I would look for connectivity kind of problems - ARPs, DNS Slow or No Response, TCP SYN Retransmissions, Resets, or maybe even unusual STP activity. That is where I would start at least!

[@IK-iu4rz]

Great stuff Chris, Thank you for your time and energy.

[@ChrisGreer]

Glad you enjoyed it

[@wedarengao8595]

Thank! 谢谢您！

[@haasjenl9247]

So Chris thanks again for the video! Nice stuff! So maybe i didn't catch this while watching but what was the problem in this trace!!?

[@ChrisGreer]

Thanks for the comment! So the issue was an MTU problem on the return path from the server. It was sending segments that were too large to fit under the MTU ceiling. From the pcaps we can determine that from the behavior, but we can't tell exactly which box was doing it.

[@jasonnavarro5971]

Thank you. 👍

[@ChrisGreer]

You are welcome!

[@user-zc4dw4jr6m]

thank you, very high quality material! quick question - at minute 15:17 - how can You be sure that the server got the 4067 ack? You said that "just by looking at the packet flow we can say that it was indeed spurious". but as I see it, theoretically it's possible that the 4067 ack didn't make it to the server, don't You think?

[@ChrisGreer]

It's most likely that the spurious retransmission was a result of the triple-double. There were three duplicate ACKS above it. The acks between, the ones you had mentioned, are fired off, and before the network roundtrip time (85mSec) we get the retransmitted data. Also, all symptoms indicate that there was packet loss of large MSS's in the direction from server back to client - not small packets (ACKS) from client to server. So it is pretty safe to assume that the server got those ACKs and was just reacting to the Triple double. This is another reason I really try to get trace files from both sides of the conversation so we can absolutely prove questions like you had. Thanks for the comment and hope that helps!

[@user-zc4dw4jr6m]

@@ChrisGreer that's very helpful, thanks so much!

[@redrover06able]

How likely the packet is not showing up in wireshark due to tcpdump or packet sniffer is not able to capture all the packets. I normally use the ip packet IP to identify gaps in my cpap. Not sure how accurate it is. Any recommendations?

[@nailsaggitarius4212]

Great video but you better to show the flow of sequences with UML diagram. You can do visually any scenario there, which clears things up.

[@amansingh_797]

any analysis on sftp..ftp tftp ..etc

[@luckymontero3549]

Hi Chris. thank you for this channel it really help me in my every day work. Just wondering if you can help. When I tried to upload a file in website I'm getting error. Where do I start looking in wireshark? thank you in advance.

[@ChrisGreer]

Lots of ways you could go with that. Start with filtering on the conversations between client and server, then add in the protocol in use (is it HTTPS? SMB?) Then at the time the error flags look for resets, application hangs, or tcp delays. That is where I would start, but it is hard to say without more detail into the issue.

[@luckymontero3549]

@@ChrisGreer cool.. thanks for giving direction where to start looking. I was able to resolved the issue... Kudos to you!

[@Youtuber-bb5bo]

Can anyone help me I’m trying to play ps4 vanguard and I have to put a port forwarding but the TCP says : 1935, 3478-3480. What to I do with the 1935?? Where do I put that number ??? Please help

[@majiddehbi9186]

Hi Chris can as i m preparing my CCNA it s just in time thx

[@ChrisGreer]

Go get it! You'll pass. Keep up that study and you'll be all good.

[@yunus-gedik]

In the first packet (the first SYN), there is an TCP options, the MSS with a value of 1460 bytes. But each TCP packet has a Window size that is greater than the MSS for example 8192 bytes. I'm telling my link partner I can receive 8192 bytes at once but my MSS is smaller. Can you explain this point please?

[@ChrisGreer]

Hello Yunus - that is a great question. So if you tell me your holding tank is 8192, I can't send you 8192 in one packet because our other buddies along the way will get upset (IP MTU and Link level MTU - usually 1500ish). So I have to cut this baby up into smaller chunks (1460) giving room for the TCP and IP headers before we bump our heads on the MTU. So 8192 will turn into five 1460 byte segments, with a last one of 892 (which will probably have the PSH bit set). It's almost like - let's go get a pizza Yunus. I can eat four slices (all my stomach can handle - 8192) but please put only one on my plate at a time because the plates are so small! Hope that helps.

[@socat9311]

Given your knowledge of packets and protocols, do you ever play with tools like scapy to test things? I think learning to craft packets it's awesome way to learn, so if you ever upload something like that I will double-like it haha

[@ChrisGreer]

Hey! I haven't used it yet but it is on my punch list since I'm digging much deeper into cybersecurity these days.

[@socat9311]

@@ChrisGreer awesome. love your content mate, I love cybersec and wireshark is a total must for it. Thanks for all the time you invest in this content.

[@LilleFjert]

Beeing 4 byte (32 bit) the max sequence number would be 4,294,967,295. Does it simply wrap around?

[@ChrisGreer]

Hello Eirik, yes that is correct. Sequence number wrapping is what it is called. This is where the timestamps option can come in. If we are moving a ton of data, TCP can use the timestamp to prevent confusion about "which" sequence number it sees in the case of wrapping - a past one or a current one.

[@supergocho]

One question: Where is the ACK for packet 9. I see the ACK for packet 10 but no for packet 9

[@ashika2884]

Sir! Can I use hamming code in wireshark for detecting errors ?

[@ChrisGreer]

I never have. TCP wouldn't but perhaps at the file level?

[@ashika2884]

@@ChrisGreer Good day Sir! Thanks for replying sir, Means a lot! Yes sir at the file level only, like if any bits changes means how to detect that using hamming code sir ? Actually I am doing project in *tracer & packet capturing using wireshark* when I searching for wireshark videos, I saw yours ( which contains what I need), but I didn't find the solution for my project on how to use hamming in wireshark sir! So I thought to ask you sir!

[@kanakashriyakrishnamoorthy8821]

I was running wireshark on my Wifi and I observed that for the same source and destination it was sometimes using TCP and sometimes QUIC which is UDP based ? How is it possible ?

[@ChrisGreer]

Right now since we are in an adoption process with QUIC, most sites support both. So you may see a TCP connection and a QUIC connection until the site goes all QUIC from the get-go. Even then, we'll probably still see TCP hanging around for some time over the web!

[@navsam7594]

Hey Chris, I know you are the only one who can help me. I am running an iperf between two sites and the link is 1G. When I run with linux I get 1G either way. As soon as I install windows on it, I get 150Mbps. Not sure why am I experiencing this behavior, can share the PCAPs as well.

[@ChrisGreer]

Hey - I saw your pcaps you sent over. You need to manually increase the window size on the iPerf test. It is only going to use 264KB as a congestion window by default. Use the -w switch and I would crank it up to 2,000,000 (2MB) in your case due to the latency.

[@navsam7594]

@Chris Greer I tried and it end up in an error message "socket buffer is not set correctly".

[@mahavirsinghrajpurohit8004]

Video 2

[@muttabonda3602]

Please upload tutorial for SSL handshake, i almost tried all the websites but no one explained clearly.

[@ChrisGreer]

Great idea, I am actually working on a TLS Handshake video!

[@muttabonda3602]

@@ChrisGreer I'm Waiting... :)

[@Themrhamoud]

You look like an American actor who did venom 2

[@ChrisGreer]

Thanks! I think?

[@usf4886]

2:18 every byte has a sequence number??????

[@ChrisGreer]

Yup. RFC793 3.3 -A fundamental notion in the design is that every octet of data sent over a TCP connection has a sequence number.

[@zsahe21]

!!!!!!

[@flinfaraday1821]

I wonder if TikTokkers appreciates what happens when they send out their trash over the internet :D