I've tried upgrading to stock firmware v1.2 and then flashed v0.6.5 *installer_signed.itb, it works as expected.
8 Likes
@daniel Thank you very much for taking the time to prove this and thanks for your hard work on these devices. I appreciate it.
2 Likes
Do not do this unless you live in Panama. There’s regulatory restrictions/limitations for a reason.
4 Likes
it will not hurt anyone if you live in a big house, with no neighbours around. And of course if your wifi doesn't cover all your house. we are all adults here (i think) to understand what we do.
Of course don't do it if you live in an appartment with neighours all around you. Unless you want to piss them off 
Btw it is not because the access point is able to send a signal far away, that your PC will be able to answer it.
This behaviour - just ignoring regulations - is the main reason why regulators seek to prevent open source wireless projects like OpenWrt and why more and more wifi devices become locked down.
Please - don't be the reason why we can't have nice things.
For your reference: https://fsfe.org/activities/radiodirective/radiodirective.en.html
9 Likes
That's provably wrong, it does hurt your neighbours very directly. Intel wireless takes its own regulatory domain from the environment, rogue APs claiming different regions will cause real havoc for those, disabling wide ranges of the 5/ 6 GHz band due to the inconsistent regulatory hints. Not obeying DFS channels can destroy (weather-) radar images for a wide area (60-80 km at worst) - and those primary users (which include military- and civilian airports and naval facilities) tend to 'retaliate' swiftly.
4 Likes
whouaaa ! so i will never take a plane in Panama then...
2 Likes
I live in Panama and the weather report clams it is raining 24/7. I guarantee you it isn't. Is our lack of DFS regulations related?
2 Likes
Hmm I have this too, If you are using 160MHz mode it seems less stable than 80MHz
2 Likes
How can I install bridger.
As I understand to enable WED I need to change the file mt7915e to include "mt7915e wed_enable=Y".
If you use vlans, the passing of ethernet frames to wifi clients is broken. 
1 Like
Thx for warning!
bridger is a package, you install it like any other package, from luci or using opkg or include it in your build; wed is only available in the master branch of openwrt (and to enable it you make the mentioned edit), the 22.03 branch is still using an older mt76 package, without wed.
Ok I've updated to the master branch and installed bridger. Enabled WED but still see high CPU usage with WLAN transfers from Internet (DHCP client connection).
So far with @anon78773196 's recommended RC2 branch I have no 5GHz disappearing issue even while 2.4GHz interface is also broadcasting.
I am still using WPA3-SAE only for 5GHz and WPA2-PSK for 2.4GHz.
Software/Hardware offloading is still currently off.
1 Like
Ok thanks for information 
Rc3 is release now
2 Likes
bridger does not help with NAT acceleration (i.e. internet - WLAN or LAN client), it helps with local transfers from a LAN client to a WLAN client. You don't need a special package for NAT acceleration, you just enable SW and HW offloading and also enable wed. But as I wrote in my post about latest wed testing, it seems the PPPoE patch from Felix broke the wed acceleration, at least in my case with a PPPoE connection. I could not test using other types of internet connections, but as you are describing it seems it is also broken with DHCP. To be sure this is the case, you need to test with an Ethernet client and in this case you must see something when invoking cat /sys/kernel/debug/mtk_ppe/bind during data transfers, confirming that the PPE engine (which performs the HW acceleration of Mediatek systems) is active. And, if you are sure wed is indeed enabled (cat /sys/module/mt7915e/parameters/wed_enable should respond Y) but you are not seeing anything in the PPE engine bind list when doing internet -> WLAN transfers this will only confirm that the PPPoE patch broke the wed acceleration also for DHCP internet connections and maybe for all types. You may also test that wed is working together with bridger, but only from an Ethernet client to a WLAN client, this is the only case when wed is active in the current master build.
3 Likes
To go back to snapshot
auc -b SNAPSHOT
3 Likes
root@RT3200:~# cat /sys/module/mt7915e/parameters/wed_enable
Y
root@RT3200:~# cat /sys/kernel/debug/mtk_ppe/bind
015b8 BND IPv4 5T orig=192.168.1.2:5201->192.168.1.155:5589 new=192.168.1.2:5201->192.168.1.155:5589 eth=xx:xx:xx:xx:xx:41->xx:xx:xx:xx:xx:35 etype=0008 vlan=0,256 ib1=2140121f ib2=007e0060
When I download from Internet on a Laptop (WAN->WLAN) I see CPU usage is 60-70% at 500Mbps.
When I do iperf3 from LAN to WLAN (desktop PC->Laptop) I see CPU usage is 20-25% at 800-900Mbps.
I suppose hardware offloading is working in the second case.
Should I edit /etc/config/bridger - # list blacklist eth0
With master build I see really bad performance on a Samsung Galaxy A20e phone that has only 2.4GHz network. It cannot download more that 2-3Mbps with huge ping above 500ms but most of the time download is less than 1Mbps. It can upload with 30Mbps.
Another smart phone make 40-50Mbps down/up on 2.4GHz WLAN.
I should test if this is related to WED.
60-70% CPU usage seems like an indication of wed not working for NAT (i.e. Internet -> WLAN), we'll have to wait for a fix (or you can revert to a build before the PPPoE fix from 6th of May, if you or others saved it, because it does not apply to your DHCP connection). The bind line shows private IP-s, this is a bridger+wed in action indication. Regarding the bridger config, I am not sure, but I suppose that uncommenting the line will exclude bridger to act between 2 different Ethernet clients, which are already "directly" connected by the switch.
I also saw problems with some wireless clients, especially older ones, but they were more or less related to the wireless security setting, I ended up using WPA2-PSK on both bands in order for all clients to be happy.
1 Like