Fernando Fernandez Mancera <ffmancera@xxxxxxxxxx> wrote: > 14:51:00.024418 IP 192.168.122.1.41462 > netfilter.90: Flags [S], seq > 4023580551, win 64240, options [mss 1460,sackOK,TS val 2149563785 ecr > 0,nop,wscale 7], length 0 Could you please trim this down to the relevant parts and add a more human-readable description as to where the problem is, under which circumstances this happens and why the !SEEN_REPLY_BIT test is bogus? Keep in mind that you know more about synproxy than I do, so its harder for me to follow what you're doing when the commit message consists of tcpdump output. > 14:51:00.024454 IP netfilter.90 > 192.168.122.1.41462: Flags [S.], seq > 727560212, ack 4023580552, win 0, options [mss 1460,sackOK,TS val 355031 ecr > 2149563785,nop,wscale 7], length 0 > 14:51:00.024524 IP 192.168.122.1.41462 > netfilter.90: Flags [.], ack 1, win > 502, options [nop,nop,TS val 2149563785 ecr 355031], length 0 > 14:51:00.024550 IP netfilter.90 > 192.168.122.1.41462: Flags [R.], seq > 3567407084, ack 1, win 0, length 0 ... its not obvious to me why a reset is generated here in first place, and why changing code in TCP_CLOSE case helps? (I could guess the hook was called in postrouting and close transition came from rst that was sent, but that still doesn't explain why it was sent to begin with). I assume the hostname "netfilter" is the synproxy machine, and 192.168.122.1 is a client we're proxying for, right?
