Hello Balazs, Thanks for the quick reply. On Jan 24, 2008 1:29 AM, Balazs Scheidler <bazsi@balabit.hu> wrote:
On Wed, 2008-01-23 at 16:40 -0800, Pranav Desai wrote:
Hello All,
I am testing with the example code foreign-tcp-connect on kernel-2.6.20.15/cttproxy-2.0.6 When I run the sample in quick successions, I get this message in /var/log/messages and program returns with errno 17 (File exists).
IP_TPROXY: socket already assigned, reuse=0, e101a8c0:0f27, sr->faddr=c000010a:d007, flags=210000, sr->tv_hashed=1201103313:191693969
Is it ok to add a check to ignore this ?
This means that the local IP:port pair is already present in the tproxy hash table. This is actually not very good, the assignment should be deleted as soon as the socket is closed.
However tracking down these cases proved to be the very problem why we wanted to avoid the current NAT based implementation in the first place. Using this tproxy hash is inherently racy and although we've managed to get it reasonably stable, we encountered similar cases every now and then. And it's very difficult to track down why it happens.
Is it possible to not use the cache ?. If so what kind of performance hit would that be.
The information in the log message is follows: * SO_REUSEADDR was not set for the socket (I can't remember if it's the old or the new socket) * the local address is 192.168.1.225, port number 9999 or 3879 (can't remember the byte order, it's probably 9999)
it is 9999.
* the requested foreign address is 10.1.0.192, port number 2000 or 533255 * flags is a bitmask of IPT* values, defined at the beginning of the iptable_tproxy file * the sr->tv_hashed value is the exact time of the previous registration
The problem happens probably because the application requests the same local ip:port, and the previous entry was not yet cleaned up, probably because the kernel side of the socket still exists.
Use automatically assigned port numbers and not fixed ones and then it should work.
We are using tproxy in our proxy server application and we already use automatically assigned ports, but its possible that the socket still exists, since this seems to happen when there are a few requests coming in almost simultaneously. Ours is an event based system using epoll. The other thing I noticed was that the connect() return EINPROGRESS the first time (its non-blocking), which seems normal, and fails with EADDRNOTAVAIL the subsequent times for the same src and dest IP pair. Would the new version of tproxy be any better ? Thanks for your help. -- Pranav
-- Bazsi
-- ------------------------------ http://pd.dnsalias.org