XPSP2 will limit your max. connections/sec


Recommended Posts

I suggest a mod close this topic.

First of all the title itself is incorrect.

Most people just read the title.

XP does not limit maximum connections

It only limits connection to a host which could not be connected to earlier.

This prevents programs from repeatedly trying to connect to hosts which do not exist -- behaviour you would see in spam clients or worms.

Link to comment
Share on other sites

yes, but it it still affects filesharing clients like Shareaza.. maybe other clients are working correctly (which I doubt), but Shareaza doesn't when you don't apply the patch..

Link to comment
Share on other sites

As does shareaza for me.

Don't complain that it's not an easy reg-key type fix; if it were, it could be easily circumvented by malware.

At any rate just be glad that joe user's infected trojan/worm factory will be that much slower at throwing out crap. I say good idea MS, but it does need to work around the P2P issue.

Link to comment
Share on other sites

Yes, and I'm glad that people running tests using Kazaa (!) of all things are concerned about unlimiting their tcp/ip connections. Same people that are probably complaining about the Security Center, not using an antivirus, or any type of firewall.

I say let the P2P software makers become compliant to the new security features of SP2 if they need to, not lessen security with some half-ass hack using files from beta versions of service packs, just so you can download minutely faster...which has yet to be proven, because my bittorrent connection has been, if anything, more stable and *faster* since SP2.

Link to comment
Share on other sites

I'd like to think I'm capable of handling how my system uses sockets enough to not have M$ act as a govt and simply limit the number of concurrent sockets in a supposed act of "security". There is NO security is limiting sockets in the TCP layer.

P2P apps rely heavily on multiple connections, as is the entire point of p2p in the first place. Limiting these connections will only hinder applications that use multiple sockets for its functionality as well as overall bandwith benefits of higher connection counts.

Asking software developers to "become compliant to the new security features of SP2" is the most rediculous comment I've heard so far. Well, at least second to the comment about how limiting user's capabilities in the name of security is a good thing. True, worms wont spread as fast as they are currently designed, but its not that hard to limit scanning to the "new super secure limited way" (see reducing 128 scan threads to 10 for example).

I feel M$ has no right to limit anything. I do somewhat understand why they would do it in terms of the fact that most people are complete idiots and have no idea what they're doing on their computer. It would save these kinds of people from hurting themselves, getting infected by viruses they wouldn't have gotten infected with if they had a bit of sense.

Not only does this restrict simply the number of connections, but you can kiss raw sockets goodbye. Remember creating/modifying those raw packets (for whatever reason) ? Forget it, because this limitation will remove the ability to do such things.

Its a new kiddie world, and everyone is invited to have their OS simplified and functionality limited because everyone is stupid.

Link to comment
Share on other sites

After digging through MS's website a bit I found some more detailed info on the restrictions they put on raw sockets and how they limited the number of simultaneous incomplete outbound TCP connection attempts. Here's the link.

Restricted traffic over raw sockets

A very small number of Windows applications make use of raw IP sockets, which provide an industry-standard way for applications to create TCP/IP packets with fewer integrity and security checks by the TCP/IP stack. The Windows implementation of TCP/IP still supports receiving traffic on raw IP sockets. However, the ability to send traffic over raw sockets has been restricted in two ways:

- TCP data cannot be sent over raw sockets.

- UDP datagrams with invalid source addresses cannot be sent over raw sockets. The IP source address for any outgoing UDP datagram must exist on a network interface or the datagram is dropped.

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 and will be resolved at a fixed rate. Under normal operation, when applications are connecting to available hosts at valid IP addresses, no connection rate-limiting will occur. When it does occur, a new event, with ID 4226, appears in the system?s event log.

So basically it shouldn't matter that much for BitTorrent clients. Under certain circumstances it may take a bit longer to connect to seeds/peers but it shouldn't really block anything nor limit your download speed. I am not sure how this may interfere with other P2P protocols and Bittorrent trackers as I am not familiar with them, but I can imagine for clients/servers that _continiously_ have to connect to other hosts at a fast rate (and if some if these connections fail), this "queueing" of connection attempts could slow them down a lot. I can not provide a definitive answer for this, because it really depends on the rate at wich these queued connection attempts are being processed.

The restrictions in the use of raw sockets seems a very wise choice. A lot of DDoS attacks at the moment are being done by 'hordes' of machines infected with trojans that are basically sending out spoofed (fake, randomised source IPs) packets targeted at one, or a select group of hosts. With SP2 these packets will not be send. This means that these trojans used for DDoS attacks will have to revert to using non-spoofed packets, which makes it a lot easier to block a DDoS attack (kinda depends on how many machines are being used in a given attack). At the same time I realise that this restriction can be a real pain for network and security specialists.

Hope this helps.

Edited by Aphax
Link to comment
Share on other sites

the least they could have done is made this patch just for Home edition and not Pro

Perhaps, but I think that all the "pro" users that for some reason need unrestricted access to raw sockets or be able to continiously open connections to hosts at a fast rate, will be able to install that fixed tcpip.sys. Personally I'd rather have it back as it was in SP1, but I can't blame MS for doing this. They've been under pressure to make Windows XP more secure, and at least by limiting the use of raw sockets, that's exactly what they've done.

Link to comment
Share on other sites

but you can kiss raw sockets goodbye. Remember creating/modifying those raw packets (for whatever reason) ? Forget it, because this limitation will remove the ability to do such things.

Good, raw sockets should never have been implemented in the first place. That was a huge security mistake.

Link to comment
Share on other sites

Just to clear up some confusion since this topic was recently linked to, the file in question from SP2 does NOT affect any P2P applications. It does not limit your max connections in any way at all, and thus will not affect you at all. Also, it does not affect any P2P applications. Me and many other users are unpatched and experience no difference, if you have an issue try disableing SP2's firewall.

See my post here for more info:

https://www.neowin.net/forum/index.php?show...#entry584348912

Link to comment
Share on other sites

As does shareaza for me.

Don't complain that it's not an easy reg-key type fix; if it were, it could be easily circumvented by malware.

At any rate just be glad that joe user's infected trojan/worm factory will be that much slower at throwing out crap. I say good idea MS, but it does need to work around the P2P issue.

which version of Shareaza?

cause i needed to patch my Tcicp.sys file for it to even connect to the networks....

Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.