stungun issues: detected NAT type symmetric

[ci-work]

running miner as validator, and etls on dedicated servers, using master libp2p, should be fixed single dedicated ip address, but getting stungun detected NAT type symmetric and also a random reports of ip address as 172. ipv4 network addresses, also incorrect.

several instances of this, but example:

2021-12-15 21:38:39.803 [info] <0.1280.0>@libp2p_transport_tcp:handle_info:500 retrying stungun with peer "/p2p/112iynLkeTKvPQnYCYhnrZp4sURMS77EHfCfsVUScG9PBmpf92U9"
2021-12-15 21:38:39.811 [info] <0.1280.0>@libp2p_transport_tcp:handle_info:527 stungun detected NAT type symmetric
2021-12-15 21:38:39.811 [info] <0.1356.0>@libp2p_relay_server:handle_cast:152 requested to init relay but we already have one @ <0.8525.1>

[ci-work]

additional info:

2021-12-16 01:26:31.064 [info] <0.1479.0>@libp2p_transport_tcp:handle_info:500 retrying stungun with peer "/p2p/116Sa97proLW3oTBwUKtR1k7yxABCCwE3dnxvDwqhkh7snbEu3z"
2021-12-16 01:26:31.242 [info] <0.1479.0>@libp2p_transport_tcp:handle_info:527 stungun detected NAT type symmetric
2021-12-16 01:26:31.247 [info] <0.1532.0>@libp2p_relay_server:init_relay:242 initiating relay with peer "/p2p/11x5kNN7RKFEfaqe7TRxXc5bGV2Mz8U4LLwXaHK7hNYA4UZTsXe"

peer book entry:

# ./bin/miner peer book /p2p/116Sa97proLW3oTBwUKtR1k7yxABCCwE3dnxvDwqhkh7snbEu3z
+--------------------------------------------------------+-------------------+------------+-----------+---------+------------+
|                        address                         |       name        |listen_addrs|connections|   nat   |last_updated|
+--------------------------------------------------------+-------------------+------------+-----------+---------+------------+
|/p2p/116Sa97proLW3oTBwUKtR1k7yxABCCwE3dnxvDwqhkh7snbEu3z|unique-tawny-oyster|     2      |    10     |symmetric|  872.894s  |
+--------------------------------------------------------+-------------------+------------+-----------+---------+------------+

+----------------------------------------------------------------------------------------------------------------------------+
|                                                 listen_addrs (prioritized)                                                 |
+----------------------------------------------------------------------------------------------------------------------------+
|                                                /ip4/31.208.250.61/tcp/44158                                                |
|/p2p/11pEL2CRTBPhSWoAMeNZn3XUTJ3YjxuXHDPnNvZBv2PKaw3YAfq/p2p-circuit/p2p/116Sa97proLW3oTBwUKtR1k7yxABCCwE3dnxvDwqhkh7snbEu3z|
+----------------------------------------------------------------------------------------------------------------------------+

perhaps don't stun relayed / nat symmetric devices? perhaps stun multiple and if any detect standard ip4 no nat then that takes precedence and other reports ignored?

[ci-work]

bump, this issue is still present and one of the causes of issues hotspot owners are complaining about, should be an easy fix

[madninja]

bump, this issue is still present and one of the causes of issues hotspot owners are complaining about, should be an easy fix

Want to supply a patch?

[ci-work]

Want to supply a patch?

I don't think I'm best placed to make adjustments here, however it looks to my untrained eye like if the list returned by libp2p_peer:connected_peers(MyPeer) was filtered to only include peers with a tcp address and no relay address, that it may help the issue (unsure if it would resolve fully) ? https://github.com/helium/erlang-libp2p/blob/451688b20a97c2fe90cacf0e6cb5f56b967268a0/src/libp2p_transport_tcp.erl#L495

Another approach may be to remove or not insert a relayer session if a valid tcp listen address is working?