core-agent-linux/network/udev-qubes-network.rules

# old udev has ENV{ID_NET_DRIVER}
SUBSYSTEMS=="xen", KERNEL=="eth*", ACTION=="add", ENV{ID_NET_DRIVER}=="vif", ENV{SYSTEMD_WANTS}+="qubes-network-uplink@%k.service"
SUBSYSTEMS=="net", KERNEL=="eth*", ACTION=="remove", ENV{ID_NET_DRIVER}=="vif", ENV{SYSTEMD_WANTS}+="qubes-network-uplink@%k.service"
# new udev has DRIVERS
SUBSYSTEMS=="xen", KERNEL=="eth*", ACTION=="add", DRIVERS=="vif", ENV{SYSTEMD_WANTS}+="qubes-network-uplink@%k.service"
network: fix rules for network setup on new udev New udev have `DRIVERS` matcher, instead of `ENV{ID_NET_DRIVER}`. Add appropriate rule to the file. Without it, network was working incidentally, because there is a fallback in qubes-misc-post.service, but dynamic network change was broken. This applies at least to Debian stretch. Fixes QubesOS/qubes-issues#3192 2017-10-19 15:10:31 +02:00			`# old udev has ENV{ID_NET_DRIVER}`
Move network uplink setup to a separate service Previously, network uplink (eth0) was configured in two places: - udev (asynchronously) - qubes-misc-post.service - at the very end of the boot process This caused multiple issues: 1. Depending on udev event processing (non-deterministic), network uplink could be enabled too early, for example before setting up firewall. 2. Again depending on udev processing, it can be enabled quite late in the boot process, after network.target is up and services assume network already configured. This for example causes qubes-firewall to fail DNS queries. 3. If udev happen try to enable enable networking even earlier, it may happend before qubesdb-daemon is started, in which case network setup fill fail. For this case, there was network re-setup in qubes-misc-post service - much later in the boot. Fix the above by placing network uplink setup in a dedicated qubes-network-uplink@${INTERFACE}.service unit ordered after network-pre.target and pulled in by udev based on vif device existence, to handle also dynamic network attach/detach. Then, create qubes-network-uplink.service unit waiting for appropriate interface-specific unit (if one is expected!) and order it before network.target. QubesOS/qubes-issues#5576 2020-11-12 01:37:12 +01:00			`SUBSYSTEMS=="xen", KERNEL=="eth*", ACTION=="add", ENV{ID_NET_DRIVER}=="vif", ENV{SYSTEMD_WANTS}+="qubes-network-uplink@%k.service"`
			`SUBSYSTEMS=="net", KERNEL=="eth*", ACTION=="remove", ENV{ID_NET_DRIVER}=="vif", ENV{SYSTEMD_WANTS}+="qubes-network-uplink@%k.service"`
network: fix rules for network setup on new udev New udev have `DRIVERS` matcher, instead of `ENV{ID_NET_DRIVER}`. Add appropriate rule to the file. Without it, network was working incidentally, because there is a fallback in qubes-misc-post.service, but dynamic network change was broken. This applies at least to Debian stretch. Fixes QubesOS/qubes-issues#3192 2017-10-19 15:10:31 +02:00			`# new udev has DRIVERS`
Move network uplink setup to a separate service Previously, network uplink (eth0) was configured in two places: - udev (asynchronously) - qubes-misc-post.service - at the very end of the boot process This caused multiple issues: 1. Depending on udev event processing (non-deterministic), network uplink could be enabled too early, for example before setting up firewall. 2. Again depending on udev processing, it can be enabled quite late in the boot process, after network.target is up and services assume network already configured. This for example causes qubes-firewall to fail DNS queries. 3. If udev happen try to enable enable networking even earlier, it may happend before qubesdb-daemon is started, in which case network setup fill fail. For this case, there was network re-setup in qubes-misc-post service - much later in the boot. Fix the above by placing network uplink setup in a dedicated qubes-network-uplink@${INTERFACE}.service unit ordered after network-pre.target and pulled in by udev based on vif device existence, to handle also dynamic network attach/detach. Then, create qubes-network-uplink.service unit waiting for appropriate interface-specific unit (if one is expected!) and order it before network.target. QubesOS/qubes-issues#5576 2020-11-12 01:37:12 +01:00			`SUBSYSTEMS=="xen", KERNEL=="eth*", ACTION=="add", DRIVERS=="vif", ENV{SYSTEMD_WANTS}+="qubes-network-uplink@%k.service"`