Vitaly Zuevsky <vzuevsky@xxxxxxx> wrote:
> > diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
> > index 81d03acf68d4..ec4164c32d27 100644
> > --- a/net/netfilter/nf_conntrack_netlink.c
> > +++ b/net/netfilter/nf_conntrack_netlink.c
> > @@ -1195,8 +1195,6 @@ ctnetlink_dump_table(struct sk_buff *skb, struct netlink_callback *cb)
> > }
> > hlist_nulls_for_each_entry(h, n, &nf_conntrack_hash[cb->args[0]],
> > hnnode) {
> > - if (NF_CT_DIRECTION(h) != IP_CT_DIR_ORIGINAL)
> > - continue;
> > ct = nf_ct_tuplehash_to_ctrack(h);
> > if (nf_ct_is_expired(ct)) {
> > if (i < ARRAY_SIZE(nf_ct_evict) &&
> > @@ -1208,6 +1206,9 @@ ctnetlink_dump_table(struct sk_buff *skb, struct netlink_callback *cb)
> > if (!net_eq(net, nf_ct_net(ct)))
> > continue;
> >
> > + if (NF_CT_DIRECTION(h) != IP_CT_DIR_ORIGINAL)
> > + continue;
> > +
> > if (cb->args[1]) {
> > if (ct != last)
> > continue;
> > --
> > 2.32.0
> >
>
> Florian, thanks for prompt turnaround on this. Seeing
> conntrack -C
> 107530
> mandates the check what flows consume this many entries. I cannot do
> this if conntrack -L skips anything while kernel defaults to not
> exposing conntrack table via /proc. This server is not supposed to NAT
> anything by the way.
Then this patch doesn't change anything.
Maybe 'conntrack -L unconfirmed' or 'conntrack -L dying' show something?
