#34486 net: Reduce local network activity when networkactive=0

• Stop port mapping and Tor control connections when networkactive=0
• Fulfills user expectations of full network inactivity and prevents unwanted local background traffic

This pull request wires NAT-PMP/PCP port mapping and Tor control port connections into CConnman's network active lifecycle. When networkactive=0 is set at startup or toggled via the setnetworkactive RPC, port mapping and Tor connection attempts are paused, and then properly resumed with reset backoff upon reactivation.

Problem: When -networkactive=0 is configured, the node still attempts NAT-PMP port mapping and repeatedly tries to connect to the Tor control port in the background, violating user expectations of a completely inactive network state and generating unnecessary network traffic.

P3 · bug fix

• P3 because it stops unintended local network traffic while networking is marked inactive
• Provides privacy and isolation guarantees expected by users
• Marginal impact because it does not fix a consensus, remote DoS, or peer protocol bug

P3 because it resolves an unexpected behavior bug where local network traffic and port mappings still occur while the network is supposedly inactive. As described in #34190, users setting networkactive=0 expect all local networking daemon attempts to stop. It provides worthwhile polish and privacy/isolation guarantees, but does not fix a consensus, remote DoS, or peer protocol vulnerability.

Membership: Touches CConnman network activation logic, torcontrol.cpp, and NAT-PMP port mapping under the P2P area.

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

• Needs rebase due to merge conflicts with master
• Awaiting author action on an edge-case patch and conflicts

The PR has merge conflicts with master and has a pending edge case discussion awaiting author action.

Author status: silent since 2026-08-17

Open concerns:

• winterrdog noted an edge case where rapid off/on toggling during a backoff sleep will increase backoff delay rather than resetting it, providing a reproduction test and patch.

Resolved concerns:

• bradleystachurski identified that reconnect backoff was not reset on reactivation, which the author fixed.
• brunoerg raised test flakiness and coverage improvements, which the author addressed across functional tests.

• Broad concept and approach agreement across multiple reviewers
• Verified NAT-PMP and Tor teardown in Docker (brunoerg)
• Concept approval without stated reasons (sedited, fanquake, Jhackman2019)
• Approach approval with an edge-case note on backoff during rapid toggles (winterrdog)

Concept and approach accepted across multiple reviewers; winterrdog noted one backoff edge case during sleep.

Multiple contributors and maintainers ACKed the concept and approach. Brunoerg tested and approved a previous revision, and winterrdog approach-ACKed the current head while offering a fix for a minor backoff race during rapid toggling.

• sedited, fanquake, Jhackman2019, and brunoerg gave Concept ACKs.
• brunoerg approved commit e5ed5f2 after verifying NAT-PMP and Tor traffic teardown in a Docker environment.
• winterrdog gave Approach ACK on 48f1321 while opening a discussion on backoff handling during rapid deactivation.

Review verdicts (DrahtBot): 0 (+1)

• Stale ACK: brunoerg
• Approach ACK: winterrdog
• Concept ACK: sedited, fanquake, Jhackman2019

File list not available for this run.

PR #34486 wires the lifecycle of NAT-PMP/PCP port mapping and Tor control connections to CConnman's networkactive state so that both pause when networking is disabled and resume when reactivated. It solves issue #34190, where bitcoind continued background network calls despite networkactive=0. The PR has strong support and testing from multiple contributors, but it is currently stale with merge conflicts and an unaddressed edge case regarding reconnect backoffs during rapid off/on cycles.