Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#3117 closed Bug (fixed)

regression: tracker queries don't honor bind-address-ipv4

Reported by: assar Owned by: charles
Priority: Normal Milestone: 1.93
Component: libtransmission Version: 1.92
Severity: Normal Keywords:
Cc: hakim

Description

In version 1.92 announces and scrapes do not honor the bind-address-ipv4 setting any more. Trackers see me as not connectable, and other peers can't connect since they've been given the wrong IP by the tracker(s). This has been a problem before on Transmission, but was fixed for version 1.80 (#2412). In 1.92 the problem resurfaced. transmission-remote -pt says the the port is not open, consistent with the announce coming from the wrong IP (however, I don't know if these queries share implementation with the tracker queries).

I'm using Linux and a vpn tunnel service. Since my modem chokes under too much pressure, the vpn tunnel is dropped regularly. To work around this instability, I've set up a dummy interface on a random but static rfc1918 address, which I set in the bind-address-ipv4 setting. Using some policy routing and iptables tricks this has always worked perfectly for any torrent client with the bind-address-ipv4 kind of setting. It has worked consistently for Transmission torrent traffic; it has worked for some time for DHT traffic (since #2312 was fixed?); it did work for tracker queries from 1.80(ish) to 1.91(ish), but not any more on 1.92.

Currently I'm solving this with even more policy routing, but that requires a bit of work.

(Setting Component to libtransmission, following #2412).

Change History (17)

comment:1 Changed 8 years ago by hakim

  • Cc hakim added
  • Priority changed from Normal to Highest
  • Severity changed from Normal to Blocker

Please fix. Torrents from private trackers don't work because of this bug.

comment:2 Changed 8 years ago by charles

  • Priority changed from Highest to Normal
  • Severity changed from Blocker to Normal

comment:3 Changed 8 years ago by charles

One thing you could do that would help track this down is to find out which release of Transmission reintroduced this problem. For example did it work in 1.91? Or 1.90? etc.

comment:4 Changed 8 years ago by assar

I did some testing. I removed the policy routing rules that I've set up for the openbittorrent trackers, downgraded to 1.91 and restarted Transmission. Tested a few times with two different torrents with the openbittorrent trackers in the torrent file announce field. The announces did work properly. I was unsure whether the policy routing rules were cached somewhere, so I upgraded to 1.92 again and restarted - and announces went out on the wrong interface (also verifying that the policy routing rules were not cached).

So, to conclude, it works properly in 1.91, but not in 1.92.

comment:5 Changed 8 years ago by assar

Some further info... I was doing some strace:ing to see if I could find out what was happening during SIGHUP:ing (#3078). In the log from one of the threads, I noticed that it did bind a socket to my rfc1918 address, a socket which was then used to do an announce. This was _after_ I had done a SIGHUP, and no longer had a listening socket.

So, I deleted the policy routing rule for a tracker and waited for an announce; and it did go out on the right interface.

After restarting transmission-daemon (to get a listening socket again) I strace:d again, and noticed that when setting up sockets for announcing, it does _not_ do the bind() call (for announces), and the announces go out on the wrong interface.

Why does it work after a SIGHUP? Or is the question, why does it work when it has no listening socket? (Long shot alert, since I have no knowledge on this level of socket programming: is it a reuseaddr issue?)

I hope this is useful information :)

comment:6 Changed 8 years ago by charles

If I were to make a change in svn, would either of you be able to make a build to test it?

comment:7 Changed 8 years ago by assar

I would definitely make an attempt at it :)

Edit: I will most definitely be able to do it, have a PKGBUILD (Arch Linux) working right now.

Last edited 8 years ago by assar (previous) (diff)

comment:8 Changed 8 years ago by charles

Another question -- could you please attach to this ticket a log of tracker announce under 1.91 and 1.92 to some torrent on www.legaltorrents.com when running Transmission with the TR_CURL_VERBOSE=1 environment variable set s.t. curl dumps the announce information to the terminal? I'd like to see the differences between 1.91 and 1.92 wrt this ticket.

comment:9 Changed 8 years ago by assar

Okay, I stopped all running torrents and ran transmission-daemon with TR_CURL_VERBOSE=1, and then added a torrent from legaltorrents.com. Transmission did a bunch of scrapes for the stopped torrents while announcing to the legaltorrent tracker, so the output seems a bit out of order (multiple threads?), but this is the difference I spotted.

In the 1.92 output, the initial lines are

* About to connect() to tracker001.legaltorrents.com port 7070 (#5)
*   Trying 8.12.35.122... * Connected to tracker001.legaltorrents.com (8.12.35.122) port 7070 (#5)

and in the 1.91 output, the initial lines are

* About to connect() to 8.12.35.122 port 7070 (#0)
*   Trying 8.12.35.122... * Name '172.20.20.20' family 2 resolved to '172.20.20.20' family 2
* Local port: 0
* Connected to 8.12.35.122 (8.12.35.122) port 7070 (#0)

and then comes the request and response headers, without differences.

The 8.12.35.122 is what tracker001.legaltorrents.com resolves to, and 172.20.20.20 is the IP of the dummy interface.

comment:10 Changed 8 years ago by charles

02:32:46 < CIA-40> charles * r10535 libtransmission/ (session.c web.c web.h): (trunk libT) #3117 "Tracker queries do not honor bind-address-ipv4" -- possible fix

assar: does this resolve the problem for you?

comment:11 Changed 8 years ago by charles

  • Keywords backport-1.9x added
  • Milestone changed from None Set to 2.00
  • Status changed from new to assigned

comment:12 Changed 8 years ago by assar

Yes, it does appear to be working now, thanks a lot! :)

comment:13 Changed 8 years ago by charles

  • Resolution set to fixed
  • Status changed from assigned to closed

comment:14 Changed 8 years ago by charles

  • Resolution fixed deleted
  • Status changed from closed to reopened

#3181 has been closed as a duplicate of this ticket.

r10535 introduced a new crash-on-shutdown error reported by Waldorf in #3181.

comment:15 Changed 8 years ago by charles

  • Resolution set to fixed
  • Status changed from reopened to closed

The new crash should be fixed now in r10554.

comment:16 Changed 8 years ago by charles

  • Keywords backport-1.9x removed
  • Milestone changed from 2.00 to 1.93

16:19:48 < CIA-40> charles * r10602 /branches/1.9x/libtransmission/ (session.c web.c web.h): (1.9x libT) backport r10535 and r10554 for #3117 "Tracker queries don't honor bind-address-ipv4"

comment:17 Changed 8 years ago by charles

  • Summary changed from Tracker queries do not honor bind-address-ipv4 (again) to regression: tracker queries don't honor bind-address-ipv4
Note: See TracTickets for help on using tickets.