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

[assar]

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

[hakim]

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

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

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

[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 :)

[charles]

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

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

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

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

[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?

[assar]

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

[charles]

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

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

[charles]

The new crash should be fixed now in r10554.

[charles]

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"