All trackers get connection failed #3285
Comments
|
I thought this might be symptomatic of me starting and stopping different builds. I've found a restart fixes everything. |
|
Restarting the app, even with clean slate / no ongoing transfers, does not fix it. It has been happening for a long while, several months. Usually peers are found by another way (DHT, I think? I am not an expert in torrent at all) so files can transfer at some point, but all trackers are in error. |
|
Sorry, i was meaning a computer restart :-( |
|
Two different torrent apps can connect fine to most of the trackers, in the same state. And I'm not restarting my computer, I have too many things on-going for that to happen. It does seem like a bug, anyway, if it requires a restart periodically to work. |
|
@fxcoudert this appears to be a duplicate of #2546? |
|
Uh, you're right, sorry. Well there is new information, which is other software can definitely connect from the same computer/network/settings. I have no idea how to debug, any advice is welcome. |
|
Usually I close the new issue in favor of the older one; however this one seems to be more actionable |
|
Full logs output, run with |
fxcoudert
removed
the
needs clarification
|
I've been encountering the same issue for at least a couple of months. I don't think this was happening in September 2021. |
I'm not seeing this error so I'd be happy for the help. Does seem like a pretty big ask, though. |
|
It's going to be a long work :( Technical question: if I do I can reproduce the bug with: Actually, the 3.00 binary has the same issue, so bisection is probably not the right way to go… |
|
Can you try, @fxcoudert, to change those two lines: Lines 63 to 64 in eefcbe7 To: I had a few torrents unblocked (but not all) by changing my version number: the issue could come from trackers banning us? |
|
@Coeur it did not change anything for me. |
|
Still occurring at e9a7ddf On the same machine, with this torrent:
|
|
I had this issue today, again. I tried to restart the app several times, but sadly the error kept showing up in all trackers (but tracker.gbitt.info:80, which retrieved clients that were not connected with, I don't know why). Instead of restarting the computer as I usually do, I tried to modify Transmission settings and restart the app, doing it one by one to find anything that could fix it. The first thing I changed was the listening port to a random one. That worked. |
|
I am also having this problem with many of the recent v4 for mac nightly builds. very annoying. Not an issue with other BT clients. Never had this issue on version 3.0 on my old intel mac. |
|
I also have that problem now, it was working fine some weeks ago. I solved it by not using Transmission from docker and use the Synology community package. I get this errors (not solved with docker and container restarts) |
|
I still get this problem with Transmission 4.0.0-beta.3 (634b1e8). It makes Transmission unusable for me. I have used different other clients with no issue, on the exact same torrents, same network, etc. The tracker says |
|
@fxcoudert Hmmm 🤔 the torrents you shared earlier are working for me. Also from your log messages above it looks like DHT is working for you, and DHT uses UDP for package transport, so it's apparently not a firewall issue. OK, I am just guessing here on how I would start tracking this down this if I were on a system where I could reproduce the problem.... Since we know UDP packets are working, but announcing via UDP isn't, my guess is that either DNS lookup is failing or we're not able to send a connect request to the tracker. Let's find out if either of those are the case. Try building with these tracers so we can see what announcer-udp is up to: Also if it is a DNS failure, try running |
|
Please see #5146 And, fwiw, I'm seeing the problem with both udp and http trackers. eg: http://tracker.trackerfix.com:80/announce What can we provide to help nail down this issue? |
|
Hi! Ubuntu 22.04 / Transmission 3.0 |
|
al3xtjames' solution worked for me-- I had another application listening on the port Transmission was trying to use. That could explain why a reboot is fixing it for some. Not to say that someone else isn't experiencing a resource leak of some kind, but in my case it was a simple port conflict. |
|
Same for me. While transmission (4.0.2 and 4.0.3) seems to get banned on most public trackers, Utorrent works on the same machine at the same time |
|
Not sure if this is completely related but while downloading, I quite often will notice that after several hours I am connected to perhaps “3 of 7 peers” and the download rate is at a crawl. Trying to update the trackers does nothing or fails but simply closing Transmission and reopening it results in a huge boost in peers. I’m guessing the trackers update correctly at that point and suddenly I’m connected to 20 of 50 peers” or whatever - in any case: significantly more than before. This is consistent and repeatable in my case. Edit: I should also note that I do not need to down my network connection as others have mentioned. I quit and then immediately start up again. |
|
Hi, I can definitely confirm that this is a bug. It only occurs if: 1.) bind-address-ipv4 is 0.0.0.0 or 127.0.0.1 Solution: Use the IP address associated with your default interface as bind-address-ipv4. For example, if your traffic goes through eth0, and eth0 has the IP address 192.168.1.100, then this IP address should be used as bind-address-ipv4. What happens under the hood is this: The transmission daemon code needs to be modified so that the socket is bound to the default interface when connecting a tracker over tcp. |
|
Hum, 0.0.0.0 is the default: |
|
I have updated my previous comment and added this line: 2.) bind-address-ipv6 is fe80:: fe80:: is often used to disable ipv6, it's still a bug, because setting bind-address-ipv6 to fe80:: should not affect ipv4 connections, but it does affect it. There is no bug if bind-address-ipv6 has the default value :: |
|
This is still happening on the latest version of Transmission Qt (openbittorrent is dead, but opentrackr isn't). |
|
It helped me to change incoming port. Maybe it was a coincidence tho |
|
@LunarN0v4 Open Command Prompt and run netstat -ab, take a look and see if your Transmission listening port is being used by another program, if it is, change the port and try again. |
@m4dm4x1337 Are you saying this issue occurs if ALL or ANY of your points are true? I am still experiencing this issue with http trackers but my IP bindings are not set as you describe. settings.json: transmission.log: |
|
@mtraynor7 It happens if all 3 points are true. fe80:: is used to disable IPv6 and that somehow causes TCP4 connections to an http tracker to be bound to the loopback interface. The docs say that libcurl is used under the hood ( https://github.com/transmission/transmission/blob/main/docs/Environment-Variables.md ), and if TR_CURL_VERBOSE is set to 1, additional debug information is logged. I testet this a while ago and the error messages I saw were the same as the ones in my example above (“Invalid argument”). That's why I'm sure TCP4 connections are bound to lo when bind-address-ipv6 is fe80:: IPv6 settings shouldn't affect TCP4 connections, so that's a bug... |
@m4dm4x1337 You are literally telling Transmission to bind to the loopback interface when you specify It sounds like you've got both IPv4 and IPv6 public Internet, so if you set Maybe scraping can be done better, but I think this is a normal result. |
@tearfur It is not a normal result or the expected behaviour. First, you need to understand why people are using fe80:: as bind-address-ipv6. Some people, like me, for example, disable IPv6 for security reasons on the kernel level by adding "ipv6.disable=1" to the kernel cmdline. Any IPv6 related commands or function calls will not work on such a system. Unfortunately, transmission is/was unable to handle that correctly (See Issue #86). To get around this other issue, people have used fe80:: as bind-address-ipv6 so that transmission doesn't try to make IPv6 connections. It looks like this other bug was recently fixed. But even if that bug has been fixed, the conclusion that an IPv4 connection must be bound to the lo interface just because the IPv6 address is also bound to lo, is incorrect. It is absolutely possible and permissible that IPv4 and IPv6 are bound to different interfaces. There are certainly many reasons why someone would use fe80:: as bind-address-ipv6, for example, maybe you simply want to temporarily disable IPv6 for a specific reason. I recommend testing it yourself. Use the values "bind-address-ipv6": "fe80::" and "bind-address-ipv4": "0.0.0.0" and then add HTTP trackers to the tracker list of your torrent. Preferably those that do not have AAAA DNS records and therefore no IPv6 addresses. Because then the incorrect behavior becomes more clear. What will happen is that all HTTP tracker connections will fail, even though IPv4 is bound to all interfaces due to the 0.0.0.0 address. And that's buggy behavior, not normal behavior :) The correct behaviors would be to: 1.) Let libcurl decide which IP protocol version to use and which interface to bind to. I could bet that there is a code snippet in the transmission that causes explicit binding for IPv4 connections based on (wrong) IPv6 properties. |
|
I'd like to make it clear that I understand the need for some people to disable IPv6, and though we do not have any official way to do that right now, I'm not arguing against it either.
Yes I did test on 8e7fc76 before writing #3285 (comment). Like I said, IPv4 announce will succeed, while IPv6 announce and scrape will fail.
I reproduced your IPv4 I'm very curious why you've suggested binding to
Absolutely, and I think we have that currently.
To my best knowledge, if there is a bug, you'll be able to find it if you start around here and trace upwards in the call stack: transmission/libtransmission/web.cc Line 309 in 1de6e93 transmission/libtransmission/web.cc Line 322 in 1de6e93 Please feel free to take a look. |
transmission: set container IP transmission: set ipv4 in settings.json; fixes unable to scrape issue transmission/transmission#3285 (comment)
|
I have the same issue (running 4.0.6 from NixOS repos). |
In my case it was caused by the fact that Transmission could not access Something similar might be happening on other distribution. If you experience this - check the contents of your Tranmission's |
|
|
|
@radicalaction An HTTP code starting with a 5, like 521, means it's an issue on the server/tracker side, not the client side. |
Seems that you're right. Thanks! |
|
Hello, I'm in the same situation here. |
|
I am also affected by this issue. With the latest |
|
same here using 4.0.6 (38c1649) in a container (lscr.io/linuxserver/transmission:latest). I can resolve dns (e.g. ping github.com) from inside the container without any problems. setting the container to a static IP address and "bind-address-ipv4" to that address does nothing. |
|
I had the same issue. I'm using Transmission-qt v4.0.6 (38c1649) on a PC with Windows 11. I opened settings.json located in C:\Windows\ServiceProfiles\LocalService\AppData\Local\transmission-daemon. There I changed "bind-address-ipv4": from "0.0.0.0", to "MyIPAddress". Then restarted the transmission daemon and EUREKA!!!!! Everything is working like a charm |
Nevermind, the issue was the way I had my container set up. When I had it in a network I use for a few containers, including flexget, it couldn't connect to udp trackers but If I create the container using the default podman network (no --net ...) in podman 5.2.3 it works flawlessly, |
Using docker image linuxserver/transmission Version 4.0.6-r0-ls272 Exactly the same happened to me, changing binding address to the specific docker ip assigned address, and trackers connections started working. |
and others
Opening a magnet link in Transmission very often leads to no peers being obtained, because none of the trackers can be connected to:
On the same machine, same network, opening the same magnet link with another client will show most of the trackers are actually online and working:
The text was updated successfully, but these errors were encountered: