AC88U with 386.4 - DHCP lost after a day

[Oferlaor]

Hi, after a dirty update, I got the unit to work fine with 386.4 without any noticeable hitch.

However, after about 24 hours, the network started to fail. I found out that the clients that used fixed IP (there are a few, that hard wire their IP address to the same one as bound to by DHCP fixed lease) all are failing to obtain an IP address.

Restarting the router worked, but as a precaution I downgraded to 386.2

One thing that struck me was that I remember that it was mentioned in the release notes that the DHCP fixed leases would be erased if we downgrade. This did not happen. I was fully prepared to lose my fixed DHCP leases, but in fact they remained intact, which leads me to believe maybe that's the problem - that the migration maybe didn't work properly?

I saw two relevant items in the changelog:

- CHANGED: Switched to Asus's own dhcp hostname support.
Existing dhcp_hostnames entries will be
converted on first boot.

and in a previous version:

- FIXED: DHCP could fail to renew its lease with some ISPs when
Trend Micro engine was enabled (workaround provided
by Asus)

I have trend micro turned on. I did not try to turn it off.

 

[ColinTaylor]

DHCP hostnames and leases are two different things.

The DHCP fix referred to above only applies to the WAN connection. It is unrelated to LAN activity.

 

[Oferlaor]

you are right, the second bug is irrelevant.

 

[ColinTaylor]

The were reports of problems with DHCP after migrating to 386.4 where some of the hostnames now contained spaces. This caused DHCP to fail. The solution was to delete the invalid entries from the DHCP "Manually Assigned..." list.

 

[ech]

Was seeing the same thing on my router (AC86U) and "service restart_dnsmasq" fixed it... dnsmasq was spinning on the cpu but not handing out leases. Maybe this was what was happening to you as well?

See here

 

[Oferlaor]

The were reports of problems with DHCP after migrating to 386.4 where some of the hostnames now contained spaces. This caused DHCP to fail. The solution was to delete the invalid entries from the DHCP "Manually Assigned..." list.

wow, I definitely have tons of spaces in mine...

 

[ColinTaylor]

wow, I definitely have tons of spaces in mine...

Oh dear. Looks like whatever code does the hostname migration doesn't work very well.

 

[Oferlaor]

Removed the spaces and will check dnsmasq next time.

but assuming it is the issue, I obviously don't want to issue that command daily...

how do you check if dnsmasq is the root cause, by running top?

 

[ColinTaylor]

It sounds like your issue was having spaces in the hostnames. In which case removing those spaces should have fixed your problem.

 

[ech]

I would've thought that spaces in names would've caused an immediate problem, rather than something that would spring up hours later... in any case, if you ssh into the router and run "top" I was seeing the dnsmasq process constantly sitting at the top of the output, which is not normal... and it would show using 50% of cpu (on my router w/ 2 cores, that means a single process spinning on one cpu). Restarting dnsmasq caused the problem to go away... until the next time it got stuck in a loop.

 

[here1310]

i have encountered same problem on 2 AX88u, 1xAC86u, but use YAZDHCP...
after about 12h failure of the complete DHCP assignment..am back to 3.86.4_alpha1, which ran stable and investigate on a test system further...

1x AX88u was completely reset 3.86.4 and reflashed several times and provided with new setup..problem was not fixed...

 

[john9527]

Reports are that dnsmasq 2.86 is having some problems (it made another build I am working on unusable)....
I wouldn't spend a lot of time trying to debug problems until a new dnsmasq release is available (the repository is currently at 2.87test5)

 

[Oferlaor]

so far, so good. More than 24h without a problem, but I do think that dnsmasq is probably at fault here and that it's a matter of time before this occurs again.

Wouldn't it be better to rollout a new version with a prior version?

 

[Oferlaor]

weird, but this time the issue occurred after a week.

I SSH'd in and saw no dnsmasq or other curious activities. Devices just started to lose the ability to get DHCP.

Rolled back to 3_2

 

[Oferlaor]

false alarm. My main switch died