uPnP doesn't work on my Dlink DSL-2650U with qbittorent 3.1.9

[GoogleCodeExporter]

>What steps will reproduce the problem?
1. Run qBittorent 3.1.9
2. Set up the port and uPnP in settings
3. Check port on http://2ip.ru/check-port/?port=45124

>What is the expected output? What do you see instead?
Port must be open. Port is closed.

>What version of the product are you using? On what operating system?
qBittorent 3.1.9 and uTorrent 3.3 on Windows 7 x86 HB

1. Run uTorrent 3.3
2. Set up the port and uPnP in settings
3. Check port on http://2ip.ru/check-port/?port=45124

Port is open.

>Please provide any additional information below.

Wireshark's packet files for qBittorent and uTorrent.

http://yadi.sk/d/OdggujUIKAKuX

Original issue reported on code.google.com by abcdefgh...@gmail.com on 8 Mar 2014 at 2:34

[GoogleCodeExporter]

thanks for the wireshark dumps. that's very helpful.

The problem here is that libtorrent ignores the SSDP response. There are 
primarily two reasons for libtorrent to do this:

1. It believes the response is not coming from the edge of your local network. 
i.e. if none of your network card IPs, masked by their netmask compares equal 
to the source IP of the SSDP response masked by the netmask, then the response 
is ignored.

2. If session_settings::upnp_ignore_nonrouters is true (it defaults to false) 
and none of the default routes in the routing table has the SSDP response 
source IP as a target, the response is not believed to come from a relevant 
router.

It's probably most likely that you're affected by (1), since (2) shouldn't 
happen with the default settings. It's possible that there's some bug or error 
related to query the netmask and adapter IP. Perhaps this should be made to 
"fail open", i.e. just assume it's a correct response if something fails. Do 
you see any logging related to upnp? There should be alerts "portmap_log_alert" 
posted for upnp events. Could you please look for those in your qbittorrent log?

Original comment by arvid.no...@gmail.com on 9 Mar 2014 at 8:07

[GoogleCodeExporter]

ok, new theory:

qBitTorrent sets the "ignore upnp non-routers" and your network setup is such 
that your UPnP router somehow does not have the same address as your default 
route IP address. Is that the case? what address does your default route have?

Original comment by arvid.no...@gmail.com on 9 Mar 2014 at 9:12

[GoogleCodeExporter]

I must say that i probably have a buggy uPnP in my router because uPnP on first 
desktop computer sometimes working sometimes not but uTorrent working fine on 
both computer. On second computer(laptop) uPnP almost doesn't work only 
uTorrent 100% working fine.

Today i check transmission-qt 2.82 on first computer and port was opened but in 
qBittorent and tribler port was closed. On second computer port was 
closed(transmission).

If it's help i provide a network settings my computers
First computer:
IP 192.168.56.34
mask 255.255.255.0
gateway(router IP) 192.168.56.32
laptop:
IP 192.168.56.56
mask 255.255.255.0
gateway(router IP) 192.168.56.32

>Do you see any logging related to upnp?
Where i can find these logs? I check it in %APPDATA% but there is no log.
I add upnp log from utorrent 3.3 http://yadi.sk/d/OdggujUIKAKuX

Original comment by abcdefgh...@gmail.com on 9 Mar 2014 at 10:54

[GoogleCodeExporter]

I don't know if or where qbittorrent provides logs. However, your 
gateway/default route does match where the SSDO response came from. So it may 
be a bug where libtorrent fails to query the default route.

Original comment by arvid.no...@gmail.com on 9 Mar 2014 at 3:18

[GoogleCodeExporter]

Here's a preliminary patch: http://dpaste.com/hold/1708850/

What this does is that, if non-routers are ignored, but there is no unpn device 
at a router address, then the ignore is overridden and it's mapped anyway. 
Please test this. I'll ask sledgehammer99 to weigh in here and shed some light 
on where one may find the alert log (where the UPnP logs should go). Maybe we 
will even be able to make a test build.

This patch is kind of involved, and I'm not sure I'm comfortable to apply it to 
the 0.16.x branch. Either way, if this works, I'll put it in trunk, for the 1.0 
release.

Original comment by arvid.no...@gmail.com on 10 Mar 2014 at 1:26

[GoogleCodeExporter]

I'll provide a build but not in the next ~2 days. I am too busy with my real 
life job. Thank you for being patient.

Original comment by hammered...@gmail.com on 10 Mar 2014 at 9:43

[GoogleCodeExporter]

I applied the patch on the 0.16.x branch. svn patch didn't complain.
Here is a link to the patch build: 
http://builds.shiki.hu/temp/qbittorrent_3.1.9_20140315_patched_libtorrent_setup.
exe
qbt doesn't log all alerts. Just a few. Open the log via View->Execution Log

Original comment by hammered...@gmail.com on 15 Mar 2014 at 3:38

[GoogleCodeExporter]

I tested patched version of qbittorent and see no difference. Port was closed.
I should say that sometime ago port was open and qbittorent correctly share 
torrents.
I retested early version when it was opened(3.1.5, 3.1.8) and port still closed.
I add two screenshots and wireshark's dump of patched qbittorent 
http://yadi.sk/d/OdggujUIKAKuX

Today i test transmission-qt win64 2.82.1 and sometimes port was open. I don't 
get when and why it's somtimes open and sometimes closed. I think i have a 
buggy router and utorrent somehow workaround buggy uPnP. In wireshark's dumps 
utorrent correctly do the uPnP protocol.

Original comment by abcdefgh...@gmail.com on 17 Mar 2014 at 10:08

[GoogleCodeExporter]

ok, clearly my attempt at disabling "ignore-non-routers" when there isn't any 
device at the router failed. I would recommend doing what everyone else is 
doing and not set that setting in qbittorrent. i.e. 
session_settings::upnp_ignore_nonrouters

Original comment by arvid.no...@gmail.com on 17 Mar 2014 at 4:16

[GoogleCodeExporter]

either that, or enable the logging of portmap_log_alert. With that logging I 
may be able to figure out exactly why the ssdp response is ignored.

Original comment by arvid.no...@gmail.com on 17 Mar 2014 at 4:18

[GoogleCodeExporter]

I will test qbittorent with these settings if sledgehammer99 create a test 
build because i don't have compiling experience.

Original comment by abcdefgh...@gmail.com on 18 Mar 2014 at 4:45

[GoogleCodeExporter]

Here is a build with session_settings::upnp_ignore_nonrouters = false and 
logging portmap_log_alert: 
http://builds.shiki.hu/temp/qbittorrent_3.1.9_patched_20140322_setup.exe

@user A file named qbittorrent_portmap_log_alert.txt will be created on your 
desktop. This is the log for portmap_log_alert that arvid is requesting.

@arvid I didn't use your patch. Was I supposed to it now too?

Original comment by hammered...@gmail.com on 22 Mar 2014 at 10:55

[GoogleCodeExporter]

my patch tries to fix the "upnp_ignore_nonrouters = true" case. It failed to do 
so. To figure out why it failed, I would need the patch applied and logging 
enabled.

However, if you're happy with using the default setting, I'm confident that 
would also solve this problem (but it would introduce a less severe and 
probably less likely problem that chris experienced).

Original comment by arvid.no...@gmail.com on 22 Mar 2014 at 4:44

[GoogleCodeExporter]

I'll wait for the user to confirm that my build fixed it and then I'll upload a 
new patched version.

Original comment by hammered...@gmail.com on 22 Mar 2014 at 5:20

[GoogleCodeExporter]

I was test this build and port still closed.
I add a logs qbittorrent_portmap_log_alert.txt to http://yadi.sk/d/OdggujUIKAKuX
I have two different logs. On first load qbittorent i get a 
qbittorrent_portmap_log_alert_1.txt then some starts qbittorent later i get 
qbittorrent_portmap_log_alert_2.txt

If qbittorrent_portmap_log_alert_1.txt then qbittorent execution log don't have 
"uPnP/NAT-PMP: port maping successful, message: successfully maped port used 
uPnP"

The logs have some russian strings. I tried to change language in settings 
qbittorent to english but some russian string still apear in logs.
One string is truncated - Операция ввода/вывода была 
прервана из-за <truncated>зав?</truncated>

Original comment by abcdefgh...@gmail.com on 23 Mar 2014 at 1:21

[GoogleCodeExporter]

Does that error message indicate the operation was aborted by the libtorrent 
side?

The second log looks like everything worked. they come from the same build, 
just run at different times?

the truncated error message is probably my fault. I'll fix that.

Original comment by arvid.no...@gmail.com on 23 Mar 2014 at 7:55

[GoogleCodeExporter]

>Does that error message indicate the operation was aborted by the libtorrent 
side?
It's mean: "Operation in/out was aborted by". I don't know libtorrent is it or 
not.

>they come from the same build, just run at different times?
Yes. Sometimes in qbittorent execution log port was opened and sometimes was 
closed.
I add wireshark's dump to http://yadi.sk/d/OdggujUIKAKuX when in execution log 
port is open.

>The second log looks like everything worked.
But port on my machine still closed.

Original comment by abcdefgh...@gmail.com on 24 Mar 2014 at 10:40

[GoogleCodeExporter]

I don't know if it help but qbittorrent_portmap_log_alert_2.txt have another 
truncated string.

<?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:AddPortMa
pping 
xmlns:u="urn:schemas-upnp-org:service:WANPPPConnection:1"><NewRemoteHost></NewRe
moteHost><NewExternalPort>11111</NewExternalPort><NewProtocol>TCP</NewProtocol>[
TRUNCATED]<NewInte[/TRUNCATED]
UPnP: map response: <?xml version="1.0"?>

Original comment by abcdefgh...@gmail.com on 24 Mar 2014 at 10:59

[GoogleCodeExporter]

Also in my router you must twice or more times retry to connect to link 
http://192.168.56.32:5431/dyndev/uuid:0000e008-20a0-00e0-b0a0-4878005808e0
I think it will explain why sometimes in execution log port open and sometimes 
port closed. 

Original comment by abcdefgh...@gmail.com on 24 Mar 2014 at 11:07

[GoogleCodeExporter]

>Also in my router you must twice or more times retry to connect to link 
http://192.168.56.32:5431/dyndev/uuid:0000e008-20a0-00e0-b0a0-4878005808e0

I mean: connect first time then stop then delay 1s then again connect.
I check that in browser.

Original comment by abcdefgh...@gmail.com on 24 Mar 2014 at 11:21

[GoogleCodeExporter]

I tried applying the patch on r9837 but it doesn't apply cleanly...
Btw, can you try this java app? -> http://upnp-portmapper.sourceforge.net/
upnp from libtorrent also fails on my pc but this application does upnp 
successfully on the same pc.
(I created a bug but failed to follow through with the tests ....)

Original comment by hammered...@gmail.com on 24 Mar 2014 at 1:27

[GoogleCodeExporter]

I tied that application and port was closed if i do all correctly ofcourse. So 
perhaps i have a buggy router?
Also i found that qbittorent doesn't corretly set TCP port. See screenshot 
"When qBittorent run PortMapper 1.9.5.png"

Original comment by abcdefgh...@gmail.com on 28 Mar 2014 at 7:37

[GoogleCodeExporter]

I check qbittorent 3.0.9 and transmission 2.82 and deluge 1.3.6 in altlinux 
7.0.4 x64 centaurus. Port was open. Also i check portmapper - port was closed.

Original comment by abcdefgh...@gmail.com on 28 Mar 2014 at 8:45

[GoogleCodeExporter]

I retest qBittorent 3.0.9 in linux and port now closed.

Original comment by abcdefgh...@gmail.com on 28 Mar 2014 at 9:15

[GoogleCodeExporter]

I have the same problem on my Linksys e2500 (3.0.00 build 6) + qbittorrent 
3.1.11
After some investigation and some comparison with other clients that worked I 
saw that the issue is because libtorrent is using HTTP 1.0 (and not HTTP 1.1) 
for POST messages.
This is the line where the POST is constructed: 
https://github.com/libtorrent/libtorrent/blob/d11376bbe3bae1d620bfba7f2d0d319bca
556c90/src/upnp.cpp#L569

I assume that by router is using pupnp library and there was an issue on the 
project to also accept HTTP 1.0 requests. 
http://sourceforge.net/p/pupnp/mailman/message/21019135/
In summary: for some reason the UPNP test tool doesn't accept http 1.0, even 
though it is against the HTTP 1.1 specs. :?

This is a HTTP 1.1 request with fiddler: http://pastebin.com/BtiJhm6X
This is a HTTP 1.0 request with fiddler: http://pastebin.com/xhF4452U

Is there a specific reason for using HTTP 1.0 in libtorrent?
Is it ok if we change the POST from upnp.cpp#L569 to HTTP 1.1 ?

--Stefan

Original comment by sst...@gmail.com on 26 Dec 2014 at 5:09

[GoogleCodeExporter]

One more thing. I've made a manual patch to my qbitorrent binary and it works :)
If somebody also whats to try it: Open the binary (i.e. qbittorrent.exe on 
windows) with your favorite hex editor (e.g. HxD, VS, ...) search for 
"HTTP/1.0" and replace it with "HTTP/1.1". This should work for other apps that 
use libtorrent.

Original comment by sst...@gmail.com on 26 Dec 2014 at 5:42

[GoogleCodeExporter]

looking back on the commit history, it appears the switch from HTTP 1.1 to 1.0 
was made to prevent the UPnP device to respond with chunked encoding (because 
that wasn't supported by my http connection at the time).

Assuming that was the only reason, I could try to switch it back to HTTP 1.1 to 
see if that solves your problem. However, I'm a little bit worried that another 
reason to switch might have been because some other UPnP device didn't like 1.1.

Original comment by arvid.no...@gmail.com on 27 Dec 2014 at 7:40

[GoogleCodeExporter]

fixed in RC_1_0 and RC_0_16

Original comment by arvid.no...@gmail.com on 27 Dec 2014 at 7:54

• Changed state: Fixed

[GoogleCodeExporter]

Cool thanks. I am really not sure what is the best practical solution on the 
long term. If the 1.1 request created compatibility issues with other routers, 
I am think about an ugly retry mechanism, something like: check with HTTP 1.0 
and then try 1.1 if 1.0 fails.

Looking at the pupnp commit history:
 - 1.1 enforcement was added in 2010: https://github.com/mrjimenez/pupnp/commit/03c858af5123295e5591cc824b77f39bfde5102e
 - and then reverted in 2012: https://github.com/mrjimenez/pupnp/commit/cf0f53bb63bf95c2f4d1de218a39941d3e48e971

Thanks for making a patch. I hope this will play nicely with all routers :)

Original comment by sst...@gmail.com on 27 Dec 2014 at 9:14