From owner-freebsd-net Sun Jul 7 1:37:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D31F37B400 for ; Sun, 7 Jul 2002 01:37:10 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73ECE43E09 for ; Sun, 7 Jul 2002 01:37:10 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 49BECAE39D; Sun, 7 Jul 2002 01:37:10 -0700 (PDT) Date: Sun, 7 Jul 2002 01:37:10 -0700 From: Alfred Perlstein To: net@freebsd.org Subject: the incredible shrinking socket Message-ID: <20020707083710.GM97638@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Some time ago I noticed that there appeared to be several members of struct socket that were either only used by listen sockets or only used by data sockets. I've taken a stab at unionizing the members and we wind up saving 28 bytes per socket on i386, and probably nearly double that on any 64 bit platform. That's ~15%, which isn't too shabby. The problem is that besideds making things a tad ugly, I haven't gotten it completely working yet. I seem to have some sort of bug with rendevous listening sockets, telnetd can accept a connection, however then the cpu goes to 100%, sshd drops my connection right after authorizing me. Most of the problem is because now that it's unionized, it's hard to make sure someone isn't clobbering the data as some functions expect _all_ fields to be there. Anyhow, if anyone wanted to take a look, the patch is here: http://people.freebsd.org/~alfred/deltas/sockunion.diff.gz -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 7 3:52:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B915E37B400 for ; Sun, 7 Jul 2002 03:52:33 -0700 (PDT) Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6DF943E42 for ; Sun, 7 Jul 2002 03:52:32 -0700 (PDT) (envelope-from joe@tao.org.uk) Received: by tao.org.uk (Postfix, from userid 100) id 7C908A8; Sun, 7 Jul 2002 11:52:01 +0100 (BST) Date: Sun, 7 Jul 2002 11:52:01 +0100 From: Josef Karthauser To: Patrick Thomas Cc: freebsd-net@freebsd.org Subject: Re: Linksys USB100M ... usbd.conf help needed. Message-ID: <20020707105201.GQ2813@genius.tao.org.uk> References: <20020706150728.G79469-100000@utility.clubscholarship.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="+nG9yj4eE4W6Oba0" Content-Disposition: inline In-Reply-To: <20020706150728.G79469-100000@utility.clubscholarship.com> User-Agent: Mutt/1.3.99i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --+nG9yj4eE4W6Oba0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Jul 06, 2002 at 03:17:28PM -0700, Patrick Thomas wrote: > > I have just purchased a Linksys USB100M - it is a very small key-style USB > NIC. I am running 5.0-DP1. I have all of the USB items except for the > removable disk device compiled into my kernel - I also have the three > aue/cue/kue options compiled into the kernel. > > I put the device in and got this message on the console: > > Jul 6 15:06:49 hostname kernel: ugen0: Linksys Linksys USB LAN Adapter, > rev 1.10/1.00, addr 2 > > Then I ran `usbdevs -v`: > > Controller /dev/usb0: > addr 1: self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev > 1.00 port 1 addr 2: full speed, power 120 mA, config 1, Linksys USB LAN > Adapter(0x8150), Linksys(0x0bda), rev 1.00 > port 2 powered Let's assume for a minute that it's an aue device (are all LinkSys'). Try applying the attached patch file to /sys/dev/usb/if_aue.c and recompiling the kernel. Do you get an aue0 attaching now when you plug the adapter in, and does it work? Joe --+nG9yj4eE4W6Oba0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="if_aue.c-patch" Index: if_aue.c =================================================================== RCS file: /home/ncvs/src/sys/dev/usb/if_aue.c,v retrieving revision 1.60 diff -u -r1.60 if_aue.c --- if_aue.c 27 May 2002 00:00:48 -0000 1.60 +++ if_aue.c 7 Jul 2002 10:50:21 -0000 @@ -151,6 +151,7 @@ {{ USB_VENDOR_IODATA, USB_PRODUCT_IODATA_USBETTX}, 0 }, {{ USB_VENDOR_IODATA, USB_PRODUCT_IODATA_USBETTXS}, PII }, {{ USB_VENDOR_KINGSTON, USB_PRODUCT_KINGSTON_KNU101TX}, 0 }, + {{ USB_VENDOR_LINKSYS, 0x8150 }, LSYS }, {{ USB_VENDOR_LINKSYS, USB_PRODUCT_LINKSYS_USB10TX1}, LSYS|PII }, {{ USB_VENDOR_LINKSYS, USB_PRODUCT_LINKSYS_USB10T}, LSYS }, {{ USB_VENDOR_LINKSYS, USB_PRODUCT_LINKSYS_USB100TX}, LSYS }, --+nG9yj4eE4W6Oba0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 7 12:36:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA95937B400 for ; Sun, 7 Jul 2002 12:36:30 -0700 (PDT) Received: from patrocles.silby.com (d85.as13.nwbl0.wi.voyager.net [169.207.135.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DB9C43E09 for ; Sun, 7 Jul 2002 12:36:29 -0700 (PDT) (envelope-from silby@silby.com) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.4/8.12.4) with ESMTP id g67Jdtcv014254; Sun, 7 Jul 2002 14:39:55 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.4/8.12.4/Submit) with ESMTP id g67JdrBO014251; Sun, 7 Jul 2002 14:39:54 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Sun, 7 Jul 2002 14:39:53 -0500 (CDT) From: Mike Silbersack To: Alfred Perlstein Cc: net@freebsd.org Subject: Re: the incredible shrinking socket In-Reply-To: <20020707083710.GM97638@elvis.mu.org> Message-ID: <20020707143846.A13771-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 7 Jul 2002, Alfred Perlstein wrote: > Some time ago I noticed that there appeared to be several members > of struct socket that were either only used by listen sockets or > only used by data sockets. > > I've taken a stab at unionizing the members and we wind up saving > 28 bytes per socket on i386, and probably nearly double that on > any 64 bit platform. That's ~15%, which isn't too shabby. Unions are ooogly. Would it be possible to seperate listen-only structures out into a seperate struct instead with a pointer to it? Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 7 12:54:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 607B137B400 for ; Sun, 7 Jul 2002 12:54:14 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0109D43E31 for ; Sun, 7 Jul 2002 12:54:03 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 41F33AE371; Sun, 7 Jul 2002 12:53:21 -0700 (PDT) Date: Sun, 7 Jul 2002 12:53:21 -0700 From: Alfred Perlstein To: Mike Silbersack Cc: net@freebsd.org Subject: Re: the incredible shrinking socket Message-ID: <20020707195321.GN97638@elvis.mu.org> References: <20020707083710.GM97638@elvis.mu.org> <20020707143846.A13771-100000@patrocles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020707143846.A13771-100000@patrocles.silby.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Mike Silbersack [020707 12:36] wrote: > > On Sun, 7 Jul 2002, Alfred Perlstein wrote: > > > Some time ago I noticed that there appeared to be several members > > of struct socket that were either only used by listen sockets or > > only used by data sockets. > > > > I've taken a stab at unionizing the members and we wind up saving > > 28 bytes per socket on i386, and probably nearly double that on > > any 64 bit platform. That's ~15%, which isn't too shabby. > > Unions are ooogly. Would it be possible to seperate listen-only > structures out into a seperate struct instead with a pointer to it? Possibly, but the additional pointer dereference would be expensive and a lot of code would have to change without the compatibility macros. I sort of did it as a proof of concept, but of course since it doesn't completely work I haven't proved it. :) -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 7 13: 5: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F095637B400; Sun, 7 Jul 2002 13:04:51 -0700 (PDT) Received: from hotmail.com (f94.law11.hotmail.com [64.4.17.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B29D43E54; Sun, 7 Jul 2002 13:04:21 -0700 (PDT) (envelope-from kimokasawa@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 7 Jul 2002 13:01:44 -0700 Received: from 68.49.49.165 by lw11fd.law11.hotmail.msn.com with HTTP; Sun, 07 Jul 2002 20:01:44 GMT X-Originating-IP: [68.49.49.165] From: "Kim Okasawa" To: freebsd-net@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Methods to detect Internet censorship. Date: Mon, 08 Jul 2002 05:01:44 +0900 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Jul 2002 20:01:44.0411 (UTC) FILETIME=[1E37BAB0:01C225F1] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Dear all, First, I need to apologize because this question is not FreeBSD-specific, but I believe I may be able to find some good answers or insights from here. Currently I'm working on a research project about Internet censorship in certain Asia and middle east countries. I need to find out which US websites has been blocked by those countries (e.g. CNN, NY Times, Wall Street Journal, etc.) The problem I encountered is that I haven't found a good way to detect the blocking. Here are a brief description of what is going on. In certain countries such as China, Singapore, and some middle east countries, goverments do NOT want their people to have access to US websites and obtain 'sensitive' information. The most common way to achieve this is to build a national 'firewall' to drop all packets that come from certain foreign IP addresses (addresses that belongs to websites such as CNN, etc.) Here's the diagram: Censored country +--------------------------------------------+ | +--- ... | | | | | +----------+ +--- ... | | | National | | | Internet ----------+--+ +-----+--- ... hosts inside | (world) | | Firewall | | the country | | +----------+ +--- ... | | | | | +--- ... | +--------------------------------------------+ To detect which websites has been blocked by those national firewalls, I have two ways and each encounters a problem. 1. Buy shell or dial-up accounts from ISPs in such countries and remotely do a HTTP GET to see if the requested webpages come back. Problem: I cannot get shell or dial-up accounts from all regions in every countries because some of them either don't accept credit card or don't deal with foreigners. 2. Use loose source routing to fix a gateway inside such countries and send HTTP GET requests to US sites from my home. So idealy, the packet will travel from my home, pass a host inside the censored country, then come back to the US site that I specified. When the US site responds to the request, the packet will follow the same route to the censored country, then back to me. If the US site is being blocked by the country, then I will never receive the packet. Problem: Loose source routing is denied by many routers and *nix machines such as Linux so this method is quite unreliable and can generate a lot of false results. Are there other inexpensive ways to detect the censorships? I'm open to any possible methods. Thank you all for the helps. Best Regards, Kim Okasawa _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 7 13:14:23 2002 Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id C0D9937B400; Sun, 7 Jul 2002 13:14:21 -0700 (PDT) Date: Sun, 7 Jul 2002 13:14:21 -0700 From: Juli Mallett To: Mike Silbersack Cc: Alfred Perlstein , net@freebsd.org Subject: Re: the incredible shrinking socket Message-ID: <20020707131421.A50599@FreeBSD.ORG> References: <20020707083710.GM97638@elvis.mu.org> <20020707143846.A13771-100000@patrocles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020707143846.A13771-100000@patrocles.silby.com>; from silby@silby.com on Sun, Jul 07, 2002 at 02:39:53PM -0500 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , X-Affiliated-Projects: FreeBSD, xMach, ircd-hybrid-7 X-Towel: Yes X-LiveJournal: flata X-Negacore: Yes X-Warning: If you make me read stupid email, don't be surprised if I respond. If you don't want me to reply to something, don't send it to me. Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * De: Mike Silbersack [ Data: 2002-07-07 ] [ Subjecte: Re: the incredible shrinking socket ] > > On Sun, 7 Jul 2002, Alfred Perlstein wrote: > > > Some time ago I noticed that there appeared to be several members > > of struct socket that were either only used by listen sockets or > > only used by data sockets. > > > > I've taken a stab at unionizing the members and we wind up saving > > 28 bytes per socket on i386, and probably nearly double that on > > any 64 bit platform. That's ~15%, which isn't too shabby. > > Unions are ooogly. Would it be possible to seperate listen-only > structures out into a seperate struct instead with a pointer to it? If you're going to do that why not just end the struct with char foo[1]; And overlay the unique bits at the end? Or do we already use storage there? -- Juli Mallett | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger jmallett@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 7 13:40:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4280537B401; Sun, 7 Jul 2002 13:40:27 -0700 (PDT) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8E9C43E54; Sun, 7 Jul 2002 13:40:26 -0700 (PDT) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 6E790534A; Sun, 7 Jul 2002 22:40:24 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Kim Okasawa" Cc: freebsd-net@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Methods to detect Internet censorship. References: From: Dag-Erling Smorgrav Date: 07 Jul 2002 22:40:23 +0200 In-Reply-To: Message-ID: Lines: 15 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org "Kim Okasawa" writes: > Are there other inexpensive ways to detect the censorships? I'm open > to any possible methods. Set up an open Squid proxy. Wait five minutes. Check the proxy logs and figure out what sites people access through your proxy, and from where. OK, so it might take a little more than five minutes, but the principle is sound. Great way do build up a huge collection of porn URLs and passwords, too :P DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 7 13:47:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD04937B401; Sun, 7 Jul 2002 13:47:32 -0700 (PDT) Received: from hotmail.com (f118.law11.hotmail.com [64.4.17.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1790143E4A; Sun, 7 Jul 2002 13:47:32 -0700 (PDT) (envelope-from kimokasawa@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 7 Jul 2002 13:47:31 -0700 Received: from 68.49.49.165 by lw11fd.law11.hotmail.msn.com with HTTP; Sun, 07 Jul 2002 20:47:31 GMT X-Originating-IP: [68.49.49.165] From: "Kim Okasawa" To: des@ofug.org Cc: freebsd-net@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Methods to detect Internet censorship. Date: Mon, 08 Jul 2002 05:47:31 +0900 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Jul 2002 20:47:31.0936 (UTC) FILETIME=[83DEC600:01C225F7] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >"Kim Okasawa" writes: > > Are there other inexpensive ways to detect the censorships? I'm open > > to any possible methods. > >Set up an open Squid proxy. Wait five minutes. Check the proxy logs >and figure out what sites people access through your proxy, and from >where. > >OK, so it might take a little more than five minutes, but the >principle is sound. Great way do build up a huge collection of porn >URLs and passwords, too :P > >DES >-- >Dag-Erling Smorgrav - des@ofug.org Well, I am not interested in fighting the censorship in such countries. All I want is to find out what US sites are being blocked by their national firewalls. Kim _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 7 14:26:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31C7737B401; Sun, 7 Jul 2002 14:26:53 -0700 (PDT) Received: from hotmail.com (f85.law11.hotmail.com [64.4.17.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id C003643E4A; Sun, 7 Jul 2002 14:26:52 -0700 (PDT) (envelope-from kimokasawa@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 7 Jul 2002 14:26:52 -0700 Received: from 68.49.49.165 by lw11fd.law11.hotmail.msn.com with HTTP; Sun, 07 Jul 2002 21:26:52 GMT X-Originating-IP: [68.49.49.165] From: "Kim Okasawa" To: brunner@nic-naa.net Cc: freebsd-security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Methods to detect Internet censorship. Date: Mon, 08 Jul 2002 06:26:52 +0900 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Jul 2002 21:26:52.0707 (UTC) FILETIME=[02FFD730:01C225FD] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Eric, I'm neither for nor against Internet censorship. I am just working on a research project that needs information on which US sites are being blocked by certain countries. I don't want to get into the discussions of whether censorship is good or bad. All I want is to find out, technically, is there a good way for me to detect/monitor censorship remotely. Thank you. Best Regards, Kim ----Original Message Follows---- From: Eric Brunner-Williams in Portland Maine To: "Kim Okasawa" CC: brunner@nic-naa.net Subject: Re: Methods to detect Internet censorship. Date: Sun, 07 Jul 2002 17:16:50 -0400 Oki Kim, When I worked with the NIC for the PRC last year several classes of abuse caused concern for network operators. To give two examples, a common browser caused packet flow to North America, generating cash drain from the PRC to the US, adding functionally unnecessary "overseas bandwidth" cost to the network operators. The underlying cause was a bug in UTF-8 handling, and also a US-centered business model. These problems (bug and business model generated consumption of expensive trans-pacific network resources) existed concurrently for all Asian network operators. The second example, specific to the PRC, was undertaken by an agency that is funded by the United States. Radio Free Republican Morons or something along those lines. They were hosting "political speach" (if you are for it) or "stuff that kills children" (if you are not), take your pick as to the better characterization of the content. You know, all of the ccTLD NICs are on-line. They all get email, and most respond to reasonable requests, and asking if, what, even how they engineer crap (and I don't know how else to characterize the WSJ editorial page) out of the traffic they carry, is reasonable. Now, could I interest you in some addictive non-smoking nicotine products targeted for Asian females ages 8 to 12? How about opiates on-line? We live on an increassingly irresponsible internet. Anyone confusing access to some "news" product in the US with responsible operation is confused. Kitakitamatsino, Eric _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 7 14:34:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9778A37B401; Sun, 7 Jul 2002 14:34:30 -0700 (PDT) Received: from 12-234-90-219.client.attbi.com (12-234-90-219.client.attbi.com [12.234.90.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0DF343E58; Sun, 7 Jul 2002 14:34:29 -0700 (PDT) (envelope-from DougB@FreeBSD.org) Received: from FreeBSD.org (master.gorean.org [10.0.0.2]) by 12-234-90-219.client.attbi.com (8.12.3/8.12.3) with ESMTP id g67LYIBu087992; Sun, 7 Jul 2002 14:34:19 -0700 (PDT) (envelope-from DougB@FreeBSD.org) Message-ID: <3D28B3DA.E120A508@FreeBSD.org> Date: Sun, 07 Jul 2002 14:34:18 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.79 [en] (X11; U; FreeBSD 4.5-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kim Okasawa Cc: freebsd-security@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: Methods to detect Internet censorship. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is not on topic for any freebsd-* lists, except -chat. -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 7 15:41:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5098337B400; Sun, 7 Jul 2002 15:41:14 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1509C43E09; Sun, 7 Jul 2002 15:41:14 -0700 (PDT) (envelope-from baka@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1921) id D99D6AE162; Sun, 7 Jul 2002 15:41:13 -0700 (PDT) Date: Sun, 7 Jul 2002 15:41:13 -0700 From: Jon Mini To: Juli Mallett Cc: Mike Silbersack , Alfred Perlstein , net@FreeBSD.ORG Subject: Re: the incredible shrinking socket Message-ID: <20020707224113.GP55378@elvis.mu.org> References: <20020707083710.GM97638@elvis.mu.org> <20020707143846.A13771-100000@patrocles.silby.com> <20020707131421.A50599@FreeBSD.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020707131421.A50599@FreeBSD.ORG> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Jul 07, 2002 at 01:14:21PM -0700, Juli Mallett wrote: > * De: Mike Silbersack [ Data: 2002-07-07 ] > [ Subjecte: Re: the incredible shrinking socket ] > > > > On Sun, 7 Jul 2002, Alfred Perlstein wrote: > > > > > Some time ago I noticed that there appeared to be several members > > > of struct socket that were either only used by listen sockets or > > > only used by data sockets. > > > > > > I've taken a stab at unionizing the members and we wind up saving > > > 28 bytes per socket on i386, and probably nearly double that on > > > any 64 bit platform. That's ~15%, which isn't too shabby. > > > > Unions are ooogly. Would it be possible to seperate listen-only > > structures out into a seperate struct instead with a pointer to it? > > If you're going to do that why not just end the struct with > char foo[1]; > > And overlay the unique bits at the end? Because that is even more oogly than a union. -- Jonathan Mini http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 7 17:18:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80D3F37B400 for ; Sun, 7 Jul 2002 17:18:50 -0700 (PDT) Received: from patrocles.silby.com (d85.as13.nwbl0.wi.voyager.net [169.207.135.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04DDE43E31 for ; Sun, 7 Jul 2002 17:18:49 -0700 (PDT) (envelope-from silby@silby.com) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.4/8.12.4) with ESMTP id g680MFcv015294; Sun, 7 Jul 2002 19:22:15 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.4/8.12.4/Submit) with ESMTP id g680MDV8015291; Sun, 7 Jul 2002 19:22:14 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Sun, 7 Jul 2002 19:22:13 -0500 (CDT) From: Mike Silbersack To: Alfred Perlstein Cc: net@freebsd.org Subject: Re: the incredible shrinking socket In-Reply-To: <20020707195321.GN97638@elvis.mu.org> Message-ID: <20020707192134.T15265-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 7 Jul 2002, Alfred Perlstein wrote: > Possibly, but the additional pointer dereference would be expensive > and a lot of code would have to change without the compatibility > macros. > > I sort of did it as a proof of concept, but of course since it doesn't > completely work I haven't proved it. :) > > > -- > -Alfred Perlstein [alfred@freebsd.org] Well, if it's not working I wouldn't worry too much about it. A TIME_WAIT cache or socket buffer autosizing would probably save a lot more memory. :) Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 7 19:41:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1965B37B400 for ; Sun, 7 Jul 2002 19:41:48 -0700 (PDT) Received: from front2.chartermi.net (24.213.60.124.up.mi.chartermi.net [24.213.60.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 261F443E7B for ; Sun, 7 Jul 2002 19:41:45 -0700 (PDT) (envelope-from ircd@wrath.com) Received: from [24.247.40.60] (HELO danrc) by front2.chartermi.net (CommuniGate Pro SMTP 3.5.3) with SMTP id 22846819 for freebsd-net@freebsd.org; Sun, 07 Jul 2002 22:41:41 -0400 Message-ID: <003a01c22628$fd847960$0b01a8c0@fear.wrath.net> From: "Brian" To: References: Subject: Re: Methods to detect Internet censorship. Date: Sun, 7 Jul 2002 22:41:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ----- Original Message ----- From: "Kim Okasawa" To: ; Sent: Sunday, July 07, 2002 4:01 PM Subject: Methods to detect Internet censorship. > Dear all, > > First, I need to apologize because this question is not FreeBSD-specific, > but I believe I may be able to find some good answers or insights from here. > > Currently I'm working on a research project about Internet censorship in > certain Asia and middle east countries. I need to find out which US > websites has been blocked by those countries (e.g. CNN, NY Times, Wall > Street Journal, etc.) Pretty common thing, I don't really see a problem with it though. If China wants to brainwash its people into believing that it was a careless american that crashed into a heroic asian airman all the power to them. The real truth is only how many people are gullible enough to believe it. It's kind of funny how many countries are worried about security and snag every file that is tarred or winzipped that wanders through their servers but yet you can bounce terabytes of spam off their servers. They'll filter the BBC, CBC, and CNN but yet child pornography run rampant. Oh well, everyone sets their own priorities. > 1. Buy shell or dial-up accounts from ISPs in such countries and remotely do > a HTTP GET to see if the requested webpages come back. > > Problem: I cannot get shell or dial-up accounts from all regions in every > countries because some of them either don't accept credit card or don't deal > with foreigners. Sadly, your best bet is to advertise somewhere that you would be willing to pay a private citizen of that country some money if you could use one of their machines for research. American Universities should work since most first, second, and third world countries that might have internet access usually send students to 'merica to go to school. It's usually the rich ones that are sent there and therefore a high chance that they'll have a computer and internet access at their home country if it is internet capable. This isn't exactly a speedy process though. Your next best bet is to get ahold of ambassador's offices in other countries and tell them that you're looking for a machine you can use for research that is hooked to the internet. If you're real nice people will usually help you out. A friend of mine at school did this recently. Most of the machines he used were businesses. Most of us Americans can't stand slow internet access so American companies usually go with satellite so it doesn't do you much good. When you can send a file faster using floppies and the Pony Express it's a bit rediculous. Plus, certain unnamed countries have a serious problem with security. I hope you're not in a hurry to do this. > Thank you all for the helps. > > Best Regards, > Kim Okasawa -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 7 21:48:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3386137B406 for ; Sun, 7 Jul 2002 21:48:14 -0700 (PDT) Received: from prism.flugsvamp.com (66-191-112-47.mad.wi.charter.com [66.191.112.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69ED843E3B for ; Sun, 7 Jul 2002 21:48:13 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.6/8.11.6) id g684l2t01700; Sun, 7 Jul 2002 23:47:02 -0500 (CDT) (envelope-from jlemon) Date: Sun, 7 Jul 2002 23:47:02 -0500 (CDT) From: Jonathan Lemon Message-Id: <200207080447.g684l2t01700@prism.flugsvamp.com> To: silby@silby.com, net@freebsd.org Subject: Re: the incredible shrinking socket X-Newsgroups: local.mail.freebsd-net In-Reply-To: References: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article you write: > >On Sun, 7 Jul 2002, Alfred Perlstein wrote: > >> Possibly, but the additional pointer dereference would be expensive >> and a lot of code would have to change without the compatibility >> macros. >> >> I sort of did it as a proof of concept, but of course since it doesn't >> completely work I haven't proved it. :) >> >> >> -- >> -Alfred Perlstein [alfred@freebsd.org] > >Well, if it's not working I wouldn't worry too much about it. A TIME_WAIT >cache or socket buffer autosizing would probably save a lot more memory. >:) I do have a smaller TIME_WAIT structure done; it even throws the socket away since it isn't needed. The savings are currently about 500 bytes, and I can and also perform some other savings in the general case. I think Alfred was just trying to get his changes done first before I got around to committing what I have. :-) :-) :-) (It's currently in p4) -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 7 22:35: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A701737B401 for ; Sun, 7 Jul 2002 22:35:02 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C67F43E64 for ; Sun, 7 Jul 2002 22:35:01 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 5B115AE39D; Sun, 7 Jul 2002 22:35:01 -0700 (PDT) Date: Sun, 7 Jul 2002 22:35:01 -0700 From: Alfred Perlstein To: Jonathan Lemon Cc: silby@silby.com, net@freebsd.org Subject: Re: the incredible shrinking socket Message-ID: <20020708053501.GR97638@elvis.mu.org> References: <200207080447.g684l2t01700@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200207080447.g684l2t01700@prism.flugsvamp.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Jonathan Lemon [020707 21:48] wrote: > > I do have a smaller TIME_WAIT structure done; it even throws the socket > away since it isn't needed. The savings are currently about 500 bytes, > and I can and also perform some other savings in the general case. > > I think Alfred was just trying to get his changes done first before I got > around to committing what I have. :-) :-) :-) (It's currently in p4) pfft, actually your return motivated me enough to try something I've been meaning to try. :) -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 7 23:36:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39C2337B400 for ; Sun, 7 Jul 2002 23:36:15 -0700 (PDT) Received: from patrocles.silby.com (d106.as29.nwbl0.wi.voyager.net [169.207.73.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B53E43E3B for ; Sun, 7 Jul 2002 23:36:11 -0700 (PDT) (envelope-from silby@silby.com) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.4/8.12.4) with ESMTP id g686dbcv016532; Mon, 8 Jul 2002 01:39:37 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.4/8.12.4/Submit) with ESMTP id g686dYKi016529; Mon, 8 Jul 2002 01:39:35 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Mon, 8 Jul 2002 01:39:33 -0500 (CDT) From: Mike Silbersack To: Alfred Perlstein Cc: Jonathan Lemon , Subject: Re: the incredible shrinking socket In-Reply-To: <20020708053501.GR97638@elvis.mu.org> Message-ID: <20020708013907.J15265-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 7 Jul 2002, Alfred Perlstein wrote: > * Jonathan Lemon [020707 21:48] wrote: > > > > I do have a smaller TIME_WAIT structure done; it even throws the socket > > away since it isn't needed. The savings are currently about 500 bytes, > > and I can and also perform some other savings in the general case. > > > > I think Alfred was just trying to get his changes done first before I got > > around to committing what I have. :-) :-) :-) (It's currently in p4) > > pfft, actually your return motivated me enough to try something I've > been meaning to try. :) > > -- > -Alfred Perlstein [alfred@freebsd.org] Yes, it's amazing what competition will do to productivity. I may actually start getting things done again. :) Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 8 0:54:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B3B237B401 for ; Mon, 8 Jul 2002 00:54:19 -0700 (PDT) Received: from nabechan.org (nabechan.org [210.228.4.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27E7643E3B for ; Mon, 8 Jul 2002 00:54:19 -0700 (PDT) (envelope-from nabe@nabechan.org) Received: from x20.a.nabechan.org (localhost [IPv6:::1]) by nabechan.org (8.12.3/8.12.3) with ESMTP id g687sFWT015347; Mon, 8 Jul 2002 16:54:15 +0900 (JST) (envelope-from nabe@nabechan.org) X-Authentication-Warning: nabechan.org: Host localhost [IPv6:::1] claimed to be x20.a.nabechan.org Date: Mon, 08 Jul 2002 16:52:55 +0900 Message-ID: <877kk61wrs.wl@nabechan.org> From: Shingo WATANABE To: joe@tao.org.uk Cc: root@utility.clubscholarship.com, freebsd-net@freebsd.org Subject: Re: Linksys USB100M ... usbd.conf help needed. In-Reply-To: <20020707105201.GQ2813@genius.tao.org.uk> References: <20020706150728.G79469-100000@utility.clubscholarship.com> <20020707105201.GQ2813@genius.tao.org.uk> User-Agent: Wanderlust/2.9.9 (Unchained Melody) XEmacs/21.1 (Cuyahoga Valley) Organization: nabechan.org X-Callsign: JG8OOM/1 X-OS: NetBSD 1.6A X-ICQ-UIN: 30482441 MIME-Version: 1.0 (generated by WEMIKO 1.14.1 - =?ISO-2022-JP?B?Ig==?= =?ISO-2022-JP?B?GyRCNl9KXExTQ24bKEIi?=) Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At Sun, 7 Jul 2002 11:52:01 +0100, Josef Karthauser wrote: > On Sat, Jul 06, 2002 at 03:17:28PM -0700, Patrick Thomas wrote: > > > > I have just purchased a Linksys USB100M - it is a very small key-style USB > > NIC. I am running 5.0-DP1. I have all of the USB items except for the > > removable disk device compiled into my kernel - I also have the three > > aue/cue/kue options compiled into the kernel. I think it is based on the Realtek RTL8150L chip and it does not work with aue/cue/kue driver. I wrote the driver (url(4)) for RTL8150 chip on NetBSD, and it was ported into OpenBSD. But the FreeBSD is not supported yet. If someone helps to test, I will port the driver into FreeBSD. :-) --- Shingo WATANABE To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 8 1: 1: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE4B437B401 for ; Mon, 8 Jul 2002 01:01:04 -0700 (PDT) Received: from bart.esiee.fr (bart.esiee.fr [147.215.1.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12D3D43E64 for ; Mon, 8 Jul 2002 01:01:02 -0700 (PDT) (envelope-from bonnetf@bart.esiee.fr) Received: (from bonnetf@localhost) by bart.esiee.fr (8.11.4/8.11.4) id g6880xw14553 for freebsd-net@freebsd.org; Mon, 8 Jul 2002 10:00:59 +0200 (METDST) Date: Mon, 8 Jul 2002 10:00:59 +0200 From: Frank Bonnet To: freebsd-net@freebsd.org Subject: Best NIC at 4.6 ? Message-ID: <20020708100059.A14510@bart.esiee.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi I wondering what would be the best supported NIC by FreeBSD 4.6 , I am in the process to upgrade our mailhub and I would like to have "freebsd-net" gurus advice on the "best" network hardware Actually I use an Intel express PRO 10/100 and I experienced some "lost connection" with the Postfix MTA , I am not sure that is the eth board, but changing it for a "better one" is not expensive. Any info advice welcome. thanks a lot. -- Frank Bonnet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 8 7:20:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB0A837B400; Mon, 8 Jul 2002 07:20:31 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63ACD43E31; Mon, 8 Jul 2002 07:20:11 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020708142011.YSJO24728.rwcrmhc51.attbi.com@InterJet.elischer.org>; Mon, 8 Jul 2002 14:20:11 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id HAA28752; Mon, 8 Jul 2002 07:18:04 -0700 (PDT) Date: Mon, 8 Jul 2002 07:18:02 -0700 (PDT) From: Julian Elischer To: John Kozubik Cc: "M. Warner Losh" , freebsd-hackers@FreeBSD.ORG, net@freebsd.org Subject: Re: multi-link 802.11b through netgraph yields poor performance. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Sorry to cross post this, I want it in the archives. [discussion on using mulitilink acrsss wireless cards deleted] I have done similar, using two IP channels and with mpd as the "one2many" basically, assign real IP addresses to the 4 cards, on 2 separate 10.x.x.x/30 networks then open ksocket mpd nodes for each network, making 2 parallel 'pipes'. then run mpd using the "netgraph" link type, and set up Multilink. Multilink will round-robin forthe links, but it will also stop using a link htat appears to have failed so you have some redundancey: here are my configs for this: firstly the script that sets up the ksockets. (Assumes all modules needed are loaded) #!/bin/sh # $FreeBSD: src/share/examples/netgraph/udp.tunnel,v 1.1 2000/01/28 00:44:30 archie Exp $ # This script sets up a virtual point-to-point WAN link between # two subnets, using UDP packets as the ``WAN connection.'' # The two subnets might be non-routable addresses behind a # firewall. # # Here define the local and remote inside networks as well # as the local and remote outside IP addresses and UDP port # number that will be used for the tunnel. # LOC_EXTERIOR_IP1=10.42.3.3 REM_EXTERIOR_IP1=10.42.5.1 UDP_TUNNEL_PORT1=4028 LOC_EXTERIOR_IP2=10.42.1.3 REM_EXTERIOR_IP2=10.42.4.1 UDP_TUNNEL_PORT2=4029 ngctl shutdown tee1: ngctl shutdown tee2: sleep 1 ngctl -f - <; Mon, 8 Jul 2002 09:53:07 -0700 (PDT) Received: from patrocles.silby.com (d49.as20.nwbl0.wi.voyager.net [169.207.138.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1474043E6A for ; Mon, 8 Jul 2002 09:53:04 -0700 (PDT) (envelope-from silby@silby.com) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.4/8.12.4) with ESMTP id g68GuScv018372; Mon, 8 Jul 2002 11:56:28 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.4/8.12.4/Submit) with ESMTP id g68GuMtT018369; Mon, 8 Jul 2002 11:56:23 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Mon, 8 Jul 2002 11:56:22 -0500 (CDT) From: Mike Silbersack To: Alfred Perlstein Cc: Jonathan Lemon , Subject: Re: the incredible shrinking socket In-Reply-To: <20020708013907.J15265-100000@patrocles.silby.com> Message-ID: <20020708115539.D18260-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 8 Jul 2002, Mike Silbersack wrote: > On Sun, 7 Jul 2002, Alfred Perlstein wrote: > > > * Jonathan Lemon [020707 21:48] wrote: > > > > > > I do have a smaller TIME_WAIT structure done; it even throws the socket > > > away since it isn't needed. The savings are currently about 500 bytes, > > > and I can and also perform some other savings in the general case. > > > > > > I think Alfred was just trying to get his changes done first before I got > > > around to committing what I have. :-) :-) :-) (It's currently in p4) > > > > pfft, actually your return motivated me enough to try something I've > > been meaning to try. :) > > > > -- > > -Alfred Perlstein [alfred@freebsd.org] > > Yes, it's amazing what competition will do to productivity. I may > actually start getting things done again. :) > > Mike "Silby" Silbersack Speaking of competition, someone should go look at this: http://mail-index.netbsd.org/current-users/2002/07/03/0011.html Sounds interesting. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 8 10: 9:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB81137B400 for ; Mon, 8 Jul 2002 10:09:10 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 245D043E09 for ; Mon, 8 Jul 2002 10:09:10 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.3/8.12.3) with ESMTP id g68H99RC031836; Mon, 8 Jul 2002 13:09:09 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.3/8.12.3/Submit) id g68H99rZ031832; Mon, 8 Jul 2002 13:09:09 -0400 (EDT) (envelope-from wollman) Date: Mon, 8 Jul 2002 13:09:09 -0400 (EDT) From: Garrett Wollman Message-Id: <200207081709.g68H99rZ031832@khavrinen.lcs.mit.edu> To: Alfred Perlstein Cc: net@FreeBSD.ORG Subject: the incredible shrinking socket In-Reply-To: <20020707083710.GM97638@elvis.mu.org> References: <20020707083710.GM97638@elvis.mu.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > Some time ago I noticed that there appeared to be several members > of struct socket that were either only used by listen sockets or > only used by data sockets. You can't do that. Self-connect is a valid operation on a socket. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 8 10:16:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87BC137B400 for ; Mon, 8 Jul 2002 10:16:44 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 292AE43E3B for ; Mon, 8 Jul 2002 10:16:44 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g68HGaV75642; Mon, 8 Jul 2002 10:16:36 -0700 (PDT) (envelope-from rizzo) Date: Mon, 8 Jul 2002 10:16:36 -0700 From: Luigi Rizzo To: Mike Silbersack Cc: Alfred Perlstein , Jonathan Lemon , net@FreeBSD.ORG Subject: Re: the incredible shrinking socket Message-ID: <20020708101636.A71846@iguana.icir.org> References: <20020708013907.J15265-100000@patrocles.silby.com> <20020708115539.D18260-100000@patrocles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020708115539.D18260-100000@patrocles.silby.com>; from silby@silby.com on Mon, Jul 08, 2002 at 11:56:22AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jul 08, 2002 at 11:56:22AM -0500, Mike Silbersack wrote: ... > Speaking of competition, someone should go look at this: > > http://mail-index.netbsd.org/current-users/2002/07/03/0011.html UDP sockets have the same problem... i posted patches for that case around dec.2000 which i never ended up committing. cheers luigi > Sounds interesting. > > Mike "Silby" Silbersack > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 8 10:20: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D999B37B400 for ; Mon, 8 Jul 2002 10:19:58 -0700 (PDT) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21A2143E54 for ; Mon, 8 Jul 2002 10:19:58 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g68HMEj09562; Mon, 8 Jul 2002 13:22:14 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Mon, 8 Jul 2002 13:22:14 -0400 From: Bosko Milekic To: Luigi Rizzo Cc: Mike Silbersack , Alfred Perlstein , Jonathan Lemon , net@FreeBSD.ORG Subject: Re: the incredible shrinking socket Message-ID: <20020708132214.A9544@unixdaemons.com> References: <20020708013907.J15265-100000@patrocles.silby.com> <20020708115539.D18260-100000@patrocles.silby.com> <20020708101636.A71846@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020708101636.A71846@iguana.icir.org>; from rizzo@icir.org on Mon, Jul 08, 2002 at 10:16:36AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jul 08, 2002 at 10:16:36AM -0700, Luigi Rizzo wrote: > On Mon, Jul 08, 2002 at 11:56:22AM -0500, Mike Silbersack wrote: > ... > > Speaking of competition, someone should go look at this: > > > > http://mail-index.netbsd.org/current-users/2002/07/03/0011.html > > UDP sockets have the same problem... i posted patches for that > case around dec.2000 which i never ended up committing. I spent a half-hour trying to dig for that thread. Do you recall what the subject of it was? When I saw this come up on DaemonNews, the first thing that came to mind was seeing that discussion; but now I can't find it through the mailing list search thing on the website. :-( > cheers > luigi > > > Sounds interesting. > > > > Mike "Silby" Silbersack Cheers, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 8 10:29:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC2B437B400 for ; Mon, 8 Jul 2002 10:29:41 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BE1143E09 for ; Mon, 8 Jul 2002 10:29:41 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g68HTbv75768; Mon, 8 Jul 2002 10:29:37 -0700 (PDT) (envelope-from rizzo) Date: Mon, 8 Jul 2002 10:29:37 -0700 From: Luigi Rizzo To: Bosko Milekic Cc: Mike Silbersack , Alfred Perlstein , Jonathan Lemon , net@FreeBSD.ORG Subject: Re: the incredible shrinking socket Message-ID: <20020708102937.A75756@iguana.icir.org> References: <20020708013907.J15265-100000@patrocles.silby.com> <20020708115539.D18260-100000@patrocles.silby.com> <20020708101636.A71846@iguana.icir.org> <20020708132214.A9544@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020708132214.A9544@unixdaemons.com>; from bmilekic@unixdaemons.com on Mon, Jul 08, 2002 at 01:22:14PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jul 08, 2002 at 01:22:14PM -0400, Bosko Milekic wrote: ... > > > Speaking of competition, someone should go look at this: > > > > > > http://mail-index.netbsd.org/current-users/2002/07/03/0011.html > > > > UDP sockets have the same problem... i posted patches for that > > case around dec.2000 which i never ended up committing. > > I spent a half-hour trying to dig for that thread. Do you recall what > the subject of it was? When I saw this come up on DaemonNews, the it was "[patch] fast sbappend*, please try..." see http://docs.freebsd.org/cgi/getmsg.cgi?fetch=366972+0+archive/2001/freebsd-net/20010211.freebsd-net jlemon had an amended patch for that. I think we should revisit this keeping in mind the tcp case as well. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 8 10:39:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C4C2237B400 for ; Mon, 8 Jul 2002 10:39:22 -0700 (PDT) Received: from prism.flugsvamp.com (66-191-112-47.mad.wi.charter.com [66.191.112.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03F6943E31 for ; Mon, 8 Jul 2002 10:39:22 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.6/8.11.6) id g68Hbv125453; Mon, 8 Jul 2002 12:37:57 -0500 (CDT) (envelope-from jlemon) Date: Mon, 8 Jul 2002 12:37:57 -0500 From: Jonathan Lemon To: Luigi Rizzo Cc: Bosko Milekic , Mike Silbersack , Alfred Perlstein , Jonathan Lemon , net@FreeBSD.ORG Subject: Re: the incredible shrinking socket Message-ID: <20020708123757.T1020@prism.flugsvamp.com> References: <20020708013907.J15265-100000@patrocles.silby.com> <20020708115539.D18260-100000@patrocles.silby.com> <20020708101636.A71846@iguana.icir.org> <20020708132214.A9544@unixdaemons.com> <20020708102937.A75756@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20020708102937.A75756@iguana.icir.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jul 08, 2002 at 10:29:37AM -0700, Luigi Rizzo wrote: > On Mon, Jul 08, 2002 at 01:22:14PM -0400, Bosko Milekic wrote: > ... > > > > Speaking of competition, someone should go look at this: > > > > > > > > http://mail-index.netbsd.org/current-users/2002/07/03/0011.html > > > > > > UDP sockets have the same problem... i posted patches for that > > > case around dec.2000 which i never ended up committing. > > > > I spent a half-hour trying to dig for that thread. Do you recall what > > the subject of it was? When I saw this come up on DaemonNews, the > > it was "[patch] fast sbappend*, please try..." > see > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=366972+0+archive/2001/freebsd-net/20010211.freebsd-net > > jlemon had an amended patch for that. > I think we should revisit this keeping in mind the tcp case as well. I still have the amended patch in my tree, I'll dig it out this week. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 8 10:55:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA77637B401 for ; Mon, 8 Jul 2002 10:55:38 -0700 (PDT) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id E448C43E42 for ; Mon, 8 Jul 2002 10:55:37 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g68HwJE09811; Mon, 8 Jul 2002 13:58:19 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Mon, 8 Jul 2002 13:58:19 -0400 From: Bosko Milekic To: Jonathan Lemon Cc: Luigi Rizzo , Mike Silbersack , Alfred Perlstein , net@FreeBSD.ORG Subject: Re: the incredible shrinking socket Message-ID: <20020708135819.A9714@unixdaemons.com> References: <20020708013907.J15265-100000@patrocles.silby.com> <20020708115539.D18260-100000@patrocles.silby.com> <20020708101636.A71846@iguana.icir.org> <20020708132214.A9544@unixdaemons.com> <20020708102937.A75756@iguana.icir.org> <20020708123757.T1020@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020708123757.T1020@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Mon, Jul 08, 2002 at 12:37:57PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jul 08, 2002 at 12:37:57PM -0500, Jonathan Lemon wrote: > On Mon, Jul 08, 2002 at 10:29:37AM -0700, Luigi Rizzo wrote: > > On Mon, Jul 08, 2002 at 01:22:14PM -0400, Bosko Milekic wrote: > > ... > > > > > Speaking of competition, someone should go look at this: > > > > > > > > > > http://mail-index.netbsd.org/current-users/2002/07/03/0011.html > > > > > > > > UDP sockets have the same problem... i posted patches for that > > > > case around dec.2000 which i never ended up committing. > > > > > > I spent a half-hour trying to dig for that thread. Do you recall what > > > the subject of it was? When I saw this come up on DaemonNews, the > > > > it was "[patch] fast sbappend*, please try..." > > see > > > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=366972+0+archive/2001/freebsd-net/20010211.freebsd-net > > > > jlemon had an amended patch for that. > > I think we should revisit this keeping in mind the tcp case as well. > > I still have the amended patch in my tree, I'll dig it out this week. Luigi also mentionned at the end of the discussion that it would be worthwhile to - besides for just keeping a pointer to the last mbuf in the sockbuf - keep a pointer to the last mbuf in the packet. Maybe this pointer could be stashed in the m_pkthdr struct. > -- > Jonathan Regards, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 8 10:57:41 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4399437B400 for ; Mon, 8 Jul 2002 10:57:39 -0700 (PDT) Received: from herbelot.dyndns.org (d108.dhcp212-198-26.noos.fr [212.198.26.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC7AE43E54 for ; Mon, 8 Jul 2002 10:57:37 -0700 (PDT) (envelope-from thierry@herbelot.com) Received: from herbelot.com (tulipe.herbelot.nom [192.168.2.5]) by herbelot.dyndns.org (8.9.3/8.9.3) with ESMTP id TAA15848; Mon, 8 Jul 2002 19:57:34 +0200 (CEST) (envelope-from thierry@herbelot.com) Message-ID: <3D29D28D.E029D99E@herbelot.com> Date: Mon, 08 Jul 2002 19:57:33 +0200 From: Thierry Herbelot X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Frank Bonnet Cc: freebsd-net@FreeBSD.ORG Subject: Re: Best NIC at 4.6 ? References: <20020708100059.A14510@bart.esiee.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org if you can still find some, I was very happy with the DLINK DFE-570-TX (4-port dc(4) NIC) TfH PS : the 3COM 3C905 NIC is also well supported under FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 8 15:42:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF70A37B400 for ; Mon, 8 Jul 2002 15:42:45 -0700 (PDT) Received: from melete.ch.intel.com (chfdns02.ch.intel.com [143.182.246.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 719C243E3B for ; Mon, 8 Jul 2002 15:42:45 -0700 (PDT) (envelope-from joydeepx.roy@intel.com) Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by melete.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g68Mgir29903 for ; Mon, 8 Jul 2002 22:42:44 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002070815432322060 for ; Mon, 08 Jul 2002 15:43:23 -0700 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Jul 2002 15:42:44 -0700 Message-ID: <288F9BF66CD9D5118DF400508B68C44601287A76@orsmsx113.jf.intel.com> From: "Roy, JoydeepX" To: freebsd-net@FreeBSD.ORG Subject: Date: Mon, 8 Jul 2002 15:42:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org unsubscribe freebsd-net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 9 2:26:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA14037B400 for ; Tue, 9 Jul 2002 02:26:21 -0700 (PDT) Received: from hotmail.com (f57.law7.hotmail.com [216.33.237.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77DA243E52 for ; Tue, 9 Jul 2002 02:26:21 -0700 (PDT) (envelope-from striker_d@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 9 Jul 2002 02:26:21 -0700 Received: from 198.31.26.195 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 09 Jul 2002 09:26:21 GMT X-Originating-IP: [198.31.26.195] From: "Brad Davis" To: freebsd-net@freebsd.org Subject: monitoring bandwidth usage Date: Tue, 09 Jul 2002 03:26:21 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Jul 2002 09:26:21.0372 (UTC) FILETIME=[AFF11FC0:01C2272A] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, I was wondering if there was a way that I could monitor the bandwidth usage live? I have heard of a linux program called iptraf, is there something similar to that for FreeBSD? Thank You, Brad Davis _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 9 2:49:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91A9837B400 for ; Tue, 9 Jul 2002 02:49:13 -0700 (PDT) Received: from zelax.ru (rosa.zelax.ru [212.188.91.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 649EF43E4A for ; Tue, 9 Jul 2002 02:49:03 -0700 (PDT) (envelope-from wr@zelax.ru) Received: (from root@localhost) by zelax.ru (8.9.3/8.9.3) id NAA60324 for freebsd-net@FreeBSD.ORG.KAV; Tue, 9 Jul 2002 13:48:56 +0400 (MSD) (envelope-from wr@zelax.ru) Received: from zelax.ru (slava.local [192.168.11.152]) by zelax.ru (8.9.3/8.9.3) with ESMTP id NAA60312 for ; Tue, 9 Jul 2002 13:48:56 +0400 (MSD) (envelope-from wr@zelax.ru) Message-ID: <3D2B13D0.9000002@zelax.ru> Date: Tue, 09 Jul 2002 12:48:16 -0400 From: "Vyacheslav V. Burdjanadze" Organization: ZELAX User-Agent: Mozilla/5.0 (compatible; MSIE5.5; Windows 98; X-Accept-Language: ru, en MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG Subject: Forwarding of UDP broadcast Content-Type: multipart/mixed; boundary="------------020207040507030300010903" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------020207040507030300010903 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Hello. I'm developing for RTEMS OS, and thus this post is bit offtopic, but RTEMS uses networking code ported from FreeBSD. I'm trying to implement forwarding of UDP broadcasts to enable MS Network browsing through chain of routers. As I noticed from code - the best place to do it - is udp_input() in udp_usrreq.c. But unfortunately I can't get my code working correct - it seems like I fill IP header incorrectly thus get ``short packet'' either on ip_input or in udp_input on the receiving side :-(. Could someone help me ? (code is attached) --------------020207040507030300010903 Content-Type: text/plain; name="udp_usrreq.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="udp_usrreq.c" /* * Copyright (c) 1982, 1986, 1988, 1990, 1993, 1995 * The Regents of the University of California. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * This product includes software developed by the University of * California, Berkeley and its contributors. * 4. Neither the name of the University nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * @(#)udp_usrreq.c 8.6 (Berkeley) 5/23/95 * $Id: udp_usrreq.c,v 1.11 2002/07/09 09:10:28 cvs Exp $ */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include /* * UDP protocol implementation. * Per RFC 768, August, 1980. */ #ifndef COMPAT_42 static int udpcksum = 1; #else static int udpcksum = 0; /* XXX */ #endif SYSCTL_INT(_net_inet_udp, UDPCTL_CHECKSUM, checksum, CTLFLAG_RW, &udpcksum, 0, "Calculate UDP checksum"); static u_long udp_sendspace = 9216; /* really max datagram size */ /* 40 1K datagrams */ SYSCTL_INT(_net_inet_udp, UDPCTL_MAXDGRAM, maxdgram, CTLFLAG_RW, &udp_sendspace, 0, "Maximum UDP datagram size"); static u_long udp_recvspace = 40 * (1024 + sizeof(struct sockaddr_in)); SYSCTL_INT(_net_inet_udp, UDPCTL_RECVSPACE, recvspace, CTLFLAG_RW, &udp_recvspace, 0, "Maximum UDP receive buffer size"); static struct inpcbhead udb; /* from udp_var.h */ static struct inpcbinfo udbinfo; #ifndef UDBHASHSIZE #define UDBHASHSIZE 64 #endif /* * UDP statistics */ struct udpstat udpstat; SYSCTL_STRUCT(_net_inet_udp, UDPCTL_STATS, stats, CTLFLAG_RW, &udpstat, udpstat, "UDP statistic"); static struct sockaddr_in udp_in = { sizeof(udp_in), AF_INET }; static void udp_detach __P((struct inpcb *)); static int udp_output __P((struct inpcb *, struct mbuf *, struct mbuf *, struct mbuf *)); static void udp_notify __P((struct inpcb *, int)); /* Added by Vasilkov. This system call is used by snmp agent code. * */ void udp_get_struct_udb (struct inpcbhead * strudb) { memcpy ((char*)strudb, (char*)&udb, sizeof(struct inpcbhead)); } /* * Register sysctl's */ void sysctl_register_udp_usrreq() { sysctl_register(_net_inet_udp,checksum); sysctl_register(_net_inet_udp,maxdgram); sysctl_register(_net_inet_udp,stats); sysctl_register(_net_inet_udp,recvspace); } void udp_init() { LIST_INIT(&udb); udbinfo.listhead = &udb; udbinfo.hashbase = hashinit(UDBHASHSIZE, M_PCB, &udbinfo.hashmask); } #ifdef FORWARD_PROTOCOL static unsigned char udp_ports[65536/8]; /* * Enable/Disable udp port forwarding */ int udp_forward_port(int port,int forward) { int byte = port/8; int offset = port%8; if (forward) udp_ports[byte] |= (0x80 >> offset); else udp_ports[byte] &= ~(0x80 >> offset); return 0; } /* * Check if port should be forwarded */ static int udp_if_forward(int port) { int byte = port/8; int offset = port%8; return (udp_ports[byte] & (0x80 >> offset)); } #endif /* FORWARD_PROTOCOL */ void udp_input(m, iphlen) register struct mbuf *m; int iphlen; { register struct ip *ip; register struct udphdr *uh; register struct inpcb *inp; struct mbuf *opts = 0, *fwd = 0; int len; struct ip save_ip; struct ifnet *ifp = m->m_pkthdr.rcvif; int log_in_vain = 0; int blackhole = 0; /* * Fetch logging flag from interface */ if (ifp->if_ip.ifi_udp & IFNET_UDP_LOG_IN_VAIN) log_in_vain = 1; /* * Check if we should silently discard refused connects */ if (ifp->if_ip.ifi_udp & IFNET_UDP_BLACKHOLE) blackhole = 1; udpstat.udps_ipackets++; /* * Strip IP options, if any; should skip this, * make available to user, and use on returned packets, * but we don't yet have a way to check the checksum * with options still present. */ if (iphlen > sizeof (struct ip)) { ip_stripoptions(m, (struct mbuf *)0); iphlen = sizeof(struct ip); } /* * Get IP and UDP header together in first mbuf. */ ip = mtod(m, struct ip *); if (m->m_len < iphlen + sizeof(struct udphdr)) { if ((m = m_pullup(m, iphlen + sizeof(struct udphdr))) == 0) { udpstat.udps_hdrops++; return; } ip = mtod(m, struct ip *); } uh = (struct udphdr *)((caddr_t)ip + iphlen); #ifdef FORWARD_PROTOCOL /* * Do local copy of mbuf */ if (udp_if_forward(ntohs(uh->uh_dport))) { fwd = m_copypacket(m,M_DONTWAIT); #ifdef FORWARD_DEBUG printf("Copy packet with port %d, iphlen=%d\n",ntohs(uh->uh_dport),ip->ip_len); #endif } #endif /* * Make mbuf data length reflect UDP length. * If not enough data to reflect UDP length, drop. */ len = ntohs((u_short)uh->uh_ulen); if (ip->ip_len != len) { if (len > ip->ip_len || len < sizeof(struct udphdr)) { udpstat.udps_badlen++; goto bad; } m_adj(m, len - ip->ip_len); /* ip->ip_len = len; */ } /* * Save a copy of the IP header in case we want restore it * for sending an ICMP error message in response. */ save_ip = *ip; /* * Checksum extended UDP header and data. */ if (uh->uh_sum) { ((struct ipovly *)ip)->ih_next = 0; ((struct ipovly *)ip)->ih_prev = 0; ((struct ipovly *)ip)->ih_x1 = 0; ((struct ipovly *)ip)->ih_len = uh->uh_ulen; uh->uh_sum = in_cksum(m, len + sizeof (struct ip)); if (uh->uh_sum) { udpstat.udps_badsum++; m_freem(m); if (fwd) m_freem(fwd); return; } } if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) || in_broadcast(ip->ip_dst, m->m_pkthdr.rcvif)) { struct inpcb *last; #ifdef FORWARD_PROTOCOL /* * If our router configured to route broadcasts (this may * be required to enable NetBIOS thru router) */ if (fwd) { /* * For each interface that allow directed broadcast * we should reflect this packet with destanation address * equal to interface subnet broadcast address */ struct ifnet *ifp = ifnet; struct mbuf *tmp; struct ip *ip = mtod(fwd,struct ip *); *ip = save_ip; ip->ip_len += iphlen; #ifdef FORWARD_DEBUG printf("Starting broadcast forwarding\n"); #endif while (ifp) { if ((ifp != fwd->m_pkthdr.rcvif) && !(ifp->if_flags & IFF_LOOPBACK) /*&& (ifp->if_ip.ifi_udp & IFNET_UDP_FORWARD_PROTOCOL)*/) { struct ifaddr *ifa = ifp->if_addrlist; #ifdef FORWARD_DEBUG printf("\tForwarding through %s%d\n",ifp->if_name,ifp->if_unit); #endif while(ifa) { int error; struct ip *ip = mtod(fwd, struct ip *); if (ifa->ifa_addr->sa_family == AF_INET) { struct route ro; if (ifp->if_flags | IFF_BROADCAST) { if (ifa->ifa_dstaddr) ip->ip_dst.s_addr = ((struct sockaddr_in *)(ifa->ifa_dstaddr))->sin_addr.s_addr; else { ip->ip_dst.s_addr = ((struct sockaddr_in *)(ifa->ifa_addr))->sin_addr.s_addr; ip->ip_dst.s_addr &= ((struct sockaddr_in *)(ifa->ifa_netmask))->sin_addr.s_addr; ip->ip_dst.s_addr |= ~(((struct sockaddr_in *)(ifa->ifa_netmask))->sin_addr.s_addr); } } else goto bad; #ifdef FORWARD_DEBUG printf("\t\tForwarding to %s\n",inet_ntoa(ip->ip_dst)); #endif bzero(&ro, sizeof ro); tmp = m_copypacket(fwd,M_DONTWAIT); error = ip_output(fwd, NULL, &ro, IP_ALLOWBROADCAST, NULL,0); #ifdef FORWARD_DEBUG if (error) printf("Output error %d\n",error); #endif fwd = tmp; if (!fwd) goto bad; if (ro.ro_rt) RTFREE(ro.ro_rt); } ifa = ifa->ifa_next; } } ifp = ifp->if_next; } m_freem(m); if (fwd) m_freem(fwd); if (opts) m_freem(opts); /* * FIXME: should also pass udp packet to socket */ return ; } #endif /* FORWARD_PROTOCOL */ /* * Deliver a multicast or broadcast datagram to *all* sockets * for which the local and remote addresses and ports match * those of the incoming datagram. This allows more than * one process to receive multi/broadcasts on the same port. * (This really ought to be done for unicast datagrams as * well, but that would cause problems with existing * applications that open both address-specific sockets and * a wildcard socket listening to the same port -- they would * end up receiving duplicates of every unicast datagram. * Those applications open the multiple sockets to overcome an * inadequacy of the UDP socket interface, but for backwards * compatibility we avoid the problem here rather than * fixing the interface. Maybe 4.5BSD will remedy this?) */ /* * Construct sockaddr format source address. */ udp_in.sin_port = uh->uh_sport; udp_in.sin_addr = ip->ip_src; m->m_len -= sizeof (struct udpiphdr); m->m_data += sizeof (struct udpiphdr); /* * Locate pcb(s) for datagram. * (Algorithm copied from raw_intr().) */ last = NULL; for (inp = udb.lh_first; inp != NULL; inp = inp->inp_list.le_next) { if (inp->inp_lport != uh->uh_dport) continue; if (inp->inp_laddr.s_addr != INADDR_ANY) { if (inp->inp_laddr.s_addr != ip->ip_dst.s_addr) continue; } if (inp->inp_faddr.s_addr != INADDR_ANY) { if (inp->inp_faddr.s_addr != ip->ip_src.s_addr || inp->inp_fport != uh->uh_sport) continue; } if (last != NULL) { struct mbuf *n; if ((n = m_copy(m, 0, M_COPYALL)) != NULL) { if (last->inp_flags & INP_CONTROLOPTS || last->inp_socket->so_options & SO_TIMESTAMP) ip_savecontrol(last, &opts, ip, n); if (sbappendaddr(&last->inp_socket->so_rcv, (struct sockaddr *)&udp_in, n, opts) == 0) { m_freem(n); if (opts) m_freem(opts); udpstat.udps_fullsock++; } else sorwakeup(last->inp_socket); opts = 0; } } last = inp; /* * Don't look for additional matches if this one does * not have either the SO_REUSEPORT or SO_REUSEADDR * socket options set. This heuristic avoids searching * through all pcbs in the common case of a non-shared * port. It * assumes that an application will never * clear these options after setting them. */ if (((last->inp_socket->so_options&(SO_REUSEPORT|SO_REUSEADDR)) == 0)) break; } if (last == NULL) { /* * No matching pcb found; discard datagram. * (No need to send an ICMP Port Unreachable * for a broadcast or multicast datgram.) */ udpstat.udps_noport++; udpstat.udps_noportbcast++; goto bad; } if (last->inp_flags & INP_CONTROLOPTS || last->inp_socket->so_options & SO_TIMESTAMP) ip_savecontrol(last, &opts, ip, m); if (sbappendaddr(&last->inp_socket->so_rcv, (struct sockaddr *)&udp_in, m, opts) == 0) { udpstat.udps_fullsock++; goto bad; } sorwakeup(last->inp_socket); if (fwd) m_freem(fwd); return; } /* * Locate pcb for datagram. */ inp = in_pcblookuphash(&udbinfo, ip->ip_src, uh->uh_sport, ip->ip_dst, uh->uh_dport, 1); if (inp == NULL) { if (log_in_vain) { char bufdst[20]; char bufsrc[20]; inet_ntop(AF_INET,&(ip->ip_dst),bufdst,sizeof(bufdst)); inet_ntop(AF_INET,&(ip->ip_src),bufdst,sizeof(bufsrc)); log(LOG_INFO, "Connection attempt to UDP %s:%d" " from %s:%d\n", bufdst, ntohs(uh->uh_dport), bufsrc, ntohs(uh->uh_sport)); } udpstat.udps_noport++; if (m->m_flags & (M_BCAST | M_MCAST)) { udpstat.udps_noportbcast++; goto bad; } *ip = save_ip; /* * If we forced to be silent as much as possible.. */ if (blackhole) goto bad; icmp_error(m, ICMP_UNREACH, ICMP_UNREACH_PORT, 0, 0); if (fwd) m_freem(fwd); return; } /* * Construct sockaddr format source address. * Stuff source address and datagram in user buffer. */ udp_in.sin_port = uh->uh_sport; udp_in.sin_addr = ip->ip_src; if (inp->inp_flags & INP_CONTROLOPTS || inp->inp_socket->so_options & SO_TIMESTAMP) ip_savecontrol(inp, &opts, ip, m); iphlen += sizeof(struct udphdr); m->m_len -= iphlen; m->m_pkthdr.len -= iphlen; m->m_data += iphlen; if (sbappendaddr(&inp->inp_socket->so_rcv, (struct sockaddr *)&udp_in, m, opts) == 0) { udpstat.udps_fullsock++; goto bad; } sorwakeup(inp->inp_socket); if (fwd) m_freem(fwd); return; bad: m_freem(m); if (fwd) m_freem(fwd); if (opts) m_freem(opts); } /* * Notify a udp user of an asynchronous error; * just wake up so that he can collect error status. */ static void udp_notify(inp, errnum) register struct inpcb *inp; int errnum; { inp->inp_socket->so_error = errnum; sorwakeup(inp->inp_socket); sowwakeup(inp->inp_socket); } void udp_ctlinput(cmd, sa, vip) int cmd; struct sockaddr *sa; void *vip; { register struct ip *ip = vip; register struct udphdr *uh; if (!PRC_IS_REDIRECT(cmd) && ((unsigned)cmd >= PRC_NCMDS || inetctlerrmap[cmd] == 0)) return; if (ip) { uh = (struct udphdr *)((caddr_t)ip + (ip->ip_hl << 2)); in_pcbnotify(&udb, sa, uh->uh_dport, ip->ip_src, uh->uh_sport, cmd, udp_notify); } else in_pcbnotify(&udb, sa, 0, zeroin_addr, 0, cmd, udp_notify); } static int udp_output(inp, m, addr, control) register struct inpcb *inp; register struct mbuf *m; struct mbuf *addr, *control; { register struct udpiphdr *ui; register int len = m->m_pkthdr.len; struct in_addr laddr; int s = 0, error = 0; if (control) m_freem(control); /* XXX */ if (len + sizeof(struct udpiphdr) > IP_MAXPACKET) { error = EMSGSIZE; goto release; } if (addr) { laddr = inp->inp_laddr; if (inp->inp_faddr.s_addr != INADDR_ANY) { error = EISCONN; goto release; } /* * Must block input while temporarily connected. */ s = splnet(); error = in_pcbconnect(inp, addr); if (error) { splx(s); goto release; } } else { if (inp->inp_faddr.s_addr == INADDR_ANY) { error = ENOTCONN; goto release; } } /* * Calculate data length and get a mbuf * for UDP and IP headers. */ M_PREPEND(m, sizeof(struct udpiphdr), M_DONTWAIT); if (m == 0) { error = ENOBUFS; if (addr) splx(s); goto release; } /* * Fill in mbuf with extended UDP header * and addresses and length put into network format. */ ui = mtod(m, struct udpiphdr *); ui->ui_next = ui->ui_prev = 0; ui->ui_x1 = 0; ui->ui_pr = IPPROTO_UDP; ui->ui_len = htons((u_short)len + sizeof (struct udphdr)); ui->ui_src = inp->inp_laddr; ui->ui_dst = inp->inp_faddr; ui->ui_sport = inp->inp_lport; ui->ui_dport = inp->inp_fport; ui->ui_ulen = ui->ui_len; /* * Stuff checksum and output datagram. */ ui->ui_sum = 0; if (udpcksum) { /*FIXME: should be taken from ouput interface */ if ((ui->ui_sum = in_cksum(m, sizeof (struct udpiphdr) + len)) == 0) ui->ui_sum = 0xffff; } ((struct ip *)ui)->ip_len = sizeof (struct udpiphdr) + len; ((struct ip *)ui)->ip_ttl = inp->inp_ip_ttl; /* XXX */ ((struct ip *)ui)->ip_tos = inp->inp_ip_tos; /* XXX */ udpstat.udps_opackets++; error = ip_output(m, inp->inp_options, &inp->inp_route, inp->inp_socket->so_options & (SO_DONTROUTE | SO_BROADCAST), inp->inp_moptions,0); if (addr) { in_pcbdisconnect(inp); inp->inp_laddr = laddr; splx(s); } return (error); release: m_freem(m); return (error); } /*ARGSUSED*/ int udp_usrreq(so, req, m, addr, control) struct socket *so; int req; struct mbuf *m, *addr, *control; { struct inpcb *inp = sotoinpcb(so); int error = 0; int s; if (req == PRU_CONTROL) return (in_control(so, (u_long)m, (caddr_t)addr, (struct ifnet *)control)); if (inp == NULL && req != PRU_ATTACH) { error = EINVAL; goto release; } /* * Note: need to block udp_input while changing * the udp pcb queue and/or pcb addresses. */ switch (req) { case PRU_ATTACH: if (inp != NULL) { error = EINVAL; break; } s = splnet(); error = in_pcballoc(so, &udbinfo); splx(s); if (error) break; error = soreserve(so, udp_sendspace, udp_recvspace); if (error) break; ((struct inpcb *) so->so_pcb)->inp_ip_ttl = ip_defttl; /*FIXME: fetch ttl from interface first*/ break; case PRU_DETACH: udp_detach(inp); break; case PRU_BIND: s = splnet(); error = in_pcbbind(inp, addr); splx(s); break; case PRU_LISTEN: error = EOPNOTSUPP; break; case PRU_CONNECT: if (inp->inp_faddr.s_addr != INADDR_ANY) { error = EISCONN; break; } s = splnet(); error = in_pcbconnect(inp, addr); splx(s); if (error == 0) soisconnected(so); break; case PRU_CONNECT2: error = EOPNOTSUPP; break; case PRU_ACCEPT: error = EOPNOTSUPP; break; case PRU_DISCONNECT: if (inp->inp_faddr.s_addr == INADDR_ANY) { error = ENOTCONN; break; } s = splnet(); in_pcbdisconnect(inp); inp->inp_laddr.s_addr = INADDR_ANY; splx(s); so->so_state &= ~SS_ISCONNECTED; /* XXX */ break; case PRU_SHUTDOWN: socantsendmore(so); break; case PRU_SEND: return (udp_output(inp, m, addr, control)); case PRU_ABORT: soisdisconnected(so); udp_detach(inp); break; case PRU_SOCKADDR: in_setsockaddr(inp, addr); break; case PRU_PEERADDR: in_setpeeraddr(inp, addr); break; case PRU_SENSE: /* * stat: don't bother with a blocksize. */ return (0); case PRU_SENDOOB: case PRU_FASTTIMO: case PRU_SLOWTIMO: case PRU_PROTORCV: case PRU_PROTOSEND: error = EOPNOTSUPP; break; case PRU_RCVD: case PRU_RCVOOB: return (EOPNOTSUPP); /* do not free mbuf's */ default: panic("udp_usrreq"); } release: if (control) { printf("udp control data unexpectedly retained\n"); m_freem(control); } if (m) m_freem(m); return (error); } static void udp_detach(inp) struct inpcb *inp; { int s = splnet(); in_pcbdetach(inp); splx(s); } --------------020207040507030300010903-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 9 6:36:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1136F37B400 for ; Tue, 9 Jul 2002 06:36:10 -0700 (PDT) Received: from smtp.uc3m.es (smtp03.uc3m.es [163.117.136.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C9EC43E58 for ; Tue, 9 Jul 2002 06:36:09 -0700 (PDT) (envelope-from jrh@it.uc3m.es) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 6750643138 for ; Tue, 9 Jul 2002 14:36:10 +0200 (CEST) Received: from it.uc3m.es (alacran.it.uc3m.es [163.117.140.44]) by smtp03.uc3m.es (Postfix) with ESMTP id 5A99199DED for ; Tue, 9 Jul 2002 14:36:10 +0200 (CEST) Message-ID: <3D2AE6BB.7CD0CEC7@it.uc3m.es> Date: Tue, 09 Jul 2002 15:35:55 +0200 From: Juan Francisco Rodriguez Hervella X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: About "sockaddr_in" and "sockaddr_in6" structures Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello: I'm seeing that "struct sockaddr_in" has a field like this: char sin_zero[8]; Why ? Could anyone explain me what's used for ? Could it be bad if I'd add the same field to "sockaddr_in6" ? PS: I'm trying to implement divert sockets for IPv6 using the KAME implementation of "ip6fw". Thanks. JFRH. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 9 10:46:39 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DB7E37B400 for ; Tue, 9 Jul 2002 10:46:35 -0700 (PDT) Received: from anastasia.lan.blastermaster.de (p5087B5E7.dip.t-dialin.net [80.135.181.231]) by mx1.FreeBSD.org (Postfix) with SMTP id 162F243E52 for ; Tue, 9 Jul 2002 10:46:28 -0700 (PDT) (envelope-from jt@barfoos.de) Received: (qmail 83533 invoked by uid 1001); 9 Jul 2002 17:46:24 -0000 Date: Tue, 9 Jul 2002 19:46:24 +0200 From: Jens Trzaska To: Brad Davis Cc: freebsd-net@freebsd.org Subject: Re: monitoring bandwidth usage Message-ID: <20020709174624.GB82172@anastasia.lan.blastermaster.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 4.6-RELEASE, i386 X-GPG-Key-ID: = 96FE36DB X-GPG-Key-Fingerprint: 1C9B 7EF8 1A22 1740 9F1B AB7B 17D2 64E1 96FE 36DB X-GPG-Key-Location: http://www.elug.de/schluessel/96FE36DB.asc X-Accept-Language: de,en User-Agent: Mutt/1.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jul 09, 2002 at 03:26:21AM -0600, Brad Davis wrote: > Hello, > > I was wondering if there was a way that I could monitor the bandwidth usage > live? I have heard of a linux program called iptraf, is there something > similar to that for FreeBSD? If it's just the bandwidth something like 'netstat -w 1 -I fxp0' will do the trick. If you are searching for something that's more like iptraf you may try trafshow from the ports. Jens -- KeyID=96FE36DB Key fingerprint=1C9B 7EF8 1A22 1740 9F1B AB7B 17D2 64E1 96FE 36DB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 9 11: 0:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3078637B400 for ; Tue, 9 Jul 2002 11:00:51 -0700 (PDT) Received: from kronos.networkrichmond.com (kronos.networkrichmond.com [64.240.180.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 803C443E4A for ; Tue, 9 Jul 2002 11:00:50 -0700 (PDT) (envelope-from kbyanc@posi.net) X-Provider: NetworkRichmond, Inc. http://www.networkrichmond.com/ Received: from localhost (kbyanc@localhost) by kronos.networkrichmond.com (8.9.3/8.9.3/antispam) with ESMTP id OAA04886; Tue, 9 Jul 2002 14:00:38 -0400 (EDT) Date: Tue, 9 Jul 2002 14:00:38 -0400 (EDT) From: Kelly Yancey X-Sender: kbyanc@kronos.networkrichmond.com To: Juan Francisco Rodriguez Hervella Cc: freebsd-net@FreeBSD.ORG Subject: Re: About "sockaddr_in" and "sockaddr_in6" structures In-Reply-To: <3D2AE6BB.7CD0CEC7@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 9 Jul 2002, Juan Francisco Rodriguez Hervella wrote: > Hello: > > I'm seeing that "struct sockaddr_in" has a field like this: > > char sin_zero[8]; > > Why ? > Could anyone explain me what's used for ? > > Could it be bad if I'd add the same field to > "sockaddr_in6" ? > > PS: I'm trying to implement divert sockets for > IPv6 using the KAME implementation of "ip6fw". > > Thanks. > > JFRH. > The minimum size of a sockaddr's address portion (as defined in sys/socket.h) is 14 bytes (max is SOCK_MAXADDRLEN = 255); combined with the size of the sa_len and sa_family fields you get a minimum length of 16 bytes for the entire structure. The sin_zero field of sockaddr_in is to pad the structure out to this minimum length. Given that a sockaddr_in6 is already larger than the minimum required, there really isn't any point in adding the padding field to it. Kelly -- Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 9 14:50:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF51637B400 for ; Tue, 9 Jul 2002 14:50:48 -0700 (PDT) Received: from mx20b.rmci.net (mx20b.rmci.net [205.162.184.38]) by mx1.FreeBSD.org (Postfix) with SMTP id 57D8B43E31 for ; Tue, 9 Jul 2002 14:50:48 -0700 (PDT) (envelope-from term@velocitus.net) Received: (qmail 27003 invoked from network); 9 Jul 2002 21:50:42 -0000 Received: from exchange.rmci.net (216.222.101.3) by mx20.rmci.net with SMTP; 9 Jul 2002 21:50:42 -0000 Received: by exchange.rmci.net with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Jul 2002 15:50:42 -0600 Message-ID: From: Chris Given To: "'freebsd-net@freebsd.org'" Subject: Bind to specific address on FreeBSD Date: Tue, 9 Jul 2002 15:50:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I can't figure out why this code won't bind to 127.0.0.1 on FreeBSD. I get an error "Can't assign requested address". #include #include #include #include #include #include #include #include #include #include #include #include #include int main() { int sock; struct sockaddr_in dp; unsigned long bind_to_addr = inet_addr("127.0.0.1"); sock = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP); if(sock < 0) { printf("Error socket : %s\n", strerror(errno)); return -1; } dp.sin_family = AF_INET; dp.sin_addr.s_addr = htonl(bind_to_addr); dp.sin_port = htons(1234); if(bind(sock, (struct sockaddr*)&dp, sizeof(struct sockaddr_in))!=0) { printf("Bind failed : %s\n", strerror(errno)); } else { printf("Bind success\n"); } } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 9 15:36:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D792137B400 for ; Tue, 9 Jul 2002 15:36:22 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id A406243E4A for ; Tue, 9 Jul 2002 15:36:22 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 4F1FDAE3DC; Tue, 9 Jul 2002 15:36:22 -0700 (PDT) Date: Tue, 9 Jul 2002 15:36:22 -0700 From: Alfred Perlstein To: Chris Given Cc: "'freebsd-net@freebsd.org'" Subject: Re: Bind to specific address on FreeBSD Message-ID: <20020709223622.GJ97638@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Chris Given [020709 14:50] wrote: > I can't figure out why this code won't bind to 127.0.0.1 on FreeBSD. I get > an error "Can't assign requested address". I don't think you want to htonl the return value from inet_addr, as it should already be in network order. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 9 17: 5:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7436237B400 for ; Tue, 9 Jul 2002 17:05:54 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF65643E4A for ; Tue, 9 Jul 2002 17:05:53 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.5/8.12.5) with ESMTP id g6A05Wwr005505; Tue, 9 Jul 2002 17:05:36 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Message-Id: <200207100005.g6A05Wwr005505@gw.catspoiler.org> Date: Tue, 9 Jul 2002 17:05:32 -0700 (PDT) From: Don Lewis Subject: Re: Bind to specific address on FreeBSD To: term@velocitus.net Cc: freebsd-net@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 9 Jul, Chris Given wrote: > I can't figure out why this code won't bind to 127.0.0.1 on FreeBSD. I get > an error "Can't assign requested address". > > struct sockaddr_in dp; > unsigned long bind_to_addr = inet_addr("127.0.0.1"); > > sock = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP); > if(sock < 0) { > printf("Error socket : %s\n", strerror(errno)); > return -1; > } > > dp.sin_family = AF_INET; > dp.sin_addr.s_addr = htonl(bind_to_addr); > dp.sin_port = htons(1234); In addition to the byte order problem you haven't initialized the sin_len member of dp and cleared the sin_zero member. Typically code will zero out the entire structure to clear any padding or fields that can default to zero before it stores the desired data in the structure. Here's an example I found in rwhod: struct sockaddr_in sin; ... memset(&sin, 0, sizeof(sin)); sin.sin_len = sizeof(sin); sin.sin_family = AF_INET; sin.sin_port = sp->s_port; if (bind(s, (struct sockaddr *)&sin, sizeof(sin)) < 0) { syslog(LOG_ERR, "bind: %m"); exit(1); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 9 22: 7:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41DB037B400 for ; Tue, 9 Jul 2002 22:07:46 -0700 (PDT) Received: from consult-scs.com (vpn.consult-scs.com [216.218.207.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3E7A43E09 for ; Tue, 9 Jul 2002 22:07:45 -0700 (PDT) (envelope-from vulture@consult-scs.com) Received: from consult-scs.com (bigv.netvulture.com [192.168.2.2]) (authenticated bits=0) by consult-scs.com (8.12.3/8.12.3) with ESMTP id g6A59AG3028293 for ; Tue, 9 Jul 2002 22:09:10 -0700 (PDT) Message-ID: <3D2BC11C.2000508@consult-scs.com> Date: Tue, 09 Jul 2002 22:07:40 -0700 From: Jonathan Feally User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG Subject: IPSEC Tunnel Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Is it not possible to have the internal ip addresses of the tunnel machines talk with other internal addresses on the other side of the tunnel? Example Set Up: Packets from say 192.168.0.2 to 192.168.1.1 and back (192.168.0.0/24 Lan)-(192.168.0.1 Internal)->(200.0.0.1 Interface)===IPSEC TUNNEL===(200.0.0.2 Inteface)<-(192.168.1.1 Internal)-(192.168.0.1/24 Lan) I can see the packets from 192.168.0.2->192.168.1.1 under tcpdump of 200.0.0.2 as a (ipip) Packet from 200.0.0.1->200.0.0.2 having 192.168.0.2->192.168.1.1 listed but the packet just seems to disappear after that. It does not show up under lo0 or the internal interface. Any Thoughts? Thanks Jon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 10 2:19:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2DE7337B401 for ; Wed, 10 Jul 2002 02:19:51 -0700 (PDT) Received: from mail.andy.de (mail.andy.de [212.8.199.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBE1543E42 for ; Wed, 10 Jul 2002 02:19:50 -0700 (PDT) (envelope-from andy@andy.de) Received: from localhost.localdomain (mail.andy.de [212.8.199.66]) by mail.andy.de (Postfix) with ESMTP id F0BF74772E7 for ; Wed, 10 Jul 2002 11:19:49 +0200 (CEST) Received: from [10.0.0.10] (gateway.buero.teuto.net [212.8.197.50]) by mail.andy.de (Postfix) with ESMTP id 31C70477241 for ; Wed, 10 Jul 2002 11:19:49 +0200 (CEST) Date: Wed, 10 Jul 2002 11:18:54 +0200 From: Andreas Gerstenberg To: freebsd-net@freebsd.org Subject: limits in routing table? Message-ID: <10400000.1026292734@ag.intra> X-Mailer: Mulberry/2.2.0 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I got the following error while figuring out the maximum amount of routes in the kernel routing table: # route add 192.168.1.1/32 10.0.0.1 route: writing to routing socket: No buffer space available add net 192.168.1.1: gateway 10.0.0.1: routing table overflow # netstat -rn | wc -l 299448 How can I set a higher limit? System: XP1700+, 512 MB DDR-RAM, FreeBSD 4.6p1 (RELENG_4_6) Maxusers is set to 512 regards, Andy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 10 9:23:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CA8437B400 for ; Wed, 10 Jul 2002 09:23:27 -0700 (PDT) Received: from omegaband.com (faust.seagullsemi.com [206.196.68.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C25D43E09 for ; Wed, 10 Jul 2002 09:23:27 -0700 (PDT) (envelope-from matt@omegaband.com) Received: from orcapc [67.89.124.10] by omegaband.com with ESMTP (SMTPD32-7.04) id AD72D4AB0150; Wed, 10 Jul 2002 11:14:42 -0500 Message-ID: <011001c2282e$1e5fd9c0$ad96a8c0@seagullsemi.com> From: "Matthew Finlay" To: "Chris Given" , References: Subject: Re: Bind to specific address on FreeBSD Date: Wed, 10 Jul 2002 11:23:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org first zero out your sockaddr_in structure before using it. bzero(&dp, sizeof(dp)); and then be sure and set the len field in sockaddr_in struct; dp.sin_len = sizeof(dp); also... get rid of the htonl(bind_to_addr) because inet_addr puts the address in network byte order. i compiled with those changes and the bind succeeded. my guess is the sockaddr_in struct had garbage in the fields that werent initialized... causing an error somewhere along the way. -matt ----- Original Message ----- From: "Chris Given" To: Sent: Tuesday, July 09, 2002 4:50 PM Subject: Bind to specific address on FreeBSD > I can't figure out why this code won't bind to 127.0.0.1 on FreeBSD. I get > an error "Can't assign requested address". > > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > > int main() { > int sock; > struct sockaddr_in dp; > unsigned long bind_to_addr = inet_addr("127.0.0.1"); > > sock = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP); > if(sock < 0) { > printf("Error socket : %s\n", strerror(errno)); > return -1; > } > > dp.sin_family = AF_INET; > dp.sin_addr.s_addr = htonl(bind_to_addr); > dp.sin_port = htons(1234); > > if(bind(sock, (struct sockaddr*)&dp, sizeof(struct sockaddr_in))!=0) > { > printf("Bind failed : %s\n", strerror(errno)); > } else { > printf("Bind success\n"); > } > } > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 10 16:30:41 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93F8E37B400; Wed, 10 Jul 2002 16:30:36 -0700 (PDT) Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48F5A43E64; Wed, 10 Jul 2002 16:30:35 -0700 (PDT) (envelope-from jhs@jhs.muc.de) Received: from fwd03.sul.t-online.de by mailout01.sul.t-online.com with smtp id 17SQuo-0006e7-01; Thu, 11 Jul 2002 01:30:34 +0200 Received: from jhs.muc.de (520006753247-0001@[217.228.210.254]) by fmrl03.sul.t-online.com with esmtp id 17SQvP-0U93QGC; Thu, 11 Jul 2002 01:31:11 +0200 Received: from flip.jhs.private (flip.jhs.private [192.168.91.24]) by jhs.muc.de (8.11.6/8.11.6) with ESMTP id g6ANUrv09225; Thu, 11 Jul 2002 01:30:54 +0200 (MET DST) (envelope-from jhs@jhs.muc.de) Received: (from jhs@localhost) by flip.jhs.private (8.11.6/8.11.6) id g6ANUrV66462; Thu, 11 Jul 2002 01:30:53 +0200 (CEST) (envelope-from jhs) Date: Thu, 11 Jul 2002 01:30:53 +0200 (CEST) Message-Id: <200207102330.g6ANUrV66462@flip.jhs.private> To: freebsd-net@freebsd.org Cc: "Gary Jennejohn" Subject: Masquerade fails to suppress X-sender From: "Julian Stacey" Organization: Vector Systems Ltd, Munich Unix & System Engineering Consultancy X-Web: http://bim.bsn.com/~jhs/ Fcc: sent-mail X-Sender: 520006753247-0001@t-dialin.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi freebsd-net@freebsd.org Since I gave my FreeBSD-4.5-Release gateway a new sendmail.cf today, I've been getting both these in my headers: Received: from jhs.muc.de (520006753247-0001@[217.235.121.155]) by fmrl11.sul.t-online.com with esmtp id 17SPs5-0MzVXEC; Thu, 11 Jul 2002 00:23:41 +0200 X-sender: 520006753247-0001@t-dialin.net I never used to have 520006753247 appear, (I've confirmed that by inspecting my morning's post to a simple expoder list (that leaves headers unchanged), which came back clean without any 520006753247) ( Reason I don't want people to see 520006753247-0001 is that's my account, & while not private as such, no need ot publicise, & dont want people emailing me (or spamming!) there either ). So I'd like to kill off that number from appearing, any idea how to do it ? I tried enabling allmasquerade, didn't help. I disabled in .cf the DSsmtprelay.t-online.de & that did indeed avoid the 2 lines with 520006753247-0001 in, but thats a bit drastic, I'd prefer to use the t-online.de smart host if possible ? Does that seem likely possible ? I'm on a DSL with dynamic IP & time out, so think it better to use the ISP's relay if possible. ( I do have control of another FreeBSD box on the net I coud use as a relay, but I'd have to get myself set up for DDNS first I presume, before it would be safe to tell my other box on the permanent net to relay me ). Here's my sendmail.mc, The file I generate the .mc from contains my notes http://bim.bsn.com/~jhs/src/bsd/fixes/FreeBSD/src/jhs/etc/sendmail/common.cpp VERSIONID(`@(#) src/etc/sendmail/common.cpp by jhs@ for wall.jhs.private ') OSTYPE(freebsd4) define(`RECEIVER_JHS_FULL',`mail.jhs.private') define(`MASQ_JHS_HOST',`jhs') define(`MASQ_JHS_DOMAIN',`muc.de') define(`MASQ_JHS_FULL',`MASQ_JHS_HOST.MASQ_JHS_DOMAIN') MASQUERADE_AS(`MASQ_JHS_FULL') MASQUERADE_DOMAIN(`jhs.private mmc.private gj.org ew.private') MASQUERADE_DOMAIN_FILE(`/etc/mail/masquerade') FEATURE(masquerade_envelope) define(`SMART_JHS_HOST',`smtprelay') define(`SMART_JHS_DOMAIN',`t-online.de') define(`SMART_JHS_FULL',`SMART_JHS_HOST.SMART_JHS_DOMAIN') # F EATURE(allmasquerade) FEATURE(masquerade_entire_domain) FEATURE(`relay_entire_domain') FEATURE(access_db,`hash -o /etc/mail/access') FEATURE(blacklist_recipients) FEATURE(virtusertable, `hash -o /etc/mail/virtusertable') FEATURE(local_lmtp) FEATURE(smrsh) FEATURE(`accept_unresolvable_domains') define(`confCW_FILE',`-o /etc/mail/local-host-names-gateway') define(`confNO_RCPT_ACTION',`add-to-undisclosed') define(`confMAX_MIME_HEADER_LENGTH',`256/128') define(`confPRIVACY_FLAGS',`authwarnings,noexpn,novrfy') FEATURE(use_cw_file) define(`MAIL_HUB',`RECEIVER_JHS_FULL') define(`SMART_HOST',`smtp:SMART_JHS_FULL') undefine(`UUCP_RELAY') define(`confTRUSTED_USERS', `jhs majordom') define(`confTIME_ZONE',`USE_SYSTEM') define(`confAUTO_REBUILD',True) define(`confCOPY_ERRORS_TO',`postmaster') define(`confTO_QUEUERETURN',`3d') define(`confTO_QUEUEWARN',`24h') define(`confDIAL_DELAY',`8s') Dw`'MASQ_JHS_HOST Dm`'MASQ_JHS_DOMAIN define(`confDOMAIN_NAME', $w.$m) define(`LUSER_RELAY',`RECEIVER_JHS_FULL') define(`LOCAL_RELAY',`RECEIVER_JHS_FULL') define(`confTO_HOSTSTATUS',`6h') MAILER(local) MAILER(smtp) MAILER(uucp) EXPOSED_USER(jhs2) Any hints welcome, thanks ! Julian Stacey Freelance Unix (BSD Linux etc) Consultant, Munich Ihr Rauchen = mein allergischer Kopfschmerz ! Schnupftabak probieren. FreeBSD-4.6 just released: 7000 Free programs: http://www.freebsd.org/ports/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 0:51: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5D5637B400 for ; Thu, 11 Jul 2002 00:50:43 -0700 (PDT) Received: from chicken.orbitel.bg (chicken100.orbitel.bg [195.24.32.21]) by mx1.FreeBSD.org (Postfix) with SMTP id D651243E58 for ; Thu, 11 Jul 2002 00:50:41 -0700 (PDT) (envelope-from I.Tanusheff@procreditbank.com) Received: (qmail 22587 invoked from network); 11 Jul 2002 07:49:59 -0000 Received: from unknown (HELO procreditbank.com) (212.95.171.20) by chicken.orbitel.bg with SMTP; 11 Jul 2002 07:49:59 -0000 Received: from itaush [172.16.248.203] by Proxy+; Thu, 11 Jul 2002 10:43:34 +0300 for multiple recipients From: "Ivailo Tanusheff" To: "FreeBSD Net" Cc: "FreeBSD Questions" Subject: Strange behaviour Date: Thu, 11 Jul 2002 10:37:06 +0300 Message-ID: <009c01c228ad$c1bae720$cbf810ac@sof.procreditbank.bg> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009D_01C228C6.E7081F20" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_009D_01C228C6.E7081F20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all, I've encountered some strange behavior on my network. I have two similar FreeBSD servers each with Squid and DNS server (djbdns). One of them is NAT/Firewall. They are in different locations, thus they are connected trough Frame relay and are in different subnets. One is "master", other Is "slave" server. Sometimes it happens that they just can't see each other. Each of them may see the whole other subnet, except the other server. Because of this the dns resolve and proxy is not functioning correct on the slave server. Have you any idea where the problem is and how may I solve it? Any help is appreciated. Thank you in advantage, Ivailo Tanusheff ------=_NextPart_000_009D_01C228C6.E7081F20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

I’ve encountered some strange behavior on my = network. I have two similar FreeBSD servers each with Squid and DNS server (djbdns). One of them is NAT/Firewall. They are in = different locations, thus they are connected trough Frame relay and are in = different subnets. One is “master”, other Is “slave” server.

Sometimes it happens that they just can’t see = each other. Each of them may see the whole other subnet, except the other = server. Because of this the dns resolve and proxy is = not functioning correct on the slave server. Have you any idea where the = problem is and how may I solve it?

Any help is appreciated.

 

Thank you in advantage,

Iva<= /font>ilo Tanusheff

------=_NextPart_000_009D_01C228C6.E7081F20-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 3:55:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1523C37B400 for ; Thu, 11 Jul 2002 03:55:32 -0700 (PDT) Received: from hotmail.com (f255.law14.hotmail.com [64.4.20.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82C0D43E42 for ; Thu, 11 Jul 2002 03:55:31 -0700 (PDT) (envelope-from alexdyas@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 11 Jul 2002 03:55:31 -0700 Received: from 194.6.2.163 by lw14fd.law14.hotmail.msn.com with HTTP; Thu, 11 Jul 2002 10:55:31 GMT X-Originating-IP: [194.6.2.163] From: "Alex Dyas" To: net@freebsd.org Subject: BSD / Firewall / 0 window size problem Date: Thu, 11 Jul 2002 10:55:31 +0000 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_62e2_3a0_21fe" Message-ID: X-OriginalArrivalTime: 11 Jul 2002 10:55:31.0398 (UTC) FILETIME=[79A1CE60:01C228C9] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_62e2_3a0_21fe Content-Type: text/plain; format=flowed Hi, I hope someone can help me with this, I've been struggling with it for quite some time now. The set up: bsdbox.foo.com -> internal GNAT firewall -> otherbox.foo.com where bsdbox.foo.com has been anything from 4.0 to 4.5, and otherbox.foo.com is anything from FreeBSD, Solaris 2.7, Solaris 2.8 The problem is delays when telnetting from the BSD box to the Solaris box. I open and use the telnet session no problem. However, if I leave the session alone for more than about 15 seconds it will lock up. The lock up will last for about 8 seconds before it lets me type again. This is not fun. The only clue I've managed to find as to what is going on is in a tcpdump of the session (attached). The trigger for the lock up seems to be a messages from the Otherbox machine setting the window size to 0 : 10:41:38.614141 otherbox.foo.com.telnet > bsdbox.foo.com.2230: . ack 154 win 0 10:41:38.614200 bsdbox.foo.com.2230 > otherbox.foo.com.telnet: . ack 337 win 33304 (DF) [tos 0x10] I've tried all the following scenarios, none of which exhibit the same problem, which is why I think the problem is with FreeBSD : bsdbox.foo.com -> otherbox.foo.com solarisbox.foo.com -> internal GNAT firewall -> otherbox.foo.com windowsbox.foo.com -> internal GNAT firewall -> otherbox.foo.com linuxbox.foo.com -> internal GNAT firewall -> otherbox.foo.com No blocks are seen on the firewall. Any ideas/pointers/suggestions/fixes at all much appreciated. Alex... _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com ------=_NextPart_000_62e2_3a0_21fe Content-Type: text/plain; name="tcpdump.txt"; format=flowed Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="tcpdump.txt" 10:41:22.149761 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: P 146:148(2) ack 285 win 33304 (DF) [tos 0x10] 10:41:22.150396 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P 285:287(2) ack 148 win 24616 (DF) 10:41:22.249151 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 287 win 33304 (DF) [tos 0x10] 10:41:22.249515 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P 287:298(11) ack 148 win 24616 (DF) 10:41:22.349154 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 298 win 33304 (DF) [tos 0x10] 10:41:22.380132 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: P 148:150(2) ack 298 win 33304 (DF) [tos 0x10] 10:41:22.380644 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P 298:300(2) ack 150 win 24616 (DF) 10:41:22.484269 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 300 win 33304 (DF) [tos 0x10] 10:41:22.484920 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P 300:311(11) ack 150 win 24616 (DF) 10:41:22.579160 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 311 win 33304 (DF) [tos 0x10] 10:41:22.599564 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: P 150:152(2) ack 311 win 33304 (DF) [tos 0x10] 10:41:22.600250 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P 311:313(2) ack 152 win 24616 (DF) 10:41:22.699161 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 313 win 33304 (DF) [tos 0x10] 10:41:22.699564 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P 313:324(11) ack 152 win 24616 (DF) 10:41:22.799162 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 324 win 33304 (DF) [tos 0x10] 10:41:22.818906 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: P 152:154(2) ack 324 win 33304 (DF) [tos 0x10] 10:41:22.819479 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P 324:326(2) ack 154 win 24616 (DF) 10:41:22.919168 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 326 win 33304 (DF) [tos 0x10] 10:41:22.919576 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P 326:337(11) ack 154 win 24616 (DF) 10:41:23.019171 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 337 win 33304 (DF) [tos 0x10] 10:41:38.614141 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: . ack 154 win 0 10:41:38.614200 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 337 win 33304 (DF) [tos 0x10] 10:41:47.199533 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . 154:155(1) ack 337 win 33304 (DF) [tos 0x10] 10:41:47.297912 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: . ack 155 win 24616 (DF) 10:41:47.297970 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: P 155:162(7) ack 337 win 33304 (DF) [tos 0x10] 10:41:47.298154 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P 337:339(2) ack 155 win 24616 (DF) 10:41:47.389540 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 339 win 33304 (DF) [tos 0x10] 10:41:47.390038 solarisbox.foo.com.telnet > bsdbox.foo.com.2230: P 339:395(56) ack 162 win 24616 (DF) 10:41:47.489541 bsdbox.foo.com.2230 > solarisbox.foo.com.telnet: . ack 395 win 33304 (DF) [tos 0x10] ------=_NextPart_000_62e2_3a0_21fe-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 6: 4:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DFC337B408 for ; Thu, 11 Jul 2002 06:04:28 -0700 (PDT) Received: from vbook.express.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3165343E3B for ; Thu, 11 Jul 2002 06:04:27 -0700 (PDT) (envelope-from vova@express.ru) Received: from vova by vbook.express.ru with local (Exim 3.36 #1) id 17SdcF-0002WU-00; Thu, 11 Jul 2002 17:04:15 +0400 Subject: Re: limits in routing table? From: "Vladimir B. " Grebenschikov To: Andreas Gerstenberg Cc: freebsd-net@freebsd.org In-Reply-To: <10400000.1026292734@ag.intra> References: <10400000.1026292734@ag.intra> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Mailer: Ximian Evolution 1.0.7 Date: 11 Jul 2002 17:04:14 +0400 Message-Id: <1026392654.790.46.camel@vbook.express.ru> Mime-Version: 1.0 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org =F7 Wed, 10.07.2002, =D7 13:18, Andreas Gerstenberg =CE=C1=D0=C9=D3=C1=CC: > Hi, >=20 > I got the following error while figuring out the maximum amount of routes= =20 > in the kernel routing table: >=20 > # route add 192.168.1.1/32 10.0.0.1 > route: writing to routing socket: No buffer space available > add net 192.168.1.1: gateway 10.0.0.1: routing table overflow >=20 > # netstat -rn | wc -l > 299448 First, you can see is it route area limit with: # vmstat -m | fgrep routetbl\ routetbl 6907 942K 1678K102400K 4870047 0 0=20 16,32,64,128,256,512 legend is: # vmstat -m | fgrep HighUse Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) On -CURRENT, as I understand there no limit for routetbl zone: # vmstat -m | fgrep rou routetbl 87 12K 13K 267490 16,32,64,128,256 # vmstat -m | fgrep MemUse Type InUse MemUse HighUse Requests Size(s) =20 =20 > How can I set a higher limit? for 4.x you can use following define in kernel config: options VM_KMEM_SIZE_SCALE=3D"(1)" # VM_KMEM_SIZE_SCALE can be set to adjust the auto-tuning factor, which # typically defaults to 4 (kernel malloc area size is physical memory=20 # divided by the scale factor). It works for me (see above) Or you can use -CURRENT to large routing tables, but not sure that it is good idea for production routers. > System: XP1700+, 512 MB DDR-RAM, FreeBSD 4.6p1 (RELENG_4_6) > Maxusers is set to 512 >=20 > regards, > Andy =20 --=20 Vladimir B. Grebenschikov vova@sw.ru, SWsoft, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 7:54:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77BC737B400; Thu, 11 Jul 2002 07:53:57 -0700 (PDT) Received: from excite.com (host134225.metrored.net.ar [200.59.134.225]) by mx1.FreeBSD.org (Postfix) with SMTP id B636A43E54; Thu, 11 Jul 2002 07:53:45 -0700 (PDT) (envelope-from Center_for_Age6414n05@excite.com) Received: from smtp013.mail.yahou.com ([29.16.108.187]) by mailout2-eri1.midmouth.com with esmtp; Thu, 11 Jul 0102 06:54:02 -0100 Received: from unknown (HELO mail.gimmixx.net) (155.22.111.109) by mta21.bigpong.com with SMTP; 11 Jul 0102 05:51:36 +1000 Received: from unknown (HELO rly-yk05.pesdets.com) (187.197.82.227) by n7.groups.huyahoo.com with asmtp; Thu, 11 Jul 0102 15:49:10 -0300 Received: from unknown (146.133.89.190) by symail.kustanai.co.kr with SMTP; 11 Jul 0102 12:46:44 -0000 Received: from 11.215.236.71 ([11.215.236.71]) by q4.quickslow.com with local; 11 Jul 0102 12:44:18 +0200 Reply-To: "Office" Message-ID: <025c34b26e3a$5734d7c4$5cb48da7@ajjqnx> From: "Office" To: Cc: , , , , , Subject: Three types of HGH products Date: Thu, 11 Jul 0102 12:53:21 +0200 MiME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00A3_62D23A1C.D7817E20" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ------=_NextPart_000_00A3_62D23A1C.D7817E20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 QXJlIEhHSCBwcm9kdWN0cyBkaWZmZXJlbnQ/DQoNCjxodG1sPg0KDQo8aGVh ZD4NCg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50 PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9d2luZG93cy0xMjUyIj4NCg0KPG1ldGEg bmFtZT0iR0VORVJBVE9SIiBjb250ZW50PSJNaWNyb3NvZnQgRnJvbnRQYWdl IDQuMCI+DQoNCjxtZXRhIG5hbWU9IlByb2dJZCIgY29udGVudD0iRnJvbnRQ YWdlLkVkaXRvci5Eb2N1bWVudCI+DQoNCjx0aXRsZT5UaGVyZSBhcmUgdGhy ZWUgZGlmZmVyZW50IHR5cGVzIG9mIEhHSCBwcm9kdWN0czwvdGl0bGU+DQoN CjwvaGVhZD4NCg0KPGJvZHkgYmFja2dyb3VuZD0iY2xvdWRzLmpwZyI+DQoN CjxwPjxmb250IHNpemU9IjQiPjxmb250IGNvbG9yPSIjODAwMDAwIj48Yj5U aGVyZSBhcmUgdGhyZWUgZGlmZmVyZW50IHR5cGVzIG9mDQoNCkhHSCBwcm9k dWN0cy48L2I+PC9mb250Pjxicj4NCg0KVGhlIGNvbmZ1c2lvbiBpcyB0aGF0 IGFsbCB0aHJlZSBhcmU8YnI+DQoNCmFkdmVydGlzZWQgYXMgaWYgdGhleSB3 ZXJlIHRoZSBzYW1lLjwvZm9udD48YnI+DQoNCiZuYnNwOzxicj4NCg0KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDx1PlRo ZSB0aHJlZSB0eXBlcyBhcmU6PC91Pjxicj4NCg0KJm5ic3A7PGJyPg0KDQo8 Yj4xKTwvYj4gLS0tIDxmb250IGNvbG9yPSIjMDAwMEZGIj48Yj5Ib21lb3Bh dGhpYyBIR0g8L2I+PC9mb250Pjxicj4NCg0KPGI+Mik8L2I+IC0tLSA8Zm9u dCBjb2xvcj0iIzAwMDBGRiI+PGI+UHJlLWN1cnNvciBIR0g8L2I+PC9mb250 Pjxicj4NCg0KPGI+Myk8L2I+IC0tLSA8Zm9udCBjb2xvcj0iIzAwMDBGRiI+ PGI+UmVhbCBvciBzeW50aGV0aWMgSEdIPC9iPjwvZm9udD4NCg0KKGRlbGl2 ZXJlZCBieSBpbmplY3Rpb248YnI+DQoNCiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvciwgYnkgYW4gb3JhbCBzcHJheSBt ZXRob2QpLjxicj4NCg0KJm5ic3A7PGJyPg0KDQpEbyB5b3Uga25vdyBkaWZm ZXJlbmNlcz88YnI+DQoNCiZuYnNwOzxicj4NCg0KQ2FsbCB1cyBhbmQgd2Un bGwgZXhwbGFpbiB0aGVtIHRvIHlvdS48YnI+DQoNCiZuYnNwOzxicj4NCg0K T3VyIHRvbGwgZnJlZSBudW1iZXIgaXMgPGZvbnQgY29sb3I9IiMwMDAwODAi PjxiPjEtODg4LTYyMS03MzAwPC9iPjwvZm9udD48YnI+DQoNCkFuIEhHSCBz dGFmZiBtZW1iZXIgaXMgYXZhaWxhYmxlPGJyPg0KDQo5IHRvIDUgUGFjaWZp YyBUaW1lLjxicj4NCg0KSWYgYWZ0ZXIgaG91cnMsIHBsZWFzZSBsZWF2ZSB5 b3UgbmFtZTxicj4NCg0KYW5kIGRheSBhbmQgZXZlbmluZyBwaG9uZSBudW1i ZXJzLjxicj4NCg0KV2Ugd2lsbCBjYWxsIHlvdSBiYWNrIGluIGEgbm8gcHJl c3N1cmUsPGJyPg0KDQplZHVjYXRpb25hbCBtYW5uZXIuPGJyPg0KDQpJZiB5 b3UgYXJlIG92ZXJzZWFzIGNhbGwgeW91ciBsb25nIGRpc3RhbmNlPGJyPg0K DQpvcGVyYXRvciBhbmQgYXNrIHRvIGJlIGNvbm5lY3RlZCB0byBvdXI8YnI+ DQoNCnBob25lIG51bWJlci4mbmJzcDsgV2Ugd2lsbCBjYWxsIHlvdSBiYWNr IHNvPGJyPg0KDQp3ZSBjYW4gcGF5IGZvciB0aGUgbG9uZyBkaXN0YW5jZSBj aGFyZ2VzLjxicj4NCg0KJm5ic3A7PGJyPg0KDQo8Zm9udCBjb2xvcj0iI0ZG MDAwMCI+Rm9yIG1vcmUgaW5mb3JtYXRpb24gb24gSEdIIHJlYWQgb24uLi4u Li4uLi4uLi48L2ZvbnQ+PGJyPg0KDQombmJzcDs8YnI+DQoNCkhBVkUgWU9V IEhFQVJEIE9GPGJyPg0KDQpIVU1BTiBHUk9XVEggSE9STU9ORSAoSEdIKT8/ Pzxicj4NCg0KJm5ic3A7PGJyPg0KDQombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgUmVsZWFzZWQgYnkgeW91ciBvd24gcGl0dWl0YXJ5IGdsYW5kLCBIR0gg c3RhcnRzDQoNCmRlY2xpbmluZzxicj4NCg0KaW4geW91ciAyMHMsIGV2ZW4g bW9yZSBpbiB5b3VyIDMwcyBhbmQgNDBzLCBldmVudHVhbGx5IHJlc3VsdGlu Zzxicj4NCg0KaW4gdGhlIHNocmlua2FnZSBvZiBtYWpvciBvcmdhbnMgLS0g cGx1cywgYWxsPGJyPg0KDQpvdGhlciBzeW1wdG9tcyByZWxhdGVkIHRvIG9s ZCBhZ2UuPGJyPg0KDQombmJzcDs8YnI+DQoNCiZuYnNwOzxicj4NCg0KSU4g VEhPVVNBTkRTIE9GIENMSU5JQ0FMIFNUVURJRVMsPGJyPg0KDQpIR0ggSEFT IEJFRU4gU0hPV04gVE8gQUNDT01QTElTSCBUSEUgRk9MTE9XSU5HOjxicj4N Cg0KJm5ic3A7PGJyPg0KDQoqIFJlZHVjZSBCb2R5IEZhdCBhbmQgQnVpbGQg TGVhbiBNdXNjbGU8YnI+DQoNCiZuYnNwOyZuYnNwOyBXSVRIT1VUIEVYRVJD SVNFITxicj4NCg0KJm5ic3A7PGJyPg0KDQoqIEVuaGFuY2UgU2V4dWFsIFBl cmZvcm1hbmNlPGJyPg0KDQombmJzcDs8YnI+DQoNCiogUmVtb3ZlIFdyaW5r bGVzIGFuZCBDZWxsdWxpdGU8YnI+DQoNCiZuYnNwOzxicj4NCg0KKiBMb3dl ciBCbG9vZCBQcmVzc3VyZSBhbmQgSW1wcm92ZSBDaG9sZXN0ZXJvbCBQcm9m aWxlPGJyPg0KDQombmJzcDs8YnI+DQoNCiogSW1wcm92ZSBTbGVlcCwgVmlz aW9uIGFuZCBNZW1vcnk8YnI+DQoNCiZuYnNwOzxicj4NCg0KKiBSZXN0b3Jl IEhhaXIgQ29sb3IgYW5kIEdyb3d0aDxicj4NCg0KJm5ic3A7PGJyPg0KDQoq IFN0cmVuZ3RoZW4gdGhlIEltbXVuZSBTeXN0ZW08YnI+DQoNCiZuYnNwOzxi cj4NCg0KKiBJbmNyZWFzZSBFbmVyZ3kgYW5kIENhcmRpYWMgT3V0cHV0PGJy Pg0KDQombmJzcDs8YnI+DQoNCiogVHVybiBiYWNrIHlvdXIgYm9keSdzIEJp b2xvZ2ljYWwgVGltZSBDbG9jayAxMCAtIDIwIHllYXJzPGJyPg0KDQombmJz cDs8YnI+DQoNCiogTGl2ZSBMb25nZXIgQU5EIFN0cm9uZ2VyPGJyPg0KDQom bmJzcDs8YnI+DQoNCkFsbCBuYXR1cmFsIGFuZCBvcmdhbmljIHBsYW50IGJh c2VkPGJyPg0KDQombmJzcDs8YnI+DQoNCjxmb250IGNvbG9yPSIjMDAwMEZG Ij48Yj5GRUVMIDEwIFlFQVJTIFlPVU5HRVIgV0lUSCBPUkFMIFNQUkFZIEhH SC48YnI+DQoNCkdVQVJBTlRFRUQ8L2I+PC9mb250Pjxicj4NCg0KJm5ic3A7 PGJyPg0KDQombmJzcDsmbmJzcDsmbmJzcDsgV2UgYXJlIHRoZSBtYW51ZmFj dHVyZXIgYW5kIHdlIHNlbGwgZGlyZWN0bHkgdG8gRG9jdG9ycyw8YnI+DQoN CkNoaXJvcHJhY3RvcnMsIGFuZCBjb25zdW1lcnMgd29ybGQgd2lkZSB0aGUg aGlnaGVzdCBncmFkZTxicj4NCg0KJm5ic3A7SEdIIE9yYWwgU3ByYXkgYXZh aWxhYmxlLiZuYnNwOzxicj4NCg0KJm5ic3A7PGJyPg0KDQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgV2l0aCBpbnRlcm5ldCBtYXJrZXRpbmcsIHdlIGFy ZSBhYmxlIHRvIHNhdmUNCg0KYWR2ZXJ0aXNpbmc8YnI+DQoNCmNvc3QgYW5k IHBhc3MgdGhvc2Ugc2F2aW5ncyBhbG9uZyB0byB5b3UuPGJyPg0KDQpCdXQg eW91IG11c3QgYWN0IG5vdy4mbmJzcDs8YnI+DQoNCiZuYnNwOzxicj4NCg0K VG8gcmVjZWl2ZSBtb3JlIGluZm9ybWF0aW9uIGNhbGwmbmJzcDsgdXMgbm93 Ljxicj4NCg0KJm5ic3A7PGJyPg0KDQombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg VE9MTCBGUkVFIDxiPjxmb250IGNvbG9yPSIjMDAwMDgwIj4xLTg4OC02MjEt NzMwMDwvZm9udD48L2I+PGJyPg0KDQombmJzcDs8YnI+DQoNCldlIG11c3Qg c3BlYWsgdG8geW91IGluIHBlcnNvbiB0byBxdWFsaWZ5IHlvdXIgdXNhZ2Uu PGJyPg0KDQombmJzcDs8YnI+DQoNCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBBbGwgb2YgeW91ciBxdWVzdGlvbnMgd2lsbCBiZSBhZGRyZXNzZWQgYW5k IGFuc3dlcmVkIGluDQoNCmEgZnJpZW5kbHksPGJyPg0KDQpubyBwcmVzc3Vy ZSBtYW5uZXIuJm5ic3A7IE91ciBtYWluIHB1cnBvc2UgaXMgdG8gcHJvdmlk ZSB5b3Ugd2l0aDxicj4NCg0KJm5ic3A7aW5mb3JtYXRpb24gc28geW91IGNh biBtYWtlIGFuIGVkdWNhdGVkIGRlY2lzaW9uLjxicj4NCg0KJm5ic3A7PGJy Pg0KDQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRm9yIG1vcmUgaW5mb3Jt YXRpb24gY2FsbDxicj4NCg0KJm5ic3A7PGJyPg0KDQombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPGI+PGZvbnQgY29sb3I9IiMwMDAwODAiPjEtODg4LTYyMS03 MzAwPC9mb250PjwvYj48YnI+DQoNCiZuYnNwOzxicj4NCg0KJm5ic3A7SWYg eW91IGFyZSBvbiBsaW5lIHdyaXRlIGRvd24gb3VyPGJyPg0KDQpwaG9uZSBu dW1iZXIgYW5kIGNhbGwgdXMgd2hlbiB5b3UgY2FuLjxicj4NCg0KJm5ic3A7 PGJyPg0KDQpTb29uLCB5b3UgYW5kIHlvdXIgbG92ZWQgb25lcyB3aWxsIGJl IHZlcnkgZ2xhZCB5b3UgZGlkLjxicj4NCg0KJm5ic3A7PGJyPg0KDQpSZWFk IHdoYXQgcGVvcGxlIGFyZSBzYXlpbmc6PGJyPg0KDQombmJzcDs8YnI+DQoN CiZxdW90O1RoZSBlZmZlY3RzIG9mIDYgbW9udGhzIG9mIEdIIG9uPGJyPg0K DQpsZWFuIGJvZHkgbWFzcyBhbmQgZmF0IHdlcmUgZXF1aXZhbGVudDxicj4N Cg0KaW4gbWFnbml0dWRlIHRvIHRoZSBjaGFuZ2VzIGluY3VycmVkPGJyPg0K DQpkdXJpbmcgMTAtMjAgeWVhcnMgb2YgYWdpbmcuJnF1b3Q7PGJyPg0KDQpE ci4gRGFuaWVsIFJ1ZG1hbiwgTUQsPGJyPg0KDQpOZXcgRW5nbGFuZCBKb3Vy bmFsIG9mIE1lZGljaW5lLjxicj4NCg0KJm5ic3A7PGJyPg0KDQomcXVvdDtX aXRoaW4gZm91ciBtb250aHMsIG15IGJvZHkgZmF0IGRlY3JlYXNlZDxicj4N Cg0KJm5ic3A7Zm9ybSAzMCUgZG93biB0byAyMSUhIEkgbm90aWNlZCBteSBz a2luPGJyPg0KDQombmJzcDtpcyBtb3JlIHN1cHBsZSBhbmQgbXkgb3ZlcmFs bCBtZW50YWw8YnI+DQoNCiZuYnNwO291dGxvb2sgaW1wcm92ZWQgc2lnbmlm aWNhbnRseS4mcXVvdDs8YnI+DQoNCiZuYnNwO0QuVy4sIE5ldyBKZXJzZXk8 YnI+DQoNCiZuYnNwOzxicj4NCg0KJnF1b3Q7V2UgaGF2ZSBiZWVuIG9uIHRo ZSBzcHJheSBmb3IganVzdCAzIHdlZWtzPGJyPg0KDQpub3csIGFuZCBiZXNp ZGVzIHRoZSB0cmVtZW5kb3VzIGVuZXJneSB3ZTxicj4NCg0KYm90aCBmZWVs LCBteSBodXNiYW5kcyBhbGxlcmdpZXMgYW5kIHNwZWxsczxicj4NCg0Kb2Yg ZGVwcmVzc2lvbiBoYXZlIGxpZnRlZC4gSSBhbSBoZWFsaW5nPGJyPg0KDQpl eHRyZW1lbHkgZmFzdCBhZnRlciBhbiBhY2NpZGVudCBhbmQgaGF2ZTxicj4N Cg0KbG9zdCA3IGxicy4gd2l0aG91dCB0cnlpbmchJnF1b3Q7PGJyPg0KDQpD LkIuLCBGbGFnc3RhZmYuIEFaPGJyPg0KDQombmJzcDs8YnI+DQoNClRoYW5r cyBmb3IgcmVhZGluZyBvdXIgbGV0dGVyLDxicj4NCg0KVGhlIEhHSCBTdGFm Zjxicj4NCg0KVVNBIERpdmlzaW9uPGJyPg0KDQombmJzcDs8YnI+DQoNClBT OiZuYnNwOyBUaGUgSEdIIFN0YWZmIGd1YXJhbnRlZXMgdGhlPGJyPg0KDQpo aWdoZXN0IHF1YWxpdHkgYW5kIGxvd2VzdCBwcmljZS48YnI+DQoNCiZuYnNw Ozxicj4NCg0KJm5ic3A7V2UgbWFudWZhY3R1cmUgYW5kIHNoaXAgZGlyZWN0 bHkgdG8geW91ciBkb29yLjxicj4NCg0KJm5ic3A7PGJyPg0KDQpDYWxsIHVz IG5vdyA8Yj48Zm9udCBjb2xvcj0iIzAwMDA4MCI+MS04ODgtNjIxLTczMDA8 L2ZvbnQ+PC9iPjxicj4NCg0KJm5ic3A7PGJyPg0KDQo9PT09PT09Jm5ic3A7 Jm5ic3A7IEVuZCBvZiBtZXNzYWdlID09PT09PT09Jm5ic3A7PGJyPg0KDQom bmJzcDs8YnI+DQoNCiZuYnNwOyZuYnNwOyBUaGUgZm9sbG93aW5nIHN0YXRl bWVudCBpcyBwcm92aWRlZCB0byBiZTxicj4NCg0KaW4gY29tcGxpYW5jZSB3 aXRoIGNvbW1lcmNpYWwgZW1haWwgbGF3cy48YnI+DQoNCiZuYnNwOzxicj4N Cg0KJm5ic3A7Jm5ic3A7IElmIHlvdSBkbyBub3Qgd2lzaCB0byByZWNlaXZl IGZ1cnRoZXI8YnI+DQoNCm1haWxpbmdzLCBwbGVhc2UgY2xpY2sgcmVwbHkg dG86ICB0aGVfaGdoX2NsaW5pY0BidGFtYWlsLm5ldC5jbiAgYW5kIHR5cGUg cmVtb3ZlIGluIHRoZSBzdWJqZWN0IGJveC48YnI+DQoNClRoZW4gY2xpY2sg c2VuZC48YnI+DQoNCiZuYnNwOzxicj4NCg0KJm5ic3A7Jm5ic3A7IFRoaXMg bWVzc2FnZSBpcyBpbiBmdWxsIGNvbXBsaWFuY2Ugd2l0aDxicj4NCg0KVS5T LiBGZWRlcmFsIHJlcXVpcmVtZW50cyBmb3IgY29tbWVyY2lhbDxicj4NCg0K ZW1haWwgdW5kZXIgYmlsbCBTLjE2MTggVGl0bGUgbGxsLCBTZWN0aW9uIDMw MSw8YnI+DQoNClBhcmFncmFwaCAoYSkoMikoQykgcGFzc2VkIGJ5IHRoZSAx MDV0aCBVLlMuPGJyPg0KDQpDb25ncmVzcyBhbmQgaXMgbm90IGNvbnNpZGVy ZWQgU1BBTTxicj4NCg0Kc2luY2UgaXQgaW5jbHVkZXMgYSByZW1vdmUgbWVj aGFuaXNtLio8YnI+DQoNClRoaXMgbWVzc2FnZSBpcyBub3QgaW50ZW5kZWQg Zm9yIHJlc2lkZW50cyBpbiB0aGU8YnI+DQoNCnN0YXRlcyBvZiBDQSwgTkMs IE5WLCBSSSwgVE4sIFZBICZhbXA7IFdBLjxicj4NCg0KU2NyZWVuaW5nIG9m IGFkZHJlc3NlcyBoYXMgYmVlbiBkb25lIHRvIHRoZSBiZXN0PGJyPg0KDQpv ZiBvdXIgdGVjaG5pY2FsIGFiaWxpdHkuPGJyPg0KDQombmJzcDs8YnI+DQoN CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDYWxsIHVzDQoNCm5vdyA8 Yj48Zm9udCBjb2xvcj0iIzAwMDA4MCI+MS04ODgtNjIxLTczMDA8L2ZvbnQ+ PC9iPiBmb3IgeW91cjxicj4NCg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGZyZWUNCg0KSEdIIGNvbnN1bHRhdGlvbi48L3A+DQoNCjxwPjxicj4N Cg0KVGhhbmsgeW91PC9wPg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NCg0KIA0K IA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0K IA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0K IA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KDQot LQ0KDQo3NTg0bkJ3ZjItNjU3REd0VzYwMTRxQkd4My0yNjJ6bDI5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 7:59:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9407F37B4B6 for ; Thu, 11 Jul 2002 07:59:41 -0700 (PDT) Received: from smtp.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id B306143E42 for ; Thu, 11 Jul 2002 07:59:40 -0700 (PDT) (envelope-from jrh@it.uc3m.es) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id C45034313E for ; Thu, 11 Jul 2002 16:59:39 +0200 (CEST) Received: from it.uc3m.es (alacran.it.uc3m.es [163.117.140.44]) by smtp02.uc3m.es (Postfix) with ESMTP id B849199EF8 for ; Thu, 11 Jul 2002 16:59:39 +0200 (CEST) Message-ID: <3D2D9D4E.74A1B6F4@it.uc3m.es> Date: Thu, 11 Jul 2002 16:59:26 +0200 From: Juan Francisco Rodriguez Hervella X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: sysctl inferface question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello: I'm very confused with the sysctl internals. For example, looking at the kernel source code of FreeBSD, I've realized of the following: netinet/in_proco.c: SYSCTL_NODE(_net_inet6, IPPROTO_DIVERT, divert, CTLFLAG_RW, 0, "DIVERT"); netinet/ip_divert.c: SYSCTL_DECL(_net_inet_divert); netinet/ip_divert.c: SYSCTL_PROC(_net_inet_divert, OID_AUTO, pcblist, CTLFLAG_RD, 0, 0, div_pcblist, "S,xinpcb", "List of active divert sockets"); Isn't this redundant ? I mean, if there is a "SYSCTL_NODE", there is *no* need for having "SYSCTL_DECL" in "ip_divert.c"... I am wrong ? Also, I don't undertand the meaning of the "fmt" field....what is it for ? What's the meaning of "S,xinpcb" in the above example ? Thanks. -- JFRH. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 8:24:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67E7837B400; Thu, 11 Jul 2002 08:24:33 -0700 (PDT) Received: from bugs.elitsat.net (bugs.elitsat.net [213.208.10.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB07843E5E; Thu, 11 Jul 2002 08:24:30 -0700 (PDT) (envelope-from amour@bugs.elitsat.net) Received: from bugs.elitsat.net (amour@localhost.elitsat.net [127.0.0.1]) by bugs.elitsat.net (8.12.3/8.12.3) with ESMTP id g6BFONpi068356; Thu, 11 Jul 2002 18:24:23 +0300 (EEST) (envelope-from amour@bugs.elitsat.net) Received: from localhost (amour@localhost) by bugs.elitsat.net (8.12.3/8.12.3/Submit) with ESMTP id g6BFOK8f068353; Thu, 11 Jul 2002 18:24:22 +0300 (EEST) Date: Thu, 11 Jul 2002 18:24:20 +0300 (EEST) From: Alexander To: freebsd-isp@freebsd.org Cc: freebsd-net@freebsd.org Subject: QUICK-R Message-ID: <20020711182027.I68345-100000@bugs.elitsat.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, I was looking for program that have lots of features about controlling my clients ppp accounts. So far I've got this QUICK-R (for those of you who don't know it, check: http://www.q-linux.com/software/quick-r/). I was wondering if there is something like this but made for BSD, or at least it is included in ports or packages. thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 10:56:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 494A037B400 for ; Thu, 11 Jul 2002 10:56:35 -0700 (PDT) Received: from kronos.networkrichmond.com (kronos.networkrichmond.com [64.240.180.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7043443E5E for ; Thu, 11 Jul 2002 10:56:34 -0700 (PDT) (envelope-from kbyanc@posi.net) X-Provider: NetworkRichmond, Inc. http://www.networkrichmond.com/ Received: from localhost (kbyanc@localhost) by kronos.networkrichmond.com (8.9.3/8.9.3/antispam) with ESMTP id NAA34575; Thu, 11 Jul 2002 13:56:28 -0400 (EDT) Date: Thu, 11 Jul 2002 13:56:28 -0400 (EDT) From: Kelly Yancey X-Sender: kbyanc@kronos.networkrichmond.com To: Juan Francisco Rodriguez Hervella Cc: freebsd-net@FreeBSD.ORG Subject: Re: sysctl inferface question In-Reply-To: <3D2D9D4E.74A1B6F4@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 11 Jul 2002, Juan Francisco Rodriguez Hervella wrote: > Hello: > > I'm very confused with the sysctl internals. > > For example, looking at the kernel source code of FreeBSD, I've realized > > of the following: > > netinet/in_proco.c: > SYSCTL_NODE(_net_inet6, IPPROTO_DIVERT, divert, > CTLFLAG_RW, 0, "DIVERT"); > netinet/ip_divert.c: > SYSCTL_DECL(_net_inet_divert); > netinet/ip_divert.c: > SYSCTL_PROC(_net_inet_divert, OID_AUTO, pcblist, CTLFLAG_RD, > 0, 0, > div_pcblist, "S,xinpcb", "List of active divert sockets"); > > Isn't this redundant ? I mean, if there is a "SYSCTL_NODE", there is > *no* need for having > "SYSCTL_DECL" in "ip_divert.c"... I am wrong ? > It is a scoping/linking issue: the SYSCTL_DECL is needed in netinet/ip_divert.c so that children may be added to the node which was defined in netinet/in_proto.c. Without it, the very next line in netinet/ip_divert would fail to compile because it coulding find the parent node. A good C reference would probably better explain the difference between declaring a variable and defining a variable, but that is exactly the difference you are witnessing here. > Also, I don't undertand the meaning of the "fmt" field....what is it for > ? What's the > meaning of "S,xinpcb" in the above example ? > > Thanks. > > -- > JFRH. > The fmt field is used by sysctl(8) to format the data returned from the kernel. The "S,xinpcb" format string tells sysctl(8) to use it's definition of "xinpcb" formatting to render the structure. Take a look at /usr/src/sbin/sysctl/sysctl.c; it is a pretty light read. Good luck, Kelly -- Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 11: 7:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39BBE37B400 for ; Thu, 11 Jul 2002 11:07:40 -0700 (PDT) Received: from TheWorld.com (pcls2.std.com [199.172.62.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7504743E31 for ; Thu, 11 Jul 2002 11:07:39 -0700 (PDT) (envelope-from cambria@world.std.com) Received: from world.std.com (dp@world-f.std.com [199.172.62.5]) by TheWorld.com (8.9.3/8.9.3) with ESMTP id OAA15364 for ; Thu, 11 Jul 2002 14:07:37 -0400 Received: (from cambria@localhost) by world.std.com (8.9.3/8.9.3) id OAA09735 for net@freebsd.org; Thu, 11 Jul 2002 14:07:36 -0400 (EDT) Date: Thu, 11 Jul 2002 14:07:36 -0400 (EDT) From: Michael C Cambria Message-Id: <200207111807.OAA09735@world.std.com> To: net@freebsd.org Subject: xl checksum and dsniff Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I've been using dsniff on 4.6-Stable (and earlier) for a while. I've setup a faster machine to run this in the lab. This machine however has an built-in xl interface. Things don't work. The 'old' machine on the same hub works just fine. Its using vx0. My guess is that doing hw checksum by the nic could be the issue. This is the only real difference I can see at present. Any ideas? Thanks, MikeC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 11:32:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB81437B400 for ; Thu, 11 Jul 2002 11:32:14 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AC3E43E42 for ; Thu, 11 Jul 2002 11:32:14 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id OAA23457; Thu, 11 Jul 2002 14:32:13 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g6BIVhH41348; Thu, 11 Jul 2002 14:31:43 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15661.53007.18632.609465@grasshopper.cs.duke.edu> Date: Thu, 11 Jul 2002 14:31:43 -0400 (EDT) To: Alfred Perlstein Cc: net@freebsd.org Subject: Re: the incredible shrinking socket In-Reply-To: <20020707083710.GM97638@elvis.mu.org> References: <20020707083710.GM97638@elvis.mu.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Alfred Perlstein writes: > Some time ago I noticed that there appeared to be several members > of struct socket that were either only used by listen sockets or > only used by data sockets. > > I've taken a stab at unionizing the members and we wind up saving > 28 bytes per socket on i386, and probably nearly double that on > any 64 bit platform. That's ~15%, which isn't too shabby. > Speaking of 64-bit platforms: While you are shrinking sockets, can you change the longs in struct sockbuf into ints? I see no reason to use 64-bit longs for those fields. That should dramatically shrink a socket on 64-bit platforms. Thanks, Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 11:37: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0289937B401 for ; Thu, 11 Jul 2002 11:37:07 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A44F43E42 for ; Thu, 11 Jul 2002 11:37:06 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id OAA23648; Thu, 11 Jul 2002 14:37:03 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g6BIaXs41355; Thu, 11 Jul 2002 14:36:33 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15661.53297.357488.144624@grasshopper.cs.duke.edu> Date: Thu, 11 Jul 2002 14:36:33 -0400 (EDT) To: Mike Silbersack Cc: Alfred Perlstein , Jonathan Lemon , Subject: Re: the incredible shrinking socket In-Reply-To: <20020708115539.D18260-100000@patrocles.silby.com> References: <20020708013907.J15265-100000@patrocles.silby.com> <20020708115539.D18260-100000@patrocles.silby.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Mike Silbersack writes: > > Speaking of competition, someone should go look at this: > > http://mail-index.netbsd.org/current-users/2002/07/03/0011.html > Its very worthwhile. Tru64 has had this for years. I think there may be a Jeff Mogul paper on it somewhere (but I don't have time to look for it). I'd be very much in favor of somebody porting this over in time for 5.0. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 11:43:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB23837B400 for ; Thu, 11 Jul 2002 11:43:50 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1C7743E58 for ; Thu, 11 Jul 2002 11:43:50 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 7E694AE03F; Thu, 11 Jul 2002 11:43:50 -0700 (PDT) Date: Thu, 11 Jul 2002 11:43:50 -0700 From: Alfred Perlstein To: Andrew Gallatin Cc: net@freebsd.org Subject: Re: the incredible shrinking socket Message-ID: <20020711184350.GY97638@elvis.mu.org> References: <20020707083710.GM97638@elvis.mu.org> <15661.53007.18632.609465@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15661.53007.18632.609465@grasshopper.cs.duke.edu> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Andrew Gallatin [020711 11:32] wrote: > > Alfred Perlstein writes: > > Some time ago I noticed that there appeared to be several members > > of struct socket that were either only used by listen sockets or > > only used by data sockets. > > > > I've taken a stab at unionizing the members and we wind up saving > > 28 bytes per socket on i386, and probably nearly double that on > > any 64 bit platform. That's ~15%, which isn't too shabby. > > > > Speaking of 64-bit platforms: While you are shrinking sockets, can > you change the longs in struct sockbuf into ints? I see no reason > to use 64-bit longs for those fields. That should dramatically shrink > a socket on 64-bit platforms. Wollman pointed out that I can't do what I wanted to because of self-connecting sockets. However you should feel free to commit that change yourself. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 11:51:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45BB737B400 for ; Thu, 11 Jul 2002 11:51:45 -0700 (PDT) Received: from ra.upan.org (ra.upan.org [204.107.76.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8937B43E31 for ; Thu, 11 Jul 2002 11:51:43 -0700 (PDT) (envelope-from mikel@ocsinternet.com) Received: from ocsinternet.com ([10.0.0.140]) by ra.upan.org (8.12.3/8.11.6) with ESMTP id g6BIpgqj046221; Thu, 11 Jul 2002 14:51:42 -0400 (EDT) (envelope-from mikel@ocsinternet.com) Message-ID: <3D2DD3BB.2010506@ocsinternet.com> Date: Thu, 11 Jul 2002 13:51:39 -0500 From: Mikel King User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nascar24 Cc: net@FreeBSD.ORG Subject: Re: DHCP lease renewal References: <01c001c221dd$38127d20$0200a8c0@winxp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Not sure if you've found this already. One thing I used to do on an older box was a simple cron job that ran a script which HUP'd the dhclient every so often thus effectively renewing the lease... If memory serves me it went something like.... #!/bin/sh kill -HUP `ps ax |awk '/dhclient/{print $1; exit}'` cheers, mikel nascar24 wrote: > Hallo, > > My FreeBSD 4.5-RELEASE machine is connected to the internet via a > cable connection. And when booting (or running dhclient) I get an IP > address. But when I have an IP address and my ISP wants to give me a > new IP address I doesn't go the way it should. Because I don't get the > new IP address, my machine continues to use the 'old' IP address. And > when that happens I get an angry phone call from my ISP, and they shut > me from internet for a day. > > So, how can I configure (dhclient.conf I guess) my machine so that it > accepts this new IP address. I thought I would configure my machine so > that it renews its lease every 10 hours. But I have read the man for > dhclient.conf, dhcp-options and dhclient but I still am puzzled. > > Gr. > > Marcel. > -- Cheers, Mikel +------------------------------------------+ Ok I'll go fsck my brain for a while as it's been a rather long night. +------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 13:17:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D912F37B401 for ; Thu, 11 Jul 2002 13:17:37 -0700 (PDT) Received: from prism.flugsvamp.com (66-191-112-47.mad.wi.charter.com [66.191.112.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F9D043E4A for ; Thu, 11 Jul 2002 13:17:37 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.6/8.11.6) id g6BKFwe70305; Thu, 11 Jul 2002 15:15:58 -0500 (CDT) (envelope-from jlemon) Date: Thu, 11 Jul 2002 15:15:58 -0500 (CDT) From: Jonathan Lemon Message-Id: <200207112015.g6BKFwe70305@prism.flugsvamp.com> To: cambria@world.std.com, net@freebsd.org Subject: Re: xl checksum and dsniff X-Newsgroups: local.mail.freebsd-net In-Reply-To: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article you write: > >Hi, > >I've been using dsniff on 4.6-Stable (and earlier) for a while. I've setup >a faster machine to run this in the lab. This machine however has an >built-in xl interface. Things don't work. > >The 'old' machine on the same hub works just fine. Its using vx0. > >My guess is that doing hw checksum by the nic could be the issue. This is >the only real difference I can see at present. > >Any ideas? Test your theory. Turn off hardware checksums with 'ifconfig xl0 -txcsum' -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 13:20:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF3AD37B400 for ; Thu, 11 Jul 2002 13:20:48 -0700 (PDT) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 105B643E09 for ; Thu, 11 Jul 2002 13:20:48 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g6BKKQa18732 for freebsd-net@freebsd.org; Thu, 11 Jul 2002 16:20:26 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Thu, 11 Jul 2002 16:20:26 -0400 From: Bosko Milekic To: freebsd-net@freebsd.org Subject: mbuf external buffer reference counters Message-ID: <20020711162026.A18717@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, Right now, in -CURRENT, there is this hack that I introduced that basically just allocates a ref. counter for external buffers attached to mbufs with malloc(9). What this means is that if you do something like allocate an mbuf and then a cluster, there's a malloc() call that is made to allocate a small (usually 4-byte) reference counter for it. That sucks, and even -STABLE doesn't do this. I changed it this way a long time ago for simplicity's sake and since then I've been meaning to do something better here. The idea was, for mbuf CLUSTERS, to stash the counter at the end of the 2K buffer area, and to make MCLBYTES = 2048 - sizeof(refcount), which should be more than enough, theoretically, for all cluster users. This is by far the easiest solution (I had it implemented about 10 months ago) and it worked great. The purpose of this Email is to find out if anyone has concrete information on why this wouldn't work (if they think it wouldn't). So, if someone has an example of some broken code somewhere that wouldn't like this, please point it out to me now before I go off and do this again and commit it. Thanks, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 13:35:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 465C637B400 for ; Thu, 11 Jul 2002 13:35:53 -0700 (PDT) Received: from patrocles.silby.com (d185.as6.nwbl0.wi.voyager.net [169.207.130.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9027643E52 for ; Thu, 11 Jul 2002 13:35:51 -0700 (PDT) (envelope-from silby@silby.com) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.4/8.12.4) with ESMTP id g6BKdZcv033122; Thu, 11 Jul 2002 15:39:35 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.4/8.12.4/Submit) with ESMTP id g6BKdW3r033119; Thu, 11 Jul 2002 15:39:33 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Thu, 11 Jul 2002 15:39:32 -0500 (CDT) From: Mike Silbersack To: Alex Dyas Cc: net@freebsd.org Subject: Re: BSD / Firewall / 0 window size problem In-Reply-To: Message-ID: <20020711153621.O33106-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 11 Jul 2002, Alex Dyas wrote: > The only clue I've managed to find as to what is going on is in a tcpdump of > the session (attached). The trigger for the lock up seems to be a messages > from the Otherbox machine setting the window size to 0 : > > 10:41:38.614141 otherbox.foo.com.telnet > bsdbox.foo.com.2230: . ack 154 win > 0 > 10:41:38.614200 bsdbox.foo.com.2230 > otherbox.foo.com.telnet: . ack 337 win > 33304 (DF) [tos 0x10] > > I've tried all the following scenarios, none of which exhibit the same > problem, which is why I think the problem is with FreeBSD : > > bsdbox.foo.com -> otherbox.foo.com > solarisbox.foo.com -> internal GNAT firewall -> otherbox.foo.com > windowsbox.foo.com -> internal GNAT firewall -> otherbox.foo.com > linuxbox.foo.com -> internal GNAT firewall -> otherbox.foo.com Could you post a tcpdump of one of the successful connections so that we can see how 0 windows are handled there? Also, have you tcpdump'd at both ends to ensure that we're not actually seeing odd sideeffects of packet loss or something? (Some reported problems in the past have been due to misbehaving duplex autodetect and bad cables.) Offhand, I can't see what the FreeBSD box is doing wrong, but I'd like something else to compare to. Thanks, Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 13:38:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B31F937B400 for ; Thu, 11 Jul 2002 13:38:07 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6828643E31 for ; Thu, 11 Jul 2002 13:38:07 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g6BKc3Z32341; Thu, 11 Jul 2002 13:38:03 -0700 (PDT) (envelope-from rizzo) Date: Thu, 11 Jul 2002 13:38:02 -0700 From: Luigi Rizzo To: Bosko Milekic Cc: freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters Message-ID: <20020711133802.A31827@iguana.icir.org> References: <20020711162026.A18717@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020711162026.A18717@unixdaemons.com>; from bmilekic@unixdaemons.com on Thu, Jul 11, 2002 at 04:20:26PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, certainly removing the malloc will improve performance a lot. As I already mentioned to Bosko, in principle the available area in ext.buffers is irrelevant, and i do not believe this will break anything (and if it does, it will be easy to fix in the kernel), but some applications might decide to do writes in multiple of 1K and trimming away the refcount area might easily result in suboptimal allocation of storage within the kernel. I'd probably try to use the same technique as -stable (i.e. have a separate array for all refcounts), if that is not too bad from other points of view. cheers luigi On Thu, Jul 11, 2002 at 04:20:26PM -0400, Bosko Milekic wrote: > > Hi, > > Right now, in -CURRENT, there is this hack that I introduced that > basically just allocates a ref. counter for external buffers attached > to mbufs with malloc(9). What this means is that if you do something > like allocate an mbuf and then a cluster, there's a malloc() call that > is made to allocate a small (usually 4-byte) reference counter for it. > > That sucks, and even -STABLE doesn't do this. I changed it this way > a long time ago for simplicity's sake and since then I've been meaning > to do something better here. The idea was, for mbuf CLUSTERS, to > stash the counter at the end of the 2K buffer area, and to make > MCLBYTES = 2048 - sizeof(refcount), which should be more than enough, > theoretically, for all cluster users. This is by far the easiest > solution (I had it implemented about 10 months ago) and it worked > great. > > The purpose of this Email is to find out if anyone has concrete > information on why this wouldn't work (if they think it wouldn't). > So, if someone has an example of some broken code somewhere that > wouldn't like this, please point it out to me now before I go off and > do this again and commit it. > > Thanks, > -- > Bosko Milekic > bmilekic@unixdaemons.com > bmilekic@FreeBSD.org > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 13:42:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BADB337B400 for ; Thu, 11 Jul 2002 13:42:47 -0700 (PDT) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A09F43E3B for ; Thu, 11 Jul 2002 13:42:47 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g6BKgPg18878; Thu, 11 Jul 2002 16:42:25 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Thu, 11 Jul 2002 16:42:25 -0400 From: Bosko Milekic To: Luigi Rizzo Cc: freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters Message-ID: <20020711164225.A18852@unixdaemons.com> References: <20020711162026.A18717@unixdaemons.com> <20020711133802.A31827@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020711133802.A31827@iguana.icir.org>; from rizzo@icir.org on Thu, Jul 11, 2002 at 01:38:02PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Jul 11, 2002 at 01:38:02PM -0700, Luigi Rizzo wrote: > Hi, > > certainly removing the malloc will improve performance a lot. > > As I already mentioned to Bosko, in principle the available area > in ext.buffers is irrelevant, and i do not believe this will break > anything (and if it does, it will be easy to fix in the kernel), > but some applications might decide to do writes in multiple of 1K > and trimming away the refcount area might easily result in suboptimal > allocation of storage within the kernel. Can you elaborate on the sub-optimal performance comment with, perhaps, an example? I'm sorry but I'm sometimes slow to understand these days (lack of sleep). Just recently, I was wondering why a 10megabit card was being outperformed by a 100megabit card, where the first was plugged into a 10/100 dual speed hub. D'oh. :-( > I'd probably try to use the same technique as -stable (i.e. have > a separate array for all refcounts), if that is not too bad > from other points of view. The problem with this approach is that I'm probably going to be allocating jumbo bufs from the same map, in which case you would have huge `gaps' in your address <-> ref. count location map and, as a result, a lot of wastage. Plus the jumbo bufs will actually store the counter at the end of themselves, so it would be nice if clusters did the same. I don't mind either way, but it's the first reason that compells me to stash them at the end of the cluster. > cheers > luigi > > On Thu, Jul 11, 2002 at 04:20:26PM -0400, Bosko Milekic wrote: > > > > Hi, > > > > Right now, in -CURRENT, there is this hack that I introduced that > > basically just allocates a ref. counter for external buffers attached > > to mbufs with malloc(9). What this means is that if you do something > > like allocate an mbuf and then a cluster, there's a malloc() call that > > is made to allocate a small (usually 4-byte) reference counter for it. > > > > That sucks, and even -STABLE doesn't do this. I changed it this way > > a long time ago for simplicity's sake and since then I've been meaning > > to do something better here. The idea was, for mbuf CLUSTERS, to > > stash the counter at the end of the 2K buffer area, and to make > > MCLBYTES = 2048 - sizeof(refcount), which should be more than enough, > > theoretically, for all cluster users. This is by far the easiest > > solution (I had it implemented about 10 months ago) and it worked > > great. > > > > The purpose of this Email is to find out if anyone has concrete > > information on why this wouldn't work (if they think it wouldn't). > > So, if someone has an example of some broken code somewhere that > > wouldn't like this, please point it out to me now before I go off and > > do this again and commit it. > > > > Thanks, > > -- > > Bosko Milekic > > bmilekic@unixdaemons.com > > bmilekic@FreeBSD.org Thanks for your feedback. -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 13:56:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13C5737B400 for ; Thu, 11 Jul 2002 13:56:10 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BA4E43E5E for ; Thu, 11 Jul 2002 13:56:09 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g6BKu8532619; Thu, 11 Jul 2002 13:56:08 -0700 (PDT) (envelope-from rizzo) Date: Thu, 11 Jul 2002 13:56:08 -0700 From: Luigi Rizzo To: Bosko Milekic Cc: freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters Message-ID: <20020711135608.A32460@iguana.icir.org> References: <20020711162026.A18717@unixdaemons.com> <20020711133802.A31827@iguana.icir.org> <20020711164225.A18852@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020711164225.A18852@unixdaemons.com>; from bmilekic@unixdaemons.com on Thu, Jul 11, 2002 at 04:42:25PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Jul 11, 2002 at 04:42:25PM -0400, Bosko Milekic wrote: ... > > and trimming away the refcount area might easily result in suboptimal > > allocation of storage within the kernel. > > Can you elaborate on the sub-optimal performance comment with, > perhaps, an example? I'm sorry but I'm sometimes slow to understand example: userland does an 8KB write, in the old case this requires 4 clusters, with the new one you end up using 4 clusters and stuff the remaining 16 bytes in a regular mbuf, then depending on the relative producer-consumer speed the next write will try to fill the mbuf and attach a new cluster, and so on... and when TCP hits these data-in-mbuf blocks will have to copy rather than reference the data blocks... Maybe it is irrelevant for performance, maybe it is not, i am not sure. > The problem with this approach is that I'm probably going to be > allocating jumbo bufs from the same map, in which case you would have > huge `gaps' in your address <-> ref. count location map and, as a how huge ? and do you really need to use the same map rather than two different ones ? cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 14: 1: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B2CD37B400 for ; Thu, 11 Jul 2002 14:00:59 -0700 (PDT) Received: from smtp.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 804AE43E3B for ; Thu, 11 Jul 2002 14:00:58 -0700 (PDT) (envelope-from jrh@lab.it.uc3m.es) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 9874343142; Thu, 11 Jul 2002 23:00:57 +0200 (CEST) Received: from itserv2.lab.it.uc3m.es (itserv2.lab.it.uc3m.es [163.117.144.121]) by smtp01.uc3m.es (Postfix) with ESMTP id 33DC299E03; Thu, 11 Jul 2002 23:00:57 +0200 (CEST) Received: from lm011.lab.it.uc3m.es (root@lm011.lab.it.uc3m.es [163.117.144.140]) by itserv2.lab.it.uc3m.es (8.9.3/8.9.3) with ESMTP id XAA05748; Thu, 11 Jul 2002 23:00:57 +0200 Received: from localhost (jrh@localhost) by lm011.lab.it.uc3m.es (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id XAA22340; Thu, 11 Jul 2002 23:00:56 +0200 Date: Thu, 11 Jul 2002 23:00:56 +0200 (CEST) From: Juan Francisco Rodriguez Hervella To: Luigi Rizzo Cc: Bosko Milekic , freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters In-Reply-To: <20020711133802.A31827@iguana.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 11 Jul 2002, Luigi Rizzo wrote: > Hi, > > certainly removing the malloc will improve performance a lot. > > As I already mentioned to Bosko, in principle the available area > in ext.buffers is irrelevant, and i do not believe this will break > anything (and if it does, it will be easy to fix in the kernel), > but some applications might decide to do writes in multiple of 1K > and trimming away the refcount area might easily result in suboptimal > allocation of storage within the kernel. > First of all, let me say that Im newbie with these topics, I only know a bit about mbufs, but I dont understand how can an application trim away the refcount if the size is MCLBYTES = 2040 - sizeof(refcount). Don't this limit the room which an app. can write ? Thanks. JFRH > I'd probably try to use the same technique as -stable (i.e. have > a separate array for all refcounts), if that is not too bad > from other points of view. > > cheers > luigi > > On Thu, Jul 11, 2002 at 04:20:26PM -0400, Bosko Milekic wrote: > > > > Hi, > > > > Right now, in -CURRENT, there is this hack that I introduced that > > basically just allocates a ref. counter for external buffers attached > > to mbufs with malloc(9). What this means is that if you do something > > like allocate an mbuf and then a cluster, there's a malloc() call that > > is made to allocate a small (usually 4-byte) reference counter for it. > > > > That sucks, and even -STABLE doesn't do this. I changed it this way > > a long time ago for simplicity's sake and since then I've been meaning > > to do something better here. The idea was, for mbuf CLUSTERS, to > > stash the counter at the end of the 2K buffer area, and to make > > MCLBYTES = 2048 - sizeof(refcount), which should be more than enough, > > theoretically, for all cluster users. This is by far the easiest > > solution (I had it implemented about 10 months ago) and it worked > > great. > > > > The purpose of this Email is to find out if anyone has concrete > > information on why this wouldn't work (if they think it wouldn't). > > So, if someone has an example of some broken code somewhere that > > wouldn't like this, please point it out to me now before I go off and > > do this again and commit it. > > > > Thanks, > > -- > > Bosko Milekic > > bmilekic@unixdaemons.com > > bmilekic@FreeBSD.org > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 14:13:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E57737B400 for ; Thu, 11 Jul 2002 14:13:19 -0700 (PDT) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3161A43E09 for ; Thu, 11 Jul 2002 14:13:18 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g6BLCtC19034; Thu, 11 Jul 2002 17:12:55 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Thu, 11 Jul 2002 17:12:55 -0400 From: Bosko Milekic To: Luigi Rizzo Cc: freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters Message-ID: <20020711171255.A19014@unixdaemons.com> References: <20020711162026.A18717@unixdaemons.com> <20020711133802.A31827@iguana.icir.org> <20020711164225.A18852@unixdaemons.com> <20020711135608.A32460@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020711135608.A32460@iguana.icir.org>; from rizzo@icir.org on Thu, Jul 11, 2002 at 01:56:08PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Jul 11, 2002 at 01:56:08PM -0700, Luigi Rizzo wrote: > example: userland does an 8KB write, in the old case this requires > 4 clusters, with the new one you end up using 4 clusters and stuff > the remaining 16 bytes in a regular mbuf, then depending on the > relative producer-consumer speed the next write will try to fill > the mbuf and attach a new cluster, and so on... and when TCP hits > these data-in-mbuf blocks will have to copy rather than reference > the data blocks... > > Maybe it is irrelevant for performance, maybe it is not, > i am not sure. I see what you're saying. I think that what this means is simply that the `optimal' chunk of data to send is just a different size, so instead of it being 8192 bytes, it'll be something like 8180 bytes or something (to account for the counters). So, in other words, it really depends on the frequency of exact 8192 sized sends in userland applications. This is a good observation if we're going to be doing benchmarking, but I'm not sure whether the repercussions are that important (unless, as I said, there's a lot of applications that send exactly 8192 byte chunks?). Basically, what we're doing is shifting the optimal send size when using exactly 4 clusters, in this case, to (8192 - 16) bytes. We can still send with exactly 4 clusters, it's just that the optimal send size is a little different, that's all (this produces a small shift in block send benchmark curves, usually). > > The problem with this approach is that I'm probably going to be > > allocating jumbo bufs from the same map, in which case you would have > > huge `gaps' in your address <-> ref. count location map and, as a > > how huge ? and do you really need to use the same map rather than > two different ones ? Well, I can use a different map, I guess (I use a different map for mbufs in order to not let huge cluster allocations eat up all of the address space reserved for mbufs). However, it seems that jumbo bufs and clusters are logically equivalent (your driver will either use one or the other) so it would make sense to have them share the same `chunk' of address space. As for the gaps, they are quite huge. I think we calculated a week or so ago when discussing jumbo bufs that we would probably end up allocating them in chunks of 3 or 4 at a time. So that would mean at least ~9 page 'holes' in the address space from which clusters are allocated, so that would mean ~18 counters wasted, at least, for every hole. With the number of jumbo bufs we would have, that can really add up. > cheers > luigi > -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 14:15:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2A5A37B400 for ; Thu, 11 Jul 2002 14:15:34 -0700 (PDT) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FFC143E58 for ; Thu, 11 Jul 2002 14:15:34 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g6BLFAJ19065; Thu, 11 Jul 2002 17:15:10 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Thu, 11 Jul 2002 17:15:10 -0400 From: Bosko Milekic To: Juan Francisco Rodriguez Hervella Cc: freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters Message-ID: <20020711171510.A19053@unixdaemons.com> References: <20020711133802.A31827@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jrh@lab.it.uc3m.es on Thu, Jul 11, 2002 at 11:00:56PM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Jul 11, 2002 at 11:00:56PM +0200, Juan Francisco Rodriguez Hervella wrote: > First of all, let me say that Im newbie with these topics, > I only know a bit about mbufs, but I dont understand how > can an application trim away the refcount if the size is > MCLBYTES = 2040 - sizeof(refcount). > > Don't this limit the room which an app. can write ? No. It just changes it. Also, it's not the application trimming away anything, and the size is not 2040, it's 2048. :-) FWIW, the application has no idea about mbufs or clusters. These are buffers and structures only the kernel knows about. > Thanks. > > JFRH -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 15:29:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 324AA37B400 for ; Thu, 11 Jul 2002 15:29:48 -0700 (PDT) Received: from smtp.noos.fr (camus.noos.net [212.198.2.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3798C43E42 for ; Thu, 11 Jul 2002 15:29:47 -0700 (PDT) (envelope-from root@gits.dyndns.org) Received: (qmail 40196139 invoked by uid 0); 11 Jul 2002 22:29:45 -0000 Received: from unknown (HELO gits.gits.dyndns.org) ([212.198.229.153]) (envelope-sender ) by 212.198.2.70 (qmail-ldap-1.03) with SMTP for ; 11 Jul 2002 22:29:45 -0000 Received: from gits.gits.dyndns.org (n2msrn0jbdrw89mv@localhost [127.0.0.1]) by gits.gits.dyndns.org (8.12.5/8.12.5) with ESMTP id g6BMThTL023642; Fri, 12 Jul 2002 00:29:44 +0200 (CEST) (envelope-from root@gits.dyndns.org) Received: (from root@localhost) by gits.gits.dyndns.org (8.12.5/8.12.5/Submit) id g6BMTd4H023639; Fri, 12 Jul 2002 00:29:39 +0200 (CEST) (envelope-from root) Date: Fri, 12 Jul 2002 00:29:39 +0200 From: Cyrille Lefevre To: Juan Francisco Rodriguez Hervella Cc: freebsd-net@FreeBSD.ORG Subject: Re: sysctl inferface question Message-ID: <20020711222939.GE21234@gits.dyndns.org> Mail-Followup-To: Cyrille Lefevre , Juan Francisco Rodriguez Hervella , freebsd-net@FreeBSD.ORG References: <3D2D9D4E.74A1B6F4@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D2D9D4E.74A1B6F4@it.uc3m.es> User-Agent: Mutt/1.3.99i Organization: ACME X-Face: V|+c;4!|B?E%BE^{E6);aI.[< List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Jul 11, 2002 at 04:59:26PM +0200, Juan Francisco Rodriguez Hervella wrote: > > I'm very confused with the sysctl internals. > > For example, looking at the kernel source code of FreeBSD, I've realized > > of the following: > > netinet/in_proco.c: > SYSCTL_NODE(_net_inet6, IPPROTO_DIVERT, divert, > CTLFLAG_RW, 0, "DIVERT"); > netinet/ip_divert.c: > SYSCTL_DECL(_net_inet_divert); > netinet/ip_divert.c: > SYSCTL_PROC(_net_inet_divert, OID_AUTO, pcblist, CTLFLAG_RD, > 0, 0, > div_pcblist, "S,xinpcb", "List of active divert sockets"); > > Isn't this redundant ? I mean, if there is a "SYSCTL_NODE", there is > *no* need for having > "SYSCTL_DECL" in "ip_divert.c"... I am wrong ? to define a node (pcblist here), you have to declare the node (_net_inet_divert here) you want attach it before. > Also, I don't undertand the meaning of the "fmt" field....what is it for > ? What's the > meaning of "S,xinpcb" in the above example ? the format strings isn't used by the kernel but is by the sysctl(1) command. take a look around lines 556-589 (show_var) in /usr/src/sbin/sysctl/sysctl.c : case 'S': i = 0; if (strcmp(fmt, "S,clockinfo") == 0) func = S_clockinfo; else if (strcmp(fmt, "S,timeval") == 0) func = S_timeval; else if (strcmp(fmt, "S,loadavg") == 0) func = S_loadavg; else if (strcmp(fmt, "T,dev_t") == 0) func = T_dev_t; else func = NULL; if (func) { if (!nflag) printf("%s%s", name, sep); return ((*func)(len, p)); } /* FALL THROUGH */ default: if (!oflag && !xflag) return (1); if (!nflag) printf("%s%s", name, sep); printf("Format:%s Length:%d Dump:0x", fmt, len); while (len-- && (xflag || p < val + 16)) printf("%02x", *p++); if (!xflag && len > 16) printf("..."); return (0); so, the "S" is required, but, IMHO, ",xinpcb" is just informative for now. # sysctl net.inet.divert # sysctl net.inet.divert.pcblist # sysctl -A net.inet.divert net.inet.divert.pcblist: Format:S,xinpcb Length:336 Dump:0x18000000010000000100000000000000... # sysctl -A net.inet.divert.pcblist (same) Cyrille. -- Cyrille Lefevre mailto:cyrille.lefevre@laposte.net 12, Rue de Bizerte 75017 Paris http://clefevre.fr.st tel/fax: +33 (0)1 45 22 83 85 gsm: +33 (0)6 80 94 76 63 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 15:49:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D26637B400 for ; Thu, 11 Jul 2002 15:49:12 -0700 (PDT) Received: from smtp.uc3m.es (smtp03.uc3m.es [163.117.136.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CDA043E31 for ; Thu, 11 Jul 2002 15:49:11 -0700 (PDT) (envelope-from jrh@lab.it.uc3m.es) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 11A6E43149; Thu, 11 Jul 2002 23:49:12 +0200 (CEST) Received: from lmserv2.lab.it.uc3m.es (lmserv2.lab.it.uc3m.es [163.117.144.152]) by smtp03.uc3m.es (Postfix) with ESMTP id DD79499DE7; Thu, 11 Jul 2002 23:49:11 +0200 (CEST) Received: from lm005.lab.it.uc3m.es (root@lm005.lab.it.uc3m.es [163.117.144.134]) by lmserv2.lab.it.uc3m.es (8.9.3/8.9.3) with ESMTP id AAA21726; Fri, 12 Jul 2002 00:49:09 +0200 Received: from localhost (jrh@localhost) by lm005.lab.it.uc3m.es (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id AAA10914; Fri, 12 Jul 2002 00:49:09 +0200 Date: Fri, 12 Jul 2002 00:49:09 +0200 (CEST) From: Juan Francisco Rodriguez Hervella To: Bosko Milekic Cc: freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters In-Reply-To: <20020711171510.A19053@unixdaemons.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Ahhh, ok, I misunderstood the first mail :) Thanks. On Thu, 11 Jul 2002, Bosko Milekic wrote: > > On Thu, Jul 11, 2002 at 11:00:56PM +0200, Juan Francisco Rodriguez Hervella wrote: > > First of all, let me say that Im newbie with these topics, > > I only know a bit about mbufs, but I dont understand how > > can an application trim away the refcount if the size is > > MCLBYTES = 2040 - sizeof(refcount). > > > > Don't this limit the room which an app. can write ? > > No. It just changes it. Also, it's not the application trimming away > anything, and the size is not 2040, it's 2048. :-) > > FWIW, the application has no idea about mbufs or clusters. These are > buffers and structures only the kernel knows about. > > > Thanks. > > > > JFRH > > -- > Bosko Milekic > bmilekic@unixdaemons.com > bmilekic@FreeBSD.org > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 16:20:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1799537B401 for ; Thu, 11 Jul 2002 16:20:17 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id B05DD43E52 for ; Thu, 11 Jul 2002 16:20:16 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020711232016.CGLI8262.rwcrmhc52.attbi.com@InterJet.elischer.org>; Thu, 11 Jul 2002 23:20:16 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA48706; Thu, 11 Jul 2002 16:11:23 -0700 (PDT) Date: Thu, 11 Jul 2002 16:11:23 -0700 (PDT) From: Julian Elischer To: Bosko Milekic Cc: Juan Francisco Rodriguez Hervella , freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters In-Reply-To: <20020711171510.A19053@unixdaemons.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 11 Jul 2002, Bosko Milekic wrote: > > On Thu, Jul 11, 2002 at 11:00:56PM +0200, Juan Francisco Rodriguez Hervella wrote: > > First of all, let me say that Im newbie with these topics, > > I only know a bit about mbufs, but I dont understand how > > can an application trim away the refcount if the size is > > MCLBYTES = 2040 - sizeof(refcount). > > > > Don't this limit the room which an app. can write ? > > No. It just changes it. Also, it's not the application trimming away > anything, and the size is not 2040, it's 2048. :-) > > FWIW, the application has no idea about mbufs or clusters. These are > buffers and structures only the kernel knows about. except if you are trying to use 0 copy semantics. > > > Thanks. > > > > JFRH > > -- > Bosko Milekic > bmilekic@unixdaemons.com > bmilekic@FreeBSD.org > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 16:20:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CB9A37B400 for ; Thu, 11 Jul 2002 16:20:27 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id B306243E09 for ; Thu, 11 Jul 2002 16:20:26 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020711232026.CGQA8262.rwcrmhc52.attbi.com@InterJet.elischer.org>; Thu, 11 Jul 2002 23:20:26 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA48704; Thu, 11 Jul 2002 16:10:33 -0700 (PDT) Date: Thu, 11 Jul 2002 16:10:32 -0700 (PDT) From: Julian Elischer To: Bosko Milekic Cc: Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters In-Reply-To: <20020711171255.A19014@unixdaemons.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 11 Jul 2002, Bosko Milekic wrote: > > Well, I can use a different map, I guess (I use a different map for > mbufs in order to not let huge cluster allocations eat up all of the > address space reserved for mbufs). However, it seems that jumbo bufs > and clusters are logically equivalent (your driver will either use one > or the other) so it would make sense to have them share the same > `chunk' of address space. > > As for the gaps, they are quite huge. I think we calculated a week or > so ago when discussing jumbo bufs that we would probably end up > allocating them in chunks of 3 or 4 at a time. So that would mean at > least ~9 page 'holes' in the address space from which clusters are > allocated, so that would mean ~18 counters wasted, at least, for every > hole. With the number of jumbo bufs we would have, that can really > add up. Don't forget that "external" does not neccesarily mean "cluster". I still consider the method used in (hmm was it NetBSD or OSF/1?) to be very good.. mbufs that referred to the same object were linked together. I forget the details exactly. maybe someone else can remember.. it did it without ref counts somehow.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 16:31:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6528437B400 for ; Thu, 11 Jul 2002 16:31:39 -0700 (PDT) Received: from kronos.networkrichmond.com (kronos.networkrichmond.com [64.240.180.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id A000443E09 for ; Thu, 11 Jul 2002 16:31:38 -0700 (PDT) (envelope-from kbyanc@posi.net) X-Provider: NetworkRichmond, Inc. http://www.networkrichmond.com/ Received: from localhost (kbyanc@localhost) by kronos.networkrichmond.com (8.9.3/8.9.3/antispam) with ESMTP id TAA51972; Thu, 11 Jul 2002 19:31:17 -0400 (EDT) Date: Thu, 11 Jul 2002 19:31:17 -0400 (EDT) From: Kelly Yancey X-Sender: kbyanc@kronos.networkrichmond.com To: Bosko Milekic Cc: Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters In-Reply-To: <20020711171255.A19014@unixdaemons.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 11 Jul 2002, Bosko Milekic wrote: > > On Thu, Jul 11, 2002 at 01:56:08PM -0700, Luigi Rizzo wrote: > > example: userland does an 8KB write, in the old case this requires > > 4 clusters, with the new one you end up using 4 clusters and stuff > > the remaining 16 bytes in a regular mbuf, then depending on the > > relative producer-consumer speed the next write will try to fill > > the mbuf and attach a new cluster, and so on... and when TCP hits > > these data-in-mbuf blocks will have to copy rather than reference > > the data blocks... > > > > Maybe it is irrelevant for performance, maybe it is not, > > i am not sure. > > I see what you're saying. I think that what this means is simply that > the `optimal' chunk of data to send is just a different size, so > instead of it being 8192 bytes, it'll be something like 8180 bytes or > something (to account for the counters). So, in other words, it > really depends on the frequency of exact 8192 sized sends in userland > applications. > ...or exactly 2k or 4k or 6k or 10k... > This is a good observation if we're going to be doing benchmarking, > but I'm not sure whether the repercussions are that important (unless, > as I said, there's a lot of applications that send exactly 8192 > byte chunks?). Basically, what we're doing is shifting the optimal > send size when using exactly 4 clusters, in this case, to (8192 - 16) > bytes. We can still send with exactly 4 clusters, it's just that the > optimal send size is a little different, that's all (this produces a > small shift in block send benchmark curves, usually). > Are you kidding? Benchmarks, presumably like every other piece of software produced by someone trying to get the most performance out of the system, are more likely to have power-of-two write buffers. Are you willing to risk that they didn't also just happen to pick a multiple of 2^11? Yes, it seems elegant to put the counters in the space that is normally unused for receive mbuf clusters, but you can't just blow off Luigi's point regarding the send side. Kelly -- Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 19: 8:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B45CC37B400 for ; Thu, 11 Jul 2002 19:08:13 -0700 (PDT) Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CC1243E31 for ; Thu, 11 Jul 2002 19:08:13 -0700 (PDT) (envelope-from bmilekic@angelica.unixdaemons.com) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.5/8.12.1) with ESMTP id g6C27v6M004200; Thu, 11 Jul 2002 22:07:57 -0400 (EDT) X-Authentication-Warning: angelica.unixdaemons.com: Host bmilekic@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.5/8.12.1/Submit) id g6C27vXv004195; Thu, 11 Jul 2002 22:07:57 -0400 (EDT) (envelope-from bmilekic) Date: Thu, 11 Jul 2002 22:07:57 -0400 From: Bosko Milekic To: Kelly Yancey Cc: freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters Message-ID: <20020711220757.A2476@unixdaemons.com> References: <20020711171255.A19014@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from kbyanc@posi.net on Thu, Jul 11, 2002 at 07:31:17PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Jul 11, 2002 at 07:31:17PM -0400, Kelly Yancey wrote: > > This is a good observation if we're going to be doing benchmarking, > > but I'm not sure whether the repercussions are that important (unless, > > as I said, there's a lot of applications that send exactly 8192 > > byte chunks?). Basically, what we're doing is shifting the optimal > > send size when using exactly 4 clusters, in this case, to (8192 - 16) > > bytes. We can still send with exactly 4 clusters, it's just that the > > optimal send size is a little different, that's all (this produces a > > small shift in block send benchmark curves, usually). > > > > Are you kidding? Benchmarks, presumably like every other piece of > software produced by someone trying to get the most performance out of > the system, are more likely to have power-of-two write buffers. Are you > willing to risk that they didn't also just happen to pick a multiple of > 2^11? > > Yes, it seems elegant to put the counters in the space that is normally > unused for receive mbuf clusters, but you can't just blow off Luigi's > point regarding the send side. First of all, I'm not "blowing off" anyone's comments. I don't appreciate the fact that you're eagerly instructing me to "not blow off comments" (which I didn't do to begin with) without providing any more constructive feedback. All I pointed out was that the optimal block size is merely changed from an exact 2k, 4k, 8k, etc. to something slightly smaller. What point are *you* trying to put across? Tell me what's bad about that or, better: Do you have a better suggestion to make? What do *you* suggest we do with the external ref. counts? Please, spare me the flame bait. I wasn't being confrontational when I answered Luigi's post and I don't need anyone turning this into something confrontational. Thanks. > Kelly > > -- > Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 19:27:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7100937B400 for ; Thu, 11 Jul 2002 19:27:41 -0700 (PDT) Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5E9543E42 for ; Thu, 11 Jul 2002 19:27:40 -0700 (PDT) (envelope-from bmilekic@angelica.unixdaemons.com) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.5/8.12.1) with ESMTP id g6C2RS6M006908; Thu, 11 Jul 2002 22:27:28 -0400 (EDT) X-Authentication-Warning: angelica.unixdaemons.com: Host bmilekic@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.5/8.12.1/Submit) id g6C2RPmO006906; Thu, 11 Jul 2002 22:27:25 -0400 (EDT) (envelope-from bmilekic) Date: Thu, 11 Jul 2002 22:27:25 -0400 From: Bosko Milekic To: Julian Elischer Cc: Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters Message-ID: <20020711222725.A5284@unixdaemons.com> References: <20020711171255.A19014@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from julian@elischer.org on Thu, Jul 11, 2002 at 04:10:32PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Jul 11, 2002 at 04:10:32PM -0700, Julian Elischer wrote: > Don't forget that "external" does not neccesarily mean "cluster". > I still consider the method used in (hmm was it NetBSD or OSF/1?) > to be very good.. > > mbufs that referred to the same object were linked together. > I forget the details exactly. maybe someone else can remember.. > it did it without ref counts somehow.. Yes, this is in NetBSD still and it is very elegant. I remember looking at this a long time ago but to be honest, the reason I didn't implement it then first escaped me. However, thanks to David Malone's awesome commit messages, I found it: rev 1.53 of sys/sys/mbuf.h, extract: [...] "NetBSD's system of linked lists of mbufs was cosidered, but Alfred felt it would have locking issues when the kernel was made more SMP friendly." [...] I think it's almost clear now that there are, in fact, no SMP issues with it (we don't do per-cluster locking, or anything ridiculous like that), so unless Alfred has the reason again, I'll consider that method again instead. Thanks for the constructive feedback. Regards, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 19:34:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFAD537B400 for ; Thu, 11 Jul 2002 19:34:54 -0700 (PDT) Received: from kronos.networkrichmond.com (kronos.networkrichmond.com [64.240.180.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 707A343E54 for ; Thu, 11 Jul 2002 19:34:52 -0700 (PDT) (envelope-from kbyanc@posi.net) X-Provider: NetworkRichmond, Inc. http://www.networkrichmond.com/ Received: from localhost (kbyanc@localhost) by kronos.networkrichmond.com (8.9.3/8.9.3/antispam) with ESMTP id WAA57705; Thu, 11 Jul 2002 22:34:46 -0400 (EDT) Date: Thu, 11 Jul 2002 22:34:46 -0400 (EDT) From: Kelly Yancey X-Sender: kbyanc@kronos.networkrichmond.com To: Bosko Milekic Cc: freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters In-Reply-To: <20020711220757.A2476@unixdaemons.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 11 Jul 2002, Bosko Milekic wrote: > First of all, I'm not "blowing off" anyone's comments. I don't > appreciate the fact that you're eagerly instructing me to "not blow off > comments" (which I didn't do to begin with) without providing any more > constructive feedback. > > All I pointed out was that the optimal block size is merely changed > from an exact 2k, 4k, 8k, etc. to something slightly smaller. What > point are *you* trying to put across? Tell me what's bad about that > or, better: > > Do you have a better suggestion to make? What do *you* suggest we do > with the external ref. counts? Please, spare me the flame bait. I > wasn't being confrontational when I answered Luigi's post and I don't > need anyone turning this into something confrontational. Thanks. > > -- > Bosko Milekic > bmilekic@unixdaemons.com > bmilekic@FreeBSD.org > Whoa man, that must have across completely wrong. I didn't mean to imply any confrontational at all. Actually, if anything I was just trying to restate what should be obvious (and which I think was the point Luigi already made): that for better or worse userland apps think that using power-of-2 write buffers will improve performance. You're right, I don't understand all of the issues well enough to suggest an alternative. And if it weren't for the fact the just about every engineer on the planet has had the "power-of-2 good" rule drilled into them, I would have kept my mouth shut as I usually do. When I saw you suggesting that the optimum size would just be a little lower without mentioning POLA, an alarm went off in my head. In any event, I'll go crawl back into my corner now. Kelly -- Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 19:44:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBCB937B400 for ; Thu, 11 Jul 2002 19:44:41 -0700 (PDT) Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D0AB43E65 for ; Thu, 11 Jul 2002 19:44:41 -0700 (PDT) (envelope-from bmilekic@angelica.unixdaemons.com) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.5/8.12.1) with ESMTP id g6C2iU6M009372; Thu, 11 Jul 2002 22:44:30 -0400 (EDT) X-Authentication-Warning: angelica.unixdaemons.com: Host bmilekic@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.5/8.12.1/Submit) id g6C2iULW009370; Thu, 11 Jul 2002 22:44:30 -0400 (EDT) (envelope-from bmilekic) Date: Thu, 11 Jul 2002 22:44:30 -0400 From: Bosko Milekic To: Kelly Yancey Cc: freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters Message-ID: <20020711224430.A9127@unixdaemons.com> References: <20020711220757.A2476@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from kbyanc@posi.net on Thu, Jul 11, 2002 at 10:34:46PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm sorry. I should have waited before hitting the "send" button. I've had a long and [shitty] day and I shouldn't have blew it off here. Sorry. -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 20:15:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A72BA37B400 for ; Thu, 11 Jul 2002 20:15:20 -0700 (PDT) Received: from tp.databus.com (p72-186.acedsl.com [66.114.72.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD39D43E4A for ; Thu, 11 Jul 2002 20:15:19 -0700 (PDT) (envelope-from barney@databus.com) Received: from databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.4/8.12.3) with ESMTP id g6C3FJQZ070152 for ; Thu, 11 Jul 2002 23:15:19 -0400 (EDT) (envelope-from barney@databus.com) Received: (from barney@localhost) by databus.com (8.12.4/8.12.4/Submit) id g6C3FJFT070151 for freebsd-net@freebsd.org; Thu, 11 Jul 2002 23:15:19 -0400 (EDT) Date: Thu, 11 Jul 2002 23:15:19 -0400 From: Barney Wolff To: freebsd-net@freebsd.org Subject: Re: mbuf external buffer reference counters Message-ID: <20020711231519.A70046@tp.databus.com> References: <20020711220757.A2476@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from kbyanc@posi.net on Thu, Jul 11, 2002 at 10:34:46PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Perhaps it might have something to do with disk sector size and memory page size and BUFSIZ all being powers of 2? :) On Thu, Jul 11, 2002 at 10:34:46PM -0400, Kelly Yancey wrote: > ... that for better or worse userland apps think that > using power-of-2 write buffers will improve performance. -- Barney Wolff I never met a computer I didn't like. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 21:34:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23AFB37B400 for ; Thu, 11 Jul 2002 21:34:52 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6D4343E3B for ; Thu, 11 Jul 2002 21:34:51 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id A2E55AE211; Thu, 11 Jul 2002 21:34:51 -0700 (PDT) Date: Thu, 11 Jul 2002 21:34:51 -0700 From: Alfred Perlstein To: Bosko Milekic Cc: Julian Elischer , Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters Message-ID: <20020712043451.GE97638@elvis.mu.org> References: <20020711171255.A19014@unixdaemons.com> <20020711222725.A5284@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020711222725.A5284@unixdaemons.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Bosko Milekic [020711 19:28] wrote: > > On Thu, Jul 11, 2002 at 04:10:32PM -0700, Julian Elischer wrote: > > Don't forget that "external" does not neccesarily mean "cluster". > > I still consider the method used in (hmm was it NetBSD or OSF/1?) > > to be very good.. > > > > mbufs that referred to the same object were linked together. > > I forget the details exactly. maybe someone else can remember.. > > it did it without ref counts somehow.. > > Yes, this is in NetBSD still and it is very elegant. I remember > looking at this a long time ago but to be honest, the reason I didn't > implement it then first escaped me. However, thanks to David Malone's > awesome commit messages, I found it: > > rev 1.53 of sys/sys/mbuf.h, extract: > [...] > "NetBSD's system of linked lists of mbufs was cosidered, but Alfred > felt it would have locking issues when the kernel was made more > SMP friendly." > [...] > > I think it's almost clear now that there are, in fact, no SMP issues > with it (we don't do per-cluster locking, or anything ridiculous like > that), so unless Alfred has the reason again, I'll consider that method > again instead. Thanks for the constructive feedback. Yes it was NetBSD that did this. How do you plan on manipulating a linked list without switching from a simple atomic_int/dec to a complex global or hashed mutex operation? -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 22:30:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A4C537B400 for ; Thu, 11 Jul 2002 22:30:04 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6203C43E52 for ; Thu, 11 Jul 2002 22:30:03 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id WAA80974; Thu, 11 Jul 2002 22:20:28 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g6C5JoH36140; Thu, 11 Jul 2002 22:19:50 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200207120519.g6C5JoH36140@arch20m.dellroad.org> Subject: Re: mbuf external buffer reference counters In-Reply-To: <20020711222725.A5284@unixdaemons.com> "from Bosko Milekic at Jul 11, 2002 10:27:25 pm" To: Bosko Milekic Date: Thu, 11 Jul 2002 22:19:50 -0700 (PDT) Cc: Julian Elischer , Luigi Rizzo , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bosko Milekic writes: > > mbufs that referred to the same object were linked together. > > I forget the details exactly. maybe someone else can remember.. > > it did it without ref counts somehow.. > > Yes, this is in NetBSD still and it is very elegant. I remember > looking at this a long time ago but to be honest, the reason I didn't > implement it then first escaped me. However, thanks to David Malone's > awesome commit messages, I found it: > > rev 1.53 of sys/sys/mbuf.h, extract: > [...] > "NetBSD's system of linked lists of mbufs was cosidered, but Alfred > felt it would have locking issues when the kernel was made more > SMP friendly." > [...] > > I think it's almost clear now that there are, in fact, no SMP issues > with it (we don't do per-cluster locking, or anything ridiculous like > that), so unless Alfred has the reason again, I'll consider that method > again instead. Thanks for the constructive feedback. That's a cool idea.. haven't looked at NetBSD but am imagining the mbufs would be linked in a 'ring'. This works because you never care how many references are, just whether there's one or more than one, and this is easy to tell by examining the ring pointer. I.e., you never have to iterate through the entire ring. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 22:43:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1305637B400 for ; Thu, 11 Jul 2002 22:43:33 -0700 (PDT) Received: from wso-h001.wsonline.net (12-254-30-97.client.attbi.com [12.254.30.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74A3543E58 for ; Thu, 11 Jul 2002 22:43:32 -0700 (PDT) (envelope-from seahorse51@attbi.com) Received: from seahorse.attbi.com (trilluser@seahorse [192.168.1.101]) by wso-h001.wsonline.net (8.12.5/8.12.5) with ESMTP id g6C5hUYS001958; Thu, 11 Jul 2002 23:43:31 -0600 (MDT) (envelope-from seahorse51@attbi.com) Message-Id: <5.1.0.14.0.20020711233932.0237f368@wsonline.net> X-Sender: seahorse@wsonline.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 11 Jul 2002 23:43:52 -0600 To: Mikel King , nascar24 From: Andy Subject: Re: DHCP lease renewal Cc: net@FreeBSD.ORG In-Reply-To: <3D2DD3BB.2010506@ocsinternet.com> References: <01c001c221dd$38127d20$0200a8c0@winxp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is the script I use to accomplish this. Just substitute the network card interface code with the one you wish to have renewed. I run this every 24 hours, and have been able to keep the same IP address for going on 6 months now. It also generates a handy Email to root when run from /etc/crontab, so that you can review the renewal information, verify your ifconfig settings for that network card, and your change in the IP lease. #!/bin/sh # # Restart DHCLIENT and reconfigure ifconfig ... # SHELL=/bin/sh PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin HOME=/var/log echo " " echo "************************************************************" echo "Started DHCLIENT update: `date \"+%Y-%m-%d %H:%M:%S\"`" echo "************************************************************" echo " " kill -TERM `cat /var/run/dhclient.pid` echo "DHCP Killed, restarting" echo " " /sbin/dhclient xl0 echo " " sleep 10 ifconfig xl0 echo " " more /var/db/dhclient.leases echo " " echo "************************************************************" echo "Finished DHCLIENT update: `date \"+%Y-%m-%d %H:%M:%S\"`" echo "************************************************************" echo " " At 12:51 07/11/2002, Mikel King wrote: >Not sure if you've found this already. One thing I used to do on an older >box was a simple cron job that ran a script which HUP'd the dhclient every >so often thus effectively renewing the lease... > >If memory serves me it went something like.... > > #!/bin/sh > > kill -HUP `ps ax |awk '/dhclient/{print $1; exit}'` >cheers, >mikel > >nascar24 wrote: > >>Hallo, >> >>My FreeBSD 4.5-RELEASE machine is connected to the internet via a cable >>connection. And when booting (or running dhclient) I get an IP address. >>But when I have an IP address and my ISP wants to give me a new IP >>address I doesn't go the way it should. Because I don't get the new IP >>address, my machine continues to use the 'old' IP address. And when that >>happens I get an angry phone call from my ISP, and they shut me from >>internet for a day. >> >>So, how can I configure (dhclient.conf I guess) my machine so that it >>accepts this new IP address. I thought I would configure my machine so >>that it renews its lease every 10 hours. But I have read the man for >>dhclient.conf, dhcp-options and dhclient but I still am puzzled. >> >>Gr. >> >>Marcel. >> > >Cheers, >Mikel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 23:41: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93D2B37B400 for ; Thu, 11 Jul 2002 23:41:04 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5362143E5E for ; Thu, 11 Jul 2002 23:41:04 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 0F3A2AE216; Thu, 11 Jul 2002 23:41:04 -0700 (PDT) Date: Thu, 11 Jul 2002 23:41:04 -0700 From: Alfred Perlstein To: Archie Cobbs Cc: Bosko Milekic , Julian Elischer , Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters Message-ID: <20020712064104.GG97638@elvis.mu.org> References: <20020711222725.A5284@unixdaemons.com> <200207120519.g6C5JoH36140@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200207120519.g6C5JoH36140@arch20m.dellroad.org> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Archie Cobbs [020711 22:30] wrote: > Bosko Milekic writes: > > > mbufs that referred to the same object were linked together. > > > I forget the details exactly. maybe someone else can remember.. > > > it did it without ref counts somehow.. > > > > Yes, this is in NetBSD still and it is very elegant. I remember > > looking at this a long time ago but to be honest, the reason I didn't > > implement it then first escaped me. However, thanks to David Malone's > > awesome commit messages, I found it: > > > > rev 1.53 of sys/sys/mbuf.h, extract: > > [...] > > "NetBSD's system of linked lists of mbufs was cosidered, but Alfred > > felt it would have locking issues when the kernel was made more > > SMP friendly." > > [...] > > > > I think it's almost clear now that there are, in fact, no SMP issues > > with it (we don't do per-cluster locking, or anything ridiculous like > > that), so unless Alfred has the reason again, I'll consider that method > > again instead. Thanks for the constructive feedback. > > That's a cool idea.. haven't looked at NetBSD but am imagining the > mbufs would be linked in a 'ring'. This works because you never > care how many references are, just whether there's one or more than > one, and this is easy to tell by examining the ring pointer. > I.e., you never have to iterate through the entire ring. That's true, but could someone explain how one can safely and effeciently manipulate such a structure in an SMP environment? I'm not saying it's impossible, I'm just saying it didn't seem intuative to me back then, as well as now. -- -Alfred Perlstein [alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 11 23:46:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9DE937B400 for ; Thu, 11 Jul 2002 23:46:26 -0700 (PDT) Received: from smak.floondoon.com (12-235-54-229.client.attbi.com [12.235.54.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8551743E4A for ; Thu, 11 Jul 2002 23:46:26 -0700 (PDT) (envelope-from james@floondoon.com) Received: from sphynx (unknown [192.168.235.15]) by smak.floondoon.com (Postfix) with ESMTP id 6062F130895 for ; Thu, 11 Jul 2002 23:24:14 -0700 (PDT) Message-ID: <002901c2296f$d98f6fc0$0feba8c0@sphynx> From: "James Satterfield" To: Subject: ipsec + racoon + WatchGuard Firebox? Date: Thu, 11 Jul 2002 23:46:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Anyone have any success with creating a ipsec tunnel between a freebsd gateway and a WatchGuard Firebox? It looks like I'm getting past authentication. I can't tell if the tunnel is actually getting created, but I certainly cannot move traffic through it. James. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 12 0: 0:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 782F737B408 for ; Fri, 12 Jul 2002 00:00:25 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF72143E58 for ; Fri, 12 Jul 2002 00:00:24 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020712070024.TLNG8262.rwcrmhc52.attbi.com@InterJet.elischer.org>; Fri, 12 Jul 2002 07:00:24 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA50396; Thu, 11 Jul 2002 23:44:23 -0700 (PDT) Date: Thu, 11 Jul 2002 23:44:23 -0700 (PDT) From: Julian Elischer To: Alfred Perlstein Cc: Archie Cobbs , Bosko Milekic , Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters In-Reply-To: <20020712064104.GG97638@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 11 Jul 2002, Alfred Perlstein wrote: > > That's true, but could someone explain how one can safely and > effeciently manipulate such a structure in an SMP environment? what does NetBSD do for that? > I'm not saying it's impossible, I'm just saying it didn't seem > intuative to me back then, as well as now. > > -- > -Alfred Perlstein [alfred@freebsd.org] > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 12 0:10:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF8BF37B400 for ; Fri, 12 Jul 2002 00:10:41 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 837EA43E3B for ; Fri, 12 Jul 2002 00:10:41 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 574C3AE24A; Fri, 12 Jul 2002 00:10:41 -0700 (PDT) Date: Fri, 12 Jul 2002 00:10:41 -0700 From: Alfred Perlstein To: Julian Elischer Cc: Archie Cobbs , Bosko Milekic , Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters Message-ID: <20020712071041.GH97638@elvis.mu.org> References: <20020712064104.GG97638@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Julian Elischer [020712 00:00] wrote: > > > On Thu, 11 Jul 2002, Alfred Perlstein wrote: > > > > That's true, but could someone explain how one can safely and > > effeciently manipulate such a structure in an SMP environment? > > what does NetBSD do for that? They don't! *** waves skull staff exasperatedly *** RORWLRLRLLRL To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 12 4:26:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D79437B400 for ; Fri, 12 Jul 2002 04:26:53 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D6BE43E4A for ; Fri, 12 Jul 2002 04:26:53 -0700 (PDT) (envelope-from baka@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1921) id 0A6C3AE23A; Fri, 12 Jul 2002 04:26:53 -0700 (PDT) Date: Fri, 12 Jul 2002 04:26:53 -0700 From: Jon Mini To: Alfred Perlstein Cc: Archie Cobbs , Bosko Milekic , Julian Elischer , Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters Message-ID: <20020712112653.GS55378@elvis.mu.org> References: <20020711222725.A5284@unixdaemons.com> <200207120519.g6C5JoH36140@arch20m.dellroad.org> <20020712064104.GG97638@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020712064104.GG97638@elvis.mu.org> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Jul 11, 2002 at 11:41:04PM -0700, Alfred Perlstein wrote: > > That's a cool idea.. haven't looked at NetBSD but am imagining the > > mbufs would be linked in a 'ring'. This works because you never > > care how many references are, just whether there's one or more than > > one, and this is easy to tell by examining the ring pointer. > > I.e., you never have to iterate through the entire ring. > > That's true, but could someone explain how one can safely and > effeciently manipulate such a structure in an SMP environment? > > I'm not saying it's impossible, I'm just saying it didn't seem > intuative to me back then, as well as now. I'm probably speaking out of turn here (I have no idea what structure you all are talking about), but a monodirectional ring can be safely modified with a compare-and-exchange atomic operation. -- Jonathan Mini http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 12 4:39: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECD5737B400 for ; Fri, 12 Jul 2002 04:38:59 -0700 (PDT) Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C74B43E31 for ; Fri, 12 Jul 2002 04:38:59 -0700 (PDT) (envelope-from bmilekic@angelica.unixdaemons.com) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.5/8.12.1) with ESMTP id g6CBcg6M075934; Fri, 12 Jul 2002 07:38:42 -0400 (EDT) X-Authentication-Warning: angelica.unixdaemons.com: Host bmilekic@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.5/8.12.1/Submit) id g6CBcgxl075933; Fri, 12 Jul 2002 07:38:42 -0400 (EDT) (envelope-from bmilekic) Date: Fri, 12 Jul 2002 07:38:42 -0400 From: Bosko Milekic To: Alfred Perlstein Cc: Julian Elischer , Archie Cobbs , Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters Message-ID: <20020712073842.A75547@unixdaemons.com> References: <20020712064104.GG97638@elvis.mu.org> <20020712071041.GH97638@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020712071041.GH97638@elvis.mu.org>; from bright@mu.org on Fri, Jul 12, 2002 at 12:10:41AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jul 12, 2002 at 12:10:41AM -0700, Alfred Perlstein wrote: > * Julian Elischer [020712 00:00] wrote: > > > > > > On Thu, 11 Jul 2002, Alfred Perlstein wrote: > > > > > > That's true, but could someone explain how one can safely and > > > effeciently manipulate such a structure in an SMP environment? > > > > what does NetBSD do for that? > > They don't! > > *** waves skull staff exasperatedly *** > > RORWLRLRLLRL Again, Alfred is right. :-) I can't think of a way to ensure that the owner of the other mbuf doesn't manipulate its two forward/backward pointers while we're manipulating ours. The only way that springs to mind is to have them protected by a mutex, but: 1) that would be very expensive and would bloat the mbuf structure a LOT; 2) we would probably run into lock order reversal problems. I see now what Alfred meant when he made his original comment. -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 12 4:50: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB80237B401 for ; Fri, 12 Jul 2002 04:50:03 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79E3343E31 for ; Fri, 12 Jul 2002 04:50:03 -0700 (PDT) (envelope-from baka@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1921) id 1B7B6AE22C; Fri, 12 Jul 2002 04:50:03 -0700 (PDT) Date: Fri, 12 Jul 2002 04:50:03 -0700 From: Jon Mini To: Bosko Milekic Cc: Alfred Perlstein , Archie Cobbs , Julian Elischer , Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters Message-ID: <20020712115003.GT55378@elvis.mu.org> References: <20020711222725.A5284@unixdaemons.com> <200207120519.g6C5JoH36140@arch20m.dellroad.org> <20020712064104.GG97638@elvis.mu.org> <20020712112653.GS55378@elvis.mu.org> <20020712074507.B75547@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020712074507.B75547@unixdaemons.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jul 12, 2002 at 07:45:07AM -0400, Bosko Milekic wrote: > > [ ... Description of modifying a bidrectional ring ... ] > > So I guess that what we're dealing with isn't really a > "monodirectional" ring. Right? Yep. =) -- Jonathan Mini http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 12 5: 9:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9742237B401 for ; Fri, 12 Jul 2002 05:09:26 -0700 (PDT) Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4F9D43E6A for ; Fri, 12 Jul 2002 05:09:10 -0700 (PDT) (envelope-from keramida@ceid.upatras.gr) Received: from hades.hell.gr (patr530-a107.otenet.gr [212.205.215.107]) by mailsrv.otenet.gr (8.12.4/8.12.4) with ESMTP id g6CC81Hw023621; Fri, 12 Jul 2002 15:08:02 +0300 (EEST) Received: from hades.hell.gr (hades [127.0.0.1]) by hades.hell.gr (8.12.5/8.12.5) with ESMTP id g6CC809J052613; Fri, 12 Jul 2002 15:08:00 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from charon@localhost) by hades.hell.gr (8.12.5/8.12.5/Submit) id g6CC7xnp052612; Fri, 12 Jul 2002 15:07:59 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Fri, 12 Jul 2002 15:07:57 +0300 From: Giorgos Keramidas To: Bosko Milekic Cc: Luigi Rizzo , freebsd-net@FreeBSD.org Subject: Re: mbuf external buffer reference counters Message-ID: <20020712120757.GE51735@hades.hell.gr> References: <20020711162026.A18717@unixdaemons.com> <20020711133802.A31827@iguana.icir.org> <20020711164225.A18852@unixdaemons.com> <20020711135608.A32460@iguana.icir.org> <20020711171255.A19014@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020711171255.A19014@unixdaemons.com> X-Operating-System: FreeBSD 5.0-CURRENT i386 X-PGP-Fingerprint: C1EB 0653 DB8B A557 3829 00F9 D60F 941A 3186 03B6 X-Phone: +30-944-116520 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 2002-07-11 17:12 +0000, Bosko Milekic wrote: > On Thu, Jul 11, 2002 at 01:56:08PM -0700, Luigi Rizzo wrote: > > example: userland does an 8KB write, in the old case this requires > > 4 clusters, with the new one you end up using 4 clusters and stuff > > the remaining 16 bytes in a regular mbuf, then depending on the > > relative producer-consumer speed the next write will try to fill > > the mbuf and attach a new cluster, and so on... and when TCP hits > > these data-in-mbuf blocks will have to copy rather than reference > > the data blocks... > > This is a good observation if we're going to be doing benchmarking, > but I'm not sure whether the repercussions are that important (unless, > as I said, there's a lot of applications that send exactly 8192 > byte chunks?). This is not true only for 8192 byte-sized writes. Anything that uses a block size >2048 near a power of 2 will have the same problem. Writes that use 2048 bytes, 4096, 8192, 16384, ... will all have this very same problem :/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 12 5:12:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E790437B400 for ; Fri, 12 Jul 2002 05:12:45 -0700 (PDT) Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 055C543E65 for ; Fri, 12 Jul 2002 05:12:45 -0700 (PDT) (envelope-from bmilekic@angelica.unixdaemons.com) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.5/8.12.1) with ESMTP id g6CBj86M076625; Fri, 12 Jul 2002 07:45:08 -0400 (EDT) X-Authentication-Warning: angelica.unixdaemons.com: Host bmilekic@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.5/8.12.1/Submit) id g6CBj761076624; Fri, 12 Jul 2002 07:45:07 -0400 (EDT) (envelope-from bmilekic) Date: Fri, 12 Jul 2002 07:45:07 -0400 From: Bosko Milekic To: Jon Mini Cc: Alfred Perlstein , Archie Cobbs , Julian Elischer , Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters Message-ID: <20020712074507.B75547@unixdaemons.com> References: <20020711222725.A5284@unixdaemons.com> <200207120519.g6C5JoH36140@arch20m.dellroad.org> <20020712064104.GG97638@elvis.mu.org> <20020712112653.GS55378@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020712112653.GS55378@elvis.mu.org>; from baka@elvis.mu.org on Fri, Jul 12, 2002 at 04:26:53AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jul 12, 2002 at 04:26:53AM -0700, Jon Mini wrote: > On Thu, Jul 11, 2002 at 11:41:04PM -0700, Alfred Perlstein wrote: > > > That's a cool idea.. haven't looked at NetBSD but am imagining the > > > mbufs would be linked in a 'ring'. This works because you never > > > care how many references are, just whether there's one or more than > > > one, and this is easy to tell by examining the ring pointer. > > > I.e., you never have to iterate through the entire ring. > > > > That's true, but could someone explain how one can safely and > > effeciently manipulate such a structure in an SMP environment? > > > > I'm not saying it's impossible, I'm just saying it didn't seem > > intuative to me back then, as well as now. > > I'm probably speaking out of turn here (I have no idea what structure you > all are talking about), but a monodirectional ring can be safely modified > with a compare-and-exchange atomic operation. The jist of the problem is that when you want to say, remove yourself from the list, you have to: 1) your "next"'s back pointer to your "back" pointer 2) your "Prev"'s next pointer to your "next" pointer So that's two operations but for all you know your "next" or your "back" may be doing the same thing to you at the same time. As far as I know, you can't (intuitively) figure out a way to do both of these atomically. i.e., maybe you'll set your next's back pointer to whatever you have in `back' but then your `back' guy will set your back pointer to whatever he has in `back' and then your next guy's back pointer will be invalid, for example. So I guess that what we're dealing with isn't really a "monodirectional" ring. Right? > -- > Jonathan Mini > http://www.freebsd.org/ Regards, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 12 5:28:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 635FF37B400 for ; Fri, 12 Jul 2002 05:28:33 -0700 (PDT) Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59A7143E58 for ; Fri, 12 Jul 2002 05:28:32 -0700 (PDT) (envelope-from keramida@ceid.upatras.gr) Received: from hades.hell.gr (patr530-a107.otenet.gr [212.205.215.107]) by mailsrv.otenet.gr (8.12.4/8.12.4) with ESMTP id g6CCSGHw018569; Fri, 12 Jul 2002 15:28:17 +0300 (EEST) Received: from hades.hell.gr (hades [127.0.0.1]) by hades.hell.gr (8.12.5/8.12.5) with ESMTP id g6CCSF9J052866; Fri, 12 Jul 2002 15:28:15 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from charon@localhost) by hades.hell.gr (8.12.5/8.12.5/Submit) id g6CCSDee052865; Fri, 12 Jul 2002 15:28:13 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Fri, 12 Jul 2002 15:28:12 +0300 From: Giorgos Keramidas To: Bosko Milekic Cc: Jon Mini , Alfred Perlstein , Archie Cobbs , Julian Elischer , Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters Message-ID: <20020712122811.GA52803@hades.hell.gr> References: <20020711222725.A5284@unixdaemons.com> <200207120519.g6C5JoH36140@arch20m.dellroad.org> <20020712064104.GG97638@elvis.mu.org> <20020712112653.GS55378@elvis.mu.org> <20020712074507.B75547@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020712074507.B75547@unixdaemons.com> X-Operating-System: FreeBSD 5.0-CURRENT i386 X-PGP-Fingerprint: C1EB 0653 DB8B A557 3829 00F9 D60F 941A 3186 03B6 X-Phone: +30-944-116520 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 2002-07-12 07:45 +0000, Bosko Milekic wrote: > The jist of the problem is that when you want to say, remove yourself > from the list, you have to: > > 1) your "next"'s back pointer to your "back" pointer > 2) your "Prev"'s next pointer to your "next" pointer > > So that's two operations but for all you know your "next" or your > "back" may be doing the same thing to you at the same time. As far as > I know, you can't (intuitively) figure out a way to do both of these > atomically. i.e., maybe you'll set your next's back pointer to whatever > you have in `back' but then your `back' guy will set your back pointer > to whatever he has in `back' and then your next guy's back pointer will > be invalid, for example. > > So I guess that what we're dealing with isn't really a > "monodirectional" ring. Right? No it isn't. It looks more like the "dining philosophers" problem. But that problem's solution would require at least one mutex for every part of the ring :-( To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 12 6: 6:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F6F437B400 for ; Fri, 12 Jul 2002 06:06:20 -0700 (PDT) Received: from rerun.avayactc.com (rerun.avayactc.com [199.93.237.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C916E43E58 for ; Fri, 12 Jul 2002 06:06:19 -0700 (PDT) (envelope-from mcambria@avaya.com) Received: by rerun.avayactc.com with Internet Mail Service (5.5.2653.19) id <3YWRQQQX>; Fri, 12 Jul 2002 09:06:13 -0400 Message-ID: <3A6D367EA1EFD4118C9B00A0C9DD99D7065A34@rerun.avayactc.com> From: "Cambria, Mike" To: 'Jonathan Lemon' , cambria@world.std.com, net@freebsd.org Subject: RE: xl checksum and dsniff Date: Fri, 12 Jul 2002 09:06:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > -----Original Message----- > From: Jonathan Lemon [mailto:jlemon@flugsvamp.com] >> > > >My guess is that doing hw checksum by the nic could be the > issue. This is > >the only real difference I can see at present. > > > >Any ideas? > > Test your theory. Turn off hardware checksums with 'ifconfig > xl0 -txcsum' When I do 'ifconfig xl0 -txcsum', a subsequent 'ifconfig' reads as if the command had no effect. In other words, ifconfig shows options=3 still. Using tcpdump, it also still reports 'bad checksum' even though everything works fine. The man page for xl also doesn't show these commands. Perhaps they are not turned on yet? On a similar machine, running OpenBSD 3.0, dsniff works just fine. This machine doesn't have support for checksum offload (or at least, ifconfig xl0 doesn't indicate it.) MikeC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 12 8:12: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E57E537B400 for ; Fri, 12 Jul 2002 08:12:05 -0700 (PDT) Received: from exchange.epx.com (exchange.epx.com [128.121.22.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E3CB43E6D for ; Fri, 12 Jul 2002 08:12:05 -0700 (PDT) (envelope-from tsevy@exchange.epx.com) Received: (from root@localhost) by ux340prd.epx.com (8.11.6/8.11.6) id g6CEtI400824 for net@freebsd.org; Fri, 12 Jul 2002 10:55:18 -0400 (EDT) (envelope-from tsevy) Message-Id: <200207121455.g6CEtI400824@ux340prd.epx.com> Content-Type: text/plain; charset="iso-8859-1" From: freebsd To: net@freebsd.org Subject: Question about network layers in FreeBSD 4.x Date: Fri, 12 Jul 2002 10:55:18 -0400 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have a system I run FreeBSD 4.5-release on. The purpose of this system is to run Snort (IDS). The current system is a Compaq Proliant 1850R, have also tried on a Compaq Proliant 1600R. Both systems are SMP with dual processors, > 256m ram, and Compaq Smart Array controller to handle raid in hardware. I want to use this box to monitor multiple lan segments. So I use the builtin tlan eth for mgmt, and than add other nics with no IP addresses for snort to listen on. This works great when I use distinct multiple NIC cards. 3com + Intel + Realtek. However, when I try to use a quad ethernet card, it fails. The programs don't bomb, no errors reported. But there is amount of activity that doesn't get picked up when using the quad cards vs. when using the multiple NICs scenario. For example, if someone in lan segment x.x.a.x connects to a *nix server in x.x.b.x (both monitored by this box), and a suspicious event occurs I will see it captured by both of the snort interfaces. If, however, I put in the quad card, and the same thing happens, it will only be seen/recorded by one of the snort nic instances. I have tried this with a Znyx ZX346Q and with an Adaptec quad card. With the Znyx I tried both the default freebsd drivers it sees that card as and also with the Znyx drivers. This seems to be a problem somewhere other than in the NIC driver itself. Any suggestions or insight into what might be wrong here would be greatly appreciated. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 12 10: 2:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4479E37B400 for ; Fri, 12 Jul 2002 10:02:30 -0700 (PDT) Received: from prism.flugsvamp.com (66-191-112-47.mad.wi.charter.com [66.191.112.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id A699643E58 for ; Fri, 12 Jul 2002 10:02:29 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.6/8.11.6) id g6CH0m210374; Fri, 12 Jul 2002 12:00:48 -0500 (CDT) (envelope-from jlemon) Date: Fri, 12 Jul 2002 12:00:48 -0500 From: Jonathan Lemon To: "Cambria, Mike" Cc: "'Jonathan Lemon'" , cambria@world.std.com, net@freebsd.org Subject: Re: xl checksum and dsniff Message-ID: <20020712120048.B8927@prism.flugsvamp.com> References: <3A6D367EA1EFD4118C9B00A0C9DD99D7065A34@rerun.avayactc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <3A6D367EA1EFD4118C9B00A0C9DD99D7065A34@rerun.avayactc.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jul 12, 2002 at 09:06:13AM -0400, Cambria, Mike wrote: > > -----Original Message----- > > From: Jonathan Lemon [mailto:jlemon@flugsvamp.com] > >> > > > >My guess is that doing hw checksum by the nic could be the > > issue. This is > > >the only real difference I can see at present. > > > > > >Any ideas? > > > > Test your theory. Turn off hardware checksums with 'ifconfig > > xl0 -txcsum' > > When I do 'ifconfig xl0 -txcsum', a subsequent 'ifconfig' reads as if the > command had no effect. In other words, ifconfig shows > options=3 still. Oh, hmm. It appears that this driver doesn't support disabling checksums. For the time being, you can recompile the driver, and manually disable the checksums by editing the define at the top of the file: #define XL905B_CSUM_FEATURES 0 -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 12 10:43:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C635A37B400 for ; Fri, 12 Jul 2002 10:43:33 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C0A643E65 for ; Fri, 12 Jul 2002 10:43:33 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g6CHhOJ54643; Fri, 12 Jul 2002 10:43:24 -0700 (PDT) (envelope-from rizzo) Date: Fri, 12 Jul 2002 10:43:24 -0700 From: Luigi Rizzo To: Jonathan Lemon Cc: "Cambria, Mike" , cambria@world.std.com, net@FreeBSD.ORG Subject: Re: xl checksum and dsniff Message-ID: <20020712104324.A54624@iguana.icir.org> References: <3A6D367EA1EFD4118C9B00A0C9DD99D7065A34@rerun.avayactc.com> <20020712120048.B8927@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020712120048.B8927@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Fri, Jul 12, 2002 at 12:00:48PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Actually, I seem to remember that the ifconfig output only shows the driver's capabilities, not the actual setting. cheers luigi On Fri, Jul 12, 2002 at 12:00:48PM -0500, Jonathan Lemon wrote: > > On Fri, Jul 12, 2002 at 09:06:13AM -0400, Cambria, Mike wrote: > > > -----Original Message----- > > > From: Jonathan Lemon [mailto:jlemon@flugsvamp.com] > > >> > > > > >My guess is that doing hw checksum by the nic could be the > > > issue. This is > > > >the only real difference I can see at present. > > > > > > > >Any ideas? > > > > > > Test your theory. Turn off hardware checksums with 'ifconfig > > > xl0 -txcsum' > > > > When I do 'ifconfig xl0 -txcsum', a subsequent 'ifconfig' reads as if the > > command had no effect. In other words, ifconfig shows > > options=3 still. > > Oh, hmm. It appears that this driver doesn't support disabling checksums. > For the time being, you can recompile the driver, and manually disable the > checksums by editing the define at the top of the file: > > #define XL905B_CSUM_FEATURES 0 > -- > Jonathan > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 12 10:51:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16F5937B400 for ; Fri, 12 Jul 2002 10:51:52 -0700 (PDT) Received: from prism.flugsvamp.com (66-191-112-47.mad.wi.charter.com [66.191.112.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 395B443E3B for ; Fri, 12 Jul 2002 10:51:51 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.6/8.11.6) id g6CHo2K12069; Fri, 12 Jul 2002 12:50:02 -0500 (CDT) (envelope-from jlemon) Date: Fri, 12 Jul 2002 12:50:02 -0500 From: Jonathan Lemon To: Luigi Rizzo Cc: Jonathan Lemon , "Cambria, Mike" , cambria@world.std.com, net@FreeBSD.ORG Subject: Re: xl checksum and dsniff Message-ID: <20020712125002.C8927@prism.flugsvamp.com> References: <3A6D367EA1EFD4118C9B00A0C9DD99D7065A34@rerun.avayactc.com> <20020712120048.B8927@prism.flugsvamp.com> <20020712104324.A54624@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20020712104324.A54624@iguana.icir.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org No - ifconfig shows the actual settings. 'ifconfig -m' will show both the configured settings and the driver capability list. -- Jonathan On Fri, Jul 12, 2002 at 10:43:24AM -0700, Luigi Rizzo wrote: > Actually, I seem to remember that the ifconfig output only shows > the driver's capabilities, not the actual setting. > > cheers > luigi > > On Fri, Jul 12, 2002 at 12:00:48PM -0500, Jonathan Lemon wrote: > > > > On Fri, Jul 12, 2002 at 09:06:13AM -0400, Cambria, Mike wrote: > > > > -----Original Message----- > > > > From: Jonathan Lemon [mailto:jlemon@flugsvamp.com] > > > >> > > > > > >My guess is that doing hw checksum by the nic could be the > > > > issue. This is > > > > >the only real difference I can see at present. > > > > > > > > > >Any ideas? > > > > > > > > Test your theory. Turn off hardware checksums with 'ifconfig > > > > xl0 -txcsum' > > > > > > When I do 'ifconfig xl0 -txcsum', a subsequent 'ifconfig' reads as if the > > > command had no effect. In other words, ifconfig shows > > > options=3 still. > > > > Oh, hmm. It appears that this driver doesn't support disabling checksums. > > For the time being, you can recompile the driver, and manually disable the > > checksums by editing the define at the top of the file: > > > > #define XL905B_CSUM_FEATURES 0 > > -- > > Jonathan > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 12 11: 2:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16A6B37B400 for ; Fri, 12 Jul 2002 11:02:19 -0700 (PDT) Received: from herbelot.dyndns.org (d108.dhcp212-198-26.noos.fr [212.198.26.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0976843E3B for ; Fri, 12 Jul 2002 11:02:18 -0700 (PDT) (envelope-from thierry@herbelot.com) Received: from herbelot.com (tulipe.herbelot.nom [192.168.2.5]) by herbelot.dyndns.org (8.9.3/8.9.3) with ESMTP id UAA23411; Fri, 12 Jul 2002 20:02:14 +0200 (CEST) (envelope-from thierry@herbelot.com) Message-ID: <3D2F19A5.68708464@herbelot.com> Date: Fri, 12 Jul 2002 20:02:13 +0200 From: Thierry Herbelot X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd Cc: net@FreeBSD.ORG Subject: Re: Question about network layers in FreeBSD 4.x References: <200207121455.g6CEtI400824@ux340prd.epx.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org freebsd wrote: > > I have a system I run FreeBSD 4.5-release on. The purpose of this system is > to run Snort (IDS). > > The current system is a Compaq Proliant 1850R, have also tried on a Compaq > Proliant 1600R. > > Both systems are SMP with dual processors, > 256m ram, and Compaq Smart Array > controller to handle raid in hardware. > FreeBSD 4.x (did-you notice 4.6 has been released ?) is not very good at using SMP machines where there are lots of interrupts (the kernel can only be run by one CPU at any one time, and this is enforced by a "Big Giant Lock"). you should re-run your test without the SMP option, to see it the problem is still here (it should not) then, there are kernel options in recent versions of FreeBSD enabling an optimized use of the interrupts (DEVICE POLLING). this may help you, if the driver has been modified. I used a cheap 4-port NIC from DLINK (DFE-570-TX) with very good success (this is the dc driver) Hope this helps TfH To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 12 11: 3:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6ABF237B400 for ; Fri, 12 Jul 2002 11:03:51 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1477D43E4A for ; Fri, 12 Jul 2002 11:03:50 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g6CI3kT24919; Fri, 12 Jul 2002 11:03:46 -0700 (PDT) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.4/8.12.4/Submit) id g6CI3je9008944; Fri, 12 Jul 2002 11:03:45 -0700 (PDT) (envelope-from jdp) Date: Fri, 12 Jul 2002 11:03:45 -0700 (PDT) Message-Id: <200207121803.g6CI3je9008944@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: bmilekic@unixdaemons.com Subject: Re: mbuf external buffer reference counters In-Reply-To: <20020711162026.A18717@unixdaemons.com> References: <20020711162026.A18717@unixdaemons.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <20020711162026.A18717@unixdaemons.com>, Bosko Milekic wrote: > > Right now, in -CURRENT, there is this hack that I introduced that > basically just allocates a ref. counter for external buffers attached > to mbufs with malloc(9). What this means is that if you do something > like allocate an mbuf and then a cluster, there's a malloc() call that > is made to allocate a small (usually 4-byte) reference counter for it. > > That sucks, Eeek, it sure does! > and even -STABLE doesn't do this. I changed it this way > a long time ago for simplicity's sake and since then I've been meaning > to do something better here. The idea was, for mbuf CLUSTERS, to > stash the counter at the end of the 2K buffer area, and to make > MCLBYTES = 2048 - sizeof(refcount), which should be more than enough, > theoretically, for all cluster users. This is by far the easiest > solution (I had it implemented about 10 months ago) and it worked > great. > > The purpose of this Email is to find out if anyone has concrete > information on why this wouldn't work (if they think it wouldn't). I've been out of town and I realize I'm coming into this thread late and that it has evolved a bit. But I still think it's worthwhile to point out a very big problem with the idea of putting the reference count at the end of each mbuf cluster. It would have disastrous consequences for performance because of cache effects. Bear with me through a little bit of arithmetic. Consider a typical PIII CPU that has a 256 kbyte 4-way set-associative L2 cache with 32-byte cache lines. 4-way means that there are 4 different cache lines associated with each address. Each group of 4 is called a set, and each set covers 32 bytes of the address space (the cache line size). The total number of sets is: 256 kbytes / 32 bytes per line / 4 lines per set = 2048 sets and as mentioned above, each set covers 32 bytes. The cache wraps around every 256 kbytes / 4-way = 64 kbytes of address space. In other words, if address N maps onto a given set, then addresses N + 64k, N + 128k, etc. all map onto the same set. An mbuf cluster is 2 kbytes and all mbuf clusters are well-aligned. So the wrap around of the cache occurs every 64 kbytes / 2 kbytes per cluster = 32 clusters. To put it another way, all of the reference counts would be sharing (i.e., competing for) the same 32 cache sets and they would never utilize the remaining 2061 sets at all. Only 1.56% of the cache (32 sets / 2048 sets) would be usable for the reference counts. This means there would be a lot of cache misses as reference count updates caused other reference counts to be flushed from the cache. These cache effects are huge, and they are growing all the time as CPU speeds increase while RAM speeds remain relatively constant. It is much better to have the reference counts laid out as they are in -stable, i.e., one big contiguous block of counts. That way, the counts are spread out through the entire cache and they don't compete with each other nearly so much. That is the underlying principle of slab allocators, by the way. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 12 11:20:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66E3237B401 for ; Fri, 12 Jul 2002 11:20:10 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD47043E6D for ; Fri, 12 Jul 2002 11:20:09 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020712182009.ZSFB29588.sccrmhc01.attbi.com@InterJet.elischer.org>; Fri, 12 Jul 2002 18:20:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA52972; Fri, 12 Jul 2002 11:09:49 -0700 (PDT) Date: Fri, 12 Jul 2002 11:09:47 -0700 (PDT) From: Julian Elischer To: Giorgos Keramidas Cc: Bosko Milekic , Jon Mini , Alfred Perlstein , Archie Cobbs , Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters In-Reply-To: <20020712122811.GA52803@hades.hell.gr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 12 Jul 2002, Giorgos Keramidas wrote: > On 2002-07-12 07:45 +0000, Bosko Milekic wrote: > > > > So I guess that what we're dealing with isn't really a > > "monodirectional" ring. Right? > > No it isn't. It looks more like the "dining philosophers" problem. > But that problem's solution would require at least one mutex for every > part of the ring :-( Te stuff under consideration originally came from OSF/1 which became true-64 that was heavily SMP can anyone find out what they did? > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 12 11:21:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAC2337B401 for ; Fri, 12 Jul 2002 11:21:05 -0700 (PDT) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFA8243E31 for ; Fri, 12 Jul 2002 11:21:04 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g6CIKLf44665; Fri, 12 Jul 2002 14:20:21 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Fri, 12 Jul 2002 14:20:21 -0400 From: Bosko Milekic To: John Polstra Cc: net@freebsd.org Subject: Re: mbuf external buffer reference counters Message-ID: <20020712142021.A44645@unixdaemons.com> References: <20020711162026.A18717@unixdaemons.com> <200207121803.g6CI3je9008944@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <200207121803.g6CI3je9008944@vashon.polstra.com>; from jdp@polstra.com on Fri, Jul 12, 2002 at 11:03:45AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jul 12, 2002 at 11:03:45AM -0700, John Polstra wrote: > I've been out of town and I realize I'm coming into this thread late > and that it has evolved a bit. But I still think it's worthwhile to > point out a very big problem with the idea of putting the reference > count at the end of each mbuf cluster. It would have disastrous > consequences for performance because of cache effects. Bear with me > through a little bit of arithmetic. > > Consider a typical PIII CPU that has a 256 kbyte 4-way set-associative > L2 cache with 32-byte cache lines. 4-way means that there are 4 > different cache lines associated with each address. Each group of 4 > is called a set, and each set covers 32 bytes of the address space > (the cache line size). > > The total number of sets is: > > 256 kbytes / 32 bytes per line / 4 lines per set = 2048 sets > > and as mentioned above, each set covers 32 bytes. > > The cache wraps around every 256 kbytes / 4-way = 64 kbytes of address > space. In other words, if address N maps onto a given set, then > addresses N + 64k, N + 128k, etc. all map onto the same set. > > An mbuf cluster is 2 kbytes and all mbuf clusters are well-aligned. > So the wrap around of the cache occurs every 64 kbytes / 2 kbytes per > cluster = 32 clusters. To put it another way, all of the reference > counts would be sharing (i.e., competing for) the same 32 cache sets > and they would never utilize the remaining 2061 sets at all. Only > 1.56% of the cache (32 sets / 2048 sets) would be usable for the > reference counts. This means there would be a lot of cache misses as > reference count updates caused other reference counts to be flushed > from the cache. > > These cache effects are huge, and they are growing all the time as CPU > speeds increase while RAM speeds remain relatively constant. I've thought about the cache issue with regards to the ref. counts before, actually, and initially, I also thought the exact same thing as you bring up here. However, there are a few things you need to remember: 1) SMP; counters are typically referenced by several different threads which may be running on different CPUs at any given point in time, and this means that we'll probably end up having corresponding cache lines invalidated back and forth anyway; 2) Using more cache lines may not be better overall, we may be doing write-backs of other data already there; in any case, we would really have to measure this; 3) By far the most important: all modifications to the ref. count are atomic, bus-locked, ops. I spoke to Peter a little about this and although I'm not 100% sure, we think that bus-locked fetch-inc/dec-stores need the bus anyway. If that's the case, then we really don't care about whether or not they get cached, right? > John > -- > John Polstra > John D. Polstra & Co., Inc. Seattle, Washington USA > "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa Thanks for the cool infos. and feedback. Regards, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 12 12:17:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52AC137B400 for ; Fri, 12 Jul 2002 12:17:50 -0700 (PDT) Received: from rerun.avayactc.com (rerun.avayactc.com [199.93.237.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80F5C43E42 for ; Fri, 12 Jul 2002 12:17:49 -0700 (PDT) (envelope-from mcambria@avaya.com) Received: by rerun.avayactc.com with Internet Mail Service (5.5.2653.19) id <3YWRQQXK>; Fri, 12 Jul 2002 15:17:46 -0400 Message-ID: <3A6D367EA1EFD4118C9B00A0C9DD99D7065A3E@rerun.avayactc.com> From: "Cambria, Mike" To: 'Jonathan Lemon' , "Cambria, Mike" Cc: cambria@world.std.com, "'freebsd-net@freebsd.org'" Subject: RE: xl checksum and dsniff Date: Fri, 12 Jul 2002 15:17:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > #define XL905B_CSUM_FEATURES 0 This worked. dsniff is behaving just fine now. Next I'll try to track down if this is this a libnet problem, libnids problem or dsniff problem, so I know which project I need to inform. Thanks, MikeC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 12 12:22:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40CCB37B400 for ; Fri, 12 Jul 2002 12:22:35 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37DC243E3B for ; Fri, 12 Jul 2002 12:22:34 -0700 (PDT) (envelope-from arr@watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.4/8.12.4) with ESMTP id g6CJMObL096216; Fri, 12 Jul 2002 15:22:24 -0400 (EDT) (envelope-from arr@watson.org) Received: from localhost (arr@localhost) by fledge.watson.org (8.12.4/8.12.4/Submit) with SMTP id g6CJMN55096213; Fri, 12 Jul 2002 15:22:24 -0400 (EDT) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Fri, 12 Jul 2002 15:22:23 -0400 (EDT) From: "Andrew R. Reiter" To: "Cambria, Mike" Cc: "'Jonathan Lemon'" , cambria@world.std.com, "'freebsd-net@freebsd.org'" Subject: RE: xl checksum and dsniff In-Reply-To: <3A6D367EA1EFD4118C9B00A0C9DD99D7065A3E@rerun.avayactc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 12 Jul 2002, Cambria, Mike wrote: : :> #define XL905B_CSUM_FEATURES 0 : :This worked. dsniff is behaving just fine now. : :Next I'll try to track down if this is this a libnet problem, libnids :problem or dsniff problem, so I know which project I need to inform. IIRC, the problem is BPF b/c it doesn't know the checksum since the calculation was offloaded, no? -- Andrew R. Reiter arr@watson.org arr@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 12 12:34: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37C3C37B400 for ; Fri, 12 Jul 2002 12:33:59 -0700 (PDT) Received: from rerun.avayactc.com (rerun.avayactc.com [199.93.237.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3ADFF43E75 for ; Fri, 12 Jul 2002 12:33:58 -0700 (PDT) (envelope-from mcambria@avaya.com) Received: by rerun.avayactc.com with Internet Mail Service (5.5.2653.19) id <3YWRQQXW>; Fri, 12 Jul 2002 15:33:55 -0400 Message-ID: <3A6D367EA1EFD4118C9B00A0C9DD99D7065A40@rerun.avayactc.com> From: "Cambria, Mike" To: "'Andrew R. Reiter'" , "Cambria, Mike" Cc: 'Jonathan Lemon' , "'freebsd-net@freebsd.org'" Subject: RE: xl checksum and dsniff Date: Fri, 12 Jul 2002 15:33:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > -----Original Message----- > From: Andrew R. Reiter [mailto:arr@watson.org] > :Next I'll try to track down if this is this a libnet problem, libnids > :problem or dsniff problem, so I know which project I need to inform. > > IIRC, the problem is BPF b/c it doesn't know the checksum since the > calculation was offloaded, no? Possibly, or perhaps libpcap? Now that I know checksum offload is indeed involved, I booted the original kernel and poked around. Using dsniff -c, dsniff was able to see packets received just fine. The half of the session sent is what dsniff can't track. Packets received, although tcpdump shows "bad checksum", are seen by dsniff just fine. I expected it to be the other way around. MikeC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 12 15:45: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A312A37B49A for ; Fri, 12 Jul 2002 15:44:38 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0981C4492F for ; Fri, 12 Jul 2002 15:31:32 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g6CLwZe26390; Fri, 12 Jul 2002 14:58:35 -0700 (PDT) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.4/8.12.4/Submit) id g6CLwZax009408; Fri, 12 Jul 2002 14:58:35 -0700 (PDT) (envelope-from jdp) Date: Fri, 12 Jul 2002 14:58:35 -0700 (PDT) Message-Id: <200207122158.g6CLwZax009408@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: bmilekic@unixdaemons.com Subject: Re: mbuf external buffer reference counters In-Reply-To: <20020712142021.A44645@unixdaemons.com> References: <20020711162026.A18717@unixdaemons.com> <200207121803.g6CI3je9008944@vashon.polstra.com> <20020712142021.A44645@unixdaemons.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <20020712142021.A44645@unixdaemons.com>, Bosko Milekic wrote: > > I've thought about the cache issue with regards to the ref. counts > before, actually, and initially, I also thought the exact same thing > as you bring up here. However, there are a few things you need to > remember: > > 1) SMP; counters are typically referenced by several different threads > which may be running on different CPUs at any given point in time, and > this means that we'll probably end up having corresponding cache lines > invalidated back and forth anyway; Agreed. The PII and newer CPUs do have some short cuts built in that mitigate this somewhat by doing direct cache-to-cache updates in the SMP case. But quantitatively I don't know how much that helps. > 2) Using more cache lines may not be better overall, we may be doing > write-backs of other data already there; in any case, we would really > have to measure this; The research that led to the slab allocator demonstrated pretty conclusively that, at least in general, it's better to spread out the usage across all cache lines rather than compete for just a few. Measurements trump research, though, as long as the measurements reflect real-world usage patterns. If you decide to pack the refcounts into the clusters themselves, it might be better to put the recount at the front of each cluster, and offset the packet data by 16 bytes to make room for it. That way, the reference count would be in the same cache line as the first part of the packet header -- a cache line which is almost certain to be accessed (though probably not dirtied) anyway. > 3) By far the most important: all modifications to the ref. count are > atomic, bus-locked, ops. I spoke to Peter a little about this and > although I'm not 100% sure, we think that bus-locked > fetch-inc/dec-stores need the bus anyway. If that's the case, > then we really don't care about whether or not they get cached, right? I'm afraid I don't know the answer to that. The majority of systems will be uniprocessor for a good long time, and I would hate to see their performance sacrificed needlessly. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 12 15:56:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E553837B400 for ; Fri, 12 Jul 2002 15:56:12 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0487843E42 for ; Fri, 12 Jul 2002 15:56:12 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id SAA04553; Fri, 12 Jul 2002 18:56:07 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g6CMtb043246; Fri, 12 Jul 2002 18:55:37 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15663.24169.445698.304534@grasshopper.cs.duke.edu> Date: Fri, 12 Jul 2002 18:55:37 -0400 (EDT) To: Julian Elischer Cc: Bosko Milekic , freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters In-Reply-To: References: <20020712122811.GA52803@hades.hell.gr> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Julian Elischer writes: > > > On Fri, 12 Jul 2002, Giorgos Keramidas wrote: > > > On 2002-07-12 07:45 +0000, Bosko Milekic wrote: > > > > > > So I guess that what we're dealing with isn't really a > > > "monodirectional" ring. Right? > > > > No it isn't. It looks more like the "dining philosophers" problem. > > But that problem's solution would require at least one mutex for every > > part of the ring :-( > > Te stuff under consideration originally came from OSF/1 which became > true-64 > > that was heavily SMP > can anyone find out what they did? From looking at a Tru64 5.1 header file, it looks like they do per-ext locking and declare an MBUF_EXT_LOCK(m) macro. It is not clear how one is supposed to use this & it appears to be undocumented. Tru64 also has a global mbuf lock. Tru64 4.x does not appear to have the MBUF_EXT_LOCK (so I think it uses just the global MBUF_LOCK for all mbuf manipulations; and I'll bet that just does a 'splimp' on UP systems). AIX also has this nice ext_refq structure and it also appears to be doing per-ext locking. From mbuf.h, AIX's ext mbufs are all just malloc'ed memory. This jives with the pain & suffering I had when writing an ethernet driver for AIX & finding mbuf's which cross page boundaries. MacOS-X seems to have both a refq and a refcnt array like in -stable. It appears to use the refq for externally managed data and the refcnt for system clusters. As for locking, it looks a lot like Tru64 4.x -- it has a global mbuf lock. Perhaps this is what the original Mach did? WRT to using refqs -- I think that Bosko's system in -current is just as nice from a user's perspective, and if we can work out an acceptable solution for doing refcnts, lets not revert to refqs. I agree with John about where to put the refcnts: I think we should have a big hunk of memory for the refcnts like in -stable. My understanding is that the larger virtually contig mbufs are the only thing that would cause a problem for this, or is that incorrect? If so, then why not just put their counter elsewhere? One concrete example against putting the refcnts into the cluster is that it would cause NFS servers & clients to use 25% more mbufs for a typical 8K read or write request. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 12 18:38: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85E2237B400 for ; Fri, 12 Jul 2002 18:38:05 -0700 (PDT) Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id C085D43E5E for ; Fri, 12 Jul 2002 18:38:04 -0700 (PDT) (envelope-from bmilekic@angelica.unixdaemons.com) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.5/8.12.1) with ESMTP id g6D1bc6M008230; Fri, 12 Jul 2002 21:37:38 -0400 (EDT) X-Authentication-Warning: angelica.unixdaemons.com: Host bmilekic@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.5/8.12.1/Submit) id g6D1bbA2008221; Fri, 12 Jul 2002 21:37:37 -0400 (EDT) (envelope-from bmilekic) Date: Fri, 12 Jul 2002 21:37:37 -0400 From: Bosko Milekic To: Andrew Gallatin Cc: Julian Elischer , freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters Message-ID: <20020712213737.A7548@unixdaemons.com> References: <20020712122811.GA52803@hades.hell.gr> <15663.24169.445698.304534@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <15663.24169.445698.304534@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Fri, Jul 12, 2002 at 06:55:37PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jul 12, 2002 at 06:55:37PM -0400, Andrew Gallatin wrote: [...] FWIW, BSD/OS also does similar to -STABLE. [...] > I agree with John about where to put the refcnts: I think we should > have a big hunk of memory for the refcnts like in -stable. My > understanding is that the larger virtually contig mbufs are the only > thing that would cause a problem for this, or is that incorrect? > If so, then why not just put their counter elsewhere? > > One concrete example against putting the refcnts into the cluster is > that it would cause NFS servers & clients to use 25% more mbufs for a > typical 8K read or write request. If we decide to allocate jumbo bufs from their own seperate map as well then we have no wastage for the counters for clusters if we keep them in a few pages, like in -STABLE, and it should all work out fine. For the jumbo bufs I still maintain that we should keep the counter for them at the end of the buf because the math works out (see my post in that thread with the math example) and because their total size is not a power of 2 anyway. They'll also be more randomly spread out and use more cache slots. > Drew Regards, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 12 19: 8:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B7E837B400 for ; Fri, 12 Jul 2002 19:08:40 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4CC343E42 for ; Fri, 12 Jul 2002 19:08:39 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id WAA07789; Fri, 12 Jul 2002 22:08:37 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g6D287n43440; Fri, 12 Jul 2002 22:08:07 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15663.35719.282690.983639@grasshopper.cs.duke.edu> Date: Fri, 12 Jul 2002 22:08:07 -0400 (EDT) To: Bosko Milekic Cc: Julian Elischer , freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters In-Reply-To: <20020712213737.A7548@unixdaemons.com> References: <20020712122811.GA52803@hades.hell.gr> <15663.24169.445698.304534@grasshopper.cs.duke.edu> <20020712213737.A7548@unixdaemons.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bosko Milekic writes: <...> > If we decide to allocate jumbo bufs from their own seperate map as > well then we have no wastage for the counters for clusters if we keep > them in a few pages, like in -STABLE, and it should all work out fine. That sounds good. > For the jumbo bufs I still maintain that we should keep the counter > for them at the end of the buf because the math works out (see my post > in that thread with the math example) and because their total size is > not a power of 2 anyway. They'll also be more randomly spread out and > use more cache slots. How about, as (I think it was) John suggested, putting the counters at the front of the buffer so they'd be close to the headers, etc in the cache and would be less likely to cause their own unique cache miss when you access them? Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 12 19:32:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DEA537B401 for ; Fri, 12 Jul 2002 19:32:52 -0700 (PDT) Received: from out013.verizon.net (out013pub.verizon.net [206.46.170.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85D5843E67 for ; Fri, 12 Jul 2002 19:32:51 -0700 (PDT) (envelope-from jimmcgra@bellatlantic.net) Received: from Default ([141.154.238.157]) by out013.verizon.net (InterMail vM.5.01.05.05 201-253-122-126-105-20020426) with SMTP id <20020713023252.UJZJ23523.out013.verizon.net@Default>; Fri, 12 Jul 2002 21:32:52 -0500 From: "Jim McGrath" To: "Andrew Gallatin" , "Julian Elischer" Cc: "Bosko Milekic" , Subject: RE: mbuf external buffer reference counters Date: Fri, 12 Jul 2002 22:32:50 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <15663.24169.445698.304534@grasshopper.cs.duke.edu> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Julian Elischer writes: > > > > > > Te stuff under consideration originally came from OSF/1 which became > > true-64 > > > > that was heavily SMP > > can anyone find out what they did? > > From looking at a Tru64 5.1 header file, it looks like they do per-ext > locking and declare an MBUF_EXT_LOCK(m) macro. It is not clear how > one is supposed to use this & it appears to be undocumented. Tru64 > also has a global mbuf lock. Tru64 4.x does not appear to have the > MBUF_EXT_LOCK (so I think it uses just the global MBUF_LOCK for all > mbuf manipulations; and I'll bet that just does a 'splimp' on UP > systems). > When I was at Hitachi in Watltham, MA. we did a port of OSF/1 to Hitachi's SR8000 Super. http://www.hitachi-eu.com/hel/hpcc/ It is based on a 64 bit implementation of the Power PC. My only involvement was with the Large File System. and I really don't remember how cluster bufs ref count was implemented. Most of the people who may have been involved are at Egenera, with the code somewhere at Hitachi in Japan. If you have any contact at either place, you might check with them. Jim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 13 0: 4:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 113F137B400; Sat, 13 Jul 2002 00:04:27 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A27A43E5E; Sat, 13 Jul 2002 00:04:26 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020713070425.GCNF24728.rwcrmhc51.attbi.com@blossom.cjclark.org>; Sat, 13 Jul 2002 07:04:25 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g6D74OJK049583; Sat, 13 Jul 2002 00:04:24 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g6D74NWA049582; Sat, 13 Jul 2002 00:04:23 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Sat, 13 Jul 2002 00:04:23 -0700 From: "Crist J. Clark" To: Julian Stacey Cc: freebsd-net@FreeBSD.ORG, Gary Jennejohn Subject: Re: Masquerade fails to suppress X-sender Message-ID: <20020713070423.GC48937@blossom.cjclark.org> Reply-To: "Crist J. Clark" References: <200207102330.g6ANUrV66462@flip.jhs.private> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200207102330.g6ANUrV66462@flip.jhs.private> User-Agent: Mutt/1.4i X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Jul 11, 2002 at 01:30:53AM +0200, Julian Stacey wrote: > Hi freebsd-net@freebsd.org > Since I gave my FreeBSD-4.5-Release gateway a new sendmail.cf today, > I've been getting both these in my headers: > Received: from jhs.muc.de (520006753247-0001@[217.235.121.155]) > by fmrl11.sul.t-online.com with esmtp id > 17SPs5-0MzVXEC; Thu, 11 Jul 2002 00:23:41 +0200 > X-sender: 520006753247-0001@t-dialin.net > I never used to have 520006753247 appear, (I've confirmed that by > inspecting my morning's post to a simple expoder list (that leaves > headers unchanged), which came back clean without any 520006753247) > ( Reason I don't want people to see 520006753247-0001 is that's my > account, & while not private as such, no need ot publicise, > & dont want people emailing me (or spamming!) there either ). > > So I'd like to kill off that number from appearing, any idea how to do it ? The '-f' option of sendmail(8) would do this. See also the "trusted user" options for your sendmail.mc. I am not aware of away to set up a fake user in the sendmail.{mc,cf} files, but that does not mean there isn't one. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 13 7:34:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B4E737B400 for ; Sat, 13 Jul 2002 07:34:32 -0700 (PDT) Received: from mail.speakeasy.net (mail17.speakeasy.net [216.254.0.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id E23D643E3B for ; Sat, 13 Jul 2002 07:34:31 -0700 (PDT) (envelope-from jerkart@speakeasy.net) Received: (qmail 14301 invoked from network); 13 Jul 2002 14:34:31 -0000 Received: from unknown (HELO jose.jerkart.net) ([216.254.115.11]) (envelope-sender ) by mail17.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 13 Jul 2002 14:34:31 -0000 Date: Sat, 13 Jul 2002 10:34:30 -0400 Subject: Re: ipsec + racoon + WatchGuard Firebox? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: freebsd-net@freebsd.org To: "James Satterfield" From: Jeremy Karteczka In-Reply-To: <002901c2296f$d98f6fc0$0feba8c0@sphynx> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org James, If I recall correctly WatchGuard boxes are weird in the fact that they must exchange keys in DES, then they can go up to 3DES. I don't have my documentation at home, but I was able to find this link to an example for OpenBSD. With a little manipulation you should be able to get going from this. http://www.rootprompt.net/openbsd_vpn.html Best regards, Jeremy Karteczka On Friday, July 12, 2002, at 02:46 AM, James Satterfield wrote: > Anyone have any success with creating a ipsec tunnel between a freebsd > gateway and a WatchGuard Firebox? It looks like I'm getting past > authentication. I can't tell if the tunnel is actually getting created, > but > I certainly cannot move traffic through it. > > James. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 13 14:15:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DB3637B401 for ; Sat, 13 Jul 2002 14:15:33 -0700 (PDT) Received: from kumquat.ixs1.net (usny58.ixs1.net [209.10.179.58]) by mx1.FreeBSD.org (Postfix) with SMTP id 08E3043E65 for ; Sat, 13 Jul 2002 14:15:32 -0700 (PDT) (envelope-from AcquireSolution.ue.h117320.y56528937@ixs2.net) From: AcquireSolution To: net@freebsd.org Subject: AcquireSolution requests your permission Date: Sat, 13 Jul 2002 17:03:45 -0400 X-Mailer: Zen Mailer (Bartmail 2.0) Message-ID: OM:AcquireSolution.ue.h117320.y56528937@ixs2.net Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="OMPH.56528937.1026594223819" Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. --OMPH.56528937.1026594223819 Content-Type: text/plain Dear Friend, Everyday more and more exciting and important information is being communicated via E-mail. In the future, we would like to communicate with you via E-mail, and send you exciting and "Up to Date" information on current subject matter, free e-commerce newsletters, case studiests, and services that Internet users like yourself would have interest in. We are presently seeking your permission for the privilege to serve you efficiently and electronically via E-Mail. Thank you! If you do not wish to have us contact you via e-mail, please click the "Unsubscribe" link within the message below and your name will be deleted from our email mailing lists. Sincerely, Acquire Solution Thank You for Reading. To unsubscribe to this publication, reply to this message and put "unsubscribe" in the subject line. You can also unsubscribe by clicking on this link: http://link.ixs2.net/s/link/unsub?rc=ue&rti=h117320&si=y56528937 If you can't click on the links in this message, copy the entire link and paste into the Location:/Address: field of your browser. --OMPH.56528937.1026594223819 Content-Type: text/html Acquire Solution


Dear Friend,

Everyday more and more exciting and important information is being communicated via E-mail. In the future, we would like to communicate with you via E-mail, and send you exciting and "Up to Date" information on current subject matter, free e-commerce newsletters, case studiests, and services that Internet users like yourself would have interest in. We are presently seeking your permission for the privilege to serve you efficiently and electronically via E-Mail.

Thank you!

If you do not wish to have us contact you via e-mail, please click the "Unsubscribe" link within the message below and your name will be deleted from our email mailing lists.


Sincerely,

Acquire Solution


Unsubscribe

--OMPH.56528937.1026594223819-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message