wpa_gui cannot talk to wpa_supplicant. Whenever I start it up I see the status message "Could not get status from wpa_supplicant". I have been using wpa_supplicant for a while now and had the gui portion working, but haven't had to use the gui for a while (at least 6 months). I tried to use it today to connect to a new network and can't get it running. I tried re-emerging, I tired it with different use flags. Nothing I tried works and I can't seem to find anything on the web. It used to work. That's how most of the network blocks made it into my wpa_supplicant.conf file. below are my net file, my wpa_supplicant.conf file and some other data that may be useful. /etc/conf.d/net: modules=( "wpa_supplicant" ) wpa_supplicant_wlan0="-Dwext" config_wlan0=( "dhcp" ) /etc/wpa_supplicant/wpa_supplicant.conf: ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel update_config=1 ap_scan=1 running wpa related processes: [ root@Panacea:/home/jdwieber ]# ps -ef | grep wpa root 15376 1 0 13:06 ? 00:00:00 /sbin/wpa_supplicant -Dwext -c/etc/wpa_supplicant/wpa_supplicant.conf -W -W -B -iwlan0 -P/var/run/wpa_supplicant-wlan0.pid root 15387 1 0 13:06 ? 00:00:00 /bin/wpa_cli -a/etc/wpa_supplicant/wpa_cli.sh -p/var/run/wpa_supplicant -iwlan0 -P/var/run/wpa_cli-wlan0.pid -B current version: net-wireless/wpa_supplicant-0.6.9 USE="dbus eap-sim qt4 readline ssl wps -debug -fasteap -gnutls -madwifi (-ps3) -qt3" Reproducible: Always Steps to Reproduce: 1.emerge wpa_supplicant 2.configure and have a working wireless network 3.start wpa_gui to try and modify wireless connections Actual Results: The gui simply states "Could not get status from wpa_supplicant" and then does nothing. Expected Results: The ability to manage wireless connections.
I'm sorry for the patronizing question, but are you certain that your user is a member of wheel? The version works for me, but I had a similar problem that I discovered when I ran wpa_gui as root, and it worked fine.
Thanks for the quick response. No worries, it's not a patronizing question. It is something that needed to be asked. I wish it were that easy, but I am the user and my primary group is wheel. I thought it might be a permissions thing too, so to test it I tried running wpa_gui from a terminal as root, but it never shows up. The process creates, but I never get the gui. Not sure why that is. In any case, I am in group wheel and it used to work. I don't use it often since my laptop is mainly used as a mobile desktop, gut when I do go someplace new I'd like to have a gui to configure any new wireless connection. I'm not familiar with how the two pieces communicate. Is there a log file I can look at? I didn't see any messages written to syslog. Also, if I launch wpa_gui from a terminal as my normal user I don't see any diagnostics written to stdout of stderr. I'm not sure what I did to break it, or how long ago it actually stopped working. Thanks.
I have the same thing. Only in my case wpa_gui shows up when called as root. And then it works. This points to a permission problem. The directory /var/run/wpa_supplicant/ and the socket wlan0 below are both owned by root:root. Changing both to root:wheel allows wpa_gui to work. Only I don't know how to create the socket with root:wheel ownership, nor do I know if changing the ownership of these files is the 'clean' way of fixing this...
Michel, Not only does wpa_gui not run if I call it as root, it also fails if I setuid for /usr/bin/wpa_gui. I don't know why it doesn't run for me as root, or with root privileges. If it works for you when you run it as root, then that leads me to believe it's a permissions issue. It seems odd that no one else is having this problem. Are you AMD64 as well?
Joseph, I am amd64 as well. (core 2 duo). I have tried to set /usr/bin/wpa_gui suid root, and then it works also. Changing the permissions of the /var/run/wpa_supplicant directory, and the socket do not hold between reboots. The files are created during boot, I think. In my wpa_supplicant crtl_interface_group was set to 0. Changing it to wheel -- as you did -- changes the group (as it should) and then wpa_gui can talk to wpa_supplicant, without problems. Have you checked permissions of /var/run/wpa_supplicant and /var/run/wpa_supplicant/wlan0 (the socket wpa_gui talks to)? Have you tried -Dnl80211 instead of -Dwext as driver?
Michel, Glad to hear that it works for you now. The only two drivers I can use are ndiswrapper and wext. Neither one allows wpa_gui to talk to wpa_supplicant. Ironically when I use ndiswrapper as my driver (which is the actual driver I have installed) wpa fails to connect to my router and only connects to routers that are wide open. So, I just use wext. My /var/run/wpa_supplicant directory and both files in that directory are root:wheel.
I had the same problem. I am currently running wpa_supplicant-0.7.1 the option: ctrl_interface_group=wheel has given me errors, as such "/etc/init.d/wpa_supplicant start" fails to execute but when I make the following changes in /etc/wpa_supplicant/wpa_supplicant.conf from: ctr_interface=/var/run/wpa_supplicant to ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel the error message given by wpa_gui vanishes (I am a member of group wheel) I hope this will be helpful
FL, I just upgraded my wpa_supplicant to wpa_supplicant-0.7.1 (even though it's masked ~) but still get the same "Could not get status from wpa_supplicant" message. I tried using both my original /etc/wpa_supplicant/wpa_supplicant.conf ctr_interface line and the new one that you gave me. Neither gave me an error, but neither allowed wpa_gui to work. Thanks for trying though. I'm gettng so few replies on this bug that I'm thinking that it's not a bug with wpa, but something specific to my system. The only thing I haven't tried yet is switching from ndiswrapper to the kernel network driver for my broadcom "air force one" card. In my net config file I have to use -Dwext because -Dndiswrapper fails to connect to any secured AP. Maybe I need to dump ndiswrapper and try the broadcom driver. It's just so much more convenient to have a gui to manage my wireless connections. It's also a tad embarrassing being the only Linux advocate in my group. If you have any other suggestions pleas send them my way. Do you know if there is some error or trace log that wpa_gui writes to? Thanks again.
I think the ndiswrapper driver for wpa_supplicant seems to be deprecated when the version of ndiswrapper is >1.12 and you have to resort to -Dwext. Also you do not need anything that has to do with the gentoo network configuration that relies on /etc/conf.d/net and /etc/init.d/net.* /etc/init.d/wpa_supplicant does everything for you. Afterwards you only have to start "dhcpcd your wlan interface" manually or with /etc/init.d/dhcpcd (which also chooses the inteface automatically for you) You also cannot rely only solely on wpa_gui, you have to start wpa_supplicant as root via the init.d scripts yourself before wpa_gui does anything, which means you have to set your network configuration in /etc/wpa_supplicant/wpa_supplicant.conf. wpa_supplicant -i your_wlan_interface -D wext -c /etc/wpa_supplicant/wpa_supplicant.conf -d prints a lot of debugging output. But you maybe need to paste it and get somebody with some understanding to read it because the what it prints out is somewhat hard to understand. This are at least my conditions to get it to work. Sorry if I have repeated myself here somewhere. Should your kernel driver work as good as ndiswrapper then I can only say change it.
FL, I'm using net-wireless/ndiswrapper-1.55-r1. I don't have a wpa_supplicant init script, or a dhcpd init script. /etc/init.d/net.wlan0 starts all that for me. This laptop install is old. I first installed it in 2005 and have only done upgrades through portage with no major changes to the initial install. I don't remember the steps I had to take for wireless setup/configuration. Maybe there was some upgrade that I missed? It seems strange that I don't have a wpa_supplicant inti script. When the wlan0 init script runs it starts * Starting wlan0 * Starting wpa_supplicant on wlan0 ... [ ok ] * Starting wpa_cli on wlan0 ... [ ok ] * Backgrounding ... and starts these two daemons: [ root@Panacea:/etc/init.d ]# ps -ef | grep wpa root 25991 1 0 Feb20 ? 00:00:00 /sbin/wpa_supplicant -Dwext -c/etc/wpa_supplicant/wpa_supplicant.conf -W -W -B -iwlan0 -P/var/run/wpa_supplicant-wlan0.pid root 26002 1 0 Feb20 ? 00:00:00 /bin/wpa_cli -a/etc/wpa_supplicant/wpa_cli.sh -p/var/run/wpa_supplicant -iwlan0 -P/var/run/wpa_cli-wlan0.pid -B I'll run the wpa_supplicant command later today and post it's output. Maybe you can have a look at it and tell me what I did wrong. Thanks for the info.
No, sorry. Files like /etc/init.d/wpa_supplicant and /etc/init.d/dhcpcd only are installed if you have changed from baselayout-1.x to baselayout-2.x + openrc with a version higher than 0.5. Sadly I have never configured wlan for the old baselayout and only ever set it up by hand, because the old one was at that time to confusing (at least for me). As such I am sorry to say but I do not know the inner workings of baselayout-1.x anymore (as much as I have read through the scripts), and won't be as such of much help. Someone with experience in wlan configuration with baselayout-1.x should be more help.
FL, I didn't know there was another baselayout. I'm on sys-apps/baselayout-1.12.13. But I guess that's soon to change. The migration documentation seems fairly straight forward. Of course I'll image my system before doing it. I'll post when I'm done with it. Thanks for all the info., you've been a big help.
Well, I went to migrate to baselayout-2 and openrc and discovered both are masked ~AMD64, so I won't be migrating at this time. I guess the question remains then, why doesn't my wpa_gui work under the old baselayout and the old rc system.
I've used wpa_supplicant for quite a while, and the gui also recently stopped working for me, I think it was just after an upgrade to the 0.7.1. I'm using baselayout-2. When I try to run wpa_cli, a more detailed error shows up: $ wpa_cli [snip] Selected interface '.keep_net-wireless_wpa_supplicant-0' Could not connect to wpa_supplicant - re-trying It seems that wpa_gui and wpa_cli are trying to open the .keep file in the same directory as the socket(s) wpa uses for its internal communication. I've found out that if I run wpa_gui (or wpa_cli) with a interface name, ex. $ wpa_gui -i ath0 then it works. (I'm using madwifi-ng drivers hence ath0, most people would probably use wlan0) I wonder if/why is the .keep file in /var/run/wpa_supplicant needed. I've deleted the whole directory /var/run/wpa_supplicant and after bringing the wireless interface back on (and thus starting wpa_supplicant) it was created automatically (and with the right permissions). And without the .keep file wpa_[gui,cli] works again as it worked before.
Carlos, I don't get the same error as you regarding the .keep files, but running wpa_cli without parameters showed that it is choosing the wrong interface. In my case it is choosing eth1. Also, when I run wpa_gui and wpa_cli with -i wlan0 they both work perfectly. According to the man pages both apps will default to the first interface found with a control socket in the socket path. I removed /var/run/wpa_supplicant/eth1 and left only wlan0 and now both work as expected without -i wlan0. I remember at some point in time an upgrade to dbus created eth1 in place of wlan0 and a later upgrade went back to using wlan0. I guess that's where the eth1 control socket came from. In any case thank you for your post as it certainly led to the solution. As for the .keep file in that directory, I don't know why wpa would be using it. It's my understanding that .keep files are only used to prevent portage from deleting that directory if you unmerge wpa_supplicant.
(In reply to comment #15) Sorry, I wrote dbus when I meant udev. Sleep deprivation is a terrible thing.
