rakshasa / rtorrent

rTorrent BitTorrent client
https://github.com/rakshasa/rtorrent/wiki
GNU General Public License v2.0
4.18k stars 415 forks source link

Wrong ratio data sent to tracker #561

Open ErikZown opened 7 years ago

ErikZown commented 7 years ago

As i cant re-open closed issues i've made a new one. the closed one i saw but no solved comment: https://github.com/rakshasa/rtorrent/issues/548

Anyway, seems my rtorrent are sending wrong stats to the private tracker im using. Its not on every torrent but on those affected torrents, it usually dont report any downloaded data and says i have uploaded more than 500GB (when rtorrent says like 20-30GB).

Anyone else knows about this? Pretty serious as it can be seen as ratio cheating..

Thanks!

My setup is using rtorrent 0.9.6, libtorrent 0.13.6

pyroscope commented 7 years ago

There's nothing anyone can do without (scrubbed) tracker request logs.

colinhd8 commented 7 years ago

I also have the problem.It report correct uploaded data but report 0 downloaded. @pyroscope How to report the tracker request logs? add log.open_file = "tracker", (cat,logs/tracker.log) log.add_output = "tracker_debug", "tracker" to rtorrent.rc is right?

colinhd8 commented 7 years ago

I just found that the downloaded data wrong is because some torrents are free leech, so i think it's no problem, at least for me.

Neonlinx commented 7 years ago

I often have this issue....and happens both on very fast server 1-20Gbit) and on 100Mbit server. The file is correctly downloaded and in seed. But the tracker reports (for example) 200% or 300% or 500% or more data downloaded (when the file is for example 40GB). Many times this file is also reported not in seeding. I noticed that this happens when I download 2 same identical files from 2 different trackers. But anyway, I start thinking that is caused by the tracker or someone is "injecting" fake peers. Could be?

P.s.: sorry I'm not a programmer.

rakshasa commented 7 years ago

As said, nothing I can do without proper tracker logs.

kannibalox commented 7 years ago

Many times this file is also reported not in seeding. I noticed that this happens when I download 2 same identical files from 2 different trackers

there are many variables besides "same files" which could effect ratio, maybe try enabling tracker logging?

Neonlinx commented 7 years ago

Thanks for replies!!

I added logs to my rtorrent.rc. I will check logs

colinhd8 commented 7 years ago

@Neonlinx wait your logs. The rtorrent 0.9.6 was banned by some trackers, so i also want to know if there is really a bug in it. P.S. Don't forget to hide the passkey if the tracker is a private tracker.

@rakshasa It seems that you have commit a lot of codes to the feature-bind branch, is it a time to release a new release?

VadVoci commented 7 years ago

rtorrent 0.9.6 was banned by some big private trackers a week ago. Those trackers are based on NexusPHP source.

demonotaku commented 7 years ago

Big, not really big, One sends Passwords in Plain Text

None of the Major modern trackers have banned rTorrent 0.9.6

and none were banned for mis-calculation of ratio

They banned it, saying it was announcing too often

scoobynz commented 7 years ago

Well. HD-Torrents has now banned 0.9.6 and that is reasonably big/popular. Their message is;

Apparently when the client receives a bad piece (for any reason) instead of banning the peer that is sending fault data, this client requests the piece FROM THE SAME PEER AGAIN, rejects the bad data, requests the piece, rejects the data, wash, rinse, repeat.

Fugor commented 7 years ago

SCC, HDT, HDChina, CHDBITS... etc. That's a lot, yes. Reason: wrong data reported. "Announcing too often" only concerns Deluge.

Fugor commented 7 years ago

From CHDBits forums:

HDBits admins quote: "For those interested (with the rtorrent 0.9.6 ban on some trackers), we had debugged and solved the problem shortly after opening this thread. The problem was duplicate peer_ids across multiple users. Whether this is the consequence of something rtorrent did with a prng function, intended or not, I don't know, but the solution was extremely simple.

I won't go into detail, but our tracker pre-supposed that peer_id was unique and tried to fetch the peer data from the database using only the peer_id. All we did was add another condition to the SQL statement: AND userid = $userid. The userid should already be present because it can be derived from the passkey."

Any chance CHDbits sysops could fix it too instead of banning so popular client?

notojak commented 6 years ago

@Fugor @demonotaku @VadVoci The current version rtorrent, has been unlocked on the HDC in the last week.

screenshot-192 168 1 110-2018-05-05-13-13-47-576

screenshot-192 168 1 110-2018-05-05-13-21-56-007