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. -- You received this bug notification because you are a member of Dcplusplus-team, which is subscribed to DC++. https://bugs.launchpad.net/bugs/1993817 Title: Unable to create port mappings in DC++ with MiniUPnP mapper while other apps using MiniUPnP succeed Status in DC++: Confirmed Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/dcplusplus/+bug/1993817/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~linuxdcpp-team Post to : linuxdcpp-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~linuxdcpp-team More help : https://help.launchpad.net/ListHelp
