Opened 8 years ago

Last modified 3 years ago

#4327 new Bug

Could not connect to tracker when IPv6 binding have not a Global scope

Reported by: lildadou Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.31
Severity: Normal Keywords: ipv6
Cc: hotplug.ru@…, moo.tinys@…

Description

In seeking to disable IPv6 for transmission, I put the value of bind-address ipv6 to "::1". Since then, transmission is no longer able to connect to trackers.

Change History (16)

comment:1 Changed 8 years ago by lildadou

Replying to livings124:

No, this ticket covers it. Version indicates where the issue first appeared. If we updated the version to the current version for all issues whenever we release, that field would be meaningless (all open tickets would have the same version, or they wouldn't be open).

Edit: Note, this is my point of view

Last edited 8 years ago by lildadou (previous) (diff)

comment:2 follow-up: Changed 8 years ago by Username

Stupid UDP protocol does not supports IPv6 at all. Probably that's why :)

P.S. as for me, you will get a better results with iptables + protocol type + something like (allow/deny) PID of process, for example, if you really need to reach such stupid/uncommon goal at any price.

comment:3 in reply to: ↑ 2 ; follow-up: Changed 8 years ago by x190

Replying to Username:

Stupid UDP protocol does not supports IPv6 at all. Probably that's why :)

P.S. as for me, you will get a better results with iptables + protocol type + something like (allow/deny) PID of process, for example, if you really need to reach such stupid/uncommon goal at any price.

Seems I had the same stupid/uncommon goal. :lol:

lildadou: Try commenting out/removing the code block at Line 204-212 in session.c.

Last edited 8 years ago by x190 (previous) (diff)

comment:4 in reply to: ↑ 3 Changed 8 years ago by lildadou

Replying to Username:

Stupid UDP protocol does not supports IPv6 at all. Probably that's why :) P.S. as for me, you will get a better results with iptables + protocol type + something like (allow/deny) PID of process, for example, if you really need to reach such stupid/uncommon goal at any price.

I think that block requests, in one way or another, will produce the same results.

Replying to x190:

Seems I had the same stupid/uncommon goal. :lol:

lildadou: Try commenting out/removing the code block at Line 204-212 ( in session.c

If I have to put my hands in the source will be to make the optional IPv6 officially. :)

Last edited 8 years ago by lildadou (previous) (diff)

comment:5 Changed 8 years ago by Username

I think that block requests, in one way or another, will produce the same results.

Sure. But as for me, it's actually disadvantage of udp trackers that they do not support IPv6. If this is not corrected, they have no future. IPv4 address pools exhausted, so there will be NATs and other torrent-unfriendly stuff. As for me, such protocol makes little sense in long term (not to mention torrent can already run without trackers at all due to DHT).

comment:6 Changed 8 years ago by lildadou

  • Summary changed from Could not connect to tracker when bind [::1] IPv6 address to Could not connect to tracker when IPv6 binding have not a Global scope
  • Version changed from 2.31 to 2.33

Hello, the bug is still present so I update the ticket. I noticed that this bug also produced if I bind [fe80::] interface (scope:link-local)

comment:7 Changed 8 years ago by livings124

  • Version changed from 2.33 to 2.31

comment:8 Changed 8 years ago by lildadou

Should I open a new report for the 2.33 version?

comment:9 follow-up: Changed 8 years ago by livings124

No, this ticket covers it. Version indicates where the issue first appeared. If we updated the version to the current version for all issues whenever we release, that field would be meaningless (all open tickets would have the same version, or they wouldn't be open).

comment:10 in reply to: ↑ 9 Changed 8 years ago by lildadou

Replying to livings124:

No, this ticket covers it. Version indicates where the issue first appeared. If we updated the version to the current version for all issues whenever we release, that field would be meaningless (all open tickets would have the same version, or they wouldn't be open).

But if the version is old, one can believe that the bug has been fixed unless the ticket was taken over by a developer. Edit: Thank you for these details (bellow)

Last edited 8 years ago by lildadou (previous) (diff)

comment:11 Changed 8 years ago by livings124

If it was fixed, the ticket wouldn't be open.

Version - where the issue was first noticed
Milestone - when it was/will be fixed
Status (new, closed, etc.) - if it's still an issue

If a ticket is open, it's not fixed in the current version. No reason to set the version of all open tickets to the current version; that just gives us less information.

Last edited 8 years ago by livings124 (previous) (diff)

comment:12 Changed 7 years ago by Vortigont

Just FYI. The same issue exist in the opposite direction. If I disable ipv4 by binding v4 to 127.0.0.1 - transmission will be unable to connect to any ipv6 tracker this time. But at the same time it is able to do peer connections and upload/download with peers discovered via DHT or PEX. Looks like something is wrong with those bind options and tracker announces. And I think it would be nice to have those special knobs to disable ipv4/ipv6 binding/connections.

comment:13 Changed 7 years ago by udo

Even with a global scope the ipv4 tcp stuff fails. (2.71...) This means that bind-address-ipv6 does only work while disabling ipv4 tcp trackers. You can put in ::1, a local link number, a global scope number. No more tcpv4 trackers, no more test tcp port.

Last edited 7 years ago by udo (previous) (diff)

comment:14 Changed 6 years ago by Vortigont

  • Cc hotplug.ru@… added

comment:15 Changed 5 years ago by moo

  • Cc moo.tinys@… added

comment:16 Changed 3 years ago by ejona86

I was bit by this as well, but when using a global scope ipv6 address against an ipv4-only tracker. I also noticed testing the tcp port was broken.

Looking at the source it seems likely caused by the CURLOPT_INTERFACE configuration. I didn't try commenting out the check and testing, so I have not confirmed the curl configuration is the culprit.

createEasy really wants something like CURLOPT_DNS_LOCAL_IP{4,6} so that it can set the address of family individually and let curl attempt both families. Instead, it seems web.c would have to try the task twice any time bind is specified, one for each address family. If bind is only specified for one address, then it would need to use CURLOPT_IPRESOLVE. If no bind is specified, it could choose to only make one attempt.

Note: See TracTickets for help on using tickets.