fix: do not write tcp port 0 and remove 100 chars length limit for multiaddresses

[richard-ramos]

The reason why i removed the condition of checking for the length of the multiaddress is that we can just let the error handling determine whether writing to the enr was succesful or not.

[status-im-auto]

Jenkins Builds

Click to see older builds (5)

❔	Commit	#️⃣	Finished (UTC)	Duration	Platform	Result
✔️	4d4820e	#1	2024-06-17 19:38:22	~2 min	nix-flake	📄log
✔️	d98a0e4	#2	2024-06-18 13:39:26	~1 min	nix-flake	📄log
✔️	72eee6c	#3	2024-06-18 14:10:37	~2 min	nix-flake	📄log
✔️	edeae3d	#4	2024-06-18 14:43:07	~2 min	nix-flake	📄log
✔️	22a0c73	#5	2024-06-18 18:39:41	~1 min	nix-flake	📄log

❔	Commit	#️⃣	Finished (UTC)	Duration	Platform	Result
✔️	e04b052	#6	2024-06-19 00:24:15	~1 min	nix-flake	📄log
✔️	192991c	#7	2024-06-19 18:14:33	~2 min	nix-flake	📄log

[chaitanyaprem]

Looks like tests and compilation is failing, that needs fixing

[richard-ramos]

@chaitanyaprem I fixed a race codnition in this PR that is probably affecting your other open PR. You can cherry pick that commit if needed to get past CI.

[chaitanyaprem]

I was also wondering why i am getting a lot of NO_RESERVATION errors when i try to connect via circuit-relay. Could it be possible that nodes announcing circuit-relay addresses via a peer are not reserving themselves with the peer?
Was looking at libp2p circuit-relay example and the node that wants to expose a circuit-relay address is supposed to reserve itself with circuit-relay peer. https://github.com/libp2p/go-libp2p/blob/6cebdd88366696a19b61dc209768c932a8f1ec4b/examples/relay/main.go#L110-L114

ERROR[06-19|12:38:59.878|github.com/waku-org/go-waku/waku/v2/protocol/filter/client.go:405] Failed to subscribe pubSubTopic=/waku/2/rs/16/32 contentTopics=[/waku/1/0xfce8db73/rfc26] error="failed to dial: failed to dial 16Uiu2HAm2ZckNiQUAKbHAmokqxafm8FftwXch6aNQwrMiEJX1B9A: all dials failed\n * [/ip4/95.216.204.65/tcp/60000/p2p/16Uiu2HAmLktdCHRc63Br2YBX8LihJBiBZPkqymt5HRheeoUXGHwP/p2p-circuit] error opening relay circuit: NO_RESERVATION (204)\n * [/ip4/88.156.142.133/tcp/61446] dial tcp4 0.0.0.0:51978->88.156.142.133:61446: i/o timeout"

I don't see the use of reserve function in go-waku anywhere. Is my understanding correct @richard-ramos or am i missing something?

[richard-ramos]

@chaitanyaprem: I don't see the use of reserve function in go-waku anywhere.

It's because the reservation process is handled by Autorelay in https://github.com/libp2p/go-libp2p/blob/6cebdd88366696a19b61dc209768c932a8f1ec4b/p2p/host/autorelay/relay_finder.go#L610 which in go-waku is setup here: https://github.com/waku-org/go-waku/blob/master/waku/v2/node/wakunode2.go#L217-L242

In the example from go-libp2p Autorelay is not used, I guess to ilustrate what's the process to follow to use circuit relay manually.

[chaitanyaprem]

@chaitanyaprem: I don't see the use of reserve function in go-waku anywhere.

It's because the reservation process is handled by Autorelay in https://github.com/libp2p/go-libp2p/blob/6cebdd88366696a19b61dc209768c932a8f1ec4b/p2p/host/autorelay/relay_finder.go#L610 which in go-waku is setup here: https://github.com/waku-org/go-waku/blob/master/waku/v2/node/wakunode2.go#L217-L242

In the example from go-libp2p Autorelay is not used, I guess to ilustrate what's the process to follow to use circuit relay manually.

Got it, makes sense.

But in that case i am wondering why connectivity fails with NO_RESERVATION error towards peers that advertise circuit-relay. Will require more testing to understand. Hopefully the peer address reported in ENR and circuit-relay reservation are always in sync.
What if circuit-relay node doesn't accept reservation, will we still consider that address and add it to ENR?

[richard-ramos]

But in that case i am wondering why connectivity fails with NO_RESERVATION error towards peers that advertise circuit-relay. Will require more testing to understand. Hopefully the peer address reported in ENR and circuit-relay reservation are always in sync.

We have to test, but I'm thinking the problem is that the escenario we are seeing is the following:

1. Alice reserves with a circuit relay server
2. Alice publishes her ENR
3. Alice goes offline or loses connection to the circuit relay server
4. Circuit relay server eliminates the reserve since Alice is no longer online
5. Bob asks for peers using discv5 / peer exchange and receives Alice's (routing tables can take some time to gc a node)
6. Bob tries to connect to Alice's circuit relay multiaddress
7. Circuit relay server receives the connection attempt and complains that there's no reserve because it no longer has a connection to Alice.

[chaitanyaprem]

But in that case i am wondering why connectivity fails with NO_RESERVATION error towards peers that advertise circuit-relay. Will require more testing to understand. Hopefully the peer address reported in ENR and circuit-relay reservation are always in sync.

We have to test, but I'm thinking the problem is that the escenario we are seeing is the following:

1. Alice reserves with a circuit relay server

2. Alice publishes her ENR

3. Alice goes offline or loses connection to the circuit relay server

4. Circuit relay server eliminates the reserve since Alice is no longer online

5. Bob asks for peers using discv5 / peer exchange and receives Alice's (routing tables can take some time to gc a node)

6. Bob tries to connect to Alice's circuit relay multiaddress

7. Circuit relay server receives the connection attempt and complains that there's no reserve because it no longer has a connection to Alice.

True that is also possible.

[richard-ramos]

@chaitanyaprem I fixed the issues and got green lights in the CI.
I only need your seal of approval :)

[chaitanyaprem]

Tested this locally and ENR generated doesn't fail to decode and doesn't include address with port 0.

Only minor thing we can probably improve is to not fill private IP address in ENR if present. It is not a major issue though as long as we include other addresses as part of Waku Multiaddrs field.