[tproxy] TPROXY_ASSIGN fails with File exists

[Pranav Desai]

Hello Balazs,

Thanks for the quick reply.

On Jan 24, 2008 1:29 AM, Balazs Scheidler <bazsi at 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