[Beta] Asuswrt-Merlin 384.13 Beta is now available

[Zastoff]

Hi, a question. I assume that if using only OpenVPN server I will not be affected by this, right ? ..just to evaluate if I can afford to test this beta...

Openvpn Server/Client working fine for me

 

[skeal]

Openvpn Server/Client working fine for me

+1

 

[Xentrk]

Okey, I have use mine scripts for years with no problem. Revert to Alpha2 start working again. All script is chmode 0755
I have this in log:

Error: an inet prefix is expected rather than "217.64.xx.xx via 158.174.xxx.x dev eth0".
Error: an inet prefix is expected rather than "158.174.xxx.x dev eth0  proto kernel  scope link".
Error: an inet prefix is expected rather than "192.168.12.0/24 dev br0  proto kernel  scope link  src 192.168.12.1".
Error: an inet prefix is expected rather than "10.8.40.0/24 dev tun22  proto kernel  scope link  src 10.8.40.1".
Error: an inet prefix is expected rather than "158.174.xxx.x/22 dev eth0  proto kernel  scope link  src 158.174.xxx.x".
Error: an inet prefix is expected rather than "10.128.0.0/16 dev tun11  proto kernel  scope link  src 10.128.xxx.xx".
Error: an inet prefix is expected rather than "10.129.0.0/16 dev tun13  proto kernel  scope link  src 10.129.xxx.xxx".
Error: an inet prefix is expected rather than "127.0.0.0/8 dev lo  scope link".
Error: an inet prefix is expected rather than "0.0.0.0/1 via 10.128.0.1 dev tun11".
Error: an inet prefix is expected rather than "128.0.0.0/1 via 10.128.0.1 dev tun11".
Error: an inet prefix is expected rather than "default via 158.174.xxx.x dev eth0".
RTNETLINK answers: No such process

#!/bin/sh

scr_name="$(basename $0)[$$]"
wan_gw=$(nvram get wan0_gateway)
wan_ip=$(nvram get wan0_ipaddr)
wan_if=$(nvram get wan0_ifname)

# Determine caller
case "$1" in
    "tun11")
        vpn_name="client1"
        ;;
    "tun12")
        vpn_name="client2"
        ;;
    "tun13")
        vpn_name="client3"
        ;;
    "tun14")
        vpn_name="client4"
        ;;
    "tun15")
        vpn_name="client5"
        ;;
    "tun21")
        vpn_name="server1"
        ;;
    "tun22")
        vpn_name="server2"
        ;;
    *)
        vpn_name=""
        ;;
esac

# Call appropriate script based on script_type
vpn_script_name="vpn$vpn_name-$script_type"
vpn_script_log="/tmp/vpn${vpn_name}_state"


# Check script state
#    vpn_script_state=$(cat $vpn_script_log)
    vpn_script_state=$(cat $vpn_script_log 2>/dev/null)

if [ "$vpn_script_name" = "$vpn_script_state" ]; then
#   echo "VPN script" $vpn_script_name "already run" | logger -t "$scr_name"
    echo "     ***VPN script" $vpn_script_name "already run" | logger -t "$scr_name"
    exit 0
fi

# Execute and log script state
if [[ -f "/jffs/scripts/$vpn_script_name" ]]; then
    echo "     Script executing.. for VPN event: "$vpn_script_name | logger -t $scr_name
    echo "$vpn_script_name" > $vpn_script_log
    /bin/sh /jffs/scripts/$vpn_script_name $*
else
#   echo "Script not defined for event: "$vpn_script_name | logger -t $scr_name
    echo "     Script not defined for VPN event: "$vpn_script_name | logger -t $scr_name
    exit 0
fi

exit 0

Using 384.12, I've been testing using the $PARAM with and without the quotes using the vpnrouting.sh script that was modified in Beta 1. The parameters are passed to openvpn-event with no issues. I reverted back to the 384.13 Beta version of vpnrouting.sh and no issues.

I added the line

echo $@ >> /jffs/scripts/logger

to openvpn-event.sh

I got consistent results.

tun13 1500 1584 10.31.0.10 10.31.0.9
tun11 1500 1584 10.24.0.18 10.24.0.17 init
tun11 1500 1584 10.24.0.18 10.24.0.17 init
tun11 1500 1584 10.24.0.14 10.24.0.13 init
tun11 1500 1584 10.24.0.14 10.24.0.13
tun15 1500 1585 10.35.0.6 10.35.0.5 init
tun15 1500 1585 10.35.0.6 10.35.0.5 init
tun15 1500 1585 10.35.0.14 10.35.0.13 init
tun15 1500 1585 10.35.0.14 10.35.0.13
###############################################
tun15 1500 1585 10.35.0.14 10.35.0.13 init
tun15 1500 1585 10.35.0.14 10.35.0.13 init
tun15 1500 1585 10.35.0.18 10.35.0.17 init
tun15 1500 1585 10.35.0.18 10.35.0.17
####################### firmware vpnrouting.sh
tun15 1500 1585 10.35.0.18 10.35.0.17 init
tun15 1500 1585 10.35.0.18 10.35.0.17 init
tun15 1500 1585 10.35.0.14 10.35.0.13 init
tun15 1500 1585 10.35.0.14 10.35.0.13
tun15 1500 1585 10.35.0.14 10.35.0.13 init
tun15 1500 1585 10.35.0.14 10.35.0.13 init
tun15 1500 1585 10.35.0.10 10.35.0.9 init
tun15 1500 1585 10.35.0.10 10.35.0.9

My openvpn-event script is very similar to yours with some small differences.

#!/bin/sh
###########################################################################################################
# Script: openvpn-event
# Author: Xentrk
# Last Updated Date: 3-June-2019
#
# Description:
#   Original Script by John9527:
#   https://www.snbforums.com/threads/fork-asuswrt-merlin-374-43-lts-releases-v39e3.18914/page-238#post-294825
#
#   Modified by Xentrk for x3mRouting project
############################################################################################################
# shellcheck disable=SC2154
PROJECT_REPO="/jffs/scripts/x3mRouting"

scr_name="$(basename "$0")[$$]"

case "$1" in
"tun11")
  vpn_name="client1"
  ;;
"tun12")
  vpn_name="client2"
  ;;
"tun13")
  vpn_name="client3"
  ;;
"tun14")
  vpn_name="client4"
  ;;
"tun15")
  vpn_name="client5"
  ;;
"tun21")
  vpn_name="server1"
  ;;
"tun22")
  vpn_name="server2"
  ;;
*)
  vpn_name=""
  ;;
esac

# Call appropriate script based on script_type
vpn_script_name=vpn"$vpn_name"-"$script_type"

# Check script state/use nvram to save last script run
vpn_script_state=$(nvram get vpn_script_state)
nvram set vpn_script_state="$vpn_script_name"
if [ "$vpn_script_name" = "$vpn_script_state" ]; then
  echo "VPN script" "$vpn_script_name" "already run" | logger -t "$scr_name"
  exit 0
fi

if [ -f "$PROJECT_REPO/$vpn_script_name" ]; then
  echo "Running $PROJECT_REPO/$vpn_script_name $*" | logger -t "$scr_name"
  sh $PROJECT_REPO/"$vpn_script_name" "$*"
else
  echo "Script not defined for event: ""$vpn_script_name" | logger -t "$scr_name"
  exit 0
fi

exit 0

I will flash to the Beta firmware tomorrow to see if I can spot where the issue is occurring.

 

[TheUntouchable]

Doesn't look like your screenshot Using latest beta and cloudflare-dns.com

 

[skeal]

Doesn't look like your screenshot Using latest beta and cloudflare-dns.com
View attachment 18735

There is nothing wrong with these results.

 

[TheUntouchable]

There is nothing wrong with these results.

Mh okay, I was confused because of the resulsts from merlin here:
https://www.snbforums.com/threads/e...-13-test-aimesh-dnssec-through-openssl.57489/

 

[scjr]

Updated to 384.13 beta1 and all is well. DoT/DNSSEC working fine. Thanks, Merlin!

 

[skeal]

Mh okay, I was confused because of the resulsts from merlin here:
https://www.snbforums.com/threads/e...-13-test-aimesh-dnssec-through-openssl.57489/

I get the exact same results as you.

 

[scjr]

Mh okay, I was confused because of the resulsts from merlin here:
https://www.snbforums.com/threads/e...-13-test-aimesh-dnssec-through-openssl.57489/

I believe that’s his results from his ISP. I get same results with Cloudflare as you and @skeal do.

 

[TheUntouchable]

Thanks for the feedback, guys, now I feel calmed down again

 

[New2This]

Thanks for this, everything seems to be running ok with my setup Primary 86U with node Rog 5300. Just one thing I have a USB hard drive hooked up to the 5300, how can my clients see that now? As it cannot be seen

Thanks

 

[jpdsc]

Great update, will install tonight!

@RMerlin does this means that you ported the AIMESH code from compatible devices into non-compatible devices such as the AC87U? Or did ASUS release a stock FW update which allows all routers to use AIMESH?

Thanks

 

[Zastoff]

Great update, will install tonight!

@RMerlin does this means that you ported the AIMESH code from compatible devices into non-compatible devices such as the AC87U? Or did ASUS release a stock FW update which allows all routers to use AIMESH?

Thanks

No AiMesh for AC3200 or AC87u more info read post2

 

[rgnldo]

Unfortunately, unbound does not work as intended in 384.13_beta1. The merlin libunbound and unbound-anchor solution would be great. Well, let's get to what we have. 384.13_beta1 is working 100%. Very good job.

 

[Mutzli]

Installed it on both routers and dnsmasq / OpenSSL works as intended. Thank you!

 

[LimJK]

Hi,
I have just upgraded to FW:384.13_beta1-g73181bd3ae for my AiMesh Router, AiMesh Nodes with Stock FW. Everything seems to be running for me, including:

• dhcp_staticlist, custom_clientlist, customised device icons (list of 43 devices)
  
• OpenVPN Server
• etc ...

I only found an issue where one of my AiMesh Nodes shows "Connection Priority" as "NonSupported"

My work around was to Remove (-) the offending AiMesh Node, then Search and Add AiMesh Node again. All is well after that:

 

[RMerlin]

Sincere apologies for the error. Not sure why I haven't experienced the issue. I'll do some more testing this weekend. I have been running the code for nearly a year and haven't had an issue with the quoted $PARAM line. I will revisit and look into more in-depth.

run_custom_script() {
  if [ -f /jffs/scripts/openvpn-event ]; then
    /usr/bin/logger -t "custom_script" "Running /jffs/scripts/openvpn-event (args: $PARAM)"
    /bin/sh /jffs/scripts/openvpn-event "$PARAM"
  fi
}

I prefer to leave the script as it was before, to be honest. I see no real point in trying to achieve POSIX compliance with a script developed exclusively for Asuswrt-merlin.

Installed on AX88U and set as Mesh Router. Using AC68U on stock firmware as node. When searching for updates I get "Unable to connect to the update server."

Make sure you don't use anything that might block access either to Asus's servers, or my own (which is behind Cloudflare, so VPN providers might potentially be blocked by them).

Hi, a question. I assume that if using only OpenVPN server I will not be affected by this, right ? ..just to evaluate if I can afford to test this beta...

Correct, the script is only used for VPN clients. It will also only affect people that have an openvpn-event script which parses the arguments received from vpnrouting.sh.

 

[RMerlin]

I will flash to the Beta firmware tomorrow to see if I can spot where the issue is occurring.

Look at the test script I wrote in my post, showing the difference between quoted and non-quoted argument passing. Quoting makes the target receive all separate argument as if it was only one single argument. $@ does not try to extract a specific argument, it takes the whole string as a whole, that's why your test doesn't show anything wrong.

 

[RMerlin]

Mh okay, I was confused because of the resulsts from merlin here:
https://www.snbforums.com/threads/e...-13-test-aimesh-dnssec-through-openssl.57489/

DNSSEC validation is done as a chain. If your upstream server lacks support for a specific crypto, it might pass a failing result to dnsmasq, which cannot "unfail" it.

Thanks for this, everything seems to be running ok with my setup Primary 86U with node Rog 5300. Just one thing I have a USB hard drive hooked up to the 5300, how can my clients see that now? As it cannot be seen

USB sharing can only be done from the primary router, since nodes cannot be separately accessed by the clients.

 

[New2This]

DNSSEC validation is done as a chain. If your upstream server lacks support for a specific crypto, it might pass a failing result to dnsmasq, which cannot "unfail" it.



USB sharing can only be done from the primary router, since nodes cannot be separately accessed by the clients.

Gotcha. Everything is working fine now, since putting it main router