On Fri, Feb 5, 2016 at 11:43 AM, Jouni Malinen <j@xxxxx> wrote:
> On Wed, Feb 03, 2016 at 12:33:16PM -0800, Naveen Singh wrote:
>> I was looking into the code for fast_connect from
>> wpa_supplicant_event_disassoc_finish and it looks like we try to
>> connect to same BSS. If it is trying to connect to same BSS how does
>> it helping us in solving band steering or load balancing problem. If
>> the connect request is invoked from wpas_select_network_from_last_scan
>> we may have a different BSSID and then I can understand it is trying
>> to connect to a different BSSID. Am I missing something here?
>>
>> if (fast_reconnect) {
>> #ifndef CONFIG_NO_SCAN_PROCESSING
>> wpa_dbg(wpa_s, MSG_DEBUG, "Try to reconnect to the same BSS");
>
> Please note that fast_reconnect is set only if
> disconnect_reason_recoverable() indicates that there is reason to
> believe the same AP would accept the STA back, i.e., this is not the
> band steering/load balancing case. This is the case where the AP drops
> an association due to inactivity or some unexpected state mismatch. The
> band steering/load balancing case goes through temporary blacklisting of
> the BSSID with which the STA was associated when the disconnection
> indication happened and an attempt to connect to the same ESS (i.e.,
> find another BSSID in the same ESS that is not blacklisted).
Yes I realized that as well. For test I actually disabled the piece of
code in connman that disables the entire network and re-connection to
AP was blazing fast.
>
> --
> Jouni Malinen PGP id EFC895FA
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
