Re: attempt to scan fails (device busy) if essid/ssid was changed recently

[Dan Williams <dcbw@redhat.com>]

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