Package: netcfg Severity: serious Tags: patch Justification: no networking after installation X-Debbugs-Cc: ifupd...@packages.debian.org, w...@packages.debian.org
Hi, I'm putting both ifupdown and wpa maintainers in the loop since I'd like to get some feedback of the proposed resolution for this major issue that's been annoying us for several releases: - wpa maintainers, you can jump to the second issue. - ifupdown maintainers, you can jump to the second and third issues. I know we have a few open bug reports about this already, but I thought I'd start a fresh bug, cutting to the chase. I've pushed three commits in the pu/ifupdown+wireless branch: https://salsa.debian.org/installer-team/netcfg/-/commits/pu/ifupdown+wireless Commit links: 1. https://salsa.debian.org/installer-team/netcfg/-/commit/9494d7ec02b32538db842d88c105db1ab2a6201b 2. https://salsa.debian.org/installer-team/netcfg/-/commit/247056dbb22e6eacbea6348c5c9a6951eab948bd 3. https://salsa.debian.org/installer-team/netcfg/-/commit/5ca665c6c26346e3c9c37c2df6366e8e5d718238 # First issue The first one explains why this could never work: we have a netcfg/target_network_config template that's preseedable, without a default value. The finish-install.d/55netcfg-copy-config script checks whether a value is preseeded, and sets it if it isn't: - if NM is installed, we use NM; - otherwise, if the connection is wired, we use ifupdown; - otherwise, the connection is wireless, and we use… loopback?! That means that at this point, /etc/network/interfaces contains entries for the wireless interface, but it's getting emptied to only contain the lo entry. The proposed fix is to stick to ifupdown for wired and wireless connections, with a small variation: if the connection is wireless and secured (WPA or WEP with a non-empty passphrase), we chmod 400 /e/n/i (in /target = the installed system); that used to be done a long while ago, in the early days of the patch series but that got scratched along the way. # Second issue Once that's fixed, if one gets both DHCP+SLAAC, the generated /e/n/i looks like this (± comments/newlines): allow-hotplug wlXXX iface wlXXX inet dhcp iface wlXXX inet6 auto wpa-ssid my-home-network wpa-psk my-very-secret-passphrase At best, we get SLAAC to work (IPv6 via RAs) but not DHCP: the first iface stanza is missing wpa-* parameters, and we get a huge delay at boot-up until dhclient finally times out. My first instinct was to replicate wpa-* settings in both stanzas: allow-hotplug wlXXX iface wlXXX inet dhcp wpa-ssid my-home-network wpa-psk my-very-secret-passphrase iface wlXXX inet6 auto wpa-ssid my-home-network wpa-psk my-very-secret-passphrase But that doesn't work either: when the DHCP is brought up, wpa-* are used by wpa_supplicant to do the authentication/association dance, DHCP works. But right afterwards, when the SLAAC entry is processed, the kernel and wpa_supplicant complain about being already associated, many errors are logged and deassociation ultimately happens. This leaves us with: an IPv4 address, no IPv6 address, and a DOWN interface. What seems to work in the DHCP+SLAAC case is writing just the DHCP entry, and let RAs bring up IPv6 connectivity on their own. I'm tempted to go with this solution for bookworm, as that cannot be worse than the current situation, but I'd be happy to get feedback from ifupdown and wpa maintainers about the best way to write /e/n/i for DHCP + SLAAC. As far as I can tell, ifupdown's interfaces manpage points at the many packages that can deal with extra options, and wpasupplicant's README.Debian is only about inet entries, inet6 is never mentioned. → ifupdown & wpa maintainers, comments welcome! # Third issue netcfg has some hotplug detection, which was last touched in 2005; it tries to identify interfaces that are hotpluggable, and lists them under /etc/network/devhotplug (in the installer's context), which is then used to determine whether interfaces should be declared “auto” or “allow-hotplug”. My rtl8192cu-based Wi-Fi USB dongle (shared from the host via libvirt) ends up as “allow-hotplug”, which is problematic because the module gets loaded after networking.service has returned, failing to raise the wireless interface. Using “auto” makes ifupdown wait a little more, and I'm getting my wireless interface configured. Looking at the contents of that /etc/network/devhotplug file, both lo and ens3 (which are not “hotpluggable”?!) appear several times, so I'd think the hotplug detection logic (via a script run when udev events happen in the net subsystem) no longer works as it did in the early 2000s. It's not clear to me what the downside of having “auto” everywhere would be; adding some “auto” statements about interfaces that don't exist seem to only lead to a few seconds being wasted at bootup (and the networking.service unit being marked as failed), meaning that some Ethernet or Wi-Fi dongle's getting unplugged wouldn't prevent machines from booting up, and users/admins concerned with networking.service being marked as failed could always revert from “auto” to “allow-hotplug” if that works for them (remember the timing issue mentioned above). → ifupdown maintainers, comments welcome! Cheers, -- Cyril Brulebois (k...@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
