Date: Tue, 03 Apr 2018 08:49:09 +0200 From: "Kristof Provost" <kp@FreeBSD.org> To: "Gleb Smirnoff" <glebius@FreeBSD.org> 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: <4F543A96-C6B1-4FF0-A501-BC6C7FD3F26A@FreeBSD.org> In-Reply-To: <20180402220430.GD1917@FreeBSD.org> References: <201803260936.w2Q9aMfD082758@repo.freebsd.org> <20180402220430.GD1917@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3 Apr 2018, at 0:04, Gleb Smirnoff wrote: > I just want to note that this is a huge change of behaviour > of pf(4) for a user. Over a decade everybody has been used > to the difference between "reload" and "resync". There is no difference. r330105 removed the ‘$pf_program -Fnat -Fqueue -Frules -FSources -Finfo -FTables -Fosfp’ line, but this never actually did what the author thought it did. pfctl only ever performed the last ‘-F’, not all of them, so all this ever did was flush the OS fingerprints information. Clearly that’s not what was intended. pf never actually breaks existing connections, because existing states keep using the rule that created them, regardless of the current rules. It wouldn’t have broken connections with resync either. A ‘restart’ will, because ‘start’ does ‘pfctl -F all’. If the flush had actually done what was intended it’d arguably have been a security issue, because reloading rules would then (briefly) open the firewall, allowing all traffic to pass and establish state. > Yes, I admit > that back in 2008 the difference was awkward and annoying, but > todays I'm afraid that change would be more annoying than > keeping status quo. > > This definitely shouldn't reach stable/11, absolutely. > I will wait to do the MFC until we’re in agreement about it. Regards, Kristof
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F543A96-C6B1-4FF0-A501-BC6C7FD3F26A>