IPv6 does not work against dual-stacked trackers

[mikal]

I get no response from tracker when I use the new beta2 build. When I replace tracker.thepiratebay.org with the ipv4 address it starts recieving responses.

[jhujhiti]

I'm curious how many users are experiencing this. Can I see a few "me too" posts here?

I'm pasting this as a note to myself: 20:25 < jhujhiti> erdgeist: so proper behavior would be to do the entire

libcurl mess twice, and, what, just ignore it if one of the protocols doesn't work?

20:25 < erdgeist> jhujhiti: yes 20:25 < erdgeist> jhujhiti: You'll have to do the same considerations with pex 20:25 < erdgeist> jhujhiti: whom to exchange which peers with 20:26 < jhujhiti> yes, as it stands now we just pick some v4 and v6 peers and

put them in proper dictionaries

20:26 < jhujhiti> regardless of which address family the peer is using 20:26 < erdgeist> jhujhiti: yes, thats not good

[mikal]

There seem to be a problem with thepiratebay, it is not accepting connections. There is en entry in their blog about ipv6 which contains some relevant comments.

​http://thepiratebay.org/blog/146

telnet -6  tracker.thepiratebay.org 80
Trying 2a01:298:3:1::2...
telnet: Unable to connect to remote host: Connection timed out

telnet -4  tracker.thepiratebay.org 80
Trying 77.247.176.138...
Connected to tracker.thepiratebay.org.
Escape character is '^]'.
GET /
HTTP/1.0 404 Not Found
Content-Type: text/html
Connection: close
Content-Length: 25

<title>Not Found</title>
Connection closed by foreign host.

[bouilloire]

It does reply, it is just a little bit overloaded, so it takes time to establish the connection.

$ telnet tracker.thepiratebay.org 80
Trying 2a01:298:3:1::2...
Connected to tracker.thepiratebay.org.
Escape character is '^]'.
GET / HTTP/1.0
HTTP/1.0 404 Not Found
Content-Type: text/html
Connection: close
Content-Length: 25

<title>Not Found</title>
Connection closed by foreign host.
$

I can't test right now whether transmission works with this tracker or not. I will try that and report next week, if no one has done it before :)

[mikal]

The problem as I see it that if the ipv6 connection fail, an ipv4 connection is never attempted.

[Habbie]

I can't download anything from thepiratebay since they added AAAA records. My machine is IPv6-enabled. I'm running Transmission 1.42.

Adding the piratebay hostnames to /etc/hosts with one of their v4 addresses works for me, as a workaround.

[kab]

Same problem here. All piratebay.org downloads don't start and are broken because of IPv6

[dschlenker]

Is this necessarily a bug in transmission, or a problem with thepiratebay.org?

Perhaps it would make sense to include an option in preferences to fall back to IPv4 if IPv6 fails, but not all users may want this.

[mikal]

My problem was that the tracker was unreachable due to a routing problem with my 6to4 tunnel. I would like to see a connection retry to the ipv4 address after the first timeout. I cannot see why anyone would NOT like that.

[mercurix]

Replying to dschlenker:

Is this necessarily a bug in transmission, or a problem with thepiratebay.org?

I see the problem with an IPv6-only tracker I set up myself too. The bug must have appeared lately as the beta 1.42+ (7812) still works quite well for me on Mac OS X.

[praseodym]

These seem two separate problems: Transmission not working with IPv6 trackers because it will not properly connect to the tracker, and problems related to broken IPv6 connectivity. I have tried the latest Transmission nightlies with the the SixXS IPv6-only tracker (​http://www.sixxs.net/tools/tracker/) and Transmission will not correctly scrape the server, while my IPv6 connectivity is fine (i.e. the former of the two problems). All it gives me is a "No Response (0)" error.

[jhujhiti]

Brief explanation for posterity and those out of the loop: In libTransmission (pre-1.60?, that's the plan anyway) "torrent" and "tracker" are used interchangeably. With the addition of IPv6 support, the two concepts need to be separated. This is a fairly major refactoring job. For 1.5x and in trunk currently, IPv6 DNS resolution in libcurl (the library we use for tracker communication) is disabled to prevent breakage of trackers with AAAA and A records on the same hostname (notably, TPB). For those of you coming here from #1937, the curl option to disable IPv6 "DNS resolution" apparently also causes curl to bail if given an explicit IPv6 tracker address (such as ​http://[::1]/announce), so that bug is the same as this one.

[charles]

#2091 has been marked as a duplicate of this ticket.

[jch]

Replying to jhujhiti:

With the addition of IPv6 support, the two concepts need to be separated.

Not necessarily. A simple solution is to simply attempt an IPv4 connection, and fall-back to IPv6 if it fails.

Note that this is the opposite of the default behaviour for double-stack hosts. The reason is that if we connect over IPv4, we can reliably provide our IPv6 address to the tracker (see #2112). OTOH, if we connect over IPv6, we cannot easily find out our global IPv4 address (we're most probably behind NAT).

--Juliusz

[livings124]

jhujhiti: Transmission now supports multiple trackers at the same time. Care to update your status?

[berni]

Anything going on regarding this bug?

We have deployed the 26C3 conference recordings on an additional IPv6-only tracker (with multi-tracker extensions) and it works fine, except for Transmission. Completely non-fatal except for IPv6 only hosts (and those can use DHT in the future), but a fix would be highly appreciated nevertheless.

jch's suggestion looks good. Or maybe even just attempt two connections to the tracker, one with forced IPv4 and one with forced IPv6. OTOH the only public tracker I know which was dualstacked and caused this problem to appear (Piratebay) has ceased existence anyway.

[jch]

Anything going on regarding this bug?

I'll start working on this as soon as 1.80 is out. (1.80 is long overdue, so I'm currently refraining from submitting any new patches to Charles. And I've got quite a few already in my private repository.)

OTOH the only public tracker I know which was dualstacked and caused this problem to appear (Piratebay) has ceased existence anyway.

It can be expected that dual-stack trackers will generalise over the next years, so any solution that's inefficient with such trackers is not a good idea.

--Juliusz

[charles]

Replying to jch:

Anything going on regarding this bug?

I'll start working on this as soon as 1.80 is out. (1.80 is long overdue, so I'm currently refraining from submitting any new patches to Charles. And I've got quite a few already in my private repository.)

Juliusz, are you still planning on working on this ticket? Is this still an issue in 1.92 now that the libcurl glue code is somewhat less awful?

[charles]

Juliusz: ping

[livings124]

jch: ping

[udo]

Also, when specifying any local ipv6 via bind-address-ipv6 in settings.json, the outgoing ipv4 (!) connections to trackers fail. I.e.: no more '::' for bind-address-ipv6 and tcpv4 trackers are no-go.

[x190]

Does anyone still consider this an issue? Libcurl tries both v4 and v6, if both are available and one or the other is unsuccessful.