[Test builds] 380.58 alpha builds are now available

[Marc Elser]

Hi,

Also in this new 380.58_beta builds I have the same problem as with 380_57 and 380_56. the scripts in /jffs/scripts are not started anymore. I always have to log-in through ssh and execute them manually. At least /jffs/scripts/services-start is not executed anymore. I'm not completely sure about /jffs/scripts/firewall-start, maybe that scripts is executed, but services-start is not.

It used to work maybe with 380.55 or so, but it stopped working for quite some time now. Can you please fix this for the 380.58 final, would be nice to have starting those scripts working again. Especially as you mention them as feature in your readme.

Thanks

 

[RMerlin]

Sorry, my fault. I don't know why I thought that the last number on firmware's version was the GPL number. For example, right now on Asus website and for AC68U you can find:

Asus released a binary firmware, but they did not release the corresponding source code.

 

[RMerlin]

Hi,

Also in this new 380.58_beta builds I have the same problem as with 380_57 and 380_56. the scripts in /jffs/scripts are not started anymore. I always have to log-in through ssh and execute them manually. At least /jffs/scripts/services-start is not executed anymore. I'm not completely sure about /jffs/scripts/firewall-start, maybe that scripts is executed, but services-start is not.

It used to work maybe with 380.55 or so, but it stopped working for quite some time now. Can you please fix this for the 380.58 final, would be nice to have starting those scripts working again. Especially as you mention them as feature in your readme.

Thanks

Scripts are working fine in the firmware, check your System Log. I bet you didn't enable them - this will show in your system log.

 

[Lee Banwell]

They don't push any route to you, which means they are most likely not configured to redirect Internet traffic through them. This is how the PUSH request look like with vpnbook:

Mar 13 14:23:55 openvpn[833]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS  8.8.8.8,dhcp-option DNS  91.239.100.100,route 10.9.0.1,topology net30,ping 5,ping-restart 30,ifconfig 10.9.0.30 10.9.0.29'

The "redirect-gateway def1" instructs the client to redirect all traffic through its gateway.

Yours look like this:

Mar 11 00:31:27 openvpn[842]: PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 202.14.67.4,dhcp-option DNS 202.14.67.14,ping 1,ping-restart 60,route-gateway 100.64.16.1,topology subnet,ifconfig 100.64.16.2 255.255.248.0'

route-gateway only instructs what gateway to use for routes that get pushed to the client, but I don't see any route pushed to you.

Try adding "redirect-gateway def1" to your Custom configuration to see if it resolves the issue.

Been having the same issue here. It appears myself and the OP use the same VPN provider - StrongVPN or reliablehosting.

My push command is

Mar 18 12:20:53 openvpn[1142]: PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 202.14.67.4,dhcp-option DNS 202.14.67.14,ping 1,ping-restart 60,route-gateway 100.64.16.1,topology subnet,ifconfig 100.64.16.3 255.255.248.0'

You are correct inserting the "redirect-gateway def1" works and I can now reroute via the policy rules - Success.

I do however get a warning in the sys log -

Mar 18 12:23:22 openvpn[1315]: Ignore conflicted routing rule: 103.16.229.125 255.255.255.255

Also the GUI warns routing conflict on the VPN page. I assume its safe to ignore this message?

 

[RMerlin]

Been having the same issue here. It appears myself and the OP use the same VPN provider - StrongVPN or reliablehosting.

My push command is

Mar 18 12:20:53 openvpn[1142]: PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 202.14.67.4,dhcp-option DNS 202.14.67.14,ping 1,ping-restart 60,route-gateway 100.64.16.1,topology subnet,ifconfig 100.64.16.3 255.255.248.0'

You are correct inserting the "redirect-gateway def1" works and I can now reroute via the policy rules - Success.

Do they offer a control panel? If so, check if there's an option that might need to be enabled to request that all traffic be redirected through the tunnel.

Otherwise, looks like a misconfiguration on their end, or something that they expect their custom client (assuming they offer one) is taking care of it automatically. Either way, it's not a bug in the firmware, and providing the missing option would also fix your problem.

I do however get a warning in the sys log -

Mar 18 12:23:22 openvpn[1315]: Ignore conflicted routing rule: 103.16.229.125 255.255.255.255

Also the GUI warns routing conflict on the VPN page. I assume its safe to ignore this message?

Yes, openvpn has already ignored the duplicate/conflicting rule.

 

[tamalero]

Try plugging them to a different outlet. It's unlikely to be the cause of your problem since you are using UPSes (which would filter out any electrical noise), but worth a try.

not need out, just found it is not my router.
Its my ISP.

My "New" ISP does give you a "fake" B class ip that "shares" a rotating pool of external ips that change every 10-30minutes.
This is confusing my router and is done to prevent file sharing, ftp server, camera.
They do this to shove you a 60 USD fee for having a "external ip".
I'm going to start looking for new ISPS.

So it seems every ip changes from the pool confuses my ASUS router (this causes the glitch) and has to "refresh' all paths again(hence why everything works fine if I click RECONNECT on the WAN button, until the external ip changes again).

 

[el pescador]

Its present, but don't work fine

Also 380.59 MU-MIMO alpha has a problem with movistar.
No internet connection.

"waiting for PADO packets" shows in the system log.
AC88U

buenas dias

 

[el pescador]

Can confirm that movistar via the manual method and static ip on the decoder doesnt work on this beta.
Have the same settings on alpha 4 and it works fine.

 

[hggomes]

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.

Welcome to RT-AC56U world, bootloader on this model was always a mess from the beginning, i cannot tell you what i've already seen happening on this specific model, the same as you and even more. You can revive it or not, it depends the router mood.

My conclusion was that some FWs make it happen somehow...

PS: No JTAG software support, only serial port works.