We have an application named "Seamer" installed on 2008R2 machine named "R2DUO" which has IP address set as 192.61.247.37 in host file and 172.26.127.40 is IP address of Ethernet card .We have two more systems in the LAN named R2TMBER and R2LEAF. One functionality should be achieved when there is a connection with port 5009.As of now that functionality is not achieving,, when I checked netstat -a I could see these entries ,
TCP 0.0.0.0:5009 R2DUO:0 LISTENING
TCP 127.0.0.1:445 R2DUO:64181 ESTABLISHED
TCP 127.0.0.1:5009 R2DUO:49519 ESTABLISHED
TCP 127.0.0.1:49156 R2DUO:5009 TIME_WAIT around 50 entries are there now
TCP 127.0.0.1:49519 R2DUO:5009 ESTABLISHED
TCP 127.0.0.1:64181 R2DUO:microsoft-ds ESTABLISHED
TCP 127.0.0.1:65190 R2DUO:5009 TIME_WAIT again 50 entries are there
TCP 172.26.127.42:5009 R2DUO:64445 ESTABLISHED
TCP 172.26.127.42:64445 R2DUO:5009 ESTABLISHED
TCP 192.61.247.37:5009 R2TMBER:50334 ESTABLISHED
TCP 192.61.247.37:61552 R2LEAF:5009 ESTABLISHED
These all are the knowledge which I know as of now ,,first 5009 in listening mode then it will establish coonection.But after that suddenly it goes TIME_WAIT, then establish connection and again goes timewait ,finally it establish connection with two other systems in the LAN. Can any body guide me any thing wrong in the system setup.Or do I need to check any network related stuff. I would like to know the logic behind this sequence in netstat shown below
First it will be 0.0.0.0:portnumber then it will be 127.0.0.1(loopback):portnumber then it is ethernetIp:portnumber finally it will be with ipaddress of system entered in the host file and other two machines etc..
Best Answer
Update based on the comment; Check that the service is not conflicting with some underlying MS service;
Service Name and Transport Protocol Port Number Registry
I think that you might be interested to read the wikipedia article on TCP connection handshaking, and the connection life-cycle, if you were very interested in understanding the netstat information. Also, you mentioned the state of the connection, which relates to TCP socket programming, but you can actually ignore all that, because its actually pretty simple. (well...;-)
When you call
netstat -a
you are asking for ALL connections both listening and connected.Basically the
LISTENING
line indicates that there is some process listening on TCP port 5009, which is good because this is your application...However, when some remote process makes a connection to the TCP socket 5009, the programme controlling 5009 normally forks off another process or thread to handle the connection, so you actually end up with
netstat -a
like this;which is the originally listener, plus the connected remote process. i.e. this is your client programme connecting to the server.
Further connections create additional lines like so;
TIME_WAIT
There is a pretty good explanation of the TIME_WAIT state in this answer here;
https://stackoverflow.com/questions/337115/setting-time-wait-tcp
TIME_WAIT is a status that arises at the end of the connection on the client side, where the client has actively closed the connection by sending an ACK to a FIN, but as is possible that there is still packets coming from the other side of the connection, hence the client connection sits in TIME_WAIT status which is always longer than the packet TTL, see this and that for very in depth discussion of the TIME_WAIT TCP status.
Port 5009 appears to be registered the Microsoft Windows Filesystem (winfs) service, so you would have to provide further details of your services and setup, and what the problem is other than what you have seen on the netstat output.
Loads of TIME_WAIT connections
Basically, you client is connecting, and then immediately disconnecting, many times over, so something earlier on in the application such as authentication, or application protocol mismatch, or something not related to the underlying TCP.
I think this suggests that there is some problem with configuration, in such a way that the client cannot continue once connected, hence the client closes the connection to the server. The result being lots of connections that are quickly closed. hence you see these are TIME_WAIT
Some possibilities for this, are some sort of password problem between the client and server, or some other application misconfiguration which would cause an abrupt close from the client.