Raspberry Pi WiFi to ethernet bridge(willhaley.com)
willhaley.com
Raspberry Pi WiFi to ethernet bridge
https://willhaley.com/blog/raspberry-pi-wifi-ethernet-bridge/
66 comments
On wired ethernet, a packet contains the MAC address of the destination host. Switches across the network keep track of which port a given MAC address is associated with and forward it appropriately. Wifi doesn't have the same concept - the only destination MAC address in a standard 802.11 packet is that of the destination Wifi station. So, if you have a device on Wifi with several wired devices behind it, and you want to send a packet to one of those wired devices, you can't stick the wired device's MAC address in there - it needs to be the address of the one with Wifi. So how does that Wifi node know which wired device to forward the packet to?
(This is avoided with WDS, but that requires the AP to cooperate)
(This is avoided with WDS, but that requires the AP to cooperate)
The 802.11 header has 4 MAC addresses: Source Address (SA), Destination Address (DA), Transmitter Address (TA), Receiver Address (RA). The TA and RA are those of the Wifi station and SA and DA are the Ethernet addresses. This allows bridging Ethernet and Wifi interfaces and it is how many (most?) Linux-based Wifi routers work.
Yes, if you're using WDS, otherwise you only have three addresses used. Since you need the transmitting device to populate the DA, you can't just turn on bridging on a client and have everything work - you need both ends of the link to be involved.
Yes, for a wifi client (like in the article) you're right. manuel_w was talking about bridging on the AP and for that you do just enable bridging and it works fine.
It seems like making an ethernet bridge shouldn't be hard; off the top of my head, if we wanted to bridge eth1 to wlan1 it would be something like:
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.
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.
I wondered too, and found this from the debian docs: https://wiki.debian.org/BridgeNetworkConnectionsProxyArp
TL;DR: Some routers don't like it, so layer 3 might work better
TL;DR: Some routers don't like it, so layer 3 might work better
I used an old Airport Extreme I had sitting around to set up a bridge network recently. In doing so I realized those routers can become Time Machine devices simply by plugging a HD into the back USB port.
I’m trying to understand why this is better than a usb WiFi dongle, and coming up empty. Anyone have an idea?
No driver, processing or configuration is required on the bridged machine. This is good for devices you can't install a driver on (smart TVs, networked printers, any other appliance). No configuration also means you don't have to risk your wifi password being stored/shared with third parties.
Gotcha. These are actual great use cases. I wonder if there’s a market to make an actual dedicated consumer device.
I guess the main issue is that Ethernet ports are going the way of the dodo.
I guess the main issue is that Ethernet ports are going the way of the dodo.
~~Lots of~~ Some* wireless access points support operating in either a client or bridged mode. Client mode usually implies (not always) it NAT'ing the WiFi connection similar to what a home router might do with your internet connection. Sometimes client mode is synonymous to bridging which is what this Pi is doing.
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.
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.
You have a printer thats no where near a wired port.
Your USB stick isnt going to work in this case.
Similar case, I did this with a home security system when I moved in. It's old but has a web interface for viewing some alarm data, and can technically reach out to the web for sending alarms. The panel is in a closet so the Pi worked perfectly.
n=1
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.
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.
I did this when I didn't have a dongle but did have a Raspberry Pi on hand.
Wireless bridges can be useful when you're trying to connect several devices through a single wireless link. Think about potentially having a whole room of devices all with a perfectly placed antenna instead of half a dozen antennas placed in compromised locations.
I have an ASUS RT-N16 router from about 2013 that has been doing this duty since about 2015. It's running the old Toastman build of TomatoUSB. It's only WiFi G (not N) so throughput wasn't so hot. But it really served me well until I decommissioned it last week.
I'm curious if this would work on a network with a captive portal enabled. It would be quite useful for connecting smart devices by hooking up a router on the raspberry's ethernet port.
Any way to do a Bluetooth proxy to use a remote Pi to relay Bluetooth to another network connected Pi?
This is amazing! was looking for this exact solution :D
Raspberry Pi 4 Model B still looks too bloated to me. I'm sure a more lightweight embedded option is possible.
A couple of months ago, another setup for a wifi to ethernet bridge was posted here: https://news.ycombinator.com/item?id=26940521
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...
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...
> * median ping was 2.4% higher on the bridged pi
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
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
Even download & upload should be posted as bride/no-bridge speeds. Assuming they meant internet upload/download then it makes a big difference if you are testing using a 50Mbps internet connection or 500Mbps.
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'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.
DD-WRT has support for Rpi now though.
You can also do this with an old OpenWrt router, which also gets you a management interface and a gigabit Ethernet switch as part of the plastic box.
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.
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.
I'm bridging for an IPTV box now TP-Link Archer C20i that cots me $10.
It also make 2nd AP connected wireless to first one for extending WiFi coverage. Not a perfect setup but works few months without issues.
It also make 2nd AP connected wireless to first one for extending WiFi coverage. Not a perfect setup but works few months without issues.
DD-WRT also supports this (wifi mode: "client")
And probably also a much better antenna.
I agree that this is a much better option. Also, if you use two OpenWrt devices, you can enable WDS mode to build a true layer 2 bridge. That is, you won't need Proxy ARP and DHCP relay. For example, DHCP and IPv6 will just work out of the box.
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.
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.
I might as well just dump this question in this thread:
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?
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?
Yep, rather straight-forward. Little bit of iptables forwarding and you're all set:
refs: [0]https://www.wireguard.com/
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
refs: [0]https://www.wireguard.com/
May I ask where I might start learning things like this?
The tutorials provided by VPS providers like Digital Ocean are a pretty good way to learn how to setup a VPN or any other common webservice yourself. They have a pretty well maintained library:
https://www.digitalocean.com/community/tutorials/how-to-crea...
etc. I'd also second a recommendation of wireguard over OpenVPN - it's far simpler to configure too.
https://www.digitalocean.com/community/tutorials/how-to-crea...
etc. I'd also second a recommendation of wireguard over OpenVPN - it's far simpler to configure too.
Stand up a few useful services around the home and harden them. Stuff like Plex/Emby, Paperless-ng, *arr's, etc. Self hosting is addicting and one of the best teachers.
Great thanks for the info!
Yes, but a better approach would be to enable forwarding on the pi and using the pi as a gateway.
Performance is probably the only reason you'd favor bridging over routing. A segmented network is a safer network.
Performance is probably the only reason you'd favor bridging over routing. A segmented network is a safer network.
Some routers support acting as a transparent vpn client as well, particularly those with open linux firmwares.
Has anyone tried this and successfully blocked ads from services like YouTube and Hulu? uBlock works on my computer but I've always had a hard time with pihole. It'll work for like a day then go back to serving ads.
Make sure nothing is changing your DNS. You may need to set your router to push the pihole as your DNS and tell any programs to use system DNS.
I've checked that my router continues to point to the pihole (no fallbacks, though I've tried with fallbacks and no difference). I also setup the pihole with cloudflare. I'm just always confused because it seems like some people have absolutely no problem and there's others in my camp and the former just stop after "just follow the directions." I even remember the LTT video mentioned this specific problem.
I went down a similar rabbit hole recently with unbound as a caching resolver, where it appeared to work on my real computers but didn't on phones. I took a pcap and found that my Android 10+ devices were refusing to use the good-old port 53 DNS my unbound jail was serving because it wasn't DoT. Once I set up unbound with real certs _and_ set it as each device's "Private DNS", it worked as expected.
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.
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.
Oh I didn't realise anyone had that work. I just assumed it wasn't possible (i.e. ads served from same domain as content) and uBO was able to do it by 'content blocking' (i.e. DOM manipulation) rather than XHR blocking.
So, you're not alone, me too.
So, you're not alone, me too.
Ah yes, network configuration by way of executing a random bash script from a blog. With tasty morsels like:
># I have to admit, I do not understand ARP and IP forwarding enough to explain exactly what is happening here.
># I have to admit, I do not understand ARP and IP forwarding enough to explain exactly what is happening here.
I mean, the number of people on this site who could intelligently explain ARP and IP forwarding in detail is probably 10x higher than in the general population—and that percentage here is probably in the low single digits.
I think you mean the proportion is higher here, unless you mean that >90% of people who could intelligently explain ARP and IP forwarding are HN posters.
Yes, I read it and found the overall approach a bit strange. I wondered why they weren't just using a normal bridge interface, like https://unix.stackexchange.com/questions/363332/how-do-i-con...
Yeah, I don't like the style of this 'first, download this script; then, execute it'.. and it creates/overwrites files.
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.
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 did something similar to bring a legacy cable-only printer online for wifi clients where there were no cabled uplink. Worked well. Tried to add airprint with cups as well but that was hit&miss.
parprouted & dhcp-helper are secret gems!
parprouted & dhcp-helper are secret gems!
This should work with ZeroTier's Ethernet bridging capability. You could have a WiFi network that bridged right into a virtual Ethernet network that spanned sites.
This can also be set up graphically using OpenWRT (which is a lighter-weight OS if you just want to do some networking and not use the Pi for anything else.
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 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.
What operating frequency did you use? I got the RPi4 mentioned in the article and I run OpenWrt on it as my home router. I got it configured to AC mode, 40 MHz width, and I easily hit 100Mbps.
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.
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.
Yes, those speeds are roughly consistent with what I got in my speed tests here :)
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.
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.
Yeah, this. I've used Ethernet bridge on old Netgear 802.11n routers, and it's quite fast.
Is the kernel's proxy ARP support not enough to handle everything? What is the reason to have parprouted?
Is this a "true" bridge (i.e. every Ethernet segment coming in on one end is transformed into an appropriate 802.11 frame and vice versa)? If not, is that possible using an RPi?
Not every IEEE 802.1 Ethernet frame can be converted to an IEEE 802.11 WiFi frame. To do that you would need some type of tunnel to the Ethernet fabric.
No tunnel is needed. Just use a bridge interface.
Since not all IEEE 802.1 Ethernet frames can be converted to IEEE 802.11 frames using the Linux bridging infrastructure isn't sufficient (even though it can do fancy things like bridge non-Ethernet and Ethernet interfaces; Like bridging PPP interfaces and IEEE 802.1 Interfaces). You genuinely need a tunnel if you want support all Ethernet functionality.
I'm highly skeptical that bridging is insufficient for most use cases. After all, most Linux-based access points are using standard bridging.
Indeed that is true that for most cases WiFi can do the things users want. My note was that not everything you can do with Ethernet frames can be converted to WiFi frames.
One such example is Ethernet multicast.
One such example is Ethernet multicast.
I've thought of doing something similar, but exposing it as a USB-Ethernet adapter instead. The Pi 4 (and Pi Zero W) support USB OTG. It looks simple enough with a single command with Linux USB gadget to create the network interface usb0.
Then you can do power and data over the single USB port.
Then you can do power and data over the single USB port.
This is fun! I wanted to do something similar but ended up buying two TP-Link AC routers with WDS for ~100$. Setup was simple and I get the full 400Mbps download speed from the paired router (the one that isn't connected to WAN).
I was using my Raspberry Pi 4 as a WiFi bridge for a "temporary" networking solution after I moved house. I ended up running it that way for over a year and it worked pretty flawlessly. Only problem was that it didn't get anywhere near my full WiFi speed.
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?