BitComet? Or a new form of hostile?

I spotted this in µTorrent v1.7's logs:

[12:15:55] Incoming connection from 69.158.152.133

[12:15:55] 69.158.152.133 : Disconnect: No such torrent: *

[12:15:55] Incoming connection from 69.158.152.133

[12:15:55] 69.158.152.133 : Disconnect: No such torrent: *

[12:15:56] Incoming connection from 69.158.152.133

[12:15:56] 69.158.152.133 : Disconnect: No such torrent: *

[12:15:57] Incoming connection from 69.158.152.133

[12:15:57] 69.158.152.133 : Disconnect: No such torrent: *

[12:15:58] Incoming connection from 69.158.152.133

[12:15:58] 69.158.152.133 : Disconnect: No such torrent: *

[12:15:58] Incoming connection from 69.158.152.133

[12:15:58] 69.158.152.133 : Disconnect: No such torrent: *

(this repeats ad-nausem)

* = I removed the torrent value here

After some testing, I discovered the stopped torrent it was asking for and restarted it...and saw this:

69.158.152.133 BitComet/0.0.8.0 I 77.6%

Is this a BitComet standard behavior, a bug intrinsic to only that particular version, or possibly a hack that masquerades as BitComet?

I would certainly prefer the last possibility over the middle, and the middle over the first!

In any case, this behavior is VERY hostile!

I added it to my ipfilter.dat file and immediately received this:

[12:20:01] IpFilter blocked peer 69.158.152.133

[12:20:01] IpFilter blocked peer 69.158.152.133

[12:20:02] IpFilter blocked peer 69.158.152.133

[12:20:02] IpFilter blocked peer 69.158.152.133

[12:20:02] IpFilter blocked peer 69.158.152.133

[12:20:02] IpFilter blocked peer 69.158.152.133

[12:20:02] IpFilter blocked peer 69.158.152.133

[12:20:03] IpFilter blocked peer 69.158.152.133

[12:20:03] IpFilter blocked peer 69.158.152.133

...

In total, 100 blocks in 1 minute!

If this is the standard behavior of BitComet, it deserves nothing but a bad name...because this is EXACTLY the kind of behavior from file-sharing programs that makes ISPs ban them! :mad:

Hm, I haven't seen that kind of behavior from any BitComet/0.0.8.0 peers thus far...

Edit: Yeah, one of 'em tried reconnecting several times, but not at the insane rate that you observed :|

Edit: Its connection attempts seems sporadic...

The same torrent seems to have a second hostile on it:

64.53.218.148 BitComet/0.0.8.0 UO I 46.8

It also exhibits the same behavior if I break the connection and/or stop that torrent...though it doesn't seem to be hammering quite so often:

[12:46:25] Incoming connection from 64.53.218.148

[12:46:25] 64.53.218.148 : Disconnect: No such torrent: *

[12:46:39] Incoming connection from 64.53.218.148

[12:46:39] 64.53.218.148 : Disconnect: No such torrent: *

[12:46:39] Incoming connection from 64.53.218.148

[12:46:39] 64.53.218.148 : Disconnect: No such torrent: *

[12:46:39] Incoming connection from 64.53.218.148

[12:46:39] 64.53.218.148 : Disconnect: No such torrent: *

[12:46:40] Incoming connection from 64.53.218.148

[12:46:40] 64.53.218.148 : Disconnect: No such torrent: *

[12:46:40] Incoming connection from 64.53.218.148

[12:46:40] 64.53.218.148 : Disconnect: No such torrent: *

[12:46:40] Incoming connection from 64.53.218.148

[12:46:40] 64.53.218.148 : Disconnect: No such torrent: *

...So maybe only 20-60 times per minute instead of 100.

Possibly the retry rate is a user-configurable value?

But to allow rates like this, even for testing purposes, would qualify as hostile.

It almost seems like these 2 ips are working together, but the reverse dns values for them suggest wildly separate locations.

Yeah, I also suspect it's a user-configurable behavior.

[13:32:42] Incoming connection from 82.137.249.52

[13:32:42] 82.137.249.52 : Disconnect: No such torrent: *

[13:33:25] Incoming connection from 82.137.249.52

[13:33:25] 82.137.249.52 : Disconnect: No such torrent: *

[13:35:36] Incoming connection from 82.137.249.52

[13:35:36] 82.137.249.52 : Disconnect: No such torrent: *

[13:35:52] Incoming connection from 82.137.249.52

[13:35:52] 82.137.249.52 : Disconnect: No such torrent: *

[13:36:49] Incoming connection from 82.137.249.52

[13:36:49] 82.137.249.52 : Disconnect: No such torrent: *

[13:37:20] Incoming connection from 82.137.249.52

[13:37:20] 82.137.249.52 : Disconnect: No such torrent: *

[13:38:26] Incoming connection from 82.137.249.52

[13:38:26] 82.137.249.52 : Disconnect: No such torrent: *

[13:41:46] Incoming connection from 82.137.249.52

[13:41:46] 82.137.249.52 : Disconnect: No such torrent: *

The attempts are pretty far apart in comparison with your observations (an average of less than once per minute), and after that last one, the attempts have stopped.

Actually, another possibility comes to mind. It could be the number of torrents they're running.

If they only have 1 torrent which has a small peer list, or worse yet a peer list of ONE, then even if BitComet abides by a relatively low half open connection limit of 8...still means it could be attempting the same ip multiple times per second! The limiting factor would then (ironically!) be how fast the ip they're trying responds back and closes the connection.

Hm, I haven't seen that kind of behavior from any BitComet/0.0.8.0 peers thus far...

You mean the DoS like connecting was fixed in 0.80+ or you've never seen that kind of behavior at all?

Switeck, only 1-2connections per second? Your BC-friend is slow

My "friend" is faster and was kind to give me 4MB of log (mostly hammering).

http://www.smail.lt/~stone/2007-01-11_1.txt

http://www.smail.lt/~stone/2007-01-11_2.txt

Also, does Azureus have a DoS plugin?

http://www.smail.lt/~stone/az-hammer.txt

Nah, I don't know about hammering being fixed -- I'm just saying that I haven't seen it in action yet

I guess I just never noticed it before because I rotate ports occasionally. Also any ip that would hammer that hard tends to quickly download the torrent and leave.

...though the BitComet SEEDS that do this are doubly annoying when I'm trying to seed too!

There are two problems with BitComet, the main problem A) the manual connect button that newbies & noobs pound away on.

And BitComet's users need to configure their client:

In bitcomet the number of your upload slots is related to your max global connections and controlled automatically. I.e. if your max global connection is 100, and your global upload rate is 100 kB/s. your could upload to 10 peers at 10 kB/s each or 50 peers at 2kB/s each. This upload slot limit is decided by many elements, such as global connections, global upload rate, global download rate, and simultaneous download task numbers ...

So if users follow the guides at the BitComet forums and properly limit thier upload speed to 85% of the max upload and only run one or two torrents at a time BitComet users will be fine and probably even helpful.

Dark Shroud,

This isn't a manual connect button they're pounding on to cause this "hostile-like" effect. This is automated, goes for HOURS on end, and can progressively create "ghost" connections stuck in a half closed state. This alone can cause crashes for people (on marginal networking hardware/software) on BitTorrent.

When BitComet users run more than 1 torrent at a time and/or set their global upload speed low, they are invariably bad or at least marginal seeds and peers on the torrents they're on. Their upload speed per upload slot is OFTEN less than 0.3 KiloBYTES/sec. I've seen it too many times to assume it's accidental. That the BitComet client not only allows such behavior ...it does it by default... makes it hostile. And short of stopping most/all your torrents and/or reducing global connections to probably less than 30 total to "fix" it, there is nothing you can do! I gave BitComet a run on my box before I formatted, mostly to just try seeding my existing torrents. With torrents that have 2 or 4 MB pieces, uploading at <0.5 KiloBYTES/sec per upload slot means a 1-2.3 hour wait for each piece -- even assuming constant uploading to a given ip!

BitComet v1.0.3 seems to still do this to a lesser degree.

I've got an outgoing encrypted connection to one...and it insists on trying to make incoming UNENCRYPTED connections to me as well!

IP Port Client Flags % Relevance Down Speed Up Speed Downloaded Uploaded Reqs Inactive Hasherr Peer dl. Queued MaxUp MaxDown Debug Waited

64.180.xxx.xxx 8552 BitComet/0.1.0.3 U XE 59.9 0.0 32.2 kB/s 153 MB 58.0 kB/s 80.0 kB 38.7 kB/s 0.5 kB/s 0| -1

[2008-08-11 16:02:08] Incoming connection from 64.180.xxx.xxx:2886

[2008-08-11 16:02:08] 64.180.xxx.xxx:2886: Disconnect: Incoming legacy not allowed

[2008-08-11 16:03:57] Incoming connection from 64.180.xxx.xxx:3290

[2008-08-11 16:03:57] 64.180.xxx.xxx:3290: Disconnect: Incoming legacy not allowed

[2008-08-11 16:08:38] Incoming connection from 64.180.xxx.xxx:3630

[2008-08-11 16:08:38] 64.180.xxx.xxx:3630: Disconnect: Incoming legacy not allowed

[2008-08-11 16:08:59] Incoming connection from 64.180.xxx.xxx:3743

[2008-08-11 16:08:59] 64.180.xxx.xxx:3743: Disconnect: Incoming legacy not allowed

[2008-08-11 16:09:13] Incoming connection from 64.180.xxx.xxx:3771

[2008-08-11 16:09:13] 64.180.xxx.xxx:3771: Disconnect: Incoming legacy not allowed

[2008-08-11 16:11:46] Incoming connection from 64.180.xxx.xxx:3865

[2008-08-11 16:11:46] 64.180.xxx.xxx:3865: Disconnect: Incoming legacy not allowed

[2008-08-11 16:12:20] Incoming connection from 64.180.xxx.xxx:3959

[2008-08-11 16:12:20] 64.180.xxx.xxx:3959: Disconnect: Incoming legacy not allowed

[2008-08-11 16:12:29] Incoming connection from 64.180.xxx.xxx:3998

[2008-08-11 16:12:29] 64.180.xxx.xxx:3998: Disconnect: Incoming legacy not allowed

[2008-08-11 16:13:07] Incoming connection from 64.180.xxx.xxx:4040

[2008-08-11 16:13:07] 64.180.xxx.xxx:4040: Disconnect: Incoming legacy not allowed

[2008-08-11 16:13:45] Incoming connection from 64.180.xxx.xxx:4128

[2008-08-11 16:13:45] 64.180.xxx.xxx:4128: Disconnect: Incoming legacy not allowed

[2008-08-11 16:14:09] Incoming connection from 64.180.xxx.xxx:4170

[2008-08-11 16:14:09] 64.180.xxx.xxx:4170: Disconnect: Incoming legacy not allowed

[2008-08-11 16:15:52] Incoming connection from 64.180.xxx.xxx:4276

[2008-08-11 16:15:52] 64.180.xxx.xxx:4276: Disconnect: Incoming legacy not allowed

[2008-08-11 16:16:42] Incoming connection from 64.180.xxx.xxx:4372

[2008-08-11 16:16:42] 64.180.xxx.xxx:4372: Disconnect: Incoming legacy not allowed

[2008-08-11 16:16:54] Incoming connection from 64.180.xxx.xxx:4415

[2008-08-11 16:16:54] 64.180.xxx.xxx:4415: Disconnect: Incoming legacy not allowed

This looks to be either a fake, possibly Thunderbolt, or a modded version of BC. There were a few "patches" floating around for BitComet. One changed the client ID & announce. Others messed with internal settings. BitComet 1.03 has very limited settings, nothing on rate of connection for BitComet.

FYI, 0.70 was the last fully stable version of BitComet.

Actually, this may still be standard behavior for BitComet...

The half open rate that BitComet IS set for probably won't be exceeded when it's only contacting me once every 5+ seconds.

BitComet may just not have a cooldown timer for EACH peer/seed it tries to connect to, so as long as the half open rate is high enough and there's few peers/seeds to try...a single peer/seed may be retried rather quickly. (See above for examples!)

BitComet may allow multiple connections per ip, either by default or by a settings change. I believe there's even a setting similar to that in uTorrent's advanced settings. I had an outgoing encrypted connection to that BitComet client, so MY port wouldn't match up with an incoming attempt on my ip...BitComet may not recognize that it was already connected to me for that reason.

The reason why the incoming connection is unencrypted is probably due to default settings as well...it possibly attempts an unencrypted connection first and then if it fails it tries an encrypted one. Really though, it should probably do the reverse.

Lastly, yes it COULD be a fake client...or hacked client. But this behavior was definitely "normal" for BitComet in the past.

I believe BitComet still defaults to allowing 10 downloading torrents at once...and I don't know how many seeding torrents at the same time. It cannot be totally blamed on "newbie error" when the default settings are so bad and there's no good setup guide (like uTorrent has) with BitComet. BitComet is just still slightly hostile by design.