That would be awesome. Looking forward to that.
Happy to help test it. I have a bunch of ZBT-WE3526 / 512MB devices.
1 Like
+1 for this!!!
Also willing to test. Have multiple test boxes with MT7621 with 7612EN for 5GHz and 7603E for 2.4GHz.
Sorry to bug you about this, but is there progress on this?
Sounds like a good solution to the challenges with MT76, as not even 21.02 RC1 is as stable as I'd like.
CharlesYu ->
Tested with last debian but requiert gcc 4.8 or gcc++ 4.8 later ???
i have 4.10.2.1-1 installed
any option for mt7615 please?
I don't know , I guess your gcc version is old.
OpenWRT will use host gcc to build a toolchain, then use this toolchain compile this driver.
I just use master branch to test, and gcc version maybe gcc-8.4.0 or later.
ChalesYu
cc --version
gcc (Debian 10.2.1-6) 10.2.1 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
no problem for build last OpenWrt 19.05 or 21.02 ...
cc --version
gcc (Debian 10.2.1-6) 10.2.1 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
yes , this version also work on master branch
you can cherry-pick my commit to test
and the tested build target kernel is 5.10 , old terget kernel version may failed.
Any updates on this?
Would love to help test using 19.07.8 as a base on multiple ZBT WE3526 units.
Life is hell with the OpenWRT WiFi drivers, low throughput, low power, loss of Internet while still showing connected, etc.
Take a look at that implementation:
I based that in the PandoraBox implementation. The idea is to generate the dat file that the original vendor driver use when openwrt modify the /etc/config/wireless. You may need to change the location for you dat file. I tested that with "wifi up" and "wifi down" ...
For luci, we need to modify the driver to export new functions to the iwinfo package.
The driver I'm using is the openwrt mtk one:
I'll make a fork from this repository to modify it, but this one is for mt7620/7612 only...
2 Likes
No time to do it. Approach of enabling cfg80211 on mtk drivers failed - driver crashes.
I think idea of @gaspare has written is the best approach. One would need:
- driver built from source (can be found on github for almost all chips)
- patched libiwinfo - to get status/statistics via MTK ioctl (like received power)
- tests tests tests...
Low throughput with ac devices?
When using one device to test, and 5GHz radio is in ac mode, with 80MHz width, it syncs at 800+ Mbps from a MacBook Pro 16 sitting two feet away, and throughput is 500+Mbps to a local server.
But once you have >10 feet distance, the weak signal means lower rates. It is also not stable, so I run using N mode at width 40 and while that cuts max throughput, it works better and when sharing the AP with six or so other devices, much smoother.
Really close to the AP, all looks good, low latency, download is close to the 300Mbps speed of the line: http://www.dslreports.com/speedtest/69338491
But move 15' away (one wall) and throughput is cut, but worse, massive latency spikes (see the upload detail graph) leading to a poor bufferbloat score http://www.dslreports.com/speedtest/69338725
The 2.4Ghz radio not only has low throughput but will stop passing traffic to the br-lan for a minute or two (or sometimes longer), even though clients indicate they are connected.
The stock MT drivers (and other commercial APs) are a lot less sensitive to interference. The OpenWRT driver folds over in the presence of other APs nearby. The WiFi is pretty much useless in an apartment building.
I love all the things the Open Source drivers support, like airtime fairness, but stability and reach are two non-negotiable WiFi table-stakes, and the open driver lacks those at the moment.
I re-tested the above using an MT7621/7603 unit running 19.07.8.
The MT7621 devices usually have a MT7663 for 5GHz. This is a relatively new port to the open source driver and not all features have been ported yet... For the MT7603, this 2.4GHz chip is similar to the internal MT7628 2.4Ghz radio (difference is that one is SoC e the other is external). But, on more expensive routers, like the ones that have the MT7621 SoC, it usually have a PA and/or LNA external chip to increase power/reduce noise in the radio. No all of those chips are compatible...
I'm trying to stabilise the open driver with this features, but it will take time... Do not lose the faith in open source driver 
3 Likes
That's one for the worst things with mt76.
But the worst is support: many opened issues without any reply.
How such a bad driver was accepted to official kernel?
@gaspare mt7602, mt7610, mt7612 should already tune registers for lna/pa. On newer chips, this could be handled by firmware, but I am not sure.
I think that was because it is the only option... Its either accept that or not have support at all... And it works in general cases... Those drivers are complex and need time to mature...
Thats right for mt7602/7612 ... The open driver have the registers activated for lna/pa, although I think they are not tuned for all cases. Vendor driver do some voodoo to optimize those chips based on the parameters of eprom. Particularly on features like dynamic vga, beanforming, and things like that.... And that's another problem. Not all routers have an optimize eprom in flash. Some routers use an internal file for eprom, and openwrt read all information from a partition from flash. I already saw routers that have eprom in flash and in the file system, and the one in file system is the one used by the original firmware... Oh, well...
But I thinks that's why mt76 works satisfactory for MT7612 5GHz chip... I don't think that the wifi firmware do those optimisations in other chips. The driver must activate it...
In my case, the problem is worst by the fact that mt7620 is an old driver in kernel, not mt76 (I'm working on a C5)...
@gaspare https://github.com/dangowrt/mt76/commit/2bdcd63888e04d9c7e1a02f42bbe2f37a465bbff this could be the solution for what you described. The difference is that one would need to copy eeprom file to dts.
I read that rt2800soc issues should be solved now, aren't they?
yep... that's right... We just have to include the right eprom in the routers now ...
The problem with rt2800 is the external LNA... The driver have improved a lot with the calibration changes, but it still lacks the temperature compensation that MT7620 need. And the external LNA that C5 have uses a different procedure for radio calibration that is a pain... Thats why C5 have a poor 2.4Ghz and others MT7620 works well...
Man, I have all of these problems and I thought it was the devices connected...
@lukasz92
I have UniElec U7621-06-16mb with MT7602E for 2.4ghz and MT7612E for 5ghz
I'm using the latest snapshot. How can I help for testing?
1 Like