Opened 8 years ago

Last modified 6 months ago

#1731 new Bug

IPv6 does not work against dual-stacked trackers

Reported by: mikal Owned by: jhujhiti
Priority: Normal Milestone: Sometime
Component: libtransmission Version: 1.50
Severity: Normal Keywords: ipv6
Cc: praseodym@…, berni@…, transmission@…, kenyon@…, nikoli@…, hotplug.ru@…

Description

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.

Change History (34)

comment:1 Changed 8 years ago by jhujhiti

  • Owner changed from charles to 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

comment:2 Changed 8 years ago by 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.

comment:3 Changed 8 years ago by 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 :)

comment:4 Changed 8 years ago by mikal

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

comment:5 Changed 8 years ago by 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.

comment:6 Changed 8 years ago by kab

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

comment:7 Changed 8 years ago by charles

  • Version set to 1.42+

comment:8 follow-up: Changed 8 years ago by 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.

comment:9 Changed 8 years ago by 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.

comment:10 Changed 8 years ago by jhujhiti

  • Milestone changed from 1.50 to 1.51

comment:11 in reply to: ↑ 8 Changed 8 years ago by 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.

comment:12 Changed 8 years ago by charles

  • Milestone changed from 1.51 to 1.60

comment:13 Changed 8 years ago by praseodym

  • Cc praseodym@… added

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.

comment:14 Changed 8 years ago by charles

  • Version changed from 1.42+ to 1.50

comment:15 follow-up: Changed 8 years ago by 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.

comment:16 Changed 8 years ago by jhujhiti

  • Milestone changed from 1.60 to Sometime

comment:17 Changed 8 years ago by charles

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

comment:18 in reply to: ↑ 15 Changed 8 years ago by 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

comment:19 Changed 8 years ago by jch

  • Cc jch@… added

comment:20 Changed 7 years ago by berni

  • Cc berni@… added

comment:21 Changed 7 years ago by livings124

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

comment:22 Changed 7 years ago by 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.

comment:23 follow-up: Changed 7 years ago by 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

comment:24 Changed 7 years ago by livings124

  • Summary changed from IPv6 does not work against thepiratebay.org to IPv6 does not work against dual-stacked trackers

comment:25 in reply to: ↑ 23 Changed 7 years ago by 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?

comment:26 Changed 7 years ago by charles

Juliusz: ping

comment:27 Changed 6 years ago by livings124

jch: ping

comment:28 Changed 6 years ago by jch

  • Cc jch@… removed

comment:29 Changed 4 years ago by 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.

comment:30 Changed 4 years ago by BlueMatt

  • Cc transmission@… added

comment:31 Changed 4 years ago by kenyon

  • Cc kenyon@… added

comment:32 Changed 4 years ago by Nikoli

  • Cc nikoli@… added

comment:33 Changed 3 years ago by Vortigont

  • Cc hotplug.ru@… added

comment:34 Changed 6 months ago by 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.

Note: See TracTickets for help on using tickets.