(info) RTL8811AU device fixed to channel 1 (cannot set band or channel)

[drws]

I'm trying to use an Edimax EW-7811UAC (containing RTL8811AU) in monitor mode on a Raspberry Pi and it appears it is staying fixed to channel 1 in the 2.4GHz band. airodump -c 11 or airodump -b a are always returning channel 1 data for example. iw list lists all the expected channels in the 2.4 and 5 GHz bands, but iw wlan0 set channel 11 produces command failed: Device or resource busy (-16) while the interface is not in use, not even by network managers. I have enabled ARM support during the build process and the interface appears to be working, except channel switching.

[morrownr]

Hi @drws

Recommend you read the file Monitor_Mode.md in the /docs folder. It shows you how to do things manually and it points you to a script test-mon.sh that is located here in the driver directory.

This driver and the 8812au are pretty good drivers for monitor mode ... for Realtek drivers. The thing we have to be aware of is that these Realtek out-of-kernel drivers are not Linux Wireless Standards compliant. What that means is that you will run into that things that don't seem to work by the instructions you are looking at. Most of the guides and app instructions are written for drivers that are Linux Wireless Standards compliant. Before you ask why Realtek does what it does, let me say that I have no idea. It is what it is.

For standards compliant adapters, you can stop by the following site for information, discussions (see issues and discussions) and links to many adapters:

https://github.com/morrownr/USB-WiFi

If you have any questions regarding the document and script that I suggested above, let me know.

Regards

[drws]

Thank you for the thorough intro. I know Realtek is mildly put not the best option, but I would like to make use of an adapter I have at least for surveying purposes. I was using commands from Monitor_Mode.md before. I have now retried them with manual monitor mode switching and it seems that after using iw wlan0 set monitor control the resource busy error is no longer displayed when channel is set and I am now getting data from all channels in both bands.

Even though the error is not displayed anymore, the channel doesn't change nor with iw (while interface is in any of the states) nor with airodump's --channel or --band parameters. iw always reports channel 1, even while airodump's running and actively hopping channels.

Currently it seems that channel can be set somehow since airodump is returning multiple channel data. But I'm not sure airodump is the one that is doing the actual hopping, it could be the card itself. If airodump knew how to set a channel, its --channel and --band should be working.

[morrownr]

Did you run?

$ airmon-ng check kill

What are you seeing when you run?

$ sudo ./test-mon.sh

[drws]

I did ran airmon-ng check kill last time, but error -16 was still showing after and only the enablement of the monitor mode with iw wlan0 set monitor control made it go away. This appears to be the crucial thing to run before airodump-ng and after that it now seems that airodump's --band and --channel are actually working, with a bug however. It appears that only some data from the other channels is received, remmants from the previously active scan. Apparently I have mistakenly interpret this as continuous all-channel hopping before.

To reproduce one can run airodump-ng without --band or --channel parameters for a short amount of time and re-run it with one of those parameters afterwards. The output contains old remmant data and it happens practically every time.

The current workaround is to run airodump-ng twice with the same filtering arguments or using its --berlin option, which only filters the displayed data after a timeout. The remmants are still captured if recording to a file is set.

To recap, I see these main issues:

• iw dev always returning channel 1 in the 2.4GHz band, even during airodump-ng's 5GHz-only scan for example
• iw wlan0 set channel might not be working correctly
• iw wlan0 set monitor control has to be run before airodump-ng for the --band and --channel filtering to work
• airodump-ng receives frames from previous scans (only in the beginning)

[morrownr]

I did ran airmon-ng check kill last time, but error -16 was still showing after and only the enablement of the monitor mode with iw wlan0 set monitor control made it go away.

Okay. That looks normal to me. Where is the problem?

This appears to be the crucial thing to run before airodump-ng and after that it now seems that airodump's --band and --channel are actually working

Yes, crucial thing is very good way to put it. If you do not stop or kill certain processes then they will be fighting you for control. Some of what you have been talking about is exactly what happens when you do not stop or kill those processes. airmon-ng check kill does a pretty good job but not always perfect. I am currently adding this capability to my test-mon.sh. I am hoping that it works a little better than airmon-ng check kill. Do you want to test it?

, with a bug however. It appears that only some data from the other channels is received, remmants from the previously active scan. Apparently I have mistakenly interpret this as continuous all-channel hopping before.

To reproduce one can run airodump-ng without --band or --channel parameters for a short amount of time and re-run it with one of those parameters afterwards. The output contains old remmant data and it happens practically every time.

I will take a look as I have time. Keep in mind that I maintain this driver, not Aircrack-ng. This driver is very heavily used and you are the only one reporting this so I am skeptical that it is a problem with the driver. Would you check this by using another app that does the same thing... maybe Wireshark?

The current workaround is to run airodump-ng twice with the same filtering arguments or using its --berlin option, which only filters the displayed data after a timeout. The remmants are still captured if recording to a file is set.

To recap, I see these main issues:

• iw dev always returning channel 1 in the 2.4GHz band, even during airodump-ng's 5GHz-only scan for example

You have not run my test-mon.sh script have you? This script is such that if you see that something is working with the script, you can look at the source in a text editor to see what commands are working. Most guides and even some of the instructions that go with Aircrack-ng are for standards compliant drivers. Let me say this again... Realtek's USB WiFi drivers are NOT standards complant. I wish they were but it is what it is and we in the community do not have the ability to do a total rewrite to make them compliant.

• iw wlan0 set channel might not be working correctly
• iw wlan0 set monitor control has to be run before airodump-ng for the --band and --channel filtering to work

I am curious about what has caused you to think that this command would work without monitor mode being set?

I realize I am sounding somewhat short at this point but I need to get your attention so please listen:

• I am not an instructor of a wireless security analysis/pen testing class.
• I am the head maintainer of this driver and am glad to work issues with the driver if I can.
• I do not get paid to maintain this driver.
• I understand that monitor mode can be a little challenging at first.
• If I see a situation where I offer some advice and that advice is ignored, and that appears to be the case here, I will discontinue my efforts to help.

[drws]

Okay. That looks normal to me. Where is the problem?

I see my error in wrongly predicting channel setting should also work in STA mode. But the error type returned (resource busy) is still not the most descriptive when the interface is not in the right mode to be able to change the channel and not claimed otherwise. Is it a Realtek thing?

Keep in mind that I maintain this driver, not Aircrack-ng.

I am aware of that and will be submitting issue report there if we find it necessary.

This driver is very heavily used and you are the only one reporting this so I am skeptical that it is a problem with the driver.

I feel the same way during all of this and only posted issue report here in good faith.

You have not run my test-mon.sh script have you?

Even though I prefer to go step by step to learn more about these tools myself, I have ran your script before even though I did not explicitly state so. I thought copy of the main commands used would suffice and I see now that a complete terminal log would be more useful. I have also compared the used Monitor_Mode.md's and test-mon.sh's commands and their execution order to double-check no error would slip there and as said, also tried running the script.

The test-mon.sh did show the channel as changed, but only because it deliberately outputs what the user entered and not what iw dev wlan0mon info provides (prints $chan instead of $iface_chan), which is always channel 1. And that's why I prefer to do such operations manually.

Realtek's USB WiFi drivers are NOT standards complant. I wish they were but it is what it is and we in the community do not have the ability to do a total rewrite to make them compliant.

I understand that and please tell me where I'm chasing ghosts, but for example I would sincerely expect even a non-compliant driver to be able to display set channel. It is one of the most basic radio parameters afterall, it's not some exotic proprietary protocol extension. Even if not, I know you're not the one to blame.

• iw wlan0 set channel might not be working correctly

I am curious about what has caused you to think that this command would work without monitor mode being set?

As explained above I'm taking this one back.

• iw wlan0 set monitor control has to be run before airodump-ng for the --band and --channel filtering to work

I am curious about what has caused you to think that this command would work without monitor mode being set?

I believe airodump-ng puts the card into monitor mode if it's not already, even if some parts of the documentation hint otherwise. However, it is partly failing in our case: it enables monitor mode, but in a way that it cannot switch channels afterwards, which considering the fact that it works with other drivers and the issue of iw dev always getting channel 1, seems driver-related.

Also, airmon-ng start wlan0 doesn't suffice, it has to be iw dev wlan0 set monitor * for the --band and --channel to work afterwards...

• I am not an instructor of a wireless security analysis/pen testing class.

I have to stress that nothing in this issue report is security-related in any way. I'm talking about low-level radio network analysis that the driver can provide and need no pentesting tips.

• If I see a situation where I offer some advice and that advice is ignored, and that appears to be the case here, I will discontinue my efforts to help.

Of course, just please say so if you do.

Do you want to test it?

I can test the improved script even though I am not even a bit convinced check kill is truly necessary in my case since I know what is running on my system, claiming the interface, and it's nothing. It's an almost-embedded system with no GUI, running selected services. Again, I can of course test it to help and also out of curiosity how will you be doing the process detection.

Would you check this by using another app that does the same thing... maybe Wireshark?

Will do further testing about the issue sooner or later, let's just clear things up a bit more first.

[morrownr]

Good morning @drws

I see my error in wrongly predicting channel setting should also work in STA mode. But the error type returned (resource busy) is still not the most descriptive when the interface is not in the right mode to be able to change the channel and not claimed otherwise. Is it a Realtek thing?

I guess we can call it a Realtek thing because there is a lot of standardization in how the in-kernel drivers, whether usb or internal wifi cards, handle things like this. I understand the frustration that non-specific error codes can cause.

You have not run my test-mon.sh script have you?

Even though I prefer to go step by step to learn more about these tools myself, I have ran your script before even though I did not explicitly state so. I thought copy of the main commands used would suffice and I see now that a complete terminal log would be more useful. I have also compared the used Monitor_Mode.md's and test-mon.sh's commands and their execution order to double-check no error would slip there and as said, also tried running the script.

Let me throw this out: There was a gentleman in one of these Realtek driver repos I maintain here that stopped by last year raising hell about not being able to change the mac address of his adapter. He explained that it always worked with his old Ralink chipset based adapter that uses an in-kernel driver. I fiddled around for a little while and discovered that with these Realtek drivers you have to change the mac address before you enter monitor mode (or you get that wonderful resource busy nonsense). I explained this, the gentleman tried it and off he went. Repeat this with various other issues and you see why I try to post a guide and script to help.

The test-mon.sh did show the channel as changed, but only because it deliberately outputs what the user entered and not what iw dev wlan0mon info provides (prints $chan instead of $iface_chan), which is always channel 1. And that's why I prefer to do such operations manually.

I am aware of how the script is written. The reason I point you to the script is that a lot of testing has gone into the script so a lot can be learned from the order and exact commands that are used. The script may be printing $chan to the screen but the lesson is in why I did that. What I discovered is that the channel is changed when the command to set the channel is run but iw does not indicate it but you can see from the result that the channel was changed. The script should provide a quick confirmation that this is the case. I can work on minor issues and clean some things up but major rewrites to clean things like this up are beyond the scope of what I have time or desire to do. If you are going to use the Realtek drivers, you need to get away from the mindset of how things should work and concentrate on how they really do work. The alternative it get a usb adapter or card that uses in-kernel drivers and many people go that route.

Do you want to test it?

I can test the improved script even though I am not even a bit convinced check kill is truly necessary in my case since I know what is running on my system

It may not be. The improved version of the script i am working will tell you if there are problem processes as it STOPS them. I am not using KILL. I am using STOP and CONT. I am out of time for now but will send a working copy of the new script as I have time later today or tomorrow.

Regards

[morrownr]

test-mon.sh.tar.gz

Here is test-mon.sh in its current state.

The main new thing in this edition is that it handles problematic processes on its own instead of relying on airmon-ng. The approach that airmon-ng takes is that it simply kills the processes it thinks may interfere. That may be fine for those only have one adapter running in monitor mode but I always have multiple adapters connected to my dev system and I don't need everything wireless to die when I am testing monitor mode. There may be multiple ways to accomplish what I want, but the idea in use in test-mon.sh currently is simply to identify the processes that could cause problems and STOP (basically halt) them. This approach is less drastic and allows the system to be returned to its original state via CONT without a reboot.

Of interest to you is that I am having the script stop and post the processes that it is stopping so that you can see them. That way we can see if you were on the right track when you said you did not think your setup would have any problematic processes. Post the results so we can discuss it if you don't mind.

Another thing is that this script is a work in progress so if you have some great ideas, bring them on. So far development has centered around my plan to have a script to speed up checking the results of my work on drivers but I see that this could spawn a more operational companion script.

Regards

[drws]

I had the device-in-question caught up in some project so it took some time, but I've tested your improved script now. The output is as expected:

The following processes have been stopped:

  PID Name

 Press any key to continue... 

When trying to set fixed channel with the script, the iw dev is actually returning correct channel now. Running airodump-ng wlan0mon afterwards makes device hop all 2.4GHz channels and the channel value is now changing. I did update the kernel (to 5.15.24) and DKMS module was rebuilt with it, but I haven't updated the module itself from previous experiments. The iw dev wlan0mon set channel now works for 2.4GHz channels as well.

However now I cannot find a way to make 5GHz work. Using airodump-ng's --channel or --band always displays channel 1 data only and even with 2.4GHz it seems to be all channels or channel 1 only.

In any case I've accepted the fact that:

If you are going to use the Realtek drivers, you need to get away from the mindset of how things should work and concentrate on how they really do work.

And I guess Realtek can make you think I should've gotten an Alfa...

[ivanovborislav]

Hi, drws! Can you test this git clone https://github.com/ivanovborislav/rtl8821au.git please!

[drws]

First of all it now appears that --channel and --band started working after physically replugging the interface so all in all this issue is partly resolved.

@ivanovborislav Your fork does indeed work the best, iw shows any channel set and even 5GHz channels can be manually set now. We'd probably all be interested if you could comment on your approach a bit.

[ivanovborislav]

I tried to find a driver for my old phone (Samsung Galaxy S5 plus Kali NetHunter, rtl8821au) without success. One, couldn't compile, other didn't work in monitor mode. Then tried change the source to support kernel below 3.5.0 and monitor mode. Start with EW-7811UTC_Linux_Driver_4.3.19.5 (rtl8821AU_linux_v4.3.19.5_17672.20160506_BTCOEX20150921-58), I read, compare different drivers, change a few lines and test the result.

If you read os_intfs.c (rtl8821AU_linux_v5.12.5.2-0-g70054197b.20210708_COEX20190509-6d6f) you see this:

#ifdef CONFIG_REGD_SRC_FROM_OS
static uint rtw_regd_src = CONFIG_RTW_REGD_SRC;
module_param(rtw_regd_src, uint, 0644);
MODULE_PARM_DESC(rtw_regd_src, "The default regd source selection, 0:Realtek defined, 1: OS");
#endif

Regulatory Domain selection, is a just one single line #define CONFIG_REGD_SRC_FROM_OS (I add this line, nothing more).

Let's see...

ioctl_cfg80211.c (rtl8821AU_linux_v4.3.19.5_17672.20160506_BTCOEX20150921-58)

static int  cfg80211_rtw_set_channel(struct wiphy *wiphy

    #if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,35))

    , struct net_device *ndev

    #endif

    , struct ieee80211_channel *chan, enum nl80211_channel_type channel_type)

{

    int chan_target = (u8) ieee80211_frequency_to_channel(chan->center_freq);

    int chan_offset = HAL_PRIME_CHNL_OFFSET_DONT_CARE;

    int chan_width = CHANNEL_WIDTH_20;

    _adapter *padapter = wiphy_to_adapter(wiphy);

Can put the card into monitor mode(use patch) and can start airodump-ng, older kernel.

ioctl_cfg80211.c (rtl8821AU_linux_v5.12.5.2-0-g70054197b.20210708_COEX20190509-6d6f)

static int  cfg80211_rtw_set_channel(struct wiphy *wiphy
    #if (LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 35))
    , struct net_device *ndev
    #endif
    , struct ieee80211_channel *chan, enum nl80211_channel_type channel_type)
{
#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 35))
    _adapter *padapter = (_adapter *)rtw_netdev_priv(ndev);
#else
    _adapter *padapter = wiphy_to_adapter(wiphy);
#endif

Can put the card into monitor mode but can't start airodump-ng, older kernel.

etc.

[oneshotbin]

Hi Nick, nice driver and nice test-mon.sh script ! I encountered the same issue with Kali+8811AU on Raspberry 3B+ , when I use airodump-ng to capture WPA handshake , it has "fixed channel wlan0mon:1" error on the right corner of screen and can not send deauth packet successfully . Use you test-mon.sh I can set txpower,change channels sucessfully. here is the debug information:

└─$ uname -a; mokutil --sb-state; lsusb; rfkill list all; dkms status; iw dev Linux kali-raspberry-pi 5.15.44-Re4son-v8+ #1 SMP PREEMPT Debian kali-pi (2022-07-03) aarch64 GNU/Linux EFI variables are not supported on this system Bus 001 Device 006: ID 0bda:a811 Realtek Semiconductor Corp. RTL8811AU 802.11a/b/g/n/ac WLAN Adapter Bus 001 Device 007: ID 0424:7800 Microchip Technology, Inc. (formerly SMSC) Bus 001 Device 003: ID 0424:2514 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub Bus 001 Device 002: ID 0424:2514 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub 0: phy0: Wireless LAN Soft blocked: no Hard blocked: no 1: phy1: Wireless LAN Soft blocked: no Hard blocked: no 2: hci0: Bluetooth Soft blocked: no Hard blocked: no phy#1 Interface wlan0mon ifindex 4 wdev 0x100000001 addr ac:e0:11:f9:c7:64 type monitor channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz txpower 27.00 dBm phy#0 Interface wlan0 ifindex 3 wdev 0x1 addr b8:18:eb:43:cc:cb type managed channel 4 (2427 MHz), width: 20 MHz, center1: 2427 MHz txpower 12.00 dBm

Any idea? can I use other tools instead of aircrack-ng to do the test ? Which one do you suggest to choose?

[morrownr]

Hi @oneshotbin

nice test-mon.sh script

I actually retired that script a while back. My work along these lines can be found at item 10 of the Main Menu:

https://github.com/morrownr/USB-WiFi

There will be test document and a start-mon.sh script that helps you get into monitor mode. It may very well help with your problem.

For capturing I use Wireshark:

sudo apt install wireshark

Use the script to get into monitor mode and then call up wireshark:

sudo wireshark

Nick

[oneshotbin]

Hi Nick , Thanks for your quick response and your suggestions , I will study on the links you provide and have a nice day :)