Status code with assoc response

[Naveen Singh]

On Tue, Mar 1, 2016 at 12:03 PM, Dan Williams <dcbw at redhat.com> wrote:
> On Tue, 2016-03-01 at 11:00 -0800, Naveen Singh wrote:
>> 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
>> > place.
>> >
>> > >
>> > > 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
>> > >                                 "status_code=%u",
>> > >                                 data->assoc_reject.status_code);
>> > > +                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
>> > disconnection.
>> >
>> > --
>> > 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.
>
> What is the roaming issue here?  When that status code gets returned,
> the supplicant should simply pick another AP of the same BSSID to
> associate with and do so automatically.  I might even blacklist the one
> that returned the bad status so it doesn't get tried again.  Or maybe
> I'm not understanding the roaming issue here...
>
> Are you trying to do roaming manually in connman by restricting the BSS
> list or the frequency list when you get the status=17?
>
> Dan

Hi Dan
Enterprise AP sometimes send you assoc response with status code as
17. Now wpa_supplicant with this status code, sends a disconnect
notification to connman. Connman treats all disconnect the same way
(disable the network, try to connect to same SSID again (Issues that
we have talked about in past)). The reality is that tby sending assoc
response with status code 17, AP is indirectly telling you to find a
different BSSID (chose an AP in 5 GHZ for band steering purposes or
this AP is heavily loaded for load balancing purposes). If
wpa_supplicant is left alone as you mentioned, it will blacklist this
AP and proceed to try with the next BSSID and would eventually
converge to the correct BSSID where association would stick.

So I tried to handle this by doing following:

1) Send the assoc status code to connman (I overloaded the reason code
for this which is not correct)
2) Send the disconnect notification.

I modified connman code to not look into DisconnectReason
propertieschanged Signal and extract the reason. And as a part of
handling the subsequent disconnect notification if the previous reason
code was 17, I do not process this disconnect notification. This would
let supplicant continue its logic of choosing the correct BSSID.
I tested this and it worked fine.

But looks like Jouni suggestion is going to make life easier for
connman, if we do not decide to send the disconnect notification in
this case as technically there is no connection established.

Let me know your thoughts on this

Regards
Naveen