Description of problem: Every time I configure the wpa2 key (ALL digits), or manually edit /etc/wpa_supplicant.conf with the correct key, the system changes the key from decimal to hex and the connection fails. Even tried making wpa_supp... file read-only; but system changed it back and clobbered the key anyway... ;p ;p Will report back if I can eventually connect; but a clue as to how to prevent this auto dec->hex conversionwould be appreciated.. Opening as separate bug (see bug 12185) Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. attempt to connect to wpa2 AP that has a numeric-only key 2. 3. Reproducible: Steps to Reproduce:
see also bug 12185
out of frustration, installed wpa_gui, deleted this network and created it anew and got connected immediately... well, after many hours of troubleshooting... Since I did connect successfully last time I was at this location, I won't be surprised if this bug kicks in again next time I try to connect... Something is causing wireless networks which have an ALL-numbers key to have that key converted to hex and the connection fails. Found the hexified key in at least these files: /etc/wpa_supplicant.conf /etc/sysconfig/network-scripts/wireless.d/${SSID} /etc/sysconfig/network-scripts/wireless.d/wlp8s0 No amount of correcting these files would solve the problem. Every time I tried starting the network, the hex string would replace the decimal string. Even tried using chmod and chattr in an attempt to stop the rewrites; but whatever is causing this problem just resets all the perms and clobbers the decimal key anyway... :P So using wpa_gui turned out to be a quick(sic) workaround. However, this is still a MAJOR bug for anyone trying to connect to a network who's SSID wpa2 key is all numbers.
Hit Disconnect on drakroam gui and it locked up -- kill -1... Tried to connect and the key is clobbered again... using wpa_gui, deleted the network, recreated it and I'm back on...
This is getting convoluted... (see also bug 12420 where the default gateway does not get set correctly) When traveling back to this location where the numeric key gets clobbered, I have to delete that network and re-create it; so in this case the default gateway does get set, apparently on initial setup...
Have you tested it with NetworkManager?
CC: (none) => mageia
Dumped NM back in mga2 days -- don't recall the reason; but will try again...
I have several wireless bugs open... this one is about all-digits numeric key getting clobbered with hex equivalent which AP does not accept. Installed NM; but a note reads: Starting with networkmanager-0.8.9997-3 systemd support is enable. However systemd is not starting automatically networkmanager. You can enable it (under the root user) via the command line : systemctl enable NetworkManager.service However, it doesn't seem to want to start as indicated... # systemctl status NetworkManager.service NetworkManager.service - Network Manager Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled) Active: inactive (dead) # systemctl enable NetworkManager.service # systemctl status NetworkManager.service NetworkManager.service - Network Manager Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled) Active: inactive (dead)
You need to configure your network interface and during that check the checkbox that this interface is controlled by NM. Then you need to reboot. Now NM should be started. But depending on your DE you also need NM applet for NM. It should be built in into Gnome but for KDE you need plasma-applet-nm. To enable the applet in KDE you have to right click on the icon that shows hidden icons in the system tray and choose options. From there you have to enable network management (you might need another reboot after that) and then you should be able to control your interface with NM. It uses wpa_supplicant as a service and as such I haven't had problems with wpa_supplicant ever since..
Well... not sure if this is why I dumped NM previously... this is a laptop and after installing NM, lid close does not put it to sleep any more... Uninstalled NM and I have lid close -> sleep again... So, NM is not acceptable. Besides, I can't think of any way NM would solve the auto-conversion of a numeric key to a hex key (the purpose of this bug report)...
NM doesn't save its settings in wpa_supplicant's conf. So it probably wouldn't have that problem. About the lid problem.. I have no idea.. haven't had such problem. Probably could be solved with some debugging..
Closing. Seems to have been resolved somehow...
Status: NEW => RESOLVEDResolution: (none) => WORKSFORME