# Flint4 Support Now Available in Mainline OpenWrt

**URL:** <https://forum.gl-inet.com/t/flint4-support-now-available-in-mainline-openwrt/71154>\
**Category:** Router\
**Created:** [September 9, 2026, 1:40am UTC](https://forum.gl-inet.com/t/flint4-support-now-available-in-mainline-openwrt/71154 "2026-09-09T01:40:27Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![shi05275](https://forum-assets.gl-inet.com/user_avatar/forum.gl-inet.com/shi05275/32/36932_2.png) [@shi05275](https://forum.gl-inet.com/u/shi05275)\
**Post date:** [September 9, 2026, 1:40am UTC](https://forum.gl-inet.com/t/flint4-support-now-available-in-mainline-openwrt/71154/1 "2026-09-09T01:40:27Z")

</div>

> **[GitHub - JiaY-shi/openwrt at flint4-support](https://github.com/JiaY-shi/openwrt/tree/flint4-support)**
>
> This repository is a mirror of https://git.openwrt.org/openwrt/openwrt.git It is for reference only and is not active for check-ins. We will continue to accept Pull Requests here. They will be mer...

Mainline OpenWrt source code support for the Flint4 has been released. The main work was done by [blogic](https://github.com/blogic), with some additional contributions from me. At present, all features of the Flint4 are working properly, including the touchscreen (the display program also comes from blogic). Since I do not have 10G Ethernet equipment or optical modules, I was unable to test these two aspects. Everyone is welcome to test and use it.

---

<div class="post-metadata">

**Author:** ![will.qiu](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/w/b38774/32.png) [@will.qiu](https://forum.gl-inet.com/u/will.qiu)\
**Post date:** [September 9, 2026, 1:55am UTC](https://forum.gl-inet.com/t/flint4-support-now-available-in-mainline-openwrt/71154/2 "2026-09-09T01:55:49Z")

</div>

Hi,

Thanks for sharing this, and thanks to you and blogic for the work.

We recently published Flint 4 support in our OpenWrt 25.12 branch as well. 😉

> **[GitHub - gl-inet/gl-openwrt: This repository is a mirror of...](https://github.com/gl-inet/gl-openwrt/tree/openwrt-25.12)**
>
> openwrt-25.12

---

<div class="post-metadata">

**Author:** ![xize11](https://forum-assets.gl-inet.com/user_avatar/forum.gl-inet.com/xize11/32/5340_2.png) [@xize11](https://forum.gl-inet.com/u/xize11)\
**Post date:** [September 9, 2026, 1:28pm UTC](https://forum.gl-inet.com/t/flint4-support-now-available-in-mainline-openwrt/71154/4 "2026-09-09T13:28:42Z")

</div>

Hi,

I just tried a very limited config for jenkins like here:

> <https://gist.github.com/xize/ef507f18852cba77ba4031fcb6f04134>

But I did not used make menuconfig to verify, just injecting packages and hope it works.

Compiling works, but flashing fails, I think I just need to check the menuconfig.

Is the ubootmod variant needed as sysupgrade?

edit:

~~yup I figured it was obvious the `make menuconfig` showed ubootmod I was using the normal sysupgrade so I need to adjust my jenkins config 🙂~~

No it is not U-boot mod atleast in luci I get a dangerous message the partition layout is different, went back to normal sysupgrade and fixed diffconfig but to me it doesn't work, also tried plugging cable in the 1gb ports but to no avail.

---

<div class="post-metadata">

**Author:** ![eseiker](https://forum-assets.gl-inet.com/user_avatar/forum.gl-inet.com/eseiker/32/29871_2.png) [@eseiker](https://forum.gl-inet.com/u/eseiker)\
**Post date:** [September 10, 2026, 2:09am UTC](https://forum.gl-inet.com/t/flint4-support-now-available-in-mainline-openwrt/71154/6 "2026-09-10T02:09:38Z")

</div>

Waiting for upstream PRs 😉

---

<div class="post-metadata">

**Author:** ![nilanka](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/n/e274bd/32.png) [@nilanka](https://forum.gl-inet.com/u/nilanka)\
**Post date:** [September 11, 2026, 1:35am UTC](https://forum.gl-inet.com/t/flint4-support-now-available-in-mainline-openwrt/71154/7 "2026-09-11T01:35:15Z")

</div>

Does this mean that the 10G ports, optical and RJ45 should be working?

---

<div class="post-metadata">

**Author:** ![nilanka](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/n/e274bd/32.png) [@nilanka](https://forum.gl-inet.com/u/nilanka)\
**Post date:** [September 11, 2026, 1:35am UTC](https://forum.gl-inet.com/t/flint4-support-now-available-in-mainline-openwrt/71154/8 "2026-09-11T01:35:20Z")

</div>

Looking forward to this. Will an image be released?

---

<div class="post-metadata">

**Author:** ![will.qiu](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/w/b38774/32.png) [@will.qiu](https://forum.gl-inet.com/u/will.qiu)\
**Post date:** [September 11, 2026, 3:15am UTC](https://forum.gl-inet.com/t/flint4-support-now-available-in-mainline-openwrt/71154/11 "2026-09-11T03:15:19Z")

</div>

> [@nilanka](#):
>
> Does this mean that the 10G ports, optical and RJ45 should be working?

We have conducted some initial internal testing with several SFP+ modules, and yes, they are working properly. The 10G RJ45 port is also working.

> [@nilanka](#):
>
> Looking forward to this. Will an image be released?

If you mean a vanilla OpenWrt image, we first need to complete the pull request and wait for it to be accepted upstream. The OpenWrt team would then be responsible for releasing the image.

If you mean the GL.iNet SDK firmware based on OpenWrt 25 for Flint 4, it is still under development, but we expect it to be available relatively soon.

---

<div class="post-metadata">

**Author:** ![nilanka](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/n/e274bd/32.png) [@nilanka](https://forum.gl-inet.com/u/nilanka)\
**Post date:** [September 11, 2026, 1:00pm UTC](https://forum.gl-inet.com/t/flint4-support-now-available-in-mainline-openwrt/71154/12 "2026-09-11T13:00:59Z")

</div>

Thank you. I’ll keep an eye out 🙂

---

<div class="post-metadata">

**Author:** ![nilanka](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/n/e274bd/32.png) [@nilanka](https://forum.gl-inet.com/u/nilanka)\
**Post date:** [September 11, 2026, 5:53pm UTC](https://forum.gl-inet.com/t/flint4-support-now-available-in-mainline-openwrt/71154/13 "2026-09-11T17:53:13Z")

</div>

I tired the build from the GL iNet tree. It went well SFP+ ports and eth are working. I have some trouble setting up MLO though

A `wifi-iface` with `option mlo '1'`, `option device 'radio1'` and `list radios 'radio1' 'radio2'` produces `ap-mld0` with `radio mask: 2` only; a second section on `radio2` sharing `ifname ap-mld0` gives mask 4 (last one wins); `mlo '1'` on both normal interfaces gives two one-link MLDs (`ap-mld0`, `ap-mld1`). `strings /sbin/netifd` shows no `mlo`/`radios`, and nothing on the image calls `hostapd mld_set`, so hostapd never receives a group definition with both radios. Calling `mld_set` by hand with `"radios":[1,2]` is accepted but the links get re-processed before the group has an address ("Skip MLD interface phy0.2").

Is the netifd side of MLO missing from this tree, or is there a config shape I am missing?

---

<div class="post-metadata">

**Author:** ![nilanka](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/n/e274bd/32.png) [@nilanka](https://forum.gl-inet.com/u/nilanka)\
**Post date:** [September 14, 2026, 2:18pm UTC](https://forum.gl-inet.com/t/flint4-support-now-available-in-mainline-openwrt/71154/15 "2026-09-14T14:18:49Z")

</div>

Follow-up / solved. On the `gl-openwrt` `openwrt-25.12` build for the BE14000, two-link AP MLD now works; what was missing was config syntax (not netifd):

- The radios go into `device` **as a list** : `list device 'radio1'` + `list device 'radio2'` on ONE `wifi-iface` with `option mlo '1'`, `encryption sae`, `ieee80211w 2`. (`option device 'radio1'` + `list radios …` yields a one-radio MLD — mask 2/4; the `radios` schema option is unused.) → `Set MLD config: ["ap-mld0"]`, `Create MLD interface ap-mld0 … radio mask: 6`.

- Use **fixed channels** on both radios; with `channel auto` the two links’ ACS scans collide (“ACS in progress in a partner link”, `-16 Resource busy`) and one link is disabled, reported `https://github.com/openwrt/openwrt/issues/25181`.

- The pinned mt76 (2026-07-01) **oopses when an MLO client associates** (openwrt/mt76 #1109, `skb_pull` in `mt7996_mcu_rx_event`). Applying the #1105 diff as`package/kernel/mt76/patches/900-*.patch` fixes it; a straight mt76 bump doesn’t build against the tree’s mac80211 (`ieee80211_get_fils_discovery_tmpl`). PR opened on gl-openwrt: `https://github.com/gl-inet/gl-openwrt/pull/1` (and `https://github.com/gl-inet/gl-openwrt/pull/2` for the panel’s touch controller driver, which the tree also lacks).

---

<div class="post-metadata">

**Author:** ![will.qiu](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/w/b38774/32.png) [@will.qiu](https://forum.gl-inet.com/u/will.qiu)\
**Post date:** [September 15, 2026, 9:34am UTC](https://forum.gl-inet.com/t/flint4-support-now-available-in-mainline-openwrt/71154/16 "2026-09-15T09:34:43Z")

</div>

Hi,

Thanks for the detailed follow-up, testing, and analysis.

We’ll ask our R&D team to review the reported issues and the submitted PRs, and determine the appropriate way to handle the changes.

---

<div class="post-metadata">

**Author:** ![skarpinis](https://forum-assets.gl-inet.com/user_avatar/forum.gl-inet.com/skarpinis/32/37520_2.png) [@skarpinis](https://forum.gl-inet.com/u/skarpinis)\
**Post date:** [September 22, 2026, 9:10am UTC](https://forum.gl-inet.com/t/flint4-support-now-available-in-mainline-openwrt/71154/17 "2026-09-22T09:10:24Z")

</div>

hostapd: nl80211: nl80211\_recv\_beacons-\>nl\_recvmsgs failed: -5 appears after I insert the SFP module.

Conclusion: The SFP port is not working.

---

<div class="post-metadata">

**Author:** ![AI\_bot](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/a/ecccb3/32.png) [@AI\_bot](https://forum.gl-inet.com/u/AI_bot)\
**Post date:** [September 22, 2026, 9:10am UTC](https://forum.gl-inet.com/t/flint4-support-now-available-in-mainline-openwrt/71154/18 "2026-09-22T09:10:51Z")

</div>

The `hostapd: nl80211... -5` message is related to the Wi-Fi control path and, by itself, does not prove that the SFP port has failed. Please test the SFP interface directly:

1. Insert the module and check the router’s kernel log with `logread -f` (or `dmesg -w`).
2. Identify the SFP network interface with `ip link`, then run `ethtool <interface>` and check whether it reports `Link detected: yes`, along with the negotiated speed.
3. Please share the exact OpenWrt image/build and SFP module model, plus the short `ethtool` result. This will distinguish a physical/module compatibility issue from a Wi-Fi-related log message.

> **This reply was generated by AI. Please verify its accuracy.**
> 
> GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.

---

<div class="post-metadata">

**Author:** ![skarpinis](https://forum-assets.gl-inet.com/user_avatar/forum.gl-inet.com/skarpinis/32/37520_2.png) [@skarpinis](https://forum.gl-inet.com/u/skarpinis)\
**Post date:** [September 22, 2026, 2:13pm UTC](https://forum.gl-inet.com/t/flint4-support-now-available-in-mainline-openwrt/71154/19 "2026-09-22T14:13:58Z")

</div>

[22 Sept 2026, 11:32:14 UTC] kern.info: [8588.420786] sfp sfp: module OEM SFP-10G-T rev B sn 2606170390 dc 260617  
[22 Sept 2026, 11:32:14 UTC] kern.info: [8588.479704] hwmon hwmon6: temp1\_input not attached to any thermal zone

[8884.275317] sfp sfp: mdiobus scan returned -EIO

Nothing else. The port is completely unresponsive, but it works just fine with the stock firmware.

---

<div class="post-metadata">

**Author:** ![nilanka](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/n/e274bd/32.png) [@nilanka](https://forum.gl-inet.com/u/nilanka)\
**Post date:** [September 23, 2026, 11:16am UTC](https://forum.gl-inet.com/t/flint4-support-now-available-in-mainline-openwrt/71154/20 "2026-09-23T11:16:59Z")

</div>

which fork did you build from? I remember blogic’s one.

If your SFP port shows link up but never receives anything (rx\_packets stays 0, ONT never answers ARP/DHCP, ethtool -m sfp says not supported), check whether your image includes kmod-sfp and kmod-i2c-gpio. The BE14000 recipe in the JiaY-shi/blogic fork omited both (PRs have been made so the fork has the fixes); GL.iNet’s recipe has them. Without the SFP core the cage device never binds and the module is never configured, and without i2c-gpio the bit-banged I2C bus for the module EEPROM does not exist. It cannot be fixed by loading modules on a running image because the kernel’s PHY library is built without SFP support, so rebuild with CONFIG\_PACKAGE\_kmod-sfp=y and CONFIG\_PACKAGE\_kmod-i2c-gpio=y and reflash. On mine the module was detected at boot and WAN came up immediately after that. Optionally also add the two SFP rate-select GPIOs from GL’s DTS (pio 83 and 80). Reported on blogic/openwrt PR #4 on 16 Sept, not yet merged.

---

<div class="post-metadata">

**Author:** ![skarpinis](https://forum-assets.gl-inet.com/user_avatar/forum.gl-inet.com/skarpinis/32/37520_2.png) [@skarpinis](https://forum.gl-inet.com/u/skarpinis)\
**Post date:** [September 23, 2026, 2:01pm UTC](https://forum.gl-inet.com/t/flint4-support-now-available-in-mainline-openwrt/71154/21 "2026-09-23T14:01:06Z")

</div>

Yep, after I built from the latest commits in the flint4-support fork, SFP started working. 🙂

---

<div class="post-metadata">

**Author:** ![g2w09fyl8](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/g/9dc877/32.png) [@g2w09fyl8](https://forum.gl-inet.com/u/g2w09fyl8)\
**Post date:** [October 16, 2026, 7:15am UTC](https://forum.gl-inet.com/t/flint4-support-now-available-in-mainline-openwrt/71154/22 "2026-10-16T07:15:19Z")

</div>

Hello there,

I was lurking on this topic since few days, and I did compile and test both fork (official GL.iNet one and JiaY-shi one).

Both boot fine, and report in dmesg that:  
`sfp sfp: Host maximum power 3.0W`

so that should be enough for the WAS-110 ONU SFP+ stick ( [WAS-110 - PON dot WIKI](https://pon.wiki/xgs-pon/ont/bfw-solutions/was-110/) ).

But, in both case, when plugging the said module, I get:  
`[88.675197] sfp sfp: module FiberMall XGSPON-ONU-STICK rev V1.0 sn MT253160154 dc 250703`  
`[89.049374] sfp sfp: module transmit fault indicated`  
`[91.647042] sfp sfp: module transmit fault indicated`  
`[94.092779] sfp sfp: module transmit fault recovered`  
`[94.097783] sfp sfp: module transmit fault indicated`  
`[96.789377] sfp sfp: module persistently indicates fault, disabling`

To compare, I did test it on the Banana Pi R4 Pro 8X, which is now officially supported on OpenWRT snapshot, and the stick was detected properly and was working fine.

Since the Banana Pi is also rocking the same Filogic SoC as the Flint 4, I'm holding hope.

I also tested this stick on the Altalabs Route 10 router, with an unofficial openwrt support branch pending MR on upstream, but the stick was never detected, but since dmesg reported that the SFP cage was only supporting 1W, it was not a surprise.

On a side note, I noticed that JiaY-shi fork doesn't do anything visible to the screen, which stays pitch black, but the GL.iNet fork seems to at least partially initialized the screen, which show a tiny vertical white line on the bottom left corner of the screen.

I hope you'll have an idea on this, or at least commands I can issue to help you debug this.

Kind regards,

---

<div class="post-metadata">

**Author:** ![shi05275](https://forum-assets.gl-inet.com/user_avatar/forum.gl-inet.com/shi05275/32/36932_2.png) [@shi05275](https://forum.gl-inet.com/u/shi05275)\
**Post date:** [October 16, 2026, 8:46am UTC](https://forum.gl-inet.com/t/flint4-support-now-available-in-mainline-openwrt/71154/23 "2026-10-16T08:46:30Z")

</div>

Are you using the latest code branch? I don't have an SFP device myself, but many people have reported that SFP works fine. As for the screen issue you mentioned, you'll need to add the feed: `https://github.com/blogic/feed-blogic.git`.

---

<div class="post-metadata">

**Author:** ![g2w09fyl8](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/g/9dc877/32.png) [@g2w09fyl8](https://forum.gl-inet.com/u/g2w09fyl8)\
**Post date:** [October 17, 2026, 6:57am UTC](https://forum.gl-inet.com/t/flint4-support-now-available-in-mainline-openwrt/71154/24 "2026-10-17T06:57:40Z")

</div>

Yes, for the JiaY-shi (you ? :p) fork, I'm using the flint4-support branch, commit 6b930c7, and for the GL.iNet fork, I'm using openwrt-25.12 branch, commit b5e7466.

However, before flashing these forks, I did try to use the latest "stock" beta firmware, and the stick seemed to be recognized in the default web interface (I'm sorry, I didn't take a look at dmesg at this moment).

Despite this support, I needed to switch to "pure" OpenWRT because the default stock kernel didn't support egress netfilter hook (`CONFIG_NETFILTER_EGRESS`) which is needed in my case: I need to tag outgoing (WAN) DHCP packages to the highest priority, while leaving all the other traffic untouched (with this ONU stick, I'm in the process of bypassing my ISP hardware).

The default OpenWRT kernel does support egress filter, as I saw in the Banana Pi R4 Pro 8x (official support in SNAPSHOT).

Don't hesitate to ask me for commands outputs to try to debug it since you don't have such SFP+ harware

---

<div class="post-metadata">

**Author:** ![g2w09fyl8](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/g/9dc877/32.png) [@g2w09fyl8](https://forum.gl-inet.com/u/g2w09fyl8)\
**Post date:** [October 17, 2026, 10:52pm UTC](https://forum.gl-inet.com/t/flint4-support-now-available-in-mainline-openwrt/71154/25 "2026-10-17T22:52:00Z")

</div>

I just tried the beta 4 firmware and the WAS-110 ONU seems to be properly recognized:  
`root@OpenWrt:~# dmesg |grep -i sfp`  
`[0.780378] sfp sfp: Host maximum power 3.0W`  
`[0.784702] sfp sfp: tx disable 1 -> 1`  
`[0.788464] sfp sfp: SM: enter empty:detached:down event insert`  
`[0.794387] sfp sfp: SM: exit probe:detached:down`  
`[0.799410] sfp sfp: tx disable 1 -> 0`  
`[0.803177] sfp sfp: SM: enter probe:detached:down event timeout`  
`[0.844968] sfp sfp: module FiberMall XGSPON-ONU-STICK rev V1.0 sn MT253160154 dc 250703`  
`[0.854285] sfp sfp: SM: exit waitdev:detached:down`  
`[7.302271] yt92xx: SFP notify br_nominal=100 ext=0x00 dac=0 copper=0 -> speed=5`  
`[7.313256] yt92xx: P4 SFP apply 10G-force path`  
`[7.317797] yt92xx: SFP callbacks registered (minimal single-path)`  
`[7.327536] yt92xx: P4 SFP apply 10G-force path`  
`[7.836661] yt92xx yt92xx.0: eth1.2(port 4, sfp) link up, speed 10Gbps`

Theese yt92xx lines aren't present on both of the "pure" OpenWRT firmware described in this thread.

It seems the SFP+ cage isn't properly initialized on these forks.

So, right now, the beta 4 firmware allow me to advance a little further on my quest to replace my ISP box, but since its kernel don't support `CONFIG_NETFILTER_EGRESS`I still can't use it.

I would prefer run pure OpenWRT on the Flint 4, but the hardware doesn't seem to be initialized properly for now.

@will.qiu or @shi05275, let me know if I can test anything else that could to help you debug the problem and fix your forks on this specific matter.

Any help would be appreciated.

[Next page](https://forum.gl-inet.com/t/flint4-support-now-available-in-mainline-openwrt/71154.md?page=2)
