-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FS#896 - mt7620 - dropping frames (WiFi) #7408
Comments
psyborg55:
or
are not cause of interface freezing |
psyborg55: patch that suppose to fix this problem: https://lists.openwrt.org/pipermail/openwrt-devel/2015-September/035776.html |
psyborg55: as well as the guy from this issue https://bugs.lede-project.org/index.php?do=details&task_id=557 you could've write exact chipset version which in your case happens to be MT7620N |
lugovykh: Please fix it. I cant use my Xiaomi WiFi mini with LEDE while WiFi 2.4 is broken. |
drut: Is there anything going on with the issue? |
psyborg55: interface freeze in AP+STA mode. try scanning for APs did not work, logs revealed:
after re-enabling interface:
|
dangowrt: I picked up the [[https://lists.openwrt.org/pipermail/openwrt-devel/2015-September/035776.html|patch mentioned above]] with some minor fixes into [[https://git.lede-project.org/?p=lede/dangole/staging.git;a=summary|my staging tree]]. Please build, test and report back. If it improves the situation, we may carry it in our tree for a while and then push it upstream. |
psyborg55: patch might have fixed the issue with the current kernel version at the time it was made but not with latest 4.x.x kernel versions. |
psyborg55: meanwhile i found to change gpio mode:
|
psyborg55: how did you define alc for ht40 +/- 4dB ? |
ambientsummer: Daniel Golle, I use r5049-e53bdcb694 compiled against your tree for 4 days without any problems. |
Cjcr: Daniel Golle: I tested last version of the staging trunk "mac80211: rt2x00: fix rt2800 queue management" doing the "git clone https://git.lede-project.org/lede/dangole/staging.git" and compiling it. The result it is that it hangs very fast and stop working but the tx queue 2 issue doens't appear this time in the logs but the result is the same. Need to restart device to make it working again. It is setup as AP only and I use a just a laptop to connect to it. The connection hangs when reach 100-200 MB @ 3-5 MB/s. Before it only hangs when are more than one client connected. Now it seems that happens even with just one client.
Edit #1: Seems that the hangs is caused just when WMM is activated in N mode, seems not related to the famous tx queue 2 issue. Maybe this is a new bug introduced. Edit #2: For now, the __tx_queue __2 issue doesn't appear in N mode without the WMM (because if I enable this, it hangs very soon, as I said before, this sounds like a new bug). I will update this when I test it a bit more. For now looks good ... Edit #3: 25 GB @ 3 MB/s without crash (N mode, No WMM, 2 clients = phone and laptop) :-) |
kofec: I have similar experience. Uptime is 2 days and till now no issues (Xiaomi MINI) |
Cjcr: kofec can you try to reproduce the hang of the WiFi using N mode with WMM option on? It happens to me with high traffic load |
psyborg55: increasing queue limit decreases throughput. use 128/64 values, if the problem does not re-appear patch might work. |
psyborg55:
sure, somebody followed standards and disabled HT rates for WMM off mode. check again you're connected at 54Mbps. so effectively G mode not N |
Cjcr: psborg55: |
Cjcr: As I said before, N mode is totally broken in the last version of Daniel Golle (LEDE Reboot SNAPSHOT r5049-e53bdcb / LuCI Master (git-17.289.53761-19f30d0)) It crash very quick at high data rates, that doesn't happens before. Can you check it? Thank you. |
kofec: can you merge your latest changes to master. In my case, Im'm using it over a month and it is fine (much better). My hardware is Xiaomi Mini |
Cjcr: @kofec even N mode with WMM is working fine for you?? |
kofec: My configuration for 2,4
|
wjesiek: I have the same problem with Asus RT-N14U on LEDE Reboot 17.01-SNAPSHOT r3566-98c003e. Router hangs up very quickly, only reboot helps.
My wireless settings:
|
hexvar: same problem on my dlink dir-300 I can actually trigger this using a network scan android app: NetxPRO. I don't think it matters.
|
roger-: I seem to be having a similar problem on LEDE Reboot 17.01.4 r3560-79f57e422d on a Nexx WT3020 (8M):
In my case WiFi dies, but seems to come back after some time (don't think I did anything besides logging in over LAN). Is this issue still in trunk? |
Cjcr: It still crash (WT3020) at high rates with the very latest verion (build of yersterday)
LEDE Edit: It is build from https://git.lede-project.org/lede/dangole/staging.git |
kewl5962: TP-LINK MR200 my log is full of : phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 Powered by LuCI Master (git-17.343.27587-8e6b1a6) |
Timeless: I also have this issue with a VGV7519 and WL-351. But I must add that the Wireless connection does not always fail when these messages appear. Sometimes it fails and sometimes I don't notice any hick up. There was a OpenWRT issue about this aswell: https://dev.openwrt.org/ticket/12313 There are also multiple topics about this, I wont link them since I don't think it will help much. |
svobodavac: I have experienced the same problem not only on ramips/mt7620 platform (ZBT-WE2026) There are at least two different issues with the rt2x00 driver.
HOWTO simply reproduce WLAN hangs:
AP in 802.11g mode is stable. PLEASE, PLEASE, help us with the hanging AP in N mode. |
svobodavac: Sorry it sould be: |
kristrev: Hi, I am seeing the same issue and am trying the work-around with unloading/loading modules to get wifi back in a working state. However, I can't seem to figure out which modules to unload. Unloading seemingly relevant modules (like rt2800pci) has no effect, while the board reboots when unloading for example rt2800soc. Any hints or pointers to which module to remove? Also, at least for me, the "Dropping frame ..."-error is harmless. However, in my case, that error message is usually (at some point) followed by the "Arrived at non-free ..." message. When the latter message arrives, wifi always hangs. Thanks in advance for any help, |
rotanid: the actual mt76 bugtracker is there: https://github.com/openwrt/mt76/issues |
Cjcr: There are some news here https://patchwork.kernel.org/patch/10432383/ and here https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=summary about the very well known bug rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue. Someone test it already? I'm compiling it now for WT3020 (8MB) device... let's see. |
Cjcr: I got it and I'm testing it ... If someone wants to test it in WT3020 (8MB) here's the link for It comes with LuCI Web UI, htop and Nano. No USB support. |
Cjcr: An update: 24 GB at 30-50 Mbps with two devices connected (laptop and smartphone) and for now, it's working fine. No wifi dropouts. However, the logs shows the rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2.
Nombre de máquina OpenWrt
Model Nexx WT3020 (8M)
Architecture MediaTek MT7620N ver:2 eco:6
Versión del firmware OpenWrt SNAPSHOT r7880-54dd5ad / LuCI Master (git-18.227.63010-18805b8)
Versión del Kernel 4.14.62
Hora local Thu Aug 16 10:37:05 2018
Tiempo activo 2h 1m 55s
Carga Media 0.00, 0.09, 0.45
Here's the logs:
|
Cjcr: Still working .... |
drut: Isn't this moment that the patch should be applied to OpenWrt then? ;-) |
Cjcr: @A is also working well for you? what device? |
drut: @cjcr I didn't test it yet - I just have ton of WT3020 devices waiting to be re-estabilished in the field when proper software show up, currently no oppoturnity to test tho. |
r0ck3r: Have that bug too on Xiaomi MiWifi Mini UPDATE: |
r0ck3r: @kofec Now I am on 18.06.1, built from source. Since I switched to it I don't had this bug, but I don't think it is related to version - this is only luck, because I don't found anything about this chip in changelog between 18.06.1 and 18.06, on which this bug has appeared twice or more for me. |
ashus: @cjcr I'd like to test the firmware for you on my WT3020 (8MB) - currently having this issue with latest stable OpenWrt 18.06.1. |
Cjcr: Here's the latest one based on https://github.com/sgruszka/openwrt/commits/rt2x00 that includes also some other changes. I'm using it for a week or more and is stable. Luci, nano, usb-support, usb-storage, etc. Sysupgrade: https://mega.nz/#!48oyUKTL!MbNyMtHXjYUn4WS4_TIEKKA77C6f0xi1AshZb3OkpbA |
r0ck3r: Got this bug again on stock 18.06.1 after 13 days of uptime |
pakesusu: well, got this today, cant believe its happening, HC5661 - MT7620A. have been running for several months, and now.. its having same issues:
|
r0ck3r: Reverted to stock 18.06.1 because of very slow WiFi |
ashus: @cjcr I tested this build of yours and never seen this bug again. Tested extensively for 2 days, then a bit less for 3 more days and with another master router. The message never appeared in logs nor was it needed to reboot this OpenWRT router. |
dawncold: I got this error too, my device is MediaTek MT7620A ver:2 eco:6 and firmware version is OpenWrt 18.06.1 r7258-5eb055306f / LuCI openwrt-18.06 branch (git-18.228.31946-f64b152) After I denied two wireless MACs to MAC-filter list, the wireless works for several days, and I still found the kernel log output included ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 Even kernel log output included ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2, if you modify MAC-filter list, the wireless can return to normal, I don't need restart my device. Does anyone want to test it? |
arkhub: @cjcr can you tell me which patch to use and how to compile it, I have the xiaomi mini (MT7260A ver:2 eco:6) and have the same packet dropped problem in 2.4 ghz. Update : I manage to download only the latest patch (b037ec7) using wget and main repository, after that compile it just like in the howto and after few days it seems no more packet dropped, I'll just hope it stays stable like now. |
FeelTheLemon: 7 days passed and no issues with wifi on the snapshot below Model Asus RT-N14U |
cciRRus: //(My device is not an MT7620, so please delete this reply if it is inapprioriate.)// I'm using the stable release OpenWrt 18.06.2, which is very much resistant to the bug, but issue is still there (the bug is definitely not fixed). I am able to trigger the bug with high probability. How could I help fix the bug? Device: Asus RT-N56U |
kofec: I think that you can test the latest changes and share you feedback |
kofec: The best can be download from: |
Vladdrako: Asus RT-N14U. OpenWrt snapshot 11.03.2019. After forcing 40MHz mode or enabling 802.11r: |
cciRRus: I have updated to the latest OpenWrt 18.06.4 released on July 1st, 2019, and the problem is still not fixed. Device: Asus RT-N56U |
Kojoley: The issue still persists. Easily reproducible by simply installing miniupnpd, you will instantly see the log growing with frame drop messages, and by the end of the day the network will halt. Model: Xiaomi MiWiFi Mini |
Kojoley: The problem still persists |
ynezz:
So if I understand this properly, the problem has been fixed in the snapshots builds, but still remain to be fixed in 18.06? Would be nice to know if it has been fixed in the upcoming 19.07 release https://downloads.openwrt.org/releases/19.07-SNAPSHOT/ |
LazzaWA: I have the same issue Fri Oct 4 14:15:42 2019 kern.err kernel: [26189.707975] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 If there is a patch that works for this would someone be able to point me in the right direction of how to apply the patch ... in layman terms please ? I have a home automation setup so losing WIFI means losing all my home automation which as you could appreciate sucks :( . Router firmware is "Powered by LuCI openwrt-18.06-media branch (git-18.301.29719-aeeeafb) / RVWIFI 3.0.7 r0-aeeeafb" |
drut:
Device: Nexx WT3020 (MT7620)
LEDE release: LEDE Reboot 17.01-SNAPSHOT r3435-65eec8b
Latest LEDE on Nexx WT3020 with MT7620 is getting syslog spammed with:
ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
It usually occurs with high-bandwidth usage of WiFi client (Android i.e.) and results with need to reboot router (or WiFi won't even work for devices - it's seen but unable to connect).
# cat /etc/config/wireless
config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11g'
option path 'platform/10180000.wmac'
option country 'PL'
option disabled '0'
option htmode 'HT40'
option distance '3'
option txpower '20'
option channel '6'
config wifi-iface
option device 'radio0'
option mode 'ap'
option ssid 'xxx'
option network 'lan'
option encryption 'psk2+ccmp'
option key 'xxx'
Also it's connected with the issue of android devices loosing connectivity/dropping wifi even 1 meter next to router:
Fri Jul 7 00:32:11 2017 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated
Fri Jul 7 00:32:11 2017 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 2)
Fri Jul 7 00:32:11 2017 daemon.notice hostapd: wlan0: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx
Fri Jul 7 00:32:11 2017 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Fri Jul 7 00:32:51 2017 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: disconnected due to excessive missing ACKs
Fri Jul 7 00:32:51 2017 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED xx:xx:xx:xx:xx:xx
Fri Jul 7 00:32:55 2017 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated
Fri Jul 7 00:32:55 2017 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 2)
Fri Jul 7 00:32:55 2017 daemon.notice hostapd: wlan0: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx
Fri Jul 7 00:32:55 2017 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: pairwise key handshake completed (RSN)
The text was updated successfully, but these errors were encountered: