Date: Fri, 30 Aug 2019 12:27:40 +0200 From: "Kristof Provost" <kp@FreeBSD.org> To: "Goran =?utf-8?q?Meki=C4=87?=" <meka@tilda.center> Cc: "Andrew White" <andywhite@gmail.com>, freebsd-net@freebsd.org Subject: Re: pf (rules and nat) + (ipfw + dummynet) Message-ID: <B6C36E1C-E1BD-4AA4-8223-E1990BD61291@FreeBSD.org> In-Reply-To: <20190818093346.jjxdjkd5twzfg56c@hal9000.home.meka.rs> References: <CAOZMOUFfzoVj2mtOHcQRpkrjU%2B02-kik%2BNt7m0_oELUW=H=RXg@mail.gmail.com> <20190817215151.GA8888@vega.codepro.be> <20190818093346.jjxdjkd5twzfg56c@hal9000.home.meka.rs>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18 Aug 2019, at 11:33, Goran Meki=C4=87 wrote: > Hello, > > If I knew we almost made it compile and boot (with dummynet, pf and = > pflog loaded), > I would postpone the previous email. :o) > > The code I'm working on is = > https://github.com/mekanix/freebsd/tree/feature/pf+dummynet/12.0. > It is nothing more than releng/12.0 branch into which I copied parts = > of PFSense > code until it started working. I still don't know how to test it, as = > I'm not > sure what's the PFSense's syntax for pf.conf. I know you can use "ipfw > pipe list" to show the pipes without ipfw module loaded. Once loaded, > ipfw lets you manage dummynet. What I do for now is load ipfw, set the > pipes, unload ipfw. > > If anyone knows how to configure pf.conf so that it passes everything > it receives to dummynet, I'm all ears. I will "fork" /sbin/ipfw and > create /sbin/dnctl so we don't have to depend on IPFW at all, but I > would like it to start working like this, first. > Apple do this through dnctl as you=E2=80=99re proposing: = http://www.manpagez.com/man/8/dnctl/ They=E2=80=99ve even published source code for it: = https://opensource.apple.com/source/network_cmds/network_cmds-543.260.3/d= nctl/ I=E2=80=99m somewhat tempted towards an approach where the pipe definitio= ns = are part of pf.conf, for similarity with how ALTQ worked in pf, and how = dummynet now works in ipfw. That=E2=80=99s probably not a hard requiremen= t = though. If it makes more sense to have two tools then let=E2=80=99s go fo= r = that. > My concerns about this patch is that it changes IPFW, too. I don't = > know > if the following link is visible if you're not logged into github, but > it shows the difference between releng/12.0 and this branch: > https://github.com/freebsd/freebsd/compare/releng/12.0...mekanix:featur= e/pf+dummynet/12.0?expand=3D1 > One of the issues I have with the PFSense patches is that they=E2=80=99re= not = broken down into usefully documented chunks. From a quick look that diff = seems to contain completely unrelated changes. Part of the effort is certainly going to be to tease that apart, and = work out what bits are relevant (and *why*). Best regards, Kristof From owner-freebsd-net@freebsd.org Fri Aug 30 11:19:06 2019 Return-Path: <owner-freebsd-net@freebsd.org> Delivered-To: freebsd-net@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 4A9D5CB45F for <freebsd-net@mailman.nyi.freebsd.org>; Fri, 30 Aug 2019 11:19:06 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from sender4-of-o59.zoho.com (sender4-of-o59.zoho.com [136.143.188.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46KcS85cN3z4109 for <freebsd-net@freebsd.org>; Fri, 30 Aug 2019 11:19:04 +0000 (UTC) (envelope-from patfbsd@davenulle.org) ARC-Seal: i=1; a=rsa-sha256; t=1567163941; cv=none; d=zoho.com; s=zohoarc; b=Lbkog3vtZ0njz1v3vRcEVVAT+BoOt7B5BcqiiAmTCmxuDRamPv4RrfaFSaBKIAr63KBSj+EvD+kxrX/Y+l1Gc80LzfFiQeJaJVFhcAkXT3hDLWt3kNfcbHvfI9jGlyVQvLiUjxVm6Ax7hrTJMtdo1QGW5GeKH0eqnj48rsSEFLg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1567163941; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=7z8QAvzBA8XXn2axV+W6V7qsi30wSwDOm5XMz3upOs0=; b=Xn6kSDSQukxYgw7pz80YCeW/lwdE3gCedqfnYZO2B9mZdFCudtYv/Xibzu007gx4NtXCJL5A1eyI19qcwMTnHpWEOJX7GbFOfTZpY2F5sNi+KJmZqrlhXyYFXaX5yYjS8A3ddnjq06c+Mq+EA222w40pMnIMEiTQK7OAi9XaXYI= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=davenulle.org; spf=pass smtp.mailfrom=patfbsd@davenulle.org; dmarc=pass header.from=<patfbsd@davenulle.org> header.from=<patfbsd@davenulle.org> Received: from mr185033.univ-rennes1.fr (mr185033.univ-rennes1.fr [129.20.185.33]) by mx.zohomail.com with SMTPS id 1567163939869532.453351156497; Fri, 30 Aug 2019 04:18:59 -0700 (PDT) Date: Fri, 30 Aug 2019 13:18:52 +0200 From: Patrick Lamaiziere <patfbsd@davenulle.org> To: freebsd-net@freebsd.org Subject: Re: problem with carp on 11.3-RELEASE Message-ID: <20190830131852.42604d56@mr185033.univ-rennes1.fr> In-Reply-To: <20190829125441.12197ea8@mr185033.univ-rennes1.fr> References: <20190829125441.12197ea8@mr185033.univ-rennes1.fr> 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=US-ASCII Content-Transfer-Encoding: 7bit X-ZohoMailClient: External X-Rspamd-Queue-Id: 46KcS85cN3z4109 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of patfbsd@davenulle.org has no SPF policy when checking 136.143.188.59) smtp.mailfrom=patfbsd@davenulle.org X-Spamd-Result: default: False [-5.75 / 15.00]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[davenulle.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-1.66)[ipnet: 136.143.188.0/24(-4.86), asn: 2639(-3.39), country: US(-0.05)]; NEURAL_HAM_SHORT(-0.99)[-0.987,0]; RCVD_IN_DNSWL_NONE(0.00)[59.188.143.136.list.dnswl.org : 127.0.15.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:2639, ipnet:136.143.188.0/24, country:US]; ARC_ALLOW(-1.00)[i=1] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>, <mailto:freebsd-net-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>; List-Post: <mailto:freebsd-net@freebsd.org> List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>, <mailto:freebsd-net-request@freebsd.org?subject=subscribe> X-List-Received-Date: Fri, 30 Aug 2019 11:19:06 -0000 On Thu, 29 Aug 2019 12:54:41 +0200 Patrick Lamaiziere <patfbsd@davenulle.org> wrote: Hello, > I've upgraded our two firewalls from 11.2-RELEASE-p11 to 11.3 release > p3 and I'm seeing a problem with carp, the carp slave becomes briefly > MASTER and returns to the slave state. This occurs often. ... I've made an other attempt today and all is working fine. I don't know where was the issue but I think that's not related to FreeBSD. Sorry for the noise :-) Regards.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B6C36E1C-E1BD-4AA4-8223-E1990BD61291>