Comment 14 for bug 1993817

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.