Cyril Brulebois <k...@debian.org> (2014-09-11): > Chris Tillman <toff.till...@gmail.com> (2014-09-11): > > With this installation I was using WPA2-Personal at the access point. I see > > the > > log messages look similar as in bug #741622, deauthenticating immediately > > after connect. > > > > For a later install on the same computer, also to USB target, I used WEP > > in the installer to connect to the access point (installation > > report #761148). So possibly the problem has to do with WPA2 as opposed > > to WEP. > > That's an interesting data point, thank you! > > (That reminds me I haven't yet submitted an installation report… the > wireless part wasn't OK either.)
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 verified that installing over a wired connection lets me configure wpa_supplicant and connect to wireless from within the same VM, so there's definitely something fishy within d-i, even if I don't know what yet. Anyway, that doesn't allow me to conclude on the “WEP might be OK” topic, but various WPA setups are clearly broken. Let's see whether I can get that debugged further tomorrow. Mraw, KiBi.
signature.asc
Description: Digital signature
