uTorrent 1.7.7

I've recently upgraded to version 1.7.7 from 1.6.x (as I remember). When uTorrent is running all browsers extremely slow down (I guess that not only browsers but any program that uses internet connection). The worst thing is that there is a huge delay while reaching 127.0.0.1 where my local server is running (Apache + MySQL). Without uTorrent everything is fine. I had to install BitComet to avoid the connection problem. Hope you'll solve it.

P.S. System was recently reinstalled (Win XP SP2). ESET Smart Security package was also installed but it doesn't block uTorrent so it's not the source of problems.

Have you tried uTorrent with ESET uninstalled?

Have you followed http://forum.utorrent.com/viewtopic.php?id=15992 yet?

Bet you raised your half-open.

I think I have the same problem: torrents download but browsers (and all other software requiring connections) time out. Even tracker update times out (and results in red icon in uTorrent).

I reverted back to 1.7.6 and everything works fine again. I haven't changed a single additional option.

Thanks. Awesome client, by the way! The only one I use.

Read the link DWK posted then.

I found this also, and I think I found the root cause (it sure looks like a utorrent bug in the connection teardown code) and a 3-part solution:

http://forum.utorrent.com/viewtopic.php?id=36396

If you're on torrents that are actively attacked by anti-p2p organizations, and using ipfilter.dat, this bug will cause your PC to soon come to a screeching halt. In this case you could remove ipfilter.dat, leave that torrent, or hope for a bugfix.

Unfortunately this means that those IP's that are blocked can trivially mount a DOS attack on your PC with only a few thousand connection attempts, if you are using ipfilter.dat.

Kimmy

Spamming what you THINK is the root cause won't get your issue looked at any faster. If anything, this will make us ban you for cross posting.

Sorry... There was no reaction from the moderators to my posts, even though you guys are quick to point out the 15992 post which is rarely helpful I think.

Maybe you could ack with "got it, looking into it", then I would know my post was noticed and I wouldn't try so hard to get the developers' attention.

I am looking forward to an assessment of my alleged root cause.

Thanks

Spamming it won't make them look at it any faster. The dedicated staff are overworked. Multi-posting only adds to the workload of those who frequent the forums' cleanup duties.

Through the entire post you made, you didn't mention your net.max_halfopen, nor did you mention what internet security software you had installed.

my net.max_halfopen setting is at its default, 8

Other than Spybot 1.52, and a fully patched up XP installation (SP2 with all the hotfixes), I use no internet security software. The firewall and virus protections of Windows are both disabled.

Also I pass all HTTP traffic through a linux squid proxy which removes access to ad servers. This is an external proxy, and utorrent traffic doesn't go through it.

My router implements the firewall, and it's configured to only forward my utorrent port to the PC.

"even though you guys are quick to point out the 15992 post which is rarely helpful I think."

That post asks for specific info if it fails to help.

You're more than welcome to contribute improvements...but your solution is for a specific situation that tends to only occur with Windows Vista and a router with loopback NAT enabled while using a 'big' IPFILTER.DAT file on a torrent that is heavily infested with hostile ips. And I think there's other conditions you have that makes the problem worse...or even occur at all! (3rd party router firmware bug/s? strange/incompatible software on your box?) That is somewhat unlikely to be the cause of many people's problems.

Actually, I run XP, not vista.

I disagree that my configuration is the only config that triggers the bug. However, I have not tested others. It's not for me to generalize.

It may also be that while being tech savvy enough to use Wireshark and know about TCP connection and teardown handshakes, run a transparent proxy, etc, my computer is infested as you say.

I would like to invite you to test for this bug on a machine of your own choosing. Here're a configuration that I believe will expose the bug:

1. Take two instances of utorrent (pehaps two computers are required)

2. Get them to share a test torrent, made specifically for the purpose (so that no other peers enter the picture).

3. On one of the instances, enable an ipfilter, in which you list ONLY the ip of the other instance. Enable logging of peer traffic to file on this instance.

4. It doesn't matter what tracker you use. Hopefully you have one set up for testing.

After a few minutes, use the log file to count how many times the blocking instance has received and blocked connections ("grep -c blocked utorrent.log"). Then, run netstat -ano, and count how many connections in the FIN_WAIT_2 state, and belong to the utorrent PID. Do this at regular intervals, noting the similarity between the two numbers.

Allow enough time to pass for the numbers to settle to a maximum (it will probably be many thousands). Then, try to browse. Also, try to ping the blocking instance's IP from an external source, and note the round trip time.

Then, draw your own conclusions.

I know it's easy to point the finger in an unrelated direction, but do some basic testing before you yield to that craving, especially when the evidence is quite clear.

BTW, can you tone down the big font, red, bold CAPITALIZATION in your FAQ's ? You're not dealing with total morons, and I can only assume you wouldn't like it if people talked at you like that.

I've followed your instructions, and haven't seen any connections stuck in FIN_WAIT_2, even after an hour of waiting. Yes, every few minutes, I see 2 connections blocked in the Logger tab for the instance with ipfilter.dat enabled, but (again) netstat -ano shows absolutely no connections stuck as you described.

(I manually reloaded ipfilter.dat, which explains the bit about loading in the Logger tab)

Emphasizing something does NOT equate to treating the reader as a moron. Interpret the font weight/color/size as you wish, but you haven't been around here long enough to realize how many people DON'T read things carefully. On that note, you also haven't been around here long enough to see how many times problems were solved simply by having users follow the suggestions in that thread, so there's little truth behind your opinion:

you guys are quick to point out the 15992 post which is rarely helpful I think

(my emphasis added, obviously)

That's not to say that this is the solution to every problem (clearly, we can see cases where it's not), but considering the frequency with which it *does* work, and the fact that it helps with followups by asking for additional information to help us help the user with troubleshooting, I don't see any problem with being "quick to point out the 15992 post" (it's proven its utility).

Ultima, thank you for trying the scenario I suggested.

I am surprised that you are not able to reproduce the behaviour I am seeing, and I will look a little deeper into this myself.

What version of windows are you using? and I assume you use utorrent 1.7.7 as published on the front page?

It was perhaps wrong of me to comment on post 15992 without being here longer, so I'm sorry if I did so prematurely. It sure sounds though that people can't find if indeed it helps and yet it has to be pointed to so frequently.

Thanks

K

I'm using XP with SP2, and I've tried both 1.7.7 and the 1.8 alpha -- neither exhibit the problem described.

People have to be manually directed to the thread because they don't read the stickies like anyone should when they join a forum. Some people don't even notice the big fat Announcement up at the top of every single forum page, and continue to ask for support with whatever they download.

FIN_WAIT_2 is a connection state handled by the OS, not µTorrent. In other words, Windows is waiting for an ACK from the other side to fully close the connection (after µT sent a FIN). It is no longer in the hands of µTorrent at this point.

It probably is possible for a lousy firewall or something similar to screw it up, because it is kernel mode software and could directly interfere with this.

I understand that FIN_WAIT_2 is a connection state handled by the OS. I also understand that the OS may or may not handle it as expected (ie, reseting all such connection when the owning process exits).

There is no firewall installed, and nothing else than Spybot.

I ran the same test I suggested, and I found results similar but not identical to Ultima's. Ie, after a 3-hour run, I only got 5 stuck connections.

I monitored all packets with Wireshark, and on most connection attempts, the blocking ut resets the connection (sends ACK, then RST), but on some it ends with FIN ACK. About 90% of the time it ends with FIN ACK, the connection ends up stuck.

It is my understanding that bugs in an application can and sometimes do trigger bugs in an OS, even though it's not supposed to be that way.

Since utorrent only attempts a connect every minute on average (I found the interval is random), I ran the following script to generate a lot more connection attempts, and ran it from a host that is blocked. As expected, this caused the blocking utorrent to leave a lot more connections in the FIN_WAIT_2 state. I do understand that utorrent does not have direct control of the TCP algorithm, but it does indirectly drive it.

while true; do echo ConnectFromNC | nc 192.168.20.151 15104; done

This uses netcat (nc) in a cygwin shell to connect to the utorrent host repeatedly. Doing this results in a connection rate of 1 every 400ms on my network. It would be equivalent to a very mild DOS attack. (I get more connections than this when I actually share files)

It looks like with this script, about 90% of the attempts are ended with "FIN ACK", and about 90% of those are left in the FIN_WAIT_2 state, even though I can clearly see the FIN-ACK exchange done in both directions.

The same connections are completely finished on the blocked host (ie, no FIN_WAIT_2 there).

Ultima, would you mind testing this netcat attack on your setup?

Tested with a real Linux installation. It was hammering µTorrent with ~75 connection attempts per second, and still nothing -- connection attempts were closing properly. I saw FIN_WAIT_2 appear in netstat every once in a while, but they disappeared the next time netstat updated (netstat -ano 1), and TCPView didn't see any connections in FIN_WAIT_2 state. I tested for ~15 minutes this time without any positive results, so I simply stopped it. All connections died in a timely manner.

All the while, µTorrent was blocking the IP, and I simply saw "write error: Broken pipe" in Terminal.

Edit: FWIW, I have seen FIN_WAIT_2 connections in normal µTorrent operation that took a while to close, but they never actually accumulated -- they did close after a while. I'm not sure what to say here... things seem to be pointing at something in your setup being the problem (unless you have other things for me to try to see if I can reproduce the problem?). If so, then exactly what it is, I'm not sure either. Basically, nothing conclusive is turning up here :/

I've done some more testing here on two more PCs: One running XP SP2, and the other Win2K SP4. The results on the other XP machine are consistent with mine (lots of FIN_WAIT_2), but the Win2K machine was well behaved, showing only TIME_WAIT connections that expired timely, as you have seen.

So I've done a little more testing on the XP machines. I'll explain what I did shortly, but these tests point in the direction of a race condition in the XP kernel, relating to closing an accepted connection that has pending data, but without reading the data. If the close() is delayed somewhat (tens of ms), the issue never occurs even on my XP boxes. If XP sends the FIN/ACK within 500us of receiving the first data, the connection ends up as FIN_WAIT_2 much of the time, but not always. If XP sees data more than 500us before it is ready to close, it sends RST instead of FIN/ACK. If XP sees data between sending FIN/ACK and receiving FIN/ACK, the connection ends up as FIN_WAIT_2 most (all?) of the time.

Anyway, using a simple echo server, I can get rid of the FIN_WAIT_2 states completely if I insert a select() with a timeout of 30ms+ between accept() and close(). I tested this by hammering the echo server for ~2 hours with 30 connections/second, and not a single FIN_WAIT_2. Now if only I had a way of putting a 30ms delay between utorrent's accept() and close()...

I am seeing a few broken pipe errors too, but I believe those mean that nc has already received the FIN/ACK from utorrent before it was ready to copy the output of 'echo' to the socket. In these cases, I would not expect FIN_WAIT_2 at all. The problem is when data is sent before the FIN/ACK is received. Have you looked at the wire with wireshark? It's possible that your utorrent machine is so fast that it is always able to send the FIN/ACK before the remote end sends data. If you're seeing broken pipes for every connection, it means your setup is too fast to even see the conditions that seem to cause the error (ie, 1st data packet received @ utorrent at about the same time as it is sending FIN/ACK)

I am instrumenting an echo client to send data at various delays after connect, to see if there is a range of delays where XP is more sensitive.

Since your connection rate is so much higher than mine, it could be that the performance differences between our computers could also hide some effects. My PC is a few years old, a P4/2.8GHz with 1GB or RAM, with gigabit nic, sitting on a 100Mbps LAN.

Anyway, I'll instrument an echo client and run some more tests to get more hard data and I'll let you know what I find.

It's also possible that in the torrent of hotfixes from Microsoft, some errored out and were not properly installed on my system, so I may very well have one or two DLLs out of date. (my tcpip.sys is at 5.1.2600.2892, how about yours?)

I noticed in your screen capture that you're runnig several utorent instances on the user account? How is this possible?

You have broken software installed sir. Even I don't suffer this, and MY computer is "ancient" considering your few years old computer suffers this. amd xp 2000+ *that's under 2 GHz* and I've stress tested up to 50 halfopen :/ I don't know what else to say

Have you tried running a HijackThis! log and going through everything?

@Kimz: My tcpip.sys file has a version number of 5.1.2600.3244 from October 30, 2007 (unpatched). Regarding multiple instances... see this.

I have run Hijackthis, and removed a couple of old entries that are no longer necessary (old printer driver), and some entries without descriptions, but I didn't find anything suspicious. No behaviour change after the cleanup, either.

The fact that my wife's PC experiences the same behaviour, even though it is much newer, and very different than mine (she has an AMD X2 Dual Core 3800+ on Asus MB, wireless lan, XP SP2, new since about 6 months ago), and not nearly as much software installed as I do, is quite interesting.

But, I did test two PC's at work, and could not reproduce the FIN_WAIT_2 state. So I've started comparing DLL versions that I use at work with those from home, and also registry TCP/IP settings. Since there are many expected differences, the comparison is going slowly.

I'll have to spend more time digging.

Kimmy

Intel C2D E6600 here.

Just to be sure it wasn't because I was doing everything locally that I didn't notice the problem, I tried connecting from a remote machine on my network, and still, connections were dying normally.