@bruce since we’ve not seen upstream activity (including removal of the conflicting copyright declarations), can we just get a clear direction on where GL is going with this?
The OWRT community it seems has rejected accepting the existing RT code as it implements legacy swconfig and is instead pursuing DSA. So, will GL be fixing the VLANs on the exiting RT base, and if so, when (or which version) please?
Or, should we expect GL is going to sync with the upstream and we’ll see the fixes at that point?
please accept our apologies. Due to an oversight, the fixed code was not committed to the main branch and was consequently excluded from the build process.
We have identified the issue, and it will be resolved in the next release.
We have escalated this request to our senior R&D. According to their current project schedule, they are expected to allocate resources to implement DSA support later approximately two weeks.
We kindly ask for your patience while we process this matter. Thank you for your understanding.
Excellent. Thank you @bruce! DSA with full OpenWRT mainline support seems like the win for everyone. Sincerely appreciate your continued follow up on this!
The Brume 3 is marketed as a "High-Speed VPN Security Gateway". Its own product page says it runs OpenWrt 21.02 with Linux kernel 5.4.281, and firmware 4.9.0 is on the same kernel.
Both of those are dead upstream.
OpenWrt 21.02 reached end of life on 1 May 2023 with the 21.02.7 release: "We will not fix any security problems, even severe ones in the OpenWrt 21.02 release branch any more."
Linux 5.4 reached end of life on 3 December 2025 at 5.4.302. Greg Kroah-Hartman's final announcement: "This is the LAST 5.4.y release. It is now end-of-life and should not be used by anyone, anymore." He also noted "1539 documented unfixed CVEs for this kernel branch, and that number will only increase over time."
5.4.281 shipped in July 2024, so the firmware is 21 point releases behind the final version of a branch that is now closed.
Nobody maintains 5.4 anywhere. It is not in the upstream longterm list, and not in the Civil Infrastructure Platform SLTS set either (those are 4.4, 4.19, 5.10 and 6.1). Any fix after December 2025 has to come from GL.iNet.
For reference, current OpenWrt stable is 25.12.5 on kernel 6.12.94.
Credit where it's due: bruce on 1 July, "Realtek has officially agreed to open-source the source code for this switch", with the upstream PR following on 15 July. But that PR has had no activity since 17 July, and the reviewer called it "a massive and ugly Realtek vendor driver in a device support commit", asking for conversion to upstream DSA instead.
Three questions:
In post #106 on 4 August, bruce said senior R&D were "expected to allocate resources to implement DSA support later approximately two weeks". That window has passed. Has the DSA work started?
Separately from vanilla OpenWrt, is there any plan to move stock MT5000 firmware off 21.02 and kernel 5.4, via an OP25 build like Flint 2 and Beryl AX received, or otherwise?
If not, does GL.iNet backport upstream kernel CVE fixes into 5.4.281, and is there a published record of which ones? Owners can plan around a clear answer either way. We cannot plan around silence.
I also hope that Brume 3 can get official upstream OpenWrt support as soon as possible. At the same time, however, I would also like to see GL.iNet continue updating its official firmware to a newer MediaTek SDK, ideally with OpenWrt 25.x as the base.
This way, users could choose between a more vanilla OpenWrt experience with proper upstream support, or GL.iNet’s official firmware with access to the more complete hardware acceleration and platform-specific features provided by MediaTek’s vendor SDK, allowing them to better utilize the full performance potential of the hardware.
We sincerely apologize for the delay. Since the insertion of other matters and the R&D team’s current focus on higher-priority issues, progress on this item may have been delayed.
We have coordinated with the R&D team and will arrange resources to address this matters asap.