Jump to content

hashfails with 1.5


dznutz

Recommended Posts

Posted

i'm currently on a torrent with 5 peers. when i activate PE and "allow incoming legacy" connections i get hashfails to the point where all the peers are banned. the 5 peers consist of 3 azureus 2.4.0.0 users and 2 ut 1.4 users. i don't understand how the ut 1.4 users were kicked but they did. especially since only 1 azureus was displayed with an E flag (encrypted connection)

the day before there were 3 users on the same torrent and had the same problem. 2 users were using az 2400 and 1 was using ut 1.5 and ut ended up banning all 3.

to test out whether or not the torrent was poisoned i selected a couple of files within that torrent to complete. the files worked flawlessly. i then turned off PE and disable "allow incoming legacy connections." transfers were smooth and had no hashfails for over 3 hours and counting as compared to the previous run where all 5 were banned within 40 min.

i remember reading about this a couple of weeks ago about the hashfails being azureus' fault and they've fixed it. but my banning of 2 ut 1.4 users makes me wonder

i don't think the hashfails are on my end. i ran bc .63 and ut 1.4 a couple of days ago and had very few to no hashfails - so ide cables are fine. router is not acting strange and i have no dos attacks.

i understand the technology is relatively new and i'm grateful to the developer for this. i'm just wondering if anybody noticed this as well. my solution for anyone with this problem is to disable PE. and if the peers have been banned then just remove and restart the torrent file (that's the only way i can think of to delete the banned peer list).

Posted

AZ 2.4.0.0 is at fault. It has a buggy encryption implementation.

The reason other clients take "splash damage" as it were and get banned is because they also contribute to pieces that fail the hash checks.

AZ 2.4.0.1 and newer have the fix.

Posted

ok, i understand that part.

but here's the odd situation. turning off PE and not allowing legacy connections stopped all the hashfails altogether. currently discarded 64kb with 0 hashfails for the last 3 hours or so

Posted

ok, this is strange.

i disabled protocol encryption and i did not allow legacy connections in the settings yet i still see "e" and "E" in the status for only 1 torrent. i have 41 hashfails with about 170mb excess download. i believe that is due to the problem in the encryption as i said before.

however, on the other torrent i have no "e or E" and thus is following the commands i gave. there are no hashfails for the torrent without any "e or E"

is this normal?

and thanks for the help guys.

also i'd like to add: this is from a private tracker. they don't allow beta testing so the fixed az (which is beta) is not allowed yet.

Posted

legacy = non-encrypted. not allowing legacy connections means that only encrypted peers can connect to you. so really disabling pe but not allowing legacy should be mutually exclusive, and technically it should mean you can only make outgoing unencrypted connections. there might be some bugginess there on the options part, but i guess it's mostly because you're selecting options that don't go together. try turning legacy back on and see if it happens.

Posted

thanks for the tip guys. unfortunately i still see encrypted transfers (e and E) regardless if i disabled or enabled legacy connections. however, like yesterday, encryption occured on this particular torrent. it's almost as if it magically turned on after a couple of hours of no encryption. for this particular file i was connected to over 50 seeders. after i started seeing encrypted transfers for this particular file i'm connected to only 16 seeds with over 40+ hashfails

this is really strange. although encryption was manually disabled it was only seen on this particular torrent and thus is causing many hashfails and peer banning.

so long story short - encryption was disabled in my client but somehow turned on ONLY for this particular torrent. all the other torrent files were ok.

details of this torrent without giving out the name and tracker:

private tracker

a large 60+ gb torrent consisting of many files

uploaded on august of last year

has a mix of clients. 99% are either utorrent 1.4/1.5 and azureus 2400. no bitcomet and its derivatives

good speeds for an old file: started at 2mb/s download and 200kb/s upload before the bannings (my upload max is 5mb/s but there are more seeders than leechers for this file)

thanks for any help

Posted

yes firon i did read your post but assumed "E and e" meant outgoing encryption and incoming encryption respectively. i just now read the faq and it turns out to be something else.

anyway, i have to add something. az users using encryption may specify sending via encryption but as long as i don't accept encryption or don't have the ability to accept the encryption then they won't use encryption. i rolled back to utorrent 1.4 and started the torrent in question. i had no hashfails.

i guess the mystery of why this one particular torrent had problems shall live on

so thanks for your help guys. guess i'll be sticking with ut 1.4 till all the az users get the next stable release (i'm using ut on trackers that ban bc and all of them specify only stable releases).

Posted

As pointed out earlier, there wasn't really a mystery in the first place.

Even though you had encryption set to Disabled, at some point, someone in the swarm initiated an outgoing encrypted connection (incoming from your POV) to you.

As Firon said, incoming encrypted will still be accepted. (wether _you_ disabled encryption or not)

Like you, I'm also experiencing lots of hash fails. Caused by Azureus 2400 peers, ofcourse.

I'm also being traffic shaped. So encrypted traffic is essential for me.

(Unless I choose to settle for 20kB/s download/upload speeds, which I dont)

A workaround is, leave Encryption enabled, but block _ALL_ Azureus 2400 peers. That's what I'm doing.

Since the last couple of days, there are usually plenty of µT 1500 and BitComet 0.63 peers within my swarm anyways. So there's no need for Azureus 2400 peers.

Unfortunately, banning clients is not an easy thing to do in µT.

The way I do it.. I go to the Peers tab, then sort by Client, then I select all Azureus 2400 peers, then right-mouse click "Copy selected hosts" (make sure you dont have "Resolve IPs" checked)

Then paste those IP's into your ipfilter.dat and stop the torrent, restart µTorrent and start the torrent again.

Now all Azureus 2400 are gone.. No more peers poisoning your pieces and getting everyone else banned along in the process :)

Problem is ofcourse, when a new Azureus 2400 peer connects to the swarm, then you'll have to do the previous steps all over again (copy/paste IP to ipfilter.dat, restart client, etc..)

Let's just hope Azureus 2402 stable comes through soon.

But till then, those of us who depend on encrypted BT traffic, will need to get rid of Azureus 2400.

Posted
Even though you had encryption set to Disabled, at some point, someone in the swarm initiated an outgoing encrypted connection (incoming from your POV) to you.

As Firon said, incoming encrypted will still be accepted. (wether _you_ disabled encryption or not)

yes, that was the weird part. i guess since 1.5 supports encryption you can't really disable it entirely eventhough the option about legacy encryption "appears" to allow you to disable incoming encryption.

i've since gone back to ut 1.4 and will use 1.5 once the new stable azureus is out. since 1.4 doesn't support encryption i've received very little to no hashfails with other peers.

Posted
What I do is just restart the client when I see it's banned half the world. Pain in the ass, but nothing we can do about it... :/

Yup I do that too, I'm able to download fast for a while then (until the hashfails start kicking in again). But on a few 1.37 Gb torrents I tried I only needed to restart it 1-2 times or so.

1.4 is no option for me (I think it's not a good build anyway)

Archived

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

×
×
  • Create New...