From owner-freebsd-net Sun Mar 3 8:10:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from serv1.is1.u-net.net (serv1.is1.u-net.net [195.102.240.129]) by hub.freebsd.org (Postfix) with ESMTP id A356437B400; Sun, 3 Mar 2002 08:10:25 -0800 (PST) Received: from [62.30.181.162] (helo=the-rubber-chicken-network.co.uk) by serv1.is1.u-net.net with smtp (Exim 3.12 #1) id 16hYZ4-0003lm-00; Sun, 03 Mar 2002 16:10:22 +0000 From: Mike Woods To: freebsd-questions@freebsd.org, freebsd-net@freebsd.org Date: Sun, 14 Apr 2024 21:10:33 +0100 Message-ID: X-Mailer: YAM 2.2 [040] AmigaOS E-Mail Client (c) 1995-2000 by Marcel Beck http://www.yam.ch Subject: NFS odditiy MIME-Version: 1.0 Content-Type: text/plain Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Right, first of all let me state that im somewhat of a unix newbie (having only been using it for 3 weeks or so) so i might be missing something obvoius here. Ok, first my netwrok setup, im running Freebsd 4.4 on a p90 with 48mb and a nice chunky 40gb hard drive, this is my file server (called bitch), now my client machines are a windows 2000 box and my amiga a4000. On Bitch there is a partition called /Store which im sharing with the network, my exports file reads /Store -alldirs -maproot=0 192.68.0.1 192.168.0.2 i can mount this share on both machines with no problem i can read/write into /Store/Mp3 and /Store/Filter... but, i cant read/write into /Store itself although i can browse /Store, thus far all the literature ive read seems to say i shouldnt be having this problem. Any ideas ? -- Mike Woods WoA SE Webmonkey & General Dogsbody Amiga North Thames Webmaster & Games Co-ordinator ------------------------------------------------------------------- World Of Amiga SE - http://www.worldofamiga.com Amiga North Thames - Http://www.AmigaNorthThames.co.uk HomePage - Http://www.planetheck.co.uk/~damnation Micronik Busboards Support - Http://www.microniksupport.n3.net ICQ uin - 86410172 ------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 3 8:36:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from sage-one.net (adsl-64-219-20-209.dsl.crchtx.swbell.net [64.219.20.209]) by hub.freebsd.org (Postfix) with ESMTP id 162A137B417; Sun, 3 Mar 2002 08:36:17 -0800 (PST) Received: from SAGEONE (sageone [192.168.0.5]) by sage-one.net (8.11.6/8.11.6) with SMTP id g23GaEp11963; Sun, 3 Mar 2002 10:36:15 -0600 (CST) (envelope-from admin@sage-one.net) Message-Id: <3.0.5.32.20020303103613.011ce1b8@mail.sage-one.net> X-Sender: admin@mail.sage-one.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sun, 03 Mar 2002 10:36:13 -0600 To: Mike Woods , freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG From: Server Admin Subject: Re: NFS odditiy In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Do you have "rw" set for /store in the /etc/fstab...??? At 09:10 PM 4.14.2024 +0100, Mike Woods wrote: >Right, first of all let me state that im somewhat of a unix newbie (having >only been using it for 3 weeks or so) so i might be missing something >obvoius here. > >Ok, first my netwrok setup, im running Freebsd 4.4 on a p90 with 48mb and a >nice chunky 40gb hard drive, this is my file server (called bitch), now my >client machines are a windows 2000 box and my amiga a4000. > >On Bitch there is a partition called /Store which im sharing with the >network, my exports file reads > >/Store -alldirs -maproot=0 192.68.0.1 192.168.0.2 i can mount this share on >both machines with no problem i can read/write into /Store/Mp3 and >/Store/Filter... but, i cant read/write into /Store itself although i can >browse /Store, thus far all the literature ive read seems to say i shouldnt >be having this problem. > >Any ideas ? > >-- >Mike Woods >WoA SE Webmonkey & General Dogsbody >Amiga North Thames Webmaster & Games Co-ordinator >------------------------------------------------------------------- >World Of Amiga SE - http://www.worldofamiga.com >Amiga North Thames - Http://www.AmigaNorthThames.co.uk >HomePage - Http://www.planetheck.co.uk/~damnation >Micronik Busboards Support - Http://www.microniksupport.n3.net >ICQ uin - 86410172 >------------------------------------------------------------------- > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-questions" in the body of the message > > .... our website: http://www.sage-one.net/ Best regards, Jack L. Stone Server Admin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 3 14:47:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from ns1.hexanet.fr (ns1.hexanet.fr [194.98.140.1]) by hub.freebsd.org (Postfix) with ESMTP id E90E837B404 for ; Sun, 3 Mar 2002 14:47:43 -0800 (PST) Received: from freak.rural (speedfreak.hexanet.fr [194.98.140.14]) by ns1.hexanet.fr (8.9.3/8.9.3) with ESMTP id XAA69969 for ; Sun, 3 Mar 2002 23:47:43 +0100 (CET) (envelope-from c.prevotaux@hexanet.fr) Received: from freak (locahost.rural [127.0.0.1]) by freak.rural (8.11.6/8.11.6) with SMTP id g23MlBN00447 for ; Sun, 3 Mar 2002 23:47:12 +0100 (CET) (envelope-from c.prevotaux@hexanet.fr) Date: Sun, 3 Mar 2002 23:47:11 +0100 From: Christophe Prevotaux To: net@freebsd.org Subject: UDLR on FreeBSD Message-Id: <20020303234711.30af96c4.c.prevotaux@hexanet.fr> Organization: HEXANET X-Mailer: Sylpheed version 0.7.1 (GTK+ 1.2.8; i386--freebsd4.5) 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 Is anyone working on implementing UDLR in FreeBSD Current or Stable ? This would be a really usefull thing. RFC 3077 <--- UDLR RFC -- =================================================================== Christophe Prevotaux Email: chris@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A Farman Sud Tel: +33 (0)3 26 79 30 05 9 rue Roland Coffignot Direct: +33 (0)3 26 79 08 02 BP415 Fax: +33 (0)3 26 79 30 06 51689 Reims Cedex 2 FRANCE =================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 3 15: 5:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from ns1.hexanet.fr (ns1.hexanet.fr [194.98.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 9E58937B419 for ; Sun, 3 Mar 2002 15:05:35 -0800 (PST) Received: from freak.rural (speedfreak.hexanet.fr [194.98.140.14]) by ns1.hexanet.fr (8.9.3/8.9.3) with ESMTP id AAA70071 for ; Mon, 4 Mar 2002 00:05:34 +0100 (CET) (envelope-from c.prevotaux@hexanet.fr) Received: from freak (locahost.rural [127.0.0.1]) by freak.rural (8.11.6/8.11.6) with SMTP id g23N46N00507 for ; Mon, 4 Mar 2002 00:05:04 +0100 (CET) (envelope-from c.prevotaux@hexanet.fr) Date: Mon, 4 Mar 2002 00:04:05 +0100 From: Christophe Prevotaux To: net@freebsd.org Subject: More on UDLR Message-Id: <20020304000405.551fd8fa.c.prevotaux@hexanet.fr> Organization: HEXANET X-Mailer: Sylpheed version 0.7.1 (GTK+ 1.2.8; i386--freebsd4.5) 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 If someone is willing to reintegrate all of this in FreeBSD Stable or Current in order to have native UDLR support on FreeBSD. http://www-sop.inria.fr/rodeo/personnel/eduros/ http://www.udcast.com/udlr/ http://www-sop.inria.fr/rodeo/personnel/eduros/index-dvb.html I suggest interested people also look at things like ftp://ftp.ietf.org/rfc/rfc3077.txt Unidirectional path support would be a very interesting thing to have in order to devellop rural or remote areas internet access and more.... -- =================================================================== Christophe Prevotaux Email: chris@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A Farman Sud Tel: +33 (0)3 26 79 30 05 9 rue Roland Coffignot Direct: +33 (0)3 26 79 08 02 BP415 Fax: +33 (0)3 26 79 30 06 51689 Reims Cedex 2 FRANCE =================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 3 15:20:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by hub.freebsd.org (Postfix) with SMTP id 7CA4A37B402 for ; Sun, 3 Mar 2002 15:20:57 -0800 (PST) Received: (qmail 12067 invoked from network); 3 Mar 2002 23:20:56 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (66.92.188.241) by 0 with SMTP; 3 Mar 2002 23:20:56 -0000 Message-ID: <3C82AFD8.5020102@tenebras.com> Date: Sun, 03 Mar 2002 15:20:56 -0800 From: Michael Sierchio Reply-To: kudzu@tenebras.com User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.8) Gecko/20020218 X-Accept-Language: en-us MIME-Version: 1.0 To: Christophe Prevotaux Cc: net@freebsd.org Subject: Re: UDLR on FreeBSD References: <20020303234711.30af96c4.c.prevotaux@hexanet.fr> 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 Christophe Prevotaux wrote: > Is anyone working on implementing UDLR in FreeBSD Current or Stable ? > This would be a really usefull thing. > > RFC 3077 <--- UDLR RFC Have you contacted the RFC authors? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 3 17:42:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from garfield.bmk.com.au (bmkind.lnk.telstra.net [139.130.51.118]) by hub.freebsd.org (Postfix) with ESMTP id 27C8337B400 for ; Sun, 3 Mar 2002 17:42:34 -0800 (PST) Received: from localhost (brendan@localhost) by garfield.bmk.com.au (8.9.3/8.9.3) with SMTP id MAA13587 for ; Mon, 4 Mar 2002 12:42:31 +1100 (EST) (envelope-from brendan@bmk.com.au) Date: Mon, 4 Mar 2002 12:42:29 +1100 (EST) From: Brendan Kosowski To: FreeBSD Networking Subject: How can I give one route priority over the other route ? 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 In situations where there are 2 routes in your routing table that apply to a given destination IP address, how do you give one route priority over the other ? Regards, Brendan... ------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 3 17:48:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from artemis.drwilco.net (diana.drwilco.net [66.48.127.79]) by hub.freebsd.org (Postfix) with ESMTP id 9CF1537B400 for ; Sun, 3 Mar 2002 17:48:26 -0800 (PST) Received: from ceres.drwilco.net (docwilco.xs4all.nl [213.84.68.230]) by artemis.drwilco.net (8.11.6/8.11.6) with ESMTP id g241mDV24690 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Sun, 3 Mar 2002 20:48:17 -0500 (EST) (envelope-from drwilco@drwilco.net) Message-Id: <5.1.0.14.0.20020304025555.02c9eac8@mail.drwilco.net> X-Sender: lists@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 04 Mar 2002 02:59:04 +0100 To: Brendan Kosowski , FreeBSD Networking From: "Rogier R. Mulhuijzen" Subject: Re: How can I give one route priority over the other route ? In-Reply-To: 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 At 12:42 4-3-2002 +1100, Brendan Kosowski wrote: >In situations where there are 2 routes in your routing table that apply to >a given destination IP address, how do you give one route priority over >the other ? The one with the widest netmask is used. So if you have both 10.0.0.0/8 and 10.42.69.0/24 in your routing table and for instance a packet needs to go to 10.42.69.13 the latter is used. Doc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 3 18:10:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from m2.mv.meer.net (mail.meer.net [209.157.152.14]) by hub.freebsd.org (Postfix) with ESMTP id 42F0B37B404 for ; Sun, 3 Mar 2002 18:10:54 -0800 (PST) Received: from neville-neil.com ([209.157.133.226]) by m2.mv.meer.net (8.12.1/8.12.1/meer) with ESMTP id g242ARBu093357; Sun, 3 Mar 2002 18:10:27 -0800 (PST) Message-Id: <200203040210.g242ARBu093357@m2.mv.meer.net> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "Rogier R. Mulhuijzen" Cc: Brendan Kosowski , FreeBSD Networking Subject: Re: How can I give one route priority over the other route ? In-Reply-To: Message from "Rogier R. Mulhuijzen" of "Mon, 04 Mar 2002 02:59:04 +0100." <5.1.0.14.0.20020304025555.02c9eac8@mail.drwilco.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 03 Mar 2002 18:10:36 -0800 From: "George V. Neville-Neil" 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 situations where there are 2 routes in your routing table that apply to > >a given destination IP address, how do you give one route priority over > >the other ? > > The one with the widest netmask is used. > > So if you have both 10.0.0.0/8 and 10.42.69.0/24 in your routing table and > for instance a packet needs to go to 10.42.69.13 the latter is used. > Alas this is not what the writer is asking for. This is an issue with the routing system design. Many routers allow duplicate routes (same netmask) that have different priorities. This makes it quicker to switch routes during a failure. At the moment, the only way to do this in *BSD that I know if is to hack the sources and add sysctl/ioctls to address this. There is a derivative implementation that puts a list of addresses at each node but that's not the best solution. Later, George -- George V. Neville-Neil gnn@neville-neil.com NIC:GN82 "Those who would trade liberty for temporary security deserve neither" - Benjamin Franklin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 3 18:16:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by hub.freebsd.org (Postfix) with ESMTP id 9387F37B400 for ; Sun, 3 Mar 2002 18:16:44 -0800 (PST) Received: from elischer.org ([64.170.121.0]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GSF00EBVFNVUT@mta7.pltn13.pbi.net> for net@freebsd.org; Sun, 03 Mar 2002 18:16:44 -0800 (PST) Date: Sun, 03 Mar 2002 18:15:29 -0800 From: Julian Elischer Subject: Re: More on UDLR To: Christophe Prevotaux Cc: net@freebsd.org Message-id: <3C82D8C1.2DD2ADAE@elischer.org> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) Content-type: text/plain; charset=iso-8859-2 Content-transfer-encoding: 7BIT X-Accept-Language: en, hu References: <20020304000405.551fd8fa.c.prevotaux@hexanet.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 Christophe Prevotaux wrote: > > If someone is willing to reintegrate all of this > in FreeBSD Stable or Current in order to have > native UDLR support on FreeBSD. > > http://www-sop.inria.fr/rodeo/personnel/eduros/ > http://www.udcast.com/udlr/ > http://www-sop.inria.fr/rodeo/personnel/eduros/index-dvb.html > > I suggest interested people also look at things like > > ftp://ftp.ietf.org/rfc/rfc3077.txt > > Unidirectional path support would be a very interesting thing > to have in order to devellop rural or remote areas internet access > and more.... I only skimmed over the RFC but it looks like it would be almost trivial to impliment this in Netgraph, using exisiting nodes to separate the packets and deliver then to/from a special 3077 node. > > -- > =================================================================== > Christophe Prevotaux Email: chris@hexanet.fr > HEXANET SARL URL: http://www.hexanet.fr/ > Z.A Farman Sud Tel: +33 (0)3 26 79 30 05 > 9 rue Roland Coffignot Direct: +33 (0)3 26 79 08 02 > BP415 Fax: +33 (0)3 26 79 30 06 > 51689 Reims Cedex 2 > FRANCE > =================================================================== > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 3 21:15: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id F18D137B400 for ; Sun, 3 Mar 2002 21:15:04 -0800 (PST) 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 VAA70509; Sun, 3 Mar 2002 21:00:42 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g2450MZ29580; Sun, 3 Mar 2002 21:00:22 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200203040500.g2450MZ29580@arch20m.dellroad.org> Subject: Re: no more buffer problems yes!! In-Reply-To: "from Julian Elischer at Mar 1, 2002 10:58:32 am" To: Julian Elischer Date: Sun, 3 Mar 2002 21:00:22 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Julian Elischer writes: > ok, so if thre is a new version cooking, can we co-operate with > adding radius to it? (using PAP)? It's not 'cooking' that fast... :-) Perhaps thawing is a better word... -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 3 23:21:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by hub.freebsd.org (Postfix) with ESMTP id 8D1CD37B400; Sun, 3 Mar 2002 23:21:24 -0800 (PST) Received: from compaq ([64.165.200.80]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GSF009RUTRO0P@mta5.snfc21.pbi.net>; Sun, 03 Mar 2002 23:21:24 -0800 (PST) Date: Sun, 03 Mar 2002 23:30:20 -0800 From: Koroush Saraf Subject: Routing question, Routed using one interface To: freebsd-net@freebsd.org Cc: freebsd-questions@freebsd.org Message-id: <004a01c1c34e$70d1af20$50c8a540@compaq> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Mailer: Microsoft Outlook Express 5.00.3018.1300 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20020227145812.F425-200000@brain.cc.rsu.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 Hi All, I like to know why when I turn on ROUTED on my machines they don't discover the attached subnets to the link. The scenario is below: I' have several bsd computers each with one network card. All the computers sit on a shared Ethernet. I like to perform some routing simulations comparing ospf and rip. So I have setup the computers so that each NIC has several IP address aliases assigned. When I turn on ROUTED I see a few hello packets exchanged and very so often I see an IGMP multicast for the router discovery protocol. However, the routing tables remain as they were before I turnon ROUTED. So basically the aliased NIC IP addresses are not being advertised. Can you tell me how I can make routing work through these aliased addresses? Also I have addressed my computers in the 10.x.x.x range which is the private IP address range and not internet routable. Does ROUTED care about the range of addresses in use or all IP addresses are using in the routing table as valid routable addresses. Just wanted to make sure this wasn't my problem. Thanks in advance for taking the time to suggest solution, ~Koroush Saraf To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 3 23:28:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from senator.nodewarrior.org (senator.nodewarrior.org [216.243.168.27]) by hub.freebsd.org (Postfix) with ESMTP id 834C037B400 for ; Sun, 3 Mar 2002 23:28:33 -0800 (PST) Received: from discus.nodewarrior.org (discus [192.168.1.20]) by senator.nodewarrior.org (Postfix) with ESMTP id DB8F521C75; Mon, 4 Mar 2002 01:28:28 -0600 (CST) From: Dan Debertin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15491.8758.497061.87297@gargle.gargle.HOWL> Date: Mon, 4 Mar 2002 01:28:54 -0600 To: Koroush Saraf Cc: freebsd-net@freebsd.org Subject: Re: Routing question, Routed using one interface In-Reply-To: <004a01c1c34e$70d1af20$50c8a540@compaq> References: <20020227145812.F425-200000@brain.cc.rsu.ru> <004a01c1c34e$70d1af20$50c8a540@compaq> X-Mailer: VM 7.00 under Emacs 21.1.1 X-Meat: Turkey Jerky 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 > Also I have addressed my computers in the 10.x.x.x range which is the > private IP address range and not internet routable. Does ROUTED care about > the range of addresses in use or all IP addresses are using in the routing > table as valid routable addresses. Just wanted to make sure this wasn't my > problem. RIP is a classful routing protocol. So if the only network you're using is 10/8, then each machine running routed will advertise a route for 10/8, which will be discarded by every other machine because they already have a connected route for that network. Try using a few different (classful) networks on each machine. Dan -- Dan Debertin airboss@nodewarrior.org www.nodewarrior.org 3ffe:2900:1100:2::2 There is no magic. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 3 23:57:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailhost.mlnet.net (mailhost.mlnet.net [194.217.128.21]) by hub.freebsd.org (Postfix) with ESMTP id DCE3F37B402 for ; Sun, 3 Mar 2002 23:57:51 -0800 (PST) Received: (from postie@localhost) by mailhost.mlnet.net (8.8.8/8.8.8) id HAA13330; Mon, 4 Mar 2002 07:56:16 GMT Received: from dhcp172.nominet.org.uk(194.205.67.172) by mailhost via smap (V2.1) id xma013312; Mon, 4 Mar 02 07:55:42 GMT Message-ID: <3C83282A.2849E051@mlnet.net> Date: Mon, 04 Mar 2002 07:54:18 +0000 From: Matthew Reply-To: m@mlnet.net X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brendan Kosowski Cc: FreeBSD Networking Subject: Re: How can I give one route priority over the other route ? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org IMHO, this should be done by the routing protocol of your choice rather than by the kernel. I recommend checking out www.zebra.org for the zebra routing protocol suite which includes OSPF, BGP, RIP The syntax is very cisco like. I use BGP out of personal preference - all you need to do is add weights to your neighbors to give priority to a peer. M Brendan Kosowski wrote: > > In situations where there are 2 routes in your routing table that apply to > a given destination IP address, how do you give one route priority over > the other ? > > Regards, Brendan... > > ------------------- > > 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 4 2:56:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from bart.esiee.fr (bart.esiee.fr [147.215.1.20]) by hub.freebsd.org (Postfix) with ESMTP id 1525537B402 for ; Mon, 4 Mar 2002 02:56:07 -0800 (PST) Received: (from bonnetf@localhost) by bart.esiee.fr (8.11.4/8.11.4) id g24Au5t08473 for freebsd-net@freebsd.org; Mon, 4 Mar 2002 11:56:05 +0100 (MET) Date: Mon, 4 Mar 2002 11:56:05 +0100 From: Frank Bonnet To: freebsd-net@freebsd.org Subject: date statement in icmp-response bandwidth limit message ? Message-ID: <20020304115605.A8446@bart.esiee.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi would it be possible to add a date statement in the "icmp-response bandwidth limit" written in the console to better track such problem ? Thanks a lot. -- Frank Bonnet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 4 4:11:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.spc.org (insomnia.spc.org [195.224.94.183]) by hub.freebsd.org (Postfix) with SMTP id DDBBB37B404 for ; Mon, 4 Mar 2002 04:11:23 -0800 (PST) Received: (qmail 20657 invoked by uid 1031); 4 Mar 2002 12:00:23 -0000 Date: Mon, 4 Mar 2002 12:00:23 +0000 From: Bruce M Simpson To: Adrian Penisoara Cc: freebsd-net@freebsd.org, altq@csl.sony.co.jp, snap-users@kame.net Subject: Re: ALTQ integration in FreeBSD Message-ID: <20020304120022.D2325@spc.org> Mail-Followup-To: Bruce M Simpson , Adrian Penisoara , freebsd-net@freebsd.org, altq@csl.sony.co.jp, snap-users@kame.net References: 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 ady@freebsd.ady.ro on Sat, Mar 02, 2002 at 12:36:49PM +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 Sat, Mar 02, 2002 at 12:36:49PM +0200, Adrian Penisoara wrote: > Hi, > > For my diploma exam I will study the state of QoS in today's > networking and further directions and I probably will concentrate on > ALTQ in FreeBSD (as I'm pretty familiar w/ FreeBSD). > > I see that most of today's OSes have a default QoS implementation (at > least Win2000 and OpenBSD come to my mind) and there is a growing need > for QoS integration into the OS. I was wondering what kept FreeBSD from > integrating a QoS implementation (as it did with Kame IPv6) -- for > example what are pro and cons of integration ALTQ in FreeBSD (I saw > there was a thread launched sometime in the beginning of May 2001). I > also saw that ALTQ on FreeBSD seems to be used pretty much even in > production. > > What other QoS implementation alternatives are available for FreeBSD ? > Why didn't FreeBSD follow tracks along OpenBSD's integration of ALTQ ? You might want to check out the materials on Lucent's ECLIPSE project, which added layer 2 and 3 QoS as well as disk I/O scheduling to FreeBSD 3.x. http://www.bell-labs.com/project/eclipse/release/ BMS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 4 4:18: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from proton.hexanet.fr (proton.hexanet.fr [194.98.140.18]) by hub.freebsd.org (Postfix) with ESMTP id 2AFE837B405 for ; Mon, 4 Mar 2002 04:18:03 -0800 (PST) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.11.6/8.11.6) with SMTP id g24CHvc01652; Mon, 4 Mar 2002 13:17:57 +0100 (CET) (envelope-from c.prevotaux@hexanet.fr) Date: Mon, 4 Mar 2002 13:17:57 +0100 From: Christophe =?ISO-8859-1?B?UHLpdm90YXV4?= To: kudzu@tenebras.com Cc: net@freebsd.org Subject: Re: UDLR on FreeBSD Message-Id: <20020304131757.3c9b822f.c.prevotaux@hexanet.fr> In-Reply-To: <3C82AFD8.5020102@tenebras.com> References: <20020303234711.30af96c4.c.prevotaux@hexanet.fr> <3C82AFD8.5020102@tenebras.com> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i386--freebsd4.4) X-NCC-RegID: fr.hexanet 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 Yes I have ,but Emmanuel Duros is now running a company called UDCAST that makes its money off using UDLR.So they are not willing to contribute to FreeBSD any code other than what they have already contributed while at INRIA On Sun, 03 Mar 2002 15:20:56 -0800 Michael Sierchio wrote: > Christophe Prevotaux wrote: > > Is anyone working on implementing UDLR in FreeBSD Current or Stable ? > > This would be a really usefull thing. > > > > RFC 3077 <--- UDLR RFC > > Have you contacted the RFC authors? > -- =================================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 79 08 02 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE =================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 4 4:26:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from proton.hexanet.fr (proton.hexanet.fr [194.98.140.18]) by hub.freebsd.org (Postfix) with ESMTP id 50AC937B402 for ; Mon, 4 Mar 2002 04:26:20 -0800 (PST) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.11.6/8.11.6) with SMTP id g24CQEc01683; Mon, 4 Mar 2002 13:26:14 +0100 (CET) (envelope-from c.prevotaux@hexanet.fr) Date: Mon, 4 Mar 2002 13:26:14 +0100 From: Christophe =?ISO-8859-1?B?UHLpdm90YXV4?= To: Julian Elischer Cc: net@freebsd.org Subject: Re: More on UDLR Message-Id: <20020304132614.57588f06.c.prevotaux@hexanet.fr> In-Reply-To: <3C82D8C1.2DD2ADAE@elischer.org> References: <20020304000405.551fd8fa.c.prevotaux@hexanet.fr> <3C82D8C1.2DD2ADAE@elischer.org> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i386--freebsd4.4) X-NCC-RegID: fr.hexanet 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 On Sun, 03 Mar 2002 18:15:29 -0800 Julian Elischer wrote: > Christophe Prevotaux wrote: > > > > If someone is willing to reintegrate all of this > > in FreeBSD Stable or Current in order to have > > native UDLR support on FreeBSD. > > > > http://www-sop.inria.fr/rodeo/personnel/eduros/ > > http://www.udcast.com/udlr/ > > http://www-sop.inria.fr/rodeo/personnel/eduros/index-dvb.html > > > > I suggest interested people also look at things like > > > > ftp://ftp.ietf.org/rfc/rfc3077.txt > > > > Unidirectional path support would be a very interesting thing > > to have in order to devellop rural or remote areas internet access > > and more.... > > > I only skimmed over the RFC but it looks like it would be almost trivial > to impliment this in Netgraph, using exisiting nodes to separate the packets > and deliver then to/from a special 3077 node. That would be really cool , however I am not a programmer, but I still think this is something that would be really usefull. UDLR has been implemented in VxWorks , Mentat TCP etc... all of these guys are using BSD but they are not contributing anything back into BSD , I know this is their right to do so, but UDLR is something that everyone could use. For example, you could use any system with a slow uplink (or no uplink) bandwidth and a fast return channel in order to provide lightning fast internet access in remote areas. You could also deliver Newsgroups or source code or any other kind of data to a large group of users. Imagine a FreeBSD source CVSup live multicast. People would just have to plug in their satellite dish with a DVB revceiver card (provided there are any drivers for FreeBSD) and then would start receiving FreeBSD code source change etc.... Of course in many areas like USA this is useless because almost everyone has access to broadband internet , but in other less fortunate areas of the world this would likely be used very much. Not only this but also Mailing list and Newsgroups this would save a lot of bandwidth :) Even Emails or binary patch could be delivered this way, also security alerts :) -- =================================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 79 08 02 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE =================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 4 4:29:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from proton.hexanet.fr (proton.hexanet.fr [194.98.140.18]) by hub.freebsd.org (Postfix) with ESMTP id DBA7F37B400 for ; Mon, 4 Mar 2002 04:29:19 -0800 (PST) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.11.6/8.11.6) with SMTP id g24CTIc01698 for ; Mon, 4 Mar 2002 13:29:19 +0100 (CET) (envelope-from c.prevotaux@hexanet.fr) Date: Mon, 4 Mar 2002 13:29:18 +0100 From: Christophe =?ISO-8859-1?B?UHLpdm90YXV4?= To: net@freebsd.org Subject: UDLR Message-Id: <20020304132918.19b00442.c.prevotaux@hexanet.fr> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i386--freebsd4.4) X-NCC-RegID: fr.hexanet 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 This is also something that it could be used with : http://www.worldspace.com/ -- =================================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 79 08 02 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE =================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 4 6:49: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from odin.egate.net (as2.dm.egate.net [216.235.1.5]) by hub.freebsd.org (Postfix) with ESMTP id 9DBA237B402; Mon, 4 Mar 2002 06:48:39 -0800 (PST) Received: from as2.dm.egate.net (as2.dm.egate.net [216.235.1.5]) by odin.egate.net (8.11.6/8.11.4) with ESMTP id g24Emc985680; Mon, 4 Mar 2002 09:48:38 -0500 (EST) Date: Mon, 4 Mar 2002 09:48:38 -0500 (EST) From: Ryan Morris To: Cc: FreeBSD User Questions List Subject: Re: Multiple connections to MPD-netgraph as PPTP server In-Reply-To: <1015112907.73601.9.camel@shumai.marcuscom.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 I solved my own problem... it turns out that my naming conventions caused an issue when MPD labelled the PPP node. It truncated the bundle names at 8 characters, and since mine were 8 characters plus a number following the truncated names for all the links were identical, and it refused to load them. It was naming them like so: [pptp0] ppp node is "mpd50391-pptpbund" -- should have been mpd50391-pptpbundle0 [pptp1] ppp node is "mpd50391-pptpbund" -- should have been mpd50391-pptpbundle1 Now it names them like so: "mpd50391-pptp0" "mpd50391-pptp1" in my mpd.conf I changed this: ---------- pptp0: new -i ng0 pptpbundle0 pptplink0 ... pptp1: new -i ng1 pptpbundle1 pptplink1 ... ---------- to this: ---------- pptp0: new -i ng0 pptp0 pptplink0 ... pptp1: new -i ng1 pptp1 pptplink1 ... ---------- And now it works fine :) So the moral of the story is: don't make your bundle names identical over 8 characters... Thanks for everyone's help (especially Julian for his method to simplify the mpd.conf file!) Best regards, Ryan Morris --- "Some mornings, it's just not worth chewing through the leather straps." - Emo Philips On 2 Mar 2002, Joe Clarke wrote: > On Sat, 2002-03-02 at 18:25, Michele Possamai wrote: > > What if you change the self ipaddress in mpd.links? > > they are the same in both connections > > In my setup the pptp self address is always the same, but it isn't the > same address I use as the server VPN endpoint address. > > For my setup, I use the following in mpd.conf: > > load pptpuser1 > load pptpuser2 > > pptpuser1: > new -i ng0 pptp1 pptp1 > set iface disable on-demand > set iface enable proxy-arp > set iface idle 1800 > set bundle disable multilink > set link yes acfcomp protocomp > set link no pap chap > set link enable chap > set link keep-alive 10 60 > set ipcp yes vjcomp > set ipcp ranges 192.168.100.1/32 192.168.100.246/32 > set ipcp dns 192.168.100.1 > set ipcp nbns 192.168.100.1 > set bundle enable compression > set ccp yes mppc > set ccp yes mpp-e40 > set ccp yes mpp-e128 > set ccp yes mpp-stateless > > pptpuser2: > new -i ng1 pptp2 pptp2 > set iface disable on-demand > set iface enable proxy-arp > set iface idle 1800 > set bundle disable multilink > set link yes acfcomp protocomp > set link no pap chap > set link enable chap > set link keep-alive 10 60 > set ipcp yes vjcomp > set ipcp ranges 192.168.100.1/32 192.168.100.247/32 > set ipcp dns 192.168.100.1 > set ipcp nbns 192.168.100.1 > set bundle enable compression > set ccp yes mppc > set ccp yes mpp-e40 > set ccp yes mpp-e128 > set ccp yes mpp-stateless > > Then, for the .links entries: > > pptp1: > set link type pptp > set pptp self 63.x.x.x > set pptp enable incoming > set pptp disable originate > > pptp2: > set link type pptp > set pptp self 63.x.x.x > set pptp enable incoming > set pptp disable originate > > The 63.x.x.x address is the public external address, and 192.168.100.1 > is my server VPN endpoint address as well as my internal IP address on > my LAN. > > Joe > > > > > On Fri, 1 Mar 2002, Ryan Morris wrote: > > > > > Hello everyone, > > > > > > I recently (successfully) configured MPD-netgraph as a pptp server on my > > > FreeBSD machine. It works great... for one user. When I change my > > > configuration to support multiple PPTP bundles/links I get the following > > > error when starting mpd: > > > > > > bsd# mpd > > > Multi-link PPP for FreeBSD, by Archie L. Cobbs. > > > Based on iij-ppp, by Toshiharu OHNO. > > > mpd: pid 518, version 3.7 (root@bsd.imagineering.ca 16:39 28-Feb-2002) > > > [pptpbundle0] ppp node is "mpd518-pptpbund" > > > mpd: local IP address for PPTP is 192.168.0.253 > > > [pptpbundle0] using interface ng0 > > > [pptpbundle1] can't name ppp node: Address already in use > > > [pptpbundle1] netgraph initialization failed > > > > > > I have varied the IP address assignments in my configuration files, and > > > examples on the web have duplicated IP addresses between bundles without > > > causing this problem. > > > > > > Does this make reference to the ppp node name (mpd518-pptpbund)? And if > > > so, how do I change what the ppp node name will be? > > > > > > Best regards, > > > > > > Ryan Morris > > > > > > > > > Here are my configuration files: > > > --- > > > mpd.conf: > > > > > > default: > > > load pptp0 > > > load pptp1 > > > > > > pptp0: > > > new -i ng0 pptpbundle0 pptplink0 > > > set iface disable on-demand > > > set iface enable proxy-arp > > > set iface idle 1800 > > > set bundle disable multilink > > > set link yes acfcomp protocomp > > > set link no pap chap > > > set link enable chap > > > set link keep-alive 10 60 > > > set ipcp yes vjcomp > > > set ipcp ranges 192.168.0.253/32 192.168.0.128/29 > > > set ipcp dns 192.168.0.1 > > > set ipcp nbns 192.168.0.253 > > > #Enable Microsoft Point-to-Point Encryption: > > > set bundle enable compression > > > set ccp yes mppc > > > set ccp no mpp-e40 > > > set ccp yes mpp-e128 > > > set ccp no mpp-stateless > > > > > > pptp1: > > > new -i ng1 pptpbundle1 pptplink1 > > > set iface disable on-demand > > > set iface enable proxy-arp > > > set iface idle 1800 > > > set bundle disable multilink > > > set link yes acfcomp protocomp > > > set link no pap chap > > > set link enable chap > > > set link keep-alive 10 60 > > > set ipcp yes vjcomp > > > set ipcp ranges 192.168.0.252/32 192.168.0.128/29 > > > set ipcp dns 192.168.0.1 > > > set ipcp nbns 192.168.0.253 > > > #Enable Microsoft Point-to-Point Encryption: > > > set bundle enable compression > > > set ccp yes mppc > > > set ccp no mpp-e40 > > > set ccp yes mpp-e128 > > > set ccp no mpp-stateless > > > > > > # END > > > > > > --- > > > mpd.links: > > > > > > pptplink0: > > > set link type pptp > > > set pptp self 192.168.0.253 > > > set pptp enable incoming > > > set pptp disable originate > > > > > > pptplink1: > > > set link type pptp > > > set pptp self 192.168.0.253 > > > set pptp enable incoming > > > set pptp disable originate > > > > > > #END > > > > > > --- > > > "Some mornings, it's just not worth chewing through the leather straps." > > > - Emo Philips > > > > > > > > > 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-questions" 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 4 9:20:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailgw3a.lmco.com (mailgw3a.lmco.com [192.35.35.24]) by hub.freebsd.org (Postfix) with ESMTP id C6D3337B400; Mon, 4 Mar 2002 09:20:15 -0800 (PST) Received: from emss01g01.ems.lmco.com ([129.197.181.54]) by mailgw3a.lmco.com (8.11.6/8.11.6) with ESMTP id g24HKDo00234; Mon, 4 Mar 2002 12:20:13 -0500 (EST) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-33 #38886) id <0GSG00D01LGSEW@lmco.com>; Mon, 4 Mar 2002 09:19:40 -0800 (PST) Received: from BSDWIN2KKOROUSH ([129.197.23.48]) by lmco.com (PMDF V5.2-33 #38886) with SMTP id <0GSG002WBLGNV5@lmco.com>; Mon, 04 Mar 2002 09:19:37 -0800 (PST) Date: Mon, 04 Mar 2002 09:19:24 -0800 From: Koroush Saraf Subject: Re: Routing question, Routed using one interface (more info) To: Koroush Saraf , freebsd-net@FreeBSD.ORG Cc: freebsd-questions@FreeBSD.ORG Message-id: <008c01c1c3a0$bb140680$3017c581@BSDWIN2KKOROUSH> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20020227145812.F425-200000@brain.cc.rsu.ru> <004a01c1c34e$70d1af20$50c8a540@compaq> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm making a new post to attach the network diagram in order to clarify my question. I have several bsd4.3 computers each with one NIC on a shared LAN as below: +-------------+ |10.1.1.1/24 | | +--+ | | | +-------------+ | | +-------------+ | |10.1.1.2/24 | | |10.2.2.2/24 +--+ | | | +-------------+ | | +-------------+ | |10.2.2.3/24 | | |10.3.3.3/24 +--+ | | | +-------------+ | | +-------------+ | |10.3.3.4/24 | | | +--+ | | +-------------+ Now I like to turn on Routed, and have the approperiate routes discovered. Then from the 10.1.1.1 computer I like to be able to run traceroute to the 10.3.3.4 computer and see the following: 10.1.1.1 <-> 10.1.1.2 <->10.2.2.3<->10.3.3.4 currently I've tried this, but the routing is not being discovered and the routing table remains unchanged. There are no default routes either. Can you tell me if this is possible? and if so what I need to do to get it to work? > Hi All, > I like to know why when I turn on ROUTED on my machines they don't discover > the attached subnets to the link. The scenario is below: > > I' have several bsd computers each with one network card. All the computers > sit on a shared Ethernet. I like to perform some routing simulations > comparing ospf and rip. So I have setup the computers so that each NIC has > several IP address aliases assigned. When I turn on ROUTED I see a few > hello packets exchanged and very so often I see an IGMP multicast for the > router discovery protocol. However, the routing tables remain as they were > before I turnon ROUTED. So basically the aliased NIC IP addresses are not > being advertised. Can you tell me how I can make routing work through these > aliased addresses? > Also I have addressed my computers in the 10.x.x.x range which is the > private IP address range and not internet routable. Does ROUTED care about > the range of addresses in use or all IP addresses are using in the routing > table as valid routable addresses. Just wanted to make sure this wasn't my > problem. > Thanks in advance for taking the time to suggest solution, > ~Koroush Saraf > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" 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 4 9:23: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id DDD1337B400 for ; Mon, 4 Mar 2002 09:22:58 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020304172258.LYJW1147.rwcrmhc52.attbi.com@blossom.cjclark.org>; Mon, 4 Mar 2002 17:22:58 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g24HMwB87775; Mon, 4 Mar 2002 09:22:58 -0800 (PST) (envelope-from cjc) Date: Mon, 4 Mar 2002 09:22:58 -0800 From: "Crist J. Clark" To: Frank Bonnet Cc: freebsd-net@FreeBSD.ORG Subject: Re: date statement in icmp-response bandwidth limit message ? Message-ID: <20020304092258.C87533@blossom.cjclark.org> References: <20020304115605.A8446@bart.esiee.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020304115605.A8446@bart.esiee.fr>; from bonnetf@bart.esiee.fr on Mon, Mar 04, 2002 at 11:56:05AM +0100 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Mar 04, 2002 at 11:56:05AM +0100, Frank Bonnet wrote: > Hi > > would it be possible to add a date statement > in the "icmp-response bandwidth limit" written > in the console to better track such problem ? That's what syslogd(8) is for. If you are using a default syslog.conf(5), those messages will be in /var/log/messages. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 4 9:36:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from senator.nodewarrior.org (senator.nodewarrior.org [216.243.168.27]) by hub.freebsd.org (Postfix) with ESMTP id B1D9237B416; Mon, 4 Mar 2002 09:36:07 -0800 (PST) Received: from senator.nodewarrior.org.nodewarrior.org (senator [216.243.168.27]) by senator.nodewarrior.org (Postfix) with ESMTP id 0F2EB21C7A; Mon, 4 Mar 2002 11:36:06 -0600 (CST) From: Dan Debertin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15491.45188.985601.625000@senator.nodewarrior.org> Date: Mon, 4 Mar 2002 11:36:04 -0600 To: Koroush Saraf Cc: Koroush Saraf , freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Routing question, Routed using one interface (more info) In-Reply-To: <008c01c1c3a0$bb140680$3017c581@BSDWIN2KKOROUSH> References: <20020227145812.F425-200000@brain.cc.rsu.ru> <004a01c1c34e$70d1af20$50c8a540@compaq> <008c01c1c3a0$bb140680$3017c581@BSDWIN2KKOROUSH> X-Mailer: VM 6.95 under Emacs 21.1.1 X-Drdoom-Fodder: crash satan passwd security drdoom crypt CERT 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 As I have said before. RIP (routed) won't announce a 10.x.x.x network address, regardless of your VLSM netmask, as anything but 255.0.0.0, i.e. 10/8. You may be able to work around this using RIPv2. I haven't played with FreeBSD's implementation of it. Otherwise, using RIPv1, try using several different classful networks on each machine instead of just one. Koroush Saraf writes: > Now I like to turn on Routed, and have the approperiate routes discovered. > Then from the 10.1.1.1 computer I like to be able to run traceroute to the > 10.3.3.4 computer and see the following: > 10.1.1.1 <-> 10.1.1.2 <->10.2.2.3<->10.3.3.4 Dan -- Dan Debertin airboss@nodewarrior.org www.nodewarrior.org 3ffe:2900:1100:2::2 There is no magic. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 4 9:38:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by hub.freebsd.org (Postfix) with SMTP id 551B937B402 for ; Mon, 4 Mar 2002 09:38:36 -0800 (PST) Received: (qmail 14298 invoked from network); 4 Mar 2002 17:38:35 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (66.92.188.241) by 0 with SMTP; 4 Mar 2002 17:38:35 -0000 Message-ID: <3C83B11B.3060306@tenebras.com> Date: Mon, 04 Mar 2002 09:38:35 -0800 From: Michael Sierchio Reply-To: kudzu@tenebras.com User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.8) Gecko/20020218 X-Accept-Language: en-us MIME-Version: 1.0 To: Koroush Saraf Cc: Koroush Saraf , freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Routing question, Routed using one interface (more info) References: <20020227145812.F425-200000@brain.cc.rsu.ru> <004a01c1c34e$70d1af20$50c8a540@compaq> <008c01c1c3a0$bb140680$3017c581@BSDWIN2KKOROUSH> 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 Koroush Saraf wrote: > I have several bsd4.3 computers each with one NIC on a shared LAN as below: Well, on a shared link layer network... > Now I like to turn on Routed, and have the approperiate routes discovered. what options are you invoking routed with? do you have firewall enabled? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 4 11: 6: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by hub.freebsd.org (Postfix) with SMTP id E019B37B400 for ; Mon, 4 Mar 2002 11:05:43 -0800 (PST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Mon Mar 4 14:04:20 EST 2002 Received: from aura.research.bell-labs.com (aura.research.bell-labs.com [135.104.46.10]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g24J41k13347 for ; Mon, 4 Mar 2002 14:04:01 -0500 (EST) Received: from fgupcmh (fgu-pcmh.research.bell-labs.com [135.104.47.121]) by aura.research.bell-labs.com (8.9.1/8.9.1) with SMTP id OAA04678 for ; Mon, 4 Mar 2002 14:04:00 -0500 (EST) Reply-To: From: "Fengrui Gu" To: Subject: Queue size limitation in dummynet Date: Mon, 4 Mar 2002 14:08:20 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3C83B11B.3060306@tenebras.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 When trying to set queue size (>100) with ipfw, I found ipfw actually hard-coded the queue size limit to 100. I am trying to simulation network link with very high delay and relatively low bandwidth. However, I don't want to suffer packet drops. So I need a large queue size. Can anyone tell me why 100 is the limitation? Is there any problem if I increase the number, e.g., 200? 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 4 11:28:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from ns1.interbgc.com (mail.interbgc.com [217.9.224.3]) by hub.freebsd.org (Postfix) with SMTP id 6A2A337B405 for ; Mon, 4 Mar 2002 11:28:37 -0800 (PST) Received: (qmail 50178 invoked by uid 1005); 4 Mar 2002 19:28:31 -0000 Received: from misho@interbgc.com by keeper.interbgc.com with qmail-scanner-1.01 (uvscan: v4.0.50/v4183. . Clean. Processed in 0.79911 secs); 04 Mar 2002 19:28:31 -0000 Received: from unknown (HELO joiner) (217.9.226.238) by mail.interbgc.com with SMTP; 4 Mar 2002 19:28:30 -0000 Message-ID: <001201c1c3b3$72de0600$eee209d9@cablebg.net> Reply-To: "Mihail Balikov" From: "Mihail Balikov" To: References: Subject: Re: Queue size limitation in dummynet Date: Mon, 4 Mar 2002 21:33:23 +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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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, Can you recommend me HSSI and sync. serian cards (V.35) for FreeBSD with support of Frame-Relay and HDLC regards, Mihail Balikov To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 4 11:59:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailgw3a.lmco.com (mailgw3a.lmco.com [192.35.35.24]) by hub.freebsd.org (Postfix) with ESMTP id E6ECD37B405; Mon, 4 Mar 2002 11:59:16 -0800 (PST) Received: from emss01g01.ems.lmco.com ([129.197.181.54]) by mailgw3a.lmco.com (8.11.6/8.11.6) with ESMTP id g24JxCo15880; Mon, 4 Mar 2002 14:59:13 -0500 (EST) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-33 #38886) id <0GSG00E01SUNLY@lmco.com>; Mon, 4 Mar 2002 11:59:11 -0800 (PST) Received: from BSDWIN2KKOROUSH ([129.197.23.48]) by lmco.com (PMDF V5.2-33 #38886) with SMTP id <0GSG00NKMSUILY@lmco.com>; Mon, 04 Mar 2002 11:59:06 -0800 (PST) Date: Mon, 04 Mar 2002 11:59:06 -0800 From: Koroush Saraf Subject: Re: Routing question, Routed using one interface (more info) To: kudzu@tenebras.com Cc: freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Message-id: <002d01c1c3b7$0a36a770$3017c581@BSDWIN2KKOROUSH> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20020227145812.F425-200000@brain.cc.rsu.ru> <004a01c1c34e$70d1af20$50c8a540@compaq> <008c01c1c3a0$bb140680$3017c581@BSDWIN2KKOROUSH> <3C83B11B.3060306@tenebras.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 Since I have a single nic card I invoke the following: routed -s I also have used the flags -P pm_rdisc and -P rdisc_interval=45, but I think that's irrelevant at this moment. Also I do not have any firewalling enabled. ----- Original Message ----- From: "Michael Sierchio" To: "Koroush Saraf" Cc: "Koroush Saraf" ; ; Sent: Monday, March 04, 2002 9:38 AM Subject: Re: Routing question, Routed using one interface (more info) > Koroush Saraf wrote: > > > I have several bsd4.3 computers each with one NIC on a shared LAN as below: > > Well, on a shared link layer network... > > > Now I like to turn on Routed, and have the approperiate routes discovered. > > what options are you invoking routed with? do you have firewall enabled? > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 4 12:18:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by hub.freebsd.org (Postfix) with SMTP id 0CE6C37B405 for ; Mon, 4 Mar 2002 12:18:16 -0800 (PST) Received: (qmail 15045 invoked from network); 4 Mar 2002 20:17:37 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (66.92.188.241) by 0 with SMTP; 4 Mar 2002 20:17:37 -0000 Message-ID: <3C83D661.2050209@tenebras.com> Date: Mon, 04 Mar 2002 12:17:37 -0800 From: Michael Sierchio Reply-To: kudzu@tenebras.com User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.8) Gecko/20020218 X-Accept-Language: en-us MIME-Version: 1.0 To: Koroush Saraf Cc: freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Routing question, Routed using one interface (more info) References: <20020227145812.F425-200000@brain.cc.rsu.ru> <004a01c1c34e$70d1af20$50c8a540@compaq> <008c01c1c3a0$bb140680$3017c581@BSDWIN2KKOROUSH> <3C83B11B.3060306@tenebras.com> <002d01c1c3b7$0a36a770$3017c581@BSDWIN2KKOROUSH> 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 Koroush Saraf wrote: > Since I have a single nic card I invoke the following: > routed -s > I also have used the flags -P pm_rdisc and -P rdisc_interval=45, but I think > that's irrelevant at this moment. As someone else noted, you'll need ripv2. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 4 16:40:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 2C29037B400; Mon, 4 Mar 2002 16:40:14 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020305004009.RZVV2951.rwcrmhc53.attbi.com@InterJet.elischer.org>; Tue, 5 Mar 2002 00:40:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA28009; Mon, 4 Mar 2002 16:23:39 -0800 (PST) Date: Mon, 4 Mar 2002 16:23:37 -0800 (PST) From: Julian Elischer To: Ryan Morris Cc: freebsd-net@freebsd.org, FreeBSD User Questions List Subject: Re: Multiple connections to MPD-netgraph as PPTP server In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 4 Mar 2002, Ryan Morris wrote: > I solved my own problem... it turns out that my naming conventions caused > an issue when MPD labelled the PPP node. It truncated the bundle names at > 8 characters, and since mine were 8 characters plus a number following the > truncated names for all the links were identical, and it refused to load > them. > I guess this needs noting in the ppp docs Soem limits may be inherrited from Netgraph too. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 4 21:30:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 5FEEC37B416; Mon, 4 Mar 2002 21:30:15 -0800 (PST) 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 VAA78079; Mon, 4 Mar 2002 21:16:24 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g255Fr033139; Mon, 4 Mar 2002 21:15:53 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200203050515.g255Fr033139@arch20m.dellroad.org> Subject: Re: Multiple connections to MPD-netgraph as PPTP server In-Reply-To: "from Julian Elischer at Mar 4, 2002 04:23:37 pm" To: Julian Elischer Date: Mon, 4 Mar 2002 21:15:53 -0800 (PST) Cc: Ryan Morris , freebsd-net@FreeBSD.ORG, FreeBSD User Questions List X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Julian Elischer writes: > > I solved my own problem... it turns out that my naming conventions caused > > an issue when MPD labelled the PPP node. It truncated the bundle names at > > 8 characters, and since mine were 8 characters plus a number following the > > truncated names for all the links were identical, and it refused to load > > them. > > I guess this needs noting in the ppp docs > Soem limits may be inherrited from Netgraph too. This problem has bitten me in several different situations. We should increase NG_TYPELEN, NG_HOOKLEN, and NG_NODELEN from 15 to, say 63. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 5 2:17: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by hub.freebsd.org (Postfix) with ESMTP id 9AA1737B405 for ; Tue, 5 Mar 2002 02:17:02 -0800 (PST) Received: by hanoi.cronyx.ru id NAA21973 for freebsd-net@FreeBSD.ORG.checked; (8.9.3/vak/2.1) Tue, 5 Mar 2002 13:14:04 +0300 (MSK) (envelope-from rik@cronyx.ru) Received: from cronyx.ru by hanoi.cronyx.ru with ESMTP id NAA21928; (8.9.3/vak/2.1) Tue, 5 Mar 2002 13:13:52 +0300 (MSK) (envelope-from rik@cronyx.ru) Message-ID: <3C849B68.5010408@cronyx.ru> Date: Tue, 05 Mar 2002 13:18:16 +0300 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Mihail Balikov Cc: freebsd-net@FreeBSD.ORG Subject: Re: Queue size limitation in dummynet References: <001201c1c3b3$72de0600$eee209d9@cablebg.net> 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 Hi, Mihail Balikov wrote: >Hi, > >Can you recommend me HSSI and sync. serian cards (V.35) for FreeBSD with >support of Frame-Relay and HDLC > http://www.cronyx.ru/hardware/taupci.html http://www.cronyx.ru/hardware/taupg703.html http://www.cronyx.ru/hardware/taupe1.html http://www.cronyx.ru/hardware/sigma22.html We also plan to release HSSI card in future. Best regards, Roman Kurakin > > >regards, >Mihail Balikov > > > >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 5 4: 2:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from freddy.inty.net (freddy.inty.net [195.224.93.243]) by hub.freebsd.org (Postfix) with ESMTP id B5C0C37B400 for ; Tue, 5 Mar 2002 04:02:13 -0800 (PST) Received: from inty.hq.inty.net (inty.hq.inty.net [213.38.150.150]) by freddy.inty.net (8.11.3/8.11.3) with ESMTP id g25BjnO99891 for ; Tue, 5 Mar 2002 11:45:57 GMT Received: from tariq ([10.0.1.156]) by inty.hq.inty.net (8.12.1/8.12.1) with SMTP id g25Bji0C092190 for ; Tue, 5 Mar 2002 11:45:44 GMT From: "Tariq Rashid" To: Subject: racoon and pgpnet "virtual identities"? Date: Tue, 5 Mar 2002 11:47:54 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <5.1.0.14.2.20020219204129.00b5aa20@outshine> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Sender-IP: 10.0.1.156 X-INT-DeliveryDone: g25Bji0C092190 X-suppress-rcpt-virus-notify: yes X-Skip-Virus-Check: yes X-Virus-Checked: 49057 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 not kept up to date with racoon since late last year - is it now possible to use racoon with PGPnet roaming clients and use the "acquire virtual identity" option? I think the protocol is called isamkp-cfg or ike-cfg. regards tariq intY has automatically scanned this email with Sophos Anti-Virus (www.inty.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 5 5:44:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from web20102.mail.yahoo.com (web20102.mail.yahoo.com [216.136.226.39]) by hub.freebsd.org (Postfix) with SMTP id EABAF37B402 for ; Tue, 5 Mar 2002 05:44:17 -0800 (PST) Message-ID: <20020305134417.51019.qmail@web20102.mail.yahoo.com> Received: from [212.234.238.114] by web20102.mail.yahoo.com via HTTP; Tue, 05 Mar 2002 05:44:17 PST Date: Tue, 5 Mar 2002 05:44:17 -0800 (PST) From: ome ome Subject: mpd and bpf node 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, What is the aim of the bpf node in MPD ? __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.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 5 10: 0:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 8D94337B416 for ; Tue, 5 Mar 2002 10:00:15 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020305180015.TMUF1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Tue, 5 Mar 2002 18:00:15 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA31669; Tue, 5 Mar 2002 09:53:51 -0800 (PST) Date: Tue, 5 Mar 2002 09:53:50 -0800 (PST) From: Julian Elischer To: ome ome Cc: freebsd-net@freebsd.org Subject: Re: mpd and bpf node In-Reply-To: <20020305134417.51019.qmail@web20102.mail.yahoo.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 The bpf node acts as a programmable packet filter, able to divert packets according to a program loaded into it using the normal bpf virtual machine. see man ng_bpf for more details. On Tue, 5 Mar 2002, ome ome wrote: > Hi, > > What is the aim of the bpf node in MPD ? > > __________________________________________________ > Do You Yahoo!? > Try FREE Yahoo! Mail - the world's greatest free email! > http://mail.yahoo.com/ > > 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 5 13:52:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from artemis.drwilco.net (diana.drwilco.net [66.48.127.79]) by hub.freebsd.org (Postfix) with ESMTP id A04A937B416 for ; Tue, 5 Mar 2002 13:52:39 -0800 (PST) Received: from ceres.drwilco.net (docwilco.xs4all.nl [213.84.68.230]) by artemis.drwilco.net (8.11.6/8.11.6) with ESMTP id g25LqXV12025 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Tue, 5 Mar 2002 16:52:35 -0500 (EST) (envelope-from drwilco@drwilco.net) Message-Id: <5.1.0.14.0.20020305230137.01c3a7c0@mail.drwilco.net> X-Sender: lists@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 05 Mar 2002 23:03:24 +0100 To: Julian Elischer , ome ome From: "Rogier R. Mulhuijzen" Subject: Re: mpd and bpf node Cc: freebsd-net@FreeBSD.ORG In-Reply-To: References: <20020305134417.51019.qmail@web20102.mail.yahoo.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 At 09:53 5-3-2002 -0800, Julian Elischer wrote: >The bpf node acts as a programmable packet filter, able to divert >packets according to a program loaded into it using the normal >bpf virtual machine. > >see >man ng_bpf for more details. What Julian means is, the bpf node is used to route some packets that need attention of the mpd daemon to it, and leave the other packets alone. /me grins at Julian Doc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 5 14:40:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 74D4337B41D for ; Tue, 5 Mar 2002 14:40:08 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020305224008.VUQY2951.rwcrmhc53.attbi.com@InterJet.elischer.org>; Tue, 5 Mar 2002 22:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA32852; Tue, 5 Mar 2002 14:30:51 -0800 (PST) Date: Tue, 5 Mar 2002 14:30:50 -0800 (PST) From: Julian Elischer To: "Rogier R. Mulhuijzen" Cc: ome ome , freebsd-net@FreeBSD.ORG Subject: Re: mpd and bpf node In-Reply-To: <5.1.0.14.0.20020305230137.01c3a7c0@mail.drwilco.net> 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 ummm yeah.. On Tue, 5 Mar 2002, Rogier R. Mulhuijzen wrote: > At 09:53 5-3-2002 -0800, Julian Elischer wrote: > >The bpf node acts as a programmable packet filter, able to divert > >packets according to a program loaded into it using the normal > >bpf virtual machine. > > > >see > >man ng_bpf for more details. > > What Julian means is, the bpf node is used to route some packets that need > attention of the mpd daemon to it, and leave the other packets alone. > > /me grins at Julian > > Doc > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 5 22:35: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from kanga.honeypot.net (kanga.honeypot.net [208.162.254.109]) by hub.freebsd.org (Postfix) with ESMTP id DAED137B402 for ; Tue, 5 Mar 2002 22:34:56 -0800 (PST) Received: from pooh.int (pooh.int [10.0.1.2]) by kanga.honeypot.net (8.11.6/8.11.6) with ESMTP id g266YtI01175 for ; Wed, 6 Mar 2002 00:34:55 -0600 (CST) (envelope-from kirk@strauser.com) Received: (from kirk@localhost) by pooh.int (8.11.6/8.11.6) id g266YtH22306; Wed, 6 Mar 2002 00:34:55 -0600 (CST) (envelope-from kirk@strauser.com) To: freebsd-net@FreeBSD.ORG Subject: Solution found (was My DNS is giving wrong answers (sometimes)) References: <87u1s1tmct.fsf@pooh.int> From: Kirk Strauser Date: 06 Mar 2002 00:33:39 -0600 In-Reply-To: <87u1s1tmct.fsf@pooh.int> Message-ID: <871yey19z0.fsf@pooh.int> Lines: 15 X-Mailer: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 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 At 2002-02-28T19:52:50Z, Kirk Strauser writes: > Basically, if I query $host.honeypot.net, and $host is defined, then I > always get the answer of kanga.honeypot.net's own IP. I don't *think* it > would matter, but I'm on a permanent DSL connection with a static IP, and my > LAN (and kanga.honeypot.net itself) is numbered in the 10/8 netblock. My > Cisco 678 router is handling NAT, with dynamic mapped outbound connections, > and a small set of static mapped inbound rules (DNS, SMTP, HTTP, etc.). For those interested, the problem was that my new Cisco 678 CPE router was re-writing outbound DNS packets. Why? Darned if I know. Anyway, the problem was solved, and FreeBSD is blameless. -- Kirk Strauser To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 6 0:42:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 3817237B400 for ; Wed, 6 Mar 2002 00:42:12 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g268ftx83874; Wed, 6 Mar 2002 00:41:55 -0800 (PST) (envelope-from rizzo) Date: Wed, 6 Mar 2002 00:41:54 -0800 From: Luigi Rizzo To: Fengrui Gu Cc: freebsd-net@FreeBSD.ORG Subject: Re: Queue size limitation in dummynet Message-ID: <20020306004154.B83775@iguana.icir.org> References: <3C83B11B.3060306@tenebras.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i 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 04, 2002 at 02:08:20PM -0500, Fengrui Gu wrote: > When trying to set queue size (>100) with ipfw, > I found ipfw actually hard-coded the queue size limit to 100. > > I am trying to simulation network link with very high delay and relatively > low bandwidth. However, I don't want to suffer packet drops. So I need a > large queue size. > > Can anyone tell me why 100 is the limitation? Is there any problem if I > increase the number, e.g., 200? there is no problem in increasing the max queue size, i just had to set a limit somewhere... but i agree that 100 is probably too low, especially these days when machines have tons of memory. I will try to bump up the limit in the future. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 6 12:29:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 3175037B419 for ; Wed, 6 Mar 2002 12:29:47 -0800 (PST) Received: (from jgreco@localhost) by aurora.sol.net (8.9.3/8.9.2/SNNS-1.02) id OAA54251; Wed, 6 Mar 2002 14:29:25 -0600 (CST) From: Joe Greco Message-Id: <200203062029.OAA54251@aurora.sol.net> Subject: Re: Luigi's polling code and 4.5R To: rizzo@icir.org (Luigi Rizzo) Date: Wed, 6 Mar 2002 14:29:25 -0600 (CST) Cc: freebsd-net@freebsd.org In-Reply-To: <20020202092954.B65442@iguana.icir.org> from "Luigi Rizzo" at Feb 02, 2002 09:29:55 AM X-Mailer: ELM [version 2.5 PL3] 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 > what is curious is that I am using a 4-port D-link on our > test boxes as primary development cards and they do not seem > to freeze. The card uses 21143 and seems quite reliable. > > I know of a bug in the code on my web site whose symptoms look like > a freeze, but that is presumably related to a race in delivering > softisr's and so should be card independent and appear with the > fxp's as well -- as a matter of fact i first hit it with the "sis" > card. As a datapoint, I applied the 4.5R patch (rather than the pre-RELEASE patch) and it works as expected. And very nicely I must say. :-) -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 6 12:50:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from big.uwaterloo.ca (styx.uwaterloo.ca [129.97.105.10]) by hub.freebsd.org (Postfix) with ESMTP id 0104337B400 for ; Wed, 6 Mar 2002 12:50:55 -0800 (PST) Received: from localhost (bmukherj@localhost) by big.uwaterloo.ca (8.11.0/8.11.0) with ESMTP id g26KojL24670 for ; Wed, 6 Mar 2002 15:50:45 -0500 Date: Wed, 6 Mar 2002 15:50:45 -0500 (EST) From: Roop Mukherjee To: Subject: netgraph for slip or 802.11 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 am wondering if there is any chance that someone has implemented netgraph nodes for slip or 802.11 interfaces? If so I would appreciate any pointers. -- Roop ________________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 6 13: 0:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 61BAD37B402 for ; Wed, 6 Mar 2002 13:00:15 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020306210015.EJHU2951.rwcrmhc53.attbi.com@InterJet.elischer.org>; Wed, 6 Mar 2002 21:00:15 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA37961; Wed, 6 Mar 2002 12:59:14 -0800 (PST) Date: Wed, 6 Mar 2002 12:59:13 -0800 (PST) From: Julian Elischer To: Roop Mukherjee Cc: freebsd-net@freebsd.org Subject: Re: netgraph for slip or 802.11 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org no, as far as I kow neither has been done. I'm intersted in knowing exactly what you mena by 802.11 in netgraph.. Do you mean the Beaconning etc, needed for AP operation? On Wed, 6 Mar 2002, Roop Mukherjee wrote: > I am wondering if there is any chance that someone has implemented > netgraph nodes for slip or 802.11 interfaces? If so I would appreciate any > pointers. > > -- Roop > ________________________________________ > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 6 13:23:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from noos.fr (r168m18.cybercable.tm.fr [195.132.168.18]) by hub.freebsd.org (Postfix) with ESMTP id E1E7E37B400 for ; Wed, 6 Mar 2002 13:22:50 -0800 (PST) Received: (from mux@localhost) by noos.fr (8.11.6/8.11.4) id g26LMoW02575 for freebsd-net@FreeBSD.org; Wed, 6 Mar 2002 22:22:50 +0100 (CET) (envelope-from mux) Date: Wed, 6 Mar 2002 22:22:49 +0100 From: Maxime Henrion To: freebsd-net@FreeBSD.org Subject: [CFR] Patch for clonable interfaces Message-ID: <20020306212249.GC2371@nebula.noos.fr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline User-Agent: Mutt/1.3.24i 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 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, Currently, every clonable interface which uses the if_clone_*() framework has a chunk of duplicated rman code to handle unit allocation. This is exactly the same code in every clonable interface driver. Moreover, this code is only used in the case of a "wildcard" creation, i.e. when the user does "ifconfig gif create" without specifying an unit number. The other necessary checks (to not create an already-existing interface, or to not remove a non-existing one) are already done in the generic layer. The intent of this patch is to move all the unit allocation code into the generic layer to avoid all the duplicated code. This code doesn't use rman, for several reasons. First, rman returns a struct resource * pointer for every unit allocated, which has to be stored somewhere in order to deallocate the unit later. This is problematic since the generic layer doesn't maintain per-clone structures, so it would have to pass it down to the interface-dependant code and have it store it for us, or to maintain another set of per-clone structures. Both solutions are gross and really unbeautiful. Second, rman can fail and return an error, but our if_clone_{attach,detach} functions are void at the moment and cannot fail. That's why I chosed to implement unit allocation using a bitmap. It's fast, and much cleaner than rman here. It also allows us to keep our if_clone_{attach,detach} functions void. The current code has only one problem that I know of, it's not very space-efficient. The driver passes the maximum allowed unit number to the generic code and thus avoid allocation a big bitmap if the interface wants only one clone (e.g. if_stf), but most drivers will pass IF_MAXUNIT (0x7fff) which requires a 4K bitmap. A future improvement could be to allocate chunks of bitmaps on demand rather than one big bitmap, but I'm not sure if it's really needed. Note that having the unit management code into the generic layer implies that you can't bypass it, otherwise it would result in bitmaps inconsistencies. However, it is still OK to call the foo_clone_destroy() functions directly at module unload, unless I'm missing something here :-) Any reviews or comments are appreciated. Thanks, Maxime --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="net.patch" Index: if.c =================================================================== RCS file: /home/ncvs/src/sys/net/if.c,v retrieving revision 1.132 diff -u -r1.132 if.c --- if.c 5 Mar 2002 17:50:35 -0000 1.132 +++ if.c 6 Mar 2002 19:45:54 -0000 @@ -119,6 +119,7 @@ MALLOC_DEFINE(M_IFADDR, "ifaddr", "interface address"); MALLOC_DEFINE(M_IFMADDR, "ether_multi", "link-level multicast address"); +MALLOC_DEFINE(M_CLONE, "clone", "interface cloning framework"); #define CDEV_MAJOR 165 @@ -580,7 +581,7 @@ { struct if_clone *ifc; char *dp; - int wildcard; + int wildcard, bytoff, bitoff; int unit; int err; @@ -591,12 +592,41 @@ if (ifunit(name) != NULL) return (EEXIST); + bytoff = bitoff = 0; wildcard = (unit < 0); + /* + * Find a free unit if none was given. + */ + if (wildcard) { + while ((bytoff < ifc->ifc_bmlen) + && (ifc->ifc_units[bytoff] == 0xff)) + bytoff++; + if (bytoff >= ifc->ifc_bmlen) + return (ENOSPC); + while ((ifc->ifc_units[bytoff] & (1 << bitoff)) != 0) + bitoff++; + unit = (bytoff << 3) + bitoff; + } + + if (unit > ifc->ifc_maxunit) + return (ENXIO); - err = (*ifc->ifc_create)(ifc, &unit); + err = (*ifc->ifc_create)(ifc, unit); if (err != 0) return (err); + if (!wildcard) { + bytoff = unit >> 3; + bitoff = unit - (bytoff << 3); + } + + /* + * Allocate the unit in the bitmap. + */ + KASSERT((ifc->ifc_units[bytoff] & (1 << bitoff)) == 0, + ("%s: bit is already set", __func__)); + ifc->ifc_units[bytoff] |= (1 << bitoff); + /* In the wildcard case, we need to update the name. */ if (wildcard) { for (dp = name; *dp != '\0'; dp++); @@ -624,8 +654,10 @@ { struct if_clone *ifc; struct ifnet *ifp; + int bytoff, bitoff; + int err, unit; - ifc = if_clone_lookup(name, NULL); + ifc = if_clone_lookup(name, &unit); if (ifc == NULL) return (EINVAL); @@ -636,7 +668,19 @@ if (ifc->ifc_destroy == NULL) return (EOPNOTSUPP); - return ((*ifc->ifc_destroy)(ifp)); + err = (*ifc->ifc_destroy)(ifp); + if (err != 0) + return (err); + + /* + * Compute offset in the bitmap and deallocate the unit. + */ + bytoff = unit >> 3; + bitoff = unit - (bytoff << 3); + KASSERT((ifc->ifc_units[bytoff] & (1 << bitoff)) != 0, + ("%s: bit is already cleared", __func__)); + ifc->ifc_units[bytoff] &= ~(1 << bitoff); + return (0); } /* @@ -689,7 +733,17 @@ if_clone_attach(ifc) struct if_clone *ifc; { + int len, maxclone; + /* + * Compute bitmap size and allocate it. + */ + maxclone = ifc->ifc_maxunit + 1; + len = maxclone >> 3; + if ((len << 3) < maxclone) + len++; + ifc->ifc_units = malloc(len, M_CLONE, M_WAITOK | M_ZERO); + ifc->ifc_bmlen = len; LIST_INSERT_HEAD(&if_cloners, ifc, ifc_list); if_cloners_count++; } @@ -703,6 +757,7 @@ { LIST_REMOVE(ifc, ifc_list); + free(ifc->ifc_units, M_CLONE); if_cloners_count--; } Index: if.h =================================================================== RCS file: /home/ncvs/src/sys/net/if.h,v retrieving revision 1.69 diff -u -r1.69 if.h --- if.h 4 Mar 2002 21:43:49 -0000 1.69 +++ if.h 6 Mar 2002 11:58:06 -0000 @@ -55,6 +55,7 @@ */ #define IFNAMSIZ 16 #define IF_NAMESIZE IFNAMSIZ +#define IF_MAXUNIT 0x7fff /* ifp->if_unit is only 15 bits */ /* * Structure describing a `cloning' interface. @@ -63,13 +64,16 @@ LIST_ENTRY(if_clone) ifc_list; /* on list of cloners */ const char *ifc_name; /* name of device, e.g. `gif' */ size_t ifc_namelen; /* length of name */ + int ifc_maxunit; /* maximum unit number */ + unsigned char *ifc_units; /* bitmap to handle units */ + int ifc_bmlen; /* bitmap length */ - int (*ifc_create)(struct if_clone *, int *); + int (*ifc_create)(struct if_clone *, int); int (*ifc_destroy)(struct ifnet *); }; -#define IF_CLONE_INITIALIZER(name, create, destroy) \ - { { 0 }, name, sizeof(name) - 1, create, destroy } +#define IF_CLONE_INITIALIZER(name, create, destroy, maxunit) \ + { { 0 }, name, sizeof(name) - 1, maxunit, NULL, 0, create, destroy } /* * Structure used to query names of interface cloners. Index: if_faith.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_faith.c,v retrieving revision 1.12 diff -u -r1.12 if_faith.c --- if_faith.c 4 Mar 2002 21:43:49 -0000 1.12 +++ if_faith.c 6 Mar 2002 19:43:34 -0000 @@ -57,8 +57,6 @@ #include #include #include -#include /* XXX: Shouldn't really be required! */ -#include #include #include @@ -85,11 +83,9 @@ #include #define FAITHNAME "faith" -#define FAITH_MAXUNIT 0x7fff /* ifp->if_unit is only 15 bits */ struct faith_softc { struct ifnet sc_if; /* must be first */ - struct resource *r_unit; LIST_ENTRY(faith_softc) sc_list; }; @@ -104,14 +100,13 @@ static int faithmodevent __P((module_t, int, void *)); static MALLOC_DEFINE(M_FAITH, FAITHNAME, "Firewall Assisted Tunnel Interface"); -static struct rman faithunits[1]; static LIST_HEAD(, faith_softc) faith_softc_list; -int faith_clone_create __P((struct if_clone *, int *)); +int faith_clone_create __P((struct if_clone *, int)); int faith_clone_destroy __P((struct ifnet *)); -struct if_clone faith_cloner = - IF_CLONE_INITIALIZER(FAITHNAME, faith_clone_create, faith_clone_destroy); +struct if_clone faith_cloner = IF_CLONE_INITIALIZER(FAITHNAME, + faith_clone_create, faith_clone_destroy, IF_MAXUNIT); #define FAITHMTU 1500 @@ -121,22 +116,9 @@ int type; void *data; { - int err; switch (type) { case MOD_LOAD: - faithunits->rm_type = RMAN_ARRAY; - faithunits->rm_descr = "configurable if_faith units"; - err = rman_init(faithunits); - if (err != 0) - return (err); - err = rman_manage_region(faithunits, 0, FAITH_MAXUNIT); - if (err != 0) { - printf("%s: faithunits: rman_manage_region: " - "Failed %d\n", FAITHNAME, err); - rman_fini(faithunits); - return (err); - } LIST_INIT(&faith_softc_list); if_clone_attach(&faith_cloner); @@ -156,10 +138,6 @@ faith_clone_destroy( &LIST_FIRST(&faith_softc_list)->sc_if); - err = rman_fini(faithunits); - if (err != 0) - return (err); - break; } return 0; @@ -177,34 +155,16 @@ int faith_clone_create(ifc, unit) struct if_clone *ifc; - int *unit; + int unit; { - struct resource *r; struct faith_softc *sc; - if (*unit > FAITH_MAXUNIT) - return (ENXIO); - - if (*unit < 0) { - r = rman_reserve_resource(faithunits, 0, FAITH_MAXUNIT, 1, - RF_ALLOCATED | RF_ACTIVE, NULL); - if (r == NULL) - return (ENOSPC); - *unit = rman_get_start(r); - } else { - r = rman_reserve_resource(faithunits, *unit, *unit, 1, - RF_ALLOCATED | RF_ACTIVE, NULL); - if (r == NULL) - return (ENOSPC); - } - sc = malloc(sizeof(struct faith_softc), M_FAITH, M_WAITOK); bzero(sc, sizeof(struct faith_softc)); sc->sc_if.if_softc = sc; sc->sc_if.if_name = FAITHNAME; - sc->sc_if.if_unit = *unit; - sc->r_unit = r; + sc->sc_if.if_unit = unit; sc->sc_if.if_mtu = FAITHMTU; /* Change to BROADCAST experimentaly to announce its prefix. */ @@ -225,15 +185,11 @@ faith_clone_destroy(ifp) struct ifnet *ifp; { - int err; struct faith_softc *sc = (void *) ifp; LIST_REMOVE(sc, sc_list); bpfdetach(ifp); if_detach(ifp); - - err = rman_release_resource(sc->r_unit); - KASSERT(err == 0, ("Unexpected error freeing resource")); free(sc, M_FAITH); return (0); Index: if_gif.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_gif.c,v retrieving revision 1.20 diff -u -r1.20 if_gif.c --- if_gif.c 4 Mar 2002 21:43:49 -0000 1.20 +++ if_gif.c 6 Mar 2002 19:42:52 -0000 @@ -46,8 +46,6 @@ #include #include #include -#include /* XXX: Shouldn't really be required! */ -#include #include #include @@ -82,10 +80,8 @@ #include #define GIFNAME "gif" -#define GIF_MAXUNIT 0x7fff /* ifp->if_unit is only 15 bits */ static MALLOC_DEFINE(M_GIF, "gif", "Generic Tunnel Interface"); -static struct rman gifunits[1]; static LIST_HEAD(, gif_softc) gif_softc_list; void (*ng_gif_input_p)(struct ifnet *ifp, struct mbuf **mp, int af); @@ -93,11 +89,11 @@ void (*ng_gif_attach_p)(struct ifnet *ifp); void (*ng_gif_detach_p)(struct ifnet *ifp); -int gif_clone_create __P((struct if_clone *, int *)); +int gif_clone_create __P((struct if_clone *, int)); int gif_clone_destroy __P((struct ifnet *)); -struct if_clone gif_cloner = - IF_CLONE_INITIALIZER("gif", gif_clone_create, gif_clone_destroy); +struct if_clone gif_cloner = IF_CLONE_INITIALIZER("gif", + gif_clone_create, gif_clone_destroy, IF_MAXUNIT); static int gifmodevent __P((module_t, int, void *)); void gif_delete_tunnel __P((struct gif_softc *)); @@ -158,34 +154,16 @@ int gif_clone_create(ifc, unit) struct if_clone *ifc; - int *unit; + int unit; { - struct resource *r; struct gif_softc *sc; - if (*unit > GIF_MAXUNIT) - return (ENXIO); - - if (*unit < 0) { - r = rman_reserve_resource(gifunits, 0, GIF_MAXUNIT, 1, - RF_ALLOCATED | RF_ACTIVE, NULL); - if (r == NULL) - return (ENOSPC); - *unit = rman_get_start(r); - } else { - r = rman_reserve_resource(gifunits, *unit, *unit, 1, - RF_ALLOCATED | RF_ACTIVE, NULL); - if (r == NULL) - return (EEXIST); - } - sc = malloc (sizeof(struct gif_softc), M_GIF, M_WAITOK); bzero(sc, sizeof(struct gif_softc)); sc->gif_if.if_softc = sc; sc->gif_if.if_name = GIFNAME; - sc->gif_if.if_unit = *unit; - sc->r_unit = r; + sc->gif_if.if_unit = unit; sc->encap_cookie4 = sc->encap_cookie6 = NULL; #ifdef INET @@ -252,9 +230,6 @@ bpfdetach(ifp); if_detach(ifp); - err = rman_release_resource(sc->r_unit); - KASSERT(err == 0, ("Unexpected error freeing resource")); - free(sc, M_GIF); return (0); } @@ -265,22 +240,9 @@ int type; void *data; { - int err; switch (type) { case MOD_LOAD: - gifunits->rm_type = RMAN_ARRAY; - gifunits->rm_descr = "configurable if_gif units"; - err = rman_init(gifunits); - if (err != 0) - return (err); - err = rman_manage_region(gifunits, 0, GIF_MAXUNIT); - if (err != 0) { - printf("%s: gifunits: rman_manage_region: Failed %d\n", - GIFNAME, err); - rman_fini(gifunits); - return (err); - } LIST_INIT(&gif_softc_list); if_clone_attach(&gif_cloner); @@ -295,9 +257,6 @@ while (!LIST_EMPTY(&gif_softc_list)) gif_clone_destroy(&LIST_FIRST(&gif_softc_list)->gif_if); - err = rman_fini(gifunits); - if (err != 0) - return (err); #ifdef INET6 ip6_gif_hlim = 0; #endif Index: if_gif.h =================================================================== RCS file: /home/ncvs/src/sys/net/if_gif.h,v retrieving revision 1.8 diff -u -r1.8 if_gif.h --- if_gif.h 27 Sep 2001 03:14:16 -0000 1.8 +++ if_gif.h 21 Feb 2002 02:07:39 -0000 @@ -68,7 +68,6 @@ int gif_flags; const struct encaptab *encap_cookie4; const struct encaptab *encap_cookie6; - struct resource *r_unit; /* resource allocated for this unit */ void *gif_netgraph; /* ng_gif(4) netgraph node info */ LIST_ENTRY(gif_softc) gif_link; /* all gif's are linked */ }; Index: if_loop.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_loop.c,v retrieving revision 1.68 diff -u -r1.68 if_loop.c --- if_loop.c 4 Mar 2002 21:46:00 -0000 1.68 +++ if_loop.c 6 Mar 2002 19:50:14 -0000 @@ -99,21 +99,18 @@ #endif #define LONAME "lo" -#define LOMAXUNIT 0x7fff /* ifp->if_unit is only 15 bits */ struct lo_softc { struct ifnet sc_if; /* network-visible interface */ LIST_ENTRY(lo_softc) sc_next; - struct resource *r_unit; }; int loioctl(struct ifnet *, u_long, caddr_t); static void lortrequest(int, struct rtentry *, struct rt_addrinfo *); int looutput(struct ifnet *ifp, struct mbuf *m, struct sockaddr *dst, struct rtentry *rt); -int lo_clone_create(struct if_clone *, int *); +int lo_clone_create(struct if_clone *, int); int lo_clone_destroy(struct ifnet *); -static void locreate(int, struct resource *); struct ifnet *loif = NULL; /* Used externally */ @@ -122,41 +119,12 @@ static LIST_HEAD(lo_list, lo_softc) lo_list; struct if_clone lo_cloner = - IF_CLONE_INITIALIZER(LONAME, lo_clone_create, lo_clone_destroy); - -static struct rman lounits[1]; - -int -lo_clone_create(ifc, unit) - struct if_clone *ifc; - int *unit; -{ - struct resource *r; - - if (*unit > LOMAXUNIT) - return (ENXIO); - - if (*unit < 0) { - r = rman_reserve_resource(lounits, 0, LOMAXUNIT, 1, - RF_ALLOCATED | RF_ACTIVE, NULL); - if (r == NULL) - return (ENOSPC); - *unit = rman_get_start(r); - } else { - r = rman_reserve_resource(lounits, *unit, *unit, 1, - RF_ALLOCATED | RF_ACTIVE, NULL); - if (r == NULL) - return (EEXIST); - } - locreate(*unit, r); - return (0); -} + IF_CLONE_INITIALIZER(LONAME, lo_clone_create, lo_clone_destroy, IF_MAXUNIT); int lo_clone_destroy(ifp) struct ifnet *ifp; { - int err; struct lo_softc *sc; sc = ifp->if_softc; @@ -167,9 +135,6 @@ if (loif == ifp) return (EINVAL); - err = rman_release_resource(sc->r_unit); - KASSERT(err == 0, ("Unexpected error freeing resource")); - bpfdetach(ifp); if_detach(ifp); LIST_REMOVE(sc, sc_next); @@ -177,8 +142,10 @@ return (0); } -static void -locreate(int unit, struct resource *r) +int +lo_clone_create(ifc, unit) + struct if_clone *ifc; + int unit; { struct lo_softc *sc; @@ -193,40 +160,27 @@ sc->sc_if.if_type = IFT_LOOP; sc->sc_if.if_snd.ifq_maxlen = ifqmaxlen; sc->sc_if.if_softc = sc; - sc->r_unit = r; if_attach(&sc->sc_if); bpfattach(&sc->sc_if, DLT_NULL, sizeof(u_int)); LIST_INSERT_HEAD(&lo_list, sc, sc_next); if (loif == NULL) loif = &sc->sc_if; + + return (0); } static int loop_modevent(module_t mod, int type, void *data) { int err; - int unit; switch (type) { case MOD_LOAD: - lounits->rm_type = RMAN_ARRAY; - lounits->rm_descr = "configurable if_loop units"; - err = rman_init(lounits); - if (err != 0) - return (err); - err = rman_manage_region(lounits, 0, LOMAXUNIT); - if (err != 0) { - printf("%s: lounits: rman_manage_region: Failed %d\n", - LONAME, err); - rman_fini(lounits); - return (err); - } LIST_INIT(&lo_list); if_clone_attach(&lo_cloner); /* Create lo0 */ - unit = 0; - err = lo_clone_create(NULL, &unit); + err = if_clone_create("lo0", sizeof ("lo0")); KASSERT(err == 0, ("%s: can't create lo0", __func__)); break; case MOD_UNLOAD: Index: if_stf.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_stf.c,v retrieving revision 1.18 diff -u -r1.18 if_stf.c --- if_stf.c 4 Mar 2002 21:43:49 -0000 1.18 +++ if_stf.c 6 Mar 2002 19:35:18 -0000 @@ -86,8 +86,6 @@ #include #include #include -#include /* XXX: Shouldn't really be required! */ -#include #include #include @@ -118,7 +116,6 @@ #include #define STFNAME "stf" -#define STF_MAXUNIT 0 /* only one is currently allowed */ #define IN6_IS_ADDR_6TO4(x) (ntohs((x)->s6_addr16[0]) == 0x2002) #define GET_V4(x) ((struct in_addr *)(&(x)->s6_addr16[1])) @@ -131,14 +128,12 @@ } __sc_ro46; #define sc_ro __sc_ro46.__sc_ro4 const struct encaptab *encap_cookie; - struct resource *r_unit; /* resource allocated for this unit */ LIST_ENTRY(stf_softc) sc_list; /* all stf's are linked */ }; static LIST_HEAD(, stf_softc) stf_softc_list; static MALLOC_DEFINE(M_STF, STFNAME, "6to4 Tunnel Interface"); -static struct rman stfunits[1]; static int ip_stf_ttl = 40; extern struct domain inetdomain; @@ -162,40 +157,23 @@ static void stf_rtrequest __P((int, struct rtentry *, struct rt_addrinfo *)); static int stf_ioctl __P((struct ifnet *, u_long, caddr_t)); -int stf_clone_create __P((struct if_clone *, int *)); +int stf_clone_create __P((struct if_clone *, int)); int stf_clone_destroy __P((struct ifnet *)); +/* only one clone is currently allowed */ struct if_clone stf_cloner = - IF_CLONE_INITIALIZER(STFNAME, stf_clone_create, stf_clone_destroy); + IF_CLONE_INITIALIZER(STFNAME, stf_clone_create, stf_clone_destroy, 0); int stf_clone_create(ifc, unit) struct if_clone *ifc; - int *unit; + int unit; { - struct resource *r; struct stf_softc *sc; - if (*unit > STF_MAXUNIT) - return (ENXIO); - - if (*unit < 0) { - r = rman_reserve_resource(stfunits, 0, STF_MAXUNIT, 1, - RF_ALLOCATED | RF_ACTIVE, NULL); - if (r == NULL) - return (ENOSPC); - *unit = rman_get_start(r); - } else { - r = rman_reserve_resource(stfunits, *unit, *unit, 1, - RF_ALLOCATED | RF_ACTIVE, NULL); - if (r == NULL) - return (EEXIST); - } - sc = malloc(sizeof(struct stf_softc), M_STF, M_WAITOK | M_ZERO); sc->sc_if.if_name = STFNAME; - sc->sc_if.if_unit = *unit; - sc->r_unit = r; + sc->sc_if.if_unit = unit; sc->encap_cookie = encap_attach_func(AF_INET, IPPROTO_IPV6, stf_encapcheck, &in_stf_protosw, sc); @@ -229,9 +207,6 @@ bpfdetach(ifp); if_detach(ifp); - err = rman_release_resource(sc->r_unit); - KASSERT(err == 0, ("Unexpected error freeing resource")); - free(sc, M_STF); return (0); } @@ -242,22 +217,9 @@ int type; void *data; { - int err; switch (type) { case MOD_LOAD: - stfunits->rm_type = RMAN_ARRAY; - stfunits->rm_descr = "configurable if_stf units"; - err = rman_init(stfunits); - if (err != 0) - return (err); - err = rman_manage_region(stfunits, 0, STF_MAXUNIT); - if (err != 0) { - printf("%s: stfunits: rman_manage_region: Failed %d\n", - STFNAME, err); - rman_fini(stfunits); - return (err); - } LIST_INIT(&stf_softc_list); if_clone_attach(&stf_cloner); @@ -267,10 +229,6 @@ while (!LIST_EMPTY(&stf_softc_list)) stf_clone_destroy(&LIST_FIRST(&stf_softc_list)->sc_if); - - err = rman_fini(stfunits); - KASSERT(err == 0, ("Unexpected error freeing resource")); - break; } Index: if_vlan.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_vlan.c,v retrieving revision 1.38 diff -u -r1.38 if_vlan.c --- if_vlan.c 4 Mar 2002 21:43:49 -0000 1.38 +++ if_vlan.c 6 Mar 2002 19:42:23 -0000 @@ -66,8 +66,6 @@ #include #include #include -#include /* XXX: Shouldn't really be required! */ -#include #include #include @@ -83,17 +81,15 @@ #endif #define VLANNAME "vlan" -#define VLAN_MAXUNIT 0x7fff /* ifp->if_unit is only 15 bits */ SYSCTL_DECL(_net_link); SYSCTL_NODE(_net_link, IFT_L2VLAN, vlan, CTLFLAG_RW, 0, "IEEE 802.1Q VLAN"); SYSCTL_NODE(_net_link_vlan, PF_LINK, link, CTLFLAG_RW, 0, "for consistency"); static MALLOC_DEFINE(M_VLAN, "vlan", "802.1Q Virtual LAN Interface"); -static struct rman vlanunits[1]; static LIST_HEAD(, ifvlan) ifv_list; -static int vlan_clone_create(struct if_clone *, int *); +static int vlan_clone_create(struct if_clone *, int); static int vlan_clone_destroy(struct ifnet *); static void vlan_start(struct ifnet *ifp); static void vlan_ifinit(void *foo); @@ -105,8 +101,8 @@ static int vlan_unconfig(struct ifnet *ifp); static int vlan_config(struct ifvlan *ifv, struct ifnet *p); -struct if_clone vlan_cloner = - IF_CLONE_INITIALIZER("vlan", vlan_clone_create, vlan_clone_destroy); +struct if_clone vlan_cloner = IF_CLONE_INITIALIZER("vlan", + vlan_clone_create, vlan_clone_destroy, IF_MAXUNIT); /* * Program our multicast filter. What we're actually doing is @@ -176,22 +172,9 @@ static int vlan_modevent(module_t mod, int type, void *data) { - int err; switch (type) { case MOD_LOAD: - vlanunits->rm_type = RMAN_ARRAY; - vlanunits->rm_descr = "configurable if_vlan units"; - err = rman_init(vlanunits); - if (err != 0) - return (err); - err = rman_manage_region(vlanunits, 0, VLAN_MAXUNIT); - if (err != 0) { - printf("%s: vlanunits: rman_manage_region: Failed %d\n", - VLANNAME, err); - rman_fini(vlanunits); - return (err); - } LIST_INIT(&ifv_list); vlan_input_p = vlan_input; vlan_input_tag_p = vlan_input_tag; @@ -203,9 +186,6 @@ vlan_input_tag_p = NULL; while (!LIST_EMPTY(&ifv_list)) vlan_clone_destroy(&LIST_FIRST(&ifv_list)->ifv_if); - err = rman_fini(vlanunits); - if (err != 0) - return (err); break; } return 0; @@ -220,29 +200,12 @@ DECLARE_MODULE(if_vlan, vlan_mod, SI_SUB_PSEUDO, SI_ORDER_ANY); static int -vlan_clone_create(struct if_clone *ifc, int *unit) +vlan_clone_create(struct if_clone *ifc, int unit) { - struct resource *r; struct ifvlan *ifv; struct ifnet *ifp; int s; - if (*unit > VLAN_MAXUNIT) - return (ENXIO); - - if (*unit < 0) { - r = rman_reserve_resource(vlanunits, 0, VLAN_MAXUNIT, 1, - RF_ALLOCATED | RF_ACTIVE, NULL); - if (r == NULL) - return (ENOSPC); - *unit = rman_get_start(r); - } else { - r = rman_reserve_resource(vlanunits, *unit, *unit, 1, - RF_ALLOCATED | RF_ACTIVE, NULL); - if (r == NULL) - return (EEXIST); - } - ifv = malloc(sizeof(struct ifvlan), M_VLAN, M_WAITOK | M_ZERO); ifp = &ifv->ifv_if; SLIST_INIT(&ifv->vlan_mc_listhead); @@ -253,8 +216,7 @@ ifp->if_softc = ifv; ifp->if_name = "vlan"; - ifp->if_unit = *unit; - ifv->r_unit = r; + ifp->if_unit = unit; /* NB: flags are not set here */ ifp->if_linkmib = &ifv->ifv_mib; ifp->if_linkmiblen = sizeof ifv->ifv_mib; @@ -279,7 +241,6 @@ { struct ifvlan *ifv = ifp->if_softc; int s; - int err; s = splnet(); LIST_REMOVE(ifv, ifv_list); @@ -288,8 +249,6 @@ ether_ifdetach(ifp, ETHER_BPF_SUPPORTED); - err = rman_release_resource(ifv->r_unit); - KASSERT(err == 0, ("Unexpected error freeing resource")); free(ifv, M_VLAN); return (0); } Index: if_vlan_var.h =================================================================== RCS file: /home/ncvs/src/sys/net/if_vlan_var.h,v retrieving revision 1.10 diff -u -r1.10 if_vlan_var.h --- if_vlan_var.h 5 Sep 2001 21:10:28 -0000 1.10 +++ if_vlan_var.h 21 Feb 2002 02:09:34 -0000 @@ -48,7 +48,6 @@ } ifv_mib; SLIST_HEAD(__vlan_mchead, vlan_mc_entry) vlan_mc_listhead; LIST_ENTRY(ifvlan) ifv_list; - struct resource *r_unit; /* resource allocated for this unit */ }; #define ifv_if ifv_ac.ac_if #define ifv_tag ifv_mib.ifvm_tag --k+w/mQv8wyuph6w0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 6 13:50:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from web21103.mail.yahoo.com (web21103.mail.yahoo.com [216.136.227.105]) by hub.freebsd.org (Postfix) with SMTP id 17F9837B400 for ; Wed, 6 Mar 2002 13:50:26 -0800 (PST) Message-ID: <20020306215021.21033.qmail@web21103.mail.yahoo.com> Received: from [152.15.24.198] by web21103.mail.yahoo.com via HTTP; Wed, 06 Mar 2002 13:50:21 PST Date: Wed, 6 Mar 2002 13:50:21 -0800 (PST) From: Vinod Subject: Re: netgraph for slip or 802.11 To: Roop Mukherjee Cc: freebsd-net@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org am looking for the same info too. Vinod --- Roop Mukherjee wrote: > I am wondering if there is any chance that someone > has implemented > netgraph nodes for slip or 802.11 interfaces? If so > I would appreciate any > pointers. > > -- Roop > ________________________________________ > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.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 6 15:27:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from big.uwaterloo.ca (styx.uwaterloo.ca [129.97.105.10]) by hub.freebsd.org (Postfix) with ESMTP id 19FAA37B400 for ; Wed, 6 Mar 2002 15:27:52 -0800 (PST) Received: from localhost (bmukherj@localhost) by big.uwaterloo.ca (8.11.0/8.11.0) with ESMTP id g26NRp425314 for ; Wed, 6 Mar 2002 18:27:51 -0500 Date: Wed, 6 Mar 2002 18:27:51 -0500 (EST) From: Roop Mukherjee To: Subject: Re: netgraph for slip or 802.11 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Actually my interest is for using it at the mobile node. I was also hoping that someone could answer a quick question about the code. I was thinking that the netgraph nodes that represent the network interfaces, forward packets to the drivers and let them do framing and control etc. But I can't seem to find any call to ether_output() or even packets being queued at if_snd. How does the ng_ether node actually cause transmission on the wire? Cheers, -- Roop PS: Please copy me on the reply as I am not a subscriber of the mailing list. On Wed, 6 Mar 2002, Julian Elischer wrote: > no, as far as I kow neither has been done. > > I'm intersted in knowing exactly what you mena by 802.11 in netgraph.. > Do you mean the Beaconning etc, needed for AP operation? > > > > On Wed, 6 Mar 2002, Roop Mukherjee wrote: > > > I am wondering if there is any chance that someone has implemented > > netgraph nodes for slip or 802.11 interfaces? If so I would appreciate any > > pointers. > > > > -- Roop > > ________________________________________ > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 6 17: 8:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 4FD5C37B400; Wed, 6 Mar 2002 17:08:14 -0800 (PST) Received: from pool0533.cvx21-bradley.dialup.earthlink.net ([209.179.194.23] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16imOD-00052s-00; Wed, 06 Mar 2002 17:08:13 -0800 Message-ID: <3C86BD6B.3ADCB4F0@mindspring.com> Date: Wed, 06 Mar 2002 17:07:55 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: net@freebsd.org Cc: hackers@freebsd.org Subject: in_pcblookup_hash() called multiple times 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 There are redundant calls to the in_pcblookup_hash() in the ip_fw_chk() function called via (*ip_fw_chk_ptr)() in the ip_input path. Would it be useful to modify the (*pr_input) function pointer in the struct ipprotosw to take a fourth argument (perhaps it should be cast to a "void *" to keep it generalized?) to pass the pre-looked-up struct inpcb * to TCP, if the lookup has already been done? Profiling indicates that this is one of the most expensive calls in the code path, particularly when there are a lot of sockets open. Increasing the hash table size only works so far; at "a lot", the number of connections makes the lookup expensive anyway (it's a linear traversal of the collision chain for the bucket). Since there are reasons other than firewalling to do the lookup early, it seems that it would be useful to pass a pointer the a pointer that was non-NULL, if the lookup had already taken place. For example, moving the ipflow to use an overlay structure for the inpcb would mean that a single lookup was used for fast forwarding, firewalling, and inpcb identification for tcpcb retrieval for TCP. Note that I'm only talking about the packet input path here, at this time, so the firewall code isn't really generalizable (the inpcb is already known on output, except to the ip_fw code; it probably doesn't make sense to push knwledge of it into the ip_output path, at least without more thought). Right now, I'm just talking about a way ip_input could pass the already looked up input inpcb to tcp_input, udp_input, or udp_ctlinput -- all of which repeat the lookup operation. -- 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 6 17:40:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 81C4437B416; Wed, 6 Mar 2002 17:40:08 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020307014008.UBOB1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Thu, 7 Mar 2002 01:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA38997; Wed, 6 Mar 2002 17:28:28 -0800 (PST) Date: Wed, 6 Mar 2002 17:28:27 -0800 (PST) From: Julian Elischer To: Terry Lambert Cc: net@freebsd.org, hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times In-Reply-To: <3C86BD6B.3ADCB4F0@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 sounds good.. can you send us a patch to look at? On Wed, 6 Mar 2002, Terry Lambert wrote: > There are redundant calls to the in_pcblookup_hash() in the > ip_fw_chk() function called via (*ip_fw_chk_ptr)() in the > ip_input path. > > Would it be useful to modify the (*pr_input) function pointer > in the struct ipprotosw to take a fourth argument (perhaps it > should be cast to a "void *" to keep it generalized?) to pass > the pre-looked-up struct inpcb * to TCP, if the lookup has > already been done? > > Profiling indicates that this is one of the most expensive > calls in the code path, particularly when there are a lot > of sockets open. Increasing the hash table size only works > so far; at "a lot", the number of connections makes the > lookup expensive anyway (it's a linear traversal of the > collision chain for the bucket). > > Since there are reasons other than firewalling to do the > lookup early, it seems that it would be useful to pass a > pointer the a pointer that was non-NULL, if the lookup had > already taken place. For example, moving the ipflow to > use an overlay structure for the inpcb would mean that a > single lookup was used for fast forwarding, firewalling, > and inpcb identification for tcpcb retrieval for TCP. > > Note that I'm only talking about the packet input path here, > at this time, so the firewall code isn't really generalizable > (the inpcb is already known on output, except to the ip_fw > code; it probably doesn't make sense to push knwledge of it > into the ip_output path, at least without more thought). > > Right now, I'm just talking about a way ip_input could pass > the already looked up input inpcb to tcp_input, udp_input, > or udp_ctlinput -- all of which repeat the lookup operation. > > -- Terry > > 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 7 1:29: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 8622A37B426; Thu, 7 Mar 2002 01:28:48 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1098) id 52817AE1FC; Thu, 7 Mar 2002 01:28:48 -0800 (PST) Date: Thu, 7 Mar 2002 01:28:48 -0800 From: Bill Fumerola To: Terry Lambert Cc: net@freebsd.org, hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times Message-ID: <20020307092848.GX803@elvis.mu.org> Reply-To: Bill Fumerola References: <3C86BD6B.3ADCB4F0@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C86BD6B.3ADCB4F0@mindspring.com> User-Agent: Mutt/1.3.27i X-Operating-System: FreeBSD 4.5-MUORG-20020215 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 On Wed, Mar 06, 2002 at 05:07:55PM -0800, Terry Lambert wrote: > There are redundant calls to the in_pcblookup_hash() in the > ip_fw_chk() function called via (*ip_fw_chk_ptr)() in the > ip_input path. in addition to what you're talking about, ipfw will repeat the hash lookup for every rule it goes through that has a uid or gid keyword. http://people.freebsd.org/~billf/bsdcon2000/presentation/graphics/countudpfromanytoanyuidbillf.png http://people.freebsd.org/~billf/bsdcon2000/presentation/graphics/counttcpfromanytoanyuidbillf.png 'old ipfw' = ipfw as of oct 2000 'new ipfw' = ipfw w/pcb cache + uid cache (as part of a compiled ruleset) in the compiled case, in_pcblookup_hash() is called the first time a uid needs compared. after that, uid lookups become a integer compare and not another call to in_pcblookup_hash(). gid lookups still use groupmember() each rule, but also don't have to do a pcb lookup each time. > Right now, I'm just talking about a way ip_input could pass > the already looked up input inpcb to tcp_input, udp_input, > or udp_ctlinput -- all of which repeat the lookup operation. my results are with a cached lookup just in the ipfw code, but if ip_input() did the lookup and passed it to both ipfw and the protocol handler that would be nice. -- - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org / billf@mu.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 7 2:50:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from web13006.mail.yahoo.com (web13006.mail.yahoo.com [216.136.174.16]) by hub.freebsd.org (Postfix) with SMTP id 200F437B448 for ; Thu, 7 Mar 2002 02:50:30 -0800 (PST) Message-ID: <20020307105030.11376.qmail@web13006.mail.yahoo.com> Received: from [147.83.130.105] by web13006.mail.yahoo.com via HTTP; Thu, 07 Mar 2002 02:50:30 PST Date: Thu, 7 Mar 2002 02:50:30 -0800 (PST) From: Russo Roberto Subject: (FreeBSD TCP) vs (Linux TCP) 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 working to evaluate performance of throughput between two PC connected between a Fore-ATM card adapter to a network: the netwotk is composed of a PVC of 4Mbps between three routers and I am just looking to use differente queuing discipline like FIFO-PQ-WFQ. I have configured the two PC with the same Operating Systems: a Linux (Red-Hat) and a FreeBSD v4.3 (Kame Patch) and I am using NETPERF to make throughput test. Making the first tests I note a difference beetwen using the two FreeBSD or the two LINUX: [1] for example when using FreeBSD-FIFO and make a default TCP_STREAM Netperf with the deafult values of SendSocketSize and ReceiverSocketSize (16.000) the value of througput is lower (<2Mbps) than the 3.5Mpbs that I have configured in the PVC; however making the same test with the values of SendSocketSize and ReceiverSocketSize of 128000 the test is good and I have the value of 3.45Mbps using Linux-FIFO and make a default TCP_STREAM with the deafult values of SendSocketSize and ReceiverSocketSize (16.000) the value of througput is of 3.5Mpbs. [2] using other queuing discipline I have always to change in FreeBSD the values of SendSocketSize and ReceiverSocketSize to have values that seems the real condition of the network; using Linux the values is always correct without changing the values of the Sockets. - anybody can help me to resolve this problem ? Is the TCP/IP stacks of the two systems very differents ? What is different ? Why the Linux seems have the best performances ? - Where I can find some documents that describe the TCP stacks of the two systems ? really Thanks...!!!!! Roberto __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.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 7 4: 0:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id DFB6A37B400; Thu, 7 Mar 2002 04:00:29 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020307120029.MXCA1147.rwcrmhc52.attbi.com@InterJet.elischer.org>; Thu, 7 Mar 2002 12:00:29 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id DAA41437; Thu, 7 Mar 2002 03:51:42 -0800 (PST) Date: Thu, 7 Mar 2002 03:51:41 -0800 (PST) From: Julian Elischer To: Bill Fumerola Cc: Terry Lambert , net@freebsd.org, hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times In-Reply-To: <20020307092848.GX803@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org what would be even nicer is if ipfw found the cached entry and passed it back to ip_input so it didn't need to :-) On Thu, 7 Mar 2002, Bill Fumerola wrote: > On Wed, Mar 06, 2002 at 05:07:55PM -0800, Terry Lambert wrote: > > > There are redundant calls to the in_pcblookup_hash() in the > > ip_fw_chk() function called via (*ip_fw_chk_ptr)() in the > > ip_input path. > > in addition to what you're talking about, ipfw will repeat the hash > lookup for every rule it goes through that has a uid or gid keyword. > > http://people.freebsd.org/~billf/bsdcon2000/presentation/graphics/countudpfromanytoanyuidbillf.png > http://people.freebsd.org/~billf/bsdcon2000/presentation/graphics/counttcpfromanytoanyuidbillf.png > > 'old ipfw' = ipfw as of oct 2000 > 'new ipfw' = ipfw w/pcb cache + uid cache (as part of a compiled ruleset) > > in the compiled case, in_pcblookup_hash() is called the first time a uid > needs compared. after that, uid lookups become a integer compare and not > another call to in_pcblookup_hash(). gid lookups still use groupmember() > each rule, but also don't have to do a pcb lookup each time. > > > Right now, I'm just talking about a way ip_input could pass > > the already looked up input inpcb to tcp_input, udp_input, > > or udp_ctlinput -- all of which repeat the lookup operation. > > my results are with a cached lookup just in the ipfw code, but if > ip_input() did the lookup and passed it to both ipfw and the protocol > handler that would be nice. > > -- > - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org / billf@mu.org > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" 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 7 4:20:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 016E337B429 for ; Thu, 7 Mar 2002 04:20:09 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020307122008.JZRJ2626.rwcrmhc51.attbi.com@InterJet.elischer.org>; Thu, 7 Mar 2002 12:20:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id EAA41541; Thu, 7 Mar 2002 04:05:28 -0800 (PST) Date: Thu, 7 Mar 2002 04:05:27 -0800 (PST) From: Julian Elischer To: Russo Roberto Cc: freebsd-net@FreeBSD.ORG Subject: Re: (FreeBSD TCP) vs (Linux TCP) In-Reply-To: <20020307105030.11376.qmail@web13006.mail.yahoo.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 It may or may not help but 4.3/4.4 had a few bad TCP bugs that were fixed in 4.5. 4.5 + ALTQ patch may give better results. On Thu, 7 Mar 2002, Russo Roberto wrote: > Hi, > > I am working to evaluate performance of > throughput between two PC connected between > a Fore-ATM card adapter to a network: > the netwotk is composed of a PVC of 4Mbps between > three routers and I am just looking to use > differente queuing discipline like FIFO-PQ-WFQ. > > I have configured the two PC with the same Operating > Systems: a Linux (Red-Hat) and a FreeBSD v4.3 (Kame > Patch) and I am using NETPERF to make throughput > test. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 7 8:19:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 3B70637B42F for ; Thu, 7 Mar 2002 08:19:18 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [fec0::1:12]) by Awfulhak.org (8.11.6/8.11.6) with ESMTP id g27GJE544973; Thu, 7 Mar 2002 16:19:14 GMT (envelope-from brian@freebsd-services.com) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.12.2/8.12.2) with ESMTP id g27DZAH6073810; Thu, 7 Mar 2002 13:35:10 GMT (envelope-from brian@freebsd-services.com) Message-Id: <200203071335.g27DZAH6073810@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Julian Elischer Cc: ome ome , freebsd-net@FreeBSD.ORG, brian@freebsd-services.com Subject: Re: MPD Server ? In-Reply-To: Message from Julian Elischer of "Wed, 20 Feb 2002 10:23:20 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Mar 2002 13:35:10 +0000 From: Brian Somers 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 > mpd does not know how to be a pppoe server. > HOWEVER the pppoed program is designed to turn the normal ppp > into a server. It is possible that archie might be able to > make mpd use pppoed (or embed it) but I'm pretty sure he hasn't done > it yet. pppoed can be told to run mpd. As long as mpd can handle treating descriptor 0 as it's link, it'll work. > MPD Is a multilink server, yes. When a second link is established from a client, it'll invoke a new mpd instance. Is mpd smart enough to detect this and pass the link from one invocation to the other ? This was one of the trickiest parts of making ppp(8) a multilink server. > On Wed, 20 Feb 2002, ome ome wrote: > > > Hi. > > > > I would like to test a multi-link over 2 different > > types of device with MPD 3.7 (PPPoE and PPP over a > > serial link) between two stations on freeBSD 3.5. > > > > MPD works fine as client, so I would like to know if > > MPD 3.7 could be a server PPPoE? Moreover, could MPD > > be > > a multi-link server? > > > > Thanks in advance. -- Brian http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 7 8:19:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 4670437B430 for ; Thu, 7 Mar 2002 08:19:20 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [fec0::1:12]) by Awfulhak.org (8.11.6/8.11.6) with ESMTP id g27GJF544976; Thu, 7 Mar 2002 16:19:15 GMT (envelope-from brian@freebsd-services.com) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.12.2/8.12.2) with ESMTP id g27DdQH6073865; Thu, 7 Mar 2002 13:39:26 GMT (envelope-from brian@freebsd-services.com) Message-Id: <200203071339.g27DdQH6073865@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "Matthew Emmerton" Cc: "Greg Black" , freebsd-net@FreeBSD.ORG, brian@freebsd-services.com Subject: Re: ppp -nat fails with adsl, but ok with modem In-Reply-To: Message from "Matthew Emmerton" of "Sun, 24 Feb 2002 18:22:27 EST." <001e01c1bd8a$22f347b0$1200a8c0@gsicomp.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Mar 2002 13:39:26 +0000 From: Brian Somers 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 > > "Matthew Emmerton" wrote: > > > > | From: "Greg Black" > > | To: > > | Sent: Friday, February 22, 2002 10:39 PM > > | Subject: ppp -nat fails with adsl, but ok with modem > > | > > | > I've had ppp -nat working just fine over a normal modem link, > > | > but it is not working at all well on my ADSL link to the same > > | > provider. > > | > > > | > To quantify "not working at all well", although I can ping and > > | > traceroute ok from the hosts on my LAN, HTTP and FTP traffic is > > | > so slow and bursty as to be useless. Clicking on a link with > > | > Netscape will see short bursts of data with long periods (of a > > | > minute or more) where it says "stalled". > > | > > > | > Clicking on from > > | > my gateway host gets the page in an eye-blink, but on the NAT > > | > hosts, it will take 40 seconds to load the top banner and the > > | > "FreeBSD GNOME News Flash" heading, then another delay of 40 or > > | > so seconds before the rest of the page will be displayed. Even > > | > then, Netscape thinks it has stalled and keeps waiting for the > > | > last bit of data. > > | > > > | > With FTP, a small transfer (e.g., a directory listing of / on > > | > ftp.freebsd.org) will complete normally; but something slightly > > | > larger (e.g., a listing of /pub/FreeBSD on the same server), > > | > will produce: > > | > > > | > ftp> cd /pub/FreeBSD > > | > 250 CWD command successful. > > | > ftp> dir > > | > 200 PORT command successful. > > | > 150 Opening ASCII mode data connection for '/bin/ls'. > > | > ftp: netin: Connection reset by peer > > | > 226 Transfer complete. > > | > ftp> quit > > | > 421 Timeout (60 seconds): closing control connection. > > | > > > | > If I do the same things from the host that is connected to the > > | > modem(s), everything works fine, for both types of connections. > > | > > > | > I'm finding this very frustrating, and I'm wondering if there's > > | > something weird about PPPoE with the ADSL link that needs some > > | > special magic in order for things to work properly. > > | > > > | > If anybody can point me at the truth, I'd be most grateful. > > | > > > | > Alternatively, if anybody can suggest steps I could take to > > | > identify the nature of the problem, that would also be most > > | > welcome. > > | > > > | > Greg Black > > | > > > | > To Unsubscribe: send mail to majordomo@FreeBSD.org > > | > with "unsubscribe freebsd-net" in the body of the message > > | > > | What version of FreeBSD are you using? The ppp included in early 4.x > > | distributions doesn't have the TCP MSS fixup code that is required to > make > > | things work properly with a PPPoE connection, and cause the kinds of > > | symptoms that you describe. > > > > The NAT box is running 4.2-RELEASE -- is that a problem? > > Yes. This problem was first fixed in 4.2-STABLE. There are two safe ways to > fix this: > - upgrade to a newer -RELEASE or -STABLE > - run the tcpmssd program (which is in the ports collection - > /usr/ports/net/tcpmssd) - Install the latest version of ppp from http://www.Awfulahk.org/ppp.html > -- > Matt Emmerton -- Brian http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 7 10:40:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 755EC37B446 for ; Thu, 7 Mar 2002 10:40:15 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020307184014.WWED1147.rwcrmhc52.attbi.com@InterJet.elischer.org>; Thu, 7 Mar 2002 18:40:14 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA43132; Thu, 7 Mar 2002 10:24:10 -0800 (PST) Date: Thu, 7 Mar 2002 10:24:09 -0800 (PST) From: Julian Elischer To: Brian Somers Cc: ome ome , freebsd-net@FreeBSD.ORG Subject: Re: MPD Server ? In-Reply-To: <200203071335.g27DZAH6073810@hak.lan.Awfulhak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 7 Mar 2002, Brian Somers wrote: > > mpd does not know how to be a pppoe server. > > HOWEVER the pppoed program is designed to turn the normal ppp > > into a server. It is possible that archie might be able to > > make mpd use pppoed (or embed it) but I'm pretty sure he hasn't done > > it yet. > > pppoed can be told to run mpd. As long as mpd can handle treating > descriptor 0 as it's link, it'll work. > > > MPD Is a multilink server, yes. > > When a second link is established from a client, it'll invoke a new > mpd instance. Is mpd smart enough to detect this and pass the link > from one invocation to the other ? > > This was one of the trickiest parts of making ppp(8) a multilink > server. I remember Archie and I discussing this with you way back when you were trying to work out how to do it, and I know that Archie halped with suggestions, but as far as I know there is no code i mpd to do that as it wasn't needed for what mpd was designed to do. of course I believe that ppp can now do everything that the writer asks for.. :-) > > > On Wed, 20 Feb 2002, ome ome wrote: > > > > > Hi. > > > > > > I would like to test a multi-link over 2 different > > > types of device with MPD 3.7 (PPPoE and PPP over a > > > serial link) between two stations on freeBSD 3.5. > > > > > > MPD works fine as client, so I would like to know if > > > MPD 3.7 could be a server PPPoE? Moreover, could MPD > > > be > > > a multi-link server? > > > > > > Thanks in advance. > > -- > Brian > http://www.freebsd-services.com/ > Don't _EVER_ lose your sense of humour ! > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 7 10:43:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from goose.prod.itd.earthlink.net (goose.mail.pas.earthlink.net [207.217.120.18]) by hub.freebsd.org (Postfix) with ESMTP id 34E0937B416; Thu, 7 Mar 2002 10:42:00 -0800 (PST) Received: from pool0314.cvx21-bradley.dialup.earthlink.net ([209.179.193.59] helo=mindspring.com) by goose.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16j2pr-0000Qi-00; Thu, 07 Mar 2002 10:41:52 -0800 Message-ID: <3C87B45F.3061AABF@mindspring.com> Date: Thu, 07 Mar 2002 10:41:35 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Bill Fumerola , net@freebsd.org, hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times References: Content-Type: multipart/mixed; boundary="------------87879C4452F25813094EB958" 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. --------------87879C4452F25813094EB958 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Julian Elischer wrote: > what would be even nicer is if ipfw found the cached entry and passed it > back to ip_input so it didn't need to :-) This is the approach I intended. The problem is that there are cases where you want the inpcb for additional processing (e.g. ipfw), and cases where there is no additioanl processing. Just because you have IP traffic doesn't mean you have an inpcb requirement. In addition, there are two lookup cases that are meaningful to the upper layers of the code (wildcard and non-wildcard); both of these are constrained to the source/source port and dest/dest port. The ipfw code actually does a number of lookups based on both input and output processing. Fixing up the input processing is rather easy (if tedious). The output processing is much harder to do anything but cache. NB: Is there a particular reason Bill's changes haven't simply been committed? In any case, I have a rough set of patches that adds a parameter for the cached inpcb, and passes a pointer to the pointer to the ipfw_chk() that it can fill out, and that will be passed to the upper level protocol processing, if it's filled out. I say "rough" here because I've not included the IPv6 code; don't worry: everything still works, but the IPv6 code seems to use varradic functions as initializers for the protosw in some cases, and seems to be broken in a couple of other places, and I wasn't going to go through and fix it without the IPv6 people being involved. The if_gif code is a particular abomination. 8-(. I also only do the tcp_input() and udp_input() path, and leave the ctlinput path for both for someone else (the parameter is there, I just don't check it before the lookup, which is trivial to do... see tcp_input). A clever eye will note that the lookup in the ip_fw code is non-wildcard, and the lookup in the tcp_input is wildcard. This works because the tcp_input call to in_pcblookup_hash wildcard case matches in both the wildcard and the non-wildcard case. The wildcard case is handled by doing a wildcard lookup if the cached value is NULL. This makes the code work in all cases, including the case where the ipfw code is not enabled (it just falls back to the old behaviour). Actually, I'm not sure that the non-wildcard lookup in the ipfw case is correct. It seems to me that you could use this to do filter avoidance on initial packets (e.g. T/TCP or data piggyback on the ACK for an outbound connection setup). Anyway, patches in unidiff format (that Julian likes) against -stable as of yesterday's CVSup are attached (about 20k). I'd like to see Bill F's stuff rolled in, too... obviously. -- Terry --------------87879C4452F25813094EB958 Content-Type: text/plain; charset=us-ascii; name="inp.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="inp.patch" Index: net/bridge.c =================================================================== RCS file: /usr/cvs/src/sys/net/bridge.c,v retrieving revision 1.16.2.17 diff -u -r1.16.2.17 bridge.c --- net/bridge.c 24 Nov 2001 01:48:21 -0000 1.16.2.17 +++ net/bridge.c 7 Mar 2002 18:22:36 -0000 @@ -767,7 +767,8 @@ * The firewall knows this is a bridged packet as the cookie ptr * is NULL. */ - i = ip_fw_chk_ptr(&ip, 0, NULL, NULL /* cookie */, &m0, &rule, NULL); + i = ip_fw_chk_ptr(&ip, 0, NULL, NULL /* cookie */, &m0, &rule, + NULL, NULL); if ( (i & IP_FW_PORT_DENY_FLAG) || m0 == NULL) /* drop */ return m0 ; /* Index: netinet/igmp.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/igmp.c,v retrieving revision 1.29.2.1 diff -u -r1.29.2.1 igmp.c --- netinet/igmp.c 17 Sep 2001 15:17:46 -0000 1.29.2.1 +++ netinet/igmp.c 7 Mar 2002 07:23:22 -0000 @@ -146,9 +146,10 @@ } void -igmp_input(m, off, proto) +igmp_input(m, off, proto, vimp) register struct mbuf *m; int off, proto; + void *vimp; { register int iphlen = off; register struct igmp *igmp; @@ -336,7 +337,7 @@ * Pass all valid IGMP packets up to any process(es) listening * on a raw IGMP socket. */ - rip_input(m, off, proto); + rip_input(m, off, proto, vimp); } void Index: netinet/igmp_var.h =================================================================== RCS file: /usr/cvs/src/sys/netinet/igmp_var.h,v retrieving revision 1.17 diff -u -r1.17 igmp_var.h --- netinet/igmp_var.h 29 Dec 1999 04:40:59 -0000 1.17 +++ netinet/igmp_var.h 7 Mar 2002 07:23:46 -0000 @@ -86,7 +86,7 @@ #define IGMP_AGE_THRESHOLD 540 void igmp_init __P((void)); -void igmp_input __P((struct mbuf *, int, int)); +void igmp_input __P((struct mbuf *, int, int, void *)); void igmp_joingroup __P((struct in_multi *)); void igmp_leavegroup __P((struct in_multi *)); void igmp_fasttimo __P((void)); Index: netinet/in_gif.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/in_gif.c,v retrieving revision 1.5.2.5 diff -u -r1.5.2.5 in_gif.c --- netinet/in_gif.c 24 Jul 2001 19:10:18 -0000 1.5.2.5 +++ netinet/in_gif.c 7 Mar 2002 07:34:19 -0000 @@ -202,10 +202,11 @@ } void -in_gif_input(m, off, proto) +in_gif_input(m, off, proto, vinp) struct mbuf *m; int off; int proto; + void *vinp; { struct ifnet *gifp = NULL; struct ip *ip; Index: netinet/in_gif.h =================================================================== RCS file: /usr/cvs/src/sys/netinet/in_gif.h,v retrieving revision 1.3.2.2 diff -u -r1.3.2.2 in_gif.h --- netinet/in_gif.h 24 Jul 2001 19:10:18 -0000 1.3.2.2 +++ netinet/in_gif.h 7 Mar 2002 07:34:41 -0000 @@ -37,7 +37,7 @@ extern int ip_gif_ttl; -void in_gif_input __P((struct mbuf *, int off, int proto)); +void in_gif_input __P((struct mbuf *, int off, int proto, void *)); int in_gif_output __P((struct ifnet *, int, struct mbuf *, struct rtentry *)); int gif_encapcheck4 __P((const struct mbuf *, int, int, void *)); Index: netinet/ip_divert.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/ip_divert.c,v retrieving revision 1.42.2.4 diff -u -r1.42.2.4 ip_divert.c --- netinet/ip_divert.c 29 Jul 2001 19:32:40 -0000 1.42.2.4 +++ netinet/ip_divert.c 7 Mar 2002 07:44:31 -0000 @@ -129,7 +129,7 @@ * with that protocol number to enter the system from the outside. */ void -div_input(struct mbuf *m, int off, int proto) +div_input(struct mbuf *m, int off, int proto, void *vinp) { ipstat.ips_noproto++; m_freem(m); Index: netinet/ip_encap.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/ip_encap.c,v retrieving revision 1.1.2.2 diff -u -r1.1.2.2 ip_encap.c --- netinet/ip_encap.c 3 Jul 2001 11:01:46 -0000 1.1.2.2 +++ netinet/ip_encap.c 7 Mar 2002 17:59:44 -0000 @@ -211,7 +211,7 @@ psw = (const struct ipprotosw *)match->psw; if (psw && psw->pr_input) { encap_fillarg(m, match); - (*psw->pr_input)(m, off, proto); + (*psw->pr_input)(m, off, proto, NULL); } else m_freem(m); return; @@ -230,16 +230,17 @@ #endif /* last resort: inject to raw socket */ - rip_input(m, off, proto); + rip_input(m, off, proto, NULL); } #endif #ifdef INET6 int -encap6_input(mp, offp, proto) +encap6_input(mp, offp, proto, vinp) struct mbuf **mp; int *offp; int proto; + void *vinp; { struct mbuf *m = *mp; struct ip6_hdr *ip6; Index: netinet/ip_encap.h =================================================================== RCS file: /usr/cvs/src/sys/netinet/ip_encap.h,v retrieving revision 1.1.2.1 diff -u -r1.1.2.1 ip_encap.h --- netinet/ip_encap.h 15 Jul 2000 07:14:30 -0000 1.1.2.1 +++ netinet/ip_encap.h 7 Mar 2002 07:41:34 -0000 @@ -50,7 +50,7 @@ void encap_init __P((void)); void encap4_input __P((struct mbuf *, ...)); -int encap6_input __P((struct mbuf **, int *, int)); +int encap6_input __P((struct mbuf **, int *, int, void *)); const struct encaptab *encap_attach __P((int, int, const struct sockaddr *, const struct sockaddr *, const struct sockaddr *, const struct sockaddr *, const struct protosw *, void *)); Index: netinet/ip_fw.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/ip_fw.c,v retrieving revision 1.131.2.30 diff -u -r1.131.2.30 ip_fw.c --- netinet/ip_fw.c 7 Jan 2002 22:40:22 -0000 1.131.2.30 +++ netinet/ip_fw.c 7 Mar 2002 18:27:30 -0000 @@ -227,7 +227,7 @@ static int ip_fw_chk (struct ip **pip, int hlen, struct ifnet *oif, u_int16_t *cookie, struct mbuf **m, struct ip_fw **flow_id, - struct sockaddr_in **next_hop); + struct sockaddr_in **next_hop, struct inpcb **inpp); static int ip_fw_ctl (struct sockopt *sopt); ip_dn_ruledel_t *ip_dn_ruledel_ptr = NULL; @@ -1059,7 +1059,7 @@ ip_fw_chk(struct ip **pip, int hlen, struct ifnet *oif, u_int16_t *cookie, struct mbuf **m, struct ip_fw **flow_id, - struct sockaddr_in **next_hop) + struct sockaddr_in **next_hop, struct inpcb **inpp) { struct ip_fw *f = NULL; /* matching rule */ struct ip *ip = *pip; @@ -1298,10 +1298,13 @@ P = in_pcblookup_hash(&tcbinfo, dst_ip, dst_port, src_ip, src_port, 0, oif); - else + else { P = in_pcblookup_hash(&tcbinfo, src_ip, src_port, dst_ip, dst_port, 0, NULL); + if( inpp) + *inpp = P; + } if (P && P->inp_socket) { if (f->fw_flg & IP_FW_F_UID) { @@ -1327,10 +1330,13 @@ P = in_pcblookup_hash(&udbinfo, dst_ip, dst_port, src_ip, src_port, 1, oif); - else + else { P = in_pcblookup_hash(&udbinfo, src_ip, src_port, dst_ip, dst_port, 1, NULL); + if( inpp) + *inpp = P; + } if (P && P->inp_socket) { if (f->fw_flg & IP_FW_F_UID) { Index: netinet/ip_fw.h =================================================================== RCS file: /usr/cvs/src/sys/netinet/ip_fw.h,v retrieving revision 1.47.2.10 diff -u -r1.47.2.10 ip_fw.h --- netinet/ip_fw.h 3 Nov 2001 00:36:09 -0000 1.47.2.10 +++ netinet/ip_fw.h 7 Mar 2002 18:15:01 -0000 @@ -335,7 +335,7 @@ struct ip; struct sockopt; typedef int ip_fw_chk_t (struct ip **, int, struct ifnet *, u_int16_t *, - struct mbuf **, struct ip_fw **, struct sockaddr_in **); + struct mbuf **, struct ip_fw **, struct sockaddr_in **, struct inpcb **); typedef int ip_fw_ctl_t (struct sockopt *); extern ip_fw_chk_t *ip_fw_chk_ptr; extern ip_fw_ctl_t *ip_fw_ctl_ptr; Index: netinet/ip_icmp.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/ip_icmp.c,v retrieving revision 1.39.2.14 diff -u -r1.39.2.14 ip_icmp.c --- netinet/ip_icmp.c 14 Jan 2002 07:54:35 -0000 1.39.2.14 +++ netinet/ip_icmp.c 7 Mar 2002 07:25:59 -0000 @@ -237,9 +237,10 @@ * Process a received ICMP message. */ void -icmp_input(m, off, proto) +icmp_input(m, off, proto, vinp) register struct mbuf *m; int off, proto; + void *vinp; { int hlen = off; register struct icmp *icp; @@ -584,7 +585,7 @@ } raw: - rip_input(m, off, proto); + rip_input(m, off, proto, vinp); return; freeit: Index: netinet/ip_icmp.h =================================================================== RCS file: /usr/cvs/src/sys/netinet/ip_icmp.h,v retrieving revision 1.16 diff -u -r1.16 ip_icmp.h --- netinet/ip_icmp.h 29 Dec 1999 04:41:01 -0000 1.16 +++ netinet/ip_icmp.h 7 Mar 2002 07:26:21 -0000 @@ -186,7 +186,7 @@ #ifdef _KERNEL void icmp_error __P((struct mbuf *, int, int, n_long, struct ifnet *)); -void icmp_input __P((struct mbuf *, int, int)); +void icmp_input __P((struct mbuf *, int, int, void *)); #endif #endif Index: netinet/ip_input.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/ip_input.c,v retrieving revision 1.130.2.31 diff -u -r1.130.2.31 ip_input.c --- netinet/ip_input.c 15 Dec 2001 01:06:27 -0000 1.130.2.31 +++ netinet/ip_input.c 7 Mar 2002 18:09:49 -0000 @@ -282,6 +282,7 @@ u_int32_t divert_info = 0; /* packet divert/tee info */ #endif struct ip_fw *rule = NULL; + struct inpcb *inp = NULL; /* pre-cache inpcb, if any */ #ifdef IPDIVERT /* Get and reset firewall cookie */ @@ -434,7 +435,8 @@ * produced by the firewall. */ i = ip_fw_chk_ptr(&ip, - hlen, NULL, &divert_cookie, &m, &rule, &ip_fw_fwd_addr); + hlen, NULL, &divert_cookie, &m, &rule, &ip_fw_fwd_addr, + &inp); if ( (i & IP_FW_PORT_DENY_FLAG) || m == NULL) { /* drop */ if (m) m_freem(m); @@ -812,7 +814,7 @@ { int off = hlen, nh = ip->ip_p; - (*inetsw[ip_protox[ip->ip_p]].pr_input)(m, off, nh); + (*inetsw[ip_protox[ip->ip_p]].pr_input)(m, off, nh, inp); #ifdef IPFIREWALL_FORWARD ip_fw_fwd_addr = NULL; /* tcp needed it */ #endif Index: netinet/ip_mroute.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/ip_mroute.c,v retrieving revision 1.56.2.3 diff -u -r1.56.2.3 ip_mroute.c --- netinet/ip_mroute.c 7 Dec 2001 09:23:11 -0000 1.56.2.3 +++ netinet/ip_mroute.c 7 Mar 2002 07:32:49 -0000 @@ -118,10 +118,11 @@ int (*mrt_ioctl)(int, caddr_t, struct proc *) = _mrt_ioctl; void -rsvp_input(m, off, proto) /* XXX must fixup manually */ +rsvp_input(m, off, proto, vinp) /* XXX must fixup manually */ struct mbuf *m; int off; int proto; + void *vinp; { /* Can still get packets with rsvp_on = 0 if there is a local member * of the group to which the RSVP packet is addressed. But in this @@ -135,15 +136,17 @@ if (ip_rsvpd != NULL) { if (rsvpdebug) printf("rsvp_input: Sending packet up old-style socket\n"); - rip_input(m, off, proto); + rip_input(m, off, proto, vinp); return; } /* Drop the packet */ m_freem(m); } -void ipip_input(struct mbuf *m, int off, int proto) { /* XXX must fixup manually */ - rip_input(m, off, proto); +/* XXX must fixup manually */ +void ipip_input(struct mbuf *m, int off, int proto, void *vinp) +{ + rip_input(m, off, proto, vinp); } int (*legal_vif_num)(int) = 0; @@ -1615,13 +1618,14 @@ */ void #ifdef MROUTE_LKM -X_ipip_input(m, off, proto) +X_ipip_input(m, off, proto, vinp) #else -ipip_input(m, off, proto) +ipip_input(m, off, proto, vinp) #endif register struct mbuf *m; int off; int proto; + void *vinp; { struct ifnet *ifp = m->m_pkthdr.rcvif; register struct ip *ip = mtod(m, struct ip *); @@ -1631,7 +1635,7 @@ register struct vif *vifp; if (!have_encap_tunnel) { - rip_input(m, off, proto); + rip_input(m, off, proto, vinp); return; } /* @@ -2125,10 +2129,11 @@ } void -rsvp_input(m, off, proto) +rsvp_input(m, off, proto, vinp) struct mbuf *m; int off; int proto; + void *vinp; { int vifi; register struct ip *ip = mtod(m, struct ip *); @@ -2173,7 +2178,7 @@ if (ip_rsvpd != NULL) { if (rsvpdebug) printf("rsvp_input: Sending packet up old-style socket\n"); - rip_input(m, off, proto); /* xxx */ + rip_input(m, off, proto, vinp); /* xxx */ } else { if (rsvpdebug && vifi == numvifs) printf("rsvp_input: Can't find vif for packet.\n"); Index: netinet/ip_output.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/ip_output.c,v retrieving revision 1.99.2.24 diff -u -r1.99.2.24 ip_output.c --- netinet/ip_output.c 28 Dec 2001 10:08:33 -0000 1.99.2.24 +++ netinet/ip_output.c 7 Mar 2002 18:15:33 -0000 @@ -577,7 +577,7 @@ struct sockaddr_in *old = dst; off = ip_fw_chk_ptr(&ip, - hlen, ifp, &divert_cookie, &m, &rule, &dst); + hlen, ifp, &divert_cookie, &m, &rule, &dst, NULL); /* * On return we must do the following: * IP_FW_PORT_DENY_FLAG -> drop the pkt (XXX new) Index: netinet/ip_var.h =================================================================== RCS file: /usr/cvs/src/sys/netinet/ip_var.h,v retrieving revision 1.50.2.5 diff -u -r1.50.2.5 ip_var.h --- netinet/ip_var.h 7 Dec 2001 09:23:14 -0000 1.50.2.5 +++ netinet/ip_var.h 7 Mar 2002 07:45:04 -0000 @@ -176,12 +176,12 @@ ip_randomid __P((void)); #endif int rip_ctloutput __P((struct socket *, struct sockopt *)); -void rip_ctlinput __P((int, struct sockaddr *, void *)); +void rip_ctlinput __P((int, struct sockaddr *, void *, void *)); void rip_init __P((void)); -void rip_input __P((struct mbuf *, int, int)); +void rip_input __P((struct mbuf *, int, int, void *)); int rip_output __P((struct mbuf *, struct socket *, u_long)); -void ipip_input __P((struct mbuf *, int, int)); -void rsvp_input __P((struct mbuf *, int, int)); +void ipip_input __P((struct mbuf *, int, int, void *)); +void rsvp_input __P((struct mbuf *, int, int, void *)); int ip_rsvp_init __P((struct socket *)); int ip_rsvp_done __P((void)); int ip_rsvp_vif_init __P((struct socket *, struct sockopt *)); @@ -190,7 +190,7 @@ #ifdef IPDIVERT void div_init __P((void)); -void div_input __P((struct mbuf *, int, int)); +void div_input __P((struct mbuf *, int, int, void *)); void divert_packet __P((struct mbuf *, int, int)); extern struct pr_usrreqs div_usrreqs; extern u_int16_t ip_divert_cookie; Index: netinet/ipprotosw.h =================================================================== RCS file: /usr/cvs/src/sys/netinet/ipprotosw.h,v retrieving revision 1.1 diff -u -r1.1 ipprotosw.h --- netinet/ipprotosw.h 22 Dec 1999 19:13:23 -0000 1.1 +++ netinet/ipprotosw.h 7 Mar 2002 04:31:56 -0000 @@ -79,11 +79,11 @@ short pr_protocol; /* protocol number */ short pr_flags; /* see below */ /* protocol-protocol hooks */ - void (*pr_input) __P((struct mbuf *, int off, int proto)); + void (*pr_input) __P((struct mbuf *, int off, int proto, void *)); /* input to protocol (from below) */ int (*pr_output) __P((struct mbuf *m, struct socket *so)); /* output to protocol (from above) */ - void (*pr_ctlinput)__P((int, struct sockaddr *, void *)); + void (*pr_ctlinput)__P((int, struct sockaddr *, void *, void *)); /* control input (from below) */ int (*pr_ctloutput)__P((struct socket *, struct sockopt *)); /* control output (from above) */ Index: netinet/raw_ip.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/raw_ip.c,v retrieving revision 1.64.2.10 diff -u -r1.64.2.10 raw_ip.c --- netinet/raw_ip.c 26 Nov 2001 10:07:57 -0000 1.64.2.10 +++ netinet/raw_ip.c 7 Mar 2002 07:32:20 -0000 @@ -113,9 +113,10 @@ * mbuf chain. */ void -rip_input(m, off, proto) +rip_input(m, off, proto, vimp) struct mbuf *m; int off, proto; + void *vimp; { register struct ip *ip = mtod(m, struct ip *); register struct inpcb *inp; @@ -396,10 +397,11 @@ * interface routes. */ void -rip_ctlinput(cmd, sa, vip) +rip_ctlinput(cmd, sa, vip, vinp) int cmd; struct sockaddr *sa; void *vip; + void *vinp; { struct in_ifaddr *ia; struct ifnet *ifp; Index: netinet/tcp_input.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.107.2.20 diff -u -r1.107.2.20 tcp_input.c --- netinet/tcp_input.c 14 Dec 2001 20:21:12 -0000 1.107.2.20 +++ netinet/tcp_input.c 7 Mar 2002 18:34:55 -0000 @@ -321,15 +321,16 @@ return IPPROTO_DONE; } - tcp_input(m, *offp, proto); + tcp_input(m, *offp, proto, NULL); return IPPROTO_DONE; } #endif void -tcp_input(m, off0, proto) +tcp_input(m, off0, proto, vinp) register struct mbuf *m; int off0, proto; + void *vinp; { register struct tcphdr *th; register struct ip *ip = NULL; @@ -544,8 +545,11 @@ m->m_pkthdr.rcvif); else #endif /* INET6 */ - inp = in_pcblookup_hash(&tcbinfo, ip->ip_src, th->th_sport, - ip->ip_dst, th->th_dport, 1, m->m_pkthdr.rcvif); + if( vinp != NULL) + inp = vinp; /* use cached value */ + else + inp = in_pcblookup_hash(&tcbinfo, ip->ip_src, th->th_sport, + ip->ip_dst, th->th_dport, 1, m->m_pkthdr.rcvif); } #ifdef IPSEC Index: netinet/tcp_subr.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/tcp_subr.c,v retrieving revision 1.73.2.23 diff -u -r1.73.2.23 tcp_subr.c --- netinet/tcp_subr.c 14 Dec 2001 20:21:12 -0000 1.73.2.23 +++ netinet/tcp_subr.c 7 Mar 2002 05:05:03 -0000 @@ -972,10 +972,11 @@ void -tcp_ctlinput(cmd, sa, vip) +tcp_ctlinput(cmd, sa, vip, vinp) int cmd; struct sockaddr *sa; void *vip; + void *vinp; { struct ip *ip = vip; struct tcphdr *th; Index: netinet/tcp_var.h =================================================================== RCS file: /usr/cvs/src/sys/netinet/tcp_var.h,v retrieving revision 1.56.2.10 diff -u -r1.56.2.10 tcp_var.h --- netinet/tcp_var.h 14 Dec 2001 20:21:12 -0000 1.56.2.10 +++ netinet/tcp_var.h 7 Mar 2002 05:17:04 -0000 @@ -437,7 +437,7 @@ void tcp_canceltimers __P((struct tcpcb *)); struct tcpcb * tcp_close __P((struct tcpcb *)); -void tcp_ctlinput __P((int, struct sockaddr *, void *)); +void tcp_ctlinput __P((int, struct sockaddr *, void *, void *)); int tcp_ctloutput __P((struct socket *, struct sockopt *)); struct tcpcb * tcp_drop __P((struct tcpcb *, int)); @@ -446,7 +446,7 @@ struct rmxp_tao * tcp_gettaocache __P((struct in_conninfo *)); void tcp_init __P((void)); -void tcp_input __P((struct mbuf *, int, int)); +void tcp_input __P((struct mbuf *, int, int, void *)); void tcp_mss __P((struct tcpcb *, int)); int tcp_mssopt __P((struct tcpcb *)); void tcp_drop_syn_sent __P((struct inpcb *, int)); Index: netinet/udp_usrreq.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/udp_usrreq.c,v retrieving revision 1.64.2.15 diff -u -r1.64.2.15 udp_usrreq.c --- netinet/udp_usrreq.c 29 Oct 2001 19:28:43 -0000 1.64.2.15 +++ netinet/udp_usrreq.c 7 Mar 2002 18:35:08 -0000 @@ -148,9 +148,10 @@ } void -udp_input(m, off, proto) +udp_input(m, off, proto, vinp) register struct mbuf *m; int off, proto; + void *vinp; { int iphlen = off; register struct ip *ip; @@ -339,8 +340,11 @@ /* * Locate pcb for datagram. */ - inp = in_pcblookup_hash(&udbinfo, ip->ip_src, uh->uh_sport, - ip->ip_dst, uh->uh_dport, 1, m->m_pkthdr.rcvif); + if (vinp != NULL) + inp = vinp; /* use cached value */ + else + inp = in_pcblookup_hash(&udbinfo, ip->ip_src, uh->uh_sport, + ip->ip_dst, uh->uh_dport, 1, m->m_pkthdr.rcvif); if (inp == NULL) { if (log_in_vain) { char buf[4*sizeof "123"]; @@ -502,10 +506,11 @@ } void -udp_ctlinput(cmd, sa, vip) +udp_ctlinput(cmd, sa, vip, vinp) int cmd; struct sockaddr *sa; void *vip; + void *vinp; { struct ip *ip = vip; struct udphdr *uh; Index: netinet/udp_var.h =================================================================== RCS file: /usr/cvs/src/sys/netinet/udp_var.h,v retrieving revision 1.22.2.1 diff -u -r1.22.2.1 udp_var.h --- netinet/udp_var.h 18 Feb 2001 07:12:25 -0000 1.22.2.1 +++ netinet/udp_var.h 7 Mar 2002 05:17:48 -0000 @@ -103,9 +103,9 @@ extern struct udpstat udpstat; extern int log_in_vain; -void udp_ctlinput __P((int, struct sockaddr *, void *)); +void udp_ctlinput __P((int, struct sockaddr *, void *, void *)); void udp_init __P((void)); -void udp_input __P((struct mbuf *, int, int)); +void udp_input __P((struct mbuf *, int, int, void *)); void udp_notify __P((struct inpcb *inp, int errno)); int udp_shutdown __P((struct socket *so)); --------------87879C4452F25813094EB958-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 7 10:59: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by hub.freebsd.org (Postfix) with SMTP id B1F4237B400 for ; Thu, 7 Mar 2002 10:59:02 -0800 (PST) Received: from kshitijgunjikar (AUTH poptime) at unknown (HELO kshitij) (203.124.128.243) by smtp.mail.vip.sc5.yahoo.com with SMTP; 7 Mar 2002 09:55:01 -0000 From: "Kshitij Gunjikar" To: Subject: icmp related question Date: Thu, 7 Mar 2002 15:35:05 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi All, Hi I'm studying code for ICMP . there is a piece of code in icmp_input which just returns when we find the ICMP packet length lesser than allowed. if (icmplen < ICMP_MINLEN) { icmpstat.icps_tooshort++; goto freeit; } i = hlen + min(icmplen, ICMP_ADVLENMIN); if (m->m_len < i && (m = m_pullup(m, i)) == 0) { icmpstat.icps_tooshort++; return; } where #define ICMPADVELMIN (8 + sizeof(struct ip) + 8) and icmplen = ip->ip_len ; why the return? Shouldn't there be a freeing of the msg.i.e call the m_freem(m) instead of return ? Can anybody please shed light on this ? Thanks. Regards Kshitij _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.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 7 11:36:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from mule.icir.org (mule.icir.org [192.150.187.28]) by hub.freebsd.org (Postfix) with ESMTP id 3735737B404; Thu, 7 Mar 2002 11:36:19 -0800 (PST) Received: from mule.icir.org (localhost [127.0.0.1]) by mule.icir.org (8.11.6/8.11.3) with ESMTP id g27JaJw38650; Thu, 7 Mar 2002 11:36:19 -0800 (PST) (envelope-from hodson@mule.icir.org) Message-Id: <200203071936.g27JaJw38650@mule.icir.org> X-Mailer: exmh version 2.1.1 10/15/1999 X-Exmh-Isig-CompType: unknown X-Exmh-Isig-Folder: xorp-dev From: Orion Hodson To: freebsd-net@freebsd.org Cc: orion@freebsd.org Subject: Pre-emptive ARP refresh Mime-Version: 1.0 Content-Type: text/plain Date: Thu, 07 Mar 2002 11:36:19 -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 There is a very minor issue with our ARP implementation and it's refresh behaviour. At present, entries in the ARP cache timeout and are removed from the cache. The number of packets buffered from a host with an incomplete entry in the ARP table is limited to 1, so high packet rate sources therefore experience drops when their ARP entry times out. This was reported in kern/25517 and pointed out on the IETF AVT mailing yesterday: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/25517 http://www.ietf.org/mail-archive/working-groups/avt/current/msg00850.html A simple fix would be to send ARP requests about a host before it times out if that host is exchanging packets with us. An example of how this might be done (relative to -STABLE) is: http://people.freebsd.org/~orion/if_ether.c.1.64.2.17.arp-patch For an entry in the cache that is sending data it sends an ARP request every arpt_down seconds for up to a maximum arp_maxtries before the entry times out. This is in the spirit of what's described in the last three paragraphs of RFC826. Does this seem reasonable? Kind Regards - Orion To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 7 12:28:41 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id BC56337B41A; Thu, 7 Mar 2002 12:28:11 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g27KSBU01868; Thu, 7 Mar 2002 12:28:11 -0800 (PST) (envelope-from rizzo) Date: Thu, 7 Mar 2002 12:28:11 -0800 From: Luigi Rizzo To: Orion Hodson Cc: freebsd-net@FreeBSD.ORG Subject: Re: Pre-emptive ARP refresh Message-ID: <20020307122811.B1614@iguana.icir.org> References: <200203071936.g27JaJw38650@mule.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200203071936.g27JaJw38650@mule.icir.org> User-Agent: Mutt/1.3.23i 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 am not totally sure about the fix you propose. If you send a preemptive refresh request when the entry is about to timeout, how do you let an arp table entry go away, other than hoping that the host goes down ? This might be a problem with a busy host on a large switched lan (there are some large ones around). I'd rather see something like the following (along the lines of what Steve Casner suggested): 1) do lazy deletion of arp cache entries (much like ipfw/dummynet does with dynamic rules and pipes); 2) when an entry has expired but there is state about it, keep using the cached value for some grace period from the last transmission, while you send ARP requests and wait for the replies to come back. 3) possibly refresh ARP entries on incoming input packets. This should not be terribly expensive if we link the inpcb to the arp entry somehow. Not sure if #1 and #3 are already implemented. cheers luigi On Thu, Mar 07, 2002 at 11:36:19AM -0800, Orion Hodson wrote: > > There is a very minor issue with our ARP implementation and it's > refresh behaviour. At present, entries in the ARP cache timeout and > are removed from the cache. The number of packets buffered from a > host with an incomplete entry in the ARP table is limited to 1, so > high packet rate sources therefore experience drops when their ARP > entry times out. > > This was reported in kern/25517 and pointed out on the IETF AVT > mailing yesterday: > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/25517 > http://www.ietf.org/mail-archive/working-groups/avt/current/msg00850.html > > A simple fix would be to send ARP requests about a host before it > times out if that host is exchanging packets with us. An example of > how this might be done (relative to -STABLE) is: > > http://people.freebsd.org/~orion/if_ether.c.1.64.2.17.arp-patch > > For an entry in the cache that is sending data it sends an ARP request > every arpt_down seconds for up to a maximum arp_maxtries before the > entry times out. This is in the spirit of what's described in the > last three paragraphs of RFC826. > > Does this seem reasonable? > > Kind Regards > - Orion > > > > 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 7 12:31:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtpout.mac.com (smtpout.mac.com [204.179.120.89]) by hub.freebsd.org (Postfix) with ESMTP id 036C737B404 for ; Thu, 7 Mar 2002 12:31:13 -0800 (PST) Received: from smtp-relay01.mac.com (server-source-si02 [10.13.10.6]) by smtpout.mac.com (8.12.1/8.10.2/1.0) with ESMTP id g27KVCth000556 for ; Thu, 7 Mar 2002 12:31:12 -0800 (PST) Received: from asmtp01.mac.com ([10.13.10.65]) by smtp-relay01.mac.com (Netscape Messaging Server 4.15 relay01 Jun 21 2001 23:53:48) with ESMTP id GSMEC000.FQF for ; Thu, 7 Mar 2002 12:31:12 -0800 Received: from grinch ([12.234.224.67]) by asmtp01.mac.com (Netscape Messaging Server 4.15 asmtp01 Jun 21 2001 23:53:48) with ESMTP id GSMEBZ00.E9E for ; Thu, 7 Mar 2002 12:31:11 -0800 Date: Thu, 7 Mar 2002 12:31:10 -0800 Subject: Re: icmp related question Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v475) From: "Justin C. Walker" To: Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <42D1F914-320A-11D6-BB09-00306544D642@mac.com> X-Mailer: Apple Mail (2.475) 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 Thursday, March 7, 2002, at 02:05 AM, Kshitij Gunjikar wrote: > Hi All, > Hi I'm studying code for ICMP . > > there is a piece of code in icmp_input which just returns when we find > the > ICMP packet length lesser than allowed. > > if (icmplen < ICMP_MINLEN) { > icmpstat.icps_tooshort++; > goto freeit; > } > i = hlen + min(icmplen, ICMP_ADVLENMIN); > if (m->m_len < i && (m = m_pullup(m, i)) == 0) { > icmpstat.icps_tooshort++; > return; > } > where #define ICMPADVELMIN (8 + sizeof(struct ip) + 8) > and icmplen = ip->ip_len ; > > > why the return? Shouldn't there be a freeing of the msg.i.e call the > m_freem(m) instead of return ? If you look at the last 'if' statement, you'll notice that the call to m_pullup() has returned NULL, which means that the mbuf has been freed already (or, in any case, at this point in the code, there is no mbuf to free, due to the assignment). Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | When LuteFisk is outlawed | Only outlaws will have | LuteFisk *--------------------------------------*-------------------------------* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 7 15:20: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 7D36D37B487 for ; Thu, 7 Mar 2002 15:18:56 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.6) id g27NIn006328; Thu, 7 Mar 2002 18:18:49 -0500 (EST) (envelope-from wollman) Date: Thu, 7 Mar 2002 18:18:49 -0500 (EST) From: Garrett Wollman Message-Id: <200203072318.g27NIn006328@khavrinen.lcs.mit.edu> To: "George V. Neville-Neil" Cc: FreeBSD Networking Subject: Re: How can I give one route priority over the other route ? In-Reply-To: <200203040210.g242ARBu093357@m2.mv.meer.net> References: <5.1.0.14.0.20020304025555.02c9eac8@mail.drwilco.net> <200203040210.g242ARBu093357@m2.mv.meer.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: > This is an issue with the routing system design. Many routers > allow duplicate routes (same netmask) that have different priorities. > This makes it quicker to switch routes during a failure. FreeBSD permits this as well. It is the responsibility of the routing process to manage which specific route is installed in the kernel forwarding table at any given time. (FreeBSD's `routed' can do this in some instances.) FreeBSD does not directly support multiple static routes to a given destination, since it has no knowledge which would enable it to choose among them; again, a routing process can be used to manage this. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 7 15:34:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from outboundx.mv.meer.net (outboundx.mv.meer.net [209.157.152.12]) by hub.freebsd.org (Postfix) with ESMTP id E781A37B400 for ; Thu, 7 Mar 2002 15:34:21 -0800 (PST) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outboundx.mv.meer.net (8.11.6/8.11.6) with ESMTP id g27NYGs12000; Thu, 7 Mar 2002 15:34:16 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from neville-neil.com ([209.157.133.226]) by mail.meer.net (8.12.1/8.12.1/meer) with ESMTP id g27NYGcI087209; Thu, 7 Mar 2002 15:34:21 -0800 (PST) Message-Id: <200203072334.g27NYGcI087209@mail.meer.net> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Garrett Wollman Cc: FreeBSD Networking Subject: Re: How can I give one route priority over the other route ? In-Reply-To: Message from Garrett Wollman of "Thu, 07 Mar 2002 18:18:49 EST." <200203072318.g27NIn006328@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Mar 2002 15:34:16 -0800 From: "George V. Neville-Neil" 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 an issue with the routing system design. Many routers > > allow duplicate routes (same netmask) that have different priorities. > > This makes it quicker to switch routes during a failure. > > FreeBSD permits this as well. It is the responsibility of the routing > process to manage which specific route is installed in the kernel > forwarding table at any given time. (FreeBSD's `routed' can do this > in some instances.) FreeBSD does not directly support multiple static > routes to a given destination, since it has no knowledge which would > enable it to choose among them; again, a routing process can be used > to manage this. FreeBSD permits this so long as you write a program to do it. The kernel table is not really a routing table as many networking folks would define it. It's a forwarding table mixed with other things. In many routing systems there is a routing table that multiple routing processes can share. It is a common database and is treated as such. It is from this arena that such questions arise. The way things work in FreeBSD is that you run a single routing process (Zebra, Routed, GateD etc.) that maintains a real routing database and then periodically pushing things down into the kernel. Later, George -- George V. Neville-Neil gnn@neville-neil.com NIC:GN82 "Those who would trade liberty for temporary security deserve neither" - Benjamin Franklin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 7 19:37:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 70B3237B402; Thu, 7 Mar 2002 19:37:24 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1098) id 415D2AE265; Thu, 7 Mar 2002 19:37:24 -0800 (PST) Date: Thu, 7 Mar 2002 19:37:24 -0800 From: Bill Fumerola To: Julian Elischer , Terry Lambert Cc: green@freebsd.org, net@freebsd.org, hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times Message-ID: <20020308033724.GZ803@elvis.mu.org> References: <20020307092848.GX803@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-Operating-System: FreeBSD 4.5-MUORG-20020215 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 On Thu, Mar 07, 2002 at 03:51:41AM -0800, Julian Elischer wrote: > what would be even nicer is if ipfw found the cached entry and passed it > back to ip_input so it didn't need to :-) i think this entire idea of cacheing it in ip_input() is a bad idea, no offense terry. first, having a uid or gid rule in your ipfw ruleset (or even running ipfw) certainly isn't the common case. we're now going to bloat the ip_fw_chk() calls protocol handler calls to add an arguement that 99% of time is going to be NULL. then you have to bloat the protocol handlers to check if that pointer, that is NULL 99% of the time, isn't NULL. i just don't think that the gain in the edge case justifies the slowdown in the common case. the first person to say 'sysctl' or '#ifdef' gets to drink from the fire hose. second, the real travesty is that if you have N rules in ipfw that reference a uid or gid, you will do a pcb lookup on the same packet for each of those N rules until you match. the worst case scenario of having to do a lookup for each uid rule is what the charts in my previous post measure. terry asked in his post: "NB: Is there a particular reason Bill's changes haven't simply been committed?", the reason is that my cache of the pcb and uid was done in my compiledipfw code, not the mainline ipfw. its really not a straight port because of somethings that compiledipfw keeps state on before generating code (skiptos, mostly); ipfw would have to be more careful then the generated code needs to be. if brian feldman (the author of the ipfw uid/gid code) doesn't fix this out of embarassment first, i'll backport my cache into the main ipfw code. -- - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org / billf@mu.org - my anger management counselor can beat up your self-affirmation therapist To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 7 20: 3:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id C731A37B405; Thu, 7 Mar 2002 20:03:31 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id g2843JD42713; Thu, 7 Mar 2002 23:03:19 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 7 Mar 2002 23:03:19 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Bill Fumerola Cc: Julian Elischer , Terry Lambert , green@freebsd.org, net@freebsd.org, hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times In-Reply-To: <20020308033724.GZ803@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org A couple of comments: - You can always cache the pcb the first time it's used, and then have it available for future use. I agree with your concerns about generating it every time -- that would be a disaster for routers where no packets are even delivered locally. :-) - The uid/gid code is broken for a number of important applications, including SSH forwarding, because SSHd binds the socket using a root credential rather than the user credential. Arguably, this is a bug with SSHd, and it also breaks a number of other things including the MAC support we're adding to 5.0-CURRENT. Also, it had some *evil* bugs involving NFS that I recently fixed in 5.0-CURRENT, where sockets were rebound using the credential of the user making the VFS operation, resulting in ipfw uid/gid rules dropping/rate-limiting file system requests for all users. For those running into the whole sshd tunnel and ident problem, it's the same cause. Now we have a combined pcred/ucred in ucred, in theory the rules could also act on effective/real/saved credentials, although that might not be useful. Actually, it arguably might be for setuid network tools. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services On Thu, 7 Mar 2002, Bill Fumerola wrote: > On Thu, Mar 07, 2002 at 03:51:41AM -0800, Julian Elischer wrote: > > what would be even nicer is if ipfw found the cached entry and passed it > > back to ip_input so it didn't need to :-) > > i think this entire idea of cacheing it in ip_input() is a bad idea, no > offense terry. > > first, having a uid or gid rule in your ipfw ruleset (or even running > ipfw) certainly isn't the common case. we're now going to bloat the > ip_fw_chk() calls protocol handler calls to add an arguement that 99% > of time is going to be NULL. then you have to bloat the protocol handlers > to check if that pointer, that is NULL 99% of the time, isn't NULL. > > i just don't think that the gain in the edge case justifies the slowdown > in the common case. the first person to say 'sysctl' or '#ifdef' gets > to drink from the fire hose. > > second, the real travesty is that if you have N rules in ipfw that > reference a uid or gid, you will do a pcb lookup on the same packet for > each of those N rules until you match. the worst case scenario of having > to do a lookup for each uid rule is what the charts in my previous post > measure. > > terry asked in his post: "NB: Is there a particular reason Bill's changes > haven't simply been committed?", the reason is that my cache of the pcb > and uid was done in my compiledipfw code, not the mainline ipfw. its > really not a straight port because of somethings that compiledipfw keeps > state on before generating code (skiptos, mostly); ipfw would have to > be more careful then the generated code needs to be. > > if brian feldman (the author of the ipfw uid/gid code) doesn't fix this > out of embarassment first, i'll backport my cache into the main ipfw > code. > > -- > - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org / billf@mu.org > - my anger management counselor can beat up your self-affirmation therapist > > > > 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 7 21:15:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 5B99C37B405; Thu, 7 Mar 2002 21:15:20 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1098) id 245A4AE211; Thu, 7 Mar 2002 21:15:20 -0800 (PST) Date: Thu, 7 Mar 2002 21:15:20 -0800 From: Bill Fumerola To: Robert Watson Cc: Julian Elischer , Terry Lambert , green@freebsd.org, net@freebsd.org, hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times Message-ID: <20020308051520.GB803@elvis.mu.org> Reply-To: Bill Fumerola References: <20020308033724.GZ803@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-Operating-System: FreeBSD 4.5-MUORG-20020215 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 On Thu, Mar 07, 2002 at 11:03:19PM -0500, Robert Watson wrote: > A couple of comments: > > - You can always cache the pcb the first time it's used, and then have it > available for future use. I agree with your concerns about generating > it every time -- that would be a disaster for routers where no packets > are even delivered locally. :-) you can't cache it and make it available for future use without making the invasive changes that i mention: > > first, having a uid or gid rule in your ipfw ruleset (or even running > > ipfw) certainly isn't the common case. we're now going to bloat the > > ip_fw_chk() calls protocol handler calls to add an arguement that 99% ^-- "and" > > of time is going to be NULL. then you have to bloat the protocol handlers > > to check if that pointer, that is NULL 99% of the time, isn't NULL. i think that ip_fw_chk() taking _8_ arguments is getting a bit obscene. adding another one to the protocol handlers doesn't seem like a great idea either. we're talking about an optimization that less then .1% of our userbase will ever take advantage of v. a pessimization (additional argument in the protocol handler + check of that arguement in the handler) in the critical path of packet delivery in ALL cases (even kernels w/o ipfw). it's just not worth it. with ipfw cacheing the pcb lookup + credential check and w/o terry's patch, the worst case would be a ruleset with any uid/gid rules: a pcb lookup being done twice (once ever in ipfw, once in the protocol handler). that's really not so bad compared with the current behavior with uid/gid rules where the lookup is done of a lot of times (as many uid/gid rules you walk through before you match) in ipfw and once in the protocol handler. > - The uid/gid code is broken for a number of important applications, > including SSH forwarding, because SSHd binds the socket using a root > credential rather than the user credential. Arguably, this is a bug > with SSHd, and it also breaks a number of other things including the MAC > support we're adding to 5.0-CURRENT. Also, it had some *evil* bugs > involving NFS that I recently fixed in 5.0-CURRENT, where sockets were > rebound using the credential of the user making the VFS operation, > resulting in ipfw uid/gid rules dropping/rate-limiting file system > requests for all users. For those running into the whole sshd tunnel > and ident problem, it's the same cause. i would like to make my cache have the proper credential(s) rather then just cache the current socket credentials cr_uid, if that's wrong. please let me know privately just what exactly i should be comparing against (or functions i should be using, if an API exists now) in -current with the changes to credentials. when i mfc the cache, i'll just keep the current uid comparing behavior. -- - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org / billf@mu.org - my anger management counselor can beat up your self-affirmation therapist To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 7 22: 1:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 2762F37B417; Thu, 7 Mar 2002 22:00:25 -0800 (PST) Received: from pool0036.cvx21-bradley.dialup.earthlink.net ([209.179.192.36] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16jDQL-0006dx-00; Thu, 07 Mar 2002 22:00:14 -0800 Message-ID: <3C885357.931A4E43@mindspring.com> Date: Thu, 07 Mar 2002 21:59:51 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fumerola Cc: Julian Elischer , green@freebsd.org, net@freebsd.org, hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times References: <20020307092848.GX803@elvis.mu.org> <20020308033724.GZ803@elvis.mu.org> 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 Bill Fumerola wrote: > On Thu, Mar 07, 2002 at 03:51:41AM -0800, Julian Elischer wrote: > > what would be even nicer is if ipfw found the cached entry and passed it > > back to ip_input so it didn't need to :-) > > i think this entire idea of cacheing it in ip_input() is a bad idea, no > offense terry. No, the idea is to cache it when it's looked up, and pass it arounf from ip_input. In the modified firewall code, I have: P = in_pcblookup_hash(&udbinfo, src_ip, src_port, dst_ip, dst_port, 1, NULL); if( inpp) *inpp = P; inside the loop. THis could just as easily be: if (inpp) { if (*inpp) { P = *inpp; } else { P = *inpp = in_pcblookup_hash(&udbinfo, src_ip, src_port, dst_ip, dst_port, 1, NULL); } } else { P = *inpp = in_pcblookup_hash(&udbinfo, src_ip, src_port, dst_ip, dst_port, 1, NULL); } etc., which would cache the lookup. Also, the ip_fw_chk is not necessarily the first thing that gets called that needs to do an in_pcblookup_hash. > first, having a uid or gid rule in your ipfw ruleset (or even running > ipfw) certainly isn't the common case. we're now going to bloat the > ip_fw_chk() calls protocol handler calls to add an arguement that 99% > of time is going to be NULL. That's an extra push and pop. When a UDP or TCP packet is handed off to the upper level code, the cost compared to an additional in_pcblookup_hash call is very, very tiny. If you want to get technical, the same sort of lookup is used in the ip_flow.c code. If ipforwarding is enabled, and there is at least one flow active, then the lookup will happen, as well. > then you have to bloat the protocol handlers to check if > that pointer, that is NULL 99% of the time, isn't NULL. For the TCP and UDP cases, this is true... if the firewall code was not invoked. That's an extra push/pop and compare. > i just don't think that the gain in the edge case justifies the slowdown > in the common case. the first person to say 'sysctl' or '#ifdef' gets > to drink from the fire hose. 8-). Actually, you should ask John Lemon about this; he has splicing code. Splicing needs to do the same sort of lookup. I don't know if Cisco will let him commit it, but if so, that's three cases. > second, the real travesty is that if you have N rules in ipfw that > reference a uid or gid, you will do a pcb lookup on the same packet for > each of those N rules until you match. the worst case scenario of having > to do a lookup for each uid rule is what the charts in my previous post > measure. That's cacheable (per the above). > terry asked in his post: "NB: Is there a particular reason Bill's changes > haven't simply been committed?", the reason is that my cache of the pcb > and uid was done in my compiledipfw code, not the mainline ipfw. its > really not a straight port because of somethings that compiledipfw keeps > state on before generating code (skiptos, mostly); ipfw would have to > be more careful then the generated code needs to be. I think that you could cache the lookup the first time through the loop, in any case, or, even better, before the loop, if the loop is going to be hit (the list of rules is non-empty). > if brian feldman (the author of the ipfw uid/gid code) doesn't fix this > out of embarassment first, i'll backport my cache into the main ipfw > code. I think it's useful to push the cached value up through the stack. In a firewall case, or in a splice case, if you can get the code out of Lemon, or in the ip_flow case for the IP fast forwarding, if the hash is unified properly, we're talking about 1/2 to 1/4 of the overhead for the lookup. Actually, I'd use a global if I thought I could get away with it... ;^)... but the overhead of pushing another pointer and popping it later is really low, compared to the alternative. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 7 22:18:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from creme-brulee.marcuscom.com (rdu57-28-046.nc.rr.com [66.57.28.46]) by hub.freebsd.org (Postfix) with ESMTP id 179AB37B400 for ; Thu, 7 Mar 2002 22:18:36 -0800 (PST) Received: from shumai.marcuscom.com (shumai.marcuscom.com [192.168.1.4]) by creme-brulee.marcuscom.com (8.11.6/8.11.6) with ESMTP id g286HpK48145 for ; Fri, 8 Mar 2002 01:17:51 -0500 (EST) (envelope-from marcus@marcuscom.com) Subject: rt_setgate returning EDQUOT From: Joe Clarke To: freebsd-net@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-OP4KzKbQiJ51tv1dS6aa" X-Mailer: Evolution/1.0.2 Date: 08 Mar 2002 01:18:40 -0500 Message-Id: <1015568320.27447.13.camel@shumai.marcuscom.com> 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 --=-OP4KzKbQiJ51tv1dS6aa Content-Type: multipart/mixed; boundary="=-m4kl+ohjrNwWcQXpTC9u" --=-m4kl+ohjrNwWcQXpTC9u Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Every so often when my VPN link provided by user ppp goes away, and when I restart it I see an error saying that a route cannot be added because my disc quota has been exceeded. This is coming from route.c in the rt_setgate() function at line 1001 on -current. My question is should this be a different error? EDEADLK seems more accurate, or at least EEXIST. Given this doesn't happen often, but it can still be confusing. From man intro(2): "EDQUOT Disc quota exceeded. A write(2) to an ordinary file, the creation of a directory or symbolic link, or the creation of a directory entry failed because the user's quota of disk blocks was exhausted, or the allocation of an inode for a newly created file failed because the user's quota of inodes was exhausted." It doesn't mention anything about a recursive routing problem. Attached are patches for both errnos above. Joe --=-m4kl+ohjrNwWcQXpTC9u Content-Disposition: attachment; filename=route.c.patch.EDEADLK Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --- sys/net/route.c.orig Thu Mar 7 22:40:02 2002 +++ sys/net/route.c Thu Mar 7 22:41:54 2002 @@ -998,7 +998,7 @@ if (rt->rt_gwroute =3D=3D rt) { RTFREE(rt->rt_gwroute); rt->rt_gwroute =3D 0; - return EDQUOT; /* failure */ + return EDEADLK; /* failure */ } } =20 --=-m4kl+ohjrNwWcQXpTC9u Content-Disposition: attachment; filename=route.c.patch.EEXIST Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --- sys/net/route.c.orig Thu Mar 7 22:40:02 2002 +++ sys/net/route.c Thu Mar 7 22:43:56 2002 @@ -998,7 +998,7 @@ if (rt->rt_gwroute =3D=3D rt) { RTFREE(rt->rt_gwroute); rt->rt_gwroute =3D 0; - return EDQUOT; /* failure */ + return EEXIST; /* failure */ } } =20 --=-m4kl+ohjrNwWcQXpTC9u-- --=-OP4KzKbQiJ51tv1dS6aa Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjyIV8AACgkQb2iPiv4Uz4fLXQCdF8XtllCOyREyrt3JYKSY4xKp pDQAoIowJhU//Za8vZnXHRGOkE+wQI51 =9poL -----END PGP SIGNATURE----- --=-OP4KzKbQiJ51tv1dS6aa-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 7 22:24:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id 89C2137B402; Thu, 7 Mar 2002 22:24:25 -0800 (PST) Received: from pool0036.cvx21-bradley.dialup.earthlink.net ([209.179.192.36] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16jDnj-0000k3-00; Thu, 07 Mar 2002 22:24:24 -0800 Message-ID: <3C885900.E1CB18C0@mindspring.com> Date: Thu, 07 Mar 2002 22:24:00 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fumerola Cc: Robert Watson , Julian Elischer , green@freebsd.org, net@freebsd.org, hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times References: <20020308033724.GZ803@elvis.mu.org> <20020308051520.GB803@elvis.mu.org> 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 Bill Fumerola wrote: > i think that ip_fw_chk() taking _8_ arguments is getting a bit obscene. ip_fw_chk should be obscene and not heard? 8-). > we're talking about an optimization that less then .1% of our userbase > will ever take advantage of v. a pessimization (additional argument in > the protocol handler + check of that arguement in the handler) in the > critical path of packet delivery in ALL cases (even kernels w/o ipfw). The check occurs only in the case that an in_pcblookup_hash() of the type needed was imminent. In the failure case, the call is made anyway. The comparative overhead relative to the actual hash lookup itself is miniscule. > it's just not worth it. 8-). The main performance path is going to be ip_flow fast forwarding. Actually, it's tempting to replace the src/src dst/dst hash with a src/src hash with a second level hash for the dst/dst lookup. THis would simplify the wildcard/non-wildcard case, as well as allowing a unification of the search space. If it were just the pcbhash, I think I'd go with a btree... or to make Alfred happy... a skiplist... ;^). > with ipfw cacheing the pcb lookup + credential check and w/o terry's > patch, the worst case would be a ruleset with any uid/gid rules: a pcb > lookup being done twice (once ever in ipfw, once in the protocol handler). > > that's really not so bad compared with the current behavior with uid/gid > rules where the lookup is done of a lot of times (as many uid/gid rules > you walk through before you match) in ipfw and once in the protocol > handler. This is the expensive part that I'd like to avoid. There are actually three hash lookups, if you have the firewall and ipflow code active. > > - The uid/gid code is broken for a number of important applications, > > including SSH forwarding, because SSHd binds the socket using a root > > credential rather than the user credential. [ ... ] > > i would like to make my cache have the proper credential(s) rather then > just cache the current socket credentials cr_uid, if that's wrong. Actually, I think the place to correct this is by allowing the fchown/fchmod on sockets to actually do the right thing... > please let me know privately just what exactly i should be comparing > against (or functions i should be using, if an API exists now) in -current > with the changes to credentials. > > when i mfc the cache, i'll just keep the current uid comparing behavior. The cache is a definite win; I think it should be more general, though. Luigi was talking about adding metadata to mbufs; you *could* tunnel the inp looked up through the metadata on the mbuf on which the data was dereferenced out of for the lookup in the first place. I think it's easier to just pass another parameter. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 8 5:30:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id C0CFA37B423; Fri, 8 Mar 2002 05:30:21 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id g28DThD67687; Fri, 8 Mar 2002 08:29:43 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 8 Mar 2002 08:29:42 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Bill Fumerola Cc: Julian Elischer , Terry Lambert , green@freebsd.org, net@freebsd.org, hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times In-Reply-To: <20020308051520.GB803@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 7 Mar 2002, Bill Fumerola wrote: > On Thu, Mar 07, 2002 at 11:03:19PM -0500, Robert Watson wrote: > > A couple of comments: > > > > - You can always cache the pcb the first time it's used, and then have it > > available for future use. I agree with your concerns about generating > > it every time -- that would be a disaster for routers where no packets > > are even delivered locally. :-) > > you can't cache it and make it available for future use without making > the invasive changes that i mention: Ah, I misread your e-mail. I was interested in caching it within ipfw, but not exporting the cached entry to be reused in ip_input(). My personal feeling is that the notion of uid/gid rules doesn't really fit the model very well at all, but it falles into the category of "interesting hack". > with ipfw cacheing the pcb lookup + credential check and w/o terry's > patch, the worst case would be a ruleset with any uid/gid rules: a pcb > lookup being done twice (once ever in ipfw, once in the protocol > handler). > > that's really not so bad compared with the current behavior with uid/gid > rules where the lookup is done of a lot of times (as many uid/gid rules > you walk through before you match) in ipfw and once in the protocol > handler. Sounds like we agree. > > - The uid/gid code is broken for a number of important applications, > > including SSH forwarding, because SSHd binds the socket using a root > > credential rather than the user credential. Arguably, this is a bug > > with SSHd, and it also breaks a number of other things including the MAC > > support we're adding to 5.0-CURRENT. Also, it had some *evil* bugs > > involving NFS that I recently fixed in 5.0-CURRENT, where sockets were > > rebound using the credential of the user making the VFS operation, > > resulting in ipfw uid/gid rules dropping/rate-limiting file system > > requests for all users. For those running into the whole sshd tunnel > > and ident problem, it's the same cause. > > i would like to make my cache have the proper credential(s) rather then > just cache the current socket credentials cr_uid, if that's wrong. > > please let me know privately just what exactly i should be comparing > against (or functions i should be using, if an API exists now) in > -current with the changes to credentials. > > when i mfc the cache, i'll just keep the current uid comparing behavior. I don't think there is a "proper" set of credentials in most cases. Consider the following cases: (1) Socket-to-socket communication (loop-back packet to another socket) (2) Stack-to-socket communication (icmp version of EHOSTUNREACH) (3) Socket-to-stack communication (resulting in stack response such as icmp version of EHOSTUNREACH) (4) Socket to interface communication (outbound packet to remote host) (5) Interface to socket communication (inbound packet from remote host) (6) Stack to interface communication (connection refused icmp) (7) Interface to stack communication (tcp SYN that will be refused) (8) Interface to interface communication (routed packet) The only situations in which you could argue a credential might be involved are the cases including a socket. Then the question arises: what credential is the right credential? Observe that a socket may be in use by a number of processes, and even the kernel. A credential is always available when the socket is created, and that's generally cached as so->so_cred. However, after that point, the notion of an active credential is ambiguous. When a packet is created on the socket by a process (kernel or otherwise), then potentially that is the "proper" credential for out-going authorization. However, when a packet is received for a socket, you don't know yet which process will be receiving the data, since that's done asynchronously by one of potentially many different credentials listening on the socket. In fact, it may *never* be read. And it gets even more confusing with stream sockets, where different credentials might potentially read the same data. Another pointer: for loopback communication, potentially *two* sockets will match the same packet. Part of what's going on here is that a socket isn't really a subject (credential). It's an object. Subjects put data (either as part of a stream or as datagrams) into the object, and that generates new objects that can't be directly referenced by a subject except through another object (be it another socket, bpf device, whatever). In the MAC implementation, we recognize that a socket is an object, and provide it with a label, which may be managed using socket options. Datagrams generated from the socket generally inherit the same label, although individual policies might do different things. When a datagram is being considered for delivery to a socket, the labels of the mbuf and socket can be used in two ways: (1) to affect the pcb match, and (2) to perform access control on the delivery. This allows policies maximum flexibility in both defining the notion of a "match", and in blocking inappropriate but matching traffic. Likewise, we've hypothesized having ipfw rules that use the labels. That said, I think moving to having uids/gids on sockets may not be a good idea, because most applications would simply not understand how to change them (and the mode on the socket). Part of the confusion would come also from the fact that some sockets have filesystem representations: because a socket is not the same as its filesystem representation, there would be two seperate owner/group/mode sets, and that can be confusing for the developer. We accept that confusion for the MAC code, because it's required, but for uid/gid rules, just using a cached credential may be a lot easier. So what I'm suggesting is that you stick with the so_cred model, because it's easy, but that we fix applications like SSH, which Do The Wrong Thing, and kernel facilities that fall into the same boat. I've already fixed the NFS client so it caches the mount-time credential and uses that to rebind the socket, which differs from the old behavior, where the VOP cred was used to rebind the socket. If you had ipfw uid/gid rules that affected the uid or gid that happened to be on hand, from then until the point when the socket got disconnected, you'd have your NFS mount impacted by the rules. We ran into this with the MAC code: if the NFS mount was over a high integrity interface, and the connection broke (TCP, or whatever), and the first user to read from the filesystem was low integrity, NFS would use the low integrity credential to rebind the socket, and then packets would no longer be allowed out the high integrity interface. So NFS would keel over with EPERM. This also, until recently, caused an mbuf leak because NFS took mbuf delivery failures poorly. :-) I am concerned netsmb might have some of the same issues, and need to look at it, although I haven't yet. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 8 14:21:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 9471537B42C; Fri, 8 Mar 2002 14:21:06 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id g28ML6009917; Fri, 8 Mar 2002 14:21:06 -0800 Date: Fri, 8 Mar 2002 14:21:06 -0800 From: Brooks Davis To: Maxime Henrion Cc: freebsd-net@FreeBSD.ORG Subject: Re: [CFR] Patch for clonable interfaces Message-ID: <20020308142106.A9209@Odin.AC.HMC.Edu> References: <20020306212249.GC2371@nebula.noos.fr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020306212249.GC2371@nebula.noos.fr>; from mux@FreeBSD.ORG on Wed, Mar 06, 2002 at 10:22:49PM +0100 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 --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 06, 2002 at 10:22:49PM +0100, Maxime Henrion wrote: >=20 > Any reviews or comments are appreciated. Ok, I've actually tested it now and it works with all the devices I checked. For the record, I reviewed earlier versions of this patch and I'm happy with it. As far as I'm concerned it can be committed as is. It changes the cloning API again, but does so in a way the brings us back toward NetBSD which is all to the good. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --mP3DRpeJDSE+ciuQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8iTlRXY6L6fI4GtQRAvO8AKDQP42xWQgILC+HlRnu8gnwAX/bTgCgpRgO aNoV2xyr4PQx1PyzuFtInxM= =K7Nx -----END PGP SIGNATURE----- --mP3DRpeJDSE+ciuQ-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 8 15:58:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from gate.soum.co.jp (gate.soum.co.jp [202.221.40.2]) by hub.freebsd.org (Postfix) with ESMTP id 3B92437B422; Fri, 8 Mar 2002 15:58:24 -0800 (PST) Received: from force.soum.co.jp (force.soum.co.jp [IPv6:3ffe:501:80a:1:a00:20ff:fef0:4c9c]) by gate.soum.co.jp (8.12.2/8.11.6) with ESMTP id g28NwMv9000920; Sat, 9 Mar 2002 08:58:22 +0900 (JST) (envelope-from fujita@soum.co.jp) Received: from vanilla.soum.co.jp (vanilla.soum.co.jp [3ffe:501:80a:1:202:b3ff:fe98:8115]) by force.soum.co.jp (8.11.6/3.7W-2001122804) with ESMTP id g28NwMS22459; Sat, 9 Mar 2002 08:58:22 +0900 (JST) Received: from localhost (localhost [::1]) by vanilla.soum.co.jp (Postfix) with ESMTP id 1497D3F58; Sat, 9 Mar 2002 08:58:21 +0900 (JST) Date: Sat, 09 Mar 2002 08:58:20 +0900 (JST) Message-Id: <20020309.085820.102575644.fujita@soum.co.jp> To: freebsd-net@freebsd.org Cc: freebsd-stable@freebsd.org Subject: sendmsg(2) problem ? From: FUJITA Kazutoshi X-PGP-PublicKey: http://www.soum.co.jp/~fujita/fujita-GnuPG-publickey.txt X-PGP-FingerPrint: 9956 2ECE 7E7D B425 EC2D D49E FEBB 3C5F 2C34 1ECA Organization: SOUM Corporation, JAPAN X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 =?iso-2022-jp?B?KBskQjgtTFobKEIp?= 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 there, I CVSuped to 4.5-STABLE(RELENG_4) yesterday, it seems something strange with rtadvd(8). My IPv6 router machine says, Mar 9 08:32:29 gate2 rtadvd[178]: sendmsg on de1: Permission denied What's happening ??? TIA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 8 16:26:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from gate.soum.co.jp (gate.soum.co.jp [202.221.40.2]) by hub.freebsd.org (Postfix) with ESMTP id 81B2437B433; Fri, 8 Mar 2002 16:25:59 -0800 (PST) Received: from force.soum.co.jp (force.soum.co.jp [IPv6:3ffe:501:80a:1:a00:20ff:fef0:4c9c]) by gate.soum.co.jp (8.12.2/8.11.6) with ESMTP id g290Pwv9001358; Sat, 9 Mar 2002 09:25:58 +0900 (JST) (envelope-from fujita@soum.co.jp) Received: from vanilla.soum.co.jp (vanilla.soum.co.jp [3ffe:501:80a:1:202:b3ff:fe98:8115]) by force.soum.co.jp (8.11.6/3.7W-2001122804) with ESMTP id g290PvS26236; Sat, 9 Mar 2002 09:25:57 +0900 (JST) Received: from localhost (localhost [::1]) by vanilla.soum.co.jp (Postfix) with ESMTP id E60913F58; Sat, 9 Mar 2002 09:25:56 +0900 (JST) Date: Sat, 09 Mar 2002 09:25:56 +0900 (JST) Message-Id: <20020309.092556.88477736.fujita@soum.co.jp> To: freebsd-net@FreeBSD.ORG Cc: freebsd-stable@FreeBSD.ORG Subject: Re: sendmsg(2) problem ? From: FUJITA Kazutoshi In-Reply-To: <20020309.085820.102575644.fujita@soum.co.jp> References: <20020309.085820.102575644.fujita@soum.co.jp> X-PGP-PublicKey: http://www.soum.co.jp/~fujita/fujita-GnuPG-publickey.txt X-PGP-FingerPrint: 9956 2ECE 7E7D B425 EC2D D49E FEBB 3C5F 2C34 1ECA Organization: SOUM Corporation, JAPAN X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 =?iso-2022-jp?B?KBskQjgtTFobKEIp?= 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 From: FUJITA Kazutoshi Subject: sendmsg(2) problem ? Date: Sat, 09 Mar 2002 08:58:20 +0900 (JST) Message-ID: <20020309.085820.102575644.fujita@soum.co.jp> > I CVSuped to 4.5-STABLE(RELENG_4) yesterday, > it seems something strange with rtadvd(8). > > My IPv6 router machine says, > > Mar 9 08:32:29 gate2 rtadvd[178]: sendmsg on de1: Permission denied Sorry, I missed 'Mini-HEADS UP: Minor rc.firewall{,6} Change'. I'm using as 'ipv6_firewall_enable="YES"' on the IPv6 router, but I didn't pass icmp6 from local. Thanks for your advice, Brandon. TIA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 9 12: 0:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 9493337B400 for ; Sat, 9 Mar 2002 12:00:20 -0800 (PST) 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 LAA14714; Sat, 9 Mar 2002 11:46:09 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g29JjZP54517; Sat, 9 Mar 2002 11:45:35 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200203091945.g29JjZP54517@arch20m.dellroad.org> Subject: Re: mpd and bpf node In-Reply-To: <20020305134417.51019.qmail@web20102.mail.yahoo.com> "from ome ome at Mar 5, 2002 05:44:17 am" To: ome ome Date: Sat, 9 Mar 2002 11:45:34 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ome ome writes: > What is the aim of the bpf node in MPD ? It's used to implement 'dial-on-demand'. Certain packets should not be counted as 'demand', e.g., NTP packets. So the BPF node is there to filter out non-demand packets. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 9 12: 1: 1 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 3C30737B419 for ; Sat, 9 Mar 2002 12:00:43 -0800 (PST) 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 LAA14729; Sat, 9 Mar 2002 11:54:22 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g29JriG54543; Sat, 9 Mar 2002 11:53:44 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200203091953.g29JriG54543@arch20m.dellroad.org> Subject: Re: MPD Server ? In-Reply-To: <200203071335.g27DZAH6073810@hak.lan.Awfulhak.org> "from Brian Somers at Mar 7, 2002 01:35:10 pm" To: Brian Somers Date: Sat, 9 Mar 2002 11:53:44 -0800 (PST) Cc: Julian Elischer , ome ome , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Brian Somers writes: > > MPD Is a multilink server, yes. > > When a second link is established from a client, it'll invoke a new > mpd instance. Is mpd smart enough to detect this and pass the link > from one invocation to the other ? No, mpd doesn't know how to do anything like that unfortunately.. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 9 13: 0: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 8B18437B400 for ; Sat, 9 Mar 2002 13:00:04 -0800 (PST) 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 MAA15072; Sat, 9 Mar 2002 12:46:43 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g29Kk9A54700; Sat, 9 Mar 2002 12:46:09 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200203092046.g29Kk9A54700@arch20m.dellroad.org> Subject: Re: netgraph for slip or 802.11 In-Reply-To: "from Roop Mukherjee at Mar 6, 2002 06:27:51 pm" To: Roop Mukherjee Date: Sat, 9 Mar 2002 12:46:09 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Roop Mukherjee writes: > But I can't seem to find any call to ether_output() or even packets being > queued at if_snd. How does the ng_ether node actually cause transmission > on the wire? All packets passing through the code in if_ethersubr.c get detoured through ng_ether.c via function pointers which are set when the ng_ether.ko module is loaded. To transmit a packet on the wire, ng_ether.c calls ether_output_frame(). -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message