Performance Issues with Raspberry Pi 4 & Relayd

Installing and Using OpenWrt Network and Wireless Configuration
1

I am trying to use a Raspberry Pi 4 B running OpenWrt 24.10.0, r28427-6df0e3d02a as a wireless bridge between my primary router (not running OpenWRT) and a few wired-only devices, since I am not able to run a direct wired connection between the router and the network switch. The intended use case is that devices on either side of the bridge be on the same subnet, and all the routing, DHCP, etc. is handled by the primary router/AP.

The network topology looks something like this:

ISP Modem <-Cat5-> Primary Router/AP <-Wifi AC-> Pi <-Cat5-> Gigabit switch <-Cat5-> Client device.

I set up a Relayd bridge between the wired and wireless interfaces of the Pi, following the docs: https://openwrt.org/docs/guide-user/network/wifi/relay_configuration. The wireless radio on the Pi is placed in Client only mode, it is not also acting as a second AP.

I am experiencing similar problems to this older thread, where packets are occasionally dropped by the Relayd bridge: Relayd dropping packets - launching tcpdump solves the issue

As far as I can tell, either all the packets are being forwarded correctly, or all packets are being dropped, and this cuts back and forth seemingly at random. As an example, a ping from a client PC:

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=17.1 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=35.1 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=116 time=26.8 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=116 time=36.6 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=116 time=17.8 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=116 time=28.6 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=116 time=16.0 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=116 time=14.2 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=116 time=14.9 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=116 time=21.0 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=116 time=14.5 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=116 time=15.7 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=116 time=14.9 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=116 time=17.0 ms
64 bytes from 8.8.8.8: icmp_seq=33 ttl=116 time=1013 ms
64 bytes from 8.8.8.8: icmp_seq=34 ttl=116 time=14.9 ms
64 bytes from 8.8.8.8: icmp_seq=35 ttl=116 time=17.9 ms
64 bytes from 8.8.8.8: icmp_seq=36 ttl=116 time=16.7 ms
^C
--- 8.8.8.8 ping statistics ---
36 packets transmitted, 18 received, 50% packet loss, time 35466ms
rtt min/avg/max/mdev = 14.204/75.138/1012.845/227.529 ms

However, there is never any packet loss when performing these pings from the Pi itself (either in LuCi or when connected via SSH). As in the previous thread, launching tcpdump on the wireless interface or putting it into promiscuous mode was able to resolve the problem. However, for reasons that are unclear to me, this has stopped working, and now turning on promiscuous mode causes me to no longer be able to ping anything over the wireless interface, browse the network, etc.

Coinciding with this change to the promiscuous mode fix is a change in how the Pi is mounted, going from an enclosed case to being mounted on a piece of acrylic. I have tried restoring the settings from a backup taken before this change was made, which has not made any difference.

Does anyone have any ideas of what to try, how to configure Relayd, etc.? I am just about at my wits' end here.

2

Why use relayd at all? The linux kernel is able to route packets from one interface to another. Just go with simple packet forwarding as usual.

3

All I found in the OpenWrt documentation to achieve this was Relayd and WDS. The latter doesn't work unless I can configure it exactly the same on both routers, so I used Relayd. If you can point me at documentation for how to set this up (ideally through LuCi), I'd gladly give it a try!

4

https://openwrt.org/docs/guide-user/network/openwrt_as_routerdevice

5

Ah, I understand you now. This does not meet my use case. This produces different subnets on the two sides of the bridge, but I need both sides to be within the same subnet.

6

It doesn't make sense to route a subnet to itself, though.

7

Oh, maybe you want bridge mode? I operate a wifi router this way, its just bridging the LAN network (acquired thorugh DHCP) with the wifi, without running its own DHCP server (or DNS). Perhaps that's what you're looking for? Also possible with stock configuration...

8

Did you read the documentation on the Relayd bridge from the original post?

The use case is replacing a physical ethernet cable from the primary router to the switch with a wireless connection through the pi, then a wired connection from the pi to the switch. Everything should all be on the same network.

9

https://openwrt.org/docs/guide-user/network/wifi/wifiextenders/bridgedap

10

That relayd documentation also says:

Using relayd as instructed in this article isn't guaranteed to work with all Openwrt compatible devices or wifi networks - use only as a last resort.

I fail to see what relayd buys you that simple AP bridging doesn't already get you with tons and tons less complexity and configuratoin.

11

Yes, I am trying to make a bridge. I am following the documentation for how to connect wirelessly to the primary router/AP, not over ethernet; for this the documentation suggests WDS or Relayd. WDS is not supported on my upstream AP, so I am using Relayd.

The page you have linked explicitly states that it requires an upstream wired connection. Perhaps it can be adapted, but that is why I was not originally following that method.

E: After further reading, it appears to be, in general, impossible to bridge a wifi client to another network. Thus the need for some additional pieces such as Relayd. See, for example: WLAN to LAN bridge, no DHCP

12

Oh, you may be right -- i've never tried to bridge an wired link to a wireless link. In some ways that's a bitchy problem -- consider an inbound ARP/DHCP request on the ethernet. This cannot be sent along wifi. We need some sort of NAT/encapsulation. Presumably this is what 'relayd' although I would think kernel NAT + firewall would work too. Others might chime up.

Is it at all possible you could run hardwire ethernet between the primary rounter and your Pi?

A few other random general comments.

Pi's are not great routers for this purpose, in particular, the wifi is quite slow compared to a proper router. I believe there is lots of evidence for this.

You mentioned Cat5 but that's several decade out of date, if you're doing any new wiring, I'd recommend Cat7 or Cat6e if the cat7 size is too large...

13

Yes, I know the pi is not the optimal solution. However, it's hardware that I already have, and it's not intended to be a long-term thing anyway. We're probably moving within the next 6 months. When packets aren't getting dropped, the wifi performance is more than good enough for my use case.

Not really possible to run hardwire ethernet, without being a tripping hazard, unfortunately. Believe me, I would prefer that too! As a minor aside, the only purpose of the pi here is to bridge between wireless and wired connections, if I could get a cable all the way over here, it would go right into the switch and the pi would be gone :slight_smile:

Cat5/e is good enough for gigabit, and that's all any of the decade-old hardware at the pi end of this bridge supports :slight_smile:
Yes, if I was buying any new cables, or doing any long-term runs I'd want something nicer, but for now, the existing cables I've accumulated over the years are good enough for my purposes.

Something I am considering, if I can't get Relayd to work, is putting the two parts of the network on separate subnets, and setting up static routes between the two subnets via the pi and the primary router. This would break some other parts of my network, but the things it breaks would be easier to work around than packet loss. I'll look into this, but am still hoping someone might have a configuration suggestion to make the relay bridge a little smoother.