[tproxy] (no subject)

[KOVACS Krisztian]

   Hi,

Jon Nelson wrote:
> Problem #1: assume a process has gone through the steps of locally
> binding, calling setsockopt(ASSIGN) and setsockopt(LISTEN|ONCE) but has
> /not/ called 'listen' on the socket.
> 
> If the process ends abruptly, the iptable_tproxy module refuses to
> unhash the socket:
> 
> IP_TPROXY_UNASSIGN: not unhashing socket, 0100007f:2080, sr=c083c100,
> proto=6, sk->state=7, sr->flags=10003
> 
> The relevant code is near line 868, and I believe the test:
> 
> (sk->state != TCP_LISTEN)
> 
> is too specific.  In the above sock, the state was TCP_CLOSE.
> 
> Should TCP_CLOSE, TCP_CLOSE_WAIT, and/or TCP_CLOSING
> be added (I'm inclined to think that /just/ TCP_CLOSE)?

   Thanks for reporting, this is really an ugly bug. However, I don't 
really like adding TCP_CLOSE to the tests. The whole test has the purpose 
of differentiating between TCP listening sockets and sockets which are 
used by accepted connections. (You should not free the sockref in the 
second case.) Your proposed patch would not solve all these ugly problems, 
for example: if you ASSIGN a foreign address to the socket, set it 
ITP_LISTEN, and then instead of listen() you call connect(), and close() 
the socket. Although correct user-space software would not do this, it 
causes the tproxy hash to fill up... It looks like we need another way to 
differentiate between these type of sockets.

   The problem is already fixed in the just released development version 
of the patch, and will be fixed in the next stable version, also.

> Issue #2: assume a machine with 4 interfaces (if you include lo).
> Binding locally to any of the 3 non-lo addresses works just fine.
> However, why does (the initial local) binding to either 0 (INADDR_ANY)
> or 127.0.0.1 not work?

   It's because of the inner workings of Netfilter, although it certainly 
would be useful to have this working... For now, you should bind to non-lo 
addresses. (If this causes problems, try using a dummy net interface with 
a fake IP.)

-- 
   Regards,
     Krisztian KOVACS