From owner-freebsd-current@freebsd.org Thu Nov 5 21:59:00 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 605F9A260BB for ; Thu, 5 Nov 2015 21:59:00 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 299FF1913 for ; Thu, 5 Nov 2015 21:59:00 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from [IPv6:2a02:1811:2419:4e02:7588:40fe:7158:9ce] (unknown [IPv6:2a02:1811:2419:4e02:7588:40fe:7158:9ce]) by venus.codepro.be (Postfix) with ESMTPSA id 533AA20767; Thu, 5 Nov 2015 22:58:57 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3106\)) Subject: Re: r289932 causes pf reversion - breaks rules with broadcast destination From: Kristof Provost In-Reply-To: <563B944A.50905@uffner.com> Date: Thu, 5 Nov 2015 22:58:51 +0100 Cc: FreeBSD-Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <563AB177.6030809@uffner.com> <563B944A.50905@uffner.com> To: Tom Uffner X-Mailer: Apple Mail (2.3106) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 21:59:00 -0000 > On 05 Nov 2015, at 18:39, Tom Uffner 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