This forum has been archived. All content is frozen. Please use KDE Discuss instead.

Strange behavior

Tags: None
(comma "," separated)
Pär H
Registered Member
Posts
28
Karma
0

Strange behavior

Sat Nov 19, 2005 8:51 am
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"
George
Moderator
Posts
5421
Karma
1

Sat Nov 19, 2005 11:21 am
I can't seem to reproduce that behaviour.

The IP address in the Authentication(S) message, is that your own ?
imported4-Ivan
Registered Member
Posts
819
Karma
0

Sat Nov 19, 2005 2:51 pm
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)
George
Moderator
Posts
5421
Karma
1

Sat Nov 19, 2005 6:52 pm
Ivan wrote: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).


Send me a torrent I need to reproduce this.

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)


Even if a Peer gets killed, for some reason, that still shouldn't change the num_peers variable.
imported4-Ivan
Registered Member
Posts
819
Karma
0

Sat Nov 19, 2005 8:40 pm
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 :)
George
Moderator
Posts
5421
Karma
1

Sun Nov 20, 2005 12:04 pm
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 ?
imported4-Ivan
Registered Member
Posts
819
Karma
0

Sun Nov 20, 2005 12:31 pm
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 ;)
George
Moderator
Posts
5421
Karma
1

Sun Nov 20, 2005 12:56 pm
Ivan wrote: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....


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.

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.


Authentication(S) is allways incoming.


Torrent legality is 'similar' to the one I've sent you earlier ;)


You mean it's legal on the planet Mars :lol:
George
Moderator
Posts
5421
Karma
1

Sun Nov 20, 2005 1:13 pm
I added the check, it should prevent duplicate connections from the same peer.
imported4-Ivan
Registered Member
Posts
819
Karma
0

Sun Nov 20, 2005 1:35 pm
You mean it's legal on the planet Mars

Well, can you tell for sure that MS doesn't have offices on Mars? Think about it ;)

Do you happen to know what client (AZ, the official, BitComet ...), that was doing this ?

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.
Pär H
Registered Member
Posts
28
Karma
0

Sun Nov 20, 2005 4:49 pm
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.
imported4-Ivan
Registered Member
Posts
819
Karma
0

Sun Nov 20, 2005 6:03 pm
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.
imported4-Ivan
Registered Member
Posts
819
Karma
0

Sun Nov 20, 2005 6:38 pm
I've just checked. From ~150 peers only one IP was listed in level1 antip2p file.

Par, could you check to see if 202.180.104.211 shows in your peer list? I've picked this random IP and, oh my, he tried to connect to my client ~50 times in only a minute...
Nikolay
Registered Member
Posts
33
Karma
0

Sun Nov 20, 2005 7:18 pm
Do you happen to know what client (AZ, the official, BitComet ...), that was doing this ?


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.
Pär H
Registered Member
Posts
28
Karma
0

Sun Nov 20, 2005 7:52 pm
No, I can not see 202.180.104.211,


Bookmarks



Who is online

Registered users: bancha, Bing [Bot], Google [Bot], Sogou [Bot]