Proxy Socks5 (BTguard)

Linux specific questions, problems.
sledgehammer_999
Administrator
Administrator
Posts: 2443
Joined: Sun Jan 23, 2011 1:17 pm

Re: Proxy Socks5 (BTguard)

Post by sledgehammer_999 »

@MrGreg you should ask arvid in the bug report I linked. Maybe he will answer.
Unfortunately I don't know much about the libtorrent internals nor do I now much about networking. Just basic stuff.
MrGreg

Re: Proxy Socks5 (BTguard)

Post by MrGreg »

Hi Sledge and thanks for weighing in. I am with you man, me either. I will do as you suggest and ask Arvid.

ciaobaby, I am not using BT Guard. I am using Private Internet Access. I am not sure if they do things the same way as BT Guard. What I do know is that libtorrent is constantly updating DHT peers as it should. Some fall away and new ones are added. During this process, if the hostname is used, which I suspect it is, then I can see how the IP could change. For instance when I used nslookup on my proxy hostname, I am returned a different list of IP's each time I run it.

I do believe that there is a problem with libtorrent when the External IP changes for whatever reason. DHT seems to lose its way and go to zero. This should obviously not happen. I agree with red5goahead in that when this occurs, torrents still work if there are peers available via the trackers. The torrent just will not have any DHT peers to download pieces with.
Last edited by MrGreg on Wed Sep 24, 2014 6:58 am, edited 1 time in total.
ciaobaby

Re: Proxy Socks5 (BTguard)

Post by ciaobaby »

With any proxy system it is NOT the inbound IP (the one that your system makes requests to) that changes. It is the outbound IP (the one that makes requests  to remote systems on your behalf) that does.

This is what makes proxies "anonymous" [along with some other internal mechanisms that are far too geeky/nerdy to try and explain here :) ] each request to the remote user agent will appear to be from a different source, this same method is what also makes 'anonymiser' proxies often woefully inadequate for network  connections that require a high degree of permanence (called 'persistent connections') such as FTP or indeed BTP does.

Try running a 'What's my torrent IP' (http://torguard.net/checkmytorrentipaddress.php) task  through a proxy that rotates and see how soon the task becomes 'invalid' because of "Excessive IP changes".
MrGreg

Re: Proxy Socks5 (BTguard)

Post by MrGreg »

I have had qB running for over 18 hours and the External IP has not changed. I find this very odd considering the last couple of runs it changed multiple times in a much shorter time frame. The interesting thing is that DHT peers have gone from 120+ to 0 again but this time without the External IP changing. I watched them slowly drop away. This morning it was down to 6 and now 0. I figured the drop to 0 was associated with the IP changing and libtorrent not picking up the change. However this seems not to be the case. To be quite honest I am not sure what is going on here. I am once again attaching a screen shot.

I really do not think that my proxy provider is rotating my IP when an active connection has been established. I would think this would introduce a potential for data loss. If I find this is the case, I will be switching providers because this is unacceptable.

Arvid has asked that I try and pin this down with a wireshark packet capture. I am not sure if the IP will change but it might yield a clue as to why the DHT peers are going to 0. I will initiate one before I go to bed tonight.
Attachments
Changing External IP 4.jpg
Last edited by MrGreg on Wed Sep 24, 2014 11:54 pm, edited 1 time in total.
ciaobaby

Re: Proxy Socks5 (BTguard)

Post by ciaobaby »

I have had qB running for over 18 hours and the External IP has not changed.
Is that with something actually monitoring the ip or just hoping that qbittorrent/libtorrent will 'pick up' change?
I really do not think that my proxy provider is rotating my IP when an active connection has been established. I would think this would introduce a potential for data loss.
You are one hundred percent, utterly wrong on that point, it IS the VERY REASON why the BitTorrent protocol was developed.

"To facilitate reliable data transfer over unreliable networks"
https://wiki.theory.org/BitTorrentSpeci ... tification
MrGreg

Re: Proxy Socks5 (BTguard)

Post by MrGreg »

ciaobaby,

I was not running wireshark on this run to monitor the External IP change. However the change has been picked up by qbittorrent/libtorrent on all of my previous runs. I just assumed that on this run it did not change.

Just because the BitTorrent protocol was developed to handle this kind of situation does NOT mean that this is what is actually occurring here. That is what I am trying to figure out. I suppose that it really does not matter if the External IP changes. However if it does, qbittorent/libtorrent must pick up the change and the change cannot break DHT.
Last edited by MrGreg on Thu Sep 25, 2014 4:51 pm, edited 1 time in total.
MrGreg

Re: Proxy Socks5 (BTguard)

Post by MrGreg »

Arvid, here is the wireshark capture you requested. I have changed my password after the capture as you suggested. I am also attaching a screen shot of qB displaying the log. You will see that the External IP changed at 6:43 AM. This should help you narrow down where to look in the wireshark capture.
When the External IP changes, the DHT count goes to 0 and never recovers.

On the run before this (Reply #18 in this thread), I ran qB for 18 hours and the External IP never changed. I noticed the DHT count had also gone to 0. So there maybe two seperate issues here. To isolate this I will disable my proxy and run another test. Lets see if the DHT count goes to 0 without a proxy.
Attachments
Changing External IP 5.jpg

[The extension has been deactivated and can no longer be displayed.]

arvidn

Re: Proxy Socks5 (BTguard)

Post by arvidn »

the socks server resets the TCP connection every 5 minute, and it's reconnected. it's not disconnected at 6:43, probably because the RST packet won't arrive, since your IP changed. I think adding TCP keep-alives to that connection would probably fix this.
MrGreg

Re: Proxy Socks5 (BTguard)

Post by MrGreg »

Arvid, I have just finished a test run with the patched version Sledge provided. I used the 3.2 alpha version with libtorrent 1.0.2. The test was run for about 17 hours. Unfortunately the test is inconclusive. I experienced the same behavior as Reply #18 in this thread. It seems that qbittorrent/libtorrent is not picking up the External IP changes. At least the qB log is not showing the changes. However this time I have a wireshark capture. According the the wireshark log, the External IP changed 17 times. I have listed the changes below. You can find the changes easily by searching the capture for privateinternetaccess.

46.166.186.202 -> 46.166.186.226
46.166.186.226 -> 46.166.186.200
46.166.186.200 -> 109.201.154.237
109.201.154.237 -> 109.201.154.133
109.201.154.133 -> 46.166.186.205
46.166.186.205 -> 109.201.154.130
109.201.154.130 -> 46.166.186.200
46.166.186.200 -> 109.201.154.133
109.201.154.133 -> 46.166.186.200
46.166.186.200 -> 109.201.154.240
109.201.154.240 -> 109.201.135.183
109.201.135.183 -> 46.166.186.205
46.166.186.205 -> 46.166.186.204
46.166.186.204 -> 109.201.154.206
109.201.154.206 -> 46.166.186.200
46.166.186.200 -> 109.201.152.233
109.201.152.233 -> 109.201.154.133

The interesting thing is that I was observing the DHT count for the first 4 or 5 hours of this capture. It started at 128 and was still over 100 before I went to bed early. During this time frame, the External IP changed multiple times. I am not sure how or why DHT did not go to zero when the IP changed. However over the duration of the run, DHT count eventually went to 0. The screen shot shows this.

Obviously the UDP keep alive patch is not causing this behavior. Because in Reply #18 I was not using the UDP keep alive patch. I suspect that in my other runs where the qB logs showed 3-4 changes, there were actually many other IP changes that were not picked up.

It seems we first have to figure out why qbittorrent/libtorrent is not picking up the IP changes. Then we can figure out why DHT is going to 0.

I would think that when qbittorrent/libtorrent DOES pick up an IP change, DHT should do a complete restart with a new node id. I am not convinced that this is occurring.

The wireshark capture is to large for this forum. I have uploaded it here...

http://www.mediafire.com/download/yvebybs6keaw2c0/Wireshark_Capture_2.pcapng

PS: I will be unavailable for most of the day. I am going to start another run including a wireshark capture...
Attachments
Changing External IP 6.jpg
Last edited by MrGreg on Mon Sep 29, 2014 7:27 pm, edited 1 time in total.
ciaobaby

Re: Proxy Socks5 (BTguard)

Post by ciaobaby »

It seems we first have to figure out why qbittorrent/libtorrent is not picking up the IP changes. Then we can figure out why DHT is going to 0


No 'figuring out' is necessary. The simple fact is that when the external IP changes no incoming messages WILL be received because ALL peers, trackers and DHT nodes are replying to the last IP that the messages came from.

The explanation why is fairly simple
Out-going DHT messages for any particular loaded task are multicast  to find and connect to as many DHT nodes as possible, return (incoming) messages are unicast

Multicast is where one or more nodes send messages that are to be picked up by one or more remote nodes

Unicast is direct communication from one discrete node to another discrete node.

It's a bit like having  a "tin can telephone" connected to six friends, you say "Anybody listening" then take a step forward so the string goes slack before any body says "yes".
arvidn

Re: Proxy Socks5 (BTguard)

Post by arvidn »

[quote="MrGreg"]
According the the wireshark log, the External IP changed 17 times.[/quote]

I'm pretty sure you don't mean your external IP changed 17 times, the IP of the proxy you talked to changed 17 times. The proxy kills the connection every 5 minutes. Every time, libtorrent reconnects.
Presumably the DNS has a TTL of one hour, so every hour the hostname is re-resolved, and each time there's a chance you get the IPs back in a different order, i.e. you connect to a different IP.

Every time you connect to a different IP, things will behave essentially as if your external IP changed, because your proxy's external IP changed (or rather, you changed proxy to one with a different external IP).

I would expect all your peers to stall and get disconnected when this happens. I would expect you to drop all your DHT nodes. I would expect you to slowly rebuild your DHT routing table and gradually reconnect new peers as you kick off the stale ones. Only uTP peers are affected btw. TCP peers probably will just keep working, since they are pinned to the original proxy by the CONNECT command, not the UDP ASSOCIATE command.

All of these problems are expected and as far as I can tell, only your proxy provider can fix them. Here are some things they could do:

1. don't disconnect UDP ASSOCIATE connections every 5 minutes, but let them live indefinitely (and they should enable TCP keepalive on their end too)
2. make the DNS responses consistent, so that any given user has a consistent order in which to try the proxies.

Now, the problem we're looking for, as far as I can tell, is where libtorrent fails to detect that a proxy is no longer working, because the client's external IP changed. Did you actually experience your own IP changing?

what I'm seeing in your log is that, around time 2415 seconds, the SOCKS5 handshake fails (did you change your username or password?). It's retried once more and still fails, and then there are no more attempts for the duration of the capture. Was this failure reported in any way in the UI?
ciaobaby

Re: Proxy Socks5 (BTguard)

Post by ciaobaby »

C'mon guys, what is it that you are missing about wide area network communication ALWAYS failing if the IP changes between outgoing requests and incoming responses.


The 'problem' is going to be that libtorrent possibly has a time out issue between sending a request and not receiving replies or not responding to the fact that the returning data has stopped.

Sending keep-alives is NOT going to make any difference because it is NOT the communication between libtorrent and proxy that has failed, it is the connection between REMOTE peer and proxy that has been broken.

If you need a picture to visualise it, let me know and I'll fire up Inkscape
MrGreg

Re: Proxy Socks5 (BTguard)

Post by MrGreg »

Arvid, I will try and answer your questions as best I can...
I'm pretty sure you don't mean your external IP changed 17 times, the IP of the proxy you talked to changed 17 times.
Yes the Proxy IP changed 17 times. I use the term External IP because that is what qBittorent calls the Proxy IP in the log.
The proxy kills the connection every 5 minutes. Every time, libtorrent reconnects.
Can you please provide line numbers in the last wireshark log when this occurs?
Presumably the DNS has a TTL of one hour, so every hour the hostname is re-resolved, and each time there's a chance you get the IPs back in a different order, i.e. you connect to a different IP.
Actually the TTL can be 30 minutes or 1 hour. The wireshark log confirms 30 minute intervals for some IP's and 1 hour for others.
Every time you connect to a different IP, things will behave essentially as if your external IP changed, because your proxy's external IP changed (or rather, you changed proxy to one with a different external IP).
Agreed...
I would expect all your peers to stall and get disconnected when this happens. I would expect you to drop all your DHT nodes. I would expect you to slowly rebuild your DHT routing table and gradually reconnect new peers as you kick off the stale ones. Only uTP peers are affected btw. TCP peers probably will just keep working, since they are pinned to the original proxy by the CONNECT command, not the UDP ASSOCIATE command.
Agreed. However this does not seem to be the case. When I observe the DHT count, it remains fairly steady for quite some time. I would think that it would drop to 0 each time the Proxy IP changes. Then I would expect to see it rebuilding. I do not this occurring.

The comments in session_impl.cpp indicate that when the External or Proxy IP changes, DHT will restart with a new node id. These are just your comments. I am not sure what the code is doing. I am not sure this is actually occurring each time the IP changes.
All of these problems are expected and as far as I can tell, only your proxy provider can fix them. Here are some things they could do:

1. don't disconnect UDP ASSOCIATE connections every 5 minutes, but let them live indefinitely (and they should enable TCP keepalive on their end too)
2. make the DNS responses consistent, so that any given user has a consistent order in which to try the proxies.
This is simply not going to happen. I have been fighting these people for 3 months trying to resolve an issue were some of their IP's fail to connect with the error "The target computer actively refused the connection". The issue is random and still unresolved. Their Admin team is like a black hole.
Now, the problem we're looking for, as far as I can tell, is where libtorrent fails to detect that a proxy is no longer working, because the client's external IP changed. Did you actually experience your own IP changing?
This is the problem that we are looking for. No my LAN or WAN IP did not change.
what I'm seeing in your log is that, around time 2415 seconds, the SOCKS5 handshake fails (did you change your username or password?). It's retried once more and still fails, and then there are no more attempts for the duration of the capture. Was this failure reported in any way in the UI?
Please provide a line # where this occurred. I did not change my username or password midstream during this run. No the failure was not reported in the UI. I do change my password AFTER each wireshark capture that I post. After I change it, sometimes I get an authentication error on initial connection attempt in the qB log. I have to wonder if the proxy server is caching the old password. Just another quirk with this shitty provider.

I did another run yesterday for about 11 hours with similar results. This time the qB logs showed the External IP or Proxy IP changing twice. However the wireshark log shows it changed 12 times. Do you want me to post the qB screen shot and the wireshark log?
Last edited by MrGreg on Mon Sep 29, 2014 3:21 pm, edited 1 time in total.
Post Reply