peer exchange/peer caching.

utorrent has been banned on the private tracker site I use because of this peer exchange

they say it is letting people in from outside the site...

so now I can't participate

there should be an option to turn this off if needed!!!!

AFAIK, peer exchange isn't even implemented yet...perhaps they got confused with DHT? :/

nope they tested it with DHT enabled and disabled

No, peer exchange is not implemented. FUD...

I am not sure who any of the people posting to this thread are... so no offense, but I would prefer a developer to tell me that! so that I can take this to the sysop of this private tracker site to prove him wrong... cause he claims he tested it and proved that peers not from the site are connecting with utorrent.

utorrent has been banned on the private tracker site I use because of this peer exchange

they say it is letting people in from outside the site...

so now I can't participate

there should be an option to turn this off if needed!!!!

There is no Peer Exchange. The only reason this happens is because your tracker admins are to stupid to private falg their torrents, which µTorrent reads as it is okay to use DHT. Just Right Click Torrent > Properties > Then 'un-check Enable DHT'

I am not sure who any of the people posting to this thread are... so no offense, but I would prefer a developer to tell me that! so that I can take this to the sysop of this private tracker site to prove him wrong... cause he claims he tested it and proved that peers not from the site are connecting with utorrent.

If your only planning on trusting the devs then you'll be waiting awhile. your tracker admin must know shit next to nothing about torrents if he can't figure out that it is DHT and it just needs to be disabled or he needs to get some brains and private flag his torrents.

see that's the thing... they tested it with DHT disabled and enabled

I am not saying they are wrong here.. cause I think they are.. but I want to prove it!

Yeah, it's called DHT. Your tracker admin isn't very bright, and most definitely shouldn't be running a tracker, if he doesn't know that...

And yes, you can turn it off, you can also force clients to turn it off for that torrent using the private flag. I do hope your tracker admin knows what that is.

Ok, i am not the sysops for the site, but i was involved in the testing.

This sort of problem is happening in a lot of private trackers.

First of all, sysops is very bright, probaly smarter than you will ever be

The torrents we tested on were privately flagged torrents, and there also is a private key written in the announce. And yes we know the difference between DHT and peer exchange, and the testing was done with DHT disabled and enabled.

This wasnt some 30 minute test, but we were busy on it for a long time.

Basicaly, the ghost peers were coming in due to the torrents being uploaded to another site. When we tested we banned and used a range of clients. One of the clients was letting ghost peers in.

Basically without a Utorrent client in the swarm, it was secure. No illegals were let in, and running different clients we couldnt get into the 'legal' swarm. All the illegals had to hang around outside, sharing amongst themselves.

But when a Utorrent client (one connecting via the tracker) joined the swarm, whilst connected to these ghost leechers, he dumped all the ghosts onto all the tracker peers.

So... utorrent was disabled.

Now after hanging around the same swarms (tested on mulitple torrents) for about 6 hours, there is NOT one ghost peer in the swarm. Whereas before utorrent was banned, the instant utorrent jumped into the swarm, we were hit with many illegals.

And yes... when reloading our clients they werent peercashing.

Sure... utorrent doesnt have peer exchange. So why does it do this. Probaly poor coding. What do you expect from a client 90KB in size, theres bound to be problems with it.

What more do i need to say. The facts speak for themselves. We have banned Utorrent, and created secure swarms again. Btw Bitlord pretty much did exactly the same thing as Utorrent, we went thru all of this with that client as well.

There is no such correlation between the size of a client and the number of bugs in it (90KB == problems??). In fact, I'd expect a smaller client to have less bugs than a larger one, seeing as how there's less code. The age of a client is more like what you're trying to get at. Fine, µTorrent is young, so maybe there might be bugs because of that. But size? Nah uh.

As for DHT, there *might* be some problems with µTorrent's implementation. I don't know this for a fact, but seeing as how ludde had to reverse engineer the DHT protocol to get it working in the first place (there was no documentation on the network), I wouldn't be too surprised if this was the case.

"Poor coding" isn't a good choice of words, by the way. Having bugs in an application doesn't mean poor coding. It means that the developer made a mistake.

"Poor coding" isn't a good choice of words,

by the way. Having bugs in an application doesn't mean poor coding.

It means that the developer made a mistake.

Yeah, and neither where these good choices of words....

There is no Peer Exchange. The only reason this happens is

because your tracker admins are to stupid to private falg their torrents,

which µTorrent reads as it is okay to use DHT. Just Right Click Torrent > Properties > Then 'un-check Enable DHT'

Yeah, it's called DHT. Your tracker admin isn't very bright, and most definitely shouldn't be running a tracker,

if he doesn't know that..

There is no Peer Exchange. The only reason this happens is because your tracker admins are to stupid to private falg their torrents

Fine, I agree, those were poor choices of words as well O.o

(one last note: why'd you quote ColdArmor twice, and the same exact quote both times?)

Utorrent definitely doesn't have peer-exchange atm. I'm thinking this could have something to do with that other thing people were complaining about, which is that utorrent allows connections from peers that weren't given by the tracker.

does anyone know if this is going to be fixed on the next version, and if so, will this site allow µtorrent again?

p.s. µtorrent rocks.

Hi!

I believe the problem is caused by a flaw in the tracker, the one who wrote the tracker did a poor coding job, and those that are administrating it probably don't have a clue what they are doing.

It's not the client's fault if your torrent ends up on other sites. And if it does, your tracker is supposed to have client authentication, so the "illegal" peers won't be able to get a peerlist.

/Ludde

Hey

I believe there isnt a flaw in the tracker.

The only client that is getting this illegal peer list, is Utorrent. How is it getting this list? Thru a problem in DHT? I dont know.

Utorrent is the client that is handing out this list to the other clients, once it has connected to them.

Note.. the tracker is not handing out an illegal peer list. The clients in the tracker swarm are grabbing that list of Utorrent.

For proof....

I have tried about 20 torrents that we were having problems with just 14 hours ago, and were getting a stack of illegals. These torrents HAD utorrent clients in the legal swarm. Now, with Utorrent banned, after being in the swarms for the same torrents, after 14 hours of sitting in those swarms, not a single illegal peer.

It is not a tracker problem, it is a client problem. We had exactly the same problem with Bitlord. Go around, visit a few other private trackers, you will see they are asking the same questions/having the same problems.

The facts speak for themselves.

Note : The dumb coder you speak of-as i mentioned before he is actually very bright. If you wish to be ignorant, so be it. I am just alerting you to a problem.

Actually, I think the problem has just been put forward incorrectly.

What's happening is the tracker is rejecting the unauthorized IPs. Some of the legitimate ones are using µtorrent, that's not the problem. The problem comes from other leechers being able to circumvent the tracker completely, as though they were using DHT, even though the tracker automatically adds the private tracker flag to all uploaded torrents, but only when a member using µTorrent is in the swarm. What's odd is, I've experienced the problem myself as well, but all the leechers who are circumventing are not reported as connecting through DHT. They were simply Remote connections.

What's strange is DHT doesn't seem to be used itself, as I had DHT completely disabled through Azureus. (I'd like to give µtorrent a try, but there doesn't seem to be a Linux port yet. Oh well.) This is what has the admin of the private tracker in an uproar. Since the breach of security only happens when µtorrent is connected to the tracker, they had to ban it until such time as the problem can be found and fixed (if the problem is on their side) or the cause gets written out of the client (if the problem is on the client side). As of now, they can't find a problem with the tracker code as experimentation has shown the tracker is properly rejecting the non-member IPs. This has brought about two lines of thought, both of which are addressed by section 2.1 of your FAQ, "Does µTorrent support DHT or Peer Exchange?" It quite clearly states the DHT is supported but Peer Exchange isn't, and that the private flag is respected.

The first theory is µtorrent is using DHT to circmvent the tracker. This shouldn't be since both the client is supposed to respect the "private" flag AND is incompatible with Azureus's DHT. Quoting section 5.14 of your FAQ regarding "What is DHT?": "µTorrent's DHT implementation is the same as Mainline and BitComet's, but unfortunately this is incompatible with Azureus's implementation." Since I'm receiving these non-member connections with Azureus as well with both DHT on and off in Azureus, DHT should be impossible. Should be, though.

The second theory is that there is some sort of peer exchange occuring. This makes more sense, as some of the peers that I've found sneaking in were indeed Azureus clients as well. However, your FAQ states the Peer Exachange is not available for µTorrent. The evidence does suggest otherwise, however. Especially since the connection were Remote.

Based on the information gathered and available evidence, they came to conclusion that µTorrent is leaking out the IP addresses of legitimate members of the private tracker in some fashion. Based on this conclusion, they have temporarily banned µTorrent for accessing the tracker until the client has this ability disabled. Because the client is closed source, they have no way of knowing if the client truly is responsible. (Being closed source can't be faulted on the programmers, it's their choice. Don't anyone start on that!) So they simply have to wait and see if the client gets fixed (from their point of veiw).

Perhaps that will shed a little more light on the situation. Since the problem only occurs when a µTorrent client is in the swarm, they can only conclude that they problem is with the client. If that's the case, perhaps something in the client code is causing this after all. That's what they're suggesting.

However, your FAQ states the Peer Exachange is not available for µTorrent. The evidence does suggest otherwise, however. Especially since the connection were Remote.

Incoming connections mean that they got your IP from someone else, or the tracker. That is in no way an indication of peer exchange on µTorrent's part. If you look better, you can see that normal peers come in as incoming connections too.

Peer exchange only means that two clients exchange a peerlist. So obviously, some client in the swarm is giving out YOUR IP to others, and µTorrent would obviously accept the connection since it has no way of knowing whether it's a "legal" or "illegal", as you guys put it.

Have you considered rogue Azureus/BitComet clients as being the culprits? You know, considering that they can do Peer Exchange, and µTorrent can't.

From what I understand, uTorrent does have a built-in tracker. A user with uTorrent can receive announce requests at ip:port/announce. Perhaps it's possible that some other clients attempt to announce to other peers as a form of peer exchange?

Perhaps a 'test' client could be compiled with DHT internally disabled and the internal tracker disabled, and see what happens.

I'm glad that we've stopped resorting to name-calling here. I hope that someone can figure out exact what is going on. Whether it is a 'bug' or 'issue' or nothing at all is completely up to the developers.

NiteShdw: they would still have to know of that µTorrent peer's IP and port. For this to work, you'd need a "legitimate" client in the swarm giving out this information. This is also possible with Azureus, and any other client using an embedded tracker. And µTorrent won't give its peerlist to peers that come on it's internal tracker anyway.

However, your FAQ states the Peer Exachange is not available for µTorrent. The evidence does suggest otherwise, however. Especially since the connection were Remote.

Incoming connections mean that they got your IP from someone else, or the tracker. That is in no way an indication of peer exchange on µTorrent's part. If you look better, you can see that normal peers come in as incoming connections too.

My bad, I should have been more specific. The NON-MEMBERS were all Remote connections.

Have you considered rogue Azureus/BitComet clients as being the culprits? You know, considering that they can do Peer Exchange, and µTorrent can't.

Granted that may be true, but why do the non-members only connect when a µTorrent is in the swarm? This is what they're trying to get through.

From what I understand, uTorrent does have a built-in tracker. A user with uTorrent can receive announce requests at ip:port/announce. Perhaps it's possible that some other clients attempt to announce to other peers as a form of peer exchange?

Perhaps a 'test' client could be compiled with DHT internally disabled and the internal tracker disabled, and see what happens.

See, this is what we were looking for: Possibilities. That's all. To be honest, that sounds somewhat far fetched, though. Unless µTorrent is setup to work as a backup tracker that's always active anyway, this shouldn't really be happening. But you never know...

I'm glad that we've stopped resorting to name-calling here. I hope that someone can figure out exact what is going on. Whether it is a 'bug' or 'issue' or nothing at all is completely up to the developers.

Too true. Sheesh, at one point, I was wondering when people would start calling each other a bunch of ass ramming uncle fu... I'm not halping, am I? ^^

Is this possibly because people are adding in other trackers because the main tracker is failing, and/or there are more seeds/peers to locate elsewhere.

If ever i download a torrent i add in all the main trackers as well as whatever was originally in the torrent, so i can get the maximum coverage of peers and seeds (and works nicely when the tracker fails too).

People may not like it, but i dont see a problem with it personally.

this site we are referring to is a private trackers... there are no other trackers needed when seeding files

After visits to my site from your cronies, I have decided to make 1 post here-

Would this site's admin(s) consider joining us on IRC so we can test further or something? Or at the very least, discuss it with ludde (µTorrent's dev). Although, he is in Sweden, so his hours are a bit different. He tends to be gone by about 5PM EST, but he gets on at about 2-3 AM or so.

edit: maybe it'd help if I put in the irc info...

irc.freenode.net #utorrent

With all of the name calling that was directed @ me from your forum-

surely you jest-!!

http://forum.utorrent.com/viewtopic.php?id=2407]Your tracker admin isn't very bright, and most definitely shouldn't be running a tracker, if he doesn't know that..

also

http://forum.utorrent.com/viewtopic.php?id=2407]There is no Peer Exchange. The only reason this happens is

because your tracker admins are to stupid to private falg their torrents,

which µTorrent reads as it is okay to use DHT. Just Right Click Torrent > Properties > Then 'un-check Enable DHT'

and

Hi!

I believe the problem is caused by a flaw in the tracker, the one who wrote the tracker did a poor coding job, and those that are administrating it probably don't have a clue what they are doing.

It's not the client's fault if your torrent ends up on other sites. And if it does, your tracker is supposed to have client authentication, so the "illegal" peers won't be able to get a peerlist.

/Ludde

why would you be interested in talking to someone that dosent have a clue ???

and I'm not dissing your client but you seem hell bent on dissing me, Why is that ?

Furthermore when I am done testing and rechecking my findings.

I will post them but not here due to the slanderous nature of this forum-

BTW- the above was taken from my post in my forum-

Incase you don't know it actions speak louder then words and you all spoke volumes here !

Also I think others might just be interested in the treatment I have received here !

And for what and to what end-hell this is my 1st post here

regards

thebrass

OK, it seems there is a lot of misunderstanding here. :|

TheBrass, I assume you're the admin/operator of the site in question...if you are, perhaps you were a bit premature to ban µTorrent without extensive testing. But maybe you have done so, if that is the case please enlighten us and bring forward your findings. Having said that, does your tracker have the private flag enabled? If not, why not? If you do have it enabled, maybe there's a bug in µTorrent/your tracker that prevents them from understanding each other correctly...in either case, it would be wise to present all your evidence so that Ludde/Vurlix can have a look at it.