Hello everybody,
i'm interested in the newly released Brume 3 (GL-MT5000) and have noticed that GL.iNet has already submitted a pull request [1] for adding support for this device to the openwrt project.
Unfortunately, it seems that this pr is stuck, apparently because of missing sources for the Realtek RTL8366ub switch driver.
I am now wondering about whether anybody has information on this, i.e. GL.iNet plans to potentially upstream device support with openwrt.
GL.iNet are probably not responsible for the upstream support of the Realtek switch chip. Stuff like that would generally be an effort of Realtek or the wider community to develop support like they do for other Realtek hardware. Will likely happen in due course as with other devices that make their way into upstream OpenWRT, just takes time.
My apologies, but i'm not sure if i understand correctly..
If that is the case, what is the pull request for? And why is GL.iNet promoting the device with "Full Control Starts with OpenWrt", when the device is, in fact, running their own fork of OpenWrt?
Well, most routers run their own fork of OpennWRT, its surprisingly widely utilised, just hideden behind the firmware wrappers of NEtgear, Sagemcom, TP-Link and so-on. This is because the likes of Mediatek, Qualcom, Broadcom and so forth who product the SoC inside the devices, produce reference builds of OpenWRT with closed source drivers and firmware etc to support the chips.
Impossible for me personally to say how GL.inet structure their specific fork/forks, but generally the reason the OpenWRT versions are what they are will be rooted very much in the hardware support and code/drivers from the chip makers and the specific versions etc that they align to. GL.inet potentially merge in and backport and patch to try and unify this as much as possible, but is not always an easy job with patches that you havent written yourself causing unexpected bugs and issues without further updates from the SoC manufacture in their closed source code.
Vannilla Openwrt has some support for Mediatek, but most other devices you lose all hardware support and run full in ‘CPU only’ mode at much lower performance because they do not include any closed source drivers or firmware, it only runs vanilla Openwrt with open-source elements builting into, or backported from the upstream mainline linux kernel.
Why there is a PR for this device specifically, impossible to say what the likely reasoning is, but it may be to help encorage the community to help build the required driver support to move away from the Realtek provided code.
Just further to this, there always seems to be a lot of call for getting devices on newer versions of OpenWRT, but there is often little to no reason or benefit to actually do this outside of the false perception that the higher numbers are somehow better.
Until recently OpenWRT itself didnt run on ‘new’ kernels. The main reason the last 2 years or so has seen a rapid set of new releases is they have a HUGE list of devices they try and support and they are making a consios effort to get on a recent kernel as it reduces the back-porting effort to be on a newer kernel version.
Somewhere like GL.Inet with a focus on specific devices this is much less important as there is much less to backport overall.
I noticed that the PR was stuck due to lack of Realtek driver, is there anyone know about the progress? I want op24 version so bad T-T
It’s not really dependant on that PR. There is a difference between regular OpenWRT versions that need the code in the open-source linux kernel drivers, which is what that PR will maybe result in one day.
We could still see newer OpenWRT build with closed patches from the likes of MTK updating the SDK with patches that support later OpenWRT / Kernel versions even if that PR doesn’t go anywhere.
Yes, actually it does... Read @pirate post “op24 version” is what he wants, this requires OpenWrt 24.10 to support GL-MT5000 before GL can add their GUI ontop. MT6000/MT3000 would not have OP24 releases if they were not supported in upstream OpenWrt...
There is a difference between OpenWrt and forks, yes. You care about a fork, while the PR gives options beyond GL’s SDK release cycles and continued security when GL EOLs the device.
Looking at the released firmware versions and SDKs listed, the only way a model has gone to a new OpenWrt code base is if GL rebases from the SDK to vanilla.
GL-X2000 users running ancient QSDK based on 19.07 
GL-B2200 users are going to be EOL’d this year, 2026, on QSDK based on 15.05…
Edit to add: Looking at MediaTek platforms that did get new OpenWrt builds, all are due to GL rebasing on vanilla, not a newer MTK SDK rebase.
OK, but that still doesn't need vanilla to merge the PR? It’s not going to get merged until there is DSA support for the switch in the vanilla kernel. As you said nothing stoping a GL fork having support, so that PR on vanilla still doesn’t matter to get a new OpenWRT version for this hardware as they can just include their changes in their rebased fork of a later snapshot?
If they choose to do that or not or wait for someone else to do it is a different thing, it doesnt need to happen to get a later release.
What I am trying to say is, the dependency on this happening is be a bunch of patches committed to the Linux kernel, that may get backported into Openwrt at some point. Once that is done GL have what they need independent of the existing PR being watched here is merged or not into OpenWRt upstream.
Does the lack of Realtek RTL8366ub switch driver mean if mt5000 applies Openwrt firmware, the 2 LAN ports can not communicate each other directly while both of them can communicate with the WAN port?
Right now there isn’t an image to do this unless you build it yourself from source and include the GL.inet patch.
From the notes it sounds like it might work, but you should not expect it to work properly.
Being a custom image build from source at this point to even install it I probably wouldn’t expect anything to be particularly stable and it would be safer to have the attitude that anything that actually works at all is a bonus.