Investigate UPnP problems

[ManfredKarrer]

Investigate the problems which some users have with UPnP.
Mike Hearn has reported and investigated some issues. In the last test session his router needed 4 sec. for UPnP and TomP2P has a timeout of 5 seconds, which might be one of the problems. That timeout is not configurable from outside but it should be an easy fix in the library to make it configurable.

Another issue [1] is that if the mapping table is full some routers dont report any error but fail silently (don't add a mapping). For that case a fix might be to delete old entries if the protocol allows that (port mapper tool supports taht, so should be possible). That might be only considered if the mapping table for auto mapping and maula are different. We must not delete manual entries, entried from automatic PF seems to be less problematic, as the apps can add then again on startup. But there should be additional policy (age, active) to not delete actual used mappings. So all in all that is a difficult area, and when we have realy mode supported it is less critical for us.

The port mapper tool might be used to investigate if the the weupnp lib used in TomP2P works reliable.

[1] bitletorg/weupnp#12

[ManfredKarrer]

@cbeams
If you want to test if a changed timeout solves your UPnP problems.
You need to add discoverTimeoutSec(8) in PeerNAT line 108:
DiscoverBuilder builder = new DiscoverBuilder(peer).peerAddress(futureNAT.reporter()).discoverTimeoutSec(8);

When you build locally our TomP2P fork you should get then the new timeout (default its 5 sec, and Mike Hearn reported UPnP took 4 sec for him, so with 8 sec. it should be more safe)

[ManfredKarrer]

Closed as related to TomP2P which is not used anymore.