Re: mac80211 auth/assoc in multi-channel scenarios

[Johannes Berg <johannes@sipsolutions.net>]

On Tue, 2012-06-26 at 21:18 +0300, Arik Nemtsov wrote:

> > And now this is just why it won't work even if we start from a clean
> > slate -- I haven't even talked about the backward compatibility aspect,
> > running an old supplicant on a driver that expects a ROC. Remember that
> > the driver need not give the virtual interface *any* channel time on the
> > right channel before needed, so if there's something going on on another
> > channel with multi-channel, that vif would never be able to authenticate
> > with an old supplicant.
> 
> Well that's a given, if we're introducing new features into hostap to
> support multi channel.

No, not really -- I'm going to want to rely on this mechanism even for
the single-channel case in our driver, everything else would be more
like a collection of hacks :-)

> > I could also mention how this is a stupid userspace API, you're now
> > requiring to call one thing before another call is valid, but then the
> > other call is only very briefly valid? If we really wanted ROC, we
> > should embed the time for it into the auth/assoc request, I'd say.
> 
> I think all these examples are because of our different definitions
> for ROC. If ROC is a recommendation, then we just start the ROC before
> starting the connection, and end it after the last EAPOL.
> If channel management is implemented in SW, what you're saying is a
> must. But the FW can abstract these details. Maybe we should do this
> similar to SW/HW scan in mac80211?

Well, I understand your point, but I don't think it's that simple. If,
as you say, we define this to be a recommendation, then we will require
device support for this. You may have that, but with what we're
currently seeing from our firmware I don't think it's possible to
implement it as a recommendation. Even if I could get it somehow
implemented in our device and/or the driver, we'd still be making more
assumptions than I'd want to make for this.

> > Thinking about that though -- what for connect() calls? Whole new can of
> > worms ...
> 
> Not sure what you mean here.

nl80211 connect call, where the driver is managing both auth/assoc,
sometimes even BSS selection.


> > Yes, but it would need this patch and a change to hostapd to add the
> > station when it sends the first auth frame:
> > http://johannes.sipsolutions.net/patches/kernel/all/LATEST/005-nl80211-full-sta-state.patch
> 
> Ah this is useful on another level as well. Today we have a hack in
> the driver to identify the auth-frame reply and add the STA to FW
> temporarily :)

Yes, I know. It's also useful to address a few other races, it just
needs a hostapd implementation. Want to work on it? :-)


johannes