Bug in lbs_set_essid

[Jon Nettleton]

On Thu, Apr 1, 2010 at 10:16 AM, Dan Williams <dcbw at redhat.com> wrote:
> On Thu, 2010-04-01 at 08:50 -0700, Jon Nettleton wrote:
>> I was tracking down a scanning delay that was happening during resume
>> on my olpc XO 1.5, and came across this bug.  Note, during suspend the
>> card is completely powered down, so resume is a clean start with no
>> history.
>>
>> The card is powered up and initializes a full scan.  Channels 1-4 are
>> scanned and then an association request for any is initiated.  When
>> lbs_set_essid is called the SSID is set to garbage, so then the driver
>> tries to connect to this bogus SSID for a while until it gives up and
>> then finishes scanning the rest of the channels.
>
> If the SSID is coming from the supplicant then that's expected; sending
> the "any" BSSID and the bogus SSID is the only way with WEXT to ensure
> that the card is completely disassociated from anything, and isn't
> trying to reconnect to something that we dont' want it to connect to.
>
> Some drivers interpret a blank/zero-length SSID assoc request as "find
> anything to connect to, no matter what it is".  With WEXT there is
> simply no "disassociate and stop doing anything" command, so the bogus
> SSID + BSSID stand in for this.