tags:

views:

67

answers:

3

From the ethreal packet capture, I see the following behaviour which appears quite 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?

Also, the Server Port is 6000. Could that cause any problem?

My other doubts:

  1. Why is there a FIN, ACK? Shouldn't it be only FIN? What is the meaning of the ACK in that message?
  2. Shouldn't there be a FIN from Client also?

EDIT: After some more analysis, I found if the number of file descriptors have exceeded the limit then a FIN is sent by the Server. But, in this case it doesn't appear that the file descriptors have exceeded the limit. For what other scenarios can this happen?

A: 

Seems like the server calls shutdown very shortly after accepting the connection.

valdo
+2  A: 

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

Habbie
Do you mean to say that the call to 'accept' would have surely returned successfully in this case?
Jay
Yes. Without accept() you would just see silence and eventually timeouts.
Habbie
Ok, but, there is no way an accept will send a FIN right? I mean in case of some error conditions, is it possible?
Jay
Not that I'm aware of, certainly.
Habbie
Hmm? No, the connection is set up before `accept()` is called - the backlog parameter to `listen()` specifies how many connections can be in this state (connected, but `accept()` not yet called).
caf
@caf you're right, i forgot about the backlog.
Habbie
+1  A: 

I'm guessing the connection is being accepted by inetd or a similar daemon, which then attempts to fork and exec another program to handle the connection, and that either the fork is failing (due to resource exhaustion) or the exec is failing (due to nonexistent file, permissions error, etc.).

R..
wouldn't that give RST right away?
Habbie
Hmm, I think you're right..
R..