so PF_PRIO_NOTSET doesn't turn out to have been such a good idea.
Reasoning: prio 0 is valid. So to indicate we don't wanna touch the
prio I used said define. Which in turn means that each an every place
that makes new struct pf_rules has to initialize those fields.
So instead let&#x
On Wed, Jul 11, 2012 at 13:13 +0200, Henning Brauer wrote:
> ..because now you had to initialize both set_prio in pf_rule to it
> everywhere. we did that, at least in some parts of our tree...
> problem being of course that 0 is a valid value there and can\t easily
> be used as "don't touch" indica
Jul 2012 11:57:08 - 1.13
> +++ libexec/tftp-proxy/filter.c 11 Jul 2012 11:03:11 -
> @@ -176,7 +176,6 @@ prepare_rule(u_int32_t id, struct sockad
> pfr.rule.dst.port[0] = htons(d_port);
> pfr.rule.rtableid = -1;
> pfr.rule.onrdomain = -1;
> -
, struct sockad
pfr.rule.dst.port[0] = htons(d_port);
pfr.rule.rtableid = -1;
pfr.rule.onrdomain = -1;
- pfr.rule.set_prio[0] = pfr.rule.set_prio[1] = PF_PRIO_NOTSET;
pfr.rule.action = PF_PASS;
pfr.rule.quick = 1;
pfr.rule.log = rule_log;
Index: sbi
