Flint4 Support Now Available in Mainline OpenWrt

Mainline OpenWrt source code support for the Flint4 has been released. The main work was done by 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.

4 Likes

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. :wink:

6 Likes

Hi,

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

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 :slight_smile:

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.

Waiting for upstream PRs :wink:

1 Like

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

Looking forward to this. Will an image be released?

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

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.

5 Likes

Thank you. I’ll keep an eye out :slight_smile:

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?

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 aspackage/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).

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.

1 Like

hostapd: nl80211: nl80211_recv_beacons->nl_recvmsgs failed: -5 appears after I insert the SFP module.

Conclusion: The SFP port is not working.

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.

[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.

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.

1 Like

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