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
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?
--
You received this bug
This problem is not only in my router model. Shame.
https://community.tp-link.com/us/home/forum/topic/577840
--
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
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
Mapper_MiniUpnp: ret from UPNP_GetValidIGD is : 2
--
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
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.
** Attachment added: "DCPlusPlus_debug.zip"
6 matches
Mail list logo
