Distinguishing wrong password from other failure to connect?

Hi. Curious if there is a way to distinguish between the various failure modes when failing to make an association to an AP.

In particular, I'd love to distinguish between these two states:

* User entered incorrect password

* User entered correct password, but the AP rejected them for some other reason (perhaps signal was too weak, or the AP is using MAC address filtering, or they couldn't negotiate a common encryption/authentication protocol, or whatever).

Does the Linux wireless stack support a way for applications to gather this information? Are the "reason=0x00" bytes, sometimes displayed by wpa_supplicant in the logs, standardized across all AP's?

This seems to be a common problem, because on many distributions, I see NetworkManager constantly popping up the password entry box whenever an association fails, when the user already knows the password is correct (and in fact has entered it into the box already, as it's pre-filled in the box, albeit starred out).

Thanks!

Josh

It should only have that issue with WEP (which you shouldn't be using anyway) and even then only when shared key auth is not available. Otherwise, the supplicant should have enough info about the failure.

johannes

The "reason=xx" codes are standardized by 802.11. However when reading such messages, one needs to be careful to note which party sent that reason code. There are times when the AP sends this message, and other times where the station sends it as it departs.

It is a problem in general, but for the most part I believe the onus lies with the supplicant, rather than the kernel to distinguish between the various error cases. It is the step between wpa_supplciant and whatever connection manager which makes it tricky to properly determine why a connection failed (or was lost) and relay the correct information back to the user. For example, in the ChromeOS connection manager, if we note that wpa_supplicant fell out of association while in the 4WAY_HANDSHAKE state, we assume that this is due to a bad WPA passphrase, but in the (admittedly unlikely but still statistically significant) case where we lose connectivity in that state due to lower-level failure, we assume the same thing, and tell the user their password is wrong. Not a good experience.

Even in the WEP case, you can imagine the supplicant being proactive in determining if the key is wrong by monitoring packet counts. In this situation there may need to be some kernel help -- I'm not sure where counters are kept of packets dropped due to failed WEP decryption -- but if such a thing existed, wpa_supplicant could presume the encryption key was incorrect after a period of time.

--
Paul

Thanks for the information. Is there a guideline as to what messages indicate wrong settings by the user (wrong password, etc.)?

Basically, I'm trying to know where to pin the blame: on the user's wrong password, or on the network itself.

Josh

In some cases, yes, in many, not really in any reliable way.

That depends on which security mode you are using.. With WPA/WPA2-Personal, there is no explicit indication that the connection failed because of incorrect passphrase because the AP will silently drop the message in which the wrong passphrase was used. In other words, the protocol does not provide means for the AP to indicate that connection failed because of incorrect key.

In WPA/WPA2-Enterprise, you may get an explicit error notification of password failure with some EAP methods, but not all (they may have the same lets-not-provide-any-more-info-to-attackers design for failure cases).

Well, the starting problem is that the protocol does not provide such information (sometimes by design). The best you can do is to assume things and hope that the most likely reason for an error was the cause of the problem this time. For example, with WPA/WPA2-Personal, we may assume that the passphrase was incorrect if we complete association successfully, receive EAPOL-Key 1/4, send EAPOL-Key 2/4 and get it acknowledged by the AP, but never see EAPOL-Key 3/4. This does not guarantee that the reason for incorrect passphrase, but that is one of the most likely reasons for this.

Asking for a passphrase again (and even worse, dropping the previously stored passphrase based on this) is bad UI design in my opinion for many of these cases. It should not really done unless we are pretty confident that the reason was indeed in wrong passphrase. Especially the forgetting of stored information should really never be done unless we are very confident on this being caused by wrong passphrase (e.g., never do that if we have successfully completed even one connection with WPA/WPA2-Personal).

We have most of the needed information available in user space to allow applications to do their best in figuring out what could have happened. One small addition would be to make it easier to get TX status for EAPOL-Key transmission (i.e., whether AP acknowledged a Data frame sent by wpa_supplicant) into user space. hostapd can do this with a monitor interface, and well, so could wpa_supplicant, but the simpler design of just using normal data frame transmission routines does not provide that indication back to the application. Still, this would not provide completely reliable mechanism for determining whether incorrect passphrase was used, but it would potentially allow limiting some of the false positives from being reported in cases where 4-way handshake fails due to AP not receiving frames from the station for some other reason.

Jouni Malinen                                            PGP id EFC895FA

That makes sense, to do a silent drop, because of security (you don't want to give positive feedback to a hacker that the password was rejected, that would only make it faster for them to loop through a dictionary of passwords).

It's a shame from a UI point of view, though. I don't want to accuse my user of entering the wrong password when in reality it was the network's fault, and vice versa.

Very clever idea. It would be great to have visibility into the authentication/EAPOL state machine, instead of just getting final states like "ASSOCIATED". Is this information available outside wpa_supplicant in any standard way, or will I have to patch wpa_supplicant to find a way to publish this information to my UI?

I'm glad I'm not the only one who is irritated by this design decision of NetworkManager! I keep wishing for a checkbox that says "I KNOW my password is correct, please keep trying with it, and stop bugging me". Oftentimes I'll walk my laptop out of range, then come back into range, only to have my laptop fail to automatically connect because it's just sitting there stuck at the NetworkManager password prompt.

Josh