Release Asuswrt-Merlin 386.7 is now available for all models

[Wade Coxon]

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.

The 386.7_1 test build doesn't appear to have resolved my specific problem. I just installed, and checked and had no IPv6 address.

Waited two minutes, and restarted the WAN, and received addresses from my ISP.

 

[ColinTaylor]

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.

There isn't any "new RAM cleanup code". What changed was the unnecessary flushing of the cache each time you logged into the GUI. If you're seeing processes being killed it's unrelated to this change.

 

[omrij]

Just to make sure you are use a test build from here, as the "WAN Prefix Size" are in the current 386.7 builds?

OneDrive

www.asuswrt-merlin.net

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?

Yes, I used this specific test build
No Mac clone in my config
Thanks for trying to help, much appreciated.

 

[eclp]

View attachment 42596


GT-AX11000 nothing important. Cosmetic error, but it would definitely be easier to run the speed test if the display area is larger.

Cleared browser cache or tried a different browser?

 

[eclp]

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:

Spoiler: Log Error

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.

Spoiler: WAN Restart

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?

Because of the dcd tainted error, it helps to factory reset the router and start over. The error is triggered by AiProtection. Alternatively, you can disable and revoke AiProtection.

 

[Kingp1n]

Just curios for those who are having IPV6 issues have the same problem when using the original latest firmware?

 

[Phariex]

Hi,

Do you know if a firmware for the ZenWiFi Pro ET12 is in the pipeline for future development? Thx!

 

[bennor]

Hi,

Do you know if a firmware for the ZenWiFi Pro ET12 is in the pipeline for future development? Thx!

[FAQ] READ ME FIRST before posting a question

Model support Q: Will you support the RT-xxxxxx that was just announced? A: See detailed answer in post #3. Q: Will you support router XYZ from this non-Asus manufacturer? A: No. Asuswrt-Merlin only targets Asus-supported models, due to both technical and legal reasons. Q: I'm having...

www.snbforums.com

 

[Wade Coxon]

There isn't any "new RAM cleanup code". What changed was the unnecessary flushing of the cache each time you logged into the GUI. If you're seeing processes being killed it's unrelated to this change.

Thanks for that explanation As for the terminology, I was just quoting back Kyo using their own term .

 

[Damit1]

@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.

My connection is DHCP, not PPoE
It is working flawlessly in 5.2 FW, obtained IPv6 in about 10 sec since router boot.
I guess it is not specifically related to my ISP at this matter anyway, I guess it is a change done in new FW

 

[Damit1]

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.

Which changes are done?
What did I miss?

 

[RMerlin]

Which changes are done?
What did I miss?

The 386.7_1 test build now lets the ISP decide on the prefix length (by requesting a length of 0) rather than enforcing a prefix of 64. This reverts to the previous behaviour, and is also what stock firmware currently does.

 

[Darkje]

The 386.7_1 test build now lets the ISP decide on the prefix length (by requesting a length of 0) rather than enforcing a prefix of 64. This reverts to the previous behaviour, and is also what stock firmware currently does.

It works properly here now.

 

[Howard_inGA]

The 386.7_1 test build now lets the ISP decide on the prefix length (by requesting a length of 0) rather than enforcing a prefix of 64. This reverts to the previous behaviour, and is also what stock firmware currently does.

So I tried the test build, but got really bad degradation of overall security and no increase in IPv6 connectivity scores as follows:
*-Total fail of rootcanary test ( https://rootcanary.org/test.html )
*-Failed DNSSEC Resolver Test ( https://dnssec.vs.uni-due.de/ )
*-Failure of DNSSEC secure ( http://0skar.cz/dns/en/ )
*-When IPv6 off, using Nord VPN selected in the router, my local DNS was not cloaked!?! There were no DNS leaks, but where I'm located via DNS is
apparent. ( https://www.dnsleaktest.com/ )
-No improvement of IPv6 Connection test result of 50% ( https://en.internet.nl/connection/b971c895c5b6455a9c1735c27a7ed70f/results#control-panel-5 )
-IPv6 test scores remained at 17/20 ( https://ipv6-test.com/ )
(NOTE: Critical issues marked with *)
I went back to the stable release and all these issues disappeared. I don't know what is up, but I think I'm parking it here until some of the more skilled operators are able to see why this behavior is part of the test release.

 

[Damit1]

The 386.7_1 test build now lets the ISP decide on the prefix length (by requesting a length of 0) rather than enforcing a prefix of 64. This reverts to the previous behaviour, and is also what stock firmware currently does.

Ok
From initial test it seems OK.

I did test it now for a short period of time:
Ipv6 is obtained easily- takes about 3 mins, but works without any intervention of mine- in 368 5 2 it takes about 1.5 mins- I do not know if it matters but I put it here .
My ring had difficulties woriking In 386_7 1 it did not work at all, here it works.

WIll have to further test it- but for 2 inital reboots in 15 mins it works.

WIll do further tests and WIILL update.

 

[RMerlin]

So I tried the test build, but got really bad degradation of overall security

That makes absolutely no sense, because nothing was changed regarding DNS handling. Just the size of the requested prefix.

Are you using DNSFilter?

 

[RMerlin]

From initial test it seems OK.

It works properly here now.

Thanks for the feedback.

 

[omrij]

Should I leave the prefix size empty with this build?

 

[RMerlin]

Should I leave the prefix size empty with this build?

Prefix should be left empty unless your ISP requires you to specify the prefix rather than let them automatically decide it for you.

This setting is only for special cases.

 

[Damit1]

Thanks for the feedback.

Thank you for all your hard work!
It only would be fair to feedback here for all the hard work you put here.

Will test its stability for couple of days and feedback any further