ASUS RT-AC86U firmware release 3.0.0.4.384.45713

[L&LD]

Thanks, Does the login password change when you reset?

Yes. But you shouldn't need it. The setup wizard should kick in and make you set it up again.

 

[VANT]

A node can be added wirelessly. But when you remove the node, you have to use a cable like I did.

not exactly. You can reset node to factory default by reset button and then add as node or config as router etc. by wifi (default asus ssid You should see for both band) . Cable is not neccesary.

is anyone 5GHZ band still disappearing on this firmware or that been fixed. as it was big problem for me the 5ghz band dropping for no reason.

i have some problems with 5GHz band, but i analyse it for now.

 

[Lotta Cox]

not exactly. You can reset node to factory default by reset button and then add as node or config as router etc. by wifi (default asus ssid You should see for both band) . Cable is not neccesary.

Yes, of course. I forgot all about that. (˵ ͡° ͜ʖ ͡°˵)

 

[William Paul Shivers]

Seems 3.0.0.4.384_45713 is causing a problem with AiMesh hooking up between my two AC3100. Updated firmware last night and I can no longer see or acquire my AiMesh Node. I've done a reset, a Hard Reset, then again a hard reset followed by a reset.

Aimesh Scan finds the node, gets to 100% of then AiMesh install process and just stops, Node is then no longer visible on network or accessible.

I did hard reset node in question and used it successfully as a regular router as a test, but I can no longer use it as a Node on AiMesh...

Confirmed that both AC3100 are running 3.0.0.4.384_45713...

I have run out of ideas...

Update:
In the amount time it took to create an account here and document the problem I was seeing, my AiMesh network updated and the node is working as it should after I rebooted the node one more time....

I'm so glad I retired from IT after 42 years.... lol

 

[universe83]

Please, someone with IPV6 can ping: ipv6.google.com from the router,
in my case the router can not reach IPv6 sites, on the devices it seems to work well.

UPDATE 1:
This issue occurs with the following configuration:
VDSL modem in Bridge mode ->
AC86U WAN Connection type: PPPoE and IPv6 connection type: Native

IPv6 works correctly with the following configuration:
Modem VDSL in Router mode ->
AC86U WAN Connection type: Automatic IP and IPv6 connection type: Passthrough

UPDATE 2:
I think the issue is not the asus firmware, it is from my ISP (TELMEX - Infinitum - Mexico) the IPv6 address assigned to the router starts with fc00: this is not routable on the internet, in my case it should start with 2806: that it is routable on the internet (check attached image)

 

[Gingernut]

Still getting the occasional kernel fault:

Apr 24 09:46:26 kernel: asus_lighttpd[20204]: unhandled level 2 translation fault (11) at 0x338c5328, esr 0x92000006
Apr 24 09:46:26 kernel: pgd = ffffffc008618000
Apr 24 09:46:26 kernel: [338c5328] *pgd=000000001e86e003, *pud=000000001e86e003, *pmd=0000000000000000
Apr 24 09:46:26 kernel: CPU: 0 PID: 20204 Comm: asus_lighttpd Tainted: P           O    4.1.27 #2
Apr 24 09:46:26 kernel: Hardware name: Broadcom-v8A (DT)
Apr 24 09:46:26 kernel: task: ffffffc01927ca80 ti: ffffffc007834000 task.ti: ffffffc007834000
Apr 24 09:46:26 kernel: PC is at 0xf7208f84
Apr 24 09:46:26 kernel: LR is at 0xf7208f28
Apr 24 09:46:26 kernel: pc : [<00000000f7208f84>] lr : [<00000000f7208f28>] pstate: 20000010
Apr 24 09:46:26 kernel: sp : 00000000fffc0738
Apr 24 09:46:26 kernel: x12: 00000000336b544d
Apr 24 09:46:26 kernel: x11: 0000000000000000 x10: 00000000001a9058
Apr 24 09:46:26 kernel: x9 : 000000000021e884 x8 : 0000000000000000
Apr 24 09:46:26 kernel: x7 : 0000000000000056 x6 : 00000000f72561c4
Apr 24 09:46:26 kernel: x5 : 000000000020fee0 x4 : 00000000fffc0740
Apr 24 09:46:26 kernel: x3 : 00000000338c5324 x2 : 00000000f725a088
Apr 24 09:46:26 kernel: x1 : 00000000336b544c x0 : 000000000020fed8

 

[CriticJay]

Still getting the occasional kernel fault:

Apr 24 09:46:26 kernel: asus_lighttpd[20204]: unhandled level 2 translation fault (11) at 0x338c5328, esr 0x92000006
Apr 24 09:46:26 kernel: pgd = ffffffc008618000
Apr 24 09:46:26 kernel: [338c5328] *pgd=000000001e86e003, *pud=000000001e86e003, *pmd=0000000000000000
Apr 24 09:46:26 kernel: CPU: 0 PID: 20204 Comm: asus_lighttpd Tainted: P           O    4.1.27 #2
Apr 24 09:46:26 kernel: Hardware name: Broadcom-v8A (DT)
Apr 24 09:46:26 kernel: task: ffffffc01927ca80 ti: ffffffc007834000 task.ti: ffffffc007834000
Apr 24 09:46:26 kernel: PC is at 0xf7208f84
Apr 24 09:46:26 kernel: LR is at 0xf7208f28
Apr 24 09:46:26 kernel: pc : [<00000000f7208f84>] lr : [<00000000f7208f28>] pstate: 20000010
Apr 24 09:46:26 kernel: sp : 00000000fffc0738
Apr 24 09:46:26 kernel: x12: 00000000336b544d
Apr 24 09:46:26 kernel: x11: 0000000000000000 x10: 00000000001a9058
Apr 24 09:46:26 kernel: x9 : 000000000021e884 x8 : 0000000000000000
Apr 24 09:46:26 kernel: x7 : 0000000000000056 x6 : 00000000f72561c4
Apr 24 09:46:26 kernel: x5 : 000000000020fee0 x4 : 00000000fffc0740
Apr 24 09:46:26 kernel: x3 : 00000000338c5324 x2 : 00000000f725a088
Apr 24 09:46:26 kernel: x1 : 00000000336b544c x0 : 000000000020fed8

looks like it's with the HTTP Daemon (server/service) - not the "dcd" component as per the previous firmwares (which was related to Trend Micro code)

 

[OzarkEdge]

Still getting the occasional kernel fault:

Apr 24 09:46:26 kernel: asus_lighttpd[20204]: unhandled level 2 translation fault (11) at 0x338c5328, esr 0x92000006
Apr 24 09:46:26 kernel: pgd = ffffffc008618000
Apr 24 09:46:26 kernel: [338c5328] *pgd=000000001e86e003, *pud=000000001e86e003, *pmd=0000000000000000
Apr 24 09:46:26 kernel: CPU: 0 PID: 20204 Comm: asus_lighttpd Tainted: P           O    4.1.27 #2
Apr 24 09:46:26 kernel: Hardware name: Broadcom-v8A (DT)
Apr 24 09:46:26 kernel: task: ffffffc01927ca80 ti: ffffffc007834000 task.ti: ffffffc007834000
Apr 24 09:46:26 kernel: PC is at 0xf7208f84
Apr 24 09:46:26 kernel: LR is at 0xf7208f28
Apr 24 09:46:26 kernel: pc : [<00000000f7208f84>] lr : [<00000000f7208f28>] pstate: 20000010
Apr 24 09:46:26 kernel: sp : 00000000fffc0738
Apr 24 09:46:26 kernel: x12: 00000000336b544d
Apr 24 09:46:26 kernel: x11: 0000000000000000 x10: 00000000001a9058
Apr 24 09:46:26 kernel: x9 : 000000000021e884 x8 : 0000000000000000
Apr 24 09:46:26 kernel: x7 : 0000000000000056 x6 : 00000000f72561c4
Apr 24 09:46:26 kernel: x5 : 000000000020fee0 x4 : 00000000fffc0740
Apr 24 09:46:26 kernel: x3 : 00000000338c5324 x2 : 00000000f725a088
Apr 24 09:46:26 kernel: x1 : 00000000336b544c x0 : 000000000020fed8

So, you are not running Merlin per your sig?

My Log is super quiet... using Guest Networks, AiProtection, and USB HDD local. What General features are you using, if any?

OE

 

[RMerlin]

looks like it's with the HTTP Daemon (server/service) - not the "dcd" component as per the previous firmwares (which was related to Trend Micro code)

asus_lighttpd is probably Download Master, not a firmware component.

 

[Gingernut]

asus_lighttpd is probably Download Master, not a firmware component.

Correct, decided to give download master another try and it seems that when changing some of it's settings this causes it to crash but not always.

Apart from that occasional kernel fault the log is clean.

I'm running Merlin's latest alpha 4 and is running great and with nothing to report.

 

[kibosh]

Is Merlin's latest alpha based on 3.0.0.4.384.45713?

 

[CriticJay]

Is Merlin's latest alpha based on 3.0.0.4.384.45713?

Alpha 4 is.

 

[L&LD]

Is Merlin's latest alpha based on 3.0.0.4.384.45713?

Not all models.

 

[tallytr]

I have no faults at all in my log and that after a week, to me this seems to be the best firmware yet.

 

[WET]

Are dcd crashes still happening for those using Trend Micro with this firmware? I wish to know if 3.0.0.4.384.45713 fixed the dcd crashes for those who were receiving dcd crashes. I cannot tell from earlier posts in this thread if dcd crashes stopped for some. I am running Merlin's 384.11 alpha4 which is based on 45713 but I am still getting dcd crashes.

RT-AC86U

 

[OzarkEdge]

Are dcd crashes still happening for those using Trend Micro with this firmware? I wish to know if 3.0.0.4.384.45713 fixed the dcd crashes for those who were receiving dcd crashes. I cannot tell from earlier posts in this thread if dcd crashes stopped for some. I am running Merlin's 384.11 alpha4 which is based on 45713 but I am still getting dcd crashes.

RT-AC86U

My log is pristine since booting 5 days ago. It is only listing AiMesh roaming activity. I am only running AiProtection.

OE

 

[WET]

My log is pristine since booting 5 days ago. It is only listing AiMesh roaming activity. I am only running AiProtection.

OE

Thank you for responding, were you getting dcd crashes prior to running 45713?

 

[OzarkEdge]

So were you getting dcd crashes prior to running 45713?

Sounds familiar... 45149 AiProtection was causing unhealthy log entries, so I Withdrew from using Trend Micro but kept using 45149.

I can't recall exactly that the 'crashes' were 'dcd' or 'tainted' or whatever else I've read about here.

OE

 

[CriticJay]

Are dcd crashes still happening for those using Trend Micro with this firmware? I wish to know if 3.0.0.4.384.45713 fixed the dcd crashes for those who were receiving dcd crashes. I cannot tell from earlier posts in this thread if dcd crashes stopped for some. I am running Merlin's 384.11 alpha4 which is based on 45713 but I am still getting dcd crashes.

RT-AC86U

That's unfortunate ... can you post your logs? Did you do a full factory reset / nvram wipe etc?

 

[Latzz]

Had issues with this firmware. After making changes to the Tx Power Adjustment, the router became unresponsive, with both wifi and cable connection not working. Had the new firmware run for a day before the changes to monitor potential issues.

After hardware reset to factory, got back into the router. Performed reset to factory twice with minimal config. Router seemed to work fine and connected to the ISP except the WAN led was RED.

Apr 25 11:20:20 acsd: Adjusted channel spec: 0x1004 (4)
Apr 25 11:20:20 acsd: selected channel spec: 0x1004 (4)
Apr 25 11:35:21 acsd: selected channel spec: 0x1009 (9)
Apr 25 11:35:21 acsd: Adjusted channel spec: 0x1009 (9)
Apr 25 11:35:21 acsd: selected channel spec: 0x1009 (9)
Apr 25 11:50:24 acsd: selected channel spec: 0x100a (10)
Apr 25 11:50:24 acsd: Adjusted channel spec: 0x100a (10)
Apr 25 11:50:24 acsd: selected channel spec: 0x100a (10)
Apr 25 12:05:27 acsd: selected channel spec: 0x1001 (1)
Apr 25 12:05:27 acsd: Adjusted channel spec: 0x1001 (1)
Apr 25 12:05:27 acsd: selected channel spec: 0x1001 (1)
Apr 25 12:20:30 acsd: selected channel spec: 0x100b (11)
Apr 25 12:20:30 acsd: Adjusted channel spec: 0x100b (11)
Apr 25 12:20:30 acsd: selected channel spec: 0x100b (11)
Apr 25 12:35:32 acsd: selected channel spec: 0x100a (10)
Apr 25 12:35:32 acsd: Adjusted channel spec: 0x100a (10)
Apr 25 12:35:32 acsd: selected channel spec: 0x100a (10)
Apr 25 12:50:33 acsd: selected channel spec: 0x1003 (3)
Apr 25 12:50:33 acsd: Adjusted channel spec: 0x1003 (3)

This was on the wireless set to auto channel. System log was showing channels changing every few minutes. After a day, power reset the network and the WAN led was restored to the normal white. Plus the channel was not changing as frequently.

Seemed very weird behaviour with this firmware. This is with a router that had not shown any hiccups since installation for over a year now.