Since ovpn is sensitive to time difference between ovpn link endpoints (in my case these are Microtik devices), it is quite natural idea to monitor time on routers. And it was surprise for me I just can’t get date and time in some readable format without use of API and without parsing API output. Here is what I can get:
time: 12:12:13
date: nov/27/2015
time-zone-autodetect: no
time-zone-name: ...
gmt-offset: +02:00
Yes I can parse it and create time/date from it, but I would really like to get just the string of date/time in a single SNMP request, or at least in single API call without need for parsing it.
Hope the answer is there and it is positive one, since using SNMP only is quite a option for many external probe software (not all allow to use MT API).
I don’t know about SNMP, but with the API, you can get the whole clock data (date, time, timezone) with a single API call to “/system/clock/print”.
But yeah, that output needs some basic parsing. However, it’s not like parsing is difficult. Many languages have libraries for turning datetime strings into specialized objects and vice-versa, allowing you to quickly and painlessly convert between datetime formats. e.g. PHP has DateTime::createFromFormat(), Python has datetime.datetime.strptime(), C# has System.DateTime.Parse(), etc.
Actually I’ve already did that, since that was the only way I can do that. Strange I can’t get that in form of timestamp or string via single API call (as a complete string, with no parsing needed) or SNMP.
I also can’t get any easily parsable info about SNTP client state. Hers is what I can get:
And you may be surprised that these strings like 14m45s820ms are quite hard to be converted to any timestamp. I do not know how authors marked years, months, whatever - so I can’t even know how long before the last adjustment was made and last time difference found.
When it comes to ‘ip/cloud’ time functionality you won’t get anything. At all. No ‘state’, nothing.
Again, most languages have libraries for those sorts of things, and these types are usually covered as “time duration”, which (as part of the library) can be subtracted from a datetime object, thus giving you the time before the duration (or added, thus giving you the time after the duration).
What language are you using the API with? Maybe I can help with the exact code (if you’re finding it difficult).
I was playing with PHP as this is kind of web script, but not a problem to use anything. Yet I don’t know any library that can convert timestamp of 14m45s820ms (I don’t know how it indicates years, for example - maybe like 2y8m19d14m45s820ms - then ‘m’ for months or for minutes?).
What I try to say is that I think in this very thing Mikrotik team lack of machine-readable approaches to monitor. When you’re on Linux you can use ntpq and query your ntpd to see servers list used, and exact time difference between your machine and server chosen - that is, like ‘0,000328 sec’. On Mikrotik, you have to get clock time and you’ll have these difference in seconds, not in second fraction.
I also lack of useful debug info in a case when ROS SNTP client fail to sync time. Moreover, I don’t know what is the way of time sync used in ip → cloud functionality. So, time is not the strongest part of ROS so far
I was going to suggest my own PHP API client’s Util::parseValue() function, but I see it doesn’t actually support the letter notation, but only the colon separated digits notation (supports 00:14:45.820, doesn’t support 14m45.820s and 14m45s820ms). I’ll be sure to add it for the next release. Big thanks for that.
[edit]
Aaand I’ve just added that support, plus a method for getting the current time without any additional parsing… If you want it right now, you can use Composer and issue “composer require pear2/net_routeros:dev-develop” to get the latest code of the whole thing, or see the relevant code. There are a few more things I want to add/fix before I make a new “actual” release.
[/edit]
PHP has DateInterval, which uses a very similar notation to RouterOS’ letter notation. You just need to replace the weeks with “(weeks * 7) + days”, and things less than a second are* only supported with a decimal point in the seconds.
As for the years and months… RouterOS doesn’t support those in its “time” type (because they can’t unambiguously be converted to a number), and while PHP can contain those in the DateInterval object, it can’t really “do” anything with those until it has a datetime object to base them against, i.e. you can add/subtract from a specific date a certain number of years and months, with the exact number of days being dependent on the months involved (one month from 1st Feb is 1st Mar - 28 or 29 days depending on whether the year in the datetime is a leap year - with PHP also taking care of the leap year check).
Crap… Make that “will be”… PHP doesn’t support decimal seconds yet… Subsecond information would have to be ignored or rounded up for now.
Well, time is something that’s for human eyes, that’s the idea of whole MT time/clock approach. I’d like to monitor time difference (that is, how big is the diff between “world time” and router time), and better to sub-second accuracy. ALl I can do now is to do API call to get clock, parse the time and compare against server time. So I have to enable API access on the router (extra thing to care) and tune ACL on it. I monitor the time diff in seconds, but that’s something not elegant. Sad
While I’d like to see sub-second accuracy in RouterOS’ clock for other reasons (benchmarking scripting performance), I have to ask in this case…
Why? Why bother with tracking sub-second accuracy of the clock on remote devices? There’s the NTP protocol for time sync, if the goal is to keep the clocks accurate. If the goal is to detect if such a sync is even necessary (and only do syncs manually on such an occasion), you only need the clock to be off by a few seconds to know for sure. Besides, sub-second accuracy for a remote device is very error prone, since the very act of transmitting the time takes a few milliseconds, and if the network is not that good or too remote, even up to a few seconds.
And sure, you need to enable access with the API, but that’s true for any protocol, so that’s not saying much - if you were using SNMP, you’d need to enable it too. Either way, you just need to add it to your initial/backup configuration script(s).
You see we have SNMP enabled for years and we implement API-based monitoring only recently so I still wonder if I can do the same without enabling API access.
As for me I’ve seen too many times how SNTP on ROS won’t work at all. No debug was useful (I mean device logs). It was better or not over ROS version change so I really doubt it is ROS based. Since that times I really like to monitor clock on ROS.
Besides, I don’t know if it is enough to use it → cloud clock without NTP client al all? No NTP client - no config - no attack base - no monitoring, but the only info I can find is http://wiki.mikrotik.com/wiki/Manual:IP/Cloud#Properties this part of wiki page which reads:
update-time (yes | no) If set to “yes” then router clock will be set to time, provided by cloud server IF there is no SNTP or NTP service enabled. If set to “no” then cloud service will never update router clock. If update-time = yes, Clock will be updated even when /ip cloud ddns-enabled = no
But nothing is said on its accuracy, protocol and enev which hosts needed to be allowed in firewall to have it run.
Time with “/ip cloud” uses NTP too AFAIK. The only difference is that time only syncs when the IP changes, and the NTP request goes to MikroTik’s NTP servers. Which IPs are those? Whichever one mynetname.net (or maybe a subdomain of that) points to I’d guess (ask support if you REALLY need to know). Most people using “/ip cloud” would not need to whitelist anything - as long as they have internet connection, things would just work (so MikroTik don’t have anything in the docs, so as to not confuse THOSE people). Anyone who needs finer NTP control has the NTP client at their disposal.
Sure, but again, no sub-second precision is needed here. Precision down to a second is enough.
I have yet to hear of an NTP client vulnerability. I’ve only heard of NTP server ones. But sure, I get it.
