From owner-freebsd-pf@freebsd.org Tue Mar 16 10:37:18 2021 Return-Path: Delivered-To: freebsd-pf@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C4C055A80F7 for ; Tue, 16 Mar 2021 10:37:18 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from sender4-of-o58.zoho.com (sender4-of-o58.zoho.com [136.143.188.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F08qd4LQKz3s68 for ; Tue, 16 Mar 2021 10:37:17 +0000 (UTC) (envelope-from patfbsd@davenulle.org) ARC-Seal: i=1; a=rsa-sha256; t=1615891034; cv=none; d=zohomail.com; s=zohoarc; b=LO54JsfNmvtzSdJtz71K7vUzql9ZJC6ETjUoQ5ilFTlSIjaLAdG2hfSzRNrBuCrOQ9Sqn/vXVwBHqH86KsFbeTlV5TIuXVZd6p2evgjWt/RNq3nMU91lHvI8T4rmyPaUrrZqsOttd4RR9qnKiZWxBUSEpWAlxZd1AfPTUbpgQvc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1615891034; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=P7Bby7A3LEgwPvPWVWpn5aNttRCMXNHOjkh53xEzuFk=; b=EsmihVNO1HrnkMnXM0DLt3vQfYe0K6xNBg9T0D2vS3tifJNz/ZkUOTwkL0HDtRdJ2fDanTXwJUDcR1ajUeAqW1bvAsQXsg70v4tWxIqMcmXMk8oFfchmpnUu2UFWV+ISacdtsqnWW5OVwGjavWiGDR1ONQHfqqKKcl5bd4DrvZQ= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass smtp.mailfrom=patfbsd@davenulle.org; dmarc=pass header.from= header.from= Received: from mr185033.univ-rennes1.fr (mr185033.univ-rennes1.fr [129.20.185.33]) by mx.zohomail.com with SMTPS id 161589103035054.861452025714016; Tue, 16 Mar 2021 03:37:10 -0700 (PDT) Date: Tue, 16 Mar 2021 11:37:02 +0100 From: Patrick Lamaiziere To: "Kristof Provost" Cc: freebsd-pf@freebsd.org Subject: Re: pfctl segmentation fault in pfctl_optimize.c Message-ID: <20210316113702.4b3de39b@mr185033.univ-rennes1.fr> In-Reply-To: <7963281C-B340-4AF3-9BBB-1D894DAC15E9@FreeBSD.org> References: <20210309110530.63834499@mr185033.univ-rennes1.fr> <20210312140010.506b668c@mr185033.univ-rennes1.fr> <7963281C-B340-4AF3-9BBB-1D894DAC15E9@FreeBSD.org> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External X-Rspamd-Queue-Id: 4F08qd4LQKz3s68 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; arc=pass (zohomail.com:s=zohoarc:i=1); dmarc=none; spf=none (mx1.freebsd.org: domain of patfbsd@davenulle.org has no SPF policy when checking 136.143.188.58) smtp.mailfrom=patfbsd@davenulle.org X-Spamd-Result: default: False [-4.10 / 15.00]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[136.143.188.58:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[davenulle.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[136.143.188.58:from]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2639, ipnet:136.143.188.0/23, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-pf]; ARC_ALLOW(-1.00)[zohomail.com:s=zohoarc:i=1] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 10:37:18 -0000 On Fri, 12 Mar 2021 14:06:22 +0100 "Kristof Provost" wrote: Hello, > On 12 Mar 2021, at 14:00, Patrick Lamaiziere wrote: > > I've read the code of pfctl a bit. If pfctl crashes in=20 > > pfctl_optimize_ruleset, is there a risk to leave pf in a bad state ? > > Looks like the rules are sent to pf via ioctl after the > > optimization so a crash before should be harmless (?). > > =20 > That should be the case, yes. >=20 > I=E2=80=99ve not checked the pfctl code to see if it actually starts the= =20 > operation to change the rules or not, but either way, pf rule changes=20 > are atomic. > They either succeed completely or not at all. >=20 > Pf accomplishes this by keeping an active and inactive ruleset, and > when you load new rules pfctl will start a transaction (DIOCXBEGIN), > add the complete new ruleset (DIOCADDRULE) and only then commit to > swapping the active and inactive rulesets (DIOCXCOMMIT). Ok thanks a lot Kristof. So I don't have any explanation for my problem. We will check that the firewalls filter out some trafic, stop ip forwarding if not and try to gather more informations. Best regards.