RT-AC3200 Running Merlin 384.3 Random Reboots

[bytemunchr]

Hello!

I've been seeing a very odd issue since updating to 384.3, my router will randomly reboot throughout the day. It's happened twice in a 5 hour period today alone. Nothing seems out of the ordinary and my logs are pretty clear, but I haven't caught it before it reboots itself, so I'm unsure what could be causing it. I'm not running a VPN or anything of the sort... really nothing special going on here pretty much all default settings minus utilizing Google DNS and forwarding two ports, otherwise everything is default.

I see this has been a reoccurring issue in older firmware updates on the ASUS routers, but unsure with the newest version. Any idea what could be the culprit?

 

[scjr]

Have you reset to factory default?

You could try 384.4 beta 2. Im use a different model, but on a minimal setup as well and it’s running great.

https://www.snbforums.com/threads/beta-384-ng-asuswrt-merlin-384-4-beta-is-now-available.44941/

 

[bytemunchr]

Figured I'd give factory reset a try if it continues to be a nuisance, for a while I thought it was a client that was the cause, but after some digging it doesn't seem as though anything odd is happening. Checked jffs syslog and before each reboot nothing out of the ordinary there either.

A little stumped, I actually went from stock firmware to 384.3, may rollback to latest Asus build and see if that changes anything.

 

[scjr]

Definitely factory reset, especially if coming from anything before 384. Let us know how it goes. Good luck!

 

[Nigel Jones]

Yes factory reset. Do not restore bit reconfigure manually.

Has it certainly rebooted?


Sent from my iPhone using Tapatalk

 

[mcouture]

My AC3200 runs 384.4 beta 2 very well.

The 384.3 seemed to be a bit buggy on mine...it wasn't on it for too long so I didn't do much troubleshooting...

You must do a factory reset and re-create your settings yourself. There are too many config differences jumping to the 384.x firmware.

 

[st3v3n]

Bytemunchr, just a hunch, from time to time our 3200 abruptly changes/reverses date/time zones, usually happens when DST switches occur. It may or may not have anything to do with yours does, but worth a check. If there's anything in the logs that have anything to do with NTP errors or time being off, it can create merry havoc. If that happens try a different time server, save, log out/back in, then go back to what you usually use. Good luck, Cheers.

 

[bytemunchr]

Not getting any issues with NTP, but I can definitely see that causing some issues.

I may give 384.4 a try, how long have you been running it?

 

[st3v3n]

bytemunchr, So far we haven't decided on going to 384.4, -yet. Since we haven't had other incidents with time/dates going forward/backward, the router has been well-behaved on 380.68_4. v380 was/is a well proven part of the fork, and though there was another release prior to the fork going forward to the short-lived 382 code, it serves extremely well, and there are no particular security challenges yet that demand we move on to the next build. 384.4 is still considered beta and though many are testing and running it without too many problems, we don't have time to devote to testing, and there's the problems of never being able to revert that Asus has built into this particular code. I have no personal problem with it since Merlin fixes all of Asus's releases, but never being able to revert to anything, seems a bit harsh but that's Asus's code and their decision. We'll likely adopt 384 when it's out of beta, when most problems have been reported and resolved. If you have time, don't mind not being able to ever revert back to any previous stable version of -any- build of any fork, and if running beta builds don't present an issue for you, you may want to join the bleeding edge for your 3200, where this is at present. Many hope 384 will eventually have AIMesh, which doesn't affect us. The 3200 on it's own, without an AP has always given us great coverage.

When 384 is mature enough we'll jump into it to take advantage of the NVRAM on the 3200, now at 128 MB, with five OpenVPN being possible once again. Five tunnels used to possible as far back as June, 2017 on v366.6 if memory serves, at which point Merlin limited the 3200 from 5 to two tunnels to avoid crashes due to there only being 64 MB of NVRAM (the wiki explains it better). Having the capability to handle five OpenVPN clients is desirable since when a tunnel goes down, it's easier to switch it off and turn on another rather than have to reset that client to default, dumping that config then loading another config/tunnel in it's place, especially since outages usually don't last long.

Hope that's helpful, cheers.

 

[mechtron]

I am having a similar issue. dmesg shows a stack trace on reboot. This is from an RT-AC3200 running 384.9

_ Reboot message ... _______________________________________________________
Unable to handle kernel NULL pointer derefere��U�at virtual address 00000000
pgd = 80004000
[00000000] *pgd=00000000
Internal error: Oops: 817 [#1] PREEMPT SMP
last sysfs file: /sys/module/nf_conntrack/parameters/hashsize
module:  nf_nat_sip     7f3dd000     5031
module:  nf_conntrack_sip     7f3b9000     3202
module:  nf_conn4
module:  nf_conntrack_ftp     7f3a6000     4909
module:  ip6table_mangle     7f3a0000     934
module:  usblp     7f398000     10321
module:  thfsplus     7f37b000     85357
module:  tntfs     7f2fb000     d000     53788
module:  ext4     7f26c000     222306
module:  jbd2    16     7f252000     1007
module:  e:  mbcache     7f217000     4599
module:  usb_storage     7f208000     34039
module:  sd_mod     7f1f1000an     7f1eb000     416
module:  scsi_mod     7f1c6000     108826
module:  ohci_hcd     7f1bc000     17918
module:  ehci_hcd     7f1af000     3000     3129
module:  qmi_wwan     7f1a2000     5780
module:  cdc_wdm     7f19b000     7252
module:  cdc_ncm     7f193000     8750
module:  rndis_host     7f18c000     4936
module:  cdc_ether     7f186000     310832
module:  cdc_acm     7f176f16d000     11161
module:  usbcore     7f14a000     102094
module:  ip6t_LOG     7f13d000     4494
module:  ip6table_filter     7f137000    igs     7f013000     11927
module: rack_sip nf_nat_h323 nf_conntrack_h323 nf_nat_rtsp nf_conntrack_rtsp nf_nat_ftp nf_conntrack_ftpcrc16 ext3 jbd mbcache usb_storage sg sd_mod scsi_wait_scan scsi_mod ohci_hcd ehci_hcd cdc_mbim t usbcore mii ip6t_LOG ip6table_filter jffs2 zlib_deflate dhd et(P) igs(P) emf(P) ctf(P) [last uU: 1    Tainted: P             (2.6.36.4brcmarm #1)
PC is at dhdpcie_bus_process_mailbox_intr+0x164/0x1f0 [dhd]
LR is at dhdpcie_bus_process_mailbox_intr+0x14c/0x1f0 [dhd]
pc : [<7f041870>]    lr : [<7f041858>]    psr: 60000113
sp : 8f83ded0  ip : 7f0553ec  fp : 00000000
r: 8047ecd8
r7 : 7f05dae0  r6 8eb41000
r3 : 00000000  r2 : egment kernel
Control: 10c53ck: (0x8f83ded0 to 0x8f83e000)
dec0:                                     00000000 8eb41000 000c000 7f0529bc 00000100 8041321c
df00: 8ee5c000 8ee5f8cc 00000408040 80479f20 00000001 803ca8b0
df40: 90810000 80068b34 000 8047ecd8 8004d9d0
df60: 8f83c000 00000000 8f83c000 0000001f 00000000 8007abcc 000000a3 803ca80050bc4 80050d88 8f84806a 00000edfedc3
[<7f041870>] (PC is at dhdpcie_bus_process_mailbox_inox_intr+0x164/0x1f0 [dhd]) from [<7f0529bc>] (dhd_bus_dpc+0xc8/00 e3130001 1a000006 e3a03000 (e5833000)
---[ end trace 950a31dc)
[<800536f8>] (die+0x1ac/0x1dc) from [<80057380>] (__do_k>] (do_page_fault+0x150/0x1ec) from [<8004f3a4>] (do_DataAbort+0xception stack(0x8f83de88 to 0x8    00000834 00000000 0000000a 0 c9f0c>] (__dabt_svc+0x4c/0x60) f
____________________________________________________________________________

 

[st3v3n]

Mechton, That's interesting. Haven't had any repeats since moving on to version 384.10, definitely many improvements. Toing to make the jump to 384.12. Cheers.