RinCat / RTL88x2BU-Linux-Driver

Realtek RTL88x2BU WiFi USB Driver for Linux
GNU General Public License v2.0
1.26k stars 197 forks source link

RF-K not allowed due to ld_iface not stayin union ch #120

Closed lesliev closed 2 years ago

lesliev commented 2 years ago

This driver compiled fine using the make, make install method (not dkms) on Ubuntu with the 5.15.11-051511-generic kernel, installed from a PPA.

When connecting to both 5GHz and 2.4GHz networks though, there were a bunch of errors in syslog:

Jan  3 15:44:40 reddevil NetworkManager[748]: <info>  [1641177880.9110] manager: NetworkManager state is now CONNECTED_GLOBAL
Jan  3 15:44:40 reddevil whoopsie[1647]: [15:44:40] The default IPv4 route is: /org/freedesktop/NetworkManager/ActiveConnection/7
Jan  3 15:44:40 reddevil whoopsie[1647]: [15:44:40] Not a paid data plan: /org/freedesktop/NetworkManager/ActiveConnection/7
Jan  3 15:44:40 reddevil whoopsie[1647]: [15:44:40] Found usable connection: /org/freedesktop/NetworkManager/ActiveConnection/7
Jan  3 15:44:40 reddevil NetworkManager[748]: <info>  [1641177880.9361] device (wlp9s0): supplicant interface state: disconnected -> scanning
Jan  3 15:44:42 reddevil whoopsie[1647]: [15:44:42] online
Jan  3 15:44:43 reddevil NetworkManager[748]: <info>  [1641177883.2367] device (wlp9s0): supplicant interface state: scanning -> disconnected
Jan  3 15:44:51 reddevil systemd[1]: NetworkManager-dispatcher.service: Succeeded.
Jan  3 15:44:56 reddevil systemd[1656]: Started VTE child process 3471 launched by terminator process 2794.
Jan  3 15:45:01 reddevil CRON[3505]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jan  3 15:45:04 reddevil kernel: [  283.007126] RTW: ERROR [RFK-CHK] RF-K not allowed due to ld_iface not stayin union ch
Jan  3 15:45:04 reddevil kernel: [  283.142384] RTW: WARN LPS sctx query timeout, operation abort!!
Jan  3 15:45:09 reddevil kernel: [  288.087111] RTW: ERROR [RFK-CHK] RF-K not allowed due to ld_iface not stayin union ch
Jan  3 15:45:11 reddevil kernel: [  290.119106] RTW: ERROR [RFK-CHK] RF-K not allowed due to ld_iface not stayin union ch
Jan  3 15:45:11 reddevil kernel: [  290.627935] RTW: WARN LPS sctx query timeout, operation abort!!
Jan  3 15:45:13 reddevil kernel: [  292.133098] RTW: ERROR [RFK-CHK] RF-K not allowed due to ld_iface not stayin union ch
Jan  3 15:45:13 reddevil kernel: [  292.641614] RTW: WARN LPS sctx query timeout, operation abort!!
Jan  3 15:45:27 reddevil kernel: [  306.146059] RTW: ERROR [RFK-CHK] RF-K not allowed due to ld_iface not stayin union ch
Jan  3 15:45:30 reddevil dbus-daemon[745]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' requested by ':1.20' (uid=0 pid=775 comm="/usr/lib/snapd/snapd ")
Jan  3 15:45:30 reddevil systemd[1]: Starting Time & Date Service...
Jan  3 15:45:30 reddevil dbus-daemon[745]: [system] Successfully activated service 'org.freedesktop.timedate1'
Jan  3 15:45:30 reddevil systemd[1]: Started Time & Date Service.
Jan  3 15:45:31 reddevil kernel: [  310.328045] RTW: ERROR [RFK-CHK] RF-K not allowed due to ld_iface not stayin union ch
Jan  3 15:45:33 reddevil kernel: [  312.816616] RTW: WARN LPS sctx query timeout, operation abort!!
Jan  3 15:45:52 reddevil kernel: [  330.411983] RTW: ERROR [RFK-CHK] RF-K not allowed due to ld_iface not stayin union ch
Jan  3 15:45:54 reddevil kernel: [  332.405977] RTW: ERROR [RFK-CHK] RF-K not allowed due to ld_iface not stayin union ch

During those "stayin union ch" and "operation abort" errors, ping times were terrible:

╰─➤  ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=1207 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=194 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=116 time=2452 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=116 time=1439 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=116 time=417 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=116 time=1999 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=116 time=981 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=116 time=86.7 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=116 time=1403 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=116 time=401 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=116 time=1835 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=116 time=820 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=116 time=90.6 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=116 time=1341 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=116 time=335 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=116 time=3004 ms
64 bytes from 8.8.8.8: icmp_seq=20 ttl=116 time=1980 ms
64 bytes from 8.8.8.8: icmp_seq=21 ttl=116 time=956 ms
64 bytes from 8.8.8.8: icmp_seq=22 ttl=116 time=2113 ms
64 bytes from 8.8.8.8: icmp_seq=23 ttl=116 time=1097 ms
64 bytes from 8.8.8.8: icmp_seq=24 ttl=116 time=73.9 ms
64 bytes from 8.8.8.8: icmp_seq=25 ttl=116 time=15965 ms
64 bytes from 8.8.8.8: icmp_seq=26 ttl=116 time=14987 ms
64 bytes from 8.8.8.8: icmp_seq=27 ttl=116 time=14026 ms
64 bytes from 8.8.8.8: icmp_seq=28 ttl=116 time=13005 ms
64 bytes from 8.8.8.8: icmp_seq=29 ttl=116 time=11992 ms
64 bytes from 8.8.8.8: icmp_seq=30 ttl=116 time=10972 ms
64 bytes from 8.8.8.8: icmp_seq=31 ttl=116 time=9948 ms
64 bytes from 8.8.8.8: icmp_seq=32 ttl=116 time=8924 ms
64 bytes from 8.8.8.8: icmp_seq=33 ttl=116 time=7900 ms
64 bytes from 8.8.8.8: icmp_seq=34 ttl=116 time=6879 ms
64 bytes from 8.8.8.8: icmp_seq=35 ttl=116 time=5855 ms
64 bytes from 8.8.8.8: icmp_seq=36 ttl=116 time=4845 ms
64 bytes from 8.8.8.8: icmp_seq=37 ttl=116 time=89.0 ms
64 bytes from 8.8.8.8: icmp_seq=38 ttl=116 time=1024 ms
64 bytes from 8.8.8.8: icmp_seq=39 ttl=116 time=41.9 ms
64 bytes from 8.8.8.8: icmp_seq=40 ttl=116 time=1355 ms
64 bytes from 8.8.8.8: icmp_seq=41 ttl=116 time=341 ms
64 bytes from 8.8.8.8: icmp_seq=42 ttl=116 time=1660 ms
64 bytes from 8.8.8.8: icmp_seq=43 ttl=116 time=645 ms
64 bytes from 8.8.8.8: icmp_seq=44 ttl=116 time=1845 ms
64 bytes from 8.8.8.8: icmp_seq=45 ttl=116 time=986 ms
64 bytes from 8.8.8.8: icmp_seq=46 ttl=116 time=64.2 ms
64 bytes from 8.8.8.8: icmp_seq=47 ttl=116 time=1365 ms
64 bytes from 8.8.8.8: icmp_seq=48 ttl=116 time=357 ms

Intermittently, things would quiet down and go to normal pings and no errors:

64 bytes from 8.8.8.8: icmp_seq=764 ttl=116 time=30.2 ms
64 bytes from 8.8.8.8: icmp_seq=765 ttl=116 time=26.9 ms
64 bytes from 8.8.8.8: icmp_seq=766 ttl=116 time=27.4 ms
64 bytes from 8.8.8.8: icmp_seq=767 ttl=116 time=27.6 ms
64 bytes from 8.8.8.8: icmp_seq=768 ttl=116 time=28.1 ms
64 bytes from 8.8.8.8: icmp_seq=769 ttl=116 time=29.4 ms
64 bytes from 8.8.8.8: icmp_seq=770 ttl=116 time=30.8 ms
64 bytes from 8.8.8.8: icmp_seq=771 ttl=116 time=26.9 ms
64 bytes from 8.8.8.8: icmp_seq=772 ttl=116 time=27.0 ms
64 bytes from 8.8.8.8: icmp_seq=773 ttl=116 time=29.0 ms

...only for the errors to come back a few minutes later.

After looking at the similar sounding issue here: https://github.com/brektrou/rtl8821CU/issues/23

...I tried setting the BSSID of the interface, but that made no difference.

Anything I can do to help fix this?

RinCat commented 2 years ago

You may want to disable NetworkManager background scanning. Those errors happens when something want to do full channels scan, and the wifi adapter had to do channel switch, cause you lost packets.

lesliev commented 2 years ago

Thanks for the response! Yes you are correct, when scanning the connection becomes very slow/unstable. But I don't think I can stop it scanning. According to what I've read, setting the BSSID should turn off the scan, but it will not connect at all if I set the BSSID. (Though even removing the BSSID again, it was difficult to connect)

I've noticed that NetworkManager doesn't scan much if the Network configuration is closed, but if it's open, it scans continually, basically killing the connection. I think that scanning is interfering with connecting, as well as normal traffic.

RinCat commented 2 years ago

You may want to check this. But I did not tested that.

lesliev commented 2 years ago

Thanks, that's good to know. It does seem to work, though I've put it back to auto because I've only seen one auto scan over the last hour, so the connection has been stable. It's just when the configuration dialog is open that everything goes haywire.

lesliev commented 2 years ago

I'm going to close this because the solution is basically to avoid scans. But in all, I have many other problems with this driver - it barely works. It will not connect to the 5ghz network at all anymore and it's very spotty with the 2.4ghz one too. Often times it fails to authenticate and keeps asking for secrets even though the password is correct. From boot it often just will not connect at all and I have to turn it off and on again repeatedly for half an hour before it will connect again. This morning the driver even failed to recognise the device (even after replugging) until I recompiled and reinstalled the driver and then replugged it. Then after that, it recognised the device but would not connect on either network.

I wish I'd known how unstable this was going to be - I specially selected this Archer T3U and drove 40km to get it because my onboard wifi doesn't work properly with Linux and this one appeared to have a driver. Work starts tomorrow, I will have to run cables.

If this is your free-time project RinCat, I appreciate your time in any case. I just wish companies would not release network hardware without proper Linux drivers, it's ridiculous.

RinCat commented 2 years ago

I do not have any issue you mentioned. But if you see other issues you will find some people had issues only happened to them. That is usually a weird compatibility issue that may or may not have a way to fix it.

And yes, the overall driver quality is poor, and I created this repo because I had to fix the official driver which does not works in my system.

lesliev commented 2 years ago

Perhaps these problems are specific to the Archer T3U. Which device do you have?

RinCat commented 2 years ago

The one I used had no band but only "1200Mbps USB WiFi Adapter". Maybe your adapter is used in a high-density WiFi environment?