🥊 Hole punching with DCUtR not working

[mkermani144]

Greetings everyone! 👋

I've been diving into the world of enabling hole punching with js-libp2p lately, dedicating a substantial amount of time to it, but alas, no breakthroughs. After some contemplation, I decided to initiate a discussion over on the libp2p forum, and someone suggested seeking assistance here.

In a nutshell, I experimented with the rust-libp2p hole punching example across three different servers – one with a public IP (for relay) and the others within a private network, behind NAT. Following a few tweaks, I successfully executed a hole punching scenario over TCP, both in non-Dockerized and Dockerized environments. While it didn't achieve a 100% success rate (likely due to using TCP), it hovered around 60%.

Returning to my own JS version of the scenario using js-libp2p, I encountered a roadblock. Despite numerous modifications, successful hole punching remained elusive. I've documented my code and challenges in this GitHub repository.

Any thoughts or ideas?

@sukunrt, I was directed here from the libp2p forum as someone who might have insights. Would greatly appreciate any assistance or guidance!

[sukunrt]

Can you check if your Private node knows its public IP?
If you know it upfront you can try providing it via an env variable and see if things work.

[sukunrt]

In most cases you'd connect to many other nodes, so the address discovery should work. In this case you're just connecting to 1 node so the confidence in the address discovered over identify is low.

[mkermani144]

I think you mean through autonat service, don't you? Because I see no address confirmation mechanism for observed addresses in identify protocol (at least in js-libp2p).

[mkermani144]

And one more concern is that, js-libp2p seems not to re-use the listen port for creating new connections, which cause others to identify us with a random port different from our listen port.

[achingbrain]

I see no address confirmation mechanism for observed addresses in identify protocol

It's here: https://github.com/libp2p/js-libp2p/blob/main/packages/protocol-identify/src/identify.ts#L313

We store the observed address with no confidence: https://github.com/libp2p/js-libp2p/blob/main/packages/libp2p/src/address-manager/index.ts#L168-L170

Then later on AutoNat gets the observed addresses: https://github.com/libp2p/js-libp2p/blob/main/packages/protocol-autonat/src/autonat.ts#L343-L348

...and confirms the observed address(es) if enough peers can dial them: https://github.com/libp2p/js-libp2p/blob/main/packages/protocol-autonat/src/autonat.ts#L502

[mkermani144]

Yes, I looked at the exact codes you sent beforehand. I meant identify doesn't confirm an observed address on its own, it's the autonat that does so.

[achingbrain]

Thanks for digging into this and trying to make it more reliable, the research is very valuable.

We've not put a lot of effort in to hole punching in js-libp2p because, timing issues in JS aside, it really needs QUIC for to be reliable and support is still missing in Node.js.

The current DCUtR protocol implementation is mainly there to enable the unilateral connection attempt part of the spec whereby nodeA dials nodeB via circuit relay, but nodeA has a publicly routable address that nodeB can dial directly so it does that.

[mkermani144]

I fully understand. Great job by the way.

I tested the unilateral hole punching weeks ago and it works great, and just need some kind of conclusion on if we can rely on non-unilateral hole punching of js-libp2p or not. It's a crucial part of our network, as it helps a lot in reducing the load of relays.