← back to about

Hardware & network stack

The three pieces that actually run this network, what each one talks to, and the outside internet services each one reaches — laid out below, then explained in full underneath.

Member node Raspberry Pi + radio · one of several app_rpt / Asterisk Setup wizard (Flask :8090) allmon3 (status dashboard) Browser root shell (ttyd :7681) hostapd (setup Wi-Fi AP) gmrs-ctrl — hub LXC controller + ASL3 hub, combined WireGuard hub ASL3 hub node (Asterisk) Flask portal :8080 + SQLite FCC callsign sync (daily) Weather alerts/conditions cache gmrs-voice — LXC AI voice + shared text-to-speech Jarvis daemon (node 1504) openWakeWord + faster-whisper Piper TTS server :8092 gmrs-last-keyed :8091 WireGuard tunnel IAX2 (Asterisk) + HTTP (portal API) WireGuard tunnel USRP audio + HTTP (TTS / admin) node ↔ gmrs-voice HTTP (TTS) — same WireGuard path as above, relayed via the hub; only the portal's own API is skipped 🚫 AllStarLink: blocked Proxmox host — both LXCs run on the same physical machine Public internet services reached (see the table below for who calls what) weather.gov Open-Meteo FCC ULS Google Gemini Gmail SMTP NTP Debian + AllStarLink apt repos Nothing here is exhaustive plumbing (DNS, apt mirrors) — just the services this project's own code deliberately calls out to. NTP, apt only — NWS/Open-Meteo just as a fallback NWS, Open-Meteo, FCC ULS, Gmail SMTP, NTP, apt Google Gemini, NTP, apt

Who calls what, and why

FromToCarries
Member nodegmrs-ctrlWireGuard tunnel (UDP 51821) — IAX2 (Asterisk linking/audio) and plain HTTP to the portal (directory, weather cache, config poll, extnodes); no separate TLS needed, WireGuard already encrypts the whole tunnel
gmrs-ctrlgmrs-voiceWireGuard tunnel — USRP audio (Jarvis's hub bridge) and HTTP (shared Piper TTS, admin control)
Member nodegmrs-voiceHTTP to the shared TTS server (:8092) for announcement/weather audio, addressed straight at gmrs-voice's overlay IP — skips the hub's own Flask API, but the packets themselves still transit gmrs-ctrl (same WireGuard mesh, IP forwarding enabled there)
gmrs-ctrlNational Weather ServiceSevere weather alerts — cached hub-side so every node isn't calling NWS independently; the actual issuing authority for U.S. warnings
gmrs-ctrlOpen-MeteoCurrent-conditions data for the scheduled weather announcement, same caching reasoning
Member nodeNWS / Open-MeteoFallback only — a node calls these directly if the hub's own cache is unreachable, so a hub hiccup doesn't silently kill weather features fleet-wide
gmrs-ctrlFCC ULSDaily sync of the public GMRS license database, backing callsign autofill/validation on the registration form
gmrs-ctrlGmail SMTPAdmin notification emails (new registrations, hub-access requests)
gmrs-voiceGoogle GeminiJarvis's transcribed question, for a short spoken answer — read-only, no tools, can't control anything on the network
gmrs-ctrl & gmrs-voiceNot network traffic — both are LXCs on the same physical Proxmox host, unlike member nodes, which are separate physical hardware
All threeNTPOrdinary system clock sync
All threeDebian / AllStarLink apt reposPackage installs — repo.allstarlink.org is the one AllStarLink domain deliberately left reachable; every other AllStarLink domain (registration, stats, node lookup) is null-routed — see below
Deliberately blocked This network is fully isolated from the public AllStarLink network by design — register.allstarlink.org, stats.allstarlink.org, nodes.allstarlink.org, and update.allstarlink.org are all null-routed on the hub. Nothing here is ever registered with, or reachable from, AllStarLink at large, even though the software underneath (AllStarLink 3) is the same base the public network runs.

Live system stats

The Proxmox host and both LXCs, updated roughly every 30 seconds. This reads a small cached file — your being on this page never triggers a live query against Proxmox, no matter how many people are looking at it at once.

Proxmox host gmrs-ctrl gmrs-voice loading…

CPU

Memory

Swap

Disk

Network in

Network out