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.