Description of problem: WPA / WPA2 keys using some symbols fail to authenticate if entered as text. exclamation mark as last character causes problem. Other symbols may also cause problems - not tested. Works OK if wpa_passphrase is used to generate hex equivilent of string with exclamation mark present. (in /etc/wpa_supplicant/wpa_supplicant.conf) Version-Release number of selected component (if applicable): 0.6.8 - from wpa_supplicant -v How reproducible: Every Time Steps to Reproduce: 1.Configure WPA_Supplicant to have a text string containing a ! at the end of the passphrase 2.Attempt to connect to wireless AP 3.Wireless connections fails to associate 4.Re-configure with "wpa_passphrase" generated version of the same string 5.Attempt to connect 6.Works as expected Actual results: will not associate with AP Expected results: Correct authentiation and functional wireless link (additionally, security settings in system/administration/network reflecting WPA, WEP, TKIP, AES, etc would reduce frustration of configuring wireless) Additional info: Using NetGear WG511 v1 card Works fine with no authentication Works fine with WEP security Does not work with WPA1 or WPA2 unless hex string is used.
Does your WPA passphrase use non-ASCII characters, for example those with accents? How long is your passphrase? What is the output of "env | grep LANG"? The problem is one of encoding; depending on what your browser encoding was when you set up the AP, your passphrase could have been sent in any number of different formats. It's impossible to autodetect, which is why the WPA specification states that passphrases should be composed only of ASCII characters. Unfortunately some APs ignore that constraint. A valid WPA passphrase is between 8 and 63 (inclusive) ASCII characters.
The output of the env | grep LANG returns en_US.UTF.8. The passphrase is 16 characters long and is made up of only standard printable ASCII characters (checked with http://en.wikipedia.org/wiki/ASCII_Character_Set ). The key was made up of of numbers, letters (upper and lower) and the "!" symbol. The AP has other systems connected into it such as games consoles, Windows PC, mobile phones, etc and all work fine with "!" in the key and as I stated previously, on FC12 if the key wpa_passphrase tool is used to encode the same key as a hex sequence, then FC12 works too. If there is really a limitation on the character set, then this is not visible before or during entry, nor restricted by validation of the key after entry. The fault is not the AP (which incidentally runs Linux too !)
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.