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!
