From owner-freebsd-ipfw@FreeBSD.ORG Mon Aug 17 11:06:57 2009 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCC8B10656AA for ; Mon, 17 Aug 2009 11:06:57 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AA4838FC6F for ; Mon, 17 Aug 2009 11:06:57 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7HB6vv1075840 for ; Mon, 17 Aug 2009 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7HB6vsI075836 for freebsd-ipfw@FreeBSD.org; Mon, 17 Aug 2009 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Aug 2009 11:06:57 GMT Message-Id: <200908171106.n7HB6vsI075836@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 Cc: Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 11:06:57 -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/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/136695 ipfw [ipfw] [patch] fwd reached after skipto in dynamic rul o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file. o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o 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/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a 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/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent 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 62 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Aug 17 15:01:16 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C185B1065690 for ; Mon, 17 Aug 2009 15:01:16 +0000 (UTC) (envelope-from mike@magicislandtechnologies.com) Received: from mail.magicislandtechnologies.com (mail.magicislandtechnologies.com [74.208.96.3]) by mx1.freebsd.org (Postfix) with ESMTP id 686668FC75 for ; Mon, 17 Aug 2009 15:01:16 +0000 (UTC) Received: (qmail 4721 invoked from network); 17 Aug 2009 19:27:19 +0400 Received: from unknown (HELO mork.mitglobalnet.net) (mike@217.194.139.22) by mail.magicislandtechnologies.com with SMTP; 17 Aug 2009 19:27:18 +0400 Message-ID: <4A8969FF.2070601@magicislandtechnologies.com> Date: Mon, 17 Aug 2009 18:32:31 +0400 From: Michael Spratt Organization: Magic Island Technologies User-Agent: Thunderbird 2.0.0.6 (X11/20070818) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: out xmit (demux) pipe bw accounting X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mike@magicislandtechnologies.com List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 15:01:16 -0000 Could not find answer to following question. Given : # pipe 1 config bw 1Mbit/sec # ipfw 1000 add pipe 1 ip from any to any out xmit em0 Will the bandwidth limit include layer 2 Ethernet headers or will only the IP datagram itself be included in the accounting mechanism? Total output on the em0 at layer 2 is limited to 1Mbit/s or IP going out em0 layer 3 will be limited to 1Mbit/s -- -------------------------------------------------- Mike Spratt - Iraq (GMT+3) Office: (214)242-1782 DSN: (318)847-2983 Cell: +964-770-398-4366 mike@magicislandtechnologies.com --------------------------------------------------- From owner-freebsd-ipfw@FreeBSD.ORG Mon Aug 17 17:25:35 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 357361065696 for ; Mon, 17 Aug 2009 17:25:35 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout011.mac.com (asmtpout011.mac.com [17.148.16.86]) by mx1.freebsd.org (Postfix) with ESMTP id 232928FC55 for ; Mon, 17 Aug 2009 17:25:34 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from cswiger1.apple.com ([17.227.140.124]) by asmtp011.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KOJ0072R728EB10@asmtp011.mac.com> for freebsd-ipfw@freebsd.org; Mon, 17 Aug 2009 10:25:33 -0700 (PDT) Message-id: From: Chuck Swiger To: mike@magicislandtechnologies.com In-reply-to: <4A8969FF.2070601@magicislandtechnologies.com> Date: Mon, 17 Aug 2009 10:25:20 -0700 References: <4A8969FF.2070601@magicislandtechnologies.com> X-Mailer: Apple Mail (2.936) Cc: freebsd-ipfw@freebsd.org Subject: Re: out xmit (demux) pipe bw accounting X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 17:25:35 -0000 Hi-- On Aug 17, 2009, at 7:32 AM, Michael Spratt wrote: > Could not find answer to following question. > > Given : > # pipe 1 config bw 1Mbit/sec > # ipfw 1000 add pipe 1 ip from any to any out xmit em0 > > Will the bandwidth limit include layer 2 Ethernet headers or will > only the IP datagram itself be included in the accounting mechanism? IPFW normally processes traffic at layer-3, but you can toggle net.link.ether.ipfw sysctl to on, in which case the above rule would also be run against layer-2 packets including the 802.3 ethernet header. See the diagram in "PACKET FLOW" of "man ipfw".... Regards, -- -Chuck From owner-freebsd-ipfw@FreeBSD.ORG Wed Aug 19 09:11:27 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 569D1106568C for ; Wed, 19 Aug 2009 09:11:27 +0000 (UTC) (envelope-from mike@magicislandtechnologies.com) Received: from mail.magicislandtechnologies.com (mail.magicislandtechnologies.com [74.208.96.3]) by mx1.freebsd.org (Postfix) with ESMTP id 138AC8FC3F for ; Wed, 19 Aug 2009 09:11:26 +0000 (UTC) Received: (qmail 21414 invoked from network); 19 Aug 2009 14:04:10 +0400 Received: from unknown (HELO mork.mitglobalnet.net) (mike@217.194.139.22) by mail.magicislandtechnologies.com with SMTP; 19 Aug 2009 14:04:08 +0400 Message-ID: <4A8BC140.8050203@magicislandtechnologies.com> Date: Wed, 19 Aug 2009 13:09:20 +0400 From: Michael Spratt Organization: Magic Island Technologies User-Agent: Thunderbird 2.0.0.6 (X11/20070818) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org References: <4A8969FF.2070601@magicislandtechnologies.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rizzo@icir.org Subject: Re: out xmit (demux) pipe bw accounting X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mike@magicislandtechnologies.com List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 09:11:27 -0000 Chuck Swiger wrote: > Hi-- > > On Aug 17, 2009, at 7:32 AM, Michael Spratt wrote: >> Could not find answer to following question. >> >> Given : >> # pipe 1 config bw 1Mbit/sec >> # ipfw 1000 add pipe 1 ip from any to any out xmit em0 >> >> Will the bandwidth limit include layer 2 Ethernet headers or will only >> the IP datagram itself be included in the accounting mechanism? > > IPFW normally processes traffic at layer-3, but you can toggle > net.link.ether.ipfw sysctl to on, in which case the above rule would > also be run against layer-2 packets including the 802.3 ethernet > header. See the diagram in "PACKET FLOW" of "man ipfw".... > > Regards, Dear Chuck thanks for your response. I am not sure though that my question is answered. Yes switching net.link.ether.ipfw->1 does cause processing against layer 2 as indicated in the man ipfw diagram and the command # sysctl -d net.link.ether.ipfw Yields the description net.link.ether.ipfw: Pass ether pkts through firewall Setting this sysctl variable to 0 does disengage the processing of Ethernet frames and corresponding IP payloads according to the rule set specified and visa-versa. I do not see anything indicating this sysctl variable affects the way dummynet does bit counting as it enforces bw limits on a pipe or queue. Will the ruleset I provided above impliment the 1Mbit/s limit at layer 2 including the Ethernet frames in the 1Mbit/s budget or (VS.) Only layer 3 IP datagrams (and their coresponding layer 4 payloads) are incrementing the counters responsible for counting against the 1Mbit/s limit Simplification of question: Given: # pipe 1 config bw 1Mbit/sec # ipfw 1000 add pipe 1 ip from any to any out xmit em0 Dichotomy: layer 2 is limit to 1Mbit/s out em0 (Vs.) layer 3 is limit to 1Mbit/s out em0 Only one of these can be correct and I do not see documentation anywhere indicating to me which one is indeed correct. I am not educated enough to look in the source code to determine this for myself. I did not state before the dummynet is on a freebsd transparent bridge. Here are my sysctl variables net.link.ether.ipfw: 0 net.link.bridge.ipfw: 1 net.link.bridge.ipfw_arp: 0 # sysctl -a | grep dummynet net.inet.ip.dummynet.debug: 0 net.inet.ip.dummynet.pipe_byte_limit: 7000000 net.inet.ip.dummynet.pipe_slot_limit: 100 net.inet.ip.dummynet.io_pkt_drop: 33250421 net.inet.ip.dummynet.io_pkt_fast: 0 net.inet.ip.dummynet.io_pkt: 3512830485 net.inet.ip.dummynet.io_fast: 0 net.inet.ip.dummynet.tick_lost: 0 net.inet.ip.dummynet.tick_diff: 1662798 net.inet.ip.dummynet.tick_adjustment: 1679911 net.inet.ip.dummynet.tick_delta_sum: 721 net.inet.ip.dummynet.tick_delta: 2 net.inet.ip.dummynet.red_max_pkt_size: 1500 net.inet.ip.dummynet.red_avg_pkt_size: 512 net.inet.ip.dummynet.red_lookup_depth: 256 net.inet.ip.dummynet.max_chain_len: 16 net.inet.ip.dummynet.expire: 1 net.inet.ip.dummynet.search_steps: 0 net.inet.ip.dummynet.searches: 0 net.inet.ip.dummynet.extract_heap: 0 net.inet.ip.dummynet.ready_heap: 16 net.inet.ip.dummynet.curr_time: 1804818806 net.inet.ip.dummynet.hash_size: 64 # sysctl -a | grep fw net.inet.ip.fw.dyn_keepalive: 1 net.inet.ip.fw.dyn_short_lifetime: 5 net.inet.ip.fw.dyn_udp_lifetime: 10 net.inet.ip.fw.dyn_rst_lifetime: 1 net.inet.ip.fw.dyn_fin_lifetime: 1 net.inet.ip.fw.dyn_syn_lifetime: 20 net.inet.ip.fw.dyn_ack_lifetime: 300 net.inet.ip.fw.static_count: 26 net.inet.ip.fw.dyn_max: 4096 net.inet.ip.fw.dyn_count: 0 net.inet.ip.fw.curr_dyn_buckets: 256 net.inet.ip.fw.dyn_buckets: 256 net.inet.ip.fw.default_rule: 65535 net.inet.ip.fw.verbose_limit: 0 net.inet.ip.fw.verbose: 0 net.inet.ip.fw.debug: 1 net.inet.ip.fw.one_pass: 1 net.inet.ip.fw.autoinc_step: 100 net.inet.ip.fw.enable: 1 rule set 00900 15945359 1264958184 allow ip from 10.18.0.6 to any out xmit bce0 00901 44378882 8041056830 pipe 1 ip from 10.18.0.0/24 to any out xmit bce0 00910 225165 18913860 pipe 1 ip from 10.18.2.1 to any out xmit bce0 00915 0 0 pipe 2 ip from 10.18.2.2 to any out xmit bce0 00920 0 0 pipe 3 ip from 10.18.2.3 to any out xmit bce0 01000 265959 40261978 pipe 1 ip from 10.21.192.8/29 to any out xmit bce0 01001 19627389 3444748305 pipe 1 ip from 10.20.0.0/20 to any out xmit bce0 01002 180922838 31277916333 pipe 1 ip from 10.21.32.0/20 to any out xmit bce0 01003 376697028 75171259985 pipe 1 ip from 10.20.64.0/20 to any out xmit bce0 01004 68629348 12603497407 pipe 1 ip from 10.20.192.0/20 to any out xmit bce0 01005 185005607 37413644435 pipe 1 ip from 10.20.176.0/20 to any out xmit bce0 01006 59179395 10051795154 pipe 1 ip from 10.20.144.0/20 to any out xmit bce0 01007 235863676 41845371053 pipe 1 ip from 10.20.128.0/20 to any out xmit bce0 01008 51518999 10847386956 pipe 1 ip from 10.20.96.0/20 to any out xmit bce0 01009 79734709 13723937026 pipe 1 ip from 10.20.112.0/20 to any out xmit bce0 01010 30062283 4078276506 pipe 1 ip from 10.20.80.0/20 to any out xmit bce0 01011 36318511 6974450810 pipe 1 ip from 10.20.208.0/20 to any out xmit bce0 01012 19642496 3098922560 pipe 1 ip from 10.20.160.0/20 to any out xmit bce0 01013 18209570 2964820411 pipe 1 ip from 10.20.224.0/20 to any out xmit bce0 01014 13707931 3915527156 pipe 1 ip from 10.22.160.0/20 to any out xmit bce0 01015 9893051 1175739042 pipe 1 ip from 10.21.112.0/20 to any out xmit bce0 01016 39876049 7905051976 pipe 1 ip from 10.22.144.0/20 to any out xmit bce0 01017 0 0 pipe 1 ip from 10.22.147.0/24 to any out xmit bce0 01018 128251743 24972920481 pipe 1 ip from 10.21.0.0/20 to any out xmit bce0 01019 102099411 27172050432 pipe 1 ip from 10.21.16.0/20 to any out xmit bce0 65535 53581341116 24295389614128 allow ip from any to any and pipe spec # ipfw pipe list 00001: 11.500 Mbit/s 0 ms 75 KB 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 10.21.44.163/47934 65.55.131.121/80 1735939204 358391598184 1 191 10152696 You can see that the bw has been configured to 11.5Mbit/s which should be the base 10 expression for bit/s meaning exactly 11,500,000 bit/s And here lies the question again does this limit include layer 2 Ethernet frame headers in the bit/s counting mechanism -Mike -- -------------------------------------------------- Mike Spratt - Iraq (GMT+3) Office: (214)242-1782 DSN: (318)847-2983 Cell: +964-770-398-4366 mike@magicislandtechnologies.com --------------------------------------------------- From owner-freebsd-ipfw@FreeBSD.ORG Wed Aug 19 15:20:25 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B979106564A for ; Wed, 19 Aug 2009 15:20:25 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id 697F38FC45 for ; Wed, 19 Aug 2009 15:20:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id n7JFKKE7041661; Thu, 20 Aug 2009 01:20:21 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 20 Aug 2009 01:20:20 +1000 (EST) From: Ian Smith To: Michael Spratt In-Reply-To: <4A8BC140.8050203@magicislandtechnologies.com> Message-ID: <20090819224032.B90928@sola.nimnet.asn.au> References: <4A8969FF.2070601@magicislandtechnologies.com> <4A8BC140.8050203@magicislandtechnologies.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-ipfw@freebsd.org, rizzo@icir.org Subject: Re: out xmit (demux) pipe bw accounting X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 15:20:25 -0000 On Wed, 19 Aug 2009, Michael Spratt wrote: > Chuck Swiger wrote: > > Hi-- > > > > On Aug 17, 2009, at 7:32 AM, Michael Spratt wrote: > > > Could not find answer to following question. > > > > > > Given : > > > # pipe 1 config bw 1Mbit/sec > > > # ipfw 1000 add pipe 1 ip from any to any out xmit em0 > > > > > > Will the bandwidth limit include layer 2 Ethernet headers or will only > > > the IP datagram itself be included in the accounting mechanism? > > > > IPFW normally processes traffic at layer-3, but you can toggle > > net.link.ether.ipfw sysctl to on, in which case the above rule would also > > be run against layer-2 packets including the 802.3 ethernet header. See > > the diagram in "PACKET FLOW" of "man ipfw".... > > > > Regards, > > Dear Chuck thanks for your response. I am not sure though that my question is > answered. Yes switching net.link.ether.ipfw->1 does cause processing against > layer 2 as indicated in the man ipfw diagram and the command > # sysctl -d net.link.ether.ipfw Yields the description net.link.ether.ipfw: > Pass ether pkts through firewall > > Setting this sysctl variable to 0 does disengage the processing of Ethernet > frames and corresponding IP payloads according to the rule set specified and > visa-versa. > > I do not see anything indicating this sysctl variable affects the way > dummynet does bit counting as it enforces bw limits on a pipe or queue. That's right, dummynet pipes and queues work at the IP packet level. > Will the ruleset I provided above impliment the 1Mbit/s limit at layer 2 > including the Ethernet frames in the 1Mbit/s budget or (VS.) Only layer 3 IP > datagrams (and their coresponding layer 4 payloads) are incrementing the > counters responsible for counting against the 1Mbit/s limit I think only IP packets are queued in dummynet pipes, and it's IP packet throughput rates being managed. Check out Luigi's site at http://info.iet.unipi.it/~luigi/dummynet/ There's a couple of really good .pdfs listed at the bottom describing the porting of ipfw/dummynet to Linux, with lots of detail background. It'd seem unusual if the 1Mbit/s limit you've presumably been allocated from 'higher up' would include ethernet headers as well as IP traffic. And even if it did, it's not so hard to calculate what factor to use to keep the rate below 1Mbit/s at ethernet layer, if they count that way. > Simplification of question: > Given: > # pipe 1 config bw 1Mbit/sec > # ipfw 1000 add pipe 1 ip from any to any out xmit em0 > Dichotomy: > layer 2 is limit to 1Mbit/s out em0 (Vs.) layer 3 is limit to 1Mbit/s out > em0 > > Only one of these can be correct and I do not see documentation anywhere > indicating to me which one is indeed correct. I am not educated enough to > look in the source code to determine this for myself. man ipfw read a few times forwards and backwards pretty well covers it, though the code's not bad bedtime reading :) > I did not state before the dummynet is on a freebsd transparent bridge. > Here are my sysctl variables > > net.link.ether.ipfw: 0 > net.link.bridge.ipfw: 1 > net.link.bridge.ipfw_arp: 0 > # sysctl -a | grep dummynet > net.inet.ip.dummynet.debug: 0 > net.inet.ip.dummynet.pipe_byte_limit: 7000000 > net.inet.ip.dummynet.pipe_slot_limit: 100 > net.inet.ip.dummynet.io_pkt_drop: 33250421 > net.inet.ip.dummynet.io_pkt_fast: 0 > net.inet.ip.dummynet.io_pkt: 3512830485 > net.inet.ip.dummynet.io_fast: 0 > net.inet.ip.dummynet.tick_lost: 0 > net.inet.ip.dummynet.tick_diff: 1662798 > net.inet.ip.dummynet.tick_adjustment: 1679911 > net.inet.ip.dummynet.tick_delta_sum: 721 > net.inet.ip.dummynet.tick_delta: 2 > net.inet.ip.dummynet.red_max_pkt_size: 1500 > net.inet.ip.dummynet.red_avg_pkt_size: 512 > net.inet.ip.dummynet.red_lookup_depth: 256 > net.inet.ip.dummynet.max_chain_len: 16 > net.inet.ip.dummynet.expire: 1 > net.inet.ip.dummynet.search_steps: 0 > net.inet.ip.dummynet.searches: 0 > net.inet.ip.dummynet.extract_heap: 0 > net.inet.ip.dummynet.ready_heap: 16 > net.inet.ip.dummynet.curr_time: 1804818806 > net.inet.ip.dummynet.hash_size: 64 > # sysctl -a | grep fw > net.inet.ip.fw.dyn_keepalive: 1 > net.inet.ip.fw.dyn_short_lifetime: 5 > net.inet.ip.fw.dyn_udp_lifetime: 10 > net.inet.ip.fw.dyn_rst_lifetime: 1 > net.inet.ip.fw.dyn_fin_lifetime: 1 > net.inet.ip.fw.dyn_syn_lifetime: 20 > net.inet.ip.fw.dyn_ack_lifetime: 300 > net.inet.ip.fw.static_count: 26 > net.inet.ip.fw.dyn_max: 4096 > net.inet.ip.fw.dyn_count: 0 > net.inet.ip.fw.curr_dyn_buckets: 256 > net.inet.ip.fw.dyn_buckets: 256 > net.inet.ip.fw.default_rule: 65535 > net.inet.ip.fw.verbose_limit: 0 > net.inet.ip.fw.verbose: 0 > net.inet.ip.fw.debug: 1 > net.inet.ip.fw.one_pass: 1 > net.inet.ip.fw.autoinc_step: 100 > net.inet.ip.fw.enable: 1 > > rule set > > 00900 15945359 1264958184 allow ip from 10.18.0.6 to any out xmit bce0 > 00901 44378882 8041056830 pipe 1 ip from 10.18.0.0/24 to any out xmit bce0 > 00910 225165 18913860 pipe 1 ip from 10.18.2.1 to any out xmit bce0 > 00915 0 0 pipe 2 ip from 10.18.2.2 to any out xmit bce0 > 00920 0 0 pipe 3 ip from 10.18.2.3 to any out xmit bce0 > 01000 265959 40261978 pipe 1 ip from 10.21.192.8/29 to any out xmit bce0 > 01001 19627389 3444748305 pipe 1 ip from 10.20.0.0/20 to any out xmit bce0 > 01002 180922838 31277916333 pipe 1 ip from 10.21.32.0/20 to any out xmit bce0 > 01003 376697028 75171259985 pipe 1 ip from 10.20.64.0/20 to any out xmit bce0 > 01004 68629348 12603497407 pipe 1 ip from 10.20.192.0/20 to any out xmit bce0 > 01005 185005607 37413644435 pipe 1 ip from 10.20.176.0/20 to any out xmit bce0 > 01006 59179395 10051795154 pipe 1 ip from 10.20.144.0/20 to any out xmit bce0 > 01007 235863676 41845371053 pipe 1 ip from 10.20.128.0/20 to any out xmit bce0 > 01008 51518999 10847386956 pipe 1 ip from 10.20.96.0/20 to any out xmit bce0 > 01009 79734709 13723937026 pipe 1 ip from 10.20.112.0/20 to any out xmit bce0 > 01010 30062283 4078276506 pipe 1 ip from 10.20.80.0/20 to any out xmit bce0 > 01011 36318511 6974450810 pipe 1 ip from 10.20.208.0/20 to any out xmit bce0 > 01012 19642496 3098922560 pipe 1 ip from 10.20.160.0/20 to any out xmit bce0 > 01013 18209570 2964820411 pipe 1 ip from 10.20.224.0/20 to any out xmit bce0 > 01014 13707931 3915527156 pipe 1 ip from 10.22.160.0/20 to any out xmit bce0 > 01015 9893051 1175739042 pipe 1 ip from 10.21.112.0/20 to any out xmit bce0 > 01016 39876049 7905051976 pipe 1 ip from 10.22.144.0/20 to any out xmit bce0 > 01017 0 0 pipe 1 ip from 10.22.147.0/24 to any out xmit bce0 > 01018 128251743 24972920481 pipe 1 ip from 10.21.0.0/20 to any out xmit bce0 > 01019 102099411 27172050432 pipe 1 ip from 10.21.16.0/20 to any out xmit bce0 > 65535 53581341116 24295389614128 allow ip from any to any > > and pipe spec > > # ipfw pipe list > 00001: 11.500 Mbit/s 0 ms 75 KB 1 queues (1 buckets) droptail > mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte > Drp > 0 tcp 10.21.44.163/47934 65.55.131.121/80 1735939204 358391598184 > 1 191 10152696 > > > You can see that the bw has been configured to 11.5Mbit/s which should be the > base 10 expression for bit/s meaning exactly 11,500,000 bit/s Yes, but I don't see how you get 11.5Mbit/s from your specification above of 1Mbit/s? Or is this a different example? > And here lies the question again does this limit include layer 2 Ethernet > frame headers in the bit/s counting mechanism I'd say not, but check with your provider that 1Mbit/s of IP is allowed; that would be my expectation of such a spec, hereabouts anyway. cheers, Ian From owner-freebsd-ipfw@FreeBSD.ORG Sat Aug 22 00:10:05 2009 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E9C6106568F for ; Sat, 22 Aug 2009 00:10:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4D8318FC1D for ; Sat, 22 Aug 2009 00:10:05 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7M0A4Lq071353 for ; Sat, 22 Aug 2009 00:10:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7M0A419071352; Sat, 22 Aug 2009 00:10:04 GMT (envelope-from gnats) Date: Sat, 22 Aug 2009 00:10:04 GMT Message-Id: <200908220010.n7M0A419071352@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Lars Eggert Cc: Subject: Re: bin/117214: ipfw(8) fwd with IPv6 treats input as IPv4 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lars Eggert List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 00:10:05 -0000 The following reply was made to PR bin/117214; it has been noted by GNATS. From: Lars Eggert To: bug-followup@FreeBSD.org, fabian@wenks.ch Cc: Subject: Re: bin/117214: ipfw(8) fwd with IPv6 treats input as IPv4 Date: Sat, 22 Aug 2009 02:27:44 +0300 I still see this on 7.2-STABLE: [root@fit: ~] uname -a FreeBSD fit.nokia.com 7.2-STABLE FreeBSD 7.2-STABLE #18: Fri Jun 26 15:43:17 EEST 2009 root@fit.nokia.com:/usr/obj/usr/src/sys/FIT i386 [root@fit: ~] ipfw add 64010 fwd 2001:2060:40:1::1 ip6 from 2001:2060:40:1::123,2001:2060:40:1::124 to not 2001:0708:0040:fff2::1/64 out 64010 fwd 0.0.7.209,2060 ip6 from 2001:2060:40:1::123,2001:2060:40:1::124 to not 2001:708:40:fff2::/64 out [root@fit: ~] ipfw show 64010 64010 0 0 fwd 0.0.7.209,2060 ip6 from 2001:2060:40:1::123,2001:2060:40:1::124 to not 2001:708:40:fff2::/64 out From owner-freebsd-ipfw@FreeBSD.ORG Sat Aug 22 00:10:07 2009 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35DEA106568D for ; Sat, 22 Aug 2009 00:10:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 249758FC08 for ; Sat, 22 Aug 2009 00:10:07 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7M0A7pf071386 for ; Sat, 22 Aug 2009 00:10:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7M0A78T071385; Sat, 22 Aug 2009 00:10:07 GMT (envelope-from gnats) Date: Sat, 22 Aug 2009 00:10:07 GMT Message-Id: <200908220010.n7M0A78T071385@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Lars Eggert Cc: Subject: Re: bin/104921: [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (another variation on PR 91245) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lars Eggert List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 00:10:07 -0000 The following reply was made to PR bin/104921; it has been noted by GNATS. From: Lars Eggert To: bug-followup@FreeBSD.org, seh-10lzx4@mail.quadrizen.com Cc: Subject: Re: bin/104921: [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (another variation on PR 91245) Date: Sat, 22 Aug 2009 02:27:27 +0300 I still see this on 7.2-STABLE: [root@fit: ~] uname -a FreeBSD fit.nokia.com 7.2-STABLE FreeBSD 7.2-STABLE #18: Fri Jun 26 15:43:17 EEST 2009 root@fit.nokia.com:/usr/obj/usr/src/sys/FIT i386 [root@fit: ~] ipfw add 64010 fwd 2001:2060:40:1::1 ip6 from 2001:2060:40:1::123,2001:2060:40:1::124 to not 2001:0708:0040:fff2::1/64 out 64010 fwd 0.0.7.209,2060 ip6 from 2001:2060:40:1::123,2001:2060:40:1::124 to not 2001:708:40:fff2::/64 out [root@fit: ~] ipfw show 64010 64010 0 0 fwd 0.0.7.209,2060 ip6 from 2001:2060:40:1::123,2001:2060:40:1::124 to not 2001:708:40:fff2::/64 out From owner-freebsd-ipfw@FreeBSD.ORG Sat Aug 22 11:42:22 2009 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D03B0106568C for ; Sat, 22 Aug 2009 11:42:22 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (unknown [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 676198FC0C for ; Sat, 22 Aug 2009 11:42:22 +0000 (UTC) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 8BABA153435; Sat, 22 Aug 2009 13:42:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSyBzqyT03D2; Sat, 22 Aug 2009 13:42:18 +0200 (CEST) Received: from [192.168.10.242] (vaio [192.168.10.242]) by mail.digiware.nl (Postfix) with ESMTP id A17DE153434; Sat, 22 Aug 2009 13:42:18 +0200 (CEST) Message-ID: <4A8FD99F.1050406@digiware.nl> Date: Sat, 22 Aug 2009 13:42:23 +0200 From: Willem Jan Withagen Organization: Digiware Management User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Lars Eggert References: <200908220010.n7M0A419071352@freefall.freebsd.org> In-Reply-To: <200908220010.n7M0A419071352@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@FreeBSD.org Subject: Re: bin/117214: ipfw(8) fwd with IPv6 treats input as IPv4 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 11:42:22 -0000 Lars Eggert wrote: > The following reply was made to PR bin/117214; it has been noted by GNATS. > > From: Lars Eggert > To: bug-followup@FreeBSD.org, fabian@wenks.ch > Cc: > Subject: Re: bin/117214: ipfw(8) fwd with IPv6 treats input as IPv4 > Date: Sat, 22 Aug 2009 02:27:44 +0300 > > I still see this on 7.2-STABLE: > > [root@fit: ~] uname -a > FreeBSD fit.nokia.com 7.2-STABLE FreeBSD 7.2-STABLE #18: Fri Jun 26 > 15:43:17 EEST 2009 root@fit.nokia.com:/usr/obj/usr/src/sys/FIT i386 > > [root@fit: ~] ipfw add 64010 fwd 2001:2060:40:1::1 ip6 from > 2001:2060:40:1::123,2001:2060:40:1::124 to not > 2001:0708:0040:fff2::1/64 out > 64010 fwd 0.0.7.209,2060 ip6 from > 2001:2060:40:1::123,2001:2060:40:1::124 to not 2001:708:40:fff2::/64 out > > [root@fit: ~] ipfw show 64010 > 64010 0 0 fwd 0.0.7.209,2060 ip6 from > 2001:2060:40:1::123,2001:2060:40:1::124 to not 2001:708:40:fff2::/64 out The trouble is with the :'s and the fact that parsing doen't really take care of multiple :'s. What I considering is changing it in such a way that one is allowed to specify ipv6 adresses as [a:bc::d] just like it works in firefox (and other places) Question then is do we use [a:bc::d]/48:53 or [a:bc::d/48]:53? --WjW