Opened 7 years ago

Closed 7 years ago

Last modified 3 years ago

#4032 closed Bug (fixed)

Better error detection / reporting in http announces

Reported by: Guinness2702 Owned by: jordan
Priority: Low Milestone: 2.30
Component: libtransmission Version: 1.93
Severity: Minor Keywords: error messages, dns
Cc:

Description

If a DNS lookup of the tracker fails to lookup the tracker in DNS, the error message reported is "tracker did not respond." A message "hostname not found" would have made it much easier for me to track down the cause.

Note: This error was displayed in transgui 2.2. I am *assuming* that the error message is generated by transmission-daemon, not the GUI. My apologies if this is not the case.

This can be reproduced by blocking off your DNS in firewall (as I inadvertently did), and adding a new torrent. The tracker state will go to updating, and eventually change to this error.

Change History (12)

comment:1 Changed 7 years ago by Guinness2702

  • Component changed from Transmission to Daemon

comment:2 Changed 7 years ago by jordan

  • Component changed from Daemon to libtransmission
  • Resolution set to invalid
  • Status changed from new to closed
  • Version changed from 1.93+ to 1.93

Hi Guinness2702,

Thanks for reporting this issue. You're right that the "tracker did not respond" message is a catch-all for lots of cases, and a "hostname not found" type message would be useful.

However, I don't see any way to pull enough information out of libcurl for Transmission to know when to use a message like that. This libcurl page lists the information that we can pull out of a completed task but there doesn't seem to be anything about the DNS lookup result. I looked at libcurl's code to see if CURLINFO_NAMELOOKUP_TIME has a special value for lookup failures, but it doesn't. CURLINFO_PRIMARY_IP also looks promising, but it's only applied after a connection is made, so it doesn't seem to tell the difference between a lookup failure and an unresponsive server either.

If you see some way to do this from that libcurl page, please reopen this ticket and let the developers know. I think this ticket is a good idea.

comment:3 Changed 7 years ago by Guinness2702

  • Resolution invalid deleted
  • Status changed from closed to reopened

Okay, fair enough, but at least change the message to "could not connect to tracker" pls. "Tracker did not respond" suggests (or at least did to me) that something was sent to the tracker and no reply was received, rather than the truth that nothing was even sent to the tracker. Led me to make some assumptions which started me looking in the wrong place.

Also, now that I think to mention to it, I didn't see anything at all in the error log (syslog) about a failure to connect to the tracker (log level is 3). Perhaps would be nice to put something here too.

comment:4 Changed 7 years ago by jordan

  • Milestone changed from None Set to 2.30

"Could not connect to tracker" is a good idea. Milestoning that request for 2.30.

I'm less sure about logging this in syslog. We already the tracker response (or "tracker did not respond") as an info-level message, which should show up if you're running with --log-info. The problem with escalating it to an error message is most public domain torrents have several trackers, even dozens of trackers... if a couple of those don't respond, it doesn't matter to the user, but it'll generate a lot of useless error messages in the log.

comment:5 Changed 7 years ago by jordan

  • Summary changed from Poor error message on tracker DNS lookup failure to Better error detection / reporting in http announces

comment:6 Changed 7 years ago by jordan

r11896:

(trunk) #4032 "Better error detection / reporting in http announces" -- added to trunk.

This patch adds two new flags to the callback function -- did_connect and did_timeout -- that are calculated inside of web.c using information from libcurl. This allows the announcer to detect timeouts more accurately and also to distinguish between unresponsive trackers (which get the preexisting "Tracker did not respond" error message) and unconnectable trackers (which get a new error message, "Could not connect to tracker").

Last edited 7 years ago by jordan (previous) (diff)

comment:7 Changed 7 years ago by jordan

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

comment:8 Changed 7 years ago by jordan

reopening for attribution

comment:9 Changed 7 years ago by jordan

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:10 Changed 7 years ago by jordan

  • Owner set to jordan
  • Status changed from reopened to new

comment:11 Changed 7 years ago by jordan

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

comment:12 Changed 3 years ago by cfpp2p

In r11896 web.h, and although the parameter order for the two bool hasn't affected function, the two bool are properly ordered by r14572.

Note: See TracTickets for help on using tickets.