Aggressive peer connection burst at startup (can look like port scanning)
Maintainers usually reply within 2 days
@akrem-chabchoub is already working on this.
Since Sep 3, 2026.
Assessment
This issue has not been assessed yet.
Description
Context
- Bee version: 2.7.1-rc2
- Mode: ultra-light (no RPC), mainnet, existing data dir with populated address book
- Config:
full-node: false,blockchain-rpc-endpoint: "",mainnet: true,verbosity: debug
Summary
On startup, the node connects to bootnodes then immediately tries to connect to every peer in the address book in one go. That produces a large burst of outbound TCP connection attempts to many IPs/ports in a short time. Many attempts fail (stale addresses, private IPs, unreachable IPv6), but the pattern can look like port scanning to network monitoring or firewalls. In a restart loop (e.g. when RPC is down), this burst repeats every restart and amplifies the effect.
Expected behavior
Startup peer discovery should be gradual: connect to bootnodes first, then add and connect to address-book peers in a limited or staggered way so we don’t blast hundreds of connection attempts in the first seconds.
Actual behavior
- Node starts and connects to bootnodes (e.g. 3).
- Kademlia loads the full address book from disk and adds all peers as known (batches of 500).
- The manage loop runs immediately and tries to connect to many of those peers in parallel.
- Result: hundreds of "attempting connect to peer" and "libp2p connect" attempts in a short window; many fail (connection refused, i/o timeout, no route to host). Log grows very large (e.g. hundreds of thousands of characters).
Relevant log excerpts (verbosity debug):
Startup and bootnode connections:
"time"="2026-02-23 14:49:54.370753" "level"="info" "logger"="node" "msg"="chain backend disabled - starting in ultra-light mode" "full_node_mode"=false "blockchain-rpc-endpoint"=""
"time"="2026-02-23 14:49:54.371014" "level"="info" "logger"="node" "msg"="using chain with network" "chain_id"=100 "network_id"=1
"time"="2026-02-23 14:50:04.845372" "level"="debug" "logger"="node/libp2p" "msg"="successfully connected to peer (outbound)" "address"="6b2bbaefb45f2e3a5bcfde27efa4acf0b646422a3a93152dccd07652e61cd419"
"time"="2026-02-23 14:50:16.387694" "level"="debug" "logger"="node/libp2p" "msg"="successfully connected to peer (outbound)" "address"="b0901e49ce52ed334be87917260020d62247c94936a792b27b708c415559b8fd"
"time"="2026-02-23 14:50:26.776554" "level"="debug" "logger"="node/libp2p" "msg"="successfully connected to peer (outbound)" "address"="a8ef8f87372897bfb37e2614a38d801ba3561ea14e8e4a9d3e67ccb5499be82c"
Immediately after, Kademlia starts a burst of connection attempts (same second):
"time"="2026-02-23 14:50:26.779170" "level"="debug" "logger"="node/kademlia" "msg"="attempting connect to peer" "peer_address"="a445397b498ce9cc05c12c24a281cd20fba88102ac24ac44d805d10987ae2eef"
"time"="2026-02-23 14:50:26.779279" "level"="debug" "logger"="node/kademlia" "msg"="attempting connect to peer" "peer_address"="b414b4c2a5e041509a16756a76e290b9e6db5dbfa2903c0614717d36b278414d"
"time"="2026-02-23 14:50:26.779363" "level"="debug" "logger"="node/kademlia" "msg"="attempting connect to peer" "peer_address"="dcc5bb419e24164892fc67b3934bb3168c9d7668ae224ec23c26779882967244"
"time"="2026-02-23 14:50:26.779584" "level"="debug" "logger"="node/kademlia" "msg"="attempting connect to peer" "peer_address"="94085d1cd13219c6b7d0dedbd81ed4fb63772d6434329b24625a9f02cead4beb"
"time"="2026-02-23 14:50:26.779663" "level"="debug" "logger"="node/kademlia" "msg"="attempting connect to peer" "peer_address"="fc5c6e007f5a2089ad551d55d529de2ddfe3083361f1b9b0f2f4443583f7a12f"
"time"="2026-02-23 14:50:26.779650" "level"="debug" "logger"="node/kademlia" "msg"="attempting connect to peer" "peer_address"="99fba5149f92fce4394ff48785c2b4f74f9e97974f8be0fb4ff886176ec6e993"
... (many more in same second)
Failures (connection refused, private IP timeouts, IPv6 no route):
"time"="2026-02-23 14:50:26.904886" "level"="warning" "logger"="node/libp2p" "msg"="libp2p connect" "peer_id"="QmWNHYruQVrBYyEeZqXn5RbE38mAEamhGfNhnAbJaVTPd3" "underlay"=["/ip4/46.212.38.179/tcp/49856"] "error"="... dial tcp4 46.212.38.179:49856: connect: connection refused"
"time"="2026-02-23 14:50:26.905353" "level"="info" "logger"="node/kademlia" "msg"="could not connect to peer" "peer_address"="99fba5149f92fce4394ff48785c2b4f74f9e97974f8be0fb4ff886176ec6e993" "error"="... connection refused"
"time"="2026-02-23 14:50:42.134581" "level"="warning" "logger"="node/libp2p" "msg"="libp2p connect" "underlay"=["/ip4/10.233.86.42/tcp/1634"] "error"="... dial tcp4 10.233.86.42:1634: i/o timeout"
"time"="2026-02-23 14:50:42.134752" "level"="warning" "logger"="node/libp2p" "msg"="libp2p connect" "underlay"=["/ip4/10.233.88.6/tcp/1634"] "error"="... i/o timeout"
"time"="2026-02-23 14:50:04.846461" "level"="debug" "logger"="node/libp2p/reacher" "msg"="ping failed" "addr"="/ip6/2a03:b0c0:2:d0::10bf:e001/tcp/1634/..." "error"="... connect: no route to host"
Steps to reproduce
- Run a Bee node on mainnet with RPC for a while so the address book gets populated (or use an existing data dir that already has many peers).
- Stop the node then emove RPC config.
- Start Bee again with the same data dir.
- Observe logs: right after bootnode connections, many "attempting connect to peer" (kademlia) and "libp2p connect" (success or warning) lines in a short time; many failures to private IPs (10.x), stale ports (connection refused), or IPv6 (no route to host). Log file grows quickly.
Possible solution
Spread it out: Don’t add the whole address book at once. Add peers in small chunks over time (e.g. 50 every 10–15 seconds) instead of 500 in one go. That way connection attempts are spread over time and we avoid a big burst at startup. Same peers get tried, just not all in the first few seconds.
- Dominant language
- Go
- Stars
- 1.5k
- Forks
- 390
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 23
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from ethersphere/bee
-
Chequebook deployment uses a fixed 175,000 gas limit; it needs about 630,000 under Glamsterdam (live on Sepolia since 2026-10-06)Possibly taken @sbackend123 claimed this 10 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
ethersphere/bee#5650 · 1 assignee ·
Maintainers usually reply within 2 days
-
Add a transaction inbox for outbound chain transactionsPossibly taken @sbackend123 claimed this 4 days ago. Openseen
Difficulty 5/5 Over a week Newbie friendliness 35/100
ethersphere/bee#5660 · 1 assignee ·
Maintainers usually reply within 2 days
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
ethersphere/bee#5659 ·
Maintainers usually reply within 2 days
-
accepted seen
Difficulty 4/5 3-5 days Newbie friendliness 40/100
ethersphere/bee#5648 · 1 comment ·
Maintainers usually reply within 2 days
-
pusher: chunksWorker deadlocks on a deferred chunk that fails IdentityAddress (send on nil op.Err), halting all push-syncPossibly taken @sbackend123 claimed this 12 days ago. Openseen
Difficulty 3/5 1-2 days Newbie friendliness 75/100
ethersphere/bee#5641 · 1 assignee ·
Maintainers usually reply within 2 days
Similar issues
-
good first issue help wanted v3
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
oras-project/oras-go#1621 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
Maintainers usually reply within 4 days
-
Chained slog With calls discard previously bound attributesPossibly taken @yuefdev claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
[scanner] TestAgentNowLineStates hard-fails instead of degrading when node is off PATHPossibly taken @arteeh claimed this today. Openagent/scanner ci help wanted kind/test
Difficulty 1/5 Under an hour Newbie friendliness 90/100
hivecommons/hive#12924 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Gentleman-Programming/engram#1940 ·
Maintainers usually reply within 1 day