Geek Answers Handbook

Why does the TCP server send FIN right after receiving the connection?

From capturing the ethreal package, I see the following behavior, which seems pretty strange to me:

Client --> Server [SYN] Server --> Client [SYN, ACK] Client --> Server [ACK] Server --> Client [FIN, ACK] Client --> Server [ACK] Client --> Server [TCP Segment of a reassembled PDU] (I don't know what this means) Server --> Client [RST]

Any ideas as to why this could be happening?

In addition, the server port has 6000. Could this cause any problems?

My other doubts:

  • Why is there FIN, ACK? Isn't that just FIN? What is the meaning of ACK in this post?
  • Should there be no FIN from the Client?

EDIT: After some analysis, I found that the number of file descriptors exceeded the limit, then FIN is sent by the server. But in this case it is not visible that the file descriptors have exceeded the limit. For what other scenarios could this happen?

+4
source share
5 answers

FIN usually means the other side, called shutdown(..) on the socket.

+2
source

An in-depth analysis found that the cause is the problem:

When a client tries to connect to TCP, even if the server does not currently receive a connection, the connection will fail. This will happen if the server called the listen function and it will continue to accept connections until the lag limit is reached.

But if the application process exceeds the limit of the maximum file descriptors that it can use, then when server calls are received, then he realizes that there are no file descriptors available for the socket and that the call and the TCP connection sending FIN to the other side cannot be accepted.

I just post this output here. I still leave the accepted answer, as with Hubby.

Thanks to everyone who answered this question.

+8
source

I assume that the connection is accepted by inetd or a similar daemon, which then tries to execute fork and exec another program to process the connection and that either fork does not work (due to resource exhaustion) or exec fails (due to a nonexistent file, permission error etc.).

+1
source

Could be TCP wrappers . If the server process was created with libwrap support, it will accept the connection, check /etc/hosts.allow and /etc/hosts.deny , and then immediately close the connection if it is rejected by the policy.

It is easy to see if the server uses libwrap:

 > ldd /usr/sbin/sshd | grep libwrap libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f1562d44000)
+1
source

It seems that the server is causing shutdown very soon after accepting the connection.

0
source

More articles:


All Articles