3

I'm trying to understand the peer discovery process, especially for a private network with majority of the nodes having dynamic IP addresses and behind typical wifi router firewall. If I run a Geth node with --nodiscovery flag, the node will only call out/connect to other peers, not accept calls from peers, correct? Isn't my firewall already doing that? And those peers my node calls out to must have port 30303 open, and they must be in discovery mode, correct? If my node is in NOdiscovery mode, I need a bootnode list or manually add (via file or CLI) static nodes in a private network, correct? Basically, if a new private network was created, some of the nodes would have to be in discovery mode and/or have port 30303 open on the WAN side, or the network would fail, correct? And does a private network have to supply a bootnode list everytime I restart Geth?

GusGorman402
  • 441
  • 5
  • 15
  • study this question" https://ethereum.stackexchange.com/questions/29029/how-to-avoid-collisions-between-ethereum-like-networks/29096#29096 – Nulik Nov 19 '17 at 15:53
  • I found this dissection of ping pong https://ocalog.com/post/10/ but I still don't really understand the nodiscovery option. Does it set the node so it ignores all PINGs? – GusGorman402 Nov 20 '17 at 06:01
  • no exactly. --no-discovery tells your node to stop PINGing other nodes. But if your node was discovered by other nodes. they will save your IP in the database, and they will PING your node and it will respond with a PONG. After PONG they will try to connect but connection won't succeed since the blockchain's genesis block is different. These nodes will ping you forever generating traffic. Use tcpdump and verbosity.debug=6 to see what happens at networking layer. – Nulik Nov 20 '17 at 21:34
  • This is very odd. I am yet to use tcpdump or wireshark. I have a private PoA network setup inside my LAN. 7 nodes, and 1 bootnode. They all sync up and work fine, but I never turned up the verbosity to 4. While my private network was running, I released renewed my WAN IP address, but even then I still got random connections trying to handshake with my private network. Maybe I don't understand firewalls or UDP completely, but I thought my router firewall blocked all incoming PINGs. It seems more like my nodes are trying to call out. But I haven't done tcpdump yet – GusGorman402 Nov 26 '17 at 09:43
  • if you ever run geth from your net to connect to Ethereum's main net, just once, for example for testing, you will pollute your IP addresses with discovery protocol, other nodes will try to connect to you.Also, your router may have UPnP enabled and your node may be discovered this way. – Nulik Nov 26 '17 at 12:12
  • By default geth has --maxpeers set at 25. When I run Rinkeby network, I have tons of nodes with different network IDs trying to connect(and vice versa) resulting in bad handshakes/differing genesis block. But if I connect to Rinkeby with --maxpeers set to 2 or 3, I don't have the problem anymore. When I start my private network, I have to disconnect my router from the WAN(cable modem), or else it spends about 20minutes trying to connect to other nodes before it tries my LAN private bootnode and private nodes – GusGorman402 Nov 27 '17 at 04:31
  • I think I fixed the problem for my private network. I deleted the nodes folder inside the geth directory on every node, then restarted the network. I think I have to use the --bootnode option EVERY time I load up my private nodes. I thought I only had to use -bootnode the first time for new nodes. Then after the first time, the node remembers those peer IP addresses and automatically searches for them next run. This does work, however the one time I started my network without a private bootnode, it by default connected out to public mainnet bootnodes and polluted my private node peer database – GusGorman402 Nov 27 '17 at 05:54
  • I found I also have to use the -nodiscover option also. Even after removing the nodes folder, the network worked fine for about an hour then suddenly started trying to connect to external peers. I think maybe it was a single node that caused the problem, possibly it had a bad network connection with my private bootnode and defaulted back to the public bootnode. I turned nodiscover on just one of my nodes for testing, and it is protecting that specific node from all these mainnet IP addresses that keep infecting my private p2p database. – GusGorman402 Nov 27 '17 at 08:39
  • Nodiscover option isn't so great either. Some of my nodes have problems connecting. I think you have seen this issue https://github.com/ethereum/go-ethereum/issues/15358 Everybody is just doing quick fixes until the developers work out a solution lol. I think I'm just going to set my firewall up to block all PINGS and PONGS from outside my LAN. – GusGorman402 Nov 27 '17 at 09:43

1 Answers1

1

The --nodiscover option works the other way. If you run geth with this option, the geth node will not search for any peer and not connect to any peer. So yes, you will need a bootnode list or add peers manually if you use the --nodiscover option. However, you need it for your node, not for the others.

As far as I know, you cannot hold back other nodes from connecting to your node, besides changing or blocking the port used for peer discovery. The default for that port is 30303, that's right, you can change it with the --port option.

To answer your question: --nodiscover is not redundant behind a firewall without port forwarding, since it achieves a different goal.

gisdev_p
  • 1,801
  • 1
  • 9
  • 18
  • My firewall blocks all the ports, so I am holding back other nodes from connecting to my node. From the Go-Ethereum documentation "Geth continuously attempts to connect to other nodes on the network until it has peers. If you have UPnP enabled on your router or run ethereum on an Internet-facing server, it will also accept connections from other nodes" – GusGorman402 Nov 20 '17 at 05:43
  • I kinda get it now. There's been issues with folks private networks trying to connect with the mainnet, mine included. I have to use --nodiscover to prevent this. – GusGorman402 Nov 27 '17 at 09:45