1. Introduction
In the previous article, we covered the basics of TCP. From this section onward, we’ll focus on using TCP packet capture examples in Wireshark to diagnose TCP problems commonly encountered in networks. During TCP communication, both parties establish a connection, exchange data, and ultimately close the connection. The process begins with a request sent from the source port to the destination port. Issues can sometimes occur during the establishment or termination of this connection. This article delves into diagnosing TCP problems by leveraging Wireshark’s network packet capture to identify and resolve these network issues.
2. Problem manifestation:
The problem may have many types of manifestations:
· Try to run an application but find that the application does not work. Try to browse the network but cannot get a response.
· Try to send an email but cannot connect to the email server.
· The problem may be caused by simple reasons, such as the server is down, the application is not running on the server, or the network is disconnected somewhere between the client and the server. · The problem may
also be caused by complex reasons, such as DNS problems, insufficient server memory and unable to connect (for example, an application occupies a high memory space), duplicate IP, and other reasons.
Solution:
The following will introduce clues to solve the problem and how to diagnose TCP connection problems by capturing packets. Typically, these problems will result in no output when running an application.
When you are running an application, such as a database client, mail client, watching a video, etc., and you are not getting output, follow these steps to diagnose:
Verify that the server and application are running.
Verify that the client is running, has an IP address configured (manually or through DHCP), and is connected to the network.
Ping the server and verify that the connection is working.
In some cases, the server cannot be pinged but the connection is working. This is due to a firewall blocking ICMP messages, so if you cannot ping, it does not necessarily mean that there is a problem with the connection. The firewall may be a dedicated device in the network or a firewall installed on a Windows/Linux/UNIX terminal device.
5. In the packet capture file, look for the following patterns:
· Triple SYN messages with no response (see the screenshot below)
· SYN messages with a reset (RST) response
In both cases, it is possible that the firewall is blocking the specific application or the application is not running.
The screenshot below is a simple case: the client cannot connect to the web server 81.218.31.171 (packets 61, 62, and 63). It may be that it is not allowed by the firewall or the server is malfunctioning. We can see that the connection to another station, 108.160.163.43 (packets 65, 66, and 67), is working fine, so the connectivity issue is limited to 81.218.31.171.
The following example is a relatively complex case. In this case, the client
wants to log in to the camera server to access the camera at a remote site. The IP address of the camera server is 135.82.12.1. The problem is that the client can see the login window on the server homepage, but cannot log in to the system. In the screenshot below, you can see that a connection is open to the IP address 135.82.12.1. The TCP connection to the HTTP server is open, and there seems to be no connection problems at first:
When we filter out the data flow with the destination IP address 135.82.12.1, which is the camera server, we can see here that when trying to connect to TCP port 6036, we get a RST/ACK response. There are the following possibilities:
· The firewall blocked port 6036
· If port address translation (PAT) is configured, only port 80 is translated instead of 6036
· The username and password verification is done on TCP port 6036, and the firewall only allows port 80, so the verification is blocked and the application does not work
In short, when you cannot connect to the server normally, check whether all TCP/UDP ports on the server and client can be forwarded through the network, and whether there are unknown ports.
Working process:
When the TCP connection starts, the following three steps occur:
1. The client TCP process sends a SYN message. The SYN flag is set to 1 in this message. In this message, the client:
· Specifies its own initial sequence number. This is the first byte that the client sends to the server.
· Indicates its own window size. This is the size of the buffer allocated by the client to the process (located in the client’s RAM).
· Sets the options it will use: MSS, Selective ACK, etc.
2. When the server receives the connection request, the server:
· Sends SYN/ACK to the client to confirm the receipt of the SYN request.
· Indicates the server’s initial sequence number. This is the first byte that the server sends to the client.
· Indicates the server’s window size. This is the size of the buffer allocated by the server to the process (located in the server’s RAM).
· Reply to the request options and set the server options.
3. When receiving the server’s SYN/ACK, the client:
· Sends an ACK message to the server to confirm the receipt of the SYN/ACK from the server.
· Indicates the client window size. Although this parameter is defined in the first message, the server still refers to this value because it is the latest window size.
In the option field of the TCP header, there are several main options:
· Maximum Segment Size (MSS): The maximum number of bytes in a TCP datagram, that is, the number of bytes from the TCP header to the end of the message.
· Windows Scale Option (WSopt): This factor is multiplied by the Window Size field in the TCP header to notify the receiver to expand the buffer. Since the maximum window size of the header is 64KB, multiplying it by a factor of 4 is a 256KB window size.
· SACK: Selective ACK, this option enables both parties of the connection to confirm only the specified message. When a single message is lost, only this message will be retransmitted. When the connection is established, both parties need to agree to SACK.
· Timestamps Option (TSopt): This parameter refers to the delay between the client and the server.
At this stage, both parties:
· Agree to establish a connection
· Know the other party’s initial sequence number
· Know the other party’s window size
When establishing a connection, except for the three-way handshake signal, all other signals indicate problems. This includes SYN without response, SYN/ACK after SYN but no ACK at the end, SYN response with RST, etc.
Summary
· If the SYN packet receives a reply RST, check for firewalls that block the port number.
· Three SYNs without any reply may be due to the application not responding or the firewall blocking requests on a specific port.
· Always remember to check if there is NAT, port forwarding, and mechanisms involving TCP and UDP ports. These mechanisms may interrupt the normal operation of TCP.