Balazs Scheidler wrote: > Hmm... this is a real problem, but I only see this occuring in our case > when we redirect a session, and responses must be de-NATed. In this case > however skb->sk is unique (except for maybe SYN-ACK, because socket is not > created until the three-way handshake is fully completed)
There will in no doubt be a couple of corner cases where one has to guess a little based on the TPROXY table. * Concurrent SYN-ACK from two different destinations to the same client IP,PORT. * As above, but locally generated TCP RST on initial SYN or ACK (port closed, rejected, or syn backlog overflow and set to reset on overflow) * RST from the client in response to SYN-ACK. for example in case spoofed SYN. Maybe this can be ignored but you must then expire not fully connected TPROXY sessions (not having a local socket). * ICMP "port unreachable" on closed UDP sockets. And I am not sure about skb->sk in case of TCP RST when the application kills a socket (socket closed with data in the receive queue, and no linger). Regards Henrik
