[pkg-wpa-devel] Bug#779007: closed by Stefan Lippers-Hollmann <s.l-h at gmx.de> (Re: Bug#779007: iw: Implement hook script for ifupdown, please?)

[Elliott Mitchell]

reopen 779007
quit

On Mon, Feb 23, 2015 at 03:03:17PM +0100, Stefan Lippers-Hollmann wrote:
> On 2015-02-22, Elliott Mitchell wrote:
> > Package: iw
> > Version: 3.4-1
> > Severity: wishlist
> > 
> > It would be helpful if the iw package could implement an ifupdown hook
> > script similar to the one the wireless-tools package has, but using iw
> > instead of iwconfig.  Avoiding conflicting with wireless-tools may be a
> > bit interesting, but this will make iw rather handier.
> 
> Sorry, but no, this will not be done.
> 
> The problem here is two-fold. On the one hand iw can't deal with 
> non-nl80211 compatible drivers (and unfortunately, 'thanks' to the
> various staging drivers, these aren't dying out any time soon), making
> a full 1:1 replacement (and/ or taking over the existing syntax from-)
> of wireless-tools impossible. On the other hand iw does not provide 
> any kind of connection supervision, it's just a one-shot configuration
> tool. This means a wireless connection purely configured by iw won't
> recover from connection losses (getting out of range, temporary 
> interference, etc.) and it can't roam between different access points
> either.

The latter is exactly what I expected from reading the package
description, behavior identical to `ifconfig` and `iwconfig`.

Meanwhile the former is near trivially solveable, though some trivial
cooperation with wireless-tools is needed.  The exit value of running
`iw <interface>` and `iwconfig <interface>` tells you whether the
interface has wireless support and if so which mechanism.  That merely
leaves the corner case of an interface that supports both.

> This leads to the next problem, contrary to the old IEEE 802.11a/b/g
> standards, IEEE 802.11n (802.11ac, 802.11ad, ...) mandates the use of
> WPA2/ CCMP (WEP/ WPA1 are not specified for 802.11n and therefore 
> can't be expected to work), which therefore mandates the use of 
> wpa_supplicant (for all reasonable intents and purposes) anyways. The
> wpasupplicant package now does provide exactly what you're looking 
> for, ifupdown hooks which do use the native nl80211 APIs (unless you
> force wext explicitly or if your wlan card doesn't support nl80211 
> and therefore needs to trigger the transparent fallback to wext). As
> a side effect wpa_supplicant does provide what iw is missing, 
> connection supervision and management - it can reconnect after 
> connection drops, it can roam between different APs of a larger wlan
> installation (or even heterogenous, independent, networks) and it's
> mandatory for any wpa2 links anyways (contrary to some ancient 
> full-mac drivers, modern mac80211 based drivers don't have kernel 
> support for WPA encryption, using wpa_supplicant in user-space is
> required here).

Right now I'm in the early phases of bring-up, as such I want to make
sure the basic things are working before I tackle more complex bits.  If
iw *cannot* work without wpasupplicant or hostapd, why doesn't the iw
package depend on these?

> For these reasons, I won't add yet another distro-specific networking
> syntax and pollute the ifupdown namespace even more. Even less 
> considering the rising popularity of more modern networking daemons 
> (like network-manager, systemd-networkd, wicd or connman). iw is an
> important tool for debugging wireless issues, to aid configuring the
> regulatory domain settings (indirectly via crda) and to do advanced
> interface manipulations (adding multiple VIFs etc.), but it's not a 
> suitable method for general wlan interface supervision.

I believe the correct spelling is "nyetwork-munger" (hopefully it has
improved, but right now that isn't the issue).  Meanwhile I haven't come
to a conclusion (or concussion, yet) on systemd, but I'm rather concerned
about that situation.  More notably though, those aren't the right tool
for the particular situation.

If you're going to leave this unsolved, I suspect the correct action is
to mark the bug "wontfix", not to close an unsolved bug.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         EHeM+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445