Inconsistent network connection after upgrading systemd to v250

[ejose19]

Qubes OS release

R4.1

Brief summary

Upon updating to systemd v250 (on archlinux template), I notice that launching any appVM randomly ends up with a broken network, upon inspecting the interfaces with ip a I noticed the following the interface name changed from eth0 to enX0:

enX0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff

On systemd changelog I see some point of interest:

* The predictable naming logic for network interfaces has been extended
      to generate stable names from Xen netfront device information.

Steps to reproduce

• Update systemd to v250 on a template that has the package available
• notice how the network connection is broken on some starts

Expected behavior

Network should work without issues on all launches

Actual behavior

Network connection only work on random starts

Additional info

With the connection working only on some starts, this points to a race condition somewhere.

AppVM logs while changing NetVM from none to sys-firewall

kernel: xen_netfront: backend supports XDP headroom
systemd-udevd[827]: Using default interface naming scheme 'v250'.
kernel: vif vif-0 enX0: renamed from eth0
systemd-udevd[831]: Using default interface naming scheme 'v250'.

while in sys-firewall I see this:

systemd-udevd[5839]: Using default interface naming scheme 'v247'.
systemd-udevd[5839]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
kernel: vif vif-44-0 vif44.0: Guest Rx ready
root[5855]: /etc/xen/scripts/vif-route-qubes: online type_if=vif XENBUS_PATH=backend/vif/44/0
root[5888]: /etc/xen/scripts/vif-route-qubes: Successful vif-route-qubes online for vif44.0.
root[5889]: /etc/xen/scripts/vif-route-qubes: Writing backend/vif/44/0/hotplug-status connected to xenstore.

Upon inspecting that called script, I see this diagram

https://github.com/QubesOS/qubes-core-agent-linux/blob/dfc7104055a60346515ad5940ed5257bf5db132a/network/vif-qubes-nat.sh#L12-L27

#
#               .----------------------------------.
#               |          NetVM/ProxyVM           |
# .------------.|.------------------.              |
# |   AppVM    ||| $netns namespace |              |
# |            |||                  |              |
# |  eth0<--------->$netns_appvm_if |              |
# |$appvm_ip   |||   $appvm_gw_ip   |              |
# |$appvm_gw_ip|||         ^        |              |
# '------------'||         |NAT     |              |
#               ||         v        |              |
#               ||  $netns_netvm_if<--->$netvm_if  |
#               ||     $netvm_ip    |  $netvm_gw_ip|
#               |'------------------'              |
#               '----------------------------------'
#

which may hint that eth0 is hardcoded somewhere and would need to change to a dynamic value

Temporary workaround

Reverting to the old eth0 makes network work consistently again, as stated in arch wiki

# ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules

[na--]

This seems like a duplicate of #7284?

[ejose19]

@na-- Indeed it is, thanks