The internet has an immense amount of information on creating Wi-Fi access points using the Raspberry Pi single-board computer. Typically, the native operating system for the 'raspberry' is assumed to be Raspbian.
As an enthusiast of RPM-based systems, I couldn't pass by this little marvel without trying my favorite CentOS on it.
This article provides a guide on how to build a 5GHz/AC Wi-Fi router from a Raspberry Pi 3 Model B+ using CentOS as the operating system. It will include several standard yet little-known tricks, along with a bonus — a schematic for connecting additional Wi-Fi equipment to the 'raspberry,' allowing it to operate in multiple modes (2.4+5GHz) simultaneously.
(a mix of freely available images)
Let’s note right away that we won't achieve astronomical speeds. I'm squeezing a maximum of 100 Mbps out of my 'raspberry' wirelessly, which covers my internet provider's speed. Why would you need such a sluggish AC when you could theoretically get half a gigabit even on N? If this is your question, head to the store for a real router with eight external antennas.
0. What you will need
- The actual 'raspberry product' is: Pi 3 Model B+ (for achieving those coveted 5GHz speeds and channels);
- A quality microSD >= 4GB;
- A workstation with Linux and a microSD reader/writer;
- Sufficient skills in Linux, as this article is for the prepared Geek;
- Wired network (eth0) connectivity between the Raspberry and Linux, a functioning DHCP server in the local network, and internet access on both devices.
A small comment on the last point. 'What came first, the chicken or...' how to make a Wi-Fi router in the absence of any internet access equipment? We’ll leave this fascinating exercise outside the scope of the article and just assume that the Raspberry is connected to the local network via cable and has internet access. In this case, we won't need an additional television or mouse for setting up the 'raspberry.'
1. Installing CentOS
At the time of writing this article, the working version of CentOS on the device is 32-bit. I've come across opinions across the vastness of the web about a 20% drop in performance for such OSs on a 64-bit ARM architecture. I’ll leave this point uncommented.
On Linux, let's download the minimal image with the kernel '-RaspberryPI-» and writing it to microSD:
# xzcat CentOS-Userland-7-armv7hl-RaspberryPI-Minimal-1810-sda.raw.xz |
dd of=/dev/mmcblk0 bs=4M
# sync
Before starting to use the image, we will remove the SWAP partition, expand the root to the full available size, and disable SELinux. The algorithm is simple: we make a copy of the root on Linux, delete all partitions from the microSD except the first (\/boot), create a new root partition, and restore its contents from the copy.
Example of necessary actions (raw console output)
# mount /dev/mmcblk0p3 /mnt
# cd /mnt
# tar cfz ~/pi.tgz . --no-selinux
# cd
# umount /mnt
# parted /dev/mmcblk0
(parted) unit s
(parted) print free
Model: SD SC16G (sd/mmc)
Disk /dev/mmcblk0: 31116288s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
63s 2047s 1985s Free Space
1 2048s 1370111s 1368064s primary fat32 boot, lba
2 1370112s 2369535s 999424s primary linux-swap(v1)
3 2369536s 5298175s 2928640s primary ext4
5298176s 31116287s 25818112s Free Space
(parted) rm 3
(parted) rm 2
(parted) print free
Model: SD SC16G (sd/mmc)
Disk /dev/mmcblk0: 31116288s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
63s 2047s 1985s Free Space
1 2048s 1370111s 1368064s primary fat32 boot, lba
1370112s 31116287s 29746176s Free Space
(parted) mkpart
Partition type? primary/extended? primary
File system type? [ext2]? ext4
Start? 1370112s
End? 31116287s
(parted) set
Partition number? 2
Flag to Invert? lba
New state? on/[off]? off
(parted) print free
Model: SD SC16G (sd/mmc)
Disk /dev/mmcblk0: 31116288s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
63s 2047s 1985s Free Space
1 2048s 1370111s 1368064s primary fat32 boot, lba
2 1370112s 31116287s 29746176s primary ext4
(parted) quit
# mkfs.ext4 /dev/mmcblk0p2
mke2fs 1.44.6 (5-Mar-2019)
/dev/mmcblk0p2 contains a swap file system labelled '_swap'
Proceed anyway? (y,N) y
Discarding device blocks: done
Creating filesystem with 3718272 4k blocks and 930240 inodes
Filesystem UUID: 6a1a0694-8196-4724-a58d-edde1f189b31
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208
Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
# mount /dev/mmcblk0p2 /mnt
# tar xfz ~/pi.tgz -C /mnt --no-selinux
After unpacking the contents of the root partition, it's time to make some changes.
We disable SELinux in /mnt/etc/selinux/config:
SELINUX=disabled
Editing /mnt/etc/fstab, leaving only two entries about the partitions: the boot partition (\/boot, unchanged) and the root partition (change the UUID value, which can be found by checking the output of the blkid command in Linux):
UUID=6a1a0694-8196-4724-a58d-edde1f189b31 \/ ext4 defaults,noatime 0 0
UUID=6938-F4F2 \/boot vfat defaults,noatime 0 0
Finally, we modify the kernel boot parameters: specify the new location of the root partition, disable debugging information output, and (optionally) prevent the kernel from assigning IPv6 addresses to network interfaces:
# cd
# umount /mnt
# mount /dev/mmcblk0p1 /mnt
We bring the contents /mnt/cmdline.txt to the following form (one line without breaks):
root=\/dev\/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait quiet ipv6.disable_ipv6=1
Done:
# cd
# umount /mnt
# sync
We move the microSD to the 'raspberry', boot it up, and gain network access via ssh (root\/centos).
2. Configuring CentOS
The first three immutable actions: passwd, yum -y update, reboot.
We assign network management to networkd:
# yum install systemd-networkd
# systemctl enable systemd-networkd
# systemctl disable NetworkManager
# chkconfig network off
We create a file (along with directories) /etc/systemd/network/eth0.network:
[Match]
Name=eth0
[Network]
DHCP=ipv4
We reboot the 'raspberry' and again gain network access via ssh (the IP address may change). Note that the /etc/resolv.conf, created earlier by Network Manager, is being used. Therefore, in case of problems with resolution, edit its contents. We will not use systemd-resolved it.
We remove the 'unnecessary', fix, and speed up the OS boot:
# systemctl set-default multi-user.target
# yum remove GeoIP Network* aic* alsa* cloud-utils-growpart
cronie* dhc* firewal* initscripts iwl* kexec* logrotate
postfix rsyslog selinux-pol* teamd wpa_supplicant
Who needs cron and cannot handle the built-in , can install the missing one. /var/log-and monitor through journalctl. If a history of the log is required (by default, only information since the system start is stored):
# mkdir /var/log/journal
# systemd-tmpfiles --create --prefix /var/log/journal
# systemctl restart systemd-journald
# vi /etc/systemd/journald.conf
We disable IPv6 usage for the main services (if needed)/etc/ssh/sshd_config:
AddressFamily inet
/etc/sysconfig/chronyd:
OPTIONS="-4"
Time accuracy on the 'raspberry' is an important matter. Since there is no hardware capability to retain the current state of the clock during reboot, synchronization is required. A very good and fast daemon for this is chrony — is already installed and starts automatically. You can change the NTP servers to the nearest ones.
/etc/chrony.conf:
server 0.ru.pool.ntp.org iburst
server 1.ru.pool.ntp.org iburst
server 2.ru.pool.ntp.org iburst
server 3.ru.pool.ntp.org iburst
To set the time zone, we will use a trick. Since our goal is to create a Wi-Fi router that operates at 5GHz frequencies, we will prepare for surprises in advance. regulator:
# yum info crda
Summary: Regulatory compliance daemon for 802.11 wireless networking
This malicious construct, taking into account the time zone, "prohibits" the use of 5GHz frequencies and channels with "high" numbers in Russia. The trick is to set the time zone without using continent/city names, that is, instead of:
# timedatectl set-timezone Europe/Moscow
We push:
# timedatectl set-timezone Etc/GMT-3
And the final touches in the system's configuration:
# hostnamectl set-hostname router
/root/.bash_profile:
. . .
# User specific environment and startup programs
export PROMPT_COMMAND="vcgencmd measure_temp"
export LANG=en_US.UTF-8
export PATH=$PATH:$HOME/bin
3. CentOS Additions
Everything mentioned above can be considered a completed instruction for installing "vanilla" CentOS on Raspberry Pi. You should have a PC that boots in less than 10 seconds, uses less than 15 Megabytes of RAM, and 1.5 Gigabytes of microSD (actually less than 1 Gigabyte due to an incomplete /boot, but let’s be honest to the end).
To install the Wi-Fi access point software on this system, we will need to enhance the capabilities of the standard CentOS distribution. First of all, we will "upgrade" the driver (firmware) of the built-in Wi-Fi adapter. The project's homepage states:
Wifi on the Raspberry 3B and 3B+
The Raspberry PI 3B/3B+ firmware files are not allowed to be distributed by the CentOS Project. You can use the following articles to understand the issue, get the firmware and set up the wifi.
What the CentOS project cannot do, we are not prohibited from doing for personal use. We will replace the distribution Wi-Fi firmware in CentOS with the corresponding one from Broadcom developers (the same hated binary blobs...). This, in particular, will allow the use of AC mode in access point mode.
Wi-Fi firmware upgradeWe determine the device model and the current firmware version:
# journalctl | grep $(basename $(readlink /sys/class/net/wlan0/device/driver))
Jan 01 04:00:03 router kernel: brcmfmac: F1 signature read @0x18000000=0x15264345
Jan 01 04:00:03 router kernel: brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43455-sdio.bin for chip 0x004345(17221) rev 0x000006
Jan 01 04:00:03 router kernel: usbcore: registered new interface driver brcmfmac
Jan 01 04:00:03 router kernel: brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Mar 1 2015 07:29:38 version 7.45.18 (r538002) FWID 01-6a2c8ad4
Jan 01 04:00:03 router kernel: brcmfmac: brcmf_c_preinit_dcmds: CLM version = API: 12.2 Data: 7.14.8 Compiler: 1.24.9 ClmImport: 1.24.9 Creation: 2014-09-02 03:05:33 Inc Data: 7.17.1 Inc Compiler: 1.26.11 Inc ClmImport: 1.26.11 Creation: 2015-03-01 07:22:34
We see that the firmware version 7.45.18 from 01.03.2015 is present, and we note the following set of numbers: 43455 (brcmfmac43455-sdio.bin).
. The lazy can write the image to microSD and retrieve the firmware files from there. Alternatively, you can mount the root partition of the image in Linux and copy what you need from it:
# wget https://downloads.raspberrypi.org/raspbian_lite_latest
# unzip -p raspbian_lite_latest > raspbian.img
# fdisk -l raspbian.img
Disk raspbian.img: 2 GiB, 2197815296 bytes, 4292608 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x17869b7d
Device Boot Start End Sectors Size Id Type
raspbian.img1 8192 532480 524289 256M c W95 FAT32 (LBA)
raspbian.img2 540672 4292607 3751936 1.8G 83 Linux
# mount -t ext4 -o loop,offset=$((540672 * 512)) raspbian.img /mnt
# cp -fv /mnt/lib/firmware/brcm/*43455* ...
'/mnt/lib/firmware/brcm/brcmfmac43455-sdio.bin' -> ...
'/mnt/lib/firmware/brcm/brcmfmac43455-sdio.clm_blob' -> ...
'/mnt/lib/firmware/brcm/brcmfmac43455-sdio.txt' -> ...
# umount /mnt
The acquired Wi-Fi adapter firmware files need to be copied with replacement to the "raspberry" directory. /usr/lib/firmware/brcm/
We restart the future router and smile happily:
# journalctl | grep $(basename $(readlink /sys/class/net/wlan0/device/driver))
Jan 01 04:00:03 router kernel: brcmfmac: F1 signature read @0x18000000=0x15264345
Jan 01 04:00:03 router kernel: brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43455-sdio.bin for chip 0x004345(17221) rev 0x000006
Jan 01 04:00:03 router kernel: usbcore: registered new interface driver brcmfmac
Jan 01 04:00:03 router kernel: brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Feb 27 2018 03:15:32 version 7.45.154 (r684107 CY) FWID 01-4fbe0b04
Jan 01 04:00:03 router kernel: brcmfmac: brcmf_c_preinit_dcmds: CLM version = API: 12.2 Data: 9.10.105 Compiler: 1.29.4 ClmImport: 1.36.3 Creation: 2018-03-09 18:56:28
Version: 7.45.154 from 27.02.2018.
And of course EPEL:
# cat > /etc/yum.repos.d/epel.repo << EOF
[epel]
name=Epel rebuild for armhfp
baseurl=https://armv7.dev.centos.org/repodir/epel-pass-1/
enabled=1
gpgcheck=0
EOF
# yum clean all
# rm -rfv /var/cache/yum
# yum update
4. Network Configuration and Upcoming Challenges
As we agreed earlier, the 'raspberry' is connected by 'cable' to the local network. Let's assume that the provider also provides Internet access in exactly the same way: the address in the public network is dynamically assigned by the DHCP server (possibly tied to the MAC). In this case, after the final configuration of the 'raspberry', it is sufficient to 'plug' the provider's cable into it and everything is ready. Authorization via systemd-networkd — is a topic for another article and is not discussed here.
Wi-Fi interface(s) on Raspberry is the local network, while the built-in Ethernet adapter (eth0) is external. We will statically number the local network, for example: 192.168.0.0/24. The 'raspberry' address: 192.168.0.1. The DHCP server will operate in the external network (Internet).
and — are two issues lurking for anyone dealing with network interface and service configurations in systemd distributions.
Parallel Chaos (lyrical digression)Lennart Poettering crafted his program systemd very well. This systemd launches other programs so quickly that they, without having time to recover from the referee's whistle, stumble and fall at the start without even beginning their hurdle race.
But seriously, aggressive parallelization of launching processes at systemd OS startup is somewhat of a 'donkey bridge' for seasoned sequential LSB folks. Fortunately, bringing this 'parallel chaos' into order turns out to be a simple, though not always obvious task.
We create two virtual bridge interfaces with permanent names: lan and wan. We will 'connect' the Wi-Fi adapter(s) to the first, and eth0 of the 'raspberry' to the second.
/etc/systemd/network/lan.netdev:
[NetDev]
Name=lan
Kind=bridge
/etc/systemd/network/lan.network:
[Match]
Name=lan
[Network]
Address=192.168.0.1/24
IPForward=yes
/etc/systemd/network/wan.netdev:
[NetDev]
Name=wan
Kind=bridge
#MACAddress=xx:xx:xx:xx:xx:xx
/etc/systemd/network/wan.network:
[Match]
Name=wan
[Network]
DHCP=ipv4
IPForward=yes
IPForward=yes eliminates the need to hint the kernel about enabling routing through sysctl.
MACAddress= we will uncomment and change if necessary.
First, we 'connect' eth0. We remember the 'problem of consistency' and only use the MAC address of this interface, which can be found out, for example, like this:
# cat /sys/class/net/eth0/address
Creating /etc/systemd/network/eth.network:
[Match]
MACAddress=b8:27:eb:xx:xx:xx
[Network]
Bridge=wan
We remove the previous configuration file for eth0, reboot the "Raspberry Pi" and gain network access (the IP address will most likely change):
# rm -fv /etc/systemd/network/eth0.network
# reboot
5. DNSMASQ
For creating Wi-Fi access points, nothing beats the sweet duo of dnsmasq + hostapd hasn't been invented yet. In my opinion.
If anyone has forgotten, then… — this is a tool that manages Wi-Fi adapters (in particular, it will take on the task of connecting them to the virtual lan "Raspberry Pi"), authenticates and registers wireless clients.
— configures the client network stack: assigns IP addresses, DNS servers, default gateways, and similar goodies.
We start with dnsmasq:
# yum install dnsmasq
Template /etc/resolv.conf:
nameserver 1.1.1.1
nameserver 1.0.0.1
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 77.88.8.8
nameserver 77.88.8.1
domain router.local
search router.local
we edit it to our liking.
Minimalist /etc/dnsmasq.conf:
domain-needed
bogus-priv
interface=lan
bind-dynamic
expand-hosts
domain=#
dhcp-range=192.168.0.100,192.168.0.199,255.255.255.0,24h
conf-dir=\/etc\/dnsmasq.d
The 'magic' here lies in the parameter bind-dynamic, which tells the dnsmasq daemon to wait for the appearance of the interface=lan, rather than faint from a bout of proud solitude after startup.
# systemctl enable dnsmasq
# systemctl start dnsmasq; journalctl -f
6. HOSTAPD
And finally, the magical configurations of hostapd. I have no doubt that someone reads this article in search of these coveted lines.
Before installing hostapd, we need to tackle the 'uniformity problem'. The built-in Wi-Fi adapter wlan0 can easily change its name to wlan1 when additional USB Wi-Fi equipment is connected. Therefore, we will fix the names of the interfaces in the following way: we will come up with unique names for the (wireless) adapters and bind them to their MAC addresses.
For the built-in Wi-Fi adapter, which is still wlan0:
# cat /sys/class/net/wlan0/address
b8:27:eb:xx:xx:xx
Creating /etc/systemd/network/wl0.link:
[Match]
MACAddress=b8:27:eb:xx:xx:xx
[Link]
Name=wl0
Now we can be sure that wl0 — this is the built-in Wi-Fi. We reboot the "Raspberry Pi" to confirm this.
Installing:
# yum install hostapd wireless-tools
Configuration file /etc/hostapd/hostapd.conf:
ssid=rpi
wpa_passphrase=1234567890
channel=36
country_code=US
interface=wl0
bridge=lan
driver=nl80211
auth_algs=1
wpa=2
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
macaddr_acl=0
hw_mode=a
wmm_enabled=1
# N
ieee80211n=1
require_ht=1
ht_capab=[MAX-AMSDU-3839][HT40+][SHORT-GI-20][SHORT-GI-40][DSSS_CCK-40]
# AC
ieee80211ac=1
require_vht=1
ieee80211d=0
ieee80211h=0
vht_capab=[MAX-AMSDU-3839][SHORT-GI-80]
vht_oper_chwidth=1
vht_oper_centr_freq_seg0_idx=42
Not forgetting for a minute about , we change the necessary parameters and manually check for functionality:
# hostapd /etc/hostapd/hostapd.conf
hostapd will start in interactive mode, displaying its status on the console. If there are no errors, clients that support AC mode can connect to the access point. To stop hostapd, use Ctrl-C.
Now we need to enable hostapd to start automatically with the system. If we proceed with the standard approach (systemctl enable hostapd), after the next reboot, we might find a ‘bleeding’ daemon with the diagnosis of ‘interface wl0 not found’. As a result of the ‘parallel chaos’, hostapd started faster than the kernel found the wireless adapter.
The internet is full of solutions: from forced timeouts before the daemon starts (a few minutes) to another daemon that monitors the interface appearance and (re)starts hostapd. These solutions are workable but quite unsightly. We call upon the great systemd with its ‘goals’ and ‘tasks’ ‘dependencies’.
We copy the distribution service file to /etc/systemd/system/hostapd.service:
# cp -fv /usr/lib/systemd/system/hostapd.service /etc/systemd/system
and modify its content as follows:
[Unit]
Description=Hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator
After=sys-subsystem-net-devices-wl0.device
BindsTo=sys-subsystem-net-devices-wl0.device
[Service]
Type=forking
PIDFile=/run/hostapd.pid
ExecStart=/usr/sbin/hostapd /etc/hostapd/hostapd.conf -P /run/hostapd.pid -B
[Install]
WantedBy=sys-subsystem-net-devices-wl0.device
The magic of the updated service file lies in the dynamic binding of hostapd to the new target — the wl0 interface. The daemon starts when the interface appears and stops when it disappears. And all of this happens online — without rebooting the system. This technique will be especially useful when connecting a USB Wi-Fi adapter to the Raspberry Pi.
Now we can:
# systemctl enable hostapd
# reboot
7. IPTABLES
‘What???’ © Yes, yes! No systemd. No trendy machines (like firewalld) that ultimately do the same thing.
We will use the old trusty iptables, whose service will load network rules into the kernel upon starting and then exit gracefully without remaining resident or consuming resources. systemd has an elegant IPMasquerade=, but we will still trust iptables for address translation (NAT) and the firewall.
Installing:
# yum install iptables-services
# systemctl enable iptables ip6tables
I prefer to keep the iptables configuration in the form of a script (example):
#!/bin/bash
#
# Disable IPv6
#
ip6tables --flush
ip6tables --delete-chain
ip6tables --policy INPUT DROP
ip6tables --policy FORWARD DROP
ip6tables --policy OUTPUT DROP
ip6tables-save > /etc/sysconfig/ip6tables
systemctl restart ip6tables
#
# Cleaning
#
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
#
# Loopback, lan
#
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i lan -j ACCEPT
#
# Ping, Established
#
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
#
# NAT
#
iptables -t nat -A POSTROUTING -o wan -j MASQUERADE
#
# Saving
#
iptables-save > /etc/sysconfig/iptables
systemctl restart iptables
We execute the above script and lose the ability to establish new wired SSH connections with the Raspberry Pi. That's right, we've created a Wi-Fi router, access to which ‘through the Internet’ is disabled by default — now it’s only ‘over the air’. Connect the provider's cable to Ethernet and start surfing!
8. Bonus: +2.4GHz
When I assembled the first Raspberry router according to the above-mentioned diagram, I found myself with a number of gadgets that could not detect the 'berry' at all due to their design limitations with Wi-Fi. Reconfiguring the router to work on 802.11b/g/n felt unsporting, as the maximum speed 'over the air' in that case wouldn’t exceed 40 Mbps, while my favorite Internet provider offers me 100 (via cable).
In fact, the solution to the problem had already been devised: a second Wi-Fi interface operating at a frequency of 2.4GHz, and a second access point. I bought the second USB Wi-Fi 'dongle' that came to hand at the nearest kiosk. The seller was bombarded with questions about the chipset, compatibility with ARM cores of Linux, and the possibility of operating in AP mode (he began it first).
We will configure the 'dongle' similarly to the built-in Wi-Fi adapter.
First, we will rename it to wl1:
# cat /sys/class/net/wlan0/address
b0:6e:bf:xx:xx:xx
/etc/systemd/network/wl1.link:
[Match]
MACAddress=b0:6e:bf:xx:xx:xx
[Link]
Name=wl1
We will delegate the management of the new Wi-Fi interface to a separate daemon hostapd, which will start and stop depending on the presence of a strictly defined 'dongle': wl1.
Configuration file /etc/hostapd/hostapd2.conf:
ssid=rpi2
wpa_passphrase=1234567890
#channel=1
#channel=6
channel=11
interface=wl1
bridge=lan
driver=nl80211
auth_algs=1
wpa=2
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
macaddr_acl=0
hw_mode=g
wmm_enabled=1
# N
ieee80211n=1
require_ht=1
ht_capab=[HT40][SHORT-GI-20][SHORT-GI-40][DSSS_CCK-40]
The contents of this file directly depend on the model of the USB Wi-Fi adapter, so a simple copy/paste may let you down.
We copy the distribution service file to /etc/systemd/system/hostapd2.service:
# cp -fv /usr/lib/systemd/system/hostapd.service /etc/systemd/system/hostapd2.service
and modify its content as follows:
[Unit]
Description=Hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator
After=sys-subsystem-net-devices-wl1.device
BindsTo=sys-subsystem-net-devices-wl1.device
[Service]
Type=forking
PIDFile=/run/hostapd2.pid
ExecStart=/usr/sbin/hostapd /etc/hostapd/hostapd2.conf -P /run/hostapd2.pid -B
[Install]
WantedBy=sys-subsystem-net-devices-wl1.device
Now it's time to start the new instance of hostapd:
# systemctl enable hostapd2
That's it! Give a tug on the 'dongle' and the 'berry' itself, and take a look at the wireless networks around.
Lastly, I want to warn about the quality of the USB Wi-Fi adapter and the power supply for the Raspberry. A 'hot-plugged dongle' can sometimes cause the 'berry' to freeze due to brief electrical issues.
Source: habr.com
