Release Asuswrt-Merlin 384.19 is now available

[JWoo]

I feel you haven't tried hard enough!

I also tried 384.19 on my RT-AX58U. Everything is fine for a few days. After a couple of days, my 5Ghz devices lose connection. On these devices, my 5Ghz SSID is visible but the devices cannot obtain an IP address. Nothing really strange in the log files / dmesg. Going back to 384.16 or 384.17 fixes it. I tried playing around with using WPA2 personal only instead of WPA2/WPA3 personal but that does not fix it. I know @RMerlin also has an RT-AX58U and wondering if he has seen anything like this or not. Also noticed the GIT activity around the new 386 codebase and that is itself pretty exciting for us router nerds. BTW, I have done clean installs not dirty flashes. There is something going on, maybe with the dnsmasq changes in 384.19 to 2.82-openssl not sure.

 

[Clark Griswald]

I take the RMerlin fw release as my time to clean up my Main/AP and do a clean install of my used scripts. Doing the scripts "clean" install is automated via the amtm script. Since updating to .19 we have not experienced any down time (due to fw/scripts). Honestly people, if The Griswald kid can do it, so can you!

 

[Deleted member 22229]

384.19 was working great until this morning woke up to no internet. After checking on things i noticed my 5GHz band was no longer broadcasting a ssid or signal. Took 3 reboots to get it working again very strange indeed never had this happen before. Went ahead and went back to stock 9505 firmware and will wait for the Alpha 386 Merlin code before i flash again.

 

[L&LD]

@det721, your patience is very low.

Only three reboots needed, and you gave up already? I would have at least tried it once more to see if it lasted the same number of days again before giving up the 5GHz band.

Was a full reset (M&M Config, see link in the signature below) performed when you flashed 384.19_0? From which firmware did you upgrade it from? If you went from stock Asus to RMerlin, that is most likely your issue right there.

 

[Deleted member 22229]

@det721, your patience is very low.

LOL possibly. I upgraded from stock when 19 was released and yes full factory reset via web UI and another from the reset button on the back of the router. All settings were manually entered. Been in this game for some time nothing new to me. The reason i jumped back to stock so quickly is because i need my connection up and running don't have time today for any down time and stock works great as well. I see Merlin is working on putting 386 together so i will just wait that out. Have to say though this was the very first time i ever had any big issues using Merlin and perhaps it was not even .19 that caused it, guess time will tell.

 

[Trent Hubbert]

I also tried 384.19 on my RT-AX58U. Everything is fine for a few days. After a couple of days, my 5Ghz devices lose connection. On these devices, my 5Ghz SSID is visible but the devices cannot obtain an IP address. Nothing really strange in the log files / dmesg. Going back to 384.16 or 384.17 fixes it. I tried playing around with using WPA2 personal only instead of WPA2/WPA3 personal but that does not fix it. I know @RMerlin also has an RT-AX58U and wondering if he has seen anything like this or not. Also noticed the GIT activity around the new 386 codebase and that is itself pretty exciting for us router nerds. BTW, I have done clean installs not dirty flashes. There is something going on, maybe with the dnsmasq changes in 384.19 to 2.82-openssl not sure.

I’m having the same issue with 5G.

 

[Vimes]

Is it possible to change back to 384.18 without issue, on my RT-86U...?
Just understanding that one of the changes to 384.19 the JFFS partition was reduced in size. So going back to the previous firmware will be ok and no need to consider the JFFS partition as it will remain at 47mb...?

Thanks

 

[Xentrk]

Is it possible to change back to 384.18 without issue, on my RT-86U...?
Just understanding that one of the changes to 384.19 the JFFS partition was reduced in size. So going back to the previous firmware will be ok and no need to consider the JFFS partition as it will remain at 47mb...?

Thanks

Shouldn't be an issue. I've seen reports of others reverting.

 

[Xentrk]

^^^^ TY. I was sort of leaning that way with the hidden dirs -> /jffs/.sys/...
So I think this is what I'm going to do... and if I still see issues, then it's @L&LD nuclear reset and start over.

Since already upgraded to 384.19, below. This is similar to what I have in the 384.19 upgrade procedure but not exactly.

a) rm /jffs/.sys/nc/nt_center.db (hidden file in .sys)
b) Backup JFFS
c) Remove USB in GUI, then remove USB physically
c) In GUI, Disable JFFS for scripts
d) Check format, Check Apply
e) Reboot
f) Sit 10 mins
g) Reboot
h) Sit 10 mins
i) Reboot
j) Sit 10 mins
k) Reconnect USB, re-enable JFFS
l) Reboot
m) Let sit 10 minutes
n) Restore JFFS
o) Reboot,...
p) Monitor closely all J* scripts when moved back to JFFS (1 by 1) to see if CRC errors return.
q) No work right? -> Deploy 2nd router as front-door backup for AC86U
r) Implement @L&LD "nuclear reset" option on this AC86U for ultra clean start.
n) ...

Having second thoughts about disabling jffs before applying upgrade since some of the nvram parms, such as dhcp_hostnames and dhcp_staticlist are store in /jffs/nvram directory. May not be a good idea after all.

EDIT:
I ended up going to the site and

• disabled jffs after taking backup
• rebooted
• applied firmware update
• Enabled/format at next boot
• Apply/Reboot
• Restore jffs
• Reboot

All is good.

Don't disable jffs though if doing a remote update as the OpenVPN certs are stored in jffs partition.

 

[Vimes]

Shouldn't be an issue. I've seen reports of others reverting.

Thanks, I did see a warning about downgrading from 384.18 to earlier builds in the release notes but nothing about this one.
Good to know that it should be fine to do so.

 

[Xentrk]

Thanks, I did see a warning about downgrading from 384.18 to earlier builds in the release notes but nothing about this one.
Good to know that it should be fine to do so.

I just took the plunge. See my update above.

 

[Vimes]

I just took the plunge. See my update above.

Thanks, after further "anomalies" whilst using the 384.19 firmware I have returned to the previous 384.18.

As you will be aware the JFFS partition is then restored to 48mb. I did back that up but as I only use this firmware to run a VPN client it was easy enough for me to do a factory reset and manually enter in my details, after formatting the JFFS partition so that it would mount.

All seems fine now, hopefully it will resolve the issues that I have been experiencing.

 

[gattaca]

Having second thoughts about disabling jffs before applying upgrade since some of the nvram parms, such as dhcp_hostnames and dhcp_staticlist are store in /jffs/nvram directory. May not be a good idea after all. .......Don't disable jffs though if doing a remote update as the OpenVPN certs are stored in jffs partition.

Correct. People have warned that OpenVPN config items are stored in JFFS. I didn't know that's where the router stashes the dhcp items. I had to stop using that more than a year back as my list is too large so I use the file approach.

I'm still planning what to do about my in-line AC86U. I'm almost at the point of deploying a dual AC86U blue/green design where I run two AC86U parallel and only update 1 at a time and the next lags 1 release back. Then I can hot-plug switch'm if one has issues. Yeah, that sounds crazy but operationally, I have too many operational dependencies on this SPOF AC86U which puts me in the hot seat with family, work, etc..

You guys, who support 10, 20, 50+ ASUS units in the field, IDK how you handle this one gracefully if those are AC86U units.

So far, with no changes, the existing AC86U is running ok without errors once I moved the J* scripts to the USB SSD. I've seen no 5GHz dropping issues as is being reported by multiple people. But that adds to the strong caution flag.

I'm going to try the route I described above earlier with backing up, reformatting the JFFS but with @Xentrk mods/warning I'm also making sure I do 3 reboots before restoring the JFFS to allow it time to properly format the units. I found a gitlab from 2018 which said the AC86U was having trouble formatting the JFFS and that it took multiple reboots to "get it right"... that was the solution.

I also believe relocating the J* scripts to the USB SSD is the superior long-term solution.

ASUS *@(*@ with this JFFS size on the AC86U has really consumed way too much time. We all want an advanced, best-of-breed router that just works reliability. RMerlin and the many people here, TLC, Yatz, ... deliver "advanced" but have no control on the "reliably parts by ASUS" .

 

[ClockerXP]

Just updated my RT-AC86U to .19 from .17. I did backup the JFSS beforehand, formatted it at the next reboot, reflashed it, and then rebooted it again. I don't really use any custom features except for OpenVPN which seems to be working fine. Are there any issues I should watch out for?

 

[L&LD]

@gattaca, I am one who supports many routers, including the RT-AC86U, for customers and I have yet to see one fail outright. They also understand that they are buying and using a consumer router which is not guaranteed any uptime percentage (let alone 99.999%) either. Everyone seems fine with that so far.

Asus' firmware developers know best what is coming down the pipe and what requirements and stresses the various hardware will be put under. While it is inconvenient to adjust to this today, I don't think anything should be done about it either (including moving all J* scripts to the USB drive) as that just moves the potential point of failure from one place to another.

The move they made to use (internally) an additional 1MB of the JFFS was to make the router more reliable (considering what is coming that they know about).

I wish all customers thought like you and I could set up for them (and charge them the maintenance for) 2 or more identical routers when one will do, but not only does it not make economic sense, it doesn't give you any real form of backup either. If the issues are inherent, they will apply to all copies of that model (at least eventually).

Just like buying two cars to have one as a backup makes little sense, I feel having two identical routers and only using one is the same kind of 'waste'.

For myself, when issues arise, I give some quick troubleshooting tips to my customers and 90% of the time, they don't call back because the issue was resolved. For the remaining 10%, they call back in a few minutes and for the majority, I simply do what I had already suggested to them to get their network back up and running smoothly. The downtime is not the end of the world. Even for customers who have no children and 'just' need to work from home, their workplace understands that sometimes technical issues arise, and they must be dealt with.

I hope your system works for you. But you're doing more than double the work for no perceptible improvement in guaranteed uptime, in my opinion.

 

[L&LD]

@ClockerXP, if your network is working as you need it, then there are no issues to go looking for. If you do find anomalies in the future, post your specific concern/question and help will be here.

 

[krgck]

Solid performance with ac88u, no scripts.

Only what catches my eye is some reason my rtk switch restarts every few days or so. I don't use those so no biggie. But is my router falling apart, or this normal?

Sep  3 13:09:28 rtl_fail:  rtkswitch fail access, restart.
Sep  3 13:09:28 kernel: rtl_error retVal(0) data(0)
Sep  3 13:09:30 kernel: rtl8365mbrtl8365mb initialized(0)(retry:0)
Sep  3 13:09:30 kernel: rtk port_phyEnableAll ok
Sep  3 13:09:31 kernel: txDelay_user: 1
Sep  3 13:09:31 kernel: # txDelay - TX delay value, 1 for delay 2ns and 0 for no-delay
Sep  3 13:09:31 kernel: EXT_PORT:16 new txDelay: 1, rxDelay: 4
Sep  3 13:09:31 kernel: current EXT_PORT:16 txDelay: 1, rxDelay: 4
Sep  3 13:09:31 kernel: rxDelay_user: 4
Sep  3 13:09:31 kernel: # rxDelay - RX delay value, 0~7 for delay setupEXT_PORT:16 new txDelay: 1, rxDelay: 4
Sep  3 13:09:31 kernel: current EXT_PORT:16 txDelay: 1, rxDelay: 4

 

[gattaca]

... But you're doing more than double the work for no perceptible improvement in guaranteed uptime, in my opinion.

BLUF: Two issues have been reported with 384.19 specifically on the AC86U:

1. Issues with 5GHz dropping have been reported earlier.
2. ASUS resizing the JFFS from 48M to 47M has caused some of us issues when using AMTM J* scripts hitting the JFFS. Others have had 0 issues.

YMMV.

I agree with most. Either ASUS has something coming with new features or they are fixing something they just found wrong in the AC86U or both. This is not the first time the AC86U has had "JFFS issues" See -> https://github.com/RMerl/asuswrt-merlin.ng/issues/95

There's a solid market for remote mgt services on non-enterprise hardware to many small businesses, home offices, and even home owners who just "want their routers to work and be properly maintained/patched etc.." vs. the crap delivered the huge service providers who shall remain nameless. Sadly, far too many people believe one just connects a router and it's GTG forever with no maintenance. H'mm, $9.99 / mth anyone or $18.99 with router.

For those that do not know what blue/green cycles are, read here -> https://en.wikipedia.org/wiki/Blue-green_deployment

Yes, you are correct - depending on the vantage. While some may view B/G as 2x the costs, others see reduced business risks a/o a quicker time to recovery as the priorities when something fails like a botched update or later proven FW issues in our case. It's up to the business or customers to make the call on risk and costs to operations. We see this in SLA's all the time and perform trade offs by deploying RAID storage setups, dual PSU, redundant power feeds, dual CRACs, multiple internet feeds, redundant NW switches all the way down the stack, UPSes, Generators, and even redundant backup generators when it's that's important!

As our homes become increasingly dependent on WAH, educate at home, IOT, smart cams, smart(er) appliances, smart vacuums, etc., some of this redundancy will waterfall to increase reliability and remove (shift) SPOFs! Most patrons here are just ahead of that curve! For instance, I run all of my routers on small sine-wave UPSes to prevent the gotchas from all the power blinks we've had here in the past month which is more than 15. My entire setup never blinks unless the provider drops the modem link.

It's funny, I've always said while people believe SPOF is all cost focused, it is really more about reliability and shifting the "gotcha" to somewhere else in the ops stack. Just like I run those UPSes b/c I do not want to deal with the PITA the utility suppliers cost me each time they blink. Which could be countless hours of possible debugging and restoring this and that - it's a huge cost avoidance given the frequency of blinks that I do not want to put-up-with. I can apply the same thing to our routers.

• What's the costs?
• What's the risks to the business?
• What's the costs when "it" fails for N hours?
• What's the cost and risks of doing nothing with "it"?

In a B/G approach, one router is always lagging the other which provides instant fallback in my case by simply moving 2 cables. I would never upgrade both routers in the same cycle as that's a tenant of the b/g approach.

I've (and many here) have gone for 2+ years now without a "nuclear reset" and no gotcha with "dirty upgrades" b/c I stay current and generally give things 2-3 weeks to calm down after RMerlin releases a public version. I guess I just ran outta "luck" this time with 384.19 JFFS change on my AC86U + J* scripting.

I cannot agree that relocating the J* scripts is not a viable option. That move gave me breathing room on the setup and is probably really where high I/O stuff belongs but that's why Yaz designed in a choice. FWIW, my AC86U deploys a 256MiB Macronix SLC NAND which is a higher quality / better than most NAND. The larger erase size of 128KiB and 2048B page size with high I/O of J* scripts may not be good long term... but this is a $200 router and they are using SLC vs QLC etc.. which is good from a RAS PoV. From my current AC86U which has been running J* scripts for a a year+, it boots showing at least 3 "bad blocks" identified. While this is "normal" I see 0 bad blocks on any other router I've checked.

May  5 01:05:11 kernel: jffs2: version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
May  5 01:05:11 kernel: fuse init (API version 7.23)
May  5 01:05:11 kernel: io scheduler noop registered (default)
May  5 01:05:11 kernel: brd: module loaded
May  5 01:05:11 kernel: loop: module loaded
May  5 01:05:11 kernel: nand: Could not find valid ONFI parameter page; aborting
May  5 01:05:11 kernel: nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xda
May  5 01:05:11 kernel: nand: Macronix NAND 256MiB 3,3V 8-bit
May  5 01:05:11 kernel: nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
May  5 01:05:11 kernel: bcm63xx_nand ff801800.nand: Adjust timing_1 to 0x65324458 timing_2 to 0x80040e54
May  5 01:05:11 kernel: bcm63xx_nand ff801800.nand: detected 256MiB total, 128KiB blocks, 2KiB pages, 16B OOB, 8-bit, BCH-4
May  5 01:05:11 kernel: Bad block table found at page 131008, version 0x01
May  5 01:05:11 kernel: Bad block table found at page 130944, version 0x01
May  5 01:05:11 kernel: nand_read_bbt: bad block at 0x0000032e0000
May  5 01:05:11 kernel: nand_read_bbt: bad block at 0x000007b00000
May  5 01:05:11 kernel: nand_read_bbt: bad block at 0x00000f880000
May  5 01:05:11 kernel: >>>>> For primary mtd partition rootfs, cferam/vmlinux.lz mounted as JFFS2, vmlinux fs mounted as UBIFS <<<<<
May  5 01:05:11 kernel: Secondary mtd partition rootfs_update detected as JFFS2 for cferam/vmlinux source and UBIFS for vmlinux filesystem
May  5 01:05:11 kernel: setup_mtd_parts: misc indx 2 name misc3 nvram configured size 1
May  5 01:05:11 kernel: setup_mtd_parts: name misc3 configured size 0x00100000 offset 0xF600000
May  5 01:05:11 kernel: setup_mtd_parts: misc indx 1 name misc2 nvram configured size 47
May  5 01:05:11 kernel: setup_mtd_parts: name misc2 configured size 0x02f00000 offset 0xC700000
May  5 01:05:11 kernel: setup_mtd_parts: misc indx 0 name misc1 nvram configured size 8
May  5 01:05:11 kernel: setup_mtd_parts: name misc1 configured size 0x00800000 offset 0xBF00000
May  5 01:05:11 kernel: Creating 11 MTD partitions on "brcmnand.0":
May  5 01:05:11 kernel: 0x000006460000-0x00000bf00000 : "rootfs"
May  5 01:05:11 kernel: 0x000000560000-0x000006000000 : "rootfs_update"
May  5 01:05:11 kernel: 0x00000f700000-0x00000ff00000 : "data"
May  5 01:05:11 kernel: 0x000000000000-0x000000100000 : "nvram"
May  5 01:05:11 kernel: 0x000000100000-0x000006000000 : "image_update"
May  5 01:05:11 kernel: 0x000006000000-0x00000bf00000 : "image"
May  5 01:05:11 kernel: 0x000006000000-0x000006460000 : "bootfs"
May  5 01:05:11 kernel: 0x000000100000-0x000000560000 : "bootfs_update"
May  5 01:05:11 kernel: 0x00000f600000-0x00000f700000 : "misc3"
May  5 01:05:11 kernel: 0x00000c700000-0x00000f600000 : "misc2"
May  5 01:05:11 kernel: 0x00000bf00000-0x00000c700000 : "misc1"
...

Oh well, back to the plan... Take care. We are on the same page. Stay safe, stay alive. Peace.

 

[Mutzli]

I visited this page this morning. I just tried this evening (now home to download the driver) and.... the page no longer exists.

Strange, but you can also download the administration version and manually install it through the device manager.

 

[Sebastien Bougie]

Since I installed this version i'm having trouble adding new device to my network. I see them connect in the wireless log but no ip assign to them. I formatted the JFFS didnt changed anything, Anybody else with the same problem? Any solution?