Trying to connect to network with LEAP authentication
dcbw at redhat.com
Thu Sep 28 08:11:57 EDT 2006
On Wed, 2006-09-27 at 20:08 -0700, Jouni Malinen wrote:
> On Fri, Sep 22, 2006 at 10:34:50AM -0400, Dan Williams wrote:
> > I believe cards that actually support LEAP (airo, ipw)  do most of
> > the association work in firmware. Unfortunately, that's a black box
> > that you can't easily see into. wpa_supplicant (and any other stuff
> > that talks to the card) just sets up a bunch of values and pushes them
> > to the card. The firmware then returns 'success/failure' for the
> > association. You may be able to figure out if you configuration is at
> > fault if you enable verbose debugging for the wireless driver.
> >  I'm quite curious; do any other cards actually support LEAP? How is
> > LEAP done with softmac drivers like bcm43xx? Is it implemented at all?
> Well, LEAP is a bit different beast than other EAP methods since it may
> be used to indicate couple of different things.. LEAP is an EAP method
> (though, not really a standard compliant one) and in theory, it should
> work if any other EAP method works. However, Cisco APs have an option
> for requiring a so called "Network EAP" authentication algorithm
> (802.11 authentication) which does not really do anything else than
> changes the algorithm number in the authentication frames (i.e., there
> is no real authentication here). This is one of the most common problems
> in getting "LEAP" to work.
> Selecting "Network EAP" authentication algorithm can be forced by adding
> auth_alg=LEAP into the network block in wpa_supplicant configuration.
> This is tried automatically if LEAP is in the list of allowed EAP
> methods. However, "Network EAP" is not a standard 802.11 feature and
> many drivers do not support it.. I have not tried ipw drivers with it
> (nor softmac for that matter; Devicescape stack has support for it).
> As far as your question about how LEAP is implemented is concerned,
> there are indeed some drivers that implement LEAP (the EAP method) in
> firmware. This is somewhat odd design, but well, that's what you get
> with proprietary authentication mechanisms.. If the driver is indeed
> doing this, username/password will need to be configured with some
> driver specific mechanisms and there is not much that wpa_supplicant can
> do about it. If the driver does not implement LEAP (or allows internal
> implementation to be disabled), wpa_supplicant can be used to take care
> of the LEAP authentication (EAP method; not the 802.11 authentication).
I'm still somewhat unclear here... Given a card like airo or ipwXXXX,
what parts of the connection process does the firmware handle, does the
driver handle, and does wpa_supplicant handle? On an airo, it's _all_
firmware of course, using private ioctl() calls. On the ipw2x00
drivers, you can set the auth alg to LEAP, but it seems the firmware
handles the rest? I see a lot of LEAP code (eap-leap.c) in
wpa_supplicant, but what's the handling flow?
More information about the HostAP