From owner-freebsd-net@FreeBSD.ORG Sun Dec 3 03:09:06 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4EDA616A403 for ; Sun, 3 Dec 2006 03:09:06 +0000 (UTC) (envelope-from ask@develooper.com) Received: from x8.develooper.com (x8.develooper.com [216.52.237.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10DF943CA2 for ; Sun, 3 Dec 2006 03:08:42 +0000 (GMT) (envelope-from ask@develooper.com) Received: (qmail 4720 invoked from network); 3 Dec 2006 03:09:05 -0000 Received: from dsl081-039-130.lax1.dsl.speakeasy.net (HELO ?10.50.0.20?) (ask@cleverpeople.org@64.81.39.130) by smtp.develooper.com with (AES128-SHA encrypted) SMTP; 3 Dec 2006 03:09:05 -0000 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <0B1CC4E4-DEBA-4E72-9ADD-FBFA4F1B7EC8@develooper.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-net@freebsd.org From: =?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?= Date: Sat, 2 Dec 2006 19:09:03 -0800 X-Mailer: Apple Mail (2.752.3) Subject: poor fastforwarding and polling performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2006 03:09:06 -0000 Hi, I'm playing with the settings for some PC Engines WRAP cards[1] (sis interfaces) that acts as mini routers on relatively slow networks. I am testing with iperf from two Linux boxes (that are plugged directly into an interface each on the FreeBSD box). The IP addresses used for the routing are managed by CARP, does that make a difference? Without polling or fastforwarding I get ~25-40Mbit throughput (~25Mbit with pf, ~40Mbit with pf disabled). (During this the box is completely unresponsive on the console). With fastforwarding I get ~7-15Mbit (!) With polling (ifconfig sis0 polling; ifconfig sis1 polling) I get about 1.5-2Mbit (pf doesn't make a difference). If I enable both fastforwarding and polling I seem to get slightly better results, but still Not Good. The only upside is that with polling enabled the box stays responsive, but it not much help. :-) Any ideas? - ask [1] http://www.pcengines.ch/wrap.htm -- http://develooper.com/ - http://askask.com/ From owner-freebsd-net@FreeBSD.ORG Mon Dec 4 00:10:59 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0993416A417 for ; Mon, 4 Dec 2006 00:10:59 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2674643CAD for ; Mon, 4 Dec 2006 00:10:24 +0000 (GMT) (envelope-from mike@sentex.net) Received: from BLUELAPIS.sentex.ca (cage.simianscience.com [64.7.134.1]) by smarthost2.sentex.ca (8.13.8/8.13.8) with SMTP id kB40AiH2019849; Sun, 3 Dec 2006 19:10:44 -0500 (EST) (envelope-from mike@sentex.net) From: Mike Tancsa To: =?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?= Date: Sun, 03 Dec 2006 19:11:20 -0500 Message-ID: <2kp6n2tl4tnrj6s10mt41ei0b6h1jvt0fs@4ax.com> References: <0B1CC4E4-DEBA-4E72-9ADD-FBFA4F1B7EC8@develooper.com> In-Reply-To: <0B1CC4E4-DEBA-4E72-9ADD-FBFA4F1B7EC8@develooper.com> X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: poor fastforwarding and polling performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2006 00:10:59 -0000 On Sat, 2 Dec 2006 19:09:03 -0800, in sentex.lists.freebsd.net you wrote: > >With polling (ifconfig sis0 polling; ifconfig sis1 polling) I get =20 >about 1.5-2Mbit (pf doesn't make a difference). =46or Polling, set kern.polling.idle_poll=3D1 Also, try removing options ADAPTIVE_GIANT # Giant mutex is adaptive. and adding options NO_ADAPTIVE_MUTEXES from the kernel. This should help a little with the non fast_forwarding case. ---Mike -------------------------------------------------------- Mike Tancsa, Sentex communications http://www.sentex.net Providing Internet Access since 1994 mike@sentex.net, (http://www.tancsa.com) From owner-freebsd-net@FreeBSD.ORG Mon Dec 4 06:37:42 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0ACDE16A412 for ; Mon, 4 Dec 2006 06:37:42 +0000 (UTC) (envelope-from weiwu@sdf.lonestar.org) Received: from bossdog.realss.com (bossdog.realss.com [211.157.108.128]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F51F43CA2 for ; Mon, 4 Dec 2006 06:37:10 +0000 (GMT) (envelope-from weiwu@sdf.lonestar.org) Received: from localhost (unknown [127.0.0.1]) by bossdog.realss.com (Postfix) with ESMTP id 7CB501C00D6 for ; Mon, 4 Dec 2006 14:37:53 +0800 (CST) Received: from bossdog.realss.com ([127.0.0.1]) by localhost (bossdog.realss.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09377-12 for ; Mon, 4 Dec 2006 14:37:51 +0800 (CST) Received: from [218.193.55.195] (unknown [218.85.104.43]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by bossdog.realss.com (Postfix) with ESMTP id DDB994C8F40 for ; Mon, 4 Dec 2006 14:37:50 +0800 (CST) From: =?UTF-8?Q?=E5=BC=A0=E9=9F=A1=E6=AD=A6?= To: freebsd-net@freebsd.org Content-Type: text/plain Date: Mon, 04 Dec 2006 14:37:34 +0800 Message-Id: <1165214254.14766.22.camel@joe.realss.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at bossdog.realss.com Subject: cannot read windows share X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2006 06:37:42 -0000 Using FreeBSD 6.1, I can mount a windows share but the Chinese characters in folder and file names look junk text to me. Charset conversion (-E parameter of mount_smbfs) do not work at all. If I do ls(1) to a directory that has Chinese character in its name, the process 'ls' will take about 80% CPU resource and hang there forever. Ctrl+C cannot stop it (kill -KILL can). If I run other command that read any file in the directory that has Chinese character in its name, that application hangs there taking about 80% CPU resource too. This process is better illustrated with this screenshot: gopher://sdf.lonestar.org/I/users/weiwu/mount_chinese_smbshare.png In the screenshot, I do have mounted the share with -E parameter which should convert GB18030 folder names to UTF-8 but actually no conversion is done (see the ls | iconv which shows what it should be looking like if the conversion is done) Actually I have never successfully done charset conversion with mount_smbfs, what did I do wrong? From owner-freebsd-net@FreeBSD.ORG Mon Dec 4 08:03:35 2006 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9361A16A508 for ; Mon, 4 Dec 2006 08:03:35 +0000 (UTC) (envelope-from rabbiu@datagroup.de) Received: from tacdepot.com (2Cust16.dub2.alter.net [62.125.89.16]) by mx1.FreeBSD.org (Postfix) with SMTP id 144D143CA3 for ; Mon, 4 Dec 2006 08:02:53 +0000 (GMT) (envelope-from rabbiu@datagroup.de) Message-ID: <01c71772$5d9b06e0$2101a8c0@kofd> Date: Mon, 4 Dec 2006 08:03:56 +0100 X-MSMail-Priority: Normal X-Priority: 3 From: "Edweena Dewar" To: MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_000C_01C71779.96EEC2E0" Content-Location: http://seek2.zootseek.com/d4/body2.html X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: paravan runu X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Edweena Dewar List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2006 08:03:35 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C71779.96EEC2E0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable dear, welcome. I would stand to greet you, but only with difficulty. turned back and spread his arms wide. We were slammed back into our seats and were on our way. High and You have to close your gob. Look at these orders. Do as instructed. The elevator they hustled me to had not been marked on the map issued Nothing important, I sand, stifling a yawn at the unimportance of beginning when the explosion occurred. End of report. never can. the male sex. I would appreciate samples from your associates. was in the open long enough for a brief transmission. It looks alien enough to be alien, I said. Looking at it was ------=_NextPart_000_000C_01C71779.96EEC2E0-- From owner-freebsd-net@FreeBSD.ORG Mon Dec 4 11:08:50 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 92A8E16A51C for ; Mon, 4 Dec 2006 11:08:50 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAAD743CC0 for ; Mon, 4 Dec 2006 11:07:58 +0000 (GMT) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kB4B8Uq4045446 for ; Mon, 4 Dec 2006 11:08:30 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kB4B8Scm045441 for freebsd-net@FreeBSD.org; Mon, 4 Dec 2006 11:08:28 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Dec 2006 11:08:28 GMT Message-Id: <200612041108.kB4B8Scm045441@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2006 11:08:50 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue o kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit 4 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19875 net A new protocol family, PF_IPOPTION, to handle IP optio o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] IP Encapsulation mask_match() returns wrong o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n 9 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Dec 4 15:13:41 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 06CB216A47C for ; Mon, 4 Dec 2006 15:13:41 +0000 (UTC) (envelope-from m.jakeman@lancaster.ac.uk) Received: from pigwidgeon.lancs.ac.uk (pigwidgeon.lancs.ac.uk [148.88.0.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 462CB43CA8 for ; Mon, 4 Dec 2006 15:13:06 +0000 (GMT) (envelope-from m.jakeman@lancaster.ac.uk) Received: from mail01.lancs.ac.uk ([148.88.1.53] helo=marl.lancs.ac.uk) by pigwidgeon.lancs.ac.uk with esmtp (Exim 4.60) (envelope-from ) id 1GrFVj-0003B5-0t for freebsd-net@freebsd.org; Mon, 04 Dec 2006 15:13:39 +0000 Received: from ina044000004.lancs.ac.uk ([148.88.224.46]) by marl.lancs.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1GrFVe-0002Jj-DS for freebsd-net@freebsd.org; Mon, 04 Dec 2006 15:13:34 +0000 From: Matthew Jakeman Organization: Lancaster University To: freebsd-net@freebsd.org Date: Mon, 4 Dec 2006 15:01:00 +0000 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612041501.00968.m.jakeman@lancaster.ac.uk> Subject: RFC 3095 - Robust Header Compression Implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: m.jakeman@lancaster.ac.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2006 15:13:41 -0000 Hi all, Is there an implementation of RFC3095, Robust Header Compression, available for FreeBSD? Thanks Matt From owner-freebsd-net@FreeBSD.ORG Tue Dec 5 10:04:11 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CBE4E16A415 for ; Tue, 5 Dec 2006 10:04:11 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF20543CA3 for ; Tue, 5 Dec 2006 10:03:32 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id kB5A481D061918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Dec 2006 13:04:08 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id kB5A47S0061917; Tue, 5 Dec 2006 13:04:07 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 5 Dec 2006 13:04:07 +0300 From: Gleb Smirnoff To: Ari Suutari Message-ID: <20061205100407.GB32700@cell.sick.ru> References: <200612041538.kB4FcQjk073583@freefall.freebsd.org> <0eaa01c71835$f12055f0$6602a8c0@sad.syncrontech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <0eaa01c71835$f12055f0$6602a8c0@sad.syncrontech.com> User-Agent: Mutt/1.5.6i Cc: net@FreeBSD.org Subject: Re: kern/104377: [carp] [patch] CARP interface doesn't go up on VmWare X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2006 10:04:11 -0000 On Tue, Dec 05, 2006 at 08:23:50AM +0200, Ari Suutari wrote: A> Hi, A> A> OK, what would then be the right fix to get things working A> under vmware ? I run a bunch of servers here and some of A> them are redundant pairs. We have some pressure to virtualize A> those servers, but we cannot do it as the carp does not work. A> A> I don't really get it why the link state is so important here, as A> to my understanding carp works in similar as vrrp, using A> heartbeats ? Also, the current state of matters is more confusing, A> since you can get the carp interface up by issuing another A> "ifconfig up" (people suggested this to me, but I cannot accept A> that a system providing redundancy requires this kind of kludgery) A> A> I can accept that my solution is not the correct one, but A> it is a little hard to accept turning it down without A> giving any suggestion how to really fix things. When one created a redundant routers, he enables CARP an all interfaces of the router. Imagine, that one interface goes down, but CARP doesn't notice that and keeps claiming to be the master on the other interfaces. Traffic comes to it, and it sends it to downed interface. If interface, that went down, had reported its state then CARP would had noticed that and would had lowered its priority, gave up mastering, and became backup. This will be redundant. A> ----- Original Message ----- A> From: "Gleb Smirnoff" A> To: ; ; A> A> Sent: Monday, December 04, 2006 5:38 PM A> Subject: Re: kern/104377: [carp] [patch] CARP interface doesn't go up on A> VmWare A> A> A> >Synopsis: [carp] [patch] CARP interface doesn't go up on VmWare A> > A> >State-Changed-From-To: open->closed A> >State-Changed-By: glebius A> >State-Changed-When: Mon Dec 4 15:34:00 UTC 2006 A> >State-Changed-Why: A> >I am sorry, but I am not going to commit this patch. Let me explain. A> >CARP is not going to work properly on interfaces that do not report A> >its state being changed. The proposed patch will change CARP behavior A> >to be pretending to work when interface doesn't support reporting A> >its link state. I think it is better to refuse to work earlier, then A> >pretend to be working but don't provide any redundancy. The proposed A> >patch is going to confuse people. A> > A> >http://www.freebsd.org/cgi/query-pr.cgi?pr=104377 -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Dec 5 10:31:00 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2AE2B16A494; Tue, 5 Dec 2006 10:31:00 +0000 (UTC) (envelope-from ari.suutari@syncrontech.com) Received: from espresso2.syncrontech.com (sync-old.syncrontech.com [213.28.98.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF12843CA3; Tue, 5 Dec 2006 10:29:57 +0000 (GMT) (envelope-from ari.suutari@syncrontech.com) Received: from guinness.syncrontech.com (guinness.syncrontech.com [62.71.8.57]) by espresso2.syncrontech.com (8.13.1/8.13.1) with ESMTP id kB5AUYwl084391; Tue, 5 Dec 2006 12:30:34 +0200 (EET) (envelope-from ari.suutari@syncrontech.com) Received: from coffee (asatest1.syncrontech.com [62.71.8.41]) by guinness.syncrontech.com (8.13.4/8.13.4) with SMTP id kB5AUXvC010745; Tue, 5 Dec 2006 12:30:33 +0200 (EET) (envelope-from ari.suutari@syncrontech.com) Message-ID: <100a01c71858$64b1efc0$6602a8c0@sad.syncrontech.com> From: "Ari Suutari" To: "Gleb Smirnoff" References: <200612041538.kB4FcQjk073583@freefall.freebsd.org> <0eaa01c71835$f12055f0$6602a8c0@sad.syncrontech.com> <20061205100407.GB32700@cell.sick.ru> Date: Tue, 5 Dec 2006 12:30:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="KOI8-R"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Cc: net@FreeBSD.org Subject: Re: kern/104377: [carp] [patch] CARP interface doesn't go up on VmWare X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2006 10:31:00 -0000 Hi, > On Tue, Dec 05, 2006 at 08:23:50AM +0200, Ari Suutari wrote: > A> Hi, > A> > A> OK, what would then be the right fix to get things working > A> under vmware ? I run a bunch of servers here and some of > A> them are redundant pairs. We have some pressure to virtualize > A> those servers, but we cannot do it as the carp does not work. > A> > A> I don't really get it why the link state is so important here, as > A> to my understanding carp works in similar as vrrp, using > A> heartbeats ? Also, the current state of matters is more confusing, > A> since you can get the carp interface up by issuing another > A> "ifconfig up" (people suggested this to me, but I cannot accept > A> that a system providing redundancy requires this kind of kludgery) > A> > A> I can accept that my solution is not the correct one, but > A> it is a little hard to accept turning it down without > A> giving any suggestion how to really fix things. > > When one created a redundant routers, he enables CARP an all > interfaces of the router. Imagine, that one interface goes down, > but CARP doesn't notice that and keeps claiming to be the master > on the other interfaces. Traffic comes to it, and it sends it to > downed interface. Doesn't the other machine notice this from the absense of hearbeat on that interface ? I thought that this could combined with net.inet.carp.preempt sysctl to force carp to fail over the other interfaces in this case also. If this doesn't work then you are right; I really didn't test this under vmware (I should have tested it, of course). > > If interface, that went down, had reported its state then CARP > would had noticed that and would had lowered its priority, > gave up mastering, and became backup. This will be redundant. Is it impossible to add link state reporting to lnc driver ? I think this would be the perfect fix and acceptable by everyone. Ari S. > > A> ----- Original Message ----- > A> From: "Gleb Smirnoff" > A> To: ; ; > A> > A> Sent: Monday, December 04, 2006 5:38 PM > A> Subject: Re: kern/104377: [carp] [patch] CARP interface doesn't go up on > A> VmWare > A> > A> > A> >Synopsis: [carp] [patch] CARP interface doesn't go up on VmWare > A> > > A> >State-Changed-From-To: open->closed > A> >State-Changed-By: glebius > A> >State-Changed-When: Mon Dec 4 15:34:00 UTC 2006 > A> >State-Changed-Why: > A> >I am sorry, but I am not going to commit this patch. Let me explain. > A> >CARP is not going to work properly on interfaces that do not report > A> >its state being changed. The proposed patch will change CARP behavior > A> >to be pretending to work when interface doesn't support reporting > A> >its link state. I think it is better to refuse to work earlier, then > A> >pretend to be working but don't provide any redundancy. The proposed > A> >patch is going to confuse people. > A> > > A> >http://www.freebsd.org/cgi/query-pr.cgi?pr=104377 > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > > From owner-freebsd-net@FreeBSD.ORG Tue Dec 5 10:48:37 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 616B016A407 for ; Tue, 5 Dec 2006 10:48:37 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2FC143CB5 for ; Tue, 5 Dec 2006 10:47:56 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id kB5AmXwU062197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Dec 2006 13:48:33 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id kB5AmWnv062196; Tue, 5 Dec 2006 13:48:33 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 5 Dec 2006 13:48:32 +0300 From: Gleb Smirnoff To: Ari Suutari Message-ID: <20061205104832.GD32700@cell.sick.ru> References: <200612041538.kB4FcQjk073583@freefall.freebsd.org> <0eaa01c71835$f12055f0$6602a8c0@sad.syncrontech.com> <20061205100407.GB32700@cell.sick.ru> <100a01c71858$64b1efc0$6602a8c0@sad.syncrontech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <100a01c71858$64b1efc0$6602a8c0@sad.syncrontech.com> User-Agent: Mutt/1.5.6i Cc: net@FreeBSD.org Subject: Re: kern/104377: [carp] [patch] CARP interface doesn't go up on VmWare X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2006 10:48:37 -0000 On Tue, Dec 05, 2006 at 12:30:27PM +0200, Ari Suutari wrote: A> >A> OK, what would then be the right fix to get things working A> >A> under vmware ? I run a bunch of servers here and some of A> >A> them are redundant pairs. We have some pressure to virtualize A> >A> those servers, but we cannot do it as the carp does not work. A> >A> A> >A> I don't really get it why the link state is so important here, as A> >A> to my understanding carp works in similar as vrrp, using A> >A> heartbeats ? Also, the current state of matters is more confusing, A> >A> since you can get the carp interface up by issuing another A> >A> "ifconfig up" (people suggested this to me, but I cannot accept A> >A> that a system providing redundancy requires this kind of kludgery) A> >A> A> >A> I can accept that my solution is not the correct one, but A> >A> it is a little hard to accept turning it down without A> >A> giving any suggestion how to really fix things. A> > A> >When one created a redundant routers, he enables CARP an all A> >interfaces of the router. Imagine, that one interface goes down, A> >but CARP doesn't notice that and keeps claiming to be the master A> >on the other interfaces. Traffic comes to it, and it sends it to A> >downed interface. A> A> Doesn't the other machine notice this from the absense of hearbeat A> on that interface ? I thought that this could combined with A> net.inet.carp.preempt sysctl to force carp to fail over the A> other interfaces in this case also. If this doesn't work then you A> are right; I really didn't test this under vmware (I should A> have tested it, of course). Yes, it will notice this and claim mastering on the downed net. However it will fail to get mastering on the other nets. A> >If interface, that went down, had reported its state then CARP A> >would had noticed that and would had lowered its priority, A> >gave up mastering, and became backup. This will be redundant. A> A> Is it impossible to add link state reporting to lnc driver ? A> I think this would be the perfect fix and acceptable by A> everyone. You are 100% right :) -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Dec 5 13:31:54 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B274E16A501; Tue, 5 Dec 2006 13:31:54 +0000 (UTC) (envelope-from ari.suutari@syncrontech.com) Received: from espresso2.syncrontech.com (sync-old.syncrontech.com [213.28.98.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0896B43CEA; Tue, 5 Dec 2006 13:23:27 +0000 (GMT) (envelope-from ari.suutari@syncrontech.com) Received: from guinness.syncrontech.com (guinness.syncrontech.com [62.71.8.57]) by espresso2.syncrontech.com (8.13.1/8.13.1) with ESMTP id kB5DNU3U084985; Tue, 5 Dec 2006 15:23:30 +0200 (EET) (envelope-from ari.suutari@syncrontech.com) Received: from coffee (asatest1.syncrontech.com [62.71.8.41]) by guinness.syncrontech.com (8.13.4/8.13.4) with SMTP id kB5DNSN1013725; Tue, 5 Dec 2006 15:23:30 +0200 (EET) (envelope-from ari.suutari@syncrontech.com) Message-ID: <000801c71870$8d9192c0$6602a8c0@sad.syncrontech.com> From: "Ari Suutari" To: "Gleb Smirnoff" References: <200612041538.kB4FcQjk073583@freefall.freebsd.org> <0eaa01c71835$f12055f0$6602a8c0@sad.syncrontech.com> <20061205100407.GB32700@cell.sick.ru> <100a01c71858$64b1efc0$6602a8c0@sad.syncrontech.com> <20061205104832.GD32700@cell.sick.ru> Date: Tue, 5 Dec 2006 15:23:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Cc: net@FreeBSD.org Subject: Re: kern/104377: [carp] [patch] CARP interface doesn't go up on VmWare X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2006 13:31:54 -0000 Hi, > A> >If interface, that went down, had reported its state then CARP > A> >would had noticed that and would had lowered its priority, > A> >gave up mastering, and became backup. This will be redundant. > A> > A> Is it impossible to add link state reporting to lnc driver ? > A> I think this would be the perfect fix and acceptable by > A> everyone. > > You are 100% right :) I hope not on this being impossible :-) Ari S. From owner-freebsd-net@FreeBSD.ORG Tue Dec 5 16:48:55 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2548D16A412 for ; Tue, 5 Dec 2006 16:48:55 +0000 (UTC) (envelope-from freebsdworld@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A49943CA5 for ; Tue, 5 Dec 2006 16:48:10 +0000 (GMT) (envelope-from freebsdworld@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so257258nfc for ; Tue, 05 Dec 2006 08:48:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=JQZ61oUY9RpksMWeW/pAdzSL32sOGGH1GOEYIrv0aWnDPZpJkeHWXA4p44v2nFggycf7cybjZtbObyuLrLrMRDFZ2ctGVwrSf6fW/zklHWtowyB2A9ulNlI8ImlcTFK/R32KKreIWIeMWajxTTHCXs+J1e4NhGNYPlUlrYNbBF8= Received: by 10.82.141.4 with SMTP id o4mr1761119bud.1165337330016; Tue, 05 Dec 2006 08:48:50 -0800 (PST) Received: by 10.82.107.7 with HTTP; Tue, 5 Dec 2006 08:48:49 -0800 (PST) Message-ID: <6199c3dc0612050848g16a0911dga145485ba14bf21f@mail.gmail.com> Date: Tue, 5 Dec 2006 11:48:49 -0500 From: "Benjamin Adams" To: freebsd-net@freebsd.org, freebsd-chat@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Bandwidth Monitoring program X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2006 16:48:55 -0000 I'm on a network that has a normal store firewall, setup as a NAT. I'm trying to find a way to monitor all bandwidth by clients through that firewall. I don't have the ability to just put an inline box to examine packets. Is there a program where I can see whats going on from the computer on that network. What I'm looking for is: client ip : 2.3 GB List of ports used in bandwidth amounts. Thanks for any help, Ben Adams From owner-freebsd-net@FreeBSD.ORG Tue Dec 5 17:45:21 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D9C7F16A403 for ; Tue, 5 Dec 2006 17:45:21 +0000 (UTC) (envelope-from nomadlogic@gmail.com) Received: from nz-out-0102.google.com (nz-out-0506.google.com [64.233.162.233]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36D7943C9D for ; Tue, 5 Dec 2006 17:44:41 +0000 (GMT) (envelope-from nomadlogic@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so2080133nzh for ; Tue, 05 Dec 2006 09:45:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sVAXWkgqNKdRBTbszvOFFrzxF0BrZUYVEqejFOQNDqGQtbdpm9bcJLmkQti/z+3JlAE/oNNQe/Pm+VHx5gRHoioGiPTqlOrG41EdqcTqjqX+IfDfTSQb3sTZaFFCh3kq70RjN6PLp8gmGO+Yf4J/B6lzJi+XXIf4qEtaGjiXR2Q= Received: by 10.78.21.7 with SMTP id 7mr9175720huu.1165340719507; Tue, 05 Dec 2006 09:45:19 -0800 (PST) Received: by 10.78.195.14 with HTTP; Tue, 5 Dec 2006 09:45:19 -0800 (PST) Message-ID: <57d710000612050945j2b1f7240mdcb58bc5afd2839e@mail.gmail.com> Date: Tue, 5 Dec 2006 09:45:19 -0800 From: "pete wright" To: "Benjamin Adams" In-Reply-To: <6199c3dc0612050848g16a0911dga145485ba14bf21f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6199c3dc0612050848g16a0911dga145485ba14bf21f@mail.gmail.com> Cc: freebsd-net@freebsd.org, freebsd-chat@freebsd.org Subject: Re: Bandwidth Monitoring program X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2006 17:45:21 -0000 On 12/5/06, Benjamin Adams wrote: > I'm on a network that has a normal store firewall, setup as a NAT. I'm > trying to find a way to monitor all bandwidth by clients through that > firewall. I don't have the ability to just put an inline box to examine > packets. Is there a program where I can see whats going on from the > computer on that network. > > What I'm looking for is: > client ip : 2.3 GB > List of ports used in bandwidth amounts. > hard to tell with out knowing what you are running as a gateway/router but I would look into using some sort of SNMP script to gather that info and plot it out. A lot of people use MRTG, i've recently starting using Cacti (www.cacti.net) to help implement this. HTH -pete -- ~~o0OO0o~~ Pete Wright www.nycbug.org NYC's *BSD User Group From owner-freebsd-net@FreeBSD.ORG Tue Dec 5 17:58:03 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A474416A416 for ; Tue, 5 Dec 2006 17:58:03 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.200.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEF3943CA2 for ; Tue, 5 Dec 2006 17:57:22 +0000 (GMT) (envelope-from josh@tcbug.org) Received: from gimpy (failure[24.118.173.219]) by comcast.net (sccrmhc14) with ESMTP id <20061205175802014006im7ge>; Tue, 5 Dec 2006 17:58:02 +0000 From: Josh Paetzel To: freebsd-net@freebsd.org Date: Tue, 5 Dec 2006 11:57:27 -0600 User-Agent: KMail/1.9.4 References: <6199c3dc0612050848g16a0911dga145485ba14bf21f@mail.gmail.com> <57d710000612050945j2b1f7240mdcb58bc5afd2839e@mail.gmail.com> In-Reply-To: <57d710000612050945j2b1f7240mdcb58bc5afd2839e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612051157.28177.josh@tcbug.org> Cc: pete wright , Benjamin Adams Subject: Re: Bandwidth Monitoring program X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2006 17:58:03 -0000 On Tuesday 05 December 2006 11:45, pete wright wrote: > On 12/5/06, Benjamin Adams wrote: > > I'm on a network that has a normal store firewall, setup as a > > NAT. I'm trying to find a way to monitor all bandwidth by > > clients through that firewall. I don't have the ability to just > > put an inline box to examine packets. Is there a program where I > > can see whats going on from the computer on that network. > > > > What I'm looking for is: > > client ip : 2.3 GB > > List of ports used in bandwidth amounts. > > hard to tell with out knowing what you are running as a > gateway/router but I would look into using some sort of SNMP script > to gather that info and plot it out. A lot of people use MRTG, > i've recently starting using Cacti (www.cacti.net) to help > implement this. > > HTH > -pete In response to your question, the answer basically lies in your networking gear. If you are using a hub you could put a computer on the network into promiscuous mode and use any number of tools to track bandwidth usage. If you have a switched network then you are going to need to gather info on the router itself. SNMP would be the logical choice if the router is capable of running it. You could then poll SNMP from a computer on the network and use any number of tools to analyze/graph the usage. (MRTG and rrdtool being a couple of popular ones) -- Thanks, Josh Paetzel From owner-freebsd-net@FreeBSD.ORG Tue Dec 5 18:52:25 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7095B16A407; Tue, 5 Dec 2006 18:52:25 +0000 (UTC) (envelope-from joe@joeholden.co.uk) Received: from claire.ber.rewt.org.uk (claire.ber.rewt.org.uk [217.160.200.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 780ED43CA3; Tue, 5 Dec 2006 18:51:44 +0000 (GMT) (envelope-from joe@joeholden.co.uk) Received: from localhost (unknown [127.0.0.1]) by claire.ber.rewt.org.uk (Postfix) with ESMTP id 7FE7E5CA9; Tue, 5 Dec 2006 18:52:23 +0000 (GMT) X-Virus-Scanned: amavisd-new at claire.ber.rewt.org.uk Received: from claire.ber.rewt.org.uk ([127.0.0.1]) by localhost (claire.ber.rewt.org.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpz-AgLrsjit; Tue, 5 Dec 2006 18:52:20 +0000 (GMT) Received: from [62.84.172.67] (dsl172-67.as6911.net [62.84.172.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by claire.ber.rewt.org.uk (Postfix) with ESMTP id 6EF665CA5; Tue, 5 Dec 2006 18:52:20 +0000 (GMT) Message-ID: <4575BFE2.6060601@joeholden.co.uk> Date: Tue, 05 Dec 2006 18:52:18 +0000 From: Joe Holden User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Benjamin Adams References: <6199c3dc0612050848g16a0911dga145485ba14bf21f@mail.gmail.com> In-Reply-To: <6199c3dc0612050848g16a0911dga145485ba14bf21f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-chat@freebsd.org Subject: Re: Bandwidth Monitoring program X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: joe@joeholden.co.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2006 18:52:25 -0000 Benjamin Adams wrote: > I'm on a network that has a normal store firewall, setup as a NAT. I'm > trying to find a way to monitor all bandwidth by clients through that > firewall. I don't have the ability to just put an inline box to examine > packets. Is there a program where I can see whats going on from the > computer on that network. > > What I'm looking for is: > client ip : 2.3 GB > List of ports used in bandwidth amounts. > > > Thanks for any help, > Ben Adams Take a look at "bandwidthd," it's in ports HTH, Joe From owner-freebsd-net@FreeBSD.ORG Tue Dec 5 20:29:57 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D038616A403; Tue, 5 Dec 2006 20:29:57 +0000 (UTC) (envelope-from fbsd-net@mawer.org) Received: from mail-ihug.icp-qv1-irony2.iinet.net.au (ihug-mail.icp-qv1-irony2.iinet.net.au [203.59.1.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AB4143DB6; Tue, 5 Dec 2006 20:27:49 +0000 (GMT) (envelope-from fbsd-net@mawer.org) Received: from 203-206-173-235.perm.iinet.net.au (HELO [10.24.1.1]) ([203.206.173.235]) by mail-ihug.icp-qv1-irony2.iinet.net.au with ESMTP; 06 Dec 2006 04:28:25 +0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAOBkdUXLzq3r/2dsb2JhbAAN X-IronPort-AV: i="4.09,501,1157299200"; d="scan'208"; a="724819712:sNHT18747036" Message-ID: <4575D610.702@mawer.org> Date: Wed, 06 Dec 2006 07:26:56 +1100 From: Antony Mawer User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Gleb Smirnoff References: <200612041538.kB4FcQjk073583@freefall.freebsd.org> <0eaa01c71835$f12055f0$6602a8c0@sad.syncrontech.com> <20061205100407.GB32700@cell.sick.ru> <100a01c71858$64b1efc0$6602a8c0@sad.syncrontech.com> <20061205104832.GD32700@cell.sick.ru> In-Reply-To: <20061205104832.GD32700@cell.sick.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: net@FreeBSD.org, Ari Suutari Subject: Re: kern/104377: [carp] [patch] CARP interface doesn't go up on VmWare X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2006 20:29:57 -0000 On 5/12/2006 9:48 PM, Gleb Smirnoff wrote: > On Tue, Dec 05, 2006 at 12:30:27PM +0200, Ari Suutari wrote: > A> >If interface, that went down, had reported its state then CARP > A> >would had noticed that and would had lowered its priority, > A> >gave up mastering, and became backup. This will be redundant. > A> > A> Is it impossible to add link state reporting to lnc driver ? > A> I think this would be the perfect fix and acceptable by > A> everyone. > > You are 100% right :) If you are running VMware 5.x, then you can use the em driver (Intel Pro/1000) instead, which is far more functional than the lnc driver. To do so: 1. Shutdown the VMware system 2. Locate the *.vmx file for your virtual machine 3. Open the *.vmx file in your favourite text editor 4. Add the following line: ethernet0.virtualDev = "e1000" 5. Save the file, and re-open the VM in VMware 6. Enjoy a more functional NIC under VMware! Cheers Antony From owner-freebsd-net@FreeBSD.ORG Wed Dec 6 05:52:47 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2758916A412; Wed, 6 Dec 2006 05:52:47 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3260F43C9D; Wed, 6 Dec 2006 05:52:03 +0000 (GMT) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id WAA04850; Tue, 5 Dec 2006 22:52:40 -0700 (MST) Message-Id: <200612060552.WAA04850@lariat.net> X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 05 Dec 2006 22:52:34 -0700 To: "Benjamin Adams" , freebsd-net@freebsd.org, freebsd-chat@freebsd.org From: Brett Glass In-Reply-To: <6199c3dc0612050848g16a0911dga145485ba14bf21f@mail.gmail.co m> References: <6199c3dc0612050848g16a0911dga145485ba14bf21f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-avg-checked=avg-ok-4213473 Cc: Subject: Re: Bandwidth Monitoring program X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2006 05:52:47 -0000 Add a few IPFW "count" rules to count the bytes and packets. Then, periodically harvest and reset the counters via a cron job and write the results to a file. You can then prepare tables and charts which are as simple or as fancy as you please, without resorting to SNMP (which isn't secure). A little bit of code in your favorite scripting language will do it. And of course you can output to a graphing package, though for me a simple histogram using asterisks has sufficient precision in most cases. --Brett Glass At 09:48 AM 12/5/2006, Benjamin Adams wrote: >I'm on a network that has a normal store firewall, setup as a NAT. I'm >trying to find a way to monitor all bandwidth by clients through that >firewall. I don't have the ability to just put an inline box to examine >packets. Is there a program where I can see whats going on from the >computer on that network. > >What I'm looking for is: >client ip : 2.3 GB >List of ports used in bandwidth amounts. > > >Thanks for any help, >Ben Adams >_______________________________________________ >freebsd-chat@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-chat >To unsubscribe, send any mail to "freebsd-chat-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Dec 6 08:55:46 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E04EB16A417; Wed, 6 Dec 2006 08:55:46 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 926B243DCA; Wed, 6 Dec 2006 08:53:25 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id kB68s2eF070132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Dec 2006 11:54:02 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id kB68s1F7070131; Wed, 6 Dec 2006 11:54:01 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Wed, 6 Dec 2006 11:54:01 +0300 From: Gleb Smirnoff To: oleg@freebsd.org, net@freebsd.org Message-ID: <20061206085401.GH32700@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.6i Cc: MQ Subject: [antinvidia@gmail.com: some questions about bge(4)] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2006 08:55:47 -0000 Forwarding to net@ list and to Oleg, who has made polling support for bge(4). ----- Forwarded message from MQ ----- From: MQ To: glebius@freebsd.org, davidch@broadcom.com Subject: some questions about bge(4) Date: Sat, 2 Dec 2006 09:32:27 +0000 Delivered-To: glebius@freebsd.org DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=ZL3ZZ1zR0mt4LaUN2Rr+jXTPSzQgJYRwLiwKnv95r2UCEids5Wl7oA2BNgicJ2QRG8OalJ7DqY7lM1HBgv0OVTlXOhGQ9aFmKQAuTNi6ueZA817XUacXyViEepnj0oNyYgAnkbaaBO1+nl2Fpb3IxV+MIe575WRlqbglF8kdOek= Hi David and Gleb, I'm using several chips whose driver is bge(4). And now I have some questions about the driver, would you please an answer for me? My confusion is related with some codes in /sys/dev/mii/brgphy.c. The bge(4) uses the callout to drive the watchdog. And the brgphy_service() is called once per second. It calls brgphy_mii_phy_auto() every 5 seconds to autonegotiate the media. Normally, it costs about 0.5ms in the first function brgphy_service(), and about 5ms when autonegotiation is proceeded. I haven't done streestest on it, consequently I don't know if this delay will cause packets to be dropped. But I've enabled device polling with the bge(4) on FreeBSD 6.1-RELEASE. If HZ is set to a high value(e.g. 4000), this delay will cause the kern.polling.lost_polls to increase by one or two every second. And for about five seconds, the lost poll will increase by at least 16 regularly. So I think this behavior has some impact on the systems that enables device polling. Could we get something to make the bge(4) a bit more friendly to the device polling? I don't know if autonegotiation is really needed to be called so frequently when we are connected to a good network environment. Can I modify the interval between two autonegotiations to have less lost_polls? However, I have no idea about the long time spent in the brgphy_service(), please take a look at the problem when you have enough time. Regards MQ ----- End forwarded message ----- -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Dec 6 09:13:26 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0CF1716A407 for ; Wed, 6 Dec 2006 09:13:26 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.200.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72A3E43CAA for ; Wed, 6 Dec 2006 09:12:41 +0000 (GMT) (envelope-from josh@tcbug.org) Received: from gimpy (c-24-118-173-219.hsd1.mn.comcast.net[24.118.173.219]) by comcast.net (sccrmhc14) with ESMTP id <20061206091324014006dcere>; Wed, 6 Dec 2006 09:13:24 +0000 From: Josh Paetzel To: freebsd-net@freebsd.org Date: Wed, 6 Dec 2006 03:13:23 -0600 User-Agent: KMail/1.9.4 References: <6199c3dc0612050848g16a0911dga145485ba14bf21f@mail.gmail.com> <200612060552.WAA04850@lariat.net> In-Reply-To: <200612060552.WAA04850@lariat.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612060313.23621.josh@tcbug.org> Cc: Brett Glass , Benjamin Adams Subject: Re: Bandwidth Monitoring program X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2006 09:13:26 -0000 On Tuesday 05 December 2006 23:52, Brett Glass wrote: > Add a few IPFW "count" rules to count the bytes and packets. Then, > periodically harvest and reset the counters via a cron job and > write the results to a file. You can then prepare tables and charts > which are as simple or as fancy as you please, without resorting to > SNMP (which isn't secure). A little bit of code in your favorite > scripting language will do it. And of course you can output to a > graphing package, though for me a simple histogram using asterisks > has sufficient precision in most cases. > > --Brett Glass > Just curious.....but where is he going to run ipfw? I seriously doubt his router can run it, and what good is it going to do him to run it on a machine on the network if the network is switched? It's not going to be able to see any of the traffic other than what that specific machine is sending/receiving. -- Thanks, Josh Paetzel From owner-freebsd-net@FreeBSD.ORG Wed Dec 6 15:09:41 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E702A16A40F for ; Wed, 6 Dec 2006 15:09:41 +0000 (UTC) (envelope-from maillist.ifiaas@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5146243CAB for ; Wed, 6 Dec 2006 15:08:55 +0000 (GMT) (envelope-from maillist.ifiaas@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so552641nfc for ; Wed, 06 Dec 2006 07:09:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=azemAcJPt6VJ97wfCXrl3kFONowcAZL/tKMPUys9frfdWtRh2LTWMVbtCFTSSYQZlMSLm6H4FsVl7j44bCzVNF5+X1A1cwVApFzB3geZrW3pY/0SzD7jI46FA8gm0B0jXu6rReurk9Xws/Vw2xCO3iiOWN+cVHpE/Wm9nHmbB44= Received: by 10.49.7.10 with SMTP id k10mr2319235nfi.1165417779605; Wed, 06 Dec 2006 07:09:39 -0800 (PST) Received: by 10.48.242.15 with HTTP; Wed, 6 Dec 2006 07:09:39 -0800 (PST) Message-ID: <161d69110612060709n3bf99bd4y47d94b021b8f1d02@mail.gmail.com> Date: Wed, 6 Dec 2006 23:09:39 +0800 From: "maillist ifiaas" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Urel, a TCP option for Unreliable Streaming. Need your help. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2006 15:09:42 -0000 Hi friends, This is one of my research project. Our purpose is to modify TCP to support unreliable but congestion controlled streaming. The motivation is pretty similar to the one of DCCP CCID2. We have implemented a prototype on FreeBSD 5.4, and the the modifications are limited mostly in tcp_input.c and tcp_output.c. Source code, a paper about the design (under submission), and an Iperf modification to test out TCP Urel, is provided on the following page: www.comp.nus.edu.sg/~malin/ Our current stage is changing Urel into a single directional streaming protocol, so taht it could be abosolutely fair with default TCP Sack, in FreeBSD. But we found after all the modifications (on single directional streaming), Urel generates less ACK than normal Sack, making it under utilized when competing to TCP Sack. About only 3 out of 10 tries, Urel take the same throughput as Sack. The reason seems to lying in the Delay ACK code, in tcp_input.c. Because, when we turn off the Delay ACK option, using sysctl command, Urel and Sack play fairly. However after days of looking at the code, we failed to find the secret... Therefore, I turn to you, the specialists of the TCP code in FreeBSD. Hope you can help us to find the bug of our code. Any suggesion, comments, is appreciated. For details of how the code is implemented, how our experiment is conducted, you may need to spend one or two hours to browse through our paper, and the source code. Sincerely, Gavin From owner-freebsd-net@FreeBSD.ORG Wed Dec 6 16:05:06 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 49F2616A403 for ; Wed, 6 Dec 2006 16:05:06 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B64343CA8 for ; Wed, 6 Dec 2006 16:04:14 +0000 (GMT) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id JAA12191; Wed, 6 Dec 2006 09:04:51 -0700 (MST) Message-Id: <200612061604.JAA12191@lariat.net> X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 06 Dec 2006 09:04:39 -0700 To: Josh Paetzel , freebsd-net@freebsd.org From: Brett Glass In-Reply-To: <200612060313.23621.josh@tcbug.org> References: <6199c3dc0612050848g16a0911dga145485ba14bf21f@mail.gmail.com> <200612060552.WAA04850@lariat.net> <200612060313.23621.josh@tcbug.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-avg-checked=avg-ok-12F27FC7 Cc: Benjamin Adams Subject: Re: Bandwidth Monitoring program X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2006 16:05:06 -0000 At 02:13 AM 12/6/2006, Josh Paetzel wrote: >Just curious.....but where is he going to run ipfw? I seriously doubt >his router can run it, and what good is it going to do him to run it >on a machine on the network if the network is switched? It's not >going to be able to see any of the traffic other than what that >specific machine is sending/receiving. Of course, if his machine isn't acting as a router or bridge, and is not attached to a hub or the management port of a switch, there's no way that it could measure the traffic. So, we must assume that one of these things is true. Otherwise, all bets are off from the start. --Brett Glass From owner-freebsd-net@FreeBSD.ORG Wed Dec 6 16:11:13 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D44FB16A403 for ; Wed, 6 Dec 2006 16:11:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outN.internet-mail-service.net (outN.internet-mail-service.net [216.240.47.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88F8B43CA2 for ; Wed, 6 Dec 2006 16:10:27 +0000 (GMT) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Wed, 06 Dec 2006 07:57:09 -0800 Received: from [192.168.2.4] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id kB6GBACv068145; Wed, 6 Dec 2006 08:11:10 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <4576EB9D.2040300@elischer.org> Date: Wed, 06 Dec 2006 08:11:09 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Josh Paetzel References: <6199c3dc0612050848g16a0911dga145485ba14bf21f@mail.gmail.com> <200612060552.WAA04850@lariat.net> <200612060313.23621.josh@tcbug.org> In-Reply-To: <200612060313.23621.josh@tcbug.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Benjamin Adams , Brett Glass Subject: Re: Bandwidth Monitoring program X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2006 16:11:13 -0000 Josh Paetzel wrote: > On Tuesday 05 December 2006 23:52, Brett Glass wrote: >> Add a few IPFW "count" rules to count the bytes and packets. Then, >> periodically harvest and reset the counters via a cron job and >> write the results to a file. You can then prepare tables and charts >> which are as simple or as fancy as you please, without resorting to >> SNMP (which isn't secure). A little bit of code in your favorite >> scripting language will do it. And of course you can output to a >> graphing package, though for me a simple histogram using asterisks >> has sufficient precision in most cases. >> >> --Brett Glass >> > > Just curious.....but where is he going to run ipfw? I seriously doubt > his router can run it, and what good is it going to do him to run it > on a machine on the network if the network is switched? It's not > going to be able to see any of the traffic other than what that > specific machine is sending/receiving. > run ipfw in layer 2 after turning on promiscuous mode and attaching it to a hub. I do it all the time. From owner-freebsd-net@FreeBSD.ORG Wed Dec 6 17:53:30 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED53216A412 for ; Wed, 6 Dec 2006 17:53:30 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.200.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAAE643CA8 for ; Wed, 6 Dec 2006 17:52:41 +0000 (GMT) (envelope-from josh@tcbug.org) Received: from gimpy (c-24-118-173-219.hsd1.mn.comcast.net[24.118.173.219]) by comcast.net (sccrmhc11) with ESMTP id <2006120617532701100fakr5e>; Wed, 6 Dec 2006 17:53:27 +0000 From: Josh Paetzel To: Julian Elischer Date: Wed, 6 Dec 2006 11:53:25 -0600 User-Agent: KMail/1.9.4 References: <6199c3dc0612050848g16a0911dga145485ba14bf21f@mail.gmail.com> <200612060313.23621.josh@tcbug.org> <4576EB9D.2040300@elischer.org> In-Reply-To: <4576EB9D.2040300@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612061153.26040.josh@tcbug.org> Cc: freebsd-net@freebsd.org, Benjamin Adams , Brett Glass Subject: Re: Bandwidth Monitoring program X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2006 17:53:31 -0000 On Wednesday 06 December 2006 10:11, Julian Elischer wrote: > Josh Paetzel wrote: > > On Tuesday 05 December 2006 23:52, Brett Glass wrote: > >> Add a few IPFW "count" rules to count the bytes and packets. > >> Then, periodically harvest and reset the counters via a cron job > >> and write the results to a file. You can then prepare tables and > >> charts which are as simple or as fancy as you please, without > >> resorting to SNMP (which isn't secure). A little bit of code in > >> your favorite scripting language will do it. And of course you > >> can output to a graphing package, though for me a simple > >> histogram using asterisks has sufficient precision in most > >> cases. > >> > >> --Brett Glass > > > > Just curious.....but where is he going to run ipfw? I seriously > > doubt his router can run it, and what good is it going to do him > > to run it on a machine on the network if the network is switched? > > It's not going to be able to see any of the traffic other than > > what that specific machine is sending/receiving. > > run ipfw in layer 2 after turning on promiscuous mode and attaching > it to a hub. > > I do it all the time. > He specifically said in his original post that putting a machine between the router and his lan wasn't an option. His question was, "Is there a program where I can see whats going on from the computer on that network?" The answer to that question is, if he's on a switched network, no. Not without a topology change. If he can't put a box between the switch and router how likely is it that he's going to be able to put a hub between the switch and router and then attach a box to that? -- Thanks, Josh Paetzel From owner-freebsd-net@FreeBSD.ORG Wed Dec 6 18:01:33 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D5EE416A415 for ; Wed, 6 Dec 2006 18:01:33 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outU.internet-mail-service.net (outU.internet-mail-service.net [216.240.47.244]) by mx1.FreeBSD.org (Postfix) with ESMTP id 132EB43CA3 for ; Wed, 6 Dec 2006 18:00:47 +0000 (GMT) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Wed, 06 Dec 2006 09:47:29 -0800 Received: from [192.168.2.4] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id kB6I1V8Y039616; Wed, 6 Dec 2006 10:01:31 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <4577057B.7060801@elischer.org> Date: Wed, 06 Dec 2006 10:01:31 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Josh Paetzel References: <6199c3dc0612050848g16a0911dga145485ba14bf21f@mail.gmail.com> <200612060313.23621.josh@tcbug.org> <4576EB9D.2040300@elischer.org> <200612061153.26040.josh@tcbug.org> In-Reply-To: <200612061153.26040.josh@tcbug.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Benjamin Adams , Brett Glass Subject: Re: Bandwidth Monitoring program X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2006 18:01:33 -0000 Josh Paetzel wrote: > On Wednesday 06 December 2006 10:11, Julian Elischer wrote: >> Josh Paetzel wrote: >>> On Tuesday 05 December 2006 23:52, Brett Glass wrote: >>>> Add a few IPFW "count" rules to count the bytes and packets. >>>> Then, periodically harvest and reset the counters via a cron job >>>> and write the results to a file. You can then prepare tables and >>>> charts which are as simple or as fancy as you please, without >>>> resorting to SNMP (which isn't secure). A little bit of code in >>>> your favorite scripting language will do it. And of course you >>>> can output to a graphing package, though for me a simple >>>> histogram using asterisks has sufficient precision in most >>>> cases. >>>> >>>> --Brett Glass >>> Just curious.....but where is he going to run ipfw? I seriously >>> doubt his router can run it, and what good is it going to do him >>> to run it on a machine on the network if the network is switched? >>> It's not going to be able to see any of the traffic other than >>> what that specific machine is sending/receiving. >> run ipfw in layer 2 after turning on promiscuous mode and attaching >> it to a hub. >> >> I do it all the time. >> > > He specifically said in his original post that putting a machine > between the router and his lan wasn't an option. His question > was, "Is there a program where I can see whats going on from the > computer on that network?" The answer to that question is, if he's on > a switched network, no. Not without a topology change. If he can't > put a box between the switch and router how likely is it that he's > going to be able to put a hub between the switch and router and then > attach a box to that? I'd say that adding a hub is quite possible.. > > From owner-freebsd-net@FreeBSD.ORG Wed Dec 6 19:35:31 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E0F716A40F for ; Wed, 6 Dec 2006 19:35:31 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BF6044042 for ; Wed, 6 Dec 2006 19:20:21 +0000 (GMT) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id MAA15281; Wed, 6 Dec 2006 12:08:20 -0700 (MST) Message-Id: <200612061908.MAA15281@lariat.net> X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 06 Dec 2006 11:38:39 -0700 To: Josh Paetzel , Julian Elischer From: Brett Glass In-Reply-To: <200612061153.26040.josh@tcbug.org> References: <6199c3dc0612050848g16a0911dga145485ba14bf21f@mail.gmail.com> <200612060313.23621.josh@tcbug.org> <4576EB9D.2040300@elischer.org> <200612061153.26040.josh@tcbug.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-avg-checked=avg-ok-12F27FC7 Cc: freebsd-net@freebsd.org, Benjamin Adams Subject: Re: Bandwidth Monitoring program X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2006 19:35:31 -0000 At 10:53 AM 12/6/2006, Josh Paetzel wrote: >He specifically said in his original post that putting a machine >between the router and his lan wasn't an option. His question >was, "Is there a program where I can see whats going on from the >computer on that network?" The answer to that question is, if he's on >a switched network, no. Not without a topology change. Is adding a hub or a bridge a topology change? I'd argue that it wasn't. You can't listen in if you can't connect to the wire. --Brett Glass From owner-freebsd-net@FreeBSD.ORG Wed Dec 6 19:53:23 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7FC1E16A4C2 for ; Wed, 6 Dec 2006 19:53:23 +0000 (UTC) (envelope-from amason@rackspace.com) Received: from mx.sat.rackspace.com (mx.sat.rackspace.com [64.39.1.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id A471C43DF4 for ; Wed, 6 Dec 2006 19:47:33 +0000 (GMT) (envelope-from amason@rackspace.com) Received: from mail.rackspace.com (mail.rackspace.com [64.39.2.181]) by mx.sat.rackspace.com (8.13.8/8.13.8) with ESMTP id kB6JmCEp021490 for ; Wed, 6 Dec 2006 13:48:12 -0600 (envelope-from amason@rackspace.com) Received: from mizar.rackspace.com (office105-56.sat4.rackspace.com [10.6.105.56]) by mail.rackspace.com (8.13.1/8.13.1) with ESMTP id kB6Jltrj015461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 6 Dec 2006 13:47:55 -0600 From: Art Mason Organization: Rackspace Managed Hosting To: freebsd-net@freebsd.org Date: Wed, 6 Dec 2006 13:49:59 -0600 User-Agent: KMail/1.9.4 References: <6199c3dc0612050848g16a0911dga145485ba14bf21f@mail.gmail.com> <4576EB9D.2040300@elischer.org> <200612061153.26040.josh@tcbug.org> In-Reply-To: <200612061153.26040.josh@tcbug.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612061349.59511.amason@rackspace.com> Subject: Re: Bandwidth Monitoring program X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2006 19:53:23 -0000 On Wednesday 06 December 2006 11:53, Josh Paetzel wrote: > On Wednesday 06 December 2006 10:11, Julian Elischer wrote: > > Josh Paetzel wrote: > > > On Tuesday 05 December 2006 23:52, Brett Glass wrote: > > >> Add a few IPFW "count" rules to count the bytes and packets. > > >> Then, periodically harvest and reset the counters via a cron job > > >> and write the results to a file. You can then prepare tables and > > >> charts which are as simple or as fancy as you please, without > > >> resorting to SNMP (which isn't secure). A little bit of code in > > >> your favorite scripting language will do it. And of course you > > >> can output to a graphing package, though for me a simple > > >> histogram using asterisks has sufficient precision in most > > >> cases. > > >> > > >> --Brett Glass > > > > > > Just curious.....but where is he going to run ipfw? I seriously > > > doubt his router can run it, and what good is it going to do him > > > to run it on a machine on the network if the network is switched? > > > It's not going to be able to see any of the traffic other than > > > what that specific machine is sending/receiving. > > > > run ipfw in layer 2 after turning on promiscuous mode and attaching > > it to a hub. > > > > I do it all the time. > > He specifically said in his original post that putting a machine > between the router and his lan wasn't an option. His question > was, "Is there a program where I can see whats going on from the > computer on that network?" The answer to that question is, if he's on > a switched network, no. Not without a topology change. If he can't > put a box between the switch and router how likely is it that he's > going to be able to put a hub between the switch and router and then > attach a box to that? Not sure if this has been discussed already, but If the router's internal interface is plugged into a managed switch that supports a SPAN port, you can always set your monitoring box running NTOP, bandwidthd, NetFlow, etc. up on the destination switchport . Hope that helps. -- Art Mason amason@rackspace.com Intensive Network Security Rackspace Managed Hosting (800) 961-4454 ext. 4290 From owner-freebsd-net@FreeBSD.ORG Wed Dec 6 20:07:06 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9478316A407 for ; Wed, 6 Dec 2006 20:07:06 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BEF243CC7 for ; Wed, 6 Dec 2006 20:06:17 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin05-en2 [10.13.10.150]) by smtpout.mac.com (Xserve/8.12.11/smtpout03/MantshX 4.0) with ESMTP id kB6K0EC4006395; Wed, 6 Dec 2006 12:00:18 -0800 (PST) Received: from [17.214.13.96] (a17-214-13-96.apple.com [17.214.13.96]) (authenticated bits=0) by mac.com (Xserve/smtpin05/MantshX 4.0) with ESMTP id kB6JxONl017198; Wed, 6 Dec 2006 11:59:40 -0800 (PST) In-Reply-To: <200612061908.MAA15281@lariat.net> References: <6199c3dc0612050848g16a0911dga145485ba14bf21f@mail.gmail.com> <200612060313.23621.josh@tcbug.org> <4576EB9D.2040300@elischer.org> <200612061153.26040.josh@tcbug.org> <200612061908.MAA15281@lariat.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Wed, 6 Dec 2006 11:59:24 -0800 To: Brett Glass X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: freebsd-net@freebsd.org Subject: Re: Bandwidth Monitoring program X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2006 20:07:06 -0000 On Dec 6, 2006, at 10:38 AM, Brett Glass wrote: > Is adding a hub or a bridge a topology change? I'd argue that it > wasn't. Um. Adding a normal client machine to an existing hub or switch does not constitute a topology change. Adding a new hub or bridge most certainly would constitute a topology change. [ Add "IMHO" and salt if needed to season to taste. But if the result of a change can result in a loop-- ie, connecting two ports on the new hub to the rest of the network, or connecting two ports from a bridge to the same hub/switch-- or if the change might result in the network no longer being in compliance with the networking requirements (ie, you can only daisy-chain a limited number of hubs together before you break the timing tolerance)-- such changes do effect the topology... ] -- -Chuck From owner-freebsd-net@FreeBSD.ORG Wed Dec 6 20:45:39 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E66416A530 for ; Wed, 6 Dec 2006 20:45:39 +0000 (UTC) (envelope-from hidden@4you.lt) Received: from tequila.4you.lt (tequila.4you.lt [212.122.65.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F9D843CB8 for ; Wed, 6 Dec 2006 20:44:27 +0000 (GMT) (envelope-from hidden@4you.lt) Received: (qmail 36700 invoked by uid 98); 6 Dec 2006 20:45:13 -0000 Received: from 84.240.25.195 by tequila.4you.lt (envelope-from , uid 89) with qmail-scanner-1.25 (f-prot: 4.6.6/3.16.14. spamassassin: 3.1.7. Clear:RC:0(84.240.25.195):SA:0(-1.6/5.0):. Processed in 5.456878 secs); 06 Dec 2006 20:45:13 -0000 X-Spam-Status: No, hits=-1.6 required=5.0 X-Qmail-Scanner-Mail-From: hidden@4you.lt via tequila.4you.lt X-Qmail-Scanner: 1.25 (Clear:RC:0(84.240.25.195):SA:0(-1.6/5.0):. Processed in 5.456878 secs) Received: from unknown (HELO BLUEBIRD) (hidden@4you.lt@84.240.25.195) by tequila.4you.lt with SMTP; 6 Dec 2006 20:45:08 -0000 Date: Wed, 6 Dec 2006 22:45:04 +0200 From: Timofej Dod X-Mailer: The Bat! (v3.51.10) Professional Organization: UAB "Eilorita", 4you.lt X-Priority: 3 (Normal) Message-ID: <1895992105.20061206224504@4you.lt> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: dummynet throughput problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Timofej Dod List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2006 20:45:39 -0000 Hi, I got a firewall with ipfw + dummynet. system is: FreeBSD 6.1-RELEASE-p10 table 1 contains 211 IP addresses. 00502 pipe 11 ip from any to table(1) out via rl0 00502 skipto 2000 ip from any to table(1) and with pipe configured ipfw -q pipe 11 config mask dst-ip 0xffffffff bw 256Kbit/s however everybody only getting half of it i.e. 128 Kbits. also net.inet.ip.fw.one_pass: 1 doesn't seem to work properly since counters show that skipto rule is being triggered and it should not with the one_pass activated. Any clues how to make it give the speed it is supposed to? -- Timofej Dod From owner-freebsd-net@FreeBSD.ORG Wed Dec 6 22:01:12 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 95E9516A5E0 for ; Wed, 6 Dec 2006 22:01:12 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02E0D43F6C for ; Wed, 6 Dec 2006 21:38:32 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id kB6LbE5K052134 for ; Wed, 6 Dec 2006 14:37:15 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 06 Dec 2006 14:38:08 -0700 (MST) Message-Id: <20061206.143808.-1350498609.imp@bsdimp.com> To: net@freebsd.org From: "M. Warner Losh" X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Wed, 06 Dec 2006 14:37:15 -0700 (MST) Cc: Subject: FreeBSD NFS Client, Windows 2003 NFS server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2006 22:01:12 -0000 Does anybody have experience with using FreeBSD 4.x or 6.x NFS clients against a Windows 2003 NFS server? What is the performance relative to using a FreeBSD NFS server? What is the stability? Does locking work? Does the Windows 2003 server have extensions that grok file system flags? Thanks much Warner P.S. If this is the wrong place to ask, please suggest a better one. From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 00:18:21 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 979A816A512 for ; Thu, 7 Dec 2006 00:18:21 +0000 (UTC) (envelope-from freebsdworld@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 455D543CAE for ; Thu, 7 Dec 2006 00:17:32 +0000 (GMT) (envelope-from freebsdworld@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so336369wxc for ; Wed, 06 Dec 2006 16:18:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=BEw2yfAYWQFpQwHeotpPgEE49Nn729qZH5KnmQmsjfK7RX5pyhVXXrHoF/H2xQoH6MV4zpB1ZJ45Ya3ZD0g3fdgkoyS8WBvUEMEA6Kz0R3aoRbqjowX697DffIAZ5NL4QGZDDFatVbv7++r+HM5qwoqSyfbWeFCa9X5zhavGZ1o= Received: by 10.70.65.8 with SMTP id n8mr2511791wxa.1165450699787; Wed, 06 Dec 2006 16:18:19 -0800 (PST) Received: from ?192.168.1.2? ( [24.213.219.145]) by mx.google.com with ESMTP id h14sm40709880wxd.2006.12.06.16.18.18; Wed, 06 Dec 2006 16:18:19 -0800 (PST) From: Benjamin D Adams To: Brett Glass In-Reply-To: <200612061908.MAA15281@lariat.net> References: <6199c3dc0612050848g16a0911dga145485ba14bf21f@mail.gmail.com> <200612060313.23621.josh@tcbug.org> <4576EB9D.2040300@elischer.org> <200612061153.26040.josh@tcbug.org> <200612061908.MAA15281@lariat.net> Content-Type: text/plain Date: Wed, 06 Dec 2006 19:18:28 -0500 Message-Id: <1165450708.1055.9.camel@testing.freebsdworld.net> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Josh Paetzel , Julian Elischer , freebsd-net@freebsd.org Subject: Re: Bandwidth Monitoring program X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 00:18:21 -0000 What my network looks like: NET | NAT/FIREWALL(2.1.24.34) | ------------------- | | | 2.1.24.35 2.1.24.36 2.1.24.37 There is no DHCP, I don't think it is possablie to do this but I want to install a bandwidth monitoring program on 2.1.24.35. That will monitor all traffic going through 2.1.24.34. I installed bandwidthd but it's only local traffic I can't get all traffic through 2.1.24.34. I think I need to but a middle man between NET and 2.1.24.34. I don't have any more ips to use. 2.1.24.34 is a firewall like netgear, linksys, etc setup with NAT. What I see is I need to replace the NAT with something where I have a shell. I don't think it is possible with the current setup, but figured I would ask. Thanks for any help. Ben Adams On Wed, 2006-12-06 at 11:38 -0700, Brett Glass wrote: > At 10:53 AM 12/6/2006, Josh Paetzel wrote: > > >He specifically said in his original post that putting a machine > >between the router and his lan wasn't an option. His question > >was, "Is there a program where I can see whats going on from the > >computer on that network?" The answer to that question is, if he's on > >a switched network, no. Not without a topology change. > > Is adding a hub or a bridge a topology change? I'd argue that it > wasn't. > > You can't listen in if you can't connect to the wire. > > --Brett Glass > From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 00:25:09 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DBB0316A4C8 for ; Thu, 7 Dec 2006 00:25:09 +0000 (UTC) (envelope-from prvs=jelischer=489c5c408@ironport.com) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 696B143CA2 for ; Thu, 7 Dec 2006 00:24:21 +0000 (GMT) (envelope-from prvs=jelischer=489c5c408@ironport.com) DomainKey-Signature: s=key512; d=ironport.com; c=nofws; q=dns; b=GVisUO01ndjtvsLhIMMOv7nhADYxnmrVhvFfOJjVjleBCiTecbZgnN4EPFbMuY7S8GRMszW8Y/DJUBuXql+1lg==; Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 06 Dec 2006 16:25:09 -0800 Message-ID: <45775F64.9060501@ironport.com> Date: Wed, 06 Dec 2006 16:25:08 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Benjamin D Adams References: <6199c3dc0612050848g16a0911dga145485ba14bf21f@mail.gmail.com> <200612060313.23621.josh@tcbug.org> <4576EB9D.2040300@elischer.org> <200612061153.26040.josh@tcbug.org> <200612061908.MAA15281@lariat.net> <1165450708.1055.9.camel@testing.freebsdworld.net> In-Reply-To: <1165450708.1055.9.camel@testing.freebsdworld.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Brett Glass , freebsd-net@freebsd.org, Josh Paetzel Subject: Re: Bandwidth Monitoring program X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 00:25:09 -0000 Benjamin D Adams wrote: > What my network looks like: > NET > | > NAT/FIREWALL(2.1.24.34) > | > ------------------- <---- put a cheap hub here > | | | > 2.1.24.35 2.1.24.36 2.1.24.37 > if you place a cheap 100Mb hub in the location shown, then you should be able to look at all traffic that is headed to the firewall by listenning on .35 > There is no DHCP, I don't think it is possablie to do this but I want to > install a bandwidth monitoring program on 2.1.24.35. That will monitor > all traffic going through 2.1.24.34. I installed bandwidthd but it's > only local traffic I can't get all traffic through 2.1.24.34. I think I > need to but a middle man between NET and 2.1.24.34. I don't have any > more ips to use. 2.1.24.34 is a firewall like netgear, linksys, etc > setup with NAT. > > What I see is I need to replace the NAT with something where I have a > shell. I don't think it is possible with the current setup, but figured > I would ask. Thanks for any help. > > Ben Adams > > \eebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 00:29:38 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F3C716A416 for ; Thu, 7 Dec 2006 00:29:38 +0000 (UTC) (envelope-from freebsdworld@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBE5F43CC2 for ; Thu, 7 Dec 2006 00:28:41 +0000 (GMT) (envelope-from freebsdworld@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so338481wxc for ; Wed, 06 Dec 2006 16:29:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=nXMF9NWep9zEJ5hkMj/DAaC3VqcA6oFsxXRhBM4S7HQaSF/b/eioePuHL5LioIrH63EOdsFhz7oM6k04SR7wASrti0krnHnQ/rl2kU/HHD8qXkwa5Sv42kB/iLtYUKD5YFbtchx9su/Nop8+b0Ix+HEF5O/Quk8PHq1jhp5kodQ= Received: by 10.70.9.4 with SMTP id 4mr2526846wxi.1165451369317; Wed, 06 Dec 2006 16:29:29 -0800 (PST) Received: from ?192.168.1.2? ( [24.213.219.145]) by mx.google.com with ESMTP id i10sm41398302wxd.2006.12.06.16.29.28; Wed, 06 Dec 2006 16:29:28 -0800 (PST) From: Benjamin D Adams To: Julian Elischer In-Reply-To: <45775F64.9060501@ironport.com> References: <6199c3dc0612050848g16a0911dga145485ba14bf21f@mail.gmail.com> <200612060313.23621.josh@tcbug.org> <4576EB9D.2040300@elischer.org> <200612061153.26040.josh@tcbug.org> <200612061908.MAA15281@lariat.net> <1165450708.1055.9.camel@testing.freebsdworld.net> <45775F64.9060501@ironport.com> Content-Type: text/plain Date: Wed, 06 Dec 2006 19:29:38 -0500 Message-Id: <1165451378.1055.11.camel@testing.freebsdworld.net> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Brett Glass , freebsd-net@freebsd.org, Josh Paetzel Subject: Re: Bandwidth Monitoring program X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 00:29:38 -0000 On Wed, 2006-12-06 at 16:25 -0800, Julian Elischer wrote: > Benjamin D Adams wrote: > > What my network looks like: > > NET > > | > > NAT/FIREWALL(2.1.24.34) > > | > > ------------------- <---- put a cheap hub here > > | | | > > 2.1.24.35 2.1.24.36 2.1.24.37 > > > > if you place a cheap 100Mb hub in the location shown, then > you should be able to look at all traffic that is headed to the firewall > by listenning on .35 Yes there is a SWITCH there, do you mean listen to port 35? would I do a packet sniffer on 2.1.24.34 just port 35? > > > > > There is no DHCP, I don't think it is possablie to do this but I want to > > install a bandwidth monitoring program on 2.1.24.35. That will monitor > > all traffic going through 2.1.24.34. I installed bandwidthd but it's > > only local traffic I can't get all traffic through 2.1.24.34. I think I > > need to but a middle man between NET and 2.1.24.34. I don't have any > > more ips to use. 2.1.24.34 is a firewall like netgear, linksys, etc > > setup with NAT. > > > > What I see is I need to replace the NAT with something where I have a > > shell. I don't think it is possible with the current setup, but figured > > I would ask. Thanks for any help. > > > > Ben Adams > > > > \eebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 00:53:40 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 98F8616A4D0 for ; Thu, 7 Dec 2006 00:53:40 +0000 (UTC) (envelope-from prvs=jelischer=489c5c408@ironport.com) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE2CD43CC5 for ; Thu, 7 Dec 2006 00:52:48 +0000 (GMT) (envelope-from prvs=jelischer=489c5c408@ironport.com) DomainKey-Signature: s=key512; d=ironport.com; c=nofws; q=dns; b=jKSNfDYBnWyP62tHEOw19fiEtkj/bxf/wEtu3e+i/WU0nTg9z8sdpTf/DGtLc9veT52w3uJj2pInGSRth9w63Q==; Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 06 Dec 2006 16:53:35 -0800 Message-ID: <4577660D.9070105@ironport.com> Date: Wed, 06 Dec 2006 16:53:33 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Benjamin D Adams References: <6199c3dc0612050848g16a0911dga145485ba14bf21f@mail.gmail.com> <200612060313.23621.josh@tcbug.org> <4576EB9D.2040300@elischer.org> <200612061153.26040.josh@tcbug.org> <200612061908.MAA15281@lariat.net> <1165450708.1055.9.camel@testing.freebsdworld.net> <45775F64.9060501@ironport.com> <1165451378.1055.11.camel@testing.freebsdworld.net> In-Reply-To: <1165451378.1055.11.camel@testing.freebsdworld.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Brett Glass , freebsd-net@freebsd.org, Josh Paetzel Subject: Re: Bandwidth Monitoring program X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 00:53:40 -0000 Benjamin D Adams wrote: > On Wed, 2006-12-06 at 16:25 -0800, Julian Elischer wrote: > >> Benjamin D Adams wrote: >> >>> What my network looks like: >>> NET >>> | >>> NAT/FIREWALL(2.1.24.34) >>> | >>> /-----[ HUB ]----\ <---- put a cheap hub here >>> | | | >>> 2.1.24.35 2.1.24.36 2.1.24.37 >>> >>> >> if you place a cheap 100Mb hub in the location shown, then >> you should be able to look at all traffic that is headed to the firewall >> by listenning on .35 >> > > Yes there is a SWITCH there, do you mean listen to port 35? would I do > a packet sniffer on 2.1.24.34 just port 35? > go buy a $39.99 hub at your local electronics store (make sure it is a hub) put it in the location shown (see changed diagramm above). listen on 2.1.24.35 using promiscuous mode.. even better, if you have 2 ethernet ports on your PC: [internet] | [Firewall] | /-------[HUB] | | | [current switch]-------\ | | | | | | | | | | | | [ 2.1.24.35] [x.x.x.x.x] [y.y.y.y.y] set -arp , promisc and no address on the listenning port, and you can listen on only traffic going to the firewall. OR you may just make a TAP (only works for 10Mb/s and 100Mb/sec) by following the instructions at: http://www.sun.com/bigadmin/content/submitted/passive_ethernet_tap.html and put it where the hub is above. julian >> >> >> >>> There is no DHCP, I don't think it is possablie to do this but I want to >>> install a bandwidth monitoring program on 2.1.24.35. That will monitor >>> all traffic going through 2.1.24.34. I installed bandwidthd but it's >>> only local traffic I can't get all traffic through 2.1.24.34. I think I >>> need to but a middle man between NET and 2.1.24.34. I don't have any >>> more ips to use. 2.1.24.34 is a firewall like netgear, linksys, etc >>> setup with NAT. >>> >>> What I see is I need to replace the NAT with something where I have a >>> shell. I don't think it is possible with the current setup, but figured >>> I would ask. Thanks for any help. >>> >>> Ben Adams >>> >>> \eebsd.org" >>> From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 02:03:10 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9126D16A412 for ; Thu, 7 Dec 2006 02:03:10 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26C3F43CB1 for ; Thu, 7 Dec 2006 02:02:20 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id kB721T51010673; Wed, 6 Dec 2006 18:01:32 -0800 (PST) Date: Thu, 07 Dec 2006 10:35:32 +0900 Message-ID: From: gnn@freebsd.org To: "maillist ifiaas" In-Reply-To: <161d69110612060709n3bf99bd4y47d94b021b8f1d02@mail.gmail.com> References: <161d69110612060709n3bf99bd4y47d94b021b8f1d02@mail.gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.90 (i386-apple-darwin8.8.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: Urel, a TCP option for Unreliable Streaming. Need your help. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 02:03:10 -0000 At Wed, 6 Dec 2006 23:09:39 +0800, maillist ifiaas wrote: > > Hi friends, > > This is one of my research project. Our purpose is to modify TCP to > support unreliable but congestion controlled streaming. The > motivation is pretty similar to the one of DCCP CCID2. We have > implemented a prototype on FreeBSD 5.4, and the the modifications > are limited mostly in tcp_input.c and tcp_output.c. Source code, a > paper about the design (under submission), and an Iperf modification > to test out TCP Urel, is provided on the following page: > www.comp.nus.edu.sg/~malin/ > > Our current stage is changing Urel into a single directional > streaming protocol, so taht it could be abosolutely fair with > default TCP Sack, in FreeBSD. But we found after all the > modifications (on single directional streaming), Urel generates less > ACK than normal Sack, making it under utilized when competing to TCP > Sack. About only 3 out of 10 tries, Urel take the same throughput as > Sack. The reason seems to lying in the Delay ACK code, in > tcp_input.c. Because, when we turn off the Delay ACK option, using > sysctl command, Urel and Sack play fairly. However after days of > looking at the code, we failed to find the secret... Therefore, I > turn to you, the specialists of the TCP code in FreeBSD. Hope you > can help us to find the bug of our code. Any suggesion, comments, is > appreciated. > > For details of how the code is implemented, how our experiment is > conducted, you may need to spend one or two hours to browse through > our paper, and the source code. How is this different from the recently integrated SCTP? Best, George From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 03:46:36 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DDC5516A403 for ; Thu, 7 Dec 2006 03:46:36 +0000 (UTC) (envelope-from maillist.ifiaas@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC29F43CA2 for ; Thu, 7 Dec 2006 03:45:46 +0000 (GMT) (envelope-from maillist.ifiaas@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so728231nfc for ; Wed, 06 Dec 2006 19:46:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SNVJRZgy87sjYp+/Tq6G0Z4vriKYYzZgFBPxxqZbMtndKtyyfQEw9ZCAR/pOxq37ahrRr6geHF3SyEXWjktG8GK9MlQZ2+KY9p46W/lxxRDa9vf7B0qEtbMhjcedxU+cnogoWUk2uYk2f45IeaYJIa/J6lvYrwcEQr9NfAkqcH8= Received: by 10.48.220.15 with SMTP id s15mr3227094nfg.1165463194727; Wed, 06 Dec 2006 19:46:34 -0800 (PST) Received: by 10.48.242.15 with HTTP; Wed, 6 Dec 2006 19:46:34 -0800 (PST) Message-ID: <161d69110612061946w16c292b6ja9a8bd6b742d5885@mail.gmail.com> Date: Thu, 7 Dec 2006 11:46:34 +0800 From: "maillist ifiaas" To: freebsd-net@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <161d69110612060709n3bf99bd4y47d94b021b8f1d02@mail.gmail.com> Cc: gnn@freebsd.org Subject: Re: Urel, a TCP option for Unreliable Streaming. Need your help. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 03:46:36 -0000 Hi George, Compare to SCTP, TCP Urel is much simpler. Drawback is the (1) lack of multihoming, (2) directly implmentation of partial reliabiliity. These drawbacks, however, allows more flexibility for usage. I am not very familiar with SCTP. I suppose the multihoming support is the key for SCTP to support multipath streaming. But not all client (say, home users) has multiple IP address: seldom of them use two network card, ISP less willing to offer multiple IP addresses to single user, or the Cable Modem/home-gateway which has only one IP address to the outside world. Therefore, I suppose that multpath streaming to home users, the largeset group that multimedia application should serve, is only feasible now at the application layer. I.e. a transport protocol may be better off to offer the flexibility for multipath streaming, rather than do it by yourself. TCP Urel realize congestion controlled unreliability on single path. It provide segment loss information to the receiver; therefore if the application want, they are able to do retranmission by themselves. This simplisity gives the free of retransmission to the application: to retransmit or not, and from where to retranmit? One pontential application is the Distributed Media Streaming (or Multi-Source Streaming), where the receiver should have the freedom to decide from which sender the retranmission should be conducted. We believe TCP Urel has a niche fit to this type of applications. Another benifit from TCP Urel, is that, it inherents the API from TCP. Therefore, many exsiting streaming programs that currently using TCP for multimedia stremaing purpose can acctually be changed to use Urel by change a few lines in the source code, to set socket options, and to handle same simple metadata at the receiver. Very simple modifcation are needed. The third benifit is that, since Urel is only an option on TCP. When the TCP evolves in the future, say, the congestion control is modified a bit here and there, Urel adapts to these changes. And we can anticipate that, the unreliable support from Urel in that version of TCP, will be still there. To other protocols that are designed to be friendly to TCP, they may have to be modified very carefully to retain the TCP-friendliness. Since TCP is the dominant protocol, and the keystone of the network stability, attaching the unliability function to TCP instead of creating a new protocol may be a safer and easier bet. Regards, Gavin On 12/7/06, gnn@freebsd.org wrote: > At Wed, 6 Dec 2006 23:09:39 +0800, > maillist ifiaas wrote: > > > > Hi friends, > > > > This is one of my research project. Our purpose is to modify TCP to > > support unreliable but congestion controlled streaming. The > > motivation is pretty similar to the one of DCCP CCID2. We have > > implemented a prototype on FreeBSD 5.4, and the the modifications > > are limited mostly in tcp_input.c and tcp_output.c. Source code, a > > paper about the design (under submission), and an Iperf modification > > to test out TCP Urel, is provided on the following page: > > www.comp.nus.edu.sg/~malin/ > > > > Our current stage is changing Urel into a single directional > > streaming protocol, so taht it could be abosolutely fair with > > default TCP Sack, in FreeBSD. But we found after all the > > modifications (on single directional streaming), Urel generates less > > ACK than normal Sack, making it under utilized when competing to TCP > > Sack. About only 3 out of 10 tries, Urel take the same throughput as > > Sack. The reason seems to lying in the Delay ACK code, in > > tcp_input.c. Because, when we turn off the Delay ACK option, using > > sysctl command, Urel and Sack play fairly. However after days of > > looking at the code, we failed to find the secret... Therefore, I > > turn to you, the specialists of the TCP code in FreeBSD. Hope you > > can help us to find the bug of our code. Any suggesion, comments, is > > appreciated. > > > > For details of how the code is implemented, how our experiment is > > conducted, you may need to spend one or two hours to browse through > > our paper, and the source code. > > How is this different from the recently integrated SCTP? > > Best, > George > From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 07:01:48 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 62EAB16A4A7; Thu, 7 Dec 2006 07:01:48 +0000 (UTC) (envelope-from ari.suutari@syncrontech.com) Received: from espresso2.syncrontech.com (sync-old.syncrontech.com [213.28.98.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4DBF43CAB; Thu, 7 Dec 2006 07:00:52 +0000 (GMT) (envelope-from ari.suutari@syncrontech.com) Received: from guinness.syncrontech.com (guinness.syncrontech.com [62.71.8.57]) by espresso2.syncrontech.com (8.13.1/8.13.1) with ESMTP id kB771etq092141; Thu, 7 Dec 2006 09:01:40 +0200 (EET) (envelope-from ari.suutari@syncrontech.com) Received: from coffee (asatest1.syncrontech.com [62.71.8.41]) by guinness.syncrontech.com (8.13.4/8.13.4) with SMTP id kB771Yvd034691; Thu, 7 Dec 2006 09:01:39 +0200 (EET) (envelope-from ari.suutari@syncrontech.com) Message-ID: <010801c719cd$88ee09c0$6602a8c0@sad.syncrontech.com> From: "Ari Suutari" To: "Antony Mawer" , "Gleb Smirnoff" References: <200612041538.kB4FcQjk073583@freefall.freebsd.org> <0eaa01c71835$f12055f0$6602a8c0@sad.syncrontech.com> <20061205100407.GB32700@cell.sick.ru> <100a01c71858$64b1efc0$6602a8c0@sad.syncrontech.com> <20061205104832.GD32700@cell.sick.ru> <4575D610.702@mawer.org> Date: Thu, 7 Dec 2006 09:01:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Cc: net@FreeBSD.org Subject: Re: kern/104377: [carp] [patch] CARP interface doesn't go up on VmWare X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 07:01:48 -0000 Hi, > > > If you are running VMware 5.x, then you can use the em driver (Intel > Pro/1000) instead, which is far more functional than the lnc driver. To > do so: > > 1. Shutdown the VMware system > 2. Locate the *.vmx file for your virtual machine > 3. Open the *.vmx file in your favourite text editor > 4. Add the following line: > > ethernet0.virtualDev = "e1000" > > 5. Save the file, and re-open the VM in VMware > 6. Enjoy a more functional NIC under VMware! Great ! I didn't know this. Well, I guess this problem is solved then. Thanks, Ari S. From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 08:12:15 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3050F16A492 for ; Thu, 7 Dec 2006 08:12:15 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 650F243CA6 for ; Thu, 7 Dec 2006 08:11:24 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from knop-beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-3.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 09:12:12 +0100 Date: Thu, 7 Dec 2006 09:12:11 +0100 (CET) From: Harti Brandt X-X-Sender: brandt_h@knop-beagle.kn.op.dlr.de To: "M. Warner Losh" In-Reply-To: <20061206.143808.-1350498609.imp@bsdimp.com> Message-ID: <20061207090026.I17220@knop-beagle.kn.op.dlr.de> References: <20061206.143808.-1350498609.imp@bsdimp.com> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 07 Dec 2006 08:12:12.0671 (UTC) FILETIME=[663438F0:01C719D7] Cc: net@freebsd.org Subject: Re: FreeBSD NFS Client, Windows 2003 NFS server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 08:12:15 -0000 Hi Warner, On Wed, 6 Dec 2006, M. Warner Losh wrote: MWL>Does anybody have experience with using FreeBSD 4.x or 6.x NFS clients MWL>against a Windows 2003 NFS server? What is the performance relative MWL>to using a FreeBSD NFS server? What is the stability? Does locking MWL>work? Does the Windows 2003 server have extensions that grok file MWL>system flags? I use this regularily (well, -CURRENT). I have no numbers, but performance is ok. I have the home directories on a W2003k server and it 'feels' fast enough. The only problem I see is a lot of 'file server not reponding' and 'file server up again' (with 2-3 seconds in between). This is usually when saving a large mail from pine. Linux clients see the same problem, so I suppose it is a problem on the SFU side. Locking seems to work. Problems are with filenames that are illegal for NTFS - hosting a 2.11BSD source tree on a W2003 NFS share does not work because of filenames containing ':' :-). I've not tested what other characters are illegal. Another problem is that on the NTFS side there is no good way to backup, copy, whatever the trees, because while NTFS handles Makefile and makefile, no Windows tool can access both of them. Even worse thinks like ADSM backup sometimes die with internal errors. Mapping of UIDs and GIDs is rather magic. The FreeBSD side, the SFU tools and cygwin all see different numbers which is rather annoying. The same is with symbolic links. The file flags are not supported by the server. There are no extensions that I know of. harti From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 09:01:24 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C368016A522 for ; Thu, 7 Dec 2006 09:01:24 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90CE843CCC for ; Thu, 7 Dec 2006 09:00:23 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 31456 invoked from network); 7 Dec 2006 08:49:39 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 7 Dec 2006 08:49:39 -0000 Message-ID: <4577D858.4010300@freebsd.org> Date: Thu, 07 Dec 2006 10:01:12 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: gnn@freebsd.org References: <161d69110612060709n3bf99bd4y47d94b021b8f1d02@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, maillist ifiaas Subject: Re: Urel, a TCP option for Unreliable Streaming. Need your help. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 09:01:24 -0000 gnn@freebsd.org wrote: > At Wed, 6 Dec 2006 23:09:39 +0800, > maillist ifiaas wrote: >> Hi friends, >> >> This is one of my research project. Our purpose is to modify TCP to >> support unreliable but congestion controlled streaming. The >> motivation is pretty similar to the one of DCCP CCID2. We have >> implemented a prototype on FreeBSD 5.4, and the the modifications >> are limited mostly in tcp_input.c and tcp_output.c. Source code, a >> paper about the design (under submission), and an Iperf modification >> to test out TCP Urel, is provided on the following page: >> www.comp.nus.edu.sg/~malin/ >> >> Our current stage is changing Urel into a single directional >> streaming protocol, so taht it could be abosolutely fair with >> default TCP Sack, in FreeBSD. But we found after all the >> modifications (on single directional streaming), Urel generates less >> ACK than normal Sack, making it under utilized when competing to TCP >> Sack. About only 3 out of 10 tries, Urel take the same throughput as >> Sack. The reason seems to lying in the Delay ACK code, in >> tcp_input.c. Because, when we turn off the Delay ACK option, using >> sysctl command, Urel and Sack play fairly. However after days of >> looking at the code, we failed to find the secret... Therefore, I >> turn to you, the specialists of the TCP code in FreeBSD. Hope you >> can help us to find the bug of our code. Any suggesion, comments, is >> appreciated. >> >> For details of how the code is implemented, how our experiment is >> conducted, you may need to spend one or two hours to browse through >> our paper, and the source code. > > How is this different from the recently integrated SCTP? It doesn't try to retransmit at all. A lost segment is lost and resending it would be pointless for realtime content. On the other hand you don't want to blast the network at a fixed rate and so this protocol wants to use a congestion control algorithm to back off when bandwidth gets scarce. I haven't looked at the details yet but my initial guess would be that the actual TCP code isn't the best starting point. TCP is too obsessed with retransmitting if something got lost. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 09:13:38 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 258C616A407 for ; Thu, 7 Dec 2006 09:13:38 +0000 (UTC) (envelope-from maillist.ifiaas@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id D600F43CA2 for ; Thu, 7 Dec 2006 09:12:46 +0000 (GMT) (envelope-from maillist.ifiaas@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so792602nfc for ; Thu, 07 Dec 2006 01:13:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FHs031UfVjGAVZtaV1JjpSV92+quqQ9jeYVgDPT0RvYi0fqezzOV7MGREuUgwlRPhD1XAnKQvNpvo6z1QPTbawChNeR85KKL5VYvOFwQoXzPRjVRmVYmp0yWfolBm4YtlaNxK2FkrVJi0Um1E3d4h/00kod4UDRxO1uI1hHheAc= Received: by 10.48.48.13 with SMTP id v13mr3598086nfv.1165482815622; Thu, 07 Dec 2006 01:13:35 -0800 (PST) Received: by 10.48.242.15 with HTTP; Thu, 7 Dec 2006 01:13:35 -0800 (PST) Message-ID: <161d69110612070113g7dcf027dj532cffdcd633a4a@mail.gmail.com> Date: Thu, 7 Dec 2006 17:13:35 +0800 From: "maillist ifiaas" To: "Andre Oppermann" In-Reply-To: <4577D858.4010300@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <161d69110612060709n3bf99bd4y47d94b021b8f1d02@mail.gmail.com> <4577D858.4010300@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: Urel, a TCP option for Unreliable Streaming. Need your help. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 09:13:38 -0000 Thank you Andre. You explain it clearer than me. Yes, TCP's interweaving with retransmission scares people from multimedia streaming point of view. So we find a way to remove retransmission in TCP. Acctually it turns out to be easier than it looks. We only add another 750 lines of code in the source, including the debugging and preprocessor directives. We are trapped on the delay ACK problem, and don't know how our code affects the delay ACK action in original TCP. Through experiments, we find TCP Urel delayed more ACK than TCP Sack. For Sack, the delack / nondelack which are triggered by incoming data segment is almost 1:1 (in fast track), but for TCP Urel, the same ratio is around 2:1. -gavin On 12/7/06, Andre Oppermann wrote: > gnn@freebsd.org wrote: > > At Wed, 6 Dec 2006 23:09:39 +0800, > > maillist ifiaas wrote: > >> Hi friends, > >> > >> This is one of my research project. Our purpose is to modify TCP to > >> support unreliable but congestion controlled streaming. The > >> motivation is pretty similar to the one of DCCP CCID2. We have > >> implemented a prototype on FreeBSD 5.4, and the the modifications > >> are limited mostly in tcp_input.c and tcp_output.c. Source code, a > >> paper about the design (under submission), and an Iperf modification > >> to test out TCP Urel, is provided on the following page: > >> www.comp.nus.edu.sg/~malin/ > >> > >> Our current stage is changing Urel into a single directional > >> streaming protocol, so taht it could be abosolutely fair with > >> default TCP Sack, in FreeBSD. But we found after all the > >> modifications (on single directional streaming), Urel generates less > >> ACK than normal Sack, making it under utilized when competing to TCP > >> Sack. About only 3 out of 10 tries, Urel take the same throughput as > >> Sack. The reason seems to lying in the Delay ACK code, in > >> tcp_input.c. Because, when we turn off the Delay ACK option, using > >> sysctl command, Urel and Sack play fairly. However after days of > >> looking at the code, we failed to find the secret... Therefore, I > >> turn to you, the specialists of the TCP code in FreeBSD. Hope you > >> can help us to find the bug of our code. Any suggesion, comments, is > >> appreciated. > >> > >> For details of how the code is implemented, how our experiment is > >> conducted, you may need to spend one or two hours to browse through > >> our paper, and the source code. > > > > How is this different from the recently integrated SCTP? > > It doesn't try to retransmit at all. A lost segment is lost and > resending it would be pointless for realtime content. On the other > hand you don't want to blast the network at a fixed rate and so > this protocol wants to use a congestion control algorithm to back > off when bandwidth gets scarce. I haven't looked at the details > yet but my initial guess would be that the actual TCP code isn't > the best starting point. TCP is too obsessed with retransmitting > if something got lost. > > -- > Andre > > From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 09:42:59 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 277C716A417; Thu, 7 Dec 2006 09:42:59 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from ilsa.franken.de (mail-n.franken.de [193.175.24.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id E151F43CA5; Thu, 7 Dec 2006 09:42:07 +0000 (GMT) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from [192.168.1.15] (p508FDDC2.dip.t-dialin.net [80.143.221.194]) by ilsa.franken.de (Postfix) with ESMTP id 6AA0E2464B; Thu, 7 Dec 2006 10:42:56 +0100 (CET) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <4577D858.4010300@freebsd.org> References: <161d69110612060709n3bf99bd4y47d94b021b8f1d02@mail.gmail.com> <4577D858.4010300@freebsd.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2786D1DE-E8FA-490C-AFF7-E458E262AEF7@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Date: Thu, 7 Dec 2006 10:42:59 +0100 To: Andre Oppermann X-Mailer: Apple Mail (2.752.2) Cc: gnn@freebsd.org, maillist ifiaas , freebsd-net@freebsd.org Subject: Re: Urel, a TCP option for Unreliable Streaming. Need your help. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 09:42:59 -0000 Hi Andre, see my comments in-line. Best regards Michael On Dec 7, 2006, at 10:01 AM, Andre Oppermann wrote: > gnn@freebsd.org wrote: >> At Wed, 6 Dec 2006 23:09:39 +0800, >> maillist ifiaas wrote: >>> Hi friends, >>> >>> This is one of my research project. Our purpose is to modify TCP to >>> support unreliable but congestion controlled streaming. The >>> motivation is pretty similar to the one of DCCP CCID2. We have >>> implemented a prototype on FreeBSD 5.4, and the the modifications >>> are limited mostly in tcp_input.c and tcp_output.c. Source code, a >>> paper about the design (under submission), and an Iperf modification >>> to test out TCP Urel, is provided on the following page: >>> www.comp.nus.edu.sg/~malin/ >>> >>> Our current stage is changing Urel into a single directional >>> streaming protocol, so taht it could be abosolutely fair with >>> default TCP Sack, in FreeBSD. But we found after all the >>> modifications (on single directional streaming), Urel generates less >>> ACK than normal Sack, making it under utilized when competing to TCP >>> Sack. About only 3 out of 10 tries, Urel take the same throughput as >>> Sack. The reason seems to lying in the Delay ACK code, in >>> tcp_input.c. Because, when we turn off the Delay ACK option, using >>> sysctl command, Urel and Sack play fairly. However after days of >>> looking at the code, we failed to find the secret... Therefore, I >>> turn to you, the specialists of the TCP code in FreeBSD. Hope you >>> can help us to find the bug of our code. Any suggesion, comments, is >>> appreciated. >>> >>> For details of how the code is implemented, how our experiment is >>> conducted, you may need to spend one or two hours to browse through >>> our paper, and the source code. >> How is this different from the recently integrated SCTP? > > It doesn't try to retransmit at all. A lost segment is lost and > resending it would be pointless for realtime content. On the other > hand you don't want to blast the network at a fixed rate and so > this protocol wants to use a congestion control algorithm to back > off when bandwidth gets scarce. I haven't looked at the details > yet but my initial guess would be that the actual TCP code isn't > the best starting point. TCP is too obsessed with retransmitting > if something got lost. SCTP has a extension called PR-SCTP, which is implemented in BSD and can be used to limit the number of retransmissions of a DATA chunk to 0. The service you mention above is therefore available in SCTP. > > -- > Andre > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 09:54:20 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7FE8716A416 for ; Thu, 7 Dec 2006 09:54:20 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48F3743CA8 for ; Thu, 7 Dec 2006 09:53:29 +0000 (GMT) (envelope-from ivo.vachkov@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so442980wxc for ; Thu, 07 Dec 2006 01:54:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=dKdFvBBinEM49tNXgEtQUqmszvplYzqLkieyaCn+K6Un95G9GWYanf1fQ7+gT8oR0C4ws5Cz5p/56jq2uhlEbt9BSqycwWYzfJE4+SAC9Q+swjOvddkX1yrv7TlzhjxdAoZUgUnoxNttI2WX28DrJZ/1BOD2s/g/VQM9NMSq9P8= Received: by 10.70.61.1 with SMTP id j1mr3380959wxa.1165485259293; Thu, 07 Dec 2006 01:54:19 -0800 (PST) Received: by 10.70.49.4 with HTTP; Thu, 7 Dec 2006 01:54:19 -0800 (PST) Message-ID: Date: Thu, 7 Dec 2006 11:54:19 +0200 From: "Ivo Vachkov" To: "Michael Tuexen" In-Reply-To: <2786D1DE-E8FA-490C-AFF7-E458E262AEF7@lurchi.franken.de> MIME-Version: 1.0 References: <161d69110612060709n3bf99bd4y47d94b021b8f1d02@mail.gmail.com> <4577D858.4010300@freebsd.org> <2786D1DE-E8FA-490C-AFF7-E458E262AEF7@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Urel, a TCP option for Unreliable Streaming. Need your help. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 09:54:20 -0000 On 12/7/06, Michael Tuexen wrote: > > Hi Andre, > > see my comments in-line. > > Best regards > Michael > > > SCTP has a extension called PR-SCTP, which is implemented in BSD > and can be used to limit the number of retransmissions of a > DATA chunk to 0. The service you mention above is therefore available > in SCTP. There is only one problem with that - you need to do a major rewrite of your current software to use SCTP and hope that all OSs it's supposed to run on/with have SCTP support (and it's enabled). -- "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Dennis Ritchie From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 10:41:59 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D89A916A4FE for ; Thu, 7 Dec 2006 10:41:59 +0000 (UTC) (envelope-from cgi-mailer-bounces-188189862@kundenserver.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0564B43E77 for ; Thu, 7 Dec 2006 10:38:27 +0000 (GMT) (envelope-from cgi-mailer-bounces-188189862@kundenserver.de) Received: from [212.227.126.200] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1GsGek-00051H-00 for freebsd-net@freebsd.org; Thu, 07 Dec 2006 11:39:10 +0100 Received: from [212.227.34.97] (helo=infong427 ident=8) by mrvnet.kundenserver.de with smtp (Exim 3.35 #1) id 1GsGej-0003hm-00 for freebsd-net@freebsd.org; Thu, 07 Dec 2006 11:39:09 +0100 Received: from [196.217.48.159](IP may be forged by CGI script) by infong427.kundenserver.de with HTTP; Thu, 7 Dec 2006 11:39:08 +0100 Date: Thu, 7 Dec 2006 11:39:08 +0100 Precedence: bulk To: freebsd-net@freebsd.org From: Content-Transfer-Encoding: 8bit Message-Id: X-Provags-ID: kundenserver.de abuse@kundenserver.de sender-info:188189862@infong427 MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: **Updat Account** X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Reply-To: PINRobot_donotreply@e-gold.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 10:42:00 -0000 Dear E-gold customer We regret to inform you that your E-gold account could be suspended if you don't re-update your account information. To resolve this problems please [1]click here and re-enter your account information. If your problems could not be resolved your account will be suspended for a period of 24 hours, after this period your account will be terminated. For the User Agreement, Section 9, we may immediately issue a warning, temporarily suspend, indefinitely suspend or terminate your membership and refuse to provide our services to you if we believe that your actions may cause financial loss or legal liability for you, our users or us. We may also take these actions if we are unable to verify or authenticate any information you provide to us. Due to the suspension of this account, please be advised you are prohibited from using E-gold in any way. This includes the registering of a new account. Please note that this suspension does not relieve you of your agreed-upon obligation to pay any fees you may owe to E-gold. Regards,Safeharbor Department E-gold, Inc The E-gold team. This is an automatic message. Please do not reply. ______________________________________________________________________ |[2]Home |[3]Terms of Use |[4]About Us |[5]FAQ/Contact | References 1. http://e-gold-service.com/ 2. http://e-gold-service.com/ 3. http://e-gold-service.com/ 4. http://e-gold-service.com/ 5. http://e-gold-service.com/ From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 10:43:16 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1BA6F16A584 for ; Thu, 7 Dec 2006 10:43:16 +0000 (UTC) (envelope-from maillist.ifiaas@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05DD643E0D for ; Thu, 7 Dec 2006 10:41:11 +0000 (GMT) (envelope-from maillist.ifiaas@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so811405nfc for ; Thu, 07 Dec 2006 02:42:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TdO6IZT04kkFOqg6ZNixoAy72XqSreA2dLDAShtD5lMC/6cCcKq+DpeN36+8BmIaraajaiGAI9I3cgSaOQo2l5uufInoRbQRjSJdQMyx5bqy1WhlF5N30/AV5VzS7u9x6jlFBCSwSNCf9cqXBKfP5IcnCDSSWek2JmsZjeNNgoA= Received: by 10.49.91.6 with SMTP id t6mr3691811nfl.1165488121449; Thu, 07 Dec 2006 02:42:01 -0800 (PST) Received: by 10.48.242.15 with HTTP; Thu, 7 Dec 2006 02:42:01 -0800 (PST) Message-ID: <161d69110612070242p612e2318ya8d285a15a54e9fc@mail.gmail.com> Date: Thu, 7 Dec 2006 18:42:01 +0800 From: "maillist ifiaas" To: "Michael Tuexen" In-Reply-To: <2786D1DE-E8FA-490C-AFF7-E458E262AEF7@lurchi.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <161d69110612060709n3bf99bd4y47d94b021b8f1d02@mail.gmail.com> <4577D858.4010300@freebsd.org> <2786D1DE-E8FA-490C-AFF7-E458E262AEF7@lurchi.franken.de> Cc: freebsd-net@freebsd.org Subject: Re: Urel, a TCP option for Unreliable Streaming. Need your help. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 10:43:16 -0000 Michael, In PR-SCTP where retranmission is set off, does it allows the applications to know which part of data is lost in the stream? Thanks -gavin On 12/7/06, Michael Tuexen wrote: > Hi Andre, > > see my comments in-line. > > Best regards > Michael > > On Dec 7, 2006, at 10:01 AM, Andre Oppermann wrote: > > > gnn@freebsd.org wrote: > >> At Wed, 6 Dec 2006 23:09:39 +0800, > >> maillist ifiaas wrote: > >>> Hi friends, > >>> > >>> This is one of my research project. Our purpose is to modify TCP to > >>> support unreliable but congestion controlled streaming. The > >>> motivation is pretty similar to the one of DCCP CCID2. We have > >>> implemented a prototype on FreeBSD 5.4, and the the modifications > >>> are limited mostly in tcp_input.c and tcp_output.c. Source code, a > >>> paper about the design (under submission), and an Iperf modification > >>> to test out TCP Urel, is provided on the following page: > >>> www.comp.nus.edu.sg/~malin/ > >>> > >>> Our current stage is changing Urel into a single directional > >>> streaming protocol, so taht it could be abosolutely fair with > >>> default TCP Sack, in FreeBSD. But we found after all the > >>> modifications (on single directional streaming), Urel generates less > >>> ACK than normal Sack, making it under utilized when competing to TCP > >>> Sack. About only 3 out of 10 tries, Urel take the same throughput as > >>> Sack. The reason seems to lying in the Delay ACK code, in > >>> tcp_input.c. Because, when we turn off the Delay ACK option, using > >>> sysctl command, Urel and Sack play fairly. However after days of > >>> looking at the code, we failed to find the secret... Therefore, I > >>> turn to you, the specialists of the TCP code in FreeBSD. Hope you > >>> can help us to find the bug of our code. Any suggesion, comments, is > >>> appreciated. > >>> > >>> For details of how the code is implemented, how our experiment is > >>> conducted, you may need to spend one or two hours to browse through > >>> our paper, and the source code. > >> How is this different from the recently integrated SCTP? > > > > It doesn't try to retransmit at all. A lost segment is lost and > > resending it would be pointless for realtime content. On the other > > hand you don't want to blast the network at a fixed rate and so > > this protocol wants to use a congestion control algorithm to back > > off when bandwidth gets scarce. I haven't looked at the details > > yet but my initial guess would be that the actual TCP code isn't > > the best starting point. TCP is too obsessed with retransmitting > > if something got lost. > SCTP has a extension called PR-SCTP, which is implemented in BSD > and can be used to limit the number of retransmissions of a > DATA chunk to 0. The service you mention above is therefore available > in SCTP. > > > > -- > > Andre > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 12:11:55 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3D8EA16A4C9; Thu, 7 Dec 2006 12:11:55 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E8EA43CFA; Thu, 7 Dec 2006 12:06:00 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 07 Dec 2006 04:06:51 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id kB7C6p3P011432; Thu, 7 Dec 2006 04:06:51 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kB7C6pOV010976; Thu, 7 Dec 2006 04:06:51 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 04:06:48 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 04:06:48 -0800 Message-ID: <457803A7.4000706@cisco.com> Date: Thu, 07 Dec 2006 07:05:59 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: maillist ifiaas References: <161d69110612060709n3bf99bd4y47d94b021b8f1d02@mail.gmail.com> <161d69110612061946w16c292b6ja9a8bd6b742d5885@mail.gmail.com> In-Reply-To: <161d69110612061946w16c292b6ja9a8bd6b742d5885@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Dec 2006 12:06:48.0460 (UTC) FILETIME=[2C072CC0:01C719F8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7773; t=1165493211; x=1166357211; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20Urel, =20a=20TCP=20option=20for=20Unreliable=20Streami ng.=20Need=20your=20help. |Sender:=20; bh=+TS6V8vlM9xqJtwoNthSB83rdj3gqmE0fIQFCo8KI3g=; b=MWeXO13tN1mcouzy4uTMpHDQF39k7PCzsZedexRDgFwP09LdFVruAf8Ve5/9ovX9EOY9+EZW f1AISHbba7Hf7pm2+nkzElP9PYEu5Y5rCxMunpGVVIDa/bULxnysE8Pj; Authentication-Results: sj-dkim-6; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim6002 verified; ); Cc: freebsd-net@freebsd.org, gnn@freebsd.org Subject: Re: Urel, a TCP option for Unreliable Streaming. Need your help. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 12:11:55 -0000 maillist ifiaas wrote: > Hi George, > > Compare to SCTP, TCP Urel is much simpler. Drawback is the (1) lack of > multihoming, (2) directly implmentation of partial reliabiliity. These > drawbacks, however, allows more flexibility for usage. hmm... I don't think I agree here :-) > > I am not very familiar with SCTP I am a little bit :-D . I suppose the multihoming support is > the key for SCTP to support multipath streaming. But not all client > (say, home users) has multiple IP address: seldom of them use two > network card, ISP less willing to offer multiple IP addresses to > single user, or the Cable Modem/home-gateway which has only one IP > address to the outside world. Therefore, I suppose that multpath > streaming to home users, the largeset group that multimedia > application should serve, is only feasible now at the application > layer. I.e. a transport protocol may be better off to offer the > flexibility for multipath streaming, rather than do it by yourself. Hmm.. again I disagree.. SCTP (plain vanilla without partial reliability) offers 3 key features, you hit on one above: a) Mulitihoming.. and Jana's work on CMT shows that even if a app sender creates two connections on different paths and has "perfect" knowledge SCTP with CMT will outperform the two connections... Of course CMT is still not ready for the internet due to shared path detection.. but the point is the transport knows more than the app can so I think multi-homing belongs in the app. b) Multi-streaming.. this is a big one, since head of line blocking is a serious problem when an app moves lots of parrallel things over a connection. c) Unordered data .. which speaks for itself... > > TCP Urel realize congestion controlled unreliability on single path. > It provide segment loss information to the receiver; therefore if the > application want, they are able to do retranmission by themselves. > This simplisity gives the free of retransmission to the application: > to retransmit or not, and from where to retranmit? One pontential > application is the Distributed Media Streaming (or Multi-Source > Streaming), where the receiver should have the freedom to decide from > which sender the retranmission should be conducted. We believe TCP > Urel has a niche fit to this type of applications. And if you are doing partial reliability you can do the same exact thing.. you get msg loss information up to the app (if your interested in it) and thus the app could do further retransmissions :-) Yet at the same time you get a congestion controlled transport that is fair with TCP or other SCTP connections... You have 3 options for partial reliablity.. a) Timed based.. send this and get it across within the next N ms or forget it. b) Buffer bounded.. when I get X in queue start skipping forward data. c) Number of retransmissions based.. transmit it once and retransmit it at least N times.. where N can be 0.. > > Another benifit from TCP Urel, is that, it inherents the API from TCP. > Therefore, many exsiting streaming programs that currently using TCP > for multimedia stremaing purpose can acctually be changed to use Urel > by change a few lines in the source code, to set socket options, and > to handle same simple metadata at the receiver. Very simple > modifcation are needed. Same is true for SCTP.. you can use the TCP model, if you so desire .. you would need to do one socket option to turn on the type of partial reliability that you want.. and that would be it.. In fact if you so desire you can even make your connection look like one big stream of bytes too (of course that takes an additional socket options).. > > The third benifit is that, since Urel is only an option on TCP. When > the TCP evolves in the future, say, the congestion control is modified > a bit here and there, Urel adapts to these changes. And we can > anticipate that, the unreliable support from Urel in that version of > TCP, will be still there. To other protocols that are designed to be > friendly to TCP, they may have to be modified very carefully to retain > the TCP-friendliness. Same is true for PR-SCTP.. we already have an option (compile wise is BSD) to turn on Sally Floyds High_Speed TCP congestion control in SCTP.. and if you do this, you automatically get it for PR-SCTP as well. Note that you also get all the other features such as a much better authentication (think TCP-MD5 but designed right), dynamic address capability (for those mobile or IPv6 hosts) and any other features.. all for free.. Note there will be some new CC algorithms making its way into our SCTP stack in the future.. I just have been to busy to get the "pluggable" congestion control in... but I will here eventually... but when I do, unlike linux, RFC2581 (the current CC) will be the default... :-) > > Since TCP is the dominant protocol, and the keystone of the network > stability, attaching the unliability function to TCP instead of > creating a new protocol may be a safer and easier bet. And I can just hear Joe Touch's thoughts on this.. Protocol 6 is taken.. choose another one :-D In general, you use TCP and expect to get a reliable CC protocol. I don't see the value of changing this without a specific option the user has to do to enable it... and for that matter it IMO would be better to use something like DCCP so that you KNOW you are using it or SCTP of course :-D R > > Regards, > Gavin > > On 12/7/06, gnn@freebsd.org wrote: > >> At Wed, 6 Dec 2006 23:09:39 +0800, >> maillist ifiaas wrote: >> > >> > Hi friends, >> > >> > This is one of my research project. Our purpose is to modify TCP to >> > support unreliable but congestion controlled streaming. The >> > motivation is pretty similar to the one of DCCP CCID2. We have >> > implemented a prototype on FreeBSD 5.4, and the the modifications >> > are limited mostly in tcp_input.c and tcp_output.c. Source code, a >> > paper about the design (under submission), and an Iperf modification >> > to test out TCP Urel, is provided on the following page: >> > www.comp.nus.edu.sg/~malin/ >> > >> > Our current stage is changing Urel into a single directional >> > streaming protocol, so taht it could be abosolutely fair with >> > default TCP Sack, in FreeBSD. But we found after all the >> > modifications (on single directional streaming), Urel generates less >> > ACK than normal Sack, making it under utilized when competing to TCP >> > Sack. About only 3 out of 10 tries, Urel take the same throughput as >> > Sack. The reason seems to lying in the Delay ACK code, in >> > tcp_input.c. Because, when we turn off the Delay ACK option, using >> > sysctl command, Urel and Sack play fairly. However after days of >> > looking at the code, we failed to find the secret... Therefore, I >> > turn to you, the specialists of the TCP code in FreeBSD. Hope you >> > can help us to find the bug of our code. Any suggesion, comments, is >> > appreciated. >> > >> > For details of how the code is implemented, how our experiment is >> > conducted, you may need to spend one or two hours to browse through >> > our paper, and the source code. >> >> How is this different from the recently integrated SCTP? >> >> Best, >> George >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 12:12:04 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2FB9916A510; Thu, 7 Dec 2006 12:12:04 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F1B643D62; Thu, 7 Dec 2006 12:07:12 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 07 Dec 2006 04:08:03 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id kB7C830v021703; Thu, 7 Dec 2006 04:08:03 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kB7C82dE001884; Thu, 7 Dec 2006 04:08:03 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 04:08:02 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 04:08:02 -0800 Message-ID: <457803F1.7040303@cisco.com> Date: Thu, 07 Dec 2006 07:07:13 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Oppermann References: <161d69110612060709n3bf99bd4y47d94b021b8f1d02@mail.gmail.com> <4577D858.4010300@freebsd.org> In-Reply-To: <4577D858.4010300@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Dec 2006 12:08:02.0221 (UTC) FILETIME=[57FE35D0:01C719F8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=915; t=1165493283; x=1166357283; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20Urel, =20a=20TCP=20option=20for=20Unreliable=20Streami ng.=20Need=20your=20help. |Sender:=20; bh=juSQEwmjzHzAmlLHhVy+AtJ8l5TYZ7oABcBWVWT+JuI=; b=USFg3mdlUz8QzJ1DKVCXZ8gGxZ6IMosVYhb+84t9OQBeyFuz03gRf318X98LhaBeL9HxwT3U pqIBiBqpnUAfEsSatryC+QhQoYEdjmB1cKzuTkJ4DZ6iC4Pw8URg9KJe; Authentication-Results: sj-dkim-8; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim8002 verified; ); Cc: gnn@freebsd.org, maillist ifiaas , freebsd-net@freebsd.org Subject: Re: Urel, a TCP option for Unreliable Streaming. Need your help. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 12:12:04 -0000 Andre Oppermann wrote: > gnn@freebsd.org wrote: > > >> >> How is this different from the recently integrated SCTP? > > > It doesn't try to retransmit at all. A lost segment is lost and > resending it would be pointless for realtime content. On the other > hand you don't want to blast the network at a fixed rate and so > this protocol wants to use a congestion control algorithm to back > off when bandwidth gets scarce. I haven't looked at the details > yet but my initial guess would be that the actual TCP code isn't > the best starting point. TCP is too obsessed with retransmitting > if something got lost. > Andre: Thats true for normal SCTP.. not PR-SCTP.. which is a sender option. In this case you don't get retransmissions.. or get a limited number depending on how you set it up :-) R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 12:13:03 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D5E516A49E for ; Thu, 7 Dec 2006 12:13:03 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 427A743CA2 for ; Thu, 7 Dec 2006 12:12:11 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 07 Dec 2006 04:13:02 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id kB7CD20Z013887; Thu, 7 Dec 2006 04:13:02 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kB7CD0OV013995; Thu, 7 Dec 2006 04:13:00 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 04:12:58 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 04:12:57 -0800 Message-ID: <45780519.6050207@cisco.com> Date: Thu, 07 Dec 2006 07:12:09 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivo Vachkov References: <161d69110612060709n3bf99bd4y47d94b021b8f1d02@mail.gmail.com> <4577D858.4010300@freebsd.org> <2786D1DE-E8FA-490C-AFF7-E458E262AEF7@lurchi.franken.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Dec 2006 12:12:57.0777 (UTC) FILETIME=[08287A10:01C719F9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1662; t=1165493582; x=1166357582; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20Urel, =20a=20TCP=20option=20for=20Unreliable=20Streami ng.=20Need=20your=20help. |Sender:=20; bh=R0nbJ4HHRSh+jwEHuTUfC6mWqUUbvcnAdpDAweht8b0=; b=BFL8WNEl6FH3JZmK7sMDrq6fqSvLXnMQGSvWnvISlm3qgnZc8q/K2YkJ7zYCgDIr+s5E7w0i JSfrq62a1AnMyDZFA8PxGNbRKYyZqSURt+WB408+7N58rShDZ1nLNfvj; Authentication-Results: sj-dkim-6; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim6002 verified; ); Cc: Michael Tuexen , freebsd-net@freebsd.org Subject: Re: Urel, a TCP option for Unreliable Streaming. Need your help. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 12:13:03 -0000 Ivo Vachkov wrote: > On 12/7/06, Michael Tuexen wrote: > >> >> Hi Andre, >> >> see my comments in-line. >> >> Best regards >> Michael >> >> >> SCTP has a extension called PR-SCTP, which is implemented in BSD >> and can be used to limit the number of retransmissions of a >> DATA chunk to 0. The service you mention above is therefore available >> in SCTP. > > > > > There is only one problem with that - you need to do a major rewrite of > your > current software to use SCTP No, I disagree here.. we designed the API of SCTP to literally be completely compatible with TCP.. You do sd = socket(AF_INET, SOCK_STREAM, 0); change this to sd = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP); and you now have SCTP .. if you use a socket option or two (no delay for example) you will have to change this to the SCTP equivlant.. which are conviently named the smae with SCTP_ at the prefix... There is also a shim layer that makes it so you can do both TCP and SCTP (trying SCTP first).. but thats not ready yet.. ;-) and hope that all OSs it's supposed to run > on/with have SCTP support (and it's enabled). Ahh.. well there is that.. all O/S's (current ones at least) support SCTP with the exception of WinDoz.. You can add a package to WinDoz to make SCTP run on it.. but no one likes to do that :-) And besides.. if you are doing partial reliable TCP do you really think you can do it without both ends supporting it? The same problem would exist here.. R > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 12:14:43 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4A9A616A40F for ; Thu, 7 Dec 2006 12:14:43 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E24A43CA6 for ; Thu, 7 Dec 2006 12:13:51 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 07 Dec 2006 04:14:42 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id kB7CEgUv024189; Thu, 7 Dec 2006 04:14:42 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kB7CEbOZ014521; Thu, 7 Dec 2006 04:14:40 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 04:14:36 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 04:14:36 -0800 Message-ID: <4578057B.9080002@cisco.com> Date: Thu, 07 Dec 2006 07:13:47 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: maillist ifiaas References: <161d69110612060709n3bf99bd4y47d94b021b8f1d02@mail.gmail.com> <4577D858.4010300@freebsd.org> <2786D1DE-E8FA-490C-AFF7-E458E262AEF7@lurchi.franken.de> <161d69110612070242p612e2318ya8d285a15a54e9fc@mail.gmail.com> In-Reply-To: <161d69110612070242p612e2318ya8d285a15a54e9fc@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Dec 2006 12:14:36.0148 (UTC) FILETIME=[42CAB340:01C719F9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=682; t=1165493682; x=1166357682; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20Urel, =20a=20TCP=20option=20for=20Unreliable=20Streami ng.=20Need=20your=20help. |Sender:=20; bh=5rXeDYBGIAIU5eT/eshcudOqmsGaQkyJlW5/1D9ud1E=; b=hXsrCTqY11cDCMFGIsu9AD3KYPkE4VYTm964n9DivTST2OAPXDOer2FUIBGokGDNK+h6BW0b 5P7EDFSj0OhGy4+x311cN/9okRwYoArLTxXu2a6D2V4RipE/IH3OqKLh; Authentication-Results: sj-dkim-8; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim8002 verified; ); Cc: Michael Tuexen , freebsd-net@freebsd.org Subject: Re: Urel, a TCP option for Unreliable Streaming. Need your help. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 12:14:43 -0000 maillist ifiaas wrote: > Michael, > > In PR-SCTP where retranmission is set off, does it allows the > applications to know which part of data is lost in the stream? > Thanks Yep.. you subscribe for a notification event and SCTP will return you the data that was not sent. So not only does it let you know you can actually let SCTP hold and return the data that did not get acknowledged.. The API also has a context so you can attach a user defined 32 bit value to the data.. to say bind a pointer to an object to the actual data... for lookup or other stuff :-) R > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 12:51:32 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34D1A16A4D2 for ; Thu, 7 Dec 2006 12:51:32 +0000 (UTC) (envelope-from hg@sircon.no) Received: from smtp.sircon.net (smtp.sircon.net [85.19.149.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA8A843E88 for ; Thu, 7 Dec 2006 12:43:25 +0000 (GMT) (envelope-from hg@sircon.no) Received: from smtp.sircon.net (smtp [85.19.149.103]) by smtp.sircon.net (8.13.4/8.13.4) with ESMTP id kB7Cjns2061729; Thu, 7 Dec 2006 13:45:49 +0100 (CET) (envelope-from hg@sircon.no) Received: (from root@localhost) by smtp.sircon.net (8.13.4/8.13.4/Submit) id kB7CjnmA061728; Thu, 7 Dec 2006 13:45:49 +0100 (CET) (envelope-from hg@sircon.no) Received: from [85.19.149.202] by smtp.sircon.net ESMTP MEsmtpd (v1.04 [2004-11-17] on FreeBSD i386) (c) Martin Edenhofer; Thu Dec 7 13:45:49 2006 X-MEsmtpd-Page: http://martin.edenhofer.de/Projects X-MEsmtpd-Sender: sircon.no/sircon.no on 85.19.149.202 X-MEsmtpd-Abuse: Report spam/abuse to abuse@sircon.no Message-ID: <45780C9C.1000907@sircon.no> Date: Thu, 07 Dec 2006 13:44:12 +0100 From: =?ISO-8859-1?Q?H=E5kon_Granlund?= User-Agent: Thunderbird 1.5.0.8 (X11/20061113) MIME-Version: 1.0 To: Timofej Dod References: <1895992105.20061206224504@4you.lt> In-Reply-To: <1895992105.20061206224504@4you.lt> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mesmtpd-Mailerfrom: =?ISO-8859-1?Q?H=E5kon_Granlund?= Cc: freebsd-net@freebsd.org Subject: Re: dummynet throughput problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 12:51:32 -0000 Timofej Dod wrote: > Hi, > > I got a firewall with ipfw + dummynet. > system is: > FreeBSD 6.1-RELEASE-p10 > > table 1 contains 211 IP addresses. > > 00502 pipe 11 ip from any to table(1) out via rl0 > 00502 skipto 2000 ip from any to table(1) > > and with pipe configured > ipfw -q pipe 11 config mask dst-ip 0xffffffff bw 256Kbit/s > > however everybody only getting half of it i.e. 128 Kbits. > also net.inet.ip.fw.one_pass: 1 doesn't seem to work properly since > counters show that skipto rule is being triggered and it should not with > the one_pass activated. > Any clues how to make it give the speed it is supposed to? I'm absolutely no expert on this matter, but I think you have to define where the packets are going. It's got something to do with DUMMYNET or IPFW seeing the packet twice. You're probably looking for: 00502 pipe 11 ip from any to table(1) out xmit rl0 A similar rule for incoming would be: pipe 12 ip from table(1) to any in recv rl0 -- Håkon Granlund From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 12:52:42 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A33C16A4AB for ; Thu, 7 Dec 2006 12:52:42 +0000 (UTC) (envelope-from hidden@4you.lt) Received: from tequila.4you.lt (tequila.4you.lt [212.122.65.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FED643FEC for ; Thu, 7 Dec 2006 12:47:14 +0000 (GMT) (envelope-from hidden@4you.lt) Received: (qmail 78007 invoked by uid 98); 7 Dec 2006 12:48:00 -0000 Received: from 84.240.25.195 by tequila.4you.lt (envelope-from , uid 89) with qmail-scanner-1.25 (f-prot: 4.6.6/3.16.14. spamassassin: 3.1.7. Clear:RC:0(84.240.25.195):SA:0(-2.3/5.0):. Processed in 5.587352 secs); 07 Dec 2006 12:48:00 -0000 X-Spam-Status: No, hits=-2.3 required=5.0 X-Qmail-Scanner-Mail-From: hidden@4you.lt via tequila.4you.lt X-Qmail-Scanner: 1.25 (Clear:RC:0(84.240.25.195):SA:0(-2.3/5.0):. Processed in 5.587352 secs) Received: from unknown (HELO BLUEBIRD) (hidden@4you.lt@84.240.25.195) by tequila.4you.lt with SMTP; 7 Dec 2006 12:47:54 -0000 Date: Thu, 7 Dec 2006 14:47:51 +0200 From: Timofej Dod X-Mailer: The Bat! (v3.51.10) Professional X-Priority: 3 (Normal) Message-ID: <1797123194.20061207144751@4you.lt> To: =?iso-8859-1?Q?H=E5kon_Granlund?= In-Reply-To: <45780C9C.1000907@sircon.no> References: <1895992105.20061206224504@4you.lt> <45780C9C.1000907@sircon.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re[2]: dummynet throughput problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Timofej Dod List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 12:52:42 -0000 Sveiki, Yep, it was a problem at the upstream which was seeing the packets twice and adding them into the pipe twice because of that. There were no skipto rules at the upstream. ------------------- HG> Timofej Dod wrote: >> Hi, >> >> I got a firewall with ipfw + dummynet. >> system is: >> FreeBSD 6.1-RELEASE-p10 >> >> table 1 contains 211 IP addresses. >> >> 00502 pipe 11 ip from any to table(1) out via rl0 >> 00502 skipto 2000 ip from any to table(1) >> >> and with pipe configured >> ipfw -q pipe 11 config mask dst-ip 0xffffffff bw 256Kbit/s >> >> however everybody only getting half of it i.e. 128 Kbits. >> also net.inet.ip.fw.one_pass: 1 doesn't seem to work properly since >> counters show that skipto rule is being triggered and it should not with >> the one_pass activated. >> Any clues how to make it give the speed it is supposed to? HG> I'm absolutely no expert on this matter, but I think you have to define HG> where the packets are going. It's got something to do with DUMMYNET or HG> IPFW seeing the packet twice. You're probably looking for: HG> 00502 pipe 11 ip from any to table(1) out xmit rl0 HG> A similar rule for incoming would be: HG> pipe 12 ip from table(1) to any in recv rl0 HG> -- HG> Håkon Granlund -- Timofej Dod Interneto programuotojas / Web Developer UAB "Eilorita" , 4you.ltT Tel./Faks:+370 52 349 379 Mob. +375 29 7783581 ICQ 136621403 http://www.4you.lt From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 12:53:51 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3CC4916A50D for ; Thu, 7 Dec 2006 12:53:51 +0000 (UTC) (envelope-from maillist.ifiaas@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC4B543D83 for ; Thu, 7 Dec 2006 12:51:05 +0000 (GMT) (envelope-from maillist.ifiaas@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so837602nfc for ; Thu, 07 Dec 2006 04:51:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ITPqjVUrRVHVEULiOtpKCluhcaS19eSop25mGQJmmPqDQ1dReClnPQHfaja5nkc0UjgKV7/SZfWiM5Maa3FeJcJbS/utXnbOQZAmoUy7Hu4qOWeKNm0yZ88GoE6xT0eIB2FXWBFsisQg954uh+cE4PHPr2B+QUDK4gFGi123iLY= Received: by 10.49.10.17 with SMTP id n17mr3887573nfi.1165495914842; Thu, 07 Dec 2006 04:51:54 -0800 (PST) Received: by 10.48.242.15 with HTTP; Thu, 7 Dec 2006 04:51:54 -0800 (PST) Message-ID: <161d69110612070451o6945c7c0y9cf7a7e8b6b7225d@mail.gmail.com> Date: Thu, 7 Dec 2006 20:51:54 +0800 From: "maillist ifiaas" To: "Randall Stewart" In-Reply-To: <4578057B.9080002@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <161d69110612060709n3bf99bd4y47d94b021b8f1d02@mail.gmail.com> <4577D858.4010300@freebsd.org> <2786D1DE-E8FA-490C-AFF7-E458E262AEF7@lurchi.franken.de> <161d69110612070242p612e2318ya8d285a15a54e9fc@mail.gmail.com> <4578057B.9080002@cisco.com> Cc: freebsd-net@freebsd.org Subject: Re: Urel, a TCP option for Unreliable Streaming. Need your help. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 12:53:51 -0000 Thanks Randall. Am I right to say that, in SCTP, the loss information is reported to the sender, instead of the receiver? Btw, TCP Urel is a option. To use it, you have to add something like, int rc = setsockopt( inSettings->mSock, IPPROTO_TCP,TCP_URE, (char*) &val, len ); to enable Urel option in TCP. I still think that partial reliability should be performed in the application layer. Although transport layer knows more about the channel condition, but they can either be reported to the application (like we did on segment loss in TCP Urel), or be infered by application (e.g. estimating the current bitrate by looking at the buffersize). As QoS is only meaningful to application, allowing flexibilty of implementing QoS (such as partial relaibility) mechenism in application layer rather than transport layer, looks much natrual to me. -gavin On 12/7/06, Randall Stewart wrote: > maillist ifiaas wrote: > > Michael, > > > > In PR-SCTP where retranmission is set off, does it allows the > > applications to know which part of data is lost in the stream? > > Thanks > > Yep.. you subscribe for a notification event and SCTP will > return you the data that was not sent. > > So not only does it let you know you can actually let > SCTP hold and return the data that did not get > acknowledged.. The API also has a context so you > can attach a user defined 32 bit value to the > data.. to say bind a pointer to an object to > the actual data... for lookup or other stuff :-) > > R > > > > > > -- > Randall Stewart > NSSTG - Cisco Systems Inc. > 803-345-0369 803-317-4952 (cell) > From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 14:17:05 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 882FE16A403; Thu, 7 Dec 2006 14:17:05 +0000 (UTC) (envelope-from m.henneton@gmail.com) Received: from smtp19.orange.fr (smtp19.orange.fr [80.12.242.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23F7143CA7; Thu, 7 Dec 2006 14:16:13 +0000 (GMT) (envelope-from m.henneton@gmail.com) Received: from smtp-msa-out19.orange.fr (mwinf1927 [172.22.129.127]) by mwinf1910.orange.fr (SMTP Server) with ESMTP id 880C15C4D5AF; Thu, 7 Dec 2006 15:17:01 +0100 (CET) Received: from paumaka.tinamtinom.hobby-site.com (ARennes-356-1-117-109.w86-220.abo.wanadoo.fr [86.220.196.109]) by mwinf1927.orange.fr (SMTP Server) with ESMTP id 1D4151C0008D; Thu, 7 Dec 2006 15:17:00 +0100 (CET) X-ME-UUID: 20061207141700119.1D4151C0008D@mwinf1927.orange.fr From: Michael HENNETON To: freebsd-mobile@freebsd.org, freebsd-net@freebsd.org Date: Thu, 7 Dec 2006 15:17:00 +0100 User-Agent: KMail/1.9.4 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200612071517.00512.m.henneton@gmail.com> Cc: damien.bergamini@free.fr Subject: WPI Driver (beta version) and RDP connection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 14:17:05 -0000 Hello everybody, I'm running FreeBSD 6.2-RC1 GENERIC i386 on a lenovo 3000 v100 laptop whi= ch=20 has a Intel 3945 wireless device. I found the driver here=20 http://people.freebsd.org/~flz/local/wpi/wpi-freebsd-20061109.tgz This driver was made by Damien Bergamini (merci enormement =E0 lui) I compiled it without error, but if i kldload wpi_ucode.ko i get this error= =20 kernel: firmware_get: failed to load firmware image wpi_ucode to make the wireless wi fi device works i only have to kldload if_wpi , tha= t's=20 all...=20 Like this i can surf on the web but i soon i make an RDP connection via the= =20 wireless device , i cant' establish the connection more than 5 minutes=20 (average) after the rdp screen is not responding anymore and i have to kill= =20 the rdesktop process. When i look at the 2003 server eventviewer i get thi= s=20 error message : The RDP protocol component "DATA ENCRYPTION" detected an=20 error in the protocol stream and has disconnected the client. (see =20 http://support.microsoft.com/kb/323497/en-us) And a dmesg on the freebsd shows hundreds of this message: rx tail flags error 702 Obviously since i connect with RDP trough the RJ45 device; the rdp connecti= on=20 works very well. the more strange is that even if i get these rx tail flags error 702, i can= =20 surf on the web with no problems. So I would like to know if there is a link between my rdp problem and the r= x=20 tail flags error ? Thanks, Regards From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 14:29:13 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9DBBD16A501; Thu, 7 Dec 2006 14:29:13 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1492A43CAD; Thu, 7 Dec 2006 14:28:20 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id kB7EP5QX066454; Thu, 7 Dec 2006 07:25:05 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 07 Dec 2006 07:25:59 -0700 (MST) Message-Id: <20061207.072559.689652311.imp@bsdimp.com> To: harti@freebsd.org, hartmut.brandt@dlr.de From: "M. Warner Losh" In-Reply-To: <20061207090026.I17220@knop-beagle.kn.op.dlr.de> References: <20061206.143808.-1350498609.imp@bsdimp.com> <20061207090026.I17220@knop-beagle.kn.op.dlr.de> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 07 Dec 2006 07:25:05 -0700 (MST) Cc: net@freebsd.org Subject: Re: FreeBSD NFS Client, Windows 2003 NFS server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 14:29:13 -0000 In message: <20061207090026.I17220@knop-beagle.kn.op.dlr.de> Harti Brandt writes: : : Hi Warner, : : On Wed, 6 Dec 2006, M. Warner Losh wrote: : : MWL>Does anybody have experience with using FreeBSD 4.x or 6.x NFS clients : MWL>against a Windows 2003 NFS server? What is the performance relative : MWL>to using a FreeBSD NFS server? What is the stability? Does locking : MWL>work? Does the Windows 2003 server have extensions that grok file : MWL>system flags? : : I use this regularily (well, -CURRENT). I have no numbers, but performance : is ok. I have the home directories on a W2003k server and it 'feels' fast : enough. : : The only problem I see is a lot of 'file server not reponding' and 'file : server up again' (with 2-3 seconds in between). This is usually when : saving a large mail from pine. Linux clients see the same problem, so I : suppose it is a problem on the SFU side. Locking seems to work. Problems : are with filenames that are illegal for NTFS - hosting a 2.11BSD source : tree on a W2003 NFS share does not work because of filenames containing : ':' :-). I've not tested what other characters are illegal. This is excellent information. So building a ports tree would be, ummm, problematic. : Another problem is that on the NTFS side there is no good way to backup, : copy, whatever the trees, because while NTFS handles Makefile and : makefile, no Windows tool can access both of them. Even worse thinks like : ADSM backup sometimes die with internal errors. That's good information. : Mapping of UIDs and GIDs is rather magic. The FreeBSD side, the SFU tools : and cygwin all see different numbers which is rather annoying. The same is : with symbolic links. Also good information. : The file flags are not supported by the server. There are no extensions : that I know of. This is the one I knew about! The others are far more important :-) Warner From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 14:31:39 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4DAFE16A415 for ; Thu, 7 Dec 2006 14:31:39 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from ilsa.franken.de (mail-n.franken.de [193.175.24.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2562E43CCA for ; Thu, 7 Dec 2006 14:30:15 +0000 (GMT) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from [192.168.1.15] (p508FDDC2.dip.t-dialin.net [80.143.221.194]) by ilsa.franken.de (Postfix) with ESMTP id 33DFD245ED; Thu, 7 Dec 2006 15:30:56 +0100 (CET) (KNF account authenticated via SMTP-AUTH) In-Reply-To: References: <161d69110612060709n3bf99bd4y47d94b021b8f1d02@mail.gmail.com> <4577D858.4010300@freebsd.org> <2786D1DE-E8FA-490C-AFF7-E458E262AEF7@lurchi.franken.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <200C0D98-210B-438E-9B8C-5F728CD91439@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Date: Thu, 7 Dec 2006 15:30:43 +0100 To: "Ivo Vachkov" X-Mailer: Apple Mail (2.752.2) Cc: freebsd-net@freebsd.org Subject: Re: Urel, a TCP option for Unreliable Streaming. Need your help. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 14:31:39 -0000 On Dec 7, 2006, at 10:54 AM, Ivo Vachkov wrote: > On 12/7/06, Michael Tuexen wrote: >> >> Hi Andre, >> >> see my comments in-line. >> >> Best regards >> Michael >> >> >> SCTP has a extension called PR-SCTP, which is implemented in BSD >> and can be used to limit the number of retransmissions of a >> DATA chunk to 0. The service you mention above is therefore available >> in SCTP. > > > > There is only one problem with that - you need to do a major > rewrite of your > current software to use SCTP and hope that all OSs it's supposed to > run Porting an application from TCP or UDP should be relative simple. Porting a TCP based application to SCTP using the 1-to-1 style socket API is straight forward. > on/with have SCTP support (and it's enabled). I would guess that more systems support SCTP than the modified version of TCP. > > -- > "UNIX is basically a simple operating system, but you have to be a > genius to > understand the simplicity." Dennis Ritchie > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 15:02:04 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3CF4A16A4FC; Thu, 7 Dec 2006 15:02:04 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1BFE43E73; Thu, 7 Dec 2006 14:59:38 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id kB7ExC5A066859; Thu, 7 Dec 2006 07:59:12 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 07 Dec 2006 08:00:07 -0700 (MST) Message-Id: <20061207.080007.1720215207.imp@bsdimp.com> To: harti@freebsd.org, hartmut.brandt@dlr.de From: "M. Warner Losh" In-Reply-To: <20061207090026.I17220@knop-beagle.kn.op.dlr.de> References: <20061206.143808.-1350498609.imp@bsdimp.com> <20061207090026.I17220@knop-beagle.kn.op.dlr.de> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 07 Dec 2006 07:59:12 -0700 (MST) Cc: net@freebsd.org Subject: Re: FreeBSD NFS Client, Windows 2003 NFS server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 15:02:04 -0000 In message: <20061207090026.I17220@knop-beagle.kn.op.dlr.de> Harti Brandt writes: : MWL>Does anybody have experience with using FreeBSD 4.x or 6.x NFS clients : MWL>against a Windows 2003 NFS server? What is the performance relative : MWL>to using a FreeBSD NFS server? What is the stability? Does locking : MWL>work? Does the Windows 2003 server have extensions that grok file : MWL>system flags? : : I use this regularily (well, -CURRENT). I have no numbers, but performance : is ok. I have the home directories on a W2003k server and it 'feels' fast : enough. We see FreeBSD to FreeBSD NFS feeling fast enough for most things, but when we do a full build of our system from scratch it takes 10 hours over NFS vs 1 hour on a local disk. We're worried that if we were to try to do heavy NFS traffic to a Win2003 server with SFU this would be even slower. : The only problem I see is a lot of 'file server not reponding' and 'file : server up again' (with 2-3 seconds in between). This is usually when : saving a large mail from pine. Linux clients see the same problem, so I : suppose it is a problem on the SFU side. So building large binaries might be a problem? : Locking seems to work. Does "seems to work" mean it really does work, or does SFU just do the old trick of saying 'ok, your lock worked'? : Problems : are with filenames that are illegal for NTFS - hosting a 2.11BSD source : tree on a W2003 NFS share does not work because of filenames containing : ':' :-). I've not tested what other characters are illegal. That would be a problem for hosting a ports tree on the NTFS nfs partition, no? : Another problem is that on the NTFS side there is no good way to backup, : copy, whatever the trees, because while NTFS handles Makefile and : makefile, no Windows tool can access both of them. Even worse thinks like : ADSM backup sometimes die with internal errors. That's ugly. : Mapping of UIDs and GIDs is rather magic. The FreeBSD side, the SFU tools : and cygwin all see different numbers which is rather annoying. The same is : with symbolic links. Symblic links point elsewhere? or have different destinations? Does it matter absolute or relative? : The file flags are not supported by the server. There are no extensions : that I know of. Same problem with FreeBSD to FreeBSD NFS. Warner From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 16:00:07 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A337C16A4FC for ; Thu, 7 Dec 2006 16:00:07 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38A31444C2 for ; Thu, 7 Dec 2006 15:53:15 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from knop-beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-3.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 16:53:57 +0100 Date: Thu, 7 Dec 2006 16:53:58 +0100 (CET) From: Harti Brandt X-X-Sender: brandt_h@knop-beagle.kn.op.dlr.de To: "M. Warner Losh" In-Reply-To: <20061207.080007.1720215207.imp@bsdimp.com> Message-ID: <20061207163626.N17220@knop-beagle.kn.op.dlr.de> References: <20061206.143808.-1350498609.imp@bsdimp.com> <20061207090026.I17220@knop-beagle.kn.op.dlr.de> <20061207.080007.1720215207.imp@bsdimp.com> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 07 Dec 2006 15:53:57.0822 (UTC) FILETIME=[E7C2C5E0:01C71A17] Cc: net@freebsd.org Subject: Re: FreeBSD NFS Client, Windows 2003 NFS server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 16:00:07 -0000 On Thu, 7 Dec 2006, M. Warner Losh wrote: MWL>In message: <20061207090026.I17220@knop-beagle.kn.op.dlr.de> MWL> Harti Brandt writes: MWL>: MWL>Does anybody have experience with using FreeBSD 4.x or 6.x NFS clients MWL>: MWL>against a Windows 2003 NFS server? What is the performance relative MWL>: MWL>to using a FreeBSD NFS server? What is the stability? Does locking MWL>: MWL>work? Does the Windows 2003 server have extensions that grok file MWL>: MWL>system flags? MWL>: MWL>: I use this regularily (well, -CURRENT). I have no numbers, but performance MWL>: is ok. I have the home directories on a W2003k server and it 'feels' fast MWL>: enough. MWL> MWL>We see FreeBSD to FreeBSD NFS feeling fast enough for most things, but MWL>when we do a full build of our system from scratch it takes 10 hours MWL>over NFS vs 1 hour on a local disk. We're worried that if we were to MWL>try to do heavy NFS traffic to a Win2003 server with SFU this would be MWL>even slower. Ok. I did a very short test (no time to do much more). Read performance with dd if=/nfs/bigfile of=/dev/null bs=4k is around 9MByte/sec. Write performance with dd if=/dev/zero of=/nfs/bigfile bs=4k is 4MByte/sec. Client is something around 1GHz with a 100Mbps link. Fileserver is a double proc Xeon with a 1Gbps link. The Server has a load of around 30% (from the antivirus scanner). 72Mbps on a 100Mbps link looks actually ok for me. I've no FreeBSD on a Gigabit link to test with. If you want I could try to do a buildworld. MWL>: The only problem I see is a lot of 'file server not reponding' and 'file MWL>: server up again' (with 2-3 seconds in between). This is usually when MWL>: saving a large mail from pine. Linux clients see the same problem, so I MWL>: suppose it is a problem on the SFU side. MWL> MWL>So building large binaries might be a problem? Hmm. I just discovered, that these messages are gone since approx. two weeks. No idea why! MWL> MWL>: Locking seems to work. MWL> MWL>Does "seems to work" mean it really does work, or does SFU just do the MWL>old trick of saying 'ok, your lock worked'? I just did the following test: tty0 # lockf /nfs/foo sleep 100 tty1 # lockf /nfs/foo sh -c 'while true ; do echo -n '.' ; sleep 1 ; done' When I interrupt the lockf on tty0 with ^C, the process on tty1 starts to print dots. So I suppose it actually works. MWL> MWL>: Problems MWL>: are with filenames that are illegal for NTFS - hosting a 2.11BSD source MWL>: tree on a W2003 NFS share does not work because of filenames containing MWL>: ':' :-). I've not tested what other characters are illegal. MWL> MWL>That would be a problem for hosting a ports tree on the NTFS nfs MWL>partition, no? I suppose so. Interestinly enough the SFU documentation says, that these file names are actually allowed, so this seems like a bug. MWL>: Another problem is that on the NTFS side there is no good way to backup, MWL>: copy, whatever the trees, because while NTFS handles Makefile and MWL>: makefile, no Windows tool can access both of them. Even worse thinks like MWL>: ADSM backup sometimes die with internal errors. MWL> MWL>That's ugly. Yes. While NTFS can handle lower/uppercase, the access layer between NTFS and applications make 'a'=='A'. My plan here is to mount the NFS share on a UNIX host and make the backups from there. MWL>: Mapping of UIDs and GIDs is rather magic. The FreeBSD side, the SFU tools MWL>: and cygwin all see different numbers which is rather annoying. The same is MWL>: with symbolic links. MWL> MWL>Symblic links point elsewhere? or have different destinations? Does MWL>it matter absolute or relative? NTFS has no symbolic links, so they are implemented above in the application layer (SFU or the cygwin libraries). Obviously everybody implements them differently. So if you create a symbolic link on the NFS share. Then cygwin on the server just sees a short data file. MWL>: The file flags are not supported by the server. There are no extensions MWL>: that I know of. MWL> MWL>Same problem with FreeBSD to FreeBSD NFS. harti From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 16:00:57 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 47F1216A47E for ; Thu, 7 Dec 2006 16:00:57 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from unsane.co.uk (www.unsane.co.uk [85.233.185.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9571443DE5 for ; Thu, 7 Dec 2006 15:54:46 +0000 (GMT) (envelope-from jhary@unsane.co.uk) Received: from [192.168.10.217] (150.117-84-212.staticip.namesco.net [212.84.117.150]) (authenticated bits=0) by unsane.co.uk (8.13.7/8.13.3) with ESMTP id kB7Fto6g009103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 Dec 2006 15:55:51 GMT (envelope-from jhary@unsane.co.uk) Message-ID: <4578396E.6070503@unsane.co.uk> Date: Thu, 07 Dec 2006 15:55:26 +0000 From: Vince User-Agent: Thunderbird 1.5.0.8 (X11/20061204) MIME-Version: 1.0 To: net@freebsd.org References: <20061206.143808.-1350498609.imp@bsdimp.com> <20061207090026.I17220@knop-beagle.kn.op.dlr.de> <20061207.080007.1720215207.imp@bsdimp.com> In-Reply-To: <20061207.080007.1720215207.imp@bsdimp.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: FreeBSD NFS Client, Windows 2003 NFS server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 16:00:57 -0000 M. Warner Losh wrote: > In message: <20061207090026.I17220@knop-beagle.kn.op.dlr.de> > Harti Brandt writes: > : MWL>Does anybody have experience with using FreeBSD 4.x or 6.x NFS clients > : MWL>against a Windows 2003 NFS server? What is the performance relative > : MWL>to using a FreeBSD NFS server? What is the stability? Does locking > : MWL>work? Does the Windows 2003 server have extensions that grok file > : MWL>system flags? > : > : I use this regularily (well, -CURRENT). I have no numbers, but performance > : is ok. I have the home directories on a W2003k server and it 'feels' fast > : enough. > > We see FreeBSD to FreeBSD NFS feeling fast enough for most things, but > when we do a full build of our system from scratch it takes 10 hours > over NFS vs 1 hour on a local disk. We're worried that if we were to > try to do heavy NFS traffic to a Win2003 server with SFU this would be > even slower. > > : The only problem I see is a lot of 'file server not reponding' and 'file > : server up again' (with 2-3 seconds in between). This is usually when > : saving a large mail from pine. Linux clients see the same problem, so I > : suppose it is a problem on the SFU side. > > So building large binaries might be a problem? > > : Locking seems to work. > > Does "seems to work" mean it really does work, or does SFU just do the > old trick of saying 'ok, your lock worked'? > > : Problems > : are with filenames that are illegal for NTFS - hosting a 2.11BSD source > : tree on a W2003 NFS share does not work because of filenames containing > : ':' :-). I've not tested what other characters are illegal. > > That would be a problem for hosting a ports tree on the NTFS nfs > partition, no? > > : Another problem is that on the NTFS side there is no good way to backup, > : copy, whatever the trees, because while NTFS handles Makefile and > : makefile, no Windows tool can access both of them. Even worse thinks like > : ADSM backup sometimes die with internal errors. > > That's ugly. > > : Mapping of UIDs and GIDs is rather magic. The FreeBSD side, the SFU tools > : and cygwin all see different numbers which is rather annoying. The same is > : with symbolic links. > > Symblic links point elsewhere? or have different destinations? Does > it matter absolute or relative? > > : The file flags are not supported by the server. There are no extensions > : that I know of. > > Same problem with FreeBSD to FreeBSD NFS. > Just out of interest since cygwin was mentioned, has anyone tried out the cygwin NFS server rather than the SFU one? If it were combined with cygwin's "managed mount" mode it should in theory support ':' or other similar names that are normally illegal on windows, although they wouldnt be accessible from windows from what i remeber. Also I seem to remember things were always rather slow when I used to use cygwin, so it might not be worth it in terms of speed. Sorry if this is getting a little offtopic. Vince > Warner > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 18:37:39 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6CDBA16A51F for ; Thu, 7 Dec 2006 18:37:39 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57CC743CCB for ; Thu, 7 Dec 2006 18:36:28 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 07 Dec 2006 10:37:20 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kB7IbHeY009528; Thu, 7 Dec 2006 10:37:17 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kB7IbHin005785; Thu, 7 Dec 2006 10:37:17 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 10:37:17 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 10:37:16 -0800 Message-ID: <45785F2C.7040004@cisco.com> Date: Thu, 07 Dec 2006 13:36:28 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: maillist ifiaas References: <161d69110612060709n3bf99bd4y47d94b021b8f1d02@mail.gmail.com> <4577D858.4010300@freebsd.org> <2786D1DE-E8FA-490C-AFF7-E458E262AEF7@lurchi.franken.de> <161d69110612070242p612e2318ya8d285a15a54e9fc@mail.gmail.com> <4578057B.9080002@cisco.com> <161d69110612070451o6945c7c0y9cf7a7e8b6b7225d@mail.gmail.com> In-Reply-To: <161d69110612070451o6945c7c0y9cf7a7e8b6b7225d@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Dec 2006 18:37:16.0861 (UTC) FILETIME=[B87176D0:01C71A2E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2307; t=1165516637; x=1166380637; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20Urel, =20a=20TCP=20option=20for=20Unreliable=20Streami ng.=20Need=20your=20help. |Sender:=20; bh=CtHGg+YvnaLS3DeSHdC8CpwFqmuCtXmHXzm+OyAKmRg=; b=cHs5H8wKWiyqUlSczyLuJNVLXUNqPbpy+vnWLKDueQhq0z6tYkwhWPx/d4VpAmFd8FXUEpWI l4jPxrLtNd0zoUoYdN6XnmbnX0ws9RfCU/f4qejl2NnBvcbE61gz7E9s; Authentication-Results: sj-dkim-1; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim1002 verified; ); Cc: freebsd-net@freebsd.org Subject: Re: Urel, a TCP option for Unreliable Streaming. Need your help. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 18:37:39 -0000 maillist ifiaas wrote: > Thanks Randall. > > Am I right to say that, in SCTP, the loss information is reported to > the sender, instead of the receiver? Correct... the sender is notified of the loss... you could tell the receiver as well.. but the current BSD implementation does not do this .. the info is there .. just not reported :-D > > Btw, TCP Urel is a option. To use it, you have to add something like, > int rc = setsockopt( inSettings->mSock, IPPROTO_TCP,TCP_URE, (char*) > &val, len ); > to enable Urel option in TCP. Yep.. I thought so, so basically it is no different than having to set the prefered send option.. with a socket opt.. and then a one line change to add IPPROTO_SCTP to the socket() call .. No different coding wise I think.. > > I still think that partial reliability should be performed in the > application layer. Although transport layer knows more about the > channel condition, but they can either be reported to the application > (like we did on segment loss in TCP Urel), or be infered by > application (e.g. estimating the current bitrate by looking at the > buffersize). As QoS is only meaningful to application, allowing > flexibilty of implementing QoS (such as partial relaibility) mechenism > in application layer rather than transport layer, looks much natrual to me. Then why modify TCP? R > > -gavin > > On 12/7/06, Randall Stewart wrote: > >> maillist ifiaas wrote: >> > Michael, >> > >> > In PR-SCTP where retranmission is set off, does it allows the >> > applications to know which part of data is lost in the stream? >> > Thanks >> >> Yep.. you subscribe for a notification event and SCTP will >> return you the data that was not sent. >> >> So not only does it let you know you can actually let >> SCTP hold and return the data that did not get >> acknowledged.. The API also has a context so you >> can attach a user defined 32 bit value to the >> data.. to say bind a pointer to an object to >> the actual data... for lookup or other stuff :-) >> >> R >> > >> >> >> >> -- >> Randall Stewart >> NSSTG - Cisco Systems Inc. >> 803-345-0369 803-317-4952 (cell) >> > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Fri Dec 8 02:30:20 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A66F16A403; Fri, 8 Dec 2006 02:30:20 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3CCE43CC5; Fri, 8 Dec 2006 02:29:24 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id 5B2CE1190D1; Fri, 8 Dec 2006 13:30:15 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 9737927438; Fri, 8 Dec 2006 13:30:13 +1100 (EST) Date: Fri, 8 Dec 2006 13:30:13 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: "M. Warner Losh" In-Reply-To: <20061207.080007.1720215207.imp@bsdimp.com> Message-ID: <20061208125250.B39681@delplex.bde.org> References: <20061206.143808.-1350498609.imp@bsdimp.com> <20061207090026.I17220@knop-beagle.kn.op.dlr.de> <20061207.080007.1720215207.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: hartmut.brandt@dlr.de, harti@freebsd.org, net@freebsd.org Subject: Re: FreeBSD NFS Client, Windows 2003 NFS server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2006 02:30:20 -0000 On Thu, 7 Dec 2006, M. Warner Losh wrote: > We see FreeBSD to FreeBSD NFS feeling fast enough for most things, but > when we do a full build of our system from scratch it takes 10 hours > over NFS vs 1 hour on a local disk. I have a report that lost dotdot caching seems to be responsible for most of the enormous slowness of nfs under FreeBSD (for building a large non-FreeBSD system), but I think this is only one of several slowness factors, and building things in parallel is an adequate workaround in all cases that I tried (mainly building kernels and worlds). > We're worried that if we were to > try to do heavy NFS traffic to a Win2003 server with SFU this would be > even slower. The slowness in FreeBSD's nfs seems to be mostly in the client (except network latency is in the network). The client doesn't cache things very well, so it generates a large number of RPCs so the total latency = (per-RPC-latency * number-of-RPCs) is enormous if the per-RPC latency is just large. Bruce From owner-freebsd-net@FreeBSD.ORG Fri Dec 8 03:17:01 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6EEA316A40F; Fri, 8 Dec 2006 03:17:01 +0000 (UTC) (envelope-from paul.koch@statseeker.com) Received: from wally.statseeker.com (wally.statscout.com [203.39.101.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A16A43CAC; Fri, 8 Dec 2006 03:16:04 +0000 (GMT) (envelope-from paul.koch@statseeker.com) Received: from localhost (localhost [127.0.0.1]) by wally.statseeker.com (8.13.3/8.13.3) with ESMTP id kB64hgf5011048; Wed, 6 Dec 2006 14:43:42 +1000 (EST) (envelope-from paul.koch@statseeker.com) Received: from wally.statseeker.com ([127.0.0.1]) by localhost (wally.statseeker.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10842-01; Wed, 6 Dec 2006 14:43:30 +1000 (EST) Received: from speedy (speedy.statseeker.com [10.1.1.100]) (authenticated bits=0) by wally.statseeker.com (8.13.3/8.13.3) with ESMTP id kB64hRhj011033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Dec 2006 14:43:27 +1000 (EST) (envelope-from paul.koch@statseeker.com) From: Paul Koch To: "Benjamin Adams" Date: Wed, 6 Dec 2006 14:43:23 +1000 User-Agent: KMail/1.9.1 References: <6199c3dc0612050848g16a0911dga145485ba14bf21f@mail.gmail.com> In-Reply-To: <6199c3dc0612050848g16a0911dga145485ba14bf21f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612061443.23626.paul.koch@statseeker.com> X-Virus-Scanned: amavisd-new at statseeker.com Cc: freebsd-net@freebsd.org, freebsd-chat@freebsd.org Subject: Re: Bandwidth Monitoring program X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: paul.koch@statseeker.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2006 03:17:01 -0000 On Wednesday 06 December 2006 02:48, Benjamin Adams wrote: > I'm on a network that has a normal store firewall, setup as a NAT. > I'm trying to find a way to monitor all bandwidth by clients through > that firewall. I don't have the ability to just put an inline box to > examine packets. Is there a program where I can see whats going on > from the computer on that network. > > What I'm looking for is: > client ip : 2.3 GB > List of ports used in bandwidth amounts. > > > Thanks for any help, > Ben Adams If the firewall device supports netflow, you could use one of the netflow collector/reporter ports. Otherwise you'll have to setup a mirror port on a switch, direct all the packets to another machine and use a program that captures/counts the packets on the wire and does the necessary stats. Fyi, for real-time address/protocol LAN statistics, we submitted a port a few months ago in net/ltm. You can add your own protocol types, but you'll need to read the supplied manual entries first :) Paul. From owner-freebsd-net@FreeBSD.ORG Fri Dec 8 08:21:32 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E0C016A4B3 for ; Fri, 8 Dec 2006 08:21:32 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D73A43CB2 for ; Fri, 8 Dec 2006 08:20:34 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from knop-beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-3.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 09:21:28 +0100 Date: Fri, 8 Dec 2006 09:21:30 +0100 (CET) From: Harti Brandt X-X-Sender: brandt_h@knop-beagle.kn.op.dlr.de To: "M. Warner Losh" In-Reply-To: <20061207163626.N17220@knop-beagle.kn.op.dlr.de> Message-ID: <20061208091822.M17220@knop-beagle.kn.op.dlr.de> References: <20061206.143808.-1350498609.imp@bsdimp.com> <20061207090026.I17220@knop-beagle.kn.op.dlr.de> <20061207.080007.1720215207.imp@bsdimp.com> <20061207163626.N17220@knop-beagle.kn.op.dlr.de> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 08 Dec 2006 08:21:28.0851 (UTC) FILETIME=[DC204E30:01C71AA1] Cc: net@freebsd.org Subject: Re: FreeBSD NFS Client, Windows 2003 NFS server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2006 08:21:32 -0000 On Thu, 7 Dec 2006, Harti Brandt wrote: HB>On Thu, 7 Dec 2006, M. Warner Losh wrote: HB> HB>MWL>In message: <20061207090026.I17220@knop-beagle.kn.op.dlr.de> HB>MWL> Harti Brandt writes: HB>MWL>: MWL>Does anybody have experience with using FreeBSD 4.x or 6.x NFS clients HB>MWL>: MWL>against a Windows 2003 NFS server? What is the performance relative HB>MWL>: MWL>to using a FreeBSD NFS server? What is the stability? Does locking HB>MWL>: MWL>work? Does the Windows 2003 server have extensions that grok file HB>MWL>: MWL>system flags? HB>MWL>: HB>MWL>: I use this regularily (well, -CURRENT). I have no numbers, but performance HB>MWL>: is ok. I have the home directories on a W2003k server and it 'feels' fast HB>MWL>: enough. HB>MWL> HB>MWL>We see FreeBSD to FreeBSD NFS feeling fast enough for most things, but HB>MWL>when we do a full build of our system from scratch it takes 10 hours HB>MWL>over NFS vs 1 hour on a local disk. We're worried that if we were to HB>MWL>try to do heavy NFS traffic to a Win2003 server with SFU this would be HB>MWL>even slower. HB> HB>Ok. I did a very short test (no time to do much more). Read performance HB>with dd if=/nfs/bigfile of=/dev/null bs=4k is around 9MByte/sec. Write HB>performance with dd if=/dev/zero of=/nfs/bigfile bs=4k is 4MByte/sec. HB> HB>Client is something around 1GHz with a 100Mbps link. Fileserver is a HB>double proc Xeon with a 1Gbps link. The Server has a load of around 30% HB>(from the antivirus scanner). HB> HB>72Mbps on a 100Mbps link looks actually ok for me. I've no FreeBSD on a HB>Gigabit link to test with. HB> HB>If you want I could try to do a buildworld. Ok. To answer my own mail. A buildworld with a local /usr/src takes 2:50h on that machine, with /usr/src on the W2003 server 3:50h. Looks not that bad. harti From owner-freebsd-net@FreeBSD.ORG Fri Dec 8 09:06:01 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C92B416A40F; Fri, 8 Dec 2006 09:06:01 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90FBD43CA2; Fri, 8 Dec 2006 09:05:04 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id kB894QIB031236; Fri, 8 Dec 2006 02:04:26 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 08 Dec 2006 02:05:20 -0700 (MST) Message-Id: <20061208.020520.723205823.imp@bsdimp.com> To: harti@freebsd.org, hartmut.brandt@dlr.de From: "M. Warner Losh" In-Reply-To: <20061208091822.M17220@knop-beagle.kn.op.dlr.de> References: <20061207.080007.1720215207.imp@bsdimp.com> <20061207163626.N17220@knop-beagle.kn.op.dlr.de> <20061208091822.M17220@knop-beagle.kn.op.dlr.de> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 08 Dec 2006 02:04:26 -0700 (MST) Cc: net@freebsd.org Subject: Re: FreeBSD NFS Client, Windows 2003 NFS server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2006 09:06:01 -0000 In message: <20061208091822.M17220@knop-beagle.kn.op.dlr.de> Harti Brandt writes: : On Thu, 7 Dec 2006, Harti Brandt wrote: : : HB>On Thu, 7 Dec 2006, M. Warner Losh wrote: : HB> : HB>MWL>In message: <20061207090026.I17220@knop-beagle.kn.op.dlr.de> : HB>MWL> Harti Brandt writes: : HB>MWL>: MWL>Does anybody have experience with using FreeBSD 4.x or 6.x NFS clients : HB>MWL>: MWL>against a Windows 2003 NFS server? What is the performance relative : HB>MWL>: MWL>to using a FreeBSD NFS server? What is the stability? Does locking : HB>MWL>: MWL>work? Does the Windows 2003 server have extensions that grok file : HB>MWL>: MWL>system flags? : HB>MWL>: : HB>MWL>: I use this regularily (well, -CURRENT). I have no numbers, but performance : HB>MWL>: is ok. I have the home directories on a W2003k server and it 'feels' fast : HB>MWL>: enough. : HB>MWL> : HB>MWL>We see FreeBSD to FreeBSD NFS feeling fast enough for most things, but : HB>MWL>when we do a full build of our system from scratch it takes 10 hours : HB>MWL>over NFS vs 1 hour on a local disk. We're worried that if we were to : HB>MWL>try to do heavy NFS traffic to a Win2003 server with SFU this would be : HB>MWL>even slower. : HB> : HB>Ok. I did a very short test (no time to do much more). Read performance : HB>with dd if=/nfs/bigfile of=/dev/null bs=4k is around 9MByte/sec. Write : HB>performance with dd if=/dev/zero of=/nfs/bigfile bs=4k is 4MByte/sec. : HB> : HB>Client is something around 1GHz with a 100Mbps link. Fileserver is a : HB>double proc Xeon with a 1Gbps link. The Server has a load of around 30% : HB>(from the antivirus scanner). : HB> : HB>72Mbps on a 100Mbps link looks actually ok for me. I've no FreeBSD on a : HB>Gigabit link to test with. : HB> : HB>If you want I could try to do a buildworld. : : Ok. To answer my own mail. A buildworld with a local /usr/src takes 2:50h : on that machine, with /usr/src on the W2003 server 3:50h. Looks not that bad. So we're talking 33% slower here rather than 90% slower that I see for my entire product build. So the speed is similar to what I've seen over NFS here... Warner From owner-freebsd-net@FreeBSD.ORG Sat Dec 9 06:09:05 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9747116A416; Sat, 9 Dec 2006 06:09:05 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDE8643C9D; Sat, 9 Dec 2006 06:08:02 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id 7D2936E008; Sat, 9 Dec 2006 17:09:02 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 95E142740E; Sat, 9 Dec 2006 17:09:02 +1100 (EST) Date: Sat, 9 Dec 2006 17:09:02 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Harti Brandt In-Reply-To: <20061208091822.M17220@knop-beagle.kn.op.dlr.de> Message-ID: <20061209165044.B43826@delplex.bde.org> References: <20061206.143808.-1350498609.imp@bsdimp.com> <20061207090026.I17220@knop-beagle.kn.op.dlr.de> <20061207.080007.1720215207.imp@bsdimp.com> <20061207163626.N17220@knop-beagle.kn.op.dlr.de> <20061208091822.M17220@knop-beagle.kn.op.dlr.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "M. Warner Losh" , net@FreeBSD.org Subject: Re: FreeBSD NFS Client, Windows 2003 NFS server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2006 06:09:05 -0000 On Fri, 8 Dec 2006, Harti Brandt wrote: > On Thu, 7 Dec 2006, Harti Brandt wrote: > HB>Ok. I did a very short test (no time to do much more). Read performance > HB>with dd if=/nfs/bigfile of=/dev/null bs=4k is around 9MByte/sec. Write > HB>performance with dd if=/dev/zero of=/nfs/bigfile bs=4k is 4MByte/sec. > HB> > HB>Client is something around 1GHz with a 100Mbps link. Fileserver is a > HB>double proc Xeon with a 1Gbps link. The Server has a load of around 30% > HB>(from the antivirus scanner). > HB> > HB>72Mbps on a 100Mbps link looks actually ok for me. I've no FreeBSD on a > HB>Gigabit link to test with. > HB> > HB>If you want I could try to do a buildworld. > > Ok. To answer my own mail. A buildworld with a local /usr/src takes 2:50h > on that machine, with /usr/src on the W2003 server 3:50h. Looks not that bad. Hmm, with such slow machines, network/nfs latency shouldn't be much of a problem. Makeworld of a ~5.2 world with a Turion X2 2GHz takes 14:24m here. About 1m of this time is extra for nfs. It took a bit of work to reduce the nfs overhead from a few minutes (about 5?) to only 1. Bruce