What's new

Release Asuswrt-Merlin 384.19 is now available

  • 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.
This is how all over the place the current firmware + GPL release situation is, as of tonight:

https://docs.google.com/spreadsheet...Xq4I0i6lQo-RN48SGFSkKNKq8/edit#gid=2007755387

I can't deal anymore with the complete mess that 384 releases have become on Asus's end, with some GPLs being 4+ months outdated, only two models out of 10 sharing the same release, two models not even having recent enough GPLs to be compatible with every other models, etc...

I'm done with firmware releases until Asus re-unifies everything and starts issuing more regular GPL releases, which most likely won't be happening until everything is moved to the 386 code base. So, next release might be 3 months from now, 6 months from now, a year from now? I don't know, but it will take whatever time it takes. I'm tired of trying to mix and match all of these separate releases, and dealing with the aftermath.

So until then, run whatever works for you, be it 384.19, 384.18 or Asus's stock. It's out of my control, and I simply give up trying to keep it all together in the current situation.

Got my vote! You only need to look at the changelog to realise it's been a nightmare for a long time.

Will continue to use Merlin 384.13 on AC88U until code base is unified.
 
as of 384.19, if I want to give LAN access to router's USB share, which one is safer? NFS or SMB mounts?
thx
 
Definitely all the issues you've posted on the forum recently look like JFFS corruption which is a known issue on 384.19 + AC86U.

You needed to have done the JFFS backup thingy as per the firmware installation instructions ... if you didn't, you are going to have to wipe your JFFS partition and start over, otherwise you'll just get more and more JFFS corruption as time goes on, and it will cause issues with your custom scripts etc....
I re-formatted USB drive and JFFS this morning, re-installed scripts, started from scratch with everything but resetting the router. That will be my next step, if any. All is clean from the USB up, and everything seems to be smooth now. Only took a couple of hours, and I felt like I would continue having problems if I didn't. There must have been something corrupt about my JFFS backup, because I reformated it (after I figured out to hit the RESET button at the bottom) and uploaded it and had problems until now. Now my RAM allocation is back to 92%, and my head is empty. Only thing I lack is configuring the NTPmerlin servers, I think.
thanks,
jts
 
After reading all pages, two things were mentioned which concern me.

a) if you change the default login userid from admin to something else, you may get burned somewhere in this "format and then restore JFFS after flashing to 384.19" process. It seems no matter what we do, we should "restore the JFFS backup" period. I think @L&LD made that clear! TY!

So before we do this 384.19 on an AC86U, should the recommendation be: "If you have changed the router's login ID from admin to something else, change it back to "admin" before updating 384.19" Is that accurate or recommended?

b) With all the JFFS issues with 384.19 + AC86U.... I feel like I want to get a spare AC86 testing router and practice the upgrade on it first. Since I've never done that, if I backup the router's config in the GUI and the JFFS in the GUI, can I then restore them to a different AC86U? Will all the router's setups carry over with those 2 items restored?

I remember there being a full backup router tool but then support was dropped and the tool fell outta favor. Now all these various "backup" this and that are merging in my head.

FWIW, I'm running AMTM with Diversion, Skynet and many of the other tools. I cannot mess this up or the family will be howling because with everyone working from home, uptime is now critical in my household. Once my AC86 goes down, everything goes with it. It would be much easier to swap in a replacement and fall back to the untouched router if it craps out.

The upgrades on my AC88U and AC1900's went well. No issues I've seen but I backed up the configs and JFFS anyway to CMA.

FWIW, I use a slightly different process that has been published here. I always backup the config and JFFS, then I reboot the router before doing anything else. Then I let it settled for a 5-10 mins, then login and flash to next level, then reboot one more time. This has worked for dirty upgrades for years without issues. IDK why, it just has (knocking on my real wooden desk). As always, YMMV. Thanks!
 
Last edited:
@gattaca
I removed my usb, upgraded fw on my AC86, and all was/is well. I then reformatted my usb drive and did a clean install of my scripts.
 
Last edited:
Since upgrading to 384.19 (from 384.18) Only one of my mesh nodes is reporting clients attached. My main router is an RT-AX88U with two RT-AC86U, as mesh nodes. I've tried the stock firmware (3.0.0.4.384_82072-gc842320) on the mesh nodes as well, and still no difference. At any given time, I generally have 15-25 devices connected. Some of my devices are struggling to get a connection after this upgrade, but the odd thing is when they do connect it does appear to be a strong connection with good throughput, but easily loses the connection. Maybe it is just misreporting, not sure if I can ssh in and see the connected devices?

I don't have any load balancing enabled, nothing but the default smart connect rules.

I have not tried a factory reset of the RT-AX88U, but would symptoms like this warrant a reset?
 
After reading all pages, two things were mentioned which concern me.

a) if you change the default login userid from admin to something else, you may get burned somewhere in this "format and then restore JFFS after flashing to 384.19" process. It seems no matter what we do, we should "restore the JFFS backup" period. I think @L&LD made that clear! TY!

So before we do this 384.19 on an AC86U, should the recommendation be: "If you have changed the router's login ID from admin to something else, change it back to "admin" before updating 384.19" ??

b) With all the JFFS issues with 384.19 + AC86U.... I feel like I want to get a spare AC86 testing router and practice the upgrade on it first. Since I've never done that, if I backup the router's config in the GUI and the JFFS in the GUI, can I then restore them to a different AC86U? Will all the router's setups carry over with those 2 items restored?

Don't sweat it! Post 140 means you can fix this, as long as you have SSH enabled. Worked perfectly for me.
 
You needed to have done the JFFS backup thingy as per the firmware installation instructions ... if you didn't, you are going to have to wipe your JFFS partition and start over, otherwise you'll just get more and more JFFS corruption as time goes on, and it will cause issues with your custom scripts etc....

Having had an issues with a previous update on my AC86 and having to wipe my JFFS partition one thing I have changed in my update process is besides backing up the JFFS is that instead of unmounting then removing attached USB drives before an update I just unmount them so when the router reboots after applying the update the drive with the scripts are up and available. Worth a try as the AC86 has its set of peculiarities.
 
Could someone explain what "Added support for static routes for PPTP/L2TP VPN clients, on the Static Route page (themiron)" means? Does that mean that we can set set some of our devices with static IPs to use the VPN connection while others use the home internet connection, or does it mean that whenever we connect to the VPN server it will always give us the same static IP?
 
Hi,

Same problems on AX88U with 384.19
No connexion during 20-30 minutes... then all is OK.
Reboot and web connexion is now fast.

My first log can help to find problem... maybe !

Aug 19 21:05:14 ntpd: Initial clock set
Aug 19 21:05:14 miniupnpd[1748]: HTTP listening on port XXXXXXX
Aug 19 21:05:14 miniupnpd[1748]: Listening for NAT-PMP/PCP traffic on port XXXX
Aug 19 21:05:14 rc_service: ntpd_synced 1734:notify_rc restart_diskmon
Aug 19 21:05:14 disk_monitor: Finish
Aug 19 21:05:14 start_ddns: update WWW.ASUS.COM update@asus.com, wan_unit 0
Aug 19 21:05:14 disk_monitor: be idle
Aug 19 21:05:15 inadyn[1786]: In-a-dyn version 2.7 -- Dynamic DNS update client.
Aug 19 21:05:16 WLCEVENTD: Auth 70:EE:50:xx:xx:xxx
Aug 19 21:05:16 WLCEVENTD: Assoc 70:EE:50:xx:xx:xx
Aug 19 21:05:16 WLCEVENTD: Auth 48:D6:YY:YY:YY:YY
Aug 19 21:05:16 WLCEVENTD: Assoc 48:D6:YY:YY:YY:YY
Aug 19 21:05:17 WLCEVENTD: Auth 48:D6:YY:YY:YY:ZZ
Aug 19 21:05:17 WLCEVENTD: Assoc 48:YY:YY:YY:YY:ZZ
Aug 19 21:05:18 kernel: SHN Release Version: 2.0.1 4b635f32
Aug 19 21:05:18 kernel: UDB Core Version: 0.2.18
Aug 19 21:05:18 kernel: sizeof forward pkt param = 280
Aug 19 21:05:18 kernel: The For ALL DEVICES flag of Prof 2 has been set to ENABLE
Aug 19 21:05:18 BWDPI: fun bitmap = 47f
Aug 19 21:05:18 inadyn[1786]: Update forced for alias XXXXXXXXXXXXXXXXXX.asuscomm.com, new IP# XX.XX.XX.XX
Aug 19 21:05:18 kernel: The For ALL DEVICES flag of Prof 1 has been set to ENABLE
Aug 19 21:05:20 inadyn[1786]: Updating cache for XXXXXXXXXXXXXXXXXXXXX.asuscomm.com
Aug 19 21:05:22 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
Aug 19 21:05:22 dhcp_client: bound 192.166.0.3/255.255.255.0 via 192.166.0.1 for 86400 seconds.
Aug 19 21:05:33 kernel: ubi1: attaching mtd10
Aug 19 21:05:33 kernel: ubi1: scanning is finished
Aug 19 21:05:33 kernel: ubi1: attached mtd10 (name "misc1", size 8 MiB)
Aug 19 21:05:33 kernel: ubi1: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
Aug 19 21:05:33 kernel: ubi1: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
Aug 19 21:05:33 kernel: ubi1: VID header offset: 2048 (aligned 2048), data offset: 4096
Aug 19 21:05:33 kernel: ubi1: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0
Aug 19 21:05:33 kernel: ubi1: user volume: 1, internal volumes: 1, max. volumes count: 128
Aug 19 21:05:33 kernel: ubi1: max/mean erase counter: 21/7, WL threshold: 4096, image sequence number: 527176359
Aug 19 21:05:33 kernel: ubi1: available PEBs: 0, total reserved PEBs: 64, PEBs reserved for bad PEB handling: 4
Aug 19 21:05:33 kernel: ubi1: background thread "ubi_bgt1d" started, PID 2210
Aug 19 21:05:34 kernel: UBIFS (ubi1:0): background thread "ubifs_bgt1_0" started, PID 2235
Aug 19 21:05:34 kernel: UBIFS (ubi1:0): UBIFS: mounted UBI device 1, volume 0, name "nvram"
Aug 19 21:05:34 kernel: UBIFS (ubi1:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
Aug 19 21:05:34 kernel: UBIFS (ubi1:0): FS size: 5840896 bytes (5 MiB, 46 LEBs), journal size 1396736 bytes (1 MiB, 11 LEBs)
Aug 19 21:05:34 kernel: UBIFS (ubi1:0): reserved for root: 0 bytes (0 KiB)
Aug 19 21:05:34 kernel: UBIFS (ubi1:0): media format: w4/r0 (latest is w4/r0), UUID 2A675828-417B-4663-A146-8F7254785AF, small LPT model
Aug 19 21:05:34 kernel: UBIFS (ubi1:0): un-mount UBI device 1
Aug 19 21:05:34 kernel: UBIFS (ubi1:0): background thread "ubifs_bgt1_0" stops
Aug 19 21:05:34 kernel: ubi1: detaching mtd10
Aug 19 21:05:34 kernel: ubi1: mtd10 is detached
Aug 19 21:05:42 crond[1265]: time disparity of 1206120 minutes detected
Aug 19 21:06:10 kernel: bcm_i2c: bus 0: Failed to detect SFP: 100 retries exhausted

Aug 19 21:07:42 aaews[2114]: Tunnel built successfully.
Aug 19 21:13:22 aaews[2114]: Tunnel built successfully.
Aug 19 21:20:15 aaews[2114]: Tunnel built successfully.
Aug 19 21:48:42 WLCEVENTD: Auth A4:77:AA:AA:AA:AA
Aug 19 21:48:42 WLCEVENTD: Assoc A4:77:AA:AA:AA:AA
Aug 19 21:48:42 WLCEVENTD: Auth 74:D6:BB:BB:BB:BB
Aug 19 21:48:42 WLCEVENTD: Assoc 74:D6:BB:BB:BB:BB
(...)
 
Last edited:
Make sure you load the latest driver from Intel. Intel fixed some reconnect issues with this release:
21.90.3
Actually the latest are 21.110.1... but for some reason Intel took down the customer version and only left the IT one ;)
 
Does anyone know if this latest version has these vulnerabilities patched for the RT-AC3100?
Annotation 2020-08-19 175001.png
 
Some cellular providers (I'm looking at you Verizon) specifically force phones on their network NOT to use WiFi calling if there is a cellular signal, no matter how poor. The phones will drop calls repeatedly or cut out parts of conversations rather than use your WiFi. In Android 7 you could force Verizon phones to use WiFi calling with a little ADB 'hack' which is why I have spent three years dismissing several alerts a day asking me to update my version of Android.

My Pixel 4 XL on Verizon with 1 or 2 signal bars (RSRP=-111 RSSI=-83 RSRQ=-15) will make and recieve wifi calls all day long.
 
After upgrading AX58u to .19 from .18, httpd/web interface seems to only load 10% of the times - login page shows up after restart, but after that nothing. Not sure if this is related to jffs? I took a backup but without the web interface, unsure how to restore it.
 
Last edited:
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