mirror of
https://github.com/morrownr/8812au-20210820.git
synced 2026-10-14 21:38:30 +00:00
[GH-ISSUE #27] Project: Add 8812au rtw88 in-kernel driver. Need testers... #24
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @morrownr on GitHub (Jun 23, 2024).
Original GitHub issue: https://github.com/morrownr/8812au-20210820/issues/27
Greetings to anyone that reads this message.
This Issue is where we coordinate and take bug reports for the new 8812au in-kernel driver.
An effort is underway to add support for the rtl8812au chipset to the rtw88 in-kernel driver series. The driver is available for testing at the following repo:
https://github.com/lwfinger/rtw88
Remember to first remove the out-of-kernel driver in this repo or whatever repo you may have installed. You can run the following to remove it if using this repo:
$ sudo sh remove-driver.sh
It is important to follow the instructions in the README at the repo with the new test driver. You may not be familiar with rtw88 in the kernel but even if you are, there are some necessary mods that you need to know about. The rtw88 that has this new driver is more advanced than the rtw88 in stable kernels as it follows wireless-next and is used to work on and develop new drivers.
We welcome you to test and report on this new driver. Your testing will help us get this new driver in the Linux kernel sooner and in better shape. If you are aware of anyone who is familiar with mac80211 drivers, please invite them as more eyes on the code is a good thing. Your ideas are most welcome. We can do this.
@morrownr
Status report:
Reports go in this issue.
@tcoard commented on GitHub (Jun 23, 2024):
Updating to kernel 6.9.3 broke my wifi (I was on aircrack-ng/rtl8812au before), so I tried the repo you linked and it works!
System: Pop_OS!
Device: Linksys WUSB6300
USB Ports tried: 3.2 gen2, 3.2 gen1, 2.0
Notes: All ports work, I had to enter the credentials for my wifi network again when trying the 2.0 port.
Let me know if there is any more info you would like. (I don't know much about drivers, so I don't know what information is pertinent to send).
@morrownr commented on GitHub (Jun 23, 2024):
@dubhater
Adding you to this message to make sure you are on this new issue for the 8812au. Note that this Issue is in the 8812au repo. See first report above.
@tcoard
That is great.
Entering credentials again when you switch ports seems to be normal operations. Now to make sure that the driver is switching to be in the correct mode, can I get you to run the following command while in a usb2 port and then again in a usb3 port:
$ lsusb -t
Please post both sets of results. On the line for your driver, you should see 5000 if in usb3 mode and 480 if in usb2 mode. We need to make sure that is happening properly.
Well figure out what info we need as we go. You just keep using it and if something does not work like you think it should, let us know what is wrong and we will tell you what info we need.
Your help is greatly appreciated. It will be cool when this driver is in mainline. Our 8812au adapters will finally have a proper in-kernel driver and will be plug and play.
@tcoard commented on GitHub (Jun 24, 2024):
@morrownr
Yup, I see 5000 if in usb3 mode and 480 if in usb2 mode.
usb3:
usb2:
@Jake-Grafton commented on GitHub (Jun 24, 2024):
The rtw8812au driver works flawlessly with my (previously useless) ALFA AWUS036ACH!
Monitor mode works! (see screenshot)
The driver also works with USB 3 and USB 2.
USB 3 Port:
USB 2 Port:
@kikitte commented on GitHub (Jun 24, 2024):
Finally we get the kernel driver! Thank you!
Model: ALFA AWUS036ACH
UPDATE: Monitor mode works with aircrack-ng but not working with hcxdumptool, I am using the wrong command to test hcxdumptool.
@dubhater commented on GitHub (Jun 24, 2024):
@kikitte Someone sent a fix for those warnings: https://lore.kernel.org/linux-wireless/20240528110246.477321-1-marcin.slusarz@gmail.com/
@Jake-Grafton What is the application in your screenshot?
@Redditor247 commented on GitHub (Jun 24, 2024):
Currently working with this driver. Installed correctly, but can't get this to go into monitor mode for whatever reason. Card being used is an Alfa AWUS036ACH, realtek 8812au driver.
This will connect to Wi-Fi and hold a connection fine, but monitor mode will error out.
UPDATE: tried a clean install of the experimental driver and nothing. Going to keep trying and update as able.
@kikitte commented on GitHub (Jun 24, 2024):
About monitor mode, may be something went wrong in my system, it is not related to this driver, Intel AX200 also not working with hcxdumptool but I can conform it works a few days agoUPDATE: Monitor mode works with aircrack-ng but not working with hcxdumptool. I am using the wrong command to test hcxdumptool.
@Jake-Grafton commented on GitHub (Jun 24, 2024):
hcxdumptool, as it is vastly superior to the aircrack-ng suite.
@morrownr commented on GitHub (Jun 24, 2024):
@dubhater
The author of hcxdumptool is @ZerBea . He was helping with the testing of 8821/11au. He can likely answer questions about hcxdumptool if you have any. We may need to see if anyone has an extra 8812au based adapter that we can get into his hands. Unfortunately I only have one 8812au based adapter or I would get one in the mail to him today.
@ZerBea commented on GitHub (Jun 24, 2024):
@morrownr
No need to send a device, according to this screen shots, hcxdumptool is working as expected:
https://github.com/ZerBea/hcxdumptool/issues/458#issuecomment-2185787738
BTW:
Don't worry about the 160 packets dropped by kernel.
Running monitor mode and interacting with the targets (APs andCLIENTs) places very high demands on the hardware. As a result, some packets are dropped by the kernel.
I'll order this adapter:
https://www.reichelt.de/de/en/usb-3-0-dual-band-wlan-mini-stick-867-mbps-delock-12502-p208115.html?GROUPID=5839&START=0&OFFSET=16&SID=929bb67fe740d35447714c48cdad3a0042274c665a29e76c30d98&LANGUAGE=EN&&r=1
According to Delock, it should be a RTL8812AU based one:
https://www.delock.de/produkt/12502/merkmale.html?setLanguage=en
There is no need to run hcxdumptool on high TX power devices.
https://github.com/ZerBea/hcxdumptool/discussions/419
@castillofrancodamian commented on GitHub (Jun 24, 2024):
@morrownr The
sudo sh remove-driver.shcommand to uninstall the driver is not working. I restart the PC and still see networks in network manager.@alkisg commented on GitHub (Jun 25, 2024):
How about this?
@sisi399 commented on GitHub (Jun 25, 2024):
I've noticed there's ongoing development of a mac80211 driver for the RTL8812AU chip. As someone who's been following this topic casually, I'm hoping for some insights:
Can someone explain the recent developments in layman's terms? What significant changes have occurred?
Historical context: In the past, many issues with RTL8812AU-based devices were attributed to Realtek not releasing mac80211-compatible source code. Has this situation changed?
What prompted this development? Did Realtek change their policy and release source code, or is this an independent effort?
I've seen mentions of a developer named "lwfinger" in relation to this project. Are they affiliated with Realtek, or are they an independent contributor?
Was developing a mac80211 driver always technically feasible, and the delay was due to a lack of developer expertise or interest? Or were there genuine technical or legal barriers that have only recently been overcome?
I've attempted to research these questions independently but haven't found comprehensive answers. As a novice in this field, I'd greatly appreciate any insights from those more knowledgeable about the situation.
Thank you for any information or clarification you can provide!
@morrownr commented on GitHub (Jun 25, 2024):
Hi @sisi399
You are at the right place. Read message one in this thread for instructions on how to test.
Larry Finger passed away last Friday. RIP Larry. He will be greatly missed but we are trying to carry on without him. We are still using his rtw88 repo to do the work. @dubhater and I have the appropriate rights to use the site.
I am really busy right now so maybe we can get to more of your questions later. Right now, we need testers so please read the first message in thread and consider helping us by testing.
Regards,
@morrownr
@dubhater commented on GitHub (Jun 27, 2024):
AP mode should work now.
I also enabled power saving. @castillofrancodamian You will be disappointed:
As far as I can tell, it's because of the way rtw88 decides when to enter power saving and for how long. The official driver makes those decisions differently. Something to ask Ping-Ke about...
@ZerBea commented on GitHub (Jun 27, 2024):
@dubhater
Does this mean that the nl80211 message "NL80211_PS_DISABLED" addressed to "NL80211_ATTR_PS_STATE" will be ignored in monitor mode too?
@dubhater commented on GitHub (Jun 27, 2024):
Is that the same as running
iw wlp3s0f3u2 set power_save off? I don't think rtw88 is ignoring it.@ZerBea commented on GitHub (Jun 27, 2024):
Thanks for that information.
Yes, it is the same - monitored by nlmon & Wireshark:
nlmon in combination with Wireshark is a powerful instrument to debug NETLINK.
Unfortunately we can't trust it 100%. Some drivers report success but ignore the command.
@castillofrancodamian commented on GitHub (Jun 27, 2024):
But from what I understand, that behavior is correct (using an Android phone as reference). What I reported in the past is not the same as the ping you see. In my case there were interruptions in the use of the internet via Wi-Fi, not now.
Maybe what was happening to me was a power saving mode that was not working correctly. In addition, it had other problems, such as complete disconnections from a Wi-Fi network. I no longer notice any of the problems I noticed with the previous controller.
I also notice that enabling and disabling the power saving mode works.
@dubhater commented on GitHub (Jun 27, 2024):
@castillofrancodamian
Oh, I didn't remember that.
More bad news: I have interruptions in the use of the internet. For example, sometimes NetworkManager can't reach ping.archlinux.org for many seconds. If I move the RTL8812AU into a particular position, it stops receiving beacons and gets disconnected from the AP. The distance is about 3 meters, with no obstacles. The AP is on channel 48. The 2.4 GHz band seems better.
I didn't use the official driver long enough to see if it has the first problem, but I did reproduce the second problem with it. It has some code which tries to fix it, doesn't succeed entirely.
@aikawayataro commented on GitHub (Jun 27, 2024):
Is this the right place for a status report 😅?
Im running rtw88 with my AWUS036ACH right now and it works pretty well!
I've made an Arch Linux package for this driver with firmware included, you can find it here (it's "fixed" cuz there's already an rtw88 package, but it's unmaintained).
I will be running it for some time and will report any problems I encounter, thank you!
@morrownr commented on GitHub (Jun 28, 2024):
Hi @aikawayataro
Yes
Nice adapter. I have one.
I'm trying to think about whether putting rtw88 (the one we are using, not mainline) up on AUR is going to have the effect that you are intending. Are AUR users going to know to report problems here? If AUR users post issues at lwfinger/rtw88, I'm not sure that anyone is currently monitoring issues there. The owner, Larry Finger, passed away last week. Dubhater and I do have the rights to change the code at the site but you really don't want us handling the administrator chores as we are shorthanded anyway. It was 3 person team and now it is 2. What might work better is for you to make a post in the appropriate Arch forum that has a link to this issue and instructions to read message 1. Also, make it clear this is about testing rtl8812au based adapters. Things can get really complicated quickly and we really need to try to avoid that if we can.
Looking forward to your 8812au report.
@morrownr
@aikawayataro commented on GitHub (Jun 28, 2024):
Of course, I will leave a comment about 8812au testing with proper place for reports, sorry.
I believe there won't be this kind of problem, I only posted this package link here in my comment and I doubt it will spread much.
My deepest condolences on Larry's passing. He has truly impacted wireless Linux.
@morrownr commented on GitHub (Jun 28, 2024):
He will be missed.
Where is your report?
@castillofrancodamian commented on GitHub (Jun 28, 2024):
I tried to try AP mode but it is not working. Is the configuration file the same as the one presented in USB-WiFi?
This file I tried:
/etc/hostapd/hostapd.conf
@aikawayataro commented on GitHub (Jun 28, 2024):
Originally I just meant a status report that it's working fine.
But now, after using it for a while, I encountered a problem. After some time the wifi connection becomes unstable but still works, I just get a connection timeouts and it goes back to "normal" after a few seconds. The "broken" phase will return after some time, interval I've noticed is close to 10 minutes (sometimes it's longer).
Just unplugging wifi solves the problem for me. Interesting, but it stops working almost 4800 seconds after I plug it. (I observed this delay twice). During unstable wifi, my kernel log is spammed with these messages (
[12122.732596]connected the device,[16932.148366]wifi issue begins):Previous driver I used was https://github.com/aircrack-ng/rtl8812au but sometimes required me to replug my wi-fi after startup and works flawlessly after that (It got broken after recent commit and they ignore user reports so I decided to give rtw88 a shot).
@morrownr commented on GitHub (Jun 28, 2024):
@castillofrancodamian
The settings for AP mode are different for rtw_8821au than for 8821au (the vendor driver) so I expect that to be the case with this driver also. I had not tested AP mode yet for this driver since Dubhater said it was not working but now I'll take a look and will post what I find.
@dubhater commented on GitHub (Jun 28, 2024):
@aikawayataro
"failed to get tx report from firmware" is caused by the power saving.(Edit 4 months later: that's probably a lie.) They are about 22 seconds apart. It's strange that it's so regular.@morrownr commented on GitHub (Jun 28, 2024):
@castillofrancodamian
hostapd.conf settings for rtw_8812au:
ht_capab=[HT40+][HT40-][SHORT-GI-20][SHORT-GI-40][MAX-AMSDU-7935]
vht_capab=[MAX-MPDU-11454][SHORT-GI-80][TX-STBC-2BY1][SU-BEAMFORMEE][HTC-VHT]
Things to keep in mind:
The settings above are based on what the driver says it can do and not me actually testing the settings. I will test but have not had time yet,
Interestingly enough, rtw_8821au actually shows more capability than rtw_8812au. This is not what I am used to seeing with AC600 vs. AC1200.
If the settings do not work, report what you find. rtw88 (mainline) does not have a good track record for supporting what it says it supports but this driver is an add on and I have been following exactly what it is depending on for core support. You are the first tester of AP mode in this driver.
@morrownr commented on GitHub (Jun 28, 2024):
@castillofrancodamian
FYI: The above setting are for band 2 (5 GHz). If you need band 1 settings, let me know.
@morrownr commented on GitHub (Jun 28, 2024):
@dubhater
Bug report:
Debian 12 with kernel 6.6
Country code: US
I am seeing the following for rtw_8812au, which is not correct:
5720 MHz [144] (disabled)
In the same machine, the mt7922 PCIe adapter is showing the following, which is correct:
5720 MHz [144] (24.0 dBm) (radar detection)
Is the rtw_8812au driver using info from the eeprom? At one time, several years ago, the disabled reading would have been correct but that channel has been allowed for several years now in the US.
@aikawayataro commented on GitHub (Jun 29, 2024):
I was too amazed at how regular the interval is. Sometimes it's not 22 seconds, but 12 or even 15 (varies between replugs). The more interesting part is that this behavior always starts 4800 seconds after I plugged it in. I will play with the power for a bit to confirm, thank you.
@morrownr commented on GitHub (Jun 29, 2024):
@dubhater
Disregard the channel available bug report above. I made a mistake.
@amnuhs commented on GitHub (Jun 29, 2024):
cannot enable monitor mode - alfa awus036ach
@morrownr commented on GitHub (Jun 29, 2024):
@amnuhs
Can you provide the steps you used to attempt to enter monitor mode? Thanks.
@castillofrancodamian commented on GitHub (Jun 29, 2024):
I tried again and it is not possible to connect to the AP from an Android device. It tries to get an IP and gets disconnected. I tried connecting with a static IP and it connects but immediately disconnects in a loop.
cat /etc/hostapd/hostapd.conf
cat /etc/dnsmasq.conf
Interface configuration
journalctl -u hostapd
@morrownr commented on GitHub (Jun 29, 2024):
@castillofrancodamian
Hmmm... I am going to go ahead and terminate the current AP mode testing on my RasPi4B and see about testing rtw_8812au.
I'll let you know what I find.
@morrownr commented on GitHub (Jun 29, 2024):
@castillofrancodamian
Back to you.
Looking good here so far. Here is what I am seeing when using the rtll8812au based adapter with hostapd:
Here is the exact hostapd.conf that I am using:
The networking setup can be found in my AP guide on the Main Menu.
@morrownr
@morrownr commented on GitHub (Jun 29, 2024):
@dubhater
rtw_8812au initial AP mode report:
The compilation is based on the rtw88 repo as it was about 10 minutes ago... in other words, I did a clean pull of the repo for AP testing.
Very nice so far. Here are the appropriate parts from the log:
I brought the system up from a cold boot and checked USB mode. It is in USB3 mode.
So far, looking good.
@morrownr commented on GitHub (Jun 29, 2024):
@dubhater @castillofrancodamian
I am running into problems with AP mode now. Let me get an idea of what is going on and I'll let you know.
@castillofrancodamian commented on GitHub (Jun 30, 2024):
@morrownr I got all these errors. There were complete disconnections on several occasions using it as a station.
@dubhater commented on GitHub (Jun 30, 2024):
@castillofrancodamian have you tried different USB ports?
@dubhater commented on GitHub (Jun 30, 2024):
I feel like the disconnections in the 5 GHz band are less likely with this:
@castillofrancodamian commented on GitHub (Jul 1, 2024):
Yes, even those from another device. I still have the same result. The client cannot connect to the AP.
@dubhater commented on GitHub (Jul 1, 2024):
So I checked AP mode now and it's not transmitting any beacons. That would explain why the clients are disconnecting. Actually it behaves similarly to my RTL8811CU:
I checked RTL8811AU and RTL8723DU and they also don't transmit beacons. It seems none of the USB devices are transmitting beacons.
@aikawayataro commented on GitHub (Jul 2, 2024):
Now I get a lot of crashes:
@morrownr commented on GitHub (Jul 2, 2024):
@dubhater
AP mode report, including the latest patch:
Interface comes up. Client able to connect and things work for a short period then the connection dies.
Log is similar to yours:
I tested AP mode with rtw_8821au over a considerable period of time and did not see problems. Should I take another look?
@dubhater commented on GitHub (Jul 2, 2024):
@morrownr Yes, if you can use another device in monitor mode to check if RTL8811AU is transmitting any beacons.
I've been looking into it but no luck so far.
@morrownr commented on GitHub (Jul 2, 2024):
@dubhater
Okay, I am going to set my 8812au adapter aside until it is needed and work with the 8811au adapter. I will test in monitor mode to see if it is transmitting any beacons.
Remember what Larry said: Small steps. Sometimes it is good to back off and take a look at the big picture or just step aside so your brain can do a refresh. Something else to think about and I know it would be more work but separating rtw_8812a and rtw_8821a into separate drivers could help in the long run. Something to think about.
@morrownr commented on GitHub (Jul 3, 2024):
@dubhater
Okay, I set the 8821au based adapter up in AP mode again. I tested it for a couple of hours by just using the client. It just works. I get about 200 Mbps according to iperf3. No drops. No problems noted.
Then I set up a mt7612u based adapter as the mt7612u driver is well know to be a very good chip/driver for monitor mode. I took the unused interface into monitor mode. I then used a couple of ways to look for beacons. I saw beacons from 4 other APs but nothing from my little AP using the rtw_8821au driver. That is not something that I anticipated so had not been checking it.
Have you checked a card that is supported by a driver in rtw88? I only have usb adapters.
What else can I do?
@morrownr commented on GitHub (Jul 3, 2024):
Disregard about the cards. Wired networking doesn't use beacons does it?
To test to make sure something else would not explain the lack of beacons, I changed position with the usb adapters to make the mt7612u adapter the AP and the 8821au adapter the client. Now I see plenty of beacons. That seems to make rtw_8821au the guilty party.
@castillofrancodamian commented on GitHub (Jul 3, 2024):
I can see the SSID on an Android but not on the OpenWrt scanner. I don't understand why in one it is and in another it can't be seen.
@morrownr commented on GitHub (Jul 3, 2024):
@castillofrancodamian
I think we might be seeing this if the
beacon intervalis set way to high. I tested for this with my hostapd.conf file but did not see any difference and I should have seen a difference. What is interesting is that my 2 client systems that I have been testing with are not having a difficult time seeing the bssid and I would have expected that.@morrownr commented on GitHub (Jul 3, 2024):
@castillofrancodamian
My comment above is based on testing AP mode with rtw_8821au as requested by Dubhater. AP mode seems to work extremely well with the rtw_8821au driver as does all other functionality but I did see unexpected results with the far less than expected beacons which seems to indicate a common problem in rtw88.
@dubhater commented on GitHub (Jul 3, 2024):
@morrownr Thanks for testing again. I did test my PCI-based RTL8822CE, it transmits beacons in AP mode, with the exact same rtw88 code.
@castillofrancodamian Devices that use passive scans will not see the network because they just listen for beacons. Devices that use active scans will see the network because they send probe requests and the network answers with a probe response. The probe response contains a lot of the information found in beacons. In our case I'm pretty sure the probe response is being sent by mac80211. The beacon is supposed to be sent by the firmware running on the RTL8812AU's microcontroller.
@morrownr commented on GitHub (Jul 3, 2024):
@dubhater
Thanks for the Active vs Passive Scans lesson.
I did some additional testing on rtw_8821au as AP after sending my report. With the following:
$ sudo airodump-ng wlxblablabla --band a
It found 2 beacons and then nothing more over about 10 minutes. I was seeing constant beacons with the other 4 APs that were within range.
I also used wireshark, but did not see any beacons from rtw_8821au but maybe my eyes are bad.
Why would the beacons appear to stop soon after the scans begin? These are passive scans so ? This seem strange.
@castillofrancodamian commented on GitHub (Jul 7, 2024):
@morrownr In the end the adapter continues to disconnect. The operating system beeps when a USB device is disconnected and matches when the adapter is disconnected.
@morrownr commented on GitHub (Jul 7, 2024):
@castillofrancodamian
I'm still gettings drops in AP mode also. In fact, I do not think any of the drivers in mainline rtw88 do a good job with AP mode. The rtw_8821au driver we were testing before this one is the only one that does a good job in AP mode and it is not in the kernel yet.
I think @dubhater mentioned the other day that we may need an assist from Realtek and it appears that Ping-Ke has tasked one of his devs to take a look... this based on a patch that had been submitted to linux-wireless... which led to a discussion. It seems there is a core problem that needs to be fixed. I hope it is fixed soon.
Side story: I regularly test what I am testing with so as to ensure results are accurate. At one point last week I decided to switch out my 8812au based adapter for a 7612u based adapter. Both are AC1200 class adapters with similar characteristics. Here is what I get in the log with the mt7612u based adapter:
$ sudo dmesg | grep 7612
[ 2.662630] usb 2-2: New USB device found, idVendor=0e8d, idProduct=7612, bcdDevice= 1.00
[ 8.951703] mt76x2u 2-2:1.0: ASIC revision: 76120044
Yes, that is it. It has been up for 6-7 days now. My main box is wearing it out. No drops. No slows down. I've ran iperf3 for long periods and it just keeps going... but I expected that. It also means my AP setup is good. I just have to hang my head. The different between Mediatek and Realtek drivers is like night and day. When is Realtek going to start supporting usb wifi?
/rant
The 8821au drivers is in great shape and we'll get there. I'm looking forward to both the 8821au and 8812au heading to the kernel.
@dubhater commented on GitHub (Jul 7, 2024):
@castillofrancodamian Do you get errors like that if you disable the USB mode switching? rtw_usb has the parameter switch_usb_mode. You can set it to 0.
@dubhater commented on GitHub (Jul 12, 2024):
Those should be gone now.
@dubhater commented on GitHub (Jul 12, 2024):
@castillofrancodamian Maybe those are fixed too? Please pull and test again.
@ZerBea commented on GitHub (Jul 12, 2024):
Today I got two devices (TP-Link Archer T2U and TP-Link Archer T2U Plus).
Running rtw88 driver (compiles fine on 6.9.8-arch1-1), monitor mode is working (but only on first time).
TP-Link Archer T2U
First run, everything is working as expected:
But second run failed!
The device has to be unplugged and plugged back in!
That is exactly the same error as we know from other Realtek devices (rtl8xxxu):
https://bugzilla.kernel.org/show_bug.cgi?id=217205#c72
This bug is still unfixed in latest Linux stock kernel.
The same applies to the second tested device: TP-Link Archer T2U Plus
@ZerBea commented on GitHub (Jul 12, 2024):
BTW:
Please consider to add ZSTD compression (beside GZIP and backdored XZ).
E.g Arch Linux use ZSTD on images
https://archlinux.org/news/moving-to-zstandard-images-by-default-on-mkinitcpio/
and on modules:
@morrownr commented on GitHub (Jul 12, 2024):
@ZerBea
I understand the request but without Larry maintaining the repo, things like this will likely take a backseat, at least until the currently in testing new drivers are upstreamed. I have been slowed again by health issues but also have several things on my to-do list that need to happen in support of this project and rtw88 in general. If you want to take a look and send a PR, @dubhater and I both have the ability to manage the repo.
Nick
@dubhater commented on GitHub (Jul 12, 2024):
@ZerBea Do you have the latest code? I pushed some things today.
I don't have target.bpf, but you gave me this command a while ago:
First I turned off NetworkManager. Then I ran that command several times in a row and every time I got a list of network names. My device is also RTL8811AU (Archer T2U Nano). My kernel is also 6.9.8-arch1-1.
@ZerBea commented on GitHub (Jul 12, 2024):
$ git pull
Already up to date.
tested three devices (rtl8811au, rtl8821au, rtl8821au:
Bus 005 Device 003: ID 7392:a812 Edimax Technology Co., Ltd Edimax AC600 USB
Bus 005 Device 004: ID 2357:0120 TP-Link Archer T2U PLUS [RTL8821AU]
Bus 005 Device 005: ID 2357:011f TP-Link 802.11ac WLAN Adapter
$ hcxdumptool -l
0 3 74da380645e7 f03f032c14d5 * wlp48s0f4u2u4 rtw_8821au NETLINK
1 4 e4fac44d0096 e4fac44d0096 * wlp48s0f4u2u1 rtw_8821au NETLINK
2 5 98254a5b9dc3 98254a5b9dc3 * wlp48s0f4u2u2 rtw_8821au NETLINK
The two rtl8821au devices showing the same behavior if connected to an USB3 port of an MSI B550-A Pro
If connected to an USB2 port, I got this on the second run:
BTW:
I'm running a target filter to prevent that other devices inside my house are targeted by hcxdumptool.
@morrownr commented on GitHub (Jul 12, 2024):
I'll stop what I am working on to do a
git pulland see what I can see on a Debian system.Hmmm.... it looks like Dubhater may have already worked that zst request.
@ZerBea commented on GitHub (Jul 12, 2024):
Some additional information.
This device is not affected:
Bus 005 Device 003: ID 7392:a812 Edimax Technology Co., Ltd Edimax AC600 USB
Chipset is a rtl8811au.
It takes a long time to init, but than it is working as expected (even on the second, third, forth run).
@ZerBea commented on GitHub (Jul 12, 2024):
@morrownr
zstd support is easy to add to Makefile.
@morrownr commented on GitHub (Jul 12, 2024):
@dubhater
Still compiling
rtw88/rtw_8821ae.ko. You know that will conflict with an existing driver.... you pointed it out to me at one point so this is just a reminder.@dubhater commented on GitHub (Jul 12, 2024):
@morrownr Right, I deleted it now.
@ZerBea Do you get the same problem if you load rtw_usb with
switch_usb_mode=0?@ZerBea commented on GitHub (Jul 12, 2024):
switch_usb_mode=0 solves the problem.
Now rtl8821au works on first, second, third, forth time as expected.
And I figured out why this happens:
usually dmesg is a fast command:
But if the driver is in init process, it will take a long time:
terminal 1:
$ sudo hcxdumptool
terminal 2:
If I plug a second device within this init time, this failure occurs:
@ZerBea commented on GitHub (Jul 12, 2024):
I have similar problems with mt76 on OpenWRT.
Here it is mandatory to set "/bin/sleep 10" to make sure the driver has been loaded and the device has been init.
@ZerBea commented on GitHub (Jul 12, 2024):
This is definitely a USB problem that does not appear on a PCIe card:
04:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8821CE 802.11ac PCIe Wireless Network Adapter
terminal 1:
$ sudo hcxdumptoolterminal 2:
@dubhater commented on GitHub (Jul 12, 2024):
But wait, that makes no sense. rtw_8821au is not even trying to switch to USB 3.
switch_usb_mode=0should have no effect.@morrownr commented on GitHub (Jul 12, 2024):
I am testing with my little Alfa adapter with a rtl8811au chip. I am using a USB3 extension cable because it was handy and should not make a difference. It is plugged in a USB2 port. Should I test with a USB3 port?
I have ran
hcxdumptool -i wlan0 --rds=1several times and it captured packets and looked normal each time without rebooting or replugging the adapters.Here is the log:
$ sudo dmesg | grep 8821
[ 5.698818] rtw_8821au 1-1.1:1.0: firmware: direct-loading firmware rtw88/rtw8821a_fw.bin
[ 5.698929] rtw_8821au 1-1.1:1.0: Firmware version 42.4.0, H2C version 0
[ 5.830976] usbcore: registered new interface driver rtw_8821au
[ 5.834948] rtw_8821au 1-1.1:1.0 wlx00c0caac47c7: renamed from wlan0
Nice job cleaning up the log!
Only complaint is that
hcxdumptooldoes not give me back my wifi interface in the same state that I gave it tohcxdumptool. Even my little script that handles taking the system into monitor mode asks if you want the interface returned to previous settings. Not a big deal Mike... but I needed something to report. :)@aikawayataro commented on GitHub (Jul 13, 2024):
@dubhater
Thanks! I can no longer observe them. I also can't observe the suspected power related tx problem in the last few weeks (possibly linux kernel update solved this).
Is there anything specific I can test on 8812au?
@ZerBea commented on GitHub (Jul 13, 2024):
@morrownr hcxdumptool does not switch the interface back to managed. This behavior is wanted in case you run tshark/Wireshark in parallel. If the user do not want this it it is mandatory to use iw / macchanger to go back to initial mode.
@dubhater
I'll do some more tests and I have an idea: I'll add some time measurement debug function to figure out where it hangs.
Even if switch_usb_mode=0 makes no sense, it took some time to type it into the terminal. Enough additional time to complete the init process of the device. That is similar to the sleep on the AXML.
Also there is a difference between the rtl8811au and the rtl8821au chip.
@ZerBea commented on GitHub (Jul 13, 2024):
As already suspected, the chipset init process is different:
I added some time measurement functions to two NL80211 and one RTNETLINK function.
All USB devices are slower then the PCIe card. Some more, some less.
Now that I know this, I can take care about it.
Thanks for pointing me to this direction.
Regarding rtw_8821ce and rtw_8821au the driver is working as expected. I just have to give it more time.
@Samt43 commented on GitHub (Jul 13, 2024):
Hi all,
AP beacon issue not sent using RTW88 is the same on 8822bu device, please see my original report here : https://github.com/lwfinger/rtw88/issues/112
On my side i never found the reason unfortunatly, i think all usb devices are impacted. Thanks a lot for all your work !!
@Samt43 commented on GitHub (Jul 13, 2024):
@morrownr
Do you know which patch were you talking about ?
@castillofrancodamian commented on GitHub (Jul 13, 2024):
The disconnections continue.
How could I change that USB parameter?
@morrownr commented on GitHub (Jul 13, 2024):
@Samt43
I'd have to go search... the title started with
[PATCH] wifi:rtw88@a5a5aa555oo commented on GitHub (Jul 14, 2024):
@castillofrancodamian You can simply run this command and then reboot. it will create a file called
rtw_usb.conf in /etc/modprobe.d and prevent your wifi adapter from switching to USB 3 mode.
sudo sh -c 'echo options rtw_usb switch_usb_mode=0 > /etc/modprobe.d/rtw_usb.conf'@dubhater i noticed that castillofrancodamian's device is TP-LINK Archer T4UHP (0x2357, 0x010f),
a high power usb adapter, will the problem be caused because of it?
@castillofrancodamian commented on GitHub (Jul 14, 2024):
Would doing that cause USB 2.0 to be used?
@a5a5aa555oo commented on GitHub (Jul 14, 2024):
https://patchwork.kernel.org/project/linux-wireless/patch/77906c62-5674-426f-bde1-1b2a12a0339d@gmail.com/
Yes, according to the description of Bitterblue(dubhater)'s patch, set this parameter to 0 will make wifi adapter stay in
USB 2 mode, but i dont know if 8812au is also applicable.
You can delete /etc/modprobe.d/rtw_usb.conf if you dont like it, and your wifi adapter will go back to USB 3 mode after reboot.
@morrownr commented on GitHub (Jul 14, 2024):
It should be applicable. The patch does not mention the 8812au because it is not in the kernel yet.
Another way to have the adapter in USB2 mode is to use a USB2 port if one is available..
@dubhater commented on GitHub (Jul 14, 2024):
@morrownr sure, why not?
@Samt43 this one: https://lore.kernel.org/linux-wireless/44061283fd014cbc898a382ed5c3c26b@realtek.com/
@a5a5aa555oo I don't know.
@castillofrancodamian commented on GitHub (Jul 22, 2024):
Wi-Fi disconnections every few seconds.
@dubhater commented on GitHub (Jul 22, 2024):
@castillofrancodamian What channel are you using? Mine is disconnecting a lot on channel 48 but not as much on channel 132. You can also try moving the adapter a few centimeters. It makes a big difference for me. There are spots where it can't receive anything, but 5 centimeters to the left is fine.
The full dmesg would be useful.
@dubhater commented on GitHub (Jul 23, 2024):
I finally found it: RTL8812AU (and the others) can transmit beacons in AP mode now.
@castillofrancodamian commented on GitHub (Jul 23, 2024):
I tried between different USB 2 and USB 3 ports (like their physical position) and the disconnections definitely occur when plugged into any of the USB 3 ports. No matter what Wi-Fi network (and channel) I connect to, the result is the same.
sudo dmesg
@morrownr commented on GitHub (Jul 23, 2024):
@dubhater
That is great.
What I need at this point is for you to tell me exactly what you want me to do. Should I test AP mode on rtw_8812au?
@dubhater commented on GitHub (Jul 23, 2024):
@morrownr Yes, please.
@castillofrancodamian You don't get all those "USB disconnect" errors with 8812au-20210820, do you?
@castillofrancodamian commented on GitHub (Jul 23, 2024):
I can't uninstall the rtw88 driver.
@morrownr commented on GitHub (Jul 24, 2024):
Somebody was playing with the Makefile. Try:
$ sudo make install
$ sudo make uninstall
@castillofrancodamian commented on GitHub (Jul 24, 2024):
I get
@a5a5aa555oo commented on GitHub (Jul 24, 2024):
Run these commands and then reboot, and the rtw88 driver will be removed.
sudo rm -v /lib/modules/$(uname -r)/kernel/drivers/net/wireless/realtek/rtw88/rtw_*.ko*sudo depmod -a@castillofrancodamian commented on GitHub (Jul 24, 2024):
The first command didn't work. This is the content of that directory:
Even so, I no longer see the adapter available when I restart the PC. I think it was solved by updating the kernel to 6.10 without having to use that first command.
I have also noticed that the rtl8812au driver is still being compiled when updating the kernel. Is there any log to show what I see when doing that process? Maybe that's the reason for all the problems.
@morrownr commented on GitHub (Jul 24, 2024):
Look at the difference in the driver names.
The first name is the name from rtw mainline. The second name is what Larry did to keep from having conflicts.
Edit: Mistake in the above line. rtw_8723cs is Larry's naming. rtw88_8723cs is the Mainline name. Larry did this to avoid conflicts and allow users to use this repo as an out-of-kernel driver.
@dubhater
I think you did this.
@castillofrancodamian
You probably don't want to mess with this until @dubhater decides what to go.
@morrownr commented on GitHub (Jul 24, 2024):
@dubhater
That is what I am seeing. Gotta be careful changing those names. I know you are working on patches to upstream but you are breaking this repo.
@a5a5aa555oo commented on GitHub (Jul 24, 2024):
Maybe your rtl8812au driver was installed via dkms, you can check it with this command.
sudo dkms status@a5a5aa555oo commented on GitHub (Jul 24, 2024):
@dubhater I have a question:
I checked uninstall step in Makefile, won't the system crash
if a driver for PCI-E wireless adapter is unloaded on a running system?
@Samt43 commented on GitHub (Jul 24, 2024):
@dubhater @morrownr : I tried 4a1ee64475672a9186e10d87ac5e251448f86914 (beacon fix) with a 8822bu device. In my case, unfortunatly i still can't see my hotspot on 5GHz band using an intel wifi card (windows 10) and also my lenovo duet device (chromeos). Using realtek driver, i have no issue. My phone (realtek) and my android box (mediatek) can both see it (for these two devices hotspot seems to work). Not sure your fix fix beacon issue for 8822bu device unfortunatly :'(
@dubhater commented on GitHub (Jul 24, 2024):
@morrownr I thought one of the pull requests I merged recently broke it, but no, that part of the Makefile hasn't changed. It actually looks like a bug in modprobe. From its manual:
@a5a5aa555oo I'm unloading rtw_8822ce all the time and nothing bad happens.
@castillofrancodamian You don't need to uninstall rtw88, or to install 8812au. It's enough to manually unload rtw_8812au (the others don't matter for this case), then you can load 8812au. Works until you reboot.
@dubhater commented on GitHub (Jul 24, 2024):
Or maybe one of those changes did break it. The SDIO drivers should be uninstalled only if they were compiled.
@a5a5aa555oo commented on GitHub (Jul 24, 2024):
I made a patch to fix it, I'll open a pull request later.
@castillofrancodamian commented on GitHub (Jul 24, 2024):
That's how it is. When I tested the rtl8812au driver I did it using dkms.
I get:
@a5a5aa555oo commented on GitHub (Jul 24, 2024):
@castillofrancodamian
If you don't want rtl8812au driver be built/installed during a kernel update, you can remove it.
sudo dkms remove rtl8812au/5.13.6 --all@castillofrancodamian commented on GitHub (Jul 24, 2024):
The rest of the driver remains unremoved.
After reboot.
I think I'm going to have to use the old reliable: reinstall the operating system.
@a5a5aa555oo commented on GitHub (Jul 24, 2024):
Before reinstalling your OS, try just removing /var/lib/dkms/rtl8812au-5.13.6
sudo rm -rf /var/lib/dkms/rtl8812au-5.13.6@castillofrancodamian commented on GitHub (Jul 24, 2024):
It appears to have been removed.
@morrownr commented on GitHub (Jul 24, 2024):
Another way to correct that problem:
sudo apt purge dkms
That is for Debian but the idea is to uninstall it. You can always reinstall it if you actually need it.
@castillofrancodamian commented on GitHub (Jul 24, 2024):
I reinstalled rtl8812au (after removing rtw_8812au) using dkms as asked by dubhater in this comment, so I don't want to remove dkms at the moment.
@morrownr commented on GitHub (Jul 24, 2024):
@castillofrancodamian
I understand but the 8812au driver in this repo can be installed without dkms:
$ make
$ sudo make install
Just trying to give you an option to clean up that specific dkms issue.
@castillofrancodamian commented on GitHub (Jul 24, 2024):
@morrownr I already installed rtl8812au manually and I see the same symptoms as with
rtw_8812au. Disconnections when plugged into USB port 3 and no disconnections in USB port 2, although it is still having problems. I am once again having the very high pings and unpredictable interruptions that I have previously reported on thertl8812aucontroller. Dmesg does not report as much as when thertw_8812audriver is installed.Installation
@dubhater commented on GitHub (Jul 25, 2024):
@castillofrancodamian That's a relief. :)
Are you using tlp ?
@castillofrancodamian commented on GitHub (Jul 25, 2024):
What's that? A tool?
@dubhater commented on GitHub (Jul 25, 2024):
Something that causes problems: https://wiki.archlinux.org/title/TLP
@morrownr commented on GitHub (Jul 25, 2024):
I've been sick for 3 days but will test AP mode on rtw_8812au as a priority as able.
@Samt43 commented on GitHub (Jul 25, 2024):
Hi @dubhater , i could test again rtw88 driver on :
github.com/lwfinger/rtw88@4a1ee64475Here is a airdump with realtek driver vs rtw88 driver :
capture_wsl1_channel36_r.zip
With rtw88, we can clearly see that the driver is now sending some beacons at the begining (network is hacksterwifi2) (this is new, i think your commit solved this !). But after some seconds, beacons stop (this seems to be as soon as my device has tried to connect)
@Samt43 commented on GitHub (Jul 25, 2024):
On some devices (ex : my phone) connexion continue to work even when beacons stop.
Here is logs :
[ 1192.471094] usbcore: deregistering interface driver rtl88x2bu
[ 1192.626030] rtl88x2bu 1-1.4.4.1:1.0: Runtime PM usage count underflow!
[ 1208.418609] rtw_8822bu 1-1.4.4.1:1.0: Firmware version 27.2.0, H2C version 13
[ 1209.047809] rtw_8822bu 1-1.4.4.1:1.0: write register 0xc4 failed with -71
[ 1209.048021] rtw_8822bu 1-1.4.4.1:1.0: rtw_usb_reg_sec: reg 0x4e0, usb write 1 fail, status: -71
[ 1209.048565] usbcore: registered new interface driver rtw_8822bu
[ 1209.295399] usb 1-1.4.4.1: USB disconnect, device number 10
[ 1209.691036] usb 1-1.4.4.1: new high-speed USB device number 16 using dwc_otg
[ 1209.822318] usb 1-1.4.4.1: New USB device found, idVendor=0bda, idProduct=b812, bcdDevice= 2.10
[ 1209.822352] usb 1-1.4.4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1209.822366] usb 1-1.4.4.1: Product: 802.11ac NIC
[ 1209.822377] usb 1-1.4.4.1: Manufacturer: Realtek
[ 1209.822388] usb 1-1.4.4.1: SerialNumber: 123456
[ 1209.824022] rtw_8822bu 1-1.4.4.1:1.0: Firmware version 27.2.0, H2C version 13
[ 1211.203343] usbcore: registered new interface driver rtl88x2bu
[ 1211.228381] rtw_8822bu 1-1.4.4.1:1.0 wlx1cbfce35170a: renamed from wlan0
[ 1218.994973] IPv6: ADDRCONF(NETDEV_CHANGE): wlx1cbfce35170a: link becomes ready
[ 1880.579920] rtw_8822bu 1-1.4.4.1:1.0: error beacon valid
[ 1880.580259] rtw_8822bu 1-1.4.4.1:1.0: failed to download drv rsvd page
[ 2217.888445] rtw_8822bu 1-1.4.4.1:1.0: error beacon valid
[ 2217.888781] rtw_8822bu 1-1.4.4.1:1.0: failed to download drv rsvd page
Please note that beacon and drv rsvd page failure do not always happen (whatever if the beacons are working or not)
@Samt43 commented on GitHub (Jul 25, 2024):
Using airdump, we can clearly see no beacons are emitted on channel 36 currently, eventhough hotspot is working on some devices
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
30:93:BC:9F:C0:D5 -77 10 4 0 100 1733 WPA2 CCMP PSK Livebox-C0D0
6C:61:F4:68:7E:05 -79 8 0 0 52 1170 WPA2 CCMP PSK SFR_7E00_5GHZ
72:61:F4:68:7E:07 -79 7 0 0 52 1170 WPA2 CCMP PSK SFR_7E00
1C:BF:CE:35:17:0A -1 0 0 0 36 -1 <length: 0>
BSSID STATION PWR Rate Lost Frames Notes Probes
30:93:BC:9F:C0:D5 20:1F:3B:83:81:53 -72 0 - 6 0 1
1C:BF:CE:35:17:0A 6A:31:75:8E:97:33 -61 0 - 6 0 1
1C:BF:CE:35:17:0A FC:02:96:E9:65:10 -38 0 - 6e 0 4
Quitting...
@castillofrancodamian commented on GitHub (Jul 25, 2024):
My PC is a desktop. Therefore it is not an energy problem.
@dubhater commented on GitHub (Jul 27, 2024):
This should be fixed now.
@Samt43 commented on GitHub (Jul 27, 2024):
@dubhater i confirm that
github.com/lwfinger/rtw88@610e04fc38fixed definitively beacon issues on 8822bu. Well done, thank you for all your team work, this is really impressive !I noticed that bitrates are quite low compared to realteck driver :
Connecting to host 10.0.0.1, port 5201
[ 5] local 100.115.92.198 port 60874 connected to 10.0.0.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 6.27 MBytes 52.6 Mbits/sec 3 211 KBytes
[ 5] 1.00-2.00 sec 9.13 MBytes 76.6 Mbits/sec 0 242 KBytes
[ 5] 2.00-3.00 sec 8.82 MBytes 74.0 Mbits/sec 1 266 KBytes
[ 5] 3.00-4.00 sec 8.70 MBytes 73.0 Mbits/sec 0 290 KBytes
[ 5] 4.00-5.00 sec 5.78 MBytes 48.5 Mbits/sec 2 235 KBytes
[ 5] 5.00-6.00 sec 9.13 MBytes 76.6 Mbits/sec 0 264 KBytes
[ 5] 6.00-7.00 sec 9.45 MBytes 79.2 Mbits/sec 0 280 KBytes
[ 5] 7.00-8.03 sec 11.8 MBytes 95.6 Mbits/sec 0 307 KBytes
[ 5] 8.03-9.00 sec 10.9 MBytes 94.3 Mbits/sec 0 334 KBytes
[ 5] 9.00-10.00 sec 10.4 MBytes 87.0 Mbits/sec 2 355 KBytes
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 90.3 MBytes 75.8 Mbits/sec 8 sender
[ 5] 0.00-10.04 sec 89.7 MBytes 75.0 Mbits/sec receiver
iperf Done.
In normal times, i have around 200mb bandwidth, so something is still wrong. But what a progress !
@morrownr commented on GitHub (Jul 27, 2024):
@Samt43
Clarify for us:
You are adapter is based on a rtl8822bu or rtl8812bu chip?
Running USB2 or USB3 mode? $ lsusb -t
@dubhater is really good. Now, if I could get him to stop fixing things for a couple of days and clean up some patches to send upstream.
@Samt43 commented on GitHub (Jul 28, 2024):
@morrownr i wouls say rtl8822bu, as i'm loading the driver using :
sudo modprobe rtw_8822bu
Here is are some logs, using the realteck driver.
Bus 001 Device 010: ID 0bda:b812 Realtek Semiconductor Corp. RTL88x2bu [AC1200 Techkey]
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.10
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0bda Realtek Semiconductor Corp.
idProduct 0xb812 RTL88x2bu [AC1200 Techkey]
bcdDevice 2.10
iManufacturer 1 Realtek
iProduct 2 802.11ac NIC
iSerial 3 123456
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0035
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 5
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 2 802.11ac NIC
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x06 EP 6 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87 EP 7 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 3
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x08 EP 8 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Binary Object Store Descriptor:
bLength 5
bDescriptorType 15
wTotalLength 0x0016
bNumDeviceCaps 2
USB 2.0 Extension Device Capability:
bLength 7
bDescriptorType 16
bDevCapabilityType 2
bmAttributes 0x00000002
HIRD Link Power Management (LPM) Supported
SuperSpeed USB Device Capability:
bLength 10
bDescriptorType 16
bDevCapabilityType 3
bmAttributes 0x00
wSpeedsSupported 0x0006
Device can operate at Full Speed (12Mbps)
Device can operate at High Speed (480Mbps)
bFunctionalitySupport 1
Lowest fully-functional device speed is Full Speed (12Mbps)
bU1DevExitLat 10 micro seconds
bU2DevExitLat 1023 micro seconds
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0000
(Bus Powered)
sudo lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M
|__ Port 3: Dev 4, If 0, Class=Vendor Specific Class, Driver=rt2800usb, 480M
|__ Port 4: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 4: Dev 9, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 3: Dev 12, If 0, Class=Vendor Specific Class, Driver=usbfs, 480M
|__ Port 3: Dev 12, If 1, Class=Vendor Specific Class, Driver=, 480M
|__ Port 1: Dev 10, If 0, Class=Vendor Specific Class, Driver=rtl88x2bu, 480M
|__ Port 4: Dev 14, If 0, Class=Vendor Specific Class, Driver=dvb_usb_af9035, 480M
|__ Port 2: Dev 15, If 3, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 2: Dev 15, If 1, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 2: Dev 15, If 4, Class=Mass Storage, Driver=usb-storage, 480M
|__ Port 2: Dev 15, If 2, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 2: Dev 15, If 0, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 2: Dev 8, If 0, Class=Vendor Specific Class, Driver=dvb_usb_dib0700, 480M
|__ Port 1: Dev 7, If 0, Class=Mass Storage, Driver=usb-storage, 480M
|__ Port 5: Dev 6, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 5: Dev 6, If 1, Class=Wireless, Driver=btusb, 12M
I only have usb 2.0, but even for 2.0, bandwith is adnormally low compared to realtek driver
@dubhater commented on GitHub (Oct 31, 2024):
"failed to get urb length:32768" and "Rate marked as a VHT rate but data is invalid" errors are fixed now.
@duc5800 commented on GitHub (Feb 8, 2025):
Hi,
I updated to Mainline kernel 6.13, but there is no driver loaded for my RTL8812AU adapter and hence it doesn't show up in Ubuntu.
The hardware ID is part of the current code https://github.com/torvalds/linux/blob/master/drivers/net/wireless/realtek/rtw88/rtw8812au.c .
Is the in-kernel driver supposed to be included in 6.13 already or do I need to wait for 6.14?
@morrownr commented on GitHub (Feb 8, 2025):
Hi @duc5800
I can answer yes to both of those questions. I can dig this information out but I think my memory is good...
The 8812au driver went into 6.13, however, the updated rtw8812au.c file did not go in until 6.14 so you may be seeing your id in the current file in the current version of the kernel but that does not mean the complete file was in 6.13. Sorry about that. You can blame me as I worked on that file.
There is also the issue of whether you have the firmware file in your installation. Remember that it takes both the driver and the firmware for the driver to function. The Main Menu of this site is:
https://github.com/morrownr/USB-WiFi
Menu item 7 addresses firmware.
Probably the easiest way to be up and running until 6.14 is ready is to use the repo where the driver was developed as it can be installed:
https://github.com/lwfinger/rtw88
Let me know what you think of the driver.
@duc5800 commented on GitHub (Feb 8, 2025):
Thanks for your explanation.
The firmware file rtw8812a_fw.bin did indeed not exist in the folder /lib/firmware/rtw88.
I might try the driver by lwfinger at a later time.
By the way, a successful build of kernel 6.14-RC1 has just showed up on Mainline. I tried it quickly, but my TP-Link T4U v2 was still not working. (that was with the file rtw8812a_fw.bin already inside /lib/firmware/rtw88)
@morrownr commented on GitHub (Feb 8, 2025):
Yes, Ubuntu Mainline. Thanks for letting me know. I hope that repo stays fixed as it is handy for the testing I do.
Well, here is the deal. Just because a driver enters the kernel does not mean that it will instantly show up as a compiled driver. The maintainers of the distro have to turn on compilation for this new driver for it to be compiled. Did you check to see if the driver is actually compiled and in place? If it is not there then the Ubuntu maintainers have not turned on compilation yet.
$ find . -name rtw88_8812au.ko*
It is a challenge to be on the bleeding edge with new drivers. It is not hard to use the lwfinger/rtw88 drivers and that is the repo we have used and continue to use to test what is going into the kernel so you would actually be doing us a favor by testing it. When you don't need it anymore, it is easy to uninstall.
@duc5800 commented on GitHub (Feb 8, 2025):
Thanks, I didn't know that.
The file you mentioned exists in kernel 6.13 as well as 6.14rc1.
So it should be a matter of the hardware ID 2357:010d not having it made into these kernel builds, right?
@duc5800 commented on GitHub (Feb 8, 2025):
I just noticed there was still a *.conf file present in /etc/modprobe.d that blacklisted the in-kernel driver. A leftover from a previous driver installation.
After removing that file the final conclusion is that the TP-Link T4U v2 with hardware ID 2357:010d does work fine with kernel 6.14rc1 using the in-kernel rtw88 driver!
The T4U v2 works in USB 3 mode with this rtw88 driver. Data throughput with iperf3 fluctuates, but does go up to 370 Mbps.
I am sorry for causing the confusion above.
@morrownr commented on GitHub (Feb 9, 2025):
Glad you have it going.
If it was the driver in this repo then if you had run the remove-driver.sh script, it would have removed the .conf file. Are you sure that the driver in this repo is uninstalled?
$ dkms status
FWIW: I went over the the following to check if your device ID was in 6.14rc1:
https://github.com/torvalds/linux
It was.
Then I plugged my adapter into the system that I updated with 6.14rc1 earlier today and it worked. That is good and it tells me the Ubuntu devs have already taken care of turning on the compiling of the driver and they have added the firmware. When Ubuntu 25.05 ships with kernel 6.14, a lot of people with Realtek WiFi 5 adapters should be happy.
Switching to USB3 mode is now automatic for the USB3 capable adapters in rtw88... works just like the Mediatek drivers.
370 Mbps is not bad at all. The 8812au should show around 400 Mbps if there is little to no congestion so you appear to be in good shape. Give it a good workout and let us know what you find.
@Simon566 commented on GitHub (Feb 14, 2025):
im still seeing things like
Feb 14 08:22:21 odroid-h3 kernel: rtw_8812au 1-2:1.0: error beacon valid
Feb 14 08:22:21 odroid-h3 kernel: rtw_8812au 1-2:1.0: failed to download drv rsvd page
Feb 14 08:22:21 odroid-h3 kernel: rtw_8812au 1-2:1.0: error beacon valid
Feb 14 08:22:21 odroid-h3 kernel: rtw_8812au 1-2:1.0: failed to download drv rsvd page
@morrownr commented on GitHub (Feb 14, 2025):
That is not the driver from 6.14 rcx. That is the driver from the lwfinger rtw88 repo.
@Simon566 commented on GitHub (Feb 14, 2025):
yes you are correct, arent those identical ? shall i go for 6.14 better ?
@Simon566 commented on GitHub (Feb 14, 2025):
ok , i just tested 6.14rc2 , same story
Feb 14 11:55:14 odroid-h3 kernel: rtw_8812au 1-2:1.0: error beacon valid
Feb 14 11:55:14 odroid-h3 kernel: rtw_8812au 1-2:1.0: failed to download drv rsvd page
Feb 14 11:55:16 odroid-h3 kernel: rtw_8812au 1-2:1.0: error beacon valid
Feb 14 11:55:16 odroid-h3 kernel: rtw_8812au 1-2:1.0: failed to download drv rsvd page
@morrownr commented on GitHub (Feb 14, 2025):
You are not testing the driver from 6.14 rc2 if you see the above. That is the driver from the lwfinger rtw88 repo.
What you should see if using the driver in 6.14 rc2 is: rtw88_8812au
When the lwfinger rtw88 drivers are installed, they install a file that blacklists the in-kernel drivers. You must uninstall the lwfinger rtw88 drivers to remove the blacklists and allow the in-kernel drivers to work.
Go to the directory you have rtw88 in and run the following:
$ sudo make uninstall
Reboot
Mostly but they cannot be perfectly identical for various reasons. We need to be specific about which driver we are seeing the specific results from.
@dubhater commented on GitHub (Feb 15, 2025):
@morrownr Unfortunately the kernel messages have the same prefix (rtw_) even if you are using the modules built into the kernel. The file names are different (rtw88_8812au.ko versus rtw_8812au.ko) but that prefix doesn't come from the file name, it comes from the source code. Something I've been meaning to fix but there are always other things.
@Simon566 "error beacon valid" is a known problem with USB, it's still not fixed. People say AP mode works anyway.
@Simon566 commented on GitHub (Feb 15, 2025):
@morrownr
i can confirm that this was 6.14rc2 with the in kernel drivers . AP mode works , but with clients not being able to connect etc , depends on the client and weather , temperature and menstruation
@morrownr commented on GitHub (Feb 15, 2025):
@Simon566
Well, yes, Dubhater got me on that one. It is something that needs to be fixed.
@morrownr commented on GitHub (Feb 15, 2025):
@Simon566
Is this one the same system that you are having trouble with the AXML? If so, I am beginning to suspect something to do with that specific system hardware or the distro. I use adapters with mt7921au chips and rtl8812au chips in AP mode on a RasPi4B and they are as solid as a rock.
@Simon566 commented on GitHub (Feb 15, 2025):
Hi,
Yes. But the rtl8812au Adapter also cause issues alone. But when the clients all connected,then itis fine
Home Automation with esphome/esp8266 , 24/7
15.02.2025 21:48:19 morrownr @.***>: