(in-progress) Some differences between this driver and the older repo about 8821au-20210708 HOT 27 CLOSED

• For some reason, wpa_supplicant seems to be not quite compatible with this driver, since I never got wpa_cli -i RTL8811AU_DONGLE_INTERFACE to work. The error was "Could not connect to wpa_supplicant: RTL8811AU_DONGLE_INTERFACE - re-trying". (I do not think the older driver worked here either, but am not 100% sure I tested it.)

What version of wpa_supplicant are you using?

• When starting wpa_supplicant, there is still the same error in dmesg, or according to journalctl: "wpa_supplicant[851254]: nl80211: kernel reports: Authentication algorithm number required". But it seems to work (see above), so this must be minor.

I will take a look.

• Despite rtw_drv_log_level=0 in /etc/modprobe.d/8821au.conf, The dmesg log is severely spammed (2-3 seconds between each) by messages such as "[191259.082604] RTW: rtl8812_sreset_xmit_status_check REG_TXDMA_STATUS:0x00000401" during normal operation. Note that it says 8812, not 8811 (which matches my chipset) or 8821 (which is the name of this driver).

The 8811au chipset driver used to be included in the 8812au driver. The 8821ai/8811au driver was only broken out as a separate driver last year with the old driver here. The old driver had "8812" all over the place. It is much better now but obvious the cleanup is not complete.

The log mess is concerning. I'll take a look.

• Despite rtw_drv_log_level=0 in /etc/modprobe.d/8821au.conf, during start of either wpa_supplicant or hostapd, it seems every step of the setup process is logged there too, with "RTW" as a prefix in dmesg.

Ditto.

• The default output power in the AP mode, as reported by e.g. iw phy#2 channels, was not higher than +13 dBm in any of the 5 GHz channels, which is lower than the older driver reported. The older driver supported up to +31 dBm for some (not all) of the 5 GHz channels.
  The last issue above is annoying, but not really a stopper, since a command such as this can be used to increase the output power if needed: iw phy#2 set txpower fixed 2000 Note that higher output power is not always better, but that is a completely separate discussion

I'll take a look as I have time.

from 8821au-20210708.

Thanks.

What version of wpa_supplicant are you using?

Version 2.9, which is the default in Ubuntu 21.04.
wpa_supplicant -v:

wpa_supplicant v2.9

Or, according to apt show wpasupplicant | grep Version:

Version: 2:2.9.0-21

from 8821au-20210708.

Oops, I think I made a mistake. I did not reboot after installing the new driver, just insmod/modprobe. After at reboot, there were no longer any RTW log messages, so I guess just activating the driver the way I did it did not read the /etc/modprobe.d/ config file. So ignore the RTW log issue above.

To clarify, the wpa_supplicant "nl80211: kernel reports: Authentication algorithm number required" error message in the log is still there after a reboot.

from 8821au-20210708.

• When using this driver in the AP mode (hostapd), it still works more or less as before.

Would you mind posting the hostapd.conf that you are using? Maybe we can crosscheck each other to see if there are any settings that we are using that are problematic.

from 8821au-20210708.

Oops, I think I made a mistake. I did not reboot after installing the new driver, just insmod/modprobe. After at reboot, there were no longer any RTW log messages, so I guess just activating the driver the way I did it did not read the /etc/modprobe.d/ config file. So ignore the RTW log issue above.

Ignoring as requested... sort of. You caused me to do some more thinking. In the previous edition of this driver, I used 0 in the Makefile. I had left 4 as we worked on this new driver. @5kft submitted a PR that changed the setting to 0 but somehow in the days after that merge, I managed to change it back to 4. I'm going to change the setting back to 0 and add additional documentation regarding debug log level. I'll try to get that cleaned up today if possible.

To clarify, the wpa_supplicant "nl80211: kernel reports: Authentication algorithm number required" error message in the log is still there after a reboot.

I will add this to my to-do list. For various reasons, it would be nice if we had a new release of wpa_supplicant that could work its way into our distros because WPA3 support is not practical for most users of these Realtek drivers until that happens. There are almost no issues, certainly no major issues, with in-kernel drivers and wpa_supplicant but then the primary author of wpa_supplicant is a kernel dev working on Atheros wifi drivers among other things.

from 8821au-20210708.

Would you mind posting the hostapd.conf that you are using? Maybe we can crosscheck each other to see if there are any settings that we are using that are problematic.

Would you also post the options line of your /etc/modprobe.d/8821au.conf file?

from 8821au-20210708.

To clarify, the wpa_supplicant "nl80211: kernel reports: Authentication algorithm number required" error message in the log is still there after a reboot.

I will add this to my to-do list.

FWIW, I saw this as well when I was looking at this new driver previously - however when I switched to the newer supplicant (i.e., "top-of-tree" version) this error went away. So it seems like an existing issue in the default older "current" supplicant that is currently provided by the distro.

For various reasons, it would be nice if we had a new release of wpa_supplicant that could work its way into our distros because WPA3 support is not practical for most users of these Realtek drivers until that happens.

Yes, totally agree.

from 8821au-20210708.

• The default output power in the AP mode, as reported by e.g. iw phy#2 channels, was not higher than +13 dBm in any of the 5 GHz channels, which is lower than the older driver reported. The older driver supported up to +31 dBm for some (not all) of the 5 GHz channels.

Okay. I have completed testing txpower here with my 8811au based adapter...

My adapter is an Alfa AWUS036ACS. Tested in 5 GHz 80 MHz channel width AP mode on channel 36.

$ iw phy#0 channels
...
Band 2:
* 5180 MHz [36]
Maximum TX power: 13.0 dBm
Channel widths: 20MHz HT40- HT40+ VHT80
...
$ iw dev
...
phy#0
Interface wlx00c0caac47c7
ifindex 4
wdev 0x1
addr 00:c0:ca:ac:47:XX
ssid myPI-5g
type AP
channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
txpower 13.00 dBm
...
Output in wavemon for connected client: signal level: -65 dBM

$ sudo iw phy#0 set txpower fixed 1000

$ iw dev
...
phy#0
Interface wlx00c0caac47c7
ifindex 4
wdev 0x1
addr 00:c0:ca:ac:47:XX
ssid myPI-5g
type AP
channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
txpower 10.00 dBm
...
Output in wavemon for connected client: signal level: -67 dBM

$ sudo iw phy#0 set txpower fixed 1900

$ iw dev
...
phy#0
Interface wlx00c0caac47c7
ifindex 4
wdev 0x1
addr 00:c0:ca:ac:47:XX
ssid myPI-5g
type AP
channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
txpower 19.00 dBm
...
Output in wavemon for connected client: signal level: -60 dBM

Test result: The Maximum Tx Power of 13 dBm that was returned proved to be wrong because I was easily able to exceed that. I never attempt to increase or decrease tx power on an adapter without a method to show whether it is actually working. I used wavemon on a connected client in this case to see what happened to the signal as I increased and decreased tx power. The signal did indeed change as expected. I also used iperf3 at each tx power level to see if it made a difference. iperf3 results for 1000 and above were consistent at around 140 Mb/s and no retries. Once I took the tx power down to 600... whew, I saw seriously degraded performance. But that is within expectations.

Overall: Some adapters are hardcoded in firmware so your ability to change tx power can be limited. From where I sit, it appears the driver is working per specifications with the exception that Maximum Tx Power is being misreported. So functionality is not impacted which is good. I need to go take care of other issues for now but if you stumble across good information about how this issue can be corrected, let me know. Hint: I think I remember a PR regarding this subject with the old driver. If you can find that merge and point me to it, please do so.

Regards

from 8821au-20210708.

Nice. Regarding the incorrectly reported max TX power, the old driver reported this differently (i.e., higher power levels, IIRC it was up to +31 dBm). I connected a Raspberry Pi to the hostapd AP, and entered iw dev wlan0 info; iw dev wlan0 link to do what you did with wavemon, but I also confirmed that changing the TX output power actually did result in a measurable difference on the other end of the link.

Would you also post the options line of your /etc/modprobe.d/8821au.conf file?

The only thing I changed from the default was to disable powersaving, so it is perhaps not surprising that I did not get any 80 MHz channels with hostapd. And I did not update the beamforming to match what iw phy reports under "VHT Capabilities". Anyway, here it is:
cat /etc/modprobe.d/8821au.conf | sed '/^#/d' gives
options 8821au rtw_drv_log_level=0 rtw_vht_enable=1 rtw_power_mgnt=0 rtw_beamform_cap=10

Would you mind posting the hostapd.conf that you are using? Maybe we can crosscheck each other to see if there are any settings that we are using that are problematic.

Before I added the "ht_capab"/"vht_capab" lines, with 20 MHz channels, I got up to 72 Mbps (IIRC, more than 65 Mbps). Afterwards, with "ht_capab"/"vht_capab" and 40 MHz channels, I got at least 150 Mbps. Here is my slightly redacted config file:
cat hostapd.conf | sed '/^#/d' | sed '/^$/d' | grep -v -e passphrase -e ssid -e interface:

bridge=br0
hw_mode=a
channel=44
ieee80211n=1
ieee80211ac=1
wmm_enabled=1
ht_capab=[HT40+][HT40-]
vht_capab=[MAX-MPDU-11454][SHORT-GI-80][RX-STBC-1][SU-BEAMFORMEE][HTC-VHT]
macaddr_acl=0
auth_algs=1
wpa=2
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
ieee80211n=1
ieee80211ac=1
wmm_enabled=1

from 8821au-20210708.

The only thing I changed from the default was to disable powersaving, so it is perhaps not surprising that I did not get any 80 MHz channels with hostapd.

Would you mind posting the hostapd.conf that you are using? Maybe we can crosscheck each other to see if there are any settings that we are using that are problematic.

Before I added the "ht_capab"/"vht_capab" lines, with 20 MHz channels, I got up to 72 Mbps (IIRC, more than 65 Mbps). Afterwards, with "ht_capab"/"vht_capab" and 40 MHz channels, I got at least 150 Mbps.

bridge=br0
hw_mode=a
channel=44
ieee80211n=1
ieee80211ac=1
wmm_enabled=1
ht_capab=[HT40+][HT40-]
vht_capab=[MAX-MPDU-11454][SHORT-GI-80][RX-STBC-1][SU-BEAMFORMEE][HTC-VHT]
macaddr_acl=0
auth_algs=1
wpa=2
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
ieee80211n=1
ieee80211ac=1
wmm_enabled=1

Let's make a deal: I'll get you going with 80 MHz channel width and you go over the README here to see what improvements can be made. Deal?

First change:

options 8821au rtw_vht_enable=2

The only time you should set rtw_vht_enable=2 is when in AP mode looking for 80 MHz channel width. You must have it for 80 MHz channel width in 5 GHz AP mode but if you use it in other situations, your performance will suck.

Next: Time to make changes to hostapd.conf

channel=36 (or 149)
ht_capab=[HT40+][HT40-][SHORT-GI-20][SHORT-GI-40][MAX-AMSDU-7935]
vht_capab=[MAX-MPDU-11454][SHORT-GI-80][HTC-VHT]
vht_oper_chwidth=1
vht_oper_centr_freq_seg0_idx=42

For entertainment purposes, I am going to try to paste my 5 GHz hostapd.conf:

hostapd-5g.conf.txt

from 8821au-20210708.

Sure, I'll have a look at the README and see what suggestions I can come up with. I'm a bit short on time right now, but I'll test your hostapd.conf parameters a little later this week, and reply here once I have.

from 8821au-20210708.

I've not gotten the AP to work reliably for channel widths > 20 MHz. The Raspberry Pi 3 I have connected to it loses its connection after one to a couple of hours (but "instantly", within 15 seconds, reconnect after a systemctl restart hostapd on the AP). I logged some statistics, and while it never seems to lose the connection completely, the reported data rate (both TX and RX) can drop down to 6 Mbps, more commonly 24 Mbps (as opposed to 130+ Mbps after a fresh handshake).
I could monitor for lost connectivity, and restart the link when detected, but I will not...

However, I do not think this is the driver's fault, due to undervoltage warnings in the RPi's kernel log. I guess the wider channel consumes too much current, in the RPi itself and/or DC voltage drop in the feed cable.

I have tried different power supplies (both 5.0 V and 5.1 V) and different cables, but no change in behaviour. The next step is to hook it up to a lab power supply and feed it 5.2 V (which should be relatively safe, but 5.3 V is where many electronic components start to get out of spec and may physically break). But before I get rid of these undervoltage warnings, there is no point in trying to assess the stability of the driver.

from 8821au-20210708.

Let me make sure I understand the setup: Your 8811au based adapter is plugged into a usb port on a RasPi3b? If my understanding is correct, please allow me to throw out some info that may be useful:

RasPi's 3B to 4B have a max of 1200 mA that is available on the usb subsystem. Some usb adapters take a lot of power. My 8811au based adapter is measured at only 270 mA at heavy usage so I'll bet your adapter is close to that which is a low power requirement... but it also depends on the other things you have plugged in.

It could be your power supply not providing adequate power but you know that. I have an extra RasPi3B that is not working for a living currently so I will see about setting it up to test with my 8811au adapter this week to see what I see.

Here is a link to a power supply that has proven to be a very good power supply here:

https://www.amazon.com/dp/B08C9VYLLK

I have been seeing some issues that are either usb related or power related or both so I need to investigate further. Something seems to be wrong and it isn't just this driver, I'm also seeing it in the new 8812au driver that I am working which is still private right now.

from 8821au-20210708.

No, you misunderstood. I have the RTL8811AU-equipped dongle attached to a Seeed Odyssey, and that should have more than enough power for this dongle (even with the SATA HDD that is also attached). The undervoltage warnings appeared in the kernel log on the RPi3, which used its own, internal Wifi (no external USB parts whatsoever attached to the RPi3, but it does have a PiCamera module attached, which obviously consumes some power but I haven't looked into it in detail).

Having said that, it has now been up and running for about 12 hours, without voltage warnings or loss of connectivity, so I might have found a power supply/cable combination that was good enough. If it lasts another 12 hours without problems, it might be operational by now.

from 8821au-20210708.

Ah, I suspected there was some confusion on my end.

The Seeed Odyssey looks cool. Which model do you have?

FYI: After testing and bug fixing this weekend, I uploaded several changes. I think the contents of the repo are now very stable. Maybe I can talk you into doing a removal followed by a new download and reinstallation?

The problems I was seeing were related to power saving, usb support and LED support. It isn't clear to me what the causes were so I turned power saving off and removed LED control support. I will just have to work in the background over time to figure things out.

from 8821au-20210708.

I just installed the new driver, rebooted, and it worked straightaway (with your hostapd *_capab settings above):
modinfo 8821au | head -n 6

filename: /lib/modules/5.11.0-37-generic/updates/dkms/8821au.ko
version: v5.12.5.2-0-g70054197b.20210708_COEX20190509-6d6f
author: Realtek Semiconductor Corp.
description: Realtek Wireless Lan Driver
license: GPL
srcversion: 2619915BBA67651FD8B4770

I have a couple of scripts running that log server-side and client-side status once a minute, so I'll write back here if it doesn't seem to be stable.

The Seeed Odyssey looks cool. Which model do you have?

I have the X86J4105 model, which seems to have been replaced with a model with a newer CPU sometime this year. I'm pretty happy with it, it's like a Raspberry Pi on steroids, many times more powerful for just about twice the cost. It also has a Raspberry-compatible pin header (which I have not used myself).

The major reason I got it is that apart from a more powerful CPU, with a M2-to-SATA expansion board, you can hook up three SATA drives to it (in addition to the M2 drive my version shipped with), including power.

Review here: https://arstechnica.com/gadgets/2020/08/review-odyssey-x86j4105-a-mini-pc-for-makers-and-builders/

(If the internal Wifi had worked in AP mode at 5+ GHz, I would not have got the poorly supported RTL8811AU USB dongle that led me to your driver. :-) )

from 8821au-20210708.

Sorry about the delay, things came up... But I created a pull request with some in my opinions improvements to the Readme.

Regarding stability: I went back to the 20 MHz setup, but not even that was completely stable. It has been running for more than one week now, up and down according to this (screenshot from Nagios' host monitoring). I restarted hostapd last Saturday at about 1140, but have not touched it since.

There never seems to be any problems when connecting to the AP using the Realtek driver from this repo, but sometimes the RPi3 loses contact, and during the outages it records TX and/or RX speeds in the 6-24 Mbps range (not 72 Mbps as when everything is up and running). But I do not blame your driver (at least not yet :-) ) since I'd like to try some other hardware than that RPi3 first (but right now, I don't have any available - I guess this is a reason a reason to get yet another RPi4, but I don't have any other project planned that needs one).

One question/comment regarding the Readme: Does power saving work or not? It is listed under Features...

from 8821au-20210708.

Sorry about the delay, things came up...

I understand. That is life.

But I created a pull request with some in my opinions improvements to the Readme.

I appreciate the work on the README. It is good to have extra eyes going over things. Thanks.

Regarding stability: I went back to the 20 MHz setup, but not even that was completely stable. It has been running for more than one week now, [up and down according to this]

Up and down. Hmmm...

I ran mine in AP mode, 5 GHz, for a few days last week but did not see anything but then I am not running scripts that are logging things. I could try with the scripts here if you want.

There never seems to be any problems when connecting to the AP using the Realtek driver from this repo, but sometimes the RPi3 loses contact, and during the outages it records TX and/or RX speeds in the 6-24 Mbps range (not 72 Mbps as when everything is up and running).

Something to consider is that we are dealing with different types of drivers. The in-kernel drivers, including the Broadcom drivers for the Pi, are written to Linux Wireless Standards and are thus mac80211 style drivers whereas the Realtek out-of-kernel drivers are not. I have adapters based on Mediatek and Atheros chipsets that are supported by in-kernel drivers and the difference really comes to life in monitor mode. Note that I have added a doc file (Monitor_Mode) and a script (start-mon.sh) mostly to help users with the variations in how things are done. Run Aircrack-ng with an adapter that uses Mediatek or Atheros in-kernel drivers and everything works in accordance with the documentation. Not so with the Realtek out-of-kernel drivers.

But I do not blame your driver (at least not yet :-) )

This driver is Realtek's driver. I am simply trying to help it be something that is usable by inexperienced users and I, along with others that help, try to fix and update what we can.

One question/comment regarding the Readme: Does power saving work or not? It is listed under Features...

It works. Actually it works well... I think. The only option that I expose and document in 8821au.conf currently is rtw_power_mgnt. There are actually several more options that have to do with power saving but it is very complicated. I can elaborate if you have questions.

Lastly, this thread is getting close to exceeding my capability to keep up with the situation. Let me see....

You are using the internal 2.4 GHz radio on the Pi3b to access the 8811au adapter that is in the Sneeed system which is in AP mode?

Do you have a lot of congestion on the channel you are using?

from 8821au-20210708.

I appreciate the work on the README. It is good to have extra eyes going over things. Thanks.

No problem.

I ran mine in AP mode, 5 GHz, for a few days last week but did not see anything but then I am not running scripts that are logging things. I could try with the scripts here if you want.

No thanks, you've done plenty. But just FYI, on the client, I recorded the currently connected AP SSID, TX speed, RX speed and RSSI once per minute. The client device never "formally" left the access point, it just did not have any IP connectivity. And then, spontaneously, started to work again. On the AP side, it remained connected throughout the IP outage (according to iw dev DEVICE station dump -v), without warnings (that I could find) in the logs.

And as I said, I want to try something other that that particular RPi3 in order to pinpoint the problem.

But I do not blame your driver (at least not yet :-) )

This driver is Realtek's driver. I am simply trying to help it be something that is usable by inexperienced users and I, along with others that help, try to fix and update what we can.

I know, but "your driver" is a bit shorter than "the driver that I got from your git repo". And I appreciate the effort.

One question/comment regarding the Readme: Does power saving work or not? It is listed under Features...

It works. Actually it works well... I think. The only option that I expose and document in 8821au.conf currently is rtw_power_mgnt. There are actually several more options that have to do with power saving but it is very complicated. I can elaborate if you have questions.

No, I was referring to your comment above:
"It isn't clear to me what the causes were so I turned power saving off and removed LED control support"
And if that is still the case, it should not be under Features in the Readme, at least not without a "work in progress" or other disclaimer/caveat.

Lastly, this thread is getting close to exceeding my capability to keep up with the situation. Let me see....

You are using the internal 2.4 GHz radio on the Pi3b to access the 8811au adapter that is in the Sneeed system which is in AP mode?

Do you have a lot of congestion on the channel you are using?

No, I use the internal 5 GHz radio in the RPi3, in client mode, to access the RTL8811AU adapter plugged into a USB port on my Seeed Odyssey, which runs the AP. (The Odyssey's internal WiFi is disabled.) The channel does not seem to be congested according to my not very frequent checks with my Android phone.

It is possible that some neighbor's Wifi is messing with this channel, intermittently. However, since this driver and that chipset can be used to set up a AP in the protected "radar detection" bands, I can probably find a frequency band that no neighbors ever access (since most consumer APs are locked to the channels outside that range). I will try that next.

from 8821au-20210708.

No, I was referring to your comment above: "It isn't clear to me what the causes were so I turned power saving off and removed LED control support" And if that is still the case, it should not be under Features in the Readme, at least not without a "work in progress" or other disclaimer/caveat.

My bad for going back and forth during testing.

Regarding Power Saving. I have changed no code in the driver. The only difference from the driver default is that I am setting rtw_power_mgnt to 1 instead of the default 2. This is based on my testing of the various modes. Users are welcome to read the docs in 8821au.conf and set any of the 3 available options.

Regarding LED support. I had to add a lot of code to the driver for LED configuration support. I pulled all of that code back out when I could not stabilize the results. I'll do some behind the scenes work when able and try to get it going. This was pulled from the README. The README should be accurate. If it is not, please let me know.

However, since this driver and that chipset can be used to set up a AP in the protected "radar detection" bands, I can probably find a frequency band that no neighbors ever access (since most consumer APs are locked to the channels outside that range). I will try that next.

No USB WiFi driver for any platform is capable of DFS channels in AP mode as far as I can tell and I have searched a lot of code and docs. This driver can do DFS channels in managed mode. I wish we could do DFS in AP mode. You would have to go to one of the internal card format devices to get DFS in AP mode.

from 8821au-20210708.

No USB WiFi driver for any platform is capable of DFS channels in AP mode as far as I can tell and I have searched a lot of code and docs. This driver can do DFS channels in managed mode. I wish we could do DFS in AP mode. You would have to go to one of the internal card format devices to get DFS in AP mode.

What I meant was that I could find one interference-free channel among the DFS channels, and configure my AP to use that and only that channel. Since my wifi-interfering neighbors are likely not using that channel range.

Perhaps I'm not familiar with the distinction between managed mode and AP mode... But if we are talking about hostapd, isn't that what the channel, chanlist and freqlist parameters are for? From that link:

If CONFIG_ACS build option is enabled, the channel can be selected
automatically at run time by setting channel=acs_survey or channel=0, both of
which will enable the ACS survey based algorithm.

from 8821au-20210708.

What I meant was that I could find one interference-free channel among the DFS channels, and configure my AP to use that and only that channel. Since my wifi-interfering neighbors are likely not using that channel range.

Using a DFS channel on my ZyXEL NBG6817 (OpenWRT) WiFi router works very well because none of my neighbors even know what DFS is so DFS is wide open and clear. This ZyXEL uses an Atheros chipset internally and it is capable of DFS. I also have an ALFA AWUS036ACHM plugged into one of the USB ports on the ZyXEL so I can have two 5 GHz networks. The ALFA is a USB adapter so is not capable of DFS in AP mode.

Perhaps I'm not familiar with the distinction between managed mode and AP mode... But if we are talking about hostapd, isn't that what the channel, chanlist and freqlist parameters are for?

Yes but remember that hostapd is supporting all kinds of devices, not just USB adapters and the USB adapters drivers do not have the DFS code to support it. Give it and try and get back to me.

from 8821au-20210708.

Yes but remember that hostapd is supporting all kinds of devices, not just USB adapters and the USB adapters drivers do not have the DFS code to support it. Give it and try and get back to me.

I may have been mistaken about the DFS support in this driver. Check the new parameter in 8821au.conf:

rtw_dfs_region_domain

Give it a try and tell me if this driver supports DFS channels in AP mode.

Thanks.

from 8821au-20210708.

I added that line, followed by modprobe -r 8821au; modprobe 8821au, but I did not uninstall/recompile/install the driver from the newest master branch (I cloned this repo and installed on 2021-10-04). It did (still) not work, dmesg complained about "8821au: unknown parameter 'rtw_led_ctrl' ignored" but not the region flag, so at least it recognized it. I will install the newest driver, but not today.

As before, channels listed by iw phy that did not have "disabled" or "radar detection" after the channel number work just fine ([36:4:48], [149:4:165]). Trying to set a "radar detection" channel fails, and according to journalctl, it is hostapd that complains, but I do not know if hostapd gets this information from the 8821au driver or from the crda package.

Part of the journalctl output, when I tried channel 56:

hostapd[343179]: Channel 56 (primary) not allowed for AP mode, flags: 0x1979 RADAR
hostapd[343179]: wlan0: IEEE 802.11 Configured channel (56) not found from the channel list of current mode (2) IEEE 802.11a
hostapd[343179]: wlan0: IEEE 802.11 Hardware does not support configured channel
hostapd[343179]: Could not select hw_mode and channel. (-3)

Addition: The hostapd.conf file is identical to one I am using with channel 56 on a Raspberry Pi 4, except for ssid/interface/passphrase, both using hostapd v2.9 (but the RPi4 is Ubuntu 20.04, this driver is used on a Ubuntu 21.04 system).

from 8821au-20210708.

I added that line, followed by modprobe -r 8821au; modprobe 8821au, but I did not uninstall/recompile/install the driver from the newest master branch (I cloned this repo and installed on 2021-10-04). It did (still) not work, dmesg complained about "8821au: unknown parameter 'rtw_led_ctrl' ignored"

I found a coding error related to rtw_led_ctrl yesterday and fixed it. It should be working now but you will need to pull, ./remove-driver.sh and ./install-driver.sh again for the fix to activate. Please confirm the fix when able.

As before, channels listed by iw phy that did not have "disabled" or "radar detection" after the channel number work just fine ([36:4:48], [149:4:165]). Trying to set a "radar detection" channel fails, and according to journalctl, it is hostapd that complains, but I do not know if hostapd gets this information from the 8821au driver or from the crda package.

Part of the journalctl output, when I tried channel 56:

hostapd[343179]: Channel 56 (primary) not allowed for AP mode, flags: 0x1979 RADAR
hostapd[343179]: wlan0: IEEE 802.11 Configured channel (56) not found from the channel list of current mode (2) IEEE 802.11a
hostapd[343179]: wlan0: IEEE 802.11 Hardware does not support configured channel
hostapd[343179]: Could not select hw_mode and channel. (-3)

Addition: The hostapd.conf file is identical to one I am using with channel 56 on a Raspberry Pi 4, except for ssid/interface/passphrase, both using hostapd v2.9 (but the RPi4 is Ubuntu 20.04, this driver is used on a Ubuntu 21.04 system).

I'll try to recheck this as I have time this week.

from 8821au-20210708.

I got the latest driver. No dmesg LED-related error anymore, but my module doesn't have any LEDs, so I can't confirm that it works either.

But I did get the AP to work in DFS bands! It probably would have worked for the earlier driver too.

My solution, or my error, was that the rtw_dfs_region_domain parameter in /etc/modprobe.d/8821au.conf was set to 0 = "NONE (default) (use this option for managed mode)" (according to the comment). When I changed it, and set the country code in hostapd.conf to match, there was no longer any "radar detection" flags. And I could set the channel to anything that wasn't listed as a disabled channel in the channel list.

Thanks for all the help, I guess this issue can be closed now.

from 8821au-20210708.

My solution, or my error, was that the rtw_dfs_region_domain parameter in /etc/modprobe.d/8821au.conf was set to 0 = "NONE (default) (use this option for managed mode)" (according to the comment). When I changed it, and set the country code in hostapd.conf to match, there was no longer any "radar detection" flags. And I could set the channel to anything that wasn't listed as a disabled channel in the channel list.

Setting rtw_dfs_region_domain in the system that is running hostapd is the one that matters.

Cheers

from 8821au-20210708.