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.
  • If you are having issues getting hostapd to run via init.d (service hostapd start) and nothing seems to be occurring... refer to this forum post. – user82133 Aug 27 '14 at 2:32

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.

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)

  • @lordvlad is more correct, I had missed the DAEMON_CONF setting, which is why the -B option worked for me. – Sir_Scofferoff Feb 6 '16 at 17:50
  • 'Correct' is what works, and this one works on systemd, neatly sidestepping a bunch of other issues the others don't solve. – John Mee Mar 17 '16 at 10:33
  • 1
    @Teoma, actually @lordvlad is incorrect if you follow typical hostapd instructions and set DAEMON_CONF in /etc/defaults/hostapd as @Matt (not me) suggests in another answer (rather than hackily putting it in /etc/init.d/hostapd as vlad suggests). That said, your particular answer here addresses a race condition that exists even after that DAEMON_CONF is set, which is more of a bug in how hostapd's startup scripts are implemented than anything. So, thank you for that!! – matt Mar 5 '17 at 23:50
  • 1
    This is the only way I could get it to work on raspbian, rpi3. And that with >15 years unix experience. Systemd hijacked start-stop-daemon and does a crappy job at starting a sysv daemon (both udhcpd and hostapd). I have no clue what could be wrong, cause as far as systemd goes it did it's job (and the daemon "exited"). So if you have post-up, use it. – Melvyn Jun 29 '17 at 22:25

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

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.

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.

  • 1
    If one has followed the typical installation instructions for hostapd, this answer is incorrect and likely to confuse. Line 23 pulls variables defined in the file referenced by DAEMON_DEFS, which in turn typically has DAEMON_CONF defined in it. Thus, this script will only exit at line 24 if DAEMON_CONF is defined in neither /etc/init.d/hostapd (which you've misspelled as hostPAD in your first line) nor /etc/defaults/hostapd. – matt Mar 5 '17 at 23:41

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!

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.

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

protected by Hauke Laging May 15 at 21:02

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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