Re: r289932 causes pf reversion - breaks rules with broadcast destination

From: Florian Smeets <flo_at_smeets.xyz>
Date: Fri, 6 Nov 2015 17:41:22 +0100
On 06.11.15 17:06, Kristof Provost wrote:
> I suspect I've also found the source of the problem:
> pf_addr_wrap_neq() uses PF_ANEQ(), but sets address family 0.
> As a result of the fix that now means we always return false there.
> 
> Can you give this a quick test:
> 
> diff --git a/sys/netpfil/pf/pf.c b/sys/netpfil/pf/pf.c
> index 1dfc37d..762b82e 100644
> --- a/sys/netpfil/pf/pf.c
> +++ b/sys/netpfil/pf/pf.c
> _at__at_ -1973,9 +1973,9 _at__at_ pf_addr_wrap_neq(struct pf_addr_wrap *aw1, struct pf_addr_wrap *aw2)
>         switch (aw1->type) {
>         case PF_ADDR_ADDRMASK:
>         case PF_ADDR_RANGE:
> -               if (PF_ANEQ(&aw1->v.a.addr, &aw2->v.a.addr, 0))
> +               if (PF_ANEQ(&aw1->v.a.addr, &aw2->v.a.addr, AF_INET6))
>                         return (1);
> -               if (PF_ANEQ(&aw1->v.a.mask, &aw2->v.a.mask, 0))
> +               if (PF_ANEQ(&aw1->v.a.mask, &aw2->v.a.mask, AF_INET6))
>                         return (1);
>                 return (0);
>         case PF_ADDR_DYNIFTL:
> 

I was affected by this, too. The patch above does indeed make my rule
set work again.

Thanks!
Florian


Received on Fri Nov 06 2015 - 15:41:49 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:00 UTC