ODI DFP-34X-2C2 in einem Turris Omnia linkt nur mit 1000base-x, ethtool nimmt speed 2500 nicht an
Ich habe die ISP-ONU gegen einen ODI-DFP-34X-2C2-GPON-Stick in meinem Turris Omnia getauscht, damit die Faser im Router endet statt in einer anderen Box im Regal. Der Teil hat funktioniert: Die Leitung ist registriert, Traffic fließt, keine Beschwerden. Das Problem ist die Rate. Sie geht nie über 1Gbps hinaus, und 2.5G war der ganze Grund, warum ich diesen Stick gekauft habe.
- Turris Omnia, TurrisOS 6.0.4
- ODI-DFP-34X-2C2-GPON-Stick in der SFP-Cage, eth2
- Kupfer-WAN abgesteckt, die Cage besitzt den Port
Was der Kernel nach einem Boot sagt, und was passiert, wenn ich versuche, die Rate hochzudrücken:
# dmesg | grep mvneta
eth2: switched to inband/1000base-x link mode
# ethtool -s eth2 speed 2500
Invalid argumentethtool eth2 zeigt bei aktivem Link das Modul als 1000baseX/Full und nichts Höheres, und die Ablehnung oben ist ethtool, das mir sagt, dass speed 2500 nicht angeboten werden kann.
Bisher versucht:
- per Telnet in den Stick und die Rate aus seiner eigenen Shell gesetzt; er nimmt den Befehl an und kommt dann bei 1Gbps zurück
- Reboots mit und ohne angeschlossenes Kupfer-WAN
- dmesg durchsucht nach irgendetwas darüber, dass der MAC 2.5G angeboten bekommt, da ist nichts
Deckelt hier der Router den Port, oder ist es der Stick selbst? Und gibt es etwas hostseitig, das eth2 mit diesem Stick auf 2500base-x hochbringt?
Comments 5
Die Decke hier ist das Modul selbst, nicht der Omnia.
Wogegen der Host verhandelt, ist das, was das EEPROM des Moduls als sein Können deklariert, denn zum Zeitpunkt der Prüfung ist dieser Chip alles, worauf sich die Cage stützen kann. Auf diesem Stick ist er auf 1000Mbps codiert. Der Port wird also als inband/1000base-x eingerichtet, es gibt keinen 2500base-x-Modus, den phylink anbieten könnte, und ethtool weigert sich bei speed 2500, weil es nichts gibt, womit es das anbieten könnte. Kein hostseitiger Schalter kommt daran vorbei: ethtool kann nur Modi anfragen, von denen dem Port gesagt wurde, dass sie existieren. Die Shell im Stick konfiguriert die PON-Seite des Moduls, nicht das, was die Cage gegenüber dem MAC anbietet, genau deshalb verpufft deine Telnet-Änderung, und du landest wieder bei 1Gbps.
Bleiben zwei echte Optionen: das Modul umcodieren lassen, sodass es 2.5G anbietet, oder es durch eines ersetzen, das das schon tut. Wer den Umcodierungsweg geht, sollte ein Ersatzteil auf dem Tisch haben. Man schreibt die Identitätsseite um, der der Host vertraut, und ein falsches Byte dort sorgt für ein Modul, das die Cage überhaupt nicht mehr erkennt. Auch die beiden Raten im Kopf auseinanderhalten: Was die PON-Seite liefert und was der SFP-zu-MAC-Link aushandelt, sind zwei getrennte Zahlen, also erst klären, was dabei tatsächlich gewonnen wird, bevor Geld dafür ausgegeben wird.
Bevor der Stick beschuldigt wird: prüfen, welchen Device Tree die Box bootet. Die Cage an einem Omnia ist kein zusätzliches Interface: Sie und die metallische WAN-Hälfte sind zwei Frontends auf ein und demselben eth2, und immer nur eines von beiden ist tatsächlich zum MAC durchverbunden. Welches das ist, hängt vom dtb ab, den der Kernel beim Boot lädt. Also nachsehen, worauf /boot/dtb zeigt: Wenn es nicht armada-385-turris-omnia-sfp.dtb ist, schaut man auf die Kupferseite, und die Zahlen bedeuten nichts.
Auch das vollständige dmesg | grep -i sfp posten, nicht nur die mvneta-Zeile. Was der Kernel beim Sondieren aus dem Modul ausliest, ist hier der interessante Teil, und das klärt die Frage meist in einer Zeile.
Der dtb ist schon der SFP-dtb, ich habe armada-385-turris-omnia-sfp.dtb verlinkt, als ich den Stick zuerst reingesteckt habe, sonst kam gar nichts hoch. Die Cage besitzt eth2, und das Kupfer-WAN bleibt abgesteckt.
dmesg | grep -i sfp zeigt das Modul identifiziert und dann dieselbe Zeile, die ich gepostet habe, eth2 switched to inband/1000base-x link mode. Nirgends etwas über 2500. ethtool eth2 meldet 1000baseX/Full, während der Link oben ist und Traffic durchlässt, und ethtool -s eth2 speed 2500 kommt immer noch mit Invalid argument zurück, es wird 2500 also gar nicht anbieten. Die Rate per Telnet im Stick zu setzen verhält sich wie zuvor, er nimmt es an und fällt dann zurück auf 1Gbps.
Verwandte Geschichte vom selben Board, falls hier jemand mit einem Stick landet, der überhaupt nicht hochkommt statt bei 1G hängen zu bleiben. HALNy HL-GSFP in einem Omnia auf Turris OS HBS 6.2.4: der Kernel hat es identifiziert, der Port ist sogar auf inband/1000base-x umgeschaltet, und dann ist der Link weggebrochen, und eth2 kam nie hoch.
Das ist kein EEPROM-Problem. In diesem Stick lebt ein ganzes kleines OS, und das will etwa eine Minute für sich, bevor es überhaupt in der Lage ist, dem Host zu antworten. Bei einem Kaltstart hat der Router die Cage längst sondiert und aufgegeben, bevor es so weit ist, also geht der Port zurück auf die Kupfer-Magnetics. Die U-Boot-Verzögerung zu verlängern hat es hier behoben:
Standard sind 3 Sekunden; bei 60 ist der Stick fertig hochgefahren, bis der Kernel dazu kommt, die Cage zu sondieren. Das Kupfer-WAN abzustecken und ein zweites Mal neu zu starten half bei der Erkennung ebenfalls. Und falls mal jemand in einen Stick reinschauen muss: Seriell darauf sind 38400 8N1.
Der Diagnose stimme ich zu, mit einer Einschränkung für alle, die hier mit einem ähnlichen Symptom landen. Nicht jedes „es macht kein 2.5G" an diesem Board ist das Modul. Es gab einen OpenWrt-Snapshot, in dem der generische phylink-validate-Code zurückportiert wurde, und der hat die Omnia-Cage glatt kaputtgemacht: ethtool bot weiterhin 2500baseX/Full an, meldete aber Link detected: no. Dieses Backport rückgängig zu machen brachte den Port dahin zurück, wo er gewesen war, ethtool las Link detected: yes, 2500Mb/s full duplex, und ein späterer Pull Request hat das Backport upstream bereinigt.
Der Hinweis steckt darin, was ethtool als supported und advertised listet. Wenn 2500baseX/Full da drinsteht und der Link einfach nicht hochkommen will, den Kernel und phylink nach dem letzten Image-Upgrade anschauen, nicht die Optik. Wenn, wie hier, der Port immer nur 1000baseX kennt, weil das Modul das über sich selbst deklariert hat, wird keine Host-Software den Modus herbeizaubern. Das ist das Nominal-Bitrate-Byte im EEPROM, das genau das tut, was SFF-8472 vorschreibt.