Bug 532723

does your phassphrase contain any non-ascii characters?  By the standard, wpa passphrases may only contain ASCII characters.  What may be happening is, if your passphrase does contain non-ascii characters, those may not evaluate to a 1-byte long, and thus your passphrase overflows the check.  Unfortunately, the only way to distinguish between passphrase and hex key is with length, so we can't just accept any length passphrase.

Hi,

I used the "63 random printable ASCII characters" passwords from the https://www.grc.com/passwords.htm site so the characters in the passphrase should all be printable ASCII characters. I looked at my passphrase and all the characters seemed to be ASCII. I wasn't aware of the issue with non-ASCII characters - thanks for pointing this out.

I'm no expert on wireless networking so please excuse me if this is dumb question but the same 63 character passphrase worked with wpa_supplicant so shouldn't it have worked with NetworkManager as well?

Hi,

The password I was using when I encountered the problem is:
"pVZ7!WXQ\17L[\av)e;}bL1%oa20e&wuzQn~{2"r'NvMQQP^N,4f+/(wDDC!5JC"

Thanks.

Confirmed, there is a bug validating 63-character passphrases which was fixed upstream earlier this year:

commit f216af1e5d02c2f847d343616b7af7beac0fcdd3
Author: Tambet Ingo <tambet>
Date:   Fri Jun 19 11:34:56 2009 +0300

    wifi: Allow 63 byte long PSK (Patch from Robert Piasek).


PM: the fix is trivial and obviously correct.

QE: using the passphrase above, a buggy system would show the message "nm_supplicant_config_add_setting_wireless_security(): Invalid PSK length 63:
not between 8 and 63 characters inclusive." when attempting to connect to an AP using that WPA passphrase and fail to connect.  A correctly operating system would not show that message in /var/log/messages, and would connect to the AP.

Full patch would be:

diff --git a/src/supplicant-manager/nm-supplicant-config.c b/src/supplicant-manager/nm-supplicant-config.c
index 6df7168..64a4a06 100644
--- a/src/supplicant-manager/nm-supplicant-config.c
+++ b/src/supplicant-manager/nm-supplicant-config.c
@@ -609,7 +609,7 @@ nm_supplicant_config_add_setting_wireless_security (NMSupplicantConfig *self,
                                nm_warning ("Error adding 'psk' to supplicant config.");
                                return FALSE;
                        }
-               } else if (psk_len >= 8 && psk_len < 63) {
+               } else if (psk_len >= 8 && psk_len <= 63) {
                        /* Use TYPE_STRING here so that it gets pushed to the
                         * supplicant as a string, and therefore gets quoted,
                         * and therefore the supplicant will interpret it as a

rh532723-long-psk-fix.patch

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2010-0263.html