Re: user/3658: pfctl -t <table> -T test 192.168.0.0/24 can't decode

[Daniel Hartmeier <daniel_(_at_)_benzedrine_(_dot_)_cx>]

The following reply was made to PR user/3658; it has been noted by GNATS.

From: Daniel Hartmeier <daniel_(_at_)_benzedrine_(_dot_)_cx>
To: okan_(_at_)_demirmen_(_dot_)_com
Cc: gnats_(_at_)_openbsd_(_dot_)_org
Subject: Re: user/3658: pfctl -t <table> -T test 192.168.0.0/24 can't decode
Date: Thu, 29 Jan 2004 08:54:55 +0100

 On Wed, Jan 28, 2004 at 08:43:27PM -0500, okan_(_at_)_demirmen_(_dot_)_com wrote:
 
 > >Number:         3658
 > >Synopsis:       pfctl -t <table> -T test 192.168.0.0/24 can't decode
 
 > 	pfctl(8) doesn't seem to parse CIDR formated address except /32
 > 	when testing for address/networks in pf tables
 
 > >Fix:
 > 	none yet - unless feature is supposed to be there.
 
 It is like that on purpose. At least, until you can explain what -T
 should do when the parameter is a netblock and not just a single
 address.
 
 With a single address, what pfctl -T does is show what most-specific
 entry in the table the address matches, if any. It shows the result of
 the lookup in the radix tree.
 
 For instance, with a table containing
 
   10.0.0.0/8
   !10.1.0.0/16
   10.1.2.0/24
 
 pfctl -vvTt 10.1.2.3 shows
 
   M  10.1.2.3      10.1.2.0/24
 
 Note how it returns 'the most specific match' (at most one entry) and
 not just 'whether the table contains the exact argument' (there's no
 entry 10.1.2.3 in the table).
 
 That's how lookups in the radix tree work, you pass a single address
 (like source or destination address of a packet) and see whether it
 matches a table. The filtering engine always has one single address (of
 a packet) to check, never a netblock.
 
 If you could pass a netblock as argument, semantics are unclear, for
 instance, how should the table
 
   10.0.0.0/8
   10.1.2.0/24
   !10.1.2.3
 
 match pfctl -vvTt 10.1.0.0/16? What if netblock entries of the table
 overlap, and your argument partially overlaps several of them? What
 about negated entries?
 
 I can't think of one single definition that would make more sense than
 any other, and I don't think the radix tree API would even allow a
 lookup with a netblock (it just makes no sense, since nothing else does
 that).
 
 Daniel