Jump to content

Incorrect tracker handling


Merkwurdigliebe

Recommended Posts

When a torrent contains both UDP and HTTP trackers using the same base URL, it loads them into the list like this:

http://tracker.openbittorrent.com:80/announce

udp://tracker.openbittorrent.com:80/announce

http://tracker.publicbt.com:80/announce

udp://tracker.publicbt.com:80/announce

Only the UDP trackers show up down in the tracker list, and if you are using any kind of firewall at all, they time out. You have to go into the list and edit it to look like this:

http://tracker.openbittorrent.com:80/announce

udp://tracker.openbittorrent.com:80/announce

http://tracker.publicbt.com:80/announce

udp://tracker.publicbt.com:80/announce

Then it will pick up the HTTP trackers, but it transfers the "Tracker Timed Out" status to the newly-visible HTTP trackers from the UDP trackers and you have to manually go in and update the HTTP trackers. This is happening on pretty much every torrent I get these days.

I have looked at the torrent files in a binary editor and there is nothing special about the way these trackers are listed within the file. They are listed just like all the other trackers, separated by a colon. They just have two trackers that differ only by the UDP or HTTP indicator, one right after the other, and uTorrent picks them up incorrectly every time..

This is probably a bug.

I am running 2.0 Build 18488. The updater says this is the most current release.

Link to comment
Share on other sites

I wait until is says "Tracker timed out", or something close to that. The torrent is marked with a little red arrow and there are no connections. UDP trackers don't work through any firewall I have used, because stateful inspection only works with stateful connections, so the UDP trackers just fail.

The torrent files themselves seem fine. I have opened up a couple of dozen examples and looked at the tracker lists and the only thing that stands out between the ones that work and the ones that don't are that the latter have two trackers listed consecutively that differ only in the protocol.

Link to comment
Share on other sites

Starting at offset 0x2 and continuing for 269 bytes, here is a snip from one of the failing torrents:

:announce45:http://tracker.openbittorrent.com:80/announce13:announce-listll45:

http://tracker.openbittorrent.com:80/announce44:udp://tracker.openbittorrent.com:80/announceel39:

http://tracker.publicbt.com:80/announce38:udp://tracker.publicbt.com:80/announceee7:comment10:

If I leave them alone all day they stay the same way. I first noticed this when I loaded about 5 torrents and took off for work. Ten hours later they were in the state described. No connections, red arrows, tracker timeout messages.

Link to comment
Share on other sites

I was writing my post while you were writing yours. They crossed in the mail. I have a hex editor handy, I don't have one of the other things. It is suitable for seeing if the ones that work are somehow different from the ones that fail.

These torrents are coming off btjunkie and isohunt, BTW.

Link to comment
Share on other sites

I'll download it and see.

Yes, it persists in the RC.

FYI: When it first incorrectly displays only the UDP trackers, they still get seed, peer, and download numbers.

It has to be getting them from the HTTP tracker. I have a hardware firewall that is configured to block any outbound UDP other than port 53.

I traced it with Wireshark and found two things:

1. It tries sending UDP to the trackers but never receives a response.

2. It is getting the numbers via HTTP.

Whether it displays the HTTP trackers or not, it does load that data from them. It does not result in any connections, though.

I'll consider this reported and await an updated build that addresses it.

Thanks for your time.

Link to comment
Share on other sites

That's what I am doing as a workaround for this unintended behavior.

It is a pain in the rear because I have to wait for the trackers to time out, manually edit the list, then refresh the tracker. It would be a lot easier if this just worked the way it was intended to.

I think that if the draft Multitracker Metadata Extension specification (http://bittorrent.org/beps/bep_0012.html) were expanded to specify the data structures needed to represent the referenced tiers, then future torrents would be more likely to be created correctly. It's always hard to develop against draft standards that lack specifications. It's like coding against Microsoft API's.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...