Ticket #2149 (new bug)

Opened 10 months ago

Last modified 7 months ago

deluge ignoring proxy settings

Reported by: rm Owned by:
Priority: critical Milestone: not applicable
Component: libtorrent Version: 1.3.5
Keywords: proxy Cc: pterodactyle@…, shellsonthefloor@…

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?

Change History

  Changed 10 months ago by Cas

Please test with libtorrent 0.15.

  Changed 9 months ago by ku

  • priority changed from major to critical
  • cc pterodactyle@… added
  • version changed from other (please specify) to 1.3.5
  • keywords proxy added

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).

  Changed 9 months ago by Cas

  • component changed from gtkui to core

See if clearing session.state helps: #2109

  Changed 9 months 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.

  Changed 9 months 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.

  Changed 9 months 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.

  Changed 9 months 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.

  Changed 9 months 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?

  Changed 9 months 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".

follow-up: ↓ 11   Changed 9 months 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.

in reply to: ↑ 10   Changed 9 months 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?

  Changed 9 months ago by rm

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

  Changed 9 months 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.

  Changed 9 months 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.

  Changed 9 months 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

  Changed 9 months 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.

  Changed 9 months 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.

  Changed 8 months 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.

  Changed 8 months 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.

  Changed 8 months 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.

  Changed 8 months 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.

  Changed 7 months ago by Cas

  • milestone changed from 1.3.6 to not applicable
Note: See TracTickets for help on using tickets.