Turris Omnia blocca uno stick XPON Luleey LL-XS2510 su 1000baseX ed ethtool non offre mai 2.5G

Posta l'output completo di ethtool eth2 e le righe sfp da dmesg, non solo il messaggio di link. La parte interessante è cosa ha deciso l'host riguardo alle capacità del modulo: se phylink si è stabilizzato su inband/1000base-x, l'ha preso dall'EEPROM del modulo stesso, e niente di quello che configuri sul router aggiungerà una modalità che il driver non ha mai visto.

La cage dell'Omnia va bene fino a 2.5G, quindi qui non è l'hardware a limitarti. Di' anche se di recente è cambiato qualcosa sull'host, upgrade dell'immagine incluso.

dmesg, identico a ogni boot:

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

ethtool eth2 dà 1000baseX/Full sia come insieme supported che advertised, e Link detected: yes a 1000Mb/s full duplex. Nell'output non compare nulla sopra 1G.

flash set LAN_SDS_MODE 6 sullo stick va effettivamente a buon fine e sopravvive a un reboot del modulo, ma il lato host non reagisce affatto: stesso messaggio, stesso 1G. Il router è su questa immagine da quando è entrato lo stick, quindi non c'è nulla a cui tornare indietro.

Questo è l'host che prende il modulo in parola. Il driver sfp legge l'EEPROM, vede una parte che dichiara 1000base-x, e blocca eth2 su inband/1000base-x; a quel punto phylink non ha nessuna modalità 2.5G da offrire, che è esattamente l'output di ethtool che hai postato. Quello che imposti dentro l'RTL960x con LAN_SDS_MODE tocca il serdes proprio del modulo, non quello che annuncia al router, quindi non avrebbe mai potuto cambiare la modalità negoziata.

Due vie d'uscita, e ne conosco solo due. O riscrivi l'EEPROM del modulo perché annunci 2.5G, che è il trucco noto sul DFP-34X-2C3, ma il tuo è un 2C2 e non darei per scontati gli stessi offset. Oppure patchi l'host: aggiungi un quirk per questo modulo in sfp.c e fai girare un kernel con quello, lasciando lo stick intatto.

Tutto sommato patcherei l'host. Un EEPROM bricchato in uno stick che non puoi riflashare facilmente è un pomeriggio molto peggiore di un kernel da cui puoi tornare indietro.

Un altro motivo per tenere sotto sospetto l'host piuttosto che il modulo. Sugli snapshot OpenWrt c'è stato un periodo in cui il codice generico di validazione phylink backportato rompeva del tutto la cage SFP dell'Omnia: ethtool continuava ad annunciare 2500baseX/Full e la porta riportava semplicemente Link detected: no. Il bisect ha puntato in modo netto a quel commit del kernel, togliere il backport ha riportato il link a 2500Mb/s full duplex, e una correzione successiva ha chiuso la faccenda.

Sintomo diverso dal tuo, stessa lezione. Sulle schede mvneta e phylink è il software dell'host a decidere cosa può fare la cage, e conviene tenersi un'immagine di sicura funzionalità su cui tornare prima di iniziare a costruirsene una propria.

Se decidi comunque di percorrere la strada del kernel personalizzato su Turris OS, fai prima uno snapshot: schnapps create "Before new kernel", poi opkg install --force-reinstall /srv/kernel_5.15.148-1_arm_cortex-a9_vfpv3-d16.ipk e riavvia. Se il kernel si comporta male torni indietro invece di smontare il router.

La seconda cosa che nessuno menziona finché non è troppo tardi: un link a 2,5 Gbps non è 2,5 Gbps di traffico. La CPU Armada dell'Omnia non lo spingerà su una singola coda, quindi mettete in conto packet steering e tuning dell'RPS prima che il numero sul cavo diventi throughput vero.

Una trappola non correlata per chiunque altro legga questo con uno stick diverso: alcuni moduli PON fanno girare un proprio sistema operativo e hanno bisogno di circa un minuto prima di rispondere anche solo minimamente, quindi a un cold boot il router interroga la cage troppo presto e ripiega sui magnetici in rame. fw_setenv bootdelay 60 in U-Boot è la cura solita. Non è il tuo caso, dato che il tuo modulo viene rilevato immediatamente.

Chiudo il cerchio: ha vinto l'host patchato. Ho costruito un kernel con l'sfp.c modificato, fatto prima lo snapshot con schnapps, installato l'ipk con --force-reinstall e riavviato. ethtool eth2 ora elenca 2500baseX/Full e il link si alza a 2,5 Gbps.

Al modulo alla fine non è stato fatto nulla. LAN_SDS_MODE è rimasto dov'era e si è rivelato irrilevante, quindi non ho mai dovuto toccare l'EEPROM.

Anche il throughput ha avuto bisogno del secondo consiglio. Subito dopo il reboot il box stava ben al di sotto della velocità del link su una singola coda; con il packet steering messo a punto la WAN finalmente fa quello per cui lo stick è stato comprato.