Hi Krisztian!
Sorry :o(. I'm currently recompiling the kernel with a larger log buffer and will rerun the tests and post an updated tarball.
I'm afraid it won't help much, but let's see.
OK, http://www.minter.demon.co.uk/tproxy-bug-2.tar.bz2 [3.1M] is available; the system log files are considerably longer this time, but it's possible that you'll find that they're still not complete :o/
Could you try what happens if you omit the ITP_ONCE flag from the FLAGS setsockopt(), and set only ITP_CONNECT?
OK, in this case we don't get any un-NATted packets at the remote host, but sooner or later one of the processes gets stuck in a connect() call and never returns: presumably every time it attempts to issue a SYN packet, this packet gets lost somewhere? Maybe with proper logging it will be clearer what's going on here.
OK, thanks. So, in the meantime I reproduced the problem (and tested without ITP_ONCE as well). Seems interesting, since I get a lot of "failed to apply NAT mapping" errors...
The above tarball also has a log of a run without the ITP_ONCE flag. It's encouraging that you've been able to reproduce the problem at your end -- was it on an SMP box? By "failed to apply NAT mapping" error, I assume you mean the "IP_TPROXY: error applying NAT mapping" error? Just to confirm, I'm not getting any of these error messages at all (perhaps because I've configured NAT reservations off?) Cheers, Jim