UPnP in the TcpConfig

[tomaka]

Add attempt_upnp: bool in the TcpConfig, and implement it!

[tomaka]

Some references:

• http://www.upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf
• http://www.upnp-hacks.org/igd.html
• https://github.com/sbstp/rust-igd (MIT, but pulls lots of dependencies, and uses boxes without Send)

One issue is that listen_on is only allowed to produce one listened address, while in practice if we traverse a NAT we are actually listening on two addresses: the one on the LAN and the on on the WAN.
Maybe listen_on should return an Iterator<Item = Multiaddr> instead of a Multiaddr.

[twittner]

How about PCP instead of IGD?

[tomaka]

Whatever works!

[dvdplm]

@twittner I couldn't find any rust lib that implements PCP – do you know of any?

[Isan-Rivkin]

@dvdplm
Maybe this one pcp_mmv-rs
Or you could maybe use FFI

• pcp
• repcpc

[twittner]

@dvdplm: No, I do not. FYI, I have started a small UPNP-IGD implementation at https://github.com/paritytech/upnp-igdp but it is currently using a fork of tokio and I am reluctant to test it, given the security implications of opening port mappings available to the outside world.

[dvdplm]

fork of tokio

Curious: why did you have to fork it?

[tomaka]

Curious: why did you have to fork it?

tokio-rs/tokio#710

[tomaka]

I'm kind of conflicted whether this is a good "getting-started" issue.

The problem we encountered is that opening on the router is not instantaneous.
When one calls listen_on on TcpConfig, it needs to open ports. However the listen_on method is expected to immediately return the listened address, which depends on opening ports.

This also raises the question of making listen_on report known external addresses, for example the IP addresses of the local network interfaces.

[thomaseizinger]

Closed as stale.