p2p: fix seed/priority ban exemption for portless pins; skip serving rejected connections - #66
Open
DHEBP wants to merge 2 commits into
Open
p2p: fix seed/priority ban exemption for portless pins; skip serving rejected connections#66DHEBP wants to merge 2 commits into
DHEBP wants to merge 2 commits into
Conversation
… conns IsAddressInBanList returned true (banned) for nonbanlist entries, the opposite of the documented "never banned" intent, and the compare never matched because entries are stored as host:port while callers pass a bare IP. Normalize the stored entry and return false so seed, exclusive and priority nodes are actually exempt. The incoming-accept loop closed already-connected and banned connections but then fell through to tls.Server/ServeCodecWithState on the closed socket. Add continue after each close, matching the loop's existing rate-limiter and accept-error branches.
The previous commit made the seed/exclusive/priority exemption actually match by normalizing every nonbanlist entry to a bare IP. That also made it match ip:port entries -- every compiled-in seed and any pin given with a port -- and for those addresses Ban_Address accepted the ban with no error, IsAddressInBanList never enforced it, and UnBan_Address then reported "not found in ban list" for an entry that was actually present. A ban that succeeds, does nothing, and cannot be undone. isNonBannable now canonicalizes only entries that already parse as a bare IP -- a pin given without a port. net.ParseIP fails on ip:port and on a hostname, so every seed and every ported pin stays bannable and evictable exactly as before this PR. Ban_Address refuses a genuinely exempt address with an error, which both callers in main.go now print (one previously discarded the error entirely). Tests cover the inversion, that ported pins and seeds are unaffected, IPv6 canonical-form matching, that a refused ban leaves nothing for unban to lie about, and that ordinary bans are untouched. Verified locally: build, vet, test, and -race all green; this branch has no CI.
DHEBP
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two small p2p fixes, both non-consensus.
The "never ban seed/exclusive/priority nodes" exemption never worked. IsAddressInBanList returned true (banned) for those entries, backwards from the comment, and it never matched anyway since nonbanlist stores host:port while callers pass a bare IP.
It's fixed to make the exemption real for a pin given without a port (e.g.
--add-priority-node=1.2.3.4), which is the case that was actually broken -- such a pin was getting refused as "banned" with no ban ever placed. Entries that already have a port (every compiled-in seed, and any pin given with one) are deliberately left unmatched, so they stay bannable and evictable exactly as before this PR. Ban_Address now refuses to ban a genuinely exempt address, with an error the console prints, instead of silently recording a ban that would never be enforced. SeeisNonBannablein p2p/bans.go for exactly what is and isn't covered.The incoming accept loop closed already-connected and banned connections but didn't continue, so it fell through to tls.Server + ServeCodecWithState on the closed socket — wasted work on every rejected connection. Added continue after each close, matching what the loop already does for the rate limiter and accept-error branches.
Note: Ban_Address has a comment implying it also guards seed nodes, but it doesn't -- it never checks the list. The exemption is enforced there now too.
Tests: p2p/bans_test.go, 5 cases covering the inversion, that ported pins/seeds are unaffected, IPv6 canonical-form matching, that a refused ban leaves nothing for unban to lie about, and that ordinary bans are untouched.
Update: the first version of fix 1 above normalized every nonbanlist entry, which made ip:port entries match too -- every compiled-in seed and any ported pin. For those, Ban_Address accepted the ban with no error, IsAddressInBanList never enforced it, and UnBan_Address then reported "not found in ban list" for an entry that was actually present -- a ban that succeeds, does nothing, and can't be undone. Narrowed to portless entries only and added the tests above; verified locally (build/vet/test/-race all green -- this branch has no CI).
Known, unrelated, not touched here:
unbanon a subnet member can report success while a covering supernet ban still applies. Pre-existing oncommunity-dev, unaffected by this PR.