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

# 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.

My daemon configuration file is as follows:

$ cat /etc/hostapd/hostapd.conf

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
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
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]
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_hidden_ssid ignore_broadcast_ssid:0, KITT,4
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, 2014 at 2:32

8 Answers 8


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

you have to configure:

sudo nano /etc/default/hostapd


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

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. Feb 6, 2016 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, 2016 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!!
    – mr_z_ro
    Mar 5, 2017 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, 2017 at 22:25

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.


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


Which should read:


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


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

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
18 NAME=hostapd
19 DESC="advanced IEEE 802.11 management"
20 PIDFILE=/var/run/hostapd.pid
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


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

  • 2
    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.
    – mr_z_ro
    Mar 5, 2017 at 23:41

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .