hive: reth does not respond to eth/TestMaliciousHandshake properly

[Rjected]

Describe the bug

The hive simulator for the eth/TestMaliciousHandshake test does cause reth to fail the handshake, but not in the right way. The simulator outputs the following logs:

skipping suite "discv4" because it doesn't match test pattern eth/TestMaliciousHandshake
1..1
not ok 1 TestMaliciousHandshake
# Testing malicious handshake 0
# dial failed: read tcp 172.17.0.3:35620->172.17.0.4:30303: read: connection reset by peer
exit status 1
skipping suite "snap" because it doesn't match test pattern eth/TestMaliciousHandshake

This is how reth terminates the connection:

2023-02-22T20:32:08.611565Z TRACE Sending disconnect message during the handshake reason=Useless peer
2023-02-22T20:32:08.614217Z TRACE disconnected pending session session_id=SessionId(0) remote_addr=172.17.0.3:35606 error=Some(P2PStreamError(HandshakeError(NoSharedCapabilities)))
2023-02-22T20:32:08.614258Z  WARN Incoming pending session failed remote_addr=172.17.0.3:35606 error=Some(Eth(P2PStreamError(HandshakeError(NoSharedCapabilities))))
2023-02-22T20:32:08.614297Z TRACE The incoming ip address is in the ban list remote_addr=172.17.0.3:35620

This places the IP in the ban list, which causes problems for all succeeding hive tests, because the IP is the same for the rest of the tests.

The other issue is that because of this, the test cannot establish a connection for its other malicious handshakes, since TestMaliciousHandshake actually tests sending multiple malicious handshakes that should not succeed.

Steps to reproduce

Follow instructions in #851 for running hive, and run the devp2p tests.

This was run with reth logs set to:

RUST_LOG=net=trace,reth_eth_wire=trace 

Node logs

No response

Platform(s)

No response

What version/commit are you on?

No response

Code of Conduct

• I agree to follow the Code of Conduct

[mattsse]

The other issue is that because of this, the test cannot establish a connection for its other malicious handshakes, since TestMaliciousHandshake actually tests sending multiple malicious handshakes that should not succeed.

this is in the same test with same PeerId?
can you please link that here.

[Rjected]

Update:

This happens because we ban the hive simulator container's IP after it sends the first malicious handshake. These containers have non-routable IPs however, so we do not necessarily need to IP ban them. To fix this, we should create a helper is_global method that determines whether or not the IP is globally routable, similar to the nightly IpAddr::is_global method. We should not ban non-routable peers.

Geth also implements this functionality, which is why it does not throttle hive test peers.