Turris Omnia fixiert einen Luleey-LL-XS2510-XPON-Stick auf 1000baseX, und ethtool bietet nie 2.5G an

Poste die vollständige ethtool eth2-Ausgabe und die sfp-Zeilen aus dmesg, nicht nur die Link-Meldung. Der interessante Teil ist, wozu der Host das Modul für fähig hält: Wenn phylink sich auf inband/1000base-x festgelegt hat, hat es das aus dem eigenen EEPROM des Moduls übernommen, und nichts, was du am Router konfigurierst, fügt einen Modus hinzu, den der Treiber nie gesehen hat.

Der Käfig an der Omnia geht problemlos bis 2.5G, die Hardware ist hier also nicht die Grenze. Sag auch, ob sich am Host zuletzt etwas geändert hat, ein Image-Upgrade eingeschlossen.

dmesg, bei jedem Boot identisch:

mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode
Link is Up - 1Gbps/Full

ethtool eth2 gibt 1000baseX/Full sowohl als Supported- als auch als Advertised-Set, und Link detected: yes bei 1000Mb/s Vollduplex. Nichts über 1G taucht in der Ausgabe auf.

flash set LAN_SDS_MODE 6 am Stick geht durch und übersteht einen Neustart des Moduls, aber die Host-Seite reagiert überhaupt nicht darauf: gleiche Meldung, gleiches 1G. Der Router läuft auf diesem Image, seit der Stick drinsteckt, es gibt also nichts, worauf ich zurückrollen könnte.

Das ist der Host, der dem Modul aufs Wort glaubt. Der sfp-Treiber liest das EEPROM, sieht ein Teil, das 1000base-x deklariert, und fixiert eth2 auf inband/1000base-x; phylink hat dann keinen 2.5G-Modus anzubieten, genau die ethtool-Ausgabe, die du gepostet hast. Was du im RTL960x mit LAN_SDS_MODE einstellst, betrifft das eigene Serdes des Moduls, nicht das, was es dem Router meldet, das sollte den ausgehandelten Modus also nie ändern.

Zwei Auswege, und ich kenne nur diese zwei. Entweder das Modul-EEPROM umschreiben, damit es 2.5G meldet, das ist der bekannte Trick beim DFP-34X-2C3, aber deins ist ein 2C2, und ich würde nicht dieselben Offsets annehmen. Oder den Host patchen: einen Quirk für dieses Modul in sfp.c ergänzen und einen Kernel damit fahren, der Stick bleibt dabei unangetastet.

Unterm Strich würde ich den Host patchen. Ein zerschossenes EEPROM in einem Stick, den man nicht einfach neu flashen kann, ist ein deutlich schlimmerer Nachmittag als ein Kernel, den man zurückrollen kann.

Ein weiterer Grund, eher den Host als das Modul im Verdacht zu behalten. Bei OpenWrt-Snapshots gab es eine Phase, in der der zurückportierte generische phylink-Validate-Code den SFP-Käfig der Omnia komplett zerschossen hat: ethtool meldete weiterhin 2500baseX/Full, und der Port zeigte nur Link detected: no. Das ließ sich sauber auf diesen Kernel-Commit zurückführen, den Backport rauszunehmen brachte den Link mit 2500Mb/s Vollduplex zurück, und ein Folge-Fix hat es endgültig behoben.

Anderes Symptom als deins, gleiche Lehre. Auf mvneta- und phylink-Boards entscheidet die Host-Software, was der Käfig darf, und es zahlt sich aus, ein nachweislich funktionierendes Image zum Zurückfallen zu behalten, bevor man anfängt, sich einen eigenen zu bauen.

Falls du beim eigenen Kernel auf Turris OS landest, zuerst einen Snapshot ziehen: schnapps create "Before new kernel", dann opkg install --force-reinstall /srv/kernel_5.15.148-1_arm_cortex-a9_vfpv3-d16.ipk und neu starten. Wenn der Kernel Zicken macht, rollst du zurück, statt den Router auseinanderzunehmen.

Die zweite Sache, die niemand erwähnt, bevor es zu spät ist: Ein 2,5-Gbps-Link ist kein 2,5-Gbps-Durchsatz. Die Armada-CPU in der Omnia bekommt das auf einer einzigen Queue nicht durchgedrückt, also mit Packet Steering und RPS-Tuning rechnen, bevor die Zahl auf der Leitung zu echtem Durchsatz wird.

Unabhängige Falle für alle, die das hier mit einem anderen Stick lesen: Manche PON-Module fahren ihr eigenes Betriebssystem hoch und brauchen etwa eine Minute, bevor sie überhaupt antworten, bei einem Kaltstart fragt der Router den Käfig also zu früh ab und fällt auf die Kupfer-Magnetics zurück. fw_setenv bootdelay 60 in U-Boot ist die übliche Abhilfe. Nicht dein Fall, da dein Modul sofort erkannt wird.

Um das hier abzuschließen: Der gepatchte Host hat gewonnen. Einen Kernel mit modifizierter sfp.c gebaut, vorher den schnapps-Snapshot gezogen, das ipk mit --force-reinstall installiert und neu gestartet. ethtool eth2 listet jetzt 2500baseX/Full, und der Link kommt mit 2,5 Gbps hoch.

Am Modul wurde am Ende nichts gemacht. LAN_SDS_MODE blieb, wo es war, und stellte sich als irrelevant heraus, ich musste also nie ans EEPROM.

Der Durchsatz brauchte auch den zweiten Ratschlag. Direkt nach dem Neustart lag die Box auf einer einzigen Queue deutlich unter der Link-Rate; mit abgestimmtem Packet Steering macht das WAN jetzt endlich das, wofür der Stick gekauft wurde.