Problem

Two LibreFang nodes on the same network, each with a matching [network] shared_secret and the other's address in bootstrap_peers, can never connect. Both sides log, symmetrically:

WARN  OFP: failed to connect to bootstrap peer error=Handshake failed: Remote error 403: HMAC authentication failed
DEBUG OFP: inbound connection ended: Handshake failed: HMAC verification failed on incoming Handshake

No configuration change fixes it — not ports, mDNS, shared_secret, or a WireGuard/Netbird overlay. The handshake is reached; HMAC verification is what fails.

Root cause (regression from #3920)

#3920 bound the recipient node ID into the handshake HMAC so a captured handshake cannot be replayed against a different federation node sharing the same shared_secret:

auth_data = nonce | sender_node_id | recipient_node_id

The bootstrap dialer cannot satisfy that binding. bootstrap_peers is a list of addresses, and each node's node_id is derived from its persisted Ed25519 keypair (key_mgr.load_or_generate() in background_lifecycle.rs) — unique per machine, not user-settable. So the kernel dials each bootstrap entry via PeerNode::connect_to_peer, which hardcodes the recipient to the empty string:

// peer.rs
pub async fn connect_to_peer(&self, addr, handle) -> Result<(), WireError> {
    self.connect_to_peer_with_id(addr, handle, "").await   // recipient = ""
}

The receiver, however, verified the HMAC against its own real node ID with no fallback for the empty form:

// peer.rs inbound handshake (pre-fix)
let expected_data = format!("{}|{}|{}", nonce, node_id, node.config.node_id);
if !hmac_verify(&node.config.shared_secret, expected_data.as_bytes(), auth_hmac) { /* 403 */ }

HMAC(nonce|sender|"") never equals HMAC(nonce|sender|<receiver id>), so every bootstrap handshake 403s, in both directions. Commit 9ccf2a42 (#3920) introduced both the empty-recipient bootstrap call and the strict receiver check together, and every test used connect_to_peer_with_id with a known recipient, so the real bootstrap path was never exercised.

Fix

The inbound handshake accepts either binding:

1. the recipient-bound form (nonce|sender|<our node id>) — the strong anti-replay path, used by send_to_peer once the peer's node ID is known; or
2. the empty bootstrap form (nonce|sender|) — for an initial bootstrap dial that cannot know our node ID.

Whichever form authenticated is threaded into the subsequent Ed25519 identity verification (the client signed that same auth_data). The remaining authentication layers still fully cover the bootstrap path:

• nonce dedup (OFP NonceTracker does O(n) retain() on every handshake — DoS amplifier under flood; also runs before HMAC verify #3880),
• Ed25519 TOFU identity pinning (OFP authenticates the entire mesh with one shared_secret + self-asserted node_id — no per-peer identity, no PKI #3873),
• per-handshake ECDH session key (bug(wire): OFP per-message HMAC session_key still coupled to shared_secret #4269) — an attacker who lacks the X25519 ephemeral private key cannot derive the session key and so cannot communicate even if they replayed a bootstrap handshake.

A wrong, non-empty recipient is still rejected, so the #3875 cross-node replay protection is preserved for the established-link path.

Changes

• crates/librefang-wire/src/peer.rs: inbound handshake HMAC verification accepts the empty-recipient (bootstrap) binding as a fallback to the recipient-bound form; the matched auth_data is reused for Ed25519 identity verification. Doc comment on connect_to_peer updated to describe the accepted bootstrap binding.

Verification

• cargo test -p librefang-wire --lib — 69 passed, 0 failed, including:
  • issue_3920_bootstrap_connect_without_recipient_id_succeeds (new) — dials through the real connect_to_peer entry point and asserts the handshake completes in both directions.
  • issue_3920_wrong_nonempty_recipient_still_rejected (new) — a wrong non-empty recipient is still refused.
  • test_handshake_hmac_includes_recipient, issue_3873_*, issue_4269_* — existing replay / identity / KEX coverage unchanged.
• cargo clippy -p librefang-wire --all-targets -- -D warnings — clean.
• rustfmt --check — clean.

(Built and tested in the sanctioned Linux dev container; the change is platform-independent.)

Review follow-up (commit 2)

• Added issue_3920_identity_bootstrap_connect_succeeds_and_pins: the HMAC-only test above uses identity-less nodes (PeerNode::start carries no keypair), so it never exercised the line that threads the matched auth_data into Ed25519 identity verification — the production default, where every node loads a load_or_generate keypair. The new test dials two identity-bearing nodes through the empty-recipient connect_to_peer and asserts both sides pin each other's pubkey. Verified non-vacuous by mutation: feeding the bound form into identity verification makes this test fail with Ed25519 identity signature invalid while the HMAC-only test still passes.
• Recorded the fix under CHANGELOG.md [Unreleased].
• Full librefang-wire lib suite: 70 passed, 0 failed; cargo clippy -p librefang-wire --all-targets -- -D warnings clean; rustfmt --check clean.

Out of scope (separate observation, not fixed here)

[network] mdns_enabled is a dead config knob: it is referenced only in config struct / default / API display / validation, with no mDNS discovery implementation anywhere in crates/ (no mdns-sd, ServiceDaemon, or multicast dial). Toggling it has no effect on peering — the only discovery/dial path is bootstrap_peers. Implementing mDNS auto-discovery is feature work in the kernel mesh subsystem and belongs in its own issue/PR.