[PATCH] dbus_new: add property to track reason for a state change

[Jouni Malinen]

On Mon, Oct 24, 2011 at 03:54:59PM -0700, mukesh agrawal wrote:
> In the connection manager, it is sometimes useful to disambiguate the
> reason for a connection failure. For example, if a connection attempt
> fails due to WLAN_REASON_4WAY_HANDSHAKE_TIMEOUT, it is more likely
> that the connection manager has the wrong key than if the connection
> attempt fails due to WLAN_REASON_DEAUTH_LEAVING.

Maybe so, but please note that 4-way handshake timeout can be even more
likely indicating that there was an issue in sending or receiving
EAPOL-Key frames rather than the passphrase being incorrect.. IEEE Std
802.11 simply does not provide a clear mechanism that could be relied on
to indicate that the passphrase/PSK was incorrect.

> This patch
> - adds a new D-Bus property, "StateChangeReason"
> - adds a reason_code argument to wpa_supplicant_set_state

Why would this be bound this tightly with wpa_state changes? That is the
exact part I'm not exactly happy about exposing to external programs in
the first place and it looks odd to use IEEE 802.11 Reason Code as the
reason was state changes. That would only apply to the cases when a
Deauthentication or Disassociation frames is received and all other
state changes do not have such information. It would sound much clearer
to add a new signal that indicates that a Deauthentication or
Disassociation frame was received with a specific Reason Code..

> - modifies wpa_supplicant_event_disassoc to pass the disconnect_reason
>   down to wpa_supplicant_set_state (via wpa_supplicant_mark_disassoc)

Getting that reason code value propagated sounds reasonable, but I don't
want to see it in wpa_supplicant_set_state.

> - modifies sme_event_assoc_reject to pass the status_code down to
>   wpa_supplicant_set_state (via sme_deauth)

Same here. Though, this is even worse since Association Response uses
Status Code, not Reason Code. The way this is handled merges those into
the same D-Bus property and makes it pretty much impossible for the
recipient to figure out whether the value is a Reason Code or Status
Code (those are separate definitions in IEEE Std 802.11 and have
different meanings, e.g., Reason Code 2 = Previous authentication no
longer valid and Status Code 2 = TDLS wakeup schedule rejected but
alternative schedule provided).

Authentication and association rejections should really be in their own
D-Bus signal that includes the received status code.

> - modifies wpa_supplicant_disassociate and wpa_supplicant_deauthenticate
>   to pass the reason_code down to wpa_supplicant_set_state
>   (via wpa_supplicant_clear_connection and wpa_supplicant_mark_disassoc)

And these mix in locally generated reasons.. Those need to be separated
from the case when it is the AP that disconnected us.

-- 
Jouni Malinen                                            PGP id EFC895FA