On Mon, Mar 06, 2006 at 09:25:23PM +0100, Daniel Hartmeier wrote:
> On Sat, Mar 04, 2006 at 04:04:23PM +0100, Sven Ingebrigt Ulland wrote:
> > What exactly does pfctl_get_pool() do, and why is it there? I did not
> > get much smarter by looking at the function and trying to figure out
> > what it does. It runs DIOCGETADDRS to get the ticket, and then
> > DIOCGETADDR, both of which can fail (for reasons I'm unable to figure
> > out).
>
> It downloads a pool (a set, a list) of addresses associated with the
> rule from the kernel, and stores it in the structure.
>
> See print pfctl_parser.c print_rule() and print_pool().
>
> Filter rules can have a pool of addresses as parameters for the
> 'route/reply/dup-to' options, as in
>
> pass ... route-to { ( xl0 10.1.2.3 ), ( xl1 10.2.3.4 ) } ...
>
> Translation rules can have a pool of replacement addresses, as in
>
> nat ... -> { 10.1.2.3, 10.2.3.4 } round-robin
>
> Even when such rules only use a single address as parameter, we still
> call it a pool (one that just contains a single address), and
> pfctl_get_pool() fetches that.
Good explanation, I get it now.
> If you don't need to do anything with the pool addresses (i.e. you don't
> want to show them), there's no need to fetch them. pfctl -sr prints
> them, so it has to fetch them.
Yup, I don't need to get the pools. Thanks for the answer, Daniel.
sven
