wpa_supplicant
will not be running in the container unless you start it.
A major difference between docker containers and a normal environment is that there are no system services running in the container unless you run it with init
or systemd
as the base command, since it is init (systemd is an init implementation) that manages these.
Containers are intended to do specialised things, not simply duplicate the host environment. Rather than umpteen background processes running, you have only those that you explicitly start.
You do not need to need to use init to run wpa_supplicant
, however -- and not having it running simplifies things considerably, because there are no networking daemons to interfere with your intentions.
wpa_supplicant -i wlan0 -c /etc/wpa_supplicant/my.conf -B
Will start it, and go to the background if successful (-B
). You may have to first:
ip link set wlan0 up
Both these require root privilleges. Wpa_supplicant and the wpa_cli
interface use a local socket for communication, so should not require any other system services. You may need to indicate the socket; see man wpa_cli
and ctrl_interface
in the conf file.
Gotchas
If what you are trying to do is communicate with the wpa_supplicant
already running in the host, you can't. This is not about permissions, this is about the logic of containerization. Although wpa_supplicant
uses a socket to communicate, it is a unix local socket, meaning it is only accessible on the local system via a file path, not an inet address.
You should not need to do this. If you need to do things with the host networking, you need to do it from the host.
If that's not what you are up to (i.e., you want to actually initiate an internet connection from within the container), note wpa_supplicant
is not the only component of such.