What works when the outside goes away.
An operations centre, two shelters and a field team keep working on their own networks when the uplink fails, and reach each other again when it comes back. That is the use FrogNet was built for. This page says what has been shown, what has only been recorded, and what has not been shown, so you can decide what to test yourself.
The scenario.
A county operations centre, two shelters and a mobile field team. Each site has one FrogNet node and whatever phones and laptops are there. On its own LAN each site is complete: the node serves addresses and names, the machines on it find each other, and the site's applications run against the site's own shared memory. A region host, reachable by all four sites, joins them into one network; each site's node opens a WireGuard tunnel to it. When a shelter loses its uplink, that shelter keeps working on its LAN; the others keep working with each other. When the uplink returns, the shelter's tunnel comes back on its own and its facts are visible again.
Nothing is replayed or reconciled on reconnection. Each site's applications publish their own current facts and re-publish them when the world changes; what you see is what each site says now. Incident history belongs in a durable record of your own, not in FrogNet's memory. The design is deliberate (specification §2, §9).
The equipment.
| Piece | What it is | Status |
|---|---|---|
| A node | An Ubuntu 24.04 x86-64 machine with two network interfaces: one upstream, one for the LAN it serves. Installed from the repository with one command (docs/OPERATING.md §2). | Clean install passes its own 28 checks and comes up LAN-only after the reboot (docs/cleanup-2026-10/t5b-logs/g1-install.txt). |
| A Raspberry Pi node | The same node on aarch64. | Pi nodes ran in the field before October 2026. The cleaned tree has not been installed on a Pi; its installer was built, not run (CLAIMS.md, "Not shown"). |
| A region host | One small machine at an address every site can reach: a VPS, or any box on a network the sites share. Holds the region's membership, not your data (Run a region host). | Created and exercised in the October 2026 gates on a private address, 172.30.0.10 (t4b-logs/g3-region-create.txt). |
| Phones | The FrogNet Android app joins a region as a member and carries the Communicator. | Source only: no APK ships, build it with an Android SDK (docs/OPERATING.md, Phones). A handset joined and reached on build a15, by the author's report (ANDROID-HANDOFF.md). |
| Windows PCs | The Windows bridge joins a PC to a region. | Needs a Wintun adapter and configuration (docs/OPERATING.md, Windows PCs). |
| Radios | FrogNet rides any IP link. 900 MHz and HaLow have carried it. | The 900 MHz call is a recording on this site, not a test in the tree (below). |
What has been shown, by a test or a log in the tree.
From CLAIMS.md. Each row names the file that shows it.
| For the scenario | Shown by |
|---|---|
| Two nodes on one LAN find each other, name each other, route to each other's network and elect the same database host, with nothing outside the LAN | netns-lan-only-test.sh, 19/19; two installed machines, t4b-logs/final2-* |
| Nodes at two sites reach each other through the region's hub, 3/3 pings each way | t4b-logs/g3-n1-after-reboot.txt, g3-n2-after-reboot.txt; netns-region-loop-test.sh |
| The region recovers from a loss of the region host's network with no manual step: 55 s between disconnect and reconnect, pings both ways 20 s after | t4b-logs/g3-outage.txt |
| A region needs no internet: the region host can be any address the members reach | the gates used a private address; not shown on a network with no uplink at all |
| One node in two ponds, switched without a restart | netns-ponds-daemon-test.sh |
| A phone or PC reaches into another pond as that pond's configuration allows | netns-reach-test.sh, 70 checks |
| An upgrade keeps the node's identity; an uninstall leaves nothing behind | t4c-logs/g4-*, t4b-logs/g5-* |
| Nothing in the shipped runtime talks to a rendezvous service, and nothing has a second mechanism behind a failed one | static-no-broker.sh, static-no-fallback.sh, 0 violations |
What has been recorded, and not reproduced by the tree.
These are recordings on this site. Nothing in the repository re-runs them, and the October cleanup did not.
- A two-way video call sustained under 150 kbit/s over 900 MHz HaLow, 22 fps measured (demonstrations).
- A call that continues across a deliberate network partition (demonstrations).
- The media ladder stepping down under contested bandwidth and recovering without redialling (simulator).
- A value written in one city read in another with no application messaging (home).
The applications.
DisasterComm's first release, DC_APPS_V1, on the fdf-carry branch: web pages a node serves, used from any phone or laptop on the node's Wi-Fi, nothing to install.
| App | Who writes | What |
|---|---|---|
| Help requests | The person needing help, or someone on their behalf | Name, how many, needs, status (open / safe / resolved), location, contact |
| Responders | Each team, ambulance, equipment holder or volunteer | Kind, capabilities, availability, crew, location |
| Hospital capacity | Each hospital | Receiving status (open / limited / diversion / closed), capabilities, beds |
| Coordination | Whoever acts on a request, for a unit | Assigned, en route, on scene, assisted, transported, released |
| Chat | Each sender | Text for communities, field teams and coordination centres |
Every truth has one owner and the owner writes its own cell; nobody edits anybody else's record. A request's state is read, not stored: its own status plus the newest action from each unit. Two coordinators assigning at once each write their own action cell, and both are seen (opt/fdf/www/dc/README.md). These apps are the first release and are not in the October gates: nothing in the tree yet tests them.
What has not been shown.
- Size. The largest region in the gates had three members; the largest LAN-only pond two nodes. Nothing larger has been measured.
- Independent verification. Every claim was produced and checked by one author. Nobody outside has reproduced any of it.
- Permanent loss of the region host. Recovery from a network outage is tested; destruction and replacement of the host is not.
- The hub sees inter-site traffic. Every cross-site tunnel ends at the region host, which decrypts and forwards in the kernel. On one LAN the hub never sees a byte (§7.4).
- Who may write what. One writer per truth is a programming rule; nothing in the fabric enforces it. What the region enforces is admission: a member gets a tunnel only with an invitation, and an invitation can be revoked (§7.3).
- A hypervisor guest, a Pi after the cleanup, the phone app after the cleanup, the Communicator servers on a node. Not tested in the gates (
CLAIMS.md, "Not shown").
Test it yourself.
The gates are scripts in the repository; they run in network namespaces on one Ubuntu 24.04 machine and need no hardware. docs/OPERATING.md is the installation and operation guide for the current build, and README.md says how to run every gate. An evaluation that matters to you is the scenario above on your own hardware, with your own people operating it; the author's offer is on Work with us.