On a basic level, when data is sent from one point to another through TCP, in the end, both sender and receiver agree that information is what it should be, and things are alright. Whenever there is a problem with TCP, one of the sides keeps waiting (TIME_WAIT state), there can be the abrupt close of the sessions, which results in RESET flag in the TCP header.
Troubleshoot TCP/IP connectivity
This RESET flag can be seen through the Message Analyzer tool or any of the Network Monitoring Tools which can help you figure out TCP header. The header carries information which helps to identify if there was a problem, particularly RESET flag. Imagine every data sent has a header or transmitter which gives info about whereabouts of data. When using the Message Analyzer, you will have to set up the IP address of the server, the port number if available, and dig into each trace result for detailed information. If there is any error, the tool will mark it. Click on it, and you should be able to see the level of the error message for that packet. It is easy to use, but then it also needs a proper understanding of how to use it.
Finding Packet drops
When data is sent, and no response is received from the other end, it means there is a packet loss. The source waits for confirmation, and when that’s not accepted it will send a ping with ACK RESET flag. This flag means that since there was no confirmation, it means there could be packet drops or data loss and hence the connection is being dropped. It usually means that the network device in between has some problem. Use the Network tool to monitor the ports and run the trace program. If you do not see the same trace results, you know the issue is somewhere in between.
The incorrect parameter in the TCP header
In-between devices and software usually modify TCP headers. It is standard on computers where internet security software changes the certificates coming from HTTPS compliant websites. Devices like WAN accelerators can do the same.IT admin will have to look into the configuration of those hardware devices to solve this issue. To figure this out, you will have run the trace on both source and destination, and if the results differ, especially the TCP packet details, then we have a problem.
Application side reset
If the traces don’t show anything probabilistic, then it could be the application which is causing the issue. It happens when the server has accepted about data received but doesn’t accept the connection. So the application would be like it didn’t get anything, and you would be wondering that all links are in place. You can identify this scenario by looking at the TCP flags. If the packet has ACK+RST it means the application is causing the issue, i.e., destination/server for some reason does not want to accept the package for some reason. If your application is making use of UDP, then it will be difficult to find it this way. Instead, you will have to make use of ICMP as an error reporting protocol. If you notice message ICMP Destination host unreachable: Port unreachable message immediately after the UDP packet, then the application is the cause. Tips: Message Analyzer is a powerful tool which can be used to perform such traces, and check data in real time. If you can master it, you can master the art of troubleshooting TCP/IP connectivity issues.
