Status code with assoc response
naveensingh0977 at gmail.com
Tue Mar 1 11:00:05 PST 2016
On Tue, Mar 1, 2016 at 12:12 AM, Jouni Malinen <j at w1.fi> wrote:
> On Mon, Feb 29, 2016 at 07:07:44PM -0800, Naveen Singh wrote:
>> The reason code from deauth/dis-assoc frames are sent over DBUS as a
>> part of "PropertiesChanged" DBUS signal but not the status code
>> (especially failure ones) from assoc response.
> Status Code is not Reason Code; these are two completely different
> fields with different meanings.
>> I am working on some changes in connman to take care of enterprise
>> roaming case (when AP is denying association with reason code 17
>> hoping client would move to a different AP). This is for load
>> balancing and/or band steering. Idea is that connman gets the reason
>> code as a part of disconnect notification and acts differently.
> AP is not denying association with any reason code; it is doing that
> with status code. Strictly speaking, this should not really even be
> disconnect notification since there was no connection in the first
>> Is there any objection in not sending the assoc response status code
>> over DBUS. I was thinking of adding something like this in
>> ASSOC_REJECT handler:
> I have no issues with making the status code available over D-Bus, but I
> won't accept misuse of a single field to send over both reason codes and
> status codes in a manner that makes it impossible to figure out which
> one was sent.
>> @@ -2496,6 +2496,8 @@ void wpa_supplicant_event(void *ctx, enum
>> wpa_event_type event,
>> wpa_msg(wpa_s, MSG_INFO, WPA_EVENT_ASSOC_REJECT
>> + wpa_s->disconnect_reason = data->assoc_reject.status_code;
>> + wpas_notify_disconnect_reason(wpa_s);
> disconnect_reason is documented as containing WLAN_REASON_* reason codes
> and negative versions of those for locally generated cases.
> data->assoc_reject.status_code is a status code (WLAN_STATUS_*) and not
> appropriate to use in that field. wpas_notify_disconnect_reason() does
> not sound like correct function to call here either; this should provide
> a new signal indicating that connection failed instead of indicating
> Jouni Malinen PGP id EFC895FA
Thanks Jouni. I agree with you that status code and reason code are
two different things and convey two different meanings. I was just
exploring a quick hack to see if enterprise roaming start working when
i send the status code to connman and for this purpose I overloaded
the reason code. Having this status conveyed to connman simplifies
thing quite a bit to handle this scenario. I can work on a patch to
generate another "PropertiesChanged" DBUS signal which conveys the
status code of assoc response.
More information about the Hostap