Question on L3 'pseudo-bridge' implementation for Raspberry Pi 4B

Question

We have implemented, on the Raspberry Pi 4B, a L3 "pseudo-bridge" using Proxy ARP (parprouted) under the static configuration guidance given by user Ingo found here to provide a local database to our field systems that will synchronize with the outside world. Our systems run Buster. The system seems to be working well, but I want to make sure that we're using it as intended by describing some of the nuances/issues we seem to be having. I'll start by describing our topology:

                          ┌─proxy arp─┐     UPLINK
                wired     V           V      wifi            wan
a few hosts <─────────> (eth0)RPi(wlan0) <~.~.~.~.> hotspot <---> INTERNET
     \                           \
(STATIC IP for easy id'ing)   (STATIC IP for easy id'ing)

I will also mention we use multiple RPi's that will reach out to this hotspot for outside connectivity. Each RPi serves some equipment that needs to get linked up, but the equipment only has wired capability. This is not the only reason we do it, each piece of equipment is very far away from the hotspot and we utilize 6dBi gain omnidirectional antennas going into our ext-antenna WiFi-to-USB dongles.

The issues we're having are 2 in particular:

1.) If the hotspot is not up, we can't ping the Raspberry Pi.

2.) IF we run a long stretch of cable to the RPi as a hard-wired contingency plan due to poor WiFi reception, the RPi rarely handles this smoothly, often resulting in poor traffic through eth0 while it still attempts to link through wlan0, despite the poor connection. I realize the bridge ARP functionality makes these one in the same, so perhaps that could complicate the "fail-over" behavior of the NICs.

I suspect one of the issues might be in the way our Gateway or DNS settings are configuring within /etc/systemd/network/08-wlan0.network where we specify our provisioning script as follows:

cat > /etc/systemd/network/08-wlan0.network <<EOF
[Match]
Name=wlan0
[Network]
Address=192.168.100.200/16
Gateway=192.168.0.1
DNS=8.8.8.8
IPForward=yes
EOF

If such a gateway is included, in this case our Hotspot, would this pose issues downing the RPi when the Hotspot is down?

I also read somewhere that if Promiscuous mode is not enabled, then the pseudo-bridge will not function correctly. Should we be adding the following on Buster?

ip link set wlan0 promisc on

Thanks for your help.

Answer 1

I have tested the setup again to verify your issues but of course with current operating system version and hardware. These are Raspbian Buster on a Raspberry Pi 4B. The referenced setup is Workaround for a wifi bridge on a Raspberry Pi with proxy arp. For the General Setup there I have the classic name resolver and the avahi daemon deinstalled and systemd-reolved enabled because I believe it fits better to systemd-networkd. You should have a look at it.

1.) If the hotspot is not up, we can't ping the Raspberry Pi.

This is by intention. The RasPi should be transparent to its connected devices like a real bridge. They should see the hotspot and not the RasPi. Its ip address is only to manage proxy arp on OSI layer 3 and meaningless for the connected devices. If you look at eth0 and wlan0 they both have the same ip address. This cannot work on a normal network device. So if the hotspot is down then the RasPis interfaces are also down because they work like on interface.

2.) IF we run a long stretch of cable to the RPi [..] the RPi rarely handles this smoothly, often resulting in poor traffic through eth0 while it still attempts to link through wlan0, despite the poor connection.

This is a point I can't really verify because I don't have a long distance ethernet cable but with a length within the ethernet specification it should do without problems. If not then it may be more a problem of the cable itself, shielding, contacts and so on. To get an idea I have made a bandwidth test on my not very performant test net with old RasPis. On a wired connected device behind the hotspot I run iperf --server. On a device connected to eth0 on the RasPi I run:

rpi ~$ iperf --time 60 --client 192.168.50.174
------------------------------------------------------------
Client connecting to 192.168.50.174, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[  3] local 192.168.50.3 port 43434 connected with 192.168.50.174 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.9 sec   286 MBytes  39.4 Mbits/sec

The interface eth0 on the RasPi doesn't show any errors:

rpi ~$ ip -statistics link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether dc:a6:32:01:db:ec brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast
    510673218  338397   0       0       0       155
    TX: bytes  packets  errors  dropped carrier collsns
    2690947    35971    0       0       0       0

On wlan0 I find a similar clean result without errors.

Your setting of a static Address, Gateway and DNS in /etc/systemd/network/08-wlan0.network is correct. I have tested with a similar configuration and it has nothing to do with downing the RPi when the Hotspot is down (see point 1.) above).

Promiscuous mode is needed and it is set in the parprouted.service Unit file. There you will find

ExecStartPre=/sbin/ip link set wlan0 promisc on
# and
ExecStopPost=/sbin/ip link set wlan0 promisc off

so there is no need to do it again.