> I understand and appreciate your efforts. But please consider the case > when one have to diagnose a failing connection and conntrack drops > packets. What should be suspected? Firewall rules? One can enable TRACE > and check which rules are hit - but because conntrack drops packet, > nothing is shown there. Enable and check conntrack events? Because the > packets are INVALID, checking the events does not help either. Only when > one runs tcpdump and compares it with the TRACE/NFLOG/LOG entries can one > spot that some packets "disappeared". > > Compare the whole thing with the case when packets are not dropped > silently but can be logged via checking the INVALID flag. One can directly > tell that conntrack could not handle the packets and can see all packet > parameters. Thanks for explaining such importance about why not drop silently. Now I can see :) In my first version, I didn't drop it directly but let it go without clearing skb->_nfct fields and then let the TCP layer handle it. As you said, the out-of-window case is just one of some INVALID cases which could also cause RST behaviour, so it seems that the first version doesn't handle it well either. It has to take all INVALID cases into account... Is there anything left I can do like particular tracepoints something like this? No idea. I only hope somebody who encounters such an issue can notice this behaviour effortlessly :) Thanks, Jason > > Best regards, > Jozsef
