On Jul 3, 2018, at 12:42 PM, Templin (US), Fred L <Fred.L.Templin@xxxxxxxxxx> wrote:
> On a pair of Ubuntu linux laptops (call them A and B) connected via a 1Gbps link, I am
> running “iperf3 –c” on node A and “iperf3 –s” on node B. Also on node B I am running
> wireshark on B’s “eth0” interface to capture the traffic. When I start the wireshark
> capture, and then start the iperf3 test, the capture shows “summary” TCP/IP packets
> instead of the “real” packets.
>
> I call them “summary” packets because their length is much larger than 1500 bytes (the
> MTU of the link connecting A and B).
They're probably the results of TCP segmentation offloading:
https://en.wikipedia.org/wiki/Large_send_offload
wherein a network adapter, or layers of the networking stack below the layer at which packets being sent are copied and passed to the packet capture mechanism used by tcpdump/Wireshark/etc., take TCP segments that are larger than the MTU and divide them into MTU-or-smaller segments, so that the segmentation isn't seen by whatever program is using the capture mechanism, or TCP reassembly offloading:
https://en.wikipedia.org/wiki/Large_receive_offload
wherein a network adapter, or layers of the network stack below the layer at which packets that have been received are copied and passed to the packet capture mechanism, reassemble multiple segments and pass them to the host, or up the networking stack, as larger-than-MTU-sized chunks.
> For example, I see packets with lengths like 20338,
> 29026, etc. When I use wireshark to examine the IP headers of these “summary” packets,
> the IP length field reflects these larger values and shows the packets as non-fragmented
> IP packets, which makes no sense because the largest non-fragmented IP packet possible
> is only 1500 bytes.
The process in question includes providing fake IP headers with a size sufficient to account for the lack of segmentation (on transmitted packets) or to account for reassembly (on received packets).
> When I put a router (call it R) between nodes A and B and run wireshark on R, what I see
> is the “summary” packet followed by N 1500 byte packets that cover the same sequence
> number space as for the summary packet. This begins to make sense to me because the
> smaller packets fit inside the path MTU. But, the “summary” packet sill shows up in the
> wireshark capture.
That sounds like the network adapters, or the networking stack, on the router is doing weird stuff - the routers are just passing those packets through, there's no reason for their hardware or software to be doing reassembly and/or TCP segmentation.
