On Tue, 2009-04-07 at 15:51 +0300, Maxim Levitsky wrote: > On Tue, 2009-04-07 at 10:18 +0200, Johannes Berg wrote: > > On Tue, 2009-04-07 at 03:00 +0300, Maxim Levitsky wrote: > > > > > I noticed that always first attempt at scan fails when NM asks for scan. > > > I also noticed that this happens with quite recent kernels (I think > > > 2,6.28) didn't have this behavior. > > > > I'm pretty sure it did. > I am sure that on older kernel there was no -EBUSY error returned to > userspace. It probably just stalled the client. > > > > > > > Looking a bit deeper I discovered that each time NM disconnects from a > > > networks it sets random ssid/essid to the card (using wireless > > > extensions) > > > > This forces a scan > > > > > After that scan fails for some time. > > > > > > as a NM free example you can run > > > > > > iwconfig wlan0 essid dummy > > > iwlist scan > > > > and then this fails with EBUSY. > Thanks for explanation. > Since NM has its reasons to clear essid (to prevent unwanted > association), then what can be done to prevent this (and still use > wireless extensions, since nl80211 support isn't yet mature)? Honestly I think this should be handled by the driver or wpa_supplicant. Recent supplicant versions will already send a bogus SSID and BSSID to the driver when a forced disconnection happens, but that's not enough to stop some drivers like 2.6.27's iwl3945 from continually attempting reconnection to an SSID in other cases. The problem is that wext has no mechanism for saying "stop doing whatever you're doing dammit and wait for me to tell you what to do next". I guess that would really be !IFF_UP, but of course you can't scan then on most parts. In the end, I'm probably going to patch the supplicant to handle this and remove that code from NM. It's really old code and things have moved on since then. 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
