I like Will Haley's setup better though, because it keeps everything in the same subnet.
The slowdown from the bridge is negligible, in my experience. After running 10 trials, I found that:
* median ping was 2.4% higher on the bridged pi
* median download speed was 3.6% slower on the bridged pi
* median upload speed was 0.1% slower on the bridged pi
More details about my setup and how I performed this speedtest: https://github.com/dasl-/pitools/tree/main/wifi-ethernet-bri...
Pings are best compared in absolute terms as the latency of the Pi would be additive, not multiplicative.
I looked at your results and the Pi appears to add 0.6ms, which is indeed very negligible!
Thanks for sharing detailed results
I'd be very curious of the Wifi & Ethernet can both operate at link saturation speeds so 1Gbit on the Ethernet. While the 4B has AC WiFi, just quick search shows it can only hit ~120Mbps with maybe 200Mbps maybe being achievable with some tweaks. At best it can do 480Mbps.
Considering the 4B costs ~$80, you would be better off buying a dedicated bridge. I think any Ubiquity AP can be used as a bridge for example. An old router would also work. I have a hard time thinking of a situation where you would want a 1-many bridge but don't need decent bandwidth. i.e most situations where minimal throughput is OK means you probably only need 1 raspberry pi for the task anyway.
Still it's a pretty decent project and good intro to networking.
I used to have such a bridge (OpenWrt on Netgear WNDR3800 hardware) Velcro'd to the underside of a TV cart, so that an appliance on the cart that only had Ethernet and 2.4 GHz WiFi built-in could do a more reliable 5 GHz across the room.
Edit: From what I can tell, support for WDS depends on the WiFi chipset. "iw list" must explicitly include "WDS" as a "supported interface mode". At least the Broadcom chipset on the Raspberry Pi Zero does not support this, but, for example, the Atheros chipsets used in a variety of routers do.
It also make 2nd AP connected wireless to first one for extending WiFi coverage. Not a perfect setup but works few months without issues.
Would this be easy to combine with openvpn? Basically what I'd like is to hook (say) my Apple TV into my pi by ethernet and then use the pi's wifi to connect to my router. Finally I'd like to be able to connect the pi to a VPN and have the Apple TV transparently use that connection. Is this straight-forward to achieve?
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -A FORWARD -i eth0 -o wlan0 -j ACCEPT
iptables -A FORWARD -i wlan0 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
etc. I'd also second a recommendation of wireguard over OpenVPN - it's far simpler to configure too.
Performance is probably the only reason you'd favor bridging over routing. A segmented network is a safer network.
Your issue might be different but I suggest taking a pcap to make sure your assumptions about what is answering a given DNS query are true.
So, you're not alone, me too.
># I have to admit, I do not understand ARP and IP forwarding enough to explain exactly what is happening here.
Why not tell me to create the necessary files, with some article content around what we're doing and why?
As an article this doesn't seem to offer anything more than a suggestively named GitHub repository with a small readme.
I should note that while the onboard WiFi is 802.11ac, I've never seen it get more than 60-70 Mbps in my own testing (in a variety of network environments), so if you want more speed, you might want to get an old n or ac router and flash it with OpenWRT instead.
I live in an apartment though, I wouldn't trust it to cover much of a house. Also it's struggling with keeping 10+ devices connected. But speed is not bad! I prefer it over the retail routers I got hooked up as access points.
You (and others in these comments) have suggested using OpenWRT as an alternative. I suppose one advantage of the approach outlined in the submitted article is that you can still use the pi for other tasks using the normal raspberry pi OS, instead of installing the OpenWRT OS.
Then you can do power and data over the single USB port.
For those curious, find the `/etc/network/interfaces` and `/etc/hostapd.conf` here: (Grep for `br0` in both)
Can anyone elaborate on why the authors way of implementation is superior to that? He/she's using `parprouted` and `dhcp-helper`.
From the parprouted man page:
> parprouted is a daemon for transparent IP (Layer 3) proxy ARP bridging. Unlike standard bridging, proxy ARP bridging allows to bridge Ethernet networks behind wireless nodes. Normal L2 bridging does not work between wireless nodes because wireless does not know about MAC addresses used in the wired Ethernet networks. Also this daemon is useful for making transparent firewalls.
When wireless nodes don't know about mac addresses, why is my wireless interface on `ip a` showing a mac address then?
(This is avoided with WDS, but that requires the AP to cooperate)
One such example is Ethernet multicast.
brctl addbr br0
brctl addif br0 eth1
brctl addif br0 wlan1
ip link set br0 up
I frequently use RPi as a programmable soft switch, plugging in four USB-ethernet dongles. On my Pi it splits the USB bandwidth, but it's still very useful.
TL;DR: Some routers don't like it, so layer 3 might work better
I guess the main issue is that Ethernet ports are going the way of the dodo.
So yes, there's been a market for this on lots of consumer devices for quite some time. Most people just don't know it exists.
Edited my comment a bit as doing a bit more research its not quite as common as I believed but does exist on a number of consumer devices. I still stand by my point that most people don't know about this feature of their hardware when present as most people don't understand the difference between a router and an access point.
I use an intel nuc i3-7100U as a wifi to ethernet bridge for a Windows 10 machine (HP Elitedesk 8300 Core i5-3470). The nuc also serves as a htpc running libreelec.
Why? I tried 4 different USB WiFi dongles with different chipsets spanning ~11 years and each one would end up being the cause of intermittent blue screen of death. The dump file backtrace repeatedly pointed to the usb-wifi stack.
parprouted & dhcp-helper are secret gems!