No connection to UDP tracker through SOCKS5 proxy

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Set up a jail in FreeBSD 9.2-Release amd64
2. portmaster net-p2p/deluge
3. run deluge, setup SOCKS5 proxy and add a torrent through magnet link

What is the expected output? What do you see instead?
Expected: establish connection to upd tracker. Instead: no connection

What version of the product are you using? On what operating system?
libtorrent 0.16.13.0

Please provide any additional information below.
This issue was marked as fixed here: 
https://code.google.com/p/libtorrent/issues/detail?id=439&can=1&q=proxy 
however, using deluge 1.3.6 and libtorrent 0.16.13.0 I still get this issue.

Original issue reported on code.google.com by Stefa...@gmail.com on 20 Jan 2014 at 8:05

[GoogleCodeExporter]

deluged: 1.3.6
libtorrent: 0.16.11.0

Initial connections succeed, then after initial torrents are finished, any 
subsequent torrents added via magnet links aren't able to download metadata.

I get a bunch of these in tcpdump while a torrent is sitting in the queue, 
unable to download:

10:55:22.685710 IP 10.1.1.18.49412 > 109.201.152.231.55095: UDP, length 111
10:55:22.795199 IP 109.201.152.231 > 10.1.1.18: ICMP 109.201.152.231 udp port 
55095 unreachable, length 147

I am not familiar with socks proxy internals, but maybe port 55095 was assigned 
to me, then expired during idle, and libtorrent isn't requesting a new port? 
That's why a restart works.  Just a guess.

What steps will reproduce the problem?
1. Fresh install of Ubuntu server 13.10 (saucy)
2. install deluge from repo
3. run deluge, setup SOCKS5 proxy and add a torrent through magnet link
4. after first torrent finishes, add another torrent through magnet link
5. unable to download metadata

Original comment by dan.latu...@gmail.com on 26 Jan 2014 at 4:58

[GoogleCodeExporter]

the way udp associate works is by opening a TCP connection which creates the 
association. iirc, the association is supposed to exist for the duration of 
this TCP connection. If the socks server wants to time it out, it should also 
close the TCP connection that opened it, to communicate that it's gone. This 
would trigger libtorrent to re-open it.

Original comment by arvid.no...@gmail.com on 26 Jan 2014 at 5:35

[GoogleCodeExporter]

could you post a wireshark log where this fails? if it works for a while first, 
please include that too. That way I may be able to find the place where it 
breaks and figure out what's going on.

Original comment by arvid.no...@gmail.com on 26 Jan 2014 at 5:36

[GoogleCodeExporter]

Sorry, I can't post a full pcap file, but it looks like the connection issue 
has nothing to do with the subsequently added torrents after the first one 
finishes.  It starts getting those ICMP udp port unreachable responses right as 
the first torrent is finishing.

I am seeing my machine sending a TCP FIN packet approx 100ms before it starts 
getting the ICMPs.  Could libtorrent be disconnecting the tcp connection for 
some reason just before the torrent finishes?

Original comment by dan.latu...@gmail.com on 26 Jan 2014 at 9:13

[GoogleCodeExporter]

libtorrent is supposed to only close the connection when shutting down or 
changing the proxy settings. looking through the code, it should also re-open 
and re-issue the udp associate command if the connection is closed by the other 
side.

Original comment by arvid.no...@gmail.com on 26 Jan 2014 at 10:31

[GoogleCodeExporter]

After a bit more digging, I see a TCP connection being established to the socks 
server, logging in, and then starts sending UDP packets.  After some time, I 
see a TCP packet from the same source port on my side getting sent with a FIN 
flag, a FIN, ACK from the server, etc for shutting down the TCP connection.  
That's when the ICMP udp port unreachable errors start happening.

Can you suggest anything else to help figure out where the issue is?

Original comment by dan.latu...@gmail.com on 30 Jan 2014 at 3:09

[GoogleCodeExporter]

interesting. here's what I can think of (and I realize this might be getting a 
bit deep into debugging, I should try to reproduce this myself):

build libtorrent in debug mode.

set breakpoints in libtorrent::udp_socket::hung_up(). This is the last thing 
that should be called after we initiate a closing of the connection, hopefully 
we can catch it sooner. 

set a breakpoint in libtorrent::udp_socket::close() If this is called, capture 
the callstack to see where it's called from and potentially why.

set a breakpoint in libtorrent::udp_socket::set_proxy_settings() this will 
close the socks5 connection, but if the proxy settings still are to use socks5, 
it should be re-established again immediately. If this is hit after the initial 
setup, capture its callstack too, to see where it's being called from and 
potentially why.

set a breakpoint in libtorrent::udp_socket::on_timeout(), this is only supposed 
to be called in case the sock5 TCP connection establishment takes longer than 
10 seconds. Once established it should never be called. If it is, capture 
callstack and potentially why it's being called.

Is the time from the connection establishment to the FIN consistent? If it 
seems to be close to 10 seconds it could be the case that the connect timeout 
is broken and always reports a timeout.

Original comment by arvid.no...@gmail.com on 30 Jan 2014 at 10:26

[GoogleCodeExporter]

Is there a fix or workaround for this?  I have been trying to get this to work, 
im having the same problem and its driving me nuts

Original comment by MattKlim...@gmail.com on 20 Mar 2014 at 8:18

[GoogleCodeExporter]

please provide a wireshark dump of the communication with the socks5 server.
have you confirmed that your socks5 server supports UDP?

Original comment by arvid.no...@gmail.com on 20 Mar 2014 at 8:59

[GoogleCodeExporter]

My workaround has been to bounce my torrent client (deluged) when it gets 
"stuck" and that seems to get things moving along.  I haven't had time to do 
the debugging as suggested. 

Original comment by dan.latu...@gmail.com on 20 Mar 2014 at 12:01

[GoogleCodeExporter]

libtorrent 0.16.16
deluge/deluged 1.3.6
ubuntu 14.04

same issue for me. using a socks5 proxy with deluge; flexget will populate 
deluge with a torrent, and nothing much happens. stop/starting deluged brings 
the torrent back and it immediately starts populating peers/sources/etc. at 
present, i've got deluged restarting itself every few hours via cron, but it's 
not really a solution.

please advise what info i can provide to help solve, commands to run, etc.

Original comment by hoho...@gmail.com on 27 May 2014 at 12:43

[GoogleCodeExporter]

A user of qbittorrent has similar problems. He pointed here and I asked him to 
provide a wireshark dump to you. However, as you can see in the linked bug he 
says that during the dump and after a while the udp trackers started to work.

Also he has another problem. Libtorrent doesn't seem to be able to resolve the 
proxy name so he enters an IP directly in the proxy settings.

qbittorrent issue: 
https://github.com/qbittorrent/qBittorrent/issues/1716#issuecomment-44894210

Original comment by hammered...@gmail.com on 2 Jun 2014 at 9:37

[GoogleCodeExporter]

Ignore the DNS problem. It's cause was found. (his ISP blocks that hostname)

Original comment by hammered...@gmail.com on 2 Jun 2014 at 9:43

[GoogleCodeExporter]

hopefully this will help.

libtorrent 0.16.16, deluge 1.3.6, ubuntu 14.04.  using 
privateinternetaccess.com socks5 proxy with auth, socks host is 
'proxy-nl.privateinternetaccess.com', port 1080 (multiple IP addresses for the 
host).

attempt a ubuntu torrent from piratebay: 
https://thepiratebay.se/torrent/9982925/Ubuntu_14.04_64_bit -- this starts up 
quickly and works as expected.

attempt a different torrent from piratebay: 
https://thepiratebay.se/torrent/10280036/Silicon_Valley_S01E08_HDTV_x264-KILLERS
_[eztv] -- this hangs/does nothing. restarting deluge makes it find sources and 
begin downloading as expected.

i ran wireshark (tshark) with no filters/etc. not sure what you guys need to 
see; if there's a specific incantation you want me to run, let me know.

success: http://pastebin.com/i52qY8Az
failure: http://pastebin.com/r3WrtcEV

my internal lan IP for the ubuntu machine is 192.168.1.64. my client machine 
(connected via SSH) is 192.168.1.155. 

tracker list for both torrents appears to be the same, all UDP trackers.

Original comment by hoho...@gmail.com on 3 Jun 2014 at 4:58