L'ODI DFP-34X-2C2 in un Turris Omnia fa link solo a 1000base-x, ethtool non accetta speed 2500
Ho sostituito l'ONU dell'ISP con uno stick GPON ODI DFP-34X-2C2 nel mio Turris Omnia, così la fibra termina nel router invece che in un'altra scatola sullo scaffale. Quella parte ha funzionato: la linea è registrata, il traffico passa, nessun problema. Il problema è la velocità. Non va mai oltre 1Gbps, e il 2.5G era tutto il motivo per cui ho comprato questo stick.
- Turris Omnia, TurrisOS 6.0.4
- stick GPON ODI DFP-34X-2C2 nella cage SFP, eth2
- WAN in rame scollegata, la cage possiede la porta
Cosa dice il kernel dopo un boot, e cosa succede quando provo a forzare la velocità:
# dmesg | grep mvneta
eth2: switched to inband/1000base-x link mode
# ethtool -s eth2 speed 2500
Invalid argumentethtool eth2 con il link up mostra il modulo come 1000baseX/Full e niente di più alto, e il rifiuto sopra è ethtool che mi dice che speed 2500 non può essere annunciata.
Già provato:
- entrare via telnet nello stick e impostare la velocità dalla sua stessa shell; accetta il comando e poi torna a 1Gbps
- riavvii con e senza la WAN in rame collegata
- guardato in dmesg per qualcosa sul MAC a cui viene offerto 2.5G, non c'è niente
È il router che limita la porta, o è il modulo stesso? E c'è qualcosa lato host che fa salire eth2 a 2500base-x con questo stick?
Comments 5
Il limite qui è il modulo stesso, non l'Omnia.
Quello contro cui negozia l'host è quello che l'EEPROM del modulo dichiara di saper fare, perché al momento della probe quel chip è l'unica cosa su cui la cage può basarsi. Su quello stick è codificato per 1000Mbps. Quindi la porta viene impostata come inband/1000base-x, non c'è nessuna modalità 2500base-x che phylink possa offrire, ed ethtool rifiuta speed 2500 perché non c'è niente con cui annunciarla. Nessuna impostazione lato host aggira questo: ethtool può chiedere solo le modalità che alla porta è stato detto esistere. La shell dentro lo stick configura il lato PON del modulo, non quello che la cage annuncia verso il MAC, ed è esattamente per questo che la tua modifica via telnet evapora e torni a 1Gbps.
Restano due opzioni vere: far ricodificare il modulo perché annunci 2.5G, oppure sostituirlo con uno che già lo fa. Se scegli la strada della ricodifica, tieni un pezzo di scorta sulla scrivania. Stai riscrivendo la pagina di identità di cui l'host si fida, e un byte sbagliato lì ti restituisce un modulo che la cage smette del tutto di riconoscere. Tieni anche separate in testa le due velocità: quello che il lato PON consegna e quello che il link SFP-MAC negozia sono numeri distinti, quindi calcola cosa guadagni davvero prima di spendere soldi su questo.
Prima di dare la colpa allo stick, controlla quale device tree carica la scatola all'avvio. La cage su un Omnia non è un'interfaccia in più: lei e la metà in rame della WAN sono due ingressi sullo stesso identico eth2, e solo uno dei due è collegato davvero al MAC alla volta. Quale dei due dipende dal dtb che il kernel carica al boot. Quindi guarda a cosa punta /boot/dtb: se non è armada-385-turris-omnia-sfp.dtb, stai fissando il lato rame e i numeri non significano niente.
Posta anche l'output completo di dmesg | grep -i sfp, non solo la riga di mvneta. Quello che il kernel legge dal modulo al momento della probe è la parte interessante qui, e di solito risolve la domanda in una riga.
Il dtb è già quello SFP, ho fatto il symlink di armada-385-turris-omnia-sfp.dtb quando ho messo lo stick la prima volta, altrimenti non saliva niente. La cage possiede eth2 e la WAN in rame resta scollegata.
dmesg | grep -i sfp mostra il modulo identificato e poi la stessa riga che ho postato, eth2 switched to inband/1000base-x link mode. Niente su 2500 da nessuna parte. ethtool eth2 riporta 1000baseX/Full mentre il link è up e passa traffico, e ethtool -s eth2 speed 2500 torna comunque con Invalid argument, quindi non annuncia affatto 2500. Impostare la velocità via telnet dentro lo stick si comporta come prima, accetta il comando e poi ricade a 1Gbps.
Storia collegata sulla stessa scheda, nel caso qualcuno arrivi qui con uno stick che non sale per niente invece che uno bloccato a 1G. HALNy HL-GSFP in un Omnia su Turris OS HBS 6.2.4: il kernel lo identificava, la porta passava perfino a inband/1000base-x, e poi il link cadeva ed eth2 non saliva mai.
Quello non è un problema di EEPROM. Dentro quello stick vive un piccolo OS a sé, e vuole circa un minuto per conto suo prima di essere in condizione di rispondere all'host. Su un avvio a freddo il router ha già sondato la cage e rinunciato molto prima di quel punto, quindi la porta torna alla magnetica in rame. Allungare il ritardo di U-Boot ha risolto qui:
Il default è 3 secondi; a 60 lo stick ha finito di salire per quando il kernel arriva a sondare la cage. Anche scollegare la WAN in rame e riavviare una seconda volta ha aiutato il rilevamento. E se mai devi guardare dentro uno stick, la seriale è 38400 8N1.
D'accordo sulla diagnosi, con un avvertimento per chiunque arrivi qui con un sintomo simile. Non ogni caso di "non fa il 2.5G" su questa scheda è il modulo. C'è stato uno snapshot OpenWrt in cui il codice generico di phylink validate è stato backportato, e ha rotto la cage dell'Omnia di netto: ethtool continuava ad annunciare 2500baseX/Full ma riportava Link detected: no. Fare il revert di quel backport ha rimesso la porta dov'era, con ethtool che leggeva Link detected: yes, 2500Mb/s full duplex, e una pull request successiva ha sistemato il backport a monte.
Il segnale è in quello che ethtool elenca come supported e advertised. Se 2500baseX/Full c'è e il link semplicemente si rifiuta di salire, guarda il kernel e phylink dopo il tuo ultimo aggiornamento immagine, non l'ottica. Se, come qui, la porta conosce solo 1000baseX perché è quello che il modulo ha dichiarato di sé, nessun software lato host evocherà quella modalità. Quello è il byte del nominal bit rate nell'EEPROM che fa esattamente quello che dice SFF-8472.