SIOCSIWESSID + SIOCSIWAP behaviour

SIOCSIWESSID + SIOCSIWAP behaviour

[Daniel Drake]

Hi Jean,

I'd just like to check my understanding (and softmacs implementation) 
of SIWESSID and SIWAP behaviour, for managed mode.

When SIWESSID happens, softmac drops association/authentication with the 
current network and then starts a scan for the requested SSID. When 
found, softmac authenticates and associates to that network.

When SIWAP happens, softmac drops association/authentication with the 
current network and then starts a scan for the requested BSSID. When 
found, softmac authenticates and associates to that network.

Is it correct that both of these immediately trigger 
deauthenication+deassocation then authentication+assocation?

Is it correct that SIWAP can legally select *any* AP? (As opposed to 
only being for selecting a specific AP *on the ESS* indicated by a past 
or future SIWESSID call)


Right now, wpa_supplicant does SIWESSID and SIWAP in quick succession, 
which causes softmac to associate twice, and that quickly confuses things.

No matter how I think of it, this strikes me as a hard interface to 
implement. Because association isn't an atomic operation, it is tricky 
to get the sequencing right, e.g. if the user does SIWESSID to start 
association, and then SIWAP to select a different AP before the original 
association has completed.

Any clarification appreciated.

Thanks,
Daniel

Re: SIOCSIWESSID + SIOCSIWAP behaviour

[Dan Williams]

On Mon, 2006-05-15 at 00:29 +0100, Daniel Drake wrote:
> Hi Jean,
> 
> I'd just like to check my understanding (and softmacs implementation) 
> of SIWESSID and SIWAP behaviour, for managed mode.
> 
> When SIWESSID happens, softmac drops association/authentication with the 
> current network and then starts a scan for the requested SSID. When 
> found, softmac authenticates and associates to that network.
> 
> When SIWAP happens, softmac drops association/authentication with the 
> current network and then starts a scan for the requested BSSID. When 
> found, softmac authenticates and associates to that network.

I'll chime in too... My understanding of WE is that your understanding
of WE is correct.  But if the user has already set the SSID and _then_
sets the BSSID, the driver must attempt to associate with an AP that has
_both_ those properties.  Setting one doesn't cancel the other out
(Jean, correct if I'm wrong here?)  AFAIK, you can actually set any old
BSSID you like on the access point, so there's no guarantee that the
BSSID any access point advertises is unique.  Furthermore I believe you
can have one AP with one BSSID server more than one ESSID.  Higher-end
Cisco/3Com/etc products allow this.

> Is it correct that both of these immediately trigger 
> deauthenication+deassocation then authentication+assocation?

Correct.

> Is it correct that SIWAP can legally select *any* AP? (As opposed to 
> only being for selecting a specific AP *on the ESS* indicated by a past 
> or future SIWESSID call)

Correct.  The user may SIWAP _any_ BSSID at all, not necessarily related
to the SSID.  However, if the user just set an ESSID with SIWESSID, I'm
fairly sure that ESSID must be honored as well.

> Right now, wpa_supplicant does SIWESSID and SIWAP in quick succession, 
> which causes softmac to associate twice, and that quickly confuses things.

(I don't really understand why wpa_supplicant uses SIWAP when a BSSID
isn't specified in the config file, but...)

How does that confuse things?  My understanding of most of the other
non-softmac drivers is that the SIWESSID sets the required SSID, then
the SIWAP sets the required BSSID, and that only if that ESSID is _also_
a member of the BSSID, then the association is permitted to happen.  The
options are cumulative.  If the user happens to set an ESSID and then a
BSSID that doesn't actually contain that ESSID, user==stupid and the
card can't do anything.

One may reset/unlock the ESSID to "any" by setting the "flags" member of
0 in the IWESSID request.  The user can also reset/unlock the BSSID to
any by setting the BSSID in the request to all 0x00 or all 0xFF.

If a user app gets confused by disassociation events to userspace, the
app needs to get fixed.

> No matter how I think of it, this strikes me as a hard interface to 
> implement. Because association isn't an atomic operation, it is tricky 
> to get the sequencing right, e.g. if the user does SIWESSID to start 
> association, and then SIWAP to select a different AP before the original 
> association has completed.

Hmm, what problems does this have?  It's not really any different than
if the user issues two SIWESSID calls in short sequence, so you have to
handle the start assoc->disassoc->start assoc sequence anyway...

Dan

Re: SIOCSIWESSID + SIOCSIWAP behaviour

[Jouni Malinen]

On Sun, May 14, 2006 at 11:29:38PM -0400, Dan Williams wrote:
> On Mon, 2006-05-15 at 00:29 +0100, Daniel Drake wrote:
> > When SIWESSID happens, softmac drops association/authentication with the 
> > current network and then starts a scan for the requested SSID. When 
> > found, softmac authenticates and associates to that network.

I don't think there is requirement for doing a new scan here if recent
scan results are available.

> > When SIWAP happens, softmac drops association/authentication with the 
> > current network and then starts a scan for the requested BSSID. When 
> > found, softmac authenticates and associates to that network.

Same here. Neither of these commands should drop IEEE 802.11
authentication. I would say that neither should drop association either
until a new association is available or it is clear that current
configuration does not allow association to be created. First case would
just report a new association (no disassociation reported) and second
case would report disassociation to user space.

> > Right now, wpa_supplicant does SIWESSID and SIWAP in quick succession, 
> > which causes softmac to associate twice, and that quickly confuses things.
> 
> (I don't really understand why wpa_supplicant uses SIWAP when a BSSID
> isn't specified in the config file, but...)

There are two different modes and what is being described here is
ap_scan=1, i.e., wpa_supplicant being responsible for requesting
scanning and selecting an AP. In this mode, it is actually assumed that
the driver does not do extra scans with SIWAP or SIWESSID.
wpa_supplicant is telling the driver which channel (SIOCSIWFREQ), SSID,
and BSSID to use.

In the other mode, ap_scan=2, wpa_supplicant is only configuring the
SSID and requesting the driver (or well, kernel side 802.11 management
code) to figure out which AP to use.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: SIOCSIWESSID + SIOCSIWAP behaviour

[Dan Williams]

On Mon, 2006-05-15 at 06:16 -0700, Jouni Malinen wrote:
> On Sun, May 14, 2006 at 11:29:38PM -0400, Dan Williams wrote:
> > On Mon, 2006-05-15 at 00:29 +0100, Daniel Drake wrote:
> > > When SIWESSID happens, softmac drops association/authentication with the 
> > > current network and then starts a scan for the requested SSID. When 
> > > found, softmac authenticates and associates to that network.
> 
> I don't think there is requirement for doing a new scan here if recent
> scan results are available.

Yeah, thought that was understood.  No reason to do another scan if you
just did one in the driver 5 seconds ago.

> > > When SIWAP happens, softmac drops association/authentication with the 
> > > current network and then starts a scan for the requested BSSID. When 
> > > found, softmac authenticates and associates to that network.
> 
> Same here. Neither of these commands should drop IEEE 802.11
> authentication. I would say that neither should drop association either
> until a new association is available or it is clear that current
> configuration does not allow association to be created. First case would

I assume that by "or it is clear that the current configuration does not
allow association to be created" means that the driver cannot find an AP
matching both the ESSID and the BSSID the user set, right?  If so, then
quite correct, the driver shouldn't disassociate until it's certain that
the current user-specified configuration (ie, any combination of ESSID
and BSSID set) does not apply to any known access points in the scan
list.

It's perfectly legal to send a new SIWAP event with a different BSSID if
the driver simply associates with a new access point in the same ESSID
too.  In this case, the driver does _not_ need to send a blank SIWAP
disassoc event to userspace, since it's staying within the same ESSID.

I think at this point I'm still still assuming that APs with the same
ESSID are on the same network by default.  Although that's not entirely
valid, especially in the realm of consumer gear (multiple 'linksys' APs
on the same channel even, each with different upstream connection), in
this case the user space application will have to know to lock the BSSID
of the card/driver to the one it wants.  That's a user space issue, not
a driver issue.  Driver's shouldn't be too smart about this stuff
without providing standard overrides.

> configuration does not allow association to be created. First case would
> just report a new association (no disassociation reported) and second
> case would report disassociation to user space.

If no association has been completed yet before the user sets SIWESSID
or SIWAP, then of course no disassociation event needs to get sent to
userspace because there's been no association from which to
disassociate.

I believe the following sequence is correct:

boot
user app issues SIWESSID 'foo'
driver finds associates/authenticates to 'foo'
  (if not available, it Just Does Nothing)
  (if available, sends SIWAP of '<whatever foo is>' to userspace)
user app issues SIWAP '12:34:56:78:91:23'
driver sends SIWAP of 00:00:00:00:00:00 (disassoc) to userspace
driver finds and associates with '12:34:56:78:91:23'
  (if not available, it Just Does Nothing)
  (if available, sends SIWAP of '12:34:56:78:91:23' to userspace)

Similarly, I believe the following is correct:

boot
user app issues SIWESSID 'foo'
driver searches for 'foo' but does not find it
  (if driver does background scanning and finds 'foo', it may associate)
  (if driver does not do background scanning, must wait until user
     app requests a scan, and if 'foo' is in results, may associate)
user app issues SIWAP '12:34:56:78:91:23'
  (no SIWAP driver disassoc event needed because no association exists)
driver finds and associates with '12:34:56:78:91:23'
  (if not available, it Just Does Nothing)
  (if available, sends SIWAP of '12:34:56:78:91:23' to userspace)

Dan

Re: SIOCSIWESSID + SIOCSIWAP behaviour

[Jean Tourrilhes]

On Sun, May 14, 2006 at 11:29:38PM -0400, Dan Williams wrote:
> On Mon, 2006-05-15 at 00:29 +0100, Daniel Drake wrote:
> > Hi Jean,

	Hi,

	Nice discussion you got going here ;-)

> > I'd just like to check my understanding (and softmacs implementation) 
> > of SIWESSID and SIWAP behaviour, for managed mode.
> > 
> > When SIWESSID happens, softmac drops association/authentication with the 
> > current network and then starts a scan for the requested SSID. When 
> > found, softmac authenticates and associates to that network.
> > 
> > When SIWAP happens, softmac drops association/authentication with the 
> > current network and then starts a scan for the requested BSSID. When 
> > found, softmac authenticates and associates to that network.
> 
> I'll chime in too... My understanding of WE is that your understanding
> of WE is correct.

	Yes.
	There is one case where you don't need to reassociate : if you
already have the correct ESSID or BSSID. This mostly happens when you
set the ESSID to any or the BSSID to off or any.
	Also, Jouni is correct that you don't need to scan if your
scan results are fresh enough.

>  But if the user has already set the SSID and _then_
> sets the BSSID, the driver must attempt to associate with an AP that has
> _both_ those properties.  Setting one doesn't cancel the other out
> (Jean, correct if I'm wrong here?)

	Correct.

>  AFAIK, you can actually set any old
> BSSID you like on the access point, so there's no guarantee that the
> BSSID any access point advertises is unique.  Furthermore I believe you
> can have one AP with one BSSID server more than one ESSID.  Higher-end
> Cisco/3Com/etc products allow this.

	I believe the BSSID has to be unique. HP APs can also offer
multiple ESSID for the same BSSID, but they do so using different
BSSID. If you look at the 802.11 spec, I can't see how two different
virtual cells can have the same BSSID, because the BSSID is the only
thing that identify the cell (the ESSID is not in each packet).

> > Is it correct that SIWAP can legally select *any* AP? (As opposed to 
> > only being for selecting a specific AP *on the ESS* indicated by a past 
> > or future SIWESSID call)
> 
> Correct.  The user may SIWAP _any_ BSSID at all, not necessarily related
> to the SSID.  However, if the user just set an ESSID with SIWESSID, I'm
> fairly sure that ESSID must be honored as well.

	The main configuration is SIWESSID, that's the only config
that is required by the standard. WIWAP is only a secondary
configuration, that is optional and not supported in all drivers. The
ESSID set should always be respected.
	If an ESSID is set, SIWAP should only look within APs having
this ESSID, and not use a different ESSID. Only if the ESSID is set to
'any' should the card really pick any AP regardless of ESSID.
	Personally, I think that SIWAP is too tricky to use properly
for most users, so we should encourage them to not use it.

> > No matter how I think of it, this strikes me as a hard interface to 
> > implement. Because association isn't an atomic operation, it is tricky 
> > to get the sequencing right, e.g. if the user does SIWESSID to start 
> > association, and then SIWAP to select a different AP before the original 
> > association has completed.
> 
> Hmm, what problems does this have?  It's not really any different than
> if the user issues two SIWESSID calls in short sequence, so you have to
> handle the start assoc->disassoc->start assoc sequence anyway...

	I agree that it make things messy in the driver. I also agree
that the user can do stupid things with iwconfig, and therefore there
is no real difference.
	There is still a performance issue. Having to cancel and
restart associations waste CPU cycles. One way to deal with that would
be to improve the "commit" strategy of the Wireless API. Basically,
every time you do a set, you schedule or reschedule the "commit" ioctl
to happen in a few dozen ms. This way, you could bundle all the
settting of apps such as wpa_supplicant with only a single
commit. This is similar to the way the routing API works.
	But, you won't get away that end-users can do stupid stuff
with iwconfig.

> Dan

	Have fun...

	Jean

Re: SIOCSIWESSID + SIOCSIWAP behaviour

[Jouni Malinen]

On Mon, May 15, 2006 at 01:28:13PM -0700, Jean Tourrilhes wrote:

> 	I believe the BSSID has to be unique. HP APs can also offer
> multiple ESSID for the same BSSID, but they do so using different
> BSSID. If you look at the 802.11 spec, I can't see how two different
> virtual cells can have the same BSSID, because the BSSID is the only
> thing that identify the cell (the ESSID is not in each packet).

What the standard says is somewhat irrelevant since there are APs that
use multiple SSID with the same BSSID. I would say that it is reasonable
for users to expect that this works with Linux, too.

> 	Personally, I think that SIWAP is too tricky to use properly
> for most users, so we should encourage them to not use it.

Keep in mind that it is also used by some programs (e.g., wpa_supplicant
in ap_scan=1) without the user having to know anything about that level
of details..

> 	There is still a performance issue. Having to cancel and
> restart associations waste CPU cycles. One way to deal with that would
> be to improve the "commit" strategy of the Wireless API. Basically,
> every time you do a set, you schedule or reschedule the "commit" ioctl
> to happen in a few dozen ms. This way, you could bundle all the
> settting of apps such as wpa_supplicant with only a single
> commit. This is similar to the way the routing API works.

Number of drivers use an atomic "associate" command (usually, a private
ioctl) with wpa_supplicant. If there were a standard way of doing that,
it could be helpful.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: SIOCSIWESSID + SIOCSIWAP behaviour

[Jean Tourrilhes]

On Mon, May 15, 2006 at 02:40:14PM -0700, Jouni Malinen wrote:
> On Mon, May 15, 2006 at 01:28:13PM -0700, Jean Tourrilhes wrote:
> 
> > 	I believe the BSSID has to be unique. HP APs can also offer
> > multiple ESSID for the same BSSID, but they do so using different
> > BSSID. If you look at the 802.11 spec, I can't see how two different
> > virtual cells can have the same BSSID, because the BSSID is the only
> > thing that identify the cell (the ESSID is not in each packet).
> 
> What the standard says is somewhat irrelevant since there are APs that
> use multiple SSID with the same BSSID. I would say that it is reasonable
> for users to expect that this works with Linux, too.

	Yeah, I guess it's required when you are using standard client
card, but using the same BSSID is not as clean.

> > 	Personally, I think that SIWAP is too tricky to use properly
> > for most users, so we should encourage them to not use it.
> 
> Keep in mind that it is also used by some programs (e.g., wpa_supplicant
> in ap_scan=1) without the user having to know anything about that level
> of details..

	My point is that we don't have to be perfect with respect to
the end user through SIWAP.

> > 	There is still a performance issue. Having to cancel and
> > restart associations waste CPU cycles. One way to deal with that would
> > be to improve the "commit" strategy of the Wireless API. Basically,
> > every time you do a set, you schedule or reschedule the "commit" ioctl
> > to happen in a few dozen ms. This way, you could bundle all the
> > settting of apps such as wpa_supplicant with only a single
> > commit. This is similar to the way the routing API works.
> 
> Number of drivers use an atomic "associate" command (usually, a private
> ioctl) with wpa_supplicant. If there were a standard way of doing that,
> it could be helpful.

	My goal was to offer the "commit" mechanism to solve those
issues. The basic plumbing is in place, so we just a slightly more
clever "commit" mechanism. The advantage is that the mechanism is
generic, so will work for anything.

> Jouni Malinen                                            PGP id EFC895FA

	Jean