Re: RFC: WPA-related API changes

[Dan Williams <dcbw redhat com>]

On Wed, 2005-12-07 at 12:35 -0500, Robert Love wrote:
> On Wed, 2005-12-07 at 12:32 -0500, Dan Williams wrote:
> 
> > Right, I'll land some API breaking patches I've got lying around then to
> > start converging with wireless-tools constants.
> 
> Great.
> 
> After these API changes, what is next wrt WPA support?

Part of the convergence with wireless-tools is to better support the WPA
stuff so that we have a clear mapping between the parameters we use for
auth, encryption algorithm, and WPA to wireless-tools and
wpa_supplicant.

Immediately after this, we need to determine the capabilities of the
drivers, through two methods:

1) Use the enc_capa field in the iw_range info for the driver to
determine WPA capabilities.  Not many drivers support this yet.

2) If that fails, figure out what calls wpa_supplicant makes to detect
WPA capability and do that in NetworkManager

Next, we need to do a more intelligent parsing of the WPA and RSN IE
fields that come in beacon packets from access points (some of which is
already present) to determine which access points have WPA and WPA2
capability, and which algorithms they support.

Once we get capabilities down correctly, we need to make the applets
understand these extended capabilities, so that they can provide correct
user feedback, and prevent users from trying WPA on a non-WPA capable
card, and from trying WPA with a non-WPA access point.  To provide the
best experience, we need to do this as close to the user as possible, ie
in the applets.

Once we've got all this information, and made the API changes, we can
then write out the correct conf files for wpa_supplicant.

Next, we need to connect to wpa_supplicant's socket for a particular
interface, and monitor its association status to determine when we've
successfully connected, and when the card is disconnected.  That's a lot
more complicated than just listening to netlink.  This is where a
DBUS-enabled wpa_supplicant would come in quite handy.

We could also just use wpa_supplicant for all connections, even WEP and
unencrypted connections.  This is compelling because it removes quite a
bit of code from NetworkManager's device activation process, but it also
introduces regressions which we'd have to fix in wpa_supplicant (some
WEP issues with airo driver for example).  A case of two steps forward,
much pain for a month.

I've got some of these changes locally, and a few bits are already in
NM.  Anyone is welcome to step up if they've got some time and/or
patches.

Dan