On Thu, Dec 15, 2016 at 3:55 PM, Pablo Neira Ayuso <[email protected]> wrote: > > On Wed, Dec 14, 2016 at 04:35:57PM -0500, [email protected] wrote: > > From: Joe Conley <[email protected]> > > > > Two missing ifdef checks for CONFIG_NF_CONNTRACK_MARK were causing > > EOPNOTSUPP to be returned. Every single place that cda[CTA_MARK] or > > cda[CTA_MARK_MASK] > > was checked was inside a #ifdef for CONFIG_NF_CONNTRACK_MARK except for > > these > > two places. The reason for this change stems from this commit: > > 866476f323465a8afef10b14b48d5136bf5c51fe (netfilter: conntrack: Flush > > connections with a given mark) > > > > This allows conntrack -L to be ran succesfully when CONFIG_NF_CONNTRACK_MARK > > is not enabled. > > I would like to understand how you're triggering this problem. If it > is a plain 'conntrack -L' command line invocation that triggers the > problem, then it's probably a userspace problem since we should not > send any mark attribute to the kernel if not set.
Building the kernel with CONFIG_NF_CONNTRACK_MARK disabled will cause conntrack -L to return EOPNOTSUPP because of the missing ifdef checks. Building the kernel with it enabled allows conntrack -L to run successfully. At first, I thought this was a userspace bug as well but it is not. Every single place CTA_MARK or CTA_MARK_MASK is used is inside an ifdef check for CONFIG_NF_CONNTRACK_MARK except for these two places. There is no clear reason as to why. There is no reason that conntrack -L should return EOPNOTSUPP when CONFIG_NF_CONNTRACK_MARK is disabled. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
