marten-seemann
commented
1 year ago Does this also happen with the current version? v0.22 is pretty old.
Closed iulianpascalau closed 1 year ago
marten-seemann
commented
1 year ago Does this also happen with the current version? v0.22 is pretty old.
iulianpascalau
commented
1 year ago Will try. Thanks for the suggestion.
iulianpascalau
commented
1 year ago Tested with
go-libp2p v0.27.5
go-libp2p-kad-dht v0.23.0
go-libp2p-kbucket v0.5.0
go-libp2p-pubsub v0.9.3
go-multiaddr v0.9.0and the go compiler v1.20.3 and we've got the same results: while the host is not bound to the public interface, is not able to manually connect to another host.
marten-seemann
commented
1 year ago Your listen address is wrong, the port number is missing.
Other than that, the listening and the dialing code path don’t have a lot of overlap (other than reuseport, might be worth trying if disabling it helps). You could also inspect what’s going on on the wire using Wireshark.
I don’t really understand your point about holepunching. Hole punching requires you to have a connection to a relay server, at the very least. So if hole punching works, you were able to establish at least that one connection.
iulianpascalau
commented
1 year ago The code above might be a little confusing as the port number is always provided to the new host instance:
address := fmt.Sprintf(args.ListenAddress+"%d", port)
opts := []libp2p.Option{
libp2p.ListenAddrStrings(address),if args.ListenAddress is set to /ip4/0.0.0.0/tcp/ then the whole address var will hold something like /ip4/0.0.0.0/tcp/10001 if the provided port was 10001
The holepunching I was referring to was related to the NAT', UPnP feature. Since the host I'm trying to work on is behind a NAT, it will use the UPnP to negotiate a way to bind on the public interface(s) on a port given by the NAT. What strikes me is that using very old libp2p libs, this connection always works despite the fact that the node triggering the connection managed to bind on the public interface or not. Will try to narrow down this issue (maybe adding more prints or something).
Thanks once again for your time
iulianpascalau
commented
1 year ago yup, confirmed that tcp.DisableReuseport() fixed the issue.
Since this setting will need to be set only on our seednodes, I guess I can make it configurable.
Thanks for the help, this issue can be closed.
marten-seemann
commented
1 year ago Great, thanks for confirming. Do you have any theory why reuseport is causing problems here?
iulianpascalau
commented
1 year ago No, not a clue why disabling the reuse port fixes the issue.
MarcoPolo
commented
1 year ago I wonder if this is router specific. Does reuseport confuse the router? Does it prevent upnp? Something else?
Hello, migrating from
to
surfaced a potential bug that was found mostly by coincidence. First, we are instantiating the host in golang as follows:
where
args.ListenAddressis a const set to"/ip4/0.0.0.0/tcp/"The bug happens when we call the host's method
Connect(ctx context.Context, pi peer.AddrInfo) errorto try to manually connect to a peer. If the host managed to do the "NAT hole punching", the connection attempt succeeds, otherwise, it will fail with the following error:We've observed the coincidence between the peer-bounded interfaces and the appearance of the above-mentioned error. So, whenever we see bounded interfaces like:
the error appears, but when we see this:
the connection & peer discovery through kad-dht works.
Enabling the log subsystem on libp2p packages for the node that should have accepted the connection, we've observed the following log lines after the node initiating the connection bound on the public interfaces
Thanks and sorry for the long wall of text
Version Information