The issue boils down to all trackers reporting issues connecting (potentially related to #3285):
As well as the port test failing (which it really shouldn't):
As expected on the IPv6 only network all the IPv4 requests to the trackers get errors (here EINVAL):
At this point the IPv4-only trackers of course bail out.
However other trackers (exodus.desync.com for instance) should work fine considering they have a valid public IPv6 address, which doesn't seem to be the case though:
Prior Troubleshooting
I have tried so far:
setting IPv4 binding to 127.0.0.1 (I don't want it to use IPv4 but IIRC setting something invalid caused even more issues) and IPv6 to ::
setting IPv6 binding to the actual IPv6 address
setting the DHT announce to be enabled and using the public IPv6 address
The Network Setup™
While there are IPv4 addresses on multiple interfaces I do not want Transmission to use those for legal reasons, and also just because I don't like IPv4.
The one address that transmission is supposed to use is added to the loopback interface lo, and has multiple routes, including a default route, each using two nexthops and a src attribute to loadbalance the traffic over the attached 10G links:
default proto bird src [REDACTED] metric 32 pref medium
nexthop via fe80::[REDACTED] dev enp5s0d1 weight 1
nexthop via fe80::[REDACTED] dev enp5s0 weight 1
Note that enp5s0d1 and enp5s0 are "blank" in terms of addresses:
0: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
inet6 fe80::[REDACTED]/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
11: enp5s0d1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
inet6 fe80::[REDACTED]/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
The setup is fully routed over the IPv6 link-local addresses, link-layer (and by extension Ethernet addressing) extends only onto those individual cables, there is no further Ethernet.
OSPFv3 is taking care of distributing the routes, which means that the public IPv6 address which is assigned to lo is properly distributed across the network, and is publicly reachable globally.
The port check confirms this when run via curl:
However when I do run the port test via the GTK interface the interface reports the port as closed and there is no IPv6 packet (either TCP or UDP) arriving on any of the interfaces, indicating that transmission does not actually initiate a port check via IPv6.
I assume that the trackers not being reachable is caused by the same underlying problem.
There is literally no firewall. At all. This device is on the public internet.
TL;DR
Transmission fails to connect to IPv6 trackers or check the port using the port tester when provided with a public IPv6 address attached to lo and appropriate bidirectional routes on the device itself and the attached switches/routers, despite being provided the public IPv6 address in its configuration.
If you need any further information, I'll be happy to provide it.
What is the issue?
Quick Outline
The issue boils down to all trackers reporting issues connecting (potentially related to #3285):
As well as the port test failing (which it really shouldn't):
As expected on the IPv6 only network all the IPv4 requests to the trackers get errors (here
EINVAL):At this point the IPv4-only trackers of course bail out. However other trackers (
exodus.desync.comfor instance) should work fine considering they have a valid public IPv6 address, which doesn't seem to be the case though:Prior Troubleshooting
I have tried so far:
127.0.0.1(I don't want it to use IPv4 but IIRC setting something invalid caused even more issues) and IPv6 to::The Network Setup™
While there are IPv4 addresses on multiple interfaces I do not want Transmission to use those for legal reasons, and also just because I don't like IPv4. The one address that transmission is supposed to use is added to the loopback interface lo, and has multiple routes, including a default route, each using two nexthops and a src attribute to loadbalance the traffic over the attached 10G links:
Note that enp5s0d1 and enp5s0 are "blank" in terms of addresses:
The setup is fully routed over the IPv6 link-local addresses, link-layer (and by extension Ethernet addressing) extends only onto those individual cables, there is no further Ethernet. OSPFv3 is taking care of distributing the routes, which means that the public IPv6 address which is assigned to lo is properly distributed across the network, and is publicly reachable globally. The port check confirms this when run via curl:
However when I do run the port test via the GTK interface the interface reports the port as closed and there is no IPv6 packet (either TCP or UDP) arriving on any of the interfaces, indicating that transmission does not actually initiate a port check via IPv6. I assume that the trackers not being reachable is caused by the same underlying problem.
There is literally no firewall. At all. This device is on the public internet.
TL;DR
Transmission fails to connect to IPv6 trackers or check the port using the port tester when provided with a public IPv6 address attached to lo and appropriate bidirectional routes on the device itself and the attached switches/routers, despite being provided the public IPv6 address in its configuration.
If you need any further information, I'll be happy to provide it.
Which application of Transmission?
GTK+ app on Linux, BSD, etc.
Which version of Transmission?
4.0.4