1

I have this error when i try tu run my second node on Geth...I used authrpc.port but still the problem persists:

I ran my node1 with these commands:

geth --datadir node1 --networkid 2244 --allow-insecure-unlock --unlock 0x00fB51927e31f071293195CEfac6fA41ce185ee7  --http --port 30304 --http.corsdomain '*' --authrpc.port 8546 --http.vhosts '*'  --http.api admin,eth,miner,net,txpool,personal,web3 --syncmode full --nodiscover --ipcdisable --nat extip:127.0.0.1 --mine --bootnodes "enode://714e0e5f60b486b8a7d6d10518265399472e826fd190c7fe7e5da86d733042a0c870eb5e52670a5aeb84f2a47fffdfa14a3d8bd8edcd0949c7c2c4135ce3a256@127.0.0.1:0?discport=30303" console                     

And this node is set up perfectly. When, however, I try to run the second node with:

geth --datadir node2 --networkid 2244 --allow-insecure-unlock --unlock 0x0167539345b577d4a6551DD27DcFF15DEFb41a81  --http --port 30305 --http.corsdomain '*' --authrpc.port 8547 --http.vhosts '*'  --http.api admin,eth,miner,net,txpool,personal,web3 --syncmode full --ipcdisable --bootnodes "enode://714e0e5f60b486b8a7d6d10518265399472e826fd190c7fe7e5da86d733042a0c870eb5e52670a5aeb84f2a47fffdfa14a3d8bd8edcd0949c7c2c4135ce3a256@127.0.0.1:0?discport=30303" --mine console

This returns me:

INFO [03-31|12:23:03.476] Started P2P networking self=enode://1716de0f30b7094bf4858d89ffc2e02583f20a009a67a219729c0fd477ca36d0728c125a9e08f0c2ff77e076b6ce50f2840cba7f8eaf94554d11ab2615cbf750@127.0.0.1:30305 INFO [03-31|12:23:03.476] Loaded JWT secret file path=C:\Users\alexc\OneDrive\Documenti\GitHub\private-blockchain-nopuppeth-2\node2\geth\jwtsecret crc32=0x55db3bf5 Fatal: Error starting protocol stack: listen tcp 127.0.0.1:8545: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.

Why is it trying to connect to port 8545?? I also ran a bootnode by this command, and the results is:

bootnode -nodekey boot.key -addr 30303 :30303enode://714e0e5f60b486b8a7d6d10518265399472e826fd190c7fe7e5da86d733042a0c870eb5e52670a5aeb84f2a47fffdfa14a3d8bd8edcd0949c7c2c4135ce3a256@127.0.0.1:0?discport=30303
Note: you're using cmd/bootnode, a developer tool. We recommend using a regular node as bootstrap node for production deployments.
INFO [03-31|12:09:42.495] New local node record seq=1,680,257,382,484 id=370ac589e36cff6f ip= udp=0 tcp=0

The first node successfully connected to the bootnode, while the second node doesn't boot either. I think I found why both nodes don't connect together:

If we execute in the cmd the command "netstat -ano | findstr :8546 " After running the node1:

The command returns this process with PID 31164 in my case: TCP 127.0.0.1:8546 0.0.0.0:0 LISTENING 31164

Similarly we can see that if I run the same command on the netstat port -ano | findstr :8545

The command returns the same process:

TCP 127.0.0.1:8546 0.0.0.0:0 LISTENING 31164

and that's why when I try to run the second node, it gives me the error I showed before, because the node tries to connect both to the indicated port (8547), but for some operating logic of the --authrpc command, yes it also connects to port 8545.

Is there a way to disable this "dual connect"? Apparently the same behavior applies to the command --http.port , in fact:

If I try to use --http.port 8546, the node will connect to both port 8546 and port 8551(in this case)

*** ⬇️EDIT⬇️ ***

I think I found why both nodes don't connect together:

If we execute in the cmd the command netstat -ano | findstr :8546(after running the node1),

The command returns this process (with PID 31164 in my case):

TCP 127.0.0.1:8546 0.0.0.0:0 LISTENING 31164

Similarly we can see that if I run the same command on the netstat port -ano | findstr :8545

The command returns the same process:

TCP 127.0.0.1:8545 0.0.0.0:0 LISTENING 31164

and that's why when I try to run the second node, it gives me the error I showed before, because the node tries to connect both to the indicated port (8547), but for some operating logic of the --authrpc command, yes it also connects to port 8545.

Is there a way to disable this "dual connect"? Apparently the same behavior applies to the command --http.port , in fact:

If I try to use --http.port 8546, the node will connect to both port 8546 and port 8551(in this case)

Can someone help me please...

6
  • The parameter you need to change is --http.port 8545, also check if you have --ws enabled for --ws.port 8546.
    – Ismael
    Commented Apr 4, 2023 at 2:55
  • It does not works for me... Anyway, take a look at my EDIT I ​​added.
    – AlexCav
    Commented Apr 5, 2023 at 16:30
  • You can try leaving several ports in between, for example 12545 the first node and 12550 the next one, to say some numbers. The default ports used by geth are 8545 for http, 8546 for websocket, 8551 for authrpc. See the command line options description here geth.ethereum.org/docs/fundamentals/command-line-options.
    – Ismael
    Commented Apr 5, 2023 at 23:58
  • I don't think it will work this way because, as I explained, it is as if the connection took place on two ports, so even if I wanted to, I could use a wider range as you say, but the problem will still reoccur because it is basically the default port (even if specified) remains active. Whether you use --http --ws or --authrpc.
    – AlexCav
    Commented Apr 6, 2023 at 8:57
  • Did you try? I haven't used windows in a long time but it was possible to run multiple geth instances.
    – Ismael
    Commented Apr 6, 2023 at 9:04

1 Answer 1

0

I was able to run multiple geth instances by specifying different values for port, http.port, ws.port and authrpc.port

geth.exe --datadir data1 --networkid 12345 --http --http.port 8545 --port 30304 --http.api admin,eth,miner,net,txpool,personal,web3 --nodiscover --ipcdisable --ws.port 8546 --authrpc.port 8551 console

geth.exe --datadir data2 --networkid 12345 --http --http.port 8575 --port 30306 --http.api admin,eth,miner,net,txpool,personal,web3 --nodiscover --ipcdisable --ws.port 8576 --authrpc.port 8581 console

1
  • I think putting --ws is unnecessary. The main problem is with the --authrpc.port. I believe the problem is solved by specifying both auth.rpc and another between --http and --ws
    – AlexCav
    Commented Apr 12, 2023 at 8:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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