How TCP Works - Duplicate Acknowledgments

This video will dig into how to read and interpret duplicate acknowledgments in Wireshark. These are common to see in our trace files, especially when troubleshooting TCP/IP, so let's understand what they mean and why sometimes we see hundreds of them.
Download the pcap: www.cloudshark.org/captures/9...
Like/Share/Subscribe for more Wireshark content!
== More 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...

[@ToddMagers]

Great video Chris!! SACK and dup acks can be hard to explain but you have done a tremendous job!

[@ChrisGreer]

thanks Todd! Agreed, it's hard to condense it down to a few minutes.

[@xzwei]

Viewed twice, it helped me to understand the DupAcks clearly.

[@purvivakani9408]

I had knowledge of TCP Header. and now have been starting learn tcp by your each videos. Nice explanations. Thank you.

[@ChrisGreer]

Thank you for the comment Purvi! I will keep them coming.

[@anshul161987]

So finally I have seen very crisp and clear understanding of SACK and DUP-ACK... well done and great job Chris. You have just earned a true subscriber, who will for sure watch all your videos.

[@ChrisGreer]

Thanks for the comment Anshul! Great to have you on the channel.

[@CharlesRMani]

Ma man am so thankful for yu.. these lessons make me grow better as a fresher nd ur a master in wireshark..u the best 💛.god bless yu and ur family✝️.we would love u being active more on youtube and posting videos now and then.

[@ChrisGreer]

Thanks Charles for the comment! I'll keep working at posting more often. I appreciate the feedback and it definitely motivates me to keep on going.

[@ericwf1]

This answers some questions I had on a case at work. Great video Chris, thank you!

[@ChrisGreer]

Thanks for watching!

[@moelmakrani7116]

Hi Chris, your videos are just a pleasure to watch and listen. Great job man!

[@ChrisGreer]

Glad you like them!

[@vipulv07]

"Hundreds of Dup Acks" - I asked this question in last the streaming with Kary😀 although that explanation helped too, this video is well elaborated and really helpful for someone worried about it. Amazing work Chris!

[@ChrisGreer]

Glad it was helpful! Thank you!

[@shaishankar8499]

I just watched only once and i'm very clear... Kudos sir!

[@ChrisGreer]

Thank you!

[@rameshnaidum]

Thank you Chris. Clarity dawning

[@ranjanadissanayaka5390]

amazing video...I always wondered what those packets highlighted in black. Thanks Chris.

[@billstegman9785]

clear and concise explanation, thank you

[@ChrisGreer]

Thanks for the comment Bill, glad it helped.

[@jhc4090]

Super helpful! thanks for putting out this content.

[@rakeshkhannam1668]

Thanks Chris !!! Really Great Stuff. Learning more from your videos.

[@ChrisGreer]

Thanks for the comment Rakesh! I appreciate the positive vibes.

[@ashishvishwakarma815]

@Chris Greer, thanks for this amazing videos. your explanation is really nice.

[@ChrisGreer]

Thanks Ashish! I appreciate the comment.

[@llJoDall]

Thx for this video! You explained it really well.

[@ChrisGreer]

Thanks for the comment - I'll keep it up. 👍

[@sapnachaudhary9418]

Hey Chris, I really like all your videos, all are very informative. I just want to request you to make some more videos on QUIC about how QUIC different from TCP through Wireshark traces where we can understand how QUIC solves the retransmission ambiguity of TCP. Also what if I want to plot a Steven graph for QUIC just like we can have in TCP.

[@dgharge]

Great Explanation , Thank you.

[@ChrisGreer]

Thanks for watching!

[@cooki3cutt3r13]

awesome video, great info.

[@badriyadav6056]

you are awesome, thankyou so much for this insightfull information. Looking forward to more and more videos:)

[@ChrisGreer]

Thanks for the comment! More to come...

[@marimuthumanoj7206]

thanks buddy for help me to step up into network, for still keep it up (thumbs up)

[@ChrisGreer]

Glad I could help. Thanks for the comment.

[@NorwayRaj]

Grate video bro. Much appreciated

[@ChrisGreer]

You are welcome Raja

[@hemant_pande]

You are awesome Chris ❤️

[@ChrisGreer]

Thanks Hemant for the comment!

[@sumitjha7841]

East or West, Chris is the best.

[@nidalfikri3445]

Great video Chris!

[@ChrisGreer]

thanks! Always appreciate a kind comment.

[@baazshabaz]

Well explained...

[@MahananGogoi]

Awesome Chris..Thanks a lot

[@ChrisGreer]

You bet @Maha. Glad that the video helped you. Thanks for stopping by and commenting.

[@nehalkapse1761]

Great video

[@emirh.9376]

Another great video, keep em coming! I have learned a lot from you and Kerry over at Packet Bomb.

[@ChrisGreer]

Thanks for the comment Emir - I will!

[@aashishkgoyal7600]

Great video Chris. Awesome explanation. Few things that I would still like to understand... 1. Would server send that segment again once those 4 DUP ACKs are received? 2. How is the ACK determined? Meaning, whether to ACK every 2, 4, 6, etc packets... How is that determined? And how long does server wait for ACK from client? Let's say ACK is lost in transit, then how things would work?

[@ChrisGreer]

Hello Aashish, thanks for stopping by the channel. 1. Yes, if the server supports fast retransmission, which most stacks do these days. 2. The ACK interval is determined by the stack settings. How long does the server wait for an ACK? That depends on a value that is set when a packet is transmitted called the retransmission timer. If the server hears nothing from the receiver by the time the timer expires, then it will retransmit the packet. This value is typically set by the stack once it sorts out the network roundtrip time. If an ACK is lost in transit on the way back to the server, then we would have to wait for the timer to expire and resend the packet. Hope these answers help!

[@luissantiago7294]

Excelente!

[@nimaforoughi3008]

Amazing!!!

[@PraveenRai]

@chris is it possible to share your wireshark profiles also to try

[@mcgirishnetwork]

Very helpful..

[@tolgayucel1442]

Hi Chris, Thanks for your efforts. My question is what if there is antother packet loss while client send dup ack, how would be situation?

[@thuglife896]

Excellent 😊

[@ChrisGreer]

Thank you! Cheers!

[@punggukbulan8674]

Hi Chris, this is great video explanation. Maybe you need to add more clear illustration and picture from minutes 01:00 until 03:--. for example use separate and more line for data and ACK as illustration, so it will be easier to study for new people in TCP by giving more picture illustration. Sometimes brain of new people will be more understand if they see more clear illustration. Overall, good work and very helpful for us as beginner. I LIKE IT...

[@ChrisGreer]

Thanks for the suggestion! I'll try it on the next video.

[@mautezsyria8480]

Thanks , really Great video Chris What if two ends don't support SACK, now will duplicate each packet till retransmission happens?

[@ChrisGreer]

Not sure on the exact question, but If the endpoints do not support SACK, retransmissions will occur after loss but the receiver will not be able to indicate successful reception of packets after the lost packet. So a sender will have to retransmit data that was already successfully received.

[@lancelandrum6541]

Hey Chris, Thank you for these videos. I have a question about the 'options' tab in the packet details pane in wireshark. I am able to expand options for the syn and syn,ack packets but after that wireshark doesn't give me 'options' in the packet details pane for the remainder of the stream. I am wondering if it has something to do with the version of wireshark I am using. Have you seen this before? Thank you.

[@ChrisGreer]

Hello Lance - that is how TCP works. The options field is actually "optional"! Depending if options are in use for a given segment of data. You almost always see it in the SYN - SYN/ACK packets, since these advertise the options that each endpoint can support. After those two packets, you only will see the options field when the options are in use - for example, when a SACK block is present or maybe a TCP timestamp. You can usually find one of those if you search for a Duplicate ACK, then look for the optional SACK block in the options. You will only see this option however if both sides can support SACK. Hope this helps.

[@RoboBeaver6]

Is the "TCP Analysis" profile available for download?

[@en4ble773]

@Chris Greer Great video thank you. QQ how do you add these additional columns of yours? I.e sequence number etc..? Thank you in advance.

[@ChrisGreer]

Hello Bart, just find the field that you want to add as a column, right click it, and click Add as Column. It will add a column up in the summary view.

[@en4ble773]

@@ChrisGreer Awesome thank you. I appreciate you time explaining.

[@AzherQadirshah]

Amazing! comment from palo alto guy

[@ChrisGreer]

Thank you!!

[@jcarlosrivera4157]

Great video, Chris quick question is this related to jitter too?

[@ChrisGreer]

Hey @jCarlos Rivera usually when we are talking about jitter, we are referring to what happens during an RTP or SRTP stream, which is UDP based. That is the variation of inter-packet delta time, causing packets to arrive at varying intervals. UDP doesn't have the idea of connections and sequence numbers, so it has no acks like TCP does.

[@jcarlosrivera4157]

@@ChrisGreer thank you very much, make sense, taking a note from this tip.

[@mautezsyria8480]

Thanks , Chris The LAst one , we see here many Dup ack before retransmission , but there is a rule that after 3 dup ack a fast retransmission will happen , so when this rule will be apply

[@ChrisGreer]

If both sides support fast retransmissions, yes, that will be triggered by 3 duplicate acks. Basically the higher the latency between two endpoints, the more duplicate acks you will see in data transfers. You can have hundreds of duplicate acks for only one lost packet in a stream of data. The duplicate acks will continue until the retransmission is sent and received by the target station.

[@williamalmeida5883]

Great video. How I create wireshark visual like yours ?

[@ChrisGreer]

Have you seen my latest video on setting up Wireshark? Go check it out!

[@vijay85cisco]

thank u..

[@ChrisGreer]

Thanks for the comment!

[@ThePumbaadk]

Thanks very good

[@ChrisGreer]

Thanks! I appreciate the feedback.

[@ThePumbaadk]

Hope you make more video like this :)

[@lalatkoshy3418]

Can you please do some video on snmp?

[@samitpiku]

can you make video on TCP ut of order packets

[@dominiquerossignol2212]

Hi Chris, thank you for your video. In your example there is only one SEQ missing, so DupACK is used with ACK=last SEQ received before the loss for ACKing every segment after the loss And option SACK in the TCP header is used to know what is ACKed after the loss But can TCP manage DupACKs and option SACK in the same way, if new loss of segments happen when older lost segments are not yet be retransmitted Can TCP manage multiple missed range of SEQ when ACKing regular other SEQ ?

[@ChrisGreer]

Yes, TCP can handle multiple SACK blocks. I've seen up to four, but most stacks can support up to three these days. It's not a big deal.

[@dominiquerossignol2212]

@@ChrisGreer thanks Chris for your reply but how TCP handle this case ? does sender continue to send DupACK with the SEQ value of the first lost segment ? Doing so, in TCP header option SACK, there will be now a hole between the left edge and the right edge corresponding to the loss of others segments. Could you clarify ? Best regards

[@titipene]

Hi Chris, what happen if there is no SACK enable on client/server?

[@ChrisGreer]

Hello Mauricio - if SACK is not enabled, then the endpoints cannot use the option and will only be able to acknowledge complete sequences of data with no loss. So if you sent out sequence numbers for packets 1, 2, 3, 4, 5... 100 and packet 2 was lost, but all others were received, the receiver would only be able to ack the sequence numbers in packet 1, even if packets 3-100 were successfully received. The sender would have to retransmit the data in packets 2-100 and hope for no gaps on receipt. (I'm using packet numbers rather than sequence numbers to keep this description simple). So SACK makes things MUCH more efficient!

[@gratengraten3716]

I can't thank you enough my teacher if you don't mind can you make a video about the certs.

[@ChrisGreer]

Hello Graten, thanks for the comment! Can you be more specific? Do you mean a video about industry certifications? Or something else?

[@gratengraten3716]

@@ChrisGreer what I meant teacher is the certifications of wireshark it will be great if you make a playlist for it

[@gratengraten3716]

Sorry I forgot to add another question is the certificate of wireshark has a good value and if I take it can I find a good job. Thank you in advance ☺️

[@ChrisGreer]

@@gratengraten3716 Oh gotcha. I think that the Wireshark Certification is a nice way to cover the core skills most people need with the analyzer. As far as getting a good job with just that cert - you probably would need some of the other industry certs as well, but it definitely can't hurt. It would just depend on how much packet focus the role would have and if the employer really understands what Wireshark is. Hope that helps.

[@gratengraten3716]

@@ChrisGreer I do really appreciate what you said hopefully you'll make a playlist for this aim.

[@naveenjkumar9684]

Hi Chris sir, can you kindly explain asymmetric issue traffic how to isolate in wireshark with any capture pls

[@ChrisGreer]

Hello Naveenj, I would be happy to help, but I would need a bit more detail. There are lots of things that can go into asymmetric traffic problems. If you want, you can send your capture to packetpioneer (at) gmail.com and I'll take a peek for you.

[@naveenjkumar9684]

@@ChrisGreer thanks Chris for reply to question ,sorry I dont have any capture with me right now . But would like to troubleshoot isolate any asymmetric routing issue ,like how traffic will look like in capture from sender ,receiver,intermediate devices. Can't we isolate/find asymmetric routing issue by checking at sender end packet capture only or we need to capture sender/receiver/intermediate device also.

[@ChrisGreer]

@@naveenjkumar9684 Ok I see the question. I always have the goal of as many capture points as possible. Otherwise it is easy to make assumptions about how the network paths and shapes the traffic. So at a minimum capture on both ends, then if possible, an intermediate device. Then we can follow packet streams as they flow and have a better idea of how they are being sent.

[@niz11]

Hi Chris...i'm getting a problem that is really baffling for me and i wonder if you can shed some lights. My client is sending TCP SYN to the server to initate a TCP connection, but the SYN-ACK received from the server contains a different acknowledgement number than what is went by client in the SYN packet. This then caused client to send RST. Why can something like this happen?

[@ChrisGreer]

Hey John Doe - interesting behavior for sure. Hmmm... is there a chance there was already a connection on that port from the server perspective? I'd also take a look at the server side TCP stack just to see if there are any updates needed/patches. I wonder if that socket was in a close-wait state or something like that from a previous connection? I would need more data to be sure but those are the things I would check.

So a DUP ACK is when the ack number and windows size stays the same, and we do see that in the capture. But if the receive window does not grow/shrink, how does the server know how much it can send to the client ? Isn't that window size supposed to change since the client is receiving more data, even during the dup ack transmissions ?

[@ChrisGreer]

Hello Mathieu, thanks for the comment and question. On the receiver side, if it is keeping up with the ingress data then the window will not fill, so the window size will either stay the same or grow, depending on the system. So with each ACK, the receiver informs the sender how much window size it has to work with, so the server will have constant feedback about how much data it can have outstanding on the wire unacknowledged. Hope this helps!

@@ChrisGreer thanks for the answer ! And awesome videos by the way !

[@ChrisGreer]

@ Sure thing!

[@joeyp978]

Why would you maybe see one ack, but most of the time two? Seems like it’s important to know when trying to understand fundamentally how tcp works. Really wish I could find someone explaining tcp for smooth brains like me. Unluck

[@joeyp978]

Nevermind. You addressed it later in the video. Still think you should have addressed it when the situation originally arose 😅

[@tebes9265]

How come in packet no. 57 the server 10.0.0.1 didn't update its ack number to 1272 despite having the ack flag set? When you study the pcap-file you can see that the client 192.168.0.1 already had the squence number 1272 in packet no. 32. I'm a bit confused.

[@ChrisGreer]

Greetings Te Bes. Thanks for asking the questions! So the server doesn't update its ack number because there was no new data sent in that direction to acknowledge. If you look at packets 55 and 56, they have no payload - so no new data to ack. The reason this packet has an ack flag is because there is a legit ack number. Every packet after the SYN has the ack flag set in most TCP connections, except in some resets. So the server has not seen any new data from the client since packet 27 - that is why it keeps repeating the ACK number, no new data. I hope that helps understand it better.

[@tebes9265]

@@ChrisGreer Hi Chris, thank you very much for answering my question! In packet 27 the client has a (relative) sequence number of 1241 and sends 31 bytes of data to the server which leads to a sequence number of 1272 in the following packets by the client. My guess is that the server doesn't update its ack number until packet 58 because of the RTT. Is that right? I didn't consider that being a factor in my initial question. When almost every packet after SYN has the ack flag set, how can the receiver tell that those are not duplicate acks? That means that one packet can get ack'ed again and again and suddenly another packet that the sender gets multiple acks for is a duplicate ack? Does it take RTT into consideration? And why does Wireshark only show [ACK] in some Info texts when the ACK flag is always set? Now I'm even more confused. :D I'd really appreciate it if you could clear this up :)

[@ChrisGreer]

@@tebes9265 Good questions. Here is the criteria for Wireshark to mark a packet as a duplicate ack in a packet trace: ------ The segment size is zero. The window size is non-zero and hasn’t changed. The next expected sequence number and last-seen acknowledgment number are non-zero (i.e. the connection has been established). SYN, FIN, and RST are not set. ------- So in this trace, in packets that have a payload, a duplicated ACK number just means no more data has been received in the opposite direction. No data was in flight. You are correct, packet 58 is ACKing the data in packet 27, this takes about 26mSec, which is close to the initial network roundtrip time. So yes, the RTT was in play. In the info column, Wireshark shows data that is most helpful in troubleshooting. For packets where the ACK number isn't really a factor in helping for analysis, it isn't shown in the Info column. Hope these answers help!

[@tebes9265]

@@ChrisGreer Wow, thank you so much for taking the time answering my questions! I really appreciate what you do with your channel. You've resolved all of my questions! :)

[@ChrisGreer]

@@tebes9265 Of course no problem. Thanks for the comments and for watching the channel Te.

[@andreostrufka69]

What happens when the client detects a missing pkt, start to receive the other pkts and send ACKs with incrementing SACK, but before I receive the first missing pkt, another pkt is missing? For example: CLIENT

[@ChrisGreer]

Hello Andre - The client just starts to indicate another SACK block in the TCP options. Most TCP stacks can support between 2-4 unique SACK blocks. So this would indicate that there is a gap between the ack number in the TCP header and the left edge of the first block, then another gap between the right edge of the first block and the left edge of the second block.

[@andreostrufka69]

@@ChrisGreer Understood. Thanks! Your videos are very good, congrats!

[@maulikkharecha8060]

I have one different question which is not relevant to this video. How can we decrypt the HTTPS/TLS traffic in the Wireshark tool?

[@ChrisGreer]

Great question - one that is asked quite a bit. I am working on doing a TLS series as well for the channel. I will definitely cover that topic as we get there. Thanks for the comment!

[@martinencizo6513]

Please traduction in spanish

[@user-sc2gg7dn3d]

More

[@hariprasad-uw2yn]

Dear Chris, could you help me to analyze the PCAP collected for replication slowness between HQ to DR for one of our customer. Please share your email.

[@ChrisGreer]

hello - sure I could take a peek. [e-mail]

[@hariprasad-uw2yn]

@@ChrisGreer Thank you so much. I will send you very soon.