Beta Asuswrt-Merlin 3004.388.6 Beta is now available

[PR3MIUM]

For me its currently they have all a battle, the haxx0rs itself and the firms too, so no one is getting out currently ?

 

[MacG32]

My VPNs keep restarting every minute when in use. I even have the setting Firewall | General | Respond ICMP Echo (ping) Request from WAN set to YES. It stopped working in the last stable release and I thought updating to the BETA might fix it. It used to work just fine before that. I have Skynet 7.5.2 and YazFi 4.4.4 also installed. VPN1 goes to guest networks 1-3, 5 & 6. VPN2 goes to guest network 4. Skynet is using it's standard block list. My pfSense Plus logs show no pings being blocked or anything that has to do with the VPNs. I hope this report finds you well. Thank you!

Spoiler: CODE

Jan 15 15:54:27 ovpn-client1[5616]: [atlanta417] Inactivity timeout (--ping-restart), restarting
Jan 15 15:54:27 ovpn-client1[5616]: SIGUSR1[soft,ping-restart] received, process restarting
Jan 15 15:54:27 ovpn-client1[5616]: Restart pause, 1 second(s)
Jan 15 15:54:28 ovpn-client1[5616]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jan 15 15:54:28 ovpn-client1[5616]: TCP/UDP: Preserving recently used remote address: [AF_INET]181.214.167.202:1197
Jan 15 15:54:28 ovpn-client1[5616]: Socket Buffers: R=[524288->524288] S=[524288->524288]
Jan 15 15:54:28 ovpn-client1[5616]: UDPv4 link local: (not bound)
Jan 15 15:54:28 ovpn-client1[5616]: UDPv4 link remote: [AF_INET]181.214.167.202:1197
Jan 15 15:54:28 ovpn-client1[5616]: TLS: Initial packet from [AF_INET]181.214.167.202:1197, sid=ac8a64bb 15e7cec5
Jan 15 15:54:28 ovpn-client1[5616]: VERIFY OK: depth=1, C=US, ST=CA, L=LosAngeles, O=Private Internet Access, OU=Private Internet Access, CN=Private Internet Access, name=Private Internet Access, emailAddress=secure@privateinternetaccess.com
Jan 15 15:54:28 ovpn-client1[5616]: VERIFY KU OK
Jan 15 15:54:28 ovpn-client1[5616]: Validating certificate extended key usage
Jan 15 15:54:28 ovpn-client1[5616]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Jan 15 15:54:28 ovpn-client1[5616]: VERIFY EKU OK
Jan 15 15:54:28 ovpn-client1[5616]: VERIFY OK: depth=0, C=US, ST=CA, L=LosAngeles, O=Private Internet Access, OU=Private Internet Access, CN=atlanta417, name=atlanta417
Jan 15 15:54:28 ovpn-client1[5616]: Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 4096 bits RSA, signature: RSA-SHA512, peer temporary key: 253 bits X25519
Jan 15 15:54:28 ovpn-client1[5616]: [atlanta417] Peer Connection Initiated with [AF_INET]181.214.167.202:1197
Jan 15 15:54:28 ovpn-client1[5616]: TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
Jan 15 15:54:28 ovpn-client1[5616]: TLS: tls_multi_process: initial untrusted session promoted to trusted
Jan 15 15:54:28 ovpn-client1[5616]: PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway def1,route-ipv6 2000::/3,dhcp-option DNS 10.0.0.243,route-gateway 10.7.110.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.7.110.7 255.255.255.0,peer-id 2,cipher AES-256-GCM'
Jan 15 15:54:28 ovpn-client1[5616]: OPTIONS IMPORT: --ifconfig/up options modified
Jan 15 15:54:28 ovpn-client1[5616]: OPTIONS IMPORT: route options modified
Jan 15 15:54:28 ovpn-client1[5616]: OPTIONS IMPORT: route-related options modified
Jan 15 15:54:28 ovpn-client1[5616]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Jan 15 15:54:28 ovpn-client1[5616]: Preserving previous TUN/TAP instance: tun11
Jan 15 15:54:28 ovpn-client1[5616]: Initialization Sequence Completed
Jan 15 15:54:28 ovpn-client1[5616]: Data Channel: cipher 'AES-256-GCM', peer-id: 2, compression: 'stub'
Jan 15 15:54:28 ovpn-client1[5616]: Timers: ping 10, ping-restart 60
Jan 15 15:55:23 ovpn-client2[2998]: [atlanta417] Inactivity timeout (--ping-restart), restarting
Jan 15 15:55:23 ovpn-client2[2998]: SIGUSR1[soft,ping-restart] received, process restarting
Jan 15 15:55:23 ovpn-client2[2998]: Restart pause, 1 second(s)
Jan 15 15:55:24 ovpn-client2[2998]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jan 15 15:55:24 ovpn-client2[2998]: TCP/UDP: Preserving recently used remote address: [AF_INET]181.214.167.202:1197
Jan 15 15:55:24 ovpn-client2[2998]: Socket Buffers: R=[524288->524288] S=[524288->524288]
Jan 15 15:55:24 ovpn-client2[2998]: UDPv4 link local: (not bound)
Jan 15 15:55:24 ovpn-client2[2998]: UDPv4 link remote: [AF_INET]181.214.167.202:1197
Jan 15 15:55:24 ovpn-client2[2998]: TLS: Initial packet from [AF_INET]181.214.167.202:1197, sid=4cfdaa78 2ac13467
Jan 15 15:55:25 ovpn-client2[2998]: VERIFY OK: depth=1, C=US, ST=CA, L=LosAngeles, O=Private Internet Access, OU=Private Internet Access, CN=Private Internet Access, name=Private Internet Access, emailAddress=secure@privateinternetaccess.com
Jan 15 15:55:25 ovpn-client2[2998]: VERIFY KU OK
Jan 15 15:55:25 ovpn-client2[2998]: Validating certificate extended key usage
Jan 15 15:55:25 ovpn-client2[2998]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Jan 15 15:55:25 ovpn-client2[2998]: VERIFY EKU OK
Jan 15 15:55:25 ovpn-client2[2998]: VERIFY OK: depth=0, C=US, ST=CA, L=LosAngeles, O=Private Internet Access, OU=Private Internet Access, CN=atlanta417, name=atlanta417
Jan 15 15:55:25 ovpn-client2[2998]: Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 4096 bits RSA, signature: RSA-SHA512, peer temporary key: 253 bits X25519
Jan 15 15:55:25 ovpn-client2[2998]: [atlanta417] Peer Connection Initiated with [AF_INET]181.214.167.202:1197
Jan 15 15:55:25 ovpn-client2[2998]: TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
Jan 15 15:55:25 ovpn-client2[2998]: TLS: tls_multi_process: initial untrusted session promoted to trusted
Jan 15 15:55:25 ovpn-client2[2998]: PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway def1,route-ipv6 2000::/3,dhcp-option DNS 10.0.0.243,route-gateway 10.7.110.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.7.110.7 255.255.255.0,peer-id 3,cipher AES-256-GCM'
Jan 15 15:55:25 ovpn-client2[2998]: OPTIONS IMPORT: --ifconfig/up options modified
Jan 15 15:55:25 ovpn-client2[2998]: OPTIONS IMPORT: route options modified
Jan 15 15:55:25 ovpn-client2[2998]: OPTIONS IMPORT: route-related options modified
Jan 15 15:55:25 ovpn-client2[2998]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Jan 15 15:55:25 ovpn-client2[2998]: Preserving previous TUN/TAP instance: tun12
Jan 15 15:55:25 ovpn-client2[2998]: Initialization Sequence Completed
Jan 15 15:55:25 ovpn-client2[2998]: Data Channel: cipher 'AES-256-GCM', peer-id: 3, compression: 'stub'
Jan 15 15:55:25 ovpn-client2[2998]: Timers: ping 10, ping-restart 60

 

[Alaska99]

How is your parental control configured?

Kids have profile on android asus app with devices assigned, time schedule and filters on for adult content.

 

[RMerlin]

Kids have profile on android asus app with devices assigned, time schedule and filters on for adult content.

Configure it through the webui. The mobile app is not supported.

 

[Martinski]

My VPNs keep restarting every minute when in use. ...

Jan 15 15:54:27 ovpn-client1[5616]: [atlanta417] Inactivity timeout (--ping-restart), restarting
Jan 15 15:54:27 ovpn-client1[5616]: SIGUSR1[soft,ping-restart] received, process restarting
Jan 15 15:54:27 ovpn-client1[5616]: Restart pause, 1 second(s)
...
Jan 15 15:55:23 ovpn-client2[2998]: [atlanta417] Inactivity timeout (--ping-restart), restarting
Jan 15 15:55:23 ovpn-client2[2998]: SIGUSR1[soft,ping-restart] received, process restarting
Jan 15 15:55:23 ovpn-client2[2998]: Restart pause, 1 second(s)

The OpenVPN clients are restarting every 60 seconds due to the "inactivity timeout" triggered by the 60-sec "ping-restart" directive which is pushed to the clients. This "inactivity timeout" sends the SIGUSR1 signal which is what causes the encrypted tunnels to be closed and restarted every minute.

To avoid the above behavior, the "persist-tun" & "persist-key" directives are normally set on the server side and then pushed to the clients as well; however, based on the log you provided, I don't see those directives being pushed at all to your VPN clients, so I'd recommend double-checking to see if they exist in your client configuration files like so:

persist-tun
persist-key

If not found, I suggest adding those lines to each client configuration.

Also, it appears that you have both OpenVPN clients being assigned the same IP address while trying to start up, one after the other, based on these log entries:

Jan 15 15:54:28 ovpn-client1[5616]: PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway def1,route-ipv6 2000::/3,dhcp-option DNS 10.0.0.243,route-gateway 10.7.110.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.7.110.7 255.255.255.0,peer-id 2,cipher AES-256-GCM'
...
...
Jan 15 15:55:25 ovpn-client2[2998]: PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway def1,route-ipv6 2000::/3,dhcp-option DNS 10.0.0.243,route-gateway 10.7.110.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.7.110.7 255.255.255.0,peer-id 3,cipher AES-256-GCM'

This should not happen. Did you import the same configuration file when you set up the two OpenVPN clients on the router?

If yes, that's not correct because then you can end up in a situation where two separate OpenVPN client instances are started using exactly the same certificate/key pair. In such a scenario, the OpenVPN server authenticates & creates a connection with the 1st client; but a short time later, the 2nd client tries to connect so the server may just "replace" the current connection with the 1st client (thinking they're the same, just reconnecting & reestablishing the encrypted tunnel), leaving the 1st client instance "hanging" which means that it doesn't get any "keepalive" pings anymore & without any tunnel traffic.

This eventually leads to the 1st client reaching the "inactivity timeout" triggered by the "ping-restart" directive. Now, the 1st client instance tries to reconnect, kicking off the 2nd client connection, and the loop repeats with the 2nd client instance eventually reaching the "inactivity timeout" after 60 seconds because it has no "keepalives" & no tunnel traffic.

The bottom line is I recommend you double-check & make sure that each OpenVPN client has its own, unique cert & key pair in its corresponding configuration file.

 

[MacG32]

The OpenVPN clients are restarting every 60 seconds due to the "inactivity timeout" triggered by the 60-sec "ping-restart" directive which is pushed to the clients. This "inactivity timeout" sends the SIGUSR1 signal which is what causes the encrypted tunnels to be closed and restarted every minute.

To avoid the above behavior, the "persist-tun" & "persist-key" directives are normally set on the server side and then pushed to the clients as well; however, based on the log you provided, I don't see those directives being pushed at all to your VPN clients, so I'd recommend double-checking to see if they exist in your client configuration files like so:

persist-tun
persist-key

If not found, I suggest adding those lines to each client configuration.

Also, it appears that you have both OpenVPN clients being assigned the same IP address while trying to start up, one after the other, based on these log entries:

Jan 15 15:54:28 ovpn-client1[5616]: PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway def1,route-ipv6 2000::/3,dhcp-option DNS 10.0.0.243,route-gateway 10.7.110.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.7.110.7 255.255.255.0,peer-id 2,cipher AES-256-GCM'
...
...
Jan 15 15:55:25 ovpn-client2[2998]: PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway def1,route-ipv6 2000::/3,dhcp-option DNS 10.0.0.243,route-gateway 10.7.110.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.7.110.7 255.255.255.0,peer-id 3,cipher AES-256-GCM'

This should not happen. Did you import the same configuration file when you set up the two OpenVPN clients on the router?

If yes, that's not correct because then you can end up in a situation where two separate OpenVPN client instances are started using exactly the same certificate/key pair. In such a scenario, the OpenVPN server authenticates & creates a connection with the 1st client; but a short time later, the 2nd client tries to connect so the server may just "replace" the current connection with the 1st client (thinking they're the same, just reconnecting & reestablishing the encrypted tunnel), leaving the 1st client instance "hanging" which means that it doesn't get any "keepalive" pings anymore & without any tunnel traffic.

This eventually leads to the 1st client reaching the "inactivity timeout" triggered by the "ping-restart" directive. Now, the 1st client instance tries to reconnect, kicking off the 2nd client connection, and the loop repeats with the 2nd client instance eventually reaching the "inactivity timeout" after 60 seconds because it has no "keepalives" & no tunnel traffic.

The bottom line is I recommend you double-check & make sure that each OpenVPN client has its own, unique cert & key pair in its corresponding configuration file.

Thank you so very much @Martinski ! Adding persist-tun & key to the custom configurations fixed the consistent reconnects. I'm so very glad that you saw that they were missing and needed. I'm really glad it's not a firmware issue as well. Everything in the BETA is functioning properly and without a hitch. Thank you too @RMerlin !

 

[rwheaton1]

OK..this is bad...I just installed the beta and under system logs...items that should be showing under skynet (ie items that are being blocked) are showing under system messages log.

 

[dave14305]

OK..this is bad...I just installed the beta and under system logs...items that should be showing under skynet (ie items that are being blocked) are showing under system messages log.

That sounds like a Scribe/uiScribe problem rather than a firmware problem.

 

[Stpa67]

Works for me. Are you sure UPNP is enabled and you do have actual UPNP port forwards in place?

iptables -t nat -L VUPNP -vn

should confirm whether you truly have forwarded ports.

This is the output i get:

But the RT-AX58U Log shows nothing:

 

[dave14305]

This is the output i get:

View attachment 55621

But the RT-AX58U Log shows nothing:

View attachment 55622

Look for the /tmp/upnp.leases file on the router. That is where the UPNP entries will come from.

 

[SANdood]

Dirty upgrade on GT-AX11000 from 3004.388.5 (release) to 3004.388.6 beta - BOTH of my AIMesh nodes did not/would not re-connect (one RT-AX58U running 3.0.0.4.388_23925-g269b2a6 and one RP-AX58 running 3.0.0.4.388_23437-gad1cd46). After a few minutes, the two disappeared from the AI Mesh page (they showed 'disconnected' before they disappeared).

Tried rebooting the GT-AX11000, same result.

Dirty downgrade back to 3004.388.5, and all's well again.

I'm happy to try again, if anyone has any suggestions on how to fix or avoid the problem...

 

[Stpa67]

Look for the /tmp/upnp.leases file on the router. That is where the UPNP entries will come from.

I looked in the upnp.leases file and got:

control@RT-AX58U-2C40:/tmp# cat upnp.leases
TCP:43775:192.168.50.7:43775:0:
UDP:43775:192.168.50.7:43775:0:

But still nothing in "System Log => Port Forwarding"

 

[dave14305]

I looked in the upnp.leases file and got:

control@RT-AX58U-2C40:/tmp# cat upnp.leases
TCP:43775:192.168.50.7:43775:0:
UDP:43775:192.168.50.7:43775:0:

View attachment 55640

But still nothing in "System Log => Port Forwarding"

In your browser, if you right click and View Page Source on the page, what does the line look like where it says var upnparray = …

 

[Stpa67]

In your browser, if you right click and View Page Source on the page, what does the line look like where it says var upnparray = …

It says:

var upnparray = [[]];

I tried port forwarding and that shows up, but no upnp forward.

var vserverarray = [["ALL", "0.0.0.0", "TCP", "20", "192.168.50.7", "21", "VSERVER"],
["ALL", "0.0.0.0", "TCP", "21", "192.168.50.7", "21", "VSERVER"],
[]];

var upnparray = [[]];

 

[dave14305]

It says:

var upnparray = [[]];

I tried port forwarding and that shows up, but no upnp forward.

var vserverarray = [["ALL", "0.0.0.0", "TCP", "20", "192.168.50.7", "21", "VSERVER"],
["ALL", "0.0.0.0", "TCP", "21", "192.168.50.7", "21", "VSERVER"],
[]];

var upnparray = [[]];

I think it’s expecting some description in the leases file after the last colon. Never used upnp before so I’m no expert.

Edit: by adding a test description to the file, the lines appear.

 

[ColinTaylor]

I think it’s expecting some description in the leases file after the last colon. Never used upnp before so I’m no expert.

388.5:

# cat /tmp/upnp.leases
UDP:9308:192.168.1.156:9308:0:192.168.1.156:9308 to 9308 (UDP)
UDP:8571:192.168.1.156:8571:0:192.168.1.156:8571 to 8571 (UDP)

 

[rwheaton1]

That sounds like a Scribe/uiScribe problem rather than a firmware problem.

Well, I uninstalled skynet and scribe(s)...reinstalled and then all the logs disappeared and the main "original" log showed only....so, I did a complete factory reset...had the DDNS problem...reconnect my node...started reinstalling all the scripts and it was going pretty well until I installed SCMerlin (which I did last) and then I lost my node and skynet hangs and I have to restart entware application, from the SCMerlin UI, for skynet to start working again...LOL..so here I am now thinking on what I'm going to do next. I'm going to downgrade back to Merlin released version and hopefully just upload my backups and cross my fingers. Otherwise, I will have to completely rebuild my setup again. I guess that is better than having surgery tomorrow, which that is a whole other story, because the hospital is stuck on stupid. Anyhoo, if anyone needs anything from my router to help diagnose these problems...let me know including how to pull whatever you need.

Updated 1/17/2024:
Well, sometime last night my node reconnected LOL. I did an reboot this morning and it's still connected...I guess the gremlins worked themselves out? LOL

 

[MDM]

Works as one expect.
No issues - Boring!

 

[RMerlin]

I think it’s expecting some description in the leases file after the last colon.

That would make sense. sscanf() does not consider an empty string as a valid parameter, so the scan process will need to take that into account.

That issue would have been there forever, since that code was last changed in 2017. I guess most clients use NAT-PMP these days, and so will provide a description.

 

[RMerlin]

Configure it through the webui. The mobile app is not supported.

I can confirm that it's working fine for me with a test laptop configured through the webui. Laptop lost connectivity, and regained it at the properly scheduled times.