On Sat, Mar 31, 2018 at 09:04:55PM +0200, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> 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? > > It already works via nft_compat. > > Only issue is that nft list ruleset won't display this correctly > because ebt lacks xlate() functions. > > However, I thought ebtables might be a low-hanging fruit to > ditch nft_compat and make it work with nftables directly. That's also fine yes. We can do different for this case. -- 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
