Sys-net not not searching for wifi network or connecting after being disconnected

Hey I am having an issue with sys-net that I have had for a few months now. sys-net disconnects from the network properly but when i try reconnecting to the network after some hrs sys-net fails to search for WiFi networks or connect to the network previously used.

I find my self having to kill sys-net and starting it again and reconnect to the network again. This is not very convenient. Can anyone help with this?

Did you try to use another template for your sys-net? For instance, Debian instead of Fedora?

Yes, sys-net is a disposable based on Debian 11. I would prefer for it to be persistent but i haven’t changed it yet.

How did you get sys-net to connect to wifi in the first place, if you’re using a disposable?

I’m having to actually open a terminal on sys-net and issue a command (nmcli with a bunch of parameters, including the wifi password) to get it to connect. As near as I can tell this is because, although normally wifi remembers its networks from one boot to the next, a disposable won’t remember that.

(I’ve tried putting the command into system-d as a startup service, but apparently that runs too early [i.e., before the wifi controller is running] to do any good. My next attempt will be to alter that startup service file to loop until success, then exit.)

It’s not even displaying the popup asking for my password, because the disposable doesn’t remember from one startup to the next that it’s supposed to try to connect to that network.

well i connect sys-net initially to the network i choose first. sys-net should retain the password until the vm is actually shut down, When i close my PC or disconnect from the WiFi, it fails to start WiFi/ connect to WiFi automatically when i reopen my laptop again.

Thanks…I was hoping you had something slicker than having to log into the wifi every time. On another thread there was a discussion about how to do that. After reboot wifi password forgotten - #17 by Sven

Thanks but this still doesn’t solve my problem. I still have the problem of having to kill sys-net and start it again after opening my laptop.

I have the same problem after waking up from suspend, but not every time (I’m using Fedora). It was flawless on R4.0.

Known issue related to fedora increasingly requiring more RAM and issues that would be shown under sys-net by keeping a scrolling system journal before the issue happens sudo journalctl -f to see logs when you loose network (and hopefully push devs to increase the sys-net/sys-usb default of assigned memory). Was reported in different threads for sys-usb (camera disconnection, usb proxy failing, etc) and sys-net (after resume of suspend, on high network throughput etc).

You could either assign more memory to those HVMs (no memory ballooning for sys-* machines), try to tune systemctl there, rely on a minimal template, switch to debian… But the simplest is to assign more memory to the faulty sys-net/sys-usb:

1 Like

I would recommend starting your qubes session by opening a shell on sys-net and calling sudo journalctl -f. It might be a faulty driver causing it to oops the kernel, amongst other things. Depending of the network card used, there might be a lot of kernel modules dependencies, and maybe one of them is having a memory leak.

The symptom you express seems to be the consequence of a kernel driver being faulty, but it might as well be something killed by kernel memory manager, kicking out a process that consumed too much memory. Best is to see what is happening when you loose networking from sys-net perspective and go from there. My previous posts were related to fedora and its ever increasing memory cost at each release, having consequences. But as well, the size of applications that are running by default. Debian is normally more lightweight.

What is your hardware? Network card and sys-net memory assignment information would be a start, with journal trace around the moment of disconnection to know what is actually happening.

See also:

I’m using a privacy beast from insurgo.ca. I am also already using Debian as my default Disposable.

Clean install of Qubes 4.1.1 will require you to change memory assignment of sys-net yourself.

If you experience loss of networking, I recommended changing the default memory assignment to something around 500Mb.

Repeating:

The default will not be changed upstream. Some services might be deactivated by default later on, as discussed in referred issue in previous post in thread (Fedora related, while discussions are relevant to other service qubes as well).

Where important traces for troubleshooting of issues would still be the same and important to others as well:

I cannot replicate the issue on my side: Fedora-36-dvm based sys-net with 500Mb assigned.
Of course, you have to shut down sys-net first (dom0: qvm-shutdown --force --wait sys-net)
Open sys-net Settings, Advanced tab and set Initial memory to 500mb:


Apply, OK. And then start sys-net again.
(dom0: qvm-start sys-net will do, or starting a new qube will also start sys-net as well as part of its startup.)

Fun fact: it is now possible to change the memory allocation (dunno since when) while sys-net is running.

Note that HVMs cannot have memory allocation dynamically changed, so the new setting will be applied on reboot of sys-net, even though nothing currently warns the user that those new settings are not currently applied.

Still have the same issue after allocating the memory to sys-net.
Ill check the log in an hr to see what happened.

  1. Connect to network on freshly started sys-net
  2. Open terminal on sys-net
  3. sudo journalctl -f
  4. Ctrl-c that command on terminal when you suffer disconnection.
  5. Scroll up for errors, warnings, kernel messages
  6. Share that pertinent information

You can as well search for logs after the issue happened, but it requires digging then…

Increasing Memory to 500 did the job. Thanks for the help!

1 Like