port closed / traders den issue

[udo]

Hello,

I am running Fedora Linux with iptables firewalls.
Despite the port being open, as confirmed by external port check sites, transmission thinks the port (6881) is closed when I test the port.
How can I find out what happens and why transmission thinks the port is closed?
I did not yet find methods to see low level logging so i used strace and wireshark to get a clue of what's going on.

Furthermore transmission cannot connect to the tracker of the tradersden. I can surf there without issue but transmission says it cannot connect.
Also here I did not find a way to get lowlevel logging so also here i used strace and wireshark to get a clue of what's going on.
Nothing yet.

What steps can I take to solve these issues?

[udo]

I am not blocking anything w.r.t. tradersden.
The tracker appears to be working for other people.
I am now running transmission 2.71, had a slightly lower Fedora-released version before. Same issues.

[udo]

BTW: Main difference: tradersden is a tcp-based tracker, the others appear to be (mostly if not all) udp.

[udo]

The debug log doesn't tell me anything more than: Could not connect to tracker.
No lower level mentions of what was tried and how it failed.

I am running Fedora 17 -updated almost daily- so I guess libcurl is up to date: libcurl-7.24.0-5.fc17.x86_64
I built transmission 2.71 from source as the repo's did not have this version yet so the code did not complain when built.

[udo]

Now that is an interesting setting!

I now see stuff like:

Code: Select all

* About to connect() to www.tracker.example.com port 80 (#1)
*   Trying 199.101.99.188...
* Name '<my local ipv6 address>' family 2 resolved to '<my local ipv6 address>' family 10
* bind failed with errno 22: Invalid argument
* Closing connection #1

I see confusion about the adresses family.
The <my local ipv6 address> address is in settings.json for "bind-address-ipv6".

When I set "bind-address-ipv6" to :: stuff starts to work again for thetradersden.
Also the TCP port is now open.
I officially declare this a bug.

[udo]

I initiated another trac ticket, referring to this thread. (old attempts are numbered 5065 and 5066)

I am quite sure the torrent is valid as with "bind-address-ipv6" set to :: all works as expected.

Additional info:
It doesn't matter whether "bind-address-ipv6" is set to the automagically configured ipv6 address or via IPV6ADDR_SECONDARIES with RFC 3484 support, the result is the same:
No working ipv4 tcp connections to tracker, no good tcp port test.

[udo]

bind-address-ipv6: String (default = "::") Where to listen for peer connections

This is for ipv6.
I see ipv4 problems correlated and very probably caused by this.
The ipv6 setting you mention is there to select another ipv6 address than the default, e.g. for some privacy.
bind-address-ipv4 is set to 0.0.0.0, the default.

I'll see what I can find in trac.

[udo]

https://trac.transmissionbt.com/ticket/4957 is closed, mentions the same ipv6 address, comment 9:

sorry, i didn't know that feature request. but i do think connection to ipv4 tracker should not fail silently.

https://trac.transmissionbt.com/ticket/4327 is funny: listening at ::1 makes it no longer able to connect to trackers. See comment 12 there.

[udo]

So this issue has been more or less known for over a year. (!)
Now where in the code should I look for cooking up a fix?

[udo]

Well, binding the ipv6 works fine.
It's some weird logic I suppose that makes it interfere with outgoing ipv4 communications.
It's the internal administration that makes it confused about ipv4 due to an explicit ipv6 number instead of a default one.
Nothing ipv6-specific.

[udo]

BTW: who is that developer? I might ask him/her.

[udo]

Oh, can I sponsor a developer to have this bug and/or the ipv6 stuff as a whole fixed?

[udo]

Thanks, PM sent.

[udo]

No response yet to the PM.
Also no email yet about the latest track issue I sent in, referring to this thread, or mail about the revival of the old two trac issues.

But we do have a track ticket: https://trac.transmissionbt.com/ticket/5071

[udo]

Developer does want to do unpaid work.

Any updates on the ticket?
ipv6 just doesn't work and ipv4 is in the same boat when we try to make ipv6 work.
This is a major issue.