Mikrotikstat.us - check the health status of various MikroTik services

[cyrq]

Some time, during a downtime of the old forum or the CHR licence activation server (can’t remember exactly) someone on Discord mentioned that MikroTik lacks a status/ health page of it’s services, similar to ex. Google, CloudFlare or FortiNet.
So I’ve spun up a quick instance of Uptime Kuma, tweaked some stuff, bought a “catchy” domain and it’s been running fora couple of months now.
I’ve linked it previously on Discord/ Reddit but not on this forum.

If someone thinks that there’s something that should be added or removed from the page (ex. I’m not sure that there’s much sense of monitoring cloud*.mikrotik.com) then feel free to leave a comment.

[jaclaz]

NIce!

[infabo]

Good idea! Now Mikrotik can monitor the status of their services.

[Amm0]

Looks great.

@cyrq

I’m not sure that there’s much sense of monitoring cloud*.mikrotik.com

That actually what BTH and internet-detect use in their check for “direct” connectivity.

I recommend adding a UDP check on port 30000 to cloud.mikrotik.com, if possible — since that is actually used by RouterOS depending on config…

Detect Internet - RouterOS - MikroTik Documentation

[anserk]

@Amm0

I recommend adding a UDP check

For my own educational purposes, how can one possibly check a UDP port status strictly at layer 4 (without application built-in checks)?

[cyrq]

I guess it could be possible to monitor if a host:port allows a connection via UDP.
Sadly Uptime-Kuma doesn’t support that yet.

[anserk]

UDP is stateless, so I don’t understand how any such monitoring is possible. Only if the application-level protocol specifically supports some kind of health checks, but then it won’t be UDP monitoring anymore but the application monitoring.

[Amm0]

Just to note, if possible:

@Amm0

port 30000 to cloud.mikrotik.com, if possible

Well, there is still a ping-pong with UDP… So you send something and look for response. The possible part does seem a bit too optimistic. While not sure Uptime Karma support doing anything with UDP, which was my first thought.

now, the The Dude support checking UDP as probe

But there is secondary problem is format MikroTik is some 32byte value that changes, presumable it has the DDNS name/serial number/software-id or multiple — but obviously it is documented. I did a quick Wireshark since I wasn’t sure of what it send/got.

So yeah IDK — but you just asked “what’s missing”

Side-note, it uses the MNDP port 5678 (“winbox’s neighbors”) as source port, which is curious since it have to allow that back… I’m not sure it a good idea to overlap the two port usages, different topic.

[anserk]

@Amm0

So you send something and look for response

Indeed, if a higher-level protocol supports this. The Dude probe is either based on proprietary MikroTik discovery protocol MNDP (as you pointed out) or uses some other proprietary protocol. It is this data that is being exchanged, riding on top of UDP.

While this is not a UDP check per se, I agree it is technically possible for third-party tools to support MikroTik proprietary protocol checks if its details are published.

[jaclaz]

Only as a side note, to keep things as together as possible.

Currently there is seemingly a sort of specific “down” on this UDP port 30000 (which is used for “detect-internet”) that has two consequences:

1. those using “detect-internet” only to see nice graphs on the mobile app cannot see them anymore :
   Internet-Available-On-Sfp1-Limited-Access - #7 by COden6484
2. those using “detect-internet” for failover had their routers switch to secondary route (often LTE, please read as slower and more expensive):
   Detect internet stopped working (in Hungary? Spain? EU?)

This confirms that a way should be found to check for that UDP port functioning as it should.

[Amm0]

Yeah everyone’s favorite “detect-internet” is documented to use it that port. What it does using it, isn’t. Now looks similar to “packed”/TLV format used elsewhere like in MNDP

But I actually think port 30000 is used in /ip/cloud/ddns and ip/cloud/back-to-home-* - which are more widely used features. My suggestion wasn’t because of detect-internet’s problems - which are more likely local, or design issue since it’s config is error-prone and limited.

Now… AFAIK most of the /ip/cloud outages we’ve seen were network routing failures (so ping would catch). I’m not sure there been a case where some sub-service, like whatever port 30000 does, didn’t work.

[jaclaz]

… not sure … … there been a case …

I don’t get It, here Is one, It Is evidently NOT “local”.

There are reports from several EU countries and one from Brazil that since a few days:

1. cloud.mikrotik.com seems functional, responds to pings and the present dashboard reports It as FULLY operations.
2. yet detect-internet has stopped working

And there are reports of what seems like a similar case in 2023, and you took part in that thread :

Detect internet stopped working

At some point about 3h30m ago the detect internet function in my mikrotik routers stopped adding interfaces to the internet interface list This happened to two devices in two different locations with 2 different isp connections. I can still connect to cloud.mikrotik.com on udp port 3000 using “nc -zvu cloud.mikrotik.com 3000” Did something happen?

I understand how It might not be possible to check if the port/service Is working, but the dashboard should then (IMHO) have a static text to the effect of “detect-internet status:unknown”.