wpa encryption ETA?

Dan Williams dcbw at redhat.com
Sun Dec 17 09:45:44 EST 2006

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
> 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.


More information about the Devel mailing list