Date: Thu, 5 Nov 2015 22:58:51 +0100 From: Kristof Provost <kp@FreeBSD.org> To: Tom Uffner <tom@uffner.com> Cc: FreeBSD-Current <freebsd-current@FreeBSD.org> Subject: Re: r289932 causes pf reversion - breaks rules with broadcast destination Message-ID: <A12C5B03-DA5F-47BD-A459-7B81A15F1F16@FreeBSD.org> In-Reply-To: <563B944A.50905@uffner.com> References: <563AB177.6030809@uffner.com> <563B944A.50905@uffner.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 05 Nov 2015, at 18:39, Tom Uffner <tom@uffner.com> wrote: >=20 > Tom Uffner wrote: >> Commit r289932 causes pf rules with broadcast destinations (and some = but not >> all rules after them in pf.conf) to be silently ignored. This is bad. >=20 >> I do not understand the pf code well enough to see why this change = caused >> the breakage, but I suspect that it might expose some deeper problem = and >> should not simply be reverted. >=20 > OK, so here is why I don't want to simply back this out and have a = "working" > firewall again: >=20 > Apparently PF_ANEQ was prone to false positives when comparing IPv4 = addrs. > This is what r289932 and r289940 fixed. For IPv4 it does not matter = where > in bits 32-127 the address mismatch occurs or what order the garbage = data > is tested. That is all the paren fix in r289940 changes. It might be = relevant > for v6, but doesn't matter here. >=20 Yes, that=E2=80=99s right.=20 I haven=E2=80=99t yet had the time to look at your problem in any depth. I=E2=80=99m currently working on a different pf issue, but this one is = also high on my=20 priority list. Hopefully I=E2=80=99ll get round to it in the next few = days, but please do prod me=20 if you hear nothing. Regards, Kristof
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A12C5B03-DA5F-47BD-A459-7B81A15F1F16>