Hello all, we need a custom "extention" module working on Layer 2 (nfproto "bridge" or "netdev"). Making a kernel module and an xtables "extention" shared object is simple enough. But then it gets more complicated. In order to make an "extention" work on Layer 3 (with command `iptables`) it is sufficient to place the shared object in the directory with other existing extensions (/usr/lib/x86_64-linux-gnu/xtables in a typical linux distro), and then existing `iptables` command will load it on demand if it was specified as a "match extension" option `-m` or used as a jump target. (Existing third party tools such as iptables-netflow use this approach). However such "load on demand" mechanism does not exist for Layer 2 (`ebtables` command). Instead, `ebtables` has a hardcoded list of extensions that are all loaded at startup time (iptables/xtables-eb.c, function `ebt_load_match_extensions()`). This makes the use of in-house extensions impossible without rolling out a modified version of `ebtables` command. Questions: 1. Is my analysis correct, and it is not possible to use existing netfilter control tools to configure and enable custom extensions on layer 2? 2. Is it correct that "new generation" `nft` filtering infrastructure does not support dynamically loadable extensions at all? (We need a custom kernel module because we need access to the fields in the skb that are not exposed to `nft`, and we need a custom extension to configure the custom module.) 3. If modification to `ebtables` is indeed inevitable, and we make such modification to allow on demand loading the same way as in `iptables`, would upstream be interested to incorporate such patch for some future relase? Thank you, Eugene
Attachment:
signature.asc
Description: OpenPGP digital signature
