Re: RFC: WPA-related API changes

[Dan Williams <dcbw redhat com>]

On Wed, 2005-12-07 at 11:10 -0800, Jouni Malinen wrote:
> On Wed, Dec 07, 2005 at 12:58:08PM -0500, Dan Williams wrote:
> 
> > 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
> 
> wpa_supplicant uses enc_capa and if that is not present, falls back to
> assuming that everything is supported.

Though looking at the latest git netdev-2.6 tree, it appears that almost
no drivers support enc_capa...?  At least, airo, ipw2100, and ipw2200 do
not.  I doubt that atmel does either.  So we still need some sort of
fallback to detect what drivers do here.

> > 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.
> 
> If you are considering of using wpa_supplicant for getting scan result,
> it already does this parsing and reports supported types as a text field
> (e.g., [WPA-PSK-TKIP]).

Possibly.  But I seriously do _not_ want to parse scan results from text
that wpa_supplicant shoves over the socket.  If wpa_supplicant had a
dbus interface, that would be fine, and that's what we should work
towards.  But parsing text from wpa_supplicant here is just dumb; it's
fine for humans, but not for programs, for the reasons I've laid out
many times before.  a) error reporting, b) type safety, c) parsing
required, and d) harder and more error-prone to code for.

> > 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.
> 
> What part of this is more complicated than listening to netlink? Using
> wpa_ctrl.c from wpa_supplicant, this would involve something like this:
> 
> ctrl = wpa_ctrl_open(path);
> wpa_ctrl_attach(ctrl);
> fd = wpa_ctrl_get_fd(); /* for whatever eventloop/select/etc. is being
> 			 * used */
> 
> Whenever something is received from fd, compare the prefix to
> WPA_EVENT_CONNECTED/DISCONNECT, and if yes, there's the even you were
> waiting for..

For two reasons:

1) Drivers have historically sucked at netlink.  Yes, the drivers should
get fixed.  But there is no standard spec for when a driver says "I have
a link".

2) What does a "link" mean in a wireless context?  Does it mean that
you're associated with an access point?  Does it mean that you can pass
traffic to that access point?  Does it mean you have an IP address?

Users don't immediately care (or want to know) whether they have
successfully completed Shared Key Authentication or whether they've WPA2
pre-authed against an access point or not.  They care whether they can
Send Packets.  So from a purely hardware standpoint, yes, a netlink
"link" message means that the card is sending radio signals to the
access point.  That's fine.  But from a user-level (and therefore
NetworkManager), it's quite a bit more complicated to determine what a
"link" means.  We've chosen to make a link mean "I can send IP packets
successfully to this access point." 

One could even argue that a more user centric definition most of the
time would be "can I browse the web and send email", which would imply
not claiming a link unless we can actually pass packets to the general
internet and their configured mail server. Its actually a very common
problem that people think they're connected (because they can pass
packets to the gateway), but *so* many APs out in the wild won't
actually let you use them to access the internet (they require WWW or
other out of band auth, they aren't connected to the internet at all,
etc etc). But we're not pushing that extreme a view of connection at the
moment.

I think it's fine for us to have different opinions as to what "link"
means.  It serves our respective user communities better.
NetworkManager obviously needs to know what wpa_supplicant thinks the
link status is, and that forms a part of how NetworkManager decides that
there is a "link", just as it does now.

> > 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.
> 
> If someone were to report these issues to wpa_supplicant bugzilla, it
> might be possible that actually someone else were to fix them and you
> would not need to that ;-).

Yes, that's implied.  I don't think it's at all constructive to bitch
about problems in wpa_supplicant when we've all got problems.  When I
noted the issues with wpa_supplicant + airo, I was testing out an
earlier version and was not at the point where I was actually working on
wpa_supplicant integration.  When NetworkManager integrates with
wpa_supplicant in a usable manner (quite soon hopefully), I can assure
you that we'll likely uncover bugs with wpa_supplicant which will get
filed, many along with patches if we've done our homework.  I don't
anticipate black-boxing wpa_supplicant and simply whining when it
doesn't work, since that doesn't get anyone anywhere.

Dan