ODI DFP-34X-2C2 in een Turris Omnia linkt alleen op 1000base-x, ethtool accepteert speed 2500 niet
Ik heb de ISP-ONU vervangen door een ODI DFP-34X-2C2 GPON-stick in mijn Turris Omnia, zodat de vezel in de router eindigt in plaats van in nog een doos op de plank. Dat deel werkte: de lijn is geregistreerd, verkeer stroomt, geen klachten. Het probleem is de snelheid. Die komt nooit boven 1Gbps uit, en 2,5G was nou net de hele reden dat ik deze stick kocht.
- Turris Omnia, TurrisOS 6.0.4
- ODI DFP-34X-2C2 GPON-stick in de SFP-cage, eth2
- koperen WAN losgekoppeld, de cage bezit de poort
Wat de kernel zegt na een boot, en wat er gebeurt als ik de snelheid probeer te forceren:
# dmesg | grep mvneta
eth2: switched to inband/1000base-x link mode
# ethtool -s eth2 speed 2500
Invalid argumentethtool eth2 toont de module met de link up als 1000baseX/Full en niets hogers, en de weigering hierboven is ethtool die me vertelt dat speed 2500 niet geadverteerd kan worden.
Al geprobeerd:
- via telnet in de stick zelf de snelheid instellen vanuit zijn eigen shell; hij accepteert het commando en komt daarna terug op 1Gbps
- reboots met en zonder de koperen WAN aangesloten
- dmesg doorzocht op iets over de MAC die 2,5G aangeboden krijgt, er staat niets
Is dit de router die de poort beperkt, of de module zelf? En is er iets aan de hostkant dat eth2 met deze stick op 2500base-x kan laten opkomen?
Comments 5
Het plafond hier is de module zelf, niet de Omnia.
Waar de host tegen onderhandelt is wat de EEPROM van de module claimt te kunnen, want op het moment van probing is die chip het enige waar de cage op kan afgaan. Op deze stick staat hij gecodeerd voor 1000Mbps. Dus wordt de poort ingesteld als inband/1000base-x, is er geen 2500base-x-modus die phylink kan aanbieden, en weigert ethtool speed 2500 omdat er niets is om het mee te adverteren. Geen enkele hostkant-schakelaar komt daar omheen: ethtool kan alleen modi opvragen waarvan de poort te horen heeft gekregen dat ze bestaan. De shell in de stick configureert de PON-kant van de module, niet wat de cage naar de MAC toe adverteert, en dat is precies waarom je telnet-wijziging verdampt en je weer op 1Gbps terechtkomt.
Dan blijven er twee echte opties over: laat de module hercoderen zodat hij 2,5G adverteert, of vervang hem door een die dat al doet. Ga je de hercodeerroute op, houd dan een reserve op het bureau. Je herschrijft de identiteitspagina die de host vertrouwt, en één verkeerde byte daar levert je een module op die de cage helemaal niet meer herkent. Houd ook de twee snelheden uit elkaar in je hoofd: wat de PON-kant levert en wat de SFP-naar-MAC-link onderhandelt zijn losse cijfers, dus reken eerst uit wat je er echt mee opschiet voor je hier geld aan uitgeeft.
Voor je de stick de schuld geeft, controleer welke device tree de doos boot. De cage op een Omnia is geen extra interface: die en de metalen WAN-helft zijn twee front-ends op een en dezelfde eth2, en er is er maar één tegelijk echt doorverbonden naar de MAC. Welke dat is, hangt af van de dtb die de kernel bij het booten laadt. Kijk dus naar waar /boot/dtb naar wijst: is het niet armada-385-turris-omnia-sfp.dtb, dan kijk je naar de koperkant en betekenen de cijfers niets.
Post ook de volledige dmesg | grep -i sfp, niet alleen de mvneta-regel. Wat de kernel bij het probe-moment uit de module uitleest is hier het interessante deel, en dat beslecht de vraag meestal in één regel.
De dtb is al die van de SFP, ik heb armada-385-turris-omnia-sfp.dtb gesymlinkt toen ik de stick voor het eerst plaatste, anders kwam er helemaal niets op. De cage bezit eth2 en de koperen WAN blijft losgekoppeld.
dmesg | grep -i sfp toont de module als geïdentificeerd en dan dezelfde regel die ik gepost heb, eth2 switched to inband/1000base-x link mode. Nergens iets over 2500. ethtool eth2 meldt 1000baseX/Full terwijl de link up is en verkeer verwerkt, en ethtool -s eth2 speed 2500 komt nog steeds terug met Invalid argument, dus het adverteert 2500 helemaal niet. De snelheid via telnet in de stick instellen gedraagt zich als voorheen, hij accepteert het en valt daarna terug op 1Gbps.
Verwant verhaal van hetzelfde board, voor het geval iemand hier terechtkomt met een stick die helemaal niet opkomt in plaats van een die op 1G vastzit. HALNy HL-GSFP in een Omnia op Turris OS HBS 6.2.4: de kernel identificeerde hem, de poort schakelde zelfs over naar inband/1000base-x, en toen viel de link weg en kwam eth2 nooit meer op.
Dat is geen EEPROM-probleem. Er zit een heel klein OS in die stick, en dat wil ongeveer een minuut voor zichzelf hebben voor het in enige staat is om de host te antwoorden. Bij een koude start heeft de router de cage al geprobed en opgegeven ruim voor dat moment, dus valt de poort terug op de koperen magnetics. De U-Boot-vertraging verlengen loste het hier op:
Standaard is 3 seconden; op 60 is de stick klaar met opkomen tegen de tijd dat de kernel aan het proben van de cage toekomt. De koperen WAN loskoppelen en een tweede keer rebooten hielp ook bij de detectie. En als je ooit in een stick moet kijken, de seriële poort staat op 38400 8N1.
Eens met de diagnose, met één kanttekening voor iedereen die hier met een vergelijkbaar symptoom terechtkomt. Niet elke "doet geen 2,5G" op dit board is de module. Er was een OpenWrt-snapshot waarin de generieke phylink-validate-code werd teruggeport, en dat brak de Omnia-cage ronduit: ethtool adverteerde nog steeds 2500baseX/Full maar meldde Link detected: no. Die backport terugdraaien zette de poort terug zoals hij was, ethtool las Link detected: yes, 2500Mb/s full duplex, en een latere pull request loste de backport upstream op.
Het teken zit in wat ethtool als supported en advertised vermeldt. Staat daar 2500baseX/Full tussen en weigert de link gewoon op te komen, kijk dan naar de kernel en phylink na je laatste image-upgrade, niet naar de optiek. Als, zoals hier, de poort alleen ooit 1000baseX kent omdat dat is wat de module over zichzelf heeft opgegeven, tovert geen enkele hostsoftware de modus tevoorschijn. Dat is de nominal bit rate-byte in de EEPROM die precies doet wat SFF-8472 voorschrijft.