OpenWrt as DHCP client, fallback ip for accessing device?

If you have OpenWrt as a dumb AP client using DHCP, is there any option to provide a usable fallback ip address to acces the device in case the server is not available or because of some misconfiguration the OpenWrt dhcp client is unable to negotiate a lease, and not end up with a ip-less device that you cant access?

I was thinking of putting an alias for dhcp client interface with an static ip address, but this should be in a different subnet than the main dhcp subnet range, and thus I would not be able to access the device without setting up a static interface on the other end.

I was thinking of something along the lines of this:
dhcpcd - ArchWiki (archlinux.org)
were if the dhcp lease is not obtained after some timeout the client automatically configures some sort of backup ip/gw/dns for the machine.

It's a bit contradictory though isn't it? What if you have five dumb APs and the main, DHCP providing one goes down. What backup IP addresses would you give each of the five to avoid collisions? Once you've worked it out why not make them static all the time anyway?

As a backup strategy you could look at something like setting up Windows Internet Connection Sharing when you need it, which will create a DHCP service. Plug the device into it and you should be able to reach it to configure it. Or a similar service you can start that already has a MAC to IP assignment so that you know which IP address the device will end up with (EDIT: Which could be a spare OpenWRT router that you plug in when needed :slight_smile: ).

2 Likes

You can have a "poor man's redundant DHCP" by setting up 2 devices with a DHCP scope but different lease ranges. For example DHCP server 1 hands out 192.168.123.10 through 50 and DHCP server 2 hands out 192.168.123.60 through 100.

Thanks for the backup strategies, I like the spare OpenWrt router idea :+1:

If the dump APs have static leases, maybe I can give them the same ip they would get from the DHCP server if it were available, would that cause collisions, if for example the DHCP returns after some time? Or maybe give them ips outside of the DHCP range?

I assume that dhcpcd fallback profile feature doesnt exist in udhcpc right?

I'm not sure if that would help if there is a problem with the DHCP client on the dump APs, specially if the are connected just over a wireless link to the DHCP server.
I'm asking about how to access the dumb ap OpenWrt devices in case there are problems with themselves obtaining a dhcp lease, more like a failsafe than a redundant setup.

Right now I'm just using one of the switch port vlans with a static ip as failsafe, I was looking for a more elegant solution that could coexist with dhcp client without taking a physical port for itself.

Yes.

Yes.

Not really.

Yes, this is what I would suggest.

I use 192.168.1.X for my network where...
X= 1 to 19 for network devices;
X = 20 to 50 for things like printers, etc that I want to be able to access with know IP;
X = 100 to 199 for DHCP to share out.

Is there a reason you want the network device to have a variable IP address? You and other devices will have trouble finding it unless you use internal DNS where the new IP address is registered. Is it an example of many similar devices that you just want to plug in to do things as a client device (eg BitCoin mining that it then sends to a known "upstream" server)?

Create a new interface with static ip with a different network address than your lan. Make sure it is bridged with eth0, firewall on the lan side and no dhcp server. You can reach the router through the static ip. I did this with my router but I think it should work with a dumb ap.

1 Like

Unless you're setting up an enterprise environment and know what you're doing™, multiple DHCP servers in your LAN are a recipe for disaster and severe pains. In a home environment, it makes more sense to have a spare router pre-configured as cold-standby, to swap-in when needed (and DHCP is actually the least of your worries, temporary static IPs are quickly configured for recovery, but DHCP failing usually implies everything else being broken as well).

If the dumb AP's have predictable names, there is a possibility for scripting. Fox example... WR-1, WR-2 etc. Extract the number from hostname , add to base , 100 + nr, and assign static IP for interface