Scripting in the context of Netwatch

Josephny · Wed May 07, 2025 3:00 pm

This script is called in Netwatch when DOWN or UP status changes.

I can't figure out why this script fails if I un-comment any of the ":local" variable declarations:

:local myhost $host

/tool netwatch
#:local mystatus [get [find where host=$myhost] status]
#:local mycomment [get [find where host=$myhost] comment]
#:local myinterval [get [find where host=$myhost] interval]
#:local mytimeout [get [find where host=$myhost] timeout]
#:local mypacketinterval [get [find where host=$myhost] packet-interval]
#:local mypacketcount [get [find where host=$myhost] packet-count]
#:local mythrmax [get [find where host=$myhost] thr-max]
#:local mythravg [get [find where host=$myhost] thr-avg]
#:local mythrlosspercent [get [find where host=$myhost] thr-loss-percent]
#:local mythrlosscount [get [find where host=$myhost] thr-loss-count]
#:local mysince [get [find where host=$myhost] since]
#:local mypacketsize [get [find where host=$myhost] packet-size]

:log info "NETWATCH host=$myhost status=$mystatus comment=$mycomment interval=$myinterval timeout=$mytimeout packet-interval=$mypacketinterval packet-count=$mypacketcount thr-avg=$mythravg thr-loss-percent=$mythrlosspercent rttavg=$myrttavg"


:log info "NETWATCH Loss-Percentage=$"loss-percent""
:log info "NETWATCH rtt-avg=$"rtt-avg""
:log info "NETWATCH rtt-avg=$"thr-max""

jaclaz · Wed May 07, 2025 5:15 pm

Is actually

:local myhost $host

working?

or, what happens with:

{
:local myhost $host
:put $myhost
}

Josephny · Wed May 07, 2025 5:54 pm

:local myhost $host

works just fine

"log info $myhost"

creates the correct log entry.

When I uncomment any of the commented :local statements an error is generated.

jaclaz · Wed May 07, 2025 6:04 pm

Can you just post the output of:

{
:local myhost $host
:put $myhost
}

Josephny · Wed May 07, 2025 6:09 pm

Terminal output:

[admin@355hEX] > {
{... :local myhost $host
{... :put $myhost
{... }

[admin@355hEX] >

In the netwatch UP and DOWN entry: No output because, I believe, :put has no where to "put" it

In a script (with nothing else) called by the netwatch UP and DOWN entries: Also, no output.

Josephny · Wed May 07, 2025 6:23 pm

The following as the script called by DOWN and UP in netwatch works fine:

:local myhost $host

:log info $myhost

/tool netwatch
#:local mystatus [get [find where host=$myhost] status]
#:local mycomment [get [find where host=$myhost] comment]
#:local myinterval [get [find where host=$myhost] interval]
#:local mytimeout [get [find where host=$myhost] timeout]
#:local mypacketinterval [get [find where host=$myhost] packet-interval]
#:local mypacketcount [get [find where host=$myhost] packet-count]
#:local mythrmax [get [find where host=$myhost] thr-max]
#:local mythravg [get [find where host=$myhost] thr-avg]
#:local mythrlosspercent [get [find where host=$myhost] thr-loss-percent]
#:local mythrlosscount [get [find where host=$myhost] thr-loss-count]
#:local mysince [get [find where host=$myhost] since]
#:local mypacketsize [get [find where host=$myhost] packet-size]

:log info "NETWATCH host=$myhost status=$mystatus comment=$mycomment interval=$myinterval timeout=$mytimeout packet-interval=$mypacketinterval packet-count=$mypacketcount thr-avg=$mythravg thr-loss-percent=$mythrlosspercent rttavg=$myrttavg"


:log info "NETWATCH Loss-Percentage=$"loss-percent""
:log info "NETWATCH rtt-avg=$"rtt-avg""
:log info "NETWATCH rtt-avg=$"thr-max""

Screenshot 2025-05-07 112259.png

Amm0 · Wed May 07, 2025 6:25 pm

Didn't we already have this discussion about the same script?
See viewtopic.php?t=216444
It's not helpful to start again, since context is lost.

Discussed in that thread is there is no need for :local variables in the first place! When a /system/script is called as action of /tool/netwatch up/down/test script, it will already have all the netwatch variables defined...
so all the :local that just do a find/get are unnecessary.

Also, the /system/script is marked as "Don't Require Permissions", correct?

jaclaz · Wed May 07, 2025 6:33 pm

If there is no output, I would suspect that $myhost is empty/not defined or not found.

Simple test:

{
:local myhost Pippo
:put $myhost
}

and/or:

/tool netwatch 
:local mystatus [get [find where host=] status]

does it give the same or a different error?

Josephny · Wed May 07, 2025 8:24 pm

Didn't we already have this discussion about the same script?
See viewtopic.php?t=216444
It's not helpful to start again, since context is lost.

Discussed in that thread is there is no need for :local variables in the first place! When a /system/script is called as action of /tool/netwatch up/down/test script, it will already have all the netwatch variables defined...
so all the :local that just do a find/get are unnecessary.

Also, the /system/script is marked as "Don't Require Permissions", correct?

It's a different problem.

And, my understanding is that only the rtt-* variables are predefined -- not the thr-* variables. Is that not correct?

Yes, "Don't Require Permissions" is checked.

Josephny · Wed May 07, 2025 8:29 pm

If there is no output, I would suspect that $myhost is empty/not defined or not found.

Simple test:
Code: Select all
{
:local myhost Pippo
:put $myhost
}
and/or:
Code: Select all
/tool netwatch 
:local mystatus [get [find where host=] status]
does it give the same or a different error?

[admin@355hEX] /tool/netwatch> {
{... :local myhost Pippo
{... :put $myhost
{... }
Pippo

And

[admin@355hEX] /tool/netwatch> :local mystatus [get [find where host=] status]
expected host value (line 1 column 39)

jaclaz · Wed May 07, 2025 8:44 pm

So, in the script, if you replace
:local myhost $host
with
:local myhost 8.8.8.8
(or whatever host you are using in the netwatch)
what happens?

Amm0 · Wed May 07, 2025 8:52 pm

Didn't we already have this discussion about the same script?
See viewtopic.php?t=216444
It's a different problem.

Anyway, jaclaz has more patience than I. If we knew what the desired output and preferred scheme, it be easier to help.

And, my understanding is that only the rtt-* variables are predefined -- not the thr-* variables. Is that not correct?

Half true. The thr-* are not passed correct. But the variables passed on mostly right in docs https://help.mikrotik.com/docs/spaces/R ... Fvariables – with only the variable names for the ICMP specific probe statistics not be being corrected.

Josephny · Wed May 07, 2025 10:27 pm

So, in the script, if you replace
:local myhost $host
with
:local myhost 8.8.8.8
(or whatever host you are using in the netwatch)
what happens?

Still blank:

[admin@355hEX] /tool/netwatch> :local myhost 8.8.8.8
[admin@355hEX] /tool/netwatch> :put $myhost

[admin@355hEX] /tool/netwatch>

I tried this on multipl MT devices -- same behavior.

Josephny · Wed May 07, 2025 10:31 pm

It's a different problem.
Anyway, jaclaz has more patience than I. If we knew what the desired output and preferred scheme, it be easier to help.

And, my understanding is that only the rtt-* variables are predefined -- not the thr-* variables. Is that not correct?
Half true. The thr-* are not passed correct. But the variables passed on mostly right in docs https://help.mikrotik.com/docs/spaces/R ... Fvariables – with only the variable names for the ICMP specific probe statistics not be being corrected.

Like a good portion of what I do, it's mostly for learning.

In this case, I want to log the rtt-* values when Netwatch determines a DOWN situation so that I can tweak the thr-* values and come up with an overall combination threshold that works for me.

Larsa · Wed May 07, 2025 10:43 pm

You need to use curly brackets when running commands in the terminal to keep everything in the same "scope":

{
:local myhost 8.8.8.8
:put $myhost
}

Or:

{ :local myhost 8.8.8.8; :put $myhost }

jaclaz · Wed May 07, 2025 10:45 pm

Yep, "in the script" does not mean "in terminal".
Curly brackets are needed (in terminal).

@Amm0
It's not like I have more patience, more simply you are way more experienced and knowledgeable than I am in Mikrotik scripts, so you automatically give for reknown basic things that a beginner needs to learn, and the only way to learn is IMHO to try (and fail, and try again). I am pretty sure that Josephny after this will remember curly brackets and how "local" means "local".

Josephny · Wed May 07, 2025 11:19 pm

You need to use curly brackets when running commands in the terminal to keep everything in the same "scope":
Code: Select all
{
:local myhost 8.8.8.8
:put $myhost
}
Or:
Code: Select all
{ :local myhost 8.8.8.8; :put $myhost }

Now I get it.

Yes, :put output is now "8.8.8.8"

Thank you for your extreme patience and wise teaching skill.

Now back to why the :local commands in the script are causing an error....

jaclaz · Wed May 07, 2025 11:43 pm

I would try seeing what happens changing this:
:local mystatus [get [find where host=$myhost] status]
to:

:local mystatus [get [find where host=8.8.8
8] status]

(8.8.8.8 or whatever host Is your netwatch for)

Amm0 · Thu May 08, 2025 12:45 am

@Amm0
so you automatically give for reknown basic things that a beginner needs to learn

My point is if you understand the problem, you MAY be able to avoid script. If goal is to JUST "tweak a netwatch", then to output current values (rtt- loss- etc) AND configured "threshold", the /system/logging topics=netwatch would do that. Not it's not one line in logs, but so much easier than messing with any scripts.... And, you can add a custom /system/logging/action just for netwatch to keep these netwatch debug items separate from main log. IMO that be a better approach for tweaking. Or if you want to get serious and track them, you can have the script append to file with CSV data to latter review in Excel.

If this is to learn scripting better... repeating the same get [find ...] varname a bunch of times is inefficient. You can do ONE "get" without any attributes, and will return an array with all attributes. So as a learning exercise, it be better to learn arrays, which avoid needing so many locals. And there is a few videos on MiktoTik's YouTube that fill in the blanks on array scripting usage more generally.

Thus you can use ONE local to get all the variables, then use array deconstruction to get particular values as needed (shown for CLI use ... if using in /system/script the outer { } are NOT needed):

{
:local got [/tool/netwatch get [find host=8.8.8.8]]       
:log info "status $($got->"status") stdev $($got->"rtt-stdev") / $($got->"thr-stdev") max $($got->"rtt-max") / $($got->"thr-max") "
}

Amm0 · Thu May 08, 2025 12:52 am

Also, what may be happening... is netwatch will not "get" a threshold value if it is still default value / left unset. (More specifically, the value return of the get will be type "nil", and NOT the default value).

jaclaz · Thu May 08, 2025 11:30 am

I may be old fashioned, but before learning to script better there is IMHO the needed step of learning to script.

As I see it (non-working) scripts should be divided between those that do not work because they are "wrong" (conceptually) and those that do not work just because of some mistake in the (with Mikrotik scripting language quite complex) syntax of the commands used.

Josephny's attempt seems to me largely of the second kind, so, once the syntax issues will be solved, it should work.

Once it will be working, it can surely be optimized/made more efficient, or even replaced by a non-script solution.

Josephny · Thu May 08, 2025 12:16 pm

@Amm0
so you automatically give for reknown basic things that a beginner needs to learn
My point is if you understand the problem, you MAY be able to avoid script. If goal is to JUST "tweak a netwatch", then to output current values (rtt- loss- etc) AND configured "threshold", the /system/logging topics=netwatch would do that. Not it's not one line in logs, but so much easier than messing with any scripts.... And, you can add a custom /system/logging/action just for netwatch to keep these netwatch debug items separate from main log. IMO that be a better approach for tweaking. Or if you want to get serious and track them, you can have the script append to file with CSV data to latter review in Excel.

If this is to learn scripting better... repeating the same get [find ...] varname a bunch of times is inefficient. You can do ONE "get" without any attributes, and will return an array with all attributes. So as a learning exercise, it be better to learn arrays, which avoid needing so many locals. And there is a few videos on MiktoTik's YouTube that fill in the blanks on array scripting usage more generally.

Thus you can use ONE local to get all the variables, then use array deconstruction to get particular values as needed (shown for CLI use ... if using in /system/script the outer { } are NOT needed):
Code: Select all
{
:local got [/tool/netwatch get [find host=8.8.8.8]]       
:log info "status $($got->"status") stdev $($got->"rtt-stdev") / $($got->"thr-stdev") max $($got->"rtt-max") / $($got->"thr-max") "
}

Now I understand why my goal (i.e., the problem I want to solve) is important to specify.

First I tried the following in at the CLI, then without the brackets in Netwatch's ON-DOWN/ON-UP, and various versions including replacing "8.8.8.8" with "192.168.2.2" and could not get it to work -- always an error:

{
:local got [/tool/netwatch get [find host=8.8.8.8]]       
:log info "status $($got->"status") stdev $($got->"rtt-stdev") / $($got->"thr-stdev") max $($got->"rtt-max") / $($got->"thr-max") "
}

I confirmed that 192.168.2.2 is there as a host:

[admin@355hEX] /tool/netwatch> print
Flags: X - DISABLED
Columns: TYPE, HOST, INTERVAL, STATUS, SINCE
 #   TYPE    HOST           INTERVAL  STATUS   SINCE              
;;; Netwatch-8.8.4.4
 0 X simple  8.8.4.4        30s       unknown                     
;;; Netwatch-192.168.20.1
 1 X simple  192.168.20.1   30s       unknown                     
;;; Netwatch-192.168.30.2
 2 X simple  192.168.30.2   20s       unknown                     
;;; Netwatch-192.168.40.1
 3 X icmp    192.168.40.1   30s       unknown                     
;;; Netwatch-192.168.70.1
 4 X simple  192.168.70.1   30s       unknown                     
;;; Netwatch-192.168.20.22
 5 X simple  192.168.20.22  30s       unknown                     
;;; Netwatch-192.168.1.2
 6 X simple  192.168.1.2    30s       unknown                     
;;; Netwatch-1.1.1.1
 7 X simple  1.1.1.1        30s       unknown                     
;;; Netwatch-192.168.0.80
 8 X simple  192.168.0.80   30s       unknown                     
;;; Netwatch-192.168.0.32
 9 X simple  192.168.0.32   30s       unknown                     
;;; Netwatch-192.168.0.31
10 X simple  192.168.0.31   30s       unknown                     
;;; Netwatch-192.168.2.5
11 X simple  192.168.2.5    30s       unknown                     
;;; Netwatch-192.168.2.7
12 X simple  192.168.2.7    30s       unknown                     
;;; Netwatch-192.168.20.5
13 X simple  192.168.20.5   30s       unknown

So I moved on from that failure and I tried the following directly in the ON-DOWN/ON-UP:

:log info "NETWATCH loss-count=$"loss-count""
:log info "NETWATCH loss-Percentage=$"loss-percent""
:log info "NETWATCH rtt-avg=$"rtt-avg""
:log info "NETWATCH thr-avg=$"thr-avg""
:log info "NETWATCH host=$"host""
:log info "NETWATCH comment=$"comment""
:log info "NETWATCH interval=$"interval""
:log info "NETWATCH timeout=$"timeout""

All the results are logged except "thr-avg" -- can't figure out why the value is nil.

Screenshot 2025-05-08 050931.png

And, thr-avg is not set to its default value:

add comment=Netwatch-192.168.2.2-TESTING disabled=no down-script=":log info \"NETWATCH loss-count=\$\"loss-count\"\"\
    \n:log info \"NETWATCH loss-Percentage=\$\"loss-percent\"\"\
    \n:log info \"NETWATCH rtt-avg=\$\"rtt-avg\"\"\
    \n:log info \"NETWATCH thr-avg=\$\"thr-avg\"\"\
    \n:log info \"NETWATCH host=\$\"host\"\"\
    \n:log info \"NETWATCH comment=\$\"comment\"\"\
    \n:log info \"NETWATCH interval=\$\"interval\"\"\
    \n:log info \"NETWATCH timeout=\$\"timeout\"\"" host=192.168.2.2 interval=10s name=Netwatch-192.168.2.2-TESTING packet-count=5 packet-interval=50ms test-script="" thr-avg=50ms thr-loss-percent=20% type=icmp up-script=":log info \"NETWATCH lo\
    ss-count=\$\"loss-count\"\"\
    \n:log info \"NETWATCH loss-Percentage=\$\"loss-percent\"\"\
    \n:log info \"NETWATCH rtt-avg=\$\"rtt-avg\"\"\
    \n:log info \"NETWATCH thr-avg=\$\"thr-avg\"\"\
    \n:log info \"NETWATCH host=\$\"host\"\"\
    \n:log info \"NETWATCH comment=\$\"comment\"\"\
    \n:log info \"NETWATCH interval=\$\"interval\"\"\
    \n:log info \"NETWATCH timeout=\$\"timeout\"\""

FYI, I do like using variables (or an array) so that I can email the results of a DOWN status if I want.

Josephny · Thu May 08, 2025 12:58 pm

I may be old fashioned, but before learning to script better there is IMHO the needed step of learning to script.

As I see it (non-working) scripts should be divided between those that do not work because they are "wrong" (conceptually) and those that do not work just because of some mistake in the (with Mikrotik scripting language quite complex) syntax of the commands used.

Josephny's attempt seems to me largely of the second kind, so, once the syntax issues will be solved, it should work.

Once it will be working, it can surely be optimized/made more efficient, or even replaced by a non-script solution.

A fuddy-duddy, eh?

I like your approach: Baby steps, albeit sometimes in circles, still helps one learn to walk.

Larsa · Thu May 08, 2025 1:44 pm

An alternative solution that doesn’t require scripting is to enable Netwatch logging with "/system logging add prefix=debug topics=netwatch", and then check all the values in the log:

07:39:10 netwatch,debug debug: [ type: icmp, host: 1.1.1.1 ] Stats:
07:39:10 netwatch,debug debug:    [ OK ] rtt-max: 44.740 ms [ <= 1000.000 ms ] 
07:39:10 netwatch,debug debug:    [ OK ] rtt-jitter: 21.856 ms [ <= 1000.000 ms ] 
07:39:10 netwatch,debug debug:    [ OK ] rtt-avg: 30.724 ms [ <= 800.000 ms ] 
07:39:10 netwatch,debug debug:    [ OK ] rtt-stdev: 7.186 ms [ <= 500.000 ms ] 
07:39:10 netwatch,debug debug:    [ OK ] loss count: 0 [ <= 4294967295 ] 
07:39:10 netwatch,debug debug:    [ OK ] loss: 0% [ <= 100.0% ]

Josephny · Thu May 08, 2025 1:53 pm

An alternative solution that doesn’t require scripting is to enable Netwatch logging with "/system logging add prefix=debug topics=netwatch", and then check all the values in the log:

07:39:10 netwatch,debug debug: [ type: icmp, host: 1.1.1.1 ] Stats:
07:39:10 netwatch,debug debug:    [ OK ] rtt-max: 44.740 ms [ <= 1000.000 ms ] 
07:39:10 netwatch,debug debug:    [ OK ] rtt-jitter: 21.856 ms [ <= 1000.000 ms ] 
07:39:10 netwatch,debug debug:    [ OK ] rtt-avg: 30.724 ms [ <= 800.000 ms ] 
07:39:10 netwatch,debug debug:    [ OK ] rtt-stdev: 7.186 ms [ <= 500.000 ms ] 
07:39:10 netwatch,debug debug:    [ OK ] loss count: 0 [ <= 4294967295 ] 
07:39:10 netwatch,debug debug:    [ OK ] loss: 0% [ <= 100.0% ]

Yes, I have been playing with this. It's great in it's simplicity to set up.

But, it is helpful (for my limited time to focus) to be able to see something that calls out to me the following:

"Hey Joe, I detected a DOWN connection to host aaaa at <date/time> because the rtt-avg was xxx ms and the loss% was yy%. These values exceed the thresholds in place of thr-avg of qqq ms and thr-loss% of yy%. Connection was restored (back UP) at <date/time>. Love, Mikrotik's Netwatch facility running on device with IP ddd.eee.fff.ggg"

rextended · Thu May 08, 2025 2:12 pm

Please provide an appropriate title, the current one IS WRONG and ONLY creates CONFUSION.

First of all it is wrong to refer to netwatch in this way "/tool/netwatch get [find host=8.8.8.8]" because there can be more than 1 netwatch with the same IP 8.8.8.8,

second, thr-avg is a property, and not a result, so you can't read it by simply putting $"thr-avg" in the script, but you have to get it as a property of the netwatch.

Josephny · Thu May 08, 2025 2:31 pm

delete please

Josephny · Thu May 08, 2025 2:36 pm

Please provide an appropriate title, the current one IS WRONG and ONLY creates CONFUSION.

First of all it is wrong to refer to netwatch in this way "/tool/netwatch get [find host=8.8.8.8]" because there can be more than 1 netwatch with the same IP 8.8.8.8,

second, thr-avg is a property, and not a result, so you can't read it by simply putting $"thr-avg" in the script, but you have to get it as a property of the netwatch.

I don't see a way to change the original subject, but I will change it for this reply.

What would be the correct way to use "/tool/netwatch get [find host=xxx]"?

Maybe assign a variable:

:local myhost $host
/tool/netwatch get [find host=$myhost]

As for the property thr-avg: How do you "get" it?

Thanks.

jaclaz · Thu May 08, 2025 3:03 pm

I thought that by this time we had established that the thing that surely doesn't work is

:local myhost $host

rextended BTW just explained that host is anyway not a good selector as there could be more than one netwatch instances aimed to a same host.

Since netwatch has a "name" property, as long as this name is unique seems like a better selector. (and it can be combined with host if needed).

I don't see a way to change the original subject, but I will change it for this reply.

If you edit the first post, top left there is a text box that is the title of the thread.

rextended · Thu May 08, 2025 3:22 pm

also the name can be omitted (...) or can be duplicated.

This is how to read properties and runtime results:

example from 7.16.2 code

/tool netwatch
:local lhost          [:toip $host]
:local lstatus        $status
:local lsince         $since
:local ldonetests     $"done-tests"
:local lfailedtests   $"failed-tests"
:local lsentcount     $"sent-count"
:local lresponsecount $"response-count"
:local llosscount     $"loss-count"
:local llosspercent   $"loss-percent"
:local lrttavg        $"rtt-avg"
:local lrttmin        $"rtt-min"
:local lrttmax        $"rtt-max"
:local lrttjitter     $"rtt-jitter"
:local lrttstdev      $"rtt-stdev"

:local netwatchID ([find where host=$lhost and type=icmp]->0)

:log info "netwatch ID is >$netwatchID<"

:log info "netwatch *host is >$[get $netwatchID host]< and type is >$[get $netwatchID type]<"
:log info "netwatch *status is >$[get $netwatchID status]<"

:log info "netwatch comment is >$[                          get $netwatchID comment                  ]<"
:log info "netwatch interval (10s) is >$[                   get $netwatchID interval                 ]<"
:log info "netwatch timeout (3s) is >$[                     get $netwatchID timeout                  ]<"
:log info "netwatch start-delay (3s) is >$[                 get $netwatchID start-delay              ]<"
:log info "netwatch startup-delay (5m) is >$[               get $netwatchID startup-delay            ]<"
:log info "netwatch packet-interval (50ms) is >$[           get $netwatchID packet-interval          ]<"
:log info "netwatch packet-count (10) is >$[                get $netwatchID packet-count             ]<"
:log info "netwatch packet-size (54) is >$[                 get $netwatchID packet-size              ]<"
:log info "netwatch thr-max (1s) is >$[                     get $netwatchID thr-max                  ]<"
:log info "netwatch thr-avg (100ms) is >$[                  get $netwatchID thr-avg                  ]<"
:log info "netwatch thr-stdev (250ms) is >$[                get $netwatchID thr-stdev                ]<"
:log info "netwatch thr-jitter (1s) is >$[                  get $netwatchID thr-jitter               ]<"
:log info "netwatch thr-loss-percent (85%) is >$[           get $netwatchID thr-loss-percent         ]<"
:log info "netwatch thr-loss-count (4294967295) is >$[      get $netwatchID thr-loss-count           ]<"
:log info "netwatch ttl (255) is >$[                        get $netwatchID ttl                      ]<"
:log info "netwatch accept-icmp-time-exceeded (false) is >$[get $netwatchID accept-icmp-time-exceeded]<"
:log info "netwatch disabled (false) is >$[                 get $netwatchID disabled                 ]<"

:log info "runtime *host is >$lhost<"
:log info "runtime *status is >$lstatus<"
:log info "runtime since is >$lsince<"
:log info "runtime done-tests is >$ldonetests<"
:log info "runtime failed-tests is >$lfailedtests<"
:log info "runtime sent-count is >$lsentcount<"
:log info "runtime response-count is >$lresponsecount<"
:log info "runtime loss-count is >$llosscount<"
:log info "runtime loss-percent is >$llosspercent</10 %"
:log info "runtime rtt-avg is >$lrttavg< us (=4294967295 on down)"
:log info "runtime rtt-min is >$lrttmin< us (=4294967295 on down)"
:log info "runtime rtt-max is >$lrttmax< us (=4294967295 on down)"
:log info "runtime rtt-jitter is >$lrttjitter< us (=4294967295 on down)"
:log info "runtime rtt-stdev is >$lrttstdev< us (=4294967295 on down)"

If the values on netwatch are undefined, they return something like netwatch packet-count (10) is ><
If are defined return netwatch packet-count (10) is >10<

I use this (removed scripts for readability)

test icmp netwatch with default netwatch values code

/tool netwatch
add accept-icmp-time-exceeded=no disabled=no down-script="[...]" host=1.1.1.1 interval=10s packet-count=10 packet-interval=50ms packet-size=54 \
    start-delay=3s startup-delay=5m test-script="[...]" thr-avg=100ms thr-jitter=1s thr-loss-count=4294967295 thr-loss-percent=85% thr-max=1s \
    thr-stdev=250ms timeout=3s ttl=255 type=icmp up-script="[...]"

Josephny · Thu May 08, 2025 3:59 pm

Now that's a sexy script!

Josephny · Thu May 08, 2025 11:25 pm

I added this to your script:

:local thisBox [/system identity get name]

:log info "Netwatch at $thisBox detected a $lstatus condition to host $lhost.  The rtt-avg was $lrttavg and the loss-percent was $llosspercent.  These value exceed at least 1 of the thresholds of thr-avg of $[get $netwatchID thr-avg] and the threshold loss-percent of $[get $netwatchID thr-loss-percent]."

FYI, thr-loss-percent reports a value ten times the actual set value. That is, Netwatch has a value of 80% and the log shows:

Netwatch at 355hEX detected a up condition to host 192.168.2.2.  The rtt-avg was 24516 and the loss-percent was 0.  These value exceed at least 1 of the thresholds of thr-avg of 00:00:01 and the threshold loss-percent of 800.

And, the rtt-avg of 24516 actually means 24.516ms.

jaclaz · Thu May 08, 2025 11:57 pm

And, the rtt-avg of 24516 actually means 24.516ms.

Hmmm.

That would imply that inside the router there Is a clock (or some other high precision technology marvel ) capable of 1 millionth second (microsecond) resolution.

Josephny · Fri May 09, 2025 12:13 am

And, the rtt-avg of 24516 actually means 24.516ms.
Hmmm.
That would imply that inside the router there Is a clock (or some other high precision technology marvel ) capable of 1 millionth second (microsecond) resolution.

I can't say I know anything about this, but my conclusion was far less flattering: I figured the coding and/or calculations in ROS is erroneous or misleading.

The Status section of Netwatch shows the rtt-avg in milliseconds through 3 decimal places (e.g., 24.516), so it's reporting to the 1/1000000 of a second -- but I have no idea if it's real.

jaclaz · Fri May 09, 2025 12:51 am

Since It Is an average, it is possible that for *some reason* they are using 1/1000 precision in the math operations used to calculate this average, but it makes little sense, since the corresponding thr-avg is set in "whole" milliseconds.

Curiosity of the day:
The netwatch help page has been changed/edited yesterday, and while the rtt- vs. thr- mistake Is still there the rtt-min (that was thr-min) I listed just a few days ago has vanished from icmp probes/results:
viewtopic.php?p=1141361#p1141361

EDIT: corrected wrong statement, see below posts

Amm0 · Fri May 09, 2025 1:04 am

Curiosity of the day:
The netwatch help page has been changed/edited yesterday,

I filed a report about the docs. MT fixed the description of the thr- params...but yeah they forgot the ICMP probe stats (which have been wrong for a while). It's still open.

jaclaz · Fri May 09, 2025 1:30 am

The curiosity Is not that the page has been edited, It Is that an item has been removed from the list/table, while keeping the other parameters with the wrong names.
It Is not like they did not touch that list/table (as if they had forgotten it).
I seem to remember you had some ways to link to the history of the changes on a Mikrotik help page, I would be curious to check what (the heck) was changed.

EDIT: corrected wrong statement

Amm0 · Fri May 09, 2025 1:48 am

The "sandwich" in upper-right "..." has a "Page History" for any page in help.mikrotik.com. Diff can be seen there:
https://help.mikrotik.com/docs/pages/vi ... Id=8323208

jaclaz · Fri May 09, 2025 1:55 am

Ah, ok thanks.
Then it Is my fault, the rtt-min (wrong thr-min) wasn't there, I must have derived It from your status screenshot and the discussione about those parameters.

Josephny · Fri May 09, 2025 1:42 pm

At 00:30 today the netwatched host went down.

The rtt-avg was 4294967295 (choose whatever unit you prefer) and the packet loss was 1000% -- that's a lot of DOWN!

Netwatch at 355hEX detected a down condition to host 192.168.2.2.  The rtt-avg was 4294967295 and the loss-percent was 1000.  These value exceed at least 1 of the thresholds of thr-avg of 00:00:00.400 and the threshold loss-percent of 900.

rextended · Fri May 09, 2025 2:47 pm

FYI, thr-loss-percent reports a value ten times the actual set value. That is, Netwatch has a value of 80% and the log shows:

You do not read???

:log info "runtime loss-percent is >$llosspercent</10 %"

$llosspercent/10 %

And, the rtt-avg of 24516 actually means 24.516ms.

The same:

:log info "runtime rtt-avg is >$lrttavg< us (=4294967295 on down)"

us (correct is µs)

The rtt-avg was 4294967295 (choose whatever unit you prefer) and the packet loss was 1000% -- that's a lot of DOWN!

the unit is microseconds us (correct is µs), from previous quote... (=4294967295 on down) and $llosspercent/10 %

4294967295 = 0xFFFFFFFF is the classic RouterOS programers error... must be -1 as DWORD, not 4294967295 as QWORD
(the same for timezone offset fixed some versions ago).

Josephny · Fri May 09, 2025 5:24 pm

I did read and did try, with and without the "<" and ">" symbols and it doesn't work.

:log info "runtime loss-percent is >$llosspercent</10 %"
:log info "runtime rtt-avg is >$lrttavg< us (=4294967295 on down)"

runtime loss-percent is >0</10 %
runtime rtt-avg is >21565< us (=4294967295 on down)

Would be nice to convert 21565us to ms. I tried by including a "/1000" but that didn't work.

rextended · Fri May 09, 2025 7:36 pm

That's just text describing what that value is, it's not operations...

>< is used to identify where the value should be written, it's just text...

example conversion code

:log info "runtime loss-percent is >$($llosspercent/10)< %"
:log info "runtime rtt-avg is >$lrttavg< us >$($lrttavg/1000)< ms"

It is not worth counting microseconds by putting the full stop and the rest.
add ($lrttavg % 1000) as string after "00" and take the last 3 characters on the left.

!!!EXAMPLES BELOW ON PSEUDOCODE!!!!

for example 21565us
21565 / 1000 = 21 (for RouterOS)
21565 % 1000 = 565
21 + "." + 565 = 21.565ms

but if is 21065...
21065 / 1000 = 21 (for RouterOS)
21065 % 1000 = 65
21 + "." + 65 = 21.65ms is wrong, must be 21.065,
so, for add the "0" (or "00" if the result is 9 or less or "000" if the result is 0), add "00" to 65 as string and you obtain 0065
take the last 3 characters with len/pick and you obtain 065,
so, 21 + "." + "065" = 21.065ms the correct value.

but if is 21005...
21005 / 1000 = 21 (for RouterOS)
21005 % 1000 = 5 (like previous, add 00 "005" and take last 3 charactes)
21 + "." + "005" = 21.005ms the correct value.

but if is 21000...
21000 / 1000 = 21 (for RouterOS)
21000 % 1000 = 0 (like previous, add 00 "000" and take last 3 charactes)
21 + "." + "000" = 21.000ms the correct value.

You can also count the length of the number converted to string and add as many 0s as string before the number to align the values.
value = 5
value = tostring(value)
# and now value is "5"
if len of "5" is < 3 add a "0" on the right;
if len of "05" is < 3 add a "0" on the right;

or

value = 5
value = tostring(value)
# and now value is "5"
if len of "5" is = 1 add a "00" on the right;
if len of "5" is = 2 add a "0" on the right;

or

value = 5
value = tostring(value)
# and now value is "5"
while (len value < 3) do add a "0" on the right;

or

......................

EDIT: fixed typos, thanks @jaclaz

Josephny · Sat May 10, 2025 2:18 am

So these variables hold text, right?

$llosspercent
$lrttavg

But, the following show the results in whole ms:

:local roundrttavg ($lrttavg / 1000)
:log info $roundrttavg

Does adding " / 1000" simply drop the last 3 characters of the text value of $lrttavg?

And getting the results in ms to 2 decimal places seems like a genuine PITA.

jaclaz · Sat May 10, 2025 11:15 am

If you do a math operation in RoS, you are using integer math.
The result is the same as you would use INT in a spreadsheet.
Or the same (with other limits) as you can have in Windows command line/batch.

The examples rextended posted (set apart some little typos with 21565 that is not changed in a few lines) show you the use of plain division and of the modulus operator.

In Windows, open a command prompt and type in it:
set /a 21065/21
[ENTER]
21
set /a 21065%1000
[ENTER]
65

So:
set /a integer=21065/1000
set /a decimals=21065%1000
::from now on integer and decimals will be treated as text/string
::prepend 2 zeroes
set decimals=00%decimals%
::get last 3 characters
set decimals=%decimals:~-3%
echo %integer%.%decimals%

Josephny · Sun May 11, 2025 2:07 pm

I'm blown away at the level of expertise on this forum. And, somehow, even more in awe of the generousity shown while sharing all of your expertise.

FYI, I am grateful that you are providing an irresistable temptation to exercise this tired old brain.

Please let me know if I have this correctly:

ROS' "predefined" variables, such as those used by Netwatch (e.g., rtt-avg and loss-percent), are of type integer.

Therefore (for example) when rtt-avg reports its results in us, in order to convert it, we need to do the following:

1) Create a text-type variable that includes only the whole-integrer portion of rtt-avg by dividing rtt-avg by 1000, named "integer"

2) Create a text-type variable that contains the the decimal portion (999 or fewer us in rtt-avg) by using the % operation (which provides the remainder of division when using only integers, hence 21065%1000 results in 065), named "decimal"

3) Prepend 2 zeros to "decimal" in case the original rtt-avg has a zero in one of it's places (as it does in the example of 21065).

4) Delete all but the last 3 characters of "decimal" so that the remaining 3 characters can be used to represent the digits to the right of the decimal point in the ms version of rtt-avg

5) Concatenate the whole unit variable ("integer") and the 3 character variable ("decimal") to form the rtt-avg shown is xx.xxx ms

jaclaz · Sun May 11, 2025 3:33 pm

Yep, almost all correct

, to be picky you forgot here the deciimal separator (dot if we use the English notation):

5) Concatenate the whole unit variable ("integer"), the decimal separator and the 3 character variable ("decimal") to form the rtt-avg shown is xx.xxx ms

but this is IMHO needlessly limited/restricted:

ROS' "predefined" variables, such as those used by Netwatch (e.g., rtt-avg and loss-percent), are of type integer.

I would state that in RoS ANY numeric variable can ONLY be of type "integer" (more specifically 64 bit signed)

See here:
https://help.mikrotik.com/docs/spaces/R ... /Scripting

Data types

RouterOS scripting language has the following data types:
Type		Description
num (number)	- 64bit signed integer, possible hexadecimal input;
...

In this it rather similar to the DOS/Windows command line/batch environment (there the integers are signed 32 bit, though, so the max value is 7FFFFFFF or 2,147,483,647).

In RoS being 64 bit signed it should be 7FFFFFFFFFFFFFFFFF or 9,223,372,036,854,775,807 BUT the max accepted value in most places/settings is actually FFFFFFFF or 4,294,967,295 which is the max possible value for unsigned 32 bit numbers (go figure

).

rextended · Mon May 12, 2025 10:15 am

academically that's one thing,
but in practice, just ignore microseconds and use milliseconds...
so a /1000 suffice...

instead if it were, for example, the voltage "2357",
there is a big difference between writing 23V and 23.57V

jaclaz · Mon May 12, 2025 11:12 am

Just thinking aloud, but the "risk" (in a lmited number of cases) is that one might not be able to easily find the culprit of a "down" if caused by these "-avg" or -stdev" thresholds.

I mean, let's say that the thr-avg is left as default to 100 ms. <- so this setting has milliseconds resolution
If the corresponding rtt-avg has instead microseconds resolution, and you have (still the default) 10 pings with values:
100000
100001
100002
100003
100004
100005
100006
100007
100008
100009
the rtt-avg should come out as (in floating point) 100004.500, that should be rounded to 100005.

If you only divide by 1000 results up to 100999 will come out as 100.

So you might have a script line printing the equivalent of:
Netwatch had a down event because the rtt-avg of 100ms exceeded the set thr-avg of 100ms
or if you prefer:
100>100

An alternative could be, instead of dividing rtt-avg us by 1000, to multiply thr-avg us by 1000.

The result would be:
Netwatch had a down event because the rtt-avg of 100005us exceeded the set thr-avg of 100000us
or if you prefer:
100005>100000

Still it feels wrong that a threshold uses a different unit of measure from the test result.

Josephny · Mon May 12, 2025 1:32 pm

Imperfections abound....

I'm still working on getting something more useful.

The script now produces:

Netwatch at 355hEX detected a up condition to host 192.168.2.2.  The rtt-avg was 22 ms and the loss-percent was 0 %.  These value exceed at least 1 of the thresholds of thr-avg of 00:00:00.400 and the threshold loss-percent of 900

So, I still have the following problems (if only these were my only problems):

1) Space between 22 and ms
2) Space between 0 and %
3) thr-avg shows hours:minutes:second:ms -- nicer if it read only ms
4) thr-loss-percentage for 900 instead of 90

I played around "/10," parenthesis, quotes, defining more variable and came up with zilch.

Here's the script:

:local thisBox [/system identity get name]
/tool netwatch
:local lhost          [:toip $host]
:local lstatus        $status
:local lsince         $since
:local ldonetests     $"done-tests"
:local lfailedtests   $"failed-tests"
:local lsentcount     $"sent-count"
:local lresponsecount $"response-count"
:local llosscount     $"loss-count"
:local llosspercent   $"loss-percent"
:local lrttavg        $"rtt-avg"
:local lrttmin        $"rtt-min"
:local lrttmax        $"rtt-max"
:local lrttjitter     $"rtt-jitter"
:local lrttstdev      $"rtt-stdev"
#:local thrlosspercent $[get $netwatchID thr-loss-percent]
#:local correctedthrlosspercent $thrlosspercent/10

:local netwatchID ([find where host=$lhost and type=icmp]->0)

#:log info "netwatch ID is >$netwatchID<"

#:log info "netwatch *host is >$[get $netwatchID host]< and type is >$[get $netwatchID type]<"
#:log info "netwatch *status is >$[get $netwatchID status]<"

#:log info "netwatch comment is >$[                          get $netwatchID comment                  ]<"
#:log info "netwatch interval (10s) is >$[                   get $netwatchID interval                 ]<"
#:log info "netwatch timeout (3s) is >$[                     get $netwatchID timeout                  ]<"
#:log info "netwatch start-delay (3s) is >$[                 get $netwatchID start-delay              ]<"
#:log info "netwatch startup-delay (5m) is >$[               get $netwatchID startup-delay            ]<"
#:log info "netwatch packet-interval (50ms) is >$[           get $netwatchID packet-interval          ]<"
#:log info "netwatch packet-count (10) is >$[                get $netwatchID packet-count             ]<"
#:log info "netwatch packet-size (54) is >$[                 get $netwatchID packet-size              ]<"
#:log info "netwatch thr-max (1s) is >$[                     get $netwatchID thr-max                  ]<"
#:log info "netwatch thr-avg (100ms) is >$[                  get $netwatchID thr-avg                  ]<"
#:log info "netwatch thr-stdev (250ms) is >$[                get $netwatchID thr-stdev                ]<"
#:log info "netwatch thr-jitter (1s) is >$[                  get $netwatchID thr-jitter               ]<"
#:log info "netwatch thr-loss-percent (85%) is >$[           get $netwatchID thr-loss-percent         ]<"
#:log info "netwatch thr-loss-count (4294967295) is >$[      get $netwatchID thr-loss-count           ]<"
#:log info "netwatch ttl (255) is >$[                        get $netwatchID ttl                      ]<"
#:log info "netwatch accept-icmp-time-exceeded (false) is >$[get $netwatchID accept-icmp-time-exceeded]<"
#:log info "netwatch disabled (false) is >$[                 get $netwatchID disabled                 ]<"

#:log info "runtime *host is >$lhost<"
#:log info "runtime *status is >$lstatus<"
#:log info "runtime since is >$lsince<"
#:log info "runtime done-tests is >$ldonetests<"
#:log info "runtime failed-tests is >$lfailedtests<"
#:log info "runtime sent-count is >$lsentcount<"
#:log info "runtime response-count is >$lresponsecount<"
#:log info "runtime loss-count is >$llosscount<"
#:log info "runtime loss-percent is >$llosspercent<"
#:log info "runtime rtt-avg is >$lrttavg< us (=4294967295 on down)"
#:log info "runtime rtt-min is >$lrttmin< us (=4294967295 on down)"
#:log info "runtime rtt-max is >$lrttmax< us (=4294967295 on down)"
#:log info "runtime rtt-jitter is >$lrttjitter< us (=4294967295 on down)"
#:log info "runtime rtt-stdev is >$lrttstdev< us (=4294967295 on down)"

:local roundrttavg ($lrttavg / 1000)
:local correctedlosspercent ($llosspercent / 10)

#:log info "correctedthrlosspercent $correctedthrlosspercent"
:log info "loss-count $"loss-count""
:log info "rttavg $lrttavg"
:log info "loss-percent $"loss-percent""
:log info "losspercent $llosspercent"
:log info "correctedlosspercet $correctedlosspercent"

:log info "Netwatch at $thisBox detected a $lstatus condition to host $lhost.  The rtt-avg was $roundrttavg ms and the loss-percent was $correctedlosspercent %.  These value exceed at least 1 of the thresholds of thr-avg of $[get $netwatchID thr-avg] and the threshold loss-percent of $[get $netwatchID thr-loss-percent]"


#:local roundrttavg ($lrttavg / 1000)
#:log info $roundrttavg
#:local shortroundrttavg ($rttavg %1000)
#:log info $shortroundrttavg

rextended · Mon May 12, 2025 3:04 pm

easy for some problems:
was $roundrttavg ms
->
was $"roundrttavg"ms

Josephny · Mon May 12, 2025 3:13 pm

easy for some problems:
was $roundrttavg ms
->
was $"roundrttavg"ms

Genius:

Netwatch at 355hEX detected a up condition to host 192.168.2.2.  The rtt-avg was 23ms and the loss-percent was 0%.  These value exceed at least 1 of the thresholds of thr-avg of 00:00:00.400 and the threshold loss-percent of 900

rextended · Mon May 12, 2025 3:14 pm

or better for fix all, not only spaces....

example for you code

/tool netwatch
:local thisBox      [/system identity get name]
:local lhost        [:toip $host]
:local lstatus             $status
:local llosspercent      ($"loss-percent" /   10)
:local lrttavg           ($"rtt-avg"      / 1000)
:local netwatchID   ([find where host=$lhost and type=icmp]->0)
:local nthravg      [:tonum ([get $netwatchID thr-avg         ] * 1000)]
:local nthrlosspcnt         ([get $netwatchID thr-loss-percent] /   10)

:log info "Netwatch at $thisBox detected a $lstatus condition to host $lhost. \
           The rtt-avg was $"lrttavg"ms and the loss-percent was $llosspercent%. \
           These value exceed at least 1 of the thresholds of thr-avg of $"nthravg"ms and the threshold loss-percent of $nthrlosspcnt%"

On log:

Netwatch at 355hEX detected a up condition to host 192.168.2.2. The rtt-avg was 23ms and the loss-percent was 0%. These value exceed at least 1 of the thresholds of thr-avg of 400ms and the threshold loss-percent of 90%

rextended · Mon May 12, 2025 3:29 pm

If you do not notice, the previous post is all what you need for write that line on logs.

rextended · Mon May 12, 2025 3:35 pm

Just thinking aloud, but the "risk" [...]

right...

in pseudocode, just one example

if (x % 1000) > 0 then add +1 to the result.

on that way 00000 is 0, 100000 is 100 and all numbers between 000001 and 099999 are inside 001..100 but 100001 is 101

And the line "Netwatch had a down event because the rtt-avg of 100ms exceeded the set thr-avg of 100ms" is not possible anymore.

jaclaz · Mon May 12, 2025 4:01 pm

Typo?

:local lrttavg ($"rtt-avg" / 100)

:

should be:

:local lrttavg ($"rtt-avg" / 1000)

rextended · Mon May 12, 2025 4:14 pm

yes, thanks, fixed previous post

:local lrttavg           ($"rtt-avg"      / 1000)

# or with approx fix:
:local lrttavg           ($"rtt-avg"      / 1000)
:if (($"rtt-avg" % 1000) > 0) do={ :set lrttavg ($lrttavg + 1) }

Josephny · Mon May 12, 2025 10:52 pm

That is great.

I could swear I tried the syntax of quoted variable name followed by the slash (divided by) and then "10" and it "didn't work for me." I quote "didn't work for me" because I know full well that that phrase means that I did something wrong.

I added an email notice and that works also.


/tool netwatch
:local thisBox      [/system identity get name]
:local lhost        [:toip $host]
:local lstatus             $status
:local llosspercent      ($"loss-percent" /   10)

:local lrttavg           ($"rtt-avg"      / 1000)
:if (($"rtt-avg" % 1000) > 0) do={ :set lrttavg ($lrttavg + 1) }

:local netwatchID   ([find where host=$lhost and type=icmp]->0)
:local nthravg      [:tonum ([get $netwatchID thr-avg         ] * 1000)]
:local nthrlosspcnt         ([get $netwatchID thr-loss-percent] /   10)

:log info "Netwatch at $thisBox detected a $lstatus condition to host $lhost. \
           The rtt-avg was $"lrttavg"ms and the loss-percent was $llosspercent%. \
           These value exceed at least 1 of the thresholds of thr-avg of $"nthravg"ms and the threshold loss-percent of $nthrlosspcnt%"

:tool e-mail send to=<user>@<domain>.com subject="$thisBox $lstatus to $lhost" body=( [ :system clock get date ] . " " . [ :system clock get time ] . "  " . "$thisBox $lstatus to $lhost with rtt-avg of $lrttavg and loss-percent of $llosspercent%" )

Thank you guys for this lively and helpful thread.