Johnathan Corgan
28f9fc007a
5353 is the mDNS port, which the daemon's LAN rendezvous, Avahi and systemd-resolved can hold. On an OpenWrt access point with the gateway enabled, the gateway lost the port to the daemon's mDNS responder and dnsmasq sent .fips queries to a responder that does not answer them. 5365 is unassigned by IANA and not used by any common resolver. The OpenWrt init script now points dnsmasq at the port gateway.dns.listen actually sets, falling back to the new default, and when it swaps the .fips forwarding it clears every loopback .fips entry rather than four fixed ones, so a stale entry for an old or custom port does not linger. Forwards to other hosts and other domains are kept. The shipped OpenWrt config and the example config leave the listen line at the default. fips.yaml is a conffile on OpenWrt, and fips-ap-setup edits it, so routers that set up an access point would keep the old explicit listen: "[::1]:5353" across an upgrade and stay broken after the default moved. The first-boot setup script, which every install and upgrade path runs before the services start, now rewrites that exact shipped line to the line a fresh install ships and logs that it did; any other value is left as configured. The script is sourced rather than executed on the SDK-feed and sysupgrade paths, so the migration runs last, cannot end the script early and cannot change its exit status. The script also removes stale loopback .fips forwarding entries for port 5353. The gateway warns at startup when it is configured on 5353, whether or not the bind succeeds, since an mDNS responder can take the port later. The OpenWrt scenario harness checks the port the init script reads, that its default matches the gateway's, and the swap's cleanup against a uci stub. It also runs the real setup script executed by both package managers' upgrade scripts and sourced in a subshell, and checks the negative, missing-file, repeat-run and stale-entry cases. The dns-resolver and deb-install harnesses check that the gateway binds the new default.
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.