From owner-freebsd-ipfw@FreeBSD.ORG Mon May 24 11:06:56 2010 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 EB5EF1065672 for ; Mon, 24 May 2010 11:06:56 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DB8DB8FC25 for ; Mon, 24 May 2010 11:06:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4OB6ug7004411 for ; Mon, 24 May 2010 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4OB6u3p004409 for freebsd-ipfw@FreeBSD.org; Mon, 24 May 2010 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 May 2010 11:06:56 GMT Message-Id: <201005241106.o4OB6u3p004409@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, 24 May 2010 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/145733 ipfw [ipfw] [patch] ipfw flaws with ipv6 fragments o kern/145305 ipfw [ipfw] ipfw problems, panics, data corruption, ipv6 so o kern/145167 ipfw [ipfw] ipfw nat does not follow its documentation o kern/144869 ipfw [ipfw] [panic] Instant kernel panic when adding NAT ru o kern/144269 ipfw [ipfw] problem with ipfw tables o kern/144187 ipfw [ipfw] deadlock using multiple ipfw nat and multiple l o kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143653 ipfw [ipfw] [patch] ipfw nat redirect_port "buf is too smal o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/143474 ipfw [ipfw] ipfw table contains the same address o kern/139581 ipfw [ipfw] "ipfw pipe" not limiting bandwidth o kern/139226 ipfw [ipfw] install_state: entry already present, done 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 bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from 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/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets 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 bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s 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 70 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon May 24 15:30:58 2010 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 A4ED9106564A; Mon, 24 May 2010 15:30:58 +0000 (UTC) (envelope-from jilles@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7B9F98FC19; Mon, 24 May 2010 15:30:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4OFUwcA040167; Mon, 24 May 2010 15:30:58 GMT (envelope-from jilles@freefall.freebsd.org) Received: (from jilles@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4OFUwkk040158; Mon, 24 May 2010 15:30:58 GMT (envelope-from jilles) Date: Mon, 24 May 2010 15:30:58 GMT Message-Id: <201005241530.o4OFUwkk040158@freefall.freebsd.org> To: jilles@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: jilles@FreeBSD.org Cc: Subject: Re: kern/142951: [dummynet] using pipes&queues gives OUCH! pipe should be idle, system crash after a while 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, 24 May 2010 15:30:58 -0000 Old Synopsis: [libc] using pipes&queues gives OUCH! pipe should be idle, system crash after a while New Synopsis: [dummynet] using pipes&queues gives OUCH! pipe should be idle, system crash after a while Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: jilles Responsible-Changed-When: Mon May 24 15:30:21 UTC 2010 Responsible-Changed-Why: Assign to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=142951 From owner-freebsd-ipfw@FreeBSD.ORG Tue May 25 02:17:40 2010 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 089571065676 for ; Tue, 25 May 2010 02:17:40 +0000 (UTC) (envelope-from mjl@luckie.org.nz) Received: from zombie.scms.waikato.ac.nz (mail.scms.waikato.ac.nz [130.217.241.36]) by mx1.freebsd.org (Postfix) with ESMTP id C9CDB8FC19 for ; Tue, 25 May 2010 02:17:39 +0000 (UTC) Received: from sorcerer.cs.waikato.ac.nz ([130.217.250.39]) by zombie.scms.waikato.ac.nz with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OGjNh-0002ri-PS for freebsd-ipfw@freebsd.org; Tue, 25 May 2010 13:56:33 +1200 Message-ID: <4BFB2E51.1000800@luckie.org.nz> Date: Tue, 25 May 2010 13:56:33 +1200 From: Matthew Luckie User-Agent: Thunderbird 2.0.0.23 (X11/20091127) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: IPFW flaws with IPv6 fragments 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: Tue, 25 May 2010 02:17:40 -0000 Hi I'm just wondering if I can interest anyone in an IPFW PR with a tested patch, which I submitted a few weeks ago. http://www.freebsd.org/cgi/query-pr.cgi?pr=145733 The flaws that the patch fixes: - Rejection of packets with an IPv6 Fragmentation header if the packet is not actually fragmented (offset and mf both zero). This type of packet is allowed by RFC 2460. - Rejection of fragments with offset != 0 if they are small (because the code tries to pullup a transport layer header which isn't there) - No check of the transport layer fields with for the first fragment offset zero because the mf bit is masked into the offset field. I'm happy to address any concerns with the patch if there are any. Thanks, Matthew From owner-freebsd-ipfw@FreeBSD.ORG Tue May 25 03:57:10 2010 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 681CD106566C for ; Tue, 25 May 2010 03:57:10 +0000 (UTC) (envelope-from julian@elischer.org) Received: from out-0.mx.aerioconnect.net (out-0-36.mx.aerioconnect.net [216.240.47.96]) by mx1.freebsd.org (Postfix) with ESMTP id 4B1188FC18 for ; Tue, 25 May 2010 03:57:10 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o4P3v5sv014512; Mon, 24 May 2010 20:57:05 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 61DDD2D6014; Mon, 24 May 2010 20:57:04 -0700 (PDT) Message-ID: <4BFB4A9B.3040505@elischer.org> Date: Mon, 24 May 2010 20:57:15 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Matthew Luckie References: <4BFB2E51.1000800@luckie.org.nz> In-Reply-To: <4BFB2E51.1000800@luckie.org.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-ipfw@freebsd.org Subject: Re: IPFW flaws with IPv6 fragments 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: Tue, 25 May 2010 03:57:10 -0000 On 5/24/10 6:56 PM, Matthew Luckie wrote: > Hi > > I'm just wondering if I can interest anyone in an IPFW PR with a tested > patch, which I submitted a few weeks ago. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=145733 > > The flaws that the patch fixes: > > - Rejection of packets with an IPv6 Fragmentation header if the packet > is not actually fragmented (offset and mf both zero). This type of > packet is allowed by RFC 2460. > > - Rejection of fragments with offset != 0 if they are small (because > the code tries to pullup a transport layer header which isn't there) > > - No check of the transport layer fields with for the first fragment > offset zero because the mf bit is masked into the offset field. > > I'm happy to address any concerns with the patch if there are any. I think everyone is staying clear of ipfw at the moment as Luigi is dong work on it. if he gets done with his new work he will hopefully address the many ipfw bugs currently reported. > > Thanks, > > Matthew > _______________________________________________ > 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 Tue May 25 19:37:34 2010 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 66917106564A for ; Tue, 25 May 2010 19:37:34 +0000 (UTC) (envelope-from ml@infosec.pl) Received: from v027580.home.net.pl (v027580.home.net.pl [89.161.156.148]) by mx1.freebsd.org (Postfix) with SMTP id 9E5C48FC1B for ; Tue, 25 May 2010 19:37:33 +0000 (UTC) Received: from 94-193-57-116.zone7.bethere.co.uk [94.193.57.116] (HELO [192.168.1.65]) by freeside.home.pl [89.161.156.148] with SMTP (IdeaSmtpServer v0.70) id b4cdf9734fccdcb5; Tue, 25 May 2010 21:10:53 +0200 Message-ID: <4BFC20B8.1050700@infosec.pl> Date: Tue, 25 May 2010 20:10:48 +0100 From: Michal User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100405 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org References: <4BFB2E51.1000800@luckie.org.nz> <4BFB4A9B.3040505@elischer.org> In-Reply-To: <4BFB4A9B.3040505@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: IPFW flaws with IPv6 fragments 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: Tue, 25 May 2010 19:37:34 -0000 On 25/05/2010 04:57, Julian Elischer wrote: > > I think everyone is staying clear of ipfw at the moment as Luigi is > dong work on it. if he gets done with his new work he will hopefully > address the many ipfw bugs currently reported. Excuse my ignorance - I'm just starting with ipfw and this list - the work you are talking about, is it some kind of rewrite? Or adding new big features? M -- "Never forget what a man says to you when he is angry." -Henry Ward Beecher From owner-freebsd-ipfw@FreeBSD.ORG Wed May 26 14:49:21 2010 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 C20B6106566C for ; Wed, 26 May 2010 14:49:21 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9840D8FC25 for ; Wed, 26 May 2010 14:49:21 +0000 (UTC) Received: by pva4 with SMTP id 4so859795pva.13 for ; Wed, 26 May 2010 07:49:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=O+G6fjC6NuZdHsfk/xGGDuW/MVHgs3AIHljRYgDRw3w=; b=kgl7q11cjeV1RiGbWZ9NY8yAOcQjRZZAYpsBP2Vqo0Syqd7dP30N8nMWSKWSpmLVk1 igIvYqy+09hTCp33l89KmBVzdySklKcZAleBD6OqxES/iXuJIK3nyPQyyaILb4ZIqrqz oXijzu4XCywgJEPATGYlpaePTd65aO64MCLdE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NYTTosp3KwTJw8uA0C+gBgkzxp2ghNsrCY+Ctca+ro5LK6CO0QDdnk+nW9NvfI0FU0 OQZuFC7ZVNHPlwPXaO8N6yG5NRzZnkZouO+Oo8um3edqZl+b9YGoP5oKE3sreNrmjZ0M NNxdw+aJV8P3FgettBNHK+JssJI46D8Mdy0Ho= MIME-Version: 1.0 Received: by 10.115.132.22 with SMTP id j22mr7630041wan.125.1274883549425; Wed, 26 May 2010 07:19:09 -0700 (PDT) Received: by 10.231.182.204 with HTTP; Wed, 26 May 2010 07:19:09 -0700 (PDT) In-Reply-To: <4BFC20B8.1050700@infosec.pl> References: <4BFB2E51.1000800@luckie.org.nz> <4BFB4A9B.3040505@elischer.org> <4BFC20B8.1050700@infosec.pl> Date: Wed, 26 May 2010 09:19:09 -0500 Message-ID: From: Brandon Gooch To: Michal Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-ipfw@freebsd.org Subject: Re: IPFW flaws with IPv6 fragments 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, 26 May 2010 14:49:21 -0000 On Tue, May 25, 2010 at 2:10 PM, Michal wrote: > On 25/05/2010 04:57, Julian Elischer wrote: >> >> I think everyone is staying clear of ipfw at the moment as Luigi is >> dong work on it. if he gets done with his new work he will hopefully >> address the many ipfw bugs currently reported. > > Excuse my ignorance - I'm just starting with ipfw and this list - the work > you are talking about, is it some kind of rewrite? Or adding new big > features? > > M Check out Luigi's website, especially the first links on the page: http://info.iet.unipi.it/~luigi/dummynet/ -Brandon From owner-freebsd-ipfw@FreeBSD.ORG Thu May 27 08:44:55 2010 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 630A0106566B; Thu, 27 May 2010 08:44:55 +0000 (UTC) (envelope-from oleg@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 39A6D8FC18; Thu, 27 May 2010 08:44:55 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4R8is2G020676; Thu, 27 May 2010 08:44:54 GMT (envelope-from oleg@freefall.freebsd.org) Received: (from oleg@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4R8isKj020672; Thu, 27 May 2010 08:44:54 GMT (envelope-from oleg) Date: Thu, 27 May 2010 08:44:54 GMT Message-Id: <201005270844.o4R8isKj020672@freefall.freebsd.org> To: pomoc@robod.pl, oleg@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: oleg@FreeBSD.org Cc: Subject: Re: kern/142951: [dummynet] using pipes&queues gives OUCH! pipe should be idle, system crash after a while 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: Thu, 27 May 2010 08:44:55 -0000 Synopsis: [dummynet] using pipes&queues gives OUCH! pipe should be idle, system crash after a while State-Changed-From-To: open->feedback State-Changed-By: oleg State-Changed-When: Thu May 27 08:39:37 UTC 2010 State-Changed-Why: I believe this issue was fixed about 5 month ago. Please look at: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ipfw/ip_dummynet.c#rev1.5.2.2 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ipfw/ip_dummynet.c#rev1.9 http://www.freebsd.org/cgi/query-pr.cgi?pr=142951 From owner-freebsd-ipfw@FreeBSD.ORG Fri May 28 10:42:21 2010 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 AA164106566B for ; Fri, 28 May 2010 10:42:21 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 4289E8FC08 for ; Fri, 28 May 2010 10:42:20 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 3543173098; Fri, 28 May 2010 12:52:38 +0200 (CEST) Date: Fri, 28 May 2010 12:52:38 +0200 From: 'Luigi Rizzo' To: Nuno Diogo Message-ID: <20100528105238.GC19972@onelab2.iet.unipi.it> References: <005a01caf6a4$e8cf9c70$ba6ed550$@com> <20100521073601.GA58353@onelab2.iet.unipi.it> <004b01caf8f0$82f78720$88e69560$@com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004b01caf8f0$82f78720$88e69560$@com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-ipfw@freebsd.org Subject: Re: Performance issue with new pipe profile feature in FreeBSD 8.0 RELEASE 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: Fri, 28 May 2010 10:42:21 -0000 On Fri, May 21, 2010 at 10:18:33AM -0400, Nuno Diogo wrote: > Thank you for the break down, I get it now I hope. > Delay is applied AFTER the bandwidth bottleneck, therefore emulating other > hops the packet may have to traverse. > Profile 'delay' is applied IN the bandwidth bottleneck, emulating overhead > and unavailability for that one hop. > You are right, that parameter should be called something besides 'delay'. > Also the diagram in "Dummynet Revisited" page three, shows "delay" being > applied within the "bw" bottleneck instead of after, so that threw me off as > well. > > So unfortunately utilizing the profile delay distribution to emulate a > typical internet connection's fluctuating latency such as my ping to yahoo > below will not achieve accurate throughput emulation. > Since you already have the code that varies the overhead based on empirical > curve, how hard would it be to extend that mechanism to the delay so that > these fluctuating latencies can be emulated with dummynet? the correct way to emulate such latencies would be to add an additional traffic source that sends packets to the same pipe, and as a result causes queueing and delays to fluctuate. You can tweak the code in ip_dn_io.c::serve_sched() /* a regular mbuf received */ done++; len_scaled = (bw == 0) ? 0 : hz * (m->m_pkthdr.len * 8 + extra_bits(m, s)); si->credit -= len_scaled; /* Move packet in the delay line */ ----> dn_tag_get(m)->output_time += s->link.delay ; mq_append(&si->dline.mq, m); where the line marked adds the delay. However the change is not entirely trivial because you should: 1. make sure that those variable delays do not cause packet reordering or other odd effects such as packets coming out of the link at a rate much higher than the nominal rate; 2. implement some mechanism to push into the kernel the parameters that control the delay variations; 3. make the configuration backward compatible. My estimate is that #2 and #3 require a fair amount of time to design the thing correctly, and perhaps a bit of code refactoring to reuse the existing mechanisms used to handle 'profiles'. Unfortunate as it is, in dummynet and ipfw, 1/3 of the code is related to packet processing, and 2/3 are for managing configuration. > wc dummynet2/ip_dn_io.c dummynet2/ip_dummynet.c 929 3781 26667 dummynet2/ip_dn_io.c 2335 8534 60659 dummynet2/ip_dummynet.c cheers luigi > Can you point me to the source code that handles that? I'm not a developer > by any stretch of the imagination but maybe I can learn something while > trying to hack at it? > > Thank you for your reply and your time. > > C:\Users\nuno>ping www.yahoo.com -t -l 1470 > > Pinging any-fp.wa1.b.yahoo.com [69.147.125.65] with 1470 bytes of data: > Reply from 69.147.125.65: bytes=1470 time=45ms TTL=49 > Reply from 69.147.125.65: bytes=1470 time=45ms TTL=49 > Reply from 69.147.125.65: bytes=1470 time=48ms TTL=49 > Reply from 69.147.125.65: bytes=1470 time=44ms TTL=49 > Reply from 69.147.125.65: bytes=1470 time=46ms TTL=49 > Reply from 69.147.125.65: bytes=1470 time=42ms TTL=49 > Reply from 69.147.125.65: bytes=1470 time=50ms TTL=49 > Reply from 69.147.125.65: bytes=1470 time=43ms TTL=49 > Reply from 69.147.125.65: bytes=1470 time=45ms TTL=49 > Reply from 69.147.125.65: bytes=1470 time=45ms TTL=49 > Reply from 69.147.125.65: bytes=1470 time=45ms TTL=49 > Reply from 69.147.125.65: bytes=1470 time=43ms TTL=49 > Reply from 69.147.125.65: bytes=1470 time=72ms TTL=49 > Reply from 69.147.125.65: bytes=1470 time=45ms TTL=49 > Reply from 69.147.125.65: bytes=1470 time=46ms TTL=49 > Reply from 69.147.125.65: bytes=1470 time=44ms TTL=49 > Reply from 69.147.125.65: bytes=1470 time=46ms TTL=49 > Reply from 69.147.125.65: bytes=1470 time=59ms TTL=49 > Reply from 69.147.125.65: bytes=1470 time=43ms TTL=49 > Reply from 69.147.125.65: bytes=1470 time=43ms TTL=49 > Reply from 69.147.125.65: bytes=1470 time=45ms TTL=49 > Reply from 69.147.125.65: bytes=1470 time=42ms TTL=49 > > Ping statistics for 69.147.125.65: > Packets: Sent = 22, Received = 22, Lost = 0 (0% loss), > Approximate round trip times in milli-seconds: > Minimum = 42ms, Maximum = 72ms, Average = 46ms > > ____________________________________________________________________________ > ___ > Nuno Diogo > > > -----Original Message----- > From: Luigi Rizzo [mailto:rizzo@iet.unipi.it] > Sent: Friday, May 21, 2010 3:36 AM > To: Nuno Diogo > Cc: freebsd-ipfw@freebsd.org > Subject: Re: Performance issue with new pipe profile feature in FreeBSD 8.0 > RELEASE > > top post for convenience: > > you are making a common mistake -- "delay" and "profile" are > not the same thing. > + With "delay" you set the propagation delay of the link: once a > packet is outside of the bottleneck, it takes some extra time to > reach its destination. However, during this time, other traffic > will flow through the bottleneck; > + with "profile" you specify a distribution of the extra time that > the packet will take to go through the bottleneck link (e.g. > due to preambles, crc, framing and other stuff). The bottleneck > is effectively unavailable for other traffic during this time. > > So the throughput you measure with a "profile" of X ms is usually > much lower than the one you see with a "delay" of X ms. > > cheers > luigi > > On Thu, May 20, 2010 at 06:56:41PM -0400, Nuno Diogo wrote: > > Hi all, > > Sorry to spam the list with this issue, but I do believe that this is not > > working as intended so I performed some more testing in a controlled > > environment. > > Using a dedicated FreeBSD 8-RELEASE-p2 i386 with GENERIC kernel + the > > following additions: > > > > - options HZ=2000 > > - device if_bridge > > - options IPFIREWALL > > - options IPFIREWALL_DEFAULTS_TO_ACCEPT > > - options DUMMYNET > > > > Routing between VR0 and EM0 interfaces. > > Ipfer TCP transfers between a Win 7 laptop and a Linux virtual server. > > Only one variable changed at a time: > > > > #So lets start with your typical pipe rule using bandwidth and delay > > statement: > > > > *Test 1 with 10Mbps 10ms:* > > > > #Only one rule pushing packets to PIPE 1 if they're passing between these > > two specific interfaces > > FreeBSD-Test# ipfw list > > 0100 pipe 1 ip from any to any recv em0 xmit vr0 > > 65535 allow ip from any to any > > > > #Pipe configured with 10M bandwidth, 10ms delay and 50 slot queue > > FreeBSD-Test# ipfw pipe 1 show > > 00001: 10.000 Mbit/s 10 ms 50 sl. 1 queues (1 buckets) droptail > > burst: 0 Byte > > mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 > > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte > > Drp > > 0 icmp 192.168.100.10/0 10.168.0.99/0 112431 154127874 0 > 0 > > 168 > > > > #Traceroute from laptop to server showing just that one hop > > C:\Users\nuno>tracert -d 10.168.0.99 > > Tracing route to 10.168.0.99 over a maximum of 30 hops > > 1 <1 ms <1 ms <1 ms 192.168.100.1 > > 2 10 ms 10 ms 10 ms 10.168.0.99 > > Trace complete. > > > > #Ping result for 1470 byte packet > > C:\Users\nuno>ping 10.168.0.99 -t -l 1470 > > > > > > > > Pinging 10.168.0.99 with 1470 bytes of data: > > > > Reply from 10.168.0.99: bytes=1470 time=12ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=12ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=12ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=12ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=12ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=12ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=12ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=12ms TTL=63 > > > > > > #Iperf performance, as we can see it utilizes the entire emulated pipe > > > > bin/iperf.exe -c 10.168.0.99 -P 1 -i 1 -p 5001 -f k -t 10000 > > > > ------------------------------------------------------------ > > > > Client connecting to 10.168.0.99, TCP port 5001 > > > > TCP window size: 63.0 KByte (default) > > > > ------------------------------------------------------------ > > > > [148] local 192.168.100.10 port 49225 connected with 10.168.0.99 port 5001 > > > > [ ID] Interval Transfer Bandwidth > > > > [148] 0.0- 1.0 sec 1392 KBytes 11403 Kbits/sec > > > > [148] 1.0- 2.0 sec 1184 KBytes 9699 Kbits/sec > > > > [148] 2.0- 3.0 sec 1192 KBytes 9765 Kbits/sec > > > > [148] 3.0- 4.0 sec 1184 KBytes 9699 Kbits/sec > > > > [148] 4.0- 5.0 sec 1184 KBytes 9699 Kbits/sec > > > > [148] 5.0- 6.0 sec 1184 KBytes 9699 Kbits/sec > > > > [148] 6.0- 7.0 sec 1184 KBytes 9699 Kbits/sec > > > > [148] 7.0- 8.0 sec 1176 KBytes 9634 Kbits/sec > > > > [148] 8.0- 9.0 sec 1192 KBytes 9765 Kbits/sec > > > > [148] 9.0-10.0 sec 1200 KBytes 9830 Kbits/sec > > > > [148] 10.0-11.0 sec 1120 KBytes 9175 Kbits/sec > > > > [148] 11.0-12.0 sec 1248 KBytes 10224 Kbits/sec > > > > [148] 12.0-13.0 sec 1184 KBytes 9699 Kbits/sec > > > > [148] 13.0-14.0 sec 1184 KBytes 9699 Kbits/sec > > > > [148] 14.0-15.0 sec 1184 KBytes 9699 Kbits/sec > > > > [148] 15.0-16.0 sec 1184 KBytes 9699 Kbits/sec > > > > [148] 16.0-17.0 sec 1184 KBytes 9699 Kbits/sec > > > > [148] 17.0-18.0 sec 1184 KBytes 9699 Kbits/sec > > > > [148] 18.0-19.0 sec 1184 KBytes 9699 Kbits/sec > > > > [148] 19.0-20.0 sec 1192 KBytes 9765 Kbits/sec > > > > > > > > #Now let configure the same emulation (from my understanding) but with a > > profile > > > > FreeBSD-Test# cat ./profile > > > > name Test > > > > samples 100 > > > > bw 10M > > > > loss-level 1.0 > > > > prob delay > > > > 0.00 10 > > > > 1.00 10 > > > > > > #Pipe 1 configured with the above profile file and no additional bandwidth > > or delay parameters > > > > FreeBSD-Test# ipfw pipe 1 show > > > > 00001: 10.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail > > > > burst: 0 Byte > > > > profile: name "Test" loss 1.000000 samples 100 > > > > mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 > > > > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte > > Drp > > > > 0 icmp 192.168.100.10/0 10.168.0.99/0 131225 181884981 0 > 0 > > 211 > > > > > > #Ping time for a 1470 byte packet remains the same > > > > C:\Users\nuno>ping 10.168.0.99 -t -l 1470 > > > > > > > > Pinging 10.168.0.99 with 1470 bytes of data: > > > > Reply from 10.168.0.99: bytes=1470 time=12ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=12ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=14ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=12ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=12ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=12ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=11ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=12ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=12ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=12ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=12ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=12ms TTL=63 > > > > #Iperf transfer however drops considerable! > > > > bin/iperf.exe -c 10.168.0.99 -P 1 -i 1 -p 5001 -f k -t 10000 > > > > ------------------------------------------------------------ > > > > Client connecting to 10.168.0.99, TCP port 5001 > > > > TCP window size: 63.0 KByte (default) > > > > ------------------------------------------------------------ > > > > [148] local 192.168.100.10 port 49226 connected with 10.168.0.99 port 5001 > > > > [ ID] Interval Transfer Bandwidth > > > > [148] 0.0- 1.0 sec 248 KBytes 2032 Kbits/sec > > > > [148] 1.0- 2.0 sec 56.0 KBytes 459 Kbits/sec > > > > [148] 2.0- 3.0 sec 176 KBytes 1442 Kbits/sec > > > > [148] 3.0- 4.0 sec 128 KBytes 1049 Kbits/sec > > > > [148] 4.0- 5.0 sec 120 KBytes 983 Kbits/sec > > > > [148] 5.0- 6.0 sec 128 KBytes 1049 Kbits/sec > > > > [148] 6.0- 7.0 sec 128 KBytes 1049 Kbits/sec > > > > [148] 7.0- 8.0 sec 96.0 KBytes 786 Kbits/sec > > > > [148] 8.0- 9.0 sec 144 KBytes 1180 Kbits/sec > > > > [148] 9.0-10.0 sec 128 KBytes 1049 Kbits/sec > > > > [148] 10.0-11.0 sec 128 KBytes 1049 Kbits/sec > > > > [148] 11.0-12.0 sec 120 KBytes 983 Kbits/sec > > > > [148] 12.0-13.0 sec 120 KBytes 983 Kbits/sec > > > > [148] 13.0-14.0 sec 128 KBytes 1049 Kbits/sec > > > > [148] 14.0-15.0 sec 120 KBytes 983 Kbits/sec > > > > [148] 15.0-16.0 sec 128 KBytes 1049 Kbits/sec > > > > [148] 16.0-17.0 sec 120 KBytes 983 Kbits/sec > > > > [148] 17.0-18.0 sec 120 KBytes 983 Kbits/sec > > > > [148] 18.0-19.0 sec 128 KBytes 1049 Kbits/sec > > > > [148] 19.0-20.0 sec 64.0 KBytes 524 Kbits/sec > > > > > > Lets do the exact same but this time reducing the emulate latency down to > > just 2ms. > > *Test 2 with 10Mbps 2ms:* > > #Pipe 1 configured for 10Mbps bandwidth, 2ms latency and 50 slot queue > > > > FreeBSD-Test# ipfw pipe 1 show > > > > 00001: 10.000 Mbit/s 2 ms 50 sl. 1 queues (1 buckets) droptail > > > > burst: 0 Byte > > > > mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 > > > > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte > > Drp > > > > 0 icmp 192.168.100.10/0 10.168.0.99/0 21020 19358074 0 > 0 > > 123 > > > > > > #Ping time from laptop to server > > > > C:\Users\nuno>ping 10.168.0.99 -t -l 1470 > > > > > > > > Pinging 10.168.0.99 with 1470 bytes of data: > > > > Reply from 10.168.0.99: bytes=1470 time=4ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=4ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=4ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=4ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=4ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=4ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=4ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=4ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=3ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=4ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=3ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=4ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=4ms TTL=63 > > > > > > #Ipfer throughput, again we can use all of the emulated bandwidth > > > > bin/iperf.exe -c 10.168.0.99 -P 1 -i 1 -p 5001 -f k -t 10000 > > > > ------------------------------------------------------------ > > > > Client connecting to 10.168.0.99, TCP port 5001 > > > > TCP window size: 63.0 KByte (default) > > > > ------------------------------------------------------------ > > > > [148] local 192.168.100.10 port 49196 connected with 10.168.0.99 port 5001 > > > > [ ID] Interval Transfer Bandwidth > > > > [148] 0.0- 1.0 sec 1264 KBytes 10355 Kbits/sec > > > > [148] 1.0- 2.0 sec 1192 KBytes 9765 Kbits/sec > > > > [148] 2.0- 3.0 sec 1184 KBytes 9699 Kbits/sec > > > > [148] 3.0- 4.0 sec 1184 KBytes 9699 Kbits/sec > > > > [148] 4.0- 5.0 sec 1184 KBytes 9699 Kbits/sec > > > > [148] 5.0- 6.0 sec 1192 KBytes 9765 Kbits/sec > > > > [148] 6.0- 7.0 sec 1184 KBytes 9699 Kbits/sec > > > > [148] 7.0- 8.0 sec 1184 KBytes 9699 Kbits/sec > > > > [148] 8.0- 9.0 sec 1184 KBytes 9699 Kbits/sec > > > > [148] 9.0-10.0 sec 1152 KBytes 9437 Kbits/sec > > > > [148] 10.0-11.0 sec 1240 KBytes 10158 Kbits/sec > > > > [148] 11.0-12.0 sec 1184 KBytes 9699 Kbits/sec > > > > [148] 12.0-13.0 sec 1184 KBytes 9699 Kbits/sec > > > > [148] 13.0-14.0 sec 1176 KBytes 9634 Kbits/sec > > > > [148] 14.0-15.0 sec 984 KBytes 8061 Kbits/sec > > > > [148] 15.0-16.0 sec 1192 KBytes 9765 Kbits/sec > > > > [148] 16.0-17.0 sec 1184 KBytes 9699 Kbits/sec > > > > [148] 17.0-18.0 sec 1184 KBytes 9699 Kbits/sec > > > > [148] 18.0-19.0 sec 1184 KBytes 9699 Kbits/sec > > > > [148] 19.0-20.0 sec 1208 KBytes 9896 Kbits/sec > > > > > > #Now lets configure the profile file to emulate 10Mbps and 2ms of added > > overhead > > > > FreeBSD-Test# cat ./profile > > > > name Test > > > > samples 100 > > > > bw 10M > > > > loss-level 1.0 > > > > prob delay > > > > 0.00 2 > > 1.00 2 > > > > > > > > #Pipe 1 configured with the above profile file and no additional bandwidth > > or delay parameters > > > > FreeBSD-Test# ipfw pipe 1 show > > > > 00001: 10.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail > > > > burst: 0 Byte > > > > profile: name "Test" loss 1.000000 samples 100 > > > > mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 > > > > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte > > Drp > > 0 icmp 192.168.100.10/0 10.168.0.99/0 39570 46750171 0 > 0 > > 186 > > > > #Again, ping remains constant with this configuration > > > > C:\Users\nuno>ping 10.168.0.99 -t -l 1470 > > > > > > > > Pinging 10.168.0.99 with 1470 bytes of data: > > > > Reply from 10.168.0.99: bytes=1470 time=3ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=4ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=4ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=4ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=4ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=4ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=4ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=4ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=3ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=4ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=4ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=4ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=4ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=4ms TTL=63 > > > > Reply from 10.168.0.99: bytes=1470 time=4ms TTL=63 > > > > > > #Iperf throughput again takes a big hit, although not as much as when > we're > > adding 10ms or overhead > > > > bin/iperf.exe -c 10.168.0.99 -P 1 -i 1 -p 5001 -f k -t 10000 > > > > ------------------------------------------------------------ > > > > Client connecting to 10.168.0.99, TCP port 5001 > > > > TCP window size: 63.0 KByte (default) > > > > ------------------------------------------------------------ > > > > [148] local 192.168.100.10 port 49197 connected with 10.168.0.99 port 5001 > > > > [ ID] Interval Transfer Bandwidth > > > > [148] 0.0- 1.0 sec 544 KBytes 4456 Kbits/sec > > > > [148] 1.0- 2.0 sec 440 KBytes 3604 Kbits/sec > > > > [148] 2.0- 3.0 sec 440 KBytes 3604 Kbits/sec > > > > [148] 3.0- 4.0 sec 432 KBytes 3539 Kbits/sec > > > > [148] 4.0- 5.0 sec 440 KBytes 3604 Kbits/sec > > > > [148] 5.0- 6.0 sec 448 KBytes 3670 Kbits/sec > > > > [148] 6.0- 7.0 sec 432 KBytes 3539 Kbits/sec > > > > [148] 7.0- 8.0 sec 440 KBytes 3604 Kbits/sec > > > > [148] 8.0- 9.0 sec 440 KBytes 3604 Kbits/sec > > > > [148] 9.0-10.0 sec 448 KBytes 3670 Kbits/sec > > > > [148] 10.0-11.0 sec 440 KBytes 3604 Kbits/sec > > > > [148] 11.0-12.0 sec 440 KBytes 3604 Kbits/sec > > > > [148] 12.0-13.0 sec 392 KBytes 3211 Kbits/sec > > > > [148] 13.0-14.0 sec 488 KBytes 3998 Kbits/sec > > > > [148] 14.0-15.0 sec 440 KBytes 3604 Kbits/sec > > > > [148] 15.0-16.0 sec 440 KBytes 3604 Kbits/sec > > > > [148] 16.0-17.0 sec 440 KBytes 3604 Kbits/sec > > > > [148] 17.0-18.0 sec 440 KBytes 3604 Kbits/sec > > > > [148] 18.0-19.0 sec 440 KBytes 3604 Kbits/sec > > > > [148] 19.0-20.0 sec 448 KBytes 3670 Kbits/sec > > > > > > From my understanding, since the emulated RTT of the link remains the > same, > > Iperf performance should also stay the same. > > > > Regardless of how or why the RTT is present, (geographically induced > > latency, MAC overhead, congestion etc) the effects on a TCP transmission > > should be the same (assuming as in this test no jitter and packet loss) > > > > > > On the first test we see throughput drop from ~9.7Mbps to 980Kbps-1050Kbps > > with the addition of just 10ms of overhead in the profile! > > > > On the second test we see throughput drop from ~9.7Mbps to ~3.6Mbps with > the > > addition of just 2ms of overhead in the profile! > > > > So is this feature not working as intended or am I completely missing > > something here? > > > > > > I (and hopefully others) would highly appreciate any opinions as this new > > feature could really expand the use of dummynet as a WAN emulator, but it > > seems that in it's current implementation it does not allow for the full > > utilization of the emulated bandwidth regardless of how little or static > the > > extra delay is set to. > > > > > > Sincerely, > > > > Nuno Diogo > > > > On Tue, May 18, 2010 at 12:12 PM, Nuno Diogo wrote: > > > > > Hi all, > > > > > > I?m encountering the same situation, and I?m not quite understanding > > > Luigi?s explanation. > > > > > > If a pipe is configured with 10Mbps bandwidth and 25ms delay, it will > take > > > approximately 26.7ms for a 1470 byte packet to pass through it as per > the > > > below math. > > > > > > IPerf can fully utilize the available emulated bandwidth with that > delay. > > > > > > > > > > > > If we configure a profile with the same characteristics, 10Mbps and 25ms > > > overhead/extra-airtime/delay isn?t the end result the same? > > > > > > A 1470 byte packet should still take ~26.7ms to pass through the pipe > and > > > IPerf should still be able to fully utilize the emulated bandwidth, no? > > > > > > > > > > > > IPerf does not know how that delay is being emulated or configured, it > just > > > knows that it?s taking ~26.7ms to get ACKs back etc, so I guess I?m > missing > > > something here? > > > > > > > > > > > > I use dummynet often for WAN acceleration testing, and have been trying > to > > > use the new profile method to try and emulate ?jitter?. > > > > > > With pings it works great, but when trying to use the full configured > > > bandwidth, I get the same results as Charles. > > > > > > Regardless of delay/overhead/bandwidth configuration IPerf can?t push > more > > > than a fraction of the configured bandwidth with lots of packets queuing > and > > > dropping. > > > > > > > > > > > > Your patience is appreciated. > > > > > > > > > > > > Sincerely, > > > > > > > > > > > > > > > > ____________________________________________________________________________ > ___ > > > > > > Nuno Diogo > > > > > > > > > > > > Luigi Rizzo > > > Tue, 24 Nov 2009 21:21:56 -0800 > > > > > > Hi, > > > > > > there is no bug, the 'pipe profile' code is working correctly. > > > > > > > > > > > > In your mail below you are comparing two different things. > > > > > > > > > > > > "pipe config bw 10Mbit/s delay 25ms" > > > > > > means that _after shaping_ at 10Mbps, all traffic will > > > > > > be subject to an additional delay of 25ms. > > > > > > Each packet (1470 bytes) will take Length/Bandwidth sec > > > > > > to come out or 1470*8/10M = 1.176ms , but you won't > > > > > > see them until you wait another 25ms (7500km at the speed > > > > > > of light). > > > > > > > > > > > > "pipe config bw 10Mbit/s profile "test" ..." > > > > > > means that in addition to the Length/Bandwidth, > > > > > > _each packet transmission_ will consume > > > > > > some additional air-time as specified in the profile > > > > > > (25ms in your case) > > > > > > > > > > > > So, in your case with 1470bytes/pkt each transmission > > > > > > will take len/bw (1.176ms) + 25ms (extra air time) = 26.76ms > > > > > > That is 25 times more than the previous case and explains > > > > > > the reduced bandwidth you see. > > > > > > > > > > > > The 'delay profile' is effectively extra air time used for each > > > > > > transmission. The name is probably confusing, i should have called > > > > > > it 'extra-time' or 'overhead' and not 'delay' > > > > > > > > > > > > cheers > > > > > > luigi > > > > > > > > > > > > On Tue, Nov 24, 2009 at 12:40:31PM -0500, Charles Henri de Boysson > wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I have a simple setup with two computer connected via a FreeBSD bridge > > > > > > > running 8.0 RELEASE. > > > > > > > I am trying to use dummynet to simulate a wireless network between the > > > > > > > two and for that I wanted to use the pipe profile feature of FreeBSD > > > > > > > 8.0. > > > > > > > But as I was experimenting with the pipe profile feature I ran into > some > > > > > > > issues. > > > > > > > > > > > > > > I have setup ipfw to send traffic coming for either interface of the > > > > > > > bridge to a respective pipe as follow: > > > > > > > > > > > > > > # ipfw show > > > > > > > 00100 ?? ?? 0 ?? ?? ?? ?? 0 allow ip from any to any via lo0 > > > > > > > 00200 ?? ?? 0 ?? ?? ?? ?? 0 deny ip from any to 127.0.0.0/8 > > > > > > > 00300 ?? ?? 0 ?? ?? ?? ?? 0 deny ip from 127.0.0.0/8 to any > > > > > > > 01000 ?? ?? 0 ?? ?? ?? ?? 0 pipe 1 ip from any to any via vr0 layer2 > > > > > > > 01100 ?? ?? 0 ?? ?? ?? ?? 0 pipe 101 ip from any to any via vr4 layer2 > > > > > > > 65000 ??7089 ?? ??716987 allow ip from any to any > > > > > > > 65535 ?? ?? 0 ?? ?? ?? ?? 0 deny ip from any to any > > > > > > > > > > > > > > When I setup my pipes as follow: > > > > > > > > > > > > > > # ipfw pipe 1 config bw 10Mbit delay 25 mask proto 0 > > > > > > > # ipfw pipe 101 config bw 10Mbit delay 25 mask proto 0 > > > > > > > # ipfw pipe show > > > > > > > > > > > > > > 00001: ??10.000 Mbit/s ?? 25 ms ?? 50 sl. 0 queues (1 buckets) > droptail > > > > > > > burst: 0 Byte > > > > > > > 00101: ??10.000 Mbit/s ?? 25 ms ?? 50 sl. 0 queues (1 buckets) > droptail > > > > > > > burst: 0 Byte > > > > > > > > > > > > > > With this setup, when I try to pass traffic through the bridge with > > > > > > > iperf, I obtain the desired speed: iperf reports about 9.7Mbits/sec in > > > > > > > UDP mode and 9.5 in TCP mode (I copied and pasted the iperf runs at > > > > > > > the end of this email). > > > > > > > > > > > > > > The problem arise when I setup pipe 1 (the downlink) with an > > > > > > > equivalent profile (I tried to simplify it as much as possible). > > > > > > > > > > > > > > # ipfw pipe 1 config profile test.pipeconf mask proto 0 > > > > > > > # ipfw pipe show > > > > > > > 00001: 10.000 Mbit/s 0 ms 50 sl. 0 queues (1 buckets) droptail > > > > > > > burst: 0 Byte > > > > > > > profile: name "test" loss 1.000000 samples 2 > > > > > > > 00101: 10.000 Mbit/s 25 ms 50 sl. 0 queues (1 buckets) droptail > > > > > > > burst: 0 Byte > > > > > > > > > > > > > > # cat test.pipeconf > > > > > > > name test > > > > > > > bw 10Mbit > > > > > > > loss-level 1.0 > > > > > > > samples 2 > > > > > > > prob delay > > > > > > > 0.0 25 > > > > > > > 1.0 25 > > > > > > > > > > > > > > The same iperf TCP tests then collapse to about 500Kbit/s with the > > > > > > > same settings (copy and pasted the output of iperf bellow) > > > > > > > > > > > > > > I can't figure out what is going on. There is no visible load on the > bridge. > > > > > > > I have an unmodified GENERIC kernel with the following sysctl. > > > > > > > > > > > > > > net.link.bridge.ipfw: 1 > > > > > > > kern.hz: 1000 > > > > > > > > > > > > > > The bridge configuration is as follow: > > > > > > > > > > > > > > bridge0: flags=8843 metric 0 > mtu 1500 > > > > > > > ether 1a:1f:2e:42:74:8d > > > > > > > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > > > > > > > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > > > > > > > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > > > > > > > member: vr4 flags=143 > > > > > > > ?? ?? ?? ??ifmaxaddr 0 port 6 priority 128 path cost 200000 > > > > > > > member: vr0 flags=143 > > > > > > > ?? ?? ?? ??ifmaxaddr 0 port 2 priority 128 path cost 200000 > > > > > > > > > > > > > > > > > > > > > iperf runs without the profile set: > > > > > > > % iperf -B 10.1.0.1 -c 10.0.0.254 -t 15 > > > > > > > ------------------------------------------------------------ > > > > > > > Client connecting to 10.0.0.254, TCP port 5001 > > > > > > > Binding to local address 10.1.0.1 > > > > > > > TCP window size: 16.0 KByte (default) > > > > > > > ------------------------------------------------------------ > > > > > > > [ 3] local 10.1.0.1 port 5001 connected with 10.0.0.254 port 5001 > > > > > > > [ ID] Interval Transfer Bandwidth > > > > > > > [ 3] 0.0-15.0 sec 17.0 MBytes 9.49 Mbits/sec > > > > > > > > > > > > > > % iperf -B 10.1.0.1 -c 10.0.0.254 -t 15 -u -b 10Mbit > > > > > > > ------------------------------------------------------------ > > > > > > > Client connecting to 10.0.0.254, UDP port 5001 > > > > > > > Binding to local address 10.1.0.1 > > > > > > > Sending 1470 byte datagrams > > > > > > > UDP buffer size: 110 KByte (default) > > > > > > > ------------------------------------------------------------ > > > > > > > [ 3] local 10.1.0.1 port 5001 connected with 10.0.0.254 port 5001 > > > > > > > [ ID] Interval Transfer Bandwidth > > > > > > > [ 3] 0.0-15.0 sec 18.8 MBytes 10.5 Mbits/sec > > > > > > > [ 3] Sent 13382 datagrams > > > > > > > [ 3] Server Report: > > > > > > > [ 3] 0.0-15.1 sec 17.4 MBytes 9.72 Mbits/sec 0.822 ms 934/13381 > (7%) > > > > > > > [ 3] 0.0-15.1 sec 1 datagrams received out-of-order > > > > > > > > > > > > > > > > > > > > > iperf runs with the profile set: > > > > > > > % iperf -B 10.1.0.1 -c 10.0.0.254 -t 15 > > > > > > > ------------------------------------------------------------ > > > > > > > Client connecting to 10.0.0.254, TCP port 5001 > > > > > > > Binding to local address 10.1.0.1 > > > > > > > TCP window size: 16.0 KByte (default) > > > > > > > ------------------------------------------------------------ > > > > > > > [ 3] local 10.1.0.1 port 5001 connected with 10.0.0.254 port 5001 > > > > > > > [ ID] Interval Transfer Bandwidth > > > > > > > [ 3] 0.0-15.7 sec 968 KBytes 505 Kbits/sec > > > > > > > > > > > > > > % iperf -B 10.1.0.1 -c 10.0.0.254 -t 15 -u -b 10Mbit > > > > > > > ------------------------------------------------------------ > > > > > > > Client connecting to 10.0.0.254, UDP port 5001 > > > > > > > Binding to local address 10.1.0.1 > > > > > > > Sending 1470 byte datagrams > > > > > > > UDP buffer size: 110 KByte (default) > > > > > > > ------------------------------------------------------------ > > > > > > > [ 3] local 10.1.0.1 port 5001 connected with 10.0.0.254 port 5001 > > > > > > > [ ID] Interval Transfer Bandwidth > > > > > > > [ 3] 0.0-15.0 sec 18.8 MBytes 10.5 Mbits/sec > > > > > > > [ 3] Sent 13382 datagrams > > > > > > > [ 3] Server Report: > > > > > > > [ 3] 0.0-16.3 sec 893 KBytes 449 Kbits/sec 1.810 ms > 12757/13379 (95%) > > > > > > > > > > > > > > > > > > > > > Let me know what other information you would need to help me debugging > this. > > > > > > > In advance, thank you for your help > > > > > > > > > > > > > > -- > > > > > > > Charles-Henri de Boysson > > > > > > > _______________________________________________ > > > > > > > freebsd-ipfw@freebsd.org mailing list > > > > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > > > > > > > To unsubscribe, send any mail to > "freebsd-ipfw-unsubscr...@freebsd.org" > > > > > > _______________________________________________ > > > > > > freebsd-ipfw@freebsd.org mailing list > > > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > > > > > > To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org" > > > > > > > > > > > > > > > > > -- > > > ---------------------------------------------------------------------------- > --------------------- > > > > Nuno Diogo > > _______________________________________________ > > 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"