On Thu, 2006-12-14 at 20:18 -0200, Marcelo Tosatti wrote: > On Wed, Dec 06, 2006 at 10:28:39AM -0500, Dan Williams wrote: > > On Wed, 2006-12-06 at 09:39 -0500, Owen Williams wrote: > > > Is WPA encryption planned for the olpc, and if so, what's the expected > > > time for support to be included? Most of the networks I'm on are WPA, > > > and it's difficult to develop on the laptop without a network > > > connection. > > > > Possibly, given the time... The driver "supports" it, but that support > > is completely untested with the switch to deferred association, and it's > > unclear if the driver works correctly with wpa_supplicant WRT rekey > > events not triggering infinite reauthentication loops. > > Tried WPA-PSK: not working with the generic wpa_supplicant driver due to > SIOCSIWAUTH returning -EOPNOTSUPP for both IW_AUTH_PRIVACY_INVOKED (10) > and IW_AUTH_RX_UNENCRYPTED_EAPOL (8). > > pprpplague mentions a marvell wpa_supplicant driver patch at > http://svn.gumstix.com/gumstix-buildroot/trunk/package/wpa_supplicant/patch_wpa_supplicant-0.4.7-MSI-2-GUM > > Opened up a ticket with more details: > http://dev.laptop.org/ticket/584
The wpa_supplicant patch doesn't help us there, since it basically ignores Privacy Invoked and unencrypted eapol. I can't see where it actually uses those settings to any effect. Note that wpa_supplicant is pretty dumb here and if the driver doesn't support just _one_ of the options for auth (of which there are many and not all drivers support all options) it sets the association timeout to 5 seconds. I've patched that in Fedora to be longer, since many drivers hit that issue. In any case, it's not completely clear to me what Privacy Invoked actually is; if you google around for it there's not much there and the stuff that is there refers back to hostap (from which these extensions originally came) and to various drivers. So, for the moment, we don't care about Privacy Invoked, but the RX Unencrypted EAPOL (EAP over LAN) does have implications for WPA support. After a certain point in the 802.1X auth procedure, both the supplicant (the STA) and the authenticator (the AP) should drop unencrypted EAPOL packets for security reasons. I believe that requires firmware support on our cards; obviously softmac cards can do that in code. If we can't get it in firmware, we could drop such packets in the driver in the packet receive paths; we can easily tell if they are EAPOL packets, telling whether or not they were unencrypted over-the-air is harder. Dan _______________________________________________ Devel mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/devel
