Bug#1029352: netcfg: broken ifupdown support for wireless interfaces
Package: netcfg
Severity: serious
Tags: patch
Justification: no networking after installation
X-Debbugs-Cc: ifupdown@packages.debian.org, wpa@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 (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Reply to: