GPON stick DFP-34X-2C2 shows up in dmesg only after tens of seconds and then links at 1G
I am replacing the operator ONT with an SFP GPON stick on the Linux box that terminates our WAN, and the stick behaves nothing like a transceiver. Push it in and the cage stays silent for half a minute or more, long enough that I twice assumed the module was dead, and when the kernel finaally does notice it the link settles at gigabit speed, which defeats the point of the exercise.
The bench:
- Linux router box, SFP cage driven by the kernel SFP layer, mainline kernel
- ODI DFP-34X-2C2 GPON stick
- a Huawei MA5671a stick as a second sample
- an ordinary 1G fibre module that appears instantly in the same cage, so the cage itself is fine
$ dmesg | grep -E 'sfp|Link is'
[ 77.104] sfp sfp-p0: module ODI DFP-34X-2C2 rev sn dc
[ 79.610] eth1: Link is Up - 1Gbps/Full - flow control offTried so far:
- reseating the stick and leaving it alone for several minutes bfore touching the interface, and the wait is there every time, not just on the first insertion
- bouncing the interface after detection, which changes nothing about the negotiated mode
- the MA5671a shows the same slow appearance, so it is not one bad sample
Is this simply how GPON sticks behave on a Linux host, or is my side doing something wrong? What is actually going on between insertion and detection here?
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 7
Before the guessing starts, two things worth pinning down. First, post the untrimmed dmesg from insertion onwards instead of a two-line grep. You say the cage sits behind the kernel SFP layer and I have no reason to doubt it, but the lines you filtered out are the ones that show how many times the module was probed, what gave up in between and how long each attempt took.
Second, what does the interface itself claim it can do once the stick is finally up, and does 2500baseX appear anywhere in the advertised modes? And what speed is the ISP handing you on the PON side, since if that is a gigabit plan then the link you are getting is the correct one and there is nothing to fix.
Expected behaviour, unfortunately, and it is not your host.
A GPON stick is not a transceiver with an EEPROM chip in it. It is a small Linux computter on its own SoC, squeezed into an SFP shell, and the EEPROM your host reads over I2C is emulated by that system. Nothing answers on the bus until the stick's own firmware has booted far enough to serve those pages, which is why you sit there for tens of seconds while a normal module answers immediately. That silence before your module line is the boot.
The second half of your problem is that what the emulated pages advertise is frequently just wrong. The host-side interface on these sticks is 2500BASE-X, and the EEPROM says something else, so the SFP layer takes it at face value and settles on the gigabit mode. Both halves are dealt with in the kernel with per-module quirks rather than anything you can configure, and the OEM DFP-34X-2C2 picked up one of those quirks for precisely this reason.
Whether your sample lands on it depends on the vendor and part strings it reports, and those differ between rebadges, so compare what your dmesg line prints against what the quirk matches before assuming you are covered.
To underline why the quirk approach is needed at all: SFF-8472 assumes a passive memory device that answers within ordinary I2C timings. Nothing in it contemplates a device that needs half a minute of boot before it can talk, so a host that follows the standard has every right to give up on the module or to trust the mode bits it eventually reads.
The rebadge point above is the practical trap. Matching is on the vendor and part strings, so the same physical stick sold under a different name misses the quirk entirely and you are back to a gigabit link with no obvious reason. And do not build anything that depends on the module being present shortly after boot, because that race is unwinnable here.
Hoping the stick vendors fix their EEPROM contents is optimistic too. When these problems were raised, even large ISPs got very little back from them.
Same class of problem turns up on consumer routers, so at least you are in company. Owners of the Archer BE800, BE900 and GE800 with a stick in the 10G SFP+ combo port get 1 Gbit/s instead of the 2.5 they pay for, and TP-Link's own list of sticks reported to work in those ports is the ODI DFP-34X-2C2, the Huawei MA5671A and the Nokia G-010SA, which is the same short list of parts everyone ends up with.
First-line advice there was firmware plus reseating, and the reseating part is not nonsense, a module that has not clicked all the way home really does fall back. Beta builds eventually exposed port configuration, one per model:
With one of those on the box the SFP port mode becomes settable over telnet, interface dropped first,
ip link set eth1 downand so on.Still a workaround and not a fix, mind. A year down the line the same complaints were coming in, and not only about sticks: one person had a JT-AOC-SFP-15 AOC from JT-COM in that port, another a passive 10G SFP+ DAC from Ampcom, and both of them sat at 1 Gbit/s.
Worth knowing the other failure mode before anyone suggests moving the stick onto a NIC. On OpenWrt 19.07 on x86 with an Intel X520 and kmod-ixgbe, an MA5671a is simply refused as an unsupported SFP. Setting allow_unsupported_sfp through the usual module config files does nothing at all there, the parameter has to be given when the module is loaded:
And even with that the driver still rejects it, because the stick's EEPROM does not describe a normal transceiver in the first place and the flag cannot paper over that. If you do end up on a NIC, prove the port with an ordinary 1000BASE-T, LX or SX module first, otherwise you are debugging the card and the stick at the same time.
Careful not to run those two together though. allow_unsupported_sfp lives inside ixgbe and decides whether that driver is willing to drive a given optic at all, which is a different decision from the one being made here. The long wait and the wrong mode come from the generic SFP layer reading the emulated pages and handing the result up to phylink, and that is where the per-module quirks sit.
On a board with a proper SFP cage the ixgbe flag does not exist and is not the fix, and on an X520 the quirk list will not rescue you either. Same symptom on the surface, different layer underneath, and mixing them up is how people end up rebuilding drivers for nothing.
One more boundary worth drawing while you are at it: getting the host to see the stick and getting the OLT to accept it are independent problems, and the second one can be far worse.
There is a well documented case of a Xicom DFP-34X-2C2 loaded with the identity copied off a ZTE ZXHN F601 with setmac and OMCI queries, GPON serial, PLOAM password, LOID, hardware serial and firmware string, all of it. The stick ranges to O5 state and then just sits there, no ONU ID assigned and no traffic, because reaching O5 only means ranging worked while the MIB upload still has to match the ONT profile the OLT expects. Nobody in that thread produced a fix.
So when you do get 2500BASE-X locally, do not assume the hard part is behind you. Where the operator ties a service profile to one specific ONT model, there may be no set of copied fields that gets a third-party stick accepted.