Open GoogleCodeExporter opened 8 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
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:
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:
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
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
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:
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
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
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:
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
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:
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
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
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:
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:
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:
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:
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:
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
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
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
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
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:
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:
"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
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
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
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
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
[deleted comment]
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
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
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
I can to do both things. What will better one?
Original comment by s.rous...@gmail.com
on 25 Jan 2012 at 7:00
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
Original issue reported on code.google.com by
dch...@gmail.com
on 17 May 2010 at 10:19