Johnathan Corgan
306e455513
The Phase 1, Phase 3, and Phase 5 strict asserts each fire a single ping per directed pair. Under low-level packet loss (e.g. 1% i.i.d. per-direction loss from a CI runner under pressure), a single-shot round-trip fails at ~2% per pair, so a 20-pair strict assert misses with probability 1 - (0.98)^20 = ~33% per phase from ICMP noise alone, well above the routing-state signal the asserts are meant to catch. ping_one gains a max_attempts parameter (default 1, preserving existing call sites). On failure it retries up to MAX_PING_ATTEMPTS-1 additional times with PING_RETRY_DELAY seconds between attempts. Per-pair worst case under the defaults (4 attempts, 1 s spacing, 5 s ping6 -W timeout) is 4*5 + 3 = 23 s; per-rep worst case scales with the failing-pair count. Successful retries log "OK (RTT, attempt N)"; exhausted retries log "FAIL (after N attempts)". The retry budget is wired into all three strict asserts: - Phase 1 final ping_all (after wait_for_full_baseline converges) - Phase 3 ping_all (post-first-rekey) - Phase 5 ping_all (post-second-rekey) The wait_for_full_baseline convergence loop itself stays single-shot. Its job is to detect when the mesh first sees a fully clean 20-pair batch, and retries inside the loop would conflate transient ping loss with still-converging routing state. No daemon code changes.
FIPS Testing
Integration and simulation test harnesses for FIPS, using Docker containers running the full protocol stack.
Test Harnesses
static/ -- Static Docker Network
Fixed topologies with manual scripts for building, config generation, connectivity tests (ping, iperf), and network impairment (netem). Useful for deterministic debugging and validating specific topology configurations.
| Topology | Nodes | Transport | Description |
|---|---|---|---|
| mesh | 5 | UDP | Sparse mesh, 6 links, multi-hop |
| chain | 5 | UDP | Linear chain, max 4-hop paths |
| mesh-public | 5+1 | UDP | Mesh with external public node |
| tcp-chain | 3 | TCP | Linear chain over TCP (port 8443) |
| rekey | 5 | UDP | Rekey integration test topology |
tor/ -- Tor Transport Integration
End-to-end Tor transport testing with Docker containers running real Tor daemons. Requires internet access for Tor bootstrapping.
| Scenario | Description |
|---|---|
| socks5-outbound | Outbound SOCKS5 connections through Tor to clearnet peer |
| directory-mode | Inbound via HiddenServiceDir onion service (co-located) |
nat/ -- NAT Traversal Lab
Real Docker NAT traversal tests for the Nostr/STUN bootstrap path,
using router containers with iptables-based NAT, a local Nostr relay,
and a local STUN responder.
| Scenario | Description |
|---|---|
| cone | Two NATed peers establish a UDP traversal path |
| symmetric | UDP traversal fails under symmetric NAT, TCP fallback wins |
| lan | Peers on the same LAN prefer local addresses over reflexive |
chaos/ -- Stochastic Simulation
Automated network testing with configurable node counts, topology algorithms (random geometric, Erdos-Renyi, chain, explicit), and fault injection (netem mutation, link flaps, traffic generation, node churn). 20 scenarios covering general stress testing, cost-based parent selection, mixed link technologies (fiber/Bluetooth/WiFi), transport-specific validation (UDP, TCP, Ethernet), and ECN/congestion testing. Scenarios are defined in YAML and executed via a Python harness that manages the full lifecycle: topology generation, Docker orchestration, fault scheduling, log collection, and analysis.