linuxdcpp-team team mailing list archive

[eMTee <1993817@xxxxxxxxxxxxxxxxxx>]

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