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

[lildadou]

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.

[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

[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.

[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.

[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. :)

[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).

[lildadou]

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)

[lildadou]

Should I open a new report for the 2.33 version?

[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).

[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)

[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.

[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.

[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.

[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.