On Mon, Sep 30, 2019 at 01:02:09PM +0000, Federico Sauter wrote: > I would like to establish whether the authentication using a supplied PSK for a BSS was successful or not. The success case is easy, since it results in the establishment of the connection (fi.w1.wpa_supplicant1.Interface property state = connected). > > The error case is more tricky, since I found no way of getting an authentication failure signal over DBus. This information would be available over the socket interface: in the CTRL-EVENT-SSID-TEMP-DISABLED event, but there seems to be nothing comparable over the DBus interface. There is no explicit authentication failure indication in the protocol, so it is not exactly easy to get reliable information on a connection failure being caused by authentication failure. The best guess currently is the wpa_supplicant_event_disassoc_finish() check through could_be_psk_mismatch() which results in "WPA: 4-Way Handshake failed - pre-shared key may be incorrect" message being sent over the text-based control interface. A D-Bus signal based on this might be a reasonable approach for providing same of D-Bus. > In my observations, the AssocStatusCode, DisconnectReason, and AuthStatusCode attributes are never set to anything other than zero, making them unfit for this. > > Therefore, I added a DBus attribute for auth_failures. A change in its state is notified in the wpas_auth_failed() function, ensuring that an authentication failure is always notified by listening to the PropertiesChanged signal and checking that the new AuthFailures attribute is greater than zero. > > However, by further reading the code I noticed that wpas_auth_failed() may also be called from wpas_connection_failed() in the context of blacklist management. In that case, the auth_failures attribute would probably not be an accurate sign of an authentication failure (?). I would not use ssid->auth_failures for this or even expose it from wpa_supplicant to external programs since it is an internal counter used to determine when to delay connection attempts for a particular network. In particular, I would not expose it as an internal property based on whether wpa_s->current_ssid happens to be set at the time the value is queried. > Is the wpas_auth_failed() function the one and only place where an authentication failure can be accurately diagnosed, or are there any other locations in the code base that should be taken into account? If you are looking for signs of PSK/passphrase mismatch, I'd use the could_be_psk_mismatch() case mentioned above. > Would it make sense to change the wpas_connection_failed() as well so that it temp-disables an SSID, but it doesn't use the auth_failures counter for that? No, auth_failures was added for the exact purpose of being able to determine how long a network should be temporarily disabled. > Attached you will find the proposed patch. I don't think this is a good approach for exposing internal (and subject to change without notice) counter from wpa_supplicant. I don't want to get stuck having to maintain that exact counter value nor do really think this should be done through wpa_s->current_ssid which can change at any moment in time based on network connection attempts (i.e., the D-Bus property would not really be stable nor providing correct property changed updates). -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
