Release Asuswrt-Merlin 384.19 is now available

[bbunge]

So, my AC86U was up for 17 hours, then it rebooted about 15 min ago.
Again, only about 5 devices were connected, sorry 6, I forgot about the AC66U_B1.
There's nothing special running on the AC86U, it's pretty bare at the moment. I've been watching the Syslog periodically and nothing popped except when it rebooted by itself. I was just modifying a google doc when I noticed it said no connection on the google doc web page.
I was streaming a show on Netflix on my TV, working on a doc in Google with my laptop and my daughter was on her phone checking the status of her Doordash meal.
The only issue I have at the moment is that I can not Telnet into the router, I get a connection error with Putty. And of course, the periodic rebooting.
So, I've attached the Syslog file for anyone to browse but I've done everything possible to upgrade to 384.19.
I'm giving up... I'll start again in the morning since my wife will be home soon from work and she'll want to watch a little tv before bed and I don't want to be messing around with the network when she's home reverting back to 384.18.
The whole reason she went into work today was because of the issues I was having with the update!

Link to Syslog to view: https://bit.ly/33CMWaF

IMHO, it's not rocket science. This router is a consumer-based product and you literally should be able to plug it in and it works. Mind you we're using third-party firmware but it's better than the original. Yes, I know...there's some minor configuration to get it up and running but it's very minor. It basically plug n play.
I've spent quite a bit of time today going over pages and pages of fixes, modifications, tricks of the trade, etc on how to get the router to work and diagnosing and testing for issues.
I just can't get over all the suggestions and literal SOP's to get this device to work... it's mind-boggling to read all the information on troubleshooting.
I'm glad I'm not in the industry anymore because I think I spent more time troubleshooting network issues at home than I ever did at work!
Sorry for the rant...I'm hangry, tired, and fed up!
I don't think it's an electrical problem, as I mentioned before, I have good ups with AVR and no other devices are being affected. Network cables in use are very short so static discharge shouldn't be an issue. Software is not my forte so I have no idea, that's why I'm here looking for answers. I'm a hardware guy...
Ok, that's my 2 cents worth for today!
My wife just walked in the door...she went straight into her home office to finish the day...fingers crossed there are no issues!!!

X

For now to put a bit of stability in your life I recommend you go to Asus 384.82072. Yes, it is not as feature rich as Merlin but it is stable. Remember to remove any USB drives and do a WPS factory reset after flashing. You can have your WIFI back up in about 15 minutes.
Edit: about the only gotcha with 384.82072 is the Asus auto upgrade feature. But, it seems to check for an upgrade early in the morning.

 

[xdj]

For now to put a bit of stability in your life I recommend you go to Asus 384.82072. Yes, it is not as feature rich as Merlin but it is stable. Remember to remove any USB drives and do a WPS factory reset after flashing. You can have your WIFI back up in about 15 minutes.
Edit: about the only gotcha with 384.82072 is the Asus auto upgrade feature. But, it seems to check for an upgrade early in the morning.

Thanks, b.
Yeah, I need to step back...
I appreciate the info on the fw version. I'll look at it on the weekend

Cheers,

X

 

[Lotta Cox]

Uptime 37 days 21 hour(s) 24 minute(s) 26 seconds

What am I doing wrong

Wireless Clients (2.4 GHz)	Associated: 37 - Authorized: 37 - Authenticated: 37
Wireless clients (5 GHz)	Associated: 16 - Authorized: 16 - Authenticated: 16

 

[hervon]

Yeah. Need help too. ;-)

 

[AntonK]

Uptime 37 days 21 hour(s) 24 minute(s) 26 seconds

What am I doing wrong

​

Wireless Clients (2.4 GHz)	Associated: 37 - Authorized: 37 - Authenticated: 37
Wireless clients (5 GHz)	Associated: 16 - Authorized: 16 - Authenticated: 16

Cox, you're the best

 

[bbunge]

Uptime 37 days 21 hour(s) 24 minute(s) 26 seconds

What am I doing wrong

​

Wireless Clients (2.4 GHz)	Associated: 37 - Authorized: 37 - Authenticated: 37
Wireless clients (5 GHz)	Associated: 16 - Authorized: 16 - Authenticated: 16

Wonderful!
I am thrilled with 3 1/2 days without a crash or lockup. I turned off the reboot scheduler and my up time is a meer 18 hours but I am still very happy!

 

[Intrepid2007]

This firmware version 384.19 is the most stable firmware I have had on my Asus router. It's running 34 days without *any* issues...

Asus is beta-testing new firmware (386.xxx): maybe better mesh support or support for other/newer VPN protocols could be a reason to upgrade to newer firmware... That is if a Merlin firmware version becomes available (I like the policy based routing very much, not available in the stock firmware).

For now I am very happy with this firmware...

 

[here1310]

BUG??:

service_restart firewall destroys crontab;
carried out manually or by script updates via amtm "u"

tested on 3x ax88u, 2x ac86u under 384.19

reboot required

 

[SeTM]

Another try update RT-AC66U B1 to 384.19, after problems on dirty update .18 > .19 (https://www.snbforums.com/threads/r...19-is-now-available.65801/page-23#post-615204)

This time, all settings have been reset and JFFS cleared. The first few days were all right, but today the problems started again, strange drops in speed as before, both via wifi and via cable. A rollback to .18 solved all the problems.

 

[thecheapseats]

I blew my router's config away - did the wax on/wax off just to see if I could screw it up... no such luck...

 

[gattaca]

Uptime 37 days 21 hour(s) 24 minute(s) 26 seconds
What am I doing wrong

Count your lucky stars! There are few reporting here "no isssue" and I think that's great. We know there's a set of no problem vs lots of problems from all the posts.

Could you please verify if you are or are not using any of what I list below?

BLUF: If you are using basic 384.19 on a AC86U without any extra AMTM tooling then you stand a better much chance of NOT having issues.

Details: I don't know for sure the root-cause of many 384.19 + AC86U issues but I suspect one or more or all of the following are in play.

1. ASUS mucking with the /JFFS size on the AC86U - most certainly started this cascade.
2. Restoring a /JFFS prior backup vs redoing all settings in AMTM + other by hand seems to in the mix.
   1. I've tried both a 100% clean /JFFS empty setup and /JFFS restore, they both end up causing my AC86U GC/CRC errors eventually with all the AMTM tooling turned on and hitting the /JFFS vs USB.
3. TrendNet's AiProtection - I suspect may be causing the AC86U "unplanned reboots"
   1. Why? B/C once I turned AiProtect OFF, my AC86U has now been up for 3 days on 384.19 whereas before it would not last 12 hours without an unplanned reboot.
   2. I have also not observed any DNS issues or 100% CPU sustained since turning AIProtect OFF.
   3. I had AiProtect ON for months running 384.18 with not a single issue or unplanned reboot.
4. Using AMTM scripts in the J* category. (All were working perfectly on 384.18 writing to the /JFFS) + directing those scripts to use /JFFS vs using the USB.
   1. On 384.18 I had been using forever without issue: connmon, ntpMerlin, scMerlin, spdMerlin, DivStats, along with Diversion + Skynet all using the /JFFS for writing data.
   2. On 384.19 I am now only using or have installed: ntpMerlin, scMerlin. along with Diversion + Skynet - so things hitting the /JFFS have virtually stopped.
5. Something lurking with all the ENTWARE updates which were released about the same time.

The above is a close as I can get to a "prime suspect" list causing multiple symptoms of:

1. unplanned reboots,
2. GC/CRC errors on the /JFFS,
3. hours of missing entries in the GUI Logs which just don't show up,
4. observed on multiple occasion very high CPU use on the router for sustained time with no clear consumer in HTOP - happens around 12-14 hours of uptime. In both cases, had to reboot to recover after letting it sit for 10+ minutes hovering near 100%.
5. When both CPUs start approaching 100% sustained, DNS stops working and the howling at home begins. The only recovery route I've found so far is rebooting to restore working order.
6. ...

Stay safe, stay alive. Peace.

 

[Lotta Cox]

Some of my setup. IDK if this will help. Just normal settings.
No guest network
AI Protection: No
Adaptive QOS: Off
Traffic Analyzer: Off
Game Mode: Off
Open NAT: Not Used
USB Application: 2 Portable Hard Drives
AiCloud: Nope

Wireless
Smart Connect: Hell No
Wireless Mode: Auto
Bandwidth: 20/40 MHz, 20/40/80
Control Channel: 2.4-ch 6, 5-ch 36

IPv6: Disable
VPN: Have one setup. Never use it.

In WAN
MAC Address: Cloned from one PC (Did that during a "Red Light of Death" crisis. Kept losing internet with the red light. Most likely caused by T3 and T4 timeouts in cable modem. Comcast was great getting this resolved without a tech visit. They can see it going offline.
DHCP Query: Normal Mode

No Scripts!
I don't see any reason to use them. I have tried a few in the past. Can cause issues if something goes wrong.

Had a few issues with .19 b1 being unstable. Not caused by JFFS
After b2, it became stable after several boots. So I didn't bother with .19 final when released. Barely any difference with the final. Stability is more important than updating to me. I did have to run: service restart_httpd. Once because could not get to the GUI. Happens sometimes. No biggie.
Seems to me that it can take several reboots to be stable. When it is, don't touch it!

 

[gattaca]

Some of my setup. IDK if this will help. Just normal settings.
...

^^^ Yes, TY! You are confirming some of the deltas I quoted above as my "primary suspects..." Your setup is what I believe will be most stable on 384.19 + AC86U. It is a focused KIS implementation with no extras. I see AIProtect is OFF - keep it that way. TY for posting your setup!

 

[jpthsd]

It sounds like 384.19 kind scary update...I might skip it for the next one then

My AC86U Main Aimesh (6 months old) & AC68U Aimesh (4 years old) node are quiet stable with 384.18....it's almost 5 years I haven't been spending much on new routers hehehe!! I spent $194 last 6 month for the RT-AC86U ...

 

[bbunge]

As I wrote in a prior post I went from Asus firmware to Merlin 384.17, WPS factory reset configured WIFI and user. Flashed 384.18 then 384. 19. Did not have to mess with the /jffs as it was correctly resized to 47 MB. Finished doing a manual config:
Smart Connect - Yes
Fixed WIFI channels, 2.4 GHZ ch 1 @ 20 MHZ, 5 GHZ ch 36 @ 80 MHZ, WPS off
LAN/DHCP reservations on, DNS Server 1 set to my Pi-Hole, DNS Filter - router with exception for Pi-Hole
WAN/UPNP enabled - secure, DNS servers set to Quad9, DoT enabled to Quad9 servers, DNSSEC enabled in Stubby via stubby-postconf script
QOS - on fq_codel
Media Server and Samba - off
DDNS - on
OpenVPN server 1 - on
Traffic Monitor file saved to /jffs, Statistic - on
System Log Server on to my Pi 3b+ which is also running Pi-Hole

Router running at about 72% RAM. Had a USB with swap partition mounted for a couple of days with the Traffic Monitor file in an EXT4 partition. As the RAM usage stayed within reason I removed it.

Am beginning to agree that AiProtect may be causing issues in 384.19 on AC86U. I have two AC68U's on 384.18 that have been up for over two months.

 

[hervon]

AiProtect is ON here on my AC86U with Diversion, Skynet & Outbound. Uptime : 34 days. 384.19.

 

[xdj]

So, my AC86U was up for 17 hours, then it rebooted about 15 min ago.
Again, only about 5 devices were connected, sorry 6, I forgot about the AC66U_B1.
There's nothing special running on the AC86U, it's pretty bare at the moment. I've been watching the Syslog periodically and nothing popped except when it rebooted by itself. I was just modifying a google doc when I noticed it said no connection on the google doc web page.
I was streaming a show on Netflix on my TV, working on a doc in Google with my laptop and my daughter was on her phone checking the status of her Doordash meal.
The only issue I have at the moment is that I can not Telnet into the router, I get a connection error with Putty. And of course, the periodic rebooting.
So, I've attached the Syslog file for anyone to browse but I've done everything possible to upgrade to 384.19.
I'm giving up... I'll start again in the morning since my wife will be home soon from work and she'll want to watch a little tv before bed and I don't want to be messing around with the network when she's home reverting back to 384.18.
The whole reason she went into work today was because of the issues I was having with the update!

Link to Syslog to view: https://bit.ly/33CMWaF

IMHO, it's not rocket science. This router is a consumer-based product and you literally should be able to plug it in and it works. Mind you we're using third-party firmware but it's better than the original. Yes, I know...there's some minor configuration to get it up and running but it's very minor. It basically plug n play.
I've spent quite a bit of time today going over pages and pages of fixes, modifications, tricks of the trade, etc on how to get the router to work and diagnosing and testing for issues.
I just can't get over all the suggestions and literal SOP's to get this device to work... it's mind-boggling to read all the information on troubleshooting.
I'm glad I'm not in the industry anymore because I think I spent more time troubleshooting network issues at home than I ever did at work!
Sorry for the rant...I'm hangry, tired, and fed up!
I don't think it's an electrical problem, as I mentioned before, I have good ups with AVR and no other devices are being affected. Network cables in use are very short so static discharge shouldn't be an issue. Software is not my forte so I have no idea, that's why I'm here looking for answers. I'm a hardware guy...
Ok, that's my 2 cents worth for today!
My wife just walked in the door...she went straight into her home office to finish the day...fingers crossed there are no issues!!!

X

It was up for another 17 hours and rebooted by itself...interesting, eh?


Sep 18 14:01:12 smbd[4582]: build_sam_account: smbpasswd database is corrupt! username Download with uid 856 is not in unix passwd database!
Sep 18 14:01:12 smbd[4582]: [2020/09/18 14:01:12.613456, 0] passdb/pdb_smbpasswd.c:1252(build_sam_account)
Sep 18 14:01:12 smbd[4582]: build_sam_account: smbpasswd database is corrupt! username Download with uid 856 is not in unix passwd database!
May 5 01:05:14 kernel: nand: Could not find valid ONFI parameter page; aborting
May 5 01:05:14 kernel: brcmboard registered
May 5 01:05:14 kernel: genirq: Flags mismatch irq 36. 00000000 (brcm_36) vs. 00000000 (brcm_36)
May 5 01:05:14 kernel: pci 0000:00:00.0: of_irq_parse_pci() failed with rc=-22
May 5 01:05:14 kernel: pci 0000:01:00.0: of_irq_parse_pci() failed with rc=-22
May 5 01:05:14 kernel: pci 0001:00:00.0: of_irq_parse_pci() failed with rc=-22
May 5 01:05:14 kernel: pci 0001:01:00.0: of_irq_parse_pci() failed with rc=-22
May 5 01:05:14 kernel: broadcomThermalDrv brcm-therm: init (CPU count 2 2 2 2)
May 5 01:05:14 kernel: eth2 (Ext switch port: 1) (Logical Port: 9) Link UP 100 mbps full duplex
May 5 01:05:14 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link UP 1000 mbps full duplex
May 5 01:05:14 kernel: eth2 (Ext switch port: 1) (Logical Port: 9) Link DOWN.
May 5 01:05:14 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link DOWN.
May 5 01:05:14 kernel: eth2 (Ext switch port: 1) (Logical Port: 9) Link UP 100 mbps full duplex
May 5 01:05:14 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link UP 1000 mbps full duplex
May 5 01:05:14 kernel: eth0 (Int switch port: 3) (Logical Port: 3) Link UP 1000 mbps full duplex
May 5 01:05:14 kernel: hub 1-0:1.0: config failed, hub doesn't have any ports! (err -19)
May 5 01:05:17 acsd: selected channel spec: 0x100b (11)
May 5 01:05:17 acsd: Adjusted channel spec: 0x100b (11)
May 5 01:05:17 acsd: selected channel spec: 0x100b (11)
May 5 01:05:17 acsd: acs_set_chspec: 0x100b (11) for reason APCS_INIT
May 5 01:05:18 acsd: selected channel spec: 0xe29b (157/80)
May 5 01:05:18 acsd: Adjusted channel spec: 0xe29b (157/80)
May 5 01:05:18 acsd: selected channel spec: 0xe29b (157/80)
May 5 01:05:18 acsd: acs_set_chspec: 0xe29b (157/80) for reason APCS_INIT
May 5 01:05:19 Mastiff: init
May 5 01:05:33 modprobe: module scsi_wait_scan not found in modules.dep
May 5 01:05:33 modprobe: module uas not found in modules.dep
May 5 01:05:33 modprobe: module mbcache not found in modules.dep
May 5 01:05:33 modprobe: module jbd not found in modules.dep
May 5 01:05:33 modprobe: module ext3 not found in modules.dep
May 5 01:05:33 modprobe: module ext4 not found in modules.dep
May 5 01:05:33 modprobe: module ext2 not found in modules.dep
May 5 01:05:33 modprobe: module btusbdrv not found in modules.dep
Sep 18 16:53:25 crond[1304]: time disparity of 1249428 minutes detected
Sep 18 16:53:42 miniupnpd[2740]: upnpevents_processfds: 0x55f050, remove subscriber uuid:7f872af1-aa6c-445c-bd74-fad0357f89d5 after an ERROR cb: http://192.168.1.135:49153/
Sep 18 18:13:31 smbd[12239]: [2020/09/18 18:13:31.079195, 0] passdb/pdb_smbpasswd.c:1252(build_sam_account)
Sep 18 18:13:31 smbd[12239]: build_sam_account: smbpasswd database is corrupt! username Download with uid 856 is not in unix passwd database!
Sep 18 18:13:31 smbd[12239]: [2020/09/18 18:13:31.093300, 0] passdb/pdb_smbpasswd.c:1252(build_sam_account)
Sep 18 18:13:31 smbd[12239]: build_sam_account: smbpasswd database is corrupt! username Download with uid 856 is not in unix passwd database!
Sep 18 18:13:31 smbd[12239]: [2020/09/18 18:13:31.106357, 0] passdb/pdb_smbpasswd.c:1252(build_sam_account)
Sep 18 18:13:31 smbd[12239]: build_sam_account: smbpasswd database is corrupt! username Download with uid 856 is not in unix passwd database!
Sep 18 18:13:31 smbd[12239]: [2020/09/18 18:13:31.312409, 0] passdb/pdb_smbpasswd.c:1252(build_sam_account)
Sep 18 18:13:31 smbd[12239]: build_sam_account: smbpasswd database is corrupt! username Download with uid 856 is not in unix passwd database!

Not much in the Syslog....

I did not do any modifications today. But it is interesting it rebooted after the same length of time as it did yesterday.
Again, the router is running with minimal configurations and minimal connections.
I will continue to figure things out...

Cheers,

X

 

[Daveo]

Your samba password database is corrupt that may be what's causing the router to crash & reboot frequently.

It's saying that user ID 856 with username of Download is not in the UNIX password database.

 

[xdj]

Your samba password database is corrupt that may be what's causing the router to crash & reboot frequently.

It's saying that user ID 856 with username of Download is not in the UNIX password database.

Yeah, funny thing is that it never said that until the 384.19 update.
The username has been there for 18 months without any issues until now.
It will be gone when I wipe everything...

Thanks,

X

 

[gattaca]

^^^ If ASUS "updated/improved/altered" the handling of the router's login PW, I'd wager they also did the same with all PW for security purposes....(I'd hope...)

Update: I have another AC86U OTW to allow me to debug this further without making the family more angry with the instabilities in AC86U + 384.19 than they already are. I am now 4 days into no forced reboots and no unplanned reboots as I described above. This will allow me to rebuild from scratch on another AC86U and swap test/prod in/out more quickly if I have an issue.