Skip to content
This repository has been archived by the owner on May 12, 2021. It is now read-only.

chat-with-rendezvous connection error #70

Open
cfvescovo opened this issue Jul 10, 2019 · 8 comments
Open

chat-with-rendezvous connection error #70

cfvescovo opened this issue Jul 10, 2019 · 8 comments

Comments

@cfvescovo
Copy link

Hi,
I fired up a simple-bootstrap-node on a server of mine.
Then a friend of mine in another city and I compiled chat-with-rendezvous as described and ran it (./chat -peer <string/from/bootstrap/node> -rendezvous testing).
Our consoles connect successfully to the bootstrap-node and print "Announcing ourselves" and then we get either nothing (literally nothing) or some warnings (they find each other but can't connect).

@cfvescovo
Copy link
Author

@lbordino (the friend)

@cfvescovo
Copy link
Author

cfvescovo commented Jul 12, 2019

@bigs Any suggestion?

@bigs
Copy link
Contributor

bigs commented Jul 12, 2019

@BaldEagleX02 Are either of you behind NAT? If so, you won't be able to get a connection between the two of you. I'd recommend passing in an explicit listen address, enabling port-forwarding in your router, and trying again. Keep in mind that DHT-based discovery can take some time to kick in. You'll know you've successfully found each other when you see a print message from this line.

@cfvescovo
Copy link
Author

I modified the log level to debug and then I saw that we discovered each other (after the program printed "Searching for peers..." I saw "Found another peer" or something similar).
We aren't behind NAT as we have static public IPs from our provider.
We tried with ports opened but it didn't work.
We haven't tried with the listen option yet.

@cfvescovo
Copy link
Author

cfvescovo commented Jul 14, 2019

@bigs However I hope that this library works with NAT too, as it handles hole-punching (#4)

@cfvescovo
Copy link
Author

cfvescovo commented Jul 17, 2019

It works with UPnP (A client behind NAT and B client with static IP and UPnP).
However, it doesn't work with both clients behind NAT and/or ports closed

@bigs
Copy link
Contributor

bigs commented Jul 17, 2019

Given the configuration of that specific example, you'll have to set the listen option to reflect your public IP and an accessible port. Another approach would be to enable port mapping via the NATPortMap option in the call to libp2p.New.

Edit: To clarify, since your libp2p node doesn't know that it's publicly dialable, it won't publish any addresses to the rendezvous point.

@cfvescovo
Copy link
Author

cfvescovo commented Jul 18, 2019

Yeah, in fact this example works very well with UPnP enabled (router and program) but if I am behind NAT (e.g. a mobile connection) I don't know any accessible port. I have to use hole punching to know at least one and I was wondering if it will be implemented in this library. Obviously it would require a server. Take a look at this example: https://github.com/wilfreddenton/udp-hole-punching
It seems very well structured and, as its name suggests, implements hole punching.

Thank you for your support!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants