WPA keys must be 10 characters or less in length

[midiwall]

WPA will only work with pass phrases of 10 characters or less. For example:

 PassPhrase: 12345abcde    (works)
 PassPhrase: 12345abcdef   (doesn't work)

Please contact me if you need more info.

Mark Pulver, mark {at} midiwall {dot} com

[mbletsas]

Since wpa_passphrase doesn't seem to have an issue with longer passphrases, this seems to be a UI issue.

M.

[midiwall]

@marco tomeu: "Since wpa_passphrase doesn't seem to have an issue with longer passphrases, this seems to be a UI issue."

---

Actually.. :) Lemme fill in the back story, it may help folks fix this.

We fired up our OLPCs yesterday at the office; got the networks.cfg file set and were happily chugging along on the corporate network (WPA-PSK/TKIP).

We came in this morning, and the OLPCs couldn't connect. Went through the morning email, and our NetAdmin had changed the passphrase on what we know as our "public" wireless network overnight. mmm, 'k.

We reconfigured the OLPCs and.. nothing. Reconfigured random other devices (Macbooks, Chumby's, Nokia N800s) and everything else was fine.

dig dig dig; play play play; pull out more hair than I'd care to lose. :)

I finally got to looking at the old and new passphrase's... the old one was a mix of chars, "@"'s, numbers, mixed case text. The new one was all numeric ("easy to remember for the guest public wireless subnet"). The old one was 10 characters long, the new one was 11. Seems strange, but I started to think that either the issue was with an all numeric password, or that it had to do with length.

I grabbed an unused wireless router and setup an isolated test network. I first tried wpa-psk, 802.11/g, ssid=ngtest, passphrase=passphrase. The OLPC connected.

next: wpa-psk,802.11/g, ssid=ngtest2, passphrase=13125551212. The OLPC did *not* connect. Clicking on the network icon on the OLPC ended up prompting me for the passphrase.

next: wpa-psk,802.11/g, ssid=ngtest3, passphrase=3125551212. connected.

Each set of tests ran the sequence of a) configure router, b) configure OLPC (via terminal session and wsa.sh script), c) reboot router, d) reboot OLPC.

I've asked the network admin to change the password on the public wireless network so that I can try the OLPC on it tomorrow. I'll post up results as soon as I have 'em!

[tomeu]

Mark, it's not completely clear to me if you tried to configure the connection in the command line or only by using Sugar. Can you please confirm?

By glancing at the Sugar code, I cannot see a reason why a key of length >10 would stop working.

For reference, I think this is the only code involved in that:

# passphrase
import commands
(s, o) = commands.getstatusoutput("/usr/sbin/wpa_passphrase '%s' '%s'" % (ssid, key))
if s != 0:
    raise RuntimeError("Error hashing passphrase: %s" % o)
lines = o.split("\n")
for line in lines:
    if line.strip().startswith("psk="):
        real_key = line.strip()[4:]
if real_key and len(real_key) != 64:
    real_key = None

[midiwall]

Hey ya';

The only configuration I did was to use the wpa shell script to create the networks.cfg file. I didn't work at all within the UI. I'm not a big UI guy, I fired up the OLPC and headed for a command line. :) The script that I used for configuration is the simple one mentioned here:

http://wiki.laptop.org/go/WPA_Manual_Setting

fwiw, I suspect the issue is in the network driver, not in the config. The key that the script placed into networks.cfg was always correct, as mbletsas mentions above, wsa_passphrase doesn't have a problem generating the key.

Oh, I see where the confusion is.. Since the hash is always 64 characters long, and the key is correct as it sits in the networks.cfg file, then how could it possibly matter what the length of the ASCII key was.

Good point. It can't be a length issue, something else is up. Very weird.

I'll reconfirm my results with the test network today, and see how our live network is doing as well.

hmmm....

[midiwall]

Well, okay... ya'll knew this was coming. :)

I can't replicate the results of my test-network setup yesterday. No matter what I do in terms of ssids and passphrases, the OLPC will connect every time. But, the OLPC will still NOT connect to our corpnet public WiFi (even with the new passphrase in place). VERY weird... hmmm..

The only thing I can think of now is that it's an issue with a pure 802.11/g network (Cisco Aironet 1100), but I also had my test network set as forced /g (though with a Netgear WPN802v2).

I'll close the bug. Sorry to take up your time.

[gregorio]

Milestone Never Assigned deleted