You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem occurs on the ZBT WG3526 Arch MediaTek MT7621 ver:1 eco:3
When transferring large amounts of data across the 5Ghz band the WiFi radio will randomly stop sending or receiving packets in the default radio configuration. In order to restore connectivity the client device must disassociate from the AP and then re-associate (accomplished by disabling and re-enabling the WiFi on the laptop/device). Then traffic flows normally again until the next drop. This occurs at random intervals and when under heavy traffic load such as a multi-gigabyte file transfer. The device does not have the same issue with wired clients on the switchports.
Tested with three different devices, two with Intel Pro Wireless cards and the other with an embedded Mediatek WiFi chip. All three will randomly experience these drops. I also tried changing channels from 36 to 149 to verify it wasn't some sort of band interference.
As additional testing I configured an GL.iNet AR750S with the same version of OpenWRT (21.02 release) with the same default AP settings on the original band 36 (leaving the WG3536 on 149 to avoid interference). After testing for 2 days I have experienced none of the same drops on the exact same three devices. I have also hammered an iPerf3 server for 20-30 minutes straight without experiencing the same issues.
This device was originally working fine on 18.06.9 and only started to experience these problems after upgrading to 21.02. I have not yet reverted to 18.06.9 as a test, but the problems started immediately after the upgrade. I have also since clean installed OpenWRT 21.02 from firmware recovery on the device to verify it wasn't some sort of bad flash issue.
Not sure if related but I do keep seeing the following messages in the kernel log once and a while and I know hostapd runs the Access Point SSIDs, so it's possible the service is crashing and then restarting:
[53077.551539] Out of memory: Killed process 2440 (hostapd) total-vm:2424kB, anon-rss:120kB, file-rss:1728kB, shmem-rss:0kB, UID:0 pgtables:20kB oom_score_adj:0
[53077.569641] oom_reaper: reaped process 2440 (hostapd), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
The text was updated successfully, but these errors were encountered:
ChronicledMonocle:
Problem occurs on the ZBT WG3526 Arch MediaTek MT7621 ver:1 eco:3
When transferring large amounts of data across the 5Ghz band the WiFi radio will randomly stop sending or receiving packets in the default radio configuration. In order to restore connectivity the client device must disassociate from the AP and then re-associate (accomplished by disabling and re-enabling the WiFi on the laptop/device). Then traffic flows normally again until the next drop. This occurs at random intervals and when under heavy traffic load such as a multi-gigabyte file transfer. The device does not have the same issue with wired clients on the switchports.
Tested with three different devices, two with Intel Pro Wireless cards and the other with an embedded Mediatek WiFi chip. All three will randomly experience these drops. I also tried changing channels from 36 to 149 to verify it wasn't some sort of band interference.
As additional testing I configured an GL.iNet AR750S with the same version of OpenWRT (21.02 release) with the same default AP settings on the original band 36 (leaving the WG3536 on 149 to avoid interference). After testing for 2 days I have experienced none of the same drops on the exact same three devices. I have also hammered an iPerf3 server for 20-30 minutes straight without experiencing the same issues.
This device was originally working fine on 18.06.9 and only started to experience these problems after upgrading to 21.02. I have not yet reverted to 18.06.9 as a test, but the problems started immediately after the upgrade. I have also since clean installed OpenWRT 21.02 from firmware recovery on the device to verify it wasn't some sort of bad flash issue.
Not sure if related but I do keep seeing the following messages in the kernel log once and a while and I know hostapd runs the Access Point SSIDs, so it's possible the service is crashing and then restarting:
[53077.551539] Out of memory: Killed process 2440 (hostapd) total-vm:2424kB, anon-rss:120kB, file-rss:1728kB, shmem-rss:0kB, UID:0 pgtables:20kB oom_score_adj:0
[53077.569641] oom_reaper: reaped process 2440 (hostapd), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
The text was updated successfully, but these errors were encountered: