[Test builds] 380.58 alpha builds are now available

[RMerlin]

I looked at porting this over to my fork, and also had the problem. Found the offending line with some of my own debug code....the conversion from backquotes broke a function...

Thanks, I'll revert the change. I only did so for better code uniformity, but otherwise the original code was fine.

(1) If your VPN provider pushes multiple DNS servers which would be used in 'Exclusive' mode, only the first one will actually be used

That's correct. There's no way around this, and it generally should not be a problem. The only real solution would be for dnsmasq to start supporting different resolvers based on the MAC or IP address of the client.

(2) If you defined a CIDR range for VPN, then excludes from that range to WAN, it won't work. You need to specify each client individually

That's indeed a limitation of the current implementation. One fix would be to insert iptables rules as well for WAN clients, with a -j RETURN in them, I just haven't gotten around to looking into it yet (I only briefly tested that CIDR VPN rules worked, but didn't go any further yet with testing).

 

[RMerlin]

Thank you for implementing this. So nice to not have my printer waking up all of the time. What's the negative of disabling this?

Your networkmap list might not always be fully up-to-date, still showing disconnected clients for example.

This is just a temporary workaround. Asus has addressed the problem upstream, so this workaround will be removed once I update to their newer code.

 

[RMerlin]

This fixes the issues with properly creating DNS-routing rules for OpenVPN clients.

This should take care of DNS routing for policy-based rules that are exceptions to routing.

I haven't fully understood why it wasn't working as intended, so for now I'm reverting the watchdog changes that were causing weird LED behaviour on the RT-AC56U.

The previous RT-AC68U driver seems to work fine with the new HW revision C1, so using it for now to resolve RT-AC68U wifi w/o CTF issues.

I'll try to generate updated builds sometime Sunday.

 

[kvic]

Alpha 3 looks pretty good for RT-AC56U* and very solid from my brief tests.

I saw one bug on "reboot" CLI command. It does not stop services nor trigger /jffs/scripts/services-stop before reboot. Reboot from GUI still does..

Not sure when it's broken. It was okay in 378.55

*I didn't check what wireless binaries in Alpha 3. I replaced these directories from 378.9313 the last RT-AC56U GPL before compile:

• router/acsd_arm
• router/eapd_arm
• router/emf_arm
• router/nas_arm
• router/wl_arm
• router/wlconf_arm
• router/wps_arm

 

[tarzan2000]

Good afternoon!
Be careful with the alpha 58 for AC56U.
There was the FW57 from Merlin. I decided to try the FW 58_alpha.
As usual I flashed on WEB. All OK.
The router normally worked during 1 day until stopped working IPTV multicast.
Reboot the router did not help.
I decided to once again return to the FW57.
I uploaded via the web. Page router successfully reached 100% during the process and asked to reboot the router manually. Which I did.

The result: Blue power LED is constantly and cyclically router reboots.
Methods to Reset and WPS button is not helped.
I will try to restore router through jtag.


PS: There was nothing unusual in the NVRAM. Overclocking the processor and the memory was not.
The router works 2.5 years. The temperature of 71-75 degrees Celsius. The power supply is connected to the UPS CyberPower Brics 650VA.

 

[joegreat]

The result: Blue power LED is constantly and cyclically router reboots.
Methods to Reset and WPS button is not helped.
I will try to restore router through jtag.

PS: There was nothing unusual in the NVRAM. Overclocking the processor and the memory was not.

Interesting to see that also others bricked their routers via firmware update as I did - documented here...
In my case the guilty part was identified to be the overclocking - but now I see that you did not overclock and still bricked your router!

 

[tarzan2000]

Yes. It is sad.
But, before, I had a couple of situations with incorrect firmware AC56U. And I've always been able to successfully restore the router through Recovery mode.

 

[Savell Martin]

*EDIT* Brain fart moment

 

[pvonn]

anyone tried on a 5300 yet?

 

[applesnowleo]

anyone tried on a 5300 yet?

I am using alfa 3 on the 5300 and appears to be working stable.

 

[CODYQX4]

This fixes the issues with properly creating DNS-routing rules for OpenVPN clients.

This should take care of DNS routing for policy-based rules that are exceptions to routing.

I haven't fully understood why it wasn't working as intended, so for now I'm reverting the watchdog changes that were causing weird LED behaviour on the RT-AC56U.

The previous RT-AC68U driver seems to work fine with the new HW revision C1, so using it for now to resolve RT-AC68U wifi w/o CTF issues.

I'll try to generate updated builds sometime Sunday.

I can confirm that mounting your latest script as of that post makes it actually apply the DNS on both VPN clients.

It still doesn't seem to killswitch as I expect it to. If I stop my VPN Client 2, it doesn't truly block the client traffic, even on reboot. It certainly deactivates DNS, but I can ping 8.8.8.8 even after rebooting the client, indicating anything making direct IP entries (or caching the DNS) on a client could and would pass through.

 

[RMerlin]

I can confirm that mounting your latest script as of that post makes it actually apply the DNS on both VPN clients.

It still doesn't seem to killswitch as I expect it to. If I stop my VPN Client 2, it doesn't truly block the client traffic, even on reboot. It certainly deactivates DNS, but I can ping 8.8.8.8 even after rebooting the client, indicating anything making direct IP entries (or caching the DNS) on a client could and would pass through.

The killswitch is meant for when the tunnel unexpectedly goes down or fails to connect, not for manually turning off. This is the intended behaviour.

 

[CODYQX4]

The killswitch is meant for when the tunnel unexpectedly goes down or fails to connect, not for manually turning off. This is the intended behaviour.

OK. Do you have a good way to simulate an "unexpected failure"? Perhaps killing a specific process over the terminal or something.

 

[RMerlin]

OK. Do you have a good way to simulate an "unexpected failure"? Perhaps killing a specific process over the terminal or something.

You could try unplugging the WAN long enough for the tunnel to fail, then plug it back in. Monitor syslog to determine when you can plug it back.

 

[teva]

I am using alfa 3 on the 5300 and appears to be working stable.

Same here. So far so good.

 

[RMerlin]

I have uploaded updated builds (380-58 alpha3-gcf77301). Changelog:

cf77301 openvpn: Mark OpenVPN traffic for CTF bypass
bcc5cc4 fw: change NAT loopback mark to a single bit, and use a mask to avoid trashing other bits
05f2ee1 webui: Add setting to enable/disable the IPv6 neigh sol broadcoast drop on Comcast
3a07398 openvpn: ensure that clients set to route traffic through WAN are also excluded from DNS redirection.
976d14c rc: revert watchdog led handling code to pre-1354 as a workaround to RT-AC56U LED issues
4e221ad shared: ensure our custom led ID values don't interfere with Asus's code for cases where they rely on LED_ID_MAX
2557876 wl: Downgraded RT-AC68U driver to  6.37.14.105 (r485445).  Tested functional with both rev. A1 and C1.
3a1c0c1 Revert "openvpn: Uniformize the use of  over backticks; ensure that the fw setup script gets overwritten rather than appen

 

[jsmiddleton4]

AC68U version not loading on mine. Says its the wrong FW. I doubled checked, redownloaded, etc.

I have the faster 68U.

 

[RMerlin]

AC68U version not loading on mine. Says its the wrong FW. I doubled checked, redownloaded, etc.

I have the faster 68U.

Double check your download, someone above you just flashed it without any issue.

 

[MXM]

Got an issue with 380-58 alpha3-gcf77301 on the AC-3200...

On the Administration Tab, Firmware Upgrade, I see this message:

1. WARNING: you have JFFS enabled. Make sure you have a backup of its content, as upgrading your firmware MIGHT overwrite it!

However, the Administration, System Tab clearly has both JFFS options selected to NO
Format JFFS partition at next boot
Enable JFFS custom scripts and configs

Is this normal, a problem, or am I doing something wrong?

 

[RMerlin]

Got an issue with 380-58 alpha3-gcf77301 on the AC-3200...

On the Administration Tab, Firmware Upgrade, I see this message:

1. WARNING: you have JFFS enabled. Make sure you have a backup of its content, as upgrading your firmware MIGHT overwrite it!

However, the Administration, System Tab clearly has both JFFS options selected to NO
Format JFFS partition at next boot
Enable JFFS custom scripts and configs

Is this normal, a problem, or am I doing something wrong?

JFFS has been permanently enabled for a while now, as Asus started storing config data in it. There's no option on the webui to disable it anymore.

Sent from my Nexus 9 using Tapatalk