From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 11 11:06:51 2013 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 ESMTP id EAF3A926 for ; Mon, 11 Nov 2013 11:06:50 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) 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 D85392CB6 for ; Mon, 11 Nov 2013 11:06:50 +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 rABB6odj082079 for ; Mon, 11 Nov 2013 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rABB6oXj082077 for freebsd-ipfw@FreeBSD.org; Mon, 11 Nov 2013 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 11 Nov 2013 11:06:50 GMT Message-Id: <201311111106.rABB6oXj082077@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.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 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/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n 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 Tue Nov 12 17:35:01 2013 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 9BF972F5 for ; Tue, 12 Nov 2013 17:35:01 +0000 (UTC) Received: from r210-116.fanbridge.com (r210-116.fanbridge.com [66.228.116.210]) by mx1.freebsd.org (Postfix) with ESMTP id 569E027A2 for ; Tue, 12 Nov 2013 17:35:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=p04; d=fanbridge.com; h=From:To:Subject:Message-ID:List-Unsubscribe:Sender:Date:Content-Type:MIME-Version; i=noreply-collection-488751@fanbridge.com; bh=blnE+Zu6bSpvyQAO7irKQAaJI9o=; b=cIMwKijsVG4oycaWc+g52G/beCEaPenOtPoKlX3msv7+v2VgbRKGmrq9fZJ9nJTezt1kQHBvwHUJ 2fc8NK2uH+83DzW5AYedHLC0VDMb/9p5Kk05g86vU+vJZOMTHHDtmbGOllsp4s99I31jM01/M8Eq WY6iO0vpxYOYOsbrdis= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=p04; d=fanbridge.com; b=Gqyct+F2HR6Iv2er1NrvkKrgIKRERHkP+98K/rMg8lpyZuR1evJH8eBfET53Z8BH9GXTuwSMnkuR ZORKXYx1NqNzMibP9yX0kHKTRnQ9iAu86wgTRYKjZusVfRPbEvzvtYDcZ67hgTuMIBSUNf1yLOBS YVQwB5HvTNkKoC0WYXE=; Received: from 127.0.0.1 (108.168.153.227) by r210-116.fanbridge.com id hg9jca1lrc0u for ; Tue, 12 Nov 2013 12:34:55 -0500 (envelope-from <176374749-63980-94388-socialdigest@bounces.fanbridge.com>) From: "ZOO LIFE ENT." To: freebsd-ipfw@freebsd.org Subject: =?utf-8?Q?ZOO=20LIFE=20ENT.:=20Social=20Digest=20for=20November=2012?= Message-ID: <8233026374e1ba534138ef84e35664a0@fanbridge.com> X-fbridge-collection: collection-488751 X-fbridge-sid: 176374749 X-fbridge-cfc: X5K1c32rdKBtr9ek5XXB65hrr2 X-fbridge-uid: 63980 X-fbridge-sdrid: 94388 X-fbridge-feature: socialdigest X-fbridge-cluster: limonada X-Report-Abuse: Please report abuse here: http://www.fanbridge.com/contact.php?report_abuse Sender: FanBridge Date: Tue, 12 Nov 2013 12:34:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.16 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 17:35:01 -0000 =20 =09=09Email not displaying correctly? View it in your browser. [1] ZOO LIFE ENT.=20 Social Digest for the week of November 11, 2013 Follow Me: [2] [3] [4] [5] =20 WELCOME TO THIS WEEKS SOCIAL DIGEST! BELOW YOULL FIND A RECAP OF SOME =09 great things that happened over the past week. If you like what you read, just click on it and reply, comment, post or let us know what you think! Thanks for your support. =20 See something you think is hot? Share it with your friends by clicking on the fire icon =09=09 =09=09 [6] =09=09 [7] =20 =09=09Featured Sponsor =09=09 [8] =09=09 [9] =20 =09 40 Glocc Accepts Stars Challenge to a Fight + Accuses Him of Snitching.=20 http://t.co/MI4PaAedZ1 [10]... =20 =09=09 _4 retweets_ [11]=20 =09=09 [12]=20 =09=09via Twitter [13] on 11.10.13 =09=09 [14] =09 T.I. border-bottom: none" colspan=3D"5">=20 =09I AINT WORRIED ABOT NOTHING... SURROUNDED BY REAL ONES DAILY.. STAY READY DONT GPTTA GET READY #ZOOLIFE @everybodywants2bontop @polo_th3rd @locielocc #zoogang #40GLOCC #YONJU #zoolife #MUSIC #GUNIT =20 =09=09 [19]=20 =09=09 [20]=20 =09=09 via Instagram [21] on 11.11.13=20 =09=09 [22] =09=09 [27] =20 =09=09 [29]=20 =09=09 [30]=20 =09=09VIA INSTAGRAM [31] ON 11.10.13 =09=09 [32] =09=09 [58] =20 =09 I HEARD ON THE INTERNET IM SCARED OF MY OWN HOOD border-bottom: none">=20 =09 Chk out my homie CALS NEW VIDEO - GOT IT LIKE THAT - OFFICIAL VIDEO=20 http://t.co/eQNRK1ubXV [63] via @youtube =20 =09=09 _1 retweet_ [64]=20 =09=09 [65]=20 =09=09via Twitter [66] on 11.05.13 =09=09 [67] =09MY HOMIE @WARRENG AKA G-DUBB DOIN HIS THANG ON STAGE AT SOULTRAIN AWARDS #SOULTRAINAWARDS #soultrain2013 #soultrainawards2013 #40GLOCC #YONJU #ZOOLIFE #ZOOGANG #LASVEGAS #LasVegas702 =20 =09=09 [68]=20 =09=09 [69]=20 =09=09 via Instagram [70] on 11.09.13=20 =09=09 [71] =09 Funktioning with my homie JAZZYPHAE.. NEW WORK COMING SOON.. IMA BEAST.. MY NEW MUSIC IS…=20 http://t.co/dUZiYRrSDS [72] =20 =09=09 [73]=20 =09=09via Twitter [74] on 11.11.13 =09=09 [75] =09 My Cuzin @sun_days be pissin me off with his driving... #40GLOCC #YONJU #ZOOGANG #ZOOLIFE=20 http://t.co/1l7yJjqo1P [76] =20 =09=09 _1 retweet_ [77]=20 =09=09 [78]=20 =09=09via Twitter [79] on 11.03.13 =09=09 [80] =09T.I. border-bottom: none">=20 =09 I KEEPS IT 100 . & THUS THE MUHAMMED ALI OF MY ERA... MY HOME BOY @floydmayweather border-bottom: none">=20 =09 100... "@regulator: @40GLOCC much love" =20 =09=09 [88]=20 =09=09via Twitter [89] on 11.10.13 =09=09 [90] =09Im in the #soultrainawards kieth sweat goin in lol #40GLOCC #YONJU #ZOOGANG #ZOOLIFE #MUSIC #MUSCLE #FITNESS =20 =09=09 [91]=20 =09=09 [92]=20 =09=09 via Instagram [93] on 11.08.13=20 =09=09 [94] =09 This what my day like fuckin wit the homie @sluggo702 ..at 2pm in the afternoon!!..looks likes its… ... =20 =09=09 [95]=20 =09=09via Twitter [96] on 11.10.13 =09=09 [97] =09 MY HOMIE @regulator AKA G-DUBB DOIN HIS THANG ON STAGE AT SOULTRAIN AWARDS #SOULTRAINAWARDS…=20 http://t.co/Gm9EHc9SvJ [98] =20 =09=09 [99]=20 =09=09via Twitter [100] on 11.09.13 =09=09 [101] =09I DONT EIDE IN NO FUKIN LIMOS THATS A DEATH TRAP.. ID RATHER WALK UP WITH THE REGULAR PEOPLE.. PHUCK HOLLYWIERD SH!T.. #40GLOCC #YONJU #ZOOGANG #MUSIC #ZOOLIFE #WESTCOAST #LASVEGAS #LasVegas702 #SOULTRAINAWARDS #soultrain2013 #soultrainawards2013 =20 =09=09 [102]=20 =09=09 [103]=20 =09=09 via Instagram [104] on 11.08.13=20 =09=09 [105] =09 Im in the #soultrainawards=20 kieth sweat goin in lol #40GLOCC #YONJU #ZOOGANG #ZOOLIFE #MUSIC #MUSCLE…=20 http://t.co/kRVKc816jO [106] =20 =09=09 [107]=20 =09=09via Twitter [108] on 11.09.13 =09=09 [109] =09 LOL NEVER LIKED THEM LOL.. "@CEO_AktiveNLA: @40GLOCC lol real n!ggas have a hard time adjusting to the fame, get to azz ... =20 =09=09 [110]=20 =09=09via Twitter [111] on 11.08.13 =09=09 [112] =09CHECK MY NEW VIDEO OUT ON WWW.WORLDSTAR.COM border-bottom: none">=20 =09 I DONT EIDE IN NO FUKIN LIMOS THATS A DEATH TRAP.. ID RATHER WALK UP WITH THE REGULAR PEOPLE.. PHUCK… ... =20 =09=09 [117]=20 =09=09via Twitter [118] on 11.08.13 =09=09 [119] =09 CHECK MY NEW VIDEO OUT ON=20 http://t.co/JUHC7hJp6o [120] border-bottom: none" colspan=3D"5">=20 =09EARLY MORNING WORKOUT.. BURNING FAT.. WORKING #MUSCLE ..MAKE SURE YALL WISH MY HOMIE @djlexo702 HAPPY B-DAY.. border-bottom: none">=20 =09 NEW** WE BAK AT IT!* Video: 40 Glocc Aka Yon Ju (Feat. Zoo Life) - Hate That=20 http://t.co/XCBDcLKeuG [129] via @worldstar =20 =09=09 [130]=20 =09=09via Twitter [131] on 11.08.13 =09=09 [132] =09 EARLY MORNING WORKOUT.. BURNING FAT.. WORKING #MUSCLE ..MAKE SURE YALL WISH MY HOMIE djlexo702 HAPPY… ... =20 =09=09 [133]=20 =09=09via Twitter [134] on 11.08.13 =09=09 [135] =09FULLY LOADED.. DOWNLOAD THE ARTICLE AND HERE THE TRUTH FROM ME AT PAGE #17..... WWW.XPOZMAG.COM #XPOZ @XPOZ #40GLOCC #MUSIC #MUSCLE #FITNESS #GYM #WORKOUT #GUNIT #INLANDEMPIRE #YONJU #ZOOGANG #ZOOLIFE #WESTCOAST =20 =09=09 [136]=20 =09=09 [137]=20 =09=09 via Instagram [138] on 11.08.13=20 =09=09 [139] =09=09 Unsubscribe [140] | Update Info [141] | Privacy Policy [142]=20 ZOO LIFE ENT. sent this message to freebsd-ipfw@freebsd.org Questions? Contact ZOO LIFE ENT.=20 c/o FanBridge, Inc. - 14525 SW Millikan Way #16910 Beaverton Oregon 97005 United States Powered by: [143] =20 =20 ------ [1][6] http://40GLOCC.fanbridge.com/socialdigest/show.php?sdrid=3D94388&sid=3D1= 76374749 [2] http://facebook.com/125820717478711 [3] http://instagram.com/40glocc [4] https://www.youtube.com/subscription_center?add_user_id=3DRwe0GCrUNFehlS= gGLcy7AQ [5][12][13][16][17][24][25][34][35][38][39][47][48][51][52][60][61][65][= 66][73][74][78][79][85][86][88][89][95][96][99][100][107][108][110][111]= [117][118][122][123][130][131][133][134] http://twitter.com/ [7][8] https://www.spotify.com/?utm_source=3Dspotify_webplayer&utm_medium=3Dmkt= _consumer&utm_campaign=3Dacquisition_magnacarta_email_us&utm_content=3Du= s500616&utm_term=3Demail [9][58] https://play.spotify.com/album/0OTjYdGtP7AbwOwbYsGhyi?utm_source=3Dspoti= fy_webplayer&utm_medium=3Dmkt_consumer&utm_campaign=3Dacquisition_magnac= arta_email_us&utm_content=3Dus500614&utm_term=3Demail [10] http://t.co/MI4PaAedZ1 [11][14] https://twitter.com/#!//status/399528449485705216 [15][18] https://twitter.com/#!//status/399276888444903424 [19][22] http://instagram.com/p/gkVw0UlHXY/ [20][21][42][43][55][56][69][70][82][83][92][93][103][104][114][115][126= ][127][137][138] http://40GLOCC.fanbridge.com [23] https://twitter.com/#!//status/397927892044095488 [26] HTTPS://TWITTER.COM/#!//STATUS/397927892044095488 [27][28] HTTPS://PLAY.SPOTIFY.COM/ALBUM/37UQAKT9DLSLOB7YOMDWY4?UTM_SOURCE=3DSPOTI= FY_WEBPLAYER&UTM_MEDIUM=3DMKT_CONSUMER&UTM_CAMPAIGN=3DACQUISITION_MAGNAC= ARTA_EMAIL_US&UTM_CONTENT=3DUS500615&UTM_TERM=3DEMAIL [29] HTTP://INSTAGRAM.COM/P/GJITRALHFJ/ [30][31] HTTP://40GLOCC.FANBRIDGE.COM [32] http://instagram.com/p/gjiTRalHfj/ [33][36] https://twitter.com/#!//status/399707423096573952 [37][40] https://twitter.com/#!//status/398572666371969025 [41][44] http://instagram.com/p/ghdP19lHX_/ [45] http://t.co/0F3AGkwAS4 [46][49] https://twitter.com/#!//status/398244535412989952 [50][53] https://twitter.com/#!//status/397905851207655424 [54][57] http://instagram.com/p/ghGzfalHUp/ [59][62] https://twitter.com/#!//status/397794668836294656 [63] http://t.co/eQNRK1ubXV [64][67] https://twitter.com/#!//status/397652113523609600 [68][71] http://instagram.com/p/ggggqVFHb1/ [72] http://t.co/dUZiYRrSDS [75] https://twitter.com/#!//status/399705042447769601 [76] http://t.co/1l7yJjqo1P [77][80] https://twitter.com/#!//status/397052826415030272 [81][84] http://instagram.com/p/ggfwZ_FHap/ [87] https://twitter.com/#!//status/399413264557551616 [90] https://twitter.com/#!//status/399510994671529984 [91][94] http://instagram.com/p/gewxw7FHZZ/ [97] https://twitter.com/#!//status/399363339018833921 [98] http://t.co/Gm9EHc9SvJ [101] https://twitter.com/#!//status/399278589579100160 [102][105] http://instagram.com/p/geBJkNFHSt/ [106] http://t.co/kRVKc816jO [109] https://twitter.com/#!//status/399034195424870400 [112] https://twitter.com/#!//status/398952609169412097 [113][116] http://instagram.com/p/gdbW0qFHZ2/ [119] https://twitter.com/#!//status/398930836982341632 [120] http://t.co/JUHC7hJp6o [121] http://t.co/JxWkCbpIHY [124] https://twitter.com/#!//status/398845208080961536 [125][128] http://instagram.com/p/gdCzbOFHaf/ [129] http://t.co/XCBDcLKeuG [132] https://twitter.com/#!//status/398708279338999808 [135] https://twitter.com/#!//status/398792052265467904 [136][139] http://instagram.com/p/gcU2HclHX6/ [140] http://40GLOCC.fanbridge.com/unsubscribe/socialdigest/unsubscribe.php?us= erid=3D63980&sid=3D176374749&confCode=3DX5K1c32rdKBtr9ek5XXB65hrr2&sdrid= =3D94388 [141] http://40GLOCC.fanbridge.com/?userid=3D63980&email=3Dfreebsd-ipfw@freebs= d.org&confCode=3DX5K1c32rdKBtr9ek5XXB65hrr2 [142] http://www.fanbridge.com/privacy.php [143] http://www.fanbridge.com/?src=3Dlogo_footer_sd_v4&utm_source=3Dpowered_b= y&utm_medium=3Demail&utm_campaign=3DSocialDigest From owner-freebsd-ipfw@FreeBSD.ORG Wed Nov 13 02:35:36 2013 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 54CEFF57 for ; Wed, 13 Nov 2013 02:35:36 +0000 (UTC) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 35E1C2B75 for ; Wed, 13 Nov 2013 02:35:36 +0000 (UTC) Received: by mail-pb0-f43.google.com with SMTP id md4so7803501pbc.30 for ; Tue, 12 Nov 2013 18:35:35 -0800 (PST) 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=JVijJVc3TG1jQuMb1rpHyZqp8CWWOxve022ZGHvjQJg=; b=D3oRPFfqGk/eXrl9kib4TKZaTI+UjIf5RznqRZIhpBSVIApZOjQpdMK+CVN7ltNBEo EyyEHTQvd5l+nKiRMEU4DQYelKjN4s6tmIlWVJS1RHBmc4h839J8Vt65N6UVXlRoyqjm IXX2jLqj3gaRL5Mh39X2blwQfvlJlXOSJv8QYsj3CD3+73MRoYVMertFJUbgt/E+pXaH wzOBzQ1Ic38g79P3owuWoocZtSC+D1xOwzkDqPkvO9jZuK6FqRihUYdsyCDMkinzNKw+ QK7tG2E7aSh0DpzHg1Ng8RJ4ZqQb9QrtYZkrWTTw53wes7qb0a0z3LjqKDXyJOHXQiwG PCjg== MIME-Version: 1.0 X-Received: by 10.66.129.141 with SMTP id nw13mr6435794pab.167.1384310135923; Tue, 12 Nov 2013 18:35:35 -0800 (PST) Received: by 10.68.101.98 with HTTP; Tue, 12 Nov 2013 18:35:35 -0800 (PST) Date: Tue, 12 Nov 2013 18:35:35 -0800 Message-ID: Subject: Bursty data transfer with Dummynet From: Ahmed Hamza To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 02:35:36 -0000 Hi All, I'm trying to use Dummynet to test the behaviour of my video streaming application in various network conditions. Dummynet was compiled and installed on an Ubuntu 12.04 box with a 2.6 Linux kernel. I'm experiencing a strange behaviour when I reduce the bandwidth of the link/path. For some reason, instead of having a slow download speed. It seems as if the download is happening in bursts! A portion of the data is downloaded at a high speed, then the data transfer stops for a period of time and then resumes again (and so on). Does anyone have an idea what could be the cause? Or is this even an expected behaviour? If so, why? Thanks, -Ahmed From owner-freebsd-ipfw@FreeBSD.ORG Wed Nov 13 04:25:03 2013 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 A51CA13B for ; Wed, 13 Nov 2013 04:25:03 +0000 (UTC) Received: from c3p0.reverse.net (smtp-1.out.reverse.net [69.162.163.7]) by mx1.freebsd.org (Postfix) with ESMTP id 839A9211F for ; Wed, 13 Nov 2013 04:25:02 +0000 (UTC) Received: from r2d2.reverse.net (smtp-2.out.reverse.net [69.162.167.9]) by c3p0.reverse.net (Postfix) with ESMTP id 3F4517E82D for ; Tue, 12 Nov 2013 22:18:18 -0600 (CST) Received: from [192.168.2.175] (localhost.reverse.net [127.0.0.1]) by r2d2.reverse.net (Postfix) with ESMTP id 0E27CCAB3D for ; Tue, 12 Nov 2013 22:18:12 -0600 (CST) Message-ID: <5282FD85.5030206@gmail.com> Date: Tue, 12 Nov 2013 22:18:13 -0600 From: Matthew McGehrin User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Subject: Re: Bursty data transfer with Dummynet References: 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.16 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 04:25:03 -0000 Without actually seeing your rules, it's hard to diagnose. Ahmed Hamza wrote: > For some reason, instead of having a slow download speed. It seems as > if the download is happening in bursts! A portion of the data is > downloaded at a high speed, then the data transfer stops for a period > of time and then resumes again (and so on). Does anyone have an idea > what could be the cause? Or is this even an expected behaviour? If so, > why? > > From owner-freebsd-ipfw@FreeBSD.ORG Wed Nov 13 05:06:18 2013 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 A82ED693; Wed, 13 Nov 2013 05:06:18 +0000 (UTC) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8123322F7; Wed, 13 Nov 2013 05:06:18 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id y13so5137630pdi.28 for ; Tue, 12 Nov 2013 21:06:17 -0800 (PST) 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 :content-type; bh=tnDkyrBxLWDWcnCFN5Lf9zoIE+Uk8RRF5giTKod6LI8=; b=l/xsvzHSFzH3VJMOmBQIxQLM30PBaIRMZEap/nOzsW52qdCWpxDlT0nN+XhVAKAHuU 2nD2+v/HtvnRGnKNpmI5+rGScu9vLDV7u5V9EwiKUjR4cg6ZbgsjX/jagwvcRsM/VCPW IXe3SYkr2SW8Xg5J79IC9nUuTdAfPnaqZTqYQaMUm2mp9g2pIghj1UZGeGQ9mx7g2xkv 2JRHlHJSIeQSwjbMiXicN1eC2mR1DXhz41a/G9s5lIZ2Ah0lVza2gFSdY9w1E5BuJ+vG +/LSd+SdG0UsojY9dDbiENrTZxG6zijusjet3Mqxh1BlOlNvluj7pvsYmm7zqPZfAVZX 0fbw== MIME-Version: 1.0 X-Received: by 10.68.224.38 with SMTP id qz6mr11958747pbc.156.1384319177470; Tue, 12 Nov 2013 21:06:17 -0800 (PST) Received: by 10.68.101.98 with HTTP; Tue, 12 Nov 2013 21:06:17 -0800 (PST) In-Reply-To: <52830502.30809@freebsd.org> References: <52830502.30809@freebsd.org> Date: Tue, 12 Nov 2013 21:06:17 -0800 Message-ID: Subject: Re: Bursty data transfer with Dummynet From: Ahmed Hamza To: Julian Elischer , freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 05:06:18 -0000 On Tue, Nov 12, 2013 at 8:50 PM, Julian Elischer wrote: > On 11/12/13, 6:35 PM, Ahmed Hamza wrote: >> >> Hi All, >> >> I'm trying to use Dummynet to test the behaviour of my video streaming >> application in various network conditions. Dummynet was compiled and >> installed on an Ubuntu 12.04 box with a 2.6 Linux kernel. I'm >> experiencing a strange behaviour when I reduce the bandwidth of the >> link/path. >> >> For some reason, instead of having a slow download speed. It seems as >> if the download is happening in bursts! A portion of the data is >> downloaded at a high speed, then the data transfer stops for a period >> of time and then resumes again (and so on). Does anyone have an idea >> what could be the cause? Or is this even an expected behaviour? If so, >> why? > > > I can't really speak for dummynet on Linux but the granularity of the queues > is dependent on the timer granularity of the kernel you have and to some > extent will rely on the correct integration of dummynet into the timer > facility of the kernel you are running it in. On freeBSD with a 1kHz 'tick' > I'd' expect to see packets being release from the queue each mSec or so. > if you are getting second sized chunks then it probably is a bug. Either > dummynet is not compatible with that kind of kernel, something else has gone > wrong. It COULD also be that you are catching the wrong packets.. I've seen > similar behaviour when I was accidentally queuing all the acks instead of > all the data going in the other direction, but I presume you have already > checked to see what you are queuing. > Thanks Julian and Matthew for your replies. To clarify my settings, below are the outputs from 'ipfw show' and 'ipfw pipe show'. I should also mention that it seems the by default the Ubuntu kernel is configured for 250Hz, not 1000Hz. root@vm1:~/# ipfw pipe 1 config bw 500Kbit/s queue 500Kbyte root@nsl-vm1:~/# ipfw show 00100 202247 105063701 pipe 1 ip from 192.168.56.4 to any 65535 2245577 2648958386 allow ip from any to any root@nsl-vm1:~/# ipfw pipe show 00001: 500.000 Kbit/s 0 ms 500 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 192.168.56.1/33547 192.168.56.4/80 238083 134515909 0 0 623 From owner-freebsd-ipfw@FreeBSD.ORG Wed Nov 13 05:13:09 2013 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 8FD8E758 for ; Wed, 13 Nov 2013 05:13:09 +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 644BA2348 for ; Wed, 13 Nov 2013 05:13:09 +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 rAD4oFP9076393 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 12 Nov 2013 20:50:17 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <52830502.30809@freebsd.org> Date: Tue, 12 Nov 2013 20:50:10 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ahmed Hamza , freebsd-ipfw@freebsd.org Subject: Re: Bursty data transfer with Dummynet References: 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.16 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 05:13:09 -0000 On 11/12/13, 6:35 PM, Ahmed Hamza wrote: > Hi All, > > I'm trying to use Dummynet to test the behaviour of my video streaming > application in various network conditions. Dummynet was compiled and > installed on an Ubuntu 12.04 box with a 2.6 Linux kernel. I'm > experiencing a strange behaviour when I reduce the bandwidth of the > link/path. > > For some reason, instead of having a slow download speed. It seems as > if the download is happening in bursts! A portion of the data is > downloaded at a high speed, then the data transfer stops for a period > of time and then resumes again (and so on). Does anyone have an idea > what could be the cause? Or is this even an expected behaviour? If so, > why? I can't really speak for dummynet on Linux but the granularity of the queues is dependent on the timer granularity of the kernel you have and to some extent will rely on the correct integration of dummynet into the timer facility of the kernel you are running it in. On freeBSD with a 1kHz 'tick' I'd' expect to see packets being release from the queue each mSec or so. if you are getting second sized chunks then it probably is a bug. Either dummynet is not compatible with that kind of kernel, something else has gone wrong. It COULD also be that you are catching the wrong packets.. I've seen similar behaviour when I was accidentally queuing all the acks instead of all the data going in the other direction, but I presume you have already checked to see what you are queuing. > > Thanks, > -Ahmed > _______________________________________________ > 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 Nov 13 05:21:30 2013 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 CAB128B9 for ; Wed, 13 Nov 2013 05:21:30 +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 92E1323D6 for ; Wed, 13 Nov 2013 05:21:30 +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 rAD5LQF0076477 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 12 Nov 2013 21:21:28 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <52830C51.6020403@freebsd.org> Date: Tue, 12 Nov 2013 21:21:21 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ahmed Hamza , freebsd-ipfw@freebsd.org Subject: Re: Bursty data transfer with Dummynet References: <52830502.30809@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 05:21:30 -0000 On 11/12/13, 9:06 PM, Ahmed Hamza wrote: > On Tue, Nov 12, 2013 at 8:50 PM, Julian Elischer wrote: >> On 11/12/13, 6:35 PM, Ahmed Hamza wrote: >>> Hi All, >>> >>> I'm trying to use Dummynet to test the behaviour of my video streaming >>> application in various network conditions. Dummynet was compiled and >>> installed on an Ubuntu 12.04 box with a 2.6 Linux kernel. I'm >>> experiencing a strange behaviour when I reduce the bandwidth of the >>> link/path. >>> >>> For some reason, instead of having a slow download speed. It seems as >>> if the download is happening in bursts! A portion of the data is >>> downloaded at a high speed, then the data transfer stops for a period >>> of time and then resumes again (and so on). Does anyone have an idea >>> what could be the cause? Or is this even an expected behaviour? If so, >>> why? >> >> I can't really speak for dummynet on Linux but the granularity of the queues >> is dependent on the timer granularity of the kernel you have and to some >> extent will rely on the correct integration of dummynet into the timer >> facility of the kernel you are running it in. On freeBSD with a 1kHz 'tick' >> I'd' expect to see packets being release from the queue each mSec or so. >> if you are getting second sized chunks then it probably is a bug. Either >> dummynet is not compatible with that kind of kernel, something else has gone >> wrong. It COULD also be that you are catching the wrong packets.. I've seen >> similar behaviour when I was accidentally queuing all the acks instead of >> all the data going in the other direction, but I presume you have already >> checked to see what you are queuing. >> > Thanks Julian and Matthew for your replies. To clarify my settings, > below are the outputs from 'ipfw show' and 'ipfw pipe show'. I should > also mention that it seems the by default the Ubuntu kernel is > configured for 250Hz, not 1000Hz. I would expect that that would give a queue kick every 4 mSec or so so you should get a burst every 4mSec or so. but your queue is only doing 500kbit/sec or 1/2kbit /msec, or about 2kbit/4mSec or 250bytes per tick which is less than a packet. I'm afraid you'll have to talk to Luigi to know what happens in such a case.. > root@vm1:~/# ipfw pipe 1 config bw 500Kbit/s queue 500Kbyte > > root@nsl-vm1:~/# ipfw show > 00100 202247 105063701 pipe 1 ip from 192.168.56.4 to any > 65535 2245577 2648958386 allow ip from any to any > > root@nsl-vm1:~/# ipfw pipe show > 00001: 500.000 Kbit/s 0 ms 500 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 192.168.56.1/33547 192.168.56.4/80 238083 134515909 > 0 0 623 > From owner-freebsd-ipfw@FreeBSD.ORG Wed Nov 13 21:29:40 2013 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 2BA1887B; Wed, 13 Nov 2013 21:29:40 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0340420DC; Wed, 13 Nov 2013 21:29:39 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id y10so987893pdj.33 for ; Wed, 13 Nov 2013 13:29:39 -0800 (PST) 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 :content-type; bh=59Ajtp4r8pCbuw0WP7dPq3mjvI4O7YYsOGmA/lvIE6k=; b=n96u2AZbfLHodazzkvIb7LLXItDpQ8aP/gfP3oUhEUDZte2dvKP7rLCnXW98HUVkhP kKM6ozXANamYrMrhEbsEGgsM8MA/GUrrz5vqLKCC23Ifl6qYS/ZQcsr+wkF22K8UH053 Bh4ZkCa2O/mtudtpI9ABE222WHwbZa5eDeskwFas/OVzh9OP2mKEBbO4UdD66E/0VRo7 +3Jv+CO8WlPZRB9jAz/aIO58Afz9FqoJSGZ21HMbJs76ljEPwpTJ7trPaVqEXiHBmN+Z bOBbPhUzKmHtFRwoxh1O6J8/sGQjwcPkIcUTDAfbLlzmFeTQOhnwX7GoqBuZWFvrOShP akLA== MIME-Version: 1.0 X-Received: by 10.66.129.141 with SMTP id nw13mr11160563pab.167.1384378179610; Wed, 13 Nov 2013 13:29:39 -0800 (PST) Received: by 10.68.101.98 with HTTP; Wed, 13 Nov 2013 13:29:39 -0800 (PST) In-Reply-To: <52830C51.6020403@freebsd.org> References: <52830502.30809@freebsd.org> <52830C51.6020403@freebsd.org> Date: Wed, 13 Nov 2013 13:29:39 -0800 Message-ID: Subject: Re: Bursty data transfer with Dummynet From: Ahmed Hamza To: Julian Elischer , freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 21:29:40 -0000 I'm not sure if this would explain anything. But I am running DummyNet on a VirtualBox VM on an Ubuntu host. I have also experienced the same behaviour with both Frenzy (a FreeBSD based LiveCD) and Ubuntu guests. In the case of Frenzy, the tick was set to 1000Hz. But the host tick was 250Hz since it is an Ubuntu machine. Also, the delay between bursts is in order of seconds! My assumption about DummyNet is that while the queue is being drained new packets will be queued (i.e. there is no waiting to fill the queues before transmitting them using the specified bandwidth). On Tue, Nov 12, 2013 at 9:21 PM, Julian Elischer wrote: > On 11/12/13, 9:06 PM, Ahmed Hamza wrote: >> >> On Tue, Nov 12, 2013 at 8:50 PM, Julian Elischer >> wrote: >>> >>> On 11/12/13, 6:35 PM, Ahmed Hamza wrote: >>>> >>>> Hi All, >>>> >>>> I'm trying to use Dummynet to test the behaviour of my video streaming >>>> application in various network conditions. Dummynet was compiled and >>>> installed on an Ubuntu 12.04 box with a 2.6 Linux kernel. I'm >>>> experiencing a strange behaviour when I reduce the bandwidth of the >>>> link/path. >>>> >>>> For some reason, instead of having a slow download speed. It seems as >>>> if the download is happening in bursts! A portion of the data is >>>> downloaded at a high speed, then the data transfer stops for a period >>>> of time and then resumes again (and so on). Does anyone have an idea >>>> what could be the cause? Or is this even an expected behaviour? If so, >>>> why? >>> >>> >>> I can't really speak for dummynet on Linux but the granularity of the >>> queues >>> is dependent on the timer granularity of the kernel you have and to some >>> extent will rely on the correct integration of dummynet into the timer >>> facility of the kernel you are running it in. On freeBSD with a 1kHz >>> 'tick' >>> I'd' expect to see packets being release from the queue each mSec or so. >>> if you are getting second sized chunks then it probably is a bug. Either >>> dummynet is not compatible with that kind of kernel, something else has >>> gone >>> wrong. It COULD also be that you are catching the wrong packets.. I've >>> seen >>> similar behaviour when I was accidentally queuing all the acks instead of >>> all the data going in the other direction, but I presume you have already >>> checked to see what you are queuing. >>> >> Thanks Julian and Matthew for your replies. To clarify my settings, >> below are the outputs from 'ipfw show' and 'ipfw pipe show'. I should >> also mention that it seems the by default the Ubuntu kernel is >> configured for 250Hz, not 1000Hz. > > I would expect that that would give a queue kick every 4 mSec or so so you > should get a burst every 4mSec or so. > but your queue is only doing 500kbit/sec or 1/2kbit /msec, or about > 2kbit/4mSec or 250bytes per tick which is less than a packet. I'm afraid > you'll have to talk to Luigi to know what happens in such a case.. > > >> root@vm1:~/# ipfw pipe 1 config bw 500Kbit/s queue 500Kbyte >> >> root@nsl-vm1:~/# ipfw show >> 00100 202247 105063701 pipe 1 ip from 192.168.56.4 to any >> 65535 2245577 2648958386 allow ip from any to any >> >> root@nsl-vm1:~/# ipfw pipe show >> 00001: 500.000 Kbit/s 0 ms 500 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 192.168.56.1/33547 192.168.56.4/80 238083 134515909 >> 0 0 623 >> > From owner-freebsd-ipfw@FreeBSD.ORG Wed Nov 13 23:03:13 2013 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 5167E32F; Wed, 13 Nov 2013 23:03:13 +0000 (UTC) Received: from data.snhdns.com (data.snhdns.com [208.76.82.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0D84327E0; Wed, 13 Nov 2013 23:03:12 +0000 (UTC) Received: from [142.46.160.217] (port=57320 helo=[206.51.1.11]) by data.snhdns.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VgipQ-0000zM-QW; Wed, 13 Nov 2013 17:22:29 -0500 Message-ID: <5283FBBA.8090702@dilkie.com> Date: Wed, 13 Nov 2013 17:22:50 -0500 From: Lee Dilkie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ahmed Hamza , Julian Elischer , freebsd-ipfw@freebsd.org Subject: Re: Bursty data transfer with Dummynet References: <52830502.30809@freebsd.org> <52830C51.6020403@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.6 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - data.snhdns.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dilkie.com X-Get-Message-Sender-Via: data.snhdns.com: authenticated_id: lee@dilkie.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.16 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 23:03:13 -0000 seriously? you expect that kind of precise timing running in a VM? -lee On 11/13/2013 16:29, Ahmed Hamza wrote: > I'm not sure if this would explain anything. But I am running DummyNet > on a VirtualBox VM on an Ubuntu host. I have also experienced the same > behaviour with both Frenzy (a FreeBSD based LiveCD) and Ubuntu guests. > In the case of Frenzy, the tick was set to 1000Hz. But the host tick > was 250Hz since it is an Ubuntu machine. Also, the delay between > bursts is in order of seconds! My assumption about DummyNet is that > while the queue is being drained new packets will be queued (i.e. > there is no waiting to fill the queues before transmitting them using > the specified bandwidth). > > On Tue, Nov 12, 2013 at 9:21 PM, Julian Elischer wrote: >> On 11/12/13, 9:06 PM, Ahmed Hamza wrote: >>> On Tue, Nov 12, 2013 at 8:50 PM, Julian Elischer >>> wrote: >>>> On 11/12/13, 6:35 PM, Ahmed Hamza wrote: >>>>> Hi All, >>>>> >>>>> I'm trying to use Dummynet to test the behaviour of my video streaming >>>>> application in various network conditions. Dummynet was compiled and >>>>> installed on an Ubuntu 12.04 box with a 2.6 Linux kernel. I'm >>>>> experiencing a strange behaviour when I reduce the bandwidth of the >>>>> link/path. >>>>> >>>>> For some reason, instead of having a slow download speed. It seems as >>>>> if the download is happening in bursts! A portion of the data is >>>>> downloaded at a high speed, then the data transfer stops for a period >>>>> of time and then resumes again (and so on). Does anyone have an idea >>>>> what could be the cause? Or is this even an expected behaviour? If so, >>>>> why? >>>> >>>> I can't really speak for dummynet on Linux but the granularity of the >>>> queues >>>> is dependent on the timer granularity of the kernel you have and to some >>>> extent will rely on the correct integration of dummynet into the timer >>>> facility of the kernel you are running it in. On freeBSD with a 1kHz >>>> 'tick' >>>> I'd' expect to see packets being release from the queue each mSec or so. >>>> if you are getting second sized chunks then it probably is a bug. Either >>>> dummynet is not compatible with that kind of kernel, something else has >>>> gone >>>> wrong. It COULD also be that you are catching the wrong packets.. I've >>>> seen >>>> similar behaviour when I was accidentally queuing all the acks instead of >>>> all the data going in the other direction, but I presume you have already >>>> checked to see what you are queuing. >>>> >>> Thanks Julian and Matthew for your replies. To clarify my settings, >>> below are the outputs from 'ipfw show' and 'ipfw pipe show'. I should >>> also mention that it seems the by default the Ubuntu kernel is >>> configured for 250Hz, not 1000Hz. >> I would expect that that would give a queue kick every 4 mSec or so so you >> should get a burst every 4mSec or so. >> but your queue is only doing 500kbit/sec or 1/2kbit /msec, or about >> 2kbit/4mSec or 250bytes per tick which is less than a packet. I'm afraid >> you'll have to talk to Luigi to know what happens in such a case.. >> >> >>> root@vm1:~/# ipfw pipe 1 config bw 500Kbit/s queue 500Kbyte >>> >>> root@nsl-vm1:~/# ipfw show >>> 00100 202247 105063701 pipe 1 ip from 192.168.56.4 to any >>> 65535 2245577 2648958386 allow ip from any to any >>> >>> root@nsl-vm1:~/# ipfw pipe show >>> 00001: 500.000 Kbit/s 0 ms 500 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 192.168.56.1/33547 192.168.56.4/80 238083 134515909 >>> 0 0 623 >>> > _______________________________________________ > 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 Nov 14 03:41:12 2013 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 7F44C4B1 for ; Thu, 14 Nov 2013 03:41:12 +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 47B3F288A for ; Thu, 14 Nov 2013 03:41:11 +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 rAE3exNI079850 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 13 Nov 2013 19:41:02 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <52844646.2020802@freebsd.org> Date: Wed, 13 Nov 2013 19:40:54 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Lee Dilkie , Ahmed Hamza , freebsd-ipfw@freebsd.org Subject: Re: Bursty data transfer with Dummynet References: <52830502.30809@freebsd.org> <52830C51.6020403@freebsd.org> <5283FBBA.8090702@dilkie.com> In-Reply-To: <5283FBBA.8090702@dilkie.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.16 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 03:41:12 -0000 On 11/13/13, 2:22 PM, Lee Dilkie wrote: > seriously? > > you expect that kind of precise timing running in a VM? the fact that it is in a vm only just came out... still I'd expect better than "several seconds".. > > -lee > > On 11/13/2013 16:29, Ahmed Hamza wrote: >> I'm not sure if this would explain anything. But I am running DummyNet >> on a VirtualBox VM on an Ubuntu host. I have also experienced the same >> behaviour with both Frenzy (a FreeBSD based LiveCD) and Ubuntu guests. >> In the case of Frenzy, the tick was set to 1000Hz. But the host tick >> was 250Hz since it is an Ubuntu machine. Also, the delay between >> bursts is in order of seconds! My assumption about DummyNet is that >> while the queue is being drained new packets will be queued (i.e. >> there is no waiting to fill the queues before transmitting them using >> the specified bandwidth). >> >> On Tue, Nov 12, 2013 at 9:21 PM, Julian Elischer wrote: >>> On 11/12/13, 9:06 PM, Ahmed Hamza wrote: >>>> On Tue, Nov 12, 2013 at 8:50 PM, Julian Elischer >>>> wrote: >>>>> On 11/12/13, 6:35 PM, Ahmed Hamza wrote: >>>>>> Hi All, >>>>>> >>>>>> I'm trying to use Dummynet to test the behaviour of my video streaming >>>>>> application in various network conditions. Dummynet was compiled and >>>>>> installed on an Ubuntu 12.04 box with a 2.6 Linux kernel. I'm >>>>>> experiencing a strange behaviour when I reduce the bandwidth of the >>>>>> link/path. >>>>>> >>>>>> For some reason, instead of having a slow download speed. It seems as >>>>>> if the download is happening in bursts! A portion of the data is >>>>>> downloaded at a high speed, then the data transfer stops for a period >>>>>> of time and then resumes again (and so on). Does anyone have an idea >>>>>> what could be the cause? Or is this even an expected behaviour? If so, >>>>>> why? >>>>> I can't really speak for dummynet on Linux but the granularity of the >>>>> queues >>>>> is dependent on the timer granularity of the kernel you have and to some >>>>> extent will rely on the correct integration of dummynet into the timer >>>>> facility of the kernel you are running it in. On freeBSD with a 1kHz >>>>> 'tick' >>>>> I'd' expect to see packets being release from the queue each mSec or so. >>>>> if you are getting second sized chunks then it probably is a bug. Either >>>>> dummynet is not compatible with that kind of kernel, something else has >>>>> gone >>>>> wrong. It COULD also be that you are catching the wrong packets.. I've >>>>> seen >>>>> similar behaviour when I was accidentally queuing all the acks instead of >>>>> all the data going in the other direction, but I presume you have already >>>>> checked to see what you are queuing. >>>>> >>>> Thanks Julian and Matthew for your replies. To clarify my settings, >>>> below are the outputs from 'ipfw show' and 'ipfw pipe show'. I should >>>> also mention that it seems the by default the Ubuntu kernel is >>>> configured for 250Hz, not 1000Hz. >>> I would expect that that would give a queue kick every 4 mSec or so so you >>> should get a burst every 4mSec or so. >>> but your queue is only doing 500kbit/sec or 1/2kbit /msec, or about >>> 2kbit/4mSec or 250bytes per tick which is less than a packet. I'm afraid >>> you'll have to talk to Luigi to know what happens in such a case.. >>> >>> >>>> root@vm1:~/# ipfw pipe 1 config bw 500Kbit/s queue 500Kbyte >>>> >>>> root@nsl-vm1:~/# ipfw show >>>> 00100 202247 105063701 pipe 1 ip from 192.168.56.4 to any >>>> 65535 2245577 2648958386 allow ip from any to any >>>> >>>> root@nsl-vm1:~/# ipfw pipe show >>>> 00001: 500.000 Kbit/s 0 ms 500 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 192.168.56.1/33547 192.168.56.4/80 238083 134515909 >>>> 0 0 623 >>>> >> _______________________________________________ >> 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 Nov 14 04:06:50 2013 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 ECBC1859; Thu, 14 Nov 2013 04:06:50 +0000 (UTC) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3552929A6; Thu, 14 Nov 2013 04:06:50 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id w6so1104347lbh.13 for ; Wed, 13 Nov 2013 20:06:48 -0800 (PST) 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=OQL6fGZSbztS4yjj4RVoOyZNkxk0uLHTmAZIXTtr+v4=; b=Zd00aZhO8H/eXTa2xoynT/PM8/jOnDGAorZgg7hvzLemiaeXYEAZaPIPrNL+6qaqKp 1H2brEyKmwa6kmsd95ipeyTNCFi+z0iMiRsIPB75XtUY073QW+KZJlX6V5Y+8FE+8Zgy bqOhjlMC+m16NSndUgzL+mrGixfWdbzVxAfz1u8RebjFD/aeEnmT1C2w3DEVt3F+pWvr an/ogvu313rinqy5NxeOOVtsFkkrxb4QnxtDbpLovsJsqMkf/5eTtmIaue1wMqsYGGv3 FvrPBUkGcAv/MdZWObtcABd6Bznq4Z0vsLjDar31VGiRxhn1iAn+gc4uFoJLPuNz1k40 fGvA== MIME-Version: 1.0 X-Received: by 10.152.225.129 with SMTP id rk1mr128027lac.74.1384402008074; Wed, 13 Nov 2013 20:06:48 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.23.35 with HTTP; Wed, 13 Nov 2013 20:06:48 -0800 (PST) In-Reply-To: References: <52830502.30809@freebsd.org> Date: Thu, 14 Nov 2013 05:06:48 +0100 X-Google-Sender-Auth: jmogSPHiXnECpj1gDSpUH6idqj0 Message-ID: Subject: Re: Bursty data transfer with Dummynet From: Luigi Rizzo To: Ahmed Hamza Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-ipfw@freebsd.org, Julian Elischer X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 04:06:51 -0000 On Wed, Nov 13, 2013 at 6:06 AM, Ahmed Hamza wrote: > On Tue, Nov 12, 2013 at 8:50 PM, Julian Elischer > wrote: > > On 11/12/13, 6:35 PM, Ahmed Hamza wrote: > >> > >> Hi All, > >> > >> I'm trying to use Dummynet to test the behaviour of my video streaming > >> application in various network conditions. Dummynet was compiled and > >> installed on an Ubuntu 12.04 box with a 2.6 Linux kernel. I'm > >> experiencing a strange behaviour when I reduce the bandwidth of the > >> link/path. > >> > >> For some reason, instead of having a slow download speed. It seems as > >> if the download is happening in bursts! A portion of the data is > >> downloaded at a high speed, then the data transfer stops for a period > >> of time and then resumes again (and so on). Does anyone have an idea > >> what could be the cause? Or is this even an expected behaviour? If so, > >> why? > > > > > > I can't really speak for dummynet on Linux but the granularity of the > queues > > is dependent on the timer granularity of the kernel you have and to some > > extent will rely on the correct integration of dummynet into the timer > > facility of the kernel you are running it in. On freeBSD with a 1kHz > 'tick' > > I'd' expect to see packets being release from the queue each mSec or so. > > if you are getting second sized chunks then it probably is a bug. Either > > dummynet is not compatible with that kind of kernel, something else has > gone > > wrong. It COULD also be that you are catching the wrong packets.. I've > seen > > similar behaviour when I was accidentally queuing all the acks instead of > > all the data going in the other direction, but I presume you have already > > checked to see what you are queuing. > > > > Thanks Julian and Matthew for your replies. To clarify my settings, > below are the outputs from 'ipfw show' and 'ipfw pipe show'. I should > also mention that it seems the by default the Ubuntu kernel is > configured for 250Hz, not 1000Hz. > > root@vm1:~/# ipfw pipe 1 config bw 500Kbit/s queue 500Kbyte > > root@nsl-vm1:~/# ipfw show > 00100 202247 105063701 pipe 1 ip from 192.168.56.4 to any > 65535 2245577 2648958386 allow ip from any to any > > root@nsl-vm1:~/# ipfw pipe show > 00001: 500.000 Kbit/s 0 ms 500 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 192.168.56.1/33547 192.168.56.4/80 238083 134515909 > 0 0 623 > to debug the problem i'd first try removing/reducing the queue size, because you are queueing 8 seconds of data and that may interact badly with whatever flow control protocol you have implemented (even if you are using tcp underneath, you might have some logic in your app that decides when to send, etc.) Also, try to start with a very high bandwidth and gradually reduce it and see if there is a point where behaviour suddenly changes. As julian pointed out, dummynet works on a tick, but at the rates you are using the granularity should not matter much. And, to answer another poster, modern hardware is pretty good at running VMs with millisecond or less ticks. cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Thu Nov 14 11:40:04 2013 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 9FC65C12 for ; Thu, 14 Nov 2013 11:40:04 +0000 (UTC) Received: from c3p0.reverse.net (smtp-1.out.reverse.net [69.162.163.8]) by mx1.freebsd.org (Postfix) with ESMTP id 8155622E3 for ; Thu, 14 Nov 2013 11:40:03 +0000 (UTC) Received: from [192.168.2.175] (localhost.reverse.net [127.0.0.1]) by c3p0.reverse.net (Postfix) with ESMTP id 2FFB97E82D for ; Thu, 14 Nov 2013 05:29:08 -0600 (CST) Message-ID: <5284B405.7070008@gmail.com> Date: Thu, 14 Nov 2013 05:29:09 -0600 From: Matthew McGehrin User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Subject: Re: Bursty data transfer with Dummynet References: <52830502.30809@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.16 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 11:40:04 -0000 Your queue is too large, 500K is a lot. The default is 50 slots. 100 slots usually works well as well. I would try first: ipfw pipe 1 config bw 500k -- Matthew Ahmed Hamza wrote: > Thanks Julian and Matthew for your replies. To clarify my settings, > below are the outputs from 'ipfw show' and 'ipfw pipe show'. I should > also mention that it seems the by default the Ubuntu kernel is > configured for 250Hz, not 1000Hz. > > root@vm1:~/# ipfw pipe 1 config bw 500Kbit/s queue 500Kbyte > > > From owner-freebsd-ipfw@FreeBSD.ORG Fri Nov 15 08:34:16 2013 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 A6BFE4E6 for ; Fri, 15 Nov 2013 08:34:16 +0000 (UTC) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1AA962751 for ; Fri, 15 Nov 2013 08:34:15 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id y6so2437295lbh.5 for ; Fri, 15 Nov 2013 00:34:14 -0800 (PST) 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=Tpc9C0jLpw5PFiA4ccApLhwQd02KpYUr6ulGUpdYSCA=; b=u1S0+WYgLak1rBhDViU9HzEQOiCzw8jsDT7NPirSBVkqttNX9tMZ7I8ziAy3phurpB rXLMYVH6+1wg4x1b7WQka5ly9Z9Q2cQ8dXTr5T2UFpoq+9LhlUdmjacmcWgnkD7rVxzI SJsc8zoVs9Dbc+5celAxsilaTmzmhwkBbHQLlteyou+B5B839T8enNgMMdY1k0kDtjTE szV3Gnugo0zcHJ23MdWim/MpLslyDQvWXJBgTBbGmL5Egt5JG+KAk6Wa1c8KUzSEsSVZ FaQgOgki4+82rNwEZgNR5/W6Na37NXLdVGUoiceXTIKrFxLcyF69ZqoD2e2bfLHFbCxD PZvw== MIME-Version: 1.0 X-Received: by 10.152.4.230 with SMTP id n6mr3398699lan.1.1384504454137; Fri, 15 Nov 2013 00:34:14 -0800 (PST) Received: by 10.112.188.169 with HTTP; Fri, 15 Nov 2013 00:34:14 -0800 (PST) Date: Fri, 15 Nov 2013 10:34:14 +0200 Message-ID: Subject: ipfw inline rules From: salih ahi To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 08:34:16 -0000 I have two virtual machines running on VMware with bridge mode network interfaces. I want one of them (FreeBSD) to act as a gateway between the host OS and another VM, which also has bridge interfaces On the FreeBSD machine, I have the following rules installed # tried these rules also with keep-state, nothing changed.. ipfw -q add 00500 divert 44444 log ip from any to any via em2 in ipfw -q add 00510 divert 44444 log ip from any to any via em1 in ip addresses for these interfaces are: em2: 192.168.1.118 em1: 192.168.2.118 This machine stands between a client and server, I want the packets from these two machines to be diverted to my program which listens from a divert socket. client ip is 10.41.1.31 and server has 10.41.2.121. To see if these rules are working correctly, I drop (simply not inject back) every packet with payloads, so TCP handshake should be completed but actual data will not be transmitted When I try to connect the https server from client, I see following lines in /var/log/security Oct 25 16:58:52 legyndir kernel: ipfw: 510 Divert 44444 TCP 10.41.2.121:443 10.41.1.31:15590 in via em1 Oct 25 16:58:52 legyndir kernel: ipfw: 600 Accept TCP 10.41.2.121:443 10.41.1.31:15590 in via em1 Oct 25 16:58:52 legyndir kernel: ipfw: 600 Accept TCP 10.41.2.121:443 10.41.1.31:15590 out via em2 Oct 25 16:58:52 legyndir kernel: ipfw: 500 Divert 44444 TCP 10.41.1.31:15590 10.41.2.121:443 in via em2 Oct 25 16:58:52 legyndir kernel: ipfw: 600 Accept TCP 10.41.1.31:15590 10.41.2.121:443 in via em2 Oct 25 16:58:52 legyndir kernel: ipfw: 600 Accept TCP 10.41.1.31:15590 10.41.2.121:443 out via em1 Oct 25 16:58:52 legyndir kernel: ipfw: 500 Divert 44444 TCP 10.41.1.31:15590 10.41.2.121:443 in via em2 How is it possible that the first records belongs to a packet originating from the server to client and not vice versa? Also, how can the same originating/destination address pairs on the same network interface - as seen on the first two lines- match two different ipfw rules, 510 and 600? And although I only allow packets with payloads to get through in my program, when I run tcpdump on the server, I see packets coming with data: 16:23:31.146387 IP 10.41.1.31.21745 > 10.41.2.121.443: Flags [S], seq 1703311588, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 16:23:31.175457 IP 10.41.2.121.443 > 10.41.1.31.21745: Flags [S.], seq 2000005748, ack 1703311589, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 16:23:31.176048 IP 10.41.2.121.443 > 10.41.1.31.21745: Flags [S.], seq 2000005748, ack 1703311589, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 16:23:31.176167 IP 10.41.1.31.21745 > 10.41.2.121.443: Flags [.], ack 1, win 16425, length 0 16:23:31.176391 IP 10.41.1.31.21745 > 10.41.2.121.443: Flags [.], ack 1, win 16425, length 0 16:23:31.177656 IP 10.41.1.31.21745 > 10.41.2.121.443: Flags [P.], seq 1:195, ack 1, win 16425, length 194 16:23:31.178011 IP 10.41.2.121.443 > 10.41.1.31.21745: Flags [.], ack 195, win 123, length 0 What am I missing here?? From owner-freebsd-ipfw@FreeBSD.ORG Fri Nov 15 20:27:08 2013 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 478A48F6; Fri, 15 Nov 2013 20:27:08 +0000 (UTC) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1EC0D2321; Fri, 15 Nov 2013 20:27:08 +0000 (UTC) Received: by mail-pd0-f175.google.com with SMTP id w10so1826343pde.20 for ; Fri, 15 Nov 2013 12:27:07 -0800 (PST) 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=452VKZ9p+eILaKVHtgyuMTHVaR41n1FeFC6XUsXyMlE=; b=asESPvJXA4I9TFZ8tFB1FC5SVW6rzmpxE1o18Krbhl4/DIzadjp887UoRDh9n+NVzs 4C7NxCJwxeN/o+DIgFYmgT8th91BzZnIofwmlQKad9iU2Yq818v4MJdz+wKM80hSq9Bl rXqZcj+lp8c5ARr+9nWTdlAE5gv+Wxa7URQA9SrGYxiDX99PCiImLBBZGj64GPUuZbSQ dj6UUXsX6yOLpL6YxuXhH10aU8DtdlSQ09MZ3I8yy+DcCkz4bVOCmSiFIjhnuPmctPOc ecbYHq4MVTvlNJp5MZy2yeGcgPWTtZnzZPgjot+uaCo7RhdWv3vp7KDjXtAGVMdAWhpO j8bg== MIME-Version: 1.0 X-Received: by 10.68.193.131 with SMTP id ho3mr992960pbc.81.1384547227470; Fri, 15 Nov 2013 12:27:07 -0800 (PST) Received: by 10.68.101.98 with HTTP; Fri, 15 Nov 2013 12:27:07 -0800 (PST) In-Reply-To: References: <52830502.30809@freebsd.org> Date: Fri, 15 Nov 2013 12:27:07 -0800 Message-ID: Subject: Re: Bursty data transfer with Dummynet From: Ahmed Hamza To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-ipfw@freebsd.org, Julian Elischer X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 20:27:08 -0000 Thank you Luigi and Julian. I believe I figured it out. It was totally my bad. I configured Dummynet with the default queue size (50 slots) and a very high bandwidth on the FreeBSD LiveCD as Luigi suggested, and everything was working. Then I realized what the problem was. I'm testing an adaptive streaming application in which the bitrate (and consequently size) of the requested data changes based on bandwidth estimation. For some reason there is a problem with my bandwidth estimation logic and the returned value is an overestimation. Therefore it takes time to fill up the application buffers and the buffered content are played back quickly. There are no bursts during the download process itself. I haven't tried the Ubuntu guest again yet. But I will check it to see the effect of having a kernel configured with 250Hz. -Ahmed On Wed, Nov 13, 2013 at 8:06 PM, Luigi Rizzo wrote: > > > > On Wed, Nov 13, 2013 at 6:06 AM, Ahmed Hamza wrote: >> >> On Tue, Nov 12, 2013 at 8:50 PM, Julian Elischer >> wrote: >> > On 11/12/13, 6:35 PM, Ahmed Hamza wrote: >> >> >> >> Hi All, >> >> >> >> I'm trying to use Dummynet to test the behaviour of my video streaming >> >> application in various network conditions. Dummynet was compiled and >> >> installed on an Ubuntu 12.04 box with a 2.6 Linux kernel. I'm >> >> experiencing a strange behaviour when I reduce the bandwidth of the >> >> link/path. >> >> >> >> For some reason, instead of having a slow download speed. It seems as >> >> if the download is happening in bursts! A portion of the data is >> >> downloaded at a high speed, then the data transfer stops for a period >> >> of time and then resumes again (and so on). Does anyone have an idea >> >> what could be the cause? Or is this even an expected behaviour? If so, >> >> why? >> > >> > >> > I can't really speak for dummynet on Linux but the granularity of the >> > queues >> > is dependent on the timer granularity of the kernel you have and to some >> > extent will rely on the correct integration of dummynet into the timer >> > facility of the kernel you are running it in. On freeBSD with a 1kHz >> > 'tick' >> > I'd' expect to see packets being release from the queue each mSec or so. >> > if you are getting second sized chunks then it probably is a bug. Either >> > dummynet is not compatible with that kind of kernel, something else has >> > gone >> > wrong. It COULD also be that you are catching the wrong packets.. I've >> > seen >> > similar behaviour when I was accidentally queuing all the acks instead >> > of >> > all the data going in the other direction, but I presume you have >> > already >> > checked to see what you are queuing. >> > >> >> Thanks Julian and Matthew for your replies. To clarify my settings, >> below are the outputs from 'ipfw show' and 'ipfw pipe show'. I should >> also mention that it seems the by default the Ubuntu kernel is >> configured for 250Hz, not 1000Hz. >> >> root@vm1:~/# ipfw pipe 1 config bw 500Kbit/s queue 500Kbyte >> >> root@nsl-vm1:~/# ipfw show >> 00100 202247 105063701 pipe 1 ip from 192.168.56.4 to any >> 65535 2245577 2648958386 allow ip from any to any >> >> root@nsl-vm1:~/# ipfw pipe show >> 00001: 500.000 Kbit/s 0 ms 500 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 192.168.56.1/33547 192.168.56.4/80 238083 134515909 >> 0 0 623 > > > to debug the problem i'd first try removing/reducing the queue size, > because you are queueing 8 seconds of data and that may interact > badly with whatever flow control protocol you have implemented > (even if you are using tcp underneath, you might have some logic > in your app that decides when to send, etc.) > > Also, try to start with a very high bandwidth and gradually > reduce it and see if there is a point where behaviour suddenly changes. > > As julian pointed out, dummynet works on a tick, but at the rates > you are using the granularity should not matter much. > > And, to answer another poster, modern hardware is pretty good at > running VMs with millisecond or less ticks. > > cheers > luigi >