Hi
Just found this in my event-log after starting emule:
"EventID 4226
TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts"
This is what I get from a Microsoft-Guy when i asked him why XPSP2 slows down programs like emule which open many connections to different destinations:
"Thanks very much for responding. This new feature is one of the stack's
"springboards", security features designed to proactively reduce the
future threat from attacks like blaster and Sasser that typically spread
by opening connections to random addresses. In fact, if this feature had
already been deployed, Sasser would have taken much longer to spread.
It's not likely to help stop the spread of spam unless spammers are
trying to reach open email relays in the same way, by opening
connections on smtp ports of random IP addresses.
This is new with XP SP2 and we're trying to get it right so that it does
not interfere with normal system operation or performance of normal,
legitimate applications, but does slow the spread of viral code. New
connection attempts over the limit for half-open connections get queued
and worked off at a certain (limited rate)."
If anyone knows how to switch it off please leave a comment...
Its from Warp2search.net
well that explains my crappy luck with bittorrent recently... 
uhg.
well... JEEBUS.
I noticed something a little... POOR about how this works. They better get this straight. If I want to open lots of connections.. I damn well want to be able to!
I noticed something a little... POOR about how this works. They better get this straight. If I want to open lots of connections.. I damn well want to be able to!
Well iam sure someone will find a way to disable it but until then i guess iam staying away from SP2
hmmm, pretty aggressive solution, particularly since the integrated firewall is supposed to stop these type of problems...
that explains a lot. thanks 
now just gotta get around it...
now just gotta get around it...
(bell == ringing...) That sounds really familiar, Give this stuff a shot.QUOTE
Microsoft published how to harden NT's tcpip stack against these attacks.
The registry hacks documented here are taken from Microsoft sources.
Synattack protection involves reducing the amount of retransmissions for
the SYN-ACKS, which will reduce the time for which resources have to remain
allocated. The allocation of route cache entry resources is delayed until a
connection is made. If synattackprotect = 2, then the connection indication
to AFD is delayed until the three-way handshake is completed. Also note that
the actions taken by the protection mechanism only occur if TcpMaxHalfOpen
and TcpMaxHalfOpenRetried settings are exceeded.
Apply the following registry hack:
Hive: HKEY_LOCAL_MACHINE
Key: SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Name: SynAttackProtect
Type: REG_DWORD
Value: 0
no syn attack protection
Value: 1
reduced retransmission retries and delayed RCE ( route cache entry ) creation
if the TcpMaxHalfOpen and TcpMaxHalfOpenRetried settings are satisfied.
Value: 2
adds delayed indication to Winsock to setting of 1
When the system finds itself under attack the following options on any socket
can no longer be enabled : Scalable windows (RFC 1323) and per adapter
configured TCP parameters ( Initial RTT, window size ). This is because when
protection is functioning the route cache entry is not queried before the
SYN-ACK is sent and the Winsock options are not available at this stage of
the connection.
TcpMaxHalfOpen
parameter controls the number of connections in the SYN-RCVD state allowed
before SYN-ATTACK protection begins to operate. If SynAttackProtect is
set to 1, ensure that this value is lower than the AFD listen backlog on
the port you want to protect.
Hive: HKEY_LOCAL_MACHINE
Key: SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Name: TcpMaxHalfOpen
Type: REG_DWORD
Value: 100
Professional, Server
Value: 500
Advanced Server
The registry hacks documented here are taken from Microsoft sources.
Synattack protection involves reducing the amount of retransmissions for
the SYN-ACKS, which will reduce the time for which resources have to remain
allocated. The allocation of route cache entry resources is delayed until a
connection is made. If synattackprotect = 2, then the connection indication
to AFD is delayed until the three-way handshake is completed. Also note that
the actions taken by the protection mechanism only occur if TcpMaxHalfOpen
and TcpMaxHalfOpenRetried settings are exceeded.
Apply the following registry hack:
Hive: HKEY_LOCAL_MACHINE
Key: SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Name: SynAttackProtect
Type: REG_DWORD
Value: 0
no syn attack protection
Value: 1
reduced retransmission retries and delayed RCE ( route cache entry ) creation
if the TcpMaxHalfOpen and TcpMaxHalfOpenRetried settings are satisfied.
Value: 2
adds delayed indication to Winsock to setting of 1
When the system finds itself under attack the following options on any socket
can no longer be enabled : Scalable windows (RFC 1323) and per adapter
configured TCP parameters ( Initial RTT, window size ). This is because when
protection is functioning the route cache entry is not queried before the
SYN-ACK is sent and the Winsock options are not available at this stage of
the connection.
TcpMaxHalfOpen
parameter controls the number of connections in the SYN-RCVD state allowed
before SYN-ATTACK protection begins to operate. If SynAttackProtect is
set to 1, ensure that this value is lower than the AFD listen backlog on
the port you want to protect.
Hive: HKEY_LOCAL_MACHINE
Key: SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Name: TcpMaxHalfOpen
Type: REG_DWORD
Value: 100
Professional, Server
Value: 500
Advanced Server
can i make a reg file of this or do i need to fix it manualy
QUOTE (XP_2600 @ Jul 20 2004, 23:08)
Hi
Just found this in my event-log after starting emule:
"EventID 4226
TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts"
This is what I get from a Microsoft-Guy when i asked him why XPSP2 slows down programs like emule which open many connections to different destinations:
"Thanks very much for responding. This new feature is one of the stack's
"springboards", security features designed to proactively reduce the
future threat from attacks like blaster and Sasser that typically spread
by opening connections to random addresses. In fact, if this feature had
already been deployed, Sasser would have taken much longer to spread.
It's not likely to help stop the spread of spam unless spammers are
trying to reach open email relays in the same way, by opening
connections on smtp ports of random IP addresses.
This is new with XP SP2 and we're trying to get it right so that it does
not interfere with normal system operation or performance of normal,
legitimate applications, but does slow the spread of viral code. New
connection attempts over the limit for half-open connections get queued
and worked off at a certain (limited rate)."
If anyone knows how to switch it off please leave a comment...
Its from Warp2search.net
Just found this in my event-log after starting emule:
"EventID 4226
TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts"
This is what I get from a Microsoft-Guy when i asked him why XPSP2 slows down programs like emule which open many connections to different destinations:
"Thanks very much for responding. This new feature is one of the stack's
"springboards", security features designed to proactively reduce the
future threat from attacks like blaster and Sasser that typically spread
by opening connections to random addresses. In fact, if this feature had
already been deployed, Sasser would have taken much longer to spread.
It's not likely to help stop the spread of spam unless spammers are
trying to reach open email relays in the same way, by opening
connections on smtp ports of random IP addresses.
This is new with XP SP2 and we're trying to get it right so that it does
not interfere with normal system operation or performance of normal,
legitimate applications, but does slow the spread of viral code. New
connection attempts over the limit for half-open connections get queued
and worked off at a certain (limited rate)."
If anyone knows how to switch it off please leave a comment...
Its from Warp2search.net
This is the key to add to modify the maximum number of simultaneous connections
TcpNumConnections
Key: Tcpip\Parameters
Value Type: REG_DWORD - Number
Valid Range: 0 - 0xfffffe
Default: 0xfffffe
Description: This parameter limits the maximum number of connections that TCP can have open simultaneously.
128 decimal or 80 hexadecimal ---------------->>>0xfffffe
Hope fix that
also reads "Yeah the "fix" does not help, setting it to 0 just makes it go back to default too."
followed by:
followed by:
CODE
I have put the following into the reg to see what affect it would have, and it seems to have stoppped the error for the moment..
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters]
"TcpNumConnections"=dword:00000020
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters]
"TcpNumConnections"=dword:00000020
QUOTE (dutchie @ Jul 22 2004, 05:49)
I have seen that lines somewhere two but i cannot find the place in my registry to verifie it.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip]
"TcpNumConnections"=dword:00000080
original
then change "TcpNumConnections"=dword:0xfffffe
if u dont have TcpNumConnections u can add to the registry create a DWORD key
remember to restart after that
im testing that and some other possible chains implicate
cheers
Guys if anyone got a workaround please send.
This TcpNumConnections-"Fix" alone will definately not help, since you'll still get these 4226-TCPIP-Warnings in your Eventviewer
god damn it, no wonder....I hope someone finds a fix that works.
Found this at www.EventID.net
QUOTE
Event ID: 4226
Source Tcpip
Type Warning
Description TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts.
Comments Max A. Kostioukovitch (Last update 7/15/2004):
Info quoted from ntcanuck.com forum: “The limit you are hitting only applies to connections in which the destinations are unreachable. You absolutely should not hit it if you are opening TCP connections to addresses that are live with an active listener on the destination port. It is enforced by the stack and has nothing to do with your firewall software (third party or ours). There is an improvement to this code, which we are planning for SP2 RTM”.
In plain English if it occurs, there are many connection attempts to unreachable addresses like IP scanning performed by virus or a bad configuration.
Source Tcpip
Type Warning
Description TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts.
Comments Max A. Kostioukovitch (Last update 7/15/2004):
Info quoted from ntcanuck.com forum: “The limit you are hitting only applies to connections in which the destinations are unreachable. You absolutely should not hit it if you are opening TCP connections to addresses that are live with an active listener on the destination port. It is enforced by the stack and has nothing to do with your firewall software (third party or ours). There is an improvement to this code, which we are planning for SP2 RTM”.
In plain English if it occurs, there are many connection attempts to unreachable addresses like IP scanning performed by virus or a bad configuration.
So we gonna wait tell the next build and see.
QUOTE (Phonics Monkey @ Jul 23 2004, 00:36)
Found this at www.EventID.net
QUOTE
Event ID: 4226
Source Tcpip
Type Warning
Description TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts.
Comments Max A. Kostioukovitch (Last update 7/15/2004):
Info quoted from ntcanuck.com forum: “The limit you are hitting only applies to connections in which the destinations are unreachable. You absolutely should not hit it if you are opening TCP connections to addresses that are live with an active listener on the destination port. It is enforced by the stack and has nothing to do with your firewall software (third party or ours). There is an improvement to this code, which we are planning for SP2 RTM”.
In plain English if it occurs, there are many connection attempts to unreachable addresses like IP scanning performed by virus or a bad configuration.
Source Tcpip
Type Warning
Description TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts.
Comments Max A. Kostioukovitch (Last update 7/15/2004):
Info quoted from ntcanuck.com forum: “The limit you are hitting only applies to connections in which the destinations are unreachable. You absolutely should not hit it if you are opening TCP connections to addresses that are live with an active listener on the destination port. It is enforced by the stack and has nothing to do with your firewall software (third party or ours). There is an improvement to this code, which we are planning for SP2 RTM”.
In plain English if it occurs, there are many connection attempts to unreachable addresses like IP scanning performed by virus or a bad configuration.
Well it's not bad thing then.
Basically it slows down port scanners?
Right. Most p2p apps fail to cull out the dead wood links that are from users that are offline. They just fill a list of DL options reguardless of whether or not they're really valid (Which I find annoying as hell).
So...The SP2 stack mod is really just cleaning the DL list for you.
As far as port scanners go if it breaking off failed/invalid connections faster, then it'll probably make the scan process faster also. It's just keeping the scanned machind from being loaded down by the scan by slamming the ports shut.
At least that's the impression I'm getting sofar.
Phonics Monkey
So...The SP2 stack mod is really just cleaning the DL list for you.
As far as port scanners go if it breaking off failed/invalid connections faster, then it'll probably make the scan process faster also. It's just keeping the scanned machind from being loaded down by the scan by slamming the ports shut.
At least that's the impression I'm getting sofar.
Phonics Monkey
QUOTE (Phonics Monkey @ Jul 24 2004, 08:49)
Right. Most p2p apps fail to cull out the dead wood links that are from users that are offline. They just fill a list of DL options reguardless of whether or not they're really valid (Which I find annoying as hell).
So...The SP2 stack mod is really just cleaning the DL list for you.
So...The SP2 stack mod is really just cleaning the DL list for you.
Makes sense. I've noticed that since installing the lastest build, progs like Kazaa Lite have been returning fewer results, but I seem to be getting more 'working' downloads. Overall, though, there really haven't been any noticable differences.
Hi everybody!
After almost everybody know, that the TcpNumConnections-Fix does not work, I've created yesterday a fix for that.
It can be found under http://mitglied.lycos.de/lvllord
Please post this to other forums, too. It's hard for me to do it alone *g*
Greetz!
LvlLord
After almost everybody know, that the TcpNumConnections-Fix does not work, I've created yesterday a fix for that.
It can be found under http://mitglied.lycos.de/lvllord
Please post this to other forums, too. It's hard for me to do it alone *g*
Greetz!
LvlLord
Doesnt work for me. TCPIP-Stack doesnt start. No Network after reboot.
XP Pro SP2 2162 german. German Patch.
XP Pro SP2 2162 german. German Patch.
Yeah, I was thinking of trying it, but I don't think the tcp/ip change
has affected my download speeds ( I mostly use bitorrent networks ),
to justify fucking around with my system.
Also, sombody posting a software fix as a first posts sends
my paraniod alarm bells ringing!
Now, if he had pm'd a respected member, got them to try it,
and got them to endorse it, then I might have tried it.
But then again, who would want to run an exe posted to them in a
pm from a new member?
So there you are, that's why I didn't try it, so fuckit.
It would also be difficult to test speeds differences before and after
on p2p networks as they go up and down more than a prozzies g-string anyway!
has affected my download speeds ( I mostly use bitorrent networks ),
to justify fucking around with my system.
Also, sombody posting a software fix as a first posts sends
my paraniod alarm bells ringing!
Now, if he had pm'd a respected member, got them to try it,
and got them to endorse it, then I might have tried it.
But then again, who would want to run an exe posted to them in a
pm from a new member?
So there you are, that's why I didn't try it, so fuckit.
It would also be difficult to test speeds differences before and after
on p2p networks as they go up and down more than a prozzies g-string anyway!
QUOTE (madTaMsKi @ Jul 28 2004, 08:30)
Also, sombody posting a software fix as a first posts sends
my paraniod alarm bells ringing!
Now, if he had pm'd a respected member, got them to try it,
and got them to endorse it, then I might have tried it.
But then again, who would want to run an exe posted to them in a
pm from a new member?
my paraniod alarm bells ringing!
Now, if he had pm'd a respected member, got them to try it,
and got them to endorse it, then I might have tried it.
But then again, who would want to run an exe posted to them in a
pm from a new member?
This is definately not a new thing - People are confusing themselves. XPSP2 features a LOWER value of that same registry entry, not any new fangled feature. If you're getting these errors, you need to rethink using the software causing it as that many connections is totally unneccesary.
Recently, ever since I installed v2162, if I use DC++ and leave it running for a few hours, when I come back I cannot conenct to the Internet through Firefox, nor can I connect to AIM. However, I can still connect to my e-mail through Microsoft Outlook. Would this problem be what is causing me to not be able to conenct? To be able to get Firefox and AIM to conenct again I have to restart my computer. By the way, I am using a wireless connection. Thanks for any help.
There is a FIX but i didnt try it but its seems logically can fix it, i thought that from the begnning its something in TCPIP.dll itself not a value in registry. its look like a new behaviour.
*sigh* I hate this 
And they wonder why I REFUSE to use Windows XP after SP2 is released.
And they wonder why I REFUSE to use Windows XP after SP2 is released.
QUOTE (TranslucentIha @ Jul 29 2004, 02:44)
Recently, ever since I installed v2162, if I use DC++ and leave it running for a few hours, when I come back I cannot conenct to the Internet through Firefox, nor can I connect to AIM. However, I can still connect to my e-mail through Microsoft Outlook. Would this problem be what is causing me to not be able to conenct? To be able to get Firefox and AIM to conenct again I have to restart my computer. By the way, I am using a wireless connection. Thanks for any help.
If you get the relevant entries in your Event Viewer, then yes, otherwise no.
Why are we patching the TCP/IP subsystem when we can use the registry key stated above? What the hell are you guys doing?
Keep in mind this limit is imposed on UNSUCCESSFUL connections. Stop for a second and READ before speaking, jeez.
Keep in mind this limit is imposed on UNSUCCESSFUL connections. Stop for a second and READ before speaking, jeez.
QUOTE (swgreed @ Jul 22 2004, 15:52)
This TcpNumConnections-"Fix" alone will definately not help, since you'll still get these 4226-TCPIP-Warnings in your Eventviewer
And what did you set the value to? 0?
QUOTE (Rafael @ Jul 29 2004, 08:40)
Why are we patching the TCP/IP subsystem when we can use the registry key stated above? What the hell are you guys doing?
Keep in mind this limit is imposed on UNSUCCESSFUL connections. Stop for a second and READ before speaking, jeez.
Keep in mind this limit is imposed on UNSUCCESSFUL connections. Stop for a second and READ before speaking, jeez.
because, dumbass, that registry entry controls Max TCP connections overall, not max TCP connections / second. They're completely unrelated. This limit is new for SP2 and is not controlled by a registry entry that has been present in Windows since at least 2000. Stop for a second and READ before posting, jeez.
i've done a little more research into the proposed fix and have gotten some positive results. i'm about to apply lvllord's patch here and see how it affects this system (build 2149 ATM) and post the results. just for reference, i'm showing 56 incidences of 4226 events since July 23rd (1 1/2 weeks).
QUOTE (dmk @ Aug 5 2004, 00:23)
QUOTE (Rafael @ Jul 29 2004, 08:40)
Why are we patching the TCP/IP subsystem when we can use the registry key stated above? What the hell are you guys doing?
Keep in mind this limit is imposed on UNSUCCESSFUL connections. Stop for a second and READ before speaking, jeez.
Keep in mind this limit is imposed on UNSUCCESSFUL connections. Stop for a second and READ before speaking, jeez.
because, dumbass, that registry entry controls Max TCP connections overall, not max TCP connections / second. They're completely unrelated. This limit is new for SP2 and is not controlled by a registry entry that has been present in Windows since at least 2000. Stop for a second and READ before posting, jeez.
My mistake, I stand corrected. Thanks.
patch applied, system running, network connectivity exists (i'm posting from it right now). all that's left to do is open Azureus and work the crap out of the connection for a while and check the event log. i'll post a summary tomorrow.
So the patch works? Can you confirm? I have severe problems with Shareaza.. and many warning errors about TCP in my Event Viewer...
Yes, I'd like to know as well...I'm running into a lot of problems. Or maybe they fixed this in the RTM?
No patching here , no noticeable decrease in download speeds or connectivity with eMule or Torrents. I have had two or three warning messages in event viewer , but that doesn't mean much.
The problem im finding is that LeapFTP is disconnecting me from our webserver. I got a mate to try it out on the same server but with a different client and he had no problems, he runs SP2 as well, and i have never once had any problem with LeapFTP so i dont think its an issue with the program.
sorry, had to leave town for the weekend. my results:
Event ID 4226 before patch: 56
Event ID 4226 after patch: 1
so works for me on build 2149. after i install the sp2 Final i'll check it again.
just to sum things up, because there's a lot of misinfo in this thread:
What MS has done in SP2 is set a limit on the number of new TCP connections your machine can establish per second. The reasoning behind this is to prevent, or i guess slow the spread of worms that use techniques like picking random IP's to propagate. It's actually not a bad thing to have such a limit, and the idea has been around for a while. Anyone who uses IRC can think of it as flood prevention. Once the max number of connections per second is reached, additional connections are queued and processed at the specified max rate. MS has set that rate to 10 half-open connections. This is a little low, but the average home user probably won't even hit it. There are however a few applications, especially file sharing or p2p programs that do. You can increase the limit from 10/sec to 50/sec which should be enough for anybody.
details can be found here: http://www.lvllord.de/
just one last thing: this is not going to increase your transfer speeds, or fix programs that aren't working. neither does it control the maximum amount of connections you can have. the only way this patch is going to be of any value is if you do have a large number of Event ID 4226 in your event log due to running apps like Azureus, Sharaza, etc. that have a tendancy to connect to a great number of peers in a very short amount of time. Before applying the patch, save yourself some trouble and actually check your event log (Start-Administrative Tools-Event Viewer). If you don't see any Tcpip events with the ID 4226, or even if there's just an occasional few, you probably don't need to worry about it.
all credit and thanks goes to LvlLord for coming up with all this info and the patch.
Event ID 4226 before patch: 56
Event ID 4226 after patch: 1
so works for me on build 2149. after i install the sp2 Final i'll check it again.
just to sum things up, because there's a lot of misinfo in this thread:
What MS has done in SP2 is set a limit on the number of new TCP connections your machine can establish per second. The reasoning behind this is to prevent, or i guess slow the spread of worms that use techniques like picking random IP's to propagate. It's actually not a bad thing to have such a limit, and the idea has been around for a while. Anyone who uses IRC can think of it as flood prevention. Once the max number of connections per second is reached, additional connections are queued and processed at the specified max rate. MS has set that rate to 10 half-open connections. This is a little low, but the average home user probably won't even hit it. There are however a few applications, especially file sharing or p2p programs that do. You can increase the limit from 10/sec to 50/sec which should be enough for anybody.
details can be found here: http://www.lvllord.de/
just one last thing: this is not going to increase your transfer speeds, or fix programs that aren't working. neither does it control the maximum amount of connections you can have. the only way this patch is going to be of any value is if you do have a large number of Event ID 4226 in your event log due to running apps like Azureus, Sharaza, etc. that have a tendancy to connect to a great number of peers in a very short amount of time. Before applying the patch, save yourself some trouble and actually check your event log (Start-Administrative Tools-Event Viewer). If you don't see any Tcpip events with the ID 4226, or even if there's just an occasional few, you probably don't need to worry about it.
all credit and thanks goes to LvlLord for coming up with all this info and the patch.
http://www.lokitorrent.com/torrents-detail...m=6349#comm6349
Anyone seen this? Or has there been another fix or anything yet? I'm scared to try it
Anyone seen this? Or has there been another fix or anything yet? I'm scared to try it
I saw it i might give it a shot
Anyone got it with the final ??
Found! Here is the fix that works:
SP2 NumConnections Patch
Note: after running the prog, XP will complain that a system file was changed. Abort the request, and next confirm with OK that the "damaged" file should be retained.
On many forums all around the planet it is commonly agreed that this is the one patch that works.
Enjoy.
SP2 NumConnections Patch
Note: after running the prog, XP will complain that a system file was changed. Abort the request, and next confirm with OK that the "damaged" file should be retained.
On many forums all around the planet it is commonly agreed that this is the one patch that works.
Enjoy.
Installed. Worked.
yep patched here and it did work fine, any one know if this also appllies to windows 2003 server?
cuz if it does i could have more connections open there (lotsa download on emule on my server not this win xp sp2 client
cuz if it does i could have more connections open there (lotsa download on emule on my server not this win xp sp2 client
The stack change was done in XPSP2 only.
I think it will be applied to Windows 2003 Service Pack 1
why woudl they do that? because a server with only 10 connections, well that would be bad slow network if 25 users want some thin from the file server (think (and hope)) its a Clients only version, of they wold put the max cons. for win2003 @ 100-500 open conections.
(think (and hope)) its a Clients only version, of they wold put the max cons. for win2003 @ 100-500 open conections.
It's a limit on 'half-open' connections as previously stated in the thread, not connections total.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.