FS#37468 - [dhcpcd] dhcpcd 6.0.5-1 spawns an additional wpa_supplicant instance

Attached to Project: Arch Linux
Opened by pepper (pepperdas) - Thursday, 24 October 2013, 14:53 GMT
Last edited by Doug Newgard (Scimmia) - Wednesday, 13 May 2015, 15:28 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Ronald van Haren (pressh)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
My usual procedure for starting my system has been:
1. calling wpa_supplicant -i[myinterfacename] -c[myconfig]
and waiting for a wireless connection
2. calling dhcpcd [myinterfacename]
to configure the routing table
NOTE: I was NOT using systemd

for whatever reason, the dhcpcd service is calling its own instance of wpa_supplicant (without testing to see if wpa_supplicant was already running), and also deleting the routing table every time it called /usr/lib/dhcpcd/dhcpcd-run-hooks ROUTERADVERT

I see in the scripts in /usr/lib/dhcpcd that wpa_supplicant is started and monitored by dhcpcd to enable a type of wireless hotplugging, which is nice but this broke my ability to connect to the internet until I discovered it, and it was difficult to track
furthermore, the location of my wpa_supplicant.conf is not /etc/wpa_supplicant.conf
even though that is the location hardcoded into the dhcpcd script.

Thanks for looking at this, my system is running fine but it would be nice to fix this bug

Additional info:
* package version(s)
* config and/or log files etc.


Steps to reproduce:
This task depends upon

Closed by  Doug Newgard (Scimmia)
Wednesday, 13 May 2015, 15:28 GMT
Reason for closing:  Fixed
Comment by Roy Marples (rsmarples) - Friday, 08 November 2013, 10:40 GMT
The wpa_supplicant hook dhcpcd calls checks for /etc/wpa_supplicant.conf or /etc/wpa_supplicant/wpa_supplicant.conf, if not already defined by user config.
If that file exists then it checks that wpa_supplicant is running for that interface like so:
wpa_cli -i "$interface" status >/dev/null 2>&1
A return value of 0 indicates wpa_supplicant is already running for that interface, any other value means
that wpa_supplicant is not running on that interface, so dhcpcd starts one.

In a nutshell, your custom config is probably not creating control sockets in the directory wpa_cli expects, so I think you have two options
1: disable dhcpcd running wpa_supplicant by adding -C wpa_supplicant to the dhcpcd commandine
2: specify in your wpa_supplicant config create control sockets for wpa_cli
Comment by Roy Marples (rsmarples) - Monday, 20 January 2014, 20:24 GMT
Improvements have been made in the latest code which extracts ctrl_interace directory from the config.
If this variable is not set then we don't start wpa_supplicant.
Otherwise we pass the directory to wpa_cli and start wpa_supplicant as we currently do.

http://roy.marples.name/projects/dhcpcd/ci/d889323c10?sbs=0
http://roy.marples.name/projects/dhcpcd/ci/99483017854d?sbs=0
Comment by Anatol Pomozov (anatolik) - Wednesday, 12 March 2014, 00:39 GMT
Is this fixed in version 6.3.1 that we have in our stable repo?
Comment by Kai Hendry (hendry) - Tuesday, 18 March 2014, 02:51 GMT
I'm a little confused how to maintain my wifi connection. I initially thought wpa_supplicant@wlan0.service, but dhcpcd@wlan0.service seems to manage wpa_supplicant. /usr/lib/dhcpcd/dhcpcd-hooks/10-wpa_supplicant So what's the idea? http://dabase.com/blog/Good_riddance_netctl/
Comment by Roy Marples (rsmarples) - Tuesday, 18 March 2014, 03:23 GMT
dhcpcd can maintain it by itself. I'm sure systemd could also, but dhcpcd runs in many places where systemd does not.
However, I have gone to some lengths to ensure both won't step on each other by default.

Loading...