(can't fix) Hangs on `iw dev wlan0 del` about 8821cu-20210916

[morrownr]

Hi @ValdikSS

Ouch. That is bad behavior.

As much as I use usb wifi adapters, I never find the need to use that specific command so I can see why I would have missed this. May I ask what you are trying to accomplish?

Nick

[ValdikSS]

I never find the need to use that specific command so I can see why I would have missed this. May I ask what you are trying to accomplish?

I'm trying to use rtl8811cu on OpenWrt 22.03.3, and this is what is does internally.

[ValdikSS]

It locks here:

8821cu-20210916/os_dep/linux/os_intfs.c

Line 2219 in 8cb0ee1

unregister_netdevice(netdev);

I'm not sure which exact mutex/semaphore should not be acquired for unregister_netdevice.

[morrownr]

I took a look at where it locks today. I also tried to see when the last time that code was modified and could not determine when. It appears this code has not been touched in a long time and it is the same code is other WiFi 5 generation Realtek drivers so the search has to continue for a hint as to what could be causing this.

I use OpenWRT but only with adapters that use in-kernel drivers. I have no experience trying to use Realtek drivers on OpenWRT.

Have you tried the command on other platforms? x86_64 or ARM64?

I am hesitant to start playing with code until such time as we can narrow down whether this is an issue that affects more than just OpenWRT.

[Jibun-no-Kage]

I am testing on a Debian 11.6 x86_64 now, just happen to be created a VM so figured I would try to replicate the issue. @ValdikSS, what specific release of OpenWRT are you using? I happen to be familiar with OpenWRT. What hardware? Might be worth testing on OpenWRT for x86 as well.

[ValdikSS]

@Jibun-no-Kage, OpenWrt 22.03.3, x86 "generic" VM.
https://downloads.openwrt.org/releases/22.03.3/targets/x86/generic/

[Jibun-no-Kage]

Cool, that is what I needed to know, I will test on x86 generic OpenWRT as well. As for using the specific command, we pretty much all used NetworkManager in testing, Even when I did use iw I don't believe I ever have deleted an interface that way. Usually just replaced the entire configuration from scratch.

So x86_64, Debian 11.6, test results...

# ifconfig wlx00e032816834
wlx00e032816834: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 66:da:6d:75:0d:5a txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

# iw dev wlx00e032816834 del

# ifconfig wlx00e032816834
wlx00e032816834: error fetching interface information: Device not found

Following the basic core steps for setup and configuration, i.e. install-driver.sh with DKMS for Debian, and options file defaults, plus US as region. Reboot after installation. I was able to delete the interface without error. If tried both with the interface just created, then created and explicitly associated via nmcli. Same result no error.

So, might be specific to OpenWRT? Was there a different sequence of steps done?

Tomorrow I will create another distribution and validate... something not Debian/Unbuntu based. Maybe x86_64 Manjaro? And will try OpenWRT generic x86_64 as well, just as a sanity test.

[ValdikSS]

I have the same issue on Debian 12, on Fedora 37.

The exact steps are:

1. Plug the device, given the driver is already installed
2. Run iw dev _device_ del

That's it.

For the record:
aircrack-ng/rtl8812au#514
aircrack-ng/rtl8812au#374
diederikdehaas/rtl8812AU#56
brektrou/rtl8821CU#126

[ValdikSS]

If you're going to debug the issue, you might need to add printk's to every lock in the driver, and to notification functions, as I assume the deadlock is somewhere there (unregister_netdevice sends a notification during unregister process, which is handled by the driver).

The other way is to use lockdep kernel subsystem.

[Jibun-no-Kage]

I was able to recreate the hang on Manjaro x86_64. So at least we know this might be a greater scope than just OpenWRT. It did not crash the entire instance, but definitely hung up the network stack. I could not reference the interface via terminal session or via network manager via the UI. Manjaro is a pretty new kernel, much newer that Debian 11.6. Don't think that is maternal per se, as yet, but was a significant difference I noticed.

Wonder why Debian 11.6 did not hang but Debian 12 did? That might be an important clue.

[morrownr]

@ValdikSS @Jibun-no-Kage

When I get to this issue, I think I will test 88x2bu to see what happens. That might expand the hunt enough to help.

[morrownr]

@ValdikSS

You might want to join the conversation at:

morrownr/8821au-20210708#70

It seems related.

[morrownr]

@ValdikSS

I am still working the related issue of interface renaming and I found that the messy log is related to persistent interface names as I turned it off and everything is clean. Still working on that.

Back to the original issue here iw dev wlan0 del.

I need more info. Can I get you to give me a step by step list of exactly what commands you are using? I need to duplicate this.

A thought I had is that using iw ... del on a Realtek out-of-kernel driver would be very rare because they don't don't support adding another interface to the same adapter so why would del need to be used. Well, they support concurrent mode but that is a different animal.

Let me back up a minute. Something I noticed when I started this site around 3 years ago is people would show up posting problems using a guide that was built for in-kernel drivers expecting the Realtek driver to be able to do the same thing the in-kernel driver can do. That is not the way it is and here is why:

The in-kernel drivers such as the ar9271, rt5370, mt7610u, nt7612u and mt7921u are built using the mac80211 and stack capability per Linux Standards. Realtek and their out-of-kernel drivers are built to one degree or another on the old depreciated Wireless Extentions (WEXT) technology. I get asked on a regular basis why I don't submit the Realtek drivers here to the kernel maintainers to have it be in-kernel. Well, I can't because it would not be accepted because the Realtek drivers are based on old, depreciated technology. The submission would be denied. In fact, with WiFi 7, Realtek has no choice but to either drop Linux support or start doing the drivers in accordance with current standards as the old technology will no longer work with WiFi 7. Period.

We maintain these driver to help Linux users but if you look around, I push users to seek out adapters that use in-kernel drivers because they will operate in accordance with the guides that are posted in many places.

@morrownr

[ValdikSS]

Step-by-step list of the actions to reproduce:

1. Insert the adapter to the USB port
2. Execute iw dev wlan0 del as root, where wlan0 is the interface name.

The command would hang indefinitely.

[morrownr]

To get the iw docs, I did the following:

iw --help > iw.txt

Then I compressed it and attached it.

iw.txt.tar.gz

From the iw docs:

dev <devname> del
		Remove this virtual interface

So, we need a virtual interface. Your wlan0 is not a virtual interface. How do I know this?

Run:

iw list

Look for:

valid interface combinations

You won't find it. You will find:

interface combinations are not supported

None of the Realtek out-of-kernel drivers here or anywhere else support interface combinations.

I was able to duplicate your result and I must say that hanging the terminal is not a good thing but this has probably not come up because anyone working on iw probably knows not to use this command on a Realtek driver.

There is a reason that I put a statement in the docs encouraging Linux users to seek out adapters with in-kernel drivers. You have found one reason but there are many.

If, for example you get a Alfa ACM:

valid interface combinations:
* #{ IBSS } <= 1, #{ managed, AP, mesh point, P2P-client, P2P-GO } <= 2,
total <= 2, #channels <= 1, STA/AP BI must match

If you go to the USB-WiFi Main Menu:

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

You can select menu item 4 and get a list of many adapters and the capabilities. You have to pick out an adapter with the virtual interface capabilities you want because different drivers/chipsets mean different capabilities.

Sorry about not pointing this out right up front but I started to test and noticed the problem renaming an interface and I got focused on that... which is also a Realtek only problem.

I'm going to show this issue as can't fix.

@morrownr

[ValdikSS]

Just FYI, rtw88 mainline kernel driver (and its backport https://github.com/lwfinger/rtw88) is currently in a state which allows for 8811cu dongles to work properly in both 2.4 and 5 GHz, client/ap/monitor/injection mode without any serious issues.

[morrownr]

@ValdikSS

I've been testing rtw88 8812bu support with kernel 6.3 lately. It is coming along nicely. I'll test 8811cu starting soon. My hope is that support for both of those chipsets is in very good shape within maybe a year from now so that I can look at discontinuing support for this driver and the 88x2bu out-of-kernel drivers. That would give me more time to try to keep the older drivers supporting the 8812au and 8811au chipsets in good shape.

[bGN4]

I got the same problem on OpenWrt, the following script will call iw dev $wlan del when restart network service:
https://github.com/openwrt/openwrt/blob/openwrt-21.02/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh

[morrownr]

Hi @bGN4

I do not support OpenWRT with this driver in this repo. I do use OpenWRT. What I recommend OpenWRT users do if they want to use a usb wifi adapter is they use the adapters based on chipsets that are well supported in OpenWRT. That includes:

mt7921au
mt7612u
mt7610u

The Main Menu for this site includes a Plug and Play list that includes many adapters based on those chipsets:

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