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. E.R -----Original Message----- From: Jan Engelhardt [mailto:jengelh@linux01.gwdg.de] Sent: Monday, December 11, 2006 2:38 PM To: Eyal Rundstein Cc: tproxy@lists.balabit.hu Subject: Re: [tproxy] connection go to CLOSE_WAIT after sending FIN

Hi, I am using kernel 2.4.32 with tproxy version 2.0.2. My client is a transparent proxy. 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.

- When I use an older kernel (2.4.18) with old tproxy (version 23) I don't see this problem.

Help is appreciated. Thanks in advance, E.R

-`J' --