Wireless-to-Ethernet island for RPi cluster: IPv6, NDP proxy, mDNS reflector
vladimir.varank.in
vladimir.varank.in
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 due to chip shortage, it is closer to $30 now - https://www.amazon.com/dp/B073TSK26W
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.
1. https://s3.us-east-2.amazonaws.com/download.gl-inet.com/firm...
With default configs IME one will see some constant traffic to 8.8.8.8. This is from OpenWRT mwan3's default configs. These defaults are left unchanged by GL.inet and probably other routers running OpenWRT. I have never seen anyone complain about this traffic. I doubt this is what is being referred to as "telemetry" in the above comment. Nevertheless, it is constant pinging to Google, OpenDNS or some other third party. In typical Linux fashion, mwan3, a daemon not every user is going to need, is enabled by default anyway.
https://github.com/gl-inet/gli-pub/raw/master/mwan3/files/et...
I played with it some, with two nodes, although there's nobody near me to mesh with unfortunately.
Note that I said most, not all. I had a few Raspberry Pi's, and an old Xbox and 486 PC that I used for old games.
I ended up using DD-WRT in access point mode, and rather than having it run in station mode, it would connect to my phone as a Wi-Fi client, and forward Wi-Fi packets out the Ethernet switch.
It was quite handy, and made the summer much more bearable. As an added bonus, I now keep that router config as a backup. If my actual ISP is ever having an outage, I can reupload that config, and get all of the devices on my network back online, without having to switch them over to Wi-Fi.
I use a ZTE MF820B USB 4G LTE modem as a backup Internet connection. I configured the GL.inet router to talk to the modem on /dev/cdc-wdm0 and added my LTE service provider's APN hostname. With those two settings, it just works. I keep the LTE modem unplugged and on-hand for when my fiber (Webpass) goes down.
GL.inet is based in Hong Kong and is now under the control of the Chinese red party.
ZTE is a Chinese state-owned enterprise, so if CCP-sanctioned action is part of your threat model I'm not sure GL.inet would be the most concerning part of that stack.
1. The ZTE device is on the untrusted side of the network. It carries encrypted OpenVPN packets.
2. The ZTE device does not download new firmware.
3. The ZTE device is not addressable on the public Internet. It participates in the GSM network. It tunnels data between its USB interface and the NAT proxy server (APN) provided by the carrier.
And one point increases the risk: The ZTE device is physically attached to the USB port of the router.
CCP-sanctioned action directed at me is not part of my thread model. I'm more concerned with them breaking the security of the firmware to facilitate monitoring of PRC citizens who use GL.inet devices. There is precedent for this. For example CCP forces everyone in an entire province to install spyware on their phones that logs their activities and communications and transmits them to a central server unencrypted. The data goes over whatever network the user is connected to, with zero privacy or even any protection against MITM.
If GL.inet broke their firmware security, how long would the blackhats use it before the rest of us found out about the problem?
For example: can you run tcpflow on your mini router?
I might be wrong, will look at it longer.
But my initial point, which I should have elaborated on: compiling stuff for openwrt is a gigantic pain in the butt.
I tried to compile tcpflow for OpenWRT, installed a VM with the whole toolchain, messed with it for 4 hours and finally gave up when I realized I would have to also recompile a recent openssl to to get tcpflow to link.
Much better to run a "proper" linux distro on these firewall/routers hardware.
this is just a really narrow gripe, picking on one very tiny small perspective angle. and it doesn't take any responsibility for what it might take to do better. this is extremely cheap talk shade casting. i'm incredibly unimpressed. it reeks of sabotage.
I'd rather run Debian too. but everything about this post stinks of meanspirited senseless misonfo sabotage.
(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
---
[*]: https://en.wikipedia.org/wiki/Prefix_delegation
[*]: https://tools.ietf.org/html/rfc3633
[*]: https://github.com/openwrt/odhcp6c (-P option)
(But it should be a very early thing to try, if it's available everything else becomes much easier.)
I've tried to set up PD but it didn't work, so I've moved on with other options. Now, after you mentioned that, this feels like a good excuse to delve into what exactly didn't work back then.
(This isn't about ISP-provided locked-down routers either, though those are an abomination too IMHO. Regardless of whether the "last" ISP-controlled device is a plastic router in your home or an aggregator somewhere else, it needs to support and offer PD for you...)
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.)
There is also a new standard that covers 4-address frames, 802.11ak; I have no idea how widely that is adopted though — it was only released in 2018[1].
[1] https://standards.ieee.org/news/2018/ieee_802_11ak-2018.html
On a technical/complexity level, IP NAT is much worse because you need to hold much more state, i.e. you need the UDP/TCP flow information to rewrite correctly.
However, MAC NAT is the pinnacle of stupidity for an entirely different reason: there should be no need for it. MAC addresses only have local significance, and while there are some long-term concerns about them running out, there is absolutely enough of them right now. There should simply be no need to do MAC NAT, if only it wasn't for the shortsighted 802.11 design decision to go with 3 addresses in the header.
FWIW, MAC NAT is almost the same thing as a router with ARP/ND proxying turned on, though possibly implemented on a different level. This is the technical reason it's an extremely stupid hack: proxy ND/ARP provides pretty much the same thing, but in a much cleaner way. (The difference is that with proxy ND/ARP, the "router-ish-bridge" assumes ownership of the lower-layer exchanges, i.e. ARP & ND, and just does normal routing with that. MAC NAT, meanwhile, tries to be clever and just forward ARP and ND. Reasons for doing that are ... extremely thin IMHO.)
Thanks for that. Filed away for future use.
I had the same problems with my modem/router, a Fastgate by Fastweb (in .it)
No custom static routes, dns fixed by the provider, no vpn functionalities. Some arbitrary tcp ports can't be forwarded via NAT. TR-069 was up and running, at least in ~2017, and at the same year at CCC in Hamburg (or Leipzig?) there was a nice talk about how good of an attack vector TR-069 is.
All this is quite infuriating, specifically the DNS thing.
I ended up replacing the whole thing with custom equipment (ONT + a Linksys WRT3200ACM running OpenWrt).
But I honestly think that stuff like this should be illegal.
I've been using this setup in my home network for years now (with a dedicated OpenWRT device for each wired "island") and it works great.
Edit: To clarify, yes, this establishes a single broadcast domain. For example, DHCP and ARP requests are propagated through the entire network.
On a side note, I have more trust in documentation that is compliant with the relevant RFCs (i.e., RFC1918, RFC3849, RFC5737, et al).
In my experience, such documentation is much more likely to be "technically correct" and get the small details right.
The article mentioned an ARP relay.
Any recommendations?
It's not ARP relay, it's proxy ARP. That's a builtin feature on the Linux kernel, with 2 distinct modes to configure and enable it. (a) /proc/sys/net/.../proxy_arp, or (b) ip neigh add proxy ...; the latter way is more fine grained while the former is just an interface-wide switch that you flick on.
I see this is your first introduction to the homelab hobby. Welcome!
i don't see your claim about how much storage you have as any sort of technical claim, any proof of anything. i think it's expected that the homelab folk have an interest in going deep, in some areas. if networking isn't your bag, isn't interesting to you, fine. but the size of your storage cluster or how many vm's your running isn't really an interesting counter-claim.
Other people just enjoy the blinkenlights.
You don't have to do that. Mine is a pair of Ryzen 2 white boxes. They are dead silent and don't put out much heat either. All my network gear is fanless too.
I do automation, so I use mine for dev/test against the stuff I am automating. A lot of it could run in the cloud, but that gets expensive real quick. Especially when I am working with a VMware stack.
also within this island latencies will remain low.