1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
Dismiss Notice

Welcome To SNBForums

SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.

If you'd like to post a question, simply register and have at it!

While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!

[Beta] Asuswrt-Merlin 384.13 Beta is now available

Discussion in 'Asuswrt-Merlin' started by RMerlin, Jul 26, 2019.

Thread Status:
Not open for further replies.
  1. RMerlin

    RMerlin Super Moderator

    Joined:
    Apr 14, 2012
    Messages:
    33,288
    Location:
    Canada
    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.
     
  2. RMerlin

    RMerlin Super Moderator

    Joined:
    Apr 14, 2012
    Messages:
    33,288
    Location:
    Canada
    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.
     
    JDB, Olivier, netmik3 and 8 others like this.
  3. RMerlin

    RMerlin Super Moderator

    Joined:
    Apr 14, 2012
    Messages:
    33,288
    Location:
    Canada
    Known issues:
    • openvpn-event for clients will fail to parse arguments received from vpnrouting.sh (fixed in beta 2)
     
    Last edited: Jul 26, 2019
  4. octopus

    octopus Very Senior Member

    Joined:
    Jul 17, 2012
    Messages:
    1,406
    Last edited: Jul 26, 2019
  5. RMerlin

    RMerlin Super Moderator

    Joined:
    Apr 14, 2012
    Messages:
    33,288
    Location:
    Canada
    Server or Client? For clients it's working for me:

    Code:
    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.
     
    Last edited: Jul 26, 2019
    Vexira likes this.
  6. octopus

    octopus Very Senior Member

    Joined:
    Jul 17, 2012
    Messages:
    1,406
    Both vpnserver1-state and vpnclient1-state not been populate in /tmp
    use openvpn-event
     
  7. RMerlin

    RMerlin Super Moderator

    Joined:
    Apr 14, 2012
    Messages:
    33,288
    Location:
    Canada
    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.
     
  8. octopus

    octopus Very Senior Member

    Joined:
    Jul 17, 2012
    Messages:
    1,406
    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
    
     
  9. RMerlin

    RMerlin Super Moderator

    Joined:
    Apr 14, 2012
    Messages:
    33,288
    Location:
    Canada
    Odd, no error message here while using policy rules.

    Try replacing it with an older copy.

    Code:
    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.
     
    Vexira likes this.
  10. octopus

    octopus Very Senior Member

    Joined:
    Jul 17, 2012
    Messages:
    1,406
    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
     
  11. RMerlin

    RMerlin Super Moderator

    Joined:
    Apr 14, 2012
    Messages:
    33,288
    Location:
    Canada
    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.

    Code:
    #!/bin/sh
    PARMS=$*
    output()
    {
            echo $1
    }
    output $PARMS
    output "$PARMS"
    
    
    Code:
    [email protected]:/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.
     
    Vexira and octopus like this.
  12. octopus

    octopus Very Senior Member

    Joined:
    Jul 17, 2012
    Messages:
    1,406
    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.
     
  13. Jack Yaz

    Jack Yaz Part of the Furniture

    Joined:
    Apr 20, 2017
    Messages:
    3,852
    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.
     
  14. Zastoff

    Zastoff Senior Member

    Joined:
    Nov 21, 2017
    Messages:
    493
    Smooth update on 87u from 384.12 to 384.13_beta1
    Looking good here ;)
    Thanks
     
    scjr and QuikSilver like this.
  15. Xentrk

    Xentrk Part of the Furniture

    Joined:
    Jul 21, 2016
    Messages:
    2,921
    Location:
    The Land of Smiles
    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
    }
     
    Last edited: Jul 26, 2019
    L&LD likes this.
  16. skeal

    skeal Part of the Furniture

    Joined:
    Apr 30, 2016
    Messages:
    3,931
    Location:
    Riderville, SK
    AiMesh and DNSSEC working as expected on the AX88U! No changes to my static DHCP list, it's all intact. Nice work Eric!
     
    PoloNes, scjr and QuikSilver like this.
  17. Fuechslein

    Fuechslein New Around Here

    Joined:
    Jul 26, 2019
    Messages:
    2
    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."
     
  18. skeal

    skeal Part of the Furniture

    Joined:
    Apr 30, 2016
    Messages:
    3,931
    Location:
    Riderville, SK
    I have the exact same setup and I don't get that message.
     
  19. FTC

    FTC Senior Member

    Joined:
    Mar 2, 2016
    Messages:
    343
    Location:
    Barcelona
    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...
     
  20. skeal

    skeal Part of the Furniture

    Joined:
    Apr 30, 2016
    Messages:
    3,931
    Location:
    Riderville, SK
    I have a OVPN Server and I'm having no issues with it.
     
    L&LD and Zastoff like this.
Thread Status:
Not open for further replies.