hostapd will not start via "service" -- but will start directly

Question

I am having trouble getting hostapd to start as a service. It fails when I try to start it:

$ sudo service hostapd start
[FAIL] Starting advanced IEEE 802.11 management: hostapd failed!

From what I understand, this uses the configuration in /etc/default/hostapd:

$ cat /etc/default/hostapd 
# Defaults for hostapd initscript
#
# See /usr/share/doc/hostapd/README.Debian for information about alternative
# methods of managing hostapd.
#
# Uncomment and set DAEMON_CONF to the absolute path of a hostapd configuration
# file and hostapd will be started during system boot. An example configuration
# file can be found at /usr/share/doc/hostapd/examples/hostapd.conf.gz
#
#DAEMON_CONF=""
DAEMON_CONF=”/etc/hostapd/hostapd.conf”

# Additional daemon options to be appended to hostapd command:-
#   -d   show more debug messages (-dd for even more)
#   -K   include key data in debug messages
#   -t   include timestamps in some debug messages
#
# Note that -B (daemon mode) and -P (pidfile) options are automatically
# configured by the init.d script and must not be added to DAEMON_OPTS.
#
DAEMON_OPTS="-d"

My daemon configuration file is as follows:

$ cat /etc/hostapd/hostapd.conf
interface=wlan0
bridge=br0
driver=rtl871xdrv
country_code=USA
ctrl_interface=wlan0
ctrl_interface_group=0
ssid=KITT
hw_mode=g
channel=1
wpa=3
wpa_passphrase=georgeisyourfriend
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
beacon_int=100
auth_algs=3
macaddr_acl=0
wmm_enabled=1
eap_reauth_period=360000000

Despite the service failing to start, I am able to start it directly on my own without error:

$ sudo hostapd -d /etc/hostapd/hostapd.conf
random: Trying to read entropy from /dev/random
Configuration file: /etc/hostapd/hostapd.conf
ctrl_interface_group=0
drv->ifindex=3
Configure bridge br0 for EAPOL traffic.
BSS count 1, BSSID mask 00:00:00:00:00:00 (0 bits)
Completing interface initialization
Mode: IEEE 802.11g  Channel: 1  Frequency: 2412 MHz
RATE[0] rate=10 flags=0x1
RATE[1] rate=20 flags=0x1
RATE[2] rate=55 flags=0x1
RATE[3] rate=110 flags=0x1
RATE[4] rate=60 flags=0x0
RATE[5] rate=90 flags=0x0
RATE[6] rate=120 flags=0x0
RATE[7] rate=180 flags=0x0
RATE[8] rate=240 flags=0x0
RATE[9] rate=360 flags=0x0
RATE[10] rate=480 flags=0x0
RATE[11] rate=540 flags=0x0
Flushing old station entries
Deauthenticate all stations
+rtl871x_sta_deauth_ops, ff:ff:ff:ff:ff:ff is deauth, reason=2
rtl871x_set_key_ops
rtl871x_set_key_ops
rtl871x_set_key_ops
rtl871x_set_key_ops
Using interface wlan0 with hwaddr 80:1f:02:d3:cb:b8 and ssid 'KITT'
Deriving WPA PSK based on passphrase
SSID - hexdump_ascii(len=4):
     4b 49 54 54                                       KITT
PSK (ASCII passphrase) - hexdump_ascii(len=18): [REMOVED]
PSK (from passphrase) - hexdump(len=32): [REMOVED]
rtl871x_set_wps_assoc_resp_ie
rtl871x_set_wps_beacon_ie
rtl871x_set_wps_probe_resp_ie
urandom: Got 20/20 bytes from /dev/urandom
GMK - hexdump(len=32): [REMOVED]
Key Counter - hexdump(len=32): [REMOVED]
WPA: group state machine entering state GTK_INIT (VLAN-ID 0)
GTK - hexdump(len=32): [REMOVED]
WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0)
rtl871x_set_key_ops
rtl871x_set_beacon_ops
rtl871x_set_hidden_ssid ignore_broadcast_ssid:0, KITT,4
rtl871x_set_acl
wlan0: Setup of interface done.

Answer 1

All what you have to do is to write this command:

sudo hostapd -d /etc/hostapd/hostapd.conf

it will list you all errors, you can then correct them in hostapd.conf file

sudo nano /etc/hostapd/hostapd.conf

Answer 2

you have to configure:

sudo nano /etc/default/hostapd

DAEMON_CONF="/etc/hostapd/hostapd.conf"

Find the line above and tell the defaul config where your one is.

Answer 3

This was a problem for me also and obviously still exists. I fixed the errors by removing hostapd from /etc/rc2.d/ and /etc/networking/if-pre-up.d/

/etc/network/interfaces controls hostapd now..

iface wlan0 inet static
         post-up /usr/sbin/hostapd -B /etc/hostapd/hostapd.conf
         post-up service isc-dhcp-server restart
         address 192.168.10.1
         netmask 255.255.255.0

A reboot confirmed it brings up the interface; and Stations connect fine. Previously I had to ssh in and stop isc and hostapd and do what the post-up now does (in that order)

Answer 4

I just ran into this problem. By default install on my raspian wheezy, hostapd is started as S01 in services. This makes it start before ifplugd which configures eth0 and wlan0. The reason for this is that S01h[ostapd] < S01i[fplugd] since scripts are sorted in alphabetical order for execution.

I think that the bridge gets a hard time getting configured before everything else. Moving it to S05 didn't help either so I moved it to rc.local instead, which gets executed "a while" after everything else. I also removed all links from rc[2-5].d to hostapd. I think that S05 is still too soon for dhclient to finish properly. I am not sure this is according to the best practices. What seems to happen now is that ifplugd fails to bring br0 up but eth0 is more cooperative. I am not sure why wpa_supplicant fails here, probably because wlan0 is already promised to br0. It needs to be disabled anyway. Later on, hostapd tries to bring br0 up again and succeeds since eth0 is ok and no one took control of wlan0.

There is another possible configuration where you could specify a post-up/pre-down option for br0 in /etc/network/interfaces (man interfaces). You could start/stop hostapd from there. I didn't manage to get it to work however, but this looks like a much cleaner solution.

Answer 5

I think the problem is with your quotes on line 11 of /etc/default/hostapd:

”/etc/hostapd/hostapd.conf”

Which should read:

"/etc/hostapd/hostapd.conf"

Your post actually helped me solve my problem, so thanks!

Answer 6

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

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 "$?"
        ;;

Answer 7

You need to set DAEMON_CONF in /etc/init.d/hostpad.

It's really quite obvious if you look into /etc/init.d/hostapd, the default looks like this:

...
14 PATH=/sbin:/bin:/usr/sbin:/usr/bin
15 DAEMON_SBIN=/usr/sbin/hostapd
16 DAEMON_DEFS=/etc/default/hostapd
17 DAEMON_CONF=
18 NAME=hostapd
19 DESC="advanced IEEE 802.11 management"
20 PIDFILE=/var/run/hostapd.pid
21
22 [ -x "$DAEMON_SBIN" ] || exit 0
23 [ -s "$DAEMON_DEFS" ] && . /etc/default/hostapd
24 [ -n "$DAEMON_CONF" ] || exit 0
...

because DAEMON_CONF is empty to start with, the script exits at line 24. Too bad there is no error message or anything. Changing line 17 to

 DAEMON_CONF=/etc/hostapd/hostapd.conf

and putting the configuration in the specified file worked for me.

Answer 8

On Arch linux, where systemd seems the norm over rc/init.d I had a similar problem. This answer differs from the others in the following ways :

1. The configuration file does not reside in /etc/init.d but somewhere under /etc/systemd/system/. Specifically /etc/systemd/system/multi-user.target.wants/hostapd, in my case, where the ExecStart line points to the configuration file used.

2. Importantly this configuration file also points to the binary used, namely /usr/bin/hostapd.

The fix is then to check which hostapd file you are actually executing. running whereis will tell you what versions are available and where they are located. So

whereis hostapd

produces something like

/sbin/hostapd /usr/bin/hostapd /usr/local/bin/hostapd

Testing each one by systematically calling PATH/hostapd /etc/hostapd/hostapd.conf for each PATH identifies which one you're actually invoking and which one systemd is invoking. Again in my case the last path is what I was invoking when I punched in sudo hostapd /etc/hostapd/hostapd.conf. The second one is what systemd was invoking.

The trick is to copy the binary from /usr/bin/local to /usr/bin or to point systemd to the working hostapd. I believe the former is the "safer" option.

sudo mv /usr/bin/hostapd /usr/bin hostapd.bkp     # delete later as necessary
sudo cp /usr/local/bin/hostapd /usr/bin

Again in my case the binary under /usr/bin/local came from compiling the Realtek driver from source off of their website as described here. Well done to Realtek for supporting Linux.

Hope this helps, is not specific to my system (Arch (Arm) Linux on a Raspberry Pi B) and qualifies as a suitable answer according to the UE rules.