From owner-freebsd-current@freebsd.org Thu Nov 5 01:57:38 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 6CC14A262EB for ; Thu, 5 Nov 2015 01:57:38 +0000 (UTC) (envelope-from tom@uffner.com) Received: from eris.uffner.com (eris.uffner.com [71.162.143.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "eris.uffner.com", Issuer "Uffner.com CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 354DD1E74 for ; Thu, 5 Nov 2015 01:57:37 +0000 (UTC) (envelope-from tom@uffner.com) Received: from discordia.uffner.com (discordia.uffner.com [10.69.69.61]) (authenticated bits=0) by eris.uffner.com (8.14.9/8.14.9) with ESMTP id tA51VZIR045567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=FAIL) for ; Wed, 4 Nov 2015 20:31:43 -0500 (EST) (envelope-from tom@uffner.com) Message-ID: <563AB177.6030809@uffner.com> Date: Wed, 04 Nov 2015 20:31:35 -0500 From: Tom Uffner User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:36.0) Gecko/20100101 Firefox/36.0 SeaMonkey/2.33.1 MIME-Version: 1.0 To: FreeBSD-Current Subject: r289932 causes pf reversion - breaks rules with broadcast destination Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 01:57:38 -0000 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. this broke access to my samba shares, and every "pass in ..." rule occurring after the samba rule in my pf.conf. for example, the host in question is a file server that allows SMB access on my DMZ network. prior to r289932 the I could allow clients to browse shares with pf rules such as: pass in log on $dmz_if proto tcp from $ext_if:network to $dmz_if:0 \ port { 137 139 445 } pass in log on $dmz_if proto udp from $ext_if:network to $dmz_if:0 port 137 pass in log on $dmz_if proto udp from $ext_if:network to $dmz_if:broadcast \ port { 137 138 } after r289932 the 3rd of these was silently ignored -- pf parsed it w/o complaint and listed it w/ "pfctl -s rules" but packets that should have been allowed were instead matched by my default rule 0 ("block log all") as were packets that should have matched later pass in rules. it did not matter if the rule used an explicit address (... to 10.10.61.255) or interface (... to re0:broadcast) or a macro (to $dmz_if:broadcast). 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. tom