Ask Wireshark - RSS feedhttps://ask.wireshark.org/questions/Wireshark questions and answersenCopyright Wireshark Foundation, 2017-2019Tue, 06 Mar 2018 09:15:32 +0000More than 2 full TCP packets without ACK and large MTUhttps://ask.wireshark.org/question/1945/more-than-2-full-tcp-packets-without-ack-and-large-mtu/Hi,
Please refer to the attached [pcapng file](https://drive.google.com/open?id=133ZW0-2vYyG6Hhu0yVq5MqdgfpTvQoEH). It's an excerpt of a 1 GB PCAPNG.
It captures part of transfer of a 1GB FTP (port 21) transfer. I got two questions:
Q1) Packet # 16 through 22 were transferred without any acknowledgement. Each of those packets was more than TCP full size (1460). How is that possible?
Q2) Frame size of each of the above packets is more than the MTU size (1500). How is it possible?
Regards.Tue, 06 Mar 2018 04:51:39 +0000https://ask.wireshark.org/question/1945/more-than-2-full-tcp-packets-without-ack-and-large-mtu/Comment by Vindra for <p>Hi,
Please refer to the attached <a href="https://drive.google.com/open?id=133ZW0-2vYyG6Hhu0yVq5MqdgfpTvQoEH">pcapng file</a>. It's an excerpt of a 1 GB PCAPNG.</p>
<p>It captures part of transfer of a 1GB FTP (port 21) transfer. I got two questions:</p>
<p>Q1) Packet # 16 through 22 were transferred without any acknowledgement. Each of those packets was more than TCP full size (1460). How is that possible?</p>
<p>Q2) Frame size of each of the above packets is more than the MTU size (1500). How is it possible?</p>
<p>Regards.</p>
https://ask.wireshark.org/question/1945/more-than-2-full-tcp-packets-without-ack-and-large-mtu/?comment=1947#post-id-1947THANKS Jim, I just now reduced the file size following your adviceTue, 06 Mar 2018 06:05:23 +0000https://ask.wireshark.org/question/1945/more-than-2-full-tcp-packets-without-ack-and-large-mtu/?comment=1947#post-id-1947Comment by Jim Aragon for <p>Hi,
Please refer to the attached <a href="https://drive.google.com/open?id=133ZW0-2vYyG6Hhu0yVq5MqdgfpTvQoEH">pcapng file</a>. It's an excerpt of a 1 GB PCAPNG.</p>
<p>It captures part of transfer of a 1GB FTP (port 21) transfer. I got two questions:</p>
<p>Q1) Packet # 16 through 22 were transferred without any acknowledgement. Each of those packets was more than TCP full size (1460). How is that possible?</p>
<p>Q2) Frame size of each of the above packets is more than the MTU size (1500). How is it possible?</p>
<p>Regards.</p>
https://ask.wireshark.org/question/1945/more-than-2-full-tcp-packets-without-ack-and-large-mtu/?comment=1946#post-id-1946It's not reasonable to expect people to download a 1.3 GB file and try to load it into Wireshark in order to tell you what's happening with seven packets. Cut the capture file down to a more reasonable size. To save packets 700 to 900, for example, you could enter a display filter of "frame.number > 699 && frame.number < 901". You can then go to File > Export Specified Packets to save off only the displayed packets.Tue, 06 Mar 2018 05:53:42 +0000https://ask.wireshark.org/question/1945/more-than-2-full-tcp-packets-without-ack-and-large-mtu/?comment=1946#post-id-1946Answer by Packet_vlad for <p>Hi,
Please refer to the attached <a href="https://drive.google.com/open?id=133ZW0-2vYyG6Hhu0yVq5MqdgfpTvQoEH">pcapng file</a>. It's an excerpt of a 1 GB PCAPNG.</p>
<p>It captures part of transfer of a 1GB FTP (port 21) transfer. I got two questions:</p>
<p>Q1) Packet # 16 through 22 were transferred without any acknowledgement. Each of those packets was more than TCP full size (1460). How is that possible?</p>
<p>Q2) Frame size of each of the above packets is more than the MTU size (1500). How is it possible?</p>
<p>Regards.</p>
https://ask.wireshark.org/question/1945/more-than-2-full-tcp-packets-without-ack-and-large-mtu/?answer=1950#post-id-1950Always consider the point you're capturing on. You trace has strong signs of being captured on the sender itself.
Therefore:
Q1) As you're on the server itself, you just don't see ACKs because they had not come to you at the moment and still are somewhere on the path. It seems the sender has congestion window big enough to transmit packets 16...22 without waiting for an ACK.
Q2) This is because of "TCP segmentation offload". Please watch Paul Offord's cool video to grasp the concept:
https://www.youtube.com/watch?v=anEZGfF4P10
or take a look on wikipedia article [Large Send Offload](https://en.wikipedia.org/wiki/Large_send_offload).Tue, 06 Mar 2018 08:08:50 +0000https://ask.wireshark.org/question/1945/more-than-2-full-tcp-packets-without-ack-and-large-mtu/?answer=1950#post-id-1950Comment by Anders for <p>Always consider the point you're capturing on. You trace has strong signs of being captured on the sender itself.</p>
<p>Therefore:</p>
<p>Q1) As you're on the server itself, you just don't see ACKs because they had not come to you at the moment and still are somewhere on the path. It seems the sender has congestion window big enough to transmit packets 16...22 without waiting for an ACK.</p>
<p>Q2) This is because of "TCP segmentation offload". Please watch Paul Offord's cool video to grasp the concept:</p>
<p><a href="https://www.youtube.com/watch?v=anEZGfF4P10">https://www.youtube.com/watch?v=anEZG...</a></p>
<p>or take a look on wikipedia article <a href="https://en.wikipedia.org/wiki/Large_send_offload">Large Send Offload</a>.</p>
https://ask.wireshark.org/question/1945/more-than-2-full-tcp-packets-without-ack-and-large-mtu/?comment=1951#post-id-1951This [link](http://blog.securityonion.net/2011/10/when-is-full-packet-capture-not-full.html) is quite useful too.Tue, 06 Mar 2018 09:15:32 +0000https://ask.wireshark.org/question/1945/more-than-2-full-tcp-packets-without-ack-and-large-mtu/?comment=1951#post-id-1951