9-TCP protocol (connection abnormality)

兰博

9-TCP protocol (connection abnormality) [Copy link]

There are many situations that lead to the inability to establish a connection.

In this article, we analyze 2 situations, discussing them for Windows and Linux respectively, and they are different.

• The first case is that the connected host is not in the network
• The second case is that the host is in the network, but the corresponding service is not enabled

Different versions of the Linux kernel are also different. Here I use the Ubuntu 14.04 LTS version.

1. Correspondence between related network addresses

There are a lot of IP addresses involved here, which may confuse you. Let me explain:

• My host machine has two IP addresses, one is the address of the local network card: 192.168.166.107, the other is the virtual network card 192.168.80.2
• The Linux in the virtual machine also uses a virtual network card, the IP address is 192.168.80.130

About the correction of Section 2: There is a problem in the previous experiment. Although the target host was not pinged, it returned RST. However, the environment at that time no longer exists. Here my host has been changed to 10.154.0.45.

2. The host is not in the network

In the experiment, the address of the Linux host is 10.154.0.45, and we connect to a non-existent host 10.154.1.45.

2.1 Test on Linux

Use the tcpdump command on Linux to capture packets. The path of the cli program is unp/protocol/tools/tcpclient/cli.c.

• First start tcpdump

$ sudo tcpdump port 5000

• 1

• Open another terminal to connect to a non-existent host. Note that this IP address should not be in the same network segment as your Linux. My Linux host IP is 10.154.0.45, which is network segment 0, and the one to be connected to is network segment 1.

$ ./cli 10.154.1.45 5000

• 1

The host with the IP address 10.154.1.45 does not exist, but the client does not know whether this host is on the network.

Figure 1 Client timeout Figure 2 tcpdump Packet capture

We can analyze the following results:

• After the client sent a SYN request, it retransmitted SYN 6 times because no ack was returned due to timeout; finally, the connect timed out.
• Each timeout is twice the previous timeout (exponential backoff algorithm)

2.2 Test on Window 7

First, open OmniPeek on Windows 7, and select the network card you use to access the Internet, not the virtual machine network card.

Next, use tcp_client to connect to the 192.168.165.2 host. My Window 7 IP address is 192.168.166.107. Similarly, do not let the target IP address and the connected host be in the same network segment.

• Open OmniPeek and start capturing packets
• Open cmd and connect to the target host

F:\tools> tcp_client 192.168.165.2 5000

• 1

Three experiments were conducted on Win7, and the results are shown in Figure 3.

Figure 3 Three tests on Windows

As can be seen from Figure 3, after Windows sends the SYN packet for the first time, After the SYN segment, it did not receive an ACK from the other end and retransmitted twice. That is, it sent 3 SYN segments in total. If the SYN segment sent for the third time did not receive an ACK, the connect function would return an error directly after the timeout.

In addition, we found that the first timeout was about 3 seconds and the second time was about 6 seconds.

3. The host is in the network, but the service is not started3.1 Test on Linux

Only one test was performed here. Figure 4 Connecting to Windows Host After sending the tcp segment to the target host, the other end directly threw a RST segment over^_^, and then the connect function directly returned an error. . . .

3.2 Test on Windows

Use tcp_client on Windows to connect to Linux. Figure 5 Test on Windows

It can be seen that Windows is quite thick-skinned. The other party threw a RST 4. Summary

• Know how TCP handles abnormal connection establishment
• Know that there are differences between Windows and Linux

zxopenljx

Thanks for sharing