Interesting. And congrats!
They’re the same binary for me:
09f71fe4510bcec7f64a65262dfc33b8 target/release/nockchain
09f71fe4510bcec7f64a65262dfc33b8 /home/mashex/.cargo/bin/nockchain
Interesting. And congrats!
They’re the same binary for me:
09f71fe4510bcec7f64a65262dfc33b8 target/release/nockchain
09f71fe4510bcec7f64a65262dfc33b8 /home/mashex/.cargo/bin/nockchain
nc: Failed outgoing connection to Some(PeerId("12D3KooWJPban4vqSHmLtUUSLMpWvhiCBAXJEu2qp32CoWANjC3Z")): Failed to negotiate transport protocol(s): [(/ip4/77.110.126.16/udp/37752/quic-v1/p2p/12D3KooWJPban4vqSHmLtUUSLMpWvhiCBAXJEu2qp32CoWANjC3Z: : Multiple dial errors occurred:
- Handshake with the remote timed out.: Multiple dial errors occurred:
- Handshake with the remote timed out.: Handshake with the remote timed out.)(/ip4/77.110.126.16/udp/51145/quic-v1/p2p/12D3KooWJPban4vqSHmLtUUSLMpWvhiCBAXJEu2qp32CoWANjC3Z: : Multiple dial errors occurred:
- Handshake with the remote timed out.: Multiple dial errors occurred:
- Handshake with the remote timed out.: Handshake with the remote timed out.)]
I get this continuously. I enabled UDP 51820 on my router and used --bind /ip4/0.0.0.0/udp/51820/quic-v1
Many of us get this error and we are not sure if this is catastrophic or not. The current gut-feeling consensus as of yet among the community appears to be that these errors do not signify much in the way of justified alarm.
Even though I have dared to speak, I know little, so beware my suggestion nonetheless.
I’m not worried about the outgoing connections failing. That doesn’t necessarily indicate an issue on our side. It’s the lack of incoming connections that I see as problematic.
It turns out that I had just stopped the ufw service in preparation of the launch, but that still leaves all rules set in nftables and iptables. So guess what: I was just binding new nodes to ports that I hadn’t opened yet. Leaving this here as a hint for other poor sods who’ve forgotten their basics.
For others reading along: I don’t know about your specific situation and I don’t have a recommended fix. You can check if you’re accepting connections on UDP 3006 by running this on the server/mining rig:
nc -ul 3006
And while that process is still running, from an external machine (e.g. laptop):
echo "nock nock" | nc -u <mining-rig-ip> 3006
If you see the message on the mining rig, you’re good (for this specific bind port). If you don’t, start troubleshooting firewalls, router port forwarding, datacenter firewalls / whatever applies in your situation.
After you’ve done your test, you can kill both nc
processes. Note that this probably won’t work if you already have a nockchain node listening on port 3006. You have to stop it first, or test using another UDP port you expect to be open.
That’s horrifying. I bet my ports are utterly swamped. I should look into this too