From owner-freebsd-net Sun Mar 2 12:15:42 2003 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 7151937B401; Sun, 2 Mar 2003 12:15:41 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4BFD43FBD; Sun, 2 Mar 2003 12:15:38 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h22KFbpI075588 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 2 Mar 2003 15:15:38 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.6/8.12.6/Submit) id h22KFbn0075585; Sun, 2 Mar 2003 15:15:37 -0500 (EST) (envelope-from wollman) Date: Sun, 2 Mar 2003 15:15:37 -0500 (EST) From: Garrett Wollman Message-Id: <200303022015.h22KFbn0075585@khavrinen.lcs.mit.edu> To: Ruslan Ermilov Cc: freebsd-net@FreeBSD.ORG Subject: Re: maxsockbuf is useless value {?|:-(} In-Reply-To: <20030301134118.GE77007@sunbay.com> References: <20030228130621.A16504@phantom.cris.net> <200302281931.h1SJVAUg060319@khavrinen.lcs.mit.edu> <20030301134118.GE77007@sunbay.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 < said: > Seriously, you didn't give any alternative. How does one > knows the maximum allowed limit? By just blindly trying? Ask for however much you think you actually need, and bleat to the administrator (or limp along) if you don't get it. Keep in mind that this is a security-sensitive parameter (a user can use up to `maxsockbuf' bytes of wired kernel memory for each file descriptor he is allowed to open). -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 2 13:33:25 2003 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 05E0F37B405 for ; Sun, 2 Mar 2003 13:33:24 -0800 (PST) Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06F8243FB1 for ; Sun, 2 Mar 2003 13:33:22 -0800 (PST) (envelope-from brunner@nic-naa.net) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.7/8.12.6) with ESMTP id h22LVgtY076746 for ; Sun, 2 Mar 2003 16:31:43 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200303022131.h22LVgtY076746@nic-naa.net> To: freebsd-net@FreeBSD.ORG Subject: IPFIREWALL, /dev/ipl and friends Date: Sun, 02 Mar 2003 16:31:42 -0500 From: Eric Brunner-Williams in Portland Maine 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, What is the mechanism in 5.0 for creating /dev/{ipauth,ipl,ipstate}? MAKEDEV isn't in /dev (via buildworld/installworld) MAKEDEV fails to create /dev/ipl. mknod (from MAKEDEV) fails to create /dev/ipl. I'm behind on reading -CURRENT, and -net (and -ipf), and pointers would be appreciated. Boxen are iXsystems, 2 CPU, 2 NIC (and very nice) Eric % diff WABANAKI GENERIC 25c25 < ident WABANAKI --- > ident GENERIC 68,79d67 < # Firewall < options IPFIREWALL #firewall < options IPFIREWALL_VERBOSE #enable logging to syslogd(8) < options IPFIREWALL_FORWARD #enable transparent proxy support < options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity < options IPFIREWALL_DEFAULT_TO_ACCEPT #use ipf to close, not open < < # Do not decrement the ttl, hide firewall from traceroute class tools < options IPSTEALTH #support for stealth forwarding < 1,82c69,70 < options SMP # Symmetric MultiProcessor Kernel < options APIC_IO # Symmetric (APIC) I/O TiA, Eric To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 2 14: 1:56 2003 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 A843A37B401 for ; Sun, 2 Mar 2003 14:01:55 -0800 (PST) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id C558F43FCB for ; Sun, 2 Mar 2003 14:01:54 -0800 (PST) (envelope-from DougB@freebsd.org) Received: from master.gorean.org (12-234-22-23.client.attbi.com[12.234.22.23]) by rwcrmhc53.attbi.com (rwcrmhc53) with SMTP id <20030302220154053001s1rse>; Sun, 2 Mar 2003 22:01:54 +0000 Date: Sun, 2 Mar 2003 14:01:53 -0800 (PST) From: Doug Barton To: Eric Brunner-Williams in Portland Maine Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPFIREWALL, /dev/ipl and friends In-Reply-To: <200303022131.h22LVgtY076746@nic-naa.net> Message-ID: <20030302135953.O579@znfgre.tberna.bet> References: <200303022131.h22LVgtY076746@nic-naa.net> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! 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, 2 Mar 2003, Eric Brunner-Williams in Portland Maine wrote: > What is the mechanism in 5.0 for creating /dev/{ipauth,ipl,ipstate}? A) This message is more appropriate for freebsd-current@freebsd.org. B) If you don't know why MAKEDEV is irrelevant in 5.0-current, you should probably reconsider your decision to use it. Sorry if that sounds harsh, but I would suggest at a minimum that you catch up on that reading you mentioned.... Doug -- This .signature sanitized for your protection To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 2 14:47:12 2003 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 1262337B401 for ; Sun, 2 Mar 2003 14:47:12 -0800 (PST) Received: from mel-rto2.wanadoo.fr (smtp-out-2.wanadoo.fr [193.252.19.254]) by mx1.FreeBSD.org (Postfix) with ESMTP id 281A743F93 for ; Sun, 2 Mar 2003 14:47:11 -0800 (PST) (envelope-from vjardin@wanadoo.fr) Received: from mel-rta10.wanadoo.fr (193.252.19.193) by mel-rto2.wanadoo.fr (6.7.015) id 3E0C33700297BBEC for net@freebsd.org; Sun, 2 Mar 2003 23:47:10 +0100 Received: from venus.vincentjardin.net (80.11.204.135) by mel-rta10.wanadoo.fr (6.7.015) id 3E26DAA601965420 for net@freebsd.org; Sun, 2 Mar 2003 23:47:10 +0100 Content-Type: text/plain; charset="us-ascii" From: Vincent Jardin To: net@freebsd.org Subject: [mpd] radius and dynamic bundles Date: Sun, 2 Mar 2003 23:47:10 +0100 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200303022347.10283.vjardin@wanadoo.fr> 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 1/ When Radius is used with mpd and the answer delay of the Radius server= is=20 high, how can some PAP or CHAP timeout be avoided ? 2/ mpd provides a command to create a bundle (new [-i ngX] ...), however = there=20 is no command in order to remove the bundles. Have you ever tried to add = this=20 feature ? Regards, Vincent To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 2 18:20:48 2003 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 A9E9237B401 for ; Sun, 2 Mar 2003 18:20:47 -0800 (PST) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id CABEA43FBF for ; Sun, 2 Mar 2003 18:20:46 -0800 (PST) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.7/8.12.7) with ESMTP id h232KjFr073847; Sun, 2 Mar 2003 21:20:45 -0500 (EST) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.7/8.12.7/Submit) id h232KjdD073846; Sun, 2 Mar 2003 21:20:45 -0500 (EST) (envelope-from barney) Date: Sun, 2 Mar 2003 21:20:45 -0500 From: Barney Wolff To: Eric Brunner-Williams in Portland Maine Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPFIREWALL, /dev/ipl and friends Message-ID: <20030303022045.GA73672@pit.databus.com> References: <200303022131.h22LVgtY076746@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303022131.h22LVgtY076746@nic-naa.net> User-Agent: Mutt/1.4i X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) 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, Mar 02, 2003 at 04:31:42PM -0500, Eric Brunner-Williams in Portland Maine wrote: > What is the mechanism in 5.0 for creating /dev/{ipauth,ipl,ipstate}? > > < # Firewall > < options IPFIREWALL #firewall > < options IPFIREWALL_VERBOSE #enable logging to syslogd(8) > < options IPFIREWALL_FORWARD #enable transparent proxy support > < options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity > < options IPFIREWALL_DEFAULT_TO_ACCEPT #use ipf to close, not open > < > < # Do not decrement the ttl, hide firewall from traceroute class tools > < options IPSTEALTH #support for stealth forwarding > < > 1,82c69,70 > < options SMP # Symmetric MultiProcessor Kernel > < options APIC_IO # Symmetric (APIC) I/O IPFIREWALL and friends are for ipfw, not ipfilter (except IPSTEALTH). 5.0 uses devfs and creates pseudo-devices as needed. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 3 1:46: 7 2003 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 1037A37B401 for ; Mon, 3 Mar 2003 01:46:06 -0800 (PST) Received: from jawa.at (inforum.at [213.229.17.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3406543FDF for ; Mon, 3 Mar 2003 01:46:04 -0800 (PST) (envelope-from mbretter@jawa.at) Received: from jawa.at (dings.jawa.at [192.168.200.60]) by jawa.at (8.12.6/8.12.6) with ESMTP id h239jx07079731; Mon, 3 Mar 2003 10:46:00 +0100 (CET) (envelope-from mbretter@jawa.at) Message-ID: <3E63245D.6040800@jawa.at> Date: Mon, 03 Mar 2003 10:46:05 +0100 From: Michael Bretterklieber Organization: JAWA Management Software GmbH User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.2.1) Gecko/20021130 X-Accept-Language: de, en MIME-Version: 1.0 To: Vincent Jardin Cc: net@FreeBSD.ORG Subject: Re: [mpd] radius and dynamic bundles References: <200303022347.10283.vjardin@wanadoo.fr> In-Reply-To: <200303022347.10283.vjardin@wanadoo.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,NOSPAM_INC,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 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, Vincent Jardin schrieb: > 1/ When Radius is used with mpd and the answer delay of the Radius server is > high, how can some PAP or CHAP timeout be avoided ? > you mean, that the client times out during authentication saying that the server didn't responded? A known issue is that mpd is blocked during RADIUS requests, the solution will be to change from rad_send_request(); to rad_init_send_request() and rad_continue_send_request(); to avoid blocking of mpd. I have this on my todo-list, but atm it has low prio. bye, -- ------------------------------- ---------------------------------- Michael Bretterklieber - Michael.Bretterklieber@jawa.at JAWA Management Software GmbH - http://www.jawa.at Liebenauer Hauptstr. 200 -------------- privat ------------ A-8041 GRAZ GSM: ++43-(0)676-84 03 15 712 Tel: ++43-(0)316-403274-12 E-mail: michael@bretterklieber.com Fax: ++43-(0)316-403274-10 http://www.bretterklieber.com ------------------------------- ---------------------------------- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 3 1:59:46 2003 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 52B2837B401 for ; Mon, 3 Mar 2003 01:59:41 -0800 (PST) Received: from netnews.NCTU.edu.tw (ccreader.nctu.edu.tw [140.113.54.119]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13B0043F3F for ; Mon, 3 Mar 2003 01:59:35 -0800 (PST) (envelope-from gslin@netnews.NCTU.edu.tw) Received: by netnews.NCTU.edu.tw (Postfix, from userid 1000) id 45E802D; Mon, 3 Mar 2003 17:59:13 +0800 (CST) Date: Mon, 3 Mar 2003 17:59:13 +0800 From: Gea-Suan Lin To: net@FreeBSD.ORG Subject: Re: [mpd] radius and dynamic bundles Message-ID: <20030303095913.GA52116@ccreader.nctu.edu.tw> References: <200303022347.10283.vjardin@wanadoo.fr> <3E63245D.6040800@jawa.at> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: <3E63245D.6040800@jawa.at> User-Agent: Mutt/1.5.3i 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 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=big5 Content-Disposition: inline I find the function rad_send_request() in /usr/src/lib/libradius/libradius.c will break the stack so that mpd gets segfault in FreeBSD 4.7-RELEASE-p3, but I can't figure out where it does. If somebody want the core file, I can mail him. I copied rad_send_request() into mpd's radius.c last week, and it worked fine. I attach my patch file in this mail. On Mon, Mar 03, 2003 at 10:46:05AM +0100, Michael Bretterklieber wrote: > Hi, > > Vincent Jardin schrieb: > >1/ When Radius is used with mpd and the answer delay of the Radius server > >is high, how can some PAP or CHAP timeout be avoided ? > > > you mean, that the client times out during authentication saying that > the server didn't responded? > > A known issue is that mpd is blocked during RADIUS requests, the > solution will be to change from rad_send_request(); to > rad_init_send_request() and rad_continue_send_request(); to avoid > blocking of mpd. > > I have this on my todo-list, but atm it has low prio. > > bye, -- * Gea-Suan Lin (public key: http://ccreader.nctu.edu.tw/~gslin/key.txt) * If you cannot convince them, confuse them. -- Harry S Truman --SUOF0GtieIMvvwua Content-Type: text/plain; charset=big5 Content-Disposition: attachment; filename="radius.c.diff" --- /usr/ports/net/mpd/work/mpd-3.12/src/radius.c Tue Feb 11 06:21:15 2003 +++ radius.c Mon Mar 3 17:48:47 2003 @@ -152,10 +152,10 @@ return 0; } -void RadiusInit(void) { +static void +RadiusInit(void) { struct radius *rad = &bund->radius; - if (rad->radh != NULL) rad_close(rad->radh); memset(rad, 0, sizeof(struct radius) - sizeof(struct radiusconf)); } @@ -209,6 +209,7 @@ if (rad_create_request(rad->radh, RAD_ACCESS_REQUEST) == -1) { Log(LG_RADIUS, ("[%s] RADIUS: rad_create_request: %s", lnk->name, rad_strerror(rad->radh))); + rad_close(rad->radh); return (RAD_NACK); } @@ -343,37 +344,86 @@ } } - switch (rad_send_request(rad->radh)) { + Log(LG_RADIUS, ("[%s] RADIUS: %s: XXX 1 name=%s passlen=%d challenge_size=%d chapid=%d auth_type=%d", lnk->name, function, name, passlen, challenge_size, chapid, auth_type)); - case RAD_ACCESS_ACCEPT: - rad->valid = 1; - Log(LG_RADIUS, ("[%s] RADIUS: %s: RAD_ACCESS_ACCEPT for user %s", lnk->name, function, name)); - break; + { + struct timeval timelimit; + struct timeval tv; + int fd; + int n; - case RAD_ACCESS_REJECT: - Log(LG_RADIUS, ("[%s] RADIUS: %s: RAD_ACCESS_REJECT for user %s", lnk->name, function, name)); - rad_close(rad->radh); - return(RAD_NACK); - break; + n = rad_init_send_request(rad->radh, &fd, &tv); - case -1: - Log(LG_RADIUS, ("[%s] RADIUS: %s: rad_send_request failed %s", lnk->name, - function, rad_strerror(rad->radh))); - return(RAD_NACK); - break; - default: - Log(LG_RADIUS, ("[%s] RADIUS: %s: rad_send_request: unexpected " - "return value %s", lnk->name, function, rad_strerror(rad->radh))); - rad_close(rad->radh); - return(RAD_NACK); + if (n != 0) + return n; + + gettimeofday(&timelimit, NULL); + timeradd(&tv, &timelimit, &timelimit); + + for ( ; ; ) { + fd_set readfds; + + FD_ZERO(&readfds); + FD_SET(fd, &readfds); + + n = select(fd + 1, &readfds, NULL, NULL, &tv); + + if (n == -1) + break; + + if (!FD_ISSET(fd, &readfds)) { + /* Compute a new timeout */ + gettimeofday(&tv, NULL); + timersub(&timelimit, &tv, &tv); + if (tv.tv_sec > 0 || (tv.tv_sec == 0 && tv.tv_usec > 0)) + /* Continue the select */ + continue; + } + + Log(LG_RADIUS, ("[%s] RADIUS: %s: XXX 1 %s Host:%s PeerIp: %s", lnk->name, function, name, host, peeripname)); + n = rad_continue_send_request(rad->radh, n, &fd, &tv); + Log(LG_RADIUS, ("[%s] RADIUS: %s: XXX 2 %s Host:%s PeerIp: %s", lnk->name, function, name, host, peeripname)); + + if (n != 0) + break; + + gettimeofday(&timelimit, NULL); + timeradd(&tv, &timelimit, &timelimit); } - // Remember authname - strncpy(rad->authname, name, AUTH_MAX_AUTHNAME); - res = RadiusGetParams(); - if (res == RAD_NACK) rad->valid = 0; - rad_close(rad->radh); - return(res); + switch (n) { + + case RAD_ACCESS_ACCEPT: + rad->valid = 1; + Log(LG_RADIUS, ("[%s] RADIUS: %s: RAD_ACCESS_ACCEPT for user %s", lnk->name, function, name)); + break; + + case RAD_ACCESS_REJECT: + Log(LG_RADIUS, ("[%s] RADIUS: %s: RAD_ACCESS_REJECT for user %s", lnk->name, function, name)); + rad_close(rad->radh); + return(RAD_NACK); + break; + + case -1: + Log(LG_RADIUS, ("[%s] RADIUS: %s: rad_send_request failed %s", lnk->name, + function, rad_strerror(rad->radh))); + return(RAD_NACK); + break; + + default: + Log(LG_RADIUS, ("[%s] RADIUS: %s: rad_send_request: unexpected " + "return value %s", lnk->name, function, rad_strerror(rad->radh))); + rad_close(rad->radh); + return(RAD_NACK); + } + } + + // Remember authname + strncpy(rad->authname, name, AUTH_MAX_AUTHNAME); + res = RadiusGetParams(); + if (res == RAD_NACK) rad->valid = 0; + rad_close(rad->radh); + return(res); } int --SUOF0GtieIMvvwua-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 3 3:31:25 2003 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 0817837B401 for ; Mon, 3 Mar 2003 03:31:24 -0800 (PST) Received: from cell.sick.ru (cell.sick.ru [195.91.162.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1E0343FBD for ; Mon, 3 Mar 2003 03:31:22 -0800 (PST) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.6/8.12.6) with ESMTP id h23BVDI0041317 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 3 Mar 2003 14:31:13 +0300 (MSK) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.6/8.12.6/Submit) id h23BVDaY041316; Mon, 3 Mar 2003 14:31:13 +0300 (MSK) Date: Mon, 3 Mar 2003 14:31:13 +0300 From: Gleb Smirnoff To: Vincent Jardin Cc: net@FreeBSD.ORG Subject: Re: [mpd] radius and dynamic bundles Message-ID: <20030303113113.GB41248@cell.sick.ru> References: <200303022347.10283.vjardin@wanadoo.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200303022347.10283.vjardin@wanadoo.fr> 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 Sun, Mar 02, 2003 at 11:47:10PM +0100, Vincent Jardin wrote: V> 2/ mpd provides a command to create a bundle (new [-i ngX] ...), however there V> is no command in order to remove the bundles. Have you ever tried to add this V> feature ? This feature is really needed. My current mpd configuration is 25 identical bundles, and 25 links. Even if there are only 2 connections, all 25 ng interfaces exists, and mpd has all 25 bundles in memory. In recent future may be I'll need to increase number ob bundles. It'll be nice if bundles will be created dynamically, when remote client opens a connection, and destroyed on connection close. If Archie will give a piece of advice or some directions how to implement this, that would help. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 3 4:37:11 2003 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 3027B37B401 for ; Mon, 3 Mar 2003 04:37:06 -0800 (PST) Received: from angelo.kcl.ac.uk (angelo.kcl.ac.uk [137.73.66.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 770A743FB1 for ; Mon, 3 Mar 2003 04:37:04 -0800 (PST) (envelope-from dev.dhas@kcl.ac.uk) Received: from ctr-Dev.kcl.ac.uk (EE077.eee.kcl.ac.uk [137.73.10.124]) by angelo.kcl.ac.uk with ESMTP id h23BnAvX027330 for ; Mon, 3 Mar 2003 11:49:18 GMT Message-Id: <5.2.0.9.0.20030303115628.00ad6d48@pop2.kcl.ac.uk> X-Sender: kkqd2740@pop2.kcl.ac.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 03 Mar 2003 11:57:32 +0000 To: net@freebsd.org From: Audsin Subject: Fragmentation Avoidance Code Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-MailScanner: Found to be clean 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 Respected Sir I am currently working in the fragmentation avoidance technique caused by the overhead introduced by MIP6. I am using FreeBSD 4.4 and Kame Snap. I have introduced some code in netinet6/ip6_output.c code and netinet6/in6_pcb.h and netinet/in_pcb.h so that length of the MIP6 extension header if present is taken into account, when calculation the ipoptlen() and hence frag is avoided. Below i am pasting the code to which i have made changes. The lines starting with @ symbol shows the code introduced by me. Please go thru the code and let me know whether this takes account of the Extension header length introduced by MIP6. Since, this is my first research project, i kindly request you to go thru the code and help me. I have explained my code under the heading "Implementation" in the last ie. after the codes Please let me know, whether this code will take into account the length occupied by MIP6 Ext header. If any changes is required pls let me know. Thanks and sorry for the disturbance Code ----- netinet6/in6_pcb.h and netinet/in_pcb.h --------------------------------------- @ #ifdef MIP6 @ #include @ #include @ #include @ #include @ #endif /* MIP6 */ . . . struct in6pcb ( . . . struct ip6_pktopts *in6p_outputopts; /* IP6 options for outgoing packets */ @ #ifdef MIP6 @ struct mip6_pktopts *mip6_outputopts /* MIP6 options for outgoing packets */ @ #endif . . . ); netinet6/ip6_output.c ---------------------- In the last part of netinet6/ip6_output.c I have changed the code and pasted it under Modified code Modified Code: ----------------- /* * Compute IPv6 and MIP6 extension header length. */ #ifdef HAVE_NRL_INPCB # define in6pcb inpcb # define in6p_outputopts inp_outputopts6 #endif int ip6_optlen(in6p) struct in6pcb *in6p; { int len; @ if (!(in6p->in6p_outputopts || @ #ifdef MIP6 @ in6p->mip6_outputopts @ #endif @ )) @ return 0; len = 0; #define elen(x) \ (((struct ip6_ext *)(x)) ? (((struct ip6_ext *)(x))->ip6e_len + 1) << 3 : 0) len += elen(in6p->in6p_outputopts->ip6po_hbh); if (in6p->in6p_outputopts->ip6po_rthdr) /* dest1 is valid with rthdr only */ len += elen(in6p->in6p_outputopts->ip6po_dest1); len += elen(in6p->in6p_outputopts->ip6po_rthdr); len += elen(in6p->in6p_outputopts->ip6po_dest2); @ #ifdef MIP6 @ len += elen(in6p->mip6_outputopts->mip6po_rthdr);/* MIP6 Routing Header */ @ len += elen(in6p->mip6_outputopts->mip6po_haddr);/* MIP6 Home Addr Option */ @ len += elen(in6p->mip6_outputopts->mip6_dest2); /* MIP6 Dest2 Option */ @ #endif return len; #undef elen } #ifdef HAVE_NRL_INPCB # undef in6pcb # undef in6p_outputopts #endif Original netinet6/ip6_output.c kame Code ------------------------------ /* * Compute IPv6 extension header length. */ #ifdef HAVE_NRL_INPCB # define in6pcb inpcb # define in6p_outputopts inp_outputopts6 #endif int ip6_optlen(in6p) struct in6pcb *in6p; { int len; if (!in6p->in6p_outputopts) return 0; len = 0; #define elen(x) \ (((struct ip6_ext *)(x)) ? (((struct ip6_ext *)(x))->ip6e_len + 1) << 3 : 0) len += elen(in6p->in6p_outputopts->ip6po_hbh); if (in6p->in6p_outputopts->ip6po_rthdr) /* dest1 is valid with rthdr only */ len += elen(in6p->in6p_outputopts->ip6po_dest1); len += elen(in6p->in6p_outputopts->ip6po_rthdr); len += elen(in6p->in6p_outputopts->ip6po_dest2); return len; #undef elen } #ifdef HAVE_NRL_INPCB # undef in6pcb # undef in6p_outputopts #endif Implementation ---------------- 1)netinet6/in6_pcb.h and netinet/in_pcb.h Create a pointer to struct mip6_pktopts, if MIP6 is defined and name the pointer as *mip6_outputopts @ #ifdef MIP6 @ struct mip6_pktopts *mip6_outputopts /* MIP6 options for outgoing packets */ @ #endif 2) netinet6/ip6_output.c Modify the code of macro elen(x) present in function ip6_optlen(in6p) in netinet6/ip6_output.c such that it takes into account, the length occupied by Mip6 Extension headers @ #ifdef MIP6 @ len += elen(in6p->mip6_outputopts->mip6po_rthdr);/* MIP6 Routing Header */ @ len += elen(in6p->mip6_outputopts->mip6po_haddr);/* MIP6 Home Addr Option */ @ len += elen(in6p->mip6_outputopts->mip6_dest2); /* MIP6 Dest2 Option */ @ #endif Regards Dev To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 3 4:55:15 2003 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 155E737B401 for ; Mon, 3 Mar 2003 04:55:09 -0800 (PST) Received: from angelo.kcl.ac.uk (angelo.kcl.ac.uk [137.73.66.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51E9243FCB for ; Mon, 3 Mar 2003 04:55:08 -0800 (PST) (envelope-from dev.dhas@kcl.ac.uk) Received: from ctr-Dev.kcl.ac.uk (EE077.eee.kcl.ac.uk [137.73.10.124]) by angelo.kcl.ac.uk with ESMTP id h23CAcvX013492 for ; Mon, 3 Mar 2003 12:10:48 GMT Message-Id: <5.2.0.9.0.20030303121813.00ad7530@pop2.kcl.ac.uk> X-Sender: kkqd2740@pop2.kcl.ac.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 03 Mar 2003 12:19:00 +0000 To: freebsd-net@freebsd.org From: Audsin Subject: Fragmentation Avoidance Code Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-MailScanner: Found to be clean 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 Respected Sir I am currently working in the fragmentation avoidance technique caused by the overhead introduced by MIP6. I am using FreeBSD 4.4 and Kame Snap. I have introduced some code in netinet6/ip6_output.c code and netinet6/in6_pcb.h and netinet/in_pcb.h so that length of the MIP6 extension header if present is taken into account, when calculation the ipoptlen() and hence frag is avoided. Below i am pasting the code to which i have made changes. The lines starting with @ symbol shows the code introduced by me. Please go thru the code and let me know whether this takes account of the Extension header length introduced by MIP6. Since, this is my first research project, i kindly request you to go thru the code and help me. I have explained my code under the heading "Implementation" in the last ie. after the codes Please let me know, whether this code will take into account the length occupied by MIP6 Ext header. If any changes is required pls let me know. Thanks and sorry for the disturbance Code ----- netinet6/in6_pcb.h and netinet/in_pcb.h --------------------------------------- @ #ifdef MIP6 @ #include @ #include @ #include @ #include @ #endif /* MIP6 */ . . . struct in6pcb ( . . . struct ip6_pktopts *in6p_outputopts; /* IP6 options for outgoing packets */ @ #ifdef MIP6 @ struct mip6_pktopts *mip6_outputopts /* MIP6 options for outgoing packets */ @ #endif . . . ); netinet6/ip6_output.c ---------------------- In the last part of netinet6/ip6_output.c I have changed the code and pasted it under Modified code Modified Code: ----------------- /* * Compute IPv6 and MIP6 extension header length. */ #ifdef HAVE_NRL_INPCB # define in6pcb inpcb # define in6p_outputopts inp_outputopts6 #endif int ip6_optlen(in6p) struct in6pcb *in6p; { int len; @ if (!(in6p->in6p_outputopts || @ #ifdef MIP6 @ in6p->mip6_outputopts @ #endif @ )) @ return 0; len = 0; #define elen(x) \ (((struct ip6_ext *)(x)) ? (((struct ip6_ext *)(x))->ip6e_len + 1) << 3 : 0) len += elen(in6p->in6p_outputopts->ip6po_hbh); if (in6p->in6p_outputopts->ip6po_rthdr) /* dest1 is valid with rthdr only */ len += elen(in6p->in6p_outputopts->ip6po_dest1); len += elen(in6p->in6p_outputopts->ip6po_rthdr); len += elen(in6p->in6p_outputopts->ip6po_dest2); @ #ifdef MIP6 @ len += elen(in6p->mip6_outputopts->mip6po_rthdr);/* MIP6 Routing Header */ @ len += elen(in6p->mip6_outputopts->mip6po_haddr);/* MIP6 Home Addr Option */ @ len += elen(in6p->mip6_outputopts->mip6_dest2); /* MIP6 Dest2 Option */ @ #endif return len; #undef elen } #ifdef HAVE_NRL_INPCB # undef in6pcb # undef in6p_outputopts #endif Original netinet6/ip6_output.c kame Code ------------------------------ /* * Compute IPv6 extension header length. */ #ifdef HAVE_NRL_INPCB # define in6pcb inpcb # define in6p_outputopts inp_outputopts6 #endif int ip6_optlen(in6p) struct in6pcb *in6p; { int len; if (!in6p->in6p_outputopts) return 0; len = 0; #define elen(x) \ (((struct ip6_ext *)(x)) ? (((struct ip6_ext *)(x))->ip6e_len + 1) << 3 : 0) len += elen(in6p->in6p_outputopts->ip6po_hbh); if (in6p->in6p_outputopts->ip6po_rthdr) /* dest1 is valid with rthdr only */ len += elen(in6p->in6p_outputopts->ip6po_dest1); len += elen(in6p->in6p_outputopts->ip6po_rthdr); len += elen(in6p->in6p_outputopts->ip6po_dest2); return len; #undef elen } #ifdef HAVE_NRL_INPCB # undef in6pcb # undef in6p_outputopts #endif Implementation ---------------- 1)netinet6/in6_pcb.h and netinet/in_pcb.h Create a pointer to struct mip6_pktopts, if MIP6 is defined and name the pointer as *mip6_outputopts @ #ifdef MIP6 @ struct mip6_pktopts *mip6_outputopts /* MIP6 options for outgoing packets */ @ #endif 2) netinet6/ip6_output.c Modify the code of macro elen(x) present in function ip6_optlen(in6p) in netinet6/ip6_output.c such that it takes into account, the length occupied by Mip6 Extension headers @ #ifdef MIP6 @ len += elen(in6p->mip6_outputopts->mip6po_rthdr);/* MIP6 Routing Header */ @ len += elen(in6p->mip6_outputopts->mip6po_haddr);/* MIP6 Home Addr Option */ @ len += elen(in6p->mip6_outputopts->mip6_dest2); /* MIP6 Dest2 Option */ @ #endif Regards Dev To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 3 5: 3:27 2003 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 8E79E37B401 for ; Mon, 3 Mar 2003 05:03:21 -0800 (PST) Received: from mx1.dev.itouchnet.net (devco.net [196.15.188.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEC7443FAF for ; Mon, 3 Mar 2003 05:03:17 -0800 (PST) (envelope-from bvi@itouchlabs.com) Received: from nobody by mx1.dev.itouchnet.net with scanned_ok (Exim 3.35 #1) id 18ppbv-000HgW-00 for net@freebsd.org; Mon, 03 Mar 2003 15:04:03 +0200 Received: from devco.net ([196.15.188.2] helo=Beastie) by mx1.dev.itouchnet.net with esmtp (Exim 3.35 #1) id 18ppbu-000HgN-00; Mon, 03 Mar 2003 15:04:02 +0200 Message-ID: <004001c2e184$bfcb4e60$4508a8c0@Beastie> From: "Barry Irwin" To: , "Audsin" References: <5.2.0.9.0.20030303115628.00ad6d48@pop2.kcl.ac.uk> Subject: Re: Fragmentation Avoidance Code Date: Mon, 3 Mar 2003 14:59:34 +0200 Organization: iTouch Labs 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.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Checked: This message has been scanned for any virusses and unauthorized attachments. X-iScan-ID: 67978-1046696643-24023@unconfigured version $Name: REL_2_0_4 $ 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 While I cant really comment on your code as such, another place this kind of action would be useful would be for IPSEC processing. More often than not, the IPSEC headder bumps the packet size over the limit and so fragmentation occurs, particularly where the IPSEC is being handled by a gatewway box. Barry -- Barry Irwin bvi@itouchlabs.com Tel: +27214875178 Systems Administrator: Networks And Security iTouch TAS http://www.itouchlabs.com Mobile: +27824457210 ----- Original Message ----- From: "Audsin" To: Sent: Monday, March 03, 2003 1:57 PM Subject: Fragmentation Avoidance Code > Respected Sir > > I am currently working in the fragmentation avoidance technique caused by > the overhead introduced by MIP6. I am using FreeBSD 4.4 and Kame Snap. > I have introduced some code in netinet6/ip6_output.c code and > netinet6/in6_pcb.h and netinet/in_pcb.h so that length of the MIP6 > extension header if present is taken into account, when calculation the > ipoptlen() and hence frag is avoided. Below i am pasting the code to which > i have made changes. The lines starting with @ symbol shows the code > introduced by me. Please go thru the code and let me know whether this > takes account of the Extension header length introduced by MIP6. Since, > this is my first research project, i kindly request you to go thru the code > and help me. > I have explained my code under the heading "Implementation" in the last ie. > after the codes > > > Please let me know, whether this code will take into account the length > occupied by MIP6 Ext header. If any changes is required pls let me know. > > Thanks and sorry for the disturbance > > Code > ----- > > netinet6/in6_pcb.h and netinet/in_pcb.h > --------------------------------------- > > @ #ifdef MIP6 > @ #include > @ #include > @ #include > @ #include > @ #endif /* MIP6 */ > > . > . > . > > struct in6pcb ( > . > . > . > struct ip6_pktopts *in6p_outputopts; /* IP6 options for outgoing packets */ > > @ #ifdef MIP6 > @ struct mip6_pktopts *mip6_outputopts /* MIP6 options for outgoing > packets */ > @ #endif > . > . > . > > ); > > > > netinet6/ip6_output.c > ---------------------- > > In the last part of netinet6/ip6_output.c I have changed the code and > pasted it under Modified code > > > Modified Code: > ----------------- > > > /* > * Compute IPv6 and MIP6 extension header length. > */ > #ifdef HAVE_NRL_INPCB > # define in6pcb inpcb > # define in6p_outputopts inp_outputopts6 > #endif > int > ip6_optlen(in6p) > struct in6pcb *in6p; > { > int len; > > @ if (!(in6p->in6p_outputopts || > @ #ifdef MIP6 > @ in6p->mip6_outputopts > @ #endif > @ )) > @ return 0; > > len = 0; > #define elen(x) \ > (((struct ip6_ext *)(x)) ? (((struct ip6_ext *)(x))->ip6e_len + 1) << > 3 : 0) > > len += elen(in6p->in6p_outputopts->ip6po_hbh); > if (in6p->in6p_outputopts->ip6po_rthdr) > /* dest1 is valid with rthdr only */ > len += elen(in6p->in6p_outputopts->ip6po_dest1); > len += elen(in6p->in6p_outputopts->ip6po_rthdr); > len += elen(in6p->in6p_outputopts->ip6po_dest2); > > @ #ifdef MIP6 > > @ len += elen(in6p->mip6_outputopts->mip6po_rthdr);/* MIP6 Routing Header */ > > @ len += elen(in6p->mip6_outputopts->mip6po_haddr);/* MIP6 Home Addr > Option */ > > @ len += elen(in6p->mip6_outputopts->mip6_dest2); /* MIP6 Dest2 Option */ > > @ #endif > return len; > #undef elen > } > #ifdef HAVE_NRL_INPCB > # undef in6pcb > # undef in6p_outputopts > #endif > > > > > Original netinet6/ip6_output.c kame Code > ------------------------------ > > /* > * Compute IPv6 extension header length. > */ > #ifdef HAVE_NRL_INPCB > # define in6pcb inpcb > # define in6p_outputopts inp_outputopts6 > #endif > int > ip6_optlen(in6p) > struct in6pcb *in6p; > { > int len; > > if (!in6p->in6p_outputopts) > return 0; > > len = 0; > #define elen(x) \ > (((struct ip6_ext *)(x)) ? (((struct ip6_ext *)(x))->ip6e_len + 1) << > 3 : 0) > > len += elen(in6p->in6p_outputopts->ip6po_hbh); > if (in6p->in6p_outputopts->ip6po_rthdr) > /* dest1 is valid with rthdr only */ > len += elen(in6p->in6p_outputopts->ip6po_dest1); > len += elen(in6p->in6p_outputopts->ip6po_rthdr); > len += elen(in6p->in6p_outputopts->ip6po_dest2); > return len; > #undef elen > } > #ifdef HAVE_NRL_INPCB > # undef in6pcb > # undef in6p_outputopts > #endif > > Implementation > ---------------- > > 1)netinet6/in6_pcb.h and netinet/in_pcb.h > > Create a pointer to struct mip6_pktopts, if MIP6 is defined and name the > pointer as *mip6_outputopts > > @ #ifdef MIP6 > @ struct mip6_pktopts *mip6_outputopts /* MIP6 options for outgoing > packets */ > @ #endif > > 2) netinet6/ip6_output.c > > Modify the code of macro elen(x) present in function ip6_optlen(in6p) in > netinet6/ip6_output.c such that it takes into account, the length occupied > by Mip6 Extension headers > > @ #ifdef MIP6 > > @ len += elen(in6p->mip6_outputopts->mip6po_rthdr);/* MIP6 Routing Header */ > > @ len += elen(in6p->mip6_outputopts->mip6po_haddr);/* MIP6 Home Addr > Option */ > > @ len += elen(in6p->mip6_outputopts->mip6_dest2); /* MIP6 Dest2 Option */ > > @ #endif > > > Regards > Dev > > > > 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 Mar 3 6:57:22 2003 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 60B0A37B401 for ; Mon, 3 Mar 2003 06:57:18 -0800 (PST) Received: from mails.tsinghua.edu.cn (mails.tsinghua.edu.cn [166.111.8.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1412943F75 for ; Mon, 3 Mar 2003 06:57:17 -0800 (PST) (envelope-from lguohan00@mails.tsinghua.edu.cn) Received: (eyou send program); Mon, 03 Mar 2003 22:46:19 +0800 Received: from unknown (HELO garfield) (unknown@210.25.128.102) by 166.111.8.16 with SMTP; Mon, 03 Mar 2003 22:46:19 +0800 Message-ID: <007501c2e193$e67589e0$668019d2@garfield> From: "Lu Guohan" To: Subject: The inflated snd_cwnd doesn't get retracted after TCP recovered from multiple losses (4.5-RELEASE) Date: Mon, 3 Mar 2003 22:48:06 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 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 aGVsbG8sDQogICAgSSBhbSBuZXcgdG8gaGVhciwgYW5kIEkgYW0gbm90IHN1cmUgaWYgYW55b25l IHBvc3QgdGhpcyBwcm9ibGVtIGJlZm9yZS4gQW5kIEkgYW0gZmlndXJpbmcgb3V0IHRoZSB3YXkg dG8gcG9zdCB0aGlzIHByb2JsZW0gYnkgUFIgc2luY2UgdGhlIHdlYiBpbnRlcmZhY2UgaXMgbm90 IGF2YWlhYmxlIHJpZ2h0IG5vdy4NCg0KRGVzY3JpcHRpb246DQogICAgV2hlbiBUQ1Agc2VuZGVy IHJlY2VpdmVzIHdpbmRvdyB1cGRhdGUgYWNrIGR1cmluZyBsb3NzIHJlY292ZXJ5LCB0aGUgaW5m bGF0ZWQgdHAtPnNuZF9jd25kIGRvZXNuJ3QgZ2V0IHJldHJhY3RlZCBhZnRlciBUQ1AgcmVjb3Zl cmVkIGZyb20gbXVsdGlwbGUgbG9zc2VzLg0KICAgIEZvciBleGFtcGxlLCBzdXBwb3NlIHRoZSAy MHRoLDIxdGggcGFja2V0cyBhcmUgbG9zdC4gVGhlIHNlbmRlciB0aGVuIHJlY2VpdmVzIGR1cCBh Y2tzIGZvciB0aGUgMjB0aCBwYWNrZXQgYW5kIHJldHJhbm1pdHMgaXQuIExhdGVyLCByZWNlaXZl ZCBkdXAgYWNrcyB3aWxsIG1ha2UgdGhlIHNlbmRlciB0byBpbmZsYXRlIGl0cyB0cC0+c25kX2N3 bmQuIFRoZW4gdGhlIGFjayBmb3IgdGhlIDIxdGggcGFja2V0IGFycml2ZXMsIGFuZCB0aGUgc2Vu ZGVyIHJldHJhbnNtaXRzIGl0LiBJZiB0aGUgdGgtPnRoX3dpbiBvZiB0aGlzIGFjayBwYWNrZXQg aXMgbGVzcyB0aGFuIHRoZSBtYXhpbXVtIHZhbHVlKGxpa2VseSksIHRoZSBzZW5kZXIgd2lsbCBy ZWNlaXZlIGFuIHdpbmRvdyB1cGRhdGUgYWNrIHZlcnkgc29vbi4gVGhpcyBhY2sgd2lsbCBtYWtl IHRwLT50X2R1cGFja3MgPSAwLiBOb3csIG5ldyBhY2tzIHRoYXQgYnJpbmcgVENQIG91dCBvZiBs b3NzIHJlY292ZXJ5IHdpbGwga2VlcCB0cC0+c25kX2N3bmQgYXMgdGhlIGluZmxhdGVkIHZhbHVl LCBub3QgdGhlIHZhbHVlIHJlcXVpcmVkIGJ5IFJGQzI1ODEuDQogICAgQmVsb3cgaXMgdGhlIHRy YWNlLCBib3RoIHRoZSBzZW5kZXIgYW5kIHRoZSByZWNlaXZlciBydW4gZnJlZWJzZCA0LjUtUkVM RUFTRS4gSSBoYXZlIG1hbnkgdHJhY2VzIG9mIHRoaXMga2luZCwgaXQgb2NjdXJzIGZyZXF1ZW50 bHkuIFRoaXMgbWF5IGV2ZW4gaGF2ZSBzZWN1cml0eSBwcm9ibGVtLiBJIGFtIG5vdCBzdXJlIGlm IHRoaXMgYnVnIGlzIGZpeGVkIGluIGxhdGVyIHZlcnNpb25zLg0KDQpUcmFjZXM6DQoNCnBhY2tl dCA5NjI5MjE6OTY0MzY5KDE0NDgpIGFuZCA5NjU4MTc6OTY3MjY1KDE0NDgpIGFyZSBsb3N0Lg0K DQowMDI2MzAgb3Jzb24uLjIzOTggPiByb3kuLmZ0cC1kYXRhOiAuIGFjayA5NjI5MjEgd2luIDMw NDA4IDxub3Asbm9wLHRpbWVzdGFtcCAyMTE5Mjc2MiAxNTc2Njc4OTc+IChERikNCjAwMDAyNCBy b3kuLmZ0cC1kYXRhID4gb3Jzb24uLjIzOTg6IC4gOTc4ODQ5Ojk4MDI5NygxNDQ4KSBhY2sgMSB3 aW4gMzMzMDQgPG5vcCxub3AsdGltZXN0YW1wIDE1NzY2NzkzMiAyMTE5Mjc2Mj4gKERGKQ0KMDAw MDEyIHJveS4uZnRwLWRhdGEgPiBvcnNvbi4uMjM5ODogLiA5ODAyOTc6OTgxNzQ1KDE0NDgpIGFj ayAxIHdpbiAzMzMwNCA8bm9wLG5vcCx0aW1lc3RhbXAgMTU3NjY3OTMyIDIxMTkyNzYyPiAoREYp DQowMDI3Mjkgb3Jzb24uLjIzOTggPiByb3kuLmZ0cC1kYXRhOiAuIGFjayA5NjI5MjEgd2luIDMx ODU2IDxub3Asbm9wLHRpbWVzdGFtcCAyMTE5Mjc2MiAxNTc2Njc4OTc+IChERikNCjAwMjY3NCBv cnNvbi4uMjM5OCA+IHJveS4uZnRwLWRhdGE6IC4gYWNrIDk2MjkyMSB3aW4gMzE4NTYgPG5vcCxu b3AsdGltZXN0YW1wIDIxMTkyNzYyIDE1NzY2Nzg5Nz4gKERGKQ0KMDAwNzkxIG9yc29uLi4yMzk4 ID4gcm95Li5mdHAtZGF0YTogLiBhY2sgOTYyOTIxIHdpbiAzMTg1NiA8bm9wLG5vcCx0aW1lc3Rh bXAgMjExOTI3NjMgMTU3NjY3ODk3PiAoREYpDQowMDE1NTUgb3Jzb24uLjIzOTggPiByb3kuLmZ0 cC1kYXRhOiAuIGFjayA5NjI5MjEgd2luIDMxODU2IDxub3Asbm9wLHRpbWVzdGFtcCAyMTE5Mjc2 MyAxNTc2Njc4OTc+IChERikNCjAwMDAxOSByb3kuLmZ0cC1kYXRhID4gb3Jzb24uLjIzOTg6IC4g OTYyOTIxOjk2NDM2OSgxNDQ4KSBhY2sgMSB3aW4gMzMzMDQgPG5vcCxub3AsdGltZXN0YW1wIDE1 NzY2NzkzMyAyMTE5Mjc2Mz4gKERGKQ0Kfn5+fn5+fn5+fn5+fn5+fnJldHJhbnNtaXQgZmlyc3Qg cGFja2V0DQoNCjAwMzIwNyBvcnNvbi4uMjM5OCA+IHJveS4uZnRwLWRhdGE6IC4gYWNrIDk2Mjky MSB3aW4gMzE4NTYgPG5vcCxub3AsdGltZXN0YW1wIDIxMTkyNzYzIDE1NzY2Nzg5Nz4gKERGKQ0K MDAyMDMyIG9yc29uLi4yMzk4ID4gcm95Li5mdHAtZGF0YTogLiBhY2sgOTYyOTIxIHdpbiAzMTg1 NiA8bm9wLG5vcCx0aW1lc3RhbXAgMjExOTI3NjMgMTU3NjY3ODk3PiAoREYpDQowMDA3MjMgb3Jz b24uLjIzOTggPiByb3kuLmZ0cC1kYXRhOiAuIGFjayA5NjI5MjEgd2luIDMxODU2IDxub3Asbm9w LHRpbWVzdGFtcCAyMTE5Mjc2MyAxNTc2Njc4OTc+IChERikNCjAwMDMwNyBvcnNvbi4uMjM5OCA+ IHJveS4uZnRwLWRhdGE6IC4gYWNrIDk2MjkyMSB3aW4gMzE4NTYgPG5vcCxub3AsdGltZXN0YW1w IDIxMTkyNzYzIDE1NzY2Nzg5Nz4gKERGKQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0gd2luZG93IGlu ZmxhdGluZw0KMzQ3NjExIG9yc29uLi4yMzk4ID4gcm95Li5mdHAtZGF0YTogLiBhY2sgOTYyOTIx IHdpbiAzMTg1NiA8bm9wLG5vcCx0aW1lc3RhbXAgMjExOTI3OTYgMTU3NjY3ODk3PiAoREYpDQow MDAwMTkgcm95Li5mdHAtZGF0YSA+IG9yc29uLi4yMzk4OiAuIDk4MTc0NTo5ODMxOTMoMTQ0OCkg YWNrIDEgd2luIDMzMzA0IDxub3Asbm9wLHRpbWVzdGFtcCAxNTc2Njc5NjggMjExOTI3OTY+IChE RikNCjAwMjY3NSBvcnNvbi4uMjM5OCA+IHJveS4uZnRwLWRhdGE6IC4gYWNrIDk2MjkyMSB3aW4g MzE4NTYgPG5vcCxub3AsdGltZXN0YW1wIDIxMTkyNzk2IDE1NzY2Nzg5Nz4gKERGKQ0KMDAwMDE3 IHJveS4uZnRwLWRhdGEgPiBvcnNvbi4uMjM5ODogLiA5ODMxOTM6OTg0NjQxKDE0NDgpIGFjayAx IHdpbiAzMzMwNCA8bm9wLG5vcCx0aW1lc3RhbXAgMTU3NjY3OTY4IDIxMTkyNzk2PiAoREYpDQow MDE0Njggb3Jzb24uLjIzOTggPiByb3kuLmZ0cC1kYXRhOiAuIGFjayA5NjI5MjEgd2luIDMxODU2 IDxub3Asbm9wLHRpbWVzdGFtcCAyMTE5Mjc5NiAxNTc2Njc4OTc+IChERikNCjAwMDAxOCByb3ku LmZ0cC1kYXRhID4gb3Jzb24uLjIzOTg6IC4gOTg0NjQxOjk4NjA4OSgxNDQ4KSBhY2sgMSB3aW4g MzMzMDQgPG5vcCxub3AsdGltZXN0YW1wIDE1NzY2Nzk2OCAyMTE5Mjc5Nj4gKERGKQ0Kfn5+fn5+ fn5+fn5+fn5+fn5+fn5gDQoNCg0KMDA2MjQ4IG9yc29uLi4yMzk4ID4gcm95Li5mdHAtZGF0YTog LiBhY2sgOTY1ODE3IHdpbiAyODk2MCA8bm9wLG5vcCx0aW1lc3RhbXAgMjExOTI3OTcgMTU3NjY3 OTMzPiAoREYpDQowMDAwMTkgcm95Li5mdHAtZGF0YSA+IG9yc29uLi4yMzk4OiAuIDk2NTgxNzo5 NjcyNjUoMTQ0OCkgYWNrIDEgd2luIDMzMzA0IDxub3Asbm9wLHRpbWVzdGFtcCAxNTc2Njc5Njkg MjExOTI3OTc+IChERikNCn5+fn5+fn5+fn5+fn5+fn5yZXRyYW5zbWl0IHRoZSBzZWNvbmQgcGFj a2V0DQowMDAwMTYgcm95Li5mdHAtZGF0YSA+IG9yc29uLi4yMzk4OiAuIDk4NjA4OTo5ODc1Mzco MTQ0OCkgYWNrIDEgd2luIDMzMzA0IDxub3Asbm9wLHRpbWVzdGFtcCAxNTc2Njc5NjkgMjExOTI3 OTc+IChERikNCjAwMDA1MyBvcnNvbi4uMjM5OCA+IHJveS4uZnRwLWRhdGE6IC4gYWNrIDk2NTgx NyB3aW4gMzE4NTYgPG5vcCxub3AsdGltZXN0YW1wIDIxMTkyNzk3IDE1NzY2NzkzMz4gKERGKQ0K fn5+fn5+fn5+fn5+fn5+fn5+fn5gd2luZG93IHVwZGF0ZSBhY2ssIHRoZSBwcm9ibGVtIQ0KDQoz ODAzMzAgb3Jzb24uLjIzOTggPiByb3kuLmZ0cC1kYXRhOiAuIGFjayA5NjU4MTcgd2luIDMxODU2 IDxub3Asbm9wLHRpbWVzdGFtcCAyMTE5MjgzMiAxNTc2Njc5MzM+IChERikNCjAwMzcyMyBvcnNv bi4uMjM5OCA+IHJveS4uZnRwLWRhdGE6IC4gYWNrIDk2NTgxNyB3aW4gMzE4NTYgPG5vcCxub3As dGltZXN0YW1wIDIxMTkyODMzIDE1NzY2NzkzMz4gKERGKQ0KMDA0NzAxIG9yc29uLi4yMzk4ID4g cm95Li5mdHAtZGF0YTogLiBhY2sgOTY1ODE3IHdpbiAzMTg1NiA8bm9wLG5vcCx0aW1lc3RhbXAg MjExOTI4MzMgMTU3NjY3OTMzPiAoREYpDQowMDAwMjAgcm95Li5mdHAtZGF0YSA+IG9yc29uLi4y Mzk4OiAuIDk4NzUzNzo5ODg5ODUoMTQ0OCkgYWNrIDEgd2luIDMzMzA0IDxub3Asbm9wLHRpbWVz dGFtcCAxNTc2NjgwMDggMjExOTI4MzM+IChERikNCg0KLS0tLS0tLS0tLS0tLS0tLSBUQ1AgZ2V0 IG9mIGxvc3MgcmVjb3ZlcnksIGJ1dCBpbmZsYXRlZCB3aW5kb3cgZG9lc24ndCByZXRyYWN0DQow MDE5NTYgb3Jzb24uLjIzOTggPiByb3kuLmZ0cC1kYXRhOiAuIGFjayA5ODYwODkgd2luIDExNTg0 IDxub3Asbm9wLHRpbWVzdGFtcCAyMTE5MjgzNCAxNTc2Njc5Njk+IChERikNCjAwMDAyMyByb3ku LmZ0cC1kYXRhID4gb3Jzb24uLjIzOTg6IC4gOTg4OTg1Ojk5MDQzMygxNDQ4KSBhY2sgMSB3aW4g MzMzMDQgPG5vcCxub3AsdGltZXN0YW1wIDE1NzY2ODAwOCAyMTE5MjgzND4gKERGKQ0KMDAwMDEx IHJveS4uZnRwLWRhdGEgPiBvcnNvbi4uMjM5ODogLiA5OTA0MzM6OTkxODgxKDE0NDgpIGFjayAx IHdpbiAzMzMwNCA8bm9wLG5vcCx0aW1lc3RhbXAgMTU3NjY4MDA4IDIxMTkyODM0PiAoREYpDQow MDAwMTMgcm95Li5mdHAtZGF0YSA+IG9yc29uLi4yMzk4OiAuIDk5MTg4MTo5OTMzMjkoMTQ0OCkg YWNrIDEgd2luIDMzMzA0IDxub3Asbm9wLHRpbWVzdGFtcCAxNTc2NjgwMDggMjExOTI4MzQ+IChE RikNCjAwMDAxOCByb3kuLmZ0cC1kYXRhID4gb3Jzb24uLjIzOTg6IC4gOTkzMzI5Ojk5NDc3Nygx NDQ4KSBhY2sgMSB3aW4gMzMzMDQgPG5vcCxub3AsdGltZXN0YW1wIDE1NzY2ODAwOCAyMTE5Mjgz ND4gKERGKQ0KMDAwMDE1IG9yc29uLi4yMzk4ID4gcm95Li5mdHAtZGF0YTogLiBhY2sgOTg2MDg5 IHdpbiAxOTc3NiA8bm9wLG5vcCx0aW1lc3RhbXAgMjExOTI4MzQgMTU3NjY3OTY5PiAoREYpDQow MDAwMTkgcm95Li5mdHAtZGF0YSA+IG9yc29uLi4yMzk4OiAuIDk5NDc3Nzo5OTYyMjUoMTQ0OCkg YWNrIDEgd2luIDMzMzA0IDxub3Asbm9wLHRpbWVzdGFtcCAxNTc2NjgwMDggMjExOTI4MzQ+IChE RikNCjAwMDAxMiByb3kuLmZ0cC1kYXRhID4gb3Jzb24uLjIzOTg6IC4gOTk2MjI1Ojk5NzY3Mygx NDQ4KSBhY2sgMSB3aW4gMzMzMDQgPG5vcCxub3AsdGltZXN0YW1wIDE1NzY2ODAwOCAyMTE5Mjgz ND4gKERGKQ0KMDAwMDE2IHJveS4uZnRwLWRhdGEgPiBvcnNvbi4uMjM5ODogLiA5OTc2NzM6OTk5 MTIxKDE0NDgpIGFjayAxIHdpbiAzMzMwNCA8bm9wLG5vcCx0aW1lc3RhbXAgMTU3NjY4MDA4IDIx MTkyODM0PiAoREYpDQowMDAwMTEgcm95Li5mdHAtZGF0YSA+IG9yc29uLi4yMzk4OiAuIDk5OTEy MToxMDAwNTY5KDE0NDgpIGFjayAxIHdpbiAzMzMwNCA8bm9wLG5vcCx0aW1lc3RhbXAgMTU3NjY4 MDA4IDIxMTkyODM0PiAoREYpDQowMDAwMDkgcm95Li5mdHAtZGF0YSA+IG9yc29uLi4yMzk4OiAu IDEwMDA1Njk6MTAwMjAxNygxNDQ4KSBhY2sgMSB3aW4gMzMzMDQgPG5vcCxub3AsdGltZXN0YW1w IDE1NzY2ODAwOCAyMTE5MjgzND4gKERGKQ0KMDAwMDA5IHJveS4uZnRwLWRhdGEgPiBvcnNvbi4u MjM5ODogLiAxMDAyMDE3OjEwMDM0NjUoMTQ0OCkgYWNrIDEgd2luIDMzMzA0IDxub3Asbm9wLHRp bWVzdGFtcCAxNTc2NjgwMDggMjExOTI4MzQ+IChERikNCjAwMDAyOCByb3kuLmZ0cC1kYXRhID4g b3Jzb24uLjIzOTg6IC4gMTAwMzQ2NToxMDA0OTEzKDE0NDgpIGFjayAxIHdpbiAzMzMwNCA8bm9w LG5vcCx0aW1lc3RhbXAgMTU3NjY4MDA4IDIxMTkyODM0PiAoREYpDQowMDY0NzUgb3Jzb24uLjIz OTggPiByb3kuLmZ0cC1kYXRhOiAuIGFjayA5ODYwODkgd2luIDI3OTY4IDxub3Asbm9wLHRpbWVz dGFtcCAyMTE5MjgzNCAxNTc2Njc5Njk+IChERikNCjAwMDAyNyByb3kuLmZ0cC1kYXRhID4gb3Jz b24uLjIzOTg6IC4gMTAwNDkxMzoxMDA2MzYxKDE0NDgpIGFjayAxIHdpbiAzMzMwNCA8bm9wLG5v cCx0aW1lc3RhbXAgMTU3NjY4MDA5IDIxMTkyODM0PiAoREYpDQowMDAwMTIgcm95Li5mdHAtZGF0 YSA+IG9yc29uLi4yMzk4OiAuIDEwMDYzNjE6MTAwNzgwOSgxNDQ4KSBhY2sgMSB3aW4gMzMzMDQg PG5vcCxub3AsdGltZXN0YW1wIDE1NzY2ODAwOSAyMTE5MjgzND4gKERGKQ0KMDAwMDExIHJveS4u ZnRwLWRhdGEgPiBvcnNvbi4uMjM5ODogLiAxMDA3ODA5OjEwMDkyNTcoMTQ0OCkgYWNrIDEgd2lu IDMzMzA0IDxub3Asbm9wLHRpbWVzdGFtcCAxNTc2NjgwMDkgMjExOTI4MzQ+IChERikNCg0KDQpD b2RlIHJlbGF0ZWQgdG8gdGhpcyBpc3N1ZToNCkluIHRjcF9pbnB1dC5jDQoNCg0KaWYgKFNFUV9M RVEodGgtPnRoX2FjaywgdHAtPnNuZF91bmEpKSB7DQogICBpZiAodGxlbiA9PSAwICYmIHRpd2lu ID09IHRwLT5zbmRfd25kKSB7DQogICAgLi4uLi4uLg0KICAgfSBlbHNlDQogICAgdHAtPnRfZHVw YWNrcyA9IDA7DQogICBicmVhazsNCiAgfQ0KDQouLi4uLi4NCg0KICAvKg0KICAgKiBJZiB0X2R1 cGFja3MgIT0gMCBoZXJlLCBpdCBpbmRpY2F0ZXMgdGhhdCB3ZSBhcmUgc3RpbGwNCiAgICogaW4g TmV3UmVubyBmYXN0IHJlY292ZXJ5IG1vZGUsIHNvIHdlIGxlYXZlIHRoZSBjb25nZXN0aW9uDQog ICAqIHdpbmRvdyBhbG9uZS4NCiAgICovDQogIGlmICh0Y3BfZG9fbmV3cmVubyA9PSAwIHx8IHRw LT50X2R1cGFja3MgPT0gMCkNCiAgIHRwLT5zbmRfY3duZCA9IG1pbihjdyArIGluY3IsVENQX01B WFdJTjw8dHAtPnNuZF9zY2FsZSk7DQogIH0NCg0KDQpHdW9oYW4gTHUNCg0K To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 3 8:21:31 2003 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 E87B037B401 for ; Mon, 3 Mar 2003 08:21:29 -0800 (PST) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16DD243FA3 for ; Mon, 3 Mar 2003 08:21:27 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.12.3/8.12.3) with ESMTP id h23GLPu5081211 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 3 Mar 2003 08:21:25 -0800 (PST) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.6/8.12.6/Submit) id h23GLPVB006964; Mon, 3 Mar 2003 08:21:25 -0800 (PST) (envelope-from jdp) Date: Mon, 3 Mar 2003 08:21:25 -0800 (PST) Message-Id: <200303031621.h23GLPVB006964@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: lguohan00@mails.tsinghua.edu.cn Subject: Re: The inflated snd_cwnd doesn't get retracted after TCP recovered from multiple losses (4.5-RELEASE) In-Reply-To: <007501c2e193$e67589e0$668019d2@garfield> References: <007501c2e193$e67589e0$668019d2@garfield> 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 <007501c2e193$e67589e0$668019d2@garfield>, Lu Guohan wrote: > When TCP sender receives window update ack during loss > recovery, the inflated tp->snd_cwnd doesn't get retracted > after TCP recovered from multiple losses. There were some serious bugs in the TCP implementation in 4.5-RELEASE. Try upgrading to the latest -stable. 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 Mon Mar 3 8:41:19 2003 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 1FD9E37B401 for ; Mon, 3 Mar 2003 08:41:18 -0800 (PST) Received: from odysseus.silby.com (d87.as28.nwbl0.wi.voyager.net [169.207.69.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BE8D43F85 for ; Mon, 3 Mar 2003 08:41:16 -0800 (PST) (envelope-from silby@silby.com) Received: from odysseus.silby.com (localhost [127.0.0.1]) by odysseus.silby.com (8.12.7/8.12.7) with ESMTP id h23GcBF7009650; Mon, 3 Mar 2003 10:38:11 -0600 (CST) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by odysseus.silby.com (8.12.7/8.12.7/Submit) with ESMTP id h23Gc9oL009647; Mon, 3 Mar 2003 10:38:11 -0600 (CST) X-Authentication-Warning: odysseus.silby.com: silby owned process doing -bs Date: Mon, 3 Mar 2003 10:38:09 -0600 (CST) From: Mike Silbersack To: Lu Guohan Cc: freebsd-net@freebsd.org Subject: Re: The inflated snd_cwnd doesn't get retracted after TCP recovered from multiple losses (4.5-RELEASE) In-Reply-To: <007501c2e193$e67589e0$668019d2@garfield> Message-ID: <20030303103330.J9513@odysseus.silby.com> References: <007501c2e193$e67589e0$668019d2@garfield> 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, 3 Mar 2003, Lu Guohan wrote: > hello, > I am new to hear, and I am not sure if anyone post this problem > before. And I am figuring out the way to post this problem by PR > since the web interface is not avaiable right now. > > RFC2581. Below is the trace, both the sender and the receiver run > freebsd 4.5-RELEASE. I have many traces of this kind, it occurs > frequently. This may even have security problem. I am not sure if > this bug is fixed in later versions. Jeffery Hsu recently fixed this problem in 4.7-stable. If you have time, you should update to the RELENG_4 branch and confirm that the problem goes away for you. Although it was a few weeks late, I do appreciate the quality of your bug report. Had Jeffery not already worked on the problem, your report would have been a great help in finding a solution. Tell us if you find any more bugs! 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 Mar 3 10:28: 5 2003 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 9E67837B421 for ; Mon, 3 Mar 2003 10:28:03 -0800 (PST) Received: from mel-rto4.wanadoo.fr (smtp-out-4.wanadoo.fr [193.252.19.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7893243FBD for ; Mon, 3 Mar 2003 10:28:02 -0800 (PST) (envelope-from vjardin@wanadoo.fr) Received: from mel-rta7.wanadoo.fr (193.252.19.61) by mel-rto4.wanadoo.fr (6.7.015) id 3E0C33FD02A0558D; Mon, 3 Mar 2003 19:27:56 +0100 Received: from mercure.vincentjardin.net (193.253.220.163) by mel-rta7.wanadoo.fr (6.7.015) id 3E5335B1006F3D11; Mon, 3 Mar 2003 19:27:56 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Vincent Jardin To: Michael Bretterklieber Subject: Re: [mpd] radius and dynamic bundles Date: Mon, 3 Mar 2003 18:27:54 +0000 User-Agent: KMail/1.4.3 Cc: net@FreeBSD.ORG References: <200303022347.10283.vjardin@wanadoo.fr> <3E63245D.6040800@jawa.at> In-Reply-To: <3E63245D.6040800@jawa.at> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200303031827.54786.vjardin@wanadoo.fr> 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 Monday 03 March 2003 09:46, Michael Bretterklieber wrote: > Hi, > > Vincent Jardin schrieb: > > 1/ When Radius is used with mpd and the answer delay of the Radius se= rver > > is high, how can some PAP or CHAP timeout be avoided ? > > you mean, that the client times out during authentication saying that > the server didn't responded? Yes, that the main problem that happens sometimes. > A known issue is that mpd is blocked during RADIUS requests, the > solution will be to change from rad_send_request(); to > rad_init_send_request() and rad_continue_send_request(); to avoid > blocking of mpd. > > I have this on my todo-list, but atm it has low prio. It does not look to be simple because the whole PAP and CHAP authenticati= on=20 are processed by PapInput() and ChapInput() that call RadiusPAPAuthentica= te()=20 and RadiusCHAPAuthenticate(). It is a synchronous call. In order to use=20 rad_init_send_request() and rad_continue_send_request(), PapInput() and=20 ChapInput() need to be splitted, doesn't they ? Thanks, Vincent To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 3 11: 6:38 2003 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 09A2237B401 for ; Mon, 3 Mar 2003 11:06:37 -0800 (PST) Received: from jawa.at (inforum.at [213.229.17.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF49B43FCB for ; Mon, 3 Mar 2003 11:06:35 -0800 (PST) (envelope-from mbretter@jawa.at) Received: from jawa.at (worf.jawa.at [192.168.201.12]) by jawa.at (8.12.6/8.12.6) with ESMTP id h23J6R07007413; Mon, 3 Mar 2003 20:06:27 +0100 (CET) (envelope-from mbretter@jawa.at) Message-ID: <3E63A75D.6090904@jawa.at> Date: Mon, 03 Mar 2003 20:05:01 +0100 From: Michael Bretterklieber User-Agent: Mozilla/5.0 (X11; U; Linux i386; de-AT; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vincent Jardin Cc: net@FreeBSD.ORG, Archie Cobbs Subject: Re: [mpd] radius and dynamic bundles References: <200303022347.10283.vjardin@wanadoo.fr> <3E63245D.6040800@jawa.at> <200303031827.54786.vjardin@wanadoo.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-1.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 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, Vincent Jardin wrote: > On Monday 03 March 2003 09:46, Michael Bretterklieber wrote: > >>Hi, >> >>Vincent Jardin schrieb: >> >>>1/ When Radius is used with mpd and the answer delay of the Radius server >>>is high, how can some PAP or CHAP timeout be avoided ? >> >>you mean, that the client times out during authentication saying that >>the server didn't responded? > > > Yes, that the main problem that happens sometimes. > > >>A known issue is that mpd is blocked during RADIUS requests, the >>solution will be to change from rad_send_request(); to >>rad_init_send_request() and rad_continue_send_request(); to avoid >>blocking of mpd. >> >>I have this on my todo-list, but atm it has low prio. > > > It does not look to be simple because the whole PAP and CHAP authentication > are processed by PapInput() and ChapInput() that call RadiusPAPAuthenticate() > and RadiusCHAPAuthenticate(). It is a synchronous call. In order to use > rad_init_send_request() and rad_continue_send_request(), PapInput() and > ChapInput() need to be splitted, doesn't they ? hmm, IMO, yes we must detect somewhere that a RADIUS request is already in progress and skip some code, and if the request is finished we have only to send the response back to the peer. I plan delivering patches to Archie in this week for enhanced RADIUS support (incl. accounting) for the next Version of mpd, however I will have a look at this problem and see how tricky is this to implement. bye, -- ------------------------------- ------------------------------------- Michael Bretterklieber - Michael.Bretterklieber@jawa.at JAWA Management Software GmbH - http://www.jawa.at Liebenauer Hauptstr. 200 -------------- privat --------------- A-8041 GRAZ GSM: ++43-(0)676-93 96 698 Tel: ++43-(0)316-403274-12 E-mail: michael@bretterklieber.com Fax: ++43-(0)316-403274-10 http://www.bretterklieber.com ------------------------------- ------------------------------------- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 3 14:48:44 2003 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 400E637B401 for ; Mon, 3 Mar 2003 14:48:43 -0800 (PST) Received: from web21008.mail.yahoo.com (web21008.mail.yahoo.com [216.136.227.62]) by mx1.FreeBSD.org (Postfix) with SMTP id D82BC43F3F for ; Mon, 3 Mar 2003 14:48:42 -0800 (PST) (envelope-from davidmyer800@yahoo.com) Message-ID: <20030303224842.12148.qmail@web21008.mail.yahoo.com> Received: from [65.172.158.93] by web21008.mail.yahoo.com via HTTP; Mon, 03 Mar 2003 14:48:42 PST Date: Mon, 3 Mar 2003 14:48:42 -0800 (PST) From: David Myer Subject: inetd behavior etc To: freebsd-net@FreeBSD.ORG 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 Hi, Anyone knows how inetd services will behave under stress situation ? I have a socket program that sends large amount of data over n number of connections to inetd echo servire using UDP, (echo_dg) and trying to compare data on receive, I notice that when n increases (> 8), program does not behave properly. Another question, I notice that recvfrom always returns bytes of 4096, even though I set UDP receive buffer to a big number using setsockopt(), any ideas ? Thanks __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 3 14:57:35 2003 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 75EBA37B401 for ; Mon, 3 Mar 2003 14:57:34 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9186243FBD for ; Mon, 3 Mar 2003 14:57:33 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h23MvWpI008826 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 3 Mar 2003 17:57:32 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.6/8.12.6/Submit) id h23MvWaa008823; Mon, 3 Mar 2003 17:57:32 -0500 (EST) (envelope-from wollman) Date: Mon, 3 Mar 2003 17:57:32 -0500 (EST) From: Garrett Wollman Message-Id: <200303032257.h23MvWaa008823@khavrinen.lcs.mit.edu> To: David Myer Cc: freebsd-net@FreeBSD.ORG Subject: inetd behavior etc In-Reply-To: <20030303224842.12148.qmail@web21008.mail.yahoo.com> References: <20030303224842.12148.qmail@web21008.mail.yahoo.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 < said: > Anyone knows how inetd [internal] services will behave under stress > situation ? Very poorly, since they were never intended to be used in that manner. A purpose-built server will almost invariably handle loads much better. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 3 15: 1:55 2003 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 22FC537B401 for ; Mon, 3 Mar 2003 15:01:53 -0800 (PST) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5318043FAF for ; Mon, 3 Mar 2003 15:01:52 -0800 (PST) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id h23N0EG07348; Mon, 3 Mar 2003 18:00:14 -0500 (EST) (envelope-from bmilekic@unixdaemons.com) Date: Mon, 3 Mar 2003 18:00:14 -0500 From: Bosko Milekic To: CHOI Junho Cc: net@freebsd.org Subject: Re: Performance tuning hints of gigabit networking? Message-ID: <20030303180014.A7317@unixdaemons.com> References: <20030226.220551.10329540.cjh@kr.FreeBSD.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: <20030226.220551.10329540.cjh@kr.FreeBSD.org>; from cjh@kr.FreeBSD.org on Wed, Feb 26, 2003 at 10:05:51PM +0900 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 You're not running out of mbufs or clusters, you're out of RAM. Don't bump up nmbclusters anymore because you don't need to; instead, add more RAM. On Wed, Feb 26, 2003 at 10:05:51PM +0900, CHOI Junho wrote: > > Hi, > > I am looking for a good resource for kernel tuning on very high > bandwidth HTTP servers(avg 500Mbit/sec, peak 950Mbit/sec). Today I > faced very unusual situation with 950Mbit/sec bandwidth! > > > netstat -m > 16962/93488/262144 mbufs in use (current/peak/max): > 16962 mbufs allocated to data > 16952/65536/65536 mbuf clusters in use (current/peak/max) > 154444 Kbytes allocated to network (14% of mb_map in use) > 512627 requests for memory denied > 2614 requests for memory delayed > 0 calls to protocol drain routines > > I set kern.ipc.nmbclusters=65536, but it overflowed. This is P-IV Xeon > 1.8G, 2GB RAM, and one Intel 1000baseSX(em driver) machine running > 4.7-RELEASE-pX. This server is running only one service, HTTP. I use > thttpd, since apache doesn't work in such a high load. thttpd is highly > amazing, just give <1 load in any time. > > Once I tried to increase kern.ipc.nmbclusters to 131072 or > higher(multiple of 65536 or 32768, tuning(7) only cites about 32768 > case..), it fails to boot kernel when 262144, or kernel panic in > somewhat higher load when 131072, so I gave up other changes and fall > back to 65536. > > What is a good way to calcurate this value safely? Here is another > hint, /etc/sysctl.conf: > > net.link.ether.inet.log_arp_wrong_iface=0 > kern.ipc.maxsockbuf=2048000 > kern.ipc.somaxconn=4096 > kern.ipc.maxsockets=60000 > kern.maxfiles=65536 > kern.maxfilesperproc=32768 > net.inet.tcp.rfc1323=1 > net.inet.tcp.delayed_ack=0 > net.inet.tcp.sendspace=65535 > net.inet.tcp.recvspace=65535 > net.inet.udp.recvspace=65535 > net.inet.udp.maxdgram=57344 > net.inet.icmp.drop_redirect=1 > net.inet.icmp.log_redirect=1 > net.inet.ip.redirect=0 > net.inet6.ip6.redirect=0 > net.link.ether.inet.max_age=1200 > net.inet.ip.sourceroute=0 > net.inet.ip.accept_sourceroute=0 > net.inet.icmp.bmcastecho=0 > net.inet.icmp.maskrepl=0 > net.inet.tcp.inflight_enable=1 > > kernel configuration is not specially tuned, except DEVICE_POLLING and > HZ=2000. > > -- > CHOI Junho KFUG > FreeBSD Project Web Data Bank > Key fingerprint = 1369 7374 A45F F41A F3C0 07E3 4A01 C020 E602 60F5 > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > -- 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 Mar 3 15: 3:50 2003 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 E44A437B405 for ; Mon, 3 Mar 2003 15:03:48 -0800 (PST) Received: from mail.econolodgetulsa.com (mail.econolodgetulsa.com [198.78.66.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E65943FB1 for ; Mon, 3 Mar 2003 15:03:48 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Received: from mail (user@mail [198.78.66.163]) by mail.econolodgetulsa.com (8.12.3/8.12.3) with ESMTP id h23N3xdR061496 for ; Mon, 3 Mar 2003 15:03:59 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Date: Mon, 3 Mar 2003 15:03:58 -0800 (PST) From: Josh Brooks To: freebsd-net@freebsd.org Subject: ipfw2 in 4.7 == incorrect stats ? Message-ID: <20030303150131.Q61214-100000@mail.econolodgetulsa.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 Hello, I am successfully running ipfw2 in FreeBSD 4.7-RELEASE. Everything seems fine, but it seems like the stats on each of the rules are just _way way_ low. On all rules I notice this. for instance: 65123 556880155 55168583654 allow ip from any to any This shows 55 gigabytes of total transfer for this rule - and i know we have transferred about 3 terabytes during that period ... So my questions are: 1. is this a known problem ? 2. are the packet count numbers (the first stat) wrong as well ? Or just the traffic count ? thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 3 17:57:58 2003 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 3577C37B401; Mon, 3 Mar 2003 17:57:57 -0800 (PST) Received: from relay1.cris.net (relay1.cris.net [212.110.128.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34B6443FCB; Mon, 3 Mar 2003 17:57:54 -0800 (PST) (envelope-from ml@phantom.cris.net) Received: from phantom.cris.net (root@phantom.cris.net [212.110.130.74]) by relay1.cris.net (8.12.6/8.12.6) with ESMTP id h2447jvb050154; Tue, 4 Mar 2003 04:07:46 GMT Received: (from ml@localhost) by phantom.cris.net (8.12.6/8.12.2) id h2424YiH042292; Tue, 4 Mar 2003 04:04:34 +0200 (EET) (envelope-from ml) Date: Tue, 4 Mar 2003 04:04:34 +0200 From: Alexey Zelkin To: Garrett Wollman Cc: Ruslan Ermilov , freebsd-net@FreeBSD.ORG Subject: Re: maxsockbuf is useless value {?|:-(} Message-ID: <20030304040434.A42256@phantom.cris.net> References: <20030228130621.A16504@phantom.cris.net> <200302281931.h1SJVAUg060319@khavrinen.lcs.mit.edu> <20030301134118.GE77007@sunbay.com> <200303022015.h22KFbn0075585@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200303022015.h22KFbn0075585@khavrinen.lcs.mit.edu>; from wollman@lcs.mit.edu on Sun, Mar 02, 2003 at 03:15:37PM -0500 X-Operating-System: FreeBSD 4.7-STABLE i386 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, On Sun, Mar 02, 2003 at 03:15:37PM -0500, Garrett Wollman wrote: > < said: > > > Seriously, you didn't give any alternative. How does one > > knows the maximum allowed limit? By just blindly trying? > > Ask for however much you think you actually need, and bleat to the > administrator (or limp along) if you don't get it. Keep in mind that > this is a security-sensitive parameter (a user can use up to > `maxsockbuf' bytes of wired kernel memory for each file descriptor he > is allowed to open). Wrong. As I stated originally, it's impossible to use 'maxsockbuf' value. kernel uses another value to check user supplied arguments, and this value is ~4-5% less than maxsockbuf. Therefore attempt to use 'maxsockbuf' as bufsize will fail in 100% of cases. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 3 18:12: 9 2003 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 EB30137B401 for ; Mon, 3 Mar 2003 18:12:07 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FBB243FCB for ; Mon, 3 Mar 2003 18:12:07 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost.ipv6.lcs.mit.edu [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.8/8.12.8) with ESMTP id h242C5Cd001306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Mar 2003 21:12:05 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.8/8.12.8/Submit) id h242C5fI001303; Mon, 3 Mar 2003 21:12:05 -0500 (EST) (envelope-from wollman) Date: Mon, 3 Mar 2003 21:12:05 -0500 (EST) From: Garrett Wollman Message-Id: <200303040212.h242C5fI001303@khavrinen.lcs.mit.edu> To: Alexey Zelkin Cc: freebsd-net@FreeBSD.ORG Subject: Re: maxsockbuf is useless value {?|:-(} In-Reply-To: <20030304040434.A42256@phantom.cris.net> References: <20030228130621.A16504@phantom.cris.net> <200302281931.h1SJVAUg060319@khavrinen.lcs.mit.edu> <20030301134118.GE77007@sunbay.com> <200303022015.h22KFbn0075585@khavrinen.lcs.mit.edu> <20030304040434.A42256@phantom.cris.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 < said: > Wrong. BZZZT! > As I stated originally, it's impossible to use 'maxsockbuf' value. That does not change the fact that an unprivileged user can use up to `maxsockbuf' bytes of wired kernel memory per socket. That's why the limit exists. The amount of memory allocated to socket buffer data structures is not the same as the amount of user data which can be stored in the socket buffer. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 3 18:24:46 2003 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 210CD37B401 for ; Mon, 3 Mar 2003 18:24:45 -0800 (PST) Received: from relay1.cris.net (relay1.cris.net [212.110.128.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 484FF43FBF for ; Mon, 3 Mar 2003 18:24:42 -0800 (PST) (envelope-from phantom@phantom.cris.net) Received: from phantom.cris.net (root@phantom.cris.net [212.110.130.74]) by relay1.cris.net (8.12.6/8.12.6) with ESMTP id h244Ycvb051056; Tue, 4 Mar 2003 04:34:38 GMT Received: (from phantom@localhost) by phantom.cris.net (8.12.6/8.12.2) id h242VV54042452; Tue, 4 Mar 2003 04:31:31 +0200 (EET) (envelope-from phantom) Date: Tue, 4 Mar 2003 04:31:30 +0200 From: Alexey Zelkin To: Garrett Wollman Cc: freebsd-net@FreeBSD.ORG Subject: Re: maxsockbuf is useless value {?|:-(} Message-ID: <20030304043130.B42396@phantom.cris.net> References: <20030228130621.A16504@phantom.cris.net> <200302281931.h1SJVAUg060319@khavrinen.lcs.mit.edu> <20030301134118.GE77007@sunbay.com> <200303022015.h22KFbn0075585@khavrinen.lcs.mit.edu> <20030304040434.A42256@phantom.cris.net> <200303040212.h242C5fI001303@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200303040212.h242C5fI001303@khavrinen.lcs.mit.edu>; from wollman@lcs.mit.edu on Mon, Mar 03, 2003 at 09:12:05PM -0500 X-Operating-System: FreeBSD 4.7-STABLE i386 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, On Mon, Mar 03, 2003 at 09:12:05PM -0500, Garrett Wollman wrote: > > As I stated originally, it's impossible to use 'maxsockbuf' value. > > That does not change the fact that an unprivileged user can use up to > `maxsockbuf' bytes of wired kernel memory per socket. That's why the > limit exists. The amount of memory allocated to socket buffer data > structures is not the same as the amount of user data which can be > stored in the socket buffer. Correct me if I wrong, but looks like since rev 1.102 of uipc_socket2.c "something" changed, and should be fixed in some way. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 0:12:15 2003 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 C009137B401 for ; Tue, 4 Mar 2003 00:12:14 -0800 (PST) Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52CE943FBD for ; Tue, 4 Mar 2003 00:12:13 -0800 (PST) (envelope-from john@veidit.net) Received: from d1o1000.telia.com (d1o1000.telia.com [217.208.12.241]) by mailc.telia.com (8.12.5/8.12.5) with ESMTP id h248C6bZ011491 for ; Tue, 4 Mar 2003 09:12:07 +0100 (CET) X-Original-Recipient: Received: from veidit.net (h230n1fls35o1000.telia.com [217.210.234.230]) by d1o1000.telia.com (8.10.2/8.10.1) with ESMTP id h248C6R14516 for ; Tue, 4 Mar 2003 09:12:06 +0100 (CET) Message-ID: <3E645FCE.8000900@veidit.net> Date: Tue, 04 Mar 2003 09:11:58 +0100 From: John Angelmo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: sv, en, en-us MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Sendmail AUTH agains passwd? 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 Hello I'm intrested in implementing sendmail with AUTH agains passwd, I have only been able to do this agains TSL with their database, has anyone tried agains passwd and got it to work? /John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 0:22:30 2003 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 5BDA237B401 for ; Tue, 4 Mar 2003 00:22:29 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1D8A43FA3 for ; Tue, 4 Mar 2003 00:22:28 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.3/8.12.3) with ESMTP id h248MSAq050710; Tue, 4 Mar 2003 00:22:28 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.3/8.12.3/Submit) id h248MSjZ050709; Tue, 4 Mar 2003 00:22:28 -0800 (PST) (envelope-from rizzo) Date: Tue, 4 Mar 2003 00:22:28 -0800 From: Luigi Rizzo To: Josh Brooks Cc: freebsd-net@FreeBSD.ORG Subject: Re: ipfw2 in 4.7 == incorrect stats ? Message-ID: <20030304002228.A50564@xorpc.icir.org> References: <20030303150131.Q61214-100000@mail.econolodgetulsa.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: <20030303150131.Q61214-100000@mail.econolodgetulsa.com>; from user@mail.econolodgetulsa.com on Mon, Mar 03, 2003 at 03:03:58PM -0800 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, Mar 03, 2003 at 03:03:58PM -0800, Josh Brooks wrote: ... > 65123 556880155 55168583654 allow ip from any to any > > This shows 55 gigabytes of total transfer for this rule - and i know we > have transferred about 3 terabytes during that period ... i am not aware of counter problems. Your rule however seems the last one in the ruleset so maybe the vast majority of traffic is catched by some other rules earlier ? cheers luigi > So my questions are: > > 1. is this a known problem ? > > 2. are the packet count numbers (the first stat) wrong as well ? Or just > the traffic count ? > > thanks. > > > 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 Tue Mar 4 2:11:22 2003 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 E54CB37B401 for ; Tue, 4 Mar 2003 02:11:20 -0800 (PST) Received: from mail.econolodgetulsa.com (mail.econolodgetulsa.com [198.78.66.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EF7B43FBF for ; Tue, 4 Mar 2003 02:11:20 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Received: from mail (user@mail [198.78.66.163]) by mail.econolodgetulsa.com (8.12.3/8.12.3) with ESMTP id h24ABWdR050947; Tue, 4 Mar 2003 02:11:32 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Date: Tue, 4 Mar 2003 02:11:32 -0800 (PST) From: Josh Brooks To: Luigi Rizzo Cc: freebsd-net@FreeBSD.ORG Subject: Re: ipfw2 in 4.7 == incorrect stats ? In-Reply-To: <20030304002228.A50564@xorpc.icir.org> Message-ID: <20030304021102.U49939-100000@mail.econolodgetulsa.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 No, it should be catching much more than it shows. Also many other rules that are quite specific are very very deflated. I will do some real tests later today with firm numbers. On Tue, 4 Mar 2003, Luigi Rizzo wrote: > On Mon, Mar 03, 2003 at 03:03:58PM -0800, Josh Brooks wrote: > ... > > 65123 556880155 55168583654 allow ip from any to any > > > > This shows 55 gigabytes of total transfer for this rule - and i know we > > have transferred about 3 terabytes during that period ... > > i am not aware of counter problems. Your rule however seems > the last one in the ruleset so maybe the vast majority of traffic > is catched by some other rules earlier ? > > cheers > luigi > > > So my questions are: > > > > 1. is this a known problem ? > > > > 2. are the packet count numbers (the first stat) wrong as well ? Or just > > the traffic count ? > > > > thanks. > > > > > > 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 Tue Mar 4 2:14:58 2003 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 5CBEB37B401 for ; Tue, 4 Mar 2003 02:14:57 -0800 (PST) Received: from mail.econolodgetulsa.com (mail.econolodgetulsa.com [198.78.66.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id D900F43FDD for ; Tue, 4 Mar 2003 02:14:56 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Received: from mail (user@mail [198.78.66.163]) by mail.econolodgetulsa.com (8.12.3/8.12.3) with ESMTP id h24AF9dR053429 for ; Tue, 4 Mar 2003 02:15:09 -0800 (PST) (envelope-from user@mail.econolodgetulsa.com) Date: Tue, 4 Mar 2003 02:15:09 -0800 (PST) From: Josh Brooks To: freebsd-net@freebsd.org Subject: counting firewall traffic on a second machine Message-ID: <20030304021141.C49939-100000@mail.econolodgetulsa.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 Hello, I used to have a firewall with ipfw count rules in place for every IP I had. This worked fine, but it gave me a 2000+ ruleset that would cause cpu to skyrocket under even the lightest of DoS attacks. So, I have plugged in another system on the DMZ and plan to count from there. In the most basic sense, I am thinking of sniffing trafficon this second machine and counting via that mechanism. Is this a common setup - counting traffic on a second machine that the traffic does not even flow through ? If so, is ipfw count rules used on the counting machine, or is there a better tool for counting per-IP traffic on a secondary system like this ? Any suggestions are appreciated. i will be using MRTG to show the stats, but again, the actual gathering / counting method I will use i am not sure of ... was planning on using ipfw count rules, but thought I would ask. And I am not sure of how to sniff traffic and pass it to ipfw to count .. so perhaps ipfw is not involved at all... thanks! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 5:47:40 2003 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 8CF6637B401; Tue, 4 Mar 2003 05:47:39 -0800 (PST) Received: from smtp02.syd.iprimus.net.au (smtp02.syd.iprimus.net.au [210.50.76.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id A680643FAF; Tue, 4 Mar 2003 05:47:38 -0800 (PST) (envelope-from tim@robbins.dropbear.id.au) Received: from dilbert.robbins.dropbear.id.au ([210.50.41.31]) by smtp02.syd.iprimus.net.au with Microsoft SMTPSVC(5.0.2195.5600); Wed, 5 Mar 2003 00:47:35 +1100 Received: from dilbert.robbins.dropbear.id.au (wsyclibwb0dnv8pe@localhost [127.0.0.1]) by dilbert.robbins.dropbear.id.au (8.12.6/8.12.6) with ESMTP id h24DlWJK013523; Wed, 5 Mar 2003 00:47:32 +1100 (EST) (envelope-from tim@dilbert.robbins.dropbear.id.au) Received: (from tim@localhost) by dilbert.robbins.dropbear.id.au (8.12.6/8.12.6/Submit) id h24DlVEH013521; Wed, 5 Mar 2003 00:47:31 +1100 (EST) (envelope-from tim) Date: Wed, 5 Mar 2003 00:47:30 +1100 From: Tim Robbins To: freebsd-net@freebsd.org Cc: freebsd-current@freebsd.org Subject: Removal of netns Message-ID: <20030305004730.A13129@dilbert.robbins.dropbear.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-OriginalArrivalTime: 04 Mar 2003 13:47:35.0909 (UTC) FILETIME=[9D022950:01C2E254] 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 there a compelling reason why I shouldn't remove netns? That is, does it serve a purpose now that it could not serve if it was moved to the Attic? Tim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 5:53:15 2003 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 3C40C37B405 for ; Tue, 4 Mar 2003 05:53:14 -0800 (PST) Received: from mercury.ccmr.cornell.edu (mercury.ccmr.cornell.edu [128.84.231.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5731A43F93 for ; Tue, 4 Mar 2003 05:53:13 -0800 (PST) (envelope-from mitch@ccmr.cornell.edu) Received: from ori.ccmr.cornell.edu (ori.ccmr.cornell.edu [128.84.231.243]) by mercury.ccmr.cornell.edu (8.12.8/8.12.8) with ESMTP id h24DrCTw013078; Tue, 4 Mar 2003 08:53:12 -0500 Received: from localhost (mitch@localhost) by ori.ccmr.cornell.edu (8.12.8/8.12.8) with ESMTP id h24DrCBL023834; Tue, 4 Mar 2003 08:53:12 -0500 X-Authentication-Warning: ori.ccmr.cornell.edu: mitch owned process doing -bs Date: Tue, 4 Mar 2003 08:53:12 -0500 (EST) From: Mitch Collinsworth To: John Angelmo Cc: freebsd-net@FreeBSD.ORG Subject: Re: Sendmail AUTH agains passwd? In-Reply-To: <3E645FCE.8000900@veidit.net> Message-ID: References: <3E645FCE.8000900@veidit.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 On Tue, 4 Mar 2003, John Angelmo wrote: > I'm intrested in implementing sendmail with AUTH agains passwd, I have > only been able to do this agains TSL with their database, has anyone > tried agains passwd and got it to work? One approach that has been used with success by many folks, me included, is to, rather than try to auth sendmail itself, piggyback on pop or imap authentication that's already taking place for users to pick up their incoming mail. There are various implementations of this around but the basic idea usually comes down to: 1) post-process your pop/imap logs to see who has authenticated recently 2) add the IP addresses those users connected from to a database somewhere with time of authentication 3) update sendmail's list of IPs allowed to relay mail 4) periodically timeout IPs from the database that haven't re-auth'd recently. This scheme is not perfect but it's "pretty good" and works well with a reasonable amount of implementation effort. The primary "catch" is that users have to first connect with pop or imap before they can send mail, but for the convenience of being able to roam the planet without changing their smtp settings, they're normally quite willing to learn to do that. The primary advantage is that it doesn't require any special features in the MUA, which means your users are free to use whichever MUA they prefer. The one that I've had success with is here: http://poprelay.sourceforge.net/ -Mitch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 7:11:25 2003 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 7A23837B401 for ; Tue, 4 Mar 2003 07:11:24 -0800 (PST) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33E8543F75 for ; Tue, 4 Mar 2003 07:11:23 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from PHE (silver.he.iki.fi [193.64.42.241]) by silver.he.iki.fi (8.12.8/8.11.4) with SMTP id h24FBKlL011902 for ; Tue, 4 Mar 2003 17:11:21 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <0d6e01c2e260$506836a0$932a40c1@PHE> From: "Petri Helenius" To: Subject: 5.0 network code Date: Tue, 4 Mar 2003 17:11:20 +0200 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.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 Any ideas if netgraph code is accounted for the "swiN: net" kernel process or to the interrupt virtual process? Also ideas what is the usual bottleneck in SMP Xeon system are appreciated, 600Mbps internet traffic seems to generate about 60% (on one of the CPUs) . This is on -CURRENT. The number of interrupts generated seems to fluxuate a lot, from 1000 to about 8000 a second. Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 7:57:51 2003 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 E9C9237B401; Tue, 4 Mar 2003 07:57:49 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6E5E43FB1; Tue, 4 Mar 2003 07:57:48 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0004.cvx40-bradley.dialup.earthlink.net ([216.244.42.4] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18qEna-0005xs-00; Tue, 04 Mar 2003 07:57:46 -0800 Message-ID: <3E64CCAB.4C70108F@mindspring.com> Date: Tue, 04 Mar 2003 07:56:27 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tim Robbins Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Removal of netns References: <20030305004730.A13129@dilbert.robbins.dropbear.id.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4b7b18a31286905235cb2a257310419d2666fa475841a1c7a350badd9bab72f9c350badd9bab72f9c 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 Tim Robbins wrote: > Is there a compelling reason why I shouldn't remove netns? That is, does > it serve a purpose now that it could not serve if it was moved to the > Attic? Might as well move /sys/i386/conf/GENERIC to the attic while you are at it. It can serve it's purpose from there, too. Is there a compelling reason for doing this, other than "I want to make some API/locking change, but I don't want to have to keep this code working at the same time"? Maximizing bit-rot in order to avoid effort is a bad thing, particularly when it's done by the person who is making the change that causes the rot: that person is the person most qualified in the world to correct the bit-rot (or prevent it from happening), in that they have the best understanding of *why* their change broke something. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 8:35:42 2003 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 4331D37B401; Tue, 4 Mar 2003 08:35:41 -0800 (PST) Received: from espresso.bsdmike.org (espresso.bsdmike.org [65.39.129.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9505F43FBF; Tue, 4 Mar 2003 08:35:40 -0800 (PST) (envelope-from mike@espresso.bsdmike.org) Received: by espresso.bsdmike.org (Postfix, from userid 1002) id 2A9879C5F; Tue, 4 Mar 2003 11:22:49 -0500 (EST) Date: Tue, 4 Mar 2003 11:22:49 -0500 From: Mike Barcroft To: Terry Lambert Cc: Tim Robbins , freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Removal of netns Message-ID: <20030304112249.B70629@espresso.bsdmike.org> References: <20030305004730.A13129@dilbert.robbins.dropbear.id.au> <3E64CCAB.4C70108F@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E64CCAB.4C70108F@mindspring.com>; from tlambert2@mindspring.com on Tue, Mar 04, 2003 at 07:56:27AM -0800 Organization: The FreeBSD Project 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 Terry Lambert writes: > Tim Robbins wrote: > > Is there a compelling reason why I shouldn't remove netns? That is, does > > it serve a purpose now that it could not serve if it was moved to the > > Attic? > > Might as well move /sys/i386/conf/GENERIC to the attic while > you are at it. It can serve it's purpose from there, too. This comment is not helpful. Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 9:51:18 2003 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 0295137B401; Tue, 4 Mar 2003 09:51:16 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED21043F85; Tue, 4 Mar 2003 09:51:14 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0410.cvx21-bradley.dialup.earthlink.net ([209.179.193.155] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18qGZM-0005A2-00; Tue, 04 Mar 2003 09:51:13 -0800 Message-ID: <3E64E740.9D1DC8B3@mindspring.com> Date: Tue, 04 Mar 2003 09:49:52 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Barcroft Cc: Tim Robbins , freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Removal of netns - politically correct version References: <20030305004730.A13129@dilbert.robbins.dropbear.id.au> <3E64CCAB.4C70108F@mindspring.com> <20030304112249.B70629@espresso.bsdmike.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a424144d60a93d476d123cd95ea0b69587666fa475841a1c7a350badd9bab72f9c350badd9bab72f9c 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 Barcroft wrote: > Terry Lambert writes: > > Tim Robbins wrote: > > > Is there a compelling reason why I shouldn't remove netns? That is, does > > > it serve a purpose now that it could not serve if it was moved to the > > > Attic? > > > > Might as well move /sys/i386/conf/GENERIC to the attic while > > you are at it. It can serve it's purpose from there, too. > > This comment is not helpful. Then let me politically correct it. I am cynical about the ability of any code to serve the same purpose from the Attic which it serves in the main source tree. What of the rest of my comment, which you removed? I'll rephrase that, too: Is there a compelling reason for removing this working code to the Attic? I am cynical that any purpose is served by making this change; my cynicism leads me to believe that the intention of it is to make it easier for someone to hack up other code which uses related API's, without having to hack up the netns code as well. In other words, it is being done to avoid maintenance, so that code changes may be hurried into the source tree. This upsets me, in that it seems to me that if someone makes an API change in one place, and avoids it in another, then the person who best understands the API change will be later unavailable to correct the code in which they avoided making the change. This is because, by avoiding the change in the first place, they have expressed a disinterest in making the change in the code in question. I would feel much more comfortable, were mainting older code, rather than diking it out, made part of the cost associated with making the API change in question. In other words, in order to write new code, it is sometimes necessary to maintain old code, and that maintenance is part of the price you must pay to the project in order to have your new code accepted. If this can not be accomplished, then I would submit that the new code be documented sufficiently before the dikeing out of the older code, such that someone else may take on the task of converting the code. Further, I suggest that there be some collaboration between the person making the changes, and anyone who wants to step forward in defense of the older code, such that there is an opportunity to correct the old code before it is diked out. In other words, it seems to me that the dike out is a "first strike" attack on code which will not LINT, following changes which are currently stored in someone local source tree, and the intent here is to dike out the code, and quickly follow it up with a set of commits which will kill it. Thus preventing it from "serving it's same purpose from the Attic". Practically, and historically, it seems that there are a lot of instances, recently, of code being diked out, not because it is not currently working, but because someone wished to avoid maintaining it in the face of some sweeping change or new idea they want to push into the project. Or if you prefer an analogy: it is one thing for bits to rot; it is another thing altogether to intentionally spray them with Agent Orange. Regards, -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 10:22: 4 2003 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 A3EF737B406; Tue, 4 Mar 2003 10:21:59 -0800 (PST) Received: from espresso.bsdmike.org (espresso.bsdmike.org [65.39.129.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DF4543FFB; Tue, 4 Mar 2003 10:17:20 -0800 (PST) (envelope-from mike@espresso.bsdmike.org) Received: by espresso.bsdmike.org (Postfix, from userid 1002) id 2C43D9C5F; Tue, 4 Mar 2003 13:03:36 -0500 (EST) Date: Tue, 4 Mar 2003 13:03:36 -0500 From: Mike Barcroft To: Terry Lambert Cc: Tim Robbins , freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Removal of netns - politically correct version Message-ID: <20030304130336.E70629@espresso.bsdmike.org> References: <20030305004730.A13129@dilbert.robbins.dropbear.id.au> <3E64CCAB.4C70108F@mindspring.com> <20030304112249.B70629@espresso.bsdmike.org> <3E64E740.9D1DC8B3@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E64E740.9D1DC8B3@mindspring.com>; from tlambert2@mindspring.com on Tue, Mar 04, 2003 at 09:49:52AM -0800 Organization: The FreeBSD Project 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 Terry Lambert writes: > Mike Barcroft wrote: > > Terry Lambert writes: > > > Tim Robbins wrote: > > > > Is there a compelling reason why I shouldn't remove netns? That is, does > > > > it serve a purpose now that it could not serve if it was moved to the > > > > Attic? > > > > > > Might as well move /sys/i386/conf/GENERIC to the attic while > > > you are at it. It can serve it's purpose from there, too. > > > > This comment is not helpful. > > Then let me politically correct it. This is much more useful, since you document your assertions which turn out to be incorrect (see below). > I am cynical about the ability of any code to serve the same purpose > from the Attic which it serves in the main source tree. > > What of the rest of my comment, which you removed? I'll > rephrase that, too: > > > Is there a compelling reason for removing this working code to > the Attic? Yes, the compelling reason is that it is broken and no one has stepped forward to fix it. Tim is trying to ascertain whether there are infact real users of this. Real users would either have big patchsets or very old versions of FreeBSD. > I am cynical that any purpose is served by making this change; > my cynicism leads me to believe that the intention of it is to > make it easier for someone to hack up other code which uses > related API's, without having to hack up the netns code as > well. The LINT option for Xerox NS protocols has been commented out since at least 1996. It's very unlikely there are actual FreeBSD users of said protocol. > In other words, it is being done to avoid maintenance, so that > code changes may be hurried into the source tree. No, Tim's goal is to clean up the tree and remove unused code, or find maintainers for broken code that indeed has users. [other comments based on false assertions removed.] > Practically, and historically, it seems that there are a lot > of instances, recently, of code being diked out, not because > it is not currently working, but because someone wished to > avoid maintaining it in the face of some sweeping change or > new idea they want to push into the project. I think most people just don't want to have to maintain code that no one uses. The only way we can figure out if anyone's using the code is to ask. Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 10:47:14 2003 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 A2C2437B401; Tue, 4 Mar 2003 10:47:13 -0800 (PST) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0628243FBD; Tue, 4 Mar 2003 10:47:12 -0800 (PST) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.8/8.12.7) with ESMTP id h24IlBHW021998; Tue, 4 Mar 2003 19:47:11 +0100 (CET) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.12.8/8.12.8/Submit) id h24IlAfP021997; Tue, 4 Mar 2003 19:47:10 +0100 (CET) Date: Tue, 4 Mar 2003 19:47:10 +0100 From: Wilko Bulte To: Terry Lambert Cc: Tim Robbins , freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns Message-ID: <20030304194710.D21561@freebie.xs4all.nl> References: <20030305004730.A13129@dilbert.robbins.dropbear.id.au> <3E64CCAB.4C70108F@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3E64CCAB.4C70108F@mindspring.com>; from tlambert2@mindspring.com on Tue, Mar 04, 2003 at 07:56:27AM -0800 X-OS: FreeBSD 4.8-RC X-PGP: finger wilko@freebsd.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 Tue, Mar 04, 2003 at 07:56:27AM -0800, Terry Lambert wrote: > Tim Robbins wrote: > > Is there a compelling reason why I shouldn't remove netns? That is, does > > it serve a purpose now that it could not serve if it was moved to the > > Attic? > > Might as well move /sys/i386/conf/GENERIC to the attic while > you are at it. It can serve it's purpose from there, too. > > Is there a compelling reason for doing this, other than "I > want to make some API/locking change, but I don't want to > have to keep this code working at the same time"? Maximizing Is there a compelling reason for you to moan about the removal of things constantly? -- | / o / /_ _ |/|/ / / /( (_) Bulte wilko@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 Mar 4 11:26: 9 2003 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 AE64F37B401; Tue, 4 Mar 2003 11:26:07 -0800 (PST) Received: from mel-rto3.wanadoo.fr (smtp-out-3.wanadoo.fr [193.252.19.233]) by mx1.FreeBSD.org (Postfix) with ESMTP id 184FC43FB1; Tue, 4 Mar 2003 11:26:06 -0800 (PST) (envelope-from vjardin@wanadoo.fr) Received: from mel-rta7.wanadoo.fr (193.252.19.61) by mel-rto3.wanadoo.fr (6.7.015) id 3E0C33B502AA885B; Tue, 4 Mar 2003 20:25:46 +0100 Received: from venus.vincentjardin.net (80.11.204.77) by mel-rta7.wanadoo.fr (6.7.015) id 3E5335B10078F805; Tue, 4 Mar 2003 20:25:43 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Vincent Jardin To: Tim Robbins , freebsd-net@freebsd.org Subject: Re: Removal of netns Date: Tue, 4 Mar 2003 20:25:25 +0100 User-Agent: KMail/1.4.3 Cc: freebsd-current@freebsd.org References: <20030305004730.A13129@dilbert.robbins.dropbear.id.au> In-Reply-To: <20030305004730.A13129@dilbert.robbins.dropbear.id.au> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200303042025.25227.vjardin@wanadoo.fr> 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 Why does it need to be removed ? According to me, it would be the same mi= stake=20 as the removal of netiso and netccitt. I did not know FreeBSD at this tim= e,=20 but nowadays, in order to get an OS that supports many stacks, we have to= use=20 NetBSD. BSD4.4 was designed in order to support many stacks, FreeBSD 6, 7 ou 9 wi= ll=20 support only IPv4 and IPv6, won't they ? I do not think that it needs to be removed. One should try to keep this=20 feature. Regards, Vincent Le Mardi 4 Mars 2003 14:47, Tim Robbins a =E9crit : > Is there a compelling reason why I shouldn't remove netns? That is, doe= s > it serve a purpose now that it could not serve if it was moved to the > Attic? > > > Tim > > 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 Tue Mar 4 11:34: 6 2003 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 DCF3B37B401; Tue, 4 Mar 2003 11:34:04 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB32143FA3; Tue, 4 Mar 2003 11:34:03 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h24JY1A6040580; Tue, 4 Mar 2003 20:34:01 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Vincent Jardin Cc: Tim Robbins , freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 04 Mar 2003 20:25:25 +0100." <200303042025.25227.vjardin@wanadoo.fr> Date: Tue, 04 Mar 2003 20:34:01 +0100 Message-ID: <40579.1046806441@critter.freebsd.dk> 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 message <200303042025.25227.vjardin@wanadoo.fr>, Vincent Jardin writes: >Why does it need to be removed ? According to me, it would be the same mistake >as the removal of netiso and netccitt. I did not know FreeBSD at this time, >but nowadays, in order to get an OS that supports many stacks, we have to use >NetBSD. > >BSD4.4 was designed in order to support many stacks, FreeBSD 6, 7 ou 9 will >support only IPv4 and IPv6, won't they ? We will import and retain any protocol stack which has enough interested users and committers to keep it alive. netiso and netccitt both fell for both of those criteria: neither users nor committers. netns fails both criteria too. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 11:40:28 2003 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 2636437B401; Tue, 4 Mar 2003 11:40:18 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A92D43FCB; Tue, 4 Mar 2003 11:40:17 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 022FD2A8BB; Tue, 4 Mar 2003 11:40:17 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Terry Lambert Cc: Mike Barcroft , Tim Robbins , freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Removal of netns - politically correct version In-Reply-To: <3E64E740.9D1DC8B3@mindspring.com> Date: Tue, 04 Mar 2003 11:40:17 -0800 From: Peter Wemm Message-Id: <20030304194017.022FD2A8BB@canning.wemm.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 Terry Lambert wrote: > Is there a compelling reason for removing this working code to > the Attic? Terry: will you please check your facts? It takes around 30 seconds to find out that it doesn't even compile. In file included from ../../../netns/idp_usrreq.c:51: ../../../netns/ns_pcb.h:82: warning: function declaration isn't a prototype ../../../netns/idp_usrreq.c:67: warning: return type defaults to `int' ../../../netns/idp_usrreq.c:67: warning: function declaration isn't a prototype ../../../netns/idp_usrreq.c: In function `idp_input': ../../../netns/idp_usrreq.c:83: incompatible types in assignment ../../../netns/idp_usrreq.c:83: structure has no member named `ifa_next' ../../../netns/idp_usrreq.c:101: warning: `return' with no value, in function returning non-void ../../../netns/idp_usrreq.c: At top level: ../../../netns/idp_usrreq.c:107: warning: return type defaults to `int' ../../../netns/idp_usrreq.c:107: warning: function declaration isn't a prototype ../../../netns/idp_usrreq.c: In function `idp_abort': ../../../netns/idp_usrreq.c:111: warning: implicit declaration of function `ns_pcbdisconnect' ../../../netns/idp_usrreq.c: At top level: ../../../netns/idp_usrreq.c:120: warning: function declaration isn't a prototype ../../../netns/idp_usrreq.c:141: warning: return type defaults to `int' ../../../netns/idp_usrreq.c:141: warning: function declaration isn't a prototype ../../../netns/idp_usrreq.c: In function `idp_output': ../../../netns/idp_usrreq.c:150: warning: nested extern declaration of `idpcksum' ../../../netns/idp_usrreq.c:184: warning: address of register variable `m' requested ../../../netns/idp_usrreq.c:200: too many arguments to function `ns_cksum' ../../../netns/idp_usrreq.c:209: warning: implicit declaration of function `ns_output' ../../../netns/idp_usrreq.c: At top level: ../../../netns/idp_usrreq.c:258: warning: return type defaults to `int' ../../../netns/idp_usrreq.c:258: warning: function declaration isn't a prototype ../../../netns/idp_usrreq.c: In function `idp_ctloutput': ../../../netns/idp_usrreq.c:266: warning: nested extern declaration of `ns_pexseq' ../../../netns/idp_usrreq.c: At top level: ../../../netns/idp_usrreq.c:369: warning: return type defaults to `int' ../../../netns/idp_usrreq.c:369: warning: function declaration isn't a prototype ../../../netns/idp_usrreq.c: In function `idp_usrreq': ../../../netns/idp_usrreq.c:377: warning: implicit declaration of function `ns_control' ../../../netns/idp_usrreq.c:394: warning: implicit declaration of function `ns_pcballoc' ../../../netns/idp_usrreq.c:407: warning: implicit declaration of function `ns_pcbdetach' ../../../netns/idp_usrreq.c:411: warning: implicit declaration of function `ns_pcbbind' ../../../netns/idp_usrreq.c:423: warning: implicit declaration of function `ns_pcbconnect' ../../../netns/idp_usrreq.c:493: warning: implicit declaration of function `ns_setsockaddr' ../../../netns/idp_usrreq.c:497: warning: implicit declaration of function `ns_setpeeraddr' ../../../netns/idp_usrreq.c: At top level: ../../../netns/idp_usrreq.c:531: warning: return type defaults to `int' ../../../netns/idp_usrreq.c:531: warning: function declaration isn't a prototype ../../../netns/idp_usrreq.c: In function `idp_raw_usrreq': ../../../netns/idp_usrreq.c:537: warning: nested extern declaration of `nsrawpcb' ../../../netns/idp_usrreq.c:543: `SS_PRIV' undeclared (first use in this function) ../../../netns/idp_usrreq.c:543: (Each undeclared identifier is reported only once ../../../netns/idp_usrreq.c:543: for each function it appears in.) In file included from ../../../netns/ns.c:40: ../../../sys/ioctl.h:47:2: #warning "Don't #include ioctl.h in the kernel. Include xxxio.h instead." In file included from ../../../netns/ns_error.c:49: ../../../netns/ns_pcb.h:82: warning: function declaration isn't a prototype ../../../netns/ns_error.c:66: warning: return type defaults to `int' ../../../netns/ns_error.c:66: warning: function declaration isn't a prototype ../../../netns/ns_error.c:91: warning: return type defaults to `int' ../../../netns/ns_error.c:91: warning: function declaration isn't a prototype ../../../netns/ns_error.c: In function `ns_error': ../../../netns/ns_error.c:98: warning: nested extern declaration of `idpcksum' ../../../netns/ns_error.c:107: warning: implicit declaration of function `ns_echo' ../../../netns/ns_error.c:108: warning: `return' with no value, in function returning non-void ../../../netns/ns_error.c:159: too many arguments to function `ns_cksum' ../../../netns/ns_error.c:162: warning: implicit declaration of function `ns_output' ../../../netns/ns_error.c: At top level: ../../../netns/ns_error.c:169: warning: return type defaults to `int' ../../../netns/ns_error.c:169: warning: function declaration isn't a prototype ../../../netns/ns_error.c:186: warning: return type defaults to `int' ../../../netns/ns_error.c:186: warning: function declaration isn't a prototype ../../../netns/ns_error.c: In function `ns_err_input': ../../../netns/ns_error.c:208: warning: `return' with no value, in function returning non-void ../../../netns/ns_error.c:266: warning: implicit declaration of function `spp_ctlinput' ../../../netns/ns_error.c:270: warning: implicit declaration of function `idp_ctlinput' ../../../netns/ns_error.c:189: warning: unused variable `epidp' ../../../netns/ns_error.c: At top level: ../../../netns/ns_error.c:299: warning: return type defaults to `int' ../../../netns/ns_error.c:299: warning: function declaration isn't a prototype ../../../netns/ns_error.c: In function `ns_echo': ../../../netns/ns_error.c:320: too many arguments to function `ns_cksum' In file included from ../../../netns/ns_input.c:57: ../../../netns/ns_pcb.h:82: warning: function declaration isn't a prototype ../../../netns/ns_input.c:74: warning: redundant redeclaration of `nspcb' in same scope ../../../netns/ns_pcb.h:81: warning: previous declaration of `nspcb' ../../../netns/ns_input.c:83: warning: return type defaults to `int' ../../../netns/ns_input.c:83: warning: function declaration isn't a prototype ../../../netns/ns_input.c: In function `ns_init': ../../../netns/ns_input.c:84: warning: nested extern declaration of `time' ../../../netns/ns_input.c: In function `nsintr': ../../../netns/ns_input.c:139: warning: implicit declaration of function `idp_input' ../../../netns/ns_input.c:144: warning: suggest parentheses around assignment used as truth value ../../../netns/ns_input.c:168: too many arguments to function `ns_cksum' ../../../netns/ns_input.c:175: warning: implicit declaration of function `ns_error' ../../../netns/ns_input.c:198: warning: implicit declaration of function `idp_forward' ../../../netns/ns_input.c:206: warning: redundant redeclaration of `idp_forward' in same scope ../../../netns/ns_input.c:198: warning: previous declaration of `idp_forward' ../../../netns/ns_input.c:225: warning: implicit declaration of function `spp_input' ../../../netns/ns_input.c:229: warning: implicit declaration of function `ns_err_input' ../../../netns/ns_input.c:232: warning: redundant redeclaration of `idp_input' in same scope ../../../netns/ns_input.c:139: warning: previous declaration of `idp_input' ../../../netns/ns_input.c:234: warning: redundant redeclaration of `ns_error' in same scope ../../../netns/ns_input.c:175: warning: previous declaration of `ns_error' ../../../netns/ns_input.c: At top level: ../../../netns/ns_input.c:254: warning: return type defaults to `int' ../../../netns/ns_input.c:254: warning: function declaration isn't a prototype ../../../netns/ns_input.c: In function `idp_ctlinput': ../../../netns/ns_input.c:260: warning: function declaration isn't a prototype ../../../netns/ns_input.c:260: warning: nested extern declaration of `idp_abort' ../../../netns/ns_input.c:261: warning: function declaration isn't a prototype ../../../netns/ns_input.c:261: warning: nested extern declaration of `idp_drop' ../../../netns/ns_input.c:265: warning: `return' with no value, in function returning non-void ../../../netns/ns_input.c:267: warning: `return' with no value, in function returning non-void ../../../netns/ns_input.c:277: warning: `return' with no value, in function returning non-void ../../../netns/ns_input.c:290: warning: implicit declaration of function `ns_pcbnotify' ../../../netns/ns_input.c: At top level: ../../../netns/ns_input.c:313: warning: return type defaults to `int' ../../../netns/ns_input.c:313: warning: function declaration isn't a prototype ../../../netns/ns_input.c: In function `idp_forward': ../../../netns/ns_input.c:325: warning: implicit declaration of function `ns_printhost' ../../../netns/ns_input.c:346: warning: implicit declaration of function `idp_do_route' ../../../netns/ns_input.c:358: too many arguments to function `ns_iaonnetof' ../../../netns/ns_input.c:395: warning: implicit declaration of function `ns_output' ../../../netns/ns_input.c:424: warning: implicit declaration of function `idp_undo_route' ../../../netns/ns_input.c: At top level: ../../../netns/ns_input.c:432: warning: return type defaults to `int' ../../../netns/ns_input.c:432: warning: function declaration isn't a prototype ../../../netns/ns_input.c:454: warning: return type defaults to `int' ../../../netns/ns_input.c:454: warning: function declaration isn't a prototype ../../../netns/ns_input.c:460: warning: return type defaults to `int' ../../../netns/ns_input.c:460: warning: function declaration isn't a prototype ../../../netns/ns_input.c: In function `ns_watch_output': ../../../netns/ns_input.c:480: incompatible types in assignment ../../../netns/ns_input.c:481: structure has no member named `ifa_next' ../../../netns/ns_output.c:58: warning: return type defaults to `int' ../../../netns/ns_output.c:58: warning: function declaration isn't a prototype ../../../netns/ns_output.c: In function `ns_output': ../../../netns/ns_output.c:67: warning: nested extern declaration of `idpcksum' ../../../netns/ns_output.c:80: warning: implicit declaration of function `bzero' ../../../netns/ns_output.c:93: too many arguments to function `ns_iaonnetof' ../../../netns/ns_output.c:139: warning: implicit declaration of function `ns_watch_output' ../../../netns/ns_output.c:149: warning: redundant redeclaration of `ns_watch_output' in same scope ../../../netns/ns_output.c:139: warning: previous declaration of `ns_watch_output' ../../../netns/ns_output.c:67: warning: unused variable `idpcksum' In file included from ../../../netns/ns_pcb.c:50: ../../../netns/ns_pcb.h:82: warning: function declaration isn't a prototype ../../../netns/ns_pcb.c:55: warning: return type defaults to `int' ../../../netns/ns_pcb.c:55: warning: function declaration isn't a prototype ../../../netns/ns_pcb.c: In function `ns_pcballoc': ../../../netns/ns_pcb.c:61: `MT_PCB' undeclared (first use in this function) ../../../netns/ns_pcb.c:61: (Each undeclared identifier is reported only once ../../../netns/ns_pcb.c:61: for each function it appears in.) ../../../netns/ns_pcb.c: At top level: ../../../netns/ns_pcb.c:72: warning: return type defaults to `int' ../../../netns/ns_pcb.c:72: warning: function declaration isn't a prototype ../../../netns/ns_pcb.c: In function `ns_pcbbind': ../../../netns/ns_pcb.c:98: `SS_PRIV' undeclared (first use in this function) ../../../netns/ns_pcb.c: At top level: ../../../netns/ns_pcb.c:122: warning: return type defaults to `int' ../../../netns/ns_pcb.c:122: warning: function declaration isn't a prototype ../../../netns/ns_pcb.c: In function `ns_pcbconnect': ../../../netns/ns_pcb.c:200: too many arguments to function `ns_iaonnetof' ../../../netns/ns_pcb.c: At top level: ../../../netns/ns_pcb.c:221: warning: return type defaults to `int' ../../../netns/ns_pcb.c:221: warning: function declaration isn't a prototype ../../../netns/ns_pcb.c: In function `ns_pcbdisconnect': ../../../netns/ns_pcb.c:226: warning: implicit declaration of function `ns_pcbdetach' ../../../netns/ns_pcb.c: At top level: ../../../netns/ns_pcb.c:230: warning: return type defaults to `int' ../../../netns/ns_pcb.c:230: warning: function declaration isn't a prototype ../../../netns/ns_pcb.c:243: warning: return type defaults to `int' ../../../netns/ns_pcb.c:243: warning: function declaration isn't a prototype ../../../netns/ns_pcb.c:257: warning: return type defaults to `int' ../../../netns/ns_pcb.c:257: warning: function declaration isn't a prototype ../../../netns/ns_pcb.c:278: warning: return type defaults to `int' ../../../netns/ns_pcb.c:278: warning: function declaration isn't a prototype ../../../netns/ns_pcb.c: In function `ns_pcbnotify': ../../../netns/ns_pcb.c:280: warning: function declaration isn't a prototype ../../../netns/ns_pcb.c: At top level: ../../../netns/ns_pcb.c:325: warning: function declaration isn't a prototype ../../../netns/ns_proto.c:51: warning: function declaration isn't a prototype ../../../netns/ns_proto.c:52: warning: function declaration isn't a prototype ../../../netns/ns_proto.c:52: warning: function declaration isn't a prototype ../../../netns/ns_proto.c:52: warning: function declaration isn't a prototype ../../../netns/ns_proto.c:52: warning: function declaration isn't a prototype ../../../netns/ns_proto.c:53: warning: function declaration isn't a prototype ../../../netns/ns_proto.c:53: warning: function declaration isn't a prototype ../../../netns/ns_proto.c:54: warning: function declaration isn't a prototype ../../../netns/ns_proto.c:54: warning: function declaration isn't a prototype ../../../netns/ns_proto.c:55: warning: function declaration isn't a prototype ../../../netns/ns_proto.c:55: warning: function declaration isn't a prototype ../../../netns/ns_proto.c:55: warning: function declaration isn't a prototype ../../../netns/ns_proto.c:56: warning: function declaration isn't a prototype ../../../netns/ns_proto.c:56: warning: function declaration isn't a prototype ../../../netns/ns_proto.c:56: warning: function declaration isn't a prototype ../../../netns/ns_proto.c:57: warning: function declaration isn't a prototype ../../../netns/ns_proto.c:59: warning: redundant redeclaration of `nsdomain' in same scope ../../../netns/ns.h:136: warning: previous declaration of `nsdomain' ../../../netns/ns_proto.c:65: warning: initialization from incompatible pointer type ../../../netns/ns_proto.c:68: warning: initialization from incompatible pointer type ../../../netns/ns_proto.c:73: warning: initialization from incompatible pointer type ../../../netns/ns_proto.c:73: warning: initialization from incompatible pointer type ../../../netns/ns_proto.c:75: warning: initialization from incompatible pointer type ../../../netns/ns_proto.c:75: warning: initialization from incompatible pointer type ../../../netns/ns_proto.c:75: warning: initialization from incompatible pointer type ../../../netns/ns_proto.c:78: warning: initialization from incompatible pointer type ../../../netns/ns_proto.c:78: warning: initialization from incompatible pointer type ../../../netns/ns_proto.c:83: warning: initialization from incompatible pointer type ../../../netns/ns_proto.c:88: warning: initialization from incompatible pointer type In file included from ../../../netns/spp_debug.c:52: ../../../netns/ns_pcb.h:82: warning: function declaration isn't a prototype In file included from ../../../netns/spp_debug.c:59: ../../../netns/spp_var.h:198: warning: function declaration isn't a prototype ../../../netns/spp_var.h:198: warning: function declaration isn't a prototype ../../../netns/spp_var.h:199: warning: function declaration isn't a prototype ../../../netns/spp_var.h:199: warning: function declaration isn't a prototype ../../../netns/spp_var.h:199: warning: function declaration isn't a prototype ../../../netns/spp_debug.c:68: warning: return type defaults to `int' ../../../netns/spp_debug.c:68: warning: function declaration isn't a prototype In file included from ../../../netns/spp_usrreq.c:51: ../../../netns/ns_pcb.h:82: warning: function declaration isn't a prototype In file included from ../../../netns/spp_usrreq.c:58: ../../../netns/spp_var.h:198: warning: function declaration isn't a prototype ../../../netns/spp_var.h:198: warning: function declaration isn't a prototype ../../../netns/spp_var.h:199: warning: function declaration isn't a prototype ../../../netns/spp_var.h:199: warning: function declaration isn't a prototype ../../../netns/spp_var.h:199: warning: function declaration isn't a prototype ../../../netns/spp_usrreq.c:65: warning: return type defaults to `int' ../../../netns/spp_usrreq.c:65: warning: function declaration isn't a prototype ../../../netns/spp_usrreq.c:78: warning: return type defaults to `int' ../../../netns/spp_usrreq.c:78: warning: function declaration isn't a prototype ../../../netns/spp_usrreq.c: In function `spp_input': ../../../netns/spp_usrreq.c:91: warning: `return' with no value, in function returning non-void ../../../netns/spp_usrreq.c:100: warning: `return' with no value, in function returning non-void ../../../netns/spp_usrreq.c:175: warning: implicit declaration of function `ns_pcbconnect' ../../../netns/spp_usrreq.c:182: warning: implicit declaration of function `spp_template' ../../../netns/spp_usrreq.c:250: warning: implicit declaration of function `spp_trace' ../../../netns/spp_usrreq.c:256: warning: implicit declaration of function `spp_reass' ../../../netns/spp_usrreq.c:260: warning: implicit declaration of function `spp_output' ../../../netns/spp_usrreq.c:262: warning: `return' with no value, in function returning non-void ../../../netns/spp_usrreq.c:270: warning: implicit declaration of function `ns_error' ../../../netns/spp_usrreq.c:273: warning: `return' with no value, in function returning non-void ../../../netns/spp_usrreq.c: At top level: ../../../netns/spp_usrreq.c:291: warning: return type defaults to `int' ../../../netns/spp_usrreq.c:291: warning: function declaration isn't a prototype ../../../netns/spp_usrreq.c: In function `spp_reass': ../../../netns/spp_usrreq.c:420: warning: suggest parentheses around && within || ../../../netns/spp_usrreq.c:420: warning: suggest parentheses around && within || ../../../netns/spp_usrreq.c:458: warning: redundant redeclaration of `ns_error' in same scope ../../../netns/spp_usrreq.c:447: warning: previous declaration of `ns_error' ../../../netns/spp_usrreq.c: At top level: ../../../netns/spp_usrreq.c:579: warning: return type defaults to `int' ../../../netns/spp_usrreq.c:579: warning: function declaration isn't a prototype ../../../netns/spp_usrreq.c: In function `spp_ctlinput': ../../../netns/spp_usrreq.c:583: warning: nested extern declaration of `nsctlerrmap' ../../../netns/spp_usrreq.c:584: warning: type defaults to `int' in declaration of `spp_abort' ../../../netns/spp_usrreq.c:584: warning: function declaration isn't a prototype ../../../netns/spp_usrreq.c:584: warning: nested extern declaration of `spp_abort' ../../../netns/spp_usrreq.c:584: warning: type defaults to `int' in declaration of `spp_quench' ../../../netns/spp_usrreq.c:584: warning: function declaration isn't a prototype ../../../netns/spp_usrreq.c:584: warning: nested extern declaration of `spp_quench' ../../../netns/spp_usrreq.c:585: warning: function declaration isn't a prototype ../../../netns/spp_usrreq.c:585: warning: nested extern declaration of `idp_drop' ../../../netns/spp_usrreq.c:592: warning: `return' with no value, in function returning non-void ../../../netns/spp_usrreq.c:598: warning: `return' with no value, in function returning non-void ../../../netns/spp_usrreq.c:605: warning: `return' with no value, in function returning non-void ../../../netns/spp_usrreq.c:618: warning: implicit declaration of function `ns_pcbnotify' ../../../netns/spp_usrreq.c: At top level: ../../../netns/spp_usrreq.c:643: warning: return type defaults to `int' ../../../netns/spp_usrreq.c:643: warning: function declaration isn't a prototype ../../../netns/spp_usrreq.c:700: warning: return type defaults to `int' ../../../netns/spp_usrreq.c:700: warning: function declaration isn't a prototype ../../../netns/spp_usrreq.c: In function `spp_output': ../../../netns/spp_usrreq.c:715: warning: nested extern declaration of `idpcksum' ../../../netns/spp_usrreq.c:940: warning: implicit declaration of function `spp_setpersist' ../../../netns/spp_usrreq.c:1079: too many arguments to function `ns_cksum' ../../../netns/spp_usrreq.c:1085: warning: redundant redeclaration of `spp_trace' in same scope ../../../netns/spp_usrreq.c:1018: warning: previous declaration of `spp_trace' ../../../netns/spp_usrreq.c:1088: warning: implicit declaration of function `ns_output' ../../../netns/spp_usrreq.c: At top level: ../../../netns/spp_usrreq.c:1115: warning: return type defaults to `int' ../../../netns/spp_usrreq.c:1115: warning: function declaration isn't a prototype ../../../netns/spp_usrreq.c: In function `spp_setpersist': ../../../netns/spp_usrreq.c:1117: warning: type defaults to `int' in declaration of `t' ../../../netns/spp_usrreq.c:1118: warning: nested extern declaration of `spp_backoff' ../../../netns/spp_usrreq.c:1118: warning: redundant redeclaration of `spp_backoff' in same scope ../../../netns/spp_timer.h:125: warning: previous declaration of `spp_backoff' ../../../netns/spp_usrreq.c: At top level: ../../../netns/spp_usrreq.c:1133: warning: return type defaults to `int' ../../../netns/spp_usrreq.c:1133: warning: function declaration isn't a prototype ../../../netns/spp_usrreq.c: In function `spp_ctloutput': ../../../netns/spp_usrreq.c:1146: warning: implicit declaration of function `idp_ctloutput' ../../../netns/spp_usrreq.c: At top level: ../../../netns/spp_usrreq.c:1258: warning: return type defaults to `int' ../../../netns/spp_usrreq.c:1258: warning: function declaration isn't a prototype ../../../netns/spp_usrreq.c: In function `spp_usrreq': ../../../netns/spp_usrreq.c:1270: warning: implicit declaration of function `ns_control' ../../../netns/spp_usrreq.c:1289: warning: implicit declaration of function `ns_pcballoc' ../../../netns/spp_usrreq.c:1299: `MT_PCB' undeclared (first use in this function) ../../../netns/spp_usrreq.c:1299: (Each undeclared identifier is reported only once ../../../netns/spp_usrreq.c:1299: for each function it appears in.) ../../../netns/spp_usrreq.c:1346: warning: implicit declaration of function `ns_pcbbind' ../../../netns/spp_usrreq.c:1477: warning: implicit declaration of function `ns_setsockaddr' ../../../netns/spp_usrreq.c:1481: warning: implicit declaration of function `ns_setpeeraddr' ../../../netns/spp_usrreq.c: At top level: ../../../netns/spp_usrreq.c:1510: warning: return type defaults to `int' ../../../netns/spp_usrreq.c:1510: warning: function declaration isn't a prototype ../../../netns/spp_usrreq.c:1531: warning: return type defaults to `int' ../../../netns/spp_usrreq.c:1531: warning: function declaration isn't a prototype ../../../netns/spp_usrreq.c:1559: warning: function declaration isn't a prototype ../../../netns/spp_usrreq.c: In function `spp_close': ../../../netns/spp_usrreq.c:1577: warning: implicit declaration of function `ns_pcbdetach' ../../../netns/spp_usrreq.c: At top level: ../../../netns/spp_usrreq.c:1588: warning: function declaration isn't a prototype ../../../netns/spp_usrreq.c:1594: warning: function declaration isn't a prototype ../../../netns/spp_usrreq.c:1604: warning: function declaration isn't a prototype ../../../netns/spp_usrreq.c:1625: warning: return type defaults to `int' ../../../netns/spp_usrreq.c:1625: warning: function declaration isn't a prototype ../../../netns/spp_usrreq.c:1637: warning: return type defaults to `int' ../../../netns/spp_usrreq.c:1637: warning: function declaration isn't a prototype ../../../netns/spp_usrreq.c:1661: warning: return type defaults to `int' ../../../netns/spp_usrreq.c:1661: warning: function declaration isn't a prototype ../../../netns/spp_usrreq.c: In function `spp_slowtimo': ../../../netns/spp_usrreq.c:1673: warning: `return' with no value, in function returning non-void ../../../netns/spp_usrreq.c: At top level: ../../../netns/spp_usrreq.c:1704: warning: function declaration isn't a prototype Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 11:43:44 2003 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 125F537B401; Tue, 4 Mar 2003 11:43:43 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7EB143FDF; Tue, 4 Mar 2003 11:43:41 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h24JhYA6040748; Tue, 4 Mar 2003 20:43:35 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Peter Wemm Cc: Terry Lambert , Mike Barcroft , Tim Robbins , freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns - politically correct version From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 04 Mar 2003 11:40:17 PST." <20030304194017.022FD2A8BB@canning.wemm.org> Date: Tue, 04 Mar 2003 20:43:34 +0100 Message-ID: <40747.1046807014@critter.freebsd.dk> 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 message <20030304194017.022FD2A8BB@canning.wemm.org>, Peter Wemm writes: >Terry Lambert wrote: > >> Is there a compelling reason for removing this working code to >> the Attic? > >Terry: will you please check your facts? It takes around 30 seconds >to find out that it doesn't even compile. Could we possibly move Terry to the attic too ? Please ? Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 11:44: 3 2003 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 89C1F37B401; Tue, 4 Mar 2003 11:44:01 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5898C43FCB; Tue, 4 Mar 2003 11:44:00 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 4196A2A89E; Tue, 4 Mar 2003 11:44:00 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "Poul-Henning Kamp" Cc: Vincent Jardin , Tim Robbins , freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns In-Reply-To: <40579.1046806441@critter.freebsd.dk> Date: Tue, 04 Mar 2003 11:44:00 -0800 From: Peter Wemm Message-Id: <20030304194400.4196A2A89E@canning.wemm.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 "Poul-Henning Kamp" wrote: > In message <200303042025.25227.vjardin@wanadoo.fr>, Vincent Jardin writes: > > >Why does it need to be removed ? According to me, it would be the same mista ke > >as the removal of netiso and netccitt. I did not know FreeBSD at this time, > >but nowadays, in order to get an OS that supports many stacks, we have to us e > >NetBSD. > > > >BSD4.4 was designed in order to support many stacks, FreeBSD 6, 7 ou 9 will > >support only IPv4 and IPv6, won't they ? > > We will import and retain any protocol stack which has enough interested > users and committers to keep it alive. > > netiso and netccitt both fell for both of those criteria: neither users > nor committers. > > netns fails both criteria too. Yep. It was removed in 1996 as well, because it didn't work. One company (Netcon) objected and claimed that they needed it for their commercial product and that they'd send fixes. Now, 7 years later, not a single person has shown the slightest interest in fixing it. It may as well have been left in the Attic the whole time. revision 1.7 date: 1996/10/17 18:42:19; author: jkh; state: Exp; lines: +3 -1 branches: 1.7.2; Bring back netns so that Netcon can take over support for it, as agreed. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 12:32:55 2003 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 5A92037B401; Tue, 4 Mar 2003 12:32:53 -0800 (PST) Received: from alpha.siliconlandmark.com (alpha.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA8BF43F85; Tue, 4 Mar 2003 12:32:49 -0800 (PST) (envelope-from andy@siliconlandmark.com) Received: from alpha.siliconlandmark.com (localhost [127.0.0.1]) by alpha.siliconlandmark.com (8.12.8/8.12.7) with ESMTP id h24KWnBq021823; Tue, 4 Mar 2003 15:32:49 -0500 (EST) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost) by alpha.siliconlandmark.com (8.12.8/8.12.7/Submit) with ESMTP id h24KWmvE021820; Tue, 4 Mar 2003 15:32:48 -0500 (EST) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: alpha.siliconlandmark.com: andy owned process doing -bs Date: Tue, 4 Mar 2003 15:32:48 -0500 (EST) From: Andre Guibert de Bruet To: Vincent Jardin Cc: freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns In-Reply-To: <200303042025.25227.vjardin@wanadoo.fr> Message-ID: <20030304151638.C59207@alpha.siliconlandmark.com> References: <20030305004730.A13129@dilbert.robbins.dropbear.id.au> <200303042025.25227.vjardin@wanadoo.fr> 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, 4 Mar 2003, Vincent Jardin wrote: > Why does it need to be removed ? According to me, it would be the same mistake > as the removal of netiso and netccitt. I did not know FreeBSD at this time, > but nowadays, in order to get an OS that supports many stacks, we have to use > NetBSD. If netns has so many users and our implementation has been broken for so long, why is it there hasn't been hordes of complaints? It appears as if users of netns are a rarity... > BSD4.4 was designed in order to support many stacks, FreeBSD 6, 7 ou 9 will > support only IPv4 and IPv6, won't they ? Today, widely-used networking applications use IPv4 and/or IPv6. It's understandable that as such, our IP stacks have gotten more testing and tuning than any other. If there's another networking protocol out there that has enough users interested and enough developer, vendor or device support, I don't see why it wouldn't be incorporated into the FreeBSD tree. A good example of a stack that was recently imported (comparatively speaking) would be Bluetooth. > I do not think that it needs to be removed. One should try to keep this > feature. As always, patches are welcome. If you happen to need netns for anything, scratch the itch... :-) Regards, > Andre Guibert de Bruet | Enterprise Software Consultant > > Silicon Landmark, LLC. | http://siliconlandmark.com/ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 13:25:58 2003 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 0E7C937B401 for ; Tue, 4 Mar 2003 13:25:58 -0800 (PST) Received: from gicco.homeip.net (dclient80-218-75-162.hispeed.ch [80.218.75.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4887C43F75 for ; Tue, 4 Mar 2003 13:25:56 -0800 (PST) (envelope-from hampi@rootshell.be) Received: from localhost.here (idefix@gicco.homeip.net [127.0.0.1]) by gicco.homeip.net (8.12.6/8.12.6) with ESMTP id h24LP8vB000597 for ; Tue, 4 Mar 2003 22:25:09 +0100 (CET) (envelope-from hampi@rootshell.be) Received: (from idefix@localhost) by localhost.here (8.12.6/8.12.6/Submit) id h24LP7hN000596 for freebsd-net@freebsd.org; Tue, 4 Mar 2003 22:25:08 +0100 (CET) X-Authentication-Warning: localhost.here: idefix set sender to hampi@rootshell.be using -f Date: Tue, 4 Mar 2003 22:25:07 +0100 From: Hanspeter Roth To: freebsd-net@freebsd.org Subject: amd causing dialup Message-ID: <20030304212507.GA550@gicco.homeip.net> Reply-To: freebsd-net@freebsd.org Mail-Followup-To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i 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 trying to setup amd on a host which has only localhost and a dialup network connection. When amd is started it causes a network connection on the tun0 interface. It seems to connect to ports 1023 and 1022. Several network servers can be configured to which address they should bind but I can't find something equivalent for amd. Is it possible to make amd bind to localhost only? -Hanspeter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 13:34:17 2003 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 5973037B401; Tue, 4 Mar 2003 13:34:15 -0800 (PST) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB3A443FBF; Tue, 4 Mar 2003 13:34:13 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from PHE (silver.he.iki.fi [193.64.42.241]) by silver.he.iki.fi (8.12.8/8.11.4) with SMTP id h24LYClL013528; Tue, 4 Mar 2003 23:34:12 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <0ded01c2e295$cbef0940$932a40c1@PHE> From: "Petri Helenius" To: , Subject: mbuf cache Date: Tue, 4 Mar 2003 23:34:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 did some profiling on -CURRENT from a few days back, and I think I haven´t figured the new tunables out or the code is not doing what it´s supposed to or I´m asking more than it is supposed to do but it seems that mb_free is being quite wasteful... Any pointers to how the new high/low watermark tunables should be used? Is it normal that after almost all traffic has been stopped there is still 8k+ mbufs in "cache"? Pete granularity: each sample hit covers 16 byte(s) for 0.00% of 708.90 seconds % cumulative self self total time seconds seconds calls ms/call ms/call name 18.9 134.04 134.04 778488459 0.00 0.00 mb_free [5] 10.0 204.99 70.95 290131104 0.00 0.00 ether_input [8] 9.0 268.46 63.47 __mcount [9] 6.3 313.42 44.96 198223061 0.00 0.00 m_move_pkthdr [15] 5.1 349.68 36.27 18238430 0.00 0.02 em_intr [2] 5.0 385.09 35.41 778488459 0.00 0.00 mb_alloc [17] 4.8 418.87 33.77 198510151 0.00 0.00 generic_bcopy [18] 4.5 450.64 31.77 2341 13.57 63.33 m_freem [4] 4.1 479.81 29.17 967684 0.03 0.03 call_fast_unpend [20] 3.5 504.53 24.72 17641942 0.00 0.01 em_process_receive_interru pts [3] 1.8 517.26 12.73 m_pullup [6] 1.6 528.51 11.25 290131104 0.00 0.00 em_get_buf [10] mbuf usage: GEN cache: 56/256 (in use/in pool) CPU #0 cache: 8138/12064 (in use/in pool) Total: 8194/12320 (in use/in pool) Mbuf cache high watermark: 4096 Mbuf cache low watermark: 128 Maximum possible: 51200 Allocated mbuf types: 8194 mbufs allocated to data 24% of mbuf map consumed mbuf cluster usage: GEN cache: 4/16 (in use/in pool) CPU #0 cache: 8188/12280 (in use/in pool) Total: 8192/12296 (in use/in pool) Cluster cache high watermark: 4096 Cluster cache low watermark: 16 Maximum possible: 25600 48% of cluster map consumed 27672 KBytes of wired memory reserved (66% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 13:37:44 2003 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 2C79B37B401; Tue, 4 Mar 2003 13:37:43 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A11343FAF; Tue, 4 Mar 2003 13:37:40 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0118.cvx21-bradley.dialup.earthlink.net ([209.179.192.118] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18qK6U-00016P-00; Tue, 04 Mar 2003 13:37:39 -0800 Message-ID: <3E651C37.17ACF643@mindspring.com> Date: Tue, 04 Mar 2003 13:35:51 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Wilko Bulte Cc: Tim Robbins , freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns References: <20030305004730.A13129@dilbert.robbins.dropbear.id.au> <3E64CCAB.4C70108F@mindspring.com> <20030304194710.D21561@freebie.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4987792cd64dbc1bbdf1a6ea6dfd763a6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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 Wilko Bulte wrote: > On Tue, Mar 04, 2003 at 07:56:27AM -0800, Terry Lambert wrote: > > Is there a compelling reason for doing this, other than "I > > want to make some API/locking change, but I don't want to > > have to keep this code working at the same time"? Maximizing > > Is there a compelling reason for you to moan about the removal > of things constantly? Things being removed constantly. If you will remember, there has been a rocky history with the removal of functionality in FreeBSD. If you don't remember, I will be happy to remind you of specific incidents that ended up causing a lot of grief, most of which I was not involved in, but merely watched from the sidelines. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 13:46:26 2003 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 34D5837B401; Tue, 4 Mar 2003 13:46:25 -0800 (PST) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7274543FA3; Tue, 4 Mar 2003 13:46:24 -0800 (PST) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id h24Lin510163; Tue, 4 Mar 2003 16:44:49 -0500 (EST) (envelope-from bmilekic@unixdaemons.com) Date: Tue, 4 Mar 2003 16:44:49 -0500 From: Bosko Milekic To: Petri Helenius Cc: freebsd-current@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: mbuf cache Message-ID: <20030304164449.A10136@unixdaemons.com> References: <0ded01c2e295$cbef0940$932a40c1@PHE> 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: <0ded01c2e295$cbef0940$932a40c1@PHE>; from pete@he.iki.fi on Tue, Mar 04, 2003 at 11:34:11PM +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 Tue, Mar 04, 2003 at 11:34:11PM +0200, Petri Helenius wrote: > > I did some profiling on -CURRENT from a few days back, and I think I haven´t > figured the new tunables out or the code is not doing what it´s supposed to > or I´m asking more than it is supposed to do but it seems that mb_free > is being quite wasteful... > > Any pointers to how the new high/low watermark tunables should be used? > > Is it normal that after almost all traffic has been stopped there is still 8k+ > mbufs in "cache"? > > Pete Yes, it's normal. The commit log clearly states that the new watermarks do nothing for now. I have a patch that changes that but I haven't committed it yet because I left for vacation last Sunday and I only returned early this Monday. Since then, I've been too busy to clean up and commit it. In about a week or so you should notice a difference. -- 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 Tue Mar 4 14:24:33 2003 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 3696A37B401; Tue, 4 Mar 2003 14:24:32 -0800 (PST) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2B8343FB1; Tue, 4 Mar 2003 14:24:30 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from PHE (silver.he.iki.fi [193.64.42.241]) by silver.he.iki.fi (8.12.8/8.11.4) with SMTP id h24MOSlL013809; Wed, 5 Mar 2003 00:24:29 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <0e1b01c2e29c$d1fefdc0$932a40c1@PHE> From: "Petri Helenius" To: "Bosko Milekic" Cc: , References: <0ded01c2e295$cbef0940$932a40c1@PHE> <20030304164449.A10136@unixdaemons.com> Subject: Re: mbuf cache Date: Wed, 5 Mar 2003 00:24:27 +0200 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.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 > > Yes, it's normal. The commit log clearly states that the new > watermarks do nothing for now. I have a patch that changes that but I > haven't committed it yet because I left for vacation last Sunday and I > only returned early this Monday. Since then, I've been too busy to > clean up and commit it. In about a week or so you should notice a > difference. > Any comments on the high cpu consumption of mb_free? Or any other places where I should look to improve performance? Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 14:39:45 2003 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 35D8937B401; Tue, 4 Mar 2003 14:39:44 -0800 (PST) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51FB543F85; Tue, 4 Mar 2003 14:39:43 -0800 (PST) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id h24Mc9D10411; Tue, 4 Mar 2003 17:38:09 -0500 (EST) (envelope-from bmilekic@unixdaemons.com) Date: Tue, 4 Mar 2003 17:38:09 -0500 From: Bosko Milekic To: Petri Helenius Cc: freebsd-current@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: mbuf cache Message-ID: <20030304173809.A10373@unixdaemons.com> References: <0ded01c2e295$cbef0940$932a40c1@PHE> <20030304164449.A10136@unixdaemons.com> <0e1b01c2e29c$d1fefdc0$932a40c1@PHE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <0e1b01c2e29c$d1fefdc0$932a40c1@PHE>; from pete@he.iki.fi on Wed, Mar 05, 2003 at 12:24:27AM +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 Wed, Mar 05, 2003 at 12:24:27AM +0200, Petri Helenius wrote: > > > > Yes, it's normal. The commit log clearly states that the new > > watermarks do nothing for now. I have a patch that changes that but I > > haven't committed it yet because I left for vacation last Sunday and I > > only returned early this Monday. Since then, I've been too busy to > > clean up and commit it. In about a week or so you should notice a > > difference. > > > Any comments on the high cpu consumption of mb_free? Or any other places > where I should look to improve performance? What do you mean "high cpu consumption?" The common case of mb_free() is this: bucket = mb_list->ml_btable[MB_BUCKET_INDX(m, mb_list)]; owner = bucket->mb_owner & ~MB_BUCKET_FREE; switch (owner) { ... default: cnt_lst = MB_GET_PCPU_LIST_NUM(mb_list, owner); MB_PUT_OBJECT(m, bucket, cnt_lst); MB_MBTYPES_DEC(cnt_lst, type, 1); if (bucket->mb_owner & MB_BUCKET_FREE) { SLIST_INSERT_HEAD(&(cnt_lst->mb_cont.mc_bhead), bucket, mb_blist); bucket->mb_owner = cnt_lst->mb_cont.mc_numowner; } } That's the common path, modulo a couple checks on whether or not the container being freed to needs to be moved or whether we're in a starvation situation. The only thing to be done, possibly, is make the routine smaller by moving those couple of actions to seperate routines, but I'm not clear that this is very useful, given that mb_free()'s usage is restricted to only inside subr_mbuf.c > Pete -- 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 Tue Mar 4 14:54: 1 2003 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 9D31437B401; Tue, 4 Mar 2003 14:54:00 -0800 (PST) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03DE843FBD; Tue, 4 Mar 2003 14:54:00 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by rwcrmhc52.attbi.com (rwcrmhc52) with ESMTP id <2003030422535905200pqqste>; Tue, 4 Mar 2003 22:53:59 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA53606; Tue, 4 Mar 2003 14:53:58 -0800 (PST) Date: Tue, 4 Mar 2003 14:53:56 -0800 (PST) From: Julian Elischer To: Tim Robbins Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Removal of netns In-Reply-To: <20030305004730.A13129@dilbert.robbins.dropbear.id.au> 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 I thought nwfs used it? On Wed, 5 Mar 2003, Tim Robbins wrote: > Is there a compelling reason why I shouldn't remove netns? That is, does > it serve a purpose now that it could not serve if it was moved to the > Attic? > > > Tim > > 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 Tue Mar 4 15:13: 1 2003 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 54E9637B401; Tue, 4 Mar 2003 15:12:59 -0800 (PST) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9F5443FBF; Tue, 4 Mar 2003 15:12:57 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from PHE (silver.he.iki.fi [193.64.42.241]) by silver.he.iki.fi (8.12.8/8.11.4) with SMTP id h24NCulL014178; Wed, 5 Mar 2003 01:12:56 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <0e2b01c2e2a3$96fd3b40$932a40c1@PHE> From: "Petri Helenius" To: "Bosko Milekic" Cc: , References: <0ded01c2e295$cbef0940$932a40c1@PHE> <20030304164449.A10136@unixdaemons.com> <0e1b01c2e29c$d1fefdc0$932a40c1@PHE> <20030304173809.A10373@unixdaemons.com> Subject: Re: mbuf cache Date: Wed, 5 Mar 2003 01:12:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 > > Any comments on the high cpu consumption of mb_free? Or any other places > > where I should look to improve performance? > > What do you mean "high cpu consumption?" The common case of mb_free() > is this: According to profiling mb_free takes 18.9% of all time consumed in kernel and is almost double to next cpu consuming function. Since I´m looking how to optimize the system, it´s usually a good idea to start looking where most CPU is spent. For example, I´m wondering if mbufs get unneccessarily freed and allocated or thrown around different buckets because of the tunables are wrong. I´m not saying that there must be something wrong with the code itself. For example what does "in use" mean below: There is no way there is enough traffic on the system to allocate 7075 mbufs when this netstat -m was taken. mbuf usage: GEN cache: 0/0 (in use/in pool) CPU #0 cache: 7075/8896 (in use/in pool) CPU #1 cache: 1119/4864 (in use/in pool) Total: 8194/13760 (in use/in pool) Mbuf cache high watermark: 8192 Mbuf cache low watermark: 128 Pete > > bucket = mb_list->ml_btable[MB_BUCKET_INDX(m, mb_list)]; > owner = bucket->mb_owner & ~MB_BUCKET_FREE; > switch (owner) { > ... > default: > cnt_lst = MB_GET_PCPU_LIST_NUM(mb_list, owner); > MB_PUT_OBJECT(m, bucket, cnt_lst); > MB_MBTYPES_DEC(cnt_lst, type, 1); > if (bucket->mb_owner & MB_BUCKET_FREE) { > SLIST_INSERT_HEAD(&(cnt_lst->mb_cont.mc_bhead), > bucket, > mb_blist); > bucket->mb_owner = cnt_lst->mb_cont.mc_numowner; > } > } > > That's the common path, modulo a couple checks on whether or not the > container being freed to needs to be moved or whether we're in a > starvation situation. The only thing to be done, possibly, is make > the routine smaller by moving those couple of actions to seperate > routines, but I'm not clear that this is very useful, given that > mb_free()'s usage is restricted to only inside subr_mbuf.c > > > Pete > > -- > 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 Tue Mar 4 15:17:16 2003 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 8197037B401; Tue, 4 Mar 2003 15:17:15 -0800 (PST) Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id C805843FB1; Tue, 4 Mar 2003 15:17:11 -0800 (PST) (envelope-from hiten@angelica.unixdaemons.com) Received: from angelica.unixdaemons.com (localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.7/8.12.1) with ESMTP id h24NGwjL001043; Tue, 4 Mar 2003 18:16:58 -0500 (EST) Received: (from hiten@localhost) by angelica.unixdaemons.com (8.12.7/8.12.1/Submit) id h24NGvxl001042; Tue, 4 Mar 2003 18:16:57 -0500 (EST) (envelope-from hiten) Date: Tue, 4 Mar 2003 18:16:57 -0500 From: Hiten Pandya To: Julian Elischer Cc: Tim Robbins , freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns Message-ID: <20030304231657.GA99686@unixdaemons.com> References: <20030305004730.A13129@dilbert.robbins.dropbear.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Operating-System: FreeBSD i386 X-Public-Key: http://www.pittgoth.com/~hiten/pubkey.asc X-URL: http://www.unixdaemons.com/~hiten X-PGP: http://pgp.mit.edu:11371/pks/lookup?search=Hiten+Pandya&op=index 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 (Tue, Mar 04, 2003 at 02:53:56PM -0800) wrote: > I thought nwfs used it? > > > On Wed, 5 Mar 2003, Tim Robbins wrote: > > > Is there a compelling reason why I shouldn't remove netns? That is, does > > it serve a purpose now that it could not serve if it was moved to the > > Attic? That's netncp if I am not mistaken and thanks to Tim and Max Khon, it's now fixed, IIRC. Kudos to them. :-) -- Hiten Pandya (hiten@unixdaemons.com, hiten@uk.FreeBSD.org) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 15:23:10 2003 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 B36E537B401; Tue, 4 Mar 2003 15:23:08 -0800 (PST) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id C889143FE1; Tue, 4 Mar 2003 15:23:07 -0800 (PST) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id h24NLXB10594; Tue, 4 Mar 2003 18:21:33 -0500 (EST) (envelope-from bmilekic@unixdaemons.com) Date: Tue, 4 Mar 2003 18:21:33 -0500 From: Bosko Milekic To: Petri Helenius Cc: freebsd-current@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: mbuf cache Message-ID: <20030304182133.A10561@unixdaemons.com> References: <0ded01c2e295$cbef0940$932a40c1@PHE> <20030304164449.A10136@unixdaemons.com> <0e1b01c2e29c$d1fefdc0$932a40c1@PHE> <20030304173809.A10373@unixdaemons.com> <0e2b01c2e2a3$96fd3b40$932a40c1@PHE> 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: <0e2b01c2e2a3$96fd3b40$932a40c1@PHE>; from pete@he.iki.fi on Wed, Mar 05, 2003 at 01:12:55AM +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 Wed, Mar 05, 2003 at 01:12:55AM +0200, Petri Helenius wrote: > > > Any comments on the high cpu consumption of mb_free? Or any other places > > > where I should look to improve performance? > > > > What do you mean "high cpu consumption?" The common case of mb_free() > > is this: > > According to profiling mb_free takes 18.9% of all time consumed in kernel and is > almost double to next cpu consuming function. Since I´m looking how to optimize > the system, it´s usually a good idea to start looking where most CPU is spent. > > For example, I´m wondering if mbufs get unneccessarily freed and allocated or thrown > around different buckets because of the tunables are wrong. I´m not saying that > there must be something wrong with the code itself. > > For example what does "in use" mean below: There is no way there is enough > traffic on the system to allocate 7075 mbufs when this netstat -m was taken. > > mbuf usage: > GEN cache: 0/0 (in use/in pool) > CPU #0 cache: 7075/8896 (in use/in pool) > CPU #1 cache: 1119/4864 (in use/in pool) > Total: 8194/13760 (in use/in pool) > Mbuf cache high watermark: 8192 > Mbuf cache low watermark: 128 > > > Pete This does look odd... maybe there's a leak somewhere... does "in use" go back down to a much lower number eventually? What kind of test are you running? "in pool" means that that's the number in the cache while "in use" means that that's the number out of the cache currently being used by the system; but if you're telling me that there's no way usage could be that high while you ran the netstat, either there's a serious leak somewhere or I got the stats wrong (anyone else notice irregular stats?) Another thing I find odd about those stats is that you've set the high watermark to 8192, which means that in the next free, you should be moving buckets to the general cache... see if that's really happening... The low watermark doesn't affect anything right now. Can you give me more details on the exact type of test you're running? Let's move this to -current instead of -current and -net please (feel free to trim the one you want), getting 3 copies of the same message all the time is kinda annoying. :-( -- 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 Tue Mar 4 15:27:32 2003 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 EBF8737B401; Tue, 4 Mar 2003 15:27:31 -0800 (PST) Received: from smtp02.syd.iprimus.net.au (smtp02.syd.iprimus.net.au [210.50.76.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED59D43F93; Tue, 4 Mar 2003 15:27:30 -0800 (PST) (envelope-from tim@robbins.dropbear.id.au) Received: from dilbert.robbins.dropbear.id.au ([210.50.112.207]) by smtp02.syd.iprimus.net.au with Microsoft SMTPSVC(5.0.2195.5600); Wed, 5 Mar 2003 10:27:19 +1100 Received: from dilbert.robbins.dropbear.id.au (v3hh252nn5jjxn9o@localhost [127.0.0.1]) by dilbert.robbins.dropbear.id.au (8.12.6/8.12.6) with ESMTP id h24NQTJK029156; Wed, 5 Mar 2003 10:26:37 +1100 (EST) (envelope-from tim@dilbert.robbins.dropbear.id.au) Received: (from tim@localhost) by dilbert.robbins.dropbear.id.au (8.12.6/8.12.6/Submit) id h24NQNUd029152; Wed, 5 Mar 2003 10:26:23 +1100 (EST) (envelope-from tim) Date: Wed, 5 Mar 2003 10:26:17 +1100 From: Tim Robbins To: Julian Elischer Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Removal of netns Message-ID: <20030305102617.A27891@dilbert.robbins.dropbear.id.au> References: <20030305004730.A13129@dilbert.robbins.dropbear.id.au> 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 Tue, Mar 04, 2003 at 02:53:56PM -0800 X-OriginalArrivalTime: 04 Mar 2003 23:27:25.0724 (UTC) FILETIME=[9D5AA5C0:01C2E2A5] 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, Mar 04, 2003 at 02:53:56PM -0800, Julian Elischer wrote: > I thought nwfs used it? nwfs uses netipx. From what I can tell, netipx was based on netns. Tim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 15:33:53 2003 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 CB3DB37B401; Tue, 4 Mar 2003 15:33:51 -0800 (PST) Received: from www.linuxiceberg.com (66-23-198-2.clients.speedfactory.net [66.23.198.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA77A43FBD; Tue, 4 Mar 2003 15:33:49 -0800 (PST) (envelope-from cfowler@outpostsentinel.com) Received: from [192.168.1.7] ([192.168.1.7]) by firewall.outpostsentinel.com (8.11.6/8.11.6) with ESMTP id h24NVt301781; Tue, 4 Mar 2003 18:31:56 -0500 Subject: Re: Removal of netns From: Chris Fowler To: Tim Robbins Cc: Julian Elischer , freebsd-net@freebsd.org, freebsd-current@freebsd.org In-Reply-To: <20030305102617.A27891@dilbert.robbins.dropbear.id.au> References: <20030305004730.A13129@dilbert.robbins.dropbear.id.au> <20030305102617.A27891@dilbert.robbins.dropbear.id.au> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 04 Mar 2003 18:32:03 -0500 Message-Id: <1046820725.6491.53.camel@devel> 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 What is IPX currently being used for? Legacy systems? I've been stuck in TCP/IP land for many years now. Have been lucky enough to not run into any IPX. On Tue, 2003-03-04 at 18:26, Tim Robbins wrote: > On Tue, Mar 04, 2003 at 02:53:56PM -0800, Julian Elischer wrote: > > > I thought nwfs used it? > > nwfs uses netipx. From what I can tell, netipx was based on netns. > > > Tim > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" 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 Tue Mar 4 15:44:47 2003 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 5866E37B401; Tue, 4 Mar 2003 15:44:46 -0800 (PST) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B3B143F93; Tue, 4 Mar 2003 15:44:45 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0118.cvx21-bradley.dialup.earthlink.net ([209.179.192.118] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18qM5T-0001HC-00; Tue, 04 Mar 2003 15:44:44 -0800 Message-ID: <3E6539B5.2F5D31B@mindspring.com> Date: Tue, 04 Mar 2003 15:41:41 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: Mike Barcroft , Tim Robbins , freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Removal of netns - politically correct version References: <20030304194017.022FD2A8BB@canning.wemm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4cbf330b939d2044a44604bf394e01467350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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 Peter Wemm wrote: > Terry Lambert wrote: > > Is there a compelling reason for removing this working code to > > the Attic? > > Terry: will you please check your facts? It takes around 30 seconds > to find out that it doesn't even compile. [ ... lots of trivial to fix warnings and errors ... ] Tell you what, I'll fix these and post a patch. Will that make you guys happy? This crap is *soooooooo* trivial to fix, it's easier to fix than to watch you guys bitch about it not being fixable. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 15:49:11 2003 Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id BFD6937B401; Tue, 4 Mar 2003 15:49:09 -0800 (PST) Date: Tue, 4 Mar 2003 17:49:09 -0600 From: Juli Mallett To: Terry Lambert Cc: Peter Wemm , Mike Barcroft , Tim Robbins , freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Removal of netns - politically correct version Message-ID: <20030304174909.A53897@FreeBSD.org> References: <20030304194017.022FD2A8BB@canning.wemm.org> <3E6539B5.2F5D31B@mindspring.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: <3E6539B5.2F5D31B@mindspring.com>; from tlambert2@mindspring.com on Tue, Mar 04, 2003 at 03:41:41PM -0800 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , , X-Towel: Yes X-Negacore: Yes X-Title: Code Maven 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: Terry Lambert [ Data: 2003-03-04 ] [ Subjecte: Re: Removal of netns - politically correct version ] > Peter Wemm wrote: > > Terry Lambert wrote: > > > Is there a compelling reason for removing this working code to > > > the Attic? > > > > Terry: will you please check your facts? It takes around 30 seconds > > to find out that it doesn't even compile. > > [ ... lots of trivial to fix warnings and errors ... ] > > > Tell you what, I'll fix these and post a patch. Will that make you > guys happy? > > This crap is *soooooooo* trivial to fix, it's easier to fix than > to watch you guys bitch about it not being fixable. Terry, watch your language. And then find me a site running XNS that expects to be running a current version of FreeBSD, or ideally someone I could peer an XNS system with if I were to take up maintainership of it? You have until the code is gone from CVS, which hopefully will be very soon. Thanx, juli. PS: I might be interested in getting it out of the attic if you could find me a good place for XNS-only connectivity, with IP-over-XNS of some sort so I could still IRC. -- juli mallett. email: jmallett@freebsd.org; aim: bsdflata; efnet: juli; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 16: 0:26 2003 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 2A0FA37B405; Tue, 4 Mar 2003 16:00:24 -0800 (PST) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7458A43FE3; Tue, 4 Mar 2003 16:00:23 -0800 (PST) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id B40E514352; Tue, 4 Mar 2003 18:00:22 -0600 (CST) Date: Tue, 4 Mar 2003 18:00:22 -0600 (CST) From: Mark Linimon X-X-Sender: linimon@pancho To: Terry Lambert Cc: freebsd-net@freebsd.org, Subject: Re: Removal of netns - politically correct version In-Reply-To: <3E6539B5.2F5D31B@mindspring.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 Tue, 4 Mar 2003, Terry Lambert wrote: > Tell you what, I'll fix these and post a patch. Will that make you > guys happy? Yes, as will anything else that cuts down on the metadiscussions and increases the quality of the codebase. mcl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 16: 3: 7 2003 Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 91DCB37B401; Tue, 4 Mar 2003 16:03:06 -0800 (PST) Date: Tue, 4 Mar 2003 18:03:06 -0600 From: Juli Mallett To: Mark Linimon Cc: Terry Lambert , freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Removal of netns - politically correct version Message-ID: <20030304180306.A55803@FreeBSD.org> References: <3E6539B5.2F5D31B@mindspring.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 linimon@lonesome.com on Tue, Mar 04, 2003 at 06:00:22PM -0600 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , , X-Towel: Yes X-Negacore: Yes X-Title: Code Maven 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: Mark Linimon [ Data: 2003-03-04 ] [ Subjecte: Re: Removal of netns - politically correct version ] > On Tue, 4 Mar 2003, Terry Lambert wrote: > > Tell you what, I'll fix these and post a patch. Will that make you > > guys happy? > > Yes, as will anything else that cuts down on the metadiscussions and > increases the quality of the codebase. No, it screws up the quality of the codebase if it cannot be tested and used every day, and I doubt Terry will be doing real testing. HOWEVER, I am willing to keep netns working if someone can provide a pure XNS with IP-over-XNS provider. Playing around using multiple FreeBSD boxen with a possibly broken but interoperable implementation is also out of the question, as nobody uses it. For things that people actually use, it's OK as prototyping fixes and getting them in tree, and then the users can find where it's broken later. -- juli mallett. email: jmallett@freebsd.org; aim: bsdflata; efnet: juli; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 16: 7:19 2003 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 25C7B37B405; Tue, 4 Mar 2003 16:07:17 -0800 (PST) Received: from mail.backtech.com (wilma.backtech.com [209.198.99.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id A017743FE0; Tue, 4 Mar 2003 16:07:15 -0800 (PST) (envelope-from dexter@backtech.com) Received: by net-1.backtech.com (Postfix, from userid 1001) id 68EDA593C; Mon, 3 Mar 2003 23:46:07 -0500 (EST) Date: Mon, 3 Mar 2003 23:46:07 -0500 From: Dexter McNeil To: Bill Paul Cc: freebsd-net@freebsd.org Subject: PCN driver broken (was: Re: Checksum offload support for Intel 82550/82551) Message-ID: <20030304044607.GA23496@net-1.backtech.com> References: <20030226070913.5404337B401@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030226070913.5404337B401@hub.freebsd.org> User-Agent: Mutt/1.5.3i 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, Feb 25, 2003 at 11:09:13PM -0800, Bill Paul wrote: > > Hello, > > > > > Yes, it's me. I'm still alive. > > It's great to hear that one of the most talented FreeBSD hackers is back > > in business :) > > > > Does this means that you can afford some time to investigate the problems > > regarding your old software? > > Not unless it's something I can fix using easily available resources. > I can't easily drop everything and slap together a test setup with > exactly the right software and hardware I need to debug everyone's > particular problem. ("This bug only occurs in -CURRENT as of 30 > seconds ago and on an UltraSPARC 10 with 16 if_dc interfaces and > I need you to fix it _NOW_ pleasepleasepleaseI'llevengiveyouahandjob.") On the same basic subject - it seems that sometime after the release of FreeBSD 4.3 the pcn ethernet driver was broken. I did find PR kern/34071 which indicated that the driver was broken in 4.5RC2. I've tried the following versions of FreeBSD from the fixit CDROMS: 4.3 - works fine 4.4 - doesn't work - ping can't get to the outside world (host unreachable - it's a directly connected machine I'm trying to ping...), though interface status info appears good as reported by ifconfig. Media & mediaopt options don't seem to make any difference. While the line will go to half-duplex or 10baseT/UTP modes, it doesn't solve the problem of not getting bits out the door... 4.5 - same as 4.4 4.6.2 - doesn't work - after ifconfig'ing the interface with an IP address & such, ifconfig reports that the interface is in hardware loopback. This is confirmed by the loss of link status on the switch the interface is connected to. Media & mediaopt options don't change this state. 4.7 - same as 4.6.2 4.8-prerelease - same as 4.6.2 5.0 - has the same issues as 4.6.2. The main interest in this driver is that IBM uses the AMD 79C971 chip with a National Semiconductor DP83840 PHY on the motherboard in the Netfinity 5500 server. The 79C971 chip with a Level 1 PHY is used in their fault tolerant 10/100 PCI NIC of the same vintage. I've got a number of these machines that I need/want to run FreeBSD on. I can make a quad cpu 5500 machine available for remote login, with additional access via a second machine to the serial console for test/debug/etc if this will help get the problem fixed. Let me know what has to be added to the system/test setup and I'll do my best to get it together. I'm happy to apply patches, test, compile, etc. as well. Regards, Dexter McNeil To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 16:15: 5 2003 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 C68FF37B401 for ; Tue, 4 Mar 2003 16:15:03 -0800 (PST) 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 AF30B43FAF for ; Tue, 4 Mar 2003 16:15:02 -0800 (PST) (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 QAA58381 for ; Tue, 4 Mar 2003 16:04:55 -0800 (PST) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id h2504sn6012404 for ; Tue, 4 Mar 2003 16:04:54 -0800 (PST) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id h2504sbY012403 for freebsd-net@freebsd.org; Tue, 4 Mar 2003 16:04:54 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200303050004.h2504sbY012403@arch20m.dellroad.org> Subject: Mysterious MPD hangs? Please try this patch To: freebsd-net@freebsd.org Date: Tue, 4 Mar 2003 16:04:54 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL99b (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 Hi, For anyone who's using MPD with multilink PPP enabled and is experiencing mysterious "hangs" where no data gets through for an extended period of time, please try the patch below. Thanks to Matthew Impett for finding the bug. -Archie __________________________________________________________________________ Archie Cobbs * Precision I/O * http://www.precisionio.com Index: sys/netgraph/ng_ppp.c =================================================================== RCS file: /home/cvs/freebsd/src/sys/netgraph/ng_ppp.c,v retrieving revision 1.15.2.9 diff -u -r1.15.2.9 ng_ppp.c --- sys/netgraph/ng_ppp.c 2 Jul 2002 23:44:03 -0000 1.15.2.9 +++ sys/netgraph/ng_ppp.c 5 Mar 2003 00:00:48 -0000 @@ -1370,6 +1370,7 @@ struct mbuf *m; meta_p meta; int i, seq; + int endseq; now.tv_sec = 0; /* uninitialized state */ while (1) { @@ -1419,11 +1420,12 @@ } /* Extract completed packet */ + endseq = end->seq; ng_ppp_get_packet(node, &m, &meta); /* Bump MSEQ if necessary */ - if (MP_RECV_SEQ_DIFF(priv, priv->mseq, end->seq) < 0) { - priv->mseq = end->seq; + if (MP_RECV_SEQ_DIFF(priv, priv->mseq, endseq) < 0) { + priv->mseq = endseq; for (i = 0; i < priv->numActiveLinks; i++) { struct ng_ppp_link *const alink = &priv->links[priv->activeLinks[i]]; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 16:31:47 2003 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 1318837B401; Tue, 4 Mar 2003 16:31:46 -0800 (PST) Received: from obsecurity.dyndns.org (adsl-63-207-60-52.dsl.lsan03.pacbell.net [63.207.60.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F11343FA3; Tue, 4 Mar 2003 16:31:44 -0800 (PST) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id 102F766D32; Tue, 4 Mar 2003 16:31:44 -0800 (PST) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id 06C79110C; Tue, 4 Mar 2003 16:31:44 -0800 (PST) Date: Tue, 4 Mar 2003 16:31:43 -0800 From: Kris Kennaway To: Terry Lambert Cc: Wilko Bulte , Tim Robbins , freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns Message-ID: <20030305003143.GA94234@rot13.obsecurity.org> References: <20030305004730.A13129@dilbert.robbins.dropbear.id.au> <3E64CCAB.4C70108F@mindspring.com> <20030304194710.D21561@freebie.xs4all.nl> <3E651C37.17ACF643@mindspring.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline In-Reply-To: <3E651C37.17ACF643@mindspring.com> User-Agent: Mutt/1.4i 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 --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 04, 2003 at 01:35:51PM -0800, Terry Lambert wrote: > Things being removed constantly. >=20 > If you will remember, there has been a rocky history with the > removal of functionality in FreeBSD. If you don't remember, > I will be happy to remind you of specific incidents that ended > up causing a lot of grief, most of which I was not involved in, > but merely watched from the sidelines. I'm hard-pressed to think of any change to FreeBSD that you have not involved yourself in ;-) Kris --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+ZUVvWry0BWjoQKURAnIRAKCAiOnTosdN2peryKr88qIbcJvM3ACfZ4uL oXLivFOlgA/ioaBJQSjKJGs= =WMGQ -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 16:38:18 2003 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 1855237B401 for ; Tue, 4 Mar 2003 16:38:17 -0800 (PST) Received: from mail2.dbitech.ca (radius.wavefire.com [64.141.13.252]) by mx1.FreeBSD.org (Postfix) with SMTP id 14B7143F75 for ; Tue, 4 Mar 2003 16:38:15 -0800 (PST) (envelope-from darcy@wavefire.com) Received: (qmail 16219 invoked from network); 5 Mar 2003 00:59:15 -0000 Received: from dbitech.wavefire.com (HELO dbitech) (darcy@64.141.15.253) by radius.wavefire.com with SMTP; 5 Mar 2003 00:59:15 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Darcy Buskermolen Organization: Wavefire Technologies Corp. To: Chris Fowler Subject: Re: Removal of netns Date: Tue, 4 Mar 2003 16:38:13 -0800 User-Agent: KMail/1.4.3 Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org References: <20030305004730.A13129@dilbert.robbins.dropbear.id.au> <20030305102617.A27891@dilbert.robbins.dropbear.id.au> <1046820725.6491.53.camel@devel> In-Reply-To: <1046820725.6491.53.camel@devel> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200303041638.13457.darcy@wavefire.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 I have at least 1 VPN setup that requires full IPX support. On Tuesday 04 March 2003 15:32, Chris Fowler wrote: > What is IPX currently being used for? Legacy systems? > > I've been stuck in TCP/IP land for many years now. Have been lucky > enough to not run into any IPX. > > On Tue, 2003-03-04 at 18:26, Tim Robbins wrote: > > On Tue, Mar 04, 2003 at 02:53:56PM -0800, Julian Elischer wrote: > > > I thought nwfs used it? > > > > nwfs uses netipx. From what I can tell, netipx was based on netns. > > > > > > Tim > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message --=20 Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 16:42:48 2003 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 74CD937B401 for ; Tue, 4 Mar 2003 16:42:47 -0800 (PST) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4C0443F85 for ; Tue, 4 Mar 2003 16:42:46 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc02.attbi.com (sccrmhc02) with ESMTP id <200303050042450020080ffce>; Wed, 5 Mar 2003 00:42:45 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA54467; Tue, 4 Mar 2003 16:42:43 -0800 (PST) Date: Tue, 4 Mar 2003 16:42:42 -0800 (PST) From: Julian Elischer To: Archie Cobbs Cc: freebsd-net@freebsd.org Subject: Re: Mysterious MPD hangs? Please try this patch In-Reply-To: <200303050004.h2504sbY012403@arch20m.dellroad.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 looks good here.. On Tue, 4 Mar 2003, Archie Cobbs wrote: > Hi, > > For anyone who's using MPD with multilink PPP enabled and is experiencing > mysterious "hangs" where no data gets through for an extended period of > time, please try the patch below. > > Thanks to Matthew Impett for finding the bug. > > -Archie > [...] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 17:10:51 2003 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 3DAC137B401; Tue, 4 Mar 2003 17:10:07 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AAC143FBD; Tue, 4 Mar 2003 17:10:05 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0118.cvx21-bradley.dialup.earthlink.net ([209.179.192.118] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18qNPl-0005K9-00; Tue, 04 Mar 2003 17:09:46 -0800 Message-ID: <3E654D75.E37B5861@mindspring.com> Date: Tue, 04 Mar 2003 17:05:57 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm , Mike Barcroft , Tim Robbins , freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: [PATCH] make netns compile cleanly (was Re: Removal of netns - politically correct version References: <20030304194017.022FD2A8BB@canning.wemm.org> <3E6539B5.2F5D31B@mindspring.com> Content-Type: multipart/mixed; boundary="------------81B31A38BCFEF66ED364CE7A" X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a47a597f4a0f4a1bd46bb4710ccc6b8b30667c3043c0873f7e350badd9bab72f9c350badd9bab72f9c 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. --------------81B31A38BCFEF66ED364CE7A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Terry Lambert wrote: > Peter Wemm wrote: > > Terry: will you please check your facts? It takes around 30 seconds > > to find out that it doesn't even compile. > > [ ... lots of trivial to fix warnings and errors ... ] > > Tell you what, I'll fix these and post a patch. Will that make you > guys happy? > > This crap is *soooooooo* trivial to fix, it's easier to fix than > to watch you guys bitch about it not being fixable. Here are two patches. The first fixes missing pieces in /sys/conf/files and /sys/conf/options, the second fixes all the files that need it in /sys/netns/. It's now possible to add: options NS to a kernel config, and still get a kernel that does it's thing. Note that I did not go through and made the protosw[] changes, so there's some initialization warnings there, but by my clock, I only spent an hour on the thing, and what you guys were bitching about was "it doesn't even compile". If you want that fixed too, then it's an easy fix, using the IPX sources as a guide, since IPX is derives from XNS. -- Terry --------------81B31A38BCFEF66ED364CE7A Content-Type: text/plain; charset=us-ascii; name="netnsconf.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netnsconf.diff" Index: files =================================================================== RCS file: /usr/cvs/src/sys/conf/files,v retrieving revision 1.340.2.87 diff -c -r1.340.2.87 files *** files 19 Dec 2001 20:59:27 -0000 1.340.2.87 --- files 5 Mar 2003 00:49:18 -0000 *************** *** 923,928 **** --- 923,929 ---- netns/ns_output.c optional ns netns/ns_pcb.c optional ns netns/ns_proto.c optional ns + netns/ns_cksum.c optional ns netns/spp_debug.c optional ns netns/spp_usrreq.c optional ns nfs/nfs_bio.c optional nfs Index: options =================================================================== RCS file: /usr/cvs/src/sys/conf/options,v retrieving revision 1.191.2.37 diff -c -r1.191.2.37 options *** options 3 Nov 2001 01:41:07 -0000 1.191.2.37 --- options 4 Mar 2003 22:10:11 -0000 *************** *** 272,277 **** --- 272,278 ---- TCPDEBUG TCP_DROP_SYNFIN opt_tcp_input.h XBONEHACK + NS opt_ns.h # Netgraph(4). Use option NETGRAPH to enable the base netgraph code. # Each netgraph node type can be either be compiled into the kernel --------------81B31A38BCFEF66ED364CE7A Content-Type: text/plain; charset=us-ascii; name="netns.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netns.diff" Index: idp_usrreq.c =================================================================== RCS file: /usr/cvs/src/sys/netns/idp_usrreq.c,v retrieving revision 1.9 diff -c -r1.9 idp_usrreq.c *** idp_usrreq.c 28 Aug 1999 00:49:47 -0000 1.9 --- idp_usrreq.c 5 Mar 2003 01:15:42 -0000 *************** *** 54,59 **** --- 54,63 ---- #include #include + extern int idpcksum; /* from ns_input.c */ + extern long ns_pexseq; /* from ns_input.c */ + extern struct nspcb nsrawpcb; /* from ns_input.c */ + /* * IDP protocol implementation. */ *************** *** 63,68 **** --- 67,73 ---- /* * This may also be called for raw listeners. */ + void idp_input(m, nsp) struct mbuf *m; register struct nspcb *nsp; *************** *** 79,92 **** idp_ns.sns_addr = idp->idp_sna; if (ns_neteqnn(idp->idp_sna.x_net, ns_zeronet) && ifp) { register struct ifaddr *ifa; ! for (ifa = ifp->if_addrlist; ifa; ifa = ifa->ifa_next) { if (ifa->ifa_addr->sa_family == AF_NS) { idp_ns.sns_addr.x_net = IA_SNS(ifa)->sns_addr.x_net; break; } ! } } nsp->nsp_rpt = idp->idp_pt; if ( ! (nsp->nsp_flags & NSP_RAWIN) ) { --- 84,99 ---- idp_ns.sns_addr = idp->idp_sna; if (ns_neteqnn(idp->idp_sna.x_net, ns_zeronet) && ifp) { register struct ifaddr *ifa; + int s; ! s = splimp(); ! TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) if (ifa->ifa_addr->sa_family == AF_NS) { idp_ns.sns_addr.x_net = IA_SNS(ifa)->sns_addr.x_net; break; } ! splx(s); } nsp->nsp_rpt = idp->idp_pt; if ( ! (nsp->nsp_flags & NSP_RAWIN) ) { *************** *** 103,108 **** --- 110,116 ---- m_freem(m); } + void idp_abort(nsp) struct nspcb *nsp; { *************** *** 134,153 **** so->so_error = errno; ns_pcbdisconnect(nsp); soisdisconnected(so); } int noIdpRoute; idp_output(nsp, m0) struct nspcb *nsp; struct mbuf *m0; { ! register struct mbuf *m; register struct idp *idp; register struct socket *so; register int len = 0; register struct route *ro; ! struct mbuf *mprev; ! extern int idpcksum; /* * Calculate data length. --- 142,163 ---- so->so_error = errno; ns_pcbdisconnect(nsp); soisdisconnected(so); + return(NULL); /* XXX */ } int noIdpRoute; + + int idp_output(nsp, m0) struct nspcb *nsp; struct mbuf *m0; { ! struct mbuf *m; register struct idp *idp; register struct socket *so; register int len = 0; register struct route *ro; ! struct mbuf *mprev = NULL; /* * Calculate data length. *************** *** 259,265 **** --- 269,277 ---- if (noIdpRoute) ro = 0; return (ns_output(m, ro, so->so_options & SO_BROADCAST)); } + /* ARGSUSED */ + int idp_ctloutput(req, so, level, name, value) int req, level; struct socket *so; *************** *** 269,275 **** register struct mbuf *m; struct nspcb *nsp = sotonspcb(so); int mask, error = 0; - extern long ns_pexseq; if (nsp == NULL) return (EINVAL); --- 281,286 ---- *************** *** 371,376 **** --- 382,388 ---- } /*ARGSUSED*/ + int idp_usrreq(so, req, m, nam, control) struct socket *so; int req; *************** *** 455,461 **** case PRU_SEND: { struct ns_addr laddr; ! int s; if (nam) { laddr = nsp->nsp_laddr; --- 467,473 ---- case PRU_SEND: { struct ns_addr laddr; ! int s = -1; /* XXX compiler warns improperly */ if (nam) { laddr = nsp->nsp_laddr; *************** *** 532,538 **** --- 544,552 ---- m_freem(m); return (error); } + /*ARGSUSED*/ + int idp_raw_usrreq(so, req, m, nam, control) struct socket *so; int req; *************** *** 540,555 **** { int error = 0; struct nspcb *nsp = sotonspcb(so); - extern struct nspcb nsrawpcb; switch (req) { case PRU_ATTACH: if (!(so->so_state & SS_PRIV) || (nsp != NULL)) { error = EINVAL; break; } error = ns_pcballoc(so, &nsrawpcb); if (error) break; --- 554,571 ---- { int error = 0; struct nspcb *nsp = sotonspcb(so); switch (req) { case PRU_ATTACH: + #ifdef NS_PRIV_SOCKETS if (!(so->so_state & SS_PRIV) || (nsp != NULL)) { error = EINVAL; break; } + #endif /* NS_PRIV_SOCKETS */ + error = ns_pcballoc(so, &nsrawpcb); if (error) break; Index: idp_var.h =================================================================== RCS file: /usr/cvs/src/sys/netns/idp_var.h,v retrieving revision 1.10 diff -c -r1.10 idp_var.h *** idp_var.h 29 Dec 1999 04:46:18 -0000 1.10 --- idp_var.h 5 Mar 2003 01:15:42 -0000 *************** *** 50,55 **** --- 50,66 ---- #ifdef _KERNEL struct idpstat idpstat; + struct nspcb; /* declare in scope for ptr parameter */ + + void idp_abort __P((struct nspcb *)); + void idp_input __P((struct mbuf *, struct nspcb *)); + struct nspcb *idp_drop __P((struct nspcb *, int)); + int idp_output __P(( struct nspcb *, struct mbuf *)); + int idp_ctloutput __P((int, struct socket *, int, int, struct mbuf **)); + int idp_usrreq __P(( struct socket *, int, struct mbuf *, struct mbuf *, + struct mbuf *)); + int idp_raw_usrreq __P(( struct socket *, int, struct mbuf *, struct mbuf *, + struct mbuf *)); #endif #endif Index: ns.c =================================================================== RCS file: /usr/cvs/src/sys/netns/ns.c,v retrieving revision 1.9 diff -c -r1.9 ns.c *** ns.c 28 Aug 1999 00:49:47 -0000 1.9 --- ns.c 5 Mar 2003 01:15:42 -0000 *************** *** 36,41 **** --- 36,42 ---- #include #include + #include #include #include #include *************** *** 49,54 **** --- 50,57 ---- #include #include + #include "opt_ns.h" + #ifdef NS struct ns_ifaddr *ns_ifaddr; *************** *** 59,64 **** --- 62,68 ---- * Generic internet control operations (ioctl's). */ /* ARGSUSED */ + int ns_control(so, cmd, data, ifp) struct socket *so; int cmd; *************** *** 68,76 **** register struct ifreq *ifr = (struct ifreq *)data; register struct ns_aliasreq *ifra = (struct ns_aliasreq *)data; register struct ns_ifaddr *ia; ! struct ifaddr *ifa; struct ns_ifaddr *oia; ! int error, dstIsNew, hostIsNew; /* * Find address for this interface, if it exists. --- 72,81 ---- register struct ifreq *ifr = (struct ifreq *)data; register struct ns_aliasreq *ifra = (struct ns_aliasreq *)data; register struct ns_ifaddr *ia; ! struct ifaddr *ifa = NULL; /* XXX used uninitialized ?*/ struct ns_ifaddr *oia; ! int dstIsNew, hostIsNew; ! int error = 0; /* initialize because of scoping */ /* * Find address for this interface, if it exists. *************** *** 107,114 **** --- 112,121 ---- return (0); } + #ifdef NS_PRIV_SOCKETS if ((so->so_state & SS_PRIV) == 0) return (EPERM); + #endif /* NS_PRIV_SOCKETS */ switch (cmd) { case SIOCAIFADDR: *************** *** 132,150 **** if (oia == (struct ns_ifaddr *)NULL) return (ENOBUFS); bzero((caddr_t)oia, sizeof(*oia)); ! if (ia = ns_ifaddr) { for ( ; ia->ia_next; ia = ia->ia_next) ; ia->ia_next = oia; } else ns_ifaddr = oia; ia = oia; ! if (ifa = ifp->if_addrlist) { ! for ( ; ifa->ifa_next; ifa = ifa->ifa_next) ! ; ! ifa->ifa_next = (struct ifaddr *) ia; ! } else ! ifp->if_addrlist = (struct ifaddr *) ia; ia->ia_ifp = ifp; ia->ia_ifa.ifa_addr = (struct sockaddr *)&ia->ia_addr; --- 139,153 ---- if (oia == (struct ns_ifaddr *)NULL) return (ENOBUFS); bzero((caddr_t)oia, sizeof(*oia)); ! if ((ia = ns_ifaddr) != NULL) { for ( ; ia->ia_next; ia = ia->ia_next) ; ia->ia_next = oia; } else ns_ifaddr = oia; ia = oia; ! ! TAILQ_INSERT_TAIL(&ifp->if_addrhead, ifa, ifa_link); ia->ia_ifp = ifp; ia->ia_ifa.ifa_addr = (struct sockaddr *)&ia->ia_addr; *************** *** 163,170 **** } switch (cmd) { - int error; - case SIOCSIFDSTADDR: if ((ifp->if_flags & IFF_POINTOPOINT) == 0) return (EINVAL); --- 166,171 ---- *************** *** 173,179 **** ia->ia_flags &= ~IFA_ROUTE; } if (ifp->if_ioctl) { ! error = (*ifp->if_ioctl)(ifp, SIOCSIFDSTADDR, ia); if (error) return (error); } --- 174,181 ---- ia->ia_flags &= ~IFA_ROUTE; } if (ifp->if_ioctl) { ! error = (*ifp->if_ioctl)(ifp, SIOCSIFDSTADDR, ! (caddr_t)ia); if (error) return (error); } *************** *** 181,203 **** return (0); case SIOCSIFADDR: ! return (ns_ifinit(ifp, ia, (struct sockaddr_ns *)&ifr->ifr_addr, 1)); case SIOCDIFADDR: ! ns_ifscrub(ifp, ia); ! if ((ifa = ifp->if_addrlist) == (struct ifaddr *)ia) ! ifp->if_addrlist = ifa->ifa_next; ! else { ! while (ifa->ifa_next && ! (ifa->ifa_next != (struct ifaddr *)ia)) ! ifa = ifa->ifa_next; ! if (ifa->ifa_next) ! ifa->ifa_next = ((struct ifaddr *)ia)->ifa_next; ! else ! printf("Couldn't unlink nsifaddr from ifp\n"); ! } oia = ia; if (oia == (ia = ns_ifaddr)) { ns_ifaddr = ia->ia_next; } else { --- 183,196 ---- return (0); case SIOCSIFADDR: ! return (ns_ifinit(ifp, (struct ns_ifaddr *)ia, (struct sockaddr_ns *)&ifr->ifr_addr, 1)); case SIOCDIFADDR: ! ns_ifscrub(ifp, (struct ns_ifaddr *)ia); ! /* XXX not on list? */ oia = ia; + TAILQ_REMOVE(&ifp->if_addrhead, (struct ifaddr *)ia, ifa_link); if (oia == (ia = ns_ifaddr)) { ns_ifaddr = ia->ia_next; } else { *************** *** 231,243 **** if ((ifp->if_flags & IFF_POINTOPOINT) && (ifra->ifra_dstaddr.sns_family == AF_NS)) { if (hostIsNew == 0) ! ns_ifscrub(ifp, ia); ia->ia_dstaddr = ifra->ifra_dstaddr; dstIsNew = 1; } if (ifra->ifra_addr.sns_family == AF_NS && (hostIsNew || dstIsNew)) ! error = ns_ifinit(ifp, ia, &ifra->ifra_addr, 0); return (error); default: --- 224,237 ---- if ((ifp->if_flags & IFF_POINTOPOINT) && (ifra->ifra_dstaddr.sns_family == AF_NS)) { if (hostIsNew == 0) ! ns_ifscrub(ifp, (struct ns_ifaddr *)ia); ia->ia_dstaddr = ifra->ifra_dstaddr; dstIsNew = 1; } if (ifra->ifra_addr.sns_family == AF_NS && (hostIsNew || dstIsNew)) ! error = ns_ifinit(ifp, (struct ns_ifaddr *)ia, ! &ifra->ifra_addr, 0); return (error); default: *************** *** 250,255 **** --- 244,250 ---- /* * Delete any previous route for an old address. */ + void ns_ifscrub(ifp, ia) register struct ifnet *ifp; register struct ns_ifaddr *ia; *************** *** 266,275 **** --- 261,272 ---- * Initialize an interface's internet address * and routing table entry. */ + int ns_ifinit(ifp, ia, sns, scrub) register struct ifnet *ifp; register struct ns_ifaddr *ia; register struct sockaddr_ns *sns; + int scrub; { struct sockaddr_ns oldaddr; register union ns_host *h = &ia->ia_addr.sns_addr.x_host; *************** *** 294,300 **** */ if (ns_hosteqnh(ns_thishost, ns_zerohost)) { if (ifp->if_ioctl && ! (error = (*ifp->if_ioctl)(ifp, SIOCSIFADDR, ia))) { ia->ia_addr = oldaddr; splx(s); return (error); --- 291,298 ---- */ if (ns_hosteqnh(ns_thishost, ns_zerohost)) { if (ifp->if_ioctl && ! (error = (*ifp->if_ioctl)(ifp, SIOCSIFADDR, ! (caddr_t)ia))) { ia->ia_addr = oldaddr; splx(s); return (error); *************** *** 304,310 **** || ns_hosteqnh(sns->sns_addr.x_host, ns_thishost)) { *h = ns_thishost; if (ifp->if_ioctl && ! (error = (*ifp->if_ioctl)(ifp, SIOCSIFADDR, ia))) { ia->ia_addr = oldaddr; splx(s); return (error); --- 302,309 ---- || ns_hosteqnh(sns->sns_addr.x_host, ns_thishost)) { *h = ns_thishost; if (ifp->if_ioctl && ! (error = (*ifp->if_ioctl)(ifp, SIOCSIFADDR, ! (caddr_t)ia))) { ia->ia_addr = oldaddr; splx(s); return (error); *************** *** 352,358 **** union ns_net net = dst->x_net; for (ia = ns_ifaddr; ia; ia = ia->ia_next) { ! if (ifp = ia->ia_ifp) { if (ifp->if_flags & IFF_POINTOPOINT) { compare = &satons_addr(ia->ia_dstaddr); if (ns_hosteq(*dst, *compare)) --- 351,357 ---- union ns_net net = dst->x_net; for (ia = ns_ifaddr; ia; ia = ia->ia_next) { ! if ((ifp = ia->ia_ifp) != NULL) { if (ifp->if_flags & IFF_POINTOPOINT) { compare = &satons_addr(ia->ia_dstaddr); if (ns_hosteq(*dst, *compare)) Index: ns.h =================================================================== RCS file: /usr/cvs/src/sys/netns/ns.h,v retrieving revision 1.13 diff -c -r1.13 ns.h *** ns.h 29 Dec 1999 04:46:19 -0000 1.13 --- ns.h 5 Mar 2003 01:15:42 -0000 *************** *** 142,148 **** union ns_host ns_broadhost; union ns_net ns_zeronet; union ns_net ns_broadnet; ! u_short ns_cksum(); #else #include --- 142,164 ---- union ns_host ns_broadhost; union ns_net ns_zeronet; union ns_net ns_broadnet; ! ! struct route; ! struct ns_ifaddr; ! ! u_short ns_cksum __P(( struct mbuf *, int)); ! int ns_output __P((struct mbuf *, struct route *, int)); ! int ns_control __P((struct socket *, int, caddr_t, struct ifnet *)); ! void ns_init __P((void)); ! void idp_forward __P((struct mbuf *)); ! void idp_ctlinput __P((int, caddr_t)); ! int idp_do_route __P((struct ns_addr *, struct route *)); ! void idp_undo_route __P((struct route *)); ! void ns_watch_output __P((struct mbuf *, struct ifnet *)); ! int ns_ifinit __P((struct ifnet *, struct ns_ifaddr *, struct sockaddr_ns *, ! int)); ! void ns_ifscrub __P((struct ifnet *, struct ns_ifaddr *)); ! #else #include Index: ns_error.c =================================================================== RCS file: /usr/cvs/src/sys/netns/ns_error.c,v retrieving revision 1.9 diff -c -r1.9 ns_error.c *** ns_error.c 28 Aug 1999 00:49:49 -0000 1.9 --- ns_error.c 5 Mar 2003 01:15:42 -0000 *************** *** 50,55 **** --- 50,59 ---- #include #include + extern int idpcksum; /* from ns_input.c */ + extern void spp_ctlinput( int, caddr_t); /* from spp_usrreq.c XXX */ + + #ifdef lint #define NS_ERRPRINTFS 1 #endif *************** *** 62,68 **** --- 66,74 ---- int ns_errprintfs = 0; #endif + int ns_err_x(c) + int c; { register u_short *w, *lim, *base = ns_errstat.ns_es_codes; u_short x = c; *************** *** 86,101 **** * Generate an error packet of type error * in response to bad packet. */ ! ns_error(om, type, param) struct mbuf *om; int type; { register struct ns_epidp *ep; struct mbuf *m; struct idp *nip; register struct idp *oip = mtod(om, struct idp *); - extern int idpcksum; /* * If this packet was sent to the echo port, --- 92,107 ---- * Generate an error packet of type error * in response to bad packet. */ ! void ns_error(om, type, param) struct mbuf *om; int type; + int param; { register struct ns_epidp *ep; struct mbuf *m; struct idp *nip; register struct idp *oip = mtod(om, struct idp *); /* * If this packet was sent to the echo port, *************** *** 165,170 **** --- 171,177 ---- m_freem(om); } + void ns_printhost(p) register struct ns_addr *p; { *************** *** 182,192 **** --- 189,202 ---- /* * Process a received NS_ERR message. */ + void ns_err_input(m) struct mbuf *m; { register struct ns_errp *ep; + #ifdef NS_ERRPRINTFS register struct ns_epidp *epidp = mtod(m, struct ns_epidp *); + #endif register int i; int type, code, param; *************** *** 295,300 **** --- 305,311 ---- } #endif + int ns_echo(m) struct mbuf *m; { Index: ns_error.h =================================================================== RCS file: /usr/cvs/src/sys/netns/ns_error.h,v retrieving revision 1.10 diff -c -r1.10 ns_error.h *** ns_error.h 29 Dec 1999 04:46:19 -0000 1.10 --- ns_error.h 5 Mar 2003 01:15:42 -0000 *************** *** 91,96 **** --- 91,102 ---- #ifdef _KERNEL struct ns_errstat ns_errstat; + + int ns_err_x __P((int)); + void ns_error __P((struct mbuf *, int, int)); + int ns_echo __P((struct mbuf *)); + void ns_printhost __P((struct ns_addr *)); + void ns_err_input __P((struct mbuf *)); #endif #endif Index: ns_if.h =================================================================== RCS file: /usr/cvs/src/sys/netns/ns_if.h,v retrieving revision 1.12 diff -c -r1.12 ns_if.h *** ns_if.h 29 Dec 1999 04:46:19 -0000 1.12 --- ns_if.h 5 Mar 2003 01:15:42 -0000 *************** *** 80,89 **** #endif #ifdef _KERNEL ! struct ns_ifaddr *ns_ifaddr; ! struct ns_ifaddr *ns_iaonnetof(); void nsintr __P((void)); ! struct ifqueue nsintrq; /* XNS input packet queue */ #endif #endif --- 80,91 ---- #endif #ifdef _KERNEL ! extern struct ns_ifaddr *ns_ifaddr; ! ! struct ns_ifaddr *ns_iaonnetof __P((struct ns_addr *)); void nsintr __P((void)); ! ! extern struct ifqueue nsintrq; /* XNS input packet queue */ #endif #endif Index: ns_input.c =================================================================== RCS file: /usr/cvs/src/sys/netns/ns_input.c,v retrieving revision 1.13 diff -c -r1.13 ns_input.c *** ns_input.c 13 Feb 2000 03:32:04 -0000 1.13 --- ns_input.c 5 Mar 2003 01:15:42 -0000 *************** *** 59,77 **** #include #include /* * NS initialization. */ - union ns_host ns_thishost; - union ns_host ns_zerohost; - union ns_host ns_broadhost; - union ns_net ns_zeronet; - union ns_net ns_broadnet; struct sockaddr_ns ns_netmask, ns_hostmask; static u_short allones[] = {-1, -1, -1}; - struct nspcb nspcb; struct nspcb nsrawpcb; int nsqmaxlen = IFQ_MAXLEN; --- 59,74 ---- #include #include + extern void spp_input(struct mbuf *, struct nspcb *); /* spp_usrreq.c XXX */ + + /* * NS initialization. */ struct sockaddr_ns ns_netmask, ns_hostmask; static u_short allones[] = {-1, -1, -1}; struct nspcb nsrawpcb; int nsqmaxlen = IFQ_MAXLEN; *************** *** 81,96 **** const int nsintrq_present = 1; ns_init() { - extern struct timeval time; - ns_broadhost = * (union ns_host *) allones; ns_broadnet = * (union ns_net *) allones; nspcb.nsp_next = nspcb.nsp_prev = &nspcb; nsrawpcb.nsp_next = nsrawpcb.nsp_prev = &nsrawpcb; nsintrq.ifq_maxlen = nsqmaxlen; ! ns_pexseq = time.tv_usec; ns_netmask.sns_len = 6; ns_netmask.sns_addr.x_net = ns_broadnet; ns_hostmask.sns_len = 12; --- 78,92 ---- const int nsintrq_present = 1; + void ns_init() { ns_broadhost = * (union ns_host *) allones; ns_broadnet = * (union ns_net *) allones; nspcb.nsp_next = nspcb.nsp_prev = &nspcb; nsrawpcb.nsp_next = nsrawpcb.nsp_prev = &nsrawpcb; nsintrq.ifq_maxlen = nsqmaxlen; ! ns_pexseq = tick; ns_netmask.sns_len = 6; ns_netmask.sns_addr.x_net = ns_broadnet; ns_hostmask.sns_len = 12; *************** *** 141,147 **** idp = mtod(m, struct idp *); len = ntohs(idp->idp_len); ! if (oddpacketp = len & 1) { len++; /* If this packet is of odd length, preserve garbage byte for checksum */ } --- 137,143 ---- idp = mtod(m, struct idp *); len = ntohs(idp->idp_len); ! if ((oddpacketp = (len & 1))) { len++; /* If this packet is of odd length, preserve garbage byte for checksum */ } *************** *** 250,264 **** int idp_donosocks = 1; idp_ctlinput(cmd, arg) int cmd; caddr_t arg; { struct ns_addr *ns; struct nspcb *nsp; ! struct ns_errp *errp; ! int idp_abort(); ! extern struct nspcb *idp_drop(); int type; if (cmd < 0 || cmd > PRC_NCMDS) --- 246,259 ---- int idp_donosocks = 1; + void idp_ctlinput(cmd, arg) int cmd; caddr_t arg; { struct ns_addr *ns; struct nspcb *nsp; ! struct ns_errp *errp = (struct ns_errp *)arg; /* XXX */ int type; if (cmd < 0 || cmd > PRC_NCMDS) *************** *** 309,314 **** --- 304,310 ---- struct route idp_droute; struct route idp_sroute; + void idp_forward(m) struct mbuf *m; { *************** *** 428,433 **** --- 424,430 ---- m_freem(mcopy); } + int idp_do_route(src, ro) struct ns_addr *src; struct route *ro; *************** *** 450,461 **** --- 447,460 ---- return (1); } + void idp_undo_route(ro) register struct route *ro; { if (ro->ro_rt) {RTFREE(ro->ro_rt);} } + void ns_watch_output(m, ifp) struct mbuf *m; struct ifnet *ifp; *************** *** 477,489 **** idp->idp_sna.x_net = ns_zeronet; idp->idp_sna.x_host = ns_thishost; if (ifp && (ifp->if_flags & IFF_POINTOPOINT)) ! for(ifa = ifp->if_addrlist; ifa; ! ifa = ifa->ifa_next) { if (ifa->ifa_addr->sa_family==AF_NS) { idp->idp_sna = IA_SNS(ifa)->sns_addr; break; } - } idp->idp_len = ntohl(m0->m_pkthdr.len); idp_input(m0, nsp); } --- 476,486 ---- idp->idp_sna.x_net = ns_zeronet; idp->idp_sna.x_host = ns_thishost; if (ifp && (ifp->if_flags & IFF_POINTOPOINT)) ! TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) if (ifa->ifa_addr->sa_family==AF_NS) { idp->idp_sna = IA_SNS(ifa)->sns_addr; break; } idp->idp_len = ntohl(m0->m_pkthdr.len); idp_input(m0, nsp); } Index: ns_output.c =================================================================== RCS file: /usr/cvs/src/sys/netns/ns_output.c,v retrieving revision 1.7 diff -c -r1.7 ns_output.c *** ns_output.c 28 Aug 1999 00:49:51 -0000 1.7 --- ns_output.c 5 Mar 2003 01:15:42 -0000 *************** *** 57,62 **** --- 57,63 ---- int ns_output_cnt = 0; struct mbuf *ns_lastout; + int ns_output(m0, ro, flags) struct mbuf *m0; struct route *ro; *************** *** 67,73 **** int error = 0; struct route idproute; struct sockaddr_ns *dst; - extern int idpcksum; if (ns_hold_output) { if (ns_lastout) { --- 68,73 ---- Index: ns_pcb.c =================================================================== RCS file: /usr/cvs/src/sys/netns/ns_pcb.c,v retrieving revision 1.9 diff -c -r1.9 ns_pcb.c *** ns_pcb.c 28 Aug 1999 00:49:51 -0000 1.9 --- ns_pcb.c 5 Mar 2003 01:15:42 -0000 *************** *** 51,56 **** --- 51,57 ---- struct ns_addr zerons_addr; + int ns_pcballoc(so, head) struct socket *so; struct nspcb *head; *************** *** 58,64 **** struct mbuf *m; register struct nspcb *nsp; ! m = m_getclr(M_DONTWAIT, MT_PCB); if (m == NULL) return (ENOBUFS); nsp = mtod(m, struct nspcb *); --- 59,65 ---- struct mbuf *m; register struct nspcb *nsp; ! m = m_getclr(M_DONTWAIT, MT_CONTROL); /* protocol private PCB */ if (m == NULL) return (ENOBUFS); nsp = mtod(m, struct nspcb *); *************** *** 68,73 **** --- 69,75 ---- return (0); } + int ns_pcbbind(nsp, nam) register struct nspcb *nsp; struct mbuf *nam; *************** *** 92,102 **** --- 94,107 ---- } lport = sns->sns_port; if (lport) { + #ifdef NS_PRIV_SOCKETS u_short aport = ntohs(lport); if (aport < NSPORT_RESERVED && (nsp->nsp_socket->so_state & SS_PRIV) == 0) return (EACCES); + #endif /* NS_PRIV_SOCKETS */ + if (ns_pcblookup(&zerons_addr, lport, 0)) return (EADDRINUSE); } *************** *** 118,123 **** --- 123,129 ---- * If don't have a local address for this socket yet, * then pick one. */ + int ns_pcbconnect(nsp, nam) struct nspcb *nsp; struct mbuf *nam; *************** *** 217,222 **** --- 223,229 ---- return (0); } + void ns_pcbdisconnect(nsp) struct nspcb *nsp; { *************** *** 226,231 **** --- 233,239 ---- ns_pcbdetach(nsp); } + void ns_pcbdetach(nsp) struct nspcb *nsp; { *************** *** 239,244 **** --- 247,253 ---- (void) m_free(dtom(nsp)); } + void ns_setsockaddr(nsp, nam) register struct nspcb *nsp; struct mbuf *nam; *************** *** 253,258 **** --- 262,268 ---- sns->sns_addr = nsp->nsp_laddr; } + void ns_setpeeraddr(nsp, nam) register struct nspcb *nsp; struct mbuf *nam; *************** *** 274,283 **** * Also pass an extra paramter via the nspcb. (which may in fact * be a parameter list!) */ ns_pcbnotify(dst, errno, notify, param) register struct ns_addr *dst; long param; ! int errno, (*notify)(); { register struct nspcb *nsp, *oinp; int s = splimp(); --- 284,295 ---- * Also pass an extra paramter via the nspcb. (which may in fact * be a parameter list!) */ + void ns_pcbnotify(dst, errno, notify, param) register struct ns_addr *dst; long param; ! void (*notify)(struct nspcb *); ! int errno; { register struct nspcb *nsp, *oinp; int s = splimp(); Index: ns_pcb.h =================================================================== RCS file: /usr/cvs/src/sys/netns/ns_pcb.h,v retrieving revision 1.11 diff -c -r1.11 ns_pcb.h *** ns_pcb.h 29 Dec 1999 04:46:20 -0000 1.11 --- ns_pcb.h 5 Mar 2003 01:15:42 -0000 *************** *** 79,85 **** #ifdef _KERNEL struct nspcb nspcb; /* head of list */ ! struct nspcb *ns_pcblookup(); #endif #endif --- 79,93 ---- #ifdef _KERNEL struct nspcb nspcb; /* head of list */ ! struct nspcb *ns_pcblookup __P((struct ns_addr *, u_short, int)); ! void ns_pcbdisconnect __P((struct nspcb *)); ! void ns_pcbdetach __P((struct nspcb *)); ! int ns_pcballoc __P((struct socket *, struct nspcb *)); ! int ns_pcbbind __P((struct nspcb *, struct mbuf *)); ! int ns_pcbconnect __P((struct nspcb *, struct mbuf *)); ! void ns_setsockaddr __P((struct nspcb *, struct mbuf *)); ! void ns_setpeeraddr __P((struct nspcb *, struct mbuf *)); ! void ns_pcbnotify __P(( struct ns_addr *, int, void(*)(struct nspcb *), long)); #endif #endif Index: ns_proto.c =================================================================== RCS file: /usr/cvs/src/sys/netns/ns_proto.c,v retrieving revision 1.10 diff -c -r1.10 ns_proto.c *** ns_proto.c 28 Aug 1999 00:49:51 -0000 1.10 --- ns_proto.c 5 Mar 2003 01:15:42 -0000 *************** *** 44,62 **** #include #include /* * NS protocol family: IDP, ERR, PE, SPP, ROUTE. */ - int ns_init(); - int idp_input(), idp_output(), idp_ctlinput(), idp_usrreq(); - int idp_raw_usrreq(), idp_ctloutput(); - int spp_input(), spp_ctlinput(); - int spp_usrreq(), spp_usrreq_sp(), spp_ctloutput(); - int spp_init(), spp_fasttimo(), spp_slowtimo(); - extern int raw_usrreq(); - extern struct domain nsdomain; struct protosw nssw[] = { { 0, &nsdomain, 0, 0, --- 44,68 ---- #include #include + #include + + /* XXX+ */ + void spp_input( struct mbuf *, struct nspcb *); + void spp_ctlinput( int, caddr_t); + int spp_ctloutput( int, struct socket *, int, int, struct mbuf **); + int spp_usrreq( struct socket *, int, struct mbuf *, struct mbuf *, struct mbuf *); + int spp_usrreq_sp( struct socket *, int, struct mbuf *, struct mbuf *, struct mbuf *); + void spp_init(void); + void spp_fasttimo(void); + void spp_slowtimo(void); + + /* XXX- */ + /* * NS protocol family: IDP, ERR, PE, SPP, ROUTE. */ struct protosw nssw[] = { { 0, &nsdomain, 0, 0, Index: spp_debug.c =================================================================== RCS file: /usr/cvs/src/sys/netns/spp_debug.c,v retrieving revision 1.10 diff -c -r1.10 spp_debug.c *** spp_debug.c 28 Aug 1999 00:49:52 -0000 1.10 --- spp_debug.c 5 Mar 2003 01:15:42 -0000 *************** *** 64,69 **** --- 64,70 ---- /* * spp debug routines */ + void spp_trace(act, ostate, sp, si, req) short act; u_char ostate; Index: spp_debug.h =================================================================== RCS file: /usr/cvs/src/sys/netns/spp_debug.h,v retrieving revision 1.9 diff -c -r1.9 spp_debug.h *** spp_debug.h 28 Aug 1999 00:49:53 -0000 1.9 --- spp_debug.h 5 Mar 2003 01:15:42 -0000 *************** *** 63,65 **** --- 63,70 ---- int spp_debx; #endif + + #ifdef _KERNEL + + void spp_trace __P(( short, u_char, struct sppcb *, struct spidp *, int)); + #endif Index: spp_usrreq.c =================================================================== RCS file: /usr/cvs/src/sys/netns/spp_usrreq.c,v retrieving revision 1.11 diff -c -r1.11 spp_usrreq.c *** spp_usrreq.c 28 Aug 1999 00:49:53 -0000 1.11 --- spp_usrreq.c 5 Mar 2003 01:15:42 -0000 *************** *** 58,66 **** --- 58,73 ---- #include #include + extern u_char nsctlerrmap[]; /* from ns_input.c */ + extern int idpcksum; /* from ns_input.c */ + + int spp_backoff[SPP_MAXRXTSHIFT+1] = + { 1, 2, 4, 8, 16, 32, 64, 64, 64, 64, 64, 64, 64 }; + /* * SP protocol implementation. */ + void spp_init() { *************** *** 74,79 **** --- 81,87 ---- u_short spp_newchecks[50]; /*ARGSUSED*/ + void spp_input(m, nsp) register struct mbuf *m; register struct nspcb *nsp; *************** *** 81,87 **** register struct sppcb *cb; register struct spidp *si = mtod(m, struct spidp *); register struct socket *so; ! short ostate; int dropsocket = 0; --- 89,95 ---- register struct sppcb *cb; register struct spidp *si = mtod(m, struct spidp *); register struct socket *so; ! short ostate = 0; /* compiler erroneously flags */ int dropsocket = 0; *************** *** 287,292 **** --- 295,301 ---- * but its function is somewhat different: It merely queues * packets up, and suppresses duplicates. */ + int spp_reass(cb, si) register struct sppcb *cb; register struct spidp *si; *************** *** 415,423 **** update_window: if (SSEQ_LT(cb->s_snxt, cb->s_rack)) cb->s_snxt = cb->s_rack; ! if (SSEQ_LT(cb->s_swl1, si->si_seq) || cb->s_swl1 == si->si_seq && (SSEQ_LT(cb->s_swl2, si->si_ack) || ! cb->s_swl2 == si->si_ack && SSEQ_LT(cb->s_ralo, si->si_alo))) { /* keep track of pure window updates */ if ((si->si_cc & SP_SP) && cb->s_swl2 == si->si_ack && SSEQ_LT(cb->s_ralo, si->si_alo)) { --- 424,432 ---- update_window: if (SSEQ_LT(cb->s_snxt, cb->s_rack)) cb->s_snxt = cb->s_rack; ! if (SSEQ_LT(cb->s_swl1, si->si_seq) || (cb->s_swl1 == si->si_seq && (SSEQ_LT(cb->s_swl2, si->si_ack) || ! (cb->s_swl2 == si->si_ack && SSEQ_LT(cb->s_ralo, si->si_alo))))) { /* keep track of pure window updates */ if ((si->si_cc & SP_SP) && cb->s_swl2 == si->si_ack && SSEQ_LT(cb->s_ralo, si->si_alo)) { *************** *** 575,589 **** return (0); } spp_ctlinput(cmd, arg) int cmd; caddr_t arg; { struct ns_addr *na; ! extern u_char nsctlerrmap[]; ! extern spp_abort(), spp_quench(); ! extern struct nspcb *idp_drop(); ! struct ns_errp *errp; struct nspcb *nsp; struct sockaddr_ns *sns; int type; --- 584,596 ---- return (0); } + void spp_ctlinput(cmd, arg) int cmd; caddr_t arg; { struct ns_addr *na; ! struct ns_errp *errp = 0; /* compiler erroneously flags */ struct nspcb *nsp; struct sockaddr_ns *sns; int type; *************** *** 639,644 **** --- 646,652 ---- * When a source quench is received, close congestion window * to one packet. We will gradually open it again as we proceed. */ + void spp_quench(nsp) struct nspcb *nsp; { *************** *** 697,702 **** --- 705,711 ---- } #endif + int spp_output(cb, m0) register struct sppcb *cb; struct mbuf *m0; *************** *** 713,719 **** int idle; #endif struct mbuf *mprev; - extern int idpcksum; if (m0) { int mtu = cb->s_mtu; --- 722,727 ---- *************** *** 1112,1122 **** int spp_do_persist_panics = 0; spp_setpersist(cb) register struct sppcb *cb; { ! register t = ((cb->s_srtt >> 2) + cb->s_rttvar) >> 1; ! extern int spp_backoff[]; if (cb->s_timer[SPPT_REXMT] && spp_do_persist_panics) panic("spp_output REXMT"); --- 1120,1130 ---- int spp_do_persist_panics = 0; + void spp_setpersist(cb) register struct sppcb *cb; { ! register int t = ((cb->s_srtt >> 2) + cb->s_rttvar) >> 1; if (cb->s_timer[SPPT_REXMT] && spp_do_persist_panics) panic("spp_output REXMT"); *************** *** 1130,1135 **** --- 1138,1144 ---- cb->s_rxtshift++; } /*ARGSUSED*/ + int spp_ctloutput(req, so, level, name, value) int req; struct socket *so; *************** *** 1255,1267 **** } /*ARGSUSED*/ spp_usrreq(so, req, m, nam, controlp) struct socket *so; int req; struct mbuf *m, *nam, *controlp; { struct nspcb *nsp = sotonspcb(so); ! register struct sppcb *cb; int s = splnet(); int error = 0, ostate; struct mbuf *mm; --- 1264,1277 ---- } /*ARGSUSED*/ + int spp_usrreq(so, req, m, nam, controlp) struct socket *so; int req; struct mbuf *m, *nam, *controlp; { struct nspcb *nsp = sotonspcb(so); ! register struct sppcb *cb = NULL; int s = splnet(); int error = 0, ostate; struct mbuf *mm; *************** *** 1297,1303 **** } nsp = sotonspcb(so); ! mm = m_getclr(M_DONTWAIT, MT_PCB); sb = &so->so_snd; if (mm == NULL) { --- 1307,1314 ---- } nsp = sotonspcb(so); ! /* private PCB */ ! mm = m_getclr(M_DONTWAIT, MT_CONTROL); sb = &so->so_snd; if (mm == NULL) { *************** *** 1507,1512 **** --- 1518,1524 ---- return (error); } + int spp_usrreq_sp(so, req, m, nam, controlp) struct socket *so; int req; *************** *** 1528,1533 **** --- 1540,1546 ---- * in a skeletal spp header (choosing connection id), * minimizing the amount of work necessary when the connection is used. */ + void spp_template(cb) register struct sppcb *cb; { *************** *** 1622,1627 **** --- 1635,1641 ---- return (spp_close(cb)); } + void spp_abort(nsp) struct nspcb *nsp; { *************** *** 1629,1639 **** (void) spp_close((struct sppcb *)nsp->nsp_pcb); } - int spp_backoff[SPP_MAXRXTSHIFT+1] = - { 1, 2, 4, 8, 16, 32, 64, 64, 64, 64, 64, 64, 64 }; /* * Fast timeout routine for processing delayed acks */ spp_fasttimo() { register struct nspcb *nsp; --- 1643,1652 ---- (void) spp_close((struct sppcb *)nsp->nsp_pcb); } /* * Fast timeout routine for processing delayed acks */ + void spp_fasttimo() { register struct nspcb *nsp; *************** *** 1658,1663 **** --- 1671,1677 ---- * Updates the timers in all active pcb's and * causes finite state machine actions if timers expire. */ + void spp_slowtimo() { register struct nspcb *ip, *ipnxt; *************** *** 1682,1689 **** if (cb->s_timer[i] && --cb->s_timer[i] == 0) { (void) spp_usrreq(cb->s_nspcb->nsp_socket, PRU_SLOWTIMO, (struct mbuf *)0, ! (struct mbuf *)i, (struct mbuf *)0, ! (struct mbuf *)0); if (ipnxt->nsp_prev != ip) goto tpgone; } --- 1696,1702 ---- if (cb->s_timer[i] && --cb->s_timer[i] == 0) { (void) spp_usrreq(cb->s_nspcb->nsp_socket, PRU_SLOWTIMO, (struct mbuf *)0, ! (struct mbuf *)i, (struct mbuf *)0); if (ipnxt->nsp_prev != ip) goto tpgone; } Index: spp_var.h =================================================================== RCS file: /usr/cvs/src/sys/netns/spp_var.h,v retrieving revision 1.11 diff -c -r1.11 spp_var.h *** spp_var.h 29 Dec 1999 04:46:21 -0000 1.11 --- spp_var.h 5 Mar 2003 01:15:42 -0000 *************** *** 195,202 **** #endif u_short spp_iss; ! extern struct sppcb *spp_close(), *spp_disconnect(), ! *spp_usrclosed(), *spp_timers(), *spp_drop(); #endif #define SPP_ISSINCR 128 --- 195,224 ---- #endif u_short spp_iss; ! ! void spp_init __P((void)); ! void spp_input __P((struct mbuf *, struct nspcb *)); ! void spp_ctlinput __P((int, caddr_t)); ! int spp_ctloutput __P((int, struct socket *, int, int, struct mbuf **)); ! int spp_usrreq __P((struct socket *, int, struct mbuf *, struct mbuf *, ! struct mbuf *)); ! int spp_usrreq_sp __P((struct socket *, int, struct mbuf *, struct mbuf *, ! struct mbuf *)); ! void spp_fasttimo __P((void)); ! void spp_slowtimo __P((void)); ! void spp_template __P((struct sppcb *)); ! int spp_reass __P((struct sppcb *, struct spidp *)); ! int spp_output __P((struct sppcb *, struct mbuf *)); ! void spp_quench __P((struct nspcb *)); ! void spp_abort __P((struct nspcb *)); ! void spp_setpersist __P((struct sppcb *)); ! ! struct sppcb *spp_close __P((struct sppcb *)); ! struct sppcb *spp_disconnect __P((struct sppcb *)); ! struct sppcb *spp_usrclosed __P((struct sppcb *)); ! struct sppcb *spp_timers __P((struct sppcb *, int)); ! struct sppcb *spp_drop __P((struct sppcb *, int)); ! #endif #define SPP_ISSINCR 128 --------------81B31A38BCFEF66ED364CE7A-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 17:15:27 2003 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 8643937B401; Tue, 4 Mar 2003 17:15:25 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8DA543F75; Tue, 4 Mar 2003 17:15:24 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id AE7422A89E; Tue, 4 Mar 2003 17:15:24 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Julian Elischer Cc: Tim Robbins , freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Removal of netns In-Reply-To: Date: Tue, 04 Mar 2003 17:15:24 -0800 From: Peter Wemm Message-Id: <20030305011524.AE7422A89E@canning.wemm.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 Julian Elischer wrote: > I thought nwfs used it? Nope. But actually looking at the code would have told you that. Remember, we're talking about the Xerox networking suite here. It's not like its a widely deployed protocol or something important. > > On Wed, 5 Mar 2003, Tim Robbins wrote: > > > Is there a compelling reason why I shouldn't remove netns? That is, does > > it serve a purpose now that it could not serve if it was moved to the > > Attic? > > > > > > Tim > > > > 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-current" in the body of the message > Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 17:18:22 2003 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 46D7F37B401; Tue, 4 Mar 2003 17:18:20 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB05643FBF; Tue, 4 Mar 2003 17:18:19 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id B590E2A89E; Tue, 4 Mar 2003 17:18:19 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Darcy Buskermolen Cc: Chris Fowler , freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Removal of netns In-Reply-To: <200303041638.13457.darcy@wavefire.com> Date: Tue, 04 Mar 2003 17:18:19 -0800 From: Peter Wemm Message-Id: <20030305011819.B590E2A89E@canning.wemm.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 Darcy Buskermolen wrote: > I have at least 1 VPN setup that requires full IPX support. Yep, but keep in mind that netipx is different to netns. netipx actually works and is actually useful. > On Tuesday 04 March 2003 15:32, Chris Fowler wrote: > > What is IPX currently being used for? Legacy systems? > > > > I've been stuck in TCP/IP land for many years now. Have been lucky > > enough to not run into any IPX. > > > > On Tue, 2003-03-04 at 18:26, Tim Robbins wrote: > > > On Tue, Mar 04, 2003 at 02:53:56PM -0800, Julian Elischer wrote: > > > > I thought nwfs used it? > > > > > > nwfs uses netipx. From what I can tell, netipx was based on netns. > > > > > > > > > Tim > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-current" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > --=20 > Darcy Buskermolen > Wavefire Technologies Corp. > ph: 250.717.0200 > fx: 250.763.1759 > http://www.wavefire.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 17:28: 0 2003 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 BAE6E37B401; Tue, 4 Mar 2003 17:27:58 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 206F743FCB; Tue, 4 Mar 2003 17:27:58 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 09C912A89E; Tue, 4 Mar 2003 17:27:58 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Terry Lambert Cc: Mike Barcroft , Tim Robbins , freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Removal of netns - politically correct version In-Reply-To: <3E6539B5.2F5D31B@mindspring.com> Date: Tue, 04 Mar 2003 17:27:58 -0800 From: Peter Wemm Message-Id: <20030305012758.09C912A89E@canning.wemm.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 Terry Lambert wrote: > Peter Wemm wrote: > > Terry Lambert wrote: > > > Is there a compelling reason for removing this working code to > > > the Attic? > > > > Terry: will you please check your facts? It takes around 30 seconds > > to find out that it doesn't even compile. > > [ ... lots of trivial to fix warnings and errors ... ] > > > Tell you what, I'll fix these and post a patch. Will that make you > guys happy? Not really. I'd like to see a relevant demonstration of it working with another relevant networking system [that does NOT speak some other common protocol such as IP or IPX] that shows that it is worth keeping this baggage around. No, I'm not interested in some DOS-2.11 floppy disks you have had sitting untouched in a drawer for 10 years. ie: Show that it is worth something to the project to keep it. This was only revived last time because somebody promised to maintain it. And as you can see, for the last 7 years it hasn't been missed. The point wasn't that "it doesn't compile", rather "nobody gave a damn that it didn't compile for 7 years". Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 17:34:43 2003 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 7EBED37B401 for ; Tue, 4 Mar 2003 17:34:42 -0800 (PST) Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8E2343FBF for ; Tue, 4 Mar 2003 17:34:40 -0800 (PST) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 87964 invoked from network); 5 Mar 2003 01:51:50 -0000 Received: from babolo.ru (HELO cicuta.babolo.ru) (194.58.226.160) by ints.mail.pike.ru with SMTP; 5 Mar 2003 01:51:50 -0000 Received: (nullmailer pid 1188 invoked by uid 136); Wed, 05 Mar 2003 01:36:50 -0000 Subject: Re: counting firewall traffic on a second machine X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <20030304021141.C49939-100000@mail.econolodgetulsa.com> To: Josh Brooks Date: Wed, 5 Mar 2003 04:36:49 +0300 (MSK) From: "."@babolo.ru Cc: freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1046828210.004291.1187.nullmailer@cicuta.babolo.ru> 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 used to have a firewall with ipfw count rules in place for every IP I > had. This worked fine, but it gave me a 2000+ ruleset that would cause > cpu to skyrocket under even the lightest of DoS attacks. > > So, I have plugged in another system on the DMZ and plan to count from > there. > > In the most basic sense, I am thinking of sniffing trafficon this second > machine and counting via that mechanism. > > Is this a common setup - counting traffic on a second machine that the > traffic does not even flow through ? If so, is ipfw count rules used on > the counting machine, or is there a better tool for counting per-IP > traffic on a secondary system like this ? > > Any suggestions are appreciated. i will be using MRTG to show the stats, > but again, the actual gathering / counting method I will use i am not sure > of ... was planning on using ipfw count rules, but thought I would ask. > > And I am not sure of how to sniff traffic and pass it to ipfw to count .. > so perhaps ipfw is not involved at all... Use of specialised account tools is better. I use ports/net/argus with some postprocessing, but it is not simpliest way. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 17:35:11 2003 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 6FE2837B401; Tue, 4 Mar 2003 17:35:10 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3A3043F85; Tue, 4 Mar 2003 17:35:09 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id AD7662A8BB; Tue, 4 Mar 2003 17:35:09 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Terry Lambert Cc: Mike Barcroft , Tim Robbins , freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: [PATCH] make netns compile cleanly (was Re: Removal of netns - politically correct version In-Reply-To: <3E654D75.E37B5861@mindspring.com> Date: Tue, 04 Mar 2003 17:35:09 -0800 From: Peter Wemm Message-Id: <20030305013509.AD7662A8BB@canning.wemm.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 Terry Lambert wrote: > Terry Lambert wrote: > > Peter Wemm wrote: > > > Terry: will you please check your facts? It takes around 30 seconds > > > to find out that it doesn't even compile. > > > > [ ... lots of trivial to fix warnings and errors ... ] > > > > Tell you what, I'll fix these and post a patch. Will that make you > > guys happy? > > > > This crap is *soooooooo* trivial to fix, it's easier to fix than > > to watch you guys bitch about it not being fixable. > > > Here are two patches. The first fixes missing pieces in /sys/conf/files > and /sys/conf/options, the second fixes all the files that need it in > /sys/netns/. You seem to have posted the wrong patch. This is against 4.x, not -current, and this is current@freebsd.org. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 18:41:20 2003 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 CC13537B401 for ; Tue, 4 Mar 2003 18:41:18 -0800 (PST) Received: from fubar.adept.org (fubar.adept.org [63.147.172.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 480ED43FB1 for ; Tue, 4 Mar 2003 18:41:18 -0800 (PST) (envelope-from mike@adept.org) Received: by fubar.adept.org (Postfix, from userid 1001) id 2A00E15227; Tue, 4 Mar 2003 18:39:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by fubar.adept.org (Postfix) with ESMTP id 27B0515226 for ; Tue, 4 Mar 2003 18:39:23 -0800 (PST) Date: Tue, 4 Mar 2003 18:39:23 -0800 (PST) From: Mike Hoskins To: freebsd-net@freebsd.org Subject: Re: Transparent Proxy In-Reply-To: <200302201559.16002.darcy@wavefire.com> Message-ID: <20030304183210.A70561-100000@fubar.adept.org> 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, 25 Feb 2003, Darcy Buskermolen wrote: > I'm trying to deploy a transparent proxy server for a friend's office but have > run into a couple of snags that I can't seam to find the correct answer for. a) Draw a diagram, b) Check IPFW rules (tcpdump is your friend), c) Check out transproxy... A) and b) were suggested by others... The few times I've done this, it /really/ helped to have a clear diagram (that you understand) of what's going on. Then you can double-check your rulechain and ensure everything makes sense. For c), see /usr/ports/www/transproxy... From pkg-descr: transproxy - transparently proxy HTTP requests. This program is used with ipfw's fwd rules or Darren Reed's IPFILTER package, and is used to intercept HTTP requests and divert them to a HTTP proxy server (eg: squid), without requiring user intervention or configuration. The last time I set this up, I used transproxy and (after getting my ipfw rules right) things worked great. (Just make sure you're using the /usr/ports/www/squid port, I.e. Squid 2.5.x.) -m To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 18:58: 4 2003 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 A657137B401 for ; Tue, 4 Mar 2003 18:58:03 -0800 (PST) Received: from fubar.adept.org (fubar.adept.org [63.147.172.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C7DA43F75 for ; Tue, 4 Mar 2003 18:58:03 -0800 (PST) (envelope-from mike@adept.org) Received: by fubar.adept.org (Postfix, from userid 1001) id BBEFF15227; Tue, 4 Mar 2003 18:56:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by fubar.adept.org (Postfix) with ESMTP id BB33115226 for ; Tue, 4 Mar 2003 18:56:08 -0800 (PST) Date: Tue, 4 Mar 2003 18:56:08 -0800 (PST) From: Mike Hoskins To: net@freebsd.org Subject: Re: Performance tuning hints of gigabit networking? In-Reply-To: <20030227.160757.68128597.cjh@kr.FreeBSD.org> Message-ID: <20030304185448.A70561-100000@fubar.adept.org> 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, 27 Feb 2003, CHOI Junho wrote: > Final: What is a good math for calculating these values safely? > kern.ipc.nmbclusters > kern.ipc.nsfbufs FWIW, The math you want should be in tuning(7). -m To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 4 19:51:28 2003 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 1E50F37B401; Tue, 4 Mar 2003 19:51:27 -0800 (PST) Received: from relay.butya.kz (butya-gw.butya.kz [212.19.129.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E58643FA3; Tue, 4 Mar 2003 19:51:25 -0800 (PST) (envelope-from bp@vertex.kz) Received: by relay.butya.kz (Postfix, from userid 1000) id EC508591C; Wed, 5 Mar 2003 09:51:21 +0600 (ALMT) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id DE6F34944; Wed, 5 Mar 2003 09:51:21 +0600 (ALMT) Date: Wed, 5 Mar 2003 09:51:21 +0600 (ALMT) From: Boris Popov X-Sender: bp@lion.butya.kz To: Tim Robbins Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Removal of netns In-Reply-To: <20030305004730.A13129@dilbert.robbins.dropbear.id.au> 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 Wed, 5 Mar 2003, Tim Robbins wrote: > Is there a compelling reason why I shouldn't remove netns? That is, does > it serve a purpose now that it could not serve if it was moved to the > Attic? netns could be safely moved to Attic. I'm receive enough IPX related questions, and never got any about XNS. netns stack was used by NetCon package which implemented TFS filesystem for NetWare connectivity. Guess, which protocol they used to communicate with servers ? Right, it was IPX. So, if netns were still supported it became just a parallel implementation of netipx. Last version of FreeBSD supported by NetCon was 2.2.X. Lack of support for FreeBSD 3.X encouraged me to write nwfs because it was necessary for my daily tasks. BTW, NetCon still offers their product for FreeBSD 2.2: http://www.netcon.com/download/download.htm -- Boris Popov http://rbp.euro.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 0:47:32 2003 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 BC2E137B401; Wed, 5 Mar 2003 00:47:31 -0800 (PST) Received: from gidgate.gid.co.uk (gid.co.uk [194.32.164.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4D8443FDD; Wed, 5 Mar 2003 00:47:28 -0800 (PST) (envelope-from rb@gid.co.uk) Received: (from rb@localhost) by gidgate.gid.co.uk (8.11.6/8.11.6) id h258lFu91127; Wed, 5 Mar 2003 08:47:15 GMT (envelope-from rb) Message-Id: <4.3.2.7.2.20030305084442.037e9fa0@gid.co.uk> X-Sender: rbmail@gid.co.uk X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Mar 2003 08:47:15 +0000 To: Peter Wemm , Terry Lambert From: Bob Bishop Subject: Re: Removal of netns - politically correct version Cc: Mike Barcroft , Tim Robbins , freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG In-Reply-To: <20030305012758.09C912A89E@canning.wemm.org> References: <3E6539B5.2F5D31B@mindspring.com> 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 Hi, Here's a hint: "The Apollo Domain and XNS networking protocols will no longer be offered after Cisco IOS Release 12.2. Information about these protocols will not appear in future releases of the Cisco IOS software documentation set." http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a008007fba7.html He's dead, Jim. -- Bob Bishop +44 (0)118 977 4017 rb@gid.co.uk fax +44 (0)118 989 4254 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 0:59:29 2003 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 8777537B401; Wed, 5 Mar 2003 00:59:27 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE9A643F93; Wed, 5 Mar 2003 00:59:26 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from dialup-209.245.134.12.dial1.sanjose1.level3.net ([209.245.134.12] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18qUkA-0002YM-00; Wed, 05 Mar 2003 00:59:19 -0800 Message-ID: <3E65BB24.3E37D90D@mindspring.com> Date: Wed, 05 Mar 2003 00:53:56 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Bishop Cc: Peter Wemm , Mike Barcroft , Tim Robbins , freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns - politically correct version References: <3E6539B5.2F5D31B@mindspring.com> <4.3.2.7.2.20030305084442.037e9fa0@gid.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a46d87ca3c496d9e3a738bd6810ba7b878350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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 Bob Bishop wrote: > Here's a hint: > > "The Apollo Domain and XNS networking protocols will no longer be offered > after Cisco IOS Release 12.2. Information about these protocols will not > appear in future releases of the Cisco IOS software documentation set." > http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a008007fba7.html > > He's dead, Jim. The code is still useful as a simple implementation, much more easily understood by the student than the current TCP/IP stack, for certain. Given that the current TCP/IP stack no longer matches the Stevens books, and given that Stevens is too dead to update the books to the new FreeBSD stack, even if he wanted to, it's useful to have a relatively simple set of code that can be understood without a book that's not getting written. Also, it's interesting from the perspective of people with living Xerox Alto hardware (not many, but they do exist), but I fully admit that that's not a compelling reason. On the other hand, there's no compelling reason to dike it out, if it can be made to work. I would argue that ISA support is more or less just as obsolete, as is 486 support, as is the F00F bug workaround, as is ... a lot of code that's still there. In any case, Peter pointed out that my patch was against -stable, not -current. I'm in the process of CVSup'ing new sources now, and will update the patch against -current, and post it, most likely tomorrow morning, if the CVSup doesn't complete in the next hour. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 1: 7: 9 2003 Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 1D37937B401; Wed, 5 Mar 2003 01:07:08 -0800 (PST) Date: Wed, 5 Mar 2003 03:07:08 -0600 From: Juli Mallett To: Terry Lambert Cc: Bob Bishop , Peter Wemm , Mike Barcroft , Tim Robbins , freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns - politically correct version Message-ID: <20030305030708.A21014@FreeBSD.org> References: <3E6539B5.2F5D31B@mindspring.com> <4.3.2.7.2.20030305084442.037e9fa0@gid.co.uk> <3E65BB24.3E37D90D@mindspring.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: <3E65BB24.3E37D90D@mindspring.com>; from tlambert2@mindspring.com on Wed, Mar 05, 2003 at 12:53:56AM -0800 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , , X-Towel: Yes X-Negacore: Yes X-Title: Code Maven 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: Terry Lambert [ Data: 2003-03-05 ] [ Subjecte: Re: Removal of netns - politically correct version ] > On the other hand, there's no compelling reason to dike it out, > if it can be made to work. I would argue that ISA support is > more or less just as obsolete, as is 486 support, as is the F00F > bug workaround, as is ... a lot of code that's still there. I have a 486, lots of people have 486 PC 104 boards. I have a lot of ISA stuff. VLSI support would be equally obsolete. So would support for a Sequent SMP 386. We don't support them. We have at least one feature you demonstate over and over needs moved to the attic. -- juli mallett. email: jmallett@freebsd.org; aim: bsdflata; efnet: juli; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 1:16:14 2003 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 934D137B401; Wed, 5 Mar 2003 01:16:12 -0800 (PST) Received: from gidgate.gid.co.uk (gid.co.uk [194.32.164.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FE6C43FAF; Wed, 5 Mar 2003 01:16:10 -0800 (PST) (envelope-from rb@gid.co.uk) Received: (from rb@localhost) by gidgate.gid.co.uk (8.11.6/8.11.6) id h259G8D91238; Wed, 5 Mar 2003 09:16:08 GMT (envelope-from rb) Message-Id: <4.3.2.7.2.20030305091443.037eb018@gid.co.uk> X-Sender: rbmail@gid.co.uk X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Mar 2003 09:16:08 +0000 To: Terry Lambert From: Bob Bishop Subject: Re: Removal of netns - politically correct version Cc: Peter Wemm , Mike Barcroft , Tim Robbins , freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG In-Reply-To: <3E65BB24.3E37D90D@mindspring.com> References: <3E6539B5.2F5D31B@mindspring.com> <4.3.2.7.2.20030305084442.037e9fa0@gid.co.uk> 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 Hi At 08:53 5/3/03, Terry Lambert wrote: >[...] >The code is still useful as a simple implementation, much more >easily understood by the student than the current TCP/IP stack, >for certain. The same is true for netipx (wc -l *.[ch] is almost identical). -- Bob Bishop +44 (0)118 977 4017 rb@gid.co.uk fax +44 (0)118 989 4254 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 1:24:17 2003 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 E007A37B401; Wed, 5 Mar 2003 01:24:16 -0800 (PST) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E93143FA3; Wed, 5 Mar 2003 01:24:16 -0800 (PST) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 995D314351; Wed, 5 Mar 2003 03:24:15 -0600 (CST) Date: Wed, 5 Mar 2003 03:24:15 -0600 (CST) From: Mark Linimon X-X-Sender: linimon@pancho To: Terry Lambert Cc: Bob Bishop , Peter Wemm , Mike Barcroft , Tim Robbins , , In-Reply-To: <3E65BB24.3E37D90D@mindspring.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 the other hand, there's no compelling reason to dike it out, > if it can be made to work. work == "not just compiled, but QAed against known-working implementations and correctly documented". Have fun. Looking forward to the patches and logs. mcl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 1:27:25 2003 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 CDB1537B401; Wed, 5 Mar 2003 01:27:23 -0800 (PST) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 915E043F75; Wed, 5 Mar 2003 01:27:22 -0800 (PST) (envelope-from DougB@freebsd.org) Received: from master.gorean.org (12-234-22-23.client.attbi.com[12.234.22.23]) by sccrmhc02.attbi.com (sccrmhc02) with SMTP id <200303050927200020081etbe>; Wed, 5 Mar 2003 09:27:21 +0000 Date: Wed, 5 Mar 2003 01:27:20 -0800 (PST) From: Doug Barton To: Terry Lambert Cc: Bob Bishop , Peter Wemm , Mike Barcroft , Tim Robbins , freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns - politically correct version In-Reply-To: <3E65BB24.3E37D90D@mindspring.com> Message-ID: <20030305011926.T18288@znfgre.tberna.bet> References: <3E6539B5.2F5D31B@mindspring.com> <4.3.2.7.2.20030305084442.037e9fa0@gid.co.uk> <3E65BB24.3E37D90D@mindspring.com> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! 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 Wed, 5 Mar 2003, Terry Lambert wrote: > The code is still useful as a simple implementation, much more > easily understood by the student than the current TCP/IP stack, > for certain. And it will still be available. It'll just be available in the Attic. The fact that it will get more broken in the future because it's not being maintained in the tree is not terribly significant since it's already broken now. > On the other hand, there's no compelling reason to dike it out, There is at least one, namely that it will make kernel code updates easier to do, and easier to test. > if it can be made to work. I would argue that ISA support is > more or less just as obsolete, as is 486 support, as is the F00F > bug workaround, as is ... a lot of code that's still there. Your argument here is non sequitur because we still have large bases of users and developers that have and use this hardware. I retired a box with an original P90 f00f bug cpu not that long ago, for example. netns has neither freebsd users or developers, and hasn't for years. > In any case, Peter pointed out that my patch was against -stable, > not -current. I'm in the process of CVSup'ing new sources now, > and will update the patch against -current, and post it, most > likely tomorrow morning, if the CVSup doesn't complete in the next > hour. I think that fixing the current brokeness is still useful, even if it gets axed. Putting it to bed with a full tummy will make future educational value of the code that much higher. Doug -- This .signature sanitized for your protection To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 1:34:46 2003 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 2090C37B401; Wed, 5 Mar 2003 01:34:44 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 671D043F3F; Wed, 5 Mar 2003 01:34:43 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from dialup-209.245.134.12.dial1.sanjose1.level3.net ([209.245.134.12] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18qVIQ-00069f-00; Wed, 05 Mar 2003 01:34:42 -0800 Message-ID: <3E65C34D.19E2D95C@mindspring.com> Date: Wed, 05 Mar 2003 01:28:45 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Juli Mallett Cc: Bob Bishop , Peter Wemm , Mike Barcroft , Tim Robbins , freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns - politically correct version References: <3E6539B5.2F5D31B@mindspring.com> <4.3.2.7.2.20030305084442.037e9fa0@gid.co.uk> <3E65BB24.3E37D90D@mindspring.com> <20030305030708.A21014@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4905eca38be64cb1cec62febb9e2426ba3ca473d225a0f487350badd9bab72f9c350badd9bab72f9c 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 Juli Mallett wrote: > * De: Terry Lambert [ Data: 2003-03-05 ] > [ Subjecte: Re: Removal of netns - politically correct version ] > > On the other hand, there's no compelling reason to dike it out, > > if it can be made to work. I would argue that ISA support is > > more or less just as obsolete, as is 486 support, as is the F00F > > bug workaround, as is ... a lot of code that's still there. > > I have a 486, lots of people have 486 PC 104 boards. I have a lot > of ISA stuff. VLSI support would be equally obsolete. So would > support for a Sequent SMP 386. We don't support them. We have at > least one feature you demonstate over and over needs moved to the > attic. I personally have two 4-port terminal servers that speak XNS. I'm pretty sure that others exist. The argument about "IPX is just as simple" is true. But it's not useful for educational purposes, because it collides with a protocol in common use; hacking it up isn't a good thing. The argument about Cisco's IOS not supporting it soon is irrelevent, until all the Cisco's on the net have their IOS image updated to the version that doesn't support it. It took about 3 years for the updates to get out there so IPv6 was usable, so we have at least 3 years. If you want to make this argument about "orphan code", then make it about "orphan code". If you want to make this argument about "reduced FreeBSD size", then make it about "reduced FreeBSD size". If you want to make it about "failure to attract a maintainer", then do that. I can give you reasoned arguments why all of these are wrong, using historical examples from previous major code changes in the FreeBSD source tree. And here we see the source of my previous cynicism: The truth is that you are proving that this was never about "the code does not even compile", and you are proving that this was never about "no one is willing to maintain the code". If you go ahead and dike the code out, in the future, don't be disingenuous about your motives in doing so, and pretend that they are based on legitimate maintenance concerns, when they aren't. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 1:38:37 2003 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 A83B537B405; Wed, 5 Mar 2003 01:38:35 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id C424943FBD; Wed, 5 Mar 2003 01:38:34 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from dialup-209.245.134.12.dial1.sanjose1.level3.net ([209.245.134.12] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18qVM6-0006P9-00; Wed, 05 Mar 2003 01:38:31 -0800 Message-ID: <3E65C432.F3F1C42C@mindspring.com> Date: Wed, 05 Mar 2003 01:32:34 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Linimon Cc: Bob Bishop , Peter Wemm , Mike Barcroft , Tim Robbins , freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4f02ef0987691519604ada4c5205a492c666fa475841a1c7a350badd9bab72f9c350badd9bab72f9c 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 Mark Linimon wrote: > > On the other hand, there's no compelling reason to dike it out, > > if it can be made to work. > > work == "not just compiled, but QAed against known-working implementations > and correctly documented". > > Have fun. Looking forward to the patches and logs. Just to be perfectly clear on what you are saying here: Diking things out is OK, if there's no proven QA and/or no documentation, or the documentation which exists is not correct, right? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 1:43: 1 2003 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 F2B5537B405; Wed, 5 Mar 2003 01:42:58 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 395BD43FCB; Wed, 5 Mar 2003 01:42:58 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from dialup-209.245.134.12.dial1.sanjose1.level3.net ([209.245.134.12] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18qVQO-0006j4-00; Wed, 05 Mar 2003 01:42:57 -0800 Message-ID: <3E65C538.A4F7A73A@mindspring.com> Date: Wed, 05 Mar 2003 01:36:56 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Doug Barton Cc: Bob Bishop , Peter Wemm , Mike Barcroft , Tim Robbins , freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns - politically correct version References: <3E6539B5.2F5D31B@mindspring.com> <4.3.2.7.2.20030305084442.037e9fa0@gid.co.uk> <3E65BB24.3E37D90D@mindspring.com> <20030305011926.T18288@znfgre.tberna.bet> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4f02ef09876915196a9cad9c88b30f9922601a10902912494350badd9bab72f9c350badd9bab72f9c 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 Doug Barton wrote: > On Wed, 5 Mar 2003, Terry Lambert wrote: > > The code is still useful as a simple implementation, much more > > easily understood by the student than the current TCP/IP stack, > > for certain. > > And it will still be available. It'll just be available in the Attic. The > fact that it will get more broken in the future because it's not being > maintained in the tree is not terribly significant since it's already > broken now. Why don't we let me sumbit patches, apply the things, and *then* dike the code out, if that's your reasoning? > > On the other hand, there's no compelling reason to dike it out, > > There is at least one, namely that it will make kernel code updates easier > to do, and easier to test. And here people were telling me I was wrong for cynically assuming that the reason people diked out so much code in the past year was because they wanted to perform kernel code updates, without having to maintain all the code they would be touching with those updates... > > if it can be made to work. I would argue that ISA support is > > more or less just as obsolete, as is 486 support, as is the F00F > > bug workaround, as is ... a lot of code that's still there. > > Your argument here is non sequitur because we still have large bases of > users and developers that have and use this hardware. I retired a box with > an original P90 f00f bug cpu not that long ago, for example. netns has > neither freebsd users or developers, and hasn't for years. And I have two XNS terminalservers, and there are people on this list with Apollo equipment. Your point was again? > > In any case, Peter pointed out that my patch was against -stable, > > not -current. I'm in the process of CVSup'ing new sources now, > > and will update the patch against -current, and post it, most > > likely tomorrow morning, if the CVSup doesn't complete in the next > > hour. > > I think that fixing the current brokeness is still useful, even if it gets > axed. Putting it to bed with a full tummy will make future educational > value of the code that much higher. I suggested that before. People are telling me they won't apply the patches before they murder the code. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 1:44:35 2003 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 CC85C37B401; Wed, 5 Mar 2003 01:44:33 -0800 (PST) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DAA043FD7; Wed, 5 Mar 2003 01:44:33 -0800 (PST) (envelope-from DougB@freebsd.org) Received: from master.gorean.org (12-234-22-23.client.attbi.com[12.234.22.23]) by rwcrmhc53.attbi.com (rwcrmhc53) with SMTP id <20030305094432053001sbsae>; Wed, 5 Mar 2003 09:44:32 +0000 Date: Wed, 5 Mar 2003 01:44:32 -0800 (PST) From: Doug Barton To: Terry Lambert Cc: Juli Mallett , Bob Bishop , Peter Wemm , Mike Barcroft , Tim Robbins , freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns - politically correct version In-Reply-To: <3E65C34D.19E2D95C@mindspring.com> Message-ID: <20030305014105.K18288@znfgre.tberna.bet> References: <3E6539B5.2F5D31B@mindspring.com> <4.3.2.7.2.20030305084442.037e9fa0@gid.co.uk> <3E65BB24.3E37D90D@mindspring.com> <20030305030708.A21014@FreeBSD.org> <3E65C34D.19E2D95C@mindspring.com> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! 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 Wed, 5 Mar 2003, Terry Lambert wrote: > If you want to make it about "failure to attract a maintainer", then > do that. Actually several people have made this argument, along with the corollary "failure to attract a userbase." -- This .signature sanitized for your protection To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 1:47:30 2003 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 8BBB037B401; Wed, 5 Mar 2003 01:47:29 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07AA143FCB; Wed, 5 Mar 2003 01:47:29 -0800 (PST) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18qVUm-0001Ce-00; Wed, 05 Mar 2003 01:47:28 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18qVUk-0000uQ-00; Wed, 05 Mar 2003 01:47:26 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 5 Mar 2003 01:47:25 -0800 To: Terry Lambert Cc: freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns - politically correct version References: <3E6539B5.2F5D31B@mindspring.com> <4.3.2.7.2.20030305084442.037e9fa0@gid.co.uk> <3E65BB24.3E37D90D@mindspring.com> <20030305030708.A21014@FreeBSD.org> <3E65C34D.19E2D95C@mindspring.com> Message-Id: 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 > It took about 3 years for the updates to get out there so IPv6 > was usable i have yet to see a cisco ios image supporting ipv6 that was usable in production environment. and i have tried hard. but i will admit to not having seen apollo networking for over a decade. but i probably have not been looking very widely. seems to me that one useful question is whether the netns code being there non-trivially complicates maintenance and/or reliability of other code, and can i compile or module it out if the bits it occupies really bothers me? randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 1:47:52 2003 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 4340B37B401 for ; Wed, 5 Mar 2003 01:47:49 -0800 (PST) Received: from daemon.kr.FreeBSD.org (daemon.kr.freebsd.org [211.176.62.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D73643FB1 for ; Wed, 5 Mar 2003 01:47:48 -0800 (PST) (envelope-from cjh@kr.FreeBSD.org) Received: from gradius.wdb.co.kr (daemon [211.176.62.31]) by daemon.kr.FreeBSD.org (Postfix) with ESMTP id A02D48F65B; Wed, 5 Mar 2003 18:47:46 +0900 (KST) Received: from localhost (localhost [127.0.0.1]) by gradius.wdb.co.kr (8.12.7/8.12.7) with ESMTP id h242qw8x090841; Tue, 4 Mar 2003 11:53:00 +0900 (KST) (envelope-from cjh@kr.FreeBSD.org) Date: Tue, 04 Mar 2003 11:52:58 +0900 (KST) Message-Id: <20030304.115258.21844180.cjh@kr.FreeBSD.org> To: bmilekic@unixdaemons.com Cc: net@freebsd.org Subject: Re: Performance tuning hints of gigabit networking? From: CHOI Junho In-Reply-To: <20030303180014.A7317@unixdaemons.com> References: <20030226.220551.10329540.cjh@kr.FreeBSD.org> <20030303180014.A7317@unixdaemons.com> Organization: Korea FreeBSD Users Group X-URL: http://www.kr.FreeBSD.org/~cjh X-Mailer: Mew version 3.2rc1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 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 That's 2GB machine. How much RAM I need more? mbuf clusters is full(observed by netstat -m) at peak time(3-4 hours). netstat -m output below is when the connection is low, but please see the peak value of mbuf clusters. From: Bosko Milekic Subject: Re: Performance tuning hints of gigabit networking? Date: Mon, 3 Mar 2003 18:00:14 -0500 > > > You're not running out of mbufs or clusters, you're out of RAM. > Don't bump up nmbclusters anymore because you don't need to; instead, > add more RAM. > > On Wed, Feb 26, 2003 at 10:05:51PM +0900, CHOI Junho wrote: > > > > Hi, > > > > I am looking for a good resource for kernel tuning on very high > > bandwidth HTTP servers(avg 500Mbit/sec, peak 950Mbit/sec). Today I > > faced very unusual situation with 950Mbit/sec bandwidth! > > > > > netstat -m > > 16962/93488/262144 mbufs in use (current/peak/max): > > 16962 mbufs allocated to data > > 16952/65536/65536 mbuf clusters in use (current/peak/max) > > 154444 Kbytes allocated to network (14% of mb_map in use) > > 512627 requests for memory denied > > 2614 requests for memory delayed > > 0 calls to protocol drain routines > > > > I set kern.ipc.nmbclusters=65536, but it overflowed. This is P-IV Xeon > > 1.8G, 2GB RAM, and one Intel 1000baseSX(em driver) machine running > > 4.7-RELEASE-pX. This server is running only one service, HTTP. I use > > thttpd, since apache doesn't work in such a high load. thttpd is highly > > amazing, just give <1 load in any time. > > > > Once I tried to increase kern.ipc.nmbclusters to 131072 or > > higher(multiple of 65536 or 32768, tuning(7) only cites about 32768 > > case..), it fails to boot kernel when 262144, or kernel panic in > > somewhat higher load when 131072, so I gave up other changes and fall > > back to 65536. > > > > What is a good way to calcurate this value safely? Here is another > > hint, /etc/sysctl.conf: > > > > net.link.ether.inet.log_arp_wrong_iface=0 > > kern.ipc.maxsockbuf=2048000 > > kern.ipc.somaxconn=4096 > > kern.ipc.maxsockets=60000 > > kern.maxfiles=65536 > > kern.maxfilesperproc=32768 > > net.inet.tcp.rfc1323=1 > > net.inet.tcp.delayed_ack=0 > > net.inet.tcp.sendspace=65535 > > net.inet.tcp.recvspace=65535 > > net.inet.udp.recvspace=65535 > > net.inet.udp.maxdgram=57344 > > net.inet.icmp.drop_redirect=1 > > net.inet.icmp.log_redirect=1 > > net.inet.ip.redirect=0 > > net.inet6.ip6.redirect=0 > > net.link.ether.inet.max_age=1200 > > net.inet.ip.sourceroute=0 > > net.inet.ip.accept_sourceroute=0 > > net.inet.icmp.bmcastecho=0 > > net.inet.icmp.maskrepl=0 > > net.inet.tcp.inflight_enable=1 > > > > kernel configuration is not specially tuned, except DEVICE_POLLING and > > HZ=2000. > > > > -- > > CHOI Junho KFUG > > FreeBSD Project Web Data Bank > > Key fingerprint = 1369 7374 A45F F41A F3C0 07E3 4A01 C020 E602 60F5 > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > -- > Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org -- CHOI Junho KFUG FreeBSD Project Web Data Bank Key fingerprint = 1369 7374 A45F F41A F3C0 07E3 4A01 C020 E602 60F5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 1:51:26 2003 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 2802137B401; Wed, 5 Mar 2003 01:51:25 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F03143FA3; Wed, 5 Mar 2003 01:51:24 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from dialup-209.245.134.12.dial1.sanjose1.level3.net ([209.245.134.12] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18qVYY-0007Lq-00; Wed, 05 Mar 2003 01:51:23 -0800 Message-ID: <3E65C72C.789FE15@mindspring.com> Date: Wed, 05 Mar 2003 01:45:16 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Doug Barton Cc: Juli Mallett , Bob Bishop , Peter Wemm , Mike Barcroft , Tim Robbins , freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns - politically correct version References: <3E6539B5.2F5D31B@mindspring.com> <4.3.2.7.2.20030305084442.037e9fa0@gid.co.uk> <3E65BB24.3E37D90D@mindspring.com> <20030305030708.A21014@FreeBSD.org> <3E65C34D.19E2D95C@mindspring.com> <20030305014105.K18288@znfgre.tberna.bet> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4f02ef098769151960f747dfc0293a497666fa475841a1c7a350badd9bab72f9c350badd9bab72f9c 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 Doug Barton wrote: > On Wed, 5 Mar 2003, Terry Lambert wrote: > > If you want to make it about "failure to attract a maintainer", then > > do that. > > Actually several people have made this argument, along with the corollary > "failure to attract a userbase." I would claim that non-working code *repelled* the userbase, just as all the packet radio people went to Linux when the ISODE code was murdered and X.25 went away, the same way we are talking about doing to the XNS code now. If your system can't do something, then *of course* you are n'tgoing to attract user who want to do that something: they will go to systems that aren't incapable of doing what they want. I would claim that the "failure to attract a maintainer" was a result of too stringent control of commit priviledges. There is code lying fallow in FreeBSD now which has no maintainer, for lack of commit priviledges for people willing to maintain the code (and no, I am not making a case for myself here). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 1:55:29 2003 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 9ACAB37B401; Wed, 5 Mar 2003 01:55:27 -0800 (PST) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8129E43FB1; Wed, 5 Mar 2003 01:55:26 -0800 (PST) (envelope-from DougB@freebsd.org) Received: from master.gorean.org (12-234-22-23.client.attbi.com[12.234.22.23]) by sccrmhc01.attbi.com (sccrmhc01) with SMTP id <2003030509552500100j6lshe>; Wed, 5 Mar 2003 09:55:25 +0000 Date: Wed, 5 Mar 2003 01:55:24 -0800 (PST) From: Doug Barton To: Terry Lambert Cc: Bob Bishop , Peter Wemm , Mike Barcroft , Tim Robbins , freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns - politically correct version In-Reply-To: <3E65C538.A4F7A73A@mindspring.com> Message-ID: <20030305014800.E18288@znfgre.tberna.bet> References: <3E6539B5.2F5D31B@mindspring.com> <4.3.2.7.2.20030305084442.037e9fa0@gid.co.uk> <3E65BB24.3E37D90D@mindspring.com> <20030305011926.T18288@znfgre.tberna.bet> <3E65C538.A4F7A73A@mindspring.com> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! 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 Wed, 5 Mar 2003, Terry Lambert wrote: > Doug Barton wrote: > > On Wed, 5 Mar 2003, Terry Lambert wrote: > > > The code is still useful as a simple implementation, much more > > > easily understood by the student than the current TCP/IP stack, > > > for certain. > > > > And it will still be available. It'll just be available in the Attic. The > > fact that it will get more broken in the future because it's not being > > maintained in the tree is not terribly significant since it's already > > broken now. > > Why don't we let me sumbit patches, apply the things, and *then* > dike the code out, if that's your reasoning? We should. If no one else wants to do it, I'll be glad to. I can raise my kernel commit percentage a whole order of magnitude! (up to 0.0001%) > > > On the other hand, there's no compelling reason to dike it out, > > > > There is at least one, namely that it will make kernel code updates easier > > to do, and easier to test. > > And here people were telling me I was wrong for cynically assuming > that the reason people diked out so much code in the past year was > because they wanted to perform kernel code updates, without having > to maintain all the code they would be touching with those updates... I think that's definitely part of the motivation, I just think you're wrong to be cynical about it. :) There is no reason not to cut broken, unused code when it will always be available in CVS if someone comes along to make it useful again. > > > if it can be made to work. I would argue that ISA support is > > > more or less just as obsolete, as is 486 support, as is the F00F > > > bug workaround, as is ... a lot of code that's still there. > > > > Your argument here is non sequitur because we still have large bases of > > users and developers that have and use this hardware. I retired a box with > > an original P90 f00f bug cpu not that long ago, for example. netns has > > neither freebsd users or developers, and hasn't for years. > > And I have two XNS terminalservers, and there are people on this > list with Apollo equipment. Your point was again? My point is that we do not, and can not have any user base for the code as it exists, and we could not have for years because it doesn't work. The fact that there may be N users of netns in the universe doesn't affect the brokeness of our code as it has existed in recent history. Doug -- This .signature sanitized for your protection To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 1:57:21 2003 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 B44E637B401 for ; Wed, 5 Mar 2003 01:57:20 -0800 (PST) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 492AB43FB1 for ; Wed, 5 Mar 2003 01:57:20 -0800 (PST) (envelope-from DougB@freebsd.org) Received: from master.gorean.org (12-234-22-23.client.attbi.com[12.234.22.23]) by rwcrmhc52.attbi.com (rwcrmhc52) with SMTP id <2003030509571905200pqulee>; Wed, 5 Mar 2003 09:57:19 +0000 Date: Wed, 5 Mar 2003 01:57:19 -0800 (PST) From: Doug Barton To: CHOI Junho Cc: bmilekic@unixdaemons.com, net@freebsd.org Subject: Re: Performance tuning hints of gigabit networking? In-Reply-To: <20030304.115258.21844180.cjh@kr.FreeBSD.org> Message-ID: <20030305015704.D18288@znfgre.tberna.bet> References: <20030226.220551.10329540.cjh@kr.FreeBSD.org> <20030303180014.A7317@unixdaemons.com> <20030304.115258.21844180.cjh@kr.FreeBSD.org> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! 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, 4 Mar 2003, CHOI Junho wrote: > > That's 2GB machine. How much RAM I need more? The statistics clearly show that you do. -- This .signature sanitized for your protection To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 2: 9:53 2003 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 A2E0937B401; Wed, 5 Mar 2003 02:09:51 -0800 (PST) Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id B441E43FA3; Wed, 5 Mar 2003 02:09:50 -0800 (PST) (envelope-from mark@grondar.org) Received: from storm.FreeBSD.org.uk (Ugrondar@localhost [127.0.0.1]) by storm.FreeBSD.org.uk (8.12.7/8.12.7) with ESMTP id h25A9ndE009248; Wed, 5 Mar 2003 10:09:49 GMT (envelope-from mark@grondar.org) Received: (from Ugrondar@localhost) by storm.FreeBSD.org.uk (8.12.7/8.12.7/Submit) with UUCP id h25A9nii009247; Wed, 5 Mar 2003 10:09:49 GMT X-Authentication-Warning: storm.FreeBSD.org.uk: Ugrondar set sender to mark@grondar.org using -f Received: from grondar.org (localhost [127.0.0.1]) by grimreaper.grondar.org (8.12.7/8.12.7) with ESMTP id h25A8PIg042840; Wed, 5 Mar 2003 10:08:25 GMT (envelope-from mark@grondar.org) From: Mark Murray Message-Id: <200303051008.h25A8PIg042840@grimreaper.grondar.org> To: Terry Lambert Cc: Peter Wemm , Mike Barcroft , Tim Robbins , freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns - politically correct version In-Reply-To: Your message of "Tue, 04 Mar 2003 15:41:41 PST." <3E6539B5.2F5D31B@mindspring.com> Date: Wed, 05 Mar 2003 10:08:25 +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 Terry Lambert writes: > Peter Wemm wrote: > > Terry Lambert wrote: > > > Is there a compelling reason for removing this working code to > > > the Attic? > > > > Terry: will you please check your facts? It takes around 30 seconds > > to find out that it doesn't even compile. > > [ ... lots of trivial to fix warnings and errors ... ] > > > Tell you what, I'll fix these and post a patch. Will that make you > guys happy? > > This crap is *soooooooo* trivial to fix, it's easier to fix than > to watch you guys bitch about it not being fixable. Will it be runnable (as in tested), rather than a compile-only fix? M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 2:13:31 2003 Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id BF93237B401; Wed, 5 Mar 2003 02:13:29 -0800 (PST) Date: Wed, 5 Mar 2003 04:13:29 -0600 From: Juli Mallett To: Mark Murray Cc: Terry Lambert , Peter Wemm , Mike Barcroft , Tim Robbins , freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns - politically correct version Message-ID: <20030305041329.A29330@FreeBSD.org> References: <3E6539B5.2F5D31B@mindspring.com> <200303051008.h25A8PIg042840@grimreaper.grondar.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: <200303051008.h25A8PIg042840@grimreaper.grondar.org>; from mark@grondar.org on Wed, Mar 05, 2003 at 10:08:25AM +0000 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , , X-Towel: Yes X-Negacore: Yes X-Title: Code Maven 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: Mark Murray [ Data: 2003-03-05 ] [ Subjecte: Re: Removal of netns - politically correct version ] > Terry Lambert writes: > > Peter Wemm wrote: > > > Terry Lambert wrote: > > > > Is there a compelling reason for removing this working code to > > > > the Attic? > > > > > > Terry: will you please check your facts? It takes around 30 seconds > > > to find out that it doesn't even compile. > > > > [ ... lots of trivial to fix warnings and errors ... ] > > > > > > Tell you what, I'll fix these and post a patch. Will that make you > > guys happy? > > > > This crap is *soooooooo* trivial to fix, it's easier to fix than > > to watch you guys bitch about it not being fixable. > > Will it be runnable (as in tested), rather than a compile-only fix? compile-only would be a good state to leave the code in the attic. -- juli mallett. email: jmallett@freebsd.org; aim: bsdflata; efnet: juli; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 2:21:36 2003 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 7F3A437B405; Wed, 5 Mar 2003 02:21:35 -0800 (PST) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id A304843F85; Wed, 5 Mar 2003 02:21:33 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from PHE (silver.he.iki.fi [193.64.42.241]) by silver.he.iki.fi (8.12.8/8.11.4) with SMTP id h25ALUlL017362; Wed, 5 Mar 2003 12:21:31 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <006f01c2e300$fdfc49f0$932a40c1@PHE> From: "Petri Helenius" To: "Randy Bush" , "Terry Lambert" Cc: , References: <3E6539B5.2F5D31B@mindspring.com><4.3.2.7.2.20030305084442.037e9fa0@gid.co.uk><3E65BB24.3E37D90D@mindspring.com><20030305030708.A21014@FreeBSD.org><3E65C34D.19E2D95C@mindspring.com> Subject: Re: Removal of netns - politically correct version Date: Wed, 5 Mar 2003 12:21:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 yet to see a cisco ios image supporting ipv6 that was usable > in production environment. and i have tried hard. This is getting OT but on the subject of repelling users, they´re probably trying hard to repel their users to the vendor J boxen. > > but i will admit to not having seen apollo networking for over a > decade. but i probably have not been looking very widely. I´ve made a sighting in 1996 if I remember correctly. For their sake, I hope that´s gone now. > > seems to me that one useful question is whether the netns code > being there non-trivially complicates maintenance and/or > reliability of other code, and can i compile or module it out if > the bits it occupies really bothers me? > This is probably the right question. Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 2:24:46 2003 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 135E737B401; Wed, 5 Mar 2003 02:24:45 -0800 (PST) Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2046343FA3; Wed, 5 Mar 2003 02:24:44 -0800 (PST) (envelope-from mark@grondar.org) Received: from storm.FreeBSD.org.uk (Ugrondar@localhost [127.0.0.1]) by storm.FreeBSD.org.uk (8.12.7/8.12.7) with ESMTP id h25AOhdE009389; Wed, 5 Mar 2003 10:24:43 GMT (envelope-from mark@grondar.org) Received: (from Ugrondar@localhost) by storm.FreeBSD.org.uk (8.12.7/8.12.7/Submit) with UUCP id h25AOg28009388; Wed, 5 Mar 2003 10:24:42 GMT X-Authentication-Warning: storm.FreeBSD.org.uk: Ugrondar set sender to mark@grondar.org using -f Received: from grondar.org (localhost [127.0.0.1]) by grimreaper.grondar.org (8.12.7/8.12.7) with ESMTP id h25AOrIg043058; Wed, 5 Mar 2003 10:24:53 GMT (envelope-from mark@grondar.org) From: Mark Murray Message-Id: <200303051024.h25AOrIg043058@grimreaper.grondar.org> To: Juli Mallett Cc: Terry Lambert , Peter Wemm , Mike Barcroft , Tim Robbins , freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns - politically correct version In-Reply-To: Your message of "Wed, 05 Mar 2003 04:13:29 CST." <20030305041329.A29330@FreeBSD.org> Date: Wed, 05 Mar 2003 10:24:53 +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 Juli Mallett writes: > > > This crap is *soooooooo* trivial to fix, it's easier to fix than > > > to watch you guys bitch about it not being fixable. > > > > Will it be runnable (as in tested), rather than a compile-only fix? > > compile-only would be a good state to leave the code in the attic. Only if it kills this _really_ dumb debate. In time, it will no longer compile, and then the situation will be the same as just punting to the Attic without the "fix". M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 2:39:36 2003 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 944F037B401; Wed, 5 Mar 2003 02:39:35 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id D843343F3F; Wed, 5 Mar 2003 02:39:34 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from dialup-209.245.138.78.dial1.sanjose1.level3.net ([209.245.138.78] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18qWJA-0004n7-00; Wed, 05 Mar 2003 02:39:32 -0800 Message-ID: <3E65D1E7.9C744476@mindspring.com> Date: Wed, 05 Mar 2003 02:31:03 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Murray Cc: Peter Wemm , Mike Barcroft , Tim Robbins , freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns - politically correct version References: <200303051008.h25A8PIg042840@grimreaper.grondar.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a44d2fdc9a6c7bf6f26b60fce9e3b351c4a7ce0e8f8d31aa3f350badd9bab72f9c350badd9bab72f9c 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 Mark Murray wrote: > Terry Lambert writes: > > Peter Wemm wrote: > > > Terry: will you please check your facts? It takes around 30 seconds > > > to find out that it doesn't even compile. > > > > [ ... lots of trivial to fix warnings and errors ... ] > > > > Tell you what, I'll fix these and post a patch. Will that make you > > guys happy? > > Will it be runnable (as in tested), rather than a compile-only fix? Is "tested" a requirement fo code to be committed or to have it stay in the tree? Be careful of your answer, unless you are willing to remove all code that does not meet that criteria... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 3:19:36 2003 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 2E6C137B401 for ; Wed, 5 Mar 2003 03:19:34 -0800 (PST) Received: from hotmail.com (f88.law15.hotmail.com [64.4.23.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFA1E43F75 for ; Wed, 5 Mar 2003 03:19:31 -0800 (PST) (envelope-from soheil_hh@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 5 Mar 2003 03:19:27 -0800 Received: from 194.225.40.59 by lw15fd.law15.hotmail.msn.com with HTTP; Wed, 05 Mar 2003 11:19:27 GMT X-Originating-IP: [194.225.40.59] From: "soheil soheil" To: darcy@wavefire.com, freebsd-net@freebsd.org Subject: Re: Transparent Proxy Date: Wed, 05 Mar 2003 11:19:27 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 05 Mar 2003 11:19:27.0706 (UTC) FILETIME=[15A3C3A0:01C2E309] 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 think if you add the following rule to the ipfw rules on 192.168.0.1 ( the squid-running host ) you can have your proxy working. skipto 510 tcp from 192.168.0.1 to any dst-port 80 >From: Darcy Buskermolen >To: freebsd-net@freebsd.org >Subject: Transparent Proxy >Date: Tue, 25 Feb 2003 16:42:09 -0800 > > >(Promoted to -net due to lack of responces on -questions) > > >I'm trying to deploy a transparent proxy server for a friend's office but >have >run into a couple of snags that I can't seam to find the correct answer >for. >Please see http://home2.dbitech.bc.ca:8080/netconfig.txt for graphical >topology > >Note that I'm running IPFW2 on both BSD boxes. > >ipfw list output on 192.168.0.254: > >00001 skipto 50000 tcp from any 1023-65535 to me dst-port 22 >00040 skipto 50 tcp from 192.168.0.1 to any dst-port 80 >00048 fwd 192.168.0.1 tcp from 192.168.0.0/24 to any dst-port 80 out >00999 divert 8669 ip from any to any via ed0 >65533 allow ip from any to any >65535 deny ip from any to any > >ipfw list output on 192.168.0.1: > >00500 fwd 127.0.0.1,3128 ip from 192.168.0.0/16 to any dst-port 80 in >65000 allow ip from any to any >65535 deny ip from any to any > >When the windows box (192.168.0.32) makes a web request it gets forwarded >to >the squid machine fine, and squid returns a "access denied" error message, >checking the cache.log on squid I see the reason is as follows: > >2003/02/20 04:19:47| WARNING: Forwarding loop detected for: >GET / HTTP/1.0 > >All the information I can find online regaring setting up transparent >proxying >for squid using ipfw shows squid running on the gateway host, or on a >diffrent network segment. Can anybody point me in the correct direction to >tell me what it is that I'm missing? > >-- >Darcy Buskermolen >Wavefire Technologies Corp. >ph: 250.717.0200 >fx: 250.763.1759 >http://www.wavefire.com > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-net" in the body of the message _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 3:20:19 2003 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 9835B37B401; Wed, 5 Mar 2003 03:20:18 -0800 (PST) Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id B044943F75; Wed, 5 Mar 2003 03:20:17 -0800 (PST) (envelope-from mark@grondar.org) Received: from storm.FreeBSD.org.uk (Ugrondar@localhost [127.0.0.1]) by storm.FreeBSD.org.uk (8.12.7/8.12.7) with ESMTP id h25BKGdE010115; Wed, 5 Mar 2003 11:20:16 GMT (envelope-from mark@grondar.org) Received: (from Ugrondar@localhost) by storm.FreeBSD.org.uk (8.12.7/8.12.7/Submit) with UUCP id h25BKGrb010114; Wed, 5 Mar 2003 11:20:16 GMT X-Authentication-Warning: storm.FreeBSD.org.uk: Ugrondar set sender to mark@grondar.org using -f Received: from grondar.org (localhost [127.0.0.1]) by grimreaper.grondar.org (8.12.7/8.12.7) with ESMTP id h25BIHIg043714; Wed, 5 Mar 2003 11:18:17 GMT (envelope-from mark@grondar.org) From: Mark Murray Message-Id: <200303051118.h25BIHIg043714@grimreaper.grondar.org> To: Terry Lambert Cc: freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns - politically correct version In-Reply-To: Your message of "Wed, 05 Mar 2003 02:31:03 PST." <3E65D1E7.9C744476@mindspring.com> Date: Wed, 05 Mar 2003 11:18:17 +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 Terry Lambert writes: > Mark Murray wrote: > > Will it be runnable (as in tested), rather than a compile-only fix? > > Is "tested" a requirement fo code to be committed or to have it > stay in the tree? Both. > Be careful of your answer, unless you are willing to remove all > code that does not meet that criteria... Be careful of your interpretation of my answer. State _all_ your premises, and be careful not to use any undeclared ones. Do not hold me to any premise that I have not agreed to. All broken code needs to be fixed XOR removed. All fixes need to be tested. All code in the tree needs to be tested often to ensure that it is not broken. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 4:20:20 2003 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 23EEA37B401; Wed, 5 Mar 2003 04:19:27 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0939843FBF; Wed, 5 Mar 2003 04:19:25 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from dialup-209.245.138.78.dial1.sanjose1.level3.net ([209.245.138.78] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18qXrG-0004Dk-00; Wed, 05 Mar 2003 04:18:51 -0800 Message-ID: <3E65E7A5.DBD9097A@mindspring.com> Date: Wed, 05 Mar 2003 04:03:49 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: Mike Barcroft , Tim Robbins , freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: [PATCH 5.x] netns References: <20030305013509.AD7662A8BB@canning.wemm.org> Content-Type: multipart/mixed; boundary="------------683C78166CD831774FABBA7C" X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4d7bdc6a7051604583ef0aeb5b0711289a7ce0e8f8d31aa3f350badd9bab72f9c350badd9bab72f9c 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. --------------683C78166CD831774FABBA7C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Peter Wemm wrote: > Terry Lambert wrote: > > Here are two patches. The first fixes missing pieces in /sys/conf/files > > and /sys/conf/options, the second fixes all the files that need it in > > /sys/netns/. > > You seem to have posted the wrong patch. > > This is against 4.x, not -current, and this is current@freebsd.org. Here is a single patch vs. 5.x. I believe this makes it actually work. I have addressed all the protosw issues in this patch. Please apply this to the code, even if you are intent on putting working code in the Attic. Thanks, -- Terry --------------683C78166CD831774FABBA7C Content-Type: text/plain; charset=us-ascii; name="netns5.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netns5.diff" Index: conf/files =================================================================== RCS file: /cvs/src/sys/conf/files,v retrieving revision 1.765 diff -c -r1.765 files *** conf/files 4 Mar 2003 23:19:55 -0000 1.765 --- conf/files 5 Mar 2003 06:03:11 -0000 *************** *** 1429,1434 **** --- 1429,1435 ---- netns/ns_output.c optional ns netns/ns_pcb.c optional ns netns/ns_proto.c optional ns + netns/ns_cksum.c optional ns netns/spp_debug.c optional ns netns/spp_usrreq.c optional ns netsmb/smb_conn.c optional netsmb Index: netns/idp_usrreq.c =================================================================== RCS file: /cvs/src/sys/netns/idp_usrreq.c,v retrieving revision 1.15 diff -c -r1.15 idp_usrreq.c *** netns/idp_usrreq.c 19 Feb 2003 05:47:37 -0000 1.15 --- netns/idp_usrreq.c 5 Mar 2003 08:04:20 -0000 *************** *** 54,59 **** --- 54,63 ---- #include #include + extern int idpcksum; /* from ns_input.c */ + extern long ns_pexseq; /* from ns_input.c */ + extern struct nspcb nsrawpcb; /* from ns_input.c */ + /* * IDP protocol implementation. */ *************** *** 63,72 **** /* * This may also be called for raw listeners. */ ! idp_input(m, nsp) struct mbuf *m; ! register struct nspcb *nsp; { register struct idp *idp = mtod(m, struct idp *); struct ifnet *ifp = m->m_pkthdr.rcvif; --- 67,78 ---- /* * This may also be called for raw listeners. */ ! void ! idp_input(m, nsp0) struct mbuf *m; ! int nsp0; /* XXX offset */ { + register struct nspcb *nsp = ns_pcblookupm(m); register struct idp *idp = mtod(m, struct idp *); struct ifnet *ifp = m->m_pkthdr.rcvif; *************** *** 79,92 **** idp_ns.sns_addr = idp->idp_sna; if (ns_neteqnn(idp->idp_sna.x_net, ns_zeronet) && ifp) { register struct ifaddr *ifa; ! for (ifa = ifp->if_addrlist; ifa; ifa = ifa->ifa_next) { if (ifa->ifa_addr->sa_family == AF_NS) { idp_ns.sns_addr.x_net = IA_SNS(ifa)->sns_addr.x_net; break; } ! } } nsp->nsp_rpt = idp->idp_pt; if ( ! (nsp->nsp_flags & NSP_RAWIN) ) { --- 85,100 ---- idp_ns.sns_addr = idp->idp_sna; if (ns_neteqnn(idp->idp_sna.x_net, ns_zeronet) && ifp) { register struct ifaddr *ifa; + int s; ! s = splimp(); ! TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) if (ifa->ifa_addr->sa_family == AF_NS) { idp_ns.sns_addr.x_net = IA_SNS(ifa)->sns_addr.x_net; break; } ! splx(s); } nsp->nsp_rpt = idp->idp_pt; if ( ! (nsp->nsp_flags & NSP_RAWIN) ) { *************** *** 103,108 **** --- 111,117 ---- m_freem(m); } + void idp_abort(nsp) struct nspcb *nsp; { *************** *** 134,153 **** so->so_error = errno; ns_pcbdisconnect(nsp); soisdisconnected(so); } int noIdpRoute; ! idp_output(nsp, m0) ! struct nspcb *nsp; struct mbuf *m0; { ! register struct mbuf *m; register struct idp *idp; - register struct socket *so; register int len; register struct route *ro; ! struct mbuf *mprev; ! extern int idpcksum; len = m_length(m0, &mprev); /* --- 143,164 ---- so->so_error = errno; ns_pcbdisconnect(nsp); soisdisconnected(so); + return(NULL); /* XXX */ } int noIdpRoute; ! ! int ! idp_output(m0, so) struct mbuf *m0; + struct socket *so; { ! struct nspcb *nsp = sotonspcb(so); ! struct mbuf *m; register struct idp *idp; register int len; register struct route *ro; ! struct mbuf *mprev = NULL; len = m_length(m0, &mprev); /* *************** *** 204,210 **** /* * Output datagram. */ - so = nsp->nsp_socket; if (so->so_options & SO_DONTROUTE) return (ns_output(m, (struct route *)0, (so->so_options & SO_BROADCAST) | NS_ROUTETOIF)); --- 215,220 ---- *************** *** 253,274 **** if (noIdpRoute) ro = 0; return (ns_output(m, ro, so->so_options & SO_BROADCAST)); } /* ARGSUSED */ ! idp_ctloutput(req, so, level, name, value) ! int req, level; struct socket *so; ! int name; ! struct mbuf **value; { register struct mbuf *m; struct nspcb *nsp = sotonspcb(so); int mask, error = 0; - extern long ns_pexseq; if (nsp == NULL) return (EINVAL); ! switch (req) { case PRCO_GETOPT: if (value==NULL) --- 263,284 ---- if (noIdpRoute) ro = 0; return (ns_output(m, ro, so->so_options & SO_BROADCAST)); } + /* ARGSUSED */ ! int ! idp_ctloutput( so, sopt) struct socket *so; ! struct sockopt *sopt; { register struct mbuf *m; + struct mbuf **value = sopt->sopt_val; /* XXX dangerous */ struct nspcb *nsp = sotonspcb(so); int mask, error = 0; if (nsp == NULL) return (EINVAL); ! switch (sopt->sopt_dir) { case PRCO_GETOPT: if (value==NULL) *************** *** 276,282 **** m = m_get(M_DONTWAIT, MT_DATA); if (m==NULL) return (ENOBUFS); ! switch (name) { case SO_ALL_PACKETS: mask = NSP_ALL_PACKETS; --- 286,292 ---- m = m_get(M_DONTWAIT, MT_DATA); if (m==NULL) return (ENOBUFS); ! switch (sopt->sopt_name) { case SO_ALL_PACKETS: mask = NSP_ALL_PACKETS; *************** *** 318,324 **** break; case PRCO_SETOPT: ! switch (name) { int *ok; case SO_ALL_PACKETS: --- 328,334 ---- break; case PRCO_SETOPT: ! switch (sopt->sopt_name) { int *ok; case SO_ALL_PACKETS: *************** *** 365,374 **** } /*ARGSUSED*/ ! idp_usrreq(so, req, m, nam, control) struct socket *so; int req; struct mbuf *m, *nam, *control; { struct nspcb *nsp = sotonspcb(so); int error = 0; --- 375,386 ---- } /*ARGSUSED*/ ! int ! idp_usrreq(so, req, m, nam, control, td) struct socket *so; int req; struct mbuf *m, *nam, *control; + struct thread *td; { struct nspcb *nsp = sotonspcb(so); int error = 0; *************** *** 449,455 **** case PRU_SEND: { struct ns_addr laddr; ! int s; if (nam) { laddr = nsp->nsp_laddr; --- 461,467 ---- case PRU_SEND: { struct ns_addr laddr; ! int s = -1; /* XXX compiler warns improperly */ if (nam) { laddr = nsp->nsp_laddr; *************** *** 472,478 **** break; } } ! error = idp_output(nsp, m); m = NULL; if (nam) { ns_pcbdisconnect(nsp); --- 484,490 ---- break; } } ! error = idp_output(m, so); m = NULL; if (nam) { ns_pcbdisconnect(nsp); *************** *** 526,549 **** m_freem(m); return (error); } /*ARGSUSED*/ ! idp_raw_usrreq(so, req, m, nam, control) struct socket *so; int req; struct mbuf *m, *nam, *control; { int error = 0; struct nspcb *nsp = sotonspcb(so); - extern struct nspcb nsrawpcb; switch (req) { case PRU_ATTACH: if (!(so->so_state & SS_PRIV) || (nsp != NULL)) { error = EINVAL; break; } error = ns_pcballoc(so, &nsrawpcb); if (error) break; --- 538,566 ---- m_freem(m); return (error); } + /*ARGSUSED*/ ! int ! idp_raw_usrreq(so, req, m, nam, control, td) struct socket *so; int req; struct mbuf *m, *nam, *control; + struct thread *td; { int error = 0; struct nspcb *nsp = sotonspcb(so); switch (req) { case PRU_ATTACH: + #ifdef NS_PRIV_SOCKETS if (!(so->so_state & SS_PRIV) || (nsp != NULL)) { error = EINVAL; break; } + #endif /* NS_PRIV_SOCKETS */ + error = ns_pcballoc(so, &nsrawpcb); if (error) break; *************** *** 555,561 **** nsp->nsp_flags = NSP_RAWIN | NSP_RAWOUT; break; default: ! error = idp_usrreq(so, req, m, nam, control); } return (error); } --- 572,578 ---- nsp->nsp_flags = NSP_RAWIN | NSP_RAWOUT; break; default: ! error = idp_usrreq(so, req, m, nam, control, td); } return (error); } Index: netns/idp_var.h =================================================================== RCS file: /cvs/src/sys/netns/idp_var.h,v retrieving revision 1.10 diff -c -r1.10 idp_var.h *** netns/idp_var.h 29 Dec 1999 04:46:18 -0000 1.10 --- netns/idp_var.h 5 Mar 2003 07:51:33 -0000 *************** *** 50,55 **** --- 50,67 ---- #ifdef _KERNEL struct idpstat idpstat; + struct nspcb; /* declare in scope for ptr parameter */ + struct thread; /* XXX not used */ + + void idp_abort __P((struct nspcb *)); + void idp_input __P((struct mbuf *, int)); + struct nspcb *idp_drop __P((struct nspcb *, int)); + int idp_output __P(( struct mbuf *, struct socket *)); + int idp_ctloutput __P((struct socket *, struct sockopt *)); + int idp_usrreq __P(( struct socket *, int, struct mbuf *, struct mbuf *, + struct mbuf *, struct thread *)); + int idp_raw_usrreq __P(( struct socket *, int, struct mbuf *, struct mbuf *, + struct mbuf *, struct thread *)); #endif #endif Index: netns/ns.c =================================================================== RCS file: /cvs/src/sys/netns/ns.c,v retrieving revision 1.13 diff -c -r1.13 ns.c *** netns/ns.c 19 Feb 2003 05:47:37 -0000 1.13 --- netns/ns.c 5 Mar 2003 06:32:52 -0000 *************** *** 36,43 **** #include #include #include ! #include #include #include #include --- 36,44 ---- #include #include + #include #include ! #include #include #include #include *************** *** 49,54 **** --- 50,57 ---- #include #include + #include "opt_ns.h" + #ifdef NS struct ns_ifaddr *ns_ifaddr; *************** *** 59,64 **** --- 62,68 ---- * Generic internet control operations (ioctl's). */ /* ARGSUSED */ + int ns_control(so, cmd, data, ifp) struct socket *so; int cmd; *************** *** 68,76 **** register struct ifreq *ifr = (struct ifreq *)data; register struct ns_aliasreq *ifra = (struct ns_aliasreq *)data; register struct ns_ifaddr *ia; ! struct ifaddr *ifa; struct ns_ifaddr *oia; ! int error, dstIsNew, hostIsNew; /* * Find address for this interface, if it exists. --- 72,81 ---- register struct ifreq *ifr = (struct ifreq *)data; register struct ns_aliasreq *ifra = (struct ns_aliasreq *)data; register struct ns_ifaddr *ia; ! struct ifaddr *ifa = NULL; /* XXX used uninitialized ?*/ struct ns_ifaddr *oia; ! int dstIsNew, hostIsNew; ! int error = 0; /* initialize because of scoping */ /* * Find address for this interface, if it exists. *************** *** 107,114 **** --- 112,121 ---- return (0); } + #ifdef NS_PRIV_SOCKETS if ((so->so_state & SS_PRIV) == 0) return (EPERM); + #endif /* NS_PRIV_SOCKETS */ switch (cmd) { case SIOCAIFADDR: *************** *** 132,150 **** if (oia == (struct ns_ifaddr *)NULL) return (ENOBUFS); bzero((caddr_t)oia, sizeof(*oia)); ! if (ia = ns_ifaddr) { for ( ; ia->ia_next; ia = ia->ia_next) ; ia->ia_next = oia; } else ns_ifaddr = oia; ia = oia; ! if (ifa = ifp->if_addrlist) { ! for ( ; ifa->ifa_next; ifa = ifa->ifa_next) ! ; ! ifa->ifa_next = (struct ifaddr *) ia; ! } else ! ifp->if_addrlist = (struct ifaddr *) ia; ia->ia_ifp = ifp; ia->ia_ifa.ifa_addr = (struct sockaddr *)&ia->ia_addr; --- 139,153 ---- if (oia == (struct ns_ifaddr *)NULL) return (ENOBUFS); bzero((caddr_t)oia, sizeof(*oia)); ! if ((ia = ns_ifaddr) != NULL) { for ( ; ia->ia_next; ia = ia->ia_next) ; ia->ia_next = oia; } else ns_ifaddr = oia; ia = oia; ! ! TAILQ_INSERT_TAIL(&ifp->if_addrhead, ifa, ifa_link); ia->ia_ifp = ifp; ia->ia_ifa.ifa_addr = (struct sockaddr *)&ia->ia_addr; *************** *** 163,170 **** } switch (cmd) { - int error; - case SIOCSIFDSTADDR: if ((ifp->if_flags & IFF_POINTOPOINT) == 0) return (EINVAL); --- 166,171 ---- *************** *** 173,179 **** ia->ia_flags &= ~IFA_ROUTE; } if (ifp->if_ioctl) { ! error = (*ifp->if_ioctl)(ifp, SIOCSIFDSTADDR, ia); if (error) return (error); } --- 174,181 ---- ia->ia_flags &= ~IFA_ROUTE; } if (ifp->if_ioctl) { ! error = (*ifp->if_ioctl)(ifp, SIOCSIFDSTADDR, ! (caddr_t)ia); if (error) return (error); } *************** *** 181,203 **** return (0); case SIOCSIFADDR: ! return (ns_ifinit(ifp, ia, (struct sockaddr_ns *)&ifr->ifr_addr, 1)); case SIOCDIFADDR: ! ns_ifscrub(ifp, ia); ! if ((ifa = ifp->if_addrlist) == (struct ifaddr *)ia) ! ifp->if_addrlist = ifa->ifa_next; ! else { ! while (ifa->ifa_next && ! (ifa->ifa_next != (struct ifaddr *)ia)) ! ifa = ifa->ifa_next; ! if (ifa->ifa_next) ! ifa->ifa_next = ((struct ifaddr *)ia)->ifa_next; ! else ! printf("Couldn't unlink nsifaddr from ifp\n"); ! } oia = ia; if (oia == (ia = ns_ifaddr)) { ns_ifaddr = ia->ia_next; } else { --- 183,196 ---- return (0); case SIOCSIFADDR: ! return (ns_ifinit(ifp, (struct ns_ifaddr *)ia, (struct sockaddr_ns *)&ifr->ifr_addr, 1)); case SIOCDIFADDR: ! ns_ifscrub(ifp, (struct ns_ifaddr *)ia); ! /* XXX not on list? */ oia = ia; + TAILQ_REMOVE(&ifp->if_addrhead, (struct ifaddr *)ia, ifa_link); if (oia == (ia = ns_ifaddr)) { ns_ifaddr = ia->ia_next; } else { *************** *** 231,243 **** if ((ifp->if_flags & IFF_POINTOPOINT) && (ifra->ifra_dstaddr.sns_family == AF_NS)) { if (hostIsNew == 0) ! ns_ifscrub(ifp, ia); ia->ia_dstaddr = ifra->ifra_dstaddr; dstIsNew = 1; } if (ifra->ifra_addr.sns_family == AF_NS && (hostIsNew || dstIsNew)) ! error = ns_ifinit(ifp, ia, &ifra->ifra_addr, 0); return (error); default: --- 224,237 ---- if ((ifp->if_flags & IFF_POINTOPOINT) && (ifra->ifra_dstaddr.sns_family == AF_NS)) { if (hostIsNew == 0) ! ns_ifscrub(ifp, (struct ns_ifaddr *)ia); ia->ia_dstaddr = ifra->ifra_dstaddr; dstIsNew = 1; } if (ifra->ifra_addr.sns_family == AF_NS && (hostIsNew || dstIsNew)) ! error = ns_ifinit(ifp, (struct ns_ifaddr *)ia, ! &ifra->ifra_addr, 0); return (error); default: *************** *** 250,255 **** --- 244,250 ---- /* * Delete any previous route for an old address. */ + void ns_ifscrub(ifp, ia) register struct ifnet *ifp; register struct ns_ifaddr *ia; *************** *** 266,275 **** --- 261,272 ---- * Initialize an interface's internet address * and routing table entry. */ + int ns_ifinit(ifp, ia, sns, scrub) register struct ifnet *ifp; register struct ns_ifaddr *ia; register struct sockaddr_ns *sns; + int scrub; { struct sockaddr_ns oldaddr; register union ns_host *h = &ia->ia_addr.sns_addr.x_host; *************** *** 294,300 **** */ if (ns_hosteqnh(ns_thishost, ns_zerohost)) { if (ifp->if_ioctl && ! (error = (*ifp->if_ioctl)(ifp, SIOCSIFADDR, ia))) { ia->ia_addr = oldaddr; splx(s); return (error); --- 291,298 ---- */ if (ns_hosteqnh(ns_thishost, ns_zerohost)) { if (ifp->if_ioctl && ! (error = (*ifp->if_ioctl)(ifp, SIOCSIFADDR, ! (caddr_t)ia))) { ia->ia_addr = oldaddr; splx(s); return (error); *************** *** 304,310 **** || ns_hosteqnh(sns->sns_addr.x_host, ns_thishost)) { *h = ns_thishost; if (ifp->if_ioctl && ! (error = (*ifp->if_ioctl)(ifp, SIOCSIFADDR, ia))) { ia->ia_addr = oldaddr; splx(s); return (error); --- 302,309 ---- || ns_hosteqnh(sns->sns_addr.x_host, ns_thishost)) { *h = ns_thishost; if (ifp->if_ioctl && ! (error = (*ifp->if_ioctl)(ifp, SIOCSIFADDR, ! (caddr_t)ia))) { ia->ia_addr = oldaddr; splx(s); return (error); *************** *** 352,358 **** union ns_net net = dst->x_net; for (ia = ns_ifaddr; ia; ia = ia->ia_next) { ! if (ifp = ia->ia_ifp) { if (ifp->if_flags & IFF_POINTOPOINT) { compare = &satons_addr(ia->ia_dstaddr); if (ns_hosteq(*dst, *compare)) --- 351,357 ---- union ns_net net = dst->x_net; for (ia = ns_ifaddr; ia; ia = ia->ia_next) { ! if ((ifp = ia->ia_ifp) != NULL) { if (ifp->if_flags & IFF_POINTOPOINT) { compare = &satons_addr(ia->ia_dstaddr); if (ns_hosteq(*dst, *compare)) Index: netns/ns.h =================================================================== RCS file: /cvs/src/sys/netns/ns.h,v retrieving revision 1.16 diff -c -r1.16 ns.h *** netns/ns.h 6 Sep 2002 16:58:13 -0000 1.16 --- netns/ns.h 5 Mar 2003 07:03:40 -0000 *************** *** 139,145 **** extern union ns_host ns_broadhost; extern union ns_net ns_zeronet; extern union ns_net ns_broadnet; ! u_short ns_cksum(void); #else #include --- 139,160 ---- extern union ns_host ns_broadhost; extern union ns_net ns_zeronet; extern union ns_net ns_broadnet; ! ! struct route; ! struct ns_ifaddr; ! ! u_short ns_cksum __P(( struct mbuf *, int)); ! int ns_output __P((struct mbuf *, struct route *, int)); ! int ns_control __P((struct socket *, int, caddr_t, struct ifnet *)); ! void ns_init __P((void)); ! void idp_forward __P((struct mbuf *)); ! void idp_ctlinput __P((int, struct sockaddr *, void *)); ! int idp_do_route __P((struct ns_addr *, struct route *)); ! void idp_undo_route __P((struct route *)); ! void ns_watch_output __P((struct mbuf *, struct ifnet *)); ! int ns_ifinit __P((struct ifnet *, struct ns_ifaddr *, struct sockaddr_ns *, ! int)); ! void ns_ifscrub __P((struct ifnet *, struct ns_ifaddr *)); #else #include Index: netns/ns_cksum.c =================================================================== RCS file: /cvs/src/sys/netns/ns_cksum.c,v retrieving revision 1.7 diff -c -r1.7 ns_cksum.c *** netns/ns_cksum.c 28 Aug 1999 00:49:49 -0000 1.7 --- netns/ns_cksum.c 5 Mar 2003 08:08:55 -0000 *************** *** 37,42 **** --- 37,47 ---- #include #include + #include + #include + #include + #include /* prototype in scope */ + /* * Checksum routine for Network Systems Protocol Packets (Big-Endian). * Index: netns/ns_error.c =================================================================== RCS file: /cvs/src/sys/netns/ns_error.c,v retrieving revision 1.11 diff -c -r1.11 ns_error.c *** netns/ns_error.c 19 Feb 2003 05:47:37 -0000 1.11 --- netns/ns_error.c 5 Mar 2003 07:09:51 -0000 *************** *** 50,55 **** --- 50,60 ---- #include #include + extern int idpcksum; /* from ns_input.c */ + /* from spp_usrreq.c XXX */ + extern void spp_ctlinput( int, struct sockaddr *, void *); + + #ifdef lint #define NS_ERRPRINTFS 1 #endif *************** *** 62,68 **** --- 67,75 ---- int ns_errprintfs = 0; #endif + int ns_err_x(c) + int c; { register u_short *w, *lim, *base = ns_errstat.ns_es_codes; u_short x = c; *************** *** 86,101 **** * Generate an error packet of type error * in response to bad packet. */ ! ns_error(om, type, param) struct mbuf *om; int type; { register struct ns_epidp *ep; struct mbuf *m; struct idp *nip; register struct idp *oip = mtod(om, struct idp *); - extern int idpcksum; /* * If this packet was sent to the echo port, --- 93,108 ---- * Generate an error packet of type error * in response to bad packet. */ ! void ns_error(om, type, param) struct mbuf *om; int type; + int param; { register struct ns_epidp *ep; struct mbuf *m; struct idp *nip; register struct idp *oip = mtod(om, struct idp *); /* * If this packet was sent to the echo port, *************** *** 165,170 **** --- 172,178 ---- m_freem(om); } + void ns_printhost(p) register struct ns_addr *p; { *************** *** 182,192 **** --- 190,203 ---- /* * Process a received NS_ERR message. */ + void ns_err_input(m) struct mbuf *m; { register struct ns_errp *ep; + #ifdef NS_ERRPRINTFS register struct ns_epidp *epidp = mtod(m, struct ns_epidp *); + #endif register int i; int type, code, param; *************** *** 263,273 **** #endif switch(ep->ns_err_idp.idp_pt) { case NSPROTO_SPP: ! spp_ctlinput(code, (caddr_t)ep); break; default: ! idp_ctlinput(code, (caddr_t)ep); } goto freeit; --- 274,284 ---- #endif switch(ep->ns_err_idp.idp_pt) { case NSPROTO_SPP: ! spp_ctlinput(code, NULL, ep); break; default: ! idp_ctlinput(code, NULL, ep); } goto freeit; *************** *** 295,300 **** --- 306,312 ---- } #endif + int ns_echo(m) struct mbuf *m; { Index: netns/ns_error.h =================================================================== RCS file: /cvs/src/sys/netns/ns_error.h,v retrieving revision 1.10 diff -c -r1.10 ns_error.h *** netns/ns_error.h 29 Dec 1999 04:46:19 -0000 1.10 --- netns/ns_error.h 5 Mar 2003 06:03:54 -0000 *************** *** 91,96 **** --- 91,102 ---- #ifdef _KERNEL struct ns_errstat ns_errstat; + + int ns_err_x __P((int)); + void ns_error __P((struct mbuf *, int, int)); + int ns_echo __P((struct mbuf *)); + void ns_printhost __P((struct ns_addr *)); + void ns_err_input __P((struct mbuf *)); #endif #endif Index: netns/ns_if.h =================================================================== RCS file: /cvs/src/sys/netns/ns_if.h,v retrieving revision 1.16 diff -c -r1.16 ns_if.h *** netns/ns_if.h 4 Mar 2003 23:19:53 -0000 1.16 --- netns/ns_if.h 5 Mar 2003 06:44:13 -0000 *************** *** 80,88 **** #endif #ifdef _KERNEL ! extern struct ns_ifaddr *ns_ifaddr; ! struct ns_ifaddr *ns_iaonnetof(void); ! void nsintr(struct mbuf *); #endif #endif --- 80,91 ---- #endif #ifdef _KERNEL ! extern struct ns_ifaddr *ns_ifaddr; ! ! struct ns_ifaddr *ns_iaonnetof __P((struct ns_addr *)); ! void nsintr __P((struct mbuf *)); ! ! extern struct ifqueue nsintrq; /* XNS input packet queue */ #endif #endif Index: netns/ns_input.c =================================================================== RCS file: /cvs/src/sys/netns/ns_input.c,v retrieving revision 1.19 diff -c -r1.19 ns_input.c *** netns/ns_input.c 4 Mar 2003 23:19:53 -0000 1.19 --- netns/ns_input.c 5 Mar 2003 08:00:43 -0000 *************** *** 58,77 **** #include #include /* * NS initialization. */ - union ns_host ns_thishost; - union ns_host ns_zerohost; - union ns_host ns_broadhost; - union ns_net ns_zeronet; - union ns_net ns_broadnet; struct sockaddr_ns ns_netmask, ns_hostmask; static u_short allones[] = {-1, -1, -1}; static struct ifqueue nsintrq; - struct nspcb nspcb; struct nspcb nsrawpcb; int nsqmaxlen = IFQ_MAXLEN; --- 58,73 ---- #include #include + extern void spp_input(struct mbuf *, struct nspcb *); /* spp_usrreq.c XXX */ + /* * NS initialization. */ struct sockaddr_ns ns_netmask, ns_hostmask; static u_short allones[] = {-1, -1, -1}; static struct ifqueue nsintrq; struct nspcb nsrawpcb; int nsqmaxlen = IFQ_MAXLEN; *************** *** 79,93 **** int idpcksum = 1; long ns_pexseq; ns_init() { - extern struct timeval time; - ns_broadhost = * (union ns_host *) allones; ns_broadnet = * (union ns_net *) allones; nspcb.nsp_next = nspcb.nsp_prev = &nspcb; nsrawpcb.nsp_next = nsrawpcb.nsp_prev = &nsrawpcb; ! ns_pexseq = time.tv_usec; ns_netmask.sns_len = 6; ns_netmask.sns_addr.x_net = ns_broadnet; ns_hostmask.sns_len = 12; --- 75,88 ---- int idpcksum = 1; long ns_pexseq; + void ns_init() { ns_broadhost = * (union ns_host *) allones; ns_broadnet = * (union ns_net *) allones; nspcb.nsp_next = nspcb.nsp_prev = &nspcb; nsrawpcb.nsp_next = nsrawpcb.nsp_prev = &nsrawpcb; ! ns_pexseq = tick; ns_netmask.sns_len = 6; ns_netmask.sns_addr.x_net = ns_broadnet; ns_hostmask.sns_len = 12; *************** *** 109,115 **** register struct idp *idp; register struct nspcb *nsp; register int i; ! int len, s, error; char oddpacketp; /* --- 104,110 ---- register struct idp *idp; register struct nspcb *nsp; register int i; ! int len, error; char oddpacketp; /* *************** *** 128,139 **** */ for (nsp = nsrawpcb.nsp_next; nsp != &nsrawpcb; nsp = nsp->nsp_next) { struct mbuf *m1 = m_copy(m, 0, (int)M_COPYALL); ! if (m1) idp_input(m1, nsp); } idp = mtod(m, struct idp *); len = ntohs(idp->idp_len); ! if (oddpacketp = len & 1) { len++; /* If this packet is of odd length, preserve garbage byte for checksum */ } --- 123,134 ---- */ for (nsp = nsrawpcb.nsp_next; nsp != &nsrawpcb; nsp = nsp->nsp_next) { struct mbuf *m1 = m_copy(m, 0, (int)M_COPYALL); ! if (m1) idp_input(m1, (int)nsp); } idp = mtod(m, struct idp *); len = ntohs(idp->idp_len); ! if ((oddpacketp = (len & 1))) { len++; /* If this packet is of odd length, preserve garbage byte for checksum */ } *************** *** 221,227 **** ns_err_input(m); return; } ! idp_input(m, nsp); } else { ns_error(m, NS_ERR_NOSOCK, 0); } --- 216,222 ---- ns_err_input(m); return; } ! idp_input(m, (int)nsp); } else { ns_error(m, NS_ERR_NOSOCK, 0); } *************** *** 242,256 **** int idp_donosocks = 1; ! idp_ctlinput(cmd, arg) int cmd; ! caddr_t arg; { struct ns_addr *ns; struct nspcb *nsp; ! struct ns_errp *errp; ! int idp_abort(); ! extern struct nspcb *idp_drop(); int type; if (cmd < 0 || cmd > PRC_NCMDS) --- 237,252 ---- int idp_donosocks = 1; ! /* ARGSUSED */ ! void ! idp_ctlinput(cmd, sa, arg) int cmd; ! struct sockaddr *sa; ! void *arg; { struct ns_addr *ns; struct nspcb *nsp; ! struct ns_errp *errp = (struct ns_errp *)arg; /* XXX */ int type; if (cmd < 0 || cmd > PRC_NCMDS) *************** *** 301,306 **** --- 297,303 ---- struct route idp_droute; struct route idp_sroute; + void idp_forward(m) struct mbuf *m; { *************** *** 420,425 **** --- 417,423 ---- m_freem(mcopy); } + int idp_do_route(src, ro) struct ns_addr *src; struct route *ro; *************** *** 442,453 **** --- 440,453 ---- return (1); } + void idp_undo_route(ro) register struct route *ro; { if (ro->ro_rt) {RTFREE(ro->ro_rt);} } + void ns_watch_output(m, ifp) struct mbuf *m; struct ifnet *ifp; *************** *** 469,483 **** idp->idp_sna.x_net = ns_zeronet; idp->idp_sna.x_host = ns_thishost; if (ifp && (ifp->if_flags & IFF_POINTOPOINT)) ! for(ifa = ifp->if_addrlist; ifa; ! ifa = ifa->ifa_next) { if (ifa->ifa_addr->sa_family==AF_NS) { idp->idp_sna = IA_SNS(ifa)->sns_addr; break; } - } idp->idp_len = ntohl(m0->m_pkthdr.len); ! idp_input(m0, nsp); } } } --- 469,481 ---- idp->idp_sna.x_net = ns_zeronet; idp->idp_sna.x_host = ns_thishost; if (ifp && (ifp->if_flags & IFF_POINTOPOINT)) ! TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) if (ifa->ifa_addr->sa_family==AF_NS) { idp->idp_sna = IA_SNS(ifa)->sns_addr; break; } idp->idp_len = ntohl(m0->m_pkthdr.len); ! idp_input(m0, (int)nsp); } } } Index: netns/ns_output.c =================================================================== RCS file: /cvs/src/sys/netns/ns_output.c,v retrieving revision 1.8 diff -c -r1.8 ns_output.c *** netns/ns_output.c 3 Nov 2001 13:35:07 -0000 1.8 --- netns/ns_output.c 5 Mar 2003 06:45:54 -0000 *************** *** 35,40 **** --- 35,41 ---- */ #include + #include #include #include #include *************** *** 54,59 **** --- 55,61 ---- int ns_output_cnt = 0; struct mbuf *ns_lastout; + int ns_output(m0, ro, flags) struct mbuf *m0; struct route *ro; *************** *** 64,70 **** int error = 0; struct route idproute; struct sockaddr_ns *dst; - extern int idpcksum; if (ns_hold_output) { if (ns_lastout) { --- 66,71 ---- Index: netns/ns_pcb.c =================================================================== RCS file: /cvs/src/sys/netns/ns_pcb.c,v retrieving revision 1.14 diff -c -r1.14 ns_pcb.c *** netns/ns_pcb.c 19 Feb 2003 05:47:37 -0000 1.14 --- netns/ns_pcb.c 5 Mar 2003 08:06:16 -0000 *************** *** 51,56 **** --- 51,57 ---- struct ns_addr zerons_addr; + int ns_pcballoc(so, head) struct socket *so; struct nspcb *head; *************** *** 58,64 **** struct mbuf *m; register struct nspcb *nsp; ! m = m_getclr(M_DONTWAIT, MT_PCB); if (m == NULL) return (ENOBUFS); nsp = mtod(m, struct nspcb *); --- 59,65 ---- struct mbuf *m; register struct nspcb *nsp; ! m = m_getclr(M_DONTWAIT, MT_CONTROL); /* protocol private PCB */ if (m == NULL) return (ENOBUFS); nsp = mtod(m, struct nspcb *); *************** *** 68,73 **** --- 69,75 ---- return (0); } + int ns_pcbbind(nsp, nam) register struct nspcb *nsp; struct mbuf *nam; *************** *** 92,102 **** --- 94,107 ---- } lport = sns->sns_port; if (lport) { + #ifdef NS_PRIV_SOCKETS u_short aport = ntohs(lport); if (aport < NSPORT_RESERVED && (nsp->nsp_socket->so_state & SS_PRIV) == 0) return (EACCES); + #endif /* NS_PRIV_SOCKETS */ + if (ns_pcblookup(&zerons_addr, lport, 0)) return (EADDRINUSE); } *************** *** 118,123 **** --- 123,129 ---- * If don't have a local address for this socket yet, * then pick one. */ + int ns_pcbconnect(nsp, nam) struct nspcb *nsp; struct mbuf *nam; *************** *** 217,222 **** --- 223,229 ---- return (0); } + void ns_pcbdisconnect(nsp) struct nspcb *nsp; { *************** *** 226,231 **** --- 233,239 ---- ns_pcbdetach(nsp); } + void ns_pcbdetach(nsp) struct nspcb *nsp; { *************** *** 239,244 **** --- 247,253 ---- (void) m_free(dtom(nsp)); } + void ns_setsockaddr(nsp, nam) register struct nspcb *nsp; struct mbuf *nam; *************** *** 253,258 **** --- 262,268 ---- sns->sns_addr = nsp->nsp_laddr; } + void ns_setpeeraddr(nsp, nam) register struct nspcb *nsp; struct mbuf *nam; *************** *** 274,283 **** * Also pass an extra paramter via the nspcb. (which may in fact * be a parameter list!) */ ns_pcbnotify(dst, errno, notify, param) register struct ns_addr *dst; long param; ! int errno, (*notify)(); { register struct nspcb *nsp, *oinp; int s = splimp(); --- 284,295 ---- * Also pass an extra paramter via the nspcb. (which may in fact * be a parameter list!) */ + void ns_pcbnotify(dst, errno, notify, param) register struct ns_addr *dst; long param; ! void (*notify)(struct nspcb *); ! int errno; { register struct nspcb *nsp, *oinp; int s = splimp(); *************** *** 361,364 **** --- 373,401 ---- } } return (match); + } + + #include + #include + + /* + * Given an mbuf with a struct idp in it, return the npcb that matches + * + * XXX Dirty; sorry + */ + struct nspcb * + ns_pcblookupm(struct mbuf *m) + { + register struct idp *idp; + register struct nspcb *nsp; + + if ((m->m_flags & M_EXT || m->m_len < sizeof (struct idp)) && + (m = m_pullup(m, sizeof (struct idp))) == 0) { + idpstat.idps_toosmall++; + return( NULL); /* XXX */ + } + idp = mtod(m, struct idp *); + nsp = ns_pcblookup(&idp->idp_sna, idp->idp_dna.x_port, NS_WILDCARD); + + return(nsp); } Index: netns/ns_pcb.h =================================================================== RCS file: /cvs/src/sys/netns/ns_pcb.h,v retrieving revision 1.11 diff -c -r1.11 ns_pcb.h *** netns/ns_pcb.h 29 Dec 1999 04:46:20 -0000 1.11 --- netns/ns_pcb.h 5 Mar 2003 08:02:19 -0000 *************** *** 79,85 **** #ifdef _KERNEL struct nspcb nspcb; /* head of list */ ! struct nspcb *ns_pcblookup(); #endif #endif --- 79,94 ---- #ifdef _KERNEL struct nspcb nspcb; /* head of list */ ! struct nspcb *ns_pcblookupm __P((struct mbuf *m)); ! struct nspcb *ns_pcblookup __P((struct ns_addr *, u_short, int)); ! void ns_pcbdisconnect __P((struct nspcb *)); ! void ns_pcbdetach __P((struct nspcb *)); ! int ns_pcballoc __P((struct socket *, struct nspcb *)); ! int ns_pcbbind __P((struct nspcb *, struct mbuf *)); ! int ns_pcbconnect __P((struct nspcb *, struct mbuf *)); ! void ns_setsockaddr __P((struct nspcb *, struct mbuf *)); ! void ns_setpeeraddr __P((struct nspcb *, struct mbuf *)); ! void ns_pcbnotify __P(( struct ns_addr *, int, void(*)(struct nspcb *), long)); #endif #endif Index: netns/ns_proto.c =================================================================== RCS file: /cvs/src/sys/netns/ns_proto.c,v retrieving revision 1.10 diff -c -r1.10 ns_proto.c *** netns/ns_proto.c 28 Aug 1999 00:49:51 -0000 1.10 --- netns/ns_proto.c 5 Mar 2003 07:49:28 -0000 *************** *** 44,62 **** #include #include /* * NS protocol family: IDP, ERR, PE, SPP, ROUTE. */ - int ns_init(); - int idp_input(), idp_output(), idp_ctlinput(), idp_usrreq(); - int idp_raw_usrreq(), idp_ctloutput(); - int spp_input(), spp_ctlinput(); - int spp_usrreq(), spp_usrreq_sp(), spp_ctloutput(); - int spp_init(), spp_fasttimo(), spp_slowtimo(); - extern int raw_usrreq(); - extern struct domain nsdomain; struct protosw nssw[] = { { 0, &nsdomain, 0, 0, --- 44,70 ---- #include #include + #include + + /* XXX+ */ + void spp_input( struct mbuf *, int); + void spp_ctlinput( int, struct sockaddr *, void *); + int spp_ctloutput( struct socket *, struct sockopt *); + int spp_usrreq( struct socket *, int, struct mbuf *, struct mbuf *, + struct mbuf *, struct thread *); + int spp_usrreq_sp( struct socket *, int, struct mbuf *, struct mbuf *, + struct mbuf *, struct thread *); + void spp_init(void); + void spp_fasttimo(void); + void spp_slowtimo(void); + + /* XXX- */ + /* * NS protocol family: IDP, ERR, PE, SPP, ROUTE. */ struct protosw nssw[] = { { 0, &nsdomain, 0, 0, *************** *** 85,91 **** 0, 0, 0, 0, }, { SOCK_RAW, &nsdomain, NSPROTO_ERROR, PR_ATOMIC|PR_ADDR, ! idp_ctlinput, idp_output, 0, idp_ctloutput, idp_raw_usrreq, 0, 0, 0, 0, }, --- 93,99 ---- 0, 0, 0, 0, }, { SOCK_RAW, &nsdomain, NSPROTO_ERROR, PR_ATOMIC|PR_ADDR, ! /* XXX idp_ctlinput*/ 0, idp_output, 0, idp_ctloutput, idp_raw_usrreq, 0, 0, 0, 0, }, Index: netns/spp_debug.c =================================================================== RCS file: /cvs/src/sys/netns/spp_debug.c,v retrieving revision 1.10 diff -c -r1.10 spp_debug.c *** netns/spp_debug.c 28 Aug 1999 00:49:52 -0000 1.10 --- netns/spp_debug.c 5 Mar 2003 06:03:54 -0000 *************** *** 64,69 **** --- 64,70 ---- /* * spp debug routines */ + void spp_trace(act, ostate, sp, si, req) short act; u_char ostate; Index: netns/spp_debug.h =================================================================== RCS file: /cvs/src/sys/netns/spp_debug.h,v retrieving revision 1.9 diff -c -r1.9 spp_debug.h *** netns/spp_debug.h 28 Aug 1999 00:49:53 -0000 1.9 --- netns/spp_debug.h 5 Mar 2003 06:03:55 -0000 *************** *** 63,65 **** --- 63,70 ---- int spp_debx; #endif + + #ifdef _KERNEL + + void spp_trace __P(( short, u_char, struct sppcb *, struct spidp *, int)); + #endif Index: netns/spp_usrreq.c =================================================================== RCS file: /cvs/src/sys/netns/spp_usrreq.c,v retrieving revision 1.19 diff -c -r1.19 spp_usrreq.c *** netns/spp_usrreq.c 19 Feb 2003 05:47:38 -0000 1.19 --- netns/spp_usrreq.c 5 Mar 2003 08:12:56 -0000 *************** *** 58,66 **** --- 58,73 ---- #include #include + extern u_char nsctlerrmap[]; /* from ns_input.c */ + extern int idpcksum; /* from ns_input.c */ + + int spp_backoff[SPP_MAXRXTSHIFT+1] = + { 1, 2, 4, 8, 16, 32, 64, 64, 64, 64, 64, 64, 64 }; + /* * SP protocol implementation. */ + void spp_init() { *************** *** 74,87 **** u_short spp_newchecks[50]; /*ARGSUSED*/ ! spp_input(m, nsp) register struct mbuf *m; ! register struct nspcb *nsp; { register struct sppcb *cb; register struct spidp *si = mtod(m, struct spidp *); register struct socket *so; ! short ostate; int dropsocket = 0; --- 81,96 ---- u_short spp_newchecks[50]; /*ARGSUSED*/ ! void ! spp_input(m, nsp0) register struct mbuf *m; ! int nsp0; /* XXX offset */ { + register struct nspcb *nsp = ns_pcblookupm(m); register struct sppcb *cb; register struct spidp *si = mtod(m, struct spidp *); register struct socket *so; ! short ostate = 0; /* compiler erroneously flags */ int dropsocket = 0; *************** *** 287,292 **** --- 296,302 ---- * but its function is somewhat different: It merely queues * packets up, and suppresses duplicates. */ + int spp_reass(cb, si) register struct sppcb *cb; register struct spidp *si; *************** *** 415,423 **** update_window: if (SSEQ_LT(cb->s_snxt, cb->s_rack)) cb->s_snxt = cb->s_rack; ! if (SSEQ_LT(cb->s_swl1, si->si_seq) || cb->s_swl1 == si->si_seq && (SSEQ_LT(cb->s_swl2, si->si_ack) || ! cb->s_swl2 == si->si_ack && SSEQ_LT(cb->s_ralo, si->si_alo))) { /* keep track of pure window updates */ if ((si->si_cc & SP_SP) && cb->s_swl2 == si->si_ack && SSEQ_LT(cb->s_ralo, si->si_alo)) { --- 425,433 ---- update_window: if (SSEQ_LT(cb->s_snxt, cb->s_rack)) cb->s_snxt = cb->s_rack; ! if (SSEQ_LT(cb->s_swl1, si->si_seq) || (cb->s_swl1 == si->si_seq && (SSEQ_LT(cb->s_swl2, si->si_ack) || ! (cb->s_swl2 == si->si_ack && SSEQ_LT(cb->s_ralo, si->si_alo))))) { /* keep track of pure window updates */ if ((si->si_cc & SP_SP) && cb->s_swl2 == si->si_ack && SSEQ_LT(cb->s_ralo, si->si_alo)) { *************** *** 575,589 **** return (0); } ! spp_ctlinput(cmd, arg) int cmd; ! caddr_t arg; { struct ns_addr *na; ! extern u_char nsctlerrmap[]; ! extern spp_abort(), spp_quench(); ! extern struct nspcb *idp_drop(); ! struct ns_errp *errp; struct nspcb *nsp; struct sockaddr_ns *sns; int type; --- 585,599 ---- return (0); } ! /* ARGSUSED */ ! void ! spp_ctlinput(cmd, sa, arg) int cmd; ! struct sockaddr *sa; ! void *arg; { struct ns_addr *na; ! struct ns_errp *errp = 0; /* compiler erroneously flags */ struct nspcb *nsp; struct sockaddr_ns *sns; int type; *************** *** 639,644 **** --- 649,655 ---- * When a source quench is received, close congestion window * to one packet. We will gradually open it again as we proceed. */ + void spp_quench(nsp) struct nspcb *nsp; { *************** *** 696,701 **** --- 707,713 ---- } #endif + int spp_output(cb, m0) register struct sppcb *cb; struct mbuf *m0; *************** *** 712,718 **** int idle; #endif struct mbuf *mprev; - extern int idpcksum; if (m0) { int mtu = cb->s_mtu; --- 724,729 ---- *************** *** 1111,1121 **** int spp_do_persist_panics = 0; spp_setpersist(cb) register struct sppcb *cb; { ! register t = ((cb->s_srtt >> 2) + cb->s_rttvar) >> 1; ! extern int spp_backoff[]; if (cb->s_timer[SPPT_REXMT] && spp_do_persist_panics) panic("spp_output REXMT"); --- 1122,1132 ---- int spp_do_persist_panics = 0; + void spp_setpersist(cb) register struct sppcb *cb; { ! register int t = ((cb->s_srtt >> 2) + cb->s_rttvar) >> 1; if (cb->s_timer[SPPT_REXMT] && spp_do_persist_panics) panic("spp_output REXMT"); *************** *** 1129,1149 **** cb->s_rxtshift++; } /*ARGSUSED*/ ! spp_ctloutput(req, so, level, name, value) ! int req; struct socket *so; ! int name; ! struct mbuf **value; { register struct mbuf *m; struct nspcb *nsp = sotonspcb(so); register struct sppcb *cb; int mask, error = 0; ! if (level != NSPROTO_SPP) { /* This will have to be changed when we do more general stacking of protocols */ ! return (idp_ctloutput(req, so, level, name, value)); } if (nsp == NULL) { error = EINVAL; --- 1140,1160 ---- cb->s_rxtshift++; } /*ARGSUSED*/ ! int ! spp_ctloutput( so, sopt) struct socket *so; ! struct sockopt *sopt; { + struct mbuf **value = sopt->sopt_val; /* XXX dangerous */ register struct mbuf *m; struct nspcb *nsp = sotonspcb(so); register struct sppcb *cb; int mask, error = 0; ! if (sopt->sopt_level != NSPROTO_SPP) { /* This will have to be changed when we do more general stacking of protocols */ ! return (idp_ctloutput(so, sopt)); } if (nsp == NULL) { error = EINVAL; *************** *** 1151,1157 **** } else cb = nstosppcb(nsp); ! switch (req) { case PRCO_GETOPT: if (value == NULL) --- 1162,1168 ---- } else cb = nstosppcb(nsp); ! switch (sopt->sopt_dir) { case PRCO_GETOPT: if (value == NULL) *************** *** 1159,1165 **** m = m_get(M_DONTWAIT, MT_DATA); if (m == NULL) return (ENOBUFS); ! switch (name) { case SO_HEADERS_ON_INPUT: mask = SF_HI; --- 1170,1176 ---- m = m_get(M_DONTWAIT, MT_DATA); if (m == NULL) return (ENOBUFS); ! switch (sopt->sopt_name) { case SO_HEADERS_ON_INPUT: mask = SF_HI; *************** *** 1198,1204 **** error = EINVAL; break; } ! switch (name) { int *ok; case SO_HEADERS_ON_INPUT: --- 1209,1215 ---- error = EINVAL; break; } ! switch (sopt->sopt_name) { int *ok; case SO_HEADERS_ON_INPUT: *************** *** 1254,1266 **** } /*ARGSUSED*/ ! spp_usrreq(so, req, m, nam, controlp) struct socket *so; int req; struct mbuf *m, *nam, *controlp; { struct nspcb *nsp = sotonspcb(so); ! register struct sppcb *cb; int s = splnet(); int error = 0, ostate; struct mbuf *mm; --- 1265,1279 ---- } /*ARGSUSED*/ ! int ! spp_usrreq(so, req, m, nam, controlp, td) struct socket *so; int req; struct mbuf *m, *nam, *controlp; + struct thread *td; { struct nspcb *nsp = sotonspcb(so); ! register struct sppcb *cb = NULL; int s = splnet(); int error = 0, ostate; struct mbuf *mm; *************** *** 1296,1302 **** } nsp = sotonspcb(so); ! mm = m_getclr(M_DONTWAIT, MT_PCB); sb = &so->so_snd; if (mm == NULL) { --- 1309,1316 ---- } nsp = sotonspcb(so); ! /* private PCB */ ! mm = m_getclr(M_DONTWAIT, MT_CONTROL); sb = &so->so_snd; if (mm == NULL) { *************** *** 1506,1517 **** return (error); } ! spp_usrreq_sp(so, req, m, nam, controlp) struct socket *so; int req; struct mbuf *m, *nam, *controlp; { ! int error = spp_usrreq(so, req, m, nam, controlp); if (req == PRU_ATTACH && error == 0) { struct nspcb *nsp = sotonspcb(so); --- 1520,1533 ---- return (error); } ! int ! spp_usrreq_sp(so, req, m, nam, controlp, td) struct socket *so; int req; struct mbuf *m, *nam, *controlp; + struct thread *td; { ! int error = spp_usrreq(so, req, m, nam, controlp, td); if (req == PRU_ATTACH && error == 0) { struct nspcb *nsp = sotonspcb(so); *************** *** 1527,1532 **** --- 1543,1549 ---- * in a skeletal spp header (choosing connection id), * minimizing the amount of work necessary when the connection is used. */ + void spp_template(cb) register struct sppcb *cb; { *************** *** 1621,1626 **** --- 1638,1644 ---- return (spp_close(cb)); } + void spp_abort(nsp) struct nspcb *nsp; { *************** *** 1628,1638 **** (void) spp_close((struct sppcb *)nsp->nsp_pcb); } - int spp_backoff[SPP_MAXRXTSHIFT+1] = - { 1, 2, 4, 8, 16, 32, 64, 64, 64, 64, 64, 64, 64 }; /* * Fast timeout routine for processing delayed acks */ spp_fasttimo() { register struct nspcb *nsp; --- 1646,1655 ---- (void) spp_close((struct sppcb *)nsp->nsp_pcb); } /* * Fast timeout routine for processing delayed acks */ + void spp_fasttimo() { register struct nspcb *nsp; *************** *** 1657,1662 **** --- 1674,1680 ---- * Updates the timers in all active pcb's and * causes finite state machine actions if timers expire. */ + void spp_slowtimo() { register struct nspcb *ip, *ipnxt; *************** *** 1682,1688 **** (void) spp_usrreq(cb->s_nspcb->nsp_socket, PRU_SLOWTIMO, (struct mbuf *)0, (struct mbuf *)i, (struct mbuf *)0, ! (struct mbuf *)0); if (ipnxt->nsp_prev != ip) goto tpgone; } --- 1700,1706 ---- (void) spp_usrreq(cb->s_nspcb->nsp_socket, PRU_SLOWTIMO, (struct mbuf *)0, (struct mbuf *)i, (struct mbuf *)0, ! (struct thread *)0); if (ipnxt->nsp_prev != ip) goto tpgone; } Index: netns/spp_var.h =================================================================== RCS file: /cvs/src/sys/netns/spp_var.h,v retrieving revision 1.11 diff -c -r1.11 spp_var.h *** netns/spp_var.h 29 Dec 1999 04:46:21 -0000 1.11 --- netns/spp_var.h 5 Mar 2003 08:10:06 -0000 *************** *** 194,202 **** #define sppstat spp_istat.newstats #endif u_short spp_iss; ! extern struct sppcb *spp_close(), *spp_disconnect(), ! *spp_usrclosed(), *spp_timers(), *spp_drop(); #endif #define SPP_ISSINCR 128 --- 194,226 ---- #define sppstat spp_istat.newstats #endif + struct thread; /* not used */ + u_short spp_iss; ! ! void spp_init __P((void)); ! void spp_input __P((struct mbuf *, int)); ! void spp_ctlinput __P((int, struct sockaddr *, void *)); ! int spp_ctloutput __P((struct socket *, struct sockopt *)); ! int spp_usrreq __P((struct socket *, int, struct mbuf *, struct mbuf *, ! struct mbuf *, struct thread *)); ! int spp_usrreq_sp __P((struct socket *, int, struct mbuf *, struct mbuf *, ! struct mbuf *, struct thread *)); ! void spp_fasttimo __P((void)); ! void spp_slowtimo __P((void)); ! void spp_template __P((struct sppcb *)); ! int spp_reass __P((struct sppcb *, struct spidp *)); ! int spp_output __P((struct sppcb *, struct mbuf *)); ! void spp_quench __P((struct nspcb *)); ! void spp_abort __P((struct nspcb *)); ! void spp_setpersist __P((struct sppcb *)); ! ! struct sppcb *spp_close __P((struct sppcb *)); ! struct sppcb *spp_disconnect __P((struct sppcb *)); ! struct sppcb *spp_usrclosed __P((struct sppcb *)); ! struct sppcb *spp_timers __P((struct sppcb *, int)); ! struct sppcb *spp_drop __P((struct sppcb *, int)); ! #endif #define SPP_ISSINCR 128 --------------683C78166CD831774FABBA7C-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 4:25:56 2003 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 DF21637B401; Wed, 5 Mar 2003 04:25:54 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FA9043F75; Wed, 5 Mar 2003 04:25:54 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from dialup-209.245.138.78.dial1.sanjose1.level3.net ([209.245.138.78] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18qXxv-000590-00; Wed, 05 Mar 2003 04:25:46 -0800 Message-ID: <3E65E938.E4BA9956@mindspring.com> Date: Wed, 05 Mar 2003 04:10:32 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Petri Helenius Cc: Randy Bush , freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns - politically correct version References: <3E6539B5.2F5D31B@mindspring.com><4.3.2.7.2.20030305084442.037e9fa0@gid.co.uk><3E65BB24.3E37D90D@mindspring.com><20030305030708.A21014@FreeBSD.org><3E65C34D.19E2D95C@mindspring.com> <006f01c2e300$fdfc49f0$932a40c1@PHE> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a45525140f334d66a7f73a64e2ac762a47548b785378294e88350badd9bab72f9c350badd9bab72f9c 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 Petri Helenius wrote: > > seems to me that one useful question is whether the netns code > > being there non-trivially complicates maintenance and/or > > reliability of other code, and can i compile or module it out if > > the bits it occupies really bothers me? > > > This is probably the right question. As people keep pointing out, the code has been disabled since 1996, so it doesn't complicate maintenance, because maintenance hasn't been being done, even though it's trivially easy. What pisses me off about this is that people have been breaking API's out from under code, in such a way that no one who is not highly domain knowledgable can unbreak the code that they did not maintain. An API is a contract between pieces of code. If you break that contract, then you are responsible for fixing every piece of code that uses the contract. If people actually did this (they *don't*), THEN leaving the code in would complicate maintenance. Please apply the patches I have posted to the list for netns. Thanks, -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 4:28:47 2003 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 1286337B401; Wed, 5 Mar 2003 04:28:45 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 766D843FBD; Wed, 5 Mar 2003 04:28:44 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from dialup-209.245.138.78.dial1.sanjose1.level3.net ([209.245.138.78] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18qY0o-0005Pj-00; Wed, 05 Mar 2003 04:28:43 -0800 Message-ID: <3E65E9E2.94F85833@mindspring.com> Date: Wed, 05 Mar 2003 04:13:22 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Murray Cc: Juli Mallett , Peter Wemm , Mike Barcroft , Tim Robbins , freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns - politically correct version References: <200303051024.h25AOrIg043058@grimreaper.grondar.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a45525140f334d66a7ca7154398def1250a8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c 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 Mark Murray wrote: > Only if it kills this _really_ dumb debate. In time, it will no longer > compile, and then the situation will be the same as just punting to the > Attic without the "fix". Only if some idiot breaks the API contract again. Whatever happened to "you broke it, you fix it"? Hopefully, the next time it happens, and something gets punted to the Attic, it will be code *you* care about, instead of code I care about. Then it will be *your* problem, and I can sit back and make smarmy postings. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 4:48:41 2003 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 D54AA37B401; Wed, 5 Mar 2003 04:48:39 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5268343FA3; Wed, 5 Mar 2003 04:48:39 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from dialup-209.245.138.78.dial1.sanjose1.level3.net ([209.245.138.78] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18qYK3-0007Z1-00; Wed, 05 Mar 2003 04:48:37 -0800 Message-ID: <3E65EE57.BBD230B4@mindspring.com> Date: Wed, 05 Mar 2003 04:32:23 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Murray Cc: freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns - politically correct version References: <200303051118.h25BIHIg043714@grimreaper.grondar.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4d3422fd38a98687d5c9b769ca125679e548b785378294e88350badd9bab72f9c350badd9bab72f9c 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 Mark Murray wrote: > Terry Lambert writes: > > Mark Murray wrote: > > > Will it be runnable (as in tested), rather than a compile-only fix? > > > > Is "tested" a requirement fo code to be committed or to have it > > stay in the tree? > > Both. Cool. Then I have a long list of things that can be fixed or removed. This whole thing about netns started 3 days ago. How many days after code is questioned does someone have to fix it before it is it OK to dike it out? > > Be careful of your answer, unless you are willing to remove all > > code that does not meet that criteria... > > Be careful of your interpretation of my answer. State _all_ your > premises, and be careful not to use any undeclared ones. Do not hold > me to any premise that I have not agreed to. > > All broken code needs to be fixed XOR removed. All fixes need to be > tested. All code in the tree needs to be tested often to ensure that > it is not broken. Let' start wth the libalias/natd incremental checksum update code; the code is based on RFC1141, instead of RFC1624. As a result, it get updated incorrectly occasionally, because it's using two's complement instead of one's complement math. Per RFC1642: RFC 1141 yields an updated header checksum of -0 when it should be +0. This is because it assumed that one's complement has a distributive property, which does not hold when the result is 0 (see derivation of [Eqn. 2]). People see this as hands on FTP installs, etc., going through FreeBSD based NAT's. It's very obvious ad easy to repeat: 1) Put a printf in tcp_input.c that compalins when the checksum is incorect. 2) Do a CVSup from that machine through a FreeBSD NAT How long can this remain unfixed before the code is diked out, and the checksum is recalculated fully, instead? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 5:42:51 2003 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 0A30337B401; Wed, 5 Mar 2003 05:42:50 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46E1343FAF; Wed, 5 Mar 2003 05:42:49 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h25DgmA7028534; Wed, 5 Mar 2003 06:42:48 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 05 Mar 2003 06:40:00 -0700 (MST) Message-Id: <20030305.064000.31317673.imp@bsdimp.com> To: freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns - politically correct version From: "M. Warner Losh" In-Reply-To: <20030305030708.A21014@FreeBSD.org> References: <4.3.2.7.2.20030305084442.037e9fa0@gid.co.uk> <3E65BB24.3E37D90D@mindspring.com> <20030305030708.A21014@FreeBSD.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 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 De: Terry Lambert [ Data: 2003-03-05 ] [ Subjecte: Re: Removal of netns - politically correct version ] > On the other hand, there's no compelling reason to dike it out, > if it can be made to work. I would argue that ISA support is > more or less just as obsolete, as is 486 support, as is the F00F > bug workaround, as is ... a lot of code that's still there. ISA support is not obsolete. All new PCs still have ISA busses. They might not have ISA Expansion Bus Slots, but they all[*] still connect their serial ports, parallel ports, and mouse/keyboard ports via ISA. Warner [*] well, except for the legacy free ones, which aren't many. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 6:10:53 2003 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 89FF837B401; Wed, 5 Mar 2003 06:10:52 -0800 (PST) Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CCC343FBD; Wed, 5 Mar 2003 06:10:51 -0800 (PST) (envelope-from mark@grondar.org) Received: from storm.FreeBSD.org.uk (Ugrondar@localhost [127.0.0.1]) by storm.FreeBSD.org.uk (8.12.7/8.12.7) with ESMTP id h25EAmdE012451; Wed, 5 Mar 2003 14:10:48 GMT (envelope-from mark@grondar.org) Received: (from Ugrondar@localhost) by storm.FreeBSD.org.uk (8.12.7/8.12.7/Submit) with UUCP id h25EAmeh012450; Wed, 5 Mar 2003 14:10:48 GMT X-Authentication-Warning: storm.FreeBSD.org.uk: Ugrondar set sender to mark@grondar.org using -f Received: from grondar.org (localhost [127.0.0.1]) by grimreaper.grondar.org (8.12.7/8.12.7) with ESMTP id h25E99Ig046536; Wed, 5 Mar 2003 14:09:09 GMT (envelope-from mark@grondar.org) From: Mark Murray Message-Id: <200303051409.h25E99Ig046536@grimreaper.grondar.org> To: Terry Lambert Cc: freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns - politically correct version In-Reply-To: Your message of "Wed, 05 Mar 2003 04:13:22 PST." <3E65E9E2.94F85833@mindspring.com> Date: Wed, 05 Mar 2003 14:09:09 +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 Terry Lambert writes: > Mark Murray wrote: > > Only if it kills this _really_ dumb debate. In time, it will no longer > > compile, and then the situation will be the same as just punting to the > > Attic without the "fix". > > Only if some idiot breaks the API contract again. > > Whatever happened to "you broke it, you fix it"? > > Hopefully, the next time it happens, and something gets punted > to the Attic, it will be code *you* care about, instead of code I > care about. Then it will be *your* problem, and I can sit back > and make smarmy postings. Guess what? This has already happened. I'm working on a fix. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 6:16:42 2003 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 E566537B401 for ; Wed, 5 Mar 2003 06:16:40 -0800 (PST) Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id A192E43FAF for ; Wed, 5 Mar 2003 06:16:39 -0800 (PST) (envelope-from jwb@homer.att.com) Received: from ulysses.homer.att.com ([135.205.193.8]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h25EGcFl021340 for ; Wed, 5 Mar 2003 08:16:38 -0600 (CST) Received: from akiva.homer.att.com (akiva.homer.att.com [135.205.212.39]) by ulysses.homer.att.com (8.9.3/8.9.3) with ESMTP id JAA17826 for ; Wed, 5 Mar 2003 09:16:37 -0500 (EST) Received: from akiva.homer.att.com (localhost [127.0.0.1]) by akiva.homer.att.com (8.11.6+Sun/8.9.3) with ESMTP id h25EGaF04635 for ; Wed, 5 Mar 2003 09:16:36 -0500 (EST) Message-Id: <200303051416.h25EGaF04635@akiva.homer.att.com> X-Mailer: exmh version 2.6.1 02/18/2003 with nmh-1.0.4 To: freebsd-net@FreeBSD.ORG Subject: route pointing to a gateway that's not on net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Mar 2003 09:16:36 -0500 From: "J. W. Ballantine" 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 was recently following a thread on tech-netbsd that was discussing the routing tables when the gateway address was on a 10.x.x.x network while the machine was assigned a 209.122.66.x address. The long and short of the discussion (as I understand the discussion) was that this was that while it can be accessed via windose and Linux ( > > On Linux, we could do this to get around that minor problem: > > route add -host 192.168.14.88 dev eth0 ) that is was an evil, ugy illegal network route and that it not possible, will not be implemented in NetBSD. Now since my cable ISP has me provised it this manner, and since I can't find a method to get out from FreeBSD using the route command. I was wondering if a) I missed something and there is some option for the route command that allows to route to be setup, or if not will netgraph allow me to setup this route? Thanks Jim Ballantine To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 6:30: 4 2003 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 771F037B401; Wed, 5 Mar 2003 06:30:03 -0800 (PST) Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CEA543FAF; Wed, 5 Mar 2003 06:30:02 -0800 (PST) (envelope-from mark@grondar.org) Received: from storm.FreeBSD.org.uk (Ugrondar@localhost [127.0.0.1]) by storm.FreeBSD.org.uk (8.12.7/8.12.7) with ESMTP id h25EU1dE012845; Wed, 5 Mar 2003 14:30:01 GMT (envelope-from mark@grondar.org) Received: (from Ugrondar@localhost) by storm.FreeBSD.org.uk (8.12.7/8.12.7/Submit) with UUCP id h25EU1Uq012844; Wed, 5 Mar 2003 14:30:01 GMT X-Authentication-Warning: storm.FreeBSD.org.uk: Ugrondar set sender to mark@grondar.org using -f Received: from grondar.org (localhost [127.0.0.1]) by grimreaper.grondar.org (8.12.7/8.12.7) with ESMTP id h25ETsIg047004; Wed, 5 Mar 2003 14:29:54 GMT (envelope-from mark@grondar.org) From: Mark Murray Message-Id: <200303051429.h25ETsIg047004@grimreaper.grondar.org> To: Terry Lambert Cc: freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns - politically correct version In-Reply-To: Your message of "Wed, 05 Mar 2003 04:32:23 PST." <3E65EE57.BBD230B4@mindspring.com> Date: Wed, 05 Mar 2003 14:29:54 +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 Terry Lambert writes: > Let' start wth the libalias/natd incremental checksum update code; > the code is based on RFC1141, instead of RFC1624. As a result, > it get updated incorrectly occasionally, because it's using two's > complement instead of one's complement math. Per RFC1642: > > RFC 1141 yields an updated header checksum of -0 when it should be > +0. This is because it assumed that one's complement has a > distributive property, which does not hold when the result is 0 (see > derivation of [Eqn. 2]). > > People see this as hands on FTP installs, etc., going through > FreeBSD based NAT's. > > It's very obvious ad easy to repeat: > > 1) Put a printf in tcp_input.c that compalins when the > checksum is incorect. > > 2) Do a CVSup from that machine through a FreeBSD NAT > > > How long can this remain unfixed before the code is diked out, > and the checksum is recalculated fully, instead? Terry, you sound rather foolish when you argue like this. This is semantic tomfoolery and off topic. End of thread. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 8:32:16 2003 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 E3F9137B401 for ; Wed, 5 Mar 2003 08:32:13 -0800 (PST) Received: from mail2.dbitech.ca (radius.wavefire.com [64.141.13.252]) by mx1.FreeBSD.org (Postfix) with SMTP id CE2FC43F3F for ; Wed, 5 Mar 2003 08:32:11 -0800 (PST) (envelope-from darcy@wavefire.com) Received: (qmail 11399 invoked from network); 5 Mar 2003 16:53:19 -0000 Received: from dbitech.wavefire.com (HELO dbitech) (darcy@64.141.15.253) by radius.wavefire.com with SMTP; 5 Mar 2003 16:53:19 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Darcy Buskermolen Organization: Wavefire Technologies Corp. To: "soheil soheil" , freebsd-net@freebsd.org Subject: Re: Transparent Proxy Date: Wed, 5 Mar 2003 08:32:08 -0800 User-Agent: KMail/1.4.3 References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200303050832.08348.darcy@wavefire.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 I thank everybody who took the time to reply to me, and I found the probl= em,=20 my fwd/skipto rules needed to be after the divert rules. On Wednesday 05 March 2003 03:19, soheil soheil wrote: > I think if you add the following rule to the ipfw rules on 192.168.0.1 = ( > the squid-running host ) you can have your proxy working. > > skipto 510 tcp from 192.168.0.1 to any dst-port 80 > > > > From: Darcy Buskermolen > > >To: freebsd-net@freebsd.org > >Subject: Transparent Proxy > >Date: Tue, 25 Feb 2003 16:42:09 -0800 > > > > > >(Promoted to -net due to lack of responces on -questions) > > > > > >I'm trying to deploy a transparent proxy server for a friend's office = but > >have > >run into a couple of snags that I can't seam to find the correct answe= r > >for. > >Please see http://home2.dbitech.bc.ca:8080/netconfig.txt for graphical > >topology > > > >Note that I'm running IPFW2 on both BSD boxes. > > > >ipfw list output on 192.168.0.254: > > > >00001 skipto 50000 tcp from any 1023-65535 to me dst-port 22 > >00040 skipto 50 tcp from 192.168.0.1 to any dst-port 80 > >00048 fwd 192.168.0.1 tcp from 192.168.0.0/24 to any dst-port 80 out > >00999 divert 8669 ip from any to any via ed0 > >65533 allow ip from any to any > >65535 deny ip from any to any > > > >ipfw list output on 192.168.0.1: > > > >00500 fwd 127.0.0.1,3128 ip from 192.168.0.0/16 to any dst-port 80 in > >65000 allow ip from any to any > >65535 deny ip from any to any > > > >When the windows box (192.168.0.32) makes a web request it gets forwar= ded > >to > >the squid machine fine, and squid returns a "access denied" error mess= age, > >checking the cache.log on squid I see the reason is as follows: > > > >2003/02/20 04:19:47| WARNING: Forwarding loop detected for: > >GET / HTTP/1.0 > > > >All the information I can find online regaring setting up transparent > >proxying > >for squid using ipfw shows squid running on the gateway host, or on a > >diffrent network segment. Can anybody point me in the correct directi= on > > to tell me what it is that I'm missing? > > > >-- > >Darcy Buskermolen > >Wavefire Technologies Corp. > >ph: 250.717.0200 > >fx: 250.763.1759 > >http://www.wavefire.com > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-net" in the body of the message > > _________________________________________________________________ > STOP MORE SPAM with the new MSN 8 and get 2 months FREE* > http://join.msn.com/?page=3Dfeatures/junkmail --=20 Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 9:58: 0 2003 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 E680737B401 for ; Wed, 5 Mar 2003 09:57:58 -0800 (PST) Received: from pursued-with.net (adsl-66-125-9-242.dsl.sndg02.pacbell.net [66.125.9.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75CFB43FCB for ; Wed, 5 Mar 2003 09:57:55 -0800 (PST) (envelope-from Kevin_Stevens@pursued-with.net) Received: from pursued-with.net (localhost [127.0.0.1]) by pursued-with.net (8.12.6/8.12.8) with SMTP id h25HvsPg007384; Wed, 5 Mar 2003 09:57:55 -0800 (PST) (envelope-from Kevin_Stevens@pursued-with.net) Received: from 192.85.47.1 (SquirrelMail authenticated user imap) by new.host.name with HTTP; Wed, 5 Mar 2003 09:57:55 -0800 (PST) Message-ID: <30622.192.85.47.1.1046887075.squirrel@new.host.name> Date: Wed, 5 Mar 2003 09:57:55 -0800 (PST) Subject: Re: route pointing to a gateway that's not on net From: "Kevin Stevens" To: In-Reply-To: <200303051416.h25EGaF04635@akiva.homer.att.com> References: <200303051416.h25EGaF04635@akiva.homer.att.com> X-Priority: 3 Importance: Normal Cc: Reply-To: Kevin_Stevens@pursued-with.net X-Mailer: SquirrelMail (version 1.2.11) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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 was recently following a thread on tech-netbsd that was discussing the > routing tables when the gateway address was on a 10.x.x.x network while > the machine was assigned a 209.122.66.x address. The long and short of > the discussion (as I understand the discussion) was that this was that > while it can be accessed via windose and Linux ( > > > On Linux, we could do this to get around that minor problem: > route add -host 192.168.14.88 dev eth0 > ) that is was an evil, ugy illegal network route and that it not > possible, will not be implemented in NetBSD. It is all of that. ;) I've used this in a network setup where there were multiple local links that terminated at a remote router, and the desire was that traffic be able to flow over any of them. But it leaves a bad taste in my brain, like when Cisco refers to "layer three switching". > Now since my cable ISP has me provised it this manner, and since I can't > find a method to get out from FreeBSD using the route command. I was > wondering if a) I missed something and there is some option for the > route command that allows to route to be setup, or if not will netgraph > allow me to setup this route? I think you do it the same way. Can't you create a route to the 10.x.x.x subnet that simply points to the outbound interface? (rummaging around for network access to router...) Yes, you can use the -interface option with the route command. Try this: route add -net 10.0.0.0 -interface (whatever). Worked for me in at least adding the route, I don't have a ready way to test it at the moment. KeS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 10: 8:18 2003 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 84BEE37B401; Wed, 5 Mar 2003 10:08:17 -0800 (PST) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id E15E643FAF; Wed, 5 Mar 2003 10:08:15 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost.he.iki.fi [127.0.0.1]) by silver.he.iki.fi (8.12.8/8.11.4) with ESMTP id h25I85lL020186; Wed, 5 Mar 2003 20:08:06 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <3E663D05.8090401@he.iki.fi> Date: Wed, 05 Mar 2003 20:08:05 +0200 From: Petri Helenius User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021117 X-Accept-Language: English [en],Finnish [fi] MIME-Version: 1.0 To: "M. Warner Losh" Cc: freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns - politically correct version References: <4.3.2.7.2.20030305084442.037e9fa0@gid.co.uk> <3E65BB24.3E37D90D@mindspring.com> <20030305030708.A21014@FreeBSD.org> <20030305.064000.31317673.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; 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 M. Warner Losh wrote: >ISA support is not obsolete. All new PCs still have ISA busses. They >might not have ISA Expansion Bus Slots, but they all[*] still connect >their serial ports, parallel ports, and mouse/keyboard ports via ISA. > > > Not to mention i8254 which gets to be major pain if ACPI would not be an option. Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 10:28: 8 2003 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 D519A37B405 for ; Wed, 5 Mar 2003 10:28:06 -0800 (PST) Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3213A43FA3 for ; Wed, 5 Mar 2003 10:28:05 -0800 (PST) (envelope-from jwb@homer.att.com) Received: from ulysses.homer.att.com ([135.205.193.8]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h25IS0Fl024919; Wed, 5 Mar 2003 12:28:01 -0600 (CST) Received: from akiva.homer.att.com (akiva.homer.att.com [135.205.212.39]) by ulysses.homer.att.com (8.9.3/8.9.3) with ESMTP id NAA24922; Wed, 5 Mar 2003 13:28:00 -0500 (EST) Received: from akiva.homer.att.com (localhost [127.0.0.1]) by akiva.homer.att.com (8.11.6+Sun/8.9.3) with ESMTP id h25IRxF05514; Wed, 5 Mar 2003 13:27:59 -0500 (EST) Message-Id: <200303051827.h25IRxF05514@akiva.homer.att.com> X-Mailer: exmh version 2.6.1 02/18/2003 with nmh-1.0.4 To: Kevin_Stevens@pursued-with.net Cc: freebsd-net@FreeBSD.ORG Subject: Re: route pointing to a gateway that's not on net In-reply-to: Your message of "Wed, 05 Mar 2003 09:57:55 PST." <30622.192.85.47.1.1046887075.squirrel@new.host.name> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Mar 2003 13:27:59 -0500 From: "J. W. Ballantine" 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 Well it's not the way I wanted it, but it's the way I have to try and work with. I tried the route add net 10.0.0.0 -interface (whatever) and that didn't work for me. ---------- In Response to your message ------------- > Date: Wed, 5 Mar 2003 09:57:55 -0800 (PST) > To: > From: "Kevin Stevens" > Subject: Re: route pointing to a gateway that's not on net > > > > > I was recently following a thread on tech-netbsd that was discussing the > > routing tables when the gateway address was on a 10.x.x.x network while > > the machine was assigned a 209.122.66.x address. The long and short of > > the discussion (as I understand the discussion) was that this was that > > while it can be accessed via windose and Linux ( > > > > On Linux, we could do this to get around that minor problem: > > route add -host 192.168.14.88 dev eth0 > > ) that is was an evil, ugy illegal network route and that it not > > possible, will not be implemented in NetBSD. > > It is all of that. ;) I've used this in a network setup where there were > multiple local links that terminated at a remote router, and the desire > was that traffic be able to flow over any of them. But it leaves a bad > taste in my brain, like when Cisco refers to "layer three switching". > > > Now since my cable ISP has me provised it this manner, and since I can't > > find a method to get out from FreeBSD using the route command. I was > > wondering if a) I missed something and there is some option for the > > route command that allows to route to be setup, or if not will netgraph > > allow me to setup this route? > > I think you do it the same way. Can't you create a route to the 10.x.x.x > subnet that simply points to the outbound interface? (rummaging around > for network access to router...) > > Yes, you can use the -interface option with the route command. Try this: > route add -net 10.0.0.0 -interface (whatever). Worked for me in at least > adding the route, I don't have a ready way to test it at the moment. > > KeS > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 10:42:59 2003 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 6E58737B401; Wed, 5 Mar 2003 10:42:58 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5727743FA3; Wed, 5 Mar 2003 10:42:57 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from dialup-209.247.139.242.dial1.sanjose1.level3.net ([209.247.139.242] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18qdqx-0003tR-00; Wed, 05 Mar 2003 10:42:55 -0800 Message-ID: <3E6644E1.7D099302@mindspring.com> Date: Wed, 05 Mar 2003 10:41:37 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Murray Cc: freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: libalias/NAT incremental checksum (was Re: Removal of netns) References: <200303051429.h25ETsIg047004@grimreaper.grondar.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4153c2644eab069e855f5771b60e2c85ca7ce0e8f8d31aa3f350badd9bab72f9c350badd9bab72f9c 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 Mark Murray wrote: > > How long can this remain unfixed before the code is diked out, > > and the checksum is recalculated fully, instead? > > Terry, you sound rather foolish when you argue like this. This > is semantic tomfoolery and off topic. End of thread. This is not a argument over mere implmenetation semantics. The incremental checksum code is broken. Bad tcpchecksum - before: 0x000038f3 after: 0x00001802 Bad tcpchecksum - before: 0x00002870 after: 0x0000e81e Bad tcpchecksum - before: 0x00006319 after: 0x00000608 Bad tcpchecksum - before: 0x0000369a after: 0x00001212 Bad tcpchecksum - before: 0x0000d885 after: 0x00000004 The packets do not get through, no matter how many times they are resent by the sender. The reason that the CVSup is successful is an artifact of the CVSup retry mechanism. People using other protocols, like FTP, or programs like "fetch" are well and truly screwed by this bug. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 10:47:33 2003 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 A135037B401 for ; Wed, 5 Mar 2003 10:47:31 -0800 (PST) Received: from pursued-with.net (adsl-66-125-9-242.dsl.sndg02.pacbell.net [66.125.9.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDC1143F85 for ; Wed, 5 Mar 2003 10:47:30 -0800 (PST) (envelope-from Kevin_Stevens@pursued-with.net) Received: from pursued-with.net (localhost [127.0.0.1]) by pursued-with.net (8.12.6/8.12.8) with SMTP id h25IlUPg007697; Wed, 5 Mar 2003 10:47:30 -0800 (PST) (envelope-from Kevin_Stevens@pursued-with.net) Received: from 192.85.47.2 (SquirrelMail authenticated user imap) by new.host.name with HTTP; Wed, 5 Mar 2003 10:47:30 -0800 (PST) Message-ID: <12883.192.85.47.2.1046890050.squirrel@new.host.name> Date: Wed, 5 Mar 2003 10:47:30 -0800 (PST) Subject: Re: route pointing to a gateway that's not on net From: "Kevin Stevens" To: In-Reply-To: <200303051827.h25IRxF05514@akiva.homer.att.com> References: Your message of "Wed, 05 Mar 2003 09:57:55 PST." <200303051827.h25IRxF05514@akiva.homer.att.com> X-Priority: 3 Importance: Normal Cc: Reply-To: Kevin_Stevens@pursued-with.net X-Mailer: SquirrelMail (version 1.2.11) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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 > Well it's not the way I wanted it, but it's the way I have to try and > work with. > > I tried the route add net 10.0.0.0 -interface (whatever) > and that didn't work for me. That's not the syntax I gave you, and obviously it needs to have your local interface information inserted. I can confirm that the command: route add -net 10.0.0.0 -interface em0 does parse and operate correctly on my 4.7 system, as confirmed by netstat -nr. That is the general approach for directing traffic out a local interface rather than to a same-subnet gateway. Try looking at man route for the details, or perhaps someone else will respond with a higher level of hand-holding. KeS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 11:12:36 2003 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 F2A9E37B401 for ; Wed, 5 Mar 2003 11:12:34 -0800 (PST) Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11F9243FDF for ; Wed, 5 Mar 2003 11:12:34 -0800 (PST) (envelope-from jwb@homer.att.com) Received: from ulysses.homer.att.com ([135.205.193.8]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h25JCVFl022851; Wed, 5 Mar 2003 13:12:32 -0600 (CST) Received: from akiva.homer.att.com (akiva.homer.att.com [135.205.212.39]) by ulysses.homer.att.com (8.9.3/8.9.3) with ESMTP id OAA26207; Wed, 5 Mar 2003 14:12:31 -0500 (EST) Received: from akiva.homer.att.com (localhost [127.0.0.1]) by akiva.homer.att.com (8.11.6+Sun/8.9.3) with ESMTP id h25JCUF05694; Wed, 5 Mar 2003 14:12:30 -0500 (EST) Message-Id: <200303051912.h25JCUF05694@akiva.homer.att.com> X-Mailer: exmh version 2.6.1 02/18/2003 with nmh-1.0.4 To: Kevin_Stevens@pursued-with.net Cc: freebsd-net@FreeBSD.ORG Subject: Re: route pointing to a gateway that's not on net In-reply-to: Your message of "Wed, 05 Mar 2003 10:47:30 PST." <12883.192.85.47.2.1046890050.squirrel@new.host.name> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Mar 2003 14:12:30 -0500 From: "J. W. Ballantine" 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, my typo. I did try route add -net 10.0.0.0 -interface xl0 and route add -net 10.17.47.37 -interface xl0 As I recall both didn't respond with a error message, but when I tried to get out it didn't work. I'll try again tonight and see what happens. Thanks ---------- In Response to your message ------------- > Date: Wed, 5 Mar 2003 10:47:30 -0800 (PST) > To: > From: "Kevin Stevens" > Subject: Re: route pointing to a gateway that's not on net > > > > Well it's not the way I wanted it, but it's the way I have to try and > > work with. > > > > I tried the route add net 10.0.0.0 -interface (whatever) > > and that didn't work for me. > > That's not the syntax I gave you, and obviously it needs to have your > local interface information inserted. I can confirm that the command: > > route add -net 10.0.0.0 -interface em0 > > does parse and operate correctly on my 4.7 system, as confirmed by netstat > -nr. That is the general approach for directing traffic out a local > interface rather than to a same-subnet gateway. > > Try looking at man route for the details, or perhaps someone else will > respond with a higher level of hand-holding. > > KeS > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 11:36:33 2003 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 1232F37B405; Wed, 5 Mar 2003 11:36:32 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB43743FCB; Wed, 5 Mar 2003 11:36:29 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (smmsp@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.7/8.12.7) with ESMTP id h25JaMdh037231; Wed, 5 Mar 2003 11:36:22 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.7/8.12.7/Submit) id h25JaL7u037230; Wed, 5 Mar 2003 11:36:21 -0800 (PST) Date: Wed, 5 Mar 2003 11:36:21 -0800 From: "David O'Brien" To: Terry Lambert Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: [PATCH 5.x] netns Message-ID: <20030305193621.GA37174@dragon.nuxi.com> Reply-To: freebsd-net@freebsd.org, freebsd-current@freebsd.org References: <20030305013509.AD7662A8BB@canning.wemm.org> <3E65E7A5.DBD9097A@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E65E7A5.DBD9097A@mindspring.com> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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 Wed, Mar 05, 2003 at 04:03:49AM -0800, Terry Lambert wrote: > Peter Wemm wrote: > > Terry Lambert wrote: > > > Here are two patches. The first fixes missing pieces in /sys/conf/files > > > and /sys/conf/options, the second fixes all the files that need it in > > > /sys/netns/. > > > > You seem to have posted the wrong patch. > > This is against 4.x, not -current, and this is current@freebsd.org. > Here is a single patch vs. 5.x. > > I believe this makes it actually work. ^^^^^^^^^ huh? This is untested? > Please apply this to the code, even if you are intent on putting > working code in the Attic. Why keep it? You've just proven that even one with a desire has trouble determining if it works or not. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 11:58:46 2003 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 0AA0937B401 for ; Wed, 5 Mar 2003 11:58:46 -0800 (PST) Received: from web21009.mail.yahoo.com (web21009.mail.yahoo.com [216.136.227.63]) by mx1.FreeBSD.org (Postfix) with SMTP id AE37543FCB for ; Wed, 5 Mar 2003 11:58:45 -0800 (PST) (envelope-from davidmyer800@yahoo.com) Message-ID: <20030305195845.5289.qmail@web21009.mail.yahoo.com> Received: from [65.172.158.93] by web21009.mail.yahoo.com via HTTP; Wed, 05 Mar 2003 11:58:45 PST Date: Wed, 5 Mar 2003 11:58:45 -0800 (PST) From: David Myer Subject: UDP socket receive size To: freebsd-net@FreeBSD.ORG 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 Hi, I am setting SO_RCVBUF for UDP socket to 64000 using setsockopt, when sending 8K data using sendto, and recvfrom back from inetd echo service, the length returned from recvfrom is always 4K, why is this ?How can I read a large data back from UDP ( > 4K ) then ? Appreciate the help Dave __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 12:26:11 2003 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 50FDC37B401; Wed, 5 Mar 2003 12:26:10 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id A619143F3F; Wed, 5 Mar 2003 12:26:09 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from dialup-209.247.139.242.dial1.sanjose1.level3.net ([209.247.139.242] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18qfSp-0006Xv-00; Wed, 05 Mar 2003 12:26:08 -0800 Message-ID: <3E665D07.9F8A2C15@mindspring.com> Date: Wed, 05 Mar 2003 12:24:39 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: [PATCH 5.x] netns References: <20030305013509.AD7662A8BB@canning.wemm.org> <3E65E7A5.DBD9097A@mindspring.com> <20030305193621.GA37174@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a486d2ad767939c687cc3c8e4d173d3d6e2601a10902912494350badd9bab72f9c350badd9bab72f9c 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 David O'Brien wrote: > > Here is a single patch vs. 5.x. > > > > I believe this makes it actually work. > ^^^^^^^^^ > huh? This is untested? Will you accept interoperability between two FreeBSD boxes? A FreeBSD box and a NetBSD box? > > Please apply this to the code, even if you are intent on putting > > working code in the Attic. > > Why keep it? You've just proven that even one with a desire has trouble > determining if it works or not. No, I've just implied that I don't personally have the ability to put together an interoperability test bed that tests against non-FreeBSD boxes, without a lot of effort. Is FreeBSD/FreeBSD interoperability acceptable? It's like posting a driver for a SCSI card that was written from the specifications, without a card in hand. Except that his code is *already* in the tree, so it's not like I'm asking anyone to commit anything that doesn't at least make the status quo better. For heaven's sake! *It has only been 3 days* since the code was threatened! What do you expect *in 3 days*!?! -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 12:36:49 2003 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 6712C37B401; Wed, 5 Mar 2003 12:36:48 -0800 (PST) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id A321F43FAF; Wed, 5 Mar 2003 12:36:47 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.12.8/8.12.7) with ESMTP id h25KalgF067791; Wed, 5 Mar 2003 12:36:47 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.12.8/8.12.8/Submit) id h25Kalx1067790; Wed, 5 Mar 2003 12:36:47 -0800 (PST) Date: Wed, 5 Mar 2003 12:36:47 -0800 From: Steve Kargl To: Terry Lambert Cc: freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: [PATCH 5.x] netns Message-ID: <20030305203647.GA67596@troutmask.apl.washington.edu> References: <20030305013509.AD7662A8BB@canning.wemm.org> <3E65E7A5.DBD9097A@mindspring.com> <20030305193621.GA37174@dragon.nuxi.com> <3E665D07.9F8A2C15@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E665D07.9F8A2C15@mindspring.com> User-Agent: Mutt/1.4i 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 Wed, Mar 05, 2003 at 12:24:39PM -0800, Terry Lambert wrote: > > For heaven's sake! *It has only been 3 days* since the code > was threatened! What do you expect *in 3 days*!?! > The code has been broken for 7 years. You've had ample time to fix and *maintain* this code. Points moot, anyway. netns has been moved to the attic. -- Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 13: 3:31 2003 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 09CD537B401; Wed, 5 Mar 2003 13:03:30 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5113843F85; Wed, 5 Mar 2003 13:03:29 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from dialup-209.247.139.242.dial1.sanjose1.level3.net ([209.247.139.242] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18qg2v-0002QW-00; Wed, 05 Mar 2003 13:03:26 -0800 Message-ID: <3E6665AA.CAECC0A8@mindspring.com> Date: Wed, 05 Mar 2003 13:01:30 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Kargl Cc: freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: [PATCH 5.x] netns References: <20030305013509.AD7662A8BB@canning.wemm.org> <3E65E7A5.DBD9097A@mindspring.com> <20030305193621.GA37174@dragon.nuxi.com> <3E665D07.9F8A2C15@mindspring.com> <20030305203647.GA67596@troutmask.apl.washington.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4aa53b3a0ad581abae6cb9c7e30eba8eb350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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 Steve Kargl wrote: > On Wed, Mar 05, 2003 at 12:24:39PM -0800, Terry Lambert wrote: > > For heaven's sake! *It has only been 3 days* since the code > > was threatened! What do you expect *in 3 days*!?! > > > > The code has been broken for 7 years. You've > had ample time to fix and *maintain* this code. > > Points moot, anyway. netns has been moved to > the attic. Well, that'll certainly show Terry! Any chance at all of committing my patch to the code in the attic, so that it will at least compile and run as of current of the time it was put in the attic? Thanks, -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 15:27:29 2003 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 945A137B401; Wed, 5 Mar 2003 15:27:27 -0800 (PST) Received: from scl8owa02.int.exodus.net (scl8out02.exodus.net [66.35.230.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB80843FDD; Wed, 5 Mar 2003 15:27:24 -0800 (PST) (envelope-from Maksim.Yevmenkin@cw.com) Received: from scl8owa01.int.exodus.net ([66.35.230.241]) by scl8owa02.int.exodus.net with Microsoft SMTPSVC(5.0.2195.5329); Wed, 5 Mar 2003 15:27:24 -0800 Received: from exodus.net ([165.193.27.35]) by scl8owa01.int.exodus.net over TLS secured channel with Microsoft SMTPSVC(5.0.2195.5329); Wed, 5 Mar 2003 15:27:24 -0800 Message-ID: <3E66871A.4080304@exodus.net> Date: Wed, 05 Mar 2003 15:24:10 -0800 From: Maksim Yevmenkin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021126 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: current@freebsd.org Cc: net@freebsd.org Subject: Bluetooth stack for FreeBSD References: <3E667ED7.2060603@exodus.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Mar 2003 23:27:24.0351 (UTC) FILETIME=[C6F2E4F0:01C2E36E] 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 Hackers, I'm very pleased to announce that another release is available for download at http://www.geocities.com/m_evmenkin/ngbt-fbsd-20030305.tar.gz The Bluetooth sockets layer has been cleaned up. People should not see any WITNESS complains with new code. Locking issues have been revisited and code in much better shape now, although it probably is not 100% SMP ready just yet. The code should work on SMP system anyway because sockets layer is still under Giant. Minor bug in OpenOBEX library has been fixed and OPEX Put-Empty command now works. Also ng_ubt(4) now supports Wireless Transceiver for Bluetooth from Microsoft. Thanks to Dustin Boontheekul for testing. IMPORTANT! Due to changes in API userland tools must be in sync with the kernel. People should install new include files, recompile and reinstall all userland tools as part of upgrade. I'm sorry about that. IMPORTANT! New taskqueue_swi_giant has been introduces recently in FreeBSD. The socket code has been converted to use it. If you system is not recent you will need 1) upgrade to recent -current or 2) change taskqueue_swi_giant to taskqueue_swi and compile code. People are advised to upgrade and try the new code. Please do ask question and submit success stories/bug reports to me. Please also CC to one the FreeBSD mailing lists (mobile, net or current) for archive purposes. thanks, max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 20:13:34 2003 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 D599D37B405 for ; Wed, 5 Mar 2003 20:13:33 -0800 (PST) Received: from web13403.mail.yahoo.com (web13403.mail.yahoo.com [216.136.175.61]) by mx1.FreeBSD.org (Postfix) with SMTP id 2B00C43F85 for ; Wed, 5 Mar 2003 20:13:33 -0800 (PST) (envelope-from giffunip@yahoo.com) Message-ID: <20030306041333.7884.qmail@web13403.mail.yahoo.com> Received: from [200.24.79.242] by web13403.mail.yahoo.com via HTTP; Thu, 06 Mar 2003 05:13:33 CET Date: Thu, 6 Mar 2003 05:13:33 +0100 (CET) From: "=?iso-8859-1?q?Pedro=20F.=20Giffuni?=" Subject: Re: [PATCH 5.x] netns To: freebsd-net@freebsd.org, freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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 Guys; I have to agree with Terry that the fixes for netns should be committed, and furthermore they should be MFC (using his first patch perhaps). It's a nightmare to try to rescue anything from the Attic, at least it would be nice to have it in better shape before killing it. The flame fest on removing it or not can go on ;). cheers, Pedro. ______________________________________________________________________ Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonino http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 5 21: 7:24 2003 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 823C137B401; Wed, 5 Mar 2003 21:07:23 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DF6D43F85; Wed, 5 Mar 2003 21:07:23 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id E4E742A8C1; Wed, 5 Mar 2003 21:07:22 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "=?iso-8859-1?q?Pedro=20F.=20Giffuni?=" Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: [PATCH 5.x] netns In-Reply-To: <20030306041333.7884.qmail@web13403.mail.yahoo.com> Date: Wed, 05 Mar 2003 21:07:22 -0800 From: Peter Wemm Message-Id: <20030306050722.E4E742A8C1@canning.wemm.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 "=?iso-8859-1?q?Pedro=20F.=20Giffuni?=" wrote: > Guys; > > I have to agree with Terry that the fixes for netns > should be committed, and furthermore they should be > MFC (using his first patch perhaps). It's a nightmare > to try to rescue anything from the Attic, at least it > would be nice to have it in better shape before > killing it. They can be cleaned up and committed to RELENG_4 after the freeze is over. The original 4.x patch posted wasn't ready for commit though. (eg: externs scattered all over the place rather than declaring things properly in the include files). Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 6 3: 5: 0 2003 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 960B237B401 for ; Thu, 6 Mar 2003 03:04:57 -0800 (PST) Received: from smtp.completel.fr (smtp.completel.fr [213.244.0.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7659E43F85 for ; Thu, 6 Mar 2003 03:04:56 -0800 (PST) (envelope-from fabien.thomas@netasq.com) Received: from netasq.com (unknown [213.30.137.178]) by smtp.completel.fr (Postfix) with ESMTP id B5FA6179EDE for ; Thu, 6 Mar 2003 12:04:52 +0100 (CET) Received: from netasq.com by completel.fr (8.10.1/8.10.1) with ESMTP id h26B7UA22359 for ; Thu, 6 Mar 2003 12:07:30 +0100 (CET) Date: Thu, 6 Mar 2003 12:04:40 +0100 From: Fabien THOMAS X-Mailer: The Bat! (v1.62i) Business Organization: NETASQ X-Priority: 3 (Normal) Message-ID: <160266830406.20030306120440@netasq.com> To: freebsd-net@FreeBSD.ORG Subject: rl driver mac address probem MIME-Version: 1.0 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 Hi, I've a problem for setting the mac address for the rl driver (ifconfig rl0 ether xx:xx:xx:xx:xx:xx). The chip datasheet said that address can be read as a single byte but it must be written 4 bytes at a time. The patch correct the problem and have been grabbed from the linux driver (but have a read overflow of 2 bytes). is it possible that someone can review & commit the correction fabien --- if_rl.c.orig Thu Mar 6 11:32:58 2003 +++ if_rl.c Thu Mar 6 11:33:37 2003 @@ -1474,7 +1474,7 @@ struct rl_softc *sc = xsc; struct ifnet *ifp = &sc->arpcom.ac_if; struct mii_data *mii; - int s, i; + int s; u_int32_t rxcfg = 0; s = splimp(); @@ -1487,9 +1487,9 @@ rl_stop(sc); /* Init our MAC address */ - for (i = 0; i < ETHER_ADDR_LEN; i++) { - CSR_WRITE_1(sc, RL_IDR0 + i, sc->arpcom.ac_enaddr[i]); - } + CSR_WRITE_1(sc, RL_EECMD, RL_EEMODE_WRITECFG); + CSR_WRITE_4(sc, RL_IDR0, *(u_int32_t *)&sc->arpcom.ac_enaddr[0]); + CSR_WRITE_4(sc, RL_IDR4, *(u_int32_t *)&sc->arpcom.ac_enaddr[4]); /* Init the RX buffer pointer register. */ CSR_WRITE_4(sc, RL_RXADDR, vtophys(sc->rl_cdata.rl_rx_buf)); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 6 10: 3:48 2003 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 045E837B401; Thu, 6 Mar 2003 10:03:47 -0800 (PST) Received: from ntli.com (pc1-glfd2-4-cust59.glfd.cable.ntl.com [81.99.187.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C3D943FB1; Thu, 6 Mar 2003 10:03:45 -0800 (PST) (envelope-from william@palfreman.com) Received: from aqua.lan.palfreman.com (localhost [127.0.0.1]) by ntli.com (8.12.3/8.12.3) with ESMTP id h26I8V8Q003128; Thu, 6 Mar 2003 18:08:31 GMT (envelope-from william@palfreman.com) Received: from localhost (william@localhost) by aqua.lan.palfreman.com (8.12.3/8.12.3/Submit) with ESMTP id h26I8SSf003125; Thu, 6 Mar 2003 18:08:29 GMT X-Authentication-Warning: aqua.lan.palfreman.com: william owned process doing -bs Date: Thu, 6 Mar 2003 18:08:28 +0000 (GMT) From: William Palfreman To: Terry Lambert Cc: Bob Bishop , Peter Wemm , Mike Barcroft , Tim Robbins , freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Removal of netns - politically correct version In-Reply-To: <3E65BB24.3E37D90D@mindspring.com> Message-ID: <20030306174753.H2461@ndhn.yna.cnyserzna.pbz> References: <3E6539B5.2F5D31B@mindspring.com> <4.3.2.7.2.20030305084442.037e9fa0@gid.co.uk> <3E65BB24.3E37D90D@mindspring.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 Wed, 5 Mar 2003, Terry Lambert wrote: > if it can be made to work. I would argue that ISA support is > more or less just as obsolete, as is 486 support, as is the F00F > bug workaround, as is ... a lot of code that's still there. Three of my machines have the F00F bug; my firewall, my print server and my laptop - I happened to test this earlier today, while upgrading my last 4.5-pX machines. I also use ISA network cards a bit, and a lot of on-motherboard things seem to be logically ISA devices. I don't have any 486s now, but that is more to do with end-of-life ones not being prefitted with a useful amount of memory. I'd be very grateful if ISA support and the f00f workaround stayed in FreeBSD for a long time yet. Regards, William Palfreman. -- W. Palfreman. I'm looking for a job: Tel: 0771 355 0354 http://www.palfreman.com/william/ for my CV. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 6 10:44:48 2003 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 146AA37B401 for ; Thu, 6 Mar 2003 10:44:46 -0800 (PST) Received: from s142-179-196-204.ab.hsia.telus.net (s142-179-196-204.ab.hsia.telus.net [142.179.196.204]) by mx1.FreeBSD.org (Postfix) with SMTP id 29AC443F93 for ; Thu, 6 Mar 2003 10:44:45 -0800 (PST) (envelope-from shawn@crsretailpro.com) Received: (qmail 74010 invoked from network); 6 Mar 2003 18:56:55 -0000 Received: from unknown (HELO peter.CRSEDM.local) (10.0.11.1) by s142-179-196-204.ab.hsia.telus.net with SMTP; 6 Mar 2003 18:56:55 -0000 Subject: FreeBSD 5.0 Multiple NICs , IPFW and IPNAT Date: Thu, 6 Mar 2003 11:46:31 -0700 Message-ID: X-MS-Has-Attach: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MS-TNEF-Correlator: Thread-Topic: FreeBSD 5.0 Multiple NICs , IPFW and IPNAT Thread-Index: AcLkELP1pDeqpl59TIqVsPLoDxpetg== content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 From: "Shawn Dillon" To: 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 need some help. I have a freebsd 5.0 box running IPNAT and IPF as a firewall. I = currently have five static IPS with my ISP. With my ISP I must register = the MAC address of the adapter to obtain an IP. Thus I have a FreeBSD = box with six nics in it ( all 3c905C). The basic config is as follows: ***************************** * * * Internet * ****************************** | | | 3Com DSL Bridge | | | 3Com 10MB Office Connect Hub | | | | | | | | | | | | | | | | | | | | | | | | | xl1 xl2 xl3 xl4 xl5 ******************************************************** * * * FreeBSD 5.0 IPNAT/IPFW * ********************************************************* | | | xl0 | | 3Com 3300 XM Switch I can get one external NIC up and running. But when I get a second one = up and running I get a kernel message stating that the second NIC (xl2) is trying to use the same IP as XL1. They are = set to different IP's in the rc.conf. I assume that this is because they = can see each other on the hub that splits the 3Com bridge out.=20 Is there any arguments or settings that I could use to resolve this? An = ipconfig setting? Or even a kernel option. I would recompile the kernel = in a second if it would help. You can assume that xl1 has an ip of 142.179.196.134 and xl2 has an ip = of 142.179.196.135 both with a subnet of 255.255.248.0. Thanks in advance Shawn Dillon =09 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 6 11:34:22 2003 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 1E6EE37B401; Thu, 6 Mar 2003 11:34:19 -0800 (PST) Received: from haakonia.hitnet.rwth-aachen.de (haakonia.hitnet.RWTH-Aachen.DE [137.226.181.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24DBC43F93; Thu, 6 Mar 2003 11:34:14 -0800 (PST) (envelope-from chris@unixpages.org) Received: from gondor.middleearth (gondor.middleearth [192.168.1.42]) by haakonia.hitnet.rwth-aachen.de (Postfix) with ESMTP id 8F751ABD4; Thu, 6 Mar 2003 20:34:13 +0100 (CET) Received: by gondor.middleearth (Postfix, from userid 1001) id 230EB4408; Thu, 6 Mar 2003 20:34:12 +0100 (CET) Date: Thu, 6 Mar 2003 20:34:12 +0100 From: Christian Brueffer To: Maksim Yevmenkin Cc: current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Bluetooth stack for FreeBSD Message-ID: <20030306193412.GF63966@unixpages.org> References: <3E667ED7.2060603@exodus.net> <3E66871A.4080304@exodus.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XStn23h1fwudRqtG" Content-Disposition: inline In-Reply-To: <3E66871A.4080304@exodus.net> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT X-PGP-Key: http://people.freebsd.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D 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 --XStn23h1fwudRqtG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 05, 2003 at 03:24:10PM -0800, Maksim Yevmenkin wrote: >=20 > Dear Hackers, >=20 > I'm very pleased to announce that another release is available for=20 > download at >=20 > http://www.geocities.com/m_evmenkin/ngbt-fbsd-20030305.tar.gz >=20 > The Bluetooth sockets layer has been cleaned up. People should not > see any WITNESS complains with new code. Locking issues have been > revisited and code in much better shape now, although it probably > is not 100% SMP ready just yet. The code should work on SMP system > anyway because sockets layer is still under Giant. Minor bug in > OpenOBEX library has been fixed and OPEX Put-Empty command now works. > Also ng_ubt(4) now supports Wireless Transceiver for Bluetooth from > Microsoft. Thanks to Dustin Boontheekul > for testing. >=20 > IMPORTANT! >=20 > Due to changes in API userland tools must be in sync with the kernel. > People should install new include files, recompile and reinstall all > userland tools as part of upgrade. I'm sorry about that. >=20 > IMPORTANT! >=20 > New taskqueue_swi_giant has been introduces recently in FreeBSD. > The socket code has been converted to use it. If you system is > not recent you will need >=20 > 1) upgrade to recent -current > or > 2) change taskqueue_swi_giant to taskqueue_swi and compile code. >=20 > People are advised to upgrade and try the new code. Please do ask > question and submit success stories/bug reports to me. Please also > CC to one the FreeBSD mailing lists (mobile, net or current) for > archive purposes. >=20 > thanks, > max >=20 Are there any undertakings on the way to update the bluetooth code in -CURRENT to a newer snapshot? - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --XStn23h1fwudRqtG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+Z6K0bHYXjKDtmC0RAsAnAKDdo09nMb7/RrUbfa7L8ai1k3bUPACfaD4G VLN1j2KI+PdPb2kwW2skW9E= =wniD -----END PGP SIGNATURE----- --XStn23h1fwudRqtG-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 6 11:42:52 2003 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 2AD5837B401 for ; Thu, 6 Mar 2003 11:42:49 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67FA543FB1 for ; Thu, 6 Mar 2003 11:42:48 -0800 (PST) (envelope-from larse@ISI.EDU) Received: from isi.edu (nik.isi.edu [128.9.168.58]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id h26Jgjv25849; Thu, 6 Mar 2003 11:42:45 -0800 (PST) Message-ID: <3E67A4B5.3090905@isi.edu> Date: Thu, 06 Mar 2003 11:42:45 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030305 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Shawn Dillon Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 5.0 Multiple NICs , IPFW and IPNAT References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090803070900030502000507" 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 cryptographically signed message in MIME format. --------------ms090803070900030502000507 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Shawn Dillon wrote: > > I have a freebsd 5.0 box running IPNAT and IPF as a firewall. I > currently have five static IPS with my ISP. With my ISP I must > register the MAC address of the adapter to obtain an IP. Thus I have > a FreeBSD box with six nics in it ( all 3c905C). If they are static addresses, there is no need to run DHCP to get them. Just assign them as aliases to a single NIC, turn off DHCP, and related MAC address registration headaches go away. Lars -- Lars Eggert USC Information Sciences Institute --------------ms090803070900030502000507 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAzMDMwNjE5NDI0NVowIwYJKoZIhvcNAQkEMRYEFFujrcyAzUVEgJU3nhBH B8BYePFOMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCVBMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMIJUEwDQYJKoZIhvcNAQEBBQAEggEAB7ZJ+JdvJ7VtRMqUdVOnLayc4AazLS0pDLbt L4Utod22mez7Dbqfe3i5sbCxrhYivu4JyE2ny7c1aoMT5dBhKtQSskrnHV6LXyv5Y6aoEy5K NIPRQgdeXirwGEIIawzF5WU4QswEBRpOS3mcZhCiM5BvcL/w7yfnHeaA28lcmbSPI8+8RtTO aodGL6WgrRbnaTW0iknX8RGNUDmt3Tot2PUZZDS11OqxUEoVnMAwPS8rR+HXoHI8Fe528WgF kdc/LbqLir9E8AARQs+L+1A+gy2/mmB6qRwAVj9flaAM3sCaKCkAp7MlPR+Y+uhlSMniIwsA TONPaHIyGOo3oZFU8gAAAAAAAA== --------------ms090803070900030502000507-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 6 11:44:42 2003 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 9CD1537B407; Thu, 6 Mar 2003 11:44:41 -0800 (PST) Received: from scl8owa02.int.exodus.net (scl8out02.exodus.net [66.35.230.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EF4D43FCB; Thu, 6 Mar 2003 11:44:39 -0800 (PST) (envelope-from Maksim.Yevmenkin@cw.com) Received: from scl8owa01.int.exodus.net ([66.35.230.241]) by scl8owa02.int.exodus.net with Microsoft SMTPSVC(5.0.2195.5329); Thu, 6 Mar 2003 11:44:39 -0800 Received: from exodus.net ([165.193.27.35]) by scl8owa01.int.exodus.net over TLS secured channel with Microsoft SMTPSVC(5.0.2195.5329); Thu, 6 Mar 2003 11:44:38 -0800 Message-ID: <3E67A463.9050402@exodus.net> Date: Thu, 06 Mar 2003 11:41:23 -0800 From: Maksim Yevmenkin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021126 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: Christian Brueffer Cc: current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Bluetooth stack for FreeBSD References: <3E667ED7.2060603@exodus.net> <3E66871A.4080304@exodus.net> <20030306193412.GF63966@unixpages.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2003 19:44:38.0874 (UTC) FILETIME=[D2EAB3A0:01C2E418] 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 Christian, [...] > Are there any undertakings on the way to update the bluetooth code > in -CURRENT to a newer snapshot? As soon as I get at least few positive feedbacks from the testers Julian will commit it :) I do not feel comfortable to commit the code that has only been tested on the limited set of devices I have. So I'll ask this again. Please try the new code and let me know if it works for you. Pretty please with two sugar lumps on top :) thanks, max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 6 11:53:38 2003 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 BCA2037B405; Thu, 6 Mar 2003 11:53:36 -0800 (PST) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id E190543F3F; Thu, 6 Mar 2003 11:53:35 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc01.attbi.com (sccrmhc01) with ESMTP id <2003030619533400100j5cq6e>; Thu, 6 Mar 2003 19:53:35 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA71399; Thu, 6 Mar 2003 11:53:33 -0800 (PST) Date: Thu, 6 Mar 2003 11:53:31 -0800 (PST) From: Julian Elischer To: Christian Brueffer Cc: Maksim Yevmenkin , current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Bluetooth stack for FreeBSD In-Reply-To: <20030306193412.GF63966@unixpages.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 yes as soon as we get some +ve feedback about it.. i.e. if it works for you let us know and af we don't hear anything -ve and do hear +ve, we'll commit it :-) (Or rather I'll commit it for Maksim). On Thu, 6 Mar 2003, Christian Brueffer wrote: > > Are there any undertakings on the way to update the bluetooth code > in -CURRENT to a newer snapshot? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 6 13:32:45 2003 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 C3DB537B401; Thu, 6 Mar 2003 13:32:43 -0800 (PST) Received: from jawa.at (jawa.at [213.229.17.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E5A143F3F; Thu, 6 Mar 2003 13:32:40 -0800 (PST) (envelope-from mbretter@jawa.at) Received: from jawa.at (worf.jawa.at [192.168.201.12]) by jawa.at (8.12.6/8.12.6) with ESMTP id h26LWX1Z048083; Thu, 6 Mar 2003 22:32:33 +0100 (CET) (envelope-from mbretter@jawa.at) Message-ID: <3E67BE17.6030401@jawa.at> Date: Thu, 06 Mar 2003 22:31:03 +0100 From: Michael Bretterklieber User-Agent: Mozilla/5.0 (X11; U; Linux i386; de-AT; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vincent Jardin Cc: net@FreeBSD.ORG, archie Subject: Re: [mpd] radius and dynamic bundles References: <200303022347.10283.vjardin@wanadoo.fr> <3E63245D.6040800@jawa.at> <200303031827.54786.vjardin@wanadoo.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-1.0 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 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, Vincent Jardin wrote: > > It does not look to be simple because the whole PAP and CHAP authentication > are processed by PapInput() and ChapInput() that call RadiusPAPAuthenticate() > and RadiusCHAPAuthenticate(). It is a synchronous call. In order to use > rad_init_send_request() and rad_continue_send_request(), PapInput() and > ChapInput() need to be splitted, doesn't they ? actualy I had a look on this and in fact it seems that this needs a bigger rewrite of mpd's authentication system, because it isn't designed for asynchronous authentication. Atm I have no time to do this, sorry, bye, -- ------------------------------- ------------------------------------- Michael Bretterklieber - Michael.Bretterklieber@jawa.at JAWA Management Software GmbH - http://www.jawa.at Liebenauer Hauptstr. 200 -------------- privat --------------- A-8041 GRAZ GSM: ++43-(0)676-93 96 698 Tel: ++43-(0)316-403274-12 E-mail: michael@bretterklieber.com Fax: ++43-(0)316-403274-10 http://www.bretterklieber.com ------------------------------- ------------------------------------- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 6 13:50:26 2003 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 CCB9737B405 for ; Thu, 6 Mar 2003 13:50:24 -0800 (PST) Received: from web14803.mail.yahoo.com (web14803.mail.yahoo.com [216.136.224.219]) by mx1.FreeBSD.org (Postfix) with SMTP id DC3CE43F3F for ; Thu, 6 Mar 2003 13:50:23 -0800 (PST) (envelope-from fabrica64@yahoo.com) Message-ID: <20030306215023.64687.qmail@web14803.mail.yahoo.com> Received: from [80.116.123.11] by web14803.mail.yahoo.com via HTTP; Thu, 06 Mar 2003 13:50:23 PST Date: Thu, 6 Mar 2003 13:50:23 -0800 (PST) From: Paolo M Subject: BIND stange behavior To: questions@freebsd.org Cc: net@freebsd.org 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 Hi Everybody, I am using a FreeBSD 4.7p7 box as the gateway to the Internet in my home. I saw a very starnge behavior accessing mail.yahoo.com from a connected Apple MacOS (but also from any other PC), the first attempt to resolve the names replies an error. If I repeat the request everything is fine. If I wait some minutes all the sequence repeats... It seems BIND is answering with an error.. so I saw that mail.yahoo.com has two addresses (with nslookup), and that it returns one of them in an altternate way, but all the two addresses are ok, if accessed directly as IP from the browser. From a couple of week, also www.apple.com has the same behavior. The twos are handled by akadns.net Has anybody experienced this problem? Thanks you! Paolo __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 6 13:58:37 2003 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 0F16337B401; Thu, 6 Mar 2003 13:58:35 -0800 (PST) Received: from gatekeeper.microcell.ca (gatekeeper.microcell.ca [205.151.8.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C411143F75; Thu, 6 Mar 2003 13:58:31 -0800 (PST) (envelope-from SoHo@admin.fido.ca) Received: from mailserv.microcell.ca (mailserv.microcell.ca [10.2.0.87]) by gatekeeper.microcell.ca (Postfix) with ESMTP id EE2CD16D06; Thu, 6 Mar 2003 16:58:30 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by mailserv.microcell.ca (Postfix) with SMTP id B612416BD5; Thu, 6 Mar 2003 16:58:30 -0500 (EST) Received: from lenard.admin.fido.ca (lamus.fido.ca [10.0.1.45]) by mailserv.microcell.ca (Postfix) with ESMTP id E7BB316BD5; Thu, 6 Mar 2003 16:58:29 -0500 (EST) Received: from magni.microcell.ca (magni.microcell.ca [10.6.22.102]) by lenard.admin.fido.ca (SMTP_Gateway) with ESMTP id B375C47D3C; Thu, 6 Mar 2003 16:58:29 -0500 (EST) Received: from magni.microcell.ca (localhost.microcell.ca [127.0.0.1]) by magni.microcell.ca (8.12.6/8.12.7) with ESMTP id h26M3Zfa001114; Thu, 6 Mar 2003 17:03:35 -0500 (EST) (envelope-from SoHo@admin.fido.ca) Received: (from ebaroud@localhost) by magni.microcell.ca (8.12.6/8.12.6/Submit) id h26M3Zxm001113; Thu, 6 Mar 2003 17:03:35 -0500 (EST) X-Authentication-Warning: magni.microcell.ca: ebaroud set sender to SoHo@admin.fido.ca using -f Date: Thu, 6 Mar 2003 17:03:35 -0500 From: Edmond Baroud To: Paolo M Cc: questions@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: BIND stange behavior Message-ID: <20030306220335.GA1068@admin.fido.ca> References: <20030306215023.64687.qmail@web14803.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030306215023.64687.qmail@web14803.mail.yahoo.com> User-Agent: Mutt/1.4i X-Sanitizer: This message has been sanitized! X-Sanitizer-Rev: $Id: Sanitizer.pm,v 1.64 2002/10/22 16:37:04 bre Exp $ 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 man named.conf search for Ordering, round, robin or cyclic that is a "feature" and not a strange behaviour. Ed. Quoting Paolo M (fabrica64@yahoo.com): > Hi Everybody, > > I am using a FreeBSD 4.7p7 box as the gateway to the > Internet in my home. > > I saw a very starnge behavior accessing mail.yahoo.com > from a connected Apple MacOS (but also from any other > PC), the first attempt to resolve the names replies an > error. If I repeat the request everything is fine. If > I wait some minutes all the sequence repeats... > > It seems BIND is answering with an error.. so I saw > that mail.yahoo.com has two addresses (with nslookup), > and that it returns one of them in an altternate way, > but all the two addresses are ok, if accessed directly > as IP from the browser. > > >From a couple of week, also www.apple.com has the same > behavior. > > The twos are handled by akadns.net > > Has anybody experienced this problem? > > Thanks you! > > Paolo > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message -- Edmond Baroud UNIX Systems Admin mailto:SoHo@admin.fido.ca Fingerprint 140F 5FD5 3FDD 45D9 226D 9602 8C3D EAFB 4E19 BEF9 "UNIX is very user friendly, it's just picky about who its friends are." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 6 14:57:27 2003 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 EB29B37B401; Thu, 6 Mar 2003 14:57:24 -0800 (PST) Received: from haakonia.hitnet.rwth-aachen.de (haakonia.hitnet.RWTH-Aachen.DE [137.226.181.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id B062943F93; Thu, 6 Mar 2003 14:57:23 -0800 (PST) (envelope-from chris@unixpages.org) Received: from gondor.middleearth (gondor.middleearth [192.168.1.42]) by haakonia.hitnet.rwth-aachen.de (Postfix) with ESMTP id EB581ABC9; Thu, 6 Mar 2003 23:57:22 +0100 (CET) Received: by gondor.middleearth (Postfix, from userid 1001) id 6A70A4408; Thu, 6 Mar 2003 23:57:22 +0100 (CET) Date: Thu, 6 Mar 2003 23:57:22 +0100 From: Christian Brueffer To: Maksim Yevmenkin Cc: current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Bluetooth stack for FreeBSD Message-ID: <20030306225722.GH63966@unixpages.org> References: <3E667ED7.2060603@exodus.net> <3E66871A.4080304@exodus.net> <20030306193412.GF63966@unixpages.org> <3E67A463.9050402@exodus.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZYOWEO2dMm2Af3e3" Content-Disposition: inline In-Reply-To: <3E67A463.9050402@exodus.net> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT X-PGP-Key: http://people.freebsd.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D 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 --ZYOWEO2dMm2Af3e3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 06, 2003 at 11:41:23AM -0800, Maksim Yevmenkin wrote: > Hello Christian, >=20 > [...] >=20 > >Are there any undertakings on the way to update the bluetooth code > >in -CURRENT to a newer snapshot? >=20 > As soon as I get at least few positive feedbacks from the testers > Julian will commit it :) I do not feel comfortable to commit the > code that has only been tested on the limited set of devices I have. >=20 > So I'll ask this again. Please try the new code and let me know if > it works for you. Pretty please with two sugar lumps on top :) >=20 > thanks, > max >=20 Great news :-) However, I can't test the code at the moment. My cell phone is bluetooth capable, but I don't have a bluetooth card yet. I was just interested because the -CURRENT sources haven't been updated for some time :-) - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --ZYOWEO2dMm2Af3e3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+Z9JSbHYXjKDtmC0RAoCOAKDdDsFBVrco77lDVlrFudvf+IlPgQCfdbf8 N/mlFWDppMHf0h3qontHHT8= =VQIV -----END PGP SIGNATURE----- --ZYOWEO2dMm2Af3e3-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 6 17:29:43 2003 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 028B037B401 for ; Thu, 6 Mar 2003 17:29:42 -0800 (PST) Received: from yama.openaccess.org (ns1.openaccess.org [216.57.214.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A8F443F3F for ; Thu, 6 Mar 2003 17:29:41 -0800 (PST) (envelope-from michael@staff.openaccess.org) Received: from [216.57.214.91] ([216.57.214.91]) by yama.openaccess.org (8.12.3/8.11.6) with ESMTP id h271GcQs010050 for ; Thu, 6 Mar 2003 17:16:39 -0800 (PST) (envelope-from michael@staff.openaccess.org) User-Agent: Microsoft-Entourage/10.0.0.1309 Date: Thu, 06 Mar 2003 17:29:32 -0800 Subject: Load balancing /multipath From: Michael DeMan To: Message-ID: Mime-version: 1.0 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 Hi All, Are there any plans to get load balancing our multipath routing in the BSD kernel similar to what iproute2 supports in linux? Thanks, - Mike Michael F. DeMan Director of Technology OpenAccess Internet Services 1305 11th St., 3rd Floor Bellingham, WA 98225 Tel 360-647-0785 x204 Fax 360-738-9785 michael@staff.openaccess.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 6 18:12:52 2003 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 DF37F37B401 for ; Thu, 6 Mar 2003 18:12:50 -0800 (PST) Received: from odysseus.silby.com (d77.as6.nwbl0.wi.voyager.net [169.207.128.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F91B43FDF for ; Thu, 6 Mar 2003 18:12:47 -0800 (PST) (envelope-from silby@silby.com) Received: from odysseus.silby.com (localhost [127.0.0.1]) by odysseus.silby.com (8.12.7/8.12.7) with ESMTP id h26NEl0K001470; Thu, 6 Mar 2003 17:14:47 -0600 (CST) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by odysseus.silby.com (8.12.7/8.12.7/Submit) with ESMTP id h26NEkoP001467; Thu, 6 Mar 2003 17:14:47 -0600 (CST) X-Authentication-Warning: odysseus.silby.com: silby owned process doing -bs Date: Thu, 6 Mar 2003 17:14:46 -0600 (CST) From: Mike Silbersack To: "J. W. Ballantine" Cc: freebsd-net@FreeBSD.ORG Subject: Re: route pointing to a gateway that's not on net In-Reply-To: <200303051416.h25EGaF04635@akiva.homer.att.com> Message-ID: <20030306171300.V855@odysseus.silby.com> References: <200303051416.h25EGaF04635@akiva.homer.att.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 Wed, 5 Mar 2003, J. W. Ballantine wrote: > I was recently following a thread on tech-netbsd that was discussing > the routing tables when the gateway address was on a 10.x.x.x network > while the machine was assigned a 209.122.66.x address. The long and short > of the discussion (as I understand the discussion) was that this was > that while it can be accessed via windose and Linux ( > > > On Linux, we could do this to get around that minor problem: > > > route add -host 192.168.14.88 dev eth0 > ) that is was an evil, ugy illegal network route and that it not possible, > will not be implemented in NetBSD. > > Now since my cable ISP has me provised it this manner, and since I can't > find a method to get out from FreeBSD using the route command. I was > wondering if a) I missed something and there is some option for the route > command that allows to route to be setup, or if not will netgraph allow me > to setup this route? > > Thanks > > Jim Ballantine Have you tried using arp to create an arp entry for that IP address? That may allow the route command to then work, as it'll believe that you're local to the router. (Not tested, although I recall doing something similar before.) Alternately, using arp to assign a *fake* IP address which is on your subnet to the ethernet address of the router, then add a default route to that. Maybe the router will still pass the packets. 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 Mar 6 18:29:59 2003 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 6F15637B401 for ; Thu, 6 Mar 2003 18:29:58 -0800 (PST) Received: from exchange.wan.no (exchange.wan.no [80.86.128.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EA8943FB1 for ; Thu, 6 Mar 2003 18:29:57 -0800 (PST) (envelope-from sten.daniel.sorsdal@wan.no) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: TCP in TIME_WAIT for too long? X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 7 Mar 2003 03:29:51 +0100 Message-ID: <0AF1BBDF1218F14E9B4CCE414744E70F07DE6B@exchange.wanglobal.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP in TIME_WAIT for too long? Thread-Index: AcLkUVQLyvKNSuJSQI+t7c8cy5t++A== From: =?iso-8859-1?Q?Sten_Daniel_S=F8rsdal?= To: 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've tried freebsd-questions but no reply. I use a FreeBSD 4.7-STABLE box as a Zebra BGP route server. When my provider reset their interface (switch inbetween) the=20 TCP connect seems to linger in TIME_WAIT for a very long time (up to 20 minutes?). Are there any ways to tweak the TCP settings to detect a dead tcp connect in just a manner of minutes/seconds? - Sten To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 6 19: 7: 3 2003 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 3BAC237B401 for ; Thu, 6 Mar 2003 19:07:02 -0800 (PST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 014B043F75 for ; Thu, 6 Mar 2003 19:07:01 -0800 (PST) (envelope-from hsu@FreeBSD.org) Received: from FreeBSD.org ([63.193.112.125]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with ESMTP id <0HBC00G5MZ9MHC@mta5.snfc21.pbi.net> for freebsd-net@FreeBSD.org; Thu, 06 Mar 2003 19:05:46 -0800 (PST) Date: Thu, 06 Mar 2003 19:10:33 -0800 From: Jeffrey Hsu Subject: Re: TCP in TIME_WAIT for too long? In-reply-to: Message from =?iso-8859-1?Q?Sten_Daniel_S=F8rsdal?= "of Fri, 07 Mar 2003 03:29:51 +0100." <0AF1BBDF1218F14E9B4CCE414744E70F07DE6B@exchange.wanglobal.net> To: =?iso-8859-1?Q?Sten_Daniel_S=F8rsdal?= Cc: freebsd-net@FreeBSD.org Message-id: <0HBC00G5NZ9MHC@mta5.snfc21.pbi.net> MIME-version: 1.0 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 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 You could try adjusting the net.inet.tcp.msl sysctl down from its default of 30 seconds. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 6 20:56:58 2003 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 EE87E37B401 for ; Thu, 6 Mar 2003 20:56:56 -0800 (PST) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C60E43FAF for ; Thu, 6 Mar 2003 20:56:55 -0800 (PST) (envelope-from ikostov@otel.net) Received: from judicator.otel.net ([212.36.9.113]) by mail.otel.net with esmtp (Exim 3.36 #1) id 18r9uV-000B0C-00; Fri, 07 Mar 2003 06:56:43 +0200 Date: Fri, 7 Mar 2003 06:56:42 +0200 (EET) From: Iasen Kostov To: "J. W. Ballantine" Cc: Kevin_Stevens@pursued-with.net, Subject: Re: route pointing to a gateway that's not on net In-Reply-To: <200303051912.h25JCUF05694@akiva.homer.att.com> Message-ID: <20030307065558.W52594-100000@shadowhand.OTEL.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 Use : route add -net 10.17.47.37/32 -cloning -iface xl0 that sould work. On Wed, 5 Mar 2003, J. W. Ballantine wrote: > > Sorry, my typo. I did try > route add -net 10.0.0.0 -interface xl0 > and > route add -net 10.17.47.37 -interface xl0 > > As I recall both didn't respond with a error message, but when I tried to > get out it didn't work. > > I'll try again tonight and see what happens. > > Thanks > > ---------- In Response to your message ------------- > > > Date: Wed, 5 Mar 2003 10:47:30 -0800 (PST) > > To: > > From: "Kevin Stevens" > > Subject: Re: route pointing to a gateway that's not on net > > > > > > > Well it's not the way I wanted it, but it's the way I have to try and > > > work with. > > > > > > I tried the route add net 10.0.0.0 -interface (whatever) > > > and that didn't work for me. > > > > That's not the syntax I gave you, and obviously it needs to have your > > local interface information inserted. I can confirm that the command: > > > > route add -net 10.0.0.0 -interface em0 > > > > does parse and operate correctly on my 4.7 system, as confirmed by netstat > > -nr. That is the general approach for directing traffic out a local > > interface rather than to a same-subnet gateway. > > > > Try looking at man route for the details, or perhaps someone else will > > respond with a higher level of hand-holding. > > > > KeS > > > > > > > > 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 Mar 6 23:57:27 2003 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 2EF8D37B401; Thu, 6 Mar 2003 23:57:25 -0800 (PST) Received: from www6.mailru.com (www6.mailru.com [80.68.244.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78DAB43FCB; Thu, 6 Mar 2003 23:57:24 -0800 (PST) (envelope-from denb@front.ru) Received: by HotBOX.Ru WebMail v2.1 id h2780hWF058395 for ; Date: Fri, 7 Mar 2003 11:00:43 +0300 (MSK) Message-Id: <200303070800.h2780hWF058395@www6.mailru.com> From: denb To: freebsd-net@FreeBSD.ORG Cc: ipfw@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit X-Mailer: Free WebMail HotBOX.ru X-Proxy-IP: [212.1.229.5] X-Originating-IP: [172.16.0.103] Subject: Why natd don't divert packets? 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 Why natd don't divert packets? *********screenshot*********************** #ipfw add divert 1111 tcp from any to any 7 #ipfw add divert 1111 tcp from any 7 to any #natd -v -p 1111 -a 172.16.0.102 -redirect_port tcp 172.16.0.253:7 7 In [TCP] [TCP] 172.16.0.104:49169 -> 172.16.0.102:7 aliased to [TCP] 172.16.0.104:49169 -> 172.16.0.253:7 In [TCP] [TCP] 172.16.0.104:49169 -> 172.16.0.102:7 aliased to [TCP] 172.16.0.104:49169 -> 172.16.0.253:7 ^C *********screenshot*********************** Where is Out[TCP]? Rules after natd running (why second rule has 0 in packets number?): *********screenshot*********************** #ipfw show 0001 6 180 divert 1111 tcp from any to any dst-port 7 0002 0 0 divert 1111 tcp from any 7 to any *********screenshot*********************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 7 2:11:12 2003 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 1D8D637B401 for ; Fri, 7 Mar 2003 02:11:10 -0800 (PST) Received: from pipenetworks.com (cartman.pipenetworks.com [202.4.251.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA99D43FB1 for ; Fri, 7 Mar 2003 02:11:08 -0800 (PST) (envelope-from steve@pipenetworks.com) Received: (from root@localhost) by pipenetworks.com (8.11.6/8.11.2) id h27A2nE19654; Fri, 7 Mar 2003 20:02:49 +1000 From: Steve Baxter Received: from internal.pipenetworks.com (internal.pipenetworks.com [10.10.10.1]) by pipenetworks.com (8.11.6/8.11.2) with ESMTP id h27A2nV19621; Fri, 7 Mar 2003 20:02:49 +1000 Received: from internal (internal [10.10.10.1]) by internal.pipenetworks.com (8.11.6/8.11.2) with ESMTP id h27ANaR29087; Fri, 7 Mar 2003 20:23:37 +1000 Date: Fri, 7 Mar 2003 20:23:36 +1000 (EST) To: freebsd-net@freebsd.org Cc: Chris Foote Subject: is there a better way to bridge ethernet over IP (some performance stats included) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-scanner: nil by mouth 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, Currently I am using FreeBSD 4.7STABLE on a Sokris net4521. The SOEKRIS has an equivilent 486-133 chip in it so it is not especially speedy. I am using vtund and netgraph to bridge over IP in the following configuration : LAN The bridging works well, it will bridge 10Mb/sec one direction | which is a series of wgets of a large gzipped file. |tap +----------+ I thought it was suffering some or all of : | SOEKRIS | +----------+ o packets over 1500 bytes need to get fragmented adding to CPU | load |IP o vtund is a user space app | o netgraph *may* also be user space +----------+ o tap device processing overhead maybe | SOEKRIS | +----------+ I have reduced the MTU in order to make the MTU issue go away, |tap as a result little or no fragments were sent but this had no | effect on the CPU untilisation of the SOEKRIS box. | This also had no positive effect on the throughput :-( LAN I went from netgraph to sysctl bridging and this had little of no effect as well. I am looking for a way to bridge ether over IP that does not require a user process to do it, maybe an all netgraph method of of encapsulating ethernet frames into udp and then striping them out at the other end ? I have looked at the netgraph examples and am essentially using the ethernet example for my netgraph bridging, it is just that I am using vtund to do the encapsulation of packets. Does any body have any ideas on how to directly encapsulate ethernet frames onto udp without vtund or similar user process ? Cheers, SB -- Stephen Baxter Director - PIPE Networks phone : 07 3220 1100/ 0417 818 695 fax : 07 3220 1800 ______________________________________ PIPE Networks/IX Services Australia disclaimer The above email should be read in conjunction with our standard disclaimer/terms which can be found at : http://www.pipenetworks.com/docs/disclaimer.htm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 7 5:55: 8 2003 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 09ABB37B401 for ; Fri, 7 Mar 2003 05:55:06 -0800 (PST) Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9282C43F85 for ; Fri, 7 Mar 2003 05:55:04 -0800 (PST) (envelope-from jwb@homer.att.com) Received: from ulysses.homer.att.com ([135.205.193.8]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h27Dt2Fl012573; Fri, 7 Mar 2003 07:55:02 -0600 (CST) Received: from akiva.homer.att.com (akiva.homer.att.com [135.205.212.39]) by ulysses.homer.att.com (8.9.3/8.9.3) with ESMTP id IAA03285; Fri, 7 Mar 2003 08:55:01 -0500 (EST) Received: from akiva.homer.att.com (localhost [127.0.0.1]) by akiva.homer.att.com (8.11.6+Sun/8.9.3) with ESMTP id h27Dt0304504; Fri, 7 Mar 2003 08:55:00 -0500 (EST) Message-Id: <200303071355.h27Dt0304504@akiva.homer.att.com> X-Mailer: exmh version 2.6.1 02/18/2003 with nmh-1.0.4 To: Kevin_Stevens@pursued-with.net Cc: freebsd-net@FreeBSD.ORG Subject: Re: route pointing to a gateway that's not on net In-reply-to: Your message of "Wed, 05 Mar 2003 10:47:30 PST." <12883.192.85.47.2.1046890050.squirrel@new.host.name> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Mar 2003 08:55:00 -0500 From: "J. W. Ballantine" 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 OK, I tried your advice: FreeBSD 4.8 PRERELEASE #2 kernel boots and since dhcp fails I only get the local loopback: >Script started on Thu Mar 6 14:42:44 2003 ># netstat -nr >Routing tables > >Internet: >Destination Gateway Flags Refs Use Netif Expire >127.0.0.1 127.0.0.1 UH 0 0 lo0 > I add the route as your advise and it add the net gateway ># route add -net 10.0.0.0 -interface xl0 >add net 10.0.0.0: gateway xl0 ># netstat -nr >Routing tables > >Internet: >Destination Gateway Flags Refs Use Netif Expire >10 00:01:02:54:ca:dd USc 0 0 xl0 >127.0.0.1 127.0.0.1 UH 0 0 lo0 > Now I configure my card with the assigned address and it added it ># ifconfig xl0 inet 209.122.66.XXX netmask 255.255.255.0 ># netstat -nr >Routing tables > >Internet: >Destination Gateway Flags Refs Use Netif Expire >10 00:01:02:54:ca:dd USc 0 0 xl0 >127.0.0.1 127.0.0.1 UH 0 0 lo0 >209.122.66 link#1 UC 0 0 xl0 > Finally I try and ping the assigned DHCP server (ie cable modem) and I get no route to host. What is needed to associate the 10 network gateway with 209.122.66.XXX address assigned to my machine??? ># ping 10.17.47.37 >PING 10.17.47.37 (10.17.47.37): 56 data bytes >ping: sendto: No route to host >ping: sendto: No route to host >ping: sendto: No route to host >ping: sendto: No route to host >^C >--- 10.17.47.37 ping statistics --- >4 packets transmitted, 0 packets received, 100% packet loss ># exit > >Script done on Thu Mar 6 14:49:29 2003 I also tried it using 10.17.47.37 as the route add -net and reversed the order of the route and ifocnfig command, same result. Thanks for any help/handholding. ---------- In Response to your message ------------- > Date: Wed, 5 Mar 2003 10:47:30 -0800 (PST) > To: > From: "Kevin Stevens" > Subject: Re: route pointing to a gateway that's not on net > > > > Well it's not the way I wanted it, but it's the way I have to try and > > work with. > > > > I tried the route add net 10.0.0.0 -interface (whatever) > > and that didn't work for me. > > That's not the syntax I gave you, and obviously it needs to have your > local interface information inserted. I can confirm that the command: > > route add -net 10.0.0.0 -interface em0 > > does parse and operate correctly on my 4.7 system, as confirmed by netstat > -nr. That is the general approach for directing traffic out a local > interface rather than to a same-subnet gateway. > > Try looking at man route for the details, or perhaps someone else will > respond with a higher level of hand-holding. > > KeS > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message