Hi Johannes,
On 09/15/2017 08:29 AM, Johannes Berg wrote:
On Fri, 2017-09-15 at 07:50 -0500, Denis Kenzior wrote:
E.g. if I CMD_CONNECT to AP1, then pre-authenticate to AP2 and
issue a CMD_CONNECT to AP2?
That's not something you can do with full-MAC cards?
Err, why not? Pre-Authentication runs over a 0x88c7 protocol. So
we should get these just like regular PAE frames. But forget
pre-authentication, one can still force a roam between BSSes within
the same ESS by specifying NL80211_ATTR_PREV_BSSID. At least that's
what the docs say ;)
Oh, you meant that kind of pre-authentication :-)
I thought you meant sending an 802.11 auth frame to the new AP before
breaking the connection to the old AP.
I mean 802.11-2012 Section 11.5.9.2 type preauthentication.
And AFAIK the kernel generates a disconnected event as soon as we send a
CMD_AUTHENTICATE, so not sure how you envision 'your' preauthentication
working...
However, you're not answering my question...
And even mac80211 doesn't really support pre-authentication (unless
you mean over-the-DS)
There's only one kind of preauthentication? Are you confusing this
with FT?
No, see above.
We use FT-over-Air just fine on mac80211 and on real hardware. We
even have an autotest for this based on mac80211_hwsim. FT-over-DS
should work as well.
Full macs don't support FT due to lack of
CMD_ASSOCIATE/CMD_AUTHENTICATE. Can we fix that btw?
Well, with full MAC devices you should let the device decide on the
BSS?
Why? So we can deal with the various ways a vendor firmware can screw
up? Besides, you have an asymmetry in the kernel API. One can use
regular roaming on a full mac but not FT.
Regards,
-Denis
