-
Notifications
You must be signed in to change notification settings - Fork 451
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
kad-dht: NO_VALID_ADDRESSES #2040
Comments
NOTE: I understand that this is likely a problem with kubo / boxo / go-libp2p, but js-libp2p does not work consistently because of this. Related to ipfs/helia#255 |
Most addresses are private addresses -> this isn't surprising in that most of a nodes addresses are probably private (e.g. an ipv4 and/or v6 public address vs v4 and v6 localhost + local network addresses). Those addresses might not be worth spending dials on, especially in resource limited environments like browsers. If you could digest that log info further into the peers(/percentage of peers) where they have some public addresses (e.g. public QUIC or TCP) but only private webtransport that could be interesting (particularly in the case of QUIC) if they're not running old nodes that had some advertising bugs with webtransport. |
related to libp2p/go-libp2p#2568 |
Can you try 0.46.9 ? I have a kind of related issue but seems to be gone with 0.46.9 |
@marcus-pousette I believe the issue I was running into is due to the IPFS network as a whole and not related to any specific js-libp2p version. I was seeing similar in 0.46.9. (the problem is covered more thoroughly in libp2p/go-libp2p#2568) |
As explained above, this is not a bug in js-libp2p, in that there is no PR that can be opened to this repo that will fix the issue. Instead kubo/go-libp2p needs to correctly advertise the webtransport addresses it is listening on, and the network needs to upgrade to these versions. |
0.46.10
Darwin Russells-MacBook-Pro-314.local 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul 5 22:22:05 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6000 arm64
kad-dht
Severity:
High - The main functionality of the application does not work, API breakage, repo format breakage, etc.
Description:
I have been attempting to debug problems mentioned at https://discuss.ipfs.tech/t/helia-example-doesnt-work/16747/6 and noticed that most dht progress events end up erroring out with
kad-dht:query:query-error
with error{"code":"ERR_NO_VALID_ADDRESSES","props":{},"name":"CodeError"}
So I started to look for peers that had valid addresses, and it appears that the majority of the webtransport addresses returned when we do get a
kad-dht:query:peer-response
, are private addresses.A few examples:
Steps to reproduce the error:
The text was updated successfully, but these errors were encountered: