Re: ebtables: load-on-demand extensions

[Eugene Crosser <crosser@average.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1056 bytes --]

On 6/16/20 5:21 PM, Jan Engelhardt wrote:

>> 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.)
> 
> Why not make a patch to publicly expose the skb's data via nft_meta?
> No more custom modules, no more userspace modifications, that would seem 
> to be a win-win situation.

This looks unrealistic to me, at least at the first glance. For our
particular use case, we are running the skb through the kernel function
`skb_validate_network_len()` with custom mtu size, and make decision
based on the outcome. Who knows what other things other people may need
to do. At least the kernel module seems to be a must.

OTOH if it were possible to configure the module in an "agnostic" way,
without a custom "extension" shared object, that would be a win.

Regards,

Eugene


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]