Replies: 2 comments
|
We updated to version 26.8.0 and it actualy managed to connect to some peers, but even after 24 hours, it never managed to pass the 10 connections threshold. I checked the peers and got this: $ curl http://localhost:5051/eth/v1/node/peers | jq | grep "last_seen_p2p_address"
"last_seen_p2p_address": "/ip4/52.99. 1.12/udp/9001/quic-v1",
"last_seen_p2p_address": "/ip4/161.159.23.234/udp/9001/quic-v1",
"last_seen_p2p_address": "/ip4/3.15.31.77/udp/9001/quic-v1",I didn't changed any firewall rules, so, port 9001 is still blocked. What I think it's happening is that, after v26.6.1, quic becomes the default and my node keeps advertising it, but other nodes can't access it. Can you confirm that using quic no longer is optional? |
0 replies
|
Note: v26.6.1 works just fine. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
We're running a geth-teku node and decided to update the tools versions.
We sucessfully updated geth to 1.17.5, but, when we tried updating teku to version 26.7.1, it just couldn't find another peers no matter how long we waited (total 2h).
We made no changes to the firewall configs nor the VM itself. We simply:
$ systemctl stop geth.service $ systemctl stop teku.service $ mv /var/lib/teku /var/lib/teku-26.3.0 $ mv /tmp/teku-26.7.1 /var/lib/teku $ systemctl start geth.service $ # wait a minute $ systemctl start teku.serviceWe're running the node in a VM within a corporate network, that is, using NAT, but, it was running perfectly at v26.3.0.
We noticed that the newer version uses QUIC and that UDP/9001 is blocked in our network, so we're wondering whether this could explain the lack of peers.
Is the quic now obligatory? Do the new version need the quic to run properly? Is there a workaround or a way to tell teku "don't use quic, work like the previous versions". Any debug tips you can suggest?
Any info will be of great help.
All reactions