Unable to create port mappings in DC++ with MiniUPnP mapper while other apps using MiniUPnP succeed

[Sergei K]

Tested DC++ up to version 0.880. Windows 10 x64.

System Log:
 [17:35] Port mapping: Failed to initialize the MiniUPnP interface
 [17:35] Port mapping: Failed to map the Transfer port (54648 TCP) with the NAT-PMP interface
 [17:35] Port mapping: Failed to create port mappings

I tried to select a specific network interface in the settings, disable all network interfaces except one.
At the same time ApexDC++ and qBittorrent are successfully opened ports with UPnP.

[eMTee (realprogger)]

This looks to be a log snippet from an automatic connectivity detection operation. If so then that won't try all available interfaces by design, only the one that is set as default in the OS.

If you need to force a specific interface to use with DC++ then you have to set the connection settings manually.

[Sergei K (sk757a)]

Manual mode is used and network interface is selected.

[eMTee (realprogger)]

Please try to make sure DC++ is enabled in Windows/3rd party firewalls/app controls (if any), see https://dcplusplus.sourceforge.io/webhelp/faq_unblock.html

[Sergei K (sk757a)]

Everything looks good, just like other programs. But doesn't work :(

[Sergei K (sk757a)]

Turned off Windows firewall completely, same result.

[eMTee (realprogger)]

Well, I am out of suggestions that you might try with your current setup.

It's either our port mapping library/version is incompatible with your gateway or something else at play here. Obviously what I see in your screenshots are working here.

If you're up to do some rather easy tests (I guess you probably don't, you just simply want to use this program) then we might figure out more, otherwise I'm afraid the only solution for you is to try to do manual port forwarding in order to use DC++ right now.

[Sergei K (sk757a)]

Thanks for the advice. But I don't really need help with setting up the network. I'm sure everything is ok since all programs (p2p and others) work fine. I can just use ApexDC++, but I'm here to improve DC++. I have experience as a software developer, so I am ready to run any tests, collect logs or somehow help to localize the problem.

[eMTee (realprogger)]

Alright, let's start with test some older verisons with relevant changes to the mapper library to see whether this is a regression. I've made a few portable ones available to download from our website.

Please extract them to a separate folder to avoid interference with the installed version.

The two newer version should work the same as the current one, in 0.802 we had two UPnP mappers, one of which has been deprecated since. ApexDC++ also uses that one possibly, I'm not sure.

https://dcplusplus.sourceforge.io/DCPlusPlus-0.865-x64.zip
https://dcplusplus.sourceforge.io/DCPlusPlus-0.851-x64.zip
https://dcplusplus.sourceforge.io/DCPlusPlus-0.802.zip

For easier communication, if you like, you can join our dev hub at adcs://hub.dcbase.org:16591/?kp=SHA256/ATFW63HSK5RSOSSOGJ7GIRNEDWNQY7YK2GPZ3PKLSFVFZZTVL2ZA

Thanks for your help!

[Sergei K (sk757a)]

>The two newer version should work the same as the current one, in 0.802 we had two UPnP mappers, one of which has been deprecated since. ApexDC++ also uses that one possibly, I'm not sure.

Exactly.

ApexDC++ works for me because it uses Windows UPnP mapper, not MiniUPnP or NAT-PMP:
>Port mapping: Successfully created port mappings (TCP: 30000, UDP: 30000, TLS: 30001) on the "Generic" device with the Windows UPnP interface

And of course version 0.802 works too and others do not:
>Port mapping: Failed to initalize the MiniUPnP interface
>Port mapping: Failed to map the Transfer port (57515 TCP) with the NAT-PMP interface
>Port mapping: Successfully created port mappings (Transfers: 57515, Encrypted transfers: 57516, Search: 63870) on the "Generic" device with the Windows UPnP interface

So far it looks more likely so this is a problem in the router:
https://github.com/miniupnp/miniupnp/issues/634

[Sergei K (sk757a)]

I thought that my router can't work with any miniupnpc version at all. But there is Emule. It uses miniupnpc and works for me!

22.10.2022 23:42:33: Using MiniUPnPLib based implementation
22.10.2022 23:42:33: miniupnpc (c) 2005-2021 Thomas Bernard - http://miniupnp.free.fr/
22.10.2022 23:42:35: List of UPNP devices found on the network:
22.10.2022 23:42:35: Desc: http://192.168.158.1:1900/igd.xml, st: urn:schemas-upnp-org:device:InternetGatewayDevice:1
22.10.2022 23:42:35: Found a (not connected?) IGD : http://192.168.158.1:1900/ipc - Trying to continue anyway
22.10.2022 23:42:35: Our LAN IP: 192.168.158.130
22.10.2022 23:42:35: Successfully added mapping for port 28244 (TCP) on local IP 192.168.158.130
22.10.2022 23:42:35: Successfully added mapping for port 43088 (UDP) on local IP 192.168.158.130

[eMTee (realprogger)]

Yeah, depending on the outcome I was about to recommend running the MiniUPnPc command line client next to see what happens but you overtook me in a way and confirmed that the library is indeed working well with your router.

I'll try to build something that emits more about why the mapper initialization fails at you.

[eMTee (realprogger)]

Can you please try a MiniUPnP mapping with the attached debug build? It'll open a console where it should print a line starting with 'Mapper_MiniUpnp:' the same time when you get the error message in the program UI.

[Sergei K (sk757a)]

Mapper_MiniUpnp: ret from UPNP_GetValidIGD is : 2

[eMTee (realprogger)]

Yeah, that was expected looking at the code and your earlier eMule log.
Basically this means your router does not report to be connected (to the Internet presumably) by the way MiniUPnP detects it and our current code doesn't accept those as a successfully usable device for mapping.

See https://github.com/miniupnp/miniupnp/blob/207cf440a22c075cb55fb067a850be4f9c204e6e/miniupnpc/src/miniupnpc.c#L532 which calls https://github.com/miniupnp/miniupnp/blob/207cf440a22c075cb55fb067a850be4f9c204e6e/miniupnpc/src/miniupnpc.c#L516 for the connectivity detection - which is really a hackish detection so it's not a surprise that some IGD implementations may return other arbitrary string (or nothing) there with the connection status.

The problem is that unconditionally accepting these cases are illogical since if the device is really not connected or it is e.g. an old router used for switch in a local network with UPnP service left enabled, etc... then it is unusable for our purpose.

You do have only one gateway device in your local network, right?

We are weighing options for checking for all available gateways and use unconnected ones only if there's no connected one, possibly with a warning displayed but it'd make the current straightforward slick mapper init thing a lot more difficult (and error prone).

Another way is to add an "Advanced device discovery" option to manual connectivity settings and do the above only if it's enabled manually and do not use it for the automatic connectivity detection process.

If you're curious we can give another go and get what status string your router provides while it is apparently connected - maybe M. Bernard would also interested on it :) Though skimming through https://github.com/miniupnp/miniupnp/blob/207cf440a22c075cb55fb067a850be4f9c204e6e/miniupnpc/src/upnpcommands.c#L119 I won't be surprised to see no string returned at all, etiher.

[Sergei K (sk757a)]

This problem is not only in my router model. Shame. https://community.tp-link.com/us/home/forum/topic/577840

[Sergei K (sk757a)]

Thank you very much for your participation. Now everything has become clearer and I do not see an error in the behavior of the program. I think the question can be closed.

The only thing I'm wondering is why the Windows UPnP mapper implementation was rejected?

[eMTee (realprogger)]

We want to fix this somehow by adding a possibility to detect these slightly ill behaving routers so this remains open. Especially after seeing your link suggesting there's a whole lot of newish TP-Link models suffer from this issue.

The Windows UPnP mapper implementation was great option when it's been added ~20 years ago but it was pretty unstable and error prone, not working well with many router models and produce false positives (report success when port mapping won't work) with others. Eventually we thought MiniUPnP would cover it all as we've found great rate of successful port mappings with it.