Would it be possible to enable all common parameters to Netwatch like it is possible to set for ping?

At least:
-interface
-TTL

Hope it is not complicated so it could be earlier than in v.7. Thank you.

Hi everyone, I am woundering the same as jarda,

Will future RoS installments enable netwatch to have a function for interface specific monitoring?

Here is my problem:

I am using a bandwidth based fail over so if something happened to WAN2 and the script sees that WAN1 is saturated and starts sending data to that WAN2 the client would start to get timeouts.

Thanks in advance...

Is this on some to-do list or was it rejected?

And even it was requested several times before I asked for it:
http://forum.mikrotik.com/viewtopic.php?f=2&t=68358
http://forum.mikrotik.com/viewtopic.php?f=2&t=32358
http://forum.mikrotik.com/viewtopic.php?f=1&t=40075
http://forum.mikrotik.com/viewtopic.php?f=1&t=11010
and others.

There are still newer and newer requests for the same angain and again.

Mikrotik, do you hear us? What have you done during those years of requesting this functionality that does not seem to be so hard to implement?

I am starting to wonder the same.

Bump.

Fully featured ping-like Netwatch would be very nice.
For example:

• src-interface
• src-address
• routing-table

Quite tired of having to make a static route just to specify a source IP address.

if this is really the place of requests, then bring 'em on - i guess at least this could be in par with the "regular" ping command

- packet size (in bytes)
- df-bit-set
- log (log the "comment" and the state change (down,up))

yes, i know, one can just poke in a one-liner to log the outcome as down/up-script, but do we really need to do this manually?
btw, when we are there with scripts, it would be handy to know on which entry points which environment values are exposed to the user.
i kinda could think of "comment" and "host". or if i let my mind fly away, then i'll add "number-of-probes", so netwatch would send X consecutive ICMP echo requests, then report back the success rate or successfully received replies, and one could specify a "threshold" value to judge whether the target is reachable or not. and in this case the script could receive "probes_sent" and "probes_received"

even the current operation could be mapped to this: number-of-probes=1 threshold=1

and there we almost have cisco's RTR/SAA

I agree with the threshold parameter requirement, it is often not good to declare something down because of 1 missed ping (and up again a ping interval later).
Also, I would like to see a "dead time" after reboot, so the monitoring starts only after interfaces have had a chance to come up, VPNs started, automatic
routing started (route table populated by BGP), etc.
As it is now, netwatch is not really usable and a lot of custom scripting has to be added, to the point where it is easier to write a scheduled script that does
the entire work of netwatch.