WISPMap: a map-first monitoring tool for MikroTik WISPs (feedback wanted)

3rd party tools
1

Edit (7 Nov): wireless link quality, subscribers per tower and a router security check have been added since this post. See the update further down.

Hi all,

I run a small hosting business in South Africa and have been building a monitoring tool for wireless ISPs on MikroTik. It's now usable, and before I go further I'd really value feedback from people who run MikroTik networks every day. Full disclosure: it's my own product, and the basic tier is free.

The problem I wanted to solve
When a backhaul drops, most tools send you 30 "down" alerts for everything behind it, and you still have to work out what actually failed. On top of that, here we deal with load-shedding, batteries and cable theft, so "is it the link or the power?" is often the first question.

What it does

  • One live map of your towers, devices and links, with status from ping and the RouterOS API. Links are suggested from your routers' neighbour tables and you confirm them.
  • Root cause instead of an alert storm: devices behind a failed link show as unreachable, not down, and you get one incident naming the failed link and the sites that are cut off.
  • OSPF aware: it reads which links are active and which are backup from the routers themselves, and tells you when a backup takes over.
  • Power: voltage and board/CPU temperature from /system health, battery state per site (mains lost, on battery, battery low), and PoE-out per port, including faults like a short circuit or overload, with a "powered from" hint when a PoE-powered device goes down.
  • Charts for latency, loss, traffic, CPU and memory, kept for two years.
  • Maintenance windows that keep planned work (and everything behind it) from raising alerts.
  • Email alerts with reminders, quiet hours and one-click acknowledge.
    **Thank you to @rextended for catching the empty section.

How it connects
A small collector runs inside your network (Docker, on any small Linux box or a Raspberry Pi). It talks to your routers through the API with a read-only user:

/user group add name=wispmon policy=read,api,test

It sends results out over HTTPS, so there's no port forwarding, and router passwords never leave your network. The collector is open source (Apache 2.0): GitHub - gigahost-za/wispmap-collector · GitHub
It works with RouterOS v6 and v7. Other vendors are ping-only for now.

What it doesn't do (yet)
No config push, no BGP, and no config backups yet.

Try it
There's a live demo with a simulated WISP that breaks things on purpose (power cuts, backhaul failures with OSPF failover, PoE faults), with no signup needed:

https://wispmap.gigahost.co.za/demo/

During the public beta, everything in the Pro plan is free (no card needed), with at least 30 days' notice before launch. After launch there's a free plan for up to 25 devices.

What I'd love your input on

  1. What do you use for monitoring today (The Dude, UISP, LibreNMS, Zabbix, something else), and what annoys you about it?
  2. What RouterOS data would you want that it doesn't read yet? Wireless registration tables, CAPsMAN, BGP, queues, something else?
  3. Is the read-only policy set above something you'd be comfortable giving a tool like this? Anything you'd want changed?
  4. Which alert channels matter most to you: WhatsApp, SMS, Telegram, something else?
  5. Of the things on the roadmap (customer impact, a public status page, config backups, BGP), which would you want first?
  6. How much non-MikroTik gear is in your network, and what is it?

Honest criticism is very welcome, including "this already exists, use X". Happy to answer any questions here.

Thanks for reading!

2

Thanks, I’ll take you literally.

This is the best part of the whole topic.
What does it do?
It doesn't do anything!
it’s just for starting a thread on the forum.

immagine
immagine172×208 8.35 KB

I took a screenshot because a responsible person would check what they post for announce something,
rather than just copy-pasting from an AI,
without even knowing what they’re doing.
You can go ahead and edit the post now,
but I’ve got a screenshot that captures your laziness and . .
These are insults directed at people on the forum,
"I’m just tossing the text out there to promote myself",
after all, why should I care about the people on the forum?

There are dozens of things that already do this;
why start from scratch every single time someone wakes up in the morning
and decides to spend some time tinkering with AI to launch yet another product,
one that, yet again, does the exact same thing,
to start all over from the beginning?

3

@rextended
You're right, and I apologise.

I wrote the announcement once so I could post it in a few places, and I was still posting it elsewhere when this one went up, before I'd checked how it came out here. That's on me, and it isn't how I want to treat people I'm asking for help. I've edited the post so the list is there now.

On why build another one: I didn't start from "let's build another monitoring tool". I started by asking WISP operators here what frustrates them about the tools they already run (The Dude, UISP, LibreNMS, Zabbix and others), and built around what kept coming up:

  • Alert storms: one backhaul drops and you get an alert for every device behind it. WISPMap sends one incident naming the failed link and the sites cut off, using links it reads from the routers' neighbour tables and OSPF, rather than dependencies someone has to maintain by hand.
  • "Is it power or the link?": with load-shedding and cable theft, that's the first question. Battery state per site and PoE faults sit on the map next to link status.
  • Another server to look after: a small open-source collector connects outbound only, with a read-only API user, and credentials stay on your network.

It's deliberately narrow. If an existing tool already solves those well for a small WISP, I'd genuinely like to know which one and how you've set it up.

4

Update: what's new in WISPMap since the first post

Thanks to everyone who tried the demo and sent feedback. Here's what has shipped since:

Wireless link quality (1.8)

  • Every AP and PtP radio lists its clients: signal, SNR, CCQ, tx/rx rates and connected time, weakest first, with history charts. Works with the legacy wireless package, RouterOS 7 wifi and 60 GHz (w60g).
  • Links between towers show what each end hears, compared with that link's own normal level (the median of its past week), so a dish knocked out of alignment stands out even when the number still looks acceptable.
  • Two new alerts: signal 6 dB below the link's normal level for 15 minutes, and SNR below 15 dB for 10 minutes.
  • A "Signal" view on the map colours wireless links good / fair / poor.

Subscribers per tower (1.8)

  • Customers online per router and per tower, from PPPoE, hotspot or DHCP leases, on the device page and the map. Counts only: no names or usernames leave your network, and customers never count towards your plan.

Router security check (1.9)

  • Every router checked against MikroTik's hardening advice and advisories:
    • RouterOS versions with known exploited flaws (CVE-2018-14847, CVE-2023-30799);
    • telnet, FTP and plain HTTP left on, and the default admin user still enabled;
    • SOCKS or web proxy switched on (a common sign of malware), and MAC Winbox open on every interface;
    • newer RouterOS on the router's own channel.
  • It also tells you if the monitoring login itself has more rights than reading needs. Each finding comes with the commands to fix it.

Public beta (1.7)

  • Everything in the Pro plan is free until launch, with at least 30 days' notice before that changes. Places are approved by hand to keep the beta small.

All of this is read with the same read-only user (policy=read,api,test). To get the wireless, subscriber and security data, update the collector to 0.6.0 (docker compose pull && docker compose up -d in its folder).

Live demo: https://wispmap.gigahost.co.za/demo/
Changelog: https://wispmap.gigahost.co.za/changelog/

Coming next: a weekly report, webhooks and Telegram alerts. After that, upstreams, BGP and multiple POPs.

That last one is where I'd value your input most:

  1. How many upstreams and POPs do you run?
  2. Do you use BGP with your own ASN, or static default routes with failover (distance, netwatch, recursive routes)?
  3. When an upstream fails, what do you want to know first?