Yes, the exact port numbers are used in an attempt to maximize transparency. The SO_REUSEADDR only allows the bind to proceed, but the connect still fails due to the socket with the matching 4-tuple being in the time_wait state. Would tcp_tw_recycle/tcp_tw_reuse help in this case? Ron -----Original Message----- From: Balazs Scheidler [mailto:bazsi@balabit.hu] Sent: Thursday, April 15, 2010 4:13 AM To: Ron Parker Cc: tproxy@lists.balabit.hu Subject: Re: [tproxy] EADDRNOTAVAIL from connect, but only sometimes On Sun, 2010-01-10 at 19:46 -0500, Ron Parker wrote:
Hi,
We are using the tproxy patch for Linux 2.6.24 (Ubuntu 8.0.4). When placing outgoing connections, we use the original socket address (4-tuple) in the bind and set SO_REUSEADDR on the socket. The sequence we are having difficulty with is:
· Client connects to transparent proxy
· Transparent proxy connects to remote server
· Normal data transfer…
· Remote server closes the connection (but client connection is maintained)
· Transparent proxy attempts to connect again to remote server using the original 4-tuple (again)
o Bind succeeds
o Connect fails with EADDRNOTAVAIL
The original socket is probably in TIME_WAIT at this point. I thought the SO_REUSEADDR would take care of the problem. What am I missing here?
Well, SO_REUSEADDR behaviour is not changed, so if you get EADDRNOTAVAIL it either means that IP_TRANSPARENT is not enabled, or there's a conflicting socket still in the socket table. Are you using using exact port numbers when you bind? It might help to automatically allocate that. -- Bazsi