What's new

Release Asuswrt-Merlin 386.7 is now available for all models

  • 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.
^^^^ Hmmm. I just started having major DNS issues with all - cloudflare, quad9, google - the wife is about to well... (Note: I've tried switching to cloudflare, quad9, and then then google - with the same results.) I've also rebooted the router a couple times this AM attempting to stabilize it.

Something is up because the router's main logs say:

dnsmasq: no root trust anchor provided for DNSSEC.
dnsmasq: FAILED to start up.
...

I’ve been having oddity delays and retries on on DNS not resolving for 1-2 days. I upgraded to current about 1 week ago.

Setup been rock stable months using DOT.

apologies in advance as I’m typing this on my phone just to reach here..

Update01: OK TY for the testing link. Details: something in _MY_ </jffs/scripts/dnsmasq.postconf> is not playing nice now. It's not changed since 09/03/2021. I removed <dnsmasq.postconf> from processing and dnsmasq is starting OK. I'll put back the DoT items slowly.

Update02: Reviewing my <dnsmasq.postconf> processing remains a mystery for how dnsmasq had been "working fine" since 9/2021. I also noted that using quad9's EDNS simply would not work for me yesterday even without my frakked up <dnsmasq.postconf> control file. I'll take another run at that later.

Digging about the "trust anchors" said that info has to be provided to enable DNSSEC. So whatever _my_ dnsmasq.postconf is doing to the running dnsmasq.conf is breaking that setup. My apologies for the false alert. Thanks for the help!
 
Last edited:
^^^^ Hmmm. I just started having major DNS issues with all - cloudflare, quad9, googlrand the wife is about to well…..

Something is up bc the logs say
dnsmasq: no root trust anchor provided for DNSSEC.
dnsmasd: FAILED to start up.

I’ve been having oddities on DNS not resolving for a few days. I upgraded about 1 week ago.

Setup been stable for months using DOT.

apologies in advance as I’m typing this on my phone to reach here
I’ve had occasional issues using DoT. Usually it’s the provider, though. This sounds different. Personally I just use plain DNS on 53. Simple and it works.
 
^^^^ Hmmm. I just started having major DNS issues with all - cloudflare, quad9, google - the wife is about to well...

Something is up because the router's main logs say:

dnsmasq: no root trust anchor provided for DNSSEC.
dnsmasq: FAILED to start up.
...

I’ve been having oddity delays and retries on on DNS not resolving for 1-2 days. I upgraded to current about 1 week ago.

Setup been rock stable months using DOT.

apologies in advance as I’m typing this on my phone to reach here..
I'm unfortunately not seeing these errors running DoT using Quad9 on 386.7... like you said, it's been rock solid. Also, this is a really great tool to check if DNSSEC is actually working for you on your dns lookups: https://dnscheck.tools/#results
 
I and my friends who use AX86U can confirm 5G WiFi often drop from 160MHz to 80MHz. DFS State changes from In-Service Monitoring (ISM) to Idle.
386.5.2 is OK.

I know WiFi is closed source and RMerlin cannot modify it. I say these to show that there is a WiFi problem with this version of the firmware, so that people who don't want to encounter this problem should not update.
 
Is Cloudfare no longer in the list of DNS servers on WAN page? Should I switch to QUad9 (9.9.9.9, 149.112.112.112)?

Does anyone run older(ac68U) in bridge mode and have low-speed issues?

Is this where you are talking about in the preset server drop down?

1657292468939.png
 
No, I'm talking about at the top of your screenshot. Mine says service name Cloudfare and IPs for it.

Just enter cloudflare manually and hit apply that simple. 1.1.1.1 1.0.0.1
 
I and my friends who use AX86U can confirm 5G WiFi often drop from 160MHz to 80MHz. DFS State changes from In-Service Monitoring (ISM) to Idle.
386.5.2 is OK.

I know WiFi is closed source and RMerlin cannot modify it. I say these to show that there is a WiFi problem with this version of the firmware, so that people who don't want to encounter this problem should not update.
I'm another on AX86U seeing the same thing (along with many here), does seem like a common issue. Dropping back down to 386.52 made the issue go away
 
@omrij & @Damit1 were having a problem with their ISP(Partner?), I think it might have been a PPPoE connection, they didn't provide many details.


If you do can your provide some connection details about your ISPs IPv6 setup - name, wan prefix size & from the syslog the line that begins with "WAN Prefix Size Requested:".

Saying my ISP works or not is meaningless to help will problems unless you specify your ISP, as they can do IPv6 differently.
Well, my ISP is "Partner" from Israel
it's configures as automatic ip in WAN and native in IPV6
with AsusWRT the prefix size is 56
with MerlinWRT i've tried 64 (default) and 56
with the new version - still can't get IPV6 address
and no "WAN Prefix Size Requested:" in system log
 
With living in a very small town in the Andes Mountains of Colombia South America I only have internet speeds of 30Mbps on a good day o_O ... and that 30Mbps was because Fiber was just installed here in town a few months ago... before that I was lucky to get 5Mbps :eek:... So I can't really test speeds on my Nodes to see what the max is as I can't go any higher then 30. If I had a hardwired server I could probably setup something that lets me test the thru-put on my local WiFi network. Not sure how much I believe SPEEDTEST as I know the speed on the Orbi router that I get my internet from shows only 30Mbps on a good day but it also usesSPEEDTEST so go figure. I sure do miss high speed Fios that I had at my last house in PA. I see all these post here in this thread with close to1GB speeds and start to cry but then I remember its always around 75 here year round and I cheer right back up! :)
But the coffee though...excellent! saludos!
 
I have also noticed it takes a bit longer than before with the latest release for NTP to sync (up to 2 minutes even after WAN connection is restored).
For me, it just doesn't.
 
A couple of problems that I have noticed recently.

I had noticed my RT-AC86U's RAM usage climbing after 11 days of uptime. I had not seen it do this in the previous firmware.

Logs showed a couple of process errors:
Jul 7 18:38:59 kernel: pgd = ffffffc00b7a6000
Jul 7 18:38:59 kernel: [00000000] *pgd=000000000abdd003, *pud=000000000abdd003, *pmd=0000000006400003, *pte=0000000000000000
Jul 7 18:38:59 kernel: CPU: 1 PID: 4258 Comm: dcd Tainted: P O 4.1.27 #2
Jul 7 18:38:59 kernel: Hardware name: Broadcom-v8A (DT)
Jul 7 18:38:59 kernel: task: ffffffc010e5ea40 ti: ffffffc00b5e0000 task.ti: ffffffc00b5e0000
Jul 7 18:38:59 kernel: PC is at 0x29d34
Jul 7 18:38:59 kernel: LR is at 0x29fb4
Jul 7 18:38:59 kernel: pc : [<0000000000029d34>] lr : [<0000000000029fb4>] pstate: 200f0010
Jul 7 18:38:59 kernel: sp : 00000000ffda54a0
Jul 7 18:38:59 kernel: x12: 00000000000a211c
Jul 7 18:38:59 kernel: x11: 0000000000081d6c x10: 0000000000000021
Jul 7 18:38:59 kernel: x9 : 0000000000000003 x8 : 0000000000000021
Jul 7 18:38:59 kernel: x7 : 00000000f5f043dc x6 : 0000000000000036
Jul 7 18:38:59 kernel: x5 : 0000000000000205 x4 : 00000000f5f0443c
Jul 7 18:38:59 kernel: x3 : 0000000000000000 x2 : 0000000000000020
Jul 7 18:38:59 kernel: x1 : 000000000000000b x0 : 0000000000000000
Jul 7 18:38:59 kernel: CPU: 1 PID: 4258 Comm: dcd Tainted: P O 4.1.27 #2
Jul 7 18:38:59 kernel: Hardware name: Broadcom-v8A (DT)
Jul 7 18:38:59 kernel: task: ffffffc010e5ea40 ti: ffffffc00b5e0000 task.ti: ffffffc00b5e0000
Jul 7 18:38:59 kernel: PC is at 0x29d34
Jul 7 18:38:59 kernel: LR is at 0x29fb4
Jul 7 18:38:59 kernel: pc : [<0000000000029d34>] lr : [<0000000000029fb4>] pstate: 200f0010
Jul 7 18:38:59 kernel: sp : 00000000ffda54a0
Jul 7 18:38:59 kernel: x12: 00000000000a211c
Jul 7 18:38:59 kernel: x11: 0000000000081d6c x10: 0000000000000021
Jul 7 18:38:59 kernel: x9 : 0000000000000003 x8 : 0000000000000021
Jul 7 18:38:59 kernel: x7 : 00000000f5f043dc x6 : 0000000000000036
Jul 7 18:38:59 kernel: x5 : 0000000000000205 x4 : 00000000f5f0443c
Jul 7 18:38:59 kernel: x3 : 0000000000000000 x2 : 0000000000000020
Jul 7 18:38:59 kernel: x1 : 000000000000000b x0 : 0000000000000000

Running top from the command line didn't show much, other than chrony consuming 17% of RAM as the highest reported process.

I just rebooted the router and went to bed since it was late and I wasn't in the mood to go chasing problems.

Second issue is ipv6 related.
Checking on the router this morning following the reboot, I noticed that my router hadn't acquired an ipv6 address from my ISP.

I disconnected the WAN and reconnected, and the router fetched the ipv6 address properly.

Jul 9 00:20:26 CakeQOS-Merlin: /jffs/addons/cake-qos/cake-qos (pid=3720) called in unattended mode with 1 args: startup
Jul 9 00:20:26 CakeQOS-Merlin: Applying iptables rules
Jul 9 00:20:26 CakeQOS-Merlin: Flushing conntrack table
Jul 9 00:20:36 crond[1151]: time disparity of 2196675 minutes detected
Jul 9 10:49:03 dnsmasq[3276]: interface br0 failed to join DHCPv6 multicast group: Address already in use
Jul 9 10:49:03 dnsmasq[3276]: interface eth0 failed to join DHCPv6 multicast group: Address already in use
Jul 9 10:49:07 dnsmasq[3276]: interface br0 failed to join DHCPv6 multicast group: Address already in use
Jul 9 10:49:07 dnsmasq[3276]: interface eth0 failed to join DHCPv6 multicast group: Address already in use
Jul 9 10:49:11 CakeQOS-Merlin: /jffs/addons/cake-qos/cake-qos (pid=4505) called in unattended mode with 1 args: startup
Jul 9 10:49:11 CakeQOS-Merlin: Applying iptables rules
Jul 9 10:49:11 kernel: bcm_mcast_mld_add:833 mc_fdb->rep_list ffffffc01287cea8 next ffffffc010a2a4e0 prev ffffffc010a2a4e0 rep_entry->list ffffffc010a2a4e0 next ffffffc01287cea8 prev ffffffc01287cea8
Jul 9 10:49:11 CakeQOS-Merlin: Flushing conntrack table
Jul 9 10:49:12 kernel: bcm_mcast_mld_add:833 mc_fdb->rep_list ffffffc010ac1f68 next ffffffc0144e7b60 prev ffffffc0144e7b60 rep_entry->list ffffffc0144e7b60 next ffffffc010ac1f68 prev ffffffc010ac1f68
Jul 9 10:49:26 miniupnpd[5505]: upnpevents_processfds: 0x5cc1a8, remove subscriber uuid:adcc00b4-e48c-451c-a76a-0d2923f8563f after an ERROR cb: http://192.168.0.80:2869/upnp/eventing/ximphnudcb
Jul 9 10:49:29 CakeQOS-Merlin: /jffs/addons/cake-qos/cake-qos (pid=5579) called in unattended mode with 1 args: startup
Jul 9 10:49:29 CakeQOS-Merlin: Applying iptables rules
Jul 9 10:49:30 CakeQOS-Merlin: Flushing conntrack table

The log from above was from the moment when I disconnected and reconnected my WAN connection. The connection had been up for about 11 hours following the reboot with no other errors reported in between.

I have had previous instances where the ipv6 address was not fetched correctly. I can't recall if it only happens after a cold reboot.

Can anyone suggest some extra diagnostic steps to work out what might have gone wrong?
 
A couple of problems that I have noticed recently.

I had noticed my RT-AC86U's RAM usage climbing after 11 days of uptime. I had not seen it do this in the previous firmware.

Logs showed a couple of process errors:
Jul 7 18:38:59 kernel: pgd = ffffffc00b7a6000
Jul 7 18:38:59 kernel: [00000000] *pgd=000000000abdd003, *pud=000000000abdd003, *pmd=0000000006400003, *pte=0000000000000000
Jul 7 18:38:59 kernel: CPU: 1 PID: 4258 Comm: dcd Tainted: P O 4.1.27 #2
Jul 7 18:38:59 kernel: Hardware name: Broadcom-v8A (DT)
Jul 7 18:38:59 kernel: task: ffffffc010e5ea40 ti: ffffffc00b5e0000 task.ti: ffffffc00b5e0000
Jul 7 18:38:59 kernel: PC is at 0x29d34
Jul 7 18:38:59 kernel: LR is at 0x29fb4
Jul 7 18:38:59 kernel: pc : [<0000000000029d34>] lr : [<0000000000029fb4>] pstate: 200f0010
Jul 7 18:38:59 kernel: sp : 00000000ffda54a0
Jul 7 18:38:59 kernel: x12: 00000000000a211c
Jul 7 18:38:59 kernel: x11: 0000000000081d6c x10: 0000000000000021
Jul 7 18:38:59 kernel: x9 : 0000000000000003 x8 : 0000000000000021
Jul 7 18:38:59 kernel: x7 : 00000000f5f043dc x6 : 0000000000000036
Jul 7 18:38:59 kernel: x5 : 0000000000000205 x4 : 00000000f5f0443c
Jul 7 18:38:59 kernel: x3 : 0000000000000000 x2 : 0000000000000020
Jul 7 18:38:59 kernel: x1 : 000000000000000b x0 : 0000000000000000
Jul 7 18:38:59 kernel: CPU: 1 PID: 4258 Comm: dcd Tainted: P O 4.1.27 #2
Jul 7 18:38:59 kernel: Hardware name: Broadcom-v8A (DT)
Jul 7 18:38:59 kernel: task: ffffffc010e5ea40 ti: ffffffc00b5e0000 task.ti: ffffffc00b5e0000
Jul 7 18:38:59 kernel: PC is at 0x29d34
Jul 7 18:38:59 kernel: LR is at 0x29fb4
Jul 7 18:38:59 kernel: pc : [<0000000000029d34>] lr : [<0000000000029fb4>] pstate: 200f0010
Jul 7 18:38:59 kernel: sp : 00000000ffda54a0
Jul 7 18:38:59 kernel: x12: 00000000000a211c
Jul 7 18:38:59 kernel: x11: 0000000000081d6c x10: 0000000000000021
Jul 7 18:38:59 kernel: x9 : 0000000000000003 x8 : 0000000000000021
Jul 7 18:38:59 kernel: x7 : 00000000f5f043dc x6 : 0000000000000036
Jul 7 18:38:59 kernel: x5 : 0000000000000205 x4 : 00000000f5f0443c
Jul 7 18:38:59 kernel: x3 : 0000000000000000 x2 : 0000000000000020
Jul 7 18:38:59 kernel: x1 : 000000000000000b x0 : 0000000000000000

Running top from the command line didn't show much, other than chrony consuming 17% of RAM as the highest reported process.

I just rebooted the router and went to bed since it was late and I wasn't in the mood to go chasing problems.

Second issue is ipv6 related.
Checking on the router this morning following the reboot, I noticed that my router hadn't acquired an ipv6 address from my ISP.

I disconnected the WAN and reconnected, and the router fetched the ipv6 address properly.

Jul 9 00:20:26 CakeQOS-Merlin: /jffs/addons/cake-qos/cake-qos (pid=3720) called in unattended mode with 1 args: startup
Jul 9 00:20:26 CakeQOS-Merlin: Applying iptables rules
Jul 9 00:20:26 CakeQOS-Merlin: Flushing conntrack table
Jul 9 00:20:36 crond[1151]: time disparity of 2196675 minutes detected
Jul 9 10:49:03 dnsmasq[3276]: interface br0 failed to join DHCPv6 multicast group: Address already in use
Jul 9 10:49:03 dnsmasq[3276]: interface eth0 failed to join DHCPv6 multicast group: Address already in use
Jul 9 10:49:07 dnsmasq[3276]: interface br0 failed to join DHCPv6 multicast group: Address already in use
Jul 9 10:49:07 dnsmasq[3276]: interface eth0 failed to join DHCPv6 multicast group: Address already in use
Jul 9 10:49:11 CakeQOS-Merlin: /jffs/addons/cake-qos/cake-qos (pid=4505) called in unattended mode with 1 args: startup
Jul 9 10:49:11 CakeQOS-Merlin: Applying iptables rules
Jul 9 10:49:11 kernel: bcm_mcast_mld_add:833 mc_fdb->rep_list ffffffc01287cea8 next ffffffc010a2a4e0 prev ffffffc010a2a4e0 rep_entry->list ffffffc010a2a4e0 next ffffffc01287cea8 prev ffffffc01287cea8
Jul 9 10:49:11 CakeQOS-Merlin: Flushing conntrack table
Jul 9 10:49:12 kernel: bcm_mcast_mld_add:833 mc_fdb->rep_list ffffffc010ac1f68 next ffffffc0144e7b60 prev ffffffc0144e7b60 rep_entry->list ffffffc0144e7b60 next ffffffc010ac1f68 prev ffffffc010ac1f68
Jul 9 10:49:26 miniupnpd[5505]: upnpevents_processfds: 0x5cc1a8, remove subscriber uuid:adcc00b4-e48c-451c-a76a-0d2923f8563f after an ERROR cb: http://192.168.0.80:2869/upnp/eventing/ximphnudcb
Jul 9 10:49:29 CakeQOS-Merlin: /jffs/addons/cake-qos/cake-qos (pid=5579) called in unattended mode with 1 args: startup
Jul 9 10:49:29 CakeQOS-Merlin: Applying iptables rules
Jul 9 10:49:30 CakeQOS-Merlin: Flushing conntrack table

The log from above was from the moment when I disconnected and reconnected my WAN connection. The connection had been up for about 11 hours following the reboot with no other errors reported in between.

I have had previous instances where the ipv6 address was not fetched correctly. I can't recall if it only happens after a cold reboot.

Can anyone suggest some extra diagnostic steps to work out what might have gone wrong?
Well... if you read some past posts:

1. RAM cleanup code has changed, the ram high usage doesn't represent a bad behavior per se, as long as there is no issues with the normal operation.
2. IPv6 issue was noted by some others and there is a beta-test release in past pages that seems to fix it.
 
Screenshot 2022-07-08 at 22-50-03 ASUS Wireless Router GT-AX11000 - Internet Speed.png



GT-AX11000 nothing important. Cosmetic error, but it would definitely be easier to run the speed test if the display area is larger. :)
 
Since 386.7 on my ax-88u i have problems with my sip-provider. Phone is registered at the provider but calling is not possible (Connection broken). Downgrade to 386.5_2 solved my problem. Any ideas what could be the reason for this behaviour?
 
Last edited:
Well, my ISP is "Partner" from Israel
it's configures as automatic ip in WAN and native in IPV6
with AsusWRT the prefix size is 56
with MerlinWRT i've tried 64 (default) and 56
with the new version - still can't get IPV6 address
and no "WAN Prefix Size Requested:" in system log
Just to make sure you are use a test build from here, as the "WAN Prefix Size" are in the current 386.7 builds?

You could also toggle the "Release Prefix on Exit" to "disable" to see if your ISP will release/renew your IPv6 prefix.

Not cloning your WAN MAC are you?
Maybe try changing it as a temp test to get a new DUID?
 
Thanks for the reports concerning IPv6. However I'm mostly interested in hearing from people who had connectivity issue starting with 386.7 to see if the change fixes it for them or not. If your IPv6 was already working, then the changes won't affect that.

I will try and disable IPv6 to see if it works better.
I have an issue with the latest version where wifi drops out randomly and a lot.
But cable is 100% stable.
Intermittent loss of Wi-Fi since upgrading to 386.7 | Page 6 | SmallNetBuilder Forums (snbforums.com)
 
Well... if you read some past posts:

1. RAM cleanup code has changed, the ram high usage doesn't represent a bad behavior per se, as long as there is no issues with the normal operation.
2. IPv6 issue was noted by some others and there is a beta-test release in past pages that seems to fix it.
Ahh, thanks for the heads up on the IPv6. I admit, I had been skimming the thread this week, and had seen reports of IPv6 related issues, but had missed the test build. I will tray that out.

As for the normal operation, I think I am seeing the router killing processes there, so that doesn't seem ideal. It might look all roses from the GUI, but if the new RAM cleanup code isn't cleaning up fast enough to avoid memory exhaustion, then I would think there is a problem.
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

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