Community discussions

 
User avatar
Xymox
Member Candidate
Member Candidate
Topic Author
Posts: 283
Joined: Thu Jan 21, 2010 5:04 pm
Location: Phoenix, Arizona US
Contact:

Netwatch deprecated ?

Fri May 18, 2018 12:35 am

So.... Whats the status of Netwatch ?

The release notes on 6.42 show Mikrotik removed almost all the useful functionality. As I was using it to do a variety of things like sense internet connections, monitor network paths, monitor network devices, monitor devices on the network and even light LEDs based on a network device status. I also used it to sense when a router had internet access and then run DDNS. I used it to send txt msgs about the status of a wide variety of things.. So the loss of Netwatch has been a significant blow for me.

Mikrotik has not explained this removal of a really useful RouterOS feature. As far as i can remember this is the first time Mikrotik has removed any feature.

I dont understand WHY it was deprecated.

For some applications im now considering buying Ubiquiti devices as they run a open OS and so I can install any tools I want. Ive never needed a tool not already provided by RouterOS until now. I have some purchases coming up and I need to know what the fate of Netwatch will be. If Mikrotik is not going to restore it, I will need to swap out all customer routers for Ubiquiti to gain the ability to do "netwatch" like functions. For me this would end a very long relationship with Mikrotik that goes back to when they first started making PC Boards and i had to put them in enclosures.

As far as I know this is the only info on this total. From the 6.42 changelog:

*) netwatch - limit to read, write, test and reboot policies for Netwatch script execution;
 
sindy
Forum Guru
Forum Guru
Posts: 1148
Joined: Mon Dec 04, 2017 9:19 pm

Re: Netwatch deprecated ?

Fri May 18, 2018 1:21 pm

So far I was always thinking that the newly introduced limitation of netwatch script privileges is so frustrating for you because you would have to rewrite the configurations to accommodate the new approach.

But this post contradicts such understanding pretty much.

I have used netwatch myself for some months and all the time it was really disappointing for me that it could not tolerate some share of lost responses. So if the monitored address was accessible e.g. through a wireless link with sporadically occurring inteference, a single lost ping response was triggering the down-script action as if the monitored device was indeed down, whilst in fact it only indicated an otherwise tolerable amount of packet loss.

So from using down-script and up-script in netwatch, I've moved to use of scheduled scripts which watch address-lists populated by responses to netwatch-generated pings (where the lifetime of the item on the address-list is a multiple of the distance between ping requests sent). The privileges (policies) of these scripts and scheduler jobs are configured individually, and it is up to you whether you use a single script to evaluate the state of all monitored addresses or whether you use one script per each address.

On one hand, I fully agree with you that netwatch should be permitted to do anything you wish; on the other hand, I do understand that as it could be misused to bypass users' policy restrictions, Mikrotik had to do something about it. But my approach would be to assign policies to netwatch items the same way they are associated with scheduler jobs and scripts, and to allow the user to assign to the netwatch item he creates only policies with which his own account is configured (which I believe is the case with scheduler jobs and scripts).

If this approach would satisfy you, why not send a constructive ticket to support@mikrotik.com suggesting this?

Who is online

Users browsing this forum: BartoszP, Bing [Bot] and 40 guests