Bug#1029352: netcfg: broken ifupdown support for wireless interfaces
Hello,
On 21/01/2023 at 17:14, Cyril Brulebois wrote:
# 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.
(...)
→ ifupdown & wpa maintainers, comments welcome!
Comment from a simple user: I hate so say, but IMO ifupdown and/or
/etc/network/interfaces format is broken by design. Stanzas mix link
layer and network layer parameters and this causes various issues when
you have several stanzas for the same interface. Link layer parameters
should be applied once per interface regardless of the address family.
# 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.
That should not happen. After reading Alf's reply, I suspect a
regression introduced in the latest bookwork ifupdown release:
* networking.service: Add ExecStart=/sbin/ifup -a --allow=hotplug.
Patch by "Oleg A. Arkhangelsky" <sysoleg@yandex.ru>
(Closes: #1022843)
According to the bug report, the patch also adds '--ignore-errors' so
that ifup and networking.service return success even if hotplug
interfaces are missing. I'm afraid it has a side effect: it also marks
the interface as brought up, and when invoked by udev after the
interface is created, ifup will not do anything.
Reply to: