On Tuesday 24 May 2011 00:00:47 JD wrote: > On 05/23/11 15:41, Tim Smith wrote: > > On Monday 23 May 2011 22:26:49 JD wrote: > >> On 05/23/11 12:22, Tim Smith wrote: > >>> On Monday 23 May 2011 17:50:50 JD wrote: > >>>> On 05/23/11 09:28, Tim Smith wrote: > >>>>> On Monday 23 May 2011 16:36:00 Tim wrote: > >>>>> Not really. This is SSID, not BSSID (BSSID is usually the MAC of > >>>>> the AP). When you scan, you not only listen for beacons, but you > >>>>> (should) send probe requests. If you put an SSID into your probe > >>>>> request, you will get a response only from a BSS with a matching > >>>>> SSID, so you broadcast saying "network named 'MyHouseNetwork' > >>>>> please respond" at which point you get the response from the real > >>>>> BSS which has the real SSID in it and not the bogus one that went > >>>>> in the beacons. > >>>> > >>>> Well, I have placed wpa_supplicant in full debug verbosity > >>>> output mode, and it's probe/scan does not seem to be aimed > >>>> at just my router. In fact it gets usually 3 to 5 responses > >>>> from which it then selects my AP. > >>>> The wpa_supplicant.conf has the SSID and the BSSID in the > >>>> configuration. So, how come the probe/scan gets more than > >>>> one response? > >>> > >>> Well, note I said "If" :-) > >>> > >>> If you do not place ANY SSID into the probe request, then all > >>> networks will respond. Depending on the configuration of a > >>> multi-SSID AP you may see more than one probe response from the same > >>> MAC address in this case. Or not. That may be up to the guy who runs > >>> the network(s) or it may be a hard-coded behaviour of the APs being > >>> used. > >>> > >>> See the scan_ssid parameter for wpa_supplicant for how to change > >>> wpa_supplicant's behaviour in this respect. > >> > >> You did not show the part where I said that > >> my router's BSSID and the nets SSID are in > >> wpa_supplicant.conf. > >> So, I am asking how come the wpa_supplicant > >> is not aiming it's probe directly at that BSSID > >> and SSID coded in the config file? It seems to > >> me that it should do that. > > > > I wrote: > >>> See the scan_ssid parameter for wpa_supplicant for how to change > >>> wpa_supplicant's behaviour in this respect. > > > > Seriously. wpa_supplicant won't do that unless you change that > > parameter. Though of course you don't say whether that parameter is > > set, so you might have it set and I didn't know that, in which case it > > seems like you might have found a bug in wpa_supplicant (I'm assuming > > you have a sniffer trace of the probe request off the air to verify > > this. Call me old-fashioned and paranoid but I never *quite* trust a > > program's own debug output without independent verification :-) > > > > > From /usr/share/doc/wpa_supplicant-0.6.8/wpa_supplicant.conf: > > # scan_ssid: > > # 0 = do not scan this SSID with specific Probe Request frames > > (default) # 1 = scan with SSID-specific Probe Request frames > > (this can be used to # find APs that do not accept broadcast > > SSID or use multiple SSIDs; # this will add latency to > > scanning, so enable this only when needed) > > My conf file for my net has > scan_ssid=1 > > So, does that mean it will/will not send the ssid as part of the probe? According to its documentation, it will be doing that. If it isn't then either the documentation or the program is wrong. The source for 0.6.10 looks like it's doing the right thing there (just had a quick look, not a detailed inspection). OTOH, a quick check with 0.6.8 and a sniffer reveals that this is badly bugged there - the probe request comes out with non-broadcast SSID all right but it's complete gibberish. I'm not sure whose fault that is though. It could easily be the rather odd driver I'm using there - it's not production code because I'm normally mucking with the wireless chip firmware in rude and interesting ways. Definitely worth checking with a sniffer to see what your system is doing... -- But while the ant gathered food, the grasshopper contracted to a point on a manifold that was NOT a 3-sphere... -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
