Pablo Neira Ayuso wrote:
The point is that I don't understand why we have to apply these NFCT
patches which IMO do a sloppy netlink handling and then wait until this
is completely rewritten again properly... (continue below)
Well, those patches were done over time of about a year or so. The
initial NFCT code wasn't working for me when I initially tried it, so I
started to hack on that myself. Only the later patches turn it into the
well-working solution you should use.
Don't forget that this is a patchset with an RFC in mind. With that
series of patches you clearly see how NFCT evolved over time, with the
possibility to get the rational of all those patches.
Another option would be to just provide the newest code, without a
history at all. Is that what you like more?
That patch was provided exactly to solve that issue.
... because AFAICS if we check for ENOBUFS and then resync against the
kernel table using GET_CONNTRACK we won't need the sequence cache later,
will we?
You will on a busy site. The sole purpose of checking ENOBUFS or
NETLINK_OVERRUN is to check whether you need that logic during normal
operation. So, on a not-so-busy site you won't have those GET_CONNTRACK
requests at all.
Of course the GET_CONNTRACK requests should be disabled if there wasn't
any overrun for a certain period of time (e. g. one turnaround).
But still that's only an optimisation.
/holger
-
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
