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

[Dan Williams]

On Mon, 2011-10-24 at 23:10 +0300, Jouni Malinen wrote:
> On Mon, Oct 24, 2011 at 12:07:41PM -0700, Sam Leffler wrote:
> > We agree about having explicit signal.  The way we infer a 4WHS issue
> > is no less reliable than we would get if State change signals were NOT
> > coalesced.  Having an explicit status code / indication is what I
> > suggested >year ago when we first hit this issue.  Having the 802.11
> > status / reason codes would definitely improve life when a connection
> > manager wants to get directly involved in handling certain events.
> 
> Huh.. We don't have that with D-Bus? The reason code is included in the
> ctrl_iface CTRL-EVENT-DISCONNECTED event and now that I tried to find
> matching D-Bus code, I did not even find any signal going out when we
> receive a deauth/disassoc frame from the AP. Is the D-Bus interface
> really using just the wpa_state change event for this?

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

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.

> Similarly, there is a ctrl_iface event on possible 4-way handshake
> event, but obviously no D-Bus code for that either. Not that this would
> really be very reliable indication in the first place.. Actually, I
> could make it a bit more reliable now that some APs are starting to use
> reason codes 15 or 16 to indicate 4-way handshake timeouts and that
> could filter out many false positives here.

That's a good thought and those two codes would be useful.  But again,
the best thing to do here would be:

1) Create a new enum that's a superset of the current supplicant
interface states, and generate that new enum from the internal
supplicant interface states. That enum could even map exactly to the
current supplicant interface states.

2) Create a new enum that's a reason code for the state change, and make
that enum a superset of the available 802.11 reason/status codes, EAP
status/failure codes, and supplicant internal failure codes.

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.

Dan