While testing/analyzing the changes in commit 4e95200ded923, I noticed comparison of rules containing among matches was not behaving right. In fact, most part of the among match data was ignored when comparing, due to the way among extension scales its payload. This problem exists since day 1 of the extension implementation for ebtables-nft. Patch 1 fixes this by placing a hash of the "invisible" data in well-known space. Patch 2 is a minor cleanup of commit 4e95200ded923, eliminating some ineffective function signature changes. Patch 3 adds set (with element) dumps to debug output. Note about 4e95200ded923 itself: I don't quite like the approach of conditionally converting a rule into libnftnl format using only compat expressions for extensions. I am aware my proposed compatibility mode does the same, but it's a global switch changing add_match() behaviour consistently. What the commit above does works only because for rule comparison, both rules are converted back into iptables_command_state objects. I'd like to follow an alternative path of delaying the rule conversion so that it does not happen in nft_cmd_new() but later from nft_action() (or so). This should eliminate some back-and-forth and also implicitly fix the case of needless set creation. Phil Sutter (3): extensions: libebt_among: Fix for false positive match comparison nft: Do not pass nft_rule_ctx to add_nft_among() nft: Include sets in debug output extensions/libebt_among.c | 1 + iptables/nft-bridge.h | 16 ++++++++ iptables/nft-cache.c | 10 ++++- iptables/nft-ruleparse-bridge.c | 2 + iptables/nft.c | 17 +++++--- .../testcases/ebtables/0009-among-lookup_0 | 39 +++++++++++++++++++ 6 files changed, 78 insertions(+), 7 deletions(-) create mode 100755 iptables/tests/shell/testcases/ebtables/0009-among-lookup_0 -- 2.40.0
