Qbittorrent: UPnP/NAT-PMP: Port mapping failure, message: could not map port using UPnP: unknown UPnP error (-911)

[stdedos]

qBittorrent version and Operating System

4.2.4 / Win10 1803 (17134.1006)

What is the problem

UPnP/NAT-PMP: Port mapping failure, message: could not map port using UPnP: unknown UPnP error (-911)

I am also getting that non-green-plug icon (is it a yellow flame?)

My router has a lot of _very weird design flaws_, but none-the-less, UPnP works. It used to work with qbittorrent too.
I see other applications registering their UPnP too.

What is weirder though is that I can do it myself e.g. with this http://miniupnp.free.fr/files/

C:\Users\usr>E:\usr\Desktop\upnpc-exe-win32-20150918\upnpc-static.exe -a 5.5.5.2 12345 12345 tcp
upnpc : miniupnpc library test client, version 1.9.
 (c) 2005-2014 Thomas Bernard.
Go to http://miniupnp.free.fr/ or http://miniupnp.tuxfamily.org/
for more information.
List of UPNP devices found on the network :
 desc: http://5.5.5.1:1900/gatedesc.xml
 st: urn:schemas-upnp-org:device:InternetGatewayDevice:1

Found valid IGD : http://5.5.5.1:1900/upnp/control/WANIPConn1
Local LAN ip address : 5.5.5.2
ExternalIPAddress = 1.1.1.1
InternalIP:Port = 5.5.5.2:12345
external 1.1.1.1:12345 TCP is redirected to internal 5.5.5.2:12345 (duration=0)

At which time I can see this:

[stdedos]

There are a lot of UPnP issues opened (e.g. https://github.com/qbittorrent/qBittorrent/issues/12066, https://github.com/qbittorrent/qBittorrent/issues/11759) but they don't see related to mine

[FranciscoPombal]

Is it possible that your router does not support upnp lease duration? try playing with that value (it's in the advanced settings). See https://github.com/arvidn/libtorrent/blob/c537f6277f4de2d80cadc0eb40733ac8705f4cad/include/libtorrent/settings_pack.hpp#L1777 and https://github.com/qbittorrent/qBittorrent/pull/12175

[stdedos]

Is it possible that your router does not support upnp lease duration? try playing with that value (it's in the advanced settings). See arvidn/libtorrent:include/libtorrent/settings_pack.hpp@c537f62#L1777 and #12175

Does not apply:

and timed lease works with the example program I've used

[FranciscoPombal]

@stdedos is this a 4.2.4 regression, or was this already happening previously?

[stdedos]

Things have changed on my PC too these days, so I cannot guarantee that 4.2.2 and 4.2.4 run on the exact same configuration.

My bisect range would be 4.2.2-4.4.4 - but I don't know.
I know that there is a program that at this time can do it though, so my money would be qbt's UPnP is "not complete"/broken (and I don't know what NAT-PMP is).

[iz8mbw]

@starius please can you confirm that with version 4.2.1 you don't have this issue?
If you don't have the issue with version 4.2.1 may be you have exactly the same problem I have, see here https://github.com/qbittorrent/qBittorrent/issues/12406 and here https://github.com/qbittorrent/qBittorrent/issues/12406#issuecomment-620649397

In my case the problem is born with the "upnp lease duration" feature (also if I set it to "0").

@FranciscoPombal if the value of "upnp lease duration" is "0" this means that value "0" is sent to the router or this means that parameter is not sent like before to introduce the "upnp lease duration" in libtorrent?

I mean, if the value is set to "0" I expect that the upnp feature in libtorrent will not sent to the router the parameter so the upnp feature will works like in the past (when it worked also to me). Is it so?

[FranciscoPombal]

@iz8mbw
For me temporary leases work as well as previously, and setting it to 0 also works.

Setting to 0 also works for me. I would expect that if upnp lease duration is set to 0, that lease duration is not sent at all. It is possible that is actually being sent, and might router happens to work depite that, still.

If you do a wireshark capture and find that 0 is being set, let us know.

[stdedos]

@starius please can you confirm that with version 4.2.1 you don't have this issue?
If you don't have the issue with version 4.2.1 may be you have exactly the same problem I have, see here #12406 and here #12406 (comment)

In my case the problem is born with the "upnp lease duration" feature (also if I set it to "0").

By starius you mean @stdedos, I assume?

I would be willing to downgrade, if someone that has bisected the repository has any suspicion that the code was changed - otherwise, I don't like to play with anything that might interfere with the sanity of the configuration or the torrents themselves.

[iz8mbw]

In fact, send the parameter "0" and do not send that parameter are two different thing :-)
For your info, I can confirm that with version 4.2.1 the UPnP still works and so I'm able to open ports on gateway.
Then I still suspect that problem is born with the introduction of "upnp lease duration" (also is it's "0"), may be my gateway is not able to recognize the lease duration parameter also if it's 0.
I think the "solution" for almost all users is to can choose via "settings" if send or not send the "upnp lease duration" and if send it gives the possibility to choose the value in number.
Will do wireshark.

Thank you!

[iz8mbw]

@starius please can you confirm that with version 4.2.1 you don't have this issue?
If you don't have the issue with version 4.2.1 may be you have exactly the same problem I have, see here #12406 and here #12406 (comment)
In my case the problem is born with the "upnp lease duration" feature (also if I set it to "0").

By starius you mean @stdedos, I assume?

I would be willing to downgrade, if someone that has bisected the repository has any suspicion that the code was changed - otherwise, I don't like to play with anything that might interfere with the sanity of the configuration or the torrents themselves.

Yes sorry....
I personally upgraded from 4.2.1 to 4.2.5 and after come back (downgrade) from 4.2.5 to 4.2.1 without problems. You can find the old release here: https://www.fosshub.com/qBittorrent-old.html

[stdedos]

@starius please can you confirm that with version 4.2.1 you don't have this issue?
If you don't have the issue with version 4.2.1 may be you have exactly the same problem I have, see here #12406 and here #12406 (comment)
In my case the problem is born with the "upnp lease duration" feature (also if I set it to "0").

By starius you mean @stdedos, I assume?
I would be willing to downgrade, if someone that has bisected the repository has any suspicion that the code was changed - otherwise, I don't like to play with anything that might interfere with the sanity of the configuration or the torrents themselves.

Yes sorry....
I personally upgraded from 4.2.1 to 4.2.5 and after come back (downgrade) from 4.2.5 to 4.2.1 without problems. You can find the old release here: fosshub.com/qBittorrent-old.html

I am not saying otherwise - both of them should be minor version updates aka fully compatible with each other, either way. The fact that one person did (or multiple), does not mean it's fool-proof though.

[iz8mbw]

Do it if you can/want to do it. It's a test also for you.

[arvidn]

@stdedos could you get a wireshark dump of the UPnP traffic from qbt, and post it here?

[FranciscoPombal]

This could be related: https://github.com/arvidn/libtorrent/issues/4580. That particular issue was recently fixed by https://github.com/arvidn/libtorrent/pull/4585.

Can anyone test with that patch?

[stdedos]

@arvidn
@stdedos could you get a wireshark dump of the UPnP traffic from qbt, and post it here?

upnp-only.pcapng.gz
There you go - but I cannot read if that's useful or not

This could be related: arvidn/libtorrent#4580. That particular issue was recently fixed by arvidn/libtorrent#4585.

Can anyone test with that patch?

I am on Windows, so I don't know how would that work

[arvidn]

@stdedos really the only thing that patch fixes it to make it possible to change the lease duration setting on the fly. If you change it and restart, it should still take effect. Which I assume you have done by now anyway

[stdedos]

@stdedos really the only thing that patch fixes it to make it possible to change the lease duration setting _on the fly_. If you change it and restart, it should still take effect. Which I assume you have done by now anyway

It would've been nice if it were possible to manually trigger UPnP from the settings. But yes, at this time, in order to try and see what happens with UPnP, is to restart qtb.

Not that bad, but still a bit inconvenient.

[FranciscoPombal]

@stdedos

It would've been nice if it were possible to manually trigger UPnP from the settings. But yes, at this time, in order to try and see what happens with UPnP, is to restart qtb.

Not that bad, but still a bit inconvenient.

I think you misunderstood what was said. It was already possible to toggle upnp without restarting, now it's _also_ possible to change the lease duration without restarting.

[stdedos]

@stdedos

It would've been nice if it were possible to manually trigger UPnP from the settings. But yes, at this time, in order to try and see what happens with UPnP, is to restart qtb.

Not that bad, but still a bit inconvenient.

I think you misunderstood what was said. It was already possible to toggle upnp without restarting, now it's _also_ possible to change the lease duration without restarting.

Manually triggered or hidden inside the "OnChange" event of the port number?

[arvidn]

@stdedos looking at that wireshark, I only see the SSDP (discovery) exchange. Is there no HTTP connection as well? Or did you filter that out?

I would have expected a request to http://192.168.1.1:1900/gatedesc.xml

[stdedos]

@stdedos looking at that wireshark, I only see the SSDP (discovery) exchange. Is there no HTTP connection as well? Or did you filter that out?

I would have expected a request to http://192.168.1.1:1900/gatedesc.xml

I saved with ssdp filter, as the network was highly active at the time. I thought it would be enough 😕

[FranciscoPombal]

Manually triggered or hidden inside the "OnChange" event of the port number?
Look at the patch, libtorrent automatically handles it:
https://github.com/arvidn/libtorrent/pull/4585/files

[arvidn]

@stdedos if you filter with ip.addr == 192.168.1.1 I think you'd mostly just get the UPnP traffic

[stdedos]

Manually triggered or hidden inside the "OnChange" event of the port number?
Look at the patch, libtorrent automatically handles it:
#4585 (files)

Apologies, my cpp skills are not that good, neither can I navigate such big (real) projects I am not working against 😕

"I can settle" in restarting qbt to explicitly trigger the mapping

[xavier2k6]

Windows test build of 4.2.5 with listed libraries:

libtorrent-rasterbar | 1.2.6 +git e2501c0
Qt                   | 5.14.2
OpenSSL              | 1.1.1g
zlib                 | 1.2.11
Boost                | 1.73

@stdedos Can you try below build please?

qBittorrent 4.2.5 + libtorrent commit e2501c0 with Boost 1.73

[iz8mbw]

Hi all @FranciscoPombal @arvidn
I have captured with Wireshark and here the captures:
version 4.2.1 upnp works
version 4.2.5 upnp does not works (could not map port using UPnP: no router found).
v4.2.1_upnp_OK.zip
v4.2.5_upnp_NOT_ok.zip

As you can see in the capture, the version 4.2.5 is not able to find the upnp "server" that in my case has IP 10.255.255.250 on port 1900.
The version 4.2.1 is able to find it and so talk to it via HTTP/1.1 and so open ports.

Thank you.

[stdedos]

@arvidn
@stdedos if you filter with ip.addr == 192.168.1.1 I think you'd mostly just get the UPnP traffic

No, sorry, it's not mostly just this traffic 😕

It seems though we have someone that did it.

[xavier2k6]

@iz8mbw can you try the build in https://github.com/qbittorrent/qBittorrent/issues/12610#issuecomment-620943593

[iz8mbw]

@xavier2k6 tested it works "bad" like 4.2.5: "could not map port using UPnP: no router found"

[FranciscoPombal]

@iz8mbw what value did you set the upnp lease duration setting to for the wireshark capture above?

[iz8mbw]

@iz8mbw what value did you set the upnp lease duration setting to for the wireshark capture above?

0

[iz8mbw]

@FranciscoPombal @arvidn
Here more detailed captures with better filtering:
v4.2.1_upnp_OK_MORE_DETAILS.zip
v4.2.5_upnp_NOT_ok_MORE_DETAILS.zip

[iz8mbw]

but we are (wrongly) still focus on the "upnp lease duration".
If you look well to the capture, it's clear that after the discovery, qbittorrent will not go to make the GET /gateDesc.xml and after the POST /upnp/control/WANIPConn1 to the upnp "gateway" (that can be a router or a software server) in order to open ports.

[iz8mbw]

and, the "upnp lease duration" seems to be present also on version 4.2.1 setted already to "0" by default:
<NewPortMappingDescription>qBittorrent/4.2.1</NewPortMappingDescription><NewLeaseDuration>0</NewLeaseDuration></u:AddPortMapping></s:Body></s:Envelope>

Full text of the POST from capture (version 4.2.1 where upnp works):

POST /upnp/control/WANIPConn1 HTTP/1.1
Host: 10.255.255.250:1900
Content-Type: text/xml; charset="utf-8"
Content-Length: 600
Soapaction: "urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping"

<?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1"><NewRemoteHost></NewRemoteHost><NewExternalPort>27257</NewExternalPort><NewProtocol>TCP</NewProtocol><NewInternalPort>27257</NewInternalPort><NewInternalClient>10.132.211.194</NewInternalClient><NewEnabled>1</NewEnabled><NewPortMappingDescription>qBittorrent/4.2.1</NewPortMappingDescription><NewLeaseDuration>0</NewLeaseDuration></u:AddPortMapping></s:Body></s:Envelope> HTTP/1.1 200 OK
Content-Length: 260
Content-Type: 'text/xml;  charset="utf-8"
Server: Linux/2.6 UPnP/1.0 HideUPnP/1.0
Date: Wed, 29 Apr 2020 11:55:36 GMT

<?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:AddPortMappingResponse xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1"/></s:Body></s:Envelope>

[arvidn]

@iz8mbw

as far as I can tell from the capture where it doesn't work (assuming it would have captured any HTTP request to the router as well), the problem is likely that the router isn't on the same subnet as your local network. I think that can happen sometimes, but it's kind of weird. I would like to know more about your setup.

The reason libtorrent doesn't contact routers outside of the subnet is because sometimes people have large networks with mutlicast enabled, and you will discover all your neighbour's routers as well, but we should really only care about yours.

so, what I see in the capture us that you (10.231.211.194) broadcast the SSDP M-SEARCH message. a gateway device responds (10.255.255.250) saying it's a UPnP device.

libtorrent appears to be ignoring this and I'm supposing it's because your netmask for your network is 255.255.0.0 for some reason, instead of 255.0.0.0. Assuming your netmask indicates the root device (10.255.255.250) is outside of your network this is expected behavior. This was a somewhat recent change in libtorrent, where previously it was configurable to ignore such routers or not.

So, I have two questions:

1. is your netmask "narrow" enough to make the gateway be outside of your network? (i.e. (your_ip & netmask) != router_ip & netmask)).

2. is your network "router" or "gateway" set to this IP as well? 10.255.255.250?

[iz8mbw]

Hi @arvidn
The latest captures (the more detailed ones) on this post https://github.com/qbittorrent/qBittorrent/issues/12610#issuecomment-621157201 should captured all what we needs and were made whith:

ip.dst == 10.255.255.250 || ip.dst == 239.255.255.250 || ip.src == 10.255.255.250 || ip.src == 239.255.255.250

where:
10.255.255.250 is the UPnP "server"
239.255.255.250 is the SSDP

Yes, in this scenario the UPnP "server" is not my router but a software UPnP "server" since I'm using a VPN.

This is the IP/Network configuration of my PC while connected to the VPN:

IP: 10.231.211.194
Subnet Mask: 255.255.255.255
Gateway: 0.0.0.0

In this VPN scenario for sure the UPnP "server" is outside my LAN since my subnet mask is 255.255.255.255 and since it is a Linux UPnP Server: Linux/2.6 UPnP/1.0 HideUPnP/1.0.

Well, since libtorrent has the answer from a UPnP "server" (10.255.255.250 in my case), I expect that it tries anyway to go ahead by contact it (to open ports) but this does not happens.

Thank you.

[iz8mbw]

I think my problem is the same of https://github.com/arvidn/libtorrent/issues/4471

[arvidn]

could someone give this a try? https://github.com/arvidn/libtorrent/pull/4595

[iz8mbw]

@xavier2k6 you would be so kind to make a qBittorrent Windows 64bit built that include this https://github.com/arvidn/libtorrent/pull/4595 libtorrent patch?
Thank you.

[xavier2k6]

@iz8mbw Here you go!

Windows test build of 4.2.5 with https://github.com/arvidn/libtorrent/pull/4595
Libraries used:

libtorrent-rasterbar | 1.2.6 +git 9edc542
Qt                   | 5.14.2
OpenSSL              | 1.1.1g
zlib                 | 1.2.11
Boost                | 1.73

qBittorrent 4.2.5 with libtorrent patch #4595

[iz8mbw]

@xavier2k6 many thanks!
@arvidn Thank you, UPnP WORKS AGAIN!!!!

[stdedos]

@arvidn How does that look like? upnp-only-v2.pcapng.gz

note that this is still with v4.2.4 and not v4.2.5, since "there seems to be something wrong" and seeding torrents "does not work" for some reason - trackers are marked as "Not working" (happens also with downloads, but not consistently.

@FranciscoPombal what would you require to investigate the aforementioned issue? Or is it known issue already?

[iz8mbw]

@stdedos I gave a fast look to the capture and the answer from your router is HTTP/500 (Internal Server Error).
More, I don't why but I cannot see the word "qBittorrent" in the HTTP POST for the description field <NewPortMappingDescription></NewPortMappingDescription>...

[FranciscoPombal]

@stdedos

@arvidn How does that look like? upnp-only-v2.pcapng.gz

note that this is still with v4.2.4 and not v4.2.5, since "there seems to be something wrong" and seeding torrents "does not work" for some reason - trackers are marked as "Not working" (happens also with downloads, but not consistently.

@FranciscoPombal what would you require to investigate the aforementioned issue? Or is it known issue already?

I think the following would be useful:

1. upnp traffic capture with 4.2.5 with upnp lease duration disabled
2. upnp traffic capture with the patched build (https://github.com/qbittorrent/qBittorrent/issues/12610#issuecomment-621789872) with upnp lease duration disabled
3. repeat 1 & 2 with upnp lease duration enabled (you can set it to something like 5 minutes to speed up testing).

So 4 captures in total. Hopefully one of these will either work or reveal some more workable error than "500 internal server error".

[stdedos]

Given the time required of cropping the traffic captures (since proto:ssdp does not cut it), I would say that this is not possible.

Especially given that I have provided a working example of a different program being able to create a UPNP lease, I'll just continue downgrading until something suitable comes up ...

[FranciscoPombal]

@stdedos even if doing the wireshark capture is not possible for you right now, you could just test the patched build. It solved the problem for the other user, there's a chance it could also solve it for you.

[iz8mbw]

Given the time required of cropping the traffic captures (since proto:ssdp does not cut it), I would say that this is not possible.

Especially given that I have provided a working example of a different program being able to create a UPNP lease, I'll just continue downgrading until something suitable comes up ...

but I did not understand one thing: did you test it https://github.com/qbittorrent/qBittorrent/issues/12610#issuecomment-621789872?

[stdedos]

I just downloaded the above build. It does not fix UPnP.

However, it does fix some "not contacted / not working" torrents that are seeding though - so I'll keep this one instead.

[iz8mbw]

well, now next step is you go to capture with this build.

[stdedos]

upnp-1.2.6 +git 9edc542.pcapng.gz

[arvidn]

@stdedos This is what your UPnP router says, when libtorrent attempts to open a port:

HTTP/1.1 500 Internal Server Error
CONTENT-LENGTH: 413
CONTENT-TYPE: text/xml; charset="utf-8"
DATE: Thu, 07 May 2020 14:28:36 GMT
EXT:
SERVER: Linux/3.4.11-rt19, UPnP/1.0, Portable SDK for UPnP devices/1.6.19
X-User-Agent: redsonic

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<s:Fault>
<faultcode>s:Client</faultcode>
<faultstring>UPnPError</faultstring>
<detail>
<UPnPError xmlns="urn:schemas-upnp-org:control-1-0">
<errorCode>-911</errorCode>
<errorDescription>Internal Error</errorDescription>
</UPnPError>
</detail>
</s:Fault>
</s:Body>
</s:Envelope>

I don't believe -911 is an error code defined by the UPnP standard, that's why it's being reported as "unknown UPnP error".

The request libtorrent i sending is:

POST /upnp/control/WANIPConn1 HTTP/1.1
Host: 192.168.1.1:1900
Content-Type: text/xml; charset="utf-8"
Content-Length: 580
Soapaction: "urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping"

<?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1"><NewRemoteHost></NewRemoteHost><NewExternalPort>49935</NewExternalPort><NewProtocol>TCP</NewProtocol><NewInternalPort>49935</NewInternalPort><NewInternalClient>192.168.1.2</NewInternalClient><NewEnabled>1</NewEnabled><NewPortMappingDescription></NewPortMappingDescription><NewLeaseDuration>0</NewLeaseDuration></u:AddPortMapping></s:Body></s:Envelope>

Perhaps your router doesn't support lease duration 0, try configuring it to, say, 3600 instead.

[stdedos]

Did you look at the very first post of this issue?
I _can_ set an infinite duration lease.

And no, non-0 lease does not help qbt.

[arvidn]

Did you look at the very first post of this issue?

Yes, but a long time ago.

It seems clear that your router is "UPnP challenged". The question is, what kinds of requests will it accept? Do you have a capture of when it works?

[stdedos]

It seems clear that your router is "UPnP challenged".

That wouldn't suprise me 😒
I've been trying to get the company to fix it, issue RMA, refund me ....

For the record (and to issue some bad publicity, since the company believes it "works as it is supposed to"), it's a TP-Link Archer VR400.

The question is, what kinds of requests will it accept? Do you have a capture of when it works?

upnp-works.pcapng.gz

I guess the response is: "Don't send 0" when the lease is supposed to be permanent

[FranciscoPombal]

I guess qBittorrent/libtorrent needs an option to not send lease values at all then.

[stdedos]

Or you can just do this after 1 (or 3) failures of the "normal" attempt to send a lease.

And/or, match the error code too.

[iz8mbw]

I guess qBittorrent/libtorrent needs an option to not send lease values at all then.

I fully agree.
In my opinion, the options should be:

1. Disable (do not send lease parameter at all)
2. Enable but customizable (BUT set to 0 by default)

[arvidn]

If the UPnP spec allows to omit the lease duration, that might make sense when it's 0

[iz8mbw]

If the UPnP spec allows to omit the lease duration, that might make sense when it's 0

Sure!

[arvidn]

the problem is that it's virtually impossible how many other UPnP implementations break with such change. It's a game of whack-a-mole..

[stdedos]

Why isn't this suggestion taken into account?

Or you can just do this after 1 (or 3) failures of the "normal" attempt to send a lease.

And/or, match the error code too.

Code won't look nice, but it doesn't have to be that ugly ...

[arvidn]

Why isn't this suggestion taken into account?

Or you can just do this after 1 (or 3) failures of the "normal" attempt to send a lease.

And/or, match the error code too.

That's a lot of work. It adds additional state which doubles the number of existing states which introduces a lot of opportunities for unexpected and incorrect behavior. It's also hard to test (until I have implemented a UPnP device in the simulator, but it's hard to motivate doing that, I just don't like UPnP enough).

I don't think the error code (-911) is standard (iirc, the defined error codes are positive numbers) so that would probably not be a good hint to use.

I suppose we could build a database of known shortcomings of various implementations and fingerprint devices and select a configuration that's likely to work. I would rather work on other things though, and just let PCP gain popularity.

[stdedos]

I am not sure I understand why, but I guess I can trust you.

So please add me a flag, if you may?

[arvidn]

This is the request that worked:

POST /upnp/control/WANIPConn1 HTTP/1.1
Host: 192.168.1.1:1900
User-Agent: MSWindows/6.3.9600, UPnP/1.1, MiniUPnPc/2.1
Content-Length: 595
Content-Type: text/xml
SOAPAction: "urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping"
Connection: Close
Cache-Control: no-cache
Pragma: no-cache

<?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body>
<u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1">
<NewRemoteHost></NewRemoteHost>
<NewExternalPort>51181</NewExternalPort>
<NewProtocol>TCP</NewProtocol>
<NewInternalPort>51181</NewInternalPort>
<NewInternalClient>192.168.1.2</NewInternalClient>
<NewEnabled>1</NewEnabled>
<NewPortMappingDescription>libminiupnpc</NewPortMappingDescription>
<NewLeaseDuration>0</NewLeaseDuration>
</u:AddPortMapping></s:Body></s:Envelope>

This is the request that failed:

POST /upnp/control/WANIPConn1 HTTP/1.1
Host: 192.168.1.1:1900
Content-Type: text/xml; charset="utf-8"
Content-Length: 578
Soapaction: "urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping"

<?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body>
<u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1">
<NewRemoteHost></NewRemoteHost>
<NewExternalPort>8080</NewExternalPort>
<NewProtocol>TCP</NewProtocol>
<NewInternalPort>8080</NewInternalPort>
<NewInternalClient>192.168.1.2</NewInternalClient>
<NewEnabled>1</NewEnabled>
<NewPortMappingDescription></NewPortMappingDescription>
<NewLeaseDuration>0</NewLeaseDuration>
</u:AddPortMapping></s:Body></s:Envelope>

(I've inserted line breaks for easier reading)

[arvidn]

I don't think the lease duration tag is the issue

[stdedos]

I don't see anything either. If anything, my request has much more things.
The only think I am suspecting: you mark it as ; charset="utf-8", and your header is "not properly cased".

Also note, you probably caught the wrong port. qbt is set on random port for each start. 8080 is awfully specific for a "random" port.

[arvidn]

I think libminiupnpc is capitalizing its HTTP headers wrong :)

I don't know what you mean by "caught the wrong port". I copy pasted this from wireshark, verbatim (from your captures). Perhaps there's a web UI that maps port 8080?

Here's the other one from upnp-only-v2 capture (which also fails in the same way):

POST /upnp/control/WANIPConn1 HTTP/1.1
Host: 192.168.1.1:1900
Content-Type: text/xml; charset="utf-8"
Content-Length: 580
Soapaction: "urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping"

<?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body>
<u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1">
<NewRemoteHost></NewRemoteHost>
<NewExternalPort>64866</NewExternalPort>
<NewProtocol>UDP</NewProtocol>
<NewInternalPort>64866</NewInternalPort>
<NewInternalClient>192.168.1.2</NewInternalClient>
<NewEnabled>1</NewEnabled>
<NewPortMappingDescription></NewPortMappingDescription>
<NewLeaseDuration>0</NewLeaseDuration>
</u:AddPortMapping></s:Body></s:Envelope>

[stdedos]

I think libminiupnpc is capitalizing its HTTP headers wrong :)

At least _it_ works 😛

8080 is coming from qbt's WebUI probably.

However, I started this after trying to investigate issues with "keeping up" connections (and not the WebUI I barely even used) - so maybe it's different. Or it's not idk.

[iz8mbw]

Hi @arvidn why the POST that fails here https://github.com/qbittorrent/qBittorrent/issues/12610#issuecomment-625527274 there is not the "Description" parameter (<NewPortMappingDescription></NewPortMappingDescription>)?
I mean, since the POST was done by qBittorrent I expect that this filed is valorized beacuse qBittorrent valorize it....

And, may be a blank "Description" parameter can generate a UPnP fail on that router?

[arvidn]

@stdedos has UPnP worked for you in older versions of qbt?

[stdedos]

Honestly, I don't know. I have switched to qbt "relatively recently", and so did my router.

I started noticing issues (namely https://github.com/qbittorrent/qBittorrent/issues/12208) and then I started poking around everything

[stdedos]

Also Transmission 2.9.4 is working correctly

[FranciscoPombal]

For me UPnP has always worked (as far back as the 3.3.x versions, I believe).

[arvidn]

@stdedos would you mind capturing transmission request too? just to narrow down what might be causing the internal error.

[stdedos]

upnp-transmission.pcapng.gz

[arvidn]

POST /upnp/control/WANIPConn1 HTTP/1.1
Host: 192.168.1.1:1900
User-Agent: Windows, UPnP/1.1, MiniUPnPc/1.9
Content-Length: 604
Content-Type: text/xml
SOAPAction: "urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping"
Connection: Close
Cache-Control: no-cache
Pragma: no-cache

<?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body>
<u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1">
<NewRemoteHost></NewRemoteHost>
<NewExternalPort>58512</NewExternalPort>
<NewProtocol>TCP</NewProtocol>
<NewInternalPort>58512</NewInternalPort>
<NewInternalClient>192.168.1.2</NewInternalClient>
<NewEnabled>1</NewEnabled>
<NewPortMappingDescription>Transmission at 58512</NewPortMappingDescription>
<NewLeaseDuration>0</NewLeaseDuration>
</u:AddPortMapping></s:Body></s:Envelope>

It almost seems transmission is using the windows service for UPnP

[iz8mbw]

But the description parameter is valorized in this case

[stdedos]

I am announcing that my store's customer support _most likely_ agreed to a refund/exchange - so, in a few hours, I will be having a new modem/router.

Hopefully all required diagnostics are collected - sadly, I won't be able to do verification 😕

_As expected, switching routers helped. GO ZyXEL 🥰_

[Mike-EE]

To provide another data point, I have an instance on a Win7/64 machine running v4.1.9.1 that can configure my router (a Linksys Orbi with the latest firmware) via uPNP, but the build above (installed on a Win10/64 machine) will not configure the same router.

I noticed the v4.2.5 installation (the one that will not configure the router via uPNP will only upload when downloading, and stops uploading when downloads are complete and that seems consistent with not having the port forwarded.

Let me know if I can provide any additional information.

[stdedos]

I noticed the v4.2.5 installation (the one that will not configure the router via uPNP will only upload when downloading, and stops uploading when downloads are complete and that seems consistent with not having the port forwarded.

Duplicate of https://github.com/qbittorrent/qBittorrent/issues/12208 aka https://github.com/qbittorrent/qBittorrent/issues/12781?

[Mike-EE]

I noticed the v4.2.5 installation (the one that will not configure the router via uPNP will only upload when downloading, and stops uploading when downloads are complete and that seems consistent with not having the port forwarded.

Duplicate of #12208 aka #12781?

I posted here specifically because of the similar failure message, but v4.2.5 does display the symptoms mentioned in the other issues.

[stdedos]

[...] but the build above (installed on a Win10/64 machine) will not configure the same router.

If indeed you are getting the same exact message (_and you did read the issue_), then a traffic capture would be nice.

I noticed the v4.2.5 installation (the one that will not configure the router via uPNP will only upload when downloading, and stops uploading when downloads are complete and that seems consistent with not having the port forwarded.

Duplicate of #12208 aka #12781?

I posted here specifically because of the similar failure message, but v4.2.5 does display the symptoms mentioned in the other issues.

I think this ^^ is getting mixed with the original purpose of this issue (like I was doing in the first place).

[Audionut]

I'm seeing the same issue. qBittorrent reports a good connection status but no port forwarded. I think I have actually seen qBittorrent reported in the router system forwarding log on occasion.

I downgraded to 4.2.1 which made no difference. (maybe kept to many settings?).
I tried changing the lease duration which made no difference.

Then I used the tool linked above from from here: http://miniupnp.free.fr/files/
Worked perfectly. Strange thing is that it seems to be using a duration=0 also.

external xxx.xxx.xxx.xxx:63328 TCP is redirected to internal 192.168.50.239:63328 (duration=0)

Found valid IGD : http://192.168.50.1:60776/ctl/IPConn
Local LAN ip address : 192.168.50.239
 i protocol exPort->inAddr:inPort description remoteHost leaseTime
 0 TCP 63328->192.168.50.239:63328 'libminiupnpc' '' 0

[stdedos]

For completeness, please attach pcap like me (see on the above comments how to do it).

The workaround is to downgrade <= 4.1.x, but be careful. Your fastresume (torrent status metadata) files will be void and need to be re-calculated.

[Audionut]

And recheck over 1500 torrents, some from a network, no thanks. Miniupnp worked fine.

I'm not interested in debugging an issue that the developer cares little about (probably why it's broken in the first place). I comment to assist others having the same issue.

[arvidn]

I'm not interested in debugging an issue that the developer cares little about (probably why it's broken in the first place)

That's rude and ungrateful. People spend a lot of their free time working on this. Not enough people probably.

[Audionut]

It is blunt, I will concede that.

If people want to commit to digging themselves out of their own opinion of upnp, and commit time to this issue, expect a return commitment from this end.

If people want to have a "meh" opinion of upnp and the bugs that have been created ((likely) because of the "meh" opinion of upnp), then those people should probably expect a little strong criticism, even if it is by a dumb end user with no contributions to the project.

I have this strong opinion exactly because of the work dedicated to this project. Because I respect the work that has gone into this project, but I don't respect the "meh" opinion, and I voiced such.

Cheers.

[FranciscoPombal]

Alright, I think it's safe to close this as "not an issue", as this was due to a router with a presumably faulty UPnP implementation (suspected to be so because the returned code is non-standard). Thank you for your contributions.

If you run into issues with the latest version (4.3.0, at the time of writing), please file a new issue report.