In p2p/5, after the hello message, all subsequent messages should be snappy-compresssed, but when Nethermind has reached max peers, it sends its disconnect message uncompressed - this leads a protocol violation in nimbus which causes that peer to be downscored.
From the spec:
All messages following Hello are compressed using the Snappy algorithm.
No other messages may be sent until a Hello is received.
Here's a debug log:
2024-11-05 23:38:35.480+01:00 Peer sent us topics="eth p2p rlpx" remote=Node[91.134.22.6:30401] msgBody=01c104
2024-11-05 23:38:35.480+01:00 TODO Raising protocol breach topics="eth p2p rlpx" remote=Node[91.134.22.6:30401] clientId=Nethermind/v1.26.0+0068729c/linux-x64/dotnet8.0.4 msg="Could not decompress snappy data"
This happens for multiple nethermind versions - we can see the message being 01c104 which effectively is a TooManyPeers disconnect, but uncompressed. This follows the hello message from which the client id has been taken.
In p2p/5, after the hello message, all subsequent messages should be snappy-compresssed, but when Nethermind has reached max peers, it sends its disconnect message uncompressed - this leads a protocol violation in nimbus which causes that peer to be downscored.
From the spec:
Here's a debug log:
This happens for multiple nethermind versions - we can see the message being
01c104which effectively is aTooManyPeersdisconnect, but uncompressed. This follows the hello message from which the client id has been taken.