How to Build your Own

Wireless Router
Renaud Cerrato
Follow
Oct 22, 2018 · 4 min read
  Choosing the hardware (this part)

 Bringing up the network interfaces (part 2)

 Setting-up a 802.11ac (5Ghz) access-

point (part 3)

I’ve spent the last decade buying cheap networking

hardware and upgrading them to DD-WRT in order to
get back $500+ worth of “features” that have been
expunged from the Linux kernel on which the stock
firmwares were based on.

Despite unstable builds, unfixed bugs and the

controversy about it, DD-WRT was still a better choice
than stock firmwares. But nowadays, decent hardware
is cheaper than ever and Linux is the new fad among
the DIY community (I’m looking at you, Mr Raspberry),
so why not making your own, tailor-made, wireless
router once and for all?

The Hardware
Among the important pieces of hardware you’ll have to
pick, you must first choose your platform: x86 or ARM?
I’m not going to explain the key differences in details
since that information is available, but long story short:
the former have better performance while the latter is
all about being cost and power effective. Whereas
Raspberry Pi boards (or alike) are extremely cheap and
probably have more horsepower than most wireless
routers you’ll find on commercial off-the-shelf
products, keep in mind that x86-based platforms are
widespreads and benefits of well-standardized form
factors and extension ports.

Of course, the most important piece of hardware is the

wireless chipset: both 802.11n (2.4Ghz)
and 802.11ac (5Ghz) are de-facto standards today, but
choosing a wireless device for Linux might be
a daunting task, even more if AP mode must be
supported. Long story short again: Atheros chipsets
are the way to go for a painless road.
Both ath9k and ath10k drivers are well maintained,
and you’ll easily find those chipsets in USB and/or
mini-PCIe shape depending on your available ports.
While a single NIC interface is the minimum
requirement, RAM and storage may be freely chosen
according to your needs.

Bill of Material
Making some personal trade-off on price and power-
consumption, I chose an x86-based platform to benefit
of a modular, upgradable (and relatively beefy) setup.

If you’re not going to pick an ARM platform, be sure to

go fanless.

 Gigabyte GA-J1900N-D3V (J1900 Quad-Core

2Ghz Celeron, dual NIC)

 Airetos AEX-QCA9880-NX (dual band

802.11ac, MIMO)

 4GB RAM (DDR3-LP, 1333Mhz, 1.35v)

 mPCIe Extender

 MX500 mini-ITX case

 3 x 6dBi RP-SMA Dual Band Antenna + RP-

SMA Pigtail Cable

 PicoPSU-90

 Spare 2.5” HDD

The case is spacious, and have pre-cut holes for the
AC/DC plug. The motherboard, RAM and the Pico-PSU
installation went smoothly:

Hardware Porn
The trickiest part has been the mini-PCIe WiFi
card since the board only supports half-sized cards:
here come the mPCIe Extender to the rescue. I used a
20cm FFC cable (included) to connect both sides of the
adapter and fixed the mini-PCIe side to the chassis
using some double sided tape.
mini-PCIe Extender

Luckily, the case comes with 3 pre-cut holes for the

antennas. Here’s the final result:
The next part will show you how to setup your network
interfaces and enable a minimal 802.11n access-point.
How to Build your Own
Wireless Router (Part 2)
Renaud Cerrato
Follow
Oct 22, 2018 · 5 min read

This post is the second part of the serie. The first

part covered the hardware, that part will show you how
to setup your network interfaces and enable a minimal
802.11n access-point.

 Choosing the hardware (part 1)

 Bringing up the network interfaces (this part)

 Setting-up a 802.11ac (5Ghz) access-point (part 3)

The Software
No surprise, Linux is the de-facto choice. Depending on
the hardware you previously picked, it may be an
optimized distribution like Raspbian (for Raspberry Pi)
or any other Linux distro you’re comfortable with.
Since I’m an Ubuntu user for years, I chose Ubuntu
Server 18.04 LTS for a butter smooth experience and
long term support.
The remaining parts of the serie will assume you’re
running a Debian-derived Linux distribution.

Assuming the installation went right and you’re given

access to a shell, let’s first identify the interfaces
names:
$ ip -br a | awk '{print $1}'
lo
enp1s0
enp2s0
wlp5s0

The motherboard have 2 built-in NIC

named enp1s0 and enp2s0. The wireless card is showing
as wlp5s0, and support AP mode as expected:
$ iw list
...
Supported interface modes:
* managed
* AP
* AP/VLAN
* monitor
* mesh point

We are now able to draw what we want to achieve: the

first NIC will serve as the WAN port, while the
remaining one will be bridged to the wireless interface:
Networking
If you’re running Ubuntu 18.04, let’s immediately get
rid of netplan to get back /etc/network/interfaces support:
$ sudo apt-get install ifupdown bridge-utils
$ sudo systemctl stop networkd-dispatcher
$ sudo systemctl disable networkd-dispatcher
$ sudo systemctl mask networkd-dispatcher
$ sudo apt-get purge nplan netplan.io
We’ll pick dnsmasq as DHCP/DNS server:
$ sudo apt-get install dnsmasq

Since we’ll be running and configuring

the dnsmasq process through the post-up hook, don’t forget
to disable the daemon on startup:
$ sudo sed -i "s/^ENABLED=1$/ENABLED=0/g" /etc/default/dnsmasq

Let’s write a preliminary network interfaces

configuration matching the diagram, including a
minimal dnsmasq setup:
$ cat /etc/network/interfaces
# Loopback
auto lo
iface lo inet loopback# WAN interface
auto enp1s0
iface enp1s0 inet dhcp# Bridge (LAN)
auto br0
iface br0 inet static
address 192.168.1.1
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
bridge_ports enp2s0
post-up /usr/sbin/dnsmasq \
--pid-file=/var/run/dnsmasq.$IFACE.pid \
--dhcp-leasefile=/var/lib/misc/dnsmasq.
$IFACE.leases \
--conf-file=/dev/null \
--interface=$IFACE --except-interface=lo \
--bind-interfaces \
--dhcp-range=192.168.1.10,192.168.1.150,24h

pre-down cat /var/run/dnsmasq.$IFACE.pid | xargs kill

/etc/network/interfaces documentation is available on

the man page.
As you may have noticed, dnsmasq will be started as soon
as the bridge is up thanks to the post-up section. Its
configuration is done through command line
arguments only (--conf-file=/dev/null) and the process will
be shutdown when the interface go down.

The bridge_ports field is intentionally missing wlp5s0 since

that interface will be added to the bridge automatically
by hostapd (brctl may refuse to do this before hostapd has
been started to change the interface mode).

dnsmasq documentation is available on the man page.

You can now restart your networking (sudo service networking

restart) or simply reboot to check if your network

configuration is properly setup.

However, please note that while you should be able to

get DHCP leases from enp2s0 at this point, you won’t be
able to connect wirelessly (more on this later), nor
able to connect to the internet yet (see below).

Routing
At this point, we need to route packets between the
LAN (enp2s0) and WAN (enp1s0) interfaces, and
enable masquerading on it.

Enabling packet forwarding is easy:

$ sudo sysctl -w net.ipv4.ip_forward=1
$ echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf

The latter command will ensure that the configuration

will survive to the next reboot.

Enabling packet masquerading is another story, and

usually requires to deal (or rather fight) with iptables.
Thankfully, stone-age has long passed by, and the guys
at FireHol put a lot of efforts adding the required level
of abstraction to that:
$ sudo apt-get install firehol

FireHOL is a language which builds secure, stateful

firewalls from easy to understand, human-readable
configurations. Humans are not required to
write iptables statements anymore: your configuration
file will be translated to iptables statements and applied
before quitting. No daemon running in the background.

Enabling masquerading for the LAN interfaces while

adding minimum firewall rules using firehol is as simple
as:
$ cat /etc/firehol/firehol.conf
version 6# Accept all client traffic on WAN
interface enp1s0 wan
client all accept# Accept all traffic on LAN
interface br0 lan
server all accept
client all accept# Route packets between LAN and WAN
router lan2wan inface br0 outface enp1s0
masquerade
route all accept
 has been made for humans by humans. Take a
firehol

look at the documentation.

You can test the above setup by starting firehol manually

(sudo firehol start) and by connecting a laptop to the LAN
port: you should now be able to browse the
internet if the WAN port is plugged.

Before rebooting, do not forget to

edit /etc/default/firehol to allow FireHol to start on boot:
$ sudo sed -i -E "s/^START_FIREHOL=.+$/START_FIREHOL=YES/g"
/etc/default/firehol

I won’t go into details about the whole firehol syntax,

the configuration file should be almost self-explanatory
and I recommend giving a look at
the documentation for a more complex setup. If you’re
really curious about what firehol did to your iptables,
just drop sudo firehol status on the command line.

Wireless Access Point

With no surprise, we’ll use hostapd to manage your
access-point:
$ sudo apt-get install hostapd

Before going further, I’d recommend to

uninstall NetworkManager since we don't need it anymore but
mostly because of a known bug:
$ sudo nmcli radio wifi off && sudo rfkill unblock wlp5s0
$ sudo apt-get remove network-manager
You’ll find below a minimal and almost self-explanatory
802.11n/2.4Ghz/WPA2-AES configuration file:
$ cat /etc/hostapd/hostapd-simple.conf
#### Interface configuration ####
interface=wlp5s0
bridge=br0
driver=nl80211##### IEEE 802.11 related configuration #####
ssid=iCanHearYouHavingSex
hw_mode=g
channel=1
auth_algs=1
wmm_enabled=1##### IEEE 802.11n related configuration #####
ieee80211n=1##### WPA/IEEE 802.11i configuration #####
wpa=2
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
wpa_passphrase=YouCantGuess

hostpad.conf documentation can be found inline

at /usr/share/doc/hostapd/examples/hostapd.conf

The configuration above can be tested by hand:

$ sudo hostapd /etc/hostapd/hostapd-simple.conf

If everything goes well, you should now be able to

connect wirelessly. If you’re satisfied with the
result, do not forget to edit the interface
configuration to start hostapd right after the interface
goes up (as seen below).

Here’s your final /etc/network/interfaces:

$ cat /etc/network/interfaces
# Loopback
auto lo
iface lo inet loopback# WAN interface
auto enp1s0
iface enp1s0 inet dhcp# Bridge (LAN)
auto br0
iface br0 inet static
 address 192.168.1.1
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
bridge_ports enp2s0
post-up /usr/sbin/hostapd \
-P /var/run/hostapd.$IFACE.pid \
-B /etc/hostapd/hostapd-simple.conf
post-up /usr/sbin/dnsmasq \
--pid-file=/var/run/dnsmasq.$IFACE.pid \
--dhcp-leasefile=/var/lib/misc/dnsmasq.
$IFACE.leases \
--conf-file=/dev/null \
--interface=$IFACE --except-interface=lo \
--bind-interfaces \
--dhcp-range=192.168.1.10,192.168.1.150,24h

pre-down cat /var/run/dnsmasq.$IFACE.pid | xargs kill

pre-down cat /var/run/hostapd.$IFACE.pid | xargs kill

Conclusion
In this part, we learned how to properly setup your
network interfaces using /etc/network/interfaces,
introducing dnsmasq as DHCP server. We
leveraged firehol to declare your firewall and routing
rules before setting-up hostapd. At this point, your router
is accepting and properly routing traffic between its
interfaces, delivering DHCP leases on the LAN and
broadcasting some SSID on the 2.4Ghz channels.

The next part will enable 802.11ac (5Ghz).

How to Build your Own

Wireless Router (Part 3)
Renaud Cerrato
Follow
Oct 22, 2018 · 6 min read
Photo by John Barkiple on Unsplash

This post is the third part of the serie. The previous

part covered the system configuration of a minimal
802.11n (2.4Ghz) access point, that part will enable
802.11ac (5Ghz).

 Choosing the hardware (part 1)

 Bringing up the network interfaces (part 2)

 Setting-up a 802.11ac (5Ghz) access-point (this part)

Passive Scan
According to the documentation of the Airetos AEX-
QCA9880-NX, the chipset is fully 802.11ac capable and
we should now be able to move from the crowded 2.4
Ghz channels to the 5 Ghz heaven.

Let’s ask the device about the supported frequencies:

$ iw list
...
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)
 ...
Frequencies:
* 5180 MHz [36] (17.0 dBm) (no IR)
* 5200 MHz [40] (17.0 dBm) (no IR)
* 5220 MHz [44] (17.0 dBm) (no IR)
* 5240 MHz [48] (17.0 dBm) (no IR)
* 5260 MHz [52] (23.0 dBm) (no IR, radar detection)
* 5280 MHz [56] (23.0 dBm) (no IR, radar detection)
* 5300 MHz [60] (23.0 dBm) (no IR, radar detection)
* 5320 MHz [64] (23.0 dBm) (no IR, radar detection)
* 5500 MHz [100] (23.0 dBm) (no IR, radar detection)
* 5520 MHz [104] (23.0 dBm) (no IR, radar detection)
* 5540 MHz [108] (23.0 dBm) (no IR, radar detection)
* 5560 MHz [112] (23.0 dBm) (no IR, radar detection)
* 5580 MHz [116] (23.0 dBm) (no IR, radar detection)
* 5600 MHz [120] (23.0 dBm) (no IR, radar detection)
* 5620 MHz [124] (23.0 dBm) (no IR, radar detection)
* 5640 MHz [128] (23.0 dBm) (no IR, radar detection)
* 5660 MHz [132] (23.0 dBm) (no IR, radar detection)
* 5680 MHz [136] (23.0 dBm) (no IR, radar detection)
* 5700 MHz [140] (23.0 dBm) (no IR, radar detection)
* 5720 MHz [144] (23.0 dBm) (no IR, radar detection)
* 5745 MHz [149] (30.0 dBm) (no IR)
* 5765 MHz [153] (30.0 dBm) (no IR)
* 5785 MHz [157] (30.0 dBm) (no IR)
* 5805 MHz [161] (30.0 dBm) (no IR)
* 5825 MHz [165] (30.0 dBm) (no IR)
...

From the curated output above, we can see that the

chipset supports channels 1 to 14 (2.4 Ghz) and
channels 36 to 165 (5 Ghz) — but did you noticed the no

IR flag?

The no IR flag stands for no-initiating-

radiation (a.k.a passive scan) and that means you
cannot use that mode of operation if that require you to
initiate radiation first (and that includes beacons). In
other words, you cannot run an access-point on
those channels!
Regulatory compliance
The above situation is because of the Linux regulatory
compliance, which regulates usage of the radio
spectrum depending on a territory basis.

But, wait!

I’m living in the US and according to the link above, I

should be able to emit on channels 36–48, so
what’s going on? Let’s take a look at the regulatory
domain currently in use:
$ iw reg get
country 00: DFS-UNSET
 (2402 - 2472 @ 40), (N/A, 20), (N/A)
(2457 - 2482 @ 40), (N/A, 20), (N/A), NO-IR
(2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, NO-IR
(5170 - 5250 @ 80), (N/A, 20), (N/A), NO-IR
(5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, NO-IR
(5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, NO-IR
(5735 - 5835 @ 80), (N/A, 20), (N/A), NO-IR
(57240 - 63720 @ 2160), (N/A, 0), (N/A)

The output above tell us that the current regulatory

domain in use is worldwide (or unset), that mean it is
currently using minimum values allowed in every
country.

Unfortunately, trying to manually set the regulatory

domain through sudo iw reg set US won’t help because the
card has been shipped with the world regulatory
domain burned into EEPROM:
$ dmesg | grep EEPROM
[ 12.123068] ath: EEPROM regdomain: 0x6c
Patch it!
Fortunately, the regulatory compliance is dealt at the
driver level and can be easily patched. The original
patch can be found in the Open-WRT source tree.

First of all, be sure to enable the source repository

from/etc/apt/sources.list :
$ cat /etc/apt/sources.list
...
deb-src http://us.archive.ubuntu.com/ubuntu/ bionic main
restricted
...

Then, prepare the build environment by installing the

required dependencies:
$ sudo apt-get install build-essential fakeroot
$ sudo apt-get build-dep linux

Grab the source of your current kernel:

$ apt-get source linux

Since the original Open-WRT patch can’t be applied “as

is” against the Ubuntu Kernel tree because of subtle
differences in the build system, I had to fix it:
$ VERSION=$(uname -r)
$ cd linux-${VERSION%%-*}
$ wget -O -
https://gist.github.com/renaudcerrato/02de8b2e8dc013bc71326defd2
ef062c/raw/a2db325e520e6442c8c12f7599d64ac1b7596a3e/402-
ath_regd_optional.patch | patch -p1 -b

Everything should now be ready for the build:

$ fakeroot debian/rules clean
$ fakeroot debian/rules binary-generic
If everything goes well, you can now install your
patched Kernel over the previous one:
$ cd ..
$ sudo dpkg -i linux*.deb

Reboot, and voilà:

$ sudo iw reg set US
$ iw list
...
Frequencies:
* 5180 MHz [36] (17.0 dBm)
* 5200 MHz [40] (17.0 dBm)
* 5220 MHz [44] (17.0 dBm)
* 5240 MHz [48] (17.0 dBm)
* 5260 MHz [52] (23.0 dBm) (radar detection)
* 5280 MHz [56] (23.0 dBm) (radar detection)
* 5300 MHz [60] (23.0 dBm) (radar detection)
* 5320 MHz [64] (23.0 dBm) (radar detection)
* 5500 MHz [100] (23.0 dBm) (radar detection)
* 5520 MHz [104] (23.0 dBm) (radar detection)
* 5540 MHz [108] (23.0 dBm) (radar detection)
* 5560 MHz [112] (23.0 dBm) (radar detection)
* 5580 MHz [116] (23.0 dBm) (radar detection)
* 5600 MHz [120] (23.0 dBm) (radar detection)
* 5620 MHz [124] (23.0 dBm) (radar detection)
* 5640 MHz [128] (23.0 dBm) (radar detection)
* 5660 MHz [132] (23.0 dBm) (radar detection)
* 5680 MHz [136] (23.0 dBm) (radar detection)
* 5700 MHz [140] (23.0 dBm) (radar detection)
* 5720 MHz [144] (23.0 dBm) (radar detection)
* 5745 MHz [149] (30.0 dBm)
* 5765 MHz [153] (30.0 dBm)
* 5785 MHz [157] (30.0 dBm)
* 5805 MHz [161] (30.0 dBm)
* 5825 MHz [165] (30.0 dBm)
...

In order to avoid unattended upgrade, you may want

to pin your Linux Kernel version.

Configuration
Your new hostapd configuration file should be almost
straightforward now: hw_mode=a will enable the 5Ghz
bands while ieee80211ac=1 enable 802.11ac (VHT).
Using ieee80211d=1 along with country_code=US, we’ll advertise
the regulatory domain we’re working on.

To get the most of your

bandwidth, ht_capab and vht_capab should been set to reflect
the capabilities of the hardware:
$ iw list
...
Band 1:
Capabilities: 0x19e3
RX LDPC
HT20/HT40
Static SM Power Save
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 7935 bytes
DSSS/CCK HT40
...
Band 2:
VHT Capabilities (0x338001b2):
Max MPDU length: 11454
Supported Channel Width: neither 160 nor 80+80
RX LDPC
short GI (80 MHz)
TX STBC
RX antenna pattern consistency
TX antenna pattern consistency
...

According to the output above, here’s your

final hostapd.conf:
$ cat /etc/hostapd/hostapd.conf
#### Interface configuration ####
interface=wlp5s0
bridge=br0
driver=nl80211##### IEEE 802.11 related configuration #####
ssid=iCanHearYouHavingSex
hw_mode=a
channel=0
auth_algs=1
wmm_enabled=1
country_code=US
ieee80211d=1
ieee80211h=0##### IEEE 802.11n related configuration #####
ieee80211n=1
ht_capab=[HT40+][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1]
[DSSS_CK-40][LDPC][MAX-AMSDU-7935]##### IEEE 802.11ac related
configuration #####
ieee80211ac=1
vht_capab=[MAX-MPDU-11454][RXLDPC][SHORT-GI-80][TX-STBC-2BY1]
[RX-STBC-1][MAX-A-MPDU-LEN-EXP7][TX-ANTENNA-PATTERN][RX-ANTENNA-
PATTERN]
vht_oper_chwidth=1##### WPA/IEEE 802.11i configuration #####
wpa=2
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
wpa_passphrase=YouCantGuess

hostpad.conf documentation can be found inline

at /usr/share/doc/hostapd/examples/hostapd.conf

Conclusion
In this part, you learned about Linux regulatory
compliance and how to workaround it by patching your
Linux kernel before setting-up hostapd for 5GHz
operations.

At this point, your wireless router is fully capable, and

you should now be able to dive into most of the
configuration files if you’re interested in more complex
setups.
Feel free to suggest new articles for the serie and, in
the meantime, I recommend to have a look at my
companion article about adding virtual SSID to hostapd.

Thanks for reading!

How to Setup a Virtual SSID

with hostapd
Renaud Cerrato
Follow
Oct 22, 2018 · 3 min read

Whether you’re willing to setup a guest access-point,

or a dedicated wireless network for your VPN needs,
you’ll have to setup a virtual SSID at some point. This
article will walk you through the required steps to
achieve it using hostapd.

This article is a companion to my previous serie “How

to Build Your Own Wireless Router” and is assuming
you already setup your wireless card as an access-
point. If this is not the case, head up to my previous
article.

Diagram
Based on my current setup, here’s an updated diagram
of what I want to achieve. Assuming wlp5s0 is the
physical wireless interface, the virtual SSID will run on
a virtual wlan0 interface, using its own 192.168.2.0/24 sub-
network:
Preliminary
First of all, let’s check that your wireless device
supports multiple SSID:
$ iw list
...
valid interface combinations:
* #{ AP, mesh point } <= 8,
 total <= 8, #channels <= 1, STA/AP BI must match
...

From the output above, we know that the chipset

supports up to 8 AP on a single channel. That mean
we can setup up to 7 virtual SSID, and they will all run
on the same channel.

Network interfaces
According to the documentation found in hostapd.conf,
there’s a strong requirement between the MAC
address of the physical interface, and the BSSID of the
virtual interfaces:
hostapd will generate a BSSID mask based on the BSSIDs that are
configured. hostapd will verify that dev_addr & MASK ==
dev_addr. If this is not the case, the MAC address of the radio
must be changed before starting hostapd. If a BSSID is
configured for every secondary BSS, this limitation is not
applied at hostapd and other
masks may be used if the driver supports them (e.g., swap the
locally administered bit)BSSIDs are assigned in order to each
BSS, unless an explicit BSSID is specified using the 'bssid'
parameter.If an explicit BSSID is specified, it must be chosen
such that it:
- results in a valid MASK that covers it and the dev_addr
- is not the same as the MAC address of the radio
- is not the same as any other explicitly specified BSSID

In order to fulfill the requirements above and

let hostapd automatically assign the BSSID of the virtual
interface(s) without complaining, we’ll update the MAC
address of the physical wireless interface by forcing its
four least significant bits to zero. That’s enough to
allocate 15 virtual BSSID, way more than necessary.
First, let’s determine the current MAC address:
$ ip addr show wlp5s0 | grep link | awk '{print $2}'
44:c3:06:00:03:eb

According to the output above, by clearing the four

least significant bits and also setting the U/L bit (for
sanity), the new MAC address would be 46:c3:06:00:03:e0.

Now, let’s update the network interface configuration

to change the MAC address right before the interface
is brought up, and also declare the virtual wireless
interface according to the diagram:
$ cat /etc/network/interfaces
...
# Physical Wireless
auto wlp5s0
iface wlp5s0 inet manual
pre-up ip link set dev wlp5s0 address 46:c3:06:00:03:e0#
Virtual Wireless
allow-hotplug wlan0
iface wlan0 inet static
address 192.168.2.1
network 192.168.2.0
netmask 255.255.255.0
broadcast 192.168.2.255
post-up /usr/sbin/dnsmasq \
--pid-file=/var/run/dnsmasq-wlan0.pid \
--conf-file=/dev/null \
--interface=wlan0 --except-interface=lo \
--bind-interfaces \
--dhcp-range=192.168.2.10,192.168.2.150,24h
post-down cat /var/run/dnsmasq-wlan0.pid | xargs kill
...

That’s it. I’m using dnsmasq as DHCP server - feel free to

use your prefered weapons. Please note that allow-
hotplug is required on the virtual interface to properly

work.
Access point configuration
Now, the easiest part: we’ll add a virtual SSID to the
current hostapd configuration. Simply append, at the
bottom of your existing hostapd.conf, the desired
configuration:
$ cat /etc/hostapd/hostapd.conf
...
### Virtual SSID(s) ###
bss=wlan0
ssid=MyVirtualSSID
wpa=2
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
wpa_passphrase=you_cant_guess

In the example above, I used a WPA2 encryption but

most of the options are available apart from radio
interface specific items (like channel). We could add more
virtual SSIDs by simply appending more configurations
— according we declared and properly configured the
corresponding virtual interfaces.

Now, reboot, and you should be able to see your new

SSID, along with your new wireless interface (notice
the MAC address):
$ ip addr show wlan0 | grep link | awk '{print $2}'
46:c3:06:00:03:e1

That’s all folks

*CLICK SHOW MORE FOR PARTS LIST* If you want to build a cheap but powerful router to manage
your home network, this build may be for you! You can also refurbish an old pc that you already
have to save some money and have the same result. PARTS USED FOR THIS BUILD: AMD Athlon 5350
(AM1) ASUS AM1M-A (any recent processor & motherboard will work fine) A stick of 8 GB DDR3
RAM I had lying around (everything from 2 GB is OK) 120 GB Kingston SSD (any SSD is OK) Realtek-
based quad NIC (could have used a dual NIC as well) TP-Link WiFi cards with Atheros chipset (one for
each frequency, you can also set up a VLAN and use just one card) DC-DC converter & power brick
scavenged from a LC-Power case (you can use a PicoPSU) Micro-ATX case with low profile brackets