Opened 12 years ago
Last modified 5 years 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 12 years ago by jhujhiti
- Owner changed from charles to jhujhiti
comment:2 Changed 12 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 12 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 12 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 12 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 12 years ago by kab
Same problem here. All piratebay.org downloads don't start and are broken because of IPv6
comment:7 Changed 12 years ago by charles
- Version set to 1.42+
comment:8 follow-up: ↓ 11 Changed 12 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 12 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 12 years ago by jhujhiti
- Milestone changed from 1.50 to 1.51
comment:11 in reply to: ↑ 8 Changed 12 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 12 years ago by charles
- Milestone changed from 1.51 to 1.60
comment:13 Changed 12 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 12 years ago by charles
- Version changed from 1.42+ to 1.50
comment:15 follow-up: ↓ 18 Changed 12 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 12 years ago by jhujhiti
- Milestone changed from 1.60 to Sometime
comment:17 Changed 12 years ago by charles
#2091 has been marked as a duplicate of this ticket.
comment:18 in reply to: ↑ 15 Changed 12 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 12 years ago by jch
- Cc jch@… added
comment:20 Changed 11 years ago by berni
- Cc berni@… added
comment:21 Changed 11 years ago by livings124
jhujhiti: Transmission now supports multiple trackers at the same time. Care to update your status?
comment:22 Changed 11 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: ↓ 25 Changed 11 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 11 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 11 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 11 years ago by charles
Juliusz: ping
comment:27 Changed 10 years ago by livings124
jch: ping
comment:28 Changed 10 years ago by jch
- Cc jch@… removed
comment:29 Changed 8 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 8 years ago by BlueMatt
- Cc transmission@… added
comment:31 Changed 8 years ago by kenyon
- Cc kenyon@… added
comment:32 Changed 8 years ago by Nikoli
- Cc nikoli@… added
comment:33 Changed 8 years ago by Vortigont
- Cc hotplug.ru@… added
comment:34 Changed 5 years 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.
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
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
20:26 < jhujhiti> regardless of which address family the peer is using 20:26 < erdgeist> jhujhiti: yes, thats not good