What's new

Release Asuswrt-Merlin 386.12 is now available for AC 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.
Daily reboots for no reason put more wear and tear on the routers' components.

Can hide underlying issues.

Isn't needed in any well-functioning network.
I'm curious to know if anything is written to flash when the router reboots. Repeatedly writing to flash memory does wear it out eventually. But just reading from flash does not significantly impact MTBF as far as I know. Rebooting will surely place very little stress on the other components. The power supply is already up and running at a stable temperature, so no inrush current stress or thermal cycling stress to worry about. But writing to flash every day, that could be a worry.

I ask as a user who has a daily reboot scheduled on the family router, reason being just in case it gets its knickers in a noodle while I am away from home. Family gets very upset when "the internet is broken" - which is mostly caused by ISP service outages, not a messed up router. However, possible messed up router scenarios I am seeking to mitigate with the nightly reboot would be "malicious packets" running into an unpatched security vulnerability and hanging a process, or a bug in this otherwise excellent firmware that escaped testing. In nearly 4 years of running asuswrt-merlin with nightly scheduled reboots, this router has only needed manually power cycling to restart messed up wireless a couple of times. But now I'm worried about wearing out the flash memory. Is that where the system log is written? Can anyone please advise?
 
Wi-Fi broken again for me on 386.12_4, uptime was longer than 386.12_2 (about 2 days) but just after i rebooted and went to sleep, i woke up 7 hours later to find it broken again. Downgrading to 386.12 for now to see what the hell is going on.
Could be radios failing but unlikely as more people have this issue, weather is colder now, and radios still stay up and what looks like to me they stop communicating with the main cpu as unless i am blind i didn't see anything in the log:

 
Wi-Fi broken again for me on 386.12_4, uptime was longer than 386.12_2 (about 2 days) but just after i rebooted and went to sleep, i woke up 7 hours later to find it broken again. Downgrading to 386.12 for now to see what the hell is going on.
Could be radios failing but unlikely as more people have this issue, weather is colder now, and radios still stay up and what looks like to me they stop communicating with the main cpu as unless i am blind i didn't see anything in the log:

Disable FlexQoS and change Diversion from "Standard" to the "Lite" version. Both of those are known to have issues with recent firmware.
 
Wi-Fi broken again for me on 386.12_4, uptime was longer than 386.12_2 (about 2 days)

My Uptime is 3 days 7 hour(s) now. No problem with Wi-Fi.

Anyway, I keep getting these (TrendMicro related?) messages in General log:

Code:
Nov 24 22:01:29 kernel: dcd/30670: potentially unexpected fatal signal 11.
 
I fully understand that, but still I had this issue all the time with 386_12.0 that my work laptop connected on 2.4 Ghz had a very bad internet connection while the other computers at home did work as they should be. After turning off TM engine, it did work again without any issues on 386_12.0. With 386_12.2 this issue was not present and the only issue were problems with the VPN server, but also quite limited for me. Also, the problems that others report, that the wireless networks only show up after a long time did never happen to me.

Today with 386_12.4 during a teams meeting I could see how the 2.4 Ghz connection did deteriorate again. In the beginning of the meeting all video streams were shown without issues, at the end of the meeting I could only hear voices and every video or screen share was completely frozen, even with the TM engine disabled. After a reboot of the router it worked for maybe 30 min, then again no throughput and not even writing emails was possible as outlook got continously stuck. At the same time, the router did show a lot of crashes of various processes (see the post above), which was not the case with 386_12.0 or 12.2.

In order to be able to work, I downgraded now to 12.2 and the only issue I see are 2 crashes of asd, everything else (including the VPN server) is working without any issues and at full speed.
Have you considered interference from USB3.0 data signal? It can considerably hinder the quality of wireless in 2.4Ghz range.
 
I'm curious to know if anything is written to flash when the router reboots. Repeatedly writing to flash memory does wear it out eventually. But just reading from flash does not significantly impact MTBF as far as I know. Rebooting will surely place very little stress on the other components. The power supply is already up and running at a stable temperature, so no inrush current stress or thermal cycling stress to worry about. But writing to flash every day, that could be a worry.

I ask as a user who has a daily reboot scheduled on the family router, reason being just in case it gets its knickers in a noodle while I am away from home. Family gets very upset when "the internet is broken" - which is mostly caused by ISP service outages, not a messed up router. However, possible messed up router scenarios I am seeking to mitigate with the nightly reboot would be "malicious packets" running into an unpatched security vulnerability and hanging a process, or a bug in this otherwise excellent firmware that escaped testing. In nearly 4 years of running asuswrt-merlin with nightly scheduled reboots, this router has only needed manually power cycling to restart messed up wireless a couple of times. But now I'm worried about wearing out the flash memory. Is that where the system log is written? Can anyone please advise?

One can consult flash memory write cycle expectations:

I expect the router eMMC to be no worse than TLC - meaning 3k cycles. That's slightly more than 8 years of daily full re-writes. If the memory is MLC - then we get 24 years expected. The flash never re-written fully though, and one can end up with a stray chip that fails way earlier. But overall there is no expectation of users routinely wearing out flash from anything they do within normal usage bounds, and that would include daily reboots.
 
Hello everyone, RMerlin,

AC86U here.
I installed 0, 2 and 4 when they were released. I didn't experience or notice the issues that some reported (except the "Release Note preview not working", mentioned above, which I do experience, even if I don't really care. I read them after download.).

Thank you for the continued support

Best regards

PS: I still think every release deserves a separate announcement post. If _0 works fine on my router, I have no reason to keep checking page 16 of the original thread to see that _2 was released. YMMV.
 
Hello everyone, I've been using RT-AC68U in AP mode Firmware 386.12_4 for 2 days 5 hour(s) and I don't have any problems
 
I noticed an error when entering Network map clients, then View list and when you want to X to exit, it freezes and the processor goes to 100% RT-AC68U
 
Last edited:
Nov 25 22:26:02 kernel: asd/186: potentially unexpected fatal signal 11.
Nov 25 22:26:02 kernel: Pid: 186, comm: asd
Nov 25 22:26:02 kernel: CPU: 0 Tainted: P (2.6.36.4brcmarm #1)
Nov 25 22:26:02 kernel: PC is at 0x404c17a8
Nov 25 22:26:02 kernel: LR is at 0x404bc050
Nov 25 22:26:02 kernel: pc : [<404c17a8>] lr : [<404bc050>] psr: a0000010
Nov 25 22:26:02 kernel: sp : bece3990 ip : 404f0da0 fp : 00000000
Nov 25 22:26:02 kernel: r10: 0000001c r9 : bece3b18 r8 : 00000020
Nov 25 22:26:02 kernel: r7 : 00000000 r6 : 0000016d r5 : 0000000b r4 : bece3a10
Nov 25 22:26:02 kernel: r3 : 0000016d r2 : 00000000 r1 : ffffffff r0 : 0000016d
Nov 25 22:26:02 kernel: Flags: NzCv IRQs on FIQs on Mode USER_32 ISA ARM Segment user
Nov 25 22:26:02 kernel: Control: 10c53c7d Table: 9da5004a DAC: 00000015
Nov 25 22:26:04 rc_service: service 14722:notify_rc restart_firewall

First entry in log on 12_4 any ideas? On RT-AC68U V3 hardware.
 
Hello everyone, RMerlin,

AC86U here.
I installed 0, 2 and 4 when they were released. I didn't experience or notice the issues that some reported (except the "Release Note preview not working", mentioned above, which I do experience, even if I don't really care. I read them after download.).

Thank you for the continued support

Best regards

PS: I still think every release deserves a separate announcement post. If _0 works fine on my router, I have no reason to keep checking page 16 of the original thread to see that _2 was released. YMMV.

You're checking wrong.

 
Just installed 386.12_4 on my AC86U main/AP combo. I'll post my experience in a few days.

After 32 hours, everything appears to be the same as running 386.12_0. No changes in the log entries or wireless behavior, and solid performance. asd continues to routinely crash on my AP router, but not the main router. No obvious effect on router behavior. Tomorrow morning, I will try Martinski's script for automatically restarting asd to avoid the crash.
 
Last edited:
Have you considered interference from USB3.0 data signal? It can considerably hinder the quality of wireless in 2.4Ghz range.
No not really, but I could maybe switch the USB configuration to 2.0. But if it was the USB, then I guess the issue should be present in every firmware, unless something was changed in the USB driver.

Now with switching back to 386_12.2, my issues are gone. The VPN server seems to be running stable and asd did crash 2 times after the upgrade, but not again in the last 36 hours.
 
No not really, but I could maybe switch the USB configuration to 2.0.
You definitely should try.
But if it was the USB, then I guess the issue should be present in every firmware, unless something was changed in the USB driver.
You're correct. The issue is not in the firmware or the driver. It's in the nature of radio signals. You can have a look at this Intel's whitepaper to familiarize yourself with the issue.
Now with switching back to 386_12.2, my issues are gone.
Your 2.4Ghz devices may seem to function well until the next interference from USB3.0 data signal, which you may not notice if you're not watching constantly, imho.
 
Thanks for the hint, something quite interesting. I need to monitor that during my next home office day and see if either changing the USB configuration does help or if there is a difference between the 2.4 GHz and the 5 GHz connection (even if the 5 Ghz signal in that room is rather weak). However, still the issue does remain that with 386_12.4 I had crashes of asd, wred and dcd while with 386_12.2 there were only occasional crashes of asd.
 
... Tomorrow morning, I will try Martinski's script for automatically restarting asd to avoid the crash.
Which Martinski's script are you talking about? Link?

I updated to 386.12_4 on AC86u more than 2 days ago. At first, the log was full of asd and dcd errors. Then about ~24 hours after a reboot they all disappeared. And now it's running error free. Cannot talk about dig errors, I filtered them out fully. See the relevant log section - last dcd error at 1:49, then nothing. Very weird.

Code:
...
Nov 25 01:23:09 RT-AC86U-9988 kernel: dcd[5683]: unhandled level 3 translation fault (11) at 0x00000000, esr 0x92000007
Nov 25 01:23:09 RT-AC86U-9988 kernel: pgd = ffffffc0175ed000
Nov 25 01:23:09 RT-AC86U-9988 kernel: [00000000] *pgd=0000000003c31003, *pud=0000000003c31003, *pmd=0000000011634003, *pte=0000000000000000
Nov 25 01:23:09 RT-AC86U-9988 kernel: potentially unexpected fatal signal 11.
Nov 25 01:25:42 RT-AC86U-9988 kernel: asd[7713]: unhandled level 3 translation fault (11) at 0x00000168, esr 0x92000007
Nov 25 01:25:42 RT-AC86U-9988 kernel: pgd = ffffffc005a43000
Nov 25 01:25:42 RT-AC86U-9988 kernel: [00000168] *pgd=0000000011029003, *pud=0000000011029003, *pmd=0000000005bbd003, *pte=0000000000000000
Nov 25 01:25:42 RT-AC86U-9988 kernel: potentially unexpected fatal signal 11.
Nov 25 01:25:42 RT-AC86U-9988 rc_service: service 19386:notify_rc restart_firewall
Nov 25 01:25:42 RT-AC86U-9988 custom_script: Running /jffs/scripts/service-event (args: restart firewall)
Nov 25 01:25:43 RT-AC86U-9988 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
Nov 25 01:25:45 RT-AC86U-9988 uiScribe: Mounting WebUI page for uiScribe
Nov 25 01:25:45 RT-AC86U-9988 uiScribe: Mounted uiScribe WebUI page as Main_LogStatus_Content.asp
Nov 25 01:25:50 RT-AC86U-9988 rc_service: service 20209:notify_rc restart_dnsmasq
Nov 25 01:25:50 RT-AC86U-9988 custom_script: Running /jffs/scripts/service-event (args: restart dnsmasq)
Nov 25 01:25:50 RT-AC86U-9988 dnsmasq[8878]: exiting on receipt of SIGTERM
Nov 25 01:25:50 RT-AC86U-9988 custom_config: Appending content of /jffs/configs/dnsmasq.conf.add.
Nov 25 01:25:50 RT-AC86U-9988 custom_script: Running /jffs/scripts/dnsmasq.postconf (args: /etc/dnsmasq.conf)
Nov 25 01:25:51 RT-AC86U-9988 Diversion: created br0:ad_blocking_excl for 192.168.1.16
Nov 25 01:25:51 RT-AC86U-9988 dnsmasq[20628]: started, version 2.89 cachesize 150
Nov 25 01:25:51 RT-AC86U-9988 dnsmasq[20628]: compile time options: IPv6 GNU-getopt no-RTC no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset no-nftset no-auth cryptohash DNSSEC no-ID loop-detect no-inotify no-dumpfile
Nov 25 01:25:51 RT-AC86U-9988 dnsmasq[20628]: read /etc/hosts - 22 names
Nov 25 01:25:51 RT-AC86U-9988 dnsmasq[20628]: using nameserver 172.16.1.254#53
Nov 25 01:25:51 RT-AC86U-9988 dnsmasq[20628]: using nameserver 172.16.1.254#53 for domain attlocal.net
Nov 25 01:25:51 RT-AC86U-9988 dnsmasq[20628]: using nameserver 172.16.1.254#53
Nov 25 01:25:51 RT-AC86U-9988 dnsmasq[20628]: using nameserver 172.16.1.254#53 for domain attlocal.net
Nov 25 01:25:51 RT-AC86U-9988 Diversion: started separate Dnsmasq instance for ad-blocking exclusion on IP 192.168.1.16
Nov 25 01:25:51 RT-AC86U-9988 Diversion: restarted Dnsmasq to apply settings
Nov 25 01:25:51 RT-AC86U-9988 (dnsmasq.postconf): Updating /etc/dnsmasq.conf for unbound.....
Nov 25 01:25:51 RT-AC86U-9988 uiDivStats: dnsmasq has restarted, restarting taildns
Nov 25 01:25:54 RT-AC86U-9988 admin: Started taildns from .
Nov 25 01:30:00 RT-AC86U-9988 Temp: 47.9 38.5 47.5 ; Mem free: 33828 KB; Swap used: 32380 KB; sda1 wrote: 1737.17 MB
Nov 25 01:45:00 RT-AC86U-9988 Temp: 47.9 38.5 47.5 ; Mem free: 33104 KB; Swap used: 32380 KB; sda1 wrote: 1749.64 MB
Nov 25 01:49:50 RT-AC86U-9988 kernel: dcd[17172]: unhandled level 3 translation fault (11) at 0x00000000, esr 0x92000007
Nov 25 01:49:50 RT-AC86U-9988 kernel: pgd = ffffffc005bd6000
Nov 25 01:49:50 RT-AC86U-9988 kernel: [00000000] *pgd=00000000044a6003, *pud=00000000044a6003, *pmd=0000000003c31003, *pte=0000000000000000
Nov 25 01:49:50 RT-AC86U-9988 kernel: potentially unexpected fatal signal 11.
Nov 25 01:57:00 RT-AC86U-9988 (unbound_log.sh): 9887 Processed 0 reply_domains...
Nov 25 01:57:00 RT-AC86U-9988 (unbound_log.sh): 9887 Processed 0 nx_domains...
Nov 25 01:57:00 RT-AC86U-9988 (unbound_log.sh): 9887 Processed 0 RPZ events...
Nov 25 02:00:00 RT-AC86U-9988 Temp: 48.3 38.5 47.5 ; Mem free: 28740 KB; Swap used: 32380 KB; sda1 wrote: 1767.40 MB
Nov 25 02:00:00 RT-AC86U-9988 uiDivStats: Starting stat update
Nov 25 02:00:12 RT-AC86U-9988 uiDivStats: Stats updated successfully
Nov 25 02:15:00 RT-AC86U-9988 Temp: 47.9 38.5 47.5 ; Mem free: 26516 KB; Swap used: 32504 KB; sda1 wrote: 1786.07 MB
Nov 25 02:30:00 RT-AC86U-9988 Temp: 48.3 38.5 47.5 ; Mem free: 28632 KB; Swap used: 32508 KB; sda1 wrote: 1800.65 MB
Nov 25 02:45:00 RT-AC86U-9988 Temp: 48.3 38.0 47.5 ; Mem free: 27628 KB; Swap used: 32504 KB; sda1 wrote: 1812.38 MB
Nov 25 02:57:00 RT-AC86U-9988 (unbound_log.sh): 25427 Processed 0 reply_domains...
Nov 25 02:57:00 RT-AC86U-9988 (unbound_log.sh): 25427 Processed 0 nx_domains...
Nov 25 02:57:00 RT-AC86U-9988 (unbound_log.sh): 25427 Processed 0 RPZ events...
Nov 25 03:00:00 RT-AC86U-9988 Temp: 47.9 38.0 47.5 ; Mem free: 29516 KB; Swap used: 32504 KB; sda1 wrote: 1828.84 MB
Nov 25 03:00:00 RT-AC86U-9988 uiDivStats: Starting stat update
Nov 25 03:00:03 RT-AC86U-9988 kernel: do_ni_syscall: 55 callbacks suppressed
Nov 25 03:00:08 RT-AC86U-9988 kernel: do_ni_syscall: 46 callbacks suppressed
Nov 25 03:00:10 RT-AC86U-9988 uiDivStats: Stats updated successfully
Nov 25 03:15:01 RT-AC86U-9988 Temp: 47.4 38.0 47.5 ; Mem free: 32320 KB; Swap used: 32540 KB; sda1 wrote: 1847.01 MB
Nov 25 03:30:00 RT-AC86U-9988 Temp: 47.4 38.0 47.5 ; Mem free: 29888 KB; Swap used: 32540 KB; sda1 wrote: 1859.96 MB
Nov 25 03:45:00 RT-AC86U-9988 Temp: 47.4 38.0 47.5 ; Mem free: 30296 KB; Swap used: 32540 KB; sda1 wrote: 1871.50 MB
Nov 25 03:57:00 RT-AC86U-9988 (unbound_log.sh): 8453 Processed 0 reply_domains...
Nov 25 03:57:00 RT-AC86U-9988 (unbound_log.sh): 8453 Processed 0 nx_domains...
Nov 25 03:57:00 RT-AC86U-9988 (unbound_log.sh): 8453 Processed 0 RPZ events...
Nov 25 04:00:00 RT-AC86U-9988 Temp: 47.4 38.0 47.5 ; Mem free: 101024 KB; Swap used: 32536 KB; sda1 wrote: 1887.82 MB
Nov 25 04:00:00 RT-AC86U-9988 uiDivStats: Starting stat update
Nov 25 04:00:12 RT-AC86U-9988 uiDivStats: Stats updated successfully
Nov 25 04:15:00 RT-AC86U-9988 Temp: 47.9 38.0 47.5 ; Mem free: 39068 KB; Swap used: 32536 KB; sda1 wrote: 1906.25 MB
Nov 25 04:30:00 RT-AC86U-9988 Temp: 47.4 38.0 47.5 ; Mem free: 37648 KB; Swap used: 32536 KB; sda1 wrote: 1920.72 MB
Nov 25 04:45:00 RT-AC86U-9988 Temp: 47.4 38.0 47.5 ; Mem free: 34996 KB; Swap used: 32536 KB; sda1 wrote: 1932.92 MB
Nov 25 04:57:00 RT-AC86U-9988 (unbound_log.sh): 24702 Processed 0 reply_domains...
Nov 25 04:57:00 RT-AC86U-9988 (unbound_log.sh): 24702 Processed 0 nx_domains...
Nov 25 04:57:00 RT-AC86U-9988 (unbound_log.sh): 24702 Processed 0 RPZ events...
Nov 25 05:00:00 RT-AC86U-9988 Temp: 47.4 38.0 47.5 ; Mem free: 32812 KB; Swap used: 32532 KB; sda1 wrote: 1949.73 MB
Nov 25 05:00:00 RT-AC86U-9988 uiDivStats: Starting stat update
Nov 25 05:00:02 RT-AC86U-9988 kernel: do_ni_syscall: 56 callbacks suppressed
Nov 25 05:00:07 RT-AC86U-9988 uiDivStats: Stats updated successfully
Nov 25 05:10:00 RT-AC86U-9988 dn-vnstat: Lock file found (age: 600 seconds)
Nov 25 05:15:00 RT-AC86U-9988 Temp: 47.9 38.0 47.5 ; Mem free: 32060 KB; Swap used: 32532 KB; sda1 wrote: 1968.64 MB
Nov 25 05:15:00 RT-AC86U-9988 dn-vnstat: Stale lock file found (>600 seconds old) - purging lock
Nov 25 05:20:01 RT-AC86U-9988 Diversion: rotated dnsmasq log files
Nov 25 05:30:01 RT-AC86U-9988 Temp: 47.4 38.0 47.0 ; Mem free: 33260 KB; Swap used: 32576 KB; sda1 wrote: 1983.60 MB
Nov 25 05:45:00 RT-AC86U-9988 Temp: 46.9 38.0 47.0 ; Mem free: 31564 KB; Swap used: 32576 KB; sda1 wrote: 1995.69 MB
Nov 25 05:57:00 RT-AC86U-9988 (unbound_log.sh): 6809 Processed 0 reply_domains...
Nov 25 05:57:00 RT-AC86U-9988 (unbound_log.sh): 6809 Processed 0 nx_domains...
Nov 25 05:57:01 RT-AC86U-9988 (unbound_log.sh): 6809 Processed 0 RPZ events...
Nov 25 06:00:00 RT-AC86U-9988 Temp: 46.9 38.0 47.5 ; Mem free: 27784 KB; Swap used: 32576 KB; sda1 wrote: 2012.57 MB
Nov 25 06:00:01 RT-AC86U-9988 uiDivStats: Starting stat update
Nov 25 06:00:03 RT-AC86U-9988 kernel: do_ni_syscall: 54 callbacks suppressed
Nov 25 06:00:08 RT-AC86U-9988 kernel: do_ni_syscall: 48 callbacks suppressed
Nov 25 06:00:09 RT-AC86U-9988 uiDivStats: Stats updated successfully
Nov 25 06:15:00 RT-AC86U-9988 Temp: 47.4 38.0 47.0 ; Mem free: 28368 KB; Swap used: 32496 KB; sda1 wrote: 2032.53 MB
Nov 25 06:30:00 RT-AC86U-9988 Temp: 46.9 38.0 47.0 ; Mem free: 28116 KB; Swap used: 32492 KB; sda1 wrote: 2047.35 MB
Nov 25 06:45:00 RT-AC86U-9988 amtm routerdate[20688]: Preserving router date via cron (2023-11-25 12:45:00) UTC time.
...
 
I just updated to 386.12_2 & re-entered all my settings. Just now noticed 386.12_4 was released w/ only one difference in the changelog which states (UPDATED: openvpn to 2.6.8 (fixes a crash introduced in 2.6.7)

Should I flash the newest firmware even if I never use OPENVPN?? will I get crashes if I dont use openvpn, or is it ok to just wait for the next version?
 
Which Martinski's script are you talking about? Link?

I updated to 386.12_4 on AC86u more than 2 days ago. At first, the log was full of asd and dcd errors. Then about ~24 hours after a reboot they all disappeared. And now it's running error free. Cannot talk about dig errors, I filtered them out fully. See the relevant log section - last dcd error at 1:49, then nothing. Very weird.

...

Martinski's script (which is working for me) is here:


However, your log doesn't indicate that asd is crashing. Looks more like there are runtime errors. A few people have noted asd/dcd issues for a short while after restart and then no further errors. You may be in the same boat.
 
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