Bug 562951

Summary: WPA keys with symbols fail
Product: [Fedora] Fedora Reporter: Tim Chilton <tim.chilton>
Component: wpa_supplicantAssignee: Dan Williams <dcbw>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 12CC: dcbw
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-12-03 23:06:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Tim Chilton 2010-02-08 20:08:06 UTC
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.

Comment 1 Dan Williams 2010-02-09 00:31:21 UTC
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.

Comment 2 Dan Williams 2010-02-09 00:31:31 UTC
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.

Comment 3 Tim Chilton 2010-02-09 08:46:54 UTC
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 !)

Comment 4 Bug Zapper 2010-11-03 22:40:57 UTC
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

Comment 5 Bug Zapper 2010-12-03 23:06:42 UTC
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.