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 <[email protected]> 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] <[email protected]> http://lkml.kernel.org/r/<[email protected]> [2] for the matter of this discussion I define "obsolete" as <= 11 MBit/s and pretty much all not supporting WPA.
signature.asc
Description: This is a digitally signed message part.
