Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
mickvandijke opened this issue Jul 19, 2024 · 4 comments
Open

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

mickvandijke opened this issue Jul 19, 2024 · 4 comments

Comments

@mickvandijke
Copy link

mickvandijke commented Jul 19, 2024

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
Copy link
Author

mickvandijke commented Jul 19, 2024

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
Copy link
Member

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
Copy link
Author

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
Copy link
Author

@dariusc93 Opened a PR for it that fixes it for me: dariusc93/rust-igd#8

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants