AImesh node requests dhcp, but never receives one...

[ColinTaylor]

It is technically incorrect, for this reason it is not recommended and even not allowed on some servers.

It is not technically incorrect. Point me to any RFC or international standard that says so. Different vendors have different ways of managing DHCP but that doesn't mean one is technically correct and the others aren't.

I made no comment regarding AiMesh so you're just trying to distract.

 

[Tech9]

Untill now , yes, always same node

Was the same happening with the previous version of Asuswrt-Merlin on the main router?

 

[Pergola Fabio]

Was the same happening with the previous version of Asuswrt-Merlin on the main router?

Well. I only have the AX-88u for a few months , before I had the ac-88u , then it never happened, was same config

 

[Tech9]

You may have to give up on some old habits. The RT-AC86U units are EoL and AiMesh component is unchanged for quite some time, but RT-AX88U is still supported and changes in behavior are expected. If your ultimate goal is AiMesh - use stock Asuswrt on all units. If you have no interest in Guest Network propagation to nodes - Router + AP Mode is more stable configuration with potentially higher performance plus options for better Roaming optimization.

 

[bbunge]

Untill now , yes, always same node

As I've said a couple of times here - you have a hardware problem with the AC86U - it is failing! Time to send it to the big recycle bin and get another Aimesh node. If you really need all the WIFI that is...

 

[Tech9]

In my experience this is not a typical RT-AC86U failure symptom. They do have software quirks, but usually not present in AP/Node configuration. Most of RT-AC86U failures were hardware related like port, power circuit, radio IC, etc. This is something the user can catch relatively quickly.

 

[Martinski]

It is technically incorrect, for this reason it is not recommended and even not allowed on some servers.

That's the wrong assessment and conclusion. Given the context of the OP's system with dnsmasq as the DHCP server, it's definitely and technically correct. In fact, both RFC 2131 and RFC 2132, which define the core specifications for the functionality and behavior of the Dynamic Host Configuration Protocol (DHCP), allow for static (i.e. manual) IP address reservations to be outside the defined IP address pool as long as they are within the boundaries defined by the subnet mask assigned to the network interface.

If other DHCP implementations (from other vendors) choose to do something more restrictive, it doesn't mean dnsmasq is "technically incorrect" since it's still following the standard specifications.

IMO, you need to read more and familiarize yourself with the actual DHCP technical specs so that you don't rely purely on anecdotal evidence that leads to making inaccurate and misleading statements.

 

[Tech9]

you don't rely purely on anecdotal evidence

Okay, you guys @ColinTaylor and @Martinski win on RFCs, can't argue with that. I'm sure you know what the specifics and common practices are in different systems and are more familiar than most about ASUS specifics. I have a genuine question at the end of this post and will share first hand experience and findings. If you know additional details and can share your knowledge or at least thoughts - it will be great.

ASUS with AiMesh have node discovery, self-healing, supported features set check, backhaul monitoring, device pairing, etc. mechanisms in place. The likeliness to break AiMesh goes as follows:

A) external DHCP server
B) manual reservation outside of DHCP pool
C) manual reservation inside the DHCP pool
D) automatic IP assignment by DHCP

In my experience with AiMesh and it dates back to AiMesh 1.0 scenario D is what AiMesh expects to have in order to work correctly. ASUS removed one of the requirements with AiMesh 2.0, external DHCP was not allowed before AiMesh in AP Mode configuration become available. The negative effects of user interfering with DHCP may not be immediate, but only when specific mechanism kicks in and doesn't find what it expects.

I have similar findings related to disabling WPS after setting up AiMesh. It may cause issues with self-healing mechanism in wireless backhaul scenarios since (based on behavior observations) it apparently uses WPS. To me it seems like ASUS also has a set of specific requirements on top of what is allowed individually in firmware components. There is another non-documented quirk related to factory paired units like in this case. I'm sure ASUS Support may not be able to help with this one quicker than a SNB Forums member who has seen it before.

The question: Do we know what the specific ASUS requirements for AiMesh are? If we do - the information is directly related to the OPs issue and may prevent further issues of this nature.