Bug#1029352: netcfg: broken ifupdown support for wireless interfaces

2023-01-23 Thread Cyril Brulebois 
Control: tag -1 pending

Cyril Brulebois  (2023-01-21):
> I've pushed three commits in the pu/ifupdown+wireless branch:
>   
> https://salsa.debian.org/installer-team/netcfg/-/commits/pu/ifupdown+wireless

Updated branch:
  
https://salsa.debian.org/installer-team/netcfg/-/commits/pu/ifupdown+wireless-v2

> 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

Updated commits, with changelog entries this time (no code change):
 1. 
https://salsa.debian.org/installer-team/netcfg/-/commit/aa62245f2960363f8b16f1f30d666936cc88bc83
 2. 
https://salsa.debian.org/installer-team/netcfg/-/commit/815cdfccaa5567fdf53594d47545d97c235de68e

Please note the third commit got moved to another branch:
  
https://salsa.debian.org/installer-team/netcfg/-/tree/pu/disable-hotplug-detection
  
https://salsa.debian.org/installer-team/netcfg/-/commit/9000be355b5e35134958c2655ec35bc75ba1b7e7

I suppose we can postpone wondering what to do about hotplug support
(netcfg currently believes everything is hotpluggable…) to a later time
(after bookworkm) given the broken “allow-hotplug” support at boot-up
(third issue) was an ifupdown regression in the end: #1022843.


My current plan includes more work on hw-detect; I'll upload netcfg with
commits from the ifupdown+wireless-v2 branch once I'm done (probably in
a few hours). Feedback regarding the netcfg commits is still very much
welcome (even after the upload, we can still tweak things before the
release).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1029352: netcfg: broken ifupdown support for wireless interfaces

2023-01-22 Thread Pascal Hambourg 

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" 
 (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.

Bug#1029352: netcfg: broken ifupdown support for wireless interfaces

2023-01-21 Thread Cyril Brulebois 
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