On Thu, Nov 11, 2010 at 11:25:29PM -0800, Josh Lehan wrote: > Hi. Curious if there is a way to distinguish between the various > failure modes when failing to make an association to an AP. In some cases, yes, in many, not really in any reliable way. > 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 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). > 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? 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. > 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). 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
