Hi! Thank you a ton for DietPi. It’s a wonderful piece of software! I’m having some troubles configuring it though.
I’m trying to use NanoPi R5S as a smart network switch using its 3 Ethernet ports. I was able to successfully do that on the previous OS installed on it – an OpenWRT derivative. The relevant part of /etc/config/network file looked like this:
config interface 'lan'
option ipv6 'off'
option device 'switch0'
option proto 'dhcp'
config device
option type 'bridge'
option name 'switch0'
list ports 'eth0'
list ports 'eth1'
list ports 'eth2'
option ipv6 '0'
option mtu '1500'
option macaddr '86:5E:CE:F4:81:18'
So I want to link eth0, eth1 and eth2 all into a single bridge. I tried replicating this on DietPi:
This partially works. I’m able to make connections to and from the DietPi host, but the traffic switching part doesn’t seem to be working: From a laptop connected over a wire to the NanoPi, I’m able to ssh into DietPi, but I’m not able to reach either my network router, nor the public internet. Everything works if I bypass the wired connection by using WiFi of course.
My network topology looks like this: OpenWRT router <=Ethernet-cable=> NanoPi <=Ethernet-cable=> laptop
On the DHCP server, I configure DietPi to be assigned IP address 192.168.1.100.
Can anyone recommend what else can I check to make the laptop reach the public internet (I’m not sure if I’m supposed to have 1 or 2 subnets for instance)? Any help appreciated!
And in the screenshot, it shows .100 as gateway/router.
You are telling your laptop, that the gateway/ route to internet is your DietPi device, which is not the case, it’s just another client in the LAN, which is acting like a router.
I think you would need to set gateway/router also to .1 on the laptop. (Or let DHCP all handle this)
(You could establish another subnet via DHCP on your NanoPi, then it would be the gateway of the connected clients. But then you need routing rules to you other subnet, so why fiddle with all that? Let the existing DHCP server handle all that.)
No, the NanoPi is already a part of your existing LAN an also the connected devices will become part of it.
I tried that and generally had problems with picking right IP addresses for the ethX interfaces: I needed to specify either a static one or a DHCP and neither of those makes sense or is necessary for bridging AFAIU (the bridge interface it’s the only one that should have an IP address). The current configuration that I have looks right: the bridge interface is up, it’s the only one that has an IP address, all the ethX interfaces are also up yet they don’t have IP addresses. That’s how it should all looks, so I’m a bit reluctant to touch it
Good point! I changed it and a ping 192.168.1.1 from the laptop still doesn’t reach the router though, indicating that packet switching on the DietPi still isn’t functional.
Thank you, that’s good to hear because it makes the entire setup simpler!
This is expected since nothing is connected to them. It’s like a router, the router itself (bridge) has an IP. The ports do not have an IP, only the devices you connect to this ports.
If you want them as interfaces, you can’t use the bridge mode.
auto eth0
iface eth0 inet manual # Set to "manual" to prevent automatic configuration
auto eth1
iface eth1 inet manual # Set to "manual" to prevent automatic configuration
auto eth2
iface eth2 inet manual # Set to "manual" to prevent automatic configuration
And you can also try to use DHCP on the laptop and check on the router if it assigned an IP to it.
I changed that, did ifdown -a && if up -a, systemctl restart networking.service (for good measure) and there’s no difference – still can’t ping router from the laptop.
If I do tcpdump -i eth1 port 67 or port 68 -e -n -vv on the DietPi, I can see the DHCP requests coming from the laptop.
I have an analogous tcpdump command opened at the same time, but for the eth1 interface on DietPi and it doesn’t show any DHCP requests being forwarded from the laptop to the router.
That leads me to believe the DHCP requests are getting swallowed/not forwarded by NanoPi for some reason.
Found it! Turns out it’s an iptables issue! This one exactly: networking - why linux bridge doesn't work - Super User
After echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables, the laptop got its IP address via DHCP finally and pinging the router started working!
Now the problem is that the setting get reset on reboot even if I put it into /etc/sysctl.conf.
Since setting the requisite kernel parameters at boot time seems to be buggy, I had to resort to create a workaround. I created this systemd init file (/etc/systemd/system/bridge-config.service):
