Raspi (Zero W or Rpi 4) router with wlan1 Wifi Dongle

Pi Zero

There are a few options to do this. I used the official documentation and adapted it to create a script:

https://gist.github.com/brettbeeson/4ecf4eb21b39f502a4c50bd1e196e90c

On the Raspi Zero W, plug in a USB OTG adaptor and a wifi dongle. Then run the script.

I used the official docs with minor adaptions.

Other options are RaspAP which is heavyweight by full featured. This tutorial is similiar (wlan0/1 are swapped).

Pi 4

I’m now doing this with a dongle on a Pi4. The aim is a repeater: a low-power IOT device connects to AP on wlan0 (on-board) which is routed to wlan1 (dongle). wlan1 connects via a high-power wifi dongle to the local Wifi.

Setup

Setup pi headless as normal.
Use quick start at raspap.com

Update: Feedback from raspap says it should work out of the box – systemd-resolve should be disabled by RaspAP. My ansible setup script probably interferes with this. The following solution is valid is that scenario.

But! systemd-resolved is hogging port 53 and preventing dnsmasq running. This means the raspi-webgui is visible but you’ll get “unable to get IP address”.

Fix dnsmasq / systemd-resolved conflict

I read this question and did this:

DNSStubLIstener=no # /etc/systemd/resolve.conf
sudo systemctl restart dnsmasq
sudo systemctl restart systemd-resolved

You can check status with systemctl status dnsmasq|systemd-resolved

Now you can connect to the AP and get an IP address!

Check wlan0 and wlan1

Use FAQ about “can I use wlan0 and wlan1 instead of eth0?”. For me, this didn’t require any changes: wlan0 (on-board) was already the AP and wlan1 (dongle) was already connected to my wifi router and the internet.

But! No internet is available on the Pi4: ping www.google.com gets an IP to ping but not result. ping -I wlan1 www.google.com does work. It’s a routing problem… let’s fix that.

Fix Routing

route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.3.141.1      0.0.0.0         UG    303    0        0 wlan0
0.0.0.0         192.168.0.1     0.0.0.0         UG    304    0        0 wlan1
10.3.141.0      0.0.0.0         255.255.255.0   U     303    0        0 wlan0
192.168.0.0     0.0.0.0         255.255.255.0   U     304    0        0 wlan1

The kernel is trying to ge3t out to internet via 10.3.141.1, not the gateway at 192.168.0.1. We (thanks Jeff) can edit /etc/dhcpcd.conf and push wlan0 down a bit by adding metric 500 under it’s heading. Running route -n again shows 192.168.0.1 is back on top, baby! And so we have internets.