[Alpha] Preview builds for Asuswrt-Merlin 380.60

[RMerlin]

Another issue I came across is with the openvpn client. If you route any device through the VPN using policy rules, those routing entries stick and your device is stuck with no internet access. Even if you set the redirect Internet policy to no or set the service state to no for the tunnel.

What do you mean by "they stick"? After your turn off the tunnel? I just tested it, and it's working properly for me.

 

[z3r0k3wl]

What do you mean by "they stick"? After your turn off the tunnel? I just tested it, and it's working properly for me.

Sorry I may not have been clear. The behavior I get with any device I direct through the openvpn client is when I change the service state of that tunnel to off, those clients can no longer access the internet. I have to reboot the router to clear the problem. I hope that clarifies it.

Sent from my Nexus 7 using Tapatalk

 

[RMerlin]

Sorry I may not have been clear. The behavior I get with any device I direct through the openvpn client is when I change the service state of that tunnel to off, those clients can no longer access the internet. I have to reboot the router to clear the problem. I hope that clarifies it.

Sent from my Nexus 7 using Tapatalk

If you disable "Block routed clients if tunnel goes down" you will regain Internet access.

 

[z3r0k3wl]

If you disable "Block routed clients if tunnel goes down" you will regain Internet access.

That feature is not enabled.

Sent from my Nexus 7 using Tapatalk

 

[RMerlin]

That feature is not enabled.

Sent from my Nexus 7 using Tapatalk

It's the only way I can reproduce your issue here - when that feature is enabled. Otherwise, my tunnel goes down properly, and my VM maintains Internet access.

 

[RMerlin]

I found that for serving as masterbrowser a USB Device attached to the router is required.

Fixed.

 

[RMerlin]

That feature is not enabled.

Post the content of your syslog while starting, and also while stopping the tunnel. Also make sure you don't have the option to block traffic in one of the four other OpenVPN clients.

 

[Shonk]

Anyone getting loads of consolidating space?
device has been up for 22 hours and the last 6 hours its been consolidating the nvram space all the time it seems to be trying to keep well below 64k (even though its a 128k device)

NVRAM usage 59451 / 131072 bytes
JFFS 2.31 / 64.00 MB

Jun 17 17:00:24 kernel: nvram: consolidating space!
Jun 17 17:49:47 kernel: nvram: consolidating space!
Jun 17 18:39:36 kernel: nvram: consolidating space!
Jun 17 19:29:24 kernel: nvram: consolidating space!
Jun 17 20:19:12 kernel: nvram: consolidating space!
Jun 17 21:09:01 kernel: nvram: consolidating space!
Jun 17 21:58:49 kernel: nvram: consolidating space!
Jun 17 23:00:58 disk_monitor: Got SIGALRM...

 

[z3r0k3wl]

Post the content of your syslog while starting, and also while stopping the tunnel. Also make sure you don't have the option to block traffic in one of the four other OpenVPN clients.

Jun 17 19:55:18 rc_service: httpds 1614:notify_rc stop_vpnclient1
Jun 17 19:55:19 openvpn[1884]: event_wait : Interrupted system call (code=4)
Jun 17 19:55:19 openvpn[1884]: SIGTERM received, sending exit notification to peer
Jun 17 19:55:21 dnsmasq[1874]: exiting on receipt of SIGTERM
Jun 17 19:55:21 dnsmasq[2841]: started, version 2.76 cachesize 1500
Jun 17 19:55:21 dnsmasq[2841]: asynchronous logging enabled, queue limit is 5 messages
Jun 17 19:55:21 dnsmasq-dhcp[2841]: DHCP, IP range 192.168.1.2 -- 192.168.1.254, lease time 1d
Jun 17 19:55:21 dnsmasq[2841]: using local addresses only for domain THEGIBSON
Jun 17 19:55:21 dnsmasq[2841]: read /etc/hosts - 5 addresses
Jun 17 19:55:21 dnsmasq[2841]: using nameserver 64.71.255.198#53 for domain phub.net.cable.rogers.com
Jun 17 19:55:21 dnsmasq[2841]: using nameserver 64.71.255.204#53 for domain phub.net.cable.rogers.com
Jun 17 19:55:21 dnsmasq[2841]: using local addresses only for domain THEGIBSON
Jun 17 19:55:21 dnsmasq[2841]: using nameserver 64.71.255.204#53
Jun 17 19:55:21 dnsmasq[2841]: using nameserver 64.71.255.198#53
Jun 17 19:55:57 rc_service: httpds 1614:notify_rc start_vpnclient1
Jun 17 19:55:58 kernel: tun: Universal TUN/TAP device driver, 1.6
Jun 17 19:55:58 kernel: tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
Jun 17 19:55:59 openvpn[2851]: OpenVPN 2.3.11 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Jun 11 2016
Jun 17 19:55:59 openvpn[2851]: library versions: OpenSSL 1.0.2h 3 May 2016, LZO 2.08
Jun 17 19:55:59 openvpn[2852]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jun 17 19:55:59 openvpn[2852]: Control Channel Authentication: using 'static.key' as a OpenVPN static key file
Jun 17 19:55:59 openvpn[2852]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Jun 17 19:55:59 openvpn[2852]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Jun 17 19:55:59 openvpn[2852]: Socket Buffers: R=[122880->122880] S=[122880->122880]
Jun 17 19:55:59 openvpn[2852]: UDPv4 link local: [undef]
Jun 17 19:55:59 openvpn[2852]: UDPv4 link remote: [AF_INET]184.75.221.42:443
Jun 17 19:55:59 openvpn[2852]: TLS: Initial packet from [AF_INET]184.75.221.42:443, sid=3b90952f 4b6ba89c
Jun 17 19:56:00 openvpn[2852]: VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
Jun 17 19:56:00 openvpn[2852]: Validating certificate key usage
Jun 17 19:56:00 openvpn[2852]: ++ Certificate has key usage 00a0, expects 00a0
Jun 17 19:56:00 openvpn[2852]: VERIFY KU OK
Jun 17 19:56:00 openvpn[2852]: Validating certificate extended key usage
Jun 17 19:56:00 openvpn[2852]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Jun 17 19:56:00 openvpn[2852]: VERIFY EKU OK
Jun 17 19:56:00 openvpn[2852]: VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=server, emailAddress=info@airvpn.org
Jun 17 19:56:03 openvpn[2852]: Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Jun 17 19:56:03 openvpn[2852]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jun 17 19:56:03 openvpn[2852]: Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Jun 17 19:56:03 openvpn[2852]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jun 17 19:56:03 openvpn[2852]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
Jun 17 19:56:03 openvpn[2852]: [server] Peer Connection Initiated with [AF_INET]184.75.221.42:443
Jun 17 19:56:05 openvpn[2852]: SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Jun 17 19:56:05 openvpn[2852]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 10.4.0.1,comp-lzo no,route-gateway 10.4.0.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.4.18.223 255.255.0.0'
Jun 17 19:56:05 openvpn[2852]: OPTIONS IMPORT: timers and/or timeouts modified
Jun 17 19:56:05 openvpn[2852]: OPTIONS IMPORT: LZO parms modified
Jun 17 19:56:05 openvpn[2852]: OPTIONS IMPORT: --ifconfig/up options modified
Jun 17 19:56:05 openvpn[2852]: OPTIONS IMPORT: route options modified
Jun 17 19:56:05 openvpn[2852]: OPTIONS IMPORT: route-related options modified
Jun 17 19:56:05 openvpn[2852]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Jun 17 19:56:05 openvpn[2852]: TUN/TAP device tun11 opened
Jun 17 19:56:05 openvpn[2852]: TUN/TAP TX queue length set to 100
Jun 17 19:56:05 openvpn[2852]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Jun 17 19:56:05 openvpn[2852]: /usr/sbin/ip link set dev tun11 up mtu 1500
Jun 17 19:56:05 openvpn[2852]: /usr/sbin/ip addr add dev tun11 10.4.18.223/16 broadcast 10.4.255.255
Jun 17 19:56:10 openvpn[2852]: Ignore conflicted routing rule: 184.75.221.42 255.255.255.255
Jun 17 19:56:10 openvpn[2852]: /usr/sbin/ip route add 0.0.0.0/1 via 10.4.0.1
Jun 17 19:56:10 openvpn[2852]: /usr/sbin/ip route add 128.0.0.0/1 via 10.4.0.1
Jun 17 19:56:10 openvpn-routing: Configuring policy rules for client 1
Jun 17 19:56:10 openvpn-routing: Creating VPN routing table
Jun 17 19:56:10 openvpn-routing: Removing route for 0.0.0.0/1 to tun11 from main routing table
Jun 17 19:56:10 openvpn-routing: Removing route for 128.0.0.0/1 to tun11 from main routing table
Jun 17 19:56:11 openvpn-routing: Removing rule 1101 from routing policy
Jun 17 19:56:11 openvpn-routing: Adding route for 192.168.1.94 to 0.0.0.0 through VPN client 1
Jun 17 19:56:11 openvpn-routing: Completed routing policy configuration for client 1
Jun 17 19:56:11 openvpn[2852]: Initialization Sequence Completed


Sent from my Nexus 7 using Tapatalk

 

[Skuggo]

Just a quick question here. Would it be a good idea to upgrade from the n66u at this point? Seems like it's trailing behind the others in regards to updates. Might it be so that Asus is discontinuing it soon?

 

[frenskefrens]

I'm using the 380.60.alpha3 firmware on RT-AC5300
I want to report the following:
After i added a long line in /etc/hosts via /jffs/scripts/hosts.postconf samba panics and exits:

Jun 18 15:28:00 rc_service: httpd 553:notify_rc restart_samba
Jun 18 15:28:00 Samba Server: smb daemon is stopped
Jun 18 15:28:00 kernel: gro disabled
Jun 18 15:28:00 custom script: Running /jffs/scripts/hosts.postconf (args: /etc/hosts)
Jun 18 15:28:00 kernel: gro enabled with interval 2
Jun 18 15:28:02 smbd[4247]: [2016/06/18 15:28:02.057597, 0] lib/fault.c:47(fault_report)
Jun 18 15:28:02 smbd[4247]: ===============================================================
Jun 18 15:28:02 smbd[4247]: [2016/06/18 15:28:02.057929, 0] lib/fault.c:48(fault_report)
Jun 18 15:28:02 smbd[4247]: INTERNAL ERROR: Signal 11 in pid 4247 (3.6.25)
Jun 18 15:28:02 smbd[4247]: Please read the Trouble-Shooting section of the Samba3-HOWTO
Jun 18 15:28:02 smbd[4247]: [2016/06/18 15:28:02.058147, 0] lib/fault.c:50(fault_report)
Jun 18 15:28:02 smbd[4247]:
Jun 18 15:28:02 smbd[4247]: From: http://www.samba.org/samba/docs/Samba3-HOWTO.pdf
Jun 18 15:28:02 smbd[4247]: [2016/06/18 15:28:02.058335, 0] lib/fault.c:51(fault_report)
Jun 18 15:28:02 smbd[4247]: ===============================================================
Jun 18 15:28:02 smbd[4247]: [2016/06/18 15:28:02.058479, 0] lib/util.c:1117(smb_panic)
Jun 18 15:28:02 smbd[4247]: PANIC (pid 4247): internal error
Jun 18 15:28:02 smbd[4247]: [2016/06/18 15:28:02.058630, 0] lib/util.c:1271(log_stack_trace)
Jun 18 15:28:02 smbd[4247]: unable to produce a stack trace on this platform
Jun 18 15:28:02 smbd[4247]: [2016/06/18 15:28:02.058815, 0] lib/fault.c:372(dump_core)
Jun 18 15:28:02 smbd[4247]: dumping core in /var/cores/smbd
Jun 18 15:28:02 smbd[4247]:

The offending line in /etc/hosts is:
192.168.123.106 raspberrypi.frens.be buongusto.frens.be www.hdsmartapps.com beaute.frens.be www.hobomaasafvaart.be www.frens.be www.zanggroepalegria.nl beatrice.zanggroepalegria.nl cam.frens.be www.jessmin.com

After splitting up the domains into separate lines, samba no longer panics and works fine

 

[Tiga]

Hello, english is not my main language.
Is there an alpha build to use with Asus RT-AC66U (380.60_alpha)?

Thank you very much.

Tiga Jr.

 

[RMerlin]

I'm using the 380.60.alpha3 firmware on RT-AC5300
I want to report the following:
After i added a long line in /etc/hosts via /jffs/scripts/hosts.postconf samba panics and exits:



The offending line in /etc/hosts is:
192.168.123.106 raspberrypi.frens.be buongusto.frens.be www.hdsmartapps.com beaute.frens.be www.hobomaasafvaart.be www.frens.be www.zanggroepalegria.nl beatrice.zanggroepalegria.nl cam.frens.be www.jessmin.com

After splitting up the domains into separate lines, samba no longer panics and works fine

It's a known limitation of uclibc (if I remember correctly, it's been a few years). Nothing I can do about.

 

[RMerlin]

Hello, english is not my main language.
Is there an alpha build to use with Asus RT-AC66U (380.60_alpha)?

Thank you very much.

Tiga Jr.

Please read the first post. Then re-read it a second time.

 

[RMerlin]

Just a quick question here. Would it be a good idea to upgrade from the n66u at this point? Seems like it's trailing behind the others in regards to updates. Might it be so that Asus is discontinuing it soon?

It's not trailing behind by more than a single release. 380.59 is available for the RT-N66U. 380.60 isn't, due to the GPL release missing necessary components.

 

[RMerlin]

Jun 17 19:55:18 rc_service: httpds 1614:notify_rc stop_vpnclient1

For some reasons the updown and vpnrouting script are not executed at all when you stop your tunnel, so there's no cleanup being done. Please post the content of the Custom Settings box on your VPN client config, as you might be overriding the scripts with a specific configuration there.

 

[z3r0k3wl]

For some reasons the updown and vpnrouting script are not executed at all when you stop your tunnel, so there's no cleanup being done. Please post the content of the Custom Settings box on your VPN client config, as you might be overriding the scripts with a specific configuration there.

remote-cert-tls server
route-delay 5
explicit-exit-notify 5

Sent from my Nexus 7 using Tapatalk

 

[RMerlin]

remote-cert-tls server
route-delay 5
explicit-exit-notify 5

Sent from my Nexus 7 using Tapatalk

Try removing "explicit-exit-notify 5".

 

[z3r0k3wl]

Try removing "explicit-exit-notify 5".

Same results after removing it.

Sent from my Nexus 7 using Tapatalk

 

[RMerlin]

Same results after removing it.

Sent from my Nexus 7 using Tapatalk

Reboot your router after changing this. This setting is definitely causing problems with your router's ability to execute the cleanup script. See this entry fron 376.54's changelog:

- FIXED: Router DNS weren't reverted to their original values
            when shutting down an OpenVPN client with "explicit-
            exit-notify" enabled.  Now we manually clean it up
            after the user manually terminates the client - it might
            still not be cleaned up after an unexpected shutdown however.
            Ideally, users should try avoiding using this setting when
            possible.

While the firmware now handles the DNS, it still can't handle the policy-based routes cleanup if you use that setting.