# Flint 4 OpenWRT vanilla **URL:** \ **Category:** VPN, DNS, Leaks\ **Created:** [September 17, 2026, 6:58pm UTC](https://forum.gl-inet.com/t/flint-4-openwrt-vanilla/71383 "2026-09-17T18:58:18Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![username89](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/u/da6949/32.png) [@username89](https://forum.gl-inet.com/u/username89)\ **Post date:** [September 17, 2026, 6:58pm UTC](https://forum.gl-inet.com/t/flint-4-openwrt-vanilla/71383/1 "2026-09-17T18:58:18Z")
Hey GL.iNet Team, I'm an early bird Flint 4 owner who pre-ordered based on "OpenWrt support" marketing which has since vanished and replaced with Multi WAN support. I have specific questions: 1. Can you identify from serial number whether my unit supports U-Boot web recovery or requires serial console flashing? If not, why is this unknown? 2. Flint 2 allows vanilla OpenWrt via web UI without verification rejection. Flint 4 blocks this from what i have read. Why is firmware access worse on a newer product can you explain this please? 3. What percentage of Flint 4 units succeed with U-Boot web recovery? This should be documented if it's not already. 4. When the Flint 4 appears on the official OpenWrt firmware selector. Will web UI accept vanilla then? 5. If FCC compliance drove this, why are non-US units (Australia) identically locked? Will region-specific firmware come? 6. Will upcoming batches remove signature verification, or is this permanent? Early adopters deserve transparency here. Thanks I appreciate the feedback. ---
**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 17, 2026, 7:35pm UTC](https://forum.gl-inet.com/t/flint-4-openwrt-vanilla/71383/3 "2026-09-17T19:35:09Z")
> [@username89](#): > > Can you identify from serial number whether my unit supports U-Boot web recovery or requires serial console flashing? If not, why is this unknown? It works with U-boot web ui đź‘Ť > [@username89](#): > > Flint 2 allows vanilla OpenWrt via web UI without verification rejection. Flint 4 blocks this from what i have read. Why is firmware access worse on a newer product can you explain this please? I think from what I readed in various forks of OpenWrt core developers and contributers, it was primarily a issue with the motorcom drivers the 10gb ethernet port and sfp, the flint 4 has two separate internal switches one from motocom, initially there was some talk of support for motorcom by upstream linux but this version was different. Then someone posted a link to the leaked source and license, I don't know if they worked on this driver source or the now released GL-iNet drivers (between you and me I don't think this is that important). Now GL-iNet is releasing their drivers, but there is also some porting being done either way support for OpenWrt is almost done. GL-iNet repo: > **[GitHub - gl-inet/gl-openwrt: This repository is a mirror of...](https://github.com/gl-inet/gl-openwrt)** > > 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 merged via staging trees then into openwrt.git. Blogic repo one of the core devs (please see the PR by shi): > **[GitHub - blogic/openwrt: This repository is a mirror of...](https://github.com/blogic/openwrt)** > > 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 or for reporting issues. We will continue to accept Pull Requests here. They will be merged via staging trees then into openwrt.git. All issues should be reported at: https://bugs.openwrt.org The topic by @shi05275 > [@Flint4 Support Now Available in Mainline OpenWrt](https://forum.gl-inet.com/t/flint4-support-now-available-in-mainline-openwrt/71154): > > 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. And the OpenWrt forum discussions: > **[Gl.iNet Flint 4 support](https://forum.openwrt.org/t/gl-inet-flint-4-support/251851/119)** > > seems like glinet working on support too IMO, I won't worry too much I have been testing some self compiled builds and the ethernet ports work, there only need to be some more testing, like the hardware macs etc, possible hardware offloading, for me the reset logic still failed for me. ^in short: flashing should just work as intended ---
**Author:** ![username89](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/u/da6949/32.png) [@username89](https://forum.gl-inet.com/u/username89)\ **Post date:** [September 18, 2026, 1:07am UTC](https://forum.gl-inet.com/t/flint-4-openwrt-vanilla/71383/4 "2026-09-18T01:07:22Z")
Thank you very much for the quick reply, I was a bit worried and you have settled my worries and have been a tremendous help. ---
**Author:** ![DiGz\_Au](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/d/eb8c5e/32.png) [@DiGz\_Au](https://forum.gl-inet.com/u/DiGz_Au)\ **Post date:** [September 18, 2026, 5:15am UTC](https://forum.gl-inet.com/t/flint-4-openwrt-vanilla/71383/5 "2026-09-18T05:15:07Z")
ive compiled a few builds and have a few fixes included, latest build is here with mac fixes for gmac1. [Release Flint 4 (GL-BE14000) OpenWrt Test Build – GMAC1 MAC Fix · DiGz-Au/Flint4-build · GitHub](https://github.com/DiGz-Au/Flint4-build/releases/tag/flint4-test-gmac1-fix) - Complete Motorcomm YT9224 switch support - - YT8824 PHY package support - - Fixed 10G USXGMII switch link support - - YT922x 4-byte DSA tagging - - MediaTek PPE hardware flow offload support - - YT9224 hardware bridge forwarding - - MT7996 WED support - - MT7988 wireless offload firmware - - RTL8261C PHY firmware probe fix - - GL-BE14000 production device-tree fixes - - GL.iNet Panel UI - Touchscreen rotation fix - - LuCI - SQM / CAKE support - - GMAC1 factory MAC address fix ---
**Author:** ![username89](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/u/da6949/32.png) [@username89](https://forum.gl-inet.com/u/username89)\ **Post date:** [September 18, 2026, 8:14am UTC](https://forum.gl-inet.com/t/flint-4-openwrt-vanilla/71383/7 "2026-09-18T08:14:15Z")
Nicely done repo build there cheers, @DiGz_Au, I'll keep a close eye on it and have a copy locally now ---
**Author:** ![DiGz\_Au](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/d/eb8c5e/32.png) [@DiGz\_Au](https://forum.gl-inet.com/u/DiGz_Au)\ **Post date:** [September 18, 2026, 8:56am UTC](https://forum.gl-inet.com/t/flint-4-openwrt-vanilla/71383/8 "2026-09-18T08:56:25Z")
im running it now and its pretty good. no issues just a couple of little things like the blogic feed coming up when updating apk. nothing to control the screen from luci is another thing id love to implement. for now its options are easier to change via ssh ---
**Author:** ![twistedddx](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/t/2acd7d/32.png) [@twistedddx](https://forum.gl-inet.com/u/twistedddx)\ **Post date:** [September 18, 2026, 12:26pm UTC](https://forum.gl-inet.com/t/flint-4-openwrt-vanilla/71383/9 "2026-09-18T12:26:56Z")
Does vanilla openwrt have the same issue as glinet firmware where: Luci web ui →MTK→wifi configuration → config any wireless interface eg ra3→bridge Only first 2 bridges are shown/selectable. For glinet firmware the default created iot bridge is not shown and clicking save in iot ra3 will save incorrect bridge br-lan. Only way to recover function of iot wireless is to say and ssh → vi /etc/config/wireless→ change ra3 bridge back to iot. I assume the Luci issue of only showing the first 2 bridges is a fault in the openwrt MTK driver web interface? ---
**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 18, 2026, 12:47pm UTC](https://forum.gl-inet.com/t/flint-4-openwrt-vanilla/71383/10 "2026-09-18T12:47:02Z")
Afaik, (not tested by myself but seen on Github and forum responses). There is no luci app for mtk, but instead the normal wireless menu item which you should expect. Unto further reading, some reported to have no phy for 6ghz, but they confirmed that it only becomes visible if the country settings are correct, some countries don't support the full 6ghz band, I'm not sure if that is something you also are seeing in the mtk sdk, this however are completely different implementations with OpenWrt as base. As for MLO, this is just my personal untested opinion, I think the drivers are not fully mature for it to work stable I just compare it with the history of older wifi standards here, it takes close to a new wifi standard to say all quircks and issues are gone, minimum a year or two, from now I think they already at a year or close to it, luckily the banana pi had this chip quite some time allowing developers to support things alot earlier. So it will not be strange to experience some issues or corner cases on this field 🙂 Edit: I didn't read properly, i didn't notice bridge issues myself with vanilla. ---
**Author:** ![twistedddx](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/t/2acd7d/32.png) [@twistedddx](https://forum.gl-inet.com/u/twistedddx)\ **Post date:** [September 18, 2026, 1:13pm UTC](https://forum.gl-inet.com/t/flint-4-openwrt-vanilla/71383/11 "2026-09-18T13:13:02Z")
Oh I thought the MTK menu would be common between vanilla openwrt and the glinet firmware. It must only exists on the glinet version / MTK sdk. Because the issue was in Luci I wasn't sure if it would be considered an openwrt issue but clearly sounds like it is not a vanilla openwrt issue. ---
**Author:** ![oly](https://forum-assets.gl-inet.com/user_avatar/forum.gl-inet.com/oly/32/14311_2.png) [@oly](https://forum.gl-inet.com/u/oly)\ **Post date:** [September 18, 2026, 4:05pm UTC](https://forum.gl-inet.com/t/flint-4-openwrt-vanilla/71383/12 "2026-09-18T16:05:17Z")
I just wanted to say a huge thank you for your vanilla OpenWrt test build for the **Flint 4 (GL-BE14000)**, especially with the recent GMAC1 MAC address fix. I've been testing it out, and it runs incredibly well—honestly, it feels much smoother and faster than the official GL.iNet stock firmware. Excellent work, and thanks for supporting the community with these builds! [[1](https://github.com/DiGz-Au/Flint4-build/releases/tag/flint4-test-gmac1-fix#:~:text=Flint%204%20(GL%2DBE14000)%20OpenWrt%20Test%20Build%20%E2%80%93%20GMAC1%20MAC%20Fix)] ![image](https://forum-static.gl-inet.com/original/3X/b/8/b8f7676e2572ba59ff921e92d96f2e86c8924057.jpeg) ![image](https://forum-static.gl-inet.com/original/3X/1/1/11900221a6375d55bf2e90f25a2a91c6511079d9.jpeg) ![image](https://forum-static.gl-inet.com/original/3X/8/8/88737f78ab762225a6b41ffcbd7b02031cda8e4c.jpeg) Hi GL.iNet Team, After testing the vanilla OpenWrt community builds for the **Flint 4 (GL-BE14000)** (like the ones provided by DiGz\_Au), the performance and stability differences are highly noticeable. The pure OpenWrt experience runs significantly better and smoother than the official stock software. Please consider focusing more resources on providing or supporting pure, vanilla OpenWrt firmware images for your devices. The Flint 4 hardware is amazing. ---
**Author:** ![DiGz\_Au](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/d/eb8c5e/32.png) [@DiGz\_Au](https://forum.gl-inet.com/u/DiGz_Au)\ **Post date:** [September 18, 2026, 11:58pm UTC](https://forum.gl-inet.com/t/flint-4-openwrt-vanilla/71383/13 "2026-09-18T23:58:36Z")
awesome. the gmac1 address should be +2 according the the boards documented layout so i have changed it accordingly. `+1`: stable and functional, but invents a separate LAN-side identity. not broken though so safe to use. `+2`: stable, matches GL.iNet’s intended factory LAN mapping, and keeps both LAN switch groups under the same LAN identity. ---
**Author:** ![username89](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/u/da6949/32.png) [@username89](https://forum.gl-inet.com/u/username89)\ **Post date:** [September 19, 2026, 3:18am UTC](https://forum.gl-inet.com/t/flint-4-openwrt-vanilla/71383/14 "2026-09-19T03:18:12Z")
I will flash this when i get a chance at the moment I got to much on my plate, and if i find anything wrong bugs or otherwise I'll gladly help out. Thanks again @DiGz_Au legend from one Aussie to another. ---
**Author:** ![oly](https://forum-assets.gl-inet.com/user_avatar/forum.gl-inet.com/oly/32/14311_2.png) [@oly](https://forum.gl-inet.com/u/oly)\ **Post date:** [September 19, 2026, 4:43am UTC](https://forum.gl-inet.com/t/flint-4-openwrt-vanilla/71383/15 "2026-09-19T04:43:38Z")
**Hi everyone,** I wanted to share that I successfully flashed the **Tomato64 firmware (Version 2026.3)** onto a **GL.iNet GL-BE14000** router (powered by the MediaTek MT7988A / Cortex-A73 chipset). Crucially, the installation and transition were done directly from DiGz-Au's unofficial OpenWrt test build ( **Flint 4 OpenWrt Test Build – GMAC1 MAC Fix** ) available here: > **[GitHub · Change is constant. GitHub keeps you ahead.](https://github.com)** > > Join the world's most widely adopted, AI-powered developer platform where millions of developers, businesses, and the largest open source community build software that advances humanity. The entire upgrade process from that specific OpenWrt build to Tomato64 went completely smoothly without any flashing errors or issues. As shown in the attached screenshot, the control panel loads correctly, the system is fully operational, and hardware resources (CPU, RAM) are being accurately recognized by the new system. **One important remark:** The built-in **touchscreen is currently non-functional** under this build. If anyone has any questions about the specific steps or the long-term stability of this firmware, feel free to ask below! > **[GitHub - tomato64/openwrt-be14000-kernel](https://github.com/tomato64/openwrt-be14000-kernel)** > > Contribute to tomato64/openwrt-be14000-kernel development by creating an account on GitHub. > **[index - powered by h5ai v0.30.0 (https://larsjung.de/h5ai/)](https://tomato64.org/files/)** > > index - powered by h5ai v0.30.0 (https://larsjung.de/h5ai/) ![Screenshot 2026-09-19 074141](https://forum-static.gl-inet.com/original/3X/8/2/82ba35531ac0a28c89fc65753ec4e19dd0e3aff5.png) [Digi Storage - Password required](https://s.go.ro/zgrvgsmg) | password: 354600 ![Screenshot 2026-09-19 071220](https://forum-static.gl-inet.com/original/3X/2/4/24066142b25a123f95fe7984987783bf972d637e.png) ![Screenshot 2026-09-19 074348](https://forum-static.gl-inet.com/original/3X/c/6/c6ea48a55910553e15fedd670df0b721787ae781.png) ![image](https://forum-static.gl-inet.com/original/3X/3/9/398c5afea963e0634912c834e4c980a6c31ae1a5.png) ```auto root@unknown:~# df -h Filesystem Size Used Available Use% Mounted on /dev/root 57.1G 552.8M 54.2G 1% / devtmpfs 987.2M 444.0K 986.8M 0% /dev tmpfs 987.5M 308.0K 987.2M 0% /tmp root@unknown:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS mmcblk0 179:0 0 58.2G 0 disk ├─mmcblk0p1 179:1 0 512K 0 part ├─mmcblk0p2 179:2 0 4M 0 part ├─mmcblk0p3 179:3 0 3M 0 part ├─mmcblk0p4 179:4 0 1M 0 part ├─mmcblk0p5 179:5 0 2M 0 part ├─mmcblk0p6 179:6 0 32M 0 part └─mmcblk0p7 179:7 0 58G 0 part / mmcblk0boot0 179:8 0 4M 1 disk mmcblk0boot1 179:16 0 4M 1 disk zram0 254:0 0 0B 0 disk root@unknown:~# dmesg | grep -iE 'error|fail|corrupt|bad block|ext4' [0.000000] Kernel command line: console=ttyS0,115200n1 loglevel=8 earlycon=uart8250,mmio32,0x11000000 earlyprintk pci=pcie_bus_perf root=PARTLABEL=rootfs rootwait rootfstype=ext4 [0.701874] /soc/pcie@11300000: Failed to get clk index: 0 ret: -517 [0.708317] mtk-pcie-gen3 11300000.pcie: failed to get clocks [0.745154] /soc/pcie@11310000: Failed to get clk index: 0 ret: -517 [0.751595] mtk-pcie-gen3 11310000.pcie: failed to get clocks [0.893020] mtk_soc_eth 15100000.ethernet: error -ENXIO: IRQ fe1 not found [0.899896] mtk_soc_eth 15100000.ethernet: error -ENXIO: IRQ fe2 not found [1.764041] GPT: Use GNU Parted to correct GPT errors. [3.933879] fitblk fitblk: probe with driver fitblk failed with error -22 [3.949458] mtk_soc_eth 15100000.ethernet: error -ENXIO: IRQ fe1 not found [3.956332] mtk_soc_eth 15100000.ethernet: error -ENXIO: IRQ fe2 not found [4.568103] mdio_bus mt7530-0: Failed to setup PHY LED pinctrl [4.593610] mdio_bus mt7530-0: Failed to setup PHY LED pinctrl [4.619230] mdio_bus mt7530-0: Failed to setup PHY LED pinctrl [4.644620] mdio_bus mt7530-0: Failed to setup PHY LED pinctrl [5.847043] EXT4-fs (mmcblk0p7): orphan cleanup on readonly fs [5.853009] EXT4-fs (mmcblk0p7): mounted filesystem ec456d7e-3d79-457e-a88e-e02b47ba1512 ro with ordered data mode. Quota mode: disabled. [5.865382] VFS: Mounted root (ext4 filesystem) readonly on device 179:7. [7.237782] EXT4-fs (mmcblk0p7): re-mounted ec456d7e-3d79-457e-a88e-e02b47ba1512 r/w. [8.431628] EXT4-fs (mmcblk0p7): resizing filesystem from 192000 to 15204352 blocks [8.505478] EXT4-fs (mmcblk0p7): resized filesystem to 15204352 ``` [https://www.linksysinfo.org/index.php?threads/flint-4-gl-be14000.79804/](https://www.linksysinfo.org/index.php?threads/flint-4-gl-be14000.79804/) ---
**Author:** ![username89](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/u/da6949/32.png) [@username89](https://forum.gl-inet.com/u/username89)\ **Post date:** [September 19, 2026, 5:41am UTC](https://forum.gl-inet.com/t/flint-4-openwrt-vanilla/71383/16 "2026-09-19T05:41:32Z")
I didn't know this, thank you very much this is new news for me ill look into it also. ---
**Author:** ![DiGz\_Au](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/d/eb8c5e/32.png) [@DiGz\_Au](https://forum.gl-inet.com/u/DiGz_Au)\ **Post date:** [September 19, 2026, 6:10am UTC](https://forum.gl-inet.com/t/flint-4-openwrt-vanilla/71383/17 "2026-09-19T06:10:39Z")
awesome to see tomato64. ive fixed gmac1 here with the correct layout and fixed the apk feeds. [Releases · DiGz-Au/Flint4-build · GitHub](https://github.com/DiGz-Au/Flint4-build/releases#release-Flint4-v1.1) ---
**Author:** ![username89](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/u/da6949/32.png) [@username89](https://forum.gl-inet.com/u/username89)\ **Post date:** [September 20, 2026, 1:27am UTC](https://forum.gl-inet.com/t/flint-4-openwrt-vanilla/71383/18 "2026-09-20T01:27:09Z")
I saw the repo update yesterday , very nice , This is truly a humbling experience watching the opensource community and Gl.Inet developers working in perfect sync trying to achieve like mined goals its artwork, Its even better knowing others in my own country doing this also, this is a niece area and not many people truly know or appreciate it the talent it takes to do this at a high level and is very motivating experience for me, as the saying goes "iron sharpens iron". Nothing but respect. ---
**Author:** ![Ein](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/e/e5b9ba/32.png) [@Ein](https://forum.gl-inet.com/u/Ein)\ **Post date:** [October 10, 2026, 1:34am UTC](https://forum.gl-inet.com/t/flint-4-openwrt-vanilla/71383/19 "2026-10-10T01:34:32Z")
I checked the LuCI code on my Flint 4 running 4.9.2. In `/usr/lib/lua/luci/view/admin_mtk/mtk_wifi_vif_cfg.htm`, the Bridge dropdown is hardcoded to only `br-lan` and `br-guest`. The backend in `/usr/lib/lua/luci/controller/mtkwifi.lua` also only maps: ```auto br-lan -> lan br-guest -> guest ``` This seems to explain why custom bridges never appear in the dropdown and cannot be saved correctly through the MTK WiFi UI. An interesting detail is the comment at the top of the same file: > “This module is a demo to configure MTK' proprietary WiFi driver. > Basic idea is to bypass uci and edit wireless profile (mt76xx.dat) directly.” It also says: > “LuCI's WiFi configuration is more logical and elegent, but it's quite tricky to translate uci into MTK's WiFi profile.” So it looks like this MTK page was originally designed as a demo/direct MediaTek configuration layer rather than around the normal UCI network model. Would it make sense to resolve other bridge names dynamically through UCI instead of hardcoding only LAN and Guest? ---
**Author:** ![oly](https://forum-assets.gl-inet.com/user_avatar/forum.gl-inet.com/oly/32/14311_2.png) [@oly](https://forum.gl-inet.com/u/oly)\ **Post date:** [October 26, 2026, 8:37pm UTC](https://forum.gl-inet.com/t/flint-4-openwrt-vanilla/71383/20 "2026-10-26T20:37:52Z")
[https://forum.openwrt.org/t/gl-inet-flint-4-support/251851/192https://github.com/openw](https://forum.openwrt.org/t/gl-inet-flint-4-support/251851/192https://github.com/openw) > > > Add the GL.iNet GL-BE14000 (Flint 4) and the panel, touch and U-Boot mod > for t…he GL-BE10000 (Slate 7). > > Boards: > - GL-BE14000, stock U-Boot and U-Boot mod variant > - GL-BE10000, panel, touch and U-Boot mod variant > > Bootloader: > - uboot-mediatek: GL-BE10000 and GL-BE14000, ST7789P3 video driver, > MT7987 2.5G PHY via the XGMAC > - arm-trusted-firmware-mediatek: BL2 splash for both boards, MT7987 SPI2 > 4k+256 UBI variant > > Switch: > - Backport of the Motorcomm YT92xx DSA driver, with the YT922x support > from the net-next v1 posting > - Fixes for the YT922x support that need to go upstream > - mtk\_eth\_soc, PPE and mtk-usxgmii changes for the YT9224: fixed 10G > USXGMII link, four-byte tag offload, cross-switch bridge flows > - bridger: propagate offload errors > > Panel: > - mipi-dbi: ST7789P3 init sequences for both boards > - panel-mipi-dbi: adopt a panel the bootloader already initialised > - cst353x touchscreen driver