web-dev-qa-db-fra.com

hostapd ne démarrera pas via "service" - mais démarrera directement

J'ai du mal à démarrer hostapd 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.
networkingservicesinit-scriptinit.dhostapd
19
gnychis

vous devez configurer:

Sudo nano /etc/default/hostapd

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

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

14
Matt

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 pouvez ensuite les corriger dans hostapd.conf fichier

Sudo nano /etc/hostapd/hostapd.conf
14
Salah laaroussi

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

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 quoi le post-up fait maintenant (dans cet ordre)

11
Sir_Scofferoff

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 ifplugd 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 à apporter br0 up mais eth0 est plus coopératif. Je ne sais pas pourquoi wpa_supplicant échoue ici, probablement parce que wlan0 a déjà promis de br0. Il doit être désactivé de toute façon. Plus tard, hostapd essaie d'apporter br0 à nouveau et réussit depuis eth0 est ok et personne n'a pris le contrôle de wlan0.

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

3
Eric

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!

2
Bart Joosten

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

1) Sudo nano /etc/init.d/hostapd 2) Ajoutez le sleep dans start) section 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 "$?"
        ;;
1
junaid

Vous devez définir DAEMON_CONF dans /etc/init.d/hostpad.

C'est vraiment assez évident si vous regardez dans /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
...

parce que DAEMON_CONF est 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.

1
lordvlad

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.d mais quelque part sous /etc/systemd/system/. Plus précisément /etc/systemd/system/multi-user.target.wants/hostapd, dans mon cas, où la ligne ExecStart 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 de whereis vous indiquera 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.conf pour chaque PATH identifie celui que vous invoquez réellement et lequel systemd invoque. Encore une fois, dans mon cas, le dernier chemin est ce que j'invoquais lorsque j'ai introduit Sudo hostapd /etc/hostapd/hostapd.conf. Le second est ce que systemd invoquait.

L'astuce consiste à copier le binaire de /usr/bin/local à /usr/bin ou pour 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 binaire sous /usr/bin/local provient de la compilation du pilote Realtek à partir de la source 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.

0
Carel