On Tue, Mar 1, 2016 at 12:03 PM, Dan Williams <dcbw@xxxxxxxxxx> 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@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 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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
