On Tue, 2016-03-01 at 11:00 -0800, Naveen Singh wrote: > On Tue, Mar 1, 2016 at 12:12 AM, Jouni Malinen <j@xxxxx> 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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
