Project: Add 8821/11au rtw88 in-kernel driver. Need testers...

[morrownr]

Greetings to anyone that reads this message.

This Issue is where we coordinate and take bug report for the new 8821a in-kernel driver.

An effort is underway to add support for the rtl8821/11au 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. We do have specific needs. The most immediate need is to find users that have adapters that have bluetooth support (rtl8821au chip). The current developers only have adapters that have rtl8811au chips so we need help. We also need testers with old laptps that have the rtl8821ae chip.

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:

• Managed mode (client) appears to be in really good shape. No outstanding issues.

• Monitor mode appears to be in good shape but Active Monitor mode is not supported yet.

• AP mode is in good shape but AP Mode DFS channels are not supported (this common on usb wifi adapters). This is an issue that needs to be investigated but should not slow down the upstreaming of this driver.

• P2P mode is in good shape.

• IBSS mode has not been tested yet. Please test and report.

Overall: the driver appears to be in good shape. Please test and report your results.

[lwfinger]

I get a maximum of 130 Mbps transmit and 93 RX with iperf3. LibreSpeed gets 119 down and 113 up.

[lwfinger]

The master branch now contains all of dubhater's changes for the RTW8821AU and RTW8812AU, and the driver works. I have not removed any of the other branches until the code is checked a bit more, but please test everything. The speeds are still on the low side, but that will come.

[morrownr]

@lwfinger

The master branch now contains all of dubhater's changes for the RTW8821AU and RTW8812AU, and the driver works.

Thanks. I'll start testing and adding additional vid/pids for rtw8812au.

@dubhater

As you ready for rtw8812au to be tested or just rtw8821au?

[morrownr]

Initital testing of rtw88 master:

$ iperf3 -c 192.168.1.1
Connecting to host 192.168.1.1, port 5201
[  5] local 192.168.1.172 port 57430 connected to 192.168.1.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  28.6 MBytes   240 Mbits/sec    0    526 KBytes       
[  5]   1.00-2.00   sec  25.4 MBytes   213 Mbits/sec    0    526 KBytes       
[  5]   2.00-3.00   sec  25.5 MBytes   214 Mbits/sec    0    526 KBytes       
[  5]   3.00-4.00   sec  25.5 MBytes   214 Mbits/sec    0    551 KBytes       
[  5]   4.00-5.00   sec  25.7 MBytes   216 Mbits/sec    0    551 KBytes       
[  5]   5.00-6.00   sec  25.7 MBytes   216 Mbits/sec    0    551 KBytes       
[  5]   6.00-7.00   sec  26.5 MBytes   222 Mbits/sec    0    577 KBytes       
[  5]   7.00-8.00   sec  24.2 MBytes   203 Mbits/sec    0    577 KBytes       
[  5]   8.00-9.00   sec  25.5 MBytes   214 Mbits/sec    0    577 KBytes       
[  5]   9.00-10.00  sec  25.6 MBytes   215 Mbits/sec    0    577 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   258 MBytes   217 Mbits/sec    0             sender
[  5]   0.00-10.01  sec   256 MBytes   214 Mbits/sec                  receiver

iperf Done.

I ran iperf3 several times with my primary testing setup. Speed looks really good. Around 220 Mbps is about as fast as this chip can go if the out-of-kernel results over the last few years are good. The test above is on a DFS channel where there is no congestion. dmesg is clean. I'm impressed so far.

Monitor mode frame injection test:

$ sudo aireplay-ng --test wlx00c0caac47c7
[sudo] password for morrow:         
13:40:39  Trying broadcast probe requests...
13:40:39  Injection is working!
13:40:41  Found 12 APs

13:40:41  Trying directed probe requests...
13:40:41  C6:BE:59:93:4F:3B - channel: 44 - ''
13:40:43  Ping (min/avg/max): 2.473ms/9.155ms/17.771ms Power: -81.38
13:40:43  21/30:  70%

13:40:43  10:33:BF:60:FA:3B - channel: 44 - 'CoxWiFi'
13:40:43  Ping (min/avg/max): 1.548ms/5.636ms/8.924ms Power: -39.00
13:40:43  29/30:  96%

13:40:43  08:A7:C0:14:81:DA - channel: 44 - 'Wade Wifi'
13:40:47  Ping (min/avg/max): 10.801ms/17.700ms/27.914ms Power: -76.69
13:40:47  13/30:  43%

13:40:47  08:A7:C0:14:81:DF - channel: 44 - ''
13:40:51  Ping (min/avg/max): 14.111ms/22.023ms/39.249ms Power: -76.83
13:40:51  12/30:  40%

13:40:51  CC:BE:59:93:4F:3B - channel: 44 - 'SKHutch5'
13:40:52  Ping (min/avg/max): 2.017ms/6.207ms/20.025ms Power: -80.83
13:40:52  24/30:  80%

13:40:52  08:A7:C0:14:81:DD - channel: 44 - ''
13:40:57  Ping (min/avg/max): 10.314ms/21.516ms/31.877ms Power: -77.00
13:40:57  10/30:  33%

13:40:57  C2:BE:59:93:4F:3B - channel: 44 - ''
13:40:59  Ping (min/avg/max): 7.544ms/18.691ms/34.159ms Power: -79.70
13:40:59  20/30:  66%

13:40:59  10:33:BF:60:FA:3A - channel: 44 - ''
13:41:00  Ping (min/avg/max): 3.128ms/9.390ms/16.078ms Power: -38.93
13:41:00  28/30:  93%

13:41:00  10:33:BF:60:FA:3E - channel: 44 - ''
13:41:00  Ping (min/avg/max): 1.213ms/8.218ms/20.971ms Power: -38.80
13:41:00  30/30: 100%

13:41:00  08:A7:C0:14:81:DC - channel: 44 - 'CoxWiFi'
13:41:04  Ping (min/avg/max): 6.712ms/18.391ms/26.479ms Power: -77.00
13:41:04   9/30:  30%

13:41:04  08:A7:C0:14:81:DB - channel: 44 - ''
13:41:09  Ping (min/avg/max): 12.830ms/20.560ms/26.364ms Power: -77.00
13:41:09   9/30:  30%

13:41:09  10:33:BF:60:FA:3C - channel: 44 - ''
13:41:09  Ping (min/avg/max): 2.109ms/8.086ms/23.178ms Power: -38.93
13:41:09  28/30:  93%

Going in and out of monitor mode works well and things look like they should. The injection test above showed very good results. So far monitor mode looks good.

I will do more detailed test on managed and monitor mode as able this week and I plan to test AP mode and P2P-client. So far, this driver looks good.

I plan to rework the first message in this thread to provide instructions to those who can test/report as most will not be used to the instructions for getting this driver going,

I am still looking for someone with a rtl8821au based adapter and someone with an old laptop with a rtl8821ce chip in it so we can test bluetooth.

@morrownr

[dubhater]

@morrownr rtw_8812au is not ready yet.

I can see some RTL8821AE on Aliexpress, both M.2 and mini PCIe.

[morrownr]

@dubhater

I can see some RTL8821AE on Aliexpress, both M.2 and mini PCIe.

Give me a chance to round up some testers that already have the chips. We can always go get one if we have to do so. This repo gets over 100 hits per day so there are a lot of users of this chip. I just need to work on getting them in here now that we have something for them to test. I'll work it.

I'm impressed with this driver so far. We'll find problems but so far it is working well. My opinion after a few years of supporting out-of-kernel drivers for both the rtl8821au and rtl8821cu is that the au is simply a more reliable chip that causes users far fewer problems.

@morrownr

[gmsanchez]

@morrownr

I have a TP-Link Archer T2U PLUS [RTL8821AU]. I removed this kernel module using $ sudo sh remove-driver.sh and installed rtw88 using the provided readme on Kubuntu 24.04

So far everything is working good. I am willing to help, but I don't have a lot of experience in this field. Are there any instructions to run the required tests? Just let me know.

[morrownr]

Hi @gmsanchez

Thanks for testing.

Are there any instructions to run the required tests?

Do you have any experience using any modes in addition to managed (client) mode?

Please document your distro and version here and post the results of the following:

$ uname -r $ gcc --version

Do you know of a way to test your speed? If so, do it.

Post the results of:

$ sudo dmesg | grep rtw

Since you have an adapter with the version of the chip that has bluetooth support, can you verify that bluetooth is working correctly?

Post the results of:

$ lsusb

If your adapter has an LED, does it blink?

Lastly, just use it. See if anything goes wrong over the next few days. Keep us posted.

You may also get questions from @dubhater and @lwfinger .

@morrownr

[gmsanchez]

Do you know of a way to test your speed? If so, do it.

I don't know how to test my speed.

Since you have an adapter with the version of the chip that has bluetooth support, can you verify that bluetooth is working correctly?

I don't have any bluetooth device on my system.

If your adapter has an LED, does it blink?

I'll move the adapter to the front and check the LED status.

In the meantime, the requested output of the commands is below:

$ uname -r
6.8.0-31-generic
$ gcc --version
gcc (Ubuntu 13.2.0-23ubuntu4) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ sudo dmesg | grep rtw
[    3.848959] rtw_core: loading out-of-tree module taints kernel.
[    3.848966] rtw_core: module verification failed: signature and/or required key missing - tainting kernel
[    3.874055] rtw_8821au 3-1:1.0: Firmware version 42.4.0, H2C version 0
[    3.915832] usbcore: registered new interface driver rtw_8821au
[    3.919055] rtw_8821au 3-1:1.0 wlx6c5ab0d0395d: renamed from wlan0
[    6.110598] rtw_8821au 3-1:1.0: MAC has not been powered on yet
$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 003: ID 05e3:0606 Genesys Logic, Inc. USB 2.0 Hub / D-Link DUB-H4 USB 2.0 Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 003: ID 046d:c31c Logitech, Inc. Keyboard K120
Bus 002 Device 004: ID 046d:c077 Logitech, Inc. Mouse
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 2357:0120 TP-Link Archer T2U PLUS [RTL8821AU]
Bus 003 Device 003: ID 046d:08e4 Logitech, Inc. C505e HD Webcam
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

[morrownr]

@dubhater

rtw88 master - rtw_8821au

I am seeing the below during compilation. This is with Debian 12 and kernels 6.1 LTS and 6.6 LTS plus gcc 12.2. This not fatal but...

  CC [M]  /home/morrow/src/rtw88/rtw8821a.o
  CC [M]  /home/morrow/src/rtw88/rtw8821a_table.o
In file included from /usr/src/linux-headers-6.1.0-21-common/include/linux/kernel.h:26,
                 from /usr/src/linux-headers-6.1.0-21-common/arch/x86/include/asm/percpu.h:27,
                 from /usr/src/linux-headers-6.1.0-21-common/arch/x86/include/asm/current.h:6,
                 from /usr/src/linux-headers-6.1.0-21-common/include/linux/sched.h:12,
                 from /usr/src/linux-headers-6.1.0-21-common/include/linux/delay.h:23,
                 from /usr/src/linux-headers-6.1.0-21-common/include/linux/usb.h:15,
                 from /home/morrow/src/rtw88/rtw8821a.c:5:
/home/morrow/src/rtw88/rtw8821a.c: In function ‘rtw8821a_tx_power_training’:
/usr/src/linux-headers-6.1.0-21-common/include/linux/minmax.h:20:35: warning: comparison of distinct pointer types lacks a cast
   20 |         (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
      |                                   ^~
/usr/src/linux-headers-6.1.0-21-common/include/linux/minmax.h:26:18: note: in expansion of macro ‘__typecheck’
   26 |                 (__typecheck(x, y) && __no_side_effects(x, y))
      |                  ^~~~~~~~~~~
/usr/src/linux-headers-6.1.0-21-common/include/linux/minmax.h:36:31: note: in expansion of macro ‘__safe_cmp’
   36 |         __builtin_choose_expr(__safe_cmp(x, y), \
      |                               ^~~~~~~~~~
/usr/src/linux-headers-6.1.0-21-common/include/linux/minmax.h:52:25: note: in expansion of macro ‘__careful_cmp’
   52 | #define max(x, y)       __careful_cmp(x, y, >)
      |                         ^~~~~~~~~~~~~
/home/morrow/src/rtw88/rtw8821a.c:2481:31: note: in expansion of macro ‘max’
 2481 |                 write_data |= max(power_level, 2) << (i * 8);
      |                               ^~~

[lwfinger]

The problem is that the code used max(a,b), whereas it should have been max_t(u32,a,b). It now compiles cleanly on openSUSE Tumbleweed and Debian 12.

[morrownr]

@gmsanchez

I don't know how to test my speed.

You can give the following site a try for basic speed testing:

https://testmy.net/

Most of us use iperf3 on our local lans for speed testing. Do you have a RasPi on your local lan or a wifi router that runs OpenWRT?

I don't have any bluetooth device on my system.

It looked like you might have a version of the chipset that includes bluetooth support so I was looking to see if the bluetooth in your adapter was working. Maybe you have a chip that is wifi only.

[ 6.110598] rtw_8821au 3-1:1.0: MAC has not been powered on yet

Let me think out loud here for a moment. I am trying to sort out why the above line is needed. What is it doing for us?

Thanks for the info and we'll be waiting for additional reports.

@morrownr

[morrownr]

@lwfinger

The problem is that the code used max(a,b), whereas it should have been max_t(u32,a,b). It now compiles cleanly on openSUSE Tumbleweed and Debian 12.

Awesome! Clean compile here.

FYI: I'll be moving to AP mode testing soon. So far, managed and monitor modes look really good but my AP mode testing will take me to another distro and ARM64.

[morrownr]

@dubhater @lwfinger

Here is a very minor nitpick:

When I run iperf3, I am seeing drop (in the statistics box) increase regularly. With other wireless devices I am more used to it not increasing or occasionally incrementing but not as regularly as I am seeing here. Do we have a buffer set slightly smaller than it needs to be?

Like I said, nitpick. I am having a difficult time finding any problems with managed and monitor modes.

I am off to test AP mode.

@morrownr

[lwfinger]

Do you see any WARNINGS in your logs like this "WARNING: CPU: 3 PID: 36 at net/mac80211/rx.c"? Your CPU and PID will be different. That may be the source of your drops.

I have a patch to silence the WARNINGS, but the drops are not fixed as the packets are malformed.

What is the utility that produced the screenshot? I am not familiar with anything like it.

[5kft]

@morrownr I'm using a Debian-based custom arm64/armhf distribution, and as such I can't build the rtw88 driver via @lwfinger's process (I didn't bother to try to address this further). Instead, I simply removed the original mainline (6.9-rc7) rtw88 driver source and replaced it completely with @lwfinger's version from his github.

Now, when building this new version of rtw88 I am getting errors relating to the PCI driver module support or something (see errors below). My kernel configuration does not enable CONFIG_PCI, just in case this might be related. I haven't debugged the new in-kernel rtw88 build process any further. I'm pointing this out just in case there is an oversight in this new rtw88 code for non-CONFIG_PCI and/or ARM builds (or something).

As a comparison, the mainline 6.9-rc7 rtw88 driver builds completely fine - without any errors - so there does appear to be a regression in this new version of the driver source.

In my kernel config I am only enabling the the 8821CU module, so it is kind of odd that the build is erroring out for driver sources that aren't even enabled:

CONFIG_RTW88=m
CONFIG_RTW88_CORE=m
CONFIG_RTW88_USB=m
CONFIG_RTW88_8821C=m
# CONFIG_RTW88_8822BS is not set
# CONFIG_RTW88_8822BU is not set
# CONFIG_RTW88_8822CS is not set
# CONFIG_RTW88_8822CU is not set
# CONFIG_RTW88_8723DS is not set
# CONFIG_RTW88_8723DU is not set
# CONFIG_RTW88_8821CS is not set
CONFIG_RTW88_8821CU=m
# CONFIG_RTW88_DEBUG is not set
# CONFIG_RTW88_DEBUGFS is not set

Build errors:

drivers/net/wireless/realtek/rtw88/rtw8822be.c:27:1: warning: data definition has no type or storage class
   27 | module_pci_driver(rtw_8822be_driver);
      | ^~~~~~~~~~~~~~~~~
drivers/net/wireless/realtek/rtw88/rtw8822be.c:27:1: error: type defaults to ‘int’ in declaration of ‘module_pci_driver’ [-Werror=implicit-int]
drivers/net/wireless/realtek/rtw88/rtw8822be.c:27:1: warning: parameter names (without types) in function declaration
drivers/net/wireless/realtek/rtw88/rtw8822be.c:19:26: warning: ‘rtw_8822be_driver’ defined but not used [-Wunused-variable]
   19 | static struct pci_driver rtw_8822be_driver = {
      |                          ^~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
make[7]: *** [scripts/Makefile.build:244: drivers/net/wireless/realtek/rtw88/rtw8822be.o] Error 1
make[7]: *** Waiting for unfinished jobs....
drivers/net/wireless/realtek/rtw88/rtw8822ce.c:31:1: warning: data definition has no type or storage class
   31 | module_pci_driver(rtw_8822ce_driver);
      | ^~~~~~~~~~~~~~~~~
drivers/net/wireless/realtek/rtw88/rtw8822ce.c:31:1: error: type defaults to ‘int’ in declaration of ‘module_pci_driver’ [-Werror=implicit-int]
drivers/net/wireless/realtek/rtw88/rtw8822ce.c:31:1: warning: parameter names (without types) in function declaration
drivers/net/wireless/realtek/rtw88/rtw8822ce.c:23:26: warning: ‘rtw_8822ce_driver’ defined but not used [-Wunused-variable]
   23 | static struct pci_driver rtw_8822ce_driver = {
      |                          ^~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
make[7]: *** [scripts/Makefile.build:244: drivers/net/wireless/realtek/rtw88/rtw8822ce.o] Error 1
make[6]: *** [scripts/Makefile.build:485: drivers/net/wireless/realtek/rtw88] Error 2
make[5]: *** [scripts/Makefile.build:485: drivers/net/wireless/realtek] Error 2
make[4]: *** [scripts/Makefile.build:485: drivers/net/wireless] Error 2
make[3]: *** [scripts/Makefile.build:485: drivers/net] Error 2
make[2]: *** [scripts/Makefile.build:485: drivers] Error 2

[morrownr]

@lwfinger

Do you see any WARNINGS in your logs like this "WARNING: CPU: 3 PID: 36 at net/mac80211/rx.c"?

No. Log is really clean.

What is the utility that produced the screenshot? I am not familiar with anything like it.

wavemon

For Debian:

$ sudo apt install wavemon $ wavemon

[morrownr]

@dubhater @lwfinger

My monitor mode testing was basic but I did ask a friend that is an expert to do more detailed monitor mode testing. Here is what he passed on to me this morning:

None of the Realtek drivers is able to run active monitor mode. (he is talking about rtw88 as well as the out-of-kernel drivers)

Only Mediatek drivers have this (NL80211_FEATURE_ACTIVE_MONITOR) feature.

mt76/mac80211.c:        wiphy->features |= NL80211_FEATURE_ACTIVE_MONITOR |

Active monitor mode is a feature that is desirable for many users of monitor mode. If this feature could be added, it would benefit users of monitor mode.

@morrownr

[morrownr]

AP Mode report

AP Mode seems to be working well. This message is coming to you through my rtl8811au based adapter working in AP mode. Performance is good, around 200 Mbps. No drops noted. It survived and stayed up all night last night. More details below.

Missing feature: No DFS support in AP mode. DFS is supported in the WiFi 5 out-of-kernel drivers that I have up here at this site which would indicate to me that Realtek does have the certifications for this feature. The rtl8812au driver is a good example of AP mode DFS working. It sure would be good to add this feature to rtw88.

Details:

WPA2 AES, mixed and WPA3 work fine.

Details of configuration for hostapd.conf:

# rtw88 rtl8811au
# Capabilities: 0x196e
#       HT20/HT40
#       SM Power Save disabled
#       RX HT20 SGI
#       RX HT40 SGI
#       RX STBC 1-stream
#       Max AMSDU length: 7935 bytes
#       DSSS/CCK HT40
ht_capab=[HT40+][HT40-][SHORT-GI-20][SHORT-GI-40][RX-STBC1][MAX-AMSDU-7935][DSSS_CCK-40]

# rtw88 rtl8811au
# VHT Capabilities (0x03d07122):
#       Max MPDU length: 11454
#       Supported Channel Width: neither 160 nor 80+80
#       short GI (80 MHz)
#       SU Beamformee
#       MU Beamformee
#       +HTC-VHT
vht_capab=[MAX-MPDU-11454][SHORT-GI-80][SU-BEAMFORMEE][MU-BEAMFORMEE][HTC-VHT]

Performance:

Since I cannot use a DFS channel, I am using channel 149 for testing. There is some congestion on this channel.

$ iperf3 -c 192.168.1.1
Connecting to host 192.168.1.1, port 5201
[  5] local 192.168.1.135 port 58952 connected to 192.168.1.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  22.4 MBytes   188 Mbits/sec    0    502 KBytes       
[  5]   1.00-2.00   sec  21.9 MBytes   183 Mbits/sec    0    529 KBytes       
[  5]   2.00-3.00   sec  20.7 MBytes   174 Mbits/sec    0    557 KBytes       
[  5]   3.00-4.00   sec  22.1 MBytes   186 Mbits/sec    0    621 KBytes       
[  5]   4.00-5.00   sec  20.9 MBytes   175 Mbits/sec    0    649 KBytes       
[  5]   5.00-6.00   sec  21.2 MBytes   178 Mbits/sec    0    680 KBytes       
[  5]   6.00-7.00   sec  21.2 MBytes   178 Mbits/sec    0    714 KBytes       
[  5]   7.00-8.00   sec  21.2 MBytes   178 Mbits/sec    0    782 KBytes       
[  5]   8.00-9.00   sec  21.2 MBytes   178 Mbits/sec    0    819 KBytes       
[  5]   9.00-10.00  sec  21.2 MBytes   178 Mbits/sec    0    819 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   214 MBytes   180 Mbits/sec    0             sender
[  5]   0.00-10.02  sec   211 MBytes   177 Mbits/sec                  receiver

Overall: AP mode is working well. As I said, AP mode DFS support is missing, This is a feature that is desirable, especially in some parts of the world where non-DFS channels are limited.

After a few more days of testing AP mode, I will move on to testing P2P. If other testers are reading this, we need IBSS mode tested.

@morrownr

[dubhater]

Missing feature: No DFS support in AP mode.

How can you tell? Does rtw88 support it with any of the chips? I guess you can't check if you only have USB devices and they don't work at all in AP mode.

Active monitor mode is a feature that is desirable for many users of monitor mode.

All I know about this is that simply adding NL80211_FEATURE_ACTIVE_MONITOR is not enough. What is active monitor mode? How does it work?

When I run iperf3, I am seeing drop (in the statistics box) increase regularly.

That could indicate a problem. @lwfinger Do you see warnings from net/mac80211/rx.c? Please paste one if you do.

[ 6.110598] rtw_8821au 3-1:1.0: MAC has not been powered on yet

Let me think out loud here for a moment. I am trying to sort out why the above line is needed. What is it doing for us?

I was curious if it ever says that MAC has been powered on already. (It never does.) I will delete that message later.

[lwfinger]

@dubhater: Yes I am seeing warnings out of net/mac80211/rx..c:5350 ieee80211_rx_list+0x5c2/0xd50 because the band is incorrect. I just pushed a patch that silences the warning and drops the offending warning. That avoids a memory leak.

The NIC still does a reset, but the log is a little smaller. There are storms of these events as follows:

[98993.769696] usb 2-6: SerialNumber: 00e04c000001 [98993.774147] rtw_8821au 2-6:1.0: Firmware version 42.4.0, H2C version 0 [98993.774287] rtw_8821au 2-6:1.0: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status [98993.774291] rtw_8821au 2-6:1.0: band wrong, packet dropped [98993.774323] rtw_8821au 2-6:1.0: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status [98993.774325] rtw_8821au 2-6:1.0: band wrong, packet dropped [98993.774359] rtw_8821au 2-6:1.0: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status [98993.774361] rtw_8821au 2-6:1.0: band wrong, packet dropped [98993.774376] rtw_8821au 2-6:1.0: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status [98993.774378] rtw_8821au 2-6:1.0: band wrong, packet dropped [98993.774398] rtw_8821au 2-6:1.0: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status [98993.774400] rtw_8821au 2-6:1.0: band wrong, packet dropped [98993.774413] rtw_8821au 2-6:1.0: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status [98993.774415] rtw_8821au 2-6:1.0: band wrong, packet dropped [98993.774439] rtw_8821au 2-6:1.0: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status [98993.774440] rtw_8821au 2-6:1.0: band wrong, packet dropped [98993.774448] rtw_8821au 2-6:1.0: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status [98993.774449] rtw_8821au 2-6:1.0: band wrong, packet dropped [98993.774463] rtw_8821au 2-6:1.0: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status [98993.774465] rtw_8821au 2-6:1.0: band wrong, packet dropped [98993.774482] rtw_8821au 2-6:1.0: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status [98993.774484] rtw_8821au 2-6:1.0: band wrong, packet dropped [98993.774498] rtw_8821au 2-6:1.0: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status [98993.774500] rtw_8821au 2-6:1.0: band wrong, packet dropped [98993.774510] rtw_8821au 2-6:1.0: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status [98993.774512] rtw_8821au 2-6:1.0: band wrong, packet dropped [98993.774531] rtw_8821au 2-6:1.0: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status [98993.774532] rtw_8821au 2-6:1.0: band wrong, packet dropped [98993.774544] rtw_8821au 2-6:1.0: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status [98993.774545] rtw_8821au 2-6:1.0: band wrong, packet dropped [98993.774562] rtw_8821au 2-6:1.0: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status [98993.774564] rtw_8821au 2-6:1.0: band wrong, packet dropped [98993.774577] rtw_8821au 2-6:1.0: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status [98993.774579] rtw_8821au 2-6:1.0: band wrong, packet dropped [98993.791298] rtw_8821au 2-6:1.0: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status [98993.791304] rtw_8821au 2-6:1.0: band wrong, packet dropped [98993.831092] 00000000: 29 81 00 7c 01 00 01 00 4c 00 04 00 10 00 00 00 )..|....L.......

If it would help to see other info, please let me know.

[dubhater]

@lwfinger The driver is receiving frames before it even read the efuse. At that point the chip should not be powered on and frame reception should not be enabled yet. I don't know how this can happen.

[morrownr]

@dubhater

All I know about this is that simply adding NL80211_FEATURE_ACTIVE_MONITOR is not enough. What is active monitor mode? How does it work?

@ZerBea should be able to answer these questions and more. His github site is:

https://github.com/ZerBea/hcxdumptool

I contacted him via email and asked to bring him into this conversation so as to have more information about the Active Monitor mode issue. Just wait for him to reply to this message.

[morrownr]

@dubhater

Missing feature: No DFS support in AP mode.

How can you tell?

When I use non-DFS channels, they work. When I use DFS channels, they don't work.

Does rtw88 support it with any of the chips?

That is a good question. This driver is the first rtw88 driver where I have had success in AP mode. If I had to guess, I would say DFS channels are not currently supported in rtw88. DFS is supported in the out-of-kernel driver in this repo.

My opinion is that the drop issue that you and @lwfinger are working and the Active Monitor mode issue are higher priority issues than this so I am not pushing this issue, just pointing it out.

Edit: When and if we find time to work this DFS channel issue, I can show you how to activate the capability in the driver in this repo. It requires the use of a module parameter and some settings in hostapd for it to work which should clue us into what code is being used.

[lwfinger]

@morrownr: What does 'iw list' show for channel 60?

[morrownr]

@lwfinger

What does 'iw list' show for channel 60?

            * 5180 MHz [36] (23.0 dBm)
            * 5200 MHz [40] (23.0 dBm)
            * 5220 MHz [44] (23.0 dBm)
            * 5240 MHz [48] (23.0 dBm)
            * 5260 MHz [52] (24.0 dBm) (radar detection)
            * 5280 MHz [56] (24.0 dBm) (radar detection)
            * 5300 MHz [60] (24.0 dBm) (radar detection)
            * 5320 MHz [64] (24.0 dBm) (radar detection)
            * 5500 MHz [100] (24.0 dBm) (radar detection)
            * 5520 MHz [104] (24.0 dBm) (radar detection)
            * 5540 MHz [108] (24.0 dBm) (radar detection)
            * 5560 MHz [112] (24.0 dBm) (radar detection)
            * 5580 MHz [116] (24.0 dBm) (radar detection)
            * 5600 MHz [120] (24.0 dBm) (radar detection)
            * 5620 MHz [124] (24.0 dBm) (radar detection)
            * 5640 MHz [128] (24.0 dBm) (radar detection)
            * 5660 MHz [132] (24.0 dBm) (radar detection)
            * 5680 MHz [136] (24.0 dBm) (radar detection)
            * 5700 MHz [140] (24.0 dBm) (radar detection)
            * 5720 MHz [144] (24.0 dBm) (radar detection)
            * 5745 MHz [149] (30.0 dBm)
            * 5765 MHz [153] (30.0 dBm)
            * 5785 MHz [157] (30.0 dBm)
            * 5805 MHz [161] (30.0 dBm)
            * 5825 MHz [165] (30.0 dBm)

That is exactly what it should say for the US. AP mode DFS works with the out-of-kernel driver in this repo. You do have to add a module parameter and make sure a couple of settings in hostapd.conf are correct but it works. Background: AP mode DFS channel support does require a separate FCC certification for this to be legal. I am assuming that Realtek has the certs if it works in the out-of-kernel driver ? This might be an issue that needs to be addressed with Ping-Ke.

FYI: When I have my rtl8811au based adapter using the out-of-kernel driver in this repo and set to a DFS channel in AP mode, I see what I expect to see: There is about a 60 second delay before you can connect while the adapter supposedly scanning to see if there is interference. I have never seen it change channels due to interference because I don't think there are any devices that will interfere in my area. So... it appears to work but I would need to some expensive equipment to actually test to see if it is actually doing what it should be doing. My wifi routers have never detected interference on DFS channels either. and they should be certified and working correctly.

[lwfinger]

@dubhater: That parameter in the vendor driver has the following snippet:

    registry_par->dfs_region_domain = (u8)rtw_dfs_region_domain;
    if (registry_par->dfs_region_domain != RTW_DFS_REGD_NONE) {
            RTW_WARN("%s force disable radar detection capability for now\n", __func__);
            registry_par->dfs_region_domain = RTW_DFS_REGD_NONE;
    }

That won't help much as it turns the capability off if you try to turn radar detection on.

The 8821cu driver has similar code.

[morrownr]

@dubhater @lwfinger

The module parameter that is required for AP mode DFS operation with the vendor driver in this repo is:

# DFS Options ( rtw_dfs_region_domain )
#
# 0 = NONE (default)
# 1 = FCC
# 2 = MKK
# 3 = ETSI
#
# Notes:
# - Activates DFS channels in AP mode.
# - DFS FCC 80 MHz channels for hostapd: 52(58), 100(106), 116(122) and 132(138)
# - For more information: https://en.wikipedia.org/wiki/List_of_WLAN_channels
#
# Note: An AP needs to listen on a DFS channel for a period of 60 seconds
# before transmitting on the channel. If any radar pulses are detected,
# the AP cannot use that channel and will have to try a different channel.

There is also a different module parameter needed for 80 Mhz channel width in AP mode.

Would it help if I changed over to the vendor driver so as to provide information about AP mode DFS operation? I am convinced at this point that AP mode is working VERY well in this driver so the only issue with AP mode is the lack of DFS support.

[lwfinger]

Look at the code a few lines down. If you set anything but RTW_DFS_REGD_NONE, it changes it back to RTW_DFS_REGD_NONE.

[ZerBea]

@dubhater

All I know about this is that simply adding NL80211_FEATURE_ACTIVE_MONITOR is not enough. What is active monitor mode? How does it work?

@ZerBea should be able to answer these questions and more. His github site is:

https://github.com/ZerBea/hcxdumptool

I contacted him via email and asked to bring him into this conversation so as to have more information about the Active Monitor mode issue. Just wait for him to reply to this message.

In monitor mode, the device retransmit frames addressed to the device MAC (IFLA_ADDRESS) for n times if they are not ACK'ed and the device ACK frames addressed to the device MAC (IFLA_ADDRESS).

@morrownr aireplay-ng injection test is limited to this frames only (Wireshark: radiotap.present.dbm_antsignal == False): PROBEREQUEST NULL RTS AUTHENTICATION An injection of other frames than this ones is not tested.

[morrownr]

@ZerBea

aireplay-ng injection test is limited to this frames only

I am aware of that but as you know, I'm not an expert at monitor mode. I work with it to try to fix a problem now and then and to help users along their journey. As it is currently, if a user wants Active Monitor mode support, I just have to point then to the Plug and Play List and tell them to get a Mediatek based adapter.

If you could give a rundown of what Active Monitor mode is used for and how it works, that would help @dubhater greatly. I think you also mentioned that you had been working on Active Monitor mode in another driver lately so maybe you could share that experience. I don't think any of the drivers in rtw88 support Active Monitor mode and I'm not sure if there has ever been a Realtek driver that does support it. I know the Mediatek drivers support... like mt7610u, mt7612u, mt7921u (though it seems to be broken currently) and the mt7925 but since no adapters are available yet, who knows.

Your help is greatly appreciated.

[ZerBea]

@dubhater I fully agree, telling the kernel that the device support ACTIVE MONITOR by setting NL80211_FEATURE_ACTIVE_MONITOR is far away from ACKing incoming frames and retransmitting not ACKed frames in MONITOR MODE.

[ZerBea]

I forgot to mention that I just test the drivers if they work together with hcxdumptool/hcxlabtool (target respond). AP mode, data rate, reliability of values like RSSI or TX power are untested, because I'm not interested in this values. My attitude is: If the target respond in time, RSSI and TX power in both directions is enough!

[ma8ma]

Hi, @morrownr

I have a USB wireless adapter BUFFALO WI-U2-433DHP. I've tried it with the rtw88 driver on Kubuntu 23.10. Here are your questions answers.

Do you have any experience using any modes in addition to managed (client) mode?

No, I'm using client mode.

Please document your distro and version here and post the results of the following:

$ uname -r $ gcc --version

Kubuntu 23.10, x86_64

$ uname -r
6.5.0-27-generic

$ gcc --version
gcc (Ubuntu 13.2.0-4ubuntu3) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Do you know of a way to test your speed? If so, do it.

Yes, I used iperf3 to test the speed. Here are the results:

$ iperf3 --version
iperf 3.14 (cJSON 1.7.15)
Linux ma8ma-System-Product-Name 6.5.0-27-generic #28-Ubuntu SMP PREEMPT_DYNAMIC Thu Mar  7 18:21:00 UTC 2024 x86_64
Optional features available: CPU affinity setting, IPv6 flow label, SCTP, TCP congestion algorithm setting, sendfile / zerocopy, socket pacing, authentication, bind to device, support IPv4 don't fragment

$ iperf3 -c ping.online.net
Connecting to host ping.online.net, port 5201
[  5] local 192.168.11.12 port 49060 connected to 51.158.1.21 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   256 KBytes  2.10 Mbits/sec    0   56.2 KBytes
[  5]   1.00-2.00   sec   134 KBytes  1.09 Mbits/sec   24   45.0 KBytes
[  5]   2.00-3.00   sec   325 KBytes  2.66 Mbits/sec    0   47.8 KBytes
[  5]   3.00-4.00   sec   127 KBytes  1.04 Mbits/sec    0   49.2 KBytes
[  5]   4.00-5.00   sec   127 KBytes  1.04 Mbits/sec    0   49.2 KBytes
[  5]   5.00-6.00   sec   253 KBytes  2.07 Mbits/sec    0   50.6 KBytes
[  5]   6.00-7.00   sec   127 KBytes  1.04 Mbits/sec    0   57.7 KBytes
[  5]   7.00-8.00   sec   443 KBytes  3.63 Mbits/sec    0   71.7 KBytes
[  5]   8.00-9.00   sec   443 KBytes  3.63 Mbits/sec    0   97.0 KBytes
[  5]   9.00-10.00  sec   253 KBytes  2.07 Mbits/sec    8   77.3 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  2.43 MBytes  2.04 Mbits/sec   32             sender
[  5]   0.00-10.27  sec  1.94 MBytes  1.58 Mbits/sec                  receiver

iperf Done.

Post the results of:

$ sudo dmesg | grep rtw

$ sudo dmesg  | grep rtw
[  658.781262] usbcore: registered new interface driver rtw_8821au
[  684.951207] rtw_8821au 1-5:1.0: Firmware version 42.4.0, H2C version 0
[  688.180399] rtw_8821au 1-5:1.0 wlx7403bdea6ebe: renamed from wlan0
[  688.235313] rtw_8821au 1-5:1.0: MAC has not been powered on yet

Since you have an adapter with the version of the chip that has bluetooth support, can you verify that bluetooth is working correctly?

No, the BUFFALO WI-U2-433DHP adapter does not support Bluetooth. According to the product specifications, it is a USB wireless LAN adapter without Bluetooth functionality.

Post the results of:

$ lsusb

$ lsusb
Bus 004 Device 002: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 006: ID 0411:029b BUFFALO INC. (formerly MelCo., Inc.) 802.11ac WLAN Adapter
Bus 001 Device 004: ID 0566:3107 Monterey International Corp. Keyboard
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

If your adapter has an LED, does it blink?

Yes, the LED on the adapter blinks, indicating that it is operating normally.

Lastly, just use it. See if anything goes wrong over the next few days. Keep us posted.

I have just started using it, so I will report any issues that may arise.

You may also get questions from @dubhater and @lwfinger .

I will admit that I may not have the confidence to provide satisfactory answers due to my limited knowledge in this area.

Thank you for your work!

[ZerBea]

rtl8811aun: Neither monitor mode nor packet injection is working:

lsusb:
ID 7392:a812 Edimax Technology Co., Ltd Edimax AC600 USB

dmesg:
[  465.250392] usb 5-2.1: New USB device found, idVendor=7392, idProduct=a812, bcdDevice= 2.00
[  465.250403] usb 5-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  465.250406] usb 5-2.1: Product: Edimax AC600 USB
[  465.250408] usb 5-2.1: Manufacturer: Realtek
[  465.250411] usb 5-2.1: SerialNumber: 00e04c000001
[  465.314039] rtw_8821au 5-2.1:1.0: Firmware version 42.4.0, H2C version 0
[  465.572633] 00000000: 29 81 00 7c 01 00 01 00 4c 00 04 00 10 00 00 00  )..|....L.......
[  465.572640] 00000010: 20 20 20 20 20 20 28 28 28 29 29 f0 ff ff ff ff        ((()).....
[  465.572642] 00000020: ff ff 2c 2b 2a 29 2e 2c 2a 29 28 27 29 2a 29 28  ..,+*).,*)(')*)(
[  465.572644] 00000030: 01 ff ff ff ff ff cc ff ff ff ff ff ff ff ff ff  ................
[  465.572646] 00000040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[  465.572647] 00000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[  465.572648] 00000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[  465.572650] 00000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[  465.572651] 00000080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[  465.572653] 00000090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[  465.572654] 000000a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[  465.572656] 000000b0: ff ff ff ff ff ff ff ff 42 0b 1e 00 00 00 ff 00  ........B.......
[  465.572657] 000000c0: ff 08 00 ff 00 00 00 55 00 ff ff ff ff ff ff ff  .......U........
[  465.572659] 000000d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[  465.572660] 000000e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[  465.572661] 000000f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[  465.572663] 00000100: 92 73 12 a8 e7 47 03 74 da 38 06 45 e7 09 03 52  .s...G.t.8.E...R
[  465.572665] 00000110: 65 61 6c 74 65 6b 12 03 45 64 69 6d 61 78 20 41  ealtek..Edimax A
[  465.572666] 00000120: 43 36 30 30 20 55 53 42 00 ff ff ff ff ff ff ff  C600 USB........
[  465.572667] 00000130: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[  465.572669] 00000140: ff ff ff ff ff ff ff 0f ff ff ff ff ff ff ff ff  ................
[  465.572670] 00000150: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[  465.572672] 00000160: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[  465.572673] 00000170: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[  465.572675] 00000180: ff ff ff ff ff ff ff ff 83 ab 99 2d 03 93 98 a0  ...........-....
[  465.572676] 00000190: fc 8c 00 11 9b c4 00 ff ff ff ff ff ff ff ff ff  ................
[  465.572678] 000001a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[  465.572679] 000001b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[  465.572680] 000001c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[  465.572682] 000001d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[  465.572683] 000001e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[  465.572685] 000001f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[  465.585086] rtw_8821au 5-2.1:1.0 wlp48s0f4u2u1: renamed from wlan0

$ hcxdumptool -I wlp48s0f4u2u1

Requesting physical interface capabilities. This may take some time.
Please be patient...

interface information:

phy idx hw-mac       virtual-mac  m ifname           driver (protocol)
---------------------------------------------------------------------------------------------
  5   8 74da380616f3 c8aaccbcc183 * wlp48s0f4u2u1    rtw_8821au (NETLINK)

available frequencies: frequency [channel] tx-power of Regulatory Domain: DE

  2412 [  1] 20.0 dBm     2417 [  2] 20.0 dBm     2422 [  3] 20.0 dBm     2427 [  4] 20.0 dBm
  2432 [  5] 20.0 dBm     2437 [  6] 20.0 dBm     2442 [  7] 20.0 dBm     2447 [  8] 20.0 dBm
  2452 [  9] 20.0 dBm     2457 [ 10] 20.0 dBm     2462 [ 11] 20.0 dBm     2467 [ 12] 20.0 dBm
  2472 [ 13] 20.0 dBm     2484 [ 14] disabled     5180 [ 36] 23.0 dBm     5200 [ 40] 23.0 dBm
  5220 [ 44] 23.0 dBm     5240 [ 48] 23.0 dBm     5260 [ 52] 20.0 dBm     5280 [ 56] 20.0 dBm
  5300 [ 60] 20.0 dBm     5320 [ 64] 20.0 dBm     5500 [100] 26.0 dBm     5520 [104] 26.0 dBm
  5540 [108] 26.0 dBm     5560 [112] 26.0 dBm     5580 [116] 26.0 dBm     5600 [120] 26.0 dBm
  5620 [124] 26.0 dBm     5640 [128] 26.0 dBm     5660 [132] 26.0 dBm     5680 [136] 26.0 dBm
  5700 [140] 26.0 dBm     5720 [144] 13.0 dBm     5745 [149] 13.0 dBm     5765 [153] 13.0 dBm
  5785 [157] 13.0 dBm     5805 [161] 13.0 dBm     5825 [165] 13.0 dBm

$ sudo hcxdumptool wlp48s0f4u2u1 --rds=1
[  553.620384] rtw_8821au 5-2.1:1.0 wlp48s0f4u2u1: entered promiscuous mode
[  559.198609] rtw_8821au 5-2.1:1.0: failed to get tx report from firmware
[  560.185290] rtw_8821au 5-2.1:1.0: failed to get tx report from firmware
[  560.928724] rtw_8821au 5-2.1:1.0 wlp48s0f4u2u1: left promiscuous mode

BTW: make uninstall doesn't remove: rtw88_8723x.ko

[dubhater]

@ma8ma That speed is surprisingly low. Are you far from the access point/router?

Could you run this in another terminal while you test the speed again? iw dev wlx7403bdea6ebe station dump

@ZerBea Does sudo hcxdumptool wlp48s0f4u2u1 --rds=1 bring down the interface and then up again before it starts transmitting? Or does it change the MAC address before transmitting?

[ma8ma]

Hi, @dubhater

Are you far from the access point/router?

Yes, the access point is across the hallway. I found an iperf3 server in my country, a public one, and tried it:

$ iperf3 -c 89.187.160.1
Connecting to host 89.187.160.1, port 5201
[  5] local 192.168.11.12 port 55672 connected to 89.187.160.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   373 KBytes  3.05 Mbits/sec   15   19.7 KBytes
[  5]   1.00-2.00   sec   332 KBytes  2.72 Mbits/sec    2   15.5 KBytes
[  5]   2.00-3.00   sec   269 KBytes  2.20 Mbits/sec    2   15.5 KBytes
[  5]   3.00-4.00   sec   266 KBytes  2.18 Mbits/sec    1   19.7 KBytes
[  5]   4.00-5.00   sec   319 KBytes  2.62 Mbits/sec    2   15.5 KBytes
[  5]   5.00-6.00   sec   269 KBytes  2.20 Mbits/sec    1   19.7 KBytes
[  5]   6.00-7.00   sec   319 KBytes  2.62 Mbits/sec    2   14.1 KBytes
[  5]   7.00-8.00   sec   316 KBytes  2.59 Mbits/sec    1   19.7 KBytes
[  5]   8.00-9.00   sec   274 KBytes  2.25 Mbits/sec    3   14.1 KBytes
[  5]   9.00-10.00  sec   316 KBytes  2.59 Mbits/sec    1   18.3 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  2.98 MBytes  2.50 Mbits/sec   30             sender
[  5]   0.00-10.07  sec  2.86 MBytes  2.38 Mbits/sec                  receiver

iperf Done.

$ iw dev wlx7403bdea6ebe station dump
Station 58:27:8c:73:d3:e8 (on wlx7403bdea6ebe)
        inactive time:  128 ms
        rx bytes:       68564624
        rx packets:     74612
        tx bytes:       24808819
        tx packets:     42546
        tx retries:     0
        tx failed:      0
        beacon loss:    5
        beacon rx:      8114
        rx drop misc:   358
        signal:         -58 [-58] dBm
        signal avg:     -46 [-46] dBm
        beacon signal avg:      -57 dBm
        tx bitrate:     72.2 MBit/s MCS 7 short GI
        tx duration:    0 us
        rx bitrate:     65.0 MBit/s MCS 7
        rx duration:    0 us
        authorized:     yes
        authenticated:  yes
        associated:     yes
        preamble:       long
        WMM/WME:        yes
        MFP:            no
        TDLS peer:      no
        DTIM period:    1
        beacon interval:100
        short slot time:yes
        connected time: 882 seconds
        associated at [boottime]:       10729.372s
        associated at:  1715528954368 ms
        current time:   1715529834558 ms

[ZerBea]

@ma8ma That speed is surprisingly low. Are you far from the access point/router?

Could you run this in another terminal while you test the speed again? iw dev wlx7403bdea6ebe station dump

@ZerBea Does sudo hcxdumptool wlp48s0f4u2u1 --rds=1 bring down the interface and then up again before it starts transmitting? Or does it change the MAC address before transmitting?

hcxdumptool does:

1. set interface down (RT-NETLINK)
2. set interface mac  (RT-NETLINK)
3. set monitor mode (NL80211)
4. set interface up (RT-NETLINK)
5. set powersave off (NL80211)
followed by:
get interfacestatus (NL80211)
get interfacestatus (RT NETLINK)
followed by scan loop:
set timer (EPOLL)
set frequency (NL80211)

Important notice: The entire procedure is not comparable to e.g. macchanger! The virtual MAC (IFLA_ADDRESS) is changed by hcxdumptool (during the init process) but unused as long as ACTIVE MONITOR MODE is not selected via "-A" option and allowed by device (NL80211_FEATURE_ACTIVE_MONITOR).

This is the RADIOTAP header:

static const u8 rthtxdata[] =
{
0x00, 0x00, /* radiotap version and padding */
0x0a, 0x00, /* radiotap header length */
0x00, 0x80, 0x00, 0x00, /* bitmap */
0x18, 0x00 /* tx flags */
};

followed by the entire 802.11 frame!

The entire process can be monitored via NETLINK monitor interface in combination with Wireshark:

sudo ip link add  nlmon0 type nlmon
sudo ip link set dev nlmon0 up

It is working as expected on all tested kernel tree drivers and some out of kernel tree drivers: https://github.com/kimocoder/realtek_rtwifi https://github.com/aircrack-ng/rtl8812au https://github.com/lwfinger/rtw88 (RTW8821CE)

BTW: The combination of ip and iw is doing nearly the same as hcxdumptool/hcxlabtool.

[dubhater]

@ma8ma The signal strength and tx/rx rates look good. I guess your internet connection is just that slow.

@ZerBea Okay, then it looks like the same problem I see when I enable NetworkManager's MAC address randomisation. The first attempt to connect fails:

wlp3s0f3u4: send auth to ... (try 3/3)
rtw_8821au 1-4:1.0: failed to get tx report from firmware
wlp3s0f3u4: authentication with ... timed out

The second attempt works. I'll investigate more later.

[ZerBea]

@dubhater Thanks.

[lwfinger]

@dubhater - Ignore my complaint about [100545.061997] rtw_8821au 2-6:1.0: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status and [100545.062001] rtw_8821au 2-6:1.0: band wrong, packet dropped errors. I had the NIC plugged into a USB port that is a bit worn. In addition, the NIC's socket is a bit large. Apparently the resulting sloppiness caused some connection to be interrupted. I moved it to a different port, and the problems went away.

I will revert my patch.

[morrownr]

@lwfinger

@ZerBea said: make uninstall doesn't remove: rtw88_8723x.ko

I took a look in Makefile and I see the following. Is it a typo?

obj-m           += rtw88_8723x.o
rtw88_8723x-objs    := rtw8723x.o

If following the convention you have in the Makefile, it seems to me that it should read:

obj-m           += rtw_8723x.o
rtw_8723x-objs  := rtw8723x.o

I'm not touching it as it is not clear to me what your intention was.

[lwfinger]

Fixed. It should have been rtw_8 rather than rtw88_8. The difference is in the name of the .ko that is produced.

[ZerBea]

@dubhater Some additional information. I've disabled to set the virtual MAC in hcxdumptool. Now dmesg shows:

[ 5223.268659] rtw_8821au 5-2.1:1.0 wlp48s0f4u2u1: renamed from wlan0
[ 5232.906547] rtw_8821au 5-2.1:1.0: MAC has not been powered on yet
[ 5235.441079] rtw_8821au 5-2.1:1.0 wlp48s0f4u2u1: entered promiscuous mode
[ 5241.015642] rtw_8821au 5-2.1:1.0: failed to get tx report from firmware
[ 5242.002540] rtw_8821au 5-2.1:1.0: failed to get tx report from firmware
[ 5243.015644] rtw_8821au 5-2.1:1.0: failed to get tx report from firmware
[ 5244.005652] rtw_8821au 5-2.1:1.0: failed to get tx report from firmware
[ 5244.152333] rtw_8821au 5-2.1:1.0 wlp48s0f4u2u1: left promiscuous mode

Monitor mode and packet injection is not working. Looks like it is not a problem of the virtual MAC, because device is powered off in monitor mode.

[morrownr]

@dubhater

Monitor mode and packet injection is not working.

After seeing @ZerBea 's comment, the first thing that popped into my mind is where is there code that is working and might serve as an example, possibly even pointing us in the right direction?

mt76. The mt7610u (AC600) driver and the mt7612u (AC1200) driver both set the standard for monitor mode support and both support Active Monitor mode. @ZerBea , do you agree with this statement?

[ZerBea]

@morrownr mt76 update on kernel 6.8.9-arch1-2 and "sudo hcxdumptool --rds=1 -A" -A = set NL80211_MNTR_FLAG_ACTIVE

mt76x0u: running active monitor mode this driver is working as expected!

0 ERROR(s) during runtime
873 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
1 SHB written to pcapng dumpfile
1 IDB written to pcapng dumpfile
1 ECB written to pcapng dumpfile
61 EPB written to pcapng dumpfile
exit on sigterm

mt7601u: running active monitor mode this driver is partly working - only frames addressed to the device MAC (IFLA_ADDRESS) and addressed to broadcast are forwarded via raw packet socket (PF_PACKET, SOCK_RAW)

0 ERROR(s) during runtime
1184 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
1 SHB written to pcapng dumpfile
1 IDB written to pcapng dumpfile
1 ECB written to pcapng dumpfile
50 EPB written to pcapng dumpfile
exit on sigterm

mt7921u: running active monitor mode neither monitor mode nor packet injection is working

0 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
Warning: too less packets received (monitor mode may not work as expected)
Possible reasons:
 no transmitter in range
 frames are filtered out by BPF
 driver is broken
1 SHB written to pcapng dumpfile
1 IDB written to pcapng dumpfile
1 ECB written to pcapng dumpfile
0 EPB written to pcapng dumpfile
exit on sigterm

mt76x2u: running active monitor mode neither monitor mode nor packet injection is working

0 ERROR(s) during runtime
0 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
Warning: too less packets received (monitor mode may not work as expected)
Possible reasons:
 no transmitter in range
 frames are filtered out by BPF
 driver is broken
1 SHB written to pcapng dumpfile
1 IDB written to pcapng dumpfile
1 ECB written to pcapng dumpfile
0 EPB written to pcapng dumpfile
exit on sigterm

All drivers set/report active monitor mode capabilities: NL80211_FEATURE_ACTIVE_MONITOR

[morrownr]

@ZerBea

mt76x0u: running active monitor mode this driver is working as expected!

Okay, then the mt7610u might be the best example to look at.

I knew the mt7921u driver has broken Active Monitor mode but did not realize that mt7612u has an issue.

For those that may be reading this thread, Active Monitor mode is a specific mode within monitor mode. Monitor mode may work perfectly... which I think it is close on the mt7612u and mt7921u drivers, but there are some use cases that either require or work much faster if Active Monitor is turned on and works correctly.

Is it possible to get an assessment of this driver, rtw_8821au, while not using Active Monitor mode? That is, how good, overall is monitor mode right now? Sorry for all the questions but there are folks here that do not have a PhD in WiFi Security Analysis.

The rtw_8821au driver says that it supports Active Monitor mode? (which we should turn off if we cannot fix it in the short term?)

How do we know the driver says is supports Active Monitor mode:

$ iw list

Look for the following line:

Device supports active monitor (which will ACK incoming frames)

[lwfinger]

Yes, I turned that mode on. Having that parameter set is a necessary, but not sufficient step. It is not in the in-kernel driver, just in this repo.

[ZerBea]

@morrownr iw's message is misleading: Device supports active monitor (which will ACK incoming frames) Correct is: Device supports active monitor (which will ACK incoming frames addressed to the device MAC) That's a huge difference!

Running in monitor mode, a device that ACK all(!) incoming/received frames regardless if they are addressed to the device MAC or not, will mess up the entire traffic on a channel!

[morrownr]

@lwfinger

Yes, I turned that mode on. Having that parameter set is a necessary, but not sufficient step. It is not in the in-kernel driver, just in this repo.

I'm with you on that. We'll just need to revert it if we cannot fix this. I do not think it will be easy so I was trying to figure out where the best example code might be and, with @ZerBea 's help, it appears that said code may be in mt7610u. I hope it can help.

This is a highly desirable feature but right now, based on the issues that have come up, I would rank the issues in this priority order:

1. The drop issue. While this driver is very stable in managed and AP modes, it is showing the drops in both modes. I am probably not saying this properly but I first noticed the odd behavior using wavemon and is calls it drop. I just tested with my PCIe card using a mt7921e driver with a mt7922 chip and zilch. Drop does show up in wavemon until there is at least one drop counted and nothing ever showed and I beat on it pretty hard. I can do more testing with other cards and adapters if anyone thinks that might be desireable. I'm wondering if this is usb specific.

2. Active Monitor mode. This is a desirable feature but is not a show stopper as far as getting a solid driver into the kernel goes. I was thinking that if we can figure this out now, it might help bring the capability to the rest of rtw88.

3. AP mode DFS support. This is the lowest priority but someone should probably ask Ping-Ke if Realtek really does have the certs for this before we waste our time.

Overall getting to the bottom of item 1 is most important. I have beat up AP mode over the last few days and it seems to be solid... I did see the drop issue there as well but the driver is solid, performance is good and no disconnects. I'm going to move on to testing P2P later this week.