Turris Omnia refuses an unlocked MA5671A GPON stick: eth2 never comes up on Turris OS 5.0.3
Trying to replace the ISP terminal in my home rack with a GPON stick straight in the router, so the fibre lands in one box instead of two. The stick is recognised, and that is where the good news ends.
- Turris Omnia on Turris OS 5.0.3, stock kernel
- Huawei MA5671A GPON stick with unlocked firmware, set to SGMII 1G
- SC/APC pigtail from the wall socket into the stick
- eth2 is the SFP port
The module is detected but the interface never activates:
# dmesg | grep sfp
SFP module encoding does not support 8b10b nor 64b66beth2 stays down after that, no carrier, nothing in the counters.
What I have tried so far:
- flashing the stick back to stock firmware, which gets me an EEPROM read error instead
- forcing the rate with ethtool -s eth2 1000 autoneg off duplex full, after which the interface sits at 10 Mbit half duplex
- moving the same stick into a MikroTik router, where it does come up once the port speed is set by hand
So the module itself is alive and the fbre side is fine. What is it in the stick that the kernel objects to, and which GPON sticks actually come up on an Omnia rather than being refused?
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 4
This is a host-side problem, not a dead module. The EEPROM in these repurposed GPON sticks declares an encoding that the mainline sfp driver will not map, phylink therefore refuses to bring the port up, and the line you pasted is the driver saying precisely that. Your own evidence points the same way: the identical stick links on a MikroTik once the port speed is set by hand, so the optics and the PON side are fine.
The only thing that moved the needle for me was a kernel new enough to carry the per-module quirks, which on the Omnia meant the HBD testing branch with kernel 5.4. Be warned that this is a partial win and it depends heavily on which stick you have. On that kenel:
So if you want the Omnia working now rather than eventually, the DFP-34G-2C2 is the one I would put in the cage. Test it on your own box before committing, results here clearly vary between sticks and even between firmware revisions of the same one.
Two things worth pinning down before anyone starts guessing. First, which branch is that 5.0.3 from and what kernel does uname report? The per-module SFP quirks that these repurposed GPON sticks need landed later, so a shipped stable kernel and a testing one behave very differently with exactly the same module.
Second, is the ONU serial registered on the provider side? A stick that never gets authorised on the OLT will sit there looking dead, and plenty of providers refuse to register a third-party ONU at all.
And when you plug it in, does the port ever switch to inband/1000base-x, or does the log stop right at that encoding message?
Stable branch, stock kernel for 5.0.3, nothing custom on top. The provider side is not the problem here, it is the same fibre and the stick carries the registered serial.
The log stops at the encoding line, the port never flips to inband/1000base-x. What I get depends on the firmware. With the unlocked one:
plus a transmit fault reported by the module. With stock firmware it does not even get thhat far:
And as said, forcing the rate does nothing at all: after ethtool -s eth2 1000 autoneg off duplex full the interface still sits at 10 Mbit half duplex.
Another failure mode to rule out on the same router, because it looks similar and has nothing to do with the encoding. A HALNy HL-GSFP on Turris OS HBS 6.2.4 was detected, the port even switched to inband/1000base-x, then the link dropped and eth2 stayed down.
Cause: that stick is a small computer in its own right. It spends something like a minute bringing up its own firmware, and only after that does it answer the cage with anything sensible. A cold boot has the router looking into the cage long before that point, so detection fails and the box quietly falls back to the copper WAN magnetics. Lengthening the boot delay fixed it:
Sixty seconds instead of the default three, and someone else with the same stick confirmed it. Two more things that helped: unplug the copper WAN cable and reboot once more, and log into the module itself to see what state it is in, over serial at 38400 8N1 or over SSH on 192.168.77.154 port 22666.