Version: (using KDE 4.2.2) OS: Linux Installed from: Ubuntu Packages Recently I upgraded from plain old stable KDE 3.5 to KDE 4.2 (I just installed the latest Kubuntu CD). The first thing I wanted to do is connect to my WiFi network, which has a WEP encryption key. Yes, I know it's unsafe and old and all that, but I have some old harware in the network that doesn't support WPA. To my great surprise, in the new KNetworkManager, it is *impossible* to enter the WEP key in ASCII, only in HEX. So what I had to do was either 1) Convert the ASCII key to HEX using an on-line converter on another PC or 2) killall NetworkManager, connect using iwconfig and the "key s:asciikey" parameter. I used the latter method. What strikes me most is that in the previous networkmanager of KDE 3.5, it was perfectly possible to enter an ASCII WEP key. I know it's a more-or-less deprecated technology, but seriously guys, a lot of people still use it. Please, pretty please, return this functionality.
passphrases for 128 bit keys are supported - do you mean 64 bit ascii keys? We tried to implement this but there does not seem to be a standard hashing algorithm for 40/64 bit. What worked on one router failed on another.
(In reply to comment #1) > passphrases for 128 bit keys are supported - do you mean 64 bit ascii keys? We > tried to implement this but there does not seem to be a standard hashing > algorithm for 40/64 bit. What worked on one router failed on another. Hi Will, thanks for your reply. I am indeed talking about ASCII keys, but I'm not sure how much bit they are. I don't see why there would be a problem with the hashing algorithm; I suppose you use iwconfig underneath, and using the "key s:<asciikey>" parameter automatically converts ASCII to HEX. And of course it was working perfectly before in the KDE 3.5 version :)
NM uses wpa_supplicant internally, but that's an implementation detail. It expects to be given the hashed hex key, derived from the ascii key or passphrase by the applet. For 40/64 bit WEP there is no standard algorithm, so the algorithm used in KDE 3.5 knetworkmanager worked for some people and not for others depending on the AP used, so we took the decision to remove it. PS you can see your key length with iwconfig once you are connected, it will be either 10 or 26 hex digits long.
I don't think iwconfig shows the length of the key, but here is the complete (obfuscated (x)) output: $ iwconfig wlan0 wlan0 IEEE 802.11abg ESSID:"accesspoint" Mode:Managed Frequency:2.462 GHz Access Point: 00:DE:AD:BE:EF:11 Bit Rate=54 Mb/s Tx-Power=15 dBm Retry min limit:7 RTS thr:off Fragment thr=2352 B Encryption key:xxxx-xxxx-xx Security mode:open Power Management:off Link Quality=77/100 Signal level:-57 dBm Noise level=-90 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 Then there's also this: $ sudo iwlist wlan0 keys wlan0 2 key sizes : 40, 104bits 4 keys available : [1]: xxxx-xxxx-xx (40 bits) [2]: off [3]: off [4]: off Current Transmit Key: [1] Security mode:open I hope it's of any use to you, please let me know if you need more information.
xxxx-xxxx-xx - 10 x's Also the [1]: xxxx-xxxx-xx (40 bits) line tells me it's a 10-digit key - 40 bit WEP uses 10 hex digits, 104 bit uses 26. Sorry I can't do more for you - it was luck that KDE 3 knetworkmanager used the same algorithm as your AP, but we had a lot of bug reports from people who it didn't work for. See this site for why generating 40 bit WEP keys from passphrases cannot work reliably unless you control both the AP software and the client software. http://www.csgnetwork.com/wepgeneratorcalc.html The generator at that site hashes the string "maryhadalittlelamb" to a different value that the Netgear AP I'm testing with.
Okay, no problem, WEP is deprecated anyway. I have one last question though, how can the wireless manager in Windows XP or MacOS X know which algorithm to use? And it seems like iwconfig with the "key s:" option also knows this, or am I seeing this wrong? Thanks for your time.
I don't know. Perhaps it works by coincidence with your APs. Perhaps I'm wrong, but I don't have time right now to investigate. If you have a look at the iwconfig sources and see what it does, I could use that information later on to add a reliable set of hashing functions.
I appreciate the difficulties with 64bit WEP keys. However, I submit that it is preferable to permit a user to attempt connection using the algorithms that were formerly permitted, albeit with a warning message that usage is deprecated and may not work. Even if it doesn't work with half the connections it is not rational to deny any connections via this method. In any event, I would suggest that when a user attempts to enter a 64bit WEP key, rather than just having their connection refused, a message should display explaining why their connection isn't working, and what they may do to about (get a HEX key, or use WPA for example). This would at least prevent some users worrying what was going wrong with their computer, and attempting all kinds of fixes (aggravated further since they may have no internet connection to research the problem, and if their WEP key and connection used to work fine with KDE or Windows).
Downstream: https://bugzilla.novell.com/show_bug.cgi?id=498284 https://bugs.edge.launchpad.net/ubuntu/+source/plasma-widget-network-manager/+bug/339313/comments/88
Kubuntu bug moved to https://bugs.launchpad.net/knetworkmanager/+bug/453260
SVN commit 1038524 by wstephens: Allow WEP keys to be entered as ASCII (not passphrases). I misunderstood the bug report initially, confusing the simple conversion of an ascii string to pairs of hex digits with the passphrase hashing approach. BUG: 199786 M +16 -4 backends/NetworkManager/settings/802-11-wireless-securitydbus.cpp M +1 -1 libs/ui/security/wep.ui M +18 -20 libs/ui/security/wepwidget.cpp M +2 -0 libs/ui/security/wirelesssecuritysettingwidget.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1038524