EXACTLY! The client SHOULD go to FIN_WAIT_2 but what I see is that it goes to CLOSE_WAIT That's the bug! -----Original Message----- From: Jan Engelhardt [mailto:jengelh@linux01.gwdg.de] Sent: Monday, December 11, 2006 4:09 PM To: Eyal Rundstein Cc: tproxy@lists.balabit.hu Subject: RE: [tproxy] connection go to CLOSE_WAIT after sending FIN

...

...

My client opens a transparent connection to the server, sends a message and then closes the connection with FIN. The server replies with an ACK, WITHOUT sending a FIN. Now I see that the connection stays in the ip_conntrack table in CLOSE_WAIT state. During that time I can not reuse the connection. (SYNs to the same dest are not sent).

This is correct, as per RFC 793 page 21 and page 39.

...

1) Isn't the correct behavior for that connection is to go to FIN_WAIT_2 state? Is it a bug? 2) The CLOSE_WAIT timeout is 500 seconds. Is there a way I can still open a new connection to the same destination?

setsockopt SO_REUSEADDR may help.

As far as I understand, the RFC 793 states that the correct behavior is

to go to state FIN_WAIT_2. We go to CLOSE_WAIT only if we receive FIN and send ACK. Page 21: CLOSE-WAIT - represents waiting for a connection termination request from the LOCAL user. FIN-WAIT-2 - represents waiting for a connection termination request from the REMOTE TCP.

If the client sends a FIN (optionally with ACK), the server responds with ACK and goes into CLOSE-WAIT. The client goes to FIN-WAIT-2. The server may continue to send data. -`J' --