Release Asuswrt-Merlin 384.19 is now available

[Butterfly Bones]

Hi All,

I'm on this latest FW with my AX88U.
Is it normal that the RAM usage is always around 95-96% sometimes more?
Fresh setup from scratch out of the box, logs are not stored in RAM, statistics turned on, amtm on USB...
Anyone experiencing this?

Yes it is normal. This question of "high" RAM usage comes up often. Here is one reply I posted to help understand Linux RAM use.

Max RAM% allocated usage?

My RAM is usually between 93-95%, which has crept up from about 89% over the last few months and weeks. I read some threads where one should be concerned if there wasn't over 10% available. My RT-AC86U has an Asusmesh node and not over 20 clients usually , and they are pretty small potatoes...

www.snbforums.com

 

[Centrifuge]

"pre-boot the router"

Thanks for braving this update for the 86U, so you're saying reboot before backing up the JFFS? Update, reboot, restore JFFS, reboot, then reinstall the scripts and so on? Did you have any log/pass problems? Did you have a VPN server working that persists after the update?

 

[gattaca]

^^^ Correct. I always follow @L&LD guides b/c they keep me (and many others) outta the ditch.

The one mod I make is I backup the router and jffs, then reboot, let it setting 10+ minutes (I'm running many AMTM scripts), then I backup the router and jffs again before performing any updates. For me that seems to clear out any lingering gremlins.

This time though we were warned about the issues with jffs.. on AC86U, so I did the above, then restored the jffs, then rebooted. I let it sit a while and the jffs was now writeable and I thought GTG.. but after 2 days, most of my AMTM scripts had stopped reporting or graphing from the GUI. After that, I decided to remove the AMTM J* scripts and reinstall them all. That seems to have fixed the AMTM utilities.

That makes me think that the restoring over top of a running router (with all these utilities active) may not be capable of doing everything we think it is doing. Some people has proposed just doing the jffs format ahead of time and if I did NOT have a bunch of AMTM utils, I surely would have. I do not think we have the final answer on this...

There were no log problems I saw but I did not go check every "addon" in the GUI either. That would have been a clue things were not GTG. No, I do not run a VPN on this AC86U.

 

[Xentrk]

^^^ Correct. I always follow @L&LD guides b/c they keep me (and many others) outta the ditch.

The one mod I make is I backup the router and jffs, then reboot, let it setting 10+ minutes (I'm running many AMTM scripts), then I backup the router and jffs again before performing any updates. For me that seems to clear out any lingering gremlins.

This time though we were warned about the issues with jffs.. on AC86U, so I did the above, then restored the jffs, then rebooted. I let it sit a while and the jffs was now writeable and I thought GTG.. but after 2 days, most of my AMTM scripts had stopped reporting or graphing from the GUI. After that, I decided to remove the AMTM J* scripts and reinstall them all. That seems to have fixed the AMTM utilities.

That makes me think that the restoring over top of a running router (with all these utilities active) may not be capable of doing everything we think it is doing. Some people has proposed just doing the jffs format ahead of time and if I did NOT have a bunch of AMTM utils, I surely would have. I do not think we have the final answer on this...

There were no log problems I saw but I did not go check every "addon" in the GUI either. That would have been a clue things were not GTG. No, I do not run a VPN on this AC86U.

The key is to first reformat the JFFS partition, reboot, then restore your JFFS backup. The format will resize and partition the disk to accommodate the backup.

 

[Xentrk]

Have a problem with 384.19 on a RT-AC3100 when using hotel internet... Being in a hotel I run everything through a VPN (Mullvad) except for the router. The router (WAN) is connected via ethernet to the hotel internet service.

It has a login page once you plug in and every 24 hours I get dropped and usually just reboot the router and the login screen pops up and with a room number and name it allows access to the internet again...

On 384.18 it was no problem rebooting and accessing the internet again. I loaded 384.19 in the middle of the day and access to the internet was still there. However, once the 24 hour drop occurs a simple reboot with .19 and it doesn't present the login screen for hotel access to the internet.

If I drop back to .18 then reboot after it is loaded the login screen appears and I can access the internet. I have done that a few times and it works each time.

The only thing in the logs is that ntpd doesn't start which obviously will not allow the VPN to start... but I do not even get the hotel login screen either.

Since the OpenVPN implementation changed on this release I thought I'd post before going any further and completely wiping and manually reconfiguring the router.

Thanks, David

I doubt the OpenVPN changes are contributing to the issue you are having. The NTPD issue is probably due to the router not having WAN access since the authentication step hasn't been performed.

Several releases back, some ntpd issues were resolved by setting the item below to "No"
Tools -> Other Settings -> Wan: Use local caching DNS server as system resolver (default: No)

I use a GLiNet travel router when staying at hotels and always have issues with the splash screens. The OpenWRT firmware on my travel router has a repeater mode. I usually have to connect to the hotel wifi first and note the IP address of the splash page. After I connect a device to the travel router, I then go a browser and enter the IP address of the splash page and authenticate. After that, all devices that connect to the travel router can then logon.

 

[Smokey613]

No, don't expect anything anytime soon. That is only one single model (RT-AC86U), the merge isn't fully debugged yet, none of the AX-specific code has been merged in yet (I have to comb through my ax branch one commit at a time), and it's based on early beta 386 code which is not ready for public usage either.

Just one more reason I am very satisfied with my pair of RT-AC86U routers.

 

[dcguru]

Hey All

Upgraded a AC86U from .13 to .19, backed up JFFS before flashing.

After upgrade I tried to restore JFFS (after formatting) but it was just all over the place and not behaving properly. So I clean formatted and restored to default, then formatted JFFS and installed scripts 1 by 1.

I'm seeing pretty high loads(4.2 4.1, 4.0) and I took a look at what was running. Nothing seemed to be using CPU, but I did see a couple of processes using the VSZ under top. Firstly diversion (so i stopped and restarted it, which fixed it, then reinstalled diversion for good measure) but second amas_lib reports 11% usage on VSZ. If I kill it, CPU drops off and router seems to be ok, but it seems to trigger every now and again. Seems other people have reported this here: https://www.snbforums.com/threads/amas_lib-high-cpu-usage.55624/ previously.

I haven't configured this router in an AIMESH setup ever, so its very odd.

Finally even with these processes killed off I still see loads as below, is this normal on an 86U?

CPU: 0.9% usr 0.1% sys 0.0% nic 98.9% idle 0.0% io 0.0% irq 0.0% sirq
Load average: 2.37 2.26 2.21

My USB stick is 2GB and in the USB3.0 port, ive not got auto channel selection on either of the wireless channels, no QOS or AI protection enabled

Any pointer or suggestions welcome please!

 

[gattaca]

The key is to first reformat the JFFS partition, reboot, then restore your JFFS backup. The format will resize and partition the disk to accommodate the backup.

OK but what's unclear, at least to me, is what happens on the reboot after the JFFS is reformatted to all our AMTM scripts which boot and run automatically and had files on this newly formatted JFFS? Many of AMTM scripts point to JFFS for files, db, etc.. So do these scripts just "freak out a bit?" "do they just stop working - gracefully?" Then restore the backed up JFFS to the newly formatted JFFS and then reboot once more and the AMTM scripts recover and we are GTG? This is the part that's confusing to me. It feels like we are saying, "...reformat your C: drive, then boot to Windows to restore it.." Is that not what's happening with the AMTM tooling?

This feels like a test case gotcha that we really haven't encountered or had to deal with before now + AMTM.

So maybe you are saying:
a) backup router and jffs
b) then click the box to format JFFS
c) reboot and let sit 5-10 mins
d) login and then restore the JFFS backup,
e) reboot router,
f) let sit 5-10 minutes
g) login and then check that ops look normal, verify the AMTM tooling is happy. Is the AMTM tooling working by graphing and collection points for the router's "add on" GUI tab?

If there were no AMTM scripts involved, I'd say that works perfectly. BUT, toss in what is happening with AMTM and it murks up the path to GTG in my brain and from what I saw during my upgrade on SUN, just restoring the JFFS did not work b/c all the AMTM scripts were not working properly - at least the ones I mentioned above in the add-ons tab were not graphing or collecting data properly.

But I may be overthinking this as a computer guy for more decades than I'll admit. The "reformat path" has not been "critical" in the steps we've so far posted to make this work reliability. But I think we are close. It's like merlin needs a "reboot the router but do not run the AMTM scripts control gate checkbox...." to allow us to do all the above? It could be as simple as the AMTM scripts do not run if the JFFS is "empty....?"

@L&LD and folks chime in. A lot of AC86U owners using AMTM are interested!

This thread has gotten eerily quiet.

 

[Lord Lovaduck]

Hi,
kindly look at my start at this link.
Thank you

Well, I clearly see you are an italian dude (ciao amico! Sono argentino, è quasi lo stesso!) dealing with a double NAT environment cascading from a FASTGate DGA4131 router.
The images don't clarify anything else to me except that simple fact. Now let's work with that and the comment from your post, which is that you have a fixed IP Address. For sure that static IP ought to make the use of DDNS unnecessary, doesn't it? You can access your cameras (you mention CAM so I guess that's what it is) just by using the ip address. You could also find out what's the hostname associated with that address by going to a command prompt in windows and doing a ping -a 2.229.xxx.xxx or online at https://whatismyipaddress.com/ip-hostname. It may or may not be there, and it may also be complicated so not sure if this would help but it might. You are using the ASUS DDNS service... there are alternatives that may be better suited for your environment. We can discuss that later if relevant.
If you don't use the DGA4131 for connecting other clients in your network, only the Asus AC68U, you may simply put your AC68U lan IP address in the DMZ of the DGA router. This will make all incoming ports to be redirected to the AC68U so it would be less affected by the double NAT. The DMZ entry is usually found in the firewall pages of your main router configuration.
You may also need to have proper port redirection set up at the AC68U for the camera you are using. If you decide to do something like this, then for sure you need your firewall up in your AC68U.

 

[DCT]

RT-AC86U 384.19 Been up for 6 days without a reboot, I think everything is working good but if someone that knows more about what the data should look like can take a peek.

 

[doczenith1]

OK but what's unclear, at least to me, is what happens on the reboot after the JFFS is reformatted to all our AMTM scripts which boot and run automatically and had files on this newly formatted JFFS? Many of ATAM scripts point to JFFS for files, db, etc.. So do these scripts just "freak out a bit?" "do they just stop working - gracefully?" Then restore the backed up JFFS to the newly formatted JFFS and then reboot once more and the AMTM scripts recover and we are GTG? This is the part that's confusing to me. It feels like we are saying, "...reformat your C: drive, then boot to Windows to restore it.." Is that not what's happening with the AMTM tooling?

This feels like a test case gotcha that we really haven't encountered or had to deal with before now + AMTM.

So maybe you are saying:
a) backup router and jffs
b) then click the box to format JFFS
c) reboot and let sit 5-10 mins
d) login and then restore the JFFS backup,
e) reboot router,
f) let sit 5-10 minutes
g) login and then check that ops look normal, verify the AMTM tooling is happy. Is the AMTM tooling working by graphing and collection points for the router's "add on" GUI tab?

If there were no AMTM scripts involved, I'd say that works perfectly. BUT, toss in what is happening with AMTM and it murks up the path to GTG in my brain and from what I saw during my upgrade on SUN, just restoring the JFFS did not work b/c all the AMTM scripts were not working properly - at least the ones I mentioned above in the add-ons tab were not graphing or collecting data properly.

But I may be overthinking this as a computer guy for more decades than I'll admit. The "reformat path" has not been "critical" in the steps we've so far posted to make this work reliability. But I think we are close. It's like merlin needs a "reboot the router but do not run the AMTM scripts control gate checkbox...." to allow us to do all the above? It could be as simple as the AMTM scripts do not run if the JFFS is "empty....?"

@L&LD and folks chime in. A lot of AC86U owners using AMTM are interested!

My plan is:

a) backup router and jffs
b) unmount flash drive with scripts and remove flash drive
c) click the box to format JFFS
d) reboot and let sit 5-10 mins
e) reboot again just to make sure JFFS is happy
f) login and then restore the JFFS backup,
g) pull power cord on router
h) plug flash drive back in and power on router

 

[Vimes]

Hello

I had been running 384.18 on my 86U fine with no issues. Nothing "exotic" with my needs, apart from using a VPN client. The config for that client is generated successfully by AIRVPN, the online company I use for my VPN needs.

Noted the potential issues with the JFFS partition due to its reduction in size.
Backed up the JFFS partition(12mb or so) but then, router gone through many firmware revisions and settings, formatted the partition on reboot and so rebooted.
All went well with the newly created JFFS partition mounted, about 1.3mb in size of 48mb available.
Then backed up that JFFS partition again, just in case.
Downloaded and flashed successfully with the 384.19 firmware.
Rebooted and noted that the JFFS partition was not mounted.
Selected to reformat that partition and reboot.
Rebooted and all seemed well. 1.34mb of 47mb used on the JFFS partition.
Connected fine to the Internet, no issues so far.

The problem......

Created usual config from AIRVPN and uploaded it as usual into Client 1 for the VPN.
Rather than the usual immediate connection this time it does not connect and remains "connecting"
Errors noted in the system log.
Reset the Client 1 to defaults. Applied and the settings from the config then went empty but the Client 1 still changed to "connecting" even tho it was set to "off".
That would not change.
Reboot router would not change.
Reboot router and format JFFS and then it was fine with no remaining "connecting" issues
This time I repeated the above but tried VPN Client 2.

Errors within System log......

Spoiler

Aug 28 09:07:25 ovpn-client2[4083]: OpenVPN 2.4.9 arm-buildroot-linux-gnueabi [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Aug 14 2020
Aug 28 09:07:25 ovpn-client2[4083]: library versions: OpenSSL 1.1.1g 21 Apr 2020, LZO 2.08
Aug 28 09:07:25 ovpn-client2[4084]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Aug 28 09:07:25 ovpn-client2[4084]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug 28 09:07:25 ovpn-client2[4084]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug 28 09:07:28 ovpn-client2[4084]: TCP/UDP: Preserving recently used remote address: [AF_INET]89.238.150.42:443
Aug 28 09:07:28 ovpn-client2[4084]: Socket Buffers: R=[524288->524288] S=[524288->524288]
Aug 28 09:07:28 ovpn-client2[4084]: UDP link local: (not bound)
Aug 28 09:07:28 ovpn-client2[4084]: UDP link remote: [AF_INET]89.238.150.42:443
Aug 28 09:07:28 ovpn-client2[4084]: TLS: Initial packet from [AF_INET]89.238.150.42:443, sid=2e338ce1 b70ce898
Aug 28 09:07:28 ovpn-client2[4084]: VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
Aug 28 09:07:28 ovpn-client2[4084]: VERIFY KU OK
Aug 28 09:07:28 ovpn-client2[4084]: Validating certificate extended key usage
Aug 28 09:07:28 ovpn-client2[4084]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Aug 28 09:07:28 ovpn-client2[4084]: VERIFY EKU OK
Aug 28 09:07:28 ovpn-client2[4084]: VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Arion, emailAddress=info@airvpn.org
Aug 28 09:07:28 ovpn-client2[4084]: Control Channel: TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
Aug 28 09:07:28 ovpn-client2[4084]: [Arion] Peer Connection Initiated with [AF_INET]89.238.150.42:443
Aug 28 09:07:29 ovpn-client2[4084]: SENT CONTROL [Arion]: 'PUSH_REQUEST' (status=1)
Aug 28 09:07:29 ovpn-client2[4084]: PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway ipv6 def1 bypass-dhcp,dhcp-option DNS 10.17.244.1,dhcp-option DNS6 fde6:7a:7d20:df4::1,tun-ipv6,route-gateway 10.17.244.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 fde6:7a:7d20:df4::10f7/64 fde6:7a:7d20:df4::1,ifconfig 10.17.244.249 255.255.255.0,peer-id 1,cipher AES-256-GCM'
Aug 28 09:07:29 ovpn-client2[4084]: OPTIONS IMPORT: timers and/or timeouts modified
Aug 28 09:07:29 ovpn-client2[4084]: OPTIONS IMPORT: compression parms modified
Aug 28 09:07:29 ovpn-client2[4084]: OPTIONS IMPORT: --ifconfig/up options modified
Aug 28 09:07:29 ovpn-client2[4084]: OPTIONS IMPORT: route options modified
Aug 28 09:07:29 ovpn-client2[4084]: OPTIONS IMPORT: route-related options modified
Aug 28 09:07:29 ovpn-client2[4084]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Aug 28 09:07:29 ovpn-client2[4084]: OPTIONS IMPORT: peer-id set
Aug 28 09:07:29 ovpn-client2[4084]: OPTIONS IMPORT: adjusting link_mtu to 1625
Aug 28 09:07:29 ovpn-client2[4084]: OPTIONS IMPORT: data channel crypto options modified
Aug 28 09:07:29 ovpn-client2[4084]: Data Channel: using negotiated cipher 'AES-256-GCM'
Aug 28 09:07:29 ovpn-client2[4084]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Aug 28 09:07:29 ovpn-client2[4084]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Aug 28 09:07:29 ovpn-client2[4084]: GDG6: remote_host_ipv6=n/a
Aug 28 09:07:29 ovpn-client2[4084]: TUN/TAP device tun12 opened
Aug 28 09:07:29 ovpn-client2[4084]: TUN/TAP TX queue length set to 1000
Aug 28 09:07:29 ovpn-client2[4084]: /sbin/ifconfig tun12 10.17.244.249 netmask 255.255.255.0 mtu 1500 broadcast 10.17.244.255
Aug 28 09:07:29 lldpd[1368]: removal request for address of 10.17.244.249%22, but no knowledge of it
Aug 28 09:07:29 lldpd[1368]: removal request for address of 10.17.244.249%22, but no knowledge of it
Aug 28 09:07:29 ovpn-client2[4084]: /sbin/ifconfig tun12 add fde6:7a:7d20:df4::10f7/64
Aug 28 09:07:29 ovpn-client2[4084]: Linux ifconfig inet6 failed: external program exited with error status: 1
Aug 28 09:07:29 ovpn-client2[4084]: Exiting due to fatal error

Now what happens is that the Client 2 VPN will remain trying to connect even if I try and revert the settings to the default. The only way that I have found to stop that is the reformat the JFFS partition and then everything "stops" and no client is trying to connect, which fails.

Screen shots below, and 1 thumbnail shows the status of the VPN client

Spoiler

Screen Shot 2 thumbnail shows the Open VPN client settings and even though it is set to "off" it still tries to connect, but there are those errors noted in the system logs.

any advice please, keeping that advice "simple" if possible
EDIT: Tried to reset Client 2 VPN to the default settings. The logs show.....

Spoiler

Aug 28 09:36:04 rc_service: httpd 1267:notify_rc stop_vpnclient2;clearvpnclient2
Aug 28 09:36:04 openvpn: Resetting client (unit 2) to default settings
Aug 28 09:36:24 rc_service: httpd 1267:notify_rc restart_vpnclient2
Aug 28 09:36:24 ovpn-client2[14058]: Options error: You must define CA file (--ca) or CA path (--capath)
Aug 28 09:36:24 ovpn-client2[14058]: Use --help for more information.
Aug 28 09:36:24 openvpn: Starting OpenVPN client 2 failed!

but the client now shows......
status.....

Spoiler

settings...

even though it is set to "off" and should not be trying to connect
To return a "clear" status to the VPN client I reset the JFFS partition and rebooted. Partition mounted fine and no "connection" issues noted with the VPN clients. But they will no longer connect as they did previously without generating the noted error in the system log

 

[gattaca]

I'm sorry, I have no experience with the VPNs. If there's a specific forum thread you might try there.

What I will share is I feel after this JFFS "resizing" experience, I really hope ASUS does not mess with the JFFS ever again or at least as long as I own an AC86U. While my AMTM tooling now appears to be working/graphing/collecting data, I now have less confidence my setup is really OK b/c I did not "format the jffs" and then restore it as part of this upgrade. I just restored it...

@doczenith1 please post your results once your try that route.

@L&LD I read you said you did a bunch of routers without formatting the jffs. Have you had any issues since with any of the AMTM tooling? You did add in a post (but you cannot modify the original post below) that you must restore the jffs - that is not optional - but you did not have to add "check format the jffs", then "reboot" to the process...?

https://www.snbforums.com/threads/b...eta-is-now-available.65581/page-6#post-608612

Stay safe, stay alive. Peace.

 

[Vimes]

Thanks, appreciate that, you too stay safe and well in these troubled times.

Maybe I'm wrong but I do not think that my issues are necessarily related to the JFFS changes. I think that they might have something to do with the noted changes to the VPN implementation, but that is not based on anything but noted changes in this release.
All that I do know is now the VPN client no longer works or behaves as it has previously when trying to use it. Unsure of the meaning of the errors in the system log file.

Due to the partition changes in this release I would not feel assured going back to a previous firmware, not that I would really want to.

 

[ATLga]

Hello

I had been running 384.18 on my 86U fine with no issues. Nothing "exotic" with my needs, apart from using a VPN client. The config for that client is generated successfully by AIRVPN, the online company I use for my VPN needs.

Noted the potential issues with the JFFS partition due to its reduction in size.
Backed up the JFFS partition(12mb or so) but then, router gone through many firmware revisions and settings, formatted the partition on reboot and so rebooted.
All went well with the newly created JFFS partition mounted, about 1.3mb in size of 48mb available.
Then backed up that JFFS partition again, just in case.
Downloaded and flashed successfully with the 384.19 firmware.
Rebooted and noted that the JFFS partition was not mounted.
Selected to reformat that partition and reboot.
Rebooted and all seemed well. 1.34mb of 47mb used on the JFFS partition.
Connected fine to the Internet, no issues so far.

The problem......

Created usual config from AIRVPN and uploaded it as usual into Client 1 for the VPN.
Rather than the usual immediate connection this time it does not connect and remains "connecting"
Errors noted in the system log.
Reset the Client 1 to defaults. Applied and the settings from the config then went empty but the Client 1 still changed to "connecting" even tho it was set to "off".
That would not change.
Reboot router would not change.
Reboot router and format JFFS and then it was fine with no remaining "connecting" issues

This time I repeated the above but tried VPN Client 2.

Errors within System log......

Aug 28 09:07:25 ovpn-client2[4083]: OpenVPN 2.4.9 arm-buildroot-linux-gnueabi [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Aug 14 2020
Aug 28 09:07:25 ovpn-client2[4083]: library versions: OpenSSL 1.1.1g 21 Apr 2020, LZO 2.08
Aug 28 09:07:25 ovpn-client2[4084]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Aug 28 09:07:25 ovpn-client2[4084]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug 28 09:07:25 ovpn-client2[4084]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug 28 09:07:28 ovpn-client2[4084]: TCP/UDP: Preserving recently used remote address: [AF_INET]89.238.150.42:443
Aug 28 09:07:28 ovpn-client2[4084]: Socket Buffers: R=[524288->524288] S=[524288->524288]
Aug 28 09:07:28 ovpn-client2[4084]: UDP link local: (not bound)
Aug 28 09:07:28 ovpn-client2[4084]: UDP link remote: [AF_INET]89.238.150.42:443
Aug 28 09:07:28 ovpn-client2[4084]: TLS: Initial packet from [AF_INET]89.238.150.42:443, sid=2e338ce1 b70ce898
Aug 28 09:07:28 ovpn-client2[4084]: VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
Aug 28 09:07:28 ovpn-client2[4084]: VERIFY KU OK
Aug 28 09:07:28 ovpn-client2[4084]: Validating certificate extended key usage
Aug 28 09:07:28 ovpn-client2[4084]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Aug 28 09:07:28 ovpn-client2[4084]: VERIFY EKU OK
Aug 28 09:07:28 ovpn-client2[4084]: VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Arion, emailAddress=info@airvpn.org
Aug 28 09:07:28 ovpn-client2[4084]: Control Channel: TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
Aug 28 09:07:28 ovpn-client2[4084]: [Arion] Peer Connection Initiated with [AF_INET]89.238.150.42:443
Aug 28 09:07:29 ovpn-client2[4084]: SENT CONTROL [Arion]: 'PUSH_REQUEST' (status=1)
Aug 28 09:07:29 ovpn-client2[4084]: PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway ipv6 def1 bypass-dhcp,dhcp-option DNS 10.17.244.1,dhcp-option DNS6 fde6:7a:7d20:df4::1,tun-ipv6,route-gateway 10.17.244.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 fde6:7a:7d20:df4::10f7/64 fde6:7a:7d20:df4::1,ifconfig 10.17.244.249 255.255.255.0,peer-id 1,cipher AES-256-GCM'
Aug 28 09:07:29 ovpn-client2[4084]: OPTIONS IMPORT: timers and/or timeouts modified
Aug 28 09:07:29 ovpn-client2[4084]: OPTIONS IMPORT: compression parms modified
Aug 28 09:07:29 ovpn-client2[4084]: OPTIONS IMPORT: --ifconfig/up options modified
Aug 28 09:07:29 ovpn-client2[4084]: OPTIONS IMPORT: route options modified
Aug 28 09:07:29 ovpn-client2[4084]: OPTIONS IMPORT: route-related options modified
Aug 28 09:07:29 ovpn-client2[4084]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Aug 28 09:07:29 ovpn-client2[4084]: OPTIONS IMPORT: peer-id set
Aug 28 09:07:29 ovpn-client2[4084]: OPTIONS IMPORT: adjusting link_mtu to 1625
Aug 28 09:07:29 ovpn-client2[4084]: OPTIONS IMPORT: data channel crypto options modified
Aug 28 09:07:29 ovpn-client2[4084]: Data Channel: using negotiated cipher 'AES-256-GCM'
Aug 28 09:07:29 ovpn-client2[4084]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Aug 28 09:07:29 ovpn-client2[4084]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Aug 28 09:07:29 ovpn-client2[4084]: GDG6: remote_host_ipv6=n/a
Aug 28 09:07:29 ovpn-client2[4084]: TUN/TAP device tun12 opened
Aug 28 09:07:29 ovpn-client2[4084]: TUN/TAP TX queue length set to 1000
Aug 28 09:07:29 ovpn-client2[4084]: /sbin/ifconfig tun12 10.17.244.249 netmask 255.255.255.0 mtu 1500 broadcast 10.17.244.255
Aug 28 09:07:29 lldpd[1368]: removal request for address of 10.17.244.249%22, but no knowledge of it
Aug 28 09:07:29 lldpd[1368]: removal request for address of 10.17.244.249%22, but no knowledge of it
Aug 28 09:07:29 ovpn-client2[4084]: /sbin/ifconfig tun12 add fde6:7a:7d20:df4::10f7/64
Aug 28 09:07:29 ovpn-client2[4084]: Linux ifconfig inet6 failed: external program exited with error status: 1
Aug 28 09:07:29 ovpn-client2[4084]: Exiting due to fatal error

Now what happens is that the Client 2 VPN will remain trying to connect even if I try and revert the settings to the default. The only way that I have found to stop that is the reformat the JFFS partition and then everything "stops" and no client is trying to connect, which fails.

Screen shot 1 thumbnail shows the status of the VPN client

View attachment 25826


Screen Shot 2 thumbnail shows the Open VPN client settings and even though it is set to "off" it still tries to connect, but there are those errors noted in the system logs.


View attachment 25825



any advice please, keeping that advice "simple" if possible

EDIT: Tried to reset Client 2 VPN to the default settings. The logs show.....

Aug 28 09:36:04 rc_service: httpd 1267:notify_rc stop_vpnclient2;clearvpnclient2
Aug 28 09:36:04 openvpn: Resetting client (unit 2) to default settings
Aug 28 09:36:24 rc_service: httpd 1267:notify_rc restart_vpnclient2
Aug 28 09:36:24 ovpn-client2[14058]: Options error: You must define CA file (--ca) or CA path (--capath)
Aug 28 09:36:24 ovpn-client2[14058]: Use --help for more information.
Aug 28 09:36:24 openvpn: Starting OpenVPN client 2 failed!



but the client now shows......

status.....

View attachment 25827

settings...

View attachment 25828



even though it is set to "off" and should not be trying to connect

To return a "clear" status to the VPN client I reset the JFFS partition and rebooted. Partition mounted fine and no "connection" issues noted with the VPN clients. But they will no longer connect as they did previously without generating the noted error in the system log

Following along with your details, I see the flash of 384.19, then there is a format of JFFS and reboot, but I don’t see a JFFS restore after this point...

 

[Vimes]

Following along with your details, I see the flash of 384.19, then there is a format of JFFS and reboot, but I don’t see a JFFS restore after this point...

Please correct me if I am wrong here. Just putting aside, if we can, the re-partitioning by Asus of the JFFS partition from 48 to 47MB it was always possible to reformat that partition on the next reboot. As noted that is what I did. I ran fine without any errors at all keeping on the 384.18 firmware. So zero errors with a JFFS partition of around 1.3MB of the 48mb available.
No VPN client was being used at that time. Just a "std" router with no VPN settings.
Then I did as noted with the 384.19 firmware and again up and running fine once the JFFS partition was formatted, it didn't mount initially.
Only then did I start from fresh trying to implement a VPN client.
Are you suggesting that I need to restore the JFFS partition from the 48mb original save (12mb or so) or the fresh one after it was formatted, as I have both. Both are related to the 384.18 firmware.
As the JFFS partition retains settings etc I thought that all of these , if not trying to restore, would be recreated wither the VPN config file when installed, as shown on the first screens...?
I had thought of starting from scratch and doing a full reset of the router, need to find how that is done or if the pressing of the reset button on the rear is enough to wipe everything. That would be my last option tho.

Thanks

 

[ATLga]

Please correct me if I am wrong here. Just putting aside, if we can, the re-partitioning by Asus of the JFFS partition from 48 to 47MB it was always possible to reformat that partition on the next reboot. As noted that is what I did. I ran fine without any errors at all keeping on the 384.18 firmware. So zero errors with a JFFS partition of around 1.3MB of the 48mb available.
No VPN client was being used at that time. Just a "std" router with no VPN settings.

Then I did as noted with the 384.19 firmware and again up and running fine once the JFFS partition was formatted, it didn't mount initially.

Only then did I start from fresh trying to implement a VPN client.

Are you suggesting that I need to restore the JFFS partition from the 48mb original save (12mb or so) or the fresh one after it was formatted, as I have both. Both are related to the 384.18 firmware.

As the JFFS partition retains settings etc I thought that all of these , if not trying to restore, would be recreated wither the VPN config file when installed, as shown on the first screens...?

I had thought of starting from scratch and doing a full reset of the router, need to find how that is done or if the pressing of the reset button on the rear is enough to wipe everything. That would be my last option tho.

Thanks

From post #1 this thread
Backup before...restore after

“IMPORTANT: due to a flash partition layout change from Asus on the RT-AC86U, the JFFS partition content for that model may be missing or corrupted following the upgrade to 384.19. Make sure you make a backup of your JFFS partition before upgrading. If you run into issues, then reformat the JFFS partition (don`t forget to reboot), then restore your JFFS backup.”

 

[bbunge]

Please correct me if I am wrong here. Just putting aside, if we can, the re-partitioning by Asus of the JFFS partition from 48 to 47MB it was always possible to reformat that partition on the next reboot. As noted that is what I did. I ran fine without any errors at all keeping on the 384.18 firmware. So zero errors with a JFFS partition of around 1.3MB of the 48mb available.
No VPN client was being used at that time. Just a "std" router with no VPN settings.

Then I did as noted with the 384.19 firmware and again up and running fine once the JFFS partition was formatted, it didn't mount initially.

Only then did I start from fresh trying to implement a VPN client.

Are you suggesting that I need to restore the JFFS partition from the 48mb original save (12mb or so) or the fresh one after it was formatted, as I have both. Both are related to the 384.18 firmware.

As the JFFS partition retains settings etc I thought that all of these , if not trying to restore, would be recreated wither the VPN config file when installed, as shown on the first screens...?

I had thought of starting from scratch and doing a full reset of the router, need to find how that is done or if the pressing of the reset button on the rear is enough to wipe everything. That would be my last option tho.

Thanks

Yes, restore after format. Has been this way since release. Better yet do another manual configuration after factory reset.

 

[Vimes]

Ok found out what the problem was, even tho I did a full reset of the router. That was not needed and the restore of the JFFS partition was also not needed.......
This is now the connection to the AIRVPN VPN as it should......



the problem was twofold....

AIRVPN has now started including IPv 6 in their config file. Older config files did not include this. I could not see any warning regarding its implementation before downloading the config file.
The router by default has IPv 6 disabled.
so thankfully I saw a message posted about this very problem, within the AIR forums from another user using this firmware and the same issue. The solution was to enable IPv6 as a pass-through option within the router and now it works fine.
The VPN client can now turn on and show green, it couldn't do that before and the problem was with that the downloaded config file and the disabled IPv6 caused the issue.
In this case it had nothing to do with the JFFS partition.

Thanks for your replies, maybe what I note might help others if they also have a similar issue.

 

[L&LD]

@L&LD I read you said you did a bunch of routers without formatting the jffs. Have you had any issues since with any of the AMTM tooling? You did add in a post (but you cannot modify the original post below) that you must restore the jffs - that is not optional - but you did not have to add "check format the jffs", then "reboot" to the process...?

https://www.snbforums.com/threads/b...eta-is-now-available.65581/page-6#post-608612

Stay safe, stay alive. Peace.

@gattaca, that thread had been locked when I posted the additional info below.

Release - Asuswrt-Merlin 384.19 is now available

Did full wipe of JFFS, and complete factory settings prior to isntalling384.19b2 then dirty upgrade to 384.19 final. One error keeps coming back up Aug 15 08:28:06 kernel: bcm_i2c: bus 0: Failed to detect SFP: 100 retries exhausted Not an error, just Linux`s typical way of saying it tried to...

www.snbforums.com

I have no doubt that there will be some combination of options/features and scripts that don't seem to need the suggested steps below, but for 100% peace of mind, the minimal commitment to save the JFFS and then restore it after flashing 384.19_0 or later is worth it.

[Beta] Asuswrt-Merlin 384.19 beta is now available
Dirty flashed from 384.19_alpha4 to 384.19_beta1 and lost my internet connection. Dirty flashed back to 384.19_alpha4 and my internet connection was available again. Bit short on time now to look at the logs. Router model RT-AC86U. Hi, to correct my issue. First of all I noticed no code...

www.snbforums.com

Note that I cannot edit the original post stating "... restore the JFFS partition 'if necessary' with 'required'..."

Restore the JFFS you saved after flashing to 384.19_0 to prevent unneeded wild goose chases on ghost issues that don't really exist.