[PATCH 0/2] dbus: Do Not Coalesce State Changed Signals

[Paul Stewart]

On Sat, Oct 29, 2011 at 9:07 AM, Jouni Malinen <j at w1.fi> wrote:
> On Thu, Oct 27, 2011 at 01:17:27AM -0500, Dan Williams wrote:
>> No, we don't, partly because the codes we want aren't solely 802.11
>> codes.  We want the EAP reason codes (or some abstraction thereof) too.
>
> Sure.
>
>> That would require a generic reason enum that is a superset of both
>> 802.11 and EAP and other reason codes for state changes.  That would be
>> awesome, but there isn't such a thing yet.  I'd love to add one.

I'm not sure we need another enum.  Why not separate the reason code
in to subsystem (authentication, association, eap) and reason # parts,
so we don't need to create (and maintain) a separate enum that needs
to be synced?  Unless wpa_supplicant adds extra knowledge (like
translating vendor-specific codes into generic ones based on extra
information) I don't think a bespoke enum is any more descriptive than
a qualified copy of the originals.

> I can fully understand the reasons being exposed, but the "state change"
> part may need some more clarification as long as it is tied to enum
> wpa_states. There's not really much point in indicating a specific
> reason, or even the state change, for things like moving from 4-way
> handshake to group handshake within WPA-Personal connection setup.
>
>> For deauth/disassoc, clients don't really need to know anything about
>> that until the supplicant actually changes state; it's kind of pointless
>> to have a separate signal for that if the supplicant is just going to
>> change states and look for a new AP upon receiving a deauth/disassoc, so
>> we might as well send out some status code when we change states.
>
> Well, the state will change immediately on deauth/disassoc RX, so I
> would like to better understand what is the exact state change here.
> For example, let's consider a case when wpa_supplicant-based SME is used
> in a WPA2-Enterprise network with multiple BSSes and load balancing. The
> current AP decides to kick us out in hopes of getting the station to
> move to another AP. As far as wpa_s->wpa_state is concerned, this would
> move through following states:
> WPA_COMPLETED -> WPA_DISCONNECTED -> WPA_SCANNING -> WPA_AUTHENTICATING
> -> WPA_ASSOCIATING -> WPA_ASSOCIATED -> WPA_4WAY_HANDSHAKE ->
> WPA_COMPLETED
>
> What state changes would be indicated through the new D-Bus signal, if
> any? Let's say this all took less than a second.
>
> Then let's assume the same case, but with the station going out of
> network coverage and not being able to connect. wpa_state would do this:
> WPA_COMPLETE -> WPA_DISCONNECTED -> WPA_SCANNING. And then remain there
> for considerable amount of time. What would be signaled through the new
> D-Bus signal and at what point?

I think this is where Sam's use of the CurrentBSS instead of state
worked so well.  In many cases the connection manager doesn't really
care what state the supplicant is in (except to inform UI elements) if
wpa_supplicant is making progress towards a connection, even when its
state transitions through WPA_DISCONNECTED.  Assuming that the CM has
configured network blocks that make sense, there's nothing to do until
the supplicant "gives up", which currently is indicated by a
CurrentBSS transitioning to "none".  We can treat that as an "I give
up", and the CM can swoop in and take action (switch to another less
preferred network, switch to a different medium, etc).  If supplicant
had a more formal signal of "I'm quiescent and sad", that'd be great
(and preferred), but right now CurrentBSS works reasonably well.

>> 3) Create a new D-Bus signal for state changes that includes the new
>> state and the reason code.  (a new signal since the existing signal
>> cannot change it's signature for compat reasons)
>>
>> This allows clients to easily inspect the reason code and figure out why
>> the supplicant's state has changed instead of having separate signals
>> emitted for different reasons.  The socket control interface could also
>> use this.  It's just more convenient for clients to have all this
>> information in one signal to process instead of a few different signals
>> (one for state, one for 802.11 deauth/disassoc reason code, another for
>> EAP failure reasons, etc).
>>
>> I'd volunteer to do this if it sounds reasonable to you.
>
> In general, this sounds good. Though, I'd like to understand the
> expected scenarios (at which point in time in internal wpa_supplicant
> state changes) when this new signal would be emitted and what the
> different exposed states would be (I'm assuming they would not be
> identical to enum wpa_states, but could be quite close to it) before
> much time is spent implementing this.
>
> --
> Jouni Malinen                                            PGP id EFC895FA
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>