You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Geth version: Geth/v1.13.1-unstable-16cd1a75
CL client : lighthouse
OS & Version: Linux
Describe the bug
There is 4 issues on the ping packet from discv4 when Geth don't respond to a ping, the issues are spec non compliance issues .
1/ Wrong Version field
According to the devp2p specs, if a node send a ping with a wrong version field in the Ping packet node should respond with a Pong .
If i send a ping packet with the string : !@4><;14/$0$ (&9 in the version field , Geth don't respond.
2/ Wrong To field
According to the devp2p specs and hive test, if a node send a ping with a wrong To field in the Ping packet node should respond with a Pong .
If i send a ping packet with the string : 6;5(7-4? 6&%&0 in the To field , Geth don't respond.
3/ Wrong From field
According to the devp2p specs and hive test, if a node send a ping with a wrong From field in the Ping packet node should respond with a Pong .
If i send a ping packet with the string : 8?)83'-6#394 in the From field , Geth don't respond.
4/ Extra data
According to the devp2p specs and hive test, if a node send a ping with extra data field in the Ping packet node should respond with a Pong .
If i send a ping packet with two additional fields with contains the string -#8<!2'91&3&8!=*:; , Geth don't respond.
Steps to reproduce
You can use the implementation of your choice and send a ping message to a Geth node, or using the devp2p binaries from geth and edit the ping message .
Or you can use D4C, a modified version of geth that send fuzzed message , just clone the repo and use this command (you need to have go in your computer) : make all
then use the corresponding commands that send a ping message :
System information
Geth version: Geth/v1.13.1-unstable-16cd1a75
CL client : lighthouse
OS & Version: Linux
Describe the bug
There is 4 issues on the ping packet from discv4 when Geth don't respond to a ping, the issues are spec non compliance issues .
1/ Wrong Version field
According to the devp2p specs, if a node send a ping with a wrong version field in the Ping packet node should respond with a Pong .
If i send a ping packet with the string : !@4><;14/$0$ (&9 in the version field , Geth don't respond.
2/ Wrong To field
According to the devp2p specs and hive test, if a node send a ping with a wrong To field in the Ping packet node should respond with a Pong .
If i send a ping packet with the string : 6;5(7-4? 6&%&0 in the To field , Geth don't respond.
3/ Wrong From field
According to the devp2p specs and hive test, if a node send a ping with a wrong From field in the Ping packet node should respond with a Pong .
If i send a ping packet with the string : 8?)83'-6#394 in the From field , Geth don't respond.
4/ Extra data
According to the devp2p specs and hive test, if a node send a ping with extra data field in the Ping packet node should respond with a Pong .
If i send a ping packet with two additional fields with contains the string -#8<!2'91&3&8!=*:; , Geth don't respond.
Steps to reproduce
You can use the implementation of your choice and send a ping message to a Geth node, or using the devp2p binaries from geth and edit the ping message .
Or you can use D4C, a modified version of geth that send fuzzed message , just clone the repo and use this command (you need to have go in your computer) :
make all
then use the corresponding commands that send a ping message :
./build/bin/devp2p discv4 wrong-version-ping < enode address > random-fuzzer 1
./build/bin/devp2p discv4 wrong-to-ping < enode address > random-fuzzer 1
./build/bin/devp2p discv4 wrong-from-ping < enode address > random-fuzzer 1
./build/bin/devp2p discv4 extra-data-ping < enode address > random-fuzzer 1
Ressources
The expected behaviors come from :
Devp2p specifications
Hive tests (check the existing unit test and the comments )
The text was updated successfully, but these errors were encountered: