rtl8812AU_8821AU_linux
rtl8812AU_8821AU_linux copied to clipboard
abperiasamy
Archer T4UH v.1.0 loses ability to connect to previously connected network
Summary:
After successful connection to 5ghz network Archer T4UH works for approx 4-6 hours then reports disconnection and does not connect back to the same network until reboot. Please see attached kern.log kern.zip .
Steps to reproduce.
- Connect to wifi network
- Leave it connected for 4-6 hours.
- You will receive disconnection notification
- Manual retires to connect it back will be unsuccessful until reboot.
Kernel: 4.9.0-11-linuxium System: Intel atom z-8300 Wintel cx-w8 pro Ubuntu 17.04 driver: 4.3.8
PS. Give me a shout if you need additional info.
PS2: Problems begin here. Apparently it fails to transmit something and refuses to reconnect (probably):
Jan 23 18:19:28
any update on this? I have the same problemm, though it is not dependent on time. sometimes I can go for days without a problem, other times it will happen several times in an hour, and I have yet to find a way to reproduce the issue
I had the same issue with Asus USB-AC56. Problem is resolved in version 5.1.5 of the driver which is available in this repository: https://github.com/uminokoe/rtl8812AU/tree/driver-5.1.5 For TP-Link Archer support you may try one of these forks: https://github.com/mk-fg/rtl8812au https://github.com/ojnickel/rtl8812au
More details for developers:
I compiled drivers with debug logs and tried to pinpoint the root cause of the issue. It doesn't matter if there is high traffic or connection is idle. Here is (shortened) output when hang happened:
kwi 10 22:38:28.985346 Kejk-PC kernel: RTL871X: chk_ap_is_alive(wlan0) rx:(m:0, c:0, d:0), beacon:0, probersp_to_self:0, retry:0 kwi 10 22:38:28.985356 Kejk-PC kernel: RTL871X: chk_ap_is_alive(wlan0) tx_pkts:18690, link_count:2 kwi 10 22:38:29.497333 Kejk-PC kernel: RTL871X: rtw_sctx_wait timeout: rtw_ack_tx_wait kwi 10 22:38:30.009338 Kejk-PC kernel: RTL871X: rtw_sctx_wait timeout: rtw_ack_tx_wait kwi 10 22:38:30.521319 Kejk-PC kernel: RTL871X: rtw_sctx_wait timeout: rtw_ack_tx_wait kwi 10 22:38:30.521346 Kejk-PC kernel: RTL871X: issue_probereq_ex(wlan0) to xx:xx:xx:xx:xx:xx, ch:36, 3/3 in 1536 ms kwi 10 22:38:31.033346 Kejk-PC kernel: RTL871X: rtw_sctx_wait timeout: rtw_ack_tx_wait kwi 10 22:38:31.033377 Kejk-PC kernel: RTL871X: rtl8812au_xmitframe_complete #1, connot alloc xmitbuf!!!! kwi 10 22:38:31.033388 Kejk-PC kernel: RTL871X: rtl8812au_xmitframe_complete #1, connot alloc xmitbuf!!!! kwi 10 22:38:31.033395 Kejk-PC kernel: RTL871X: rtl8812au_xmitframe_complete #1, connot alloc xmitbuf!!!! kwi 10 22:38:31.545346 Kejk-PC kernel: RTL871X: rtw_sctx_wait timeout: rtw_ack_tx_wait kwi 10 22:38:32.057334 Kejk-PC kernel: RTL871X: rtw_sctx_wait timeout: rtw_ack_tx_wait kwi 10 22:38:32.057361 Kejk-PC kernel: RTL871X: issue_nulldata(wlan0) to xx:xx:xx:xx:xx:xx, ch:36, 3/3 in 1536 ms ... kwi 10 22:38:41.273401 Kejk-PC kernel: RTL871X: chk_ap_is_alive(wlan0) rx:(m:0, c:0, d:0), beacon:0, probersp_to_self:0, retry:4 kwi 10 22:38:41.273407 Kejk-PC kernel: RTL871X: chk_ap_is_alive(wlan0) tx_pkts:18748, link_count:3 kwi 10 22:38:41.785343 Kejk-PC kernel: RTL871X: rtw_sctx_wait timeout: rtw_ack_tx_wait kwi 10 22:38:42.297337 Kejk-PC kernel: RTL871X: rtw_sctx_wait timeout: rtw_ack_tx_wait kwi 10 22:38:42.809365 Kejk-PC kernel: RTL871X: rtw_sctx_wait timeout: rtw_ack_tx_wait kwi 10 22:38:42.809386 Kejk-PC kernel: RTL871X: issue_probereq_ex(wlan0) to xx:xx:xx:xx:xx:xx, ch:36, 3/3 in 1536 ms kwi 10 22:38:43.321339 Kejk-PC kernel: RTL871X: rtw_sctx_wait timeout: rtw_ack_tx_wait kwi 10 22:38:43.833355 Kejk-PC kernel: RTL871X: rtw_sctx_wait timeout: rtw_ack_tx_wait kwi 10 22:38:44.345335 Kejk-PC kernel: RTL871X: rtw_sctx_wait timeout: rtw_ack_tx_wait kwi 10 22:38:44.345362 Kejk-PC kernel: RTL871X: issue_nulldata(wlan0) to xx:xx:xx:xx:xx:xx, ch:36, 3/3 in 1536 ms kwi 10 22:38:44.345370 Kejk-PC kernel: RTL871X: linked_status_chk(wlan0) disconnect or roaming kwi 10 22:38:51.581274 Kejk-PC kernel: RTL871X: There are some pkts to transmit 2 kwi 10 22:38:51.581295 Kejk-PC kernel: RTL871X: free_xmitbuf_cnt: 4, free_xmit_extbuf_cnt: 28
Driver keeps checking if connection with Access Point is still alive (chk_ap_is_alive). When there is no traffic it sends empty (?) packets (issue_nulldata, rtw_sctx_wait) and waits for the response. For some reason device hangs and is not sending packages (or handling retrieved responses). The issue_nulldata and rtw_sctx_wait functions are timing out, connection is closed and disconnect signal is send to operating system. Situation is even tricker: sometimes device is able to reset itself (by happy coincident). Driver has build in power saving. If there is no active connection (as in our case) devices in turned off. Usually network manager will try to scan for new WIFI networks after few seconds so device is again powered on and everything is back to normal. After this reset connection is working fine. But if there is something left in xmitbuf or xmit_extbuf buffers then it writes "There are some pkts to transmit" error message to logs and refuses to power off. Unloading kernel module or reconnecting device to USB helps, restart is not required. It looks that the problem is solely in the driver because 5.1.5 version is working fine for me - I tested it for a few days - no hangs, timeouts or disconnects.
@abperiasamy are you planning to use 5.1.5 version?
BTW, official Asus drivers for Windows also has this issue! I even got warranty replacement but issue still persisted.
If anyone is testing with a RTL8811AU / RTL8821AU chipset, please note that my repository is very experimental. I don't have the version 5.1.5 HAL files of the aforementioned chipsets (see this commit) and part of the code regarding the "ant band switch issue" is commented out as a temporary workaround (see this commit).
@uminokoe It is RTL8812AU. I guess that issue is somewhere within HAL but I don't have enough knowledge about drivers to verify it.
@kmaterka The repository by @uminokoe that you referenced is no longer available. I am facing the same issue that you have mentioned in your post. Can you please put your copy of the driver in Github? It will help others who are looking for this version of driver. Thanks
@rks80 Tree up to this commit - https://github.com/mk-fg/rtl8812au/commit/495c2d992cbe318572ed4fdcf5f5cd8f37e93a5a - should be exactly what was in that repo. Though iirc 5.2.20 was a much better and complete version, unlike 5.1.5 that was pieced together from different ones like uminokoe described. That's as of year ago, when I last looked at that driver, there're probably newer releases by now.
i got same problem, the driver print massage something like this
<4>[55574.378111] RTW: There are some pkts to transmit
<4>[55574.382896] RTW: free_xmitbuf_cnt: 0, free_xmit_extbuf_cnt: 32
<4>[55576.330851] RTW: xmit_status_check REG_TXDMA_STATUS:0x00004020
the bug occur time is random, it's hard to dbg. and i also got the msg
RTW: rtw_set_ps_mode(wlan0) Enter 802.11 power save - WIFI-TRAFFIC_IDLE
i found when the problem occur, the driver is no longer exit power save mode
wifi moudle: 6221A-src driver: rtl8821cs interface: sdio2.0 kernal ver: 4.4.194
fixed but don't know the reason:
- wifi driver makefile - CONFIG_POWER_SAVING=n
- kernel config - CONFIG_CFG80211_DEFAULT_PS is not set