On Fri, Mar 24, 2006 at 09:31:56PM +0000, David Woodhouse wrote: > wpa_supplicant appears to be aware of none of this -- it expects the > SSID to be precisely correct in the scan results after it does an active > probe for a specific SSID. Thus, it doesn't work when SSID broadcasting > is turned off unless I apply the hack at > http://david.woodhou.se/wpa_supplicant-hack.patch
wpa_supplicant does indeed require that the scan results are reported correctly. I don't see much point in the results if they are not correct.. It is unfortunate if you need to use this kind of patch since it would not work very well in cases where there is more than one BSSID with "<hidden>" reported as the SSID.. > Do we really expect to push this problem to userspace, or should the > kernel drivers be assuming for themselves that the probe response > _should_ have the same SSID as we actually probed for, then fixing it up > accordingly? I think that whoever is responsible for processing Beacon and Probe Response frames should report SSIDs correctly. In case this is done in kernel code (which is the case for more or less all Linux drivers at the moment), this would need to be in kernel (but can and should be shared with all drivers). As an example, Host AP driver keeps a local list of detected BSSes and it keeps a separate entry for each SSID to support multi-SSID configuration. SIOCGIWSCAN will then get list of all detected BSSID,SSID combinations with SSID field updated based on Probe Response for the cases where Beacon frame used an empty SSID (or had another SSID in case of multi-SSID). In case scanning is moved to user space, this process would happen in an user space application instead. -- Jouni Malinen PGP id EFC895FA - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
