0

My intention is to start an (headless) RPI in AP mode when it is not able to connect to the configured WIFI network(s). I have seen several solutions, many of them related to Debian, but so far I was not able to get something working.

The current configuration (Poky Dunfell, derived from meta-raspberry-pi core-image-base) :

  • udhcpd
  • wpa_supplicant
  • dnsmasq
  • hostapd

As far as I understand, there are 2 directions to go:

  1. Use wpa_supplicant for the AP (this seems the easiest and cleanest)
  2. Use hostapd for the AP

Using hostapd, I was able to create an hotspot, but it requires quite some 'glue'scripting to implement automatic fallback, so I went for the wpa_supplicant route (disabled hostapd start at boot).

I added an entry to wpa_supplicant.conf, which you find similarly in several examples:

network={
    priority=0
    ssid="Hotspot"
    mode=2
    key_mgmt=WPA-PSK
    psk="password"
    frequency=2437
}

I would expect this, to be sufficient to create at least the hotspot (no dhcp yet), but that does not seems to work.

On top of wpa_supplicant.conf is an entry "ap_scan", which in most examples is set to 1, but I found one example where was mentioned to set it to 2 for AP mode. Documentation about this option is not so clear to me. I tried both, but no AP was created. I just found out, that with ap_mode=2 station mode does not work, it might be this option is driver dependent.

I also miss the logging of wpa_supplicant, which makes it difficult to understand what is going on under the hood. Any suggestion where to configure this ?

Before spending more time, I hope somebody can give me some hints or directions which way to go.

2
  • 1
    "I also miss the logging of wpa_supplicant" -> Is Yocto read-only or something? And by "headless" do you also mean, "I have no monitor and keyboard to use in setting this up". Ie., You have to just keep making blind guesses and rebooting and have no means of determining what went wrong with anything beyond what you can observe from (presumably) scanning for the AP with a phone or something? That is not all that sane an approach...
    – goldilocks
    Commented Apr 27, 2022 at 13:20
  • Yocto is not readonly. However the included version of wpa_supplicant does not have the '-f' command line option to specify a log file. The intention is a 'headless setup' At this moment I have shell access. I just found out that, when starting wpa_supplicant from the command line with (purposely) a wrong password for client mode, it tries a few times to connect and then starts an AP. However on reboot the AP is not created ( client mode works as expected)
    – Waldorf
    Commented Apr 27, 2022 at 16:25

1 Answer 1

1

In the mean time I found out the cause.

When starting wpa_supplicant from the command line, the AP was started after a some connection attempts in STA mode. After a reboot this did not happen. I noticed in the WPA supplicant command line (after boot) a driver option ("-D wext"), which I did not use when trying manually.

When adding "-D wext" to the arguments when starting manually, it was indicated that the driver does not support AP mode. Then tried another driver option "nl80211" and both AP and STA mode worked. (It is still unclear to me how to obtain the driver name to use, most examples I have seen use wext)

The driver name is configured in: /etc/network/interfaces

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.