There is a huge amount of information on the Internet on creating Wi-Fi access points based on a Raspberry single-board PC. As a rule, the use of the Raspbian native operating system for the Raspberry is implied.
Being an adept of RPM-based systems, I could not pass by this little miracle and not try my favorite CentOS on it.
The article provides instructions for making a 5GHz / AC Wi-Fi router from Raspberry Pi 3 Model B + based on the CentOS operating system. There will be several standard, but little-known tricks, and as a bonus, a drawing for connecting additional Wi-Fi equipment to the “raspberry”, allowing it to work simultaneously in several modes (2,4 + 5GHz).
(mix of images from the public domain)
We note right away that some cosmic velocities will not work. I squeeze a maximum of 100 Mbps from my "raspberry" over the air, and this covers the speed of my Internet provider. Why do we need such a sluggish AC, if even on N in theory you can get half a gigabit? If you asked yourself such a question, then go to the store for a real router with eight external antennas.
0. What you need
- Actually, the very “raspberry product” of caliber: Pi 3 Model B + (to achieve the coveted 5GHz speeds and channels);
- Solid microSD >= 4GB;
- Workstation with Linux and microSD reader/writer;
- The presence of sufficient skills in Linux, the article is for the prepared Geek;
- Wired network (eth0) connectivity between Raspberry and Linux, a running DHCP server on the local network and Internet access from both devices.
A small comment on the last point. “Which came first, the egg or…” how to make a Wi-Fi router in the absence of any Internet access equipment? Let's leave this entertaining exercise out of the scope of the article and just assume that the Raspberry is connected to the local network by wire and has access to the Internet. In this case, we do not need an additional TV and a manipulator to set up the "raspberry".
1. Install CentOS
At the time of this writing, the running version of CentOS on the device is 32-bit. Somewhere on the World Wide Web, I came across opinions about a decrease in the performance of such operating systems on the 64-bit ARM architecture by as much as 20%. I will leave this moment without comment.
On Linux, download the minimal image with the kernel "-RaspberryPI-"and write it to microSD:
# xzcat CentOS-Userland-7-armv7hl-RaspberryPI-Minimal-1810-sda.raw.xz |
dd of=/dev/mmcblk0 bs=4M
# sync
Before we start using the image, we will remove the SWAP partition from it, expand the root to the entire available volume, and get rid of SELinux. The algorithm is simple: we make a copy of the root on Linux, delete all partitions from the microSD except the first one (/boot), create a new root and return its contents from the copy.
Example of required actions (harsh 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 extracting the contents of the root partition, it's time to make some changes to it.
Disable SELinux in /mnt/etc/selinux/config:
SELINUX=disabled
Editing /mnt/etc/fstab, leaving only two partition entries in it: boot (/boot, unchanged) and root (we change the UUID value, which can be found by examining the output of the blkid command on Linux):
UUID=6a1a0694-8196-4724-a58d-edde1f189b31 / ext4 defaults,noatime 0 0
UUID=6938-F4F2 /boot vfat defaults,noatime 0 0
Finally, we change the kernel boot parameters: specify a new location for the root partition, disable debug output, and (optionally) prevent the kernel from assigning IPv6 addresses on network interfaces:
# cd
# umount /mnt
# mount /dev/mmcblk0p1 /mnt
Here is the content /mnt/cmdline.txt to the following form (one line without hyphens):
root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait quiet ipv6.disable_ipv6=1
Finish:
# cd
# umount /mnt
# sync
We rearrange the microSD to the "raspberry", run it and get network access to it via ssh (root / centos).
2. Setting up CentOS
The first three unshakable movements: Passwd, yum-y update, reboot.
We give away network management networked:
# yum install systemd-networkd
# systemctl enable systemd-networkd
# systemctl disable NetworkManager
# chkconfig network off
Create a file (along with directories) /etc/systemd/network/eth0.network:
[Match]
Name=eth0
[Network]
DHCP=ipv4
We reboot the "raspberry" and again we get network access to it via ssh (the IP address may change). Pay attention to what is being used / Etc / resolv.conf, created earlier by Network Manager. Therefore, in case of problems with resolve, edit its contents. Use systemd-resolved we will not.
We remove the "superfluous", repair and speed up the loading of the OS:
# 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 who does not digest the built , can install the missing. / var / logand look through journalctl. If you need a log history (by default, information is stored only from the moment the system was started):
# mkdir /var/log/journal
# systemd-tmpfiles --create --prefix /var/log/journal
# systemctl restart systemd-journald
# vi /etc/systemd/journald.conf
Disable the use of IPv6 by core services (if required)/ Etc / ssh / sshd_config:
AddressFamily inet
/etc/sysconfig/chronyd:
OPTIONS="-4"
The relevance of time on the "raspberry" is an important thing. Since “out of the box” there is no hardware ability to save the current state of the clock upon reboot, synchronization is needed. A very good and fast demon for this - 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 timezone we will use trick. Since our goal is to create a Wi-Fi router operating at 5GHz frequencies, we will prepare in advance for surprises regulator:
# yum info crda
Summary: Regulatory compliance daemon for 802.11 wireless networking
This malicious design, focusing, among other things, on the time zone, “prohibits” the use (in Russia) of 5GHz frequencies and channels with “large” numbers. The trick is to set the time zone without using the names of the continents / cities, that is, instead of:
# timedatectl set-timezone Europe/Moscow
We press:
# timedatectl set-timezone Etc/GMT-3
And the final touches in the hairstyle of the system:
# 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 add-ons
Everything that was said above can be considered a complete instruction for installing vanilla CentOS on a Raspberry Pi. You should end up with a PC that (re)boots in less than 10 seconds, uses less than 15 MB of RAM and 1.5 GB of microSD (less than 1 GB actually due to the incomplete /boot, but let's be honest).
To install Wi-Fi access point software on this system, you will need to slightly expand the capabilities of the standard CentOS distribution. First of all, we will “pump” the driver (firmware) of the built-in Wi-Fi adapter. The project homepage says:
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 is not allowed to the CentOS project is not forbidden to us for personal use. We replace the distribution Wi-Fi firmware in CentOS with the corresponding one from the Broadcom developers (those hated binary blobs ...). This, in particular, will allow the use of AC in access point mode.
WiFi firmware upgradeWe find out 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 is 7.45.18 dated 01.03.2015/XNUMX/XNUMX, and remember the following set of numbers: 43455 (brcmfmac43455-sdio.bin)
. The lazy ones can write the image to microSD and take the files with the firmware from there. Or you can mount the root partition of the image in Linux and copy what you need from there:
# 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 resulting Wi-Fi adapter firmware files must be copied with a replacement for "raspberry" into the directory /usr/lib/firmware/brcm/
We reboot the future router and smile pretty:
# 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/XNUMX/XNUMX.
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 challenges ahead
As we agreed above, the "raspberry" is connected by "wire" to the local network. Suppose that the provider also provides Internet access in exactly the same way: the address in the public network is issued dynamically by the DHCP server (maybe tied to the MAC). In this case, after the final configuration of the "raspberry", just "plug" the provider's cable into it and you're done. Authorization using systemd-networkd - the topic of a separate article and is not considered here.
The Wi-Fi interface(s) on the Raspberry is a local network, and the built-in Ethernet adapter (eth0) is an external one. Let's number the local network statically, for example: 192.168.0.0/24. Raspberry address: 192.168.0.1. The external network (Internet) will run a DHCP server.
и - two troubles that await everyone who is involved in configuring network interfaces and services in systemd distributions.
Parallel chaos (lyrical digression)Lennart Pottering made his program systemd Very good. This systemd launches other programs so quickly that they stumble and fall at the start before they even start their steeplechase before they have time to recover from the referee's kick of the whistle.
But seriously, the aggressive parallelization of running processes at the start of systemd-OS is a kind of "donkey bridge" for hardened serial LSB-shnikov. Fortunately, putting this “parallel chaos” in order turns out to be a simple, though not always obvious, matter.
Create two virtual bridge interfaces (bridge) with constant names: lan и wan. We “connect” the Wi-Fi adapter (s) to the first one, and eth0 “raspberries” to the second one.
/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 to the kernel via sysctl to enable routing.
MACAddress= uncomment and change if necessary.
First we "connect" eth0. Keep in mind the “problem of uniformity” and use only the MAC address of this interface, which you can find out, for example, like this:
# cat /sys/class/net/eth0/address
Create /etc/systemd/network/eth.network:
[Match]
MACAddress=b8:27:eb:xx:xx:xx
[Network]
Bridge=wan
Delete the previous eth0 configuration file, reboot the raspberry and get network access to it (the IP address will most likely change):
# rm -fv /etc/systemd/network/eth0.network
# reboot
5.DNSMASQ
For the manufacture of Wi-Fi access points, nothing is better than a sweet couple from dnsmasq + hostapd not yet figured out. In my opinion.
If anyone forgot... - this is a thing that manages Wi-Fi adapters (in particular, it will take the trouble of connecting them to a virtual lan "raspberries"), authorizes and registers wireless clients.
- configures the network stack of clients: gives out IP addresses, DNS servers, default gateway and similar delights.
Starting with dnsmasq:
# yum install dnsmasq
Pattern / 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
edit it to your liking.
minimalistic /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 interface=lan, and not faint from an attack of proud loneliness after the start.
# systemctl enable dnsmasq
# systemctl start dnsmasq; journalctl -f
6. HOSTAPD
And finally, the magical hostapd configurations. I have no doubt that someone is reading this article in search of these cherished lines.
Before installing hostapd, you need to deal with the "uniformity problem". The built-in Wi-Fi adapter wlan0 can easily change its name to wlan1 when connecting additional USB Wi-Fi equipment. Therefore, we fix the interface names in the following way: we will come up with unique names for (wireless) adapters and bind them to 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
Create /etc/systemd/network/wl0.link:
[Match]
MACAddress=b8:27:eb:xx:xx:xx
[Link]
Name=wl0
Now we will be sure that wl0 is built-in Wi-Fi. We reboot the "raspberry" to make sure of this.
Install:
# 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
Don't forget for a moment , change the parameters we need and manually check for performance:
# hostapd /etc/hostapd/hostapd.conf
hostapd will start in interactive mode, broadcasting its status to the console. If there are no errors, then clients that support AC mode can already connect to the access point. To stop hostapd - Ctrl-C.
It remains to include hostapd in the system startup. If you act as standard (systemctl enable hostapd), then after the next reboot, you can get a “rolling in the blood” demon with a diagnosis of “interface wl0 not found". As a result of the "parallel chaos", hostapd started up faster than the kernel found the wireless adapter.
The Internet is full of cures: from a forced timeout before starting the daemon (a few minutes), to another daemon that monitors the appearance of the interface and (re)starts hostpad. The solutions are quite working, but terribly ugly. We call on the help of the great systemd with its "goals" and "objectives" "dependencies".
Copy the distribution service file to /etc/systemd/system/hostapd.service:
# cp -fv /usr/lib/systemd/system/hostapd.service /etc/systemd/system
and bring its contents to the following form:
[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 is to dynamically bind hostapd to a new target, the wl0 interface. When an interface appears, the daemon starts, when it disappears, it stops. And it's all online - without rebooting the system. This technique will be especially useful when connecting a USB Wi-Fi adapter to a raspberry.
Now you can:
# systemctl enable hostapd
# reboot
7.IPTABLES
"Wha???" © Yes, yes! None systemd. No newfangled combines (in the form firewalld), which end up doing the same thing.
We use the good old iptables, whose services, after their start, will load network rules into the kernel and quietly complete their work without remaining resident and without consuming resources. systemd has elegant IPMasquerade=, but we will still entrust address translation (NAT) and the firewall to iptables.
Install:
# yum install iptables-services
# systemctl enable iptables ip6tables
I prefer to store the iptables configuration as 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". That's right, we have made a Wi-Fi router, access to which "via the Internet" is prohibited by default - now only "over the air". We connect the provider's cable to Ethernet and start surfing!
8. Bonus: +2,4GHz
When, according to the above drawing, I assembled the first Raspberry router, I found a number of gadgets in my household that, due to their Wi-Fi design limitations, could not see the “raspberry” at all. Reconfiguring the router to work in 802.11b / g / n was unsportsmanlike, since the maximum speed "over the air" in this case did not exceed 40 Mbps, and my favorite Internet provider offers me 100 (by cable).
In fact, the solution to the problem had already been thought of: a second Wi-Fi interface operating at 2,4GHz and a second access point. In the nearest stall, I bought not the first, but the second USB Wi-Fi “whistle” that came across to me. The seller was tormented by questions about the chipset, compatibility with ARM Linux kernels, and the ability to work in AP mode (he started it first).
We configure the "whistle" by analogy with the built-in Wi-Fi adapter.
First, let's 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 assign a separate hostapd daemon to manage the new Wi-Fi interface, which will start and stop depending on the presence of a strictly defined “whistle” in the system: 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 content of this file directly depends on the USB Wi-Fi adapter model, so a banal copy / paste can let you down.
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 bring its contents to the following form:
[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
It remains to enable the new hostapd instance:
# systemctl enable hostapd2
That's all! Pull the "whistle" and the "raspberry" itself, look at the wireless networks around.
And finally, I want to warn you about the quality of the USB Wi-Fi adapter and Raspberry power supply. Connected "on a hot whistle", can sometimes cause "raspberry hang" due to short-term electrical troubles.
Source: habr.com