From owner-freebsd-ipfw@FreeBSD.ORG Mon Feb 24 11:06:51 2014 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35C5BA9C for ; Mon, 24 Feb 2014 11:06:51 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 21895161D for ; Mon, 24 Feb 2014 11:06:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1OB6ouI027565 for ; Mon, 24 Feb 2014 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1OB6oLa027563 for freebsd-ipfw@FreeBSD.org; Mon, 24 Feb 2014 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Feb 2014 11:06:50 GMT Message-Id: <201402241106.s1OB6oLa027563@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 11:06:51 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/180731 ipfw [ipfw] problem with displaying 255.255.255.255 address o kern/180729 ipfw [ipfw] ipfw nat show empty output o kern/178482 ipfw [ipfw] logging problem from vnet jail o kern/178480 ipfw [ipfw] dynamically loaded ipfw with a vimage kernel do o kern/178317 ipfw [ipfw] ipfw options need to specifed in specific order o kern/177948 ipfw [ipfw] ipfw fails to parse port ranges (p1-p2) for udp o kern/176503 ipfw [ipfw] ipfw layer2 problem o conf/167822 ipfw [ipfw] [patch] start script doesn't load firewall_type o kern/166406 ipfw [ipfw] ipfw does not set ALTQ identifier for ipv6 traf o kern/165939 ipfw [ipfw] bug: incomplete firewall rules loaded if tables o kern/165190 ipfw [ipfw] [lo] [patch] loopback interface is not marking o kern/158066 ipfw [ipfw] ipfw + netgraph + multicast = multicast packets o kern/157689 ipfw [ipfw] ipfw nat config does not accept nonexistent int f kern/155927 ipfw [ipfw] ipfw stops to check packets for compliance with o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw [ipfw] does not support specifying rules with ICMP cod o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. f kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l f kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes s kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 41 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 3 11:06:46 2014 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C272AE06 for ; Mon, 3 Mar 2014 11:06:46 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ACBF2943 for ; Mon, 3 Mar 2014 11:06:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s23B6kJ5008534 for ; Mon, 3 Mar 2014 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s23B6ke2008532 for freebsd-ipfw@FreeBSD.org; Mon, 3 Mar 2014 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Mar 2014 11:06:46 GMT Message-Id: <201403031106.s23B6ke2008532@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 11:06:46 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/180731 ipfw [ipfw] problem with displaying 255.255.255.255 address o kern/180729 ipfw [ipfw] ipfw nat show empty output o kern/178482 ipfw [ipfw] logging problem from vnet jail o kern/178480 ipfw [ipfw] dynamically loaded ipfw with a vimage kernel do o kern/178317 ipfw [ipfw] ipfw options need to specifed in specific order o kern/177948 ipfw [ipfw] ipfw fails to parse port ranges (p1-p2) for udp o kern/176503 ipfw [ipfw] ipfw layer2 problem o conf/167822 ipfw [ipfw] [patch] start script doesn't load firewall_type o kern/166406 ipfw [ipfw] ipfw does not set ALTQ identifier for ipv6 traf o kern/165939 ipfw [ipfw] bug: incomplete firewall rules loaded if tables o kern/165190 ipfw [ipfw] [lo] [patch] loopback interface is not marking o kern/158066 ipfw [ipfw] ipfw + netgraph + multicast = multicast packets o kern/157689 ipfw [ipfw] ipfw nat config does not accept nonexistent int f kern/155927 ipfw [ipfw] ipfw stops to check packets for compliance with o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw [ipfw] does not support specifying rules with ICMP cod o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. f kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l f kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes s kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 41 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 10 11:06:47 2014 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 439A2159 for ; Mon, 10 Mar 2014 11:06:47 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3120380B for ; Mon, 10 Mar 2014 11:06:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2AB6l7T043232 for ; Mon, 10 Mar 2014 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2AB6kiA043230 for freebsd-ipfw@FreeBSD.org; Mon, 10 Mar 2014 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Mar 2014 11:06:46 GMT Message-Id: <201403101106.s2AB6kiA043230@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 11:06:47 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/180731 ipfw [ipfw] problem with displaying 255.255.255.255 address o kern/180729 ipfw [ipfw] ipfw nat show empty output o kern/178482 ipfw [ipfw] logging problem from vnet jail o kern/178480 ipfw [ipfw] dynamically loaded ipfw with a vimage kernel do o kern/178317 ipfw [ipfw] ipfw options need to specifed in specific order o kern/177948 ipfw [ipfw] ipfw fails to parse port ranges (p1-p2) for udp o kern/176503 ipfw [ipfw] ipfw layer2 problem o conf/167822 ipfw [ipfw] [patch] start script doesn't load firewall_type o kern/166406 ipfw [ipfw] ipfw does not set ALTQ identifier for ipv6 traf o kern/165939 ipfw [ipfw] bug: incomplete firewall rules loaded if tables o kern/165190 ipfw [ipfw] [lo] [patch] loopback interface is not marking o kern/158066 ipfw [ipfw] ipfw + netgraph + multicast = multicast packets o kern/157689 ipfw [ipfw] ipfw nat config does not accept nonexistent int f kern/155927 ipfw [ipfw] ipfw stops to check packets for compliance with o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw [ipfw] does not support specifying rules with ICMP cod o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. f kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l f kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes s kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 41 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 11 03:53:58 2014 Return-Path: Delivered-To: ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E1EC61C for ; Tue, 11 Mar 2014 03:53:58 +0000 (UTC) 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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 04B02AC9 for ; Tue, 11 Mar 2014 03:53:54 +0000 (UTC) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id s2B3rkNg000849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 10 Mar 2014 20:53:47 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <531E88C3.6030305@freebsd.org> Date: Mon, 10 Mar 2014 20:53:39 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: ipfw@FreeBSD.org Subject: ipfw stateful and ICMP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 03:53:58 -0000 It has annoyed me for some time that icmp packets refering ot an ongoing session can not be matched by a dynamic rule that goversn that session. For example, if you have a dynamic rule for tcp 1.2.3.4 port 80 from 5.6.7.8 port 10000 then a returning icmp packet giving "destination unreachable" and holding the appropriate header in it's data segment should probably be allowed to go through back to the originator. Briefly looking at the code I see no sign of this and I haven't seen any sign of it in action so I hope I'm not going to get a "but it already does that" response. My way of approaching it would be to change the dynamic rule code so that it checks that the ICMP destination address matches the source address of the packet fragment in the 'data' section, and then match the data segment packet header with the dynamic rules instead of the icmp packet itself. I would also add a sysctl to disable this behaviour, because there is always someone who doesn't want any change you care to name. The only way you can allow get icmp packets back to the originating sender at the moment is to just allow them through without any major filtering. That leaves you open to a large attack window. anyone have violent objections? (I'm currently rewriting the firewall rules at $DAYJOB and I think I'd like to have this, but as we're on 8.0 I'll have to wait a while before I can use my own patch :-) Julian From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 11 08:06:38 2014 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7003C53F; Tue, 11 Mar 2014 08:06:38 +0000 (UTC) Received: from nskntmtas02p.mx.bigpond.com (nskntmtas02p.mx.bigpond.com [61.9.168.140]) by mx1.freebsd.org (Postfix) with ESMTP id DC46D26A; Tue, 11 Mar 2014 08:06:37 +0000 (UTC) Received: from nskntcmgw08p ([61.9.169.168]) by nskntmtas02p.mx.bigpond.com with ESMTP id <20140311080629.HPQA26993.nskntmtas02p.mx.bigpond.com@nskntcmgw08p>; Tue, 11 Mar 2014 08:06:29 +0000 Received: from hermes.heuristicsystems.com.au ([121.210.107.100]) by nskntcmgw08p with BigPond Outbound id c86V1n00F29zwdD0186VS8; Tue, 11 Mar 2014 08:06:29 +0000 X-Authority-Analysis: v=2.0 cv=b8MwE66x c=1 sm=1 a=SEJ2iDwVkb98DYvesvueMw==:17 a=JipEcVzqA9wA:10 a=8nJEP1OIZ-IA:10 a=GHIR_BbyAAAA:8 a=6I5d2MoRAAAA:8 a=KRYVWgrIeV_SfOQ2490A:9 a=wPNLvfGTeEIA:10 a=SV7veod9ZcQA:10 a=OUIiSCU4Aon4Tw1b:21 a=8090jt6BRmlbcaYK:21 a=SEJ2iDwVkb98DYvesvueMw==:117 Received: from [10.0.5.3] (ewsw01.hs [10.0.5.3]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id s2B86hSj014186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 11 Mar 2014 19:06:44 +1100 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Message-ID: <531EC3E6.8030604@heuristicsystems.com.au> Date: Tue, 11 Mar 2014 19:05:58 +1100 From: Dewayne Geraghty User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Julian Elischer , ipfw@freebsd.org Subject: Re: ipfw stateful and ICMP References: <531E88C3.6030305@freebsd.org> In-Reply-To: <531E88C3.6030305@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 08:06:38 -0000 On 11/03/2014 2:53 PM, Julian Elischer wrote: > It has annoyed me for some time that icmp packets refering ot an > ongoing session can not be matched by a dynamic rule that goversn that > session. > > For example, if you have a dynamic rule for tcp 1.2.3.4 port > 80 from 5.6.7.8 port 10000 then a returning icmp packet giving > "destination unreachable" and holding the appropriate header > in it's data segment should probably be allowed to go through > back to the originator. > > Briefly looking at the code I see no sign of this and I haven't seen > any sign of it in action so I hope I'm not going to get a > "but it already does that" response. > > My way of approaching it would be to change the dynamic rule code so that > it checks that the ICMP destination address matches the source address > of the packet fragment in the 'data' section, and then match the data > segment > packet header with the dynamic rules instead of the icmp packet itself. > > I would also add a sysctl to disable this behaviour, because there is > always > someone who doesn't want any change you care to name. > > The only way you can allow get icmp packets back to the originating > sender > at the moment is to just allow them through without any major filtering. > That leaves you open to a large attack window. > > anyone have violent objections? > > (I'm currently rewriting the firewall rules at $DAYJOB and I think I'd > like to have this, > but as we're on 8.0 I'll have to wait a while before I can use my own > patch :-) > > Julian > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > Julian, That's a good idea, and I appreciate the feedback opportunity. May I suggest a sysctl to enable the behaviour, rather than one to disable it. For two reasons: so that existing ipfw sites don't find the need to change or amend existing firewall rules (we typically open icmp 3 and 11); and how do you envisage "ipfw show" will display this compound behaviour? Regards, Dewayne. From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 12 07:05:53 2014 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 282DA290 for ; Wed, 12 Mar 2014 07:05:53 +0000 (UTC) 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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D6E43EF9 for ; Wed, 12 Mar 2014 07:05:51 +0000 (UTC) Received: from Julian-MBP3.local ([12.157.112.67]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id s2C75cCR004663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 12 Mar 2014 00:05:39 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5320073B.7070006@freebsd.org> Date: Wed, 12 Mar 2014 00:05:31 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Dewayne Geraghty , ipfw@freebsd.org Subject: Re: ipfw stateful and ICMP References: <531E88C3.6030305@freebsd.org> <531EC3E6.8030604@heuristicsystems.com.au> In-Reply-To: <531EC3E6.8030604@heuristicsystems.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 07:05:53 -0000 On 3/11/14, 1:05 AM, Dewayne Geraghty wrote: > On 11/03/2014 2:53 PM, Julian Elischer wrote: >> It has annoyed me for some time that icmp packets refering ot an >> ongoing session can not be matched by a dynamic rule that goversn that >> session. >> >> For example, if you have a dynamic rule for tcp 1.2.3.4 port >> 80 from 5.6.7.8 port 10000 then a returning icmp packet giving >> "destination unreachable" and holding the appropriate header >> in it's data segment should probably be allowed to go through >> back to the originator. >> >> Briefly looking at the code I see no sign of this and I haven't seen >> any sign of it in action so I hope I'm not going to get a >> "but it already does that" response. >> >> My way of approaching it would be to change the dynamic rule code so that >> it checks that the ICMP destination address matches the source address >> of the packet fragment in the 'data' section, and then match the data >> segment >> packet header with the dynamic rules instead of the icmp packet itself. >> >> I would also add a sysctl to disable this behaviour, because there is >> always >> someone who doesn't want any change you care to name. >> >> The only way you can allow get icmp packets back to the originating >> sender >> at the moment is to just allow them through without any major filtering. >> That leaves you open to a large attack window. >> >> anyone have violent objections? >> >> (I'm currently rewriting the firewall rules at $DAYJOB and I think I'd >> like to have this, >> but as we're on 8.0 I'll have to wait a while before I can use my own >> patch :-) >> >> Julian >> >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >> >> > Julian, > That's a good idea, and I appreciate the feedback opportunity. > > May I suggest a sysctl to enable the behaviour, rather than one to > disable it. For two reasons: so that existing ipfw sites don't find the > need to change or amend existing firewall rules (we typically open icmp > 3 and 11); and how do you envisage "ipfw show" will display this > compound behaviour? I don't know that it need show anything special. the display of dynamic rules might be changed to show something but I haven't thought too much about it yet. > > Regards, Dewayne. > > > From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 16 15:07:50 2014 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52EA539C; Sun, 16 Mar 2014 15:07:50 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A56811CA; Sun, 16 Mar 2014 15:07:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s2GEssrN001823; Mon, 17 Mar 2014 01:54:55 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 17 Mar 2014 01:54:54 +1100 (EST) From: Ian Smith To: Julian Elischer Subject: Re: ipfw stateful and ICMP In-Reply-To: <531E88C3.6030305@freebsd.org> Message-ID: <20140317004822.T98925@sola.nimnet.asn.au> References: <531E88C3.6030305@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 15:07:50 -0000 On Mon, 10 Mar 2014 20:53:39 -0700, Julian Elischer wrote: > It has annoyed me for some time that icmp packets refering ot an ongoing > session can not be matched by a dynamic rule that goversn that session. > > For example, if you have a dynamic rule for tcp 1.2.3.4 port > 80 from 5.6.7.8 port 10000 then a returning icmp packet giving > "destination unreachable" and holding the appropriate header > in it's data segment should probably be allowed to go through > back to the originator. Can you always expect the data segment to contain the true srcaddr (perhaps NAT'd, perhaps with the same srcport) when any router along the way might be sending these - legitimately or otherwise? We don't need an open door for any MITM router to send us whatever ICMP it fancies, but I am interested in the development of this idea. Maybe you'll be looking into in-general stateful ICMP anyway? ISTR that any icmptypes were passed in return, but that was ages ago; is there yet any matching for request and response types, beyond pings? > Briefly looking at the code I see no sign of this and I haven't seen > any sign of it in action so I hope I'm not going to get a > "but it already does that" response. > > My way of approaching it would be to change the dynamic rule code so that > it checks that the ICMP destination address matches the source address > of the packet fragment in the 'data' section, and then match the data segment > packet header with the dynamic rules instead of the icmp packet itself. Have we only the srcaddr/dstaddr in the data returned to match flows on? And ports if from say a TCP or UDP request? Sorry, I've no time to hunt code, hope you don't mind me asking such basic stuff? I'm wondering about security in which case you (or at least authors of ipfw rulesets) might - likely should - want to filter out potential nasties like redirects, perhaps router advertisements, even better first pre-pass specified allowed icmptypes, dropping the rest (or at least, dropping them for consideration in stateful matches), BEFORE any check-state or keep-state waves packets through the fast lane - and we see quite a few rulesets published that begin with a check-state. > I would also add a sysctl to disable this behaviour, because there is always > someone who doesn't want any change you care to name. I agree with Dewayne about POLA; start opt-in, it will get promoted once widely appreciated :) It may need more sysctls for default behaviours. > The only way you can allow get icmp packets back to the originating sender > at the moment is to just allow them through without any major filtering. > That leaves you open to a large attack window. Yes, so cautious people have followed assorted gurus' advice re 'good' icmptypes, and this will need a way (apart from expert ruleset creation) to integrate that - some sort of allowed / denied icmptypes mask with conservative defaults? - so people don't inadvertantly open their boxes to, say, MITM floodpings, MSS choking, dodgy redirects, or worse(?) > anyone have violent objections? > > (I'm currently rewriting the firewall rules at $DAYJOB and I think I'd like > to have this, > but as we're on 8.0 I'll have to wait a while before I can use my own patch > :-) Can you trust a patch that its author isn't using? :) cheers, Ian From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 17 11:06:47 2014 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EFA259E6 for ; Mon, 17 Mar 2014 11:06:46 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DC59F295 for ; Mon, 17 Mar 2014 11:06:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2HB6kFH011275 for ; Mon, 17 Mar 2014 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2HB6kWL011273 for freebsd-ipfw@FreeBSD.org; Mon, 17 Mar 2014 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Mar 2014 11:06:46 GMT Message-Id: <201403171106.s2HB6kWL011273@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 11:06:47 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/180731 ipfw [ipfw] problem with displaying 255.255.255.255 address o kern/180729 ipfw [ipfw] ipfw nat show empty output o kern/178482 ipfw [ipfw] logging problem from vnet jail o kern/178480 ipfw [ipfw] dynamically loaded ipfw with a vimage kernel do o kern/178317 ipfw [ipfw] ipfw options need to specifed in specific order o kern/177948 ipfw [ipfw] ipfw fails to parse port ranges (p1-p2) for udp o kern/176503 ipfw [ipfw] ipfw layer2 problem o conf/167822 ipfw [ipfw] [patch] start script doesn't load firewall_type o kern/166406 ipfw [ipfw] ipfw does not set ALTQ identifier for ipv6 traf o kern/165939 ipfw [ipfw] bug: incomplete firewall rules loaded if tables o kern/165190 ipfw [ipfw] [lo] [patch] loopback interface is not marking o kern/158066 ipfw [ipfw] ipfw + netgraph + multicast = multicast packets o kern/157689 ipfw [ipfw] ipfw nat config does not accept nonexistent int f kern/155927 ipfw [ipfw] ipfw stops to check packets for compliance with o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw [ipfw] does not support specifying rules with ICMP cod o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. f kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l f kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes s kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 41 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 17 13:32:07 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E52E0382 for ; Mon, 17 Mar 2014 13:32:07 +0000 (UTC) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8ABE736C for ; Mon, 17 Mar 2014 13:32:06 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by fs.denninger.net (8.14.8/8.14.8) with ESMTP id s2HDW541043396 for ; Mon, 17 Mar 2014 08:32:05 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [127.0.0.1] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Mon Mar 17 08:32:05 2014 Message-ID: <5326F94F.9090400@denninger.net> Date: Mon, 17 Mar 2014 08:31:59 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Subject: Kernel memory leak in ipfw internal NAT 10-STABLE? Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070101040206020702090308" X-Antivirus: avast! (VPS 140317-0, 03/17/2014), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 13:32:08 -0000 This is a cryptographically signed message in MIME format. --------------ms070101040206020702090308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable It certainly looks like there is one; with the internal NAT capability=20 enabled (which was fine in 9.2-STABLE) I have a very busy machine that=20 consumed all (~20+GB!) of its RAM into the "inact" bucket and was=20 threatening to deadlock -- it got rid of all the free RAM and slowly=20 started forcing the working set out onto swap as well. None of the user processes showed a problem and killing them all did not = drop the allocation. Nor did unloading everything I could unload from=20 the kernel either. I reverted to running natd, and the problem has disappeared. A quick=20 look through the commits doesn't show anything suspicious -- and this=20 was working fine on 9.2-STABLE. Kernel rev is FreeBSD 10.0-STABLE #13 r263037M --=20 -- Karl karl@denninger.net --------------ms070101040206020702090308 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFTzCC BUswggQzoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwgZ0xCzAJBgNVBAYTAlVTMRAwDgYDVQQI EwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkqhkiG9w0BCQEWIGN1c3Rv bWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0MB4XDTEzMDgyNDE5MDM0NFoXDTE4MDgyMzE5 MDM0NFowWzELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExFzAVBgNVBAMTDkthcmwg RGVubmluZ2VyMSEwHwYJKoZIhvcNAQkBFhJrYXJsQGRlbm5pbmdlci5uZXQwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC5n2KBrBmG22nVntVdvgKCB9UcnapNThrW1L+dq6th d9l4mj+qYMUpJ+8I0rTbY1dn21IXQBoBQmy8t1doKwmTdQ59F0FwZEPt/fGbRgBKVt3Quf6W 6n7kRk9MG6gdD7V9vPpFV41e+5MWYtqGWY3ScDP8SyYLjL/Xgr+5KFKkDfuubK8DeNqdLniV jHo/vqmIgO+6NgzPGPgmbutzFQXlxUqjiNAAKzF2+Tkddi+WKABrcc/EqnBb0X8GdqcIamO5 SyVmuM+7Zdns7D9pcV16zMMQ8LfNFQCDvbCuuQKMDg2F22x5ekYXpwjqTyfjcHBkWC8vFNoY 5aFMdyiN/Kkz0/kduP2ekYOgkRqcShfLEcG9SQ4LQZgqjMpTjSOGzBr3tOvVn5LkSJSHW2Z8 Q0dxSkvFG2/lsOWFbwQeeZSaBi5vRZCYCOf5tRd1+E93FyQfpt4vsrXshIAk7IK7f0qXvxP4 GDli5PKIEubD2Bn+gp3vB/DkfKySh5NBHVB+OPCoXRUWBkQxme65wBO02OZZt0k8Iq0i4Rci WV6z+lQHqDKtaVGgMsHn6PoeYhjf5Al5SP+U3imTjF2aCca1iDB5JOccX04MNljvifXgcbJN nkMgrzmm1ZgJ1PLur/ADWPlnz45quOhHg1TfUCLfI/DzgG7Z6u+oy4siQuFr9QT0MQIDAQAB o4HWMIHTMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAsBglg hkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHw4 +LnuALyLA5Cgy7T5ZAX1WzKPMB8GA1UdIwQYMBaAFF3U3hpBZq40HB5VM7B44/gmXiI0MDgG CWCGSAGG+EIBAwQrFilodHRwczovL2N1ZGFzeXN0ZW1zLm5ldDoxMTQ0My9yZXZva2VkLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAZ0L4tQbBd0hd4wuw/YVqEBDDXJ54q2AoqQAmsOlnoxLO 31ehM/LvrTIP4yK2u1VmXtUumQ4Ao15JFM+xmwqtEGsh70RRrfVBAGd7KOZ3GB39FP2TgN/c L5fJKVxOqvEnW6cL9QtvUlcM3hXg8kDv60OB+LIcSE/P3/s+0tEpWPjxm3LHVE7JmPbZIcJ1 YMoZvHh0NSjY5D0HZlwtbDO7pDz9sZf1QEOgjH828fhtborkaHaUI46pmrMjiBnY6ujXMcWD pxtikki0zY22nrxfTs5xDWGxyrc/cmucjxClJF6+OYVUSaZhiiHfa9Pr+41okLgsRB0AmNwE f6ItY3TI8DGCBQowggUGAgEBMIGjMIGdMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxvcmlk YTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRwwGgYD VQQDExNDdWRhIFN5c3RlbXMgTExDIENBMS8wLQYJKoZIhvcNAQkBFiBjdXN0b21lci1zZXJ2 aWNlQGN1ZGFzeXN0ZW1zLm5ldAIBCDAJBgUrDgMCGgUAoIICOzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDAzMTcxMzMxNTlaMCMGCSqGSIb3DQEJBDEW BBR/0NjnkTbqt8ArWKc6esuhwG0YezBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG0BgkrBgEEAYI3EAQxgaYwgaMwgZ0xCzAJBgNV BAYTAlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoT EEN1ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkq hkiG9w0BCQEWIGN1c3RvbWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0AgEIMIG2BgsqhkiG 9w0BCRACCzGBpqCBozCBnTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExEjAQBgNV BAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExMQzEcMBoGA1UEAxMTQ3Vk YSBTeXN0ZW1zIExMQyBDQTEvMC0GCSqGSIb3DQEJARYgY3VzdG9tZXItc2VydmljZUBjdWRh c3lzdGVtcy5uZXQCAQgwDQYJKoZIhvcNAQEBBQAEggIAedFjP47W6bSJPqPtUGOcumGxL2zR AkNCJ/+e1LBhF9O4U8enZTM2/gKjUB2j5HH9QIYg5sYJmPBoHXbqm5+XqQ2hQmlS+7jdu5Ln QX8Ett7igL+SoGdMryorq7d+d/O9I7BoQa7RLhBtMBTEQmI0MlBOvRDHmUYy4DLoSsqS6ron RD/pd43qDNTok4igNIKhvZTDfh8JYBtCQ8Rz1Ig167/YhLtiFHUKgyp3NpQ7PPKbli2tLFlq maL15uRdG5Cnlkl+yTgbiH0ksy7HoR0QzVWFk1hZoi4QUFW7/VHIOX/51zLdmUJ7rJFFStTh LyPxoXeiqGOZ9MSv6GRznrmJ0znIK3KczQZDqzubdIRfmxlZJxwWtz+435HX+4KdShAQEy/U 5CYzq2S+54Ws9nOtX7tEU9PCe1M1KFIShIMsUahSh9rSSQRg1k/rtgkxvCGXd6IbU9Mv2iWf xCZyvVeejVypD39/aOMS5xpQREgiQl6H1fVZUVeBQiHKCkCW+jiKhrIUHUDa/uwZ5Fd2IR3Q mo0cUI32qHv1/L7mqqvr4rh84Of7HT9g9RHZmMvSau7zfpHB0C63bM9txxBBEiyETcMp9xNj SBWXRoD2xwmdB9Q34RrqG944HR53XqD+0+YqHzJVIs3GKoqtv+OuhYSdG+M7Xnc+RsjOxg8m A0A87nYAAAAAAAA= --------------ms070101040206020702090308-- From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 23 05:34:04 2014 Return-Path: Delivered-To: ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 49A35808; Sun, 23 Mar 2014 05:34:04 +0000 (UTC) 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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1882B9; Sun, 23 Mar 2014 05:34:03 +0000 (UTC) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s2N5XtLT002560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 22 Mar 2014 22:33:56 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <532E723C.2090109@freebsd.org> Date: Sat, 22 Mar 2014 22:33:48 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: RW , freebsd-security@freebsd.org, ipfw@FreeBSD.org Subject: Re: URGENT? References: <51546.1395432085@server1.tristatelogic.com> <20140322182402.Q83569@sola.nimnet.asn.au> <201403221454.IAA22021@mail.lariat.net> <20140322151155.184d5229@gumby.homeunix.com> In-Reply-To: <20140322151155.184d5229@gumby.homeunix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 05:34:04 -0000 On 3/22/14, 8:11 AM, RW wrote: > On Sat, 22 Mar 2014 08:48:40 -0600 > Brett Glass wrote: > >> This is correct. And that's awkward, because you might not want all of >> these checks in one place. Also, if there are many dynamic rules this >> will slow traffic down quite a bit. in ipfw that's up to you.. but I usually put the check-state quite early in my rule sets. I am working on a new rc.firewall that is much more efficient. the trouble is that the script to make it do what I want is a bit more complicated. I'll put it out for discussion later. maybe tonight. > It should be the other way around. Once a flow has been learned it's > just a simple hash-table lookup once you hit the first stateful rule. > In pf most packets bypass the rules altogether. > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 23 05:39:44 2014 Return-Path: Delivered-To: ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C62AAA58; Sun, 23 Mar 2014 05:39:44 +0000 (UTC) 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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9963AFC; Sun, 23 Mar 2014 05:39:44 +0000 (UTC) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s2N5dhC8002575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 22 Mar 2014 22:39:43 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <532E7398.5090607@freebsd.org> Date: Sat, 22 Mar 2014 22:39:36 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: RW , freebsd-security@freebsd.org, ipfw@FreeBSD.org Subject: Re: ipfw dynamic rules References: <51546.1395432085@server1.tristatelogic.com> <20140322182402.Q83569@sola.nimnet.asn.au> <201403221454.IAA22021@mail.lariat.net> <20140322151155.184d5229@gumby.homeunix.com> <532E723C.2090109@freebsd.org> In-Reply-To: <532E723C.2090109@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 05:39:44 -0000 reposting with a useful subject line and more comments On 3/22/14, 10:33 PM, Julian Elischer wrote: > > in ipfw that's up to you.. > but I usually put the check-state quite early in my rule sets. > On 3/22/14, 1:34 AM, Ian Smith wrote: > Firstly, that's the one page in the handbook (that I know of) that needs > completely nuking. It contains many factual errors as well as weird > notions, and will only tend to mislead you; consult ipfw(8) and prosper. > I'd say refer to the examples in rc.firewall but it too is in disrepair. I am working on a new rc.firewall that is much more efficient. the trouble is that the script to make it do what I want is a bit more complicated. I'll put it out for discussion later. maybe tonight. as for the handbook pages.. after we see how the new firewall rules work we can see about rewriting the page. From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 23 13:16:29 2014 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A44FECD; Sun, 23 Mar 2014 13:16:29 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E7CE08C6; Sun, 23 Mar 2014 13:16:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s2NDGQr2048012; Mon, 24 Mar 2014 00:16:26 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 24 Mar 2014 00:16:26 +1100 (EST) From: Ian Smith To: Julian Elischer Subject: Re: ipfw dynamic rules In-Reply-To: <532E7398.5090607@freebsd.org> Message-ID: <20140324000439.F87212@sola.nimnet.asn.au> References: <51546.1395432085@server1.tristatelogic.com> <20140322182402.Q83569@sola.nimnet.asn.au> <201403221454.IAA22021@mail.lariat.net> <20140322151155.184d5229@gumby.homeunix.com> <532E723C.2090109@freebsd.org> <532E7398.5090607@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-security@freebsd.org, RW , ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 13:16:29 -0000 On Sat, 22 Mar 2014 22:39:36 -0700, Julian Elischer wrote: > reposting with a useful subject line and more comments > > On 3/22/14, 10:33 PM, Julian Elischer wrote: > > > > in ipfw that's up to you.. > > but I usually put the check-state quite early in my rule sets. > > > On 3/22/14, 1:34 AM, Ian Smith wrote: > > Firstly, that's the one page in the handbook (that I know of) that needs > > completely nuking. It contains many factual errors as well as weird > > notions, and will only tend to mislead you; consult ipfw(8) and prosper. > > I'd say refer to the examples in rc.firewall but it too is in disrepair. Firstly, I owe an apology to the doc crew, one of whom contacted me privately to point out that the ipfw page has had quite a massaging lately, and work is ongoing. I'm sorry for not checking again first. > I am working on a new rc.firewall that is much more efficient. > the trouble is that the script to make it do what I want is a bit more > complicated. > I'll put it out for discussion later. maybe tonight. Great. Maybe my failed rc.firewall patch from '11 can still be useful. > as for the handbook pages.. after we see how the new firewall rules work > we can see about rewriting the page. Yes, well it seems there's a newer framework worth hanging it on now. I guess we should drop freebsd-security@ until there's some news? cheers, Ian From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 23 14:47:39 2014 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 618C93C3 for ; Sun, 23 Mar 2014 14:47:39 +0000 (UTC) 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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0AF9990 for ; Sun, 23 Mar 2014 14:47:38 +0000 (UTC) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s2NElaMT004253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 23 Mar 2014 07:47:37 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <532EF401.80506@freebsd.org> Date: Sun, 23 Mar 2014 07:47:29 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ian Smith Subject: Re: ipfw dynamic rules References: <51546.1395432085@server1.tristatelogic.com> <20140322182402.Q83569@sola.nimnet.asn.au> <201403221454.IAA22021@mail.lariat.net> <20140322151155.184d5229@gumby.homeunix.com> <532E723C.2090109@freebsd.org> <532E7398.5090607@freebsd.org> <20140324000439.F87212@sola.nimnet.asn.au> In-Reply-To: <20140324000439.F87212@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 14:47:39 -0000 On 3/23/14, 6:16 AM, Ian Smith wrote: > On Sat, 22 Mar 2014 22:39:36 -0700, Julian Elischer wrote: > > reposting with a useful subject line and more comments > > > > On 3/22/14, 10:33 PM, Julian Elischer wrote: > > > > > > in ipfw that's up to you.. > > > but I usually put the check-state quite early in my rule sets. > > > > > On 3/22/14, 1:34 AM, Ian Smith wrote: > > > Firstly, that's the one page in the handbook (that I know of) that needs > > > completely nuking. It contains many factual errors as well as weird > > > notions, and will only tend to mislead you; consult ipfw(8) and prosper. > > > I'd say refer to the examples in rc.firewall but it too is in disrepair. > > Firstly, I owe an apology to the doc crew, one of whom contacted me > privately to point out that the ipfw page has had quite a massaging > lately, and work is ongoing. I'm sorry for not checking again first. > > > I am working on a new rc.firewall that is much more efficient. > > the trouble is that the script to make it do what I want is a bit more > > complicated. > > I'll put it out for discussion later. maybe tonight. > > Great. Maybe my failed rc.firewall patch from '11 can still be useful. rather than show the script (for now) here's the generated output for a machine with 2 interfaces performing NAT on behalf of its bretheren inside. inside nets are covered in table1 table 2 specifies your DNS secondaries if you are serving dns as a primary. table 13 is all the addresses you should never put out.. or get. I run a very similar firewall on my machines but I'm generalising it. curious to see what people make of it :-) I haven't run this since I started rewriting the script so it may have errors. count the following: 1/ the number of rules any given packet traverses 2/ the number of tests done on each packet ('from any to any ' is no tests, from me to any is 1 test, 'from me to you' is 2 tests.) One if the things that drives me crazy with the current firewalls is that incoming and outgoing packets from multiple interfaces traverse the same rules, in the same direction. In this set each interface gets its own rules.. in the scripts they actually have their own files, which are included to give this aggregate ruleset. comments welcome (bugs expected) /sbin/ipfw table add 13 0.0.0.0/8 /sbin/ipfw table add 13 10.0.0.0/8 /sbin/ipfw table add 13 169.254.0.0/16 /sbin/ipfw table add 13 172.16.0.0/12 /sbin/ipfw table add 13 192.0.2.0/24 /sbin/ipfw table add 13 192.168.0.0/16 /sbin/ipfw table add 13 224.0.0.0/4 /sbin/ipfw table add 13 240.0.0.0/4 /sbin/sysctl net.inet.ip.fw.autoinc_step=2 /sbin/sysctl net.inet.ip.fw.default_to_accept=0 /sbin/sysctl net.inet.ip.fw.one_pass=0 /sbin/ipfw add 0 set 0 add pass ipv6-icmp from :: to ff02::/16 /sbin/ipfw add 2 set 0 add pass ipv6-icmp from fe80::/10 to fe80::/10 /sbin/ipfw add 4 set 0 add pass ipv6-icmp from fe80::/10 to ff02::/16 /sbin/ipfw add 6 set 0 add pass ipv6-icmp from any to any icmp6types 1 /sbin/ipfw add 8 set 0 add pass ipv6-icmp from any to any icmp6types 2,135,136 /sbin/ipfw add 500 set 0 skipto 1000 ip from any to any in recv lo0 /sbin/ipfw add 502 set 0 skipto 1500 ip from any to any out xmit lo0 /sbin/ipfw add 504 set 0 deny all from 127.0.0.1 to any /sbin/ipfw add 506 set 0 deny all from any to 127.0.0.1 /sbin/ipfw add 508 set deny all from any to ::1 /sbin/ipfw add 510 set deny all from ::1 to any /sbin/ipfw add 512 set 0 skipto 2000 ip from any to any in recv xn0 /sbin/ipfw add 514 set 0 skipto 2500 ip from any to any out xmit xn0 /sbin/ipfw add 516 set 0 skipto 3000 ip from any to any in recv xn1 /sbin/ipfw add 518 set 0 skipto 3500 ip from any to any out xmit xn1 /sbin/ipfw add 520 set 0 deny ip from any to any #lo0 rules /sbin/ipfw add 1000 set 0 allow all from any to any /sbin/ipfw add 1500 set 0 allow all from any to any #xn0 input packets /sbin/ipfw add 2000 set 0 skipto 2200 ip from any to MY_ADDR /sbin/ipfw add 2002 set 0 reject ip from any to table(13) /sbin/ipfw add 2004 set 0 allow udp from any to 255.255.255.255 /sbin/ipfw add 2006 set 0 allow udp from MY_NET to MY_BCASTADDR /sbin/ipfw add 2008 set 0 drop ip from any to any /sbin/ipfw add 2200 set 0 check-state /sbin/ipfw add 2202 set 0 reject ip from table(13) to any /sbin/ipfw add 2204 set 0 allow udp from any to any 53 keep-state /sbin/ipfw add 2206 set 0 allow tcp from table(2) to any setup 53 keep_state /sbin/ipfw add 2208 set 1 allow tcp from any to any 25,993,995,597,514,80,443 setup keep-state /sbin/ipfw add 2210 set 0 allow udp from any to any frag /sbin/ipfw add 2212 set 0 allow icmp from any to any keep-state /sbin/ipfw add 2214 set 3 nat 1 ip from any to any /sbin/ipfw add 2216 set 3 accept ip from any to table(1) /sbin/ipfw add 2218 set 0 drop ip from any to any #xn0 output packets /sbin/ipfw add 2500 set 0 skipto 2700 ip from MY_ADDR to any /sbin/ipfw add 2502 set 0 drop ip from not table(1) to any /sbin/ipfw add 2504 set 0 reject ip from any to table(13) /sbin/ipfw add 2506 set 3 nat 1 all from table(1) to any /sbin/ipfw add 2508 set 3 accept all from MY_ADDR to any /sbin/ipfw add 2510 set 0 drop ip from any to any /sbin/ipfw add 2700 set 0 check-state /sbin/ipfw add 2702 set 0 reject ip from any to table(13) /sbin/ipfw add 2704 set 0 allow tcp from any to any setup keep-state /sbin/ipfw add 2706 set 0 allow tcp from any to any established keep-state /sbin/ipfw add 2708 set 0 allow udp from any to any keep-state /sbin/ipfw add 2710 set 0 allow icmp from any to any keep-state /sbin/ipfw add 2712 set 0 drop ip from any to any #xn1 input packets /sbin/ipfw add 3000 set 0 skipto 3200 ip from any to 10.11.50.2 # to me? /sbin/ipfw add 3002 set 0 deny log ip from any to any /sbin/ipfw add 3200 set 0 check-state /sbin/ipfw add 3202 set 0 allow icmp from any to any icmptype 0,3,8 keep-state /sbin/ipfw add 3204 set 0 deny log ip from any to any xn1 output packets /sbin/ipfw add 3500 set 0 skipto 3700 ip from 10.11.50.2 to any # from me? /sbin/ipfw add 3502 set 0 deny log ip from any to any /sbin/ipfw add 3700 set 0 check-state /sbin/ipfw add 3702 set 0 allow tcp from any to any setup keep-state /sbin/ipfw add 3704 set 0 allow ip from any to any keep-state > > > as for the handbook pages.. after we see how the new firewall rules work > > we can see about rewriting the page. > > Yes, well it seems there's a newer framework worth hanging it on now. > > I guess we should drop freebsd-security@ until there's some news? > > cheers, Ian > From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 23 15:00:19 2014 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3BA5F71C; Sun, 23 Mar 2014 15:00:19 +0000 (UTC) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id C611E186; Sun, 23 Mar 2014 15:00:18 +0000 (UTC) Received: from Toshi.lariat.org (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id JAA00968; Sun, 23 Mar 2014 09:00:11 -0600 (MDT) Message-Id: <201403231500.JAA00968@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 23 Mar 2014 08:56:07 -0600 To: Julian Elischer , RW , freebsd-security@freebsd.org, ipfw@freebsd.org From: Brett Glass Subject: Re: URGENT? In-Reply-To: <532E723C.2090109@freebsd.org> References: <51546.1395432085@server1.tristatelogic.com> <20140322182402.Q83569@sola.nimnet.asn.au> <201403221454.IAA22021@mail.lariat.net> <20140322151155.184d5229@gumby.homeunix.com> <532E723C.2090109@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 15:00:19 -0000 At 11:33 PM 3/22/2014, Julian Elischer wrote: >in ipfw that's up to you.. >but I usually put the check-state quite early in my rule sets. I don't, because I want packets to touch as few rules as possible for the sake of efficiency. One "check state" can cause an awful lot of work to be done! In my IPFW rule sets, I divide the work up by interface, and so there's a "check-state" only for interfaces and directions (in vs. out) to which automatically generated rules will apply. The problem is that this is still inefficient, because there's only one batch of automatically generated rules, containing some that will never apply in certain situations. My rule sets would be more efficient if I could divide the automatically created rules into multiple batches, and do "keep-state N" and "check-state N" to check only the batch that needed to be tested in a particular spot. This ought to be a relatively easy patch, and I've thought many times about coding and submitting it. "N" would default to zero, so the old behavior would be preserved if there was no "N" at the end so as not to violate POLA. >I am working on a new rc.firewall that is much more efficient. >the trouble is that the script to make it do what I want is a bit >more complicated. >I'll put it out for discussion later. maybe tonight. Would like to see it! --Brett Glass From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 23 15:00:17 2014 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36CDE71A; Sun, 23 Mar 2014 15:00:17 +0000 (UTC) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0B4F2184; Sun, 23 Mar 2014 15:00:16 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 7966037B5AE; Sun, 23 Mar 2014 10:00:15 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3fsMMy6hLCz2DT; Sun, 23 Mar 2014 10:00:14 -0500 (CDT) Date: Sun, 23 Mar 2014 10:00:14 -0500 From: "Matthew D. Fuller" To: Julian Elischer Subject: Re: ipfw dynamic rules Message-ID: <20140323150014.GE96701@over-yonder.net> References: <51546.1395432085@server1.tristatelogic.com> <20140322182402.Q83569@sola.nimnet.asn.au> <201403221454.IAA22021@mail.lariat.net> <20140322151155.184d5229@gumby.homeunix.com> <532E723C.2090109@freebsd.org> <532E7398.5090607@freebsd.org> <20140324000439.F87212@sola.nimnet.asn.au> <532EF401.80506@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <532EF401.80506@freebsd.org> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.23 (2014-03-12) X-Virus-Scanned: clamav-milter 0.98.1 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: ipfw@freebsd.org, Ian Smith X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 15:00:17 -0000 On Sun, Mar 23, 2014 at 07:47:29AM -0700 I heard the voice of Julian Elischer, and lo! it spake thus: > > comments welcome (bugs expected) > > > /sbin/ipfw table add 13 0.0.0.0/8 > /sbin/ipfw table add 13 10.0.0.0/8 > /sbin/ipfw table add 13 169.254.0.0/16 > /sbin/ipfw table add 13 172.16.0.0/12 > /sbin/ipfw table add 13 192.0.2.0/24 > /sbin/ipfw table add 13 192.168.0.0/16 > /sbin/ipfw table add 13 224.0.0.0/4 > /sbin/ipfw table add 13 240.0.0.0/4 > > /sbin/ipfw add 2002 set 0 reject ip from any to table(13) Missing a couple martians, and this is a bit automatable. It's sh, after all. Out of the script on one of my servers: ---------------------- # A table for ipv4 martians # Source: http://www.team-cymru.org/Services/Bogons/bogon-bn-agg.txt # NOTE: Source file doesn't have terminating newline; be sure to add one! mtable="100" bogfile="${mydir}/bogon-bn-agg.txt" if [ -r "$bogfile" ]; then ${ipfw} table ${mtable} flush cat $bogfile | while read block ; do ${ipfw} table ${mtable} add ${block} ; done fi # ... lots of stuff elided # Ignore ${ipfw} add 1010 drop ip4 from table\(${mtable}\) to any ---------------------- Handy to just be able to randomly fetch(1) a new file and let the fw keep up. Though watch out for that lacking trailing newline; I've been left without 224.0.0.0/3 (save a slot, escew /4!) once or twice from forgetting. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 23 15:29:20 2014 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97B96217 for ; Sun, 23 Mar 2014 15:29:20 +0000 (UTC) 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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4EC395F9 for ; Sun, 23 Mar 2014 15:29:19 +0000 (UTC) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s2NFTGSk004386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 23 Mar 2014 08:29:17 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <532EFDC5.7060605@freebsd.org> Date: Sun, 23 Mar 2014 08:29:09 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Matthew D. Fuller" Subject: Re: ipfw dynamic rules References: <51546.1395432085@server1.tristatelogic.com> <20140322182402.Q83569@sola.nimnet.asn.au> <201403221454.IAA22021@mail.lariat.net> <20140322151155.184d5229@gumby.homeunix.com> <532E723C.2090109@freebsd.org> <532E7398.5090607@freebsd.org> <20140324000439.F87212@sola.nimnet.asn.au> <532EF401.80506@freebsd.org> <20140323150014.GE96701@over-yonder.net> In-Reply-To: <20140323150014.GE96701@over-yonder.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfw@freebsd.org, Ian Smith X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 15:29:20 -0000 On 3/23/14, 8:00 AM, Matthew D. Fuller wrote: > On Sun, Mar 23, 2014 at 07:47:29AM -0700 I heard the voice of > Julian Elischer, and lo! it spake thus: >> comments welcome (bugs expected) >> >> >> /sbin/ipfw table add 13 0.0.0.0/8 >> /sbin/ipfw table add 13 10.0.0.0/8 >> /sbin/ipfw table add 13 169.254.0.0/16 >> /sbin/ipfw table add 13 172.16.0.0/12 >> /sbin/ipfw table add 13 192.0.2.0/24 >> /sbin/ipfw table add 13 192.168.0.0/16 >> /sbin/ipfw table add 13 224.0.0.0/4 >> /sbin/ipfw table add 13 240.0.0.0/4 >> >> /sbin/ipfw add 2002 set 0 reject ip from any to table(13) > Missing a couple martians, and this is a bit automatable. It's sh, > after all. Out of the script on one of my servers: yeah though remember this is the output stream of the script, not the script itself.. it was loading it up from the small table I had in a "here" file in the script.. could easily be done from a separate file... What I'm hoping for is to make a script set where you specify a 'type' for each interface, and the script builds itself.. e.g. interfaces="xn0 xn1 tun0 tun1 lo0" fw_xn0_type="hostile nat" fw_xn1_type="trusted local fw_tun0_type="trusted remote" fw_tun1_type="hostile nat_in" (lo0 need not be given a type) this would firewall xn0 and tun1 and just do sanity testing on tun0 and xn1 Julian > > > ---------------------- > # A table for ipv4 martians > # Source: http://www.team-cymru.org/Services/Bogons/bogon-bn-agg.txt > # NOTE: Source file doesn't have terminating newline; be sure to add one! > mtable="100" > bogfile="${mydir}/bogon-bn-agg.txt" > if [ -r "$bogfile" ]; then > ${ipfw} table ${mtable} flush > cat $bogfile | while read block ; do > ${ipfw} table ${mtable} add ${block} ; > done > fi > > # ... lots of stuff elided > > # Ignore > ${ipfw} add 1010 drop ip4 from table\(${mtable}\) to any > ---------------------- > > > Handy to just be able to randomly fetch(1) a new file and let the fw > keep up. Though watch out for that lacking trailing newline; I've > been left without 224.0.0.0/3 (save a slot, escew /4!) once or twice > from forgetting. > > From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 23 15:47:44 2014 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DFA0198A; Sun, 23 Mar 2014 15:47:44 +0000 (UTC) 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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 96CD17E6; Sun, 23 Mar 2014 15:47:44 +0000 (UTC) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s2NFlgbD004437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 23 Mar 2014 08:47:43 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <532F0217.6050507@freebsd.org> Date: Sun, 23 Mar 2014 08:47:35 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Brett Glass , RW , freebsd-security@freebsd.org, ipfw@freebsd.org Subject: Re: URGENT? References: <51546.1395432085@server1.tristatelogic.com> <20140322182402.Q83569@sola.nimnet.asn.au> <201403221454.IAA22021@mail.lariat.net> <20140322151155.184d5229@gumby.homeunix.com> <532E723C.2090109@freebsd.org> <201403231500.JAA00968@mail.lariat.net> In-Reply-To: <201403231500.JAA00968@mail.lariat.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 15:47:44 -0000 On 3/23/14, 7:56 AM, Brett Glass wrote: > At 11:33 PM 3/22/2014, Julian Elischer wrote: > >> in ipfw that's up to you.. >> but I usually put the check-state quite early in my rule sets. > > I don't, because I want packets to touch as few rules as possible > for the sake of > efficiency. One "check state" can cause an awful lot of work to be > done! check state is a hash ;ookup and generally doesn't cause a lot of work. it's about the equivalent of 2 simple rules I would guess so if you save two rules by using check state, then you win. > > In my IPFW rule sets, I divide the work up by interface, and so > there's a > "check-state" only for interfaces and directions (in vs. out) to > which automatically > generated rules will apply. I do the same. first thing my rule set does is break the packet flow into N*4 separate sets of rules, where N is the number of interfaces. Each interface gets two sets of rules.. one for incoming and one for outgoing. each of these it further divided into two smaller sets. One for packets that are for or from THIS machine, and one that is for packets no for or from this machine) incoming, for me incoming NOT for me outgoing from me outgoing NOT from me each of these sets can then have rules. however since we know some of the information already it doesn't need to be tested again so the rules there tend to be "from any to any" because we already know who it's for (or from, depedning on the direction) > The problem is that this is still inefficient, because there's only > one batch of > automatically generated rules, containing some that will never apply > in certain > situations. My rule sets would be more efficient if I could divide > the automatically > created rules into multiple batches, and do "keep-state N" and > "check-state N" to check > only the batch that needed to be tested in a particular spot. This > ought to be a relatively > easy patch, and I've thought many times about coding and submitting > it. "N" would default > to zero, so the old behavior would be preserved if there was no "N" > at the end so as not > to violate POLA. > >> I am working on a new rc.firewall that is much more efficient. >> the trouble is that the script to make it do what I want is a bit >> more complicated. >> I'll put it out for discussion later. maybe tonight. > > Would like to see it! see other emails for sample output. > > --Brett Glass > > From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 23 17:08:29 2014 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 195D142E for ; Sun, 23 Mar 2014 17:08:29 +0000 (UTC) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D565EE0D for ; Sun, 23 Mar 2014 17:08:28 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id wp18so4671594obc.21 for ; Sun, 23 Mar 2014 10:08:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fhjBBYS/iRr2NrfvnzgMR1UIxfkUaQVV/5CTVNdkF9I=; b=kHwpA5NBACJBHiGSWHyV+E0wgteIfww/DK6WLiPb560HwWDYO6wuK7UnqHrMJpRy9i hNl0BCg6zXbszsLXp9yKybGBqlVi4pYGn+R3UxNVzecPk5gM7aYTj+zhWC+0iY4YlgSX /GY0k8gijegqKhXBk+OrJ+h5AMhnv8VuTRfg9PQmEThATydCdBReWYvktWNM9bq1Mdcs gJCaBJNtGQKxFIv1QBMOpgQYGzK/U1tWWnR54y6TlT0IId2MFwGpdeTkm0AYsDTI95Qe PB0drgr36yFC3zObmljlJVLxcs+B44De/icRDTxWjatt9wREXx1gNsBUtwC0pkqw0nZ2 3CdQ== X-Gm-Message-State: ALoCoQm5852uP/ByOCDrq48HYvoNJBoEvnT4TRUHBqrpFpJUtKGEl8mt/xmyNsc6x0hPbD9vMnDV MIME-Version: 1.0 X-Received: by 10.182.22.135 with SMTP id d7mr22460248obf.1.1395594501839; Sun, 23 Mar 2014 10:08:21 -0700 (PDT) Received: by 10.60.17.33 with HTTP; Sun, 23 Mar 2014 10:08:21 -0700 (PDT) In-Reply-To: <532EF401.80506@freebsd.org> References: <51546.1395432085@server1.tristatelogic.com> <20140322182402.Q83569@sola.nimnet.asn.au> <201403221454.IAA22021@mail.lariat.net> <20140322151155.184d5229@gumby.homeunix.com> <532E723C.2090109@freebsd.org> <532E7398.5090607@freebsd.org> <20140324000439.F87212@sola.nimnet.asn.au> <532EF401.80506@freebsd.org> Date: Sun, 23 Mar 2014 10:08:21 -0700 Message-ID: Subject: Re: ipfw dynamic rules From: Michael Sierchio To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-ipfw@freebsd.org" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 17:08:29 -0000 Thanks, Julian, this is sort of independent confirmation of something I've been doing. I've heard folks complain about efficiency of NAT (more so when using natd/DIVERT), and then saw that they matched every packet on a nat rule - 2 or 4 times. Some things I abstract from this: Use tables for lists of addresses where there's more than 5 or so. Use skipto (judiciously) Use stateless and stateful rules appropriately Stick to some convention for tables - 13 for bogons, 0 for whitelist RFC1918 addrs, 1 for whitelist public addrs, etc. Separate processing of packets coming in versus going out I have a function in the shell script that loads tables from named files - the contents of tables change without changing the ruleset Packets not destined for "me" will be processed again when they're headed out - you can "allow ip from any to any in" after filtering for the things you do/don't want for "me" - which is the norm for a firewall router protecting internal nets. This is, of course, after early drop for traffic that is obviously "bad" Use rulesets and matching tables to permit atomic table replacement with rule swap I also do policy-based routing with setfib and table arg, which means that as conditions change, I can send traffic from a particular net out a different interface. /sbin/ipfw add set 1 05000 setfib tablearg ip from table\(1\) to any in lookup src-ip 1 NAT is something that should happen first on all packets incoming on an if and last on packets headed out an if - with few exceptions. "Last" except for a final decision to pass or deny the traffic. - M From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 23 23:31:17 2014 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B89FB5BB for ; Sun, 23 Mar 2014 23:31:17 +0000 (UTC) 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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 92C09228 for ; Sun, 23 Mar 2014 23:31:17 +0000 (UTC) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s2NNVFpf005426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 23 Mar 2014 16:31:16 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <532F6EBF.9000802@freebsd.org> Date: Sun, 23 Mar 2014 16:31:11 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Michael Sierchio Subject: Re: ipfw dynamic rules References: <51546.1395432085@server1.tristatelogic.com> <20140322182402.Q83569@sola.nimnet.asn.au> <201403221454.IAA22021@mail.lariat.net> <20140322151155.184d5229@gumby.homeunix.com> <532E723C.2090109@freebsd.org> <532E7398.5090607@freebsd.org> <20140324000439.F87212@sola.nimnet.asn.au> <532EF401.80506@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-ipfw@freebsd.org" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 23:31:17 -0000 On 3/23/14, 10:08 AM, Michael Sierchio wrote: > Thanks, Julian, this is sort of independent confirmation of something > I've been doing. I've heard folks complain about efficiency of NAT > (more so when using natd/DIVERT), and then saw that they matched every > packet on a nat rule - 2 or 4 times. > > Some things I abstract from this: > > Use tables for lists of addresses where there's more than 5 or so. I think tables are not as expensive as people think.. it's basically a single routing table lookup. The funtionality added by allowing rule sets to stay, while changing behaviour makes it worth using them even with 1 or 0 entries. We really should try profile ipfw.. I've never done that.. any profiling experts on the list? :-) I have not got my head fully around the lookup command yet or using interfaces as table keys (I can't use that at work in 8.0 anyhow) ipfw add 100 ipfw skipto tablearg ip from any to any recv 'table(10)' in but we should see if it gives us any performance advantage over a simple hardcoded filter like I used in my set. I'd also like to have a number of local variables that you can set on each packet.. tags come close and maybe we should look to see what they can do for us, but > > Use skipto (judiciously) In static rulesets, skipto is fast since they are not 'computed' the destination is cached, and the cache is only cleared when new rules are added or removed. using a tablearg for a skipto is unfortunately not so good as it can not cache the result and must therefore actually traverse the set looking for the target. (unless someone has added a table for rules that I missed since I last loooked.) > > Use stateless and stateful rules appropriately Basically in my experience, you can not use stateful behaviour on sessions that use NAT, So you need to separate them out. However you still get statefull behaviour because libalias uses a similar state table internally, meaning that incoming packets must match some session already started in an outgoing direction, or a specifically re-arranged translation. I would really like to have multiple state tables as mentioned earlier.. another thing for the 'todo' file I guess, or maybe the ability to add an entry to a table dynamically.. # stash away the address of our ntp servers in table 3 e.g. ipfw add 1000 table_add_dest 3 udp from me to any 123 out xmit xn0 > > Stick to some convention for tables - 13 for bogons, 0 for whitelist > RFC1918 addrs, 1 for whitelist public addrs, etc. we could make such a standard doc.. and put it in the rc.firewall code speaks loudest. > > Separate processing of packets coming in versus going out I really think this is important. rule requirements are very different for in and out. I further divide each into "for us" or "for other" on incoming, and "from us" or "from other" on outgoing. these rulesets are also usually very different. One difficulty I have thugh is handling alias addresses, and packets that have been redirected to go out an interface that doesn't match the from address it has, even though it was locally generated. I haven't found a way to say "was locally generated" other than "from me" which is expensive.. "me" is a fairly expensive lookup, and depends on a field that could have come from externally, (unless one has good anti-spoof rules in place early in the set I guess. > > > I have a function in the shell script that loads tables fro named > files - the contents of tables change without changing the ruleset. yes, a good reason to use tables. > > Packets not destined for "me" will be processed again when they're > headed out - you can "allow ip from any to any in" after filtering for > the things you do/don't want for "me" - which is the norm for a > firewall router protecting internal nets. This is, of course, after > early drop for traffic that is obviously "bad" I only do this on 'trusted' interfaces. I tend to trust on outgoing and filter on incoming more. but it's an interesting thought. I hadn't really considered that. another nice -to-have would be a filter point for routed traffic, just as it is routed.. (see the diagram in the man page). it's possible we could simulateit on output if we could see if packets have been routed or not, sort of the inverse of the "locally generated" test. > > Use rulesets and matching tables to permit atomic table replacement > with rule swap I do this.. at $JOB I just wrote an ipfw set that is the same regardless of which configuration teh device is put in but rules come and go using set enable/disable as options are turned on/off. but disabled rules still have a cost I believe as hey still need to be traversed, unless someone has been very smart.. > > I also do policy-based routing with setfib and table arg, which means > that as conditions change, I can send traffic from a particular net > out a different interface. It's a pitty that you need to do policy based routing only on input, as output packets are already past their routing decision. The 'fwd' rule can however sometimes be used later. > > /sbin/ipfw add set 1 05000 setfib tablearg ip from table\(1\) to any > in lookup src-ip 1 yes there is a reason I added fibs, and the ipfw rules to manipulate packet fibs. :-) > NAT is something that should happen first on all packets incoming on > an if and last on packets headed out an if - with few exceptions. > "Last" except for a final decision to pass or deny the traffic. I find that you can bypass NAT for all locally generated sessions by having local packet rules before the NAT. depending on whether the machine in question is a large user of the internet, or just a router, that may be a big saving or not. > > - M > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 24 00:14:38 2014 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 023DB5CF for ; Mon, 24 Mar 2014 00:14:38 +0000 (UTC) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BBBDB7EC for ; Mon, 24 Mar 2014 00:14:37 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id l6so5031844oag.39 for ; Sun, 23 Mar 2014 17:14:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=2+uMSV1QbmXiyPIuLARnFBRrMcinkiTtDlHzy4q+9Js=; b=Sox8rnYR01jLs8okHKnUYCNdGRHfEbI2rpwPPEq1xpCgZMBkHWHqlRdSp6e7Yfj/1C UtwPevsx7vTWsNoTFnKzKJY6Bcog6H1Ped8ufsVO855o+L4Tb2qncVP+ecgPXBcpoSB/ Xougl07dRvF0fsW45+Mmb+3uRYx2S/vur4teMqcceWqea6hIKxdOGFZE6GpLJqOonQ70 qXYnk/bDFpihGJ249EiF30weinWfWr0s/Q3Ze/C1l56uk5sFHHIF41SFTPfaxCNCcsIq VgzihPC5fY5rdEE7pGleVZ0PgfTMR3ILyTaXAcS4NLaYYhjDEXcSMGXT9f45WDeRxCug IwKw== X-Gm-Message-State: ALoCoQmxJ0wdQVPoZLBnzp0nRjLpMM593KmyE5u+AWdbCkDN0CijQX7EJ2fGDg0vRJGJ5n75Hwh+ MIME-Version: 1.0 X-Received: by 10.60.232.105 with SMTP id tn9mr53590208oec.11.1395620071619; Sun, 23 Mar 2014 17:14:31 -0700 (PDT) Received: by 10.60.17.33 with HTTP; Sun, 23 Mar 2014 17:14:31 -0700 (PDT) In-Reply-To: <532F6EBF.9000802@freebsd.org> References: <51546.1395432085@server1.tristatelogic.com> <20140322182402.Q83569@sola.nimnet.asn.au> <201403221454.IAA22021@mail.lariat.net> <20140322151155.184d5229@gumby.homeunix.com> <532E723C.2090109@freebsd.org> <532E7398.5090607@freebsd.org> <20140324000439.F87212@sola.nimnet.asn.au> <532EF401.80506@freebsd.org> <532F6EBF.9000802@freebsd.org> Date: Sun, 23 Mar 2014 17:14:31 -0700 Message-ID: Subject: Re: ipfw dynamic rules From: Michael Sierchio To: "freebsd-ipfw@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 00:14:38 -0000 On Sun, Mar 23, 2014 at 4:31 PM, Julian Elischer wrote: > but disabled rules still have a cost I believe as hey still need to be > traversed, > unless someone has been very smart.. This I did not know. I don't have many, but it's a small disappointment, if true. > It's a pitty that you need to do policy based routing only on input, > as output packets are already past their routing decision. > The 'fwd' rule can however sometimes be used later. Agreed. From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 24 00:25:00 2014 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E94EB57 for ; Mon, 24 Mar 2014 00:25:00 +0000 (UTC) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 128968BB for ; Mon, 24 Mar 2014 00:24:59 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id w7so3136225lbi.16 for ; Sun, 23 Mar 2014 17:24:57 -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:date:message-id:subject :from:to:cc:content-type; bh=G0WwpoLX5uHi3EUvnRjs6M7+slSh/lfmoLb7R2gXm9c=; b=ytCtwblBE/ZoTSWFH/gZplN1l2kT6RSMB3rT4z9KptvwXRmsOTWvkox+S5UMRFVJby J08hvHwtNUwyl0DgI9eAFr8aieecyJcKzXTyssEFkKAFy/wRUP5Ypgm+2mqt6CmDvY4P xb5FQYFp7gemF9+tS6JDkt0Sby9tInICnO3mbQcscK9jhycsL5uAwEDNq88nYcIG0RO9 Sc4sCdM6gKmb+jcHNTvjPJ113gSWvPhdbnTj6F9fXhNHNw6v+ypqAjY9F+SzR2BPg/U5 UmGwT+e4/pUaAlKv0IYm0/dLZjT5hYO+wbGqvyz22IqQyQsUW/KcQS/c6qvPmKxBDXhZ AsTQ== MIME-Version: 1.0 X-Received: by 10.112.163.69 with SMTP id yg5mr21729411lbb.14.1395620697809; Sun, 23 Mar 2014 17:24:57 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.107 with HTTP; Sun, 23 Mar 2014 17:24:57 -0700 (PDT) In-Reply-To: References: <51546.1395432085@server1.tristatelogic.com> <20140322182402.Q83569@sola.nimnet.asn.au> <201403221454.IAA22021@mail.lariat.net> <20140322151155.184d5229@gumby.homeunix.com> <532E723C.2090109@freebsd.org> <532E7398.5090607@freebsd.org> <20140324000439.F87212@sola.nimnet.asn.au> <532EF401.80506@freebsd.org> <532F6EBF.9000802@freebsd.org> Date: Mon, 24 Mar 2014 01:24:57 +0100 X-Google-Sender-Auth: jaUFiIsBqDzet-61xmtOLgN95r0 Message-ID: Subject: Re: ipfw dynamic rules From: Luigi Rizzo To: Michael Sierchio Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-ipfw@freebsd.org" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 00:25:00 -0000 On Mon, Mar 24, 2014 at 1:14 AM, Michael Sierchio wrote: > On Sun, Mar 23, 2014 at 4:31 PM, Julian Elischer > wrote: > > > but disabled rules still have a cost I believe as hey still need to be > > traversed, > > unless someone has been very smart.. > > This I did not know. I don't have many, but it's a small > disappointment, if true. > skipto is at most log(n) in the number of rules. cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 24 05:17:43 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F8FB181 for ; Mon, 24 Mar 2014 05:17:43 +0000 (UTC) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5EEF997 for ; Mon, 24 Mar 2014 05:17:43 +0000 (UTC) Received: by mail-qc0-f175.google.com with SMTP id e16so5288245qcx.6 for ; Sun, 23 Mar 2014 22:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=KDOVZ3EbxxP4QS+ORaILMn1MqEjhcXZobU7rCrB1gn4=; b=rJJM37MpthTHGD0MdwcEoTuQ2/kiqGg9MgoShsw6A7LIk5+H4EvkHOc2YNuhuUqNmX y2RwnS/B+dZr4W5djs15JLIdLmR8cTyM3HPNrRofN24u5j41O1v+Dt+nGT6VVXn5ByZr HEj/h/8DAd3aM/g9d4U6wIosC76eALcLnsmzLmeQK67rA1kQXDGymg6aGSY11eaDpQMt TiBmX/2/udQk8qj62FxD3n6/OMyap1B2Qdk9nXrAPU2Ea3E+FwPom2qUQLX8sobP1zaz tHrtlyItlSz3+cKxARY+XcZ6OuluBVlIvxgj9OoofzTCMWGo/ALrcL1wlzMPp5MGWvab n+QQ== MIME-Version: 1.0 X-Received: by 10.140.47.203 with SMTP id m69mr68977164qga.21.1395638262534; Sun, 23 Mar 2014 22:17:42 -0700 (PDT) Received: by 10.224.191.66 with HTTP; Sun, 23 Mar 2014 22:17:42 -0700 (PDT) Date: Mon, 24 Mar 2014 13:17:42 +0800 Message-ID: Subject: Ping No buffer space with Dummynet From: Niu Zhixiong To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 05:17:43 -0000 Dear all, I meet a problem that is ping another machine with Dummynet(bw 1Mbit/s delay=3D10ms and plr=3D0.10). It says ping: sendto: No buffer space availab= le. I changed kern.ipc.nmbclusters and kern.ipc.nsfbufs from default to 32768. The problem still happens. PING 192.168.8.110 (192.168.8.110): 56 data bytes 64 bytes from 192.168.8.110: icmp_seq=3D0 ttl=3D64 time=3D20.898 ms 64 bytes from 192.168.8.110: icmp_seq=3D1 ttl=3D64 time=3D22.233 ms 64 bytes from 192.168.8.110: icmp_seq=3D2 ttl=3D64 time=3D22.163 ms 64 bytes from 192.168.8.110: icmp_seq=3D3 ttl=3D64 time=3D21.883 ms 64 bytes from 192.168.8.110: icmp_seq=3D4 ttl=3D64 time=3D21.917 ms 64 bytes from 192.168.8.110: icmp_seq=3D5 ttl=3D64 time=3D21.215 ms 64 bytes from 192.168.8.110: icmp_seq=3D6 ttl=3D64 time=3D21.926 ms 64 bytes from 192.168.8.110: icmp_seq=3D7 ttl=3D64 time=3D23.918 ms 64 bytes from 192.168.8.110: icmp_seq=3D8 ttl=3D64 time=3D21.855 ms ping: sendto: No buffer space available 64 bytes from 192.168.8.110: icmp_seq=3D10 ttl=3D64 time=3D22.941 ms ping: sendto: No buffer space available 64 bytes from 192.168.8.110: icmp_seq=3D12 ttl=3D64 time=3D21.938 ms 64 bytes from 192.168.8.110: icmp_seq=3D13 ttl=3D64 time=3D21.761 ms 64 bytes from 192.168.8.110: icmp_seq=3D14 ttl=3D64 time=3D22.911 ms 64 bytes from 192.168.8.110: icmp_seq=3D15 ttl=3D64 time=3D21.877 ms 64 bytes from 192.168.8.110: icmp_seq=3D16 ttl=3D64 time=3D21.919 ms 64 bytes from 192.168.8.110: icmp_seq=3D17 ttl=3D64 time=3D21.922 ms The command I use kldload dummynet sysctl net.inet.sctp.cmt_on_off=3D1 ipfw add 400 pipe 1 ip from 192.168.6.0/24. to 192.168.6.0/24 ipfw add 400 pipe 2 ip from 192.168.8.0/24 to 192.168.8.0/24 ipfw pipe 1 config delay 10ms queue 50 bw 10Mbit/s plr 0 ipfw pipe 2 config delay 10ms queue 50 bw 1Mbit/s plr 0.10 ping 192.168.8.110 (pipe2 plr =3D 0.10) will display ping: sendto: No buffer space available ping 192.168.6.110(pipe1 plr=3D0) is OK Did packet loss leads that? is it normal? system parameters are as following uname -a FreeBSD freetest0 10.0-RELEASE FreeBSD 10.0-RELEASE #0: Sun Mar 23 14:13:36 HKT 2014 root@freetest0:/mirror/usr/src/sys/i386/compile/HZ1000_NO_SCTP= _DEBUG i386 cat /mirror/usr/src/sys/i386/conf/HZ1000_NO_SCTP_DEBUG include GENERIC ident MYKERNEL #options SCTP_DEBUG options HZ=3D1000 sysctl -a net.inet net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.first: 10000 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.randomized: 1 net.inet.ip.portrange.randomcps: 10 net.inet.ip.portrange.randomtime: 45 net.inet.ip.forwarding: 0 net.inet.ip.redirect: 1 net.inet.ip.ttl: 64 net.inet.ip.rtexpire: 3600 net.inet.ip.rtminexpire: 10 net.inet.ip.rtmaxcache: 128 net.inet.ip.sourceroute: 0 net.inet.ip.intr_queue_maxlen: 256 net.inet.ip.intr_queue_drops: 0 net.inet.ip.accept_sourceroute: 0 net.inet.ip.keepfaith: 0 net.inet.ip.gifttl: 30 net.inet.ip.no_same_prefix: 0 net.inet.ip.random_id_period: 8192 net.inet.ip.random_id_collisions: 0 net.inet.ip.random_id_total: 0 net.inet.ip.mcast.maxgrpsrc: 512 net.inet.ip.mcast.maxsocksrc: 128 net.inet.ip.mcast.loop: 1 net.inet.ip.fastforwarding: 0 net.inet.ip.sendsourcequench: 0 net.inet.ip.random_id: 0 net.inet.ip.check_interface: 0 net.inet.ip.fragpackets: 0 net.inet.ip.maxfragsperpacket: 16 net.inet.ip.maxfragpackets: 1024 net.inet.ip.process_options: 1 net.inet.ip.fw.one_pass: 1 net.inet.ip.fw.autoinc_step: 100 net.inet.ip.fw.verbose: 0 net.inet.ip.fw.verbose_limit: 0 net.inet.ip.fw.default_rule: 65535 net.inet.ip.fw.tables_max: 128 net.inet.ip.fw.default_to_accept: 0 net.inet.ip.fw.static_count: 14 net.inet.ip.fw.enable: 1 net.inet.ip.fw.dyn_buckets: 256 net.inet.ip.fw.curr_dyn_buckets: 256 net.inet.ip.fw.dyn_count: 0 net.inet.ip.fw.dyn_max: 4096 net.inet.ip.fw.dyn_ack_lifetime: 300 net.inet.ip.fw.dyn_syn_lifetime: 20 net.inet.ip.fw.dyn_fin_lifetime: 1 net.inet.ip.fw.dyn_rst_lifetime: 1 net.inet.ip.fw.dyn_udp_lifetime: 10 net.inet.ip.fw.dyn_short_lifetime: 5 net.inet.ip.fw.dyn_keepalive: 1 net.inet.ip.dummynet.hash_size: 64 net.inet.ip.dummynet.pipe_slot_limit: 100 net.inet.ip.dummynet.pipe_byte_limit: 1048576 net.inet.ip.dummynet.io_fast: 0 net.inet.ip.dummynet.debug: 0 net.inet.ip.dummynet.red_lookup_depth: 256 net.inet.ip.dummynet.red_avg_pkt_size: 512 net.inet.ip.dummynet.red_max_pkt_size: 1500 net.inet.ip.dummynet.tick_delta: 4 net.inet.ip.dummynet.tick_delta_sum: -184 net.inet.ip.dummynet.tick_adjustment: 13988 net.inet.ip.dummynet.tick_diff: 16350 net.inet.ip.dummynet.tick_lost: 0 net.inet.ip.dummynet.expire: 1 net.inet.ip.dummynet.expire_cycle: 0 net.inet.ip.dummynet.schk_count: 4 net.inet.ip.dummynet.si_count: 0 net.inet.ip.dummynet.fsk_count: 2 net.inet.ip.dummynet.queue_count: 0 net.inet.ip.dummynet.io_pkt: 192 net.inet.ip.dummynet.io_pkt_fast: 0 net.inet.ip.dummynet.io_pkt_drop: 6 net.inet.icmp.maskrepl: 0 net.inet.icmp.icmplim: 200 net.inet.icmp.icmplim_output: 1 net.inet.icmp.maskfake: 0 net.inet.icmp.log_redirect: 0 net.inet.icmp.reply_src: net.inet.icmp.reply_from_interface: 0 net.inet.icmp.quotelen: 8 net.inet.icmp.bmcastecho: 0 net.inet.icmp.drop_redirect: 0 net.inet.igmp.recvifkludge: 1 net.inet.igmp.sendra: 1 net.inet.igmp.sendlocal: 1 net.inet.igmp.v1enable: 1 net.inet.igmp.v2enable: 1 net.inet.igmp.legacysupp: 0 net.inet.igmp.default_version: 3 net.inet.igmp.gsrdelay: 10 net.inet.tcp.rfc1323: 1 net.inet.tcp.mssdflt: 536 net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 32768 net.inet.tcp.recvspace: 65536 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.v6mssdflt: 1220 net.inet.tcp.cc.algorithm: newreno net.inet.tcp.cc.available: newreno net.inet.tcp.hostcache.cachelimit: 15360 net.inet.tcp.hostcache.hashsize: 512 net.inet.tcp.hostcache.bucketlimit: 30 net.inet.tcp.hostcache.count: 0 net.inet.tcp.hostcache.expire: 3600 net.inet.tcp.hostcache.prune: 300 net.inet.tcp.hostcache.purge: 0 net.inet.tcp.log_in_vain: 0 net.inet.tcp.blackhole: 0 net.inet.tcp.delayed_ack: 1 net.inet.tcp.drop_synfin: 0 net.inet.tcp.rfc3042: 1 net.inet.tcp.rfc3390: 1 net.inet.tcp.experimental.initcwnd10: 1 net.inet.tcp.rfc3465: 1 net.inet.tcp.abc_l_var: 2 net.inet.tcp.ecn.enable: 0 net.inet.tcp.ecn.maxretries: 1 net.inet.tcp.insecure_rst: 0 net.inet.tcp.recvbuf_auto: 1 net.inet.tcp.recvbuf_inc: 16384 net.inet.tcp.recvbuf_max: 2097152 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.tso: 1 net.inet.tcp.sendbuf_auto: 1 net.inet.tcp.sendbuf_inc: 8192 net.inet.tcp.sendbuf_max: 2097152 net.inet.tcp.reass.maxsegments: 2222 net.inet.tcp.reass.cursegments: 0 net.inet.tcp.reass.overflows: 0 net.inet.tcp.sack.enable: 1 net.inet.tcp.sack.maxholes: 128 net.inet.tcp.sack.globalmaxholes: 65536 net.inet.tcp.sack.globalholes: 0 net.inet.tcp.minmss: 216 net.inet.tcp.log_debug: 0 net.inet.tcp.tcbhashsize: 32768 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.pcbcount: 5 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.soreceive_stream: 0 net.inet.tcp.syncookies: 1 net.inet.tcp.syncookies_only: 0 net.inet.tcp.syncache.bucketlimit: 30 net.inet.tcp.syncache.cachelimit: 15360 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.msl: 30000 net.inet.tcp.rexmit_min: 30 net.inet.tcp.rexmit_slop: 200 net.inet.tcp.always_keepalive: 1 net.inet.tcp.fast_finwait2_recycle: 0 net.inet.tcp.finwait2_timeout: 60000 net.inet.tcp.keepcnt: 8 net.inet.tcp.rexmit_drop_options: 0 net.inet.tcp.per_cpu_timers: 0 net.inet.tcp.timer_race: 0 net.inet.tcp.maxtcptw: 20349 net.inet.tcp.nolocaltimewait: 0 net.inet.udp.checksum: 1 net.inet.udp.maxdgram: 9216 net.inet.udp.recvspace: 42080 net.inet.udp.log_in_vain: 0 net.inet.udp.blackhole: 0 net.inet.sctp.sendspace: 1864135 net.inet.sctp.recvspace: 1864135 net.inet.sctp.auto_asconf: 1 net.inet.sctp.ecn_enable: 1 net.inet.sctp.strict_sacks: 1 net.inet.sctp.peer_chkoh: 256 net.inet.sctp.maxburst: 4 net.inet.sctp.fr_maxburst: 4 net.inet.sctp.maxchunks: 4096 net.inet.sctp.tcbhashsize: 1024 net.inet.sctp.pcbhashsize: 256 net.inet.sctp.min_split_point: 2904 net.inet.sctp.chunkscale: 10 net.inet.sctp.delayed_sack_time: 200 net.inet.sctp.sack_freq: 2 net.inet.sctp.sys_resource: 1000 net.inet.sctp.asoc_resource: 10 net.inet.sctp.heartbeat_interval: 30000 net.inet.sctp.pmtu_raise_time: 600 net.inet.sctp.shutdown_guard_time: 180 net.inet.sctp.secret_lifetime: 3600 net.inet.sctp.rto_max: 60000 net.inet.sctp.rto_min: 1000 net.inet.sctp.rto_initial: 3000 net.inet.sctp.init_rto_max: 60000 net.inet.sctp.valid_cookie_life: 60000 net.inet.sctp.init_rtx_max: 8 net.inet.sctp.assoc_rtx_max: 10 net.inet.sctp.path_rtx_max: 5 net.inet.sctp.path_pf_threshold: 65535 net.inet.sctp.add_more_on_output: 1452 net.inet.sctp.incoming_streams: 2048 net.inet.sctp.outgoing_streams: 10 net.inet.sctp.cmt_on_off: 1 net.inet.sctp.nr_sack_on_off: 0 net.inet.sctp.cmt_use_dac: 0 net.inet.sctp.cwnd_maxburst: 1 net.inet.sctp.asconf_auth_nochk: 0 net.inet.sctp.auth_disable: 0 net.inet.sctp.nat_friendly: 1 net.inet.sctp.abc_l_var: 2 net.inet.sctp.max_chained_mbufs: 5 net.inet.sctp.do_sctp_drain: 1 net.inet.sctp.hb_max_burst: 4 net.inet.sctp.abort_at_limit: 0 net.inet.sctp.strict_data_order: 0 net.inet.sctp.min_residual: 1452 net.inet.sctp.max_retran_chunk: 30 net.inet.sctp.log_level: 0 net.inet.sctp.default_cc_module: 0 net.inet.sctp.default_ss_module: 0 net.inet.sctp.default_frag_interleave: 1 net.inet.sctp.mobility_base: 0 net.inet.sctp.mobility_fasthandoff: 0 net.inet.sctp.udp_tunneling_port: 0 net.inet.sctp.enable_sack_immediately: 0 net.inet.sctp.nat_friendly_init: 0 net.inet.sctp.vtag_time_wait: 60 net.inet.sctp.buffer_splitting: 0 net.inet.sctp.initial_cwnd: 3 net.inet.sctp.rttvar_bw: 4 net.inet.sctp.rttvar_rtt: 5 net.inet.sctp.rttvar_eqret: 0 net.inet.sctp.rttvar_steady_step: 20 net.inet.sctp.use_dcccecn: 1 net.inet.sctp.blackhole: 0 net.inet.raw.maxdgram: 9216 net.inet.raw.recvspace: 9216 net.inet.accf.unloadable: 0 Regards, Niu Zhixiong =EF=BC=8D=EF=BC=8D=EF=BC=8D=EF=BC=8D=EF=BC=8D=EF=BC=8D=EF=BC=8D=EF=BC=8D=EF= =BC=8D=EF=BC=8D=EF=BC=8D=EF=BC=8D=EF=BC=8D=EF=BC=8D=EF=BC=8D kaiaixi@gmail.com From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 24 11:06:47 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0AD7EFA2 for ; Mon, 24 Mar 2014 11:06:47 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EBA62170 for ; Mon, 24 Mar 2014 11:06:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2OB6kti013882 for ; Mon, 24 Mar 2014 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2OB6kdj013879 for freebsd-ipfw@FreeBSD.org; Mon, 24 Mar 2014 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Mar 2014 11:06:46 GMT Message-Id: <201403241106.s2OB6kdj013879@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 11:06:47 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/180731 ipfw [ipfw] problem with displaying 255.255.255.255 address o kern/180729 ipfw [ipfw] ipfw nat show empty output o kern/178482 ipfw [ipfw] logging problem from vnet jail o kern/178480 ipfw [ipfw] dynamically loaded ipfw with a vimage kernel do o kern/178317 ipfw [ipfw] ipfw options need to specifed in specific order o kern/177948 ipfw [ipfw] ipfw fails to parse port ranges (p1-p2) for udp o kern/176503 ipfw [ipfw] ipfw layer2 problem o conf/167822 ipfw [ipfw] [patch] start script doesn't load firewall_type o kern/166406 ipfw [ipfw] ipfw does not set ALTQ identifier for ipv6 traf o kern/165939 ipfw [ipfw] bug: incomplete firewall rules loaded if tables o kern/165190 ipfw [ipfw] [lo] [patch] loopback interface is not marking o kern/158066 ipfw [ipfw] ipfw + netgraph + multicast = multicast packets o kern/157689 ipfw [ipfw] ipfw nat config does not accept nonexistent int f kern/155927 ipfw [ipfw] ipfw stops to check packets for compliance with o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw [ipfw] does not support specifying rules with ICMP cod o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. f kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l f kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes s kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 41 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 24 18:34:15 2014 Return-Path: Delivered-To: freebsd-ipfw@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57FE4110; Mon, 24 Mar 2014 18:34:15 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2B46CA32; Mon, 24 Mar 2014 18:34:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2OIYEU0058138; Mon, 24 Mar 2014 18:34:14 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2OIYE3A058137; Mon, 24 Mar 2014 18:34:14 GMT (envelope-from linimon) Date: Mon, 24 Mar 2014 18:34:14 GMT Message-Id: <201403241834.s2OIYE3A058137@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: bin/187904: [ipfw] ipfw(8) does not properly recognize the network in shorthand [regression] X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 18:34:15 -0000 Old Synopsis: ipfw (8) does not properly recognize the network in shorthand New Synopsis: [ipfw] ipfw(8) does not properly recognize the network in shorthand [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Mon Mar 24 18:33:04 UTC 2014 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=187904 From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 31 11:06:46 2014 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F37FD9AA for ; Mon, 31 Mar 2014 11:06:45 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 E0B27B9C for ; Mon, 31 Mar 2014 11:06:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2VB6jUB058716 for ; Mon, 31 Mar 2014 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2VB6j4n058714 for freebsd-ipfw@FreeBSD.org; Mon, 31 Mar 2014 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 31 Mar 2014 11:06:45 GMT Message-Id: <201403311106.s2VB6j4n058714@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 11:06:46 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/187904 ipfw [ipfw] ipfw(8) does not properly recognize the network o kern/180731 ipfw [ipfw] problem with displaying 255.255.255.255 address o kern/180729 ipfw [ipfw] ipfw nat show empty output o kern/178482 ipfw [ipfw] logging problem from vnet jail o kern/178480 ipfw [ipfw] dynamically loaded ipfw with a vimage kernel do o kern/178317 ipfw [ipfw] ipfw options need to specifed in specific order o kern/177948 ipfw [ipfw] ipfw fails to parse port ranges (p1-p2) for udp o kern/176503 ipfw [ipfw] ipfw layer2 problem o conf/167822 ipfw [ipfw] [patch] start script doesn't load firewall_type o kern/166406 ipfw [ipfw] ipfw does not set ALTQ identifier for ipv6 traf o kern/165939 ipfw [ipfw] bug: incomplete firewall rules loaded if tables o kern/165190 ipfw [ipfw] [lo] [patch] loopback interface is not marking o kern/158066 ipfw [ipfw] ipfw + netgraph + multicast = multicast packets o kern/157689 ipfw [ipfw] ipfw nat config does not accept nonexistent int f kern/155927 ipfw [ipfw] ipfw stops to check packets for compliance with o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw [ipfw] does not support specifying rules with ICMP cod o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. f kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l f kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes s kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 42 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Apr 7 11:06:46 2014 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD0E2A7A for ; Mon, 7 Apr 2014 11:06:45 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 BE44ABF5 for ; Mon, 7 Apr 2014 11:06:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s37B6jj9071085 for ; Mon, 7 Apr 2014 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s37B6jsD071083 for freebsd-ipfw@FreeBSD.org; Mon, 7 Apr 2014 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 7 Apr 2014 11:06:45 GMT Message-Id: <201404071106.s37B6jsD071083@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 11:06:46 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/187904 ipfw [ipfw] ipfw(8) does not properly recognize the network o kern/180731 ipfw [ipfw] problem with displaying 255.255.255.255 address o kern/180729 ipfw [ipfw] ipfw nat show empty output o kern/178482 ipfw [ipfw] logging problem from vnet jail o kern/178480 ipfw [ipfw] dynamically loaded ipfw with a vimage kernel do o kern/178317 ipfw [ipfw] ipfw options need to specifed in specific order o kern/177948 ipfw [ipfw] ipfw fails to parse port ranges (p1-p2) for udp o kern/176503 ipfw [ipfw] ipfw layer2 problem o conf/167822 ipfw [ipfw] [patch] start script doesn't load firewall_type o kern/166406 ipfw [ipfw] ipfw does not set ALTQ identifier for ipv6 traf o kern/165939 ipfw [ipfw] bug: incomplete firewall rules loaded if tables o kern/165190 ipfw [ipfw] [lo] [patch] loopback interface is not marking o kern/158066 ipfw [ipfw] ipfw + netgraph + multicast = multicast packets o kern/157689 ipfw [ipfw] ipfw nat config does not accept nonexistent int f kern/155927 ipfw [ipfw] ipfw stops to check packets for compliance with o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw [ipfw] does not support specifying rules with ICMP cod o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. f kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l f kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes s kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 42 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Fri Apr 11 01:14:25 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC006BDA for ; Fri, 11 Apr 2014 01:14:25 +0000 (UTC) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) (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 A17411B9E for ; Fri, 11 Apr 2014 01:14:25 +0000 (UTC) Received: by mail-pb0-f47.google.com with SMTP id up15so4694950pbc.34 for ; Thu, 10 Apr 2014 18:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:mime-version:message-id:content-type; bh=+uFstPdFeMjjpLWyWQNFL0vtoyv2THuszDrZsgFtz2g=; b=yY+XxcE74xzgQoJeOxglh5OS/FRDacOqIBgOL2bASRqsw6IVdkcGOu4IiLGGrtfZt8 17x3iecslFxPoJOkGulHr+h3QnIubcmVUhOtY0MrRJlkbPHOfZL6L6EQAUH9AU1+ZsPE ol8RwQne6v5W9MsRhjoIQkmbWiH+OocrZxvdtZXoR5Ibei2fhoekraCixj77SwpPE6pZ ht7keGgsHZWeyghc7FlKAJdE8PypWR/NYno4PI4ZEkWHQkCZky+eYmpFbByr2eWW4rZ0 sPPaX+JUV+o0qjJygaNIRKN4AuuD9oOO0PNqKRaDUZ5TwQ8yqg7J10A9+9WvZn94iKJl h8Wg== X-Received: by 10.68.201.226 with SMTP id kd2mr23391798pbc.157.1397178865312; Thu, 10 Apr 2014 18:14:25 -0700 (PDT) Received: from bill_win7 ([183.90.37.178]) by mx.google.com with ESMTPSA id oz7sm11825361pbc.41.2014.04.10.18.14.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Apr 2014 18:14:24 -0700 (PDT) Date: Fri, 11 Apr 2014 09:14:24 +0800 From: "bycn82@gmail.com" To: freebsd-ipfw Subject: ipfw not functioning as the manpage on FreeBSD10 X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 0, 111[en] Mime-Version: 1.0 Message-ID: <201404110914222131923@gmail.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 01:14:25 -0000 CgoKCgoKb24gRnJlZUJTRDEwIGFtZDY0CiJpcGZ3IGFkZCBhbGxvdyBhbGwgZnJvbSBhbnkgdG8g YW55IGxheWVyMiBpbiB2aWEgZW0wIiCgaXMgbm90IGZ1bmN0aW9uaW5nIHdoaWxlIGl0IHdvcmtz IHdlbGwgb24gRnJlZUJTRDguMSBhbWQ2NAoKCg== From owner-freebsd-ipfw@FreeBSD.ORG Fri Apr 11 14:15:48 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8F542D4 for ; Fri, 11 Apr 2014 14:15:48 +0000 (UTC) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) (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 7C7401046 for ; Fri, 11 Apr 2014 14:15:48 +0000 (UTC) Received: by mail-pb0-f47.google.com with SMTP id up15so5469629pbc.20 for ; Fri, 11 Apr 2014 07:15:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:references:mime-version:message-id :content-type; bh=/MNs010rZZ4atie3HFGJVem4ONcTEMjC7hGqi5z/VzY=; b=AleZTuXdlFRfN4h4uY2Tyl/b6kMYEeHmzwAEH5IxXvvl3qU5WAM4DECDZ8Dl2xMdKU Sz3yrJRz1msAxJBy3tCFoWH325pgICG7gP9JJpsDV7WsRlAevuLJ56tP/fM+HfhUE+pr jL7sB14wZg3sqqCVk1Axxs+0nTTPDRF/aND5qTsibTtXMt/8psDtVXkYEVnERjdRoFos nr9ZIjOKAAOUPNpaoSOSPDmQ0BT66+9KQyptfoh8CoMvl5zqhma0+hFD20awPI7Orv37 KcrtgomJGCe/zZrPy+k85lqimPbjmkHVHQnF2xiv2rsMHBipCH1xAoChvvo6dpXTkgsg 6voA== X-Received: by 10.66.219.68 with SMTP id pm4mr348568pac.21.1397225748163; Fri, 11 Apr 2014 07:15:48 -0700 (PDT) Received: from bill_win7 ([183.90.37.178]) by mx.google.com with ESMTPSA id aj7sm36580843pad.29.2014.04.11.07.15.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Apr 2014 07:15:47 -0700 (PDT) Date: Fri, 11 Apr 2014 22:15:48 +0800 From: "bycn82@gmail.com" To: "Jan Bramkamp" Subject: Re: Re: ipfw not functioning as the manpage on FreeBSD10 References: <201404110914222131923@gmail.com>, <5347EDA0.6090905@rlwinm.de> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 0, 111[en] Mime-Version: 1.0 Message-ID: <201404112215462278467@gmail.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 14:15:48 -0000 CgoKCgoKVGhhbmtzIGZvciB5b3VyIHJlcGx5LEl0IGlzIGRpZmZpY3VsdCB0byBsaXN0IGRvd24g YWxsIHRoZSBzZXR0aW5ncyB0aGluZ3Mgb24gbXkgQlNELCBidXQgYW4gc2ltcGxlIHRlc3QgY2Fu IHNob3cgdXMgaXQgd2FzIHdyb25nIG9uIHRoaXMgbWFjaGluZSBhbmQgaXQgaXMgYWJub3JtYWwg LkkgaGF2ZSB0d28gbGluZXMgaW4gdGhlIGZpcmV3YWxsIGFzIGJlbG93OjEuIGNvdW50IGFsbCBm cm9tIGFueSB0byBhbnkgTUFDIGFueSBhbnkgaW4gdmlhIGVtMTIuIGNvdW50IGFsbCBmcm9tIGFu eSB0byBhbnkgTUFDIGFueSBhbnkgcmVjdiBlbTF0aGUgdGVzdGluZyByZXN1bHQgaXMgLCBjb3Vu dGVyIGZvciBsaW5lMiBpcyBjaGFuZ2luZyAsd2hpbGUgZm9yIGxpbmUxIGlzIGFsd2F5cyAwLiBJ dCBpcyBub3QgY29ycmVjdCBhY2NvcmRpbmcgdG8gdGhlIG1hbiBwYWdlIUNhbiBzb21lb25lIHRv IGhhdmUgYSB0cnkgaWYgeW91IGFyZSBhbHNvIHVzaW5nIEZyZWVCU0QxMCwgSSBoYXZlIGFub3Ro ZXIgbWFjaGluZSB3aGljaCBpcyB3b3JraW5nIHdpdGggRkI4LjEgLGl0IGJlaGF2ZXMgY29ycmVj dGx5LgpUaGFua3MgZm9yIHlvdXIgdGltZSygRnJvbTqgSmFuIEJyYW1rYW1wRGF0ZTqgMjAxNC0w NC0xMaAyMToyNlRvOqBieWNuODJAZ21haWwuY29tU3ViamVjdDqgUmU6IGlwZncgbm90IGZ1bmN0 aW9uaW5nIGFzIHRoZSBtYW5wYWdlIG9uIEZyZWVCU0QxME9uIDExLjA0LjIwMTQgMDM6MTQsIGJ5 Y244MkBnbWFpbC5jb20gd3JvdGU6Cj4gaXBmdyBhZGQgYWxsb3cgYWxsIGZyb20gYW55IHRvIGFu eSBsYXllcjIgaW4gdmlhIGVtMApJdCBkb2VzIHdvcmsgaWYgaXBmdyBpcyBhdmFpbGFibGUgaW4g eW91ciBrZXJuZWwuIElmIHlvdSB1c2UgYSBHRU5FUklDCmxvYWQgdGhlIGNvcnJlY3Qga2VybmVs IG1vZHVsZXMgKGlwZncua28gYW5kIGlwZndfbmF0LmtvKS4gTG9hZGluZyBpcGZ3CndpbGwgYWN0 aXZhdGUgYSBkZW55IGFsbCBkZWZhdWx0IHJ1bGVzZXQuCgo= From owner-freebsd-ipfw@FreeBSD.ORG Mon Apr 14 11:06:47 2014 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD276FB7 for ; Mon, 14 Apr 2014 11:06:46 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 CA3BB165D for ; Mon, 14 Apr 2014 11:06:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3EB6kEl025905 for ; Mon, 14 Apr 2014 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3EB6k4W025903 for freebsd-ipfw@FreeBSD.org; Mon, 14 Apr 2014 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 14 Apr 2014 11:06:46 GMT Message-Id: <201404141106.s3EB6k4W025903@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 11:06:47 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/187904 ipfw [ipfw] ipfw(8) does not properly recognize the network o kern/180731 ipfw [ipfw] problem with displaying 255.255.255.255 address o kern/180729 ipfw [ipfw] ipfw nat show empty output o kern/178482 ipfw [ipfw] logging problem from vnet jail o kern/178480 ipfw [ipfw] dynamically loaded ipfw with a vimage kernel do o kern/178317 ipfw [ipfw] ipfw options need to specifed in specific order o kern/177948 ipfw [ipfw] ipfw fails to parse port ranges (p1-p2) for udp o kern/176503 ipfw [ipfw] ipfw layer2 problem o conf/167822 ipfw [ipfw] [patch] start script doesn't load firewall_type o kern/166406 ipfw [ipfw] ipfw does not set ALTQ identifier for ipv6 traf o kern/165939 ipfw [ipfw] bug: incomplete firewall rules loaded if tables o kern/165190 ipfw [ipfw] [lo] [patch] loopback interface is not marking o kern/158066 ipfw [ipfw] ipfw + netgraph + multicast = multicast packets o kern/157689 ipfw [ipfw] ipfw nat config does not accept nonexistent int f kern/155927 ipfw [ipfw] ipfw stops to check packets for compliance with o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw [ipfw] does not support specifying rules with ICMP cod o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. f kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l f kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes s kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 42 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Wed Apr 16 00:58:39 2014 Return-Path: Delivered-To: freebsd-ipfw@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 354AD1E3; Wed, 16 Apr 2014 00:58:39 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 0B0C4134A; Wed, 16 Apr 2014 00:58:39 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3G0wcww096554; Wed, 16 Apr 2014 00:58:38 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3G0wcLt096553; Wed, 16 Apr 2014 00:58:38 GMT (envelope-from linimon) Date: Wed, 16 Apr 2014 00:58:38 GMT Message-Id: <201404160058.s3G0wcLt096553@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/183479: [ipfw] ipfw table contains duplicate entry. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 00:58:39 -0000 Old Synopsis: ipfw table contains duplicate entry. New Synopsis: [ipfw] ipfw table contains duplicate entry. Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Wed Apr 16 00:58:12 UTC 2014 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=183479 From owner-freebsd-ipfw@FreeBSD.ORG Wed Apr 16 01:13:43 2014 Return-Path: Delivered-To: freebsd-ipfw@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D60D6804; Wed, 16 Apr 2014 01:13:43 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 AAED2153B; Wed, 16 Apr 2014 01:13:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3G1DhQv004904; Wed, 16 Apr 2014 01:13:43 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3G1DhBj004903; Wed, 16 Apr 2014 01:13:43 GMT (envelope-from linimon) Date: Wed, 16 Apr 2014 01:13:43 GMT Message-Id: <201404160113.s3G1DhBj004903@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/170604: [ipfw] ipv6 reass broken X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 01:13:43 -0000 Synopsis: [ipfw] ipv6 reass broken Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Wed Apr 16 01:13:21 UTC 2014 Responsible-Changed-Why: reassign. http://www.freebsd.org/cgi/query-pr.cgi?pr=170604 From owner-freebsd-ipfw@FreeBSD.ORG Wed Apr 16 01:14:31 2014 Return-Path: Delivered-To: freebsd-ipfw@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 562E688E; Wed, 16 Apr 2014 01:14:31 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 2B8121554; Wed, 16 Apr 2014 01:14:31 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3G1EVJm004955; Wed, 16 Apr 2014 01:14:31 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3G1EUuT004954; Wed, 16 Apr 2014 01:14:30 GMT (envelope-from linimon) Date: Wed, 16 Apr 2014 01:14:30 GMT Message-Id: <201404160114.s3G1EUuT004954@freefall.freebsd.org> To: ndenev@gmail.com, linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/185854: [ipfw] ipfw reads breaks IPv6 traffic X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 01:14:31 -0000 Old Synopsis: ipfw reads breaks IPv6 traffic New Synopsis: [ipfw] ipfw reads breaks IPv6 traffic State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Wed Apr 16 01:12:59 UTC 2014 State-Changed-Why: apparently a duplicate of kern/170604. Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Wed Apr 16 01:12:59 UTC 2014 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=185854 From owner-freebsd-ipfw@FreeBSD.ORG Wed Apr 16 01:40:36 2014 Return-Path: Delivered-To: freebsd-ipfw@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 671D7503; Wed, 16 Apr 2014 01:40:36 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 3BAEB180F; Wed, 16 Apr 2014 01:40:36 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3G1eajj012932; Wed, 16 Apr 2014 01:40:36 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3G1eavT012931; Wed, 16 Apr 2014 01:40:36 GMT (envelope-from linimon) Date: Wed, 16 Apr 2014 01:40:36 GMT Message-Id: <201404160140.s3G1eavT012931@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/188543: [ipfw] ipfw option `in` is not working on FreeBSD10 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 01:40:36 -0000 Old Synopsis: ipfw option `in` is not working on FreeBSD10 New Synopsis: [ipfw] ipfw option `in` is not working on FreeBSD10 Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Wed Apr 16 01:40:14 UTC 2014 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=188543 From owner-freebsd-ipfw@FreeBSD.ORG Wed Apr 16 02:40:01 2014 Return-Path: Delivered-To: freebsd-ipfw@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42C93552 for ; Wed, 16 Apr 2014 02:40:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 306EB1C93 for ; Wed, 16 Apr 2014 02:40:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3G2e0qf034858 for ; Wed, 16 Apr 2014 02:40:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3G2e0Pn034857; Wed, 16 Apr 2014 02:40:00 GMT (envelope-from gnats) Date: Wed, 16 Apr 2014 02:40:00 GMT Message-Id: <201404160240.s3G2e0Pn034857@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org Cc: From: lhmwzy Subject: Re: kern/188543: [ipfw] ipfw option `in` is not working on FreeBSD10 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lhmwzy List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 02:40:01 -0000 The following reply was made to PR kern/188543; it has been noted by GNATS. From: lhmwzy To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/188543: [ipfw] ipfw option `in` is not working on FreeBSD10 Date: Wed, 16 Apr 2014 10:33:34 +0800 --001a11c14da43b033404f71fbe29 Content-Type: text/plain; charset=UTF-8 I have tested under 10.0 and the count is alwayls 0. #sysctl -a|grep ipfw net.link.ether.ipfw:1 under 8.4 and 9.2,the count is correct. --001a11c14da43b033404f71fbe29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have tested under 10.0 and the=C2=A0 count is = alwayls 0.
#sysctl -a|grep ipfw
net.link.ether.ipfw:1

under 8.4 and 9.2,the count is correct.
--001a11c14da43b033404f71fbe29-- From owner-freebsd-ipfw@FreeBSD.ORG Wed Apr 16 12:25:55 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 246BBDD2 for ; Wed, 16 Apr 2014 12:25:55 +0000 (UTC) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::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 E994618B3 for ; Wed, 16 Apr 2014 12:25:54 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id p10so10734063pdj.3 for ; Wed, 16 Apr 2014 05:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:to:subject:references:date:mime-version:from :organization:message-id:in-reply-to:user-agent; bh=E2yf27BWI5lrHk7IbT/0rUu0rck+G13vZx411WrGkfk=; b=fQYBsga7al8F8zmgH4uaBupgo2ZHie0GGvdSiqAEnpZN5uH3QnBgVIpynagXrrW3gm NPSgJuwb73oNYSIxTYhBOQYX0QXIoE/yPPwWqmGfyWHXrVWMZnRdQoPNtGuTY7AFMnnM WBKQ8tpJJVKOCdiWy1c9sMtKN/d0hjrbIQYUq1zuMUzZF+FvYmPuEL0o4bYtm0fP8ybt CgzFL5shQmsYJHEf+x+oi/qb8y9hIeocNeNPlwWqSvP2JYFmR+ecyHhIwmLB0HwbyYyM esMHbdh26QXCVQimOAd3FCChfIS+hi1ZmPd8NNkO4ruUqLgMAjHpk95qe82SK15oUyts N+4A== X-Received: by 10.68.112.225 with SMTP id it1mr8207309pbb.142.1397651154557; Wed, 16 Apr 2014 05:25:54 -0700 (PDT) Received: from bill-win7 (amx-tls2.starhub.net.sg. [203.116.164.12]) by mx.google.com with ESMTPSA id x5sm46764621pbw.26.2014.04.16.05.25.52 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 16 Apr 2014 05:25:54 -0700 (PDT) To: freebsd-ipfw@freebsd.org, lhmwzy Subject: Re: kern/188543: [ipfw] ipfw option `in` is not working on FreeBSD10 References: <201404160240.s3G2e0Pn034857@freefall.freebsd.org> Date: Wed, 16 Apr 2014 20:25:50 +0800 MIME-Version: 1.0 From: bycn82 Organization: cozilyworks Message-ID: In-Reply-To: <201404160240.s3G2e0Pn034857@freefall.freebsd.org> User-Agent: Opera Mail/1.0 (Win32) Content-Type: text/plain; charset=gbk; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 12:25:55 -0000 thanks for commenting, for testing i started to read the source code this morning when i was in the mrt. i was a java developer and the source code for i have to said "what a mess!" On Wed, 16 Apr 2014 10:40:00 +0800, lhmwzy wrote: > The following reply was made to PR kern/188543; it has been noted by > GNATS. > > From: lhmwzy > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: kern/188543: [ipfw] ipfw option `in` is not working on > FreeBSD10 > Date: Wed, 16 Apr 2014 10:33:34 +0800 > > --001a11c14da43b033404f71fbe29 > Content-Type: text/plain; charset=UTF-8 > I have tested under 10.0 and the count is alwayls 0. > #sysctl -a|grep ipfw > net.link.ether.ipfw:1 > under 8.4 and 9.2,the count is correct. > --001a11c14da43b033404f71fbe29 > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable >
I have tested under 10.0 and the=C2=A0 count > is = > alwayls 0.
#sysctl -a|grep > ipfw
net.link.ether.ipfw:1

div>under 8.4 and 9.2,the count is correct.
> --001a11c14da43b033404f71fbe29-- > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Wed Apr 16 13:20:01 2014 Return-Path: Delivered-To: freebsd-ipfw@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42A93AB6 for ; Wed, 16 Apr 2014 13:20:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 2E8A71D88 for ; Wed, 16 Apr 2014 13:20:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3GDK1OG061236 for ; Wed, 16 Apr 2014 13:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3GDK0n9061235; Wed, 16 Apr 2014 13:20:00 GMT (envelope-from gnats) Date: Wed, 16 Apr 2014 13:20:00 GMT Message-Id: <201404161320.s3GDK0n9061235@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org Cc: From: lhmwzy Subject: Re: kern/188543: [ipfw] ipfw option `in` is not working on FreeBSD10 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lhmwzy List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 13:20:01 -0000 The following reply was made to PR kern/188543; it has been noted by GNATS. From: lhmwzy To: bug-followup@FreeBSD.org, bycn82@gmail.com Cc: Subject: Re: kern/188543: [ipfw] ipfw option `in` is not working on FreeBSD10 Date: Wed, 16 Apr 2014 21:12:42 +0800 --001a11c12c1af3685704f728aba7 Content-Type: text/plain; charset=UTF-8 Under 10.0 00100 0 0 count ip from any to any MAC any any in via em0 00200 0 0 count ip from any to any MAC any 00:0c:29:f4:d8:75 in via em0 00400 0 0 count ip from any to any MAC any 00:0c:29:f4:d8:75 in these rules's count are 0 00300 2999 1089504 count ip from any to any MAC any 00:0c:29:f4:d8:75 00500 2959 287441 count ip from any to any out 00600 812 113255 count ip from any to any in 00700 45 8952 count ip from any to any MAC any 00:0c:29:f4:d8:75 out These rules look like working normal 00:0c:29:f4:d8:75 is MAC of my em0 --001a11c12c1af3685704f728aba7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Under 10.0

00100 0 0 count ip from any to any = MAC any any in via em0
=C2=A000200 0 0 count ip from any to any MAC any= 00:0c:29:f4:d8:75 in via em0
=C2=A000400 0 0 count ip from any to any = MAC any 00:0c:29:f4:d8:75 in

these rules's count are 0

=C2=A000300 2999 1089504 count ip= from any to any MAC any 00:0c:29:f4:d8:75
=C2=A000500 2959 287441 coun= t ip from any to any out
=C2=A000600 812 113255 count ip from any to an= y in
=C2=A000700 45 8952 count ip from any to any MAC any 00:0c:29:f4:d= 8:75 out

=C2=A0These rules look like working normal
=C2=A000:= 0c:29:f4:d8:75 is MAC of my em0
--001a11c12c1af3685704f728aba7-- From owner-freebsd-ipfw@FreeBSD.ORG Wed Apr 16 14:20:01 2014 Return-Path: Delivered-To: freebsd-ipfw@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31496D9; Wed, 16 Apr 2014 14:20:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 04F511505; Wed, 16 Apr 2014 14:20:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3GEK0KZ081232; Wed, 16 Apr 2014 14:20:00 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3GEK0OB081227; Wed, 16 Apr 2014 14:20:00 GMT (envelope-from ae) Date: Wed, 16 Apr 2014 14:20:00 GMT Message-Id: <201404161420.s3GEK0OB081227@freefall.freebsd.org> To: ae@FreeBSD.org, freebsd-ipfw@FreeBSD.org, ae@FreeBSD.org From: ae@FreeBSD.org Subject: Re: kern/188543: [ipfw] ipfw option `in` is not working on FreeBSD10 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 14:20:01 -0000 Synopsis: [ipfw] ipfw option `in` is not working on FreeBSD10 Responsible-Changed-From-To: freebsd-ipfw->ae Responsible-Changed-By: ae Responsible-Changed-When: Wed Apr 16 14:19:42 UTC 2014 Responsible-Changed-Why: Take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=188543 From owner-freebsd-ipfw@FreeBSD.ORG Wed Apr 16 14:22:10 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB1FC153 for ; Wed, 16 Apr 2014 14:22:09 +0000 (UTC) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (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 C040315AC for ; Wed, 16 Apr 2014 14:22:09 +0000 (UTC) Received: by mail-pd0-f182.google.com with SMTP id y10so10742923pdj.41 for ; Wed, 16 Apr 2014 07:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:to:subject:references:date:mime-version :content-transfer-encoding:from:organization:message-id:in-reply-to :user-agent; bh=P0oSpGuoXiXYshIhbV0Hd6oG5jtEuRCFxCy+B0+cRO8=; b=RXfX8pDiNO0XWolJzUc9Hoz7EqwZQIUZd5BwG2MdrwLveHq31hvWzoWUMjy1z9U7uW Fpx+k8QOz2ns01QPyPK5EnDvSH0QacZ+R56gGmv/DqiwpTX4LWz/3GdXLNy0TFX3+XWg 9ZMDMs30RxIbklMLK/1UKpp8roIbrbvtaw4Nk6KkTzsbEwrlOdn+VOUG/gLWQF3I4u91 HeveUZjjrtKW1+ahlpV/dT+NyQjMmT4kZT26H7HXvHWhUrBSd7gHcpWe8RLZ7xMWvi8X DOXwzMvicNsWX6uf0PFNyCzyPB0FwcKkR6Tma/QQyr2dWMPJTsM6qneCG+G9BPUxtBNs 8lxw== X-Received: by 10.68.99.194 with SMTP id es2mr8890644pbb.100.1397658129398; Wed, 16 Apr 2014 07:22:09 -0700 (PDT) Received: from bill-win7 (amx-tls2.starhub.net.sg. [203.116.164.12]) by mx.google.com with ESMTPSA id h6sm47311132pbl.75.2014.04.16.07.22.07 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 16 Apr 2014 07:22:09 -0700 (PDT) Content-Type: text/plain; charset=gbk; format=flowed; delsp=yes To: freebsd-ipfw@freebsd.org, lhmwzy Subject: Re: kern/188543: [ipfw] ipfw option `in` is not working on FreeBSD10 References: <201404161320.s3GDK0n9061235@freefall.freebsd.org> Date: Wed, 16 Apr 2014 22:22:04 +0800 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: bycn82 Organization: cozilyworks Message-ID: In-Reply-To: <201404161320.s3GDK0n9061235@freefall.freebsd.org> User-Agent: Opera Mail/1.0 (Win32) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 14:22:10 -0000 tks for ur testing, u r right, that s the reason y i said the `in` option is not functioning properly. and who is the guy maintains the source of ipfw. two things i want to said to him, 1. the source of ipfw is cool,amazingly powerful, by reading the source code, it found actually it checked more things then what i expected. more feature than what i assumed.good job! 2.today it is my first perusal of the a system's source code,maybe it is your standard, but for me it s really disgusting! anyway, since it is still under your control, Best Regards, Bill Yuan On Wed, 16 Apr 2014 21:20:00 +0800, lhmwzy wrote: > The following reply was made to PR kern/188543; it has been noted by > GNATS. > > From: lhmwzy > To: bug-followup@FreeBSD.org, bycn82@gmail.com > Cc: > Subject: Re: kern/188543: [ipfw] ipfw option `in` is not working on > FreeBSD10 > Date: Wed, 16 Apr 2014 21:12:42 +0800 > > --001a11c12c1af3685704f728aba7 > Content-Type: text/plain; charset=UTF-8 > Under 10.0 > 00100 0 0 count ip from any to any MAC any any in via em0 > 00200 0 0 count ip from any to any MAC any 00:0c:29:f4:d8:75 in via em0 > 00400 0 0 count ip from any to any MAC any 00:0c:29:f4:d8:75 in > these rules's count are 0 > 00300 2999 1089504 count ip from any to any MAC any 00:0c:29:f4:d8:75 > 00500 2959 287441 count ip from any to any out > 00600 812 113255 count ip from any to any in > 00700 45 8952 count ip from any to any MAC any 00:0c:29:f4:d8:75 out > These rules look like working normal > 00:0c:29:f4:d8:75 is MAC of my em0 > --001a11c12c1af3685704f728aba7 > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable >
Under 10.0

00100 0 0 count ip from any to > any = > MAC any any in via em0
=C2=A000200 0 0 count ip from any to any MAC > any= > 00:0c:29:f4:d8:75 in via em0
=C2=A000400 0 0 count ip from any to > any = > MAC any 00:0c:29:f4:d8:75 in
>
these rules's count are 0

=C2=A000300 2999 1089504 > count ip= > from any to any MAC any 00:0c:29:f4:d8:75
=C2=A000500 2959 287441 > coun= > t ip from any to any out
=C2=A000600 812 113255 count ip from any > to an= > y in
=C2=A000700 45 8952 count ip from any to any MAC any > 00:0c:29:f4:d= > 8:75 out
>
=C2=A0These rules look like working > normal
=C2=A000:= > 0c:29:f4:d8:75 is MAC of my em0
> --001a11c12c1af3685704f728aba7-- > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Wed Apr 16 15:23:18 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 443E37C7; Wed, 16 Apr 2014 15:23:18 +0000 (UTC) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (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 F11141B1F; Wed, 16 Apr 2014 15:23:17 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id y13so10770474pdi.5 for ; Wed, 16 Apr 2014 08:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:to:subject:references:date:mime-version :content-transfer-encoding:from:organization:message-id:in-reply-to :user-agent; bh=qZpBy3rpaB2nHv00dPtutKdw6Hb1CQ0aPGLiPjbwzKY=; b=oZNfIqehNTTxrYakFJXpFly6ohkrmcHFYhPkvoTwoEDFOFx1ZD9oGvXcRLOxd7HxOo 7JrXgkJId4zxNe7h5YGHH1HIUE5ZIQhtGJQlafifxD7JVvLIYAadNafER4nLYJ96VDpp SeQDXu5XLEqxnkNx/GFvqZTu1EqZAR0+PfJUJ4s8tItn6WwUrAp57Q9Z+g7MekkZhnZ2 dBBljnOa0rqTN6PeitrDplBG6fBH61tndVKwHat8TVueYuZ0KQbCCC3BxfYt/AuyYEHa hIFAdDe5dJ5PiSvugeH6fZDHdbDGwDavsD+1D/FKxwetUBOiHq9/LwN8/8ea/st7h32h 1G7Q== X-Received: by 10.68.179.36 with SMTP id dd4mr9095887pbc.139.1397661797345; Wed, 16 Apr 2014 08:23:17 -0700 (PDT) Received: from bill-win7 (amx-tls2.starhub.net.sg. [203.116.164.12]) by mx.google.com with ESMTPSA id kl1sm47609355pbd.73.2014.04.16.08.23.13 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 16 Apr 2014 08:23:15 -0700 (PDT) Content-Type: text/plain; charset=gbk; format=flowed; delsp=yes To: ae@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: kern/188543: [ipfw] ipfw option `in` is not working on FreeBSD10 References: <201404161420.s3GEK0OB081227@freefall.freebsd.org> Date: Wed, 16 Apr 2014 23:23:03 +0800 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: bycn82 Organization: cozilyworks Message-ID: In-Reply-To: <201404161420.s3GEK0OB081227@freefall.freebsd.org> User-Agent: Opera Mail/1.0 (Win32) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 15:23:18 -0000 Cool! I just finished the overview of the source code,and finally understood the `for loop` in the ip_fw2.c roughly, beside of the coding style,sorry for my ironic words, I want to ask whether my understanding is correct. you wrap the packet/frame in the `check frame` or `check packet` which where invoked in the hook() function, and pass it into the chk() function and the chk() function will check the `args` against the whole rule set.( the `chain` variable) so my question is , does it mean that all the packet need to be checked against all the firewall rule, sorry I did not have time to check/understand how we generate the `chain` yet, If it is really working in this case, I cannot accept that personally! according to the man page, we have 4 `check point`, I assumed that we have registered the hook() into 4 different places, for saying , if I have 10K lines of rules which are for 4st `check point` only, based on current logic, each packet/frame need to check against the rules for 4 times, and actually in the 1 2 3rd `check-point` ,the verification are not needed. I hope i was wrong, Can someone kindly explain the correct logic ? thanks very much! On Wed, 16 Apr 2014 22:20:00 +0800, wrote: > Synopsis: [ipfw] ipfw option `in` is not working on FreeBSD10 > > Responsible-Changed-From-To: freebsd-ipfw->ae > Responsible-Changed-By: ae > Responsible-Changed-When: Wed Apr 16 14:19:42 UTC 2014 > Responsible-Changed-Why: > Take it. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=188543 > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Wed Apr 16 15:40:20 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ACA2AE6A; Wed, 16 Apr 2014 15:40:20 +0000 (UTC) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) (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 78D301CE6; Wed, 16 Apr 2014 15:40:20 +0000 (UTC) Received: by mail-pb0-f51.google.com with SMTP id uo5so11068768pbc.10 for ; Wed, 16 Apr 2014 08:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:to:subject:references:date:mime-version :content-transfer-encoding:from:organization:message-id:in-reply-to :user-agent; bh=PZVttTT8JE5O8mYjlkWmPJpoPRWoJNbcD4q/3EkO6VU=; b=q21hnJP+gPXZhr3OwqfI9bAIZrltT72NUxIAtjhFqwngSTI6nyolwCGD+1mCZABt44 WG+dEKwCriu+Poiel/41A2At7LhZ/JRPKzio5+xWRcn75SSy5LrrfYojju1jXeeqS9se LikFATQP0hoXlCjZwjqnbQCP/fD5LCKpdNl0TGPUa2rtgethznfBFoBdKvaQGsARd0E/ smKwA4HKzkEnKDg23EqJSUZ4WPNXInkzDY4hi+indzWw5DWfPuRqEf4r0SPNDCrWC56+ oDMGnF9z3LwzvcEw+BrPU2hq2zFjtrcCCFQ4wi7IKRMlOe3GCHprkYPSeJTe00IEfetm m0Pg== X-Received: by 10.68.133.163 with SMTP id pd3mr2783582pbb.166.1397662820034; Wed, 16 Apr 2014 08:40:20 -0700 (PDT) Received: from bill-win7 (amx-tls2.starhub.net.sg. [203.116.164.12]) by mx.google.com with ESMTPSA id g6sm112864138pat.2.2014.04.16.08.40.17 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 16 Apr 2014 08:40:19 -0700 (PDT) Content-Type: text/plain; charset=gbk; format=flowed; delsp=yes To: ae@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: kern/188543: [ipfw] ipfw option `in` is not working on FreeBSD10 References: <201404161420.s3GEK0OB081227@freefall.freebsd.org> Date: Wed, 16 Apr 2014 23:40:15 +0800 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: bycn82 Organization: cozilyworks Message-ID: In-Reply-To: User-Agent: Opera Mail/1.0 (Win32) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 15:40:20 -0000 Hi According to the `loop` in the chk() function, everytime it was invoked, the arg will be checked against `the chain`, so I assumed that the same is always the same, I saw that, `the chain` is always `V_layer3_chain`, but I did not find any V_layer2_chain !!! So I assumed that currently it always using the same`chain`. If so , is it better to separate the rules into multiple `chain`? for saying , chain1 chain2 chain3 chain4, and differnet `check point`s are going to use its own chain accordingly ? Respect your effort, and I want to say `thanks` here, Thanks! Best Regards, Bill Yuan On Wed, 16 Apr 2014 23:23:03 +0800, bycn82 wrote: > Cool! > I just finished the overview of the source code,and finally understood > the `for loop` in the ip_fw2.c roughly, > beside of the coding style,sorry for my ironic words, I want to ask > whether my understanding is correct. > > you wrap the packet/frame in the `check frame` or `check packet` which > where invoked in the hook() function, and pass it into the chk() function > and the chk() function will check the `args` against the whole rule > set.( the `chain` variable) > > so my question is , does it mean that all the packet need to be checked > against all the firewall rule, sorry I did not have time to > check/understand how we generate the `chain` yet, If it is really > working in this case, I cannot accept that personally! > > according to the man page, we have 4 `check point`, I assumed that we > have registered the hook() into 4 different places, for saying , if I > have 10K lines of rules which are for 4st `check point` only, based on > current logic, each packet/frame need to check against the rules for 4 > times, and actually in the 1 2 3rd `check-point` ,the verification are > not needed. I hope i was wrong, > > Can someone kindly explain the correct logic ? thanks very much! > > > On Wed, 16 Apr 2014 22:20:00 +0800, wrote: > >> Synopsis: [ipfw] ipfw option `in` is not working on FreeBSD10 >> >> Responsible-Changed-From-To: freebsd-ipfw->ae >> Responsible-Changed-By: ae >> Responsible-Changed-When: Wed Apr 16 14:19:42 UTC 2014 >> Responsible-Changed-Why: >> Take it. >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=188543 >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> http://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 Apr 17 19:29:22 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F2005D9 for ; Thu, 17 Apr 2014 19:29:22 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (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 9138318EB for ; Thu, 17 Apr 2014 19:29:21 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id z2so3401398wiv.0 for ; Thu, 17 Apr 2014 12:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berger-family.org; s=google; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=zJEKS/RhjTCrKirxLIho46fnzLsjI8PiEjw27tWrLtY=; b=FQ+r80KmaCyXGuHUA0+LMhn349yccesjupZyqcMqd/SRWrkkBR2HtN6G9es2V7vkL1 Nxipv4JOmjPHaUHOs4TAESnVLtDRq3CY36d9O+1+FJAbVtV/hQE/HYK5zjLtrbVoyjNt HuYNrK5e3hL9J2glhPMqasjRoec5f2kR2cM7o= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=zJEKS/RhjTCrKirxLIho46fnzLsjI8PiEjw27tWrLtY=; b=gQOLyFyyUaCrUuoc2ayqp+Gsb+ACQQhi8Gl2za+htgYOyJC3jtlCPnIKKDharAh6DA /V3DsPPiebEFyFH0zHWW8NQklbKXImgyoE2gVqnyiQu99rLVtr/b+EnsmxCx7XTEVFYP URjwUAUWuPmeBLGfC970Uh4Grbv2h5Zfr3PwWC3yCd9jStF+wXvZ4q09vEcK3oPgP4IW 0kaC1nM1cahwmGNeEEVpyepqptW4qv6ovJCuugb/8FJrmPanQ45HOHboLKHi4YEZUZUn vluZTSaHM2qG0IcC3qQrlVK6UeijC1jTgyU2EAljSNCPtIJiCHv54Vh7owXi+r+fFNm8 Be0w== 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:date:message-id:subject:from :to:content-type; bh=zJEKS/RhjTCrKirxLIho46fnzLsjI8PiEjw27tWrLtY=; b=KN50A2P1vAEFHUu3ulI5kW4MCD5Q/AxvUGLaAbR9ENlzEsKIovIkktaU32HFmVuOa2 4TjfGsNhiboq/6pnItL/2XopRGbJpDMn0CNbkP3HuifsR/Ba8yLtuM13nGaF4OqOONS9 urf4OEsb7chtEwBDHwgz48QWOFXYs8rIgxSnqNv16OSct5xjDz2D1sneL3tS9YgMt/M3 5ND1MtO518o2NyrEm5BArB6ThPhOedVvpRY8Wkez2UpZh60AOBEY7Bxu6gJyyEDFVwNb 1h/tW2IkI4bSg0VxXTOreJiqDvbnXTdtKHyiWwHZftgrsOV8YxquOYXJhXg1boVy9srg cQYg== X-Gm-Message-State: ALoCoQl4kZAFgJqr+xGq72erxuNhT3NFpfBvdAhDbwXPQ4cDDjScTQxB8nMuHMEqL3CffMmfmHN5 MIME-Version: 1.0 X-Received: by 10.194.188.68 with SMTP id fy4mr13356341wjc.30.1397762959396; Thu, 17 Apr 2014 12:29:19 -0700 (PDT) Sender: joubert@berger-family.org Received: by 10.194.139.178 with HTTP; Thu, 17 Apr 2014 12:29:19 -0700 (PDT) Date: Thu, 17 Apr 2014 15:29:19 -0400 X-Google-Sender-Auth: KeDaK7am9z5YSTDIQ0IqHmdWKpI Message-ID: Subject: user-space dummnet From: Joubert Berger To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 19:29:22 -0000 I am attempting to get the user-space dummynet working and have run into a problem. Luigi has been very gracious with his help, but I felt I was starting to abuse it, so I thought I would ask a wider audience and see if I could take some of the load off of him :-) This is my setup. I have installed 9-stable. Build kernel with netmap enabled. Checkout out code from https://code.google.com/p/netmap-ipfw The README says to build as follows: make NETMAP_INC=/some/where/with/netmap-release/sys When I do: make NETMAP_INC=/usr/src/sys I get errors compiling: error: "VNET_SYSINIT" redefined error: "VNET_SYSUNINIT" redefined I then just do: make And it compiles fine. Next I do the "for testing purposes" example: ./kipfw In another window I do: telnet localhost 5556 And I get a bunch of ip_fw_pfil.c:ipfw_check_frame [349] M_PREPEND not implemented and then a core dump. Any pointers to what I am doing wrong? --joubert Below the the output of when I run kipfw ./kipfw [ 124.163183] missing.c:callout_startup [361] start init_children mod_idx value 9 +++ start module 0 ipfw ipfw at 0x61eaa0 order 0x1 +++ start module 1 sy_ipfw SYSINIT at 0x0 order 0x2 ipfw2 initialized, divert loadable, nat loadable, default to accept, logging disabled +++ start module 2 sy_Vnet_ipfw SYSINIT at 0x0 order 0x3 [ 124.163237] missing.c:callout_init [308] c 0x61f1e0 mpsafe 8 [ 124.163313] missing.c:pfil_head_get [89] called [ 124.163316] missing.c:pfil_add_hook [96] called +++ start module 3 dummynet dummynet at 0x61eae0 order 0x4 DUMMYNET 0x0 with IPv6 initialized (100409) [ 124.163330] missing.c:taskqueue_create_fast [427] start dummynet fn 0x415950 ctx 0x61f260 [ 124.163334] missing.c:taskqueue_start_threads [435] tqp 0x61f260 count 1 (dummy) [ 124.163336] missing.c:callout_init [308] c 0x61f300 mpsafe 8 +++ start module 4 dn_fifo dn_fifo at 0x61eb30 order 0x5 [ 124.163341] ip_dummynet.c:load_dn_sched [2245] dn_sched FIFO loaded +++ start module 5 dn_wf2qp dn_wf2qp at 0x61ec10 order 0x6 [ 124.163346] ip_dummynet.c:load_dn_sched [2245] dn_sched WF2Q+ loaded +++ start module 6 dn_rr dn_rr at 0x61ecf0 order 0x7 [ 124.163351] ip_dummynet.c:load_dn_sched [2245] dn_sched RR loaded +++ start module 7 dn_qfq dn_qfq at 0x61edd0 order 0x8 [ 124.163355] ip_dummynet.c:load_dn_sched [2245] dn_sched QFQ loaded +++ start module 8 dn_prio dn_prio at 0x61eeb0 order 0x9 [ 124.163359] ip_dummynet.c:load_dn_sched [2245] dn_sched PRIO loaded *** Global Sysctl Table entries = 41, total size = 2144 *** [ 124.163419] session.c:do_server [531] +++ listening tcp 127.0.0.1:5555 [ 124.163436] session.c:do_server [531] +++ listening tcp 127.0.0.1:5556 [ 132.826581] ip_fw_pfil.c:ipfw_check_frame [349] M_PREPEND not implemented From owner-freebsd-ipfw@FreeBSD.ORG Sat Apr 19 07:45:23 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD17951B for ; Sat, 19 Apr 2014 07:45:23 +0000 (UTC) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (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 830261822 for ; Sat, 19 Apr 2014 07:45:23 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id v10so2091932pde.25 for ; Sat, 19 Apr 2014 00:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=k7+7SABDKyXR9gnlkUKZThLWCATq3EhYNyAjuKj6uDU=; b=z+iFTfBP2ndty1MlihuAlUu6XbDEqKxtcYZYEX2MeF7lDMnUdNO/GXWjBtP4lAh5uP flfoN1ESfH2A4lNU1Em+4FmCn9I9VdiR3EHXK6F7Dk1U990LkbOYngM9nldCBJEx+vTP E+FUAbT/ONeqhkoNILCIwckP3+wT5nOHwUQXU4mJVzdGD0rWV37+GZ3JvSW1oORXFGos 24JaC3k4tYpKlKi3KCYD9UznfCJ30Zo5medEYHCAPz1ptpUGUi8EqHNulYnMhO50OFWb rlw7aIkfABA+5KbuuJC6SBTGB/jXKPPFwLVLo79UwmlVh9muU1pyHTveSOfL7N1/G+kd CRow== X-Received: by 10.68.139.137 with SMTP id qy9mr26300855pbb.11.1397893523156; Sat, 19 Apr 2014 00:45:23 -0700 (PDT) Received: from [192.168.1.100] ([183.90.37.157]) by mx.google.com with ESMTPSA id f3sm64326535pbg.60.2014.04.19.00.45.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Apr 2014 00:45:22 -0700 (PDT) Message-ID: <5352298C.2090902@gmail.com> Date: Sat, 19 Apr 2014 15:45:16 +0800 From: bycn82 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Subject: how does it pass in the rule sets Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 07:45:23 -0000 Hi, can someone help to explain how does the user land command `ipfw` pass the rule set into the hook function in the kernel? I assume that it must be hardcoded in somewhere, but I did not find it yet. Best Regards Bycn82 From owner-freebsd-ipfw@FreeBSD.ORG Sat Apr 19 18:04:02 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14AD45AC; Sat, 19 Apr 2014 18:04:02 +0000 (UTC) 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 D1DF71D0C; Sat, 19 Apr 2014 18:04:01 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-232-70.lns20.per1.internode.on.net [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s3JI3vU2032262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 19 Apr 2014 11:03:59 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5352BA87.50803@freebsd.org> Date: Sun, 20 Apr 2014 02:03:51 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: bycn82 , ae@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: kern/188543: [ipfw] ipfw option `in` is not working on FreeBSD10 References: <201404161420.s3GEK0OB081227@freefall.freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 18:04:02 -0000 On 4/16/14, 11:40 PM, bycn82 wrote: > Hi > According to the `loop` in the chk() function, everytime it was > invoked, the arg will be checked against `the chain`, so I assumed > that the same is always the same, > I saw that, `the chain` is always `V_layer3_chain`, but I did not > find any V_layer2_chain !!! > So I assumed that currently it always using the same`chain`. > If so , is it better to separate the rules into multiple `chain`? > for saying , chain1 chain2 chain3 chain4, and differnet `check > point`s are going to use its own chain accordingly ? you can do that with 1 chain, by using the 'skipto' command to make packets from different entry-points skipto different rule numbers. > > Respect your effort, and I want to say `thanks` here, Thanks! > > Best Regards, > Bill Yuan > > On Wed, 16 Apr 2014 23:23:03 +0800, bycn82 wrote: > >> Cool! >> I just finished the overview of the source code,and finally >> understood the `for loop` in the ip_fw2.c roughly, >> beside of the coding style,sorry for my ironic words, I want to ask >> whether my understanding is correct. >> >> you wrap the packet/frame in the `check frame` or `check packet` >> which where invoked in the hook() function, and pass it into the >> chk() function >> and the chk() function will check the `args` against the whole rule >> set.( the `chain` variable) >> >> so my question is , does it mean that all the packet need to be >> checked against all the firewall rule, sorry I did not have time to >> check/understand how we generate the `chain` yet, If it is really >> working in this case, I cannot accept that personally! >> >> according to the man page, we have 4 `check point`, I assumed that >> we have registered the hook() into 4 different places, for saying , >> if I have 10K lines of rules which are for 4st `check point` only, >> based on current logic, each packet/frame need to check against the >> rules for 4 times, and actually in the 1 2 3rd `check-point` ,the >> verification are not needed. I hope i was wrong, >> >> Can someone kindly explain the correct logic ? thanks very much! >> >> >> On Wed, 16 Apr 2014 22:20:00 +0800, wrote: >> >>> Synopsis: [ipfw] ipfw option `in` is not working on FreeBSD10 >>> >>> Responsible-Changed-From-To: freebsd-ipfw->ae >>> Responsible-Changed-By: ae >>> Responsible-Changed-When: Wed Apr 16 14:19:42 UTC 2014 >>> Responsible-Changed-Why: >>> Take it. >>> >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=188543 >>> _______________________________________________ >>> freebsd-ipfw@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >>> To unsubscribe, send any mail to >>> "freebsd-ipfw-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > From owner-freebsd-ipfw@FreeBSD.ORG Mon Apr 21 11:06:48 2014 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F5A6FA2 for ; Mon, 21 Apr 2014 11:06:48 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 4BE44195D for ; Mon, 21 Apr 2014 11:06:48 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3LB6mG0085738 for ; Mon, 21 Apr 2014 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3LB6ldj085736 for freebsd-ipfw@FreeBSD.org; Mon, 21 Apr 2014 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Apr 2014 11:06:47 GMT Message-Id: <201404211106.s3LB6ldj085736@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 11:06:48 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/187904 ipfw [ipfw] ipfw(8) does not properly recognize the network o kern/183479 ipfw [ipfw] ipfw table contains duplicate entry. o kern/180731 ipfw [ipfw] problem with displaying 255.255.255.255 address o kern/180729 ipfw [ipfw] ipfw nat show empty output o kern/178482 ipfw [ipfw] logging problem from vnet jail o kern/178480 ipfw [ipfw] dynamically loaded ipfw with a vimage kernel do o kern/178317 ipfw [ipfw] ipfw options need to specifed in specific order o kern/177948 ipfw [ipfw] ipfw fails to parse port ranges (p1-p2) for udp o kern/176503 ipfw [ipfw] ipfw layer2 problem o kern/170604 ipfw [ipfw] ipv6 reass broken o conf/167822 ipfw [ipfw] [patch] start script doesn't load firewall_type o kern/166406 ipfw [ipfw] ipfw does not set ALTQ identifier for ipv6 traf o kern/165939 ipfw [ipfw] bug: incomplete firewall rules loaded if tables o kern/165190 ipfw [ipfw] [lo] [patch] loopback interface is not marking o kern/158066 ipfw [ipfw] ipfw + netgraph + multicast = multicast packets o kern/157689 ipfw [ipfw] ipfw nat config does not accept nonexistent int f kern/155927 ipfw [ipfw] ipfw stops to check packets for compliance with o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw [ipfw] does not support specifying rules with ICMP cod o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. f kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l f kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes s kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 44 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Apr 21 14:36:00 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF09C675 for ; Mon, 21 Apr 2014 14:36:00 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 05160F8; Mon, 21 Apr 2014 14:35:59 +0000 (UTC) Message-ID: <53552C83.7060008@FreeBSD.org> Date: Mon, 21 Apr 2014 18:34:43 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: bycn82 , freebsd-ipfw@freebsd.org Subject: Re: how does it pass in the rule sets References: <5352298C.2090902@gmail.com> In-Reply-To: <5352298C.2090902@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 14:36:00 -0000 On 19.04.2014 11:45, bycn82 wrote: > Hi, > can someone help to explain how does the user land command `ipfw` pass > the rule set into the hook function in the kernel? I assume that it must > be hardcoded in somewhere, but I did not find it yet. ipfw(8) uses raw socket and setsockopt(2)/getsockopt(2) functions to interact with kernel. In particular, do_cmd() function from ipfw2.c does it. -- WBR, Andrey V. Elsukov From owner-freebsd-ipfw@FreeBSD.ORG Mon Apr 21 15:14:21 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8CCC5BCF; Mon, 21 Apr 2014 15:14:21 +0000 (UTC) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (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 5AEDD11D6; Mon, 21 Apr 2014 15:14:21 +0000 (UTC) Received: by mail-pd0-f177.google.com with SMTP id y10so3748804pdj.22 for ; Mon, 21 Apr 2014 08:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=1BA1/rQade+9J8tVbftl3ZroO/6H15oIevY86aBaINI=; b=tc0hebMBtwu0ldMdfRJnFe0D5F4Pjbpw3Xw5QTIU1Ejpai4xaaf9qQ58mav7DO1Dx8 4tJ/1tcrFOrDEcf3RWHjFLRQUfkFeBXJcDAkULQR/Xp/2qhODK3VS36SXf0jvqROI5Qc NeLj6wQmjYn0us9snqUH80YVCrfmDzNRh6nkgRh4x1ZY5d+py0wJ+aVwPrlnb7AeG7b/ 4PmF//gZfdJviEX+EiijEujmr6mM72wGdOQ5F498eDoaDMcdaHhQ8tn93PXgeyZsv65J SW513rkot044DscmqIm6tXyKKui6xr0XPBES8xXJu7MGWg8E3c5cW+iNgf/NAarrlD3O MEwg== X-Received: by 10.67.2.34 with SMTP id bl2mr38806618pad.58.1398093260963; Mon, 21 Apr 2014 08:14:20 -0700 (PDT) Received: from [192.168.1.100] ([183.90.37.157]) by mx.google.com with ESMTPSA id ff4sm187710194pad.24.2014.04.21.08.14.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Apr 2014 08:14:20 -0700 (PDT) Message-ID: <535535C7.1050707@gmail.com> Date: Mon, 21 Apr 2014 23:14:15 +0800 From: bycn82 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "Andrey V. Elsukov" Subject: Re: how does it pass in the rule sets References: <5352298C.2090902@gmail.com> <53552C83.7060008@FreeBSD.org> In-Reply-To: <53552C83.7060008@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 15:14:21 -0000 On 4/21/14 22:34, Andrey V. Elsukov wrote: > On 19.04.2014 11:45, bycn82 wrote: >> Hi, >> can someone help to explain how does the user land command `ipfw` pass >> the rule set into the hook function in the kernel? I assume that it must >> be hardcoded in somewhere, but I did not find it yet. > ipfw(8) uses raw socket and setsockopt(2)/getsockopt(2) functions to > interact with kernel. In particular, do_cmd() function from ipfw2.c does it. > Thanks very much, Actually I saw the source already, the ipfw_ctl() method. I would like to call it as "an event handler" But why it will triggered? where are the code to register this method as listener? Sorry for using Java terminologies ;) From owner-freebsd-ipfw@FreeBSD.ORG Mon Apr 21 15:35:29 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4976439F for ; Mon, 21 Apr 2014 15:35:29 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 933CF1DDF; Mon, 21 Apr 2014 15:35:28 +0000 (UTC) Message-ID: <53553A74.4000405@FreeBSD.org> Date: Mon, 21 Apr 2014 19:34:12 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: bycn82 Subject: Re: how does it pass in the rule sets References: <5352298C.2090902@gmail.com> <53552C83.7060008@FreeBSD.org> <535535C7.1050707@gmail.com> In-Reply-To: <535535C7.1050707@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 15:35:29 -0000 On 21.04.2014 19:14, bycn82 wrote: > On 4/21/14 22:34, Andrey V. Elsukov wrote: >> On 19.04.2014 11:45, bycn82 wrote: >>> Hi, >>> can someone help to explain how does the user land command `ipfw` pass >>> the rule set into the hook function in the kernel? I assume that it must >>> be hardcoded in somewhere, but I did not find it yet. >> ipfw(8) uses raw socket and setsockopt(2)/getsockopt(2) functions to >> interact with kernel. In particular, do_cmd() function from ipfw2.c does it. >> > Thanks very much, > Actually I saw the source already, the ipfw_ctl() method. I would like > to call it as "an event handler" > But why it will triggered? where are the code to register this method > as listener? > Sorry for using Java terminologies ;) You need to improve your grep-fu :) When you load ipfw.ko kernel module, vnet_ipfw_init() initializes V_ip_fw_ctl_ptr = ipfw_ctl. When you call setsockopt() for raw socket, it invokes ctloutput method for RAW IP - rip_ctloutput() (netinet/raw_ip.c). It calls ipfw_ctl() via V_ip_fw_ctl_ptr pointer. -- WBR, Andrey V. Elsukov From owner-freebsd-ipfw@FreeBSD.ORG Sun Apr 27 08:23:01 2014 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 747B51DF for ; Sun, 27 Apr 2014 08:23:01 +0000 (UTC) Received: from nm30-vm0.bullet.mail.bf1.yahoo.com (nm30-vm0.bullet.mail.bf1.yahoo.com [98.139.213.126]) (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 004431A3F for ; Sun, 27 Apr 2014 08:23:00 +0000 (UTC) Received: from [98.139.215.141] by nm30.bullet.mail.bf1.yahoo.com with NNFMP; 27 Apr 2014 08:22:59 -0000 Received: from [98.139.212.231] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 27 Apr 2014 08:22:59 -0000 Received: from [127.0.0.1] by omp1040.mail.bf1.yahoo.com with NNFMP; 27 Apr 2014 08:22:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 794661.84956.bm@omp1040.mail.bf1.yahoo.com Received: (qmail 58601 invoked by uid 60001); 27 Apr 2014 08:22:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398586979; bh=+pkgg9AYXLIAalWhEZT4uYH1kOo5WMHeTh9EfNAs1OM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=z14ivlydd4zMW7Xg60N8jHnd+SzBe3Ns7pPya9+LWoh0XpjbHnwlXZ3hkWDGa6Ztdu3MFukuOICP+xc/wtyW8y6vBv0kmORZqL7BCtUFxLeFmutVojOFwBxCsG3T+KbixL+G+fiMPG9bq11ljJO3j8YSPaQcasby3R49lPTY27Q= X-YMail-OSG: yRh.r0IVM1nOuFWFDgX1H1vKNq0hQSl2SsbHxDlhEEpQoVX O6ueEVXygMRgr9805MKnODPKsGlzKbl68cvdt0tWkSUXrB7W5yiwMekWWyMy oObT16Sb9z2jyUGBY.uSDS5jDqw2TKXUNWMU_f3p5tVZXA_Zfw_RCr.lK731 BqhvoUiA5f1Eu3KG6unfc9uQcNjBehEGvI7P3GYi02MY2emWqnvQQKQD8yFW YJEImK5kvWPYupOFDiPvMwyLIV41_fkE0BfbqmvCDJMoLsH8PD_yK4tVNiQ. 14vQ2AGRPxoG.knYaAnFJP_eLvhM.u.ZlVoVImzB4QcKun5bZyyGPIGRjfKL lPjencln2dXcAtPOOZe5PWU8Vqb3akZe23YXzFtLK7CRQZR3rpqlxpCqPsg. F3opcxYdp.HjEiBTSwAFdKg9RbX78.4zgCxMEAat7SolOWQcz4yUuhGWOmtb 4h6HhPOVS.hX4apoEwfO2Jy35Sw4F4s7nE2GOX6RPhYLhRHBiGRJ9e2uWeJl RjfSGlJHyjmvMgB0AQgJw6yIkYV2TdyEQXdO6fCtDXQM7 Received: from [83.101.140.11] by web141002.mail.bf1.yahoo.com via HTTP; Sun, 27 Apr 2014 01:22:59 PDT X-Rocket-MIMEInfo: 002.001, RGVhciBTaXIsIEkgYW0gbmV3IGluIE5ldHdvcmtpbmcgYW5kIGFsc28gbmV3IGluIGZyZWUgQlNELkkgZG9uJ3Qga25vdyBhYm91dCBmcmVlIEJTRCBQcm94eS4KSSBoYXZlIHNvbWUgcXVlc3Rpb24gaSBob3BlIHUgd2lsbCBoZWxwIG1lLgpJIHdhbnQgdG8gaW1wbGVtZW50IGZyZWVCU0QgaW4gbXkgbmV0d29yayBlbnZpcm9ubWVudC5jYW4gYW55IGJvZHkgZ3VpZGUgbWUgd2hhdCBhcmUgdGhlIHBhY2thZ2VzIGkgbmVlZCB0byBpbnN0YWxsIHdpdGggZnJlZSBCU0QuZnJvbSB3aGVyZSBpIHdpbGwgc3RhcnQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.185.657 Message-ID: <1398586979.43416.YahooMailNeo@web141002.mail.bf1.yahoo.com> Date: Sun, 27 Apr 2014 01:22:59 -0700 (PDT) From: Abdul Waheed Subject: Free BSD Question? To: "questions@FreeBSD.org" MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 27 Apr 2014 11:33:47 +0000 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Abdul Waheed List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 08:23:01 -0000 Dear Sir, I am new in Networking and also new in free BSD.I don't know about free BSD Proxy. I have some question i hope u will help me. I want to implement freeBSD in my network environment.can any body guide me what are the packages i need to install with free BSD.from where i will start this.I don't know I want to use FreeBSD 9.1 for following purpose: 1. As a proxy server 2. As a Router what i need to fulfill these requirement.please guide me from start. Thanks for help Abdul From owner-freebsd-ipfw@FreeBSD.ORG Mon Apr 28 11:06:48 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1D5C451 for ; Mon, 28 Apr 2014 11:06:48 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 BEBA01AA6 for ; Mon, 28 Apr 2014 11:06:48 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3SB6mtr086157 for ; Mon, 28 Apr 2014 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3SB6mEx086155 for freebsd-ipfw@FreeBSD.org; Mon, 28 Apr 2014 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 28 Apr 2014 11:06:48 GMT Message-Id: <201404281106.s3SB6mEx086155@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 11:06:49 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/187904 ipfw [ipfw] ipfw(8) does not properly recognize the network o kern/183479 ipfw [ipfw] ipfw table contains duplicate entry. o kern/180731 ipfw [ipfw] problem with displaying 255.255.255.255 address o kern/180729 ipfw [ipfw] ipfw nat show empty output o kern/178482 ipfw [ipfw] logging problem from vnet jail o kern/178480 ipfw [ipfw] dynamically loaded ipfw with a vimage kernel do o kern/178317 ipfw [ipfw] ipfw options need to specifed in specific order o kern/177948 ipfw [ipfw] ipfw fails to parse port ranges (p1-p2) for udp o kern/176503 ipfw [ipfw] ipfw layer2 problem o kern/170604 ipfw [ipfw] ipv6 reass broken o conf/167822 ipfw [ipfw] [patch] start script doesn't load firewall_type o kern/166406 ipfw [ipfw] ipfw does not set ALTQ identifier for ipv6 traf o kern/165939 ipfw [ipfw] bug: incomplete firewall rules loaded if tables o kern/165190 ipfw [ipfw] [lo] [patch] loopback interface is not marking o kern/158066 ipfw [ipfw] ipfw + netgraph + multicast = multicast packets o kern/157689 ipfw [ipfw] ipfw nat config does not accept nonexistent int f kern/155927 ipfw [ipfw] ipfw stops to check packets for compliance with o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw [ipfw] does not support specifying rules with ICMP cod o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. f kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l f kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes s kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 44 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Tue Apr 29 03:28:43 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 19D08A25 for ; Tue, 29 Apr 2014 03:28:43 +0000 (UTC) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) (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 E95408CE for ; Tue, 29 Apr 2014 03:28:42 +0000 (UTC) Received: by mail-pb0-f47.google.com with SMTP id up15so6596734pbc.34 for ; Mon, 28 Apr 2014 20:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/29nMRn7DPNknGLVxtD5ZP/qcBQIxlacPHHyV6jgi8w=; b=k3mTkKALlTfVkutbmp8Qf6ECEQAGOgH4XXPMZrkj/Gyb4SsUNf1cbDGcKBw5bn2lgx Q4LiipTtOd89Us9y7nyyOgmNhUbYHWDBO/d2U4n6iTELQIjgqoh+MPNNUW4T6joGGwGv cJqZ/cguJnvbZaYHJhZZYdvnSq6Bx9IrpjKYWdUKouINBxbnT8pkEV1wRXbWaZR3e/pm re+YiXRhwDHoJ7FHrkqFkGf3glVs6+PFUbxf+4LZ4Y1+qi0qrRQyJT3QRU3DMgtXe7K7 V/WKa6H+GKa0JKpqbk9bYFwxtLFiHkk15BulQBhjoDgnnsNJbukxvbktw6WjWGaEpv2F VELw== MIME-Version: 1.0 X-Received: by 10.66.184.239 with SMTP id ex15mr13496730pac.122.1398742122488; Mon, 28 Apr 2014 20:28:42 -0700 (PDT) Received: by 10.70.126.138 with HTTP; Mon, 28 Apr 2014 20:28:42 -0700 (PDT) Date: Tue, 29 Apr 2014 11:28:42 +0800 Message-ID: Subject: bug in the Makefile From: Bill Yuan To: freebsd-ipfw Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 03:28:43 -0000 I am still using the FreeBSD10. release version, and it said that the cdefs.h is not found, but the file was there, I did not touch it. Can someone help to check #make cc -O2 -pipe -DIPFIREWALL -DIPFIREWALL_VERBOSE -DIPFIREWALL_VERBOSE_LIMIT=1000 -DIPFIREWALL_DEFAULT_TO_ACCEPT -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /usr/src/sys/modules/ipfw/../../netpfil/ipfw/ip_fw2.c /usr/src/sys/modules/ipfw/../../netpfil/ipfw/ip_fw2.c:27:10: fatal error: 'sys/cdefs.h' file not found #include ^ 1 error generated. *** Error code 1 Stop. make: stopped in /usr/src/sys/modules/ipfw #ls /usr/src/sys/sys/cdefs.h /usr/src/sys/sys/cdefs.h # From owner-freebsd-ipfw@FreeBSD.ORG Wed Apr 30 12:52:12 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0FE6FF08 for ; Wed, 30 Apr 2014 12:52:12 +0000 (UTC) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (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 D998A1CC5 for ; Wed, 30 Apr 2014 12:52:11 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id ld10so1906243pab.26 for ; Wed, 30 Apr 2014 05:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=0A7v/YdnJqoCwWYKUtaKci6vp0OsfUp5rMrMxCcld60=; b=rpfwLDL112gv12y/uLG6/xW38190/e1Lq9d/2gp1d073qjYd5raNFGHx5JzP1yeSQc /Jm9NoNvoO+PnPZ2QJmBFALPLB8G6Q3++XQARNMUzBbrOoHkDs39Si76YJlTl+3neZcs 6kp1s/IJctRbH3PkuwRDtkRj2ov6sZWioBu6Y9I1I/un2TAiOQ1Sez9epuKdhK0SwNHl drgyyvcNejaw0Rsv6IzxR5CwDcuz54i8yQuXgCaNJbMJigyRcWbBBWeea60iP8FIaMUc YWsAr7hAXYZcehXTO3o1MF55Mu+R63rNde8rvj/gWFScerk0sJmCMPPgejUWL9bTH+N5 +rTw== X-Received: by 10.66.192.41 with SMTP id hd9mr8136814pac.87.1398862327806; Wed, 30 Apr 2014 05:52:07 -0700 (PDT) Received: from [192.168.1.102] ([203.117.37.53]) by mx.google.com with ESMTPSA id el14sm135267785pac.31.2014.04.30.05.52.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Apr 2014 05:52:07 -0700 (PDT) Message-ID: <5360F1F4.9060808@gmail.com> Date: Wed, 30 Apr 2014 20:52:04 +0800 From: bycn82 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-ipfw@FreeBSD.org Subject: feature of `packet per second` Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 12:52:12 -0000 Hi `packet per second` it is easy to be implemented using iptables, there is a module named `recent`, but in using ipfw, Do we have any solution to fulfill it? check the link below https://forums.freebsd.org/viewtopic.php?f=44&t=42933&p=258441#p258441 bycn82 From owner-freebsd-ipfw@FreeBSD.ORG Wed Apr 30 15:02: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B77F8131 for ; Wed, 30 Apr 2014 15:02:01 +0000 (UTC) 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 8BB3D1C1A for ; Wed, 30 Apr 2014 15:01:58 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-232-70.lns20.per1.internode.on.net [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s3UF1rS8077571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 30 Apr 2014 08:01:55 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5361105C.1040203@freebsd.org> Date: Wed, 30 Apr 2014 23:01:48 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: bycn82 , freebsd-ipfw@FreeBSD.org Subject: Re: feature of `packet per second` References: <5360F1F4.9060808@gmail.com> In-Reply-To: <5360F1F4.9060808@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 15:02:01 -0000 On 4/30/14, 8:52 PM, bycn82 wrote: > Hi > > `packet per second` it is easy to be implemented using iptables, > there is a module named `recent`, but in using ipfw, Do we have any > solution to fulfill it? check the link below > https://forums.freebsd.org/viewtopic.php?f=44&t=42933&p=258441#p258441 since I don't use linux.. what is "packet per second"?.. does it report it or set a limit on it? > > bycn82 > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > From owner-freebsd-ipfw@FreeBSD.ORG Wed Apr 30 15:31:10 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F88B65B; Wed, 30 Apr 2014 15:31:10 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (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 3105D1FDA; Wed, 30 Apr 2014 15:31:10 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id y20so2066448ier.40 for ; Wed, 30 Apr 2014 08:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=BQJgWdOLGobw0Ki7EUHZrJKBswcwgzee+t9FCav8Qc4=; b=vbbHowZOyeX53LhGWJ42ddvwruWnpX1jg2QcLQyrvaPriBGiheHYhf/EKmgFNP16JV RAMWc9DhE/w/zxOglk8wiLrMixGQl9rRTTz55NlrYhN/g/rlvqh4skpMQSh80E1q4bqB N4h1lR/tlIicaYrjZaPPhMYnzH6maWknIkxik08f6bglMNuc3qDwkAKgdLpRmebd6sow jJOgvRoRTZ2f359v7JDtV50nsfPa3I7Q8ZCxjv9Pcf4CmVhhTA+easndFUpdvgEOfmqt RH5dEijKxiRqc78Yyhf5SAkqINWwRcvBqZd8yC6Q/tXytrLY2t6we1MUEmf60aLkFCTE SB8A== X-Received: by 10.50.23.52 with SMTP id j20mr5551114igf.13.1398871867462; Wed, 30 Apr 2014 08:31:07 -0700 (PDT) Received: from [192.168.1.102] ([203.117.37.53]) by mx.google.com with ESMTPSA id fx1sm6777693igd.1.2014.04.30.08.31.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Apr 2014 08:31:06 -0700 (PDT) Message-ID: <53611738.8010103@gmail.com> Date: Wed, 30 Apr 2014 23:31:04 +0800 From: bycn82 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Julian Elischer Subject: Re: feature of `packet per second` References: <5360F1F4.9060808@gmail.com> <5361105C.1040203@freebsd.org> In-Reply-To: <5361105C.1040203@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 15:31:10 -0000 On 4/30/14 23:01, Julian Elischer wrote: > On 4/30/14, 8:52 PM, bycn82 wrote: >> Hi >> >> `packet per second` it is easy to be implemented using iptables, >> there is a module named `recent`, but in using ipfw, Do we have any >> solution to fulfill it? check the link below >> https://forums.freebsd.org/viewtopic.php?f=44&t=42933&p=258441#p258441 > > since I don't use linux.. what is "packet per second"?.. does it > report it or set a limit on it? >> >> bycn82 >> >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >> >> > > Yes, "Packets Per Second"means limit a connection based on the packets number, for example, If I allow 2 ICMP packets come to my server in each individual second. only the first 2 packets will be allow, all others in the same second will be dropped. From owner-freebsd-ipfw@FreeBSD.ORG Wed Apr 30 15:45: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D6FC8D9 for ; Wed, 30 Apr 2014 15:45:13 +0000 (UTC) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (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 6661C117F for ; Wed, 30 Apr 2014 15:45:13 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id o6so2144807oag.22 for ; Wed, 30 Apr 2014 08:45:12 -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=JAd+1dkEOnEOeYBXcA2liYRUOSJzGX+68VzTpXK0rF0=; b=ZzJS+s2Zm0uA+wJznBi9I5vrpzb6j/YD3XPpOyM1OA+bDlly9cpScL5sUmrPPhO0cY lU6XsVW3eioRWM4mtn0SyEto+Or1b8OstgfRMmyTIChUL5eA8u9MDjyvOev6ehdf4XJ6 8oNDSb+pz3FkgAhwLJtQtLF82syHOUF3l+F0jWRpnJjX/rtgytwBMxJrtZ0Bs4s5YAwY PQir87FV5LhUoSoT0D+jo1UdF2H8YDo5l2YNz0LUbowsTmPn1lLAiIG7sTtMJGZfZDtG tFqk4VCVivjMMbBG22hwyjGEDtbHpkVVPXE3s64l1CWpdvNPTuxrZtRXN9pYTj+OzVuJ VRvw== MIME-Version: 1.0 X-Received: by 10.60.159.5 with SMTP id wy5mr2866177oeb.58.1398872712567; Wed, 30 Apr 2014 08:45:12 -0700 (PDT) Received: by 10.76.180.40 with HTTP; Wed, 30 Apr 2014 08:45:12 -0700 (PDT) In-Reply-To: <53611738.8010103@gmail.com> References: <5360F1F4.9060808@gmail.com> <5361105C.1040203@freebsd.org> <53611738.8010103@gmail.com> Date: Wed, 30 Apr 2014 08:45:12 -0700 Message-ID: Subject: Re: feature of `packet per second` From: Freddie Cash To: bycn82 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-ipfw@freebsd.org" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 15:45:13 -0000 On Wed, Apr 30, 2014 at 8:31 AM, bycn82 wrote: > On 4/30/14 23:01, Julian Elischer wrote: > >> On 4/30/14, 8:52 PM, bycn82 wrote: >> >>> Hi >>> >>> `packet per second` it is easy to be implemented using iptables, there >>> is a module named `recent`, but in using ipfw, Do we have any solution = to >>> fulfill it? check the link below >>> https://forums.freebsd.org/viewtopic.php?f=3D44&t=3D42933&p=3D258441#p2= 58441 >>> >> >> since I don't use linux.. what is "packet per second"?.. does it report >> it or set a limit on it? >> >>> >>> bycn82 >>> >>> _______________________________________________ >>> freebsd-ipfw@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >>> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >>> >>> >>> >> >> Yes, "Packets Per Second"means limit a connection based on the packets > number, for example, If I allow 2 ICMP packets come to my server in each > individual second. only the first 2 packets will be allow, all others in > the same second will be dropped. > =E2=80=8BFor ICMP, specifically, there's a sysctl to control the rate (per = second): # sysctl -d =E2=80=8Bnet.inet.icmp.icmplim net.inet.icmp.icmplim: Maximum number of ICMP responses per second For everything else, you'd want to use dummynet(4). --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-ipfw@FreeBSD.ORG Wed Apr 30 16:03:08 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9E54D8D for ; Wed, 30 Apr 2014 16:03:08 +0000 (UTC) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (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 9200C1343 for ; Wed, 30 Apr 2014 16:03:08 +0000 (UTC) Received: by mail-ig0-f173.google.com with SMTP id hl10so7803738igb.0 for ; Wed, 30 Apr 2014 09:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=dbFgJmpBHGJfKQVPZJ6RHlKlFUKSUQs3tpVyUykkdio=; b=Rd8h73GWY6Zg7fPJc03JIhUYHp1zVk8FnHOjAJ7S2HqHCx73beyohf8U3masgGb56v 86rASlJk7UFehHUJ5+2U/pw8lHkg/viRDuvyslVHkx7ByQl7fXR0zadooVJoi1r4+Hyf s19vwu+7LnVPpU5fJ0vkZEi2n/EbVvvNULIXEq4IYZHYkSA86U9Ov0tH8zBkkH4pNRUc JvDhEW+v9evGq1/YqwLSPkUGBP1AaGacIm/t6oHFIfA5OWGQbuF1yu1MOvjl4gpGwiPb b8OZrj+t7Cwb8EY7BAQOL6YN3ejcBljiSGmWza4KzLx0Hog3xUMguA6/dLXtCj5cPQLJ JYrg== X-Received: by 10.50.61.177 with SMTP id q17mr39124981igr.44.1398873786493; Wed, 30 Apr 2014 09:03:06 -0700 (PDT) Received: from [192.168.1.102] ([203.117.37.53]) by mx.google.com with ESMTPSA id b6sm7054954igm.2.2014.04.30.09.03.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Apr 2014 09:03:05 -0700 (PDT) Message-ID: <53611EB1.4000406@gmail.com> Date: Thu, 01 May 2014 00:02:57 +0800 From: bycn82 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Freddie Cash Subject: Re: feature of `packet per second` References: <5360F1F4.9060808@gmail.com> <5361105C.1040203@freebsd.org> <53611738.8010103@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-ipfw@freebsd.org" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 16:03:08 -0000 On 4/30/14 23:45, Freddie Cash wrote: > On Wed, Apr 30, 2014 at 8:31 AM, bycn82 >wrote: > > On 4/30/14 23:01, Julian Elischer wrote: > > On 4/30/14, 8:52 PM, bycn82 wrote: > > Hi > > `packet per second` it is easy to be implemented using > iptables, there is a module named `recent`, but in using > ipfw, Do we have any solution to fulfill it? check the > link below > https://forums.freebsd.org/viewtopic.php?f=44&t=42933&p=258441#p258441 > > > > since I don't use linux.. what is "packet per second"?.. does > it report it or set a limit on it? > > > bycn82 > > _______________________________________________ > freebsd-ipfw@freebsd.org > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to > "freebsd-ipfw-unsubscribe@freebsd.org > " > > > > > Yes, "Packets Per Second"means limit a connection based on the > packets number, for example, If I allow 2 ICMP packets come to my > server in each individual second. only the first 2 packets will > be allow, all others in the same second will be dropped. > > > ​For ICMP, specifically, there's a sysctl to control the rate (per > second): > > # sysctl -d ​net.inet.icmp.icmplim > net.inet.icmp.icmplim: Maximum number of ICMP responses per second > > > For everything else, you'd want to use dummynet(4). > > -- > Freddie Cash > fjwcash@gmail.com Thanks for your reply, and it is good to know the sysctl for ICMP. finally it works.I just added a new `action` in firewall and it is called `pps`, that means it can be generic purpose while the net.inet.icmp.icmplim is only for ICMP traffic. the usage will be like below root@F10:/usr/src/sbin/ipfw # .*/ipfw add pps 1 icmp from any to any* 00100 pps 1 icmp from any to any root@F10:/usr/src/sbin/ipfw # ./ipfw show 00100 9 540 pps 1 icmp from any to any 65535 13319 1958894 allow ip from any to any root@F10:/usr/src/sbin/ipfw # regards, bycn82 From owner-freebsd-ipfw@FreeBSD.ORG Fri May 2 05:56:06 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42EA6E58 for ; Fri, 2 May 2014 05:56:06 +0000 (UTC) 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 0D6961BFF for ; Fri, 2 May 2014 05:56:05 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-232-70.lns20.per1.internode.on.net [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s425u1RR084325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 1 May 2014 22:56:04 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5363336C.7020504@freebsd.org> Date: Fri, 02 May 2014 13:55:56 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: bycn82 , Freddie Cash Subject: Re: feature of `packet per second` References: <5360F1F4.9060808@gmail.com> <5361105C.1040203@freebsd.org> <53611738.8010103@gmail.com> <53611EB1.4000406@gmail.com> In-Reply-To: <53611EB1.4000406@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "freebsd-ipfw@freebsd.org" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 05:56:06 -0000 On 5/1/14, 12:02 AM, bycn82 wrote: > On 4/30/14 23:45, Freddie Cash wrote: >> On Wed, Apr 30, 2014 at 8:31 AM, bycn82 > >wrote: >> >> On 4/30/14 23:01, Julian Elischer wrote: >> >> On 4/30/14, 8:52 PM, bycn82 wrote: >> >> Hi >> >> `packet per second` it is easy to be implemented using >> iptables, there is a module named `recent`, but in using >> ipfw, Do we have any solution to fulfill it? check the >> link below >> https://forums.freebsd.org/viewtopic.php?f=44&t=42933&p=258441#p258441 >> >> >> >> since I don't use linux.. what is "packet per second"?.. does >> it report it or set a limit on it? >> >> >> bycn82 >> >> _______________________________________________ >> freebsd-ipfw@freebsd.org >> mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to >> "freebsd-ipfw-unsubscribe@freebsd.org >> " >> >> >> >> >> Yes, "Packets Per Second"means limit a connection based on the >> packets number, for example, If I allow 2 ICMP packets come to my >> server in each individual second. only the first 2 packets will >> be allow, all others in the same second will be dropped. >> >> >> ​For ICMP, specifically, there's a sysctl to control the rate (per >> second): >> >> # sysctl -d ​net.inet.icmp.icmplim >> net.inet.icmp.icmplim: Maximum number of ICMP responses per second >> >> >> For everything else, you'd want to use dummynet(4). >> >> -- >> Freddie Cash >> fjwcash@gmail.com > Thanks for your reply, and it is good to know the sysctl for ICMP. > > finally it works.I just added a new `action` in firewall and it is > called `pps`, that means it can be generic purpose while the > net.inet.icmp.icmplim is only for ICMP traffic. you probably should be using the dummynet extension to ipfw to do this but post your changes to a freebsd bug report anyhow so we can keep it somewhere. I doubt it would be needed in general as Dummynet give you so much more control and is I think a superset. Don't forget to add a patch for the man page.... a patch with no man page change would never be accepted. > > the usage will be like below > > root@F10:/usr/src/sbin/ipfw # .*/ipfw add pps 1 icmp from any to any* > 00100 pps 1 icmp from any to any > root@F10:/usr/src/sbin/ipfw # ./ipfw show > 00100 9 540 pps 1 icmp from any to any > 65535 13319 1958894 allow ip from any to any > root@F10:/usr/src/sbin/ipfw # > > regards, > bycn82 > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://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 2 07:05:34 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7ACD4E06; Fri, 2 May 2014 07:05: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 49A0A1293; Fri, 2 May 2014 07:05:34 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id x10so4291624pdj.29 for ; Fri, 02 May 2014 00:05:33 -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=vY9ensIdF5uOkN6km2VZ3kp361PR6mA3oLd2mrFE8hs=; b=x87qKf1n7ihNJ7ujVsTmsHEzpFyd4lmDIOGGVsKCrI+PP+GvRWazRujZJN36B8B3WY HAlqeCws93QM9emlnVP5AORk27JA2SAZIIbpRqVNj3fas6facef6Zr4vqgWvvBUPTRSr PWNkpMv3TwinMQUFvsosaXq1wvXOihRXj2btd4W7IjGIL/ht0qy42LrWyOcPjrxFv8d4 +R2YeIRlsrj4For3fHBnDY8de23mCZPwc5F6a+Rb7MApjfEhfxuJyEBGOFiAGsKErp3G eJFcHrLd0s0IONXEONVYnkf9opNkLAxBcLCvqEBiTJ4ndTRjUYqAprOQf36WPHifRZmS zubQ== MIME-Version: 1.0 X-Received: by 10.67.13.226 with SMTP id fb2mr142402pad.146.1399014209013; Fri, 02 May 2014 00:03:29 -0700 (PDT) Received: by 10.70.126.138 with HTTP; Fri, 2 May 2014 00:03:18 -0700 (PDT) In-Reply-To: <5363336C.7020504@freebsd.org> References: <5360F1F4.9060808@gmail.com> <5361105C.1040203@freebsd.org> <53611738.8010103@gmail.com> <53611EB1.4000406@gmail.com> <5363336C.7020504@freebsd.org> Date: Fri, 2 May 2014 15:03:18 +0800 Message-ID: Subject: Re: feature of `packet per second` From: Bill Yuan To: Julian Elischer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-ipfw@freebsd.org" , Freddie Cash X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 07:05:34 -0000 I was coding it in dummynet way yesterday, Personally I prefer to add it as a new action. By the way, Is there anybody want to say something about the ip_fw.h? there are two ip_fw.h files, one in /sys/netinet/ another in usr/include/netinet, it is better to remove one of it , or create a soft link instread? On Fri, May 2, 2014 at 1:55 PM, Julian Elischer wrote: > On 5/1/14, 12:02 AM, bycn82 wrote: > >> On 4/30/14 23:45, Freddie Cash wrote: >> >>> On Wed, Apr 30, 2014 at 8:31 AM, bycn82 >> bycn82@gmail.com>>wrote: >>> >>> >>> On 4/30/14 23:01, Julian Elischer wrote: >>> >>> On 4/30/14, 8:52 PM, bycn82 wrote: >>> >>> Hi >>> >>> `packet per second` it is easy to be implemented using >>> iptables, there is a module named `recent`, but in using >>> ipfw, Do we have any solution to fulfill it? check the >>> link below >>> https://forums.freebsd.org/viewtopic.php?f=3D44&t=3D42933&p=3D258441#p2= 58441 >>> >>> >>> >>> since I don't use linux.. what is "packet per second"?.. does >>> it report it or set a limit on it? >>> >>> >>> bycn82 >>> >>> _______________________________________________ >>> freebsd-ipfw@freebsd.org >>> >>> mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >>> To unsubscribe, send any mail to >>> "freebsd-ipfw-unsubscribe@freebsd.org >>> " >>> >>> >>> >>> >>> >>> Yes, "Packets Per Second"means limit a connection based on the >>> packets number, for example, If I allow 2 ICMP packets come to my >>> server in each individual second. only the first 2 packets will >>> be allow, all others in the same second will be dropped. >>> >>> >>> =E2=80=8BFor ICMP, specifically, there's a sysctl to control the rate (= per >>> second): >>> >>> # sysctl -d =E2=80=8Bnet.inet.icmp.icmplim >>> net.inet.icmp.icmplim: Maximum number of ICMP responses per second >>> >>> >>> For everything else, you'd want to use dummynet(4). >>> >>> -- >>> Freddie Cash >>> fjwcash@gmail.com >>> >> Thanks for your reply, and it is good to know the sysctl for ICMP. >> >> finally it works.I just added a new `action` in firewall and it is calle= d >> `pps`, that means it can be generic purpose while the >> net.inet.icmp.icmplim is only for ICMP traffic. >> > > you probably should be using the dummynet extension to ipfw to do this > but post your changes to a freebsd bug report anyhow so we can keep it > somewhere. > I doubt it would be needed in general as Dummynet give you so much more > control and is I think a superset. > Don't forget to add a patch for the man page.... a patch with no man pag= e > change would never be accepted. > >> >> the usage will be like below >> >> root@F10:/usr/src/sbin/ipfw # .*/ipfw add pps 1 icmp from any to any* >> >> 00100 pps 1 icmp from any to any >> root@F10:/usr/src/sbin/ipfw # ./ipfw show >> 00100 9 540 pps 1 icmp from any to any >> 65535 13319 1958894 allow ip from any to any >> root@F10:/usr/src/sbin/ipfw # >> >> regards, >> bycn82 >> >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> http://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 2 08:59: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E359290 for ; Fri, 2 May 2014 08:59:06 +0000 (UTC) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010: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 D8C921B60 for ; Fri, 2 May 2014 08:59:05 +0000 (UTC) Received: by mail-la0-f44.google.com with SMTP id hr17so2936653lab.3 for ; Fri, 02 May 2014 01:59:03 -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:date:message-id:subject :from:to:cc:content-type; bh=/QdCnhtaSyfw+hYw1n0Ji6QFBHI+ufWf87DrVy6AYc4=; b=e91egh0wnUQtT1/pDGpG6G/5hRb0aHBmhT6OuRZvvO7RDtLZ++RNQjyg0pn17rrtlH ngA74AvAEAqqTWQLOE4ecMqwD4sPeH9TTbcpFG0wpTjdU7cRozxr9vcfqzgsFw5E3VS+ R4d2/G2DsbLJ9yL+HDMrMDqXPZ7ohhYPmJt84i8lKy0+iDyVF2p8ayZLdXjubBzLRVr4 we2wapD1fTvZ95A7PhbAMEhH01tXv0jIQd6pGITEDO+NimfIPOjMupJkA1Kh8nhlWqpa NqciECFP/ia2dqfja5BGtbn2b3DqOs8A851beQvQFZNnSk7p6aGSdNpAYHf2+YrvcOb4 gHhg== MIME-Version: 1.0 X-Received: by 10.112.27.133 with SMTP id t5mr10848833lbg.21.1399021143538; Fri, 02 May 2014 01:59:03 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.107 with HTTP; Fri, 2 May 2014 01:59:03 -0700 (PDT) In-Reply-To: <53611EB1.4000406@gmail.com> References: <5360F1F4.9060808@gmail.com> <5361105C.1040203@freebsd.org> <53611738.8010103@gmail.com> <53611EB1.4000406@gmail.com> Date: Fri, 2 May 2014 10:59:03 +0200 X-Google-Sender-Auth: DQbWoDAdGjFbAtylLcVZj2fJ0vU Message-ID: Subject: Re: feature of `packet per second` From: Luigi Rizzo To: bycn82 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-ipfw@freebsd.org" , Freddie Cash X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 08:59:06 -0000 On Wed, Apr 30, 2014 at 6:02 PM, bycn82 wrote: > >> fjwcash@gmail.com >> > Thanks for your reply, and it is good to know the sysctl for ICMP. > > finally it works.I just added a new `action` in firewall and it is called > `pps`, that means it can be generic purpose while the > net.inet.icmp.icmplim is only for ICMP traffic. > > the usage will be like below > > root@F10:/usr/src/sbin/ipfw # .*/ipfw add pps 1 icmp from any to any* > 00100 pps 1 icmp from any to any > root@F10:/usr/src/sbin/ipfw # ./ipfw show > 00100 9 540 pps 1 icmp from any to any > 65535 13319 1958894 allow ip from any to any > root@F10:/usr/src/sbin/ipfw # > > =E2=80=8Bhi, as julian said it would be great if you would like to share your code so we can integrate it in future ipfw releases. Once again citing Julian, dummynet is a bit of a superset of pps but not exactly, so i see value in the additional feature. One thing =E2=80=8Bto keep in mind in the implementation: the burst size used for limiting is an important parameter that everyone forgets. 1 pps is basically "don't bother me". 1000 pps could be "1000 packets every fixed 1-sec interval" or "1 packet every ms" or (this is more difficult) "20 pkt in the last 50ms interval". If i were to implement the feature i would add two parameters (burst, I_max) with reasonable defaults and compute the internal interval and max_count as follows if (burst > max_pps * I_max) burst =3D max_pps * I_max; // make sure it is not too large else if (burst < max_pps / HZ) burst =3D max_pps * HZ; // nor too small max_count =3D max_pps / burst; interval =3D HZ * burst / max_pps; count =3D 0; // actual counter then add { max_count, interval, timestamp, count } to the rule descriptor. On incoming packets: if (ticks >=3D r->interval + r->timestamp) { r->timestamp =3D r->ticks; r->count =3D 1; return ACCEPT; } if (r->count > r->max_count) return DENY; r->count++; return ACCEPT; cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Sat May 3 12:27:11 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D36A16FF for ; Sat, 3 May 2014 12:27:11 +0000 (UTC) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (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 A38F217DF for ; Sat, 3 May 2014 12:27:11 +0000 (UTC) Received: by mail-pd0-f177.google.com with SMTP id p10so536367pdj.22 for ; Sat, 03 May 2014 05:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=QhLW9p1lF7jovGz5pTS6AMNI5O8y/hAT3fjB/PxVmeE=; b=WHPo2fXq5vHpSsEW0WN5Ec296UDntfU5x79RA0CGKGvZxXdLHjLh0B7S5IzvxOhicB Fyl8Ac1LEkXkB60U0NceddXiLJfUs5LMAnEcUVQRBVPomnS/paI4cIJxDvkdW6v3I5Bo 5FdgT+68YjbtAjwV2g6OSVSvu8uVvQQc9UeKihLn0zEe2BI7nxpi1Bog6uSIIBpuaIsu ecsNf2JtL0aSRTaQqBcZNjIIoRKd8o8vyVCV2Y0Rv3FYFrh5KzAvP05ZoyiPp0n154u8 lquNJDo+VLrVxBLRiW4iVi1ZTX9z0q2rRSodxvgESR0fEJmSUDVzNQwtlDnLoCsOQXWm nAfg== X-Received: by 10.66.240.4 with SMTP id vw4mr47076552pac.26.1399120030663; Sat, 03 May 2014 05:27:10 -0700 (PDT) Received: from [192.168.1.101] ([203.117.37.234]) by mx.google.com with ESMTPSA id tu3sm17602817pab.1.2014.05.03.05.27.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 03 May 2014 05:27:10 -0700 (PDT) Message-ID: <5364E097.9020106@gmail.com> Date: Sat, 03 May 2014 20:27:03 +0800 From: bycn82 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: feature of `packet per second` References: <5360F1F4.9060808@gmail.com> <5361105C.1040203@freebsd.org> <53611738.8010103@gmail.com> <53611EB1.4000406@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-ipfw@freebsd.org" , Freddie Cash X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 12:27:12 -0000 On 5/2/14 16:59, Luigi Rizzo wrote: > > > > On Wed, Apr 30, 2014 at 6:02 PM, bycn82 > wrote: > > > fjwcash@gmail.com > > > > Thanks for your reply, and it is good to know the sysctl for ICMP. > > finally it works.I just added a new `action` in firewall and it is > called `pps`, that means it can be generic purpose while the > net.inet.icmp.icmplim is only for ICMP traffic. > > the usage will be like below > > root@F10:/usr/src/sbin/ipfw # .*/ipfw add pps 1 icmp from any to any* > 00100 pps 1 icmp from any to any > root@F10:/usr/src/sbin/ipfw # ./ipfw show > 00100 9 540 pps 1 icmp from any to any > 65535 13319 1958894 allow ip from any to any > root@F10:/usr/src/sbin/ipfw # > > > ​hi, > as julian said it would be great if you would like to share your code > so we can integrate it in future ipfw releases. > Once again citing Julian, dummynet is a bit of a superset of pps but > not exactly, so i see value in the additional feature. > > One thing ​to keep in mind in the implementation: > > the burst size used for limiting is an important parameter that > everyone forgets. 1 pps is basically "don't bother me". > 1000 pps could be "1000 packets every fixed 1-sec interval" > or "1 packet every ms" or (this is more difficult) > "20 pkt in the last 50ms interval". > > If i were to implement the feature i would add two parameters > (burst, I_max) with reasonable defaults and compute the internal > interval and max_count as follows > if (burst > max_pps * I_max) > burst = max_pps * I_max; // make sure it is not too large > else if (burst < max_pps / HZ) > burst = max_pps * HZ; // nor too small > max_count = max_pps / burst; > interval = HZ * burst / max_pps; > count = 0; // actual counter > > then add { max_count, interval, timestamp, count } to the rule descriptor. > On incoming packets: > > if (ticks >= r->interval + r->timestamp) { > r->timestamp = r->ticks; > r->count = 1; > return ACCEPT; > } > if (r->count > r->max_count) > return DENY; > r->count++; > return ACCEPT; > > cheers > luigi > Hi Luigi, You are right, it will be more generic if provide two parameters as you described, But this PPS feature should not be used to control the traffic rate, the dummynet you provided is the correct way. So I am thinking in what kind of scenario, people need this PPS feature? in my opinion, people will use PPS only when they want to limit the connections/transactions numbers. ( already have limit command to limit the connections) So I think provide a simple PPS feature is good enough, and we can improve it if someone complaint on this. bycn82 From owner-freebsd-ipfw@FreeBSD.ORG Sat May 3 17:19:28 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F8CDF0C for ; Sat, 3 May 2014 17:19:28 +0000 (UTC) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (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 83B1710A5 for ; Sat, 3 May 2014 17:19:27 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id el20so1792630lab.35 for ; Sat, 03 May 2014 10:19:25 -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:date:message-id:subject :from:to:cc:content-type; bh=pmox4Yyy5U0GzUfbwkxIBaLaN2SRi7/HGPDn7mNPyRg=; b=JUdvHX9SC/7sIbGyeJNjvRI5qgmmAub6LtpYnfGX0UG54b2YdtuX2S5FMv9IywktFR H62985YhngitbMkrjl6c480MSos3DNn1cZU2XbGhMQoScyhte/1XplSNth+hzQClFb8Z JWL1AQmBcKe0gqouMR7rKur+UxglT/Vv4CIQX4W4gvpkdg8XqgYub0339kstLdD0gcBB m9o1rwpThXV5+h6WvHtAgTTcumTXkiTMyXEcChkOFALRKnMQjwRpM200bNoHLKS1SBAk 7wf939ySujJD29FcC6j7FHNNj9GhtcNDhMhUncy/gw+ajeMsztavh+hf5iZyVRrNKPCi sgDQ== MIME-Version: 1.0 X-Received: by 10.112.47.3 with SMTP id z3mr12423241lbm.34.1399137565043; Sat, 03 May 2014 10:19:25 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.107 with HTTP; Sat, 3 May 2014 10:19:24 -0700 (PDT) In-Reply-To: <5364E097.9020106@gmail.com> References: <5360F1F4.9060808@gmail.com> <5361105C.1040203@freebsd.org> <53611738.8010103@gmail.com> <53611EB1.4000406@gmail.com> <5364E097.9020106@gmail.com> Date: Sat, 3 May 2014 19:19:24 +0200 X-Google-Sender-Auth: Dy7B8KYVJlHGDKN_0uZ-fhFj4O4 Message-ID: Subject: Re: feature of `packet per second` From: Luigi Rizzo To: bycn82 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-ipfw@freebsd.org" , Freddie Cash X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 17:19:28 -0000 On Sat, May 3, 2014 at 2:27 PM, bycn82 wrote: > On 5/2/14 16:59, Luigi Rizzo wrote: > > > > > On Wed, Apr 30, 2014 at 6:02 PM, bycn82 wrote: > >> >>> fjwcash@gmail.com >>> >> Thanks for your reply, and it is good to know the sysctl for ICMP. >> >> finally it works.I just added a new `action` in firewall and it is calle= d >> `pps`, that means it can be generic purpose while the >> net.inet.icmp.icmplim is only for ICMP traffic. >> >> the usage will be like below >> >> root@F10:/usr/src/sbin/ipfw # .*/ipfw add pps 1 icmp from any to any* >> 00100 pps 1 icmp from any to any >> root@F10:/usr/src/sbin/ipfw # ./ipfw show >> 00100 9 540 pps 1 icmp from any to any >> 65535 13319 1958894 allow ip from any to any >> root@F10:/usr/src/sbin/ipfw # >> >> > =E2=80=8Bhi, > as julian said it would be great if you would like to share your code > so we can integrate it in future ipfw releases. > Once again citing Julian, dummynet is a bit of a superset of pps but > not exactly, so i see value in the additional feature. > > One thing =E2=80=8Bto keep in mind in the implementation: > > the burst size used for limiting is an important parameter that > everyone forgets. 1 pps is basically "don't bother me". > 1000 pps could be "1000 packets every fixed 1-sec interval" > or "1 packet every ms" or (this is more difficult) > "20 pkt in the last 50ms interval". > > If i were to implement the feature i would add two parameters > (burst, I_max) with reasonable defaults and compute the internal > interval and max_count as follows > > if (burst > max_pps * I_max) > burst =3D max_pps * I_max; // make sure it is not too large > else if (burst < max_pps / HZ) > burst =3D max_pps * HZ; // nor too small > max_count =3D max_pps / burst; > interval =3D HZ * burst / max_pps; > count =3D 0; // actual counter > > then add { max_count, interval, timestamp, count } to the rule > descriptor. > On incoming packets: > > if (ticks >=3D r->interval + r->timestamp) { > r->timestamp =3D r->ticks; > r->count =3D 1; > return ACCEPT; > } > if (r->count > r->max_count) > return DENY; > r->count++; > return ACCEPT; > > cheers > luigi > > Hi Luigi, > You are right, it will be more generic if provide two parameters as you > described, > But this PPS feature should not be used to control the traffic rate, the > dummynet you provided is the correct way. > So I am thinking in what kind of scenario, people need this PPS feature? > in my opinion, people will use PPS only when they want to limit the > connections/transactions numbers. ( already have limit command to limit t= he > connections) > So I think provide a simple PPS feature is good enough, and we can improv= e > it if someone complaint on this. > =E2=80=8Bpps has a strong reason to exist because it is a lot cheaper than a dummynet pipe, and given its pur=E2=80=8Bpose is to police traffic (icmp, dns requests, etc) which should not even get close to the limit which is set, I think it is a completely reasonable feature to have. Given that the above code is the complete implementation with the two parameters (burst and interval) there is no reason not to use them, at least internally. Then you could choose not to expose them as part of the user interface (though since you are implementing a new option from scratch, it is completely trivial to parse 1, 2 or 3 arguments and set defaults for the others). cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Sun May 4 02:24:57 2014 Return-Path: Delivered-To: freebsd-ipfw@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 537A31A3; Sun, 4 May 2014 02:24:57 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 27BAF1050; Sun, 4 May 2014 02:24:57 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s442OuwZ026505; Sun, 4 May 2014 02:24:56 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s442OuKG026504; Sun, 4 May 2014 02:24:56 GMT (envelope-from linimon) Date: Sun, 4 May 2014 02:24:56 GMT Message-Id: <201405040224.s442OuKG026504@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/189272: [ipfw] do not work layer allow ip from any to any layer2 in X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 02:24:57 -0000 Old Synopsis: do not work layer allow ip from any to any layer2 in New Synopsis: [ipfw] do not work layer allow ip from any to any layer2 in Responsible-Changed-From-To: freebsd-amd64->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Sun May 4 02:24:26 UTC 2014 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=189272 From owner-freebsd-ipfw@FreeBSD.ORG Sun May 4 08:29:39 2014 Return-Path: Delivered-To: freebsd-ipfw@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E429EB50; Sun, 4 May 2014 08:29:39 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 B69351C61; Sun, 4 May 2014 08:29:39 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s448TdIu088102; Sun, 4 May 2014 08:29:39 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s448TbVE088101; Sun, 4 May 2014 08:29:37 GMT (envelope-from ae) Date: Sun, 4 May 2014 08:29:37 GMT Message-Id: <201405040829.s448TbVE088101@freefall.freebsd.org> To: support@vorkuta.com, ae@FreeBSD.org, freebsd-ipfw@FreeBSD.org, ae@FreeBSD.org From: ae@FreeBSD.org Subject: Re: kern/189272: [ipfw] do not work layer allow ip from any to any layer2 in X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 08:29:40 -0000 Synopsis: [ipfw] do not work layer allow ip from any to any layer2 in State-Changed-From-To: open->closed State-Changed-By: ae State-Changed-When: Sun May 4 08:28:53 UTC 2014 State-Changed-Why: This was fixed in r264813. Thanks. Responsible-Changed-From-To: freebsd-ipfw->ae Responsible-Changed-By: ae Responsible-Changed-When: Sun May 4 08:28:53 UTC 2014 Responsible-Changed-Why: Take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=189272 From owner-freebsd-ipfw@FreeBSD.ORG Mon May 5 11:06:45 2014 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F18CDF3 for ; Mon, 5 May 2014 11:06:45 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 8998D1CEB for ; Mon, 5 May 2014 11:06:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s45B6jWJ083141 for ; Mon, 5 May 2014 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s45B6jpr083138 for freebsd-ipfw@FreeBSD.org; Mon, 5 May 2014 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 May 2014 11:06:45 GMT Message-Id: <201405051106.s45B6jpr083138@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 11:06:45 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/187904 ipfw [ipfw] ipfw(8) does not properly recognize the network o kern/183479 ipfw [ipfw] ipfw table contains duplicate entry. o kern/180731 ipfw [ipfw] problem with displaying 255.255.255.255 address o kern/180729 ipfw [ipfw] ipfw nat show empty output o kern/178482 ipfw [ipfw] logging problem from vnet jail o kern/178480 ipfw [ipfw] dynamically loaded ipfw with a vimage kernel do o kern/178317 ipfw [ipfw] ipfw options need to specifed in specific order o kern/177948 ipfw [ipfw] ipfw fails to parse port ranges (p1-p2) for udp o kern/176503 ipfw [ipfw] ipfw layer2 problem o kern/170604 ipfw [ipfw] ipv6 reass broken o conf/167822 ipfw [ipfw] [patch] start script doesn't load firewall_type o kern/166406 ipfw [ipfw] ipfw does not set ALTQ identifier for ipv6 traf o kern/165939 ipfw [ipfw] bug: incomplete firewall rules loaded if tables o kern/165190 ipfw [ipfw] [lo] [patch] loopback interface is not marking o kern/158066 ipfw [ipfw] ipfw + netgraph + multicast = multicast packets o kern/157689 ipfw [ipfw] ipfw nat config does not accept nonexistent int f kern/155927 ipfw [ipfw] ipfw stops to check packets for compliance with o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw [ipfw] does not support specifying rules with ICMP cod o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. f kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l f kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes s kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 44 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon May 5 15:10:02 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07EFCE13 for ; Mon, 5 May 2014 15:10:01 +0000 (UTC) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (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 B01D51799 for ; Mon, 5 May 2014 15:10:01 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id rl12so8311488iec.0 for ; Mon, 05 May 2014 08:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=FajInMP/mJO5puAkd9GRtb37jLFhTzigWTGsexUu8eM=; b=xTlV00zqRjHM+wsXrjJESlQkb52EMrGYzlHCulIfpS4PNqUdpRTkx/in/TPaXwEnrd wH6rfmVJHt0LJb/xqSgnHgBRyChYQcRsKJhmvnM843iCDTFZK2y2f4BFZK9bnuCzUFCY a9pMJKdI+Dv1VvvD7TiycaWUD9ZBpR2UlCy1+LDESqkKStA3NkCjYq8vLcBcDm1oqfZe fOFyTRY9LdhgXcfH7LCruXrVijP9NsemIXipuFSlAHTZ2uefnpVmtW9vryz1WWvBsCZ0 bC3c1XRF6gIF4NS/bBlyTOlj45aHEdqxRXnDDzLdBFceDNNuMgZHKIX1VTraiG3HMO17 uB7g== X-Received: by 10.43.13.134 with SMTP id pm6mr3864304icb.79.1399302601093; Mon, 05 May 2014 08:10:01 -0700 (PDT) Received: from [192.168.1.101] ([203.116.251.237]) by mx.google.com with ESMTPSA id s1sm28210766igr.14.2014.05.05.08.09.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 May 2014 08:09:59 -0700 (PDT) Message-ID: <5367A9C0.8000105@gmail.com> Date: Mon, 05 May 2014 23:09:52 +0800 From: bycn82 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: feature of `packet per second` References: <5360F1F4.9060808@gmail.com> <5361105C.1040203@freebsd.org> <53611738.8010103@gmail.com> <53611EB1.4000406@gmail.com> <5364E097.9020106@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-ipfw@freebsd.org" , Freddie Cash X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 15:10:02 -0000 On 5/4/14 1:19, Luigi Rizzo wrote: > > > > On Sat, May 3, 2014 at 2:27 PM, bycn82 > wrote: > > On 5/2/14 16:59, Luigi Rizzo wrote: >> >> >> >> On Wed, Apr 30, 2014 at 6:02 PM, bycn82 > > wrote: >> >> >> fjwcash@gmail.com >> > >> >> Thanks for your reply, and it is good to know the sysctl for >> ICMP. >> >> finally it works.I just added a new `action` in firewall and >> it is called `pps`, that means it can be generic purpose >> while the net.inet.icmp.icmplim is only for ICMP traffic. >> >> the usage will be like below >> >> root@F10:/usr/src/sbin/ipfw # .*/ipfw add pps 1 icmp from any >> to any* >> 00100 pps 1 icmp from any to any >> root@F10:/usr/src/sbin/ipfw # ./ipfw show >> 00100 9 540 pps 1 icmp from any to any >> 65535 13319 1958894 allow ip from any to any >> root@F10:/usr/src/sbin/ipfw # >> >> >> ​hi, >> as julian said it would be great if you would like to share your code >> so we can integrate it in future ipfw releases. >> Once again citing Julian, dummynet is a bit of a superset of pps but >> not exactly, so i see value in the additional feature. >> >> One thing ​to keep in mind in the implementation: >> >> the burst size used for limiting is an important parameter that >> everyone forgets. 1 pps is basically "don't bother me". >> 1000 pps could be "1000 packets every fixed 1-sec interval" >> or "1 packet every ms" or (this is more difficult) >> "20 pkt in the last 50ms interval". >> >> If i were to implement the feature i would add two parameters >> (burst, I_max) with reasonable defaults and compute the internal >> interval and max_count as follows >> if (burst > max_pps * I_max) >> burst = max_pps * I_max; // make sure it is not too large >> else if (burst < max_pps / HZ) >> burst = max_pps * HZ; // nor too small >> max_count = max_pps / burst; >> interval = HZ * burst / max_pps; >> count = 0; // actual counter >> >> then add { max_count, interval, timestamp, count } to the rule >> descriptor. >> On incoming packets: >> >> if (ticks >= r->interval + r->timestamp) { >> r->timestamp = r->ticks; >> r->count = 1; >> return ACCEPT; >> } >> if (r->count > r->max_count) >> return DENY; >> r->count++; >> return ACCEPT; >> >> cheers >> luigi >> > Hi Luigi, > You are right, it will be more generic if provide two parameters > as you described, > But this PPS feature should not be used to control the traffic > rate, the dummynet you provided is the correct way. > So I am thinking in what kind of scenario, people need this PPS > feature? > in my opinion, people will use PPS only when they want to limit > the connections/transactions numbers. ( already have limit command > to limit the connections) > So I think provide a simple PPS feature is good enough, and we can > improve it if someone complaint on this. > > > ​pps has a strong reason to exist because it is a lot cheaper > than a dummynet pipe, and given its pur​pose is to police > traffic (icmp, dns requests, etc) which should not even > get close to the limit which is set, I think it is > a completely reasonable feature to have. > > Given that the above code is the complete implementation > with the two parameters (burst and interval) there is no > reason not to use them, at least internally. > > Then you could choose not to expose them as part of the > user interface (though since you are implementing a new > option from scratch, it is completely trivial to > parse 1, 2 or 3 arguments and set defaults for the others). > > cheers > luigi I got you point and I totally agree with you. but i have 2 questions i am not sure about. 1. the action in current ipfw can accept 1 parameter only. the ipfw_insn is 32 bit only. 2. system will maintain the uptime or the system time in seconds, if we need the millisecond, that means will have extra cost. is it worst? or can we get `current time ` in millisecond directly ? From owner-freebsd-ipfw@FreeBSD.ORG Thu May 8 00:35:12 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CB49EAD for ; Thu, 8 May 2014 00:35:12 +0000 (UTC) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (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 1B6EC24F for ; Thu, 8 May 2014 00:35:12 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id fb1so1895238pad.23 for ; Wed, 07 May 2014 17:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=l3Nf2v5MOT0lrcynufDIktGBSLZWiV/QaLV0/ry9ltA=; b=AiniKKdZeNUuQCp3pu2LeSqjxkJqSrbyJ4/Ozmr1uY7wjdcBp9tzK+RoCfL9lMajkp anLl1SrfPnPEwQXR2WKf4AUWYlMtZSzVQDyVdiiP5qroFAd2aDlt0UuBwv9lSfTGvYd9 dZzW7W5tvLJl/dj/fyz+GaZSuCacqR+W6pUveSt95CZ9km9ddDUMsJ19nQhjjdqwU7yL oU2ChvCp+ThOmCwZUx5eYSor0kmKjT4Tyrx1WcJZQcrfSUaCSdWpVNLp/p+nC39GM2pY nXBQlPsKvtOWOP5gC6p8Pyxys3z4vLkgGvPXEBu+iIgCFUlFX4NG9aNrSKcLw83+XKwc wVYA== X-Received: by 10.66.180.168 with SMTP id dp8mr831402pac.100.1399509311725; Wed, 07 May 2014 17:35:11 -0700 (PDT) Received: from [192.168.1.101] ([203.117.37.234]) by mx.google.com with ESMTPSA id hb10sm5322374pbd.75.2014.05.07.17.35.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 May 2014 17:35:10 -0700 (PDT) Message-ID: <536AD13B.6080907@gmail.com> Date: Thu, 08 May 2014 08:35:07 +0800 From: bycn82 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: feature of `packet per second` References: <5360F1F4.9060808@gmail.com> <5361105C.1040203@freebsd.org> <53611738.8010103@gmail.com> <53611EB1.4000406@gmail.com> <5364E097.9020106@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-ipfw@freebsd.org" , Freddie Cash X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 00:35:12 -0000 On 5/4/14 1:19, Luigi Rizzo wrote: > > > > On Sat, May 3, 2014 at 2:27 PM, bycn82 > wrote: > > On 5/2/14 16:59, Luigi Rizzo wrote: >> >> >> >> On Wed, Apr 30, 2014 at 6:02 PM, bycn82 > > wrote: >> >> >> fjwcash@gmail.com >> > >> >> Thanks for your reply, and it is good to know the sysctl for >> ICMP. >> >> finally it works.I just added a new `action` in firewall and >> it is called `pps`, that means it can be generic purpose >> while the net.inet.icmp.icmplim is only for ICMP traffic. >> >> the usage will be like below >> >> root@F10:/usr/src/sbin/ipfw # .*/ipfw add pps 1 icmp from any >> to any* >> 00100 pps 1 icmp from any to any >> root@F10:/usr/src/sbin/ipfw # ./ipfw show >> 00100 9 540 pps 1 icmp from any to any >> 65535 13319 1958894 allow ip from any to any >> root@F10:/usr/src/sbin/ipfw # >> >> >> ​hi, >> as julian said it would be great if you would like to share your code >> so we can integrate it in future ipfw releases. >> Once again citing Julian, dummynet is a bit of a superset of pps but >> not exactly, so i see value in the additional feature. >> >> One thing ​to keep in mind in the implementation: >> >> the burst size used for limiting is an important parameter that >> everyone forgets. 1 pps is basically "don't bother me". >> 1000 pps could be "1000 packets every fixed 1-sec interval" >> or "1 packet every ms" or (this is more difficult) >> "20 pkt in the last 50ms interval". >> >> If i were to implement the feature i would add two parameters >> (burst, I_max) with reasonable defaults and compute the internal >> interval and max_count as follows >> if (burst > max_pps * I_max) >> burst = max_pps * I_max; // make sure it is not too large >> else if (burst < max_pps / HZ) >> burst = max_pps * HZ; // nor too small >> max_count = max_pps / burst; >> interval = HZ * burst / max_pps; >> count = 0; // actual counter >> >> then add { max_count, interval, timestamp, count } to the rule >> descriptor. >> On incoming packets: >> >> if (ticks >= r->interval + r->timestamp) { >> r->timestamp = r->ticks; >> r->count = 1; >> return ACCEPT; >> } >> if (r->count > r->max_count) >> return DENY; >> r->count++; >> return ACCEPT; >> >> cheers >> luigi >> > Hi Luigi, > You are right, it will be more generic if provide two parameters > as you described, > But this PPS feature should not be used to control the traffic > rate, the dummynet you provided is the correct way. > So I am thinking in what kind of scenario, people need this PPS > feature? > in my opinion, people will use PPS only when they want to limit > the connections/transactions numbers. ( already have limit command > to limit the connections) > So I think provide a simple PPS feature is good enough, and we can > improve it if someone complaint on this. > > > ​pps has a strong reason to exist because it is a lot cheaper > than a dummynet pipe, and given its pur​pose is to police > traffic (icmp, dns requests, etc) which should not even > get close to the limit which is set, I think it is > a completely reasonable feature to have. > > Given that the above code is the complete implementation > with the two parameters (burst and interval) there is no > reason not to use them, at least internally. > > Then you could choose not to expose them as part of the > user interface (though since you are implementing a new > option from scratch, it is completely trivial to > parse 1, 2 or 3 arguments and set defaults for the others). > > cheers > luigi OK, PPS with 2 parameters , it is done, But how to get the current time in millisecond? any recommendation? From owner-freebsd-ipfw@FreeBSD.ORG Thu May 8 01:09:27 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B911C542 for ; Thu, 8 May 2014 01:09:27 +0000 (UTC) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (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 8736E69B for ; Thu, 8 May 2014 01:09:27 +0000 (UTC) Received: by mail-pd0-f176.google.com with SMTP id y13so1741134pdi.7 for ; Wed, 07 May 2014 18:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=gSkWMWq4DvbcKHWbNRruBrCW1o+hHAvg4t8tp0f3xzM=; b=CnQbApRU0VHiIG/D0Btjkg+ISpx6YrK0Ju+x49XQkU3atUMdZhT9Einn/SWuUuBdUX XCuSh40Pq7CCg1vHN8pPFOkSQP5bQMOYlU3ErR8zs/46nP9u8tlpHOyxqOrJR70L2gMK 4LDPddWfb46kd4bpW3z+tYwQxycps6QQZJyetMa8vKeit/SsrJC5Cs2VPbADeErLbDsO /ZfPSmd4+cJPxsl8tkpGLGaJj4sZyKGxyrVJwiJklNiIqmI/cUeisAjj/jbJ0ea16oul R8uAiPvwdJqz40/dg+chD5qhrc7V5Qlt5h21J6Y5t+MPnrvYiuZ0lqB17l6HKI1Tbx1p mdIg== X-Received: by 10.66.141.144 with SMTP id ro16mr797694pab.131.1399511366930; Wed, 07 May 2014 18:09:26 -0700 (PDT) Received: from [192.168.1.101] ([203.117.37.234]) by mx.google.com with ESMTPSA id kj11sm5446698pbd.8.2014.05.07.18.09.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 May 2014 18:09:25 -0700 (PDT) Message-ID: <536AD941.9090102@gmail.com> Date: Thu, 08 May 2014 09:09:21 +0800 From: bycn82 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: feature of `packet per second` References: <5360F1F4.9060808@gmail.com> <5361105C.1040203@freebsd.org> <53611738.8010103@gmail.com> <53611EB1.4000406@gmail.com> <5364E097.9020106@gmail.com> <536AD13B.6080907@gmail.com> In-Reply-To: <536AD13B.6080907@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-ipfw@freebsd.org" , Freddie Cash X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 01:09:27 -0000 On 5/8/14 8:35, bycn82 wrote: > On 5/4/14 1:19, Luigi Rizzo wrote: >> >> >> >> On Sat, May 3, 2014 at 2:27 PM, bycn82 > > wrote: >> >> On 5/2/14 16:59, Luigi Rizzo wrote: >>> >>> >>> >>> On Wed, Apr 30, 2014 at 6:02 PM, bycn82 >> > wrote: >>> >>> >>> fjwcash@gmail.com >>> > >>> >>> Thanks for your reply, and it is good to know the sysctl >>> for ICMP. >>> >>> finally it works.I just added a new `action` in firewall and >>> it is called `pps`, that means it can be generic purpose >>> while the net.inet.icmp.icmplim is only for ICMP traffic. >>> >>> the usage will be like below >>> >>> root@F10:/usr/src/sbin/ipfw # .*/ipfw add pps 1 icmp from >>> any to any* >>> 00100 pps 1 icmp from any to any >>> root@F10:/usr/src/sbin/ipfw # ./ipfw show >>> 00100 9 540 pps 1 icmp from any to any >>> 65535 13319 1958894 allow ip from any to any >>> root@F10:/usr/src/sbin/ipfw # >>> >>> >>> ​hi, >>> as julian said it would be great if you would like to share your >>> code >>> so we can integrate it in future ipfw releases. >>> Once again citing Julian, dummynet is a bit of a superset of pps but >>> not exactly, so i see value in the additional feature. >>> >>> One thing ​to keep in mind in the implementation: >>> >>> the burst size used for limiting is an important parameter that >>> everyone forgets. 1 pps is basically "don't bother me". >>> 1000 pps could be "1000 packets every fixed 1-sec interval" >>> or "1 packet every ms" or (this is more difficult) >>> "20 pkt in the last 50ms interval". >>> >>> If i were to implement the feature i would add two parameters >>> (burst, I_max) with reasonable defaults and compute the internal >>> interval and max_count as follows >>> if (burst > max_pps * I_max) >>> burst = max_pps * I_max; // make sure it is not too large >>> else if (burst < max_pps / HZ) >>> burst = max_pps * HZ; // nor too small >>> max_count = max_pps / burst; >>> interval = HZ * burst / max_pps; >>> count = 0; // actual counter >>> >>> then add { max_count, interval, timestamp, count } to the rule >>> descriptor. >>> On incoming packets: >>> >>> if (ticks >= r->interval + r->timestamp) { >>> r->timestamp = r->ticks; >>> r->count = 1; >>> return ACCEPT; >>> } >>> if (r->count > r->max_count) >>> return DENY; >>> r->count++; >>> return ACCEPT; >>> >>> cheers >>> luigi >>> >> Hi Luigi, >> You are right, it will be more generic if provide two parameters >> as you described, >> But this PPS feature should not be used to control the traffic >> rate, the dummynet you provided is the correct way. >> So I am thinking in what kind of scenario, people need this PPS >> feature? >> in my opinion, people will use PPS only when they want to limit >> the connections/transactions numbers. ( already have limit >> command to limit the connections) >> So I think provide a simple PPS feature is good enough, and we >> can improve it if someone complaint on this. >> >> >> ​pps has a strong reason to exist because it is a lot cheaper >> than a dummynet pipe, and given its pur​pose is to police >> traffic (icmp, dns requests, etc) which should not even >> get close to the limit which is set, I think it is >> a completely reasonable feature to have. >> >> Given that the above code is the complete implementation >> with the two parameters (burst and interval) there is no >> reason not to use them, at least internally. >> >> Then you could choose not to expose them as part of the >> user interface (though since you are implementing a new >> option from scratch, it is completely trivial to >> parse 1, 2 or 3 arguments and set defaults for the others). >> >> cheers >> luigi > OK, PPS with 2 parameters , it is done, > But how to get the current time in millisecond? > any recommendation? In order to get the millisecond, i tried to include the timeb.h but i met below n file included from /usr/src/sys/modules/ipfw/../../netpfil/ipfw/ip_fw2.c:42: @/sys/timeb.h:42:2: error: "this file includes which is deprecated" [-Werror,-W#warnings] #warning "this file includes which is deprecated" ^ any replacement for timeb.h From owner-freebsd-ipfw@FreeBSD.ORG Thu May 8 07:34:19 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BEF16F1 for ; Thu, 8 May 2014 07:34:19 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id DFBA39E7 for ; Thu, 8 May 2014 07:34:18 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 52B7B7300A; Thu, 8 May 2014 09:38:16 +0200 (CEST) Date: Thu, 8 May 2014 09:38:16 +0200 From: Luigi Rizzo To: bycn82 Subject: Re: feature of `packet per second` Message-ID: <20140508073816.GB64368@onelab2.iet.unipi.it> References: <5360F1F4.9060808@gmail.com> <5361105C.1040203@freebsd.org> <53611738.8010103@gmail.com> <53611EB1.4000406@gmail.com> <5364E097.9020106@gmail.com> <536AD13B.6080907@gmail.com> <536AD941.9090102@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <536AD941.9090102@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "freebsd-ipfw@freebsd.org" , Freddie Cash X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 07:34:19 -0000 On Thu, May 08, 2014 at 09:09:21AM +0800, bycn82 wrote: > On 5/8/14 8:35, bycn82 wrote: > > On 5/4/14 1:19, Luigi Rizzo wrote: > >> > >> > >> > >> On Sat, May 3, 2014 at 2:27 PM, bycn82 >> > wrote: > >> > >> On 5/2/14 16:59, Luigi Rizzo wrote: > >>> > >>> > >>> > >>> On Wed, Apr 30, 2014 at 6:02 PM, bycn82 >>> > wrote: > >>> > >>> > >>> fjwcash@gmail.com > >>> > > >>> > >>> Thanks for your reply, and it is good to know the sysctl > >>> for ICMP. > >>> > >>> finally it works.I just added a new `action` in firewall and > >>> it is called `pps`, that means it can be generic purpose > >>> while the net.inet.icmp.icmplim is only for ICMP traffic. > >>> > >>> the usage will be like below > >>> > >>> root@F10:/usr/src/sbin/ipfw # .*/ipfw add pps 1 icmp from > >>> any to any* > >>> 00100 pps 1 icmp from any to any > >>> root@F10:/usr/src/sbin/ipfw # ./ipfw show > >>> 00100 9 540 pps 1 icmp from any to any > >>> 65535 13319 1958894 allow ip from any to any > >>> root@F10:/usr/src/sbin/ipfw # > >>> > >>> > >>> ???hi, > >>> as julian said it would be great if you would like to share your > >>> code > >>> so we can integrate it in future ipfw releases. > >>> Once again citing Julian, dummynet is a bit of a superset of pps but > >>> not exactly, so i see value in the additional feature. > >>> > >>> One thing ???to keep in mind in the implementation: > >>> > >>> the burst size used for limiting is an important parameter that > >>> everyone forgets. 1 pps is basically "don't bother me". > >>> 1000 pps could be "1000 packets every fixed 1-sec interval" > >>> or "1 packet every ms" or (this is more difficult) > >>> "20 pkt in the last 50ms interval". > >>> > >>> If i were to implement the feature i would add two parameters > >>> (burst, I_max) with reasonable defaults and compute the internal > >>> interval and max_count as follows > >>> if (burst > max_pps * I_max) > >>> burst = max_pps * I_max; // make sure it is not too large > >>> else if (burst < max_pps / HZ) > >>> burst = max_pps * HZ; // nor too small > >>> max_count = max_pps / burst; > >>> interval = HZ * burst / max_pps; > >>> count = 0; // actual counter > >>> > >>> then add { max_count, interval, timestamp, count } to the rule > >>> descriptor. > >>> On incoming packets: > >>> > >>> if (ticks >= r->interval + r->timestamp) { > >>> r->timestamp = r->ticks; > >>> r->count = 1; > >>> return ACCEPT; > >>> } > >>> if (r->count > r->max_count) > >>> return DENY; > >>> r->count++; > >>> return ACCEPT; > >>> > >>> cheers > >>> luigi > >>> > >> Hi Luigi, > >> You are right, it will be more generic if provide two parameters > >> as you described, > >> But this PPS feature should not be used to control the traffic > >> rate, the dummynet you provided is the correct way. > >> So I am thinking in what kind of scenario, people need this PPS > >> feature? > >> in my opinion, people will use PPS only when they want to limit > >> the connections/transactions numbers. ( already have limit > >> command to limit the connections) > >> So I think provide a simple PPS feature is good enough, and we > >> can improve it if someone complaint on this. > >> > >> > >> ???pps has a strong reason to exist because it is a lot cheaper > >> than a dummynet pipe, and given its pur???pose is to police > >> traffic (icmp, dns requests, etc) which should not even > >> get close to the limit which is set, I think it is > >> a completely reasonable feature to have. > >> > >> Given that the above code is the complete implementation > >> with the two parameters (burst and interval) there is no > >> reason not to use them, at least internally. > >> > >> Then you could choose not to expose them as part of the > >> user interface (though since you are implementing a new > >> option from scratch, it is completely trivial to > >> parse 1, 2 or 3 arguments and set defaults for the others). > >> > >> cheers > >> luigi > > OK, PPS with 2 parameters , it is done, > > But how to get the current time in millisecond? > > any recommendation? > In order to get the millisecond, i tried to include the timeb.h but i > met below FreeBSD has a global kernel variable called ticks which increments (roughly) HZ times per second and is all you need for this kind of coarse estimates. In linux there is something similar (jiffies maybe ?), and the code to build ipfw on linux does some reasonable mapping. The code i posted is, i believe, complete and contains all the details. cheers luigi > > n file included from > /usr/src/sys/modules/ipfw/../../netpfil/ipfw/ip_fw2.c:42: > @/sys/timeb.h:42:2: error: "this file includes which is > deprecated" > [-Werror,-W#warnings] > #warning "this file includes which is deprecated" > ^ > any replacement for timeb.h From owner-freebsd-ipfw@FreeBSD.ORG Thu May 8 16:11:22 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 025C6162 for ; Thu, 8 May 2014 16:11:22 +0000 (UTC) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (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 C2F19224 for ; Thu, 8 May 2014 16:11:21 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id kp14so3032809pab.26 for ; Thu, 08 May 2014 09:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=NQhpZ060eEBSVzqQStbRoQiahypZzG70XmImWLKtFyA=; b=ka8vBZ1WMjNtDcR7AlR0JWiW+c5q3Xgf3p7wyJavKa/0Hpdf2nWiB4yIB7a/HkBuA3 5R9guW1UY8xizzQYIlMrEK1+33J1PnibFE+eYn8P0FfRjFNGm0KUjFAVqeO9kfny6Kcb JZm9pJjUXqVhtHNFLjUN8CXjPOY59QuVPuKe2qg8l2hsI+h8EC9F1pvPsNpe7ZUyXlCZ Qbvjg465bwiSvpmLEhDQP7uM0dDTTLpl+n/0mSMwq+WHBOlJhikQ9VaiLbn9PySbEKlR NIqz+YjL5a8fQ/p49R4LopA2gyNYIvIjXfoiMqar5wbTacTEbt36TMugQ62Ch53ou21r wU6w== X-Received: by 10.66.122.72 with SMTP id lq8mr9200990pab.69.1399565481371; Thu, 08 May 2014 09:11:21 -0700 (PDT) Received: from [192.168.1.102] ([203.117.37.234]) by mx.google.com with ESMTPSA id ba5sm2762125pbc.61.2014.05.08.09.11.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 May 2014 09:11:20 -0700 (PDT) Message-ID: <536BACA4.7010702@gmail.com> Date: Fri, 09 May 2014 00:11:16 +0800 From: bycn82 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: feature of `packet per second` References: <5360F1F4.9060808@gmail.com> <5361105C.1040203@freebsd.org> <53611738.8010103@gmail.com> <53611EB1.4000406@gmail.com> <5364E097.9020106@gmail.com> <536AD13B.6080907@gmail.com> <536AD941.9090102@gmail.com> <20140508073816.GB64368@onelab2.iet.unipi.it> In-Reply-To: <20140508073816.GB64368@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-ipfw@freebsd.org" , Freddie Cash X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 16:11:22 -0000 On 5/8/14 15:38, Luigi Rizzo wrote: > On Thu, May 08, 2014 at 09:09:21AM +0800, bycn82 wrote: >> On 5/8/14 8:35, bycn82 wrote: >>> On 5/4/14 1:19, Luigi Rizzo wrote: >>>> >>>> >>>> On Sat, May 3, 2014 at 2:27 PM, bycn82>>> > wrote: >>>> >>>> On 5/2/14 16:59, Luigi Rizzo wrote: >>>>> >>>>> >>>>> On Wed, Apr 30, 2014 at 6:02 PM, bycn82>>>> > wrote: >>>>> >>>>> >>>>> fjwcash@gmail.com >>>>> > >>>>> >>>>> Thanks for your reply, and it is good to know the sysctl >>>>> for ICMP. >>>>> >>>>> finally it works.I just added a new `action` in firewall and >>>>> it is called `pps`, that means it can be generic purpose >>>>> while the net.inet.icmp.icmplim is only for ICMP traffic. >>>>> >>>>> the usage will be like below >>>>> >>>>> root@F10:/usr/src/sbin/ipfw # .*/ipfw add pps 1 icmp from >>>>> any to any* >>>>> 00100 pps 1 icmp from any to any >>>>> root@F10:/usr/src/sbin/ipfw # ./ipfw show >>>>> 00100 9 540 pps 1 icmp from any to any >>>>> 65535 13319 1958894 allow ip from any to any >>>>> root@F10:/usr/src/sbin/ipfw # >>>>> >>>>> >>>>> ???hi, >>>>> as julian said it would be great if you would like to share your >>>>> code >>>>> so we can integrate it in future ipfw releases. >>>>> Once again citing Julian, dummynet is a bit of a superset of pps but >>>>> not exactly, so i see value in the additional feature. >>>>> >>>>> One thing ???to keep in mind in the implementation: >>>>> >>>>> the burst size used for limiting is an important parameter that >>>>> everyone forgets. 1 pps is basically "don't bother me". >>>>> 1000 pps could be "1000 packets every fixed 1-sec interval" >>>>> or "1 packet every ms" or (this is more difficult) >>>>> "20 pkt in the last 50ms interval". >>>>> >>>>> If i were to implement the feature i would add two parameters >>>>> (burst, I_max) with reasonable defaults and compute the internal >>>>> interval and max_count as follows >>>>> if (burst> max_pps * I_max) >>>>> burst = max_pps * I_max; // make sure it is not too large >>>>> else if (burst< max_pps / HZ) >>>>> burst = max_pps * HZ; // nor too small >>>>> max_count = max_pps / burst; >>>>> interval = HZ * burst / max_pps; >>>>> count = 0; // actual counter >>>>> >>>>> then add { max_count, interval, timestamp, count } to the rule >>>>> descriptor. >>>>> On incoming packets: >>>>> >>>>> if (ticks>= r->interval + r->timestamp) { >>>>> r->timestamp = r->ticks; >>>>> r->count = 1; >>>>> return ACCEPT; >>>>> } >>>>> if (r->count> r->max_count) >>>>> return DENY; >>>>> r->count++; >>>>> return ACCEPT; >>>>> >>>>> cheers >>>>> luigi >>>>> >>>> Hi Luigi, >>>> You are right, it will be more generic if provide two parameters >>>> as you described, >>>> But this PPS feature should not be used to control the traffic >>>> rate, the dummynet you provided is the correct way. >>>> So I am thinking in what kind of scenario, people need this PPS >>>> feature? >>>> in my opinion, people will use PPS only when they want to limit >>>> the connections/transactions numbers. ( already have limit >>>> command to limit the connections) >>>> So I think provide a simple PPS feature is good enough, and we >>>> can improve it if someone complaint on this. >>>> >>>> >>>> ???pps has a strong reason to exist because it is a lot cheaper >>>> than a dummynet pipe, and given its pur???pose is to police >>>> traffic (icmp, dns requests, etc) which should not even >>>> get close to the limit which is set, I think it is >>>> a completely reasonable feature to have. >>>> >>>> Given that the above code is the complete implementation >>>> with the two parameters (burst and interval) there is no >>>> reason not to use them, at least internally. >>>> >>>> Then you could choose not to expose them as part of the >>>> user interface (though since you are implementing a new >>>> option from scratch, it is completely trivial to >>>> parse 1, 2 or 3 arguments and set defaults for the others). >>>> >>>> cheers >>>> luigi >>> OK, PPS with 2 parameters , it is done, >>> But how to get the current time in millisecond? >>> any recommendation? >> In order to get the millisecond, i tried to include the timeb.h but i >> met below > FreeBSD has a global kernel variable called ticks which increments > (roughly) HZ times per second and is all you need for this > kind of coarse estimates. > In linux there is something similar (jiffies maybe ?), > and the code to build ipfw on linux does some reasonable > mapping. > > The code i posted is, i believe, complete and contains > all the details. > > cheers > luigi > >> n file included from >> /usr/src/sys/modules/ipfw/../../netpfil/ipfw/ip_fw2.c:42: >> @/sys/timeb.h:42:2: error: "this file includes which is >> deprecated" >> [-Werror,-W#warnings] >> #warning "this file includes which is deprecated" >> ^ >> any replacement for timeb.h Man page patch for PPS .It Cm pps Ar limit duration Rule with the .Cm pps keyword will allow the first .Ar limit packets in each .Ar duration milliseconds. and it will be like blow pps _limit duration_ Rule with the pps keyword will allow the first _limit _packets in each _duration _milliseconds. is that OK? From owner-freebsd-ipfw@FreeBSD.ORG Thu May 8 16:25:14 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5DD8BA3 for ; Thu, 8 May 2014 16:25:14 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 74648608 for ; Thu, 8 May 2014 16:25:14 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 4FAE97300A; Thu, 8 May 2014 18:29:18 +0200 (CEST) Date: Thu, 8 May 2014 18:29:18 +0200 From: Luigi Rizzo To: bycn82 Subject: Re: feature of `packet per second` Message-ID: <20140508162918.GA68254@onelab2.iet.unipi.it> References: <53611738.8010103@gmail.com> <53611EB1.4000406@gmail.com> <5364E097.9020106@gmail.com> <536AD13B.6080907@gmail.com> <536AD941.9090102@gmail.com> <20140508073816.GB64368@onelab2.iet.unipi.it> <536BACA4.7010702@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <536BACA4.7010702@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "freebsd-ipfw@freebsd.org" , Freddie Cash X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 16:25:14 -0000 On Fri, May 09, 2014 at 12:11:16AM +0800, bycn82 wrote: > On 5/8/14 15:38, Luigi Rizzo wrote: ... > >>>>> If i were to implement the feature i would add two parameters > >>>>> (burst, I_max) with reasonable defaults and compute the internal > >>>>> interval and max_count as follows > >>>>> if (burst> max_pps * I_max) > >>>>> burst = max_pps * I_max; // make sure it is not too large > >>>>> else if (burst< max_pps / HZ) > >>>>> burst = max_pps * HZ; // nor too small > >>>>> max_count = max_pps / burst; > >>>>> interval = HZ * burst / max_pps; > >>>>> count = 0; // actual counter > >>>>> > >>>>> then add { max_count, interval, timestamp, count } to the rule > >>>>> descriptor. > >>>>> On incoming packets: > >>>>> > >>>>> if (ticks>= r->interval + r->timestamp) { > >>>>> r->timestamp = r->ticks; > >>>>> r->count = 1; > >>>>> return ACCEPT; > >>>>> } > >>>>> if (r->count> r->max_count) > >>>>> return DENY; > >>>>> r->count++; > >>>>> return ACCEPT; > >>>>> > >>>>> cheers > >>>>> luigi > >>>>> > >>>> Hi Luigi, > >>>> You are right, it will be more generic if provide two parameters > >>>> as you described, > >>>> But this PPS feature should not be used to control the traffic > >>>> rate, the dummynet you provided is the correct way. > >>>> So I am thinking in what kind of scenario, people need this PPS > >>>> feature? > >>>> in my opinion, people will use PPS only when they want to limit > >>>> the connections/transactions numbers. ( already have limit > >>>> command to limit the connections) > >>>> So I think provide a simple PPS feature is good enough, and we > >>>> can improve it if someone complaint on this. ... > Man page patch for PPS > > .It Cm pps Ar limit duration > Rule with the > .Cm pps > keyword will allow the first > .Ar limit > packets in each > .Ar duration > milliseconds. > > and it will be like blow > pps _limit duration_ > Rule with the pps keyword will allow the first _limit > _packets in > each _duration _milliseconds. > > is that OK? looks good to me. Just remember that the value of HZ may be quite low (e.g. HZ=100 or less in some cases) so internally the code should round up the intervals as needed. cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Thu May 8 17:10:41 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E35DCF9A for ; Thu, 8 May 2014 17:10:41 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (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 758C6A4D for ; Thu, 8 May 2014 17:10:40 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s48HBxOp057953; Thu, 8 May 2014 10:12:05 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s48HBsOI057950; Thu, 8 May 2014 10:11:54 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Thu, 8 May 2014 10:11:54 -0700 (PDT) Message-ID: <90ff4a7ff9a1d1bac510bb04fc457a91.authenticated@ultimatedns.net> In-Reply-To: <536BACA4.7010702@gmail.com> References: <5360F1F4.9060808@gmail.com> <5361105C.1040203@freebsd.org> <53611738.8010103@gmail.com> <53611EB1.4000406@gmail.com> <5364E097.9020106@gmail.com> <536AD13B.6080907@gmail.com> <536AD941.9090102@gmail.com> <20140508073816.GB64368@onelab2.iet.unipi.it> <536BACA4.7010702@gmail.com> Date: Thu, 8 May 2014 10:11:54 -0700 (PDT) Subject: Re: feature of `packet per second` From: "Chris H" To: "bycn82" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "freebsd-ipfw@freebsd.org" , Freddie Cash , Luigi Rizzo X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 17:10:42 -0000 > On 5/8/14 15:38, Luigi Rizzo wrote: >> On Thu, May 08, 2014 at 09:09:21AM +0800, bycn82 wrote: >>> On 5/8/14 8:35, bycn82 wrote: >>>> On 5/4/14 1:19, Luigi Rizzo wrote: >>>>> >>>>> >>>>> On Sat, May 3, 2014 at 2:27 PM, bycn82>>>> > wrote: >>>>> >>>>> On 5/2/14 16:59, Luigi Rizzo wrote: >>>>>> >>>>>> >>>>>> On Wed, Apr 30, 2014 at 6:02 PM, bycn82>>>>> > wrote: >>>>>> >>>>>> >>>>>> fjwcash@gmail.com >>>>>> > >>>>>> >>>>>> Thanks for your reply, and it is good to know the sysctl >>>>>> for ICMP. >>>>>> >>>>>> finally it works.I just added a new `action` in firewall and >>>>>> it is called `pps`, that means it can be generic purpose >>>>>> while the net.inet.icmp.icmplim is only for ICMP traffic. >>>>>> >>>>>> the usage will be like below >>>>>> >>>>>> root@F10:/usr/src/sbin/ipfw # .*/ipfw add pps 1 icmp from >>>>>> any to any* >>>>>> 00100 pps 1 icmp from any to any >>>>>> root@F10:/usr/src/sbin/ipfw # ./ipfw show >>>>>> 00100 9 540 pps 1 icmp from any to any >>>>>> 65535 13319 1958894 allow ip from any to any >>>>>> root@F10:/usr/src/sbin/ipfw # >>>>>> >>>>>> >>>>>> ???hi, >>>>>> as julian said it would be great if you would like to share your >>>>>> code >>>>>> so we can integrate it in future ipfw releases. >>>>>> Once again citing Julian, dummynet is a bit of a superset of pps but >>>>>> not exactly, so i see value in the additional feature. >>>>>> >>>>>> One thing ???to keep in mind in the implementation: >>>>>> >>>>>> the burst size used for limiting is an important parameter that >>>>>> everyone forgets. 1 pps is basically "don't bother me". >>>>>> 1000 pps could be "1000 packets every fixed 1-sec interval" >>>>>> or "1 packet every ms" or (this is more difficult) >>>>>> "20 pkt in the last 50ms interval". >>>>>> >>>>>> If i were to implement the feature i would add two parameters >>>>>> (burst, I_max) with reasonable defaults and compute the internal >>>>>> interval and max_count as follows >>>>>> if (burst> max_pps * I_max) >>>>>> burst = max_pps * I_max; // make sure it is not too large >>>>>> else if (burst< max_pps / HZ) >>>>>> burst = max_pps * HZ; // nor too small >>>>>> max_count = max_pps / burst; >>>>>> interval = HZ * burst / max_pps; >>>>>> count = 0; // actual counter >>>>>> >>>>>> then add { max_count, interval, timestamp, count } to the rule >>>>>> descriptor. >>>>>> On incoming packets: >>>>>> >>>>>> if (ticks>= r->interval + r->timestamp) { >>>>>> r->timestamp = r->ticks; >>>>>> r->count = 1; >>>>>> return ACCEPT; >>>>>> } >>>>>> if (r->count> r->max_count) >>>>>> return DENY; >>>>>> r->count++; >>>>>> return ACCEPT; >>>>>> >>>>>> cheers >>>>>> luigi >>>>>> >>>>> Hi Luigi, >>>>> You are right, it will be more generic if provide two parameters >>>>> as you described, >>>>> But this PPS feature should not be used to control the traffic >>>>> rate, the dummynet you provided is the correct way. >>>>> So I am thinking in what kind of scenario, people need this PPS >>>>> feature? >>>>> in my opinion, people will use PPS only when they want to limit >>>>> the connections/transactions numbers. ( already have limit >>>>> command to limit the connections) >>>>> So I think provide a simple PPS feature is good enough, and we >>>>> can improve it if someone complaint on this. >>>>> >>>>> >>>>> ???pps has a strong reason to exist because it is a lot cheaper >>>>> than a dummynet pipe, and given its pur???pose is to police >>>>> traffic (icmp, dns requests, etc) which should not even >>>>> get close to the limit which is set, I think it is >>>>> a completely reasonable feature to have. >>>>> >>>>> Given that the above code is the complete implementation >>>>> with the two parameters (burst and interval) there is no >>>>> reason not to use them, at least internally. >>>>> >>>>> Then you could choose not to expose them as part of the >>>>> user interface (though since you are implementing a new >>>>> option from scratch, it is completely trivial to >>>>> parse 1, 2 or 3 arguments and set defaults for the others). >>>>> >>>>> cheers >>>>> luigi >>>> OK, PPS with 2 parameters , it is done, >>>> But how to get the current time in millisecond? >>>> any recommendation? >>> In order to get the millisecond, i tried to include the timeb.h but i >>> met below >> FreeBSD has a global kernel variable called ticks which increments >> (roughly) HZ times per second and is all you need for this >> kind of coarse estimates. >> In linux there is something similar (jiffies maybe ?), >> and the code to build ipfw on linux does some reasonable >> mapping. >> >> The code i posted is, i believe, complete and contains >> all the details. >> >> cheers >> luigi >> >>> n file included from >>> /usr/src/sys/modules/ipfw/../../netpfil/ipfw/ip_fw2.c:42: >>> @/sys/timeb.h:42:2: error: "this file includes which is >>> deprecated" >>> [-Werror,-W#warnings] >>> #warning "this file includes which is deprecated" >>> ^ >>> any replacement for timeb.h > > Man page patch for PPS > > .It Cm pps Ar limit duration > Rule with the > .Cm pps > keyword will allow the first > .Ar limit > packets in each > .Ar duration > milliseconds. > >- and it will be like blow + and it will be below > pps _limit duration_ > Rule with the pps keyword will allow the first _limit > _packets in > each _duration _milliseconds. > > is that OK? Just a suggestion. :) --Chris > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://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 9 03:00:58 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80F0B481 for ; Fri, 9 May 2014 03:00:58 +0000 (UTC) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (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 04FD06EB for ; Fri, 9 May 2014 03:00:57 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id hm4so655059wib.4 for ; Thu, 08 May 2014 20:00:56 -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=fTjTsldnO8Zq/cymdY0RjrztlWQkBZ4mDElyc7NzAVI=; b=AuBrm3qLjnoADOUBIap8FgCylMT6i/mL6Lv5DDgUMoWFxe0LUT2feSbIw7wJQGxriJ +dsVeokEJe1sHzzsdKNj10beCgm60CQQ2QvzX3xpFUdBeYQy8xEAI+wEk97vjWffzttZ 1CfUekVTUzqSETZsWbj3mdV/fUFypCLWWLR8FmWDEQu9NCZs6eYC2ucyzd/GUbKV8gjF 0pWvb3uKDgs2de2pdXumyB/NGGFcCpIajpXuGbDeLK2hk6YBEsRGoqECXYz0XqbpX72W n5rZEyF7M5DZbkoHJqLTBH7qmO2meA1DGcXtfyS7le6IBGEqsqpKjuwaMlWK4xBy6YNL +VFQ== MIME-Version: 1.0 X-Received: by 10.194.1.242 with SMTP id 18mr6246430wjp.22.1399604455993; Thu, 08 May 2014 20:00:55 -0700 (PDT) Received: by 10.216.116.136 with HTTP; Thu, 8 May 2014 20:00:55 -0700 (PDT) In-Reply-To: <90ff4a7ff9a1d1bac510bb04fc457a91.authenticated@ultimatedns.net> References: <5360F1F4.9060808@gmail.com> <5361105C.1040203@freebsd.org> <53611738.8010103@gmail.com> <53611EB1.4000406@gmail.com> <5364E097.9020106@gmail.com> <536AD13B.6080907@gmail.com> <536AD941.9090102@gmail.com> <20140508073816.GB64368@onelab2.iet.unipi.it> <536BACA4.7010702@gmail.com> <90ff4a7ff9a1d1bac510bb04fc457a91.authenticated@ultimatedns.net> Date: Fri, 9 May 2014 11:00:55 +0800 Message-ID: Subject: Re: feature of `packet per second` From: Bill Yuan To: Chris H Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-ipfw@freebsd.org" , Freddie Cash , Luigi Rizzo X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 03:00:58 -0000 OK then I will submit it as a patch in this weekend. On Fri, May 9, 2014 at 1:11 AM, Chris H wrote: > > On 5/8/14 15:38, Luigi Rizzo wrote: > >> On Thu, May 08, 2014 at 09:09:21AM +0800, bycn82 wrote: > >>> On 5/8/14 8:35, bycn82 wrote: > >>>> On 5/4/14 1:19, Luigi Rizzo wrote: > >>>>> > >>>>> > >>>>> On Sat, May 3, 2014 at 2:27 PM, bycn82 >>>>> > wrote: > >>>>> > >>>>> On 5/2/14 16:59, Luigi Rizzo wrote: > >>>>>> > >>>>>> > >>>>>> On Wed, Apr 30, 2014 at 6:02 PM, bycn82 >>>>>> > wrote: > >>>>>> > >>>>>> > >>>>>> fjwcash@gmail.com > >>>>>> > > >>>>>> > >>>>>> Thanks for your reply, and it is good to know the sysctl > >>>>>> for ICMP. > >>>>>> > >>>>>> finally it works.I just added a new `action` in firewall > and > >>>>>> it is called `pps`, that means it can be generic purpose > >>>>>> while the net.inet.icmp.icmplim is only for ICMP traffic. > >>>>>> > >>>>>> the usage will be like below > >>>>>> > >>>>>> root@F10:/usr/src/sbin/ipfw # .*/ipfw add pps 1 icmp from > >>>>>> any to any* > >>>>>> 00100 pps 1 icmp from any to any > >>>>>> root@F10:/usr/src/sbin/ipfw # ./ipfw show > >>>>>> 00100 9 540 pps 1 icmp from any to any > >>>>>> 65535 13319 1958894 allow ip from any to any > >>>>>> root@F10:/usr/src/sbin/ipfw # > >>>>>> > >>>>>> > >>>>>> ???hi, > >>>>>> as julian said it would be great if you would like to share > your > >>>>>> code > >>>>>> so we can integrate it in future ipfw releases. > >>>>>> Once again citing Julian, dummynet is a bit of a superset of > pps but > >>>>>> not exactly, so i see value in the additional feature. > >>>>>> > >>>>>> One thing ???to keep in mind in the implementation: > >>>>>> > >>>>>> the burst size used for limiting is an important parameter that > >>>>>> everyone forgets. 1 pps is basically "don't bother me". > >>>>>> 1000 pps could be "1000 packets every fixed 1-sec interval" > >>>>>> or "1 packet every ms" or (this is more difficult) > >>>>>> "20 pkt in the last 50ms interval". > >>>>>> > >>>>>> If i were to implement the feature i would add two parameters > >>>>>> (burst, I_max) with reasonable defaults and compute the > internal > >>>>>> interval and max_count as follows > >>>>>> if (burst> max_pps * I_max) > >>>>>> burst = max_pps * I_max; // make sure it is not too > large > >>>>>> else if (burst< max_pps / HZ) > >>>>>> burst = max_pps * HZ; // nor too small > >>>>>> max_count = max_pps / burst; > >>>>>> interval = HZ * burst / max_pps; > >>>>>> count = 0; // actual counter > >>>>>> > >>>>>> then add { max_count, interval, timestamp, count } to the rule > >>>>>> descriptor. > >>>>>> On incoming packets: > >>>>>> > >>>>>> if (ticks>= r->interval + r->timestamp) { > >>>>>> r->timestamp = r->ticks; > >>>>>> r->count = 1; > >>>>>> return ACCEPT; > >>>>>> } > >>>>>> if (r->count> r->max_count) > >>>>>> return DENY; > >>>>>> r->count++; > >>>>>> return ACCEPT; > >>>>>> > >>>>>> cheers > >>>>>> luigi > >>>>>> > >>>>> Hi Luigi, > >>>>> You are right, it will be more generic if provide two parameters > >>>>> as you described, > >>>>> But this PPS feature should not be used to control the traffic > >>>>> rate, the dummynet you provided is the correct way. > >>>>> So I am thinking in what kind of scenario, people need this PPS > >>>>> feature? > >>>>> in my opinion, people will use PPS only when they want to limit > >>>>> the connections/transactions numbers. ( already have limit > >>>>> command to limit the connections) > >>>>> So I think provide a simple PPS feature is good enough, and we > >>>>> can improve it if someone complaint on this. > >>>>> > >>>>> > >>>>> ???pps has a strong reason to exist because it is a lot cheaper > >>>>> than a dummynet pipe, and given its pur???pose is to police > >>>>> traffic (icmp, dns requests, etc) which should not even > >>>>> get close to the limit which is set, I think it is > >>>>> a completely reasonable feature to have. > >>>>> > >>>>> Given that the above code is the complete implementation > >>>>> with the two parameters (burst and interval) there is no > >>>>> reason not to use them, at least internally. > >>>>> > >>>>> Then you could choose not to expose them as part of the > >>>>> user interface (though since you are implementing a new > >>>>> option from scratch, it is completely trivial to > >>>>> parse 1, 2 or 3 arguments and set defaults for the others). > >>>>> > >>>>> cheers > >>>>> luigi > >>>> OK, PPS with 2 parameters , it is done, > >>>> But how to get the current time in millisecond? > >>>> any recommendation? > >>> In order to get the millisecond, i tried to include the timeb.h but i > >>> met below > >> FreeBSD has a global kernel variable called ticks which increments > >> (roughly) HZ times per second and is all you need for this > >> kind of coarse estimates. > >> In linux there is something similar (jiffies maybe ?), > >> and the code to build ipfw on linux does some reasonable > >> mapping. > >> > >> The code i posted is, i believe, complete and contains > >> all the details. > >> > >> cheers > >> luigi > >> > >>> n file included from > >>> /usr/src/sys/modules/ipfw/../../netpfil/ipfw/ip_fw2.c:42: > >>> @/sys/timeb.h:42:2: error: "this file includes which is > >>> deprecated" > >>> [-Werror,-W#warnings] > >>> #warning "this file includes which is deprecated" > >>> ^ > >>> any replacement for timeb.h > > > > Man page patch for PPS > > > > .It Cm pps Ar limit duration > > Rule with the > > .Cm pps > > keyword will allow the first > > .Ar limit > > packets in each > > .Ar duration > > milliseconds. > > > >- and it will be like blow > + and it will be below > > pps _limit duration_ > > Rule with the pps keyword will allow the first _limit > > _packets in > > each _duration _milliseconds. > > > > is that OK? > Just a suggestion. :) > > --Chris > > _______________________________________________ > > freebsd-ipfw@freebsd.org mailing list > > http://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 9 09:47:45 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 734ACE12 for ; Fri, 9 May 2014 09:47:45 +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 C4988F40 for ; Fri, 9 May 2014 09:47:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s499lQKG000269; Fri, 9 May 2014 19:47:26 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 9 May 2014 19:47:26 +1000 (EST) From: Ian Smith To: Bill Yuan Subject: Re: feature of `packet per second` In-Reply-To: Message-ID: <20140509193112.M11699@sola.nimnet.asn.au> References: <5360F1F4.9060808@gmail.com> <5361105C.1040203@freebsd.org> <53611738.8010103@gmail.com> <53611EB1.4000406@gmail.com> <5364E097.9020106@gmail.com> <536AD13B.6080907@gmail.com> <536AD941.9090102@gmail.com> <20140508073816.GB64368@onelab2.iet.unipi.it> <536BACA4.7010702@gmail.com> <90ff4a7ff9a1d1bac510bb04fc457a91.authenticated@ultimatedns.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "freebsd-ipfw@freebsd.org" , Freddie Cash , Luigi Rizzo , Chris H X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 09:47:45 -0000 On Fri, 9 May 2014 11:00:55 +0800, Bill Yuan wrote: > OK then I will submit it as a patch in this weekend. [..] > > > Man page patch for PPS > > > > > > .It Cm pps Ar limit duration > > > Rule with the > > > .Cm pps > > > keyword will allow the first > > > .Ar limit > > > packets in each > > > .Ar duration > > > milliseconds. > > > > > >- and it will be like blow > > + and it will be below > > > pps _limit duration_ > > > Rule with the pps keyword will allow the first _limit > > > _packets in > > > each _duration _milliseconds. ! each _duration_ milliseconds, rounded up to the next tick (1/HZ seconds) as Luigi suggested, especially relevant for lower HZ rates than 1000, eg at 100Hz that's the next 10ms, particularly if limit were as low as 1 .. cheers, Ian From owner-freebsd-ipfw@FreeBSD.ORG Fri May 9 09:56:26 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 141FB13D for ; Fri, 9 May 2014 09:56:26 +0000 (UTC) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (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 6E5012F for ; Fri, 9 May 2014 09:56:25 +0000 (UTC) Received: by mail-lb0-f181.google.com with SMTP id u14so5185064lbd.26 for ; Fri, 09 May 2014 02:56:23 -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:date:message-id:subject :from:to:cc:content-type; bh=zq66c0bgat6MDoUIvipdyJhK+HZ2ANwnTKaG+0xhB0E=; b=uN1r9T8HJHm/2GG6wdhWpAw+9sJvdjIdeozN0VrprnUcwAnI4Kq8xg+yg/TUdKlUHu 6hBns0e5cJ3pp760laa7qiOnOgiYlUZ6zcjLoqJWFO9Z9TtrXyDj+0sDNh4lA/qlJ5fi WfryxeB6nmDf37sz7NB9asgqL9YB5wNF7y7aAn2R/an7bveLwo0pdjI4LQ4qssfeoG03 +t5sq/HyxMZrskrjOog+9nVTrcaQIp+DmVkSXtSO9mLpZae7WOtj9fXVdkLlK43l7DlX x+h7SdHiX3lq29/FaUNphp7MR4I9OU87PViTu6SKsXShTJPdV4iV45QK9K3Hto9fvUID RpcQ== MIME-Version: 1.0 X-Received: by 10.112.41.101 with SMTP id e5mr1230575lbl.46.1399629383283; Fri, 09 May 2014 02:56:23 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.107 with HTTP; Fri, 9 May 2014 02:56:23 -0700 (PDT) In-Reply-To: References: <5360F1F4.9060808@gmail.com> <5361105C.1040203@freebsd.org> <53611738.8010103@gmail.com> <53611EB1.4000406@gmail.com> <5364E097.9020106@gmail.com> <536AD13B.6080907@gmail.com> <536AD941.9090102@gmail.com> <20140508073816.GB64368@onelab2.iet.unipi.it> <536BACA4.7010702@gmail.com> <90ff4a7ff9a1d1bac510bb04fc457a91.authenticated@ultimatedns.net> Date: Fri, 9 May 2014 11:56:23 +0200 X-Google-Sender-Auth: RBLo9H9jcAelOJMkH8I9gMa0NcI Message-ID: Subject: Re: feature of `packet per second` From: Luigi Rizzo To: Bill Yuan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-ipfw@freebsd.org" , Freddie Cash X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 09:56:26 -0000 On Fri, May 9, 2014 at 5:00 AM, Bill Yuan wrote: > OK then I will submit it as a patch in this weekend. > > =E2=80=8Bthank you, much appreciated. Don't worry about the details on the manpage, we can fix them at a later time, same as handling corner cases with small HZ values etc. cheers luigi =E2=80=8B > > On Fri, May 9, 2014 at 1:11 AM, Chris H wrote: > >> > On 5/8/14 15:38, Luigi Rizzo wrote: >> >> On Thu, May 08, 2014 at 09:09:21AM +0800, bycn82 wrote: >> >>> On 5/8/14 8:35, bycn82 wrote: >> >>>> On 5/4/14 1:19, Luigi Rizzo wrote: >> >>>>> >> >>>>> >> >>>>> On Sat, May 3, 2014 at 2:27 PM, bycn82> >>>>> > wrote: >> >>>>> >> >>>>> On 5/2/14 16:59, Luigi Rizzo wrote: >> >>>>>> >> >>>>>> >> >>>>>> On Wed, Apr 30, 2014 at 6:02 PM, bycn82> >>>>>> > wrote: >> >>>>>> >> >>>>>> >> >>>>>> fjwcash@gmail.com >> >>>>>> > >> >>>>>> >> >>>>>> Thanks for your reply, and it is good to know the sysct= l >> >>>>>> for ICMP. >> >>>>>> >> >>>>>> finally it works.I just added a new `action` in firewall >> and >> >>>>>> it is called `pps`, that means it can be generic purpos= e >> >>>>>> while the net.inet.icmp.icmplim is only for ICMP traffic= . >> >>>>>> >> >>>>>> the usage will be like below >> >>>>>> >> >>>>>> root@F10:/usr/src/sbin/ipfw # .*/ipfw add pps 1 icmp fro= m >> >>>>>> any to any* >> >>>>>> 00100 pps 1 icmp from any to any >> >>>>>> root@F10:/usr/src/sbin/ipfw # ./ipfw show >> >>>>>> 00100 9 540 pps 1 icmp from any to any >> >>>>>> 65535 13319 1958894 allow ip from any to any >> >>>>>> root@F10:/usr/src/sbin/ipfw # >> >>>>>> >> >>>>>> >> >>>>>> ???hi, >> >>>>>> as julian said it would be great if you would like to share >> your >> >>>>>> code >> >>>>>> so we can integrate it in future ipfw releases. >> >>>>>> Once again citing Julian, dummynet is a bit of a superset of >> pps but >> >>>>>> not exactly, so i see value in the additional feature. >> >>>>>> >> >>>>>> One thing ???to keep in mind in the implementation: >> >>>>>> >> >>>>>> the burst size used for limiting is an important parameter >> that >> >>>>>> everyone forgets. 1 pps is basically "don't bother me". >> >>>>>> 1000 pps could be "1000 packets every fixed 1-sec interval" >> >>>>>> or "1 packet every ms" or (this is more difficult) >> >>>>>> "20 pkt in the last 50ms interval". >> >>>>>> >> >>>>>> If i were to implement the feature i would add two parameter= s >> >>>>>> (burst, I_max) with reasonable defaults and compute the >> internal >> >>>>>> interval and max_count as follows >> >>>>>> if (burst> max_pps * I_max) >> >>>>>> burst =3D max_pps * I_max; // make sure it is not too >> large >> >>>>>> else if (burst< max_pps / HZ) >> >>>>>> burst =3D max_pps * HZ; // nor too small >> >>>>>> max_count =3D max_pps / burst; >> >>>>>> interval =3D HZ * burst / max_pps; >> >>>>>> count =3D 0; // actual counter >> >>>>>> >> >>>>>> then add { max_count, interval, timestamp, count } to the ru= le >> >>>>>> descriptor. >> >>>>>> On incoming packets: >> >>>>>> >> >>>>>> if (ticks>=3D r->interval + r->timestamp) { >> >>>>>> r->timestamp =3D r->ticks; >> >>>>>> r->count =3D 1; >> >>>>>> return ACCEPT; >> >>>>>> } >> >>>>>> if (r->count> r->max_count) >> >>>>>> return DENY; >> >>>>>> r->count++; >> >>>>>> return ACCEPT; >> >>>>>> >> >>>>>> cheers >> >>>>>> luigi >> >>>>>> >> >>>>> Hi Luigi, >> >>>>> You are right, it will be more generic if provide two >> parameters >> >>>>> as you described, >> >>>>> But this PPS feature should not be used to control the traffi= c >> >>>>> rate, the dummynet you provided is the correct way. >> >>>>> So I am thinking in what kind of scenario, people need this P= PS >> >>>>> feature? >> >>>>> in my opinion, people will use PPS only when they want to lim= it >> >>>>> the connections/transactions numbers. ( already have limit >> >>>>> command to limit the connections) >> >>>>> So I think provide a simple PPS feature is good enough, and w= e >> >>>>> can improve it if someone complaint on this. >> >>>>> >> >>>>> >> >>>>> ???pps has a strong reason to exist because it is a lot cheaper >> >>>>> than a dummynet pipe, and given its pur???pose is to police >> >>>>> traffic (icmp, dns requests, etc) which should not even >> >>>>> get close to the limit which is set, I think it is >> >>>>> a completely reasonable feature to have. >> >>>>> >> >>>>> Given that the above code is the complete implementation >> >>>>> with the two parameters (burst and interval) there is no >> >>>>> reason not to use them, at least internally. >> >>>>> >> >>>>> Then you could choose not to expose them as part of the >> >>>>> user interface (though since you are implementing a new >> >>>>> option from scratch, it is completely trivial to >> >>>>> parse 1, 2 or 3 arguments and set defaults for the others). >> >>>>> >> >>>>> cheers >> >>>>> luigi >> >>>> OK, PPS with 2 parameters , it is done, >> >>>> But how to get the current time in millisecond? >> >>>> any recommendation? >> >>> In order to get the millisecond, i tried to include the timeb.h but = i >> >>> met below >> >> FreeBSD has a global kernel variable called ticks which increments >> >> (roughly) HZ times per second and is all you need for this >> >> kind of coarse estimates. >> >> In linux there is something similar (jiffies maybe ?), >> >> and the code to build ipfw on linux does some reasonable >> >> mapping. >> >> >> >> The code i posted is, i believe, complete and contains >> >> all the details. >> >> >> >> cheers >> >> luigi >> >> >> >>> n file included from >> >>> /usr/src/sys/modules/ipfw/../../netpfil/ipfw/ip_fw2.c:42: >> >>> @/sys/timeb.h:42:2: error: "this file includes which i= s >> >>> deprecated" >> >>> [-Werror,-W#warnings] >> >>> #warning "this file includes which is deprecated" >> >>> ^ >> >>> any replacement for timeb.h >> > >> > Man page patch for PPS >> > >> > .It Cm pps Ar limit duration >> > Rule with the >> > .Cm pps >> > keyword will allow the first >> > .Ar limit >> > packets in each >> > .Ar duration >> > milliseconds. >> > >> >- and it will be like blow >> + and it will be below >> > pps _limit duration_ >> > Rule with the pps keyword will allow the first _limit >> > _packets in >> > each _duration _milliseconds. >> > >> > is that OK? >> Just a suggestion. :) >> >> --Chris >> > _______________________________________________ >> > freebsd-ipfw@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org= " >> > >> >> > --=20 -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-ipfw@FreeBSD.ORG Sat May 10 03:25:52 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37F067F5 for ; Sat, 10 May 2014 03:25:52 +0000 (UTC) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (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 0F277B6E for ; Sat, 10 May 2014 03:25:52 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id w10so4427605pde.33 for ; Fri, 09 May 2014 20:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=6BHx1XGRaCUFZAXiNZcTNZXvzcHeVp4h74ahG+NDQG0=; b=ydQuEfox7xsHN1JgS+khHIQhy1MoawbjeIV6YYCGDoZkiMRGdpl5UxV65Vn4uongM2 c6g0GeyvbgZOufNxQiljfk+kTnFJR/igyy88VuNZBgNUg50CpxBjCvGcuommL71hhbuP aCvBSQb7zeCvfLjxKZ1VeMWnioFMnBJU4SjiySQB9EzDdd+UaVnCsPWOCwMCZ/Hhb9TI lVhmhKh5HhTWFEHfJhImO1lm6OPHsTzX75/A4v1W4ZKG2TgLkbPVfEc+gg7tIJTM4FCu TuV7MWrO9HBp76pL20Dd4aYRB+3Z9Hfda/O8dQ1X+GAnVdYpf1ez/aw7/pYJ5/AiKcTW 9Jaw== X-Received: by 10.66.146.170 with SMTP id td10mr27630891pab.105.1399692351483; Fri, 09 May 2014 20:25:51 -0700 (PDT) Received: from [192.168.1.101] ([183.90.37.190]) by mx.google.com with ESMTPSA id uk1sm15811650pac.26.2014.05.09.20.25.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 May 2014 20:25:50 -0700 (PDT) Message-ID: <536D9C3A.5010605@gmail.com> Date: Sat, 10 May 2014 11:25:46 +0800 From: bycn82 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-ipfw@FreeBSD.org Subject: error in make Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 03:25:52 -0000 I think someone messed-up the makefiles, root@FB10Head:/usr/src/sys/modules/ipfw # make make: "/usr/src/sys/modules/ipfw/Makefile" line 3: Could not find src.opts.mk make: "/usr/src/sys/modules/ipfw/Makefile" line 24: Malformed conditional (${MK_INET_SUPPORT} != "no") make: "/usr/src/sys/modules/ipfw/Makefile" line 28: Malformed conditional (${MK_INET6_SUPPORT} != "no") make: Fatal errors encountered -- cannot continue make: stopped in /usr/src/sys/modules/ipfw root@FB10Head:/usr/src/sys/modules/ipfw # uname -a FreeBSD FB10Head 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r265307M: Mon May 5 01:34:11 UTC 2014 root@FB10Head:/usr/obj/usr/src/sys/GENERIC amd64 root@FB10Head:/usr/src/sys/modules/ipfw # find / -name src.opts.mk /usr/src/share/mk/src.opts.mk root@FB10Head:/usr/src/sys/modules/ipfw # From owner-freebsd-ipfw@FreeBSD.ORG Mon May 12 04:28:31 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BEC6DCAC for ; Mon, 12 May 2014 04:28:31 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id A173025AC for ; Mon, 12 May 2014 04:28:30 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id AE76C3AE0E for ; Sun, 11 May 2014 21:28:27 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-ipfw@freebsd.org Subject: Where do the boot time messages go? Date: Sun, 11 May 2014 21:28:27 -0700 Message-ID: <1756.1399868907@server1.tristatelogic.com> X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 04:28:31 -0000 In my /etc/rc.conf file, I have the following (among other things): firewall_enable="YES" firewall_type="/etc/fw.rules" firewall_logging="YES" And of course, on my system, the /etc/fw.rules file is full of ipfw "add" commands. During a normal boot of FreeBSD, I can see those add commands being processed. They are shown, briefly, whizzing by, on the console. During a recent reboot, I also saw something at about the same time that looked like it might possibly have been some sort of ipfw error or warning message. I would like to investigate. Unfortunately it appears that all of the console messages that are being logged, during the time when ipfw is processing my local firewall rules file, are not in fact stored into either /var/log/messages nor even into /var/log/security. (I know. I looked.) So, um, where do these messages go, exactly? I really would like to have a look at the ones from the last boot. From owner-freebsd-ipfw@FreeBSD.ORG Mon May 12 04:42:58 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9578F64 for ; Mon, 12 May 2014 04:42:58 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (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 A569126ED for ; Mon, 12 May 2014 04:42:58 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s4C4iVdn041204; Sun, 11 May 2014 21:44:37 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s4C4iQoT041201; Sun, 11 May 2014 21:44:26 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Sun, 11 May 2014 21:44:26 -0700 (PDT) Message-ID: <8fb4ad9509f5ec232873ade4f2f3128c.authenticated@ultimatedns.net> In-Reply-To: <1756.1399868907@server1.tristatelogic.com> References: <1756.1399868907@server1.tristatelogic.com> Date: Sun, 11 May 2014 21:44:26 -0700 (PDT) Subject: Re: Where do the boot time messages go? From: "Chris H" To: "Ronald F. Guilmette" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 04:42:59 -0000 > > > In my /etc/rc.conf file, I have the following (among other things): > > firewall_enable="YES" > firewall_type="/etc/fw.rules" > firewall_logging="YES" > > And of course, on my system, the /etc/fw.rules file is full of ipfw > "add" commands. > > During a normal boot of FreeBSD, I can see those add commands being > processed. They are shown, briefly, whizzing by, on the console. > > During a recent reboot, I also saw something at about the same time > that looked like it might possibly have been some sort of ipfw error > or warning message. > > I would like to investigate. > > Unfortunately it appears that all of the console messages that are > being logged, during the time when ipfw is processing my local firewall > rules file, are not in fact stored into either /var/log/messages nor > even into /var/log/security. (I know. I looked.) > > So, um, where do these messages go, exactly? > > I really would like to have a look at the ones from the last boot. While unlikely, have a look at /var/run/dmesg.boot. I see you have: firewall_logging="YES" Isn't it possible to DEFINE the firewall LOG? :) In other words; you ask it to log, but don't tell it WHERE. :) Doing so should provide the answers you're looking for. Best wishes. --Chris > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > From owner-freebsd-ipfw@FreeBSD.ORG Mon May 12 06:09:07 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7CCC8279 for ; Mon, 12 May 2014 06:09:07 +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 C81602C8E for ; Mon, 12 May 2014 06:09:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s4C68q8t043025; Mon, 12 May 2014 16:08:53 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 12 May 2014 16:08:52 +1000 (EST) From: Ian Smith To: Chris H Subject: Re: Where do the boot time messages go? In-Reply-To: <8fb4ad9509f5ec232873ade4f2f3128c.authenticated@ultimatedns.net> Message-ID: <20140512152327.A11699@sola.nimnet.asn.au> References: <1756.1399868907@server1.tristatelogic.com> <8fb4ad9509f5ec232873ade4f2f3128c.authenticated@ultimatedns.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-ipfw@freebsd.org, "Ronald F. Guilmette" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 06:09:07 -0000 On Sun, 11 May 2014 21:44:26 -0700, Chris H wrote: [Ronald F. Guilmette wrote:] > > In my /etc/rc.conf file, I have the following (among other things): > > > > firewall_enable="YES" > > firewall_type="/etc/fw.rules" > > firewall_logging="YES" > > > > And of course, on my system, the /etc/fw.rules file is full of ipfw > > "add" commands. > > > > During a normal boot of FreeBSD, I can see those add commands being > > processed. They are shown, briefly, whizzing by, on the console. > > > > During a recent reboot, I also saw something at about the same time > > that looked like it might possibly have been some sort of ipfw error > > or warning message. > > > > I would like to investigate. Instead of "ipfw add", if you use "ipfw -q add" those rule listings will not appear on the console. Any error messages - issued on stderr rather than stdout - should still appear without all the others. While they may still not get logged, you should be able to see them without all the 'whizzing by' at that stage of post-boot processing, and scrolling back the VT0 root console should reveal it/them. > > Unfortunately it appears that all of the console messages that are > > being logged, during the time when ipfw is processing my local firewall > > rules file, are not in fact stored into either /var/log/messages nor > > even into /var/log/security. (I know. I looked.) That's true .. fortunately, in general. > > So, um, where do these messages go, exactly? > > I really would like to have a look at the ones from the last boot. Any ipfw command issued without -q writes any resultant rule to stdout. > While unlikely, have a look at /var/run/dmesg.boot. Worth a try. > I see you have: firewall_logging="YES" > Isn't it possible to DEFINE the firewall LOG? :) > In other words; you ask it to log, but don't tell it WHERE. :) > Doing so should provide the answers you're looking for. In /etc/syslog.conf you should see: security.* /var/log/security Nothing but ipfw writes to log facility security, on my systems anyway. > Best wishes. > > --Chris cheers, Ian [off topic] BTW Chris, several days ago your system rejected two direct messages to you as spam. This may be the only way I can let you know. Subtracting 17 hours, this should appear in your mail logs around 02:47 Friday. Reporting-MTA: dns; sola.nimnet.asn.au Received-From-MTA: DNS; localhost Arrival-Date: Fri, 9 May 2014 19:47:26 +1000 (EST) Final-Recipient: RFC822; bsd-lists@bsdforge.com Action: failed Status: 5.0.0 Diagnostic-Code: SMTP; 550 5.0.0 SPAM and BULK mail REJECTED Last-Attempt-Date: Fri, 9 May 2014 19:47:34 +1000 (EST) From owner-freebsd-ipfw@FreeBSD.ORG Mon May 12 06:36:58 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA3D2818 for ; Mon, 12 May 2014 06:36:58 +0000 (UTC) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::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 68ECF2EE7 for ; Mon, 12 May 2014 06:36:58 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id y10so6264262wgg.25 for ; Sun, 11 May 2014 23:36:56 -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=c6fb+30T2t83QmJk7Nn5Fh3GwPL6Uwam+O800D+bl2o=; b=oP3p/L6+zsorI5sDczqaADu0AodImb2mTebqy8oT9vD4GGw2Aw9vRNHEcYI1oYbGHm 6KooBNiPv6ZqbrBlQ6i2m8kJvt5kxVJdvww3DGc7NLwJ5UTjkRiCzmRA1NV3HNCHA3ZK juMabV7k8WcIpyob79pVHE/2HM2UeR6DLVzY/LsTPSaedAb4Vyn0FoCtN0dpBFA3Aty+ Lac0mAibHEyASV//bQzeM2cLxjAM9AmoHw0YaVpSXbNiHDfZAijw5uUQ1Pxh/t6roWMx AAATHfrr0jBe/Kwwj3r8acGEUTH1ssP9LkVL7Ytc7m0+NMjx07QfJYYcIhkFS5WOf/Ne gODQ== MIME-Version: 1.0 X-Received: by 10.180.218.35 with SMTP id pd3mr13927533wic.26.1399876616581; Sun, 11 May 2014 23:36:56 -0700 (PDT) Received: by 10.216.116.136 with HTTP; Sun, 11 May 2014 23:36:56 -0700 (PDT) In-Reply-To: <20140512152327.A11699@sola.nimnet.asn.au> References: <1756.1399868907@server1.tristatelogic.com> <8fb4ad9509f5ec232873ade4f2f3128c.authenticated@ultimatedns.net> <20140512152327.A11699@sola.nimnet.asn.au> Date: Mon, 12 May 2014 14:36:56 +0800 Message-ID: Subject: Re: Where do the boot time messages go? From: Bill Yuan To: Ian Smith Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-ipfw , Chris H , "Ronald F. Guilmette" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 06:36:58 -0000 1.The userland command "ipfw" will print the result directly on the stdout. it is using printf() method. 2.The "firewall_logging" is for ipfw kernel module, and depends on the net.inet.ip.fw.verbose_limit and it will be logged in the syslog. On Mon, May 12, 2014 at 2:08 PM, Ian Smith wrote: > On Sun, 11 May 2014 21:44:26 -0700, Chris H wrote: > [Ronald F. Guilmette wrote:] > > > In my /etc/rc.conf file, I have the following (among other things): > > > > > > firewall_enable="YES" > > > firewall_type="/etc/fw.rules" > > > firewall_logging="YES" > > > > > > And of course, on my system, the /etc/fw.rules file is full of ipfw > > > "add" commands. > > > > > > During a normal boot of FreeBSD, I can see those add commands being > > > processed. They are shown, briefly, whizzing by, on the console. > > > > > > During a recent reboot, I also saw something at about the same time > > > that looked like it might possibly have been some sort of ipfw error > > > or warning message. > > > > > > I would like to investigate. > > Instead of "ipfw add", if you use "ipfw -q add" those rule listings will > not appear on the console. Any error messages - issued on stderr rather > than stdout - should still appear without all the others. While they > may still not get logged, you should be able to see them without all the > 'whizzing by' at that stage of post-boot processing, and scrolling back > the VT0 root console should reveal it/them. > > > > Unfortunately it appears that all of the console messages that are > > > being logged, during the time when ipfw is processing my local > firewall > > > rules file, are not in fact stored into either /var/log/messages nor > > > even into /var/log/security. (I know. I looked.) > > That's true .. fortunately, in general. > > > > So, um, where do these messages go, exactly? > > > I really would like to have a look at the ones from the last boot. > > Any ipfw command issued without -q writes any resultant rule to stdout. > > > While unlikely, have a look at /var/run/dmesg.boot. > > Worth a try. > > > I see you have: firewall_logging="YES" > > Isn't it possible to DEFINE the firewall LOG? :) > > In other words; you ask it to log, but don't tell it WHERE. :) > > Doing so should provide the answers you're looking for. > > In /etc/syslog.conf you should see: > security.* /var/log/security > > Nothing but ipfw writes to log facility security, on my systems anyway. > > > Best wishes. > > > > --Chris > > cheers, Ian > > [off topic] > BTW Chris, several days ago your system rejected two direct messages to > you as spam. This may be the only way I can let you know. Subtracting > 17 hours, this should appear in your mail logs around 02:47 Friday. > > Reporting-MTA: dns; sola.nimnet.asn.au > Received-From-MTA: DNS; localhost > Arrival-Date: Fri, 9 May 2014 19:47:26 +1000 (EST) > Final-Recipient: RFC822; bsd-lists@bsdforge.com > Action: failed > Status: 5.0.0 > Diagnostic-Code: SMTP; 550 5.0.0 SPAM and BULK mail REJECTED > Last-Attempt-Date: Fri, 9 May 2014 19:47:34 +1000 (EST) > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > From owner-freebsd-ipfw@FreeBSD.ORG Mon May 12 11:06:45 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B813EB0A for ; Mon, 12 May 2014 11:06:45 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 A511026C7 for ; Mon, 12 May 2014 11:06:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4CB6jAK067841 for ; Mon, 12 May 2014 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4CB6j7b067839 for freebsd-ipfw@FreeBSD.org; Mon, 12 May 2014 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 12 May 2014 11:06:45 GMT Message-Id: <201405121106.s4CB6j7b067839@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 11:06:45 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/187904 ipfw [ipfw] ipfw(8) does not properly recognize the network o kern/183479 ipfw [ipfw] ipfw table contains duplicate entry. o kern/180731 ipfw [ipfw] problem with displaying 255.255.255.255 address o kern/180729 ipfw [ipfw] ipfw nat show empty output o kern/178482 ipfw [ipfw] logging problem from vnet jail o kern/178480 ipfw [ipfw] dynamically loaded ipfw with a vimage kernel do o kern/178317 ipfw [ipfw] ipfw options need to specifed in specific order o kern/177948 ipfw [ipfw] ipfw fails to parse port ranges (p1-p2) for udp o kern/176503 ipfw [ipfw] ipfw layer2 problem o kern/170604 ipfw [ipfw] ipv6 reass broken o conf/167822 ipfw [ipfw] [patch] start script doesn't load firewall_type o kern/166406 ipfw [ipfw] ipfw does not set ALTQ identifier for ipv6 traf o kern/165939 ipfw [ipfw] bug: incomplete firewall rules loaded if tables o kern/165190 ipfw [ipfw] [lo] [patch] loopback interface is not marking o kern/158066 ipfw [ipfw] ipfw + netgraph + multicast = multicast packets o kern/157689 ipfw [ipfw] ipfw nat config does not accept nonexistent int f kern/155927 ipfw [ipfw] ipfw stops to check packets for compliance with o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw [ipfw] does not support specifying rules with ICMP cod o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. f kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l f kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes s kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 44 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon May 12 17:01:27 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B132E53 for ; Mon, 12 May 2014 17:01:27 +0000 (UTC) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (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 DC65B2A3A for ; Mon, 12 May 2014 17:01:26 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id kq14so4818332pab.33 for ; Mon, 12 May 2014 10:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=NFqVRoVQS7MGSnEceUtGbX07n03ZAK4Q/4AEjVbzs4M=; b=V/yAc98OryX74CqlYQ3SkBfO5Xmb8OgZQaGnWdgmD+WVl63wh38dztBCqHiW9MdHPH hhZHytHJJPokgTfD4LpugXLcwpyk7Mwc+cL6PEUiTsQm303is55+ZFky1Fqbt6pBjtpK 6SXkMszxHzN3K2i7gs+7Vck5gKBRD20QQWLq5oGb86IDdSZRQnrkAQW28EnwfSA9k2CQ gtRxkQ6KktsxCEbvPaaAvdQfxSXQcWBeEpvAKPmoSFnplmkDhRi3mBCfYiRRXI/mMTsc //VSUCqmbEBebt3BUL541bvDq0pZnPgq8y6JlqjFFVquqroEdQlu/wMhpH/QwMVwIX76 mSoA== X-Received: by 10.66.146.170 with SMTP id td10mr57740219pab.105.1399914086340; Mon, 12 May 2014 10:01:26 -0700 (PDT) Received: from [192.168.1.101] ([203.117.37.212]) by mx.google.com with ESMTPSA id gu1sm23809146pbd.0.2014.05.12.10.01.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 May 2014 10:01:24 -0700 (PDT) Message-ID: <5370FE5E.3000104@gmail.com> Date: Tue, 13 May 2014 01:01:18 +0800 From: bycn82 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: feature of `packet per second` References: <5360F1F4.9060808@gmail.com> <5361105C.1040203@freebsd.org> <53611738.8010103@gmail.com> <53611EB1.4000406@gmail.com> <5364E097.9020106@gmail.com> <536AD13B.6080907@gmail.com> <536AD941.9090102@gmail.com> <20140508073816.GB64368@onelab2.iet.unipi.it> <536BACA4.7010702@gmail.com> In-Reply-To: <536BACA4.7010702@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-ipfw@freebsd.org" , Freddie Cash X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 17:01:27 -0000 On 5/9/14 0:11, bycn82 wrote: > On 5/8/14 15:38, Luigi Rizzo wrote: >> On Thu, May 08, 2014 at 09:09:21AM +0800, bycn82 wrote: >>> On 5/8/14 8:35, bycn82 wrote: >>>> On 5/4/14 1:19, Luigi Rizzo wrote: >>>>> >>>>> On Sat, May 3, 2014 at 2:27 PM, bycn82>>>> > wrote: >>>>> >>>>> On 5/2/14 16:59, Luigi Rizzo wrote: >>>>>> >>>>>> On Wed, Apr 30, 2014 at 6:02 PM, bycn82>>>>> > wrote: >>>>>> >>>>>> >>>>>> fjwcash@gmail.com >>>>>> > >>>>>> >>>>>> Thanks for your reply, and it is good to know the sysctl >>>>>> for ICMP. >>>>>> >>>>>> finally it works.I just added a new `action` in firewall and >>>>>> it is called `pps`, that means it can be generic purpose >>>>>> while the net.inet.icmp.icmplim is only for ICMP traffic. >>>>>> >>>>>> the usage will be like below >>>>>> >>>>>> root@F10:/usr/src/sbin/ipfw # .*/ipfw add pps 1 icmp from >>>>>> any to any* >>>>>> 00100 pps 1 icmp from any to any >>>>>> root@F10:/usr/src/sbin/ipfw # ./ipfw show >>>>>> 00100 9 540 pps 1 icmp from any to any >>>>>> 65535 13319 1958894 allow ip from any to any >>>>>> root@F10:/usr/src/sbin/ipfw # >>>>>> >>>>>> >>>>>> ???hi, >>>>>> as julian said it would be great if you would like to share your >>>>>> code >>>>>> so we can integrate it in future ipfw releases. >>>>>> Once again citing Julian, dummynet is a bit of a superset of pps but >>>>>> not exactly, so i see value in the additional feature. >>>>>> >>>>>> One thing ???to keep in mind in the implementation: >>>>>> >>>>>> the burst size used for limiting is an important parameter that >>>>>> everyone forgets. 1 pps is basically "don't bother me". >>>>>> 1000 pps could be "1000 packets every fixed 1-sec interval" >>>>>> or "1 packet every ms" or (this is more difficult) >>>>>> "20 pkt in the last 50ms interval". >>>>>> >>>>>> If i were to implement the feature i would add two parameters >>>>>> (burst, I_max) with reasonable defaults and compute the internal >>>>>> interval and max_count as follows >>>>>> if (burst> max_pps * I_max) >>>>>> burst = max_pps * I_max; // make sure it is not too large >>>>>> else if (burst< max_pps / HZ) >>>>>> burst = max_pps * HZ; // nor too small >>>>>> max_count = max_pps / burst; >>>>>> interval = HZ * burst / max_pps; >>>>>> count = 0; // actual counter >>>>>> >>>>>> then add { max_count, interval, timestamp, count } to the rule >>>>>> descriptor. >>>>>> On incoming packets: >>>>>> >>>>>> if (ticks>= r->interval + r->timestamp) { >>>>>> r->timestamp = r->ticks; >>>>>> r->count = 1; >>>>>> return ACCEPT; >>>>>> } >>>>>> if (r->count> r->max_count) >>>>>> return DENY; >>>>>> r->count++; >>>>>> return ACCEPT; >>>>>> >>>>>> cheers >>>>>> luigi >>>>>> >>>>> Hi Luigi, >>>>> You are right, it will be more generic if provide two parameters >>>>> as you described, >>>>> But this PPS feature should not be used to control the traffic >>>>> rate, the dummynet you provided is the correct way. >>>>> So I am thinking in what kind of scenario, people need this PPS >>>>> feature? >>>>> in my opinion, people will use PPS only when they want to limit >>>>> the connections/transactions numbers. ( already have limit >>>>> command to limit the connections) >>>>> So I think provide a simple PPS feature is good enough, and we >>>>> can improve it if someone complaint on this. >>>>> >>>>> >>>>> ???pps has a strong reason to exist because it is a lot cheaper >>>>> than a dummynet pipe, and given its pur???pose is to police >>>>> traffic (icmp, dns requests, etc) which should not even >>>>> get close to the limit which is set, I think it is >>>>> a completely reasonable feature to have. >>>>> >>>>> Given that the above code is the complete implementation >>>>> with the two parameters (burst and interval) there is no >>>>> reason not to use them, at least internally. >>>>> >>>>> Then you could choose not to expose them as part of the >>>>> user interface (though since you are implementing a new >>>>> option from scratch, it is completely trivial to >>>>> parse 1, 2 or 3 arguments and set defaults for the others). >>>>> >>>>> cheers >>>>> luigi >>>> OK, PPS with 2 parameters , it is done, >>>> But how to get the current time in millisecond? >>>> any recommendation? >>> In order to get the millisecond, i tried to include the timeb.h but i >>> met below >> FreeBSD has a global kernel variable called ticks which increments >> (roughly) HZ times per second and is all you need for this >> kind of coarse estimates. >> In linux there is something similar (jiffies maybe ?), >> and the code to build ipfw on linux does some reasonable >> mapping. >> >> The code i posted is, i believe, complete and contains >> all the details. >> >> cheers >> luigi >> >>> n file included from >>> /usr/src/sys/modules/ipfw/../../netpfil/ipfw/ip_fw2.c:42: >>> @/sys/timeb.h:42:2: error: "this file includes which is >>> deprecated" >>> [-Werror,-W#warnings] >>> #warning "this file includes which is deprecated" >>> ^ >>> any replacement for timeb.h > > Man page patch for PPS > > .It Cm pps Ar limit duration > Rule with the > .Cm pps > keyword will allow the first > .Ar limit > packets in each > .Ar duration > milliseconds. > > and it will be like blow > pps _limit duration_ > Rule with the pps keyword will allow the first _limit > _packets in > each _duration _milliseconds. > > is that OK? Done ,submitted. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/189721 From owner-freebsd-ipfw@FreeBSD.ORG Mon May 12 20:41:20 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39DF37DE for ; Mon, 12 May 2014 20:41:20 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 357962E16 for ; Mon, 12 May 2014 20:41:18 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 476173AE7B for ; Mon, 12 May 2014 13:41:12 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-ipfw@freebsd.org Subject: Re: Where do the boot time messages go? In-Reply-To: <20140512152327.A11699@sola.nimnet.asn.au> Date: Mon, 12 May 2014 13:41:12 -0700 Message-ID: <7346.1399927272@server1.tristatelogic.com> X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 20:41:20 -0000 In message <20140512152327.A11699@sola.nimnet.asn.au>, Ian Smith wrote: >... and scrolling back >the VT0 root console should reveal it/them. Thank you! I'm a bit ashamed to admit it, but I never even know about this console feature until today. It has already proved quite helpful to me in another context, and I will most certainly be using it soon to try to see if in fact I'm getting any boot-time errors from my ipfw setup. > > While unlikely, have a look at /var/run/dmesg.boot. > >Worth a try. Nope. The boot-time ipfw messages are not in there either. > > I see you have: firewall_logging="YES" > > Isn't it possible to DEFINE the firewall LOG? :) > > In other words; you ask it to log, but don't tell it WHERE. :) > > Doing so should provide the answers you're looking for. > >In /etc/syslog.conf you should see: >security.* /var/log/security Yes, quite. I do have that. But as I mentioned earlier, the boot-time messages relating to ipfw startup don't seem to be present within the /var/log/security file, and as someone else has mentioned, there's no reason that they should be. When my rules file is being processed, ipfw is most likely (verbosely) showing each of those in turn, but just to either stdout or stderr... and not syslogging them. Regards, rfg From owner-freebsd-ipfw@FreeBSD.ORG Mon May 12 22:46:22 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD148684 for ; Mon, 12 May 2014 22:46:22 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (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 6223C2E10 for ; Mon, 12 May 2014 22:46:22 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id s7so8181482lbd.28 for ; Mon, 12 May 2014 15:46:20 -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:date:message-id:subject :from:to:cc:content-type; bh=s6C0InEKp6ssPwa+nCxAgSQ2wHZEw5m1LK0AXX0j9R0=; b=FOEWYUXx0n4WjgfxBI2YDEVAaCwhw1I7DXRik/bwVj5R4u0bbO/0jzCbHcK1upKTGD UxQ8amssVMtNz2a6VyLueiTOitXRChgyaGrDr9xdnELXZI6diZ5y2g0yzQ1AzPRPXZbj 7gxilPslbJWB8VnCqOeyA8epShtiqdaZZo4iNUhQpLO0oEqtwrjIYGFWYbzfGLJpmwG0 2P5BucTQUlAebetlobGZ9ND7Z03d9h3ckY8bsl+UcNJhN6Ri/oxCeZJVJX31nL/lLDia Ldt28nFHXmitLDUrSyINyCGasC1jQNX5Ba2kbp1r2jNK2YfjmqH+ZLFs9dee9iy5fZaT oveQ== MIME-Version: 1.0 X-Received: by 10.152.29.133 with SMTP id k5mr3668759lah.44.1399934780135; Mon, 12 May 2014 15:46:20 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.107 with HTTP; Mon, 12 May 2014 15:46:20 -0700 (PDT) In-Reply-To: <5370FE5E.3000104@gmail.com> References: <5360F1F4.9060808@gmail.com> <5361105C.1040203@freebsd.org> <53611738.8010103@gmail.com> <53611EB1.4000406@gmail.com> <5364E097.9020106@gmail.com> <536AD13B.6080907@gmail.com> <536AD941.9090102@gmail.com> <20140508073816.GB64368@onelab2.iet.unipi.it> <536BACA4.7010702@gmail.com> <5370FE5E.3000104@gmail.com> Date: Tue, 13 May 2014 00:46:20 +0200 X-Google-Sender-Auth: 7Tngzy2H8WLld5juDfbtRIWAsKQ Message-ID: Subject: Re: feature of `packet per second` From: Luigi Rizzo To: bycn82 Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-ipfw@freebsd.org" , Luigi Rizzo X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 22:46:22 -0000 On Mon, May 12, 2014 at 7:01 PM, bycn82 wrote: > On 5/9/14 0:11, bycn82 wrote: > ... > Done ,submitted. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/189721 > can you clean up the formatting and style (including some gratuitous whitespace changes). Also there are several things to fix: - please use { } even for blocks with a single statement - please make count and duration 32 bit values. 16 bits are way too little for count, and there is no point to be stingy with count - count should not be incremented upon a 'DENY' or it could wrap (very risky for 16-bit values); cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Tue May 13 04:52:15 2014 Return-Path: Delivered-To: freebsd-ipfw@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC6921C3; Tue, 13 May 2014 04:52:15 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 A14F22A51; Tue, 13 May 2014 04:52:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4D4qF6W003274; Tue, 13 May 2014 04:52:15 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4D4qFSv003273; Tue, 13 May 2014 04:52:15 GMT (envelope-from linimon) Date: Tue, 13 May 2014 04:52:15 GMT Message-Id: <201405130452.s4D4qFSv003273@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 04:52:15 -0000 Old Synopsis: pps action for ipfw New Synopsis: [ipfw] [patch] pps action for ipfw Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Tue May 13 04:51:40 UTC 2014 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=189720 From owner-freebsd-ipfw@FreeBSD.ORG Tue May 13 04:54:45 2014 Return-Path: Delivered-To: freebsd-ipfw@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 231992BB; Tue, 13 May 2014 04:54:45 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 EC0002A80; Tue, 13 May 2014 04:54:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4D4siPc003505; Tue, 13 May 2014 04:54:44 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4D4si38003504; Tue, 13 May 2014 04:54:44 GMT (envelope-from linimon) Date: Tue, 13 May 2014 04:54:44 GMT Message-Id: <201405130454.s4D4si38003504@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/189655: [ipfw] ipfw does not pass same_ports option to kernel nat (libalias) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 04:54:45 -0000 Synopsis: [ipfw] ipfw does not pass same_ports option to kernel nat (libalias) Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Tue May 13 04:54:36 UTC 2014 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=189655 From owner-freebsd-ipfw@FreeBSD.ORG Tue May 13 05:18:36 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8832D847 for ; Tue, 13 May 2014 05:18:36 +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 D4CAA2C1B for ; Tue, 13 May 2014 05:18:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s4D5ISml091623; Tue, 13 May 2014 15:18:30 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 13 May 2014 15:18:28 +1000 (EST) From: Ian Smith To: "Ronald F. Guilmette" Subject: Re: Where do the boot time messages go? In-Reply-To: <7346.1399927272@server1.tristatelogic.com> Message-ID: <20140513140531.D11699@sola.nimnet.asn.au> References: <7346.1399927272@server1.tristatelogic.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 05:18:36 -0000 On Mon, 12 May 2014 13:41:12 -0700, Ronald F. Guilmette wrote: > In message <20140512152327.A11699@sola.nimnet.asn.au>, > Ian Smith wrote: > > >... and scrolling back > >the VT0 root console should reveal it/them. > > Thank you! > > I'm a bit ashamed to admit it, but I never even know about this console > feature until today. It has already proved quite helpful to me in another > context, and I will most certainly be using it soon to try to see if in > fact I'm getting any boot-time errors from my ipfw setup. > > > > While unlikely, have a look at /var/run/dmesg.boot. > > > >Worth a try. > > Nope. The boot-time ipfw messages are not in there either. No, they're not saved anywhere. If there was indeed an error message from ipfw then I thought it might have gone there, but I'm not sure. > >security.* /var/log/security > > Yes, quite. I do have that. > > But as I mentioned earlier, the boot-time messages relating to ipfw > startup don't seem to be present within the /var/log/security file, > and as someone else has mentioned, there's no reason that they should > be. When my rules file is being processed, ipfw is most likely > (verbosely) showing each of those in turn, but just to either stdout > or stderr... and not syslogging them. Yes; they do go to stdout (unless using -q) but that has nothing to do with verbose logging being set - as Bill pointed out, that's only to do with kernel mode syslogging of matching rules having the 'log' keyword. root@x200:~ # kldload ipfw && ipfw add 64000 allow ip from any to any 64000 allow ip from any to any root@x200:~ # ipfw add 65000 allow ip from any to any > test root@x200:~ # cat test 65000 allow ip from any to any And ipfw error messages do go to stderr, as is customary: root@x200:~ # ipfw add 65001 invalid >test ipfw: invalid action invalid root@x200:~ # cat test && rm test && kldunload ipfw root@x200:~ # Of course you don't have to wait to reboot to run your rules file again; as long as it begins with an 'ipfw -q flush' to clear existing rules, as it ought, just run '# sh /pathto/yourrulesfile' .. and you can redirect that output to a file if you want, though 'ipfw show' is usually more useful. As ever, the best advice is ipfw(8) cheers, Ian From owner-freebsd-ipfw@FreeBSD.ORG Tue May 13 10:57:59 2014 Return-Path: Delivered-To: freebsd-ipfw@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A25ECE70; Tue, 13 May 2014 10:57:59 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 78094297C; Tue, 13 May 2014 10:57:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4DAvx1U053644; Tue, 13 May 2014 10:57:59 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4DAvxj0053643; Tue, 13 May 2014 10:57:59 GMT (envelope-from linimon) Date: Tue, 13 May 2014 10:57:59 GMT Message-Id: <201405131057.s4DAvxj0053643@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: bin/189471: [ipfw] ipfw table regression X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 10:57:59 -0000 Old Synopsis: ipfw table regression New Synopsis: [ipfw] ipfw table regression Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Tue May 13 10:56:39 UTC 2014 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=189471 From owner-freebsd-ipfw@FreeBSD.ORG Tue May 13 14:20:01 2014 Return-Path: Delivered-To: freebsd-ipfw@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D0D8F7DA for ; Tue, 13 May 2014 14:20:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 BC34C2AD0 for ; Tue, 13 May 2014 14:20:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4DEK1T6027101 for ; Tue, 13 May 2014 14:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4DEK1Ri027099; Tue, 13 May 2014 14:20:01 GMT (envelope-from gnats) Date: Tue, 13 May 2014 14:20:01 GMT Message-Id: <201405131420.s4DEK1Ri027099@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org Cc: From: Marcelo Gondim Subject: Re: bin/189471: [ipfw] ipfw table regression Reply-To: Marcelo Gondim X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 14:20:01 -0000 The following reply was made to PR bin/189471; it has been noted by GNATS. From: Marcelo Gondim To: bug-followup@FreeBSD.org, dyr@smartspb.net Cc: Subject: Re: bin/189471: [ipfw] ipfw table regression Date: Tue, 13 May 2014 11:13:29 -0300 This is a multi-part message in MIME format. --------------020508070802030905040507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The problem continues. Try: # ipfw table 99 add 0.0.0.0/8 # ipfw table 99 list ::/8 0 # uname -a FreeBSD mail.xxxxxx.com.br 10.0-STABLE FreeBSD 10.0-STABLE #14 r265947: Tue May 13 08:18:03 BRT 2014 root@mail.xxxxxx.com.br:/usr/obj/usr/src/sys/GONDIM amd64 Cheers, --------------020508070802030905040507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The problem continues. Try:

# ipfw table 99 add 0.0.0.0/8
# ipfw table 99 list
::/8 0

# uname -a
FreeBSD mail.xxxxxx.com.br 10.0-STABLE FreeBSD 10.0-STABLE #14 r265947: Tue May 13 08:18:03 BRT 2014     root@mail.xxxxxx.com.br:/usr/obj/usr/src/sys/GONDIM  amd64

Cheers,
 --------------020508070802030905040507-- From owner-freebsd-ipfw@FreeBSD.ORG Fri May 16 11:41:08 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C9996AB for ; Fri, 16 May 2014 11:41:08 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 25EAC2565 for ; Fri, 16 May 2014 11:41:07 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id DB8D03ACD0 for ; Fri, 16 May 2014 04:41:04 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-ipfw@freebsd.org Subject: Zero packet counters? Date: Fri, 16 May 2014 04:41:04 -0700 Message-ID: <98317.1400240464@server1.tristatelogic.com> X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 11:41:08 -0000 Is there a way to reset ipfw's packet counters to zero (either all of them or selected individual counters) ... I mean, you know, without rebooting the whole system? From owner-freebsd-ipfw@FreeBSD.ORG Fri May 16 11:45:55 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC24970F for ; Fri, 16 May 2014 11:45:55 +0000 (UTC) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (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 6210925F5 for ; Fri, 16 May 2014 11:45:54 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id 10so1831377lbg.16 for ; Fri, 16 May 2014 04:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zhovner.com; s=love; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=oWhTx6M4s7Vsm3h4eyRiiyHVMpIfuHEESy3r3z+Ekr4=; b=To+8ymNQDCi519vzyvnQDkY7a7CTiyfz33MAQ+bj9trAfxvL9JzsriVSbHz8CvCukT YAOlt+JcP5iZMB37w+KqqgNYvpCgFKdVUHoU+G8jdg+s4kJwlyBgOTlMM6AGWjRgO70C f2M7AhV90OB0LTloxP0h5UveKPMA92Qsr1K8g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=oWhTx6M4s7Vsm3h4eyRiiyHVMpIfuHEESy3r3z+Ekr4=; b=PbJkCHQPzY6zqlaR0Pe2rpwL6ZLwenQPzM4B36ty7dEmbEEkFkoYOXHGgcauIvDXxx HPnCJGKM12Gs/iAYweesi/SQP9rnxxmnTbV/G2oJQB9foxUsJweWc/GLISE9ANsLdaan xN28GZW1rS2JnsddytOCEOREH3t9G/26/Oyz0+F2L745f9HiyjcceAvF3aINM/Ca4Ril CaAVUcY0qredMV4LlodWxeKrf5aZGUEzhi+KYtDoczsod8RneJSm081gygDGS86xwJJK TpXA53TKOYE0VQr1ho9Lvwo8ejRdlC4R7GVd+z0Qny65F8EW5b9VRlNCI8fXAeAXZR2V a3aA== X-Gm-Message-State: ALoCoQmXeiZ0q61pKUBkZKFdCDFy/OVu20o2KCHlLa4kTf0ky12MD2cZjtHQV5HXF0J1eNHJO4n2 X-Received: by 10.152.207.74 with SMTP id lu10mr11819226lac.28.1400240752820; Fri, 16 May 2014 04:45:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.18.198 with HTTP; Fri, 16 May 2014 04:45:22 -0700 (PDT) X-Originating-IP: [79.111.119.183] In-Reply-To: <98317.1400240464@server1.tristatelogic.com> References: <98317.1400240464@server1.tristatelogic.com> From: Pavel Zhovner Date: Fri, 16 May 2014 15:45:22 +0400 Message-ID: Subject: Re: Zero packet counters? To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 11:45:55 -0000 ipfw zero NUM Where NUM is rule number. On Fri, May 16, 2014 at 3:41 PM, Ronald F. Guilmette wrote: > > > Is there a way to reset ipfw's packet counters to zero (either all of > them or selected individual counters) ... I mean, you know, without > rebooting the whole system? > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://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 16 11:48:18 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0A86760 for ; Fri, 16 May 2014 11:48:18 +0000 (UTC) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (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 858D6260A for ; Fri, 16 May 2014 11:48:18 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id kq14so2447088pab.5 for ; Fri, 16 May 2014 04:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=zxKgtZY2Rq4jDfXzMeud9IXqjPqKg5XX260ZRVgkltQ=; b=DeXMuvam2eB1fEz1kOPXcNFV/aqB2kSDOEpNizDCF5ZfeJIUu2OwCzUhFn1F91h/zR jwEaAIn9iuXlz5RphJdOnXofzqswNINxMgSlWFz+wZC6u2NFKOPTeE5d0sMQaxQtlZCl wFNFzlvYOnwvCVmxl0h3thzCnqFImstHkv3ExsJMELjzztOqaL2EMae1o9Xlxda1k7Iv faOv9uOKNFzwm5Z2Rn5M3o1g1l623x/NLIM30e1xvjF25PASUcBe6nXc8hUXwkRRxcaQ pgOiQiITwKUqgnM3kCztMoimHMOoWIe2Jz+EpEZ6lSoh2eNrN+URIE46KV0MJHTC558m EL+w== X-Received: by 10.68.197.99 with SMTP id it3mr19907874pbc.37.1400240898139; Fri, 16 May 2014 04:48:18 -0700 (PDT) Received: from [192.168.1.101] ([183.90.37.148]) by mx.google.com with ESMTPSA id gg3sm14181924pbc.34.2014.05.16.04.48.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 May 2014 04:48:17 -0700 (PDT) Message-ID: <5375FAFF.90507@gmail.com> Date: Fri, 16 May 2014 19:48:15 +0800 From: bycn82 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Subject: Re: Zero packet counters? References: <98317.1400240464@server1.tristatelogic.com> In-Reply-To: <98317.1400240464@server1.tristatelogic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 11:48:18 -0000 On 5/16/14 19:41, Ronald F. Guilmette wrote: > > Is there a way to reset ipfw's packet counters to zero (either all of > them or selected individual counters) ... I mean, you know, without > rebooting the whole system? > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > I think the only way to reset the counter is "reboot the whole system" if you don't read the man page of ipfw. From owner-freebsd-ipfw@FreeBSD.ORG Fri May 16 11:49:34 2014 Return-Path: Delivered-To: freebsd-ipfw@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36A437AB; Fri, 16 May 2014 11:49:34 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 09CBB2617; Fri, 16 May 2014 11:49:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4GBnX0D046902; Fri, 16 May 2014 11:49:33 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4GBnX9O046901; Fri, 16 May 2014 11:49:33 GMT (envelope-from ae) Date: Fri, 16 May 2014 11:49:33 GMT Message-Id: <201405161149.s4GBnX9O046901@freefall.freebsd.org> To: ae@FreeBSD.org, freebsd-ipfw@FreeBSD.org, ae@FreeBSD.org From: ae@FreeBSD.org Subject: Re: kern/189655: [ipfw] ipfw does not pass same_ports option to kernel nat (libalias) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 11:49:34 -0000 Synopsis: [ipfw] ipfw does not pass same_ports option to kernel nat (libalias) Responsible-Changed-From-To: freebsd-ipfw->ae Responsible-Changed-By: ae Responsible-Changed-When: Fri May 16 11:49:10 UTC 2014 Responsible-Changed-Why: Take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=189655 From owner-freebsd-ipfw@FreeBSD.ORG Sat May 17 12:07:41 2014 Return-Path: Delivered-To: freebsd-ipfw@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85A038B6; Sat, 17 May 2014 12:07:41 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 5B5BE2B10; Sat, 17 May 2014 12:07:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4HC7fWQ032161; Sat, 17 May 2014 12:07:41 GMT (envelope-from melifaro@freefall.freebsd.org) Received: (from melifaro@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4HC7fbs032160; Sat, 17 May 2014 12:07:41 GMT (envelope-from melifaro) Date: Sat, 17 May 2014 12:07:41 GMT Message-Id: <201405171207.s4HC7fbs032160@freefall.freebsd.org> To: melifaro@FreeBSD.org, freebsd-ipfw@FreeBSD.org, melifaro@FreeBSD.org From: melifaro@FreeBSD.org Subject: Re: bin/189471: [ipfw] ipfw table regression X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 May 2014 12:07:41 -0000 Synopsis: [ipfw] ipfw table regression Responsible-Changed-From-To: freebsd-ipfw->melifaro Responsible-Changed-By: melifaro Responsible-Changed-When: Sat May 17 12:07:29 UTC 2014 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=189471 From owner-freebsd-ipfw@FreeBSD.ORG Sat May 17 15:10:52 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 84DF3A50 for ; Sat, 17 May 2014 15:10:52 +0000 (UTC) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (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 5908D2B78 for ; Sat, 17 May 2014 15:10:52 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id fb1so3827416pad.9 for ; Sat, 17 May 2014 08:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=aFfrxecjWcObtxnD1mKmWxJJXKRL495yi7MiecI6sV4=; b=tmdR4MvVKZtQttOCnud3N/vQBmldjHnKVmc+2BiiOXFQW7UgWdNI1Ipz011gYzM3Wt Iwfqvng0tPadqo19ZGB4hneq2EfoZ9qmsGJ72LZheRFNtBTxG05wG4OTXNaR7U4OTZ67 UikOZsjlhzFPgNoa8C4GrTBxSx2bFYg8d+iyCjG88rpyLXhg4nJqc811W1PUySmJjNwn VMNRxQM2V/P6lDlts6VZ2WVGngBJ5fKenaynaYWg3yZv3GfFQ5T2GiGTHgKg/cT30I0L 5S0ykgy7aWJQLhWEGkfg44rnZ+9TGV+QlM+SvNbVKddav8zuVVHoFiAQkrELwK8mT0SI gf/Q== X-Received: by 10.66.122.72 with SMTP id lq8mr29459052pab.69.1400339451949; Sat, 17 May 2014 08:10:51 -0700 (PDT) Received: from [192.168.1.102] ([183.90.37.121]) by mx.google.com with ESMTPSA id di3sm20442852pbc.11.2014.05.17.08.10.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 17 May 2014 08:10:50 -0700 (PDT) Message-ID: <53777BF8.9000409@gmail.com> Date: Sat, 17 May 2014 23:10:48 +0800 From: bycn82 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Subject: Re: bin/189471: [ipfw] ipfw table regression References: <201405171207.s4HC7fbs032160@freefall.freebsd.org> In-Reply-To: <201405171207.s4HC7fbs032160@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 May 2014 15:10:52 -0000 On 5/17/14 20:07, melifaro@FreeBSD.org wrote: > Synopsis: [ipfw] ipfw table regression > > Responsible-Changed-From-To: freebsd-ipfw->melifaro > Responsible-Changed-By: melifaro > Responsible-Changed-When: Sat May 17 12:07:29 UTC 2014 > Responsible-Changed-Why: > Take. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=189471 > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to"freebsd-ipfw-unsubscribe@freebsd.org" > Hi, About the table , I read the code last time and I noticed that you are still working on it, Can you please explain in which direction you are enhancing it ? I am willing to help if I can. Actually I am trying to introduce some new features into the table. regards, bycn82 From owner-freebsd-ipfw@FreeBSD.ORG Sat May 17 16:43:47 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4900710B for ; Sat, 17 May 2014 16:43:47 +0000 (UTC) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::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 1A7D12397 for ; Sat, 17 May 2014 16:43:47 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id rd3so3904210pab.1 for ; Sat, 17 May 2014 09:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=rpoOFcQPVG5KvouOsP9bkn8NFH0ZCGE4CWfe8DyXCpM=; b=oUx+63fPr6RQBzJ6MLYAdVhXbAzHSLwLHwJYzKL8gMF8LvLo8XaFvxl7dQL+ScCeg3 DXiv44hqW15ji0iOhqL5lOTEUKDuu2HcBLd5R9wHTakepLzS3gFFfte/zt1aFNm9n7jl FceLQbbdSa5rnuDTu0xB4zOKziCOvhzLYtkreahEFW9dfeIIVGTVlmHDH20zOeVdWSwx DZ/WVBY6nduJBMBh2skwXzEzD/P35dIfjDtbZxfjQtZoSFXWzdUA2EBFb91KevwcmTZS kC/GvQZVwGC58leIO0REpEvDoFfsvKQ+6+WZvk8LzpCrP/hrqpGQDbqJqINvWETCkBMa 7F9A== X-Received: by 10.68.181.67 with SMTP id du3mr30123142pbc.96.1400345026543; Sat, 17 May 2014 09:43:46 -0700 (PDT) Received: from [192.168.1.102] ([183.90.37.121]) by mx.google.com with ESMTPSA id ci4sm20779713pbb.50.2014.05.17.09.43.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 17 May 2014 09:43:43 -0700 (PDT) Message-ID: <537791BC.7090209@gmail.com> Date: Sun, 18 May 2014 00:43:40 +0800 From: bycn82 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Freddie Cash Subject: Re: feature of `packet per second` References: <5360F1F4.9060808@gmail.com> <5361105C.1040203@freebsd.org> <53611738.8010103@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-ipfw@freebsd.org" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 May 2014 16:43:47 -0000 On 4/30/14 23:45, Freddie Cash wrote: > On Wed, Apr 30, 2014 at 8:31 AM, bycn82 >wrote: > > On 4/30/14 23:01, Julian Elischer wrote: > > On 4/30/14, 8:52 PM, bycn82 wrote: > > Hi > > `packet per second` it is easy to be implemented using > iptables, there is a module named `recent`, but in using > ipfw, Do we have any solution to fulfill it? check the > link below > https://forums.freebsd.org/viewtopic.php?f=44&t=42933&p=258441#p258441 > > > > since I don't use linux.. what is "packet per second"?.. does > it report it or set a limit on it? > > > bycn82 > > _______________________________________________ > freebsd-ipfw@freebsd.org > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to > "freebsd-ipfw-unsubscribe@freebsd.org > " > > > > > Yes, "Packets Per Second"means limit a connection based on the > packets number, for example, If I allow 2 ICMP packets come to my > server in each individual second. only the first 2 packets will > be allow, all others in the same second will be dropped. > > > ​For ICMP, specifically, there's a sysctl to control the rate (per > second): > > # sysctl -d ​net.inet.icmp.icmplim > net.inet.icmp.icmplim: Maximum number of ICMP responses per second > > > For everything else, you'd want to use dummynet(4). > > -- > Freddie Cash > fjwcash@gmail.com Hi As Freddie said, for ICMP protocal, actually it comes with this 'PPS' feature. So I just double checked the source code of ip_icmp.c file because I dont know this before. And suddenly a question came into my mind. "Why I dont know it before" Yes, I can list down all the sysctl option by `sysctl -a` command, But we dont have any page which introduced all the options, root@FB10Head:~ # sysctl -a | grep rexmit_min net.inet.tcp.rexmit_min: 30 root@FB10Head:~ # sysctl -a | grep icmplim net.inet.icmp.icmplim: 200 net.inet.icmp.icmplim_output: 1 root@FB10Head:~ # sysctl -a | wc -l 4120 root@FB10Head:~ # So, more than 4000 options!!! Maybe we should have mail-list to collect the introduction of all the options or a public WiKi page like wikipedia for it. Regards, bycn82 From owner-freebsd-ipfw@FreeBSD.ORG Mon May 19 11:06:47 2014 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 266FA36F for ; Mon, 19 May 2014 11:06:47 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 135A72DB1 for ; Mon, 19 May 2014 11:06:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4JB6k8r080044 for ; Mon, 19 May 2014 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4JB6kpU080042 for freebsd-ipfw@FreeBSD.org; Mon, 19 May 2014 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 May 2014 11:06:46 GMT Message-Id: <201405191106.s4JB6kpU080042@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 11:06:47 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/189720 ipfw [ipfw] [patch] pps action for ipfw o bin/187904 ipfw [ipfw] ipfw(8) does not properly recognize the network o kern/183479 ipfw [ipfw] ipfw table contains duplicate entry. o kern/180731 ipfw [ipfw] problem with displaying 255.255.255.255 address o kern/180729 ipfw [ipfw] ipfw nat show empty output o kern/178482 ipfw [ipfw] logging problem from vnet jail o kern/178480 ipfw [ipfw] dynamically loaded ipfw with a vimage kernel do o kern/178317 ipfw [ipfw] ipfw options need to specifed in specific order o kern/177948 ipfw [ipfw] ipfw fails to parse port ranges (p1-p2) for udp o kern/176503 ipfw [ipfw] ipfw layer2 problem o kern/170604 ipfw [ipfw] ipv6 reass broken o conf/167822 ipfw [ipfw] [patch] start script doesn't load firewall_type o kern/166406 ipfw [ipfw] ipfw does not set ALTQ identifier for ipv6 traf o kern/165939 ipfw [ipfw] bug: incomplete firewall rules loaded if tables o kern/165190 ipfw [ipfw] [lo] [patch] loopback interface is not marking o kern/158066 ipfw [ipfw] ipfw + netgraph + multicast = multicast packets o kern/157689 ipfw [ipfw] ipfw nat config does not accept nonexistent int f kern/155927 ipfw [ipfw] ipfw stops to check packets for compliance with o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw [ipfw] does not support specifying rules with ICMP cod o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. f kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l f kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes s kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 45 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Fri May 23 13:53:22 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DFFEC3C3 for ; Fri, 23 May 2014 13:53:22 +0000 (UTC) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (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 7A6842F3E for ; Fri, 23 May 2014 13:53:22 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id r20so885619wiv.7 for ; Fri, 23 May 2014 06:53:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=xzogMQ7DAssl82o6ObdTpDVvCyuz7d1TqWpzLCdYjjg=; b=ywQHS9D95AmeWta582OppQBqbA8fts/0FQl4qIRTon/pP69DGi5nR3JI/F9kEBxrc7 dIrLZtIXRQOoGbfIvZoZXFz0UDoySxZS91glWIPStwCv53mxor+r7XML0vVUY3kKX1zc Mq9xdDBDwlUiaqrpDPYyTeu6uhDimRpHLoOHT1NBtrZhYgperQeXyhZQLAa4IAf2J192 4+uih5F5gkMdAj0yBiN/Aui57P4LwvvH5A+W6uHF3VmO8E8kCreChpAlUp6WO9i/9yBb N4EVb49b3f7klaGNjGEgF9FL3rTuWLPrgb5+g8z9MFOMv1gDMt0XNYHLoCoLj0k8xCtw DCzQ== X-Received: by 10.194.243.3 with SMTP id wu3mr4387171wjc.29.1400853200777; Fri, 23 May 2014 06:53:20 -0700 (PDT) Received: from ?IPv6:2001:62a:4:411:442c:8378:55cd:8ae3? ([2001:62a:4:411:442c:8378:55cd:8ae3]) by mx.google.com with ESMTPSA id l4sm3080355wiy.0.2014.05.23.06.53.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 May 2014 06:53:20 -0700 (PDT) From: Patrick Zwickl Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Dummynet pipe cascades Message-Id: Date: Fri, 23 May 2014 15:53:18 +0200 To: freebsd-ipfw@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 13:53:23 -0000 Dear all, I am currently experimenting with ipfw dummynet features (coming rather = from the netem tc corner; so being new to dummynet and apologise for = these kind of questions) and was wondering how to syntactically achieve = "build cascades of pipes=94 listed on [1]=92s front page. Unfortunately, = I could not find a minimal example for this in the documentation (or I = missed the point). Background: I am currently looking for concepts allowing me to put some = traffic into a pipe being followed by several queues, the scheduler and = then reinserted into another pipe (optimally as clean as possible). So, = basically, a cascade of pipes, optimally being able to consume from = different other pipes or interfaces. =46rom the statement in [1], I = assume ipfw + dummynet could be the perfect playground for this, but = from the syntax it was not clear to me how this is done. Any pointer to a minimal example or any reading recommendation would be = highly appreciated (maybe I have been searching the wrong channels so = far). Thanks in advance for reading and potentially commenting :) Best regards, Patrick [1] http://info.iet.unipi.it/~luigi/dummynet/#3d2a= From owner-freebsd-ipfw@FreeBSD.ORG Mon May 26 11:06:47 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0525DE5 for ; Mon, 26 May 2014 11:06:47 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 8D41C24DD for ; Mon, 26 May 2014 11:06:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4QB6l0j032049 for ; Mon, 26 May 2014 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4QB6lW3032047 for freebsd-ipfw@FreeBSD.org; Mon, 26 May 2014 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 26 May 2014 11:06:47 GMT Message-Id: <201405261106.s4QB6lW3032047@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 11:06:47 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/189720 ipfw [ipfw] [patch] pps action for ipfw o bin/187904 ipfw [ipfw] ipfw(8) does not properly recognize the network o kern/183479 ipfw [ipfw] ipfw table contains duplicate entry. o kern/180731 ipfw [ipfw] problem with displaying 255.255.255.255 address o kern/180729 ipfw [ipfw] ipfw nat show empty output o kern/178482 ipfw [ipfw] logging problem from vnet jail o kern/178480 ipfw [ipfw] dynamically loaded ipfw with a vimage kernel do o kern/178317 ipfw [ipfw] ipfw options need to specifed in specific order o kern/177948 ipfw [ipfw] ipfw fails to parse port ranges (p1-p2) for udp o kern/176503 ipfw [ipfw] ipfw layer2 problem o kern/170604 ipfw [ipfw] ipv6 reass broken o conf/167822 ipfw [ipfw] [patch] start script doesn't load firewall_type o kern/166406 ipfw [ipfw] ipfw does not set ALTQ identifier for ipv6 traf o kern/165939 ipfw [ipfw] bug: incomplete firewall rules loaded if tables o kern/165190 ipfw [ipfw] [lo] [patch] loopback interface is not marking o kern/158066 ipfw [ipfw] ipfw + netgraph + multicast = multicast packets o kern/157689 ipfw [ipfw] ipfw nat config does not accept nonexistent int f kern/155927 ipfw [ipfw] ipfw stops to check packets for compliance with o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw [ipfw] does not support specifying rules with ICMP cod o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. f kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l f kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes s kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 45 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon May 26 16:57:30 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68DF6EBE for ; Mon, 26 May 2014 16:57:30 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 2B8CA2720 for ; Mon, 26 May 2014 16:57:29 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 1A9327300B; Mon, 26 May 2014 19:01:55 +0200 (CEST) Date: Mon, 26 May 2014 19:01:55 +0200 From: Luigi Rizzo To: Patrick Zwickl Subject: Re: Dummynet pipe cascades Message-ID: <20140526170155.GB40172@onelab2.iet.unipi.it> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 16:57:30 -0000 On Fri, May 23, 2014 at 03:53:18PM +0200, Patrick Zwickl wrote: > Dear all, > > I am currently experimenting with ipfw dummynet features (coming rather from the netem tc corner; so being new to dummynet and apologise for these kind of questions) and was wondering how to syntactically achieve "build cascades of pipes? listed on [1]?s front page. Unfortunately, I could not find a minimal example for this in the documentation (or I missed the point). > > Background: I am currently looking for concepts allowing me to put some traffic into a pipe being followed by several queues, the scheduler and then reinserted into another pipe (optimally as clean as possible). So, basically, a cascade of pipes, optimally being able to consume from different other pipes or interfaces. From the statement in [1], I assume ipfw + dummynet could be the perfect playground for this, but from the syntax it was not clear to me how this is done. > > Any pointer to a minimal example or any reading recommendation would be highly appreciated (maybe I have been searching the wrong channels so far). Thanks in advance for reading and potentially commenting :) the trick to enable cascades is to set the sysctl variable net.inet.ip.fw.one_pass=0 (or equivalent in linux, /sys/modules/...) so that packets coming out from a pipe re-enter the firewall at the next rule. cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Thu May 29 14:10:02 2014 Return-Path: Delivered-To: freebsd-ipfw@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2773284F for ; Thu, 29 May 2014 14:10:02 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 EE1842DDB for ; Thu, 29 May 2014 14:10:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4TEA1Kh010182 for ; Thu, 29 May 2014 14:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4TEA1c0010181; Thu, 29 May 2014 14:10:01 GMT (envelope-from gnats) Date: Thu, 29 May 2014 14:10:01 GMT Message-Id: <201405291410.s4TEA1c0010181@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org Cc: From: Luigi Rizzo Subject: kern/189720: [ipfw] [patch] pps action for ipfw Reply-To: Luigi Rizzo X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:10:02 -0000 The following reply was made to PR kern/189720; it has been noted by GNATS. From: Luigi Rizzo To: bug-followup@FreeBSD.org, bycn82@gmail.com Cc: Subject: kern/189720: [ipfw] [patch] pps action for ipfw Date: Thu, 29 May 2014 16:12:16 +0200 Hi, I have looked at the update from May 13th but it is not ready yet, the code assumes HZ=1000 so 1 tick=1ms. The translation can be done in userspace or in the kernel. I would prefer the latter. Please note that the count might need to be adjusted accordingly if 1/HZ > duration. I covered most of these things in the email exchange before the patch was submitted. cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Thu May 29 15:10:01 2014 Return-Path: Delivered-To: freebsd-ipfw@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57687775 for ; Thu, 29 May 2014 15:10:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 43E7523DD for ; Thu, 29 May 2014 15:10:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4TFA1fY029150 for ; Thu, 29 May 2014 15:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4TFA1w5029149; Thu, 29 May 2014 15:10:01 GMT (envelope-from gnats) Date: Thu, 29 May 2014 15:10:01 GMT Message-Id: <201405291510.s4TFA1w5029149@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org Cc: From: "bycn82" Subject: RE: kern/189720: [ipfw] [patch] pps action for ipfw Reply-To: "bycn82" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 15:10:01 -0000 The following reply was made to PR kern/189720; it has been noted by GNATS. From: "bycn82" To: "'Luigi Rizzo'" , Cc: Subject: RE: kern/189720: [ipfw] [patch] pps action for ipfw Date: Thu, 29 May 2014 23:06:27 +0800 -----Original Message----- From: Luigi Rizzo [mailto:rizzo@iet.unipi.it]=20 Sent: 29 May, 2014 22:12 To: bug-followup@FreeBSD.org; bycn82@gmail.com Subject: kern/189720: [ipfw] [patch] pps action for ipfw Hi, I have looked at the update from May 13th but it is not ready yet, the = code assumes HZ=3D1000 so 1 tick=3D1ms. The translation can be done in userspace or in the kernel. I would prefer the latter. I see,=20 If the HZ=3D3, that means every tick=3D333ms And if the user wants to =E2=80=9C 1 packet per 500ms=E2=80=9D, then in = the backend will not do the exactly the same as what user expect. Actually the implementation should be =E2=80=9Cpackets per = ticks=E2=80=9D, so how about this? Instead of translate it in codes. Why = not update the document, and explain it to the user in the document ? Please note that the count might need to be adjusted accordingly if 1/HZ = > duration. I covered most of these things in the email exchange before = the patch was submitted. cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Thu May 29 15:20:03 2014 Return-Path: Delivered-To: freebsd-ipfw@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C2B6B2B for ; Thu, 29 May 2014 15:20:03 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 EF27324D0 for ; Thu, 29 May 2014 15:20:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4TFK1NU032926 for ; Thu, 29 May 2014 15:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4TFK124032925; Thu, 29 May 2014 15:20:01 GMT (envelope-from gnats) Date: Thu, 29 May 2014 15:20:01 GMT Message-Id: <201405291520.s4TFK124032925@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org Cc: From: "'Luigi Rizzo'" Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw Reply-To: "'Luigi Rizzo'" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 15:20:03 -0000 The following reply was made to PR kern/189720; it has been noted by GNATS. From: 'Luigi Rizzo' To: bycn82 Cc: bug-followup@FreeBSD.org Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw Date: Thu, 29 May 2014 17:17:59 +0200 On Thu, May 29, 2014 at 11:06:27PM +0800, bycn82 wrote: > > > -----Original Message----- > From: Luigi Rizzo [mailto:rizzo@iet.unipi.it] > Sent: 29 May, 2014 22:12 > To: bug-followup@FreeBSD.org; bycn82@gmail.com > Subject: kern/189720: [ipfw] [patch] pps action for ipfw > > Hi, > I have looked at the update from May 13th but it is not ready yet, the code assumes HZ=1000 so 1 tick=1ms. > > The translation can be done in userspace or in the kernel. > I would prefer the latter. > I see, > If the HZ=3, that means every tick=333ms > And if the user wants to ??? 1 packet per 500ms???, then in the backend will not do the exactly the same as what user expect. > > Actually the implementation should be ???packets per ticks???, so how about this? Instead of translate it in codes. Why not update the document, and explain it to the user in the document ? 'Packets per tick' this is not a useful specification since the tick's duration is unknown to the user. Depending on the platform you can have HZ ranging from 15-20 (on windows) to 10000 or even more. Normal values are 100, 250, 1000 but you just cannot know what you are going to get. Yes there are rounding issues, and yes it is boring to write code to handle them. luigi From owner-freebsd-ipfw@FreeBSD.ORG Thu May 29 15:30:35 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93E7C163 for ; Thu, 29 May 2014 15:30:35 +0000 (UTC) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (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 688B6262A for ; Thu, 29 May 2014 15:30:35 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id kq14so535816pab.19 for ; Thu, 29 May 2014 08:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=/jVW2nbEkzRG9HSKPUF3Nsl2wpudjU+Ts9iTwMp9/6k=; b=QlZXHYOQ1B9miRqsF8xfAIfl86w6YHPfuqehRRGwehGyLNpjnPtpp2utulTY/AJBXu VK1H+vRTssssurGOgJiMn3WUZ/L0Of4SwHzPJ9h6418AhYZF70tw8anL0cRSjtrraKcF axreJJ16Lh/7C1TU2fSz2No/1qyBgB9u1ij8kIrYbU4NsaXuJl1q3b05OXIDlYxed3XI 2IkGczBqVM78MfnTEGYvO3676buZ3Up1f6uEfcaCIjqn7k//Oi6ERLj9cgIauWie0pjb 0uCwG20vVzbx/YR9d81tIbjyMBCPn1PZLTN6y9f8ekIAolc+iS28ushGCDQgyofqn/Kj xLBg== X-Received: by 10.68.173.65 with SMTP id bi1mr9968535pbc.130.1401377434686; Thu, 29 May 2014 08:30:34 -0700 (PDT) Received: from billwin7 (amx-tls2.starhub.net.sg. [203.116.164.12]) by mx.google.com with ESMTPSA id mt1sm1798334pbb.31.2014.05.29.08.30.32 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 29 May 2014 08:30:34 -0700 (PDT) From: "bycn82" To: "'Luigi Rizzo'" , References: <201405291520.s4TFK124032925@freefall.freebsd.org> In-Reply-To: <201405291520.s4TFK124032925@freefall.freebsd.org> Subject: RE: kern/189720: [ipfw] [patch] pps action for ipfw Date: Thu, 29 May 2014 23:30:31 +0800 Message-ID: <007f01cf7b52$efd8a0c0$cf89e240$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHbWuE+qjuTx3is0SfKFp0zAb5aLJs/7YGg Content-Language: en-us X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 15:30:35 -0000 I got it, if the HZ=3D3, it always cannot meet the " 1 packet per 500ms" = perfectly.=20 But if we to "X packet per Y ticks", actually the result is the same, = still cannot meet the "1 packet per 500 ms" perfectly, instead, the = "packet per Y ticks" will force user to use " X packet per Y*300 ms". = And the user need to understand how many millisecond each tick is . =20 So I will update it this weekend.=20 > -----Original Message----- > From: owner-freebsd-ipfw@freebsd.org [mailto:owner-freebsd- > ipfw@freebsd.org] On Behalf Of 'Luigi Rizzo' > Sent: 29 May, 2014 23:20 > To: freebsd-ipfw@FreeBSD.org > Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw >=20 > The following reply was made to PR kern/189720; it has been noted by > GNATS. >=20 > From: 'Luigi Rizzo' > To: bycn82 > Cc: bug-followup@FreeBSD.org > Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw > Date: Thu, 29 May 2014 17:17:59 +0200 >=20 > On Thu, May 29, 2014 at 11:06:27PM +0800, bycn82 wrote: > > > > > > -----Original Message----- > > From: Luigi Rizzo [mailto:rizzo@iet.unipi.it] > Sent: 29 May, 2014 = 22:12 > To: > bug-followup@FreeBSD.org; bycn82@gmail.com > Subject: kern/189720: > [ipfw] [patch] pps action for ipfw > > Hi, > I have looked at the = update from > May 13th but it is not ready yet, the code assumes HZ=3D1000 so 1 = tick=3D1ms. > > > > The translation can be done in userspace or in the kernel. > > I would prefer the latter. > > I see, > > If the HZ=3D3, that means every tick=3D333ms > And if the user = wants to ??? 1 > packet per 500ms???, then in the backend will not do the exactly the = same as > what user expect. > > > > Actually the implementation should be ???packets per ticks???, so = how > about this? Instead of translate it in codes. Why not update the = document, > and explain it to the user in the document ? >=20 > 'Packets per tick' this is not a useful specification since the = tick's duration is > unknown to the user. > Depending on the platform you can have HZ ranging from 15-20 (on = windows) > to 10000 or even more. Normal values are 100, 250, 1000 but you just = cannot > know what you are going to get. >=20 > Yes there are rounding issues, and yes it is boring to write code to = handle > them. >=20 > luigi > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://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 30 14:38:52 2014 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57E94251 for ; Fri, 30 May 2014 14:38:52 +0000 (UTC) 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 3633C2C6B for ; Fri, 30 May 2014 14:38:51 +0000 (UTC) Received: from jre-mbp.elischer.org (etroy.elischer.org [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s4UEcemu070222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 30 May 2014 07:38:42 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <538897EA.5030405@freebsd.org> Date: Fri, 30 May 2014 22:38:34 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: bycn82 , "'Luigi Rizzo'" , freebsd-ipfw@FreeBSD.org Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw References: <201405291520.s4TFK124032925@freefall.freebsd.org> <007f01cf7b52$efd8a0c0$cf89e240$@gmail.com> In-Reply-To: <007f01cf7b52$efd8a0c0$cf89e240$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 14:38:52 -0000 On 5/29/14, 11:30 PM, bycn82 wrote: > I got it, > > if the HZ=3, it always cannot meet the " 1 packet per 500ms" perfectly. > But if we to "X packet per Y ticks", actually the result is the same, still cannot meet the "1 packet per 500 ms" perfectly, instead, the "packet per Y ticks" will force user to use " X packet per Y*300 ms". And the user need to understand how many millisecond each tick is . on e can write an implementation that notes how much the calculation was off by for each tick and corrects the number for the next tick.. e.g. with Hz=10, 8pps should give sometimes 1ppt and sometimes 0ppt but a simple calculation will always give 0 every tick so you need to have some way of carrying forward 'unused bandwidth' so that teh calculation looks like (over a second) ppt(real) ppt(int) 0.8 (0) 0.8+0.8=1.6 (1) 0.6+0.8=1.4 (1) (subtract 1 from 1.6, and then add the 0.8 per tick) 0.4+0.8=1.2 (1) 0.2+0.8=1.0 (1) 0.0+0.8=0.8(0) (sequence repeats) 0.8+0.8=1.6 (1) 0.6+0.8=1.4 (1) 0.4+0.8=1.2 (1) 0.2+0.8=1.0 (1) 0.0+0.8=0.8(0) if you use any of the the int(ppt) in a tick you subtract the amount used. if not you allow it to build, up to some maximum value. (sequence repeats) 0.8+0.8=1.6 (1) (not used) 1.6+0.8=2.4 (2) (not used) 2.4+0.8=3.2 (3) (not used) 3.2+0.8=4.0 (4) (4 packets allowed through further packets held or dropped) 0.0+0.8=0.8(0) 0.8+0.8=1.6 (1) (not used) 1.6+0.8=2.4 (2) (not used) 2.4+0.8=3.2 (3) 1 packet used.. 1.0 subtracted 2.2+0.8=3.0 (4) (4 packets allowed through further packets held or dropped) 0.0+0.8=0.8(0) etc. > So I will update it this weekend. > > >> -----Original Message----- >> From: owner-freebsd-ipfw@freebsd.org [mailto:owner-freebsd- >> ipfw@freebsd.org] On Behalf Of 'Luigi Rizzo' >> Sent: 29 May, 2014 23:20 >> To: freebsd-ipfw@FreeBSD.org >> Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw >> >> The following reply was made to PR kern/189720; it has been noted by >> GNATS. >> >> From: 'Luigi Rizzo' >> To: bycn82 >> Cc: bug-followup@FreeBSD.org >> Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw >> Date: Thu, 29 May 2014 17:17:59 +0200 >> >> On Thu, May 29, 2014 at 11:06:27PM +0800, bycn82 wrote: >> > >> > >> > -----Original Message----- >> > From: Luigi Rizzo [mailto:rizzo@iet.unipi.it] > Sent: 29 May, 2014 22:12 > To: >> bug-followup@FreeBSD.org; bycn82@gmail.com > Subject: kern/189720: >> [ipfw] [patch] pps action for ipfw > > Hi, > I have looked at the update from >> May 13th but it is not ready yet, the code assumes HZ=1000 so 1 tick=1ms. >> > >> > The translation can be done in userspace or in the kernel. >> > I would prefer the latter. >> > I see, >> > If the HZ=3, that means every tick=333ms > And if the user wants to ??? 1 >> packet per 500ms???, then in the backend will not do the exactly the same as >> what user expect. >> > >> > Actually the implementation should be ???packets per ticks???, so how >> about this? Instead of translate it in codes. Why not update the document, >> and explain it to the user in the document ? >> >> 'Packets per tick' this is not a useful specification since the tick's duration is >> unknown to the user. >> Depending on the platform you can have HZ ranging from 15-20 (on windows) >> to 10000 or even more. Normal values are 100, 250, 1000 but you just cannot >> know what you are going to get. >> >> Yes there are rounding issues, and yes it is boring to write code to handle >> them. >> >> luigi >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://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 30 14:39:49 2014 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B24B2AC for ; Fri, 30 May 2014 14:39:49 +0000 (UTC) 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 58CB82C85 for ; Fri, 30 May 2014 14:39:49 +0000 (UTC) Received: from jre-mbp.elischer.org (etroy.elischer.org [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s4UEdhIV070232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 30 May 2014 07:39:46 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <53889829.6030307@freebsd.org> Date: Fri, 30 May 2014 22:39:37 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: bycn82 , "'Luigi Rizzo'" , freebsd-ipfw@FreeBSD.org Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw References: <201405291520.s4TFK124032925@freefall.freebsd.org> <007f01cf7b52$efd8a0c0$cf89e240$@gmail.com> In-Reply-To: <007f01cf7b52$efd8a0c0$cf89e240$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 14:39:49 -0000 On 5/29/14, 11:30 PM, bycn82 wrote: > I got it, > > if the HZ=3, it always cannot meet the " 1 packet per 500ms" perfectly. > But if we to "X packet per Y ticks", actually the result is the same, still cannot meet the "1 packet per 500 ms" perfectly, instead, the "packet per Y ticks" will force user to use " X packet per Y*300 ms". And the user need to understand how many millisecond each tick is . on e can write an implementation that notes how much the calculation was off by for each tick and corrects the number for the next tick.. e.g. with Hz=10, 8pps should give sometimes 1ppt and sometimes 0ppt but a simple calculation will always give 0 every tick so you need to have some way of carrying forward 'unused bandwidth' so that teh calculation looks like (over a second) ppt(real) ppt(int) 0.8 (0) 0.8+0.8=1.6 (1) 0.6+0.8=1.4 (1) (subtract 1 from 1.6, and then add the 0.8 per tick) 0.4+0.8=1.2 (1) 0.2+0.8=1.0 (1) 0.0+0.8=0.8(0) (sequence repeats) 0.8+0.8=1.6 (1) 0.6+0.8=1.4 (1) 0.4+0.8=1.2 (1) 0.2+0.8=1.0 (1) 0.0+0.8=0.8(0) if you use any of the the int(ppt) in a tick you subtract the amount used. if not you allow it to build, up to some maximum value. (sequence repeats) 0.8+0.8=1.6 (1) (not used) 1.6+0.8=2.4 (2) (not used) 2.4+0.8=3.2 (3) (not used) 3.2+0.8=4.0 (4) (4 packets allowed through further packets held or dropped) 0.0+0.8=0.8(0) 0.8+0.8=1.6 (1) (not used) 1.6+0.8=2.4 (2) (not used) 2.4+0.8=3.2 (3) 1 packet used.. 1.0 subtracted 2.2+0.8=3.0 (4) (4 packets allowed through further packets held or dropped) 0.0+0.8=0.8(0) etc. one does this with some form of fixed point arithmetic as floating point isn't used in the kernel. > So I will update it this weekend. > > >> -----Original Message----- >> From: owner-freebsd-ipfw@freebsd.org [mailto:owner-freebsd- >> ipfw@freebsd.org] On Behalf Of 'Luigi Rizzo' >> Sent: 29 May, 2014 23:20 >> To: freebsd-ipfw@FreeBSD.org >> Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw >> >> The following reply was made to PR kern/189720; it has been noted by >> GNATS. >> >> From: 'Luigi Rizzo' >> To: bycn82 >> Cc: bug-followup@FreeBSD.org >> Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw >> Date: Thu, 29 May 2014 17:17:59 +0200 >> >> On Thu, May 29, 2014 at 11:06:27PM +0800, bycn82 wrote: >> > >> > >> > -----Original Message----- >> > From: Luigi Rizzo [mailto:rizzo@iet.unipi.it] > Sent: 29 May, 2014 22:12 > To: >> bug-followup@FreeBSD.org; bycn82@gmail.com > Subject: kern/189720: >> [ipfw] [patch] pps action for ipfw > > Hi, > I have looked at the update from >> May 13th but it is not ready yet, the code assumes HZ=1000 so 1 tick=1ms. >> > >> > The translation can be done in userspace or in the kernel. >> > I would prefer the latter. >> > I see, >> > If the HZ=3, that means every tick=333ms > And if the user wants to ??? 1 >> packet per 500ms???, then in the backend will not do the exactly the same as >> what user expect. >> > >> > Actually the implementation should be ???packets per ticks???, so how >> about this? Instead of translate it in codes. Why not update the document, >> and explain it to the user in the document ? >> >> 'Packets per tick' this is not a useful specification since the tick's duration is >> unknown to the user. >> Depending on the platform you can have HZ ranging from 15-20 (on windows) >> to 10000 or even more. Normal values are 100, 250, 1000 but you just cannot >> know what you are going to get. >> >> Yes there are rounding issues, and yes it is boring to write code to handle >> them. >> >> luigi >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://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 30 15:06:48 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5214D35D; Fri, 30 May 2014 15:06:48 +0000 (UTC) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (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 1ECB32F4C; Fri, 30 May 2014 15:06:48 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id v10so1038313pde.18 for ; Fri, 30 May 2014 08:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=7YuiCE1fR9TNYBdiqSHuta2c6MmeaLyGvQZVehPBpHs=; b=XriyXhZ0VB3LpsvZqUhdXs6V3Fvhp6vDnSy26FU0R1ZjrPGAUfDoVb5vAAXSd3Z/C1 meWt7oOIxFG+iQ3DUbHH9YsA+ZNXN7ZlEKxb44+8xXOhYpPPauzTeZrwbww0aIEUdZGL EshQQIsmHZa4zgiOX/RniCN8gFCKaxHIIJ9mEdgx48Gsu2abu46rvzZpeDIdqcW1To/Q L3Np0XVloNqvtD7GKyfbk8AW55zBTL0MTEBGCNfNKDV381yL05yABeBZp8dreCpBihbz kcugDiD6QuSOj9p5o2nwjXkIYsAmbtRubZCsJqAR0YTvklbO66b8VvETKF41xwAIxP4q HpVQ== X-Received: by 10.68.231.7 with SMTP id tc7mr19379844pbc.32.1401462406647; Fri, 30 May 2014 08:06:46 -0700 (PDT) Received: from billwin7 (amx-tls2.starhub.net.sg. [203.116.164.12]) by mx.google.com with ESMTPSA id pr4sm6864383pbb.53.2014.05.30.08.06.43 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 30 May 2014 08:06:46 -0700 (PDT) From: "bycn82" To: "'Julian Elischer'" , "'Luigi Rizzo'" , References: <201405291520.s4TFK124032925@freefall.freebsd.org> <007f01cf7b52$efd8a0c0$cf89e240$@gmail.com> <53889829.6030307@freebsd.org> In-Reply-To: <53889829.6030307@freebsd.org> Subject: RE: kern/189720: [ipfw] [patch] pps action for ipfw Date: Fri, 30 May 2014 23:06:43 +0800 Message-ID: <000001cf7c18$c6cbd460$54637d20$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHbWuE+qjuTx3is0SfKFp0zAb5aLAG3bGPqA4WkHDWbF46hwA== Content-Language: en-us X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 15:06:48 -0000 Hi , I am currently using HZ=3D2 in my testing environment, then the traffic = in dummynet by default delays for 500ms, the same reason for this PPS. = Because it is based on the TICK. How about introduce another option named PPT ? ( sounds familiar! ). and = in the ipfw_chk, PPS can just convert the duration from measurement = `milliseconds` to `ticks`, and can reuse the logic of PPT. PPT = technically is perfect. But for user, It is ugly. They need to know what = TICK is ! anyway, at least user have an option to choose when they = really need to be accurate. Regards, Bycn82 > -----Original Message----- > From: Julian Elischer [mailto:julian@freebsd.org] > Sent: 30 May, 2014 22:40 > To: bycn82; 'Luigi Rizzo'; freebsd-ipfw@FreeBSD.org > Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw >=20 > On 5/29/14, 11:30 PM, bycn82 wrote: > > I got it, > > > > if the HZ=3D3, it always cannot meet the " 1 packet per 500ms" = perfectly. > > But if we to "X packet per Y ticks", actually the result is the = same, still > cannot meet the "1 packet per 500 ms" perfectly, instead, the "packet = per Y > ticks" will force user to use " X packet per Y*300 ms". And the user = need to > understand how many millisecond each tick is . > on e can write an implementation that notes how much the calculation = was > off by for each tick and corrects the number for the next tick.. >=20 > e.g. with Hz=3D10, 8pps should give sometimes 1ppt and sometimes = 0ppt > but a simple calculation will always give 0 every tick so you need to = have > some way of carrying forward 'unused bandwidth' so that teh = calculation > looks like (over a second) > ppt(real) ppt(int) > 0.8 (0) > 0.8+0.8=3D1.6 (1) > 0.6+0.8=3D1.4 (1) (subtract 1 from 1.6, and then add the 0.8 per = tick) > 0.4+0.8=3D1.2 (1) > 0.2+0.8=3D1.0 (1) > 0.0+0.8=3D0.8(0) > (sequence repeats) > 0.8+0.8=3D1.6 (1) > 0.6+0.8=3D1.4 (1) > 0.4+0.8=3D1.2 (1) > 0.2+0.8=3D1.0 (1) > 0.0+0.8=3D0.8(0) >=20 > if you use any of the the int(ppt) in a tick you subtract the amount = used. if > not you allow it to build, up to some maximum value. >=20 > (sequence repeats) > 0.8+0.8=3D1.6 (1) (not used) > 1.6+0.8=3D2.4 (2) (not used) > 2.4+0.8=3D3.2 (3) (not used) > 3.2+0.8=3D4.0 (4) (4 packets allowed through further packets held or > dropped) > 0.0+0.8=3D0.8(0) > 0.8+0.8=3D1.6 (1) (not used) > 1.6+0.8=3D2.4 (2) (not used) > 2.4+0.8=3D3.2 (3) 1 packet used.. 1.0 subtracted > 2.2+0.8=3D3.0 (4) (4 packets allowed through further packets held or > dropped) > 0.0+0.8=3D0.8(0) > etc. >=20 > one does this with some form of fixed point arithmetic as floating = point isn't > used in the kernel. >=20 >=20 >=20 > > So I will update it this weekend. > > > > > >> -----Original Message----- > >> From: owner-freebsd-ipfw@freebsd.org [mailto:owner-freebsd- > >> ipfw@freebsd.org] On Behalf Of 'Luigi Rizzo' > >> Sent: 29 May, 2014 23:20 > >> To: freebsd-ipfw@FreeBSD.org > >> Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw > >> > >> The following reply was made to PR kern/189720; it has been noted = by > >> GNATS. > >> > >> From: 'Luigi Rizzo' > >> To: bycn82 > >> Cc: bug-followup@FreeBSD.org > >> Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw > >> Date: Thu, 29 May 2014 17:17:59 +0200 > >> > >> On Thu, May 29, 2014 at 11:06:27PM +0800, bycn82 wrote: > >> > > >> > > >> > -----Original Message----- > >> > From: Luigi Rizzo [mailto:rizzo@iet.unipi.it] > Sent: 29 May, = 2014 22:12 > > To: > >> bug-followup@FreeBSD.org; bycn82@gmail.com > Subject: kern/189720: > >> [ipfw] [patch] pps action for ipfw > > Hi, > I have looked at = the update > from > >> May 13th but it is not ready yet, the code assumes HZ=3D1000 so 1 = tick=3D1ms. > >> > > >> > The translation can be done in userspace or in the kernel. > >> > I would prefer the latter. > >> > I see, > >> > If the HZ=3D3, that means every tick=3D333ms > And if the user = wants to ??? > 1 > >> packet per 500ms???, then in the backend will not do the exactly = the > same as > >> what user expect. > >> > > >> > Actually the implementation should be ???packets per ticks???, = so how > >> about this? Instead of translate it in codes. Why not update the = document, > >> and explain it to the user in the document ? > >> > >> 'Packets per tick' this is not a useful specification since the = tick's duration > is > >> unknown to the user. > >> Depending on the platform you can have HZ ranging from 15-20 (on > windows) > >> to 10000 or even more. Normal values are 100, 250, 1000 but you = just > cannot > >> know what you are going to get. > >> > >> Yes there are rounding issues, and yes it is boring to write = code to > handle > >> them. > >> > >> luigi > >> _______________________________________________ > >> freebsd-ipfw@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > >> To unsubscribe, send any mail to "freebsd-ipfw- > unsubscribe@freebsd.org" > > _______________________________________________ > > freebsd-ipfw@freebsd.org mailing list > > http://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 30 17:00:01 2014 Return-Path: Delivered-To: freebsd-ipfw@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B1028D4 for ; Fri, 30 May 2014 17:00:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 38EE82A7B for ; Fri, 30 May 2014 17:00:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4UH016R031306 for ; Fri, 30 May 2014 17:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4UH00sv031305; Fri, 30 May 2014 17:00:00 GMT (envelope-from gnats) Date: Fri, 30 May 2014 17:00:00 GMT Message-Id: <201405301700.s4UH00sv031305@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org Cc: From: "bycn82" Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw Reply-To: "bycn82" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 17:00:01 -0000 The following reply was made to PR kern/189720; it has been noted by GNATS. From: "bycn82" To: , Cc: "Luigi Rizzo" Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw Date: Sat, 31 May 2014 00:53:56 +0800 This is a multipart message in MIME format. ------=_NextPart_000_0002_01CF7C6A.CF4B9B50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0003_01CF7C6A.CF4B9B50" ------=_NextPart_001_0003_01CF7C6A.CF4B9B50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 1. Add static int to store the value of kern.hz 2. Convert the duration into number of ticks based on kern.hz regards, bycn82 ------=_NextPart_001_0003_01CF7C6A.CF4B9B50 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

1.       Add = static int to store the value of kern.hz

2.       = Convert the duration into number of ticks based = on =C2=A0kern.hz

 

regards,

bycn82

------=_NextPart_001_0003_01CF7C6A.CF4B9B50-- ------=_NextPart_000_0002_01CF7C6A.CF4B9B50 Content-Type: application/octet-stream; name="pps.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pps.patch" Index: sbin/ipfw/ipfw.8=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- sbin/ipfw/ipfw.8 (revision 266886)=0A= +++ sbin/ipfw/ipfw.8 (working copy)=0A= @@ -602,6 +602,14 @@=0A= Note: logging is done after all other packet matching conditions=0A= have been successfully verified, and before performing the final=0A= action (accept, deny, etc.) on the packet.=0A= +.It Cm pps Ar limit duration=0A= +Rule with the =0A= +.Cm pps=0A= +keyword will allow the first=0A= +.Ar limit=0A= +packets in recent =0A= +.Ar duration =0A= +milliseconds=0A= .It Cm tag Ar number=0A= When a packet matches a rule with the=0A= .Cm tag=0A= Index: sbin/ipfw/ipfw2.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- sbin/ipfw/ipfw2.c (revision 266886)=0A= +++ sbin/ipfw/ipfw2.c (working copy)=0A= @@ -244,6 +244,7 @@=0A= { "allow", TOK_ACCEPT },=0A= { "permit", TOK_ACCEPT },=0A= { "count", TOK_COUNT },=0A= + { "pps", TOK_PPS },=0A= { "pipe", TOK_PIPE },=0A= { "queue", TOK_QUEUE },=0A= { "divert", TOK_DIVERT },=0A= @@ -1232,6 +1233,13 @@=0A= PRINT_UINT_ARG("skipto ", cmd->arg1);=0A= break;=0A= =0A= + case O_PPS:=0A= + {=0A= + ipfw_insn_pps *pps=3D(ipfw_insn_pps *)cmd;=0A= + printf("pps %d %d",cmd->arg1,pps->duration);=0A= + break; =0A= + }=0A= +=0A= case O_PIPE:=0A= PRINT_UINT_ARG("pipe ", cmd->arg1);=0A= break;=0A= @@ -2985,6 +2993,24 @@=0A= case TOK_COUNT:=0A= action->opcode =3D O_COUNT;=0A= break;=0A= + =0A= + case TOK_PPS:=0A= + action->opcode =3D O_PPS;=0A= + ipfw_insn_pps *p =3D (ipfw_insn_pps *)action;=0A= + action->len =3D F_INSN_SIZE(ipfw_insn_pps);=0A= + if (isdigit(**av)) {=0A= + action->arg1 =3D strtoul(*av, NULL, 10);=0A= + av++;=0A= + }else{=0A= + errx(EX_USAGE, "illegal argument pps `limit` %s", *av);=0A= + }=0A= + if (isdigit(**av)) {=0A= + p->duration =3D strtoul(*av, NULL, 10);=0A= + av++;=0A= + }else{=0A= + errx(EX_USAGE,"illegal arugment pps `duration` %s", *av);=0A= + }=0A= + break; =0A= =0A= case TOK_NAT:=0A= action->opcode =3D O_NAT;=0A= Index: sbin/ipfw/ipfw2.h=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- sbin/ipfw/ipfw2.h (revision 266886)=0A= +++ sbin/ipfw/ipfw2.h (working copy)=0A= @@ -92,6 +92,7 @@=0A= TOK_NGTEE,=0A= TOK_FORWARD,=0A= TOK_SKIPTO,=0A= + TOK_PPS,=0A= TOK_DENY,=0A= TOK_REJECT,=0A= TOK_RESET,=0A= Index: sys/netinet/ip_fw.h=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- sys/netinet/ip_fw.h (revision 266886)=0A= +++ sys/netinet/ip_fw.h (working copy)=0A= @@ -165,6 +165,7 @@=0A= O_REJECT, /* arg1=3Dicmp arg (same as deny) */=0A= O_COUNT, /* none */=0A= O_SKIPTO, /* arg1=3Dnext rule number */=0A= + O_PPS, /* arg1=3Dlimit, pps->duration */=0A= O_PIPE, /* arg1=3Dpipe number */=0A= O_QUEUE, /* arg1=3Dqueue number */=0A= O_DIVERT, /* arg1=3Dport number */=0A= @@ -378,6 +379,16 @@=0A= } ipfw_insn_log;=0A= =0A= /*=0A= + * This is used for PPS=0A= + */=0A= +typedef struct _ipfw_insn_pps{=0A= + ipfw_insn o;=0A= + uint32_t start_time;=0A= + uint32_t count;=0A= + uint32_t duration;=0A= +} ipfw_insn_pps;=0A= +=0A= +/*=0A= * Data structures required by both ipfw(8) and ipfw(4) but not part of = the=0A= * management API are protected by IPFW_INTERNAL.=0A= */=0A= Index: sys/netpfil/ipfw/ip_fw2.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- sys/netpfil/ipfw/ip_fw2.c (revision 266886)=0A= +++ sys/netpfil/ipfw/ip_fw2.c (working copy)=0A= @@ -124,6 +124,7 @@=0A= /* Use 128 tables by default */=0A= static unsigned int default_fw_tables =3D IPFW_TABLES_DEFAULT;=0A= =0A= +static unsigned int kern_hz=3D1000;=0A= /*=0A= * Each rule belongs to one of 32 different sets (0..31).=0A= * The variable set_disable contains one bit per set.=0A= @@ -186,6 +187,7 @@=0A= SYSCTL_VNET_INT(_net_inet_ip_fw, OID_AUTO, static_count,=0A= CTLFLAG_RD, &VNET_NAME(layer3_chain.n_rules), 0,=0A= "Number of static rules");=0A= +TUNABLE_INT("kern.hz", (int *)&kern_hz);=0A= =0A= #ifdef INET6=0A= SYSCTL_DECL(_net_inet6_ip6);=0A= @@ -2189,6 +2191,31 @@=0A= continue;=0A= break; /* not reached */=0A= =0A= + case O_PPS:{=0A= + int duration_in_ticks;=0A= + ipfw_insn_pps *pps =3D (ipfw_insn_pps *)cmd;=0A= + if(1000/kern_hz >=3D pps->duration){=0A= + duration_in_ticks=3D1;=0A= + }else{=0A= + duration_in_ticks=3Dpps->duration*kern_hz/1000+1;=0A= + }=0A= + if(pps->start_time+duration_in_ticks>=3D ticks){=0A= + if(pps->count < cmd->arg1){=0A= + retval =3D IP_FW_PASS;=0A= + }else{=0A= + retval =3D IP_FW_DENY;=0A= + }=0A= + pps->count++;=0A= + }else{=0A= + pps->start_time=3Dticks;=0A= + pps->count=3D1;=0A= + retval =3D IP_FW_PASS;=0A= + }=0A= + l =3D 0; =0A= + done =3D 1;=0A= + break; =0A= + }=0A= +=0A= case O_CALLRETURN: {=0A= /*=0A= * Implementation of `subroutine' call/return,=0A= Index: sys/netpfil/ipfw/ip_fw_sockopt.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- sys/netpfil/ipfw/ip_fw_sockopt.c (revision 266886)=0A= +++ sys/netpfil/ipfw/ip_fw_sockopt.c (working copy)=0A= @@ -703,6 +703,12 @@=0A= goto bad_size;=0A= break;=0A= =0A= + case O_PPS:=0A= + have_action=3D1;=0A= + if (cmdlen !=3D F_INSN_SIZE(ipfw_insn_pps))=0A= + goto bad_size;=0A= + break;=0A= +=0A= case O_PIPE:=0A= case O_QUEUE:=0A= if (cmdlen !=3D F_INSN_SIZE(ipfw_insn))=0A= ------=_NextPart_000_0002_01CF7C6A.CF4B9B50-- From owner-freebsd-ipfw@FreeBSD.ORG Fri May 30 17:20:06 2014 Return-Path: Delivered-To: freebsd-ipfw@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8888A336 for ; Fri, 30 May 2014 17:20:06 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 6B9F02C6A for ; Fri, 30 May 2014 17:20:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4UHK5wV039853 for ; Fri, 30 May 2014 17:20:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4UHK5ES039852; Fri, 30 May 2014 17:20:05 GMT (envelope-from gnats) Date: Fri, 30 May 2014 17:20:05 GMT Message-Id: <201405301720.s4UHK5ES039852@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org Cc: From: Luigi Rizzo Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw Reply-To: Luigi Rizzo X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 17:20:06 -0000 The following reply was made to PR kern/189720; it has been noted by GNATS. From: Luigi Rizzo To: bycn82 Cc: bug-followup@FreeBSD.org Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw Date: Fri, 30 May 2014 19:16:10 +0200 On Sat, May 31, 2014 at 12:53:56AM +0800, bycn82 wrote: > 1. Add static int to store the value of kern.hz this is unnecessary. There is already a global variable called "hz" which contains the correct information > 2. Convert the duration into number of ticks based on kern.hz this is done incorrectly. First, hz does not change at runtime so it is unnecessary to recompute the duration on every instace, even more since this is costing you one division. You should adjust the value when the rule is injected in the kernel, perhaps adding a couple of fields in the rule so you can store the adjusted duration and threshold (see below). Second, you are still not doing the rounding correctly. When the requested interval is shorter than a tick, you adjust the interval but leave the limit unchanged, which means you are reducing the limit below what the user wants. Instead you should correct the limit so that it approximates the desired rate; one above or one below is not a problem, but your code might be off by a very large factor. BTW even in the other case you are always adding 1 tick unconditionally. A correct way to do the rounding is (pps->duration * hz + 999)/1000 (and then again adjust the count according to the actual duration) cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Sat May 31 03:12:48 2014 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8672F4C9 for ; Sat, 31 May 2014 03:12:48 +0000 (UTC) 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 506F82B4B for ; Sat, 31 May 2014 03:12:47 +0000 (UTC) Received: from jre-mbp.elischer.org (etroy.elischer.org [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s4V3CfiQ072620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 30 May 2014 20:12:44 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <538948A5.2050003@freebsd.org> Date: Sat, 31 May 2014 11:12:37 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: bycn82 , "'Luigi Rizzo'" , freebsd-ipfw@FreeBSD.org Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw References: <201405291520.s4TFK124032925@freefall.freebsd.org> <007f01cf7b52$efd8a0c0$cf89e240$@gmail.com> <53889829.6030307@freebsd.org> <000001cf7c18$c6cbd460$54637d20$@gmail.com> In-Reply-To: <000001cf7c18$c6cbd460$54637d20$@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 03:12:48 -0000 On 5/30/14, 11:06 PM, bycn82 wrote: > Hi , > I am currently using HZ=2 in my testing environment, then the traffic in dummynet by default delays for 500ms, the same reason for this PPS. Because it is based on the TICK. > > How about introduce another option named PPT ? ( sounds familiar! ). and in the ipfw_chk, PPS can just convert the duration from measurement `milliseconds` to `ticks`, and can reuse the logic of PPT. PPT technically is perfect. But for user, It is ugly. They need to know what TICK is ! anyway, at least user have an option to choose when they really need to be accurate. the user parameter needs to be pps.. you need to convert in internally to a fixedpoint representation of PPT. > > Regards, > Bycn82 > >> -----Original Message----- >> From: Julian Elischer [mailto:julian@freebsd.org] >> Sent: 30 May, 2014 22:40 >> To: bycn82; 'Luigi Rizzo'; freebsd-ipfw@FreeBSD.org >> Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw >> >> On 5/29/14, 11:30 PM, bycn82 wrote: >>> I got it, >>> >>> if the HZ=3, it always cannot meet the " 1 packet per 500ms" perfectly. >>> But if we to "X packet per Y ticks", actually the result is the same, still >> cannot meet the "1 packet per 500 ms" perfectly, instead, the "packet per Y >> ticks" will force user to use " X packet per Y*300 ms". And the user need to >> understand how many millisecond each tick is . >> on e can write an implementation that notes how much the calculation was >> off by for each tick and corrects the number for the next tick.. >> >> e.g. with Hz=10, 8pps should give sometimes 1ppt and sometimes 0ppt >> but a simple calculation will always give 0 every tick so you need to have >> some way of carrying forward 'unused bandwidth' so that teh calculation >> looks like (over a second) >> ppt(real) ppt(int) >> 0.8 (0) >> 0.8+0.8=1.6 (1) >> 0.6+0.8=1.4 (1) (subtract 1 from 1.6, and then add the 0.8 per tick) >> 0.4+0.8=1.2 (1) >> 0.2+0.8=1.0 (1) >> 0.0+0.8=0.8(0) >> (sequence repeats) >> 0.8+0.8=1.6 (1) >> 0.6+0.8=1.4 (1) >> 0.4+0.8=1.2 (1) >> 0.2+0.8=1.0 (1) >> 0.0+0.8=0.8(0) >> >> if you use any of the the int(ppt) in a tick you subtract the amount used. if >> not you allow it to build, up to some maximum value. >> >> (sequence repeats) >> 0.8+0.8=1.6 (1) (not used) >> 1.6+0.8=2.4 (2) (not used) >> 2.4+0.8=3.2 (3) (not used) >> 3.2+0.8=4.0 (4) (4 packets allowed through further packets held or >> dropped) >> 0.0+0.8=0.8(0) >> 0.8+0.8=1.6 (1) (not used) >> 1.6+0.8=2.4 (2) (not used) >> 2.4+0.8=3.2 (3) 1 packet used.. 1.0 subtracted >> 2.2+0.8=3.0 (4) (4 packets allowed through further packets held or >> dropped) >> 0.0+0.8=0.8(0) >> etc. >> >> one does this with some form of fixed point arithmetic as floating point isn't >> used in the kernel. >> >> >> >>> So I will update it this weekend. >>> >>> >>>> -----Original Message----- >>>> From: owner-freebsd-ipfw@freebsd.org [mailto:owner-freebsd- >>>> ipfw@freebsd.org] On Behalf Of 'Luigi Rizzo' >>>> Sent: 29 May, 2014 23:20 >>>> To: freebsd-ipfw@FreeBSD.org >>>> Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw >>>> >>>> The following reply was made to PR kern/189720; it has been noted by >>>> GNATS. >>>> >>>> From: 'Luigi Rizzo' >>>> To: bycn82 >>>> Cc: bug-followup@FreeBSD.org >>>> Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw >>>> Date: Thu, 29 May 2014 17:17:59 +0200 >>>> >>>> On Thu, May 29, 2014 at 11:06:27PM +0800, bycn82 wrote: >>>> > >>>> > >>>> > -----Original Message----- >>>> > From: Luigi Rizzo [mailto:rizzo@iet.unipi.it] > Sent: 29 May, 2014 22:12 > >> To: >>>> bug-followup@FreeBSD.org; bycn82@gmail.com > Subject: kern/189720: >>>> [ipfw] [patch] pps action for ipfw > > Hi, > I have looked at the update >> from >>>> May 13th but it is not ready yet, the code assumes HZ=1000 so 1 tick=1ms. >>>> > >>>> > The translation can be done in userspace or in the kernel. >>>> > I would prefer the latter. >>>> > I see, >>>> > If the HZ=3, that means every tick=333ms > And if the user wants to ??? >> 1 >>>> packet per 500ms???, then in the backend will not do the exactly the >> same as >>>> what user expect. >>>> > >>>> > Actually the implementation should be ???packets per ticks???, so how >>>> about this? Instead of translate it in codes. Why not update the document, >>>> and explain it to the user in the document ? >>>> >>>> 'Packets per tick' this is not a useful specification since the tick's duration >> is >>>> unknown to the user. >>>> Depending on the platform you can have HZ ranging from 15-20 (on >> windows) >>>> to 10000 or even more. Normal values are 100, 250, 1000 but you just >> cannot >>>> know what you are going to get. >>>> >>>> Yes there are rounding issues, and yes it is boring to write code to >> handle >>>> them. >>>> >>>> luigi >>>> _______________________________________________ >>>> freebsd-ipfw@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >>>> To unsubscribe, send any mail to "freebsd-ipfw- >> unsubscribe@freebsd.org" >>> _______________________________________________ >>> freebsd-ipfw@freebsd.org mailing list >>> http://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 31 05:11:56 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10339872 for ; Sat, 31 May 2014 05:11:56 +0000 (UTC) Received: from nskntmtas01p.mx.bigpond.com (nskntmtas01p.mx.bigpond.com [61.9.168.137]) by mx1.freebsd.org (Postfix) with ESMTP id 9BF0F2462 for ; Sat, 31 May 2014 05:11:54 +0000 (UTC) Received: from nskntcmgw08p ([61.9.169.168]) by nskntmtas01p.mx.bigpond.com with ESMTP id <20140531051148.TVVC1388.nskntmtas01p.mx.bigpond.com@nskntcmgw08p> for ; Sat, 31 May 2014 05:11:48 +0000 Received: from hermes.heuristicsystems.com.au ([121.210.107.100]) by nskntcmgw08p with BigPond Outbound id 8VBn1o00X29zwdD01VBnsV; Sat, 31 May 2014 05:11:48 +0000 X-Authority-Analysis: v=2.0 cv=D6DF24tj c=1 sm=1 a=SEJ2iDwVkb98DYvesvueMw==:17 a=JipEcVzqA9wA:10 a=bK2Sv-scXf0A:10 a=8nJEP1OIZ-IA:10 a=GHIR_BbyAAAA:8 a=OZcsjUhxKMhyTeOwdK0A:9 a=wPNLvfGTeEIA:10 a=n-xIW37-i4wA:10 a=ndIsBwZ8hT0A:10 a=SEJ2iDwVkb98DYvesvueMw==:117 Received: from [10.0.5.3] (ewsw01.hs [10.0.5.3]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id s4V5Ag5T058298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 31 May 2014 15:10:44 +1000 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Message-ID: <53896452.20904@heuristicsystems.com.au> Date: Sat, 31 May 2014 15:10:42 +1000 From: Dewayne Geraghty User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw References: <201405291520.s4TFK124032925@freefall.freebsd.org> <007f01cf7b52$efd8a0c0$cf89e240$@gmail.com> <53889829.6030307@freebsd.org> <000001cf7c18$c6cbd460$54637d20$@gmail.com> <538948A5.2050003@freebsd.org> In-Reply-To: <538948A5.2050003@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 05:11:56 -0000 What is the "use case" of this addition? Is this objective to limit the mischief on a certain port, for example ntp or port 53? I can appreciate the need to limit the number of packets during, say a DDOS event, but I'm struggling with why I would want less that 1 packet per second. Is the idea of pps meant to remove the need of dummynet where it is used in almost trivial cases? Though if this were the case, then bps (bits per second) may be more useful? Dewayne. From owner-freebsd-ipfw@FreeBSD.ORG Sat May 31 09:07:01 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9F5037A for ; Sat, 31 May 2014 09:07:01 +0000 (UTC) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (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 90EAF262F for ; Sat, 31 May 2014 09:07:01 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id v10so1761290pde.4 for ; Sat, 31 May 2014 02:07:01 -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 :content-transfer-encoding:thread-index:content-language; bh=fIMBMUiA/QI53LyzpKqgexp22lGNw6tZu3MwlVgv+zg=; b=Okd1bEwphiPinL7LMDP92sIGfyAvaEb+FAilDnK/8ESorfOf146UiObMhbbtG+oKE2 WkuWJ2Oqt+swfcaRmgOb7+m26cC5zi+6+zOHUocVv+dB9R/PNAID3zxDtTBacDax2UMs JxaYhndJcLrUVwWmWSMxf1+bJucKv99NaSPNFrifvbKEPTZoOS0WUmqWz0aJfIik2Ewr 8dFQEo4lsyhGQdNFdpYa0AeLXR1KPZJJwYsVV02HswtKwz9eE/5ayMbxZ5oL2d5LPov5 vTlY2Y/tLoSxaPhsugLPN/FcMUutdUcs6F9QMM7hzfZaNS0P0UcH4AfeW5dFNM1so5D4 r5dA== X-Received: by 10.69.19.140 with SMTP id gu12mr24892808pbd.111.1401527221207; Sat, 31 May 2014 02:07:01 -0700 (PDT) Received: from billwin7 (amx-tls2.starhub.net.sg. [203.116.164.12]) by mx.google.com with ESMTPSA id se3sm10239390pbb.80.2014.05.31.02.06.59 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 31 May 2014 02:07:00 -0700 (PDT) From: "bycn82" To: "'Dewayne Geraghty'" , Subject: RE: kern/189720: [ipfw] [patch] pps action for ipfw Date: Sat, 31 May 2014 17:06:58 +0800 Message-ID: <000001cf7caf$afca3760$0f5ea620$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac98r6wq2UftofCrRPeSuRfDzEoG8A== Content-Language: en-us X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 09:07:01 -0000 >=20 > What is the "use case" of this addition? Is this objective to limit = the mischief > on a certain port, for example ntp or port 53? >=20 > I can appreciate the need to limit the number of packets during, say a = DDOS > event, but I'm struggling with why I would want less that 1 packet per = second. >=20 The original propose is "packet per second", I met this kind of = requirement , for example ,if you network appliance want to support 10 = queries per second, then you cannot use dummynet because the query = packets are not fixed size. > Is the idea of pps meant to remove the need of dummynet where it is = used > in almost trivial cases? Though if this were the case, then bps (bits = per > second) may be more useful? >=20 So in the beginning , the option is named =E2=80=9CPPS=E2=80=9D, and it = accepts only 1 parameter. But Luigi said =E2=80=9C10 per = second=E2=80=9D is different from =E2=80=9C1 per 100 ms=E2=80=9D and = =E2=80=9C1 per 100 ms=E2=80=9D should be better! =20 > Dewayne. >=20 From owner-freebsd-ipfw@FreeBSD.ORG Mon Jun 2 23:38:53 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5D9019D for ; Mon, 2 Jun 2014 23:38:53 +0000 (UTC) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (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 8AD3E2146 for ; Mon, 2 Jun 2014 23:38:53 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id kx10so2436176pab.38 for ; Mon, 02 Jun 2014 16:38:53 -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=vM2R41DuUr4nPHnHU3i0zUOQLt3avUpUP7+ovx2CAu0=; b=lHatSyX+xGi8Qu2/A5MBgo9QQfvQrWbPhrBU2tHbRzlEIoCdhmk/ZaG2UrTklTZKOs EgOqRtC03T01l6puN72KcN0K1TmR8gvooCGCUzAFmeoae3psFvwSyMpH1ouAENRcEq20 8Onec5mD3+I1iyGeVEQwpoGiCDmCPI2jbUmCg9voUla6xw2BXccFBbhJApQjLowp8fvU cQgF5cAM1iUSG5CXLGbbUoYKoBDV6P/NTjectpFMDEspJEr6xjxnMmaH49yUJpDvpvD0 jtPmsTOQPqNN7YcinHHA0qhvLiUyWKZXCtSu0i0/DdT7V30uB+zktmiDAC3zhtpLhn/M 2aQA== X-Received: by 10.66.216.197 with SMTP id os5mr12440618pac.29.1401752333123; Mon, 02 Jun 2014 16:38:53 -0700 (PDT) Received: from billwin7 (amx-tls2.starhub.net.sg. [203.116.164.12]) by mx.google.com with ESMTPSA id ei4sm22341440pbb.42.2014.06.02.16.38.50 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 02 Jun 2014 16:38:52 -0700 (PDT) From: "bycn82" To: Subject: build error Date: Tue, 3 Jun 2014 07:38:47 +0800 Message-ID: <003301cf7ebb$cedae5b0$6c90b110$@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac9+u8QQmy7GBXo9RFaYdw6p8BuLdg== Content-Language: en-us Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 23:38:53 -0000 root@FB10Head:/usr/src/sbin/ipfw # make cc -O2 -pipe -DPF -std=3Dgnu99 -fstack-protector -Wsystem-headers = -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign = -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare = -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function = -Wno-enum-conversion -Wno-switch -Wno-switch-enum = -Wno-knr-promoted-parameter -Qunused-arguments -c = /usr/src/sbin/ipfw/ipfw2.c cc -O2 -pipe -DPF -std=3Dgnu99 -fstack-protector -Wsystem-headers = -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign = -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare = -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function = -Wno-enum-conversion -Wno-switch -Wno-switch-enum = -Wno-knr-promoted-parameter -Qunused-arguments -c = /usr/src/sbin/ipfw/dummynet.c /usr/src/sbin/ipfw/dummynet.c:251:19: error: use of undeclared = identifier 'DN_IS_ECN'; did you mean 'DN_IS_RED'? if (fs->flags & DN_IS_ECN) ^~~~~~~~~ DN_IS_RED /usr/include/netinet/ip_dummynet.h:105:2: note: 'DN_IS_RED' declared = here DN_IS_RED =3D 0x0020, ^ /usr/src/sbin/ipfw/dummynet.c:1060:17: error: use of undeclared = identifier 'DN_IS_ECN'; did you mean 'DN_IS_RED'? fs->flags |=3D DN_IS_ECN; ^~~~~~~~~ DN_IS_RED /usr/include/netinet/ip_dummynet.h:105:2: note: 'DN_IS_RED' declared = here DN_IS_RED =3D 0x0020, ^ /usr/src/sbin/ipfw/dummynet.c:1185:23: error: use of undeclared = identifier 'DN_IS_ECN'; did you mean 'DN_IS_RED'? if ((fs->flags & DN_IS_ECN) && !(fs->flags & DN_IS_RED)) ^~~~~~~~~ DN_IS_RED /usr/include/netinet/ip_dummynet.h:105:2: note: 'DN_IS_RED' declared = here DN_IS_RED =3D 0x0020, ^ /usr/src/sbin/ipfw/dummynet.c:1192:21: error: use of undeclared = identifier 'DN_IS_ECN'; did you mean 'DN_IS_RED'? if (!(fs->flags & DN_IS_ECN) && (fs->min_th >=3D = fs->max_th)) ^~~~~~~~~ DN_IS_RED /usr/include/netinet/ip_dummynet.h:105:2: note: 'DN_IS_RED' declared = here DN_IS_RED =3D 0x0020, ^ /usr/src/sbin/ipfw/dummynet.c:1195:25: error: use of undeclared = identifier 'DN_IS_ECN'; did you mean 'DN_IS_RED'? else if ((fs->flags & DN_IS_ECN) && (fs->min_th > = fs->max_th)) ^~~~~~~~~ DN_IS_RED /usr/include/netinet/ip_dummynet.h:105:2: note: 'DN_IS_RED' declared = here DN_IS_RED =3D 0x0020, ^ 5 errors generated. *** Error code 1 =20 Stop. make: stopped in /usr/src/sbin/ipfw From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 11 08:57:16 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E4F834E5 for ; Wed, 11 Jun 2014 08:57:16 +0000 (UTC) Received: from nskntmtas04p.mx.bigpond.com (nskntmtas04p.mx.bigpond.com [61.9.168.146]) by mx1.freebsd.org (Postfix) with ESMTP id 8125D2C1D for ; Wed, 11 Jun 2014 08:57:15 +0000 (UTC) Received: from nskntcmgw08p ([61.9.169.168]) by nskntmtas04p.mx.bigpond.com with ESMTP id <20140611085707.OXRT17495.nskntmtas04p.mx.bigpond.com@nskntcmgw08p> for ; Wed, 11 Jun 2014 08:57:07 +0000 Received: from hermes.heuristicsystems.com.au ([121.210.107.100]) by nskntcmgw08p with BigPond Outbound id Cwx71o00k29zwdD01wx7MW; Wed, 11 Jun 2014 08:57:07 +0000 X-Authority-Analysis: v=2.0 cv=D6DF24tj c=1 sm=1 a=SEJ2iDwVkb98DYvesvueMw==:17 a=JipEcVzqA9wA:10 a=cFF2DyTvjdYA:10 a=8nJEP1OIZ-IA:10 a=GHIR_BbyAAAA:8 a=KhxctUoNAAAA:8 a=6I5d2MoRAAAA:8 a=MhBVioSXAAAA:8 a=GunzGQb5unaUq8hC5H8A:9 a=wPNLvfGTeEIA:10 a=T3ueIcVnjJEA:10 a=SEJ2iDwVkb98DYvesvueMw==:117 Received: from [10.0.5.3] (ewsw01.hs [10.0.5.3]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id s5B8t8uQ044384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 11 Jun 2014 18:55:09 +1000 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Message-ID: <5398196B.6070209@heuristicsystems.com.au> Date: Wed, 11 Jun 2014 18:55:07 +1000 From: Dewayne Geraghty User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Subject: Version of pf & Any impact to FreeBSD re ALTQ removal from OpenBSD 5.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 08:57:17 -0000 Two questions: 1. With this announcement http://undeadly.org/cgi?action=article&sid=20140419151959 by the OpenBSD project concerning their dropping of ALTQ for their new bandwidth and priority mechanism, can anyone share/advise what impact, if any, this will this have for ALTQ and hence pf on FreeBSD. Will we remain with ALTQ for the next few years? After 11 years with ipfw, nat and dummynet I'm considering migrating to pf, primarily for its nat with keep-state and QOS via ALTQ-CBQ capabilities. This all started with the tribulation of enabling ftp in anything like a stateful manner. Is there any plan to track the changes that OpenBSD is taking, or for that matter is there a need to take advantage of their experience in queuing/prioritisation in the foreseeable future (say 3 years)? I suspect that it will be a major task to replace ALTQ. 2. Also could someone advise which version of pf we have from OpenBSD in FreeBSD 10 Stable. From the svn logs (ref 1) it appears that pf was last imported from OpenBSD at 4.6 and a lot of updates and changes have been applied. The Copyright notice in pf.c on FreeBSD10 Stable is dated 2012, while __FBSDID("$FreeBSD: stable/10/sys/netpfil/pf/pf.c 265008 2014-04-27 09:05:34Z mm $"). >From 9.2-Beta2 __FBSDID("$FreeBSD: stable/9/sys/contrib/pf/net/pf.c 243401 2012-11-22 12:11:32Z glebius $"); There is quite a lot of documentation on pf, but it is often unclear which version I should hang my hat on. And as a newbie to pf, well - its a challenge. Ref: 1) http://svnweb.freebsd.org/base/stable/10/sys/netpfil/pf/pf.c?sortby=date&view=log [2 years, 11 months ago Update to pf from OpenBSD 4.5. Though a lot of changes have occurred since then]. 2) http://home.nuug.no/~peter/pf/newest/post47.html Regards, Dewayne