GNOME Bugzilla – Bug 736206
NM+WPA_Supplicant+Systemd: "no configuration found for current AP"
Last modified: 2014-10-19 11:23:40 UTC
Synopsis: the NM cannot connect to a public unsecured WiFi (but everything works fine on the same configuration when DHCPCD is used instead). This is what I get: [ 799.221237] wlp3s0: authenticate with 88:dc:96:03:5b:28 [ 799.222218] wlp3s0: send auth to 88:dc:96:03:5b:28 (try 1/3) [ 799.222485] iw (330) used greatest stack depth: 3440 bytes left [ 799.448774] iwlwifi 0000:03:00.0: No association and the time event is over already... [ 799.449128] wlp3s0: Connection to AP 88:dc:96:03:5b:28 lost [ 801.622309] wlp3s0: authenticated [ 801.623528] wlp3s0: associate with 88:dc:96:03:5b:28 (try 1/3) [ 801.629812] wlp3s0: RX AssocResp from 88:dc:96:03:5b:28 (capab=0x401 status=0 aid=5) [ 801.634424] wlp3s0: associated [ 801.634899] wlp3s0: deauthenticating from 88:dc:96:03:5b:28 by local choice (reason=3) [ 801.636289] iwlwifi 0000:03:00.0: Drained sta 1, but it is internal? I've exhausted at least two major avenues before filing this, so I am going to link to those instead of reproducing them here. http://forums.gentoo.org/viewtopic-t-998728.html?sid=b80692cdccc4a89301d1f27d500c4ceb https://mail.gnome.org/archives/networkmanager-list/2014-September/msg00010.html
I am wondering if somebody could *please* follow up while I'm still on this particular WiFi, and my laptop has this particular set up, so we can catch the bug (or my stupidity :) in action. As much as I wish I could freeze this, I need a working environment, so if nothing can be done to get this fixed, then I will have no choice but to switch to a different desktop. I want to get this working, so help is hugely appreciated. Many thanks.
(In reply to comment #0) > but everything works fine on the same configuration when DHCPCD is used instead Please describe how you connect successfully.
Pavel, It is extremely simple. As I pointed out, I connect using WPA Supplicant and DHCPCD while keeping the NM off. The steps are 1. systemctl start wpa_supplicant 2. systemctl start dhcpcd 3. iw dev wlp3s0 connect NetworkName 4. This may or may not be relevant. The WiFi I'm on is public but has a login page one has to go through to agree to terms and conditions. Once you do, you can use the Internet. (The "I agree" part can be done with a browser but I wrote a simple bash script that does a POST request. The result is the same as if I clicked "I agree to terms and conditions" but doesn't require a graphical environment). Does everything make sense? Many thanks.
(In reply to comment #3) > Pavel, > > It is extremely simple. As I pointed out, I connect using WPA Supplicant and > DHCPCD while keeping the NM off. The steps are > > 1. systemctl start wpa_supplicant If wpa_supplicant is already configured (missing the configuration here), then this step should be enough to get wifi up and running and see it in the logs and have the possibility to check it with the iw command. > 2. systemctl start dhcpcd I typically only use software like dhclient and dhcpcd as DHCP clients or as single network interface configurators, thus I only run it directly. If the first step was successful, I guess this second step (if dhcpcd properly configured, maybe even by default?), you should now have a fully working network. > 3. iw dev wlp3s0 connect NetworkName 1) No idea why this should be needed at all. Maybe because you run wpa_supplicant unconfigured? I wasn't aware that wpa_supplicant is any helpful in that case. Maybe someone proficient in wifi will answer. 2) For open wifi networks, this step could replace step 1 because kernel alone is capable of connecting to those networks and wpa_supplicant shouldn't be needed at all. > 4. This may or may not be relevant. The WiFi I'm on is public but has a login > page one has to go through to agree to terms and conditions. That should be the next step after connecting on the link level (iw or wpa_supplicant) and configuring the network layer (ip, dhclient or dhcpcd). > Does everything make sense? Not yet. If the wifi network is not authenticated, iw alone and wpa_supplicant alone should work for you to get the link set up, unless I missed something. Using both of them looks somewhat tricky to me.
Just found in your post in the forum[1] that you assume wpa_supplicant succeeds with dhcpcd and fails with NetworkManager. That's IMO a misunderstanding of the situation. In my opinion it fails *always* but you then use iw to connect, not wpa_supplicant. That would explain a lot. NetworkManager, on the other hand, relies on wpa_supplicant. I'm not so proficient in wireless networking, so I may be wrong, but I think that the only problem is in wpa_supplicant. [1] http://forums.gentoo.org/viewtopic-t-998728.html?sid=b80692cdccc4a89301d1f27d500c4ceb
Could you please also link to this bugzilla in the gentoo forum and in the mailing list so that people end up here when looking up further information?
1. You were right! I don't need WPA Supplicant to connect. DHCPCD and 'iw' suffice. (I'm amazed that nobody brought this up on the Gentoo forum). 2. I've linked to this thread in forums.gentoo, as you requested. 3. My WPA Supp configuration file is: ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel update_config=1 ap_scan=1 network={ key_mgmt=NONE priority=-999 } Unless you say otherwise, there's just no place for a mistake.
(In reply to comment #7) > 1. You were right! I don't need WPA Supplicant to connect. DHCPCD and 'iw' > suffice. (I'm amazed that nobody brought this up on the Gentoo forum). That also explains the difference between the two methods and suggest the problem is probably not in the kernel, so it's either a bug in wpa_supplicant or in something wpa_supplicant gets information from (config+NetworkManager, the accesspoint, ...), this is unfortunately out of my knowledge and experience. > 2. I've linked to this thread in forums.gentoo, as you requested. Thanks! > 3. My WPA Supp configuration file is: > > ctrl_interface=/var/run/wpa_supplicant > ctrl_interface_group=wheel > update_config=1 > ap_scan=1 > network={ > key_mgmt=NONE > priority=-999 > } So where's the SSID you're going to connect to? When using NetworkManager, it's supplied by NetworkManager using the stored configuration often originally created using the information from scanning but when using wpa_supplicant, it should be explicitly stated in the configuration file, no?
For debugging only, I did have my network's SSID in wpa_supplicant.conf, but that didn't matter. I always resisted hardcoding SSIDs for the simple reason that this makes the set up non-generic. I have a working Fedora installation. Its wpa_supplicant.conf is even more innocuous: ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel Thanks again.
Pavel, I hope this is general enough for you to be able to answer. (And I very much hope others will also speak up). I want to log the parameters NM passes to WPA Supp during API call(s), the functions that get called, the sequence, etc. Do you know how this is done? Some env variable I could set? This is Gentoo-specific, so it won't necessarily make sense: the NM ebuild has a "{test}" USE flag, which is disabled. Should I enable it? At present, my NM is compiled with the support for dhcpcd/wifi/wext/systemd enabled and for dhclient/resolvconf disabled.
(In reply to comment #9) > I always resisted hardcoding SSIDs for the simple reason that this makes the > set up non-generic. I have a working Fedora installation. Its > wpa_supplicant.conf is even more innocuous: Just curious, are there any docs for using wpa_supplicant without specific SSID configuration? (In reply to comment #10) > Pavel, I hope this is general enough for you to be able to answer. (And I very > much hope others will also speak up). I want to log the parameters NM passes > to WPA Supp during API call(s), the functions that get called, the sequence, > etc. Do you know how this is done? Some env variable I could set? To extend logging, you can set up the logging domains and levels either on the command line or in the configuration. See manual pages for NetworkManager and NetworkManager.conf. > This is Gentoo-specific, so it won't necessarily make sense: the NM ebuild has > a "{test}" USE flag, which is disabled. Should I enable it? No. It's only for running the test suite in my opinion. I'm a Gentoo user as well, by the way see my live ebuild[1] if interested. [1] https://github.com/okias/ixit/blob/master/net-misc/networkmanager/networkmanager-9999.ebuild > At present, my NM is compiled with the support for > dhcpcd/wifi/wext/systemd enabled and for dhclient/resolvconf > disabled. I generally recommend using dhclient instead of dhcp and the gentoo devs just fail to realize dhcpcd won't bring them any advantages when used with NetworkManager, but that's not related to your issue. You don't need wext (but shouldn't do any harm) as your wifi apparently is apparently supported via nl80211. Keep systemd turned on in order to support systemd-logind and systemd power management.
You don't need wpa_supplicant to connect to a open wifi networks. At least for NetworkManager though, which uses the supplicant for all wifi operations, it doesn't make sense to have two different codepaths, one for open and one for everything else. So the supplicant is used for all wifi control. NetworkManager logs the parameters it sends to the supplicant in syslog (or systemd journal) which look like this: NetworkManager[804]: <info> Config: added 'ssid' value 'my ssid here' NetworkManager[804]: <info> Config: added 'scan_ssid' value '1' NetworkManager[804]: <info> Config: added 'key_mgmt' value 'WPA-PSK' NetworkManager[804]: <info> Config: added 'psk' value '<omitted>' NetworkManager[804]: <info> Config: added 'proto' value 'WPA RSN' this roughly corresponds to what goes into the wpa_supplicant config file's network block.
(In reply to comment #9) > For debugging only, I did have my network's SSID in wpa_supplicant.conf, but > that didn't matter. > > I always resisted hardcoding SSIDs for the simple reason that this makes the > set up non-generic. I have a working Fedora installation. Its > wpa_supplicant.conf is even more innocuous: > > ctrl_interface=/var/run/wpa_supplicant > ctrl_interface_group=wheel This config means there are no preconfigured networks set up. Any network you want to connect to with the supplicant requires a network block that includes an SSID. What I would do to test the setup is to construct a minimal supplicant configuration file with the SSID: network={ ssid="the ssid" key_mgmt=NONE } stop NetworkManager, kill the existing supplicant, and run a new supplicant like so: wpa_supplicant -dddt -c/path/to/config/file -Dnl80211 -iwlan0 and wait for at least 30 seconds. Then get the debug output (enabled by -dddt) and attach to this bug so we can analyze it. Also, the NetworkManager logs from when it attempts to connect would be useful. Thanks!
Dan, For information's sake, I'm now using a different wireless connection -- hidden and encrypted. You said that WPA Supplicant is used no matter what, so this probably shouldn't matter. With the NetworkManager absent, I execute wpa_supplicant -dddt -c/path/to/config/file -Dnl80211 -iwlp3s0 and start DHCPCD. It connects flawlessly. Great! I then comment out the "network={}" statement in wpa_supplicant.conf, invoke the NetworkManager (without manually starting WPA Supp), and frustration starts again: nowhere in the log file does it mention anything similar to, e.g. NetworkManager[804]: <info> Config: added 'ssid' value 'my ssid here' It's as if the NM starts WPA Supp up and loses track of it. I start GNOME, go to the network applet, click "Connect to Hidden Network", type the credentials in, and nothing happens, exactly as it was before. Sep 24 04:02:39 gazelle-laptop NetworkManager[262]: <info> NetworkManager (version 0.9.8.10) is starting... Sep 24 04:02:39 gazelle-laptop NetworkManager[262]: <info> Read config file /etc/NetworkManager/NetworkManager.conf Sep 24 04:02:39 gazelle-laptop NetworkManager[262]: <info> WEXT support is enabled Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: Error parsing file '/etc/NetworkManager/NetworkManager.conf': No such file or directory Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: <info> Loaded plugin keyfile: (c) 2007 - 2010 Red Hat, Inc. To report bugs please use the NetworkManager mailing list. Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: Error parsing file '/etc/NetworkManager/NetworkManager.conf': No such file or directory Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: keyfile: parsing .keep_net-misc_networkmanager-0 ... Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: Connection failed to verify: (unknown) Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: keyfile: error: invalid or missing connection property '(null)/connection setting not found' Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: Error parsing file '/etc/NetworkManager/NetworkManager.conf': No such file or directory Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: <info> monitoring kernel firmware directory '/lib/firmware'. Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: <info> rfkill0: found WiFi radio killswitch (at /sys/devices/pci0000:00/0000:00:1c.2/0000:03:00.0/ieee80211/phy0/rfkill0) (driver iwlwifi) Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: <info> WiFi hardware radio set enabled Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: <info> WiFi enabled by radio killswitch; enabled by state file Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: <info> WWAN enabled by radio killswitch; enabled by state file Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: <info> WiMAX enabled by radio killswitch; enabled by state file Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: <info> Networking is enabled by state file Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: <info> (wlp3s0): using nl80211 for WiFi device control Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: <info> (wlp3s0): driver supports Access Point (AP) mode Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: <info> (wlp3s0): new 802.11 WiFi device (driver: 'iwlwifi' ifindex: 4) Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: <info> (wlp3s0): exported as /org/freedesktop/NetworkManager/Devices/0 Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: <info> (wlp3s0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2] Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: <info> (wlp3s0): bringing up device. Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: <info> (wlp3s0): preparing device. Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: <info> (wlp3s0): deactivating device (reason 'managed') [2] Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: <warn> failed to allocate link cache: (-26) Protocol mismatch Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: <info> (enp4s0f2): carrier is OFF Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: <info> (enp4s0f2): new Ethernet device (driver: 'r8169' ifindex: 3) Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: <info> (enp4s0f2): exported as /org/freedesktop/NetworkManager/Devices/1 Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: <info> (enp4s0f2): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2] Sep 24 04:02:40 gazelle-laptop NetworkManager[262]: <info> (enp4s0f2): bringing up device. Sep 24 04:02:41 gazelle-laptop NetworkManager[262]: <info> (enp4s0f2): preparing device. Sep 24 04:02:41 gazelle-laptop NetworkManager[262]: <info> (enp4s0f2): deactivating device (reason 'managed') [2] Sep 24 04:02:41 gazelle-laptop NetworkManager[262]: <info> Added default wired connection 'Wired connection 1' for /sys/devices/pci0000:00/0000:00:1c.3/0000:04:00.2/net/enp4s0f2 Sep 24 04:02:41 gazelle-laptop NetworkManager[262]: <warn> /sys/devices/virtual/net/lo: couldn't determine device driver; ignoring... Sep 24 04:02:41 gazelle-laptop NetworkManager[262]: <warn> /sys/devices/virtual/net/sit0: couldn't determine device driver; ignoring... Sep 24 04:02:41 gazelle-laptop NetworkManager[262]: <warn> /sys/devices/virtual/net/lo: couldn't determine device driver; ignoring... Sep 24 04:02:41 gazelle-laptop NetworkManager[262]: <warn> /sys/devices/virtual/net/sit0: couldn't determine device driver; ignoring... Sep 24 04:02:41 gazelle-laptop NetworkManager[262]: <info> wpa_supplicant started Sep 24 04:02:41 gazelle-laptop NetworkManager[262]: <info> (wlp3s0) supports 5 scan SSIDs Sep 24 04:02:41 gazelle-laptop NetworkManager[262]: <info> (wlp3s0): supplicant interface state: starting -> ready Sep 24 04:02:41 gazelle-laptop NetworkManager[262]: <info> (wlp3s0): device state change: unavailable -> disconnected (reason 'supplicant-available') [20 30 42] Sep 24 04:02:41 gazelle-laptop NetworkManager[262]: <warn> Trying to remove a non-existant call id. Sep 24 04:02:41 gazelle-laptop NetworkManager[262]: <info> (wlp3s0): supplicant interface state: ready -> disconnected Sep 24 04:02:41 gazelle-laptop NetworkManager[262]: <info> (wlp3s0) supports 5 scan SSIDs Sep 24 04:02:44 gazelle-laptop NetworkManager[262]: <info> (wlp3s0): supplicant interface state: disconnected -> inactive
Pardon the impatience, can somebody pls indicate if more information is needed? Still hope to get this working. Maybe the problem is in GNOME's NM applet? The applet shows a bunch of networks, but clicking and trying to connect makes no difference at all, as the log above shows - the behavior I've been seeing from the start, even before I got WPA Supp working (as per previous message). What other debugging options are there? Many thanks.
Just checking: you are aware that NM expects to start it's own instance of dhclient/dhcpcd? Hence, make sure that you don't have another dhcp service running (on the same interface) because they will interfere badly.
Thomas, yes, I am aware. But, unlike WPA Supplicant, I see no NM-created DHCP (DHCPCD on Gentoo) instance running. Is this bad? Or maybe DHCP runs inside the NM process? PS I've been trying to solve this for almost 2 months now. :(
(In reply to comment #17) > Thomas, yes, I am aware. But, unlike WPA Supplicant, I see no NM-created DHCP > (DHCPCD on Gentoo) instance running. Is this bad? Or maybe DHCP runs inside > the NM process? > > PS I've been trying to solve this for almost 2 months now. :( I think you should see that NM spawned a dhcpcd child process. But in the logfile that you pasted, there is also no visible attempt to connect. I suppose you created a proper connection (e.g. with nm-connection-editor/nm-applet). Then, when you click on "Connect to Hidden Wi-Fi Network" you are selecting the one, right? Can you show the configuration of that connection by pasting /etc/NetworkManager/system-connections/~KEYFILE~ ? Could you please again post a log-file, this time with DEBUG logging enabled? Do this by adding [logging] level=DEBUG domains=ALL to /etc/NetworkManager/NetworkManager.conf -- and restart NM. (maybe better attach the file, the line wrapping when pasting logfile is annoying). Check for private data before posting (but in general, there isn't anything what I would consider private). thank you
Created attachment 288167 [details] journalctl | grep NetworkManager
1. Please see attached. To get this, I ran $ journalctl | grep NetworkManager 2. Except for a .keep file, the directory /etc/NetworkManager/system-connections/ is empty. There is nothing like /etc/NetworkManager/system-connections/~KEYFILE~ there. 3. I tried connecting to a visible/non-hidden network - the applet never came back to ask for password. 4. /etc/NetworkManager/NetworkManager.conf did not exist, so I created it. Many thanks!
Much progress. It only appears to fail when I run GNOME as non-root. Unless you disagree, permissions are to blame. If somebody can suggest the best way to escalate them for NM applet, please do. Otherwise, I've already posted on the Gentoo forum: http://forums.gentoo.org/viewtopic-t-1001820.html
It works! polkit permissions were messing things up. Then I found https://wiki.archlinux.org/index.php/NetworkManager (scroll down to "Set up PolicyKit permissions"), and it did the trick. I must wonder why Gentoo does not ship this little tweak with GNOME. Would save so much time and frustration. PS The link in previous post is dead: I deleted the question.