Das Thema MTU auf der 7080

1. offizieller Beitrag

    Hallo zusammen,


    da in einem anderen Thread das Thema MTU auf der 7080 aufgekommen ist, habe ich mich auch mal ein wenig damit auseinandergesetzt. Aber irgendetwas stimmt da auf der/meiner? 7080 nicht (oder ich steh grad echt massiv auf der Leitung).



    Standardmäßig ist die MTU laut ifconfig auf 1500 eingestellt, zur Sicherheit auch nochmal per „ifconfig eth0 mtu 1500“ gesetzt:


    Code
    Aug 06 10:44:57 dm7080 connmand[193]: eth0 {newlink} index 2 address 00:09:34:XX:XX:XX mtu 1500
Aug 06 10:44:57 dm7080 connmand[193]: eth0 {newlink} index 2 operstate 6 <UP>


ifconfig eth0 | grep MTU
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1



    Allerdings beantwortet die 7080 (mit der .95) in diesem Zustand warum auch immer Pings bis gesamt 1518 Byte Ethernet-Payload (1490B ICMP-Pay + 8B ICMP-Head + 20B IP-Head) sprich ein Ethernet-Frame von 1532B :confused_face: statt der erwarteten 1500B (1472B + 8B + 20B) = 1518B Ethernet-Frame:


    Code
    ping -M do -s 1490 10.0.0.95
PING 10.0.0.95 (10.0.0.95) 1490(1518) bytes of data.
1498 bytes from 10.0.0.95: icmp_seq=1 ttl=64 time=0.213 ms


ping -M do -s 1491 10.0.0.95
PING 10.0.0.95 (10.0.0.95) 1491(1519) bytes of data.
^C


    Alle anderen Geräte im Netzwerk mit MTU 1500 machen (so wie es bei 1500 sein sollte) nur 1500B Ethernet-Payload mit, z.B.:




    Wenn ich die MTU nun z.B. per „ifconfig eth0 mtu 9000“ oder „ip link set eth0 mtu 9000“ auf 9000 hochsetzte, wird das laut journalctl und ifconfig angewendet:


    Code
    Aug 06 10:49:03 dm7080 connmand[193]: eth0 {newlink} index 2 address 00:09:34:XX:XX:XX mtu 9000
Aug 06 10:49:03 dm7080 connmand[193]: eth0 {newlink} index 2 operstate 6 <UP>


ifconfig eth0 | grep MTU
          UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1


    Allerdings führt ein entsprechender Ping Richtung Box dennoch ins Leere, die Box reagiert auch weiterhin nur auf Pings mit 1518B Ethernet Payload:




    Und ja, grundsätzlich funktionieren Jumboframes hier im Netz mit MTU 9000 ohne Probleme zwischen diversen Geräten, Beispiel zum Switch:


    Code
    ping -M do -s 8972 10.0.0.254
PING 10.0.0.254 (10.0.0.254) 8972(9000) bytes of data.
8980 bytes from 10.0.0.254: icmp_seq=1 ttl=64 time=1.93 ms


ping -M do -s 8973 10.0.0.254
PING 10.0.0.254 (10.0.0.254) 8973(9001) bytes of data.
ping: local error: Message too long, mtu=9000



    Auch die ganzen anderen Probleme, die ich mit der 7080 in Bezug auf Gig-Ethernet früher mal hatte (Aushandeln, Bekanntgabe, Flusssteuerung, MDI/MDIX) sind zumindest im aktuellen Unstable nicht mehr vorhanden, sodass ich den Port Switch-seitig wieder „normal“ konfiguriert habe, so wie bei anderen Geräten auch (sprich alles automatisch). Nur die „Kurze Reichweite“ von Green Ethernet ist weiterhin aus, da die Box sonst eine Gedenk-Minute beim Booten einlegt.


    Gigabit ist ausgehandelt und funktioniert auch prinzipiell, kurzer Test bringt 523 MBit/s:


    Code
    date && wget -O /dev/null http://10.0.0.10/testfile && date
Sat Aug  6 11:37:58 CEST 2016
Connecting to 10.0.0.10 (10.0.0.10:80)
null                 100% |*************************************|  2874M  0:00:00 ETA
Sat Aug  6 11:38:42 CEST 2016



    Getestet habe ich das Ganze auf meiner 7080 zuerst mit dem (immer wieder per Updates hochgezogenen) Unstable. Aber auch auf einem frisch geflashten aktuellen Stable (dreambox-image-deb-dm7080-20160514.tar.xz) oder Unstable (dreambox-image-deb-dm7080-20160712.tar.xz), ohne irgendwelche Einstellungen oder Plugins, komme ich zum selben Ergebnis.



    @Devs: Vielleicht könnt ihr euch das mal anschauen, wenn ihr irgendwann Zeit habt (und mir sagen, ob ich hier irgendwo einen Denkfehler habe oder es doch ein Bug ist). Gibt natürlich gerade wichtigere Dinge, wie z.B. neue Boxen. :grinning_squinting_face:
    Das GigEthernet funktioniert ja inzwischen (bis auf die Kurze Reichweite) ohne weitere Probleme, zumindest bei mir. Und MTU 9000 ist jetzt nicht gerade ein Mainstream-Problem. :smiling_face_with_sunglasses:




    PS: Falls beim Start des Rescue-Loaders kein v4-DHCP-Server zur Verfügung steht, aber ein v6er, krallt sich der Loader zwar seine entsprechende v6er-Adresse, die korrekt im Front-Display angezeigt wird. Die ist auch pingbar, aber weder SSH noch HTTP lassen sich darüber aufrufen, und damit ohne v4 leider auch nichts flashen:


    Zitat von Reichi

    Wir haben auf eine neue Basis aktualisiert.
    D.h. es wurde vor Allem EXTERNE Software aktualisiert, davon aber nahezu alles.


    Deswegen hätte es ja sein können, dass da ("nahezu alles") auch irgendetwas dabei gewesen wäre, was dieses Problem betrifft.


    Außerdem gab es seit August keine Reaktion auf den Thread und ich hatte gerade Zeit nach dem Flashen von OE 2.5 zu schauen, ob sich diesbezüglich was geändert hat oder nicht.


    Da kann man den Thread mit einem kleinen Update auch mal als freundliche Erinnerung wieder hochholen, oder?