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