I’m trying my hand at creating a 1 port bridge with an old RPi but I’m not quite there yet, right now I’m dealing with an odd issue that happens on my mac even with the RPi is powered off.
When connecting (clicking online) to the ZT-network in question, I lose all routed traffic. I can still ping my default gateway, but anything beyond returns the following weird message…
64 bytes from 172.217.165.3: icmp_seq=34 ttl=117 time=8.533 ms
64 bytes from 172.217.165.3: icmp_seq=35 ttl=117 time=8.511 ms
64 bytes from 172.217.165.3: icmp_seq=36 ttl=117 time=8.442 ms
64 bytes from 172.217.165.3: icmp_seq=37 ttl=117 time=8.576 ms
64 bytes from 172.217.165.3: icmp_seq=38 ttl=117 time=8.379 ms
ping: sendto: Address family not supported by protocol family
ping: sendto: Address family not supported by protocol family
Request timeout for icmp_seq 39
ping: sendto: Address family not supported by protocol family
Request timeout for icmp_seq 40
ping: sendto: Address family not supported by protocol family
Request timeout for icmp_seq 41
The only way to get my network stack working back to normal after this is to disable the problem ZT-network and physically disconnect/reconnect my ethernet cable (or reboot).
This doesnt happen with another ZT-network that I use normally. The only difference between these two networks is that one member is configured to “Allow Ethernet Bridging” and “Do Not Auto-Assign IPs”, but this issue happens even when that member is powered off.
OK. So Mac is on a different network than what you’re trying to bridge into. Assuming the bridge device on the pi into 192.168.100.0 is configured correctly, this should work fine.
Any chance there are routes being handed out by the LAN the mac is on is stomping on the 192.168.100/0 range? Because that could cause problems. netstat -nr will print your current routing table. If there are conflicting routes then yeah things probably won’t work as expected.
I agree, it’s very odd behaviour. Here’s something, when I turn on that specific network, it seems to steal the ipv4 default gateway and replaces it with the mac address of the ZT tunnel interface assigned to that network…
Before
OK. The bug is your ZeroTier network’s configuration. You have your managed route set to 192.168.196.0/24, but are handing out addresses in the 192.168.100.0/24 range. There is a bug on Mac where this situation does crash your network access.
Remove that managed route from your zerotier network and then set a new one to 192.168.100.0/24
No problem! I see you’ve removed the old managed route. You’ll still need to add the new one. Just put 192.168.100.0/24 in the first field, and leave the 2nd blank and you should be golden.
Something I’m going to try digging into tomorrow is creating a br0:0 sub interface with the ZT-network addressing on it set static while keeping br0 set to DHCP. I still need to create my second bridge which will be 2 ports (still en-route), but the plan is to have a one port bridge device I can drop into any dhcp scope, still manage the device via the ZT network addressing, but have DHCP pass through from the foreign network where 1 one port bridge is, to the dedicated bridge port of the 2 port device.
Probably going to take a lot of trial and error but fingers crossed. Trying to build something that will let me test controller based WiFi access points remotely, and simulate as if they’re connected to the remote switch.
BTW, I’ve been obsessed with this project since someone showed me earlier in the year. This is so freaking cool!!! You and your team should be really proud. The possibilities are endless!