Bug 219786

Happens to me with the same laptop model (S5406SA) on kernel 6.13.x (Fedora 41).

Corresponding launchpad thread [here](https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2092283). 

I believe this is an issue of implicitly relying on a WLAN_LED existing. For example, in asus-wmi.c:2036 you see

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

in the function 'asus_rfkill_set'. 

This means that the init setup did detect that the user can control wifi. However, it assumes that if you can control WiFi, you have a WiFi LED indicator for whether the wifi is on or off, which may not be the case on every laptop. 

(For me, it appears that I can control bluetooth and nothing else? My Fn + f8 key, the happy face, only toggles bluetooth and only sends bluetooth toggle messages on dmesg, it does not send any wifi toggle messages, not even wifi toggle failure messages, as shown below. So one potential issue may be that the hardware is saying, "yes you can control the wifi" even when it's really only bluetooth.)

This has the consequence that... if you don't have an LED light, well, then all messages that go through rfkill silently fail. 

My kernel was compiled with dynamic debug messages, and when I enabled them this was my dmesg output after

- enabling asus_wmi and asus_nb_wmi
- enabling debug mode on each of these by sending `module [x] +p` to the kernel debug log
- `sudo rfkill unblock all` and verifying that all but `asus_wlan` were all unblocked, while `asus_wlan` was softblocked
- *target unblocking the rfkill id* of `asus_wlan`

---

[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.

----

If you look at the structure of how `rfkill unblock` invokes kernel functions, it always seems to follow a pattern of:

Invoke the ACPI hardware function(?) 0x53545344, get back 0x00050000 (presumably some kind of OK signal) 

Invoke the ACPI hardware function(?) 0x53564544, which returns 0 on success, and otherwise, in my case, a method-unsupported error code. 

----

For reference, a normal bluetooth invocation looks like 

[35520.424711] asus_wmi: asus_wmi_evaluate_method3 called (0x53545344) with args: 0x00010013, 0x00000000, 0x00000000
[35520.424726] asus_wmi: Result: 0x00050000
[35520.425121] asus_wmi: asus_wmi_evaluate_method3 called (0x53564544) with args: 0x00010013, 0x00000000, 0x00000000
[35520.425126] asus_wmi: Result: 0x00000000

---

Notice that: 

- the structure is the same (send preliminary message, then send actual update) 
- Bluetooth invokes 0x00010013 both times, whereas the WLAN case *does* silently redirect to WLAN_LED. 
- WLAN_LED is not supported (on my machine), thus, the message fails (0xfffffffe is explicitly documented in include/.../asus-wmi.h as "Unsupported Message"). 

---

This was tested on Arch Linux 6.13.7. I have a Asus Vivobook S14 WUXGA OLED 1TB SSD 32GB RAM. 

The TL;DR is that the kernel uses a LED light to detect WLAN on/off issues, but if your device doesn't have a LED light you're SOL. I think. I believe from a software perspective this is pretty rigorous, but this anaylsis starts to depend on real hardware which I know nothing about.

It appears that the kernel developers WERE aware that this behavior was hacky; see asus-wmi.c:2044

```
	/*
	 * If the user bit is set, BIOS can't set and record the wlan status,
	 * it will report the value read from id ASUS_WMI_DEVID_WLAN_LED
	 * while we query the wlan status through WMI(ASUS_WMI_DEVID_WLAN).
	 * So, we have to record wlan status in id ASUS_WMI_DEVID_WLAN_LED
	 * while setting the wlan status through WMI.
	 * This is also the behavior that windows app will do.
	 */
```

So the workaround does not seem easy. I do notice that upon re-enablement of `asus_wmi` or `asus_nb_wmi`, *every device gets soft blocked*, so the default state appears to be just softblock everything. If there were a way to specify what are the default states of these options... it would be nice to start everything off as not softblocked, even when you load in the kernel module. 

In that case, even if you can't toggle the wifi, the default state is that you're not softblocked. Which is optimal for like 99.99% of use cases.

(In reply to lbtowers from comment #0)
> However, after trying to unblock it, NetworkManager can now scan for and
> connect to Wi-Fi networks, even with the rfkill soft-block. But GUIs (e.g.
> GNOME and KDE panels) still show the Wi-Fi as "disabled".
> 
> It's a weird situation: Wi-Fi is soft-blocked but I can still use the Wi-Fi
> chip as if it were not. Disabling asus_wmi fixes this soft-block issue.

Really? `nmcli device wifi list` does not scan any wifi networks when asus-wmi is a loaded module, even after running `sudo rfkill unblock all` and reaching your state (e.g. only asus-wlan is soft blocked). I also tried running a direct connect command, no luck. 

I'm on a Core Ultra 7 Lunar Lake 258V w/ a be201d2w wifi card which seems like what you have as well. I don't think it's a wifi card issue though, since disabling that module means wifi runs fine...

I have heard success stories of using `iw` to connect directly despite asus_wmi, which makes sense since phy0 isn't blocked at all, I'd imagine it interfaces with that directly somehow.

(In reply to bugreporter23 from comment #3)
> (In reply to lbtowers from comment #0)
> > However, after trying to unblock it, NetworkManager can now scan for and
> > connect to Wi-Fi networks, even with the rfkill soft-block. But GUIs (e.g.
> > GNOME and KDE panels) still show the Wi-Fi as "disabled".
> > 
> > It's a weird situation: Wi-Fi is soft-blocked but I can still use the Wi-Fi
> > chip as if it were not. Disabling asus_wmi fixes this soft-block issue.
> 
> Really? `nmcli device wifi list` does not scan any wifi networks when
> asus-wmi is a loaded module, even after running `sudo rfkill unblock all`
> and reaching your state (e.g. only asus-wlan is soft blocked). I also tried
> running a direct connect command, no luck. 
> 

I probably should have clarified that I ran `nmcli radio wifi on`, and then Wi-Fi started working, even if the asus-wlan soft-block still exists. `nmcli device wifi list` works after doing this.

`sudo rfkill unblock all` doesn't allow the Wi-Fi card to work, but `nmcli radio wifi on` does.

Interesting, that works for me lol. Nice find, that sort of kills my motivation to hunt for this bug more, typing a simple command in terminal on boot in exchange for having my fn keys back is something I'll gladly take (for now :P).

As a control test, I tried this: 

`nmcli radio wifi on && rfkill unblock all` without asus_nb_wmi loaded, just to make sure that all state is correct; I can verify that all states are unblocked via

`rfkill list` and `nmcli radio`

Then, `sudo modprobe asus_{nb}_wmi`. Now everything in rfkill list is blocked, and in `nmcli radio`, I see WIFI is disabled.

When I run `nmcli radio wifi on` immidiately after this, in `rfkill list`, phy0 is now un-soft-blocked, and as you stated I can connect to the internet now. As you note, `nmcli radio` still shows WIFI as disabled... I assume it's reading the state of `asus_wlan` but writing straight to the wifi card or something?

---

Next steps might be: 

- enable kernel debug messages for `asus-wmi` and see what messages (if any) are triggered on "nmcli radio wifi on/off"
- digging through NetworkManager source code to see what messages it's sending 

----

Still think a maintainer's input / documentation on what BIOS opcodes are what for typical asus motherboards here would be immensely helpful (I'm not sure if it's proprietary info or not? It seems like it is since I can't find anything online), but this does open a few more avenues for debugging for the average user.

This is also an issue for me.  Yes, I can connect, but every time the computer is started or comes back from hibernation I have to go through and re-enable the interface, and it still shows as Wi-Fi disabled.

Summary:
asus_nb_wmi exposes an invalid rfkill device (asus-wlan) that is always soft-blocked on boot, causing Wi-Fi to appear disabled in UI despite working via iwlwifi

Description:
On an Asus Vivobook S14 with Intel BE201 Wi-Fi, the kernel loads asus_nb_wmi, which creates an additional rfkill interface labeled asus-wlan.
This device is soft-blocked at boot and does not reflect the state of the actual Wi-Fi device (phy0 using iwlwifi).
Even when phy0 is up and connected, asus-wlan remains soft-blocked, which leads to incorrect Wi-Fi status being shown in GNOME and KDE.
Unblocking it manually or blacklisting asus_nb_wmi resolves the confusion.

This appears to be a redundant or broken ACPI/rfkill interface being exposed by the Asus WMI driver on newer hardware.

System Info:

Laptop: Asus Vivobook S14 (model: S5406SA)
Kernel: Linux CRLLWKS1 6.14.4-300.fc42.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Apr 25 15:43:38 UTC 2025 x86_64 GNU/Linux
Distro: Fedora 42 / Ubuntu 25.04
Wi-Fi chipset: Intel BE201 320MHz [8086:a840]
Platform driver: asus_nb_wmi
rfkill list output:

1: asus-wlan: Wireless LAN
    Soft blocked: yes
    Hard blocked: no
3: phy0: Wireless LAN
    Soft blocked: no
    Hard blocked: no

Expected behavior:
The asus-wlan rfkill device should either reflect actual radio state, or not be exposed if non-functional.

bugreporter23 thank you for your work on debugging this.

I think that I know what the problem is, let me write and attach a patch which should fix this.

Created attachment 308064 [details]
[PATCH] platform/x86: asus-wmi: Fix wlan_ctrl_by_user detection

I think this patch should fix things.

If you are seeing this problem, please give this patch a try. See your distributions documentation for how to build a local kernel with a patch applied.

Created attachment 308065 [details]
[PATCH] platform/x86: asus-wmi: Fix wlan_ctrl_by_user detection

New version of the patch which I hope will fix things. Note only the commit message has changed, if you've already started a build with the old patch that is fine. I just wanted to make sure that anyone reading the commit message, for an explanation of the fix, will be reading the fixed version.

If you are seeing this problem, please give this patch a try. See your distributions documentation for how to build a local kernel with a patch applied.

bugreporter23 in case your wondering, this part of your logs:

[32267.286227] asus_wmi: asus_wmi_evaluate_method3 called (0x53545344) with args: 0x00010011, 0x00000000, 0x00000000
[32267.286245] asus_wmi: Result: 0x00050000

Shows that a get status (0x53545344) on the wlan-devid (0x00010011) returns 0x00050000 since 0x00050000 has ASUS_WMI_DSTS_BIOS_BIT (0x00040000) set and more importantly, does not have ASUS_WMI_DSTS_USER_BIT (0x00020000) set, the device-set (0x53564544) call should also be done on the wlan-devid (0x00010011).

But the logs show that instead this is being done on the wlan-led-devid (0x00010012):

[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

The use of the wlan-led-devid instead of the wlan-devid is caused by wlan_ctrl_by_user wrongly getting set when the get status call returns 0x00050000 and that is what my patch fixes.

Just built a new kernel (6.14.4-arch1-2) with the patch. Seems to indeed have fixed the issue:

❯ rfkill
ID TYPE      DEVICE              SOFT      HARD
 0 wlan      asus-wlan      unblocked unblocked
 1 bluetooth asus-bluetooth unblocked unblocked
 2 bluetooth hci0           unblocked unblocked
 3 wlan      phy0           unblocked unblocked

I'm not sure if this is solely due to this patch, but Wi-Fi also seems to automatically be re-enabled after resuming from suspend. I'll have to test this on a clean install some other time.

I had been mucking around the asus-wmi code for a while but couldn't figure out what was going on such that asus-wlan was being soft-blocked. Turns out it was an issue I had no hope of understanding, way out of my scope of knowledge.

Thank you so much for the fix!

Thank you so much as well, bugreporter23, sorry I couldn't help much further with debugging, though, lol.

Thank you for testing the patch so quickly

I've posted the patch upstream now:

https://lore.kernel.org/platform-driver-x86/20250501131702.103360-1-hdegoede@redhat.com/

Thank you for the patch, this is a great improvement.

Providing feedback -

With this patch, the Wi-Fi comes up automatically (great!).

The only quirk I can notice is that when I'm connected to a network, if I toggle off Wi-Fi, it shows toggled on once again, and I have to toggle it off twice to have it remain off. I would expect it would only have to be toggled off once, but this does not hinder usability.  If I'm not connected to a network, I can toggle it off once and it toggles off normally.

Toggling Wi-Fi on works as expected.

I am happy to provide additional/debug information if you need it.

Thank you for this patch!

> The only quirk I can notice is that when I'm connected to a network, if I
> toggle off Wi-Fi, it shows toggled on once again, and I have to toggle it off
> twice to have it remain off.

Are you running GNOME? I don't get this behavior on KDE. Toggling off Wi-Fi immediately reflects the changes and disconnects me from the current network, and the same goes for toggling it on.

The behavior is the same regardless of whether I am connected to a network.

Interesting. Yes, that was in GNOME.  I switched to KDE and all works well.

Thanks for the patch and the quick feedback. Works great.

Tested on fedora 42, everything works beautifully. Thank you soooo much! By the way I didn't experience the toggle wifi bug on gnome, everything function normally.