This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Application Connecting/ Disconnecting

0

Hello

I have two Windows 2008 Servers that function as a client/server application.

ServerA is the client ServerB is the server

ServerA needs to connect to ServerB, however keeps reporting frequent Disconnections in the Application log. I ran continous ping from ServerA to ServerB which was fine. The latency was ok too.

I figure the next step is to launch WS for more detailed info, but could anyone give me any pointers on what I'm looking for? (I realise the question is a bit vague!)

asked 04 Mar '13, 16:57

TonyRobbins1978's gravatar image

TonyRobbins1978
6●2●2●4
accept rate: 0%

One Answer:

0

but could anyone give me any pointers on what I'm looking for?

I would do it this way.

  • get a PC that is able to run Wireshark
  • if you don't have a separate PC, the second best option is to run Wireshark on both servers in parallel. The third best option is to run Wireshark on one of the servers.
  • capture data and wait until the server reports those 'frequent disconnects' in its log.
  • stop Wireshark
  • Take the timestamp from the log and look at the captured data in that time window (+/- a few seconds/minutes)
  • "Disconnects", as reported by the application may have several reasons. Start to look for TCP RESETS and closed connections (FIN) in Wireshark.

(I realise the question is a bit vague!)

  • it's hard to tell you what to look for, if we know nothing about the application, the protocol, etc. Can you add some more details about the communication (HTTP, HTTPS, own protocol, TCP/UDP, etc.)

Regards
Kurt

answered 05 Mar '13, 10:40

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%

Thank you for taking the time to answer. I can certainly run WS on both servers, that won't be an issue. The application speaks on its own port (lets say port 4000). Am I correct in saying that I run the trace and wait for the disconnects then filter on the IP addresses or port number? I had a test run when I saw the errors and don't see any RSETS but I do see FIN, ACK packets. Is this the same as a FIN, i.e the first FIN, ACK I see is the from the server requesting the closure? Second question, is there anything in the traces, apart from the time, that I can use to identify the same packets

(05 Mar '13, 11:25) TonyRobbins1978

Am I correct in saying that I run the trace and wait for the disconnects then filter on the IP addresses or port number?

well, filtering on the IP address and the port should go into the capture filter to limit the amount of data you record (http://wiki.wireshark.org/CaptureFilters).

After you see the messages in the application log, stop Wireshark. Take the timestamp from the application log error message and look 'around' that time within the Wireshark trace, if you see anything 'unusual' (whatever that may be for your specific protocol).

Is this the same as a FIN, i.e the first FIN, ACK I see is the from the server requesting the closure?

FIN and FIN, ACK are both part of the connection tear down and you will see that frequently for TCP connections, expect your protocol relies on a long lived TCP connection. So it may or may not indicate a problem if you see FIN packets.

Second question, is there anything in the traces, apart from the time, that I can use to identify the same packets

Without any knowledge about the protocol? None that I know of.

(05 Mar '13, 11:36) Kurt Knochner ♦