ODI DFP-34X-2C2 in a Turris Omnia links at 1000base-x only, ethtool will not take speed 2500
I swapped the ISP ONU for an ODI DFP-34X-2C2 GPON stick in my Turris Omnia so the fibre terminates in the router instead of another box on the shelf. That part worked: the line is registered, traffic flows, no complaints. The problem is the rate. It never goes above 1Gbps, and 2.5G was the whole reason I bought this stick.
- Turris Omnia, TurrisOS 6.0.4
- ODI DFP-34X-2C2 GPON stick in the SFP cage, eth2
- copper WAN unplugged, the cage owns the port
What the kernel says after a boot, and what happens when I try to push the rate:
# dmesg | grep mvneta
eth2: switched to inband/1000base-x link mode
# ethtool -s eth2 speed 2500
Invalid argumentethtool eth2 with the link up shows the module as 1000baseX/Full and nothing higher, and the refusal above is ethtool telling me that speed 2500 cannot be advertised.
Tried so far:
- telnet into the stick and set the rate from its own shell; it takes the command and then comes back at 1Gbps
- reboots with and without the copper WAN attached
- looked through dmesg for anything about the MAC being offered 2.5G, there is nothing
Is this the router capping the port, or the module itself? And is there anything host-side that gets eth2 to come up at 2500base-x with this stick?
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
The ceiling here is the module itself, not the Omnia.
What the host negotiates against is what the module's EEPROM declares it can do, because at probe time that chip is the only thing the cage has to go on. On that stick it is coded for 1000Mbps. So the port is set up as inband/1000base-x, there is no 2500base-x mode for phylink to offer, and ethtool refuses speed 2500 because there is nothing to advertise it with. No host-side switch gets around that: ethtool can only ask for modes the port was told exist. The shell inside the stick configures the PON side of the module, not what the cage advertises towards the MAC, which is exactly why your telnet change evaporates and you land back on 1Gbps.
That leaves two real options: have the module re-coded so it advertises 2.5G, or replace it with one that already does. If you go the re-coding route, keep a spare on the desk. You are rewriting the identity page the host trusts, and a wrong byte there gets you a module the cage stops recognising altogether. Also keep the two rates apart in your head, what the PON side delivers and what the SFP-to-MAC link negotiates are separate numbers, so work out what you actually gain before spending money on this.
Before blaming the stick, check which device tree the box boots. The cage on an Omnia is not an extra interface: it and the metallic WAN half are two front ends onto one and the same eth2, and only one of them is connected through to the MAC at a time. Which one that is comes down to the dtb the kernel loads at boot. So look at what /boot/dtb points at: if it is not armada-385-turris-omnia-sfp.dtb, you are staring at the copper side and the numbers mean nothing.
Also post the full dmesg | grep -i sfp, not just the mvneta line. What the kernel reads out of the module at probe time is the interesting part here, and it usually settles the question in one line.
The dtb is already the SFP one, I symlinked armada-385-turris-omnia-sfp.dtb when I first put the stick in, otherwise nothing came up at all. The cage owns eth2 and the copper WAN stays unplugged.
dmesg | grep -i sfp shows the module identified and then the same line I posted, eth2 switched to inband/1000base-x link mode. Nothing about 2500 anywhere. ethtool eth2 reports 1000baseX/Full while the link is up and passing traffic, and ethtool -s eth2 speed 2500 still comes back with Invalid argument, so it will not advertise 2500 at all. Setting the rate over telnet inside the stick behaves the same as before, it accepts it and then falls back to 1Gbps.
Adjacent story from the same board, in case someone lands here with a stick that will not come up at all rather than one stuck at 1G. HALNy HL-GSFP in an Omnia on Turris OS HBS 6.2.4: the kernel identified it, the port even switched to inband/1000base-x, and then the link dropped and eth2 never came up.
That one is not an EEPROM problem. There is a whole little OS living inside that stick, and it wants about a minute to itself before it is in any state to answer the host. On a cold start the router has probed the cage and given up long before that point, so the pot goes back to the copper magnetics. Lengthening the U-Boot delay fixed it here:
Default is 3 seconds; at 60 the stick has finihed coming up by the time the kernel gets round to probing the cage. Unplugging the copper WAN and rebooting a second time helped detection as well. And if you ever need to look inside a stick, serial on it is 38400 8N1.
Agreed on the diagnosis, with one caveat for anyone who arrives here with a similar symptom. Not every "it will not do 2.5G" on this board is the module. There was an OpenWrt snapshot where the generic phylink validate code got backported, and it broke the Omnia cage outright: ethtool still advertised 2500baseX/Full but reported Link detected: no. Reverting that backport put the port back where it had been, ethtool reading Link detected: yes, 2500Mb/s full duplex, and a later pull request sorted the backport out upstream.
The tell is in what ethtool lists as supported and advertised. If 2500baseX/Full is in there and the link simply refuses to come up, look at the kernel and phylink after your last image upgrade, not at the optic. If, as here, the port only ever knows 1000baseX because that is what the module declared about itself, no host software will conjure the mode. That is the nominal bit rate byte in the EEPROM doing exactly what SFF-8472 says it should.