This is very useful for me. I am an F5 engineer from China. I often need to look at data packets. Your video is simple and easy to understand. I love it!😘
You're killing it on these tutorials. Thank you very much! What is the chance you could include a link to the trace files in the description? This way we could "follow along" in our own wireshark?
Sure! Here is the link to the trace in Cloudshark - www.cloudshark.org/captures/4e8ed77deb52 For my newer videos I am doing more of this, but I haven't done it yet for the older ones.
Hello! Have you checked out my video on FINs vs Resets? th-cam.com/video/-vgk9P-6dPY/w-d-xo.html That one goes into the four-way termination and reset behavior. Hope that helps.
Point of capture is important. If you are capturing from the perspective of the sender, you will see 3 duplicate acks followed by the retransmission. If you are capturing at the receiver, you may see many duplicate acks, since you are not aware of the retransmission yet.
Hello Sivasakthi! If you have not had a chance to yet - you can check out my Wireshark courses on Pluralsight - www.bit.ly/wiresharktshoot www.bit.ly/wiresharktcp I cover a ton of ground about Wireshark and TCP in these two courses. Check them out!
Great video as usual! One thing that confuses me is the Seq (1-201, 301-501) shown in the diagram. Since each packet is 100 Bytes I was expecting to see 1-200 (1-100 for packet #1 and 101-200 for packet #2). Respectively, I would expect to see 301-500 for the second sequence.
I understand the concept of SACK_PERM, but I'm a little confused: To me it seems as though SACK_PERM = 0 implies that the TCP connection will be using the Go-Back-N protocol, whereas with SACK_PERM = 1 the TCP connection will be using the Selective Repeat protocol. I can't seem to find any information on this elsewhere so I'd love to know if I'm mistaken or not.
While filling in the missing sequences, what happens if one of those packets are received out of order? Can there be multiple left/right edges to indicate that there are two sections missing?
Hi Cris! I have a question about SACK: In 5:13 the TCP DUP ACK has: ACK 46721 SACK 59861-61321 (the package below will increase only the right edge) In 5:37 the package has SEQ 61321 Next Seq 62781 What would happen if the package above had a SEQ = 62700 instead of 61321? In this case the next DUP ACK would have 2 SACKS to indicate: 59861-61321 and 62700-62781 (gap between 46721 and 59861, and another gap between 61321 and 62700). Is that right?
Yes, that is correct. If there was another gap in the sequence, the next ACK would indicate this by starting up another SACK block like you indicated. So the sender would need to fill in the space between 46721 and 59861, as well as 61321 and 62700. Nice work!
if the SACK feature is NOT supported ( which will be discovered in the TCP 3 way hand shake ) will the TCP transaction proceed . let say client is sending with SACK suppport or server is sending SYN-ACK with SACK suppport ( but client doesnt support) . jusy wanted to know the TCP-transaction will still proceed . or in the TCP- 3 way hand shake RST will happen ??? can you please shed more light on this . and also microburst scenarios which will lead to TCP packet Drops 2 or 3 TCP packets getting dropped .
Hi Chris, is it possible to have multiple "holes" on the TCP stream, i.e. missing multiple packets that are not contiguous. How can SACK left edge and right edge work in that case.
Hello! Great question. The answer is yes. I cover that in my SACK video, here is the link to it. th-cam.com/video/VERgI8QaYPY/w-d-xo.html In short, most TCP stacks can handle up to four "blocks" of data, with holes between each block. This informs the data sender about the missing sequence numbers so these can be retransmitted. This is also a topic I cover in detail in my Foundational TCP Analysis course on Pluralsight - bit.ly/wiresharktcp
Hi, thank u so much for this video! I have a short Q: at minute 4:27 u show that packet 54 is accepting the next seq is supposed to be 59861, why? In packet 52 seq = 45261, len =1460, in packet 53 seq = 325, len = 0, how did it jumped to 59861?
I learned at a SANS conferences (Ed Skoudis) that if we send sequence numbers 1-99, we'd get an ACK of 100, acknowledging all before 100. Any dropped packets would be cleaned up by selective acknowledgements, if any. You say you ack 1-201 with a 201 ACK? Someone is incorrect.
One i want to ask is, what is mean ACK, did it like d-dos attack like somebody trying sending malware but the main purpose is to make the connection slower, even some case it cause hacked and error to machine. Cause in my case is so much like that, imagine i am online just 4 minutes but packages which i am received are 17,000 and 40% are ACK then the detail i got is not website but like devices. Noted i am using wifi in here.
Hi Chris, Is there a specific reason why when a packet goes missing that client then sends an acknowledgment for each packet it receives with the left & right edge values in the SACK option? Normally the client will acknowledge any two packets or two full-size packets.
Hello Goblin, to boil it down to a simple statement - it gives the sender more feedback about what went missing and can trigger a fast retransmission quicker. Now the details - RFC 2581 mentions that after a point of loss or reordering a receiver will dup ack every segment until the gap is filled. As these fly back to the sender, three duplicate ACKs will trigger a fast retransmission, rather than waiting for the full retransmission timer to expire. So if we only "acked" every other packet, even when there was loss, this process would take longer to get the info back to the sender about the missing segment. This feedback also helps the sender to adjust its congestion window according to how much and how often data was lost. So as much info about the loss as quickly as possible will help TCP keep that congestion window high. I hope that helps.
@Chris Greer, thank you for your reply. Also, I appreciate you and others putting up videos to help educate people like us who are interested in learning about networking and packets analysis. Your videos have helped me with some of my own Ah-ha moments (even if I am learning it for fun).
Hello Anirudha - have you checked out my video on the TCP Trace graph? th-cam.com/video/yUmACeSmT7o/w-d-xo.html That one goes into throughput a bit. But I plan to make a focused throughput video soon. Thanks!
What happens when more than one gap in the data stream appears? The TCP ACK seems to point to the first expected segment at the start of the gap, while the SACK's keep track of the running data. What happens if another gap appears?
Hey, great question! SACK can handle that. It just starts another SACK block. You will see a second one appearing in the TCP options that shows what has been successfully received. It is up to the sender to resend the gaps between the blocks. Some stacks can support up to four blocks, while some only support two or three.
@@ChrisGreer Wow, that's funky. Thanks for the answer! This helps me dig deeper into TCP. And thanks for the videos, it's unbelievable that you make this available for free, they are a fantastic resource! Very concise :)
The receiver will only be able to ACK the highest seq number before the point of loss. Any post-loss traffic that was received will not be ACKed without a SACK block. So those will need to be resent even though they were successfully received.
This is very useful for me. I am an F5 engineer from China. I often need to look at data packets. Your video is simple and easy to understand. I love it!😘
Thank you Chris you saved my 12 hours of reading papers.
Happy to hear that it helped! This stuff can be a little dry on paper for sure.
you are the most brilliant person i ever seen in TCP analysis
Your videos are distilling down weeks of independent research. It's awesome, Thanks!
Glad you like them! Thanks for the comment!
I love your videos, no bullshit every line is up to the point and precise. Thank you
You must be an amazing teacher, Chris. This was very clear and easy to understand. Nice job!
Thanks Nadlei! I appreciate the feedback and the comment. See you around the channel.
Crystal clear explanation. Thank you very much.
Chris you are like TCP , giving us trusted and oriented knowledge. Unlike the UDP trainers.
ACK. :-)
best resource for learning tcp protocol
VERY nice to clear the sequence concept. I love your way of explaining.
Thanks for the comment!
Thanks , Your videos are helping me get a better feel for all this
Thanks for the comment - glad to hear the videos are helping.
I really appreciate your videos, you're saving much of my time❤️
You're killing it on these tutorials. Thank you very much! What is the chance you could include a link to the trace files in the description? This way we could "follow along" in our own wireshark?
Sure! Here is the link to the trace in Cloudshark - www.cloudshark.org/captures/4e8ed77deb52
For my newer videos I am doing more of this, but I haven't done it yet for the older ones.
Thanks for sharing Chris, excellent video supported with great visuals and a practical explanation.
Glad it was helpful!
Neat and clear, excellent job! Thanksss
Hey Chris, very informative video....can u make one video on four way handshake or connection termination please.
Hello! Have you checked out my video on FINs vs Resets? th-cam.com/video/-vgk9P-6dPY/w-d-xo.html That one goes into the four-way termination and reset behavior. Hope that helps.
Great explanation!
Make a video on TLS handshake process.
That's a good idea for a video Abhay. Let me work on it.
@@ChrisGreer "just do it "~ Nike :)
@@ChrisGreer Looking forward to it.
perfect , Chris Thank you very much
here we can see many duplicate ACK ( not just 3 ) before fast retransmission,
when this rule will apply :)
Point of capture is important. If you are capturing from the perspective of the sender, you will see 3 duplicate acks followed by the retransmission. If you are capturing at the receiver, you may see many duplicate acks, since you are not aware of the retransmission yet.
@@ChrisGreer many thanks really appreciate
You are doing a great job.Thank you so much
Thank you very much for the comment Subham!
Chris thanks a lot for this session, its awesome always, why cant you create WCNA course,
Hello Sivasakthi! If you have not had a chance to yet - you can check out my Wireshark courses on Pluralsight -
www.bit.ly/wiresharktshoot
www.bit.ly/wiresharktcp
I cover a ton of ground about Wireshark and TCP in these two courses. Check them out!
Excellent explanation.
great job Chris, can i have the Wireshark file , the one which you are using for this video
Nice and concise, thanks. I wonder...what controls how long or how many bytes the SACKer will wait before it gives up?
Excellent as usual.
Thanks for the comment Mohammad!
thanks man!!
this really help
Glad it helped! I have more coming out about sequence number analysis, so stay tuned!
Make a video on DNS in-depth like, different type of records
Great video as usual! One thing that confuses me is the Seq (1-201, 301-501) shown in the diagram. Since each packet is 100 Bytes I was expecting to see 1-200 (1-100 for packet #1 and 101-200 for packet #2). Respectively, I would expect to see 301-500 for the second sequence.
Yeah I feel the same. Seq number should be 1-200 and Ack would be 201.
Yes@@surenderkamboj
I understand the concept of SACK_PERM, but I'm a little confused:
To me it seems as though SACK_PERM = 0 implies that the TCP connection will be using the Go-Back-N protocol, whereas with SACK_PERM = 1 the TCP connection will be using the Selective Repeat protocol.
I can't seem to find any information on this elsewhere so I'd love to know if I'm mistaken or not.
While filling in the missing sequences, what happens if one of those packets are received out of order? Can there be multiple left/right edges to indicate that there are two sections missing?
Why did I find you this late? damn, thank you man.
Glad you found the channel!
thanks again very much, keep doing good work!!!
Thank you Chris!
Great video, subscribed!
Thanks for the sub!
Thank you so much for this video
You are welcome! Thanks for the comment.
Great video Chris!
Amazing videos sir indebted.
post some out of order and gre fragmentation packet analyses and tshoot
Great ideas, thanks!
Hi Cris! I have a question about SACK:
In 5:13 the TCP DUP ACK has:
ACK 46721
SACK 59861-61321 (the package below will increase only the right edge)
In 5:37 the package has
SEQ 61321
Next Seq 62781
What would happen if the package above had a SEQ = 62700 instead of 61321?
In this case the next DUP ACK would have 2 SACKS to indicate: 59861-61321 and 62700-62781 (gap between 46721 and 59861, and another gap between 61321 and 62700).
Is that right?
Yes, that is correct. If there was another gap in the sequence, the next ACK would indicate this by starting up another SACK block like you indicated. So the sender would need to fill in the space between 46721 and 59861, as well as 61321 and 62700. Nice work!
@@ChrisGreer Thank you!
I have a question about congestion control in relation to SACK. If a TCP layer uses SACK and a packet is missing, does TCP then detect congestion?
Thanks for giving me the ammunition to put this wireshark capture back to the customer's network 😁
if the SACK feature is NOT supported ( which will be discovered in the TCP 3 way hand shake ) will the TCP transaction proceed . let say client is sending with SACK suppport or server is sending SYN-ACK with SACK suppport ( but client doesnt support) . jusy wanted to know the TCP-transaction will still proceed . or in the TCP- 3 way hand shake RST will happen ??? can you please shed more light on this . and also microburst scenarios which will lead to TCP packet Drops 2 or 3 TCP packets getting dropped .
Hi Chris, is it possible to have multiple "holes" on the TCP stream, i.e. missing multiple packets that are not contiguous. How can SACK left edge and right edge work in that case.
Hello! Great question. The answer is yes. I cover that in my SACK video, here is the link to it. th-cam.com/video/VERgI8QaYPY/w-d-xo.html
In short, most TCP stacks can handle up to four "blocks" of data, with holes between each block. This informs the data sender about the missing sequence numbers so these can be retransmitted. This is also a topic I cover in detail in my Foundational TCP Analysis course on Pluralsight - bit.ly/wiresharktcp
@@ChrisGreer Thank you Chris. That is very helpful
@@foshan Sure thing. Let me know if you have any other questions or video suggestions.
Excellent! Thanks,
Hi, thank u so much for this video! I have a short Q: at minute 4:27 u show that packet 54 is accepting the next seq is supposed to be 59861, why? In packet 52 seq = 45261, len =1460, in packet 53 seq = 325, len = 0, how did it jumped to 59861?
what's missing in between is 46721 and 59861, that's what the SACK showed to the other side what was missing and what was received, 59861 to 62781.
This is amazing!
Thank you!
if the gap is filled,does the sever resend these packets sequence number after the last gap sequence number?thanks
I learned at a SANS conferences (Ed Skoudis) that if we send sequence numbers 1-99, we'd get an ACK of 100, acknowledging all before 100.
Any dropped packets would be cleaned up by selective acknowledgements, if any.
You say you ack 1-201 with a 201 ACK?
Someone is incorrect.
If I send 0-99 and you ack 100, that is a missing byte and TCP would freak out. So… gotta ACK every byte, no more.
Thanks. It was great. I would be better if you share the pcap file.
What does it mean when it says a max of 4 SACK blocks can be reported in 1 segment?
Is there a link to the pcap that was used?
Great work !!!
Thanks a lot chris
One i want to ask is, what is mean ACK, did it like d-dos attack like somebody trying sending malware but the main purpose is to make the connection slower, even some case it cause hacked and error to machine. Cause in my case is so much like that, imagine i am online just 4 minutes but packages which i am received are 17,000 and 40% are ACK then the detail i got is not website but like devices. Noted i am using wifi in here.
Hi Chris,
Is there a specific reason why when a packet goes missing that client then sends an acknowledgment for each packet it receives with the left & right edge values in the SACK option? Normally the client will acknowledge any two packets or two full-size packets.
Hello Goblin, to boil it down to a simple statement - it gives the sender more feedback about what went missing and can trigger a fast retransmission quicker.
Now the details - RFC 2581 mentions that after a point of loss or reordering a receiver will dup ack every segment until the gap is filled. As these fly back to the sender, three duplicate ACKs will trigger a fast retransmission, rather than waiting for the full retransmission timer to expire. So if we only "acked" every other packet, even when there was loss, this process would take longer to get the info back to the sender about the missing segment. This feedback also helps the sender to adjust its congestion window according to how much and how often data was lost. So as much info about the loss as quickly as possible will help TCP keep that congestion window high.
I hope that helps.
@Chris Greer, thank you for your reply. Also, I appreciate you and others putting up videos to help educate people like us who are interested in learning about networking and packets analysis. Your videos have helped me with some of my own Ah-ha moments (even if I am learning it for fun).
Is there a way I can download this exact trace to follow along?
Thank you very much!
You're welcome!
Namaste Sir, Kindly guide me, how to find TCP data throughput from the pcap file... Thank you
Hello Anirudha - have you checked out my video on the TCP Trace graph? th-cam.com/video/yUmACeSmT7o/w-d-xo.html
That one goes into throughput a bit. But I plan to make a focused throughput video soon. Thanks!
Can You make about Profinet TCP frames and diagnostic. You can have huge amount of viewers :)
thank you sir
What happens when more than one gap in the data stream appears? The TCP ACK seems to point to the first expected segment at the start of the gap, while the SACK's keep track of the running data. What happens if another gap appears?
Hey, great question! SACK can handle that. It just starts another SACK block. You will see a second one appearing in the TCP options that shows what has been successfully received. It is up to the sender to resend the gaps between the blocks. Some stacks can support up to four blocks, while some only support two or three.
@@ChrisGreer Wow, that's funky. Thanks for the answer! This helps me dig deeper into TCP. And thanks for the videos, it's unbelievable that you make this available for free, they are a fantastic resource! Very concise :)
@@ShadyNetworker Thanks for the comment. i will keep them coming!
@@ChrisGreer Following up to that question, what will happen if those SACK blocks have been exhausted?
good one
What happens to lost traffic in the absence of the Selective ACK?
The receiver will only be able to ACK the highest seq number before the point of loss. Any post-loss traffic that was received will not be ACKed without a SACK block. So those will need to be resent even though they were successfully received.
@@ChrisGreer got you, that makes sense. Many thanks.
Hey! this is conceptually a little incorrect. If the client sent bytes 1-201, the ACK number sent by the server would have number 202 !
They are all great , but watching this in the "How Tcp Works" playlist , this one should have been moved up to even above Seq Numbers.
tq
0 dislikes :)
ACK VIDEO
Fantastic
Thank you! Cheers!