Opened 12 years ago

Last modified 18 months ago

#2149 reopened bug

deluge ignoring proxy settings

Reported by: rm Owned by:
Priority: critical Milestone: 1.3.14
Component: Plugin Version: 2.0.3
Keywords: proxy Cc: pterodactyle@…, shellsonthefloor@…, a.starr.b@…, john.smith@…

Description

Good day.

I fail to using deluge 1.3.5 in proxy environment (w/o autorization). It worked fine in 1.3.4 at the same site and I'm 100% that I didn't block anything in squid proxy server, all the applications like IM-clients, browsers etc successfully working via the same proxy. Here is how I tested it:

  • removed ~/.config/deluge

Then just start it, go to Edit -> Preferences -> Proxy. Put in HTTP, proxyaddr:proxyport into all four fields and then just checking squid with sqstat - there is not even connections from deluge.

I also did another test: the settings are the same (proxy is turned on in deluge), and on default router's firewall I allowed direct connections with internets from my system - deluge successfully downloading the same torrent, but still not using proxy. So it looks like that it didn't ever try to use it.

If it make any difference, I'm using GTK-frontend of deluge 1.3.5 on FreeBSD. Related apps versions are:

boost-libs-1.48.0 boost-python-libs-1.48.0 libtorrent-rasterbar-0.16.2 py-libtorrent-rasterbar-0.16.2 (python binding) python 2.7.3

Please note once again that deluge working just fine another way. The problem is only appears when I try to use deluge via proxy. And there was no such problems with 1.3.4 in the same environment.

Here is what was added to my ~/.config/deluge/core.conf

  "proxies": {
    "peer": {
      "username": "", 
      "password": "", 
      "type": 4, 
      "port": 3128, 
      "hostname": "192.168.0.7"
    }, 
    "web_seed": {
      "username": "", 
      "password": "", 
      "type": 4, 
      "port": 3128, 
      "hostname": "192.168.0.7"
    }, 
    "tracker": {
      "username": "", 
      "password": "", 
      "type": 4, 
      "port": 3128, 
      "hostname": "192.168.0.7"
    }, 
    "dht": {
      "username": "", 
      "password": "", 
      "type": 4, 
      "port": 3128, 
      "hostname": "192.168.0.7"
    }
  }, 

I see in debug log:

[DEBUG   ] 15:27:06 config:197 Setting 'proxies' to {'peer': {'username': '', 'password': '', 'hostname': '', 'type': 0, 'port': 8080}, 'web_seed': {'username': '', 'password': '', 'hostname': '', 'type': 0, 'port': 8080}, 'tracker': {'username': '', 'password': '', 'hostname': '', 'type': 0, 'port': 8080}, 'dht': {'username': '', 'password': '', 'hostname': '', 'type': 0, 'port': 8080}} of <type 'dict'>

and later:

[DEBUG   ] 15:27:06 config:391 Config /home/rm/.config/deluge/core.conf version: 1.1 loaded: {'proxies': {u'peer': {u'username': u'', u'password': u'', u'type': 4, u'port': 3128, u'hostname': u'192.168.0.7'}, u'web_seed': {u'username': u'', u'password': u'', u'type': 4, u'port': 3128, u'hostname': u'192.168.0.7'}, u'tracker': {u'username': u'', u'password': u'', u'type': 4, u'port': 3128, u'hostname': u'192.168.0.7'}, u'dht': {u'username': u'', u'password': u'', u'type': 4, u'port': 3128, u'hostname': u'192.168.0.7'}}, }

So it looks like it set proxies before actually parsing core.conf?

Attachments (3)

Deluge.jpg (35.3 KB) - added by John007 4 years ago.
Deluge Version
Deluge-Proxy-Settings-Issue.jpg (72.9 KB) - added by John007 4 years ago.
The Proxy Settings Dialog
deluge not using proxy.png (128.6 KB) - added by tangles 3 years ago.
evidence of Deluge not using proxy 2021/06/27

Download all attachments as: .zip

Change History (49)

comment:1 Changed 12 years ago by Cas

Please test with libtorrent 0.15.

comment:2 Changed 12 years ago by ku

  • Cc pterodactyle@… added
  • Keywords proxy added
  • Priority changed from major to critical
  • Version changed from other (please specify) to 1.3.5

Same with me, deluge 1.3.5-1 and libtorrent-rasterbar 0.16.2-1 and 0.16.3-1 under Arch Linux. I tried a proxy, was surprised by the high speed and then tried to type in bogus IPs, one starting with 255. etc. The torrents kept downloading. Then I started wireshark and noticed that all connections on deluge's port are to real peer addresses, not to the proxy address (well, obvious since it works with bogus IPs as a proxy). I used HTTP proxy on the port 3128. I used the GUI to set it up, but checked core.conf, too and it shows everything like it should be. Seems to me like the proxy option is broken now (if it ever worked).

comment:3 Changed 12 years ago by Cas

  • Component changed from gtkui to core

See if clearing session.state helps: #2109

comment:4 Changed 12 years ago by ku

No, still having direct connections with peers. I had the same problems with ktorrent and didn't find any proxy settings in transmission, only got it to work with utorrent under wine, which is horribly inconvenient.

comment:5 Changed 12 years ago by Cas

Can you please try with qbittorrent as it uses the same 0.16 libtorrent library.

What the OP reports does not make sense (works 1.3.4 and not 1.3.5) as there have been no major changes and certainly not in the proxy code however the fact you are using lt 0.16 and not 0.15 (which is what 1.3 was designed for) could be a factor here whereas the OP's bug is likely related to #2109.

The problem will either be that somehow Deluge is failing to pass the proxy settings to libtorrent or there is an issue in libtorrent itself which would require reporting upstream.

comment:6 Changed 12 years ago by rm

Hi! I'm terribly sorry about the delay. Deluge 1.3.5 is indeed work via proxy with: libtorrent-rasterbar-0.15.9 py27-libtorrent-rasterbar-0.15.9

and ignores the proxy settings with libtorrent-rasterbar-0.16.x py27-libtorrent-rasterbar-0.16.x

So it's looks like libtorrent is the culprit. Dunno if it's an regression or some api change.

comment:7 Changed 12 years ago by Cas

The only documented api change in proxy settings from 0.15 to 0.16 are the addition of proxy_hostnames and proxy_peer_connections for which the python bindings are missing and that may be the issue.

comment:8 Changed 12 years ago by rm

Ok, so should I bug upstream or you can prepare more quality bug report to them (I didn't dig both deluge and libtorrent internals)? Would adding this functions into python bindings automagically fix deluge work behind proxy, or it should be modified too?

comment:9 Changed 12 years ago by rm

And by the way #2109 is unrelated issue, but I was caught by it too. This is the reason why I remove ~/.config/deluge before testing. So just want to say, that "it annoys me too".

comment:10 follow-up: Changed 12 years ago by arvid

The proxy settings did change in libtorrent 0.16. There is now only a single proxy setting and the previous ones just forward to that one setting.

The reason why they were coalesced was that introducing uTP (which are peers over UDP), along with DHT (also over UDP) and UDP trackers. It didn't make much sense in ever separating by peer/not peer. It doesn't make sense to announce to the DHT or a UDP tracker via the proxy, and then not accept peer connections over the proxy.

There is a risk that if deluge is setting the proxy settings, and then setting some other proxy setting to nothing, that last one overrides the first ones. One of the assumptions in the backwards-compatibility logic was that you wouldn't overwrite a proxy setting with something you didn't want set.

It's possible something went wrong in the python binding as well. I'll take a look at that.

comment:11 in reply to: ↑ 10 Changed 12 years ago by Cas

Thanks arvid, I think that is the crux of the issue and explains the weirdness I was seeing; all proxies details being identical, when testing earlier with simple lt client.

I didn't see any issue with settings values with the bindings so the only outstanding issue would be those missing options.

The code in pref manager certainly does cycle through every proxy and set it so the last one will override all others:

http://git.deluge-torrent.org/deluge/tree/deluge/core/preferencesmanager.py#n431

rm and ku could you try setting all the proxies (dht, web, tracker & dht) to see if that works?

comment:12 Changed 12 years ago by rm

Cas, I always set them all while testing/regular use - see the original message. It just didn't work.

comment:13 Changed 12 years ago by ku

Hmmh. Somehow my comment from yesterday didn't get posted. First of all, I am setting all 4 proxies. Though the only bearable free anonymous proxy i found was HTTPS and I'm using HTTP (no HTTPS option in deluge). Are HTTPS proxies supported by deluge/libtorrent? I also tried to downgrade to libtorrent-rasterbar 0.15.10 yesterday (I can't find an older version, since Arch Linux' repos only hold the latest version of packages and I purged my package cache several months ago). Still direct connections to peers (first it wouldn't even start, some problem with the classic mode and wouldn't connect to the daemon, after deleting session.state it worked, but lost all the torrents' states). I also tried to install qbittorrent, but it wouldn't build from AUR. qbittorrent-bin wouldn't start because of a symbol lookup error (EDIT: managed it to start with libtorrent-rasterbar 0.16.3-1. Also no HTTPS option and also direct connections to peers).

Sorry for the off-topic, but are there any other torrent clients under linux, that suport HTTPS proxy and magnet links? Vuze only connects to one peer from 1600+ and has a direct connection to him, utorrent under wine crashes all the time and doesn't download from TPB's magnet links. I'd also like to try a free anonymous SOCKS proxy, but can't find one.

comment:14 Changed 12 years ago by ku

Oops. I just found out where I was wrong. The whole time the daemon was running with 0.16-3 (Help->About). It doesn't start with 0.15.x at all. Googling showed that I might need boost-libs 1.48.0 for that to work, this would break other packages for me.

comment:15 Changed 12 years ago by ku

Just tested in Ubuntu 10.4 in VirtualBox? - both deluge 1.2.2 and qbittorrent 2.2.5 work with that proxy with libtorrent 0.14.10.0. I also tested fatrat (it also depends on libtorrent-rasterbar) with 0.16.3 and it didn't work, too. So indeed, it seems like something was changed or broken with libtorrent 0.16.x

comment:16 Changed 12 years ago by Cas

  • Component changed from core to libtorrent

Yep I looked again at the Deluge code and it will not overwrite if the proxy in set to None and testing with simple client and Deluge shows the Python bindings appear to get and set ok so this suggests a deeper issue in lt 0.16.

I would suggest moving the discussion to libtorrent bug tracker.

comment:17 Changed 11 years ago by arvid

I notice that you're using an HTTP proxy.

I would expect the following:

  • http trackers would use the proxy
  • TCP bittorrent connections would use the proxy via CONNECT
  • uTP bittorrent connections would _not_ use the proxy (since it doesn't support UDP)
  • udp trackers would _not_ use the proxy
  • DHT would _not_ use the proxy.

Is it possible that you see uTP traffic and expect it to go via the proxy? uTP support is new in 0.16.x.

It's possible to disable uTP support by setting session_settings::enable_incoming_utp and session_settings::enable_outgoing_utp to false (I don't think this is exposed in Deluge though).

Alternatively, you could use a SOCKS5 proxy instead, which does support UDP.

comment:18 Changed 11 years ago by shellsonthefloor

  • Cc shellsonthefloor@… added

I'm experiencing this same issue with libtorrent-rasterbar6 version .15.10-1+b1 and a socks5 proxy without authentication.

comment:19 Changed 11 years ago by shellsonthefloor

Just wiped and went down to Debian Stable and installed Deluge from repositories (1.2.3, libtorrent-rasterbar 0.14.10) and Deluge is still ignoring proxy settings. It also ignores proxy settings when tsocks is used.

comment:20 Changed 11 years ago by arvid

what are the symptoms you see to determine that Deluge ignores proxy settings?

Are you running netcat to listen on the proxy port and look for incoming connections? Do you wireshark the traffic to make sure the packets that look like bittorrent all goes to the proxy?

I have been trying to reproduce this without any success, and I'm looking for clues of differences in our setup. For instance, keep in mind that when you use an HTTP proxy, only some traffic can go through it.

comment:21 Changed 11 years ago by shellsonthefloor

I'm using a socks5 proxy - using ssh -D 8081. I'm using a much simpler method to check if it works, so here's what I see:

  1. Torrents will start downloading even when the ssh tunnel has not been started.
  2. Torrents that start while the tunnel is active do not stop when the tunnel is killed.
  3. The IP of my client in the swarm will either show up as being my "real" IP, or will only show the IP of the proxy for a short time before switching over to my "real" IP.

comment:22 Changed 11 years ago by Cas

  • Milestone changed from 1.3.6 to not applicable

comment:23 Changed 9 years ago by sslx

Deluge totaly ignores socks5 proxy. I'm trying to use socks5 with privateinternetaccess. My real ip shows up on the swarm, and Deluge starts downloading even if I put wrong username password. I tested on uTorrent, and it works as expected. If I put correct info, my real ip doesn't show up, and if I put wrong user/pass it doesn't work.

deluged: 1.3.10 libtorrent: 0.16.17.0

Last edited 9 years ago by sslx (previous) (diff)

comment:24 Changed 8 years ago by ajthemacboy

I just monitored Deluge with Wireshark and found that it's connecting directly to peers despite having a working proxy. However I have noticed some interesting behavior:

If I change one number in the proxy IP, for example, to a non-working proxy, no downloads work; everything is frozen. So Deluge will only download given a working proxy; it's just not using that proxy.

comment:25 Changed 8 years ago by WeissmanScore

Woah. That's not good... So this is confirmed and there is no way to mitigate? I am going to kill every instance I have running until I hear this is resolved.

comment:26 Changed 7 years ago by thero

Wow. How can a critical bug like this still be around 4 years later?

comment:27 Changed 7 years ago by DeadlyKnapsack

This is absolutely ridiculous. You are playing around with other people's privacy. I will immediately stop using Deluge.

comment:28 Changed 7 years ago by dg7dg

Tested on 3.1.13 on Windows, via an account with a VPS provider, and then checking access to a magnet link on http://ipmagnet.services.cbcdn.com/

This bug still occurs; the Socks5 proxy setting is ignored by Deluge.

Last edited 7 years ago by dg7dg (previous) (diff)

comment:29 follow-ups: Changed 7 years ago by Cas

Ok I think I see the issue, since libtorrent 0.16 there is only one proxy setting and the old way that Deluge sets the proxy settings using peer, web etc when applied are overwriting the previous values so if dht is empty that is likely to be the last item set which would clear the values.

The workaround for now is to set all the proxies peer, web, tracker, dht to the same values.

This definitely applies to lt 1.1. and 1.0.

libtorrent issue: https://github.com/arvidn/libtorrent/issues/1646

1.3-stable fix: [8565eccb3de9]

Last edited 7 years ago by Cas (previous) (diff)

comment:30 in reply to: ↑ 29 Changed 7 years ago by arliweng

tested 1.3.14 with libtorrent-rasterbar 1.1.1 and 1.1.3(from github) on archlinux, problem still, tracker proxy can't save

[INFO ] 17:37:39 main:130 Deluge ui 1.3.14 ... [DEBUG ] 17:37:39 preferencesmanager:496 Setting peer proxy settings: {u'username': u, u'password': u, u'type': 0, u'port': 8080, u'hostname': u} [WARNING ] 17:37:39 preferencesmanager:486 Using libtorrent >= 0.16 ignores proxy settings for tracker

comment:31 follow-up: Changed 7 years ago by Cas

  • Milestone changed from not applicable to 1.3.14
  • Resolution set to Fixed
  • Status changed from new to closed

Did you read my last comment? There is only one proxy now. So peer proxy values are now used for all proxies. See #2991

comment:32 in reply to: ↑ 31 Changed 7 years ago by DeadlyKnapsack

  • Resolution Fixed deleted
  • Status changed from closed to reopened

Replying to Cas:

Did you read my last comment? There is only one proxy now. So peer proxy values are now used for all proxies. See #2991

And still the IP is leaked! Even with the latest version 1.3.15. No matter what I do. It doesn't have to do with the settings. I can clearly see my IP in the Torrent swarm, when checking from different client downloading the same torrent. Why aren't you giving this more attention? This should clearly be one of the highest priorities. The fact that I know it is leaking, prevents me from using Deluge, so I can be safe. But what about all the other users who perhaps unknowingly are unable to hide their IP in the swarm?!

comment:33 in reply to: ↑ 29 Changed 7 years ago by DeadlyKnapsack

Replying to Cas:

Ok I think I see the issue, since libtorrent 0.16 there is only one proxy setting and the old way that Deluge sets the proxy settings using peer, web etc when applied are overwriting the previous values so if dht is empty that is likely to be the last item set which would clear the values.

The workaround for now is to set all the proxies peer, web, tracker, dht to the same values.

This definitely applies to lt 1.1. and 1.0.

libtorrent issue: https://github.com/arvidn/libtorrent/issues/1646

1.3-stable fix: [8565eccb3de9]

This is incorrect in my situation. Even with identical values for all the proxies, the IP is visible.

comment:34 follow-up: Changed 7 years ago by dg7dg

Let us be honest here :) This bug has been open for five years. It's not a stretch to say that you cannot trust Deluge with your privacy, now or in the future.

Under no circumstances I blame the developers for not fixing the bug. I do blame them for offering a no-working feature for five years.

comment:35 in reply to: ↑ 34 Changed 7 years ago by DeadlyKnapsack

Replying to dg7dg:

Let us be honest here :) This bug has been open for five years. It's not a stretch to say that you cannot trust Deluge with your privacy, now or in the future.

Under no circumstances I blame the developers for not fixing the bug. I do blame them for offering a no-working feature for five years.

Oh, I blame them for claiming the fix works. As a user, I should not be doublechecking the security.

comment:36 Changed 7 years ago by andrewsomething

  • Cc a.starr.b@… added

comment:37 Changed 7 years ago by slajerek

Wow, just tried Deluge for the first time... I did not expect that. 5 years already?? Guys, this is nonsense. Does not work for me either:

[INFO ] 23:59:01 daemon:124 Deluge daemon 1.3.10

It is completely ignoring my Proxy settings.

Time wasted, removing Deluge now. Thanks.

Last edited 7 years ago by slajerek (previous) (diff)

comment:38 Changed 6 years ago by andocromn

try using the ltConfig plugin to set the anonymous_mode and force_proxy settings, this should accomplish what you want. references below

http://forum.deluge-torrent.org/viewtopic.php?f=9&t=42887 http://www.libtorrent.org/reference-Settings.html

comment:39 Changed 5 years ago by alaneuler

Socks5 proxy for tracker still doesn't work.

Output of deluge -v:

deluge: 1.3.15
libtorrent: 1.1.12.0

My use case is a little different, my tracker IP is banned from ISP. Feels bad about the bug existed for such a long time.

Maybe I have to give other BT client a try.

Last edited 5 years ago by alaneuler (previous) (diff)

comment:40 Changed 5 years ago by dunedune

I'm also having problems. Windows 10 fresh install, + Latest deluge 1.3.15

Setting Socks 5 proxy causes deluge to reset all preferences to default on next launch.

Last edited 5 years ago by dunedune (previous) (diff)

comment:41 Changed 4 years ago by whereupon

I am using 1.3.15 on windows 10 (pro, x64). I use SOCKS5 with authentication. "all preferences" not reset on next launch.

If I change the ip address first octet to 255, pause torrent, restart, there is no traffic as expected. Worryingly there is no popup error shown. Tracker status has an error, "socket operation was attempted to an unreachable network"

Restoring the correct address BUT also entering improper credentials does not resume data as expected. Again only pause restart updates the tracker error message, "error SOCKS authentication error"

Restoring correct credentials does not resume data until torrent paused and resumed.

Aside from requisite pause/restart this is the expected behavior.

--

Similar testing done with qBitTorrent as suggested in this thread 7 years ago.

comment:42 Changed 4 years ago by whereupon

I wanted comment 42. Also: thanks for all the fish!

comment:43 Changed 4 years ago by John007

  • Cc john.smith@… added
  • Version changed from 1.3.5 to 2.0.3

Hi, adding to this. I have the latest version of Deluge running and all latest libraries from Deluge sources VS Ubuntu. It runs perfectly EXCEPT this bug being tracked here.

  1. I can setup my Proxy Credentials just fine.
  2. I can check the two boxes, or just one box. But it doesn't stick
  3. Is there a way to do this another way? From CLI?

See the two attachments for the Version Number and the Error.

Any help on this would be appreciated.

Changed 4 years ago by John007

Deluge Version

Changed 4 years ago by John007

The Proxy Settings Dialog

comment:44 Changed 4 years ago by John007

  • Component changed from libtorrent to Plugin

Changed 3 years ago by tangles

evidence of Deluge not using proxy 2021/06/27

comment:45 Changed 3 years ago by tangles

Just thought I'd reply here to add that deluge 1.3.15 does not appear to be using my proxy settings These settings have been in place since I installed deluge months ago, all of those downloads are from within the last 24h. Surely my IP would not be showing up on iknowwhatyoudownload.com were it using the proxy? Pretty damn concerning tbh. https://dev.deluge-torrent.org/attachment/ticket/2149/deluge%20not%20using%20proxy.png

Last edited 3 years ago by tangles (previous) (diff)

comment:46 Changed 18 months ago by Awe3423

Restoring the correct address BUT also entering improper credentials does not resume data as expected. Again only pause restart updates the tracker error message, "error SOCKS authentication error" https://stcloudfencingcompany.com/vinyl-fence/

Note: See TracTickets for help on using tickets.