Turris Omnia pint een Luleey LL-XS2510 XPON-stick vast op 1000baseX en ethtool biedt nooit 2.5G aan

Post de volledige ethtool eth2-output en de sfp-regels uit dmesg, niet alleen de linkmelding. Het interessante deel is waartoe de host besloot dat de module in staat is: als phylink uitkwam op inband/1000base-x, heeft hij dat uit de eigen EEPROM van de module gehaald, en niets wat jij op de router configureert voegt een modus toe die de driver nooit gezien heeft.

De cage op de Omnia kan prima tot 2.5G, dus de hardware is hier niet wat je beperkt. Zeg ook of er recent iets aan de host is veranderd, een image-upgrade inbegrepen.

dmesg, identiek bij elke boot:

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

ethtool eth2 geeft 1000baseX/Full als zowel de supported- als de advertised-set, en Link detected: yes op 1000Mb/s full duplex. Er verschijnt nergens iets boven 1G in de output.

flash set LAN_SDS_MODE 6 op de stick gaat wel door en overleeft een reboot van de module, maar de hostkant reageert er totaal niet op: zelfde melding, zelfde 1G. De router draait deze image al sinds de stick erin ging, dus er is niets om naar terug te rollen.

Dat is de host die de module op zijn woord gelooft. De sfp-driver leest de EEPROM, ziet een onderdeel dat zich als 1000base-x aandient, en pint eth2 vast op inband/1000base-x; phylink heeft dan geen 2.5G-modus om aan te bieden, en dat is precies de ethtool-output die jij plaatste. Wat je met LAN_SDS_MODE binnen de RTL960x instelt, raakt de eigen serdes van de module, niet wat hij aan de router adverteert, dus dat zou de onderhandelde modus nooit veranderen.

Twee uitwegen, en ik ken alleen deze twee. Ofwel de EEPROM van de module herschrijven zodat hij 2.5G adverteert, wat de bekende truc is op de DFP-34X-2C3, maar die van jou is een 2C2 en ik zou niet aannemen dat dezelfde offsets gelden. Ofwel de host patchen: een quirk voor deze module toevoegen in sfp.c en daarmee een kernel draaien, terwijl de stick onaangeroerd blijft.

Per saldo zou ik de host patchen. Een gebrickte EEPROM in een stick die je niet makkelijk kunt reflashen is een veel vervelendere middag dan een kernel die je kunt terugrollen.

Nog een reden om de host te verdenken in plaats van de module. Op OpenWrt-snapshots was er een periode waarin de teruggeporte generieke phylink-validate-code de SFP-cage van de Omnia ronduit stukmaakte: ethtool adverteerde nog steeds 2500baseX/Full en de poort meldde gewoon Link detected: no. Het is netjes gebisect tot op die kernel-commit, het laten vallen van de backport bracht de link terug op 2500Mb/s full duplex, en een vervolgfix sloot het af.

Ander symptoom dan het jouwe, zelfde les. Op mvneta- en phylink-boards bepaalt de hostsoftware wat de cage mag doen, en het loont om een bekend goede image achter de hand te houden om op terug te vallen voor je je eigen image gaat bouwen.

Ga je toch de custom-kernel-route op Turris OS op, maak dan eerst een snapshot: schnapps create "Before new kernel", daarna opkg install --force-reinstall /srv/kernel_5.15.148-1_arm_cortex-a9_vfpv3-d16.ipk en reboot. Gedraagt de kernel zich niet, dan rol je terug in plaats van de router uit elkaar te halen.

Het tweede ding dat niemand noemt tot achteraf: een 2.5 Gbps-link is geen 2.5 Gbps aan verkeer. De Armada-CPU in de Omnia duwt dat niet door op één enkele queue, dus reken op packet steering en RPS-tuning voordat het getal op de lijn in doorvoer verandert.

Losstaande valkuil voor iedereen die dit met een andere stick leest: sommige PON-modules draaien hun eigen besturingssysteem en hebben ruwweg een minuut nodig voor ze überhaupt reageren, dus bij een cold boot polst de router de cage te vroeg en valt hij terug op de koperen magnetics. fw_setenv bootdelay 60 in U-Boot is het gebruikelijke medicijn. Niet jouw geval, want jouw module wordt meteen gedetecteerd.

Cirkel gesloten: de gepatchte host heeft gewonnen. Een kernel gebouwd met de aangepaste sfp.c, eerst de schnapps-snapshot genomen, de ipk geïnstalleerd met --force-reinstall en gerebood. ethtool eth2 vermeldt nu 2500baseX/Full en de link komt op met 2.5 Gbps.

Aan de module is uiteindelijk niets gedaan. LAN_SDS_MODE bleef staan waar het stond en bleek irrelevant, dus ik heb de EEPROM nooit hoeven aanraken.

Doorvoer had ook het tweede advies nodig. Direct na de reboot zat de box ruim onder de linksnelheid op één queue; met packet steering afgesteld doet de WAN eindelijk waarvoor de stick gekocht is.