Hi On Monday 15 September 2014, Cyril Brulebois wrote: > [ Executive summary: WPA works fine in d-i with 3.2, but not with newer > kernels, like 3.16; and userland doesn't seem to be the obvious > culprit. ] > > Cyril Brulebois <kibi@debian.org> (2014-09-15): [...] > while within d-i I'm getting: > > ioctl[SIOCSIWFREQ]: Device or resource busy > wlan0: Associating request to the driver failed > wlan0: Associated with [mac address] > ioctl[SIOCSIWENCODEEXT]: No such file or directory The ioctl failure is because netcfg still (only) uses the deprecated wireless-tools/ wext driver API with wpa_supplicant, even for mac80211 based drivers. While cfg80211 implements a wext compatibility layer, it's strongly discouraged for modern drivers in favour of mac80211's native nl80211 access method. wpa >= 1.0~, unless forced by the user (-D{nl80211,wext}), always prefers nl80211, if the driver supports it, but netcfg can't configure it. While the Documentation/feature-removal-schedule.txt files has been removed from kernel >= 3.8~ for procedural reasons (constant merge conflicts for Linus), its stanza for CONFIG_CFG80211_WEXT is still correct[1]: What: CONFIG_CFG80211_WEXT When: as soon as distributions ship new wireless tools, ie. wpa_supplicant 1.0 and NetworkManager/connman/etc. that are able to use nl80211 Why: Wireless extensions are deprecated, and userland tools are moving to using nl80211. New drivers are no longer using wireless extensions, and while there might still be old drivers, both new drivers and new userland no longer needs them and they can't be used for an feature developed in the past couple of years. As such, compatibility with wireless extensions in new drivers will be removed. Who: Johannes Berg <johannes@sipsolutions.net> Of course basic wext operations are still supposed to work at the moment, but it's not tested or debugged anymore (and likely to be removed alltogether, once anyone sees a larger bug in it)- and almost certain to fail beyond the most simple use cases. Unfortunately legacy drivers like ipw2100/ ipw2200 (see [2] for a list, probably ipw2[12]00 is the only still relevant from that list) and most staging wlan drivers (although some newer RealTek drivers implement a non-mac80211 based nl80211 API) can only be configured/ used via wext. This is why Kel originally suggested to (ab-)use wpa_supplicant for scanning from netcfg (which prefers nl80211, but can fall back to wext where needed[3]), alternative ways that allow native scanning for nl80211 and wext would be OpenWrt's iwinfo[4]. > wlan0: WPA: Failed to set PTK to the driver (alg=3 keylen=16 bssid=[mac address]) This bug is unrelated to the ioctl warning above, but is likely caused by some missing kernel modules in the kernel udebs which are needed to enable wpa for your wlan card. Which wlan cards (well, which kernel module) are you using for testing? I see that the original submitter uses Atheros AR9485 == ath9k, which > Looking at wpa source code I see something that could explain why WEP > still works while WPA doesn't: > > ,---[ src/drivers/driver_wext.c ]--- > | /** > | * wpa_driver_wext_set_key - Configure encryption key > […] > | * This function uses SIOCSIWENCODEEXT by default, but tries to use > | * SIOCSIWENCODE if the extended ioctl fails when configuring a WEP key. > | */ > `--- > > Now, I guess the [n,w]ext step is figuring out why SIOCSIWENCODEEXT fails > within d-i. As mentioned above, the ioctl warning only happens because netcfg forces wpa_supplicant into wext mode, rather than allowing it to prefer nl80211 (like it does on a full install). A simple test for this would be configuring /etc/network/interface on an installed system by forcing nl80211 or wext for comparison (see [5] for documentation of the ifupdown hooks): # Connect to access point of ssid 'homezone' with an encryption type of # WPA-PSK/WPA2-PSK, using the 'wext' driver backend of wpa_supplicant. # The psk is given as an encoded hexadecimal string. DHCP is used to obtain # a network address. # iface wlan0 inet dhcp wpa-driver wext wpa-ssid homezone # hexadecimal psk is encoded from a plaintext passphrase wpa-psk 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f Just change wpa-driver from wext to nl80211 (or don't set this option at all), to switch between wext or nl80211 mode on an installed system. > debian-kernel@, any idea? > > > Looking around, I've seen reports about crypto-related stuff like aes > that could be missing? Maybe crypto-modules should get more stuff in? > > Trying to verify this particular option, I'm a bit astonished by > CRYPTO_AES, which is advertised as =m in linux's sources, as well as in > the generated debian/build/config.amd64_none_amd64 but advertised as =y > in the resulting binary package I have installed (at least according to > /boot/config-3.16-1-amd64). But looking at vmlinuz in the following > packages, both look identical… > > linux-image-3.16-1-amd64_3.16.2-3_amd64.deb > kernel-image-3.16-1-amd64-di_3.16.2-3_amd64.udeb > > so that might be something different anyway. This is less of a configuration (as in kernel .config) problem, but more likely to be caused by some (newly) required kernel modules providing the functionality for wpa modes missing from the udebs for d-i. Taking a simple mac80211 based wlan card (ar5523, USB) as example, forced into wext mode mode, I see these wireless modules as required for wpa2-psk/ ccmp - this is not using the Debian kernel, which might be slightly less modular: plugging in ar5523, unconfigured: + arc4 + ar5523 (well, this is the particular module only require for ar5523) + mac80211 + cfg80211 + rfkill after starting wpa_supplicant in (forced) wext mode: + ctr + ccm + af_packet For ath9k, the required module needed on top of the ones above seam to be (less reliably, as I can't hotplug PCIe): + ath9k + ath9k_common + ath9k_hw + ath Depending on your particular wlan card and how its driver is divided into sub-modules (or how well it is integrated into other kernel subsystems), you might need additional modules as well. [with my wpa maintainer hat on] Semi-related, I have a pending upload for wpa (wpasupplicant-udeb), can you give me a rough guide when it's safe to upload in order not to interfere with d-i beta2[6]? There are no behavioural changes, besides many bugfixes[7]. If you want to test it for d-i, the packaging is ready (besides the changelog entries) in the normal VCS location[8]. Regards Stefan Lippers-Hollmann [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/feature-removal-schedule.txt?id=v3.6#n422 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683281#10 [4] https://dev.openwrt.org/browser/trunk/package/network/utils/iwinfo it only needs trivial modifications to the buildsystem to work in Debian. A pure nl80211 example implementation would be found in iw. [6] https://lists.debian.org/debian-cd/2014/09/msg00027.html Subject: (Almost) Time for Jessie Beta 2? [7] probably particularly important to eduroam setups, although this particular configuration isn't supported by netcfg and can only be used in a full installation [8] Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-wpa/wpa/trunk/ Vcs-Svn: svn://anonscm.debian.org/pkg-wpa/wpa/trunk/ http://aptosid.com/slh/wpa/wpa_2.2-0~svnr1884.0.dsc http://aptosid.com/slh/wpa/wpa_2.2-0~svnr1884.0.debian.tar.xz http://aptosid.com/slh/wpa/wpa_2.2.orig.tar.xz
Attachment:
signature.asc
Description: This is a digitally signed message part.