Search Linux Wireless

Re: [RFC] nl80211: Authentication and association events

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[adding Kalle, Samuel]

On Thu, 2009-02-26 at 20:57 +0200, Jouni Malinen wrote:

> Actually, iwconfig works fine in my current version since it just uses
> the information from same functions that were used in
> net/mac80211/mlme.c. In other words, when I complete association with an
> external SME (wpa_supplicant), iwconfig can still show the BSSID etc.
> info.

Yes, I know, but we really want to move the wext stuff into cfg80211 and
then it won't really work this way any more.

> I'm now able to complete authentication and association in two steps and
> use only nl80211 for it (i.e., no WEXT code needed in driver_nl80211.c
> for auth/assoc/deauth/disassoc processing). The mlme.c changes are not
> the cleanest possible and there are still couple of places where mlme.c
> shows its SME nature by deciding to automatically do something, but
> other than that, this seems to be functional.

Sounds good. I guess we can do things piecewise...

One thing we were saying yesterday is that it might make more sense to
not do assoc w/o auth for those hardware that doesn't support it, but
rather add a new "connect" command instead so the distinction is
clearer. Not sure though.

Couple of thoughts. Trivial one: can the SSID really be 0 bytes as
documented? Does that make any sense?

Another thing I would like to do -- instead of passing this struct:

+struct cfg80211_auth_request {
+       struct ieee80211_channel *chan;
+       u8 *peer_addr;
+       const u8 *ssid;
+       size_t ssid_len;
+       enum nl80211_auth_type auth_type;
+       const u8 *ie;
+       size_t ie_len;
+};

why don't we pass a cfg80211_bss pointer and the IE info? That might
mean that cfg80211 would need to invoke scanning and have a small state
machine, but that seems reasonable. Then we inc the ref on that bss
struct and keep it around, so it stays in scan results too.

We'd probably need to change the event functions to include the BSS
pointer (if we want to allow multiple authentications to be in flight at
the same time) and whether the authentication was actually successful
(maybe we can parse that out of the reported frame).

The result of that is that we can
 * check, in MLME.associate, that we're already authenticated, and do it
   generically in cfg80211
 * keep around the BSS in scan results without having to add some extra
   code to drivers/mac80211 when we start filtering beacons
 * easily tell userspace what's going on

and we can keep around the BSS that we're associated with too for the
same reasons and to verify we're only on one BSS at a time and catch
userspace requesting a second one.

The other upside of this is that drivers will stop working entirely if
they do not provide the proper events, which is good because it means
all drivers will take great care to provide them.

johannes

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux