[Beta] Asuswrt-Merlin 380.66 Beta is now available

[elintseeker]

What browser are you using?

Same problem on AC56U. Tried both Firefox and Chrome for Linux.

Am on MacOS, tried Chrome, Safari, and Firefox.

 

[RMerlin]

Is airtime fairness more problematic on this version vs. 380.64 or 65?

No idea, I have zero problem here.

 

[Alfsu]

Are the conflicts back with beta 2, where I reverted the routing policy changes of beta 1?

I spoke too soon, in my AC68P the conflicts still exist in beta 1

...
Apr 29 08:41:05 openvpn[2395]: /usr/sbin/ip route add 0.0.0.0/1 via 10.4.0.1
Apr 29 08:41:05 openvpn[2395]: /usr/sbin/ip route add 128.0.0.0/1 via 10.4.0.1
...
Apr 29 08:41:06 openvpn[2347]: Ignore conflicted routing rule: 0.0.0.0 128.0.0.0
Apr 29 08:41:06 openvpn[2347]: Ignore conflicted routing rule: 128.0.0.0 128.0.0.0
...
Apr 29 08:41:06 openvpn-routing: Configuring policy rules for client 3
Apr 29 08:41:06 openvpn-routing: Creating VPN routing table
Apr 29 08:41:06 openvpn-routing: Configuring policy rules for client 1
Apr 29 08:41:06 openvpn-routing: Creating VPN routing table
Apr 29 08:41:06 openvpn-routing: Removing route for 0.0.0.0/1 to tun13 from main routing table
Apr 29 08:41:06 openvpn-routing: Removing route for 128.0.0.0/1 to tun13 from main routing table
Apr 29 08:41:06 openvpn-routing: Removing route for 10.8.0.0/24 to tun11 from main routing table
Apr 29 08:41:06 openvpn-routing: Removing route for 192.168.121.0/24 to tun11 from main routing table
Apr 29 08:41:06 openvpn-routing: Removing rule 10101 from routing policy
Apr 29 08:41:06 openvpn-routing: Adding route for 192.168.110.253 to 0.0.0.0 through VPN client 3
Apr 29 08:41:06 openvpn-routing: Adding route for 192.168.110.64/26 to 0.0.0.0 through VPN client 1
Apr 29 08:41:06 openvpn-routing: Adding route for 192.168.110.23 to 0.0.0.0 through VPN client 3
Apr 29 08:41:06 openvpn-routing: Tunnel re-established, restoring WAN access to clients
Apr 29 08:41:06 openvpn-routing: Completed routing policy configuration for client 1
Apr 29 08:41:06 openvpn[2347]: Initialization Sequence Completed
Apr 29 08:41:06 openvpn-routing: Completed routing policy configuration for client 3
Apr 29 08:41:06 openvpn[2395]: Initialization Sequence Completed

This only happens upon rebooting the router and both clients are set to start with the WAN. If only one client is started with WAN, and the other is started manually there is no conflicts. (Could there be a timing issue?)
Even with this behavior however, in beta 1 these conflicted routing rules do not block the traffic for the affected tunnel (client 1 in this case) as it was with 365-4.

Now with beta 2 on the AC56U, the client connections are not intertwine and no conflicts are reported:

Apr 29 09:07:08 openvpn[1232]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Apr 29 09:07:08 openvpn[1232]: /usr/sbin/ip link set dev tun13 up mtu 1500
Apr 29 09:07:08 openvpn[1232]: /usr/sbin/ip addr add dev tun13 10.4.0.252/24 broadcast 10.4.0.255
Apr 29 09:07:08 openvpn[1232]: updown.sh tun13 1500 1542 10.4.0.252 255.255.255.0 init
...
Apr 29 09:07:13 openvpn[1210]: /usr/sbin/ip route add 0.0.0.0/1 via 10.2.0.1
Apr 29 09:07:13 openvpn[1210]: /usr/sbin/ip route add 128.0.0.0/1 via 10.2.0.1
Apr 29 09:07:13 openvpn-routing: Configuring policy rules for client 2
Apr 29 09:07:13 openvpn-routing: Creating VPN routing table
Apr 29 09:07:13 openvpn-routing: Removing route for 0.0.0.0/1 to tun12 from main routing table
Apr 29 09:07:13 openvpn-routing: Removing route for 128.0.0.0/1 to tun12 from main routing table
Apr 29 09:07:14 openvpn-routing: Adding route for 192.168.120.64/26 to 0.0.0.0 through VPN client 2
Apr 29 09:07:14 openvpn-routing: Completed routing policy configuration for client 2
Apr 29 09:07:14 openvpn[1210]: Initialization Sequence Completed
...
Apr 29 09:07:18 openvpn[1232]: /usr/sbin/ip route add 0.0.0.0/1 via 10.4.0.1
Apr 29 09:07:18 openvpn[1232]: /usr/sbin/ip route add 128.0.0.0/1 via 10.4.0.1
Apr 29 09:07:18 openvpn-routing: Configuring policy rules for client 3
Apr 29 09:07:18 openvpn-routing: Creating VPN routing table
Apr 29 09:07:18 openvpn-routing: Removing route for 0.0.0.0/1 to tun13 from main routing table
Apr 29 09:07:18 openvpn-routing: Removing route for 128.0.0.0/1 to tun13 from main routing table
Apr 29 09:07:18 openvpn-routing: Adding route for 192.168.120.200 to 0.0.0.0 through VPN client 3
Apr 29 09:07:19 openvpn-routing: Completed routing policy configuration for client 3
Apr 29 09:07:19 openvpn[1232]: Initialization Sequence Completed

I realize now that testing beta 2 in the AC68P router is needed, so I will do that next.

Hope this info helps

 

[Alfsu]

Beta 2 in the AC68P show the same behavior as beta1

Apr 29 09:33:34 openvpn[1365]: /usr/sbin/ip route add 0.0.0.0/1 via 10.4.0.1
Apr 29 09:33:34 openvpn[1365]: /usr/sbin/ip route add 128.0.0.0/1 via 10.4.0.1
Apr 29 09:33:34 openvpn[1315]: Ignore conflicted routing rule: 0.0.0.0 128.0.0.0
Apr 29 09:33:34 openvpn[1315]: Ignore conflicted routing rule: 128.0.0.0 128.0.0.0
Apr 29 09:33:34 openvpn[1315]: /usr/sbin/ip route add 192.168.121.0/24 via 10.8.0.9
Apr 29 09:33:34 openvpn[1315]: /usr/sbin/ip route add 10.8.0.0/24 via 10.8.0.9
Apr 29 09:33:35 openvpn-routing: Configuring policy rules for client 3
Apr 29 09:33:35 openvpn-routing: Configuring policy rules for client 1
Apr 29 09:33:35 openvpn-routing: Creating VPN routing table
Apr 29 09:33:35 openvpn-routing: Creating VPN routing table
Apr 29 09:33:36 openvpn-routing: Removing route for 10.8.0.0/24 to tun11 from main routing table
Apr 29 09:33:36 openvpn-routing: Removing route for 0.0.0.0/1 to tun13 from main routing table
Apr 29 09:33:36 openvpn-routing: Removing route for 192.168.121.0/24 to tun11 from main routing table
Apr 29 09:33:36 openvpn-routing: Removing route for 128.0.0.0/1 to tun13 from main routing table
Apr 29 09:33:36 openvpn-routing: Removing rule 10101 from routing policy
Apr 29 09:33:37 openvpn-routing: Adding route for 192.168.110.253 to 0.0.0.0 through VPN client 3
Apr 29 09:33:37 openvpn-routing: Adding route for 192.168.110.64/26 to 0.0.0.0 through VPN client 1
Apr 29 09:33:37 openvpn-routing: Tunnel re-established, restoring WAN access to clients
Apr 29 09:33:37 openvpn-routing: Adding route for 192.168.110.23 to 0.0.0.0 through VPN client 3
Apr 29 09:33:37 openvpn-routing: Completed routing policy configuration for client 1
Apr 29 09:33:37 openvpn[1315]: Initialization Sequence Completed
Apr 29 09:33:37 openvpn-routing: Completed routing policy configuration for client 3
Apr 29 09:33:37 openvpn[1365]: Initialization Sequence Completed

 

[Naftali Oziel]

ATF. Is more for older G mixed with N devices as far as i understand what ATF does. I have had it disabled here with all N devices and have seen no issues at all. Its a outdated feature.

Thanks, what do you keep your wireless mode set to, N only or Auto?

 

[Deleted member 22229]

Thanks, what do you keep your wireless mode set to, N only or Auto?

I only use the 5 GHz. Band and I leave it set to auto. I do set a fixed channel though instead of auto for channels.

 

[Naftali Oziel]

No idea, I have zero problem here.

Thanks, thus far never had an issue as well and reference is for the 2.4 band. Figured to ask in case some changes were made to the code that contributed to some users having issues with ATF with 380.66 code.

 

[Naftali Oziel]

I only use the 5 GHz. Band and I leave it set to auto. I do set a fixed channel though instead of auto for channels.

Thanks am using the 2.4 simply that it has a better range for my house. 5 Ghz works well but I would have to have another AP to extend my range.

 

[Master84]

Hi

after flashing the Beta 2 i couldn´t logged in from any client. Nothing happends, t tried it from my samsung tablet an also from my PC with firefox.
the adresse of the router is the same like before.

can someboy please help me?

 

[Gregory Phillips]

The reboot scheduler is working again on my rt-ac88u and my unit is now keeping to the schedule.

Hi

after flashing the Beta 2 i couldn´t logged in from any client. Nothing happends, t tried it from my samsung tablet an also from my PC with firefox.
the adresse of the router is the same like before.

can someboy please help me?

Have you tried unplugging it and allowing it to deenergize then bring it back up? Have you tried using router.asus.com to log in? If those don't work then you might have to perform a hard reset and reenter your settings.

 

[Goran]

AC-88U .66 beta 2
Can someone tell me which QoS is broken and which is working.
And some guide for optimal settings.
I am on cable 50/10 and using PIA VPN client 128-CBC which significantly suffer from QoS (max speed 9/5). If QoS is off than I get max speeds.
Tnx.

 

[bratik]

Thanks Merlin!,
Running beta 2 on AC3200 for 24 hours. No issues, ipv6 working fine with Comcast. OpenVPN, Mac and iPhone clients can successfully establish connection.
The only unusual messages i see are:

Apr 28 23:00:41 disk_monitor: Got SIGALRM...
Apr 29 07:51:21 rc_service: httpds 527:notify_rc restart_wlcsca

 

[Xentrk]

Thanks Merlin!,
Running beta 2 on AC3200 for 24 hours. No issues, ipv6 working fine with Comcast. OpenVPN, Mac and iPhone clients can successfully establish connection.
The only unusual messages i see are:

Apr 28 23:00:41 disk_monitor: Got SIGALRM...
Apr 29 07:51:21 rc_service: httpds 527:notify_rc restart_wlcsca

I saw that message as well. Here is the meaning...
https://www.snbforums.com/threads/asuswrt-merlin-378-54_2-is-now-available.24902/page-2#post-186506

So far so good with 380.66 Beta 2. It has been just over 30 hours with no issues on two routers. One has VPN policy rules and the other is VPN all traffic.

 

[Master84]

The reboot scheduler is working again on my rt-ac88u and my unit is now keeping to the schedule.

Have you tried unplugging it and allowing it to deenergize then bring it back up? Have you tried using router.asus.com to log in? If those don't work then you might have to perform a hard reset and reenter your settings.

thank you it works now, i unpluged it and now i can logging in just like before

 

[RMerlin]

Apr 29 08:41:06 openvpn[2347]: Ignore conflicted routing rule: 0.0.0.0 128.0.0.0
Apr 29 08:41:06 openvpn[2347]: Ignore conflicted routing rule: 128.0.0.0 128.0.0.0

Those are created automatically by OpenVPN, they aren't actually pushed by the provider. They are rules meant to forward all traffic through the tunnel, hence the error, so any provider that uses it will have the same rules. You can tell OpenVPN to stop auto-creating these with the following config:

pull-filter ignore "redirect-gateway def1"

And also make sure your custom section does not contain "redirect-gateway def1".

 

[netguru]

with beta2 this problem is solved suddenly

"OpenVPN NCP support is now fully disabled when set as such on the webui."
Is there any flag to do this?

"openvpn[968]: Recursive routing detected, drop tun packet to [AF_INET]xxx:1194" as in alpha4 ...

 

[tsunami2311]

AC-88U .66 beta 2
Can someone tell me which QoS is broken and which is working.
And some guide for optimal settings.
I am on cable 50/10 and using PIA VPN client 128-CBC which significantly suffer from QoS (max speed 9/5). If QoS is off than I get max speeds.
Tnx.

Traditional QOS is broke on all but few models like the AC66U last i checked (been forced to use Limiting if I want to have access to the 200mbit my connection can do) , Adaptive works models that support it, bandwitdth limiter too but I wouldnt call limiter

 

[RMerlin]

with beta2 this problem is solved suddenly

"OpenVPN NCP support is now fully disabled when set as such on the webui."

Nothing sudden about it, I added the necessary settings to do so.

Is there any flag to do this?

"openvpn[968]: Recursive routing detected, drop tun packet to [AF_INET]xxx:1194" as in alpha4 ...

This is a new feature that they added in OpenVPN 2.4.0. You can disable this new feature with this setting:

allow-recursive-routing

 

[RMerlin]

Those are created automatically by OpenVPN, they aren't actually pushed by the provider. They are rules meant to forward all traffic through the tunnel, hence the error, so any provider that uses it will have the same rules. You can tell OpenVPN to stop auto-creating these with the following config:

pull-filter ignore "redirect-gateway def1"

And also make sure your custom section does not contain "redirect-gateway def1".

I suspect the root problem is because clients are started in parallel, so rules get piled up before each instance has a chance to clean up the table. I'll see if inserting a pause between client starts might help alleviate the problem.

 

[heysoundude]

Thanks, what do you keep your wireless mode set to, N only or Auto?

if your network doesn't have any b/g devices, there's no reason to not be N Only...regardless of frequency range, 2.4 or 5 GHz. And if your network devices can do both, select which freq range to use based on their usual distance from the transmission site (router/AP location). This basically optimizes the wireless links for reliability, from which comes speed.