[SOLVED] USB not authorized for WIFI stick

gotzl · 06-10-2020, 05:21 AM

Hello,

I'm moving from kernel 4.19 to 5.4 and I encounter an issue with a wifi stick.
While in 4.19, the respective kernel module gets loaded and the wifi stick is usable after boot, in 5.4, the device is 'not authorized' after boot, i.e.

Code:

# cat /sys/bus/usb/drivers/usb/1-3/authorized 
0

I don't understand why this is the case. Who is responsible of de-authorizing the device? I'm not able to see anything suspicious:

Code:

# dmesg | grep 1-3 
[    3.037295] usb 1-3: new high-speed USB device number 2 using xhci_hcd
[    3.050588] usb 1-3: New USB device found, idVendor=2357, idProduct=0106, bcdDevice= 0.00
[    3.051487] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    3.052378] usb 1-3: Product: 802.11ac NIC
[    3.053261] usb 1-3: Manufacturer: Realtek
[    3.054133] usb 1-3: SerialNumber: 123456

Also, this is the only usb device that gets de-authorized, all other devices are working.

I checked:
* authorized_default is 1
* interface_authorized_default is 1
* no udev rules are active for this port/device
* no usbguard is present

The wifi stick uses the rtl8812au driver which is compiled as module. The distribution in this case is Yocto which builds a custom, but very minimal image (Yocto 2.7 for kernel 4.19 and Yocto 3.1 for kernel 5.4).

I would appreciate any hint in any direction....

fatmac · 06-10-2020, 10:38 AM

I'd hazard a guess that the firmware hasn't been included in the later release.

Try lspci & lsmod on both versions, (&/or look in /lib/firmware).

gotzl · 06-10-2020, 12:17 PM

Hi, thanks for the idea. This brings to a point I forgot in my post

If I do

Quote:

echo 1 > /sys/bus/usb/drivers/usb/1-3/authorized

the module is loaded and the wlan device appears:

Quote:

# dmesg | grep 1-3
[ 7955.964580] usb 1-3: authorized to connect
[ 7956.104865] usb 1-3: 88XXau 50:3e:aa:db:76:05 hw_info[d8]
[ 7956.114346] 88XXau 1-3:1.0 wlp0s20f0u3: renamed from wlan0

So, no complaint about missing firmware...

jefro · 06-10-2020, 03:56 PM

Sounds like you are saying it is solved?

https://www.kernel.org/doc/Documenta...horization.txt for reference.

gotzl · 06-10-2020, 04:13 PM

@jefro No, my issue is not solved. I want to know, why the device is "not authorized" after booting the system. Sure, as a workaround I can authorize the device after boot by hand. But I would rather like to know, who deactivates it in the first place and why.

jefro · 06-10-2020, 06:44 PM

"Remove the lock down:

$ echo 1 > /sys/bus/usb/devices/usbX/authorized_default

By default, Wired USB devices are authorized by default to connect. Wireless USB hosts deauthorize by default all new connected devices (this is so because we need to do an authentication phase before authorizing). Writing “2” to the authorized_default attribute causes kernel to only authorize by default devices connected to internal USB ports."

https://www.kernel.org/doc/html/late...orization.html

I assume this will work. Since yocto is what it is there may need different way.

gotzl · 06-11-2020, 04:31 AM

Hi, thanks again for your reply.

As I stated in the first post, authorized_default is already '1'. To be super safe I've also added a commandline parameter 'usbcore.authorized_default=1', but that doesn't help.
The device is still 'not authorized' after boot.

As I side note, I'm also not sure if the WiFi stick falls into the 'Wireless USB hosts' category. I think, with this category, Wireless_USB devices that use the 'wusbcore' driver are meant.

jefro · 06-12-2020, 03:49 PM

I guess you can ask the Yocto team as to what they did. Changes published online may provide a clue.

gotzl · 06-16-2020, 02:49 PM

After some more investigation, I've realized that I forgot an active udev rule in the initrd. I use this rule to secure the USB port and only allow the specific driver.
This rule is triggered in early boot and in 5.4, it falsely 'de-authorizes' the device.

Code:

ACTION=="add", GOTO="device_check"
GOTO="rules_end"

LABEL="device_check"
KERNELS=="1-3:*", DRIVERS!="rtl88XXau", GOTO="disable_device"
GOTO="rules_end"

LABEL="disable_device"
RUN+="/bin/sh -c 'echo 0 >/sys$$DEVPATH/../authorized'"
LABEL="rules_end"

So, after all, the issue this thread is about comes from a udev rule going rogue

To investigate further I've now really disabled the rule and I've noticed a difference in timing between 4.19 and 5.4 kernels:

4.19

Code:

[    2.946083] usb 1-3: new high-speed USB device number 2 using xhci_hcd
...
[    7.869734] usb 1-3: 88XXau 50:3e:aa:db:76:05 hw_info[d8]
[    7.870226] usbcore: registered new interface driver 88XXau
[    7.917410] 88XXau 1-3:1.0 wlp0s20f0u3: renamed from wlan0

5.4

Code:

[    2.906153] usb 1-3: new high-speed USB device number 2 using xhci_hcd
...
[    4.777661] usb 1-3: 88XXau 50:3e:aa:db:76:05 hw_info[d8]
[    4.778029] usbcore: registered new interface driver rtl88XXau
[    4.782144] rtl88XXau 1-3:1.0 wlp0s20f0u3: renamed from wlan0

Notice the timing of the 'hw_info' line, which is ~3s earlier. Not sure why this is the case....
Anyways, because this seems to be related to the timing when the module gets loaded, I've compiled the driver into the kernel. Et voila, everything is fine, the udev rule doesn't 'de-authorize' my device anymore!

For me, this issue solved, even though I don't know the root-cause. Having the driver in-tree is a good solution for me in any case.

jefro · 06-16-2020, 03:28 PM

Thanks for the update.

"because this seems to be related to the timing when the module gets loaded, " This sort of usb issue used to happen a lot when we first got usb ports. I'd guess it is still going on.