recipes-kernel/linux/generic/gyroidos.cfg: build NAT/nft-compat targets into the Kernel#317
Open
aevykk wants to merge 1 commit into
Open
recipes-kernel/linux/generic/gyroidos.cfg: build NAT/nft-compat targets into the Kernel#317aevykk wants to merge 1 commit into
aevykk wants to merge 1 commit into
Conversation
…ts into the Kernel The image runs iptables-nft. When cmld sets up container NAT it shells out to `iptables -t nat` (DNAT/SNAT for port forwarding, MASQUERADE for outbound). The DNAT/SNAT/MASQUERADE targets and the nat chain type were loadable modules (nf_nat, nft_compat, xt_nat, nft_chain_nat) with nothing preloading them, so the first NAT rule after boot relied on the kernel's on-demand module autoloader. That autoload occasionally races: iptables' revision probe runs before the target module finishes registering, and the rule insert fails with "Extension DNAT revision 0 not supported" / RULE_INSERT ENOENT. Being a race it only fails sometimes; once the module is loaded the retry would succeed. NAT is fundamental to container networking, so force the stack builtin to remove the race window entirely rather than depend on first-use autoload. Follows the existing gyroidos.cfg pattern that already forces IP_NF_NAT and friends to =y; this just extends it to the nft-backend targets iptables-nft actually uses. NETFILTER_XT_MATCH_ADDRTYPE (the `-m addrtype` match) is already builtin here. Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Leander Seidlitz <leander.seidlitz@aisec.fraunhofer.de>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The image runs iptables-nft. When cmld sets up container NAT it shells out to
iptables -t nat(DNAT/SNAT for port forwarding, MASQUERADE for outbound). The DNAT/SNAT/MASQUERADE targets and the nat chain type were loadable modules (nf_nat, nft_compat, xt_nat, nft_chain_nat) with nothing preloading them, so the first NAT rule after boot relied on the kernel's on-demand module autoloader.That autoload occasionally races: iptables' revision probe runs before the target module finishes registering, and the rule insert fails with "Extension DNAT revision 0 not supported" / RULE_INSERT ENOENT. Being a race it only fails sometimes; once the module is loaded the retry would succeed. NAT is fundamental to container networking, so force the stack builtin to remove the race window entirely rather than depend on first-use autoload.
Follows the existing gyroidos.cfg pattern that already forces IP_NF_NAT and friends to =y; this just extends it to the nft-backend targets iptables-nft actually uses. NETFILTER_XT_MATCH_ADDRTYPE (the
-m addrtypematch) is already builtin here.