Re: [PATCH nf v2] netfilter: synproxy: fix rst sequence number mismatch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



El 14 de julio de 2019 0:26:24 CEST, Florian Westphal <fw@xxxxxxxxx> escribió:
>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?

Sure, I will prepare a detailed description of the problem. Sorry about that and thanks!




[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux