Relay does not work on v0.41.1

[master255]

@sukunrt @MarcoPolo

Relay doesn't work on 0.41.1.
I am trying to connect from gray ip -> white ip (Relay) -> gray ip.
At the same time white ip (Relay) -> gray ip connection exists.
The connection from gray ip -> white ip (Relay) is also exist.
But connection from gray ip -> white ip (Relay) -> gray ip does not pass. Although reservation on white ip (Relay) exists.
I looked at debug logs. Found that it immediately returns an error with the id of the node of the white ip address:
“skipping node that we recently failed to obtain a reservation with....”.
But before that there is no reservation error. And reservation is definitely exist. And there are several nodes with reservation.
Reservation by client.Reserve command

Is there a bug somewhere or am I doing something wrong?

[master255]

I went back to v0.39.1 and the connection was immediately established.
I am waiting for your fixes. And will test before updating.

The bug is on the client side that wants to connect. Since the other applications were with 0.41.1
And only the first client is 0.39.1.

Maybe it's because of changes in the holepunch algorithm. Since access to the second gray ip was through holepunch.
Maybe there are some problems with errorcodes.
I removed the errorcodes and holepunch code from 0.41.1 and the communication worked.

[MarcoPolo]

Can you git bisect the commits to narrow down the issue? If not, could you give us a way to reproduce this issue? Ideally in a controlled environment like docker compose.

[master255]

@MarcoPolo A way to reproduce:
try to connect from gray ip -> white ip (Relay) ->(holepunch connection) gray ip.

And I don't use a docker. Because I'm a programmer.

This is really very difficult to prove and demonstrate. Because this is the most difficult case.
But it looks like the holepunch connection is trying to connect directly and failing at that. And so there is no connection.
At the same time circuit relay logic works. But the connection is not established.

[filinvadim]

@master255 please add some debug logs

	_ = golog.SetLogLevel("autonatv2", "debug")
	_ = golog.SetLogLevel("autonat", "debug")
	_ = golog.SetLogLevel("p2p-holepunch", "debug")
	_ = golog.SetLogLevel("relay", "debug")
	_ = golog.SetLogLevel("nat", "debug")
	_ = golog.SetLogLevel("p2p-circuit", "debug")
	_ = golog.SetLogLevel("basichost", "debug")
	_ = golog.SetLogLevel("swarm2", "debug")
	_ = golog.SetLogLevel("autorelay", "debug")
	_ = golog.SetLogLevel("net/identify", "debug")
	_ = golog.SetLogLevel("tcp-tpt", "debug")

[master255]

My Libp2p creation:

h, err := libp2p.New(
		libp2p.ListenAddrStrings(fmt.Sprintf("/ip4/0.0.0.0/tcp/%d", port), fmt.Sprintf("/ip6/::/tcp/%d", port), fmt.Sprintf("/ip4/0.0.0.0/udp/%d/quic-v1", port), fmt.Sprintf("/ip6/::/udp/%d/quic-v1", port)),
		libp2p.Identity(privKey),
		libp2p.NATPortMap(),
		libp2p.EnableRelay(),
		libp2p.EnableHolePunching(),
		libp2p.EnableRelayService(relay.WithInfiniteLimits()),
		libp2p.EnableNATService(),
		libp2p.DisableMetrics(),
		libp2p.EnableAutoRelayWithPeerSource(func(ctx context.Context, numPeers int) <-chan peer.AddrInfo {
			peerChan, _ := routingDiscovery.FindPeers(ctx, randezvous, discovery.Limit(numPeers))
			...
		}),
		libp2p.UserAgent(randezvous))

[master255]

I'll take those logs down on the next update. So far I don't have this problem because I removed some functionality from the library.