Layer-2 filtering in NPF: breaking config parsing

[Greg Troxel <gdt%lexort.com@localhost>]

netbsd-current built yesterday, updated from release sets.
amd64, xen domU (on a n10 dom0).

system was working fine before the npf changes (well, occasional zfs
lockups, but we know why and that's not related..)

  #> npfctl validate
  table <blocklist> type lpm

  procedure "log"

  /etc/npf.conf:171:0: npfctl_print_filter: layer not supported near ''

171 is the closing brace of a big "group default" (maybe 30 rules).

I have a line

  map $ext_if dynamic $vpn_prefix -> ifaddrs($ext_if)

with earlier (different prefix)

  $ext_if = "xennet0"
  $ext_ifaddrs = ifaddrs($ext_if)

  $vpn_if = "tun0"
  $vpn_prefix = 10.1.2.0/24

and later

  group "external" on $ext_if {
    pass stateful out final proto tcp from $vpn_prefix
    pass stateful out final proto udp from $vpn_prefix
    pass stateful out final proto icmp from $vpn_prefix
  }


and while this machine doesn't have a tun0, that was ok.


If I coment out the map line (only the map line) "npfctl validate"
returns my config ok.


One can argue about whether map on an inerface that doesn't exist should
be an error or not, but that would be

  /etc/npf.conf:37:0: map statement with interface that does not exist

and not be confusing.  There's a longer discussion about general configs
that can be shared vs having to write a config generator and I'm
avoiding that.  The point, besides confused error messages, is that this
should not change with the introduction of a feature; it should only
change if we decide to change it.