After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 736206 - NM+WPA_Supplicant+Systemd: "no configuration found for current AP"
NM+WPA_Supplicant+Systemd: "no configuration found for current AP"
Status: RESOLVED NOTABUG
Product: NetworkManager
Classification: Platform
Component: Wi-Fi
0.9.8
Other Linux
: Normal blocker
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2014-09-06 19:55 UTC by ndobrynin
Modified: 2014-10-19 11:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
journalctl | grep NetworkManager (135.88 KB, text/plain)
2014-10-09 18:45 UTC, ndobrynin
Details

Description ndobrynin 2014-09-06 19:55:08 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
Comment 1 ndobrynin 2014-09-08 22:16:42 UTC
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.
Comment 2 Pavel Simerda 2014-09-09 07:55:49 UTC
(In reply to comment #0)
> but everything works fine on the same configuration when DHCPCD is used instead

Please describe how you connect successfully.
Comment 3 ndobrynin 2014-09-09 08:49:22 UTC
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.
Comment 4 Pavel Simerda 2014-09-09 09:11:41 UTC
(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.
Comment 5 Pavel Simerda 2014-09-09 09:30:34 UTC
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
Comment 6 Pavel Simerda 2014-09-09 09:39:34 UTC
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?
Comment 7 ndobrynin 2014-09-09 11:01:35 UTC
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.
Comment 8 Pavel Simerda 2014-09-09 13:14:02 UTC
(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?
Comment 9 ndobrynin 2014-09-09 14:23:40 UTC
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.
Comment 10 ndobrynin 2014-09-10 02:07:36 UTC
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.
Comment 11 Pavel Simerda 2014-09-10 06:10:01 UTC
(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.
Comment 12 Dan Williams 2014-09-11 21:55:43 UTC
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.
Comment 13 Dan Williams 2014-09-11 22:02:44 UTC
(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!
Comment 14 ndobrynin 2014-09-24 10:54:49 UTC
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
Comment 15 ndobrynin 2014-10-06 13:26:51 UTC
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.
Comment 16 Thomas Haller 2014-10-07 09:22:42 UTC
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.
Comment 17 ndobrynin 2014-10-07 21:00:31 UTC
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.  :(
Comment 18 Thomas Haller 2014-10-08 07:07:34 UTC
(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
Comment 19 ndobrynin 2014-10-09 18:45:54 UTC
Created attachment 288167 [details]
journalctl | grep NetworkManager
Comment 20 ndobrynin 2014-10-09 18:54:59 UTC
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!
Comment 21 ndobrynin 2014-10-11 23:32:33 UTC
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
Comment 22 ndobrynin 2014-10-15 01:55:27 UTC
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.