[resend; I apparently forgot a subject the first time...] While debugging why ipw2200 and wpa_supplicant would not connect to a hidden access point today even with scan_ssid=1, I ran into an interesting scan behavior question. The root of the problem was that since the ipw2200 driver aggressively rescans when it doesn't find the requested AP in it's list, and since it only allows one scan at a time, wpa_supplicant's specific SSID scans just happened to get rejected every time, which means the card never sent out probe requests for the hidden SSID I wanted to associate with. There are more general issues here than just ipw2200 though. Most of the fullmac drivers (counting ipw2x00 here) don't handle multiple scan requests very well. I'm not entirely sure what mac80211 does here but it probably doesn't have extremely sophisticated scan result handling either. At startup In the ideal case, the driver would add each separate scan request to a queue, execute each request in turn (respecting each requests options like active/passive, dwell time, SSID/BSSID, channel list, etc). Each request would trigger a corresponding scan completion event. Perhaps multiple identical scan requests (ie, a few 'iwlist <iface> scan') could be batched together for efficiency. With nl80211/cfg80211, perhaps each individual scan request would have a UID to match it up with a specific scan response (but the response would still be broadcast too). Less invasive fixes could be made to ipw2200, like caching the last SSID-specific request and instead of triggering a general scan the next time, trigger a direct scan. A workaround but not a real fix. Thoughts? How should a second, different scan request be handled while another is already in flight? Dan - To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
