On Fri, 05 Feb 2010 12:12:39 -0800 Renee Danson Sommerfeld <renee.sommerfeld at sun.com> wrote:
> On Fri, Feb 05, 2010 at 09:47:14AM +0000, Alan Maguire wrote: > > On 05/02/2010 07:14, Michael Hunter wrote: > > >On Thu, 04 Feb 2010 15:02:35 -0800 > > >Renee Danson Sommerfeld<renee.sommerfeld at sun.com> wrote: > > > > > >>I found this small bug while doing manual test 3, AP selection. I've > > >>tested this fix and verified that this test now passes. Please let me > > >>know what you think! > > >> > > >>http://jurassic.sfbay/~okie/webrev.14377/ > > >ncu_phys.c:908 I'm not sure I follow this. In this past the code was > > >such that if the essid didn't match we continued. Now the essid might > > >not match but the bssid could and we would get through. > > This was the intent; I wanted cases where the scan result did not > include an ESSID (and thus the ESSID match was guaranteed to fail) > but we had a matching BSSID in the known wlan's list to go through. There are APs which support multiple ESSIDs and multiple BSSIDs (the Cisco ones that run IOS for example). So you can't assume a 1:1 mapping between BSSID and ESSID. > > > Good point - I'm not sure if BSSIDs are guaranteed to be unique They are not. > > between different WLANs (they are mostly the AP's MAC addresses > > in practice, but there are exceptions). Checking if > > cur_wlan->nww_essid is blank (indicating a non-ESSID-broadcasting > > WLAN) as well might be worthwhile to be on the safe side, i.e. > > This is a good suggestion. I've updated the webrev (with this change > and also a comment to help explain this check); still needs testing, > but feel free to take a look. This looks good. Michael > > -renee
