Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#1447 closed Bug (fixed)

Tracker request failed. Got HTTP Status Code: 0 (No Response)

Reported by: abhorredlife Owned by: charles
Priority: High Milestone: 1.41
Component: libtransmission Version: 1.40
Severity: Major Keywords:
Cc:

Description

All of the downloads get this error code.

"Error: Tracker request failed. Got HTTP Status Code: 0 (No Response)"

Transmission 1.40 on a MacBook? 2,1 OS X 10.5.5

Attachments (3)

Transmission.jpg (31.1 KB) - added by edwhittle 8 years ago.
Screen Shot
tracker.patch (4.5 KB) - added by charles 8 years ago.
possible fix
transmission_noresponse.jpg (49.6 KB) - added by lighty 8 years ago.

Download all attachments as: .zip

Change History (24)

comment:1 Changed 8 years ago by abhorredlife

  • Priority changed from High to Highest
  • Severity changed from Major to Critical

comment:2 Changed 8 years ago by livings124

  • Component changed from Transmission to libtransmission
  • Keywords 1.40 removed
  • Milestone changed from 1.40 to None Set
  • Owner set to charles
  • Priority changed from Highest to High
  • Severity changed from Critical to Normal
  • Version set to 1.40

Changed 8 years ago by edwhittle

Screen Shot

comment:3 in reply to: ↑ description Changed 8 years ago by edwhittle

  • Severity changed from Normal to Major

I am also getting this response. In the Screen Shot attachment, you can see the Heroes file is affected. Before it was fine and not giving errors. Then I changed the Peer Listening Port checkbox "Automatically Map Port" so that it would be open instead of closed that it was before. Once it was open, I got the "Error: Tracker request failed. Got HTTP Status Code: 0 (No Response)" message. Hope that helps. I am also on a Macbook running 10.5.5


Replying to abhorredlife:

All of the downloads get this error code.

"Error: Tracker request failed. Got HTTP Status Code: 0 (No Response)"

Transmission 1.40 on a MacBook? 2,1 OS X 10.5.5

comment:4 Changed 8 years ago by justin.stevens

I too was receiving the aforementioned error with Transmission 1.40 on a 'Unibody' MacBook? Pro (Late 2008) running Mac OS X (10.5.5). Port Mapping also refused to work with Transmission 1.40 similar to Bug #1446. I have had to revert to Transmission 1.34 to get things working again. Please let me know if you need me to capture anything to help you with debugging the issue.

Changed 8 years ago by charles

possible fix

comment:5 Changed 8 years ago by charles

  • Milestone changed from None Set to 1.41
  • Status changed from new to assigned

that patch has been applied to trunk in r7100

comment:6 Changed 8 years ago by charles

  • Resolution set to fixed
  • Status changed from assigned to closed

1.4x: r7103

comment:7 Changed 8 years ago by lighty

  • Resolution fixed deleted
  • Status changed from closed to reopened

I still have the same problem, transmission doesn't get a connection to any tracker. I tried different trackers, always the same problem. I'm using nightly build r7162. Setting: Macbook 2,1 OS X 10.5.5

Changed 8 years ago by lighty

comment:8 Changed 8 years ago by charles

  • Resolution set to worksforme
  • Status changed from reopened to closed

I'm not seeing this problem...?

comment:9 Changed 8 years ago by tokyovigilante

Nice, fixed this bug on EZTV tracker from 1.4 for me, thanks.

comment:10 Changed 8 years ago by mmm

  • Resolution worksforme deleted
  • Status changed from closed to reopened

I still see this in 1.41b2 (7243) on Mac OS X 10.5.5 (9F33). It occurs when the tracker is tracker.thepiratebay.org, which has a bunch of A records assigned:

$ host tracker.thepiratebay.org tracker.thepiratebay.org has address 77.247.176.132 tracker.thepiratebay.org has address 77.247.176.153 tracker.thepiratebay.org has address 77.247.176.151 tracker.thepiratebay.org has address 77.247.176.145 tracker.thepiratebay.org has address 77.247.176.144 tracker.thepiratebay.org has address 77.247.176.139 tracker.thepiratebay.org has address 77.247.176.138 tracker.thepiratebay.org has address 77.247.176.137 tracker.thepiratebay.org has address 77.247.176.136 tracker.thepiratebay.org has address 77.247.176.135 tracker.thepiratebay.org has address 77.247.176.134

However, the tracker is not properly running at all of these addresses. For example:

$ telnet 77.247.176.145 80 Trying 77.247.176.145... telnet: connect to address 77.247.176.145: Connection refused telnet: Unable to connect to remote host

It seems that Transmission is only trying one address and giving up if the connection attempt fails, resulting in the "Tracker request failed. Got HTTP Status Code: 0 (No Response)" error. Ideally, Transmission should be a bit more resilient: if the TCP connection fails and more addresses are available, it should try another address.

comment:11 Changed 8 years ago by charles

What libcurl configuration option should Transmission be using to do this?

Here is the libcurl API documentation.

comment:12 Changed 8 years ago by mmm

libcurl should handle it automatically (see the CURL_connecthost loop in curl's lib/connect.c). It might give up after the first attempt if there's a restrictive connect timeout set?

Perhaps with curl set to be more verbose we'd be able to see why it's giving up without trying the other addresses.

comment:13 Changed 8 years ago by charles

That's pretty easy to do -- set TR_CURL_VERBOSE in your environment variables. :)

comment:14 Changed 8 years ago by mmm

Really strange: the connect appears to succeed even though the connection is actually refused.

* About to connect() to tracker.thepiratebay.org port 80 (#0)
*   Trying 77.247.176.145... * About to connect() to tracker.thepiratebay.org port 80 (#1)
*   Trying 77.247.176.145... * Connected to tracker.thepiratebay.org (77.247.176.145) port 80 (#0)
* Send failure: Broken pipe
* Failed sending HTTP request
* Connection #0 to host tracker.thepiratebay.org left intact
* Connected to tracker.thepiratebay.org (77.247.176.145) port 80 (#1)
* Send failure: Broken pipe
* Failed sending HTTP request
* Connection #1 to host tracker.thepiratebay.org left intact

I find it odd that /usr/bin/curl, using the same libcurl as Transmission, doesn't have this problem:

* About to connect() to tracker.thepiratebay.org port 80 (#0)
*   Trying 77.247.176.145... Connection refused
*   Trying 77.247.176.134... connected
* Connected to tracker.thepiratebay.org (77.247.176.134) port 80 (#0)

The thing that sticks out here is that when running in Transmission, the "Trying" line doesn't have proper status reported ("Connection refused" or "connected"). According to curl's lib/connect.c, the only way this can happen without that singleipconnect function also returning failure is the "Timeout when running the multi interface" case.

So right now, it looks to me like a bug in curl's multi interface.

comment:15 Changed 8 years ago by charles

  • Resolution set to fixed
  • Status changed from reopened to closed

I'm not able to reproduce this anymore. mmm, do you have a testcase that I can use to repeat this?

comment:16 Changed 8 years ago by mmm

Yeah, it seems like all of the addresses for that hostname now work properly on port 80.

The testcase I was using involved adding two entries to /etc/hosts: the first one with an IP address that will refuse connections on port 80, and the second one with an IP address that will accept. For example:

# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1	localhost
255.255.255.255	broadcasthost
::1             localhost 
fe80::1%lo0	localhost
128.9.64.64	tracker.thepiratebay.org
77.247.176.134	tracker.thepiratebay.org

That way, things should still work such that the first address refuses and libcurl (or anything else) should try another address:

bash$ telnet tracker.thepiratebay.org 80
Trying 128.9.64.64...
telnet: connect to address 128.9.64.64: Connection refused
Trying 77.247.176.134...
Connected to tracker.thepiratebay.org.
Escape character is '^]'.

comment:17 Changed 7 years ago by ggg

  • Resolution fixed deleted
  • Status changed from closed to reopened

I'm still observing the same behavior in 1.42 and 1.50b5.

comment:18 Changed 7 years ago by livings124

This happens on all trackers, or just a single one? Are you sure the tracker is actually capable of giving a response?

comment:19 Changed 7 years ago by livings124

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:21 Changed 7 years ago by devtrack

I am still observing it. Will resume later.

Note: See TracTickets for help on using tickets.