Bug 12185

Description of problem:  on an initial analysis, this bug appears to occur when a new WPA2 key is 10 DIGITS (or is changed to 24 DIGITS).

Have not been able to connect to an AT&T wireless AP which are usually setup as SSID=2WIRE234 with WPA2key=0123456789

Over the holidays, found a possible solution which suggested repeating the key to fill it out to 24 digits. i.e., 0123456789 becomes 012345678901234567890123 (didn't work though) 

Today, returned home, and for the first time ever, could not connect to my wireless network.  Tracked this down to /etc/wpa_supplicant.conf which now contained a WEP setup for the AT&T network, even though I specifically set the AT&T network as WPA2:

network={                      # home network
    ssid="XX"
    priority=1
    psk="xx123xxxxxxxxxxxxx"
    scan_ssid=0
}

network={                      # AT&T network
    scan_ssid=0
    priority=1
    ssid="2WIRE234"
    auth_alg=SHARED
    wep_tx_keyidx=0
    mode=0
    wep_key0="012345678901234567890123"
    key_mgmt=NONE
}

Manually changed these entries to:
network={
    ssid="XX"
    psk="xx123xxxxxxxxxxx"
    scan_ssid=0
    priority=1
}

network={
    ssid="2WIRE234"
    psk="0123456789"
    scan_ssid=0
    priority=1
}

and now I could connect to my home network.  

1. Why does a 10-digit (24-digit?) WPA2 key get treated as a WEP key?
2. Why would a network entry incorrectly entered as WEP prevent another WPA2 network from connecting?

Trying to correct this situation via mcc wireless config (before finding the above) was of no use.



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.


Reproducible: 

Steps to Reproduce: