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

[Sam Leffler]

On Mon, Oct 24, 2011 at 8:40 AM, Dan Williams <dcbw at redhat.com> wrote:
> On Mon, 2011-10-24 at 18:26 +0300, Jouni Malinen wrote:
>> On Mon, Oct 24, 2011 at 10:05:04AM -0500, Dan Williams wrote:
>> > I used to have a problem with this, but I now see where it makes sense
>> > for the State property alone. ?Most properties *should* be coalesced to
>> > reduce dbus traffic, but the State property should probably just trigger
>> > an immediate emit of the interface's changed properties. ?State doesn't
>> > change that often so it wouldn't meaningfully increase D-Bus traffic.
>>
>> What exactly are these state changes used for? The main problem I see
>> with this is that wpa_s->wpa_state is supposed to be internal data for
>> wpa_supplicant and the values it has and the way they are used are
>> subject to change whenever needed.. As such, I would really not want any
>> external functional to depends on that for anything beyond maybe showing
>> some debug information.
>
> NM uses it to determine what state the supplicant is in, obviously. ?If
> the supplicant is scanning, then we don't want to do certain operations.
> If the supplicant is connecting, there are other operations we don't
> want to do (like request a scan).

You get an explicit signal for scanning.

>
> If the supplicant fails during association/authentication, then the
> connection manager wants to know that, because that could indicate
> specific failures: a failure during 4-way handshake usually indicates
> that a password is incorrect, and that's very useful information to a
> connection manager.

We identify 4-way handshake failure when the CurrentBSS transitions to
"/".  One might argue this is a hack but it's been as reliable as
monitoring the state (both are unsatisfactory--there should be an
explicit signal/property).

>
> Obviously we want notification of disconnection events so that in NM we
> can start a timer for overall connection failure and after a certain
> period of retries, terminate the attempt and look for a different AP.

Again, monitor CurrentBSS.

>
> We need to know, after adding an interface, whether that interface is
> now ready for action or not. ?When the interface enters state COMPLETED,
> we need to know to start IP configuration. ?When the interface is DOWN
> we need to know to clean stuff up and forget about the interface. ?If
> the interface is AUTHENTICATED and we're waiting for an EAP identity or
> password, then when the interface transitions to DISCONNECTED we need to
> know that we should stop waiting for user input.
>
> All sorts of stuff :)

We were able to accomplish all the above w/o using the state variable.
 In fact it wasn't until we stopped using the state setting that we
got reliable integration (even for the old dbus api).  The typical
problem seems to there are two async state machines trying to control
each other and that just causes horrible confusion.

>
>> There are already some horrible hacks in place for wpa_state (just see
>> how WPA_IDLE is generated in Android builds) and I really do not want to
>> have to consider supporting something like that with the D-Bus
>> interface.
>
> Well, it's extremely useful to have something like this, as opposed to a
> plethora of signals for other stuff. ?Having one state signal for an
> interface means one centralized place that client code can perform
> actions based on what's happening in the supplicant. ?If not state
> signals then I'm not sure what we'd use, but hopefully it's not a
> combination of other signals since those arrive asynchronously and thus
> are harder to handle.

Integration of supplicant w/ a connection manager is problematic given
both want control under certain conditions.  Until supplicant stops
wanting to do so much or connection managers _really_ defer control to
supplicant there will continue to be madness.  We started w/ the
connman approach that the connection manager should be in control but
very quickly recognized this would never work except in the simplest
scenarios.  We stabilized once we moved more control to supplicant and
continue in this direction.

>
>> If there is desire to actually use this type of information for taking
>> some actions, it would be much safer to define a new value that will be
>> generated based on internal state (including wpa_s->wpa_state) and
>> define that in a way that makes it easier to maintain this in a stable
>> way even if the internal implementation changes.
>
> That's fine with me, we could simply keep the same state values and just
> change how the D-Bus property value is calculated. ?But having a
> notification of supplicant interface state is really, really useful.

I asked for this to be optional because it just adds overhead for us
and may introduce subtle breakage.  I still haven't seen a good reason
to change the current behaviour (e.g. we've demonstrated there's no
need for this change).  If there are explicit events clients want it
would seem better add signals than expose internal supplicant state
that will be used to inter these events.

-Sam