wpa_supplicant_select_bss error?

a.brooks2 at marathon-targets.com a.brooks2
Mon Dec 16 18:23:00 PST 2013


Hi Dan,

I'm travelling at the moment so I can't test why wpa_scan_result_compar 
might be doing the wrong thing -- but I can confirm that while using two 
APs from the same vendor, one with terrible signal-strength was ordered 
ahead of one with good signal strength.


Alex

On 2013-12-17 03:03, Dan Williams wrote:
> On Sun, 2013-12-15 at 21:53 +1100, a.brooks2 at marathon-targets.com 
> wrote:
>> Hi,
>> 
>> I've been trying to track down why a client seems to connect to the
>> (significantly) weaker of two access-points with identical SSIDs, and
>> refuses to roam to the stronger one subsequently.
>> 
>> I think there might be an error in wpa_supplicant_select_bss:
> 
> Scan results are sorted when they arrive from the driver in
> wpa_supplicant_get_scan_results() using the wpa_scan_result_compar()
> function, a huge component of which is signal strength.  Thus, when
> wpa_supplicant_select_bss() returns the first matching AP, it should
> already be the best AP because the AP list has been sorted.
> 
> So I would concentrate your debugging on that function, and find out 
> why
> it decides your "better" AP is less usable than your "worse" AP.
> 
> Dan
> 
>> static struct wpa_bss *
>> wpa_supplicant_select_bss(struct wpa_supplicant *wpa_s,
>>                struct wpa_ssid *group,
>>                struct wpa_ssid **selected_ssid)
>> {
>>      unsigned int i;
>> 
>>      wpa_dbg(wpa_s, MSG_DEBUG, "Selecting BSS from priority group %d",
>>          group->priority);
>> 
>>      for (i = 0; i < wpa_s->last_scan_res_used; i++) {
>>          struct wpa_bss *bss = wpa_s->last_scan_res[i];
>>          *selected_ssid = wpa_scan_res_match(wpa_s, i, bss, group);
>>          if (!*selected_ssid)
>>              continue;
>>          wpa_dbg(wpa_s, MSG_DEBUG, "   selected BSS " MACSTR
>>              " ssid='%s'",
>>              MAC2STR(bss->bssid),
>>              wpa_ssid_txt(bss->ssid, bss->ssid_len));
>>          return bss;
>>      }
>> 
>>      return NULL;
>> }
>> 
>> 
>> The loop returns on the first BSS it finds with the appropriate ssid.
>> So the results depend on the order of the scan results.
>> In my case I have a client which happens to list the weaker BSS first,
>> so it does the wrong thing.
>> 
>> I think this loop should find the best BSS instead.  I made this 
>> change
>> and now my client happily connects to the correct BSS, and roams
>> appropriately.
>> 
>> I can submit a patch but thought I'd ask the question first (this code
>> seems to have been around for a while so I'm surprised no-one has 
>> found
>> it if it is in fact a bug), let me know.
>> 
>> 
>> 
>> Cheers,
>> 
>> Alex
>> _______________________________________________
>> HostAP mailing list
>> HostAP at lists.shmoo.com
>> http://lists.shmoo.com/mailman/listinfo/hostap



More information about the Hostap mailing list