ASUS RT-AC86U firmware release 3.0.0.4.384.45149 12/05/2018

[universe83]

Buy the RT-AC86u 5 days ago and when turning on the router, IPv6 works correctly for a few minutes, then it does not work.?
When IPv6 works the routing table shows the default route (WAN IPv6 Gateway), when IPv6 stops working the line with the default route (WAN IPv6 Gateway) disappears.

All this happens in official firmware. versions: 3.0.0.4.384.45149, 3.0.0.4.384.32799, I do not know if in previous versions it happens.
Also try the latest version of Asus merlin and the same thing happens.

(Excuse my language, my native language is Spanish)

Update 1:
My internet connection is VDSL2 50mbps down / 10mbps up.
My configuration is as follows: ISP -> Modem Huawei HG659 (In bridge mode) -> Asus RT-AC86U.
My ISP is DualStack (IPv4/IPv6), IPv6 Connection Type: Native with DHCP-PD

Update 2019-01-04:
After 1 month of testing, now I know when the problem occurs, when turning on the router for 31 minutes the devices in my network can access IPv6 sites (https://ipv6.google.com), the router can never reach IPv6 sites (probe from router GUI -> Network tools -> Network analisys -> Ping to ipv6.google.com)
After 31 minutes default route (WAN IPv6 Gateway) disappears.

Contact asus support and after several emails and tests they said:
"We found that the default gateway was removed caused by timeout occurred, we need to check if the router get the extended time packet"

And they sent me a beta of a firmware with tcpdump enabled and the command: tcpdump -i eth0 -w /tmp/wan0.pcap -s 1500

I sent them the file with the data and then they said:
"According to the information you provide, Our Enginner think it cause by RFC 4861 (https://tools.ietf.org/html/rfc4861) Section 4.2 Router Advertisement Message Format A: A lifetime of 0 indicates that the router is not to default router and SHOULD NOT appear on the default router list "

They made some changes to the firmware and they sent it to me, now IPv6 works correctly all the time, the funny thing is that in System log-> IPv6, WAN IPv6 Address: Always is empty

I told them that IPv6 was now working correctly with the modified firmware and they said:
"We use some workaround to deal with IPv6 Packet in your environment, it seems the ISP you used, IPv6 action didn't similar to most of ISP (after analysis the packet you provided), so we use this method."

But they do not know when the patch will be in the official firmware because according to them it is a problem that only happens with my ISP, I think it happens in more ISPs but the users have not noticed, firstly because IPv6 is disabled by default, and in the second because many ISPs are just beginning the IPv6 deployment, my ISP in 1 year went from 4% to 25% of IPv6 deployment.

Looking in the forum I see similar issues to mine (I think i´m not alone):
https://www.snbforums.com/threads/wan-ipv6-gateway-problem-fix.54199/​

 

[universe83]

Buy the RT-AC86u 5 days ago and when turning on the router, IPv6 works correctly for a few minutes, then it does not work.?
When IPv6 works the routing table shows the default route (WAN IPv6 Gateway), when IPv6 stops working the line with the default route (WAN IPv6 Gateway) disappears.

All this happens in official firmware. versions: 3.0.0.4.384.45149, 3.0.0.4.384.32799, I do not know if in previous versions it happens.
Also try the latest version of Asus merlin and the same thing happens.

(Excuse my language, my native language is Spanish)

Update 1:
My internet connection is VDSL2 50mbps down / 10mbps up.
My configuration is as follows: ISP -> Modem Huawei HG659 (In bridge mode) -> Asus RT-AC86U.
My ISP is DualStack (IPv4/IPv6), IPv6 Connection Type: Native with DHCP-PD

 

[ablatt]

When IPv6 stops working like that, what do you do to get it working again? Do you have reboot?

I have the RT-AC86U with the same firmware and haven't seen the problem - YET.

 

[universe83]

When IPv6 stops working like that, what do you do to get it working again? Do you have reboot?

I have the RT-AC86U with the same firmware and haven't seen the problem - YET.

Yes, I reboot the router and IPv6 works again for a few minutes

 

[ablatt]

Yes, I reboot the router and IPv6 works again for a few minutes

Are you sure your IPv6 settings in the router are correct for your ISP?

 

[CriticJay]

How can I roll back to 32799? Any special procedure? Is factory reset recommended?

 

[heidarren]

There r not many options in IPv6 page, try all combinations won’t take u whole day, or make a call to ur ISP to get the correct IPv6 connection method

 

[CriticJay]

There r not many options in IPv6 page, try all combinations won’t take u whole day, or make a call to ur ISP to get the correct IPv6 connection method

For me, my IPv6 is configured correctly as per my ISP. The "crash" I described only started happening with yesterday's firmware. And every time it crashes it takes down my IPv6 connection.

 

[universe83]

Are you sure your IPv6 settings in the router are correct for your ISP?

I am completely sure, I have another router asus model RT-AC66U_B1 with the same ISP, IPv6 works without problem

 

[universe83]

There r not many options in IPv6 page, try all combinations won’t take u whole day, or make a call to ur ISP to get the correct IPv6 connection method

If I put my other router Asus RT-AC66U_B1 IPv6 works without problem. same ISP, same line, same configuration.

 

[whitey019]

Whatever my AiMesh problem was yesterday has mysteriously cured itself. I was going to sit down and begin another troubleshooting session and it just worked. I did absolutely nothing, but turn the plug the 68U back in and turn it on. I had power cycled (15secs) numerous times last night...so IDK!

 

[ablatt]

If I put my other router Asus RT-AC66U_B1 IPv6 works without problem. same ISP, same line, same configuration.

Did you reset/initialize the router?

 

[universe83]

Did you reset/initialize the router?

Yes, i did

 

[giant25]

Critic,

Your sentiment might be diluted by your over-reaction. I am not using IPv6, and this firmware so far seems to be better (86U router, 2x 68U nodes). Your "avoid" advice directed at users like me is therefore inaccurate.

The client list on this new firmware is still a bit of a mess.

Improvements: it now resolves names, and chooses appropriate icons.
Backwards steps: the number of clients jumps all over the place, every few seconds. One moment 8 clients, the next moment 24. Impossible to read and use.
Same old: Wired clients on DHCP appear as "static".

I see the number of clients in the client list jump all over the place just like you describe since going to this latest FW 2 days ago. I also see a constant "Assoc" and "Disassoc" messages with a MAC address appended to each within the system Log every 5-10 min. Not sure if there's a relation.

 

[tallytr]

I have the same/similar on mine but soft crashing? No, working great.
Mesh node (RT-AC86U) more stable client connection.




4QUOTE="CriticJay, post: 448085, member: 59039"]Yes. Please see this:

Dec 7 07:49:15 kernel: pgd = ffffffc00ae8b000
Dec 7 07:49:15 kernel: [00000000] *pgd=000000001253c003, *pud=000000001253c003, *pmd=000000000af31003, *pte=0000000000000000
Dec 7 07:49:15 kernel: CPU: 1 PID: 23051 Comm: dcd Tainted: P O 4.1.27 #2
Dec 7 07:49:15 kernel: Hardware name: Broadcom-v8A (DT)
Dec 7 07:49:15 kernel: task: ffffffc0170f54c0 ti: ffffffc00ae58000 task.ti: ffffffc00ae58000
Dec 7 07:49:15 kernel: PC is at 0xf7169f44
Dec 7 07:49:15 kernel: LR is at 0x1dc74
Dec 7 07:49:15 kernel: pc : [<00000000f7169f44>] lr : [<000000000001dc74>] pstate: 80070010
Dec 7 07:49:15 kernel: sp : 00000000fff85f28
Dec 7 07:49:15 kernel: x12: 000000000009ff10
Dec 7 07:49:15 kernel: x11: 00000000f63ff024 x10: 00000000000a0766
Dec 7 07:49:15 kernel: x9 : 0000000000000028 x8 : 00000000000a076c
Dec 7 07:49:15 kernel: x7 : 0000000000000028 x6 : 00000000f63ffd54
Dec 7 07:49:15 kernel: x5 : 0000000000000000 x4 : 00000000f63ffcf0
Dec 7 07:49:15 kernel: x3 : 00000000f63ffd7c x2 : 00000000ffffffff
Dec 7 07:49:15 kernel: x1 : 000000000007c674 x0 : 0000000000000000[/QUOTE]

 

[RMerlin]

Yes. Please see this:

Dec 7 07:49:15 kernel: pgd = ffffffc00ae8b000
Dec 7 07:49:15 kernel: [00000000] *pgd=000000001253c003, *pud=000000001253c003, *pmd=000000000af31003, *pte=0000000000000000
Dec 7 07:49:15 kernel: CPU: 1 PID: 23051 Comm: dcd Tainted: P O 4.1.27 #2
Dec 7 07:49:15 kernel: Hardware name: Broadcom-v8A (DT)
Dec 7 07:49:15 kernel: task: ffffffc0170f54c0 ti: ffffffc00ae58000 task.ti: ffffffc00ae58000
Dec 7 07:49:15 kernel: PC is at 0xf7169f44
Dec 7 07:49:15 kernel: LR is at 0x1dc74
Dec 7 07:49:15 kernel: pc : [<00000000f7169f44>] lr : [<000000000001dc74>] pstate: 80070010
Dec 7 07:49:15 kernel: sp : 00000000fff85f28
Dec 7 07:49:15 kernel: x12: 000000000009ff10
Dec 7 07:49:15 kernel: x11: 00000000f63ff024 x10: 00000000000a0766
Dec 7 07:49:15 kernel: x9 : 0000000000000028 x8 : 00000000000a076c
Dec 7 07:49:15 kernel: x7 : 0000000000000028 x6 : 00000000f63ffd54
Dec 7 07:49:15 kernel: x5 : 0000000000000000 x4 : 00000000f63ffcf0
Dec 7 07:49:15 kernel: x3 : 00000000f63ffd7c x2 : 00000000ffffffff
Dec 7 07:49:15 kernel: x1 : 000000000007c674 x0 : 0000000000000000

The dcd process crashed. This is a component of the Trend Micro engine (no idea what it handles specifically).

Pinging @vanic on this one.

 

[hjzwiers]

Same here, comes and goes ...... Never seen this before this firmware upgrade


Dec 8 10:10:48 kernel: pgd = ffffffc009b2c000
Dec 8 10:10:48 kernel: [00000000] *pgd=0000000010dc2003, *pud=0000000010dc2003, *pmd=0000000015763003, *pte=0000000000000000
Dec 8 10:10:48 kernel: CPU: 1 PID: 2713 Comm: dcd Tainted: P O 4.1.27 #2
Dec 8 10:10:48 kernel: Hardware name: Broadcom-v8A (DT)
Dec 8 10:10:48 kernel: task: ffffffc013d4d440 ti: ffffffc00c364000 task.ti: ffffffc00c364000
Dec 8 10:10:48 kernel: PC is at 0xf73f5f44
Dec 8 10:10:48 kernel: LR is at 0x1dc74
Dec 8 10:10:48 kernel: pc : [<00000000f73f5f44>] lr : [<000000000001dc74>] pstate: 600e0010
Dec 8 10:10:48 kernel: sp : 00000000ff90e278
Dec 8 10:10:48 kernel: x12: 000000000009ff10
Dec 8 10:10:48 kernel: x11: 00000000f66ff024 x10: 00000000000a02b4
Dec 8 10:10:48 kernel: x9 : 00000000f66ff990 x8 : 00000000000a076c
Dec 8 10:10:48 kernel: x7 : 00000000f66ff9c0 x6 : 00000000000a0766
Dec 8 10:10:48 kernel: x5 : 0000000000000000 x4 : 00000000f66ff974
Dec 8 10:10:48 kernel: x3 : 0000000000000000 x2 : 0000000000000000
Dec 8 10:10:48 kernel: x1 : 000000000007c674 x0 : 0000000000000000

Dec 8 10:30:26 kernel: pgd = ffffffc00bf76000
Dec 8 10:30:26 kernel: [00000000] *pgd=0000000008e8c003, *pud=0000000008e8c003, *pmd=0000000007887003, *pte=0000000000000000
Dec 8 10:30:26 kernel: CPU: 1 PID: 3346 Comm: dcd Tainted: P O 4.1.27 #2
Dec 8 10:30:26 kernel: Hardware name: Broadcom-v8A (DT)
Dec 8 10:30:26 kernel: task: ffffffc0151ed5c0 ti: ffffffc008e58000 task.ti: ffffffc008e58000
Dec 8 10:30:26 kernel: PC is at 0xf74f4f44
Dec 8 10:30:26 kernel: LR is at 0x1dc74
Dec 8 10:30:26 kernel: pc : [<00000000f74f4f44>] lr : [<000000000001dc74>] pstate: 600e0010
Dec 8 10:30:26 kernel: sp : 00000000ffdeb308
Dec 8 10:30:26 kernel: x12: 000000000009ff10
Dec 8 10:30:26 kernel: x11: 00000000f67ff024 x10: 00000000000a02b4
Dec 8 10:30:26 kernel: x9 : 00000000f67ff990 x8 : 00000000000a076c
Dec 8 10:30:26 kernel: x7 : 00000000f67ff9c0 x6 : 00000000000a0766
Dec 8 10:30:26 kernel: x5 : 0000000000000000 x4 : 00000000f67ff974
Dec 8 10:30:26 kernel: x3 : 0000000000000000 x2 : 0000000000000000
Dec 8 10:30:26 kernel: x1 : 000000000007c674 x0 : 0000000000000000

Dec 8 10:37:56 kernel: pgd = ffffffc012ebf000
Dec 8 10:37:56 kernel: [00000000] *pgd=000000000be7f003, *pud=000000000be7f003, *pmd=00000000153d2003, *pte=0000000000000000
Dec 8 10:37:56 kernel: CPU: 1 PID: 4172 Comm: dcd Tainted: P O 4.1.27 #2
Dec 8 10:37:56 kernel: Hardware name: Broadcom-v8A (DT)
Dec 8 10:37:56 kernel: task: ffffffc013cd0b80 ti: ffffffc00bf40000 task.ti: ffffffc00bf40000
Dec 8 10:37:56 kernel: PC is at 0xf6f7df44
Dec 8 10:37:56 kernel: LR is at 0x1dc74
Dec 8 10:37:56 kernel: pc : [<00000000f6f7df44>] lr : [<000000000001dc74>] pstate: 600e0010
Dec 8 10:37:56 kernel: sp : 00000000ffbd7668
Dec 8 10:37:56 kernel: x12: 000000000009ff10
Dec 8 10:37:56 kernel: x11: 00000000f62ff024 x10: 00000000000a02b4
Dec 8 10:37:56 kernel: x9 : 00000000f62ff990 x8 : 00000000000a076c
Dec 8 10:37:56 kernel: x7 : 00000000f62ff9c0 x6 : 00000000000a0766
Dec 8 10:37:56 kernel: x5 : 0000000000000000 x4 : 00000000f62ff974
Dec 8 10:37:56 kernel: x3 : 0000000000000000 x2 : 0000000000000000
Dec 8 10:37:56 kernel: x1 : 000000000007c674 x0 : 0000000000000000

 

[CriticJay]

The dcd process crashed. This is a component of the Trend Micro engine (no idea what it handles specifically).

Pinging @vanic on this one.

Thanks Merlin. I actually just did a full factory reset and this time I did not enable Adaptive QoS or any other Trend Micro features. So far, no crashing and no loss of IPv6. I will amend my original post with that information.

 

[Gitsum]

Seems to be happening on all forms of ASUS hardware regardless of stock or Merlin. Must be the TrendMicro 2.100 signature version update.

 

[tallytr]

Seems to be happening on all forms of ASUS hardware regardless of stock or Merlin. Must be the TrendMicro 2.100 signature version update.

I did not factory reset my two (2) RT-AC86U's for 3.0.0.4.384.45149, thought as long as it is 3.0.0.4.384 one wouldn't need to, and I hate nothing more than having to factory reset those boxes

I really like that my clients that I thought should stick to the node (Ethernet) are now actually sticking to the node.
I have the router in the basement and wired AiMesh node upstairs (2nd floor), before more clients would stick to the router...and I am really only using the AiMesh node upstairs...