Uncaught Error: dialed to the wrong peer, Ids do not match #274
Comments
jacobheun
added
help wanted
|
The error indicates there was an issue identifying the peer so the dial will stop. We should catch this error so it's not thrown and ensure there's not an issue in the chain preventing secio from getting the correct peerID to verify against. |
|
@jacobheun The majority of the failing tests report |
|
@vasco-santos if we could get a reproducible test of this in libp2p that would be super helpful. |
|
I will have a look into it! |
|
@klueq everything seems good in my side now. Tests are ok in the Can you double check if this is still an issue for you? |
|
@vasco-santos I think I've got the issue sorted out, I just need to write some tests to confirm. I'll submit some PRs tomorrow along with some improvements for catching these uncaught errors before we release with 0.24. |
|
@jacobheun I’m seeing this when you deploy to multiple servers and register the 0.0.0.0 address with the same port. What I see in the logs is the node trying to dial another peer whose multiaddrs include 127.0.0.1 port 3000 (for example). It then starts a conversation with itself and realizes it sends back a different peer id (it’s own) than the requested node. A solution for this one is tricky. There’s a ticket that talks about being able to configure published addresses vs listen addresses. That could work. Additionally, it might be prudent for the switch to filter out multiaddrs on the same IP and port as the current node’s multiaddrs |
This sounds like similar to the issue I opened here: libp2p/js-libp2p-floodsub#58 I've worked round the problem by getting each node to listen on unique ports but it'd be great to have a proper solution. |
|
@blakebyrnes you are right on the money. I think updating Switch to return a dial self error for internal addresses with the same port is a good quick fix. I am playing around with some of this already, so I will look at getting a PR for this part. Transports can advertise internal and external addresses, which makes sense when there are multiple nodes on a box. It might be useful to add an option to return only external addresses. For example, libp2p-tcp, when listening on 0.0.0.0 will return all internal and external addresses. If nodes only want to advertise external addresses tcp could additionally filter by |
|
Cool! This is the ticket with the external vs listen addresses: #202 Personally, I would love to be able to list the addresses I want to publish to the network vs just listen on. My use cases are:
There could be others. But controlling the addresses would be really nice. I poked around, but couldn't quite figure out where the current node's multiaddrs are shared with other nodes. |
|
listener.getAddrs is how the addresses are added to the peer info for the switch. Once listening is done that is called, https://github.com/libp2p/js-libp2p-switch/blob/v0.41.1/src/transport.js#L169. We could look at passing an option to switch to advertise external only, then modify the |
|
Totally makes sense for the ones that are on the ni. I guess I'm really looking for a solution to a somewhat separate problem. This might not be the right ticket to talk about it. I have separate addresses that I want to "listen", and that other nodes can reach my node on. The examples above both would have ni addresses to listen on, but in the case of docker, your addresses are the docker ip and localhost. Docker opens a port on the host machine to let traffic through to the docker network. In that case, I need to either merge the docker network with the host network, or I need some ability to "listen" on the docker ips (0.0.0.0 here), while I tell the network to reach me at the host machine ip and port. Hopefully I'm making sense. The only reason I bring it up here is if other people are having similar issues with binding/publishing, it might be worth having a core fix - which would likely go into a peer-info spec and/or a separate "listen" peer-info and "share with network" peer-info. |
|
Yes that makes sense. It sounds like #202 would get you what you need correct? I think we could just do that to help alleviate this particular problem as well, in addition to the switch dial update. |
|
Yep, #202 is exactly what I want/need. Awesome!! I think 202 will go a long way to helping libp2p be deployable in a cloud setting. Or simply with fixed IPs - ie, creating your own bootstrap nodes. |
|
Great, yeah I agree that should help improve cloud usability quite a bit. I submitted a PR for strict filtering of dialables on switch to help with this issue, libp2p/js-libp2p-switch#284. Once we add listen/announce I think we can improve the logic there. |
|
This has been fixed for some time. |
…#274) Bumps [@libp2p/interface-mocks](https://github.com/libp2p/js-libp2p-interfaces) from 11.0.3 to 12.0.1. - [Release notes](https://github.com/libp2p/js-libp2p-interfaces/releases) - [Commits](https://github.com/libp2p/js-libp2p-interfaces/compare/@libp2p/interface-mocks-v11.0.3...@libp2p/interface-mocks-v12.0.1) --- updated-dependencies: - dependency-name: "@libp2p/interface-mocks" dependency-type: direct:development update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
## [7.0.2](libp2p/js-libp2p-tcp@v7.0.1...v7.0.2) (2023-06-15) ### Trivial Changes * Update .github/workflows/semantic-pull-request.yml [skip ci] ([6dcfdb3](libp2p/js-libp2p-tcp@6dcfdb3)) * Update .github/workflows/stale.yml [skip ci] ([862af6c](libp2p/js-libp2p-tcp@862af6c)) ### Dependencies * **dev:** bump @libp2p/interface-mocks from 11.0.3 to 12.0.1 ([libp2p#274](libp2p/js-libp2p-tcp#274)) ([147610f](libp2p/js-libp2p-tcp@147610f))
I'm getting the following error when the latest js-libp2p is built with the latest js-ipfs + the DHT PR:
This error doesn't seem to break anything.
Repro, just in case: https://klueq.github.io/?https://ipfs.io/ipfs/QmdFgDWRTB4L3Ks87615kSc6yQStXxRTfp1hmYUfDGTeBe/index.js
The console log dump:
The text was updated successfully, but these errors were encountered: