Ticket #1855 (closed defect: invalid)

Opened 5 months ago

Last modified 3 months ago

Download has unordered info dictionary.

Reported by: TPAX@me.by Owned by: rakshasa
Priority: normal Milestone:
Component: libtorrent Version: HEAD
Severity: normal Keywords:
Cc:

Description

few weeks ago i've started getting those errors on quite a big percentage of torrents from one private tracker. i'm getting this error while adding a torrent files.

i'm on freeBSD and got rtorrent from ports. on 0.8.3_1 torrent file opened, but failed to download, saying Bad bencoded data. i've upgraded to 0.8.5_1 (i.e. -devel) and those torrents are just fail to open.

torrents are created by uTorrent (first i thought only 184 affected, but today i've found 1820 also has this problem)

i've also found a commit http://libtorrent.rakshasa.no/changeset/1094 where this message was added. but how to overcome this error, who is the badguy making these torrents? (at first it as 20% of newly added torrents, but now it's like 80-90%)

Attachments

Change History

  Changed 5 months ago by anonymous

torrents are created by uTorrent

who is the badguy making these torrents?

follow-up: ↓ 4   Changed 5 months ago by anonymous

Even if you remove the error message, you won't like it. It will mean that rtorrent and utorrent disagree about the SHA1 hash of the torrent. Because of a bug in utorrent it uses the incorrectly-ordered keys to compute the hash, instead of the bencode representation that's required by the bittorrent specs.

The bencode representation ALWAYS has keys in alphabetical order. So it's utorrent at fault here for making a torrent with wrongly ordered keys and then using that wrong order to compute the hash. Unfortunately most trackers will agree with utorrent, rather than the standard. I guess, if you just shout a falsehood loud enough people will believe you.

In any case, even if you make rtorrent load the file, you'll be the only peer in the swarm, except for other rtorrent clients. All utorrent versions will use the wrong info hash and so you won't find them, and they won't find you.

The only solution is to get the utorrent people to read the bencode specs again and fix their client, and to reupload fixed versions of the torrent files.

Or maybe hack rtorrent to reproduce the utorrent bug, though I doubt you'll see that become part of the code base...

  Changed 4 months ago by TPAX@me.by

thanks for the reply. i'll kick some buts where they need to be kicked :)

in reply to: ↑ 2   Changed 4 months ago by Ultima

Replying to anonymous:

The bencode representation ALWAYS has keys in alphabetical order. So it's utorrent at fault here for making a torrent with wrongly ordered keys and then using that wrong order to compute the hash. Unfortunately most trackers will agree with utorrent, rather than the standard. I guess, if you just shout a falsehood loud enough people will believe you.

Yeah, I guess you're referring to yourself when you say "you," right? After all, you're the only one I see shouting falsehoods here.  µTorrent doesn't bencode incorrectly.

  Changed 4 months ago by Ultima

To be sure, this ticket can probably be closed, because the bug lies not in either client, but in the tracker.

  Changed 4 months ago by Ultima

Scratch that (and sorry for being a bit spammy here).  After a bit of thought, I've come to the conclusion/opinion that µTorrent is probably correctly interpreting the specs, and that libTorrent (as well as other clients) may be misinterpreting the specs when it comes to calculating a .torrent file's infohash.

The topic is wide open for debate.

  Changed 3 months ago by rakshasa

  • status changed from new to closed
  • resolution set to invalid

Add/Change #1855 (Download has unordered info dictionary.)

Author


E-mail address and user name can be saved in the Preferences.


Action
as closed
Next status will be 'reopened'
 
Note: See TracTickets for help on using tickets.