Routers and Network

• Routers
• Zero-touch enrollment (QR codes)
• Router groups
• Firmware version tracking
• Multi-WAN failover
• Smart Queue Management (call quality)
• Config backups
• Scheduled reboot
• Installer checklist
• Bandwidth & speed caps
• Bandwidth cost forecast
• WiFi signal / coverage control
• Evil-twin / rogue access point detection
• Remote CLI & restart
• Fair Pause & outage alerting
• Bandwidth congestion alerts
• Fair Share bandwidth
• Content filtering
• Network topology

This is the full reference for this part of the dashboard. For everything else, see the main documentation.

Add a router with a name, a location, and an optional router ID (auto-generated if you leave it blank). You'll get a one-time SSH command to run on the physical device — it needs to be OpenWRT-based (Teltonika RutOS, GL.iNet, or similar) — plus the External Login URL to set in that router's own Hotspot settings so it knows where to send guests, pointed straight at your Captive Login. From there, every router in your fleet shows online/offline status, connected device count, and last-seen time, and an "Auto-config" wizard walks through vendor-specific setup. Fully automated (a one-time script does the work): Teltonika, GL.iNet, generic OpenWRT (also the right pick if you've flashed OpenWrt onto a supported Cudy model — Cudy's own stock firmware isn't OpenWRT-compatible), and MikroTik (access control, content filtering, and RADIUS if you've turned it on; WiFi/bandwidth settings still need configuring on the router itself). Automated via cloud API instead of a script: Cisco Meraki (paste a Dashboard API key plus your network and SSID number, and it points that SSID's splash page straight at your Captive Login — content filtering and RADIUS aren't covered for Meraki yet, since Meraki's own settings for those work differently from every other router here) and TP-Link Omada (paste your Controller URL and a hotspot-operator account, and ISN tells the Controller a guest is authorized the moment they're granted access on our side — the one thing you still set by hand in Omada's own UI is the SSID's Portal Type and External Portal URL, shown to you once your credentials verify successfully; content filtering and RADIUS aren't covered here either). Everything marked "beta" above hasn't been verified against real hardware yet. Guided manual instructions only (no automation): Cisco WLC/ISE, Cisco small-business (RV/WAP), stock Cudy firmware, Cambium (cnPilot/cnMaestro), Ruckus, and "Other" — each gets guidance actually specific to that hardware (an ISE RADIUS server, for instance, is exactly what the RADIUS authentication panel below is for; for a large project, ISN can also host and secure the RADIUS server for you on request, see the Secured RADIUS guide) rather than one generic snippet. Click into any router to set its WiFi name/password (or run it as an open network), speed caps (see Bandwidth & speed caps next), restart it remotely, or deactivate it without losing its history. Each router in the list shows its own live Download/Upload Mbps and device count — not a combined total across your fleet — since a busy or struggling router is often just one of several, and you need to tell which one from the list itself. Once an hour, each router also runs a small, bounded (2MB) speedtest against its own ISP line — shown separately as "ISP line speedtest" with latency, download, and upload — so you can tell "my internet line itself is slow" apart from "my own caps/guest sharing is the bottleneck." Deliberately small and infrequent so it never meaningfully eats into a metered data line or competes with real guest traffic.

Rotating WiFi passwords at scale. "Rotate WiFi password for all routers," above your router list, applies one new name/password to every OpenWRT-family router (Teltonika, GL.iNet, generic OpenWRT) in one password-confirmed action — no need to log into each router individually, and no risk of guests bouncing between APs with mismatched credentials mid-venue. A MikroTik or other-vendor router isn't covered by this push and needs its own Hotspot WiFi settings changed directly. Separately, most routers already self-update their own agent automatically the moment a new capability ships — a banner only appears above your router list when one genuinely predates that mechanism and needs a single manual reinstall to catch up; after that, it stays current with zero further action from you.

Standing in for a broken-down bus. A journey preset that's router-restricted for fare-enforcement can't normally tell a genuine relief-bus transfer apart from someone fare-dodging onto a different bus — both look identical from the router's side. If a bus breaks down and passengers move to a different vehicle, open the replacement router's own Manage panel and set it as "temporarily standing in for" the broken-down one, so already-paid passengers moved onto it keep working instead of getting wrongly cut off. It stays on for 24 hours after it's set, and longer automatically while passengers still hold unexpired bundles for the bus it covers (a long trip, with or without GPS, is covered because those bundles already last as long as the trip does), up to a hard limit of 7 days, so it can never quietly turn into a permanent way around that route's fare restriction. You can clear it yourself at any time. Only a bus can stand in for a bus: a bus station never appears in the list, and a station router does not offer stand-in at all. To pick the broken-down bus, type part of its name, location or ID in the search box; it shows 3 matches at a time. Data and time are also kept apart per bus route: a cheap bundle bought for one bus never adds its data or hours to a different bus's unlock, even when the same guest holds bundles for both buses. The bundles also travel with the transfer: while a bus is standing in, passengers on it are offered the broken-down bus's route bundles (with prices and passed stops worked out from the relief bus's own GPS or timetable), and the relief bus's own route bundles are hidden until the transfer ends. Bundles that belong to no bus stay visible. Bus stations. In a router's Manage panel, tick "This router is a bus station" and type the place it is in (for example Pretoria). Every route that stops at that place is then listed there automatically, whether it is the route's first stop or one in the middle (Johannesburg is a middle stop on a Pretoria to Bloemfontein bus; the last stop does not count): the Pretoria station shows the buses stopping at Pretoria, the Johannesburg station the ones stopping at Johannesburg, and a similar name such as Pretoria North never matches. A route needs a departure time to be listed. Each bus appears 2 hours before it leaves THAT station, using the time it leaves that stop (the stop's own timetable time or, when the stops carry timetable times, the first stop's timetable time plus the planned drive and waiting time up to that stop; a route with no timetable times uses its departure time instead). Keep a route's departure time and its first stop's timetable time the same, otherwise the first stop and the stops after it will disagree, sorted by departure time. Passengers at a middle station only buy tickets for the stops after it, priced from that stop (the legs they actually ride), with the waiting time added; at the first stop the price is the same as on the bus. If your routes call a stop something else (for example "Park Station" for Johannesburg or "Kroonstad Garage" for Kroonstad), press Find on map (it uses your own TomTom or GraphHopper key, and any route stop whose map pin is within 1.5 km of the station counts as that place) or add the other name under Other names; the preview under the place shows exactly which routes will be listed, with the time each leaves that station. Stations never appear in the Restrict to specific routers lists, so there is nothing to forget to tick: bundles and vouchers for a bus route reach the stations that list the route automatically, while that bus is still on offer there. A ticket bought at the station works there straight away; the waiting time until the bus leaves is added to the ticket when it is bought, so the countdown is simply the real time left. Data used at the station comes off the same ticket as on the bus, and the ticket works only at the station (until the bus has left) and on its own bus, never on another one. A ticket bought at one station does not work at a different station, even one that lists the same route. So two people using one account at two stations each use their own ticket: when two tickets are valid on the same router, the one bought there is spent first. The bundle's speed limit and device limit apply at the station exactly as they do on the bus. A bus counts as departed when its GPS has moved off heading for the next stop with passengers connected (even before its time), or has moved off with nobody connected once its time is up; an empty bus that only repositions earlier stays listed, and a bus going the wrong way is not treated as departed. A bus without GPS stays listed until 30 minutes after its time. A ticket bought before departure on a bus without GPS also gets 10 extra minutes, in case the bus leaves late. A bus with live GPS that is running late is followed automatically: the system works out when it will really arrive and leave the station from where it is now, with live traffic and closed roads (TomTom, GraphHopper as the back-up; this needs a routing key on your account), and never earlier than its timetable time. The station list then shows, for example, "scheduled 18:00 · running about 1 h 5 min late · expected 19:05", counts down to the real departure, and orders the buses by when they will really leave. Guests only see minutes, never where the bus is. A late GPS bus that is still on its way is not dropped, and a ticket bought while the bus is late includes the real waiting time (up to 3 hours). The station's Manage panel shows a Live status line for each route: expected time, how late, the road distance, what traffic adds and which bus. When the bus really leaves, every ticket bought at that station is re-timed to the real departure plus the ride, so a late bus never costs a passenger time. A passenger already riding is covered by the delay check that runs every 5 minutes: once a ticket has 20 minutes left it is extended to the real remaining drive plus 10 minutes, up to the route's planned trip length. A bus without GPS cannot be followed, so the timetable decides. If a passenger is left behind (their phone was at the station but never appeared on the bus, checked 20 minutes after it left), the station's setting decides: move the ticket to the next bus on the same route (the default), keep the station Wi-Fi until the ticket's own time runs out, or nothing. The original ticket is never removed.

Full guide: Routers and Network.

What it does. UniFi sends each new guest to your ISN login page. Once the guest has earned or bought access, in any way ISN offers (a free allocation, a voucher, an ad, a survey, a data plan, Single Sign-On, a partner network), ISN tells your UniFi controller to let that one device online for the time, speed and data that guest is entitled to. When the access ends, or you block the device, ISN tells the controller to take it away again. There is no program to install on the access points.

What you need. A UniFi Network controller that ISN can reach over the internet: a UniFi OS console (Dream Machine, Cloud Gateway, Cloud Key Gen2 or later), a classic Cloud Key or a self-hosted Network Application. Give ISN either a local controller account (a login created on the controller itself, not a ui.com account) or, on UniFi Network 9.1 or later, an API key. An account that only manages guests is safest if your version offers one. Because the calls come from our servers, the controller address must be reachable from the internet and start with https://. Private addresses (such as 192.168.x.x or 10.x.x.x) are refused. The usual ways to make a controller reachable are a public address with a firewall that only lets our servers in (ask us for the addresses to allow), or a site-to-site VPN. If your remote access points already reach the controller over the internet (Layer 3 adoption), it is probably already reachable.

Setting it up. Add a router for each location under Network, Routers. Then open Auto-config, choose Ubiquiti UniFi, and enter the controller address, the account and the UniFi site name (usually "default"). ISN tests the login and checks the site before it saves anything. The same settings, a Test connection button and a status line showing the last result are under Network, Routers, Advanced: Ubiquiti UniFi guest portal. Then, in UniFi Network, open Settings, Hotspot Manager (or Guest Hotspot) and choose External Portal Server. Set the server to your captive address, for example your-captive.isnfreewifi.co.za (UniFi adds /guest/s/<site>/ itself), add the pre-authorization list shown in the dashboard so a phone can reach your login and payment pages before it is let online, and turn the guest hotspot on for the Wi-Fi network guests use.

Several locations. UniFi tells ISN which access point the guest is on. For each location, list its access point MAC addresses (or, if each location is its own UniFi site, just the site name). A guest arriving from an access point that belongs to no location is not guessed at, so a venue is never charged or reported against the wrong place.

What ISN sends to the controller. The device address, the time in minutes, the download and upload speed in kbps, an optional data limit in MB, and the access point. If a speed limit changes during the session (for example a fair-usage throttle), ISN authorises the device again with the time that is left. The data limit is set once, at the start, because the controller would count it from zero again; ISN's own usage tracking still enforces the data allowance and removes the device when it is used up.

Security. The controller password or API key is stored encrypted and is never shown again. Only the account owner can change the settings or run the test. Connections must use https, addresses on private networks are refused, redirects from the controller are not followed, and a device is only authorised if it arrived through the UniFi redirect to your portal first. If the controller cannot be reached, the guest still receives their access on the ISN side, the failure is logged, and the dashboard status line shows it.

Certificates. Controllers often use a self-signed certificate, so ISN does not insist on a trusted certificate by default. That leaves a small risk that someone on the path between ISN and your controller could read the login. If your controller has a normal trusted certificate, tick "Require a valid HTTPS certificate". A scoped guest-only account or an API key limits the damage if a login ever leaks.

The ISN connector (recommended). Instead of making your controller reachable from the internet, run the ISN connector on any always-on computer inside the same network as the controller: a Raspberry Pi, a small PC or a Docker container with Node 18 or newer. It only calls out to ISN (it opens nothing on your firewall), picks up jobs such as authorise a guest, block a device, restart an access point or change the WiFi, does each one on the controller locally and reports back. Your controller login stays on that computer and is never sent to ISN. In the dashboard choose "Through the ISN connector", press Create the connector, download the program with the link shown (it works once and expires after 15 minutes, so the permanent secret never sits in a web address), and start it with UNIFI_URL, UNIFI_USER and UNIFI_PASS (or UNIFI_API_KEY on UniFi Network 9.1 or later; add UNIFI_VERIFY_TLS=1 if the controller has a trusted certificate). The page shows "Connected" when it is running. Keep it running after a reboot with the ready-made scripts in the connector service guide (Linux, Windows and Docker). If the connector is offline, guests still get their access on the ISN side but the controller is not told, and the dashboard says the connector is not connected. A new secret can be created at any time, which stops the old one working. Only the account owner can create it. Security: the connector checks ISN's certificate, ISN stores only a hash of the connector secret, everything the connector reports back is cleaned and length-limited before ISN uses it, and the connector can only perform a fixed list of controller actions. Run it as an ordinary user (not root) on a machine you trust, because your controller login is in its settings.

WiFi name and password, firmware and a security check. The existing WiFi settings screen changes the guest WiFi network on the controller (when a site holds only one location and one guest network; otherwise change it in UniFi, and the dashboard says why). "Upgrade access point firmware" starts the controller's own upgrade on that location's online access points, and "Run a security check" reads the controller's settings (client isolation, SSH, guest portal, protected management frames, matching firmware) and shows what to fix. The check only reads; ISN changes none of those settings.

What works like other routers. A UniFi location has no ISN agent, so ISN asks the controller instead. Every minute it lists the access points and connected devices, so the location shows online or offline, its device count and the connected-device list in the dashboard, using the access points you listed for the location (or, when a site holds only one location, all of that site's access points). A location whose access points are all offline on the controller shows offline. Blocking a device from the dashboard puts it on the controller's own block list and disconnects it, and removing the ban removes it again (this needs a local controller account, not the API-key route). The Restart button, and scheduled reboots, restart that location's access points through the controller. Speed and data limits are set on the controller when a guest is authorised, and free-access rules, vouchers, ads and usage tracking run on ISN's side as for every router.

Whole-line speed cap, SQM and WAN status. The router speed-cap setting works for UniFi through the gateway\'s own Smart Queues (UniFi\'s SQM shaper): setting a download and upload rate switches Smart Queues on for the gateway\'s WAN networks at those rates, and clearing the cap switches it off. This needs a gateway (Dream Machine, Cloud Gateway or UniFi gateway) on the site, a local controller account (or the connector), and a site that belongs to one location. The WAN status check lists each WAN port of the gateway (up or down, address) and the Smart Queues setting, so you can see multi-WAN failover at a glance. These two use controller settings that are not in Ubiquiti\'s public documentation and have not been verified on real hardware yet, so test them on the Proof of Concept before relying on them.

What UniFi does not get. Content filtering and RADIUS pushes are not available: UniFi\'s DNS filtering and its guest RADIUS mode are changed inside UniFi, and a wrong change from outside can lock guests out, so ISN does not touch them. The ISN hardening and tamper checks, Fair Share, and the abuse lookup tool need the ISN agent on the router itself (the security check above covers the settings UniFi exposes). Do those in UniFi itself. To add them safely, use Download controller report on the UniFi card: it reads the controller and saves a file of which settings and API paths it really has, with field names and types only (no passwords, keys, addresses or names). Send that file to ISN support from your Proof of Concept and we build and test the missing features against exactly what your controller shows. The pre-authorization list is pasted into UniFi by you, because ISN cannot push it.

Limits to know about. This integration is new and has not been verified against a real UniFi controller yet; the setup on a real controller is the test. Live traffic speed and per-device data use are not shown for UniFi locations, because the data cap is enforced by the controller. Phones can use a private (randomised) Wi-Fi address, which UniFi and ISN both see as a different device on a new network. Session length is enforced by the controller, so changing the time on the ISN side does not shorten a session that has already been authorised.

Pre-generate setup codes for routers you don't have in hand yet — useful when you're rolling out several at once. Under Your routers → Zero-touch enrollment, pick MikroTik or OpenWRT-family, choose how many, and generate — each one becomes a QR code and a short link, shown together in a printable sheet ("Print QR sheet"). Give one to whoever's actually installing that router (a driver, an on-site installer, a courier) — they open it, no ISN login needed, optionally name the router and its location, and get that vendor's exact install command with step-by-step instructions and a copy button. Submitting the form creates the router in your dashboard immediately, the same way adding one yourself does.

This isn't fully hands-free — someone still has to paste the command into the router's own terminal. A browser genuinely can't reach a router's local admin page directly from an HTTPS site (a real browser security limit, not something this platform can route around), so a phone scanning a QR code can't configure a router purely on its own. What this removes is you being the one who has to be there, or generate/walk through the install command live, for every single unit.

Each code is single-use and shows the install command exactly once, right after it's claimed — if whoever's setting it up navigates away before copying it, you can get it again from that router's own Manage page instead of reusing the code. A code can be revoked any time before it's used; a used or revoked code can't be claimed again. Codes never expire on their own, so you can generate and print a batch well ahead of when you'll actually need them.

Tag routers into named groups (e.g. "Ground floor", "Branch A") so a bulk change reaches just that group instead of one router at a time or your entire fleet — worth setting up once you're running more than a handful. Create a group, assign routers to it from the dropdown, then apply a speed cap to the whole group in one action, or scope "Rotate WiFi password for all routers" above to a single group instead of every router. Purely an organizational label: a router not in any group behaves exactly as it always has, and deleting a group only ungroups its routers — it never touches the routers themselves. Group names also drive the "Revenue by department" table in My revenue — rename or regroup here and that report reflects it immediately.

Each router's real firmware/OS version now shows on its own card in your router list — OpenWRT-family routers (Teltonika, GL.iNet, generic OpenWRT) report it automatically on their regular check-in; MikroTik routers don't have a continuous telemetry loop yet, so theirs is checked once a day via the same read-only command channel already used for other automated MikroTik checks.

How "outdated" is decided — deliberately not a maintained vulnerability list. We don't try to keep a live database of which specific firmware versions have which CVEs — that kind of list goes stale fast, and a wrong or outdated entry would be actively misleading for a real patching decision. Instead, a router is flagged only when it's running an older version than another router of the same vendor already elsewhere in your own fleet — if 4 of your 5 MikroTik routers are on 7.15 and one is still on 7.9, that one gets flagged; a single router, or a version nobody else in your fleet has beaten yet, is never flagged since there's nothing real to compare it against. A banner above your router list summarizes every outdated one, grouped by vendor, with a direct link to that vendor's own official release notes/security advisory page so you're reading the source, not a copy of it.

This tells you when a router has fallen behind the rest of your own fleet — it is not a vulnerability scanner and doesn't claim to know about any specific CVE. For actual security advisories, check the vendor's own page linked in the banner (MikroTik's changelog, OpenWRT's own advisory list, or your router vendor's support site).

Automatically switches a router's guest traffic to a backup internet connection if the primary one goes down, and switches back once it recovers — the same idea as a business having a fibre line with an LTE line as backup. This is entirely config we push to a connection you've already physically wired up; we can't create the second connection itself, only make the router use it correctly once it exists. Found on each router's own Manage view (only shown for supported vendors).

MikroTik uses RouterOS's own native distance-based routing: two default routes are configured, the primary at a lower distance (tried first) and the backup at a higher one, both with check-gateway=ping so RouterOS actually notices when the upstream ISP stops responding — not just when the physical cable is unplugged, which is the far more common real outage. You'll need to enter both gateway IPs (found under IP → Routes in Winbox/WebFig). OpenWRT-family routers (Teltonika, GL.iNet, generic OpenWRT) use mwan3, a standard, widely-used OpenWRT package — installed automatically the first time you turn this on for a router, never touched otherwise. You'll need the exact interface names for both connections, already configured under Network → Interfaces on the router itself.

Once enabled, which WAN is currently active is checked every 5 minutes and shown right on the router's Manage view, with a running history of every switch below it. A switch to backup sends you an alert the same way a router-offline alert does (toggle it separately under Notifications) — worth treating as "your primary line needs attention," since guests should stay online through the switch itself, that's the point.

Turning this off is bookkeeping only — we deliberately never auto-remove the routes/config already pushed to the router, since doing that automatically risks dropping a guest's connection mid-failover, and there's no reliable way to tell our own pushed config apart from something you've since changed by hand. If you want it fully removed, do that directly on the router. Not yet verified against real hardware.

Keeps video calls and voice calls smooth even while someone else on the same router is downloading something large — the technical term for the problem this solves is bufferbloat (a connection that's technically "up" but so backed up with queued traffic that everything feels laggy). Found on each router's own Manage view, right below Multi-WAN failover.

Deliberately not "detect this is a video call and prioritize it." Modern call and video apps (WhatsApp, Zoom, Teams and similar) mostly use unpredictable, constantly-changing ports specifically to avoid that kind of filtering, so building rules around specific ports or apps would be unreliable — and we'd rather not claim a precision we can't actually deliver. Instead this uses CAKE, a real, widely-deployed fair-queuing algorithm (it's the OpenWRT project's own recommended fix for bufferbloat) that achieves the same practical outcome a different way: it shares the connection fairly based on how much bandwidth each individual connection is actually using, moment to moment. A voice call naturally uses very little bandwidth compared to a bulk download, so under CAKE it naturally keeps flowing with low delay — no need to know or guess what app it belongs to.

Enter the WAN interface name (same field as Multi-WAN's own interface names) and your download/upload speed in Mbps — set these to roughly 90-95% of the router's real measured line speed (see its ISP line speedtest under Routers), not the full advertised speed. This matters: bufferbloat happens in equipment upstream of your router that this feature can't control, and giving SQM a slightly-lower ceiling to manage is what lets it actually stay ahead of that congestion instead of just adding another queue behind it.

OpenWRT-family routers use sqm-scripts, a standard OpenWRT package (installed automatically the first time you turn this on, same as mwan3 above). MikroTik uses RouterOS 7's native CAKE support — this needs RouterOS 7 or later, and is genuinely the least-tested piece of everything built in this session; if you're able to, try it on a spare or low-priority router before relying on it somewhere that matters. Same as Multi-WAN, turning this off is bookkeeping only and doesn't remove the queue config already pushed to the router.

A safety net for every config push this platform makes to a router: firewall hardening, content filtering, Smart Queue Management, and Multi-WAN failover. Found on each router's own Manage view. A backup is taken automatically right before any of those four changes is pushed — you don't have to remember to do it — and a "Back up now" button is there for taking one any other time, e.g. before you experiment with settings yourself directly on the router.

A backup is the router's own real export format, not a bespoke format only this platform understands — MikroTik's own /export command, and the equivalent for OpenWRT's UCI config system. Restoring one replays it back, which is the standard, documented way both platforms expect a config to be restored, rather than this platform inventing its own undo mechanism per feature.

WiFi password and RADIUS shared secret are deliberately never included in a backup, on either vendor — MikroTik's plain export already leaves secret values out by RouterOS's own default behavior, and the OpenWRT backup is deliberately scoped to only the config sections this platform manages (firewall, SQM, Multi-WAN, network, DHCP) rather than a full device export, skipping the sections that hold WiFi and RADIUS secrets. This also means restoring a backup can never blank out a working WiFi password.

Restoring is a real, destructive action — it replaces the router's current config in those sections with whatever was saved — so it asks you to re-enter your dashboard password first, the same step-up check as firewall hardening and Remote CLI. Only the 20 most recent backups per router are kept. Works for MikroTik and OpenWRT-family routers; not yet verified against real hardware for either.

A periodic maintenance restart on a schedule you set, found on each router's own Manage view (or applied to a whole Router group at once, under Network → Routers). Genuinely different from the outage alerting this platform already does — that only tells you when a router goes down unexpectedly; this actively restarts a healthy router on purpose, on the schedule you choose, using the exact same mechanism as the manual "Restart router" button.

Pick an hour (0-23, in SAST) and, optionally, specific days — leave every day unchecked for a daily reboot, or tick specific days for a weekly one (e.g. Sunday only, at 3am). A background check runs every 10 minutes and fires the reboot once it's inside the chosen hour, so it lands sometime within that hour rather than on the exact minute — fine for routine maintenance, not meant for split-second timing.

Applying a schedule to a whole Router group sets every router currently in that group to the same schedule in one action — it does not keep them linked afterward, so a router added to the group later needs the schedule applied again (the same one-time-bulk-apply behavior as that group's speed cap). Works for every router vendor this platform supports, since it rides the same restart mechanism already used for the manual button.

A step-by-step record for whoever physically fits a router, on that router's own Manage view under Network ? Routers (scroll to "Installer checklist"). Open it on the phone you are installing with. It has four parts: eight steps to tick off (mounted and powered, uplink working, WiFi name and password set, login page opens on a test phone, test login gives internet, guests cannot reach the router admin page, router labelled, venue contact shown how to use it); a location recorded from your phone's GPS; up to six photos with a label each (photos are shrunk on your phone before upload); and a speed test.

The speed test runs from the device you are holding. It downloads and uploads test data between your phone and this platform, so it measures what a guest at that spot would really get: the venue WiFi plus the venue's internet line together, not the router in isolation. It also records ping. Run it standing where guests will sit.

Mark install complete only works once every step is ticked and a location, at least one photo and a speed test are saved. Changing anything afterwards (a step, a photo, the location) re-opens the checklist so the record always matches what was last saved. View Only accounts can read the checklist but not change it, and Financial accounts cannot open it. Your phone will ask permission to share its location, and the location is only as accurate as the phone's GPS fix, which the page shows next to the coordinates.

Several separate speed caps exist across the dashboard, each governing a different scope — worth having in one place, since it's easy to set one expecting it to cover a case a different one actually governs. Default guest speed cap (Free access → Owner & guest access, Mbps down/up) applies to every regular guest at this location unless something more specific below overrides it — 0 means uncapped, no hidden platform ceiling underneath. Speed limit for each guest device, set from any router's own management page but — despite living there — applied account-wide across every router you run, not just that one, is the everyday version of the same idea: you pay your ISP for 150 Mbps but only want to hand each individual guest device 10 Mbps of it. Guests get full, uncapped speed the entire time they're actively watching ads to unlock or top up their ad-supported access — even one who already has an active bundle and its cap, going back to watch more — so an existing cap never fights with ad playback; the cap only re-applies the moment the new bundle actually lands. Your own owner-login session is never capped by any of this either. This router's total line speed, on that same router page, is a different and rarely-needed thing: a cap on that one specific router's own total incoming connection, for reserving bandwidth on a particular line rather than limiting individual guests.

Several more caps override the defaults above for a specific case: a data plan's own speed (sold at a certain price point, capped to match it), an internal account's own cap (0 falls back to the tenant default), a resident-issued guest voucher's visitor speed cap, the resident-guest-voucher fair usage policy's throttle speed once a resident's vouchers cross their monthly threshold, and the broader fair usage policy for all paid & earned access's own throttle speed (with its own optional per-plan/per-voucher/per-tier overrides) once any bundle crosses its rolling 24-hour threshold. In every case, 0 (or an empty field) means uncapped at that level, falling through to whichever broader default applies above it.

One thing no per-guest cap ever touches: traffic to your own captive portal itself — the login screen, Home, checking My Usage, buying a data plan — always loads at full speed, even for a guest whose general browsing is currently capped. A slow connection to your own portal would make it harder for a capped guest to buy more data or watch ads to top up, which defeats the point of capping them in the first place.

Every cap above is a fixed number you set once. Fair Share bandwidth is the alternative for a router where no single fixed number feels right for every crowd size — it automatically re-divides that router's real capacity evenly across however many guests are actually online at any given moment, instead of you picking one Mbps figure that's generous when it's quiet and not enough when it's busy.

Optional, off by default — if your ISP line has a monthly data cap, set it under Network → Routers alongside your monthly cost and which day your billing cycle starts on, and this projects whether you're on track to hit that cap before the cycle resets, based on real usage tracked at each router so far this cycle. A simple projection (your average GB/day so far, carried forward to the rest of the cycle), not anything more sophisticated — it's a heads-up, not a guarantee. Leave both fields blank to leave this off entirely; nothing is tracked or shown until you fill them in.

You'll get one email per billing cycle, the first time your projection crosses 75%, 90%, or 100% of your configured cap — not a repeat every day you're still over it. Turn it off entirely under Notifications (Bandwidth cost forecast) if you'd rather just check the dashboard yourself.

On each router's own management page, alongside its speed settings — reduces that router's WiFi broadcast power to keep coverage closer to your venue: dense buildings with shared walls or neighbouring shops, or simply stopping people outside on the street from connecting. This is a reduce-only control. Values are hard-capped at South Africa's ICASA license-exempt ceilings — 20 dBm (100 mW) on 2.4GHz, 30 dBm (1 W) on the common 5GHz WLAN bands (5150–5350 MHz and 5470–5725 MHz) — verified against the ICASA Radio Frequency Spectrum Regulations 2015, not assumed. You can never save a value above these, regardless of what the router's own hardware might technically support higher than that: staying under these ceilings is what keeps operation license-exempt in the first place, not a separate compliance step layered on top.

Leave either field blank to keep that radio at its own hardware default (full power) — nothing changes on a router until you actually set a value, and the two bands are independent (you can lower 2.4GHz while leaving 5GHz untouched, or vice versa). Automated for MikroTik (covers both RouterOS generations, since which one a given router runs isn't something we can detect in advance) and OpenWRT-family routers (Teltonika, GL.iNet, generic OpenWRT); not yet verified against real hardware for either.

On by default for every router with a WiFi name configured — nothing to turn on, nothing to set up. Every 30 minutes, the router itself briefly scans the airwaves for nearby WiFi networks and checks whether a DIFFERENT device is broadcasting the exact same network name yours is configured to use. That's the standard "evil twin" attack: someone sets up their own access point using your hotspot's name (sometimes copying the login page too), so guests connect to them by mistake and everything they type goes straight to the attacker instead of you. If one is heard, you get an automatic email the moment it's detected — the same way a router going offline or a firewall tamper event already alerts you.

Worth being precise about what this does and doesn't do: it detects and alerts — it does not, and cannot, shut the rogue device down itself. No software running on your own network can reach out and silence someone else's radio; that's true of every WiFi security product, not a limitation specific to this one. What it actually fixes is the much more common failure mode: most evil-twin attacks succeed simply because nobody ever notices one is happening. Once you're alerted, the response is on you — walk the venue for an unfamiliar device, or escalate further if it doesn't stop.

A short (a few seconds) disconnect blip is possible for guests on the affected router during each scan — the radio briefly has to leave its own channel to listen for others, the same tradeoff real enterprise wireless-security hardware makes. That's why this runs every 30 minutes rather than the same 5-minute cycle as router-offline checks, and why each scan is kept short. A repeat sighting of the same rogue device only alerts once, not every 30 minutes it's still there — you'll be alerted again if it disappears and comes back later. Automated for MikroTik and OpenWRT-family routers; not yet verified against real hardware for either.

Direct command access to a paired router for diagnostics and one-off fixes, without needing physical or SSH access to the hardware yourself. Re-enter your dashboard password to unlock it, choosing how long the unlock should last (2, 5, 15, or 30 minutes) — after that it locks again automatically. Every command you run is logged with a timestamp, the router, the command itself, its status, and its output, kept as a permanent audit trail against your account, since this is the kind of tool that can take a whole site's WiFi offline if used carelessly. Restarting a router is a separate one-click action elsewhere (no CLI unlock needed) — expect it to be briefly unreachable, about a minute, while it comes back up.

Two related things live in this one section: Fair Pause itself (protecting guest access time from outages), and NOC-style alerting so you actually find out about an outage as it happens, not from a guest complaint.

Outage alerting. The moment any router stops reporting in, and again the moment it comes back, you get an automatic email — the same "router offline"/"router back online" alert this platform has always sent, checked on a 5-minute cycle and sent only once per outage, not repeated every check while it's still down. Turn on "Also SMS me when a router goes offline or comes back online" below if email alone isn't reliably getting your attention — real NOC/ISP behaviour, using your own SMS credits, off by default since not every tenant wants an SMS for every blip. Every outage is logged in the "Outage history" table below (which router, when it went down, when it came back, how long it lasted, and how many guests had access time restored) — a durable record survives a server restart, so a redeploy mid-outage never causes a duplicate or missed alert for the same event. Texting your guests (optional). A second tick box, "Also text guests who have access running on that router", sends a short SMS to the guests who are affected right now: only people with access still running on the router that went down (a paid data plan, an ad, voucher or POS grant with time left, or an active subscriber whose device is on that router). Guests whose access already ended, resident or internal accounts, guests on your other routers, cancelled or paused subscribers and email-only guests are never texted, and each guest gets one text per outage (up to 150) and never more than one in any 6 hours, so a router that keeps flapping cannot spam anyone. The wording follows Fair Pause: when Fair Pause is on, guests whose time is protected are told it is paused and will be added back once the router is online again; subscribers, and every guest when Fair Pause is off, get a plain "we are working on it" notice that makes no promise. The texts use your own SMS credits (a message to a number in the other supported country costs more credits), stop if your credits or daily SMS limit run out, and are off by default. Each outage records how many guests were texted.

Opening hours. Under Network → Opening hours you can set, per weekday, when your WiFi is open (or tick a day Closed), and an optional message for guests. Outside those hours nobody can start new access: watching an ad, a survey unlock, buying a data plan and redeeming a voucher are refused with the closing message and the next opening time, and your captive page shows a full "closed" page in place of the login and home pages. What it deliberately does not do: it never cuts access a guest already has (they paid or earned it, it runs until it ends), and it never blocks a payment already in progress, a balance top-up, a subscription or a payment confirmation from the payment provider, so nobody is charged without being given access. A closing time earlier than the opening time means the WiFi stays open past midnight (18:00 to 02:00). Times are South Africa / Namibia time (UTC+2, no daylight saving). The dashboard preview is never blocked. Leave the setting off to be open all day, every day.

Fair Pause protects guests from losing paid access time to something outside their control: when a specific router loses power or connectivity (load-shedding is the common case in South Africa, but any outage counts) and comes back later, any guest whose paid time-based access was tied to that exact router — and who still had time left when it went down — gets their access clock frozen for the length of the outage, then resumes exactly where they left off. A guest with 4 hours remaining when the power cuts, and a 3-hour outage, still has 4 hours remaining once it's back — not 1. This is scoped strictly to the one affected router; guests connected to your other routers are completely unaffected, even routers at the same site.

Data-bundle (MB) access needs no special handling and isn't affected by this setting either way — remaining data only ever decreases from bytes a router actually reports using, so a router that's offline physically can't report anything, meaning data usage already stops accruing on its own during an outage.

Covers ad-watch unlocks, purchased/redeemed vouchers, data-plan purchases, POS (till) sales, and API-granted access — anything that represents real revenue or genuine guest-earned access. Resident and internal-account-issued vouchers (the ones you or a landlord/manager hand out directly, not something a guest earns or buys) are deliberately excluded — this protects paying and ad-supported guests specifically, not every access grant on the platform.

Built-in protection against double-crediting: if an affected guest connects to a different one of your routers during the outage and keeps browsing there, they've already continued their session — when the original router comes back online, they don't also get time credited back on it. A guest who had nothing left when the outage started gets nothing back either, same as normal expiry.

On by default for every tenant; turn it off under this section if you'd rather access simply expire on schedule regardless of router outages. Detection rides the same outage check used elsewhere in the platform, on a five-minute cycle — so the credited freeze time can run a few minutes short of the true outage length, never longer. On a load-shedding-length outage that's a rounding error, not something a guest would notice.

Full guide: Access Rules, Countries and SMS.

A genuinely different problem from a router going offline: this is a router that's UP but saturated — guests fighting over a pipe that's smaller than what's being asked of it, the plain ISP meaning of "congestion". Each router's real recent throughput (averaged over the last few minutes, not one instantaneous blip) is compared against its real capacity — preferring the router's own hourly ISP line speedtest (see Routers) where available, falling back to its configured router speed cap if not; a router with neither configured has nothing to measure against, so it's simply skipped rather than guessed at.

Cross 90% of that capacity and you get an automatic email naming the router, which direction is saturated (download or upload), the actual Mbps figure, and a suggestion (raise its cap, split load across a second router, or check who's using the most data). It won't fire again for the same ongoing event — usage has to drop back below 75% first (a deliberate gap between the alert and clear thresholds, so a router hovering right at the line doesn't flap between "alert" and "clear" every few minutes and spam you). Off/on toggle lives under Notifications, alongside every other alert type.

A smarter alternative to a single fixed per-guest speed cap. Turn it on for a specific router (from that router's own settings, next to Total line speed) and, once 2 or more guests are actually connected to it, its real capacity is automatically re-divided evenly among however many are online right now — recalculated roughly once a minute. With only 2 guests on, each can burst to roughly half the pipe; the moment a 10th guest joins, it re-splits into 10 shares automatically. This is the same idea behind MikroTik's own PCQ (Per Connection Queue) or the classic Linux SFQ (Stochastic Fairness Queuing) concept, but built at the platform level rather than as a native router feature — which is exactly why it works identically on every router vendor this platform already pushes a per-device speed cap to (MikroTik and the OpenWRT family alike), not only MikroTik.

Capacity to divide up follows the same precedence as congestion alerts: the router's own real ISP-line speedtest where available, otherwise its configured router speed cap. A router with neither set has nothing to fairly divide, so Fair Share simply has no effect on it until one is configured.

Fair Share only ever pulls a guest's speed DOWN toward the fair split — it never raises anyone above what they're already entitled to. A guest on a higher-tier data plan, or one whose fair-usage policy has already throttled them, keeps whichever of the two numbers is lower; it never overrides a plan's own cap upward. A guest who's currently fully uncapped — watching an ad to unlock access, or simply on a tenant that runs an unlimited network by default — is left alone entirely rather than having a cap forced onto them, since that would break an existing guarantee elsewhere on the platform (see Bandwidth & speed caps). As soon as the router has headroom again (a guest leaves, or overall usage drops), any speed reduction Fair Share applied is released automatically on the next check — it's a live rebalancing act, not a permanent downgrade.

Off by default, per router — unlike Fair Pause, this actively changes a connected guest's live speed rather than just sending you a notification, so it's opt-in rather than on for everyone automatically. Worth turning on for a router that regularly has many guests competing for one line and no per-guest cap that feels right for every crowd size; less useful for a router that's rarely near capacity, since it has nothing to rebalance most of the time anyway.

Block specific websites on your WiFi. Nothing is blocked until you turn something on yourself — every option here starts off. Type the domains you want blocked, one per line, re-enter your password the same way as Remote CLI, and save; the rule pushes automatically to every router in your fleet that supports it, applying as soon as each one next checks in. Routers that aren't yet automated for filtering get a manual instruction instead: add a DNS blackhole entry for each domain, and drop the relevant ports at the firewall if you also want VPN mitigation. Speaking of which, an optional "VPN mitigation" toggle blocks common VPN ports and known public DNS-over-HTTPS providers — a genuine deterrent against casual VPN use, not an absolute guarantee; a sufficiently determined, technical user can still find a way around any network-level filter, true of every vendor's product, not just this one.

Three one-click category toggles — adult content, gambling, malware & phishing — save typing domains out by hand for the common cases. Each is a starter list (roughly 150 known domains, sourced from a maintained open-source blocklist) rather than an exhaustive database — genuinely useful, not a claim to catch everything. Category domains combine with anything you type manually, capped at 500 domains total per router (the same ceiling manual entries alone already had) so a router's own DNS resolver never gets asked to hold more than it reasonably can.

Protect minors from adult content is a different kind of rule from everything above it on this panel: those apply to every device on the router equally, this one targets WHO is browsing. Turn it on and set an age (default 18), and any guest under that age gets their device's DNS transparently redirected to a third-party family-safe resolver (CleanBrowsing) instead of the router's normal DNS — an adult guest on the exact same router at the exact same time is unaffected. It reads each guest's existing date of birth (the same field Dashboard home's age-restricted signup and age-targeted ads already use) — a guest with no date of birth on file is treated as under the limit until they provide one, the same fail-closed approach used elsewhere for age checks. Off by default, same as everything else on this panel. Automated for MikroTik (a self-expiring rule, refreshed for as long as the guest stays connected) and OpenWRT-family routers (Teltonika, GL.iNet, generic OpenWRT — a heavier push per guest since OpenWRT has no equivalent self-expiring mechanism, so it's refreshed less often and cleaned up automatically once a guest's device goes quiet); not yet verified against real hardware for either vendor family.

Allow extra domains before login (walled garden) — separate from blocking above, this is about what a guest can reach before they've even logged in. A fixed set of domains is always allowed pre-login on every router, automatically, and can't be turned off here: payment gateways (so a guest paying by card or QR to unlock never gets stuck mid-payment), known ad-hosting CDNs (so a video/image ad can actually load and play before someone's earned free access), and the handful of domains phones and laptops check to pop up the "sign in to this network" prompt in the first place. Type extra domains in the box at the bottom of this panel if your own setup needs something else reachable pre-login too — a custom ad network, an embedded booking widget — one per line, wildcards like *.example.com allowed. It's additive only: you can add to this list, but you can never remove or override the protected baseline, so this feature can't accidentally lock your own guests out of paying or unlocking. Saves and pushes to your routers the same way the rest of this panel does — no separate step. Automated for MikroTik and OpenWRT-family routers; not yet verified against real hardware.

Built for bigger sites — hotels, malls, campuses — where one gateway router isn't the whole story: it's got a fleet of switches and access points behind it via a bridged LAN. Wiring-wise, nothing changes — guests are already caught by the gateway's own captive-portal redirect no matter how many switches or APs sit between them and it, as long as the network is properly bridged (same VLAN/subnet, trunk ports, APs backhauling to the gateway's LAN). What this adds is visibility: register each switch/AP under a "Network topology" section — its name, type, which gateway router it sits behind, an optional parent device if it's nested deeper (AP behind a switch, say), its LAN IP, and its SNMP read-only community string (SNMP is off by default on most switches/APs, so this is a real onboarding step, not just a form field — check the device's own admin page to turn it on and set a community string first). The gateway router's own agent does the polling — it's the only thing already on that LAN with a working channel back to the platform — walking each registered device over SNMP every 5 minutes for up/down status, latency, switch port traffic, and (best effort; AP client-counts are often vendor-proprietary rather than a standard MIB, so treat that number as approximate) connected client count, then relaying the results up the same way the existing ISP line speedtest already does.

The topology view is a simple indented tree — gateway at the top, its switches/APs nested underneath — with each device's status dot, and a health-score strip showing how many are online right now. Click into any device for its own 90-check uptime history (the same bar visualization used on the public status page) and, for switches, a per-port traffic table. One distinction matters here: a device shown gray with "no data" is different from one shown red as confirmed offline — gray means its own gateway router is currently unreachable, so the poller itself has nothing to report, not that the device is necessarily down; red means the gateway heard from it before and now can't. Offline alerts (opt in under Notifications, alongside the router-offline ones) follow the same logic — a switch/AP behind an already-alerted offline gateway won't also fire its own alert, since that's the gateway's alert to send, not two confusing emails for one outage.

Connect a controller (new, beta) skips manual per-device SNMP entry entirely for three ecosystems: UniFi, Omada, and Ruckus. Paste a UniFi Site Manager API key (generate one at unifi.ui.com under Settings → API Keys — this is Ubiquiti's own cloud API, so it works even if your console has no port-forward), an Omada Controller's Open API credentials (Settings → Platform Integration → Open API in the Controller — a different, more privileged credential than the one used for guest hotspot login), or a Ruckus SmartZone controller's own URL and admin login, pick which of your routers the discovered devices should nest under, and save. Every switch and access point the controller reports is discovered, added, and kept in sync automatically on the same 5-minute cycle as SNMP — no community string, no per-device form. A device the controller stops reporting (unplugged, removed from the site) is deactivated automatically rather than left stale, the same way a manually-removed device is. This is newly built and, unlike the SNMP path above, not yet verified against a real controller of any of the three — a wrong credential or endpoint fails as one clear sync error on this page rather than silently, and "Sync now" lets you check immediately instead of waiting for the next cycle. Ruckus covers access points only for now, not switches; for a SmartZone controller, the URL you paste needs to include the port and API base path your specific model/firmware uses (Ruckus publishes this per-version, not as one stable address).