Johnathan Corgan
87f0678ce0
start_service switched dnsmasq's .fips forwarding to the gateway's port
before the gateway ran. A gateway that then failed, on a config it could
not parse or on a NAT or route error after binding, left every LAN
client's .fips lookups going to a port nothing held, until someone
started the gateway by hand; procd gives up respawning after five
failures and says nothing.
procd now runs the init script's supervise command, which starts the
gateway, switches dnsmasq to its port once the gateway's own process holds
a socket bound there, and switches it back to the daemon's port when the
gateway exits for any reason, passing procd's SIGTERM on so the gateway can
clean up. Ownership is checked by matching a socket inode for the port in
/proc/net/udp{,6} against the gateway's open descriptors, so a port held by
something else, such as an mDNS responder on 5353, is never mistaken for the
gateway. supervise records the gateway's pid in /var/run/fips-gateway.pid,
and an exiting instance skips the swap back only when the gateway named
there, the one procd started in its place, holds the port. Every change to
the dnsmasq entry is made under one lock, so a stopping and a starting
gateway cannot interleave. stop_service still swaps back as before. The
exit status is the gateway's, so procd's respawn behaves as it did.
procd sends SIGTERM to the supervise shell and, five seconds later, SIGKILL
to that shell alone, so a gateway slow to stop would outlive it, holding its
port. supervise kills the gateway three seconds after passing the SIGTERM
on, and stops its watcher as soon as the gateway is gone.
A new scenario runs the command start_service hands procd against stub
gateways that hold their socket themselves and exit before binding, fail
after binding, are stopped by SIGTERM, or ignore it, against a port taken by
another process, and against a swap back with a process other than the
successor holding the port, and checks dnsmasq ends on the daemon's port
each time.
FIPS Documentation
FIPS (Free Internetworking Peering System) is a self-organizing encrypted mesh network built on Nostr identities, capable of operating over arbitrary transports — local networks, the public internet, Tor, Bluetooth, or point-to-point links — without central infrastructure.
With FIPS, your machine becomes a node in the mesh with a self-generated cryptographic identity. There are two ways to deploy it.
As an overlay on top of existing IP networks, FIPS lets your node reach any other FIPS node wherever it sits — behind a NAT, on a different ISP, on a phone over cellular, on a laptop with only Bluetooth in range, or behind a Tor onion. The mesh forwards IPv6 traffic transparently and end-to-end encrypted, with no central VPN concentrator or coordinating server.
From the ground up over raw Ethernet, WiFi, or Bluetooth, FIPS provides a complete permissionless network without any pre-existing IP infrastructure, ISP, or DNS. Any node that joins the link gets routable IPv6 addresses, peer discovery, and a path to every other node automatically.
Either way, existing networking software runs over it unchanged: SSH, HTTP servers, file transfer, anything IPv6-native works the same way it would on a local network.
New to FIPS? Start with the Getting Started guide.
Documentation Sections
Tutorials
If you are starting from scratch and want a guided path to a working mesh, go here.
How-To Guides
If you have a specific task in mind — enabling a feature, deploying a component, diagnosing a problem — go here.
Reference
If you need to look up wire formats, configuration keys, command flags, or counter inventories, go here.
Design
If you want to understand how the mesh self-organizes, why FIPS makes the choices it does, or how the pieces fit together, go here.
Releases
If you want the notes for a particular version — what changed, what broke, and what to do about it on upgrade — go here.