Connect handshake advertises loopback/private addresses to remote peers

[sanity]

Summary
Nodes started via freenet local keep advertising 127.0.0.1:<port> to remote peers during the connect handshake. Remote peers (e.g. Nova gateway at 5.9.111.215:31337) dutifully try to deliver follow-up messages to that loopback address and fail, which is why SuccessfulPut never makes it back to the publisher in #2086.

Evidence

• When Nova processed PUT transaction 01KA2R1W285XGJG4M0CNWPNB81, it tried to send SuccessfulPut to peer v6MWKgqKCpsc5rkG at 127.0.0.1:36078 and eventually logged TransportError("failed while establishing connection, reason: max connection attempts reached") (journalctl -u freenet-gateway --since "2025-11-14 21:10" --until "21:20" | grep 01KA2R1W285XGJG4M0CNWPNB81). That loopback address originated in the connect exchange with the publisher.
• In p2p_protoc::handle_peer_connection_msg (crates/core/src/node/network_bridge/p2p_protoc.rs:1609-1645), we only overwrite sender.peer.addr with the actual TCP/UDP socket when the incoming message’s address is 0.0.0.0 or already matches remote_addr. If the joiner pre-fills from.peer.addr = 127.0.0.1:<port>, we never correct it even though the packets clearly arrive from an external IP.
• ConnectOp::handle_request (crates/core/src/operations/connect.rs:500-520) passes from.peer.addr straight into RelayState::handle_request as the observed address. RelayState then emits ConnectMsg::ObservedAddress with that same value (lines 194-212) instead of the socket we actually observed in the transport layer. So the joiner keeps telling everyone its address is 127.0.0.1.
• We only call state.update_observed_address when the joiner’s IP is is_unspecified(), so loopback/private addresses are never replaced even when we learn better information.

Impact

• Any node started on a loopback-only interface can never receive SuccessfulPut, SuccessfulSub, etc., from remote peers, because those peers will try to connect back to 127.0.0.1.
• CI/integration tests don’t catch this because all peers run on the same host, so connecting to 127.0.0.1 works.

What needs fixing

1. When processing inbound messages (handle_peer_connection_msg), always overwrite the sender’s peer.addr with the connection’s remote_addr when the sender’s public key matches the connection, even if they pre-filled loopback/private addresses.
2. When relaying ConnectMsg::Request, pass the actual socket address observed by the transport to RelayState::handle_request, so the emitted ObservedAddress reflects reality.
3. Loosen the guard in RelayState::handle_request / JoinerState::update_observed_address so we also replace loopback/private addresses, not only 0.0.0.0.

Fixing this will stop remote peers from trying to call us on 127.0.0.1 and will unblock SuccessfulPut delivery for single-node publishers.

[github-actions]

🤖 Auto-labeled

Applied labels:

• T-bug (95% confidence)
• P-high (85% confidence)
• E-medium (80% confidence)
• A-networking (90% confidence)

Reasoning: The report describes incorrect behavior where nodes advertise loopback/private addresses (127.0.0.1) to remote peers during the connect handshake, causing delivery failures (e.g., SuccessfulPut). This is a functional bug in the networking/peer-discovery/connection-handling code (references to p2p_protoc, ConnectOp::handle_request, RelayState). It impacts correctness for nodes started on loopback interfaces and can block message delivery, so it should be treated as high priority. The required changes touch multiple networking components but are well-scoped (overwrite observed socket address, pass actual socket address into relay handling, relax guards), which suggests medium effort. Primary area is networking.

Previous labels: none

If these labels are incorrect, please update them. This helps improve the auto-labeling system.

[iduartgomez]

Regression from the handshake handler refactor.

[iduartgomez]

Any changes that touch the connection or transport protocols should be validated by a real test network harness before a new release, in fact we could add this to release action automatically.

[sanity]

Closing: Fixed by PR #2090 (propagate observed joiner address through connect) and PR #2142 (use observed external address in ConnectResponse target).

The root cause was that relays/gateways weren't updating the joiner's advertised address with the transport-observed socket. These PRs:

1. Tag inbound connect requests with the transport-observed socket at the first hop
2. Propagate that observed socket through relays (with loopback guard for localhost topologies)
3. Emit ObservedAddress back to the joiner with the correct external address
4. Use response_target field to ensure ConnectResponse goes to the observed address, not the original private address

[AI-assisted - Claude]