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

[Tech9]

nodes can have perfect dhcp reservations, there is no difference then configuring another device as a mac reservation, the problem is related to something else

If you don't take advice why are you asking questions? Just find your problem and fix it. Good luck!

 

[Pergola Fabio]

sorry, but saying dhcp reservation doesnt work for nodes/aimesh is BS, why wouldnt that work??

 

[Tech9]

Sorry to bother you, just deal with the issue yourself. Seems like you know inner workings of AiMesh better than anyone else. My only advice is to get rid of RT-AC86U routers before they get rig of... you.

 

[jksmurf]

My only advice is to get rid of RT-AC86U routers before they get rig of... you.

@Pergola Fabio. Tech9 can be prickly at the best of times, but has a wealth of experience. This (above) is very sound advice.

This router model is known to be plagued with failures; in the past, Tech9 has even gone so far as to try to salvage them at a HW level (soldering/desoldering/fluxing whatever) etc but that does not detract from the fact this is not ASUS finest model, hardware-reliability wise, far from it.

Given that you have 3 identical nodes of this model, on the balance of probablities, one of them is likely to go TU. That's a very technical term for ... will shuffle off its mortal coil. Like old goats, they don't just die in a flash of blinding light, they just get more and more cantankerous, more frustrating more often, until they eventually keel over.

Some of us get a kick out of keeping old stuff and re-purposing it but sometimes ... it's done.

 

[Pergola Fabio]

yes, offcourse, i can live wih comment that it can be an technical/hardware issue
But i read in this thread like , dhcp reservation is not recommended or doesnt work with nodes and can cause problems, sorry thats not correct!

 

[jksmurf]

yes, offcourse, i can live wih comment that it can be an technical/hardware issue
But i read in this thread like , dhcp reservation is not recommended or doesnt work with nodes and can cause problems, sorry thats not correct!

Whilst you may be correct (and I am in your camp on doing the manual assignments for nodes), with all due respect, if you come asking for advice sometimes you have to park the answers that get your back up and try to find a way to get to where you want to without reacting to it, because on that path lies only frustration. Move on. My 2c.

 

[Pergola Fabio]

Ok. Thx :+)

Next time when it happens I remove the reservation and reboot the node to see how it goes, so we can exclude that out

 

[jksmurf]

Ok. Thx :+)

Next time when it happens I remove the reservation and reboot the node to see how it goes, so we can exclude that out

Sure; or go though my list, test it and if it happens, then try that last, up to you.
Either way. My personal opinion is that it will not make a blind bit of difference, but yes, it's all a process of elimination.

 

[Tech9]

Just one last... BS before I go - when you reserve an IP address in DHCP server it doesn't become static IP address for the client. Reservation means DHCP will attempt to lease this address to this specific client. It may be rejected for various reasons. DHCP offer is not enforcement. With DHCP lease scope 192.168.0.100-200 the reserved address has to be inside this scope and not 192.168.0.2. The reserved address is still a lease. This range below 100 can be used for clients with static IP address set on the client. This is the correct way to do it. For no user control clients performing auto configuration - no guarantees.

 

[Pergola Fabio]

Hmm, makes sense , but my DHCP reservation list goes from 2 - 50 , my static clients (documented) are from 51 -99 , DHCP scope is from 100-200

So it's not a conflict if that were you are taking me

 

[Tech9]

What I'm saying is the arrangement is technically incorrect and the method doesn't guarantee the result. What do you understand from it and where do you want to go from here is your own decision.

 

[Martinski]

With DHCP lease scope 192.168.0.100-200 the reserved address has to be inside this scope and not 192.168.0.2. The reserved address is still a lease. This range below 100 can be used for clients with static IP address set on the client. This is the correct way to do it. For no user control clients performing auto configuration - no guarantees.

Hmmm... It sounds like you're saying that when using dnsmasq as the DHCP server, it's a general requirement that all manually assigned IP address reservations must be within the defined IP pool range. If that's indeed what you're saying, it would be an incorrect statement. Perhaps it's a recommended practice, but certainly not a requirement when using dnsmasq as a DHCP server.

IOW, for dnsmasq, there is no technical constraint or requirement that says IP address reservations must be within the defined network IP address pool range.

Screenshots from the dnsmasq man page:

Essentially, the dnsmasq documentation says that IP address reservations (made via dhcp-host directives) must fall within the valid, usable range defined by the subnet mask assigned to the network interface, but they do not need to be within the range defined by the IP address pool (i.e. the start/end addresses) set via the dhcp-range directive.

Now, having said that, it may be possible that the AiMesh module is interfering with the dnsmasq-allocated leases, and if so, that would be a limitation/constraint/issue/bug/feature with AiMesh, not with dnsmasq itself.

Just my 2 cents.

 

[Tech9]

not a requirement when using dnsmasq as a DHCP server

I know Dnsmasq allows it. It is common practice since the reservation is a lease.

that would be a limitation/constraint/issue/bug/feature with AiMesh

It is most likely AiMesh "feature". The bigger the generation difference in devices the greater the chance to encounter it. I've seen it and for this reason I don't recommend messing with AiMesh. It may work today and stop working tomorrow after firmware update with unknown changes.

 

[ColinTaylor]

I know Dnsmasq allows it. It is common practice since the reservation is a lease.

That's not what you said earlier. So yes, you were talking BS. And it's not "technically incorrect".

Maybe you should stop commenting of the behaviour of routers you don't use.

 

[Tech9]

It is technically incorrect, for this reason it is not recommended and even not allowed on some servers. It is allowed in Dnsmasq. How any reservation inside or outside of DHCP scope interacts with AiMesh and does it cause the issue is the question. You @ColinTaylor perhaps could share your experience with AiMesh behavior instead? I'm pretty sure I've played with AiMesh more than you and I have actually seen the issue we discuss. You can also trigger it on your RT-AX86U with RT-AC68U node, if you still have your old router. I understand the difficulties to experiment with limited available and live equipment so no rush. Thanks for stopping by.

 

[Pergola Fabio]

I think already using here for 6 years that my nodes have reservations out of the scope, never had issues, untill now with this single unit. All my other units are still working fine

 

[Tech9]

Can you switch the reservation IP of working and non-working node, reboot and see what happens? Next thing I would do is to remove one working node and replace it with currently non-working with the same IP of removed working node. If it starts working - it's AiMesh not liking your reservations. I understand you had it working for years, but ASUS makes changes to AiMesh frequently.

 

[Pergola Fabio]

The problem is that I can't replicate it, sometimes it runs for weeks without issue, last week it occurred twice, now it's running again since reboot on saterday

 

[Tech9]

Just to make it clear - is it always the same node or one of them stops after some time?

 

[Pergola Fabio]

Untill now , yes, always same node