Warum sehe ich Ethernet-Frames, die die Größe des MTU + Ethernet-Headers überschreiten?

Ich habe einen Wi-Fi-Router für Endverbraucher, der ein lokales Netzwerk hostet. Der Router ist über ein Campus-Netzwerk mit dem Internet verbunden (dh ein Ethernet-Kabel verbindet den WAN-Port mit einem Campus-Ethernet-Stecker). Ich verwende tcpdumpdie WLAN- und WAN-Schnittstellen des Routers, um den von den an den Router angeschlossenen Geräten erzeugten Datenverkehr zu erfassen.

Was mich verwirrt, ist, dass ich Frames sehe, die deutlich länger sind als die von der MTU definierte Grenze plus die Headergröße der Ebene 2. Ich dachte zuerst, dass dies durch die Unterstützung des Campusnetzwerks für Ethernet-Jumbo-Frames erklärt werden sollte, aber diese sind (normalerweise) auf 9.000 Bytes MTU begrenzt, und ich sehe einige Frames, die fast 13.000 Bytes lang sind.

Als Nächstes dachte ich, dass die Geräte, da sie über WLAN verbunden sind, nicht durch die Ethernet-MTU, sondern durch die 802.11-MTU eingeschränkt sind, aber es scheint, als wären es etwa 2304 Bytes, sodass ein 13-KB-Frame immer noch zu groß ist. Randbemerkung: Die Frames erscheinen in Wireshark als Ethernet-Frames. Dies ist jedoch offensichtlich darauf zurückzuführen, dass 802.11-Frames in gefälschte Ethernet-Frames konvertiert werden, bevor sie an den Netzwerk-Stack des Betriebssystems geliefert werden .

802.11-Adapter wandeln häufig 802.11-Datenpakete in gefälschte Ethernet-Pakete um, bevor sie sie an den Host liefern, und selbst wenn dies nicht der Fall ist, tun dies die Treiber für die Adapter häufig, bevor sie die Pakete an den Netzwerkstapel und den Paketaufnahmemechanismus des Betriebssystems liefern.

Einige interessante Beobachtungen, die Ihnen dabei helfen könnten, ein wenig Licht ins Dunkel zu bringen:

• Für die an der WLAN-Schnittstelle des Routers erfasste Ablaufverfolgung sind es nur Pakete, die von einem lokalen Gerät stammen und auf einen Internet-Host zugehen, der die MTU überschreitet. Alle eingehenden Pakete (Internet-Host zu lokalem Gerät) haben eine Länge von 1514 oder weniger.
• Für die an der WAN-Schnittstelle des Routers erfasste Trace überschreitet nur der eingehende Datenverkehr (Internet-Host zu Router) die Ethernet-MTU.
• Man kann den großen Frame (der die MTU überschreitet) auf einer Seite des Routers auf mehrere Frames mit einer MTU-Größe oder weniger auf der anderen Seite des Routers "abbilden", indem die beiden Spuren miteinander verknüpft werden.
• Dies ist der gesamte TLS-Verkehr (dies sollte jedoch keinen Unterschied machen, da dies ein Schicht-2-Limit ist).

Ich vermute, dass dieses Verhalten möglicherweise auf der Antwort von TSO / GSO beruht . Es besagt jedoch, dass man diese größeren Frames nicht sehen sollte, wenn man die Erfassung auf einem Netzwerkgerät durchführt:

[...] Sie sehen möglicherweise, dass TCP größere Segmente sendet als die MTU. Die Pakete auf dem Draht haben jedoch nur die Größe der MTU. Sie können dies durch Aufnehmen auf einem Netzwerkgerät (Switch) usw. überprüfen.

Ich führe die Aufnahme zwar auf einem Netzwerkgerät (einem Router) durch, sehe jedoch immer noch die großen Frames. Auf dem Router wird jedoch LEDE / OpenWrt ausgeführt, was meiner Meinung nach eine Art "verbessertes" Netzwerkgerät darstellt, das einem tatsächlichen Host mehr entspricht als einem Netzwerkgerät ...?

Ich füge ein Beispiel für einen Rahmen bei, der die MTU überschreitet. Beachten Sie, dass dieser Frame in der WAN-Schnittstelle des Routers ( eth0) erfasst wurde . Ist dies einfach ein Ergebnis von TSO / GSO oder gibt es etwas anderes, das mir nicht bewusst ist? Funktioniert TSO / GSO auch in beide Richtungen oder gilt dies nur für ausgehende Pakete? Wenn letzteres der Fall ist, kann TSO / GSO nicht die Erklärung sein, da das Beispielpaket aus Sicht des Routers eingehend ist.

Update: Das Deaktivieren von TSO / GSO auf den WAN- und WLAN-Schnittstellen des Routers hat nichts geändert. Die großen Frames sind immer noch vorhanden, wenn das Experiment erneut ausgeführt wird.