Re: Interpretation of "summary" TCP/IP packets?

[Guy Harris <guy () alum mit edu>]

On Jul 3, 2018, at 12:42 PM, Templin (US), Fred L <Fred.L.Templin () boeing com> 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.
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe