[Beta] Asuswrt-Merlin 380.66 Beta is now available

[RMerlin]

Both VPN servers push their own DNS servers:

Pushing a DNS and pushing a route/gateway are two totally different things.

This is my Firewall-start script:

Nothing that jumps out to me out of these, but without knowing the content of each, it's hard for me to be sure. I'd recommend testing without any custom script. If the issue disappears, then you know it's caused by one of the scripts, you can start re-introducing them until you track down the source.

 

[Naftali Oziel]

Not yet, won't be until I'm satisfied with things. There will definitely be at least another beta, as more things will need to be tested.

Thank you, make sense, another question, I currently have AC68U AP and looking to upgrade to AC-88U same AP mode. However, contemplating, if it is worth my investment to swap it out for coverage purpose. Since am am unable to locate the 88U in Toronto, I may just get the AC3100. As I understand, both devices are identical exception to the LAN ports. Not sure if there are caveats to the AC3100 such as reliability, NVRAM limitation etc. Coverage perspective has there been significant improvements? Simply trying to see if it makes sense to make the investment as I only use mine as AP only basic configuration.

Any thoughts?

 

[RMerlin]

Any thoughts?

Please don't derail this thread. I want people to keep it on the topic of beta testing, so I can easily go back to that thread throughout development to review past reports.

 

[Revelstone77]

Need more information as to how you have it configured, and whether there are any error message in System Log.

i finally figured out where to configure policy strict. i have one machine that i dont want to go out the tunnel. i put it explicitly in the list with wan selected instead of vpn in all three clients that i have configured. It is still going out the vpn. syslog shows it explicitly configured for Wan.
May 4 22:48:29 openvpn-routing: Configuring policy rules for client 1
May 4 22:48:29 openvpn-routing: Creating VPN routing table
May 4 22:48:30 openvpn-routing: Adding route for 192.168.1.50 to 0.0.0.0 through VPN client 1
May 4 22:48:30 openvpn-routing: Adding route for 192.168.1.91 to 0.0.0.0 through WAN
May 4 22:48:30 openvpn-routing: Completed routing policy configuration for client 1

Let me know what else you need.

 

[RMerlin]

i finally figured out where to configure policy strict. i have one machine that i dont want to go out the tunnel. i put it explicitly in the list with wan selected instead of vpn in all three clients that i have configured. It is still going out the vpn. syslog shows it explicitly configured for Wan.
May 4 22:48:29 openvpn-routing: Configuring policy rules for client 1
May 4 22:48:29 openvpn-routing: Creating VPN routing table
May 4 22:48:30 openvpn-routing: Adding route for 192.168.1.50 to 0.0.0.0 through VPN client 1
May 4 22:48:30 openvpn-routing: Adding route for 192.168.1.91 to 0.0.0.0 through WAN
May 4 22:48:30 openvpn-routing: Completed routing policy configuration for client 1

Let me know what else you need.

Works for me. Also note that the default behaviour is to NOT go through the WAN, so there's no reason why that other client should end up through the tunnel. How are you testing it?

 

[RMerlin]

380.66 Beta 4 is now available.

This update fixes Policy routing (please do further tests on it, especially the new Policy Rules (strict) mode, so I can determine if this mode is actually usable, otherwise it will be scrapped).

I have also done a number of tweaks related to minidlna and miniupnpd. Detailed list of changes since beta 3:

200863d Hyperlinked SNBForums in README.md page
4cc25ae Reformatted README.md using wiki encoding
dca898f Trying to deal with Github's (lack of) formatting.
342b52d Put warning sign about not using Github's issue tracker for support requests
2c39804 rc: use get_lan_hwaddr() for miniupnpd and mdns, since that function already takes care of dealing with gmac3
7575f4b Merge branch 'master' of github.com:RMerl/asuswrt-merlin
4fb815d minidlna: fix previous commit (missing function, typo, and also point out this is for minidlna, not miniupnpd)"
64de67a miniupnpd: fix previous commit (missing function and typo)"
62d7471 miniupnpd: always use the same UUID, based on LAN MAC (based on a patch by john9527)
2f0f9d2 webui: switch hyperlink on Asuswrt-Merlin logo to use https
d4ca551 Bumped revision to beta 4
d559528 shared: replace GMAC3 fix from 662c84514dacb4d4c27ec7ef26b0650179972b39 with Asus's fix backported from GPL 382
35f0b68 webui: define a default value for validator.rangeFloat(), or else the field gets filled with "undefined" on invalid values without a passed default
2c21869 webui: Also accept float values between 0.0 and 1.0 on the QoS bandwidth fields
76ed342 miniupnpd: enable support for portinuse check
c0f73de miniupnpd: process postrouting rules created by the daemon in the nat table.
830ceb7 openvpn: Fix vpn routing mode not being properly detected
8510171 Updated documentation

 

[Kanuki]

380.66 Beta 4 is now available.

This update fixes Policy routing (please do further tests on it, especially the new Policy Rules (strict) mode, so I can determine if this mode is actually usable, otherwise it will be scrapped).

I have also done a number of tweaks related to minidlna and miniupnpd. Detailed list of changes since beta 3:

200863d Hyperlinked SNBForums in README.md page
4cc25ae Reformatted README.md using wiki encoding
dca898f Trying to deal with Github's (lack of) formatting.
342b52d Put warning sign about not using Github's issue tracker for support requests
2c39804 rc: use get_lan_hwaddr() for miniupnpd and mdns, since that function already takes care of dealing with gmac3
7575f4b Merge branch 'master' of github.com:RMerl/asuswrt-merlin
4fb815d minidlna: fix previous commit (missing function, typo, and also point out this is for minidlna, not miniupnpd)"
64de67a miniupnpd: fix previous commit (missing function and typo)"
62d7471 miniupnpd: always use the same UUID, based on LAN MAC (based on a patch by john9527)
2f0f9d2 webui: switch hyperlink on Asuswrt-Merlin logo to use https
d4ca551 Bumped revision to beta 4
d559528 shared: replace GMAC3 fix from 662c84514dacb4d4c27ec7ef26b0650179972b39 with Asus's fix backported from GPL 382
35f0b68 webui: define a default value for validator.rangeFloat(), or else the field gets filled with "undefined" on invalid values without a passed default
2c21869 webui: Also accept float values between 0.0 and 1.0 on the QoS bandwidth fields
76ed342 miniupnpd: enable support for portinuse check
c0f73de miniupnpd: process postrouting rules created by the daemon in the nat table.
830ceb7 openvpn: Fix vpn routing mode not being properly detected
8510171 Updated documentation

I keep on getting the error messages 'kernel: xt_TCPMSS: unknown or invalid path-MTU (0)' after upgrading
from 380.66 Alpha 3 to Beta 4.

 

[elintseeker]

@RMerlin
Can confirm QoS manual bandwidth setting UI is fixed.

 

[Alfsu]

@RMerlin,

Further testing on Beta 3:

In an effort to duplicate this issue, loaded up the 56U router with the same VPN configurations as the 68P, and the result was that no routing conflicts were reported; even with start scripts enabled (syslog below).

May 5 09:45:54 openvpn[1222]: TUN/TAP device tun13 opened
May 5 09:45:54 openvpn[1222]: TUN/TAP TX queue length set to 100
May 5 09:45:54 openvpn[1222]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
May 5 09:45:54 openvpn[1222]: /usr/sbin/ip link set dev tun13 up mtu 1500
May 5 09:45:54 openvpn[1222]: /usr/sbin/ip addr add dev tun13 10.4.0.252/24 broadcast 10.4.0.255
May 5 09:45:54 openvpn[1222]: updown.sh tun13 1500 1542 10.4.0.252 255.255.255.0 init
May 5 09:45:57 openvpn[1200]: /usr/sbin/ip route add 173.52.XXX.XXX/32 via 192.168.200.1
May 5 09:45:59 openvpn[1200]: /usr/sbin/ip route add 0.0.0.0/1 via 10.8.0.1
May 5 09:45:59 openvpn[1200]: /usr/sbin/ip route add 128.0.0.0/1 via 10.8.0.1
May 5 09:45:59 openvpn[1200]: /usr/sbin/ip route add 192.168.121.0/24 via 10.8.0.1
May 5 09:46:00 openvpn-routing: Configuring policy rules for client 1
May 5 09:46:00 openvpn-routing: Creating VPN routing table
May 5 09:46:00 openvpn-routing: Removing route for 192.168.121.0/24 to tun11 from main routing table
May 5 09:46:00 openvpn-routing: Removing route for 0.0.0.0/1 to tun11 from main routing table
May 5 09:46:00 openvpn-routing: Removing route for 128.0.0.0/1 to tun11 from main routing table
May 5 09:46:01 openvpn-routing: Adding route for 192.168.100.128/26 to 0.0.0.0 through VPN client 1
May 5 09:46:01 openvpn-routing: Adding route for 192.168.100.1 to 0.0.0.0 through WAN
May 5 09:46:01 openvpn-routing: Tunnel re-established, restoring WAN access to clients
May 5 09:46:01 openvpn-routing: Completed routing policy configuration for client 1
May 5 09:46:01 openvpn[1200]: Initialization Sequence Completed
May 5 09:46:04 openvpn[1222]: /usr/sbin/ip route add 46.166.XXX.XXX/32 via 192.168.200.1
May 5 09:46:04 openvpn[1222]: /usr/sbin/ip route add 0.0.0.0/1 via 10.4.0.1
May 5 09:46:04 openvpn[1222]: /usr/sbin/ip route add 128.0.0.0/1 via 10.4.0.1
May 5 09:46:05 openvpn-routing: Configuring policy rules for client 3
May 5 09:46:05 openvpn-routing: Creating VPN routing table
May 5 09:46:05 openvpn-routing: Removing route for 0.0.0.0/1 to tun13 from main routing table
May 5 09:46:05 openvpn-routing: Removing route for 128.0.0.0/1 to tun13 from main routing table
May 5 09:46:05 openvpn-routing: Adding route for 192.168.120.200 to 0.0.0.0 through VPN client 3
May 5 09:46:05 openvpn-routing: Tunnel re-established, restoring WAN access to clients
May 5 09:46:06 openvpn-routing: Completed routing policy configuration for client 3
May 5 09:46:06 openvpn[1222]: Initialization Sequence Completed​

Disabling all start scripts in the 68P did not resolved the routing conflicts (syslog below).

May 5 10:14:34 openvpn[850]: TUN/TAP device tun13 opened
May 5 10:14:34 openvpn[850]: TUN/TAP TX queue length set to 100
May 5 10:14:34 openvpn[850]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
May 5 10:14:34 openvpn[850]: /usr/sbin/ip link set dev tun13 up mtu 1500
May 5 10:14:34 openvpn[850]: /usr/sbin/ip addr add dev tun13 10.4.0.166/24 broadcast 10.4.0.255
May 5 10:14:34 openvpn[850]: updown.sh tun13 1500 1542 10.4.0.166 255.255.255.0 init
May 5 10:14:42 openvpn[836]: /usr/sbin/ip route add 173.52.XXX.XXX/32 via 192.168.200.1
May 5 10:14:42 openvpn[850]: /usr/sbin/ip route add 46.166.XXX.XXX/32 via 192.168.200.1
May 5 10:14:42 openvpn[850]: /usr/sbin/ip route add 0.0.0.0/1 via 10.4.0.1
May 5 10:14:42 openvpn[850]: /usr/sbin/ip route add 128.0.0.0/1 via 10.4.0.1
May 5 10:14:42 openvpn[836]: Ignore conflicted routing rule: 0.0.0.0 128.0.0.0
May 5 10:14:42 openvpn[836]: Ignore conflicted routing rule: 128.0.0.0 128.0.0.0
May 5 10:14:42 openvpn[836]: /usr/sbin/ip route add 192.168.121.0/24 via 10.8.0.1
May 5 10:14:43 openvpn-routing: Configuring policy rules for client 3
May 5 10:14:43 openvpn-routing: Creating VPN routing table
May 5 10:14:43 openvpn-routing: Configuring policy rules for client 1
May 5 10:14:43 openvpn-routing: Creating VPN routing table
May 5 10:14:43 openvpn-routing: Removing route for 192.168.121.0/24 to tun11 from main routing table
May 5 10:14:43 openvpn-routing: Removing route for 0.0.0.0/1 to tun13 from main routing table
May 5 10:14:43 openvpn-routing: Removing route for 128.0.0.0/1 to tun13 from main routing table
May 5 10:14:43 openvpn-routing: Adding route for 192.168.110.64/26 to 0.0.0.0 through VPN client 1
May 5 10:14:43 openvpn-routing: Tunnel re-established, restoring WAN access to clients
May 5 10:14:43 openvpn-routing: Adding route for 192.168.110.253 to 0.0.0.0 through VPN client 3
May 5 10:14:43 openvpn-routing: Completed routing policy configuration for client 1
May 5 10:14:43 openvpn[836]: Initialization Sequence Completed
May 5 10:14:43 openvpn-routing: Adding route for 192.168.110.23 to 0.0.0.0 through VPN client 3
May 5 10:14:43 openvpn-routing: Tunnel re-established, restoring WAN access to clients
May 5 10:14:43 openvpn-routing: Completed routing policy configuration for client 3
May 5 10:14:43 openvpn[850]: Initialization Sequence Completed​

As you can see in the syslogs above, the sequence of the openvpn in the 56U followed a different pattern than in the 68P. So it seems a timing isssue related to when openvpn-routing is called to remove the default routes of the first client may be at play.

I did even moved the VPN configuration from client 3 to client 2 in an effort to confirm this pathern in the 68P and, yes, the result was the same.

Did you introduced any modification on Beta 4 on this regard? let me know if another round of testing is in order.

 

[Alfsu]

One more thing, a little cosmetic housekeeping, the progress count when turning OFF the VPN client for the first time goes over 100%

If you don't move away from the page and turn the VPN client ON and OFF again, the count is correct stopping at 100%

 

[Alfsu]

RMerlin,

No dice with Beta 4.
Is there a command line that can be used to turn ON / OFF a particular VPN Client?

 

[Cavey]

Hello RMerlin,

I moved from 380_64_2 to 380.66 beta3 yesteday on my AC88U, did the necessary factory resets to make sure no old settings were used from previous firmware version.

Not sure why but when i tried to go in today to the gui it was very slow, i managed to copy part of the log before rebooting the router. Not sure if this is a bug..


May 5 16:02:43 kernel: dhdpcie_checkdied: msgtrace address : 0x00000000
May 5 16:02:43 kernel: console address : 0x003FFCF0
May 5 16:02:43 kernel: Assrt not built in dongle
May 5 16:02:43 kernel: TRAP type 0x1 @ epc 0x20d46a, cpsr 0x40000093, spsr 0x40000033, sp 0x2a9f80, lp 0x2459bf, rpc 0x20d46a
May 5 16:02:43 kernel: Trap offset 0x2a9f28, r0 0x0, r1 0x3c0e58, r2 0x0, r3 0x3e4678, r4 0x3c0e58, r5 0x1, r6 0x3e1360, r7 0x2aaec8
May 5 16:02:46 kernel: dhd_detach(): thread:dhd_watchdog_thread:158e terminated OK
May 5 16:02:46 kernel: br0: port 2(eth1) entering forwarding state
May 5 16:02:46 kernel: device eth1 left promiscuous mode
May 5 16:02:46 kernel: br0: port 2(eth1) entering disabled state
May 5 16:02:46 kernel: dhd_detach(): thread:dhd_watchdog_thread:1588 terminated OK
May 5 16:02:50 kernel: PCI_PROBE: bus 1, slot 0,vendor 14E4, device 4365(good PCI location)
May 5 16:02:50 kernel: dhd_attach(): thread:dhd_watchdog_thread:241b started
May 5 16:02:50 kernel: Dongle Host Driver, version 1.363.45.58013 (r651509)
May 5 16:02:50 kernel: Compiled in drivers/net/wireless/bcmdhd on Mar 20 2017 at 10:13:39
May 5 16:02:50 kernel: Register interface [eth1] MAC: f8:32:e4:52:af:f0
May 5 16:02:50 kernel: PCI_PROBE: bus 1, slot 0,vendor 14E4, device 4365(good PCI location)
May 5 16:02:50 kernel: dhd_attach(): thread:dhd_watchdog_thread:2422 started
May 5 16:02:51 kernel: Dongle Host Driver, version 1.363.45.58013 (r651509)
May 5 16:02:51 kernel: Compiled in drivers/net/wireless/bcmdhd on Mar 20 2017 at 10:13:39
May 5 16:02:51 kernel: Register interface [eth2] MAC: f8:32:e4:52:af:f4
May 5 16:02:51 kernel: device eth1 entered promiscuous mode
May 5 16:02:51 kernel: br0: topology change detected, propagating
May 5 16:02:51 kernel: br0: port 2(eth1) entering forwarding state
May 5 16:02:51 kernel: br0: port 2(eth1) entering forwarding state

 

[Gregory Phillips]

I just updated to beta 4 on my rt-ac88u and will let you know if I see anything out of the ordinary with it. On the beta 2 I saw an issue this morning where it stopped issuing IPv6 address to my pc again even though it claimed to have a connection. Once I flashed to the beta 4 it was restored and as I recall this isn't the first time this has happened, however its the first time since I clean installed 10 on my pc yesterday.

 

[hifiwifi]

2c21869 webui: Also accept float values between 0.0 and 1.0 on the QoS bandwidth fields

Thank you for fixing this. This is a perfect example of the value you bring to the community with your efforts. Much appreciated.

 

[RMerlin]

I keep on getting the error messages 'kernel: xt_TCPMSS: unknown or invalid path-MTU (0)' after upgrading
from 380.66 Alpha 3 to Beta 4.

Check your configuration, you seem to have something configured with an MTU of 0 on either your WAN or your VPN configuration.

Did you introduced any modification on Beta 4 on this regard? let me know if another round of testing is in order.

None, as I can't reproduce the problem, so I have no idea how your router ends up starting multiple clients in parallel.

One more thing, a little cosmetic housekeeping, the progress count when turning OFF the VPN client for the first time goes over 100%

I have randomly experienced it, but I'm not sure what is causing it. I don't fully understand the webui "busy report" code, it's confusing me.

Is there a command line that can be used to turn ON / OFF a particular VPN Client?

service stop_vpnclient1
service start_vpnclient1

 

[Gregory Phillips]

Yes thank you Merlin for creating all of these different bios versions and fixes for people to have for their routers. When I get through with school and go back to work I most definitely will donate to your work. As far as I'm concerned you are the only tech support Asus router owners have.

 

[brummygit]

I've just updated my RT-AC68U to beta 4 and looked to see if your QoS bandwidth field validation solved what I think is a longstanding issue. It's still the case that the notes on the page say you can set bandwidth to zero in order to have it unlimited. I would like to apply QoS to my upstream but leave my downstream traffic unlimited. Unfortunately when I try to set this I get the following:

 

[RMerlin]

I've just updated my RT-AC68U to beta 4 and looked to see if your QoS bandwidth field validation solved what I think is a longstanding issue. It's still the case that the notes on the page say you can set bandwidth to zero in order to have it unlimited. I would like to apply QoS to my upstream but leave my downstream traffic unlimited. Unfortunately when I try to set this I get the following:
View attachment 9221

I'm not sure which of the two behaviour is correct. Asus specifically added code to reject a value of 0, while the note says that 0 is valid. My advice is to set the download bandwidth to the same value you are supposed to be getting from your provider, as I'm not even sure a value of 0 still works at all following the recent changes Asus made. It's possible that notice on the side is a left over from before they added the new "Automatic" bandwidth setting.

 

[MacG32]

Same problems as before. I just tested Beta 4 and DNS requests were leaked to my ISP with both settings of Policy Rules and Policy Rules strict. The Accept DNS Configuration is set to Exclusive. I have the IPs assigned to android tablets and then those IPs listed under Policy Rules. On Beta 2 there are no DNS leaks as seen through https://ipleak.net on those devices. Port Forwarding does not list those IPs being forwarded through the VPN in Beta 4. The IPs are present and listed as being forwarded through the VPN in Beta 2.

 

[Xentrk]

380.66 Beta 4 is now available.

This update fixes Policy routing (please do further tests on it, especially the new Policy Rules (strict) mode, so I can determine if this mode is actually usable, otherwise it will be scrapped).

I have also done a number of tweaks related to minidlna and miniupnpd. Detailed list of changes since beta 3:

200863d Hyperlinked SNBForums in README.md page
4cc25ae Reformatted README.md using wiki encoding
dca898f Trying to deal with Github's (lack of) formatting.
342b52d Put warning sign about not using Github's issue tracker for support requests
2c39804 rc: use get_lan_hwaddr() for miniupnpd and mdns, since that function already takes care of dealing with gmac3
7575f4b Merge branch 'master' of github.com:RMerl/asuswrt-merlin
4fb815d minidlna: fix previous commit (missing function, typo, and also point out this is for minidlna, not miniupnpd)"
64de67a miniupnpd: fix previous commit (missing function and typo)"
62d7471 miniupnpd: always use the same UUID, based on LAN MAC (based on a patch by john9527)
2f0f9d2 webui: switch hyperlink on Asuswrt-Merlin logo to use https
d4ca551 Bumped revision to beta 4
d559528 shared: replace GMAC3 fix from 662c84514dacb4d4c27ec7ef26b0650179972b39 with Asus's fix backported from GPL 382
35f0b68 webui: define a default value for validator.rangeFloat(), or else the field gets filled with "undefined" on invalid values without a passed default
2c21869 webui: Also accept float values between 0.0 and 1.0 on the QoS bandwidth fields
76ed342 miniupnpd: enable support for portinuse check
c0f73de miniupnpd: process postrouting rules created by the daemon in the nat table.
830ceb7 openvpn: Fix vpn routing mode not being properly detected
8510171 Updated documentation

Thanks for the update! Looks good so far. Beta4 fixed the problem I had with Beta3, where traffic was being sent thru the WAN rather than the VPN tunnel. This router is DNS Configuration = Exclusive and All Traffic is routed over the VPN. OpenVPN down/up speeds were not impacted as they were with Beta 1. I have same speeds as 380.65_4 and Beta 2.

I have a maintenance window on the router with Strict and Policy Rules tomorrow afternoon. I will update status on that one in about 30 hours from now.