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. > So probably nft-bridge and ebtables-compat is missing match/target > support and we get in sync with what we do in 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
