Router: demote cross-channel decrypt failures from ERROR to DEBUG#10259
Merged
thebentern merged 1 commit intoApr 23, 2026
Merged
Conversation
The "Invalid protobufs (bad psk?)" and "Invalid portnum (bad psk?)" messages fire every time a neighbor transmits on a channel whose 8-bit hash matches one of ours but the PSK differs. In RF environments with multiple mesh groups nearby this is routine — a single device can see dozens of these per minute from SAR/MeshCA/private networks sharing a hash collision. LOG_ERROR for a benign "not our PSK" event: - spams the log when you have any neighboring mesh group - makes a genuine PSK misconfiguration on YOUR own channel indistinguishable from the constant cross-channel noise - hides actual errors in the stream LOG_DEBUG matches how similar decryption-failure paths are handled elsewhere (eg. the PKC "decrypt attempted but failed" uses LOG_WARN). Dropping the trailing "!" as well — these are expected events, not exceptional ones.
nightjoker7
added a commit
to nightjoker7/firmware
that referenced
this pull request
Apr 23, 2026
…shtastic#10259) The "Invalid protobufs (bad psk?)" and "Invalid portnum (bad psk?)" messages fire every time a neighbor transmits on a channel whose 8-bit hash matches one of ours but the PSK differs. In RF environments with multiple mesh groups nearby this is routine — a single device can see dozens of these per minute from SAR/MeshCA/private networks sharing a hash collision. LOG_ERROR for a benign "not our PSK" event: - spams the log when you have any neighboring mesh group - makes a genuine PSK misconfiguration on YOUR own channel indistinguishable from the constant cross-channel noise - hides actual errors in the stream LOG_DEBUG matches how similar decryption-failure paths are handled elsewhere (eg. the PKC "decrypt attempted but failed" uses LOG_WARN). Dropping the trailing "!" as well — these are expected events, not exceptional ones.
mariotti
pushed a commit
to mariotti/firmware
that referenced
this pull request
May 6, 2026
…shtastic#10259) The "Invalid protobufs (bad psk?)" and "Invalid portnum (bad psk?)" messages fire every time a neighbor transmits on a channel whose 8-bit hash matches one of ours but the PSK differs. In RF environments with multiple mesh groups nearby this is routine — a single device can see dozens of these per minute from SAR/MeshCA/private networks sharing a hash collision. LOG_ERROR for a benign "not our PSK" event: - spams the log when you have any neighboring mesh group - makes a genuine PSK misconfiguration on YOUR own channel indistinguishable from the constant cross-channel noise - hides actual errors in the stream LOG_DEBUG matches how similar decryption-failure paths are handled elsewhere (eg. the PKC "decrypt attempted but failed" uses LOG_WARN). Dropping the trailing "!" as well — these are expected events, not exceptional ones.
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
2 participants
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.
Summary
The "Invalid protobufs (bad psk?)" and "Invalid portnum (bad psk?)" messages in src/mesh/Router.cpp:502-504 fire whenever a neighbor transmits on a channel whose 8-bit hash collides with one of ours but the PSK differs. In RF environments with multiple mesh groups nearby this is routine — not an error.
Why this matters
The channel hash is only 8 bits (XOR-fold of name + PSK & 0xFF), so with enough neighboring mesh groups, hash collisions are inevitable. In real-world monitoring across a single 24-hour window I counted 17 distinct cross-channel hashes hitting the device, including SAR groups, MeshCA, Tango/Whiskey (NATO), and private community networks. Each of those that hash-collides with one of our configured channels triggers these two LOG_ERROR lines every single packet.
Effects:
Fix
Demote both to
LOG_DEBUG. This matches how similar decrypt-failure paths are already treated — eg. the PKC "decrypt attempted but failed" path a few lines above usesLOG_WARN, and genuinely catastrophic paths (oversize packet, pb_decode fatal) useLOG_ERROR. Also drops the trailing "!" since these are expected events.Test plan
LOG_DEBUGoutput when enabledRelated
Part of an ongoing log-hygiene sweep. Related: #10255 (missed RX_DONE WARN→DEBUG, same spirit).