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:
signature.asc
Description: OpenPGP digital signature
