Hi Florian, On 7/14/19 1:25 AM, Fernando Fernandez Mancera wrote: > El 14 de julio de 2019 0:26:24 CEST, Florian Westphal <f...@strlen.de> > escribió: >> Fernando Fernandez Mancera <ffmanc...@riseup.net> 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? > > Sure, I will prepare a detailed description of the problem. Sorry about that > and thanks! >
When there is no service listening in the specified port in the backend, we get a reset packet from the backend that is sent to the client but the sequence number mismatches the tcp stream one so there is a loop in which the client is requesting it until the timeout. To solve this we need to adjust the sequence number, we cannot use the !SEEN_REPLY_BIT test because it is always false at this point and then we never get into the if statement. Instead of check the !SEEN_REPLY_BIT we need to check if the CT IP address is different to the original CT IP. I hope that answers your questions, here is the tcpdump output with only the important information. Please note that "netfilter" is the synproxy machine and 192.168.122.1 is the client. If that is fine to you, I will include this description into the commit message and send a v3 patch. Thanks Florian! :-) TCPDUMP output: 14:51:00.024418 IP 192.168.122.1.41462 > netfilter.90: Flags [S], seq 4023580551, 14:51:00.024454 IP netfilter.90 > 192.168.122.1.41462: Flags [S.], seq 727560212, ack 4023580552, 14:51:00.024524 IP 192.168.122.1.41462 > netfilter.90: Flags [.], ack 1, 14:51:00.024550 IP netfilter.90 > 192.168.122.1.41462: Flags [R.], seq 3567407084, 14:51:00.231196 IP 192.168.122.1.41462 > netfilter.90: Flags [.], ack 1, 14:51:00.647911 IP 192.168.122.1.41462 > netfilter.90: Flags [.], ack 1, 14:51:01.474395 IP 192.168.122.1.41462 > netfilter.90: Flags [.], ack 1,
