Networking & the Perimeter

A Mac that runs services lives inside a network, and that network is where most real-world trouble starts: a router whose WAN link flapped, a forgotten device on the wrong subnet, a port you opened months ago and never closed. FrontierStack treats the network and its perimeter — the boundary between your LAN and the internet — as first-class objects. It reads your router directly, scans the LAN to build an inventory, draws a data-flow map, and gives you several disciplined ways to expose a service to the outside.

This chapter covers the network around your servers. For linking the servers themselves over SSH see Chapter 8; for the host firewall, fail2ban and the security audit see Chapter 10; and for Cloudflare DNS and TLS see Chapter 7.

9.1Routers & firewalls you can read and drive

FrontierStack talks to network gear through its own management API where one exists, and over SSH where it does not. The two tightest integrations are OPNsense (its full REST API) and Cloudflare (covered in Chapter 7); a wider set of routers and firewalls report live status. Add a device in the Router & Network pane with its address, vendor and API key, and the AI Administrator's router_info tool can then read its version and model, uptime, CPU and memory, WAN links and gateways (up or down), interfaces and client count — plus the raw API JSON for any field FrontierStack does not map. It is read-only: it queries the device's own API, never SSH.

Huawei LTE/5G routers. Pin a Huawei B-series, E5186/E5785 or 5G CPE (H112/H122/H138) with the Huawei LTE/5G Router (HiLink) platform (default address http://192.168.8.1). Check Status reads the router's own web API: the connection, 4G or 5G network, operator, signal (RSRP, RSRQ and SINR, with a plain rating) and Wi-Fi clients without a password; model, firmware and full signal detail once its web password is in Access. Monitor the mobile connection raises an alert when mobile data drops — useful when the router is a backup WAN that nobody looks at until the fibre fails. These routers allow only one or two web sessions and lock their page after repeated failed logins, so FrontierStack signs in at most every 10 minutes (every sweep on a model that hides even its status page), always signs out, and stops retrying a refused password for 30 minutes. Huawei Wi-Fi routers, fibre ONTs, VRP gear and AirEngine access points have their own platforms, which set the right web UI, SSH user and notes. Discovery recognises Huawei product names and suggests the platform.

For OPNsense and pfSense, an API key unlocks a continuous firewall monitor (the toggle in the pinned device's pane): every Alerts sweep polls the firewall itself for gateway state, interface carrier and service liveness — so a WAN line that dies while a multi-WAN router silently fails over (servers browse fine, inbound to your sites is dead) raises an alert naming the gateway and the port that lost carrier, instead of an unexplained sea of red site dots. Nothing is installed on the router: OPNsense's REST API is built in, and pfSense needs only its REST API v2 package. The same pane can also join an OPNsense router to your tailnet: sign in to Tailscale on your Mac (Google accounts work), mint a pre-auth key, paste it in the device pane's Tailscale section — FrontierStack installs the os-tailscale plugin if needed, saves the key and login server (Headscale too), and restarts the service over the API, no browser login on the router required. The tailnet address is then remembered as a fallback: when the LAN address stops answering (off-site, VPN route down, LAN leg dead), Check Status, the monitor and certificate renewal retry over Tailscale automatically and say so, and the monitor raises a separate "LAN address" alert so a routing fault is not mistaken for a dead router.

Attack and failure signals. The same sweep that watches gateways also watches for trouble on the router itself, and a router in distress turns orange with a warning triangle in the sidebar — hover for the reason. On OPNsense with the Intrusion Detection plugin enabled, FrontierStack reads its recent Suricata alerts over the same API and shows the count and top signature (an attempted attack surfaced without opening the firewall UI; pfSense's REST API does not expose IDS uniformly, so this is OPNsense-only for now). Across every monitored router — OPNsense, pfSense, OpenWrt and the rest — each sweep also flags an unexpected reboot (uptime dropped sharply: a crash, a power event, or an attack), a brute-force spike on the router's admin/SSH (repeated failed logins, with the busiest source IP named from the router's own log), resource stress (memory or load dangerously high — a DoS, a runaway or compromised process), and an available firmware update (outdated firmware means known holes). Each raises an alert; signals a given platform cannot report are simply skipped, never a false all-clear. OPNsense and OpenWrt report the most; pfSense's API is more limited.

Certificate expiry. The same sweep reads the firewall's trust store — every CA and certificate a service uses — and raises an alert a month before one expires, and again once it has. This is the failure nobody plans for: an OpenVPN server certificate issued on OPNsense's 397-day default quietly locks every remote user out a year later, and the Web GUI's own HTTPS certificate lapsing turns the admin page into a browser warning. The device pane lists them soonest-first with a coloured dot, and a Renew… button reissues a certificate in place through the router's API: same private key, subject and CA, a lifetime you choose (up to ten years), and optional restarts of the OpenVPN servers and the Web GUI so they load it. Because the key and subject are unchanged, existing VPN client profiles keep working — nothing to re-export. On pfSense the REST API's renew action does the equivalent and restarts dependent services itself, and because its API reports no expiry for certificate authorities FrontierStack reads that date out of the CA certificate itself, so a pfSense CA warns like any other. CAs cannot be renewed through either API; an expiring CA is announced early precisely because replacing it means re-signing certificates and redistributing client profiles. The OpenVPN service pane shows the same router certificates next to the CA and client certificate embedded in every .ovpn profile on the Mac (OpenVPN Connect, Tunnelblick, the last file used), so client and server expiry sit side by side; its Plan & Cost card also notes that OpenVPN itself is free and what Access Server and CloudConnexa charge.

Driving and diagnosing a router. The AI Administrator can now do more than read: reboot_router restarts an appliance the same way it reboots a server (OPNsense/pfSense via API, OpenWrt over SSH), gated behind "Allow changes"; and when a task is genuinely better done in the router's own console, the assistant offers to open its Web UI with open_web_ui, resolving the address from the device pane rather than guessing. FrontierStack itself deliberately does not edit these appliances' firewall rules — OPNsense/pfSense/OpenWrt manage rules through their own config system, so the pane and the assistant point you at the native firewall page instead (right-click a router ▸ Open firewall rules… deep-links it). Two pane conveniences round this out: a Diagnostics button runs an API-free reachability check (ping, the common admin ports 80/443/8443/53, reverse DNS, gateway) so you can triage a router even without an API key; and for a router or firewall, Discover Services offers to open the Web UI rather than port-scanning it (a scan of your own perimeter device is rarely what you want). If SSH to an OPNsense or pfSense box is refused, SSH is either disabled or — more often — only allowed on certain interfaces (commonly the LAN, not the WAN): reaching it over the LAN, e.g. through a VPN, usually works, while from outside it is typically blocked. Enable SSH and its listening interfaces in the web UI (System ▸ Settings ▸ Administration ▸ Secure Shell on OPNsense). The SSH button itself is only hidden for consumer gateways that have no admin shell at all (NTT, some TP-Link/FRITZ!Box), where the Web UI is the only way in.

9.2Firewall vitals, graphs and power

A pinned OPNsense, pfSense or OpenWrt firewall with monitoring switched on reports its own vitals through its API, and its pane now graphs them: CPU and memory on one 0–100 chart, load average, and temperature. The samples come from the monitoring poll that was already running, so the graphs cost no extra API calls and fill in as the Alerts sweep proceeds, covering roughly the last six hours of the session.

What each platform gives differs, and the pane shows only what is real: pfSense reports an instantaneous CPU percentage, while OPNsense reports load average instead. Temperature depends on the hardware exposing a sensor FreeBSD can read — many virtualised and ARM installs have none, so a missing figure means "no sensor", not a fault.

Any pinned device can also have a smart plug linked to it, exactly as servers do: On, Off, Power-cycle, and a live wattage reading where the plug meters it. This matters most for a firewall, because it is the one box you can never reach over SSH when it wedges — the network you would reach it over is the one it serves. Neither OPNsense nor pfSense reports its own power draw (FreeBSD exposes thermal sensors, not watts), so a metered plug is the only real power figure available for one. Power-cycling asks for confirmation and warns that every connection through the firewall drops; try the API reboot first.

An OPNsense firewall linked through its API also reports the PHP its firmware installed. OPNsense’s web GUI runs PHP as root and its captive portal serves PHP pages to guest devices, so this is PHP on your perimeter. FrontierStack reads the version from the firmware package list with the daily firmware check and compares it with php.net’s latest release of that branch. The firewall’s security rows warn when it is behind a security release or on a branch that no longer gets fixes, and say what to do: update through System ▸ Firmware ▸ Updates once OPNsense ships a release with the fix, and until then keep the GUI reachable from trusted networks only. Never install PHP packages on the firewall by hand.

9.3Traffic, usage spikes and possible unauthorised use

A monitored router also reports its WAN traffic. On every Alerts sweep FrontierStack reads the cumulative byte counters it already exposes — OPNsense interface statistics, pfSense interface rows, OpenWrt device statistics, MikroTik RouterOS interfaces, a Huawei HiLink router's mobile-data totals — and turns the difference between two readings into a rate. The WAN interfaces are summed (every internet byte crosses one of them exactly once); where no WAN can be identified the busiest interface stands in, and the pane's Measured on line says which was used. A UniFi console reports its gateway's current uplink rate instead of counters, so its daily volumes are estimates. Hourly volumes are kept for about 60 days on this Mac.

The router's pane shows the rate now against the usual rate for this hour, today's volume against the usual day, the number of connected devices where the router reports it, a six-hour rate chart and a two-month bar chart of daily usage. Two alerts are built on it, both on by default with conservative thresholds; each has its own switch and a Conservative / Balanced / Most sensitive menu.

The long-term alert is the one to take seriously. Someone quietly using your connection — a neighbour who learned the Wi-Fi password, a guest network left open — adds traffic every day without ever producing a spike, so the alert reads possible unauthorised use, compares connected devices with their usual number, and points you to the connected-devices list and to Change Wi-Fi Password… (see Changing a Wi-Fi password across many routers). If the new level is expected, Accept as New Normal restarts both baselines from the last few days; Use Full History undoes it.

9.4Device Discovery: an inventory of your LAN

Open Device Discovery and press Find Monitors (or pick a subnet first). FrontierStack sweeps the chosen /24 using every method available at once, so routers, access points, switches, NAS boxes (Synology, QNAP, ZimaCube/ZimaOS…), printers, cameras and other servers all surface:

• Ping / ARP — an ICMP sweep, with ARP/MAC giving each host's vendor; turn on TCP Probe to find hosts that filter ICMP.
• Bonjour (mDNS) and SSDP / UPnP — advertised services and their friendly names.
• SNMP and LLDP / CDP — add model, port and neighbour details when net-snmp and lldpd are installed (buttons in the pane install them).
• Windows service ports — a machine that filters ICMP is still found by probing its distinctive ports (RDP, WinRM, SMB and friends), so Windows PCs no longer hide from the sweep.

The scan also notes how each host can be reached. An AnyDesk badge appears when AnyDesk is running locally or answering on its default port 7070, and a Tailscale badge — green when the peer is online — is built from this Mac's own tailscale status, matching mesh peers to discovered devices (only endpoints, hostnames and OS are kept; login names are never retained). On a directly-connected LAN, the Macs and devices macOS already knows through Bonjour appear before the slower IP sweep, so the list fills in quickly. A device's detail view carries matching AnyDesk and Tailscale rows with an Open app shortcut.

Devices from earlier scans. A scan starts with the devices it remembers from the last 90 days on this network and marks any that don't answer as Expected · not yet seen. To drop one that has gone for good, choose Forget This Device from its ⋯ menu once the scan has finished. It leaves the list and the scan history, though a device that answers a later scan is found again.

A router pinned by another address. A firewall has a different address and hardware address on each network, so the gateway a scan finds may not look like the OPNsense you pinned on another interface. Once its API key is set, FrontierStack saves the interface list OPNsense reports, and a scan row with one of those hardware addresses shows as Pinned as that router. Other router brands aren't matched this way yet.

The Wi-Fi unit you're connected through. The device this Mac's Wi-Fi is associated with is marked as an Access Point with a This Mac's Wi-Fi badge, using the radio address (BSSID) macOS reports, which needs Location access. A wireless bridge often has no address on the subnet it carries; its row then says No address on this subnet and can't be pinned or monitored until you add its management address by IP.

To pin tailnet devices without scanning for them, open the Tailscale service pane: Tailnet Devices lists every device on your tailnet as this Mac's Tailscale sees it (no API token needed; it falls back to the Tailnet pane's API list when Tailscale isn't connected here). It also finds each device's LAN (Wi-Fi/Ethernet) address — from a direct Tailscale connection, tailscale ping, the Tailscale API or Bonjour. Devices you've already pinned, or that are already in your servers, are marked and open with a click. Macs and servers get Add to Servers (the same place Device Discovery files them); everything else gets Pin. A device on this Mac's network is added at its LAN address and is still watched over its tailnet address when you're away; one elsewhere is added at its tailnet address. A Mac, Windows PC, server or NAS also joins Servers on its own when you pin it or change its type to one of those, carrying over its MAC address, vendor, icon, colour, power and UPS links, saved password, location and sidebar group; Open in Servers in its Identity section jumps to that entry.

A router on a LAN you reach through another tailnet device's subnet route answers pings, but over the tunnel there's no hardware address to prove which router answered — two sites can both have a 192.168.1.1 — so it stays offline until you vouch for it. The router's pane shows a Tailscale Subnet Route section naming the device that routes its subnet; click This router is on …'s network and from then on an answer through that route counts as online. Only one pinned router per address can hold a given route.

The AI Administrator's discover_devices tool runs the same scan and auto-pins the devices whose type it can identify confidently. Anything ambiguous is listed back rather than guessed at, so the assistant can ask you what it is and then pin it with pin_device. A pinned (monitored) device appears in its type's sidebar section; double-click it to open its pane, or use Open Web UI, Discover Services, Reclassify or Remove from its row. If you already know an address, the Add a device by IP field probes and pins it directly — no full scan needed.

Pin without waiting for the scan. A row that is already identified with high confidence shows Pin while the sweep is still running, and Review & Pin… lets you choose the type for one that isn't. A device pinned mid-scan stays pinned, and when the scan finishes (or you press Stop) its pinned record picks up whatever the rest of the scan learned. To look closer at one device instead, press Stop — the rows found so far stay — and choose Identify & Pin from its Review & Pin… or ⋯ menu: FrontierStack fingerprints just that address and pins it if the result is confident, or leaves it for you to review with the fingerprint result shown.

Point-of-sale hardware. A Square Terminal or Register opens no ports and doesn’t advertise on Bonjour, so it is recognised by Square’s own MAC address block and listed as Point of Sale. The Square pane’s Hardware section shows it next to the devices Square’s API reports (status, battery, Wi-Fi and IP). Square card Readers connect over Bluetooth and never appear on the network. Star Micronics and Epson TM receipt printers are identified by vendor and model name.

Android TV and Google TV boxes. An NVIDIA Shield, Chromecast with Google TV, Mi Box or onn box is recognised by the Android TV Remote service it advertises and pinned as Android TV / Google TV. With the Android TV / Google TV (adb) platform, Check Status reads its health over adb: model, Android version and how old its security patch is, uptime, storage, memory, whether the screen is on, temperature and the app in front, with warnings for a patch over a year old, storage over 90% full and thermal throttling. Install Google’s platform tools from the device pane, turn on Developer options ▸ USB debugging on the TV and accept the “Allow USB debugging?” prompt once. FrontierStack only reads; an offline alert keeps watch on boxes that drive signage or act as a subnet router.

Chromecast and Google Cast. A Chromecast, or a TV or speaker with Cast built in, is recognised by the Google Cast service it advertises. Its page reads the name, model, Cast firmware, network, uptime, what's casting, standby and volume, with no sign-in and nothing to turn on. Stop Casting… stops the current cast after you confirm. There's no Restart as there is on a Fire TV, because Google keeps that behind a Google account: restart it in the Google Home app, or link a smart plug and use its power-cycle. A Chromecast with Google TV is treated as an Android TV box instead.

Aqara, and Thread border routers. Aqara has no local API, so FrontierStack meets its hardware where it reports. Hubs (M1S, M2, M3, M100, M200) are pinned as smart hubs and show whether they advertise HomeKit, Matter and a Thread border router — turn on the offline alert, because a hub going down silences every Zigbee sensor behind it. Cameras and doorbells stream RTSP on port 8554 once RTSP is turned on in Aqara Home; add them in AV Feeds with the vendor Aqara. The FP-series presence radars (FP1, FP1E, FP2, FP300, FP400) report through Zigbee2MQTT, where they are named by product and show presence, light, temperature, humidity and a low-battery alert, or through Home Assistant, whose pane groups them into one row each. Any device advertising itself as a Thread border router gets a Thread badge with its network name, and an Apple TV’s pane says whether its model has a Thread radio at all.

Apple Home hubs. A HomePod or Apple TV that is a home hub gets a badge beside its name in Device Discovery: a green Home Hub on the hub running the home right now, Standby Hub on the others, and a plain Hub when this Mac's Home data doesn't record which one is active. Its device pane adds an Apple Home section with the same status, and the Apple Home pane lists every home's hubs. Apple Home picks the active hub itself and can move to another whenever a hub restarts, updates or loses its network; choose a preferred hub in the Home app under Home Settings ▸ Home Hubs & Bridges. FrontierStack reads this from the Mac's own Home data, read-only, and matches hubs to devices by name; if macOS blocks access, grant Full Disk Access in System Settings ▸ Privacy & Security.

9.5Cameras from every maker

The Cameras pane is one status board for every camera FrontierStack knows about, whether or not it can show a picture. It gathers cameras found by Device Discovery (pinned, and found but not yet pinned), AV Feeds streams, SwitchBot cameras, Smart Life cameras and UniFi Protect cameras. With dozens of cameras, the counts at the top and the Offline filter are the quick answer: offline cameras sort first, and a stream whose address matches a pinned camera is shown on that camera's tile rather than twice. A Protect camera with the same MAC address as a pinned camera is shown on that camera's tile. The bell on each tile switches its offline alert, and Alert on All covers every camera that can be checked at once. Alerts go through the Alerts pane, so a contacts preset can page the technician for the site.

A camera counts as alive if it answers on RTSP (port 554), its web port (80) or ONVIF (2020). Cloud-only cameras such as Ring, Nest, Blink and Arlo show no status, because only their own app can reach them.

Tapo cameras from anywhere (unofficial). In Services ▸ Cameras ▸ Tapo Cameras, sign in with your TP-Link ID to see each Tapo camera's online / offline state even when the Mac is away from home, with offline alerts through Alerts. FrontierStack signs in the way the Tapo Android app does, because TP-Link offers no official API — so it can break when TP-Link changes its app, and using it may be against TP-Link's terms. Only status is read. Your password is never stored, a camera counts as offline only after two checks in a row, and if TP-Link's cloud can't be reached the camera shows Status unavailable, never offline. Pinned Tapo cameras keep a green dot off-LAN while the cloud says they are online; other Tapo devices and, with a second sign-in, Kasa devices can be watched too.

SD cards. For Tapo, Hikvision/Annke, Dahua/Amcrest/Lorex, Reolink and Axis cameras, each tile also shows the memory card as the camera itself reports it: SD ✓ 42% used, No SD card, Unformatted, SD card error, or SD — when it isn't known (hover for the reason). FrontierStack asks the camera's own local API, never a cloud, and only while the Mac is on the camera's network; away from it, the last result stays with its time. Checks run every 30 minutes, one camera at a time and at most once per 10 minutes per camera. Non-Tapo cameras use the login from their AV Feeds stream or one you enter in the camera's device pane. Tapo cameras need admin and your TP-Link account password, entered once under Tapo Cameras ▸ Local camera access; it stays in the Keychain and is never sent to TP-Link's cloud. If a camera refuses a login, FrontierStack stops asking it until you fix the login or press Retry, because cameras lock accounts after repeated failures. A camera that can't be reached or signed in to is never reported as having no card. SD alerts are opt-in; nearly full alerts are off by default because most cameras loop-record and are always close to full. eufy, WTW and Eseecloud cameras have no local storage API.

Restarting a Tapo camera. A Tapo camera's device pane has Restart Camera… — the Tapo app's Reboot, sent over the same local sign-in as the SD check and under the same rules: only on the camera's network, with its pinned certificate, and not after a refused login or a lockout. The camera stops recording and streaming for about a minute.

What each make needs:

9.22.1WTW cameras and recorders

Older IP cameras. WTW's own 2018 IP camera manual gives rtsp://ip:554/live/0/main for the main stream and /live/0/sub for the sub stream. Port 554 is the default and can be changed. RTSP is turned on in the camera's web network settings. Current PoE/IP models and NV4-series recorders list RTSP and ONVIF in their specifications. If the path above doesn't connect, add the camera over ONVIF in an NVR app to find its URL.

EAGLE Wi-Fi line. These have no RTSP and no ONVIF. WTW's support site says so for one camera, and the recorder specification lists only TCP/IP, DHCP and P2P. For these, the most you can do is check that the recorder answers on its web port: pin it in Device Discovery as WTW Camera / NVR and turn on its offline alert.

Default passwords. NV4 recorders use 00000000, which becomes wtwjapan after a factory reset. Older cameras use admin with a blank password, or admin/admin. Change them before the device goes on your network.

9.22.2Smart-home clouds

Smart Life (Tuya) devices are read through Tuya's official Cloud API. Create a Cloud project at iot.tuya.com in your account's data center (Japanese accounts use Western America), link your Smart Life account with Devices ▸ Link Tuya App Account, and paste the project's Access ID and Secret into the Smart Life pane. You then see every device's online state and plug power, can switch plugs and lights — each outlet of a power strip separately — and can have any device alert when it goes offline. TESSAN, BN-LINK, Edison Smart, OHMAX and MEAPUXIN plugs are Smart Life devices too; add them to Power Control as Smart Life / Tuya outlets to power-cycle a server. The free trial allows about 26,000 calls a month and must be extended every few months, so FrontierStack checks every 10 minutes.

Minut sensors report noise, occupancy, temperature and humidity in rentals. The Minut pane alerts when a sensor goes offline, when its battery runs low, and when a home has a noise disturbance in progress. Minut opens its API only to accounts it has approved; its help article ties this to the Enterprise plan.

SmartThings, Govee, LIFX, Sensibo and Nuki each have their own pane that lists the account's devices with a status dot: green online, red offline, grey when the cloud didn't say. Turn on the bell next to a device, or Alert on all, to get an alert when it goes offline. Govee, LIFX, Sensibo and Nuki need only an API key or token from the vendor's app or website. For SmartThings, create your own OAuth app once with the SmartThings CLI so sign-in keeps working. A personal access token also works, but it expires after 24 hours. If a key is rejected or a sign-in expires, you get one account alert. If a cloud can't be reached, its devices are left unknown. Neither case is reported as devices going offline. Nuki locks are worth watching in rentals: a lock that has lost its connection can't be opened remotely for guests.

Keypad codes. For a Nuki lock with a paired Keypad, the Nuki pane lists its codes once you press Show Codes, with the digits hidden until you reveal them. You can add a code, change its digits or name, limit it to a date range, certain weekdays or a time of day, switch it off, or delete it. Nuki codes are six digits from 1 to 9 and can't start with 12. The API token needs permission to manage smart lock authorizations as well as to view locks, and each change reaches the lock through its bridge within about a minute. In the SwitchBot pane, a Keypad or Lock Vision row has a Passcodes list: add a permanent, temporary, one-time or emergency passcode of 6 to 12 digits, or delete one. SwitchBot can't edit a passcode and never sends one back in readable form, so to change a code add the new one and then delete the old one, and note the code when you add it. Each of these changes needs a real press, and Touch ID when Human-Presence Approvals asks for it, so automation driving the screen can't hand out door codes. Every change is written to the audit log without the digits.

9.6Phones, PBXes and SIP trunks

VoIP & telephony is part of Full Fleet; on Standard everything below is shown view-only. Device Discovery recognises desk phones and ATAs (Yealink, Poly, Grandstream, Snom, Fanvil, Cisco, Avaya, Mitel, Panasonic, Gigaset, 2N and Algo intercoms…) and PBX appliances and session border controllers (Grandstream UCM, Yeastar, Avaya IP Office, NEC UNIVERGE, Panasonic KX-NS, AudioCodes Mediant, FreePBX and 3CX servers…) and types them IP Phone / ATA or PBX / Phone System. A router with a built-in phone port, such as a FRITZ!Box, stays a router. The device page's VoIP section has Check SIP, which sends a real SIP OPTIONS request, Watch in Alerts, and for a phone an offline alert.

A SIP check proves more than an open port: any SIP answer, even 401 or 404, means the SIP stack is working, while a 5xx answer such as 503 means it is up but refusing calls, and counts as down. Tools ▸ SIP Health Check runs it by hand over UDP, TCP or TLS; a SIP (OPTIONS) watch in Alerts runs it on every sweep, over TLS when the port is 5061. Use it for your PBX, your SIP trunk provider's proxy and your SBC.

The VoIP & Telephony catalogue adds live monitors that alert on what actually stops calls: offline extensions and trunks on Asterisk, FreePBX, PBXact, Issabel and VitalPBX (through a read-only Asterisk REST Interface user, reached over the LAN or a VPN); unregistered trunks, an expired licence or stopped services on 3CX; offline desk phones in Zoom Phone and Webex Calling; and a prepaid balance below your floor at Telnyx, Plivo, Vonage and VoIP.ms.

Japan and Korea. Device Discovery also knows the domestic business-phone makers: Saxa PLATIA, Iwatsu Frespec, Nakayo NYC, OKI CrosCore and DISCOVERY neo, Hitachi NETTOWER, NTT SmartNetcommunity α, IPECS (formerly Ericsson-LG) and Samsung OfficeServ. A brand name on its own is never enough — an OKI printer, an NTT home gateway or a Samsung TV stays what it is. The catalogue adds BIZTEL, MOT/TEL, MiiTel, SoftBank ConnecTalk, KDDI 光ダイレクト, Arcstar IP Voice and the business internet phone services of LG U+, KT and SK Broadband. The BIZTEL monitor reads call history through BIZTEL's API (the 履歴取得API option and an API token) and alerts when unanswered inbound calls in the last hour go over your threshold; it fetches only new calls each poll so it uses little of the account's monthly API allowance, and shows that usage.

9.7The Data Map

The Data Map pane draws a per-location data-flow diagram: where your data lives and how it moves across the devices and services at one site. FrontierStack serialises the location's inventory — the discovered devices, their roles, and (optionally) scanned ports — scrubs it of secrets, and hands it to your subscription Claude through the local claude CLI (not the metered API the in-app harness uses). The reply comes back as a Mermaid flowchart plus a short narrative, rendered offline in the pane; the last diagram for each location is kept, and you can save it to your Obsidian vault as a runbook. Locations themselves are explained in Chapter 8.

9.8Opening a port: UPnP and NAT-PMP/PCP

To reach a service from the internet the classic way, a port on the router has to forward to your Mac. Rather than make you log into the router by hand, FrontierStack can ask the router for a mapping using the standard protocols it advertises:

• UPnP IGD (via miniupnpc) — the common consumer-router method.
• NAT-PMP / PCP (via libnatpmp) — Apple's and the modern equivalent.
• OPNsense — a perimeter rule and port-forward through its API directly.

These tools are installed on demand the first time you use them. A mapping made for a temporary session (see Debug Share) is torn down automatically when the session ends.

9.9Dynamic DNS: following a changing IP

Home and small-office connections rarely have a static IP, so a hostname you point at today's address goes stale tomorrow. The Dynamic DNS pane keeps a hostname tracking your current public IP. Add an entry with a Name, a Hostname (for example myhost.duckdns.org) and the account data for your provider; press Update Now to publish immediately, or turn on Update automatically. You choose whether the updater runs only while FrontierStack is running or permanently as a system service, so the record stays current even when the app is closed. Cloudflare users get a tighter path: a Cloudflare DDNS A record that follows your public IP, driven by the same Cloudflare integration as Chapter 7; a generic interval-based updater covers other providers via an update URL.

9.10DHCP Servers: scopes, leases and failover

The DHCP Servers pane (under DNS, Full Fleet) looks after the servers that hand out addresses on your networks. Pick a linked server and FrontierStack finds whichever DHCP server it runs, over the existing SSH link: the Windows Server DHCP role (read with the DhcpServer PowerShell module), Kea (kea-dhcp4.conf and its lease file), ISC DHCP (dhcpd.conf and dhcpd.leases) or dnsmasq, including the copy inside Pi-hole. On Linux, reading lease files usually needs the server's sudo password saved in Remote Management.

Reservations. On a Windows DHCP server you can add a reservation (scope, IP, MAC, optional name) and remove one; right-click a lease and choose Reserve This Address… to fill the form. FrontierStack never edits Kea, ISC or dnsmasq configuration files: for those, right-click a lease and choose Copy Reservation Line, paste the line into the config, and reload the server.

Reserving a pinned device's address. Devices that change address on every DHCP renewal (cameras that drop off Wi-Fi, a PC after a router reboot) can be pinned to one. In the device's own pane press Reserve This Address…, or ask the AI Administrator, whose tool is dhcp_reservation. FrontierStack uses the device's MAC to find which DHCP server holds its lease. On an OPNsense firewall with an API key, Dnsmasq or Kea is changed through the API and applied straight away. The key needs the “Dnsmasq DNS/DHCP: Settings” or “DHCP: Kea(v4)” privilege, and a Dnsmasq reservation also makes the name resolve locally. A Windows server here is changed with PowerShell. For OPNsense's ISC DHCP and file-configured servers you get the static-mapping path or the config line. Otherwise the router at the device's location gets step-by-step web-UI instructions, because consumer routers such as TP-Link Archer and Deco have no API. Nothing changes until you confirm.

Alerts. Tick Watch in Alerts for a server and it is checked every 30 minutes. You get an alert when the DHCP service stops, a scope reaches the alert level (95 % by default; the pane warns from 85 %), or failover goes partner-down. Change both levels at the bottom of the pane. The AI Administrator reads the same state with get_server_health and area=dhcp.

9.11Tunnels and mesh: reaching in without opening up

The better way to reach a service from outside is to skip inbound ports entirely. A tunnel makes an outbound connection that an outside endpoint rides back in on, traversing NAT with nothing forwarded:

• Cloudflare Tunnel — a Quick Tunnel gives you a public *.trycloudflare.com URL with no account, or a named tunnel for a permanent hostname.
• Tailscale — Serve keeps a service private inside your tailnet; Funnel publishes it to the internet through your Tailscale node.

For ongoing connectivity between machines, a mesh or VPN network gives every node a stable private address wherever it roams. FrontierStack manages the common ones — by API on a router that supports it (OPNsense), or over SSH on a server:

9.22.3Tailnet: the whole-network view of Tailscale

The per-server Tailscale controls live inside each server's own pane and work over SSH: they answer “is the daemon up on this box”. The Tailnet pane answers the questions that span the whole network, which only Tailscale's own API can: paste an API access token (device read is enough — the pane never writes) and it lists every device with its addresses, OS, client version, owner, tags and last-seen time.

What earns the pane its place is the Needs attention list. It surfaces node keys that are about to expire — a scheduled outage, because when a key lapses the device silently drops off the tailnet until somebody re-authenticates it — devices waiting for approval, devices advertising routes nobody approved (the usual reason a subnet is unreachable even though the node is plainly up), and devices that stopped checking in weeks ago. Key expiry and pending approvals also raise Alerts.

9.22.4Self-hosted DERP relays

When two Tailscale or Headscale devices can't connect directly — usually because one side is behind hard NAT — their traffic goes through a DERP relay. Tailscale runs relays worldwide, and you can also run your own derper for lower latency or to keep relayed traffic on hardware you control. The Tailscale DERP Relay pane (VPN ▸ Tailscale DERP Relay) covers both ends:

• This Mac's view. From the local tailscale netcheck: whether UDP works, whether the network has hard NAT, the home region and the latency to each region, any self-hosted regions in the tailnet's DERP map, and which peers are relayed through DERP right now rather than connected directly or through a peer relay.
• Your relays. Each derper you add is checked without credentials — HTTPS /derp/probe, that the DERP handler is on, the certificate's expiry, and a real STUN binding on UDP 3478 — and raises an Alert when it stops answering or its certificate is within 14 days of expiry.
• Put it into service. For each relay the pane generates the commands to run it (go install tailscale.com/cmd/derper@latest, optionally with -verify-clients so only your tailnet's devices can use it), the derpMap block for the tailnet policy file, and a DERP-map file for Headscale.

9.22.5An Apple TV as the way in: reaching a locked ISP router

ISP-supplied routers, such as NTT's XG-100NE and other FLET'S home gateways, can't run Tailscale or a VPN, and their settings page answers only on the LAN. On an IPoE line (MAP-E or DS-Lite) there is no usable inbound IPv4 port either, so port forwarding and a classic VPN server are out, and static routes only steer traffic inside the network. The answer is an always-on device behind the router running Tailscale as a subnet router. It makes only outgoing connections and exposes nothing to the internet, and an Apple TV already plugged in to the TV is an easy choice.

1. On the Apple TV, install Tailscale from the App Store, choose Install VPN Configuration and log in by scanning the QR code.
2. Turn on the app's subnet router option and enter the LAN, e.g. 192.168.1.0/24.
3. In the Tailscale admin console's Machines list, open the Apple TV's ⋯ ▸ Edit route settings…, tick the range and save; in the same menu, Disable key expiry.
4. From anywhere on your tailnet, open the router's LAN address, e.g. http://192.168.1.1.

Make the Apple TV a home hub so it stays reachable while asleep, use Ethernet where the model has a port, and test a power-cycle before you leave, because tvOS updates restart it unattended. Give the home LAN an unusual range (on NTT gateways, Web設定 ▸ LAN設定) so it doesn't collide with the 192.168.1.x network you connect from. tvOS has no SSH, so FrontierStack can't configure the Apple TV itself; the Tailnet pane shows whether it's online and flags routes still waiting for approval.

9.22.6Running your own ZeroTier controller

ZeroTier's client is only the member side; networks are normally administered at my.zerotier.com. But every zerotier-one install can also be the controller for its own networks — fully self-hosted, no third party holding your membership list — and that path ships with no local administration UI at all. The ZeroTier Controller pane is that missing interface.

It shows the controller's identity and the networks it owns, and works the member-authorisation queue with one-click authorise/deauthorise. Members authorised but unseen for a fortnight are flagged, because an unused grant is a standing hole in the network. You can edit a network's name, privacy, routes and IP assignment pool, and write flow rules in ZeroTier's own rules language — compiled locally as you type, with templates for the common cases and a warning before you save a rule set that would lock everybody out.

Everything runs over SSH against the controller's own loopback API. The controller listens on 127.0.0.1:9993 and authenticates from a root-readable token, so FrontierStack never needs — and actively discourages — a publicly reachable controller API; the built-in audit flags it if one has been exposed anyway, along with loose file permissions and a missing backup. There is also a Prometheus export, a warm-standby backup/restore, and an assistant for migrating networks out of ZeroTier Central.

9.12UniFi: Cloud Gateways, Dream Machines and Superlink

Ubiquiti's consoles get their own pane, because a UniFi gateway is doing more than a generic router probe can see. It covers the console families alike — a Dream Machine (UDM, UDM Pro, UDM SE), a Cloud Gateway (UCG-Ultra, UCG-Max, UXG), a Superlink gateway, a Cloud Key or a self-hosted controller. The UniFi pane speaks both of Ubiquiti's APIs, and they answer different questions. A Site Manager key — one key, created at unifi.ui.com — lists every console on your account with its model, firmware and online state. That is the only way to learn a remote site has lost power or its internet connection, because a console that is off the network cannot tell you anything locally. A local console key, created on the console itself under Settings ▸ Admins & Users, unlocks what the gateway is doing right now.

Locally the pane shows WAN links with their ISP, latency and throughput, and marks which link is actually carrying traffic. That last detail matters: when a primary line drops, UniFi fails over silently to the backup, which is usually slower and often metered, and the normal way people discover this is the following month's bill. It also lists adopted devices and their firmware, firewall rules in the order the gateway evaluates them, the client list, and every port forward. Each enabled forward is a deliberate hole through the firewall, so the pane flags the ones that accept connections from any source address — correct for a public web server, worth a second look for anything else.

Alerts cover a console dropping offline, a WAN link going down, running on the backup link, a device leaving the network, and internet-exposed port forwards. The pane is deliberately read-only: rule and network changes stay in the UniFi console, where their validation lives. PoE switch ports are handled in the next section, and plain console reachability still appears in Router & Network alongside the other vendors.

The Site Manager key also lists UniFi Protect cameras and doorbells, read at most every five minutes. Tick Alert on a camera, or Alert on all Protect cameras, for offline alerts. A camera that is updating, or whose console is itself offline, is shown as unknown rather than down.

9.13Changing a Wi-Fi password across many routers

When a Wi-Fi password leaks — a departing employee, a password printed in a guest room, a network someone is quietly using — the fix is a new password on every router and access point that broadcasts that network, at once. Change Wi-Fi Password… (Router & Network ▸ Routers, or the Wi-Fi Analyser) does that in one pass. It is a Full Fleet feature. FrontierStack signs in to each pinned router, lists the networks it broadcasts and ticks the ones that broadcast the network you choose. Type a new password or press Generate for a random one that is easy to read aloud, then confirm. The routers are changed one at a time; the one acting as this Mac's gateway goes last, and each row reports what was changed.

Only personal (WPA2/WPA3 pre-shared key) networks are changed. Enterprise, open and uplink (station) networks are left alone, and a RouterOS security profile that another network also uses is refused, because changing it would change that network's password too. Afterwards Rejoin This Mac reconnects this Mac, Show Join Code displays a QR code phones can scan, and Select Failed to Retry re-runs only the routers that failed.

9.14Power over Ethernet: the power button for devices that have none

Access points, cameras, door controllers and desk phones have no power switch. Their only supply is the switch port they are plugged into, which means the recovery move for a wedged one — power-cycle it — normally involves a vendor web UI, or a walk to the cabinet.

The Power over Ethernet pane makes the port the button. Add a managed switch by IP and you get, per port: its PoE state (delivering power, searching, fault), powered-device class, priority and wattage where the switch reports it — plus power off/on and a proper power cycle. It also shows the switch's power budget: total watts, watts in use, and a warning when you cross the switch's own usage threshold, past which it starts shedding low priority ports — so port priority is editable here too.

This works broadly because PoE is standardised: RFC 3621's POWER-ETHERNET-MIB is implemented by essentially every managed PoE switch — Cisco, Aruba/HPE, Netgear, TP-Link/Omada, Ubiquiti, MikroTik, D-Link, Zyxel. Reading uses the SNMPv2c or SNMPv3 profile from Device Discovery. With SNMPv2c, switching a port needs a separate read-write community, added per switch and kept in your Keychain. With SNMPv3, it uses the authenticated profile only when that user has write permission on the switch. Cutting power deserves deliberate access and confirmation; FrontierStack does not expose arbitrary OID writes. With Monitor on, a port in fault state or a switch over its power budget raises an Alert — both otherwise stay invisible until someone notices a camera has gone dark.

Vendor controllers. When you add an entry, choose its type. Besides SNMP, the pane speaks the controllers' own APIs: a UniFi console or controller (a local admin account, or a Network API key), a TP-Link Omada controller, MikroTik RouterOS 7 over REST, NETGEAR Smart Managed Plus switches (GS305EP, GS308EP, GS316EP — through their own web login, since they have no API; Smart Managed Pro models use SNMP) and Cisco Meraki through a Dashboard API key. Ports are grouped by switch, with the watts in use and — where the controller knows — the name of the device each port powers. UniFi, MikroTik, NETGEAR and Meraki cycle a port on the switch itself, so it comes back even if the access point you are cycling carries this Mac's own connection; an Omada port is switched off and then put back exactly as it was. A controller with a self-signed certificate shows its SHA-256 fingerprint first: compare it with the controller and approve it once. If the certificate later changes, FrontierStack stops sending commands until you approve the new one.

Web-only systems, pinning and whole switches. Cloud-managed lines without a public API — Aruba Instant On, Zyxel Nebula, NETGEAR Insight, EnGenius Cloud, Grandstream GWN, RUCKUS One, D-Link Nuclias — are added as Web UI only: FrontierStack can't switch their ports, so a device linked to one shows an Open … to power-cycle link instead of a button. Pin puts any controller, switch or web-only system with your pinned devices and on Places, its web page one click away. Cycle All… restarts every PoE device on one switch together: ports go off as a group, wait once, and come back as a group.

From the device. On any device's page, Add power control… ▸ PoE switch port links it to the port that powers it; the port a controller reports it on is offered first. That creates a Power Control outlet, so the device gets On, Off and Cycle in its own Power section, can be power-cycled automatically after failed health checks, and can be cycled by FrontierStack AI with your confirmation.

9.15Mellanox / NVIDIA networking

Data-centre switching from NVIDIA's Mellanox line has its own pane, Mellanox Networking (Full Fleet). It reads six kinds of device: Spectrum Ethernet switches on Onyx (its JSON API) or Cumulus Linux 5.x (the NVUE REST API on port 8765), Quantum and SwitchX InfiniBand switches on MLNX-OS, the UFM fabric manager, BlueField DPUs through their BMC's Redfish service, and the ConnectX NICs inside your fleet servers, read over SSH as the linked user.

Add each device with its management address and a read-only account: a monitor-capability user on Onyx or MLNX-OS, an nvue-monitor user on Cumulus, a Monitoring Only UFM user, a ReadOnly BMC account. A self-signed certificate is fetched and shown with its fingerprint; compare it with the console and approve it before any password is sent. Devices are checked every three minutes from the Alerts sweep, and sessions are logged out after each check.

Ports. The first good read watches every port that is up. A watched port alerts when its link goes down, and also when it dropped and came back between two checks — the pane reads each port's own link-down counter, so a flapping cable shows up even if it's up when polled. Ports somebody disabled never alert. On InfiniBand, a port that is LinkUp but not Active is called out: usually no subnet manager is running, and an embedded SM that is enabled but not running is an alert in its own right.

Hardware and fabric. Failed power supplies and fans, sensors over their critical limit (or your threshold, for NICs and DPUs), devlink health reporters in error, a BlueField whose Arm OS has crashed, and UFM's Critical and Major alarms — grouped into one alert per fabric — all reach the usual alert channels. With NVIDIA's MFT installed and passwordless sudo for mlxfwmanager, ConnectX firmware updates are listed too. The AI Administrator can read the same state through router_info with report=mellanox.

9.16Show Network: supervising a club, stage or show

A show runs on a network nobody looks at until something on it goes quiet: a CDJ drops off the link, a lighting node stops answering, the timecode stops, an NDI feed vanishes from the media server. The Show Network pane (sidebar ▸ AV & Stage) makes this Mac the supervisor of that network. It does not run the show; it watches everything that does, and tells you the moment a piece of it disappears.

9.22.7The census

At the top of the pane, FrontierStack writes one plain sentence for each network or VLAN the Mac is attached to, counted from what the devices themselves announce — for example: “There are 14 Art-Net nodes, 73 universes in use, 2 sACN sources and 1 NDI video source on en5 · 2.0.0.0/8.” It is the quickest answer to “is everything here?” when you walk into a venue, and the first thing to read after a cable has been moved.

9.22.8The Show Dashboard

Below the census, the Show Dashboard gives each part of the show its own tile:

Lists underneath show every device behind each tile, with a Watch button on each row. SMPTE LTC is an audio signal and is not read directly; convert it to MTC or Art-Net timecode (most LTC interfaces and ShowKontrol do) and it appears on the Timecode tile.

9.22.9Arm Show

Before doors open, press Arm Show. FrontierStack watches everything that is online at that moment — decks, mixer, lighting nodes, sACN sources, NDI sources, LED controllers, the Link session — and if any of it disappears, it raises an alert through your usual channels (Chapter 11), filed under the Show Network group. Disarm after the show clears the watch list. You can also watch or unwatch single devices by hand.

9.22.10Passive discovery, and stepping aside

Almost everything is found by listening, never by asking:

The one thing FrontierStack sends is an Art-Net ArtPoll: a single discovery broadcast, repeated every 30 seconds so new nodes appear on their own. Turn Poll for Art-Net nodes automatically off under Settings if you would rather press Poll Art-Net Now yourself.

Show software needs its UDP ports to itself. While rekordbox, Engine DJ, ShowKontrol, Beat Link Trigger, PRO DJ LINK Bridge, QLC+, Resolume, MadMapper, QLab or similar run on the same Mac, the matching listener closes and the pane says so. To see both the software and the network, supervise from a second Mac on the show network.

9.22.11Show Servers

Under Show Servers, Add Server takes the address of a media server, LED controller or lighting daemon. Each is checked over HTTP every 30 seconds and alerts when it stops answering. Some report real status:

• Resolume — through its web server (Preferences ▸ Webserver).
• WLED — LED count, frame rate, current draw, Wi-Fi signal and any live Art-Net or sACN input, with On/Off and brightness control.
• Falcon Player (FPP) — player state and the current sequence.
• OLA and QLC+ — the daemon or web access answering, with OLA's version and universe count.

NovaStar/COEX, Brompton Tessera, Colorlight, MADRIX 5 and Lightjams are checked for their web UI or remote port answering. Receiving cards, cabinet temperatures and topology stay in the vendors' own tools.

9.22.12Presets

9.22.13Warning lights, pinning and power

A stage manager can't watch a screen all night, so Show Network can flash a light instead. Under Warning Lights add a WLED strip or beacon, Philips Hue lights on a local bridge (press the bridge's link button, then Pair), or an HTTP request — an alarm URL and a clear URL, which drives a PATLITE network signal tower, a Shelly relay switching a rotating beacon, or a Home Assistant webhook. While anything watched is down (after a short delay you choose), the lights flash red; when it recovers, or someone presses Acknowledge, they go back to exactly how they were. The light follows Show Network second by second rather than the one-minute Alerts sweep.

Pin puts a player, mixer, Art-Net node, WLED, Falcon Player or LED processor into Device Discovery, where its device pane links a power outlet or PDU, a SwitchBot plug and the UPS behind it. Pins count against your plan's device limit. A pinned, watched device then shows Power-cycle… in Show Network and an optional Auto-cycle — off unless you choose a delay, at most twice, half an hour apart. A UPS behind show gear appears as its own tile, and going on battery flashes the warning lights. LED wall processors (NovaStar/COEX, Brompton Tessera, Colorlight) and MADRIX are High-end show systems, part of Full Fleet.

The Clubs & Bars preset includes Show Network, AV Feeds and Power over Ethernet. For festivals, touring and corporate shows, start from Stage & Shows, which adds the show network's plumbing (Places, VPN, mesh networking). Any other setup can take the Show Supervisor add-on.

9.17Generators: event and standby power

Concerts, festivals and outdoor events run on rented generators, and a generator that stops is a stage that goes quiet. The Generators pane (in AV & Stage, beside Show Network) watches them. Rental fleets mix makes, so there are three ways in:

• The controller on this network. Most sets are run by a Deep Sea Electronics, ComAp, DEIF, CRE or Datakom controller, and these speak Modbus TCP. Put the controller on the production network (DSE through its Ethernet port or a DSE855 gateway), add its IP, and FrontierStack identifies the model and reads it every few seconds — no cloud subscription, no mobile signal. Supported maps: DSE (GenComm, with alarms named for each family), ComAp InteliLite 4, DEIF AGC 150, CRE GENSYS Compact and Datakom D-300/500/545/700.
• ComAp WebSupervisor, for sets already reporting to ComAp's cloud: connect with an API key and an application client id and secret, then choose which units to watch. Values refresh every minute.
• AEMP 2.0 telematics (ISO 15143-3): Trackunit — fitted across much of the rental industry — and Atlas Copco FleetLink and most other equipment makers' portals. Connect the account, then watch the sets you want from its fleet. Snapshots refresh every five minutes; Trackunit's extended data adds the generator's own voltage, frequency and load. Telematics is good for fuel and “is it still running”, too slow to catch a trip mid-set.

Each set shows its state and mode, kW and load (set the rated kW if the controller doesn't report load), fuel with an estimate of the hours left once it has 20 minutes of running data, volts and amps per phase, frequency, coolant temperature, oil pressure, battery voltage, run hours, and the controller's own alarms by name.

When the doors open, press Arm running sets. Every set running at that moment is now expected to keep running: if one stops, faults or stops answering, an alert goes out (group “Generators”). Low fuel, fuel running out within a set number of hours, high load, a lost phase, and frequency or voltage outside tolerance are alerts too. Frequency defaults to whichever of 50 or 60 Hz the set is nearest, which matters in Japan, where both are in use. Electrical problems have to last 15 seconds before they count, so a stage's rig coming up all at once doesn't set them off. Sets with Warning lights on flash the Show Network warning lights on anything critical.

The Stage & Shows preset and the Show Supervisor add-on include Generators. The AI Administrator can read every set with ups_status (kind: generator).

9.18Internet Health and speed tests

The Internet Health pane is your view of the link itself. It continuously pings a list of Targets — Cloudflare's 1.1.1.1, Google and Quad9 DNS, two AWS regions and Tailscale's coordination server by default — showing latency and packet loss and re-testing every 30 seconds; hosts that block ICMP fall back to a TCP-connect latency on :443. The gear button in the Internet section's header opens the target-editing dialog — set the list up once and it stays out of the way. The same section carries an IPv6 verdict: each sweep checks whether a global IPv6 address is assigned, whether IPv6 traffic actually works (ping to Cloudflare/Google v6 anycast), and whether the network's advertised IPv6 DNS servers answer. The state it warns about loudest is advertised-but-broken IPv6 — the router hands out an address and an IPv6 DNS server, connections try IPv6 first, and everything stalls until IPv4 fallback; the pane says so in plain words, names the dead DNS server, and points at the router. The AI Administrator can run the same diagnosis with internet_speed (check=ipv6) and dig deeper with ping6/dig/scutil through its diagnose tool. The sidebar's Internet Health row carries a status dot fed by a light background sweep (at launch, then every 5 minutes): green when healthy, orange for broken IPv6 or heavy packet loss, red when every target is unreachable. Live Traffic graphs real-time throughput across every active interface; Addresses & Networks lists each interface, its subnet (a network you can reach directly) and the gateway. A built-in traceroute shows the ISP and transit providers your traffic crosses. Press Test Now in the Speed Test section — or ask the AI with internet_speed — to measure download, upload, latency and responsiveness, using the Ookla speedtest CLI if installed and Apple's networkQuality otherwise. While it runs, two speedtest.net-style dials show the download and upload live — needle, phase and the current Mbps — fed by Ookla's streaming output (the built-in networkQuality reports only at the end, so its dials wait), and the pane names the test server it connected to (provider and city), during the run and in the result. A test that fails now says why instead of ending silently. A Mac on Wi-Fi, though, measures its Wi-Fi as much as its ISP — so the same section can run the test from your router or a wired server instead: pick it under From Router / Server and FrontierStack runs the probe on that device over SSH (key authentication; routers as root), preferring an installed Ookla/speedtest-cli and falling back to a curl single-stream estimate. If the router measures much faster than the Mac, your bottleneck is the wireless hop, not the line — and the AI can do the same comparison via internet_speed with a source.

One test tells you about one moment; Speed History, the section below it, tells you whether the line is getting slower. Turn on Run speed tests on a schedule — it is off by default, because every test uses real bandwidth and, on a metered line, real data — and choose Every 6 hours, Daily (the suggested setting), Every 2 days or Weekly. Each run lands on a random minute, and for daily and longer rates Only between keeps it inside a quiet window such as 02:00–05:00, so results are comparable and nobody's video call is interrupted. A due test is skipped and retried later, never failed, when there is no internet, the connection is metered or in Low Data Mode (an iPhone hotspot, for example), the Mac is on battery, or another test is running; the Mac has to be awake at the chosen time. Without the Ookla CLI the built-in networkQuality does the measuring, and each result records which engine produced it. Under Also test from a router or server you can put the router's own test on the same schedule, which measures the line without this Mac's Wi-Fi in the way; each device keeps its own history, and scheduling more than one device needs Full Fleet. Every result — time, download and upload, latency and jitter where the engine reports them, engine, test server, and whether this Mac was on Wi-Fi (and which network) or Ethernet — is kept, up to 400 per source, and charted with the baseline band. When the median of the last 7 days (at least four scheduled tests spread over two days or more) falls below 65% of the median of the 28 days before (at least eight tests), a long-term decline warning appears in Alerts under Network & Routing, with recent and baseline Mbps and the percentage change. Only like is compared with like — the same source, the same engine, and for this Mac the same connection type and Wi-Fi network — so a laptop that moves between home and office never reads as a decline, and manual tests are charted but left out of the trend, since you usually run one when something already feels slow. A decline has two possible causes and the warning names both: the line or ISP has degraded, or something on the network is quietly using a lot of bandwidth — compare with the router's usage on its device pane and look for devices you don't recognise. After a deliberate change, such as a cheaper plan, Accept as New Normal makes the current speed the baseline and ends the warning. The AI Administrator reads the same history and verdict with internet_speed (check=history).

9.19Network Path: switches, hubs and hop-by-hop latency

The Network Path pane answers the physical question the IP tools cannot: which boxes does this connection actually cross, and which one slows it down? LAN Path reads your managed switches' bridge tables and LLDP neighbours over SNMP and draws the chain between this Mac and any LAN device — each link labelled with its port and speed, the slowest link flagged, and a dashed inferred box drawn where several devices share one switch port (the classic hidden unmanaged switch or hub, which cannot be queried directly). Locate a Device tracks one machine down: IP, MAC, maker (from the MAC prefix), type — and the exact switch port it is plugged into. Visual Traceroute charts each hop's round-trip time and highlights the hop that adds the most latency, so “is it my Wi-Fi, the ISP's first mile, or further out?” becomes a picture. Reading the switches uses the SNMPv2c or SNMPv3 profile set in Device Discovery; unmanaged gear stays invisible by nature, which is exactly what the inference is for. The pane fills itself in: on open it automatically maps the devices between this Mac and the router (and Map Mac → Router re-runs it). Device Link Speeds goes wider still — it surveys the negotiated Ethernet port speed of every known device from its switch port (both ends of a link negotiate the same rate), slowest and half-duplex links first: a NAS stuck at 100 Mbps on a gigabit network is usually a bad cable, an old unmanaged switch, or a mis-negotiating NIC, and this is where it shows up. Locate a Device also asks the device itself over SNMP what its ports negotiate, when it runs an agent.

9.20Subnets and VLANs

The Subnets pane lists every network FrontierStack knows about — this Mac's interfaces and VPN routes, your routers' LANs, the networks your servers and devices sit on — and what is on each. The switch at its top shows the same networks three ways: as a List, grouped By VLAN, or drawn as a VLAN Layout.

Each subnet is placed on a VLAN from the strongest evidence available. Your own word comes first: right-click a subnet and choose Assign to VLAN… for networks nothing reports (the assignment is saved with your other settings and included in settings backups). Next come routers whose API lists their VLANs — OPNsense, pfSense with the REST API package, MikroTik RouterOS and UniFi — together with the address on each VLAN interface, and router interfaces whose name carries the tag, such as igb0.10. Then this Mac's own VLAN interfaces. Last, managed switches: when most of a subnet's devices are learned on one VLAN in the switches' forwarding tables, the subnet goes there. Every placed subnet says which of these placed it, and anything left over is listed under No VLAN tag known.

VLAN Layout draws the result: the routers and switches that carry your VLANs at the top, the 802.1Q trunk below them, and a colour-coded column per VLAN with its subnets and gateways, the switch ports it uses (filled for untagged access ports, outlined for tagged ones) and the devices and servers on it — each opens its own pane. Read Switches fills in the ports: it asks the managed switches Device Discovery found for their VLAN names, port membership, native VLANs and VLAN-by-VLAN forwarding tables over SNMP, using the same read-only profile as Network Path, and marks ports that carry several VLANs tagged as trunks. Switch readings last for the session, so press it again after re-patching. Ask the AI Administrator “which VLAN is the NAS on?” and it reads the same view through router_info.

9.21Debug Share: expose a localhost server, briefly

When you need to show a colleague or a phone a dev server running on localhost, the Debug Share pane exposes it for a session and then closes itself. Enter the port (or press Scan localhost to find a running server), choose how to Expose via, set an Auto-close time, and press Open debug session. Every share also closes automatically when FrontierStack quits.

The LAN forwarder has two extras. If the host firewall is on, the pane shows Open port in firewall to allow that port in the pf rules just for the session. And an Outside access picker can map a WAN port via UPnP, NAT-PMP or the OPNsense API and pair it with a DDNS host, so a LAN share becomes reachable from the public internet — the mapping is removed when the share closes. The AI Administrator can open, list and close sessions too (debug_share_open / _list / _close), including over MCP when "Allow changes" is on.

A Debug Share session is meant to be brief. To keep your own dev server reachable from your tailnet with no timer, turn on Also serve on Tailscale for it in the Localhost pane (Chapter 4): it answers on this Mac’s Tailscale address on the same port, stays off the LAN, and closes when the server stops. The AI Administrator can start a folder that way with debug_share action serve and report the address to open.

9.22Named tunnels: a permanent public hostname

A Quick Tunnel is deliberately throwaway. When you want a service on this Mac to be reachable permanently at a real address — a self-hosted app, an internal dashboard, a webhook receiver — use a named tunnel instead. It gives the service a stable hostname on one of your own Cloudflare zones (say app.example.com), survives reboots, and — like every tunnel — opens no inbound port: the Mac dials out to Cloudflare's edge, so there is nothing to forward and nothing for a port scan to find.

Create one in the Cloudflare pane's Named Tunnels section: New Tunnel…, then a hostname under one of your zones and the local port it fronts. FrontierStack drives the whole setup through the Cloudflare API using the token you already hold — it creates the tunnel, writes its ingress rule (hostname → http://localhost:PORT), adds a proxied CNAME pointing the hostname at <id>.cfargotunnel.com, and then installs the persistent daemon with cloudflared service install. That last step needs a one-time admin prompt (it writes a LaunchDaemon under /Library); cloudflared itself is fetched from Homebrew on first use. Untick Run on this Mac now if you only want the tunnel and DNS created, to run cloudflared on some other host. Delete unwinds all of it — daemon, DNS record and the account-side tunnel. The AI Administrator has the same three verbs (tunnel_create / tunnel_list / tunnel_delete), with creating one gated behind a red confirmation because it publishes a service to the internet.

Each tunnel row also shows a live health line and a bell for an opt-in down alert, and Protect… puts a Cloudflare Access sign-in in front of the hostname — see Chapter 7.