> For quite a while now (not sure I can tell exactly for how long) we
> see issues in association and scan list.
> We send probe before authentication, get the probe response but never
> send the authentication.
> Moreover a lot of entries in the BSS list are duplicated.
>
> I began to look at it and ended up to understand that these 2 issues
> are related: we just can't find an existing BSS in the BSS table.
> Obviously this causes the second issue. The reason was it breaks the
> association is that ieee80211_probe_auth will never be able to find
> the IEs of the probe response since we couldn't fetch the BSS when we
> parsed the probe response. In short:
>
> if (auth_data->bss->proberesp_ies) {
> always return false.... and we fall back to send yet another probe request.
>
> As you probably know, the BSS table is implemented with an Red Black
> Tree which requires its elements to be comparable. The compare
> function compares the BSSID which is not always unique (there can be
> several SSIDs on the same BSSID), so all the IEs are also compared.
> But is this a good idea ?
> It seems that since the IEs of an BSS may change from time to time
> this compare function is not consistent...
Oops. Stupid me. Just noticed that we compare the SSID only...
So how come ?
>
> Just for playing I always return a positive value in cmp_bss (to have
> all the nodes serialized and avoid the possibility to miss a existing
> node) and don't rebalance the tree after insertion... the bug
> disappeared.
>
> Thought ?
>
> Emmanuel Grumbach
> egrumbach@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
