Flint 4 - compatibility with Zyxel PMG3000-D20B

MHofer · September 2, 2026, 11:02am

Hello,

I got my Flint 4 a couple of days ago. I want to use it as my main router and the SFP+ option to connect to my upcoming fiber ISP. As I have a private contract, speed will be limited to 1Gbit. So far that will be more than necessary - in particular when my kids will leave the house.
As I live in Germany, Deutsche Telekom is my ISP. They offer a compatible ONT SFP Stick in their shop: the Zyxel PMG3000-D20B.

Can anyone confirm that this SFP stick will work with the Flint 4 (unfortunately, the list of devices for this scenario is with 2 entries very limited).

Kind regrads,

Mario

PS If FW 4.10 with mesh support is coming, than I will have everything I need for my home network.

KryptonKid09 · September 2, 2026, 12:51pm

I’d imagine the number of users with your same scenario is minute to non-existent. That being the case, I’d try one yourself and see if it works. In my very limited experience, I’d imagine it will. I don’t think it will be plug and play though and some config will be required.

For example, I’m using an FS.com SFP BiDi, with generic FW in my Flint 4 to connect directly to my ISP. I needed to config a VLAN 100 on the SPF port to get it to work.

What I would suggest is that you research to find those using the Zyxel SFP module, with the same ISP you’re using, regardless of what router hardware they used, This will give you an understanding of what config they needed to use, to get it to work. That’s what I did originally and used the same SFP module and config on my previous Ubiquiti EdgeRouter, using information I found of someone using the same module and config with a Unifi UDM.

will.qiu · September 3, 2026, 1:49am

Hi,

Neither we nor any community users have tested the Zyxel PMG3000-D20B, so its compatibility has not yet been confirmed.

For reference, the following page lists modules that have been tested by GL.iNet or community users:

The situation in the broader OpenWrt ecosystem looks promising, as a user has reported that the patch works and has submitted a pull request:

github.com/turris-cz/os-build

omnia-ng: Fix GPON SFP WAN loss after the upstream-SFP rework

hbk ← LorbusChris:fix/omnia-ng-sfp-gpon

opened 03:51AM - 02 Sep 26 UTC

LorbusChris

+128 -0

Since the switch to the upstream SFP subsystem (827dfdf9, first shipped in 9.0.3…), a Turris Omnia NG with a Zyxel PMG3000-D20B GPON module (Deutsche Telekom's standard ONT stick) loses its WAN: after updating from 9.0.0 to 9.1.1 the PPPoE uplink on the SFP cage never comes back, and only a `schnapps` rollback restores connectivity. Two independent bugs, isolated by tracing a failing 9.1.1 boot against a working 9.0.0 one on the same device: 1. **The module PHY's link never reaches the MAC.** This module boots its EEPROM emulation tens of seconds after power up, so its (emulated, I2C 0x56) module PHY is connected long after the netdev was opened. The qca-ssdk glue drives the inner PHY's link only through that PHY's own phylib state machine, which nothing starts on this path — the SFP core then sits in `link_up` (rx_los clear, tx enabled, `eth4: switched to 1000base-x link mode` logged) while the port stays NO-CARRIER indefinitely; `ip link set eth4 down && ip link set eth4 up` recovers it, which is how the fix was pinned down. The first commit makes the port PHY's `read_status` poll the module PHY directly (the phylink-equivalent behaviour), stops a started module PHY on disconnect, no longer hard-fails `config_aneg` while no module is present (phylib treats the error as fatal and halts the port permanently), and reports the tracked link state instead of a constant in the HSL status path. 2. **The sfp platform probe fails silently on roughly half of all boots.** `sfp0` /`sfp1` race the pcal6408 GPIO expanders behind the I2C mux; the loser is left unbound, not deferred, with nothing logged (`sfp_probe()` returns GPIO errors without a message). A later manual `echo sfp0 > /sys/bus/platform/drivers/sfp/bind` always succeeds, so the failure is transient. The second commit adds `dev_err_probe` so the next occurrence names the failing GPIO and errno instead of disappearing; the race itself is left to fix once that errno is known. The third commit gives the PMG3000-D20B the same long-startup quirk as the Alcatel Lucent G-010S-A — its EEPROM emulation appears late and can drop off the bus once while booting. Both bugs are specific to the Omnia NG: the glue only exists because the NSS ethernet driver cannot use phylink (which handles a module appearing after the netdev opened by design), and the probe race comes from the NG's SFP control GPIOs sitting on pcal6408 expanders behind the I2C mux. The two sfp.c patches are generic, though: the module's late EEPROM emulation is exactly openwrt/openwrt#17733 (same stick on a BPI-R4), and silent `sfp_probe` failures hide this class of bug on any platform — both are candidates for mainline, and are only carried here because this is where TurrisOS keeps its ipq95xx kernel patches. **Testing:** on an Omnia NG on a live Telekom GPON line, TurrisOS 9.1.1 with the patched `qca-ssdk.ko` (built in the 9.1.0 buildroot, vermagic-identical): module detected ~62s after boot, port linked within 300ms of detection with no manual intervention, PPPoE up 20s later. Unpatched 9.1.1 on the same device never linked (observed over four instrumented boots, including a 240s watch of `/sys/kernel/debug/sfp0/state` showing the SFP core at `link_up` throughout while the MAC stayed down). The kernel patches apply and compile cleanly; the diagnosability one is untested against a live occurrence of the race by nature. Written with AI assistance; I have reviewed and understand all of it and will answer questions myself.

Could you share the exact purchase link or vendor for this module? We may be able to obtain one for testing.