#35750 addrman: make `m_last_good` network-specific

Tracks the timestamp of the last successful connection (`m_last_good`) per network in AddrMan rather than globally. Connection failure attempts are only recorded against an address if the node has recently established a successful connection on that address's specific network. If a network remains unreachable for more than seven days, AddrMan falls back to successful connections across any network to prevent dead addresses from occupying slots indefinitely.

Problem: Currently, AddrMan uses a single global `m_last_good` timestamp to decide whether to record connection failures against peer addresses. If a node loses connectivity to a single network (such as IPv6 or Tor) while remaining connected via IPv4, failed attempts are counted against those addresses and eventually mark them terrible and suppress their relay, even though the connectivity fault is local to the node.

Evidence of importance:

• PR description: "`m_last_good` is used to prevent recording failed attempts for addresses when it is our connectivity that is at fault. However, it is quite common that only some networks are unreachable - e.g. I have encountered it frequently that `IPv6` is unreachable, while `IPv4` works fine. In this case it is not correct to increase the failed counter for an `IPv6` address and ultimately making it `Terrible`, just because we are making `IPv4` connections."

Risk of a mistake: low (p2p). A bug in AddrMan failure counting could alter address selection probabilities or delay evicting unreachable peers from the address manager.

Changed since the previous assessment: Added a fallback mechanism (`ADDRMAN_NET_UNREACHABLE`, 7 days): if a network has seen no successful connections for 7 days or since startup, AddrMan falls back to the most recent successful connection across all networks so unreachable addresses can still be evicted.

Ready

Nothing known that would invalidate a review now.

Waiting on (from the thread read):

• author: author is investigating missing IPv6 auto-detection while PR is in draft 2026-10-21

Strong

substantive support, no open objection (stratospher, naiyoma, fjahr, naiyoma)

Thread notes: mzumsande addressed fjahr's suggestion by documenting the GetChance impact, pushed a 7-day fallback to address stratospher's concern, and placed the PR back into draft to investigate IPv6 auto-detection.

Objections, suggestions, and questions:

Support:

• fjahr (member) (Concept ACK, 2026-07-20): (no reason given) [not substantive]
• brunoerg (member) (Concept ACK, 2026-07-22): (no reason given) [not substantive]
• stratospher (member) (Concept ACK, 2026-07-28) [read]: this is what m_last_good is ideally supposed to be doing
• naiyoma (member) (Concept ACK, 2026-08-04): (no reason given) [not substantive]
• naiyoma (member) (2026-08-05) [tested]: tested m_last_good on master and on branch, verifying via logs that handshakes on one network no longer trigger failure counting on another
• fjahr (member) (ACK, 2026-09-28) [read]: Looks good to me, feel free to ignore my nits but adding a bit more documentation on the trade-offs mentioned would be nice if you have to retouch
• naiyoma (member) (Tested ACK, 2026-10-14) [both]: tested IPv4-unreachable / IPv6-reachable scenario on mainnet via iptables, verifying m_last_good and failure behavior, and noted keeping addresses in addrman is acceptable

Participants:

• fjahr (member, support, 5 statements 2026-07-20 to 2026-09-28): ACK; suggested documenting trade-offs for unreachable networks
• brunoerg (member, support, 1 statements 2026-07-22 to 2026-07-22): Concept ACK
• stratospher (member, objection, 2 statements 2026-07-28 to 2026-10-20): Concept ACK; raised concern about unreachable network addresses persisting indefinitely without eviction
• naiyoma (member, support, 3 statements 2026-08-04 to 2026-10-14): Tested ACK; tested mainnet iptables scenario confirming network-specific failure behavior and argued keeping unreachable addresses is acceptable
• sedited (member, neutral, 1 statements 2026-10-19 to 2026-10-19): asked author whether they plan to address review nits

102 lines under test/bench/ci.

• src/test/addrman_tests.cpp +101/-0
• src/addrman.cpp +19/-2
• src/addrman_impl.h +11/-2
• src/addrman.h +3/-0
• src/test/fuzz/addrman.cpp +1/-0

The short text the ranking pass compares across PRs.

Tracks AddrMan's last successful connection timestamp on a per-network basis rather than globally, with a 7-day fallback to global connectivity. This prevents a node with degraded connectivity on a specific network (such as broken IPv6 or Tor) from blaming remote addresses, marking them terrible, and dropping them from address relay while other networks continue functioning. An unreachable network timeout ensures permanently disconnected networks still eventually allow address eviction.

P3 · bug fix (ranking pass: Kept with the other addrman correctness fixes so they can be reviewed coherently.)

Prevents AddrMan from incorrectly penalizing and suppressing valid addresses when only a specific network encounters local connectivity failure. As described in the PR, a global `m_last_good` timestamp causes failed connection attempts on an unreachable network (e.g., IPv6 or Tor) to mark addresses 'Terrible' even though connectivity is functioning on other networks.

Membership: Changes address management in AddrMan (`src/addrman.cpp`, `src/addrman.h`) and carries the P2P label.

Factors: security/stability 1, bug 1, performance 0, user value 1, leverage 0