[ 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 <k...@debian.org> (2014-09-15): > So, putting my laptop installation aside, and concentrating on a VM > using KVM with USB pass-through to a USB adapter (USB ID is 0bda:8176, > that's RTL8188CUS), I've been able to verify (assuming firmwares have > been made available every time): > - wheezy amd64 works with WPA (TKIP) and WPA2 (AES) > [ sharing network over a Firefox OS phone with those denominations. ] > - wheezy amd64 works with WPA2-PSK/AES > [ as advertised by my home router ] > - sid amd64 doesn't work with any of those, even if I build an image > with wheezy's netcfg and/or wheezy's wpasupplicant-udeb. > > I've also checked that installing sid + 3.16 over Ethernet then manually > connecting (wpa_passphrase then wpa_supplicant) worked just fine (that's > been mentioned in my previous mail, but confirming). > > I'll now try and compare dmesg from within d-i and from the installed > system to see whether I can spot some differences which could help me > understand what the differences are, and possibly ask kernel maintainers > for help/insight. So I've created a bare wpa.conf using wpa_passphrase foo bar (matching my wireless setup) and tried to use it within d-i and outside, with: wpa_supplicant -c wpa.conf -i wlan0 Outside d-i I'm getting: ioctl[SIOCSIWFREQ]: Device or resource busy wlan0: Associating request to the driver failed wlan0: Associated with [mac address] wlan0: WPA: Key negotiation completed with [mac address] 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 wlan0: WPA: Failed to set PTK to the driver (alg=3 keylen=16 bssid=[mac address]) 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. 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. Mraw, KiBi.
signature.asc
Description: Digital signature
