wifi soft blocked by asus_nb_wmi on asus vivobook s14 oled Q423SA

[ian su]

asus_nb_wmi module is soft blocking the wifi and `rfkill unblock all` does not work. This is a duplicate of Bug #2089931 but reproduced with a supported kernel version. In addition to kernel 6.11.0-13, this bug also exist in the 6.12.5.

after unloading the the kernel module via

```
sudo modprobe -r asus_nb_wmi
```

the wifi works normally.

The laptop model is asus vivo book s14 q423 (https://www.asus.com/us/laptops/for-home/vivobook/asus-vivobook-s-14-q423/).

[ian su (iannnn)]

uname -a

[ian su (iannnn)]

lspci -nnk | grep -A3 Network

[ian su (iannnn)]

sudo journalctl -k -b

[ian su (iannnn)]

iw dev

[ian su (iannnn)]

rfkill list all

[ian su (iannnn)]

sudo lshw -C network

[ian su (iannnn)]

cat /etc/os-release

[ian su (iannnn)]

modinfo asus_nb_wmi

[ian su (iannnn)]

sudo dmidecode -t system

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Louie Torres (louie4825)]

Can reproduce with the same laptop model (S5406SA) on kernel 6.11.0-13 (Ubuntu 24.10).

Note that you can still connect to Wi-Fi networks by manually running `nmcli radio wifi on` and `nmcli dev wifi list`. NetworkManager will list and connect to Wi-Fi networks even despite the soft-block.

[Juerg Haefliger (juergh)]

6.11.0-13 is old. Can you reproduce this with 6.11.0-21.21 from oracular-proposed [1]? There are a few asus-wmi commits:

$ git log --oneline Ubuntu-6.11.0-13.14..Ubuntu-6.11.0-21.21 -- drivers/platform/x86/asus-wmi.*
555dad6852a3 platform/x86: asus-wmi: Ignore return value when writing thermal policy
b43c05c82756 platform/x86: asus-wmi: Fix inconsistent use of thermal policies
9f804e0832b1 platform/x86: asus-wmi: add support for vivobook fan profiles
3e7de2fbf2cd hid-asus: use hid for brightness control on keyboard
27535f436f92 platform/x86: asus-wmi: Fix thermal profile initialization

Also, has this worked correctly in the past?

Can you try the latest mainline kernel [2] to see if it works any better?

[1] https://wiki.ubuntu.com/Testing/EnableProposed
[2] https://kernel.ubuntu.com/mainline/v6.14-rc6/amd64/

[ian su (iannnn)]

Thank you for the reply. Sadly, my laptop currently runs fedora and I can't test new ubuntu kernel. The exact same problem does still exist with kernel 6.13.5 on fedora though, hope this info will help.

[Daniil Kirillov (danilk)]

Got the same behavior with v6.14-rc6

[bug reporter (bugreporter23)]

For what it's worth, I did some digging into the linux kernel source; I don't know how to compile a kernel properly yet though haha so actual scientific debugging will be a bit ways away.

(All code is for kernel 6.13.7)

But basically in asus-wmi.c:2036 you see these lines in `asus_rfkill_set`

```
if ((dev_id == ASUS_WMI_DEVID_WLAN) &&
     priv->asus->driver->wlan_ctrl_by_user)
    dev_id = ASUS_WMI_DEVID_WLAN_LED;
```

Huh???? So the wifi switch is implicitly dependent on reading a wifi WLAN LED? But what if your laptop doesn't have it?

For me, when asus_nb_wmi is enabled, even sudo rfkill unblock all doesn't undo the softblock. I think this explains why - the messages are being silently redirected then cast into the void.

ALL DISCLAIMERS: I know 0 actual hardware knowledge. The maintainers did this for a reason back then, and I don't know why - I'll try my best to learn more about it but it'll be quite some time.

NOR have I confirmed that a debug message is generated (e.g. that this is ACTUALLY the bug) - I think for example, in asus_wmi.c:340 there should be an ACPI failure because you try to write to WLAN_LED when it doesn't exist.

---

In the meantime, a good way to test this theory less rigorously is:

- Can you successfully load asus_nb_wmi and asus_wmi modules? If YES:

- your laptop SHOULD have a wifi soft kill switch
- your wifi switch HAS any kind of LED indicator $IFF$ [your wifi works, and something like `sudo rfkill unblock all` actually fixes the wifi]

Both of these conditions must hold true for my theory to be true. Otherwise my theory is wrong.

-----

This could be complete fanfiction, since I didn't actually, well, run the kernel in debug mode and verify that yes, asus_wmi.c:340 is throwing errors because you're trying to write to WLAN_LED when it doesn't exist. But I'm just throwing out ideas, hopefully getting the ball moving on this issue. It really is bugging me that I have to reload and unload the module every time I want to change my backlight at night, for example.

For anyone else coming in to this thread and reporting this issue, I think it would be helpful to go through this theory and report back results on your own, and try to prove/disprove it. Specifically go through each part of the flowchart (it's 3 if statements!) and determine whether or not the theory was disproven.

----

And I would like to clarify that this is NOT a wifi driver issue. Across ubuntu, NixOS, and Arch, wifi drivers (even for wifi 7) worked perfectly for me. The ONLY thing I had to change was remove the asus_nb_wmi module, and from there, wifi worked.

However, rfkill unblock all, unblocks everything, inclduing the physical phy0 lan, but NOT the asus_wlan. I think this may be why - the silent redirection.

----

Assuming my theory is correct, an alternative to digging in and getting rid of the implicit WLAN_LED behavior would be to somehow set all the default inits to "false" for wifi and bluetooth, despite the BIOS's protests. Currently, if you load in asus_nb_wmi, everything becomes softblocked (at least for me) - I don't know if it's realistic or possible, but if everything were not default softblocked.... then, a messed ...

[bug reporter (bugreporter23)]

I learned how to enable kernel debug flags, this is my result in dmesg when I specifically run

`sudo rfkill unblock [target_rfkill_id]`, where the target id is "asus_wlan" on my laptop.

------

[32267.286227] asus_wmi: asus_wmi_evaluate_method3 called (0x53545344) with args: 0x00010011, 0x00000000, 0x00000000
[32267.286245] asus_wmi: Result: 0x00050000
[32267.287502] asus_wmi: asus_wmi_evaluate_method3 called (0x53564544) with args: 0x00010012, 0x00000001, 0x00000000
[32267.287508] asus_wmi: Result: 0xfffffffe
[32267.287511] asus_wmi: asus_wmi_evaluate_method3, (0x53564544), arg 0x00010012 failed: -19

These debug messages come from asus-wmi.c:340.

Furthermore, the idiom for all rfkill messages (bluetooth, phy0, etc) appears to generate two ACPI-BIOS communication messages:

Send some kind of preliminary [0x53545344] call, get back 0x00050000 (presumably OK). This appears to be some kind of status check? I don't know hardware and it appears to be proprietary, I can't find information online about this, but this is how every other function worked.

Then, do the *actual* set call, e.g. [0x53564544]. Which fails per the silent misdirection, as noted.

I have an Asus Vivobook S14 WUXGA OLED 1TB SSD 32GB RAM, should be one of the first results on google atm. I do not have a WLAN LED on my laptop anywhere.

This happens on kernel version 6.13.7 for Arch. Haven't tested on ubuntu or NixOS, but fairly certain this is reproducible.

---

Again, there's plenty of comments in the kernel source saying that they needed to do this WLAN setting workaround, so there must be *a* reason for this, but I'm more confident now that this is the bug. Again, don't know hardware, so I don't know the fix, as I don't know the original reason for the hackaround. And it seems like all of this documentation is proprietary? I have no idea how people reverse-engineered this before.

[Louie Torres (louie4825)]

Linking the related Bugzilla report on the Kernel bug tracker: https://bugzilla.kernel.org/show_bug.cgi?id=219786

Could you please comment on there? Might help kernel devs to fix the issue.

Note: I also don't really know much about kernel development and also tried digging into the code to see what was wrong. I couldn't figure it out either.

[Ilkhan (rilkhan)]

Same bug on Asus Vivobook S16 (S5606CA)

Ubuntu 24.04.2 LTS
6.14.0-061400-generic

[Louie Torres (louie4825)]

A patch has been posted upstream by Hans de Goede: https://lore<email address hidden>/

This fixes the bug for me, but more testing is needed to make sure it doesn't break anything. Please report issues to the Bugzilla issue tracker linked above.

[ian su (iannnn)]

Tested on fedora 42, yes! this patch works.

[ian su (iannnn)]

For everyone encountering this bug, the kernel patch is included in 6.15. This issue should be fixed once ubuntu update their kernel.

[Juerg Haefliger (juergh)]

This patch is in upstream v6.14.8 and should reach plucky soon.