All trackers timeout - 1580 open ports

[FriendlyGuy]

Windows XP SP2

No levellord patch; please don't suggest it as I won't let third party software modify system files.

µTorrent 1.7.7

Direct cable connection, no router or NAT

480k upload speed (approximatively, depending on the test server)

80 connections per torrent, 230 global. I tried cutting those numbers in half without effect.

DHT disabled

net.max_halfopen at default (8)

I've run µTorrent in this configuration for years and I've only started having these problems sometime around version 1.7. After running for about 30 minutes, almost like clockwork, all trackers time out. This doesn't seem to happen in very small swarms, e.g. 6 seeds and 12 peers. The latest occurrence is a single torrent with 10 seeds and 76 peers. When the tracker timed out, µTorrent had a whopping 880 ports open. After less than half an hour, it had reached 1550 open ports and was still rising at a rate of about 1 every 2 seconds. No other programs were accessing the Internet, although I tested and web pages still opened in the browser, albeit a bit slower than usual.

At that point, I got really fed up with it and downloaded Azureus for the first time in many years.

109 connections per torrent, 187 global

DHT disabled

I restarted the same torrent from the beginning. After close to 3 hours in Azureus, the number of open ports was oscillating steadily between 54-58. After another hour, it was around 46 open ports. Tracker status OK. Therefore, it's probably a bug in µTorrent—in this case the only thing left to do is to change versions.

I managed to get µTorrent 1.6.1 from the Internet Archive Wayback Machine. Would you consider this safe to use or are there any severe unpatched security bugs? Can I simply replace utorrent.exe or would there be problems if I keep the configuration files?

Would you recommend the latest beta instead? If yes, again, could I keep the configuration files or would problems arise?

[Ultima]

There have been several security fixes for µTorrent since 1.6.1 was released. Its usage is not recommended (and absolutely not supported here either).

Yes, do try the latest beta. And check the first link in my signature regarding interrupted connections for some other suggestions (like lowering net.max_halfopen). If nothing there helps, fill the missing gaps in information you've provided with the requested information (like modem model, or process lists).

[jewelisheaven]

... if you don't have a firewall, all ports are open. I think you mean "open connections", in which case it sounds like you have http://utorrent.com/faq.php#Incompatible_software installed especially if you don't have any higher than xx/384 capacity.

As far as configuration files... you can back them up if you wish, but there's no changes I can recall which would make them incompatible, even from 1.6... except maybe if you have logging turned on, and then upgrade. In Logger tab for 1.8 there are new menu options which some have had troubles turning on/off.

[FriendlyGuy]

"Direct cable connection" means no modem.

Background scanning is disabled in anti-virus and anti-malware tools.

I don't have anything from the list of incompatible software and I don't have any of the issues listed there.

I've already listed my upload speed. 480 > 384.

IP resolving is unchecked, by the way. UPnP is also off.

It makes no sense to lower the settings when they've worked for years—back when my connection was a lot slower. As far as I can tell, the only thing I haven't already tried from the signature link is lowering net.max_halfopen (which is already at the default setting, as it always has been).

I'll have to make some time to try the beta and see how that goes first.

Thanks for the replies.

Update

µTorrent 1.8 beta (build 10198)

net.max_halfopen at default (8)

109 connections per torrent, 187 global. These are the same as settings as Azureus, but note that they're higher than µTorrent 1.7.7.

Same torrent, which has gained a few new seeds and peers. After about an hour, there are no more than 150 open ports. After a little while longer, the number went down to 54, which is comparable to Azureus.

I'm going to assume that the tracker status is OK, although I have no way of verifying: the "Update tracker" option is grayed out. I assume that's a beta bug. There's no tracker information in the "Detailed Info" pane below the torrent and the green smiley next to the torrent doesn't tell me anything (because I know the tracker asks to be contacted every 2 hours and it's only been a little over 1 hour).

I think the best thing to do would be to stop before my ratio takes more of a nosedive and stick with Azureus until the 1.8 final is out. Version 3.0.5.2 is much better than the old one I used to run before I switched to µTorrent.

[Switeck]

Have you also disabled UPnP, Resolve IPs, and Local Peer Discovery in uTorrent?

Are these open ports incoming or outgoing ports?

[DreadWingKnight]

I'm going to assume that the tracker status is OK, although I have no way of verifying: the "Update tracker" option is grayed out. I assume that's a beta bug.

Beta design change. Not a bug. It's to prevent DoS attack level use of the feature.

[FriendlyGuy]

Have you also disabled UPnP, Resolve IPs, and Local Peer Discovery in uTorrent?

I already mentioned that DHT, UPnP and Resolve IPs are disabled. Local Peer Discovery is also disabled.

Are these open ports incoming or outgoing ports?

I don't know. It's possible they were both.

Beta design change. Not a bug. It's to prevent DoS attack level use of the feature.

Does that mean it's not possible to manually update the tracker anymore? That would make no sense. It would take a lot more than manually updating the tracker every now and again to carry out an attack against a server. Why not disable manual updating for a minimum period of time after the last time the option's been used?

[DreadWingKnight]

There is a window defined by the tracker in which uTorrent will permit manual announcing. Anything outside of that window is considered abusive.

[Firon]

It's possible, but the tracker specifies the minimum interval you can announce at.

[Switeck]

In your original post, things seem to "run fine" and then a near-complete failure occurs around the 30 minute mark?

Have you verified that Windows Event Viewer isn't reporting lots of 4226 errors?

How did you verify that no other programs were accessing the Internet?

Are these open ports incoming or outgoing ports?

I don't know. It's possible they were both.

If the same port is repeated 100's of times and incidentally is the same port that you're using as uTorrent's listening port, then it's uTorrent's incoming port that's getting stuck open by numerous ips trying to connect to you.

If the open ports seem to be predominately in the 1000-5000 range, then it's your outgoing ephemeral ports that are getting stuck open.

In either case, you probably need to investigate uTorrent's logs for disconnecting peers/seeds.

Does peers/seeds seem to disconnect quickly?

Do most ips fail to connect period?

Are you firewalled sometimes? ...such as after the tracker/s time out?

[FriendlyGuy]

It's possible, but the tracker specifies the minimum interval you can announce at.

All right, fair enough, I suppose. But there doesn't seem to be a way to see what that minimum interval is, and it doesn't explain why tracker status is gone from the Details Info pane. You could see specific errors that occured, the time left until the next update, the specific tracker being contacted, and so on—why remove such useful information?

I don't know what a "near-complete failure" is, but yes, things run fine for approximatively 30-40 minutes since starting the torrent. Very small swarms run without problems for days on end until completion.

Event Viewer shows four Warnings with ID 4226 for yesterday and the day before, which is when I ran µTorrent. Nothing for the days when I didn't.

I checked that nothing else was accessing the Internet using TcpView.

µTorrent 1.7.7 again

75 connections per torrent, 180 global.

(That's still higher than before, because I tried cutting the numbers in half and it didn't help).

This is really weird. I decided to give it one last try for logging purposes and I started downloading OpenSUSE (tracker.opensuse.org). After 45 minutes, µTorrent only has 4 ports open: two are listed as the one I specified for incoming connections, one is 2239, one 2276, and one 2279. Naturally, the tracker doesn't time out.

I don't think it was a tracker bug before, because it happened on all trackers. I noticed that when I started 1.8 beta, the columns I chose and the torrent order was messed up. I changed it back, then when I started 1.7.7, it was messed up again. Maybe 1.8 beta modified something in the configuration and that fixed it? Or maybe µTorrent 1.7.7 doesn't play well with PeerGuardian? HTTP blocking is disabled, so I didn't think it would be an issue. Either way, it will be some time before I find out; I've had more than enough testing for now.

Thank you for the replies.

[jewelisheaven]

Yes there is: http://forum.utorrent.com/viewtopic.php?pid=317779#p317779

As far as columns: http://forum.utorrent.com/viewtopic.php?id=37405 and http://forum.utorrent.com/viewtopic.php?id=35037 and (my tutorial) http://forum.utorrent.com/viewtopic.php?pid=298209#p298209

[DreadWingKnight]

But there doesn't seem to be a way to see what that minimum interval is, and it doesn't explain why tracker status is gone from the Details Info pane.

And what about the trackers tab? All this information is available there.

[FriendlyGuy]

As far as columns

Thank you, but I don't plan to go back and forth between 1.7.7 and 1.8 beta, so the columns shouldn't be an issue. When 1.8 final comes out, I plan to trash the settings for a fresh start.

I was just wondering if the reset columns and the working torrent meant that 1.8 beta fixed something in the configuration file. That's most likely just wishful thinking. It's far more likely that when PeerGuardian blocks a connection, 1.7.7 doesn't realize it's been terminated and keeps the port open. The more connections are blocked, the more ports are open, until it's unable to contact the trackers. In the OpenSUSE swarm, PeerGuardian didn't block any connections and the number of open ports didn't increase abnormally.

And what about the trackers tab? All this information is available there.

Oh, cool. I had completely missed that. Thanks.

[Switeck]

You might be better off using the ip blocklist directly with uTorrent, via uTorrent's ipfilter.dat file.

[FriendlyGuy]

You might be better off using the ip blocklist directly with uTorrent, via uTorrent's ipfilter.dat file.

I can't do that because I don't use PeerGuardian only for blocking connections in µTorrent. And like I said, I've run it without problems for years (PeerGuardian was last updated on 2005-09-18) up until µTorrent 1.7.x.

Anyway, it looks like I'll just have to wait for 1.8 final. If the problem doesn't go away, I'll create a log file and see if it offers any insight.

Thank you

[Firon]

There's no way around this because of the broken way that PeerGuardian blocks connections. This will happen with -any- application that has a connection blocked by PG.

[FriendlyGuy]

Huh? :| As I said, PeerGuardian has run alongside Azureus and µTorrent without problems for years. It works with Azureus 3.0.5.2 right now and µTorrent 1.8 beta showed nearly identical behavior (as opposed to the problematic 1.7.x).

I tried the converter but my browser froze because of the size of the list. I might try Requi3m's uTorrent ipfilter.dat updater later.

[Switeck]

"I can't do that because I don't use PeerGuardian only for blocking connections in µTorrent."

Eh?

You can't also use the blocklist in uTorrent via uTorrent's ipfilter.dat?

Or is converting the list to a plain ip range format a problem...as your latest post suggests?

[FriendlyGuy]

I meant that PeerGuardian blocks connections in all applications, so I'd still need it, and if PeerGuardian still tried to block the connections from µTorrent, that wouldn't solve the problem. However, I notice in this post you said PeerGuardian tries to block the connections after µTorrent, so it might not try to block what's already blocked in ipfilter.dat.

I also came across merwin's updater but I haven't had time to try it or Requi3m's yet.

[Switeck]

Correct! By adding the ip list to uTorrent's ipfilter.dat then uTorrent would not ATTMEPT outgoing connections to 'bad' ips. ('bad' = in ipfilter.dat...though some in there probably don't belong)

Incoming connections would likely get filtered by Peer Guardian and uTorrent would never see them to block them, so that should work too. Even if uTorrent did briefly see them, uTorrent would (hopefully!) properly break the connection due to the ips being in ipfilter.dat.

[nonan]

Hey, FriendlyGuy, I've had the same problem ever since migrating from Win XP SP2 to SP3. EXACTLY.

I read that the fix was to decrease the half-open setting in TCPIP.SYS from 10 to 8, but this didn't help.

What did is increasing it to 50.

I did this with EventID 4226 Patcher Version 2.23d from http://www.lvllord.de/.

Not only did it fix uTorrent, but it also cured Azureus from crashing.

Unfortunately, it was a bit TOO high, and prevented me from uploading torrents to tracker sites, so I scaled it down to 40, and all appears to be working well.

Cheers and good luck.

[DreadWingKnight]

tcpip.sys patching is not a cureall.