[Beta] Asuswrt-Merlin 380.66 Beta is now available

[Xentrk]

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.

I have TorGuard, with 380.65 testing, I found I have to have Accept DNS Configuration set to "Strict" and not "Exclusive" when I use Policy Rules. Did you try that combination?

I also found I have to add the following in Custom Configuration
dhcp-option DNS xxx.xxx.xxx.xxx (xxx’s is the IP address of TorGuard DNS Server 1)
dhcp-option DNS xxx.xxx.xxx.xxx (xxx’s is the IP address of TorGuard DNS Server 2)

Explanation here:
I use AB-Solution 3.6.5 on all of my routers. A few days after upgrading to 380.65, I attempted to update AB-Solution on the router with Policy Rules. I was unable to connect to the AB-Solution server to perform the update and unable to ping the AB Solution server. However, I could connect and ping the AB Solution server on my other router with Redirect Internet traffic set to ALL. This is a symptom of a routing issue. The other item that no longer worked was the email function built into AB-Solution. My AB-Solution email settings are the same on the router with Redirect Internet traffic set to ALL, and on the router with Redirect Internet traffic set to Policy Rules. Having the dhcp-option DNS setting in the Custom Configuration section resolved these two issues.

 

[Alfsu]

service stop_vpnclient1
service start_vpnclient1

Excellent, this will help me until I get time for a factory reset and reconfiguration.

Thanks a lot!

Sent from my ONEPLUS A3000 using Tapatalk

 

[RMerlin]

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.

I forgot to apply the same fix to the updown.sh script that I did to vpnrouting.sh, so the DNS redirection rules aren't properly created when in DNS "Exclusive" mode. I cannot test the fix at this time because the VPNBook server I use for testing is currently down (happens a lot lately, might be time to ask one of the VPN providers out there for a free testing account), but looking at the code, this would make sense.

People could probably work around the issue by having a fixed version of the updown.sh script in JFFS, and doing a mount bind on it at boot time. The following line:

if [ $instance != 0 -a $(nvram get vpn_client$(echo $instance)_rgw) >= 2 -a $(nvram get vpn_client$(echo $instance)_adns) = 3 ]

Need to be changed with:

if [ $instance != 0 -a $(nvram get vpn_client$(echo $instance)_rgw) -ge 2 -a $(nvram get vpn_client$(echo $instance)_adns) = 3 ]

 

[charlie2alpha]

So I tried the latest beta. Back to my usual issue with Traditional QoS, the IPv6 mangle rules are generated but not applied! The simple command 'ip6tables-restore /tmp/mangle_rules_ipv6' successfully enables them to work! Since I know @RMerlin certainly didn't cause this, it's obvious ASUS messed up yet again. Going to resume testing, for now I will add the previously mentioned command to the firewall-start script.

 

[RMerlin]

So I tried the latest beta. Back to my usual issue with Traditional QoS, the IPv6 mangle rules are generated but not applied! The simple command 'ip6tables-restore /tmp/mangle_rules_ipv6' successfully enables them to work! Since I know @RMerlin certainly didn't cause this, it's obvious ASUS messed up yet again. Going to resume testing, for now I will add the previously mentioned command to the firewall-start script.

Can you point at the code portion where this should be happening?

Asus did some reorganization to the QoS code a few revisions ago, I didn't dare dive into it too much since then (beside re-applying my Codel/overhead patches to it).

 

[Jasso]

Uploaded Beta4 and Ping in network tools doesn't work .... no hardship

RT-N66U

 

[MarkRH]

Uploaded Beta4 and Ping in network tools doesn't work .... no hardship

RT-N66U

Ping worked for me on my RT-AC68U with 66 beta 4. Tried Google in the drop-down and typed in my website. Both fine.

PING markheadrick.com (72.29.66.18): 56 data bytes
64 bytes from 72.29.66.18: seq=0 ttl=52 time=46.068 ms
64 bytes from 72.29.66.18: seq=1 ttl=52 time=44.098 ms
64 bytes from 72.29.66.18: seq=2 ttl=52 time=43.873 ms
64 bytes from 72.29.66.18: seq=3 ttl=52 time=50.073 ms
64 bytes from 72.29.66.18: seq=4 ttl=52 time=44.976 ms

--- markheadrick.com ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 43.873/45.817/50.073 ms

 

[Gregory Phillips]

Its not working on my RT-AC88U either. When I try to ping nothing happens.

 

[greggy101]

Its not working on my RT-AC88U either. When I try to ping nothing happens.

No problem with ping on my 88

 

[Gregory Phillips]

Traceroute and nslookup work just fine but ping doesn't.

 

[Xentrk]

Ping, Traceroute and nslookup to www.google.com all work for me on my AC88U with Beta4.

 

[TheOldMan]

Ping, Traceroute and nslookup to www.google.com all work for me on my AC88U with Beta4.

All working fine here. No issues. RT-AC87U here.

 

[Goran]

ping working on AC-88U .66 beta4

 

[Denna]

@RMerlin,

On the RT-AC88U, the WAN interface was vlan2, but it now appears as eth0. Is that a typo or a permanent change ?

 

[AndreiV]

Its not working on my RT-AC88U either. When I try to ping nothing happens.

AC3200 and latest beta , just ran ping for 6 sites, no problem at all.

 

[Maghook]

Operating my RT-AC88 in AP mode on 380.66b4

Today I decided to reset nvram (clean setup).
Had some reproduceable trouble completing the initial internet setup wizard on .66b4 (both on using IE11 and FF53). After setting up SSIDs /w PSKs I could not complete the wizard(apply button on that very last setup page had no function at all). Only successful workaround was to switch to the ASUS firmware (current 380 branch) for completing the intial setup wizard and afterwards switching back to .66b4 (Had no trouble with 3.0.0.4.380.7378 but I would like to use 380.66 )

Could anyone confirm this weired behavior of the initial internet setup wizard for AP mode configuration or could this be just something client-related issue?

 

[iManuB]

Its not working on my RT-AC88U either. When I try to ping nothing happens.

My RT-AC3200 with last beta 380.66B4 working well. No problem at all.

I've a question:

I forgot to check SHA256. If the update has come to an end, I do not have to worry about it, right?

It all seems to work perfectly.

 

[eclp]

Syslog RT-AC87U with 380.66 beta 4:

May  7 12:26:24 miniupnpd[1725]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
May  7 12:26:24 miniupnpd[1725]: Failed to get IP for interface eth0
May  7 12:26:24 miniupnpd[1725]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping

What does it mean, what can I do?

 

[Xentrk]

I updated Router with Policy Rules to 380.66 Beta4 and tested both Policy Rules and Policy Rules (Strict) setting over the WAN and LAN. I don't have any problems. My settings are described in #242 above.

 

[voyager62]

DHCP Reservation client names haven't been fixed yet.

Supposedly fixed in this version:

- FIXED: Couldn't add a DHCP reservation client if its name contained a quote.

But it was actually only fixed for names containing an apostrophe (ASCII 39 or ' ), which is sometimes referred to as a single quote. You still can't add any device with a hostname containing an actual quotation mark (ASCII 34 or " ).

Entering a hostname with an underline (_) is still broken, even though the popup message clearly states that it is a legal character.

Hostname must only contain alphanumeric characters, underline and dash symbol. The first character cannot be dash "-" or underline "_".

So far I've been able to workaround this bug by copying and pasting the underline character into the hostname field.

Another bug that still exists, although it is caught by pressing the add button, is that typing the period character (.) into the hostname field is allowed even though it's not a legal character.