Librem 14, wireless kill switch, sys-net problem due to missing device

Hello everyone and good evening to you!

I’m wondering how to deal with a problem I have encountered. When I disable my Atheros wireless device via the hardware kill switch, I need to remove it from sys-net or it won’t start. Vice versa when I want to use it again.

I commonly switch between wireless via the kill switch and wish to avoid the manual fix of adding and removing the device upon usage needs. Any ideas? Worst case I guess I’ll keep doing the add/removal of the Atheros device in sys-net manually…


1 Like

I’m not sure exactly what your workflow is, so I will suggest a number of things, some of which might strike you as relevant. I’m hoping something here will give you ideas; please do not just blindly do as I suggest. I’ve left out a lot of details (including how to do things on the command line). I’m assuming you know how to do bash scripts.

You could, instead of directly issuing the start-vm command for sys-net, create a script that checks to ensure the device exists, and only then starts it.

If the issue is happening during bootup because sys-net tries to start, you can switch off “Start qube automatically on boot.” (You will want to do the same for sys-firewall.) On logging in you will want to run a script that starts sys-net (but only if the device isn’t killed) and then sys-firewall.

Unfortunately that won’t guard against some qube that has networking set to sys-firewall, firing up sys-firewall, which then fires up sys-net. Perhaps you could set things up so that when the wifi device isn’t there, sys-firewall’s net qube is set to none. (There’s a qvm-prefs command line to do that.) That’s perfectly allowable, even while sys-firewall is running. VMs using sys-firewall won’t be able to communicate with the internet, but that’s the whole idea, isn’t it?

As I am thinking about this, I could see a combination being used.

  1. Disable start qube automatically on boot for both sys-net and sys-firewall. (This is a one time thing).

  2. Create a script that checks to see if there is a wifi device. If there is no device, ensure sys-firewall’s network VM is set to none, and start sys-firewall. If there is a device, ensure sys-firewall’s network VM is set to sys-net, and make sure sys-net has the device assigned to it.

  3. Put that script in .config/autostart-scripts.

Those three steps should have two effects: 1) sys-firewall and sys-net will NOT start on boot but will wait for you to log in (this will shorten boot time). 2) When you do log in, you’ll either have sys-net and sys-firewall ready to access the internet through the device (if it’s not killed) or sys-firewall will be a dead end with no internet (if the device is killed).

If you flip the switch while the system is on (and I have a librem13 so I know you can do that), you can mitigate the pain by writing a “flip off” script that resets sys-firewall’s netvm to none and shuts down sys-net, and a “flip on” script that ensures the device is assigned, then turns on sys-net, and sets sys-firewall’s networkvm to sys-net. Run “flip-off” before flipping the kill switch to off, and run “flip on” after flipping the kill switch to on. It won’t be perfectly automatic BUT typing one script name is a lot faster than the manual process you’re alluding to.

The irony is that even though I actually do have a Librem13, I’ve never run into this issue, because I’ve not used the wifi kill switch since I installed Qubes on it.

So now I have something on my to-do list!



I had not thought of this method of managing the password on a disposable. It seems much more secure than what I am doing now.