Re: RFC: WPA-related API changes

[Jouni Malinen <jkmaline cc hut fi>]

On Wed, Dec 07, 2005 at 03:11:17PM -0500, Dan Williams wrote:

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

That's correct; most drivers do not support enc_capa at the moment. One
could try to start configuring WPA and then see whether driver reports
error. However, it is not always that clear whether it really means that
WPA is not supported or that the operation is just not allowed at the
current state (e.g., I would say it would be fine to reject TKIP/CCMP
key configuration when not associated).

I would believe that it would be better use of time to add enc_capa
support to drivers than to try to figure out a reliable way of detecting
whether driver supports particular feature of WPA by trial and error.

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

I don't necessarily fully agree with this, but I do understand your point.

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

OK, I misunderstood your previous comment. This topic is actually being
discussed on netdev and hopefully, there will be a solution that allows
all the necessary information to be retrieved easily.

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

Access points do not necessarily have IP address at all, but something
related to having a suitable protocol address and maybe being able to
send data packets to default gateway (if configured) would cover most
cases.

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

Agreed. wpa_supplicant reports that connection is completed once all
encryption keys needed to send/receive unicast and broadcast frames are
in place. In other words, this would the point when layer 3 addresses
should be acquired by some mechanism.

-- 
Jouni Malinen                                            PGP id EFC895FA