[Beta] Asuswrt-Merlin 380.65 Beta is now available

[john9527]

I'm using MAC filtering and site survey works fine. I can see the available wireless networks of my neighbors.

Do you have is set for both bands? If not, are you sure you aren't only seeing the survey results for the band that doesn't have MAC filtering on?

 

[netware5]

Do you have is set for both bands? If not, are you sure you aren't only seeing the survey results for the band that doesn't have MAC filtering on?

Yes, I have set it on both bands. But I see only 2.4 band networks. Most probably I am the only owner of 5 GHz router nearby.

 

[netware5]

Might be model or SDK specific perhaps. All I know is that many times in the past, people had the wireless survey feature stop working whenever they enabled MAC filtering.

May be. I can confirm that I've always used MAC filtering since 2013 and always had been able to see other networks during networks scan.

 

[Razor237]

Quick Question should i do a full factory reset for this build since there seems to be a lot of changes

 

[whsbuss]

Can I run this on the BestBuy RT-AC1900P ?

 

[RMerlin]

Quick Question should i do a full factory reset for this build since there seems to be a lot of changes

What version are you upgrading for? In general, it shouldn't be required if coming from a recent build, unless you experience any weird issue.

 

[Razor237]

What version are you upgrading for? In general, it shouldn't be required if coming from a recent build, unless you experience any weird issue.

I'm coming from 380.64_2 so should be good ... Thanks

 

[Martineau]

I can't reproduce it here with vpnbook's free server. My guess is your client is taking longer to shut down than what the webui waits for before reloading the page, so the page gets reloaded before the client has exited. can you see if that's the case by tailing /tmp/syslog.txt whole the page is reloading?

Not sure what you can deduce from tailing /tmp/syslog.txt (/tmp/syslog.log) as-is?

NOTE: I have never previously used openvpn-event and only in this release have I attempted to wean myself from a customised vpnrouting.sh using @john9527's openvpn-event (recommended) template, but I have now disabled openvpn-event to eliminate any possible impact on the VPN shutdown.

Anyway, to aid diagnostics, issuing the following command prior to stopping the VPN Client via the GUI

while sleep 1; do logger "vpn_client2_state is `nvram get vpn_client2_state`"; done

results in this Syslog extract...

Spoiler: Syslog - VPN Client shutdown via GUI timings

Jan 21 13:15:25 RT-AC68U user.warn admin: vpn_client2_state is 2
Jan 21 13:15:26 RT-AC68U user.warn admin: vpn_client2_state is 2
Jan 21 13:15:26 RT-AC68U kern.notice rc_service: httpd 3169:notify_rc stop_vpnclient2
Jan 21 13:15:27 RT-AC68U user.warn admin: vpn_client2_state is 2
Jan 21 13:15:27 RT-AC68U daemon.err openvpn[21018]: event_wait : Interrupted system call (code=4)
Jan 21 13:15:27 RT-AC68U daemon.notice openvpn[21018]: vpnrouting.sh tun12 1500 1559 10.200.199.9 255.255.255.0 init
Jan 21 13:15:27 RT-AC68U user.warn (vpnrouting.sh): 21454 v380.65 Patched by Martineau vpnrouting.sh tun12 1500 1559 10.200.199.9 255.255.255.0 init
Jan 21 13:15:27 RT-AC68U user.warn openvpn-routing: Configuring policy rules for client 2
Jan 21 13:15:27 RT-AC68U user.warn openvpn-routing: Removing rule 10201 from routing policy
Jan 21 13:15:27 RT-AC68U user.warn openvpn-routing: Removing rule 10301 from routing policy
Jan 21 13:15:27 RT-AC68U user.warn openvpn-routing: Tunnel down - VPN client access blocked
Jan 21 13:15:28 RT-AC68U user.warn openvpn-routing: Adding route for 172.16.2.1 to 0.0.0.0 through VPN client 2
Jan 21 13:15:28 RT-AC68U user.warn openvpn-routing: Adding route for 172.31.2.254 to 0.0.0.0 through WAN
Jan 21 13:15:28 RT-AC68U user.warn openvpn-routing: Completed routing policy configuration for client 2
Jan 21 13:15:28 RT-AC68U daemon.notice openvpn[21018]: /usr/sbin/ip route del 113.29.228.130/32
Jan 21 13:15:28 RT-AC68U daemon.notice openvpn[21018]: /usr/sbin/ip route del 0.0.0.0/1
Jan 21 13:15:28 RT-AC68U daemon.warn openvpn[21018]: ERROR: Linux route delete command failed: external program exited with error status: 2
Jan 21 13:15:28 RT-AC68U daemon.notice openvpn[21018]: /usr/sbin/ip route del 128.0.0.0/1
Jan 21 13:15:28 RT-AC68U daemon.warn openvpn[21018]: ERROR: Linux route delete command failed: external program exited with error status: 2
Jan 21 13:15:28 RT-AC68U daemon.notice openvpn[21018]: Closing TUN/TAP interface
Jan 21 13:15:28 RT-AC68U daemon.notice openvpn[21018]: /usr/sbin/ip addr del dev tun12 10.200.199.9/24
Jan 21 13:15:28 RT-AC68U daemon.notice openvpn[21018]: updown.sh tun12 1500 1559 10.200.199.9 255.255.255.0 init
Jan 21 13:15:28 RT-AC68U user.warn admin: vpn_client2_state is 2
Jan 21 13:15:29 RT-AC68U kern.notice rc_service: service 21562:notify_rc updateresolv
Jan 21 13:15:29 RT-AC68U kern.notice rc_service: waitting "stop_vpnclient2" via httpd ...
Jan 21 13:15:29 RT-AC68U user.warn admin: vpn_client2_state is 2
Jan 21 13:15:30 RT-AC68U user.warn admin: vpn_client2_state is 2
Jan 21 13:15:31 RT-AC68U user.warn admin: vpn_client2_state is 2
Jan 21 13:15:32 RT-AC68U user.warn admin: vpn_client2_state is 2
Jan 21 13:15:33 RT-AC68U user.warn admin: vpn_client2_state is 2
Jan 21 13:15:34 RT-AC68U user.warn admin: vpn_client2_state is 2
Jan 21 13:15:35 RT-AC68U user.warn admin: vpn_client2_state is 2
Jan 21 13:15:36 RT-AC68U user.warn admin: vpn_client2_state is 2
Jan 21 13:15:37 RT-AC68U user.warn admin: vpn_client2_state is 2
Jan 21 13:15:38 RT-AC68U user.warn admin: vpn_client2_state is 2
Jan 21 13:15:40 RT-AC68U user.warn admin: vpn_client2_state is 0
Jan 21 13:15:41 RT-AC68U user.warn admin: vpn_client2_state is 0

Using my VPN_Client_Switch.sh script to stop the VPN.....

Spoiler: Syslog - VPN Client shutdown via script timings

Jan 21 13:19:52 RT-AC68U user.warn (VPN_Client_Switch.sh): 21952 Request..... [2 off]
Jan 21 13:19:53 RT-AC68U user.warn (VPN_Client_Switch.sh): 21952 Stopping VPN Client 2
Jan 21 13:19:53 RT-AC68U user.warn (VPN_Client_Switch.sh): 21952 Blocking WAN for VPN Client 2 to 113.29.228.130
Jan 21 13:19:53 RT-AC68U user.warn (vpnrouting.sh): 22013 v380.65 Patched by Martineau /usr/sbin/vpnrouting.sh wan_block tun12
Jan 21 13:19:53 RT-AC68U kern.notice rc_service: service 22023:notify_rc stop_vpnclient2
Jan 21 13:19:54 RT-AC68U user.warn (VPN_Client_Switch.sh): 21952 Waiting for VPN Client 2 (HongKong) to disconnect.....
Jan 21 13:19:54 RT-AC68U daemon.err openvpn[21719]: event_wait : Interrupted system call (code=4)
Jan 21 13:19:54 RT-AC68U daemon.notice openvpn[21719]: vpnrouting.sh tun12 1500 1559 10.200.196.16 255.255.255.0 init
Jan 21 13:19:54 RT-AC68U user.warn (vpnrouting.sh): 22044 v380.65 Patched by Martineau vpnrouting.sh tun12 1500 1559 10.200.196.16 255.255.255.0 init
Jan 21 13:19:54 RT-AC68U user.warn openvpn-routing: Configuring policy rules for client 2
Jan 21 13:19:54 RT-AC68U user.warn openvpn-routing: Removing rule 10201 from routing policy
Jan 21 13:19:54 RT-AC68U user.warn openvpn-routing: Removing rule 10301 from routing policy
Jan 21 13:19:54 RT-AC68U user.warn openvpn-routing: Tunnel down - VPN client access blocked
Jan 21 13:19:54 RT-AC68U user.warn openvpn-routing: Adding route for 172.16.2.1 to 0.0.0.0 through VPN client 2
Jan 21 13:19:55 RT-AC68U user.warn openvpn-routing: Adding route for 172.31.2.254 to 0.0.0.0 through WAN
Jan 21 13:19:55 RT-AC68U user.warn openvpn-routing: Completed routing policy configuration for client 2
Jan 21 13:19:55 RT-AC68U daemon.notice openvpn[21719]: /usr/sbin/ip route del 113.29.228.130/32
Jan 21 13:19:55 RT-AC68U daemon.notice openvpn[21719]: /usr/sbin/ip route del 0.0.0.0/1
Jan 21 13:19:55 RT-AC68U daemon.warn openvpn[21719]: ERROR: Linux route delete command failed: external program exited with error status: 2
Jan 21 13:19:55 RT-AC68U daemon.notice openvpn[21719]: /usr/sbin/ip route del 128.0.0.0/1
Jan 21 13:19:55 RT-AC68U daemon.warn openvpn[21719]: ERROR: Linux route delete command failed: external program exited with error status: 2
Jan 21 13:19:55 RT-AC68U daemon.notice openvpn[21719]: Closing TUN/TAP interface
Jan 21 13:19:55 RT-AC68U daemon.notice openvpn[21719]: /usr/sbin/ip addr del dev tun12 10.200.196.16/24
Jan 21 13:19:55 RT-AC68U daemon.notice openvpn[21719]: updown.sh tun12 1500 1559 10.200.196.16 255.255.255.0 init
Jan 21 13:19:55 RT-AC68U user.warn (VPN_Client_Switch.sh): 21952 Waiting for VPN Client 2 to disconnect..... 0
Jan 21 13:19:55 RT-AC68U kern.notice rc_service: service 22156:notify_rc updateresolv
Jan 21 13:19:55 RT-AC68U kern.notice rc_service: waitting "stop_vpnclient2" via  ...
Jan 21 13:19:56 RT-AC68U user.warn (VPN_Client_Switch.sh): 21952 Waiting for VPN Client 2 to disconnect..... 1
Jan 21 13:19:57 RT-AC68U user.warn (VPN_Client_Switch.sh): 21952 Waiting for VPN Client 2 to disconnect..... 2
Jan 21 13:19:58 RT-AC68U user.warn (VPN_Client_Switch.sh): 21952 Waiting for VPN Client 2 to disconnect..... 3
Jan 21 13:19:59 RT-AC68U user.warn (VPN_Client_Switch.sh): 21952 Waiting for VPN Client 2 to disconnect..... 4
Jan 21 13:20:00 RT-AC68U user.warn (VPN_Client_Switch.sh): 21952 Waiting for VPN Client 2 to disconnect..... 5
Jan 21 13:20:01 RT-AC68U user.warn (VPN_Client_Switch.sh): 21952 Waiting for VPN Client 2 to disconnect..... 6
Jan 21 13:20:02 RT-AC68U user.warn (VPN_Client_Switch.sh): 21952 Waiting for VPN Client 2 to disconnect..... 7
Jan 21 13:20:03 RT-AC68U user.warn (VPN_Client_Switch.sh): 21952 Waiting for VPN Client 2 to disconnect..... 8
Jan 21 13:20:04 RT-AC68U user.warn (VPN_Client_Switch.sh): 21952 Waiting for VPN Client 2 to disconnect..... 9
Jan 21 13:20:05 RT-AC68U user.warn (VPN_Client_Switch.sh): 21952 Waiting for VPN Client 2 to disconnect..... 10
Jan 21 13:20:07 RT-AC68U user.warn (VPN_Client_Switch.sh): 21952 Waiting for VPN Client 2 to disconnect..... 11
Jan 21 13:20:08 RT-AC68U user.warn (VPN_Client_Switch.sh): 21952 VPN Client 2 (HongKong) disconnect'd in 11 secs
Jan 21 13:20:08 RT-AC68U user.warn (VPN_Client_Switch.sh): 21952 VPN Client Status:
Jan 21 13:20:08 RT-AC68U user.warn (VPN_Client_Switch.sh): 21952 *NO VPN Clients connected*

 

[john9527]

Here's the key timings.....

Jan 21 13:19:53 RT-AC68U kern.notice rc_service: service 22023:notify_rc stop_vpnclient2
....
Jan 21 13:20:08 RT-AC68U user.warn (VPN_Client_Switch.sh): 21952 VPN Client 2 (HongKong) disconnect'd in 11 secs

15 sec to shutdown.....timeout in gui is (the gui refresh is just a countdown timer, then it reads status)

<input type="hidden" name="action_wait" value="10">

So, 5 secs too short.

Also, if you use explicit-exit-notify, that value there is added secs. Probably makes sense to set the timer to 20 sec.

PS - In my fork it's set to 15 sec if the you are changing the state of the client, or 5 sec if the client is not up and you are just changing a parameter.

 

[Martineau]

Here's the key timings.....

Jan 21 13:19:53 RT-AC68U kern.notice rc_service: service 22023:notify_rc stop_vpnclient2
....
Jan 21 13:20:08 RT-AC68U user.warn (VPN_Client_Switch.sh): 21952 VPN Client 2 (HongKong) disconnect'd in 11 secs

15 sec to shutdown.....timeout in gui is (the gui refresh is just a countdown timer, then it reads status)

<input type="hidden" name="action_wait" value="10">

So, 5 secs too short.

Also, if you use explicit-exit-notify, that value there is added secs. Probably makes sense to set the timer to 20 sec.

PS - In my fork it's set to 15 sec if the you are changing the state of the client, or 5 sec if the client is not up and you are just changing a parameter.

To be honest, as I have rarely used the GUI (preferring a custom script) to stop/start the VPN Client it may be visually pleasing if the 'action_wait' values were increased, but @RMerlin wanted feedback on OpenVPN 2.4, which seems to do a lot more processing (certainly @start-up) hence my report of this issue.

NOTE: For TCP TUN connections, OpenVPN 2.4 automatically rejects 'explicit-exit-notify' directives as 'inappropriate', but using the OpenVPN 2.4 'filter ignore' directive it is a useful feature to explicitly pre-empt possible issues resulting in the dubious use of 'explicit-exit-notify' when pushed by the VPN server.

Jan 21 13:07:51 RT-AC68U daemon.notice openvpn[20027]: Pushed option removed by filter: 'ifconfig-ipv6 2001:db8:123::2/64 2001:db8:123::1'
Jan 21 13:07:51 RT-AC68U daemon.notice openvpn[20027]: Pushed option removed by filter: 'route-ipv6 2000::/3 2001:db8:123::1'
Jan 21 13:07:51 RT-AC68U daemon.notice openvpn[20027]: Pushed option removed by filter: 'explicit-exit-notify 2'

 

[john9527]

explicit-exit-notify got a bad 'rap' due to some bugs in the openvpn client stop sequence in the firmware. These have been fixed in the 380.65 code and it should work now. On my fork, I've tested it successfully with both OpenVPN 2.3.14 and 2.14.0 (I haven't put out 2.4.0 on my fork yet, I'm still testing).

And yes, it doesn't make sense for TCP so is correctly ignored.

 

[RMerlin]

PS - In my fork it's set to 15 sec if the you are changing the state of the client, or 5 sec if the client is not up and you are just changing a parameter.

Not a bad idea. Until someone's configuration starts taking 17 seconds But 15 seconds on a state change isn't unreasonable.

 

[RMerlin]

OpenVPN 2.4 'filter ignore' directive it is a useful feature

Quite a new nice changes with 2.4.0 (not just NCP). That's one of the reasons why I wanted to get it implemented as soon as possible.

[marketing alert]That must make Asuswrt-Merlin one of the first router firmware to support OpenVPN 2.4 and its new features [/marketing alert]

 

[Martineau]

/usr/sbin/vpnrouting.sh is 'broken' in my environment

In init-start I have the following:

if [ -f /jffs/configs/rt_tables ]; then                             # Use custom table
    mount -o bind /jffs/configs/rt_tables /etc/iproute2/rt_tables   # Override 'ovpncX' with  say 'AirVPN', Comcast, NewYork etc.
fi

Clearly you have hard-coded 'ovpncX' references which wasn't what I expected when you implemented my request to allow customisation of /etc/iproute2/rt_tables.

Can you consider

1. /usr/sbin/vpnrouting.sh to be patched as follows:

VPN_TBL="ovpnc"$VPN_UNIT

change to

VPN_TBL=`grep "11"$VPN_UNIT /etc/iproute2/rt_tables | cut -d" " -f2`

Optional
2. Rather than hard-coding 'ovpncX' during the boot process that creates the 'prohited' RPDB/routing tables, simply use hard-coded 11x references.

 

[Naftali Oziel]

What version are you upgrading for? In general, it shouldn't be required if coming from a recent build, unless you experience any weird issue.

Did the wireless drives get updated as well?

 

[RMerlin]

Did the wireless drives get updated as well?

I don't know, it's impossible to tell if the driver was just recompiled or it was tweaked by Asus, and it's also always relative to your previous firmware.

 

[RMerlin]

Can you consider

There's no perfect solution there. If I hardcode the numbers, someone will complain that they can't change the numbers. If I hardcode the name (allowing numbers to be changed), then someone else will complain about being unable to change the names.

The primary reason why I created a table file is to allow numbers to be resolved into names when querying the tables, making the output far more readable. With that in mind, I went with the simplest design that fulfilled this very specific need. The current design also gives me more flexibility in the future if for some technical reason I was forced to change the table numbers (for instance if Asus started using the same tables as me): just updating the table file will be sufficient to resolve the issue. If I start hardcoding numbers in vpnrouting, then it's more changes that will be required. And anyone relying on the table numbers in their custom scripts would see those scripts break overnight. Using hardcoded labels ensure that they won't have to change anything to deal with any change made mandatory by Asus's own code.

Anyone having needs beyond these (like you) should fall back on adjusting either files according to their personal needs. Those are a very, very small number of users, and the technical drawback of trying to accommodate these would potentially create more problems for everyone else in the future.

 

[ankhazam]

Hello RMerlin,
I've been toying with my AC87U on your latest firmware and its IPV6. I'm using native dhcp-pd ipv6 over PPP. The problem is to make it work I need to log in via SSH and add:

ip -6 route add default dev ppp0 metric 256

For IPV6 to be reachable by my clients.

Is it possible to add it to some kind of post PPPOE init script by so that it is done by default? This route is missing without the command and WAN IPv6 Gateway in status is empty. After adding the route it changes to: "::" and I get native ipv6 support

EDIT: Well my Win10 manages to use ipv6 with above settings nicely but Android phones internet gets totally crappy...

Cheers,
Ank

 

[Martineau]

then someone else will complain about being unable to change the names.

I think you have misunderstood..

Without the proposed one line change to /usr/sbin/vpnrouting.sh you do not honour custom names when stopping/starting the VPN Clients, but changing it doesn't break the code for any of the users that choose not to customise their VPN Client descriptions.

 

[unsynaps]

Quite a new nice changes with 2.4.0 (not just NCP). That's one of the reasons why I wanted to get it implemented as soon as possible.

[marketing alert]That must make Asuswrt-Merlin one of the first router firmware to support OpenVPN 2.4 and its new features [/marketing alert]

I need to look into the new server side features of 2.4.

I already **LOVE** the new Windows 2.4 client. Does not require admin (UAC) rights anymore and now can read from config files in the users home folders. SO NICE.