Having trouble running custom scripts

[Deceiver]

Hi guys,

Not sure if I've posted this in the right forum.

I'm having trouble getting some custom scripts to work and wondered if someone might be able to shed some light on what is happening.

I've been following the tutorial at https://github.com/RMerl/asuswrt-me...ver-VPN-and-Drop-connections-if-VPN-goes-down

I have followed it to the letter and I can't find anywhere on the router GUI that acknowledges that the scripts have been executed. I have even gone so far as to test clients set up with IP addresses that should and shouldn't work with no success.

I am running an Asus RT-AC66U router with Merlin 378.53. If someone could help me out, it would be greatly appreciated.

Cheers.

 

[Hapko]

same issues here - couldn't even get a basic reboot script to run on my AC68

 

[KiloooNL]

Same here - nothing in log to say openvpn-event ran on AC56U

 

[john9527]

Top three reasons scripts won't run....

378.50 introduced a new setting to enable script execution (on the Administration-System page)....make sure it's enabled.

For Windows users, the script was created using a Windows/DOS editor instead of a Linux editor and the file format is incorrect. Use the router shell editor (vi) or WinSCP to create/edit the scripts.

The script wasn't marked as 'executable'. Enter the command 'chmod a+rx scriptname' in the router shell.

 

[KiloooNL]

Top three reasons scripts won't run....

378.53 introduced a new setting to enable script execution (on the Administration-System page)....make sure it's enabled.

For Windows users, the script was created using a Windows/DOS editor instead of a Linux editor and the file format is incorrect. Use the router shell editor (vi) or WinSCP to create/edit the scripts.

The script wasn't marked as 'executable'. Enter the command 'chmod a+rx scriptname' in the router shell.

Dunno about the other guys but:
1 - yes that is enabled for me.
2 - I use notepad++ for scripts and winSCP over ssh to transfer to ac56u jffs folder.
3 - chmod for openvpn-event is set to 0777 - but I ran the command you posted anyway.

When I connect to openVPN server it doesn't say 'running script openvpn-event' or anything along those lines in the log. It just lists openVPN connection logging, nothing about scripts and the iptable commands does obviously not work because the script does not run

 

[john9527]

I use notepad++ for scripts

I seem to remember that Notepad++ defaults aren't quite right and need to be tweaked, but don't remember the details (sorry). Try using the build it editor in WinSCP and see if it makes a difference.

Also, I'll add a #4 to the list.....the script is saved with a .sh extension. Merlin custom scripts have no extension.

 

[KiloooNL]

I seem to remember that Notepad++ defaults aren't quite right and need to be tweaked, but don't remember the details (sorry). Try using the build it editor in WinSCP and see if it makes a difference.

Also, I'll add a #4 to the list.....the script is saved with a .sh extension. Merlin custom scripts have no extension.

Ok I'll try that and see how I get on. And nope, it's not saved as .sh

Weird thing is firewall-start runs but openvpn-event does not. I thought the order was openvpn-event THEN firewall-start but firewall-start comes up in the log but no mention of openvpn-event

 

[john9527]

log but no mention of openvpn-event

By default, I don't believe openvpn-event will put anything in the syslog unless you tell it to. Try adding a logger command in your script....something like

echo "Starting script openvpn-event" | logger -t "openvpn-event"

 

[KiloooNL]

By default, I don't believe openvpn-event will put anything in the syslog unless you tell it to. Try adding a logger command in your script....something like

echo "Starting script openvpn-event" | logger -t "openvpn-event"

Ah right you are. Bingo. It is running. Digging deeper into my script I realized on one line I accidentally set a rule to route through tun12 instead of tun11 which was a typo hence why nothing was working! Thank you

 

[john9527]

Glad you got it figured out...if I had a nickel for every typo I made that caused me grief

 

[RMerlin]

By default, I don't believe openvpn-event will put anything in the syslog unless you tell it to.

That's correct. This is because that script isn't run by rc but by openvpn itself. I'll look into adding a logger call to the updown.sh and vpnrouting.sh scripts that are responsible for launching openvpn-event.

 

[john9527]

That's correct. This is because that script isn't run by rc but by openvpn itself. I'll look into adding a logger call to the updown.sh and vpnrouting.sh scripts that are responsible for launching openvpn-event.

Minor thread hijack....also look at NOT calling openvpn-event from vpnrouting.sh if policy based routing is not active. It's already called by updown.sh so now gets executed twice.

 

[RMerlin]

Minor thread hijack....also look at NOT calling openvpn-event from vpnrouting.sh if policy based routing is not active. It's already called by updown.sh so now gets executed twice.

This is the intended behaviour. updown.sh and vpnrouting.sh are called on different events:

  fprintf(fp, "up updown.sh\n");
  fprintf(fp, "down updown.sh\n");
  fprintf(fp, "route-up vpnrouting.sh\n");
  fprintf(fp, "route-pre-down vpnrouting.sh\n");

So, that's normal for it to be called twice there, as you might want to do something on either the up event, or the route-up event. The openvpn-event script has the duty of looking at which event type is triggering it, and act accordingly. So, your script must check the content of $script_type, which will determine which of the four events above triggered it. The first call will be on the "up" event, and the second on the "route-up" event.

That's why I called it openvpn-event rather than openvpn-start (or -stop) like the other scripts. This allows a user to act according to any of these events, despite the fact they are configured to these two existing, read-only scripts from the firmware.

 

[john9527]

I'm thinking more about backwards compatibility.....there wasn't that distinction prior to your routing code and if I select the 'All traffic' to be equal to what I had before, I don't expect my existing script to run twice (checking for script types 'up' and 'down'). I removed that call when I backported to my fork for that reason.

 

[RMerlin]

I'm thinking more about backwards compatibility.....there wasn't that distinction prior to your routing code and if I select the 'All traffic' to be equal to what I had before, I don't expect my existing script to run twice (checking for script types 'up' and 'down'). I removed that call when I backported to my fork for that reason.

Then it means if a user needs to do something a route-up event, he will no longer be able to do so, since that event is pre-configured in the generated config file.

You should already have been checking script_type even before this change, otherwise how can you determine if your script is being called on an up or a down event? I can't think of many scenarios where you'd want your script to do the same thing regardless of whether you were calling it on an up or a down event. If you use the script to add or remove a route, for instance, you'd have to know which of the two actions to do.

 

[john9527]

My original script was actually written to check for 'down' or other, and I suspect others may have done the same.....other was always 'up', and worked correctly with the call from updown.sh.

I've since re-written things for myself to account for all possible combination, but I didn't want to break others who took the same approach I originally did.

 

[RMerlin]

My original script was actually written to check for 'down' or other, and I suspect others may have done the same.....other was always 'up', and worked correctly with the call from updown.sh.

I've since re-written things for myself to account for all possible combination, but I didn't want to break others who took the same approach I originally did.

I understand your point, and I agree that breaking existing configurations isn't desirable. However this can be easily resolved by affected users, while there's no simple solution for users who need to specifically apply an action on a route-up event, as they can no longer add "route-up" to the custom config section. So, I went with the lesser evil there.

 

[Deceiver]

Ok, I have tried all this and still no luck. However, I did wake up this morning to find my internet connection not working. Upon further investigation, I found that the VPN connection was responsible for this. I connected to a new server and low and behold, the internet was back up and running. So what I'm trying to understand now is, are the original scripts that I tried to implement not needed or is this "connection drop" a freak occurrence?

 

[Martineau]

Ok, I have tried all this and still no luck. However, I did wake up this morning to find my internet connection not working. Upon further investigation, I found that the VPN connection was responsible for this. I connected to a new server and low and behold, the internet was back up and running. So what I'm trying to understand now is, are the original scripts that I tried to implement not needed or is this "connection drop" a freak occurrence?

For the majority of users, with firmware 378.53, VPN selective routing is now easily managed (simply a couple of clicks) with the appropriate settings on the OpenVPN Client page

i.e. either ALL LAN traffic or redirect selected devices through the VPN.

There is also the option on the GUI to force source devices via the VPN, so if the VPN goes down, then those devices will not 'leak' via the WAN.

So unless you have more complex VPN Client routing requirements then use of additional scripts is no longer a necessary requirement.

 

[Deceiver]

For the majority of users, with firmware 378.53, VPN selective routing is now easily managed (simply a couple of clicks) with the appropriate settings on the OpenVPN Client page

i.e. either ALL LAN traffic or redirect selected devices through the VPN.

There is also the option on the GUI to force source devices via the VPN, so if the VPN goes down, then those devices will not 'leak' via the WAN.

So unless you have more complex VPN Client routing requirements then use of additional scripts is no longer a necessary requirement.

Ok, just so I understand, "Redirect Internet traffic" what is this asking me? Is that the option that you speak of that "forces" clients via the VPN? If so, should it be set to "No" or what?