Feature request: Scripting language improvement

RouterOS General
1

RouterOS actualy provides a usefull scripting feature but the scripting language it’s really limited.

It allows you to access and modify all RouterOS features but there are only a few data types, even less functions to manipulate these data types, only basic commands/functions are available, limited loop control, no error or exception handling, etc. Looking throught the forums you’ll see that, for example, a simple task like comparing two date values or covert an string to uppercase need complex solutions where in most modern languages are simple opertations.

I know there was an attempt on version 4 to integrate LUA scripting to RouterOS but it was discarted. LUA seems a good option for embedded scripting, but is not the only posibility. It would be good to have a full featured language on RouterOS, say LUA, PERL or Python, even the good old fashioned BASIC would be an improvement. We really wouldn’t need a full stack language, but even a limited version of any of these languages with access to RouterOS features should provide an unlimited set of posibilities for our devices.

Going a little further, actually only a few features on RouterOS allow to launch an script: scheduler, netwatch, … . But suppose we had a full event trap feature. For example, on interface down launch script xxx, or on vpn tunnel stablished/lost do yyy.

I know it’s a complex request but it would provide a very powerful feature to a product that already is a great solution.

Thanks

2

+1 fully agreed.

3

On if-up, if-down events scripts execute must have

4

+1

5

And not only after up/down… more importantly execute script after DHCP Client get address

6

When I talk about a full event trap system I mean any kind of event that occurs on a RouterOS. Whatever: a wifi client is registered/disconnected then launch an event, a dhcp lease is asigned/finished then launch another event. Think about as if it worked just like the log, something happens then there’s a log entry. Well, instead of a log entry you would associate an event to a script, when the event occurs then the script is called.

7

+1


But (maybe) we need a more powerfull cpu for execute every script when an event occurs like connection/desconnection a wireless cpe or any other event what occurs constatly




sent from my mobile phone using tapatalk

8

+1

But (maybe) we need a more powerfull cpu for execute every script when an event occurs like connection/desconnection a wireless cpe or any other event what occurs constatly

Well, you don’t use an RB750 to manage thousands of users, lots of firewall rules and many queues. You buy or setup a RouterOS system according to your needs. If you would need to manage complex scripts for a very frequent event you should get a powerfull device. If it’s an event that ocurrs once on a relative long time maybe the little RB750 is enough.

If the option of trapping events was there you would dimension you device according to your needs. That’s what I like from Mikrotik, from the smallest device up to the most powerfull, all of them have the same system features. The difference only exists in the used hardware and the supported workload (hardware capacity+license level)

9

Something else I found missing yesterday in Mikrotik scripting… File operations: copy, append, move, rename, etc…

10

This was requested for years.

Event/trigger feature was promised for version 4 or 5 I think, but we never got it.

11

We also find inability to trigger commands/scripts based on events to be very limiting, especially in MPLS VPN deployment.

The following is necessary:

  1. Ability to specify commands/scripts to execute inside RADIUS reply
  2. Mechanism tro trigger a script for every new log line (so there is no need to use a hack with scheduler executing a script every N seconds)
12

+1 kudos for this!

13

definitely agree with this. Could also have multi threaded scripts and not have all scripts run on the same core. Also would be good if scripts are compiled after creation/editing to make it run faster.

14

+1 for LUA =)

15

At least, make the ability to parse any size of text files (by removing 4k limitation or reading by chunks).
Or make /tool fetch to output into array of lines.
Fix this bug.
Or if you don’t want to fix any the above, make LUA available!

16

Error handling in scripts would also be a good start.
In current implementations, a command error will exit the script up to the console, even if scripts are nested.

17

You can catch those errors
http://wiki.mikrotik.com/wiki/Manual:Scripting#Catch_run-time_errors

18

You can catch those errors
http://wiki.mikrotik.com/wiki/Manual:Scripting#Catch_run-time_errors[/quote]

Tnx. I missed that one…

19

I’m going to add to this my personal want:
Ability to read more than 4096 bytes from a file.
I understand the content property of a file is a string, and that’s where the limitation comes from. Perhaps it just needs a binarycontent property that’s a byte. That could underpin the capacity to read a file line by line. Depends on a lot of things - it may be that we actually get that functionality by having a read mechanism that has a Start position, and then either a Length or an “until” byte. e.g. (and this is pseudocode, not mikrotik code)

while(eof = false)
{
	int fromPosition = currentPosition + 1
	string nextline = readbytes(fromPosition, '\r')
}