Why do I see Ethernet frames that exceed the MTU + Ethernet header size?

I have a consumer-grade Wi-Fi router that hosts a local network. The router is connected to the Internet through a campus network (i.e., an Ethernet cable connects the WAN port to a campus Ethernet plug). I'm running tcpdump on the router's WLAN and WAN interfaces to capture the traffic generated by the devices connected to the router.

What puzzles me is that I see frames which are significantly longer than the limit defined by the MTU plus the layer 2 header size. I first thought that this was to be explained by the campus network's support for Ethernet jumbo frames, but these are (usually) capped at 9,000 bytes MTU, and I see some frames which are almost 13,000 bytes long.

Next I thought that since the devices are connected by Wi-Fi, they are not limited by the Ethernet MTU, but rather the 802.11 MTU, but that one appears to be about 2304 bytes, so a 13KB frame is still too large. Side-note: the frames appear as Ethernet frames in Wireshark, but that is apparently to be explained by 802.11 frames being converted to "fake" Ethernet frames before they are delivered to the OS's networking stack as explained here:

802.11 adapters often transform 802.11 data packets into fake Ethernet packets before supplying them to the host, and, even if they don't, the drivers for the adapters often do so before supplying the packets to the operating system's networking stack and packet capture mechanism.

Some interesting observations that might help you help me shed some light on this:

• For the trace captured at the router's WLAN interface, it is only packets originating from a local device and going to towards an Internet host that exceed the MTU. All inbound packets (Internet host to local device) are of length 1514 or less.
• For the trace captured at the router's WAN interface, it is only inbound traffic (Internet host to router) that exceeds the Ethernet MTU.
• One can indeed "map" the large frame (that exceeds the MTU) captured on one side of the router to several frames that are of MTU size or less on the other side of the router by cross-referencing the two traces.
• This is all TLS traffic (but that should not make any difference as this is a layer 2 limit).

I am guessing that this behavior might be due to TSO/GSO based on this answer. However, it says that one should not see these larger frames if one performs the capture on a network device:

[...] you might see TCP sending out larger segments than the MTU. The packets on the wire , however, will be MTU size only. You can verify this by capturing on a network device (switch) etc.

I do indeed perform the capture on a network device (a router), yet I still see the large frames. However, the router runs LEDE/OpenWrt which I guess makes it sort of an "enhanced ...

edit retag close merge delete

Sort by » oldest newest most voted

I think you're seeing the effect of capturing on a device that is processing the packets. Those packets are not actually seen like this on the wire. See this blog post for more details:

https://blog.packet-foo.com/2014/05/t...

And I think you're misinterpreting the quote from the TSO/GSO answer - the capture must not be performed on any device that is part of the packet generation or forwarding. The article means you should use a SPAN port or TAP to capture with an independent device.

more

Very educating blog post, thanks a ton! Would add +1 if I had karma for it. Will accept if this proves to be the issue. Do you have any blog posts discussing how to set up a capture using SPAN/TAP btw?

( 2018-09-05 22:34:25 +0000 )edit
1

Yes, there's a whole series I wrote about how to capture packets, starting with this one:

https://blog.packet-foo.com/2016/10/t...

But if you're interested in SPAN/TAP, those are the ones covering that:

https://blog.packet-foo.com/2016/11/t...

https://blog.packet-foo.com/2016/12/t...

( 2018-09-05 22:56:37 +0000 )edit