hostapd ne démarrera pas via «service» - mais démarrera directement

J'ai du mal hostapdà démarrer en tant que service. Il échoue lorsque j'essaie de le démarrer:

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

D'après ce que je comprends, cela utilise la configuration dans /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"

Mon fichier de configuration de démon est le suivant:

$ 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

Malgré le service qui ne démarre pas, je peux le démarrer directement sans erreur:

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

Tout ce que vous avez à faire est d'écrire cette commande:

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

il vous listera toutes les erreurs, vous pourrez ensuite les corriger dans le hostapd.conffichier

sudo nano /etc/hostapd/hostapd.conf

vous devez configurer:

sudo nano /etc/default/hostapd

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

Trouvez la ligne ci-dessus et dites à la configuration par défaut où se trouve votre configuration.

Ce fut un problème pour moi aussi et existe évidemment toujours. J'ai corrigé les erreurs en supprimant hostapd de /etc/rc2.d/ et /etc/networking/if-pre-up.d/

/ etc / network / interfaces contrôle maintenant hostapd.

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

Un redémarrage a confirmé qu'il faisait apparaître l'interface; et les stations se connectent bien. Auparavant, je devais faire ssh et arrêter isc et hostapd et faire ce que le post-up fait maintenant (dans cet ordre)

Je viens de rencontrer ce problème. Par défaut, installez sur mon raspian wheezy, hostapd est démarré en tant que S01 dans les services. Cela le fait démarrer avant ifplugdce qui configure eth0 et wlan0. La raison en est que S01h[ostapd]< S01i[fplugd]puisque les scripts sont triés par ordre alphabétique pour exécution.

Je pense que le pont a du mal à se configurer avant tout le reste. Le déplacer vers S05 n'a pas aidé non plus, je l'ai donc déplacé vers rc.local à la place, qui est exécuté "un peu" après tout le reste. J'ai également supprimé tous les liens de rc [2-5] .d vers hostapd. Je pense que S05 est encore trop tôt pour que dhclient se termine correctement. Je ne suis pas sûr que ce soit conforme aux meilleures pratiques. Ce qui semble se produire maintenant, c'est que ifplugd ne parvient pas à apparaître br0, mais eth0est plus coopératif. Je ne sais pas pourquoi wpa_supplicant échoue ici, probablement parce que wlan0c'est déjà promis br0. Il doit être désactivé de toute façon. Plus tard, hostapd essaie de br0revenir et réussit car tout eth0va bien et personne n'a pris le contrôle wlan0.

Il existe une autre configuration possible dans laquelle vous pouvez spécifier une option post-up/ pre-downpour br0in /etc/network/interfaces(interfaces homme). Vous pouvez démarrer / arrêter à hostapdpartir de là. Je n'ai pas réussi à le faire fonctionner cependant, mais cela ressemble à une solution beaucoup plus propre.

Je pense que le problème vient de vos citations à la ligne 11 de /etc/default/hostapd:

”/etc/hostapd/hostapd.conf”

Ce qui devrait se lire:

"/etc/hostapd/hostapd.conf"

Votre message m'a en fait aidé à résoudre mon problème, alors merci!

Vous devez définir DAEMON_CONFdans /etc/init.d/hostpad.

C'est vraiment assez évident si vous regardez /etc/init.d/hostapd, la valeur par défaut ressemble à ceci:

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

car DAEMON_CONFest vide pour commencer, le script se termine à la ligne 24. Dommage qu'il n'y ait pas de message d'erreur ou quoi que ce soit. Changer la ligne 17 en

 DAEMON_CONF=/etc/hostapd/hostapd.conf

et mettre la configuration dans le fichier spécifié a fonctionné pour moi.

Sur Arch Linux, où systemd semble la norme par rapport à rc / init.d, j'ai eu un problème similaire. Cette réponse diffère des autres sur les points suivants:

1. Le fichier de configuration ne réside pas dans /etc/init.dmais quelque part sous /etc/systemd/system/. Plus précisément/etc/systemd/system/multi-user.target.wants/hostapd , dans mon cas, où la ExecStartligne pointe vers le fichier de configuration utilisé.

2. Il est important de noter que ce fichier de configuration pointe également vers le binaire utilisé, à savoir /usr/bin/hostapd.

Le correctif consiste ensuite à vérifier le fichier hostapd que vous exécutez réellement. l'exécution whereisvous dira quelles versions sont disponibles et où elles se trouvent. Donc

whereis hostapd

produit quelque chose comme

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

Tester chacun en appelant systématiquement PATH/hostapd /etc/hostapd/hostapd.confchacun PATHidentifie celui que vous invoquez réellement et celui que systemd invoque. Encore une fois, dans mon cas, le dernier chemin est ce que j'invoquais lorsque j'ai poinçonné sudo hostapd /etc/hostapd/hostapd.conf. Le second est ce que systemd invoquait.

L'astuce consiste à copier le binaire de /usr/bin/localvers/usr/bin ou de pointer systemd vers le hostapd de travail. Je crois que le premier est l'option "la plus sûre".

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

Encore une fois, dans mon cas, le sous-binaire /usr/bin/localprovient de la compilation du pilote Realtek à partir de la source hors de leur site Web, comme décrit ici . Bravo à Realtek pour avoir supporté Linux.

J'espère que cela aide, n'est pas spécifique à mon système (Arch (Arm) Linux sur un Raspberry Pi B) et se qualifie comme une réponse appropriée selon les règles de l'UE.

Ajout de 10 secondes de sommeil dans le fichier /etc/init.d/hostapd résolu le problème pour moi.

1) sudo nano /etc/init.d/hostapd 2) Ajoutez la section sleepin start)comme ci-dessous

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