autonat/upnp gap between rust-libp2p and go-libp2p

Description

Here is a user report about upnp in go-libp2p works in their WSL2 environment while upnp in rust-libp2p does not.

I did some analysis and found that,

• go-libp2p-upnp makes 3 attempts discoverUPNP_IG1 (), discoverUPNP_IG2 () and discoverUPNP_GenIGDev while what rust-libp2p-upnp does is equivilent to discoverUPNP_IG1.
• go-libp2p-upnp tries to map an internal port to a random external port with reties, while rust-libp2p-upnp tries to map an internal port to the same external port.

func discoverUPNP_IG1(ctx context.Context) ([]NAT, []error) {
	return discoverSearchTarget(ctx, internetgateway1.URN_WANConnectionDevice_1)
}

func discoverUPNP_IG2(ctx context.Context) ([]NAT, []error) {
	return discoverSearchTarget(ctx, internetgateway2.URN_WANConnectionDevice_2)
}

// discoverUPNP_GenIGDev is a fallback for routers that fail to respond to our
// targetted SSDP queries. It will query all devices and try to find any
// InternetGatewayDevice.
func discoverUPNP_GenIGDev(ctx context.Context) (nats []NAT, errs []error) {
    ...
}

Is this a known issue and is there plan to close such feature gap? Thanks!

Motivation

To close feature gap in upnp between rust-libp2p and go-libp2p

Current Implementation

go-libp2p-upnp makes more attempts and rust-libp2p-upnp as described above.

Are you planning to do it yourself in a pull request?

Maybe

Start by comparing the rust-libp2p-upnp implementation with the go-libp2p-upnp entry points discoverUPNP_IG1, discoverUPNP_IG2, and discoverUPNP_GenIGDev. Review how each implementation discovers gateways and maps ports; done means closing the documented discovery and external-port retry gaps.