In some dire need of assistance (AX86U)

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

shadowfiber

Occasional Visitor
Greetings everyone,

Long time lurker, super appreciative of what this community has done for this lurker in the past - Proud user of Merlin in the past. I am hoping someone has some ideas as I am at wits end.

I have been running an AC66U (original non B1) version for several years - running on Merlin 380.70. It was showing its age, randomly had issues here and there and I had decided it was time for an upgrade. Purchased an AX86U prior to Merlin sharing he was going to support the device - and in the timeframe of about 2 months, have been in a continuous loop with ASUS support trying various levels of beta firmware to solve the problem.

When configuring the new device, I had them side by side and chose the same SSID's, similar networking configuration, IP addresses, etc. etc. when deployed in the home. I had a few devices that needed firmware updates to communicate to a newer router, but overall it was a very smooth process. Except for a large component in our home.

We have 5 Google Home Minis and 1 Google Home (OG) (not the Nest Versions) that randomly disconnect from wifi (or so they say) and when attempting to be used say "Hang on while I connect to wifi". These devices are connected on the 2.4Ghz band, and the connection time varies from device to device. On Non-merlin firmware, we were able to see that the connection time would drop randomly and then re-establish to the router - however it would sometimes take hours for the Google Home to figure it out. Long story short - On the AC66U - no issues - none at all, they stay connected seemlessly, no issues at all. On the AX86U, issues all the time. As a test, right this moment, I said "hey Google" to the office Mini - and it says "hang on..." and looking at the router, it shows it's been connected for 15 minutes (last time I made some attempted changes)

If I restart the Google device - it connects with no issues for a period of time - can range from minutes to hours.

Environment Items:
- Smart Connect is OFF
- All the Trend Micro stuff is OFF
- QOS - OFF
- Wireless Config - 2.4: AX Enabled, 20/40MHz bandwidth, control channel: auto, extension channel, auto
- Pi.hole for DNS
- Majority of the items in the home have static IP's (the google homes do)

Here is the list of things we've tried:
- Various levels of firmware fixes and changes with ASUS (Also tried Alpha3 on Merlin (which is what I am running now).
- Connecting to 5.0Ghz Band
- Changing to static control channel and extension channel
- Changing to 20 or 40 MHz bandwidth static
- Various changes to Beamforming configurations, MU-MIMO etc. at the suggestion of ASUS
- Have removed the pi.hole and attempted static dns for the google homes of 8.8.8.8
- Probably several other things I cannot recall at the moment

Debug logs indicate constant DHCP offers and renewals only for the Google Home Devices as well (when they are stuck) - if I reset a device, it seems OK until things break otherwise these loop every minute or so for the associated MAC but never an ACK unless i reset the device:
dnsmasq-dhcp[2941]: DHCPDISCOVER(br0)
dnsmasq-dhcp[2941]: DHCPOFFER(br0)

I am aware of an EXTREMELY long thread in the Google Support forums that speaks about several issues - some of them AX routers (which I am unsure if it's coincidental or not). Google Support is next to useless; so can't bark up that tree. I have purchased a Sonos that has Google Assistant to get more information, my hunch is that it will be fine - but can report in a few days.

So there you have it, I am looking to the smart minds at SNB for some assistance, if anyone has guidance it would be greatly appreciated; if we do get something resolved, you can be assured I would want to throw a coffee in your direction.

Thanks for the read.
 
Last edited:

karlegas

New Around Here
Hi

I ordered that router coming the next Wednesday, could you share with me your config file to research your problem.

Thanks

Karl
 

thiggins

Mr. Easy
Staff member
If your devices are set to static IP, they're not going to ACK a DHCP offer anyway.
Have you checked that the LAN IP on the new router is set the same as the old? I think ASUS switched to 192.168.50.X awhile ago.
I'd also try switching a device to DHCP to see if that's the problem.
 

ColinTaylor

Part of the Furniture
If your devices are set to static IP, they're not going to ACK a DHCP offer anyway.
Have you checked that the LAN IP on the new router is set the same as the old? I think ASUS switched to 192.168.50.X awhile ago.
I'd also try switching a device to DHCP to see if that's the problem.
I'm guessing that by "static" he really means a reserved IP in DHCP (what Asus calls manually assigned), otherwise it wouldn't be sending a DHCPDISCOVER in the first place.
 

shadowfiber

Occasional Visitor
Hi

I ordered that router coming the next Wednesday, could you share with me your config file to research your problem.

Thanks

Karl
Hi Karl,

Happy to provide screenshots or whatever you'd like to duplicate, let me know what you find pertinent.

If your devices are set to static IP, they're not going to ACK a DHCP offer anyway.
Have you checked that the LAN IP on the new router is set the same as the old? I think ASUS switched to 192.168.50.X awhile ago.
I'd also try switching a device to DHCP to see if that's the problem.
Hi Thiggins, Thanks for the response.

As Colin reported below I used the improper verbiage. There are DHCP reservations in which case I should see an ACK (and I do when the device comes online after a restart for a period of time)

I can also confirm that the new router is the same 192.168.1.0/24 in this case, and did not change from the old.

Also can confirm, DHCP vs. DHCP reservation does not seem to make a difference. (Appreciate the idea).

----

Also, did try to connect the Sonos last night, found the same problems and issues with the Google Homes. When I wired the Sonos, no issues at all - however on the 2.4 GHz Band, it would have difficulty staying connected, linking services, etc.
Mobile Devices, such as our phones (Pixel XL and Pixel 5's), tablets (Galaxy Tab S6), Fire TV's, random wifi IP cameras, even our sprinkler controller and Roomba, do not have issues on the wireless. It seems to be now Google Home Devices and Sonos.
 

shadowfiber

Occasional Visitor
Apologies for the double post - I feel like there is something foundational occurring in these environments. I have been perusing forums, review sites, just looking for hints of something that is going on... Here is an Amazon review that talks about very similar issues. I have sent feedback to ASUS probably about 10 times now - and I just wish there was something else I could do... I love the feature sets and have been using their routers in so many different applications - but this one is just driving me wild.

Not sure if it helps, but here is the Amazon review I found.


I have been using TP link routers for several generations and I guess I'm just used to fundamental features working. I went for speed here and I failed. Just like the team at Asus did when they released thig garbage router, something people have had over a decade to figure out, and it can't even keep the SSID broadcasting on the network. It takes hours or frustrating troubleshooting to get it back online. Devices disconnect, Google home devices flip out and just forget that network existed and it takes hours to get everything back online. Yet some devices just keep on trucking. It's bonkers. I hate this router. I want to kick this router through a window. Don't buy it.
 

thiggins

Mr. Easy
Staff member
Also can confirm, DHCP vs. DHCP reservation does not seem to make a difference. (Appreciate the idea).
Thanks for checking that. Next to try, then, is to take DHCP out of the picture entirely and set static IP on the device(s). Make sure you assign addresses outside the router DHCP range.
 

shadowfiber

Occasional Visitor
Thanks for checking that. Next to try, then, is to take DHCP out of the picture entirely and set static IP on the device(s). Make sure you assign addresses outside the router DHCP range.
Hey there, thought about that process.. Unfortunately, I have been unable to find documentation where that is possible with Google Homes (happy to be proven wrong of course) - it seems most articles speak to simply adding a reservation as Google doesn't really want you to use a static.

Again, greatly appreciate your efforts and adding brain power to the mix here.
 

ColinTaylor

Part of the Furniture
Debug logs indicate constant DHCP offers and renewals only for the Google Home Devices as well (when they are stuck) - if I reset a device, it seems OK until things break otherwise these loop every minute or so for the associated MAC but never an ACK unless i reset the device:
dnsmasq-dhcp[2941]: DHCPDISCOVER(br0)
dnsmasq-dhcp[2941]: DHCPOFFER(br0)
This is suspiciously similar to this problem. I've seen other reports of this nature in these (Asus) forums in the past. Unfortunately I've not seen a definitive solution for it. In a lot of cases "it just starts working again" (or not). I did speculate in that thread that a workaround might be to change the DHCP server so that it uses broadcast replies rather than unicast. But it magically started working before that theory could be properly tested.
 
Last edited:

shadowfiber

Occasional Visitor
This is suspiciously similar to this problem. I've seen other reports of this nature in these (Asus) forums in the past. Unfortunately I've not seen a definitive solution for it. In a lot of cases "it just starts working again" (or not). I did speculate in that thread that a workaround might be to change the DHCP server so that it uses broadcast replies rather than unicast. But it magically started working before that theory could be properly tested.
I am testing the theory right now, reconfiguring pi.hole to be dhcp server - will report back the findings.
 

shadowfiber

Occasional Visitor
Interesting results about 2 hours in of testing and wanted to share where it is now.

The AX86U reports all of the addresses as "static" addresses now that it is no longer serving DHCP. In that, all wireless devices are showing a connection time of when the change occurred (roughly 2.5 hrs ago). When the router was serving DHCP, I would see random times of connectivity.

I have not seen a Google Home drop off the network yet, and they have not yet reported errors. Unfortunately, the Sonos device still is not functioning properly and has several "cannot connect" or use wireless errors. Acting just as it did when the router was doing DHCP. All other wireless devices seem to be functioning normally and didn't care about the change in DHCP server.

It may be too early to report if the Google's are functioning as they should - and definitely odd that the Sonos continues to have connectivity problems. I attempted a factory reset on the Sonos, no change. Also did confirm that Airtime Fairness was disabled as it has issues with Sonos devices.

Open to more thoughts, will report back in a few more hours of any changes. Regardless, if the DHCP change does end up solving the Google issue - I don't necessarily want/like having the pi.hole be the DHCP server; I look at the pi.hole as a more temporary thing overall and was looking to make it a VM or something else later down the road - having critical infrastructure running an a pi3 that isn't in the networking closet and literally right next to me makes me uneasy for some reason. :) I'd hope that we/I may be able to take some of this info to the developers that be and hope for some infrastructure changes? Not sure.

More to come.
 
Last edited:

RMerlin

Asuswrt-Merlin dev
If the devices report getting disconnected from wifi (as reported on the Wireless Log page), then I doubt it's related to DHCP, more likely to be a wireless-specific problem. A client with DHCP issues should still be able to stay connected to the wireless AP.

In the wifi settings, make sure you also disable Airtime Fairness - I've seen a lot of devices having problems with that, especially on the 2.4 GHz band. Can't recall if Asus finally changed that to be disabled by default (we've had talks about it in the past).

Also, stick to WPA2/Personal. Some devices seem to have issues if authentication on the router is set to both WPA2/WPA3.

Clients reporting a static IP is normal when that client gets an IP from somewhere else - it's the router's way of saying this client does not have a DHCP lease from the router itself. It has no way of saying if it's from a separate DHCP server, or from a static configuration.
 

shadowfiber

Occasional Visitor
Hi Merlin! Appreciate your response! Have confirmed Airtime Fairness is off and using WPA2 Personal.

I feel there may be 2 issues occurring, and it initially seemed like one.

Here is the latest:

1) Google Homes have not disconnected at all - so there is *definitely* something going on with the DHCP side of things on the router causing the Google Homes issues. Not sure what to do about it. Perhaps @RMerlin or @ColinTaylor has some suggestions to the next steps? Again, this did not occur on the AC66U
2) The Sonos device however still has issues. So I assume Merlin is on to something with Wireless Configurations; I am simply unsure of what configuration to change though. Universal Beamforming is Off - have tried various levels of "compatibility". Open to suggestions. I know if I wire the Sonos, it connects with no issues whatsoever. Also, when I power cycle the router/sonos, it seems like it tries to work for a few seconds, then stops for some reason ... odd.

Words cannot express the appreciation for everyone trying to help. Thank you.
 

ColinTaylor

Part of the Furniture
If you upload your router's system log to pastebin.com we can have a look at it.

Are you currently running any custom scripts or configs on your router (e.g. ad-blockers, etc.)?

I don't have any Sonos devices but reading these forums I get the impression they have their own set of compatibility issues. Use the Search and Better Search functions to find those posts and see if they offer any help.
 

shadowfiber

Occasional Visitor
Hi there,

Unfortunately, today it seemed the Google Homes dropped off and are responding the same as they have historically. No changes to the network infrastructure. After a full reset, they seem to be "more stable" than with DHCP on the asus, but I am not sure I have anything tangible other than it worked a bit longer than normal. When power cycling them, they work and are functioning.

The pi.hole has similar logs to the router when the device dropped (all devices "stuck in the cannot connect do this with no ack"):

Nov 28 14:30:47 dnsmasq-dhcp[756]: DHCPDISCOVER(eth0
Nov 28 14:30:47 dnsmasq-dhcp[756]: DHCPOFFER(eth0)

On the sonos front, I can agree that it's a picky beast. Hitting "try again" about 25 times (not kidding) finally allowed the device to connect, but it has random drop outs and such just like the Google Homes.

This leads me to believe we're going back to Wireless compatibility related problems, but I am unsure where else to go with it. All I have is the primitive fact (as I don't have an understanding) that the AC66 worked fine without these issues. I am not running any custom scripts or configurations at this time.

Any way to remove personal data in the logs you're aware of? And of course any other thoughts?

Thanks a bunch.
 
Last edited:

ColinTaylor

Part of the Furniture
You said in post #10 that you were going to test my theory regarding broadcast packets. Did you do that?
 

shadowfiber

Occasional Visitor
You said in post #10 that you were going to test my theory regarding broadcast packets. Did you do that?
Ah, yes, apologies. I had gotten stuck with nmap output that I did not fully understand.

sudo nmap -sU -p67 --script dhcp-discover 192.168.1.1 (asus) simply reports

Starting Nmap 7.40 ( https://nmap.org ) at 2020-11-28 15:07 PST
Nmap scan report for (192.168.1.1)
Host is up (0.00089s latency).
PORT STATE SERVICE
67/udp open|filtered dhcps
MAC Address: 24:4B:FE... (Unknown)

As if it's accepting the unicast request, but did not know where to go from there.
 
Last edited:

ColinTaylor

Part of the Furniture
Log into the router's GUI and go to Administration - System and set Enable JFFS custom scripts and configs to Yes. Also set Enable SSH to Yes.

Apply those changes and then SSH into your router.

Create a file called /jffs/configs/dnsmasq.conf.add with your preferred Linux editor (vi or nano) that contains this line:
Code:
dhcp-broadcast
Save that file and exit the editor.

Now, just to be absolutely sure the change is effected and picked up by the clients reboot the router.
 

shadowfiber

Occasional Visitor
Log into the router's GUI and go to Administration - System and set Enable JFFS custom scripts and configs to Yes. Also set Enable SSH to Yes.

Apply those changes and then SSH into your router.

Create a file called /jffs/configs/dnsmasq.conf.add with your preferred Linux editor (vi or nano) that contains this line:
Code:
dhcp-broadcast
Save that file and exit the editor.

Now, just to be absolutely sure the change is effected and picked up by the clients reboot the router.
Will do ,bear with me a bit - going to reset the device when Alpha 4 comes out and start from scratch (need a bit of time with the family today)
Will get back with you.
 

shadowfiber

Occasional Visitor
Alright, apologies for the delay, did some extended testing.

First, reset the router and installed a fresh alpha4 - reconfigured everything on the network - also removed the pi.hole from the equation completely. After extended testing, no google home connectivity issues - everything was working perfectly. Even the Sonos.
Second, reintroduced the pi.hole with a brand new configuration - wiped it out, redid everything. Google Homes disconnected randomly with the DHCP issues. Sonos was fine.
Third, attempted your DHCP broadcast test. No change.
Fourth, attempted random changes to pihole - unable to get back to things working. (even attempted the DNS bypass and it didn't work)

At this point, to prove concept, I may remove the pihole from the equation to see if I can get back to the initial setup working completely. This would beyond a shadow of a doubt now say the pihole is the cause of the problems; and then I can open a support thread and hope for some help there.

I had originally thought the issue was the router as the pihole was working just fine with the old router... Perhaps someone with some institutional history may have some thoughts on how DHCP/DNS changed between 370 and 384/6 firmwares? It seems something has changed enough for that it requires some additional configurations now for Google devices. I attempted to "static" the dns on the router to bypass the pihole to 8.8.8.8 and that did not work too.

I know I am missing something. I just don't know what.
 

Similar threads

Top