On 27-10-17 22:10, Johannes Berg wrote:
Hi,
IIUC, mwifiex hasn't told the firmware to do anything at this point --
the -EALREADY check is practically the first thing it does within
connect(). So it just quits the connect() request and tries to carry on
as usual. It will only do something different if the upper layers tell
it to do so afterward (e.g., calling disconnect()).
Yeah, that makes sense.
Yes, that's definitely what's happening. And it's explicitly called out
in the supplicant's nl80211 driver that this is intentional:
[...]
Right.
This is the main code path for supplicant commands like "Reattach",
which boil down to (for non SME drivers):
wpas_request_connection()
...
-> wpa_supplicant_connect()
-> wpa_supplicant_associate()
-> wpas_start_assoc_cb()
-> wpa_drv_associate()
-> wpa_driver_nl80211_associate()
-> wpa_driver_nl80211_connect()
Now for the part I'm not so familiar with: is this really the *expected*
flow for full-MAC drivers in reattach, reassociate, and roaming flows?
All of those seem to boil down to this same connect() (and fallback to
disconnect()+connect() if -EALREADY) flow.
We never implemented a "ROAM" command, so there's not all that much
choice.
But it doesn't seem like all full-MAC drivers do the same thing. Some
seem to just blaze ahead with a connect attempt (maybe some firmwares
automatically interpret this for us?) and never return -EALREADY at all.
Agree, some seem to just do some form of roaming on this, which really
just means they disconnect internally - or perhaps they even try to
roam if it's the same network?
Sorry if this is slightly off-topic, but I'm trying to understand what
the general expectations are here, based on my relatively narrow
experience with a few drivers.
I don't really know either! There aren't that many direct cfg80211
drivers that don't use mac80211, so there's not that much experience.
You're probably well positioned to say what the behaviour _should_ be
though? :-)
I tend to think we should actually do the EALREADY from cfg80211, so
that wpa_s will always be forced to go through this roundabout code
path, but also finally implement a ROAM command, to let drivers have
that option?
Note also that we've always sort of envisioned that drivers
implementing CONNECT would do BSS selection themselves, but I think
there's no automatic way of doing that with wpa_s, and it may not even
be desirable in many cases (unless you really need the power saving
advantage) since it gets us into a situation where we have all these
different algorithms etc.
wpa_s can issue a CONNECT without bssid (nor bssid_hint) leaving it up
to the driver to select the BSS. I am pretty sure I hit that scenario
although not sure what exact criteria are for wpa_s. Maybe it depended
on WIPHY_FLAG_SUPPORTS_FW_ROAM.
Regarding BSS selection I added bss_select feature. An effort which
actually was triggered by a chromebook project. Guess the number of
drivers implementing that can be counted on one ...finger ;-)
Regards,
Arend
