On Tue, Feb 24, 2015 at 05:11:14AM +0100, Stefan Lippers-Hollmann wrote: > On 2015-02-23, Elliott Mitchell wrote: > > On Mon, Feb 23, 2015 at 03:03:17PM +0100, Stefan Lippers-Hollmann wrote: > > > On 2015-02-22, Elliott Mitchell wrote: > [...] > > > [...] 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`. > > No, it can't. iw isn't a daemon, if your connection drops, your > connection is gone - mac80211 drivers won't try to reconnect. That's > a task for userspace, a supervising daemon - wpasupplicant in the most > trivial case or more sophisticated ones if you like. > > Of course one could add create yet-another-networking-daemon and add > it to the iw package, but this would be far from trivial - and be > beyond its scope. After all you don't expect /bin/ls to suddenly grow > an inotify backend daemon.
How is this relevant to the original request, adding an ifupdown script? It wasn't explicit, but I was thinking of something along the lines of what wireless-tools provides. Simply something that brought up the interface to a minimally functional state. I had no expectation of any of the tasks you bring up being handled. > iw can work without wpa_supplicant, it can do lots of things without > wpa_supplicant[0] - what it can't do is handling WPA2 encryption (as > mac80211 pushes that into user-space) or to actually manage connection > and reconnect when needed. In a perfect environment, without > interference and always a strong signal being available, where links > never drop and encryption are tales from the sci-fi universe - you can > use iw to configure an unencrypted link. But you can't to that in > practice, as nothing is ever perfect and connections will drop > frequently - and non-WPA2 encrypted networks (which is where you > hard-depend on wpa_supplicant either way) are the exception, not the > norm - especially according to IEEE 802.11n. But I'm repeating > myself... Not a single one of these things was requested. > iw is not the primary tool to connect to a wireless network - and it > doesn't depend on wpa_supplicant at all (the primary use-cases for > connecting to a wifi network do, but not iw). iw is totally optional[1] > when it comes to connecting to a wireless network, its use starts when > you want to debug on the low-level - or scan for APs, or add multiple > VIFs or do other low-level interface manipulations - or just to provide > a sample implementation of the nl80211 API. Compare it to iwlist, not > iwconfig (unless you know what you're doing and/ or do quite advanced > stuff, which is where you might compare its use to that of ethtool, > unnecessary of $Aunt_Tilly's notebook, but essential if you're doing > advanced stuff and know what you're doing). The most one could argue > for, would be adding wpa_supplicant as a suggests - but this would be > quite far-fetched[2]. And this is what one might expect an iw ifupdown script to do. Crucially, that item of handling multiple VIFs. > > 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. > > Independent of your statement itself, this language doesn't really help > your case. Sorry, I did some experimentation with it a longish while ago and it wasn't pleasant trying to get it to do simple tasks. Perhaps it is better now, but things were easily solved without it. -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | ehem+sig...@m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org