Flint 4 4.9.1: SFP+ module detected but port 4 remains waitdev:detached:down

HRTFreeman · September 2, 2026, 1:32am

Hoping someone has got the SFP+ port on a Flint 4 working, or can tell me what it is expected to support.

Setup: GL-BE14000, firmware 4.9.1 . XGS-PON fibre (8 Gbps symmetric, DS-Lite). The ISP's gateway terminates fibre in a removable SFP+ ONU module , so the natural move is to put that module into the Flint's SFP+ cage and drop the ISP router from the path.

The problem: the cage detects the module, reads its EEPROM, reports no receive LOS with a live fibre, and selects a 10G host path — and then the switch port never links. Every port-4 counter stays at zero.

sfp sfp@0: module <vendor/part> rev V1.0 sn [omitted] dc 230110
yt92xx: SFP notify br_nominal=99 ext=0x00 -> speed=5
yt92xx: P4 SFP apply 10G-force path
sfp sfp@0: SM: exit waitdev:detached:down
Module state:       waitdev
Device state:       detached
Main state:         down
moddef0:            1
rx_los:             0        (during the live-fibre control test)
tx_fault:           0
tx_disable:         1
switch0 port 4:     enabled, link down
Port 4 RX counters: all zero
Port 4 TX counters: all zero

Tested ONU modules (serials omitted):

MNC MPOS22-LDCE-T2

SourceDoing 1325-00051, rev V1.0

What I think this might mean — and where I need your help:

The combination of waitdev and Device state: detached appears consistent with the SFP bus waiting for its upstream network/phylink device, but I would appreciate confirmation from GL.iNet, because this firmware contains vendor-specific SFP and switch-driver changes and I do not want to misinterpret them.

The SFP debug state also reports tx_disable=1, while the raw TX-disable GPIO reading appeared deasserted. I do not know whether that is active-low interpretation, stale state, or another consequence of the detached upstream device. Which value is authoritative?

Possibly related as a clue only: /etc/board.json exposes an sfp role with "protocol": "none" and no obvious device binding. I understand this may describe GL.iNet UI/default-role configuration rather than the kernel phylink binding.

What I have ruled out, and what remains untested:

Two unrelated XGS-PON ONU modules produce the same host-side result. Both are known-good: they register and carry live 8 Gbps service in the ISP's own gateway, on two different ISPs, and swap freely between those boxes. Both reach waitdev:detached:down, port 4 link down, zero RX/TX counters. That makes a single defective module unlikely.
However, I have not tested a conventional Ethernet SFP+ transceiver or a passive DAC. That remains the most useful control test, and until I run it I cannot rule out a PON-specific host-interface compatibility problem. If anyone has one working in this cage, that would be very useful to know.
Optical control test: with the same module inserted, I moved only the fibre to a second, live ISP line. This generated a real los_low event and changed rx_los from 1 to 0. The driver reapplied P4 SFP apply 10G-force path twice, but the state remained waitdev:detached:down. So the SFP state machine received and reacted to the optical signal transition, yet the upstream Ethernet link never attached.
Board configuration maps the cage to switch0 port 4 through the eth1 CPU trunk. I also tested the intended VLAN configuration, but the VLAN and DHCP layers cannot explain a physical switch port that stays down with every port-4 counter at zero.
Ethernet 1 was switched to a LAN role so SFP+ was the only WAN.
Reasserting eth1 up and port 4 enable_port=1 changed nothing. swconfig, switch, mii_mgr and ethtool are present; none exposes a documented SFP host-mode override. I did not attempt undocumented register writes.

Possibly related: the Ethernet Port page shows WAN/LAN1 as link down while it is connected and working — same as this thread. If switch link-state reporting is unreliable in general, these might be one issue rather than two.

Why it matters practically: the Flint 4 has exactly two 10 G ports — SFP+ and one copper RJ45. With SFP+ unusable I have to choose between a 10 G WAN and 10 G to my workstation, and I cannot remove the ISP router from the path. On an 8 Gbps line doing sustained large-file transfer, that was the reason for this router.

Questions:

Has anyone got the SFP+ port on a Flint 4 to link with any module — ONU stick, Ethernet transceiver, or DAC? If so, which, and on what firmware?
Is switch0 port 4's phylink bound to the SFP cage on 4.9.1? The waitdev state suggests it may not be, but I would rather be told than assume.
Is there a supported way to force the upstream attach, or bring port 4 up, for diagnosis?
Does the SFP+ cage officially support only standard Ethernet SFP+/DAC devices, or are 10G-host-interface XGS-PON ONU sticks expected to work? If the former, that is fair — but it is not documented, and the port is described as WAN-capable.
What electrical host interface does the driver expect from a 10G module — 10GBASE-R / XFI — and does it perform an Ethernet-module compliance check before attaching phylink?
Is speed=5 a private YT92xx enumeration for 10 Gbps, and is br_nominal=99 being interpreted correctly?
Is tx_disable=1 expected while the state is waitdev:detached:down, and why does it differ from the raw GPIO reading?
Could you provide a diagnostic build with SFP/phylink debug enabled, or the relevant DTS / port-4 binding information?

Happy to run any diagnostics or provide full logs.

will.qiu · September 2, 2026, 7:30am

Hi,

Thank you for the detailed report.

Could you please collect the following logs to help us investigate this issue?

Before inserting the ONU stick, run:
```
dmesg -c > /dev/null
```
Insert the ONU stick, wait one minute, and then export the output of:
```
dmesg
```
After the one-minute wait, also run and share the output of:
```
swconfig dev switch0 show
```

Please also export the router logs by following the steps below and send them to us via private message:

How to export logs:

How to send a private message:

Could you also tell us where you purchased each of the two ONU sticks? If possible, please include links to the product pages so that we can confirm the exact hardware variants. It would also be helpful if you could provide photos of the sticks together with their labels.

The current firmware version, v4.9.1, does not yet support DAC cables. We plan to add DAC support in the next firmware version.

xize11 · September 2, 2026, 7:47am

You could be on something here, I do use a sfp+ ethernet copper module and twice I observed a bug where sfp+ starts flapping.

Which ment in my case wan went down, ifconfig reported also a down event, and it came up.

Under normal circumstances this bug would not occur to me, but it did because of the heavy dnsmasq restarts with 10-11 vlans that it came in a unstable state (more in a corner case), a reboot fixed it for me, my wan uses dhcp (iPoE).

I changed cable when it was in this state and it happened again, over the normal 10gb wan port I did not observe this.

About port 4 I seem to also see something occuring which looks like a negotiation problem but I haven't time to check, I don't think wan isn't related to port 4 like that in my case, therefor I think for me this is a different issue.

So did a normal restart solve anything to sfp+?

KryptonKid09 · September 2, 2026, 8:41am

I have one of these working as expected: https://www.fs.com/uk/products/75339.html

My broadband service is up to 1Gb/s so that’s why I chose the 1Gb/s BiDi. I’ve also used it successfully with a Ubiquiti EdgeRouter in the past so thought I’d try it with the Flint 4. The only additional config I needed to do, and again I knew this from previous experience, was to add a VLAN 100 for the SFP port.

HRTFreeman · September 3, 2026, 1:03am

Thanks, this is really useful — it tells me the cage isn't simply dead, which is what I'd started to assume.

Could I ask you to run one command? It would settle something I can't resolve on my own:

cat /sys/kernel/debug/sfp@0

Specifically the Device state: line. Mine reads detached and never changes — even with the cage empty, before any module is inserted. If yours says attached while your module is working, that pins the problem down precisely. If yours also says detached while working fine, then that field is a red herring on this platform and I've been chasing the wrong thing.

Either answer helps enormously, and it takes ten seconds.

Two other things if you don't mind:

Which firmware version are you on?
You mentioned adding a VLAN 100 for the SFP port — did you have to assign the port a role (WAN/LAN) first, or did it attach on its own and the VLAN was purely for your ISP's tagging? I tried creating a netdev on the SFP's switch VLAN here (swconfig shows port 4 in VLAN 2) and it produced no sfp or yt92xx activity at all.

For reference, mine is a 10 G XGS-PON ONU stick rather than an optical Ethernet transceiver, and the driver does read it — yt92xx: SFP notify br_nominal=99 ext=0x00 -> speed=5 then P4 SFP apply 10G-force path — it just never brings the port up. ext=0x00 means no extended compliance code, which is normal for PON ONUs and may well be the difference between your module and mine.

HRTFreeman · September 3, 2026, 1:03am

No — I tried exactly that and it made no difference.

Every previous attempt had been a hot-plug, so I rebooted with the ONU module already seated, on the theory that the driver had never initialised with a module present. Port 4 came up link down with all RX/TX counters at zero, same as hot-insert. No change at all.

What the module itself reports looks completely healthy. From /sys/kernel/debug/sfp@0:

Module state: waitdev Device state: detached

Main state: down Module probe attempts: 0 0

moddef0: 1 rx_los: 0 tx_fault: 0 tx_disable: 0

Module detected, optical receive present, no TX fault, TX not disabled. Everything is fine except that the device state never leaves detached — and it reads detached even with the cage empty, before any module goes in.

On your flapping: mine is the opposite way round to yours. You saw the SFP+ flap while the 10 G copper WAN stayed solid; mine is the 10 G copper WAN (eth2) dropping repeatedly — eight outages totalling ~45 seconds in a 27-minute window, one logged with mtk_soc_eth: usxgmii0: wait link up timeout! — while SFP+ never comes up at all. Probably separate issues, as you say.

Your trigger is interesting though. You mentioned it appeared with heavy dnsmasq restarts across 10–11 VLANs. I run AdGuard Home plus three bridges (br-lan, br-iot, br-guest), so there's more service churn here than a plain config too. Did yours ever flap without a dnsmasq restart nearby, or was that always the trigger?

xize11 · September 3, 2026, 2:46am

This was always a trigger, but it happened having the process doing it repeatily, so it is rare to get this state.

KryptonKid09 · September 3, 2026, 8:31am

Looks like the reporting of the SFP state is erroneous.

I don’t get any stats for it on the ‘Ethernet’ page in the router GUI either. Just the MAC address.

Router firmware is v4.9.1 and the SFP firmware is marked as ‘generic’.

I didn’t need to assign the SFP port to WAN/LAN, once I marked it as VLAN 100, it just worked.

will.qiu · September 3, 2026, 9:31am

Hi,

Thank you for sending the logs via private message. We have forwarded them to our development team for further investigation.

The review may take some time. We’ll let you know once we have an update.

will.qiu · September 4, 2026, 8:59am

Hi,

Thank you for the additional testing and for sharing the detailed results with us via private message.

We are currently trying to contact the module manufacturers to see whether we can obtain the same hardware for internal testing. This will help our development team reproduce the issue and investigate a possible fix.

We’ll let you know when we have any further updates.

KryptonKid09 · September 4, 2026, 10:36am

I included the link above but, this is the specific module I’m using.

https://www.fs.com/uk/products/75339.html

I’d be happy to buy another one and get it sent to you, if you’re not successful in obtaining one directly.

HRTFreeman · September 5, 2026, 10:07pm

Thanks — glad it's reproducible enough to pursue.

Two things that might help. First, I have a spare MNC MPOS22-LDCE-T2 (the second of the two modules I tested — it isn't my ISP's equipment). If sourcing proves difficult, I'm happy to ship it to you for testing; just let me know where to send it.

Second, I've ordered an ipolex SFP-10G-T copper module from your own compatibility list. When it arrives I'll test it in the same cage on the same firmware and report the result — that should give you a clean comparison between a validated Ethernet module and the two PON ONUs on identical hardware.

I'm also happy to run a debug or test build if that would help reproduce it.

will.qiu · September 7, 2026, 8:27am

Thank you both for offering to provide the modules for our testing. We really appreciate your help.

There is no need to send them at this time. We’ll let you know if we need them later.

dawklix · September 14, 2026, 1:39am

I have this stick https://www.alibaba.com/product-detail/Yunvo-10G-XGSPON-ONT-Stick-SC_10000041298376.html

dawklix · September 14, 2026, 1:39am

I have the same issue with YV-XGSPON-STICK

douglasparry · September 16, 2026, 1:58am

Hi, Same / Similar issue. I created a separate topic as it likely effects every ViewQwest customer in Singapore. (That one is more AI Slop, this one is hand-written )

In my case the SFP module has a checksum failure:

A override would be super useful. I have an intel x520 nic, and they have the option within the ixgbe driver ‘allow_unsupported_sfp’ that would log the failure and then continue.

Not a seating issue, SFP module verified good on the network (Currently connected through the same module through the aforementioned x520 nic and virtualised pf-sense).

Happy to assist with testing if required (time permitting)

Firmware V4.9.1

will.qiu · September 16, 2026, 2:17am

Hi,

We noticed that you have created a separate topic for this issue. Let’s continue the discussion there:

will.qiu · September 16, 2026, 2:20am

Hi,

Thank you for sharing the link to the SFP+ ONU module that is experiencing the issue.

When you have a chance, could you please collect the logs using the steps we provided previously? This will help us determine whether you are experiencing the same issue or a different one.