TCPIP.SYS Updated

Microsoft updated TPCIP.SYS in today's (14 June 2006) release of Windows XP critical updates resulting in the half open connections limit being reset to 10. Anyone who has increased their half open connections limit with the LvlLord patch needs to re-patch after installing today's Windows XP updates.

ammm yeah, normally it is recomended after every windows update to apply the patch again, or at least look if it changed the limit, it is a known issue that microsoft sometimes reset the patch

Only by pure coincedental accident... I'm sure.

btw: I'm back

I stopped using Bit Torrent for awhle as I got into Rapget ( )! Most of you probly don't know or don't care but I do! Glad to be back.

Hmmm...I didnt get the patch yet. Do you know if the office updates change the limit too?

nah, only windows ones

nah, only windows ones

Specifically, any time TCPIP.SYS gets updated. It's not every single month, but it's pretty damn close. Worth it just to run the EvID patch post-updates to check and see if the limit's been reset on you.

Limited number of simultaneous incomplete outbound TCP connection attempts— The TCP/IP stack now limits the number of simultaneous incomplete outbound TCP connection attempts. After the limit has been reached, subsequent connection attempts are put in a queue to be resolved at a fixed rate. Under normal operation, when applications are connecting to available hosts at valid IP addresses, no connection rate-limiting occurs. When it does occur, a new event, with ID 4226, appears in the system's event log.

From microsoft.com (re win2k3, but this is the exact same thing in xp we're talking about here)

10 half-open simultaneous/concurrent connection ATTEMPTS are more than enough, even for P2P. This limit is a rate limiter, not a connection limiter. You can have tons of half-open connections, just not have them initialised all at the exact same time. Please note the difference between 'half-open connection attempts' and 'half-open connections'.

More info from someone else:

PS:

Halfopen connections are connection requests that you have sent out, but have not received a reply. Setting this to 300 means that your Torrent client will target having 300 open requests to unknown clients at any time, targeting maintaining a total of 60 connections.

So, every time a client drops, you have 59 open connections, and your router pings out to 300 people looking for a new connection. That can add up FAST, especially if you connect to a dozen of them, then drop most of them because you only wanted one to reach your max of 60, then one dies a few seconds later and you do it all over again.

Experiment with this as well as the above: LOWER your Halfopen to something closer to 10-20. I have mine set to 10. This will mean slower startups for Torrents, since your Torrent client will only go after peers in small batches, but you won't have a NAT table full of useless connections so you are better off in the longer term. Then RAISE your max connections to about 200-300 so your Torrent client can find the peers it really wants and keep a relationship with them.

If you really want to find peers in large batches, then at least raise your max connections per Torrent and Global Max up so you can handle them. Your Torrent client is biting off more than it can chew, and expecting your router to absorb the results of its gluttony.

From HyperWRT forum

And another user's experience:

I use to use this fix, and then last time I re-installed I didn't bother. No difference whatsoever.

The main point is that SP2 limits to 10 simultaneous connection attempts, the idea being to slow down/add to security log events where a virus has turned the machine into a spam-bot and is trying to open hundreds of connections a second.

There is no such limit on the number of established connections or total attempts, which is why P2P isn't really affected (most BT clients already have work-arounds in place to optimise behaviour with SP2 anyway).

From whirlpool.net.au forums

Using a patch to increase the TCPIP.SYS half-open connection limit is redundant for anyone not modifying uTorrent's advanced settings anyway, as the default "net.max_halfopen" is set to 8 (at least in the latest beta)! Which is a fine setting, as it leaves plenty of room for browsing whatever else you're doing online. And, heavens forbid, should you ever be infected with a trojan/virus, it'll only make it easier for it to connect outward in bulk, thereby comprising your system and slowing your traffic down (e.g. partaking in a DDoS attack).

In conclusion: don't believe the oodles of misinformation floating outthere and forget this unnecessary patch!

EDIT: I should add my own experience, which is.... no slow down whatsoever with or without the patch! And I run 60-90+ torrents simultaneously on average. Now if you really want to make the most of your bandwidth and time, install a traffic shaper such as cFosSpeed, which prioritizes packets so your browsing will be faster (higher priority than other protocols/apps such as BT) and you can upload at maximum (no need for an upload limit), while still being able to download at full or close to full speeds!

We already know it's not necessary. But people's internet connections stop working when the queue gets full. There are 2 options: decrease net.max_halfopen in µTorrent, or increase the limit. We choose the latter because it stops people from complaining about slow rate of speed ramping, without increase security risk by any real-world, significant amount (if at all) when it is set to *at most* 100.

We already know it's not necessary.

It doesn't show in these threads concerning this topic. Most people see it as a requisite for peer-to-peer use.

But people's internet connections stop working when the queue gets full.

Please cite your source for the queue getting full, not something I've heard of before. Saying your "internet connection stops working" sounds like a huge exaggeration to me, as it's only new connection attempts that would be bogged, not existing half-open, nor existing completed connections.

There are 2 options: decrease net.max_halfopen in µTorrent, or increase the limit. We choose the latter because it stops people from complaining about slow rate of speed ramping, without increase security risk by any real-world, significant amount (if at all) when it is set to *at most* 100.

And neither is necessary. The uTorrent default of max 8 half-open connections falls below the XP limit of 10 simultaneous half-open connections and said limit should therefore not pose a problem. Unless you're running a lot of apps that all try to make a lot of new connections, like port/proxy scanners, proxy checkers, that sort.

In fact, if you see the event ID 4226 in your event log it's due to crappy software that does not limit their concurrent half-open connection attempts, or has a higher limit set than the XP built-in limit. As said, uTorrent (default config) is not one of those apps.

Just because there's crappy software outthere (again, NOT uTorrent), doesn't mean you should patch your system to make it easier on that particular software IMHO. I agree however, that setting it to 100 might not pose any direct risk, but it's still a worse setting (than 10) to have should you get infected with an outbound connecting trojan/virus (and t'is always better to be safe than sorry, especially when it's unneccessary to make the offending change).

If you want proof, you can look around the Speed Problems forum. It's not that it's a requisite in people's eyes, it's that it helps when people can't use their browsers to simply browse anymore, or even if they could, it crawls at snail's pace.

Saying your "internet connection stops working" sounds like a huge exaggeration to me, as it's only new connection attempts that would be bogged, not existing half-open, nor existing completed connections.

Yeah, sorry for not phrasing it correctly earlier. I had meant people couldn't use their internet for any other activity, or barely if they could at all. Again, look around the Speed Problems forum if you really don't believe me, and want proof. I've seen and diagnosed the problem enough times to realize that leaving it unpatched stifles some people's ability to use their internet connection while using µTorrent.

Yeah, theoretically, it shouldn't be happening. But do you realize what happens when people increase their browser's number of connections to servers, and only have 2 half-open connections available, on top of having a bunch of tabs open (the norm nowadays)? The speed of loading webpages that they're used to is instantly marginalized, and they perceive sites as being slower to load with µTorrent open. 10 is too low, considering how people "tweak" their favorite browser to use a bajillion pipelines in connecting to website servers.

As for the security front, unlimited was a real issue. Limiting to 50 or 100 already slows worm propogation significantly in comparison to pre-SP2 days.

As for making it sound like a requisite patch, the only time I do so is if I suspect that someone has already patched TCPIP.SYS, and I simply tell them to repatch. Otherwise, I tell people to try patching, and never say "you have to patch." I've always kept to the opinion that it isn't necessary to patch, and I'm fairly sure the same can be said for most of the other forum regulars as well (Nefarious up above also only said it's recommended, not necessary). If our recommending the use of this patch bothers you, I don't know what to say. It has helped a lot of people already, and we don't tell people to increase it to an unweildy amount anyway -- we know the security risk Microsoft was trying to mitigate when limiting the number of half-open connections.

Fair enough. And in that context it doesn't bother me at all, I just wanted the whole story be clear. The amount of misinformation outthere continuing to be propagated without question just bugs me a little.

As for the speed problems issue, that may be fixed in a better way for a lot of people by using a traffic shaper instead (not to be confused with the tons of registry-tweaking apps that do very little real benefit). Not a lot of routers have traffic shaping built-in yet, but there are software solutions such as cFosSpeed. The tcpip-patch hardly sped anything up for me, cFosSpeed however did. I'll stop there to avoid going off-topic any further and sounding like a shill. ;]

cheers,

It's easy. I use more than 5 networked applications at the same time (some opening as much as 100 connections at the same time) and so I have problems with such limits, so I prefer to patch it than to use less applications or change the way the applications work.

I set mine to 350 (and patched Windows to 400) because I can. Hundreds of torrents (and very few peers, but tons of seeds) sorta requires it.

I have traffic shaping on my router, but PE makes it worthless. So, I use cFosSpeed, and I've never been happier.

I set mine to 350 (and patched Windows to 400) because I can. Hundreds of torrents (and very few peers, but tons of seeds) sorta requires it.

Oh my god, no it doesn't. Please stop the flow of misinformation. Read my posts again. Torrents will speed up a little bit slower right after you start your client, after that it really makes no difference.

Sure it does, for faster startup. It'd take ages for all of them to announce to the tracker AND connect to all the seeders on every single torrent (which is a lot).

=o

Just curious, but... Firon, how many of your torrents do you start simultaneously? All 932 torrents? xD

Um. 150-200 of them?

O.o

I edited what I just posted. I dont feel like getting in this debate anymore All I know is it helped me with connectable/speed? issues. (with Bitorrent and Shareaza) I been P2Ping b4 SP2, during the days of the orig. Napster so Im not just saying stuff off the top of my head or what I read. Thats all Im saying.... One more thing: my browsing got better while torrenting after adjusting the values for the tcpip patch.

(without the patch..) Torrents will speed up a little bit slower right after you start your client, after that it really makes no difference.

Sure it does, for faster startup. It'd take ages for all of them to announce to the tracker AND connect to all the seeders on every single torrent (which is a lot).

Well, whatever you feel you have to do to........ but just for the record, I was talking seconds, not minutes. 'Ages' is definitely an overstatement, particularly considering you never contact all peers on starting a torrent (definitely not on torrents with lots and lots of peers, but often not even on torrents with only a few).

And again, this is the amount of simultaneous connection initiation attempts (not the amount of actual conn. initiations).. incomplete connection attempts usually happen very fast, freeing up attempt slots so quickly, you normally should not reach the limit (and a traffic shaper will completely make sure of it). The problem really only starts when you try to connect a lot of invalid/non-responsive IPs (peers that dropped off the swarm without sending a finall announce for example-- think of a BT client crashing), where it takes longer to verify whether packets to initiate a connection were in fact received/ACK, hogging the queue a little bit longer.

Anyway, like I said.. whatever you feel you have to do or whatever works for you.. just so long as you know both sides of the story. I think we can all agree there.

Unpatched; I experience a decline in performance with Bittorrent but I really (and I mean really) feel it when I stream video or use p2p networks like Gnutella. In fact I just noticed that the limit had been reset after an update last week when I went to CNet and none of the streaming videos worked. I wasn't even doing anything else at the time but browsing. The patch is a must for me, personally.

Ok, I have a realy strange problem so I wont open a new thread ... i'll post here.

After installing the new version of utorrent 1.6 I'm getting the problem with tcp flags. I get every second many tcp flags to port 27524 which i used before in utorrent. And I mean I get those flags/connection from many different IPs even if I close utorrent or change the port. It is very annoying cause my network card freezes when I have ports forwarded and everything goes off. I log this incoming on router (linksys befsr41 v3) log and just continious ... :\ Is it possibly that is cause a utorrent or can be ruter or is some tracker sending me a strange data ???

Tnx for all answers ...

Talking about tcpip.sys, is the x64 version of XP also equipped with the somewhat limited tcpip.sys?

Soggy Bottom, yes, x64 version of xp does also have a limited tcpip.sys.

lvllords patch also works with the x64 version of xp too.

Thanks for info Boo, now i know. Reason for asking is that i´m in the process of migrating over to the x64 platform. I tried today with a uTorrent session on x64, with an unpatched tcpip.sys and had no trouble whatsoever. Infact, the speed was amazing! And no throttling problems like Internet connection stops working.