2

I am trying to run a private network and I'm doing this by providing a bootnode for all my nodes. Every now and then I notice on my nodes that I will receive peers from outside the network. Upon further inspection admin.peers I notice that they are handshakes with public pools. I do not understand how this is occurring as I have overridden the default bootstrap nodes by providing the --bootnode flag so my nodes should not be able to find other nodes outside my network to handshake with?

Improve this question
3
  • Do all your private nodes have the same networkid and genesis file? – Richard Horrocks Mar 18 '17 at 14:37
  • Yes they all have the same genesis and are all connecting to the same bootnode. They all connect to each other fine. I however sometimes see the number of peers increase by 1 or 2 more than the maximum a node should have. When inspecting 'admin.peers' I see that a handshake is taking place with a node not on my network. – John Mar 20 '17 at 10:24
  • I wonder if this is actually something bad... The protocols: {eth: "handshake"}protocol is "handshake" and they normally don't last long. Whereas actual peers have more detail in it protocols: { eth: { difficulty: X, genesis: "0xX", head: "0xX", network: X } } – Betty Sanchez Mar 31 '17 at 19:47
2

I am having a similar issue. I am not overriding the bootnode and therefore I am not using the --nodiscover flag. However, I have 2 nodes -sharing the same genesis file and network id, running on 2 different Virtual Machines but they don't recognize each other as peers. The protocols node from admin.nodeInfo in the geth console is the same on both nodes:

protocols: {
      eth: {
        difficulty: X,
        genesis: "0xX",
        head: "0xX",
        network: X
      }
}

Yet, although they don't acknowledge each other, depending on when I run admin.peers I normally get 

> admin.peers
[]

but at times a new random node appears:

[{
    caps: ["eth/62", "eth/63", "par/1", "par/2"],
    id: "X",
    name: "Parity/v1.5.11-stable-f067f12-20170314/x86_64-linux-gnu/rustc1.15.1",
    network: {
      localAddress: "172.17.0.2:55516",
      remoteAddress: "X"
    },
    protocols: {
      eth: "handshake"
    }
}]

I've been running nodes over randomly chosen network Id's to find one where there are no unknown peers but no matter how big the number, there always seems to be one random node appearing at some point and it is not always with the same configuration.

Improve this answer
6
  • I have the same genesis file across all my nodes. My nodes are all configured to use my bootnode using the --bootnodes command. I am not using the no-discover flag as my nodes to to discover the other nodes on the network from the bootnode? Mine are also all handshakes that get rejected. – John Mar 24 '17 at 13:39
  • Because you are using a bootnode you can use it along the --nodiscoverand discovery is supposed to be made by your bootnode. Adding the flag is supposed to isolate your blockchain and make it private. Make sure you add the flag when you start a node and that every node references the bootnode either with --bootnode or with a static-nodes.json file on the nodes. Try this configuration and see if your nodes are being discovered. Let me know if it worked – Betty Sanchez Mar 24 '17 at 18:47
  • I have tried using --nodiscover before but this makes my nodes and bootnode not connect to each other even though I explicitly define a bootnode to connect to. – John Mar 27 '17 at 13:24
  • yes, actually the --nodiscover flag is not very useful for this. Try instead using a smaller network id and check this post and see if it helps. – Betty Sanchez Mar 27 '17 at 15:12
  • I have tried both a small (5 digits) and a large network id (10 digits). The issue still persists unfortunately. – John Mar 29 '17 at 10:13
1

Using the option --nodiscover while starting the geth console will prevent handshakes with external nodes. I have tried this and it works. Unfortunately for me, I am still unable to establish a handshake between the two nodes of my private blockchain on AWS.

Improve this answer
3
  • Yes, this has been me experience using --nodiscover – John Mar 27 '17 at 13:23
  • Please try a different networkid (say a 5 digit value) and then see if it re-occurs? – Parthasarathy Ramanujam Mar 27 '17 at 14:05
  • I have tried a 5 digit network id as well as a longer one. The issue still persists. – John Mar 29 '17 at 10:10
0

If you recently connected to the mainnet or testnets, bootnodes and peers from those networks may still have your IP address in their databases. They will try to connect automatically. A firewall should stop that. Changing the listening port of your private network can help. Also, if any of your Geth private nodes are started without a private bootnode running and bootnode option and nodiscover option, the node will automatically connect to the public hardcoded bootnodes, and will start trying peers from the mainnet & testnets. It will save these IP addresses in your datadir, share them with other private nodes in your network, and continually try connecting to them even after a reboot and using a private bootnode afterwards. You have to delete the datadir nodes folder on every node to fix it. The nodiscover option is most important though, or you can manually add peers instead of using a private bootnode. I also edited the params bootnode.go file before compiling the geth binary. Change all the bootnodes in that file to the enode address of your private bootnode. That solved the problem for me.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.