From owner-freebsd-ipfw@FreeBSD.ORG Wed Oct 29 14:17:13 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 169A1F2F for ; Wed, 29 Oct 2014 14:17:13 +0000 (UTC) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E0ABAE6B for ; Wed, 29 Oct 2014 14:17:12 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id bj1so3253935pad.17 for ; Wed, 29 Oct 2014 07:17:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=UAF3LhMouguTqto/Oochkr/wCrSnoGB+Pat8Rz0vjCM=; b=TxTAcyM9zl23szVNeRbl1HnsK8OWpj0F2woA56dGPwksOFA4Q0CL7iEXflQZKQ91WP eXf4HRbdA8ODrQyaOOCrstEaAaOvfBeTrAb0bLFa2lFxRAGL8EE5/TJbLUSGgxbx3rgH ClOjP22Y0+BOCgx4sEcwYVelW9L1vhUSrnDBlnOX8WDdiQt2IJzKq6RRBtuw+7Bhnx6t Sn+pULFpRK7gXohzTw7to+I4zuKCmo4Q58NQbaRVCMKv55dsCE/g8XJ1QX3wFR5VQJaE QxhbjjnCEifAiKDC07NPtV+/XXXTG2vsO56XUdK1SZGyf+94UOhepU26CClIfPAkwqHG GTzQ== X-Received: by 10.70.34.175 with SMTP id a15mr10621677pdj.123.1414592232392; Wed, 29 Oct 2014 07:17:12 -0700 (PDT) Received: from billwin7 ([138.75.190.18]) by mx.google.com with ESMTPSA id kw10sm4562993pab.0.2014.10.29.07.17.11 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 29 Oct 2014 07:17:11 -0700 (PDT) From: "bycn82" To: Subject: ipfw table features Date: Wed, 29 Oct 2014 22:17:10 +0800 Message-ID: <005901cff383$086bc6a0$194353e0$@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/zgqSUPRDmSBkGSRmBTZ0snaSk3Q== Content-Language: en-sg Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 14:17:13 -0000 Hi, Finally got some time to read the new implementation of table feature. Compare to the previous code, it is much more clear now, Well done! Regards, Bycn82 From owner-freebsd-ipfw@FreeBSD.ORG Wed Oct 29 14:39:37 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D719C431 for ; Wed, 29 Oct 2014 14:39:37 +0000 (UTC) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ACAEF103 for ; Wed, 29 Oct 2014 14:39:37 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id z10so3109308pdj.1 for ; Wed, 29 Oct 2014 07:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=WQKZc60DLdNLDxIo2d2BL3t+cKneOchr5f3TrMOKPos=; b=BKy3ORCy1CGlRIjpfKOo8B2juHJUEUhOreEwtw3Wc0P1StYjuA2ocpaoZ1T3R1KRE8 WZfwubG/9C6een8+A5uIAOj73kEe/Afkls0Jplhqe/eSsO/KgIuLLqlSZVeM1YmynDwd aGG7sXznjZ8wKQCucmdQogQKwiJDzRu2VBbeHMbdllwOpNSWBz3zXb1R3KzYBthDxi8G P/XWDFluqArmogULdjW3CFzvXxNShgbvhi9WcMEPdjRdhatJ1S2nLp4KxHvycnjQw4jg vU9NqbexDOt6RhLhMAlvTu4ST/wHVbdNcrYcEJKBy/9Wa8B98p304jRzMonIns/9OSbG p19Q== X-Received: by 10.66.118.136 with SMTP id km8mr11109682pab.100.1414593577207; Wed, 29 Oct 2014 07:39:37 -0700 (PDT) Received: from billwin7 ([138.75.190.18]) by mx.google.com with ESMTPSA id i11sm4529483pbq.84.2014.10.29.07.39.35 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 29 Oct 2014 07:39:36 -0700 (PDT) From: "bycn82" To: Subject: performance of the swtich/case statements Date: Wed, 29 Oct 2014 22:39:34 +0800 Message-ID: <009101cff386$29c30e50$7d492af0$@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/zhEX3fijTYxUjT/OSisHo9d/SSw== Content-Language: en-sg Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 14:39:37 -0000 Hi All, It is using the switch/case statement to make the code clear in the implementation, so it reminded me the question which I want to ask when I read the source of ipfw for the first time. It is about the performance of the switch/case statement. Sure the code of this table feature are running in the user-land, so there is no performance concern here, But my question is the switch/case statements in the 2 loops. I am not a C programmer, so I am not clear how the switch/case will be optimized by the compiler in FreeBSD. But I used to write a compiler by myself and I use a hash table to handle all the conditions in the case statements because my compiler don't care about performance!, But in C it is different, the case statement can only accept "int" values, so I don't think it will use hash or what , it should be directly use an array(), So whether it can be optimized it depends on the conditions in the switch/case statements, and I noticed that the cases statement in the 2 loops are not arranging the opcode in running number, so does the compiler smart enough to optimize it? Regards, Bycn82 From: bycn82 [mailto:bycn82@gmail.com] Sent: Wednesday, 29 October, 2014 10:17 PM To: 'freebsd-ipfw@freebsd.org' Subject: ipfw table features Hi, Finally got some time to read the new implementation of table feature. Compare to the previous code, it is much more clear now, Well done! Regards, Bycn82 From owner-freebsd-ipfw@FreeBSD.ORG Wed Oct 29 22:31:06 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCC75D7F for ; Wed, 29 Oct 2014 22:31:06 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A67BBF8 for ; Wed, 29 Oct 2014 22:31:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=jxJNVB3xo+1RLPyySTzTecQ+BKbyRuDvSCtkCnEo/9I=; b=EIERmd9Ys9RVi/Ri1majI7nOS6d6sdvnl4AvmWRNCQEpN8uU+Ijx6czD7e92S1tYdMXAnXN8oZewXCQ/ToGl4A/M8+k2oyB9bjLRK/LTGpllZYbA4fOcNh37CS1IOiRFeIk9TI/vI/nFCgd1UWObSmlLk9V7OOjNd4z3Y9NyYt8=; Received: from [182.0.86.235] (port=18894 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpa (Exim 4.82) (envelope-from ) id 1Xjblb-002yqy-Tx; Wed, 29 Oct 2014 16:31:00 -0600 Date: Thu, 30 Oct 2014 06:30:53 +0800 From: Erich Dollansky To: "bycn82" Subject: Re: performance of the swtich/case statements Message-ID: <20141030063053.12608314@X220.alogt.com> In-Reply-To: <009101cff386$29c30e50$7d492af0$@gmail.com> References: <009101cff386$29c30e50$7d492af0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 22:31:06 -0000 Hi, On Wed, 29 Oct 2014 22:39:34 +0800 "bycn82" wrote: > It is using the switch/case statement to make the code clear in the > > I am not a C programmer, so I am not clear how the switch/case will be > optimized by the compiler in FreeBSD. But I used to write a compiler > by myself and I use a hash table to handle all the conditions in the > case statements because my compiler don't care about performance!, > But in C it is different, the case statement can only accept "int" > values, so I don't think it will use hash or what , it should be > directly use an array(), So whether it can be optimized it depends on > the conditions in the switch/case statements, and I noticed that the > cases statement in the 2 loops are not arranging the opcode in > running number, so does the compiler smart enough to optimize it? > > I did not check recently. It was already a long, long time ago, that compilers checked the limits and used the values as an index into a table to jump to the code. I hope that this did not get changed. With other words, the order in the code does not matter. The only optimisation the compiler can do, is not to use a table if the statement consists of a low number of entries only. Erich From owner-freebsd-ipfw@FreeBSD.ORG Thu Oct 30 04:24:34 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9495E894; Thu, 30 Oct 2014 04:24:34 +0000 (UTC) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 66B35B6C; Thu, 30 Oct 2014 04:24:34 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id z10so4360936pdj.29 for ; Wed, 29 Oct 2014 21:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9VMUDdhKaNCUrwzGu5Ba+FhLnYQX+/OK/XW4GIlKX1A=; b=lZO4UdIuYXuEpxfKLHVyqpHrdzAr6u1EyK7VzW8XX+phd5dgiOi8MO9Bx4Y55shXfK mQmwrR2VceOSbB/gydREc/bITfZ5/QHNSisPk/nvHxFb2LObyYJ6xniPYkFEq8iUvLOL npmTLwRLKvY45plVdK94E+eLv8w4KPU3AjERyvQxQZwyhAirictULkVeO+Y2h8vRo2h1 QcXXVgcYUQJVn0vR4erBMCBt4Bp34+kDPqmBV6uZHVq9mPjphhDWfQ8fYRXKNr/BznCw g0Dz7unEc93kyyhrSG+d0+oiH5SSUEanFEvowK6QGgg0gTyL7qSKeeeu7MgHvDJeBcdv iHlQ== MIME-Version: 1.0 X-Received: by 10.70.96.162 with SMTP id dt2mr14761368pdb.29.1414643074006; Wed, 29 Oct 2014 21:24:34 -0700 (PDT) Received: by 10.70.42.228 with HTTP; Wed, 29 Oct 2014 21:24:33 -0700 (PDT) In-Reply-To: <20141030063053.12608314@X220.alogt.com> References: <009101cff386$29c30e50$7d492af0$@gmail.com> <20141030063053.12608314@X220.alogt.com> Date: Thu, 30 Oct 2014 12:24:33 +0800 Message-ID: Subject: Re: performance of the swtich/case statements From: bycn82 To: Erich Dollansky , FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 04:24:34 -0000 Hi, According to my understanding in Java programming, the compiler will automatically store the values into a table and jump to the correct one according to the value only when the condition values are in running number, for example. swtich(a){ case 1: code block 1 case 2: code block 2 case 3: code block 3 case 4: code block 4 default: code block 5 } it will be handled by an array 1-->code block 1 2-->code block 2 3-->code block 3 4-->code block 4 others-->code block 5 so when the value N is greater than or lesser than 1, it will be directly jump to the "code block 5" otherwise, it will jump to N, because call the cases are nice in running numbers, but when the cases are messy, it will by just like lots of if/else On Thu, Oct 30, 2014 at 6:30 AM, Erich Dollansky < erichsfreebsdlist@alogt.com> wrote: > Hi, > > On Wed, 29 Oct 2014 22:39:34 +0800 > "bycn82" wrote: > > > It is using the switch/case statement to make the code clear in the > > > > I am not a C programmer, so I am not clear how the switch/case will be > > optimized by the compiler in FreeBSD. But I used to write a compiler > > by myself and I use a hash table to handle all the conditions in the > > case statements because my compiler don't care about performance!, > > But in C it is different, the case statement can only accept "int" > > values, so I don't think it will use hash or what , it should be > > directly use an array(), So whether it can be optimized it depends on > > the conditions in the switch/case statements, and I noticed that the > > cases statement in the 2 loops are not arranging the opcode in > > running number, so does the compiler smart enough to optimize it? > > > > > I did not check recently. It was already a long, long time ago, that > compilers checked the limits and used the values as an index into a > table to jump to the code. I hope that this did not get changed. > > With other words, the order in the code does not matter. The only > optimisation the compiler can do, is not to use a table if the > statement consists of a low number of entries only. > > Erich > From owner-freebsd-ipfw@FreeBSD.ORG Thu Oct 30 23:42:01 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE7098F4; Thu, 30 Oct 2014 23:42:00 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B5576354; Thu, 30 Oct 2014 23:42:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=WxOiZICDi4Fxs7ESElswXGhp9FVcedpVd63mEOdP19o=; b=ckXTJTtjCHRM0MH2isErEP8ve4IPTwXF5z2mIgMcj+jSkzXNlT92It9TQyknD9aegJ7zmlRb4BjA134xT5lfPpFeIJ2ldsMmlthl2swGSJ3+VjIb5JRJ03T9D6ygjC8DB68xBKtxl16in5gpspjqeJm2ugXsAmmNoDSJLTzjBQk=; Received: from [182.9.153.44] (port=13067 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpa (Exim 4.82) (envelope-from ) id 1XjzLl-004LHS-9y; Thu, 30 Oct 2014 17:41:53 -0600 Date: Fri, 31 Oct 2014 07:41:49 +0800 From: Erich Dollansky To: bycn82 Subject: Re: performance of the swtich/case statements Message-ID: <20141031074149.591c09de@X220.alogt.com> In-Reply-To: References: <009101cff386$29c30e50$7d492af0$@gmail.com> <20141030063053.12608314@X220.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: FreeBSD Net , freebsd-ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 23:42:01 -0000 Hi, On Thu, 30 Oct 2014 12:24:33 +0800 bycn82 wrote: > Hi, > According to my understanding in Java programming, the compiler will aren't we talking about C here? Erich > automatically store the values into a table and jump to the correct > one according to the value only when the condition values are in > running number, > > for example. > > swtich(a){ > case 1: code block 1 > case 2: code block 2 > case 3: code block 3 > case 4: code block 4 > default: code block 5 > } > > it will be handled by an array > 1-->code block 1 > 2-->code block 2 > 3-->code block 3 > 4-->code block 4 > others-->code block 5 > > so when the value N is greater than or lesser than 1, it will be > directly jump to the "code block 5" > otherwise, it will jump to N, because call the cases are nice in > running numbers, > > but when the cases are messy, it will by just like lots of if/else > > > On Thu, Oct 30, 2014 at 6:30 AM, Erich Dollansky < > erichsfreebsdlist@alogt.com> wrote: > > > Hi, > > > > On Wed, 29 Oct 2014 22:39:34 +0800 > > "bycn82" wrote: > > > > > It is using the switch/case statement to make the code clear in > > > the > > > > > > I am not a C programmer, so I am not clear how the switch/case > > > will be optimized by the compiler in FreeBSD. But I used to write > > > a compiler by myself and I use a hash table to handle all the > > > conditions in the case statements because my compiler don't care > > > about performance!, But in C it is different, the case statement > > > can only accept "int" values, so I don't think it will use hash > > > or what , it should be directly use an array(), So whether it can > > > be optimized it depends on the conditions in the switch/case > > > statements, and I noticed that the cases statement in the 2 loops > > > are not arranging the opcode in running number, so does the > > > compiler smart enough to optimize it? > > > > > > > > I did not check recently. It was already a long, long time ago, that > > compilers checked the limits and used the values as an index into a > > table to jump to the code. I hope that this did not get changed. > > > > With other words, the order in the code does not matter. The only > > optimisation the compiler can do, is not to use a table if the > > statement consists of a low number of entries only. > > > > Erich > > From owner-freebsd-ipfw@FreeBSD.ORG Sat Nov 1 05:16:11 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EDC0B1CB; Sat, 1 Nov 2014 05:16:11 +0000 (UTC) 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 44F411D6; Sat, 1 Nov 2014 05:16:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id sA15G85D081579; Sat, 1 Nov 2014 16:16:08 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 1 Nov 2014 16:16:07 +1100 (EST) From: Ian Smith To: Freddie Cash Subject: Re: any reason not to enable IPDIVERT for ipfw module? In-Reply-To: Message-ID: <20141101144834.N52402@sola.nimnet.asn.au> References: <20141031191212.GO8852@funkthat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net , freebsd-ipfw@freebsd.org, FreeBSD Arch X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 05:16:12 -0000 On Fri, 31 Oct 2014 18:28:28 -0700, Freddie Cash wrote: > On Oct 31, 2014 12:12 PM, "John-Mark Gurney" wrote: > > > > Can any one think of a good reason not to enable IPDIVERT sockets in > > the ipfw module? Yes, two. Nowadays people are just as or perhaps more likely to use in-kernel NAT, loading ipfw_nat.ko instead of ipdivert.ko, and there's no good reason to add extra code to ipfw.ko unless it's going to be used. See libalias(3) /MODULAR ARCHITECTURE Similaly there'd be no reason to include dummynet code unless using it. > > And possibly enabling default to accept? That way you don't have to > > go to the console when you load the ipfw module because you forgot to > > auto add the accept all rule? :) That'd reverse some 15+ years of security policy, of having the firewall closed until you've loaded your ruleset, to cater to forgetfulness? :) > You can change the default rule to accept via loader.conf and it will be > set when the module is loaded. > > net.inet.IP.fw.default_to_accept or something Luke that. Yes, net.inet.ip.fw.default_to_accept=1 is a loader tunable, and can be set before ipfw is loaded, unlike the net.inet.ip.fw sysctls which don't exist until ipfw is loaded. Or it can be set to 0 to reverse policy if kernel has been built with 'options IPFIREWALL_DEFAULT_TO_ACCEPT'. Normally /etc/rc.d/ipfw takes care of loading ipfw_nat or ipdivert (or both if you wanted to use both natd(8) and ipfw_nat for some reason?) and/or dummynet, according to the rc.conf variables. I've added freebsd-ipfw@ to ccs, just because it seems relevant .. cheers, Ian > > something like: > > ==== //depot/projects/opencrypto/sys/modules/ipfw/Makefile#3 - > /home/jmg/freebsd.p4/opencrypto/sys/modules/ipfw/Makefile ==== > > --- /tmp/tmp.15774.16 2014-10-31 12:11:56.000000000 -0700 > > +++ /home/jmg/freebsd.p4/opencrypto/sys/modules/ipfw/Makefile > 2014-10-31 12:11:54.000000000 -0700 > > @@ -16,7 +16,10 @@ > > #CFLAGS+= -DIPFIREWALL_VERBOSE_LIMIT=100 > > # > > #If you want it to pass all packets by default > > -#CFLAGS+= -DIPFIREWALL_DEFAULT_TO_ACCEPT > > +CFLAGS+= -DIPFIREWALL_DEFAULT_TO_ACCEPT > > +# > > +#If you want divert sockets > > +CFLAGS+= -DIPDIVERT > > # > > > > .include > > > > -- > > John-Mark Gurney Voice: +1 415 225 5579 > > > > "All that I will do, has been done, All that I have, has not."