Use NAT traversal option in host - is it possible?

[jvsteiner]

Iv'e been working with libp2p for a while, and would like to try go-libp2p-nat to address NAT issues we are facing. am currently constructing my hosts using libp2p.New which is configured using libp2p.Options and they do not seem to allow for this option to be enabled.

the basichost package, on the other hand, has two constructors New (depreciated) and NewHost. NewHost uses bhost.HostOpts for configuration, which does allow for NAT, (but not for optional use of secure IO.)

I've commented on issue #263 (which is closed) but am opening this as a separate issue, since I think it could be different. The problem I'm facing is that the muxer option in bhost.HostOpts is a different type (*msmux.MultistreamMuxer) than what is returned by libp2p.DefaultMuxer(). When I pass a *msmux.MultistreamMuxer to NewHost, it compiles, but connections do not work.

Any ideas?

[jvsteiner]

Update

I think that everything reduces to bhost.NewHost in the end, and the rest are just wrapping that function for legacy reasons. I've been able to use NewHost to construct the host the way I think I need to, and but am running into dial attempt failed: protocol not supported even though the addresses I am dialing have not changed at all. This error seems to originate from multiformats/go-multistream - this seems kind of specific, maybe someone has seen this before.

[Stebalien]

So, take a look at how the libp2p constructor constructs the host.

You won't need to specify the MultistreamMuxer. That's actually totally unrelated to stream muxing (despite what it's called). It's the protocol dispatcher (where we end up registering protocol handlers).

Unfortunately, I'm not familiar with the specific error you're seeing.

I'm currently working on a refactor that will allow configuring this but... it won't be ready for a while. For the moment, we'd welcome a patch that adds a NATPortMap option to the libp2p config.

[jvsteiner]

After some digging, my remaining problem turns out to be unrelated the OP and will be fixed when this PR gets merged. In the libp2p constructor, it calls peer.IDFromPublicKey whereas in the bhost constructors, you have to make the ID and add it to the peerstore yourself. I've been using the broken IDFromEd25519PublicKey which causes the protocol issue in go-multistream when used this way. When I swapped the functions out, it worked.

Meanwhile, I'm happy to help with a NAT Option: added #293

[Stebalien]

Given that this issue has been fixed, I'm closing.

[jvsteiner]

agreed - sorry I left it hanging

[Stebalien]

Np. Keep up the good work.