[SOLVED] upon reboot hostapd fails to launch as a service but can be restarted at a bash prompt

[WorldScott]

Greetings fellow Raspberry Pi enthusiasts,

UPDATE Feb. 25, 2019: Note - An effective and fairly simple solution for the issue described in this initial post is right here.

TL;DR: After setting up a wifi to wifi extender system on my pi hostapd and dnsmasq do not come up properly as services at boot time but can be restarted at the end of the boot sequence with a restart command. It appears that hostapd fails because the wifi interfaces have not had time to come up before it launches. Despite the failed service launches, using crontabs one can successfully restart these services sequentially with a delay relative to reboot. Is there a less hacky way to correct this issue?

So I have successfully configured my Raspberry Pi 2 b+ installed with Stretch to be a wifi to wifi extender (with 2 usb wifi dongles) using more or less the following helpful guide:

https://pimylifeup.com/raspberry-pi-wifi-extender/

This allows one usb wifi dongle to join an existing network and then share that connection via the second wifi dongle configured as an access point (AP) with DHCP NAT routing.

The strange thing though is that hostapd fails to start as a service upon reboot and subsequently dnsmasq also fails (these failures can be verified with the sudo systemctl status hostapd command and sudo systemctl status dnsmasq command). Why this is strange is because I can first sudo service hostapd restart as a service at a post reboot bash prompt and then sudo service dnsmasq restart and then there is no further problem, everything comes up and works smoothly as intended.

Based upon some log readings I have the impression that at boot up time hostapd tries to start as a service before the wlan interfaces are up and operational and thus immediately it fails.

I found a hacky solution idea that taps into cron to restart these services with two time delays after boot:

Code: Select all

sudo crontab -e

and editing in these commands

Code: Select all

@reboot sleep 25; /home/pi/fixhostapdlaunch/delayed-restart-hostapd.sh
@reboot sleep 40; /home/pi/fixhostapdlaunch/delayed-restart-dnsmasq.sh

which tap into two launch files I created:

delayed-restart-hostapd.sh located in a home directory I created /home/pi/fixhostapdlaunch/
set with sudo chmod a+rx delayed-restart-hostapd.sh

Code: Select all

#!/bin/bash

sudo service hostapd restart 

and

delayed-restart-dnsmasq.sh located in the same directory and also set with sudo chmod a+rx delayed-restart-dnsmasq.sh

Code: Select all

#!/bin/bash

sudo service dnsmasq restart 

Though hacky this works well. Now, consistently shortly after boot these services restart and come up to work flawlessly. (I am using this service to make this post.)

What I am wondering is if the reason this might be an issue is because Stretch does not rely upon the /etc/network/interfaces functionality any longer?

While my hacky solution works fine it does not feel "right". Perhaps someone knows a standard way in Stretch to have the start of hostapd as a service be delayed until the wifi interfaces are well established? Or perhaps know that what I am thinking is actually not the issue but is something else?

Thank you in advance,

-Scott

[thagrol]

First thing to do is change your crontab entries to

Code: Select all

@reboot sleep 25; /home/pi/fixhostapdlaunch/delayed-restart-hostapd.sh > /tmp/delayed-restart-hostapd.log 2>&1
@reboot sleep 40; /home/pi/fixhostapdlaunch/delayed-restart-dnsmasq.sh >/tmp/delayed-restart-dnsmasq.log 2>&1

You can then check the log files for errors.

[WorldScott]

First thing to do is change your crontab entries to

Code: Select all

@reboot sleep 25; /home/pi/fixhostapdlaunch/delayed-restart-hostapd.sh > /tmp/delayed-restart-hostapd.log 2>&1
@reboot sleep 40; /home/pi/fixhostapdlaunch/delayed-restart-dnsmasq.sh >/tmp/delayed-restart-dnsmasq.log 2>&1

You can then check the log files for errors.

Though I have not had issues with these restart scripts this is a good tip to know for the future when a problem would potentially crop up.

I'll note that in seeking to diagnose the original problem I did alter the following code in the /etc/default/hostapd configuration file:

Code: Select all

#DAEMON_OPTS=""

changed to

Code: Select all

DAEMON_OPTS="-dd -t -f /home/pi/hostapd.log"

The errors recorded in the log found after a reboot are what gave me the impression that the hostapd service appeared to be trying to start up prior to the wlan interfaces being up.

-Scott

[thagrol]

Don't assume that a script that runs in the terminal will run from cron, rc.local or systemd. There are differences in the environments that can stop it from running.

The most obvious being a different search $PATH for programs and a different working directory. And no access to a terminal for I/O

I do have a zeroW around here running as an AP. I'll dig it out and check how I configured it but that won't be before tomorrow at the earliest (It's doing duty as an in car music player).

In the mean time you might want to check out what's reported by

Code: Select all

sudo systemctl status hostapd

and check the service files to amke sure the right dependencies are present.

[procount]

@worldscott - I'm not an expert in this, but my solution was similar to yours, i.e. to add appropriate delays between the various applications to make sure they start in the right order and have time to initialise properly.
You might want to consider using systemd to start the services instead of cron, as it has the ability to restart the services if they fail. Also you should be able to specify dependencies between them to ensure they start in the right order, but you probably still need to keep your delays.

[epoch1970]

Helpful guide, eh?

Dnsmasq probably fails to start because dnsmasq.conf includes "bind-interfaces" and this option is known to work poorly with systemd.
Do you have a reason to use "bind-interfaces"?
- If you can't answer the question, remove that option.
- If you do have a reason, replace "bind-interfaces" with "bind-dynamic"
"man dnsmasq" will clarify all that.

Hostapd probably fails to start because wpa_supplicant tries to get hold of wlan1 at the same time hostapd does.
The solution is to add "nohook wpa_supplicant" to the wlan1 interface definition within dhcpcd.conf
See a proper example here: https://www.raspberrypi.org/documentati ... s-point.md

[WorldScott]

Helpful guide, eh?

Dnsmasq probably fails to start because dnsmasq.conf includes "bind-interfaces" and this option is known to work poorly with systemd.
Do you have a reason to use "bind-interfaces"?
- If you can't answer the question, remove that option.
- If you do have a reason, replace "bind-interfaces" with "bind-dynamic"
"man dnsmasq" will clarify all that.

I'll go to remove "bind-interfaces" to see if that helps to resolve the issue more gracefully.

Hostapd probably fails to start because wpa_supplicant tries to get hold of wlan1 at the same time hostapd does.
The solution is to add "nohook wpa_supplicant" to the wlan1 interface definition within dhcpcd.conf
See a proper example here: https://www.raspberrypi.org/documentati ... s-point.md

Yes, I'd previously learned that lesson when after reboot I'd examine the wlan interfaces with iwconfig to see them both logged in. The host wlan that hostapd was meant to setup would automatically go to login to the source AP and thereby block hostapd even when attempting to restart the service after boot. Despite that configuration modification these services still will not come up after reboot without my current hacky crontab solution.

Merci,

-Scott

[WorldScott]

@worldscott - I'm not an expert in this, but my solution was similar to yours, i.e. to add appropriate delays between the various applications to make sure they start in the right order and have time to initialise properly.
You might want to consider using systemd to start the services instead of cron, as it has the ability to restart the services if they fail. Also you should be able to specify dependencies between them to ensure they start in the right order, but you probably still need to keep your delays.

I'll have to examine how to setup systemd to introduce the seemingly necessary delays. Thank you for the idea.

-Scott

[thagrol]

Been doing some testing on my rig. It seems

Code: Select all

interface wlan0
  nohook wpa_supplicant

in /etc/dhcpcd.conf is the key.

I'm using the default services for both hostapd and dnsmasq, and no restarts via cron etc. are needed. With the above it works, without it things are broken.

Interestingly, in the broken case,

Code: Select all

systemctl status hostapd

still reports hostapd as running.

Just glad I had a serial connection available to debug this.

[WorldScott]

Thank you thagrol, procount, and epoch1970.

I've finally found a more apt solution from unix.stackexchange user junaid here:

https://unix.stackexchange.com/question ... tly#436151

Adding 10 seconds sleep in file /etc/init.d/hostapd fixed the problem for me.
1) sudo nano /etc/init.d/hostapd
2) Add the sleep in start) section like below

Code: Select all

case "$1" in
  start)
        log_daemon_msg "Starting $DESC" "$NAME"
        sleep 10
        start-stop-daemon --start --oknodo --quiet --exec "$DAEMON_SBIN" \
                --pidfile "$PIDFILE" -- $DAEMON_OPTS >/dev/null
        log_end_msg "$?"
        ;;

I've rebooted several times and now after each boot the Raspberry Pi AP successful comes up fully operational. No more need for my previous hacky solution. Hopefully someone else encountering this issue will find this solution!


So, before:

Code: Select all

case "$1" in
  start)
        log_daemon_msg "Starting $DESC" "$NAME"
        start-stop-daemon --start --oknodo --quiet --exec "$DAEMON_SBIN" \
                --pidfile "$PIDFILE" -- $DAEMON_OPTS >/dev/null
        log_end_msg "$?"
        ;;

after:

Code: Select all

case "$1" in
  start)
        log_daemon_msg "Starting $DESC" "$NAME"
        sleep 10
        start-stop-daemon --start --oknodo --quiet --exec "$DAEMON_SBIN" \
                --pidfile "$PIDFILE" -- $DAEMON_OPTS >/dev/null
        log_end_msg "$?"
        ;;

Cheers!

-Scott

[svetb]

I had the same issue, and a similar solution.

Though I came here to say that since Raspbian Buster (and maybe also Stretch) the delay needs to instead be introduced in the systemd file rather than the init.d file, namely /etc/systemd/system/multi-user.target.wants/hostapd.service.

Adding

Code: Select all

ExecStartPre=/bin/sleep 15

to the [Service] section did it for me. After that my file looks like:

Code: Select all

[Unit]
Description=Advanced IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP Authenticator
After=network.target

[Service]
Type=forking
PIDFile=/run/hostapd.pid
Restart=on-failure
RestartSec=2
Environment=DAEMON_CONF=/etc/hostapd/hostapd.conf
EnvironmentFile=-/etc/default/hostapd
ExecStart=/usr/sbin/hostapd -B -P /run/hostapd.pid -B $DAEMON_OPTS ${DAEMON_CONF}
ExecStartPre=/bin/sleep 15

[Install]
WantedBy=multi-user.target

[toldcodger]

Hi,

Thanks Svetb, adding sleep 15 to the systemd hostapd.service file worked perfectly.

I tried the other fixes and the only one that worked was restarting the hostapd service.