1

I use my RPI as wifi repeater using hostapd and dnsmasq.

Since I'm using hostapd_cli to disconnect the pi from the internet if the repeater is not in use, I often can’t connect to my access point and I have to restart hostapd or dnsmasq.

How is it possible that hostapd_cli makes my access point inaccessible?

I start hostapd_cli by using rc.local:

hostapd_cli -a /home/pi/autoConnectWLAN.sh &

The script contains:

#!/bin/bash

if sudo hostapd_cli all_sta | grep -q "ASSOC" && ! ip link show wlan1 | grep -q "UP"; then
  sudo ip link set wlan1 up 

  if ! pgrep -x "wpa_supplicant"; then
    sudo wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant-wlan1.conf -Dnl80211,wext -iwlan1 -B 
  fi

elif ! sudo hostapd_cli all_sta | grep -q "ASSOC" && ip link show wlan1 | grep -q "UP"; then
  sudo ip link set wlan1 down
fi
jake
  • 1,347
  • 10
  • 23

1 Answers1

1

Please take note that using /etc/rc.local has limitations due to Compatibility with SysV. Following the recommendation of the developers from systemd you should avoid using rc.local.

In addition your script is doing things that assumes that hostapd is up and running. That may or may not be possible because there is no dependency to start your script After=hostapd.service.

The same is with wpa_supplicant. You start it in your script. If you use a default raspbian image then wpa_supplicant is managed by dhcpcd. I cannot see that you do things to avoid conflicts by starting wpa_supplicant a second time on another way.

In general you are completely ignoring the init system systemd with its dependencies to manage services. I'm sure this is the reason why hostapd_cli makes your access point inaccessible. You should use a systemd Unit file to start your access point (but that wasn't asked).

Ingo
  • 42,107
  • 20
  • 85
  • 197
  • Thanks for your answer. You are right, I don't really like to use systemd. Maybe that's the problem. But I added nohook wpa_supplicant for both devices to dhcpcd.conf. And I added until pidof hostapd; do sleep 0.5; done before I start hostapd_cli... – jake Dec 08 '18 at 15:24
  • @jake There was a big discussion about pro and contra of systemd and I respect if one doesn't like it. Yes, systemd violates old historical unix paradigm. But most distributions come with systemd, incl. Raspbian, so you have to decide what path you will follow. If you decide to follow classical unix guidelines then you should also use an operating system following it, otherwise you will run more and more into problems like your question. As far as I know debian has a new fork still using SysV init system because of this discussion. I have decided to use systemd. I believe its the mainstream. – Ingo Dec 08 '18 at 17:03
  • @jake How I solved your problem with systemd you may have al look at Access point as WiFi repeater, optional with bridge. With it you can simply start and stop the AP with sudo systemctl [start|stop] hostapd.service. Because you refer to wlan1 I guess you are using two wifi devices (one usb/wifi dongle?). Then you can look at RPI3 Raspbian Stretch regular connection on wlan0 AP on wlan1. – Ingo Dec 08 '18 at 17:18
  • 1
    You're right, I have to get used to it. I use two wifi dongles on a pi 1. I will maybe try to set it up with systemd on a fresh install. – jake Dec 08 '18 at 18:09
  • I'm following your answer in the provided link. But how can I get static device names and change mac-address? Using /etc/systemd/network/00-default.link? – jake Dec 08 '18 at 21:41
  • @jake Changing the mac address is not a big problem. Naming on an isolated network may be an issue. But this is not the right place in comments on another question. Could you please make a new question, just a short three liner? Then we have enough place and the right context for it. – Ingo Dec 09 '18 at 00:38
  • How could I manage hostapd by systemd. Just create a unit file or do I have to disable the old init.d service before? – jake Dec 27 '18 at 18:05
  • @jake There is nothing to do. As already said everything is managed by systemd. There is already a service for hostapd. You can manage it with systemctl status|start|stop|restart|cat hostapd and others like any other service. – Ingo Dec 27 '18 at 21:17
  • Okay, thanks. I only wonder why there is no unit file in /lib/systemd/system or /etc/systemd/system but there is one in /init.d. Just trying to get used to systemd :). – jake Dec 27 '18 at 21:57
  • I see there is one /run/systemd/generator.late/hostapd.service so it's an emulated service and I thought it might be better to use a »real« one... – jake Dec 27 '18 at 21:59
  • @jake Yes I agree with you. You can also get some information about this with systemctl cat hostapd. But the Debian maintainer Kel Modderman for this package seems not to be willing to go with the time. He has nothing done since 2005 for managing hostapd process(es). Look at cat /usr/share/doc/hostapd/README.Debian. – Ingo Dec 27 '18 at 22:23
  • So, then I will try to build my own unit file and delete the init.d-service. That should work, right? – jake Dec 27 '18 at 23:08
  • @jake Yes that should work. Having a look at /etc/init.d/hostapd it seems you only need start and reload. Others is managed automatically by systemd. An issue would be the dependencies shown in the INIT INFO. – Ingo Dec 28 '18 at 00:45