On Fri, 9 Oct 2020, Florian Westphal wrote: > Matches/targets that need conntrack increment a refcount. So, when all > rules are flushed, refcount goes down to 0 and conntrack is disabled > because the hooks get removed.. > > Just doing iptables-restore doesn't unregister as long as both the old > and new rulesets need conntrack. > > The "delay unregister" remark was wrt. the "all rules were deleted" > case, i.e. add a "grace period" rather than acting right away when > conntrack use count did hit 0. Now I understand it, thanks really. The hooks are removed, so conntrack cannot "see" the packets and the entries become stale. What is the rationale behind "remove the conntrack hooks when there are no rule left referring to conntrack"? Performance optimization? But then the content of the whole conntrack table could be deleted too... ;-) > Conntrack entries are not removed, only the base hooks get unregistered. > This is a problem for tcp window tracking. > > When re-register occurs, kernel is supposed to switch the existing > entries to "loose" mode so window tracking won't flag packets as > invalid, but apparently this isn't enough to handle keepalive case. "loose" (nf_ct_tcp_loose) mode doesn't disable window tracking, it enables/disables picking up already established connections. nf_ct_tcp_be_liberal would disable TCP window checking (but not tracking) for non RST packets. But both seems to be modified only via the proc entries. Best regards, Jozsef - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxx PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics H-1525 Budapest 114, POB. 49, Hungary
