Advice

[charles-d-burton]

trafficstars

Trying to figure out how to use this, it seems like a good way to go with headless config on a raspberry pi. I'm calling it like this:

bssList, err := wifi.ScanManager.Scan()
	if err != nil {
		return err
	}
	for _, bss := range bssList {
		print(bss.SSID, bss.Signal, bss.KeyMgmt)
	}

	conn, err := wifi.ConnectManager.Connect(wificreds.SSID, wificreds.Password, time.Second*60)
	if err != nil {
		return err
	}

But all I'm getting is: wpa_supplicant knows nothing about this interface.

When I ps wpa_supplicant the table looks like this:

root       377     1  0 04:24 ?        00:00:00 /sbin/wpa_supplicant -u -s -O /run/wpa_supplicant
root       421     1  0 04:24 ?        00:00:00 wpa_supplicant -B -c/etc/wpa_supplicant/wpa_supplicant.conf -iwlan0 -Dnl80211,wext

I see the -u option in there and when I run dbus-send --system --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames I get:

method return time=1609130134.013166 sender=org.freedesktop.DBus -> destination=:1.16 serial=3 reply_serial=2
   array [
      string "org.freedesktop.DBus"
      string "org.freedesktop.login1"
      string "org.freedesktop.timesync1"
      string "org.freedesktop.systemd1"
      string "org.freedesktop.Avahi"
      string "org.bluez"
      string ":1.12"
      string ":1.0"
      string ":1.1"
      string ":1.2"
      string ":1.16"
      string ":1.3"
      string ":1.4"
      string "fi.epitest.hostap.WPASupplicant"
      string "fi.w1.wpa_supplicant1"
    

Running the latest RaspberryPi OS armhf as well.

[mark2b]

The problem you have two instances of wpa_supplicant. It happens when you call D-Bus API and no instance running, D-Bus starts parameter-less instance by it self. I have only one root 236 1 0 Dec22 ? 00:00:10 /usr/sbin/wpa_supplicant -u -iwlan0 -c/etc/wpa_supplicant.conf -Dwext

You need start wpa_supplicant before you first time call wpa_connect

This configuration I use for systemd service [email protected]

[Unit]
Description=WPA supplicant for %i

[Service]
ExecStart=/usr/sbin/wpa_supplicant -u -i%i -c/etc/wpa_supplicant.conf -Dwext

[Install]
WantedBy=multi-user.target

[charles-d-burton]

Hmmm, I see what you're saying but by default I don't think that's how a Pi works. I'll dig into it a bit more.

[mark2b]

I use my own linux distro, built by yocto project, so I have full control on every service I run.

[buildscientist]

@charles-d-burton Not sure if you've made any additional progress on this with the RPI/Raspbian but I believe the reason you're seeing two separate processes of wpa_supplicant is due to one of them being managed by systemd and the other defined and subsequently started by a definition in /etc/network/interfaces

I've disabled the systemd wpa_supplicant defined service but now I am trying to figure out how to expose the latter to dbus.

[mark2b]

@buildscientist from my experience first (wrong) instance started as side effect of first dbus call. http://www.jfcarter.net/~jimc/documents/bugfix/34-wpa_cli.html

In some distros, wpa_supplicant may be started by dbus itself. The dbus service file is (usually) /usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service ; if not there, do locate WPASupplicant.service to find it. In OpenSuSE it has a line SystemdService=wpa_supplicant.service which tells dbus to use systemd to start wpa_supplicant. If your distro's dbus service file lacks systemd integration, you will need to edit the Exec line in the file to add the -u and/or -O option. dbus-daemon will read the changes automatically.

[buildscientist]

@mark2b Thanks for the advice.

@charles-d-burton I dug into this further and determined that with Raspbian lite (Debian for RPI) there are indeed two mechanisms for starting the wpa_supplicant.

To clarify I am using the 2020-12-02-raspios-buster-armhf-lite release of Raspbian but this should work with any release based off of Debian Buster.

1. The DBUS service file mentioned by @mark2b located in /etc/systemd/dbus-fi.w1.wpa_supplicant1.service
2. A hook/script invoked by dhcpcd-run-hook scripts located in /lib/dhcpcd/dhcpcd-hooks/10-wpa_supplicant

I'm not sure why Raspbian uses the dhcpcd hook instead of systemd exclusively. Either way you can disable the systemd service, sudo systemctl disable wpa_supplicant and modify the dhcpcd hook to pass the -u flag to wpa_supplicant. That's line 62 in my copy of the hook - or towards the end of the wpa_supplicant_start() function.

After doing so - if you run the code snippet under examples that scans for SSIDs it will work.

As @mark2b mentioned using yocto to build your own linux distro is likely much cleaner especially since it's clear that Raspbian isn't fully relying on systemd for process supervision.

[buildscientist]

@mark2b I'll see about submitting a PR with an update to the README for other users of this library. I think most devs are going to be using Raspberry Pi OS (formerly known as Raspbian) instead of their own distro.

That said I do agree with you that going the yocto route to build your own RPI distro is much better for IOT. Thanks for all your hard work on this library 😎

[charles-d-burton]

Awesome! Thank you for looking into that, I ended up solving it the same way you did. If I get some time between work and school to hammer out a script for it I'll PR it here. Should be easy enough to update the cloud-init files on the pi to set this up without yocto.

[buildscientist]

@charles-d-burton Not sure we really need a script for it as this is distro specific. I'll be submitting a PR with a section in the README on running a Go binary using this library on Raspberry Pi OS.

@mark2b Feel free to close out this issue as I believe it's been resolved. Thanks 😎