Dmitry Markin

To share intermediate results: I was able to reproduce the issue on polkadot+substrate master, but also on polkadot-0.9.28 & polkadot-0.9.16. So, it looks like this is not something introduced by...

> I didn't look into warping, but if it downloads significant chunks of data, it might have the same root cause as #12105, namely keep alive timeout. I tried reducing...

@EclesioMeloJunior do I understand correctly that you are not getting `Duplicate gossip` reports? I.e, `TRACE tokio-runtime-worker peerset: Report 12D3...: -4 to ###. Reason: Duplicate gossip`. Do you have any idea...

Looking at the log messages produced it looks like the packets can only differ in [`commit_finalized_height`](https://github.com/paritytech/substrate/blob/20037d573c0c2b319998541c6140df4c3d07eb56/client/finality-grandpa/src/communication/gossip.rs#L376)

It looks like sending [`NeighborPacket`s](https://github.com/paritytech/substrate/blob/20037d573c0c2b319998541c6140df4c3d07eb56/client/finality-grandpa/src/communication/gossip.rs#L370) with increasing [`commit_finalized_height`s](https://github.com/paritytech/substrate/blob/20037d573c0c2b319998541c6140df4c3d07eb56/client/finality-grandpa/src/communication/gossip.rs#L376) is perfectly legitimate behavior when a peer processes GRANDPA commit messages in [`mod.rs:567`](https://github.com/paritytech/substrate/blob/20037d573c0c2b319998541c6140df4c3d07eb56/client/finality-grandpa/src/communication/mod.rs#L567). Therefore it's not trivial to distinguish spamming neighbor messages...

> I executed another tests and I make sure that the neighbor message keep the same Thanks, this makes the matter more interesting. Going to investigate further.

Thanks @EclesioMeloJunior for the exhaustive gist with instructions! I've reproduced the error and is seeing the reputation of gossamer node increasing every second. Looking into substrate part.

Here is the draft PR for reference: https://github.com/paritytech/substrate/pull/12256

What is the desired behavior? Not to count reserved peer connections as occupying slots?

Partially resolved (for reserved nodes, added on startup) in https://github.com/paritytech/substrate/pull/11909 We should also account for reserved nodes, added at runtime via RPC. To implement this, we should refactor `Peerset` first...