# Revision history [back]

### 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" network device more on par with an actual host than a network device...?

I attach an example of a frame that exceeds the MTU. Note that this frame was captured on the router's WAN interface (eth0). Is this simply a result of TSO/GSO, or is there something else going on that I am not aware of? Also, does TSO/GSO work in both directions, or does it only apply to outbound packets? If the latter is the case, then TSO/GSO cannot be the explanation since the example packet is inbound from the router's point of view.

### 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" network device more on par with an actual host than a network device...?

I attach an example of a frame that exceeds the MTU. Note that this frame was captured on the router's WAN interface (eth0). Is this simply a result of TSO/GSO, or is there something else going on that I am not aware of? Also, does TSO/GSO work in both directions, or does it only apply to outbound packets? If the latter is the case, then TSO/GSO cannot be the explanation since the example packet is inbound from the router's point of view.

Update: disabling TSO/GSO on the router's WAN and WLAN interfaces did not change anything; the large frames are still present when re-running the experiment.

### 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" network device more on par with an actual host than a network device...?

I attach an example of a frame that exceeds the MTU. Note that this frame was captured on the router's WAN interface (eth0). Is this simply a result of TSO/GSO, or is there something else going on that I am not aware of? Also, does TSO/GSO work in both directions, or does it only apply to outbound packets? If the latter is the case, then TSO/GSO cannot be the explanation since the example packet is inbound from the router's point of view.

Update: disabling TSO/GSO on the router's WAN and WLAN interfaces did not change anything; the large frames are still present when re-running the experiment.