Jump to content

Possible bug? - "immortal" µTorrent peer stuck at 6.1%?


Switeck

Recommended Posts

On a torrent I've been seeding for weeks, I've got a peer that has only 6.1%, doesn't download anything from me, is supposedly running µTorrent v1.6.1, has the flags of XE, and has NO problem staying connected to me AND inactive for over a day straight...it's been 18 hours since I last disconnected it only to have it reconnect due to my half open limit in µTorrent being set to 1. (It's a nearly dead torrent, so eventually I reconnect just cycling through the <10 total ips.)

Now what makes this a possible bug is I'm running µTorrent v1.7.2 with these advanced settings:

peer.disconnect_inactive = TRUE

peer.disconnect_inactive_interval = 600 (seconds I presume?)

I changed the second value from 300 (seconds?) to 600. If I'm right about my units, this "immortal" peer has been connected past the peer.disconnect_inactive_interval by 100+ times over!

The ip is in an ISP range I recognize, Cox ISP, which has some throttling/blocking issues with BitTorrent traffic. The torrent is not a significant one in my opinion. So I don't expect it to be hostile, unless it's a "mom-and-pop" home line used as a monitoring hostile.

I just don't know, because it doesn't make any sense to me.

I've got Singapore ips downloading (slowly!) from me, but not this!?

Should I just use ipfilter.dat to ban this ip?

Link to comment
Share on other sites

Me can confirm the observed behaviour running here 1.7.2b3458, no changes to advanced settings except ban treshold *1 and resolve country *true only while running(seeding) torrents where some parts of directory content is(were) set to do not download so I'm not a 100% peer according to the (private) tracker

those peers show up with different percent. (Some make sense as they have for example 90+% like me.

The logger shows that me (and in case peer is 1.72 too) send and recieve regularily "keep alives" even though we both have all we want (but not the 100% of the torrent)

Link to comment
Share on other sites

I turned on Log Peer Traffic AND Verbose mode in the Logger window, and only once saw ANY response from the peer with only 6.1%. It said "[µTorrent 1.6.1 ]: Sending 4 bytes of aggregated data"

I've since turned on "log traffic to logger tab" from the peers window for the odd peer. Sure enough, I see this:

[15:54:47] [µTorrent 1.6.1 ]: Got KeepAlive

[15:54:54] [µTorrent 1.6.1 ]: Got PEX: 1 added/0 dropped

[15:56:42] [µTorrent 1.6.1 ]: Send Keepalive

[15:56:46] [µTorrent 1.6.1 ]: Sending 4 bytes of aggregated data

[15:56:48] [µTorrent 1.6.1 ]: Got KeepAlive

[15:58:43] [µTorrent 1.6.1 ]: Send Keepalive

[15:58:47] [µTorrent 1.6.1 ]: Sending 4 bytes of aggregated data

[15:58:49] [µTorrent 1.6.1 ]: Got KeepAlive

[15:58:55] [µTorrent 1.6.1 ]: Got PEX: 0 added/1 dropped

[15:59:55] [µTorrent 1.6.1 ]: Got PEX: 1 added/0 dropped

It is doing something, so technically it is active. However even if it's in initial seeding mode, it shouldn't be connected to me since I'm a seed. And if it's NOT in initial seeding mode, the only other thing that might make any sense is it's only downloaded 1 file out of the 15 total in this multi-part torrent. That seems to be the case, as the General tab shows the first ~1/5th of the torrent shaded almost solid like some peers have more of this than any other part.

So, as a feature request, can µTorrent in the future no longer maintain connections to seeds if/when all the remaining files in a multi-part torrent are set to "don't download"?

Link to comment
Share on other sites

  • 10 months later...

I am curious as to what this means. I am a little uneasy about this.

incoming connection 69.129.127.103

incoming connection 118.92.166.101

incoming connection 62.68.92.19

incoming connection 124.170.132.43

incoming connection 82.154.252.234

75.168.255.241 [utorrent 1.7.5]:Got KeepAlive

incoming connection 76.201.148.32

incoming connection 66.36.129.250

75.168.255.241 [utorrent 1.7.5] :Send KeepAlive

incoming connection63.3.133.161

75.168.255.241 [utorrent 1.7.5] :Sending 4 bytes Aggregated data

Can someone tell me what this is about? Is there a problem? Should I be concerned?

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...