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:
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 statt der erwarteten 1500B (1472B + 8B + 20B) = 1518B Ethernet-Frame:
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.:
ping -M do -s 1472 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 1472(1500) bytes of data.
1480 bytes from 10.0.0.2: icmp_seq=1 ttl=255 time=1.05 ms
ping -M do -s 1473 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 1473(1501) bytes of data.
^C
ping -M do -s 1472 10.0.0.8
PING 10.0.0.8 (10.0.0.8) 1472(1500) bytes of data.
1480 bytes from 10.0.0.8: icmp_seq=1 ttl=64 time=0.749 ms
ping -M do -s 1473 10.0.0.8
PING 10.0.0.8 (10.0.0.8) 1473(1501) bytes of data.
^C
Alles anzeigen
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:
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:
ping -M do -s 8972 10.0.0.95
PING 10.0.0.95 (10.0.0.95) 8972(9000) bytes of data.
^C
ping -M do -s 1491 10.0.0.95
PING 10.0.0.95 (10.0.0.95) 1491(1519) bytes of data.
^C
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.310 ms
Alles anzeigen
Und ja, grundsätzlich funktionieren Jumboframes hier im Netz mit MTU 9000 ohne Probleme zwischen diversen Geräten, Beispiel zum Switch:
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:
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.
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.
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:
ping6 2001:x:x:x:209:34ff:x:x
PING 2001:x:x:x:209:34ff:x:x(2001:x:x:x:209:34ff:x:x) 56 data bytes
64 bytes from 2001:x:x:x:209:34ff:x:x: icmp_seq=1 ttl=64 time=0.243 ms
ssh root@2001:x:x:x:209:34ff:x:x
ssh: connect to host 2001:x:x:x:209:34ff:x:x port 22: Connection refused
wget http://[2001:x:x:x:209:34ff:x:x]/
--2016-08-06 11:08:51-- http://[2001:x:x:x:209:34ff:x:x]/
Verbindungsaufbau zu [2001:x:x:x:209:34ff:x:x]:80... fehlgeschlagen: Verbindungsaufbau abgelehnt.
Alles anzeigen