[tproxy] tproxy 1.2.0 missing ip_tproxy_sockref_uniq?

[KOVACS Krisztian]

  Hi,

On Fri, 2004-01-09 at 18:08, Jon Nelson wrote:
> > >
> > > /* check if the proxy requested a wildcard port, and allocate
> > >  * a free port if necessary */
> > > if (itp.itp_faddr.s_addr && (itp.itp_fport == 0)) {
> > > 	itp.itp_fport = htons(ip_tproxy_sockref_uniq(itp.itp_faddr, proto));
> > > 	if (itp.itp_fport == 0) {
> > > 		/* port allocation failed */
> > > 		res = -EAGAIN;
> > > 		goto read_unlk;
> > > 	}
> > > }
> > >
> >
> >   Yes, it did. In the 1.2 branch, if a wildcard foreign port is
> > specified at ASSIGN, Netfilter's NAT subsystem allocates a foreign port.
> > This is very useful for connect()-ing from a wildcard foreign port,
> > since it avoids "failed to apply NAT mapping" errors in a lot of cases.
> > However, this allocation happens only when the first packet of the
> > connection is traversing the Netfilter hook, so you cannot get the exact
> > port number _before_ sending the first packet. In case of listening
> 
> I don't think that's true.  I hand-applied a patch to add back
> ip_tproxy_sockref_uniq (and the code that calls it, shown above) and it
> works perfectly.  After the ASSIGN I just use QUERY to get the IP
> and port which I can then use for my own devices.
> It works perfectly, and as expected.  Tested with both listening and
> connect()'ing sockets.

  Of course it works, but with these changes you lose the advantages of
the ability to let the NAT subsystem choose the protocol-dependent part
(TCP/UDP port, in our case). The problem with the uniq() approach was
that you cannot be sure that the allocated port won't clash with an
already existing connection when the first packet traverses the
Netfilter hook, and tproxy tries to apply the pre-allocated, fully
specified NAT mapping.

  The 1.2.0 approach makes transparent "wildcard" connects() perform
better and more reliably, but unfortunately this broke "wildcard"
listening support (which in some cases can be easily worked around in
userspace). This is why IP_TPROXY_ALLOC will be introduced in the next
major tproxy version.

  BTW could you publish your patch, just in case somebody else needs it,
too?

-- 
 Regards,
   Krisztian KOVACS