[wpa_supplicant] - request for clarification

[Dan Williams]

On Thu, 2010-07-15 at 17:03 +0200, Lukasz Majewski wrote:
> Hello all,
> 
> I'm trying to understand the wpa_supplicant code (debian src. ver.
> 0.6.10). It is compiled with support for the wireless extensions
> (-Dwext).

There are different "drivers" to talk to different setups.  WEXT is one
driver, nl80211 is another, etc.

> Could someone explain to me why during the disconnection from access
> point (AP) (wpa_driver_wext_disconnect function) the bssid is set to
> null values and afterwards the ssid is modified (set to random numbers)
> by calling the wpa_driver_wext_set_ssid(drv, ssid, 32).

If you are a driver writer, you should be using the kernel's
nl80211/cfg80211 API, and *not* WEXT.  By implementing cfg80211 you also
get the WEXT compatiblity layer for free.

The reason the supplicant does this is to prevent drivers from
attempting to reconnect to the access point.  WEXT is not a rich enough
API and does not have a command to say "STOP!".  Instead, many drivers
will attempt to automatically reconnect to the AP when they get
disconnected.  This is good from a reconnection standpoint, but it's bad
when the controller (wpa_supplicant) actually wants the driver to just
stop doing anything and idle.

Sometimes drivers will attempt reconnection if the AP kicks the STA off
with a "too  many clients" or "wrong authentication method", but the
driver will keep retrying connection and start spamming userspace with
floods of IWAP disconnect events.  They can only be stopped by setting
the SSID to a random value with SIOCGIWESSID which asks the driver to
associate with that SSID.  That SSID does not exist, and thus the driver
will simply idle until the SSID is found in the scan list.

> Why ssid is set to random numbers? What is the purpose to feed the
> driver with random numbers to simulate the AP's valid SSID?  

The purpose is to stop the driver and make it idle.  Since the random
SSID is highly unlikely to exist, the driver will stop attempting to
reconnect to the previous SSID.

Again, WEXT is not flexible enough (and is underspecified) such that it
does not have a "STOP!" command.  Furthermore, sending SIOCSIWESSID with
a zero-length SSID can be interpreted to mean "connect to anything you
can find" which is clearly *not* what the supplicant wants the driver to
do.

The solution to all this is to write your driver for nl80211/cfg80211,
and send wpa_supplicant the "-Dnl80211" argument to use the newer,
richer, more future-proof kernel wireless API.

> What if after successful connection with AP (via WPA/WPA2) the
> connection is forced to be closed and after that it is started again and
> is supposed to connect to cached AP (with which connection has been set
> up previously)?

The supplicant controls scanning and association requests; if the AP
disconnects you (or you manually disconnect) then the supplicant will
start the rescan loop, find the previous AP, and ask the driver to
reconnect to it.  Operation is a balance of firmware behavior, driver
behavior, and supplicant behavior.  Most of the higher-level "smarts"
are performed by the supplicant.

> Can anyone explain why it is done like that?
> 
> And another aspect: If driver has received and interpreted random
> numbers as valid AP SSID, it will try to connect to this "random" AP.
> This attempt will fail, but time for this attempt is consumed anyway.

Correct.  Instead, use nl80211/cfg80211 in the driver which actually has
a "disconnect" command.  WEXT simply doesn't.

Dan