Just an interim update on this. I have established that the problem arises with the following packet sequence: 1. Tproxy-Server -> Client FIN 2. Client->Tproxy-Server ACK (of the server's FIN) 3. Client->Tproxy-Server FIN 4. Tproxy-Server-Client ACK (of the client's FIN - this never leaves the server) Steps 3 & 4 are repeated. The problem does NOT arise with the sequence: 1. Tproxy-Server -> Client FIN 2. Client->Tproxy-Server ACK (of the server's FIN) / FIN 3. Tproxy-Server-Client ACK (of the client's FIN) The search continues... On 15/11/2011 15:20, "Simon James" <sjames@btisystems.com> wrote: Hi Thanks for the quick response! I've applied the patch but I'm still getting the problem. I'm progressing the diagnosis with printk() etc, and will update this post if and when I get any further. Thanks again. Simon On 15/11/2011 09:11, "KOVACS Krisztian" <hidden@balabit.hu> wrote: Hi, On Mon 14 Nov 2011 12:57:45 PM CET, Simon James wrote:
The problem seems to arise when the server initiates the close of the connection. In that case, the trace output shows:
1. the FIN from the server passing through the mangle:OUTPUT, filter:OUTPUT and filter:POSTROUTING tables 2. a FIN/ACK from the client arriving and passing through mangle:PREROUTING, mangle:INPUT and filter:INPUT tables 3. a final ACK from the server passing through the mangle:OUTPUT tables but getting no further.
This might be related to a problem we've fixed about a month ago in the upstream kernel: https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h... The fix made it into Linux 3.1. Can you somehow give it a try? (Backporting to your F14 kernel should be fairly trivial, since it's a one-line change in tcp_minisocks.c.) -- KOVACS Krisztian