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

[Jouni Malinen]

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 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?

> 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