Hi Jeremy, On Tue, Mar 19, 2024 at 06:27:11PM +0000, Jeremy Sowden wrote: > On 2024-03-19, at 16:00:28 +0100, Daniel Gröber wrote: > > The nftables config below triggers a BUG. > > > > $ nft -f /etc/nftables.conf > > BUG: invalid mapping expression variable > > nft: evaluate.c:1797: expr_evaluate_map: Assertion `0' failed. > > Aborted > > > > Refactoring to using $srvaddr_map instead of having the anonymous map > > inline made the bug trigger. > > That assertion has since been replaced upstream by a normal > error-message: > > /space/azazel/tmp/ruleset.1067161.nft:6:58-69: Error: invalid mapping > expression variable > ip6 nexthdr tcp redirect to ip6 daddr & $iid_mask6 map > $srvaddr_map > ~~~~~~~~~~~~~~~~~~~~~~ > ^^^^^^^^^^^^
Fair enough then. I do find this a bit of an arbitrary limitation however. > Because of the way parsing works in nftables, one can't use a symbolic > variable in that context. This, however, will work: Yup, that's what I'm doing now. I just keep running into these little irritating limitations with nftables and wanted to at least document this one somewhere. Do you think it's worth forwarding this report upstream anyway? I would like to sand off sharp nftables edges such as this. In case you're curios what I was working on: a generic way to have isolated v6 service addressess for software that doesn't support SO_BINDTODEV (*cough* syncthing *cough*) without hardcoding any prefixes https://paste.debian.net/hidden/66c2ef6e/ --Daniel
signature.asc
Description: PGP signature
