On 1/27/07, Larry Finger <[EMAIL PROTECTED]> wrote: > Paul Marks wrote: > > > > 0: 00:16:01:11:42:11 ssid='<hidden>' wpa_ie_len=26 rsn_ie_len=22 caps=0x11 > > skip - SSID mismatch > > > > That's definitely my access point, but as you can see, the driver > > never inserted the correct SSID. > > According to Dan Williams at RedHat, the insertion of "<hidden>" by ieee80211 > is wrong and no SSID > should be inserted. It may, however, be difficult to remove there. In that > case, I'll have to > recapture that message in bcm43xx and strip the faulty part out. >
>From what I read in wpa_supplicant, it looks like the driver is supposed to be inserting the AP's actual SSID there, once it knows what it is. > > When you connect to the AP's at Purdue with ndiswrapper, please send me the > output of 'iwlist s'. I > would like to see what the Windows driver and its MAC layer return. > I'm testing again just with my local access point, and when my SSID is hidden, ndiswrapper is only able to connect with wpa_supplicant in "ap_scan=2" mode. If I use "ap_scan=1", then my access point never shows up in any scans at all. If I use "ap_scan=2", then it immediately associates with my hidden SSID, and "iwlist eth1 scan" shows my AP, and it has the correct SSID filled in. Also of note, with bcm43xx, if I'm using my local AP, and set ap_scan=2, then wait a few seconds, and switch back to ap_scan=1, I'm able to associate. In this case, my access point does appear, with a correct SSID, in the scan output. My interpretation of this is that somehow, the call made by wpa_supplicant for ap_scan=2 causes the correct SSID to get inserted in the scan cache, so that when I switch back to ap_scan=1, it can match the SSID and connect to it. _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
