What's new

Release Asuswrt-Merlin 386.4 is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
Hi,

I also have similar problems after upgrading my GT-AX11000 to Merlin 386.4, while version 386.3_2 runs smoothly without a glitch.

The TP-Link smart bulbs, switches and plugs started to disconnect and re-connect from the 2.4 wifi network randomly after the router being upgraded to version 386.4.
I noticed from the wireless log that the P flag (Powersave mode) goes on and off randomly with all the TP-Link devices, whenever the P flag is ON, that particular device is disconnected.
I fall back to 386.3_2 and check the wireless log, the P flag never comes on and the devices had no connection problems at all.
Anyone has any ideas if there is a router setting that will stop activating the Powersave feature of the View attachment 38226devices?

Hi EMWGee,

This new information is very helpful and hopefully will help us to work with Merlin or probably Asus (I think issue is in GPL as the most recent factory firmware shows same behavior) to get this fixed.
 
I had problems with stock and P100 Tapo devices. If I switched off DNSoverTLS on stock they would reconnect but changing back to TLS they would go MIA after 24 hours. Haven't experienced this with Merlin's 386.4. Maybe a red herring but have you checked DNS over TLS setting or tried them off?

Thank you for the information. I think you may have been experiencing a different problem as my smart bulbs were disassociating from the wifi station several times an hour or what seemed every few minutes.

I used DNSSEC with 386.3.2 no problems but when I troubleshot with 386.4, DNS SEC was not enabled and all the bulbs were still randomly disconnecting.
 
Wifi code comes directly as 100% binary files from Asus. There is nothing for me to test or investigate there, wifi is what it is. Start reviewing your wifi configuration first. The fact that most client issues are on the 2.4 GHz lead me to believe that most of you are keeping advanced features enabled such as Implicit Beamforming or Airtime Fairness, which has well documented problems with a lot of cheap IoT wifi SoCs. Disable these features on the 2.4 GHz band, none of your clients can make use of them anyway. Sometimes, a complete power cycle (not just a reboot) of the router and the clients has also been known to help, as it ensures both are trying to establish a fresh connection.

For the record, my Roomba is connected to my 2.4 GHz band, and despite being at the complete other end of the apartment and being parked right next to my microwave oven (which is why connection time typically gets reset about every 24 hours), it was showing 31 hours of connection time when I checked earlier tonight before flashing a new firmware build. (which means the connection even survived me microwaving my pizza 6 hours ago). My Goovee light that I turn on at night have also no problem connecting to the 2.4 GHz band. As for the 5 GHz band, both my tablet and my phone both showed over 130 hours of connection time.

Regarding the WAN Disconnection State: please, read post #2. So far, the vast majority of issues turned out to be self-inflicted wounds from people who had cleared the value, or replaced it with an incorrect value (www.google.com is NOT a good test, as the IP address will change depending on which DNS servers you are querying). Restoring the WAN monitoring to proper values will fix it.

Hi Merlin,

Thank you so much for all that you do and the information about the WIFI issues. Unfortunately disabling Implicit Beamforming and Airtime Fairness did not work for me using 386.4. I tried everything from shutting all the TP-LINK bulbs down for a night, powering them on with a reset one at a time and reconfiguring them with the new router firmware, and factory resetting the router. There has to be a bug in the Asus GPL for WIFI as I also experienced the same issues with their latest factory firmware release.

I ultimately reverted back to 386.3.2 and everything works great. TP-Link bulbs never disconnect even with Implicit Beamforming or Airtime Fairness enabled. I noticed someone posted they saw the power saver flag was being set on each bulb with the new firmeware.... maybe disabling WMM APSD would help? Maybe I will try this weekend but so far I have spend almost 2 days troubleshooting which including reconfiguring a large number of settings from scratch.

-Mike


-Mike
 
Dirty flash 386.4 for AX86U and AC66U_B1 - no issues found, all good. Thank you Merlin!
 
What version are people using to dirty flash on an AC87U? I have tried 3 now and get unsuccessful message and takes like 10 minutes for my network to come back up.
 
What version are people using to dirty flash on an AC87U? I have tried 3 now and get unsuccessful message and takes like 10 minutes for my network to come back up.
AC87U is not supported by Merlin
 
What version are people using to dirty flash on an AC87U? I have tried 3 now and get unsuccessful message and takes like 10 minutes for my network to come back up.
You can't flash this firmware on an RT-AC87U, it's unsupported. The last supported Merlin firmware was 384.13_10.
 
Oh I thought 'dirty flashing' was just installing it anyway and accepting that you might brick it or something. I just got an AC68U.
 
Oh I thought 'dirty flashing' was just installing it anyway and accepting that you might brick it or something. I just got an AC68U.
No, dirty flashing is when you flash the new version and don't reconfigure everything from scratch.
 
here has to be a bug in the Asus GPL for WIFI as I also experienced the same issues with their latest factory firmware release.
Since the issue seems to be largely tied to TP-Link, I wouldn't be so sure that the fault lies in the router itself.

Long ago, following a wireless driver update on the RT-N66U, XBox started having connectivity issues. The fault was actually caused by the new wifi driver adding support for an error correction method, and support for that method was actually broken on the XBox. This led to the addition of the XBox-related setting which disabled this new feature. The actual fault was with the XBox, not the wifi driver.

EDIT: seems that connectivity issues is an old problem with these TP-Link light bulbs.

 
Last edited:
Hi Merlin,

Thank you so much for all that you do and the information about the WIFI issues. Unfortunately disabling Implicit Beamforming and Airtime Fairness did not work for me using 386.4. I tried everything from shutting all the TP-LINK bulbs down for a night, powering them on with a reset one at a time and reconfiguring them with the new router firmware, and factory resetting the router. There has to be a bug in the Asus GPL for WIFI as I also experienced the same issues with their latest factory firmware release.

I ultimately reverted back to 386.3.2 and everything works great. TP-Link bulbs never disconnect even with Implicit Beamforming or Airtime Fairness enabled. I noticed someone posted they saw the power saver flag was being set on each bulb with the new firmeware.... maybe disabling WMM APSD would help? Maybe I will try this weekend but so far I have spend almost 2 days troubleshooting which including reconfiguring a large number of settings from scratch.

-Mike


-Mike
AX88/386.4_0 (Clean upgrade): I have over twenty TP-Link devices and am not having any problems. Did you set your 2.4 GHz channel manually? If you have AImesh do you have Roaming enabled (it helps when things get reset), and of course airtime fairness and universal beam should be disabled.
 
Since the issue seems to be largely tied to TP-Link, I wouldn't be so sure that the fault lies in the router itself.

Long ago, following a wireless driver update on the RT-N66U, XBox started having connectivity issues. The fault was actually caused by the new wifi driver adding support for an error correction method, and support for that method was actually broken on the XBox. This led to the addition of the XBox-related setting which disabled this new feature. The actual fault was with the XBox, not the wifi driver.

EDIT: seems that connectivity issues is an old problem with these TP-Link light bulbs.



The problem isn't pertinent to TP-Link devices only, my LG washer and dryer are experiencing the same problem, they connected fine with my GT-AX11000 router running 386.3-2 version firmware, but not with the 386.4 upgrade.

All my IoT devices were working fine with my GT-AX11000 router running ASUS original firmware up to version GT_AX11000_300438644266, and since I had connection problems with all their newer firmwares, that was why I switched to Merlin firmware, but now it happens again.......
 
I think this was how @themiron disabled Stubby dnssec in favor of dnsmasq dnssec. Just set it to check for an unlikely value.

If I remember my DoT/DNSSEC history correctly, DNSSEC was never enabled via Stubby in Merlin firmware. I do remember my questioning the reasoning behind using DNSSEC in dnsmasq. The answer was that you can enable DNSSEC without enabling DoT. Enabling DoT just enables Stubby to do DoT.

In Stubby, DNSSEC requires a couple of entries in the stubby.yml file.
1. The line "dnssec: GETDNS_EXTENSION_TRUE" needs to be added
2. A writable place for the certs retrieved by Stubby is required. By default Stubby in Merlin does have "appdata_dir: "/var/lib/misc""

I enable DNSSEC in stubby with a stubby.postconf file:
Code:
#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
pc_insert "tls_authentication: GETDNS_AUTHENTICATION_REQUIRED" "dnssec_return_status: GETDNS_EXTENSION_TRUE" $CONFIG
This is the way I am used to running DNSSEC as I always run DoT.

Both ways do work to the same ends to enable DNSSEC validation. There is no right or wrong way.

And, the online DNSSEC test sites do not prove that the DNSSEC on the router is working. As I remember using Dig it the sure method but I've lost my notes on how to do that. I am comfortable knowing it does work with either method as I had proved it in the past. Might search for my notes later this afternoon after the nap.
 
Hello all,

New forum member here, longtime Merlin user. After upgrade to 386.4 recently I noticed today the router crashed. Is there a process to upload crash logs or would someone like to review? I will keep an eye on it.
 
Hello all,

New forum member here, longtime Merlin user. After upgrade to 386.4 recently I noticed today the router crashed. Is there a process to upload crash logs or would someone like to review? I will keep an eye on it.
You could upload the entire syslog to pastebin.com and provide a link to it.
 
No, dirty flashing is when you flash the new version and don't reconfigure everything from scratch.
Yup I got it now. I mean I knew it from dirty flashing ROMs on my phone I just had a weird idea I guess.

Anyway I was looking at this:

can you not ssh into the ac86u? how do you install everything on it? or is that the wrong one? because the picture looks nothing like it. Is the 86 better than the 87?

This is a better comparison. I don't care about the wifi I just wanted updated merlin, but i'm sad it has a worse CPU, will that affect anything like wired transfer speeds from my truenas server?

Edit: I just saw this: https://www.snbforums.com/threads/rt-ac86u-vs-rt-ac87u.49949/#post-454607
So.. from the man himself. okay sold.
 
Last edited:
Status
Not open for further replies.

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top