upnp: Gateway does not support UPnP (but it does)

[mickvandijke]

Summary

When I run the libp2p upnp example, I get the following message:

Gateway does not support UPnP

This is strange as my gateway most definitely does support upnp. I have tested it with miniupnpc and different other applications. Diving into the logs of an application that uses libp2p-upnp, I found this:

[2024-07-19T13:46:01.370996Z DEBUG libp2p_upnp::behaviour/Swarm::poll/NetworkBehaviour::poll] could not find gateway: Invalid response

Interestingly enough, the upnp port examples of rust-igd/igd-next work perfectly for me.

Expected behavior

I expected UPnP to function.

Actual behavior

UPnP did not function.

Relevant log output

[2024-07-19T13:46:01.370996Z DEBUG libp2p_upnp::behaviour/Swarm::poll/NetworkBehaviour::poll] could not find gateway: Invalid response

[2024-07-19T13:46:01.371020Z INFO sn_networking::event::swarm] UPnP event upnp_event=GatewayNotFound

[2024-07-19T13:46:01.371155Z DEBUG libp2p_upnp::behaviour/Swarm::poll] network gateway not found, UPnP port mapping of multiaddres discarded multiaddres=/ip4/192.168.0.207/udp/58142/quic-v1

Possible Solution

No response

Version

0.53.2

Would you like to work on fixing this bug ?

Maybe

[mickvandijke]

Problem stems from igd_next apparently. igd_next::aio::tokio::search_gateway() finds my Philips HUE bridge instead of my router and returns a parsing error..

[dariusc93]

Thanks for the report. Not sure why it would be giving that error or why its finding one gateway and not the other, but i do know some firmwares dont really follow igd spec and can be messy (which the spec sometime is vs pcp or nat-pmp). What type of router or modem do you use if you dont mind me asking? Is the ip reported from libp2p the same you used when running the example? Is your bridge also connected to the same machine with its own ip assigned?

[mickvandijke]

Hi @dariusc93 ,

I have looked at the code and I think the issue is that after sending the search request signal, the first response it gets is determined as the gateway. Unfortunately for me, it seems that my HUE bridge is always the first responder (the HUE bridge does have its own IP and is connected to my router). When I manually test my Router's (ASUS) UPnP response, I have no issues. Only the HUE bridge doesn't follow the igd spec and that causes the fail.

The fix would probably be to listen for more devices that answer the search request, instead of just accepting the first one. And then perhaps testing which is the router (or follows the igd spec).

[mickvandijke]

@dariusc93 Opened a PR for it that fixes it for me: https://github.com/dariusc93/rust-igd/pull/8