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.

 

[Martinski]

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.

I don't have enough experience or knowledge regarding AiMesh to provide an answer to your question.

Without a publicly available technical guide or "technical paper" from ASUS that explains with specific details how an AiMesh node is meant to be set up and configured to work consistently and reliably, along with any known limitations and constraints for different setup scenarios (including H/W & F/W combinations), all we are left with is anecdotes, theories and speculations based on what seems to work (and what doesn’t) as reported by individual users describing their own use cases and personal experiences, with varying degrees of success (or failure).

However, this collection of informal data points is not structured, systematic, and rigorous enough, IMO, to establish a set of standardized benchmarks and rules that all users can follow to get reliable, consistent, and repeatable results.

It seems highly unlikely that we’ll ever get such a technical document from ASUS, so I’m not holding my breath.

Just my 1.5 cents.

 

[jksmurf]

I don't have enough experience or knowledge regarding AiMesh to provide an answer to your question.

Without a publicly available technical guide or "technical paper" from ASUS that explains with specific details how an AiMesh node is meant to be set up and configured to work consistently and reliably, along with any known limitations and constraints for different setup scenarios (including H/W & F/W combinations), all we are left with is anecdotes, theories and speculations based on what seems to work (and what doesn’t) as reported by individual users describing their own use cases and personal experiences, with varying degrees of success (or failure).

100% and really well said. I probably happen to be one of those ‘individual users’ but it’s like feeling your way in the dark with no moon and eye shades on. Just impossible, postulating what works and what doesn’t with a grossly inadequate sample size, no road map and no signposts.

However, this collection of informal data points is not structured, systematic, and rigorous enough, IMO, to establish a set of standardized benchmarks and rules that all users can follow to get reliable, consistent, and repeatable results.

Yup.

It seems highly unlikely that we’ll ever get such a technical document from ASUS, so I’m not holding my breath.

Me neither, which is just daft. AIMesh could work really well if ASUS and users work as a collective and iron the bugs out but there’s probably insufficient will and an innate fear of getting blamed, so the default position on that front seems to be do nothing, which is disappointing.

I don’t think well-working AIMesh is too far off TBH, the issue is that by allowing a huge number of potential node models they’ve created themselves a behemoth. Even the supposed higher end GNP and VLAN capable combinations struggle.

 

[Tech9]

all we are left with is anecdotes, theories and speculations based on what seems to work (and what doesn’t) as reported by individual users describing their own use cases and personal experiences, with varying degrees of success (or failure).

You sound just like another developer who simply ignored both user experience and many hours of testing for about 2 years period and at the end of the day... engineers upstream helped fixing the "non existing" issue. This is a direct result of lack of own experience. Anyway... I personally can sit and enjoy the view when folks around fight with an issue even when I know how to fix. No official information, no official FAQ, figure it out yourself. Like I have pretty good guess what breaks @jksmurf AiMesh, but... who cares?

 

[Martinski]

You sound just like another developer who simply ignored both user experience and many hours of testing for about 2 years period and at the end of the day... engineers upstream helped fixing the "non existing" issue. This is a direct result of lack of own experience.

I have no idea what you're talking about. By using such vague references to some previous exchange with an "unnamed" developer about some "unnamed" issue, it's not clear what point exactly you're trying to make.

Now, just in case you are confused. I never said or proposed that all reported user experiences, testing, and results should be simply dismissed or ignored. What I said was that, IMO, the collection of all the isolated use cases and personal experiences as reported in the forums is "not structured, systematic and rigorous enough" (from my S/W Engineering perspective) to be able to formulate a clear overarching strategy or to develop a set of formal specifications that all users can follow to set up and configure a reliable, consistent and robust AiMesh network.

IOW, the reported user experiences may serve as an informal and loose set of "rules" one can use to try to set up and configure an AiMesh network, but should not be confused with a formal, well-tested, and well-established set of technical specifications.

Anyway... I personally can sit and enjoy the view when folks around fight with an issue even when I know how to fix. No official information, no official FAQ, figure it out yourself. Like I have pretty good guess what breaks @jksmurf AiMesh, but... who cares?

Quite frankly, your entire post sounds like you're just trolling, not attempting to provide any useful or helpful insights. Also, you seem to callously enjoy seeing other users struggle through or have difficulties with their network setup, and then you openly take great pride and pleasure in doing so, which makes it look like you have some really "dark" traits in your personality... But who knows, right?

 

[degrub]

I have no idea what you're talking about. By using such vague references to some previous exchange with an "unnamed" developer about some "unnamed" issue, it's not clear what point exactly you're trying to make.

Now, just in case you are confused. I never said or proposed that all reported user experiences, testing, and results should be simply dismissed or ignored. What I said was that, IMO, the collection of all the isolated use cases and personal experiences as reported in the forums is "not structured, systematic and rigorous enough" (from my S/W Engineering perspective) to be able to formulate a clear overarching strategy or to develop a set of formal specifications that all users can follow to set up and configure a reliable, consistent and robust AiMesh network.

IOW, the reported user experiences may serve as an informal and loose set of "rules" one can use to try to set up and configure an AiMesh network, but should not be confused with a formal, well-tested, and well-established set of technical specifications.


Quite frankly, your entire post sounds like you're just trolling, not attempting to provide any useful or helpful insights. Also, you seem to callously enjoy seeing other users struggle through or have difficulties with their network setup, and then you openly take great pride and pleasure in doing so, which makes it look like you have some really "dark" traits in your personality... But who knows, right?

And nor should business/commercial design and implementation be confused with consumer, where the latter is dominated by marketing/low margin rather than engineering.

 

[Tech9]

Now, just in case you are confused.

No confusion. When the conversation starts to steer to personal qualifications everything becomes much clearer. Just continue your software engineer life and have a nice day.