From owner-freebsd-ipfw@freebsd.org Sun Apr 29 21:01:39 2018 Return-Path: Delivered-To: freebsd-ipfw@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 1862BFB87F8 for ; Sun, 29 Apr 2018 21:01:39 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C5B5C70B48 for ; Sun, 29 Apr 2018 21:01:38 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 84C90FB87F2; Sun, 29 Apr 2018 21:01:38 +0000 (UTC) Delivered-To: ipfw@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 71069FB87F1 for ; Sun, 29 Apr 2018 21:01:38 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EC52070B23 for ; Sun, 29 Apr 2018 21:01:37 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 3FD6B1F2A2 for ; Sun, 29 Apr 2018 21:01:37 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w3TL1b4U055374 for ; Sun, 29 Apr 2018 21:01:37 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w3TL1btE055373 for ipfw@FreeBSD.org; Sun, 29 Apr 2018 21:01:37 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201804292101.w3TL1btE055373@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: ipfw@FreeBSD.org Subject: Problem reports for ipfw@FreeBSD.org that need special attention Date: Sun, 29 Apr 2018 21:01:37 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2018 21:01:39 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 215875 | [ipfw] ipfw lookup tables do not support mbuf_tag 1 problems total for which you should take action. From owner-freebsd-ipfw@freebsd.org Mon Apr 30 01:16:13 2018 Return-Path: Delivered-To: freebsd-ipfw@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 23A67FBF162 for ; Mon, 30 Apr 2018 01:16:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A9B8969D27 for ; Mon, 30 Apr 2018 01:16:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 6AA6FFBF15F; Mon, 30 Apr 2018 01:16:12 +0000 (UTC) Delivered-To: ipfw@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 56E60FBF15E for ; Mon, 30 Apr 2018 01:16:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E370D69D0C for ; Mon, 30 Apr 2018 01:16:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 34630215B3 for ; Mon, 30 Apr 2018 01:16:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w3U1GBob054757 for ; Mon, 30 Apr 2018 01:16:11 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w3U1GBGO054756 for ipfw@FreeBSD.org; Mon, 30 Apr 2018 01:16:11 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ipfw@FreeBSD.org Subject: [Bug 209680] ipfw: when enabled, net connections time out/ssh results in "broken pipe" Date: Mon, 30 Apr 2018 01:16:08 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: 0mp@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ipfw@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_severity keywords cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 01:16:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209680 Mateusz Piotrowski <0mp@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Affects Some People |Affects Many People Keywords| |patch CC| |0mp@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ipfw@freebsd.org Tue May 1 07:14:30 2018 Return-Path: Delivered-To: freebsd-ipfw@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 B10B9FAEFD8 for ; Tue, 1 May 2018 07:14:30 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B31075E68 for ; Tue, 1 May 2018 07:14:26 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (220-253-154-11.dyn.iinet.net.au [220.253.154.11]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w417EFqZ003829 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 1 May 2018 00:14:18 -0700 (PDT) (envelope-from julian@freebsd.org) To: "freebsd-ipfw@freebsd.org" From: Julian Elischer Subject: removing some error states Message-ID: <41bea4ce-de10-bdb9-1184-3016fa7c77ca@freebsd.org> Date: Tue, 1 May 2018 15:14:10 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 07:14:30 -0000 Many years ago I added code to ipfw so that if -q was set it would not complain about things that were unimportant, nor would it return an error code. Such things include removing table entries that are already gone and similar sorts of 'safe' operations. The idea is that you can write 'naive' scripts that don't need to do complicated checks to see if XXX is already present or gone.. In hte ame way that rm -f doesn't complain if the file doesn't exist..  You were going to delete it anyhow. I'd like that to continue to some of the new additions. for example the terribly annoying     ipfw: DEPRECATED: inserting data into non-existent table 18. (auto-created) (who cares?) and    ljcc-78# ipfw table 19 create      ipfw: Table creation failed: File exists As the script needs to run multiple times, I don't care if the table already exists. but I do care about other errors. I don't want to have to write special wrapper code for table create that is different from the wrappers elsewhere because it has to look for return code 71 and disregard it. Can we just have -q continue to ignore such errors please? thanks From owner-freebsd-ipfw@freebsd.org Tue May 1 15:03:34 2018 Return-Path: Delivered-To: freebsd-ipfw@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 9760FFADAC4 for ; Tue, 1 May 2018 15:03:34 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0746079C8F; Tue, 1 May 2018 15:03:33 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w41F3Pfj026424; Tue, 1 May 2018 08:03:25 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w41F3PxP026423; Tue, 1 May 2018 08:03:25 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201805011503.w41F3PxP026423@pdx.rh.CN85.dnsmgr.net> Subject: Re: removing some error states In-Reply-To: <41bea4ce-de10-bdb9-1184-3016fa7c77ca@freebsd.org> To: Julian Elischer Date: Tue, 1 May 2018 08:03:25 -0700 (PDT) CC: "freebsd-ipfw@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 15:03:34 -0000 > Many years ago I added code to ipfw so that if -q was set it would not > complain about > things that were unimportant, nor would it return an error code. > Such things include removing table entries that are already gone and > similar sorts of 'safe' operations. > The idea is that you can write 'naive' scripts that don't need to do > complicated checks to see if XXX is already present or gone.. > In hte ame way that rm -f doesn't complain if the file doesn't > exist..? You were going to delete it anyhow. > > > I'd like that to continue to some of the new additions. > for example the terribly annoying > ??? ipfw: DEPRECATED: inserting data into non-existent table 18. > (auto-created) (who cares?) > > and > > ?? ljcc-78# ipfw table 19 create > ???? ipfw: Table creation failed: File exists > > As the script needs to run multiple times, I don't care if the table > already exists. > but I do care about other errors. > I don't want to have to write special wrapper code for table create > that is different > from the wrappers elsewhere because it has to look for return code 71 > and disregard it. > Can we just have -q continue to ignore such errors please? I think there is a bigger question here, why was auto table creation with first insert "Deprecated" at all? This to me just seems like change cause someone could change it that has no usefull purpose or is there some great purpose this serves? Same with creation of an already existing file, why did that need to become a noisy warning/error? -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-ipfw@freebsd.org Tue May 1 17:05:28 2018 Return-Path: Delivered-To: freebsd-ipfw@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 E3D73FB0C21 for ; Tue, 1 May 2018 17:05:27 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C344755D4 for ; Tue, 1 May 2018 17:05:27 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (220-253-154-11.dyn.iinet.net.au [220.253.154.11]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w41H5LQu006597 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 1 May 2018 10:05:25 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: removing some error states To: "Rodney W. Grimes" Cc: "freebsd-ipfw@freebsd.org" References: <201805011503.w41F3PxP026423@pdx.rh.CN85.dnsmgr.net> From: Julian Elischer Message-ID: <81ced915-4dae-26c0-bc43-5ff5299d00d0@freebsd.org> Date: Wed, 2 May 2018 01:05:16 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <201805011503.w41F3PxP026423@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 17:05:28 -0000 On 1/5/18 11:03 pm, Rodney W. Grimes wrote: >> Many years ago I added code to ipfw so that if -q was set it would not >> complain about >> things that were unimportant, nor would it return an error code. >> Such things include removing table entries that are already gone and >> similar sorts of 'safe' operations. >> The idea is that you can write 'naive' scripts that don't need to do >> complicated checks to see if XXX is already present or gone.. >> In hte ame way that rm -f doesn't complain if the file doesn't >> exist..? You were going to delete it anyhow. >> >> >> I'd like that to continue to some of the new additions. >> for example the terribly annoying >> ??? ipfw: DEPRECATED: inserting data into non-existent table 18. >> (auto-created) (who cares?) >> >> and >> >> ?? ljcc-78# ipfw table 19 create >> ???? ipfw: Table creation failed: File exists >> >> As the script needs to run multiple times, I don't care if the table >> already exists. >> but I do care about other errors. >> I don't want to have to write special wrapper code for table create >> that is different >> from the wrappers elsewhere because it has to look for return code 71 >> and disregard it. >> Can we just have -q continue to ignore such errors please? > I think there is a bigger question here, why was auto table creation > with first insert "Deprecated" at all? This to me just seems like > change cause someone could change it that has no usefull purpose or > is there some great purpose this serves? > > Same with creation of an already existing file, why did that need > to become a noisy warning/error? > Well ther eis an argument (that I disagree with in this case) that any unexected even is an error.. Also the new tables can have many different key type and indexing algorithms, which need to be  declared up front. but I don't see that raising a fatal error for trying to delete something that doesn't exist or make something that already exists really helps much other than to make scripts more complicated. That's why I made it optional before.. Removing table entries that are not present could be an error you want to know about, but probably it isn't. From owner-freebsd-ipfw@freebsd.org Wed May 2 03:31:40 2018 Return-Path: Delivered-To: freebsd-ipfw@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 157E8FC06E7 for ; Wed, 2 May 2018 03:31:40 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B535B7F951; Wed, 2 May 2018 03:31:39 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (124-148-108-197.dyn.iinet.net.au [124.148.108.197]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w423VV7P008743 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 1 May 2018 20:31:36 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: removing some error states From: Julian Elischer To: "Rodney W. Grimes" Cc: "freebsd-ipfw@freebsd.org" , "Andrey V. Elsukov" , Oleg Bulyzhin References: <201805011503.w41F3PxP026423@pdx.rh.CN85.dnsmgr.net> <81ced915-4dae-26c0-bc43-5ff5299d00d0@freebsd.org> Message-ID: <30b5e916-60ef-c3fa-1f80-5858d0d6717c@freebsd.org> Date: Wed, 2 May 2018 11:31:26 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <81ced915-4dae-26c0-bc43-5ff5299d00d0@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 03:31:40 -0000 On 2/5/18 1:05 am, Julian Elischer wrote: > On 1/5/18 11:03 pm, Rodney W. Grimes wrote: >>> Many years ago I added code to ipfw so that if -q was set it would >>> not >>> complain about >>> things that were unimportant, nor would it return an error code. >>> Such things include removing table entries that are already gone and >>> similar sorts of 'safe' operations. >>> The idea is that you can write 'naive' scripts that don't need to do >>> complicated checks to see if XXX is already present or gone.. >>> In hte ame way that rm -f doesn't complain if the file doesn't >>> exist..? You were going to delete it anyhow. >>> >>> >>> I'd like that to continue to some of the new additions. >>> for example the terribly annoying >>>   ??? ipfw: DEPRECATED: inserting data into non-existent table 18. >>> (auto-created) (who cares?) >>> >>> and >>> >>>   ?? ljcc-78# ipfw table 19 create >>>   ???? ipfw: Table creation failed: File exists >>> >>> As the script needs to run multiple times, I don't care if the table >>> already exists. >>> but I do care about other errors. >>> I don't want to have to write special wrapper code for table create >>> that is different >>> from the wrappers elsewhere because it has to look for return code 71 >>> and disregard it. >>> Can we just have -q continue to ignore such errors please? >> I think there is a bigger question here, why was auto table creation >> with first insert "Deprecated" at all?   This to me just seems like >> change cause someone could change it that has no usefull purpose or >> is there some great purpose this serves? >> >> Same with creation of an already existing file, why did that need >> to become a noisy warning/error? >> > Well ther eis an argument (that I disagree with in this case) that > any unexected even is an error.. > > Also the new tables can have many different key type and indexing > algorithms, which need to be  declared up front. > > but I don't see that raising a fatal error for trying to delete > something that doesn't exist or make something that already exists > really helps much other than to make scripts more complicated. > That's why I made it optional before.. Removing table entries that > are not present could be an error you want to know about, but > probably it isn't. > my biggest issue is that it bombs out when you are using it as a filter. e.g. (manual simulation) 32Ssd# ipfw -q -f /dev/tty    <---- -q   "don't complain and quit on unimportant things  -f  "trust me I know what I'm doing" table 3 add 1.1.1.1 table 3 add 1.1.1.1       <- no error.. this is what I want.. table 20 add 2.2.2.2 table 3 swap 20 table all list --- table(3), set(0) --- 2.2.2.2/32 0 --- table(20), set(0) --- 1.1.1.1/32 0 table 3 swap 21      <--  doesn't quit, but doesn't generate a new empty 21 either :-( table all list --- table(3), set(0) --- 2.2.2.2/32 0 --- table(20), set(0) --- 1.1.1.1/32 0 table 21 create table 21 create  <------ this shouldn't quit..   actually I wouldprefer that I didnt NEED to make the damned things. Any reference should make it.. (e.g. swap) Line 6: Table creation failed: File exists 32Ssd#       "congratulations the parent process now has to restart it.." The Cisco/Ironport "Web Security Appliance" ran like this, with a python process feeding commands into a single instance of ipfw. I don't know if it still does (Doug Ambrisko may know).  I use this method of running ipfw regularly, as forking and exec-ing a new copy of ipfw for every firewall operation is a huge waste of resources when you have a dynamic firewall that is constantly adding and removing table entries and rules, as well as doing load control with dummynet. Last thing I need is for ipfw to start quitting on operations that should be idempotent. interestingly the man page no longer shows how to run with input from a file in hte synopsis (though it refers to it)    LIST OF RULES AND PREPROCESSING      To ease configuration, rules can be put into a file which is processed      using ipfw as shown in the last synopsis line.  An absolute pathname must      be used.  The file will be read line by line and applied as arguments to      the ipfw utility. errr, no such example.  I think I will look into adding a -F option to allow for input from a file or stdin.. and make it shut the heck up in that mode (implies -q and -f) Julian > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > From owner-freebsd-ipfw@freebsd.org Thu May 3 08:16:36 2018 Return-Path: Delivered-To: freebsd-ipfw@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 EC4D9FC90EF for ; Thu, 3 May 2018 08:16:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 842E977F46 for ; Thu, 3 May 2018 08:16:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 439EBFC90ED; Thu, 3 May 2018 08:16:35 +0000 (UTC) Delivered-To: ipfw@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 30F4FFC90EC for ; Thu, 3 May 2018 08:16:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BF34A77F3F for ; Thu, 3 May 2018 08:16:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id E3F502AF3B for ; Thu, 3 May 2018 08:16:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w438GXRq019988 for ; Thu, 3 May 2018 08:16:33 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w438GXfn019987 for ipfw@FreeBSD.org; Thu, 3 May 2018 08:16:33 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ipfw@FreeBSD.org Subject: [Bug 227674] [ipfw] [ipv6] ICMPv6 echo replies incorrectly matched by kernel ipfw Date: Thu, 03 May 2018 08:16:34 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ipfw@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 08:16:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227674 --- Comment #4 from commit-hook@freebsd.org --- A commit references this bug: Author: ae Date: Thu May 3 08:15:32 UTC 2018 New revision: 333206 URL: https://svnweb.freebsd.org/changeset/base/333206 Log: MFC r332886: icmp6_reflect() sends ICMPv6 message with new IPv6 header. So, it is considered as originated by our host packet. And thus rcvif should be NULL, since it is used by ipfw(4) to determine that packet was originat= ed from this host. Some of icmp6_reflect() consumers reuse mbuf and m_pkth= dr without resetting rcvif pointer. To avoid this always reset m_pkthdr.rc= vif pointer to NULL in icmp6_reflect(). Also remove such line and comment describing this from icmp6_error(), since it does not longer matters. PR: 227674 Changes: _U stable/11/ stable/11/sys/netinet6/icmp6.c --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ipfw@freebsd.org Thu May 3 13:43:50 2018 Return-Path: Delivered-To: freebsd-ipfw@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 C10AFFABD13 for ; Thu, 3 May 2018 13:43:49 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward101j.mail.yandex.net (forward101j.mail.yandex.net [IPv6:2a02:6b8:0:801:2::101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 25B96825F8; Thu, 3 May 2018 13:43:49 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback20j.mail.yandex.net (mxback20j.mail.yandex.net [IPv6:2a02:6b8:0:1619::114]) by forward101j.mail.yandex.net (Yandex) with ESMTP id C53711242678; Thu, 3 May 2018 16:43:46 +0300 (MSK) Received: from smtp1j.mail.yandex.net (smtp1j.mail.yandex.net [2a02:6b8:0:801::ab]) by mxback20j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 3nIHFROe6D-hkuerlPq; Thu, 03 May 2018 16:43:46 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1525355026; bh=khP9Ao8G38osWpGl2rBXof/9lXzajjNM8RtQwnABbmQ=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To; b=QeAexKjWt6jjUxsnbe03diIBS7+xL+8gNYta0Z0jtCLCHcXwBBuJUSNcXx1SN2Dq5 0tBP1i10ndJaOduC09LWkt+myuadROExMWIg6rMBEiU1zn3GF7BkdvhDzR4pQ4aHEI CD/Bpu33vb+cz1FJJ2frXwIJUwUpQ5yaCL5s92A0= Received: by smtp1j.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 2XRv4wfdqi-hjcmOMv9; Thu, 03 May 2018 16:43:46 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1525355026; bh=khP9Ao8G38osWpGl2rBXof/9lXzajjNM8RtQwnABbmQ=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To; b=QeAexKjWt6jjUxsnbe03diIBS7+xL+8gNYta0Z0jtCLCHcXwBBuJUSNcXx1SN2Dq5 0tBP1i10ndJaOduC09LWkt+myuadROExMWIg6rMBEiU1zn3GF7BkdvhDzR4pQ4aHEI CD/Bpu33vb+cz1FJJ2frXwIJUwUpQ5yaCL5s92A0= Authentication-Results: smtp1j.mail.yandex.net; dkim=pass header.i=@yandex.ru Subject: Re: removing some error states To: Julian Elischer , "Rodney W. Grimes" Cc: "freebsd-ipfw@freebsd.org" , Oleg Bulyzhin , "Alexander V. Chernikov" References: <201805011503.w41F3PxP026423@pdx.rh.CN85.dnsmgr.net> <81ced915-4dae-26c0-bc43-5ff5299d00d0@freebsd.org> <30b5e916-60ef-c3fa-1f80-5858d0d6717c@freebsd.org> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Autocrypt: addr=bu7cher@yandex.ru; prefer-encrypt=mutual; keydata= xsBNBEwBF1kBCADB9sXFhBEUy8qQ4X63Y8eBatYMHGEFWN9ypS5lI3RE6qQW2EYbxNk7qUC5 21YIIS1mMFVBEfvR7J9uc7yaYgFCEb6Sce1RSO4ULN2mRKGHP3/Sl0ijZEjWHV91hY1YTHEF ZW/0GYinDf56sYpDDehaBF5wkWIo1+QK5nmj3vl0DIDCMNd7QEiWpyLVwECgLX2eOAXByT8B bCqVhJGcG6iFP7/B9Ll6uX5gb8thM9LM+ibwErDBVDGiOgvfxqidab7fdkh893IBCXa82H9N CNwnEtcgzh+BSKK5BgvPohFMgRwjti37TSxwLu63QejRGbZWSz3OK3jMOoF63tCgn7FvABEB AAHNIkFuZHJleSBWLiBFbHN1a292IDxhZUBmcmVlYnNkLm9yZz7CwHsEEwECACUCGwMGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheABQJMB/ruAhkBAAoJEAHF6gQQyKF6MLwH/3Ri/TZl9uo0 SepYWXOnxL6EaDVXDA+dLb1eLKC4PRBBjX29ttQ0KaWapiE6y5/AfzOPmRtHLrHYHjd/aiHX GMLHcYRXD+5GvdkK8iMALrZ28X0JXyuuZa8rAxWIWmCbYHNSBy2unqWgTI04Erodk90IALgM 9JeHN9sFqTM6zalrMnTzlcmel4kcjT3lyYw3vOKgoYLtsLhKZSbJoVVVlvRlGBpHFJI5AoYJ SyfXoN0rcX6k9X7Isp2K50YjqxV4v78xluh1puhwZyC0p8IShPrmrp9Oy9JkMX90o6UAXdGU KfdExJuGJfUZOFBTtNIMNIAKfMTjhpRhxONIr0emxxDOwE0ETAEXWQEIAJ2p6l9LBoqdH/0J PEFDY2t2gTvAuzz+8zs3R03dFuHcNbOwjvWCG0aOmVpAzkRa8egn5JB4sZaFUtKPYJEQ1Iu+ LUBwgvtXf4vWpzC67zs2dDuiW4LamH5p6xkTD61aHR7mCB3bg2TUjrDWn2Jt44cvoYxj3dz4 S49U1rc9ZPgD5axCNv45j72tggWlZvpefThP7xT1OlNTUqye2gAwQravXpZkl5JG4eOqJVIU X316iE3qso0iXRUtO7OseBf0PiVmk+wCahdreHOeOxK5jMhYkPKVn7z1sZiB7W2H2TojbmcK HZC22sz7Z/H36Lhg1+/RCnGzdEcjGc8oFHXHCxUAEQEAAcLAXwQYAQIACQUCTAEXWQIbDAAK CRABxeoEEMihegkYCAC3ivGYNe2taNm/4Nx5GPdzuaAJGKWksV+w9mo7dQvU+NmI2az5w8vw 98OmX7G0OV9snxMW+6cyNqBrVFTu33VVNzz9pnqNCHxGvj5dL5ltP160JV2zw2bUwJBYsgYQ WfyJJIM7l3gv5ZS3DGqaGIm9gOK1ANxfrR5PgPzvI9VxDhlr2juEVMZYAqPLEJe+SSxbwLoz BcFCNdDAyXcaAzXsx/E02YWm1hIWNRxanAe7Vlg7OL+gvLpdtrYCMg28PNqKNyrQ87LQ49O9 50IIZDOtNFeR0FGucjcLPdS9PiEqCoH7/waJxWp6ydJ+g4OYRBYNM0EmMgy1N85JJrV1mi5i Message-ID: Date: Thu, 3 May 2018 16:41:50 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <30b5e916-60ef-c3fa-1f80-5858d0d6717c@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5ExKROSMi2sBUAxV0vF6MoNrhG6ImwFN9" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 13:43:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5ExKROSMi2sBUAxV0vF6MoNrhG6ImwFN9 Content-Type: multipart/mixed; boundary="owiHKGOpTx9nVrsLbmcfUaSug8eGhdGCE"; protected-headers="v1" From: "Andrey V. Elsukov" To: Julian Elischer , "Rodney W. Grimes" Cc: "freebsd-ipfw@freebsd.org" , Oleg Bulyzhin , "Alexander V. Chernikov" Message-ID: Subject: Re: removing some error states References: <201805011503.w41F3PxP026423@pdx.rh.CN85.dnsmgr.net> <81ced915-4dae-26c0-bc43-5ff5299d00d0@freebsd.org> <30b5e916-60ef-c3fa-1f80-5858d0d6717c@freebsd.org> In-Reply-To: <30b5e916-60ef-c3fa-1f80-5858d0d6717c@freebsd.org> --owiHKGOpTx9nVrsLbmcfUaSug8eGhdGCE Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 02.05.2018 06:31, Julian Elischer wrote: >>>> Many years ago I added code to ipfw so that if -q was set it would n= ot >>>> complain about >>>> things that were unimportant, nor would it return an error code. >>>> Such things include removing table entries that are already gone and= >>>> similar sorts of 'safe' operations. >>>> The idea is that you can write 'naive' scripts that don't need to do= >>>> complicated checks to see if XXX is already present or gone.. >>>> In hte ame way that rm -f doesn't complain if the file doesn't >>>> exist..? You were going to delete it anyhow. Hi, I added melifaro@ to CC list. IMHO, ignoring errors when you configuring firewall is not a good idea. I'm agree, that some errors are noisy, and also some of them were already fixed, so you can just submit PR or patch, if you don't like some. Due to huge difference between old tables and what we have now, it is not always possible for one man to test all old features and properly merge them with new features. --=20 WBR, Andrey V. Elsukov --owiHKGOpTx9nVrsLbmcfUaSug8eGhdGCE-- --5ExKROSMi2sBUAxV0vF6MoNrhG6ImwFN9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAlrrEZ4ACgkQAcXqBBDI oXpGkQgApsEw2eMcPiskoggGDtpzUpHRDE7Ei4TDqxj448HIIYGCxw2YmwC/tCmH kRkiulrvqt1/fDX8qU13Wsh/lOt48Uff3AQxF547uWZBt0G1FPBwFhqy/ATUBO2L rf4i6svLat13Sc8pORAncjf+M82bSwNju6PQRCT4OpfEf+lbmj7r7czDagB3P5rR lbfhNYRi9xGeEsiE2kTpBmWmrZMbuqtPlxDlE1y/tF+B3WbhQAFu9ZHciDBYp8NB ZLQ6OeBnNmqTl7mi3w2uF7z6qn2Rd4X6CZieSk2ikSBkDoJBZcjunzucmXNjrVuX 1y0JUg5+O/B7rWkSoITle8+dwOjVuA== =4DfB -----END PGP SIGNATURE----- --5ExKROSMi2sBUAxV0vF6MoNrhG6ImwFN9-- From owner-freebsd-ipfw@freebsd.org Thu May 3 22:23:16 2018 Return-Path: Delivered-To: freebsd-ipfw@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 CB728FBE3DB for ; Thu, 3 May 2018 22:23:15 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward5p.cmail.yandex.net (forward5p.cmail.yandex.net [IPv6:2a02:6b8:0:1465::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D5C074CAE; Thu, 3 May 2018 22:23:14 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mxback5o.mail.yandex.net (mxback5o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::1f]) by forward5p.cmail.yandex.net (Yandex) with ESMTP id 6683E21018; Fri, 4 May 2018 01:23:04 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback5o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id L5s8Ffi0PR-N38qLaQt; Fri, 04 May 2018 01:23:03 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfw.ru; s=mail; t=1525386183; bh=8cWbpX2oLbkoeilPEHes1NInfxNcJmNNS7L6GlezVJw=; h=From:To:Cc:In-Reply-To:References:Subject:Message-Id:Date; b=WXl5Go8AiV0a8POFFXhjpx73/jdanuQkWL1/Hi/24azZg2GQQNbqWG/cG2ClgVy/e PHWPCz/R/4nXB/plEgGOBxpn6vvs+Oxb/MpWl1nYGkSIopvE6LuKXt1/BuEbQ0tQAC vy4GiCLK6KQvarYUKwrkokL9WWj2lxJwtjwTbxGo= Authentication-Results: mxback5o.mail.yandex.net; dkim=pass header.i=@ipfw.ru Received: by web50g.yandex.ru with HTTP; Fri, 04 May 2018 01:23:03 +0300 From: Alexander V. Chernikov To: Julian Elischer , Rodney W. Grimes Cc: "freebsd-ipfw@freebsd.org" , Oleg Bulyzhin , Andrey V. Elsukov In-Reply-To: <30b5e916-60ef-c3fa-1f80-5858d0d6717c@freebsd.org> References: <201805011503.w41F3PxP026423@pdx.rh.CN85.dnsmgr.net> <81ced915-4dae-26c0-bc43-5ff5299d00d0@freebsd.org> <30b5e916-60ef-c3fa-1f80-5858d0d6717c@freebsd.org> Subject: Re: removing some error states MIME-Version: 1.0 Message-Id: <11885361525386183@web50g.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Fri, 04 May 2018 01:23:03 +0300 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 22:23:16 -0000 02.05.2018, 06:32, "Julian Elischer" : > On 2/5/18 1:05 am, Julian Elischer wrote: >>  On 1/5/18 11:03 pm, Rodney W. Grimes wrote: >>>>  Many years ago I added code to ipfw so that if -q was set it would >>>>  not >>>>  complain about >>>>  things that were unimportant, nor would it return an error code. >>>>  Such things include removing table entries that are already gone and >>>>  similar sorts of 'safe' operations. >>>>  The idea is that you can write 'naive' scripts that don't need to do >>>>  complicated checks to see if XXX is already present or gone.. >>>>  In hte ame way that rm -f doesn't complain if the file doesn't >>>>  exist..? You were going to delete it anyhow. >>>> >>>>  I'd like that to continue to some of the new additions. >>>>  for example the terribly annoying >>>>    ??? ipfw: DEPRECATED: inserting data into non-existent table 18. >>>>  (auto-created) (who cares?) >>>> >>>>  and >>>> >>>>    ?? ljcc-78# ipfw table 19 create >>>>    ???? ipfw: Table creation failed: File exists >>>> >>>>  As the script needs to run multiple times, I don't care if the table >>>>  already exists. >>>>  but I do care about other errors. >>>>  I don't want to have to write special wrapper code for table create >>>>  that is different >>>>  from the wrappers elsewhere because it has to look for return code 71 >>>>  and disregard it. >>>>  Can we just have -q continue to ignore such errors please? >>>  I think there is a bigger question here, why was auto table creation >>>  with first insert "Deprecated" at all?   This to me just seems like >>>  change cause someone could change it that has no usefull purpose or >>>  is there some great purpose this serves? In the "old" world we had single type of tables, each of them name by numbers from 1.. ip.fw.tables_max range. If the table number was less than ip.fw.tables_max - it automatically existed. If not, one had to increase ip.fw.tables_max. In the new world, number of different table types / configuration is pretty large. Additionally, one can use string names as table identifiers. In most cases, user wants to have "old" kind of table with default values, but it might not always be the case. Let's suppose one wants to have special kind of table, but forgots to create it. Then, silently creating default table upon insertion will simply hide an error leading to undesired hard-to-dianose behaviour on later stages. >>> >>>  Same with creation of an already existing file, why did that need >>>  to become a noisy warning/error? >>  Well ther eis an argument (that I disagree with in this case) that >>  any unexected even is an error.. >> >>  Also the new tables can have many different key type and indexing >>  algorithms, which need to be  declared up front. >> >>  but I don't see that raising a fatal error for trying to delete >>  something that doesn't exist or make something that already exists >>  really helps much other than to make scripts more complicated. >>  That's why I made it optional before.. Removing table entries that >>  are not present could be an error you want to know about, but >>  probably it isn't. The question here is what is the desired level of "smartness" ipfw(8) should implement. Traditionally it was a pretty low-level tool, used by other scripts/tools to manipulate the ruleset. In that case then generic idea is that we should propagate the error, so one can handle it properly in the upper layer. > > my biggest issue is that it bombs out when you are using it as a filter. > e.g. (manual simulation) I understand your frustration. The original changeset for the named tables was pretty big and I was mostly focused on fixing the kernel and providing backward compatibility, so some of the ipfw(8) stuff were not though thoughtfully. Let's discuss/agree on the desired behaviour and fix it. > > 32Ssd# ipfw -q -f /dev/tty    <---- -q   "don't complain and quit on > unimportant things  -f  "trust me I know what I'm doing" I always thought of "-q" meaning as mostly "Be quiet when executing ..." as ipfw(8) manual states, which is different from the generic "ignore errors". I totally agree that having some way of saying "ignore the error and continue" is a thing we should have. Probably, adding another option for that would be an overkill, so we indeed can rebrand "-q". > table 3 add 1.1.1.1 > table 3 add 1.1.1.1       <- no error.. this is what I want.. > table 20 add 2.2.2.2 > table 3 swap 20 > table all list > --- table(3), set(0) --- > 2.2.2.2/32 0 > --- table(20), set(0) --- > 1.1.1.1/32 0 > table 3 swap 21      <--  doesn't quit, but doesn't generate a new > empty 21 either :-( What is the "proper" behaviour from your pov here? (with and without -q)? > table all list > --- table(3), set(0) --- > 2.2.2.2/32 0 > --- table(20), set(0) --- > 1.1.1.1/32 0 > table 21 create > table 21 create  <------ this shouldn't quit..   actually I This shouldn't quit IFF "-q" is supplied and the already-created table is absolutely the same in terms of types, algorithms and values? > wouldprefer that I didnt NEED to make the damned things. Any reference > should make it.. (e.g. swap) > Line 6: Table creation failed: File exists > 32Ssd# >        "congratulations the parent process now has to restart it.." > > The Cisco/Ironport "Web Security Appliance" ran like this, with a > python process feeding commands into a single instance of ipfw. > I don't know if it still does (Doug Ambrisko may know).  I use this > method of running ipfw regularly, as forking and exec-ing a new copy > of ipfw for every firewall operation is a huge waste of resources when > you have a dynamic firewall that is constantly adding and removing > table entries and rules, as well as doing load control with dummynet. > Last thing I need is for ipfw to start quitting on operations that > should be idempotent. > > interestingly the man page no longer shows how to run with input from > a file in hte synopsis (though it refers to it) > >     LIST OF RULES AND PREPROCESSING >       To ease configuration, rules can be put into a file which is > processed >       using ipfw as shown in the last synopsis line.  An absolute > pathname must >       be used.  The file will be read line by line and applied as > arguments to >       the ipfw utility. > > errr, no such example. >   I think I will look into adding a -F option to allow for input from > a file or stdin.. > and make it shut the heck up in that mode (implies -q and -f) > > Julian > >>  _______________________________________________ >>  freebsd-ipfw@freebsd.org mailing list >>  https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >>  To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@freebsd.org Fri May 4 19:41:26 2018 Return-Path: Delivered-To: freebsd-ipfw@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 CF959FB6364 for ; Fri, 4 May 2018 19:41:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 62DEB81FC8 for ; Fri, 4 May 2018 19:41:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 271C6FB6363; Fri, 4 May 2018 19:41:26 +0000 (UTC) Delivered-To: ipfw@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 148D8FB6362 for ; Fri, 4 May 2018 19:41:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9448581F94 for ; Fri, 4 May 2018 19:41:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id DE3A115BDA for ; Fri, 4 May 2018 19:41:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w44JfO8u018283 for ; Fri, 4 May 2018 19:41:24 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w44JfOOt018281 for ipfw@FreeBSD.org; Fri, 4 May 2018 19:41:24 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ipfw@FreeBSD.org Subject: [Bug 227674] [ipfw] [ipv6] ICMPv6 echo replies incorrectly matched by kernel ipfw Date: Fri, 04 May 2018 19:41:25 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ae@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 19:41:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227674 Eugene Grosbein changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ipfw@FreeBSD.org Assignee|ipfw@FreeBSD.org |ae@FreeBSD.org --- Comment #5 from Eugene Grosbein --- (In reply to Andrey V. Elsukov from comment #1) Have you any plans to merge this to stable/10 ? --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.= From owner-freebsd-ipfw@freebsd.org Sat May 5 18:03:31 2018 Return-Path: Delivered-To: freebsd-ipfw@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 42314FB5780 for ; Sat, 5 May 2018 18:03:31 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D6C188198A; Sat, 5 May 2018 18:03:30 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (124-148-108-197.dyn.iinet.net.au [124.148.108.197]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w45I3NYc029617 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 5 May 2018 11:03:26 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: removing some error states To: "Alexander V. Chernikov" , "Rodney W. Grimes" Cc: "freebsd-ipfw@freebsd.org" , Oleg Bulyzhin , "Andrey V. Elsukov" References: <201805011503.w41F3PxP026423@pdx.rh.CN85.dnsmgr.net> <81ced915-4dae-26c0-bc43-5ff5299d00d0@freebsd.org> <30b5e916-60ef-c3fa-1f80-5858d0d6717c@freebsd.org> <11885361525386183@web50g.yandex.ru> From: Julian Elischer Message-ID: <9d710171-22ff-7df9-a803-eca8469ad61f@freebsd.org> Date: Sun, 6 May 2018 02:03:18 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <11885361525386183@web50g.yandex.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2018 18:03:31 -0000 See inline thanks for answering Ont thing you need to understand is that I tend to run ipfw with a front-end. for example which is more efficient: cat <<-DONE  |ipfw -q -f /dev/stdin     add 1 (some rule}     [100 other  operations including table and pipe operations and more rules]     DONE vs ipfw -f -q add 1 (some rule) ipfw -f -q {operation} [...] 100 more ops, same as above.. obviously the first is orders of magnitude more efficient. I have wondered if you could feed a script into ipfw's preprocessor  feature so that it actually generated data instead of just filtering it, but I haven't tried it yet.. In the version I wrote for Cisco, it is a python program that is continually manipulating hte firewall by adding and removing table entries and rules as the world changes around it. So having to not for/exec a new copy of ipfw for every operations i important to me. Maybe we want to add a special mode (-I - ) to allow stdin to be used. using /dev/stdin is a hack. and there is no way to get any output back. I actually have a way to make it work as a shell script using netcat... The server part that stays resident does:  action ()   {     local LINE="$*"     logger -p user.info -t firewall "command $LINE"     set $LINE     local COMMAND=$1     shift     case ${COMMAND} in       setup-firewall)         # called from rc.d/postpixel8 and from rc.conf via ip_filter_rules.sh         setup_firewall $*         ;; [... lots of other commands ]   if [ $MODE = "server" ]   then     FIREWALL_DISABLED=     nc -U -k -l "$CONTROL_SOCKET" | while read LINE     do       action $LINE     done     logger -p user.info -t firewall "Server loop ended"     exit 0  # server never goes below this point   fi and the client just does:   if [ "$MODE" = "client" ]   then     echo $COMMAND $* | nc -N -U $CONTROL_SOCKET   fi sending high level commands to the server, and the server, keeps state, and feeds commands out via stdout to a copy of ipfw that is started at the time the server starts, and keeps running until it quits, doing ALL the low level 'ipfw' commands.. this mode of operation if very efficient and can lead to very sophisticated active firewalls as the server has local state about hte firewall and can  manipulate it with great speed and accuracy. anyhow.. to do this I need that the ipfw program not quit every time it gets something it doesn't like. Especially things like "clear a rule  without havng to first test whether it is there". or swap with a new table.. (just create an empty table of the same kind). Or pretty much anything else that would error out.. e.g. I want most  delete commands to be "optionally" idempotent. calling it should be ok regardless of whether the rule/table/pipe/whatever already exists or has already been deleted. Like rm -f . Maybe a special mode for running as a client may be good.. or maybe ipfw is in control and fires off a given program and controls both stdin and stdout. that way the script/progra can actually get feedback.  Something I've had a hard time doing.. also some ways to get events from the firewall would be amazing. Maybe what I want is a libipfw.so, but I want to be able to use it with shell scripts. On 4/5/18 6:23 am, Alexander V. Chernikov wrote: > 02.05.2018, 06:32, "Julian Elischer" : >> On 2/5/18 1:05 am, Julian Elischer wrote: >>>  On 1/5/18 11:03 pm, Rodney W. Grimes wrote: >>>>>  Many years ago I added code to ipfw so that if -q was set it would >>>>>  not >>>>>  complain about >>>>>  things that were unimportant, nor would it return an error code. >>>>>  Such things include removing table entries that are already gone and >>>>>  similar sorts of 'safe' operations. >>>>>  The idea is that you can write 'naive' scripts that don't need to do >>>>>  complicated checks to see if XXX is already present or gone.. >>>>>  In hte ame way that rm -f doesn't complain if the file doesn't >>>>>  exist..? You were going to delete it anyhow. >>>>> >>>>>  I'd like that to continue to some of the new additions. >>>>>  for example the terribly annoying >>>>>    ??? ipfw: DEPRECATED: inserting data into non-existent table 18. >>>>>  (auto-created) (who cares?) >>>>> >>>>>  and >>>>> >>>>>    ?? ljcc-78# ipfw table 19 create >>>>>    ???? ipfw: Table creation failed: File exists >>>>> >>>>>  As the script needs to run multiple times, I don't care if the table >>>>>  already exists. >>>>>  but I do care about other errors. >>>>>  I don't want to have to write special wrapper code for table create >>>>>  that is different >>>>>  from the wrappers elsewhere because it has to look for return code 71 >>>>>  and disregard it. >>>>>  Can we just have -q continue to ignore such errors please? >>>>  I think there is a bigger question here, why was auto table creation >>>>  with first insert "Deprecated" at all?   This to me just seems like >>>>  change cause someone could change it that has no usefull purpose or >>>>  is there some great purpose this serves? > In the "old" world we had single type of tables, each of them name by numbers from 1.. ip.fw.tables_max range. If the table number was less than ip.fw.tables_max - it automatically existed. If not, one had to increase ip.fw.tables_max. > In the new world, number of different table types / configuration is pretty large. Additionally, one can use string names as table identifiers. > In most cases, user wants to have "old" kind of table with default values, but it might not always be the case. Let's suppose one wants to have special kind of table, but forgots to create it. Then, silently creating default table upon insertion will simply hide an error leading to undesired hard-to-dianose behaviour on later stages. > >>>>  Same with creation of an already existing file, why did that need >>>>  to become a noisy warning/error? >>>  Well ther eis an argument (that I disagree with in this case) that >>>  any unexected even is an error.. >>> >>>  Also the new tables can have many different key type and indexing >>>  algorithms, which need to be  declared up front. >>> >>>  but I don't see that raising a fatal error for trying to delete >>>  something that doesn't exist or make something that already exists >>>  really helps much other than to make scripts more complicated. >>>  That's why I made it optional before.. Removing table entries that >>>  are not present could be an error you want to know about, but >>>  probably it isn't. > The question here is what is the desired level of "smartness" ipfw(8) should implement. Traditionally it was a pretty low-level tool, used by other scripts/tools to manipulate the ruleset. In that case then generic idea is that we should propagate the error, so one can handle it properly in the upper layer. Unless the upper layer has asked that certain classes (the idempotent class, e.g. delete or I suggest 'create') of commads do not generate that sort of error. >> my biggest issue is that it bombs out when you are using it as a filter. >> e.g. (manual simulation) > I understand your frustration. The original changeset for the named tables was pretty big and I was mostly focused on fixing the kernel and providing backward compatibility, so some of the ipfw(8) stuff were not though thoughtfully. Let's discuss/agree on the desired behaviour and fix it. well imagine my aim ... to pipe stuff to ipfw. anything that helps tha goal is my friend and anything that makes my scripts have to cope with things like ipfw suddenly dying is my enemy :-) whether we use stdin, stdout, file descriptor 10 through 12, unix domain sockets, or fifos is all up for discussion. >> 32Ssd# ipfw -q -f /dev/tty    <---- -q   "don't complain and quit on >> unimportant things  -f  "trust me I know what I'm doing" > I always thought of "-q" meaning as mostly "Be quiet when executing ..." as ipfw(8) manual states, which is different from the generic "ignore errors". > I totally agree that having some way of saying "ignore the error and continue" is a thing we should have. Probably, adding another option for that would be an overkill, so we indeed can rebrand "-q". it was never "ignore errors" It's "ignore a certain class of error". >> table 3 add 1.1.1.1 >> table 3 add 1.1.1.1       <- no error.. this is what I want.. >> table 20 add 2.2.2.2 >> table 3 swap 20 >> table all list >> --- table(3), set(0) --- >> 2.2.2.2/32 0 >> --- table(20), set(0) --- >> 1.1.1.1/32 0 >> table 3 swap 21      <--  doesn't quit, but doesn't generate a new just give me an empty table of the same type. or make table create not die if we call it twice. >> empty 21 either :-( > What is the "proper" behaviour from your pov here? (with and without -q)? without -q  probably an error  with -q swap in an empty table >> table all list >> --- table(3), set(0) --- >> 2.2.2.2/32 0 >> --- table(20), set(0) --- >> 1.1.1.1/32 0 >> table 21 create >> table 21 create  <------ this shouldn't quit..   actually I > This shouldn't quit IFF "-q" is supplied and the already-created table is absolutely the same in terms of types, algorithms and values? certainly that would qualify as idempotent >> wouldprefer that I didnt NEED to make the damned things. Any reference >> should make it.. (e.g. swap) >> Line 6: Table creation failed: File exists >> 32Ssd# >>        "congratulations the parent process now has to restart it.." >> >> The Cisco/Ironport "Web Security Appliance" ran like this, with a >> python process feeding commands into a single instance of ipfw. >> I don't know if it still does (Doug Ambrisko may know).  I use this >> method of running ipfw regularly, as forking and exec-ing a new copy >> of ipfw for every firewall operation is a huge waste of resources when >> you have a dynamic firewall that is constantly adding and removing >> table entries and rules, as well as doing load control with dummynet. >> Last thing I need is for ipfw to start quitting on operations that >> should be idempotent. >> >> interestingly the man page no longer shows how to run with input from >> a file in hte synopsis (though it refers to it) >> >>     LIST OF RULES AND PREPROCESSING >>       To ease configuration, rules can be put into a file which is >> processed >>       using ipfw as shown in the last synopsis line.  An absolute >> pathname must >>       be used.  The file will be read line by line and applied as >> arguments to >>       the ipfw utility. >> >> errr, no such example. >>   I think I will look into adding a -F option to allow for input from >> a file or stdin.. >> and make it shut the heck up in that mode (implies -q and -f) as mentioned above... and whether it's fire off a script that runs a copy of ipfw, or run ipfw and have it run the script is a legitimate question.. ipfw --run-master /usr/local/bin/firewallmaster (yes I know we don't have long args) >> >> Julian >> >>>  _______________________________________________ >>>  freebsd-ipfw@freebsd.org mailing list >>>  https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >>>  To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@freebsd.org Sat May 5 19:20:32 2018 Return-Path: Delivered-To: freebsd-ipfw@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 B7B2DFB7450 for ; Sat, 5 May 2018 19:20:32 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 417036F0AD for ; Sat, 5 May 2018 19:20:32 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: by mail-qk0-x235.google.com with SMTP id d125so19141245qkb.8 for ; Sat, 05 May 2018 12:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tenebras-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=guzohACE3kuvDUwA8D2fbYCBhbQj9K0WMKUDe2FSiDM=; b=D1HIdEBiMLqs17jAYz3GU/ddci/tY0ppkg3uIb76Q8hKb07x+a04zhJUZnPUVJKQVv 9OP3dCTLforf7WlxivJrApjQK5wR9CLCXxAwQ+4kax0bJ51SpoaWWPT1CkLtE8HMLETO Kr+U/YMpyLE+jdyUL2S4CO7Tdg8H3KJ4eBc68Ivnvw0Lk2V6d6Rip9NxqXSoxrmA5+nl L9goBbBrmdLa2OTYnuL+yKH/rhaLa0ndE7eCCnQZUDnhz1x0Y0GSX2TtKC0GC8fOsBfX uqFCdK8dXUSIhrW/Maiz+vDBC/DmGverWRXHT+MvJICkvp/xc/Z5KizjpPGcUfbAVKpF lJKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=guzohACE3kuvDUwA8D2fbYCBhbQj9K0WMKUDe2FSiDM=; b=eIiwYcYxHOfhk04aiX8po8bKVtCDV345Al/Q/HQBqi2A9caZX8QAUdA7jr2zmYYvEL y7UYYqajqdscrWxrldvN3GLOqXyZdRihO5uTrt73J1IYTLM7WwS36Fn1L1U2SkRcp2e9 oNKyuUq8xCY++y4nLjRd9sXn2mlAYd3CxR+wfqVVoCZayG21rC9Wp3KdkPJzPSqHmX6y DxoXm9D6VSciIYQ+drsxfC3jYXyfykPpKPlL4GvT4Sgi/rnY/7o+gT4PDjYTpaz9LP96 RsQbcQCfCEyaaRhTEYYHK8yxH2KVEjxS0XTtlX4GJfvPJYNvK2cQ1mL889XCh0JSrbqv PPsg== X-Gm-Message-State: ALQs6tBxensjKwIbVsw91zdwSRVKHX9lATiYrBW7WaYrAoLRKu+149dI la+uYvF9EE3bsC4dRmGow4MEHkVxRLBvkZF1r3BhtMyD3xg= X-Google-Smtp-Source: AB8JxZrQ7SFl9NhQqmB/1zES3RlEgA8LG8EoR4jclw4b7XeWYluag6Pt4yDrCPkGPSsySya5aqPvWWj/bKKW/T7wZ30= X-Received: by 10.55.151.4 with SMTP id z4mr26229931qkd.138.1525548031321; Sat, 05 May 2018 12:20:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.41.92 with HTTP; Sat, 5 May 2018 12:20:30 -0700 (PDT) In-Reply-To: <9d710171-22ff-7df9-a803-eca8469ad61f@freebsd.org> References: <201805011503.w41F3PxP026423@pdx.rh.CN85.dnsmgr.net> <81ced915-4dae-26c0-bc43-5ff5299d00d0@freebsd.org> <30b5e916-60ef-c3fa-1f80-5858d0d6717c@freebsd.org> <11885361525386183@web50g.yandex.ru> <9d710171-22ff-7df9-a803-eca8469ad61f@freebsd.org> From: Michael Sierchio Date: Sat, 5 May 2018 12:20:30 -0700 Message-ID: Subject: Re: removing some error states To: "freebsd-ipfw@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2018 19:20:32 -0000 Hi, Julian - On Sat, May 5, 2018 at 11:03 AM, Julian Elischer wrote: >... > it was never "ignore errors" It's "ignore a certain class of error". > > table 3 add 1.1.1.1 >>> table 3 add 1.1.1.1 <- no error.. this is what I want.. >>> >> I'm wondering if it shouldn't be atomically idempotent, or... On a public-facing machine, I throttle all traffic until I get a successful auth event, and then add an IP to a table containing a whitelist, which bypasses the restrictive pipes. With a time_t value denoting when it was added. It would be nice if it simply replaced the arg value table 3 add 1.1.1.1 1525547787 and sometime later table 3 add 1.1.1.1 1525576587 which I'd like to succeed. With 11.0+ I can do this atomically with two tables and swap them, but... > table 3 swap 21 <-- doesn't quit, but doesn't generate a new >> >> +1 on this. Again, UPSERT semantics instead of DELETE-then-CREATE, or CREATE. - M