QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
526 stars 46 forks source link

Qubes loses network access on restart of `sys-net` #9313

Open GWeck opened 3 weeks ago

GWeck commented 3 weeks ago

Qubes OS release

R4.2.1

Brief summary

Whenever sys-net is restarted, network access via WiFi or ethernet cable is no longer possible.

Steps to reproduce

Restart sys-net via Qube Manager or CLI and try to establish a network connection.

Expected behavior

The previously enabled network devices should work again after sys-net has completed its startup.

Actual behavior

After restarting sys-net, for WiFi, a message is shown that the connection is established, but no access to other networks is possible. For Ethernet cable, the icon in the panel shows a red circulating dot. Both types of interfaces cannot be started manually, and any attempt to connect to an external node, like ping from a sys-net terminal will fail, possibly with a message like Network not available.

Booting Qubes restores network access.

This happens for sys-net based on Fedora-39, Fedora-40, and Debian-12. So it seems that this is not a bug in sys-net itself, but possibly in dom0 or the communication with dom0.

journalctl does not show any errors in sys-net or dom0.

This effect is specific to Qubes R4.2.1. Under Qubes R4.1.2, sys-net can be restarted without problems on the same machine. Both are running kernel 6.9.4.

drivingreturns commented 3 weeks ago

On Qubes R4.2.1, Fedora-40-xfce, and kernel 6.9.2, with wifi only, I can't reproduce this.

sys-net often loses connectivity after suspend, but restarting the qube restores it.

alimirjamali commented 3 weeks ago

On Qubes R4.2.1, Fedora-40-xfce, and kernel 6.9.2, with wifi only, I can't reproduce this.

sys-net often loses connectivity after suspend, but restarting the qube restores it.

@marmarek The above would justify the additional OpenQA unit test I suggested here in last paragraph.

GWeck commented 3 weeks ago

For me, after suspending and restarting Qubes, the network is still running. So this seems to be something different.

GWeck commented 3 weeks ago

This seems to be a hardware-dependent issue, because the effect occurs on an HP Elitebook, but not on other hardware - but why does it occur in Qubes R4.2.1 and not in R4.1.2?

apparatius commented 3 weeks ago

Do you have the same PCI attach options in Qubes OS 4.1 and 4.2? Maybe you have no-strict-reset and/or permissive option/s set only in one system?

Did network work in sys-net after restart in Qubes OS 4.2 before on this machine? Or is it a first time that you've installed Qubes OS 4.2 on this machine (or tried restarting sys-net)? You can also try to use the same kernel in Qubes OS 4.2 that you have in Qubes OS 4.1. Maybe it's an issue with latest kernel.

GWeck commented 3 weeks ago

The PCI attach options in both R4.1 and R4.2 are identical. On top of that, setting or unsetting the no-strict-reset option causes no change in the behavior in both versions.

I have been running the test installation of R4.2 for some time, but, unfortunately, I have never tried to restart sys-net previously.

Both systems are running with the same kernel 6.9.4, but going back to an earlier kernel, e.g. 6.6.25, does not change the situation.

apparatius commented 3 weeks ago

Did you check /var/log/xen/console/guest-sys-net-dm.log in dom0? Maybe there will be some info.

andrewdavidwong commented 3 weeks ago

@alimirjamali:

The above would justify the additional OpenQA unit test I suggested here in last paragraph.

I suggest opening a separate issue for adding such tests.

GWeck commented 3 weeks ago

I did not find anything suspicious in /var/log/xen/console/guest-sys-net-dm.log. The logs for both the working and the faulty start look the same, without any serious error.