SIOCSIWAP behavior question

SIOCSIWAP behavior question

[Dan Williams]

Should setting a BSSID trigger a disconnection event from the driver?
Obviously a disconnect event shouldn't be triggered if the BSSID being
set is the same BSSID the card is already associated with.  Or does that
mean "reassociate unconditionally" ?

But suppose we have two APs in the same ESS with obviously different
BSSIDs.  The card automatically associates with one BSSID, but
wpa_supplicant decides it likes the other BSSID and calls SIOCSIWAP to
lock to that one during the association process.  Should the driver
issue an IWAP event of 00:00:00:00:00:00 before attempting
re-association with the BSSID that wpa_supplicant wants?

The libertas driver currently does this; it sometimes confuses
wpa_supplicant and is arguably wrong behavior because drivers don't
issue disconnection events when auto-roaming from BSSID to BSSID in the
same ESS.

Conversely, if you have two access points 'linksys' with different
BSSIDs that really _are_ two different ESSs, this would screw up
userspace tools if a disconnect _wasn't_ sent.  But in this case
automatic tools have more problems than driver events.

Thoughts?  I guess I vote for not sending disconnect events if that
BSSID has the same capabilities and the same SSID as the current
association BSS.

Dan

Re: SIOCSIWAP behavior question

[Dan Williams]

On Mon, 2007-04-02 at 09:47 -0400, Dan Williams wrote:
> Should setting a BSSID trigger a disconnection event from the driver?

Hmm; badly phrased question.  I really meant:

Should setting a BSSID _always_ trigger a disconnection event from the
driver?

> Obviously a disconnect event shouldn't be triggered if the BSSID being
> set is the same BSSID the card is already associated with.  Or does that
> mean "reassociate unconditionally" ?
> 
> But suppose we have two APs in the same ESS with obviously different
> BSSIDs.  The card automatically associates with one BSSID, but
> wpa_supplicant decides it likes the other BSSID and calls SIOCSIWAP to
> lock to that one during the association process.  Should the driver
> issue an IWAP event of 00:00:00:00:00:00 before attempting
> re-association with the BSSID that wpa_supplicant wants?
> 
> The libertas driver currently does this; it sometimes confuses
> wpa_supplicant and is arguably wrong behavior because drivers don't
> issue disconnection events when auto-roaming from BSSID to BSSID in the
> same ESS.
> 
> Conversely, if you have two access points 'linksys' with different
> BSSIDs that really _are_ two different ESSs, this would screw up
> userspace tools if a disconnect _wasn't_ sent.  But in this case
> automatic tools have more problems than driver events.
> 
> Thoughts?  I guess I vote for not sending disconnect events if that
> BSSID has the same capabilities and the same SSID as the current
> association BSS.
> 
> Dan
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SIOCSIWAP behavior question

[Jouni Malinen]

On Mon, Apr 02, 2007 at 09:47:35AM -0400, Dan Williams wrote:
> Should setting a BSSID trigger a disconnection event from the driver?

Just the act of setting BSSID? No.

> Obviously a disconnect event shouldn't be triggered if the BSSID being
> set is the same BSSID the card is already associated with.  Or does that
> mean "reassociate unconditionally" ?

I would ike to see disconnect event only if the driver/stack notices
that it cannot complete association and based on this, believes its
association to the ESS is lost.

> But suppose we have two APs in the same ESS with obviously different
> BSSIDs.  The card automatically associates with one BSSID, but
> wpa_supplicant decides it likes the other BSSID and calls SIOCSIWAP to
> lock to that one during the association process.  Should the driver
> issue an IWAP event of 00:00:00:00:00:00 before attempting
> re-association with the BSSID that wpa_supplicant wants?

I would not like to see this. I see this as re-association within the
same ESS and the driver/stack should just report the new BSSID after
successful re-association. The exact same behavior should apply here
regardless of whether BSSID was set (sort of forced re-association) or
not (driver/stack re-associating, e.g., due to signal strength
difference).

> The libertas driver currently does this; it sometimes confuses
> wpa_supplicant and is arguably wrong behavior because drivers don't
> issue disconnection events when auto-roaming from BSSID to BSSID in the
> same ESS.
> 
> Conversely, if you have two access points 'linksys' with different
> BSSIDs that really _are_ two different ESSs, this would screw up
> userspace tools if a disconnect _wasn't_ sent.  But in this case
> automatic tools have more problems than driver events.

I would rather not see disconnect event in either case. User space tools
should react to BSSID change event by determining whether the old
network configuration is still valid. This could be done, e.g., by
pinging the default gateway (IP and/or MAC layer) and re-running DHCP if
needed.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: SIOCSIWAP behavior question

[Joerg Mayer]

On Mon, Apr 02, 2007 at 08:54:05AM -0700, Jouni Malinen wrote:
> I would ike to see disconnect event only if the driver/stack notices
> that it cannot complete association and based on this, believes its
> association to the ESS is lost.

What is the recommended way to cause a disconnect / reconnect?

 Ciao
       Joerg
--
Joerg Mayer                                           <jmayer@loplof.de>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.

Re: SIOCSIWAP behavior question

[Jouni Malinen]

On Mon, Apr 02, 2007 at 06:56:43PM +0200, Joerg Mayer wrote:
> On Mon, Apr 02, 2007 at 08:54:05AM -0700, Jouni Malinen wrote:
> > I would ike to see disconnect event only if the driver/stack notices
> > that it cannot complete association and based on this, believes its
> > association to the ESS is lost.
> 
> What is the recommended way to cause a disconnect / reconnect?

I don't know whether there is such a thing, but I normally use
SIOCSIWESSID with a different SSID (e.g., a random string) to force
disconnection and with the same SSID to force re-association to the same
ESS.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: SIOCSIWAP behavior question

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]

On Mon, 2007-04-02 at 09:47 -0400, Dan Williams wrote:
> Should setting a BSSID trigger a disconnection event from the driver?
> Obviously a disconnect event shouldn't be triggered if the BSSID being
> set is the same BSSID the card is already associated with.  Or does that
> mean "reassociate unconditionally" ?

IMHO (answering your rephrased question with "always") it should unless
the BSSIDs are really identical. After all, one disassociates from one
BSS before associating to the other.

> The libertas driver currently does this; it sometimes confuses
> wpa_supplicant and is arguably wrong behavior because drivers don't
> issue disconnection events when auto-roaming from BSSID to BSSID in the
> same ESS.

Is there a way to trigger such events when auto-roaming? :)

> Thoughts?  I guess I vote for not sending disconnect events if that
> BSSID has the same capabilities and the same SSID as the current
> association BSS.

I think that just makes things unnecessarily complex -- we'd have to try
to see if two things are really the same ESS in the driver/stack/...

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: SIOCSIWAP behavior question

[Dan Williams]

On Mon, 2007-04-02 at 18:58 +0200, Johannes Berg wrote:
> On Mon, 2007-04-02 at 09:47 -0400, Dan Williams wrote:
> > Should setting a BSSID trigger a disconnection event from the driver?
> > Obviously a disconnect event shouldn't be triggered if the BSSID being
> > set is the same BSSID the card is already associated with.  Or does that
> > mean "reassociate unconditionally" ?
> 
> IMHO (answering your rephrased question with "always") it should unless
> the BSSIDs are really identical. After all, one disassociates from one
> BSS before associating to the other.

So it appears that you and Jouni have opposite views here?  I think a
pure & consistent approach would issue disconnect every time the driver
disassociated.  But I'm not sure that would actually work in practice
for all cases.  But I don't have a good idea of all the specifics or
implications.

I tend to think thought that Jouni's right and that within the same ESS
we shouldn't send disconnect events if you're just changing BSSID.

Dan

> > The libertas driver currently does this; it sometimes confuses
> > wpa_supplicant and is arguably wrong behavior because drivers don't
> > issue disconnection events when auto-roaming from BSSID to BSSID in the
> > same ESS.
> 
> Is there a way to trigger such events when auto-roaming? :)
> 
> > Thoughts?  I guess I vote for not sending disconnect events if that
> > BSSID has the same capabilities and the same SSID as the current
> > association BSS.
> 
> I think that just makes things unnecessarily complex -- we'd have to try
> to see if two things are really the same ESS in the driver/stack/...
> 
> johannes

Re: SIOCSIWAP behavior question

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

On Mon, 2007-04-02 at 15:19 -0400, Dan Williams wrote:

> So it appears that you and Jouni have opposite views here?

Looks like :)

> I think a
> pure & consistent approach would issue disconnect every time the driver
> disassociated.  But I'm not sure that would actually work in practice
> for all cases.  But I don't have a good idea of all the specifics or
> implications.
> 
> I tend to think thought that Jouni's right and that within the same ESS
> we shouldn't send disconnect events if you're just changing BSSID.

I guess that if you just send a new BSSID without sending a 00::00
inbetween the disconnect must have been there and is sort of implied.
I'm fine with either way, and I'd like the outcome of this discussion
specified somewhere on the cfg80211 page on linuxwireless.org so we can
do it that way there too and I don't forget ;)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]