From owner-freebsd-net Sun May 26 14: 0:18 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 40F0637B401 for ; Sun, 26 May 2002 14:00:14 -0700 (PDT) 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 <20020526210013.XIBG11426.rwcrmhc51.attbi.com@InterJet.elischer.org>; Sun, 26 May 2002 21:00:13 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA03164; Sun, 26 May 2002 13:57:38 -0700 (PDT) Date: Sun, 26 May 2002 13:57:37 -0700 (PDT) From: Julian Elischer To: Rocco Lucia Cc: freebsd-net@freebsd.org Subject: Re: ng_fwdswitch netgraph node 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 Sun, 26 May 2002, Rocco Lucia wrote: > On Fri, May 24, 2002 at 10:31:54AM -0700, Julian Elischer wrote: > > some comments.. > > > > 1/ it may be more useful to not make any distinction between > > 'in' and 'out' hooks but just have connections.. > > The hooks could be given purely arbitrary names > > e.g. "source1" and "suspicious" > > a hook could be configured as being 'read-only' by command > > rather than by special name.. (though special names are > > not a very bad way of doing it.. > > "out-normal" > > and > > "out-dubious" > > > > Ah, sure, that's a good idea, I'm going to rework it to be able > to set node behavior sending it messages... that would consume > some more cycles per packet tho. Thank you for the suggestion :) not neccesarily.. use the per-hook private pointer to point to pre-configured stuff. k > > -- > Rocco Lucia - rlucia@iscanet.com Iscanet Internet Services > http://elisa.utopianet.net/~rlucia System and Network Admin > C6E6 AC9A 1361 FB38 B47A 2792 9FC4 C52F 7A68 4468 > > Free unices for a free world. Support *BSD. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 27 6:55:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.litech.net (mail.litech.net [193.232.65.38]) by hub.freebsd.org (Postfix) with ESMTP id 5D56837B400; Mon, 27 May 2002 06:54:59 -0700 (PDT) Received: from ah.litech.net (ah.litech.net [193.232.65.1]) by mail.litech.net (Postfix) with ESMTP id E71F73FDE; Mon, 27 May 2002 16:54:56 +0300 (EET DST) (envelope-from mike@LITech.lviv.ua) Date: Mon, 27 May 2002 16:54:54 +0300 (EEST) From: Mike Futerko X-X-Sender: To: , Subject: zebra + gif Message-ID: <20020527164944.G3104-100000@ah.litech.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I have the following zebra configuration: --- zebra.conf hostname rt1 password ** ! interface xl0 ! interface xl1 ! interface xl2 ! interface lo0 ! interface gif0 ! interface gif1 ! interface gif2 ! interface gif3 ! interface gif4 ! interface gif5 ! interface gif6 ! interface tun0 ! interface tun1 ! interface tun2 ! line vty ! --- ospfd.conf hostname rt1 password ** ! interface gif1 ip ospf network point-to-point router ospf redistribute kernel redistribute connected redistribute static network 10.1.11.4/32 area 0 ! line vty ! --- ifconfig -a xl0: flags=8843 mtu 1500 inet 10.1.2.1 netmask 0xffffff00 broadcast 10.1.2.255 ether 00:60:08:cf:5c:71 media: Ethernet autoselect (100baseTX ) status: active xl1: flags=8843 mtu 1500 inet xxx.xxx.207.38 netmask 0xffffff80 broadcast xxx.xxx.207.127 ether 00:60:08:14:54:34 media: Ethernet autoselect (10baseT/UTP) status: active xl2: flags=8843 mtu 1500 inet 10.1.10.4 netmask 0xffffff00 broadcast 10.1.10.255 ether 00:60:08:cf:5c:60 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 inet 10.0.2.251 netmask 0xffffff00 inet xxx.xxx.207.169 netmask 0xffffffff inet xxx.xxx.207.170 netmask 0xffffffff inet xxx.xxx.207.171 netmask 0xffffffff gif0: flags=8051 mtu 1280 tunnel inet xxx.xxx.207.38 --> xxx.xxx.253.56 inet 10.1.2.1 --> 10.1.1.1 netmask 0xffffffff gif1: flags=8051 mtu 1280 tunnel inet xxx.xxx.207.170 --> xxx.xxx.16.50 inet 10.1.10.4 --> 10.1.11.4 netmask 0xffffffff gif2: flags=8051 mtu 1280 tunnel inet xxx.xxx.207.170 --> xxx.xxx.213.244 inet 10.1.10.4 --> 10.1.12.4 netmask 0xffffffff gif3: flags=8051 mtu 1280 tunnel inet xxx.xxx.207.170 --> xxx.xxx.134.177 inet 10.1.10.4 --> 10.7.1.4 netmask 0xffffffff gif4: flags=8051 mtu 1280 tunnel inet xxx.xxx.207.170 --> xxx.xxx.206.226 inet 10.1.10.4 --> 10.3.1.4 netmask 0xffffffff gif5: flags=8051 mtu 1280 tunnel inet xxx.xxx.207.170 --> xxx.xxx.88.244 inet 10.1.10.4 --> 10.4.6.4 netmask 0xffffffff gif6: flags=8051 mtu 1280 tunnel inet xxx.xxx.207.170 --> xxx.xxx.193.171 inet 10.1.10.4 --> 10.2.10.4 netmask 0xffffffff tun0: flags=8051 mtu 1500 inet 10.0.2.251 --> 10.0.1.251 netmask 0xffffffff Opened by PID 66 tun1: flags=8010 mtu 1500 tun2: flags=8010 mtu 1500 ---- uname -rs FreeBSD 4.5-STABLE, dated by Fri Mar 8 2002 But the same behavior observed on other FreeBSD systems including FreeBSD 4.5-RELEASE-p2 After running zebra: telnet localhost ospfd rt1> en rt1# show ip ospf interface gif1 is up, line protocol is up Internet Address 10.1.10.4/32, Area 0.0.0.0 Router ID 10.1.10.4, Network Type POINTOPOINT, Cost: 10 Transmit Delay is 1 sec, State Point-To-Point, Priority 1 No designated router on this network No backup designated router on this network Timer intarvals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:00 Neighbor Count is 0, Adjacent neighbor count is 0 xl0 is up, line protocol is up OSPF not enabled on this interface xl1 is up, line protocol is up OSPF not enabled on this interface xl2 is up, line protocol is up OSPF not enabled on this interface lo0 is up, line protocol is up OSPF not enabled on this interface gif0 is up, line protocol is up OSPF not enabled on this interface gif2 is up, line protocol is up OSPF not enabled on this interface gif3 is up, line protocol is up OSPF not enabled on this interface gif4 is up, line protocol is up OSPF not enabled on this interface gif5 is up, line protocol is up OSPF not enabled on this interface gif6 is up, line protocol is up OSPF not enabled on this interface tun0 is up, line protocol is up OSPF not enabled on this interface tun1 is down, line protocol is down OSPF not enabled on this interface tun2 is down, line protocol is down OSPF not enabled on this interface That's fine, OSPF is enabled only on gif1 interface as required. But hello packets sends not via gif1, as ospfd diagnostics show: rt1# ter mon rt1# debug ospf packet hello 2002/04/21 17:20:33 OSPF: Hello sent to [224.0.0.5] via [gif1:10.1.10.4]. 2002/04/21 17:20:44 OSPF: Hello sent to [224.0.0.5] via [gif1:10.1.10.4]. 2002/04/21 17:20:54 OSPF: Hello sent to [224.0.0.5] via [gif1:10.1.10.4]. .... "tcpdunp -npigif1 proto 89" shows nothing. I have added rule into firewall to see OSPF packets: router# ipfw add 10 allow log 89 from any to any router# tail -f /var/log/security Apr 21 17:20:34 relay /kernel: ipfw: 10 Accept P:89 10.1.10.4 224.0.0.5 out via gif6 Apr 21 17:20:44 relay /kernel: ipfw: 10 Accept P:89 10.1.10.4 224.0.0.5 out via gif6 Apr 21 17:20:54 relay /kernel: ipfw: 10 Accept P:89 10.1.10.4 224.0.0.5 out via gif6 .... Why zebra sends hello-packets via gif6? Concerning to the ospfd diagnostics (show ip ospf interface) OSPF is enabled only on gif1 interface, and (debug ospf packet hello) show that zebra sends hello-packets via gif1 (OSPF: Hello sent to [224.0.0.5] via [gif1:10.1.10.4].) Is it zebra or FreeBSD specific bug? Or maybe my misconfiguration? When I stop zebra, delete gif6 interface and start zebra again, OSPF packets start appears on gif5 interface, and so on... I could provide more useful information, if required. What is wrong with my zebra configuration? Thanks in advance for any help... Regards, Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 27 9:18:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (oe33.pav1.hotmail.com [64.4.30.90]) by hub.freebsd.org (Postfix) with ESMTP id 59B8837B414 for ; Mon, 27 May 2002 09:18:30 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 27 May 2002 09:18:30 -0700 X-Originating-IP: [207.112.2.1] From: "jack xiao" To: Subject: problem on kernel ppp Date: Mon, 27 May 2002 12:15:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 27 May 2002 16:18:30.0192 (UTC) FILETIME=[23B45B00:01C2059A] Sender: owner-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 using kenerl ppp(pppd) on our DSL server (FBSD 4.2) to accept clients requests. In most of cases, it works fine. Sometimes, especially when clients disconnect and connect frequently in a short time, problems came up. After the tunnel is up, server and the client can't ping each other. On the server side, the ppp interface is up and the routing table is right. One the other side, the client gets the IP assigned by the server, and aslo gets a ppp tunnel. It seems nothing wrong. If I reboot the server box, when the client connects again, it works fine again. So I am afraid the assigned IP or something else "held" by the server in that moment. But how can I release these things when this happens, rebooting the server is not a good idea at all. Any help or hint will be appreciated. Thanks. Jack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 27 18:48:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from inter-svr1.archtek.com.tw (inter-svr1.archtek.com.tw [61.222.209.100]) by hub.freebsd.org (Postfix) with ESMTP id 637E237B400 for ; Mon, 27 May 2002 18:47:56 -0700 (PDT) Received: from nb (users.archtek.com.tw [61.222.209.98]) by inter-svr1.archtek.com.tw (8.11.5/8.11.5) with SMTP id g4S1f9g81893 for ; Tue, 28 May 2002 09:41:09 +0800 (CST) (envelope-from yuting_lin@kimo.com.tw) Message-ID: <001c01c205e9$c7824f40$be3b43cb@archtek.com.tw> From: "Yuting Lin" To: Subject: multipath on FreeBSD 4.5 Date: Tue, 28 May 2002 09:48:32 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C2062C.D3E43030" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C2062C.D3E43030 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hi, I would like to use multipath(networking) on FreeBSD 4.5, How = should I do it? did FreeBSD support multipath on networking? Thanks, Yu Ting ------=_NextPart_000_0019_01C2062C.D3E43030 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Hi,
 
        I would=20 like to use multipath(networking) on FreeBSD 4.5, How = should I do=20 it? did FreeBSD support multipath on networking?
 
Thanks,
 
Yu Ting
 
------=_NextPart_000_0019_01C2062C.D3E43030-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue May 28 3:39:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from vbook.express.ru (asplinux.ru [195.133.213.194]) by hub.freebsd.org (Postfix) with ESMTP id 0931537B406 for ; Tue, 28 May 2002 03:39:37 -0700 (PDT) Received: from vova by vbook.express.ru with local (Exim 3.36 #1) id 17CeNn-0000BC-00; Tue, 28 May 2002 14:39:15 +0400 Subject: Re: multipath on FreeBSD 4.5 From: "Vladimir B. " Grebenschikov To: Yuting Lin Cc: freebsd-net@FreeBSD.ORG In-Reply-To: <001c01c205e9$c7824f40$be3b43cb@archtek.com.tw> References: <001c01c205e9$c7824f40$be3b43cb@archtek.com.tw> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Mailer: Ximian Evolution 1.0.5 Date: 28 May 2002 14:39:14 +0400 Message-Id: <1022582354.455.13.camel@vbook.express.ru> Mime-Version: 1.0 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org =F7 Tue, 28.05.2002, =D7 05:48, Yuting Lin =CE=C1=D0=C9=D3=C1=CC: > Hi, >=20 > I would like to use multipath(networking) on FreeBSD 4.5, How sho= uld I do it? did FreeBSD support multipath on networking? At current stage no, there are some patches for it against 4.3-RELEASE. You can find descussion about this in recent current maillist. (Subject: multi default routes in freebsd !?) > Thanks, >=20 > Yu Ting >=20 --=20 Vladimir B. Grebenschikov vova@sw.ru, SWsoft, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue May 28 20: 4:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from gate21.fw.porsche.de (gate23.fw.porsche.de [193.174.9.99]) by hub.freebsd.org (Postfix) with SMTP id 0A1AA37B409 for ; Tue, 28 May 2002 20:04:41 -0700 (PDT) Received: (qmail 25454 invoked from network); 29 May 2002 03:08:03 -0000 Received: from unknown (HELO wuxin011.ibd.porsche.de) (141.36.65.1) by 193.197.149.150 with SMTP; 29 May 2002 03:08:03 -0000 Received: (qmail 14473 invoked from network); 29 May 2002 03:04:27 -0000 Received: from wuxws007.ibd.porsche.de (HELO porsche.de) (141.36.2.178) by smtp4cli.ibd.porsche.de with SMTP; 29 May 2002 03:04:27 -0000 Message-ID: <3CF445BC.2090603@porsche.de> Date: Wed, 29 May 2002 05:06:36 +0200 From: Marc Perisa User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en, de-de, es-es MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: sendto() in jail environment 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, the PR kern/26506 seems to patch sys/netinet/in_pcb.c to work correct in jail environments. Can some please take a look this PR? Thanks Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue May 28 22:15: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from atropos.snu.ac.kr (atropos.snu.ac.kr [147.46.106.37]) by hub.freebsd.org (Postfix) with ESMTP id F164F37B401 for ; Tue, 28 May 2002 22:14:58 -0700 (PDT) Received: (from redjade@localhost) by atropos.snu.ac.kr (8.11.6/8.11.6) id g4T5EpO19405; Wed, 29 May 2002 14:14:52 +0900 (KST) Date: Wed, 29 May 2002 14:14:51 +0900 From: Kyunghwan Kim To: freebsd-net@freebsd.org Subject: Device polling support for em and ti Message-ID: <20020529141451.A18124@atropos.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org These are patches that enable device polling for em and ti drivers. Patches are against RELENG_4 branch, if_em.c 1.2.2.4, if_em.h 1.1.2.4, if_ti.c 1.25.2.14, if_tireg.h 1.13.2.4 . Would someone review or test these? I don't have enough testing environment. http://atropos.snu.ac.kr/~redjade/patches/em_diff http://atropos.snu.ac.kr/~redjade/patches/ti_diff Thanks. -- Kyunghwan Kim redjade@atropos.snu.ac.kr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 29 0:18:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from isis.lip6.fr (isis.lip6.fr [132.227.60.2]) by hub.freebsd.org (Postfix) with ESMTP id ACF8737B400 for ; Wed, 29 May 2002 00:18:10 -0700 (PDT) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.2/jtpda-5.4+victor) with ESMTP id g4T7I96R007890 for ; Wed, 29 May 2002 09:18:09 +0200 X-pt: isis.lip6.fr Received: from localhost (localhost [[UNIX: localhost]]) by tibre.lip6.fr (8.11.3nb1/8.11.3) with ESMTP id g4T7I8Y28598 for ; Wed, 29 May 2002 09:18:08 +0200 (MEST) Date: Wed, 29 May 2002 09:18:07 +0200 (MEST) From: Luigi Iannone To: freebsd-net@FreeBSD.org Subject: MPLS 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 Hi! I developped a basic implementation of MPLS over Ethernet in the FreeBSD Environment! If someone is interested in my code just e.mail me! Bye Luigi Iannone ----------------------------------------------------------------> Luigi Iannone LIP 6 : Laboratoire d'Informatique de Paris VI 8, Rue du Capitaine Scott 75015 Paris France E-mail: Luigi.Iannone@lip6.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 29 2:12:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95]) by hub.freebsd.org (Postfix) with SMTP id EDFE137B401 for ; Wed, 29 May 2002 02:12:30 -0700 (PDT) Received: (qmail 15025 invoked by uid 1000); 29 May 2002 09:12:42 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 29 May 2002 09:12:42 -0000 Date: Wed, 29 May 2002 11:12:42 +0200 (CEST) From: Attila Nagy To: Luigi Iannone Cc: freebsd-net@FreeBSD.org Subject: Re: MPLS In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, > I developped a basic implementation of MPLS over Ethernet in the FreeBSD > Environment! If someone is interested in my code just e.mail me! Great! Although I do not have the devices to test this, it is very nice to hear that. I think the patches should go to hackers@freebsd.org, to give them a chance to get them into the base. Yesterday I was at Ericsson on a Juniper demo (http://www.juniper.net/). JUNOS is based on FreeBSD and knows everything, which has to be known by a core router (for example MPLS). It would be very nice to see the same functionality on a simple PC :) --------[ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]------- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 29 2:55:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 915D337B401 for ; Wed, 29 May 2002 02:55:38 -0700 (PDT) Received: (qmail 4326 invoked from network); 29 May 2002 09:55:19 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 29 May 2002 09:55:19 -0000 Message-ID: <3CF4A555.41CA27E4@pipeline.ch> Date: Wed, 29 May 2002 11:54:29 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Iannone Cc: freebsd-net@FreeBSD.org Subject: Re: MPLS 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 Luigi Iannone wrote: > > Hi! > I developped a basic implementation of MPLS over Ethernet in the FreeBSD > Environment! If someone is interested in my code just e.mail me! I'm interested in it. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 29 2:59:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 7E2C737B401 for ; Wed, 29 May 2002 02:59:42 -0700 (PDT) Received: (qmail 4931 invoked from network); 29 May 2002 09:59:24 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 29 May 2002 09:59:24 -0000 Message-ID: <3CF4A64A.EE220611@pipeline.ch> Date: Wed, 29 May 2002 11:58:34 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Attila Nagy Cc: Luigi Iannone , freebsd-net@FreeBSD.org Subject: Re: MPLS 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 Attila Nagy wrote: > > Hello, > > > I developped a basic implementation of MPLS over Ethernet in the FreeBSD > > Environment! If someone is interested in my code just e.mail me! > Great! Although I do not have the devices to test this, it is very > nice to hear that. I think the patches should go to hackers@freebsd.org, > to give them a chance to get them into the base. > > Yesterday I was at Ericsson on a Juniper demo (http://www.juniper.net/). > JUNOS is based on FreeBSD and knows everything, which has to be known by a > core router (for example MPLS). It would be very nice to see the same > functionality on a simple PC :) It is true that JUNOS is more or less FreeBSD. But it's only the control plane. All the switching and stack processing happens on the line cards which have their own CPUs and OS. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 29 7:13:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 6B09937B400 for ; Wed, 29 May 2002 07:13:23 -0700 (PDT) Received: from whizzo.transsys.com (#6@localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.12.3/8.12.3) with ESMTP id g4TEDLRG075458; Wed, 29 May 2002 10:13:22 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200205291413.g4TEDLRG075458@whizzo.transsys.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Andre Oppermann Cc: Attila Nagy , Luigi Iannone , freebsd-net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: MPLS References: <3CF4A64A.EE220611@pipeline.ch> In-reply-to: Your message of "Wed, 29 May 2002 11:58:34 +0200." <3CF4A64A.EE220611@pipeline.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 May 2002 10:13:21 -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Attila Nagy wrote: > > > > Hello, > > > > > I developped a basic implementation of MPLS over Ethernet in the FreeBSD > > > Environment! If someone is interested in my code just e.mail me! > > Great! Although I do not have the devices to test this, it is very > > nice to hear that. I think the patches should go to hackers@freebsd.org, > > to give them a chance to get them into the base. > > > > Yesterday I was at Ericsson on a Juniper demo (http://www.juniper.net/). > > JUNOS is based on FreeBSD and knows everything, which has to be known by a > > core router (for example MPLS). It would be very nice to see the same > > functionality on a simple PC :) > > It is true that JUNOS is more or less FreeBSD. But it's only the > control plane. All the switching and stack processing happens on > the line cards which have their own CPUs and OS. There is no software involved in the forwarding plane, including the line cards, in the Juniper routers. There is another CPU in the box running an embedded system kernel, which does supervisory things, but that's also not involved in the forwarding operation. The forwarding is done in Juniper's custom designed ASIC hardware, and is the other significantly valuable intellectual property they have along with the routing protocol implementation (e.g., BGP, IS-IS, etc.) louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 29 7:25:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id E1D2E37B403 for ; Wed, 29 May 2002 07:25:12 -0700 (PDT) Received: (qmail 43306 invoked from network); 29 May 2002 14:24:53 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 29 May 2002 14:24:53 -0000 Message-ID: <3CF4E483.2510639@pipeline.ch> Date: Wed, 29 May 2002 16:24:03 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Louis A. Mamakos" Cc: Attila Nagy , Luigi Iannone , freebsd-net@FreeBSD.ORG Subject: Re: MPLS References: <3CF4A64A.EE220611@pipeline.ch> <200205291413.g4TEDLRG075458@whizzo.transsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org "Louis A. Mamakos" wrote: > > > Attila Nagy wrote: > > > > > > Hello, > > > > > > > I developped a basic implementation of MPLS over Ethernet in the FreeBSD > > > > Environment! If someone is interested in my code just e.mail me! > > > Great! Although I do not have the devices to test this, it is very > > > nice to hear that. I think the patches should go to hackers@freebsd.org, > > > to give them a chance to get them into the base. > > > > > > Yesterday I was at Ericsson on a Juniper demo (http://www.juniper.net/). > > > JUNOS is based on FreeBSD and knows everything, which has to be known by a > > > core router (for example MPLS). It would be very nice to see the same > > > functionality on a simple PC :) > > > > It is true that JUNOS is more or less FreeBSD. But it's only the > > control plane. All the switching and stack processing happens on > > the line cards which have their own CPUs and OS. > > There is no software involved in the forwarding plane, including > the line cards, in the Juniper routers. There is another CPU in > the box running an embedded system kernel, which does supervisory > things, but that's also not involved in the forwarding operation. If there is no kind of software involved on the forwarding plane then I don't know how the control plane can communicate via ethernet with the line cards... The internal communication in the router is via ethernet. > The forwarding is done in Juniper's custom designed ASIC hardware, > and is the other significantly valuable intellectual property > they have along with the routing protocol implementation (e.g., > BGP, IS-IS, etc.) I agree with the ASIC hardware. But the BGP implementation smells awfully like gated (Nexthop). Anyway, a BGP deamon isn't that hard to write. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 29 8: 2:50 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 357A537B408; Wed, 29 May 2002 08:01:29 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id BAF4BAE160; Wed, 29 May 2002 08:01:29 -0700 (PDT) Date: Wed, 29 May 2002 08:01:29 -0700 From: Alfred Perlstein To: net@freebsd.org Cc: julian@freebsd.org Subject: netgraph warnings Message-ID: <20020529150129.GQ17045@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Something bizzaro with the 'struct ng_parse_struct_info' declarations, please suggest or make a fix: cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding -Werror ../../../dev/usb/udbp.c cc1: warnings being treated as errors ../../../dev/usb/udbp.c:165: warning: excess elements in array initializer ../../../dev/usb/udbp.c:165: warning: (near initialization for `ng_udbp_stat_type_info.fields') ../../../dev/usb/udbp.c:165: warning: excess elements in array initializer ../../../dev/usb/udbp.c:165: warning: (near initialization for `ng_udbp_stat_type_info.fields') ../../../dev/usb/udbp.c:165: warning: excess elements in array initializer ../../../dev/usb/udbp.c:165: warning: (near initialization for `ng_udbp_stat_type_info.fields') *** Error code 1 (continuing) cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding -Werror ../../../netgraph/ng_base.c cc1: warnings being treated as errors ../../../netgraph/ng_base.c:365: warning: excess elements in array initializer ../../../netgraph/ng_base.c:365: warning: (near initialization for `ng_mkpeer_type_info.fields') ../../../netgraph/ng_base.c:365: warning: excess elements in array initializer ../../../netgraph/ng_base.c:365: warning: (near initialization for `ng_mkpeer_type_info.fields') ../../../netgraph/ng_base.c:365: warning: excess elements in array initializer ../../../netgraph/ng_base.c:365: warning: (near initialization for `ng_mkpeer_type_info.fields') ../../../netgraph/ng_base.c:365: warning: excess elements in array initializer ../../../netgraph/ng_base.c:365: warning: (near initialization for `ng_mkpeer_type_info.fields') ../../../netgraph/ng_base.c:366: warning: excess elements in array initializer ../../../netgraph/ng_base.c:366: warning: (near initialization for `ng_connect_type_info.fields') ../../../netgraph/ng_base.c:366: warning: excess elements in array initializer ../../../netgraph/ng_base.c:366: warning: (near initialization for `ng_connect_type_info.fields') ../../../netgraph/ng_base.c:366: warning: excess elements in array initializer ../../../netgraph/ng_base.c:366: warning: (near initialization for `ng_connect_type_info.fields') ../../../netgraph/ng_base.c:366: warning: excess elements in array initializer ../../../netgraph/ng_base.c:366: warning: (near initialization for `ng_connect_type_info.fields') ../../../netgraph/ng_base.c:367: warning: excess elements in array initializer ../../../netgraph/ng_base.c:367: warning: (near initialization for `ng_name_type_info.fields') ../../../netgraph/ng_base.c:367: warning: excess elements in array initializer ../../../netgraph/ng_base.c:367: warning: (near initialization for `ng_name_type_info.fields') ../../../netgraph/ng_base.c:368: warning: excess elements in array initializer ../../../netgraph/ng_base.c:368: warning: (near initialization for `ng_rmhook_type_info.fields') ../../../netgraph/ng_base.c:368: warning: excess elements in array initializer ../../../netgraph/ng_base.c:368: warning: (near initialization for `ng_rmhook_type_info.fields') ../../../netgraph/ng_base.c:369: warning: excess elements in array initializer ../../../netgraph/ng_base.c:369: warning: (near initialization for `ng_nodeinfo_type_info.fields') ../../../netgraph/ng_base.c:369: warning: excess elements in array initializer ../../../netgraph/ng_base.c:369: warning: (near initialization for `ng_nodeinfo_type_info.fields') ../../../netgraph/ng_base.c:369: warning: excess elements in array initializer ../../../netgraph/ng_base.c:369: warning: (near initialization for `ng_nodeinfo_type_info.fields') ../../../netgraph/ng_base.c:369: warning: excess elements in array initializer ../../../netgraph/ng_base.c:369: warning: (near initialization for `ng_nodeinfo_type_info.fields') ../../../netgraph/ng_base.c:369: warning: excess elements in array initializer ../../../netgraph/ng_base.c:369: warning: (near initialization for `ng_nodeinfo_type_info.fields') ../../../netgraph/ng_base.c:370: warning: excess elements in array initializer ../../../netgraph/ng_base.c:370: warning: (near initialization for `ng_typeinfo_type_info.fields') ../../../netgraph/ng_base.c:370: warning: excess elements in array initializer ../../../netgraph/ng_base.c:370: warning: (near initialization for `ng_typeinfo_type_info.fields') ../../../netgraph/ng_base.c:370: warning: excess elements in array initializer ../../../netgraph/ng_base.c:370: warning: (near initialization for `ng_typeinfo_type_info.fields') ../../../netgraph/ng_base.c:371: warning: excess elements in array initializer ../../../netgraph/ng_base.c:371: warning: (near initialization for `ng_linkinfo_type_info.fields') ../../../netgraph/ng_base.c:371: warning: excess elements in array initializer ../../../netgraph/ng_base.c:371: warning: (near initialization for `ng_linkinfo_type_info.fields') ../../../netgraph/ng_base.c:371: warning: excess elements in array initializer ../../../netgraph/ng_base.c:371: warning: (near initialization for `ng_linkinfo_type_info.fields') ../../../netgraph/ng_base.c:371: warning: excess elements in array initializer ../../../netgraph/ng_base.c:371: warning: (near initialization for `ng_linkinfo_type_info.fields') ../../../netgraph/ng_base.c:423: warning: excess elements in array initializer ../../../netgraph/ng_base.c:423: warning: (near initialization for `ng_typelist_type_info.fields') ../../../netgraph/ng_base.c:423: warning: excess elements in array initializer ../../../netgraph/ng_base.c:423: warning: (near initialization for `ng_typelist_type_info.fields') ../../../netgraph/ng_base.c:423: warning: excess elements in array initializer ../../../netgraph/ng_base.c:423: warning: (near initialization for `ng_typelist_type_info.fields') ../../../netgraph/ng_base.c:425: warning: excess elements in array initializer ../../../netgraph/ng_base.c:425: warning: (near initialization for `ng_hooklist_type_info.fields') ../../../netgraph/ng_base.c:425: warning: excess elements in array initializer ../../../netgraph/ng_base.c:425: warning: (near initialization for `ng_hooklist_type_info.fields') ../../../netgraph/ng_base.c:425: warning: excess elements in array initializer ../../../netgraph/ng_base.c:425: warning: (near initialization for `ng_hooklist_type_info.fields') ../../../netgraph/ng_base.c:427: warning: excess elements in array initializer ../../../netgraph/ng_base.c:427: warning: (near initialization for `ng_listnodes_type_info.fields') ../../../netgraph/ng_base.c:427: warning: excess elements in array initializer ../../../netgraph/ng_base.c:427: warning: (near initialization for `ng_listnodes_type_info.fields') ../../../netgraph/ng_base.c:427: warning: excess elements in array initializer ../../../netgraph/ng_base.c:427: warning: (near initialization for `ng_listnodes_type_info.fields') *** Error code 1 (continuing) cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding -Werror ../../../netgraph/ng_parse.c cc1: warnings being treated as errors ../../../netgraph/ng_parse.c:1120: warning: excess elements in array initializer ../../../netgraph/ng_parse.c:1120: warning: (near initialization for `ng_parse_ng_mesg_type_info.fields') ../../../netgraph/ng_parse.c:1120: warning: excess elements in array initializer ../../../netgraph/ng_parse.c:1120: warning: (near initialization for `ng_parse_ng_mesg_type_info.fields') ../../../netgraph/ng_parse.c:1120: warning: excess elements in array initializer ../../../netgraph/ng_parse.c:1120: warning: (near initialization for `ng_parse_ng_mesg_type_info.fields') ../../../netgraph/ng_parse.c:1120: warning: excess elements in array initializer ../../../netgraph/ng_parse.c:1120: warning: (near initialization for `ng_parse_ng_mesg_type_info.fields') ../../../netgraph/ng_parse.c:1120: warning: excess elements in array initializer ../../../netgraph/ng_parse.c:1120: warning: (near initialization for `ng_parse_ng_mesg_type_info.fields') ../../../netgraph/ng_parse.c:1120: warning: excess elements in array initializer ../../../netgraph/ng_parse.c:1120: warning: (near initialization for `ng_parse_ng_mesg_type_info.fields') ../../../netgraph/ng_parse.c:1120: warning: excess elements in array initializer ../../../netgraph/ng_parse.c:1120: warning: (near initialization for `ng_parse_ng_mesg_type_info.fields') ../../../netgraph/ng_parse.c:1120: warning: excess elements in array initializer ../../../netgraph/ng_parse.c:1120: warning: (near initialization for `ng_parse_ng_mesg_type_info.fields') ../../../netgraph/ng_parse.c:1120: warning: excess elements in array initializer ../../../netgraph/ng_parse.c:1120: warning: (near initialization for `ng_parse_ng_mesg_type_info.fields') ../../../netgraph/ng_parse.c:1120: warning: excess elements in array initializer ../../../netgraph/ng_parse.c:1120: warning: (near initialization for `ng_parse_ng_mesg_type_info.fields') *** Error code 1 (continuing) cd ../../../modules ; MAKEOBJDIRPREFIX=/vol/share/src/sys/i386/compile/smpng/modules KMODDIR=/boot/kernel DEBUG="-g" DEBUG_FLAGS="-g" MACHINE=i386 make obj ; MAKEOBJDIRPREFIX=/vol/share/src/sys/i386/compile/smpng/modules KMODDIR=/boot/kernel DEBUG="-g" DEBUG_FLAGS="-g" MACHINE=i386 make all ... ===> txp ===> ucom ===> udbp cc -O -pipe -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -c /vol/share/src/sys/dev/usb/udbp.c /vol/share/src/sys/dev/usb/udbp.c:165: warning: excess elements in array initializer /vol/share/src/sys/dev/usb/udbp.c:165: warning: (near initialization for `ng_udbp_stat_type_info.fields') /vol/share/src/sys/dev/usb/udbp.c:165: warning: excess elements in array initializer /vol/share/src/sys/dev/usb/udbp.c:165: warning: (near initialization for `ng_udbp_stat_type_info.fields') /vol/share/src/sys/dev/usb/udbp.c:165: warning: excess elements in array initializer /vol/share/src/sys/dev/usb/udbp.c:165: warning: (near initialization for `ng_udbp_stat_type_info.fields') ld -d -warn-common -r -d -o udbp.kld udbp.o touch /vol/share/src/sys/i386/compile/smpng/modules/vol/share/src/sys/modules/udbp/export_syms awk -f /vol/share/src/sys/modules/udbp/../../conf/kmod_syms.awk udbp.kld /vol/share/src/sys/i386/compile/smpng/modules/vol/share/src/sys/modules/udbp/export_syms | xargs -J% objcopy % udbp.kld ld -Bshareable -d -warn-common -o udbp.ko.debug udbp.kld objcopy --strip-debug udbp.ko.debug udbp.ko ... ===> netgraph/async cc -O -pipe -Wall -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -c /vol/share/src/sys/netgraph/ng_async.c /vol/share/src/sys/netgraph/ng_async.c:109: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_async.c:109: warning: (near initialization for `nga_config_type_info.fields') /vol/share/src/sys/netgraph/ng_async.c:109: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_async.c:109: warning: (near initialization for `nga_config_type_info.fields') /vol/share/src/sys/netgraph/ng_async.c:109: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_async.c:109: warning: (near initialization for `nga_config_type_info.fields') /vol/share/src/sys/netgraph/ng_async.c:109: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_async.c:109: warning: (near initialization for `nga_config_type_info.fields') /vol/share/src/sys/netgraph/ng_async.c:109: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_async.c:109: warning: (near initialization for `nga_config_type_info.fields') /vol/share/src/sys/netgraph/ng_async.c:117: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_async.c:117: warning: (near initialization for `nga_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_async.c:117: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_async.c:117: warning: (near initialization for `nga_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_async.c:117: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_async.c:117: warning: (near initialization for `nga_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_async.c:117: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_async.c:117: warning: (near initialization for `nga_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_async.c:117: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_async.c:117: warning: (near initialization for `nga_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_async.c:117: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_async.c:117: warning: (near initialization for `nga_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_async.c:117: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_async.c:117: warning: (near initialization for `nga_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_async.c:117: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_async.c:117: warning: (near initialization for `nga_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_async.c:117: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_async.c:117: warning: (near initialization for `nga_stats_type_info.fields') ld -d -warn-common -r -d -o ng_async.kld ng_async.o ld -Bshareable -d -warn-common -o ng_async.ko.debug ng_async.kld objcopy --strip-debug ng_async.ko.debug ng_async.ko ===> netgraph/bpf cc -O -pipe -Wall -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -c /vol/share/src/sys/netgraph/ng_bpf.c /vol/share/src/sys/netgraph/ng_bpf.c:103: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bpf.c:103: warning: (near initialization for `ng_bpf_insn_type_info.fields') /vol/share/src/sys/netgraph/ng_bpf.c:104: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bpf.c:104: warning: (near initialization for `ng_bpf_insn_type_info.fields') /vol/share/src/sys/netgraph/ng_bpf.c:105: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bpf.c:105: warning: (near initialization for `ng_bpf_insn_type_info.fields') /vol/share/src/sys/netgraph/ng_bpf.c:106: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bpf.c:106: warning: (near initialization for `ng_bpf_insn_type_info.fields') /vol/share/src/sys/netgraph/ng_bpf.c:107: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bpf.c:107: warning: (near initialization for `ng_bpf_insn_type_info.fields') /vol/share/src/sys/netgraph/ng_bpf.c:139: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bpf.c:139: warning: (near initialization for `ng_bpf_hookprog_type_info.fields') /vol/share/src/sys/netgraph/ng_bpf.c:139: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bpf.c:139: warning: (near initialization for `ng_bpf_hookprog_type_info.fields') /vol/share/src/sys/netgraph/ng_bpf.c:139: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bpf.c:139: warning: (near initialization for `ng_bpf_hookprog_type_info.fields') /vol/share/src/sys/netgraph/ng_bpf.c:139: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bpf.c:139: warning: (near initialization for `ng_bpf_hookprog_type_info.fields') /vol/share/src/sys/netgraph/ng_bpf.c:139: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bpf.c:139: warning: (near initialization for `ng_bpf_hookprog_type_info.fields') /vol/share/src/sys/netgraph/ng_bpf.c:139: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bpf.c:139: warning: (near initialization for `ng_bpf_hookprog_type_info.fields') /vol/share/src/sys/netgraph/ng_bpf.c:147: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bpf.c:147: warning: (near initialization for `ng_bpf_hookstat_type_info.fields') /vol/share/src/sys/netgraph/ng_bpf.c:147: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bpf.c:147: warning: (near initialization for `ng_bpf_hookstat_type_info.fields') /vol/share/src/sys/netgraph/ng_bpf.c:147: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bpf.c:147: warning: (near initialization for `ng_bpf_hookstat_type_info.fields') /vol/share/src/sys/netgraph/ng_bpf.c:147: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bpf.c:147: warning: (near initialization for `ng_bpf_hookstat_type_info.fields') /vol/share/src/sys/netgraph/ng_bpf.c:147: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bpf.c:147: warning: (near initialization for `ng_bpf_hookstat_type_info.fields') /vol/share/src/sys/netgraph/ng_bpf.c:147: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bpf.c:147: warning: (near initialization for `ng_bpf_hookstat_type_info.fields') /vol/share/src/sys/netgraph/ng_bpf.c:147: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bpf.c:147: warning: (near initialization for `ng_bpf_hookstat_type_info.fields') /vol/share/src/sys/netgraph/ng_bpf.c:216: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bpf.c:216: warning: (near initialization for `ng_bpf_default_prog.bpf_prog') ld -d -warn-common -r -d -o ng_bpf.kld ng_bpf.o bpf_filter.o ld -Bshareable -d -warn-common -o ng_bpf.ko.debug ng_bpf.kld objcopy --strip-debug ng_bpf.ko.debug ng_bpf.ko ===> netgraph/bridge cc -O -pipe -Wall -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -c /vol/share/src/sys/netgraph/ng_bridge.c /vol/share/src/sys/netgraph/ng_bridge.c:175: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:175: warning: (near initialization for `ng_bridge_host_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:175: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:175: warning: (near initialization for `ng_bridge_host_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:175: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:175: warning: (near initialization for `ng_bridge_host_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:175: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:175: warning: (near initialization for `ng_bridge_host_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:175: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:175: warning: (near initialization for `ng_bridge_host_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:189: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:189: warning: (near initialization for `ng_bridge_host_ary_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:189: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:189: warning: (near initialization for `ng_bridge_host_ary_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:189: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:189: warning: (near initialization for `ng_bridge_host_ary_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:205: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:205: warning: (near initialization for `ng_bridge_config_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:205: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:205: warning: (near initialization for `ng_bridge_config_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:205: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:205: warning: (near initialization for `ng_bridge_config_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:205: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:205: warning: (near initialization for `ng_bridge_config_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:205: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:205: warning: (near initialization for `ng_bridge_config_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:205: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:205: warning: (near initialization for `ng_bridge_config_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: (near initialization for `ng_bridge_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: (near initialization for `ng_bridge_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: (near initialization for `ng_bridge_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: (near initialization for `ng_bridge_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: (near initialization for `ng_bridge_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: (near initialization for `ng_bridge_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: (near initialization for `ng_bridge_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: (near initialization for `ng_bridge_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: (near initialization for `ng_bridge_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: (near initialization for `ng_bridge_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: (near initialization for `ng_bridge_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: (near initialization for `ng_bridge_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: (near initialization for `ng_bridge_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: (near initialization for `ng_bridge_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_bridge.c:213: warning: (near initialization for `ng_bridge_stats_type_info.fields') ld -d -warn-common -r -d -o ng_bridge.kld ng_bridge.o ld -Bshareable -d -warn-common -o ng_bridge.ko.debug ng_bridge.kld objcopy --strip-debug ng_bridge.ko.debug ng_bridge.ko ===> netgraph/cisco cc -O -pipe -Wall -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -c /vol/share/src/sys/netgraph/ng_cisco.c /vol/share/src/sys/netgraph/ng_cisco.c:132: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_cisco.c:132: warning: (near initialization for `ng_cisco_ipaddr_type_info.fields') /vol/share/src/sys/netgraph/ng_cisco.c:132: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_cisco.c:132: warning: (near initialization for `ng_cisco_ipaddr_type_info.fields') /vol/share/src/sys/netgraph/ng_cisco.c:132: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_cisco.c:132: warning: (near initialization for `ng_cisco_ipaddr_type_info.fields') /vol/share/src/sys/netgraph/ng_cisco.c:140: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_cisco.c:140: warning: (near initialization for `ng_cisco_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_cisco.c:140: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_cisco.c:140: warning: (near initialization for `ng_cisco_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_cisco.c:140: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_cisco.c:140: warning: (near initialization for `ng_cisco_stats_type_info.fields') ld -d -warn-common -r -d -o ng_cisco.kld ng_cisco.o ld -Bshareable -d -warn-common -o ng_cisco.ko.debug ng_cisco.kld objcopy --strip-debug ng_cisco.ko.debug ng_cisco.ko ===> netgraph/echo ===> netgraph/eiface cc -O -pipe -Wall -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -c /vol/share/src/sys/netgraph/ng_eiface.c In file included from /vol/share/src/sys/netgraph/ng_eiface.c:54: @/netgraph/ng_eiface.h:73: warning: excess elements in array initializer @/netgraph/ng_eiface.h:73: warning: (near initialization for `ng_eiface_par_fields.fields') @/netgraph/ng_eiface.h:74: warning: excess elements in array initializer @/netgraph/ng_eiface.h:74: warning: (near initialization for `ng_eiface_par_fields.fields') @/netgraph/ng_eiface.h:75: warning: excess elements in array initializer @/netgraph/ng_eiface.h:75: warning: (near initialization for `ng_eiface_par_fields.fields') @/netgraph/ng_eiface.h:76: warning: excess elements in array initializer @/netgraph/ng_eiface.h:76: warning: (near initialization for `ng_eiface_par_fields.fields') @/netgraph/ng_eiface.h:77: warning: excess elements in array initializer @/netgraph/ng_eiface.h:77: warning: (near initialization for `ng_eiface_par_fields.fields') @/netgraph/ng_eiface.h:78: warning: excess elements in array initializer @/netgraph/ng_eiface.h:78: warning: (near initialization for `ng_eiface_par_fields.fields') @/netgraph/ng_eiface.h:79: warning: excess elements in array initializer @/netgraph/ng_eiface.h:79: warning: (near initialization for `ng_eiface_par_fields.fields') ld -d -warn-common -r -d -o ng_eiface.kld ng_eiface.o ld -Bshareable -d -warn-common -o ng_eiface.ko.debug ng_eiface.kld objcopy --strip-debug ng_eiface.ko.debug ng_eiface.ko ===> netgraph/ether cc -O -pipe -Wall -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -c /vol/share/src/sys/netgraph/ng_ether.c ld -d -warn-common -r -d -o ng_ether.kld ng_ether.o ld -Bshareable -d -warn-common -o ng_ether.ko.debug ng_ether.kld objcopy --strip-debug ng_ether.ko.debug ng_ether.ko ===> netgraph/etf cc -O -pipe -Wall -g -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -c /vol/share/src/sys/netgraph/ng_etf.c /vol/share/src/sys/netgraph/ng_etf.c:74: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_etf.c:74: warning: (near initialization for `ng_etf_stat_type_info.fields') /vol/share/src/sys/netgraph/ng_etf.c:74: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_etf.c:74: warning: (near initialization for `ng_etf_stat_type_info.fields') /vol/share/src/sys/netgraph/ng_etf.c:74: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_etf.c:74: warning: (near initialization for `ng_etf_stat_type_info.fields') /vol/share/src/sys/netgraph/ng_etf.c:81: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_etf.c:81: warning: (near initialization for `ng_etf_filter_type_info.fields') /vol/share/src/sys/netgraph/ng_etf.c:81: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_etf.c:81: warning: (near initialization for `ng_etf_filter_type_info.fields') /vol/share/src/sys/netgraph/ng_etf.c:81: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_etf.c:81: warning: (near initialization for `ng_etf_filter_type_info.fields') ld -d -warn-common -r -d -o ng_etf.kld ng_etf.o ld -Bshareable -d -warn-common -o ng_etf.ko.debug ng_etf.kld objcopy --strip-debug ng_etf.ko.debug ng_etf.ko ===> netgraph/frame_relay ===> netgraph/gif cc -O -pipe -Wall -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -c /vol/share/src/sys/netgraph/ng_gif.c ld -d -warn-common -r -d -o ng_gif.kld ng_gif.o ld -Bshareable -d -warn-common -o ng_gif.ko.debug ng_gif.kld objcopy --strip-debug ng_gif.ko.debug ng_gif.ko ===> netgraph/gif_demux cc -O -pipe -Wall -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -c /vol/share/src/sys/netgraph/ng_gif_demux.c ld -d -warn-common -r -d -o ng_gif_demux.kld ng_gif_demux.o ld -Bshareable -d -warn-common -o ng_gif_demux.ko.debug ng_gif_demux.kld objcopy --strip-debug ng_gif_demux.ko.debug ng_gif_demux.ko ===> netgraph/hole ===> netgraph/iface cc -O -pipe -Wall -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -c /vol/share/src/sys/netgraph/ng_iface.c /vol/share/src/sys/netgraph/ng_iface.c:149: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_iface.c:149: warning: (near initialization for `ng_cisco_ipaddr_type_info.fields') /vol/share/src/sys/netgraph/ng_iface.c:149: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_iface.c:149: warning: (near initialization for `ng_cisco_ipaddr_type_info.fields') /vol/share/src/sys/netgraph/ng_iface.c:149: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_iface.c:149: warning: (near initialization for `ng_cisco_ipaddr_type_info.fields') ld -d -warn-common -r -d -o ng_iface.kld ng_iface.o ld -Bshareable -d -warn-common -o ng_iface.ko.debug ng_iface.kld objcopy --strip-debug ng_iface.ko.debug ng_iface.ko ===> netgraph/ip_input ===> netgraph/ksocket cc -O -pipe -Wall -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -c /vol/share/src/sys/netgraph/ng_ksocket.c /vol/share/src/sys/netgraph/ng_ksocket.c:189: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ksocket.c:189: warning: (near initialization for `ng_parse_generic_sockaddr_type_info.fields') /vol/share/src/sys/netgraph/ng_ksocket.c:190: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ksocket.c:190: warning: (near initialization for `ng_parse_generic_sockaddr_type_info.fields') /vol/share/src/sys/netgraph/ng_ksocket.c:191: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ksocket.c:191: warning: (near initialization for `ng_parse_generic_sockaddr_type_info.fields') /vol/share/src/sys/netgraph/ng_ksocket.c:192: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ksocket.c:192: warning: (near initialization for `ng_parse_generic_sockaddr_type_info.fields') /vol/share/src/sys/netgraph/ng_ksocket.c:418: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ksocket.c:418: warning: (near initialization for `ng_ksocket_sockopt_type_info.fields') /vol/share/src/sys/netgraph/ng_ksocket.c:418: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ksocket.c:418: warning: (near initialization for `ng_ksocket_sockopt_type_info.fields') /vol/share/src/sys/netgraph/ng_ksocket.c:418: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ksocket.c:418: warning: (near initialization for `ng_ksocket_sockopt_type_info.fields') /vol/share/src/sys/netgraph/ng_ksocket.c:418: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ksocket.c:418: warning: (near initialization for `ng_ksocket_sockopt_type_info.fields') /vol/share/src/sys/netgraph/ng_ksocket.c:426: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ksocket.c:426: warning: (near initialization for `ng_ksocket_accept_type_info.fields') /vol/share/src/sys/netgraph/ng_ksocket.c:426: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ksocket.c:426: warning: (near initialization for `ng_ksocket_accept_type_info.fields') /vol/share/src/sys/netgraph/ng_ksocket.c:426: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ksocket.c:426: warning: (near initialization for `ng_ksocket_accept_type_info.fields') ld -d -warn-common -r -d -o ng_ksocket.kld ng_ksocket.o ld -Bshareable -d -warn-common -o ng_ksocket.ko.debug ng_ksocket.kld objcopy --strip-debug ng_ksocket.ko.debug ng_ksocket.ko ===> netgraph/lmi ===> netgraph/netgraph cc -O -pipe -Wall -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -c /vol/share/src/sys/netgraph/ng_base.c /vol/share/src/sys/netgraph/ng_base.c:365: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:365: warning: (near initialization for `ng_mkpeer_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:365: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:365: warning: (near initialization for `ng_mkpeer_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:365: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:365: warning: (near initialization for `ng_mkpeer_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:365: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:365: warning: (near initialization for `ng_mkpeer_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:366: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:366: warning: (near initialization for `ng_connect_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:366: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:366: warning: (near initialization for `ng_connect_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:366: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:366: warning: (near initialization for `ng_connect_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:366: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:366: warning: (near initialization for `ng_connect_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:367: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:367: warning: (near initialization for `ng_name_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:367: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:367: warning: (near initialization for `ng_name_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:368: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:368: warning: (near initialization for `ng_rmhook_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:368: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:368: warning: (near initialization for `ng_rmhook_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:369: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:369: warning: (near initialization for `ng_nodeinfo_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:369: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:369: warning: (near initialization for `ng_nodeinfo_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:369: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:369: warning: (near initialization for `ng_nodeinfo_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:369: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:369: warning: (near initialization for `ng_nodeinfo_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:369: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:369: warning: (near initialization for `ng_nodeinfo_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:370: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:370: warning: (near initialization for `ng_typeinfo_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:370: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:370: warning: (near initialization for `ng_typeinfo_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:370: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:370: warning: (near initialization for `ng_typeinfo_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:371: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:371: warning: (near initialization for `ng_linkinfo_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:371: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:371: warning: (near initialization for `ng_linkinfo_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:371: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:371: warning: (near initialization for `ng_linkinfo_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:371: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:371: warning: (near initialization for `ng_linkinfo_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:423: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:423: warning: (near initialization for `ng_typelist_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:423: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:423: warning: (near initialization for `ng_typelist_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:423: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:423: warning: (near initialization for `ng_typelist_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:425: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:425: warning: (near initialization for `ng_hooklist_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:425: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:425: warning: (near initialization for `ng_hooklist_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:425: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:425: warning: (near initialization for `ng_hooklist_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:427: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:427: warning: (near initialization for `ng_listnodes_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:427: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:427: warning: (near initialization for `ng_listnodes_type_info.fields') /vol/share/src/sys/netgraph/ng_base.c:427: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_base.c:427: warning: (near initialization for `ng_listnodes_type_info.fields') cc -O -pipe -Wall -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -c /vol/share/src/sys/netgraph/ng_parse.c /vol/share/src/sys/netgraph/ng_parse.c:1120: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_parse.c:1120: warning: (near initialization for `ng_parse_ng_mesg_type_info.fields') /vol/share/src/sys/netgraph/ng_parse.c:1120: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_parse.c:1120: warning: (near initialization for `ng_parse_ng_mesg_type_info.fields') /vol/share/src/sys/netgraph/ng_parse.c:1120: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_parse.c:1120: warning: (near initialization for `ng_parse_ng_mesg_type_info.fields') /vol/share/src/sys/netgraph/ng_parse.c:1120: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_parse.c:1120: warning: (near initialization for `ng_parse_ng_mesg_type_info.fields') /vol/share/src/sys/netgraph/ng_parse.c:1120: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_parse.c:1120: warning: (near initialization for `ng_parse_ng_mesg_type_info.fields') /vol/share/src/sys/netgraph/ng_parse.c:1120: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_parse.c:1120: warning: (near initialization for `ng_parse_ng_mesg_type_info.fields') /vol/share/src/sys/netgraph/ng_parse.c:1120: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_parse.c:1120: warning: (near initialization for `ng_parse_ng_mesg_type_info.fields') /vol/share/src/sys/netgraph/ng_parse.c:1120: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_parse.c:1120: warning: (near initialization for `ng_parse_ng_mesg_type_info.fields') /vol/share/src/sys/netgraph/ng_parse.c:1120: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_parse.c:1120: warning: (near initialization for `ng_parse_ng_mesg_type_info.fields') /vol/share/src/sys/netgraph/ng_parse.c:1120: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_parse.c:1120: warning: (near initialization for `ng_parse_ng_mesg_type_info.fields') ld -d -warn-common -r -d -o netgraph.kld ng_base.o ng_parse.o ld -Bshareable -d -warn-common -o netgraph.ko.debug netgraph.kld objcopy --strip-debug netgraph.ko.debug netgraph.ko ===> netgraph/one2many cc -O -pipe -Wall -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -c /vol/share/src/sys/netgraph/ng_one2many.c /vol/share/src/sys/netgraph/ng_one2many.c:109: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_one2many.c:109: warning: (near initialization for `ng_one2many_config_type_info.fields') /vol/share/src/sys/netgraph/ng_one2many.c:109: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_one2many.c:109: warning: (near initialization for `ng_one2many_config_type_info.fields') /vol/share/src/sys/netgraph/ng_one2many.c:109: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_one2many.c:109: warning: (near initialization for `ng_one2many_config_type_info.fields') /vol/share/src/sys/netgraph/ng_one2many.c:109: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_one2many.c:109: warning: (near initialization for `ng_one2many_config_type_info.fields') /vol/share/src/sys/netgraph/ng_one2many.c:117: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_one2many.c:117: warning: (near initialization for `ng_one2many_link_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_one2many.c:117: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_one2many.c:117: warning: (near initialization for `ng_one2many_link_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_one2many.c:117: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_one2many.c:117: warning: (near initialization for `ng_one2many_link_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_one2many.c:117: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_one2many.c:117: warning: (near initialization for `ng_one2many_link_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_one2many.c:117: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_one2many.c:117: warning: (near initialization for `ng_one2many_link_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_one2many.c:117: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_one2many.c:117: warning: (near initialization for `ng_one2many_link_stats_type_info.fields') ld -d -warn-common -r -d -o ng_one2many.kld ng_one2many.o ld -Bshareable -d -warn-common -o ng_one2many.ko.debug ng_one2many.kld objcopy --strip-debug ng_one2many.ko.debug ng_one2many.ko ===> netgraph/ppp cc -O -pipe -Wall -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -c /vol/share/src/sys/netgraph/ng_ppp.c /vol/share/src/sys/netgraph/ng_ppp.c:258: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:258: warning: (near initialization for `ng_ppp_mp_state_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:258: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:258: warning: (near initialization for `ng_ppp_mp_state_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:258: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:258: warning: (near initialization for `ng_ppp_mp_state_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:258: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:258: warning: (near initialization for `ng_ppp_mp_state_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:266: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:266: warning: (near initialization for `ng_ppp_link_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:266: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:266: warning: (near initialization for `ng_ppp_link_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:266: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:266: warning: (near initialization for `ng_ppp_link_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:266: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:266: warning: (near initialization for `ng_ppp_link_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:266: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:266: warning: (near initialization for `ng_ppp_link_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:266: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:266: warning: (near initialization for `ng_ppp_link_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:266: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:266: warning: (near initialization for `ng_ppp_link_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: (near initialization for `ng_ppp_bund_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: (near initialization for `ng_ppp_bund_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: (near initialization for `ng_ppp_bund_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: (near initialization for `ng_ppp_bund_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: (near initialization for `ng_ppp_bund_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: (near initialization for `ng_ppp_bund_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: (near initialization for `ng_ppp_bund_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: (near initialization for `ng_ppp_bund_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: (near initialization for `ng_ppp_bund_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: (near initialization for `ng_ppp_bund_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: (near initialization for `ng_ppp_bund_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: (near initialization for `ng_ppp_bund_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: (near initialization for `ng_ppp_bund_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: (near initialization for `ng_ppp_bund_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: (near initialization for `ng_ppp_bund_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:274: warning: (near initialization for `ng_ppp_bund_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:290: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:290: warning: (near initialization for `ng_ppp_conf_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:290: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:290: warning: (near initialization for `ng_ppp_conf_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:290: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:290: warning: (near initialization for `ng_ppp_conf_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:298: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:298: warning: (near initialization for `ng_ppp_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:298: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:298: warning: (near initialization for `ng_ppp_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:298: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:298: warning: (near initialization for `ng_ppp_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:298: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:298: warning: (near initialization for `ng_ppp_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:298: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:298: warning: (near initialization for `ng_ppp_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:298: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:298: warning: (near initialization for `ng_ppp_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:298: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:298: warning: (near initialization for `ng_ppp_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:298: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:298: warning: (near initialization for `ng_ppp_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_ppp.c:298: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_ppp.c:298: warning: (near initialization for `ng_ppp_stats_type_info.fields') ld -d -warn-common -r -d -o ng_ppp.kld ng_ppp.o ld -Bshareable -d -warn-common -o ng_ppp.ko.debug ng_ppp.kld objcopy --strip-debug ng_ppp.ko.debug ng_ppp.ko ===> netgraph/pppoe cc -O -pipe -Wall -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -c /vol/share/src/sys/netgraph/ng_pppoe.c /vol/share/src/sys/netgraph/ng_pppoe.c:88: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pppoe.c:88: warning: (near initialization for `ngpppoe_init_data_type_info.fields') /vol/share/src/sys/netgraph/ng_pppoe.c:88: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pppoe.c:88: warning: (near initialization for `ngpppoe_init_data_type_info.fields') /vol/share/src/sys/netgraph/ng_pppoe.c:88: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pppoe.c:88: warning: (near initialization for `ngpppoe_init_data_type_info.fields') /vol/share/src/sys/netgraph/ng_pppoe.c:96: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pppoe.c:96: warning: (near initialization for `ng_pppoe_sts_type_info.fields') /vol/share/src/sys/netgraph/ng_pppoe.c:96: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pppoe.c:96: warning: (near initialization for `ng_pppoe_sts_type_info.fields') ld -d -warn-common -r -d -o ng_pppoe.kld ng_pppoe.o ld -Bshareable -d -warn-common -o ng_pppoe.ko.debug ng_pppoe.kld objcopy --strip-debug ng_pppoe.ko.debug ng_pppoe.ko ===> netgraph/pptpgre cc -O -pipe -Wall -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -c /vol/share/src/sys/netgraph/ng_pptpgre.c /vol/share/src/sys/netgraph/ng_pptpgre.c:195: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pptpgre.c:195: warning: (near initialization for `ng_pptpgre_conf_type_info.fields') /vol/share/src/sys/netgraph/ng_pptpgre.c:195: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pptpgre.c:195: warning: (near initialization for `ng_pptpgre_conf_type_info.fields') /vol/share/src/sys/netgraph/ng_pptpgre.c:195: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pptpgre.c:195: warning: (near initialization for `ng_pptpgre_conf_type_info.fields') /vol/share/src/sys/netgraph/ng_pptpgre.c:195: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pptpgre.c:195: warning: (near initialization for `ng_pptpgre_conf_type_info.fields') /vol/share/src/sys/netgraph/ng_pptpgre.c:195: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pptpgre.c:195: warning: (near initialization for `ng_pptpgre_conf_type_info.fields') /vol/share/src/sys/netgraph/ng_pptpgre.c:195: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pptpgre.c:195: warning: (near initialization for `ng_pptpgre_conf_type_info.fields') /vol/share/src/sys/netgraph/ng_pptpgre.c:195: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pptpgre.c:195: warning: (near initialization for `ng_pptpgre_conf_type_info.fields') /vol/share/src/sys/netgraph/ng_pptpgre.c:195: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pptpgre.c:195: warning: (near initialization for `ng_pptpgre_conf_type_info.fields') /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: (near initialization for `ng_pptpgre_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: (near initialization for `ng_pptpgre_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: (near initialization for `ng_pptpgre_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: (near initialization for `ng_pptpgre_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: (near initialization for `ng_pptpgre_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: (near initialization for `ng_pptpgre_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: (near initialization for `ng_pptpgre_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: (near initialization for `ng_pptpgre_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: (near initialization for `ng_pptpgre_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: (near initialization for `ng_pptpgre_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: (near initialization for `ng_pptpgre_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: (near initialization for `ng_pptpgre_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: (near initialization for `ng_pptpgre_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: (near initialization for `ng_pptpgre_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: (near initialization for `ng_pptpgre_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: (near initialization for `ng_pptpgre_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_pptpgre.c:203: warning: (near initialization for `ng_pptpgre_stats_type_info.fields') ld -d -warn-common -r -d -o ng_pptpgre.kld ng_pptpgre.o ld -Bshareable -d -warn-common -o ng_pptpgre.ko.debug ng_pptpgre.kld objcopy --strip-debug ng_pptpgre.ko.debug ng_pptpgre.ko ===> netgraph/rfc1490 ===> netgraph/socket ===> netgraph/split ===> netgraph/sync_ar ===> netgraph/sync_sr ===> netgraph/tee cc -O -pipe -Wall -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -c /vol/share/src/sys/netgraph/ng_tee.c /vol/share/src/sys/netgraph/ng_tee.c:89: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_tee.c:89: warning: (near initialization for `ng_tee_hookstat_type_info.fields') /vol/share/src/sys/netgraph/ng_tee.c:89: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_tee.c:89: warning: (near initialization for `ng_tee_hookstat_type_info.fields') /vol/share/src/sys/netgraph/ng_tee.c:89: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_tee.c:89: warning: (near initialization for `ng_tee_hookstat_type_info.fields') /vol/share/src/sys/netgraph/ng_tee.c:89: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_tee.c:89: warning: (near initialization for `ng_tee_hookstat_type_info.fields') /vol/share/src/sys/netgraph/ng_tee.c:89: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_tee.c:89: warning: (near initialization for `ng_tee_hookstat_type_info.fields') /vol/share/src/sys/netgraph/ng_tee.c:97: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_tee.c:97: warning: (near initialization for `ng_tee_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_tee.c:97: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_tee.c:97: warning: (near initialization for `ng_tee_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_tee.c:97: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_tee.c:97: warning: (near initialization for `ng_tee_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_tee.c:97: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_tee.c:97: warning: (near initialization for `ng_tee_stats_type_info.fields') /vol/share/src/sys/netgraph/ng_tee.c:97: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_tee.c:97: warning: (near initialization for `ng_tee_stats_type_info.fields') ld -d -warn-common -r -d -o ng_tee.kld ng_tee.o ld -Bshareable -d -warn-common -o ng_tee.ko.debug ng_tee.kld objcopy --strip-debug ng_tee.ko.debug ng_tee.ko ===> netgraph/tty ===> netgraph/UI ===> netgraph/vjc cc -O -pipe -Wall -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -c /vol/share/src/sys/netgraph/ng_vjc.c /vol/share/src/sys/netgraph/ng_vjc.c:102: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_vjc.c:102: warning: (near initialization for `ng_vjc_config_type_info.fields') /vol/share/src/sys/netgraph/ng_vjc.c:102: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_vjc.c:102: warning: (near initialization for `ng_vjc_config_type_info.fields') /vol/share/src/sys/netgraph/ng_vjc.c:102: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_vjc.c:102: warning: (near initialization for `ng_vjc_config_type_info.fields') /vol/share/src/sys/netgraph/ng_vjc.c:102: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_vjc.c:102: warning: (near initialization for `ng_vjc_config_type_info.fields') /vol/share/src/sys/netgraph/ng_vjc.c:102: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_vjc.c:102: warning: (near initialization for `ng_vjc_config_type_info.fields') /vol/share/src/sys/netgraph/ng_vjc.c:132: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_vjc.c:132: warning: (near initialization for `ng_vjc_cstate_type_info.fields') /vol/share/src/sys/netgraph/ng_vjc.c:133: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_vjc.c:133: warning: (near initialization for `ng_vjc_cstate_type_info.fields') /vol/share/src/sys/netgraph/ng_vjc.c:134: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_vjc.c:134: warning: (near initialization for `ng_vjc_cstate_type_info.fields') /vol/share/src/sys/netgraph/ng_vjc.c:135: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_vjc.c:135: warning: (near initialization for `ng_vjc_cstate_type_info.fields') /vol/share/src/sys/netgraph/ng_vjc.c:136: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_vjc.c:136: warning: (near initialization for `ng_vjc_cstate_type_info.fields') /vol/share/src/sys/netgraph/ng_vjc.c:137: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_vjc.c:137: warning: (near initialization for `ng_vjc_cstate_type_info.fields') /vol/share/src/sys/netgraph/ng_vjc.c:159: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_vjc.c:159: warning: (near initialization for `ng_vjc_slcompress_type_info.fields') /vol/share/src/sys/netgraph/ng_vjc.c:160: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_vjc.c:160: warning: (near initialization for `ng_vjc_slcompress_type_info.fields') /vol/share/src/sys/netgraph/ng_vjc.c:161: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_vjc.c:161: warning: (near initialization for `ng_vjc_slcompress_type_info.fields') /vol/share/src/sys/netgraph/ng_vjc.c:162: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_vjc.c:162: warning: (near initialization for `ng_vjc_slcompress_type_info.fields') /vol/share/src/sys/netgraph/ng_vjc.c:164: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_vjc.c:164: warning: (near initialization for `ng_vjc_slcompress_type_info.fields') /vol/share/src/sys/netgraph/ng_vjc.c:165: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_vjc.c:165: warning: (near initialization for `ng_vjc_slcompress_type_info.fields') /vol/share/src/sys/netgraph/ng_vjc.c:166: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_vjc.c:166: warning: (near initialization for `ng_vjc_slcompress_type_info.fields') /vol/share/src/sys/netgraph/ng_vjc.c:167: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_vjc.c:167: warning: (near initialization for `ng_vjc_slcompress_type_info.fields') /vol/share/src/sys/netgraph/ng_vjc.c:168: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_vjc.c:168: warning: (near initialization for `ng_vjc_slcompress_type_info.fields') /vol/share/src/sys/netgraph/ng_vjc.c:169: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_vjc.c:169: warning: (near initialization for `ng_vjc_slcompress_type_info.fields') /vol/share/src/sys/netgraph/ng_vjc.c:170: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_vjc.c:170: warning: (near initialization for `ng_vjc_slcompress_type_info.fields') /vol/share/src/sys/netgraph/ng_vjc.c:171: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_vjc.c:171: warning: (near initialization for `ng_vjc_slcompress_type_info.fields') /vol/share/src/sys/netgraph/ng_vjc.c:173: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_vjc.c:173: warning: (near initialization for `ng_vjc_slcompress_type_info.fields') /vol/share/src/sys/netgraph/ng_vjc.c:174: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_vjc.c:174: warning: (near initialization for `ng_vjc_slcompress_type_info.fields') /vol/share/src/sys/netgraph/ng_vjc.c:175: warning: excess elements in array initializer /vol/share/src/sys/netgraph/ng_vjc.c:175: warning: (near initialization for `ng_vjc_slcompress_type_info.fields') ld -d -warn-common -r -d -o ng_vjc.kld ng_vjc.o slcompress.o ld -Bshareable -d -warn-common -o ng_vjc.ko.debug ng_vjc.kld objcopy --strip-debug ng_vjc.ko.debug ng_vjc.ko ===> netgraph/mppc `all' not remade because of errors. bah. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 29 8:22:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 79B0A37B400 for ; Wed, 29 May 2002 08:22:40 -0700 (PDT) Received: from whizzo.transsys.com (#6@localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.12.3/8.12.3) with ESMTP id g4TFMdRG076033; Wed, 29 May 2002 11:22:40 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200205291522.g4TFMdRG076033@whizzo.transsys.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Andre Oppermann Cc: Attila Nagy , Luigi Iannone , freebsd-net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: MPLS References: <3CF4A64A.EE220611@pipeline.ch> <200205291413.g4TEDLRG075458@whizzo.transsys.com> <3CF4E483.2510639@pipeline.ch> In-reply-to: Your message of "Wed, 29 May 2002 16:24:03 +0200." <3CF4E483.2510639@pipeline.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 May 2002 11:22:39 -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > If there is no kind of software involved on the forwarding plane > then I don't know how the control plane can communicate via ethernet > with the line cards... The internal communication in the router is > via ethernet. To be clear, "forwarding plane" to me means the machinary which causes packets that are received on one network interface on the router to be routed and sent out another (or same) interface on the router. "Control plane" is the stuff which executes the routing protocols, and does various management tasks in the router, including setting up forwarding tables used by the ASIC hardware. The control plane (e.g., the route processor) is connected to the forwarding infrastructure so it's able to send and receive traffic via the other ports on the box. Do not confuse the ethernet on the control processor with the "real" (Gigabit) Ethernet interfaces which plug into the line cards. They source and sink traffic just like the various other line card interfaces (various POS and ATM interfaces.) Also, there's no fowarding table on the line cards, either. The ASIC (one on the M5, M10, M20 and M40, 4 on the M160) are associated with the backplane of the router. Further detail may be covered by non-disclosure agreements which I'm subject to. > > The forwarding is done in Juniper's custom designed ASIC hardware, > > and is the other significantly valuable intellectual property > > they have along with the routing protocol implementation (e.g., > > BGP, IS-IS, etc.) > > I agree with the ASIC hardware. But the BGP implementation smells > awfully like gated (Nexthop). Anyway, a BGP deamon isn't that hard > to write. Please don't take this the wrong way, but this sounds like a statement from someone that's never done it before. In my professional role, I've seen literally a dozen or more vendors get the routing protocol implementation Really Wrong. Sure, building and parsing BGP protocol packet isn't that hard; the interesting bit is the policy machinary which filters and computes routes. For a router in the default-free core of the Internet, this is a rather daunting task. While the JunOS implementation might smell like gated, it has significantly more functionality and reliability than /usr/ports/net/gated does. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 29 8:40:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by hub.freebsd.org (Postfix) with ESMTP id C87D237B404 for ; Wed, 29 May 2002 08:40:49 -0700 (PDT) Received: from stl-av-02.boeing.com ([192.76.190.7]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA08465 for ; Wed, 29 May 2002 10:36:09 -0500 (CDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id KAA24368 for ; Wed, 29 May 2002 10:40:48 -0500 (CDT) Received: from xch-nwbh-02.nw.nos.boeing.com (xch-nwbh-02.nw.nos.boeing.com [192.54.12.28]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g4TFekH11001 for ; Wed, 29 May 2002 08:40:46 -0700 (PDT) Received: by xch-nwbh-02.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 May 2002 08:40:46 -0700 Message-ID: From: "Albuquerque, Marcelo M" To: "'freebsd-net@freeBSD.ORG'" Subject: Does "xmit" work with ipfw dummynet? Date: Wed, 29 May 2002 08:40:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org dummynet is not behaving as expected, and I'm wondering whether the command is compatible with bridging mode (freebsd 4.5): sysctl -w net.link.ether.bridge=1 Here is the setup: ___________________ | | 192.168.1.1 --- |FreeBSD 4.5 Bridge | --- 192.168.1.2 |___________________| | | 192.168.1.3 This works: ipfw add 100 deny ip from any to any in recv fxp0 This doesn't: ipfw add 100 deny ip from any to any out xmit fxp1 What I really want, but fear is not supported, is: ipfw add 100 deny ip from any to any out recv fxp0 xmit fxp1 That is, I want to block traffic coming in from fxp0 and going out fxp1, in bridged mode. Anyone know if this is possible? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 29 8:42:42 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 7D8EA37B405 for ; Wed, 29 May 2002 08:42:34 -0700 (PDT) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g4TFgRU21425; Wed, 29 May 2002 08:42:27 -0700 (PDT) (envelope-from rizzo) Date: Wed, 29 May 2002 08:42:27 -0700 From: Luigi Rizzo To: "Albuquerque, Marcelo M" Cc: "'freebsd-net@freeBSD.ORG'" Subject: Re: Does "xmit" work with ipfw dummynet? Message-ID: <20020529084227.A21332@iguana.icir.org> 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 marcelo.m.albuquerque@boeing.com on Wed, May 29, 2002 at 08:40:36AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, May 29, 2002 at 08:40:36AM -0700, Albuquerque, Marcelo M wrote: > dummynet is not behaving as expected, and I'm wondering whether the command > is compatible with bridging mode (freebsd 4.5): xmit cannot match on bridged packets luigi > > Here is the setup: > > ___________________ > | | > 192.168.1.1 --- |FreeBSD 4.5 Bridge | --- 192.168.1.2 > |___________________| > | > | > 192.168.1.3 > > > This works: > ipfw add 100 deny ip from any to any in recv fxp0 > > This doesn't: > ipfw add 100 deny ip from any to any out xmit fxp1 > > What I really want, but fear is not supported, is: > ipfw add 100 deny ip from any to any out recv fxp0 xmit fxp1 > > That is, I want to block traffic coming in from fxp0 and going out > fxp1, in bridged mode. > > Anyone know if this is possible? > > > 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 May 29 9: 9:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 383E937B407 for ; Wed, 29 May 2002 09:09:38 -0700 (PDT) Received: (qmail 54135 invoked from network); 29 May 2002 16:09:19 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 29 May 2002 16:09:19 -0000 Message-ID: <3CF4FCFC.3D760508@pipeline.ch> Date: Wed, 29 May 2002 18:08:28 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Louis A. Mamakos" Cc: Attila Nagy , Luigi Iannone , freebsd-net@FreeBSD.ORG Subject: Re: MPLS References: <3CF4A64A.EE220611@pipeline.ch> <200205291413.g4TEDLRG075458@whizzo.transsys.com> <3CF4E483.2510639@pipeline.ch> <200205291522.g4TFMdRG076033@whizzo.transsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org "Louis A. Mamakos" wrote: > > > If there is no kind of software involved on the forwarding plane > > then I don't know how the control plane can communicate via ethernet > > with the line cards... The internal communication in the router is > > via ethernet. > > To be clear, "forwarding plane" to me means the machinary which > causes packets that are received on one network interface on the > router to be routed and sent out another (or same) interface on > the router. "Control plane" is the stuff which executes the > routing protocols, and does various management tasks in the > router, including setting up forwarding tables used by the ASIC > hardware. Agreed. > The control plane (e.g., the route processor) is connected to > the forwarding infrastructure so it's able to send and receive > traffic via the other ports on the box. Agreed. > Do not confuse the ethernet on the control processor with the > "real" (Gigabit) Ethernet interfaces which plug into the line cards. > They source and sink traffic just like the various other line card > interfaces (various POS and ATM interfaces.) No, I don't confuse that. What I'm saying is that the box is doing it's internal communication via Ethernet. > Also, there's no fowarding table on the line cards, either. The > ASIC (one on the M5, M10, M20 and M40, 4 on the M160) are associated > with the backplane of the router. > > Further detail may be covered by non-disclosure agreements which > I'm subject to. > > > > The forwarding is done in Juniper's custom designed ASIC hardware, > > > and is the other significantly valuable intellectual property > > > they have along with the routing protocol implementation (e.g., > > > BGP, IS-IS, etc.) > > > > I agree with the ASIC hardware. But the BGP implementation smells > > awfully like gated (Nexthop). Anyway, a BGP deamon isn't that hard > > to write. > > Please don't take this the wrong way, but this sounds like a statement > from someone that's never done it before. In my professional role, We've done worse things than that. Some of the stuff we've done you can find on http://www.bgpdns.org. This is only the public stuff. We have more stuff in the works which I can't talk about yet. But you'll see some of the network stack work in FreeBSD if it gets adopted. (We is me and another code monkey). > I've seen literally a dozen or more vendors get the routing protocol > implementation Really Wrong. Sure, building and parsing BGP protocol > packet isn't that hard; the interesting bit is the policy machinary > which filters and computes routes. For a router in the default-free > core of the Internet, this is a rather daunting task. While the > JunOS implementation might smell like gated, it has significantly > more functionality and reliability than /usr/ports/net/gated does. It's clear to me that this is not based on the old 3.6 gated that is have in ports. The Nexthop stuff is more advanced. Zebra also is very reliable and I use it on many FreeBSD based routers here around. Agreed, each of these things don't push more than 50Mbit/s. But that is basically a problem of the old BSD network stack / crappy kernel routing (for- warding) table. Expect some nice work in this area in the next few month. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 29 9:36:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by hub.freebsd.org (Postfix) with ESMTP id AD2DA37B40D for ; Wed, 29 May 2002 09:35:43 -0700 (PDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA06969; Wed, 29 May 2002 09:33:18 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id JAA14820; Wed, 29 May 2002 09:35:42 -0700 (PDT) Received: from xch-nwbh-02.nw.nos.boeing.com (xch-nwbh-02.nw.nos.boeing.com [192.54.12.28]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g4TGZfH28532; Wed, 29 May 2002 09:35:41 -0700 (PDT) Received: by xch-nwbh-02.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 May 2002 09:35:17 -0700 Message-ID: From: "Albuquerque, Marcelo M" To: "'Luigi Rizzo'" Cc: "'freebsd-net@freeBSD.ORG'" Subject: RE: Does "xmit" work with ipfw dummynet? Date: Wed, 29 May 2002 09:35:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thanks Luigi. > xmit cannot match on bridged packets Is it a hard problem to make xmit compatible with bridged packets or is it just that no one had the need yet to implement the changes? Is there any way around this limitation that would allow us to achive the same goal? -----Original Message----- From: Luigi Rizzo [mailto:rizzo@icir.org] Sent: Wednesday, May 29, 2002 8:42 AM To: Albuquerque, Marcelo M Cc: 'freebsd-net@freeBSD.ORG' Subject: Re: Does "xmit" work with ipfw dummynet? On Wed, May 29, 2002 at 08:40:36AM -0700, Albuquerque, Marcelo M wrote: > dummynet is not behaving as expected, and I'm wondering whether the command > is compatible with bridging mode (freebsd 4.5): xmit cannot match on bridged packets luigi > > Here is the setup: > > ___________________ > | | > 192.168.1.1 --- |FreeBSD 4.5 Bridge | --- 192.168.1.2 > |___________________| > | > | > 192.168.1.3 > > > This works: > ipfw add 100 deny ip from any to any in recv fxp0 > > This doesn't: > ipfw add 100 deny ip from any to any out xmit fxp1 > > What I really want, but fear is not supported, is: > ipfw add 100 deny ip from any to any out recv fxp0 xmit fxp1 > > That is, I want to block traffic coming in from fxp0 and going out > fxp1, in bridged mode. > > Anyone know if this is possible? > > > 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 May 29 10:25:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by hub.freebsd.org (Postfix) with ESMTP id 8E8C437C206 for ; Wed, 29 May 2002 10:15:28 -0700 (PDT) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.3/8.11.6) with ESMTP id g4TH917f018013; Wed, 29 May 2002 13:09:02 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200205291709.g4TH917f018013@nic-naa.net> To: Andre Oppermann Cc: "Louis A. Mamakos" , Attila Nagy , Luigi Iannone , freebsd-net@FreeBSD.ORG, brunner@nic-naa.net Subject: Re: MPLS In-Reply-To: Your message of "Wed, 29 May 2002 18:08:28 +0200." <3CF4FCFC.3D760508@pipeline.ch> Date: Wed, 29 May 2002 13:09:01 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ... > It's clear to me that this is not based on the old 3.6 gated that is > have in ports. The Nexthop stuff is more advanced. Zebra also is very > reliable ... You might want to check the status of ports/net/gated. I've been giving this some thought since the rev 1.32 of the Makefile caught my attention on the cvs-all list. Eric To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 29 10:52:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95]) by hub.freebsd.org (Postfix) with SMTP id EAB6537B47B for ; Wed, 29 May 2002 10:52:11 -0700 (PDT) Received: (qmail 17920 invoked by uid 1000); 29 May 2002 17:52:26 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 29 May 2002 17:52:26 -0000 Date: Wed, 29 May 2002 19:52:26 +0200 (CEST) From: Attila Nagy To: Andre Oppermann Cc: Luigi Iannone , Subject: Re: MPLS In-Reply-To: <3CF4A555.41CA27E4@pipeline.ch> Message-ID: References: <3CF4A555.41CA27E4@pipeline.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, > > I developped a basic implementation of MPLS over Ethernet in the FreeBSD > > Environment! If someone is interested in my code just e.mail me! > I'm interested in it. BTW, there is a Linux-based effort to make it MPLS-aware -> http://sourceforge.net/projects/mpls-linux/ --------[ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]------- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 29 10:52:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [64.186.142.66]) by hub.freebsd.org (Postfix) with ESMTP id 9D83737B445 for ; Wed, 29 May 2002 10:52:11 -0700 (PDT) Received: by overlord.e-gerbil.net (Postfix, from userid 1000) id F3BB115E4B; Wed, 29 May 2002 13:52:05 -0400 (EDT) Date: Wed, 29 May 2002 13:52:05 -0400 From: Richard A Steenbergen To: Andre Oppermann Cc: "Louis A. Mamakos" , Attila Nagy , Luigi Iannone , freebsd-net@FreeBSD.ORG Subject: Re: MPLS Message-ID: <20020529175205.GJ33611@overlord.e-gerbil.net> References: <3CF4A64A.EE220611@pipeline.ch> <200205291413.g4TEDLRG075458@whizzo.transsys.com> <3CF4E483.2510639@pipeline.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <3CF4E483.2510639@pipeline.ch> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, May 29, 2002 at 04:24:03PM +0200, Andre Oppermann wrote: > > > > > > It is true that JUNOS is more or less FreeBSD. But it's only the > > > control plane. All the switching and stack processing happens on > > > the line cards which have their own CPUs and OS. > >=20 > > There is no software involved in the forwarding plane, including > > the line cards, in the Juniper routers. There is another CPU in > > the box running an embedded system kernel, which does supervisory > > things, but that's also not involved in the forwarding operation. >=20 > If there is no kind of software involved on the forwarding plane > then I don't know how the control plane can communicate via ethernet > with the line cards... The internal communication in the router is > via ethernet. The FreeBSD based part runs on an i386 piece called the Routing Rngine, which connects to the "rest of the system" (SFM SSB SCB or FEC boards depending on the model) via FastE (fxp to be precise). The Routing Engine runs the routing protocols and CLI, with all those nice FreeBSD benefits like stability, protected process memory, extensive debugging tools, etc (things that other vendors software lacks :P). After all the routing information is taken in, and all the policy rules considered, a forwarding table is constructed and passed over the ethernet link to the rest of the system. =46rom there, the Internet Processor 2 ASIC (which DOES run microcode) uses the forwarding information as well as the firewall rules which have been passed to it, to look at the headers of every packet and come back with a destination interface (or discard). The linecards and FPCs take care of putting the packet into shared memory, and forwarding it. An elegant solution to the control and forwarding planes, combining the best of all worlds, if you ask me. > I agree with the ASIC hardware. But the BGP implementation smells > awfully like gated (Nexthop). Anyway, a BGP deamon isn't that hard > to write. As someone who has actually written a BGP implementation from scratch, let me be the first to tell you that you are full of shit. BGP is a very complex beast, and Juniper has spent a good amount of time making what is without a doubt the most powerful BGP implementation currently available. --=20 Richard A Steenbergen http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 29 11: 2:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [64.186.142.66]) by hub.freebsd.org (Postfix) with ESMTP id 6266337B415 for ; Wed, 29 May 2002 11:02:05 -0700 (PDT) Received: by overlord.e-gerbil.net (Postfix, from userid 1000) id 1561315E4A; Wed, 29 May 2002 14:02:05 -0400 (EDT) Date: Wed, 29 May 2002 14:02:05 -0400 From: Richard A Steenbergen To: Andre Oppermann Cc: "Louis A. Mamakos" , Attila Nagy , Luigi Iannone , freebsd-net@FreeBSD.ORG Subject: Re: MPLS Message-ID: <20020529180204.GK33611@overlord.e-gerbil.net> References: <3CF4A64A.EE220611@pipeline.ch> <200205291413.g4TEDLRG075458@whizzo.transsys.com> <3CF4E483.2510639@pipeline.ch> <200205291522.g4TFMdRG076033@whizzo.transsys.com> <3CF4FCFC.3D760508@pipeline.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CF4FCFC.3D760508@pipeline.ch> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, May 29, 2002 at 06:08:28PM +0200, Andre Oppermann wrote: > > It's clear to me that this is not based on the old 3.6 gated that is > have in ports. The Nexthop stuff is more advanced. Zebra also is very > reliable and I use it on many FreeBSD based routers here around. Agreed, > each of these things don't push more than 50Mbit/s. Zebra is about as stable as a trailer park IRC whore who didn't take her meds. It's fine for playing around, and maybe even for a small home PC router where BGP is completely or nearly extraneous, but it is NOT a core router's BGP implementation. :) > But that is basically a problem of the old BSD network stack / crappy > kernel routing (forwarding) table. Expect some nice work in this area in > the next few month. This has been on my todo list for a while, but I never have time. Basically just gut the current radix tree and fast-switch like route-cache system, and replace it with something optimized for fast insertions and deletions (and FIB building) but not longest prefix matching for the RIB, and a 4 level 8-bit mtrie (seems to work best for PC hardware) for the FIB. -- Richard A Steenbergen http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 29 11: 6:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95]) by hub.freebsd.org (Postfix) with SMTP id 80ECD37B403 for ; Wed, 29 May 2002 11:06:38 -0700 (PDT) Received: (qmail 18066 invoked by uid 1000); 29 May 2002 18:06:52 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 29 May 2002 18:06:52 -0000 Date: Wed, 29 May 2002 20:06:52 +0200 (CEST) From: Attila Nagy To: Andre Oppermann Cc: Luigi Iannone , Subject: Re: MPLS In-Reply-To: <3CF4A64A.EE220611@pipeline.ch> Message-ID: References: <3CF4A64A.EE220611@pipeline.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, > It is true that JUNOS is more or less FreeBSD. But it's only the control > plane. All the switching and stack processing happens on the line cards > which have their own CPUs and OS. You are wrong :) That FreeBSD has many things to do. But it doesn't really involved (in a direct way) in packet forwarding, that's true. Juniper did a great job with this router. Just take a look at T640. It's a beast and it is controlled by a FreeBSD box. Nice to see. BTW, I wouldn't call JUNOS a rewrite of FreeBSD. They just (re)implemented the needed functions and kept what was suitable in FreeBSD. AFAIK this wasn't much kernel space, but user space. (just take a quick look at the output of > show system processes on the system below l/p: guest/guest). telnet olive.labs.pulltheplug.com 22 Trying 209.9.44.210... Connected to 209-9-44-210.sdsl.cais.net. Escape character is '^]'. SSH-1.99-OpenSSH_2.3.0 Isn't that OpenSSH vulnerable to multiple root exploits? ;) --------[ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]------- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 29 11:13: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 8F82537B406 for ; Wed, 29 May 2002 11:12:59 -0700 (PDT) Received: (qmail 60323 invoked from network); 29 May 2002 18:12:40 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 29 May 2002 18:12:40 -0000 Message-ID: <3CF519E6.C649CA25@pipeline.ch> Date: Wed, 29 May 2002 20:11:50 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Richard A Steenbergen Cc: "Louis A. Mamakos" , Attila Nagy , Luigi Iannone , freebsd-net@FreeBSD.ORG Subject: Re: MPLS References: <3CF4A64A.EE220611@pipeline.ch> <200205291413.g4TEDLRG075458@whizzo.transsys.com> <3CF4E483.2510639@pipeline.ch> <20020529175205.GJ33611@overlord.e-gerbil.net> 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 Richard A Steenbergen wrote: > > On Wed, May 29, 2002 at 04:24:03PM +0200, Andre Oppermann wrote: > > If there is no kind of software involved on the forwarding plane > > then I don't know how the control plane can communicate via ethernet > > with the line cards... The internal communication in the router is > > via ethernet. > > The FreeBSD based part runs on an i386 piece called the Routing Rngine, > which connects to the "rest of the system" (SFM SSB SCB or FEC boards > depending on the model) via FastE (fxp to be precise). The Routing Engine > runs the routing protocols and CLI, with all those nice FreeBSD benefits > like stability, protected process memory, extensive debugging tools, etc > (things that other vendors software lacks :P). After all the routing > information is taken in, and all the policy rules considered, a forwarding > table is constructed and passed over the ethernet link to the rest of the > system. > > From there, the Internet Processor 2 ASIC (which DOES run microcode) uses > the forwarding information as well as the firewall rules which have been > passed to it, to look at the headers of every packet and come back with a > destination interface (or discard). The linecards and FPCs take care of > putting the packet into shared memory, and forwarding it. > > An elegant solution to the control and forwarding planes, combining the > best of all worlds, if you ask me. I agree. > > I agree with the ASIC hardware. But the BGP implementation smells > > awfully like gated (Nexthop). Anyway, a BGP deamon isn't that hard > > to write. > > As someone who has actually written a BGP implementation from scratch, let > me be the first to tell you that you are full of shit. BGP is a very Thank you. You are so cute today... > complex beast, and Juniper has spent a good amount of time making what is > without a doubt the most powerful BGP implementation currently available. Bwah... It lacks things like transparent-nexthop and transparent-as which is quite useful in Route Servers and such. Don't get me wrong. I don't say it's bad or instable or whatever but it's not perfect either. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 29 11:33: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id C3D8837B480 for ; Wed, 29 May 2002 11:32:33 -0700 (PDT) Received: (qmail 61120 invoked from network); 29 May 2002 18:32:14 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 29 May 2002 18:32:14 -0000 Message-ID: <3CF51E7C.E9A47960@pipeline.ch> Date: Wed, 29 May 2002 20:31:24 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Richard A Steenbergen Cc: "Louis A. Mamakos" , Attila Nagy , Luigi Iannone , freebsd-net@FreeBSD.ORG Subject: Re: MPLS References: <3CF4A64A.EE220611@pipeline.ch> <200205291413.g4TEDLRG075458@whizzo.transsys.com> <3CF4E483.2510639@pipeline.ch> <200205291522.g4TFMdRG076033@whizzo.transsys.com> <3CF4FCFC.3D760508@pipeline.ch> <20020529180204.GK33611@overlord.e-gerbil.net> 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 Richard A Steenbergen wrote: > > On Wed, May 29, 2002 at 06:08:28PM +0200, Andre Oppermann wrote: > > > > It's clear to me that this is not based on the old 3.6 gated that is > > have in ports. The Nexthop stuff is more advanced. Zebra also is very > > reliable and I use it on many FreeBSD based routers here around. Agreed, > > each of these things don't push more than 50Mbit/s. > > Zebra is about as stable as a trailer park IRC whore who didn't take her > meds. It's fine for playing around, and maybe even for a small home PC > router where BGP is completely or nearly extraneous, but it is NOT a core > router's BGP implementation. :) I don't know how many moons ago you had your last look at Zebra/BGP but it's perfectly stable and supports a very large number of peers without any serious scalability problems. Zebra/BGP is running here on two machines with 225 days of uptime and five full feeds each. And I've got one with 53 peers and 92 days uptime (reboot for upgrade) among others. This stuff is simply limited by the forwarding engine under it (which is a FreeBSD based PC router). I agree that some IRGP in the Zebra suite are not as advanced. > > But that is basically a problem of the old BSD network stack / crappy > > kernel routing (forwarding) table. Expect some nice work in this area in > > the next few month. > > This has been on my todo list for a while, but I never have time. > > Basically just gut the current radix tree and fast-switch like route-cache > system, and replace it with something optimized for fast insertions and > deletions (and FIB building) but not longest prefix matching for the RIB, > and a 4 level 8-bit mtrie (seems to work best for PC hardware) for the > FIB. Hehe... We've come to the same conclusion for the FIB. First I tried to rip out the current flow-based fast-forward code with a highly compact LC-Trie build from the kernels PATRICIA trie. If only a nexthop changes, adjust it in the LC-Trie. If a prefix disappears, mark it as NULL. If Prefix changes, mark it as lookup- in-main-table (slow). Either after so many changes or so many slow lookups rebuild the LC-Trie. Unfortunatly this concept is impossible to implement because [if]_output expects a pointer to a routetable entry. This would mean I had to up the refcount on too many nodes in the main trie from outside of it (so the walker can't find it). This blew up the whole idea and we decided to do it the right way. Unfortunatly the whole routing stuff in BSD is so cross-pointered that untangling it is a medium task in front of it. It made have sense 15 years ago to have pointers from the INPCBs directly to the route node and the if-structures doing the same and vice versa, but today it's simply messy. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 29 11: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 4920E37B40F for ; Wed, 29 May 2002 11:41:20 -0700 (PDT) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g4TIfIi22905; Wed, 29 May 2002 11:41:18 -0700 (PDT) (envelope-from rizzo) Date: Wed, 29 May 2002 11:41:18 -0700 From: "'Luigi Rizzo'" To: "Albuquerque, Marcelo M" Cc: "'freebsd-net@freeBSD.ORG'" Subject: Re: Does "xmit" work with ipfw dummynet? Message-ID: <20020529114118.A22709@iguana.icir.org> 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 marcelo.m.albuquerque@boeing.com on Wed, May 29, 2002 at 09:35:12AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, May 29, 2002 at 09:35:12AM -0700, Albuquerque, Marcelo M wrote: > Thanks Luigi. > > > xmit cannot match on bridged packets > > Is it a hard problem to make xmit compatible with bridged packets or is it in the place the ipfw filter are in the bridging code, the info on the output interface is still not available, this is why xmit does not match. > just that no one had the need yet to implement the changes? Is there any way > around this limitation that would allow us to achive the same goal? which is what ? you do not want to bridge between fxp0 and fxp1 ? luigi > > xmit cannot match on bridged packets > > luigi > > > > > Here is the setup: > > > > ___________________ > > | | > > 192.168.1.1 --- |FreeBSD 4.5 Bridge | --- 192.168.1.2 > > |___________________| > > | > > | > > 192.168.1.3 > > > > > > This works: > > ipfw add 100 deny ip from any to any in recv fxp0 > > > > This doesn't: > > ipfw add 100 deny ip from any to any out xmit fxp1 > > > > What I really want, but fear is not supported, is: > > ipfw add 100 deny ip from any to any out recv fxp0 xmit fxp1 > > > > That is, I want to block traffic coming in from fxp0 and going out > > fxp1, in bridged mode. > > > > Anyone know if this is possible? > > > > > > 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 May 29 12:17:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from quemadura.shockwave.org (quemadura.shockwave.org [63.199.168.250]) by hub.freebsd.org (Postfix) with ESMTP id 4D72B37B40D for ; Wed, 29 May 2002 12:17:02 -0700 (PDT) Received: from trianon (trianon.shockwave.org [192.111.107.43]) by quemadura.shockwave.org (8.12.3/8.12.3/Debian-9) with SMTP id g4TJGuA4019750; Wed, 29 May 2002 12:16:57 -0700 Message-ID: <008f01c20745$65478900$2b6b6fc0@shockwave.org> From: "Paul Traina" To: "Andre Oppermann" , "Richard A Steenbergen" Cc: "Louis A. Mamakos" , "Attila Nagy" , "Luigi Iannone" , References: <3CF4A64A.EE220611@pipeline.ch> <200205291413.g4TEDLRG075458@whizzo.transsys.com> <3CF4E483.2510639@pipeline.ch> <20020529175205.GJ33611@overlord.e-gerbil.net> <3CF519E6.C649CA25@pipeline.ch> Subject: Re: MPLS Date: Wed, 29 May 2002 12:16:50 -0700 Organization: Traina & Assocaties, LLC MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Bwah... It lacks things like transparent-nexthop and transparent-as > which is quite useful in Route Servers and such. We don't add features to code unless people are willing to pay for them and use them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 29 12:50:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by hub.freebsd.org (Postfix) with ESMTP id 3328B37B416 for ; Wed, 29 May 2002 12:49:50 -0700 (PDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA26581; Wed, 29 May 2002 12:47:24 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id OAA28821; Wed, 29 May 2002 14:49:47 -0500 (CDT) Received: from xch-nwbh-02.nw.nos.boeing.com (xch-nwbh-02.nw.nos.boeing.com [192.54.12.28]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g4TJnkH28561; Wed, 29 May 2002 12:49:46 -0700 (PDT) Received: by xch-nwbh-02.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 May 2002 12:49:46 -0700 Message-ID: From: "Albuquerque, Marcelo M" To: "'Luigi Rizzo'" Cc: "'freebsd-net@freeBSD.ORG'" Subject: RE: Does "xmit" work with ipfw dummynet? Date: Wed, 29 May 2002 12:49:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > On Wed, May 29, 2002 at 09:35:12AM -0700, Albuquerque, > Marcelo M wrote: > > Thanks Luigi. > > > > > xmit cannot match on bridged packets > > > > Is it a hard problem to make xmit compatible with bridged > packets or is it > > in the place the ipfw filter are in the bridging code, the info > on the output interface is still not available, this is why xmit > does not match. Is there a place downstream where we could insert a check and match the output interface? > > > just that no one had the need yet to implement the changes? > Is there any way > > around this limitation that would allow us to achive the same goal? > > which is what ? you do not want to bridge between fxp0 and fxp1 ? We do want to bridge packets from fxp0 to fxp1 and at the same time have the firewall filter match both incoming and outgoing interfaces. > > luigi > > > > > xmit cannot match on bridged packets > > > > luigi > > > > > > > > Here is the setup: > > > > > > ___________________ > > > | | > > > 192.168.1.1 --- |FreeBSD 4.5 Bridge | --- 192.168.1.2 > > > |___________________| > > > | > > > | > > > 192.168.1.3 > > > > > > > > > This works: > > > ipfw add 100 deny ip from any to any in recv fxp0 > > > > > > This doesn't: > > > ipfw add 100 deny ip from any to any out xmit fxp1 > > > > > > What I really want, but fear is not supported, is: > > > ipfw add 100 deny ip from any to any out recv fxp0 xmit fxp1 > > > > > > That is, I want to block traffic coming in from fxp0 and going out > > > fxp1, in bridged mode. > > > > > > Anyone know if this is possible? > > > > > > > > > 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 May 29 15:40:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from stono.cs.cofc.edu (stono.cs.cofc.edu [153.9.17.3]) by hub.freebsd.org (Postfix) with ESMTP id C934737B42F for ; Wed, 29 May 2002 15:40:16 -0700 (PDT) Received: from [153.9.17.27] (burton.cs.cofc.edu [153.9.17.27]) by stono.cs.cofc.edu (8.11.6/8.11.6) with ESMTP id g4TMb7G17396 for ; Wed, 29 May 2002 18:37:11 -0400 Mime-Version: 1.0 X-Sender: jimmy@stono.cs.cofc.edu Message-Id: Date: Wed, 29 May 2002 18:42:41 -0400 To: freebsd-net@freebsd.org From: "James B. Wilkinson" Subject: TCP/IP Illustrated, vol 2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This book seems to be essentially the annotated source for the BSD 4.4 networking code. Can anybody tell me whether it is still current enough to use with today's FreeBSD source in a networking course? Thanks -- ------------------------------------------------------------- Jimmy Wilkinson | Perfesser of Computer Science jimmy@cs.CofC.edu | The College of Charleston (843) 953-8160 | Charleston SC 29424 If there is one word to describe me, that word would have to be "profectionist". Any form of incompitence is an athema to me. Metathesis??? Don't ax me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 29 15:49: 7 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 E47B737B404 for ; Wed, 29 May 2002 15:49:02 -0700 (PDT) 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 g4TMmvC03937; Wed, 29 May 2002 15:48:57 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from neville-neil.com ([209.157.133.226]) by mail.meer.net (8.12.2/8.12.1/meer) with ESMTP id g4TMn29h007285; Wed, 29 May 2002 15:49:02 -0700 (PDT) Message-Id: <200205292249.g4TMn29h007285@mail.meer.net> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "James B. Wilkinson" Cc: freebsd-net@FreeBSD.ORG Subject: Re: TCP/IP Illustrated, vol 2 In-Reply-To: Message from "James B. Wilkinson" of "Wed, 29 May 2002 18:42:41 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 May 2002 15:49:02 -0700 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 book seems to be essentially the annotated source for the BSD > 4.4 networking code. Can anybody tell me whether it is still current > enough to use with today's FreeBSD source in a networking course? > A lot has changed. The theory is often similar but a lot of details have changed. I recommend a close reading of any source you're going to use in class. cvs on a mirrored repository is your friend. Later, Geoprge -- George V. Neville-Neil gnn@neville-neil.com Neville-Neil Consulting www.neville-neil.com "I learn only to be contented." inscription at Ryoan-ji in Kyoto, Japan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 29 16:34:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [64.186.142.66]) by hub.freebsd.org (Postfix) with ESMTP id 9181E37B408 for ; Wed, 29 May 2002 16:34:21 -0700 (PDT) Received: by overlord.e-gerbil.net (Postfix, from userid 1000) id 126A815E4A; Wed, 29 May 2002 19:34:12 -0400 (EDT) Date: Wed, 29 May 2002 19:34:11 -0400 From: Richard A Steenbergen To: Andre Oppermann Cc: "Louis A. Mamakos" , Attila Nagy , Luigi Iannone , freebsd-net@FreeBSD.ORG Subject: Re: MPLS Message-ID: <20020529233411.GO33611@overlord.e-gerbil.net> References: <3CF4A64A.EE220611@pipeline.ch> <200205291413.g4TEDLRG075458@whizzo.transsys.com> <3CF4E483.2510639@pipeline.ch> <200205291522.g4TFMdRG076033@whizzo.transsys.com> <3CF4FCFC.3D760508@pipeline.ch> <20020529180204.GK33611@overlord.e-gerbil.net> <3CF51E7C.E9A47960@pipeline.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CF51E7C.E9A47960@pipeline.ch> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, May 29, 2002 at 08:31:24PM +0200, Andre Oppermann wrote: > > Basically just gut the current radix tree and fast-switch like route-cache > > system, and replace it with something optimized for fast insertions and > > deletions (and FIB building) but not longest prefix matching for the RIB, > > and a 4 level 8-bit mtrie (seems to work best for PC hardware) for the > > FIB. > > Hehe... We've come to the same conclusion for the FIB. > > First I tried to rip out the current flow-based fast-forward code Flow has its benefits, such as netflow export, and maybe even at some point it could be tied into ipfw to improve performance... I'd like to see it stay around as a route-cache method, but probably not in its current form. > with a highly compact LC-Trie build from the kernels PATRICIA trie. I've always prefered mtries myself, very simple... > If only a nexthop changes, adjust it in the LC-Trie. If a prefix > disappears, mark it as NULL. If Prefix changes, mark it as lookup- > in-main-table (slow). Either after so many changes or so many slow > lookups rebuild the LC-Trie. I'd suggest a rebuild after a prefix change, with a limit of x number of rebuilds per y time to prevent it from getting out of control. Better to continue forwarding to an old destination for a split second after a routing change then to be kicking packets up to a slow path. This lets you get rid of the patricia trie completely, since it will never be doing longest prefix matches, and make a RIB that is entirely optimized for insertions, deletions, and FIB builds. > Unfortunatly the whole routing stuff in BSD is so cross-pointered that > untangling it is a medium task in front of it. It made have sense 15 > years ago to have pointers from the INPCBs directly to the route node > and the if-structures doing the same and vice versa, but today it's > simply messy. Indeed. -- Richard A Steenbergen http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 29 18:51:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail0.yrp.nttdocomo.co.jp (mail0.yrp.nttdocomo.co.jp [202.245.184.18]) by hub.freebsd.org (Postfix) with ESMTP id 1F4DA37B412 for ; Wed, 29 May 2002 18:50:48 -0700 (PDT) Received: from mml.yrp.nttdocomo.co.jp (mml.yrp.nttdocomo.co.jp [172.21.48.50]) by mail0.yrp.nttdocomo.co.jp (8.11.6/YRPHUB0-8820020412) with ESMTP id g4U1okD19265 for ; Thu, 30 May 2002 10:50:46 +0900 (JST) Received: from OSUGASYSWKS (osuga-syswks.mml-ad.yrp.nttdocomo.co.jp [172.21.51.242]) by mml.yrp.nttdocomo.co.jp (8.9.2/3.7W-mml-990617) with SMTP id KAA06766 for ; Thu, 30 May 2002 10:50:45 +0900 (JST) Message-ID: <004301c2077c$6a373fa0$f23315ac@mmlad.yrp.nttdocomo.co.jp> From: "Daikichi Osuga" To: References: Subject: Re: TCP/IP Illustrated, vol 2 Date: Thu, 30 May 2002 10:50:45 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I think these materials are helpful to you. Performance Problems in BSD4.4 TCP http://www.cs.arizona.edu/xkernel/people/brakmo-papers/abstracts.html New Callout and Timer Facilities for NetBSD http://www.cs.berkeley.edu/~amc/research/timer/ These modifications are applyed to FreeBSD. -- Daikichi Osuga ----- Original Message ----- From: "James B. Wilkinson" To: Sent: Thursday, May 30, 2002 7:42 AM Subject: TCP/IP Illustrated, vol 2 > This book seems to be essentially the annotated source for the BSD > 4.4 networking code. Can anybody tell me whether it is still current > enough to use with today's FreeBSD source in a networking course? > > Thanks > -- > > ------------------------------------------------------------- > Jimmy Wilkinson | Perfesser of Computer Science > jimmy@cs.CofC.edu | The College of Charleston > (843) 953-8160 | Charleston SC 29424 > > If there is one word to describe me, > that word would have to be "profectionist". > Any form of incompitence is an athema to me. > Metathesis??? Don't ax me. > > 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 May 29 19:29:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from nabechan.org (nabechan.org [210.228.4.131]) by hub.freebsd.org (Postfix) with ESMTP id 0472137B401 for ; Wed, 29 May 2002 19:29:55 -0700 (PDT) Received: from x20.i.nabechan.org (localhost [::1]) by nabechan.org (3.7W-nabechan.org-02012315) id LAA23204; Thu, 30 May 2002 11:29:29 +0900 (JST) Date: Thu, 30 May 2002 11:29:25 +0900 Message-ID: <87ofeyxta2.wl@nabechan.org> From: Shingo WATANABE / =?ISO-2022-JP?B?GyRCRU9KVRsoQiAbJEI/LThjGyhC?= To: bra@fsn.hu Cc: oppermann@pipeline.ch, Luigi.Iannone@lip6.fr, freebsd-net@FreeBSD.org Subject: Re: MPLS In-Reply-To: References: <3CF4A555.41CA27E4@pipeline.ch> User-Agent: Wanderlust/2.9.9 (Unchained Melody) XEmacs/21.1 (Cuyahoga Valley) Organization: nabechan.org X-Callsign: JG8OOM/1 X-OS: NetBSD 1.6A X-ICQ-UIN: 30482441 X-Wednesday: =?ISO-2022-JP?B?GyRCJEYkJCQmJCskTRsoQiAbJEJGI0I8JDUkcxsoQiA=?= =?ISO-2022-JP?B?GyRCJEEkZyRDJEgkTRsoQiAbJEIlRiVsJVM9UDJhJC4kRyQ5JGgbKEIJ?= =?ISO-2022-JP?B?GyRCIVY3Y0F2ISobKEIyNBskQjt+NFZCZ0B0TU4kLyRzPCM8JiROGyhC?= =?ISO-2022-JP?B?GyRCTjkhVyRoJGobKEI=?= X-Weather: =?ISO-2022-JP?B?GyRCTEBGfCROQFA8bTZ1Q044ZTtWQ09KfSRPRl4bKEI=?= =?ISO-2022-JP?B?GyRCO34hOUAyJEckORsoQg==?= MIME-Version: 1.0 (generated by WEMIKO 1.14.1 - =?ISO-2022-JP?B?Ig==?= =?ISO-2022-JP?B?GyRCNl9KXExTQ24bKEIi?=) Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello At Wed, 29 May 2002 19:52:26 +0200 (CEST), Attila Nagy wrote: > > > I developped a basic implementation of MPLS over Ethernet in the FreeBSD > > > Environment! If someone is interested in my code just e.mail me! > > I'm interested in it. I'm interested in the implementation of MPLS in the FreeBSD. > BTW, there is a Linux-based effort to make it MPLS-aware -> > http://sourceforge.net/projects/mpls-linux/ There is the implementation of MPLS on the NetBSD. The AYAME Project http://www.ayame.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 30 2:48:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id EE70C37B497 for ; Thu, 30 May 2002 02:47:31 -0700 (PDT) Received: (qmail 567 invoked from network); 30 May 2002 09:47:11 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 30 May 2002 09:47:11 -0000 Message-ID: <3CF5F4ED.369BCE83@pipeline.ch> Date: Thu, 30 May 2002 11:46:21 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Richard A Steenbergen Cc: "Louis A. Mamakos" , Attila Nagy , Luigi Iannone , freebsd-net@FreeBSD.ORG Subject: Re: MPLS References: <3CF4A64A.EE220611@pipeline.ch> <200205291413.g4TEDLRG075458@whizzo.transsys.com> <3CF4E483.2510639@pipeline.ch> <200205291522.g4TFMdRG076033@whizzo.transsys.com> <3CF4FCFC.3D760508@pipeline.ch> <20020529180204.GK33611@overlord.e-gerbil.net> <3CF51E7C.E9A47960@pipeline.ch> <20020529233411.GO33611@overlord.e-gerbil.net> 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 Richard A Steenbergen wrote: > > On Wed, May 29, 2002 at 08:31:24PM +0200, Andre Oppermann wrote: > > > Basically just gut the current radix tree and fast-switch like route-cache > > > system, and replace it with something optimized for fast insertions and > > > deletions (and FIB building) but not longest prefix matching for the RIB, > > > and a 4 level 8-bit mtrie (seems to work best for PC hardware) for the > > > FIB. > > > > Hehe... We've come to the same conclusion for the FIB. > > > > First I tried to rip out the current flow-based fast-forward code > > Flow has its benefits, such as netflow export, and maybe even at some > point it could be tied into ipfw to improve performance... I'd like to see > it stay around as a route-cache method, but probably not in its current > form. I don't know if you have looked at the flow in code in FreeBSD but it's nowhere near what you'd expect from something that should do Netflow. IPFW has already something like that, it's called dynamic rules for TCP streams. On the other hand, to get performace you'd have to rewrite ipfw by a great deal or switch to OpenBSDs pf. > > with a highly compact LC-Trie build from the kernels PATRICIA trie. > > I've always prefered mtries myself, very simple... The theorie about the LC-Trie is that it'll fit into L2 cache for the entire default-free forwarding table. > > If only a nexthop changes, adjust it in the LC-Trie. If a prefix > > disappears, mark it as NULL. If Prefix changes, mark it as lookup- > > in-main-table (slow). Either after so many changes or so many slow > > lookups rebuild the LC-Trie. > > I'd suggest a rebuild after a prefix change, with a limit of x number of > rebuilds per y time to prevent it from getting out of control. Better to > continue forwarding to an old destination for a split second after a > routing change then to be kicking packets up to a slow path. > > This lets you get rid of the patricia trie completely, since it will never > be doing longest prefix matches, and make a RIB that is entirely optimized > for insertions, deletions, and FIB builds. This might work on a decicated router system. FreeBSD is being used for servers as well. Also to not to change the userland/kernel interface wrt routing we have to keep all prefixes in the kernel RIB. This means we have to be able to do longest prefix matching. Anyway, I'm confident we'll come up with something that is well balanced and much faster and more memory conserving than what we have today with the patricia trie. (A default-free kernel RIB consumes approx. 30MB of kernel memory in 4-STABLE/5-CURRENT at the moment). -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 30 3:42:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from proton.hexanet.fr (proton.hexanet.fr [81.23.32.33]) by hub.freebsd.org (Postfix) with ESMTP id C73AB37B403 for ; Thu, 30 May 2002 03:42:01 -0700 (PDT) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.12.3/8.12.3) with SMTP id g4UAfx0A001457; Thu, 30 May 2002 12:41:59 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Thu, 30 May 2002 12:41:59 +0200 From: Christophe Prevotaux To: Luigi Iannone Cc: freebsd-net@FreeBSD.ORG Subject: Re: MPLS Message-Id: <20020530124159.0400567c.c.prevotaux@hexanet.fr> In-Reply-To: References: Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-portbld-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 I am also very interested by this , as it has been mentioned already it would be nice if the Ayame project and your work could be somehow merged if necessary or at least some kind of a collaborative work. On Wed, 29 May 2002 09:18:07 +0200 (MEST) Luigi Iannone wrote: > Hi! > I developped a basic implementation of MPLS over Ethernet in the FreeBSD > Environment! If someone is interested in my code just e.mail me! > Bye > Luigi Iannone > > ----------------------------------------------------------------> > Luigi Iannone -- =============================================================== 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 61 77 72 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 30 5:44:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 17BF637B401; Thu, 30 May 2002 05:44:06 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA15587; Thu, 30 May 2002 22:43:59 +1000 Date: Thu, 30 May 2002 22:47:25 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Alfred Perlstein Cc: net@FreeBSD.ORG, Subject: Re: netgraph warnings In-Reply-To: <20020529150129.GQ17045@elvis.mu.org> Message-ID: <20020530223238.G28714-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 29 May 2002, Alfred Perlstein wrote: > Something bizzaro with the 'struct ng_parse_struct_info' declarations, > please suggest or make a fix: > ... > cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding -Werror ../../../netgraph/ng_base.c > cc1: warnings being treated as errors > ../../../netgraph/ng_base.c:365: warning: excess elements in array initializer > ../../../netgraph/ng_base.c:365: warning: (near initialization for `ng_mkpeer_type_info.fields') ... This is caused by the zero-sized array in struct ng_parse_struct_info. Zero-sized arrays used to just break compiling with C compilers (C90), but now even gcc objects to initializing them. I had one of these in my own code ( *blush* ), and eventually fixed found a portable fix using an unnamed bitfield. The bitfield hack doesn't seem to apply here though, since netgraph seems to really want to initialize the struct. BTW, does anyone have any good ideas about how to fix HIDENAME()? HIDENAME(mcount) doesn't work in the ELF case, because concatenating `.' and `mcount' doesn't give a preprocessing token. This breaks LINT. I only have bad ideas about it. It is fundamental that HIDENAME() may give non-C identifiers. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 30 8: 7:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [64.186.142.66]) by hub.freebsd.org (Postfix) with ESMTP id 3408337B414 for ; Thu, 30 May 2002 08:06:18 -0700 (PDT) Received: by overlord.e-gerbil.net (Postfix, from userid 1000) id 3E09915E4E; Thu, 30 May 2002 11:06:12 -0400 (EDT) Date: Thu, 30 May 2002 11:06:12 -0400 From: Richard A Steenbergen To: Andre Oppermann Cc: "Louis A. Mamakos" , Attila Nagy , Luigi Iannone , freebsd-net@FreeBSD.ORG Subject: Re: MPLS Message-ID: <20020530150612.GP33611@overlord.e-gerbil.net> References: <3CF4A64A.EE220611@pipeline.ch> <200205291413.g4TEDLRG075458@whizzo.transsys.com> <3CF4E483.2510639@pipeline.ch> <200205291522.g4TFMdRG076033@whizzo.transsys.com> <3CF4FCFC.3D760508@pipeline.ch> <20020529180204.GK33611@overlord.e-gerbil.net> <3CF51E7C.E9A47960@pipeline.ch> <20020529233411.GO33611@overlord.e-gerbil.net> <3CF5F4ED.369BCE83@pipeline.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CF5F4ED.369BCE83@pipeline.ch> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, May 30, 2002 at 11:46:21AM +0200, Andre Oppermann wrote: > > Flow has its benefits, such as netflow export, and maybe even at some > > point it could be tied into ipfw to improve performance... I'd like to see > > it stay around as a route-cache method, but probably not in its current > > form. > > I don't know if you have looked at the flow in code in FreeBSD but > it's nowhere near what you'd expect from something that should do > Netflow. IPFW has already something like that, it's called dynamic > rules for TCP streams. On the other hand, to get performace you'd > have to rewrite ipfw by a great deal or switch to OpenBSDs pf. Yes I know, thats why I said "probably not in its current form". Just suggesting that instead of gutting it completely, it be updated to something a little more useful. This is pretty trivial, I did such a while back but I lost the patch in a drive failure. :) > The theorie about the LC-Trie is that it'll fit into L2 cache for the > entire default-free forwarding table. Versus the reality of doing bit operations instead of byte operations. In my tests, the mtrie was always faster, even on a celeron with a piddly L2 cache. > This might work on a decicated router system. FreeBSD is being used > for servers as well. Please explain how that would not work for servers? > Also to not to change the userland/kernel interface wrt routing we have > to keep all prefixes in the kernel RIB. This means we have to be able to > do longest prefix matching. This is a non sequitur. All routes will be available through the kernel RIB, but for exact matches only. When is a longest prefix match needed there? > Anyway, I'm confident we'll come up with something that is well > balanced and much faster and more memory conserving than what we > have today with the patricia trie. (A default-free kernel RIB consumes > approx. 30MB of kernel memory in 4-STABLE/5-CURRENT at the moment). Not to mention the outrageous amounts of memory consumed by the caching mechanism. Oh, and it should be able to support multiple nexthops per prefix, and load balance across them. I think even Linux has this support now, and an actual FIB. -- Richard A Steenbergen http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 30 8:22:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id C806137B406 for ; Thu, 30 May 2002 08:22:28 -0700 (PDT) Received: (qmail 34905 invoked from network); 30 May 2002 15:22:08 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 30 May 2002 15:22:08 -0000 Message-ID: <3CF6436D.ADA51D7F@pipeline.ch> Date: Thu, 30 May 2002 17:21:17 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Richard A Steenbergen Cc: "Louis A. Mamakos" , Attila Nagy , Luigi Iannone , freebsd-net@FreeBSD.ORG Subject: Re: MPLS References: <3CF4A64A.EE220611@pipeline.ch> <200205291413.g4TEDLRG075458@whizzo.transsys.com> <3CF4E483.2510639@pipeline.ch> <200205291522.g4TFMdRG076033@whizzo.transsys.com> <3CF4FCFC.3D760508@pipeline.ch> <20020529180204.GK33611@overlord.e-gerbil.net> <3CF51E7C.E9A47960@pipeline.ch> <20020529233411.GO33611@overlord.e-gerbil.net> <3CF5F4ED.369BCE83@pipeline.ch> <20020530150612.GP33611@overlord.e-gerbil.net> 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 Richard A Steenbergen wrote: > On Thu, May 30, 2002 at 11:46:21AM +0200, Andre Oppermann wrote: > > The theorie about the LC-Trie is that it'll fit into L2 cache for the > > entire default-free forwarding table. > > Versus the reality of doing bit operations instead of byte operations. In > my tests, the mtrie was always faster, even on a celeron with a piddly L2 > cache. We'll find out. We're designing a framework into which different kinds of tables can be implemented. We can move on to profiling then. > > This might work on a decicated router system. FreeBSD is being used > > for servers as well. > > Please explain how that would not work for servers? It would work but not optimal because the packet flow is different for locally terminated/generated packets. > > Also to not to change the userland/kernel interface wrt routing we have > > to keep all prefixes in the kernel RIB. This means we have to be able to > > do longest prefix matching. > > This is a non sequitur. All routes will be available through the kernel > RIB, but for exact matches only. When is a longest prefix match needed > there? When the routing daemon instructs us to remove the prefix 10.0.0.0/8 when we also have 10.0.0.0/9 and 10.128.0.0/9. > > Anyway, I'm confident we'll come up with something that is well > > balanced and much faster and more memory conserving than what we > > have today with the patricia trie. (A default-free kernel RIB consumes > > approx. 30MB of kernel memory in 4-STABLE/5-CURRENT at the moment). > > Not to mention the outrageous amounts of memory consumed by the caching > mechanism. Where? Do you mean rt_metrics? > Oh, and it should be able to support multiple nexthops per prefix, and > load balance across them. I think even Linux has this support now, and an > actual FIB. Yes, and policy routing... -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 30 10: 0: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 1830237B403 for ; Thu, 30 May 2002 09:59:48 -0700 (PDT) Received: (qmail 40396 invoked from network); 30 May 2002 16:59:27 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 30 May 2002 16:59:27 -0000 Message-ID: <3CF65A3C.915493B8@pipeline.ch> Date: Thu, 30 May 2002 18:58:37 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Cc: freebsd-stable@freebsd.org Subject: FreeBSD kernel routing table, need statistics, please install this patch Content-Type: multipart/mixed; boundary="------------FF908FDE6605971918FB41DB" Sender: owner-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. --------------FF908FDE6605971918FB41DB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, while working on a design overhaul of the kernel routing table I was inspecting the rt_metrics stuff a little bit closer. Then I checked with some busier web servers to see how much effect the rt_metric caching actually has. The result was not very clear. Some conntctions never got cached. The attached patch collects some statistics about the usage of the rt_metrics on a system. Specifically it counts how many time it a new tcp session has been established, how many times of those it found useful cached rt_metrics and then how many times it updated those metrics. The counters look like this (on a freshly booted system): # sysctl -a | grep tcp.rmx net.inet.tcp.rmxcachelookup: 3 net.inet.tcp.rmxcachehit: 1 net.inet.tcp.rmxcacheupdate: 2 net.inet.tcp.rmxcachenoupdate: 0 Please apply the attached patch (against 4-STABLE) and after a couple of hours/days please send me the output of: # uname -a # sysctl -a | grep tcp.rmx # netstat -m # netstat -ran | wc -l # decription main usage of your system (webserver/workstation/whatever) I don't want to nuke it but I'd like to see how much it helps overall. Then, because it's TCP specific, I'd like to move it out of the main routing table (only MTU remains) and transform it into a hash table. The rt_metrics are host specific so they only ever got used on host routes and are wasting an enormous amount of space in the main routing table. Also the strategy of the rt_metrics caching is probably inapropriate for todays world with many web servers. The problem is the rt_metrics only get updated when a tcp session to/from that host closes and a sufficient number of packets have been exchanged to make a mostly accurate messurement of those parameters. Unfortunatly in todays world the webbrowsers open a number of connections in very rapid succession so there is no chance to have any cached values for the connections after the first if not one of them closed already. The benefit is only being seen when the user loads the next page and opens new tcp seesions. Even that is being migitated by HTTP/1.1 keepalive and pipelining since sessions are not closed anymore. A possible solution is to update the rt_cache for the first time after a sufficient number of packets have been exchanged to make a mostly accurate measurement. And then update it after any n packets thereafter. The here collected statistics and numbers will greatly help to determin the best way how to adjust the rt_metrics to be most effective. The patch applies against /usr/src/sys/netinet/tcp_[input.c|subr.c]. "Profile, don't speculate" Many thanks for your cooperation! -- Andre --------------FF908FDE6605971918FB41DB Content-Type: text/plain; charset=us-ascii; name="tcp_input.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tcp_input.c.patch" --- tcp_input.c Sun Apr 28 07:40:26 2002 +++ tcp_input.c.new Thu May 30 18:18:20 2002 @@ -31,7 +31,7 @@ * SUCH DAMAGE. * * @(#)tcp_input.c 8.12 (Berkeley) 5/24/95 - * $FreeBSD: src/sys/netinet/tcp_input.c,v 1.107.2.23 2002/04/28 05:40:26 suz Exp $ + * $FreeBSD: src/sys/netinet/tcp_input.c,v 1.107.2.23 2002/05/30 16:12:00 andre Exp $ */ #include "opt_ipfw.h" /* for ipfw_fwd */ @@ -126,6 +126,16 @@ &drop_synfin, 0, "Drop TCP packets with SYN+FIN set"); #endif + +int rmxcachelookup = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, rmxcachelookup, + CTLFLAG_RD, &rmxcachelookup, 0, "RMX cache lookups"); + +int rmxcachehit = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, rmxcachehit, + CTLFLAG_RD, &rmxcachehit, 0, "RMX cache hits"); + + struct inpcbhead tcb; #define tcb6 tcb /* for KAME src sync over BSD*'s */ struct inpcbinfo tcbinfo; @@ -2521,7 +2531,13 @@ * or rttvar. Convert from the route-table units * to scaled multiples of the slow timeout timer. */ + + ++rmxcachelookup; + if (tp->t_srtt == 0 && (rtt = rt->rt_rmx.rmx_rtt)) { + + ++rmxcachehit; + /* * XXX the lock bit for RTT indicates that the value * is also a minimum value; this is subject to time. --------------FF908FDE6605971918FB41DB Content-Type: text/plain; charset=us-ascii; name="tcp_subr.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tcp_subr.c.patch" --- tcp_subr.c Sun Apr 14 06:02:30 2002 +++ tcp_subr.c.new Thu May 30 18:19:12 2002 @@ -31,7 +31,7 @@ * SUCH DAMAGE. * * @(#)tcp_subr.c 8.2 (Berkeley) 5/24/95 - * $FreeBSD: src/sys/netinet/tcp_subr.c,v 1.73.2.25 2002/04/14 04:02:30 silby Exp $ + * $FreeBSD: src/sys/netinet/tcp_subr.c,v 1.73.2.25 2002/05/30 16:12:00 andre Exp $ */ #include "opt_compat.h" @@ -144,6 +144,16 @@ SYSCTL_INT(_net_inet_tcp, OID_AUTO, isn_reseed_interval, CTLFLAG_RW, &tcp_isn_reseed_interval, 0, "Seconds between reseeding of ISN secret"); + +int rmxcacheupdate = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, rmxcacheupdate, + CTLFLAG_RD, &rmxcacheupdate, 0, "RMX cache update"); + +int rmxcachenoupdate = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, rmxcachenoupdate, + CTLFLAG_RD, &rmxcachenoupdate, 0, "RMX cache no update"); + + static void tcp_cleartaocache __P((void)); static void tcp_notify __P((struct inpcb *, int)); @@ -638,6 +648,8 @@ == INADDR_ANY) goto no_valid_rt; + ++rmxcacheupdate; + if ((rt->rt_rmx.rmx_locks & RTV_RTT) == 0) { i = tp->t_srtt * (RTM_RTTUNIT / (hz * TCP_RTT_SCALE)); @@ -710,7 +722,9 @@ rt->rt_rmx.rmx_ssthresh = i; tcpstat.tcps_cachedssthresh++; } - } + } else + ++rmxcachenoupdate; + no_valid_rt: /* free the reassembly queue, if any */ while((q = LIST_FIRST(&tp->t_segq)) != NULL) { --------------FF908FDE6605971918FB41DB-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 30 16:36:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 608F037B407 for ; Thu, 30 May 2002 16:36:48 -0700 (PDT) Received: (qmail 53357 invoked from network); 30 May 2002 23:36:27 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 30 May 2002 23:36:27 -0000 Message-ID: <3CF6B748.E8CA7FC6@pipeline.ch> Date: Fri, 31 May 2002 01:35:37 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Bug in net/route.[ch] with rmx_pksent while cloning Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi all, there is a bug in sys/route.[ch] with the rmx_pksent statistics (which counts how many times the route has been used to forward a ip packet). The bug is pretty simply: When cloning an rtentry in rtrequest1() the metrics get copied one to one. Unfortunatly also the rmx_pksent sta- tistic is being copied as well. This is wrong as we want to start from zero instead of an arbitrary high number. The solution is to zero this variable in the freshly copied rtmetrics. The output of netstat -ran looks quite weird without the fix: Destination Gateway Flags Refs Use Netif Expire default 195.134.128.33 UGSc 54 77721 fxp0 24.92.226.13 195.134.128.33 UGHW 1 77578 fxp0 Here 24.92.226.13 is a fresh cloned route with already 77578 packets sent to!? No, not at all. It simply inherited this number minus a hand full of packets from the default route. This bug sneaked in when rt_use (which used to be in the rtentry itself, not in the metrics) was defined to be rt_rmx.rmx_pksent (which is in the metrics). The bug in net/route.h is different. In struct rt_msghdr rtm_use is defined as int whereas in reality it is a u_long. In net/rtsock.c then we simply assign rt->rt_use to rtm_use which converts us from u_long down to int. The solution would be to make rtm_use a u_long too but that breaks binary compatibility in -STABLE and the RTM_VERSION has to be bumped. Even in Stevens Vol.2 this bug is present. I don't know how much harm this does (probably none). On the other hand I fail to see any reason why rt_msghdr needs to havethe rtm_use information at all. So it could be removed as well (plus RTM_VERSION bump). The next bug (but somewhat unrelated) happens to be in usr.bin/netstat/ route.c where the rt_use information is being printed. This is not the rt_use from the rt_msghdr but the rmx_pksent counter. Netstat prints it as %8ld when %8lu would be really correct. The solution is to change it to %8lu. Diffs against 4-STABLE attached. Should apply to -CURRENT directly or with some fuzz. Silby, Bosko or Luigi, could you have a look at this? -- Andre --- sys/net/route.c.old Fri May 31 00:49:43 2002 +++ sys/net/route.c Fri May 31 00:51:49 2002 @@ -740,6 +740,7 @@ */ if (req == RTM_RESOLVE) { rt->rt_rmx = (*ret_nrt)->rt_rmx; /* copy metrics */ + rt->rt_rmx.rmx_pksent = 0; /* reset packet counter */ if ((*ret_nrt)->rt_flags & (RTF_CLONING | RTF_PRCLONING)) { rt->rt_parent = (*ret_nrt); (*ret_nrt)->rt_refcnt++; --- sys/net/route.h.old Thu May 30 23:42:42 2002 +++ sys/net/route.h Thu May 30 23:52:34 2002 @@ -181,12 +181,12 @@ pid_t rtm_pid; /* identify sender */ int rtm_seq; /* for sender to identify action */ int rtm_errno; /* why failed */ - int rtm_use; /* from rtentry */ + u_long rtm_use; /* from rtentry */ u_long rtm_inits; /* which metrics we are initializing */ struct rt_metrics rtm_rmx; /* metrics themselves */ }; -#define RTM_VERSION 5 /* Up the ante and ignore older versions */ +#define RTM_VERSION 6 /* Up the ante and ignore older versions */ /* * Message types. --- usr.bin/netstat/route.c.old Thu May 30 23:54:36 2002 +++ usr.bin/netstat/route.c Thu May 30 23:54:59 2002 @@ -596,7 +596,7 @@ WID_GW(addr.u_sa.sa_family)); p_flags(rt->rt_flags, "%-6.6s "); if (addr.u_sa.sa_family == AF_INET || Wflag) { - printf("%6ld %8ld ", rt->rt_refcnt, rt->rt_use); + printf("%6ld %8lu ", rt->rt_refcnt, rt->rt_use); if (Wflag) { if (rt->rt_rmx.rmx_mtu != 0) printf("%6lu ", rt->rt_rmx.rmx_mtu); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 30 19:47:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d19.as29.nwbl0.wi.voyager.net [169.207.73.19]) by hub.freebsd.org (Postfix) with ESMTP id A22B137B407 for ; Thu, 30 May 2002 19:47:09 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.3/8.12.3) with ESMTP id g4V2mLOA021563; Thu, 30 May 2002 21:48:21 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.3/8.12.3/Submit) with ESMTP id g4V2mEtW021560; Thu, 30 May 2002 21:48:20 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Thu, 30 May 2002 21:48:13 -0500 (CDT) From: Mike Silbersack To: Andre Oppermann Cc: freebsd-net@freebsd.org Subject: Re: Bug in net/route.[ch] with rmx_pksent while cloning In-Reply-To: <3CF6B748.E8CA7FC6@pipeline.ch> Message-ID: <20020530214724.W20499-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 31 May 2002, Andre Oppermann wrote: > Hi all, > > there is a bug in sys/route.[ch] with the rmx_pksent statistics (which > counts how many times the route has been used to forward a ip packet). > > Silby, Bosko or Luigi, could you have a look at this? > > -- > Andre Sure, I'll take a look at in the next day or two. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 30 21:44:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d19.as29.nwbl0.wi.voyager.net [169.207.73.19]) by hub.freebsd.org (Postfix) with ESMTP id C559D37B401 for ; Thu, 30 May 2002 21:44:16 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.3/8.12.3) with ESMTP id g4V4jTOA022201; Thu, 30 May 2002 23:45:29 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.3/8.12.3/Submit) with ESMTP id g4V4jScU022198; Thu, 30 May 2002 23:45:29 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Thu, 30 May 2002 23:45:28 -0500 (CDT) From: Mike Silbersack To: Andre Oppermann Cc: freebsd-net@freebsd.org Subject: Re: Bug in net/route.[ch] with rmx_pksent while cloning In-Reply-To: <3CF6B748.E8CA7FC6@pipeline.ch> Message-ID: <20020530233919.K22164-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 31 May 2002, Andre Oppermann wrote: Ok, here we go. > if (req == RTM_RESOLVE) { > rt->rt_rmx = (*ret_nrt)->rt_rmx; /* copy metrics */ > + rt->rt_rmx.rmx_pksent = 0; /* reset packet counter */ This has been committed to -current, and will be MFC'd after 4.6-release is tagged and away. I guess this could really throw stats off for some people, good catch! > - int rtm_use; /* from rtentry */ > + u_long rtm_use; /* from rtentry */ On i386 systems, making such a change should be safe, as int and u_long are both 32 bits, if I recall correctly. However, changing this will change the size of the structure on 64-bit architectures, so I'm not sure I want to touch it. I know that if you change the size of rtentry, you need to recompile route to match the kernel if you want any routing functions to work. Will similar breakage occur if rt_msghdr is changed? I agree that your change is correct, I just don't want to break anything in the process of making it better. :) > - printf("%6ld %8ld ", rt->rt_refcnt, rt->rt_use); > + printf("%6ld %8lu ", rt->rt_refcnt, rt->rt_use); Also committed and slated for MFC. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 30 23:39:53 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 0E21037B407 for ; Thu, 30 May 2002 23:39:31 -0700 (PDT) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.3/8.12.3) with ESMTP id g4V6dTeE031102 for ; Thu, 30 May 2002 23:39:29 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id g4V6dTaS031101 for net@freebsd.org; Thu, 30 May 2002 23:39:29 -0700 Date: Thu, 30 May 2002 23:39:29 -0700 From: Brooks Davis To: net@freebsd.org Subject: review request: cloning for ppp(4) Message-ID: <20020530233929.A29279@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Below is a patch which does the important parts of making kernel ppp devices clonable and making the module unloadable. It combines both "ifconfig create" style cloning and the sl(4) create on attach method. This was done to allow interfaces to be pre-created so things like firewall rules would work, but also to let things "just work" when some tried to run pppd on a tty. Since I've never used pppd, this patch hasn't been extensivly tested so any testing would be appreciated. Once this is commited, we'll have eliminated all compile time specification of the number of pseudo network devices. -- Brooks Index: conf/files =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/src/sys/conf/files,v retrieving revision 1.642 diff -u -p -r1.642 files --- conf/files 30 May 2002 17:37:34 -0000 1.642 +++ conf/files 30 May 2002 20:46:42 -0000 @@ -984,7 +984,7 @@ net/if_iso88025subr.c optional token net/if_loop.c optional loop net/if_media.c standard net/if_mib.c standard -net/if_ppp.c count ppp +net/if_ppp.c optional ppp net/if_sl.c optional sl net/if_spppsubr.c optional sppp net/if_spppsubr.c optional i4bisppp Index: net/if_ppp.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/src/sys/net/if_ppp.c,v retrieving revision 1.79 diff -u -p -r1.79 if_ppp.c --- net/if_ppp.c 4 Apr 2002 21:03:28 -0000 1.79 +++ net/if_ppp.c 28 Apr 2002 17:11:41 -0000 @@ -73,8 +73,6 @@ /* from if_sl.c,v 1.11 84/10/04 12:54:47 rick Exp */ /* from NetBSD: if_ppp.c,v 1.15.2.2 1994/07/28 05:17:58 cgd Exp */ =20 -#include "ppp.h" - #include "opt_inet.h" #include "opt_ipx.h" #include "opt_ppp.h" @@ -130,10 +128,13 @@ #include #endif =20 -static struct ppp_softc ppp_softc[NPPP]; +#define PPPNAME "ppp" +static MALLOC_DEFINE(M_PPP, PPPNAME, "PPP interface"); +static LIST_HEAD(, ppp_softc) ppp_softc_list; =20 /* XXX layering violation */ extern void pppasyncattach(void *); +extern void pppasyncdetach(void); =20 static int pppsioctl(struct ifnet *ifp, u_long cmd, caddr_t data); static void pppintr(void); @@ -143,6 +144,11 @@ static void ppp_ccp(struct ppp_softc *,=20 static void ppp_ccp_closed(struct ppp_softc *); static void ppp_inproc(struct ppp_softc *, struct mbuf *); static void pppdumpm(struct mbuf *m0); +static int ppp_clone_create(struct if_clone *, int); +static void ppp_clone_destroy(struct ifnet *); + +static struct if_clone ppp_cloner =3D IF_CLONE_INITIALIZER(PPPNAME, + ppp_clone_create, ppp_clone_destroy, 0, IF_MAXUNIT); =20 /* * Some useful mbuf macros not in mbuf.h. @@ -186,18 +192,15 @@ static struct compressor *ppp_compressor }; #endif /* PPP_COMPRESS */ =20 -/* - * Called from boot code to establish ppp interfaces. - */ -static void -pppattach(void) +static int +ppp_clone_create(struct if_clone *ifc, int unit) { - register struct ppp_softc *sc; - register int i =3D 0; + struct ppp_softc *sc; =20 - for (sc =3D ppp_softc; i < NPPP; sc++) { - sc->sc_if.if_name =3D "ppp"; - sc->sc_if.if_unit =3D i++; + sc =3D malloc(sizeof(struct ppp_softc), M_PPP, M_WAITOK | M_ZERO); + sc->sc_if.if_softc =3D sc; + sc->sc_if.if_name =3D PPPNAME; + sc->sc_if.if_unit =3D unit; sc->sc_if.if_mtu =3D PPP_MTU; sc->sc_if.if_flags =3D IFF_POINTOPOINT | IFF_MULTICAST; sc->sc_if.if_type =3D IFT_PPP; @@ -208,18 +211,29 @@ pppattach(void) sc->sc_inq.ifq_maxlen =3D IFQ_MAXLEN; sc->sc_fastq.ifq_maxlen =3D IFQ_MAXLEN; sc->sc_rawq.ifq_maxlen =3D IFQ_MAXLEN; - mtx_init(&sc->sc_inq.ifq_mtx, "ppp_inq", NULL, MTX_DEF); - mtx_init(&sc->sc_fastq.ifq_mtx, "ppp_fastq", NULL, MTX_DEF); - mtx_init(&sc->sc_rawq.ifq_mtx, "ppp_rawq", NULL, MTX_DEF); + mtx_init(&sc->sc_inq.ifq_mtx, "ppp_inq", NULL, MTX_DEF); + mtx_init(&sc->sc_fastq.ifq_mtx, "ppp_fastq", NULL, MTX_DEF); + mtx_init(&sc->sc_rawq.ifq_mtx, "ppp_rawq", NULL, MTX_DEF); if_attach(&sc->sc_if); bpfattach(&sc->sc_if, DLT_PPP, PPP_HDRLEN); - } - register_netisr(NETISR_PPP, pppintr); - /* - * XXX layering violation - if_ppp can work over any lower level - * transport that cares to attach to it. - */ - pppasyncattach(NULL); + LIST_INSERT_HEAD(&ppp_softc_list, sc, sc_list); + + return 1; +} + +static void +ppp_clone_destroy(struct ifnet *ifp) +{ + struct ppp_softc *sc; + + sc =3D ifp->if_softc; + + LIST_REMOVE(sc, sc_list); + bpfdetach(ifp); + if_detach(ifp); + mtx_destroy(&sc->sc_rawq.ifq_mtx); + mtx_destroy(&sc->sc_fastq.ifq_mtx); + mtx_destroy(&sc->sc_inq.ifq_mtx); } =20 static int @@ -227,10 +241,27 @@ ppp_modevent(module_t mod, int type, voi {=20 switch (type) {=20 case MOD_LOAD:=20 - pppattach(); + if_clone_attach(&ppp_cloner); + + register_netisr(NETISR_PPP, pppintr); + /* + * XXX layering violation - if_ppp can work over any lower + * level transport that cares to attach to it. + */ + pppasyncattach(NULL); break;=20 case MOD_UNLOAD:=20 - printf("if_ppp module unload - not possible for this module type\n");=20 + /* XXX: layering violation */ + pppasyncdetach(); + + unregister_netisr(NETISR_PPP); + + if_clone_detach(&ppp_cloner); + + while (!LIST_EMPTY(&ppp_softc_list)) + ppp_clone_destroy( + &LIST_FIRST(&ppp_softc_list)->sc_if); + return EINVAL;=20 }=20 return 0;=20 @@ -251,18 +282,32 @@ struct ppp_softc * pppalloc(pid) pid_t pid; { - int nppp, i; + int i; + char tmpname[IFNAMSIZ]; + struct ifnet *ifp; struct ppp_softc *sc; =20 - for (nppp =3D 0, sc =3D ppp_softc; nppp < NPPP; nppp++, sc++) + LIST_FOREACH(sc, &ppp_softc_list, sc_list) { if (sc->sc_xfer =3D=3D pid) { sc->sc_xfer =3D 0; return sc; } - for (nppp =3D 0, sc =3D ppp_softc; nppp < NPPP; nppp++, sc++) + } + LIST_FOREACH(sc, &ppp_softc_list, sc_list) { if (sc->sc_devp =3D=3D NULL) break; - if (nppp >=3D NPPP) + } + /* Try to clone an interface if we don't have a free one */ + if (sc =3D=3D NULL) { + strcpy(tmpname, PPPNAME); + if (if_clone_create(tmpname, sizeof(tmpname)) !=3D 0) + return NULL; + ifp =3D ifunit(tmpname); + if (ifp =3D=3D NULL) + return NULL; + sc =3D ifp->if_softc; + } + if (sc =3D=3D NULL || sc->sc_devp !=3D NULL) return NULL; =20 sc->sc_flags =3D 0; @@ -574,7 +619,7 @@ pppsioctl(ifp, cmd, data) caddr_t data; { struct thread *td =3D curthread; /* XXX */ - register struct ppp_softc *sc =3D &ppp_softc[ifp->if_unit]; + register struct ppp_softc *sc =3D ifp->if_softc; register struct ifaddr *ifa =3D (struct ifaddr *)data; register struct ifreq *ifr =3D (struct ifreq *)data; struct ppp_stats *psp; @@ -704,7 +749,7 @@ pppoutput(ifp, m0, dst, rtp) struct sockaddr *dst; struct rtentry *rtp; { - register struct ppp_softc *sc =3D &ppp_softc[ifp->if_unit]; + register struct ppp_softc *sc =3D ifp->if_softc; int protocol, address, control; u_char *cp; int s, error; @@ -1085,11 +1130,10 @@ static void pppintr() { struct ppp_softc *sc; - int i, s; + int s; struct mbuf *m; =20 - sc =3D ppp_softc; - for (i =3D 0; i < NPPP; ++i, ++sc) { + LIST_FOREACH(sc, &ppp_softc_list, sc_list) { s =3D splimp(); if (!(sc->sc_flags & SC_TBUSY) && (sc->sc_if.if_snd.ifq_head || sc->sc_fastq.ifq_head)) { Index: net/if_pppvar.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/src/sys/net/if_pppvar.h,v retrieving revision 1.19 diff -u -p -r1.19 if_pppvar.h --- net/if_pppvar.h 24 Mar 2002 09:34:04 -0000 1.19 +++ net/if_pppvar.h 13 Apr 2002 03:36:14 -0000 @@ -96,6 +96,7 @@ struct ppp_softc { u_short sc_outfcs; /* FCS so far for output packet */ u_char sc_rawin[16]; /* chars as received */ int sc_rawin_count; /* # in sc_rawin */ + LIST_ENTRY(ppp_softc) sc_list; }; =20 struct ppp_softc *pppalloc(pid_t pid); Index: net/ppp_tty.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/src/sys/net/ppp_tty.c,v retrieving revision 1.50 diff -u -p -r1.50 ppp_tty.c --- net/ppp_tty.c 1 Apr 2002 21:31:03 -0000 1.50 +++ net/ppp_tty.c 25 May 2002 21:15:47 -0000 @@ -114,6 +114,7 @@ static void ppplogchar(struct ppp_softc=20 =20 /* XXX called from if_ppp.c - layering violation */ void pppasyncattach(void *); +void pppasyncdetach(void); =20 /* * Some useful mbuf macros not in mbuf.h. @@ -146,6 +147,7 @@ void pppasyncattach(void *); * Define the PPP line discipline. */ =20 +static struct linesw pppnodisc; static struct linesw pppdisc =3D { pppopen, pppclose, pppread, pppwrite, ppptioctl, pppinput, pppstart, ttymodem, @@ -156,8 +158,17 @@ void pppasyncattach(dummy) void *dummy; { + /* save previous entry for detach */ + pppnodisc =3D linesw[PPPDISC]; /* register line discipline */ linesw[PPPDISC] =3D pppdisc; +} + +void +pppasyncdetach() +{ + /* deregister line discipline */ + linesw[PPPDISC] =3D pppnodisc; } =20 /* --=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 --5vNYLRcllDrimb99 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 iD8DBQE89xqgXY6L6fI4GtQRAkDbAKCC1Z0PUwLwsCijH38vcnNDmalF3wCgz/7H j1RHMEceW83yja9edLngmhA= =5twJ -----END PGP SIGNATURE----- --5vNYLRcllDrimb99-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 31 2: 6:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from starfruit.itojun.org (dhcp108.iijlab.net [202.232.15.108]) by hub.freebsd.org (Postfix) with ESMTP id 9AB4E37B400 for ; Fri, 31 May 2002 02:06:44 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 788287B9; Fri, 31 May 2002 18:06:11 +0900 (JST) To: freebsd-net@freebsd.org Subject: Re: MPLS References: <200205291709.g4TH917f018013@nic-naa.net> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: Jun-ichiro itojun Hagino Date: Fri, 31 May 2002 18:06:11 +0900 Message-Id: <20020531090611.788287B9@starfruit.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org if you want MPLS on BSD, check out http://www.ayame.org/. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 31 4:44:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id C10F437B404 for ; Fri, 31 May 2002 04:44:40 -0700 (PDT) Received: (qmail 1902 invoked from network); 31 May 2002 11:44:13 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 31 May 2002 11:44:13 -0000 Message-ID: <3CF761DA.72AE838A@pipeline.ch> Date: Fri, 31 May 2002 13:43:22 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack Cc: freebsd-net@freebsd.org Subject: Re: Bug in net/route.[ch] with rmx_pksent while cloning References: <20020530233919.K22164-100000@patrocles.silby.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Mike Silbersack wrote: > > On Fri, 31 May 2002, Andre Oppermann wrote: > > Ok, here we go. > > > if (req == RTM_RESOLVE) { > > rt->rt_rmx = (*ret_nrt)->rt_rmx; /* copy metrics */ > > + rt->rt_rmx.rmx_pksent = 0; /* reset packet counter */ > > This has been committed to -current, and will be MFC'd after 4.6-release > is tagged and away. I guess this could really throw stats off for some > people, good catch! Thanks! > > - int rtm_use; /* from rtentry */ > > + u_long rtm_use; /* from rtentry */ > > On i386 systems, making such a change should be safe, as int and u_long > are both 32 bits, if I recall correctly. However, changing this will > change the size of the structure on 64-bit architectures, so I'm not sure > I want to touch it. I know that if you change the size of rtentry, you > need to recompile route to match the kernel if you want any routing > functions to work. Will similar breakage occur if rt_msghdr is changed? I think it will break. Isn't there a compiler warning in net/rtsocket.c on 64bit platforms about the u_long to int assignment? IMO the right solution would to simply axe this field from rt_msghdr. It serves no purpose. At least none of the base utilites look at it and I don't see neither gated nor Zebra using it. My vote would go to axe it in -CURRENT and bump the version number. Netstat and route need to be recompiled. Note in UPDATING. > I agree that your change is correct, I just don't want to break anything > in the process of making it better. :) Yea, it's difficult. While testing this I locked myself out of the box because I forgot to recompile route and then the startup could failed to install the default route. Fortunatly I could login from another machine in the subnet and fix it. So for -STABLE it's a no-go. > > - printf("%6ld %8ld ", rt->rt_refcnt, rt->rt_use); > > + printf("%6ld %8lu ", rt->rt_refcnt, rt->rt_use); > > Also committed and slated for MFC. Thanks! -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 31 7:23: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from ligeti.cns.vt.edu (ligeti.cns.vt.edu [128.173.8.161]) by hub.freebsd.org (Postfix) with ESMTP id 2F8AA37B407 for ; Fri, 31 May 2002 07:22:58 -0700 (PDT) Received: by ligeti.cns.vt.edu (Postfix, from userid 1131) id 808B729D17; Fri, 31 May 2002 14:22:57 +0000 (US/Eastern) Date: Fri, 31 May 2002 10:22:57 -0400 From: Clark Gaylord To: Paul Traina Cc: freebsd-net@freebsd.org Subject: Re: MPLS Message-ID: <20020531102257.Y13136@ligeti.cns.vt.edu> Reply-To: cgaylord@cns.vt.edu References: <3CF4A64A.EE220611@pipeline.ch> <200205291413.g4TEDLRG075458@whizzo.transsys.com> <3CF4E483.2510639@pipeline.ch> <20020529175205.GJ33611@overlord.e-gerbil.net> <3CF519E6.C649CA25@pipeline.ch> <008f01c20745$65478900$2b6b6fc0@shockwave.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <008f01c20745$65478900$2b6b6fc0@shockwave.org>; from Paul Traina on Wed, May 29, 2002 at 12:16:50PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, May 29, 2002 at 12:16:50PM -0700, Paul Traina wrote: > > > Bwah... It lacks things like transparent-nexthop and transparent-as > > which is quite useful in Route Servers and such. > > We don't add features to code unless people are willing to pay for them and > use them. which is why we use rsd. --ckg -- Clark K. Gaylord Senior Research Engineer Communications Network Services Virginia Tech, Blacksburg, Virginia 24061-0506 Voice: 540/231-2347 Fax: 540/231-3928 E-mail: cgaylord@cns.vt.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 31 10: 5:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 3DB2037B407 for ; Fri, 31 May 2002 10:05:20 -0700 (PDT) Received: from isi.edu (kiaqvwlweo0nltsl@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g4VH5Je18756 for ; Fri, 31 May 2002 10:05:19 -0700 (PDT) Message-ID: <3CF7AD4D.2090801@isi.edu> Date: Fri, 31 May 2002 10:05:17 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: net@freebsd.org Subject: netgraph documentation? Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050807080500010003060902" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms050807080500010003060902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I'm starting to play with netgraph, and there doesn't seem to be much documentation out there (other then the DaemonNews article, and the man pages.) For starters, I was going to modify the UDP tunneling example in the DaemonNews article to do TCP tunneling. However, I'm having problems getting the "server" side of the TCP tunnel to listen on the ksocket: /usr/sbin/ngctl mkpeer iface dummy inet /usr/sbin/ngctl mkpeer ng3: ksocket inet inet/stream/tcp /usr/sbin/ngctl msg ng3:inet bind inet/10.0.0.1:50505 /usr/sbin/ngctl msg ng3:inet listen 1 ngctl: send msg: Operation not supported by device So I guess I have two questions: 1. Is there some other netgraph documentation out there that I don't knowe about? 2. Why can't I listen on a ksocket? Thanks, Lars -- Lars Eggert USC Information Sciences Institute --------------ms050807080500010003060902 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDUzMTE3MDUxOFowIwYJKoZIhvcNAQkEMRYEFKuZGFYczDPL TJa3BbiWiVqXSYevMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYC/G+t+wC0cx+gIwcyEVNjuqpQrmi3EJKF2RU3xcahHPquO 4UHN2Mr62PFfp0EaSMyon0Y8+4khAk9i61P6zhteqB59pJ+vNnSYtVW70MiwzupCmIdDOmpv p8evFEfFKVEXs3C0teEKTGTFGusIGYhg96+JqSvuyTVkN//+wJQP9QAAAAAAAA== --------------ms050807080500010003060902-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 31 11:45:14 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 385E837B407 for ; Fri, 31 May 2002 11:45:04 -0700 (PDT) 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 LAA57742 for ; Fri, 31 May 2002 11:30:18 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g4VITKM01684; Fri, 31 May 2002 11:29:20 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200205311829.g4VITKM01684@arch20m.dellroad.org> Subject: m_split() considered harmful To: freebsd-net@freebsd.org Date: Fri, 31 May 2002 11:29:20 -0700 (PDT) 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 Hi, There is an inconsistency in the kernel mbuf code around the "m->m_ext.ext_size" field of an M_EXT mbuf. At first glance you might assume that this field is the total amount of contiguous space available in the external buffer pointed to by "m->m_ext.ext_buf". For example, look at the M_TRAILINGSPACE() and MCLGET() macros. But alas, you know where assumptions lead... :-) Now look at m_split(), in particular this code: if (m->m_flags & M_EXT) { n->m_flags |= M_EXT; n->m_ext = m->m_ext; if(!m->m_ext.ext_ref) mclrefcnt[mtocl(m->m_ext.ext_buf)]++; else (*(m->m_ext.ext_ref))(m->m_ext.ext_buf, m->m_ext.ext_size); m->m_ext.ext_size = 0; /* For Accounting XXXXXX danger */ n->m_data = m->m_data + len; } else { Notice the 'XXXXXX' which is where the problem lies. The code is just recklessly setting m->m_ext.ext_size to zero to avoid some "accounting" problem. This has been there since revision 1.1/rgrimes. This is comletely broken and violates the semantics of the "m->m_ext.ext_size" field implied by M_TRAILINGSPACE() et. al. Moreover, I've also done a search of every occurrence of "ext_size" and everywhere else in the kernel treats this feild with the same "external buffer size" semantics, and there is no "accounting" that is done with this field. For an example of where this could cause problems, notice that a call to sbfree() on an mbuf that had gone through an m_split() could cause a "receive 1" panic (I've seen these occasionally over the years). FYI, m_split() is used in these files: netgraph/ng_ppp.c netinet6/ah_input.c netinet6/esp_input.c netinet6/frag6.c netsmb/smb_rq.c If there are no objections, I will apply the patch below. Thanks, -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com --- kern/uipc_mbuf.c.orig Fri May 31 11:17:52 2002 +++ kern/uipc_mbuf.c Fri May 31 11:27:42 2002 @@ -1194,6 +1194,10 @@ * Partition an mbuf chain in two pieces, returning the tail -- * all but the first len0 bytes. In case of failure, it returns NULL and * attempts to restore the chain to its original state. + * + * Note that the returned mbuf must be treated as read-only, because + * it will end up sharing an mbuf cluster with the original mbuf if the + * "breaking point" happens to lie within a cluster mbuf. */ struct mbuf * m_split(m0, len0, wait) @@ -1247,7 +1251,6 @@ else (*(m->m_ext.ext_ref))(m->m_ext.ext_buf, m->m_ext.ext_size); - m->m_ext.ext_size = 0; /* For Accounting XXXXXX danger */ n->m_data = m->m_data + len; } else { bcopy(mtod(m, caddr_t) + len, mtod(n, caddr_t), remain); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 31 11:56:51 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 D50CE37B404 for ; Fri, 31 May 2002 11:56:36 -0700 (PDT) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g4VIuZi46201; Fri, 31 May 2002 11:56:35 -0700 (PDT) (envelope-from rizzo) Date: Fri, 31 May 2002 11:56:35 -0700 From: Luigi Rizzo To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG Subject: Re: m_split() considered harmful Message-ID: <20020531115635.B45530@iguana.icir.org> References: <200205311829.g4VITKM01684@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200205311829.g4VITKM01684@arch20m.dellroad.org>; from archie@dellroad.org on Fri, May 31, 2002 at 11:29:20AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, May 31, 2002 at 11:29:20AM -0700, Archie Cobbs wrote: ... if you add the additional Note, then it might be worthwhile that the writability of the returned buffer should be checked in the standard way (whatever macro it is, i forget the name). cheers luigi > > --- kern/uipc_mbuf.c.orig Fri May 31 11:17:52 2002 > +++ kern/uipc_mbuf.c Fri May 31 11:27:42 2002 > @@ -1194,6 +1194,10 @@ > * Partition an mbuf chain in two pieces, returning the tail -- > * all but the first len0 bytes. In case of failure, it returns NULL and > * attempts to restore the chain to its original state. > + * > + * Note that the returned mbuf must be treated as read-only, because > + * it will end up sharing an mbuf cluster with the original mbuf if the > + * "breaking point" happens to lie within a cluster mbuf. > */ > struct mbuf * > m_split(m0, len0, wait) > @@ -1247,7 +1251,6 @@ > else > (*(m->m_ext.ext_ref))(m->m_ext.ext_buf, > m->m_ext.ext_size); > - m->m_ext.ext_size = 0; /* For Accounting XXXXXX danger */ > n->m_data = m->m_data + len; > } else { > bcopy(mtod(m, caddr_t) + len, mtod(n, caddr_t), remain); > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 31 12: 0:39 2002 Delivered-To: freebsd-net@freebsd.org Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by hub.freebsd.org (Postfix) with ESMTP id 6B60A37B401 for ; Fri, 31 May 2002 12:00:27 -0700 (PDT) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g4VIxcl71245; Fri, 31 May 2002 14:59:38 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Fri, 31 May 2002 14:59:38 -0400 From: Bosko Milekic To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG Subject: Re: m_split() considered harmful Message-ID: <20020531145938.A71219@unixdaemons.com> References: <200205311829.g4VITKM01684@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200205311829.g4VITKM01684@arch20m.dellroad.org>; from archie@dellroad.org on Fri, May 31, 2002 at 11:29:20AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, May 31, 2002 at 11:29:20AM -0700, Archie Cobbs wrote: > Hi, > > There is an inconsistency in the kernel mbuf code around the > "m->m_ext.ext_size" field of an M_EXT mbuf. > > At first glance you might assume that this field is the total amount > of contiguous space available in the external buffer pointed to by > "m->m_ext.ext_buf". For example, look at the M_TRAILINGSPACE() and > MCLGET() macros. But alas, you know where assumptions lead... :-) > > Now look at m_split(), in particular this code: > > if (m->m_flags & M_EXT) { > n->m_flags |= M_EXT; > n->m_ext = m->m_ext; > if(!m->m_ext.ext_ref) > mclrefcnt[mtocl(m->m_ext.ext_buf)]++; > else > (*(m->m_ext.ext_ref))(m->m_ext.ext_buf, > m->m_ext.ext_size); > m->m_ext.ext_size = 0; /* For Accounting XXXXXX danger */ > n->m_data = m->m_data + len; > } else { > > Notice the 'XXXXXX' which is where the problem lies. The code is > just recklessly setting m->m_ext.ext_size to zero to avoid some > "accounting" problem. This has been there since revision 1.1/rgrimes. > > This is comletely broken and violates the semantics of the > "m->m_ext.ext_size" field implied by M_TRAILINGSPACE() et. al. Good catch. Thanks Archie! > Moreover, I've also done a search of every occurrence of "ext_size" > and everywhere else in the kernel treats this feild with the same > "external buffer size" semantics, and there is no "accounting" that > is done with this field. > > For an example of where this could cause problems, notice that > a call to sbfree() on an mbuf that had gone through an m_split() > could cause a "receive 1" panic (I've seen these occasionally over > the years). > > FYI, m_split() is used in these files: > > netgraph/ng_ppp.c > netinet6/ah_input.c > netinet6/esp_input.c > netinet6/frag6.c > netsmb/smb_rq.c > > If there are no objections, I will apply the patch below. > > Thanks, > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com > > --- kern/uipc_mbuf.c.orig Fri May 31 11:17:52 2002 > +++ kern/uipc_mbuf.c Fri May 31 11:27:42 2002 > @@ -1194,6 +1194,10 @@ > * Partition an mbuf chain in two pieces, returning the tail -- > * all but the first len0 bytes. In case of failure, it returns NULL and > * attempts to restore the chain to its original state. > + * > + * Note that the returned mbuf must be treated as read-only, because > + * it will end up sharing an mbuf cluster with the original mbuf if the > + * "breaking point" happens to lie within a cluster mbuf. > */ Can you please apply this to -CURRENT first? -CURRENT has the same problem. Notice that in -CURRENT we have a M_WRITABLE() macro which will actually evaluate to false for both mbufs as they will be referring to a cluster that has a ref count of > 1 so this comment will be implicitly represented in the code. Now all we have to do is actually start using the M_WRITABLE macro more often. :-) > struct mbuf * > m_split(m0, len0, wait) > @@ -1247,7 +1251,6 @@ > else > (*(m->m_ext.ext_ref))(m->m_ext.ext_buf, > m->m_ext.ext_size); > - m->m_ext.ext_size = 0; /* For Accounting XXXXXX danger */ > n->m_data = m->m_data + len; > } else { > bcopy(mtod(m, caddr_t) + len, mtod(n, caddr_t), remain); I don't remember why the ext_size here was this originally (as you mention, it was imported that way), but it certainly seems bogus and you catching it now is hopefully going to solve some really wierd and difficult-to-debug problems we've had involving mbufs over the years. Woop! -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 31 13: 0:27 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 3300037B406 for ; Fri, 31 May 2002 13:00:15 -0700 (PDT) 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 <20020531200014.QZKY11426.rwcrmhc51.attbi.com@InterJet.elischer.org>; Fri, 31 May 2002 20:00: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 MAA29651; Fri, 31 May 2002 12:42:25 -0700 (PDT) Date: Fri, 31 May 2002 12:42:24 -0700 (PDT) From: Julian Elischer To: Archie Cobbs Cc: freebsd-net@freebsd.org Subject: Re: m_split() considered harmful In-Reply-To: <200205311829.g4VITKM01684@arch20m.dellroad.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org When I added these fields in freebsd1.x (They may have gone through some metamorphesis since) it was to support some stuff we were doing at TFS. They were variants of similar fields in BSD4.3 RENO. The problem that can occur is that the code that splits the data can end up having two references to the same external object when the data split point lies within an external object. In this case (if the reference count is > 1) the M_TRAILINGSPACE and M_LEADINGSPACE(m) must take into account that they cannot return the leading and trailing space as free as they may be used by onother mbuf. M_LEADINGSPACE(m) already has: M_WRITABLE(m) ? (m)->m_data - (m)->m_ext.ext_buf : 0 but M_TRAILINGSPACE(m) does not. so we cannot use the room in front of and after the data unless the reference count == 1. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 31 13: 0:38 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 E3CDA37B400 for ; Fri, 31 May 2002 13:00:18 -0700 (PDT) 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 <20020531200016.QZLH11426.rwcrmhc51.attbi.com@InterJet.elischer.org>; Fri, 31 May 2002 20:00:16 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA29665; Fri, 31 May 2002 12:54:40 -0700 (PDT) Date: Fri, 31 May 2002 12:54:39 -0700 (PDT) From: Julian Elischer To: Bosko Milekic Cc: Archie Cobbs , freebsd-net@FreeBSD.ORG Subject: Re: m_split() considered harmful In-Reply-To: <20020531145938.A71219@unixdaemons.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 31 May 2002, Bosko Milekic wrote: > > I don't remember why the ext_size here was this originally (as you > mention, it was imported that way), but it certainly seems bogus and > you catching it now is hopefully going to solve some really wierd and > difficult-to-debug problems we've had involving mbufs over the years. > It was imported from FreeBSD-1.x by rod. The size argument was for two reasons. 1/ to allow the M_LEADINGSPACE and M_TRAILINGSPACE calculations to be done if it was a single reference object. 2/ to allow the free function (in the case of non cluster external objects) to know what sized object they had in the case that they needed this information. I know because I added it, because I needed to do both of these at TRW in '90-'95 under MACH/BSD and when I moved the code to FreeBSD1.x it cam along.. there was no M_LEADINGSPACE/M_TRAILINGSPACE macro at that time.. I did it in my code explicitly. It was not used in standard code because only in my own protocol stack did I know that the damned object was not shared and writable.. This has improved with time.. Having the size set to 0 however stopped users from hitting cases where the WRITABILITY of the ext objext has not been correctly tracked as it always returns "not enough space" (sometimes -ve). If we change this we need to audit the WRITABILTY.. e.g. it is not checked in M_TRAILINGSPACE Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 31 13:25:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by hub.freebsd.org (Postfix) with ESMTP id 176FB37B404 for ; Fri, 31 May 2002 13:25:20 -0700 (PDT) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g4VKNvR71540; Fri, 31 May 2002 16:23:57 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Fri, 31 May 2002 16:23:57 -0400 From: Bosko Milekic To: Julian Elischer Cc: Archie Cobbs , freebsd-net@FreeBSD.ORG Subject: Re: m_split() considered harmful Message-ID: <20020531162357.A71512@unixdaemons.com> References: <20020531145938.A71219@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from julian@elischer.org on Fri, May 31, 2002 at 12:54:39PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, May 31, 2002 at 12:54:39PM -0700, Julian Elischer wrote: > > > On Fri, 31 May 2002, Bosko Milekic wrote: > > > > > I don't remember why the ext_size here was this originally (as you > > mention, it was imported that way), but it certainly seems bogus and > > you catching it now is hopefully going to solve some really wierd and > > difficult-to-debug problems we've had involving mbufs over the years. > > > It was imported from FreeBSD-1.x by rod. > > The size argument was for two reasons. > 1/ to allow the M_LEADINGSPACE and M_TRAILINGSPACE calculations > to be done if it was a single reference object. > 2/ to allow the free function (in the case of non cluster external > objects) to know what sized object they had in the case that they needed > this information. Yeah, we still need the field to exist because of (2). I just meant that we should remove the explicit setting of 0 of the field in m_split(), and that's what Archie suggested. > I know because I added it, because I needed to do both of these at TRW in > '90-'95 under MACH/BSD and when I moved the code to FreeBSD1.x it cam > along.. there was no M_LEADINGSPACE/M_TRAILINGSPACE macro at that time.. > I did it in my code explicitly. > > It was not used in standard code because only in my own protocol stack > did I know that the damned object was not shared and writable.. > This has improved with time.. > > Having the size set to 0 however stopped users from hitting > cases where the WRITABILITY of the ext objext has not been correctly > tracked as it always returns "not enough space" (sometimes -ve). Right now, in -CURRENT, we have a M_WRITABLE macro, as you noticed, that evalutes true unless one of these conditions is true: 1) M_RDONLY is set in the mbuf 2) mbuf has external buffer attached and ref. count on that buffer (e.g., cluster, whatever) is > 1. This macro (M_WRITABLE) _is_ currently used in M_LEADINGSPACE. If the mbuf being checked is not writable, M_LEADINGSPACE will evalute to 0. However, I noticed just now that it is not used in M_TRAILINGSPACE, where it probably should be. M_TRAILINGSPACE should probably look like this: #define M_TRAILINGSPACE(m) \ ((m)->m_flags & M_EXT ? \ (M_WRITABLE(m) ? \ (m)->m_ext.ext_buf + (m)->m_ext.ext_size - \ ((m)->m_data + (m)->m_len) : 0) : \ &(m)->m_dat[MLEN] - ((m)->m_data + (m)->m_len)) This is the same philosophy adopted by M_LEADINGSPACE. I have no idea how I missed that when we did the M_WRITABLE stuff. Or did we leave it out for some specific reason? Ian Dowse or David Malone would know, as the WRITABLE code was thanks to them. :-) > If we change this we need to audit the WRITABILTY.. > e.g. it is not checked in M_TRAILINGSPACE Right. > Julian -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 31 13:45:29 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 6440537B413 for ; Fri, 31 May 2002 13:45:02 -0700 (PDT) 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 NAA58363; Fri, 31 May 2002 13:26:07 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g4VKP9t02205; Fri, 31 May 2002 13:25:09 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200205312025.g4VKP9t02205@arch20m.dellroad.org> Subject: Re: m_split() considered harmful In-Reply-To: "from Julian Elischer at May 31, 2002 12:54:39 pm" To: Julian Elischer Date: Fri, 31 May 2002 13:25:09 -0700 (PDT) Cc: Bosko Milekic , Archie Cobbs , 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: > '90-'95 under MACH/BSD and when I moved the code to FreeBSD1.x it cam > along.. there was no M_LEADINGSPACE/M_TRAILINGSPACE macro at that time.. > I did it in my code explicitly. > > It was not used in standard code because only in my own protocol stack > did I know that the damned object was not shared and writable.. > This has improved with time.. > > Having the size set to 0 however stopped users from hitting > cases where the WRITABILITY of the ext objext has not been correctly > tracked as it always returns "not enough space" (sometimes -ve). > > If we change this we need to audit the WRITABILTY.. > e.g. it is not checked in M_TRAILINGSPACE It's not clear whether the caller of M_TRAILINGSPACE()/M_LEADINGSPACE() is responsible for checking for writability, or the macros themselves. It seems to make more sense that the caller would be responsible... why would you call M_TRAILINGSPACE() unless you wanted to write something in there? I agree that we should audit for writability, however, the only case where this could become an issue with this patch is if somewhere a call to m_split() is made, followed by a call to M_TRAILINGSPACE(), followed by a write to the mbuf data area because M_TRAILINGSPACE() > 0. In fact, this would have to happen to 2 or more copies of the cluster for there to be a problem. I'd say this is very unlikely, but still possible. Any *other* use of the mbuf as writable after a call to m_split() is already an existing bug and is not made any worse by this patch. As a temporary saftey measure, I'll add M_WRITABLE(m) into the M_TRAILINGSPACE() macro. However, I see this as a temporary hack; the correct fix is to put the burden of writability on the caller. After all, M_TRAILINGSPACE() doesn't modify the mbuf data! That is, what we really need is a more general audit for code that writes into mbufs that might be read-only -- and, as one special case of tha, code that calls M_TRAILINGSPACE()/M_LEADINGSPACE() before writing into an mbuf. FYI, any easy way to do this would be to add const'ness to mtod(): #define mtod(m, t) ((const t)((m)->m_data)) and then look for GCC warnings. Any takers?? :-) Updated patch below. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com Index: sys/mbuf.h =================================================================== RCS file: /home/ncvs/src/sys/sys/mbuf.h,v retrieving revision 1.89 diff -u -r1.89 mbuf.h --- sys/mbuf.h 5 Feb 2002 02:00:56 -0000 1.89 +++ sys/mbuf.h 31 May 2002 20:24:41 -0000 @@ -344,6 +344,9 @@ /* * Compute the amount of space available * before the current start of data in an mbuf. + * + * The M_WRITABLE() is a temporary, conservative safety measure: the burden + * of checking writability of the mbuf data area rests solely with the caller. */ #define M_LEADINGSPACE(m) \ ((m)->m_flags & M_EXT ? \ @@ -354,10 +357,14 @@ /* * Compute the amount of space available * after the end of data in an mbuf. + * + * The M_WRITABLE() is a temporary, conservative safety measure: the burden + * of checking writability of the mbuf data area rests solely with the caller. */ #define M_TRAILINGSPACE(m) \ - ((m)->m_flags & M_EXT ? (m)->m_ext.ext_buf + \ - (m)->m_ext.ext_size - ((m)->m_data + (m)->m_len) : \ + ((m)->m_flags & M_EXT ? \ + (M_WRITABLE(m) ? (m)->m_ext.ext_buf + (m)->m_ext.ext_size \ + - ((m)->m_data + (m)->m_len) : 0) : \ &(m)->m_dat[MLEN] - ((m)->m_data + (m)->m_len)) /* Index: kern/uipc_mbuf.c =================================================================== RCS file: /home/ncvs/src/sys/kern/uipc_mbuf.c,v retrieving revision 1.91 diff -u -r1.91 uipc_mbuf.c --- kern/uipc_mbuf.c 12 Apr 2002 00:01:50 -0000 1.91 +++ kern/uipc_mbuf.c 31 May 2002 20:24:45 -0000 @@ -560,6 +560,11 @@ * Partition an mbuf chain in two pieces, returning the tail -- * all but the first len0 bytes. In case of failure, it returns NULL and * attempts to restore the chain to its original state. + * + * Note that the resulting mbufs might be read-only, because the new + * mbuf can end up sharing an mbuf cluster with the original mbuf if + * the "breaking point" happens to lie within a cluster mbuf. Use the + * M_WRITABLE() macro to check for this case. */ struct mbuf * m_split(struct mbuf *m0, int len0, int wait) @@ -609,7 +614,6 @@ n->m_flags |= M_EXT; n->m_ext = m->m_ext; MEXT_ADD_REF(m); - m->m_ext.ext_size = 0; /* For Accounting XXXXXX danger */ n->m_data = m->m_data + len; } else { bcopy(mtod(m, caddr_t) + len, mtod(n, caddr_t), remain); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 31 13:52:39 2002 Delivered-To: freebsd-net@freebsd.org Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by hub.freebsd.org (Postfix) with ESMTP id 176EF37B420 for ; Fri, 31 May 2002 13:52:00 -0700 (PDT) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g4VKoeQ71755; Fri, 31 May 2002 16:50:40 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Fri, 31 May 2002 16:50:40 -0400 From: Bosko Milekic To: Archie Cobbs Cc: Julian Elischer , freebsd-net@FreeBSD.ORG Subject: Re: m_split() considered harmful Message-ID: <20020531165040.A71744@unixdaemons.com> References: <200205312025.g4VKP9t02205@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200205312025.g4VKP9t02205@arch20m.dellroad.org>; from archie@dellroad.org on Fri, May 31, 2002 at 01:25:09PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, May 31, 2002 at 01:25:09PM -0700, Archie Cobbs wrote: [...] > As a temporary saftey measure, I'll add M_WRITABLE(m) into the > M_TRAILINGSPACE() macro. However, I see this as a temporary hack; > the correct fix is to put the burden of writability on the caller. > After all, M_TRAILINGSPACE() doesn't modify the mbuf data! > > That is, what we really need is a more general audit for code that > writes into mbufs that might be read-only -- and, as one special case > of tha, code that calls M_TRAILINGSPACE()/M_LEADINGSPACE() before writing > into an mbuf. Agreed. [...] > Updated patch below. > > -Archie [...] Patch looks good. -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 31 14: 0:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by hub.freebsd.org (Postfix) with ESMTP id DDA2437B409 for ; Fri, 31 May 2002 14:00:24 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020531210024.MSIN20219.sccrmhc03.attbi.com@InterJet.elischer.org>; Fri, 31 May 2002 21:00:24 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA29904; Fri, 31 May 2002 13:52:19 -0700 (PDT) Date: Fri, 31 May 2002 13:52:18 -0700 (PDT) From: Julian Elischer To: Archie Cobbs Cc: Bosko Milekic , freebsd-net@FreeBSD.ORG Subject: Re: m_split() considered harmful In-Reply-To: <200205312025.g4VKP9t02205@arch20m.dellroad.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 31 May 2002, Archie Cobbs wrote: > > It's not clear whether the caller of M_TRAILINGSPACE()/M_LEADINGSPACE() > is responsible for checking for writability, or the macros themselves. > It seems to make more sense that the caller would be responsible... > why would you call M_TRAILINGSPACE() unless you wanted to write > something in there? > M_TRAILINGSPACE is called to ask "How much writable room is there after hte data here? if the module is not writable the answer should always be "none". your patch looks better now I'm wouldering however if any code other than that looks at ext_size To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 31 14:30:38 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 DCBE237B406 for ; Fri, 31 May 2002 14:30:33 -0700 (PDT) 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 OAA58663; Fri, 31 May 2002 14:12:39 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g4VLBff02718; Fri, 31 May 2002 14:11:41 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200205312111.g4VLBff02718@arch20m.dellroad.org> Subject: Re: m_split() considered harmful In-Reply-To: "from Julian Elischer at May 31, 2002 01:52:18 pm" To: Julian Elischer Date: Fri, 31 May 2002 14:11:41 -0700 (PDT) Cc: Archie Cobbs , Bosko Milekic , 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: > > It's not clear whether the caller of M_TRAILINGSPACE()/M_LEADINGSPACE() > > is responsible for checking for writability, or the macros themselves. > > It seems to make more sense that the caller would be responsible... > > why would you call M_TRAILINGSPACE() unless you wanted to write > > something in there? > > M_TRAILINGSPACE is called to ask > "How much writable room is there after hte data here? That's the other interpretation :-) > your patch looks better now > I'm wouldering however if any code other than that looks at ext_size Like I said, I did an exhaustive search. The most interesting example is sbdrop(). You can see for yourself.. there aren't that many files: vi `(cd /sys && find . -type f -print | xargs grep -lw ext_size)` -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 Fri May 31 15:57:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [64.186.142.66]) by hub.freebsd.org (Postfix) with ESMTP id 47F8A37B417 for ; Fri, 31 May 2002 15:56:48 -0700 (PDT) Received: by overlord.e-gerbil.net (Postfix, from userid 1000) id A47ED15E47; Fri, 31 May 2002 18:56:42 -0400 (EDT) Date: Fri, 31 May 2002 18:56:42 -0400 From: Richard A Steenbergen To: Andre Oppermann Cc: "Louis A. Mamakos" , Attila Nagy , Luigi Iannone , freebsd-net@FreeBSD.ORG Subject: Re: MPLS Message-ID: <20020531225642.GD385@overlord.e-gerbil.net> References: <200205291413.g4TEDLRG075458@whizzo.transsys.com> <3CF4E483.2510639@pipeline.ch> <200205291522.g4TFMdRG076033@whizzo.transsys.com> <3CF4FCFC.3D760508@pipeline.ch> <20020529180204.GK33611@overlord.e-gerbil.net> <3CF51E7C.E9A47960@pipeline.ch> <20020529233411.GO33611@overlord.e-gerbil.net> <3CF5F4ED.369BCE83@pipeline.ch> <20020530150612.GP33611@overlord.e-gerbil.net> <3CF6436D.ADA51D7F@pipeline.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CF6436D.ADA51D7F@pipeline.ch> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, May 30, 2002 at 05:21:17PM +0200, Andre Oppermann wrote: > > > Please explain how that would not work for servers? > > It would work but not optimal because the packet flow is different for > locally terminated/generated packets. Howso? Both do a routing lookup exactly the same. > > This is a non sequitur. All routes will be available through the kernel > > RIB, but for exact matches only. When is a longest prefix match needed > > there? > > When the routing daemon instructs us to remove the prefix 10.0.0.0/8 > when we also have 10.0.0.0/9 and 10.128.0.0/9. That is not a longest prefix match, this is an exact match. > Where? Do you mean rt_metrics? Yes. -- Richard A Steenbergen http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 31 16:45:10 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 4DA8C37B403 for ; Fri, 31 May 2002 16:45:04 -0700 (PDT) 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 QAA59538; Fri, 31 May 2002 16:38:34 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g4VNbbs03438; Fri, 31 May 2002 16:37:37 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200205312337.g4VNbbs03438@arch20m.dellroad.org> Subject: Re: netgraph documentation? In-Reply-To: <3CF7AD4D.2090801@isi.edu> "from Lars Eggert at May 31, 2002 10:05:17 am" To: Lars Eggert Date: Fri, 31 May 2002 16:37:37 -0700 (PDT) Cc: 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 Lars Eggert writes: > For starters, I was going to modify the UDP tunneling example in the > DaemonNews article to do TCP tunneling. However, I'm having problems > getting the "server" side of the TCP tunnel to listen on the ksocket: > > /usr/sbin/ngctl mkpeer iface dummy inet > /usr/sbin/ngctl mkpeer ng3: ksocket inet inet/stream/tcp > /usr/sbin/ngctl msg ng3:inet bind inet/10.0.0.1:50505 > /usr/sbin/ngctl msg ng3:inet listen 1 > ngctl: send msg: Operation not supported by device > > So I guess I have two questions: > > 1. Is there some other netgraph documentation out > there that I don't knowe about? Not really.. each node has a man page, but the text form of the control messages is not very well documented. > 2. Why can't I listen on a ksocket? What you are doing is correct, I don't know why you are getting that error. The error is coming from solisten(). However, when I try this the listen operation does actually succeed as witnessed by 'netstat -na -f inet'. -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 Fri May 31 17:16:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from ns1.sim.com.tr (ns1.sim.com.tr [212.175.216.1]) by hub.freebsd.org (Postfix) with SMTP id 0419D37B404 for ; Fri, 31 May 2002 17:16:44 -0700 (PDT) Received: (qmail 26842 invoked by uid 503); 1 Jun 2002 00:11:59 -0000 Received: from freebsd@sim.com.tr by mail.sim.com.tr by uid 500 with qmail-scanner-1.12 (uvscan: v4.1.40/v4200. . Clear:. Processed in 0.202671 secs); 01 Jun 2002 00:11:59 -0000 Received: from unknown (HELO erer11bxow260t) (195.174.104.177) by ns1.sim.com.tr with SMTP; 1 Jun 2002 00:11:59 -0000 Message-ID: <009301c20954$bbe84720$b168aec3@erer11bxow260t> From: "Mustafa Erer" To: Subject: Date: Sat, 1 Jun 2002 03:11:45 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0090_01C2091A.0F50D2F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0090_01C2091A.0F50D2F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable auth e09fb9ff subscribe freebsd-net freebsd@sim.com.tr ------=_NextPart_000_0090_01C2091A.0F50D2F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
auth e09fb9ff subscribe freebsd-net freebsd@sim.com.tr
------=_NextPart_000_0090_01C2091A.0F50D2F0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 31 17:57:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 71DF937B403 for ; Fri, 31 May 2002 17:57:50 -0700 (PDT) Received: (qmail 44198 invoked from network); 1 Jun 2002 00:57:28 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 1 Jun 2002 00:57:28 -0000 Message-ID: <3CF81BC5.EAF0ACC@pipeline.ch> Date: Sat, 01 Jun 2002 02:56:37 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Cc: silby@silby.com Subject: Bug in net/route.c function rtredirect() Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi all, I've found another bug in net/route.c in the function rtredirect(). When learning a new gateway from a ICMP redirect icmp_input calls rtredirect() in net/route.c. rtredirect is doing some sanity checks and then creates, if it did not find an existing host route, a new host route tagged with the RTF_DYNAMIC flag. If there was an existing host route it'll simply adjust the gateway and set the RTF_MODIFIED flag. If no pre-existing host route was found either the default route or an network route is being returned by the route table lookup in the beginning. Neither of these should be modified. It should simply add the new host route. The bug is that the jump to "create:" (host route) tries to rtfree() the found default route or network route. If the refcount on those routes is one it frees it, otherwise it decrements it by one. This is wrong. There is no reason to decrement the refcount or to free the routes. The bug is even dangerous when you happen to have many redirects, one too much and you'll loose your default route. The refcount drifts away one decrement more with every valid redirecet received. The solution is to remove the rtfree() in rtredirect. Diff against -STABLE is attached. Should apply to -CURRENT with some fuzz. The bug has been introduced by ru in commit 1.67 "Pull post-4.4BSD change from BSD/OS 4.2". This bug is also present in NetBSD and was introduced there before here (1.67 commit is a copy from NetBSD). I found this by observing a problem on a machine on my network where I have two routers. One is the default router for the machine. Some- times it'll get a redirect to use the second router and then the inconsistencies begun. I only really noticed this problem by using and watching the numbers of the tcp statistics code I posted yesterday (plus route -n monior). This is side-work for an overhaul of the kernel routing table. While being in this area I noticed that host routes created by a redirect never time out and never get removed in a regular fashion. So if you get many of them they clutter the whole routing table. This can become dangerous if you get a lot tcp sessions and your default router is sub-optimal and redirects you all the time to the "real default" router on your network. There can be a redirected route for every host on the Internet. Bad if a new code-red or nimda wave comes by. NetBSD has implemented a purger for the redirect host routes. I'll have a look at it and provide a patch for that for FreeBSD next week. Silby, could you have a look at this patch fixing the rtredirect bug? -- Andre --- route.c.old Fri May 31 21:17:50 2002 +++ route.c Sat Jun 1 02:18:20 2002 @@ -344,8 +344,6 @@ * Create new route, rather than smashing route to net. */ create: - if (rt) - rtfree(rt); flags |= RTF_GATEWAY | RTF_DYNAMIC; bzero((caddr_t)&info, sizeof(info)); info.rti_info[RTAX_DST] = dst; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 31 18: 6:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 52ECF37B40F for ; Fri, 31 May 2002 18:06:34 -0700 (PDT) Received: (qmail 44344 invoked from network); 1 Jun 2002 01:06:13 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 1 Jun 2002 01:06:13 -0000 Message-ID: <3CF81DD2.8D76F8DE@pipeline.ch> Date: Sat, 01 Jun 2002 03:05:22 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Richard A Steenbergen Cc: "Louis A. Mamakos" , Attila Nagy , Luigi Iannone , freebsd-net@FreeBSD.ORG Subject: Re: MPLS References: <200205291413.g4TEDLRG075458@whizzo.transsys.com> <3CF4E483.2510639@pipeline.ch> <200205291522.g4TFMdRG076033@whizzo.transsys.com> <3CF4FCFC.3D760508@pipeline.ch> <20020529180204.GK33611@overlord.e-gerbil.net> <3CF51E7C.E9A47960@pipeline.ch> <20020529233411.GO33611@overlord.e-gerbil.net> <3CF5F4ED.369BCE83@pipeline.ch> <20020530150612.GP33611@overlord.e-gerbil.net> <3CF6436D.ADA51D7F@pipeline.ch> <20020531225642.GD385@overlord.e-gerbil.net> 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 Richard A Steenbergen wrote: > > On Thu, May 30, 2002 at 05:21:17PM +0200, Andre Oppermann wrote: > > > This is a non sequitur. All routes will be available through the kernel > > > RIB, but for exact matches only. When is a longest prefix match needed > > > there? > > > > When the routing daemon instructs us to remove the prefix 10.0.0.0/8 > > when we also have 10.0.0.0/9 and 10.128.0.0/9. > > That is not a longest prefix match, this is an exact match. Ah, well. You're right. > > Where? Do you mean rt_metrics? > > Yes. I'm axing that right now and will provide a tcp_hostcache that will assume that role (tcp is the only consumer of rt_metrics, except for rmx_mtu and rmx_pksent). By moving this every node/leaf in the routing table shrinks by 48 bytes. On a default free view of the Internet this gives us a whopping 5.5 Mbytes in kernel memory savings (110k routes). -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 31 19: 2:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d115.as13.nwbl0.wi.voyager.net [169.207.135.243]) by hub.freebsd.org (Postfix) with ESMTP id C694C37B400 for ; Fri, 31 May 2002 19:02:21 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.3/8.12.3) with ESMTP id g5123bOA026654; Fri, 31 May 2002 21:03:38 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.3/8.12.3/Submit) with ESMTP id g5123ARQ026651; Fri, 31 May 2002 21:03:12 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Fri, 31 May 2002 21:03:10 -0500 (CDT) From: Mike Silbersack To: Andre Oppermann Cc: Richard A Steenbergen , "Louis A. Mamakos" , Attila Nagy , Luigi Iannone , Subject: Re: MPLS In-Reply-To: <3CF81DD2.8D76F8DE@pipeline.ch> Message-ID: <20020531210152.V26528-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 1 Jun 2002, Andre Oppermann wrote: > I'm axing that right now and will provide a tcp_hostcache that will > assume that role (tcp is the only consumer of rt_metrics, except for > rmx_mtu and rmx_pksent). By moving this every node/leaf in the routing > table shrinks by 48 bytes. On a default free view of the Internet this > gives us a whopping 5.5 Mbytes in kernel memory savings (110k routes). > > -- > Andre Hrm. Once you've cut the route metrics out of the route entries, is there anything preventing you from doing away with cloned routes alltogether? :) Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 31 22:32:41 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d115.as13.nwbl0.wi.voyager.net [169.207.135.243]) by hub.freebsd.org (Postfix) with ESMTP id 0BC9437B405 for ; Fri, 31 May 2002 22:32:37 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.3/8.12.3) with ESMTP id g515XtOA027402; Sat, 1 Jun 2002 00:33:55 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.3/8.12.3/Submit) with ESMTP id g515XrEp027399; Sat, 1 Jun 2002 00:33:55 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Sat, 1 Jun 2002 00:33:52 -0500 (CDT) From: Mike Silbersack To: Andre Oppermann Cc: freebsd-net@freebsd.org Subject: Re: Bug in net/route.[ch] with rmx_pksent while cloning In-Reply-To: <3CF761DA.72AE838A@pipeline.ch> Message-ID: <20020601003230.T27367-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 31 May 2002, Andre Oppermann wrote: > I think it will break. Isn't there a compiler warning in net/rtsocket.c > on 64bit platforms about the u_long to int assignment? > > IMO the right solution would to simply axe this field from rt_msghdr. > It serves no purpose. At least none of the base utilites look at it and > I don't see neither gated nor Zebra using it. > > My vote would go to axe it in -CURRENT and bump the version number. Netstat > and route need to be recompiled. Note in UPDATING. Even in -current, that's an annoying step to take. What I'm thinking of doing is renaming the field to rt_unused with a comment indicating that it should be axed if anyone else has a good reason to change the structure. I'll look over your latest round of patches tomorrow. They're a bit more in depth, I can't evaluate them in 5 minutes. :) Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 1 2:45:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from web11206.mail.yahoo.com (web11206.mail.yahoo.com [216.136.131.188]) by hub.freebsd.org (Postfix) with SMTP id 65F7437B407 for ; Sat, 1 Jun 2002 02:45:39 -0700 (PDT) Message-ID: <20020601094539.21670.qmail@web11206.mail.yahoo.com> Received: from [212.105.11.207] by web11206.mail.yahoo.com via HTTP; Sat, 01 Jun 2002 11:45:39 CEST Date: Sat, 1 Jun 2002 11:45:39 +0200 (CEST) From: =?iso-8859-1?q?Johan=20Petersson?= Subject: Duplex problem with Etherlink XL (3c900B) and xl driver. To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi everyone, I'm having problems getting FreeBSD to use full duplex with my 3com Etherlink XL card. The NIC is connected to a 10/100 switch and during power up and boot the full duplex LED on the switch is on, until the probing of the NIC (using xl driver). Then the LED goes out indicating half duplex mode. When I boot DOS the LED stays on all the time. Trying to force full duplex with ifconfig does not seem to work. There is no error message, but the LED remains off and instead network thruput falls to about 30 kbit/s... I have tried both auto (NWAY) and manual settings of the card using a 3com DOS utility, but no change. Relevant (?) lines from dmesg (boot -v): xl0: <3Com 3c900B-COMBO Etherlink XL> port 0x4000-0x407f mem 0x60000000-0x600000 7f irq 10 at device 15.0 on pci0 xl0: Ethernet address: 00:50:04:22:a1:a2 xl0: media options word: 38 xl0: guessing COMBO (AUI/BNC/TP) xl0: found 10baseT xl0: found AUI xl0: found BNC xl0: selecting 10baseT transceiver, half duplex "ifconfig xl0" gives me: xl0: flags=8843 mtu 1500 inet 192.168.1.254 netmask 0xffffff00 broadcast 192.168.1.255 ether 00:50:04:22:a1:a2 media: Ethernet 10baseT/UTP (10baseT/UTP ) Finally, "uname -a": FreeBSD hawk.sigtuna.lan 4.4-RELEASE FreeBSD 4.4-RELEASE #4: Fri May 31 13:01:43 CEST 2002 johan@falcon.sigtuna.lan:/usr/src/sys/compile/HAWK i386 The computer is an old IBM PC Pentium 133. Does anyone have any ideas how to enable full duplex under FreeBSD? Regards Johan Petersson _____________________________________________________ Följ VM på nära håll på Yahoo!s officielle VM-sajt www.yahoo.se/vm2002 Håll dig ajour med nyheter och resultat, med vinnare och förlorare... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 1 2:45:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id ACF5E37B409 for ; Sat, 1 Jun 2002 02:45:45 -0700 (PDT) Received: (qmail 56575 invoked from network); 1 Jun 2002 09:45:22 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 1 Jun 2002 09:45:22 -0000 Message-ID: <3CF89780.CBA9E2E@pipeline.ch> Date: Sat, 01 Jun 2002 11:44:32 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack Cc: Richard A Steenbergen , "Louis A. Mamakos" , Attila Nagy , Luigi Iannone , freebsd-net@FreeBSD.ORG Subject: Re: MPLS References: <20020531210152.V26528-100000@patrocles.silby.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Mike Silbersack wrote: > > On Sat, 1 Jun 2002, Andre Oppermann wrote: > > > I'm axing that right now and will provide a tcp_hostcache that will > > assume that role (tcp is the only consumer of rt_metrics, except for > > rmx_mtu and rmx_pksent). By moving this every node/leaf in the routing > > table shrinks by 48 bytes. On a default free view of the Internet this > > gives us a whopping 5.5 Mbytes in kernel memory savings (110k routes). > > > > -- > > Andre > > Hrm. Once you've cut the route metrics out of the route entries, is there > anything preventing you from doing away with cloned routes alltogether? :) No. It will go as well. Actually, it will not go in the first step but wont be used anymore. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 1 2:57:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 63DDF37B404 for ; Sat, 1 Jun 2002 02:57:20 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g519v7t57425; Sat, 1 Jun 2002 12:57:07 +0300 (EEST) (envelope-from ru) Date: Sat, 1 Jun 2002 12:57:07 +0300 From: Ruslan Ermilov To: Andre Oppermann Cc: freebsd-net@FreeBSD.ORG, silby@silby.com Subject: Re: Bug in net/route.c function rtredirect() Message-ID: <20020601095707.GC50435@sunbay.com> References: <3CF81BC5.EAF0ACC@pipeline.ch> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eHhjakXzOLJAF9wJ" Content-Disposition: inline In-Reply-To: <3CF81BC5.EAF0ACC@pipeline.ch> User-Agent: Mutt/1.3.99i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --eHhjakXzOLJAF9wJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 01, 2002 at 02:56:37AM +0200, Andre Oppermann wrote: > Hi all, >=20 > I've found another bug in net/route.c in the function rtredirect(). >=20 > When learning a new gateway from a ICMP redirect icmp_input calls > rtredirect() in net/route.c. rtredirect is doing some sanity checks > and then creates, if it did not find an existing host route, a new > host route tagged with the RTF_DYNAMIC flag. If there was an existing > host route it'll simply adjust the gateway and set the RTF_MODIFIED > flag. >=20 OK. > If no pre-existing host route was found either the default route or > an network route is being returned by the route table lookup in the > beginning. Neither of these should be modified. It should simply add > the new host route. >=20 This route lookup also increments rt_refcnt. > The bug is that the jump to "create:" (host route) tries to rtfree() > the found default route or network route. If the refcount on those > routes is one it frees it, otherwise it decrements it by one. This is > wrong. There is no reason to decrement the refcount or to free the > routes. The bug is even dangerous when you happen to have many > redirects, one too much and you'll loose your default route. The > refcount drifts away one decrement more with every valid redirecet > received. >=20 There _is_ the reason to decrement the refcount, because nothing is going to point to it after we modify it, and if we don't decrement it, this will create an "unremovable" route. > The solution is to remove the rtfree() in rtredirect. Diff against > -STABLE is attached. Should apply to -CURRENT with some fuzz. >=20 No, please try the below patch instead. > The bug has been introduced by ru in commit 1.67 "Pull post-4.4BSD > change from BSD/OS 4.2". This bug is also present in NetBSD and was > introduced there before here (1.67 commit is a copy from NetBSD). >=20 Why you're not mailing me then? The bug was introduced first in BSD/OS, FWIW. > I found this by observing a problem on a machine on my network where > I have two routers. One is the default router for the machine. Some- > times it'll get a redirect to use the second router and then the > inconsistencies begun. I only really noticed this problem by using > and watching the numbers of the tcp statistics code I posted yesterday > (plus route -n monior). This is side-work for an overhaul of the > kernel routing table. >=20 I will see if I can reproduce this, on Monday. > While being in this area I noticed that host routes created by a > redirect never time out and never get removed in a regular fashion. > So if you get many of them they clutter the whole routing table. This > can become dangerous if you get a lot tcp sessions and your default > router is sub-optimal and redirects you all the time to the "real > default" router on your network. There can be a redirected route for > every host on the Internet. Bad if a new code-red or nimda wave comes > by. NetBSD has implemented a purger for the redirect host routes. > I'll have a look at it and provide a patch for that for FreeBSD next > week. >=20 Nice catch. Please try this patch, it's believed to fix both problems. It is completely untested: %%% Index: route.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/net/route.c,v retrieving revision 1.69 diff -u -p -r1.69 route.c --- route.c 19 Mar 2002 21:54:18 -0000 1.69 +++ route.c 1 Jun 2002 09:56:11 -0000 @@ -345,7 +345,7 @@ rtredirect(dst, gateway, netmask, flags, */ create: if (rt) - rtfree(rt); + rt->rt_refcnt--; flags |=3D RTF_GATEWAY | RTF_DYNAMIC; bzero((caddr_t)&info, sizeof(info)); info.rti_info[RTAX_DST] =3D dst; @@ -355,8 +355,10 @@ rtredirect(dst, gateway, netmask, flags, info.rti_flags =3D flags; rt =3D NULL; error =3D rtrequest1(RTM_ADD, &info, &rt); - if (rt !=3D NULL) + if (rt !=3D NULL) { + rt->rt_refcnt--; flags =3D rt->rt_flags; + } stat =3D &rtstat.rts_dynamic; } else { /* %%% Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --eHhjakXzOLJAF9wJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE8+JpzUkv4P6juNwoRAvxJAJ9jhqZ2QsDSOUyYMvlaScKy84YSLgCeJWIy ZXOHZrt6xuNxpq4TGEdGkeY= =Ngt3 -----END PGP SIGNATURE----- --eHhjakXzOLJAF9wJ-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 1 3:51:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 2C74937B405 for ; Sat, 1 Jun 2002 03:51:04 -0700 (PDT) Received: (qmail 58573 invoked from network); 1 Jun 2002 10:50:41 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 1 Jun 2002 10:50:41 -0000 Message-ID: <3CF8A6CF.6033679A@pipeline.ch> Date: Sat, 01 Jun 2002 12:49:51 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ruslan Ermilov Cc: freebsd-net@FreeBSD.ORG, silby@silby.com Subject: Re: Bug in net/route.c function rtredirect() References: <3CF81BC5.EAF0ACC@pipeline.ch> <20020601095707.GC50435@sunbay.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Ruslan Ermilov wrote: > > On Sat, Jun 01, 2002 at 02:56:37AM +0200, Andre Oppermann wrote: > > Hi all, > > > > I've found another bug in net/route.c in the function rtredirect(). > > > > When learning a new gateway from a ICMP redirect icmp_input calls > > rtredirect() in net/route.c. rtredirect is doing some sanity checks > > and then creates, if it did not find an existing host route, a new > > host route tagged with the RTF_DYNAMIC flag. If there was an existing > > host route it'll simply adjust the gateway and set the RTF_MODIFIED > > flag. > > > OK. > > > If no pre-existing host route was found either the default route or > > an network route is being returned by the route table lookup in the > > beginning. Neither of these should be modified. It should simply add > > the new host route. > > > This route lookup also increments rt_refcnt. Yes. > > The bug is that the jump to "create:" (host route) tries to rtfree() > > the found default route or network route. If the refcount on those > > routes is one it frees it, otherwise it decrements it by one. This is > > wrong. There is no reason to decrement the refcount or to free the > > routes. The bug is even dangerous when you happen to have many > > redirects, one too much and you'll loose your default route. The > > refcount drifts away one decrement more with every valid redirecet > > received. > > > There _is_ the reason to decrement the refcount, because nothing is > going to point to it after we modify it, and if we don't decrement > it, this will create an "unremovable" route. You're right but the refcount decrementation will be done, just in a different place. In the "done:" section the rtfree() will be done also in the case when an existing host route was already present. > > The solution is to remove the rtfree() in rtredirect. Diff against > > -STABLE is attached. Should apply to -CURRENT with some fuzz. > > > No, please try the below patch instead. The rtfree() I removed is one too many and still has to go. Your patch doesn't change the problem, it just makes it different. Routes could go below zero refcount in your version. > > The bug has been introduced by ru in commit 1.67 "Pull post-4.4BSD > > change from BSD/OS 4.2". This bug is also present in NetBSD and was > > introduced there before here (1.67 commit is a copy from NetBSD). > > > Why you're not mailing me then? The bug was introduced first in > BSD/OS, FWIW. Sorry, Silby fixed the previous bug so I sent this to him again. > > I found this by observing a problem on a machine on my network where > > I have two routers. One is the default router for the machine. Some- > > times it'll get a redirect to use the second router and then the > > inconsistencies begun. I only really noticed this problem by using > > and watching the numbers of the tcp statistics code I posted yesterday > > (plus route -n monior). This is side-work for an overhaul of the > > kernel routing table. > > > I will see if I can reproduce this, on Monday. > > > While being in this area I noticed that host routes created by a > > redirect never time out and never get removed in a regular fashion. > > So if you get many of them they clutter the whole routing table. This > > can become dangerous if you get a lot tcp sessions and your default > > router is sub-optimal and redirects you all the time to the "real > > default" router on your network. There can be a redirected route for > > every host on the Internet. Bad if a new code-red or nimda wave comes > > by. NetBSD has implemented a purger for the redirect host routes. > > I'll have a look at it and provide a patch for that for FreeBSD next > > week. > > > Nice catch. > > Please try this patch, it's believed to fix both problems. It is > completely untested: I fail to see how you purge the redirect host routes. Actually, at the moment I have got some problems following the very twisted logic of all this... ;-) Lets have another look on monday. Anyway, patch attached which I think (at the moment) would be correct. -- Andre --- route.c.old Fri May 31 21:17:50 2002 +++ route.c Sat Jun 1 12:34:33 2002 @@ -299,7 +299,7 @@ int flags; struct rtentry **rtp; { - struct rtentry *rt; + struct rtentry *rt, *rtn; int error = 0; short *stat = 0; struct rt_addrinfo info; @@ -344,8 +344,6 @@ * Create new route, rather than smashing route to net. */ create: - if (rt) - rtfree(rt); flags |= RTF_GATEWAY | RTF_DYNAMIC; bzero((caddr_t)&info, sizeof(info)); info.rti_info[RTAX_DST] = dst; @@ -353,10 +351,10 @@ info.rti_info[RTAX_NETMASK] = netmask; info.rti_ifa = ifa; info.rti_flags = flags; - rt = NULL; - error = rtrequest1(RTM_ADD, &info, &rt); - if (rt != NULL) - flags = rt->rt_flags; + rtn = NULL; + error = rtrequest1(RTM_ADD, &info, &rtn); + if (rtn != NULL) + flags = rtn->rt_flags; stat = &rtstat.rts_dynamic; } else { /* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 1 4:35:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 6A7A937B409 for ; Sat, 1 Jun 2002 04:35:47 -0700 (PDT) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 1 Jun 2002 12:35:44 +0100 (BST) Date: Sat, 1 Jun 2002 12:35:39 +0100 From: David Malone To: Archie Cobbs Cc: Julian Elischer , Bosko Milekic , freebsd-net@FreeBSD.ORG Subject: Re: m_split() considered harmful Message-ID: <20020601113539.GA45658@walton.maths.tcd.ie> References: <200205312025.g4VKP9t02205@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200205312025.g4VKP9t02205@arch20m.dellroad.org> User-Agent: Mutt/1.3.25i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, May 31, 2002 at 01:25:09PM -0700, Archie Cobbs wrote: > As a temporary saftey measure, I'll add M_WRITABLE(m) into the > M_TRAILINGSPACE() macro. However, I see this as a temporary hack; > the correct fix is to put the burden of writability on the caller. > After all, M_TRAILINGSPACE() doesn't modify the mbuf data! I think adding the M_WRITABLE check to M_TRAILINGSPACE is probably the right thing to do, unless the cost of the extra M_WRITABLE checks is likely to be significant. I believe the only reason we didn't add it when we did the M_WRITABLE code originally was to preserve the previous behaviour of M_TRAILINGSPACE. I think it was Ian that pointed out that there is no reason to call M_{LEAD,TRAIL}INGSPACE unless you are going to write into the mbuf's storage. This means the question of where to check writability is just a trade off between efficiency and ease of use. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 1 7:48:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 53ABD37B406 for ; Sat, 1 Jun 2002 07:48:35 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id AAA20111; Sun, 2 Jun 2002 00:48:22 +1000 Date: Sun, 2 Jun 2002 00:51:56 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Archie Cobbs Cc: Julian Elischer , Bosko Milekic , Subject: Re: m_split() considered harmful In-Reply-To: <200205312025.g4VKP9t02205@arch20m.dellroad.org> Message-ID: <20020602004417.H2786-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 31 May 2002, Archie Cobbs wrote: > That is, what we really need is a more general audit for code that > writes into mbufs that might be read-only -- and, as one special case > of tha, code that calls M_TRAILINGSPACE()/M_LEADINGSPACE() before writing > into an mbuf. > > FYI, any easy way to do this would be to add const'ness to mtod(): > > #define mtod(m, t) ((const t)((m)->m_data)) > > and then look for GCC warnings. Any takers?? :-) This assumes that t is literally a pointer. When t is caddr_t, `const t' is a const variable which (if caddr_t is `char *') is a pointer to non-const storage, but you want a non-const pointer to const storage. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 1 8: 7:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from pipenetworks.com (cartman.pipenetworks.com [202.4.251.18]) by hub.freebsd.org (Postfix) with ESMTP id 6CB7F37B40B for ; Sat, 1 Jun 2002 08:07:36 -0700 (PDT) Received: from internal.pipenetworks.com (internal.pipenetworks.com [10.10.10.1]) by pipenetworks.com (8.11.2/8.11.2) with ESMTP id g51F4oE11797; Sun, 2 Jun 2002 01:04:50 +1000 Date: Sun, 2 Jun 2002 01:07:35 +1000 (EST) From: To: Cc: , Subject: bridge code, tap or vtun issue on freebsd 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 Hello, I have found a bug in using vtun on freebsd in the type ether mode in order to try and bridge ethernet over IP. I am not too sure where the problem lies. The interfaces that are being placed into the bridge group are not going into promiscuos mode. The crux of it that the vtun can establish but no frames can get through the bridge unless I do something really ugly to turn on promiscuous mode : (cat > /dev/tap1 | head -c 1 ; then clean up the net.link.ether.bridge_cfg oid back to normal again) Both machines are i386 4.5-RELEASE FreeBSD The "up" section of the vtund.conf looks like : up { ifconfig "%% inet 10.12.12.240 netmask 255.255.255.0"; #ifconfig "%% up"; program "/sbin/sysctl net.link.ether.bridge=0" wait ; program "/sbin/sysctl net.link.ether.bridge_cfg=\"\"" wait ; program "/sbin/sysctl net.link.ether.bridge_cfg=\"sis0:5,%%:5\"" wait ; program "/sbin/sysctl net.link.ether.bridge=1" wait ; }; That seems to be working as you can see from the server and cleint dumps below but I do not think that the bridge or tap code is putting the ethernet interface and tap device into promiscuous mode. From fresh boot for box acting as vtun server ============================================= bash# ifconfig -a sis0: flags=8843 mtu 1500 inet6 fe80::2a0:ccff:fe79:2a06%sis0 prefixlen 64 scopeid 0x1 ether 00:a0:cc:79:2a:06 media: Ethernet autoselect (10baseT/UTP) status: active rl0: flags=8843 mtu 1500 inet 10.11.11.100 netmask 0xffffff00 broadcast 10.11.11.255 inet6 fe80::210:dcff:fe20:d53e%rl0 prefixlen 64 scopeid 0x2 ether 00:10:dc:20:d5:3e media: Ethernet autoselect (100baseTX ) status: active lp0: flags=8810 mtu 1500 faith0: flags=8002 mtu 1500 lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet 127.0.0.1 netmask 0xff000000 ppp0: flags=8010 mtu 1500 sl0: flags=c010 mtu 552 bash# vtund -s -f /usr/local/etc/vtund.conf bash# ps ax PID TT STAT TIME COMMAND 0 ?? DLs 0:00.00 (swapper) 1 ?? SLs 0:00.01 /sbin/init -- 2 ?? DL 0:00.00 (pagedaemon) 3 ?? DL 0:00.00 (vmdaemon) 4 ?? DL 0:00.00 (bufdaemon) 5 ?? DL 0:00.00 (syncer) 6 ?? DL 0:00.00 (vnlru) 23 ?? Is 0:00.00 adjkerntz -i 62 ?? Ss 0:00.03 /usr/sbin/syslogd -s 69 ?? Is 0:00.00 /usr/sbin/inetd -wW 71 ?? Ss 0:00.00 /usr/sbin/cron 73 ?? Is 0:00.18 /usr/sbin/sshd 94 ?? S 0:00.05 sshd: root@ttyp0 (sshd) 98 ?? Ss 0:00.00 vtund: waiting for connections on port 5000 (vtund) 95 p0 Ss 0:00.03 -bash (bash) 99 p0 R+ 0:00.00 ps ax 86 v0 Is+ 0:00.01 /usr/libexec/getty Pc ttyv0 87 v1 Is+ 0:00.00 /usr/libexec/getty Pc ttyv1 88 v2 Is+ 0:00.00 /usr/libexec/getty Pc ttyv2 89 v3 Is+ 0:00.00 /usr/libexec/getty Pc ttyv3 90 v4 Is+ 0:00.00 /usr/libexec/getty Pc ttyv4 91 v5 Is+ 0:00.00 /usr/libexec/getty Pc ttyv5 92 v6 Is+ 0:00.00 /usr/libexec/getty Pc ttyv6 93 v7 Is+ 0:00.00 /usr/libexec/getty Pc ttyv7 bash# !sys:p sysctl -a | grep bridge bash# sysctl -a | grep bridge net.link.ether.bridge_cfg: sis0:1,rl0:1, net.link.ether.bridge: 0 net.link.ether.bridge_ipfw: 0 net.link.ether.bridge_ipfw_drop: 0 net.link.ether.bridge_ipfw_collisions: 0 [THIS IS WHEN THE CLIENT CONNECTS] bash# Jun 2 00:47:25 stan /kernel: BRIDGE 011031, have 8 interfaces Jun 2 00:47:25 stan /kernel: BRIDGE 011031, have 8 interfaces Jun 2 00:47:25 stan /kernel: -- index 1 sis0:1 type 6 phy 0 addrl 6 addr 00.a0.cc.79.2a.06 Jun 2 00:47:25 stan /kernel: -- index 1 sis0:1 type 6 phy 0 addrl 6 addr 00.a0.cc.79.2a.06 Jun 2 00:47:25 stan /kernel: -- index 2 rl0:1 type 6 phy 0 addrl 6 addr 00.10.dc.20.d5.3e Jun 2 00:47:25 stan /kernel: -- index 2 rl0:1 type 6 phy 0 addrl 6 addr 00.10.dc.20.d5.3e Jun 2 00:47:25 stan /kernel: -- index 8 type 6 phy 0 addrl 6 addr 00.bd.fa.13.00.00 Jun 2 00:47:25 stan /kernel: -- index 8 type 6 phy 0 addrl 6 addr 00.bd.fa.13.00.00 bash# sysctl -a | grep bridge net.link.ether.bridge_cfg: "sis0:5,tap0:5" net.link.ether.bridge: 1 net.link.ether.bridge_ipfw: 0 net.link.ether.bridge_ipfw_drop: 0 net.link.ether.bridge_ipfw_collisions: 0 Fresh from boot for box acting as vtun client ============================================= bash-2.05a# sysctl -a | grep bridge net.link.ether.bridge_cfg: sis0:1,rl0:1, net.link.ether.bridge: 0 net.link.ether.bridge_ipfw: 0 net.link.ether.bridge_ipfw_drop: 0 net.link.ether.bridge_ipfw_collisions: 0 bash-2.05a# ifconfig -a sis0: flags=8843 mtu 1500 inet6 fe80::2a0:ccff:fe77:d6f%sis0 prefixlen 64 scopeid 0x1 ether 00:a0:cc:77:0d:6f media: Ethernet autoselect (100baseTX ) status: active rl0: flags=8843 mtu 1500 inet 10.11.11.200 netmask 0xffffff00 broadcast 10.11.11.255 inet6 fe80::210:dcff:fe20:d59d%rl0 prefixlen 64 scopeid 0x2 ether 00:10:dc:20:d5:9d media: Ethernet autoselect (100baseTX ) status: active lp0: flags=8810 mtu 1500 faith0: flags=8002 mtu 1500 lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet 127.0.0.1 netmask 0xff000000 ppp0: flags=8010 mtu 1500 sl0: flags=c010 mtu 552 bash-2.05a# vtund -f /usr/local/etc/vtund.conf wc 10.11.11.100 bash-2.05a# Jun 2 00:47:25 kenny /kernel: BRIDGE 011031, have 8 interfaces Jun 2 00:47:25 kenny /kernel: BRIDGE 011031, have 8 interfaces Jun 2 00:47:25 kenny /kernel: -- index 1 sis0:1 type 6 phy 0 addrl 6 addr 00.a0.cc.77.0d.6f Jun 2 00:47:25 kenny /kernel: -- index 1 sis0:1 type 6 phy 0 addrl 6 addr 00.a0.cc.77.0d.6f Jun 2 00:47:25 kenny /kernel: -- index 2 rl0:1 type 6 phy 0 addrl 6 addr 00.10.dc.20.d5.9d Jun 2 00:47:25 kenny /kernel: -- index 2 rl0:1 type 6 phy 0 addrl 6 addr 00.10.dc.20.d5.9d Jun 2 00:47:25 kenny /kernel: -- index 8 type 6 phy 0 addrl 6 addr 00.bd.dd.19.00.00 Jun 2 00:47:25 kenny /kernel: -- index 8 type 6 phy 0 addrl 6 addr 00.bd.dd.19.00.00 bash-2.05a# sysctl -a | grep bridge net.link.ether.bridge_cfg: "sis0:5,tap0:5" net.link.ether.bridge: 1 net.link.ether.bridge_ipfw: 0 net.link.ether.bridge_ipfw_drop: 0 net.link.ether.bridge_ipfw_collisions: 0 bash-2.05a# ifconfig -a sis0: flags=8843 mtu 1500 inet6 fe80::2a0:ccff:fe77:d6f%sis0 prefixlen 64 scopeid 0x1 ether 00:a0:cc:77:0d:6f media: Ethernet autoselect (100baseTX ) status: active rl0: flags=8843 mtu 1500 inet 10.11.11.200 netmask 0xffffff00 broadcast 10.11.11.255 inet6 fe80::210:dcff:fe20:d59d%rl0 prefixlen 64 scopeid 0x2 ether 00:10:dc:20:d5:9d media: Ethernet autoselect (100baseTX ) status: active lp0: flags=8810 mtu 1500 faith0: flags=8002 mtu 1500 lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet 127.0.0.1 netmask 0xff000000 ppp0: flags=8010 mtu 1500 sl0: flags=c010 mtu 552 tap0: flags=8843 mtu 1500 inet 10.12.12.240 netmask 0xffffff00 broadcast 10.12.12.255 inet6 fe80::2bd:ddff:fe19:0%tap0 prefixlen 64 scopeid 0x8 ether 00:bd:dd:19:00:00 Opened by PID 98 bash-2.05a# To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 1 10:41:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 0739537B408 for ; Sat, 1 Jun 2002 10:41:23 -0700 (PDT) Received: from isi.edu (hcm21nobzjbdm1rv@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g51Hf7e14906; Sat, 1 Jun 2002 10:41:07 -0700 (PDT) Message-ID: <3CF90731.7060504@isi.edu> Date: Sat, 01 Jun 2002 10:41:05 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: steve@pipenetworks.com Cc: m_evmenkin@yahoo.com, freebsd-net@freebsd.org, maxk@qualcomm.com Subject: Re: bridge code, tap or vtun issue on freebsd References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020106050405000902030809" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms020106050405000902030809 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit steve@pipenetworks.com wrote: > I have found a bug in using vtun on freebsd in the type ether mode > in order to try and bridge ethernet over IP. I am not too sure where > the problem lies. The interfaces that are being placed into the > bridge group are not going into promiscuos mode. This may not be directly relevant, but vtun also has other problems for non-IPv4 traffic, because it doesn't put the tun decive into "multi-AF" mode. I've submitted patches (see the vtun SourceForge site), but haven't heard back from the author so far. I'm looking into replacing vtun with netgraph, which handles this (I hope, still evaluating), and should also have the additional benefit of being an in-kernel mechanism, thus saving two user/kernelmode switches per packet. Maybe netgraph might work for you, too. Lars -- Lars Eggert USC Information Sciences Institute --------------ms020106050405000902030809 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDYwMTE3NDEwNlowIwYJKoZIhvcNAQkEMRYEFJ4oZzpVqwa8 Xij6+Bo6HbKTrKtyMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYCReux52+Oxuo/dOM4ag/h+IkUGOiK1xnVXfsczAvI4S/Es D1bzcKGGhOxXyAd24Kk6ZmSUeW41wmp1ao8RGL9AOwQr/33LkyJSRrzAX4shcmmAgcY5M+SO /A58F74NHjiJkOR/CWbuOOlYrpivoOy5QnERDG68xaafvAKTq0zvpQAAAAAAAA== --------------ms020106050405000902030809-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 1 11:13:24 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 C50C137B409 for ; Sat, 1 Jun 2002 11:13:16 -0700 (PDT) Received: (qmail 17878 invoked by uid 1005); 1 Jun 2002 18:13:12 -0000 Received: from misho@interbgc.com by keeper.interbgc.com with qmail-scanner-1.01 (uvscan: v4.0.50/v4205. . Clean. Processed in 0.308482 secs); 01 Jun 2002 18:13:12 -0000 Received: from unknown (HELO misho) (217.9.226.238) by mail.interbgc.com with SMTP; 1 Jun 2002 18:13:11 -0000 Message-ID: <003501c20997$b453d5e0$eee209d9@interbgc.com> Reply-To: "Mihail Balikov" From: "Mihail Balikov" To: Subject: bpf direction Date: Sat, 1 Jun 2002 21:11:08 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, is there any way to find what is the direction (incomming / outgoing) of bpf captured packet?? regards, misho To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 1 14: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 0181737B401 for ; Sat, 1 Jun 2002 14:15:03 -0700 (PDT) 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 OAA65988; Sat, 1 Jun 2002 14:09:41 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g51L8f608736; Sat, 1 Jun 2002 14:08:41 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200206012108.g51L8f608736@arch20m.dellroad.org> Subject: Re: m_split() considered harmful In-Reply-To: <20020602004417.H2786-100000@gamplex.bde.org> "from Bruce Evans at Jun 2, 2002 00:51:56 am" To: Bruce Evans Date: Sat, 1 Jun 2002 14:08:41 -0700 (PDT) Cc: Archie Cobbs , Julian Elischer , Bosko Milekic , 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 Bruce Evans writes: > > That is, what we really need is a more general audit for code that > > writes into mbufs that might be read-only -- and, as one special case > > of tha, code that calls M_TRAILINGSPACE()/M_LEADINGSPACE() before writing > > into an mbuf. > > > > FYI, any easy way to do this would be to add const'ness to mtod(): > > > > #define mtod(m, t) ((const t)((m)->m_data)) > > > > and then look for GCC warnings. Any takers?? :-) > > This assumes that t is literally a pointer. When t is caddr_t, > `const t' is a const variable which (if caddr_t is `char *') is a > pointer to non-const storage, but you want a non-const pointer to > const storage. Yep, you are right about that case... (as usual :-) -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