tcp ip error in the event section

MrGenie

Member
Jul 30, 2007
50
0
0
Event Type: Warning
Event Source: Tcpip
Event Category: None
Event ID: 4226
Date: 10/31/2007
Time: 7:01:15 PM
User: N/A
Computer: GOLIATH
Description:
TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 00 00 00 00 01 00 54 00 ......T.
0008: 00 00 00 00 82 10 00 80 ....?..?
0010: 01 00 00 00 00 00 00 00 ........
0018: 00 00 00 00 00 00 00 00 ........
0020: 00 00 00 00 00 00 00 00 ........



the question, is.... is there a way to prevent this?

im mostly using a torrent client... (utorrent) is it causing this???
 

pallejr

Senior member
Apr 8, 2007
216
0
0
your torrent client sounds like a good candidate. Microsoft introduced it in sp2, to make life harder for worms to spread around the internet. After xx attempts to connect to a nonresponding ip address, further connection attempts will be queued
 

Markbnj

Elite Member <br>Moderator Emeritus
Moderator
Sep 16, 2005
15,682
14
81
www.markbetz.net
I've been seeing this for a couple of years, even after a reformat and reinstall (done for a different reason). I don't know if it's Yahoo widgets, Beyond TV, or just some quirk of the way they implemented the limit. I've used a number of tools to try and figure out who was opening the connections, but whenever I look there don't seem to be all that many active connections open. I sort of gave up caring about it.
 

Smilin

Diamond Member
Mar 4, 2002
7,357
0
0
It really shouldn't be a big deal.

A tcp session is established in what's called a 3 way handshake. All data in a tcp conversation is tracked via sequence numbers. When starting a new conversation the first thing that needs done is the sequence numbers must be synchronized on both ends...

1. SYN Packet. Client sends a TCP packet to the server's listening port with it's own return ephemeral port. To SYNchronize the sequence numbers it uses the SYN flag.
2. SYN-ACK Packet. The server must ACKnowledge packet number 1 so it set's the ACK flag and ACKS the sequence number the client sent. It is also starting it's own set of sequence numbers for data being sent back. To be sure the client knows what sequence we're on it also sets the SYN flag on this packet.
3. ACK Packet. The client ACKs packet #2.

At this point the TCP session is setup, both sides can send info. If you run a netstat -ano at this point you'll see the session as "ESTABLISHED". If you do the netstat -ano just after frame 1, you'll see the session as "SYN SENT". Note: it won't stay in a SYN SENT state for very long so by the time you see an event like the OP posted and get to a command prompt it will likely be gone.


Note that the event seen by the OP does NOT limit the number of connection attempts you can make. It just limits the number of connection attempts in the SYN SENT state. Again, this state goes away very quickly so it should not be a much of a limit for things.

Even with a Torrent or other file sharing app you should be ok. It doesn't limit the number of connections...it just limits the number of half-connections....which should RAPIDLY transition to full connections.