There are similar questions already, but I can't follow their descriptions. Here's what I have:

+-----+     +--------------------+           +----------------------+          +---------------+
|     |     | ISP's Modem/Router |           | Debian Box with      | <--GbE-- |               |
| ISP | <-- |  (opposite corner  | <--WiFi-- | USB WiFi adapter and | <--GbE-- | Local Network |
|     |     |    of the house)   |           | 8-port GbE switch    | <--GbE-- |               |
+-----+     +--------------------+           +----------------------+          +---------------+

And some of those local Ethernet cords are getting kinda long.

So here's what I want:

+-----+     +--------------------+           +---------------------------+           +---------------+
|     |     | ISP's Modem/Router |           | Debian Box with           | <--GbE--- |               |
| ISP | <-- |  (opposite corner  | <--WiFi-- | TWO USB WiFi adapters and | <--GbE--- | Local Network |
|     |     |    of the house)   |           | 8-port GbE switch         | <--WiFi-- |               |
+-----+     +--------------------+           +---------------------------+           +---------------+

Essentially, I'm just replacing the longer wires with WiFi, in the same local network. The overall result should be as if a standard WiFi router had its WAN port converted to a separate WiFi adapter, in that the local combination of wired and wireless behaves as a single network, and I can connect anything to it by just matching the "router's" SSID and password. (The "router" in this case refers to the Debian box, not the ISP's modem/router.)

Here are my config files so far, for that Debian box, which currently produce the top diagram. The question is how to modify them after plugging in the second WiFi adapter, to produce the second diagram, and to guarantee that the two adapters don't switch roles. (The one that presently connects to the ISP claims to also support AP mode, but falls apart when it tries. So I want to keep that one in its present role, and have the new one as the new AP.)


# Affects several other files:
# /etc/dnsmasq.conf
# /etc/network/interfaces
# /root/Scripts/Startup-Network.sh

# BPI-R1 VLAN configuration #
# This will create the following ethernet port:
# - eth0.101 = LAN (5 port switch)

ifconfig eth0 up

# The swconfig port number are:
# |2|1|0|4|  |3|
# (looking at front of ports)

swconfig dev eth0 set reset 1
swconfig dev eth0 set enable_vlan 1
swconfig dev eth0 vlan 101 set ports '4 0 1 2 3 8t'
swconfig dev eth0 set apply 1

exit 0


# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

auto lo
iface lo inet loopback

# eth0.x matches the 'vlan x set ports' line(s) in /etc/network/if-pre-up.d/swconfig

auto eth0.101

# dhcp configuration
#iface eth0.101 inet dhcp

# static ip configuration
iface eth0.101 inet static
        address    # (not my actual IP, but you get the idea)
#        gateway

auto wlan0
iface wlan0 inet dhcp
        wpa-ssid <ISP's SSID>
        wpa-psk  <ISP's password>

/etc/dnsmasq.conf is entirely commented out except for this at the bottom:

# eth0.x matches the 'vlan x set ports' line(s) in /etc/network/if-pre-up.d/swconfig


# normal DHCP


# special, need to be found easily

# Static1 (by MAC address instead of hostname, so that a replacement can exist simultaneously for a while)

# Static2 (by MAC address instead of hostname, so that a replacement can exist simultaneously for a while)

# Static3 (by MAC address instead of hostname, so that a replacement can exist simultaneously for a while)

/root/Scripts/Startup-Network.sh runs on startup, ultimately from /etc/rc.local:

# Match settings in /etc/network/interfaces


# Actual work

echo "1" > /proc/sys/net/ipv4/ip_forward

iptables --table nat --append POSTROUTING --out-interface $IFACE_WAN -j MASQUERADE
iptables --append FORWARD --in-interface $IFACE_LAN -j ACCEPT
  • My guess why you didn't get any reply: your title says bridge (which doesn't work with a Wifi STA/client without reconfiguring the AP and all clients and usually has no support in home grade AP and in clients) but your attempted solution describes routing + NAT. At the same time you might still think you'll be using DHCP from a single system while this would be difficult then. So you should clarify your needs and check xyproblem.info
    – A.B
    Sep 24, 2021 at 7:19
  • @A.B Wow that was timely! I was just about to go digging in my history to add my solution as an answer. And it did turn out to be XY.
    – AaronD
    Sep 24, 2021 at 13:14
  • @A.B And for the terminology, we muggles don't get it. If we knew, then we wouldn't need to ask. That's important to remember. So look past the "wrong" terms, see what's actually being asked, and answer that anyway. In this case, I just wanted a connection from here to there, with a particular starting point that does a few other things but not that.
    – AaronD
    Sep 24, 2021 at 13:17

1 Answer 1


Like a lot of things, this turned out to be an XY problem.

I wanted this, as a minimal change from what I had already:

+-----+     +--------------------+           +---------------------------+           +---------------+
|     |     | ISP's Modem/Router |           | Debian Box with           | <--GbE--- |               |
| ISP | <-- |  (opposite corner  | <--WiFi-- | TWO USB WiFi adapters and | <--GbE--- | Local Network |
|     |     |    of the house)   |           | 8-port GbE switch         | <--WiFi-- |               |
+-----+     +--------------------+           +---------------------------+           +---------------+

But I ended up with this, which is just as good functionally, and pushes the part that I couldn't figure out into an off-the-shelf box that's designed to do exactly that:

+-----+     +--------------------+           +-------------------------------+               +---------------------------+           +---------------+
|     |     | ISP's Modem/Router |           | Raspberry Pi Model A with     |               | Off-the-Shelf WiFi Router | <--GbE--- |               |
| ISP | <-- |  (opposite corner  | <--WiFi-- | USB 2.0 Dock (includes Enet)  | <--100baseT-- | with different subnet     | <--GbE--- | Local Network |
|     |     |    of the house)   |           | and USB WiFi adapter          |               | from ISP's network        | <--WiFi-- |               |
+-----+     +--------------------+           +-------------------------------+               +---------------------------+           +---------------+

I had the Pi A, the Dock, the CanaKit ("Pi official"?) USB WiFi adapter, and the router just sitting around anyway, so it was effectively free. The Pi is even powered by the dock, so that's nice too. I was especially wondering what I was going to do with an underpowered Pi by today's standards, but it seems to do a good job here, with my slow cheap internet.

And now I have the original Debian Box (a Banana Pi R1, or "wannabe router that absolutely isn't") unused and available for something else.

After several unsuccessful tries to make the RasPi into its own router with NAT and DCHP, etc., just to serve the off-the-shelf router as the only client (lots and lots of outdated tutorials to do exactly that, that don't work because RPi OS works differently now; but there's nothing to say that, not even a publishing date), I decided to try an actual bridge. This script "just worked" for that (copied verbatim from that site):

#!/usr/bin/env bash

set -e

[ $EUID -ne 0 ] && echo "run as root" >&2 && exit 1

# You should not need to update anything below this line #

# parprouted  - Proxy ARP IP bridging daemon
# dhcp-helper - DHCP/BOOTP relay agent

apt update && apt install -y parprouted dhcp-helper

systemctl stop dhcp-helper
systemctl enable dhcp-helper

# Enable ipv4 forwarding.
sed -i'' s/#net.ipv4.ip_forward=1/net.ipv4.ip_forward=1/ /etc/sysctl.conf

# Service configuration for standard WiFi connection. Connectivity will
# be lost if the username and password are incorrect.
systemctl restart wpa_supplicant.service

# Enable IP forwarding for wlan0 if it's not already enabled.
grep '^option ip-forwarding 1$' /etc/dhcpcd.conf || printf "option ip-forwarding 1\n" >> /etc/dhcpcd.conf

# Disable dhcpcd control of eth0.
grep '^denyinterfaces eth0$' /etc/dhcpcd.conf || printf "denyinterfaces eth0\n" >> /etc/dhcpcd.conf

# Configure dhcp-helper.
cat > /etc/default/dhcp-helper <<EOF

# Enable avahi reflector if it's not already enabled.
sed -i'' 's/#enable-reflector=no/enable-reflector=yes/' /etc/avahi/avahi-daemon.conf
grep '^enable-reflector=yes$' /etc/avahi/avahi-daemon.conf || {
  printf "something went wrong...\n\n"
  printf "Manually set 'enable-reflector=yes in /etc/avahi/avahi-daemon.conf'\n"

# I have to admit, I do not understand ARP and IP forwarding enough to explain
# exactly what is happening here. I am building off the work of others. In short
# this is a service to forward traffic from WiFi to Ethernet.
cat <<'EOF' >/usr/lib/systemd/system/parprouted.service
Description=proxy arp routing service
Requires=sys-subsystem-net-devices-wlan0.device dhcpcd.service
After=sys-subsystem-net-devices-wlan0.device dhcpcd.service

# Restart until wlan0 gained carrier
# clone the dhcp-allocated IP to eth0 so dhcp-helper will relay for the correct subnet
ExecStartPre=/bin/bash -c '/sbin/ip addr add $(/sbin/ip -4 -br addr show wlan0 | /bin/grep -Po "\\d+\\.\\d+\\.\\d+\\.\\d+")/32 dev eth0'
ExecStartPre=/sbin/ip link set dev eth0 up
ExecStartPre=/sbin/ip link set wlan0 promisc on
ExecStart=-/usr/sbin/parprouted eth0 wlan0
ExecStopPost=/sbin/ip link set wlan0 promisc off
ExecStopPost=/sbin/ip link set dev eth0 down
ExecStopPost=/bin/bash -c '/sbin/ip addr del $(/sbin/ip -4 -br addr show wlan0 | /bin/grep -Po "\\d+\\.\\d+\\.\\d+\\.\\d+")/32 dev eth0'


systemctl daemon-reload
systemctl enable parprouted
systemctl start parprouted dhcp-helper

Do the usual setup for a new Pi, including connecting to the upstream WiFi and fully updating, then run that script as root/sudo, and reboot. Done!

I don't know most of what that does, how, or why; only that it "just works".

The off-the-shelf local router now behaves as if its WAN/Internet port is connected directly to the ISP's WiFi (the Pi in between is completely transparent), and then it does from there what it's designed to do as a WiFi router. I imagine that the ISP's router sees 2 clients on WiFi - the Pi and my router - but I haven't felt the need to check.

Slightly off-topic, but important for someone who wants to replicate my setup:

I also set up a cron job for the Pi to automatically update and reboot once a week, just to get the latest security patches. I don't know what someone might do at that point in the system ("cut the cord" there, at minimum), but I'd rather not find out either. Also for security, I kept SSH disabled, and use the serial console instead, with a USB UART that I also had sitting around, on my administration PC.

The only thing left to do is to set up my GPIO-triggered UPS-shutdown again, as that UPS doesn't have USB but I do have an extra 5V "wall-wart" plugged into the non-UPS power. A series resistor (hopefully) prevents damage, and it actually connects between the Pi's +5V and the GPIO pin (no GND at all), so that "not powered" should float up to the Pi's +3.3V and stay there, leaving 1.7V across the un-powered wall-wart. It would have been better to use a 3V wall-wart, but I didn't have one.

  • Proxy ARP is a method looking like bridging but still doing routing. It just "cheats" on the middle layer: ARP that resolves IP address to Ethernet MAC address. ARP requests from the router always get the same answer: the proxy arp system instead of the system behind, and the proxy system will route (at IP layer) instead of bridging (at Ethernet layer). In addition in this case parprouted also appears to automatically add a route to any node behind, rather than having to add this route (once and for all) manually.
    – A.B
    Sep 24, 2021 at 16:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .