This seems like a lot of work to avoid having to run a long cable.
Wireless-to-Ethernet island for RPi cluster: IPv6, NDP proxy, mDNS reflector
11–20 of 60 posts
Re: Wireless-to-Ethernet island for RPi cluster: IPv6, NDP proxy, mDNS reflector
#12Re: Wireless-to-Ethernet island for RPi cluster: IPv6, NDP proxy, mDNS reflector
#13Having similar issue myself, I have found simpler and cheaper alternative - $20 Gl.inet mini router [1] that runs OpenWRT, but also has frienly UI where you can turn STA mode, connect it to your wireless network and have wired internet on the ethernet port. I use it for wireless Wake-on-Lan for my homelab PC, integrated with homeassistant and Google Assistant voice command “Hey Google, turn on homelab”. [1] - perhaps…
Those little devices are in high demand. I've been buying them in quantities of 10-at-a-time (Especially when they were cheaper) since they are useful for putting VOIP phones securley behind VPN. I've seen a lot of folks recommend them on HN. They support OpenVPN + Wireguard out of the box and are easy enough for non-techs to reconfigure in the field w/ remote instructions.
Re: Wireless-to-Ethernet island for RPi cluster: IPv6, NDP proxy, mDNS reflector
#14Having similar issue myself, I have found simpler and cheaper alternative - $20 Gl.inet mini router [1] that runs OpenWRT, but also has frienly UI where you can turn STA mode, connect it to your wireless network and have wired internet on the ethernet port. I use it for wireless Wake-on-Lan for my homelab PC, integrated with homeassistant and Google Assistant voice command “Hey Google, turn on homelab”. [1] - perhaps…
Those little devices are in high demand. I've been buying them in quantities of 10-at-a-time (Especially when they were cheaper) since they are useful for putting VOIP phones securley behind VPN. I've seen a lot of folks recommend them on HN. They support OpenVPN + Wireguard out of the box and are easy enough for non-techs to reconfigure in the field w/ remote instructions.
Hence why I love seeing posts like the one's submitted: lessons learned, that we can all possibly use to upgrade ourselves.
It would be nice for mainstream linux (not just openwrt) to grow more user-friendly tooling. I look at opnsense in envy, but I'm not really interest in splitting my expertise, taking on learning FreeBSD too. I know I wouldn't really have to touch the OS much, that opnsense is a pretty complete UI package, but I like to keep a fuller-stack view of things, have some up & down mastery.
Re: Wireless-to-Ethernet island for RPi cluster: IPv6, NDP proxy, mDNS reflector
#15Re: Wireless-to-Ethernet island for RPi cluster: IPv6, NDP proxy, mDNS reflector
#16Re: Wireless-to-Ethernet island for RPi cluster: IPv6, NDP proxy, mDNS reflector
#17Re: Wireless-to-Ethernet island for RPi cluster: IPv6, NDP proxy, mDNS reflector
#18(Or maybe not. Who knows. I feel like the post would've mentioned PD if they tried it.)
Also:
I divided it into a smaller subnet 2001:db8:abc:123:40::/76
Anything on a broadcast/multinode segment that isn't /64 is heresy ;)---
[*]: https://en.wikipedia.org/wiki/Prefix_delegation
[*]: https://tools.ietf.org/html/rfc3633
[*]: https://github.com/openwrt/odhcp6c (-P option)
Re: Wireless-to-Ethernet island for RPi cluster: IPv6, NDP proxy, mDNS reflector
#19Having similar issue myself, I have found simpler and cheaper alternative - $20 Gl.inet mini router [1] that runs OpenWRT, but also has frienly UI where you can turn STA mode, connect it to your wireless network and have wired internet on the ethernet port. I use it for wireless Wake-on-Lan for my homelab PC, integrated with homeassistant and Google Assistant voice command “Hey Google, turn on homelab”. [1] - perhaps…
I played with it some, with two nodes, although there's nobody near me to mesh with unfortunately.
Re: Wireless-to-Ethernet island for RPi cluster: IPv6, NDP proxy, mDNS reflector
#20Out of interest, why didn't you just bridge the two interfaces? Did you want everything on a separate subnet? (maybe I missed that but but you mentioned before how everything used to be directly plugged in anyway)
802.11 has the concept of "transmitter address" and "receiver address" in addition to source and destination. Those are MAC addresses too, but they're relevant for the on-air radio management. Things like RTS, CTS, ACKs, and fancier things like beamforming and sounding. The problem is that the design only includes 3 address fields in on-air frames; the AP can specify separate SA and TA (i.e. send a packet for somebody else, SA=real source, TA=AP MAC, RA=DA=client.) There is no mechanism for the client to do the same thing; that would require 4 address fields.
Coincidentally, 4 address fields is exactly what you get with "WDS" / "Wireless Extender" / ... modes. However, these need to be supported, enabled and configured on both the AP and client. The author of the post seems to have no access to the AP to do so (and the AP possibly doesn't support it anyway.)