We recently did a complete home renovation of the groundfloor. Improvements included floorheating, improved insulation and HR++ windows. As a side effect of modern building standards, we have a lot less ’natural ventilation’ now.

This was anticipated and I installed a heat recovery ventilation system in the attic. As I was keen on getting this networked, I bought a box for the system that exposes a LAN port. Only problem: no ethernet in the attic.

I was already browsing the internet for a Wifi<==>Ethernet bridge device, when I was remembered I still had some old unused Raspberry Pis. So I changed my search to “Raspberry network bridge” which yielded tons of very wrong and conflicting information.

Raspberry Pi as a network bridge

Word of warning: this is actually impossible. I spent/wasted some time researching and experimenting. After all, the built in wifi chip does not have hardware support to do Wifi STA - or 4addr/WDS mode (see this thread for details), which is a requirement for setting up a proper bridge. Also, finding another USB wifi adapter which does this would kind of defy the purpose.

What you can of course do is setup a routed WLAN<==>LAN connection and use NAT. Which is what lots of people writing the tutorials wrongly describe when they tell you create a bridge.

Is the difference important? Well yes. A bridge would make the device on the LAN transparently appear on the WLAN network, so you don’t need to do any additional configuration. With a routed connection the device on the LAN is on its own dedicated network, and you have to setup the Pi to forward the traffic you want to the LAN (and vice versa).

Doing it anyway - sunk cost fallacy

I was already committed at this point. So I spent some time getting this setup working anyway, and largely followed this guide to do the basic setup, which involves:

• setting up dhcpcd and dnsmasq to give a static DHCP ip lease (192.168.0.95/24) to the wired device and act as a router
• configuring the OS to allow packet forwarding between the wifi (10.0.21.0/24) and LAN (192.168.0.0/24) network
• setting up iptables to actually forward packets between the interfaces and apply NAT, and making iptables settings persistent across reboots

Then unique to the use case here was that the app does a UDP broadcast (on the Wifi subnet) to find the ventilation system API on port 56747, it then connects to the API through TCP on the same port. So I had to create some additional rules to:

• forward the UDP broadcast to the wired subnet. Usually this is a terrible idea, but I knew in this case there is only a single device connected on the subnet and it stops there
• forward the TCP port

For the UDP broadcast forwarding:

iptables -t mangle -A INPUT -i wlan0 -s 10.0.21.0/24 -d 255.255.255.255 -j TEE --gateway 192.168.0.255
iptables -t mangle -A INPUT -i eth0 -s 192.0.0.0/24 -d 255.255.255.255 -j TEE --gateway 10.0.21.255

After applying you can check if this works with:

tcpdump -i any -n udp port 56747

For the TCP traffic:

iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 56747 -j DNAT --to-destination 192.168.0.95:56747

To be checked with:

tcpdump -i any -n tcp port 56747

Success!