What's new

[Beta] Asuswrt-Merlin 384.13 Beta 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.
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 ;)
 
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:
Code:
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
Code:
#!/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
Code:
echo $@ >> /jffs/scripts/logger
to openvpn-event.sh

I got consistent results.

Code:
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.

Code:
#!/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.
 
Doesn't look like your screenshot :( Using latest beta and cloudflare-dns.com
upload_2019-7-26_15-54-37.png
 
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
 
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
 
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
 
Last edited:
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.
 
Installed it on both routers and dnsmasq / OpenSSL works as intended. Thank you!
 
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" :(

Screenshot 2019-07-26 at 10.58.26 PM.png


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

Screenshot 2019-07-26 at 11.23.24 PM.png
 
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.

Code:
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.
 
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.
 
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.
 
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
 
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