[pkg-wpa-devel] Bug#683281: Bug#683281: iw: Please update README.Debian which contains information from 2008

Mon Jul 30 16:45:43 UTC 2012

Control: severity -1 wishlist

Hi

On Monday 30 July 2012, Paul Menzel wrote:
[…]
> it would be awesome if you updated `README.Debian`. It was written in
> 2008 and I would guess that in 2012 the interfaces have stabilized.
> 
> I would even like to see this in for Wheezy to provide people reading
> the documentation with up to date information.
[…]

The interfaces themselves have kind of stabilized; while they're still 
extended quite actively, that is done in a backwards compatible way. 
Compared to wireless-tools, iw can be considered feature complete.
The cli output of iw is still, and probably always will, be considered
volatile:

$ iw
Usage:  /sbin/iw [options] command
[…]
Do NOT screenscrape this tool, we don't consider its output stable.

However, besides crda strongly recommending and using iw, there has not
been done any kind of further "integration" into Debian - and at the
moment I'm not even be sure how that could be done in the first place.
Therefore the shipped README is still correct as it stands, the only
change we could do at this moment would be:

--- debian/README.Debian
+++ debian/README.Debian
@@ -39,10 +39,7 @@
 =============================================
 
 At the time of writing, it does not. The iw binary is provided as is, without
-any system integration (eg, with ifupdown). When the Linux Wireless developers
-are sufficiently satisfied with iw's functionality, and all of their work
-begins to filter down into the stable mainline Linux kernel tree, integration
-of iw into the Debian system can begin.
+any system integration (eg, with ifupdown).
 
 
  -- Kel Modderman <kel at otaku42.de>  Thu, 30 Oct 2008

…and I'm not going to bother the release team with a freeze exception 
for this tiny change that doesn't actually provide any more information
to the user.


What is iw used for in Debian and how about its integration at this point?
--------------------------------------------------------------------------

iw is needed by crda to react on regulatory domain changes, both by 
hardware (regulatory domain hints stored in EEPROM/ OTP) and manually,
be it through /etc/default/crda or manually with "iw reg get" or "iw 
reg set COUNTRYCODE".

iw can be used as far more advanced replacement for the wireless-tools
functionality, however it still can only interface with wlan drivers 
providing nl80211 support. 
.
Legacy drivers are not supported by iw.
.
…and exactly this is (and remains to be) the crux about it. While WE/ 
wext is deprecated and shouldn't be used with mac80211 based drivers 
(the CFG80211_WEXT compatibility layer is incomplete and borderline 
buggy, besides that its days are counted[1]), only new -mostly mac80211
based- drivers provide cfg80211/ nl80211 access methods. To the best of
my knowledge Kel already had a proof-of-concept ifupdown integration 
ready in 2008, but we refrained from adding that to the Debian package
because it can't be a drop-in replacement for wireless-tools' 
configuration due to not supporting these legacy drivers (most 
importantly ipw2100, ipw2200 and several RealTek staging drivers like
rtl8187se, rtl8192e, rtl8192u and r8712u; the other legacy drivers are
probably too old and hardware limited to be considered as still being
in common use - although those still exist in addition to the ones 
listed here!) and would have to be implemented as yet-another-competing
configuration syntax. At the same time no mac80211 based driver 
implements wpa de-/encryption  in the kernel module and instead 
hard-requires wpasupplicant to provide this functionality, which in 
turn abstracts nl80211 vs wext differences nicely from the 
(ifupdown) configuration, making it optional to provide iw specific
ifupdown hooks.

wpasupplicant and hostapd don't hard-require iw and link to libnl 
directly, to access the kernel's cfg80211/ nl80211 interfaces on their 
own. 

network-manager links to libnl as well and furthermore relies on 
wpasupplicant, via DBus, to talk to the kernel, therfore it doesn't 
hard-depend on the iw binary.

The only further domain, besides debugging and on-cli configuration, 
where iw becomes mandatory is advanced interface manipulation, like
mulptiple vifs, creating and destroying virtual interfaces, etc. pp.
To the best of my knowledge network-manager can't configure these at
the moment and I have no idea how we could implement an ifupdown hook
syntax abstracting this in a sensible way, without imposing to many
obstacles (help wanted, if you care about this!) - except abusing
{pre,post}-{up,down} functionality to call iw.


Quintessence
------------

WE/ wext and subsequently wireless-tools are strongly deprecated and
shouldn't be used with modern kernel drivers.

iw/ nl80211 cannot be used to access legacy kernel drivers, therefore
we cannot take over the wireless-* syntax namespace for 
/etc/network/interfaces. Adding yet-another new nl80211 specific 
namespace (let's call it wlan-*) is not considered to be a good idea,
especially as we already have the wpa-* and hostapd-* namespace 
provided by wpa_supplicant and hostapd which abstracts this and offers
the pretty much mandatory wpa support.

The staging RealTek drivers need to be ported to mac80211, before 
they'll get accepted into the proper mainline kernel; I don't see
any active work happening on this. The devices are pretty new (all but
rtl8187se support 802.11n); at least rtl8187se and r8712u have been 
pretty popular in the consumer market (but all contemporary RealTek
devices have proper in-kernel mac80211 drivers).

ipw2200/ ipw2100 have been neglected for several years, but they're 
still rather common, because these (especially ipw2200) were the 
default wlan cards mandated by the Centrino brand for several years
(ipw2200 from 2002 up to ~ late 2006). Recently a new maintainer has 
stepped up, whose intention is to work on cfg80211 support - but he has
no access to hardware or firmware documentation and it's totally 
unknown if the desired result is achievable.

There are still lots of old drivers for 'obsolete'[2] devices, it's 
safe to assume that these will never expose nl80211 interfaces. 
Affected drivers are (the list may be incomplete):
- ray_cs, Aviator/Raytheon 2.4GHz wireless
- airo/ airo_cs, Cisco/Aironet 34X/35X/4500/4800 ISA and PCI cards
  iirc use in some IBM Thinkpads
- atmel_{cs,pci}, Atmel at76c50x 802.11b chipset
- wl3501_cs, Planet WL3501 PCMCIA cards
- zd1201, ZyDAS ZD1201 USB Wireless
- hostap_{cs,plx,pci}, Prism2/2.5/3
- orinoco_{cs,plx,pci,tmd,nortel,usb}/ airport/ spectrum, Hermes 
  chipset 802.11b support (Orinoco/Prism2/Symbol)
- vt6655/ vt6656, VIA Technologies VT6655/ VT6656
- wlags49_h2/ wlags49_h25, Agere Systems HERMES II/ II.5
- wlan-ng, Prism2.5/3 USB
To the best of my knowledge, only hostap_{cs,plx,pci} supports WPA2,
maybe also airo/ airo_cs and zd1201. Only some of the chipsets 
(AT76c505) supported by atmel_{cs,pci} support WPA1/ TKIP. I think all
but the very rare VIA VT6655/ VT6656 chipsets are <= 11 MBit/s.


So is better iw integration into Debian really needed - or even wanted,
rather than relying on wpa_supplicant (or indirectly network-manager)
to abstract the details from the user and the system configuration?

What may be a good idea for jessie would be a release goal to abandon 
WE/ wext use in applications and to avoid installing wireless-tools by
default; although this would hit some application (afaik aircrack-ng) 
hard. Disabling CFG80211_WEXT in jessies kernel would be ideal as well,
however some non-mac80211 drivers depend on it without actually being
configurable through cfg80211/ nl80211.
IMHO d-i should have never started to support installing over wlan for
wext compatible drivers (which makes its configuration seriously more
difficult), removing it now would be a regression.

Any help with this, both upstream as in Debian would be appreciated.

Regards
	Stefan Lippers-Hollmann

[1]	<1333540287.18879.3.camel at jlt3.sipsolutions.net>
	http://lkml.kernel.org/r/<1333540287.18879.3.camel@jlt3.sipsolutions.net>
[2]	for the matter of this discussion I define "obsolete" 
	as <= 11 MBit/s and pretty much all not supporting WPA.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-wpa-devel/attachments/20120730/0c85a9ae/attachment.pgp>
