Neathin
Posts: 2
Joined: Wed Dec 26, 2012 7:48 pm

Wireless AP

Wed Dec 26, 2012 8:18 pm

I set out to make my Raspberry pi a wireless AP using Arch Linux ARM. Needless to say, I've had my share of trouble, but I haven't given up. So here I am, making a new account and creating a topic, to share my WORKING configuration files and the programs I use with you, so others need not thread the road I've thread, although it was a learning experience :)

I'm using hostapd as my Access Point hosting tool because wpa_supplicant has some quirks that make it work less than great in my case.

To download and install, you can use the command pacman -S hostapd

My configuration file is a simple one. Note that the file location will be above the file contents

/etc/hostapd/hostapd.conf

interface=wlan0
driver=nl80211
ssid=networkname
wpa_passphrase=password
wpa=2
rsn_pairwise=CCMP
wpa_key_mgmt=WPA-PSK
hw_mode=g
channel=11
beacon_int=100

This will give you a wpa2/psk secured network called networkname with the password password

To make sure connected people don't have to set up the ip manually, I'm using dhcpd
To download and install dhcpd use the command: pacman -S dhcp

Again, my configuration file is very bare-bone, but adequate to do what it has to do.

/etc/dhcpd.conf

default-lease-time 600;
max-lease-time 7200;
authoritative;

subnet 192.168.2.0 netmask 255.255.255.0 {
range 192.168.2.10 192.168.2.244;
}

This defines a subnet, 192.168.2.0 with the mask /24 or 255.255.255.0, and a range of addresses that the dhcp server will lease on that subnet, starting with 192.168.2.10 and ending with 192.168.2.244. I've been thought that it is a good practice to leave a few off the top and bottom out of the pool for static IPs, since it is a practice to put servers, routers, AP-s, gateways, etc. at the end and beginning of the subnet.

Finally, last but not least, and a part I've had a lot of trouble with before I realized Arch uses systemd, it's the .service file that allows it all to be automated

etc/systemd/system/AP.service

[Unit]
Description=AP
Wants=network.target
Before=network.target
BindsTo=sys-subsystem-net-devices-wlan0.device
After=sys-subsystem-net-devices-wlan0.device

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/ip link set dev wlan0 up
ExecStart=/sbin/ip addr add 192.168.2.1/24 broadcast 192.168.2.255 dev wlan0
ExecStart=/usr/bin/hostapd -B /etc/hostapd/hostapd.conf
ExecStart=/usr/sbin/dhcpd -4 -q wlan0

ExecStop=/sbin/ip addr flush dev wlan0
ExecStop=/sbin/ip link set dev wlan0 down

[Install]
WantedBy=multi-user.target

Explanation:

[Unit]

Description is basically the name of the script, nothing important. You may call it Pablo Francisco if you wish, but that might make it hard for you to discern it's function :P
Wants, Before, BindsTo and After are important because they tell systemd about the requirements that need to be met before the script can be run. What they'll be or if they'll be depends entirely on what you are doing, so I can't really be specific here. But more is better than less, since all it does is tell systemd what to wait for before running your script. After=sys-subsystem-net-devices-wlan0.device is an absolute must because otherwise the wlan0 interface might not be available (usb dongle hasn't been recognised and started yet) and the whole script would then fail.

[Service]

Going from the top, what this does is put the wlan0 interface in an up state (turn it on, one might say), then give it an IP address. Hostapd is then called with the -B option, telling it to run in the background, followed by the path to it's configuration file. Please note that paths to programs and files must be absolute paths in systemd .service files. You can't just type the program name like in the terminal. After that, I call dhcpd, the dhcp server deamon. It runs in background by default, so no flags needed for that. The -4 flag tells it to run IPv4, and the -q flag tells it to output less nonsense like the entire EULA when starting, because that slows down the script or might even cause it to fail. Some will tell you to add the interface name to the end of this command, but that is not necessary because the dhcp deamon knows which interface to work on based on the IP address of the interface.

ExecStop=/sbin/ip addr flush dev wlan0 and ExecStop=/sbin/ip link set dev wlan0 down tell systemd that if the script is given the stop command (systemctl stop scriptname) wlan0 should be flushed, that is the IP address and other configuration options should be cleared, then the second command sets the wlan0 interface into a down state (turns it off).

[Install]

I'm not entirely sure what WantedBy=multi-user.target does. I assume it tells systemd what to do with the script, that is how to install it, but I've found that all user scripts have this thing at the end, and so does mine. :)

The script I named AP.service because that was how I wanted to name it, any name will do, but .service must be at the end. Why? Not even sure it must, but lets stick to the format, that way everything is nice and clear :)

To run it, you use the command systemctl start AP.service
To stop it, you use the command systemctl stop AP.service
To make it run at boot, use systemctl enable AP.service
To make it stop running at boot, use systemctl disable AP.service

Making the script better would probably include adding ExecStop commands to find the PID of the dhcp and hostap deamons and stopping these processes so they don't continue running in the background, but that sort of is irrelevant since it's meant to be started at boot and stopped and halt.

Comment, Critique, Enjoy :)

Neathin
Posts: 2
Joined: Wed Dec 26, 2012 7:48 pm

Re: Wireless AP

Thu Dec 27, 2012 9:29 am

I've actually made a mistake here.

The code should be

[Unit]
Description=AP
Wants=dev-usbdev1.4.device
After=dev-usbdev1.4.device

The reason for this is that that sys-subsystem-net-devices-wlan0.device sometimes works, sometimes doesn't seem to work. It isn't reliable. I figure this is because it's just plain wrong code that doesn't do a thing, and sometimes gets lucky. Wants and After dev-usbdev1.4 works since my wifi stick is plugged into that usb device. This is not an ideal solution, since it isn't a no-brainer, requiring you to know which usb device your wifi stick is. Hate it, but it's reliable. Especially hate it since I was so sure this worked and posted an entire topic, just to have to make a correction a while later

geekinthesticks
Posts: 93
Joined: Fri Feb 08, 2013 7:22 pm

Re: Wireless AP

Wed Mar 26, 2014 11:42 am

Thanks for posting that. I have been using my Pi as an AP with Arch for some time. I had a systemd unit similar to yours, which had been working for ages, but after a recent update it wouldn't bring up an ip link for wlan0. It seemed that it was trying to start the interface before wlan0 was available. Looking at your systemd unit I have been able to fix my problem.

jawj
Posts: 1
Joined: Fri Jul 01, 2016 1:11 pm

Re: Wireless AP

Fri Jul 01, 2016 1:17 pm

Hi guys, i know i'm resurrecting an old thread but it is what i am basing my question on.

I'm just following your guide and have got it all working except for the setting of the static IP address of the host. I can do this manually, but when i try to do it as you have in the service file (with network.service), i get errors (as you have already said).

I am using a raspberry pi 3 and as such don't have a dev-usbdev1.4.device connected.

Any help that you can give me as to what i should use for this? I'm quite new to Linux and super new to Arch.

Btw, i am not bridging this connection - it is purely just an access point so that device can communicate with other devices connected to the AP (and with the host of course, which is why i need to set the static ip address).

Return to “Advanced users”

Who is online

Users browsing this forum: No registered users and 20 guests