Sorry for the late response. I am taking a bit off right now and I am
try to stay away from the keyboard. :)
On 6/13/19 8:31 PM, Damien Miliche wrote:
I found out that my connection problem has appeared after this commit:
Especially, while the message commit seems to apply to my case (status
code 17), the piece of code in function handle_assoc_status_code is not
applicable for triggering retries: the condition 'wifi->state ==
G_SUPPLICANT_STATE_ASSOCIATING' is not satisfied, as the authentication
denial happens in my case during state G_SUPPLICANT_STATE_AUTHENTICATING.
Moreover, at that state, wpa_supplicant does not provide the
authentication status code in the DBUS PropertyChanged signal, that
would indicate the reason of the denial (17 -
WLAN_STATUS_AP_UNABLE_TO_HANDLE_NEW_STA), as the assoc status code
(AssocStatusCode) would be after a failed association.
Any suggestion of how to fix this?
First, thanks for your patience and good report. It really helps to
understand what is going on.
Would patching both connman and wpa_supplicant in a similar way to
commit 6245582d0dc9a3f47a6880dabf437ee7c351caef of connman and commit
c7fb678f3109e62af1ef39be9b12bf8370c35bde of hostapd/wpa_supplicant, but
for CTRL-EVENT-AUTH-REJECT event / G_SUPPLICANT_STATE_AUTHENTICATING
state, be an acceptable solution
Yes, absolutely, It looks like ConnMan and
wpa_supplicant should agree
how to handle the state changes.