On 2024-03-20, at 14:44:21 +0100, Daniel Gröber wrote: > 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.
Agreed. > > 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. Also agreed. Leave it with me. I'll send a patch or open a report in the upstream Bugzilla. > 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/ J.
signature.asc
Description: PGP signature
