On Sat, Mar 31, 2018 at 08:57:21PM +0200, Pablo Neira Ayuso wrote: > Cc'ing Arturo, he added the ebtables-compat layer so he probably > remember more details on this. > > On Sat, Mar 31, 2018 at 07:17:41PM +0200, Florian Westphal wrote: > > This (haycky) patch translates 'ebtables --mark' to a native 'meta mark' > > and dissects meta mark back to the ebt_mark_m binary representation when > > parsing back nftables rules. > > > > Plan is to do this for all the ebt matches/watchers/targets so that > > 1. 'nft list ruleset' shows correct/expected output > > 2. we can (eventually) remove ebtables support from kernel > > 3. make iptables install 'ebtables' by default as drop-in replacement. > > > > ebtables is much more feature limited than iptables, > > nft should already provide all/complete feature set. > > > > Downside: Because we can't (should not) add nftables specific code > > to libebt_XXX.c, this 'leaks' ebt_mark_m_info struct definition to > > nft-bridge.c. I think its okay, we could also eventually remove all > > the libebt_XXX files and provide everything from nft-bridge.c as builtin > > functionality. > > > > Does that appear sane to you? > > So far the compat infrastructure uses nft_compat.c, which uses xtables > matches/targets from the kernel. > > I mean, probably get this working through nft_compat instead? > > We could do similar in many other spots in the iptables-compat, > although not sure it's worth the effort. > > So probably nft-bridge and ebtables-compat is missing match/target > support and we get in sync with what we do in iptables-compat? I mean, this patch is an alternative to be more native, I'm not against it, actually this is work done already so I don't want you to drop it necessarily, my intention was just to point that we have followed a different path with iptables-compat. -- 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
