Jump to content

Auto-banning for bad data/hashfails not working - v3.1 build 26671


Reziac

Recommended Posts

Recently encountered a torrent with one seed that was sending a lot of bad data, in fact I found that running overnight, it had sent me over 600mb of bad data for a 400mb fileset. Each piece would download and fail hash check many times in a row before I'd finally get a good one. The "bad" user was never banned by uTorrent. Eventually I figured out which user it was and manually banned it via ipfilter.dat.

I've never seen this before, always in older versions it autobanned after a few hashfails. But so far in this version, I have not seen *any* IP address get banned for sending bad data. (I check the log regularly.)

Actually this might be a good place for a new feature -- to let users decide how many hashfails before a given IP address is banned. That would make it more flexible for when a file is hard to find and the only available source has a crap connection. (I've run into this situation and had to repeatedly manually unban a user to get the file.) Ideally it would have both a global setting, and a per-torrent setting (in the Advanced setting context menu, where we also set per-torrent bandwidth, would be a good place for it).

Also, this would avoid the possibility of some clever badguy crapflooding with just enough bad data that they avoid getting banned. (For instance if it takes 5 in a row to ban, some jerk doing 4 bad pieces then one good piece, 4-1-4-1 etc. would be very wasteful yet would not trigger autoban.) If some user was observed thus circumventing the autoban, they could still be banned by changing the setting.

Link to comment
Share on other sites

It's not that old, and in any event this isn't the sort of bug one can reproduce -- it was observed by sheer chance (you can't exactly *plan* to have someone send you a bunch of bad data). Once that torrent was finished it was too late; I didn't realise it was a bug, rather than a removed feature, until later. And the IP address was Verizon pool so probably dynamic and of no use by now.

I've been keeping an eye on the log since, but so far haven't hit another peer persistently sending bad data, so can't do any more than report what I saw.

BTW on the Peers tab, the "Hasherrs" column *never* shows any error count, which might be the same bug.

Link to comment
Share on other sites

Thanks for the info; didn't come up when I searched for this problem (and I don't have the time nor the dedication to try every beta nor to read every release notes file). So it was indeed a bug...

So I pulled v3.1.3.26837 and tried it... it won't run, at all. Same with 3.2.0.26986 beta.

Error message:

"the procedure entry point GetExtendedTcpTable could not be located in the dynamic link library IPHLPAPI.DLL"

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...