Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] No connected peer #3359

Open
S3VENK opened this issue Jul 10, 2024 · 6 comments
Open

[Bug] No connected peer #3359

S3VENK opened this issue Jul 10, 2024 · 6 comments
Labels
bug Incorrect or unexpected behavior

Comments

@S3VENK
Copy link

S3VENK commented Jul 10, 2024

Screenshot 2567-07-11 at 00 06 16

🐛 Bug Report

Based on the provided debug logs, it appears that the issue is related to connectivity problems with a specific IP address ('MY_IP_ADDRESS'). Here’s a breakdown of the log entries:

DEBUG snarkos_node_router::heartbeat: No connected peers
    Indicates that the node/router is reporting no connected peers, suggesting a lack of network connectivity or peers available for communication.

DEBUG snarkos_node::prover: Skipping an iteration of the puzzle (no connected peers)
    Further confirms that due to no connected peers, the node is unable to proceed with certain operations or tasks.

DEBUG snarkos_node_router::handshake: Connecting to 34.17.53.129:4130...
    Shows an attempt to establish a connection with the IP address 'MY_IP_ADDRESS' on port 4130.

WARN snarkos_node_router: Unable to connect to '34.17.53.129:4130' - '3MY_IP_ADDRESS' disconnected before sending "Message::ChallengeResponse"
    Indicates a connection failure where the node attempted to connect to 'MY_IP_ADDRESS:4130' but received a disconnection before completing the expected handshake or communication step ("Message::ChallengeResponse").

Issues Identified:

No Connected Peers: The node/router is reporting no peers connected, which could indicate network issues, misconfiguration, or peers being offline/unreachable.
Connection Failure: Specifically with 'MY_IP_ADDRESS:4130', there was an attempt to connect but it failed before completing the necessary handshake process.

Potential Impact:

Operational Disruption: Tasks dependent on peer-to-peer communication or specific connections to 'MY_IP_ADDRESS:4130'  fail and delayed.
Service Availability: Services relying on these connections may experience interruptions or degraded performance until connectivity is restored.

My Environment

  • snarkos v2.2.7
  • rust version 1.76.0
  • Ubuntu 22.04.4 LTS, CPU 16 cores, 64 GB RAM
@S3VENK S3VENK added the bug Incorrect or unexpected behavior label Jul 10, 2024
@S3VENK
Copy link
Author

S3VENK commented Jul 10, 2024

Screenshot 2567-07-09 at 23 12 32 screenshot from other day

@S3VENK
Copy link
Author

S3VENK commented Jul 11, 2024

According to the recommendations in the FAQs on Aleo's GitHub, I have already checked and ensured that ports 4130/tcp and 3030/tcp are allowed. However, the error persists.
Uploading Screenshot 2567-07-11 at 22.27.14.png…

@Demontf
Copy link

Demontf commented Jul 17, 2024

what is the network id of nowaday's testnet

@raychu86
Copy link
Contributor

Same issue as #3113.

Likely an issue with the networks not being up and running or the bootstrap nodes being down. Please try again on the latest snarkOS version and feel free to reopen an issue if you experience the same problems.

@Thormeard
Copy link

Thormeard commented Dec 9, 2024

The problem is still there. Running the latest available right now snarkOS version (v3.1.0). Node is in sync but then unable to connect to any peers after a restart of the process (graceful shutdown and start). After 20-60+mins node is starting to sync again and is able to catch up with the network. Was also the case for testnet-v1.1.0 and versions before that as well (although I don't remember it was being soooo slow to find any peers couple of months ago).

Steps to reproduce:

  1. Get a client node that is in sync with the mainnet network
  2. Restart the client
  3. Client most of the times is unable to connect to any peers for a really long amount of time

Checked only for client nodes. Happens consistently for 2 different clients on 2 different linux machines. Client started with --nocdn flag.
Let me know if you are unable to reproduce the issue.

Screenshot 2024-12-09 at 10 16 39

@Thormeard
Copy link

Small update, if you list peers from an already running node and then use those peers with a --peers flag, then node is starting to sync right away.

The problem is only with connecting to the 'default' hardcoded bootstrap peers. (34.105.20.52:4130, 35.231.118.193:4130, 35.204.253.77:4130, 34.87.188.140:4130).

Reproducible even on a fresh machine with no cache/no blocks. No vpn is used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Incorrect or unexpected behavior
Projects
None yet
Development

No branches or pull requests

4 participants