Wireshark · Wireshark-users: Re: [Wireshark-users] Interpretation of "summary" TCP/IP packets?

["Templin (US), Fred L" <Fred.L.Templin@xxxxxxxxxx>]

Hi Guy,

> -----Original Message-----
> From: Wireshark-users [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Guy Harris
> Sent: Tuesday, July 03, 2018 12:59 PM
> To: Community support list for Wireshark <wireshark-users@xxxxxxxxxxxxx>
> Subject: Re: [Wireshark-users] Interpretation of "summary" TCP/IP packets?
> 
> 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.

Yes, this would tend to explain it. So, from the end system's perspective, the
end system thinks it is sending a 20K+ TCP/IP packet out the network interface,
and the network interface does the TCP segmentation offloading. That explains
why the packet filter is only seeing the "summary" packet.

> > 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.

My "router" R is another linux node connected to the same Ethernet switch as nodes
A and B, and I set up static routes on A and B to treat R as a "router on a stick". So,
any manner of weird stuff is possible.

In any event, I think I have my answer. Thanks!

Fred
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
> Archives:    https://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
>              mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe