2
  • Geth version: v1.6.0-unstable-1018bf6a/linux/go1.7.3
  • OS & Version: Linux/Ubuntu 16.04.1 LTS (x86_64)

I want to set up a private distributed blockchain network. I am failing to make nodes (running on different machines) recognize each other.

Both nodes have the same genesis file and are connected to the same networkId.

INFO Successfully wrote genesis state  hash=X (hash equal on both nodes)

The UDP Port 30301 of the bootnode is open

> netcat -u -z -v <PUB-IP> 30301
Connection to <PUB-IP> 30301 port [udp/*] succeeded!

When I start the bootnote I pass the following arguments:

--nodekey <FILE> —addr :30301 --nat extip:<PUB-IP> --verbosity 9

The logs confirm that it is successfully created and listening:

INFO Mapped network port    proto=udp extport=30301 intport=30301 interface=ExtIP(<PUB-IP>)
DEBUG UDP listener up       self=enode://<PUB-ID>@<PUB-IP>:30301

When I start the node I pass the following arguments:

--cache=512 --verbosity=6 --datadir <DIR> --nat extip:<PUB-IP> --networkid=<VAL*> --rpc --rpcaddr=0.0.0.0 --rpcapi=eth,net,web3,personal,db --rpccorsdomain '*' --ipcapi "admin,db,eth,debug,miner,net,shh,txpool,personal,web3" --bootnodes enode://<PUB-ID>@<PUB-IP>:30301 --identity node1 

*(I am using a big networkId but it is inside the BigInteger range)

The logs on the node confirm that the bootnode is well identified

INFO  Starting P2P networking 
# >> Info about the current node:
DEBUG UDP listener up             self=enode://<PUB-ID>@<PUB-IP>:30303
INFO  Mapped network port         proto=udp extport=30303 intport=30303 interface=ExtIP(<PUB-IP>)
# >> Info about the bootnode:
TRACE Starting bonding ping/pong  id=<PUB-ID-SHORT> known=false failcount=0 age=XmXs

But connection fails and admin.peers shows no peers

TRACE >> PING/v4                 addr=<PUB-IP>:30301 err=nil
TRACE Starting bonding ping/pong id=<PUB-ID-SHORT> known=false failcount=0 age=XmXs
TRACE >> PING/v4                 addr=<PUB-IP>:30301  err=nil

When I try adding the bootnode manually, admin.addPeer("enode://..") returns true but the logs show:

DEBUG Adding static node    node=enode://<PUB-ID>@<PUB-IP>:30301
TRACE New dial task         task="staticdial <PUB-ID-SHORT> <PUB-IP>:30301"
TRACE Dial error            task="staticdial <PUB-ID-SHORT> <PUB-IP>:30301" err="dial tcp <PUB-IP>:30301: getsockopt: connection refused"
DEBUG Resolving node failed id=<PUB-ID-SHORT> newdelay=2m0s
TRACE Dial task done        task="staticdial <PUB-ID-SHORT> <PUB-IP>:30301"
TRACE New dial task         task="staticdial <PUB-ID-SHORT> <PUB-IP>:30301"
TRACE Dial error            task="staticdial <PUB-ID-SHORT> <PUB-IP>:30301" err="dial tcp <PUB-IP>:30301: getsockopt: connection refused"
TRACE Dial task done        task="staticdial <PUB-ID-SHORT> <PUB-IP>:30301"

I have tried as well to connect via static-nodes.json, where I indicate the bootnode's address in all nodes; and also without the --bootnodes flag, where somehow my nodes are not being recognized either, yet there are some random external nodes that are displayed as peers sporadically. I have tried specifying --maxpeers (following BokkyPooBah's advice) as well and seems to make no difference.

Please, help me.

  • One idea would be to leave both UDP and TCP on the default ports of 30303, and not change the listening (UDP) port to 30301. (It looks like one of your nodes has UDP 30303 and the other UDP 30301, which might not matter as you've specified the ports in the passed-in options. Personally I'd have everything as port 30303... ) – Richard Horrocks Mar 25 '17 at 19:20
  • I could try switching the bootnode port to 30303. In the network I am building the nodes use UDP 30303 but the bootnode uses 30301. The console display where port UDP 30303 is enabled corresponds to the regular node. – Betty Sanchez Mar 25 '17 at 19:58
  • Well, with port 30303 on the bootnode, it does seem to have more activity but it is still not getting the other node that explicitly connects to it. I guess the reason why 30301 would be better for bootnode and node is to have less traffic. But why don't they recognize each other? – Betty Sanchez Mar 25 '17 at 20:55
  • Have you checked if all servers are with the same datetime? Best, Marcello Kazuo – Kazuuu Mar 27 '17 at 3:01
  • yes I have. They have been syncronized – Betty Sanchez Mar 27 '17 at 10:38
2

Finally it worked. I still don't really know what did it but I will list here some of the changes that got it to work. When I figure out what exactly did it I will update my answer.

  • Use the --v5disc flag for node discovery.
  • The bootnode took ages to start with the --v5 flag so instead of using a bootnode I chose a random node as bootnode. I started my node with the --bootnodes referring to this regular node but didn't seem to work until I manually added it. Probably using static-nodes.json would have worked as well.
  • Use a small networkId. I think I was too optimistic on the size of this value. Once I ran geth and realized that it was using a different NetworkID from the one I entered. This was not a good sign but instead of choosing a smaller value I chose as the value that geth was suggesting. I only realized there was something wrong going on when I got this error Protocol eth/63 failed id=X conn=inbound err="NetworkId mismatch - 3853220132 (!= 1245324517197969700)". I am now using a 10-digit networkId and this is what seems to have done the trick.
  • [Possibly not necessary] Run a node in miner mode (personal.newAccount("pw"), miner.setEtherbase(eth.accounts[0]) & miner.start())

I am more inclined to think it was the networkId that was causing some sort of problem. At least switching to v5 made it more easy to detect.

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.