Good afternoon, AndyM48

Which distro are you using at the moment? Does `rfkill` show that the interface is hard blocked? or by hard block you mean that the interface disappears randomly?

With `evtest` you can check if the QC71 driver is sending the RFKILL event to see if it detects anything when pressing that key

Regards,

I have a choice, openbox, kde or xfce4, all installed fresh

RFkill shows wifi hard blocked

evtest shows nothing for Fn4

Supported events:

Even code 228 (KEY_KBDILLUMTOGGLE)

229 KBDILLUMDOWN

230 KBDILLUMUP

240 UNKNOWN

247 RFKILL

465 FN_ESC

467 FN_F2

470 FN_F5

477 FN_12

Andrew

Hey, Andrew
Those are all desktop environments, I wanted to know which Linux distributions you are using at the moment
In any case, if its shown as hard blocked, you can check the BIOS to see if the Wi-Fi toggle is on disabled, that will hard block or enable the Wi-Fi

Fn+F4 should send the event properly after disabling the hard block

Regards,

I am getting a bit fed up with this. I could not post a question to technical support because it said "

Oops! Something went wrong.

Take a look at the error message below."

and yes, there is no error message.

So I composed a detailed reply on the brand spanking new Slimbook, and it said "You have been blocked" or words to that effect. So I reloaded the tab and it said "405 Method not allowed".

Thank you

I will try again from the Slimbook, hoping the wifi stays up long enough

 Linux slimbook 6.18.13-artix1-1 #1 SMP PREEMPT_DYNAMIC Thu, 26 Feb 2026 15:16:00 +0000 x86_64 GNU/Linux

which is Arch linux without systemd

The BIOS shows wifi Enabled

Fn4 does nothing whether wifi is blocked or unblocked

$ lsmod | grep qc71
qc71_laptop            65536  0

Slimbook service shows System Information and Preferences greyed out at the moment, they were available before?

Andrew

Is Fn4 supposed to soft or hard block the wifi?

Hell, Andy
Fn+F4 does block the interface via software, not by hardware, so there might be another issue happening

Have you tried in a Live environment to see if the Wi-Fi does work? I suggest trying and checking
If it doesn't, you could try contacting our support team (at https://slimbook.com/en/support) to see if they can help

For what is worth, Cloudfare blocks anything that could potentially be a security issue, so sending anything that can contain commands (eg, curl, wget, cat ....) might make Cloudfare block your message

Regards,

As shown in my rant above, I received an error trying to open a ticket at https://slimbook.com/en/support

I will try from live media and let you know. Since the block is random, I can only check if evtest gives me a different result.

I see that there is a new version of EC out, so I will update that as well.

Hi, I have a similar issue, with my new Executive 14.

In my case the wifi appears hardware locked always after resume from a deep sleep...

# rfkill list
0: hci0: Bluetooth
       Soft blocked: no
       Hard blocked: no
1: phy0: Wireless LAN
       Soft blocked: no
       Hard blocked: yes

The only way to recover the wifi is rebooting the system.

Pressing FN + F4 don't do nothing. Either after a resume from a sleep or normal boot.

I'm using the latest Slimbook OS KDE.

Alex from Slimbook mentioned that I shouldn't pasting anything directly into the text while opening a ticket, otherwise submitting would be blocked by Cloudfare. Typing all the information by hand was a pain but resulted in me being able to open a support ticket. 

@marc Yes, same as me. The problem is with the wifi modules failing to restart after suspend. You can see the errors in dmesg (or may be journalctl if you use systemd). I think the solution is to disable wifi before suspending and enable it after. I haven't tested this fully, but it seems to work.

add "sudo nmcli radio wifi off" to the commands to execute pre sleep and "sudo nmcli radio wifi on" post sleep.

@mmaeschba Good luck with that. Tech Support simply refused to help with the wifi problem. You best bet is to ask her I think.