[pkg-wpa-devel] Bug#766746: Bug#806889: wpasupplicant: New upstream version (2.5)

[Stefan Lippers-Hollmann]

Hi

Thanks for the feedback, I'm really interested in the circumstances
wpa_supplicant's networkd integration is supposed to be used.

On 2016-04-20, Raphael Hertzog wrote:
> On Wed, 20 Apr 2016, Stefan Lippers-Hollmann wrote:
> > - systemd-networkd upstream hasn't committed to a policy regarding 
> >   wireless devices, its handling might change in the future  
> 
> Yes, but the fact that systemd might get some native support is
> not guaranteed to break the setup we want to use here.

While that is correct, we've been there in the past with a dedicated
sysv initscript rather than providing native hooks for ifupdown (and
removing this was painful, to say the least), that's why I'm careful
committing to a potentially temporary (but highly user-visible) way 
of configuring wpa_supplicant (users will find and use it - and 
complain loudly, if (when!) it goes away).

> > - systemd-networkd doesn't provide any tools like ifup/ ifdown so
> >   far, making dynamic configuration changes (e.g. switch from wired-
> >   to wireless networks) difficult.
> > - hotpluggable wireless cards (USB) are problematic in the sense
> >   that systemd will wait (until timeout, 90s by default) if the
> >   a configured device is unplugged.
> > - basically unsuitable for notebook scenarios, where one might 
> >   occasionally want to switch to wired ethernet (so far routing
> >   metrics seem to be the only, quite hacky workaround).  
> 
> I think that people opting for systemd-networkd are fine with those
> limitations. Consider that people want to use it on devices like
> the raspberry pi which is not really like a smartphone or a laptop...

At least RPi 1 and 2 are in the same camp, as USB wlan is the only
choice there as well, only the RPi 3B has a non-USB/ fixed wlan card. 
The same goes for many other ARM based devboards, even if they have
wlan onboard, USB cards (and thereby hotplugging) are common there (be
it that the onboard wlan card doesn't have mainline support yet or 
because it's not reliable enough). Admitted, they're less likely to be
used in an interactive fashion.

> Myself I was interested to document this setup for Kali Linux users
> (Debian derivative) where we use lots of ARM devices with built-in
> wifi.
> 
> I also don't know what's hacky with the routing metric usage. What else
> would be its purpose if not to prioritize between different routes?

Routing metrics themselves aren't hacky at all, but more or less abusing
them is. I'm indeed looking at it from a notebook centric side (not 
exclusively, more like an interactive system where one might plug/ unplug
wired ethernet from time to time). The problem I see in this usage 
scenario is this.

Imagine a notebook connected to your local network (192.168.x.y/24), 
usually via wlan, but with the intention of using the wired ethernet 
(if available) for larger file transfers. In this scenario, the ideal
approach would be that the wireless interface would be deactivated
automatically whenever the ethernet plug is connected (and re-activated
whenever the wired interface goes down). However current 
systemd-networkd doesn't have this concept (no way for providing 
default-off networkd configurations, nor selectively enabling or 
disabling a particular, pre-configured, network interface), nor an 
automated ifplud/ guessnet alike. The only workaround here would be
using routing metrics, e.g.:

$ cat /etc/systemd/network/60-wired.network 
[Match]
Name=enp2s0

[Network]
DHCP=yes
IPv6PrivacyExtensions=true

[DHCP]
UseDomains=yes
RouteMetric=30

$ cat /etc/systemd/network/60-wireless.network 
[Match]
Name=wlp3s0

[Network]
DHCP=yes
IPv6PrivacyExtensions=true

[DHCP]
UseDomains=yes
RouteMetric=20

In the simple (IPv4-only!) case, this works quite nicely, even though
both interfaces remain to be active, routing doesn't get confused and
large file transfers work quickly (over wired ethernet) and hotplugging
(or hot-unplugging) ethernet works nicely (to the extent possible).
When both interfaces are up, you end up with two IPv4 addresses from
the same subnet, routing works as expected.

The problems start, once you add IPv6 and DHCPv6 to the mix. In 
contrast to IPv4, DHCPv6 doesn't request IPv6 addresses based on 
interface's MAC address, but based on a system-wide DUID. So in this
case, both interfaces are up (and connected to the same subnet), but
only one interface can get the correct (matching the configured DNS name) 
IPv6 address (first come, first served - more or less randomly), the other
interface only gets a random IPv6 address, thereby making the routing 
metrics pretty useless (at least for incoming connections).
[ yes, systemd-networkd has much bigger problems when it comes to IPv6
  support, but this is a more or less wlan specific one ]


Now let's see the next scenario, also not too uncommon for systems used
in an interactive fashion (notebooks in particular, but not just those),
configuring embedded devices (like CPE equipment, routers, modems, PBX 
systems, etc.). You temporarily need to connect to an 'uncommon' network,
mostly via wired ethernet - while still being in range of your configured
wlan bssid. This may result in being concurrently connected to two 
different subnets with the same base address/ netmask (wlan with a valid
route to the internet, LAN as a dead-end). Enabling/ disabling interfaces 
managed by networkd doesn't work (yet), but metrics pretty much do what
they're told to do (default route on the wired interface, which may not
have an internet connection, but that's fine, worse is the wlan also being
available and providing overlapping routes that aren't expected), resulting
in quite surreal effects.


Of course, neither of these scenarios are a bug with routing metrics, they
just show that using them as a bandaid (because constantly moving and 
removing files from /etc/systemd/network/ is inconveniet) may have 
unintended consequences. But lacking a proper way to temporarily disable/ 
enable pre-configured interfaces, they're the next best thing (until you 
fall into these pitfalls, and yes I haven't constructed these, I encounter 
these problems regularly).

Regards
	Stefan Lippers-Hollmann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digitale Signatur von OpenPGP
URL: <http://lists.alioth.debian.org/pipermail/pkg-wpa-devel/attachments/20160425/c6161abe/attachment.sig>