Hey friends. As you know, Mediatek has a big issue with their disclosure, and as far as I've been able to research, there is a way for us to insert the driver .so into a static image (from buildroot on a git cloned environment of lede) , This affects several models, a couple of workhorse routers to name a few
I found a link somewhere that specified somewhat of a howto for RouterOS but I've lost it and can't seem to find it.
The issue with wifi stability is well documented and basically persists. All one would need it to inject the .so (someone with the technical chops to guide us through it), and then one could build it with that .so to modprobe or insmod.
I understand that any update would completely break kernel and so forth, however if the objective is to just create ONE image, and then deploy onto hundreds of routers, it doesn't seem like a bad tradeoff at least until mt76 works. ( a popular thread is the Pre-Compiled updated mwlwifi drivers for stable releases).
I'm talking here about including the proprietary driver blobs (also understand it's a bit of a sore topic, but so is not being able to connect or use the model at all).
To include a binary blob did cross my mind, but I found that patching the MT7612 and MT7603 propriaty drivers is not as complicated as it sounded. I didn’t get around to do the MT7628 yet. In order to fully use the driver you need to do a lot of manual configuration or it needs the Luci Wifi app to be patched. In it self that can be done as well.
But: with the latest MT76 patches most problems are solved and we are using a full open source driver.
@drbrains It would be of enormous assistance to gain support from you in this regard, MT7628 is virtually unusable. The only way it's SORTA stable is if you dial down txpower to 20, but you have to be right beside the router in order for it to work (100mw).
Also, you get random disconnects, stops working altogether, a huge mess.
Proprietary (stock) drivers work perfectly at any distance.
@drbrains Have you tried getting MT7615 to work?
There is leaked full source of MT7615 driver v18.104.22.168 ,I have not seen newer
@amaurynieto may this help? https://github.com/Nossiac/mtk-openwrt-feeds . 7620/7628/7610/7612/7603/7615 will be added soon.
Sounds like it!! How to add to a buildroot is the question also. In the case of 840 and 841 for TPLink they are both MT7628
this repo is a lede/openwrt feeds. you can put a new line into "feeds.conf.default":
src-git mtk https://github.com/Nossiac/mtk-openwrt-feeds;lede-17.01
scripts/feeds update -f mtk
scripts/feeds install -a -p mtk
now you will be able to see the packages appear in
make menuconfig -> MTK properties
Thank you. For sure I will have a closer look at the Luci Add-on.
But sofar I noticed you build the .ko files for the 4.4.x kernel and you need to update it for every new version. The MT76xx is using kernel 4.9.x already so on newer builds it will not work.
The same is for replacing the “build-in” driver for this one. I was looking into getting the cfg80211 to work, but it conflicts with the mac80211 module. If you remove that one, it still won’t work since it needs to have the cfg80211 kernel module “inside” the kernel otherwise it was missing exported symbols.
So if you are willing to make this driver for every Lede kernel version, or at least all the stable builds, I think it could be worth it for some people.
all mtk's proprietary wifi drivers are full-mac, which means they don't use cfg80211/mac80211 at all. packets are delievered from driver to network stack directly. cfg80211 support is partially implemented in some drivers, but not well accepted.
that repo is an experimental project, intent to help geeks and small startups to use mtk's chips. i think it's reasonable to build those drivers for all stable versions.
if kernel version changes frequently, maybe an autobuild server will be setup for it.
I was actually hoping to get the cfg80211 code working or to modify that code to use mac80211 and get better integration with a “modern “ system. You are not the first to tell me I’m crazy to even look into that.
Without the cfg80211-support there are not that many patches left for the driver to compile. I would love me to have a look at your patches to compare with my own. I understand you can’t/won’t publish them, but maybe you could share them via PM for me to learn.
Those interested in a benchmark I did a few months ago with the MT76 driver at that time: Bechmark results between MT76 open source and "stock" Mediatek on MT7612e and MT7603e
I didn’t do anything testing on range, but that would be interesting to see if “coverage” is indeed different as stated in the post above.
sorry that i'm not going to publish those patches. exposing the source code is against mtk's policy. I also noticed some guy had uploaded the full source to github, hmm, that's at least not respectiful ......
long time ago, mtk do released a gpl licenced driver to openwrt developers, which was the origin of current mt76 project. cfg80211 was partially implemented in that driver, i guess. you can find it here https://github.com/openwrt/mtk-wifi-gpl.
even though the mt76 driver still suffers from stability and performance problems, we still have faith in it. i think seldom people would consider adding new feature into mtk's proprietary drivers, not just because of lacking actual motivation, but also the enormous diffculties you are going to run into ....
sorry that i’m not going to publish those patches. exposing the source code is against mtk’s policy. I also noticed some guy had uploaded the full source to github, hmm, that’s at least not respectiful
I didn’t ask for the source code just for the patches to learn how other people are doing it. I managed by myself, but I’m sure it could be better (smarter). Just trying to figure out all the changes in different kernel versions was a challenge.
As for the source code: if they don’t release a working driver under GPL but they are selling the chips, what do they expect? They can’t sell hardware without software support.
the patchwork was mainly about
- a package makefile to build the driver as a openwrt kmod pacakge.
- a config.in file to generate proper kernel config for the driver.
- fix some build errors due to obsoleted kernel api.
- replace gpl api ( especially mtd read/write ) with request_firmware.
not very smart as you expected.
if you are still interested, let's discuss it at gist.
I am not a C developer so I am not able to improve the code, but I am interested in the patches, especially for the MT7610 chip, which is currently not supported by the MT76 module.
That's great! Do you have any time estimate when 7628 will be added? Thanks!
I do it in my spare time. so it may not have a stable schedule.
@numero53 yes. 7610 is included, actually full series will be covered in my plan.
@guisenges I have already build 7628 with lede. but i found an issue after some basic tests, need some more time to fix it first.
Absolutely wonderful. The power of collaboration can't be denied. Thank you
I can test mt7628 on an 840v4 from Tp-link if need be.
the code was really a mess... now I can understand why mtk denied to open it.