--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
Source: netcfg
Source-Version: 1.182
Done: Cyril Brulebois <kibi@debian.org>
We believe that the bug you reported is fixed in the latest version of
netcfg, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1029352@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Cyril Brulebois <kibi@debian.org> (supplier of updated netcfg package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Tue, 24 Jan 2023 05:15:23 +0000
Source: netcfg
Architecture: source
Version: 1.182
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team <debian-boot@lists.debian.org>
Changed-By: Cyril Brulebois <kibi@debian.org>
Closes: 1029352
Changes:
netcfg (1.182) unstable; urgency=medium
.
* Fix ifupdown configuration for wireless connections (Closes: #1029352,
issue #1): when NetworkManager isn't used, a wireless connection would
result in the internal netcfg/target_network_config (if not preseeded)
being set to “loopback”, resulting in a /etc/network/interfaces that's
mostly empty in the installed system. Instead, use “ifupdown”, just
like in the wired connection case, and keep /e/n/i as written by
netcfg initially. Since secrets can be stored there (when using WPA or
WEP with a non-empty passphrase), change its mode to 600 for secure
connections.
* Fix ifupdown configuration for wireless connections (Closes: #1029352,
issue #2): when both DHCP and SLAAC stanzas are written for a wireless
interface, the wireless options are only written for the second one
(the SLAAC stanza, inet6 auto). This means that the first one (the
DHCP stanza, inet dhcp) cannot establish a connection, leading to long
delays until dhclient times out. Since duplicating wireless options in
both stanzas wouldn't work, just write a DHCP stanza in that case,
letting router advertisements (RAs) set up IPv6 automatically.
Checksums-Sha1:
6b58976c9c13e2233a2e17bdbed1bf59764deb6b 1804 netcfg_1.182.dsc
35f0186d25f1310090f08fbd3ffbc3d13c9944a6 402580 netcfg_1.182.tar.xz
43177d5db91519135a8832e831307794df8c4eb7 5842 netcfg_1.182_source.buildinfo
Checksums-Sha256:
e8f8bfd44556a5a10ace9d39b34c76a67e21d4f4346125c1805d8013f6c6c743 1804 netcfg_1.182.dsc
094fa02c0fdea0e6401d1e5ae66bc86d6da958c7bab26c3cff436e5a4c631a8f 402580 netcfg_1.182.tar.xz
ec6895046eba5f280849057941d187bfb81880058cc5b4a3c9ce562b681c1f24 5842 netcfg_1.182_source.buildinfo
Files:
3a33a51fb5d3ce4eaa52ef14b0b9a922 1804 debian-installer optional netcfg_1.182.dsc
917a93dd8cffc745c45786efaec2eb01 402580 debian-installer optional netcfg_1.182.tar.xz
023554e39eb26783c77f672ec883c5ff 5842 debian-installer optional netcfg_1.182_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQJEBAEBCgAuFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmPPbFoQHGtpYmlAZGVi
aWFuLm9yZwAKCRD/kUrwwrNVIN7sD/4h6Cx8oHft8Ee//AB5qu5g9BVzCWqRT8rx
XlY0OKuvK5o1IzIoL39FQZ2IT1Kod9PhQjpU0HcN7lpYI9CWwIHevSkdCwZQj5cM
Y4Tt4c7y0UgMBjBcr/ByzQ5zTuO1lhN2SpQdGaX8ORWJ/ox7HAVI1wzEoelIgEf5
vMOpdXjg3aPn4pwxVoLH62ngaHd1sp5rsHuG7VoUQVHRb2OvzJN1r3Yo6wM/P/FO
TXonoP7i6vWenJrt1zSy7orm7iPft+jV/HvxaiG4rLFL5EvPx1pWRAqPwMMcTopa
F6Fo0sC5noslzWIP7ChrcfGD4GlQX45FBgnl6h0QEZtE+W5Zb0UGzulKaYkqOTAb
vo9JU7LFOBMw+4a/EsSrIaQjL9a3stqtNZABGEVt9wj9A8tOsYKuK0Q9r/bmbi7K
qhhrXOErjAyIuA9H21lWWxkrg4EiwCTR8IEfmMV9qcCsUGHyHgyoebp/50HhACTe
6HtHy8oYQk9GVfd1M0h3zNotui0qk+NRRdEr+X4oIXcSMtxESMlfcuWaOackVaMh
DmkJ7GQSe6ActXLQt9J82hhxLq7FxspjmmmsBSEsL9q39wARgqeVkUzSNoDB1xSE
HNwpzwGb8JqJ2XaTb/9JLC0SmHTDmNR7XsA9i3cewxuFSGvQrtClS+ueTXt//ygt
bEDLyX/lMA==
=4X9A
-----END PGP SIGNATURE-----
--- End Message ---