search

ericmckean / libtorrent

Automatically exported from code.google.com/p/libtorrent
0 stars 0 forks source link

libtorrent does not delete UPnP on session deletion #66

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Start a session
2. Start UPnP
3. delete the session

What is the expected output? What do you see instead?
The UPnP mapping should be deleted on the router. Instead, the mapping is 
still there.

What version of the product are you using? On what operating system?
v0.14.10 and v0.15

Please provide any additional information below.
I have tried to call stop_upnp() explicitely in my destructor but it did 
not help.

Original issue reported on code.google.com by dch...@gmail.com on 17 May 2010 at 10:19

GoogleCodeExporter commented 9 years ago 
Could you provide a wireshark dump of the upnp traffic?

Original comment by arvid.no...@gmail.com on 19 May 2010 at 12:04

GoogleCodeExporter commented 9 years ago 

Hello,

Here is my view on UPnP Port Forwarding with different Linux torrent clients.
1) Transmission doesn't open/close ports on its own at all
  but it can check if port is open or not (pressing "Check" button)
2) KTorrent opens ports and (my guess) closes it as well.
  it doesn't have UI to check if port open or not
3) I not managed to get qTorrent opening specified port

Extract from Log file of UPnP plugin in Azureus 4.4.0.4
(completed log is attached)
...
[17:21:27]     3Com Wireless 11n Cable/DSL Firewall Router(WAN Con) *
[17:21:27]      
urn:schemas-upnp-org:service:WANEthernetLinkConfig:1:desc=http://192.168.1.1:80/
igd_wec.xml,
control=http://192.168.1.1:80/upnp/control?WANEthernetLinkConfig
[17:21:27]      
urn:schemas-upnp-org:service:WANPPPConnection:1:desc=http://192.168.1.1:80/igd_w
pc.xml,
control=http://192.168.1.1:80/upnp/control?WANPPPConnection
[17:21:27]      
urn:schemas-upnp-org:service:WANIPConnection:1:desc=http://192.168.1.1:80/igd_wi
c.xml, control=http://192.168.1.1:80/upnp/control?WANIPConnection
[17:21:27]     Found WANPPPConnection
[17:21:27]   Downloading: http://192.168.1.1:80/igd_wpc.xml
[17:21:28]       mapping [0] 30493/UDP [Azureus UPnP 30493 UDP] -> 192.168.1.30
[17:21:28]       mapping [1] 30493/TCP [Azureus UPnP 30493 TCP] -> 192.168.1.30
[17:21:28]       mapping [2] 6881/TCP [KTorrent UPNP 4] -> 192.168.1.50
[17:21:28]       mapping [3] 6881/UDP [KTorrent UPNP 7] -> 192.168.1.50

I can download from router and provide igd_wec.xml, igd_wpc.xml, igd_wic.xml.
It's rather easy to understand from those xml files which UPnP "commands" are
available form router.
I don't know though how to execute UPnP commands manually (say, from Linux 
command
line or some GUI interface)
If you can give tip how to do it, I can test further available clients.

Original comment by v.ples...@gmail.com on 19 May 2010 at 6:17

Attachments:

GoogleCodeExporter commented 9 years ago 

Here is screenshot of KTorrent with port 6881 opened (default port in KTorrent, 
no
manual changes)
Ktorrent ver. 3.3.4 from OpenSUSE 11.3 Factory, KDE 4.4.2
Router:  3Com Wireless 11n Cable/DSL Firewall Router
http://www.3com.com/products/en_US/detail.jsp?tab=features&pathtype=purchase&sku
=3CRWER300-73

Pls also note that KTorrent 3.2.4 / KDE 4.3.3 was not able to open ports.
That has been tested on *stable* (production) Fedora 10
At a moment I can't upgrade system to newer version on that PC.

Original comment by v.ples...@gmail.com on 19 May 2010 at 6:30

Attachments:

GoogleCodeExporter commented 9 years ago 
In order to debug or troubleshoot what libtorrent does, I need to see what it 
does (and more importantly what 
your router responds with). Seeing what other clients do doesn't provide any 
pertinent information.

Original comment by arvid.no...@gmail.com on 19 May 2010 at 10:36

GoogleCodeExporter commented 9 years ago 
Arvid,
I would be happy to provide debug info and troubleshoot possible problems.
Question is how to get that debug info or log output.
Is it possible to enable logging somehow, or may be log file exists but I am not
aware of it?
I use stock OpenSUSE 11.3 Factory packages.

I believe KTorrent also uses libtorrent, so if UPnP works with Ktorrent, it 
should
also work with other clients.

Same is valid for qBittorrent.
Chris, does it make separate log file which can be analyzed after all?

Original comment by v.ples...@gmail.com on 20 May 2010 at 7:17

GoogleCodeExporter commented 9 years ago 

There is a testing program in Ktorrent rpm - ktupnptest.

I tested it with my router (3Com WER300).
It correctly found router.
See attached file - screenshot for search dialog and verbose output in txt log 
file.

Than I entered port number 45000 and selected Forward port.
Everything was ok. See output attached and UPnP from Vuze running on another 
machine.

Than selected Undo Port Forwarding.
There is an error at the end of file.
BUT:  Port Forwarding mapping on router has been deleted, as you can see from
continued Log from Vuze client.

Original comment by v.ples...@gmail.com on 20 May 2010 at 9:42

Attachments:

GoogleCodeExporter commented 9 years ago 
I compiling libtorrent-rasterbar with upnp debug. I will report back when I get 
home.

Original comment by dch...@gmail.com on 21 May 2010 at 12:16

GoogleCodeExporter commented 9 years ago 
KTorrent does not use libtorrent.

The most complete log would be a wireshark log.

Original comment by arvid.no...@gmail.com on 22 May 2010 at 2:34

GoogleCodeExporter commented 9 years ago 
Here is the wireshark log.

For your information, 192.168.1.1 is my router (Internet Gateway). 
192.168.1.254 is 
my WLAN AP which I do not use as a router. 

From what I can see, libtorrent maps the port on 192.168.1.254 although it is 
not my 
router. It is odd because I'm using "sessionSettings.upnp_ignore_nonrouters = 
true;".
The mapping is not deleted on exit on 192.168.1.254

Regarding my actual router (192.168.1.1), its Web UI only shows that UPnP is 
enabled 
but it does not show UPnP mappings. As a consequence, I cannot check if 
mapping/unmapping works on this one.

PS: My laptop IP is 192.168.1.2

Original comment by dch...@gmail.com on 22 May 2010 at 11:23

Attachments:

GoogleCodeExporter commented 9 years ago 
Note that I used this filter in wireshark: "udp.dstport == 1900". This is what 
I found 
when googling. It seemed to work fine.

Original comment by dch...@gmail.com on 22 May 2010 at 11:25

GoogleCodeExporter commented 9 years ago 
Here is the output if I comment:
// sessionSettings.upnp_ignore_nonrouters = true;

I don't see any visible difference, mapping is still not deleted.

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     *               255.255.255.0   U     2      0        0 wlan0
link-local      *               255.255.0.0     U     1000   0        0 wlan0
default         192.168.1.1     0.0.0.0         UG    0      0        0 wlan0

Original comment by dch...@gmail.com on 22 May 2010 at 11:36

Attachments:

GoogleCodeExporter commented 9 years ago 
Here is Wireshark capture for following usage scenario:
- start KTUPnP test  application
- search for router(s)
- open port 45000
- close port 45000

IP of machine which was used or test: 192.168.1.50
Router: 192.168.1.1
Another machine (192.168.1.30) is running Vuze/Azureus, and it is periodically 
polls
router on setup changes.
I also used it to monitor Forwarded Ports mappings after opening port 45000 and 
later
closing it.
Log file from Vuze UPnP plugin confirmed that port was opened and later closed.
To get update in Log file, I used Rescan button, which enforced 
discovery/polling
packets being sent from 192.168.1.30

P.S. Port 6881 remained open on router, despite I exited from KTorrent before 
running
test.
So, it seems that Ktorrent also have some problems deleting mappings on router 
after
closing all connection/program itself.

Original comment by v.ples...@gmail.com on 22 May 2010 at 9:19

Attachments:

GoogleCodeExporter commented 9 years ago 
And here is Wireshark capture for the same configuration of network, but with
qBittorrent instead of KTorrent.

Port selected to be forwarded (open) - 23484.
Test machine IP - 192.168.1.50

qBittorrent DOES NOT OPEN requested port.
It is confirmed by monitoring log from machine 192.168.1.30

As you can see from previous (Ktorrent) cap file, port mapping for port 45000 
has
been added in packet 328 (HTTP/XML - POST /upnp/control?WANIPConnection HTTP 
1.1)
 <NewExternalPort> 45000 </ NewExternalPort>

It's interesting that in qBittorrent capture there is a similar packet (#372)
(HTTP/XML - POST /upnp/control?WANIPConnection HTTP 1.0)

I don't know why it doesn't work for qBittorrent.
May be it's difference between HTTP 1.0 and HTTP 1.1?
Not sure here.

Original comment by v.ples...@gmail.com on 22 May 2010 at 9:51

Attachments:

GoogleCodeExporter commented 9 years ago 
It seems two .cap files attached to two previous messages were damaged during 
ftp
transfer from one computer to another.
I now copied them via USB flash and send again.

Original comment by v.ples...@gmail.com on 23 May 2010 at 3:28

Attachments:

GoogleCodeExporter commented 9 years ago 
Installed Wireshark on Windows PC and captured packets from Bittorrent 6.4 
starting
session (I stopped seeding all files, and reloaded it)
Bittorent was mapping/forwarding port 18516.
I stopped capture when *green* light on status bar appeared ("network is ok")

It seems the way it handles UPnP device (Internet Gateway/Router) is quite 
different
from KTorrent and libtorrent/qBittorrent.

Check for example packet 106:
---------------
SUBSCRIBE /upnp/event?WANEthernetLinkConfig HTTP/1.1
NT: upnp:event\r\n
Callback: <http://192.168.1.30:2869/upnp/eventing/xircqucqec>
Timeout: Second-1800
Host: 192.168.1.1

It seems client (192.168.1.30) subscribes to UPnP events for 
WANEthernetLinkConfig

Packet 148:
---------------
SUBSCRIBE /upnp/event?WANPPPConnection HTTP/1.1
NT: upnp:event\r\n
Callback: <http://192.168.1.30:2869/upnp/eventing/egrdteesxl>\r\n
Timeout: Second-1800\r\n
User-Agent: Mozilla/4.0 (compatible; UPnP/1.0; Windows 9x)
192.168.1.1

Hope this information would be useful.

Original comment by v.ples...@gmail.com on 23 May 2010 at 3:49

Attachments:

GoogleCodeExporter commented 9 years ago 

Found an easy way to strip unnecessary packets (on .cap files attached above) 
to get
info what actions on UPnP router were effected.
Apply as filter in Wireshark: xml.tag == "<SOAP-ENV:Body>"

Results are attached as screenshots for KTorrent and Bittorrent 6.4/Windows.
There are no such packets in qBittorrent (libtorrent) capture.

Original comment by v.ples...@gmail.com on 23 May 2010 at 5:18

Attachments:

GoogleCodeExporter commented 9 years ago 

Capture for Bittorrent - unmapping of mapped ports on exit.

Ports were unmapped, response from router OK.
Full XML conversation is viewable using 'xml' filter
(you will see responses from server/router in  addition to config commands)

Original comment by v.ples...@gmail.com on 23 May 2010 at 5:39

Attachments:

GoogleCodeExporter commented 9 years ago 
Capture for Start/Stop of Azureus 4.4.0.4
Communication with router is also done via XML, WANPPPConnection has been
successfully unmapped, WANIPConnection returned error "NoSuchEntryInArray"

Original comment by v.ples...@gmail.com on 23 May 2010 at 6:05

Attachments:

GoogleCodeExporter commented 9 years ago 
The router exposes two interfaces, WanPPPConnection and WanIPConnection. 
Apparently KTorrent choses to use 
the former and libtorrent prefers the latter. This could be the reason, that 
the router only supports the PPP 
version. Another difference, as you point out, could be that it doesn't support 
HTTP 1.0.

Neither of these are trivial to fix, since they require libtorrent to retry 
with the other version.

Original comment by arvid.no...@gmail.com on 23 May 2010 at 9:06

GoogleCodeExporter commented 9 years ago 
The symptom here is that the port doesn't get mapped though, which is different 
from the title of this ticket.

Also, I would suggest you send that capture file to 3Com as well, so they can 
fix their bug.

Original comment by arvid.no...@gmail.com on 23 May 2010 at 9:08

GoogleCodeExporter commented 9 years ago 
Re: "The router exposes two interfaces, WanPPPConnection and WanIPConnection.
Apparently KTorrent choses to use 
the former and libtorrent prefers the latter"

PPP connection established when router makes PPPoE connection (authenticates on
provider's gateway, and account status ok). As soon as connection established, 
all
Internet traffic goes via PPPoE.
IP connection is for static external IP address.
If I decide work only in provider's network (provider's LAN), I can assign 
static IP
address given to me to router's external (WAN) interface.
But I rarely use this scenario.

Besides, KTorrent maps port for both WanIP and PPP connections (TCP+UDP).
Pls check screenshot attached to comment #3 above.
And it's logical - Torrent client sees that there are 2 external WAN interfaces.
It doesn't know which is used / should be used.
And to be on a safe side, it maps same port number for both WAN interfaces.
And late runmaps port for both WanIP and WanPPP.
While WanPPP unmaps ok, there is a problem with WanIP port unmapping for 
KTorrent and
Azureus. Bttorrent 6.4 uses only WanPPP.
Router returns errors "No Such Entry in Array" and "Specified array index 
invalid".
So this can be a router's problem.

Original comment by v.ples...@gmail.com on 24 May 2010 at 11:50

GoogleCodeExporter commented 9 years ago 
regarding comment #19:

Would it be possible
1) map ports for both WanIP and WanPPP connections?
 in case soem provider uses PPTP - second connection would be probably called WanPPTP.
2) use HTTP 1.1?  And if this doesn't work - HTTP 1.0
 Out of several HTTP clients I tested, only qBittorrent was using HTTP 1.0 for POST
UPnP control commands.
Bittorrent, uTorrent, Azureus/Vuze, Ktorrent are using HTTP 1.1 for POST UPnP 
commands.
I don't know what standard is saying (and if it exists), but using method which 
works
for other clients/libraries may fix this problem.

Original comment by v.ples...@gmail.com on 24 May 2010 at 12:02

GoogleCodeExporter commented 9 years ago 

GUPnP-tools package can help to trim this problem.

urn:upnp-org:serviceId:L3Forwarding1
Invoke action GetDefaultConnectionService

Output:
00000000-0000-0001-0001-001ec1a1eb00:WANConnectionDevice:1,urn:upnp-org:serviceI
d:WANPPPConn1

So client can learn after discovering UPnP-enabled router which WAN connection 
is
active (default).
Than ports can be mapped only for this connection.

Client probably should subscribe to "Connection changes" event.
If connection is broken/chenged, than old mappings may need to be deleted, and 
new
mappings added.

Original comment by v.ples...@gmail.com on 24 May 2010 at 1:10

Attachments:

GoogleCodeExporter commented 9 years ago 
Returning to ticket's subject: "libtorrent does not delete UPnP on session 
deletion"

I installed second router in my network (IP 192.168.1.2), it is ASUS WL-500G 
Premium
v1 with DD-Wrt firmware - http://www.dd-wrt.com/site/index
Firmware version DD-WRT v24-sp2 (10/10/09) mega (SVN revision 13064)

DD-Wrt has nice feature - it can show mapped ports in real time via web 
interface
(NAT /QOS -> UPnP tab)

First I add port forwarding for port 4000 using ktupnptest.
Than deleted it. DDWrt first showed added port (see screenshot), than deleted 
it from
list.

Than I started qBittorrent. I saw two ports added (mapped) in Web UI.
Exited from qBittorrent.  Both mappings (TCP and UDP) are still mapped on 
router.
So, problem reported by Chris is indeed here.

Traffic between Linux machine (KTorrent, qBittorrent) is difficult to analyze.
I don't see XML packets between 192.1.68.1.50 and 192.168.1.2 (DD-Wrt router)
But there are many packets 'dpkeyserv (1780)'  which it seems encapsulate some 
HTTP
and XML inside.
Any tip how to decode this would be appreciated. :-)

It's interesting that log file from Vuze confirms that qBittorent mapped port 
23484
(TCP, UDP) on DD-Wrt router. But NOT on 3Com 11n router.
Azureus mapped itself both on DD-Wrt and 3Com 11n router.

Original comment by v.ples...@gmail.com on 24 May 2010 at 5:48

Attachments:

GoogleCodeExporter commented 9 years ago 
"upnp::close"  trying to calls "upnp::update_map",  which creates 
"http_connection" to notify router to remove mapping.  So if you call 
"session.stop_upnp" during ordinal application loop - it will deliver 
notification without problem.

But inside "session_impl" destruction (which calls 
"session_impl::abort()"->"m_upnp->close()") - all "http_connection" can't be 
done at all. Current behaviour raises two problems (svn trunk4833 + vs2008): 
1) creation of http_connection during  session_impl destruction cause noticable 
session destruction delay (asio waits for connection timeout)
2) router did not receive port update notification

My own temporary workaround for 1) is to skip "update_map" call inside 
"upnp::close" if it was called during "session_imp" destruction routine. But 2) 
issue still opened - so it would be great if "upnp::close" be called inside 
session destructor AND at time where http requests could be delivered.

Original comment by ajax16...@gmail.com on 24 Sep 2010 at 9:52

GoogleCodeExporter commented 9 years ago 
Thanks for this analysis. I'll try to extend the unit test to cover this and 
fix it.

Original comment by arvid.no...@gmail.com on 27 Sep 2010 at 2:10

GoogleCodeExporter commented 9 years ago 
I've been able to reproduce this problem and it appears this simple patch fixes 
it!

Please give it a try and confirm whether or not it works for you.

Index: src/connection_queue.cpp
===================================================================
--- src/connection_queue.cpp    (revision 4855)
+++ src/connection_queue.cpp    (working copy)
@@ -179,7 +179,8 @@
 #ifdef TORRENT_CONNECTION_LOGGING
        m_log << log_time() << " " << free_slots() << std::endl;
 #endif
-       if (m_abort) return;
+       // if this is enabled, UPnP connections will be blocked when shutting down
+//     if (m_abort) return;

        if (m_num_connecting >= m_half_open_limit
            && m_half_open_limit > 0) return;

Original comment by arvid.no...@gmail.com on 30 Sep 2010 at 8:55

GoogleCodeExporter commented 9 years ago 
in fact, I feel confident enough that I'll check it in and close this ticket as 
fixed. Please re-open it if it still doesn't work.

Original comment by arvid.no...@gmail.com on 30 Sep 2010 at 8:57

GoogleCodeExporter commented 9 years ago 
It still doesn't work... :-(
I looked sources of the version installed in my system (0.15.9) and I found 
this patch was applied. But when I try to run/close Deluge ports (TCP and UDP) 
stays opened on my router (Linux-powered PC) while the same thing works fine 
with uTorrent client (running on another computer under Windows).

Original comment by s.rous...@gmail.com on 19 Jan 2012 at 10:04

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
But I don't know how to re-open this ticket...

Original comment by s.rous...@gmail.com on 19 Jan 2012 at 10:06

GoogleCodeExporter commented 9 years ago 
Is there any chance you could build libtorrent with upnp logging and provide 
the log? or maybe wireshark dumps?

Original comment by arvid.no...@gmail.com on 19 Jan 2012 at 5:44

GoogleCodeExporter commented 9 years ago 
I can confirm that this still doesn't work. After closing Deluge, UPnP forwards 
are still left open.

Original comment by nickbr...@gmail.com on 19 Jan 2012 at 8:16

GoogleCodeExporter commented 9 years ago 
I can to do both things. What will better one?

Original comment by s.rous...@gmail.com on 25 Jan 2012 at 7:00

GoogleCodeExporter commented 9 years ago 
Using libtorrent-rasterbar6 0.15.7-1 and python-libtorrent 0.15.7-1 with Deluge 
1.3.3-1ubuntu1 I experience the same problem. 

UPnP forwards are left open after Deluge is closed, until the router closes 
them.

Original comment by johnr67...@gmail.com on 4 Apr 2012 at 1:43