From owner-freebsd-ipfw@freebsd.org Sun Jun 12 03:59:39 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D846EAF02FD for ; Sun, 12 Jun 2016 03:59:39 +0000 (UTC) (envelope-from creamain@drive9030.123servers.com) 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 C12AB2FCC for ; Sun, 12 Jun 2016 03:59:39 +0000 (UTC) (envelope-from creamain@drive9030.123servers.com) Received: by mailman.ysv.freebsd.org (Postfix) id C0733AF02FC; Sun, 12 Jun 2016 03:59:39 +0000 (UTC) Delivered-To: ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0134AF02FB for ; Sun, 12 Jun 2016 03:59:39 +0000 (UTC) (envelope-from creamain@drive9030.123servers.com) Received: from drive9030.123servers.com (drive9030.123servers.com [64.118.86.5]) (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 996182FCB for ; Sun, 12 Jun 2016 03:59:39 +0000 (UTC) (envelope-from creamain@drive9030.123servers.com) Received: from creamain by drive9030.123servers.com with local (Exim 4.87) (envelope-from ) id 1bBwGp-0002BQ-2A for ipfw@freebsd.org; Sat, 11 Jun 2016 23:41:07 -0400 To: ipfw@freebsd.org Subject: Courier was unable to deliver the parcel, ID000520770 X-PHP-Script: jwnorthsidegrill.com/post.php for 184.168.152.222 Date: Sun, 12 Jun 2016 03:41:07 +0000 From: "FedEx 2Day" Reply-To: "FedEx 2Day" Message-ID: <53e26f9f72eed0ce3186a0866c0031ec@jwnorthsidegrill.com> X-Priority: 3 MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - drive9030.123servers.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [704 501] / [47 12] X-AntiAbuse: Sender Address Domain - drive9030.123servers.com X-Get-Message-Sender-Via: drive9030.123servers.com: authenticated_id: creamain/from_h X-Authenticated-Sender: drive9030.123servers.com: tom.lindsay@jwnorthsidegrill.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2016 03:59:39 -0000 Dear Customer, Your parcel has arrived at June 11. Courier was unable to deliver the parcel to you. Please, open email attachment to print shipment label. Yours sincerely, Tom Lindsay, Sr. Support Manager. From owner-freebsd-ipfw@freebsd.org Mon Jun 13 14:54:14 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20976AF1FDC for ; Mon, 13 Jun 2016 14:54:14 +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 EA5772036; Mon, 13 Jun 2016 14:54:13 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-242-176.lns20.per4.internode.on.net [121.45.242.176]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u5DEs7Wt055423 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 13 Jun 2016 07:54:10 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: "Andrey V. Elsukov" , wishmaster , freebsd-ipfw@freebsd.org References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <1465278589.404683707.3wv9pnhq@frv34.fwdcdn.com> <57567F14.1040201@FreeBSD.org> From: Julian Elischer Message-ID: Date: Mon, 13 Jun 2016 22:54:01 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <57567F14.1040201@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 14:54:14 -0000 On 7/06/2016 4:00 PM, Andrey V. Elsukov wrote: > On 07.06.16 09:31, wishmaster wrote: >>> With the following patch you will be able create two different states, I >>> think, and solve your task with NAT and dynamic rules: >>> https://reviews.freebsd.org/D6674 >> Will there be the patch in the 11-RELEASE? > Hi, > > there are three patches for ipfw, that I want to commit: > https://reviews.freebsd.org/D6420 > https://reviews.freebsd.org/D6434 > https://reviews.freebsd.org/D6674 > > But we are in code slush and there aren't any positive review yet. So, I > guess they will be committed only after 11.0 would be branched. > 6674 would be good to have.. I;ve given it a +1 The feature I want from Lev's change is the ability to store a state entry without the implicit check-state. From owner-freebsd-ipfw@freebsd.org Mon Jun 13 14:59:33 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A1B8AF1110 for ; Mon, 13 Jun 2016 14:59:33 +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 49B60212B; Mon, 13 Jun 2016 14:59:32 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-242-176.lns20.per4.internode.on.net [121.45.242.176]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u5DExOd5055447 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 13 Jun 2016 07:59:27 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: Ian Smith , "Andrey V. Elsukov" References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <20160607220136.R15883@sola.nimnet.asn.au> Cc: lev@freebsd.org, freebsd-ipfw@freebsd.org, "Alexander V. Chernikov" From: Julian Elischer Message-ID: <8fd8d2f7-72f9-4a0f-5123-d080450d3261@freebsd.org> Date: Mon, 13 Jun 2016 22:59:19 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160607220136.R15883@sola.nimnet.asn.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 14:59:33 -0000 On 7/06/2016 10:31 PM, Ian Smith wrote: > On Tue, 7 Jun 2016 00:53:23 +0300, Andrey V. Elsukov wrote: > > On 06.06.16 22:41, Lev Serebryakov wrote: > > > > > > I still hope to see https://reviews.freebsd.org/D1776 committed before > > > 11-RELEASE. > > > > > > It seems to me, that I does everything what was requested by reviewers. > > > > Hi Lev, > > > > looking at provided description and examples, seems the main task you > > want to solve is problem with NAT. But from my point of view, you are > > trying to solve it in a easy way wrongly using existing methods. > > > > As you described in patch to ipfw(8) "Problem is, you need to create > > dynamic rule before NAT and check it after NAT actions (or vice versa) > > to have consistent addresses and ports." > > > > In terms of ipfw(4) a state is represented by ipfw_flow_id structure. > > To solve your task you just needs two states - one for not translated > > flow and second - for translated. Due to limits of implementation this > > looks impossible to solve. But proposed patch with deferred action looks > > too hackish to me. > > > > With the following patch you will be able create two different states, I > > think, and solve your task with NAT and dynamic rules: > > https://reviews.freebsd.org/D6674 > > If your patch does what Lev wanted to achieve with (I thought too many) > new dynamic rule actions, then I think your simpler solution is better, > not least because it's far easier to understand for non-Julians :) actually I want only subset.. what I want is a "set-state" that is the same as keep-state, but does not have the implicit check-state before it. (if it has a collision with an existing rule it overrides it) I also want he named state tables. :-) > > Looking from a useability and documentation perspective only - I won't > even be looking at this code - I have a few thoughts: > > Thus far, keep-state and limit seem to be interchangeable options; limit > rules will need to work the same with respect to named dynamic flows; do > I assume that you've just started with only keep-state for testing? > > I think flow names should be specified as an _optional_ parameter, thus: > > check-state [name] > > keep-state [name] > > limit {src-addr | src-port | dst-addr | dst-port} N [name] > > where name (maybe flowname, for easier comprehension by man readers?) is > optional, assigned as 'default' whenever omitted - as well as being for > backwards ruleset compatibility, which then only needs mentioning once, > and maybe also put another way in the STATEFUL FIREWALL section. I think flowname is a bad name.. it's a state table name. > > So a few of the existing example rules with no name could stand, while > others (see below) append names of OUTBOUND and INBOUND or whatever. > > As is, you have > > 740 .It Cm check-state Op Ar name | Cm any | Cm default > > which in other contexts would mean you have to supply one of 'name' or > 'any' or 'default' when you don't have to provide one, 'default' being > assigned otherwise. Otherwise I think this is fairly well described. > > Will 'ipfw -[e]d list|show' show the flow names? or the indices? > > As I pestered Lev about last year, we still need a small example ruleset > section that actually deals with potentially problematic stateful issues > with NAT - which I still don't fully understand - beyond descriptions in > the abstract case; ie an actual working dual- or multi-flow example. > > I know these are "just doc" issues of little importance while testing > working code, and I haven't supplied any patches, so are just FWIW .. > > cheers, Ian > From owner-freebsd-ipfw@freebsd.org Mon Jun 13 15:19:36 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E5EDAF175A for ; Mon, 13 Jun 2016 15:19:36 +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 7FAFE2CFB; Mon, 13 Jun 2016 15:19:36 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-242-176.lns20.per4.internode.on.net [121.45.242.176]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u5DFJUjx055512 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 13 Jun 2016 08:19:33 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: lev@FreeBSD.org, "Andrey V. Elsukov" , freebsd-ipfw@freebsd.org References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> Cc: "Alexander V. Chernikov" From: Julian Elischer Message-ID: <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> Date: Mon, 13 Jun 2016 23:19:24 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <5759DB79.10205@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 15:19:36 -0000 On 10/06/2016 5:11 AM, Lev Serebryakov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 07.06.2016 00:53, Andrey V. Elsukov wrote: > >> looking at provided description and examples, seems the main task >> you want to solve is problem with NAT. But from my point of view, >> you are trying to solve it in a easy way wrongly using existing >> methods. > It is was initial driver for this patch, yes, but, please, read > subject (? is mistype, of course, it is closing "). > > Current set of primitives, dealing with state, is terribly wrong, > IMHO. "keep-state" which trigger (any!) state check alone is awuful, > and complete "keep-state / check-state" pair is ugly hack. It is like > CISC vs RISC, actually. > > New primitives are ORTHOGONAL. Each one solves one and only one > well-defined task, state creation, state checking and command > execution are well-separated. IMHO, "keep-state" in it current form > should be killed with fire. Yes, I understand about backward > compatibility and POLA, so I don't propose to really remove it, but, > IMHO, new set is much, much better. In writing complicated automatically generated firewalls, I've wanted the following capacities: 1/ one state table for one part of the flow and another for a different part... e.g. a different table for "inside" nat to "outside" nat.. also a different table for the inside interface to the outside interface.. just because you allow a flow at one interface doesn't mean you want it to be allowed through a different one. 2/ The ability to specifically add a flow's state rule to a table, without EVERY OTHER FLOW hitting a 'check-state' at that point. If I select s particular flow , then I do not want other flows affected. just that flow should be affected. 3/ the ability to select a completley different firewall for a differnent interface.. this can be simulated at the moment. but it'd be nice to be able to specify a entry pont into the table or a separate table per interface.. ipfw interface xn0 in enter 5000 or something. or maybe ipfw interface firewall 3 4/ the ability to have variables and set and test them. We ALMOST have that with tags . i] variables would hav eone of several scopes: a) a single transit.. you might set some flag at rule 40 and branch on it at rule 4000, but a separate packet would ahv ea different instance. b) per flow.. assigned at creation of the dynamic rule and avaliable at any time after a packet has been associated with that flow. c) global ii] branching on values is possible. there are others I've wanted (and forgotten) but that's the wish-list I have at the moment. >> As you described in patch to ipfw(8) "Problem is, you need to >> create dynamic rule before NAT and check it after NAT actions (or >> vice versa) to have consistent addresses and ports." > It is only very rudimentary example to show the point of new > primitives. All meaningful examples require big and complex rulesets, > really. > >> In terms of ipfw(4) a state is represented by ipfw_flow_id >> structure. To solve your task you just needs two states - one for >> not translated flow and second - for translated. > For what?! Logically it is one flow. NAT is kludge itself, of > course, but, IMHO, logically it doesn't create new flow, or > connection, whatever your name it. It hacks existing one. > >> Due to limits of implementation this looks impossible to solve. But >> proposed patch with deferred action looks too hackish to me. > IMHO, it untangles current very sad situation. > >> With the following patch you will be able create two different >> states, I think, and solve your task with NAT and dynamic rules: >> https://reviews.freebsd.org/D6674 > Named states are great and very useful by themselves, but how this > solve problem, that "keep-state" implies "check-state" rule, for example > ? > > I seen a thousand posts, messages and how-tos about stateful IPFW and > all of them suffer from this "keep-state is check-state" problem, > really, when you try to structure your firewall in "ingress / egress" > per-interface sections and not one small ruleset for one interface. > > - -- > // Lev Serebryakov AKA Black Lion > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > > iQJ8BAEBCgBmBQJXWdt4XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF > QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePQ+kP/jTUZQ/W2srUhiRCkTzDsGpy > dbODp6utMjQGwtZKgPRVN4+0KuchgJInA6odB/34WKfgW5THpevLkh5do8QGvm+5 > /8DcYZOYwCk45TRkjhctBH6u2t0v3TPvjd1pPkknmhd3qE9Zzkk2fi+0iUWBavMH > LvLJ+afUlmw8l95Om8g4Per3C7TEWmxXews3k+vg1xgrTtPn6m1Vcwspp7gHe2Zo > OIGTzDl0S95SUofQuQX3vD7gPqm6YTnRVhtHrb36saVpP2HCv6e+7vOkyfiTV4nd > Mchu3T6e9zJ2cmWBRIE9d/wB18LRVjWE+pvosTf6EEIkRJnUUnCZF19EJj8BS+9X > 7+zbPnVeUSo17YdxSTcDXL0cBuzRIsz50V2Q6bFgl313PB9u97a4FeLdNmqEZfnN > jEgeonc8loN6Fw/Mgjdn2wjmAhZaWU+zCpozzDPcjevkl9NIVVkMys4iZUUCdRkG > yGQtU18X3hHwrbM4uJs7K9JLJj1HHEgpT9mnZ3qxCQ1YKEWZ0plgPvXoFWOiYYIB > Ecz19D/kLBad3gVZ0X9NZwqA2XM23UmfMiKqd0ZcoOPiMY1WY35PQWOocOhiCIW4 > mhcEwp9ZR2mV7OZEO1ObLiK1Jo/q0xNn2eV9UgSrYJGSjOSLPj+9rC2zOjBbO1EO > o1H+cNxLn5zMM4sybo9X > =WZgr > -----END PGP SIGNATURE----- > From owner-freebsd-ipfw@freebsd.org Wed Jun 15 15:03:34 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99363A44FAC for ; Wed, 15 Jun 2016 15:03:34 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (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 11D4617C1; Wed, 15 Jun 2016 15:03:32 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id u5FEnZOw004724; Thu, 16 Jun 2016 00:49:35 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 16 Jun 2016 00:49:35 +1000 (EST) From: Ian Smith To: Julian Elischer cc: "Andrey V. Elsukov" , lev@freebsd.org, freebsd-ipfw@freebsd.org, "Alexander V. Chernikov" Subject: Re: IPFW: more "orthogonal? state operations, push into 11? In-Reply-To: <8fd8d2f7-72f9-4a0f-5123-d080450d3261@freebsd.org> Message-ID: <20160616003432.A15883@sola.nimnet.asn.au> References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <20160607220136.R15883@sola.nimnet.asn.au> <8fd8d2f7-72f9-4a0f-5123-d080450d3261@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 15:03:34 -0000 On Mon, 13 Jun 2016 22:59:19 +0800, Julian Elischer wrote: > On 7/06/2016 10:31 PM, Ian Smith wrote: > > On Tue, 7 Jun 2016 00:53:23 +0300, Andrey V. Elsukov wrote: > > > On 06.06.16 22:41, Lev Serebryakov wrote: > > > > > > > > I still hope to see https://reviews.freebsd.org/D1776 committed > > before > > > > 11-RELEASE. > > > > > > > > It seems to me, that I does everything what was requested by > > reviewers. > > > > > > Hi Lev, > > > > > > looking at provided description and examples, seems the main task you > > > want to solve is problem with NAT. But from my point of view, you are > > > trying to solve it in a easy way wrongly using existing methods. > > > > > > As you described in patch to ipfw(8) "Problem is, you need to create > > > dynamic rule before NAT and check it after NAT actions (or vice versa) > > > to have consistent addresses and ports." > > > > > > In terms of ipfw(4) a state is represented by ipfw_flow_id structure. > > > To solve your task you just needs two states - one for not translated > > > flow and second - for translated. Due to limits of implementation this > > > looks impossible to solve. But proposed patch with deferred action > > looks > > > too hackish to me. > > > > > > With the following patch you will be able create two different states, > > I > > > think, and solve your task with NAT and dynamic rules: > > > https://reviews.freebsd.org/D6674 > > > > If your patch does what Lev wanted to achieve with (I thought too many) > > new dynamic rule actions, then I think your simpler solution is better, > > not least because it's far easier to understand for non-Julians :) > > actually I want only subset.. > what I want is a "set-state" that is the same as keep-state, but does not > have > the implicit check-state before it. (if it has a collision with an existing > rule it overrides it) > I also want he named state tables. :-) Ok, but you're regularly referring to multiple state _tables_, but I think that what is proposed is one table with name added to protocol, addresses and ports as a parameter rather than as distinct tables? Is that right, Andrey? As I said, I'm not looking at the code now. > > Looking from a useability and documentation perspective only - I won't > > even be looking at this code - I have a few thoughts: > > > > Thus far, keep-state and limit seem to be interchangeable options; limit > > rules will need to work the same with respect to named dynamic flows; do > > I assume that you've just started with only keep-state for testing? > > > > I think flow names should be specified as an _optional_ parameter, thus: > > > > check-state [name] > > > > keep-state [name] > > > > limit {src-addr | src-port | dst-addr | dst-port} N [name] > > > > where name (maybe flowname, for easier comprehension by man readers?) is > > optional, assigned as 'default' whenever omitted - as well as being for > > backwards ruleset compatibility, which then only needs mentioning once, > > and maybe also put another way in the STATEFUL FIREWALL section. > I think flowname is a bad name.. it's a state table name. I don't think so. That was just a suggestion in place of generic 'name' but the more I read your following message, which I'll respond to next, the more I think you've made a good case for 'flowname', which Andrey has used in latest review in ipfw(8). Onwards .. cheers, Ian From owner-freebsd-ipfw@freebsd.org Wed Jun 15 16:11:09 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B84B2A4553B for ; Wed, 15 Jun 2016 16:11:09 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (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 085B21289; Wed, 15 Jun 2016 16:11:08 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id u5FGB4BV007577; Thu, 16 Jun 2016 02:11:05 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 16 Jun 2016 02:11:04 +1000 (EST) From: Ian Smith To: Julian Elischer cc: lev@freebsd.org, "Andrey V. Elsukov" , freebsd-ipfw@freebsd.org, "Alexander V. Chernikov" Subject: Re: IPFW: more "orthogonal? state operations, push into 11? In-Reply-To: <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> Message-ID: <20160616005016.A15883@sola.nimnet.asn.au> References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 16:11:09 -0000 On Mon, 13 Jun 2016 23:18:24 +0800, Julian Elischer wrote: > On 10/06/2016 5:11 AM, Lev Serebryakov wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > On 07.06.2016 00:53, Andrey V. Elsukov wrote: > > > > > looking at provided description and examples, seems the main task > > > you want to solve is problem with NAT. But from my point of view, > > > you are trying to solve it in a easy way wrongly using existing > > > methods. > > It is was initial driver for this patch, yes, but, please, read > > subject (? is mistype, of course, it is closing "). > > > > Current set of primitives, dealing with state, is terribly wrong, > > IMHO. "keep-state" which trigger (any!) state check alone is awuful, > > and complete "keep-state / check-state" pair is ugly hack. It is like > > CISC vs RISC, actually. > > > > New primitives are ORTHOGONAL. Each one solves one and only one > > well-defined task, state creation, state checking and command > > execution are well-separated. IMHO, "keep-state" in it current form > > should be killed with fire. Yes, I understand about backward > > compatibility and POLA, so I don't propose to really remove it, but, > > IMHO, new set is much, much better. Lev, is there any chance you and Andrey can work together here? At the moment we seem to have two 'competing' models. Can they be melded at all? Or can you live with adding new opcodes on top of Andrey's named states? (Feel free to tell me that this is none of my business ..) > In writing complicated automatically generated firewalls, > I've wanted the following capacities: > 1/ one state table for one part of the flow and another for a different > part... e.g. a different table for "inside" nat to "outside" nat.. Isn't one table with distinct flow-or-whatever names for matching not sufficient for this purpose? Wouldn't that also be faster than having to consult multiple distinct tables? In the end those are details the user doesn't need to know about .. but ze does need to comprehend the terms conveying the ideas. > also a different table for the inside interface to the outside interface.. > just because you allow a flow at one interface doesn't mean you want it to be > allowed through a different one. Sure, so couldn't you have, say, 'inbound_outside', 'inbound_inside', 'outbound_outside' and 'outbound_inside', 'from_dmz' or whatever to distinguish multiple flows? Why doesn't 'flowname' sound right to describe what you call 'flows'? > 2/ The ability to specifically add a flow's state rule to a table, without > EVERY OTHER FLOW hitting a 'check-state' at that point. If I select s > particular flow , then I do not want other flows affected. just that flow > should be affected. Isn't that the case with Andrey's code at the moment, if you specify a name on that keep-state rule, only that - erm - flow would be checked and not other flows (including 'default' where added by unnamed rules)? Can I assume that if this is the first keep-state|limit for one flowname then an implicit check-state would check that flow only, finding none? Similarly, if I'm grokking this at all right, then only a check-state (or another keep-state or limit encountered) with that same name will match existing states having that same name? Issue 2/ solved or not? I hope you can see my concern that this be easily described in ipfw(8) so people without high level of expertise can easily see how it works. I'll have some more suggestions re description along the way, but after seeing clear agreement that the proposed model/s cover the usage cases described (somewhat), and where not, what more needs doing to make it acceptable as a next step, if not entirely ideal for every case .. To that end, I'll leave wishes 3/ and 4/ well alone .. as usual, FWIW cheers, Ian > 3/ the ability to select a completley different firewall for a differnent > interface.. this can be simulated at the moment. but it'd be nice to be able > to specify a entry pont into the table or a separate table per interface.. > ipfw interface xn0 in enter 5000 or something. > or maybe ipfw interface firewall 3 > 4/ the ability to have variables and set and test them. We ALMOST have that > with tags . > i] variables would hav eone of several scopes: > a) a single transit.. you might set some flag at rule 40 and branch on it > at rule 4000, but a separate packet would ahv ea different instance. > b) per flow.. assigned at creation of the dynamic rule and avaliable at > any time after a packet has been associated with that flow. > c) global > ii] branching on values is possible. > there are others I've wanted (and forgotten) but that's the wish-list I have > at the moment. From owner-freebsd-ipfw@freebsd.org Wed Jun 15 17:05:00 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B74D4A47260 for ; Wed, 15 Jun 2016 17:05:00 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.freebsd.org", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9FA7B1182; Wed, 15 Jun 2016 17:05:00 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from butcher-nb.yandex.net (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id B5657651BC; Wed, 15 Jun 2016 17:04:58 +0000 (UTC) (envelope-from ae@FreeBSD.org) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: Ian Smith , Julian Elischer References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <20160607220136.R15883@sola.nimnet.asn.au> <8fd8d2f7-72f9-4a0f-5123-d080450d3261@freebsd.org> <20160616003432.A15883@sola.nimnet.asn.au> Cc: lev@freebsd.org, "Alexander V. Chernikov" , freebsd-ipfw@freebsd.org From: "Andrey V. Elsukov" Message-ID: <57618AA3.7050304@FreeBSD.org> Date: Wed, 15 Jun 2016 20:04:35 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <20160616003432.A15883@sola.nimnet.asn.au> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="T7QcehiCI8A4lwdrljVMo8pStMFdOhoRp" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 17:05:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --T7QcehiCI8A4lwdrljVMo8pStMFdOhoRp Content-Type: multipart/mixed; boundary="LIlATXNbdtA1pPIDCTiI0RFJ3UwfH7RmU" From: "Andrey V. Elsukov" To: Ian Smith , Julian Elischer Cc: lev@freebsd.org, "Alexander V. Chernikov" , freebsd-ipfw@freebsd.org Message-ID: <57618AA3.7050304@FreeBSD.org> Subject: Re: IPFW: more "orthogonal? state operations, push into 11? References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <20160607220136.R15883@sola.nimnet.asn.au> <8fd8d2f7-72f9-4a0f-5123-d080450d3261@freebsd.org> <20160616003432.A15883@sola.nimnet.asn.au> In-Reply-To: <20160616003432.A15883@sola.nimnet.asn.au> --LIlATXNbdtA1pPIDCTiI0RFJ3UwfH7RmU Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 15.06.16 17:49, Ian Smith wrote: > Ok, but you're regularly referring to multiple state _tables_, but I=20 > think that what is proposed is one table with name added to protocol,=20 > addresses and ports as a parameter rather than as distinct tables? >=20 > Is that right, Andrey? As I said, I'm not looking at the code now. Internally it is implemented as one unsigned integer in addition to addresses and ports in flow structure. So, in general, there is still one hash table. > > I think flowname is a bad name.. it's a state table name. >=20 > I don't think so. That was just a suggestion in place of generic 'name= '=20 > but the more I read your following message, which I'll respond to next,= =20 > the more I think you've made a good case for 'flowname', which Andrey=20 > has used in latest review in ipfw(8). Onwards .. I updated the patch in https://reviews.freebsd.org/D6674 Also I reworked Lev's patch on top of my patch and made it simpler: https://reviews.freebsd.org/D1776#143557 --=20 WBR, Andrey V. Elsukov --LIlATXNbdtA1pPIDCTiI0RFJ3UwfH7RmU-- --T7QcehiCI8A4lwdrljVMo8pStMFdOhoRp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXYYqkAAoJEAHF6gQQyKF6rLgH/3NV2BtsJ39m2o7Qv0789iWE lFfQ/mV6zG8TgmO1YHtfDRusvd0MnoWWnkcUrkWUgEuSX/H44G+ND1QIHzUUfEyE dMA2JWd2Qhwl1QUBkEFV/pQaY0g6ETKbpU5cL7F2eqdja38pMlkZtWtY7E0TlSNO JAjcrNgSbW7k+yq6pI2BLZVgtdYNhK2X8cUQRln4Rkm/uvtKKuMHzOokUK1LYDOh mJmCajHuy2FOzAyHP6NE6/qBegsyvjbN6AwM3KDIwBT4cYVgwqthjZU71WfaanTo pYjRKgxlwj98rCWvJp73dK616sxDwSvoEQYclIMf+XbX1FyFSrpzkVG5qmy5go0= =prv7 -----END PGP SIGNATURE----- --T7QcehiCI8A4lwdrljVMo8pStMFdOhoRp-- From owner-freebsd-ipfw@freebsd.org Fri Jun 17 01:00:30 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33118A4458B; Fri, 17 Jun 2016 01:00:30 +0000 (UTC) (envelope-from feld@feld.me) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (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 E11BF2445; Fri, 17 Jun 2016 01:00:29 +0000 (UTC) (envelope-from feld@feld.me) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 1ABE220A4F; Thu, 16 Jun 2016 21:00:28 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute5.internal (MEProxy); Thu, 16 Jun 2016 21:00:28 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=feld.me; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=8BJ brNnv+eDvY1huFFmHPLOXWP4=; b=Ddnh6F68lFrPSQux4tGwoL8k2QmW+J/Av1F ixyXsJwUcl15xg6f4+hj/NfJSRq6ZqnogLr1uWJ2Lz1MNRWDM5HW/0dgsqzYLBJN tYouDNE1qBcvGtt5UN9zQARsTHPYF1N1e3+/NGqtrYZVFkpLDeZnNpuPI24m6mxt DVLQlpDg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=8BJbrNnv+eDvY1huFFmHPLOXWP4=; b=m7PpT okzXEjCrqwBLYb8kmF5Gp414/pvGxKj4CNgxBE8prqMhg2PTAb9Yl2SMGTmq0zrz /Bxh09ICCoqQTTya+VY1xrU4+DlNqMXQ9+Q3elgGE3TN4jV73nQ35jk2c5FRvDoO ZtwDZgDqjDzonesm46PM2vwQMe2ObX6dlz/CYw= Received: by mailuser.nyi.internal (Postfix, from userid 99) id C9A0516624; Thu, 16 Jun 2016 21:00:27 -0400 (EDT) Message-Id: <1466125227.1166810.640210225.0811C28B@webmail.messagingengine.com> X-Sasl-Enc: OTMgourNjeipaDaUTLymDeI6BbGva6vwgaDJiBkLRbIE 1466125227 From: Mark Felder To: freebsd-hackers@freebsd.org, freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-127413e6 Subject: ALPHA3 panic with ipfw+dummynet and gif/gre tunnels Date: Thu, 16 Jun 2016 20:00:27 -0500 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 01:00:30 -0000 Hello, I can pretty reliably panic CURRENT by creating/destroying gif and gre interfaces used for IPv6 tunnels. I'm uploading the dump, kernel.debug, and kernel in a tarball here: https://feld.me/freebsd/crash/r301929.tgz It's still uploading so you might end up with an incomplete download if you fetch it now. Here's the sha256 of it: 1e9fddad1da3bac2b11c51a18c7dad48eb9259acf844f35f5eb40630ca84de64 r301929.tgz Here's the backtrace: (kgdb) bt #0 doadump (textdump=0) at pcpu.h:221 #1 0xffffffff80391fab in db_dump (dummy=, dummy2=false, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:533 #2 0xffffffff80391da9 in db_command (cmd_table=) at /usr/src/sys/ddb/db_command.c:440 #3 0xffffffff80391b04 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493 #4 0xffffffff80394a3b in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:251 #5 0xffffffff80a88913 in kdb_trap (type=, code=, tf=) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xffffffff80eb8331 in trap_fatal (frame=0xfffffe0122831770, eva=26) at /usr/src/sys/amd64/amd64/trap.c:836 #7 0xffffffff80eb857d in trap_pfault (frame=0xfffffe0122831770, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:691 #8 0xffffffff80eb7a64 in trap (frame=0xfffffe0122831770) at /usr/src/sys/amd64/amd64/trap.c:442 #9 0xffffffff80e97f91 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236 #10 0xffffffff80c57ebc in ip6_output (m0=, opt=, ro=, flags=, im6o=0x0, ifpp=0x0, inp=) at /usr/src/sys/netinet6/ip6_output.c:1060 #11 0xffffffff82661fd2 in dummynet_send (m=) at /usr/src/sys/modules/dummynet/../../netpfil/ipfw/ip_dn_io.c:800 #12 0xffffffff82661890 in dummynet_task (context=, pending=) at /usr/src/sys/modules/dummynet/../../netpfil/ipfw/ip_dn_io.c:746 #13 0xffffffff80a9a1ac in taskqueue_run_locked (queue=) at /usr/src/sys/kern/subr_taskqueue.c:465 #14 0xffffffff80a9acf8 in taskqueue_thread_loop (arg=) at /usr/src/sys/kern/subr_taskqueue.c:719 #15 0xffffffff80a0b3e4 in fork_exit (callout=0xffffffff80a9ac70 , arg=0xffffffff8266c8a8, frame=0xfffffe0122831c00) at /usr/src/sys/kern/kern_fork.c:1038 #16 0xffffffff80e984ce in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:611 #17 0x0000000000000000 in ?? () Current language: auto; currently minimal -- Mark Felder feld@feld.me From owner-freebsd-ipfw@freebsd.org Fri Jun 17 01:03:55 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0334A446F6; Fri, 17 Jun 2016 01:03:55 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (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 7DA8B26A6; Fri, 17 Jun 2016 01:03:55 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3DCE1208C7; Thu, 16 Jun 2016 21:03:54 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Thu, 16 Jun 2016 21:03:54 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=uKDZMREEu58bWm2V7HIay96VcSM=; b=A5LOR Q/+ekZZ6AU7ABnwbBe0xnHBz64fxPD3qrm4kMx6LIQ/SIXAew2KCO7kVwlOfRNV1 RxzTMs2hJoh7gmr2EtmAbo0w7BchIiLjQf+IPqzBU7VrCNstEpQ6uSAZUtCCR7f7 n6weXOToqnIK/yU9Ub3Rz4zNRdgY/Sdzc36AWE= Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0E00F16624; Thu, 16 Jun 2016 21:03:54 -0400 (EDT) Message-Id: <1466125434.1167831.640215001.594DC233@webmail.messagingengine.com> X-Sasl-Enc: b5Y2BeezsPJxaJcmiwR4+8RS6AbPCVvtAfxmkWlLZqP0 1466125434 From: Mark Felder To: freebsd-current@freebsd.org, freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-127413e6 Subject: ALPHA3 panic with ipfw+dummynet and gif/gre tunnels Date: Thu, 16 Jun 2016 20:03:54 -0500 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 01:03:55 -0000 Hello, I can pretty reliably panic CURRENT by creating/destroying gif and gre interfaces used for IPv6 tunnels. I'm uploading the dump, kernel.debug, and kernel in a tarball here: https://feld.me/freebsd/crash/r301929.tgz It's still uploading so you might end up with an incomplete download if you fetch it now. Here's the sha256 of it: 1e9fddad1da3bac2b11c51a18c7dad48eb9259acf844f35f5eb40630ca84de64 r301929.tgz Here's the backtrace: (kgdb) bt #0 doadump (textdump=0) at pcpu.h:221 #1 0xffffffff80391fab in db_dump (dummy=, dummy2=false, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:533 #2 0xffffffff80391da9 in db_command (cmd_table=) at /usr/src/sys/ddb/db_command.c:440 #3 0xffffffff80391b04 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493 #4 0xffffffff80394a3b in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:251 #5 0xffffffff80a88913 in kdb_trap (type=, code=, tf=) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xffffffff80eb8331 in trap_fatal (frame=0xfffffe0122831770, eva=26) at /usr/src/sys/amd64/amd64/trap.c:836 #7 0xffffffff80eb857d in trap_pfault (frame=0xfffffe0122831770, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:691 #8 0xffffffff80eb7a64 in trap (frame=0xfffffe0122831770) at /usr/src/sys/amd64/amd64/trap.c:442 #9 0xffffffff80e97f91 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236 #10 0xffffffff80c57ebc in ip6_output (m0=, opt=, ro=, flags=, im6o=0x0, ifpp=0x0, inp=) at /usr/src/sys/netinet6/ip6_output.c:1060 #11 0xffffffff82661fd2 in dummynet_send (m=) at /usr/src/sys/modules/dummynet/../../netpfil/ipfw/ip_dn_io.c:800 #12 0xffffffff82661890 in dummynet_task (context=, pending=) at /usr/src/sys/modules/dummynet/../../netpfil/ipfw/ip_dn_io.c:746 #13 0xffffffff80a9a1ac in taskqueue_run_locked (queue=) at /usr/src/sys/kern/subr_taskqueue.c:465 #14 0xffffffff80a9acf8 in taskqueue_thread_loop (arg=) at /usr/src/sys/kern/subr_taskqueue.c:719 #15 0xffffffff80a0b3e4 in fork_exit (callout=0xffffffff80a9ac70 , arg=0xffffffff8266c8a8, frame=0xfffffe0122831c00) at /usr/src/sys/kern/kern_fork.c:1038 #16 0xffffffff80e984ce in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:611 #17 0x0000000000000000 in ?? () Current language: auto; currently minimal -- Mark Felder ports-secteam member feld@FreeBSD.org From owner-freebsd-ipfw@freebsd.org Fri Jun 17 03:38:43 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F914A77AD1; Fri, 17 Jun 2016 03:38:43 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 15BA422A9; Fri, 17 Jun 2016 03:38:43 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi0-x22a.google.com with SMTP id d132so99634278oig.1; Thu, 16 Jun 2016 20:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=sYahi6RMcQ9W3aXmN9lxdZGbTRKZaeuiQbCUodYIkxY=; b=AUo9u8BYEUljVwc5BWh0uR2oyIDTH5m7TugInorfoWIwAGhptmGRYtClKWWKaPQ64Q WkHjPN29hUSF9cbFvVYkS8t38ULtqeh6ppBK18wGI81C1L7oe1KAeXmtIq6387Txp6Du JG/GIvsIDTYXmXKyHCI4lH2w5rM2u6aAofz2K8HnxvYB0uiDFTjf2QBrJ6IhtB3iKrTy EMe+yBbwG9US2pLC7EbFr46EaQAIFVqajjfebRVZtZTkVfV2qy94K994tLkXx+N2UDxi h/ZUFy6afib5Uz+2090+55dfSfiGnY6nP+9cfxmnLe9n3X6xFv1IwsYdJx54JvirUX2a RmrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=sYahi6RMcQ9W3aXmN9lxdZGbTRKZaeuiQbCUodYIkxY=; b=HOzY9LzFl2P6CiPDICGALsix2qRyKaTj9Co/pYlrr6bCrZCPq3hJJybwxb7Hc7p6uM 3G2Gd3YCVS2qKbsn7NaJXJqGSliJCuFMd1Kt/BHe+iU/8QoW6T45Si4KSzOmhboc0c/J IO6Tb+/GfWnkyz5aDys/ipgPP6Q9RjeC8p0RT7Js9lS5eszdv2fb0A9qrGqKAE3sW9/F hI6fvT4Gosr5TQWMoRwUrCHGL6UHi/PzBxEkOgmMU++LQ2oUT2wm+Gh/G7PSoqPQB7ZK wN1NQfykxNygYDeVI3FVX1moGUpHLnTKoceAulWRSY7LDjaVfJPfy2Oi9ZCFuiOmbSlN 5BUQ== X-Gm-Message-State: ALyK8tIp3eNJPbD9cVnKVfuf9whu7Omd6u08htiHZXYGXUE/1Oyco6ExSj2+K3U0NuK9byjn4y5x02iv5IWjqA== X-Received: by 10.157.29.106 with SMTP id m97mr219753otm.164.1466134722329; Thu, 16 Jun 2016 20:38:42 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.202.102.206 with HTTP; Thu, 16 Jun 2016 20:38:41 -0700 (PDT) In-Reply-To: <1466125434.1167831.640215001.594DC233@webmail.messagingengine.com> References: <1466125434.1167831.640215001.594DC233@webmail.messagingengine.com> From: Alan Somers Date: Thu, 16 Jun 2016 21:38:41 -0600 X-Google-Sender-Auth: VRaAhEzuPlc0JWy3xt__7hiYO4w Message-ID: Subject: Re: ALPHA3 panic with ipfw+dummynet and gif/gre tunnels To: Mark Felder Cc: FreeBSD CURRENT , freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 03:38:43 -0000 On Thu, Jun 16, 2016 at 7:03 PM, Mark Felder wrote: > Hello, > > I can pretty reliably panic CURRENT by creating/destroying gif and gre > interfaces used for IPv6 tunnels. I'm uploading the dump, kernel.debug, > and kernel in a tarball here: > > https://feld.me/freebsd/crash/r301929.tgz > > It's still uploading so you might end up with an incomplete download if > you fetch it now. Here's the sha256 of it: > > 1e9fddad1da3bac2b11c51a18c7dad48eb9259acf844f35f5eb40630ca84de64 > r301929.tgz > > > Here's the backtrace: > > (kgdb) bt > #0 doadump (textdump=0) at pcpu.h:221 > #1 0xffffffff80391fab in db_dump (dummy=, > dummy2=false, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:533 > #2 0xffffffff80391da9 in db_command (cmd_table=) > at /usr/src/sys/ddb/db_command.c:440 > #3 0xffffffff80391b04 in db_command_loop () at > /usr/src/sys/ddb/db_command.c:493 > #4 0xffffffff80394a3b in db_trap (type=, > code=) at /usr/src/sys/ddb/db_main.c:251 > #5 0xffffffff80a88913 in kdb_trap (type=, > code=, tf=) at > /usr/src/sys/kern/subr_kdb.c:654 > #6 0xffffffff80eb8331 in trap_fatal (frame=0xfffffe0122831770, eva=26) > at /usr/src/sys/amd64/amd64/trap.c:836 > #7 0xffffffff80eb857d in trap_pfault (frame=0xfffffe0122831770, > usermode=0) at /usr/src/sys/amd64/amd64/trap.c:691 > #8 0xffffffff80eb7a64 in trap (frame=0xfffffe0122831770) at > /usr/src/sys/amd64/amd64/trap.c:442 > #9 0xffffffff80e97f91 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:236 > #10 0xffffffff80c57ebc in ip6_output (m0=, > opt=, ro=, flags= optimized out>, im6o=0x0, ifpp=0x0, inp=) > at /usr/src/sys/netinet6/ip6_output.c:1060 > #11 0xffffffff82661fd2 in dummynet_send (m=) at > /usr/src/sys/modules/dummynet/../../netpfil/ipfw/ip_dn_io.c:800 > #12 0xffffffff82661890 in dummynet_task (context=, > pending=) at > /usr/src/sys/modules/dummynet/../../netpfil/ipfw/ip_dn_io.c:746 > #13 0xffffffff80a9a1ac in taskqueue_run_locked (queue= out>) at /usr/src/sys/kern/subr_taskqueue.c:465 > #14 0xffffffff80a9acf8 in taskqueue_thread_loop (arg= out>) at /usr/src/sys/kern/subr_taskqueue.c:719 > #15 0xffffffff80a0b3e4 in fork_exit (callout=0xffffffff80a9ac70 > , arg=0xffffffff8266c8a8, > frame=0xfffffe0122831c00) at /usr/src/sys/kern/kern_fork.c:1038 > #16 0xffffffff80e984ce in fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:611 > #17 0x0000000000000000 in ?? () > Current language: auto; currently minimal > > > -- > Mark Felder > ports-secteam member > feld@FreeBSD.org > _______________________________________________ Yeah, FreeBSD has a problem with destroying any kind of cloned interface. How many times, on average, do you need to destroy one before you get the panic? From owner-freebsd-ipfw@freebsd.org Fri Jun 17 08:34:42 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF950A785C6; Fri, 17 Jun 2016 08:34:42 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward5j.cmail.yandex.net (forward5j.cmail.yandex.net [IPv6:2a02:6b8:0:1630::18]) (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 5E612225A; Fri, 17 Jun 2016 08:34:42 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp11.mail.yandex.net (smtp11.mail.yandex.net [IPv6:2a02:6b8:0:801:1::10]) by forward5j.cmail.yandex.net (Yandex) with ESMTP id D442E20EE6; Fri, 17 Jun 2016 11:34:06 +0300 (MSK) Received: from smtp11.mail.yandex.net (localhost [127.0.0.1]) by smtp11.mail.yandex.net (Yandex) with ESMTP id 68B757E0F10; Fri, 17 Jun 2016 11:34:06 +0300 (MSK) Received: by smtp11.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id VkAlsBWwGw-Y5iOa56f; Fri, 17 Jun 2016 11:34:05 +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=1466152445; bh=w+e1x2+biC5FB5q2or9245Ac8jC9G7LNk4nWkeYt2RY=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type; b=Jvfc6dSJkwsw77F/IB3QYiRo/fwemH44kj1FJIDyqVJWpKDwJSHGXv9kULJCWw2DA eeLv1lFx8ZzRI6RESO2UBInthYdO38SDFszyyRN0THbe6fS0LBI42CZJdbbG1t1uOZ 1/i0fcwWXDL+xrH9sV3q6Xo/wAAsB9lALrOu3hiA= Authentication-Results: smtp11.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-Suid-Status: 1 0,1 0,1 0 Subject: Re: ALPHA3 panic with ipfw+dummynet and gif/gre tunnels To: Mark Felder , freebsd-current@freebsd.org, freebsd-ipfw@freebsd.org References: <1466125434.1167831.640215001.594DC233@webmail.messagingengine.com> From: "Andrey V. Elsukov" Message-ID: <5763B5DF.1050202@yandex.ru> Date: Fri, 17 Jun 2016 11:33:35 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <1466125434.1167831.640215001.594DC233@webmail.messagingengine.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0dK4AjEGHXEwb3lv98X1liKNRvgSeRtoU" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 08:34:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0dK4AjEGHXEwb3lv98X1liKNRvgSeRtoU Content-Type: multipart/mixed; boundary="isgg6E500OhLN4djDRpmfe0P7fmudjjqP" From: "Andrey V. Elsukov" To: Mark Felder , freebsd-current@freebsd.org, freebsd-ipfw@freebsd.org Message-ID: <5763B5DF.1050202@yandex.ru> Subject: Re: ALPHA3 panic with ipfw+dummynet and gif/gre tunnels References: <1466125434.1167831.640215001.594DC233@webmail.messagingengine.com> In-Reply-To: <1466125434.1167831.640215001.594DC233@webmail.messagingengine.com> --isgg6E500OhLN4djDRpmfe0P7fmudjjqP Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 17.06.16 04:03, Mark Felder wrote: > #8 0xffffffff80eb7a64 in trap (frame=3D0xfffffe0122831770) at > /usr/src/sys/amd64/amd64/trap.c:442 > #9 0xffffffff80e97f91 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:236 > #10 0xffffffff80c57ebc in ip6_output (m0=3D, > opt=3D, ro=3D, flags=3D optimized out>, im6o=3D0x0, ifpp=3D0x0, inp=3D) > at /usr/src/sys/netinet6/ip6_output.c:1060 > #11 0xffffffff82661fd2 in dummynet_send (m=3D) at > /usr/src/sys/modules/dummynet/../../netpfil/ipfw/ip_dn_io.c:800 > #12 0xffffffff82661890 in dummynet_task (context=3D, > pending=3D) at > /usr/src/sys/modules/dummynet/../../netpfil/ipfw/ip_dn_io.c:746 > #13 0xffffffff80a9a1ac in taskqueue_run_locked (queue=3D out>) at /usr/src/sys/kern/subr_taskqueue.c:465 > #14 0xffffffff80a9acf8 in taskqueue_thread_loop (arg=3D out>) at /usr/src/sys/kern/subr_taskqueue.c:719 > #15 0xffffffff80a0b3e4 in fork_exit (callout=3D0xffffffff80a9ac70 > , arg=3D0xffffffff8266c8a8, > frame=3D0xfffffe0122831c00) at /usr/src/sys/kern/kern_fork.c:1038 > #16 0xffffffff80e984ce in fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:611 > #17 0x0000000000000000 in ?? () Hi, this is known issue. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209466 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D162558 It looks the same, but for IPv6. --=20 WBR, Andrey V. Elsukov --isgg6E500OhLN4djDRpmfe0P7fmudjjqP-- --0dK4AjEGHXEwb3lv98X1liKNRvgSeRtoU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXY7XjAAoJEAHF6gQQyKF64pwIAJ89e8FQj8Loj/Hx6tAn9xi3 8CJiAVCnS+hN8kRPOUCZJJtwT4ROq+z+Tr9OWQMNh+yFCV+GQCwynEzAAYfouUp+ 2i+65Zh5AIbfmx8Hp6lO1zevFQWsw3owdAjXVxpCjC0rjhNgXkVUmb8pMex6Z6wE KEKu0xvNMYjDumj75ykuhI6T3aIAKbD8+S9k0BRLrgkhAOJAgwexMk1ehC5sq8W9 E5/y8LUkyRO5yFBagBISTRE9h7JMY1nWaI9FLZD0L9yQNoLOdsEO7rbfZHiyspyl lTQYQElKWQa6rHtwu9vZfrw5UxDhbBFiJfmU/2RkQIWxp2K9T8uuUFTrnyGcYpE= =5STC -----END PGP SIGNATURE----- --0dK4AjEGHXEwb3lv98X1liKNRvgSeRtoU--