AiMesh nodes always use DHCP?

[Thw0rted]

I have three RT-AX92Us configured as mesh in AP mode. The primary is set to a static LAN IP, but as far as I can tell there's no way to assign static IPs to the nodes. It's been mostly stable, but I've had a few weird outages lately where devices will be able to connect to one node but not another.

I just came up with a theory of what might be happening. One of the nodes is wired to the home DHCP server. Sometimes, if it loses network connection for a few seconds, the DHCP server will stop handing out addresses until I intervene manually (for probably-uninteresting reasons that I'm working on separately). That would mean, though, that if the node reboots, it won't get a DHCP address, and then I don't know what it can do.

Does anybody know if my understanding is correct? If so, what can I do? I can't hook the DHCP server up to the main AP, and I don't know how long it'll take to fix the problem where it's getting knocked offline. Even if I resolve that, I really dislike having critical network hardware depend on DHCP to operate.

----

ETA: I don't want to bump the thread, but in case anybody comes to this later: I eventually caved and reorganized the network. Instead of having the DHCP server running on a PC, hanging off a mesh node with a dodgy wired backhaul, I built a replacement DHCP server from an old Pi I had lying around and wired it direct to the main router, then moved the node so that it could use wireless backhaul instead. We've also had at least 2 firmware updates since then. One of those changes seems to have more or less fixed the problem with randomly blocking clients, though I can't say which.

I still think it's dumb not to let the main AP assign static IPs to nodes when they join.

 

[OzarkEdge]

I really dislike having critical network hardware depend on DHCP to operate.

Why? I would just let the network operate as designed.

OE

 

[Thw0rted]

Why? I would just let the network operate as designed.

OE

Basically, it's a perversion of the OSI model to have lower layers depend on the successful operation of higher layers to be able to function -- it's supposed to be the other way around. DHCP should (in the moral-imperative sense) be able to work even if IP routing is buggered.

But if my theory is right, and a node that can't get a DHCP lease is unable to communicate with the primary, that goes out the window. When the AP wired to the DHCP server can't participate in the mesh, you've now segmented the network and you're stuck with clients on one side unable to get a lease, not because the DHCP server is broken (trouble for layer 3), but because they can't get packets to it (at layer 2). This greatly complicates troubleshooting because it makes sanity checks like assigning a static IP (in the correct subnet) to a client fail unexpectedly.

I've never set up any other network hardware to use dynamic IPs -- in fact I just took a network security class where they specifically say that all network infrastructure (with on-network management interfaces, at least) should be assigned static IPs. It just makes sense, and seems like a pretty silly oversight here.

 

[OzarkEdge]

Basically, it's a perversion of the OSI model to have lower layers depend on the successful operation of higher layers to be able to function -- it's supposed to be the other way around. DHCP should (in the moral-imperative sense) be able to work even if IP routing is buggered.

But if my theory is right, and a node that can't get a DHCP lease is unable to communicate with the primary, that goes out the window. When the AP wired to the DHCP server can't participate in the mesh, you've now segmented the network and you're stuck with clients on one side unable to get a lease, not because the DHCP server is broken (trouble for layer 3), but because they can't get packets to it (at layer 2). This greatly complicates troubleshooting because it makes sanity checks like assigning a static IP (in the correct subnet) to a client fail unexpectedly.

I've never set up any other network hardware to use dynamic IPs -- in fact I just took a network security class where they specifically say that all network infrastructure (with on-network management interfaces, at least) should be assigned static IPs. It just makes sense, and seems like a pretty silly oversight here.

Maybe your cat has chewed on one of your hardware layers.

I would connect up AiMesh as they prescribe it... remote nodes wired/wireless to the root node, and they get their IP address from the network DHCP server. Done.

OE

 

[MarkyPancake]

You can manually assign the node an IP via the LAN > DHCP Server page. You just need to use the node's MAC address and not the ones that it appears as in the System Log > Wireless Log.

 

[Thw0rted]

Marky, I'm running my own DHCP server elsewhere on the network. The AiMesh network is configured in AP mode so I don't have a "DHCP Server" tab, even if I wanted to use the AX92U as a server.

The point of my original post is that in order for the mesh node to get a lease, it has to be able to talk to the DHCP server, which it can't do until the mesh node comes up on the network -- it's a chicken/egg problem. I'm frustrated that I can assign a *genuinely static* IP to the primary node, but the stock firmware does not provide the option to do so for any other nodes. I guess all I can do is complain to Asus and hope for the best.

 

[WhiteDogBe]

I agree that setting a static IP on critical network devices is more important than people think. If power goes down some devices may never recover by themselves. I've had this issue where my Home Assistant running on a rPI and attached to a UPS lost his IP and couldn't get a new (same) one until I power-cycled it. Something easily avoided if you set a static IP.

I think you can still SSH into any of the nodes and assign a static IP that way. Would be interested in this too, if anyone tries, please post the commands.