Opened 6 years ago

Last modified 20 months ago

#10385 new defect

Sugar may store invalid WEP keys by accident, make it impossible to access an AP

Reported by: greenfeld Owned by: dsd
Priority: normal Milestone:
Component: sugar Version: not specified
Keywords: Cc:
Blocked By: Blocking:
Deployments affected: Action Needed: never set
Verified: no


This may be a variant or close relative to issue #9977.

Sugar may store invalid WEP keys by accident in connections.cfg, and make it impossible to access an 802.11 Access Point using said WEP key without manually editing or clearing out connections.cfg.

This has been reproduced in both 10.1.2 as well as Fedora Beta 14/Sugar 0.90, which for some reason I have had better luck reproducing this with.


  1. Setup a WEP 128(104)-bit encrypted access point with a known hex-style key.
  2. Attempt to connect to it from the Sugar network view. You should be prompted for the encryption key.
  3. Set the type of key to enter to Hex (not Passphrase) in the dropdown menu.
  4. Enter "Hello" in the field and press the Enter key {even though "OK" should be grayed out and "Cancel" the only choice, as Hello is not a valid Hex number with an acceptable length}.

Expected: The connection attempt is aborted; Sugar goes back to trying to use whatever its previous favorite AP/mesh/ad-hoc network was.

Actual: The connection attempt goes on until Sugar decides to try something else. Restarting the computer and/or attempting to access the AP setup in Step #1 will always fail.

~olpc/sugar/default/nm/connections.cfg will have a line for the AP setup in step #1 that says "key = Hello". This will cause messages to be logged to /var/log/messages that wep_key0 is invalid every time one tries to use this AP, causing Network Manager to try and go on to the next available preferred system almost immediately and never successfully prompt again to get the necessary updated key information.

Change History (5)

comment:1 follow-up: Changed 6 years ago by dsd

Maybe you'll still argue that the behaviour is wrong, but this is at least a little bit debatable.

The problem is that there's no way for the client to know if the connection failure was due to bad WEP key, or if the WEP key was correct but there was a network problem preventing the machine from obtaining a DHCP address (e.g. school server unplugged). The 2 situations appear identical to the XO.

This is due to the simplicity of WEP. There's no key exchange, challenge response, nothing. Just program the key and see if you can communicate with someone that you expect to be on the other end.

comment:2 in reply to: ↑ 1 Changed 6 years ago by greenfeld

Replying to dsd:

Maybe you'll still argue that the behaviour is wrong, but this is at least a little bit debatable.

This bug/issue is not about WEP not knowing when to do quit necessarily; it's more the GUI saving a value when the "OK" button is grayed out and the key entered does not match one of the two allowed formats (a hexdecimal number of one of two lengths) and is therefore invalid. The GUI normally does seem to enforce both the allowed data and lengths when "Hex (40/128 bits)" is selected as the WEP key type by disabling the "OK" button for invalid inputs.

And Network Manager at least in Fedora 14 knows immediately that "Hello" is not a valid WEP key, logging "NetworkManager[pid]: <warn> Invalid WEP key 'wep_key0'" to /var/log/messages, and then going on to the next connection. I do not see this behavior in 10.1.2, so perhaps we will need to do some testing in this area to see if something breaks as we move forward.

comment:3 Changed 6 years ago by dsd

  • Component changed from network manager to sugar
  • Milestone changed from Not Triaged to 11.2.0-M4
  • Owner changed from dsd to erikos

comment:4 Changed 5 years ago by erikos

  • Owner changed from erikos to dsd

Master of connectivity, you may want to have a look.

comment:5 Changed 20 months ago by Quozl

  • Milestone 11.3.0 deleted

Milestone 11.3.0 deleted

Note: See TracTickets for help on using tickets.