Hey, everybody - most of the guides that I've seen for running OpenWRT on a Raspberry Pi talk about using it as a WiFi router. That is, the ethernet port plugs into a WAN connection, and the Pi sets up a WiFi AP for other devices to connect to.
I'd like to set mine up in the opposite direction: connecting to WiFi to access the WAN, and using that connection to provide networking to devices that are plugged into its ethernet LAN. (I'm trying to set up a little Pi cluster on its own LAN to play with Kubernetes, using a small switch that gets its WAN connection from the Pi's WiFi.)
I'm about halfway there - I've got the WiFi configured as a client, I can access the web UI through that interface, and when no other interfaces are active, the OpenWRT Pi has internet access through its WiFi.
When I enable the ethernet bridge with a static IP, however, the Pi loses internet access. I think that it is probably trying to use the ethernet LAN as a WAN connection, and I haven't been able to find a way to configure it to use its WiFi as the primary outgoing link.
I'm very new to OpenWRT and low-level network configuration, so it's definitely possible that I'm missing something. I'd appreciate any advice you all could offer!
Do they? That's a horrible idea as the WiFi on a Pi is terrible. It really should only be used as a last resort!
But anyway, it is likely to just be a config issue so let's see 'em. Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
Yeah, I figure I probably don't have it configured quite right. Thanks!
root@OpenWrt:~# ubus call system board
{
"kernel": "5.15.167",
"hostname": "OpenWrt",
"system": "ARMv8 Processor rev 4",
"model": "Raspberry Pi 3 Model B Plus Rev 1.3",
"board_name": "raspberrypi,3-model-b-plus",
"rootfs_type": "ext4",
"release": {
"distribution": "OpenWrt",
"version": "23.05.5",
"revision": "r24106-10cc5fcd00",
"target": "bcm27xx/bcm2710",
"description": "OpenWrt 23.05.5 r24106-10cc5fcd00"
}
}
root@OpenWrt:~# cat /etc/config/network
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix '[ipv6 prefix]'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth0'
config interface 'wwan'
option proto 'dhcp'
option device 'radio0.network1'
config interface 'bridge'
option proto 'static'
option device 'br-lan'
option ipaddr '192.168.8.1'
option gateway '192.168.8.2'
option force_link '0'
config device
option name 'phy0-sta0'
option promisc '1'
config rule
option in 'wwan'
option src '0.0.0.0/0'
option out 'wwan'
option dest '0.0.0.0/0'
config rule6
option in 'wwan'
option src '::/0'
option out 'wwan'
option dest '::/0'
config route
option interface 'wwan'
option target '0.0.0.0/0'
config route6
option interface 'wwan'
option target '::/0'
192.168.8.0/24 shouldn't conflict with my network, and the routes / rules were an attempt to force everything through the wifi which doesn't seem to have worked.
This point was adressed already by @krazeh
The PI's Wi Fi hardware is not suitable for an AP, as well as carrying trafic of multiple clients as your use case suggests.
Network performance will be unreliable at best.
The PI is a suitable WIRED router, not a wireless one. You should reconsider your network topology.
Pi3 isn’t really optimal for network work at all. It has no Gbit connection and no USB3 and the USB2 and Ethernet connector is shared bus with about 200Mbps max on the ethernet connector.
So full duplex to a switch to grow the port numbers isn’t giving much bandwidth ether.
Thanks for the replies - yeah, I know it's not ideal but I had the board sitting around and I'm not too worried about performance.
This is more of an educational toy project, I'm trying to bridge a wifi connection to a virtual LAN over a PoE switch to minimize wiring and keep the hardware simple. It will be serving as a wired router, though - just getting its internet access from an existing WiFi AP.
Anyways, I did get the router's connectivity working without disabling every other interface, using relayd and luci-proto-relay. But I'm bridging the WiFi to the eth0 interface, configured with a static IP; I've disabled the default br-lan bridge.
Unfortunately, it looks like enabling DHCP on the ethernet interface brings the device offline again, and I'll probably need to have DHCP enabled if I want it to assign IP addresses to new client devices which get plugged into its wired LAN.
A normal home router usually have a trunk port between the switch and cpu so the meaningful thing to do if you have a vlan capable switch is to connect wan to the switch and run all vlan in one ethernet vlan trunk between the switch and pi.
But that solution will with full duplex give max bandwith of about half pi ethernet speed so that gives about 100Mbps.
Thank you! Unfortunately, I have a dumb switch (trying to do this on the cheap,) and it's a very long distance from the actual router to where my setup is.
Plus, it'd be nice to learn how to set up an "island" network which only has access to power and a wifi signal in OpenWRT, even if the Pi isn't ideal hardware for that kind of topology.
I think I might have things working - too soon to say, because I don't have any downstream devices plugged into the switch yet, but I have connectivity with DHCP enabled on the bridged ethernet interface.
I ended up loosely following this guide, and setting the ethernet interface's IPv4 gateway and DNS server to the WiFi client's IP address:
Yep, I finally got around to plugging a client device into the switch, and following the "relay configuration" tutorial seems to have worked!
The second board gets a DHCP lease from the Pi router, and its network requests get relayed over the OpenWRT WiFi interface.
I think the only differences are that I used the LAN connection as the downstream half of the bridge instead of a second wireless radio, and I gave the bridge interface its own static IP on the wired LAN's subnet.
