[Beta] Asuswrt-Merlin 384.13 Beta is now available

[RMerlin]

Asuswrt-Merlin 384.13 Beta is now available for all supported models. While the list of changes isn't as long as recent releases, this one introduces some significant changes, primarily in supporting AiMesh (for compatible models).

The highlights:

• AiMesh support for both router and nodes. See the AiMesh section below for more information.
• Updated RT-AX88U to GPL 384_6210
• dnsmasq now uses OpenSSL instead of Nettle for DNSSEC cipher operations. This allows dnsmasq to validate a wider range of ciphers.
• Note for developers, the dhcp_staticlist format was changed to revert back to the same format as stock firmware (for AiMesh compatibility). The hostname field was moved to a separate variable, dhcp_hostnames. Note that this variable will be stored in a jffs file on the RT-AC86U and RT-AX88U due to limitations on variable length for their HND platform. That means that a backed up config file will not restore these hostnames when restored (but using a JFFS backup will).
• Some changes also had to be done to the webs_* variables that are used by the new firmware checks, which might affect script developers that were accessing those variables.
• A number of minor issues were fixed, see the Changelog for details

Things in need of testing:

• After updating for the first time to a 384.13 build, make sure your DHCP static leases and their defined hostnames are still properly shown on the webui, and that you are still able to add/edit them.
• Test AiMesh compatibility, mixing stock and non-stock firmware versions on your nodes
• Test downgrading/upgrading firmware releases on your nodes

Please only post in this thread about this specific beta release.

Downloads are here.
Changelog is here.

 

[RMerlin]

AiMesh support
This release adds full support for AiMesh (both as a primary router and as a node). Nodes can run either stock Asus or Asuswrt-Merlin (384.13 or newer), however the primary router must run Asuswrt-Merlin if you want any of your nodes to also use this firmware. This means you cannot use a GT-AX11000 master running stock Asus with an RT-AC86U node running Asuswrt-Merlin, for example. However you can use an RT-AC86U running Asuswrt-Merlin as your primary router, with a Lyra Trio node running stock Asus. You can also run a mixture of Asus/Merlin nodes at the same time, adding an RT-AC68U node running Asuswrt-Merlin to that same mesh. If running a mixture of stock and Merlin nodes, I recommend trying to run firmware releases that were released at approximately the same time, for having the best chance of avoiding compatibility issues. That means a 1 year old Asus firmware might not necessarily be fully compatible with the just-released 384.13, which is based on this summer's 384_45717 release from Asus.

Nodes running this firmware will have one limitation over running on the stock firmware, which is they will lack the ability to automatically download and install new firmware versions. New firmware availability notification will still work, and the changelog will also be visible through the webui, but you will have to use the node's Upload hyperlink to manually upload any new firmware. Nodes running on the stock firmware will retain their ability to do live updates by using the global Firmware Upgrade button.

While Merlin-based nodes seem to work fine so far (aside from the above limitation), there is generally little benefit in running it on a node, so it's generally recommended to leave your nodes on the stock Asus firmware.

Note that AiMesh can sometimes be less stable than using a plain router + access point or repeater configuration. AiMesh implementation being closed source, there is nothing that can be done about that on my end. This also means that there are zero chances of adding support to unsupported models such as the RT-AC87U or RT-AC3200, or enhancing/implementing additional features specific to AiMesh. Only Asus can technically do that, since any change has to be made within components for which I don't have access to the source code.

I recommend following discussions on best practices posted on these forums about AiMesh in general when attempting to improve your mesh stability/performance.


Configuration
The process is identical to that under the stock firmware. I recommend following the official documentation:

https://www.asus.com/ca-en/support/FAQ/1035087

This is already mentioned there, but just so people don't miss it: to configure a node, it must be reset to its factory default settings. Nothing special is required however for your primary router.

 

[RMerlin]

Known issues:

• openvpn-event for clients will fail to parse arguments received from vpnrouting.sh (fixed in beta 2)

 

[octopus]

Just loaded beta release.
Seems that open openvpn-event not executed. Downgrade to alpha2

Error: an inet prefix is expected rather than
RTNETLINK answers: No such process

Probably during this modification:
https://github.com/RMerl/asuswrt-merlin.ng/commit/a43d89a984f37bb927da3be22d33dc7fc70716a1
RMerlin, take this right, happend again.....

 

[RMerlin]

Just loaded beta release.
Seems that open openvpn-event not executed. Downgrade to alpha2

Error: an inet prefix is expected rather than

Probably during this modification:
https://github.com/RMerl/asuswrt-merlin.ng/commit/a43d89a984f37bb927da3be22d33dc7fc70716a1
RMerlin, take this right, happend again.....

Server or Client? For clients it's working for me:

Jul 26 01:18:34 custom_script: Running /jffs/scripts/openvpn-event (args: tun12 1500 1585 10.8.8.3 255.255.255.0 init)
Jul 26 01:18:36 openvpn-routing: Configuring policy rules for client 2
Jul 26 01:18:36 custom_script: Running /jffs/scripts/openvpn-event (args: tun12 1500 1585 10.8.8.3 )
Jul 26 01:18:36 ovpn-client2[9450]: Initialization Sequence Completed

Make sure your script is executable, and check your system log.

 

[octopus]

Server or Client?

Both vpnserver1-state and vpnclient1-state not been populate in /tmp
use openvpn-event

 

[RMerlin]

Both vpnserver1-state and vpnclient1-state not been populate in /tmp
use openvpn-event

Check that your script is executable, and check your system log for any error message. There hasn't been any change tied to this, and vpnrouting is only called for clients, so any change to it wouldn't affect servers.

 

[octopus]

Check that your script is executable, and check your system log for any error message. There hasn't been any change tied to this, and vpnrouting is only called for clients, so any change to it wouldn't affect servers.

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

 

[RMerlin]

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

Odd, no error message here while using policy rules.

Try replacing it with an older copy.

cd /jffs
wget https://raw.githubusercontent.com/RMerl/asuswrt-merlin.ng/30241e37d28340477f1d94eaf3194714078ef8f0/release/src/router/others/vpnrouting.sh
chmod a+rx vpnrouting.sh
mount -o bind /jffs/vpnrouting.sh /usr/sbin/vpnrouting.sh
service restart_vpnserver1
service restart_vpnclient1

EDIT: the error message comes from your script, not from vpnrouting. It seems to fail parsing the parameters passed by vpnrouting, maybe because quotes were added, so your script things it's just one single argument rather than multiple separate ones.

 

[octopus]

Odd, no error message here while using policy rules.

Try replacing it with an older copy.

cd /jffs
wget https://raw.githubusercontent.com/RMerl/asuswrt-merlin.ng/30241e37d28340477f1d94eaf3194714078ef8f0/release/src/router/others/vpnrouting.sh
chmod a+rx vpnrouting.sh
mount -o bind /jffs/vpnrouting.sh /usr/sbin/vpnrouting.sh
service restart_vpnserver1
service restart_vpnclient1

Okey, can test that later.
Reverted to Alpha2 and it start working. Then "old" vpnrouting is used. Must have to do with Posix change in vpnrouting.sh

 

[RMerlin]

Okey, can test that later.
Reverted to Alpha2 and it start working. Then "old" vpnrouting is used. Must have to do with Posix change in vpnrouting.sh

Yes. Quotes were added around $PARAMS when calling openvpn-event, which breaks argument passing. openvpn-event sees the whole $PARAMS content as one single argument, rather than an array of multiple, separate arguments.

#!/bin/sh
PARMS=$*
output()
{
        echo $1
}
output $PARMS
output "$PARMS"

admin@stargate88ax:/jffs# /tmp/1.sh aaaa bbbb cccc dddd
aaaa
aaaa bbbb cccc dddd

First is correct, second is wrong.

I'll revert the whole commit for now. You'd only care about POSIX compliance if portability was your goal - in the case of an embedded device firmware, this is not really relevant, and not worth the effort to debug IMHO.

 

[octopus]

Yes. @Xentrk added quotes around $PARAMS when calling openvpn-event, which breaks argument passing. openvpn-event sees the whole $PARAMS content as one single argument, rather than an array of multiple, separate arguments.

#!/bin/sh
PARMS=$*
output()
{
        echo $1
}
output $PARMS
output "$PARMS"

admin@stargate88ax:/jffs# /tmp/1.sh aaaa bbbb cccc dddd
aaaa
aaaa bbbb cccc dddd

First is correct, second is wrong.[/code]

Ok nice.
https://github.com/RMerl/asuswrt-merlin.ng/commit/46049d43b109b141af7bf8d00e8a50a8423ebea1

I have noticed people tendens to use shellchecker and that sometimes complain about quoting.

 

[Jack Yaz]

Ok nice.
https://github.com/RMerl/asuswrt-merlin.ng/commit/46049d43b109b141af7bf8d00e8a50a8423ebea1

I have noticed people tendens to use shellchecker and that sometimes complain about quoting.

It does, but sometimes what it flags is valid for the situation. It may not be technically posix compliant, but it works in the router environment. You can't blindly make every suggestion shellcheck makes, without testing the impact.

 

[Zastoff]

Smooth update on 87u from 384.12 to 384.13_beta1
Looking good here
Thanks

 

[Xentrk]

Yes. Quotes were added around $PARAMS when calling openvpn-event, which breaks argument passing. openvpn-event sees the whole $PARAMS content as one single argument, rather than an array of multiple, separate arguments.

I'll revert the whole commit for now. You'd only care about POSIX compliance if portability was your goal - in the case of an embedded device firmware, this is not really relevant, and not worth the effort to debug IMHO.

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
}

 

[skeal]

AiMesh and DNSSEC working as expected on the AX88U! No changes to my static DHCP list, it's all intact. Nice work Eric!

 

[Fuechslein]

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."

 

[skeal]

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."

I have the exact same setup and I don't get that message.

 

[FTC]

Known issues:

• openvpn-event for clients will fail to parse arguments received from vpnrouting.sh (fixed in beta 2)

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

 

[skeal]

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

I have a OVPN Server and I'm having no issues with it.