3

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.

3
  • How long do you mean when you say "long stretch of cable"? Jan 29, 2020 at 18:56
  • About 200 feet.
    – Big Owls
    Jan 29, 2020 at 20:17
  • 1
    200 feet (61 meter) is within the ethernet specification (max. 100 meter) so it should not harm. I will try to reproduce your problems but haven't an ethernet cable of 200 feet ;-( Do you have an idea what "poor traffic through eth0" is besides slow speed? High error correction and/or retries? Poor signals on the wires? Do you tried to check with iperf?
    – Ingo
    Feb 5, 2020 at 12:07

1 Answer 1

0

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.

5
  • Ingo, thank you for taking the time to answer this question and set up a test. I am very appreciative of that level of assistance. Also, please bear with me on my follow-up to this, as network engineering is NOT my forte. Regarding the ethernet cable; what I meant to communicate was that we are physically patching the primary hotspot to the device, so merely just instead attempting to communicate via the physical ethernet port (eth0) instead of through our WiFi USB adapter. This will be a common practice when we can't get signal in the field. The device hates this, and has no redundancy...
    – Big Owls
    Feb 6, 2020 at 5:05
  • ... in order to tell it to start "listening" on the physical port instead of wirelessly over the USB/WIFI adapter. We must reboot the Pi to get it to ignore wireless. On a side note, when I buy a "industrial wireless bridge" such as an Antaira AMS 7131-AC-T, I can ping the (static ip) device without the primary hotspot being up and the WiFi on the bridge being completely disconnected. Perhaps this is due to some of the options we choose or how they are configured out of the box (I suspect this may be the difference between a "multi-client bridge" and a "fully transparent bridge."
    – Big Owls
    Feb 6, 2020 at 5:07
  • When we couldn't get this working reliably on the Pi, we bought that AMS 7131-AC-T, and sure enough, their engineers say it does not offer WLAN/LAN redundancy to the side before the bridge. Wireless bridging works great until we attempt to plug an Ethernet cable directly from the primary hotspot LAN to the bridged network. I don't think that's unreasonable because after all, it doesn't know what interface to physially use at that point! However it never just "picks" one. At that point, when the Ethernet cable is plugged in, we experience complete failure.
    – Big Owls
    Feb 6, 2020 at 5:14
  • The length of the Ethernet cable doesn't matter to me, perhaps I emphasized that poorly. This could happen on a 5 foot Ethernet cable. I more meant the behavior.
    – Big Owls
    Feb 6, 2020 at 5:20
  • @user8585939 I think the AMS 7131-AC-T (don't know it) is working as real OSI layer 2 bridge. That is a complete different configuration than proxy arp and explains the differences. It seems I'm a bit confused with the word "device" you are using. So far I have meant that a device only have a wired port and is connected to the RasPi that has eth0 and wlan0. And yes, with the static configuration you have to reboot the RasPi to discover interface changes. That is what static mean and is by definition as explained in the prefix.
    – Ingo
    Feb 6, 2020 at 8:39

You must log in to answer this question.

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