From owner-svn-src-all@freebsd.org Tue Apr 3 16:06:49 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F210F59197; Tue, 3 Apr 2018 16:06:49 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (glebi.us [96.95.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B30C848E5; Tue, 3 Apr 2018 16:06:48 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id w33G6l2G052749 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 Apr 2018 09:06:47 -0700 (PDT) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id w33G6kN0052748; Tue, 3 Apr 2018 09:06:46 -0700 (PDT) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 3 Apr 2018 09:06:46 -0700 From: Gleb Smirnoff To: Kristof Provost Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r331546 - head/etc/rc.d Message-ID: <20180403160646.GE1917@FreeBSD.org> References: <201803260936.w2Q9aMfD082758@repo.freebsd.org> <20180402220430.GD1917@FreeBSD.org> <4F543A96-C6B1-4FF0-A501-BC6C7FD3F26A@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4F543A96-C6B1-4FF0-A501-BC6C7FD3F26A@FreeBSD.org> User-Agent: Mutt/1.9.3 (2018-01-21) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 16:06:49 -0000 On Tue, Apr 03, 2018 at 08:49:09AM +0200, Kristof Provost wrote: K> On 3 Apr 2018, at 0:04, Gleb Smirnoff wrote: K> > I just want to note that this is a huge change of behaviour K> > of pf(4) for a user. Over a decade everybody has been used K> > to the difference between "reload" and "resync". K> K> There is no difference. r330105 removed the ‘$pf_program -Fnat -Fqueue K> -Frules -FSources -Finfo -FTables -Fosfp’ line, but this never K> actually did what the author thought it did. K> pfctl only ever performed the last ‘-F’, not all of them, so all K> this ever did was flush the OS fingerprints information. Clearly K> that’s not what was intended. K> K> pf never actually breaks existing connections, because existing states K> keep using the rule that created them, regardless of the current rules. K> It wouldn’t have broken connections with resync either. A K> ‘restart’ will, because ‘start’ does ‘pfctl -F all’. K> K> If the flush had actually done what was intended it’d arguably have K> been a security issue, because reloading rules would then (briefly) open K> the firewall, allowing all traffic to pass and establish state. Hmm, may be I am wrong, but back when I was actively working with pf, the "reload" command would break the ssh connection I am using, so I have taught myself to use "resync". If I am wrong, please go forward :) -- Gleb Smirnoff