Proxy IP changes aren't picked up

[GoogleCodeExporter]

This is a report from a qbt user. He uses Xubuntu 14.04 and btguard as proxy.

I think Ubuntu 14.04 uses libtorrent 0.16.13

Sometimes BTguard changes its IP and every transfer gets stalled and stuck and 
dht drops to 0. This problem is fixed if the user just re-applies the same 
settings.

My hunch is that libtorrent doesn't re-resolve the proxy and uses the initial 
IP forever.

Forum thread: http://qbforums.shiki.hu/index.php/topic,2561.msg10866.html

Original issue reported on code.google.com by hammered...@gmail.com on 4 May 2014 at 3:55

[GoogleCodeExporter]

Hi Arvid, I am experiencing this problem as well. I am using Windows 
qbittorrent 3.2.0 alpha with libtorrent 1.0.1svn+r10217. I am not using 
BTGuard. I am using Private Internet Access for my proxy. I think there is 
definately a problem here. Can you please review the thread that Sledge 
references

Original comment by gsoud...@cox.net on 24 Sep 2014 at 5:06

[GoogleCodeExporter]

as far as I can tell from the code (in head of all active branches, 0.16.x and 
1.0.x) when a socks5 proxy hangs up (the UDP associate connection) it will 
start over immediately, including resolving the hostname.

how certain are you that the problem is the name lookup not being re-issued? do 
you think you would be able to capture this in wireshark? (if you do and post 
the capture, make sure to either change your socks5 password afterwards, or 
scrub the username password from the capture, since it's all clear text).

a wireshark capture would say whether the connection is re-established, whether 
there is an actual hostname lookup being sent out (of if it's just cached).

are you sure the problem is that the proxy changes its IP? I wouldn't expect 
proxies to do that very often, since it would always cause interruptions.

Original comment by arvid.no...@gmail.com on 24 Sep 2014 at 4:41

[GoogleCodeExporter]

While waiting for someone to give a wireshark dump...
@arvid when the code tries to reconnect, does it resolve using the "regular" 
connection or does it try to resolve through the broken proxy connection?

Original comment by hammered...@gmail.com on 24 Sep 2014 at 7:23

[GoogleCodeExporter]

the proxy hostname is always resolved using the normal system hostname 
resolver. socks5 doesn't really have a hostname resolution mechanism per se. It 
just allows using hostnames as addresses when connecting to a remote machine.

the code is in udp_socket::hang_up(), which is a handler for a long-poll (in a 
way) reading from the socks5 socket. If the remote end hangs up (disconnects) 
it's called. in there, if we didn't hang up because we aborted, we simply start 
over from the beginning by calling set_proxy_settings(), which will resolve the 
hostname again.

Original comment by arvid.no...@gmail.com on 24 Sep 2014 at 7:29

[GoogleCodeExporter]

Arvid and Sledge, To be honest I am not sure what is happening here. I do know 
that when qB is idling with DHT enabled, the IP is changing but I do not know 
why. At least the qB logs says it is changing. Please check the related qB 
forum thread for details and a screen shot.

My latest run has produced different results. The IP never changed in 18 hours 
but DHT peers still dropped to 0. Perhaps there are two separate issues going 
on. Again check the forum thread for details and screen shots.

I will initiate a wireshark capture before I go to bed. I do not want any 
unnecessary packets from other network activity to be captured.

Original comment by gsoud...@cox.net on 25 Sep 2014 at 12:21

[GoogleCodeExporter]

when you say "the IP is changing", what do you mean exactly? whose IP? I was 
under the impression we're talking about the IP the proxy is at. What exactly 
does the log say? (could you copy paste it?).

If this is mentioned in the log, are you sure it's not _your_ IP that's 
changing? is it because your router/modem crashes and restarts? (if it's 
correlated with DHT, that seems like a reasonable guess).

Original comment by arvid.no...@gmail.com on 25 Sep 2014 at 2:15

[GoogleCodeExporter]

I think he refers to the "external address", which is returned by 
external_ip_alert.

Original comment by hammered...@gmail.com on 25 Sep 2014 at 6:10

[GoogleCodeExporter]

I see. presumably there is some network interruption when this happens. I would 
expect all TCP connections to be broken. Perhaps the issue is that the TCP 
connection to the proxy just hangs. Since there's no traffic expected on it, 
and perhaps no TCP keepalive, it will just sit there and not detect that the 
network was reset.

Perhaps enabling TCP keepalives on that connection would be the simplest 
solution.

Original comment by arvid.no...@gmail.com on 25 Sep 2014 at 5:35

[GoogleCodeExporter]

Arvid, I have created the wireshark capture you requested. Please reference 
Reply #21 in the qB forums http://qbforums.shiki.hu/index.php/topic,2561.15.html

Original comment by gsoud...@cox.net on 25 Sep 2014 at 6:12

[GoogleCodeExporter]

Arvid, I read your reply in the qB forums. Is adding TCP keep-alives a 
libtorrent change or a change that I need to make on my machine?

Do you have any clue as to why the External IP is changing in the first place? 

Original comment by gsoud...@cox.net on 25 Sep 2014 at 8:15

[GoogleCodeExporter]

Arvid, I just re-examined the wireshark capture again. It looks like the 
External IP actually changed at around 6:28. I guess it was not reflected in 
the qB logs until 6:43. Does this change your assessment as to why this is 
happening? Does this part of the log give any clue as to why the External IP is 
changing in the first place?

Original comment by gsoud...@cox.net on 25 Sep 2014 at 8:36

[GoogleCodeExporter]

it's a libtorrent change.
the external IP would change if the ISP is not very nice, and doesn't pin IPs 
to subscribers. it may be associated with DHCP leases expiring or having short 
leases.

Original comment by arvid.no...@gmail.com on 25 Sep 2014 at 8:38

[GoogleCodeExporter]

please test this patch:

Index: src/udp_socket.cpp
===================================================================
--- src/udp_socket.cpp  (revision 10325)
+++ src/udp_socket.cpp  (working copy)
@@ -946,6 +946,10 @@

    error_code ec;
    m_socks5_sock.open(m_proxy_addr.address().is_v4()?tcp::v4():tcp::v6(), ec);
+
+   // enable keepalives
+   m_socks5_sock.set_option(boost::asio::socket_base::keep_alive(true), ec);
+
    ++m_outstanding_ops;
 #if TORRENT_USE_ASSERTS
    ++m_outstanding_connect;

Original comment by arvid.no...@gmail.com on 26 Sep 2014 at 12:49

[GoogleCodeExporter]

I will need Sledge's help to test this change as I am not able to build. Thanks 
for your help on this matter. On another note, I have replied to issue 678. 
Could you have another look? Perhaps if this is possible, we could test both 
changes in the build Sledge makes.

Original comment by gsoud...@cox.net on 26 Sep 2014 at 12:20

[GoogleCodeExporter]

Here is a gcc build of qbt 3.1.10 against latest RC_0_16 containing the above 
patch: http://builds.shiki.hu/temp/qbittorrent_3.1.10_libtorrent_keep_alive.7z

Original comment by hammered...@gmail.com on 26 Sep 2014 at 1:52

[GoogleCodeExporter]

Here is a gcc build of qbt 3.2.0alpha against latest RC_1_0 containing the 
above patch: 
http://builds.shiki.hu/temp/qbittorrent_3.2.0alpha_libtorrent_keep_alive.7z

Original comment by hammered...@gmail.com on 26 Sep 2014 at 10:05

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Arvid, unfortunately the test was inconclusive. Please reference Reply #23 in 
the qB forums for details.

http://qbforums.shiki.hu/index.php/topic,2561.15.html

I will not be available for most of the day. I am starting another test run 
now...

Original comment by gsoud...@cox.net on 28 Sep 2014 at 1:12

[GoogleCodeExporter]

Arvid I have answered your questions in the qB topic as best I can. Please have 
a look at Reply #27. Thanks...

Original comment by gsoud...@cox.net on 29 Sep 2014 at 3:05

[GoogleCodeExporter]

Arvid I know you are very busy but could you take another look at this. 
Thanks...

Original comment by gsoud...@cox.net on 2 Oct 2014 at 1:24

[GoogleCodeExporter]

Arvid is there any progress on this issue?

Original comment by gsoud...@cox.net on 11 Oct 2014 at 4:44