Hi,
Based on the documentation for PREV_BSSID:
"previous BSSID, to be used in ASSOCIATE and CONNECT commands to
specify a request to reassociate within an ESS, i.e., to use
Reassociate Request frame"
But this actually isn't true when using CMD_CONNECT. The kernel does a
full re-connect if PREV_BSSID is provided (easily verified by kernel
logs which show an Authenticate frame being sent).
This is due to, in part, cfg80211_sme_connect() calling
cfg80211_get_conn_bss() which sets the connection state to
CFG80211_CONN_AUTHENTICATE_NEXT.
I tried hacking this to set it to CFG80211_CONN_ASSOCIATE_NEXT if
prev_bssid was set, but was unable to reassociate. I think the
CMD_CONNECT path just needs to call rdev_assoc directly if PREV_BSSID
is included? or some other modifications to cfg80211_sme_connect()?
Thanks,
James
Hi James,
Sorry, lost track of the mailing list a bit.
> "previous BSSID, to be used in ASSOCIATE and CONNECT commands to
> specify a request to reassociate within an ESS, i.e., to use
> Reassociate Request frame"
>
> But this actually isn't true when using CMD_CONNECT. The kernel does a
> full re-connect if PREV_BSSID is provided (easily verified by kernel
> logs which show an Authenticate frame being sent).
The authentication frame doesn't really have anything to do with whether
you use associate or reassociate? It's still required, unless you did
FT, but that's orthogonal?
Feels like it's working as designed?
johannes