2

Lets say, that there are two networks, Ethereum 1 and Ethereum 2, and they have different blockchains.

How would you configure both networks the way that nodes wouldn't collide with when discovering each other? Because if networks have thousands of nodes, checking chainID is a very time consuming task, there would be a lot of wasted resources if both networks collide with each other.

EDIT: or , in other words, how to you make it that both networks don't interchange TCP / UDP traffic and avoid collisions this way?

Nulik
  • 4,061
  • 1
  • 18
  • 30
  • It could be one answer : In peer to peer networks, the peer discovery often use proxy discovery (node discover other nodes via the connection of his know peers). For example if A and B (on the same network Eth 1) are connected and B is connected to C, B will indicate to A that C is also connected. So A will add C in his peer network. So if everyone (of Eth 1) is initially connect to the bootstrap node of Eth 1, everybody will stay in Eth 1 and it will be impossible for two elements of the 2 distinct blockchains to collude (they will never be in contact of each other). – Adrien Forbu Oct 22 '17 at 20:41
  • Unless someone explicitly adds a node from the second network using the --bootnodes flag... :-) – Richard Horrocks Oct 22 '17 at 21:01
  • @RichardHorrocks, this doesn't work. Tried it. There is still a lot of traffic going , which you can see if you activate debug.verbosity(6) – Nulik Oct 22 '17 at 21:03
  • I meant you can bypass the separation provided by the discovery protocols by deliberately using a node from another network as a bootnode. It used to work (or at least it didn't used to complain), even if they wouldn't talk to each other because of the subsequent handshake failure. – Richard Horrocks Oct 22 '17 at 21:08
  • @RichardHorrocks, well, my private net has bootnodes. my geth client is connected to the bootnode and everything is working ok. But I can see lots of PING/PONG in the log from hundreds of unknown IP addresses. I don't think someone even knows my bootnode IP because my net is not yet public, so this is not the case. I think there is some problem with the discovery mechanism that creates a lot of unnecessary traffic when you use private net. – Nulik Oct 22 '17 at 21:27
  • Aha, okay. I think if you're using the vanilla Geth code, and you haven't removed the hard-coded bootnodes, then you're likely to see this. If you're using vanilla Geth to boot into the public network, then it shouldn't know about any other networks (either private or the ETC/EXP public networks). So in effect, by using the "public" Geth code, with its included hard-coded bootnodes, you're pointing your private network at a bunch of public nodes. – Richard Horrocks Oct 22 '17 at 21:30
  • @RichardHorrocks thats the thing I modified params/bootnodes.go , removed all hardcoded bootnodes and put my own. But despite that I still can see weird traffic in the console. This is how I did it: https://ethereum.stackexchange.com/questions/28007/disabled-private-network-is-still-discovering-nodes – Nulik Oct 22 '17 at 21:44
  • @RichardHorrocks, well, that question doesn't modify bootnodes, but it is still bothering Ethereum's main net while in theory it shouldn't even find any node on the main net. – Nulik Oct 22 '17 at 21:48
  • Interesting. I've just read the other thread you pointed to (and the comments). You said you removed the datadir directory - did that include removing ~/.ethereum/geth/nodes/? (Which is an .ldb database of known nodes?) Could be you had old, discovered nodes in there? – Richard Horrocks Oct 22 '17 at 21:51
  • @RichardHorrocks , no, since .ethereum is the default datadir and I was using my own datadir I didn't remove it because it shouldn't be accessed by geth. But I did a fresh install on a server , ran geth for the first time, and it is still displaying traffic which shouldn't happen. – Nulik Oct 22 '17 at 22:00
  • @RichardHorrocks the bin/bootnode also gets traffic, not only geth – Nulik Oct 22 '17 at 22:33
  • @RichardHorrocks I did some test and found you are correct. I started a geth compiled with nonexistent bootnodes and it was showing connection refused error, no traffic. However as soon as replaced the binary with good bootnodes, the traffic jumped to very high rate, impossible to see the console. Somehow my blockchain database was poisoned with IP addresses from Ethereum's mainnet and now I can't get rid of them. They are replicating like viruses on each new node I am adding in my private net. – Nulik Oct 22 '17 at 23:15
  • @RichardHorrocks , maybe I should start another question: How to clean cached node IP addresses from get data directory ? – Nulik Oct 22 '17 at 23:17
  • @RichardHorrocks `rm -rf [datadir]/geth/nodes doesn't help to clean cached nodes, so even the binary compiled with non-existent bootnodes now is finding Ethereum's main_net nodes which obviously refuse to speak with my nodes since my networkid is different. What happening is that I am spamming the whole Ethereum net due to this. Very bad stuff. – Nulik Oct 22 '17 at 23:36
  • I started my node with --nodiscover option but it is too late. Now my IP address is known by nodes in Ethereum main net and they are trying to connect with me but my node says "Failed RLPx hanshake". I think this issue may only be fixed if we add networkid to the enode url. This is the only way to avoid collisions between networks. – Nulik Oct 23 '17 at 00:55
  • @RichardHorrocks, i did it. check my answer – Nulik Oct 23 '17 at 20:24

3 Answers3

2

I have found an easy solution to make your private network isolated. It does not prevent UDP packet flow, but it does prevent incoming TCP connections. The solution is to change the discovery protocol constants for packet types, so the other network would not understand you. You just have to modify this line of code in p2p/discover/udp.go:

pingPacket = iota + 1 // zero is 'reserved'

adding a constant that is larger than 4, for example:

// RPC packet types
const (
    pingPacket = iota + 64
    pongPacket 
    findnodePacket 
    neighborsPacket 
)

The result is this:

DEBUG[10-23|20:05:32] Bad discv4 packet                        addr=34.236.33.177:30303   err="unknown type: 1"
DEBUG[10-23|20:05:32] Bad discv4 packet                        addr=212.170.201.113:30399 err="unknown type: 1"
DEBUG[10-23|20:05:32] Bad discv4 packet                        addr=41.182.132.197:30399  err="unknown type: 1"
DEBUG[10-23|20:05:33] Bad discv4 packet                        addr=94.63.228.3:30399     err="unknown type: 1"
DEBUG[10-23|20:05:33] Bad discv4 packet                        addr=77.221.88.207:30303   err="unknown type: 1"
DEBUG[10-23|20:05:34] Bad discv4 packet                        addr=86.174.184.92:30399   err="unknown type: 1"
DEBUG[10-23|20:05:34] Bad discv4 packet                        addr=97.91.252.163:30399   err="unknown type: 1"
DEBUG[10-23|20:05:34] Bad discv4 packet                        addr=84.237.99.182:2931    err="unknown type: 1"

Since the rule is to receive a PONG from a PING before connecting, the dialing nodes never get a PONG and the discovery mechanism fails. It only works with your own nodes.

Nulik
  • 4,061
  • 1
  • 18
  • 30
  • +1 for working this out. I notice that there's a discussion going on under issue #15358, and that there's ongoing work on the new version of the discovery protocol. Maybe mark your own answer as accepted, and follow things on that thread :-) (Can always update this answer once the changes to the protocol have been made.) – Richard Horrocks Oct 24 '17 at 08:18
1

This occurs in real time as blocks are being propagated through the network. When a node receives a newly mined block, it will check for the previous block header (the hash of the previously chained block) and accept that block as valid if it contains the correct parent block hash.

So if there two networks Ethereum 1 and Ethereum 2 nodes on each network will know which blocks are for them based the parent block hash included in the newly mined block.

EDIT:

Sorry I didn't read your question correctly. For peer discovery there is a protocol in the Ethereum code for confirming a handshake with another node. It is basically a value that has to be sent along the wire with any other information. So when you boot up an Ethereum node and it goes searching for other nodes on the same port, it will receive a protocol message as specified in the Ethereum code.

jojeyh
  • 769
  • 3
  • 8
  • Are you saying that to make it that both network don't see each other it is enough to change the port number from 30303 to , say 40404 ? This way they wouldn't ever cross a TCP packet between them, right ? – Nulik Oct 22 '17 at 20:51
  • No that needs to be done in general, but clients could always switch ports whenever they feel like it. The real know comes from the handshake protocol which (per the code) requires certain messages to be exchanged during peer discovery. – jojeyh Oct 22 '17 at 20:54
0

Edit the params bootnode.go file, as other people have suggested. I replaced all the public bootnodes with my private bootnode IP (All my nodes and bootnode are inside my LAN) Then recompile the geth and bootnode binary. You also have to delete the nodes cache/folder from your datadir, on every node. Then install the new geth binary on every node. I restarted all my nodes with the bootnode option (pointing to my private bootnode) and discovery mode is ON. I let all the nodes p2p connect successfully. I stopped one of the nodes and restarted it without the bootnode option and it successfully reconnected to my private network without calling any mainnet/testnet bootnodes. In the past (geth compiled with mainnet bootnode IPs) my nodes would constantly try to connect out to mainnet if I forgot the bootnode option and/or nodiscovery option. People who have edited the bootnodes param file and still have issues are probably forgetting to clear their nodes cache/folder or are leaving their listening port (default 30303) exposed to the WAN (Internet)

GusGorman402
  • 441
  • 5
  • 15