Behavior consistency detection of different client devp2p protocol implementations

[1033309821]

I'm working on a project to verify that four Ethereum client devp2p network protocol implementations (Geth, Erigon, Nethermind, Besu and Reth) behave consistently with each other.

While doing devp2p/eth68 experiments, I found that the Besu client's message processing functions are very different:
We repeatedly send the same correct data message to different clients through the developed tool and get their replies. Repeat the above operation over and over again, and the interval between sending data is also the same, such as 10ms, 100ms. However, under the above different time intervals, the other four clients can reply normally, but besu will break the connection (broken pipe) after replying about 100 packets. We are not sure whether this is due to the limitation of besu's own implementation or a real bug?

In addition, for the 'Getblockheaders' packet in the eth68 protocol, if I change the 'Amount' field to a large value, the upper limit of the reply of the other four clients is 1024, and besu is 512.

Versions (Add all that apply)

• Software version: besu-25.2.0
• Java version: jdk 21.0.6
• OS Name & Version: Ubuntu 20.04.3 LTS

Additional Information (Add any of the following or anything else that may be relevant)

• Geth v1.13.8
• Reth v1.1.4
• Erigon v2.60.10
• Nethermind v1.30.3

[jflo]

Can you point us to the tooling used to reproduce this?

[1033309821]

Can you point us to the tooling used to reproduce this?

Sure, You can use D2PFuzz to execute the command:
./D2PFuzz bench --protocol "eth" --target ./test/enode_besu.txt --chain ./test/ethdata-2 --count 1 --ptype "GetBlockHeaders"
You need to replace enode.txt with the correct test node enr or enode. ethdata We use the simulated data from etherum-package and import them into besu. D2PFuzz/fuzzer/config.go is some configuration parameters that can set the number and interval of packets sent by a bench.

[1033309821]

By the way, the genesis of the besu client is different from other clients. It cannot be started directly using the file import in the program. In addition, there is a problem with the besu.json provided by ethereum-package. You need to use the corrected besu.json to start the node, and then import the data of ethdata-2/chain.rlp. We have reported this to ethereum-package.

besu.json