<div dir="ltr"><div>I have a similar (if not the same) issue where the AP list is not sorted. Additionally, the value for the current AP (when using hidden SSIDs) is never updated on subsequent scans.<br><br></div>Kurt<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 16, 2013 at 11:03 AM, Dan Williams <span dir="ltr"><<a href="mailto:dcbw@redhat.com" target="_blank">dcbw@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Sun, 2013-12-15 at 21:53 +1100, <a href="mailto:a.brooks2@marathon-targets.com">a.brooks2@marathon-targets.com</a> wrote:<br>
> Hi,<br>
><br>
> I've been trying to track down why a client seems to connect to the<br>
> (significantly) weaker of two access-points with identical SSIDs, and<br>
> refuses to roam to the stronger one subsequently.<br>
><br>
> I think there might be an error in wpa_supplicant_select_bss:<br>
<br>
</div>Scan results are sorted when they arrive from the driver in<br>
wpa_supplicant_get_scan_results() using the wpa_scan_result_compar()<br>
function, a huge component of which is signal strength. Thus, when<br>
wpa_supplicant_select_bss() returns the first matching AP, it should<br>
already be the best AP because the AP list has been sorted.<br>
<br>
So I would concentrate your debugging on that function, and find out why<br>
it decides your "better" AP is less usable than your "worse" AP.<br>
<span class="HOEnZb"><font color="#888888"><br>
Dan<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> static struct wpa_bss *<br>
> wpa_supplicant_select_bss(struct wpa_supplicant *wpa_s,<br>
> struct wpa_ssid *group,<br>
> struct wpa_ssid **selected_ssid)<br>
> {<br>
> unsigned int i;<br>
><br>
> wpa_dbg(wpa_s, MSG_DEBUG, "Selecting BSS from priority group %d",<br>
> group->priority);<br>
><br>
> for (i = 0; i < wpa_s->last_scan_res_used; i++) {<br>
> struct wpa_bss *bss = wpa_s->last_scan_res[i];<br>
> *selected_ssid = wpa_scan_res_match(wpa_s, i, bss, group);<br>
> if (!*selected_ssid)<br>
> continue;<br>
> wpa_dbg(wpa_s, MSG_DEBUG, " selected BSS " MACSTR<br>
> " ssid='%s'",<br>
> MAC2STR(bss->bssid),<br>
> wpa_ssid_txt(bss->ssid, bss->ssid_len));<br>
> return bss;<br>
> }<br>
><br>
> return NULL;<br>
> }<br>
><br>
><br>
> The loop returns on the first BSS it finds with the appropriate ssid.<br>
> So the results depend on the order of the scan results.<br>
> In my case I have a client which happens to list the weaker BSS first,<br>
> so it does the wrong thing.<br>
><br>
> I think this loop should find the best BSS instead. I made this change<br>
> and now my client happily connects to the correct BSS, and roams<br>
> appropriately.<br>
><br>
> I can submit a patch but thought I'd ask the question first (this code<br>
> seems to have been around for a while so I'm surprised no-one has found<br>
> it if it is in fact a bug), let me know.<br>
><br>
><br>
><br>
> Cheers,<br>
><br>
> Alex<br>
> _______________________________________________<br>
> HostAP mailing list<br>
> <a href="mailto:HostAP@lists.shmoo.com">HostAP@lists.shmoo.com</a><br>
> <a href="http://lists.shmoo.com/mailman/listinfo/hostap" target="_blank">http://lists.shmoo.com/mailman/listinfo/hostap</a><br>
<br>
<br>
_______________________________________________<br>
HostAP mailing list<br>
<a href="mailto:HostAP@lists.shmoo.com">HostAP@lists.shmoo.com</a><br>
<a href="http://lists.shmoo.com/mailman/listinfo/hostap" target="_blank">http://lists.shmoo.com/mailman/listinfo/hostap</a><br>
</div></div></blockquote></div><br></div>