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