Re: synack packet invalid when client reconnecting with same src port because out of window?

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

 



Jozsef Kadlecsik wrote on Thu, Jan 31, 2019:
> > tcpdump loops on:
> > 05:30:41.411346 IP x.y.z.34.49149 > x.y.z.1.24007: Flags [S], seq 837922022, win 26880, options [mss 8960,sackOK,TS val 1689048672 ecr 0,nop,wscale 7], length 0
> > 05:30:41.411481 IP x.y.z.1.24007 > x.y.z.34.49149: Flags [S.], seq 1749683989, ack 837922023, win 26844, options [mss 8960,sackOK,TS val 560823762 ecr 1689017605,nop,wscale 7], length 0
> > 05:30:57.595860 IP x.y.z.1.24007 > x.y.z.34.49149: Flags [S.], seq 1749683989, ack 837922023, win 26844, options [mss 8960,sackOK,TS val 560839947 ecr 1689017605,nop,wscale 7], length 0
>
> [...]
>
> For some reason nf_conntrack_log_invalid does not output anything to
> > dmesg, but adding log rules before and after the default firewalld's
> > INPUT --ctstate INVALID -j DROP rule shows that the synack packets fall
> > there (and should have been picked up by the RELATED rule earlier and
> > weren't)
> 
> We need the SYN/ACK packet as well. Without the packet data there's no way 
> to tell why conntrack classified it as INVALID. Packet logging is not 
> enough, please capture the whole (broken) traffic between the server and 
> the client.

I'm not sure I follow; I didn't give the packet logging here but I did
give the tcpdump textual representation above (left in the quote, it
does list sequence/window/ack) -- that's all the broken traffic I have
right now, I don't have the leading sequence.

iirc last time I was able to give you a pcap file, but I unfortunately
cannot do this as work imposes a restriction on exporting data and I
cannot give e.g. the IPs out.
If you have particular fields you'd like to see from a trace I can
export them though (tshark in superverbose mode just masking IPs would
do?)



I've been trying to reproduce ever since sending my mail and I'm super
annoyed because I managed to reproduce once but tcpdump wasn't running
(I decided to use more clients to test and forgot to run tcpdump on all
the clients); but since I could reproduce once I'll eventually get it
again...

Thanks,
-- 
Dominique



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux