[tproxy] TPROXY_ASSIGN fails with File exists

Balazs Scheidler bazsi at balabit.hu
Thu Jan 24 10:29:57 CET 2008


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.

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)
 * 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.

-- 
Bazsi



More information about the tproxy mailing list