Package Details: rtl88x2bu-dkms-git 5.13.1.r181.2812290-3

Git Clone URL: https://aur.archlinux.org/rtl88x2bu-dkms-git.git (read-only, click to copy)
Package Base: rtl88x2bu-dkms-git
Description: Kernel module for Realtek rtl88x2bu WiFi chipset
Upstream URL: https://github.com/RinCat/RTL88x2BU-Linux-Driver
Keywords: RTL8812BU RTL8822BU
Licenses: GPL2
Submitter: RinCat
Maintainer: RinCat
Last Packager: RinCat
Votes: 50
Popularity: 0.114883
First Submitted: 2018-11-23 23:14 (UTC)
Last Updated: 2023-05-07 23:15 (UTC)

Dependencies (3)

Required by (0)

Sources (1)

Pinned Comments

RinCat commented on 2020-09-20 23:29 (UTC)

If you encountered any problems, set debug log use echo 5 > /proc/net/rtl88x2bu/log_level or modprobe 88x2bu rtw_drv_log_level=5, and post your dmesg and network managers logs to https://pastebin.com/ .

Latest Comments

« First ‹ Previous 1 .. 6 7 8 9 10 11 12 13 14 15 16 .. 19 Next › Last »

bobsicle0 commented on 2021-01-09 23:34 (UTC)

I've been using this driver for a while now, and everything worked fine until a recent system update. Now I get randomly disconnected from my wifi network, and I almost always get disconnected overnight after KDE's power management blanks my monitors. Each time it disconnects, I have to disconnect and reconnect the USB adapter before it will reconnect to my network. Here are my logs from an overnight disconnect (I only extracted the relevant parts of the logs and added some comments for clarification): https://pastebin.com/G4nyyhLz

bmulkern commented on 2020-11-26 15:27 (UTC)

in PKGBUILD changing: arch=('i686' 'x86_64') to arch=('i686' 'x86_64' 'aarch64') builds fine for 5.4.77-1-MANJARO-ARM and works great

Marcuss2 commented on 2020-11-26 11:52 (UTC) (edited on 2020-11-26 12:09 (UTC) by Marcuss2)

Ok, I had some luck with

options 88x2bu rtw_power_mgnt=0 rtw_switch_usb_mode=1

in /etc/modprobe.d/88xbu.conf it was enough to get the Archer T4U working (stop the auth loop), but I guess it depends on which USB port you put it in (USB 3.0 in my case)

RinCat commented on 2020-10-28 06:39 (UTC) (edited on 2020-10-28 06:48 (UTC) by RinCat)

@gibbo3771 your auth loop is likely something wrong in networkmanager, because log said NM do not have key for that device (wlp1s0f0u1u1): no secrets: User canceled the secrets request.. There is also an Authentication with XX timed out., but since EAPOL message can be exchanged, I don't know what's goes wrong. Maybe you can check if the channel you are using is compatible? like @dpm is doing.

gibbo3771 commented on 2020-10-27 18:08 (UTC) (edited on 2020-10-27 18:08 (UTC) by gibbo3771)

Having issues here with constant auth loop. Maybe someone can help me sort it.

OS: Manjaro Awesome

Network Adapter: TP-Link T3U

Log - https://pastebin.com/8Ej8t29Q

I have no idea what to start doing to fix this.

dpm commented on 2020-10-26 19:12 (UTC)

Hi @RinCat, thank you for the suggestion of disabling MAC address randomization. Actually it hasn't worked by itself, but I just have managed to connect to Wifi through T3U. After disabling MAC randomization I have played a bit with the NetworkManager GUI for my Wifi network entry: I have set the "Restrict to device" option to my adapter (even if there were no other options) and I have tried also to restrict to just one BSSID (firstly the 2.4GHz one, then to the 5GHz). I have made these changes in loop twice (because in first place none of them worked), but in the end it worked with the 5GHz BSSID. The situation seems not really stable though since now it is connected but internet has stopped working. To me, it seems that the device only works with a reduced set of WiFi channels, I would try to find a stable situation with my router configuration and report back

RinCat commented on 2020-10-26 06:30 (UTC)

@dpm I found something interesting, in your logs, none of the MAC addresses matched each other. Try disable https://wiki.archlinux.org/index.php/NetworkManager#Configuring_MAC_address_randomization Also some users reported it works in T3U, and I still cannot find what caused it.

dpm commented on 2020-10-25 11:54 (UTC) (edited on 2020-10-25 12:04 (UTC) by dpm)

@RinCat, one thing I could add is the NIC seems to be always in DORMANT state, see

3: wlp3s0f0u2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
    link/ether c6:8f:f9:79:7f:a5 brd ff:ff:ff:ff:ff:ff