Opened 12 years ago

Last modified 10 years ago

#3528 reopened Bug

TR_PREFS_KEY_BIND_ADDRESS_IPV4 breaks IPv6-only trackers

Reported by: jch Owned by: charles
Priority: Normal Milestone: None Set
Component: libtransmission Version: 2.04
Severity: Normal Keywords: backport-2.1x backport-2.0x
Cc: transmission@…, transmissionbt@…


As pointed out by liudongmiao in , the code checking for TR_PREFS_KEY_BIND_ADDRESS_IPV4 in web.c:createEasy assumes trackers only use IPv4. Hence, setting this flag breaks IPv6 trackers.

I don't see a good solution (but I haven't looked at curl's more exotic options yet). Liudongmiao suggests simply ignoring BIND_ADDRESS for tracker connections, which is obviously not optiomal.


Attachments (1)

interface.diff (3.8 KB) - added by charles 12 years ago.
possible implementation of Harry's second suggestion

Download all attachments as: .zip

Change History (15)

comment:1 Changed 12 years ago by Harry

  • Cc transmission@… added


I discussed this problem with some people (mainly MorkBork? @ #IPv6), and the following methods of fixing have been suggested (ordered from "cleaner way" to "most dirty way"):

1) Get cURL to support multiple --interfaces. I don't know if this will happen in the near future, but it'd be the cleanest way to "solve" the problem whilst not breaking any functionality. ( ).

2) A dirty way that will work for most people would be to not even call --interface in the cURL call, IF the user has the bind-address-* values are at the default ("bind-address-ipv4": "" and "bind-address-ipv6": "::"). Most people will have these at the default wildcard interface, - those who don't will not have v6 tracker access. Yes, it's pretty silly to only "partially" fix a problem, but I think it's the best short-term solution. (Explained simpler: if they have the default bind values set, do not use --interface in the Transmission cURL request at all).

3) Do a DNS request with v4 off the bind-address-ipv4 interface - if it returns an AAAA, it will connect to the tracker via the bind-address-ipv6 interface; else use bind-address-ipv4 if you only get an A record. This method is not that good because it will be a lot harder to write it into Transmission, and might cause some unwanted problems.

I really hope this bug can be fixed soon. I hope these brainstorms can work. Option number 2 is probably the best short-term fix.

Last edited 12 years ago by Harry (previous) (diff)

comment:2 Changed 12 years ago by neufeind

  • Cc transmissionbt@… added

*argh* I've just been bitten by the same problem ... until I finally found this ticket. Commenting out the two lines (as written in the forum) did the trick here.

I agree that method 2 seems the quickest catch for now and should already solve most of the problems. So it would be really great if you could at least get that one in shortly.

About method 3 I don't see big problems there. If AAAA is returned, connect using IPv6 - fine in my eyes.

comment:3 Changed 12 years ago by haohaolee

Why not first try to bind to ipv4 address, then check the curl error, if cannnot bind, then bind to ipv6 address. I have encountered this problem, and use the 2nd dirty patch to work around. The above is my thought, and I'm not familiar with cURL

comment:4 Changed 12 years ago by charles

  • Keywords backport-2.1x backport-2.0x added
  • Milestone changed from None Set to 2.20
  • Owner set to charles
  • Status changed from new to assigned

Transmission's use of CURLOPT_INTERFACE comes from #2412:

My server has a ip alias address, the T daemon is use this alias (set in config file with bind-address-ipv4). But i notice, the tracker say me passive mode. Becuse in tracker announce we send only the ip, but announce use different ip (the interface default address).

There are 2 solution: send the ip address in tracker announce, or curl sould use bind address too.

But in my test, sendin my ip in tracker announce doesnt work (or i made a mistake), so i made a patch to bind curl to bindaddress.

Some trackers don't support ip=X in the announce, so using CURLOPT_INTERFACE seems like a good way to address #2412, even though it's not perfect.

Overall I like Harry's summary. I agree that (1) would be nice, as it seems to address the problem at the right level in the toolchain. (2) is a good short-term fix. (see patch.) (3) seems undesirable, especially since libcurl is already doing some sophisticated DNS handling and caching, so why should Transmission reinvent the wheel?

Changed 12 years ago by charles

possible implementation of Harry's second suggestion

comment:5 Changed 12 years ago by charles

Could someone review this and/or test it out on their systems before I commit this?

The patch uses the ipv4 address if it differs from the default. Otherwise, it uses the ipv6 address if it differs from the default. Otherwise, it uses nothing.

Any opinions on whether that second step -- using a custom ipv6 address -- is a good or bad idea?

comment:6 Changed 12 years ago by charles

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

r11610: suggestion (2) added to trunk

r11611: 2.1x

r11612: 2.0x

comment:7 Changed 12 years ago by jordan

  • Component changed from Transmission to libtransmission

comment:8 Changed 12 years ago by Harry

  • Resolution fixed deleted
  • Status changed from closed to reopened

Hi, I was thinking again about this today, and a thought popped into my head. Why doesn't transmission just announce twice per address; once forcing IPv4 (-4 flag on curl), and one forcing IPv6, whilst assigning themselves to the related bind-address-ipvX they require?

:~$ curl -vvv -6 --interface 2001:db8::1234
* getaddrinfo(3) failed for
* Couldn't resolve host ''
* Closing connection #0
curl: (6) Couldn't resolve host ''

See, that is expected, and it fails nice and quick if there are no AAAA records to attempt to connect to, when using -6. Vice-versa with -4.

Only disadvantage I see with this is a small increase in syscalls, but I think it's a "nicer" solution then what was committed, and also solves the issue with "split swarm pools" for dual-stacked tracker domains.

Thoughts/criticism on this new suggestion? Am I insane, or is this not a better solution then the current method transmission uses?

comment:9 follow-up: Changed 12 years ago by jordan

It's not a bad idea, but I don't see what's so wrong with the current approach? Are there any real-world observations of split swarm pools not resolvable by PEX and DHT?

comment:10 in reply to: ↑ 9 Changed 12 years ago by Harry

Replying to jordan:

Are there any real-world observations of split swarm pools not resolvable by PEX and DHT?

Private-flagged torrents. :) And yes, there are a few private trackers using dual-stacked domainnames (that I could name - but won't for obvious reasons), and there should be many more in the following years.

comment:11 Changed 11 years ago by Harry

  • Milestone 2.20 deleted
  • Version changed from 2.04 to 2.50

Was there some sort of regression with this from ~2.2x to 2.50? I noticed if I have "bind-address-ipv6" set to 2001:470:xxxx, and "bind-address-ipv4" set to, then announcing to IPv4 trackers does not work at all, while IPv6 ones work fine. I tried both -daemon and -cli. I get "Could not connect to tracker" if IPv6 is bound and IPv4 is not. (Not sure if I should make new ticket for this, as I think it's related to this). Basically your fix "flipped" itself around somehow...unless I'm really tired and not understanding what I suggested more than a year ago.

Perhaps it'd be a good idea to look into when someone had time. Should finally axe this issue forever with that, which will take out some other issues caused by this fix, such as

comment:12 Changed 11 years ago by livings124

  • Milestone set to 2.20
  • Version changed from 2.50 to 2.04

comment:13 Changed 10 years ago by user00265

I'm having issues connecting, but only to IPv6-only tracker. I have bind-v6 and bind-v4 set to the respective IP's (I don't want the main server IP for doing any kind of transfers).

However, I have tried various configurations outlined here and by searching Google, but nothing has allowed me to use some of these trackers. There are some I use that are dual-stack, but I didn't bother looking until now. I use dual-stack and one that has two trackers with two host names... one for v4 and one for v6.

comment:14 Changed 10 years ago by jordan

  • Milestone changed from 2.20 to None Set
Note: See TracTickets for help on using tickets.