[tproxy] tproxy 1.2.0 missing ip_tproxy_sockref_uniq?

[KOVACS Krisztian]

  Hi,

On Thu, 2004-01-08 at 21:55, Jon Nelson wrote:
> Let's say somebody wants to perform a non-local LISTEN.
> Since the port isn't known ahead of time, both the local bind(2)
> operation *and* the ASSIGN use a port of 0 (pick one for me).
> Of course the 'local' socket (getsockaddr) gets a port, thanks to the
> kernel.  However, getsockopt (QUERY) returns ports of 0 for both local
> *and* foreign.  How does one determine what the 'remote' port is?
> With 2.4.21-23, there was (seeming) explicit support for this scenario
> involving the function ip_tproxy_sockref_uniq (from the setsockopt
> handler):
> 
> /* 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;
> 	}
> }
> 
> Did support for automatically assigning a foreign port go away between
> 2.4.21-23 and 1.2.0?

  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
sockets, this makes no sense, of course, so as of 1.2.0 you cannot use
'wildcard' foreign ports for listening sockets. As a workaround, you
should implement roughly the same in userspace, that is, you try to
explicitly assign your sockets in a range of ports until the allocation
succeeds.

  The next version of tproxy will address exactly these problems, it
will have an ALLOC operation as well. This can be used to instantly
allocate a foreign port if none was given, ip_tproxy_sockref_uniq() will
be back. (ALLOC support is ready at the moment, however, some
work/testing is still needed before the first development release will
be published.)

-- 
 Regards,
   Krisztian KOVACS