This is driving me mad! I have two scripts consisting of 21 lines each. When run from winbox or vrrp or scheduler lines 2 and 20 are skipped in one, lines 18 and 20 are skipped in the other. When running the scripts from terminal, they run just fine! Why does this happen?
And to make this even more interesting: I copy/pasted the scripts into the other router. There it runs smoothly on all triggers (vrrp / scheduler / winbox).
So, I case some invisible characters had showed up on the original I deleted the scriptfiles and created new files and copy/pasted the code from the router where it’s running fine to the router where it was originally written… still failing when running in winbox / vrrp / scheduler - and still not failing when running in terminal!
Both routers are RB1100AHx2, ROS upgraded to 5.21.
The one where the script is failing was originally shipped with ROS 5.19. The one where the scripts are working was shipped with ROS 5.9 (I think), and upgraded to 5.11 once received, and upgraded to 5.21 before I started playing with these scripts.
It is considered bad practice to use index numbers i scripts, use some kind of [find=..] instead. But if I understand you correct, then on of the failing lines, in both cases, is the with ipsec, and that doesn’t make sence, apart from reading something about a problem witn a [find] on its own, I don’t recall what, where, or why, but just in case, try [find disabled=no] in the first and [find disabled=yes] in the second.
The ipsec line is totally skipped. It’s not like it executes on some policies and skip other. It’s failing on all of them. Adding disabled=yes/no did not make any difference. Even if I change the line to read
/ip ipsec policy enable 1
it is skipped
And if I add another /ip ipsec policy enable 1 to the end of the script, they are both ignored!
On the router where the scripts runs fine the script has policy write, test, read. On the one where it doesn’t work I started out with the same policy, but when I discovered the issues I added ALL policies, just to be sure that was not of an issue.
So I created a new script looking like this: (just the two failing lines)
/ip address enable 20
/ip ipsec policy enable 1
Both lines are ignored when running from winbox.
And still, when running from terminal it works just as expected.
Edit:
When executing the two-line testscript the following is logged:
echo: system,info address changed by admin
echo: system,info ipsec policy changed by admin
So, the lines aren’t ignored. It’s logged that they do something, but they don’t!
Like psamsig said, don’t use index numbers in scripts. They can and often do change, they are likely disabling something you don’t want, or there is no corresponding index number for them to enable/disable. The only way to reliably use index numbers is in the CLI where you print what is there first, very impractical for a script.
Instead you should be using the find function. It would go something like this:
/ip address enable [find comment="My Comment"]
It would then scan all of the comments of the IP addresses, any any address that had that specific comment, it would take the disable/enable function depending on what you told it to do. You can use almost any configurable attribute to use the find function with as well, and it doesn’t just need to be a comment.
So you think that when I run the script in winbox the index numbers are different from when I run the same script in terminal?
I think the first failing attempt with the use of find proved that the issue here is not related to find.
/ip ipsec policy enable [find]
and
/ip ipsec policy enable [find disabled=no]
With 3 ipsec policies (index 0,1 and 2) at least one of them should respond to the command
/ip ipsec policy enable 1
I don’t care which one is responding. I only goal at this point is to make any of them respond.
I think that using the index number directly is eliminating one possible source of failure. (If find doesn’t return any results, would have been a possible reason for no policies responding.) So at this stage, when debuging, I’m not using find.