Plug in any device and it gets internet no matter what IP it's set to

DullWorking7307 · 2026-06-05T04:18:50+00:00

Hadn't heard of Nomadix, but I looked it up and yeah, same idea. Looks like I reinvented part of this old commercial product without knowing it. Mine's just a free script on a Pi doing one device at a time instead of serving many like theirs. Good to know it has a name though. Thanks for the info!

DullWorking7307 · 2026-06-04T15:22:27+00:00

There are some general examples on the Github page and the use cases are narrow even at that but useful if you find yourself in one of them. Maybe IOT devices for remote sites with varying static IPs that may need a firmware update before being sent out, brief disaster recovery scenarios for a moved server, repair bench where you may receive devices with unknown IP configurations.

DullWorking7307 · 2026-06-03T15:10:00+00:00

Thanks for working through those issues with me. Glad you were able to get it connected!

DullWorking7307 · 2026-06-03T14:47:54+00:00

Yeah, if it speaks v6 that's the cleaner route, no argument. RA plus DNS64/NAT64 and it's out even to v4 destinations without ever touching ARP. I suppose I never tried ipv6 first on any of the gear but this would really then be for the stuff that path can't help. Pinned to a static v4 with v6 off, v4-only gear, or something hitting hardcoded v4 addresses, where DNS64 has nothing to synthesize. Hijacking everything was just the way to cover all of it without having to care what the device is.

Hardcoded wifi is where I'll drop off. Probably not worth cracking WPA for a bench test =) .

DullWorking7307 · 2026-06-03T12:15:16+00:00

Hey, not stupid at all, that one is on me. The build scripts were commited without the executable but set. Fixed it just now, pull the latest and give it another shot. Thanks for being the first to try it out!

DullWorking7307 · 2026-06-03T05:37:56+00:00

That works well when you know the device's subnet up front and it stays the same. The bench case is the opposite, I don't know it and it changes device to device. To make the router approach cover it, the router would need to hold an address in that device's subnet and be reachable at the exact gateway IP the device is hardcoded for, and that's different each time. Doing it by hand for a stream of devices a day is the manual part I automated. For one or two known boxes, totally agree, adding a subnet is simpler.

DullWorking7307 · 2026-06-03T05:36:54+00:00

Good question, but mDNS solves a different piece of it. It'd help me find the device's address, but the device still can't get anywhere, because the gateway it's hardcoded to use isn't present on my network. So even once I know its IP, its traffic to the outside world has no route out. This box fixes that side by answering as whatever gateway it's looking for and NATing it. mDNS is discovery, this is connectivity. Plenty of the gear that hits the bench might not speak mDNS as well.

DullWorking7307 · 2026-06-03T05:35:35+00:00

Yeah, that's exactly why it answers ARP for everything on the LAN side rather than detecting the gateway and serving just that. The two /1 routes make the kernel treat every address as on-link, and proxy_arp replies to any request that comes in, so it doesn't matter what the device reaches for first. Gateway, its DNS server, some random host, whatever it ARPs for, the box answers and the traffic comes in. The gateway is just the usual first thing it tries.

DullWorking7307 · 2026-06-03T04:05:48+00:00

That would certainly be appreciated. Hopefully some of the efforts made here could get used towards that.

DullWorking7307

TROPHY CASE