I have four of these (C2 v1) acting as dumb AP's. I have been experimenting with both early OpenWRT port and (recently) LEDE port " LEDE Reboot 17.01-SNAPSHOT r3889-a0af7c8c59 / LuCI lede-17.01 branch (git-18.098.72829-575e327)". Routers work fine but have issue with buggy 2.4GHz support.
As soon as there is lot's of traffic on 2.4GHz, kernel will start writing "phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue" into log and traffic will stop.
And it will stop in worst possible way: device will still be connected to AP but no packets will be able to flow so it will not jump to another available AP but just hand on to one that hang!
I can crash them at will by streaming particularly heavy DLNA stream to VLC on my iPhone using 2.4GHz.
So currently Archer C2 is only usable in 5GHz band under OpenWRT or LEDE. At least that is my experience. If there is newer firmware, do tell.
Basically, there is either bug in the driver or the way Linux sends data to TX buffers. Try to do some heavy transfers with Android or iPhone and kernel log will fill with:
[57135.462195] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[57135.471644] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[57135.481093] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[57135.490615] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[57135.500068] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[57135.509517] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
...and only way to make it work is to pull the plug or log on via Ethernet and force reboot.Just restarting 2.4GHz does not help
Interestingly, this does not affect 5GHz. Unfortunately, 5GHz on Archer C2 is very short range (compared to, say, C7)
So basically, any device using rt2x00 2.4GHz under LEDE or OpenWRT is affected and there is no fix in sight?
Pity. It means that Archer C2 is unusable as LEDE/OpenWRT router on 2.4GHz band (except for very slow internet access, where internet speed is so slow you never risk overloading buffers).
Very crude workaround would be to tail Kernel log and issue reboot as soon as "full tx queue" occurs.
P.S.
I suspect issue is not the hardware (as it works in stock FW), but bad implementation of 2.4GHz driver under OpenWRT / LEDE. 5GHz works fine!
no. it's already fixed in trunk version(and soon to be openwrt 18.06) (as upstream linux kernel fixed inl 4.10 and openwrt uses 4.14) but problem for C2/C20, it's 5Ghz wifi chip (mt7610e) doesn't have driver that complies in kernel 4.14(trunk)
OK, I tried to flash the image you have linked. Unfortunately it didn't work, it just hang the router. (I was able to revive it via TFTP though). The .bin file you posted is 4MB, but the one I used before is 8MB (I have Archer C2 v1.0 which has 8MB of Flash). I assume image you compiled is for another version of router with 4MB of Flash? C20 perhaps?
sorry, that was the version for I tried to make 5g wifi work.
(with https://github.com/Nossiac/mtk-openwrt-feeds)
that somewhy loads at temp modprobe but if failed to reboot..
but It's normal that sysupgrade image of trunk based version are smaller.
No. it won't boot if you import/save old settings. I don't know why
that image doesn't included mt7610e driver, but I think it may still have some problum with importing old config
Before I reflash, can you just give me some info on what is baked in into this image? Is "dropping frame due to full tx queue" fixed in this this patch?
The reason I am asking is because everything works even in the old images, both 2.4GHz and 5GHz. It is just that 2.4GHz will fold during heavy traffic
OK, I re-flashed and cleared settings and it booted fine! I had to manually re-enter settings through LUCI but it is a small price to pay. Unfortunately, 5GHz is gone but it was always rather short-range on Archer C2.
I will run this image couple of weeks and see if 2.4GHz folds during heavy traffic.
I can still lock it at will with only two devices: file copy on laptop and Bandwidth Test on iPhone. It locks and I receive: " ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0001, signal=0x010a, type=4" in Kernel log. Traffic stops flowing (but WiFi device is still connected). Basically same problem but different error.
Also, 40MHz setting on 2.4GHz doesn't seem to work. It is one channel (20MHz) only regardless of setting.
I have run various ports of both OpenWRT and LEDE on mutiple Archer C2 v1's I use as AP's.
All non-factory builds suffer from bug (?) that makes 2.4GHz WiFi freeze when exposed to high load.
Typically, kernel log will have entry "“phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue” and WiFi will stop responding until reboot (but you are still able to log into Luci via Ethernet).
According to information, this issue should have been fixed in 18.06 but it is still present, albeit in another form. Now kernel will log " ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0001, signal=0x010a, type=4" prior to WiFi locking instead.
So either Archer C2 2.4GHz hardware has built-in flaw or there is something wrong with WiFi driver for MT7620A
I'm using Archer C50 which also hosts the same chipset MT7620 and affected by the slow 2.4Ghz bug.
Are you able to find the solution?? 18.06 is meant to solve the issue for our devices but it didn't help.
I do not know if we are talking the same bug? 2.4GHz isn't slow. I was able to hit 7MB/s (megabytes). Key to this was enabling 40MHz channels and disabling legacy speeds.
The main problem is that if router is subjected to hi load (streaming from local NAS, for example) WiFi would freeze and stop sending packets. Device will still be connected to WiFi but there will be no traffic.
You are still able to log on via Ethernet and reboot though.
If you just use router for surfing the net via DSL, you will probably never saturate WiFi enough to knock it offline, but any "power user" will make it fold.
Hi, at least for me, selecting 40Mhz thru luci didn't work, i had to enable it by editing /etc/config/wireless manually thru ssh, and then it did use 40Mhz, even then, 2.4 Ghz seems slow compared to the stock firmware, also, selecting the minimum power did help devices use higher link speeds, especially for me given that i live on an apartment building where 2.4 Ghz Wi-Fi it's congested af!
As for the locking under heavy load, it's the same for me, and having 100Mbps of download means every time some device loads something heavy it crashes the Wi-Fi
