I have a Flint 2 and love the hardware. On the GL iNet firmware the wifi performs really well.
When I run OpenWRT with the open driver I just can never get the same performance and in fact its kinda unstable. In some cases I see packet loss too. Despite trying so many different configurations I have never quite got it to perform the same. I am sure part of it is to do with my client devices which are all mostly realtek based. Perhaps some sort of incompatibility with the open driver.
Currently I am running the GL iNet firmware and configuring advanced options through the luci install you can do & access. But I really want to switch back to Openwrt and get on the latest kernel too.
For my next attempt at OpenWRT, I was thinking of building it up and then installing the closed source driver from Mediatek. Is anyone else doing this? Is there anything special I need to do other than get the binaries and replace, as described in the wiki? Would you expect that after driver install and configuring the wifi like for like with the GL iNet firmware, the performance would be the same?
Thanks, thats my mistake as I am still new. So on the GL iNet firmware they run both the mediatek soc firmware and mediatek wifi driver? So I would need to do both on my hand built system?
Well for anyone else reading. I managed to get it working and it is entirely possible by doing your own build of OpenWRT. Not sure why everyone is so unhelpful here. Probably dont know themselves. Better off asking AI.
I am not asking Ford why my Toyota wont start at all. That is the worst analogy you could have made. I am asking how to customize my system to my requirements which is one of the cornerstones of using OpenWRT.
And I already have it booting with assistance from Claude.
Nice OSS LARP though guys. You really did something here.
To be fair, one of the reasons for OpenWRT project is for promoting open source code and by extension, open driver. Close source driver is possible but not officially supported.
GL.iNET MT6000 wiki page has mentioned of pesa1234's custom build. In below post, it mentioned about going back to GL.iNET OEM firmware for finding MTK SDK driver:
The fact that the original MTK SDK driver is for older Kernel & OpenWRT version (21.02) would lead me to think that hacking it to work on OpenWrt Main / 25.12 branch would be quite a undertaking even if possible. The OP could opt for ImmortalWRT that ships MTK SDK driver but that firmware is still based on Kernel 5.4.x I think.
Yep theres multiple reasons people use OpenWRT. OSS is a big part thats obvious. But so is freedom, you and I both know that. And you stretched to find a hole to poke in this. Even though you understood my point.
And I think you will find the documentation is out of date, you can get it working on 25 with latest kernel. You can build it from scratch.
In regards to the secret, there isn't one. AI can help you do it easily especially if you are already capable of building your own software from source.
Anyway, toodle-ooo, no point being here. Good luck to anyone who googles this thread.
AFAIK, close source driver does not maintain binary compatibility between different gcc versions / kernel versions. It's close source after all, right?
They actively add patches against the openwrt source code, mainly for newer hardware they are developing i guess? - But I have managed to look at their patches and cobble together a more openwrt patch to work with the current 25.12 source tree.
What I have personally working from their patches are as follows:
WiFi beamforming and ECCDA modes - Improves wifi directional connections and interference.
HW Airtime Fairness - mainly useful for 2.4ghz so that clients do not hog the air waves when connected
HWNAT support via their patched kernel module in conjunction with the netfilter flowtable support - reducing cpu overload.
LRO and RSS modes enabled - offloading network support for the mt7981/86 socs
A few other custom patches I found or adapted that seemed to have cured alot of my problems I have had on my mediatek poe ap routers.
I understand what slh and frollic are saying about not supporting these type of changes, it would be an admin nightmare. I have spent a few months cleaning their patches and making it logical and clean.
Would be good for the mediatek team to do some form of official way.
But, its possible to get best of both worlds, just takes alot of effort.
Upon a more detail look though, I cannot find mentioning of using any close source drivers from these projects that the OP specifically mentioned. Maybe Mediatek has moved some functionality to binaryfirmware file (well, that is what NVIDIA did (see last paragraph) when announcing their 'open source' GPU driver) , or maybe I have missed it somewhere?
If you happen to find any MT6000 project mentioning of adapting close source binary driver files to work with latest Kernel, then I am interested to learn about it.
Does this mean that in the next release the firmware will include these improvements? Or are they already included in the latest version? Sorry for my ignorance
So the mediatek git repo patches are a bit all over the place - no clear definition on what does what or categorised - just passing git commits on its function.
Until recently mediatek would only provide SDK to oem's. I guess they are coming around to the fact that opening up the drivers code is beneficial to them.
Most of the open source drivers have the majority of feature set already, there are just a few features that i mentioned need the patches from their repo to work.
And its probable these patches are activating the necessary operations from the binary firmware.
Unfortunately you cannot just copy their patches and hope it builds, they are targeting their newer hardware and adding snapshot patches in order to make them work, reason its taken me time to understand their changes and implement a base level of HW functionality support that is missing.
I doubt anyone is working on the closed source code as its a bit of a mess and uses old reference code that is now outdated or just a bodge.
I'm just being selfish and trying to get my hardware to work properly.
For the older SOC chipsets like mt7981/86 the firmware that is in sync with mt76 and openwrt repos are pretty much complete, just needs the drivers to activate the features - their repo pretty much has these now. Still a few things missing, no doubt - but in terms hw acceleration, i'm getting hw offloading speeds from my AP's.