In this section we will learn about different network problems that occur and try to analyze and solve them with lab exercises. Let's start with the Reset
(RST
) packet.
The TCP RST
flag resets the connection. It indicates that the receiver should delete the connection. The receiver deletes the connection based on the sequence number and header information. If a connection doesn't exist on the receiver RST
is set, and it can come at any time during the TCP connection lifecycle due to abnormal behavior. Let's take one example: a RST
packet is sent after receiving SYN/ACK
, as shown in the next image.
In this example we will see why RST
has been set after SYN-ACK
instead of ACK
:
Open the RST-01.pcap
file in the Wireshark:
As you can see in the preceding figure:
RST
packet should not be seen normallyRST
is set after the first two handshakes are complete. A possible explanation could be one of the following:This is the most common use case. Open the RST-02-ServerSocket-CLOSED.pcap
file in Wireshark. In this example the server was not started, the client attempted to make a connection, and the connection refused an RST
packet:
The steps to generate the RST
flag in a generic scenario, when the server is not in the listening state, are as follows:
tcp.port==8082
.Client0301.java
:bash$ ~ javac Client0301.java
bash$ ~ java Client0301
RST
packet in Wireshark.Often a connection is stuck in the CLOSE_WAIT
state. This scenario typically occurs when the receiver is waiting for a connection termination request from the peer.
To demonstrate the
CLOSE_WAIT
state, open the close_wait.pcap
file in Wireshark:
As you can see in the preceding screenshot:
tcp.flags.fin == 1
, and set tcp.seq == 2131384057
.ACK
packet tcp.ack == 2131384058
in packet#7 and didn't close its socket, which remains in the CLOSE_WAIT
state.
CLOSE_WAIT
means there is something wrong with the application code, and in the high-traffic environment if CLOSE_WAIT
keeps increasing, it can make your application process slow and can crash it.
The steps to reproduce CLOSE_WAIT
are as follows:
tcp.port==9999
.Server0302.java
and Client0302.java
using the javac
command:bash$ ~ javac Server0302.java Client0302.java
Server0302
using the java
command:bash$ ~ java TCPServer01
9999
:bash $ netstat -an | grep 999 tcp46 0 0 *.9999 *.* LISTEN
bash$ ~ java Client0302
CLOSE_WAIT
state:bash $ netstat -an | grep CLOSE_WAIT tcp4 0 0 127.0.0.1.56960 127.0.0.1.9999 CLOSE_WAIT
CLOSE_WAIT
, a restart is required for the process.FIN
packet from both the client and server is required to solve the CLOSE_WAIT
problem. Close the client socket and server socket when done with processing the record:socket.close(); à Initiates the FIN flow
Client0302.java
file and close the socket:Socket socket = new Socket(InetAddress.getByName("localhost"), 9999); … socket.close(); … Thread.sleep(Integer.MAX_VALUE);
CLOSE_WAIT
will not be visible.The main purpose of the
TIME_WAIT
state is to close a connection gracefully, when one of ends sits in LAST_ACK
or CLOSING
retransmitting FIN
and one or more of our ACK
are lost.
RFC 1122: "When a connection is closed actively, it MUST linger in TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime). However, it MAY accept a new SYN from the remote TCP to reopen the connection directly from TIME-WAIT state, if..."
We ignore the conditions because we are in the TIME_WAIT
state anyway.
18.191.189.23