Description of problem: NetworkManager currently has these menues for entering WEP: "WEP 40/128-bit Key" "WEP 128 bit passphase" I'm leaving out others that are not commonly used in home environment. I saw lots of users having issues with "WEP 40/128-bit Key" being the default option and when using ASCII keys. I would suggest to use one simple but very effective mechanism for deteremening if key enterer is 40/104-bit, HEX or ASCII. HEX keys have lenght of 10 characters for 40-bit, and 26 characters for 104-bit keys. ASCII keys have lenght of 5 or 13 characters. Could this be incoroprated into NetworkManager so that the menu chooses appropriate type and lenght of key by the lenght of characers that users enters? Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
(In reply to comment #0) > Description of problem: > NetworkManager currently has these menues for entering WEP: > "WEP 40/128-bit Key" > "WEP 128 bit passphase" > > I'm leaving out others that are not commonly used in home environment. > > I saw lots of users having issues with "WEP 40/128-bit Key" being the default > option and when using ASCII keys. ASCII keys are not actually passphrases, hence they are entered under WEP 40/128-bit Key", so for ASCII keys, this is correct. _Passphrases_ are not actually ASCII keys, but something completely different. WEP sucks. > I would suggest to use one simple but very effective mechanism for deteremening > if key enterer is 40/104-bit, HEX or ASCII. > > HEX keys have lenght of 10 characters for 40-bit, and 26 characters for 104-bit > keys. ASCII keys have lenght of 5 or 13 characters. > > Could this be incoroprated into NetworkManager so that the menu chooses > appropriate type and lenght of key by the lenght of characers that users > enters? This is already what happens when you choose "WEP 40/128-bit Key". NM will auto-detect what the type is based on the length and content. Unfortunately, we cannot distinguish between "passphrase" and "hex/ascii key", because passphrases are arbitrary content strings between 8 and 64 characters long. Thus, there is overlap between 40-bit Hex keys, 128-bit Hex keys, and 13 character ASCII keys, all which are _also_ legal passphrases. I've personally seen organizations use what look like 128-bit Hex keys as passphrases. We also can't re-try different hashing, becuase the only way you can know if the key is wrong is to wait for DHCP to time out. That means that a 45 second timeout before you can try a different hashing type. We might be able to make it somewhat clearer in the UI that "40/128-bit WEP Key" means ASCII too. Any suggestions?
I'm a bit puzzled :) I know of ASCII and HEX WEP keys and these are user everywhere except bigger companies who have additional 802.1x (radius?) servers. WEP or WPA + 802.1x is usually called "enterprise" encryption. So could there be an advanced button for setting up encryption that is not basic WEP? Does this make any sense to you?
(In reply to comment #2) > I'm a bit puzzled :) > > I know of ASCII and HEX WEP keys and these are user everywhere except bigger > companies who have additional 802.1x (radius?) servers. > WEP or WPA + 802.1x is usually called "enterprise" encryption. So could there > be an advanced button for setting up encryption that is not basic WEP? > > Does this make any sense to you? Not really, can you describe a bit more what you mean? When you are asked for the passphrase (for example, when connecting the first time) the menu will only show what the AP supports. The connection editor shows all options, because when editing a conneciton from there, you're obviously not connecting to the AP at that time. So I'm not sure what Dynamic WEP (WEP + 802.1x) and WPA-Enterprise have to do with this bug...
From NM GUI I thought that "WEP 40/128-bit Key" = HEX WEP key and "WEP 128 bit passphase" = ASCII WEP key I googled for NM documentation and found: http://projects.gnome.org/NetworkManager and http://live.gnome.org/NetworkManager and also looked at docs and readme files on my fedora box, I didn't find this explained anywhere. I'm connecting to AP "protected" with 64(40)-bit WEP key and I get these options: "WEP 40/128-bit Key" = HEX WEP key "WEP 128 bit passphase" = ASCII WEP key "LEAP" "Dynamic WEP (802.1x)" In Webadmin of my AP I see no provision for LEAP or 802.1x. Is AP "advertising" these functions (even if they aren't available through web UI) or it NM showing these options even if they aren't supported by AP? Is NetworkManager handling WEP ASCII/HEX, 40/104 keys "automatigically" when users type theis keys with selected "WEP 40/128-bit Key ? Should the more advances options like LEAP and Dynamic WEP be "hidden" behind "advanced button" or something like that? Why?
Created attachment 323887 [details] screenshot
(In reply to comment #4) > From NM GUI I thought that > "WEP 40/128-bit Key" = HEX WEP key > and > "WEP 128 bit passphase" = ASCII WEP key Nope. See, for example (7th hit on google for "WEP Passphrase"): http://www.tech-faq.com/wep-key-passphrase.shtml > I'm connecting to AP "protected" with 64(40)-bit WEP key and I get these > options: > "WEP 40/128-bit Key" = HEX WEP key > "WEP 128 bit passphase" = ASCII WEP key > "LEAP" > "Dynamic WEP (802.1x)" > > In Webadmin of my AP I see no provision for LEAP or 802.1x. Is AP "advertising" > these functions (even if they aren't available through web UI) or it NM showing > these options even if they aren't supported by AP? With WEP, access points don't advertise any capability other than "Privacy". Thus, you simply cannot tell what the access point supports, other than whether or not it is encrypted. "Encrypted" with WEP can mean any of the 4 options that the menu lists. LEAP and Dynamic WEP access points may or may not advertise the "Privacy" bit, but there is nothing in the AP's beacon (like there is with WPA) to indicate whether the AP uses LEAP, Dynamic WEP, 40-bit keys, or 128-bit keys. The user simply has to know. This is another reason why WEP sucks. The AP also doesn't not advertise the Authentication method (Open System or Shared Key). Again, the user simply has to know, otherwise the connection fails. Apple also includes LEAP and Dynamic WEP options in their connection dialog when you select a non-WPA protected wifi network. > Is NetworkManager handling WEP ASCII/HEX, 40/104 keys "automatigically" when > users type theis keys with selected "WEP 40/128-bit Key ? Yes. > Should the more advances options like LEAP and Dynamic WEP be "hidden" behind > "advanced button" or something like that? Why? I don't think so, there are quite a few situations where users may encounter 802.1x protected networks (educational institutions, enterprises, Starbucks, etc) and some of these aren't just in businesses. For WPA, we can autodetect what's going on. But for WEP, we simply cannot. With better drivers and kernel API we _may_ be able to hide the WEP Authentication method combo box however.
Thank you for your great answer and explanation. Should then the "WEP 40/128-bit Key" then changet to something more explanatory like: "WEP 64/128-bit Key (ASCII or HEX)" I believe that it should say 64/128-bit or 40/104-bit 40/128-bit makes no real sense. Maybe leave 64/128-bit even if it is not technically 100% correct but that is what says on wifi routers so that is what users know about.
(In reply to comment #7) > Thank you for your great answer and explanation. > > Should then the "WEP 40/128-bit Key" then changet to something more explanatory > like: "WEP 64/128-bit Key (ASCII or HEX)" This could be done. > I believe that it should say 64/128-bit or 40/104-bit > > 40/128-bit makes no real sense. Maybe leave 64/128-bit even if it is not > technically 100% correct but that is what says on wifi routers so that is what > users know about. 40-bit WEP is the most prevalent terminology for 40/64-bit WEP keys. Technically, the key _is_ only 40 bits long, the other 24 bits are the IV, not the WEP key. 128-bit WEP is the most prevelent terminology for 104/128-bit WEP keys. Mac OS X also uses "40/128-bit WEP" in the Airport UI, which made sense.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. 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 '9'. 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 9'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 9 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
This is no longer an issue, please close this bug.