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>