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

2016-04-24 Thread 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 

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

2016-04-20 Thread Raphael Hertzog
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.

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

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?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/



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

2016-04-20 Thread Stefan Lippers-Hollmann
Hi

On 2016-04-20, Raphael Hertzog wrote:
> Hi Stefan,
> 
> On Thu, 17 Mar 2016 03:01:21 +0100 Stefan Lippers-Hollmann  
> wrote:
> > Given that it's opt-in, explicitly documenting this as volatile
> > and potentially unsupported (in the future) might be a way out, 
> > but I'd still hate to eventually break previously working network
> > configurations in the future.  
> 
> Please do this if it's the only way to reassure you about this feature.
> But this setup is largely documented and already in use in ArchLinux for
> example and I was surprised to see that Debian did not support it yet.
> 
> It seems to work rather well for most persons including Debian persons:
> https://www.joachim-breitner.de/blog/664-Switching_to_systemd-networkd
> 
> That article is dated Oct 2014 so we're really late in the game... please
> fix this soon. Thank you.

What is your opinion regarding the system inherent problems I've raised?

[ pasting from <20160317030121.68b23ccf@mir>, 
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766746#22 ]

- systemd-networkd upstream hasn't committed to a policy regarding 
  wireless devices, its handling might change in the future
- 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 was really hoping to get some feedback, especially the later three
issues, from those looking to get it supported.

Regards
Stefan Lippers-Hollmann


pgpNCZD6az3ki.pgp
Description: Digitale Signatur von OpenPGP


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

2016-04-20 Thread Raphael Hertzog
Hi Stefan,

On Thu, 17 Mar 2016 03:01:21 +0100 Stefan Lippers-Hollmann  wrote:
> Given that it's opt-in, explicitly documenting this as volatile
> and potentially unsupported (in the future) might be a way out, 
> but I'd still hate to eventually break previously working network
> configurations in the future.

Please do this if it's the only way to reassure you about this feature.
But this setup is largely documented and already in use in ArchLinux for
example and I was surprised to see that Debian did not support it yet.

It seems to work rather well for most persons including Debian persons:
https://www.joachim-breitner.de/blog/664-Switching_to_systemd-networkd

That article is dated Oct 2014 so we're really late in the game... please
fix this soon. Thank you.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/