Registered Member
|
When connecting to a the tracker KTorrent start connecting to the peers, and the connection "Authentication(S) to xxxxx:" and "Connection closed" repeats until I close KTorrent, and number leachers/seeders counting up to 28(3) 5(1) and down to zero (and up again).
Version svn: 481339 Torrent: Mailed to "George" |
Moderator
|
|
Registered Member
|
I think I can confirm this. I get constant connect/disconnect from peers. Like it's going really crazy or something. Dozens of peers get connected in a few seconds and then in another second or two they all get disconnected except the ones with active transfer (the ones which are sending me data).
BTW George, when tracing the high num_peers variable in NewChokeAlgorithm::doChokingLeecherState() - num_peers gets some normal value at this function start (e.g 10-11) and by the time it goes to FOR loop we talked about num_peers is zero. I'm not sure that this has something to do with the current problem unless you kill some of the peers during this function? (which I don't think so) |
Moderator
|
Send me a torrent I need to reproduce this.
Even if a Peer gets killed, for some reason, that still shouldn't change the num_peers variable. |
Registered Member
|
I've sent you the torrent but just now I found out that it happens with other torrents as well and not always...
Also, after some examining I found out that there are lots of peers duplicated in PeerView - actually there are about 5-6 exact same IP addresses in PeerView and there are lots of these entries. Also, KT is producing ~100 lines per second in logviewer with "Authentication(S):" and "Connection closed", and most of the IP's printed are already in PeerView... We're having lots of weird things today, may I notice |
Moderator
|
It's Authentication(S) messages so we're not the ones initiating the connection. Why would those other peers, constantly be trying to contact us ?
The first thing we need to do is, add a check in the authentication procedure. When we get a PeerID we allready are connected to, we do not allow that connection. Could this be an anti P2P thing ? Some sort of DOS attack ? Ivan and Pär, the torrents this happened on, would you describe the content as legal or illegal ? |
Registered Member
|
I find this really strange too. It looks like a 'small' DOS attack but I don't think it is... I have level1 antip2p filter loaded so that should exclude all known antip2p IP's - but even then it is possible....
I forgot to use some network tool to see if those were actual incoming connections (in case KT messed up something, which I don't think so). I'll do that first time I reproduce this situation. Torrent legality is 'similar' to the one I've sent you earlier |
Moderator
|
Could be a new attack, allthough it's noting more then a small nuisance. Google isn't turning anything up. Do you happen to know what client (AZ, the official, BitComet ...), that was doing this ? Maybe some developer made a small mistake.
Authentication(S) is allways incoming.
You mean it's legal on the planet Mars |
Moderator
|
|
Registered Member
|
Well, can you tell for sure that MS doesn't have offices on Mars? Think about it
I was just about to check this out. From what I remember I think I saw some same IP's for older versions of BitComet (<0.59) and some of the v0.6 ones. There were lots of BitComets in PeerView so maybe this is a coincidence I'll look into it. |
Registered Member
|
legal or not: I have tried different torrents, The legality don't seem to mather.
If I Stop the torrent the strange connections/disconnections continues for over 1 hour. If it can have some importance, all torrents I tried with problem is on the tracker.prq.to - tracker. Or maybe a bug in some client... I have not seen this before this Friday. |
Registered Member
|
Ok, we have a clue now!
All the torrents causing this problems here are also from tracker.prq.to. Damn I hate this stupid tracker. So far I can see that BitComet makes the most connections but the weird thing is that also very old versions are acting the same, so I don't know if the problem is in BitComet. I would rather blame the tracker, maybe they messed up something? Still, that doesn't explain this large number of incoming connections from the same clients... I've discovered a bug in IPBlocklist since we switched to KNetwork classes. All incoming connections are able to pass through the filter. I'm gonna fix this and see if any of those IP's are listed in filter. |
Registered Member
|
|
Registered Member
|
It happend to me with BitComet client. It seems that it is conecting to me while it is already connected. This happens to me only with BitCommet clients (BitComet 0.0.5.9 and BitComet - I don't know why ktorrent doesn't display me a version number). I'm starting a log to see with which versions it happens. |
Registered Member
|
Registered users: bancha, Bing [Bot], Google [Bot], Sogou [Bot]