You are right, it is impossible to force it to 40MHz. Even setting "option htmode HT40+" in etc/config/wireless does not make wireless use two channels.
MT7620 support is broken and I believe 5GHz is only way to use this router under LEDE/OpenWRT (not working under 18.06, unfortunately).
Regarding the bug: something has been done in 18.06 as router will survive "full tx queue" but will lock at "ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0001, signal=0x010d, type=4" instead :(
I just got it to lock by copying a file from NAS. Checked through SSH, CPU was hovering around 12% while copying so obviously, CPU is not the issue.
I am considering switching back to factory firmware.
Unfortunately, Factory firmare without Open VPN, ad block, transmission, Vlans, Fast samba shares & Unlimited freedom is hard to live with.
Hope somebody can fix this famous bug on MT7620 once and for all.
If you really need to run LEDE/OpenWRT on C2, I recommend reverting back to 17.01. 5GHz works fine and without freezing. Just switch off (or rename) 2.4GHz.
Only issues are no KRACK-patches and shorter range.
OK, I just reverted back to:
LEDE Reboot 17.01-SNAPSHOT r3889-a0af7c8c59 / LuCI lede-17.01 branch git-18.098.72829-575e327), Kernel Version 4.4.126
5GHz is rock solid, and very quick with 40MHz channels. Unfortunately, LuCI does not talk to 5GHz driver well so there is basically no info on 5GHz clients. But device works perfect.
2.4GHz is as flaky as it ever was (even in 18.06).
So for now, my plan is to disable 2.4GHz and run with 5GHz on all AP's. As range is bad, I will try to configure 802.11r Fast Transition and let device roam between 5GHz islands.
Or I might just get more C2's to fill in the voids
Update: got roaming to work according to info in this Reddit post
Curiosity: I opened one of my AP's (bricked, tried to se-solder flash chip).
Archer C2 does not have dedicated 5GHz antenna! There is a place for it on PCB but no hardware (copper antenna). PCB strips leading to it do not have components. It seems that 5GHz RF feed is load-balanced into one of two 2.4GHz antennas instead, to save money!
A 1/4 wavelength (lambda) for 2.4 GHz (desired length) is still a 1/2 wavelength (or 2/4s) for 5.8 GHz. Definetly high impedance but this isn't as bad for 20dBm (100mW) as it would be for 37dBm (5000mW) It's like "dualband antennas" for ham radios. A single/multiple of "lambda/4" is desired.
As far as I could see, there was some sort of impedance-matching component in series of 5GHz PCB copper strip leading to antenna. So 5GHz feed is actually matched to 2.4-antenna.
One antenna seems to be used for 5GHz and other for 2.4GHz. As this is non-MIMO device, it doesn't matter.
I still have 2.4 switched off, awaiting working driver.
I have started using 80MHz channels on 5GHz band spread across whole channel range 33-140. Speed is excellent and devices are rock-solid. iPhone 7 tops out around 600Mbit/sec. 5GHz range is rather limited having five devices covers the whole house. I never ever experienced any sort of hang.
I use a iPhone app called "Wi-FiSweetSpot" that graphs connection speed in real-time. I do not know whether it is accurate or not, but it is basically max of what iPhone 802.11ac modem can handle.
Great! Would you mind sharing details on how you configured it to "use legacy WiFi"? Do you mean "non-802.11n"?
In my case, when 2.4GHz hang cycling the network daemon would not make it work. It was only reboot that helped.
You need lot's of packages to trigger this "buffer overflow" condition. In my case, I copied large files from NAS to laptop on local network at the same time as I run Bandwidth tests from my iPhone.
Typical xDSL usage will not push it over the edge.
I tried "Legacy" and it is not really a solution. What it actually does is force client to 802.11g 54Mbit connection. While it probably is stable, it is also very slow.
This trying to fix 2.4G wifi stuck in MT7620 with rt2800
see https://bugs.openwrt.org/index.php?do=details&task_id=896
my test seems ok, "Error - Dropping frame..." printk msg still but no stuck.
add watchdog for tx queues to force reset tx queues when it get stuck
it does exist that: at high loads, status is sure to be missing. we can not avoid it
so a watchdog to do reset for tx queue is necessary
remove the read limit for 'status' in irq.
You can look at the code. It does not prevent the queue to fill up. But it prevent to get stuck forever. It is an improvement.
