Failed connections slowly flooding of my connection?

[Switeck]

I'm seeding a 1.6 GB torrent and I keep seeing this in µTorrent's log:

[17:31:38] Incoming connection from 58.8.xx.xxx

[17:32:09] 58.8.xx.xxx : Disconnect: Timed out

[17:33:45] Incoming connection from 58.8.xx.xxx

[17:34:14] 58.8.xx.xxx : Disconnect: Timed out

[17:34:49] Incoming connection from 58.8.xx.xxx

[17:35:18] 58.8.xx.xxx : Disconnect: Timed out

[17:35:51] Incoming connection from 58.8.xx.xxx

[17:36:20] 58.8.xx.xxx : Disconnect: Timed out

[17:39:00] Incoming connection from 58.8.xx.xxx

[17:39:29] 58.8.xx.xxx : Disconnect: Timed out

[17:40:03] Incoming connection from 58.8.xx.xxx

[17:42:38] 58.8.xx.xxx : Disconnect: Timed out

[17:43:11] Incoming connection from 58.8.xx.xxx

[17:43:40] 58.8.xx.xxx : Disconnect: Timed out

[17:44:14] Incoming connection from 58.8.xx.xxx

[17:44:43] 58.8.xx.xxx : Disconnect: Timed out

While another ip 58.8.yyy.yy is using BitComet/0070 that is 10.0% done...but has been inactive for 2h 58m without accepting or requesting any uploads from me.

They're both on the same ISP according to reverse DNS, but 58.8.xx.xxx cannot hold onto the connection (timing out every 29-30 seconds) while 58.8.yyy.yy can stay connected for hours...but hasn't downloaded a thing from me.

I can only think this is a hostile ISP that's throttling BitTorrent traffic to oblivion...and not mine!

Am I off-base here?

Is there any other explaination for why TCP view is showing 5+ failed connections to 58.8.xx.xxx in FIN_WAIT1 state?

(These seem to build up to 10 or more after awhile if I don't manually close them in TCP View.)

Since 58.8.yyy.yy hasn't bothered to download anything from me, I have since broken the connection to it via TCP View. Now it too is attempting to reconnect and failing (timing out).

I am a little worried if enough ISPs do this, this will be detrimental for even those on "good" ISPs just due to the "broken" traffic these ips are still generating.

[TheBear]

I don't think it's ISP tomfoolery as much as two clients configured by people with no clue what they are doing, or worse yet, think they know what they are doing.

[Switeck]

I'm seeing another one now as well that's in a vastly different ip block (124.120.x.x) that's exhibiting the same behavior. Times out every 29-30 seconds after trying to connect...and I NEVER see it in the peers window.

They ALL map out to this reverse DNS:

ppp-xxx.xxx.xxx.xxx.revip2.asianet.co.th

It's a CONSPIRACY I tell ya!

So who/what the heck is this?

...ok, I turned on verbose mode in the logger and now it gets even weirder:

[20:53:43] 58.8.yyy.yyy : [bitComet/0070 ]: Got KeepAlive

[20:54:41] 58.8.yyy.yyy : [bitComet/0070 ]: Send Keepalive

[20:54:43] 58.8.yyy.yyy : [bitComet/0070 ]: Got KeepAlive

[20:54:45] 58.8.yyy.yyy : [bitComet/0070 ]: Sending 4 bytes of aggregated data

[20:54:41] 58.8.yyy.yyy : [bitComet/0070 ]: Send Keepalive

[20:54:43] 58.8.yyy.yyy : [bitComet/0070 ]: Got KeepAlive

[20:54:45] 58.8.yyy.yyy : [bitComet/0070 ]: Sending 4 bytes of aggregated data

[20:55:47] 58.8.yyy.yyy : [bitComet/0070 ]: Got KeepAlive

[21:08:45] 58.8.yyy.yyy : [bitComet/0070 ]: Got KeepAlive

[21:08:50] 58.8.yyy.yyy : [bitComet/0070 ]: Send Keepalive

[21:08:54] 58.8.yyy.yyy : [bitComet/0070 ]: Sending 4 bytes of aggregated data

[21:09:44] 58.8.yyy.yyy : [bitComet/0070 ]: Got KeepAlive

Why would this ip be sending 4 bytes of "aggregated data" over and over again and doing nothing else?

[Firon]

BitComet is a piece of shit client.

[Switeck]

Seeing as how I'm still experiencing these weird failed connections, I don't think BitComet's lack of quality can fully explain it. I don't even know what BitTorrent client 2 of these ips are using. Even though I can tell they've made a connection with my computer according to TCP View and µTorrent shows their connection in the Logger window, they never show up as either a peer or seed on any of my torrents. I thought they may in fact be the ips of the trackers I'm on, but they are attempting to connect and failing far too often for that either.