Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#44731 - [wpa_supplicant] netctl-auto service for wireless NIC broken after wpa_supplicant upgrade to 2.4-1

Attached to Project: Arch Linux
Opened by Josh Chia (Syncopated) - Saturday, 25 April 2015, 16:38 GMT
Last edited by Evangelos Foutras (foutrelis) - Tuesday, 19 January 2016, 16:24 GMT
Task Type Bug Report
Category Arch Projects
Status Closed
Assigned To Thomas Bächler (brain0)
Evangelos Foutras (foutrelis)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 20
Private No

Details

Description:
Under wpa-supplicant 2.4-1, starting netctl-auto@wlp3s0.service fails connect WiFi, and I can't get a DHCP IP, even though the service is shown as "active (running)"

Additional info:
* netctl 1.10-1, wpa_supplicant 2.4-1, wpa_actiond 1.4-2

Log:
Apr 25 12:44:47 sauron wpa_actiond[6952]: Interface 'wlp3s0' connected to network 'Edward'
Apr 25 12:44:47 sauron dhcpcd[6974]: DUID xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
Apr 25 12:44:47 sauron dhcpcd[6974]: wlp3s0: IAID xx:xx:xx:xx
Apr 25 12:44:47 sauron dhcpcd[6974]: wlp3s0: rebinding lease of 192.168.1.20
Apr 25 12:44:51 sauron dhcpcd[6974]: wlp3s0: leased 192.168.1.20 for 43200 seconds
Apr 25 12:44:51 sauron dhcpcd[6974]: wlp3s0: adding route to 192.168.1.0/24
Apr 25 12:44:51 sauron dhcpcd[6974]: wlp3s0: adding default route via 192.168.1.1
12:55 ~$ journalctl -xe -u netctl-auto@wlp3s0.service
Apr 25 12:36:28 sauron netctl-auto[5505]: Included profile 'wlp3s0-cz'
Apr 25 12:36:28 sauron netctl-auto[5505]: Successfully initialized wpa_supplicant
Apr 25 12:36:28 sauron netctl-auto[5505]: Could not read interface p2p-dev-wlp3s0 flags: No such device
Apr 25 12:36:28 sauron systemd[1]: Started Automatic wireless network connection using netctl profiles.
-- Subject: Unit netctl-auto@wlp3s0.service has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit netctl-auto@wlp3s0.service has finished starting up.

Referenced in this forum thread:
https://bbs.archlinux.org/viewtopic.php?id=196584

Steps to reproduce:
1. Start or restart netctl-auto@wlp3s0.service with systemctl
2. Wait and get no IP address showing up under ifconfig
3. See the "Could not read interface" error in the log
This task depends upon

Closed by  Evangelos Foutras (foutrelis)
Tuesday, 19 January 2016, 16:24 GMT
Reason for closing:  Fixed
Additional comments about closing:  wpa_supplicant 1:2.5-2
Comment by David Scholberg (therealarchdaemon) - Saturday, 25 April 2015, 20:53 GMT
I'm experiencing the same issue. netctl-auto fails to start any profiles, but manually starting a profile with netctl works fine.

Looking deeper at the logs, I noticed this error message from wpa_actiond (which is required by netctl-auto):

Apr 25 16:16:57 archpad wpa_actiond[2571]: Error (wlp3s0): Could not attach to wpa_supplicant

This seems to indicate that wpa_actiond can't attach to wpa_supplicant's control socket for some reason. I don't see this error anytime before the most recent wpa_supplicant upgrade, so it seems to be relevant to this netctl-auto bug.
Comment by Frank Carlyle McLaughlin (frankspace) - Sunday, 26 April 2015, 22:00 GMT
I believe this and bug #44738 to be related.
Comment by Jouke Witteveen (jouke) - Monday, 27 April 2015, 17:09 GMT
I noted a fix has landed. I'll take the patch in the next version, due soon. Thanks go to Evangelos Foutras.
Comment by Evangelos Foutras (foutrelis) - Monday, 27 April 2015, 17:34 GMT
While wifi-menu should work now, it seems that wpa_supplicant 2.4 has other issues with Intel wifi chipsets (segfaults or doesn't enable the control interface). :\
Comment by Benjamin Campbell (benjica) - Tuesday, 08 December 2015, 05:54 GMT
  • Field changed: Percent Complete (100% → 0%)
The recent release of version 1:2.5-1 has resurfaced this issue.
Comment by Robert Timm (rti) - Tuesday, 08 December 2015, 18:30 GMT
Same here

wpa_supplicant 1:2.5-1
wpa_actiond 1.4-2
netctl 1.11-1
Comment by Kevin Alberts (Kurocon) - Tuesday, 08 December 2015, 20:36 GMT
This also affects me.

wpa_supplicant 1:2.5-1
wpa_actiond 1.4-2
netctl 1.11-1
Comment by Phil Ruffwind (Rufflewind) - Tuesday, 08 December 2015, 21:40 GMT
I have the same problem (and same package versions). Had to revert to 1:2.3-1 because of this.
Comment by Bennett Piater (ClawOfLight) - Thursday, 10 December 2015, 16:55 GMT
I can confirm the same.

wpa_supplicant 1:2.5-1
wpa_actiond 1.4-2
netctl 1.11-1

Causes this problem.

However, reverting to 1:2.3-1 did *not* fix it for me.
Comment by Risto Toijala (rtoijala) - Thursday, 10 December 2015, 17:43 GMT
I bisected this to

commit 97752f7930af55106b0959c2bb191d982382afe3
Author: Johannes Berg <johannes.berg@intel.com>
Date: Mon Oct 20 12:00:08 2014 +0200

Revert "nl80211: Do not indicate P2P_DEVICE support by default"

This reverts commit 851b0c5581069de6db01ddca7c150b76cee415a2.

The kernel now has full support for this (and it is turned off
by default for hwsim) so wpa_supplicant should really go back
to autodetecting this so clients don't have to figure out what
to do.

Also add a debug message stating that P2P_DEVICE support is used.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Reverting the commit fixes the issue.
Comment by Jouke Witteveen (jouke) - Thursday, 10 December 2015, 21:14 GMT
Phew, that means it is not a netctl bug. I was starting to get worried a bit.
Unassigning myself.
Comment by Daan van Rossum (drrossum) - Friday, 11 December 2015, 03:51 GMT
Same problem here.

wpa_supplicant 1:2.5-1
wpa_actiond 1.4-2
netctl 1.11-1

03:00.0 Network controller: Intel Corporation Wireless 7260 (rev 83)
Comment by rimaille (ekyo) - Friday, 11 December 2015, 15:14 GMT
same here too, cf. my comment at https://bugs.archlinux.org/task/47320 for details.
Comment by Evangelos Foutras (foutrelis) - Friday, 11 December 2015, 16:33 GMT
I don't have the hardware to test; someone who experiences this issue and is knowledgeable enough, please post to upstream's mailing list with relevant log information. [1]

I really want to avoid downgrading the package to 2.3 (again) but this is not an issue I can troubleshoot.

[1] http://lists.infradead.org/mailman/listinfo/hostap
Comment by Bennett Piater (ClawOfLight) - Friday, 11 December 2015, 16:35 GMT
@foutrelis Do you have any idea why I still have problems even after downgrading to 1:2.3?
Comment by Evangelos Foutras (foutrelis) - Friday, 11 December 2015, 16:42 GMT
@ClawOfLight: No idea, sorry.
Comment by Bennett Piater (ClawOfLight) - Friday, 11 December 2015, 20:01 GMT
@foutrelis It seems like it works now. I will report back if I have problems again.
I just toggled my hardware button a few times though.

Of course, this is on 1:2.3; I'm afraid that the bug with 2.5 is still very much present.
Comment by Robert Fenk (wauli) - Friday, 11 December 2015, 23:10 GMT
I got it working by telling wpa_supplicant via netctl-auto to not create a p2p control interface. The problem is that the -W switch makes wpa_supplicant wait on something connecting on each control interface. wpa_actiond times out connecting to the main control socket while wpa_supplicant wait for something to connect on the p2p one.

The relevant switch for wpa_supplicant is -m <interface>. Specifying -m '' seems to prevent wpa_supplicant creating a p2p interface in /run/wpa_supplicant.
I used the per-device flag in /etc/netctl/interfaces/<interface-name> file which is sourced by netctl-auto:

# IFACE=wlp58s0
# echo WPAOptions=\"-m \'\'\" > /etc/netctl/interfaces/$IFACE
# chmod +x /etc/netctl/interfaces/$IFACE


Versions of relevant packages I'm using:
$ pacman -Q wpa_supplicant wpa_actiond netctl
wpa_supplicant 1:2.5-1
wpa_actiond 1.4-2
netctl 1.11-1
Comment by Christophe Biocca (EmperorBob) - Saturday, 12 December 2015, 04:22 GMT
I can confirm that wauli's solution resolves the problem for me. Simply adding the file and restarting netctl-auto is sufficient to resolve the problem.

wpa_supplicant 1:2.5-1
wpa_actiond 1.4-2
netctl 1.11-1

08:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)

Comment by rimaille (ekyo) - Saturday, 12 December 2015, 08:37 GMT
Problem is solved for me too with wauli's workaround (thank you!)
So, is it a wpa_supplicant upstream problem or a netctl one ?
Comment by Jouke Witteveen (jouke) - Saturday, 12 December 2015, 12:34 GMT
That is very interesting. Thanks a lot for your research, wauli.

I could not find much documentation on the '-m' switch. The man page does not list it and `wpa_supplicant -h` lists:

[-m<P2P Device config file>]
(...)
-m = Configuration file for the P2P Device interface

It could very well be that '-W' is somehow not appropriate, but the current information does not really tell me what it should be, or why adding '-m' is the proper solution. Maybe it is still wpa_supplicant that is misbehaving?
Comment by Evangelos Foutras (foutrelis) - Friday, 18 December 2015, 14:10 GMT
Let's hope upstream can shed some light on what's going wrong:

http://lists.infradead.org/pipermail/hostap/2015-December/034354.html
Comment by Matt Hayes (mattage) - Friday, 18 December 2015, 22:16 GMT
Package versions:
wpa_supplicant 1:2.5-1
wpa_actiond 1.4-2
netctl 1.11-1

Wireless card: Intel(R) Dual Band Wireless AC 7265, REV=0x210

Just to add a bit more information:
I created a per-interface netctl configuration file with WPADriver=wext in it, and that also solves the problem (the default for WPADriver is 'nl80211,wext'). According to wpa_supplicant's Changelog, in version 2.4 P2P_DEVICE support was enabled for the nl80211 driver by default.

Maybe the default netctl ordering for WPADriver should be changed to have wext tried first, until there is a bug fix for this. That technically shouldn't break anything since wpa_supplicant moves through the specified drivers list in order and stops at the first one able to initialize the device. I realize that wext is deprecated, so I suppose this option could bring some regressions with it as well (or maybe not?).
Comment by Alex Burlyga (alex.burlyga) - Sunday, 20 December 2015, 20:18 GMT
So wauli's solution worked for me. I looked into a bit more. I still see following in the journal:

Dec 20 10:26:13 briquette netctl-auto[298]: DEBUG: wpa_start: wpa_supplicant -q -B -P /run/wpa_supplicant_wlp3s0.pid -i wlp3s0 -D nl80211,wext -c/run/network/wpa_supplicant_wlp3s0.conf -m '' -W
Dec 20 10:26:14 briquette netctl-auto[298]: Failed to open config file '//''', error: No such file or directory
Dec 20 10:26:14 briquette netctl-auto[298]: Failed to read or parse configuration '//'''.

So my guess is that providing -m '' just forces wpa_supplicant to fall back to hard coded values which I think just disables p2p.

I think the proper way is to either provide p2pconf file with p2p_disabled=1 and pass it as argument to -m option, or that property might be usable from conf file specified with -c option.

I'll experiment and report back.
Comment by Alex Burlyga (alex.burlyga) - Sunday, 20 December 2015, 20:33 GMT
So yeah, following diff fixes this problem cleanly:

--- /usr/lib/network/wpa 2015-12-20 12:29:46.465292457 -0800
+++ /usr/lib/network/wpa.fixed 2015-12-20 12:30:19.648331398 -0800
@@ -210,6 +210,7 @@
if is_yes "${AdHoc:-no}"; then
echo "ap_scan=2" >> "$config_file"
fi
+ echo "p2p_disabled=1" >> "$config_file"
echo "$config_file"
}

So it looks like netctl needs to learn how to deal with p2p interfaces and might be -W is not appropriate in this case. p2p_disable set to 1 by default seems more sensible though.

Another thought is to provide a way to get this setting passed from /etc/netctl/interface/<iface> file to -m option
Comment by Evangelos Foutras (foutrelis) - Thursday, 24 December 2015, 19:11 GMT
Upstream requires debugging information to further investigate this; it could also be a bug in netctl or wpa_actiond. [1]

I reopened  FS#47428  which doesn't seem to use netctl but if someone else can reproduce the issue with just wpa_supplicant (or hack netctl to produce debugging output), feel free to post your logs.

[1] http://lists.infradead.org/pipermail/hostap/2015-December/034392.html
Comment by Evangelos Foutras (foutrelis) - Sunday, 27 December 2015, 12:59 GMT
Please test if the netctl-auto issue is fixed with the following wpa_supplicant package:

http://pkgbuild.com/~foutrelis/test-builds/wpa_supplicant/patch-561146/

It includes the second patch (561146) from here: http://lists.infradead.org/pipermail/hostap/2015-December/034409.html
Comment by lilydjwg (lilydjwg) - Sunday, 27 December 2015, 13:21 GMT
foutrelis: your package works for me, thanks!
Comment by Evangelos Foutras (foutrelis) - Sunday, 27 December 2015, 13:33 GMT
Thanks for the confirmation; updated wpa_supplicant 1:2.5-2 package is now in [testing].
Comment by Simon Wydooghe (HyperBaton) - Sunday, 27 December 2015, 20:24 GMT
A second confirm here: the fix works for me. Thanks for the follow-up on this Evangelos!
Comment by Cláudio Pereira (claudiop) - Tuesday, 19 January 2016, 15:43 GMT
  • Field changed: Percent Complete (100% → 0%)
Same behavior on 2.5 yet not specific to netctl.
http://pastebin.com/njiNp6Ju
Downgrading to 2.3 worked.
Three different network cards:
http://pastebin.com/YFdJfxyE
2.5-2 was installed
Comment by Evangelos Foutras (foutrelis) - Tuesday, 19 January 2016, 16:24 GMT
This task was specific to netctl-auto; please file a new bug for your issue and provide a more comprehensive description.

Loading...