[tproxy] tproxy 1.2.0 missing ip_tproxy_sockref_uniq?

[Jon Nelson]

I was wondering something.

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?

--
What do you call a fish with no eyes? A fsh.

Jon Nelson <jnelson-tproxy@securepipe.com>