From owner-netdev@oss.sgi.com Sun Feb 3 23:43:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g147hYk20686 for netdev-outgoing; Sun, 3 Feb 2002 23:43:34 -0800 Received: from hotmail.com (f222.law15.hotmail.com [64.4.23.222]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g147hWA20655 for ; Sun, 3 Feb 2002 23:43:32 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 3 Feb 2002 22:43:24 -0800 Received: from 165.213.0.2 by lw15fd.law15.hotmail.msn.com with HTTP; Mon, 04 Feb 2002 06:43:23 GMT X-Originating-IP: [165.213.0.2] From: "Sampada Joshi" To: netdev@oss.sgi.com Subject: Help regarding FIB Date: Mon, 04 Feb 2002 06:43:23 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Feb 2002 06:43:24.0632 (UTC) FILETIME=[3E85BD80:01C1AD47] Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello I am new to linux code and trying to understand the implementation of IP within the kernel. I am unable to understand the reason behind the following definition in the FIB organization (fib_table) - struct fn_zone *fn_zones[33] (why 33?) Can someone please help me? Thanks in advance Sampada _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-netdev@oss.sgi.com Mon Feb 4 02:31:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14AVJr23076 for netdev-outgoing; Mon, 4 Feb 2002 02:31:19 -0800 Received: from l.himel.bg (IDENT:root@unamed.infotel.bg [212.39.68.18] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14AV7A22916 for ; Mon, 4 Feb 2002 02:31:09 -0800 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 LAA02109; Mon, 4 Feb 2002 11:30:16 +0200 Date: Mon, 4 Feb 2002 11:30:16 +0200 (EET) From: Julian Anastasov X-X-Sender: ja@l To: Sampada Joshi cc: netdev@oss.sgi.com Subject: Re: Help regarding FIB In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello, On Mon, 4 Feb 2002, Sampada Joshi wrote: > I am unable to understand the reason behind the following definition in the > FIB organization (fib_table) - > struct fn_zone *fn_zones[33] (why 33?) netmask 255.255.255.255 (/32) ... netmask 0.0.0.0 (/0) 0..32 are 33 values > Can someone please help me? > Thanks in advance > Sampada Regards -- Julian Anastasov From owner-netdev@oss.sgi.com Mon Feb 4 07:34:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14FYFt01937 for netdev-outgoing; Mon, 4 Feb 2002 07:34:15 -0800 Received: from nero.doit.wisc.edu (nero.doit.wisc.edu [128.104.17.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14FYBA01886 for ; Mon, 4 Feb 2002 07:34:12 -0800 Received: (from jleu@localhost) by nero.doit.wisc.edu (8.9.3/8.9.3) id KAA12583; Mon, 4 Feb 2002 10:27:03 -0600 Date: Mon, 4 Feb 2002 10:27:03 -0600 From: "James R. Leu" To: Sampada Joshi Cc: netdev@oss.sgi.com Subject: Re: Help regarding FIB Message-ID: <20020204102702.A12579@nero.doit.wisc.edu> Reply-To: jleu@mindspring.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from sampada_joshi@hotmail.com on Mon, Feb 04, 2002 at 06:43:23AM +0000 Organization: none Sender: owner-netdev@oss.sgi.com Precedence: bulk On Mon, Feb 04, 2002 at 06:43:23AM +0000, Sampada Joshi wrote: > Hello > I am new to linux code and trying to understand the implementation of IP > within the kernel. > I am unable to understand the reason behind the following definition in the > FIB organization (fib_table) - > struct fn_zone *fn_zones[33] (why 33?) Bit length of netmasks I'd assume (0 - 32) > Can someone please help me? > Thanks in advance > Sampada > > > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com -- James R. Leu From owner-netdev@oss.sgi.com Mon Feb 4 13:05:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14L5U704779 for netdev-outgoing; Mon, 4 Feb 2002 13:05:30 -0800 Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14L56A04357 for ; Mon, 4 Feb 2002 13:05:08 -0800 Received: (qmail 1025893 invoked from network); 4 Feb 2002 14:05:04 -0700 Received: from snaresland.acl.lanl.gov (128.165.147.113) by acl.lanl.gov with SMTP; 4 Feb 2002 14:05:04 -0700 Received: (qmail 4854 invoked by uid 3499); 4 Feb 2002 14:05:04 -0700 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 4 Feb 2002 14:05:04 -0700 Date: Mon, 4 Feb 2002 14:05:04 -0700 (MST) From: Ronald G Minnich X-X-Sender: To: Alexey Kuznetsov , , cc: "Erik A. Hendriks" , Matthew J Sottile Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello, we just stumbled across this discussion as part of a search on a problem we are having. We have a monitor called Supermon. It allows us to pull status data out of the kernel at 5100 Hz. It includes a server tool which allows processes to connect via TCP and read the status data. We wrote it up in ALS 2001 if you want to see the paper, or: http://www.acl.lanl.gov/supermon/, see the paper at the bottom. Our goal is to have remote processes read the data over a TCP connection at somewhere between 100 and 500 hz., depending on the requirements. The tcp delayed ack support in Linux is killing us. Our maximum sample rate is 25 hz. It is so slow, in fact, that we may have to return to UDP, which we hate to think about doing. To recap, nivedita proposed a TCP_DELACK sockopt to allow users to completely disabled delayed acks. Alexey thought this a bad idea. We're not convinced it is a bad idea, and it has a lot of attraction for us. Alexey's comments are plain, and my comments in <<<>>> Further comments welcome. I don't subscribe to netdev, however, so if you want to include me please cc: me. ron --- In-Reply-To: <200108280207.f7S275J18467@eng4.beaverton.ibm.com> from "Nivedita Singhvi" at Aug 28, 1 06:15:02 am Sender: owner-netdev@oss.sgi.com Well, actually, I have one question: how is application supposed to determine, when it is in this "certain environment"? <<< It's easy for us. We run, see 25 hz. sample rates, and know that we have determined the need to turn OFF delayed acks. Another consideration for you: what happens if NFS ever runs over TCP in this environment. 25 hz. packet rates are really a bad thing. NFS running under delack constraints could limit NFS performance to 25*8192 bytes/second. What should NFS do to fix this? >>> I see no way, but already implemented in tcp. In any case, if you can propose another way to guess, when delayed acks harm performance, it should be added to set of heuristics. <<< I think heuristics are nice, but you can take them too far. Heuristics are not a universal solution to every problem. TCP heuristics are causing us a great deal of grief. I'd like to be able to tell the kernel what to do in some circumstances. >>>> Actually, opposite option would make sense, 2.4 really generates too much of acks in some curcumstances. :-) <<< which is OK for some environments; what's bad is low packet rates. >>> I would rather expect that applications using this funny option are to be repaired not to use it. <<< Not always true. Sometimes, the app has a good reason to need this option. >>> You can obtain required effect blocking setting tp->ack.pingpong. tp->ack.pingpong frozen at zero gives maximal reasonable ack frequency. <<< the pingpong setting seems more like a hack to me than the TCP_DELACK. Looking at 2.4.17:ipv4/net/tcp.c, how pingpong can get set is very unclear. Also, we have tried this: (protonum via getprotobyname) quickack = 1; setsockopt(fd, protonum, TCP_QUICKACK, &quickack, sizeof(quickack)) and it has had NO effect. ACKs still come 40 ms. apart. Are we doing something wrong? From owner-netdev@oss.sgi.com Mon Feb 4 17:19:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g151JdO07691 for netdev-outgoing; Mon, 4 Feb 2002 17:19:39 -0800 Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g151JTA07688 for ; Mon, 4 Feb 2002 17:19:29 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id UAA14348; Mon, 4 Feb 2002 20:16:19 -0500 Received: from d03nm035.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g151JPg145592; Mon, 4 Feb 2002 18:19:25 -0700 From: "Nivedita Singhvi" Importance: Normal Sensitivity: Subject: Re: (delayed ack option) To: rminnich@lanl.gov Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, hendriks@lanl.gov, matt@lanl.gov X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Mon, 4 Feb 2002 17:19:12 -0800 X-MIMETrack: Serialize by Router on D03NM035/03/M/IBM(Release 5.0.9 |November 16, 2001) at 02/04/2002 06:19:26 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk > The tcp delayed ack support in Linux is killing us. > Our maximum sample rate is 25 hz. It is so slow, in fact, > that we may have to return to UDP, which we hate to think > about doing. > To recap, nivedita proposed a TCP_DELACK sockopt to allow > users to completely disabled delayed acks. Alexey thought > this a bad idea. We're not convinced it is a bad idea, and > it has a lot of attraction for us. Ron, would you be interested in playing around with a patch just to get an idea of how effective this is as a solution? > Alexey's comments are plain, and my comments in <<<>>> >> Well, actually, I have one question: how is application >> supposed to determine, when it is in this "certain environment"? <<< It's easy for us. We run, see 25 hz. sample rates, and know that we have determined the need to turn OFF delayed acks. Another consideration for you: what happens if NFS ever runs over TCP in this environment. 25 hz. packet rates are really a bad thing. NFS running under delack constraints could limit NFS performance to 25*8192 bytes/second. What should NFS do to fix this? >>> >> I see no way, but already implemented in tcp. >> In any case, if you can propose another way to guess, when >> delayed acks harm performance, it should be added to set >> of heuristics. <<< I think heuristics are nice, but you can take them too far. Heuristics are not a universal solution to every problem. TCP heuristics are causing us a great deal of grief. I'd like to be able to tell the kernel what to do in some circumstances. >>>> >> Actually, opposite option would make sense, 2.4 really generates >> too much of acks in some curcumstances. :-) <<< which is OK for some environments; what's bad is low packet rates. >>> >> I would rather expect that applications using this funny option >> are to be repaired not to use it. <<< Not always true. Sometimes, the app has a good reason to need this option. >>> >> You can obtain required effect blocking setting tp->ack.pingpong. >> tp->ack.pingpong frozen at zero gives maximal reasonable ack frequency. <<< the pingpong setting seems more like a hack to me than the TCP_DELACK. Looking at 2.4.17:ipv4/net/tcp.c, how pingpong can get set is very unclear. Also, we have tried this: (protonum via getprotobyname) quickack = 1; setsockopt(fd, protonum, TCP_QUICKACK, &quickack, sizeof(quickack)) and it has had NO effect. ACKs still come 40 ms. apart. Are we doing something wrong? This is not going to do what you want - i.e turn acks off. The quickack option only turns on quickack processing state, but the OS still controls when to send acks according to its own heuristic, so only some acks are actually saved (not sent). thanks, Nivedita (note: my sequent.com address is defunct, please use the ibm one). From owner-netdev@oss.sgi.com Tue Feb 5 08:54:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15GsFR27564 for netdev-outgoing; Tue, 5 Feb 2002 08:54:15 -0800 Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15GsAA27553 for ; Tue, 5 Feb 2002 08:54:11 -0800 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace [192.168.102.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g15Gspj95214 for ; Tue, 5 Feb 2002 17:54:51 +0100 (CET) Received: from zark ([192.168.101.95]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id RAA01578 for ; Tue, 5 Feb 2002 17:54:02 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Atif Syed Organization: NEC To: netdev@oss.sgi.com Subject: Problems by forwarding packets in kernel! Date: Tue, 5 Feb 2002 17:57:26 +0100 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <02020517572604.00792@zark> Content-Transfer-Encoding: 8bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Dear all, I have a one machine which sends udp-packets. The other machine should have to change the destination and source address in kernel and send it back to this machine. They are both connected locally. This connection is based on ipv6 level. I have done changes in ip6_rcv() in /usr/src/linux/net/ipv6/ip6_input.c to change the destination and source address in sk_buff. For Neighbour Discovery i have added that all packets with next header udp should have to be changed ohter packets (icmpv6) should go through. But still it is not working it goes through these funktions : ip6_rcv() -> ip6_rcv_finish() -> ip6_route_input -> ip6_rcv_finish() -> ip6_forward -> error!!! it should have to go through ip6_forward_finish() It seems that routing is not possible. Should i have to change any other possibility in sk_buff to tell the kernel that this packet is to be routed to host, where it come from. Thanx for help in advance. Atif Syed From owner-netdev@oss.sgi.com Tue Feb 5 11:21:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15JLnG26695 for netdev-outgoing; Tue, 5 Feb 2002 11:21:49 -0800 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15JLgA26593 for ; Tue, 5 Feb 2002 11:21:43 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id WAA01856; Tue, 5 Feb 2002 22:21:23 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200202051921.WAA01856@ms2.inr.ac.ru> Subject: Re: your mail To: rminnich@lanl.gov (Ronald G Minnich) Date: Tue, 5 Feb 2002 22:21:23 +0300 (MSK) Cc: netdev@oss.sgi.com, nivedita@sequent.COM, hendriks@lanl.gov, matt@lanl.gov In-Reply-To: from "Ronald G Minnich" at Feb 4, 2 02:05:04 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello! > To recap, nivedita proposed a TCP_DELACK sockopt to allow users to > completely disabled delayed acks. Alexey thought this a bad idea. We're > not convinced it is a bad idea, and it has a lot of attraction for us. ... > Alexey's comments are plain, and my comments in <<<>>> I did not write the phrases in <<<>>>. :-) Yes, I really insist: disabling delayed ACKs is _never_ good. Such curcumstances just do not exist in the nature. I do not understand what happens in your case, you did not provide tcpdumps. Though I even can suspect that your problem is due to too frequent acking. :-) Alexey From owner-netdev@oss.sgi.com Tue Feb 5 11:37:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15Jbm601984 for netdev-outgoing; Tue, 5 Feb 2002 11:37:48 -0800 Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15JbeA01981 for ; Tue, 5 Feb 2002 11:37:40 -0800 Received: (qmail 1078518 invoked from network); 5 Feb 2002 12:37:39 -0700 Received: from snaresland.acl.lanl.gov (128.165.147.113) by acl.lanl.gov with SMTP; 5 Feb 2002 12:37:39 -0700 Received: (qmail 9667 invoked by uid 3499); 5 Feb 2002 12:37:39 -0700 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 5 Feb 2002 12:37:39 -0700 Date: Tue, 5 Feb 2002 12:37:39 -0700 (MST) From: Ronald G Minnich X-X-Sender: To: cc: , , , Subject: Re: your mail In-Reply-To: <200202051921.WAA01856@ms2.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Tue, 5 Feb 2002 kuznet@ms2.inr.ac.ru wrote: > Such curcumstances just do not exist in the nature. As far as you know. You have not seen it so do not believe it. I guess I have to disagree with you here :-) "There are more things in heaven and earth than are dreamt of ..." > I do not understand what happens in your case, you did not provide > tcpdumps. Though I even can suspect that your problem is due to > too frequent acking. :-) Basically it is no longer worth my effort to build them, I developed a workaround. That said, I'm glad we're looking at alternatives to Linux for our clustering in the long term. ron From owner-netdev@oss.sgi.com Tue Feb 5 11:55:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15Jtf010141 for netdev-outgoing; Tue, 5 Feb 2002 11:55:41 -0800 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15JtbA10137 for ; Tue, 5 Feb 2002 11:55:37 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id WAA02865; Tue, 5 Feb 2002 22:55:23 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200202051955.WAA02865@ms2.inr.ac.ru> Subject: Re: your mail To: rminnich@lanl.gov (Ronald G Minnich) Date: Tue, 5 Feb 2002 22:55:23 +0300 (MSK) Cc: netdev@oss.sgi.com, nivedita@sequent.COM, hendriks@lanl.gov, matt@lanl.gov In-Reply-To: from "Ronald G Minnich" at Feb 5, 2 12:37:39 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello! > Basically it is no longer worth my effort Ack. The subject is closed. Alexey From owner-netdev@oss.sgi.com Tue Feb 5 12:33:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15KXrF31613 for netdev-outgoing; Tue, 5 Feb 2002 12:33:53 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15KXmA31610 for ; Tue, 5 Feb 2002 12:33:48 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 74EE61E7E0; Tue, 5 Feb 2002 21:33:40 +0100 (MET) Date: Tue, 5 Feb 2002 21:33:28 +0100 From: Andi Kleen To: Ronald G Minnich Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, nivedita@sequent.COM, hendriks@lanl.gov, matt@lanl.gov Subject: Re: your mail Message-ID: <20020205213328.A15478@wotan.suse.de> References: <200202051921.WAA01856@ms2.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk On Tue, Feb 05, 2002 at 12:37:39PM -0700, Ronald G Minnich wrote: > On Tue, 5 Feb 2002 kuznet@ms2.inr.ac.ru wrote: > > > Such curcumstances just do not exist in the nature. > > As far as you know. You have not seen it so do not believe it. I guess I > have to disagree with you here :-) > > "There are more things in heaven and earth than are dreamt of ..." Claiming something and not providing tcpdumps of it is at least highly dubious. I also have a hard time to see how delayed acks should introduce user visible delays (assuming your send/receive buffers are big enough) -Andi From owner-netdev@oss.sgi.com Tue Feb 5 12:36:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15Kabr00815 for netdev-outgoing; Tue, 5 Feb 2002 12:36:37 -0800 Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15KaNA00811 for ; Tue, 5 Feb 2002 12:36:24 -0800 Received: (qmail 1050322 invoked from network); 5 Feb 2002 13:36:22 -0700 Received: from snaresland.acl.lanl.gov (128.165.147.113) by acl.lanl.gov with SMTP; 5 Feb 2002 13:36:22 -0700 Received: (qmail 10584 invoked by uid 3499); 5 Feb 2002 13:36:22 -0700 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 5 Feb 2002 13:36:22 -0700 Date: Tue, 5 Feb 2002 13:36:22 -0700 (MST) From: Ronald G Minnich X-X-Sender: To: Andi Kleen cc: , , , , Subject: Re: your mail In-Reply-To: <20020205213328.A15478@wotan.suse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Tue, 5 Feb 2002, Andi Kleen wrote: > I also have a hard time to see how delayed acks should introduce user > visible delays (assuming your send/receive buffers are big enough) I know. That's the whole problem. People have a hard time seeing something, so they deny its existence. ron From owner-netdev@oss.sgi.com Tue Feb 5 12:49:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15KnQr07191 for netdev-outgoing; Tue, 5 Feb 2002 12:49:26 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15KnMA07186 for ; Tue, 5 Feb 2002 12:49:22 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 686B21E7EE; Tue, 5 Feb 2002 21:49:16 +0100 (MET) Date: Tue, 5 Feb 2002 21:49:10 +0100 From: Andi Kleen To: Ronald G Minnich Cc: Andi Kleen , kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, nivedita@sequent.COM, hendriks@lanl.gov, matt@lanl.gov Subject: Re: your mail Message-ID: <20020205214910.B17532@wotan.suse.de> References: <20020205213328.A15478@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk On Tue, Feb 05, 2002 at 01:36:22PM -0700, Ronald G Minnich wrote: > On Tue, 5 Feb 2002, Andi Kleen wrote: > > > I also have a hard time to see how delayed acks should introduce user > > visible delays (assuming your send/receive buffers are big enough) > > I know. That's the whole problem. People have a hard time seeing > something, so they deny its existence. When you claim something that fails the sanity checks of several other people and you blame Linux it is your duty to provide evidence for it. In TCP world the standard evidence is a tcpdump. tcpdumps don't lie. Without a tcpdump we can as well assume that the problem doesn't exist. -Andi From owner-netdev@oss.sgi.com Tue Feb 5 13:00:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15L0Qa14633 for netdev-outgoing; Tue, 5 Feb 2002 13:00:26 -0800 Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15L0IA14630 for ; Tue, 5 Feb 2002 13:00:18 -0800 Received: (qmail 958750 invoked from network); 5 Feb 2002 14:00:17 -0700 Received: from xed.acl.lanl.gov (128.165.147.191) by acl.lanl.gov with SMTP; 5 Feb 2002 14:00:17 -0700 Received: (qmail 30453 invoked by uid 4480); 5 Feb 2002 14:00:17 -0700 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 5 Feb 2002 14:00:17 -0700 Date: Tue, 5 Feb 2002 14:00:17 -0700 (MST) From: Matt Sottile X-X-Sender: To: Andi Kleen cc: Ronald G Minnich , , , , Subject: Re: your mail In-Reply-To: <20020205214910.B17532@wotan.suse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Ron should be sending the TCP dump along soon. For your information, the application we're encountering this problem with is one where we are sending data periodically across the network at the highest possible rate -- a client sends a request to a server, the server responds with a result. This we call a "sample" -- now, we want to get as many samples as we can in one second. Now, we know we can poll the data source that we're getting the data from inside a single box at ~3.5 Khz (~3500 samples/second). Now, as soon as we move from a single box to a two box sampling across the network, we immediately hit a ceiling of 25Hz... Amazingly enough, if you dive into the 2.4 kernel sources and find the delayed ack code, we notice that some brilliant programmer decided the delay is related to.... HZ/25. Now, taking that into account and looking at the tcpdump that Ron will shortly pass along, we have lots of reason to believe that this delay stuff is limiting our sampling rates across the network. (Now be patient and don't tell me that I'm imagining things until you get Ron's tcpdump data...) -matt On Tue, 5 Feb 2002, Andi Kleen wrote: > On Tue, Feb 05, 2002 at 01:36:22PM -0700, Ronald G Minnich wrote: > > On Tue, 5 Feb 2002, Andi Kleen wrote: > > > > > I also have a hard time to see how delayed acks should introduce user > > > visible delays (assuming your send/receive buffers are big enough) > > > > I know. That's the whole problem. People have a hard time seeing > > something, so they deny its existence. > > When you claim something that fails the sanity checks of several other > people and you blame Linux it is your duty to provide evidence for it. > In TCP world the standard evidence is a tcpdump. tcpdumps don't lie. > Without a tcpdump we can as well assume that the problem doesn't exist. > > -Andi > > -- ------------------------------------------------------------------------ Matt Sottile | Phone: 1 (505) 665-6057 CCS-1 : Advanced Computing | Email: matt@lanl.gov MS B287 | Los Alamos National Laboratory | If you're not part of the solution, Los Alamos, NM 87545 | you're part of the precipitate. ------------------------------------------------------------------------ From owner-netdev@oss.sgi.com Tue Feb 5 13:21:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15LLWC15125 for netdev-outgoing; Tue, 5 Feb 2002 13:21:32 -0800 Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15LGLA14975 for ; Tue, 5 Feb 2002 13:16:21 -0800 Received: (qmail 1096591 invoked from network); 5 Feb 2002 14:16:20 -0700 Received: from snaresland.acl.lanl.gov (128.165.147.113) by acl.lanl.gov with SMTP; 5 Feb 2002 14:16:20 -0700 Received: (qmail 10757 invoked by uid 3499); 5 Feb 2002 14:16:19 -0700 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 5 Feb 2002 14:16:19 -0700 Date: Tue, 5 Feb 2002 14:16:19 -0700 (MST) From: Ronald G Minnich X-X-Sender: To: Andi Kleen cc: , , , , Subject: Re: your mail In-Reply-To: <20020205214910.B17532@wotan.suse.de> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1518308973-788829135-1012943779=:8565" 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. ---1518308973-788829135-1012943779=:8565 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 5 Feb 2002, Andi Kleen wrote: > When you claim something that fails the sanity checks of several other > people and you blame Linux it is your duty to provide evidence for it. > In TCP world the standard evidence is a tcpdump. tcpdumps don't lie. > Without a tcpdump we can as well assume that the problem doesn't exist. oh, all right :-) attached. sample: blue is sending a request to xed for a packet. Supermon (on xed) in turn sends status requests to several other nodes. Xed formats each "blob" of data from the other nodes and sends it to blue. The 'S' to supermon results in one byte of 'S' to the other nodes, and the data comes back from the other nodes as a large S-expression (in other words the delays you see in this tcpdump are NOT from the other nodes). Here's one cycle. Blue sends 'S' (one byte) to 'xed', and 'xed' is sending data back. As you can see, in the middle of xed sending lots of data back, there is this fine ~40 ms. delay. This delay occurs for each transaction at least once, and limits us to 25 hz. request processing. We also had this problem before with the 'mon' programs on the nodes but have developed a workaround, which we will also be applying to supermon. Please note that this is a problem that seems to have come along with 2.4. We are fixing user code that did not have this problem on 2.2. I have no argument with your effort to improve ack behavior in 2.4. I just wish you'd let me turn it off. The only option we have turned on is TCP_NODELAY, but that has proven to be pretty important for this application. However if you want me to use different options I'm willing to try it. BTW, I've done NFS over TCP once or twice (once in the SunOS kernel), and this kind of behavior leaves me worried about what your TCP will do to NFS if we ever try NFS over TCP on Linux. 1012942315.229586 eth0 < blue.acl.lanl.gov.32790 > xed.acl.lanl.gov.2709: P 2:3(1) ack 1534 win 8931 (DF) 1012942315.230563 eth0 > xed.acl.lanl.gov.2709 > blue.acl.lanl.gov.32790: P 1534:1618(84) ack 3 win 5792 (DF) 1012942315.268651 eth0 < blue.acl.lanl.gov.32790 > xed.acl.lanl.gov.2709: . 3:3(0) ack 1618 win 8931 (DF) 1012942315.268651 eth0 > xed.acl.lanl.gov.2709 > blue.acl.lanl.gov.32790: P 1618:2295(677) ack 3 win 5792 (DF) 1012942315.268651 eth0 < blue.acl.lanl.gov.32790 > xed.acl.lanl.gov.2709: . 3:3(0) ack 2295 win 10305 (DF) 1012942315.268651 eth0 > xed.acl.lanl.gov.2709 > blue.acl.lanl.gov.32790: P 2295:3067(772) ack 3 win 5792 (DF) 1012942315.268651 eth0 < blue.acl.lanl.gov.32790 > xed.acl.lanl.gov.2709: . 3:3(0) ack 3067 win 11580 (DF) 1012942315.268651 eth0 < blue.acl.lanl.gov.32790 > xed.acl.lanl.gov.2709: P 3:4(1) ack 3067 win 11580 (DF) 1012942315.269628 eth0 > xed.acl.lanl.gov.2709 > blue.acl.lanl.gov.32790: P 3067:3151(84) ack 4 win 5792 (DF) 1012942315.308693 eth0 < blue.acl.lanl.gov.32790 > xed.acl.lanl.gov.2709: . 4:4(0) ack 3151 win 11580 (DF) 1012942315.308693 eth0 > xed.acl.lanl.gov.2709 > blue.acl.lanl.gov.32790: P 3151:3828(677) ack 4 win 5792 (DF) 1012942315.308693 eth0 < blue.acl.lanl.gov.32790 > xed.acl.lanl.gov.2709: . 4:4(0) ack 3828 win 13124 (DF) 1012942315.308693 eth0 > xed.acl.lanl.gov.2709 > blue.acl.lanl.gov.32790: P 3828:4139(311) ack 4 win 5792 (DF) 1012942315.308693 eth0 < blue.acl.lanl.gov.32790 > xed.acl.lanl.gov.2709: . 4:4(0) ack 4139 win 13124 (DF) 1012942315.308693 eth0 > xed.acl.lanl.gov.2709 > blue.acl.lanl.gov.32790: P 4139:4600(461) ack 4 win 5792 (DF) ron ---1518308973-788829135-1012943779=:8565 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=acack Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=acack MTAxMjk0MjMxNS4yMDYxNDcgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMy NzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiBTIDE1NjUwOTUwNTc6MTU2 NTA5NTA1NygwKSB3aW4gNTg0MCA8bXNzIDE0NjAsc2Fja09LLHRpbWVzdGFt cCA4NTY5OTI2MyAwLG5vcCx3c2NhbGUgMD4gKERGKQ0KMTAxMjk0MjMxNS4y MDYxNDcgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNs LmxhbmwuZ292LjMyNzkwOiBTIDE1NTg4MTkwNDE6MTU1ODgxOTA0MSgwKSBh Y2sgMTU2NTA5NTA1OCB3aW4gNTc5MiA8bXNzIDE0NjAsc2Fja09LLHRpbWVz dGFtcCA4Nzc0NDU4NjYgODU2OTkyNjMsbm9wLHdzY2FsZSAwPiAoREYpDQox MDEyOTQyMzE1LjIwNjE0NyBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3 OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gMToxKDApIGFjayAxIHdp biA1ODQwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTI2MyA4Nzc0NDU4NjY+ IChERikNCjEwMTI5NDIzMTUuMjA2MTQ3IGV0aDAgPCBibHVlLmFjbC5sYW5s Lmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogUCAxOjIoMSkg YWNrIDEgd2luIDU4NDAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5MjYzIDg3 NzQ0NTg2Nj4gKERGKQ0KMTAxMjk0MjMxNS4yMDYxNDcgZXRoMCA+IHhlZC5h Y2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiAu IDE6MSgwKSBhY2sgMiB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3 NDQ1ODY2IDg1Njk5MjYzPiAoREYpDQoxMDEyOTQyMzE1LjIwNzEyNCBldGgw ID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3Yu MzI3OTA6IFAgMTo4NSg4NCkgYWNrIDIgd2luIDU3OTIgPG5vcCxub3AsdGlt ZXN0YW1wIDg3NzQ0NTg2NyA4NTY5OTI2Mz4gKERGKQ0KMTAxMjk0MjMxNS4y MDcxMjQgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFj bC5sYW5sLmdvdi4yNzA5OiAuIDI6MigwKSBhY2sgODUgd2luIDU4NDAgPG5v cCxub3AsdGltZXN0YW1wIDg1Njk5MjYzIDg3NzQ0NTg2Nz4gKERGKQ0KMTAx Mjk0MjMxNS4yMDcxMjQgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+ IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDg1OjM4NygzMDIpIGFjayAy IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDU4NjcgODU2OTky NjM+IChERikNCjEwMTI5NDIzMTUuMjA3MTI0IGV0aDAgPCBibHVlLmFjbC5s YW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiAyOjIo MCkgYWNrIDM4NyB3aW4gNjQzMiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTky NjMgODc3NDQ1ODY3PiAoREYpDQoxMDEyOTQyMzE1LjIwNzEyNCBldGgwID4g eGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3 OTA6IFAgMzg3Ojc2MigzNzUpIGFjayAyIHdpbiA1NzkyIDxub3Asbm9wLHRp bWVzdGFtcCA4Nzc0NDU4NjcgODU2OTkyNjM+IChERikNCjEwMTI5NDIzMTUu MjA4MTAwIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5h Y2wubGFubC5nb3YuMjcwOTogLiAyOjIoMCkgYWNrIDc2MiB3aW4gNzUwNCA8 bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkyNjMgODc3NDQ1ODY3PiAoREYpDQox MDEyOTQyMzE1LjIyODYxMCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5 ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgNzYyOjg0Nig4NCkgYWNr IDIgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NTg4OSA4NTY5 OTI2Mz4gKERGKQ0KMTAxMjk0MjMxNS4yMjg2MTAgZXRoMCA8IGJsdWUuYWNs LmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDI6 MigwKSBhY2sgODQ2IHdpbiA3NTA0IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5 OTI2NiA4Nzc0NDU4ODk+IChERikNCjEwMTI5NDIzMTUuMjI4NjEwIGV0aDAg PiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4z Mjc5MDogUCA4NDY6MTUzMyg2ODcpIGFjayAyIHdpbiA1NzkyIDxub3Asbm9w LHRpbWVzdGFtcCA4Nzc0NDU4ODkgODU2OTkyNjY+IChERikNCjEwMTI5NDIz MTUuMjI5NTg2IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhl ZC5hY2wubGFubC5nb3YuMjcwOTogLiAyOjIoMCkgYWNrIDE1MzMgd2luIDg5 MzEgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5MjY2IDg3NzQ0NTg4OT4gKERG KQ0KMTAxMjk0MjMxNS4yMjk1ODYgZXRoMCA+IHhlZC5hY2wubGFubC5nb3Yu MjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDE1MzM6MTUzNCgx KSBhY2sgMiB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ1ODkw IDg1Njk5MjY2PiAoREYpDQoxMDEyOTQyMzE1LjIyOTU4NiBldGgwIDwgYmx1 ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6 IC4gMjoyKDApIGFjayAxNTM0IHdpbiA4OTMxIDxub3Asbm9wLHRpbWVzdGFt cCA4NTY5OTI2NiA4Nzc0NDU4OTA+IChERikNCjEwMTI5NDIzMTUuMjI5NTg2 IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFu bC5nb3YuMjcwOTogUCAyOjMoMSkgYWNrIDE1MzQgd2luIDg5MzEgPG5vcCxu b3AsdGltZXN0YW1wIDg1Njk5MjY2IDg3NzQ0NTg5MD4gKERGKQ0KMTAxMjk0 MjMxNS4yMzA1NjMgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJs dWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDE1MzQ6MTYxOCg4NCkgYWNrIDMg d2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NTg5MSA4NTY5OTI2 Nj4gKERGKQ0KMTAxMjk0MjMxNS4yNjg2NTEgZXRoMCA8IGJsdWUuYWNsLmxh bmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDM6Mygw KSBhY2sgMTYxOCB3aW4gODkzMSA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTky NzAgODc3NDQ1ODkxPiAoREYpDQoxMDEyOTQyMzE1LjI2ODY1MSBldGgwID4g eGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3 OTA6IFAgMTYxODoyMjk1KDY3NykgYWNrIDMgd2luIDU3OTIgPG5vcCxub3As dGltZXN0YW1wIDg3NzQ0NTkzMCA4NTY5OTI3MD4gKERGKQ0KMTAxMjk0MjMx NS4yNjg2NTEgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVk LmFjbC5sYW5sLmdvdi4yNzA5OiAuIDM6MygwKSBhY2sgMjI5NSB3aW4gMTAz MDUgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5MjcwIDg3NzQ0NTkzMD4gKERG KQ0KMTAxMjk0MjMxNS4yNjg2NTEgZXRoMCA+IHhlZC5hY2wubGFubC5nb3Yu MjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDIyOTU6MzA2Nyg3 NzIpIGFjayAzIHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDU5 MzAgODU2OTkyNzA+IChERikNCjEwMTI5NDIzMTUuMjY4NjUxIGV0aDAgPCBi bHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcw OTogLiAzOjMoMCkgYWNrIDMwNjcgd2luIDExNTgwIDxub3Asbm9wLHRpbWVz dGFtcCA4NTY5OTI3MCA4Nzc0NDU5MzA+IChERikNCjEwMTI5NDIzMTUuMjY4 NjUxIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wu bGFubC5nb3YuMjcwOTogUCAzOjQoMSkgYWNrIDMwNjcgd2luIDExNTgwIDxu b3Asbm9wLHRpbWVzdGFtcCA4NTY5OTI3MCA4Nzc0NDU5MzA+IChERikNCjEw MTI5NDIzMTUuMjY5NjI4IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkg PiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAzMDY3OjMxNTEoODQpIGFj ayA0IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDU5MzEgODU2 OTkyNzA+IChERikNCjEwMTI5NDIzMTUuMzA4NjkzIGV0aDAgPCBibHVlLmFj bC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA0 OjQoMCkgYWNrIDMxNTEgd2luIDExNTgwIDxub3Asbm9wLHRpbWVzdGFtcCA4 NTY5OTI3NCA4Nzc0NDU5MzE+IChERikNCjEwMTI5NDIzMTUuMzA4NjkzIGV0 aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdv di4zMjc5MDogUCAzMTUxOjM4MjgoNjc3KSBhY2sgNCB3aW4gNTc5MiA8bm9w LG5vcCx0aW1lc3RhbXAgODc3NDQ1OTcxIDg1Njk5Mjc0PiAoREYpDQoxMDEy OTQyMzE1LjMwODY5MyBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAg PiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNDo0KDApIGFjayAzODI4IHdp biAxMzEyNCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkyNzQgODc3NDQ1OTcx PiAoREYpDQoxMDEyOTQyMzE1LjMwODY5MyBldGgwID4geGVkLmFjbC5sYW5s Lmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMzgyODo0 MTM5KDMxMSkgYWNrIDQgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3 NzQ0NTk3MSA4NTY5OTI3ND4gKERGKQ0KMTAxMjk0MjMxNS4zMDg2OTMgZXRo MCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdv di4yNzA5OiAuIDQ6NCgwKSBhY2sgNDEzOSB3aW4gMTMxMjQgPG5vcCxub3As dGltZXN0YW1wIDg1Njk5Mjc0IDg3NzQ0NTk3MT4gKERGKQ0KMTAxMjk0MjMx NS4zMDg2OTMgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUu YWNsLmxhbmwuZ292LjMyNzkwOiBQIDQxMzk6NDYwMCg0NjEpIGFjayA0IHdp biA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDU5NzEgODU2OTkyNzQ+ IChERikNCjEwMTI5NDIzMTUuMzA5NjY5IGV0aDAgPCBibHVlLmFjbC5sYW5s Lmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA0OjQoMCkg YWNrIDQ2MDAgd2luIDE0NjY4IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTI3 NCA4Nzc0NDU5NzE+IChERikNCjEwMTI5NDIzMTUuMzA5NjY5IGV0aDAgPCBi bHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcw OTogUCA0OjUoMSkgYWNrIDQ2MDAgd2luIDE0NjY4IDxub3Asbm9wLHRpbWVz dGFtcCA4NTY5OTI3NCA4Nzc0NDU5NzE+IChERikNCjEwMTI5NDIzMTUuMzA5 NjY5IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5s YW5sLmdvdi4zMjc5MDogUCA0NjAwOjQ2ODQoODQpIGFjayA1IHdpbiA1Nzky IDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDU5NzIgODU2OTkyNzQ+IChERikN CjEwMTI5NDIzMTUuMzQ4NzM0IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4z Mjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA1OjUoMCkgYWNrIDQ2 ODQgd2luIDE0NjY4IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTI3OCA4Nzc0 NDU5NzI+IChERikNCjEwMTI5NDIzMTUuMzQ4NzM0IGV0aDAgPiB4ZWQuYWNs LmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCA0 Njg0OjUzNjEoNjc3KSBhY2sgNSB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3Rh bXAgODc3NDQ2MDEyIDg1Njk5Mjc4PiAoREYpDQoxMDEyOTQyMzE1LjM0ODcz NCBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxh bmwuZ292LjI3MDk6IC4gNTo1KDApIGFjayA1MzYxIHdpbiAxNjIxMiA8bm9w LG5vcCx0aW1lc3RhbXAgODU2OTkyNzggODc3NDQ2MDEyPiAoREYpDQoxMDEy OTQyMzE1LjM0ODczNCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4g Ymx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgNTM2MTo1NjcyKDMxMSkgYWNr IDUgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NjAxMiA4NTY5 OTI3OD4gKERGKQ0KMTAxMjk0MjMxNS4zNDg3MzQgZXRoMCA8IGJsdWUuYWNs LmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDU6 NSgwKSBhY2sgNTY3MiB3aW4gMTYyMTIgPG5vcCxub3AsdGltZXN0YW1wIDg1 Njk5Mjc4IDg3NzQ0NjAxMj4gKERGKQ0KMTAxMjk0MjMxNS4zNDg3MzQgZXRo MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292 LjMyNzkwOiBQIDU2NzI6NjEzMyg0NjEpIGFjayA1IHdpbiA1NzkyIDxub3As bm9wLHRpbWVzdGFtcCA4Nzc0NDYwMTIgODU2OTkyNzg+IChERikNCjEwMTI5 NDIzMTUuMzQ5NzExIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+ IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA1OjUoMCkgYWNrIDYxMzMgd2lu IDE2MjEyIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTI3OCA4Nzc0NDYwMTI+ IChERikNCjEwMTI5NDIzMTUuMzQ5NzExIGV0aDAgPCBibHVlLmFjbC5sYW5s Lmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogUCA1OjYoMSkg YWNrIDYxMzMgd2luIDE2MjEyIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTI3 OCA4Nzc0NDYwMTI+IChERikNCjEwMTI5NDIzMTUuMzQ5NzExIGV0aDAgPiB4 ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5 MDogUCA2MTMzOjYyMTcoODQpIGFjayA2IHdpbiA1NzkyIDxub3Asbm9wLHRp bWVzdGFtcCA4Nzc0NDYwMTMgODU2OTkyNzg+IChERikNCjEwMTI5NDIzMTUu Mzg4Nzc2IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5h Y2wubGFubC5nb3YuMjcwOTogLiA2OjYoMCkgYWNrIDYyMTcgd2luIDE2MjEy IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTI4MiA4Nzc0NDYwMTM+IChERikN CjEwMTI5NDIzMTUuMzg4Nzc2IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3 MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCA2MjE3OjY4OTQoNjc3 KSBhY2sgNiB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ2MDUz IDg1Njk5MjgyPiAoREYpDQoxMDEyOTQyMzE1LjM4ODc3NiBldGgwIDwgYmx1 ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6 IC4gNjo2KDApIGFjayA2ODk0IHdpbiAxNzc1NiA8bm9wLG5vcCx0aW1lc3Rh bXAgODU2OTkyODIgODc3NDQ2MDUzPiAoREYpDQoxMDEyOTQyMzE1LjM4ODc3 NiBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTA6IFAgNjg5NDo2OTc4KDg0KSBhY2sgNiB3aW4gNTc5MiA8 bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ2MDUzIDg1Njk5MjgyPiAoREYpDQox MDEyOTQyMzE1LjM4ODc3NiBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3 OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNjo2KDApIGFjayA2OTc4 IHdpbiAxNzc1NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkyODIgODc3NDQ2 MDUzPiAoREYpDQoxMDEyOTQyMzE1LjM4ODc3NiBldGgwID4geGVkLmFjbC5s YW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgNjk3 ODo3Mjg4KDMxMCkgYWNrIDYgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1w IDg3NzQ0NjA1MyA4NTY5OTI4Mj4gKERGKQ0KMTAxMjk0MjMxNS4zODg3NzYg ZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5s Lmdvdi4yNzA5OiAuIDY6NigwKSBhY2sgNzI4OCB3aW4gMTc3NTYgPG5vcCxu b3AsdGltZXN0YW1wIDg1Njk5MjgyIDg3NzQ0NjA1Mz4gKERGKQ0KMTAxMjk0 MjMxNS4zODg3NzYgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJs dWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDcyODg6NzY2NigzNzgpIGFjayA2 IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDYwNTMgODU2OTky ODI+IChERikNCjEwMTI5NDIzMTUuMzg5NzUyIGV0aDAgPCBibHVlLmFjbC5s YW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA2OjYo MCkgYWNrIDc2NjYgd2luIDE3NzU2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5 OTI4MiA4Nzc0NDYwNTM+IChERikNCjEwMTI5NDIzMTUuMzg5NzUyIGV0aDAg PCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3Yu MjcwOTogUCA2OjcoMSkgYWNrIDc2NjYgd2luIDE3NzU2IDxub3Asbm9wLHRp bWVzdGFtcCA4NTY5OTI4MiA4Nzc0NDYwNTM+IChERikNCjEwMTI5NDIzMTUu MzkwNzI5IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFj bC5sYW5sLmdvdi4zMjc5MDogUCA3NjY2Ojc3NTAoODQpIGFjayA3IHdpbiA1 NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDYwNTUgODU2OTkyODI+IChE RikNCjEwMTI5NDIzMTUuNDI4ODE3IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdv di4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA3OjcoMCkgYWNr IDc3NTAgd2luIDE3NzU2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTI4NiA4 Nzc0NDYwNTU+IChERikNCjEwMTI5NDIzMTUuNDI4ODE3IGV0aDAgPiB4ZWQu YWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDog UCA3NzUwOjg0MjcoNjc3KSBhY2sgNyB3aW4gNTc5MiA8bm9wLG5vcCx0aW1l c3RhbXAgODc3NDQ2MDk0IDg1Njk5Mjg2PiAoREYpDQoxMDEyOTQyMzE1LjQy ODgxNyBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNs LmxhbmwuZ292LjI3MDk6IC4gNzo3KDApIGFjayA4NDI3IHdpbiAxOTMwMCA8 bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkyODYgODc3NDQ2MDk0PiAoREYpDQox MDEyOTQyMzE1LjQyODgxNyBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5 ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgODQyNzo4NTExKDg0KSBh Y2sgNyB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ2MDk0IDg1 Njk5Mjg2PiAoREYpDQoxMDEyOTQyMzE1LjQyODgxNyBldGgwIDwgYmx1ZS5h Y2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4g Nzo3KDApIGFjayA4NTExIHdpbiAxOTMwMCA8bm9wLG5vcCx0aW1lc3RhbXAg ODU2OTkyODYgODc3NDQ2MDk0PiAoREYpDQoxMDEyOTQyMzE1LjQyODgxNyBl dGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5n b3YuMzI3OTA6IFAgODUxMTo4ODIxKDMxMCkgYWNrIDcgd2luIDU3OTIgPG5v cCxub3AsdGltZXN0YW1wIDg3NzQ0NjA5NCA4NTY5OTI4Nj4gKERGKQ0KMTAx Mjk0MjMxNS40Mjg4MTcgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkw ID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDc6NygwKSBhY2sgODgyMSB3 aW4gMTkzMDAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5Mjg2IDg3NzQ0NjA5 ND4gKERGKQ0KMTAxMjk0MjMxNS40Mjg4MTcgZXRoMCA+IHhlZC5hY2wubGFu bC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDg4MjE6 OTE5OSgzNzgpIGFjayA3IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4 Nzc0NDYwOTQgODU2OTkyODY+IChERikNCjEwMTI5NDIzMTUuNDI5Nzk0IGV0 aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5n b3YuMjcwOTogLiA3OjcoMCkgYWNrIDkxOTkgd2luIDE5MzAwIDxub3Asbm9w LHRpbWVzdGFtcCA4NTY5OTI4NiA4Nzc0NDYwOTQ+IChERikNCjEwMTI5NDIz MTUuNDI5Nzk0IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhl ZC5hY2wubGFubC5nb3YuMjcwOTogUCA3OjgoMSkgYWNrIDkxOTkgd2luIDE5 MzAwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTI4NiA4Nzc0NDYwOTQ+IChE RikNCjEwMTI5NDIzMTUuNDMwNzcwIGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292 LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCA5MTk5OjkyODMo ODQpIGFjayA4IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDYw OTUgODU2OTkyODY+IChERikNCjEwMTI5NDIzMTUuNDY4ODU5IGV0aDAgPCBi bHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcw OTogLiA4OjgoMCkgYWNrIDkyODMgd2luIDE5MzAwIDxub3Asbm9wLHRpbWVz dGFtcCA4NTY5OTI5MCA4Nzc0NDYwOTU+IChERikNCjEwMTI5NDIzMTUuNDY4 ODU5IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5s YW5sLmdvdi4zMjc5MDogUCA5MjgzOjk5NjAoNjc3KSBhY2sgOCB3aW4gNTc5 MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ2MTM1IDg1Njk5MjkwPiAoREYp DQoxMDEyOTQyMzE1LjQ2ODg1OSBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3Yu MzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gODo4KDApIGFjayA5 OTYwIHdpbiAyMDg0NCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkyOTAgODc3 NDQ2MTM1PiAoREYpDQoxMDEyOTQyMzE1LjQ2ODg1OSBldGgwID4geGVkLmFj bC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAg OTk2MDoxMDA0NCg4NCkgYWNrIDggd2luIDU3OTIgPG5vcCxub3AsdGltZXN0 YW1wIDg3NzQ0NjEzNSA4NTY5OTI5MD4gKERGKQ0KMTAxMjk0MjMxNS40Njg4 NTkgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5s YW5sLmdvdi4yNzA5OiAuIDg6OCgwKSBhY2sgMTAwNDQgd2luIDIwODQ0IDxu b3Asbm9wLHRpbWVzdGFtcCA4NTY5OTI5MCA4Nzc0NDYxMzU+IChERikNCjEw MTI5NDIzMTUuNDY4ODU5IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkg PiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAxMDA0NDoxMDM1NCgzMTAp IGFjayA4IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDYxMzUg ODU2OTkyOTA+IChERikNCjEwMTI5NDIzMTUuNDY4ODU5IGV0aDAgPCBibHVl LmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTog LiA4OjgoMCkgYWNrIDEwMzU0IHdpbiAyMDg0NCA8bm9wLG5vcCx0aW1lc3Rh bXAgODU2OTkyOTAgODc3NDQ2MTM1PiAoREYpDQoxMDEyOTQyMzE1LjQ2OTgz NSBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTA6IFAgMTAzNTQ6MTA3MzIoMzc4KSBhY2sgOCB3aW4gNTc5 MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ2MTM1IDg1Njk5MjkwPiAoREYp DQoxMDEyOTQyMzE1LjQ2OTgzNSBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3Yu MzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gODo4KDApIGFjayAx MDczMiB3aW4gMjA4NDQgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5MjkwIDg3 NzQ0NjEzNT4gKERGKQ0KMTAxMjk0MjMxNS40Njk4MzUgZXRoMCA8IGJsdWUu YWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiBQ IDg6OSgxKSBhY2sgMTA3MzIgd2luIDIwODQ0IDxub3Asbm9wLHRpbWVzdGFt cCA4NTY5OTI5MCA4Nzc0NDYxMzU+IChERikNCjEwMTI5NDIzMTUuNDcwODEy IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5s Lmdvdi4zMjc5MDogUCAxMDczMjoxMDgxNig4NCkgYWNrIDkgd2luIDU3OTIg PG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NjEzNyA4NTY5OTI5MD4gKERGKQ0K MTAxMjk0MjMxNS41MDg5MDAgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMy NzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDk6OSgwKSBhY2sgMTA4 MTYgd2luIDIwODQ0IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTI5NCA4Nzc0 NDYxMzc+IChERikNCjEwMTI5NDIzMTUuNTA4OTAwIGV0aDAgPiB4ZWQuYWNs LmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAx MDgxNjoxMTQ5Myg2NzcpIGFjayA5IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVz dGFtcCA4Nzc0NDYxNzYgODU2OTkyOTQ+IChERikNCjEwMTI5NDIzMTUuNTA4 OTAwIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wu bGFubC5nb3YuMjcwOTogLiA5OjkoMCkgYWNrIDExNDkzIHdpbiAyMjM4OCA8 bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkyOTQgODc3NDQ2MTc2PiAoREYpDQox MDEyOTQyMzE1LjUwODkwMCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5 ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMTE0OTM6MTE1NzcoODQp IGFjayA5IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDYxNzYg ODU2OTkyOTQ+IChERikNCjEwMTI5NDIzMTUuNTA4OTAwIGV0aDAgPCBibHVl LmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTog LiA5OjkoMCkgYWNrIDExNTc3IHdpbiAyMjM4OCA8bm9wLG5vcCx0aW1lc3Rh bXAgODU2OTkyOTQgODc3NDQ2MTc2PiAoREYpDQoxMDEyOTQyMzE1LjUwODkw MCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTA6IFAgMTE1Nzc6MTIyNjQoNjg3KSBhY2sgOSB3aW4gNTc5 MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ2MTc2IDg1Njk5Mjk0PiAoREYp DQoxMDEyOTQyMzE1LjUwOTg3NyBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3Yu MzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gOTo5KDApIGFjayAx MjI2NCB3aW4gMjM5MzIgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5Mjk0IDg3 NzQ0NjE3Nj4gKERGKQ0KMTAxMjk0MjMxNS41MDk4NzcgZXRoMCA+IHhlZC5h Y2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQ IDEyMjY0OjEyMjY1KDEpIGFjayA5IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVz dGFtcCA4Nzc0NDYxNzcgODU2OTkyOTQ+IChERikNCjEwMTI5NDIzMTUuNTA5 ODc3IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wu bGFubC5nb3YuMjcwOTogLiA5OjkoMCkgYWNrIDEyMjY1IHdpbiAyMzkzMiA8 bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkyOTQgODc3NDQ2MTc3PiAoREYpDQox MDEyOTQyMzE1LjUwOTg3NyBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3 OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IFAgOToxMCgxKSBhY2sgMTIy NjUgd2luIDIzOTMyIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTI5NCA4Nzc0 NDYxNzc+IChERikNCjEwMTI5NDIzMTUuNTEwODUzIGV0aDAgPiB4ZWQuYWNs LmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAx MjI2NToxMjM0OSg4NCkgYWNrIDEwIHdpbiA1NzkyIDxub3Asbm9wLHRpbWVz dGFtcCA4Nzc0NDYxNzggODU2OTkyOTQ+IChERikNCjEwMTI5NDIzMTUuNTQ4 OTQxIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wu bGFubC5nb3YuMjcwOTogLiAxMDoxMCgwKSBhY2sgMTIzNDkgd2luIDIzOTMy IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTI5OCA4Nzc0NDYxNzg+IChERikN CjEwMTI5NDIzMTUuNTQ4OTQxIGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3 MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAxMjM0OToxMzAyNig2 NzcpIGFjayAxMCB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ2 MjE3IDg1Njk5Mjk4PiAoREYpDQoxMDEyOTQyMzE1LjU0ODk0MSBldGgwIDwg Ymx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3 MDk6IC4gMTA6MTAoMCkgYWNrIDEzMDI2IHdpbiAyNTQ3NiA8bm9wLG5vcCx0 aW1lc3RhbXAgODU2OTkyOTggODc3NDQ2MjE3PiAoREYpDQoxMDEyOTQyMzE1 LjU0ODk0MSBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5h Y2wubGFubC5nb3YuMzI3OTA6IFAgMTMwMjY6MTMxMTAoODQpIGFjayAxMCB3 aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ2MjE3IDg1Njk5Mjk4 PiAoREYpDQoxMDEyOTQyMzE1LjU0ODk0MSBldGgwIDwgYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gMTA6MTAo MCkgYWNrIDEzMTEwIHdpbiAyNTQ3NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2 OTkyOTggODc3NDQ2MjE3PiAoREYpDQoxMDEyOTQyMzE1LjU0ODk0MSBldGgw ID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3Yu MzI3OTA6IFAgMTMxMTA6MTM0MjAoMzEwKSBhY2sgMTAgd2luIDU3OTIgPG5v cCxub3AsdGltZXN0YW1wIDg3NzQ0NjIxNyA4NTY5OTI5OD4gKERGKQ0KMTAx Mjk0MjMxNS41NDg5NDEgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkw ID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDEwOjEwKDApIGFjayAxMzQy MCB3aW4gMjU0NzYgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5Mjk4IDg3NzQ0 NjIxNz4gKERGKQ0KMTAxMjk0MjMxNS41NDg5NDEgZXRoMCA+IHhlZC5hY2wu bGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDEz NDIwOjEzNzk4KDM3OCkgYWNrIDEwIHdpbiA1NzkyIDxub3Asbm9wLHRpbWVz dGFtcCA4Nzc0NDYyMTcgODU2OTkyOTg+IChERikNCjEwMTI5NDIzMTUuNTQ5 OTE4IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wu bGFubC5nb3YuMjcwOTogLiAxMDoxMCgwKSBhY2sgMTM3OTggd2luIDI1NDc2 IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTI5OCA4Nzc0NDYyMTc+IChERikN CjEwMTI5NDIzMTUuNTQ5OTE4IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4z Mjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogUCAxMDoxMSgxKSBhY2sg MTM3OTggd2luIDI1NDc2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTI5OCA4 Nzc0NDYyMTc+IChERikNCjEwMTI5NDIzMTUuNTQ5OTE4IGV0aDAgPiB4ZWQu YWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDog UCAxMzc5ODoxMzg4Mig4NCkgYWNrIDExIHdpbiA1NzkyIDxub3Asbm9wLHRp bWVzdGFtcCA4Nzc0NDYyMTggODU2OTkyOTg+IChERikNCjEwMTI5NDIzMTUu NTg4OTgzIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5h Y2wubGFubC5nb3YuMjcwOTogLiAxMToxMSgwKSBhY2sgMTM4ODIgd2luIDI1 NDc2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTMwMiA4Nzc0NDYyMTg+IChE RikNCjEwMTI5NDIzMTUuNTg4OTgzIGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292 LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAxMzg4MjoxNDU1 OSg2NzcpIGFjayAxMSB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3 NDQ2MjU4IDg1Njk5MzAyPiAoREYpDQoxMDEyOTQyMzE1LjU4ODk4MyBldGgw IDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292 LjI3MDk6IC4gMTE6MTEoMCkgYWNrIDE0NTU5IHdpbiAyNzAyMCA8bm9wLG5v cCx0aW1lc3RhbXAgODU2OTkzMDIgODc3NDQ2MjU4PiAoREYpDQoxMDEyOTQy MzE1LjU4ODk4MyBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1 ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMTQ1NTk6MTQ2NDMoODQpIGFjayAx MSB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ2MjU4IDg1Njk5 MzAyPiAoREYpDQoxMDEyOTQyMzE1LjU4ODk4MyBldGgwIDwgYmx1ZS5hY2wu bGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gMTE6 MTEoMCkgYWNrIDE0NjQzIHdpbiAyNzAyMCA8bm9wLG5vcCx0aW1lc3RhbXAg ODU2OTkzMDIgODc3NDQ2MjU4PiAoREYpDQoxMDEyOTQyMzE1LjU4ODk4MyBl dGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5n b3YuMzI3OTA6IFAgMTQ2NDM6MTQ5NTMoMzEwKSBhY2sgMTEgd2luIDU3OTIg PG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NjI1OCA4NTY5OTMwMj4gKERGKQ0K MTAxMjk0MjMxNS41ODg5ODMgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMy NzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDExOjExKDApIGFjayAx NDk1MyB3aW4gMjcwMjAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5MzAyIDg3 NzQ0NjI1OD4gKERGKQ0KMTAxMjk0MjMxNS41ODg5ODMgZXRoMCA+IHhlZC5h Y2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQ IDE0OTUzOjE1MzMxKDM3OCkgYWNrIDExIHdpbiA1NzkyIDxub3Asbm9wLHRp bWVzdGFtcCA4Nzc0NDYyNTggODU2OTkzMDI+IChERikNCjEwMTI5NDIzMTUu NTg5OTYwIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5h Y2wubGFubC5nb3YuMjcwOTogLiAxMToxMSgwKSBhY2sgMTUzMzEgd2luIDI3 MDIwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTMwMiA4Nzc0NDYyNTg+IChE RikNCjEwMTI5NDIzMTUuNTg5OTYwIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdv di4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogUCAxMToxMigxKSBh Y2sgMTUzMzEgd2luIDI3MDIwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTMw MiA4Nzc0NDYyNTg+IChERikNCjEwMTI5NDIzMTUuNTkwOTM2IGV0aDAgPiB4 ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5 MDogUCAxNTMzMToxNTQxNSg4NCkgYWNrIDEyIHdpbiA1NzkyIDxub3Asbm9w LHRpbWVzdGFtcCA4Nzc0NDYyNjAgODU2OTkzMDI+IChERikNCjEwMTI5NDIz MTUuNjI4MDQ4IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhl ZC5hY2wubGFubC5nb3YuMjcwOTogLiAxMjoxMigwKSBhY2sgMTU0MTUgd2lu IDI3MDIwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTMwNiA4Nzc0NDYyNjA+ IChERikNCjEwMTI5NDIzMTUuNjI5MDI0IGV0aDAgPiB4ZWQuYWNsLmxhbmwu Z292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAxNTQxNTox NjA5Mig2NzcpIGFjayAxMiB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAg ODc3NDQ2Mjk5IDg1Njk5MzA2PiAoREYpDQoxMDEyOTQyMzE1LjYyOTAyNCBl dGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwu Z292LjI3MDk6IC4gMTI6MTIoMCkgYWNrIDE2MDkyIHdpbiAyODU2NCA8bm9w LG5vcCx0aW1lc3RhbXAgODU2OTkzMDYgODc3NDQ2Mjk5PiAoREYpDQoxMDEy OTQyMzE1LjYyOTAyNCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4g Ymx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMTYwOTI6MTYxNzYoODQpIGFj ayAxMiB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ2Mjk5IDg1 Njk5MzA2PiAoREYpDQoxMDEyOTQyMzE1LjYyOTAyNCBldGgwIDwgYmx1ZS5h Y2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4g MTI6MTIoMCkgYWNrIDE2MTc2IHdpbiAyODU2NCA8bm9wLG5vcCx0aW1lc3Rh bXAgODU2OTkzMDYgODc3NDQ2Mjk5PiAoREYpDQoxMDEyOTQyMzE1LjYyOTAy NCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTA6IFAgMTYxNzY6MTY0ODYoMzEwKSBhY2sgMTIgd2luIDU3 OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NjI5OSA4NTY5OTMwNj4gKERG KQ0KMTAxMjk0MjMxNS42MjkwMjQgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292 LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDEyOjEyKDApIGFj ayAxNjQ4NiB3aW4gMjg1NjQgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5MzA2 IDg3NzQ0NjI5OT4gKERGKQ0KMTAxMjk0MjMxNS42MjkwMjQgZXRoMCA+IHhl ZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkw OiBQIDE2NDg2OjE2ODY0KDM3OCkgYWNrIDEyIHdpbiA1NzkyIDxub3Asbm9w LHRpbWVzdGFtcCA4Nzc0NDYyOTkgODU2OTkzMDY+IChERikNCjEwMTI5NDIz MTUuNjMwMDAxIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhl ZC5hY2wubGFubC5nb3YuMjcwOTogLiAxMjoxMigwKSBhY2sgMTY4NjQgd2lu IDI4NTY0IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTMwNiA4Nzc0NDYyOTk+ IChERikNCjEwMTI5NDIzMTUuNjMwMDAxIGV0aDAgPCBibHVlLmFjbC5sYW5s Lmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogUCAxMjoxMygx KSBhY2sgMTY4NjQgd2luIDI4NTY0IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5 OTMwNiA4Nzc0NDYyOTk+IChERikNCjEwMTI5NDIzMTUuNjMwOTc4IGV0aDAg PiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4z Mjc5MDogUCAxNjg2NDoxNjk0OCg4NCkgYWNrIDEzIHdpbiA1NzkyIDxub3As bm9wLHRpbWVzdGFtcCA4Nzc0NDYzMDEgODU2OTkzMDY+IChERikNCjEwMTI5 NDIzMTUuNjY4MDg5IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+ IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiAxMzoxMygwKSBhY2sgMTY5NDgg d2luIDI4NTY0IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTMxMCA4Nzc0NDYz MDE+IChERikNCjEwMTI5NDIzMTUuNjY5MDY2IGV0aDAgPiB4ZWQuYWNsLmxh bmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAxNjk0 ODoxNzYyNSg2NzcpIGFjayAxMyB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3Rh bXAgODc3NDQ2MzQwIDg1Njk5MzEwPiAoREYpDQoxMDEyOTQyMzE1LjY2OTA2 NiBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxh bmwuZ292LjI3MDk6IC4gMTM6MTMoMCkgYWNrIDE3NjI1IHdpbiAzMDEwOCA8 bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkzMTAgODc3NDQ2MzQwPiAoREYpDQox MDEyOTQyMzE1LjY2OTA2NiBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5 ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMTc2MjU6MTc3MDkoODQp IGFjayAxMyB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ2MzQw IDg1Njk5MzEwPiAoREYpDQoxMDEyOTQyMzE1LjY2OTA2NiBldGgwIDwgYmx1 ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6 IC4gMTM6MTMoMCkgYWNrIDE3NzA5IHdpbiAzMDEwOCA8bm9wLG5vcCx0aW1l c3RhbXAgODU2OTkzMTAgODc3NDQ2MzQwPiAoREYpDQoxMDEyOTQyMzE1LjY2 OTA2NiBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wu bGFubC5nb3YuMzI3OTA6IFAgMTc3MDk6MTgwMTkoMzEwKSBhY2sgMTMgd2lu IDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NjM0MCA4NTY5OTMxMD4g KERGKQ0KMTAxMjk0MjMxNS42NjkwNjYgZXRoMCA8IGJsdWUuYWNsLmxhbmwu Z292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDEzOjEzKDAp IGFjayAxODAxOSB3aW4gMzAxMDggPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5 MzEwIDg3NzQ0NjM0MD4gKERGKQ0KMTAxMjk0MjMxNS42NzAwNDIgZXRoMCA+ IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMy NzkwOiBQIDE4MDE5OjE4Mzk3KDM3OCkgYWNrIDEzIHdpbiA1NzkyIDxub3As bm9wLHRpbWVzdGFtcCA4Nzc0NDYzNDAgODU2OTkzMTA+IChERikNCjEwMTI5 NDIzMTUuNjcwMDQyIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+ IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiAxMzoxMygwKSBhY2sgMTgzOTcg d2luIDMwMTA4IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTMxMCA4Nzc0NDYz NDA+IChERikNCjEwMTI5NDIzMTUuNjcwMDQyIGV0aDAgPCBibHVlLmFjbC5s YW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogUCAxMzox NCgxKSBhY2sgMTgzOTcgd2luIDMwMTA4IDxub3Asbm9wLHRpbWVzdGFtcCA4 NTY5OTMxMCA4Nzc0NDYzNDA+IChERikNCjEwMTI5NDIzMTUuNjcxMDE5IGV0 aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdv di4zMjc5MDogUCAxODM5NzoxODQ4MSg4NCkgYWNrIDE0IHdpbiA1NzkyIDxu b3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDYzNDIgODU2OTkzMTA+IChERikNCjEw MTI5NDIzMTUuNzA4MTMxIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5 MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiAxNDoxNCgwKSBhY2sgMTg0 ODEgd2luIDMwMTA4IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTMxNCA4Nzc0 NDYzNDI+IChERikNCjEwMTI5NDIzMTUuNzA4MTMxIGV0aDAgPiB4ZWQuYWNs LmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAx ODQ4MToxOTE1OCg2NzcpIGFjayAxNCB3aW4gNTc5MiA8bm9wLG5vcCx0aW1l c3RhbXAgODc3NDQ2MzgwIDg1Njk5MzE0PiAoREYpDQoxMDEyOTQyMzE1Ljcw OTEwNyBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNs LmxhbmwuZ292LjI3MDk6IC4gMTQ6MTQoMCkgYWNrIDE5MTU4IHdpbiAzMTY1 MiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkzMTQgODc3NDQ2MzgwPiAoREYp DQoxMDEyOTQyMzE1LjcwOTEwNyBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4y NzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMTkxNTg6MTkyNDIo ODQpIGFjayAxNCB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ2 MzgxIDg1Njk5MzE0PiAoREYpDQoxMDEyOTQyMzE1LjcwOTEwNyBldGgwIDwg Ymx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3 MDk6IC4gMTQ6MTQoMCkgYWNrIDE5MjQyIHdpbiAzMTY1MiA8bm9wLG5vcCx0 aW1lc3RhbXAgODU2OTkzMTQgODc3NDQ2MzgxPiAoREYpDQoxMDEyOTQyMzE1 LjcwOTEwNyBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5h Y2wubGFubC5nb3YuMzI3OTA6IFAgMTkyNDI6MTk1NTIoMzEwKSBhY2sgMTQg d2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NjM4MSA4NTY5OTMx ND4gKERGKQ0KMTAxMjk0MjMxNS43MDkxMDcgZXRoMCA8IGJsdWUuYWNsLmxh bmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDE0OjE0 KDApIGFjayAxOTU1MiB3aW4gMzE2NTIgPG5vcCxub3AsdGltZXN0YW1wIDg1 Njk5MzE0IDg3NzQ0NjM4MT4gKERGKQ0KMTAxMjk0MjMxNS43MDkxMDcgZXRo MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292 LjMyNzkwOiBQIDE5NTUyOjE5OTMwKDM3OCkgYWNrIDE0IHdpbiA1NzkyIDxu b3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDYzODEgODU2OTkzMTQ+IChERikNCjEw MTI5NDIzMTUuNzEwMDg0IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5 MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiAxNDoxNCgwKSBhY2sgMTk5 MzAgd2luIDMxNjUyIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTMxNCA4Nzc0 NDYzODE+IChERikNCjEwMTI5NDIzMTUuNzEwMDg0IGV0aDAgPCBibHVlLmFj bC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogUCAx NDoxNSgxKSBhY2sgMTk5MzAgd2luIDMxNjUyIDxub3Asbm9wLHRpbWVzdGFt cCA4NTY5OTMxNCA4Nzc0NDYzODE+IChERikNCjEwMTI5NDIzMTUuNzExMDYx IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5s Lmdvdi4zMjc5MDogUCAxOTkzMDoyMDAxNCg4NCkgYWNrIDE1IHdpbiA1Nzky IDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDYzODMgODU2OTkzMTQ+IChERikN CjEwMTI5NDIzMTUuNzQ4MTcyIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4z Mjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiAxNToxNSgwKSBhY2sg MjAwMTQgd2luIDMxNjUyIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTMxOCA4 Nzc0NDYzODM+IChERikNCjEwMTI5NDIzMTUuNzQ4MTcyIGV0aDAgPiB4ZWQu YWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDog UCAyMDAxNDoyMDY5MSg2NzcpIGFjayAxNSB3aW4gNTc5MiA8bm9wLG5vcCx0 aW1lc3RhbXAgODc3NDQ2NDIxIDg1Njk5MzE4PiAoREYpDQoxMDEyOTQyMzE1 Ljc0OTE0OSBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQu YWNsLmxhbmwuZ292LjI3MDk6IC4gMTU6MTUoMCkgYWNrIDIwNjkxIHdpbiAz MzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkzMTggODc3NDQ2NDIxPiAo REYpDQoxMDEyOTQyMzE1Ljc0OTE0OSBldGgwID4geGVkLmFjbC5sYW5sLmdv di4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMjA2OTE6MjA3 NzUoODQpIGFjayAxNSB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3 NDQ2NDIyIDg1Njk5MzE4PiAoREYpDQoxMDEyOTQyMzE1Ljc0OTE0OSBldGgw IDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292 LjI3MDk6IC4gMTU6MTUoMCkgYWNrIDIwNzc1IHdpbiAzMzE5NiA8bm9wLG5v cCx0aW1lc3RhbXAgODU2OTkzMTggODc3NDQ2NDIyPiAoREYpDQoxMDEyOTQy MzE1Ljc0OTE0OSBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1 ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMjA3NzU6MjE0NjIoNjg3KSBhY2sg MTUgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NjQyMiA4NTY5 OTMxOD4gKERGKQ0KMTAxMjk0MjMxNS43NDkxNDkgZXRoMCA8IGJsdWUuYWNs LmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDE1 OjE1KDApIGFjayAyMTQ2MiB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0YW1w IDg1Njk5MzE4IDg3NzQ0NjQyMj4gKERGKQ0KMTAxMjk0MjMxNS43NDkxNDkg ZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwu Z292LjMyNzkwOiBQIDIxNDYyOjIxNDYzKDEpIGFjayAxNSB3aW4gNTc5MiA8 bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ2NDIyIDg1Njk5MzE4PiAoREYpDQox MDEyOTQyMzE1Ljc1MDEyNSBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3 OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gMTU6MTUoMCkgYWNrIDIx NDYzIHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkzMTggODc3 NDQ2NDIyPiAoREYpDQoxMDEyOTQyMzE1Ljc1MDEyNSBldGgwIDwgYmx1ZS5h Y2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IFAg MTU6MTYoMSkgYWNrIDIxNDYzIHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1lc3Rh bXAgODU2OTkzMTggODc3NDQ2NDIyPiAoREYpDQoxMDEyOTQyMzE1Ljc1MDEy NSBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTA6IFAgMjE0NjM6MjE1NDcoODQpIGFjayAxNiB3aW4gNTc5 MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ2NDIzIDg1Njk5MzE4PiAoREYp DQoxMDEyOTQyMzE1Ljc4ODIxNCBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3Yu MzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gMTY6MTYoMCkgYWNr IDIxNTQ3IHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkzMjIg ODc3NDQ2NDIzPiAoREYpDQoxMDEyOTQyMzE1Ljc4ODIxNCBldGgwID4geGVk LmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6 IFAgMjE1NDc6MjIyMjQoNjc3KSBhY2sgMTYgd2luIDU3OTIgPG5vcCxub3As dGltZXN0YW1wIDg3NzQ0NjQ2MiA4NTY5OTMyMj4gKERGKQ0KMTAxMjk0MjMx NS43ODkxOTAgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVk LmFjbC5sYW5sLmdvdi4yNzA5OiAuIDE2OjE2KDApIGFjayAyMjIyNCB3aW4g MzMxOTYgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5MzIyIDg3NzQ0NjQ2Mj4g KERGKQ0KMTAxMjk0MjMxNS43ODkxOTAgZXRoMCA+IHhlZC5hY2wubGFubC5n b3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDIyMjI0OjIy MzA4KDg0KSBhY2sgMTYgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3 NzQ0NjQ2MyA4NTY5OTMyMj4gKERGKQ0KMTAxMjk0MjMxNS43ODkxOTAgZXRo MCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdv di4yNzA5OiAuIDE2OjE2KDApIGFjayAyMjMwOCB3aW4gMzMxOTYgPG5vcCxu b3AsdGltZXN0YW1wIDg1Njk5MzIyIDg3NzQ0NjQ2Mz4gKERGKQ0KMTAxMjk0 MjMxNS43ODkxOTAgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJs dWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDIyMzA4OjIyOTk1KDY4NykgYWNr IDE2IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDY0NjMgODU2 OTkzMjI+IChERikNCjEwMTI5NDIzMTUuNzkwMTY3IGV0aDAgPCBibHVlLmFj bC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiAx NjoxNigwKSBhY2sgMjI5OTUgd2luIDMzMTk2IDxub3Asbm9wLHRpbWVzdGFt cCA4NTY5OTMyMiA4Nzc0NDY0NjM+IChERikNCjEwMTI5NDIzMTUuNzkwMTY3 IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5s Lmdvdi4zMjc5MDogUCAyMjk5NToyMjk5NigxKSBhY2sgMTYgd2luIDU3OTIg PG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NjQ2NCA4NTY5OTMyMj4gKERGKQ0K MTAxMjk0MjMxNS43OTAxNjcgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMy NzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDE2OjE2KDApIGFjayAy Mjk5NiB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5MzIyIDg3 NzQ0NjQ2ND4gKERGKQ0KMTAxMjk0MjMxNS43OTAxNjcgZXRoMCA8IGJsdWUu YWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiBQ IDE2OjE3KDEpIGFjayAyMjk5NiB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0 YW1wIDg1Njk5MzIyIDg3NzQ0NjQ2ND4gKERGKQ0KMTAxMjk0MjMxNS43OTEx NDQgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxh bmwuZ292LjMyNzkwOiBQIDIyOTk2OjIzMDgwKDg0KSBhY2sgMTcgd2luIDU3 OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NjQ2NSA4NTY5OTMyMj4gKERG KQ0KMTAxMjk0MjMxNS44MjgyNTUgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292 LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDE3OjE3KDApIGFj ayAyMzA4MCB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5MzI2 IDg3NzQ0NjQ2NT4gKERGKQ0KMTAxMjk0MjMxNS44MjgyNTUgZXRoMCA+IHhl ZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkw OiBQIDIzMDgwOjIzNzU3KDY3NykgYWNrIDE3IHdpbiA1NzkyIDxub3Asbm9w LHRpbWVzdGFtcCA4Nzc0NDY1MDMgODU2OTkzMjY+IChERikNCjEwMTI5NDIz MTUuODI5MjMyIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhl ZC5hY2wubGFubC5nb3YuMjcwOTogLiAxNzoxNygwKSBhY2sgMjM3NTcgd2lu IDMzMTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTMyNiA4Nzc0NDY1MDM+ IChERikNCjEwMTI5NDIzMTUuODI5MjMyIGV0aDAgPiB4ZWQuYWNsLmxhbmwu Z292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAyMzc1Nzoy Mzg0MSg4NCkgYWNrIDE3IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4 Nzc0NDY1MDQgODU2OTkzMjY+IChERikNCjEwMTI5NDIzMTUuODI5MjMyIGV0 aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5n b3YuMjcwOTogLiAxNzoxNygwKSBhY2sgMjM4NDEgd2luIDMzMTk2IDxub3As bm9wLHRpbWVzdGFtcCA4NTY5OTMyNiA4Nzc0NDY1MDQ+IChERikNCjEwMTI5 NDIzMTUuODI5MjMyIGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBi bHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAyMzg0MToyNDUyOCg2ODcpIGFj ayAxNyB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ2NTA0IDg1 Njk5MzI2PiAoREYpDQoxMDEyOTQyMzE1LjgyOTIzMiBldGgwIDwgYmx1ZS5h Y2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4g MTc6MTcoMCkgYWNrIDI0NTI4IHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1lc3Rh bXAgODU2OTkzMjYgODc3NDQ2NTA0PiAoREYpDQoxMDEyOTQyMzE1LjgzMDIw OCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTA6IFAgMjQ1Mjg6MjQ1MjkoMSkgYWNrIDE3IHdpbiA1Nzky IDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDY1MDUgODU2OTkzMjY+IChERikN CjEwMTI5NDIzMTUuODMwMjA4IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4z Mjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiAxNzoxNygwKSBhY2sg MjQ1Mjkgd2luIDMzMTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTMyNiA4 Nzc0NDY1MDU+IChERikNCjEwMTI5NDIzMTUuODMwMjA4IGV0aDAgPCBibHVl LmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTog UCAxNzoxOCgxKSBhY2sgMjQ1Mjkgd2luIDMzMTk2IDxub3Asbm9wLHRpbWVz dGFtcCA4NTY5OTMyNiA4Nzc0NDY1MDU+IChERikNCjEwMTI5NDIzMTUuODMx MTg1IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5s YW5sLmdvdi4zMjc5MDogUCAyNDUyOToyNDYxMyg4NCkgYWNrIDE4IHdpbiA1 NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDY1MDUgODU2OTkzMjY+IChE RikNCjEwMTI5NDIzMTUuODY4Mjk3IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdv di4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiAxODoxOCgwKSBh Y2sgMjQ2MTMgd2luIDMzMTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTMz MCA4Nzc0NDY1MDU+IChERikNCjEwMTI5NDIzMTUuODY4Mjk3IGV0aDAgPiB4 ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5 MDogUCAyNDYxMzoyNTI5MCg2NzcpIGFjayAxOCB3aW4gNTc5MiA8bm9wLG5v cCx0aW1lc3RhbXAgODc3NDQ2NTQ0IDg1Njk5MzMwPiAoREYpDQoxMDEyOTQy MzE1Ljg2OTI3MyBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4 ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gMTg6MTgoMCkgYWNrIDI1MjkwIHdp biAzMzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkzMzAgODc3NDQ2NTQ0 PiAoREYpDQoxMDEyOTQyMzE1Ljg2OTI3MyBldGgwID4geGVkLmFjbC5sYW5s Lmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMjUyOTA6 MjUzNzQoODQpIGFjayAxOCB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAg ODc3NDQ2NTQ1IDg1Njk5MzMwPiAoREYpDQoxMDEyOTQyMzE1Ljg2OTI3MyBl dGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwu Z292LjI3MDk6IC4gMTg6MTgoMCkgYWNrIDI1Mzc0IHdpbiAzMzE5NiA8bm9w LG5vcCx0aW1lc3RhbXAgODU2OTkzMzAgODc3NDQ2NTQ1PiAoREYpDQoxMDEy OTQyMzE1Ljg2OTI3MyBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4g Ymx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMjUzNzQ6MjYwNjEoNjg3KSBh Y2sgMTggd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NjU0NSA4 NTY5OTMzMD4gKERGKQ0KMTAxMjk0MjMxNS44NzAyNTAgZXRoMCA8IGJsdWUu YWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAu IDE4OjE4KDApIGFjayAyNjA2MSB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0 YW1wIDg1Njk5MzMwIDg3NzQ0NjU0NT4gKERGKQ0KMTAxMjk0MjMxNS44NzAy NTAgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxh bmwuZ292LjMyNzkwOiBQIDI2MDYxOjI2MDYyKDEpIGFjayAxOCB3aW4gNTc5 MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ2NTQ2IDg1Njk5MzMwPiAoREYp DQoxMDEyOTQyMzE1Ljg3MDI1MCBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3Yu MzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gMTg6MTgoMCkgYWNr IDI2MDYyIHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkzMzAg ODc3NDQ2NTQ2PiAoREYpDQoxMDEyOTQyMzE1Ljg3MDI1MCBldGgwIDwgYmx1 ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6 IFAgMTg6MTkoMSkgYWNrIDI2MDYyIHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1l c3RhbXAgODU2OTkzMzAgODc3NDQ2NTQ2PiAoREYpDQoxMDEyOTQyMzE1Ljg3 MTIyNiBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wu bGFubC5nb3YuMzI3OTA6IFAgMjYwNjI6MjYxNDYoODQpIGFjayAxOSB3aW4g NTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ2NTQ3IDg1Njk5MzMwPiAo REYpDQoxMDEyOTQyMzE1LjkwODMzOCBldGgwIDwgYmx1ZS5hY2wubGFubC5n b3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gMTk6MTkoMCkg YWNrIDI2MTQ2IHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkz MzQgODc3NDQ2NTQ3PiAoREYpDQoxMDEyOTQyMzE1LjkwODMzOCBldGgwID4g eGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3 OTA6IFAgMjYxNDY6MjY4MjMoNjc3KSBhY2sgMTkgd2luIDU3OTIgPG5vcCxu b3AsdGltZXN0YW1wIDg3NzQ0NjU4NSA4NTY5OTMzND4gKERGKQ0KMTAxMjk0 MjMxNS45MDkzMTUgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4g eGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDE5OjE5KDApIGFjayAyNjgyMyB3 aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5MzM0IDg3NzQ0NjU4 NT4gKERGKQ0KMTAxMjk0MjMxNS45MDkzMTUgZXRoMCA+IHhlZC5hY2wubGFu bC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDI2ODIz OjI2OTA3KDg0KSBhY2sgMTkgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1w IDg3NzQ0NjU4NiA4NTY5OTMzND4gKERGKQ0KMTAxMjk0MjMxNS45MDkzMTUg ZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5s Lmdvdi4yNzA5OiAuIDE5OjE5KDApIGFjayAyNjkwNyB3aW4gMzMxOTYgPG5v cCxub3AsdGltZXN0YW1wIDg1Njk5MzM0IDg3NzQ0NjU4Nj4gKERGKQ0KMTAx Mjk0MjMxNS45MDkzMTUgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+ IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDI2OTA3OjI3MjE3KDMxMCkg YWNrIDE5IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDY1ODYg ODU2OTkzMzQ+IChERikNCjEwMTI5NDIzMTUuOTA5MzE1IGV0aDAgPCBibHVl LmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTog LiAxOToxOSgwKSBhY2sgMjcyMTcgd2luIDMzMTk2IDxub3Asbm9wLHRpbWVz dGFtcCA4NTY5OTMzNCA4Nzc0NDY1ODY+IChERikNCjEwMTI5NDIzMTUuOTA5 MzE1IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5s YW5sLmdvdi4zMjc5MDogUCAyNzIxNzoyNzU5NSgzNzgpIGFjayAxOSB3aW4g NTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ2NTg2IDg1Njk5MzM0PiAo REYpDQoxMDEyOTQyMzE1LjkxMDI5MSBldGgwIDwgYmx1ZS5hY2wubGFubC5n b3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gMTk6MTkoMCkg YWNrIDI3NTk1IHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkz MzQgODc3NDQ2NTg2PiAoREYpDQoxMDEyOTQyMzE1LjkxMDI5MSBldGgwIDwg Ymx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3 MDk6IFAgMTk6MjAoMSkgYWNrIDI3NTk1IHdpbiAzMzE5NiA8bm9wLG5vcCx0 aW1lc3RhbXAgODU2OTkzMzQgODc3NDQ2NTg2PiAoREYpDQoxMDEyOTQyMzE1 LjkxMTI2OCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5h Y2wubGFubC5nb3YuMzI3OTA6IFAgMjc1OTU6Mjc2NzkoODQpIGFjayAyMCB3 aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ2NTg4IDg1Njk5MzM0 PiAoREYpDQoxMDEyOTQyMzE1Ljk0ODM4MCBldGgwIDwgYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gMjA6MjAo MCkgYWNrIDI3Njc5IHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2 OTkzMzggODc3NDQ2NTg4PiAoREYpDQoxMDEyOTQyMzE1Ljk0ODM4MCBldGgw ID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3Yu MzI3OTA6IFAgMjc2Nzk6MjgzNTYoNjc3KSBhY2sgMjAgd2luIDU3OTIgPG5v cCxub3AsdGltZXN0YW1wIDg3NzQ0NjYyNiA4NTY5OTMzOD4gKERGKQ0KMTAx Mjk0MjMxNS45NDgzODAgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkw ID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDIwOjIwKDApIGFjayAyODM1 NiB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5MzM4IDg3NzQ0 NjYyNj4gKERGKQ0KMTAxMjk0MjMxNS45NDkzNTYgZXRoMCA+IHhlZC5hY2wu bGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDI4 MzU2OjI4NDQwKDg0KSBhY2sgMjAgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0 YW1wIDg3NzQ0NjYyNyA4NTY5OTMzOD4gKERGKQ0KMTAxMjk0MjMxNS45NDkz NTYgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5s YW5sLmdvdi4yNzA5OiAuIDIwOjIwKDApIGFjayAyODQ0MCB3aW4gMzMxOTYg PG5vcCxub3AsdGltZXN0YW1wIDg1Njk5MzM4IDg3NzQ0NjYyNz4gKERGKQ0K MTAxMjk0MjMxNS45NDkzNTYgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcw OSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDI4NDQwOjI4NzUwKDMx MCkgYWNrIDIwIHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDY2 MjcgODU2OTkzMzg+IChERikNCjEwMTI5NDIzMTUuOTQ5MzU2IGV0aDAgPCBi bHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcw OTogLiAyMDoyMCgwKSBhY2sgMjg3NTAgd2luIDMzMTk2IDxub3Asbm9wLHRp bWVzdGFtcCA4NTY5OTMzOCA4Nzc0NDY2Mjc+IChERikNCjEwMTI5NDIzMTUu OTQ5MzU2IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFj bC5sYW5sLmdvdi4zMjc5MDogUCAyODc1MDoyOTEyOCgzNzgpIGFjayAyMCB3 aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ2NjI3IDg1Njk5MzM4 PiAoREYpDQoxMDEyOTQyMzE1Ljk1MDMzMyBldGgwIDwgYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gMjA6MjAo MCkgYWNrIDI5MTI4IHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2 OTkzMzggODc3NDQ2NjI3PiAoREYpDQoxMDEyOTQyMzE1Ljk1MDMzMyBldGgw IDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292 LjI3MDk6IFAgMjA6MjEoMSkgYWNrIDI5MTI4IHdpbiAzMzE5NiA8bm9wLG5v cCx0aW1lc3RhbXAgODU2OTkzMzggODc3NDQ2NjI3PiAoREYpDQoxMDEyOTQy MzE1Ljk1MDMzMyBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1 ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMjkxMjg6MjkyMTIoODQpIGFjayAy MSB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ2NjI4IDg1Njk5 MzM4PiAoREYpDQoxMDEyOTQyMzE1Ljk4ODQyMSBldGgwIDwgYmx1ZS5hY2wu bGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gMjE6 MjEoMCkgYWNrIDI5MjEyIHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAg ODU2OTkzNDIgODc3NDQ2NjI4PiAoREYpDQoxMDEyOTQyMzE1Ljk4ODQyMSBl dGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5n b3YuMzI3OTA6IFAgMjkyMTI6Mjk4ODkoNjc3KSBhY2sgMjEgd2luIDU3OTIg PG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NjY2NyA4NTY5OTM0Mj4gKERGKQ0K MTAxMjk0MjMxNS45ODg0MjEgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMy NzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDIxOjIxKDApIGFjayAy OTg4OSB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5MzQyIDg3 NzQ0NjY2Nz4gKERGKQ0KMTAxMjk0MjMxNS45ODkzOTggZXRoMCA+IHhlZC5h Y2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQ IDI5ODg5OjI5OTczKDg0KSBhY2sgMjEgd2luIDU3OTIgPG5vcCxub3AsdGlt ZXN0YW1wIDg3NzQ0NjY2OCA4NTY5OTM0Mj4gKERGKQ0KMTAxMjk0MjMxNS45 ODkzOTggZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFj bC5sYW5sLmdvdi4yNzA5OiAuIDIxOjIxKDApIGFjayAyOTk3MyB3aW4gMzMx OTYgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5MzQyIDg3NzQ0NjY2OD4gKERG KQ0KMTAxMjk0MjMxNS45ODkzOTggZXRoMCA+IHhlZC5hY2wubGFubC5nb3Yu MjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDI5OTczOjMwNjYw KDY4NykgYWNrIDIxIHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0 NDY2NjggODU2OTkzNDI+IChERikNCjEwMTI5NDIzMTUuOTg5Mzk4IGV0aDAg PCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3Yu MjcwOTogLiAyMToyMSgwKSBhY2sgMzA2NjAgd2luIDMzMTk2IDxub3Asbm9w LHRpbWVzdGFtcCA4NTY5OTM0MiA4Nzc0NDY2Njg+IChERikNCjEwMTI5NDIz MTUuOTg5Mzk4IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVl LmFjbC5sYW5sLmdvdi4zMjc5MDogUCAzMDY2MDozMDY2MSgxKSBhY2sgMjEg d2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NjY2OCA4NTY5OTM0 Mj4gKERGKQ0KMTAxMjk0MjMxNS45OTAzNzQgZXRoMCA8IGJsdWUuYWNsLmxh bmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDIxOjIx KDApIGFjayAzMDY2MSB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0YW1wIDg1 Njk5MzQyIDg3NzQ0NjY2OD4gKERGKQ0KMTAxMjk0MjMxNS45OTAzNzQgZXRo MCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdv di4yNzA5OiBQIDIxOjIyKDEpIGFjayAzMDY2MSB3aW4gMzMxOTYgPG5vcCxu b3AsdGltZXN0YW1wIDg1Njk5MzQyIDg3NzQ0NjY2OD4gKERGKQ0KMTAxMjk0 MjMxNS45OTAzNzQgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJs dWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDMwNjYxOjMwNzQ1KDg0KSBhY2sg MjIgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NjY2OSA4NTY5 OTM0Mj4gKERGKQ0KMTAxMjk0MjMxNi4wMjg0NjIgZXRoMCA8IGJsdWUuYWNs LmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDIy OjIyKDApIGFjayAzMDc0NSB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0YW1w IDg1Njk5MzQ2IDg3NzQ0NjY2OT4gKERGKQ0KMTAxMjk0MjMxNi4wMjg0NjIg ZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwu Z292LjMyNzkwOiBQIDMwNzQ1OjMxNDIyKDY3NykgYWNrIDIyIHdpbiA1Nzky IDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDY3MDggODU2OTkzNDY+IChERikN CjEwMTI5NDIzMTYuMDI4NDYyIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4z Mjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiAyMjoyMigwKSBhY2sg MzE0MjIgd2luIDMzMTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTM0NiA4 Nzc0NDY3MDg+IChERikNCjEwMTI5NDIzMTYuMDI5NDM5IGV0aDAgPiB4ZWQu YWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDog UCAzMTQyMjozMTUwNig4NCkgYWNrIDIyIHdpbiA1NzkyIDxub3Asbm9wLHRp bWVzdGFtcCA4Nzc0NDY3MDkgODU2OTkzNDY+IChERikNCjEwMTI5NDIzMTYu MDI5NDM5IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5h Y2wubGFubC5nb3YuMjcwOTogLiAyMjoyMigwKSBhY2sgMzE1MDYgd2luIDMz MTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTM0NiA4Nzc0NDY3MDk+IChE RikNCjEwMTI5NDIzMTYuMDI5NDM5IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292 LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAzMTUwNjozMTgx NigzMTApIGFjayAyMiB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3 NDQ2NzA5IDg1Njk5MzQ2PiAoREYpDQoxMDEyOTQyMzE2LjAyOTQzOSBldGgw IDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292 LjI3MDk6IC4gMjI6MjIoMCkgYWNrIDMxODE2IHdpbiAzMzE5NiA8bm9wLG5v cCx0aW1lc3RhbXAgODU2OTkzNDYgODc3NDQ2NzA5PiAoREYpDQoxMDEyOTQy MzE2LjAyOTQzOSBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1 ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMzE4MTY6MzIxOTQoMzc4KSBhY2sg MjIgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NjcwOSA4NTY5 OTM0Nj4gKERGKQ0KMTAxMjk0MjMxNi4wMzA0MTYgZXRoMCA8IGJsdWUuYWNs LmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDIy OjIyKDApIGFjayAzMjE5NCB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0YW1w IDg1Njk5MzQ2IDg3NzQ0NjcwOT4gKERGKQ0KMTAxMjk0MjMxNi4wMzA0MTYg ZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5s Lmdvdi4yNzA5OiBQIDIyOjIzKDEpIGFjayAzMjE5NCB3aW4gMzMxOTYgPG5v cCxub3AsdGltZXN0YW1wIDg1Njk5MzQ2IDg3NzQ0NjcwOT4gKERGKQ0KMTAx Mjk0MjMxNi4wMzEzOTIgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+ IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDMyMTk0OjMyMjc4KDg0KSBh Y2sgMjMgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NjcxMSA4 NTY5OTM0Nj4gKERGKQ0KMTAxMjk0MjMxNi4wNjg1MDQgZXRoMCA8IGJsdWUu YWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAu IDIzOjIzKDApIGFjayAzMjI3OCB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0 YW1wIDg1Njk5MzUwIDg3NzQ0NjcxMT4gKERGKQ0KMTAxMjk0MjMxNi4wNjg1 MDQgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxh bmwuZ292LjMyNzkwOiBQIDMyMjc4OjMyOTU1KDY3NykgYWNrIDIzIHdpbiA1 NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDY3NDkgODU2OTkzNTA+IChE RikNCjEwMTI5NDIzMTYuMDY4NTA0IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdv di4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiAyMzoyMygwKSBh Y2sgMzI5NTUgd2luIDMzMTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTM1 MCA4Nzc0NDY3NDk+IChERikNCjEwMTI5NDIzMTYuMDY5NDgxIGV0aDAgPiB4 ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5 MDogUCAzMjk1NTozMzAzOSg4NCkgYWNrIDIzIHdpbiA1NzkyIDxub3Asbm9w LHRpbWVzdGFtcCA4Nzc0NDY3NTAgODU2OTkzNTA+IChERikNCjEwMTI5NDIz MTYuMDY5NDgxIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhl ZC5hY2wubGFubC5nb3YuMjcwOTogLiAyMzoyMygwKSBhY2sgMzMwMzkgd2lu IDMzMTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTM1MCA4Nzc0NDY3NTA+ IChERikNCjEwMTI5NDIzMTYuMDY5NDgxIGV0aDAgPiB4ZWQuYWNsLmxhbmwu Z292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAzMzAzOToz MzcyNyg2ODgpIGFjayAyMyB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAg ODc3NDQ2NzUwIDg1Njk5MzUwPiAoREYpDQoxMDEyOTQyMzE2LjA2OTQ4MSBl dGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwu Z292LjI3MDk6IC4gMjM6MjMoMCkgYWNrIDMzNzI3IHdpbiAzMzE5NiA8bm9w LG5vcCx0aW1lc3RhbXAgODU2OTkzNTAgODc3NDQ2NzUwPiAoREYpDQoxMDEy OTQyMzE2LjA2OTQ4MSBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAg PiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IFAgMjM6MjQoMSkgYWNrIDMzNzI3 IHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkzNTAgODc3NDQ2 NzUwPiAoREYpDQoxMDEyOTQyMzE2LjA3MDQ1NyBldGgwID4geGVkLmFjbC5s YW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMzM3 Mjc6MzM4MTEoODQpIGFjayAyNCB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3Rh bXAgODc3NDQ2NzUxIDg1Njk5MzUwPiAoREYpDQoxMDEyOTQyMzE2LjEwODU0 NSBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxh bmwuZ292LjI3MDk6IC4gMjQ6MjQoMCkgYWNrIDMzODExIHdpbiAzMzE5NiA8 bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkzNTQgODc3NDQ2NzUxPiAoREYpDQox MDEyOTQyMzE2LjEwODU0NSBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5 ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMzM4MTE6MzQ0ODgoNjc3 KSBhY2sgMjQgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0Njc5 MCA4NTY5OTM1ND4gKERGKQ0KMTAxMjk0MjMxNi4xMDg1NDUgZXRoMCA8IGJs dWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5 OiAuIDI0OjI0KDApIGFjayAzNDQ4OCB3aW4gMzMxOTYgPG5vcCxub3AsdGlt ZXN0YW1wIDg1Njk5MzU0IDg3NzQ0Njc5MD4gKERGKQ0KMTAxMjk0MjMxNi4x MDk1MjIgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNs LmxhbmwuZ292LjMyNzkwOiBQIDM0NDg4OjM0NTcyKDg0KSBhY2sgMjQgd2lu IDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0Njc5MSA4NTY5OTM1ND4g KERGKQ0KMTAxMjk0MjMxNi4xMDk1MjIgZXRoMCA8IGJsdWUuYWNsLmxhbmwu Z292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDI0OjI0KDAp IGFjayAzNDU3MiB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5 MzU0IDg3NzQ0Njc5MT4gKERGKQ0KMTAxMjk0MjMxNi4xMDk1MjIgZXRoMCA+ IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMy NzkwOiBQIDM0NTcyOjM1MjU5KDY4NykgYWNrIDI0IHdpbiA1NzkyIDxub3As bm9wLHRpbWVzdGFtcCA4Nzc0NDY3OTEgODU2OTkzNTQ+IChERikNCjEwMTI5 NDIzMTYuMTEwNDk5IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+ IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiAyNDoyNCgwKSBhY2sgMzUyNTkg d2luIDMzMTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTM1NCA4Nzc0NDY3 OTE+IChERikNCjEwMTI5NDIzMTYuMTEwNDk5IGV0aDAgPiB4ZWQuYWNsLmxh bmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAzNTI1 OTozNTI2MCgxKSBhY2sgMjQgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1w IDg3NzQ0Njc5MiA4NTY5OTM1ND4gKERGKQ0KMTAxMjk0MjMxNi4xMTA0OTkg ZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5s Lmdvdi4yNzA5OiAuIDI0OjI0KDApIGFjayAzNTI2MCB3aW4gMzMxOTYgPG5v cCxub3AsdGltZXN0YW1wIDg1Njk5MzU0IDg3NzQ0Njc5Mj4gKERGKQ0KMTAx Mjk0MjMxNi4xMTA0OTkgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkw ID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiBQIDI0OjI1KDEpIGFjayAzNTI2 MCB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5MzU0IDg3NzQ0 Njc5Mj4gKERGKQ0KMTAxMjk0MjMxNi4xMTE0NzUgZXRoMCA+IHhlZC5hY2wu bGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDM1 MjYwOjM1MzQ0KDg0KSBhY2sgMjUgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0 YW1wIDg3NzQ0Njc5MyA4NTY5OTM1ND4gKERGKQ0KMTAxMjk0MjMxNi4xNDg1 ODcgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5s YW5sLmdvdi4yNzA5OiAuIDI1OjI1KDApIGFjayAzNTM0NCB3aW4gMzMxOTYg PG5vcCxub3AsdGltZXN0YW1wIDg1Njk5MzU4IDg3NzQ0Njc5Mz4gKERGKQ0K MTAxMjk0MjMxNi4xNDg1ODcgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcw OSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDM1MzQ0OjM2MDIxKDY3 NykgYWNrIDI1IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDY4 MzEgODU2OTkzNTg+IChERikNCjEwMTI5NDIzMTYuMTQ4NTg3IGV0aDAgPCBi bHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcw OTogLiAyNToyNSgwKSBhY2sgMzYwMjEgd2luIDMzMTk2IDxub3Asbm9wLHRp bWVzdGFtcCA4NTY5OTM1OCA4Nzc0NDY4MzE+IChERikNCjEwMTI5NDIzMTYu MTQ5NTY0IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFj bC5sYW5sLmdvdi4zMjc5MDogUCAzNjAyMTozNjEwNSg4NCkgYWNrIDI1IHdp biA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDY4MzIgODU2OTkzNTg+ IChERikNCjEwMTI5NDIzMTYuMTQ5NTY0IGV0aDAgPCBibHVlLmFjbC5sYW5s Lmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiAyNToyNSgw KSBhY2sgMzYxMDUgd2luIDMzMTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5 OTM1OCA4Nzc0NDY4MzI+IChERikNCjEwMTI5NDIzMTYuMTQ5NTY0IGV0aDAg PiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4z Mjc5MDogUCAzNjEwNTozNjc5Mig2ODcpIGFjayAyNSB3aW4gNTc5MiA8bm9w LG5vcCx0aW1lc3RhbXAgODc3NDQ2ODMyIDg1Njk5MzU4PiAoREYpDQoxMDEy OTQyMzE2LjE0OTU2NCBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAg PiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gMjU6MjUoMCkgYWNrIDM2Nzky IHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkzNTggODc3NDQ2 ODMyPiAoREYpDQoxMDEyOTQyMzE2LjE0OTU2NCBldGgwID4geGVkLmFjbC5s YW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMzY3 OTI6MzY3OTMoMSkgYWNrIDI1IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFt cCA4Nzc0NDY4MzIgODU2OTkzNTg+IChERikNCjEwMTI5NDIzMTYuMTUwNTQw IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFu bC5nb3YuMjcwOTogLiAyNToyNSgwKSBhY2sgMzY3OTMgd2luIDMzMTk2IDxu b3Asbm9wLHRpbWVzdGFtcCA4NTY5OTM1OCA4Nzc0NDY4MzI+IChERikNCjEw MTI5NDIzMTYuMTUwNTQwIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5 MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogUCAyNToyNigxKSBhY2sgMzY3 OTMgd2luIDMzMTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTM1OCA4Nzc0 NDY4MzI+IChERikNCjEwMTI5NDIzMTYuMTUwNTQwIGV0aDAgPiB4ZWQuYWNs LmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAz Njc5MzozNjg3Nyg4NCkgYWNrIDI2IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVz dGFtcCA4Nzc0NDY4MzMgODU2OTkzNTg+IChERikNCjEwMTI5NDIzMTYuMTg4 NjI4IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wu bGFubC5nb3YuMjcwOTogLiAyNjoyNigwKSBhY2sgMzY4Nzcgd2luIDMzMTk2 IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTM2MiA4Nzc0NDY4MzM+IChERikN CjEwMTI5NDIzMTYuMTg4NjI4IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3 MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAzNjg3NzozNzU1NCg2 NzcpIGFjayAyNiB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ2 ODcyIDg1Njk5MzYyPiAoREYpDQoxMDEyOTQyMzE2LjE4ODYyOCBldGgwIDwg Ymx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3 MDk6IC4gMjY6MjYoMCkgYWNrIDM3NTU0IHdpbiAzMzE5NiA8bm9wLG5vcCx0 aW1lc3RhbXAgODU2OTkzNjIgODc3NDQ2ODcyPiAoREYpDQoxMDEyOTQyMzE2 LjE4OTYwNSBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5h Y2wubGFubC5nb3YuMzI3OTA6IFAgMzc1NTQ6Mzc2MzgoODQpIGFjayAyNiB3 aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ2ODczIDg1Njk5MzYy PiAoREYpDQoxMDEyOTQyMzE2LjE4OTYwNSBldGgwIDwgYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gMjY6MjYo MCkgYWNrIDM3NjM4IHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2 OTkzNjIgODc3NDQ2ODczPiAoREYpDQoxMDEyOTQyMzE2LjE4OTYwNSBldGgw ID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3Yu MzI3OTA6IFAgMzc2Mzg6Mzc5NDgoMzEwKSBhY2sgMjYgd2luIDU3OTIgPG5v cCxub3AsdGltZXN0YW1wIDg3NzQ0Njg3MyA4NTY5OTM2Mj4gKERGKQ0KMTAx Mjk0MjMxNi4xODk2MDUgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkw ID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDI2OjI2KDApIGFjayAzNzk0 OCB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5MzYyIDg3NzQ0 Njg3Mz4gKERGKQ0KMTAxMjk0MjMxNi4xODk2MDUgZXRoMCA+IHhlZC5hY2wu bGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDM3 OTQ4OjM4MzI2KDM3OCkgYWNrIDI2IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVz dGFtcCA4Nzc0NDY4NzMgODU2OTkzNjI+IChERikNCjEwMTI5NDIzMTYuMTkw NTgyIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wu bGFubC5nb3YuMjcwOTogLiAyNjoyNigwKSBhY2sgMzgzMjYgd2luIDMzMTk2 IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTM2MiA4Nzc0NDY4NzM+IChERikN CjEwMTI5NDIzMTYuMTkwNTgyIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4z Mjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogUCAyNjoyNygxKSBhY2sg MzgzMjYgd2luIDMzMTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTM2MiA4 Nzc0NDY4NzM+IChERikNCjEwMTI5NDIzMTYuMTkxNTU4IGV0aDAgPiB4ZWQu YWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDog UCAzODMyNjozODQxMCg4NCkgYWNrIDI3IHdpbiA1NzkyIDxub3Asbm9wLHRp bWVzdGFtcCA4Nzc0NDY4NzUgODU2OTkzNjI+IChERikNCjEwMTI5NDIzMTYu MjI4NjcwIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5h Y2wubGFubC5nb3YuMjcwOTogLiAyNzoyNygwKSBhY2sgMzg0MTAgd2luIDMz MTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTM2NiA4Nzc0NDY4NzU+IChE RikNCjEwMTI5NDIzMTYuMjI4NjcwIGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292 LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAzODQxMDozOTA4 Nyg2NzcpIGFjayAyNyB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3 NDQ2OTEzIDg1Njk5MzY2PiAoREYpDQoxMDEyOTQyMzE2LjIyODY3MCBldGgw IDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292 LjI3MDk6IC4gMjc6MjcoMCkgYWNrIDM5MDg3IHdpbiAzMzE5NiA8bm9wLG5v cCx0aW1lc3RhbXAgODU2OTkzNjYgODc3NDQ2OTEzPiAoREYpDQoxMDEyOTQy MzE2LjIyOTY0NiBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1 ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMzkwODc6MzkxNzEoODQpIGFjayAy NyB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ2OTE0IDg1Njk5 MzY2PiAoREYpDQoxMDEyOTQyMzE2LjIyOTY0NiBldGgwIDwgYmx1ZS5hY2wu bGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gMjc6 MjcoMCkgYWNrIDM5MTcxIHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAg ODU2OTkzNjYgODc3NDQ2OTE0PiAoREYpDQoxMDEyOTQyMzE2LjIyOTY0NiBl dGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5n b3YuMzI3OTA6IFAgMzkxNzE6Mzk0ODEoMzEwKSBhY2sgMjcgd2luIDU3OTIg PG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NjkxNCA4NTY5OTM2Nj4gKERGKQ0K MTAxMjk0MjMxNi4yMjk2NDYgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMy NzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDI3OjI3KDApIGFjayAz OTQ4MSB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5MzY2IDg3 NzQ0NjkxND4gKERGKQ0KMTAxMjk0MjMxNi4yMjk2NDYgZXRoMCA+IHhlZC5h Y2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQ IDM5NDgxOjM5ODU5KDM3OCkgYWNrIDI3IHdpbiA1NzkyIDxub3Asbm9wLHRp bWVzdGFtcCA4Nzc0NDY5MTQgODU2OTkzNjY+IChERikNCjEwMTI5NDIzMTYu MjMwNjIzIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5h Y2wubGFubC5nb3YuMjcwOTogLiAyNzoyNygwKSBhY2sgMzk4NTkgd2luIDMz MTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTM2NiA4Nzc0NDY5MTQ+IChE RikNCjEwMTI5NDIzMTYuMjMwNjIzIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdv di4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogUCAyNzoyOCgxKSBh Y2sgMzk4NTkgd2luIDMzMTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTM2 NiA4Nzc0NDY5MTQ+IChERikNCjEwMTI5NDIzMTYuMjMwNjIzIGV0aDAgPiB4 ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5 MDogUCAzOTg1OTozOTk0Myg4NCkgYWNrIDI4IHdpbiA1NzkyIDxub3Asbm9w LHRpbWVzdGFtcCA4Nzc0NDY5MTUgODU2OTkzNjY+IChERikNCjEwMTI5NDIz MTYuMjY4NzExIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhl ZC5hY2wubGFubC5nb3YuMjcwOTogLiAyODoyOCgwKSBhY2sgMzk5NDMgd2lu IDMzMTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTM3MCA4Nzc0NDY5MTU+ IChERikNCjEwMTI5NDIzMTYuMjY4NzExIGV0aDAgPiB4ZWQuYWNsLmxhbmwu Z292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAzOTk0Mzo0 MDYyMCg2NzcpIGFjayAyOCB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAg ODc3NDQ2OTU0IDg1Njk5MzcwPiAoREYpDQoxMDEyOTQyMzE2LjI2ODcxMSBl dGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwu Z292LjI3MDk6IC4gMjg6MjgoMCkgYWNrIDQwNjIwIHdpbiAzMzE5NiA8bm9w LG5vcCx0aW1lc3RhbXAgODU2OTkzNzAgODc3NDQ2OTU0PiAoREYpDQoxMDEy OTQyMzE2LjI2OTY4OCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4g Ymx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgNDA2MjA6NDA3MDQoODQpIGFj ayAyOCB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ2OTU1IDg1 Njk5MzcwPiAoREYpDQoxMDEyOTQyMzE2LjI2OTY4OCBldGgwIDwgYmx1ZS5h Y2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4g Mjg6MjgoMCkgYWNrIDQwNzA0IHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1lc3Rh bXAgODU2OTkzNzAgODc3NDQ2OTU1PiAoREYpDQoxMDEyOTQyMzE2LjI2OTY4 OCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTA6IFAgNDA3MDQ6NDEzOTEoNjg3KSBhY2sgMjggd2luIDU3 OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0Njk1NSA4NTY5OTM3MD4gKERG KQ0KMTAxMjk0MjMxNi4yNjk2ODggZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292 LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDI4OjI4KDApIGFj ayA0MTM5MSB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5Mzcw IDg3NzQ0Njk1NT4gKERGKQ0KMTAxMjk0MjMxNi4yNjk2ODggZXRoMCA+IHhl ZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkw OiBQIDQxMzkxOjQxMzkyKDEpIGFjayAyOCB3aW4gNTc5MiA8bm9wLG5vcCx0 aW1lc3RhbXAgODc3NDQ2OTU1IDg1Njk5MzcwPiAoREYpDQoxMDEyOTQyMzE2 LjI3MDY2NSBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQu YWNsLmxhbmwuZ292LjI3MDk6IC4gMjg6MjgoMCkgYWNrIDQxMzkyIHdpbiAz MzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkzNzAgODc3NDQ2OTU1PiAo REYpDQoxMDEyOTQyMzE2LjI3MDY2NSBldGgwIDwgYmx1ZS5hY2wubGFubC5n b3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IFAgMjg6MjkoMSkg YWNrIDQxMzkyIHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkz NzAgODc3NDQ2OTU1PiAoREYpDQoxMDEyOTQyMzE2LjI3MDY2NSBldGgwID4g eGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3 OTA6IFAgNDEzOTI6NDE0NzYoODQpIGFjayAyOSB3aW4gNTc5MiA8bm9wLG5v cCx0aW1lc3RhbXAgODc3NDQ2OTU2IDg1Njk5MzcwPiAoREYpDQoxMDEyOTQy MzE2LjMwODc1MyBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4 ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gMjk6MjkoMCkgYWNrIDQxNDc2IHdp biAzMzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkzNzQgODc3NDQ2OTU2 PiAoREYpDQoxMDEyOTQyMzE2LjMwODc1MyBldGgwID4geGVkLmFjbC5sYW5s Lmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgNDE0NzY6 NDIxNTMoNjc3KSBhY2sgMjkgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1w IDg3NzQ0Njk5NSA4NTY5OTM3ND4gKERGKQ0KMTAxMjk0MjMxNi4zMDg3NTMg ZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5s Lmdvdi4yNzA5OiAuIDI5OjI5KDApIGFjayA0MjE1MyB3aW4gMzMxOTYgPG5v cCxub3AsdGltZXN0YW1wIDg1Njk5Mzc0IDg3NzQ0Njk5NT4gKERGKQ0KMTAx Mjk0MjMxNi4zMDk3MjkgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+ IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDQyMTUzOjQyMjM3KDg0KSBh Y2sgMjkgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0Njk5NiA4 NTY5OTM3ND4gKERGKQ0KMTAxMjk0MjMxNi4zMDk3MjkgZXRoMCA8IGJsdWUu YWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAu IDI5OjI5KDApIGFjayA0MjIzNyB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0 YW1wIDg1Njk5Mzc0IDg3NzQ0Njk5Nj4gKERGKQ0KMTAxMjk0MjMxNi4zMDk3 MjkgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxh bmwuZ292LjMyNzkwOiBQIDQyMjM3OjQyNTQ3KDMxMCkgYWNrIDI5IHdpbiA1 NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDY5OTYgODU2OTkzNzQ+IChE RikNCjEwMTI5NDIzMTYuMzA5NzI5IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdv di4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiAyOToyOSgwKSBh Y2sgNDI1NDcgd2luIDMzMTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTM3 NCA4Nzc0NDY5OTY+IChERikNCjEwMTI5NDIzMTYuMzA5NzI5IGV0aDAgPiB4 ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5 MDogUCA0MjU0Nzo0MjkyNSgzNzgpIGFjayAyOSB3aW4gNTc5MiA8bm9wLG5v cCx0aW1lc3RhbXAgODc3NDQ2OTk2IDg1Njk5Mzc0PiAoREYpDQoxMDEyOTQy MzE2LjMxMDcwNiBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4 ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gMjk6MjkoMCkgYWNrIDQyOTI1IHdp biAzMzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkzNzQgODc3NDQ2OTk2 PiAoREYpDQoxMDEyOTQyMzE2LjMxMDcwNiBldGgwIDwgYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IFAgMjk6MzAo MSkgYWNrIDQyOTI1IHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2 OTkzNzQgODc3NDQ2OTk2PiAoREYpDQoxMDEyOTQyMzE2LjMxMTY4MyBldGgw ID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3Yu MzI3OTA6IFAgNDI5MjU6NDMwMDkoODQpIGFjayAzMCB3aW4gNTc5MiA8bm9w LG5vcCx0aW1lc3RhbXAgODc3NDQ2OTk4IDg1Njk5Mzc0PiAoREYpDQoxMDEy OTQyMzE2LjM0ODc5NCBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAg PiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gMzA6MzAoMCkgYWNrIDQzMDA5 IHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkzNzggODc3NDQ2 OTk4PiAoREYpDQoxMDEyOTQyMzE2LjM0ODc5NCBldGgwID4geGVkLmFjbC5s YW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgNDMw MDk6NDM2ODYoNjc3KSBhY2sgMzAgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0 YW1wIDg3NzQ0NzAzNiA4NTY5OTM3OD4gKERGKQ0KMTAxMjk0MjMxNi4zNDg3 OTQgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5s YW5sLmdvdi4yNzA5OiAuIDMwOjMwKDApIGFjayA0MzY4NiB3aW4gMzMxOTYg PG5vcCxub3AsdGltZXN0YW1wIDg1Njk5Mzc4IDg3NzQ0NzAzNj4gKERGKQ0K MTAxMjk0MjMxNi4zNDk3NzEgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcw OSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDQzNjg2OjQzNzcwKDg0 KSBhY2sgMzAgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NzAz NyA4NTY5OTM3OD4gKERGKQ0KMTAxMjk0MjMxNi4zNDk3NzEgZXRoMCA8IGJs dWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5 OiAuIDMwOjMwKDApIGFjayA0Mzc3MCB3aW4gMzMxOTYgPG5vcCxub3AsdGlt ZXN0YW1wIDg1Njk5Mzc4IDg3NzQ0NzAzNz4gKERGKQ0KMTAxMjk0MjMxNi4z NDk3NzEgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNs LmxhbmwuZ292LjMyNzkwOiBQIDQzNzcwOjQ0NDU3KDY4NykgYWNrIDMwIHdp biA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDcwMzcgODU2OTkzNzg+ IChERikNCjEwMTI5NDIzMTYuMzQ5NzcxIGV0aDAgPCBibHVlLmFjbC5sYW5s Lmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiAzMDozMCgw KSBhY2sgNDQ0NTcgd2luIDMzMTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5 OTM3OCA4Nzc0NDcwMzc+IChERikNCjEwMTI5NDIzMTYuMzQ5NzcxIGV0aDAg PiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4z Mjc5MDogUCA0NDQ1Nzo0NDQ1OCgxKSBhY2sgMzAgd2luIDU3OTIgPG5vcCxu b3AsdGltZXN0YW1wIDg3NzQ0NzAzNyA4NTY5OTM3OD4gKERGKQ0KMTAxMjk0 MjMxNi4zNTA3NDcgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4g eGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDMwOjMwKDApIGFjayA0NDQ1OCB3 aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5Mzc4IDg3NzQ0NzAz Nz4gKERGKQ0KMTAxMjk0MjMxNi4zNTA3NDcgZXRoMCA8IGJsdWUuYWNsLmxh bmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiBQIDMwOjMx KDEpIGFjayA0NDQ1OCB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0YW1wIDg1 Njk5Mzc4IDg3NzQ0NzAzNz4gKERGKQ0KMTAxMjk0MjMxNi4zNTA3NDcgZXRo MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292 LjMyNzkwOiBQIDQ0NDU4OjQ0NTQyKDg0KSBhY2sgMzEgd2luIDU3OTIgPG5v cCxub3AsdGltZXN0YW1wIDg3NzQ0NzAzOCA4NTY5OTM3OD4gKERGKQ0KMTAx Mjk0MjMxNi4zODg4MzYgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkw ID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDMxOjMxKDApIGFjayA0NDU0 MiB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5MzgyIDg3NzQ0 NzAzOD4gKERGKQ0KMTAxMjk0MjMxNi4zODg4MzYgZXRoMCA+IHhlZC5hY2wu bGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDQ0 NTQyOjQ1MjE5KDY3NykgYWNrIDMxIHdpbiA1NzkyIDxub3Asbm9wLHRpbWVz dGFtcCA4Nzc0NDcwNzcgODU2OTkzODI+IChERikNCjEwMTI5NDIzMTYuMzg4 ODM2IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wu bGFubC5nb3YuMjcwOTogLiAzMTozMSgwKSBhY2sgNDUyMTkgd2luIDMzMTk2 IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTM4MiA4Nzc0NDcwNzc+IChERikN CjEwMTI5NDIzMTYuMzg5ODEyIGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3 MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCA0NTIxOTo0NTMwMyg4 NCkgYWNrIDMxIHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDcw NzggODU2OTkzODI+IChERikNCjEwMTI5NDIzMTYuMzg5ODEyIGV0aDAgPCBi bHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcw OTogLiAzMTozMSgwKSBhY2sgNDUzMDMgd2luIDMzMTk2IDxub3Asbm9wLHRp bWVzdGFtcCA4NTY5OTM4MiA4Nzc0NDcwNzg+IChERikNCjEwMTI5NDIzMTYu Mzg5ODEyIGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFj bC5sYW5sLmdvdi4zMjc5MDogUCA0NTMwMzo0NTYxMygzMTApIGFjayAzMSB3 aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ3MDc4IDg1Njk5Mzgy PiAoREYpDQoxMDEyOTQyMzE2LjM4OTgxMiBldGgwIDwgYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gMzE6MzEo MCkgYWNrIDQ1NjEzIHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2 OTkzODIgODc3NDQ3MDc4PiAoREYpDQoxMDEyOTQyMzE2LjM4OTgxMiBldGgw ID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3Yu MzI3OTA6IFAgNDU2MTM6NDU5OTEoMzc4KSBhY2sgMzEgd2luIDU3OTIgPG5v cCxub3AsdGltZXN0YW1wIDg3NzQ0NzA3OCA4NTY5OTM4Mj4gKERGKQ0KMTAx Mjk0MjMxNi4zOTA3ODkgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkw ID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDMxOjMxKDApIGFjayA0NTk5 MSB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5MzgyIDg3NzQ0 NzA3OD4gKERGKQ0KMTAxMjk0MjMxNi4zOTA3ODkgZXRoMCA8IGJsdWUuYWNs LmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiBQIDMx OjMyKDEpIGFjayA0NTk5MSB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0YW1w IDg1Njk5MzgyIDg3NzQ0NzA3OD4gKERGKQ0KMTAxMjk0MjMxNi4zOTA3ODkg ZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwu Z292LjMyNzkwOiBQIDQ1OTkxOjQ2MDc1KDg0KSBhY2sgMzIgd2luIDU3OTIg PG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NzA3OSA4NTY5OTM4Mj4gKERGKQ0K MTAxMjk0MjMxNi40Mjg4NzcgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMy NzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDMyOjMyKDApIGFjayA0 NjA3NSB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5Mzg2IDg3 NzQ0NzA3OT4gKERGKQ0KMTAxMjk0MjMxNi40Mjg4NzcgZXRoMCA+IHhlZC5h Y2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQ IDQ2MDc1OjQ2NzUyKDY3NykgYWNrIDMyIHdpbiA1NzkyIDxub3Asbm9wLHRp bWVzdGFtcCA4Nzc0NDcxMTggODU2OTkzODY+IChERikNCjEwMTI5NDIzMTYu NDI4ODc3IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5h Y2wubGFubC5nb3YuMjcwOTogLiAzMjozMigwKSBhY2sgNDY3NTIgd2luIDMz MTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTM4NiA4Nzc0NDcxMTg+IChE RikNCjEwMTI5NDIzMTYuNDI5ODU0IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292 LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCA0Njc1Mjo0Njgz Nig4NCkgYWNrIDMyIHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0 NDcxMTkgODU2OTkzODY+IChERikNCjEwMTI5NDIzMTYuNDI5ODU0IGV0aDAg PCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3Yu MjcwOTogLiAzMjozMigwKSBhY2sgNDY4MzYgd2luIDMzMTk2IDxub3Asbm9w LHRpbWVzdGFtcCA4NTY5OTM4NiA4Nzc0NDcxMTk+IChERikNCjEwMTI5NDIz MTYuNDI5ODU0IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVl LmFjbC5sYW5sLmdvdi4zMjc5MDogUCA0NjgzNjo0NzUyMyg2ODcpIGFjayAz MiB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ3MTE5IDg1Njk5 Mzg2PiAoREYpDQoxMDEyOTQyMzE2LjQyOTg1NCBldGgwIDwgYmx1ZS5hY2wu bGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gMzI6 MzIoMCkgYWNrIDQ3NTIzIHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAg ODU2OTkzODYgODc3NDQ3MTE5PiAoREYpDQoxMDEyOTQyMzE2LjQzMDgzMCBl dGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5n b3YuMzI3OTA6IFAgNDc1MjM6NDc1MjQoMSkgYWNrIDMyIHdpbiA1NzkyIDxu b3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDcxMjAgODU2OTkzODY+IChERikNCjEw MTI5NDIzMTYuNDMwODMwIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5 MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiAzMjozMigwKSBhY2sgNDc1 MjQgd2luIDMzMTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTM4NiA4Nzc0 NDcxMjA+IChERikNCjEwMTI5NDIzMTYuNDMwODMwIGV0aDAgPCBibHVlLmFj bC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogUCAz MjozMygxKSBhY2sgNDc1MjQgd2luIDMzMTk2IDxub3Asbm9wLHRpbWVzdGFt cCA4NTY5OTM4NiA4Nzc0NDcxMjA+IChERikNCjEwMTI5NDIzMTYuNDMxODA3 IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5s Lmdvdi4zMjc5MDogUCA0NzUyNDo0NzYwOCg4NCkgYWNrIDMzIHdpbiA1Nzky IDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDcxMjEgODU2OTkzODY+IChERikN CjEwMTI5NDIzMTYuNDY4OTE5IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4z Mjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiAzMzozMygwKSBhY2sg NDc2MDggd2luIDMzMTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTM5MCA4 Nzc0NDcxMjE+IChERikNCjEwMTI5NDIzMTYuNDY4OTE5IGV0aDAgPiB4ZWQu YWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDog UCA0NzYwODo0ODI4NSg2NzcpIGFjayAzMyB3aW4gNTc5MiA8bm9wLG5vcCx0 aW1lc3RhbXAgODc3NDQ3MTU5IDg1Njk5MzkwPiAoREYpDQoxMDEyOTQyMzE2 LjQ2ODkxOSBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQu YWNsLmxhbmwuZ292LjI3MDk6IC4gMzM6MzMoMCkgYWNrIDQ4Mjg1IHdpbiAz MzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkzOTAgODc3NDQ3MTU5PiAo REYpDQoxMDEyOTQyMzE2LjQ2OTg5NSBldGgwID4geGVkLmFjbC5sYW5sLmdv di4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgNDgyODU6NDgz NjkoODQpIGFjayAzMyB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3 NDQ3MTYwIDg1Njk5MzkwPiAoREYpDQoxMDEyOTQyMzE2LjQ2OTg5NSBldGgw IDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292 LjI3MDk6IC4gMzM6MzMoMCkgYWNrIDQ4MzY5IHdpbiAzMzE5NiA8bm9wLG5v cCx0aW1lc3RhbXAgODU2OTkzOTAgODc3NDQ3MTYwPiAoREYpDQoxMDEyOTQy MzE2LjQ2OTg5NSBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1 ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgNDgzNjk6NDkwNTYoNjg3KSBhY2sg MzMgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NzE2MCA4NTY5 OTM5MD4gKERGKQ0KMTAxMjk0MjMxNi40Njk4OTUgZXRoMCA8IGJsdWUuYWNs LmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDMz OjMzKDApIGFjayA0OTA1NiB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0YW1w IDg1Njk5MzkwIDg3NzQ0NzE2MD4gKERGKQ0KMTAxMjk0MjMxNi40Njk4OTUg ZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwu Z292LjMyNzkwOiBQIDQ5MDU2OjQ5MDU3KDEpIGFjayAzMyB3aW4gNTc5MiA8 bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ3MTYwIDg1Njk5MzkwPiAoREYpDQox MDEyOTQyMzE2LjQ3MDg3MiBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3 OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gMzM6MzMoMCkgYWNrIDQ5 MDU3IHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkzOTAgODc3 NDQ3MTYwPiAoREYpDQoxMDEyOTQyMzE2LjQ3MDg3MiBldGgwIDwgYmx1ZS5h Y2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IFAg MzM6MzQoMSkgYWNrIDQ5MDU3IHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1lc3Rh bXAgODU2OTkzOTAgODc3NDQ3MTYwPiAoREYpDQoxMDEyOTQyMzE2LjQ3MDg3 MiBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTA6IFAgNDkwNTc6NDkxNDEoODQpIGFjayAzNCB3aW4gNTc5 MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ3MTYxIDg1Njk5MzkwPiAoREYp DQoxMDEyOTQyMzE2LjUwODk2MCBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3Yu MzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gMzQ6MzQoMCkgYWNr IDQ5MTQxIHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTkzOTQg ODc3NDQ3MTYxPiAoREYpDQoxMDEyOTQyMzE2LjUwODk2MCBldGgwID4geGVk LmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6 IFAgNDkxNDE6NDk4MTgoNjc3KSBhY2sgMzQgd2luIDU3OTIgPG5vcCxub3As dGltZXN0YW1wIDg3NzQ0NzIwMCA4NTY5OTM5ND4gKERGKQ0KMTAxMjk0MjMx Ni41MDg5NjAgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVk LmFjbC5sYW5sLmdvdi4yNzA5OiAuIDM0OjM0KDApIGFjayA0OTgxOCB3aW4g MzMxOTYgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5Mzk0IDg3NzQ0NzIwMD4g KERGKQ0KMTAxMjk0MjMxNi41MDk5MzcgZXRoMCA+IHhlZC5hY2wubGFubC5n b3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDQ5ODE4OjQ5 OTAyKDg0KSBhY2sgMzQgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3 NzQ0NzIwMSA4NTY5OTM5ND4gKERGKQ0KMTAxMjk0MjMxNi41MDk5MzcgZXRo MCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdv di4yNzA5OiAuIDM0OjM0KDApIGFjayA0OTkwMiB3aW4gMzMxOTYgPG5vcCxu b3AsdGltZXN0YW1wIDg1Njk5Mzk0IDg3NzQ0NzIwMT4gKERGKQ0KMTAxMjk0 MjMxNi41MDk5MzcgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJs dWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDQ5OTAyOjUwNTg5KDY4NykgYWNr IDM0IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDcyMDEgODU2 OTkzOTQ+IChERikNCjEwMTI5NDIzMTYuNTEwOTEzIGV0aDAgPCBibHVlLmFj bC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiAz NDozNCgwKSBhY2sgNTA1ODkgd2luIDMzMTk2IDxub3Asbm9wLHRpbWVzdGFt cCA4NTY5OTM5NCA4Nzc0NDcyMDE+IChERikNCjEwMTI5NDIzMTYuNTEwOTEz IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5s Lmdvdi4zMjc5MDogUCA1MDU4OTo1MDU5MCgxKSBhY2sgMzQgd2luIDU3OTIg PG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NzIwMiA4NTY5OTM5ND4gKERGKQ0K MTAxMjk0MjMxNi41MTA5MTMgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMy NzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDM0OjM0KDApIGFjayA1 MDU5MCB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5Mzk0IDg3 NzQ0NzIwMj4gKERGKQ0KMTAxMjk0MjMxNi41MTA5MTMgZXRoMCA8IGJsdWUu YWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiBQ IDM0OjM1KDEpIGFjayA1MDU5MCB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0 YW1wIDg1Njk5Mzk0IDg3NzQ0NzIwMj4gKERGKQ0KMTAxMjk0MjMxNi41MTE4 OTAgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxh bmwuZ292LjMyNzkwOiBQIDUwNTkwOjUwNjc0KDg0KSBhY2sgMzUgd2luIDU3 OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NzIwMyA4NTY5OTM5ND4gKERG KQ0KMTAxMjk0MjMxNi41NDkwMDIgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292 LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDM1OjM1KDApIGFj ayA1MDY3NCB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5Mzk4 IDg3NzQ0NzIwMz4gKERGKQ0KMTAxMjk0MjMxNi41NDkwMDIgZXRoMCA+IHhl ZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkw OiBQIDUwNjc0OjUxMzUxKDY3NykgYWNrIDM1IHdpbiA1NzkyIDxub3Asbm9w LHRpbWVzdGFtcCA4Nzc0NDcyNDEgODU2OTkzOTg+IChERikNCjEwMTI5NDIz MTYuNTQ5MDAyIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhl ZC5hY2wubGFubC5nb3YuMjcwOTogLiAzNTozNSgwKSBhY2sgNTEzNTEgd2lu IDMzMTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTM5OCA4Nzc0NDcyNDE+ IChERikNCjEwMTI5NDIzMTYuNTQ5OTc4IGV0aDAgPiB4ZWQuYWNsLmxhbmwu Z292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCA1MTM1MTo1 MTQzNSg4NCkgYWNrIDM1IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4 Nzc0NDcyNDIgODU2OTkzOTg+IChERikNCjEwMTI5NDIzMTYuNTQ5OTc4IGV0 aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5n b3YuMjcwOTogLiAzNTozNSgwKSBhY2sgNTE0MzUgd2luIDMzMTk2IDxub3As bm9wLHRpbWVzdGFtcCA4NTY5OTM5OCA4Nzc0NDcyNDI+IChERikNCjEwMTI5 NDIzMTYuNTQ5OTc4IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBi bHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCA1MTQzNTo1MjEyMig2ODcpIGFj ayAzNSB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ3MjQyIDg1 Njk5Mzk4PiAoREYpDQoxMDEyOTQyMzE2LjU0OTk3OCBldGgwIDwgYmx1ZS5h Y2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4g MzU6MzUoMCkgYWNrIDUyMTIyIHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1lc3Rh bXAgODU2OTkzOTggODc3NDQ3MjQyPiAoREYpDQoxMDEyOTQyMzE2LjU0OTk3 OCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTA6IFAgNTIxMjI6NTIxMjMoMSkgYWNrIDM1IHdpbiA1Nzky IDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDcyNDIgODU2OTkzOTg+IChERikN CjEwMTI5NDIzMTYuNTUwOTU1IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4z Mjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiAzNTozNSgwKSBhY2sg NTIxMjMgd2luIDMzMTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTM5OCA4 Nzc0NDcyNDI+IChERikNCjEwMTI5NDIzMTYuNTUwOTU1IGV0aDAgPCBibHVl LmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTog UCAzNTozNigxKSBhY2sgNTIxMjMgd2luIDMzMTk2IDxub3Asbm9wLHRpbWVz dGFtcCA4NTY5OTM5OCA4Nzc0NDcyNDI+IChERikNCjEwMTI5NDIzMTYuNTUw OTU1IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5s YW5sLmdvdi4zMjc5MDogUCA1MjEyMzo1MjIwNyg4NCkgYWNrIDM2IHdpbiA1 NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDcyNDMgODU2OTkzOTg+IChE RikNCjEwMTI5NDIzMTYuNTg5MDQzIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdv di4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiAzNjozNigwKSBh Y2sgNTIyMDcgd2luIDMzMTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTQw MiA4Nzc0NDcyNDM+IChERikNCjEwMTI5NDIzMTYuNTg5MDQzIGV0aDAgPiB4 ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5 MDogUCA1MjIwNzo1Mjg4NCg2NzcpIGFjayAzNiB3aW4gNTc5MiA8bm9wLG5v cCx0aW1lc3RhbXAgODc3NDQ3MjgyIDg1Njk5NDAyPiAoREYpDQoxMDEyOTQy MzE2LjU4OTA0MyBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4 ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gMzY6MzYoMCkgYWNrIDUyODg0IHdp biAzMzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0MDIgODc3NDQ3Mjgy PiAoREYpDQoxMDEyOTQyMzE2LjU5MDAyMCBldGgwID4geGVkLmFjbC5sYW5s Lmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgNTI4ODQ6 NTI5NjgoODQpIGFjayAzNiB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAg ODc3NDQ3MjgzIDg1Njk5NDAyPiAoREYpDQoxMDEyOTQyMzE2LjU5MDAyMCBl dGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwu Z292LjI3MDk6IC4gMzY6MzYoMCkgYWNrIDUyOTY4IHdpbiAzMzE5NiA8bm9w LG5vcCx0aW1lc3RhbXAgODU2OTk0MDIgODc3NDQ3MjgzPiAoREYpDQoxMDEy OTQyMzE2LjU5MDAyMCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4g Ymx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgNTI5Njg6NTMyNzgoMzEwKSBh Y2sgMzYgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NzI4MyA4 NTY5OTQwMj4gKERGKQ0KMTAxMjk0MjMxNi41OTAwMjAgZXRoMCA8IGJsdWUu YWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAu IDM2OjM2KDApIGFjayA1MzI3OCB3aW4gMzMxOTYgPG5vcCxub3AsdGltZXN0 YW1wIDg1Njk5NDAyIDg3NzQ0NzI4Mz4gKERGKQ0KMTAxMjk0MjMxNi41OTAw MjAgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxh bmwuZ292LjMyNzkwOiBQIDUzMjc4OjUzNjU2KDM3OCkgYWNrIDM2IHdpbiA1 NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDcyODMgODU2OTk0MDI+IChE RikNCjEwMTI5NDIzMTYuNTkwOTk2IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdv di4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiAzNjozNigwKSBh Y2sgNTM2NTYgd2luIDMzMTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTQw MiA4Nzc0NDcyODM+IChERikNCjEwMTI5NDIzMTYuNTkwOTk2IGV0aDAgPCBi bHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcw OTogUCAzNjozNygxKSBhY2sgNTM2NTYgd2luIDMzMTk2IDxub3Asbm9wLHRp bWVzdGFtcCA4NTY5OTQwMiA4Nzc0NDcyODM+IChERikNCjEwMTI5NDIzMTYu NTkwOTk2IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFj bC5sYW5sLmdvdi4zMjc5MDogUCA1MzY1Njo1Mzc0MCg4NCkgYWNrIDM3IHdp biA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDcyODQgODU2OTk0MDI+ IChERikNCjEwMTI5NDIzMTYuNjI4MTA4IGV0aDAgPCBibHVlLmFjbC5sYW5s Lmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiAzNzozNygw KSBhY2sgNTM3NDAgd2luIDMzMTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5 OTQwNiA4Nzc0NDcyODQ+IChERikNCjEwMTI5NDIzMTYuNjI5MDg1IGV0aDAg PiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4z Mjc5MDogUCA1Mzc0MDo1NDQxNyg2NzcpIGFjayAzNyB3aW4gNTc5MiA8bm9w LG5vcCx0aW1lc3RhbXAgODc3NDQ3MzIzIDg1Njk5NDA2PiAoREYpDQoxMDEy OTQyMzE2LjYyOTA4NSBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAg PiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gMzc6MzcoMCkgYWNrIDU0NDE3 IHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0MDYgODc3NDQ3 MzIzPiAoREYpDQoxMDEyOTQyMzE2LjYzMDA2MSBldGgwID4geGVkLmFjbC5s YW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgNTQ0 MTc6NTQ1MDEoODQpIGFjayAzNyB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3Rh bXAgODc3NDQ3MzI0IDg1Njk5NDA2PiAoREYpDQoxMDEyOTQyMzE2LjYzMDA2 MSBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxh bmwuZ292LjI3MDk6IC4gMzc6MzcoMCkgYWNrIDU0NTAxIHdpbiAzMzE5NiA8 bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0MDYgODc3NDQ3MzI0PiAoREYpDQox MDEyOTQyMzE2LjYzMDA2MSBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5 ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgNTQ1MDE6NTQ4MTEoMzEw KSBhY2sgMzcgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NzMy NCA4NTY5OTQwNj4gKERGKQ0KMTAxMjk0MjMxNi42MzAwNjEgZXRoMCA8IGJs dWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5 OiAuIDM3OjM3KDApIGFjayA1NDgxMSB3aW4gMzMxOTYgPG5vcCxub3AsdGlt ZXN0YW1wIDg1Njk5NDA2IDg3NzQ0NzMyND4gKERGKQ0KMTAxMjk0MjMxNi42 MzAwNjEgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNs LmxhbmwuZ292LjMyNzkwOiBQIDU0ODExOjU1MTg5KDM3OCkgYWNrIDM3IHdp biA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDczMjQgODU2OTk0MDY+ IChERikNCjEwMTI5NDIzMTYuNjMxMDM4IGV0aDAgPCBibHVlLmFjbC5sYW5s Lmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiAzNzozNygw KSBhY2sgNTUxODkgd2luIDMzMTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5 OTQwNiA4Nzc0NDczMjQ+IChERikNCjEwMTI5NDIzMTYuNjMxMDM4IGV0aDAg PCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3Yu MjcwOTogUCAzNzozOCgxKSBhY2sgNTUxODkgd2luIDMzMTk2IDxub3Asbm9w LHRpbWVzdGFtcCA4NTY5OTQwNiA4Nzc0NDczMjQ+IChERikNCjEwMTI5NDIz MTYuNjMyMDE0IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVl LmFjbC5sYW5sLmdvdi4zMjc5MDogUCA1NTE4OTo1NTI3Myg4NCkgYWNrIDM4 IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDczMjYgODU2OTk0 MDY+IChERikNCjEwMTI5NDIzMTYuNjY4MTQ5IGV0aDAgPCBibHVlLmFjbC5s YW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiAzODoz OCgwKSBhY2sgNTUyNzMgd2luIDMzMTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4 NTY5OTQxMCA4Nzc0NDczMjY+IChERikNCjEwMTI5NDIzMTYuNjY4MTQ5IGV0 aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdv di4zMjc5MDogUCA1NTI3Mzo1NTk1MCg2NzcpIGFjayAzOCB3aW4gNTc5MiA8 bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ3MzYzIDg1Njk5NDEwPiAoREYpDQox MDEyOTQyMzE2LjY2OTEyNiBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3 OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gMzg6MzgoMCkgYWNrIDU1 OTUwIHdpbiAzMzE5NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0MTAgODc3 NDQ3MzYzPiAoREYpDQoxMDEyOTQyMzE2LjY3MDEwMyBldGgwID4geGVkLmFj bC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAg NTU5NTA6NTYwMzQoODQpIGFjayAzOCB3aW4gNTc5MiA8bm9wLG5vcCx0aW1l c3RhbXAgODc3NDQ3MzY1IDg1Njk5NDEwPiAoREYpDQoxMDEyOTQyMzE2LjY3 MDEwMyBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNs LmxhbmwuZ292LjI3MDk6IC4gMzg6MzgoMCkgYWNrIDU2MDM0IHdpbiAzMzE5 NiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0MTAgODc3NDQ3MzY1PiAoREYp DQoxMDEyOTQyMzE2LjY3MDEwMyBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4y NzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgNTYwMzQ6NTYzNDQo MzEwKSBhY2sgMzggd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0 NzM2NSA4NTY5OTQxMD4gKERGKQ0KMTAxMjk0MjMxNi42NzAxMDMgZXRoMCA8 IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4y NzA5OiAuIDM4OjM4KDApIGFjayA1NjM0NCB3aW4gMzMxOTYgPG5vcCxub3As dGltZXN0YW1wIDg1Njk5NDEwIDg3NzQ0NzM2NT4gKERGKQ0KMTAxMjk0MjMx Ni42NzAxMDMgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUu YWNsLmxhbmwuZ292LjMyNzkwOiBQIDU2MzQ0OjU2NzIyKDM3OCkgYWNrIDM4 IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDczNjUgODU2OTk0 MTA+IChERikNCjEwMTI5NDIzMTYuNjcxMDc5IGV0aDAgPCBibHVlLmFjbC5s YW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiAzODoz OCgwKSBhY2sgNTY3MjIgd2luIDMzMTk2IDxub3Asbm9wLHRpbWVzdGFtcCA4 NTY5OTQxMCA4Nzc0NDczNjU+IChERikNCjEwMTI5NDIzMTYuNjcxMDc5IGV0 aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5n b3YuMjcwOTogUCAzODozOSgxKSBhY2sgNTY3MjIgd2luIDMzMTk2IDxub3As bm9wLHRpbWVzdGFtcCA4NTY5OTQxMCA4Nzc0NDczNjU+IChERikNCjEwMTI5 NDIzMTYuNjcxMDc5IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBi bHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCA1NjcyMjo1NjgwNig4NCkgYWNr IDM5IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDczNjYgODU2 OTk0MTA+IChERikNCjEwMTI5NDIzMTYuNzAyMzMxIGV0aDAgPiB4ZWQuYWNs LmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogLiA1 NjgwNjo1ODI1NCgxNDQ4KSBhY2sgMzkgd2luIDU3OTIgPG5vcCxub3AsdGlt ZXN0YW1wIDg3NzQ0NzM5OCA4NTY5OTQxMD4gKERGKQ0KMTAxMjk0MjMxNi43 MDIzMzEgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFj bC5sYW5sLmdvdi4yNzA5OiAuIDM5OjM5KDApIGFjayA1ODI1NCB3aW4gMzYy MDAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NDEzIDg3NzQ0NzM2Nj4gKERG KQ0KMTAxMjk0MjMxNi43MDIzMzEgZXRoMCA+IHhlZC5hY2wubGFubC5nb3Yu MjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDU4MjU0OjU4MjU1 KDEpIGFjayAzOSB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ3 Mzk4IDg1Njk5NDEzPiAoREYpDQoxMDEyOTQyMzE2LjcwMzMwOCBldGgwIDwg Ymx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3 MDk6IFAgMzk6NDAoMSkgYWNrIDU4MjU1IHdpbiAzNjIwMCA8bm9wLG5vcCx0 aW1lc3RhbXAgODU2OTk0MTMgODc3NDQ3Mzk4PiAoREYpDQoxMDEyOTQyMzE2 LjcwMzMwOCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5h Y2wubGFubC5nb3YuMzI3OTA6IFAgNTgyNTU6NTgzMzkoODQpIGFjayA0MCB3 aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ3Mzk5IDg1Njk5NDEz PiAoREYpDQoxMDEyOTQyMzE2LjcwNDI4NCBldGgwID4geGVkLmFjbC5sYW5s Lmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IC4gNTgzMzk6 NTk3ODcoMTQ0OCkgYWNrIDQwIHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFt cCA4Nzc0NDc0MDAgODU2OTk0MTM+IChERikNCjEwMTI5NDIzMTYuNzA0Mjg0 IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFu bC5nb3YuMjcwOTogLiA0MDo0MCgwKSBhY2sgNTk3ODcgd2luIDM5MDk2IDxu b3Asbm9wLHRpbWVzdGFtcCA4NTY5OTQxMyA4Nzc0NDczOTk+IChERikNCjEw MTI5NDIzMTYuNzA0Mjg0IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkg PiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCA1OTc4Nzo1OTc4OCgxKSBh Y2sgNDAgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NzQwMCA4 NTY5OTQxMz4gKERGKQ0KMTAxMjk0MjMxNi43MDQyODQgZXRoMCA8IGJsdWUu YWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiBQ IDQwOjQxKDEpIGFjayA1OTc4OCB3aW4gMzkwOTYgPG5vcCxub3AsdGltZXN0 YW1wIDg1Njk5NDEzIDg3NzQ0NzQwMD4gKERGKQ0KMTAxMjk0MjMxNi43MDUy NjEgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxh bmwuZ292LjMyNzkwOiBQIDU5Nzg4OjU5ODcyKDg0KSBhY2sgNDEgd2luIDU3 OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NzQwMSA4NTY5OTQxMz4gKERG KQ0KMTAxMjk0MjMxNi43MTIwOTcgZXRoMCA+IHhlZC5hY2wubGFubC5nb3Yu MjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiAuIDU5ODcyOjYxMzIw KDE0NDgpIGFjayA0MSB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3 NDQ3NDA4IDg1Njk5NDEzPiAoREYpDQoxMDEyOTQyMzE2LjcxMjA5NyBldGgw IDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292 LjI3MDk6IC4gNDE6NDEoMCkgYWNrIDYxMzIwIHdpbiA0MTk5MiA8bm9wLG5v cCx0aW1lc3RhbXAgODU2OTk0MTQgODc3NDQ3NDAxPiAoREYpDQoxMDEyOTQy MzE2LjcxMjA5NyBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1 ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgNjEzMjA6NjEzMjEoMSkgYWNrIDQx IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDc0MDggODU2OTk0 MTQ+IChERikNCjEwMTI5NDIzMTYuNzEzMDc0IGV0aDAgPCBibHVlLmFjbC5s YW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogUCA0MTo0 MigxKSBhY2sgNjEzMjEgd2luIDQxOTkyIDxub3Asbm9wLHRpbWVzdGFtcCA4 NTY5OTQxNCA4Nzc0NDc0MDg+IChERikNCjEwMTI5NDIzMTYuNzEzMDc0IGV0 aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdv di4zMjc5MDogUCA2MTMyMTo2MTQwNSg4NCkgYWNrIDQyIHdpbiA1NzkyIDxu b3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDc0MDkgODU2OTk0MTQ+IChERikNCjEw MTI5NDIzMTYuNzQ4MjMyIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5 MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA0Mjo0MigwKSBhY2sgNjE0 MDUgd2luIDQxOTkyIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTQxOCA4Nzc0 NDc0MDk+IChERikNCjEwMTI5NDIzMTYuNzQ4MjMyIGV0aDAgPiB4ZWQuYWNs LmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCA2 MTQwNTo2MjA4Mig2NzcpIGFjayA0MiB3aW4gNTc5MiA8bm9wLG5vcCx0aW1l c3RhbXAgODc3NDQ3NDQ1IDg1Njk5NDE4PiAoREYpDQoxMDEyOTQyMzE2Ljc0 OTIwOSBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNs LmxhbmwuZ292LjI3MDk6IC4gNDI6NDIoMCkgYWNrIDYyMDgyIHdpbiA0MTk5 MiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0MTggODc3NDQ3NDQ1PiAoREYp DQoxMDEyOTQyMzE2Ljc1MjEzOSBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4y NzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgNjIwODI6NjIxNjYo ODQpIGFjayA0MiB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ3 NDQ5IDg1Njk5NDE4PiAoREYpDQoxMDEyOTQyMzE2Ljc1MjEzOSBldGgwIDwg Ymx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3 MDk6IC4gNDI6NDIoMCkgYWNrIDYyMTY2IHdpbiA0MTk5MiA8bm9wLG5vcCx0 aW1lc3RhbXAgODU2OTk0MTggODc3NDQ3NDQ5PiAoREYpDQoxMDEyOTQyMzE2 Ljc1MjEzOSBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5h Y2wubGFubC5nb3YuMzI3OTA6IFAgNjIxNjY6NjI0NzYoMzEwKSBhY2sgNDIg d2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NzQ0OSA4NTY5OTQx OD4gKERGKQ0KMTAxMjk0MjMxNi43NTIxMzkgZXRoMCA8IGJsdWUuYWNsLmxh bmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDQyOjQy KDApIGFjayA2MjQ3NiB3aW4gNDE5OTIgPG5vcCxub3AsdGltZXN0YW1wIDg1 Njk5NDE4IDg3NzQ0NzQ0OT4gKERGKQ0KMTAxMjk0MjMxNi43NTIxMzkgZXRo MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292 LjMyNzkwOiBQIDYyNDc2OjYyODU0KDM3OCkgYWNrIDQyIHdpbiA1NzkyIDxu b3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDc0NDkgODU2OTk0MTg+IChERikNCjEw MTI5NDIzMTYuNzUzMTE1IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5 MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA0Mjo0MigwKSBhY2sgNjI4 NTQgd2luIDQxOTkyIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTQxOCA4Nzc0 NDc0NDk+IChERikNCjEwMTI5NDIzMTYuNzUzMTE1IGV0aDAgPCBibHVlLmFj bC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogUCA0 Mjo0MygxKSBhY2sgNjI4NTQgd2luIDQxOTkyIDxub3Asbm9wLHRpbWVzdGFt cCA4NTY5OTQxOCA4Nzc0NDc0NDk+IChERikNCjEwMTI5NDIzMTYuNzUzMTE1 IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5s Lmdvdi4zMjc5MDogUCA2Mjg1NDo2MjkzOCg4NCkgYWNrIDQzIHdpbiA1Nzky IDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDc0NTAgODU2OTk0MTg+IChERikN CjEwMTI5NDIzMTYuNzg4Mjc0IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4z Mjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA0Mzo0MygwKSBhY2sg NjI5Mzggd2luIDQxOTkyIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTQyMiA4 Nzc0NDc0NTA+IChERikNCjEwMTI5NDIzMTYuNzg4Mjc0IGV0aDAgPiB4ZWQu YWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDog UCA2MjkzODo2MzYxNSg2NzcpIGFjayA0MyB3aW4gNTc5MiA8bm9wLG5vcCx0 aW1lc3RhbXAgODc3NDQ3NDg2IDg1Njk5NDIyPiAoREYpDQoxMDEyOTQyMzE2 Ljc4OTI1MCBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQu YWNsLmxhbmwuZ292LjI3MDk6IC4gNDM6NDMoMCkgYWNrIDYzNjE1IHdpbiA0 MTk5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0MjIgODc3NDQ3NDg2PiAo REYpDQoxMDEyOTQyMzE2Ljc5MjE4MCBldGgwID4geGVkLmFjbC5sYW5sLmdv di4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgNjM2MTU6NjM2 OTkoODQpIGFjayA0MyB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3 NDQ3NDkwIDg1Njk5NDIyPiAoREYpDQoxMDEyOTQyMzE2Ljc5MjE4MCBldGgw IDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292 LjI3MDk6IC4gNDM6NDMoMCkgYWNrIDYzNjk5IHdpbiA0MTk5MiA8bm9wLG5v cCx0aW1lc3RhbXAgODU2OTk0MjIgODc3NDQ3NDkwPiAoREYpDQoxMDEyOTQy MzE2Ljc5MjE4MCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1 ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgNjM2OTk6NjQzODYoNjg3KSBhY2sg NDMgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NzQ5MCA4NTY5 OTQyMj4gKERGKQ0KMTAxMjk0MjMxNi43OTIxODAgZXRoMCA8IGJsdWUuYWNs LmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDQz OjQzKDApIGFjayA2NDM4NiB3aW4gNDE5OTIgPG5vcCxub3AsdGltZXN0YW1w IDg1Njk5NDIyIDg3NzQ0NzQ5MD4gKERGKQ0KMTAxMjk0MjMxNi43OTIxODAg ZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwu Z292LjMyNzkwOiBQIDY0Mzg2OjY0Mzg3KDEpIGFjayA0MyB3aW4gNTc5MiA8 bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ3NDkwIDg1Njk5NDIyPiAoREYpDQox MDEyOTQyMzE2Ljc5MzE1NyBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3 OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNDM6NDMoMCkgYWNrIDY0 Mzg3IHdpbiA0MTk5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0MjIgODc3 NDQ3NDkwPiAoREYpDQoxMDEyOTQyMzE2Ljc5MzE1NyBldGgwIDwgYmx1ZS5h Y2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IFAg NDM6NDQoMSkgYWNrIDY0Mzg3IHdpbiA0MTk5MiA8bm9wLG5vcCx0aW1lc3Rh bXAgODU2OTk0MjIgODc3NDQ3NDkwPiAoREYpDQoxMDEyOTQyMzE2Ljc5NDEz NCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTA6IFAgNjQzODc6NjQ0NzEoODQpIGFjayA0NCB3aW4gNTc5 MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ3NDkxIDg1Njk5NDIyPiAoREYp DQoxMDEyOTQyMzE2LjgwMzkwMCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4y NzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IC4gNjQ0NzE6NjU5MTko MTQ0OCkgYWNrIDQ0IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0 NDc1MDIgODU2OTk0MjI+IChERikNCjEwMTI5NDIzMTYuODA0ODc2IGV0aDAg PCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3Yu MjcwOTogLiA0NDo0NCgwKSBhY2sgNjU5MTkgd2luIDQ0ODg4IDxub3Asbm9w LHRpbWVzdGFtcCA4NTY5OTQyMyA4Nzc0NDc0OTE+IChERikNCjEwMTI5NDIz MTYuODA0ODc2IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVl LmFjbC5sYW5sLmdvdi4zMjc5MDogUCA2NTkxOTo2NTkyMCgxKSBhY2sgNDQg d2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NzUwMyA4NTY5OTQy Mz4gKERGKQ0KMTAxMjk0MjMxNi44MDQ4NzYgZXRoMCA8IGJsdWUuYWNsLmxh bmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiBQIDQ0OjQ1 KDEpIGFjayA2NTkyMCB3aW4gNDQ4ODggPG5vcCxub3AsdGltZXN0YW1wIDg1 Njk5NDIzIDg3NzQ0NzUwMz4gKERGKQ0KMTAxMjk0MjMxNi44MDU4NTMgZXRo MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292 LjMyNzkwOiBQIDY1OTIwOjY2MDA0KDg0KSBhY2sgNDUgd2luIDU3OTIgPG5v cCxub3AsdGltZXN0YW1wIDg3NzQ0NzUwNCA4NTY5OTQyMz4gKERGKQ0KMTAx Mjk0MjMxNi44MDU4NTMgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+ IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiAuIDY2MDA0OjY3NDUyKDE0NDgp IGFjayA0NSB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ3NTA0 IDg1Njk5NDIzPiAoREYpDQoxMDEyOTQyMzE2LjgwNjgzMCBldGgwIDwgYmx1 ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6 IC4gNDU6NDUoMCkgYWNrIDY3NDUyIHdpbiA0Nzc4NCA8bm9wLG5vcCx0aW1l c3RhbXAgODU2OTk0MjMgODc3NDQ3NTA0PiAoREYpDQoxMDEyOTQyMzE2Ljgw NjgzMCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wu bGFubC5nb3YuMzI3OTA6IFAgNjc0NTI6Njc0NTMoMSkgYWNrIDQ1IHdpbiA1 NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDc1MDUgODU2OTk0MjM+IChE RikNCjEwMTI5NDIzMTYuODA2ODMwIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdv di4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogUCA0NTo0NigxKSBh Y2sgNjc0NTMgd2luIDQ3Nzg0IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTQy MyA4Nzc0NDc1MDU+IChERikNCjEwMTI5NDIzMTYuODA3ODA2IGV0aDAgPiB4 ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5 MDogUCA2NzQ1Mzo2NzUzNyg4NCkgYWNrIDQ2IHdpbiA1NzkyIDxub3Asbm9w LHRpbWVzdGFtcCA4Nzc0NDc1MDYgODU2OTk0MjM+IChERikNCjEwMTI5NDIz MTYuODM0MTc1IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVl LmFjbC5sYW5sLmdvdi4zMjc5MDogLiA2NzUzNzo2ODk4NSgxNDQ4KSBhY2sg NDYgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NzUzMyA4NTY5 OTQyMz4gKERGKQ0KMTAxMjk0MjMxNi44MzUxNTIgZXRoMCA8IGJsdWUuYWNs LmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDQ2 OjQ2KDApIGFjayA2ODk4NSB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1w IDg1Njk5NDI2IDg3NzQ0NzUwNj4gKERGKQ0KMTAxMjk0MjMxNi44MzUxNTIg ZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwu Z292LjMyNzkwOiBQIDY4OTg1OjY4OTg2KDEpIGFjayA0NiB3aW4gNTc5MiA8 bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ3NTM0IDg1Njk5NDI2PiAoREYpDQox MDEyOTQyMzE2LjgzNTE1MiBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3 OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IFAgNDY6NDcoMSkgYWNrIDY4 OTg2IHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0MjYgODc3 NDQ3NTM0PiAoREYpDQoxMDEyOTQyMzE2LjgzNjEyOCBldGgwID4geGVkLmFj bC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAg Njg5ODY6NjkwNzAoODQpIGFjayA0NyB3aW4gNTc5MiA8bm9wLG5vcCx0aW1l c3RhbXAgODc3NDQ3NTM1IDg1Njk5NDI2PiAoREYpDQoxMDEyOTQyMzE2Ljg2 ODM1NyBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNs LmxhbmwuZ292LjI3MDk6IC4gNDc6NDcoMCkgYWNrIDY5MDcwIHdpbiA1MDY4 MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0MzAgODc3NDQ3NTM1PiAoREYp DQoxMDEyOTQyMzE2Ljg2ODM1NyBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4y NzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgNjkwNzA6Njk3NDco Njc3KSBhY2sgNDcgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0 NzU2OCA4NTY5OTQzMD4gKERGKQ0KMTAxMjk0MjMxNi44NjkzMzMgZXRoMCA8 IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4y NzA5OiAuIDQ3OjQ3KDApIGFjayA2OTc0NyB3aW4gNTA2ODAgPG5vcCxub3As dGltZXN0YW1wIDg1Njk5NDMwIDg3NzQ0NzU2OD4gKERGKQ0KMTAxMjk0MjMx Ni44NzQyMTYgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUu YWNsLmxhbmwuZ292LjMyNzkwOiBQIDY5NzQ3OjY5ODMxKDg0KSBhY2sgNDcg d2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NzU3NCA4NTY5OTQz MD4gKERGKQ0KMTAxMjk0MjMxNi44NzQyMTYgZXRoMCA8IGJsdWUuYWNsLmxh bmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDQ3OjQ3 KDApIGFjayA2OTgzMSB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1 Njk5NDMwIDg3NzQ0NzU3ND4gKERGKQ0KMTAxMjk0MjMxNi44NzQyMTYgZXRo MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292 LjMyNzkwOiBQIDY5ODMxOjcwMTQxKDMxMCkgYWNrIDQ3IHdpbiA1NzkyIDxu b3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDc1NzQgODU2OTk0MzA+IChERikNCjEw MTI5NDIzMTYuODc0MjE2IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5 MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA0Nzo0NygwKSBhY2sgNzAx NDEgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTQzMCA4Nzc0 NDc1NzQ+IChERikNCjEwMTI5NDIzMTYuODc0MjE2IGV0aDAgPiB4ZWQuYWNs LmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCA3 MDE0MTo3MDUxOSgzNzgpIGFjayA0NyB3aW4gNTc5MiA8bm9wLG5vcCx0aW1l c3RhbXAgODc3NDQ3NTc0IDg1Njk5NDMwPiAoREYpDQoxMDEyOTQyMzE2Ljg3 NTE5MyBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNs LmxhbmwuZ292LjI3MDk6IC4gNDc6NDcoMCkgYWNrIDcwNTE5IHdpbiA1MDY4 MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0MzAgODc3NDQ3NTc0PiAoREYp DQoxMDEyOTQyMzE2Ljg3NTE5MyBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3Yu MzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IFAgNDc6NDgoMSkgYWNr IDcwNTE5IHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0MzAg ODc3NDQ3NTc0PiAoREYpDQoxMDEyOTQyMzE2Ljg3NTE5MyBldGgwID4geGVk LmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6 IFAgNzA1MTk6NzA2MDMoODQpIGFjayA0OCB3aW4gNTc5MiA8bm9wLG5vcCx0 aW1lc3RhbXAgODc3NDQ3NTc1IDg1Njk5NDMwPiAoREYpDQoxMDEyOTQyMzE2 LjkwODM5OCBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQu YWNsLmxhbmwuZ292LjI3MDk6IC4gNDg6NDgoMCkgYWNrIDcwNjAzIHdpbiA1 MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0MzQgODc3NDQ3NTc1PiAo REYpDQoxMDEyOTQyMzE2LjkwODM5OCBldGgwID4geGVkLmFjbC5sYW5sLmdv di4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgNzA2MDM6NzEy ODAoNjc3KSBhY2sgNDggd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3 NzQ0NzYwOSA4NTY5OTQzND4gKERGKQ0KMTAxMjk0MjMxNi45MDkzNzQgZXRo MCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdv di4yNzA5OiAuIDQ4OjQ4KDApIGFjayA3MTI4MCB3aW4gNTA2ODAgPG5vcCxu b3AsdGltZXN0YW1wIDg1Njk5NDM0IDg3NzQ0NzYwOT4gKERGKQ0KMTAxMjk0 MjMxNi45MTQyNTggZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJs dWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDcxMjgwOjcxMzY0KDg0KSBhY2sg NDggd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NzYxNSA4NTY5 OTQzND4gKERGKQ0KMTAxMjk0MjMxNi45MTQyNTggZXRoMCA8IGJsdWUuYWNs LmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDQ4 OjQ4KDApIGFjayA3MTM2NCB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1w IDg1Njk5NDM0IDg3NzQ0NzYxNT4gKERGKQ0KMTAxMjk0MjMxNi45MTQyNTgg ZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwu Z292LjMyNzkwOiBQIDcxMzY0OjcyMDUxKDY4NykgYWNrIDQ4IHdpbiA1Nzky IDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDc2MTUgODU2OTk0MzQ+IChERikN CjEwMTI5NDIzMTYuOTE0MjU4IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4z Mjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA0ODo0OCgwKSBhY2sg NzIwNTEgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTQzNCA4 Nzc0NDc2MTU+IChERikNCjEwMTI5NDIzMTYuOTE1MjM1IGV0aDAgPiB4ZWQu YWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDog UCA3MjA1MTo3MjA1MigxKSBhY2sgNDggd2luIDU3OTIgPG5vcCxub3AsdGlt ZXN0YW1wIDg3NzQ0NzYxNiA4NTY5OTQzND4gKERGKQ0KMTAxMjk0MjMxNi45 MTUyMzUgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFj bC5sYW5sLmdvdi4yNzA5OiAuIDQ4OjQ4KDApIGFjayA3MjA1MiB3aW4gNTA2 ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NDM0IDg3NzQ0NzYxNj4gKERG KQ0KMTAxMjk0MjMxNi45MTUyMzUgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292 LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiBQIDQ4OjQ5KDEpIGFj ayA3MjA1MiB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NDM0 IDg3NzQ0NzYxNj4gKERGKQ0KMTAxMjk0MjMxNi45MTYyMTEgZXRoMCA+IHhl ZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkw OiBQIDcyMDUyOjcyMTM2KDg0KSBhY2sgNDkgd2luIDU3OTIgPG5vcCxub3As dGltZXN0YW1wIDg3NzQ0NzYxNyA4NTY5OTQzND4gKERGKQ0KMTAxMjk0MjMx Ni45NDg0NDAgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVk LmFjbC5sYW5sLmdvdi4yNzA5OiAuIDQ5OjQ5KDApIGFjayA3MjEzNiB3aW4g NTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NDM4IDg3NzQ0NzYxNz4g KERGKQ0KMTAxMjk0MjMxNi45NDg0NDAgZXRoMCA+IHhlZC5hY2wubGFubC5n b3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDcyMTM2Ojcy ODEzKDY3NykgYWNrIDQ5IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4 Nzc0NDc2NTAgODU2OTk0Mzg+IChERikNCjEwMTI5NDIzMTYuOTQ4NDQwIGV0 aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5n b3YuMjcwOTogLiA0OTo0OSgwKSBhY2sgNzI4MTMgd2luIDUwNjgwIDxub3As bm9wLHRpbWVzdGFtcCA4NTY5OTQzOCA4Nzc0NDc2NTA+IChERikNCjEwMTI5 NDIzMTYuOTU0Mjk5IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBi bHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCA3MjgxMzo3Mjg5Nyg4NCkgYWNr IDQ5IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDc2NTYgODU2 OTk0Mzg+IChERikNCjEwMTI5NDIzMTYuOTU0Mjk5IGV0aDAgPCBibHVlLmFj bC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA0 OTo0OSgwKSBhY2sgNzI4OTcgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFt cCA4NTY5OTQzOCA4Nzc0NDc2NTY+IChERikNCjEwMTI5NDIzMTYuOTU0Mjk5 IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5s Lmdvdi4zMjc5MDogUCA3Mjg5Nzo3MzU4NCg2ODcpIGFjayA0OSB3aW4gNTc5 MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ3NjU2IDg1Njk5NDM4PiAoREYp DQoxMDEyOTQyMzE2Ljk1NDI5OSBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3Yu MzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNDk6NDkoMCkgYWNr IDczNTg0IHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0Mzgg ODc3NDQ3NjU2PiAoREYpDQoxMDEyOTQyMzE2Ljk1NDI5OSBldGgwID4geGVk LmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6 IFAgNzM1ODQ6NzM1ODUoMSkgYWNrIDQ5IHdpbiA1NzkyIDxub3Asbm9wLHRp bWVzdGFtcCA4Nzc0NDc2NTYgODU2OTk0Mzg+IChERikNCjEwMTI5NDIzMTYu OTU1Mjc2IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5h Y2wubGFubC5nb3YuMjcwOTogLiA0OTo0OSgwKSBhY2sgNzM1ODUgd2luIDUw NjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTQzOCA4Nzc0NDc2NTY+IChE RikNCjEwMTI5NDIzMTYuOTU1Mjc2IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdv di4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogUCA0OTo1MCgxKSBh Y2sgNzM1ODUgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTQz OCA4Nzc0NDc2NTY+IChERikNCjEwMTI5NDIzMTYuOTU1Mjc2IGV0aDAgPiB4 ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5 MDogUCA3MzU4NTo3MzY2OSg4NCkgYWNrIDUwIHdpbiA1NzkyIDxub3Asbm9w LHRpbWVzdGFtcCA4Nzc0NDc2NTcgODU2OTk0Mzg+IChERikNCjEwMTI5NDIz MTYuOTg4NDgxIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhl ZC5hY2wubGFubC5nb3YuMjcwOTogLiA1MDo1MCgwKSBhY2sgNzM2Njkgd2lu IDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTQ0MiA4Nzc0NDc2NTc+ IChERikNCjEwMTI5NDIzMTYuOTg4NDgxIGV0aDAgPiB4ZWQuYWNsLmxhbmwu Z292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCA3MzY2OTo3 NDM0Nig2NzcpIGFjayA1MCB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAg ODc3NDQ3NjkxIDg1Njk5NDQyPiAoREYpDQoxMDEyOTQyMzE2Ljk4ODQ4MSBl dGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwu Z292LjI3MDk6IC4gNTA6NTAoMCkgYWNrIDc0MzQ2IHdpbiA1MDY4MCA8bm9w LG5vcCx0aW1lc3RhbXAgODU2OTk0NDIgODc3NDQ3NjkxPiAoREYpDQoxMDEy OTQyMzE2Ljk5NDM0MSBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4g Ymx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgNzQzNDY6NzQ0MzAoODQpIGFj ayA1MCB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ3Njk3IDg1 Njk5NDQyPiAoREYpDQoxMDEyOTQyMzE2Ljk5NDM0MSBldGgwIDwgYmx1ZS5h Y2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4g NTA6NTAoMCkgYWNrIDc0NDMwIHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3Rh bXAgODU2OTk0NDIgODc3NDQ3Njk3PiAoREYpDQoxMDEyOTQyMzE2Ljk5NDM0 MSBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTA6IFAgNzQ0MzA6NzQ3NDAoMzEwKSBhY2sgNTAgd2luIDU3 OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NzY5NyA4NTY5OTQ0Mj4gKERG KQ0KMTAxMjk0MjMxNi45OTQzNDEgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292 LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDUwOjUwKDApIGFj ayA3NDc0MCB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NDQy IDg3NzQ0NzY5Nz4gKERGKQ0KMTAxMjk0MjMxNi45OTQzNDEgZXRoMCA+IHhl ZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkw OiBQIDc0NzQwOjc1MTE4KDM3OCkgYWNrIDUwIHdpbiA1NzkyIDxub3Asbm9w LHRpbWVzdGFtcCA4Nzc0NDc2OTcgODU2OTk0NDI+IChERikNCjEwMTI5NDIz MTYuOTk1MzE3IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhl ZC5hY2wubGFubC5nb3YuMjcwOTogLiA1MDo1MCgwKSBhY2sgNzUxMTggd2lu IDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTQ0MiA4Nzc0NDc2OTc+ IChERikNCjEwMTI5NDIzMTYuOTk1MzE3IGV0aDAgPCBibHVlLmFjbC5sYW5s Lmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogUCA1MDo1MSgx KSBhY2sgNzUxMTggd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5 OTQ0MiA4Nzc0NDc2OTc+IChERikNCjEwMTI5NDIzMTYuOTk1MzE3IGV0aDAg PiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4z Mjc5MDogUCA3NTExODo3NTIwMig4NCkgYWNrIDUxIHdpbiA1NzkyIDxub3As bm9wLHRpbWVzdGFtcCA4Nzc0NDc2OTggODU2OTk0NDI+IChERikNCjEwMTI5 NDIzMTcuMDI4NTIzIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+ IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA1MTo1MSgwKSBhY2sgNzUyMDIg d2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTQ0NiA4Nzc0NDc2 OTg+IChERikNCjEwMTI5NDIzMTcuMDI4NTIzIGV0aDAgPiB4ZWQuYWNsLmxh bmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCA3NTIw Mjo3NTg3OSg2NzcpIGFjayA1MSB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3Rh bXAgODc3NDQ3NzMyIDg1Njk5NDQ2PiAoREYpDQoxMDEyOTQyMzE3LjAyODUy MyBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxh bmwuZ292LjI3MDk6IC4gNTE6NTEoMCkgYWNrIDc1ODc5IHdpbiA1MDY4MCA8 bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0NDYgODc3NDQ3NzMyPiAoREYpDQox MDEyOTQyMzE3LjAzNDM4MiBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5 ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgNzU4Nzk6NzU5NjMoODQp IGFjayA1MSB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ3NzM4 IDg1Njk5NDQ2PiAoREYpDQoxMDEyOTQyMzE3LjAzNDM4MiBldGgwIDwgYmx1 ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6 IC4gNTE6NTEoMCkgYWNrIDc1OTYzIHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1l c3RhbXAgODU2OTk0NDYgODc3NDQ3NzM4PiAoREYpDQoxMDEyOTQyMzE3LjAz NDM4MiBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wu bGFubC5nb3YuMzI3OTA6IFAgNzU5NjM6NzY2NTAoNjg3KSBhY2sgNTEgd2lu IDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NzczOCA4NTY5OTQ0Nj4g KERGKQ0KMTAxMjk0MjMxNy4wMzQzODIgZXRoMCA8IGJsdWUuYWNsLmxhbmwu Z292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDUxOjUxKDAp IGFjayA3NjY1MCB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5 NDQ2IDg3NzQ0NzczOD4gKERGKQ0KMTAxMjk0MjMxNy4wMzQzODIgZXRoMCA+ IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMy NzkwOiBQIDc2NjUwOjc2NjUxKDEpIGFjayA1MSB3aW4gNTc5MiA8bm9wLG5v cCx0aW1lc3RhbXAgODc3NDQ3NzM4IDg1Njk5NDQ2PiAoREYpDQoxMDEyOTQy MzE3LjAzNTM1OSBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4 ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNTE6NTEoMCkgYWNrIDc2NjUxIHdp biA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0NDYgODc3NDQ3NzM4 PiAoREYpDQoxMDEyOTQyMzE3LjAzNTM1OSBldGgwIDwgYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IFAgNTE6NTIo MSkgYWNrIDc2NjUxIHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2 OTk0NDYgODc3NDQ3NzM4PiAoREYpDQoxMDEyOTQyMzE3LjAzNTM1OSBldGgw ID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3Yu MzI3OTA6IFAgNzY2NTE6NzY3MzUoODQpIGFjayA1MiB3aW4gNTc5MiA8bm9w LG5vcCx0aW1lc3RhbXAgODc3NDQ3NzM5IDg1Njk5NDQ2PiAoREYpDQoxMDEy OTQyMzE3LjA2ODU2NCBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAg PiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNTI6NTIoMCkgYWNrIDc2NzM1 IHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0NTAgODc3NDQ3 NzM5PiAoREYpDQoxMDEyOTQyMzE3LjA2ODU2NCBldGgwID4geGVkLmFjbC5s YW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgNzY3 MzU6Nzc0MTIoNjc3KSBhY2sgNTIgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0 YW1wIDg3NzQ0Nzc3MyA4NTY5OTQ1MD4gKERGKQ0KMTAxMjk0MjMxNy4wNjg1 NjQgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5s YW5sLmdvdi4yNzA5OiAuIDUyOjUyKDApIGFjayA3NzQxMiB3aW4gNTA2ODAg PG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NDUwIDg3NzQ0Nzc3Mz4gKERGKQ0K MTAxMjk0MjMxNy4wNzQ0MjQgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcw OSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDc3NDEyOjc3NDk2KDg0 KSBhY2sgNTIgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0Nzc3 OSA4NTY5OTQ1MD4gKERGKQ0KMTAxMjk0MjMxNy4wNzQ0MjQgZXRoMCA8IGJs dWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5 OiAuIDUyOjUyKDApIGFjayA3NzQ5NiB3aW4gNTA2ODAgPG5vcCxub3AsdGlt ZXN0YW1wIDg1Njk5NDUwIDg3NzQ0Nzc3OT4gKERGKQ0KMTAxMjk0MjMxNy4w NzQ0MjQgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNs LmxhbmwuZ292LjMyNzkwOiBQIDc3NDk2Ojc4MTgzKDY4NykgYWNrIDUyIHdp biA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDc3NzkgODU2OTk0NTA+ IChERikNCjEwMTI5NDIzMTcuMDc0NDI0IGV0aDAgPCBibHVlLmFjbC5sYW5s Lmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA1Mjo1Migw KSBhY2sgNzgxODMgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5 OTQ1MCA4Nzc0NDc3Nzk+IChERikNCjEwMTI5NDIzMTcuMDc0NDI0IGV0aDAg PiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4z Mjc5MDogUCA3ODE4Mzo3ODE4NCgxKSBhY2sgNTIgd2luIDU3OTIgPG5vcCxu b3AsdGltZXN0YW1wIDg3NzQ0Nzc3OSA4NTY5OTQ1MD4gKERGKQ0KMTAxMjk0 MjMxNy4wNzU0MDAgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4g eGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDUyOjUyKDApIGFjayA3ODE4NCB3 aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NDUwIDg3NzQ0Nzc3 OT4gKERGKQ0KMTAxMjk0MjMxNy4wNzU0MDAgZXRoMCA8IGJsdWUuYWNsLmxh bmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiBQIDUyOjUz KDEpIGFjayA3ODE4NCB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1 Njk5NDUwIDg3NzQ0Nzc3OT4gKERGKQ0KMTAxMjk0MjMxNy4wNzU0MDAgZXRo MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292 LjMyNzkwOiBQIDc4MTg0Ojc4MjY4KDg0KSBhY2sgNTMgd2luIDU3OTIgPG5v cCxub3AsdGltZXN0YW1wIDg3NzQ0Nzc4MCA4NTY5OTQ1MD4gKERGKQ0KMTAx Mjk0MjMxNy4xMDg2MDYgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkw ID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDUzOjUzKDApIGFjayA3ODI2 OCB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NDU0IDg3NzQ0 Nzc4MD4gKERGKQ0KMTAxMjk0MjMxNy4xMDg2MDYgZXRoMCA+IHhlZC5hY2wu bGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDc4 MjY4Ojc4OTQ1KDY3NykgYWNrIDUzIHdpbiA1NzkyIDxub3Asbm9wLHRpbWVz dGFtcCA4Nzc0NDc4MTQgODU2OTk0NTQ+IChERikNCjEwMTI5NDIzMTcuMTA4 NjA2IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wu bGFubC5nb3YuMjcwOTogLiA1Mzo1MygwKSBhY2sgNzg5NDUgd2luIDUwNjgw IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTQ1NCA4Nzc0NDc4MTQ+IChERikN CjEwMTI5NDIzMTcuMTE0NDY1IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3 MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCA3ODk0NTo3OTAyOSg4 NCkgYWNrIDUzIHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDc4 MjAgODU2OTk0NTQ+IChERikNCjEwMTI5NDIzMTcuMTE0NDY1IGV0aDAgPCBi bHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcw OTogLiA1Mzo1MygwKSBhY2sgNzkwMjkgd2luIDUwNjgwIDxub3Asbm9wLHRp bWVzdGFtcCA4NTY5OTQ1NCA4Nzc0NDc4MjA+IChERikNCjEwMTI5NDIzMTcu MTE0NDY1IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFj bC5sYW5sLmdvdi4zMjc5MDogUCA3OTAyOTo3OTMzOSgzMTApIGFjayA1MyB3 aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ3ODIwIDg1Njk5NDU0 PiAoREYpDQoxMDEyOTQyMzE3LjExNDQ2NSBldGgwIDwgYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNTM6NTMo MCkgYWNrIDc5MzM5IHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2 OTk0NTQgODc3NDQ3ODIwPiAoREYpDQoxMDEyOTQyMzE3LjExNDQ2NSBldGgw ID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3Yu MzI3OTA6IFAgNzkzMzk6Nzk3MTcoMzc4KSBhY2sgNTMgd2luIDU3OTIgPG5v cCxub3AsdGltZXN0YW1wIDg3NzQ0NzgyMCA4NTY5OTQ1ND4gKERGKQ0KMTAx Mjk0MjMxNy4xMTU0NDIgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkw ID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDUzOjUzKDApIGFjayA3OTcx NyB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NDU0IDg3NzQ0 NzgyMD4gKERGKQ0KMTAxMjk0MjMxNy4xMTU0NDIgZXRoMCA8IGJsdWUuYWNs LmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiBQIDUz OjU0KDEpIGFjayA3OTcxNyB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1w IDg1Njk5NDU0IDg3NzQ0NzgyMD4gKERGKQ0KMTAxMjk0MjMxNy4xMTY0MTkg ZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwu Z292LjMyNzkwOiBQIDc5NzE3Ojc5ODAxKDg0KSBhY2sgNTQgd2luIDU3OTIg PG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NzgyMiA4NTY5OTQ1ND4gKERGKQ0K MTAxMjk0MjMxNy4xNDg2NDcgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMy NzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDU0OjU0KDApIGFjayA3 OTgwMSB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NDU4IDg3 NzQ0NzgyMj4gKERGKQ0KMTAxMjk0MjMxNy4xNDg2NDcgZXRoMCA+IHhlZC5h Y2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQ IDc5ODAxOjgwNDc4KDY3NykgYWNrIDU0IHdpbiA1NzkyIDxub3Asbm9wLHRp bWVzdGFtcCA4Nzc0NDc4NTUgODU2OTk0NTg+IChERikNCjEwMTI5NDIzMTcu MTQ4NjQ3IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5h Y2wubGFubC5nb3YuMjcwOTogLiA1NDo1NCgwKSBhY2sgODA0Nzggd2luIDUw NjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTQ1OCA4Nzc0NDc4NTU+IChE RikNCjEwMTI5NDIzMTcuMTU0NTA3IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292 LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCA4MDQ3ODo4MDU2 Mig4NCkgYWNrIDU0IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0 NDc4NjEgODU2OTk0NTg+IChERikNCjEwMTI5NDIzMTcuMTU0NTA3IGV0aDAg PCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3Yu MjcwOTogLiA1NDo1NCgwKSBhY2sgODA1NjIgd2luIDUwNjgwIDxub3Asbm9w LHRpbWVzdGFtcCA4NTY5OTQ1OCA4Nzc0NDc4NjE+IChERikNCjEwMTI5NDIz MTcuMTU0NTA3IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVl LmFjbC5sYW5sLmdvdi4zMjc5MDogUCA4MDU2Mjo4MTI0OSg2ODcpIGFjayA1 NCB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ3ODYxIDg1Njk5 NDU4PiAoREYpDQoxMDEyOTQyMzE3LjE1NDUwNyBldGgwIDwgYmx1ZS5hY2wu bGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNTQ6 NTQoMCkgYWNrIDgxMjQ5IHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAg ODU2OTk0NTggODc3NDQ3ODYxPiAoREYpDQoxMDEyOTQyMzE3LjE1NDUwNyBl dGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5n b3YuMzI3OTA6IFAgODEyNDk6ODEyNTAoMSkgYWNrIDU0IHdpbiA1NzkyIDxu b3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDc4NjEgODU2OTk0NTg+IChERikNCjEw MTI5NDIzMTcuMTU1NDgzIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5 MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA1NDo1NCgwKSBhY2sgODEy NTAgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTQ1OCA4Nzc0 NDc4NjE+IChERikNCjEwMTI5NDIzMTcuMTU1NDgzIGV0aDAgPCBibHVlLmFj bC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogUCA1 NDo1NSgxKSBhY2sgODEyNTAgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFt cCA4NTY5OTQ1OCA4Nzc0NDc4NjE+IChERikNCjEwMTI5NDIzMTcuMTU1NDgz IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5s Lmdvdi4zMjc5MDogUCA4MTI1MDo4MTMzNCg4NCkgYWNrIDU1IHdpbiA1Nzky IDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDc4NjIgODU2OTk0NTg+IChERikN CjEwMTI5NDIzMTcuMTg4Njg4IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4z Mjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA1NTo1NSgwKSBhY2sg ODEzMzQgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTQ2MiA4 Nzc0NDc4NjI+IChERikNCjEwMTI5NDIzMTcuMTg4Njg4IGV0aDAgPiB4ZWQu YWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDog UCA4MTMzNDo4MjAxMSg2NzcpIGFjayA1NSB3aW4gNTc5MiA8bm9wLG5vcCx0 aW1lc3RhbXAgODc3NDQ3ODk2IDg1Njk5NDYyPiAoREYpDQoxMDEyOTQyMzE3 LjE4ODY4OCBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQu YWNsLmxhbmwuZ292LjI3MDk6IC4gNTU6NTUoMCkgYWNrIDgyMDExIHdpbiA1 MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0NjIgODc3NDQ3ODk2PiAo REYpDQoxMDEyOTQyMzE3LjE5NDU0OCBldGgwID4geGVkLmFjbC5sYW5sLmdv di4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgODIwMTE6ODIw OTUoODQpIGFjayA1NSB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3 NDQ3OTAyIDg1Njk5NDYyPiAoREYpDQoxMDEyOTQyMzE3LjE5NDU0OCBldGgw IDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292 LjI3MDk6IC4gNTU6NTUoMCkgYWNrIDgyMDk1IHdpbiA1MDY4MCA8bm9wLG5v cCx0aW1lc3RhbXAgODU2OTk0NjIgODc3NDQ3OTAyPiAoREYpDQoxMDEyOTQy MzE3LjE5NDU0OCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1 ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgODIwOTU6ODI0MDUoMzEwKSBhY2sg NTUgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0NzkwMiA4NTY5 OTQ2Mj4gKERGKQ0KMTAxMjk0MjMxNy4xOTQ1NDggZXRoMCA8IGJsdWUuYWNs LmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDU1 OjU1KDApIGFjayA4MjQwNSB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1w IDg1Njk5NDYyIDg3NzQ0NzkwMj4gKERGKQ0KMTAxMjk0MjMxNy4xOTQ1NDgg ZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwu Z292LjMyNzkwOiBQIDgyNDA1OjgyNzgzKDM3OCkgYWNrIDU1IHdpbiA1Nzky IDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDc5MDIgODU2OTk0NjI+IChERikN CjEwMTI5NDIzMTcuMTk1NTI1IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4z Mjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA1NTo1NSgwKSBhY2sg ODI3ODMgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTQ2MiA4 Nzc0NDc5MDI+IChERikNCjEwMTI5NDIzMTcuMTk1NTI1IGV0aDAgPCBibHVl LmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTog UCA1NTo1NigxKSBhY2sgODI3ODMgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVz dGFtcCA4NTY5OTQ2MiA4Nzc0NDc5MDI+IChERikNCjEwMTI5NDIzMTcuMTk1 NTI1IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5s YW5sLmdvdi4zMjc5MDogUCA4Mjc4Mzo4Mjg2Nyg4NCkgYWNrIDU2IHdpbiA1 NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDc5MDMgODU2OTk0NjI+IChE RikNCjEwMTI5NDIzMTcuMjI4NzMwIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdv di4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA1Njo1NigwKSBh Y2sgODI4Njcgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTQ2 NiA4Nzc0NDc5MDM+IChERikNCjEwMTI5NDIzMTcuMjI4NzMwIGV0aDAgPiB4 ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5 MDogUCA4Mjg2Nzo4MzU0NCg2NzcpIGFjayA1NiB3aW4gNTc5MiA8bm9wLG5v cCx0aW1lc3RhbXAgODc3NDQ3OTM3IDg1Njk5NDY2PiAoREYpDQoxMDEyOTQy MzE3LjIyODczMCBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4 ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNTY6NTYoMCkgYWNrIDgzNTQ0IHdp biA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0NjYgODc3NDQ3OTM3 PiAoREYpDQoxMDEyOTQyMzE3LjIzNDU5MCBldGgwID4geGVkLmFjbC5sYW5s Lmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgODM1NDQ6 ODM2MjgoODQpIGFjayA1NiB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAg ODc3NDQ3OTQzIDg1Njk5NDY2PiAoREYpDQoxMDEyOTQyMzE3LjIzNDU5MCBl dGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwu Z292LjI3MDk6IC4gNTY6NTYoMCkgYWNrIDgzNjI4IHdpbiA1MDY4MCA8bm9w LG5vcCx0aW1lc3RhbXAgODU2OTk0NjYgODc3NDQ3OTQzPiAoREYpDQoxMDEy OTQyMzE3LjIzNDU5MCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4g Ymx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgODM2Mjg6ODQzMTUoNjg3KSBh Y2sgNTYgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0Nzk0MyA4 NTY5OTQ2Nj4gKERGKQ0KMTAxMjk0MjMxNy4yMzQ1OTAgZXRoMCA8IGJsdWUu YWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAu IDU2OjU2KDApIGFjayA4NDMxNSB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0 YW1wIDg1Njk5NDY2IDg3NzQ0Nzk0Mz4gKERGKQ0KMTAxMjk0MjMxNy4yMzQ1 OTAgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxh bmwuZ292LjMyNzkwOiBQIDg0MzE1Ojg0MzE2KDEpIGFjayA1NiB3aW4gNTc5 MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ3OTQzIDg1Njk5NDY2PiAoREYp DQoxMDEyOTQyMzE3LjIzNTU2NiBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3Yu MzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNTY6NTYoMCkgYWNr IDg0MzE2IHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0NjYg ODc3NDQ3OTQzPiAoREYpDQoxMDEyOTQyMzE3LjIzNTU2NiBldGgwIDwgYmx1 ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6 IFAgNTY6NTcoMSkgYWNrIDg0MzE2IHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1l c3RhbXAgODU2OTk0NjYgODc3NDQ3OTQzPiAoREYpDQoxMDEyOTQyMzE3LjIz NTU2NiBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wu bGFubC5nb3YuMzI3OTA6IFAgODQzMTY6ODQ0MDAoODQpIGFjayA1NyB3aW4g NTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ3OTQ0IDg1Njk5NDY2PiAo REYpDQoxMDEyOTQyMzE3LjI2ODc3MSBldGgwIDwgYmx1ZS5hY2wubGFubC5n b3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNTc6NTcoMCkg YWNrIDg0NDAwIHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0 NzAgODc3NDQ3OTQ0PiAoREYpDQoxMDEyOTQyMzE3LjI2ODc3MSBldGgwID4g eGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3 OTA6IFAgODQ0MDA6ODUwNzcoNjc3KSBhY2sgNTcgd2luIDU3OTIgPG5vcCxu b3AsdGltZXN0YW1wIDg3NzQ0Nzk3OCA4NTY5OTQ3MD4gKERGKQ0KMTAxMjk0 MjMxNy4yNjg3NzEgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4g eGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDU3OjU3KDApIGFjayA4NTA3NyB3 aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NDcwIDg3NzQ0Nzk3 OD4gKERGKQ0KMTAxMjk0MjMxNy4yNzQ2MzEgZXRoMCA+IHhlZC5hY2wubGFu bC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDg1MDc3 Ojg1MTYxKDg0KSBhY2sgNTcgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1w IDg3NzQ0Nzk4NCA4NTY5OTQ3MD4gKERGKQ0KMTAxMjk0MjMxNy4yNzQ2MzEg ZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5s Lmdvdi4yNzA5OiAuIDU3OjU3KDApIGFjayA4NTE2MSB3aW4gNTA2ODAgPG5v cCxub3AsdGltZXN0YW1wIDg1Njk5NDcwIDg3NzQ0Nzk4ND4gKERGKQ0KMTAx Mjk0MjMxNy4yNzQ2MzEgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+ IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDg1MTYxOjg1ODQ4KDY4Nykg YWNrIDU3IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDc5ODQg ODU2OTk0NzA+IChERikNCjEwMTI5NDIzMTcuMjc0NjMxIGV0aDAgPCBibHVl LmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTog LiA1Nzo1NygwKSBhY2sgODU4NDggd2luIDUwNjgwIDxub3Asbm9wLHRpbWVz dGFtcCA4NTY5OTQ3MCA4Nzc0NDc5ODQ+IChERikNCjEwMTI5NDIzMTcuMjc0 NjMxIGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5s YW5sLmdvdi4zMjc5MDogUCA4NTg0ODo4NTg0OSgxKSBhY2sgNTcgd2luIDU3 OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0Nzk4NCA4NTY5OTQ3MD4gKERG KQ0KMTAxMjk0MjMxNy4yNzU2MDggZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292 LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDU3OjU3KDApIGFj ayA4NTg0OSB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NDcw IDg3NzQ0Nzk4ND4gKERGKQ0KMTAxMjk0MjMxNy4yNzU2MDggZXRoMCA8IGJs dWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5 OiBQIDU3OjU4KDEpIGFjayA4NTg0OSB3aW4gNTA2ODAgPG5vcCxub3AsdGlt ZXN0YW1wIDg1Njk5NDcwIDg3NzQ0Nzk4ND4gKERGKQ0KMTAxMjk0MjMxNy4y NzU2MDggZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNs LmxhbmwuZ292LjMyNzkwOiBQIDg1ODQ5Ojg1OTMzKDg0KSBhY2sgNTggd2lu IDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0Nzk4NSA4NTY5OTQ3MD4g KERGKQ0KMTAxMjk0MjMxNy4zMDg4MTMgZXRoMCA8IGJsdWUuYWNsLmxhbmwu Z292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDU4OjU4KDAp IGFjayA4NTkzMyB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5 NDc0IDg3NzQ0Nzk4NT4gKERGKQ0KMTAxMjk0MjMxNy4zMDg4MTMgZXRoMCA+ IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMy NzkwOiBQIDg1OTMzOjg2NjEwKDY3NykgYWNrIDU4IHdpbiA1NzkyIDxub3As bm9wLHRpbWVzdGFtcCA4Nzc0NDgwMTkgODU2OTk0NzQ+IChERikNCjEwMTI5 NDIzMTcuMzA4ODEzIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+ IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA1ODo1OCgwKSBhY2sgODY2MTAg d2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTQ3NCA4Nzc0NDgw MTk+IChERikNCjEwMTI5NDIzMTcuMzE0NjczIGV0aDAgPiB4ZWQuYWNsLmxh bmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCA4NjYx MDo4NjY5NCg4NCkgYWNrIDU4IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFt cCA4Nzc0NDgwMjUgODU2OTk0NzQ+IChERikNCjEwMTI5NDIzMTcuMzE0Njcz IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFu bC5nb3YuMjcwOTogLiA1ODo1OCgwKSBhY2sgODY2OTQgd2luIDUwNjgwIDxu b3Asbm9wLHRpbWVzdGFtcCA4NTY5OTQ3NCA4Nzc0NDgwMjU+IChERikNCjEw MTI5NDIzMTcuMzE0NjczIGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkg PiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCA4NjY5NDo4NzM4MSg2ODcp IGFjayA1OCB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ4MDI1 IDg1Njk5NDc0PiAoREYpDQoxMDEyOTQyMzE3LjMxNDY3MyBldGgwIDwgYmx1 ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6 IC4gNTg6NTgoMCkgYWNrIDg3MzgxIHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1l c3RhbXAgODU2OTk0NzQgODc3NDQ4MDI1PiAoREYpDQoxMDEyOTQyMzE3LjMx NTY0OSBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wu bGFubC5nb3YuMzI3OTA6IFAgODczODE6ODczODIoMSkgYWNrIDU4IHdpbiA1 NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDgwMjYgODU2OTk0NzQ+IChE RikNCjEwMTI5NDIzMTcuMzE1NjQ5IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdv di4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA1ODo1OCgwKSBh Y2sgODczODIgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTQ3 NCA4Nzc0NDgwMjY+IChERikNCjEwMTI5NDIzMTcuMzE1NjQ5IGV0aDAgPCBi bHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcw OTogUCA1ODo1OSgxKSBhY2sgODczODIgd2luIDUwNjgwIDxub3Asbm9wLHRp bWVzdGFtcCA4NTY5OTQ3NCA4Nzc0NDgwMjY+IChERikNCjEwMTI5NDIzMTcu MzE1NjQ5IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFj bC5sYW5sLmdvdi4zMjc5MDogUCA4NzM4Mjo4NzQ2Nig4NCkgYWNrIDU5IHdp biA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDgwMjYgODU2OTk0NzQ+ IChERikNCjEwMTI5NDIzMTcuMzQ4ODU0IGV0aDAgPCBibHVlLmFjbC5sYW5s Lmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA1OTo1OSgw KSBhY2sgODc0NjYgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5 OTQ3OCA4Nzc0NDgwMjY+IChERikNCjEwMTI5NDIzMTcuMzQ4ODU0IGV0aDAg PiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4z Mjc5MDogUCA4NzQ2Njo4ODE0Myg2NzcpIGFjayA1OSB3aW4gNTc5MiA8bm9w LG5vcCx0aW1lc3RhbXAgODc3NDQ4MDYwIDg1Njk5NDc4PiAoREYpDQoxMDEy OTQyMzE3LjM0ODg1NCBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAg PiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNTk6NTkoMCkgYWNrIDg4MTQz IHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0NzggODc3NDQ4 MDYwPiAoREYpDQoxMDEyOTQyMzE3LjM1NDcxNCBldGgwID4geGVkLmFjbC5s YW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgODgx NDM6ODgyMjcoODQpIGFjayA1OSB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3Rh bXAgODc3NDQ4MDY2IDg1Njk5NDc4PiAoREYpDQoxMDEyOTQyMzE3LjM1NDcx NCBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxh bmwuZ292LjI3MDk6IC4gNTk6NTkoMCkgYWNrIDg4MjI3IHdpbiA1MDY4MCA8 bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0NzggODc3NDQ4MDY2PiAoREYpDQox MDEyOTQyMzE3LjM1NDcxNCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5 ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgODgyMjc6ODg5MTQoNjg3 KSBhY2sgNTkgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0ODA2 NiA4NTY5OTQ3OD4gKERGKQ0KMTAxMjk0MjMxNy4zNTQ3MTQgZXRoMCA8IGJs dWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5 OiAuIDU5OjU5KDApIGFjayA4ODkxNCB3aW4gNTA2ODAgPG5vcCxub3AsdGlt ZXN0YW1wIDg1Njk5NDc4IDg3NzQ0ODA2Nj4gKERGKQ0KMTAxMjk0MjMxNy4z NTQ3MTQgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNs LmxhbmwuZ292LjMyNzkwOiBQIDg4OTE0Ojg4OTE1KDEpIGFjayA1OSB3aW4g NTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ4MDY2IDg1Njk5NDc4PiAo REYpDQoxMDEyOTQyMzE3LjM1NTY5MSBldGgwIDwgYmx1ZS5hY2wubGFubC5n b3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNTk6NTkoMCkg YWNrIDg4OTE1IHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0 NzggODc3NDQ4MDY2PiAoREYpDQoxMDEyOTQyMzE3LjM1NTY5MSBldGgwIDwg Ymx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3 MDk6IFAgNTk6NjAoMSkgYWNrIDg4OTE1IHdpbiA1MDY4MCA8bm9wLG5vcCx0 aW1lc3RhbXAgODU2OTk0NzggODc3NDQ4MDY2PiAoREYpDQoxMDEyOTQyMzE3 LjM1NTY5MSBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5h Y2wubGFubC5nb3YuMzI3OTA6IFAgODg5MTU6ODg5OTkoODQpIGFjayA2MCB3 aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ4MDY3IDg1Njk5NDc4 PiAoREYpDQoxMDEyOTQyMzE3LjM4ODg5NiBldGgwIDwgYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNjA6NjAo MCkgYWNrIDg4OTk5IHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2 OTk0ODIgODc3NDQ4MDY3PiAoREYpDQoxMDEyOTQyMzE3LjM4ODg5NiBldGgw ID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3Yu MzI3OTA6IFAgODg5OTk6ODk2NzYoNjc3KSBhY2sgNjAgd2luIDU3OTIgPG5v cCxub3AsdGltZXN0YW1wIDg3NzQ0ODEwMSA4NTY5OTQ4Mj4gKERGKQ0KMTAx Mjk0MjMxNy4zODg4OTYgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkw ID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDYwOjYwKDApIGFjayA4OTY3 NiB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NDgyIDg3NzQ0 ODEwMT4gKERGKQ0KMTAxMjk0MjMxNy4zOTQ3NTYgZXRoMCA+IHhlZC5hY2wu bGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDg5 Njc2Ojg5NzYwKDg0KSBhY2sgNjAgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0 YW1wIDg3NzQ0ODEwNyA4NTY5OTQ4Mj4gKERGKQ0KMTAxMjk0MjMxNy4zOTQ3 NTYgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5s YW5sLmdvdi4yNzA5OiAuIDYwOjYwKDApIGFjayA4OTc2MCB3aW4gNTA2ODAg PG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NDgyIDg3NzQ0ODEwNz4gKERGKQ0K MTAxMjk0MjMxNy4zOTQ3NTYgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcw OSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDg5NzYwOjkwMDcwKDMx MCkgYWNrIDYwIHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDgx MDcgODU2OTk0ODI+IChERikNCjEwMTI5NDIzMTcuMzk0NzU2IGV0aDAgPCBi bHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcw OTogLiA2MDo2MCgwKSBhY2sgOTAwNzAgd2luIDUwNjgwIDxub3Asbm9wLHRp bWVzdGFtcCA4NTY5OTQ4MiA4Nzc0NDgxMDc+IChERikNCjEwMTI5NDIzMTcu Mzk0NzU2IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFj bC5sYW5sLmdvdi4zMjc5MDogUCA5MDA3MDo5MDQ0OCgzNzgpIGFjayA2MCB3 aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ4MTA3IDg1Njk5NDgy PiAoREYpDQoxMDEyOTQyMzE3LjM5NTczMiBldGgwIDwgYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNjA6NjAo MCkgYWNrIDkwNDQ4IHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2 OTk0ODIgODc3NDQ4MTA3PiAoREYpDQoxMDEyOTQyMzE3LjM5NTczMiBldGgw IDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292 LjI3MDk6IFAgNjA6NjEoMSkgYWNrIDkwNDQ4IHdpbiA1MDY4MCA8bm9wLG5v cCx0aW1lc3RhbXAgODU2OTk0ODIgODc3NDQ4MTA3PiAoREYpDQoxMDEyOTQy MzE3LjM5NTczMiBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1 ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgOTA0NDg6OTA1MzIoODQpIGFjayA2 MSB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ4MTA4IDg1Njk5 NDgyPiAoREYpDQoxMDEyOTQyMzE3LjQyODkzNyBldGgwIDwgYmx1ZS5hY2wu bGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNjE6 NjEoMCkgYWNrIDkwNTMyIHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAg ODU2OTk0ODYgODc3NDQ4MTA4PiAoREYpDQoxMDEyOTQyMzE3LjQyODkzNyBl dGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5n b3YuMzI3OTA6IFAgOTA1MzI6OTEyMDkoNjc3KSBhY2sgNjEgd2luIDU3OTIg PG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0ODE0MiA4NTY5OTQ4Nj4gKERGKQ0K MTAxMjk0MjMxNy40Mjg5MzcgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMy NzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDYxOjYxKDApIGFjayA5 MTIwOSB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NDg2IDg3 NzQ0ODE0Mj4gKERGKQ0KMTAxMjk0MjMxNy40MzQ3OTcgZXRoMCA+IHhlZC5h Y2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQ IDkxMjA5OjkxMjkzKDg0KSBhY2sgNjEgd2luIDU3OTIgPG5vcCxub3AsdGlt ZXN0YW1wIDg3NzQ0ODE0OCA4NTY5OTQ4Nj4gKERGKQ0KMTAxMjk0MjMxNy40 MzQ3OTcgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFj bC5sYW5sLmdvdi4yNzA5OiAuIDYxOjYxKDApIGFjayA5MTI5MyB3aW4gNTA2 ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NDg2IDg3NzQ0ODE0OD4gKERG KQ0KMTAxMjk0MjMxNy40MzQ3OTcgZXRoMCA+IHhlZC5hY2wubGFubC5nb3Yu MjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDkxMjkzOjkxNjAz KDMxMCkgYWNrIDYxIHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0 NDgxNDggODU2OTk0ODY+IChERikNCjEwMTI5NDIzMTcuNDM0Nzk3IGV0aDAg PCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3Yu MjcwOTogLiA2MTo2MSgwKSBhY2sgOTE2MDMgd2luIDUwNjgwIDxub3Asbm9w LHRpbWVzdGFtcCA4NTY5OTQ4NiA4Nzc0NDgxNDg+IChERikNCjEwMTI5NDIz MTcuNDM0Nzk3IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVl LmFjbC5sYW5sLmdvdi4zMjc5MDogUCA5MTYwMzo5MTk4MSgzNzgpIGFjayA2 MSB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ4MTQ4IDg1Njk5 NDg2PiAoREYpDQoxMDEyOTQyMzE3LjQzNTc3NCBldGgwIDwgYmx1ZS5hY2wu bGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNjE6 NjEoMCkgYWNrIDkxOTgxIHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAg ODU2OTk0ODYgODc3NDQ4MTQ4PiAoREYpDQoxMDEyOTQyMzE3LjQzNTc3NCBl dGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwu Z292LjI3MDk6IFAgNjE6NjIoMSkgYWNrIDkxOTgxIHdpbiA1MDY4MCA8bm9w LG5vcCx0aW1lc3RhbXAgODU2OTk0ODYgODc3NDQ4MTQ4PiAoREYpDQoxMDEy OTQyMzE3LjQzNTc3NCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4g Ymx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgOTE5ODE6OTIwNjUoODQpIGFj ayA2MiB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ4MTQ5IDg1 Njk5NDg2PiAoREYpDQoxMDEyOTQyMzE3LjQ2ODk3OSBldGgwIDwgYmx1ZS5h Y2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4g NjI6NjIoMCkgYWNrIDkyMDY1IHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3Rh bXAgODU2OTk0OTAgODc3NDQ4MTQ5PiAoREYpDQoxMDEyOTQyMzE3LjQ2ODk3 OSBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTA6IFAgOTIwNjU6OTI3NDIoNjc3KSBhY2sgNjIgd2luIDU3 OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0ODE4MyA4NTY5OTQ5MD4gKERG KQ0KMTAxMjk0MjMxNy40Njg5NzkgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292 LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDYyOjYyKDApIGFj ayA5Mjc0MiB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NDkw IDg3NzQ0ODE4Mz4gKERGKQ0KMTAxMjk0MjMxNy40NzQ4MzkgZXRoMCA+IHhl ZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkw OiBQIDkyNzQyOjkyODI2KDg0KSBhY2sgNjIgd2luIDU3OTIgPG5vcCxub3As dGltZXN0YW1wIDg3NzQ0ODE4OSA4NTY5OTQ5MD4gKERGKQ0KMTAxMjk0MjMx Ny40NzQ4MzkgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVk LmFjbC5sYW5sLmdvdi4yNzA5OiAuIDYyOjYyKDApIGFjayA5MjgyNiB3aW4g NTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NDkwIDg3NzQ0ODE4OT4g KERGKQ0KMTAxMjk0MjMxNy40NzQ4MzkgZXRoMCA+IHhlZC5hY2wubGFubC5n b3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDkyODI2Ojkz NTEzKDY4NykgYWNrIDYyIHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4 Nzc0NDgxODkgODU2OTk0OTA+IChERikNCjEwMTI5NDIzMTcuNDc0ODM5IGV0 aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5n b3YuMjcwOTogLiA2Mjo2MigwKSBhY2sgOTM1MTMgd2luIDUwNjgwIDxub3As bm9wLHRpbWVzdGFtcCA4NTY5OTQ5MCA4Nzc0NDgxODk+IChERikNCjEwMTI5 NDIzMTcuNDc0ODM5IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBi bHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCA5MzUxMzo5MzUxNCgxKSBhY2sg NjIgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0ODE4OSA4NTY5 OTQ5MD4gKERGKQ0KMTAxMjk0MjMxNy40NzU4MTUgZXRoMCA8IGJsdWUuYWNs LmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDYy OjYyKDApIGFjayA5MzUxNCB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1w IDg1Njk5NDkwIDg3NzQ0ODE4OT4gKERGKQ0KMTAxMjk0MjMxNy40NzU4MTUg ZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5s Lmdvdi4yNzA5OiBQIDYyOjYzKDEpIGFjayA5MzUxNCB3aW4gNTA2ODAgPG5v cCxub3AsdGltZXN0YW1wIDg1Njk5NDkwIDg3NzQ0ODE4OT4gKERGKQ0KMTAx Mjk0MjMxNy40NzU4MTUgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+ IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDkzNTE0OjkzNTk4KDg0KSBh Y2sgNjMgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0ODE5MCA4 NTY5OTQ5MD4gKERGKQ0KMTAxMjk0MjMxNy41MDkwMjAgZXRoMCA8IGJsdWUu YWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAu IDYzOjYzKDApIGFjayA5MzU5OCB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0 YW1wIDg1Njk5NDk0IDg3NzQ0ODE5MD4gKERGKQ0KMTAxMjk0MjMxNy41MDkw MjAgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxh bmwuZ292LjMyNzkwOiBQIDkzNTk4Ojk0Mjc1KDY3NykgYWNrIDYzIHdpbiA1 NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDgyMjQgODU2OTk0OTQ+IChE RikNCjEwMTI5NDIzMTcuNTA5MDIwIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdv di4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA2Mzo2MygwKSBh Y2sgOTQyNzUgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTQ5 NCA4Nzc0NDgyMjQ+IChERikNCjEwMTI5NDIzMTcuNTE0ODgwIGV0aDAgPiB4 ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5 MDogUCA5NDI3NTo5NDM1OSg4NCkgYWNrIDYzIHdpbiA1NzkyIDxub3Asbm9w LHRpbWVzdGFtcCA4Nzc0NDgyMzAgODU2OTk0OTQ+IChERikNCjEwMTI5NDIz MTcuNTE0ODgwIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhl ZC5hY2wubGFubC5nb3YuMjcwOTogLiA2Mzo2MygwKSBhY2sgOTQzNTkgd2lu IDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTQ5NCA4Nzc0NDgyMzA+ IChERikNCjEwMTI5NDIzMTcuNTE0ODgwIGV0aDAgPiB4ZWQuYWNsLmxhbmwu Z292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCA5NDM1OTo5 NTA0Nig2ODcpIGFjayA2MyB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAg ODc3NDQ4MjMwIDg1Njk5NDk0PiAoREYpDQoxMDEyOTQyMzE3LjUxNDg4MCBl dGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwu Z292LjI3MDk6IC4gNjM6NjMoMCkgYWNrIDk1MDQ2IHdpbiA1MDY4MCA8bm9w LG5vcCx0aW1lc3RhbXAgODU2OTk0OTQgODc3NDQ4MjMwPiAoREYpDQoxMDEy OTQyMzE3LjUxNDg4MCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4g Ymx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgOTUwNDY6OTUwNDcoMSkgYWNr IDYzIHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDgyMzAgODU2 OTk0OTQ+IChERikNCjEwMTI5NDIzMTcuNTE1ODU3IGV0aDAgPCBibHVlLmFj bC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA2 Mzo2MygwKSBhY2sgOTUwNDcgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFt cCA4NTY5OTQ5NCA4Nzc0NDgyMzA+IChERikNCjEwMTI5NDIzMTcuNTE1ODU3 IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFu bC5nb3YuMjcwOTogUCA2Mzo2NCgxKSBhY2sgOTUwNDcgd2luIDUwNjgwIDxu b3Asbm9wLHRpbWVzdGFtcCA4NTY5OTQ5NCA4Nzc0NDgyMzA+IChERikNCjEw MTI5NDIzMTcuNTE1ODU3IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkg PiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCA5NTA0Nzo5NTEzMSg4NCkg YWNrIDY0IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDgyMzEg ODU2OTk0OTQ+IChERikNCjEwMTI5NDIzMTcuNTQ5MDYyIGV0aDAgPCBibHVl LmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTog LiA2NDo2NCgwKSBhY2sgOTUxMzEgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVz dGFtcCA4NTY5OTQ5OCA4Nzc0NDgyMzE+IChERikNCjEwMTI5NDIzMTcuNTQ5 MDYyIGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5s YW5sLmdvdi4zMjc5MDogUCA5NTEzMTo5NTgwOCg2NzcpIGFjayA2NCB3aW4g NTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ4MjY1IDg1Njk5NDk4PiAo REYpDQoxMDEyOTQyMzE3LjU0OTA2MiBldGgwIDwgYmx1ZS5hY2wubGFubC5n b3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNjQ6NjQoMCkg YWNrIDk1ODA4IHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0 OTggODc3NDQ4MjY1PiAoREYpDQoxMDEyOTQyMzE3LjU1NDkyMSBldGgwID4g eGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3 OTA6IFAgOTU4MDg6OTU4OTIoODQpIGFjayA2NCB3aW4gNTc5MiA8bm9wLG5v cCx0aW1lc3RhbXAgODc3NDQ4MjcxIDg1Njk5NDk4PiAoREYpDQoxMDEyOTQy MzE3LjU1NDkyMSBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4 ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNjQ6NjQoMCkgYWNrIDk1ODkyIHdp biA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0OTggODc3NDQ4Mjcx PiAoREYpDQoxMDEyOTQyMzE3LjU1NDkyMSBldGgwID4geGVkLmFjbC5sYW5s Lmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgOTU4OTI6 OTY1NzkoNjg3KSBhY2sgNjQgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1w IDg3NzQ0ODI3MSA4NTY5OTQ5OD4gKERGKQ0KMTAxMjk0MjMxNy41NTQ5MjEg ZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5s Lmdvdi4yNzA5OiAuIDY0OjY0KDApIGFjayA5NjU3OSB3aW4gNTA2ODAgPG5v cCxub3AsdGltZXN0YW1wIDg1Njk5NDk4IDg3NzQ0ODI3MT4gKERGKQ0KMTAx Mjk0MjMxNy41NTQ5MjEgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+ IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDk2NTc5Ojk2NTgwKDEpIGFj ayA2NCB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ4MjcxIDg1 Njk5NDk4PiAoREYpDQoxMDEyOTQyMzE3LjU1NTg5OCBldGgwIDwgYmx1ZS5h Y2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4g NjQ6NjQoMCkgYWNrIDk2NTgwIHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3Rh bXAgODU2OTk0OTggODc3NDQ4MjcxPiAoREYpDQoxMDEyOTQyMzE3LjU1NTg5 OCBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxh bmwuZ292LjI3MDk6IFAgNjQ6NjUoMSkgYWNrIDk2NTgwIHdpbiA1MDY4MCA8 bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk0OTggODc3NDQ4MjcxPiAoREYpDQox MDEyOTQyMzE3LjU1NTg5OCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5 ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgOTY1ODA6OTY2NjQoODQp IGFjayA2NSB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ4Mjcy IDg1Njk5NDk4PiAoREYpDQoxMDEyOTQyMzE3LjU4OTEwMyBldGgwIDwgYmx1 ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6 IC4gNjU6NjUoMCkgYWNrIDk2NjY0IHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1l c3RhbXAgODU2OTk1MDIgODc3NDQ4MjcyPiAoREYpDQoxMDEyOTQyMzE3LjU4 OTEwMyBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wu bGFubC5nb3YuMzI3OTA6IFAgOTY2NjQ6OTczNDEoNjc3KSBhY2sgNjUgd2lu IDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0ODMwNiA4NTY5OTUwMj4g KERGKQ0KMTAxMjk0MjMxNy41ODkxMDMgZXRoMCA8IGJsdWUuYWNsLmxhbmwu Z292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDY1OjY1KDAp IGFjayA5NzM0MSB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5 NTAyIDg3NzQ0ODMwNj4gKERGKQ0KMTAxMjk0MjMxNy41OTQ5NjMgZXRoMCA+ IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMy NzkwOiBQIDk3MzQxOjk3NDI1KDg0KSBhY2sgNjUgd2luIDU3OTIgPG5vcCxu b3AsdGltZXN0YW1wIDg3NzQ0ODMxMiA4NTY5OTUwMj4gKERGKQ0KMTAxMjk0 MjMxNy41OTQ5NjMgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4g eGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDY1OjY1KDApIGFjayA5NzQyNSB3 aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NTAyIDg3NzQ0ODMx Mj4gKERGKQ0KMTAxMjk0MjMxNy41OTQ5NjMgZXRoMCA+IHhlZC5hY2wubGFu bC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDk3NDI1 Ojk4MTEyKDY4NykgYWNrIDY1IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFt cCA4Nzc0NDgzMTIgODU2OTk1MDI+IChERikNCjEwMTI5NDIzMTcuNTk1OTQw IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFu bC5nb3YuMjcwOTogLiA2NTo2NSgwKSBhY2sgOTgxMTIgd2luIDUwNjgwIDxu b3Asbm9wLHRpbWVzdGFtcCA4NTY5OTUwMiA4Nzc0NDgzMTI+IChERikNCjEw MTI5NDIzMTcuNTk1OTQwIGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkg PiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCA5ODExMjo5ODExMygxKSBh Y2sgNjUgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0ODMxMyA4 NTY5OTUwMj4gKERGKQ0KMTAxMjk0MjMxNy41OTU5NDAgZXRoMCA8IGJsdWUu YWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAu IDY1OjY1KDApIGFjayA5ODExMyB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0 YW1wIDg1Njk5NTAyIDg3NzQ0ODMxMz4gKERGKQ0KMTAxMjk0MjMxNy41OTU5 NDAgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5s YW5sLmdvdi4yNzA5OiBQIDY1OjY2KDEpIGFjayA5ODExMyB3aW4gNTA2ODAg PG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NTAyIDg3NzQ0ODMxMz4gKERGKQ0K MTAxMjk0MjMxNy41OTY5MTYgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcw OSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDk4MTEzOjk4MTk3KDg0 KSBhY2sgNjYgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0ODMx NCA4NTY5OTUwMj4gKERGKQ0KMTAxMjk0MjMxNy42MjgxNjggZXRoMCA8IGJs dWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5 OiAuIDY2OjY2KDApIGFjayA5ODE5NyB3aW4gNTA2ODAgPG5vcCxub3AsdGlt ZXN0YW1wIDg1Njk5NTA2IDg3NzQ0ODMxND4gKERGKQ0KMTAxMjk0MjMxNy42 MjkxNDUgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNs LmxhbmwuZ292LjMyNzkwOiBQIDk4MTk3Ojk4ODc0KDY3NykgYWNrIDY2IHdp biA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDgzNDcgODU2OTk1MDY+ IChERikNCjEwMTI5NDIzMTcuNjI5MTQ1IGV0aDAgPCBibHVlLmFjbC5sYW5s Lmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA2Njo2Nigw KSBhY2sgOTg4NzQgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5 OTUwNiA4Nzc0NDgzNDc+IChERikNCjEwMTI5NDIzMTcuNjM1MDA0IGV0aDAg PiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4z Mjc5MDogUCA5ODg3NDo5ODk1OCg4NCkgYWNrIDY2IHdpbiA1NzkyIDxub3As bm9wLHRpbWVzdGFtcCA4Nzc0NDgzNTMgODU2OTk1MDY+IChERikNCjEwMTI5 NDIzMTcuNjM1MDA0IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+ IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA2Njo2NigwKSBhY2sgOTg5NTgg d2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTUwNiA4Nzc0NDgz NTM+IChERikNCjEwMTI5NDIzMTcuNjM1MDA0IGV0aDAgPiB4ZWQuYWNsLmxh bmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCA5ODk1 ODo5OTY0NSg2ODcpIGFjayA2NiB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3Rh bXAgODc3NDQ4MzUzIDg1Njk5NTA2PiAoREYpDQoxMDEyOTQyMzE3LjYzNTAw NCBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxh bmwuZ292LjI3MDk6IC4gNjY6NjYoMCkgYWNrIDk5NjQ1IHdpbiA1MDY4MCA8 bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk1MDYgODc3NDQ4MzUzPiAoREYpDQox MDEyOTQyMzE3LjYzNTAwNCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5 ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgOTk2NDU6OTk2NDYoMSkg YWNrIDY2IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDgzNTMg ODU2OTk1MDY+IChERikNCjEwMTI5NDIzMTcuNjM1OTgxIGV0aDAgPCBibHVl LmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTog LiA2Njo2NigwKSBhY2sgOTk2NDYgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVz dGFtcCA4NTY5OTUwNiA4Nzc0NDgzNTM+IChERikNCjEwMTI5NDIzMTcuNjM1 OTgxIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wu bGFubC5nb3YuMjcwOTogUCA2Njo2NygxKSBhY2sgOTk2NDYgd2luIDUwNjgw IDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTUwNiA4Nzc0NDgzNTM+IChERikN CjEwMTI5NDIzMTcuNjM1OTgxIGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3 MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCA5OTY0Njo5OTczMCg4 NCkgYWNrIDY3IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDgz NTQgODU2OTk1MDY+IChERikNCjEwMTI5NDIzMTcuNjY4MjEwIGV0aDAgPCBi bHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcw OTogLiA2Nzo2NygwKSBhY2sgOTk3MzAgd2luIDUwNjgwIDxub3Asbm9wLHRp bWVzdGFtcCA4NTY5OTUxMCA4Nzc0NDgzNTQ+IChERikNCjEwMTI5NDIzMTcu NjY4MjEwIGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFj bC5sYW5sLmdvdi4zMjc5MDogUCA5OTczMDoxMDA0MDcoNjc3KSBhY2sgNjcg d2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0ODM4NyA4NTY5OTUx MD4gKERGKQ0KMTAxMjk0MjMxNy42NjkxODYgZXRoMCA8IGJsdWUuYWNsLmxh bmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDY3OjY3 KDApIGFjayAxMDA0MDcgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4 NTY5OTUxMCA4Nzc0NDgzODc+IChERikNCjEwMTI5NDIzMTcuNjc1MDQ2IGV0 aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdv di4zMjc5MDogUCAxMDA0MDc6MTAwNDkxKDg0KSBhY2sgNjcgd2luIDU3OTIg PG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0ODM5NCA4NTY5OTUxMD4gKERGKQ0K MTAxMjk0MjMxNy42NzUwNDYgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMy NzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDY3OjY3KDApIGFjayAx MDA0OTEgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTUxMCA4 Nzc0NDgzOTQ+IChERikNCjEwMTI5NDIzMTcuNjc1MDQ2IGV0aDAgPiB4ZWQu YWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDog UCAxMDA0OTE6MTAwODAxKDMxMCkgYWNrIDY3IHdpbiA1NzkyIDxub3Asbm9w LHRpbWVzdGFtcCA4Nzc0NDgzOTQgODU2OTk1MTA+IChERikNCjEwMTI5NDIz MTcuNjc1MDQ2IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhl ZC5hY2wubGFubC5nb3YuMjcwOTogLiA2Nzo2NygwKSBhY2sgMTAwODAxIHdp biA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk1MTAgODc3NDQ4Mzk0 PiAoREYpDQoxMDEyOTQyMzE3LjY3NTA0NiBldGgwID4geGVkLmFjbC5sYW5s Lmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMTAwODAx OjEwMTE3OSgzNzgpIGFjayA2NyB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3Rh bXAgODc3NDQ4Mzk0IDg1Njk5NTEwPiAoREYpDQoxMDEyOTQyMzE3LjY3NjAy MiBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxh bmwuZ292LjI3MDk6IC4gNjc6NjcoMCkgYWNrIDEwMTE3OSB3aW4gNTA2ODAg PG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NTEwIDg3NzQ0ODM5ND4gKERGKQ0K MTAxMjk0MjMxNy42NzYwMjIgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMy NzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiBQIDY3OjY4KDEpIGFjayAx MDExNzkgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTUxMCA4 Nzc0NDgzOTQ+IChERikNCjEwMTI5NDIzMTcuNjc2MDIyIGV0aDAgPiB4ZWQu YWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDog UCAxMDExNzk6MTAxMjYzKDg0KSBhY2sgNjggd2luIDU3OTIgPG5vcCxub3As dGltZXN0YW1wIDg3NzQ0ODM5NSA4NTY5OTUxMD4gKERGKQ0KMTAxMjk0MjMx Ny43MDgyNTEgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVk LmFjbC5sYW5sLmdvdi4yNzA5OiAuIDY4OjY4KDApIGFjayAxMDEyNjMgd2lu IDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTUxNCA4Nzc0NDgzOTU+ IChERikNCjEwMTI5NDIzMTcuNzA4MjUxIGV0aDAgPiB4ZWQuYWNsLmxhbmwu Z292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAxMDEyNjM6 MTAxOTQwKDY3NykgYWNrIDY4IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFt cCA4Nzc0NDg0MjggODU2OTk1MTQ+IChERikNCjEwMTI5NDIzMTcuNzA5MjI4 IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFu bC5nb3YuMjcwOTogLiA2ODo2OCgwKSBhY2sgMTAxOTQwIHdpbiA1MDY4MCA8 bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk1MTQgODc3NDQ4NDI4PiAoREYpDQox MDEyOTQyMzE3LjcxNTA4NyBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5 ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMTAxOTQwOjEwMjAyNCg4 NCkgYWNrIDY4IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDg0 MzUgODU2OTk1MTQ+IChERikNCjEwMTI5NDIzMTcuNzE1MDg3IGV0aDAgPCBi bHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcw OTogLiA2ODo2OCgwKSBhY2sgMTAyMDI0IHdpbiA1MDY4MCA8bm9wLG5vcCx0 aW1lc3RhbXAgODU2OTk1MTQgODc3NDQ4NDM1PiAoREYpDQoxMDEyOTQyMzE3 LjcxNTA4NyBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5h Y2wubGFubC5nb3YuMzI3OTA6IFAgMTAyMDI0OjEwMjcxMSg2ODcpIGFjayA2 OCB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ4NDM1IDg1Njk5 NTE0PiAoREYpDQoxMDEyOTQyMzE3LjcxNTA4NyBldGgwIDwgYmx1ZS5hY2wu bGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNjg6 NjgoMCkgYWNrIDEwMjcxMSB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1w IDg1Njk5NTE0IDg3NzQ0ODQzNT4gKERGKQ0KMTAxMjk0MjMxNy43MTUwODcg ZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwu Z292LjMyNzkwOiBQIDEwMjcxMToxMDI3MTIoMSkgYWNrIDY4IHdpbiA1Nzky IDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDg0MzUgODU2OTk1MTQ+IChERikN CjEwMTI5NDIzMTcuNzE2MDY0IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4z Mjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA2ODo2OCgwKSBhY2sg MTAyNzEyIHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk1MTQg ODc3NDQ4NDM1PiAoREYpDQoxMDEyOTQyMzE3LjcxNjA2NCBldGgwIDwgYmx1 ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6 IFAgNjg6NjkoMSkgYWNrIDEwMjcxMiB3aW4gNTA2ODAgPG5vcCxub3AsdGlt ZXN0YW1wIDg1Njk5NTE0IDg3NzQ0ODQzNT4gKERGKQ0KMTAxMjk0MjMxNy43 MTYwNjQgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNs LmxhbmwuZ292LjMyNzkwOiBQIDEwMjcxMjoxMDI3OTYoODQpIGFjayA2OSB3 aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ4NDM2IDg1Njk5NTE0 PiAoREYpDQoxMDEyOTQyMzE3Ljc0ODI5MiBldGgwIDwgYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNjk6Njko MCkgYWNrIDEwMjc5NiB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1 Njk5NTE4IDg3NzQ0ODQzNj4gKERGKQ0KMTAxMjk0MjMxNy43NDgyOTIgZXRo MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292 LjMyNzkwOiBQIDEwMjc5NjoxMDM0NzMoNjc3KSBhY2sgNjkgd2luIDU3OTIg PG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0ODQ2OSA4NTY5OTUxOD4gKERGKQ0K MTAxMjk0MjMxNy43NDkyNjkgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMy NzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDY5OjY5KDApIGFjayAx MDM0NzMgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTUxOCA4 Nzc0NDg0Njk+IChERikNCjEwMTI5NDIzMTcuNzU1MTI5IGV0aDAgPiB4ZWQu YWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDog UCAxMDM0NzM6MTAzNTU3KDg0KSBhY2sgNjkgd2luIDU3OTIgPG5vcCxub3As dGltZXN0YW1wIDg3NzQ0ODQ3NiA4NTY5OTUxOD4gKERGKQ0KMTAxMjk0MjMx Ny43NTUxMjkgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVk LmFjbC5sYW5sLmdvdi4yNzA5OiAuIDY5OjY5KDApIGFjayAxMDM1NTcgd2lu IDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTUxOCA4Nzc0NDg0NzY+ IChERikNCjEwMTI5NDIzMTcuNzU1MTI5IGV0aDAgPiB4ZWQuYWNsLmxhbmwu Z292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAxMDM1NTc6 MTAzODY3KDMxMCkgYWNrIDY5IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFt cCA4Nzc0NDg0NzYgODU2OTk1MTg+IChERikNCjEwMTI5NDIzMTcuNzU1MTI5 IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFu bC5nb3YuMjcwOTogLiA2OTo2OSgwKSBhY2sgMTAzODY3IHdpbiA1MDY4MCA8 bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk1MTggODc3NDQ4NDc2PiAoREYpDQox MDEyOTQyMzE3Ljc1NTEyOSBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5 ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMTAzODY3OjEwNDI0NSgz NzgpIGFjayA2OSB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ4 NDc2IDg1Njk5NTE4PiAoREYpDQoxMDEyOTQyMzE3Ljc1NjEwNSBldGgwIDwg Ymx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3 MDk6IC4gNjk6NjkoMCkgYWNrIDEwNDI0NSB3aW4gNTA2ODAgPG5vcCxub3As dGltZXN0YW1wIDg1Njk5NTE4IDg3NzQ0ODQ3Nj4gKERGKQ0KMTAxMjk0MjMx Ny43NTYxMDUgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVk LmFjbC5sYW5sLmdvdi4yNzA5OiBQIDY5OjcwKDEpIGFjayAxMDQyNDUgd2lu IDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTUxOCA4Nzc0NDg0NzY+ IChERikNCjEwMTI5NDIzMTcuNzU2MTA1IGV0aDAgPiB4ZWQuYWNsLmxhbmwu Z292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAxMDQyNDU6 MTA0MzI5KDg0KSBhY2sgNzAgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1w IDg3NzQ0ODQ3NyA4NTY5OTUxOD4gKERGKQ0KMTAxMjk0MjMxNy43ODgzMzQg ZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5s Lmdvdi4yNzA5OiAuIDcwOjcwKDApIGFjayAxMDQzMjkgd2luIDUwNjgwIDxu b3Asbm9wLHRpbWVzdGFtcCA4NTY5OTUyMiA4Nzc0NDg0Nzc+IChERikNCjEw MTI5NDIzMTcuNzg4MzM0IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkg PiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAxMDQzMjk6MTA1MDA2KDY3 NykgYWNrIDcwIHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDg1 MTAgODU2OTk1MjI+IChERikNCjEwMTI5NDIzMTcuNzg5MzExIGV0aDAgPCBi bHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcw OTogLiA3MDo3MCgwKSBhY2sgMTA1MDA2IHdpbiA1MDY4MCA8bm9wLG5vcCx0 aW1lc3RhbXAgODU2OTk1MjIgODc3NDQ4NTEwPiAoREYpDQoxMDEyOTQyMzE3 Ljc5NTE3MCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5h Y2wubGFubC5nb3YuMzI3OTA6IFAgMTA1MDA2OjEwNTA5MCg4NCkgYWNrIDcw IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDg1MTcgODU2OTk1 MjI+IChERikNCjEwMTI5NDIzMTcuNzk1MTcwIGV0aDAgPCBibHVlLmFjbC5s YW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA3MDo3 MCgwKSBhY2sgMTA1MDkwIHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAg ODU2OTk1MjIgODc3NDQ4NTE3PiAoREYpDQoxMDEyOTQyMzE3Ljc5NTE3MCBl dGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5n b3YuMzI3OTA6IFAgMTA1MDkwOjEwNTQwMCgzMTApIGFjayA3MCB3aW4gNTc5 MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ4NTE3IDg1Njk5NTIyPiAoREYp DQoxMDEyOTQyMzE3Ljc5NTE3MCBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3Yu MzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNzA6NzAoMCkgYWNr IDEwNTQwMCB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NTIy IDg3NzQ0ODUxNz4gKERGKQ0KMTAxMjk0MjMxNy43OTUxNzAgZXRoMCA+IHhl ZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkw OiBQIDEwNTQwMDoxMDU3NzgoMzc4KSBhY2sgNzAgd2luIDU3OTIgPG5vcCxu b3AsdGltZXN0YW1wIDg3NzQ0ODUxNyA4NTY5OTUyMj4gKERGKQ0KMTAxMjk0 MjMxNy43OTYxNDcgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4g eGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDcwOjcwKDApIGFjayAxMDU3Nzgg d2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTUyMiA4Nzc0NDg1 MTc+IChERikNCjEwMTI5NDIzMTcuNzk2MTQ3IGV0aDAgPCBibHVlLmFjbC5s YW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogUCA3MDo3 MSgxKSBhY2sgMTA1Nzc4IHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAg ODU2OTk1MjIgODc3NDQ4NTE3PiAoREYpDQoxMDEyOTQyMzE3Ljc5NzEyNCBl dGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5n b3YuMzI3OTA6IFAgMTA1Nzc4OjEwNTg2Mig4NCkgYWNrIDcxIHdpbiA1Nzky IDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDg1MTkgODU2OTk1MjI+IChERikN CjEwMTI5NDIzMTcuODI4Mzc1IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4z Mjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA3MTo3MSgwKSBhY2sg MTA1ODYyIHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk1MjYg ODc3NDQ4NTE5PiAoREYpDQoxMDEyOTQyMzE3LjgyODM3NSBldGgwID4geGVk LmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6 IFAgMTA1ODYyOjEwNjUzOSg2NzcpIGFjayA3MSB3aW4gNTc5MiA8bm9wLG5v cCx0aW1lc3RhbXAgODc3NDQ4NTUxIDg1Njk5NTI2PiAoREYpDQoxMDEyOTQy MzE3LjgyOTM1MiBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4 ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNzE6NzEoMCkgYWNrIDEwNjUzOSB3 aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NTI2IDg3NzQ0ODU1 MT4gKERGKQ0KMTAxMjk0MjMxNy44MzUyMTIgZXRoMCA+IHhlZC5hY2wubGFu bC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDEwNjUz OToxMDY2MjMoODQpIGFjayA3MSB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3Rh bXAgODc3NDQ4NTU4IDg1Njk5NTI2PiAoREYpDQoxMDEyOTQyMzE3LjgzNTIx MiBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxh bmwuZ292LjI3MDk6IC4gNzE6NzEoMCkgYWNrIDEwNjYyMyB3aW4gNTA2ODAg PG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NTI2IDg3NzQ0ODU1OD4gKERGKQ0K MTAxMjk0MjMxNy44MzUyMTIgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcw OSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDEwNjYyMzoxMDY5MzMo MzEwKSBhY2sgNzEgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0 ODU1OCA4NTY5OTUyNj4gKERGKQ0KMTAxMjk0MjMxNy44MzUyMTIgZXRoMCA8 IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4y NzA5OiAuIDcxOjcxKDApIGFjayAxMDY5MzMgd2luIDUwNjgwIDxub3Asbm9w LHRpbWVzdGFtcCA4NTY5OTUyNiA4Nzc0NDg1NTg+IChERikNCjEwMTI5NDIz MTcuODM1MjEyIGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVl LmFjbC5sYW5sLmdvdi4zMjc5MDogUCAxMDY5MzM6MTA3MzExKDM3OCkgYWNr IDcxIHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDg1NTggODU2 OTk1MjY+IChERikNCjEwMTI5NDIzMTcuODM2MTg4IGV0aDAgPCBibHVlLmFj bC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA3 MTo3MSgwKSBhY2sgMTA3MzExIHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3Rh bXAgODU2OTk1MjYgODc3NDQ4NTU4PiAoREYpDQoxMDEyOTQyMzE3LjgzNjE4 OCBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxh bmwuZ292LjI3MDk6IFAgNzE6NzIoMSkgYWNrIDEwNzMxMSB3aW4gNTA2ODAg PG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NTI2IDg3NzQ0ODU1OD4gKERGKQ0K MTAxMjk0MjMxNy44MzYxODggZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcw OSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDEwNzMxMToxMDczOTUo ODQpIGFjayA3MiB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ4 NTU5IDg1Njk5NTI2PiAoREYpDQoxMDEyOTQyMzE3Ljg2ODQxNyBldGgwIDwg Ymx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3 MDk6IC4gNzI6NzIoMCkgYWNrIDEwNzM5NSB3aW4gNTA2ODAgPG5vcCxub3As dGltZXN0YW1wIDg1Njk5NTMwIDg3NzQ0ODU1OT4gKERGKQ0KMTAxMjk0MjMx Ny44Njg0MTcgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUu YWNsLmxhbmwuZ292LjMyNzkwOiBQIDEwNzM5NToxMDgwNzIoNjc3KSBhY2sg NzIgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0ODU5MiA4NTY5 OTUzMD4gKERGKQ0KMTAxMjk0MjMxNy44NjkzOTMgZXRoMCA8IGJsdWUuYWNs LmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDcy OjcyKDApIGFjayAxMDgwNzIgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFt cCA4NTY5OTUzMCA4Nzc0NDg1OTI+IChERikNCjEwMTI5NDIzMTcuODc1MjUz IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5s Lmdvdi4zMjc5MDogUCAxMDgwNzI6MTA4MTU2KDg0KSBhY2sgNzIgd2luIDU3 OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0ODU5OSA4NTY5OTUzMD4gKERG KQ0KMTAxMjk0MjMxNy44NzUyNTMgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292 LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDcyOjcyKDApIGFj ayAxMDgxNTYgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTUz MCA4Nzc0NDg1OTk+IChERikNCjEwMTI5NDIzMTcuODc1MjUzIGV0aDAgPiB4 ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5 MDogUCAxMDgxNTY6MTA4NDY2KDMxMCkgYWNrIDcyIHdpbiA1NzkyIDxub3As bm9wLHRpbWVzdGFtcCA4Nzc0NDg1OTkgODU2OTk1MzA+IChERikNCjEwMTI5 NDIzMTcuODc1MjUzIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+ IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA3Mjo3MigwKSBhY2sgMTA4NDY2 IHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk1MzAgODc3NDQ4 NTk5PiAoREYpDQoxMDEyOTQyMzE3Ljg3NTI1MyBldGgwID4geGVkLmFjbC5s YW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMTA4 NDY2OjEwODg0NCgzNzgpIGFjayA3MiB3aW4gNTc5MiA8bm9wLG5vcCx0aW1l c3RhbXAgODc3NDQ4NTk5IDg1Njk5NTMwPiAoREYpDQoxMDEyOTQyMzE3Ljg3 NjIzMCBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNs LmxhbmwuZ292LjI3MDk6IC4gNzI6NzIoMCkgYWNrIDEwODg0NCB3aW4gNTA2 ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NTMwIDg3NzQ0ODU5OT4gKERG KQ0KMTAxMjk0MjMxNy44NzYyMzAgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292 LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiBQIDcyOjczKDEpIGFj ayAxMDg4NDQgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTUz MCA4Nzc0NDg1OTk+IChERikNCjEwMTI5NDIzMTcuODc2MjMwIGV0aDAgPiB4 ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5 MDogUCAxMDg4NDQ6MTA4OTI4KDg0KSBhY2sgNzMgd2luIDU3OTIgPG5vcCxu b3AsdGltZXN0YW1wIDg3NzQ0ODYwMCA4NTY5OTUzMD4gKERGKQ0KMTAxMjk0 MjMxNy45MDg0NTggZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4g eGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDczOjczKDApIGFjayAxMDg5Mjgg d2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTUzNCA4Nzc0NDg2 MDA+IChERikNCjEwMTI5NDIzMTcuOTA4NDU4IGV0aDAgPiB4ZWQuYWNsLmxh bmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAxMDg5 Mjg6MTA5NjA1KDY3NykgYWNrIDczIHdpbiA1NzkyIDxub3Asbm9wLHRpbWVz dGFtcCA4Nzc0NDg2MzMgODU2OTk1MzQ+IChERikNCjEwMTI5NDIzMTcuOTA4 NDU4IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wu bGFubC5nb3YuMjcwOTogLiA3Mzo3MygwKSBhY2sgMTA5NjA1IHdpbiA1MDY4 MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk1MzQgODc3NDQ4NjMzPiAoREYp DQoxMDEyOTQyMzE3LjkxNTI5NSBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4y NzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMTA5NjA1OjEwOTY4 OSg4NCkgYWNrIDczIHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0 NDg2NDAgODU2OTk1MzQ+IChERikNCjEwMTI5NDIzMTcuOTE1Mjk1IGV0aDAg PCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3Yu MjcwOTogLiA3Mzo3MygwKSBhY2sgMTA5Njg5IHdpbiA1MDY4MCA8bm9wLG5v cCx0aW1lc3RhbXAgODU2OTk1MzQgODc3NDQ4NjQwPiAoREYpDQoxMDEyOTQy MzE3LjkxNTI5NSBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1 ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMTA5Njg5OjEwOTk5OSgzMTApIGFj ayA3MyB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ4NjQwIDg1 Njk5NTM0PiAoREYpDQoxMDEyOTQyMzE3LjkxNTI5NSBldGgwIDwgYmx1ZS5h Y2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4g NzM6NzMoMCkgYWNrIDEwOTk5OSB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0 YW1wIDg1Njk5NTM0IDg3NzQ0ODY0MD4gKERGKQ0KMTAxMjk0MjMxNy45MTUy OTUgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxh bmwuZ292LjMyNzkwOiBQIDEwOTk5OToxMTAzNzcoMzc4KSBhY2sgNzMgd2lu IDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0ODY0MCA4NTY5OTUzND4g KERGKQ0KMTAxMjk0MjMxNy45MTYyNzEgZXRoMCA8IGJsdWUuYWNsLmxhbmwu Z292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDczOjczKDAp IGFjayAxMTAzNzcgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5 OTUzNCA4Nzc0NDg2NDA+IChERikNCjEwMTI5NDIzMTcuOTE2MjcxIGV0aDAg PCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3Yu MjcwOTogUCA3Mzo3NCgxKSBhY2sgMTEwMzc3IHdpbiA1MDY4MCA8bm9wLG5v cCx0aW1lc3RhbXAgODU2OTk1MzQgODc3NDQ4NjQwPiAoREYpDQoxMDEyOTQy MzE3LjkxNjI3MSBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1 ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMTEwMzc3OjExMDQ2MSg4NCkgYWNr IDc0IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDg2NDEgODU2 OTk1MzQ+IChERikNCjEwMTI5NDIzMTcuOTQ4NTAwIGV0aDAgPCBibHVlLmFj bC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA3 NDo3NCgwKSBhY2sgMTEwNDYxIHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3Rh bXAgODU2OTk1MzggODc3NDQ4NjQxPiAoREYpDQoxMDEyOTQyMzE3Ljk0ODUw MCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTA6IFAgMTEwNDYxOjExMTEzOCg2NzcpIGFjayA3NCB3aW4g NTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ4Njc0IDg1Njk5NTM4PiAo REYpDQoxMDEyOTQyMzE3Ljk0ODUwMCBldGgwIDwgYmx1ZS5hY2wubGFubC5n b3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNzQ6NzQoMCkg YWNrIDExMTEzOCB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5 NTM4IDg3NzQ0ODY3ND4gKERGKQ0KMTAxMjk0MjMxNy45NTUzMzYgZXRoMCA+ IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMy NzkwOiBQIDExMTEzODoxMTEyMjIoODQpIGFjayA3NCB3aW4gNTc5MiA8bm9w LG5vcCx0aW1lc3RhbXAgODc3NDQ4NjgxIDg1Njk5NTM4PiAoREYpDQoxMDEy OTQyMzE3Ljk1NTMzNiBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAg PiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNzQ6NzQoMCkgYWNrIDExMTIy MiB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NTM4IDg3NzQ0 ODY4MT4gKERGKQ0KMTAxMjk0MjMxNy45NTUzMzYgZXRoMCA+IHhlZC5hY2wu bGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDEx MTIyMjoxMTE1MzIoMzEwKSBhY2sgNzQgd2luIDU3OTIgPG5vcCxub3AsdGlt ZXN0YW1wIDg3NzQ0ODY4MSA4NTY5OTUzOD4gKERGKQ0KMTAxMjk0MjMxNy45 NTUzMzYgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFj bC5sYW5sLmdvdi4yNzA5OiAuIDc0Ojc0KDApIGFjayAxMTE1MzIgd2luIDUw NjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTUzOCA4Nzc0NDg2ODE+IChE RikNCjEwMTI5NDIzMTcuOTU1MzM2IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292 LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAxMTE1MzI6MTEx OTEwKDM3OCkgYWNrIDc0IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4 Nzc0NDg2ODEgODU2OTk1Mzg+IChERikNCjEwMTI5NDIzMTcuOTU2MzEzIGV0 aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5n b3YuMjcwOTogLiA3NDo3NCgwKSBhY2sgMTExOTEwIHdpbiA1MDY4MCA8bm9w LG5vcCx0aW1lc3RhbXAgODU2OTk1MzggODc3NDQ4NjgxPiAoREYpDQoxMDEy OTQyMzE3Ljk1NjMxMyBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAg PiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IFAgNzQ6NzUoMSkgYWNrIDExMTkx MCB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NTM4IDg3NzQ0 ODY4MT4gKERGKQ0KMTAxMjk0MjMxNy45NTcyODkgZXRoMCA+IHhlZC5hY2wu bGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDEx MTkxMDoxMTE5OTQoODQpIGFjayA3NSB3aW4gNTc5MiA8bm9wLG5vcCx0aW1l c3RhbXAgODc3NDQ4NjgzIDg1Njk5NTM4PiAoREYpDQoxMDEyOTQyMzE3Ljk4 ODU0MSBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNs LmxhbmwuZ292LjI3MDk6IC4gNzU6NzUoMCkgYWNrIDExMTk5NCB3aW4gNTA2 ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NTQyIDg3NzQ0ODY4Mz4gKERG KQ0KMTAxMjk0MjMxNy45ODg1NDEgZXRoMCA+IHhlZC5hY2wubGFubC5nb3Yu MjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDExMTk5NDoxMTI2 NzEoNjc3KSBhY2sgNzUgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3 NzQ0ODcxNSA4NTY5OTU0Mj4gKERGKQ0KMTAxMjk0MjMxNy45ODg1NDEgZXRo MCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdv di4yNzA5OiAuIDc1Ojc1KDApIGFjayAxMTI2NzEgd2luIDUwNjgwIDxub3As bm9wLHRpbWVzdGFtcCA4NTY5OTU0MiA4Nzc0NDg3MTU+IChERikNCjEwMTI5 NDIzMTcuOTk1Mzc4IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBi bHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAxMTI2NzE6MTEyNzU1KDg0KSBh Y2sgNzUgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0ODcyMiA4 NTY5OTU0Mj4gKERGKQ0KMTAxMjk0MjMxNy45OTUzNzggZXRoMCA8IGJsdWUu YWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAu IDc1Ojc1KDApIGFjayAxMTI3NTUgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVz dGFtcCA4NTY5OTU0MiA4Nzc0NDg3MjI+IChERikNCjEwMTI5NDIzMTcuOTk1 Mzc4IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5s YW5sLmdvdi4zMjc5MDogUCAxMTI3NTU6MTEzMDY1KDMxMCkgYWNrIDc1IHdp biA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDg3MjIgODU2OTk1NDI+ IChERikNCjEwMTI5NDIzMTcuOTk1Mzc4IGV0aDAgPCBibHVlLmFjbC5sYW5s Lmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA3NTo3NSgw KSBhY2sgMTEzMDY1IHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2 OTk1NDIgODc3NDQ4NzIyPiAoREYpDQoxMDEyOTQyMzE3Ljk5NTM3OCBldGgw ID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3Yu MzI3OTA6IFAgMTEzMDY1OjExMzQ0MygzNzgpIGFjayA3NSB3aW4gNTc5MiA8 bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ4NzIyIDg1Njk5NTQyPiAoREYpDQox MDEyOTQyMzE3Ljk5NjM1NCBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3 OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNzU6NzUoMCkgYWNrIDEx MzQ0MyB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NTQyIDg3 NzQ0ODcyMj4gKERGKQ0KMTAxMjk0MjMxNy45OTYzNTQgZXRoMCA8IGJsdWUu YWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiBQ IDc1Ojc2KDEpIGFjayAxMTM0NDMgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVz dGFtcCA4NTY5OTU0MiA4Nzc0NDg3MjI+IChERikNCjEwMTI5NDIzMTcuOTk2 MzU0IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5s YW5sLmdvdi4zMjc5MDogUCAxMTM0NDM6MTEzNTI3KDg0KSBhY2sgNzYgd2lu IDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0ODcyMyA4NTY5OTU0Mj4g KERGKQ0KMTAxMjk0MjMxOC4wMjg1ODMgZXRoMCA8IGJsdWUuYWNsLmxhbmwu Z292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDc2Ojc2KDAp IGFjayAxMTM1Mjcgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5 OTU0NiA4Nzc0NDg3MjM+IChERikNCjEwMTI5NDIzMTguMDI4NTgzIGV0aDAg PiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4z Mjc5MDogUCAxMTM1Mjc6MTE0MjA0KDY3NykgYWNrIDc2IHdpbiA1NzkyIDxu b3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDg3NTYgODU2OTk1NDY+IChERikNCjEw MTI5NDIzMTguMDI4NTgzIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5 MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA3Njo3NigwKSBhY2sgMTE0 MjA0IHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk1NDYgODc3 NDQ4NzU2PiAoREYpDQoxMDEyOTQyMzE4LjAzNTQxOSBldGgwID4geGVkLmFj bC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAg MTE0MjA0OjExNDI4OCg4NCkgYWNrIDc2IHdpbiA1NzkyIDxub3Asbm9wLHRp bWVzdGFtcCA4Nzc0NDg3NjMgODU2OTk1NDY+IChERikNCjEwMTI5NDIzMTgu MDM1NDE5IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5h Y2wubGFubC5nb3YuMjcwOTogLiA3Njo3NigwKSBhY2sgMTE0Mjg4IHdpbiA1 MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk1NDYgODc3NDQ4NzYzPiAo REYpDQoxMDEyOTQyMzE4LjAzNTQxOSBldGgwID4geGVkLmFjbC5sYW5sLmdv di4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMTE0Mjg4OjEx NDU5OCgzMTApIGFjayA3NiB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAg ODc3NDQ4NzYzIDg1Njk5NTQ2PiAoREYpDQoxMDEyOTQyMzE4LjAzNTQxOSBl dGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwu Z292LjI3MDk6IC4gNzY6NzYoMCkgYWNrIDExNDU5OCB3aW4gNTA2ODAgPG5v cCxub3AsdGltZXN0YW1wIDg1Njk5NTQ2IDg3NzQ0ODc2Mz4gKERGKQ0KMTAx Mjk0MjMxOC4wMzU0MTkgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+ IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDExNDU5ODoxMTQ5NzYoMzc4 KSBhY2sgNzYgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0ODc2 MyA4NTY5OTU0Nj4gKERGKQ0KMTAxMjk0MjMxOC4wMzYzOTYgZXRoMCA8IGJs dWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5 OiAuIDc2Ojc2KDApIGFjayAxMTQ5NzYgd2luIDUwNjgwIDxub3Asbm9wLHRp bWVzdGFtcCA4NTY5OTU0NiA4Nzc0NDg3NjM+IChERikNCjEwMTI5NDIzMTgu MDM2Mzk2IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5h Y2wubGFubC5nb3YuMjcwOTogUCA3Njo3NygxKSBhY2sgMTE0OTc2IHdpbiA1 MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk1NDYgODc3NDQ4NzYzPiAo REYpDQoxMDEyOTQyMzE4LjAzNjM5NiBldGgwID4geGVkLmFjbC5sYW5sLmdv di4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMTE0OTc2OjEx NTA2MCg4NCkgYWNrIDc3IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4 Nzc0NDg3NjQgODU2OTk1NDY+IChERikNCjEwMTI5NDIzMTguMDY4NjI0IGV0 aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5n b3YuMjcwOTogLiA3Nzo3NygwKSBhY2sgMTE1MDYwIHdpbiA1MDY4MCA8bm9w LG5vcCx0aW1lc3RhbXAgODU2OTk1NTAgODc3NDQ4NzY0PiAoREYpDQoxMDEy OTQyMzE4LjA2ODYyNCBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4g Ymx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMTE1MDYwOjExNTczNyg2Nzcp IGFjayA3NyB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ4Nzk3 IDg1Njk5NTUwPiAoREYpDQoxMDEyOTQyMzE4LjA2ODYyNCBldGgwIDwgYmx1 ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6 IC4gNzc6NzcoMCkgYWNrIDExNTczNyB3aW4gNTA2ODAgPG5vcCxub3AsdGlt ZXN0YW1wIDg1Njk5NTUwIDg3NzQ0ODc5Nz4gKERGKQ0KMTAxMjk0MjMxOC4w NzU0NjEgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNs LmxhbmwuZ292LjMyNzkwOiBQIDExNTczNzoxMTU4MjEoODQpIGFjayA3NyB3 aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ4ODA0IDg1Njk5NTUw PiAoREYpDQoxMDEyOTQyMzE4LjA3NTQ2MSBldGgwIDwgYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNzc6Nzco MCkgYWNrIDExNTgyMSB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1 Njk5NTUwIDg3NzQ0ODgwND4gKERGKQ0KMTAxMjk0MjMxOC4wNzU0NjEgZXRo MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292 LjMyNzkwOiBQIDExNTgyMToxMTYxMzEoMzEwKSBhY2sgNzcgd2luIDU3OTIg PG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0ODgwNCA4NTY5OTU1MD4gKERGKQ0K MTAxMjk0MjMxOC4wNzU0NjEgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMy NzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDc3Ojc3KDApIGFjayAx MTYxMzEgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTU1MCA4 Nzc0NDg4MDQ+IChERikNCjEwMTI5NDIzMTguMDc1NDYxIGV0aDAgPiB4ZWQu YWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDog UCAxMTYxMzE6MTE2NTA5KDM3OCkgYWNrIDc3IHdpbiA1NzkyIDxub3Asbm9w LHRpbWVzdGFtcCA4Nzc0NDg4MDQgODU2OTk1NTA+IChERikNCjEwMTI5NDIz MTguMDc2NDM3IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhl ZC5hY2wubGFubC5nb3YuMjcwOTogLiA3Nzo3NygwKSBhY2sgMTE2NTA5IHdp biA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk1NTAgODc3NDQ4ODA0 PiAoREYpDQoxMDEyOTQyMzE4LjA3NjQzNyBldGgwIDwgYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IFAgNzc6Nzgo MSkgYWNrIDExNjUwOSB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1 Njk5NTUwIDg3NzQ0ODgwND4gKERGKQ0KMTAxMjk0MjMxOC4wNzY0MzcgZXRo MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292 LjMyNzkwOiBQIDExNjUwOToxMTY1OTMoODQpIGFjayA3OCB3aW4gNTc5MiA8 bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ4ODA1IDg1Njk5NTUwPiAoREYpDQox MDEyOTQyMzE4LjEwODY2NiBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3 OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNzg6NzgoMCkgYWNrIDEx NjU5MyB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NTU0IDg3 NzQ0ODgwNT4gKERGKQ0KMTAxMjk0MjMxOC4xMDg2NjYgZXRoMCA+IHhlZC5h Y2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQ IDExNjU5MzoxMTcyNzAoNjc3KSBhY2sgNzggd2luIDU3OTIgPG5vcCxub3As dGltZXN0YW1wIDg3NzQ0ODgzOCA4NTY5OTU1ND4gKERGKQ0KMTAxMjk0MjMx OC4xMDg2NjYgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVk LmFjbC5sYW5sLmdvdi4yNzA5OiAuIDc4Ojc4KDApIGFjayAxMTcyNzAgd2lu IDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTU1NCA4Nzc0NDg4Mzg+ IChERikNCjEwMTI5NDIzMTguMTE1NTAyIGV0aDAgPiB4ZWQuYWNsLmxhbmwu Z292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAxMTcyNzA6 MTE3MzU0KDg0KSBhY2sgNzggd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1w IDg3NzQ0ODg0NSA4NTY5OTU1ND4gKERGKQ0KMTAxMjk0MjMxOC4xMTU1MDIg ZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5s Lmdvdi4yNzA5OiAuIDc4Ojc4KDApIGFjayAxMTczNTQgd2luIDUwNjgwIDxu b3Asbm9wLHRpbWVzdGFtcCA4NTY5OTU1NCA4Nzc0NDg4NDU+IChERikNCjEw MTI5NDIzMTguMTE1NTAyIGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkg PiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAxMTczNTQ6MTE4MDQxKDY4 NykgYWNrIDc4IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDg4 NDUgODU2OTk1NTQ+IChERikNCjEwMTI5NDIzMTguMTE1NTAyIGV0aDAgPCBi bHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcw OTogLiA3ODo3OCgwKSBhY2sgMTE4MDQxIHdpbiA1MDY4MCA8bm9wLG5vcCx0 aW1lc3RhbXAgODU2OTk1NTQgODc3NDQ4ODQ1PiAoREYpDQoxMDEyOTQyMzE4 LjExNTUwMiBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5h Y2wubGFubC5nb3YuMzI3OTA6IFAgMTE4MDQxOjExODA0MigxKSBhY2sgNzgg d2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0ODg0NSA4NTY5OTU1 ND4gKERGKQ0KMTAxMjk0MjMxOC4xMTU1MDIgZXRoMCA8IGJsdWUuYWNsLmxh bmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDc4Ojc4 KDApIGFjayAxMTgwNDIgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4 NTY5OTU1NCA4Nzc0NDg4NDU+IChERikNCjEwMTI5NDIzMTguMTE2NDc5IGV0 aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5n b3YuMjcwOTogUCA3ODo3OSgxKSBhY2sgMTE4MDQyIHdpbiA1MDY4MCA8bm9w LG5vcCx0aW1lc3RhbXAgODU2OTk1NTQgODc3NDQ4ODQ1PiAoREYpDQoxMDEy OTQyMzE4LjExNjQ3OSBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4g Ymx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMTE4MDQyOjExODEyNig4NCkg YWNrIDc5IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDg4NDYg ODU2OTk1NTQ+IChERikNCjEwMTI5NDIzMTguMTQ4NzA3IGV0aDAgPCBibHVl LmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTog LiA3OTo3OSgwKSBhY2sgMTE4MTI2IHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1l c3RhbXAgODU2OTk1NTggODc3NDQ4ODQ2PiAoREYpDQoxMDEyOTQyMzE4LjE0 ODcwNyBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wu bGFubC5nb3YuMzI3OTA6IFAgMTE4MTI2OjExODgwMyg2NzcpIGFjayA3OSB3 aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ4ODc5IDg1Njk5NTU4 PiAoREYpDQoxMDEyOTQyMzE4LjE0ODcwNyBldGgwIDwgYmx1ZS5hY2wubGFu bC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNzk6Nzko MCkgYWNrIDExODgwMyB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1 Njk5NTU4IDg3NzQ0ODg3OT4gKERGKQ0KMTAxMjk0MjMxOC4xNTU1NDQgZXRo MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292 LjMyNzkwOiBQIDExODgwMzoxMTg4ODcoODQpIGFjayA3OSB3aW4gNTc5MiA8 bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ4ODg2IDg1Njk5NTU4PiAoREYpDQox MDEyOTQyMzE4LjE1NTU0NCBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3 OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gNzk6NzkoMCkgYWNrIDEx ODg4NyB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NTU4IDg3 NzQ0ODg4Nj4gKERGKQ0KMTAxMjk0MjMxOC4xNTU1NDQgZXRoMCA+IHhlZC5h Y2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQ IDExODg4NzoxMTkxOTcoMzEwKSBhY2sgNzkgd2luIDU3OTIgPG5vcCxub3As dGltZXN0YW1wIDg3NzQ0ODg4NiA4NTY5OTU1OD4gKERGKQ0KMTAxMjk0MjMx OC4xNTU1NDQgZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVk LmFjbC5sYW5sLmdvdi4yNzA5OiAuIDc5Ojc5KDApIGFjayAxMTkxOTcgd2lu IDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTU1OCA4Nzc0NDg4ODY+ IChERikNCjEwMTI5NDIzMTguMTU1NTQ0IGV0aDAgPiB4ZWQuYWNsLmxhbmwu Z292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAxMTkxOTc6 MTE5NTc1KDM3OCkgYWNrIDc5IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFt cCA4Nzc0NDg4ODYgODU2OTk1NTg+IChERikNCjEwMTI5NDIzMTguMTU2NTIw IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFu bC5nb3YuMjcwOTogLiA3OTo3OSgwKSBhY2sgMTE5NTc1IHdpbiA1MDY4MCA8 bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk1NTggODc3NDQ4ODg2PiAoREYpDQox MDEyOTQyMzE4LjE1NjUyMCBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3 OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IFAgNzk6ODAoMSkgYWNrIDEx OTU3NSB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NTU4IDg3 NzQ0ODg4Nj4gKERGKQ0KMTAxMjk0MjMxOC4xNTY1MjAgZXRoMCA+IHhlZC5h Y2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQ IDExOTU3NToxMTk2NTkoODQpIGFjayA4MCB3aW4gNTc5MiA8bm9wLG5vcCx0 aW1lc3RhbXAgODc3NDQ4ODg3IDg1Njk5NTU4PiAoREYpDQoxMDEyOTQyMzE4 LjE4ODc0OSBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQu YWNsLmxhbmwuZ292LjI3MDk6IC4gODA6ODAoMCkgYWNrIDExOTY1OSB3aW4g NTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NTYyIDg3NzQ0ODg4Nz4g KERGKQ0KMTAxMjk0MjMxOC4xODg3NDkgZXRoMCA+IHhlZC5hY2wubGFubC5n b3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDExOTY1OTox MjAzMzYoNjc3KSBhY2sgODAgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1w IDg3NzQ0ODkyMCA4NTY5OTU2Mj4gKERGKQ0KMTAxMjk0MjMxOC4xODg3NDkg ZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5s Lmdvdi4yNzA5OiAuIDgwOjgwKDApIGFjayAxMjAzMzYgd2luIDUwNjgwIDxu b3Asbm9wLHRpbWVzdGFtcCA4NTY5OTU2MiA4Nzc0NDg5MjA+IChERikNCjEw MTI5NDIzMTguMTk1NTg1IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkg PiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MDogUCAxMjAzMzY6MTIwNDIwKDg0 KSBhY2sgODAgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0ODky NyA4NTY5OTU2Mj4gKERGKQ0KMTAxMjk0MjMxOC4xOTU1ODUgZXRoMCA8IGJs dWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5 OiAuIDgwOjgwKDApIGFjayAxMjA0MjAgd2luIDUwNjgwIDxub3Asbm9wLHRp bWVzdGFtcCA4NTY5OTU2MiA4Nzc0NDg5Mjc+IChERikNCjEwMTI5NDIzMTgu MTk1NTg1IGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFj bC5sYW5sLmdvdi4zMjc5MDogUCAxMjA0MjA6MTIwNzMwKDMxMCkgYWNrIDgw IHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDg5MjcgODU2OTk1 NjI+IChERikNCjEwMTI5NDIzMTguMTk1NTg1IGV0aDAgPCBibHVlLmFjbC5s YW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA4MDo4 MCgwKSBhY2sgMTIwNzMwIHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAg ODU2OTk1NjIgODc3NDQ4OTI3PiAoREYpDQoxMDEyOTQyMzE4LjE5NTU4NSBl dGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5n b3YuMzI3OTA6IFAgMTIwNzMwOjEyMTEwOCgzNzgpIGFjayA4MCB3aW4gNTc5 MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ4OTI3IDg1Njk5NTYyPiAoREYp DQoxMDEyOTQyMzE4LjE5NjU2MiBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3Yu MzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gODA6ODAoMCkgYWNr IDEyMTEwOCB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NTYy IDg3NzQ0ODkyNz4gKERGKQ0KMTAxMjk0MjMxOC4xOTY1NjIgZXRoMCA8IGJs dWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5 OiBQIDgwOjgxKDEpIGFjayAxMjExMDggd2luIDUwNjgwIDxub3Asbm9wLHRp bWVzdGFtcCA4NTY5OTU2MiA4Nzc0NDg5Mjc+IChERikNCjEwMTI5NDIzMTgu MTk2NTYyIGV0aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFj bC5sYW5sLmdvdi4zMjc5MDogUCAxMjExMDg6MTIxMTkyKDg0KSBhY2sgODEg d2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0ODkyOCA4NTY5OTU2 Mj4gKERGKQ0KMTAxMjk0MjMxOC4yMjg3OTAgZXRoMCA8IGJsdWUuYWNsLmxh bmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDgxOjgx KDApIGFjayAxMjExOTIgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4 NTY5OTU2NiA4Nzc0NDg5Mjg+IChERikNCjEwMTI5NDIzMTguMjI4NzkwIGV0 aDAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdv di4zMjc5MDogUCAxMjExOTI6MTIxODY5KDY3NykgYWNrIDgxIHdpbiA1Nzky IDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDg5NjEgODU2OTk1NjY+IChERikN CjEwMTI5NDIzMTguMjI4NzkwIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4z Mjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA4MTo4MSgwKSBhY2sg MTIxODY5IHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk1NjYg ODc3NDQ4OTYxPiAoREYpDQoxMDEyOTQyMzE4LjIzNTYyNiBldGgwID4geGVk LmFjbC5sYW5sLmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6 IFAgMTIxODY5OjEyMTk1Myg4NCkgYWNrIDgxIHdpbiA1NzkyIDxub3Asbm9w LHRpbWVzdGFtcCA4Nzc0NDg5NjggODU2OTk1NjY+IChERikNCjEwMTI5NDIz MTguMjM1NjI2IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhl ZC5hY2wubGFubC5nb3YuMjcwOTogLiA4MTo4MSgwKSBhY2sgMTIxOTUzIHdp biA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk1NjYgODc3NDQ4OTY4 PiAoREYpDQoxMDEyOTQyMzE4LjIzNTYyNiBldGgwID4geGVkLmFjbC5sYW5s Lmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMTIxOTUz OjEyMjI2MygzMTApIGFjayA4MSB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3Rh bXAgODc3NDQ4OTY4IDg1Njk5NTY2PiAoREYpDQoxMDEyOTQyMzE4LjIzNTYy NiBldGgwIDwgYmx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxh bmwuZ292LjI3MDk6IC4gODE6ODEoMCkgYWNrIDEyMjI2MyB3aW4gNTA2ODAg PG5vcCxub3AsdGltZXN0YW1wIDg1Njk5NTY2IDg3NzQ0ODk2OD4gKERGKQ0K MTAxMjk0MjMxOC4yMzU2MjYgZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcw OSA+IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwOiBQIDEyMjI2MzoxMjI2NDEo Mzc4KSBhY2sgODEgd2luIDU3OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0 ODk2OCA4NTY5OTU2Nj4gKERGKQ0KMTAxMjk0MjMxOC4yMzY2MDMgZXRoMCA8 IGJsdWUuYWNsLmxhbmwuZ292LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4y NzA5OiAuIDgxOjgxKDApIGFjayAxMjI2NDEgd2luIDUwNjgwIDxub3Asbm9w LHRpbWVzdGFtcCA4NTY5OTU2NiA4Nzc0NDg5Njg+IChERikNCjEwMTI5NDIz MTguMjM2NjAzIGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhl ZC5hY2wubGFubC5nb3YuMjcwOTogUCA4MTo4MigxKSBhY2sgMTIyNjQxIHdp biA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk1NjYgODc3NDQ4OTY4 PiAoREYpDQoxMDEyOTQyMzE4LjIzNjYwMyBldGgwID4geGVkLmFjbC5sYW5s Lmdvdi4yNzA5ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMTIyNjQx OjEyMjcyNSg4NCkgYWNrIDgyIHdpbiA1NzkyIDxub3Asbm9wLHRpbWVzdGFt cCA4Nzc0NDg5NjkgODU2OTk1NjY+IChERikNCjEwMTI5NDIzMTguMjY4ODMy IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+IHhlZC5hY2wubGFu bC5nb3YuMjcwOTogLiA4Mjo4MigwKSBhY2sgMTIyNzI1IHdpbiA1MDY4MCA8 bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk1NzAgODc3NDQ4OTY5PiAoREYpDQox MDEyOTQyMzE4LjI2ODgzMiBldGgwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5 ID4gYmx1ZS5hY2wubGFubC5nb3YuMzI3OTA6IFAgMTIyNzI1OjEyMzQwMig2 NzcpIGFjayA4MiB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ5 MDAyIDg1Njk5NTcwPiAoREYpDQoxMDEyOTQyMzE4LjI2ODgzMiBldGgwIDwg Ymx1ZS5hY2wubGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3 MDk6IC4gODI6ODIoMCkgYWNrIDEyMzQwMiB3aW4gNTA2ODAgPG5vcCxub3As dGltZXN0YW1wIDg1Njk5NTcwIDg3NzQ0OTAwMj4gKERGKQ0KMTAxMjk0MjMx OC4yNzU2NjggZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUu YWNsLmxhbmwuZ292LjMyNzkwOiBQIDEyMzQwMjoxMjM0ODYoODQpIGFjayA4 MiB3aW4gNTc5MiA8bm9wLG5vcCx0aW1lc3RhbXAgODc3NDQ5MDA5IDg1Njk5 NTcwPiAoREYpDQoxMDEyOTQyMzE4LjI3NTY2OCBldGgwIDwgYmx1ZS5hY2wu bGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IC4gODI6 ODIoMCkgYWNrIDEyMzQ4NiB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1w IDg1Njk5NTcwIDg3NzQ0OTAwOT4gKERGKQ0KMTAxMjk0MjMxOC4yNzU2Njgg ZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwu Z292LjMyNzkwOiBQIDEyMzQ4NjoxMjM3OTYoMzEwKSBhY2sgODIgd2luIDU3 OTIgPG5vcCxub3AsdGltZXN0YW1wIDg3NzQ0OTAwOSA4NTY5OTU3MD4gKERG KQ0KMTAxMjk0MjMxOC4yNzU2NjggZXRoMCA8IGJsdWUuYWNsLmxhbmwuZ292 LjMyNzkwID4geGVkLmFjbC5sYW5sLmdvdi4yNzA5OiAuIDgyOjgyKDApIGFj ayAxMjM3OTYgd2luIDUwNjgwIDxub3Asbm9wLHRpbWVzdGFtcCA4NTY5OTU3 MCA4Nzc0NDkwMDk+IChERikNCjEwMTI5NDIzMTguMjc1NjY4IGV0aDAgPiB4 ZWQuYWNsLmxhbmwuZ292LjI3MDkgPiBibHVlLmFjbC5sYW5sLmdvdi4zMjc5 MDogUCAxMjM3OTY6MTI0MTc0KDM3OCkgYWNrIDgyIHdpbiA1NzkyIDxub3As bm9wLHRpbWVzdGFtcCA4Nzc0NDkwMDkgODU2OTk1NzA+IChERikNCjEwMTI5 NDIzMTguMjc2NjQ1IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4zMjc5MCA+ IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA4Mjo4MigwKSBhY2sgMTI0MTc0 IHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk1NzAgODc3NDQ5 MDA5PiAoREYpDQoxMDEyOTQyMzE4LjI3NjY0NSBldGgwIDwgYmx1ZS5hY2wu bGFubC5nb3YuMzI3OTAgPiB4ZWQuYWNsLmxhbmwuZ292LjI3MDk6IEYgODI6 ODIoMCkgYWNrIDEyNDE3NCB3aW4gNTA2ODAgPG5vcCxub3AsdGltZXN0YW1w IDg1Njk5NTcwIDg3NzQ0OTAwOT4gKERGKQ0KMTAxMjk0MjMxOC4yNzY2NDUg ZXRoMCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOSA+IGJsdWUuYWNsLmxhbmwu Z292LjMyNzkwOiBGIDEyNDE3NDoxMjQxNzQoMCkgYWNrIDgzIHdpbiA1Nzky IDxub3Asbm9wLHRpbWVzdGFtcCA4Nzc0NDkwMTAgODU2OTk1NzA+IChERikN CjEwMTI5NDIzMTguMjc2NjQ1IGV0aDAgPCBibHVlLmFjbC5sYW5sLmdvdi4z Mjc5MCA+IHhlZC5hY2wubGFubC5nb3YuMjcwOTogLiA4Mzo4MygwKSBhY2sg MTI0MTc1IHdpbiA1MDY4MCA8bm9wLG5vcCx0aW1lc3RhbXAgODU2OTk1NzAg ODc3NDQ5MDEwPiAoREYpDQo= ---1518308973-788829135-1012943779=:8565-- From owner-netdev@oss.sgi.com Tue Feb 5 13:42:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15Lgsf15593 for netdev-outgoing; Tue, 5 Feb 2002 13:42:54 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15LgjA15590 for ; Tue, 5 Feb 2002 13:42:45 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 847BE1E809; Tue, 5 Feb 2002 22:42:39 +0100 (MET) Date: Tue, 5 Feb 2002 22:42:34 +0100 From: Andi Kleen To: Ronald G Minnich Cc: Andi Kleen , kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, nivedita@sequent.COM, hendriks@lanl.gov, matt@lanl.gov Subject: Re: your mail Message-ID: <20020205224234.A30931@wotan.suse.de> References: <20020205214910.B17532@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk On Tue, Feb 05, 2002 at 02:16:19PM -0700, Ronald G Minnich wrote: > blue is sending a request to xed for a packet. Supermon (on xed) in turn > sends status requests to several other nodes. Xed formats each "blob" of > data from the other nodes and sends it to blue. The 'S' to supermon > results in one byte of 'S' to the other nodes, and the data comes back > from the other nodes as a large S-expression (in other words the delays > you see in this tcpdump are NOT from the other nodes). > > Here's one cycle. Blue sends 'S' (one byte) to 'xed', and 'xed' is sending > data back. As you can see, in the middle of xed sending lots of data back, > there is this fine ~40 ms. delay. This delay occurs for each transaction > at least once, and limits us to 25 hz. request processing. We also had > this problem before with the 'mon' programs on the nodes but have > developed a workaround, which we will also be applying to supermon. I remember at least one other report of such a spurious delay too. I suspect the problem is not the delayed ack algorithm as is, but the new user context TCP fast path. 2.4 added a somewhat experimental variant of a Van Jacobsen style user context TCP. When the receiver is blocking in recvmsg() the packet is not processed directly in softirq context, but put on a special prequeue and the user process woken up. When the user process schedules it'll run the TCP input path in its process context. If this doesn't work out (process schedules too late), the the delayed ack timer will do the TCP input processing (it's admittedly a bit of a hack) The reason for this is to do csum-copy to user space, but when your NICs do hardware checksumming anyways it shouldn't make much difference. In addition we have an adaptive delayed ack which can make the delay a bit unpredictable. It should probably be shorter. I guess your workload for some reason prevents the fast wakeup of the user context and you frequently run into the timer delayed TCP processing. You can test the theory by turning off the fast path. In net/ipv4/tcp_ipv4.c:tcp_v4_rcv replace if (!sk->lock.users) { if (!tcp_prequeue(sk, skb)) ret = tcp_v4_do_rcv(sk, skb); } else with if (!sk->lock.users) { ret = tcp_v4_do_rcv(sk, skb); } else Does this make the delay go away ? -Andi From owner-netdev@oss.sgi.com Tue Feb 5 14:04:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15M4Oq16300 for netdev-outgoing; Tue, 5 Feb 2002 14:04:24 -0800 Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15M4MA16297 for ; Tue, 5 Feb 2002 14:04:22 -0800 Received: (qmail 1100238 invoked from network); 5 Feb 2002 15:04:21 -0700 Received: from snaresland.acl.lanl.gov (128.165.147.113) by acl.lanl.gov with SMTP; 5 Feb 2002 15:04:21 -0700 Received: (qmail 11018 invoked by uid 3499); 5 Feb 2002 15:04:21 -0700 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 5 Feb 2002 15:04:21 -0700 Date: Tue, 5 Feb 2002 15:04:21 -0700 (MST) From: Ronald G Minnich X-X-Sender: To: cc: , Subject: Andi's patch In-Reply-To: <20020205224234.A30931@wotan.suse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Andi, we'll try to look at your patch as soon as we can. Thanks for confirming the possibility of a problem. Right now we are going to patch supermon first to see if we can work around the problem, since we can't ask everybody to apply that patch. But I would like at some point to see if that's it. thanks again ron From owner-netdev@oss.sgi.com Tue Feb 5 14:08:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15M86216435 for netdev-outgoing; Tue, 5 Feb 2002 14:08:06 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15M83A16426 for ; Tue, 5 Feb 2002 14:08:03 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id D0B411E81E; Tue, 5 Feb 2002 23:07:57 +0100 (MET) Date: Tue, 5 Feb 2002 23:07:57 +0100 From: Andi Kleen To: Ronald G Minnich Cc: netdev@oss.sgi.com, hendriks@lanl.gov, matt@lanl.gov Subject: Re: Andi's patch Message-ID: <20020205230757.A7270@wotan.suse.de> References: <20020205224234.A30931@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk On Tue, Feb 05, 2002 at 03:04:21PM -0700, Ronald G Minnich wrote: > Andi, we'll try to look at your patch as soon as we can. Thanks for > confirming the possibility of a problem. Right now we are going to patch > supermon first to see if we can work around the problem, since we can't > ask everybody to apply that patch. It's not really a proposed patch, but just to confirm that I diagnosed the problem correctly. The eventual goal (if that should be the problem) would be to fix the fast path to work for your workload too. You could also alternatively give supermon realtime priority to let it schedule sooner, make it process user context TCP faster. -Andi From owner-netdev@oss.sgi.com Tue Feb 5 15:19:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15NJHD22531 for netdev-outgoing; Tue, 5 Feb 2002 15:19:17 -0800 Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15NJCA22528 for ; Tue, 5 Feb 2002 15:19:12 -0800 Received: (qmail 1102930 invoked from network); 5 Feb 2002 16:19:11 -0700 Received: from xed.acl.lanl.gov (128.165.147.191) by acl.lanl.gov with SMTP; 5 Feb 2002 16:19:11 -0700 Received: (qmail 31853 invoked by uid 4480); 5 Feb 2002 16:19:11 -0700 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 5 Feb 2002 16:19:11 -0700 Date: Tue, 5 Feb 2002 16:19:11 -0700 (MST) From: Matt Sottile X-X-Sender: To: Ronald G Minnich cc: , , , Subject: Re: your mail In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk > > Such curcumstances just do not exist in the nature. > > As far as you know. You have not seen it so do not believe it. I guess I > have to disagree with you here :-) > > "There are more things in heaven and earth than are dreamt of ..." So now that we've shown that our program does in fact exist, and does lose significant performance due to nastiness in the linux TCP implementation, what does this mean? Since this program exists in our universe, does this mean that we must not exist in order to preserve this pristine, happy-ack universe you're referring to? Seems asking for an example or such would be more productive than simply assuming that a set of programs simply can't exist. Sorry for the mini-flame, but I think responses to potential bugs or performance issues with "that doesn't exist" deserves it... --m From owner-netdev@oss.sgi.com Tue Feb 5 15:46:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15NkOX24904 for netdev-outgoing; Tue, 5 Feb 2002 15:46:24 -0800 Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15Nk9A24899 for ; Tue, 5 Feb 2002 15:46:09 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA121316; Tue, 5 Feb 2002 18:42:57 -0500 Received: from d03nm035.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g15Nk4f206860; Tue, 5 Feb 2002 16:46:04 -0700 From: "Nivedita Singhvi" Importance: Normal Sensitivity: Subject: Re: your mail To: Ronald G Minnich Cc: , , X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Tue, 5 Feb 2002 15:46:01 -0800 X-MIMETrack: Serialize by Router on D03NM035/03/M/IBM(Release 5.0.9 |November 16, 2001) at 02/05/2002 04:46:04 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk It could be that pingpong is biting you because of the occasional write from blue to xed: 1. 1012942315.229586 eth0 < blue.acl.lanl.gov.32790 > xed.acl.lanl.gov.2709: P 2:3(1) ack 1534 win 8931 (DF) blue -> xed: ack 1534 TIME=0 2. 1012942315.230563 eth0 > xed.acl.lanl.gov.2709 > blue.acl.lanl.gov.32790: P 1534:1618(84) ack 3 win 5792 (DF) xed -> blue: send 84 bytes upto 1618 TIME=0.9ms 3. 1012942315.268651 eth0 < blue.acl.lanl.gov.32790 > xed.acl.lanl.gov.2709: . 3:3(0) ack 1618 win 8931 (DF) blue -> xed: ack 1618 TIME=38ms dont have the previous context, but if the ack in 1. caused pingpong to flip, then the next ack should be delayed, which it is. since this ack maxes out the delay, and no data is sent in the opposite direction, pingping state will reverse to sending acks immediately again. 4. 1012942315.268651 eth0 > xed.acl.lanl.gov.2709 > blue.acl.lanl.gov.32790: P 1618:2295(677) ack 3 win 5792 (DF) xed -> blue: send 772 bytes upto 2295 TIME=0 5. 1012942315.268651 eth0 < blue.acl.lanl.gov.32790 > xed.acl.lanl.gov.2709: . 3:3(0) ack 2295 win 10305 (DF) blue -> xed: ack 2295 TIME=0 the ack is not delayed, i'm presuming because pingpong will have reversed again. 6. 1012942315.268651 eth0 > xed.acl.lanl.gov.2709 > blue.acl.lanl.gov.32790: P 2295:3067(772) ack 3 win 5792 (DF) xed -> blue: send 772 bytes upto 3067 TIME=0 7. 1012942315.268651 eth0 < blue.acl.lanl.gov.32790 > xed.acl.lanl.gov.2709: . 3:3(0) ack 3067 win 11580 (DF) blue -> xed: ack 3067 TIME=0 the ack is not delayed because we are back in quickack mode. 8. 1012942315.268651 eth0 < blue.acl.lanl.gov.32790 > xed.acl.lanl.gov.2709: P 3:4(1) ack 3067 win 11580 (DF) blue -> xed: send 1 byte upto 4 TIME=0 this hurts - because the ack wasnt piggybacked and data went in the other direction, so delaying the ack would have helped here. pingpong gets reversed again, so the next time, we should try delaying the ack again. 9. 1012942315.269628 eth0 > xed.acl.lanl.gov.2709 > blue.acl.lanl.gov.32790: P 3067:3151(84) ack 4 win 5792 (DF) xed -> blue: send 84 bytes upto 3151 TIME=0 10. 1012942315.308693 eth0 < blue.acl.lanl.gov.32790 > xed.acl.lanl.gov.2709: . 4:4(0) ack 3151 win 11580 (DF) blue -> xed: ack 3151 TIME=39ms so this time, we delay the ack again. no data going back, however, so its useless again. since the delayed ack timer had to go off, we will reverse pingpong and go back to acking immediately. 11. 1012942315.308693 eth0 > xed.acl.lanl.gov.2709 > blue.acl.lanl.gov.32790: P 3151:3828(677) ack 4 win 5792 (DF) xed -> blue: send 677 bytes upto 3828 TIME=0 12. 1012942315.308693 eth0 < blue.acl.lanl.gov.32790 > xed.acl.lanl.gov.2709: . 4:4(0) ack 3828 win 13124 (DF) blue -> xed: ack 3828 TIME=0 we dont delay the ack therefore. [ snip ] So because the sender side writes are sending only a partial frame at a time, and the receiver never has several frames to be acked which might avoid a delayed ack. The rcvr never sends out data frequently enough for the delayed acks to be effective. This is a worst case toggle of pingpong whenever the receiver does do a write - the next ack will be unnecessarily delayed... If the sender accumulated the writes (sending more than a frame at a time) (or the receiver doesnt delay its acks... thanks, Nivedita From owner-netdev@oss.sgi.com Wed Feb 6 14:30:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16MUSd01564 for netdev-outgoing; Wed, 6 Feb 2002 14:30:28 -0800 Received: from fep01-mail.bloor.is.net.cable.rogers.com (fep01-mail.bloor.is.net.cable.rogers.com [66.185.86.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16MUQA01561 for ; Wed, 6 Feb 2002 14:30:26 -0800 Received: from acm.org ([24.112.72.255]) by fep01-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.04.06 201-253-122-122-106-20020109) with ESMTP id <20020206223020.OSIR18233.fep01-mail.bloor.is.net.cable.rogers.com@acm.org> for ; Wed, 6 Feb 2002 17:30:20 -0500 Message-ID: <3C61B00F.6582EDB5@acm.org> Date: Wed, 06 Feb 2002 17:37:06 -0500 From: Muhammad Jaseemuddin X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: your mail References: <20020205214910.B17532@wotan.suse.de> <20020205224234.A30931@wotan.suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep01-mail.bloor.is.net.cable.rogers.com from [24.112.72.255] using ID at Wed, 6 Feb 2002 17:30:20 -0500 Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi: Is there any card out there that is supporting 802.1p and does linux have device driver for that? I will appreciate your reply. Cheers, - Muhammad Jaseemuddin From owner-netdev@oss.sgi.com Wed Feb 6 15:11:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16NBNB02329 for netdev-outgoing; Wed, 6 Feb 2002 15:11:23 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16NBHA02326 for ; Wed, 6 Feb 2002 15:11:17 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id B69251ECA5 for ; Thu, 7 Feb 2002 00:11:11 +0100 (MET) Date: Thu, 7 Feb 2002 00:11:11 +0100 From: Andi Kleen To: netdev@oss.sgi.com Subject: [PATCH] Fix outgoing MSS computation in 2.4 Message-ID: <20020207001111.A27375@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk 2.4 doesn't subtract the timestamp length from the MSS for outgoing connects. This causes many problems from hosts on a network connection with an MTU < ethernet talking to path mtu blackholed (=behind a firewall that blocks all ICMPs) windows boxes. This patch fixes the problem. -Andi Index: net/ipv4/tcp_output.c =================================================================== RCS file: /cvs/linux/net/ipv4/tcp_output.c,v retrieving revision 1.146 diff -u -u -r1.146 tcp_output.c --- net/ipv4/tcp_output.c 2002/02/01 22:01:04 1.146 +++ net/ipv4/tcp_output.c 2002/02/05 01:13:44 @@ -86,14 +86,15 @@ { struct tcp_opt *tp = tcp_sk(sk); struct dst_entry *dst = __sk_dst_get(sk); - int mss = tp->advmss; - if (dst && dst->advmss < mss) { - mss = dst->advmss; - tp->advmss = mss; + if (dst && dst->advmss < tp->advmss) { + tp->advmss = dst->advmss; } - return (__u16)mss; + if (sysctl_tcp_timestamps) + tp->advmss -= TCPOLEN_TSTAMP_ALIGNED; + + return (__u16)tp->advmss; } /* RFC2861. Reset CWND after idle period longer RTO to "restart window". From owner-netdev@oss.sgi.com Wed Feb 6 17:24:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g171OLl05224 for netdev-outgoing; Wed, 6 Feb 2002 17:24:21 -0800 Received: from amdext.amd.com (amdext.amd.com [139.95.251.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g171OJA05220 for ; Wed, 6 Feb 2002 17:24:19 -0800 Received: from ssvlgs01.amd.com (ssvlgs01.amd.com [139.95.250.16]) by amdext.amd.com (8.9.3/8.9.3/AMD) with SMTP id RAA26081 for ; Wed, 6 Feb 2002 17:24:13 -0800 (PST) From: harish.vasudeva@amd.com Received: from 139.95.250.1 by ssvlgs01.amd.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.7)); Wed, 06 Feb 2002 17:24:11 -0800 X-Server-Uuid: 02753650-11b0-11d5-bbc5-00508bf987eb Received: from caexmta9.amd.com (caexmta9.amd.com [139.95.53.55]) by amdint.amd.com (8.9.3/8.9.3/AMD) with ESMTP id RAA11442 for ; Wed, 6 Feb 2002 17:24:11 -0800 (PST) Received: by caexmta9.amd.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Feb 2002 17:24:10 -0800 Message-ID: To: netdev@oss.sgi.com Subject: Need Info on EthernetDrivers Date: Wed, 6 Feb 2002 17:24:03 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 107F08B12781798-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, does Linux support TCP Segmentation & VLAN tagging for network drivers? If so, where can i get the related docs? thanx HARISH V Enterprise Connectivity Solutions, AMD (408) 749-3324 (Work) * Knowledge becomes wisdom only after it has been put to practical use. * From owner-netdev@oss.sgi.com Wed Feb 6 17:35:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g171ZjC05464 for netdev-outgoing; Wed, 6 Feb 2002 17:35:45 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g171ZeA05460 for ; Wed, 6 Feb 2002 17:35:40 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 8BAA31ECC2 for ; Thu, 7 Feb 2002 02:35:34 +0100 (MET) Date: Thu, 7 Feb 2002 02:35:34 +0100 From: Andi Kleen To: netdev@oss.sgi.com Subject: Re: [PATCH] Fix outgoing MSS computation in 2.4 -- with correct patch Message-ID: <20020207023534.A549@wotan.suse.de> References: <20020207001111.A27375@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020207001111.A27375@wotan.suse.de> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk On Thu, Feb 07, 2002 at 12:11:11AM +0100, Andi Kleen wrote: > > 2.4 doesn't subtract the timestamp length from the MSS for outgoing > connects. This causes many problems from hosts on a network connection > with an MTU < ethernet talking to path mtu blackholed (=behind > a firewall that blocks all ICMPs) windows boxes. > > This patch fixes the problem. Arnaldo pointed out that the patch I sent was against 2.5, not 2.4. Here is the correct patch for 2.4. -Andi --- linux-work/net/ipv4/tcp_output.c-TCPFIX Tue Feb 5 01:24:27 2002 +++ linux-work/net/ipv4/tcp_output.c Tue Feb 5 01:58:39 2002 @@ -86,14 +86,14 @@ { struct tcp_opt *tp = &(sk->tp_pinfo.af_tcp); struct dst_entry *dst = __sk_dst_get(sk); - int mss = tp->advmss; - if (dst && dst->advmss < mss) { - mss = dst->advmss; - tp->advmss = mss; - } + if (dst && dst->advmss < tp->advmss) + tp->advmss = dst->advmss; - return (__u16)mss; + if (sysctl_tcp_timestamps) + tp->advmss -= TCPOLEN_TSTAMP_ALIGNED; + + return (__u16)tp->advmss;; } /* RFC2861. Reset CWND after idle period longer RTO to "restart window". From owner-netdev@oss.sgi.com Thu Feb 7 15:00:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g17N04E08688 for netdev-outgoing; Thu, 7 Feb 2002 15:00:04 -0800 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g17MxwA08650 for ; Thu, 7 Feb 2002 14:59:58 -0800 Received: from marajade.sandelman.ottawa.on.ca ([2002:d8f0:2b4b::20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g17Mxn200592 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Thu, 7 Feb 2002 17:59:54 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.6/8.11.0) with ESMTP id g17MxkH04599 for ; Thu, 7 Feb 2002 17:59:47 -0500 (EST) Message-Id: <200202072259.g17MxkH04599@marajade.sandelman.ottawa.on.ca> To: netdev@oss.sgi.com Subject: PMTU info Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 07 Feb 2002 17:59:45 -0500 From: Michael Richardson Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1046 Lines: 33 -----BEGIN PGP SIGNED MESSAGE----- The FreeSWAN team is debugging some problems with generation of ICMP fragment needed packets. We observe the packets going out, but under some network conditions that we are involved in, they do not reach the destination. In particular, when we generate them addressed to the host that we are on, we can't tcpdump eth0, ipsec0 or lo to see them. So, we are wondering how to determine what the cached PMTU to a particular destination is? We think that /proc/net/rt_cache might have info, but we don't see it. Is there another place that we should look? (BSD systems with PMTU put this into the routing table, so one can see this with netstat -rn.) :!mcr!: -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPGMG34qHRg3pndX9AQGWjQQAnMx6eM3PZvJRjj0bTHFF0r7+pUL6XHGM IA4wfLA4H3ENH/NMcdGQtrmLQWSAUTnEXh649HtbUMq21B/PJSFoUHeLaavTASnt RTg3svkmDnQtzls+K9ylYC2tHRWDjdlu7R56ZakZK/5mtwTwsA+yUAczqAmbVIfL BiTGOKFxVEo= =MdvO -----END PGP SIGNATURE----- From owner-netdev@oss.sgi.com Thu Feb 7 17:12:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g181Cij11192 for netdev-outgoing; Thu, 7 Feb 2002 17:12:44 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g181CfA11186 for ; Thu, 7 Feb 2002 17:12:41 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id EB1FA1E738; Fri, 8 Feb 2002 02:12:35 +0100 (MET) Date: Fri, 8 Feb 2002 02:12:33 +0100 From: Andi Kleen To: Michael Richardson Cc: netdev@oss.sgi.com Subject: Re: PMTU info Message-ID: <20020208021233.A27027@wotan.suse.de> References: <200202072259.g17MxkH04599@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200202072259.g17MxkH04599@marajade.sandelman.ottawa.on.ca> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 334 Lines: 11 On Thu, Feb 07, 2002 at 05:59:45PM -0500, Michael Richardson wrote: > We think that /proc/net/rt_cache might have info, but we don't > see it. Is there another place that we should look? /proc/net/rt_cache has a MTU column. You can also get it via ip route get route --cache unfortunately doesn't show it. -Andi From owner-netdev@oss.sgi.com Fri Feb 8 02:59:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18AxVc27158 for netdev-outgoing; Fri, 8 Feb 2002 02:59:31 -0800 Received: from www.linux.org.uk (IDENT:exim@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18AxTA27155 for ; Fri, 8 Feb 2002 02:59:29 -0800 Received: from [67.33.170.221] (helo=mandrakesoft.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 16Z8kY-0001Af-00; Fri, 08 Feb 2002 10:59:26 +0000 Message-ID: <3C63AF8C.2457B777@mandrakesoft.com> Date: Fri, 08 Feb 2002 05:59:24 -0500 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-pre8 i686) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Morton CC: alex@foogod.com, netdev@oss.sgi.com, Andrey Savochkin Subject: Re: [PATCH] eepro100 and IFF_RUNNING under 2.4 References: <20010720143247.A6596@draco.foogod.com> <3B58E262.29833960@uow.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 198 Lines: 5 Patch applied to 2.4 and 2.5. -- Jeff Garzik | "I went through my candy like hot oatmeal Building 1024 | through an internally-buttered weasel." MandrakeSoft | - goats.com From owner-netdev@oss.sgi.com Sat Feb 9 13:41:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g19Lf1S24757 for netdev-outgoing; Sat, 9 Feb 2002 13:41:01 -0800 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g19LeuA24754 for ; Sat, 9 Feb 2002 13:40:56 -0800 Received: from marajade.sandelman.ottawa.on.ca (HSE-Kingston-ppp193918.sympatico.ca [64.229.11.13]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g19LeeU04107 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Sat, 9 Feb 2002 16:40:53 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.6/8.11.0) with ESMTP id g18Kxb001091; Fri, 8 Feb 2002 15:59:40 -0500 (EST) Message-Id: <200202082059.g18Kxb001091@marajade.sandelman.ottawa.on.ca> To: Andi Kleen cc: netdev@oss.sgi.com Subject: Re: PMTU info In-reply-to: Your message of "Fri, 08 Feb 2002 02:12:33 +0100." <20020208021233.A27027@wotan.suse.de> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 08 Feb 2002 15:59:37 -0500 From: Michael Richardson Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1444 Lines: 39 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Andi" == Andi Kleen writes: Andi> On Thu, Feb 07, 2002 at 05:59:45PM -0500, Michael Richardson wrote: >> We think that /proc/net/rt_cache might have info, but we don't >> see it. Is there another place that we should look? Andi> /proc/net/rt_cache has a MTU column. You can also get it via Andi> ip route get Andi> route --cache unfortunately doesn't show it. Do they expire very quickly? Can we extend it? Is there some debugging we can enable to log the MTU changes? Does it get deleted when the TCP connection gets closed? We did see the MTU column, but we never see something to our specific address. We know that the ICMP is being received, because the packet sizes go down. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPGQ8N4qHRg3pndX9AQHqGAQA3EVAP1shXUayLQ2JS8HMtG0cktC2KKue a9aloKQF+lpodYZoesPArVM/upggF1Gvxoj72ch4psI1ojOvqMvthxyKBIrdacN4 S6Q7A+jNrPWl0h9pXUkbfqrf/ARWmSz/Yk3RxTbt1aQMEII0wSmGpP+PobVJ3nwX 8e9do9fQw9o= =LIP9 -----END PGP SIGNATURE----- From owner-netdev@oss.sgi.com Sat Feb 9 20:04:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1A44q406009 for netdev-outgoing; Sat, 9 Feb 2002 20:04:52 -0800 Received: from www.linux.org.uk (IDENT:exim@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1A44jA06006 for ; Sat, 9 Feb 2002 20:04:45 -0800 Received: from [67.33.159.177] (helo=mandrakesoft.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 16ZlEI-0004lw-00; Sun, 10 Feb 2002 04:04:42 +0000 Message-ID: <3C65F158.12A83BFD@mandrakesoft.com> Date: Sat, 09 Feb 2002 23:04:40 -0500 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-pre8 i686) X-Accept-Language: en MIME-Version: 1.0 To: Linus Torvalds CC: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: [BK PATCHES] eepro100 pci id updates Content-Type: multipart/mixed; boundary="------------C6994543D0C319A63F15B061" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1699 Lines: 55 This is a multi-part message in MIME format. --------------C6994543D0C319A63F15B061 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Linus, Flushed some eepro100 pci id updates out to the net-drivers-2.5 BK tree. Some more changes are landing in this tree in the next few days as I sort through the drivers/net stuff in 2.4, coming in via davej. -- Jeff Garzik | "I went through my candy like hot oatmeal Building 1024 | through an internally-buttered weasel." MandrakeSoft | - goats.com --------------C6994543D0C319A63F15B061 Content-Type: text/plain; charset=us-ascii; name="net-drivers-2.5.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="net-drivers-2.5.txt" Pull from: http://gkernel.bkbits.net/net-drivers-2.5 --------------------------------------------------------------------------- ChangeSet@1.250, 2002-02-09 04:36:24-05:00, jgarzik@rum.normnet.org Add pci ids found in 2.4.18-pre9's version of eepro100 net driver to the current driver. drivers/net/eepro100.c | 4 ++++ 1 files changed, 4 insertions(+) ChangeSet@1.249, 2002-02-09 04:26:59-05:00, jgarzik@rum.normnet.org Update eepro100 net driver pci id list, at the prompting of Andrew Morton and Hanno Boeck. Three constants are substituted with their numeric equivalents, a reverse of the norm, to make the linear progression of PCI ids more clear, and easier to validate at a glance. drivers/net/eepro100.c | 25 ++++++++++--------------- 1 files changed, 10 insertions(+), 15 deletions(-) --------------------------------------------------------------------------- --------------C6994543D0C319A63F15B061-- From owner-netdev@oss.sgi.com Sat Feb 9 22:59:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1A6xdB10742 for netdev-outgoing; Sat, 9 Feb 2002 22:59:39 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1A6xYA10739 for ; Sat, 9 Feb 2002 22:59:35 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 1731C1E67A; Sun, 10 Feb 2002 07:59:29 +0100 (MET) Date: Sun, 10 Feb 2002 07:59:28 +0100 From: Andi Kleen To: Michael Richardson Cc: Andi Kleen , netdev@oss.sgi.com Subject: Re: PMTU info Message-ID: <20020210075928.A22000@wotan.suse.de> References: <20020208021233.A27027@wotan.suse.de> <200202082059.g18Kxb001091@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200202082059.g18Kxb001091@marajade.sandelman.ottawa.on.ca> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 811 Lines: 26 On Fri, Feb 08, 2002 at 03:59:37PM -0500, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Andi" == Andi Kleen writes: > Andi> On Thu, Feb 07, 2002 at 05:59:45PM -0500, Michael Richardson wrote: > >> We think that /proc/net/rt_cache might have info, but we don't > >> see it. Is there another place that we should look? > > Andi> /proc/net/rt_cache has a MTU column. You can also get it via > Andi> ip route get > > Andi> route --cache unfortunately doesn't show it. > > Do they expire very quickly? Can we extend it? Is there some debugging we > can enable to log the MTU changes? Does it get deleted when the TCP > connection gets closed? Depends on your workload. Normally not. Just add a few printks. No. -Ando From owner-netdev@oss.sgi.com Sun Feb 10 09:01:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1AH1DK19634 for netdev-outgoing; Sun, 10 Feb 2002 09:01:13 -0800 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1AH16919610 for ; Sun, 10 Feb 2002 09:01:06 -0800 Received: from marajade.sandelman.ottawa.on.ca ([2002:c08b:2e21:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g1AG13M05702 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sun, 10 Feb 2002 11:01:05 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.6/8.11.0) with ESMTP id g1AG10r00755 for ; Sun, 10 Feb 2002 11:01:03 -0500 (EST) Message-Id: <200202101601.g1AG10r00755@marajade.sandelman.ottawa.on.ca> To: netdev@oss.sgi.com Subject: Re: PMTU info In-reply-to: Your message of "Sun, 10 Feb 2002 07:59:28 +0100." <20020210075928.A22000@wotan.suse.de> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sun, 10 Feb 2002 11:00:59 -0500 From: Michael Richardson Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2102 Lines: 55 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Andi" == Andi Kleen writes: Andi> On Fri, Feb 08, 2002 at 03:59:37PM -0500, Michael Richardson wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> >> >> >>>>> "Andi" == Andi Kleen writes: Andi> On Thu, Feb 07, 2002 at 05:59:45PM -0500, Michael Richardson wrote: >> >> We think that /proc/net/rt_cache might have info, but we don't >> >> see it. Is there another place that we should look? >> Andi> /proc/net/rt_cache has a MTU column. You can also get it via ip Andi> route get >> Andi> route --cache unfortunately doesn't show it. >> Do they expire very quickly? Can we extend it? Is there some debugging >> we can enable to log the MTU changes? Does it get deleted when the TCP >> connection gets closed? Andi> Depends on your workload. Normally not. Is the timeout configurable somewhere? What kind of work would affect our workload. Andi> Just add a few printks. I was considering heading in that direction. Would some printk's and a patch to enable them via some sysctl be welcome? Adding printk's helps for debugging this, but it does not help us do regression tests of non-hacked kernels :-) We use User-Mode-Linux builds such that we can easily capture console output and control ethernet I/O. Having to apply additional patches to the kernel kind of defeats this. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPGaZOoqHRg3pndX9AQGUxQP9HQ7boMUHYaQEk0UGKe+YNhPQBzFWNhUd kmNcswj4bBC/5oWFaedzD0ZNDbkNvi7byQjPN6ZVLI/bYARHbd9OUG7vqUUX5bbp KC1cpuGMo9zYzv9twAGRPJzn7TzBjfhvmwrwstZ+X2lDRr7WCEIbOXkNgvZsJK9V x26xeTtPr5U= =TBvJ -----END PGP SIGNATURE----- From owner-netdev@oss.sgi.com Tue Feb 12 00:06:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1C86lh26078 for netdev-outgoing; Tue, 12 Feb 2002 00:06:47 -0800 Received: from www.linux.org.uk (IDENT:exim@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1C86K926075 for ; Tue, 12 Feb 2002 00:06:22 -0800 Received: from [67.33.122.88] (helo=mandrakesoft.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 16aX15-000297-00; Tue, 12 Feb 2002 07:06:15 +0000 Message-ID: <3C68BEE5.58EDB87E@mandrakesoft.com> Date: Tue, 12 Feb 2002 02:06:13 -0500 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-pre8 i686) X-Accept-Language: en MIME-Version: 1.0 To: Linus Torvalds CC: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: [BK PATCHES] net drivers merge Content-Type: multipart/mixed; boundary="------------A9501BBA804A62489A56EEF8" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 5862 Lines: 188 This is a multi-part message in MIME format. --------------A9501BBA804A62489A56EEF8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Linus, Mainly this is a merge of 2.4.x stuff from Dave Jones and his patchkit. -- Jeff Garzik | "I went through my candy like hot oatmeal Building 1024 | through an internally-buttered weasel." MandrakeSoft | - goats.com --------------A9501BBA804A62489A56EEF8 Content-Type: text/plain; charset=us-ascii; name="net-drivers-2.5.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="net-drivers-2.5.txt" Pull from: http://gkernel.bkbits.net/net-drivers-2.5 --------------------------------------------------------------------------- ChangeSet@1.307, 2002-02-12 01:56:54-05:00, jgarzik@rum.normnet.org Add new pci id to via-rhine net driver. drivers/net/via-rhine.c | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-) ChangeSet@1.306, 2002-02-12 01:43:07-05:00, jgarzik@rum.normnet.org Cleanup and fixes to sleeping/scheduling in the olympic token ring net driver. Also included are a couple of minor error reporting updates and the proper detection for cardbus removal. Contributor: Mike Phillips Linux Token Ring Project drivers/net/tokenring/olympic.c | 161 ++++++++++++++++++++++++++-------------- drivers/net/tokenring/olympic.h | 1 2 files changed, 109 insertions(+), 53 deletions(-) ChangeSet@1.305, 2002-02-12 01:39:21-05:00, jgarzik@rum.normnet.org A minor patch to remove the last isa_read/isa_write function in the ibmtr token ring net driver. Contributor: Mike Phillips Linux Token Ring Project drivers/net/tokenring/ibmtr.c | 33 +++++++++++++++++++++------------ 1 files changed, 21 insertions(+), 12 deletions(-) ChangeSet@1.304, 2002-02-12 01:36:17-05:00, jgarzik@rum.normnet.org Merge changes from yellowfin GigE net driver version LK1.1.6: * Only print warning on truly "oversized" packets * Fix theoretical bug on gigabit cards - return to 1.1.3 behavior Contributor: Val Henson drivers/net/yellowfin.c | 22 ++++++++++++++-------- 1 files changed, 14 insertions(+), 8 deletions(-) ChangeSet@1.303, 2002-02-12 01:29:52-05:00, jgarzik@rum.normnet.org Merge ethtool support and PPC fix into pcnet32 net driver, from 2.4.x. Also, remove deprecated SIOCDEVPRIVATE ioctl calls. Via Dave Jones. drivers/net/Makefile | 2 drivers/net/pcnet32.c | 194 +++++++++++++++++++++++++++++++++++++++++++------- 2 files changed, 168 insertions(+), 28 deletions(-) ChangeSet@1.302, 2002-02-12 01:26:18-05:00, jgarzik@rum.normnet.org Merge ns83820 GigE net driver changes from 2.4.x kernel: 0.13a - optical transceiver support added by Michael Clark 0.13b - call register_netdev earlier in initialization suppress duplicate link status messages 0.15 get ppc (big endian) working Via Dave Jones. drivers/net/ns83820.c | 285 +++++++++++++++++++++++++++++++++++--------------- 1 files changed, 205 insertions(+), 80 deletions(-) ChangeSet@1.301, 2002-02-12 01:24:27-05:00, jgarzik@rum.normnet.org Merge 8139too net driver oops fix from 2.4.x. Fix originally by Andreas Dilger IIRC, merged by Dave Jones. drivers/net/8139too.c | 11 ++++++----- 1 files changed, 6 insertions(+), 5 deletions(-) ChangeSet@1.300, 2002-02-12 01:22:39-05:00, jgarzik@rum.normnet.org Add new ISAPNP card id to 'ne' net driver. Via Dave Jones. drivers/net/ne.c | 3 +++ 1 files changed, 3 insertions(+) ChangeSet@1.299, 2002-02-12 01:21:42-05:00, jgarzik@rum.normnet.org Merge cosmetic cleanup and driver version increment for dmfe net driver from 2.4.x. Via Dave Jones. drivers/net/dmfe.c | 5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) ChangeSet@1.298, 2002-02-12 01:19:38-05:00, jgarzik@rum.normnet.org Fix typo in aironet4500 net driver return value, s/NODEV/-ENODEV/, which prevented the driver from building. Via Dave Jones. drivers/net/aironet4500_core.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) ChangeSet@1.297, 2002-02-12 01:14:40-05:00, jgarzik@rum.normnet.org Merge basic ethtool ioctl support from 2.4.x for 3c505 and sis900 net drivers. Merge two sis900 bug fixes from 2.4.x. Via Dave Jones. drivers/net/3c505.c | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++ drivers/net/sis900.c | 65 ++++++++++++++++++++++++++++++++++++---- 2 files changed, 139 insertions(+), 7 deletions(-) ChangeSet@1.296, 2002-02-12 01:10:04-05:00, jgarzik@rum.normnet.org Remove deprecated SIOCDEVPRIVATE ioctls in net drivers 3c59x, eepro100, sis900, and tulip. Also, update eepro100 Becker URL. Contributor: Dave Jones drivers/net/3c59x.c | 3 --- drivers/net/eepro100.c | 5 +---- drivers/net/sis900.c | 3 --- drivers/net/tulip/tulip_core.c | 3 --- 4 files changed, 1 insertion(+), 13 deletions(-) ChangeSet@1.295, 2002-02-12 01:04:17-05:00, jgarzik@rum.normnet.org request_region cleanups from 2.4 and the kernel janitors. Via Dave Jones. drivers/net/arcnet/com90io.c | 5 ++++- drivers/net/eexpress.c | 1 - drivers/net/sb1000.c | 12 ++++++------ 3 files changed, 10 insertions(+), 8 deletions(-) ChangeSet@1.294, 2002-02-12 01:01:22-05:00, jgarzik@rum.normnet.org Various minor documentation / comment typo fixes for net drivers 3c509, acenic, ni52, and skfp. Via Dave Jones. drivers/net/3c509.c | 2 +- drivers/net/acenic.c | 2 +- drivers/net/ni52.c | 2 +- drivers/net/skfp/h/cmtdef.h | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) --------------------------------------------------------------------------- --------------A9501BBA804A62489A56EEF8-- From owner-netdev@oss.sgi.com Tue Feb 12 18:57:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1D2vGZ32395 for netdev-outgoing; Tue, 12 Feb 2002 18:57:16 -0800 Received: from www.linux.org.uk (IDENT:exim@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1D2vD932392 for ; Tue, 12 Feb 2002 18:57:13 -0800 Received: from [67.33.122.88] (helo=mandrakesoft.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 16aofW-0000B3-00; Wed, 13 Feb 2002 01:57:11 +0000 Message-ID: <3C69C7F5.C196F6BB@mandrakesoft.com> Date: Tue, 12 Feb 2002 20:57:09 -0500 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-pre8 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-net@vger.kernel.org, netdev@oss.sgi.com CC: "David S. Miller" , Alexey Kuznetsov Subject: IFF_PROMISC bug? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 591 Lines: 20 Gentlemen, When I run tcpdump, /sbin/ip shows PROMISC, but /sbin/ifconfig does not. This is on recent RedHat and MDK boxes, at least. Alan Cox also noted that "ifconfig eth0 promisc" causes /sbin/ifconfig to show PROMISC. Somewhere, interface flags are not being propagated/shared correctly? This is on a 2.4 kernel. /sbin/ip uses netlink to get the flags (ifi_flags), and /sbin/ifconfig uses SIOCGIFFLAGS. Jeff -- Jeff Garzik | "I went through my candy like hot oatmeal Building 1024 | through an internally-buttered weasel." MandrakeSoft | - goats.com From owner-netdev@oss.sgi.com Tue Feb 12 21:45:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1D5j4K01078 for netdev-outgoing; Tue, 12 Feb 2002 21:45:04 -0800 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1D5j2901075 for ; Tue, 12 Feb 2002 21:45:02 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id UAA02807; Tue, 12 Feb 2002 20:43:08 -0800 Date: Tue, 12 Feb 2002 20:43:08 -0800 (PST) Message-Id: <20020212.204308.111207103.davem@redhat.com> To: jgarzik@mandrakesoft.com Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: IFF_PROMISC bug? From: "David S. Miller" In-Reply-To: <3C69C7F5.C196F6BB@mandrakesoft.com> References: <3C69C7F5.C196F6BB@mandrakesoft.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 199 Lines: 6 From: Jeff Garzik Date: Tue, 12 Feb 2002 20:57:09 -0500 When I run tcpdump, /sbin/ip shows PROMISC, but /sbin/ifconfig does not. What net driver? (hint hint) From owner-netdev@oss.sgi.com Tue Feb 12 21:55:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1D5t0q01195 for netdev-outgoing; Tue, 12 Feb 2002 21:55:00 -0800 Received: from www.linux.org.uk (IDENT:exim@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1D5sv901186 for ; Tue, 12 Feb 2002 21:54:57 -0800 Received: from [67.33.122.88] (helo=mandrakesoft.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 16arRX-0002tx-00; Wed, 13 Feb 2002 04:54:55 +0000 Message-ID: <3C69F19E.4FF14164@mandrakesoft.com> Date: Tue, 12 Feb 2002 23:54:54 -0500 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-pre8 i686) X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: linux-net@vger.kernel.org, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: IFF_PROMISC bug? References: <3C69C7F5.C196F6BB@mandrakesoft.com> <20020212.204308.111207103.davem@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 784 Lines: 23 "David S. Miller" wrote: > > From: Jeff Garzik > Date: Tue, 12 Feb 2002 20:57:09 -0500 > > When I run tcpdump, /sbin/ip shows PROMISC, but /sbin/ifconfig does not. > > What net driver? (hint hint) All that I've tested so far... sis900, tulip, eepro100, via-rhine immediately. Dunno what Alan Cox is using. tcpdump -does- work, and dmesg -does- contain '...entered promisc' and '...exited promisc'. Since netlink flags and dmesg show promisc mode, and promisc mode works, and SIOCGIFLAGS used to return IFF_PROMISC, I made the assumption that the problem was elsewhere :) -- Jeff Garzik | "I went through my candy like hot oatmeal Building 1024 | through an internally-buttered weasel." MandrakeSoft | - goats.com From owner-netdev@oss.sgi.com Tue Feb 12 22:00:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1D604S01367 for netdev-outgoing; Tue, 12 Feb 2002 22:00:04 -0800 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1D5xx901331 for ; Tue, 12 Feb 2002 21:59:59 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id UAA04289; Tue, 12 Feb 2002 20:58:09 -0800 Date: Tue, 12 Feb 2002 20:58:09 -0800 (PST) Message-Id: <20020212.205809.70219775.davem@redhat.com> To: jgarzik@mandrakesoft.com Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: IFF_PROMISC bug? From: "David S. Miller" In-Reply-To: <3C69F19E.4FF14164@mandrakesoft.com> References: <3C69C7F5.C196F6BB@mandrakesoft.com> <20020212.204308.111207103.davem@redhat.com> <3C69F19E.4FF14164@mandrakesoft.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 770 Lines: 24 From: Jeff Garzik Date: Tue, 12 Feb 2002 23:54:54 -0500 Since netlink flags and dmesg show promisc mode, and promisc mode works, and SIOCGIFLAGS used to return IFF_PROMISC, I made the assumption that the problem was elsewhere :) Can you trace the value of dev->gflags for me through all of these actions? It should contain IFF_PROMISC when set by this bit of code: if ((flags^dev->gflags)&IFF_ALLMULTI) { int inc = (flags&IFF_ALLMULTI) ? +1 : -1; dev->gflags ^= IFF_ALLMULTI; dev_set_allmulti(dev, inc); } in net/core/dev.c:dev_change_flags(), which is the only way dev_set_promiscuity and the dmesg log you see can occur. This code and logic hasn't even changed between 2.2 and 2.4.x in fact. I'm stumped :) From owner-netdev@oss.sgi.com Tue Feb 12 23:19:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1D7Jhk02263 for netdev-outgoing; Tue, 12 Feb 2002 23:19:43 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1D7Jd902260 for ; Tue, 12 Feb 2002 23:19:39 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id DED6A1E26E; Wed, 13 Feb 2002 07:19:33 +0100 (MET) Date: Wed, 13 Feb 2002 07:19:33 +0100 From: Andi Kleen To: "David S. Miller" Cc: jgarzik@mandrakesoft.com, linux-net@vger.kernel.org, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: IFF_PROMISC bug? Message-ID: <20020213071933.A22699@wotan.suse.de> References: <3C69C7F5.C196F6BB@mandrakesoft.com> <20020212.204308.111207103.davem@redhat.com> <3C69F19E.4FF14164@mandrakesoft.com> <20020212.205809.70219775.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020212.205809.70219775.davem@redhat.com> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 862 Lines: 22 On Tue, Feb 12, 2002 at 08:58:09PM -0800, David S. Miller wrote: > From: Jeff Garzik > Date: Tue, 12 Feb 2002 23:54:54 -0500 > > Since netlink flags and dmesg show promisc mode, and promisc mode works, > and SIOCGIFLAGS used to return IFF_PROMISC, I made the assumption that > the problem was elsewhere :) > > Can you trace the value of dev->gflags for me through all of these > actions? It should contain IFF_PROMISC when set by this bit of code: David, it is not a bug, but more a FAQ. Newer libpcap uses the PACKET_ADD_MEMBERSHIP to PACKET_MR_PROMISC socket options. They have an reference count instead of the old broken non ref counted bit. packet calls dev_set_promiscuity directly. Turning on/off the flag virtually when the reference count is >0 would break compatibility so it is not done. -Andi From owner-netdev@oss.sgi.com Tue Feb 12 23:24:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1D7O5E02409 for netdev-outgoing; Tue, 12 Feb 2002 23:24:05 -0800 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1D7O3902406 for ; Tue, 12 Feb 2002 23:24:03 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id WAA16475; Tue, 12 Feb 2002 22:22:10 -0800 Date: Tue, 12 Feb 2002 22:22:09 -0800 (PST) Message-Id: <20020212.222209.02299810.davem@redhat.com> To: ak@suse.de Cc: jgarzik@mandrakesoft.com, linux-net@vger.kernel.org, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: IFF_PROMISC bug? From: "David S. Miller" In-Reply-To: <20020213071933.A22699@wotan.suse.de> References: <3C69F19E.4FF14164@mandrakesoft.com> <20020212.205809.70219775.davem@redhat.com> <20020213071933.A22699@wotan.suse.de> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 332 Lines: 10 From: Andi Kleen Date: Wed, 13 Feb 2002 07:19:33 +0100 Turning on/off the flag virtually when the reference count is >0 would break compatibility so it is not done. Hmmm, I'm surprised this is being noticed now being that it has behaved this way for... something like 4 years, perhaps longer. :-) From owner-netdev@oss.sgi.com Tue Feb 12 23:30:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1D7UuU02547 for netdev-outgoing; Tue, 12 Feb 2002 23:30:56 -0800 Received: from www.linux.org.uk (IDENT:exim@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1D7Up902543 for ; Tue, 12 Feb 2002 23:30:51 -0800 Received: from [67.33.122.88] (helo=mandrakesoft.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 16aswL-00048w-00; Wed, 13 Feb 2002 06:30:49 +0000 Message-ID: <3C6A0817.B50EFC74@mandrakesoft.com> Date: Wed, 13 Feb 2002 01:30:47 -0500 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-pre8 i686) X-Accept-Language: en MIME-Version: 1.0 To: Andi Kleen CC: "David S. Miller" , linux-net@vger.kernel.org, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: IFF_PROMISC bug? References: <3C69C7F5.C196F6BB@mandrakesoft.com> <20020212.204308.111207103.davem@redhat.com> <3C69F19E.4FF14164@mandrakesoft.com> <20020212.205809.70219775.davem@redhat.com> <20020213071933.A22699@wotan.suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1539 Lines: 41 Andi Kleen wrote: > > On Tue, Feb 12, 2002 at 08:58:09PM -0800, David S. Miller wrote: > > From: Jeff Garzik > > Date: Tue, 12 Feb 2002 23:54:54 -0500 > > > > Since netlink flags and dmesg show promisc mode, and promisc mode works, > > and SIOCGIFLAGS used to return IFF_PROMISC, I made the assumption that > > the problem was elsewhere :) > > > > Can you trace the value of dev->gflags for me through all of these > > actions? It should contain IFF_PROMISC when set by this bit of code: > > David, it is not a bug, but more a FAQ. > > Newer libpcap uses the PACKET_ADD_MEMBERSHIP to PACKET_MR_PROMISC socket > options. They have an reference count instead of > the old broken non ref counted bit. packet calls dev_set_promiscuity directly. > > Turning on/off the flag virtually when the reference count is >0 would > break compatibility so it is not done. Net stack should not call net driver to enable promisc when it is already enabled, or disable promisc when it is already disabled, agreed? Further, we have a lock guaranteeing that dev->set_multicast_list call atomicity. Given that there is a clear point when promisc is enabled or disabled, I do not see why IFF_PROMISC cannot be managed properly. Please help me understand the compatibility issues that prevent this, given what I've just described... Jeff -- Jeff Garzik | "I went through my candy like hot oatmeal Building 1024 | through an internally-buttered weasel." MandrakeSoft | - goats.com From owner-netdev@oss.sgi.com Tue Feb 12 23:41:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1D7fOK02684 for netdev-outgoing; Tue, 12 Feb 2002 23:41:24 -0800 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1D7fM902680 for ; Tue, 12 Feb 2002 23:41:22 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id WAA19190; Tue, 12 Feb 2002 22:39:29 -0800 Date: Tue, 12 Feb 2002 22:39:29 -0800 (PST) Message-Id: <20020212.223929.66060180.davem@redhat.com> To: jgarzik@mandrakesoft.com Cc: ak@suse.de, linux-net@vger.kernel.org, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: IFF_PROMISC bug? From: "David S. Miller" In-Reply-To: <3C6A0817.B50EFC74@mandrakesoft.com> References: <20020212.205809.70219775.davem@redhat.com> <20020213071933.A22699@wotan.suse.de> <3C6A0817.B50EFC74@mandrakesoft.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 347 Lines: 9 From: Jeff Garzik Date: Wed, 13 Feb 2002 01:30:47 -0500 Please help me understand the compatibility issues that prevent this, given what I've just described... What if you have a "promisc" count of 4, and SIOCSIFFLAGS asks to turn IFF_PROMISC off? There is no logical way to perform such an operation. From owner-netdev@oss.sgi.com Tue Feb 12 23:46:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1D7kGa02816 for netdev-outgoing; Tue, 12 Feb 2002 23:46:16 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1D7kA902808 for ; Tue, 12 Feb 2002 23:46:10 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id EF6C41E3C8; Wed, 13 Feb 2002 07:46:04 +0100 (MET) Date: Wed, 13 Feb 2002 07:46:04 +0100 From: Andi Kleen To: Jeff Garzik Cc: Andi Kleen , "David S. Miller" , linux-net@vger.kernel.org, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: IFF_PROMISC bug? Message-ID: <20020213074604.A24375@wotan.suse.de> References: <3C69C7F5.C196F6BB@mandrakesoft.com> <20020212.204308.111207103.davem@redhat.com> <3C69F19E.4FF14164@mandrakesoft.com> <20020212.205809.70219775.davem@redhat.com> <20020213071933.A22699@wotan.suse.de> <3C6A0817.B50EFC74@mandrakesoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C6A0817.B50EFC74@mandrakesoft.com> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2178 Lines: 50 On Wed, Feb 13, 2002 at 01:30:47AM -0500, Jeff Garzik wrote: > Andi Kleen wrote: > > > > On Tue, Feb 12, 2002 at 08:58:09PM -0800, David S. Miller wrote: > > > From: Jeff Garzik > > > Date: Tue, 12 Feb 2002 23:54:54 -0500 > > > > > > Since netlink flags and dmesg show promisc mode, and promisc mode works, > > > and SIOCGIFLAGS used to return IFF_PROMISC, I made the assumption that > > > the problem was elsewhere :) > > > > > > Can you trace the value of dev->gflags for me through all of these > > > actions? It should contain IFF_PROMISC when set by this bit of code: > > > > David, it is not a bug, but more a FAQ. > > > > Newer libpcap uses the PACKET_ADD_MEMBERSHIP to PACKET_MR_PROMISC socket > > options. They have an reference count instead of > > the old broken non ref counted bit. packet calls dev_set_promiscuity directly. > > > > Turning on/off the flag virtually when the reference count is >0 would > > break compatibility so it is not done. > > Net stack should not call net driver to enable promisc when it is > already enabled, or disable promisc when it is already disabled, agreed? > Further, we have a lock guaranteeing that dev->set_multicast_list call > atomicity. > > Given that there is a clear point when promisc is enabled or disabled, I > do not see why IFF_PROMISC cannot be managed properly. > > Please help me understand the compatibility issues that prevent this, > given what I've just described... The issue is not on the driver level interface, but on the user API. The problem is that there are two incompatible user interfaces. One is essentially a reference count (PACKET_ADD_MEMBERSHIP/PACKET_DROP_MEMBERSHIP). The other is a single bit in a bitmask that was managed by saving the old state and resetting it on program exit (via SIOG[CS]IFFLAGS). Mapping the single bit toggling properly to the reference count doesn't work especially when the bit is modified so it is not tried. What ifconfig could do is to check the reference count and tell the user that the interface is in promisc mode anyways. Problem is just that the reference count is not user visible currently. -Andi From owner-netdev@oss.sgi.com Tue Feb 12 23:49:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1D7nkP02930 for netdev-outgoing; Tue, 12 Feb 2002 23:49:46 -0800 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1D7ni902927 for ; Tue, 12 Feb 2002 23:49:44 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id WAA19832; Tue, 12 Feb 2002 22:47:51 -0800 Date: Tue, 12 Feb 2002 22:47:50 -0800 (PST) Message-Id: <20020212.224750.106435646.davem@redhat.com> To: ak@suse.de Cc: jgarzik@mandrakesoft.com, linux-net@vger.kernel.org, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: IFF_PROMISC bug? From: "David S. Miller" In-Reply-To: <20020213074604.A24375@wotan.suse.de> References: <20020213071933.A22699@wotan.suse.de> <3C6A0817.B50EFC74@mandrakesoft.com> <20020213074604.A24375@wotan.suse.de> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 458 Lines: 10 From: Andi Kleen Date: Wed, 13 Feb 2002 07:46:04 +0100 What ifconfig could do is to check the reference count and tell the user that the interface is in promisc mode anyways. Problem is just that the reference count is not user visible currently. I definitely think, if there is any change, it does belong in ifconfig. In fact it should report it as "IFF_PROMISC(%d)" so that it is explicit that this is not a binary state. From owner-netdev@oss.sgi.com Wed Feb 13 00:01:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1D81IF03218 for netdev-outgoing; Wed, 13 Feb 2002 00:01:18 -0800 Received: from www.linux.org.uk (IDENT:exim@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1D81D903215 for ; Wed, 13 Feb 2002 00:01:13 -0800 Received: from [67.33.122.88] (helo=mandrakesoft.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 16atPf-0004QD-00; Wed, 13 Feb 2002 07:01:08 +0000 Message-ID: <3C6A0F32.DE282B67@mandrakesoft.com> Date: Wed, 13 Feb 2002 02:01:06 -0500 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-pre8 i686) X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: ak@suse.de, linux-net@vger.kernel.org, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: IFF_PROMISC bug? References: <20020212.205809.70219775.davem@redhat.com> <20020213071933.A22699@wotan.suse.de> <3C6A0817.B50EFC74@mandrakesoft.com> <20020212.223929.66060180.davem@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1301 Lines: 39 "David S. Miller" wrote: > > From: Jeff Garzik > Date: Wed, 13 Feb 2002 01:30:47 -0500 > > Please help me understand the compatibility issues that prevent this, > given what I've just described... > > What if you have a "promisc" count of 4, and SIOCSIFFLAGS asks to turn > IFF_PROMISC off? There is no logical way to perform such an > operation. Agreed. Why must that affect SIOCGIFFLAGS reporting? This is standard interface stuff, operation 'get' returns present state, operation 'set' updates present state, if possible and allowed. Whether ifconfig should be updated is a tangent issue (though a good suggestion IMHO, David). [further tangent, 'ifconfig eth0 promisc' may follow a buggy code path?] I still want to support IFF_PROMISC in SIOCGIFFLAGS because it is clearly possible given the net driver API if nothing else, because it broke a security program that called that ioctl to check for unwanted promisc users[1], and because it might break other security-related programs and scripts. Sound OK? Regards, Jeff [1] i.e. the bug report that led me to this subject -- Jeff Garzik | "I went through my candy like hot oatmeal Building 1024 | through an internally-buttered weasel." MandrakeSoft | - goats.com From owner-netdev@oss.sgi.com Wed Feb 13 00:45:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1D8jDq03821 for netdev-outgoing; Wed, 13 Feb 2002 00:45:13 -0800 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1D8j9903818 for ; Wed, 13 Feb 2002 00:45:09 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id XAA01078; Tue, 12 Feb 2002 23:43:25 -0800 Date: Tue, 12 Feb 2002 23:43:25 -0800 (PST) Message-Id: <20020212.234325.59465194.davem@redhat.com> To: jgarzik@mandrakesoft.com Cc: ak@suse.de, linux-net@vger.kernel.org, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: IFF_PROMISC bug? From: "David S. Miller" In-Reply-To: <3C6A0F32.DE282B67@mandrakesoft.com> References: <3C6A0817.B50EFC74@mandrakesoft.com> <20020212.223929.66060180.davem@redhat.com> <3C6A0F32.DE282B67@mandrakesoft.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 888 Lines: 27 From: Jeff Garzik Date: Wed, 13 Feb 2002 02:01:06 -0500 Why must that affect SIOCGIFFLAGS reporting? Because it is asking for a boolean and we don't have a boolean to give to it. Like I said, apps should ask for the count because that is what it is, a count. it broke a security program that called that ioctl to check for unwanted promisc users A program which should also be fixed to ask for the count. I know what you want, you want IFF_PROMISC to be (dev->promisc_count != 0), but I'm not going to publish that from SIOCGIFFLAGS for several reasons: 1) It has lousy semantics, in short it's stupid. 2) If I fix change this behavior today, people will still need to ask explicitly for the count to handle any kernel before 2.4.19preX/2.2.2X-preX/2.5.5-preX So be realistic, there is nothing to gain by the change you propose. From owner-netdev@oss.sgi.com Wed Feb 13 01:08:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1D98W704235 for netdev-outgoing; Wed, 13 Feb 2002 01:08:32 -0800 Received: from www.linux.org.uk (IDENT:exim@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1D98O904232 for ; Wed, 13 Feb 2002 01:08:24 -0800 Received: from [67.33.122.88] (helo=mandrakesoft.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 16auSk-0005KM-00; Wed, 13 Feb 2002 08:08:22 +0000 Message-ID: <3C6A1EF5.1BF97B99@mandrakesoft.com> Date: Wed, 13 Feb 2002 03:08:21 -0500 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-pre8 i686) X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: ak@suse.de, linux-net@vger.kernel.org, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: IFF_PROMISC bug? References: <3C6A0817.B50EFC74@mandrakesoft.com> <20020212.223929.66060180.davem@redhat.com> <3C6A0F32.DE282B67@mandrakesoft.com> <20020212.234325.59465194.davem@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2046 Lines: 60 "David S. Miller" wrote: > > From: Jeff Garzik > Date: Wed, 13 Feb 2002 02:01:06 -0500 > > Why must that affect SIOCGIFFLAGS reporting? > > Because it is asking for a boolean and we don't have > a boolean to give to it. > > Like I said, apps should ask for the count because that > is what it is, a count. > > it broke a security program that called that ioctl to check for unwanted > promisc users > > A program which should also be fixed to ask for the count. > > I know what you want, you want IFF_PROMISC to be > (dev->promisc_count != 0), but I'm not going to publish > that from SIOCGIFFLAGS for several reasons: > > 1) It has lousy semantics, in short it's stupid. Wrong - NIC promisc state is binary. The semantics are that it reports the true state of the hardware. It's an implementation detail that it is reference counted. And it's perfectly logical to ask if a NIC is in promisc mode or not, both IFF_PROMISC semantics and NIC promisc bit are binary in nature. > 2) If I fix change this behavior today, people will > still need to ask explicitly for the count to handle > any kernel before 2.4.19preX/2.2.2X-preX/2.5.5-preX > > So be realistic, there is nothing to gain by the change > you propose. That little weird thing called binary compatibility. It is possible to support IFF_PROMISC until the end of time, because the NIC promisc bit is similarly binary. The change I propose is to regain what we have already lost. C'est la vie. I've said my peace, let's move on. Can we at least return -EOPNOTSUPPORTED, please? Otherwise you have the current situation: random binaries breaking when you run them under 2.2.x versus 2.4.x. Further, would you object to an ethtool command which returns the NIC's RX mode bits: promisc, all-multi, hash-filter or perfect match, broadcast, etc.? Jeff -- Jeff Garzik | "I went through my candy like hot oatmeal Building 1024 | through an internally-buttered weasel." MandrakeSoft | - goats.com From owner-netdev@oss.sgi.com Wed Feb 13 01:09:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1D99ep04295 for netdev-outgoing; Wed, 13 Feb 2002 01:09:40 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1D99c904287 for ; Wed, 13 Feb 2002 01:09:38 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id F1A4E1E441; Wed, 13 Feb 2002 09:09:32 +0100 (MET) Date: Wed, 13 Feb 2002 09:09:32 +0100 From: Andi Kleen To: Jeff Garzik Cc: "David S. Miller" , ak@suse.de, linux-net@vger.kernel.org, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: IFF_PROMISC bug? Message-ID: <20020213090932.A7398@wotan.suse.de> References: <3C6A0817.B50EFC74@mandrakesoft.com> <20020212.223929.66060180.davem@redhat.com> <3C6A0F32.DE282B67@mandrakesoft.com> <20020212.234325.59465194.davem@redhat.com> <3C6A1EF5.1BF97B99@mandrakesoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C6A1EF5.1BF97B99@mandrakesoft.com> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 289 Lines: 9 On Wed, Feb 13, 2002 at 03:08:21AM -0500, Jeff Garzik wrote: > Can we at least return -EOPNOTSUPPORTED, please? Otherwise you have the > current situation: random binaries breaking when you run them under > 2.2.x versus 2.4.x. 2.2 behaved the same way. Only 2.0 did differently. -Andi From owner-netdev@oss.sgi.com Wed Feb 13 01:15:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1D9F2S04502 for netdev-outgoing; Wed, 13 Feb 2002 01:15:02 -0800 Received: from www.linux.org.uk (IDENT:exim@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1D9Ev904484 for ; Wed, 13 Feb 2002 01:14:58 -0800 Received: from [67.33.122.88] (helo=mandrakesoft.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 16auZ6-0005Ox-00; Wed, 13 Feb 2002 08:14:56 +0000 Message-ID: <3C6A207F.3590B8ED@mandrakesoft.com> Date: Wed, 13 Feb 2002 03:14:55 -0500 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-pre8 i686) X-Accept-Language: en MIME-Version: 1.0 To: Andi Kleen CC: "David S. Miller" , linux-net@vger.kernel.org, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: IFF_PROMISC bug? References: <3C6A0817.B50EFC74@mandrakesoft.com> <20020212.223929.66060180.davem@redhat.com> <3C6A0F32.DE282B67@mandrakesoft.com> <20020212.234325.59465194.davem@redhat.com> <3C6A1EF5.1BF97B99@mandrakesoft.com> <20020213090932.A7398@wotan.suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 836 Lines: 26 Andi Kleen wrote: > > On Wed, Feb 13, 2002 at 03:08:21AM -0500, Jeff Garzik wrote: > > Can we at least return -EOPNOTSUPPORTED, please? Otherwise you have the > > current situation: random binaries breaking when you run them under > > 2.2.x versus 2.4.x. > > 2.2 behaved the same way. Only 2.0 did differently. Sorry, that is not what I see with my own testing, and bug reports. Under 2.2, IFF_PROMISC flag appears and disappears correctly in /sbin/ifconfig. Under 2.4, it does not. I did not test 2.0. This behavior likewise affects libpcap 0.6.2 (most people have not upgraded to libpcap 0.7, so I'm told, due to at least a couple bugs in libpcap) Jeff -- Jeff Garzik | "I went through my candy like hot oatmeal Building 1024 | through an internally-buttered weasel." MandrakeSoft | - goats.com From owner-netdev@oss.sgi.com Wed Feb 13 01:19:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1D9JMf04619 for netdev-outgoing; Wed, 13 Feb 2002 01:19:22 -0800 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1D9JJ904616 for ; Wed, 13 Feb 2002 01:19:20 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id AAA01737; Wed, 13 Feb 2002 00:17:36 -0800 Date: Wed, 13 Feb 2002 00:17:36 -0800 (PST) Message-Id: <20020213.001736.03366378.davem@redhat.com> To: jgarzik@mandrakesoft.com Cc: ak@suse.de, linux-net@vger.kernel.org, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: IFF_PROMISC bug? From: "David S. Miller" In-Reply-To: <3C6A1EF5.1BF97B99@mandrakesoft.com> References: <3C6A0F32.DE282B67@mandrakesoft.com> <20020212.234325.59465194.davem@redhat.com> <3C6A1EF5.1BF97B99@mandrakesoft.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 804 Lines: 19 From: Jeff Garzik Date: Wed, 13 Feb 2002 03:08:21 -0500 That little weird thing called binary compatibility. It is possible to support IFF_PROMISC until the end of time, because the NIC promisc bit is similarly binary. The change I propose is to regain what we have already lost. (note: we "lost" this 5 years ago, and nobody has cared all this time, keep that in mind :-) How do we handle SIOCSIFFLAGS then? Do we just cancel out all the counts if we are asked to clear the IFF_PROMISC bit? That is definitely wrong, it blows away the entire intention of having a count in the first place. Or do we make it act as a "decrement 1 count"? That sounds equally lousy to me. We can't just ignore the request by your very arguments. Right? From owner-netdev@oss.sgi.com Wed Feb 13 01:20:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1D9KWW04724 for netdev-outgoing; Wed, 13 Feb 2002 01:20:32 -0800 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1D9KU904721 for ; Wed, 13 Feb 2002 01:20:30 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id AAA01746; Wed, 13 Feb 2002 00:18:47 -0800 Date: Wed, 13 Feb 2002 00:18:46 -0800 (PST) Message-Id: <20020213.001846.21955544.davem@redhat.com> To: ak@suse.de Cc: jgarzik@mandrakesoft.com, linux-net@vger.kernel.org, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: IFF_PROMISC bug? From: "David S. Miller" In-Reply-To: <20020213090932.A7398@wotan.suse.de> References: <20020212.234325.59465194.davem@redhat.com> <3C6A1EF5.1BF97B99@mandrakesoft.com> <20020213090932.A7398@wotan.suse.de> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 506 Lines: 14 From: Andi Kleen Date: Wed, 13 Feb 2002 09:09:32 +0100 On Wed, Feb 13, 2002 at 03:08:21AM -0500, Jeff Garzik wrote: > Can we at least return -EOPNOTSUPPORTED, please? Otherwise you have the > current situation: random binaries breaking when you run them under > 2.2.x versus 2.4.x. 2.2 behaved the same way. Only 2.0 did differently. Keep this in mind Jeff, in any arguments you make. This didn't happen yesterday, or even 2 years ago, it happened 5 years ago. From owner-netdev@oss.sgi.com Wed Feb 13 01:21:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1D9LZ004823 for netdev-outgoing; Wed, 13 Feb 2002 01:21:35 -0800 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1D9LX904820 for ; Wed, 13 Feb 2002 01:21:33 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id AAA01773; Wed, 13 Feb 2002 00:19:49 -0800 Date: Wed, 13 Feb 2002 00:19:48 -0800 (PST) Message-Id: <20020213.001948.112622987.davem@redhat.com> To: jgarzik@mandrakesoft.com Cc: ak@suse.de, linux-net@vger.kernel.org, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: IFF_PROMISC bug? From: "David S. Miller" In-Reply-To: <3C6A207F.3590B8ED@mandrakesoft.com> References: <3C6A1EF5.1BF97B99@mandrakesoft.com> <20020213090932.A7398@wotan.suse.de> <3C6A207F.3590B8ED@mandrakesoft.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 367 Lines: 10 From: Jeff Garzik Date: Wed, 13 Feb 2002 03:14:55 -0500 Under 2.2, IFF_PROMISC flag appears and disappears correctly in /sbin/ifconfig. Under 2.4, it does not. I did not test 2.0. Go look at the code Jeff, the logic is identical. Something else in your 2.2.x setup is making libpcap not use the counter promisc setting. From owner-netdev@oss.sgi.com Wed Feb 13 01:22:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1D9MnL04913 for netdev-outgoing; Wed, 13 Feb 2002 01:22:49 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1D9Mk904908 for ; Wed, 13 Feb 2002 01:22:46 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id E120B1E49C; Wed, 13 Feb 2002 09:22:40 +0100 (MET) Date: Wed, 13 Feb 2002 09:22:40 +0100 From: Andi Kleen To: Jeff Garzik Cc: Andi Kleen , "David S. Miller" , linux-net@vger.kernel.org, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: IFF_PROMISC bug? Message-ID: <20020213092240.A10264@wotan.suse.de> References: <3C6A0817.B50EFC74@mandrakesoft.com> <20020212.223929.66060180.davem@redhat.com> <3C6A0F32.DE282B67@mandrakesoft.com> <20020212.234325.59465194.davem@redhat.com> <3C6A1EF5.1BF97B99@mandrakesoft.com> <20020213090932.A7398@wotan.suse.de> <3C6A207F.3590B8ED@mandrakesoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C6A207F.3590B8ED@mandrakesoft.com> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 660 Lines: 18 On Wed, Feb 13, 2002 at 03:14:55AM -0500, Jeff Garzik wrote: > Andi Kleen wrote: > > > > On Wed, Feb 13, 2002 at 03:08:21AM -0500, Jeff Garzik wrote: > > > Can we at least return -EOPNOTSUPPORTED, please? Otherwise you have the > > > current situation: random binaries breaking when you run them under > > > 2.2.x versus 2.4.x. > > > > 2.2 behaved the same way. Only 2.0 did differently. > > Sorry, that is not what I see with my own testing, and bug reports. > > Under 2.2, IFF_PROMISC flag appears and disappears correctly in > /sbin/ifconfig. Under 2.4, it does not. I did not test 2.0. Did you use the same tcpdump/libpcap in 2.2 and 2.4 ? -Andi From owner-netdev@oss.sgi.com Wed Feb 13 01:33:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1D9XnR05107 for netdev-outgoing; Wed, 13 Feb 2002 01:33:49 -0800 Received: from www.linux.org.uk (IDENT:exim@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1D9Xj905104 for ; Wed, 13 Feb 2002 01:33:45 -0800 Received: from [67.33.122.88] (helo=mandrakesoft.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 16aurH-0005io-00; Wed, 13 Feb 2002 08:33:43 +0000 Message-ID: <3C6A24E5.B04D41F4@mandrakesoft.com> Date: Wed, 13 Feb 2002 03:33:41 -0500 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-pre8 i686) X-Accept-Language: en MIME-Version: 1.0 To: Andi Kleen CC: "David S. Miller" , linux-net@vger.kernel.org, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: IFF_PROMISC bug? References: <3C6A0817.B50EFC74@mandrakesoft.com> <20020212.223929.66060180.davem@redhat.com> <3C6A0F32.DE282B67@mandrakesoft.com> <20020212.234325.59465194.davem@redhat.com> <3C6A1EF5.1BF97B99@mandrakesoft.com> <20020213090932.A7398@wotan.suse.de> <3C6A207F.3590B8ED@mandrakesoft.com> <20020213092240.A10264@wotan.suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 832 Lines: 31 Andi Kleen wrote: > Did you use the same tcpdump/libpcap in 2.2 and 2.4 ? Yes. To separate out other bug reports and mentions, here is my own test environment: 2.2.20 MDK kernel, or 2.2.21-pre2 custom kernel, or 2.4.18-preX MDK kernel, or 2.4.18-preX custom kernel net-tools 1.60 iproute2 2.2.4 libpcap 0.6.2 tcpdump 3.6.2 glibc 2.2.4 + bug fixes from 2.2.5 (MDK glibc) So, same userland for 2.2 and 2.4. When I boot into 2.2 MDK or custom kernel, SIOCGIFFLAGS indicates IFF_PROMISC when tcpdump is running. When I boot into 2.4 MDK or custom kernel, SIOCGIFFLAGS does not indicate IFF_PROMISC under the same conditions. Thems the facts, gentlemen :) -- Jeff Garzik | "I went through my candy like hot oatmeal Building 1024 | through an internally-buttered weasel." MandrakeSoft | - goats.com From owner-netdev@oss.sgi.com Wed Feb 13 01:45:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1D9j6Y05302 for netdev-outgoing; Wed, 13 Feb 2002 01:45:06 -0800 Received: from www.linux.org.uk (IDENT:exim@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1D9j0905289 for ; Wed, 13 Feb 2002 01:45:00 -0800 Received: from [67.33.122.88] (helo=mandrakesoft.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 16av2A-00060l-00; Wed, 13 Feb 2002 08:44:58 +0000 Message-ID: <3C6A2789.5DCC1C8F@mandrakesoft.com> Date: Wed, 13 Feb 2002 03:44:57 -0500 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-pre8 i686) X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: ak@suse.de, linux-net@vger.kernel.org, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: IFF_PROMISC bug? References: <3C6A0F32.DE282B67@mandrakesoft.com> <20020212.234325.59465194.davem@redhat.com> <3C6A1EF5.1BF97B99@mandrakesoft.com> <20020213.001736.03366378.davem@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1573 Lines: 39 "David S. Miller" wrote: > That little weird thing called binary compatibility. It is possible to > support IFF_PROMISC until the end of time, because the NIC promisc bit > is similarly binary. The change I propose is to regain what we have > already lost. [sigh, I meant to have said that we can support IFF_PROMISC for SIOCGIFFLAGS -only-, until the end of time. I agree with you that SIOCSIFFLAGS+IFF_PROMISC clearly is unsupportable.] > How do we handle SIOCSIFFLAGS then? > > Do we just cancel out all the counts if we are asked to clear the > IFF_PROMISC bit? That is definitely wrong, it blows away the entire > intention of having a count in the first place. Or do we make it act > as a "decrement 1 count"? That sounds equally lousy to me. > > We can't just ignore the request by your very arguments. Right? Correct. First, a question. Is SIOCSIFFLAGS to be 100% deprecated, or just the twiddling of IFF_PROMISC bit? My preferred way would be to return -EOPNOTSUPP for SIOCSIFFLAGS. The cases for which this is returned is dependent on the answer to the question I just asked. For SIOCGIFFLAGS, my preference would be to manage the IFF_PROMISC bit at a lower level than the reference count, at the time when promisc is actually enabled or disabled. Thus IFF_PROMISC will reflect the true state of the hardware, while also maintaining binary compatibility. Jeff -- Jeff Garzik | "I went through my candy like hot oatmeal Building 1024 | through an internally-buttered weasel." MandrakeSoft | - goats.com From owner-netdev@oss.sgi.com Wed Feb 13 02:01:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1DA1Mo06705 for netdev-outgoing; Wed, 13 Feb 2002 02:01:22 -0800 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1DA1J906702 for ; Wed, 13 Feb 2002 02:01:19 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id AAA02226; Wed, 13 Feb 2002 00:43:47 -0800 Date: Wed, 13 Feb 2002 00:43:47 -0800 (PST) Message-Id: <20020213.004347.39153382.davem@redhat.com> To: jgarzik@mandrakesoft.com Cc: ak@suse.de, linux-net@vger.kernel.org, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: IFF_PROMISC bug? From: "David S. Miller" In-Reply-To: <3C6A24E5.B04D41F4@mandrakesoft.com> References: <3C6A207F.3590B8ED@mandrakesoft.com> <20020213092240.A10264@wotan.suse.de> <3C6A24E5.B04D41F4@mandrakesoft.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 688 Lines: 18 From: Jeff Garzik Date: Wed, 13 Feb 2002 03:33:41 -0500 When I boot into 2.2 MDK or custom kernel, SIOCGIFFLAGS indicates IFF_PROMISC when tcpdump is running. When I boot into 2.4 MDK or custom kernel, SIOCGIFFLAGS does not indicate IFF_PROMISC under the same conditions. Jeff, please, go into v2.2/linux/net/packet/af_packet.c and read the comment above CONFIG_PACKET_MULTICAST and the code that macro's definition controls. In particular, read the commentary about multicast routing daemons. Something is different, perhaps your kernel is configured differently or something else, but something is different as the code is identical. From owner-netdev@oss.sgi.com Wed Feb 13 02:41:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1DAfjD07310 for netdev-outgoing; Wed, 13 Feb 2002 02:41:45 -0800 Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1DAff907307 for ; Wed, 13 Feb 2002 02:41:41 -0800 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1D9fZf08927 for ; Wed, 13 Feb 2002 10:41:35 +0100 (CET) (envelope-from Atif.Syed@ccrle.nec.de) Received: from zark (zark.mobility.ccrle.nec.de [192.168.101.95]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id KAA16382 for ; Wed, 13 Feb 2002 10:41:34 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Atif Syed Organization: NEC To: netdev@oss.sgi.com Subject: EXPORT_SYMBOL() Date: Wed, 13 Feb 2002 10:45:22 +0100 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <02021310452200.00723@zark> Content-Transfer-Encoding: 8bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 796 Lines: 24 Hi all, I am writing a kernel module which do some function related to MobileIP. I have taken the example from Linux IP Networking Guide http://www.kernelnewbies.org/documents/ipnetworking/linuxipnetworking.html I have exported this test_function (EXPORT_SYMBOL()) and declared it as extern in file linux/net/netsym.c. I have chosen CONFIG_INET location in this file. Because i am calling these function in the IP-layer. I am sorry if my explanation doesnt sound so good. But question in general is that how can i link this module(test.c+Makefile) in the kernel. I have done it as it was explained in this guide. After compiling i get this error: net/network.o(__ksymtab+0x4e8): undefined reference to `test_function' make: *** [vmlinux] Error 1 Thanks advance for help, Atif Syed From owner-netdev@oss.sgi.com Wed Feb 13 04:45:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1DCjKE09167 for netdev-outgoing; Wed, 13 Feb 2002 04:45:20 -0800 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1DCjH909163 for ; Wed, 13 Feb 2002 04:45:17 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id DAA03270; Wed, 13 Feb 2002 03:43:24 -0800 Date: Wed, 13 Feb 2002 03:43:24 -0800 (PST) Message-Id: <20020213.034324.23011197.davem@redhat.com> To: jgarzik@mandrakesoft.com Cc: ak@suse.de, linux-net@vger.kernel.org, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: IFF_PROMISC bug? From: "David S. Miller" In-Reply-To: <3C6A2789.5DCC1C8F@mandrakesoft.com> References: <3C6A1EF5.1BF97B99@mandrakesoft.com> <20020213.001736.03366378.davem@redhat.com> <3C6A2789.5DCC1C8F@mandrakesoft.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 862 Lines: 20 From: Jeff Garzik Date: Wed, 13 Feb 2002 03:44:57 -0500 [sigh, I meant to have said that we can support IFF_PROMISC for SIOCGIFFLAGS -only-, until the end of time. I agree with you that SIOCSIFFLAGS+IFF_PROMISC clearly is unsupportable.] Then you will break more than what you claim is broken right now. At least the current code RESPECTS setting IFF_PROMISC if an app uses SIOCSIFFLAGS to do it, your version would not. I think you'll be breaking more apps that way, in fact right off the bat your version will break all current NMAP binaries out there. That's just the first thing I checked, there are surely several other examples. The more and more I look at this situation, the more and more I respect Alexey's decision to implement things how they are now. It is the the only reasonable choice, really... From owner-netdev@oss.sgi.com Wed Feb 13 09:03:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1DH3uG21943 for netdev-outgoing; Wed, 13 Feb 2002 09:03:56 -0800 Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1DH3p921940 for ; Wed, 13 Feb 2002 09:03:51 -0800 Received: (qmail 2606 invoked from network); 13 Feb 2002 16:03:43 -0000 Received: from unknown (HELO brick.watson.ibm.com) ([198.81.209.17]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 13 Feb 2002 16:03:43 -0000 Subject: Locking requirements for tcp_v4_do_rcv From: Michal Ostrowski To: netdev@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 13 Feb 2002 11:03:42 -0500 Message-Id: <1013616222.1019.19702.camel@brick.watson.ibm.com> Mime-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1743 Lines: 42 In my experimental environment I've noticed that the socket lock on a TCP socket can be held for a substantial amount of time when calling tcp_v4_do_rcv from tcp_v4_rcv (up 64ms -- 375Mhz PPC). This occurs when the call to tcp_v4_rcv results in subsequent calls to ip_output(), which results in queueing a large number of packets for transmission. When called from tcp_v4_rcv, tcp_v4_do_rcv is protected by bh_lock_sock(), with the additional condition that there are no users queued on the lock (and thus the work cannot be added to backlog processing). OTOH, tcp_v4_do_rcv is also called from __release_sock (via the "backlog_rcv" function pointer). In this case the spin_lock is not held, but *local* bh processing is suppressed. This would seem to imply that bh processing on another processor could grab the spin lock and call tcp_v4_do_rcv at the same time (I don't see how softirq processing here on other processors is blocked --- maybe this is the part I'm missing). Assuming this analysis is correct: 1. The locking around backlog_rcv in __release_sock must be strengthened to prevent bh processing on another cpu from calling tcp_v4_do_rcv or, 2. The locking around tcp_v4_do_rcv in tcp_v4_rcv can be relaxed. In the case of (2) the scenario I mentioned initially is alleviated since the spin lock would presumably not be held through calls to ip_output(). Anyone trying to grab to socket lock would sleep on it (as opposed to spinning on it for this long period of time). Of course, the overall point here is; is it possible to do all of the ip_output() processing without holding the socket lock (or at the very least not holding the spin lock component)? -- Michal Ostrowski mostrows@speakeasy.net From owner-netdev@oss.sgi.com Wed Feb 13 09:46:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1DHkEq22769 for netdev-outgoing; Wed, 13 Feb 2002 09:46:14 -0800 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1DHkA922766 for ; Wed, 13 Feb 2002 09:46:11 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id IAA25460; Wed, 13 Feb 2002 08:44:18 -0800 Date: Wed, 13 Feb 2002 08:44:17 -0800 (PST) Message-Id: <20020213.084417.107946244.davem@redhat.com> To: greearb@candelatech.com Cc: jgarzik@mandrakesoft.com, ak@suse.de, linux-net@vger.kernel.org, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: IFF_PROMISC bug? From: "David S. Miller" In-Reply-To: <3C6A96F8.40303@candelatech.com> References: <20020213.001736.03366378.davem@redhat.com> <3C6A2789.5DCC1C8F@mandrakesoft.com> <3C6A96F8.40303@candelatech.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 356 Lines: 9 From: Ben Greear Date: Wed, 13 Feb 2002 09:40:24 -0700 So, what is the preferred way of making something promisc/not-promisc if we are not to use SIOCSIFFLAGS? Use packet socket, and use the PACKET_{ADD,DROP}_MEMBERSHIP socket options. Pass in a "struct packet_mclist *ptr" whose ptr->type is PACKET_MR_PROMISC. From owner-netdev@oss.sgi.com Wed Feb 13 10:42:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1DIgTf32446 for netdev-outgoing; Wed, 13 Feb 2002 10:42:29 -0800 Received: from 21cn.com ([61.140.60.248]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1DIgN932443 for ; Wed, 13 Feb 2002 10:42:23 -0800 Message-Id: <200202131842.g1DIgN932443@oss.sgi.com> Received: from arpabox([210.52.204.39]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm133c6ac5b3; Thr, 14 Feb 2002 01:49:21 +0800 Date: Thu, 14 Feb 2002 1:44:50 +0800 From: Laurence Reply-To: laudney@21cn.com To: "netdev@oss.sgi.com" Subject: some questions about TCP/IP stack source codes in Linux Kernel 2.4.2 Organization: SJTU X-mailer: FoxMail 4.0 beta 1 [cn] Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1758 Lines: 44 (I'd like to receive replies in emails) I have some questions about the source codes related with connecting in the kernel 2.4.2 tcp/ip stack. First: When the client starts active open in tcp, various funtions are invoked in the following sequence: connect() ----> sys_connect() ----> inet_stream_connect() ----> tcp_v4_connect() ----> tcp_connect() ----> tcp_transmit_skb() After that, nothing is written to it. Then, buff is used as one argument to invoke tcp_connect() (net/ipv4/tcp_output.c). In tcp_connect(), I found the following: /* We'll fix this up when we get a response from the other end. * See tcp_input.c:tcp_rcv_state_process case TCP_SYN_SENT. */ tp->tcp_header_len = sizeof(struct tcphdr) + (sysctl_tcp_timestamps ? TCPOLEN_TSTAMP_ALIGNED : 0); tcp_connect() invokes tcp_transmit_skb() (net/ipv4/tcp_output.c). At the start of tcp_transmit_skb(), I found the following: if (tcb->flags & TCPCB_FLAG_SYN) { tcp_header_size = sizeof(struct tcphdr) + TCPOLEN_MSS; if(sysctl_tcp_timestamps) { tcp_header_size += TCPOLEN_TSTAMP_ALIGNED; sysctl_flags |= SYSCTL_FLAG_TSTAMPS; } Since sysctl_tcp_timestamps doesn't seem to be changed, TCPOLEN_TSTAMP_ALIGNED is added to tp->tcp_header_len twice!!!! I'm puzzled here!!!! :-( Second: in tcp_opt, we have snd_wnd and rcv_wnd. It seems rcv_wnd is the window that we use and snd_wnd is the window that the remote host advertise everytime in the tcp packet. Am I right or just the opposite?? If I'm right, in tcp_connect(), there is one line: tp->snd_wnd = 0; Well, it does so because tcp_connect sends a packet with only SYN and no data?? If I want to carry data in SYN packet, I have to set tp->snd_wnd to 2*MSS or some other value? -- Laudney From owner-netdev@oss.sgi.com Wed Feb 13 11:00:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1DJ0DV00397 for netdev-outgoing; Wed, 13 Feb 2002 11:00:13 -0800 Received: from 21cn.com ([61.140.60.248]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1DJ0B900394 for ; Wed, 13 Feb 2002 11:00:11 -0800 Message-Id: <200202131900.g1DJ0B900394@oss.sgi.com> Received: from arpabox([210.52.204.39]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jma3c6abe68; Thr, 14 Feb 2002 01:59:34 +0800 Date: Thu, 14 Feb 2002 2:2:39 +0800 From: Laurence Reply-To: laudney@21cn.com To: Netdev Subject: Transaction TCP Organization: SJTU X-mailer: FoxMail 4.0 beta 1 [cn] Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 229 Lines: 8 I'm writing T/TCP patch for Linux kernel 2.4.2. I've established the open-source project at http://ttcplinux.sourceforge.net or http://sourceforge.net/projects/ttcplinx. Is anyone interested or has anything to say about that? From owner-netdev@oss.sgi.com Wed Feb 13 11:36:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1DJamx01114 for netdev-outgoing; Wed, 13 Feb 2002 11:36:48 -0800 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1DJai901111 for ; Wed, 13 Feb 2002 11:36:44 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA05640; Wed, 13 Feb 2002 21:36:17 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200202131836.VAA05640@ms2.inr.ac.ru> Subject: Re: IFF_PROMISC bug? To: jgarzik@mandrakesoft.com (Jeff Garzik) Date: Wed, 13 Feb 2002 21:36:17 +0300 (MSK) Cc: davem@redhat.com, ak@suse.de, linux-net@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <3C6A2789.5DCC1C8F@mandrakesoft.com> from "Jeff Garzik" at Feb 13, 2 03:44:57 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1003 Lines: 28 Hello! > For SIOCGIFFLAGS, my preference would be to manage the IFF_PROMISC bit Before all SIOCGIFFLAGS must be managed consistently with SIOCSIFFLAGS. All the rest of requirements are details comparing to this. SIOCSIFFLAGS is not deprecated as api element. It is deprecated for uses sort of made by libpcap, for uses to enable bridging etc. I.e. any which are supposed to be interleaved. Its global function remains for those who want this. > actually enabled or disabled. Thus IFF_PROMISC will reflect the true > state of the hardware, Are you about IFF_PROMISC or about ifconfig yet? It is not one thing. :-) Anyway, ifconfig should show that state which it changes. If you want to look at "true" state you may use "ip link". What is the difference? The difference is that "ip link" _does_ _not_ _allow_ to change this flag. It is just an external state from its viewpoint. No problems with "improving" ifconfig to show true state too, provided untrue one remains on its place too. Alexey From owner-netdev@oss.sgi.com Wed Feb 13 20:07:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1E47sm15141 for netdev-outgoing; Wed, 13 Feb 2002 20:07:54 -0800 Received: from 21cn.com ([61.140.60.248]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1E47f915138 for ; Wed, 13 Feb 2002 20:07:44 -0800 Message-Id: <200202140407.g1E47f915138@oss.sgi.com> Received: from arpabox([210.52.205.140]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm1a3c6b6efe; Thr, 14 Feb 2002 11:06:45 +0800 Date: Thu, 14 Feb 2002 11:10:0 +0800 From: Laurence Reply-To: laudney@21cn.com To: Netdev Subject: T/TCP Problems can be solved. Organization: SJTU X-mailer: FoxMail 4.0 beta 1 [cn] Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1732 Lines: 28 On mlists.linux.kernel, on comp.os.linux.development.sys, I keep hearing from people who say T/TCP is fundamentally broken because it has various serious flaws: 1. T/TCP guesses an unreasonable window size (4k) for its peer and sends SYN with data accordingly. It can be easily changed into 2*MSS, which is used in standard TCP implementations. 2. T/TCP has great potential for DoS attacks. Because T/TCP sends data along with first SYN, ttcp is more vulnerable to DoS attacks. But, if ttcp queues the data only TAO succeeds and discards it if TAO fails, this problem can be greatly lessened. Adding some host validation methods may fully solve this problem. 3. T/TCP has great potential for r-* services attacks. TCP also has it! It's always recommended that r-* be turned off. And r-* is being replaced by SSH etc. Besides, ttcp sends packets with PUSH flag. r-* refuses any packet with PUSH flag. So, there should be no problem. FreeBSD integrates ttcp in its kernel. This can be a strong evidence about ttcp's applicability. T/TCP is considered flawed mainly because RFC 1644 doesn't consider security problems. It definitely needs improvements. A new RFC is necessary at the end. What I'm going to do is to implement a "basic" ttcp patch based on RFC 1644. Then, when people download the patch and test it, I'll collect every posted problems along with it and modify the patch accordingly. During the same process, I'll find out what improvements are needed for RFC 1644 and draft a new one. So, I hope people don't simply discard TTCP. Anyway, there will be more benefits for all of us if TTCP is fixed instead of being thrown away. I can't do that alone without your support and help. Thanks. ------- Laudney From owner-netdev@oss.sgi.com Wed Feb 13 21:45:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1E5jww16809 for netdev-outgoing; Wed, 13 Feb 2002 21:45:58 -0800 Received: from ip68-3-107-226.ph.ph.cox.net (ip68-3-107-226.ph.ph.cox.net [68.3.107.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1E5jq916806 for ; Wed, 13 Feb 2002 21:45:52 -0800 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by ip68-3-107-226.ph.ph.cox.net (8.11.6/8.11.2) with ESMTP id g1E4jes24865; Wed, 13 Feb 2002 21:45:42 -0700 Message-ID: <3C6B40F4.2010606@candelatech.com> Date: Wed, 13 Feb 2002 21:45:40 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: laudney@21cn.com CC: Netdev Subject: Re: T/TCP Problems can be solved. References: <200202140407.g1E47f915138@oss.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2193 Lines: 45 For those of us who are ignorant of T/TCP, what are the benefits of the protocol (it has to be more than just not broken for me to get interested in it :)) Thanks, Ben Laurence wrote: > On mlists.linux.kernel, on comp.os.linux.development.sys, I keep hearing from people who say T/TCP is fundamentally broken because it has various serious flaws: > 1. T/TCP guesses an unreasonable window size (4k) for its peer and sends SYN with data accordingly. > > It can be easily changed into 2*MSS, which is used in standard TCP implementations. > > 2. T/TCP has great potential for DoS attacks. > > Because T/TCP sends data along with first SYN, ttcp is more vulnerable to DoS attacks. But, if ttcp queues the data only TAO succeeds and discards it if TAO fails, this problem can be greatly lessened. Adding some host validation methods may fully solve this problem. > > 3. T/TCP has great potential for r-* services attacks. > > TCP also has it! It's always recommended that r-* be turned off. And r-* is being replaced by SSH etc. Besides, ttcp sends packets with PUSH flag. r-* refuses any packet with PUSH flag. So, there should be no problem. > > > > FreeBSD integrates ttcp in its kernel. This can be a strong evidence about ttcp's applicability. > > T/TCP is considered flawed mainly because RFC 1644 doesn't consider security problems. It definitely needs improvements. A new RFC is necessary at the end. > > What I'm going to do is to implement a "basic" ttcp patch based on RFC 1644. Then, when people download the patch and test it, I'll collect every posted problems along with it and modify the patch accordingly. During the same process, I'll find out what improvements are needed for RFC 1644 and draft a new one. > > So, I hope people don't simply discard TTCP. Anyway, there will be more benefits for all of us if TTCP is fixed instead of being thrown away. I can't do that alone without your support and help. > Thanks. > > > ------- Laudney > > -- 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 Feb 13 23:34:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1E7Yot19022 for netdev-outgoing; Wed, 13 Feb 2002 23:34:50 -0800 Received: from 21cn.com ([61.140.60.248]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1E7Yl919019 for ; Wed, 13 Feb 2002 23:34:47 -0800 Message-Id: <200202140734.g1E7Yl919019@oss.sgi.com> Received: from arpabox([210.52.204.157]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jmf3c6ba13f; Thr, 14 Feb 2002 14:33:56 +0800 Date: Thu, 14 Feb 2002 14:37:14 +0800 From: Laurence Reply-To: laudney@21cn.com To: Netdev Subject: Benefits of a sound T/TCP Organization: SJTU X-mailer: FoxMail 4.0 beta 1 [cn] Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2289 Lines: 13 T/TCP is an extension for standard TCP to improve performance. I've established "T/TCP for Linux" at http://sourceforge.net/projects/ttcplinux. Besides, our website at http://ttcplinux.sourceforge.net is ready. You can click the "Overview" tab on the left side to see a succinct description about T/TCP. But let me talk about it here first. In one scenario, say, "Transaction", will you see most performance improvement. The so-called "transaction" means the client connects to the server by TCP to send one packet of request and expects one packet of response. Then, the client closes the connection. But within seconds, the client has to send another packet of request to the same server and expects another packet of response. In one word, the connection between one client and one server is short in time but quite frequent. Using standard TCP, the brief connection requires at least 8 packets of exchange. Using T/TCP, it can be reduced to 3. The whole time is reduced by nearly half. Besides, in standard TCP, after actively closing the connection, the client is in "TIME_WAIT" state usually for 240 seconds. During this period, the socket (client.port, client.ip, server.port, server.ip) can't be used. Therefore, to start another connection immediately, the client must change its port. But, there are limited ports (say, 65535) available, which means you can start at most 65535 connections in 240 seconds. It's a serious limitation. In T/TCP, by introducing special mechanism, the TIME_WAIT period is reduced to 12 seconds. You can easily calculate the gain. When the client or the server needs to send multiple packets of data (request or response), T/TCP causes the side to send multiple packets continously, instead of sending each one and waiting for the acknowledgement before going on, as in standard TCP. Performance gain is also obvious. On http://souceforge.net/projects/ttcplinux, there are patch for 2.0.32 and 2.2.14 finished by two other people in 1997 and 1999 respectively. You may need quite a lot of tests. I'm writing the patch for 2.4.2, which can be easily transplanted to 2.4.x in the future. I haven't finished the basic version and therefore haven't uploaded the codes into CVS. But if anyone is interested, I can send them by email. --Laudney From owner-netdev@oss.sgi.com Thu Feb 14 09:07:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1EH7bv21334 for netdev-outgoing; Thu, 14 Feb 2002 09:07:37 -0800 Received: from grok.yi.org (IDENT:HZ2zqCGFWOw4iDqoupORJO/Ez2tW+pGP@ip68-3-107-226.ph.ph.cox.net [68.3.107.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1EH7U921306 for ; Thu, 14 Feb 2002 09:07:32 -0800 Received: from candelatech.com (IDENT:OHsyuGcKJJAS4KDiQ0RfgVM3ADFzA/sE@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g1EG7Pf06350; Thu, 14 Feb 2002 09:07:26 -0700 Message-ID: <3C6BE0BD.70802@candelatech.com> Date: Thu, 14 Feb 2002 09:07:25 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: laudney@21cn.com CC: Netdev Subject: Re: Benefits of a sound T/TCP References: <200202140734.g1E7Yl919019@oss.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2950 Lines: 47 Laurence wrote: > T/TCP is an extension for standard TCP to improve performance. I've established "T/TCP for Linux" at http://sourceforge.net/projects/ttcplinux. Besides, our website at http://ttcplinux.sourceforge.net is ready. You can click the "Overview" tab on the left side to see a succinct description about T/TCP. But let me talk about it here first. > > In one scenario, say, "Transaction", will you see most performance improvement. The so-called "transaction" means the client connects to the server by TCP to send one packet of request and expects one packet of response. Then, the client closes the connection. But within seconds, the client has to send another packet of request to the same server and expects another packet of response. In one word, the connection between one client and one server is short in time but quite frequent. Using standard TCP, the brief connection requires at least 8 packets of exchange. Using T/TCP, it can be reduced to 3. The whole time is reduced by nearly half. Besides, in standard TCP, after actively closing the connection, the client is in "TIME_WAIT" state usually for 240 seconds. During this period, the socket (client.port, client.ip, server.port, server.ip) can't be used. Therefore, to start another connection immediately, the client must change its port. But, there are limited ports (say ,! > 65535) available, which means you can start at most 65535 connections in 240 seconds. It's a serious limitation. In T/TCP, by introducing special mechanism, the TIME_WAIT period is reduced to 12 seconds. You can easily calculate the gain. > You can make your socket re-usable, which fixes the 240 seconds issue. The short, bursty transaction savings sounds useful...but it also sounds like most programs that need it could be optimized to keep up a continious connection! > When the client or the server needs to send multiple packets of data (request or response), T/TCP causes the side to send multiple packets continously, instead of sending each one and waiting for the acknowledgement before going on, as in standard TCP. Performance gain is also obvious. > TCP's sliding window already allows this, since like 1980 or so :) I'll try to find time to read some more details from your page soon... Thanks, Ben > On http://souceforge.net/projects/ttcplinux, there are patch for 2.0.32 and 2.2.14 finished by two other people in 1997 and 1999 respectively. You may need quite a lot of tests. > > I'm writing the patch for 2.4.2, which can be easily transplanted to 2.4.x in the future. I haven't finished the basic version and therefore haven't uploaded the codes into CVS. But if anyone is interested, I can send them by email. > > --Laudney > > -- 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 Feb 14 13:49:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1ELnjs01152 for netdev-outgoing; Thu, 14 Feb 2002 13:49:45 -0800 Received: from chmls18.ne.ipsvc.net (chmls18.ne.ipsvc.net [24.147.1.153]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1ELnh901149 for ; Thu, 14 Feb 2002 13:49:43 -0800 Received: from [192.168.1.120] (h00045ace1c92.ne.mediaone.net [24.91.198.11]) by chmls18.ne.ipsvc.net (8.11.6/8.11.6) with ESMTP id g1EKna816422; Thu, 14 Feb 2002 15:49:37 -0500 (EST) Subject: Re: Benefits of a sound T/TCP From: Frank Solensky To: laudney@21cn.com Cc: netdev@oss.sgi.com In-Reply-To: <200202140734.g1E7Yl919019@oss.sgi.com> References: <200202140734.g1E7Yl919019@oss.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 14 Feb 2002 15:03:25 -0500 Message-Id: <1013717033.1684.21.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 170 Lines: 4 FWIW, this was once discussed at an IETF meeting in 1996. See http://www.ietf.cnri.reston.va.us/proceedings/96mar/area.and.wg.reports/tsv/ttcp/ttcp-minutes-96mar.html From owner-netdev@oss.sgi.com Thu Feb 14 18:40:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1F2euC05037 for netdev-outgoing; Thu, 14 Feb 2002 18:40:56 -0800 Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1F2es905034 for ; Thu, 14 Feb 2002 18:40:54 -0800 Received: by tapu.f00f.org (Postfix, from userid 1000) id DAA151A68CC; Thu, 14 Feb 2002 17:40:37 -0800 (PST) Date: Thu, 14 Feb 2002 17:40:37 -0800 From: Chris Wedgwood To: Ben Greear Cc: laudney@21cn.com, Netdev Subject: Re: T/TCP Problems can be solved. Message-ID: <20020215014037.GA5842@tapu.f00f.org> References: <200202140407.g1E47f915138@oss.sgi.com> <3C6B40F4.2010606@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C6B40F4.2010606@candelatech.com> User-Agent: Mutt/1.3.27i X-No-Archive: Yes Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 341 Lines: 12 On Wed, Feb 13, 2002 at 09:45:40PM -0700, Ben Greear wrote: For those of us who are ignorant of T/TCP, what are the benefits of the protocol (it has to be more than just not broken for me to get interested in it :)) For small transfers, the 'handshake/setup' overhead is reduced (relative to the total packet count). --cw From owner-netdev@oss.sgi.com Thu Feb 14 19:33:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1F3XEh06005 for netdev-outgoing; Thu, 14 Feb 2002 19:33:14 -0800 Received: from 21cn.com ([61.140.60.248]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1F3XA906002 for ; Thu, 14 Feb 2002 19:33:11 -0800 Message-Id: <200202150333.g1F3XA906002@oss.sgi.com> Received: from arpabox([210.52.203.62]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm183c6ca474; Fri, 15 Feb 2002 10:40:07 +0800 Date: Fri, 15 Feb 2002 10:35:40 +0800 From: Laurence Reply-To: laudney@21cn.com To: Netdev Subject: T/TCP: why 2.4.2 Organization: SJTU X-mailer: FoxMail 4.0 beta 1 [cn] Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 328 Lines: 7 Linux kernel's TCP/IP stack source codes were greatly modified in 2.4.0. After that, according to changelogs, only small fixes are made in 2.4.2, 2.4.5, 2.4.10 and 2.4.14. In case anyone still uses early versions of 2.4.x series, I choose to write patch for 2.4.2, which can be easily transplanted to the entire 2.4.x series. From owner-netdev@oss.sgi.com Thu Feb 14 20:30:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1F4U5Y06756 for netdev-outgoing; Thu, 14 Feb 2002 20:30:05 -0800 Received: from shell.cyberus.ca (shell.cyberus.ca [216.191.240.114]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1F4Tv906740 for ; Thu, 14 Feb 2002 20:29:57 -0800 Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.3/666/Cyberus Online Inc.) with ESMTP id WAA13501; Thu, 14 Feb 2002 22:25:23 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Thu, 14 Feb 2002 22:25:23 -0500 (EST) From: jamal To: Laurence cc: Netdev Subject: Re: T/TCP Problems can be solved. In-Reply-To: <200202140407.g1E47f915138@oss.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2412 Lines: 66 Your subject sounds exciting; i almost thought you invented something new; I read it and was disapointed to find you are just sounding like a salivating marketeer. BTW, fix you eol On Thu, 14 Feb 2002, Laurence wrote: > On mlists.linux.kernel, on comp.os.linux.development.sys, I keep hearing from people who say T/TCP is fundamentally broken because it has various serious flaws: > 1. T/TCP guesses an unreasonable window size (4k) for its peer and sends SYN with data accordingly. > > It can be easily changed into 2*MSS, which is used in standard TCP implementations. > Less data to chew on ;-> > 2. T/TCP has great potential for DoS attacks. > > Because T/TCP sends data along with first SYN, ttcp is more vulnerable > to DoS attacks. But, if ttcp queues the data only TAO succeeds and > discards it if TAO fails, this problem > can be greatly lessened. Adding some host > validation methods may fully solve this problem. > How can a packet that carries data have the same effect in terms of compute power and mem abuse as one that doesnt? > 3. T/TCP has great potential for r-* services attacks. > > TCP also has it! It's always recommended that r-* be > turned off. And r-* is being replaced by SSH etc. Besides, ttcp sends So lets kill those applications so that T/TCP can live >packets with PUSH flag. r-* refuses any packet with PUSH flag. So, there > should be no problem. > > > > FreeBSD integrates ttcp in its kernel. This can be a strong evidence > about ttcp's applicability. bullshit. > T/TCP is considered flawed mainly because RFC 1644 doesn't consider > security problems. It definitely needs improvements. A new RFC is > necessary at the end. So far any of your arguements above dont prove a thing. > What I'm going to do is to implement a "basic" ttcp patch based on RFC 1644. Then, when people download the patch and test it, I'll collect every posted problems along with it and modify the patch accordingly. During the same process, I'll find out what improvements are needed for RFC 1644 and draft a new one. > > So, I hope people don't simply discard TTCP. Anyway, there will be more benefits for all of us if TTCP is fixed instead of being thrown away. I can't do that alone without your support and help. > Thanks. > Look, nobody is going to stop you from implementing things; have fun while doing it. Trying to sell used cars wont help you very much. cheers, jamal From owner-netdev@oss.sgi.com Thu Feb 14 21:32:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1F5WRS07424 for netdev-outgoing; Thu, 14 Feb 2002 21:32:27 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1F5WO907421 for ; Thu, 14 Feb 2002 21:32:24 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 28D551E454; Fri, 15 Feb 2002 05:32:18 +0100 (MET) Date: Fri, 15 Feb 2002 05:32:17 +0100 From: Andi Kleen To: Laurence Cc: Netdev Subject: Re: T/TCP: why 2.4.2 Message-ID: <20020215053217.A23795@wotan.suse.de> References: <200202150333.g1F3XA906002@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200202150333.g1F3XA906002@oss.sgi.com> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 485 Lines: 12 On Fri, Feb 15, 2002 at 10:35:40AM +0800, Laurence wrote: > Linux kernel's TCP/IP stack source codes were greatly modified > in 2.4.0. After that, according to changelogs, only small fixes > are made in 2.4.2, 2.4.5, 2.4.10 and 2.4.14. In case anyone still > uses early versions of 2.4.x series, I choose to write patch for > 2.4.2, which can be easily transplanted to the entire 2.4.x series. > That's incorrect. An major update went into 2.4.4 that changed many interfaces. -Andi From owner-netdev@oss.sgi.com Fri Feb 15 00:53:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1F8rx109245 for netdev-outgoing; Fri, 15 Feb 2002 00:53:59 -0800 Received: from coruscant.gnumonks.org (mail@coruscant.franken.de [193.174.159.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1F8rp909242 for ; Fri, 15 Feb 2002 00:53:51 -0800 Received: from uucp by coruscant.gnumonks.org with local-bsmtp (Exim 3.33 #1) id 16bdBk-0001Y5-00 for netdev@oss.sgi.com; Fri, 15 Feb 2002 08:53:48 +0100 Received: from laforge by sunbeam.gnumonks.org with local (Exim 3.34 #1) id 16bd1V-0000Pf-00; Fri, 15 Feb 2002 08:43:13 +0100 Date: Fri, 15 Feb 2002 08:43:13 +0100 From: Harald Welte To: Ulrich Mohr Cc: linux-kernel@vger.kernel.org, David Miller , Netfilter Development Mailinglist , netdev@oss.sgi.com Subject: Re: PROBLEM: Netfilter inconsistency? Message-ID: <20020215084313.Y28092@sunbeam.de.gnumonks.org> Mail-Followup-To: Harald Welte , Ulrich Mohr , linux-kernel@vger.kernel.org, David Miller , Netfilter Development Mailinglist , 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 ue2m@rz.uni-karlsruhe.de on Fri, Feb 15, 2002 at 01:01:49AM +0100 X-Operating-System: Linux sunbeam.de.gnumonks.org 2.4.17 X-Date: Today is Prickle-Prickle, the 44th day of Chaos in the YOLD 3168 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1767 Lines: 42 On Fri, Feb 15, 2002 at 01:01:49AM +0100, Ulrich Mohr wrote: Hi! > When the LOCAL_OUT hook is called via ip_build_and_send_packet or > ip_build_xmit, then ip_select_ident is called prior to the call to > the LOCAL_OUT hook and will not change after the call to the hook. > > When the LOCAL_OUT hook is called via ip_queue_xmit, then the > ip_select_ident is called after the call to the netfilter hook, and > the value of the id field in the ip-header changes after a reinject. > [...] > I tried to make the call to ip_select_ident before the hooks are called, > and I did not see any side effects (the if field was set directly after > the hook was called anyway on all execution paths, and it did not depend > on any information which was not present prior to the hook was called). > http, scp, ftp & icmp are working fine with this modification. >From a netfiler point of view I don't see any problems with your approach, and in fact it seems cleaner to have a consistent behaviour with regard to the id field. But since the change is not inside the netfilter code, but in the core networking, it's up to the core networking maintainers to decide if this patch is acceptable or might break something. > > I insert the patch I did to ip_output.c on Kernel v. 2.4.10. Please always use unified diff - it's difficult to understand your patch just from reading it since it doesn't contain context (diff -u) > Thank you, > Uli -- Live long and prosper - Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/ ============================================================================ GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M+ V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*) From owner-netdev@oss.sgi.com Fri Feb 15 07:54:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FFsEo25992 for netdev-outgoing; Fri, 15 Feb 2002 07:54:14 -0800 Received: from mailer3.bham.ac.uk (mailer3.bham.ac.uk [147.188.128.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FFs9925982 for ; Fri, 15 Feb 2002 07:54:10 -0800 Received: from bham.ac.uk ([147.188.128.127]) by mailer3.bham.ac.uk with esmtp (Exim 3.16 #2) id 16bjkO-0003j5-00 for netdev@oss.sgi.com; Fri, 15 Feb 2002 14:54:00 +0000 Received: from bham-eee-fs4.bham.ac.uk ([147.188.147.167]) by bham.ac.uk with esmtp (Exim 3.16 #3) id 16bjkO-00063y-00 for netdev@oss.sgi.com; Fri, 15 Feb 2002 14:54:00 +0000 Received: by bham-eee-fs4.bham.ac.uk with Internet Mail Service (5.5.2653.19) id <1ZNQ69AS>; Fri, 15 Feb 2002 14:53:59 -0000 Message-ID: <1396177A57E2D511A1EB0008C7866E1832198D@bham-eee-fs4.bham.ac.uk> From: "G113 (G.P.ROBERTS)" To: "'netdev@oss.sgi.com'" Subject: sk_buffs in netif_rx() Date: Fri, 15 Feb 2002 14:53:50 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1017 Lines: 28 Hi, I am using linux rh 7.0 with kernel 2.2.16-22. I am trying to printk the destination and source address of a packet in netif_rx() just before it is added to the backlog queue. I have done this successfully in Eth.c to read out skb->data[26], skb->data[27], up to skb->data[33] which gives the correct information for the source address. However, skb->data[26] does not point to the right place when I read it from a packet in the netif_rx() function. How do I work out where to look in skb->data to find the information (I would also like to read the timestamp and tcp sequence number) - are the ip addresses and timestamps now in the "actual" data section of the packet, pointed to by skb->head? I assume it has changed position because of the ethernet header having been stripped by the time it gets to netif_rx(). I would also like to be able to read it in netbh() when a packet is taken from the queue - will the information be at the same point in the packet here? Thanks, Graham From owner-netdev@oss.sgi.com Fri Feb 15 08:20:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FGKBF26446 for netdev-outgoing; Fri, 15 Feb 2002 08:20:11 -0800 Received: from 21cn.com ([61.140.60.248]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FGK2926434 for ; Fri, 15 Feb 2002 08:20:02 -0800 Message-Id: <200202151620.g1FGK2926434@oss.sgi.com> Received: from arpabox([210.52.205.113]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm133c6d3936; Fri, 15 Feb 2002 23:19:18 +0800 Date: Fri, 15 Feb 2002 23:22:35 +0800 From: Laurence Reply-To: laudney@21cn.com To: "netdev@oss.sgi.com" Subject: Re: sk_buffs in netif_rx() Organization: SJTU X-mailer: FoxMail 4.0 beta 1 [cn] Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1707 Lines: 62 >I am trying to printk the destination and source address of a packet >in netif_rx() just before it is added to the backlog queue. > >I have done this successfully in Eth.c to read out skb->data[26], >skb->data[27], up to skb->data[33] which gives the correct information >for the source address. > >However, skb->data[26] does not point to the right place when I read >it from a packet in the netif_rx() function. > >How do I work out where to look in skb->data to find the information >(I would also like to read the timestamp and tcp sequence number) - >are the ip addresses and timestamps now in the "actual" data section >of the packet, pointed to by skb->head? I assume it has changed position >because of the ethernet header having been stripped by the time it gets to >netif_rx(). Yes, you can do that. First, as for address, you mean IP address?? If so, they are in the IP header. You can access IP header in skb as follow: struct iphdr *iph = skb->nh.iph It's a pointer to struct iphdr. You can find its definition in include/linux/ip.h to access addresses: __u32 sa = skb->nh.iph.saddr __u32 da = skb->nh.iph.daddr Second, to access timestamp: sk_buff { .. struct timeval stamp; .. } Third, to access TCP sequence number: tcp sequnce number is located in tcphdr{} in include/linux/tcp.h so, struct tcphdr *th = skb->h.th; __u32 seq = th.seq; > >I would also like to be able to read it in netbh() when a packet is >taken from the queue - will the information be at the same point in >the packet here? what queue?? sk->receive_queue?? Linux uses tcp_recvmsg (net/ipv4/tcp.c) to take packets from there. Look at the source codes to find more information -- Laudney From owner-netdev@oss.sgi.com Fri Feb 15 08:35:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FGZ2Y26844 for netdev-outgoing; Fri, 15 Feb 2002 08:35:02 -0800 Received: from 21cn.com ([61.140.60.248]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FGYx926841 for ; Fri, 15 Feb 2002 08:35:00 -0800 Message-Id: <200202151635.g1FGYx926841@oss.sgi.com> Received: from arpabox([210.52.205.107]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm303c6d5114; Fri, 15 Feb 2002 23:31:36 +0800 Date: Fri, 15 Feb 2002 23:37:33 +0800 From: Laurence Reply-To: laudney@21cn.com To: Netdev Subject: program "sock" by Richard Stevens Organization: SJTU X-mailer: FoxMail 4.0 beta 1 [cn] Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 90 Lines: 6 Has anyone transplanted W. Richard Stevens's network program "sock" to Linux?? Laudney From owner-netdev@oss.sgi.com Fri Feb 15 08:45:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FGjbP27118 for netdev-outgoing; Fri, 15 Feb 2002 08:45:37 -0800 Received: from x86unx3.comp.nus.edu.sg (x86unx3.comp.nus.edu.sg [137.132.90.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FGjW927114 for ; Fri, 15 Feb 2002 08:45:32 -0800 Received: from e500a.comp.nus.edu.sg (e500a.comp.nus.edu.sg [137.132.90.23]) by x86unx3.comp.nus.edu.sg (8.9.1/8.9.1) with SMTP id XAA08051; Fri, 15 Feb 2002 23:45:27 +0800 (GMT-8) Received: from sf0.comp.nus.edu.sg(137.132.90.52) by e500a.comp.nus.edu.sg via csmap id 1744; Fri, 15 Feb 2002 23:43:29 +0800 (SGT) Received: from localhost (mksarav@localhost) by sf0.comp.nus.edu.sg (8.8.5/8.8.5) with ESMTP id XAA08609; Fri, 15 Feb 2002 23:45:26 +0800 (GMT-8) Date: Fri, 15 Feb 2002 23:45:26 +0800 (GMT-8) From: M K Saravanan To: Laurence cc: Netdev Subject: Re: program "sock" by Richard Stevens In-Reply-To: <200202151635.g1FGYx926841@oss.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 363 Lines: 19 yes. Mike Borella the author of "ipgrab" utility (ipgrab.sourceforge.net) ported sock to linux and is avl. at: http://home.xnet.com/~cathmike/mike/software/ Really a useful utility. -- mks -- On Fri, 15 Feb 2002, Laurence forced the electrons thusly: > Has anyone transplanted W. Richard Stevens's network > program "sock" to Linux?? > > Laudney > > > From owner-netdev@oss.sgi.com Fri Feb 15 09:02:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FH2DS28104 for netdev-outgoing; Fri, 15 Feb 2002 09:02:13 -0800 Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FH29928101 for ; Fri, 15 Feb 2002 09:02:09 -0800 Received: from fwd07.sul.t-online.de by mailout10.sul.t-online.com with smtp id 16bkNI-0004qP-00; Fri, 15 Feb 2002 16:34:12 +0100 Received: from there (320016507023-0001@[217.233.253.56]) by fwd07.sul.t-online.com with smtp id 16bkN6-1xPMn2C; Fri, 15 Feb 2002 16:34:00 +0100 Content-Type: text/plain; charset="iso-8859-15" From: Joachim.Franek@t-online.de (Joachim Franek) Reply-To: joachim.franek@t-online.de Organization: IBJF To: netdev@oss.sgi.com Subject: ifconfig, ip and ethernet driver module Date: Fri, 15 Feb 2002 16:30:03 +0100 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <16bkN6-1xPMn2C@fwd07.sul.t-online.com> X-Sender: 320016507023-0001@t-dialin.net Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 602 Lines: 25 Hello, I have a question about the  location, the ip number is stored. Kernel 2.4.x. Assume there is a ethernet driver module eth.o. With insmod eth.o there is eth1 available and with ifconfig eth1 192.168.10.12 up the interface is operational. ifconfig calls the code of the function: int eth_open(struct net_device *dev) And at this time I want to know  the parameter of ifconfig. my_network= ???   (Result: 192*256*256 + 168*256 + 10) my_ip= ??? (Result: 12) (assuming a netmask of 24 bits) Thanks. Joachim Franek Ernst-Reuter-Str. 8, D-63486 Bruchkoebel www.de-franek.de rs485.de-franek.de From owner-netdev@oss.sgi.com Fri Feb 15 11:58:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FJwNg07227 for netdev-outgoing; Fri, 15 Feb 2002 11:58:23 -0800 Received: from fancypants.trellisinc.com (dsl-65-188-226-101.telocity.com [65.188.226.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FJwL907224 for ; Fri, 15 Feb 2002 11:58:21 -0800 Received: from aumshiva.localnet (unknown [192.168.0.106]) by fancypants.trellisinc.com (Postfix) with SMTP id D2B5CA3C1E for ; Fri, 15 Feb 2002 13:56:51 -0500 (EST) Received: by aumshiva.localnet (sSMTP sendmail emulation); Fri, 15 Feb 2002 13:56:46 -0500 From: Jason Lunz Date: Fri, 15 Feb 2002 13:56:46 -0500 To: netdev@oss.sgi.com Subject: NAPI question about old drivers Message-ID: <20020215185646.GA6614@trellisinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 483 Lines: 17 I'm reading the NAPI patch and I don't understand how old drivers can continue to work. in net_rx_action(), NAPI does this: if (dev->quota <= 0 || dev->poll(dev, &budget)) { what happens to legacy drivers that don't set dev->poll? I see netif_rx() has been modified, but drivers that call that and don't have a dev->poll will be in trouble when net_rx_action() runs. am i missing something? -- Jason Lunz Trellis Network Security j@trellisinc.com http://www.trellisinc.com/ From owner-netdev@oss.sgi.com Fri Feb 15 18:08:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1G28VF18319 for netdev-outgoing; Fri, 15 Feb 2002 18:08:31 -0800 Received: from 21cn.com ([61.140.60.248]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1G28N918316 for ; Fri, 15 Feb 2002 18:08:24 -0800 Message-Id: <200202160208.g1G28N918316@oss.sgi.com> Received: from arpabox([210.52.203.18]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jma3c6e20c7; Sat, 16 Feb 2002 09:05:00 +0800 Date: Sat, 16 Feb 2002 9:10:59 +0800 From: Laurence Reply-To: laudney@21cn.com To: "netdev@oss.sgi.com" Subject: Re: Re: T/TCP Problems can be solved. Organization: SJTU X-mailer: FoxMail 4.0 beta 1 [cn] Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1676 Lines: 53 >> 2. T/TCP has great potential for DoS attacks. >> >> Because T/TCP sends data along with first SYN, ttcp is more vulnerable >> to DoS attacks. But, if ttcp queues the data only TAO succeeds and >> discards it if TAO fails, this problem >> can be greatly lessened. Adding some host >> validation methods may fully solve this problem. >> > >How can a packet that carries data have the same effect in terms >of compute power and mem abuse as one that doesnt? Well, you are right at this point. A packet with data will never be the same as those without data. But, just think about the benefits of doing so (reducing total time by one RTT). It's simply a tradeoff. >> 3. T/TCP has great potential for r-* services attacks. >> >> TCP also has it! It's always recommended that r-* be >> turned off. And r-* is being replaced by SSH etc. Besides, ttcp sends > >So lets kill those applications so that T/TCP can live In my implementation, every socket (or connection) has its own right to decide whether to turn T/TCP off. So, simply disable ttcp on listen sockets of those services. >> FreeBSD integrates ttcp in its kernel. This can be a strong evidence >> about ttcp's applicability. > >bullshit. Not a good response for FreeBSD community. >Look, nobody is going to stop you from implementing things; have fun >while doing it. Trying to sell used cars wont help you very much. > >cheers, >jamal Look, I'm really having fun while doing it. But let me clarify, I'm not selling used cars. We're trying to find out proper fixes to Benz 400 and produce Benz 600. Thanks for all your comments, which make me see more clearly the other side of the coin. Sincerely, Laudney From owner-netdev@oss.sgi.com Fri Feb 15 18:56:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1G2uKU18898 for netdev-outgoing; Fri, 15 Feb 2002 18:56:20 -0800 Received: from 21cn.com ([61.140.60.248]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1G2uF918895 for ; Fri, 15 Feb 2002 18:56:15 -0800 Message-Id: <200202160256.g1G2uF918895@oss.sgi.com> Received: from arpabox([210.52.203.218]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jmf3c6e2f4d; Sat, 16 Feb 2002 09:55:40 +0800 Date: Sat, 16 Feb 2002 9:58:51 +0800 From: Laurence Reply-To: laudney@21cn.com To: "netdev@oss.sgi.com" Subject: Re: Re: program "sock" by Richard Stevens Organization: SJTU X-mailer: FoxMail 4.0 beta 1 [cn] Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1036 Lines: 39 >Martin Devera writes > >I don't know the answer but I'm curious - what is >the "sock" program for ? "sock" is a network program written by W. Richard Stevens. It can be used both as a client and as a server and can generate both TCP and UDP packets. It works in 4 modes: 1. client: sock bsd echo establishes a tcp connection to bsd's echo service 2. server: sock -s 192.168.0.1 5555 runs a service on local ip address 192.168.0.1 and port 5555. Then, this server will copy data from the client to STDOUT and copy data input from STDIN to the client 3. source client: sock -i -n12 -w4096 bsd discard write 4096 bytes of data to the discard service on bsd for 12 times. 4. source server: sock -i -s 5555 discards any data received on 5555 So, "sock" is mainly used to generate tcp/udp packets across the net. You can easily study the entire process in details. It can be downloaded at http://home.xnet.com/~cathmike/mike/software/ and an improved GPL one at http://sourceforge.net/projects/opensock -- Laudney From owner-netdev@oss.sgi.com Fri Feb 15 19:09:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1G39xw19184 for netdev-outgoing; Fri, 15 Feb 2002 19:09:59 -0800 Received: from exch-connector.netcomsystems.com (mushroom.netcomsystems.com [12.9.24.195]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1G39v919181 for ; Fri, 15 Feb 2002 19:09:58 -0800 Received: by exch-connector.netcomsystems.com with Internet Mail Service (5.5.2655.55) id <19T778CL>; Fri, 15 Feb 2002 18:09:52 -0800 Message-ID: <9384475DFC05D2118F9C00805F6F263107ECA8C3@exchange1.netcomsystems.com> From: "Perches, Joe" To: netdev@oss.sgi.com Subject: RE: Re: program "sock" by Richard Stevens Date: Fri, 15 Feb 2002 18:09:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 132 Lines: 3 > an improved GPL one at http://sourceforge.net/projects/opensock Not a project. No files, no activity, no interest it appears... From owner-netdev@oss.sgi.com Sat Feb 16 02:22:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1GAMSB25930 for netdev-outgoing; Sat, 16 Feb 2002 02:22:28 -0800 Received: from 21cn.com ([61.140.60.248]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1GAMP925927 for ; Sat, 16 Feb 2002 02:22:25 -0800 Message-Id: <200202161022.g1GAMP925927@oss.sgi.com> Received: from arpabox([210.52.204.209]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm73c6e6b4c; Sat, 16 Feb 2002 17:18:58 +0800 Date: Sat, 16 Feb 2002 17:24:58 +0800 From: Laurence Reply-To: laudney@21cn.com To: Netdev Subject: about time measurement Organization: SJTU X-mailer: FoxMail 4.0 beta 1 [cn] Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 648 Lines: 19 Hi, I'm trying to measure how long a particular socket has been around. My plan is to record "jiffies" at the creation process of the socket. Then, when I want to measure, I record again "jiffies" in another variable and calculate the result. But I'm having the following problems: 1. In which file is "jiffies" defined? 2. What's the unit of "jiffies"? seconds, ms, or so?? 3. I want to compare the "jiffies" result to TCP_TIMEWAIT_LEN, which is defined in "include/net/tcp.h" as "(60*HZ)". What unit conversion must I take to compare "jiffies" result with it?? 4. If there are better ways, what're they? Thanks a lot in advance. -- Laudney From owner-netdev@oss.sgi.com Sat Feb 16 02:51:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1GApYR26257 for netdev-outgoing; Sat, 16 Feb 2002 02:51:34 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1GApV926254 for ; Sat, 16 Feb 2002 02:51:31 -0800 Received: (from robert@localhost) by robur.slu.se (8.8.7/8.8.7) id KAA15426; Sat, 16 Feb 2002 10:55:59 +0100 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15470.11439.308754.898395@robur.slu.se> Date: Sat, 16 Feb 2002 10:55:59 +0100 To: Jason Lunz Cc: netdev@oss.sgi.com Subject: NAPI question about old drivers In-Reply-To: <20020215185646.GA6614@trellisinc.com> References: <20020215185646.GA6614@trellisinc.com> X-Mailer: VM 6.92 under Emacs 19.34.1 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 526 Lines: 23 Jason Lunz writes: > > I'm reading the NAPI patch and I don't understand how old drivers can > continue to work. > what happens to legacy drivers that don't set dev->poll? I see > netif_rx() has been modified, but drivers that call that and don't have > a dev->poll will be in trouble when net_rx_action() runs. All netif_rx drivers are handled as one common net_device with name blog_dev it's defined in struct softnet_data. It's "dev->poll" method is process_backlog in dev.c. Cheers. --ro From owner-netdev@oss.sgi.com Sat Feb 16 12:01:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1GK1CS31377 for netdev-outgoing; Sat, 16 Feb 2002 12:01:12 -0800 Received: from luxik.cdi.cz (root@inway106.cdi.cz [213.151.81.106]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1GK17931367 for ; Sat, 16 Feb 2002 12:01:08 -0800 Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 16cA4z-0005yS-00; Sat, 16 Feb 2002 20:01:01 +0100 Date: Sat, 16 Feb 2002 20:01:00 +0100 (CET) From: Martin Devera To: Laurence cc: Netdev Subject: Re: about time measurement In-Reply-To: <200202161022.g1GAMP925927@oss.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 709 Lines: 24 > 1. In which file is "jiffies" defined? simple grep will reveal include/linux/sched.h file ;) > 2. What's the unit of "jiffies"? seconds, ms, or so?? in 1/HZ. And HZ is commonly 100 only 1024 on Alpha AFAIK. So typicaly one jiffie is 10ms. > 3. I want to compare the "jiffies" result to TCP_TIMEWAIT_LEN, > which is defined in "include/net/tcp.h" as "(60*HZ)". What unit > conversion must I take to compare "jiffies" result with it?? as you can see above - none. 60*HZ is 60 seconds or 60000 jiffies in i386 system. > 4. If there are better ways, what're they? Depends on resolution you want. For sub milisecond precision use TSC (CPU clock precision). See psched_time_t - it might help you. devik From owner-netdev@oss.sgi.com Mon Feb 18 01:25:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1I9Pos14137 for netdev-outgoing; Mon, 18 Feb 2002 01:25:50 -0800 Received: from gw-nl5.philips.com (gw-nl5.philips.com [212.153.235.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1I9Pl914134 for ; Mon, 18 Feb 2002 01:25:48 -0800 Received: from smtpscan-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl5.philips.com with ESMTP id JAA26519 for ; Mon, 18 Feb 2002 09:25:45 +0100 (MET) (envelope-from clement.joseph@philips.com) From: clement.joseph@philips.com Received: from smtpscan-nl1.philips.com(130.139.36.21) by gw-nl5.philips.com via mwrap (4.0a) id xma026516; Mon, 18 Feb 02 09:25:45 +0100 Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id JAA08888 for ; Mon, 18 Feb 2002 09:25:45 +0100 (MET) Received: from ehv001soh.diamond.philips.com (e2soh01.diamond.philips.com [130.139.52.212]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id JAA28114 for ; Mon, 18 Feb 2002 09:25:44 +0100 (MET) Subject: Bridging + Routing by the same Linux box To: netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Mon, 18 Feb 2002 13:45:31 +0530 X-MIMETrack: Serialize by Router on ehv001soh/H/SERVER/PHILIPS(Release 5.0.5 |September 22, 2000) at 18/02/2002 09:26:28 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 381 Lines: 14 Hi Alan, I have a Linux box ( Red Hat Linux 7.1 ) with brctl bridging utility installed. ( Any other bridging utility available ? ) I want it to work as a bridge ( MAC bridge of course ) AND as a router ( IP forwarding ) ( and + Firewall + DHCP + DNS servers ) Please guide on how to do it. Some utilities available ? Thanks a lot, Clement Email: clement.joseph@philips.com From owner-netdev@oss.sgi.com Mon Feb 18 08:42:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IGgx205145 for netdev-outgoing; Mon, 18 Feb 2002 08:42:59 -0800 Received: from plastic.brain.org (217-127-0-54.uc.nombres.ttd.es [217.127.0.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IGgu905141 for ; Mon, 18 Feb 2002 08:42:56 -0800 Received: (qmail 10313 invoked by uid 500); 18 Feb 2002 16:21:47 -0000 Date: Mon, 18 Feb 2002 17:21:47 +0100 From: PaCoRRo To: netdev@oss.sgi.com Subject: Some questions about skbuff's Message-ID: <20020218172147.A25253@gueropa.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 374 Lines: 10 Hello, i'm writting to you because i sent this mail to Alan Cox and he gave me that email address. My problem is that i don't know how fix the pointers skb->data and skb->len and why of the instructions result. Can you explain me how i can fix that pointers depending type of packet and why of the instructions that fix them? Thank You PD: Sorry for my poor english From owner-netdev@oss.sgi.com Mon Feb 18 12:07:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IK7dF09031 for netdev-outgoing; Mon, 18 Feb 2002 12:07:39 -0800 Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IK5h909017 for ; Mon, 18 Feb 2002 12:05:43 -0800 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1IJ5TO10543; Mon, 18 Feb 2002 14:05:29 -0500 (EST) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1IJ5Ql18841; Mon, 18 Feb 2002 14:05:27 -0500 (EST) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1NNMFT96; Mon, 18 Feb 2002 14:05:23 -0500 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DW9QDXN1; Mon, 18 Feb 2002 14:05:26 -0500 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 27A15520D; Mon, 18 Feb 2002 14:13:24 -0500 (EST) Message-ID: <3C715253.A4DFD89B@nortelnetworks.com> Date: Mon, 18 Feb 2002 14:13:23 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: odd issue with sending to broadcast address Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1231 Lines: 33 It appears that there has been a change in the handling of sending packets to the broadcast IP address between 2.2 and 2.4. I have an embedded system that has only local LAN access, no default route to the net as a whole. We're running 2.2.17 currently, and we use bootpc to configure the system. We're now looking at converting to 2.4 and are running into a problem with bootpc getting "Network is unreachable" errors. After some digging, it appears to be due to the fact that I don't have a default route specified, but this is on purpose. strace shows that bootpc is trying to run sendto() with a destination of 255.255.255.255, and this works fine on 2.2 and fails on 2.4. Is this the desired 2.4 behaviour? What is the appropriate configuration for my setup? Do I just add a route to 255.255.255.255? Can I set it up to broadcast out all devices automatically, or do I need to do explicit failover management? Should I be looking to fix bootpc instead? Thanks, Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com From owner-netdev@oss.sgi.com Tue Feb 19 07:21:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JFLOo17278 for netdev-outgoing; Tue, 19 Feb 2002 07:21:24 -0800 Received: from mailer3.bham.ac.uk (mailer3.bham.ac.uk [147.188.128.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JFLK917274 for ; Tue, 19 Feb 2002 07:21:21 -0800 Received: from bham.ac.uk ([147.188.128.127]) by mailer3.bham.ac.uk with esmtp (Exim 3.16 #2) id 16dB8u-0005Fk-00 for netdev@oss.sgi.com; Tue, 19 Feb 2002 14:21:16 +0000 Received: from bham-eee-fs4.bham.ac.uk ([147.188.147.167]) by bham.ac.uk with esmtp (Exim 3.16 #3) id 16dB8u-0006pT-00 for netdev@oss.sgi.com; Tue, 19 Feb 2002 14:21:16 +0000 Received: by bham-eee-fs4.bham.ac.uk with Internet Mail Service (5.5.2653.19) id <1ZNQ7AS8>; Tue, 19 Feb 2002 14:21:15 -0000 Message-ID: <1396177A57E2D511A1EB0008C7866E1833DB4C@bham-eee-fs4.bham.ac.uk> From: "H143 (P.WITHEY)" To: "'netdev@oss.sgi.com'" Subject: reading header info from netif_rx Date: Tue, 19 Feb 2002 14:21:08 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 444 Lines: 18 Hi, Alan Cox advised me to use this address for this query. I am using a Kernel 2.2.16-22 loadable module to printk the skb->nh.iph->daddr & skb->h.th->seq from packets just before enqueue in netif_rx(). This is not giving the expected results. Are the above pointers correct? The following code is used: printk("%x %x\n", skb->nh.iph->daddr, skb->h.th->seq); I am hoping to use this to log the backlog queue usage. Thanks, Phil Withey From owner-netdev@oss.sgi.com Tue Feb 19 11:54:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JJsbW24118 for netdev-outgoing; Tue, 19 Feb 2002 11:54:37 -0800 Received: from plastic.brain.org (217-127-0-54.uc.nombres.ttd.es [217.127.0.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JJsX924115 for ; Tue, 19 Feb 2002 11:54:34 -0800 Received: (qmail 19307 invoked by uid 500); 19 Feb 2002 19:33:33 -0000 Date: Tue, 19 Feb 2002 20:33:33 +0100 From: PaCoRRo To: netdev@oss.sgi.com Subject: Re: Some questions about skbuff's Message-ID: <20020219203332.A11035@gueropa.com> References: <200202190220.g1J2Kb413551@host2.espaweb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200202190220.g1J2Kb413551@host2.espaweb.org>; from laudney@21cn.com on Tue, Feb 19, 2002 at 10:23:30AM +0800 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 820 Lines: 19 El Tue, 19 de Feb de 2002, a las 10:23:30AM +0800, Laurence dijo: > Sorry, although I'm quite clear about skb, I don't > understand your question clearly enough. You should > try to express your ideas more clearly. > > -- Laudney > > Ok, i will try to express the problem crealy. I have seen many examples with skbuff's and when a tcp packet arrives in the code appears... skb->h.raw = skb->nh.raw + skb->nh.iph->ihl*4; skb->data = (unsigned char *)skb->h.raw +(skb->h.th->doff <<2); skb->len -= skb->nh.iph->ihl*4 + (skb->h.th->doff <<2); and after these lines skb->data points to payload of the packet and skb->len contains length of packet payload. My problem is that i don't understand those lines, you can explain me? and if packet would be UDP or ICMP how can i put skb->data pointing to payload? Thanks You From owner-netdev@oss.sgi.com Tue Feb 19 17:26:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1K1Q5000448 for netdev-outgoing; Tue, 19 Feb 2002 17:26:05 -0800 Received: from fancypants.trellisinc.com (dsl-65-188-226-101.telocity.com [65.188.226.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1K1Pu900444 for ; Tue, 19 Feb 2002 17:25:56 -0800 Received: from aumshiva.localnet (unknown [192.168.0.106]) by fancypants.trellisinc.com (Postfix) with SMTP id BAE14A3C1E for ; Tue, 19 Feb 2002 19:25:54 -0500 (EST) Received: by aumshiva.localnet (sSMTP sendmail emulation); Tue, 19 Feb 2002 19:25:41 -0500 From: Jason Lunz Date: Tue, 19 Feb 2002 19:25:41 -0500 To: netdev@oss.sgi.com Subject: [PATCH] allow 0 protocol for bind() of packet sockets Message-ID: <20020220002541.GA26103@trellisinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2146 Lines: 72 When creating a packet socket, it is possible to defer receiving any packets on that socket by giving socket(2) 0 for the protocol: fd = socket(PF_PACKET, SOCK_RAW, 0); That socket can later set which protocol it will receive with bind(2): struct sockaddr_ll sl; memset(&sl, 0, sizeof(sl)); sl.sll_family = AF_PACKET; sl.sll_protocol = htons(ETH_P_ALL); sl.sll_ifindex = idx; bind(sd, (struct sockaddr*)&sl, sizeof(sl)); Repeated calls to bind(2) can change the protocol, but cannot set it back to zero to put the socket in its initial state. The patch below fixes this. The last hunk is the important one, and I don't understand why the ?: is there. Can someone tell me the reason to disallow a 0 protocol here? I couldn't find one, and running with this patch doesn't seem to affect any of my pcap-based applications. diff -ur linux-2.4.17/net/packet/af_packet.c linux.bindfix/net/packet/af_packet.c --- linux-2.4.17/net/packet/af_packet.c Tue Feb 12 13:13:30 2002 +++ linux.bindfix/net/packet/af_packet.c Tue Feb 19 19:20:56 2002 @@ -835,25 +835,19 @@ sk->protinfo.af_packet->running = 0; } + if (protocol == 0) + goto out_unlock; + sk->num = protocol; sk->protinfo.af_packet->prot_hook.type = protocol; sk->protinfo.af_packet->prot_hook.dev = dev; sk->protinfo.af_packet->ifindex = dev ? dev->ifindex : 0; - if (protocol == 0) - goto out_unlock; - - if (dev) { - if (dev->flags&IFF_UP) { - dev_add_pack(&sk->protinfo.af_packet->prot_hook); - sock_hold(sk); - sk->protinfo.af_packet->running = 1; - } else { - sk->err = ENETDOWN; - if (!sk->dead) - sk->error_report(sk); - } + if (dev && !(dev->flags&IFF_UP)) { + sk->err = ENETDOWN; + if (!sk->dead) + sk->error_report(sk); } else { dev_add_pack(&sk->protinfo.af_packet->prot_hook); sock_hold(sk); @@ -920,7 +914,7 @@ if (dev == NULL) goto out; } - err = packet_do_bind(sk, dev, sll->sll_protocol ? : sk->num); + err = packet_do_bind(sk, dev, sll->sll_protocol); if (dev) dev_put(dev); -- Jason Lunz Trellis Network Security j@trellisinc.com http://www.trellisinc.com/ From owner-netdev@oss.sgi.com Tue Feb 19 21:05:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1K55rL03038 for netdev-outgoing; Tue, 19 Feb 2002 21:05:53 -0800 Received: from arpabox ([210.52.204.84]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1K55f903035 for ; Tue, 19 Feb 2002 21:05:42 -0800 Message-Id: <200202200505.g1K55f903035@oss.sgi.com> Date: Wed, 20 Feb 2002 12:8:37 +0800 From: Laurence Reply-To: laudney@21cn.com To: "netdev@oss.sgi.com" Subject: Re: Some questions about skbuff's Organization: SJTU X-mailer: FoxMail 4.0 beta 1 [cn] Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2553 Lines: 83 >Ok, i will try to express the problem crealy. >I have seen many examples with skbuff's and when a tcp packet arrives in the code appears... >skb->h.raw = skb->nh.raw + skb->nh.iph->ihl*4; >skb->data = (unsigned char *)skb->h.raw +(skb->h.th->doff <<2); >skb->len -= skb->nh.iph->ihl*4 + (skb->h.th->doff <<2); >and after these lines skb->data points to payload of the packet and skb->len contains length >of packet payload. >My problem is that i don't understand those lines, you can explain me? and if packet would be >UDP or ICMP how can i put skb->data pointing to payload? > >Thanks You Yeh, PaCoRRo, this time your question is clear enough!! Let me quote part of struct sk_buff{} first: struct sk_buff { .. /* Transport Layer header */ union { struct tcphdr *th; .. unsigned char *raw; } h; /* Network Layer header */ union { struct iphdr *iph; .. unsigned char *raw; } nh; .. } When yuo get a TCP packet, you have IP header + TCP header + data. skb->nh.raw points to the very beginning of this packet, ie. the very beginning of the IP header (since IP header is at the very front). skb->nh.iph->ihl is "IP header length" expressed in units of 32 bits, or 4 chars' length (since one char is one byte long). Thus, skb->nh.iph->ihl*4 is the legnth of the IP header expressed in bytes. Look, since skb->h.raw and skb->nh.raw are "unsigned char *" pointers, the conversion above is necessary. So, "skb->h.raw = skb->nh.raw + skb->nh.iph->ihl*4;" makes skb->h.raw points to the very start of TCP header. skb->h.th->doff can be considered the length of TCP header expressed in units of 32 bits, or 4 chars' length (just like above). skb->h.th->doff<<2 equals skb->h.th->doff*4 in effects, but much faster. Therefore, "skb->data = (unsigned char *)skb->h.raw +(skb->h.th->doff <<2);" makes skb->data points to the very start of data. "skb->len -= skb->nh.iph->ihl*4 + (skb->h.th->doff <<2);" subtracts IP and TCP header length from skb->len. From then on, skb->len represents the length of "pure data". If you receive UDP packets, simply change everything associated with TCP above (like TCP header, TCP header len) into UDP related. But, ICMP is different, since ICMP is a netowork-layer protocol. A ICMP packet encapsulated in IP header is like this: IP header + ICMP packet. A ICMP packet is like this: 8-bit type + 8-bit code + 16-bit checksum + various content It has no "len". So, simply do the following: skb->data = (unsigned char *)skb->nh.raw + skb->nh.iph->ihl*4; skb->len -= skb->nh.iph->ihl*4 -- Laudney From owner-netdev@oss.sgi.com Tue Feb 19 22:05:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1K657B03788 for netdev-outgoing; Tue, 19 Feb 2002 22:05:07 -0800 Received: from 21cn.com ([61.140.60.248]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1K64s903784 for ; Tue, 19 Feb 2002 22:04:55 -0800 Message-Id: <200202200604.g1K64s903784@oss.sgi.com> Received: from arpabox([210.52.203.44]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm483c73507c; Wed, 20 Feb 2002 13:01:27 +0800 Date: Wed, 20 Feb 2002 13:7:36 +0800 From: Laurence Reply-To: laudney@21cn.com To: "netdev@oss.sgi.com" , "netdev@oss.sgi.com" Subject: Re: [PATCH] allow 0 protocol for bind() of packet sockets Organization: SJTU X-mailer: FoxMail 4.0 beta 1 [cn] Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2165 Lines: 87 After reading the patch, I found some problems. 1. The patch doesn't allow "protocol == 0" either, even exit the funtion at an earlier stage by shifting the place of "if (protocol == 0) goto out_unlock;" forward. 2. all the bulk changes to the codes of if(dev) { .. } are simply an optimization. No content change at all!! 3. According to my understanding, I have made some modifications. Hope that works. First, maintain the following modification that's present in your patch: @@ -920,7 +914,7 @@ if (dev == NULL) goto out; } - err = packet_do_bind(sk, dev, sll->sll_protocol ? : sk->num); + err = packet_do_bind(sk, dev, sll->sll_protocol); if (dev) dev_put(dev); Then, the following is my packet_do_bind() funtion in net/packet/af_packet.c static int packet_do_bind(struct sock *sk, struct net_device *dev, int protocol) { /* * Detach an existing hook if present. */ lock_sock(sk); spin_lock(&sk->protinfo.af_packet->bind_lock); if (sk->protinfo.af_packet->running) { dev_remove_pack(&sk->protinfo.af_packet->prot_hook); __sock_put(sk); sk->protinfo.af_packet->running = 0; } /* Think about the meaning of "err = packet_do_bind(sk, dev, sll->sll_protocol ? : sk->num);" * If sll->sll_protocol==0, the parameter "protocol" in this funtion equals sk->num, * which means, sk->num is actually not modified. So, only sk->num = protocol when */ protocol != 0 if (protocol != 0) sk->num = protocol; sk->protinfo.af_packet->prot_hook.type = protocol; sk->protinfo.af_packet->prot_hook.dev = dev; sk->protinfo.af_packet->ifindex = dev ? dev->ifindex : 0; if (dev) { if (dev->flags&IFF_UP) { dev_add_pack(&sk->protinfo.af_packet->prot_hook); sock_hold(sk); sk->protinfo.af_packet->running = 1; } else { sk->err = ENETDOWN; if (!sk->dead) sk->error_report(sk); } } else { dev_add_pack(&sk->protinfo.af_packet->prot_hook); sock_hold(sk); sk->protinfo.af_packet->running = 1; } /* since protocol == 0, no hook should exist */ if (protocol == 0) sk->protinfo.af_packet->running = 0; out_unlock: spin_unlock(&sk->protinfo.af_packet->bind_lock); release_sock(sk); return 0; } From owner-netdev@oss.sgi.com Wed Feb 20 03:02:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KB2Hr08836 for netdev-outgoing; Wed, 20 Feb 2002 03:02:17 -0800 Received: from luxik.cdi.cz (root@inway106.cdi.cz [213.151.81.106]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KB2E908832 for ; Wed, 20 Feb 2002 03:02:15 -0800 Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 16dTZV-0004EJ-00; Wed, 20 Feb 2002 11:01:57 +0100 Date: Wed, 20 Feb 2002 11:01:57 +0100 (CET) From: Martin Devera To: "H143 (P.WITHEY)" cc: "'netdev@oss.sgi.com'" Subject: Re: reading header info from netif_rx In-Reply-To: <1396177A57E2D511A1EB0008C7866E1833DB4C@bham-eee-fs4.bham.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 374 Lines: 12 > I am using a Kernel 2.2.16-22 loadable module to printk the > skb->nh.iph->daddr & skb->h.th->seq from packets just before enqueue in > netif_rx(). > > This is not giving the expected results. Are the above pointers correct? Just quick idea .. where did you placed your printk ? netif_rx usualy happens at places where skb->{h,nh} are not set properly up yet. devik From owner-netdev@oss.sgi.com Wed Feb 20 03:35:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KBZKP09659 for netdev-outgoing; Wed, 20 Feb 2002 03:35:20 -0800 Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KBZG909656 for ; Wed, 20 Feb 2002 03:35:16 -0800 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1KAaqg76567 for ; Wed, 20 Feb 2002 11:36:53 +0100 (CET) (envelope-from Atif.Syed@ccrle.nec.de) Received: from zark (zark.mobility.ccrle.nec.de [192.168.101.95]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id LAA32088 for ; Wed, 20 Feb 2002 11:35:08 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Atif Syed Organization: NEC To: netdev@oss.sgi.com Subject: Problem with skb pointer! Date: Wed, 20 Feb 2002 11:39:15 +0100 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <02022011391500.00699@zark> Content-Transfer-Encoding: 8bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 844 Lines: 30 Dear all, I am writting a module. This module has very easy task to buffer 5 incoming packets and the next coming packet(6th) to buffer at 1st packet and send 1st packet changing the dst and src addresses. I have declared pointer array with 5 pointers. The buffering of 5 packets has done. But when the 6th packet comes, kernel hangs up!! What i am doing is that i save 1st packet (sk_buff) to a new temporary pointer and send it changing the dst and src addresses. it follows: struct sk_buff *skb_new[5]; struct sk_buff *temp2=NULL; temp2=skb_new[counter2]; skb_new[counter2]=skb; This means i point to sk_buff with temp2, before it was skb_new[counter2]. Could u please tell me if any thing is wrong in this matter? Thanks in advance -- Atif Syed(student) NEC Europe Ltd. - Network Laboratories Email: Atif.Syed@ccrle.nec.de From owner-netdev@oss.sgi.com Wed Feb 20 04:01:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KC1lJ10364 for netdev-outgoing; Wed, 20 Feb 2002 04:01:47 -0800 Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KC1i910361 for ; Wed, 20 Feb 2002 04:01:44 -0800 Received: from fwd02.sul.t-online.de by mailout08.sul.t-online.com with smtp id 16dUVK-0004mE-04; Wed, 20 Feb 2002 12:01:42 +0100 Received: from there (320016507023-0001@[217.233.254.254]) by fwd02.sul.t-online.com with smtp id 16dUUy-05p3DMC; Wed, 20 Feb 2002 12:01:20 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Joachim.Franek@t-online.de (Joachim Franek) Reply-To: joachim.franek@t-online.de Organization: IBJF To: Atif Syed , netdev@oss.sgi.com Subject: Re: Problem with skb pointer! Date: Wed, 20 Feb 2002 12:01:13 +0100 X-Mailer: KMail [version 1.3.1] References: <02022011391500.00699@zark> In-Reply-To: <02022011391500.00699@zark> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <16dUUy-05p3DMC@fwd02.sul.t-online.com> X-Sender: 320016507023-0001@t-dialin.net Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 410 Lines: 18 Hello. Am Mittwoch, 20. Februar 2002 11:39 schrieb Atif Syed: > struct sk_buff *skb_new[5]; > struct sk_buff *temp2=NULL; > > temp2=skb_new[counter2]; > skb_new[counter2]=skb; > > This means i point to sk_buff with temp2, before it was skb_new[counter2]. > Could u please tell me if any thing is wrong in this matter? Maybe counter2 not in range 0..4? -- Joachim Franek www.de-franek.de rs485.de-franek.de From owner-netdev@oss.sgi.com Wed Feb 20 10:44:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KIinF23302 for netdev-outgoing; Wed, 20 Feb 2002 10:44:49 -0800 Received: from preshak.recjai.ac.in ([210.212.99.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KIiN923296 for ; Wed, 20 Feb 2002 10:44:46 -0800 Received: from recjai.ac.in (localhost.localdomain [127.0.0.1]) by preshak.recjai.ac.in (8.11.2/8.11.2) with SMTP id g1KHrvN05117 for ; Wed, 20 Feb 2002 23:23:57 +0530 Received: from 192.168.250.51 (SquirrelMail authenticated user anjan) by mail.recjai.ac.in with HTTP; Wed, 20 Feb 2002 23:23:57 +0530 (IST) Message-ID: <4526.192.168.250.51.1014227637.squirrel@mail.recjai.ac.in> Date: Wed, 20 Feb 2002 23:23:57 +0530 (IST) Subject: =?iso-8859-1?Q?help_on_sk=5Fbuff?= From: "=?iso-8859-1?Q?Anjaneya_Pal?=" To: netdev@oss.sgi.com X-Mailer: SquirrelMail (version 1.0.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 232 Lines: 12 dear sir, i am really stuck with implementing sk_buff on linux. can you please suggest me any books or links from where i can get the help? thanx in advance. anjan -- Anjaneya Pal Electronics & Comm. Engg. Final Year. REC-Jaipur From owner-netdev@oss.sgi.com Wed Feb 20 16:20:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1L0KW800370 for netdev-outgoing; Wed, 20 Feb 2002 16:20:32 -0800 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1L0KP900367 for ; Wed, 20 Feb 2002 16:20:25 -0800 Received: from alan by the-village.bc.nu with local (Exim 3.33 #5) id 16dgGA-00057e-00 for netdev@oss.sgi.com; Wed, 20 Feb 2002 23:34:50 +0000 Received: from vger.kernel.org ([12.107.208.194]) by the-village.bc.nu with esmtp (Exim 3.33 #5) id 16dfL6-0004xI-00 for alan@lxorguk.ukuu.org.uk; Wed, 20 Feb 2002 22:35:54 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 20 Feb 2002 17:20:09 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 20 Feb 2002 17:19:59 -0500 Received: from palrel10.hp.com ([156.153.255.245]:918 "HELO palrel10.hp.com") by vger.kernel.org with SMTP id ; Wed, 20 Feb 2002 17:19:45 -0500 Received: from colosus1.cup.hp.com (colosus1.cup.hp.com [15.13.128.63]) by palrel10.hp.com (Postfix) with ESMTP id DEFFCC0017D; Wed, 20 Feb 2002 14:19:39 -0800 (PST) Received: from hplnx1.cup.hp.com (IDENT:root@hplnx1.cup.hp.com [15.13.133.222]) by colosus1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id OAA02668; Wed, 20 Feb 2002 14:19:39 -0800 (PST) Received: from cup.hp.com (IDENT:llaborde@hplnx1.cup.hp.com [15.13.133.222]) by hplnx1.cup.hp.com (8.11.6/8.8.7) with ESMTP id g1KEIuZ27744; Wed, 20 Feb 2002 14:18:56 GMT Message-ID: <3C73B050.5050400@cup.hp.com> Date: Wed, 20 Feb 2002 14:18:56 +0000 From: Louis Laborde Organization: Hewlett Packard (SISL) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Linux Kernel Mailing List Cc: icsc-socketwg@opengroup.org Subject: socket API extensions workgroup at OpenGroup needs HELP Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailing-List: linux-kernel@vger.kernel.org Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1613 Lines: 39 The OpenGroup InterConnect Software Consortium has started a working group to propose extensions to the current Unix socket API and is seeking help from the open source community. These extensions (ideas floating around are, but not limited to: asynchronous paradigm to enable zero copy, I/O completion ports, advance buffer registration to allow pinning and I/O preparation, ...) would enable new networking technologies (Infiniband, RDMA, ...) and would allow Unix to regain the lead over Winsock in terms of functionality and performance. The OpenGroup is trying to figure out how to include the open source community in these activities. It is actively seeking the people who are the Linux, FreeBSD, ..., thought leaders and implementors for networking and sockets, and bring them into the working group. Interested people should contact the working group co-chairs for details about how to join the effort: David Edmondson (david.edmondson@sun.co) or Satya Sharma (ssharma@us.ibm.com) The URL of the OpenGroup Interconnect Software Consortium is: http://www.opengroup.org/icsc/ Thanks for volunteering. +---------------------------------------------------------+ | Louis LABORDE e-mail: llaborde@cup.hp.com | | HP Cupertino SISL phone: (408) 447-3649 | +---------------------------------------------------------+ - 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 Feb 20 17:18:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1L1IWi01097 for netdev-outgoing; Wed, 20 Feb 2002 17:18:32 -0800 Received: from dea.linux-mips.net (a1as20-p220.stg.tli.de [195.252.194.220]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1L1IH901093 for ; Wed, 20 Feb 2002 17:18:18 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1L0IB622434 for netdev@oss.sgi.com; Thu, 21 Feb 2002 01:18:11 +0100 Received: from fancypants.trellisinc.com (dsl-65-188-226-101.telocity.com [65.188.226.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KI60922638 for ; Wed, 20 Feb 2002 10:06:01 -0800 Received: from aumshiva.localnet (unknown [192.168.0.106]) by fancypants.trellisinc.com (Postfix) with SMTP id 50F76A3C1E; Wed, 20 Feb 2002 12:05:59 -0500 (EST) Received: by aumshiva.localnet (sSMTP sendmail emulation); Wed, 20 Feb 2002 12:05:57 -0500 Date: Wed, 20 Feb 2002 12:05:57 -0500 From: Jason Lunz To: laudney@21cn.com Cc: netdev@oss.sgi.com Subject: Re: [PATCH] allow 0 protocol for bind() of packet sockets Message-ID: <20020220170557.GA27818@trellisinc.com> References: <200202200604.g1K64s903784@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200202200604.g1K64s903784@oss.sgi.com> User-Agent: Mutt/1.3.27i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1132 Lines: 35 laudney@21cn.com said: > After reading the patch, I found some problems. > 1. The patch doesn't allow "protocol == 0" either, even exit the > funtion at an earlier stage by shifting the place of > "if (protocol == 0) > goto out_unlock;" > forward. That's the point. The patch allows one to remove a socket from the ptype_all list (or ptype_base hash) after it's been added. Userspace can make the socket active again by binding to an actual protocol, like ETH_P_ALL. > 2. all the bulk changes to the codes of > if(dev) { > .. > } > are simply an optimization. No content change at all!! true. maybe I should remove that; I just thought it was just ugly having the same block in two places when one would do. > /* since protocol == 0, no hook should exist */ > if (protocol == 0) > sk->protinfo.af_packet->running = 0; this is wrong. af_packet->running indicates whether the socket is in the ptype_all list or the ptype_base hash (read the rest of af_packet.c). You break this here by setting running to 0 without actually removing it. -- Jason Lunz Trellis Network Security j@trellisinc.com http://www.trellisinc.com/ From owner-netdev@oss.sgi.com Thu Feb 21 07:18:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1LFING24126 for netdev-outgoing; Thu, 21 Feb 2002 07:18:23 -0800 Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1LFII924119 for ; Thu, 21 Feb 2002 07:18:18 -0800 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1LEKig15993 for ; Thu, 21 Feb 2002 15:20:44 +0100 (CET) (envelope-from Atif.Syed@ccrle.nec.de) Received: from zark (zark.mobility.ccrle.nec.de [192.168.101.95]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id PAA17455 for ; Thu, 21 Feb 2002 15:18:06 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Atif Syed Organization: NEC To: netdev@oss.sgi.com Subject: skb_copy(....) ? Date: Thu, 21 Feb 2002 15:22:20 +0100 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <02022115222000.00810@zark> Content-Transfer-Encoding: 8bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 406 Lines: 23 Dear all, I am trying to copy sk_buffer. skb_new=alloc_skb(sizeof(struct sk_buff) , GFP_ATOMIC); skb_new=pskb_copy(skb,GFP_KERNEL); These lines make hang the kernel. Should i have to allocate memory or only copy the skb to the new one. I am confused after reading the documentation. Thanks in advance for help. Atif Syed NEC Europe Ltd. - Network Laboratories Email: Atif.Syed@ccrle.nec.de From owner-netdev@oss.sgi.com Thu Feb 21 07:34:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1LFYwL29759 for netdev-outgoing; Thu, 21 Feb 2002 07:34:58 -0800 Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1LFYr929714 for ; Thu, 21 Feb 2002 07:34:54 -0800 Received: from fwd09.sul.t-online.de by mailout10.sul.t-online.com with smtp id 16duJ9-0006V4-0D; Thu, 21 Feb 2002 15:34:51 +0100 Received: from there (320016507023-0001@[217.233.248.97]) by fwd09.sul.t-online.com with smtp id 16duIz-1kgzZYC; Thu, 21 Feb 2002 15:34:41 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Joachim.Franek@t-online.de (Joachim Franek) Reply-To: joachim.franek@t-online.de Organization: IBJF To: netdev@oss.sgi.com Subject: Re: skb_copy(....) ? Date: Thu, 21 Feb 2002 15:33:00 +0100 X-Mailer: KMail [version 1.3.1] References: <02022115222000.00810@zark> In-Reply-To: <02022115222000.00810@zark> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <16duIz-1kgzZYC@fwd09.sul.t-online.com> X-Sender: 320016507023-0001@t-dialin.net Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 842 Lines: 35 Am Donnerstag, 21. Februar 2002 15:22 schrieb Atif Syed: > Dear all, > > I am trying to copy sk_buffer. > > > skb_new=alloc_skb(sizeof(struct sk_buff) , GFP_ATOMIC); > skb_new=pskb_copy(skb,GFP_KERNEL); > > These lines make hang the kernel. Should i have to allocate memory or only > copy the skb to the new one. I am confused after reading the > documentation. > > Thanks in advance for help. > > > Atif Syed > NEC Europe Ltd. - Network Laboratories > > Email: Atif.Syed@ccrle.nec.de Have a look at: http://lxr.linux.no/source/ choose "identifier search", and search for "pskb_copy". If you choose kernel 2.4.16 (and i386) you get the source code position: net/core/skbuff.c, line 559 . Click on this link and see, that alloc is done. BTW: thanks, I just need this function also. -- Joachim Franek www.de-franek.de rs485.de-franek.de From owner-netdev@oss.sgi.com Thu Feb 21 15:48:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1LNmdk14702 for netdev-outgoing; Thu, 21 Feb 2002 15:48:39 -0800 Received: from www.linux.org.uk (IDENT:exim@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1LNmY914699 for ; Thu, 21 Feb 2002 15:48:34 -0800 Received: from adsl-33-99-211.asm.bellsouth.net ([67.33.99.211] helo=mandrakesoft.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 16e20u-0008Sa-00; Thu, 21 Feb 2002 22:48:32 +0000 Message-ID: <3C75793B.1BFF7A1A@mandrakesoft.com> Date: Thu, 21 Feb 2002 17:48:27 -0500 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17-2mdksmp i686) X-Accept-Language: en MIME-Version: 1.0 To: Linux-Kernel list CC: netdev@oss.sgi.com Subject: eepro100 (was Re: Linux 2.4.18-rc3) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 775 Lines: 29 Marcelo Tosatti wrote: > rc3: > - Fix some eepro100 ID's which had problems > in -ac merge (Jeff Garzik) > - Add missing netif_carrier_{on,off} to > eepro100 (Andrew Morton) > rc1: > - eepro100 fixes (Jeff Garzik) eepro100 users, If you can spare some time, please test and compare 2.4.17 and 2.4.18-rc3 kernel versions, for (a) regressions in performance/behavior, and (b) -fixed- or improved behavior. Feedback and further testing sought. Regards, Jeff -- Jeff Garzik | XXX FREE! secure AFSPC AK-47 unclassified CDC Building 1024 | NATO SAS CDMA fun with filters Bellcore kibo SSL MandrakeSoft | high security goat clones infowar 2600 Magazine From owner-netdev@oss.sgi.com Thu Feb 21 16:11:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1M0B3B15186 for netdev-outgoing; Thu, 21 Feb 2002 16:11:03 -0800 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1M0B0915176 for ; Thu, 21 Feb 2002 16:11:01 -0800 Received: from alan by the-village.bc.nu with local (Exim 3.33 #5) id 16e2aJ-00007x-00; Thu, 21 Feb 2002 23:25:07 +0000 Subject: Re: eepro100 (was Re: Linux 2.4.18-rc3) To: jgarzik@mandrakesoft.com (Jeff Garzik) Date: Thu, 21 Feb 2002 23:25:07 +0000 (GMT) Cc: linux-kernel@vger.kernel.org (Linux-Kernel list), netdev@oss.sgi.com In-Reply-To: <3C75793B.1BFF7A1A@mandrakesoft.com> from "Jeff Garzik" at Feb 21, 2002 05:48:27 PM X-Mailer: ELM [version 2.5 PL6] 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 Content-Length: 372 Lines: 12 > eepro100 users, > > If you can spare some time, please test and compare 2.4.17 and > 2.4.18-rc3 kernel versions, for (a) regressions in performance/behavior, > and (b) -fixed- or improved behavior. Just glancing over the code - shouldnt it use pci_enable device before checking the regions its assigned ? Also it seems to include linux/delay.h twice J Random Pedant From owner-netdev@oss.sgi.com Thu Feb 21 16:15:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1M0FvA15347 for netdev-outgoing; Thu, 21 Feb 2002 16:15:57 -0800 Received: from www.linux.org.uk (IDENT:exim@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1M0Fs915344 for ; Thu, 21 Feb 2002 16:15:54 -0800 Received: from adsl-33-99-211.asm.bellsouth.net ([67.33.99.211] helo=mandrakesoft.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 16e2RM-0001FE-00; Thu, 21 Feb 2002 23:15:52 +0000 Message-ID: <3C757FA7.BFD51A03@mandrakesoft.com> Date: Thu, 21 Feb 2002 18:15:51 -0500 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17-2mdksmp i686) X-Accept-Language: en MIME-Version: 1.0 To: Alan Cox CC: Linux-Kernel list , netdev@oss.sgi.com Subject: Re: eepro100 (was Re: Linux 2.4.18-rc3) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 616 Lines: 19 Alan Cox wrote: > > > eepro100 users, > > > > If you can spare some time, please test and compare 2.4.17 and > > 2.4.18-rc3 kernel versions, for (a) regressions in performance/behavior, > > and (b) -fixed- or improved behavior. > > Just glancing over the code - shouldnt it use pci_enable device before > checking the regions its assigned ? > > Also it seems to include linux/delay.h twice indeed, thanks.. -- Jeff Garzik | XXX FREE! secure AFSPC AK-47 unclassified CDC Building 1024 | NATO SAS CDMA fun with filters Bellcore kibo SSL MandrakeSoft | high security goat clones infowar 2600 Magazine From owner-netdev@oss.sgi.com Fri Feb 22 01:30:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1M9UXd26588 for netdev-outgoing; Fri, 22 Feb 2002 01:30:33 -0800 Received: from mail.assyrus.it ([217.56.204.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1M9UR926584 for ; Fri, 22 Feb 2002 01:30:27 -0800 Received: from assyrus.it ([217.56.205.246]) by mail.assyrus.it (8.11.6/8.11.6) with ESMTP id g1M8B8013986; Fri, 22 Feb 2002 09:11:08 +0100 Message-ID: <3C75FD1B.AC1999B5@assyrus.it> Date: Fri, 22 Feb 2002 09:11:07 +0100 From: Fabrizio Morbini X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: IPv6 implementation... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1914 Lines: 51 Hi at all, I'm testing IPv6 (and I'm not an expert) I have encountered a problem and after an exchange of some mail with the autor of the IPv6 HowTo (Peter Bieringer) I have decided to ask you: #situation -gateway kernel 2.4.8 of Mandrake 8.1; IPv6 in IPv4 tunnel with freenet6.net and /48 network; -clients kernel 2.4.17 from www.kernel.org; one of the /48 address; #problem -on the gateway all runs fine for example: ping6 ftp6.edisontel.com -on the clients ping6 ftp6.edisontel.com receive from the gateway the response: Destination unreachable: Address unreachable. IPv6 forwarding is enabled. The problem was resolved adding the line route -Ainet6 add 2000::/3 dev sit1 to the gateway routing table. The strange behaviour is: [IPv6 icmp6 packet] ->from the client to the gateway-> the gateway open the packet see the destination address: 2001:750:2:0:202:a5ff:fefb:49ec see it's routing table and then respond to the client: >From 3ffe:b80:8a9:1::1: Destination unreachable: Address unreachable (3ffe:b80:8a9:1::1 is the gateway) But if the packet is generated by the gateway (change only the source address): the kernel add the necessary routing line into the routing table and all runs fine. Why the kernel doesn't add this line also when the source address of the packet isn't one of it's network interfaces? (the line added is: 2001:750:2:0:202:a5ff:fefb:49ec/128 2001:750:2:0:202:a5ff:fefb:49ec UC 0 2 1 sit1 ) The question is: Tcpdump doesn't report useful information (it's sniffing is: 09:05:08.711200 3ffe:b80:8a9:1:250:baff:fe0e:4d52 > 2001:750:2:0:202:a5ff:fefb:49ec: icmp6: echo request 09:05:08.711311 3ffe:b80:8a9:1::1 > 3ffe:b80:8a9:1:250:baff:fe0e:4d52: [|icmp6]) How I can view why the packet from the clients doesn't follow the same behaviour of the packet created directly on the gateway? Thank you very much for any help and Best Regards. Fabrizio From owner-netdev@oss.sgi.com Fri Feb 22 10:07:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MI7HU16589 for netdev-outgoing; Fri, 22 Feb 2002 10:07:17 -0800 Received: from chiriko (eatkyo029053.adsl.ppp.infoweb.ne.jp [61.124.137.53]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MI7D916586 for ; Fri, 22 Feb 2002 10:07:13 -0800 Received: from chiriko.linux-ipv6.org (chiriko [127.0.0.1]) by chiriko (Postfix) with ESMTP id 79BB430127; Sat, 23 Feb 2002 02:07:07 +0900 (JST) Date: Sat, 23 Feb 2002 02:07:07 +0900 Message-ID: <87vgcpa1j8.wl@chiriko.linux-ipv6.org> From: Yuji Sekiya To: Fabrizio Morbini Cc: netdev@oss.sgi.com Subject: Re: IPv6 implementation... In-Reply-To: <3C75FD1B.AC1999B5@assyrus.it> References: <3C75FD1B.AC1999B5@assyrus.it> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386-debian-linux-gnu) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1199 Lines: 34 At Fri, 22 Feb 2002 09:11:07 +0100, Fabrizio Morbini wrote: Hello, > The strange behaviour is: > [IPv6 icmp6 packet] ->from the client to the gateway-> the gateway open > the packet see the destination address: 2001:750:2:0:202:a5ff:fefb:49ec > see it's routing table and then respond to the client: > From 3ffe:b80:8a9:1::1: Destination unreachable: Address unreachable > (3ffe:b80:8a9:1::1 is the gateway) > But if the packet is generated by the gateway (change only the source > address): the kernel add the necessary routing line into the > routing table and all runs fine. Why the kernel doesn't add this line > also when the source address of the packet isn't one of it's > network interfaces? It is a specification of Linux kernel. If you would like to change the behavior, please try to use USAGI kernel, you can get it from http://www.linux-ipv6.org/. Enabling CONFIG_IPV6_EN_DFLT, your linux router can forward packets to the nexthop of default route. I made the change before, but it didn't work correctly. Then I have impremented the change again and I have got correct behavior. Please try our patch and report the result. Thanks. -- Yuji Sekiya From owner-netdev@oss.sgi.com Fri Feb 22 17:16:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1N1GPV28281 for netdev-outgoing; Fri, 22 Feb 2002 17:16:25 -0800 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1N1GK928278 for ; Fri, 22 Feb 2002 17:16:21 -0800 Received: from alan by the-village.bc.nu with local (Exim 3.33 #5) id 16eQ5W-0003cn-00 for netdev@oss.sgi.com; Sat, 23 Feb 2002 00:30:54 +0000 Received: from vger.kernel.org ([12.107.208.194]) by the-village.bc.nu with esmtp (Exim 3.33 #5) id 16eOtw-0003SC-00 for alan@lxorguk.ukuu.org.uk; Fri, 22 Feb 2002 23:14:54 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 22 Feb 2002 17:57:51 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 22 Feb 2002 17:57:42 -0500 Received: from amdext.amd.com ([139.95.251.1]:7115 "EHLO amdext.amd.com") by vger.kernel.org with ESMTP id ; Fri, 22 Feb 2002 17:57:31 -0500 Received: from ssvlgs01.amd.com (ssvlgs01.amd.com [139.95.250.16]) by amdext.amd.com (8.9.3/8.9.3/AMD) with SMTP id OAA26640 for ; Fri, 22 Feb 2002 14:57:25 -0800 (PST) From: harish.vasudeva@amd.com Received: from 139.95.250.1 by ssvlgs01.amd.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.7)); Fri, 22 Feb 2002 14:57:24 -0800 X-Server-Uuid: 02753650-11b0-11d5-bbc5-00508bf987eb Received: from caexmta9.amd.com (caexmta9.amd.com [139.95.53.55]) by amdint.amd.com (8.9.3/8.9.3/AMD) with ESMTP id OAA06732 for ; Fri, 22 Feb 2002 14:57:24 -0800 (PST) Received: by caexmta9.amd.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 14:57:23 -0800 Message-ID: To: linux-kernel@vger.kernel.org Subject: Need some help with IP/TCP Checksum Offload Date: Fri, 22 Feb 2002 14:57:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1068135E4865599-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailing-List: linux-kernel@vger.kernel.org Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 811 Lines: 21 Hi All, I am trying to offload checksum calculation to my hardware. What i am doing in my driver (kernel 2.4.6) is : dev->features = NETIF_F_IP_CHECKSUM; Then, in my start_xmit( ) routine, i am parsing for the right headers & when i get the IP/TCP header, i print out the checksum & it is already the right checksum. When does the OS/Protocol offload this task? Am i missing something here? thanx for your help HARISH V Enterprise Connectivity Solutions, AMD (408) 749-3324 (Work) * Knowledge becomes wisdom only after it has been put to practical use. * - 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 Sat Feb 23 00:27:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1N8RdH01719 for netdev-outgoing; Sat, 23 Feb 2002 00:27:39 -0800 Received: from iisc.ernet.in (iisc.ernet.in [144.16.64.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1N8RT901715 for ; Sat, 23 Feb 2002 00:27:31 -0800 Received: from eis.iisc.ernet.in (eis.iisc.ernet.in [144.16.64.5]) by iisc.ernet.in (8.9.2/8.9.0) with SMTP id NAA64818 for ; Sat, 23 Feb 2002 13:06:04 +0530 (IST) Received: by eis.iisc.ernet.in (SMI-8.6/SMI-4.1) id MAA25607; Sat, 23 Feb 2002 12:57:23 +0530 From: anand@eis.iisc.ernet.in (SVR Anand) Message-Id: <200202230727.MAA25607@eis.iisc.ernet.in> Subject: Dynamic access lists To: netdev@oss.sgi.com Date: Sat, 23 Feb 2002 12:57:23 +0530 (GMT+05:30) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2857 Lines: 60 Hi, I work in one ISP that serves a university campus connected on a LAN, apart from many other customers. We have a congested internet access link, thanks to the student community. Because of this, customers as well as the university faculty are complaining of poor throughputs. One of the professors suggested that faculty should be given a better bandwidth by imposing some kind of traffic control on the student traffic. In this regard I plan to implement the following idea. I will be happy to receive your feedback. Thanks for patiently reading my rather big mail. Hope I could express my idea clearly, and pardon me if this is not the appropriate mailing list. Thought this might be of interest to you all! Regards Anand ---------------------------------------------------------------------------- 1. Put a Linux box in the path of the traffic just before it hits the access router. After coming up with some packet classification scheme, control the rates using Linux TC. 2. I have observed that packet classification based on pre-registered static IP addresses has many difficulties. These include, i) Faculty are forced to use the machine they have registered. Maintenance of static addresses can be painful because whenever they migrate to another machine, or operate from a different Lab the IP address is going to change. ii) Static addressing will not work when DHCP is used iii) Students tend to "mis-use" faculty's machine in their absence by using masquerading/login mechanisms iv) In the long run, there will be many unused stale IP addresses clogging the classifier table which can potentially be exploited 3. To combat the fore mentioned issues, I am thinking of coming up with dynamic access lists with user authentication. There will be a notion of "soft session" in the system. It is expected to work as follows. - The faculty will initially register themselves with a server by giving password - Whenever he/she wants to access network, they will create "soft session" by means of authentication by the server. This can happen in the browser environment. During the authentication process, the faculty machine's IP address is obtained and passed onto the Linux box that is running TC - Linux box will update the faculty-classifier dynamically 4. After done with net access the faculty is expected to logout of the session. The logging out process accordingly removes the entry in the Linux TC. - In case the logout is not done explicitly, as it can happen with pre-occupied professors :), a timeout mechanism can be built into the system which will automatically purges the IP address of the idle session I have not mentioned the nitty-gritty details because I wanted to know if the basic idea is fine. From owner-netdev@oss.sgi.com Sat Feb 23 02:28:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1NASWl03432 for netdev-outgoing; Sat, 23 Feb 2002 02:28:32 -0800 Received: from titan.bieringer.de (mail.bieringer.de [195.226.187.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1NASP903428 for ; Sat, 23 Feb 2002 02:28:26 -0800 Received: (qmail 27932 invoked from network); 23 Feb 2002 09:28:18 -0000 Received: from pd9e4ef33.dip.t-dialin.net (HELO ??) (217.228.239.51) by mail.bieringer.de with SMTP; 23 Feb 2002 09:28:18 -0000 Date: Sat, 23 Feb 2002 10:28:46 +0100 From: Peter Bieringer To: SVR Anand , netdev@oss.sgi.com Subject: Re: Dynamic access lists Message-ID: <41960000.1014456526@localhost> In-Reply-To: <200202230727.MAA25607@eis.iisc.ernet.in> References: <200202230727.MAA25607@eis.iisc.ernet.in> X-Mailer: Mulberry/2.2.0b2 (Linux/x86) X-Echelon: GRU NSA GCHQ CIA Pentagon nuclear war terror anthrax X-URL: http://www.bieringer.de/pb/ X-OS: Linux MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 555 Lines: 18 --On Saturday, February 23, 2002 12:57:23 PM +0530 SVR Anand wrote: ...sure an very offtopic answer, but perhaps interesting. I've heard this week that commercial firewall Check Point FW-1 Next Generation Flood Gate will (already or soon) support QoS based on User Authentication combined with VPN. The only Linux related things: * you can install the firewall (even flood gate) on Linux systems using kernel 2.4.x * a commandline VPN client will be availabe Q2 or so (but don't if here the QoS is supported. Peter From owner-netdev@oss.sgi.com Sat Feb 23 09:00:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1NH0GL08439 for netdev-outgoing; Sat, 23 Feb 2002 09:00:16 -0800 Received: from mail.telpin.com.ar ([200.43.18.243]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1NH09908436 for ; Sat, 23 Feb 2002 09:00:10 -0800 Received: from telpin.com.ar (dsl-200-43-19-190.users.telpin.com.ar [200.43.19.190]) by mail.telpin.com.ar (8.12.1/8.12.1) with SMTP id g1NFt81S022578; Sat, 23 Feb 2002 12:55:08 -0300 Date: Sat, 23 Feb 2002 12:55:06 -0300 From: Alberto Bertogli To: Peter Bieringer Cc: SVR Anand , netdev@oss.sgi.com Subject: Re: Dynamic access lists Message-ID: <20020223125506.A200@telpin.com.ar> Mail-Followup-To: Alberto Bertogli , Peter Bieringer , SVR Anand , netdev@oss.sgi.com References: <200202230727.MAA25607@eis.iisc.ernet.in> <41960000.1014456526@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <41960000.1014456526@localhost>; from pb@bieringer.de on Sat, Feb 23, 2002 at 10:28:46AM +0100 X-RAVMilter-Version: 8.3.0(snapshot 20010925) (mail) Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1360 Lines: 39 On Sat, Feb 23, 2002 at 10:28:46AM +0100, Peter Bieringer wrote: > --On Saturday, February 23, 2002 12:57:23 PM +0530 SVR Anand > wrote: > > ...sure an very offtopic answer, but perhaps interesting. > > I've heard this week that commercial firewall Check Point FW-1 Next > Generation Flood Gate will (already or soon) support QoS based on > User Authentication combined with VPN. > > The only Linux related things: > > * you can install the firewall (even flood gate) on Linux systems > using kernel 2.4.x > * a commandline VPN client will be availabe Q2 or so (but don't if > here the QoS is supported. > > Peter If you do your VPNs using PPTP (or PPP/anything) you can easily filter over them using the network interface ppp?. Remember you can combine netfilter's capability with TC filters by MARKing the packets with NF and then using that mark with TC. Also, if you use PPTP, you can in turn write a simple plugin for pppd that would create a new rule (either via netfilter or tc) to match the packets. If you don't use VPN at all, but dhcp instead or any kind of authentication scheme, you can script the creation of the rule on the connection. Use the source =) At the end, it's all just simple scripting if you have the code. Obviously, if you are stucked with checkpoint, it wont be so nice =) Alberto From owner-netdev@oss.sgi.com Sun Feb 24 13:53:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1OLree06446 for netdev-outgoing; Sun, 24 Feb 2002 13:53:40 -0800 Received: from cheltenham.cs.arizona.edu (cheltenham.CS.Arizona.EDU [192.12.69.60]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1OLrb906442 for ; Sun, 24 Feb 2002 13:53:37 -0800 Received: from lectura.CS.Arizona.EDU (lectura.CS.Arizona.EDU [192.12.69.186]) by cheltenham.cs.arizona.edu (8.11.1/8.11.1) with ESMTP id g1OKtUD02309 for ; Sun, 24 Feb 2002 13:55:31 -0700 (MST) Received: from localhost (jarango@localhost) by lectura.CS.Arizona.EDU (8.10.2+Sun/8.10.2) with ESMTP id g1OKrTF29951 for ; Sun, 24 Feb 2002 13:53:29 -0700 (MST) X-Authentication-Warning: lectura.CS.Arizona.EDU: jarango owned process doing -bs Date: Sun, 24 Feb 2002 13:53:28 -0700 (MST) From: "Jesus M. Arango" To: Subject: network code documentation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 449 Lines: 12 Hello, I am adding some new functionality to the linux network code. What do you think is the best source of documentation on the details of the network code, specially those parts related to routing/forwarding? Perhaps some type of up-to-date commentary of the networt source code. Basically, something that would help me understand the code faster then by just reading the code by myself and figuring out and guessing the details. Thanks Jesus From owner-netdev@oss.sgi.com Mon Feb 25 06:55:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1PEtKV06291 for netdev-outgoing; Mon, 25 Feb 2002 06:55:20 -0800 Received: from coruscant.gnumonks.org (mail@coruscant.franken.de [193.174.159.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1PEtD906270 for ; Mon, 25 Feb 2002 06:55:13 -0800 Received: from uucp by coruscant.gnumonks.org with local-bsmtp (Exim 3.33 #1) id 16fLaw-0004C7-00 for netdev@oss.sgi.com; Mon, 25 Feb 2002 14:55:10 +0100 Received: from laforge by sunbeam.gnumonks.org with local (Exim 3.34 #1) id 16fLN1-00082V-00 for netdev@oss.sgi.com; Mon, 25 Feb 2002 14:40:47 +0100 Date: Mon, 25 Feb 2002 14:40:47 +0100 From: Harald Welte To: netdev@oss.sgi.com Subject: RFC iptables target for selectively removing ECN Message-ID: <20020225144047.Z23307@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i X-Operating-System: Linux sunbeam.de.gnumonks.org 2.4.17 X-Date: Today is Setting Orange, the 50th day of Chaos in the YOLD 3168 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1931 Lines: 44 Hi! I've written a small iptables target for the iptables 'mangle' chain, which allows users to remove the ECN bits of the IPv4 header ::on a per-rule basis. It forces the ECN bits of the IPv4 header to codepoint 00 == not-ECT as well as the two ECN bits in the TCP header to 00; This allows users to selectively work around ECN blackholes. Currently you basically have the following options: a) Turn ECN on and complain to the respective admins for all blackholes you find. This is the optimum case. Unfortunately you don't always succeed in convincing them that it's their fault. I'm personally going for this 'option' for quite some time - with varying results. This is not an option for most people. b) Turn off ECN and don't care about the whole discussion With ECN turned off on lots of theoretically ECN-capable hosts, the deployment of ECN will be much slower than it could be. This is what most people (and vendors) are currently doing. Very unfortunate. My iptables target would add a new option c) Generally enable ECN, but have a small blacklist of sites / networks which are known ECN blackholes. IMHO, this approach combines the advantages of a) and b). People can activate ECN, and add a per-host no-ecn rule in case they detect blackholes and can't LART the responsible administrators who cause the blackhole. The question is: Would this iptables extension be considered a candidate for inclusion in the stock kernel? It's evil, I know. But on the other hand very useful :) If yes, I'll submit it to DaveM for kernel inclusion. -- Live long and prosper - Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/ ============================================================================ GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M+ V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*) From owner-netdev@oss.sgi.com Mon Feb 25 09:32:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1PHW3g21880 for netdev-outgoing; Mon, 25 Feb 2002 09:32:03 -0800 Received: from iisc.ernet.in (www-cache.iisc.ernet.in [144.16.64.3] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1PHVr921877 for ; Mon, 25 Feb 2002 09:31:56 -0800 Received: from eis.iisc.ernet.in (eis.iisc.ernet.in [144.16.64.5]) by iisc.ernet.in (8.9.2/8.9.0) with SMTP id WAA35720; Mon, 25 Feb 2002 22:10:24 +0530 (IST) Received: by eis.iisc.ernet.in (SMI-8.6/SMI-4.1) id WAA18445; Mon, 25 Feb 2002 22:01:45 +0530 From: anand@eis.iisc.ernet.in (SVR Anand) Message-Id: <200202251631.WAA18445@eis.iisc.ernet.in> Subject: Re: Dynamic access lists To: pb@bieringer.de (Peter Bieringer) Date: Mon, 25 Feb 2002 22:01:45 +0530 (GMT+05:30) Cc: netdev@oss.sgi.com In-Reply-To: <41960000.1014456526@localhost> from "Peter Bieringer" at Feb 23, 2002 10:28:46 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1255 Lines: 35 Peter, Thanks for your response. It is an interesting coincidence that Check Point is coming up with QoS based on user authentication soon. Not sure if they have a notion of soft session though, which is important, and useful in my scenario. The approach I am suggesting is mainly inspired by RSVP, but without any explicit signaling, and state maintenance in the form of periodic updates. A simple authentication mechanism with a provision for dynamic updation of filters within Linux TC, hopefully, is all that is required to accomplish the intended task. Presently, I am looking at conventional internet access without any configured VPN. Anand > > --On Saturday, February 23, 2002 12:57:23 PM +0530 SVR Anand > wrote: > > ...sure an very offtopic answer, but perhaps interesting. > > I've heard this week that commercial firewall Check Point FW-1 Next > Generation Flood Gate will (already or soon) support QoS based on > User Authentication combined with VPN. > > The only Linux related things: > > * you can install the firewall (even flood gate) on Linux systems > using kernel 2.4.x > * a commandline VPN client will be availabe Q2 or so (but don't if > here the QoS is supported. > > Peter > From owner-netdev@oss.sgi.com Mon Feb 25 09:45:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1PHj7M22256 for netdev-outgoing; Mon, 25 Feb 2002 09:45:07 -0800 Received: from iisc.ernet.in (www-cache.iisc.ernet.in [144.16.64.3] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1PHiu922222 for ; Mon, 25 Feb 2002 09:44:57 -0800 Received: from eis.iisc.ernet.in (eis.iisc.ernet.in [144.16.64.5]) by iisc.ernet.in (8.9.2/8.9.0) with SMTP id WAA36708; Mon, 25 Feb 2002 22:23:27 +0530 (IST) Received: by eis.iisc.ernet.in (SMI-8.6/SMI-4.1) id WAA18555; Mon, 25 Feb 2002 22:14:48 +0530 From: anand@eis.iisc.ernet.in (SVR Anand) Message-Id: <200202251644.WAA18555@eis.iisc.ernet.in> Subject: Re: Dynamic access lists To: albertogli@telpin.com.ar (Alberto Bertogli) Date: Mon, 25 Feb 2002 22:14:47 +0530 (GMT+05:30) Cc: netdev@oss.sgi.com In-Reply-To: <20020223125506.A200@telpin.com.ar> from "Alberto Bertogli" at Feb 23, 2002 12:55:06 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1938 Lines: 56 Alberto, Thanks for your mail! I am actually not looking at VPN/PPP kind of scenario. A plain campus LAN on which some of the hosts get great service without their knowledge :), Of course only after they get authenticated. As you rightly pointed out a simple scripting might suffice to begin with. Since I have to deal with host idle times to update my filters in TC, per-host "last heard from" information is necessary. Don't you feel I am proposing something out of the world ?! :) Anand > > On Sat, Feb 23, 2002 at 10:28:46AM +0100, Peter Bieringer wrote: > > --On Saturday, February 23, 2002 12:57:23 PM +0530 SVR Anand > > wrote: > > > > ...sure an very offtopic answer, but perhaps interesting. > > > > I've heard this week that commercial firewall Check Point FW-1 Next > > Generation Flood Gate will (already or soon) support QoS based on > > User Authentication combined with VPN. > > > > The only Linux related things: > > > > * you can install the firewall (even flood gate) on Linux systems > > using kernel 2.4.x > > * a commandline VPN client will be availabe Q2 or so (but don't if > > here the QoS is supported. > > > > Peter > > If you do your VPNs using PPTP (or PPP/anything) you can easily filter > over them using the network interface ppp?. > > Remember you can combine netfilter's capability with TC filters by > MARKing the packets with NF and then using that mark with TC. > > Also, if you use PPTP, you can in turn write a simple plugin for pppd > that would create a new rule (either via netfilter or tc) to match the > packets. > > If you don't use VPN at all, but dhcp instead or any kind of > authentication scheme, you can script the creation of the rule on the > connection. Use the source =) > > At the end, it's all just simple scripting if you have the code. > Obviously, if you are stucked with checkpoint, it wont be so nice =) > > Alberto > > From owner-netdev@oss.sgi.com Mon Feb 25 11:20:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1PJKvG26884 for netdev-outgoing; Mon, 25 Feb 2002 11:20:57 -0800 Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1PJJ0926871 for ; Mon, 25 Feb 2002 11:19:01 -0800 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1PIIqa27654; Mon, 25 Feb 2002 13:18:52 -0500 (EST) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1PIImY18686; Mon, 25 Feb 2002 13:18:49 -0500 (EST) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FSG73ZWX; Mon, 25 Feb 2002 13:18:48 -0500 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FQT67L0N; Mon, 25 Feb 2002 13:18:43 -0500 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 671E35A3; Mon, 25 Feb 2002 13:27:07 -0500 (EST) Message-ID: <3C7A81FB.346BB9CD@nortelnetworks.com> Date: Mon, 25 Feb 2002 13:27:07 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: SVR Anand Cc: netdev@oss.sgi.com Subject: Re: Dynamic access lists References: <200202230727.MAA25607@eis.iisc.ernet.in> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1387 Lines: 31 SVR Anand wrote: > > Hi, > > I work in one ISP that serves a university campus connected on a LAN, apart > from many other customers. We have a congested internet access link, thanks to > the student community. Because of this, customers as well as the university > faculty are complaining of poor throughputs. One of the professors suggested > that faculty should be given a better bandwidth by imposing some kind of > traffic control on the student traffic. In this regard I plan to implement the > following idea. Hmm...as a former student I'm not sure I like the idea of faculty getting better net access than students. The students are paying for access through their tuition costs, the professors get it as part of their job. Now granted, there will likely be more potential abusers of bandwidth in the student population, but why not divide available bandwidth based on demand? You might want to consider tracking machines that tend to have a lot of traffic, and making them lower priority. This would cut down on the impact of perpetual abusers. This is where a table of known exceptions might be handy (web servers, etc.). -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com From owner-netdev@oss.sgi.com Mon Feb 25 14:54:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1PMsgo31799 for netdev-outgoing; Mon, 25 Feb 2002 14:54:42 -0800 Received: from coruscant.datenknoten.de (p3E9BB9B4.dip.t-dialin.net [62.155.185.180]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1PMsa931794 for ; Mon, 25 Feb 2002 14:54:39 -0800 Received: from coruscant.datenknoten.de (coruscant.datenknoten.de [127.0.0.1]) by coruscant.datenknoten.de (Postfix) with SMTP id 63996FA0; Mon, 25 Feb 2002 22:47:21 +0100 (CET) Date: Mon, 25 Feb 2002 22:47:21 +0100 From: Sebastian To: "Harald Welte" Cc: netdev@oss.sgi.com Subject: Re: RFC iptables target for selectively removing ECN Message-Id: <20020225224721.020ccfe4.sebastian+list02@datenknoten.de> In-Reply-To: <20020225144047.Z23307@sunbeam.de.gnumonks.org> References: <20020225144047.Z23307@sunbeam.de.gnumonks.org> X-Mailer: Sylpheed version 0.6.5claws25 (GTK+ 1.2.10; i386-debian-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 Content-Length: 882 Lines: 18 Hi! On Mon, 25 Feb 2002 14:40:47 +0100 "Harald Welte" wrote: > I've written a small iptables target for the iptables 'mangle' chain, > which allows users to remove the ECN bits of the IPv4 header ::on a > per-rule basis. So this target is doing what is described in section 18.1.13 of RFC 3168. You might run into a problem when an upstream router marked the packet instead of dropping it. By setting the codepoint to 0, you will remove the congestion indication. This will not be a problem if you only use this target on outgoing packets and if you don't have a marking router in the inner network. Otherwise it will be one. Since you don't know what people will do with this target and if they really understand what it does, I fear that it might become a problem. Instead, I suggest to only clear the ECE and CWR TCP flags on SYN-packets. Sebastian From owner-netdev@oss.sgi.com Mon Feb 25 19:40:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1Q3eZp05847 for netdev-outgoing; Mon, 25 Feb 2002 19:40:35 -0800 Received: from mail.telpin.com.ar ([200.43.18.243]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1Q3eL905843 for ; Mon, 25 Feb 2002 19:40:24 -0800 Received: from telpin.com.ar (dsl-200-43-19-190.users.telpin.com.ar [200.43.19.190]) by mail.telpin.com.ar (8.12.1/8.12.1) with SMTP id g1Q2c51S000991; Mon, 25 Feb 2002 23:38:09 -0300 Date: Mon, 25 Feb 2002 23:38:04 -0300 From: Alberto Bertogli To: SVR Anand Cc: netdev@oss.sgi.com Subject: Re: Dynamic access lists Message-ID: <20020225233804.A463@telpin.com.ar> Mail-Followup-To: Alberto Bertogli , SVR Anand , netdev@oss.sgi.com References: <20020223125506.A200@telpin.com.ar> <200202251644.WAA18555@eis.iisc.ernet.in> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200202251644.WAA18555@eis.iisc.ernet.in>; from anand@eis.iisc.ernet.in on Mon, Feb 25, 2002 at 10:14:47PM +0530 X-RAVMilter-Version: 8.3.0(snapshot 20010925) (mail) Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1176 Lines: 31 On Mon, Feb 25, 2002 at 10:14:47PM +0530, SVR Anand wrote: > Alberto, > > Thanks for your mail! > > I am actually not looking at VPN/PPP kind of scenario. A plain campus LAN on > which some of the hosts get great service without their knowledge :), Of course > only after they get authenticated. As you rightly pointed out a simple > scripting might suffice to begin with. Since I have to deal with host > idle times to update my filters in TC, per-host "last heard from" information > is necessary. Don't underestimate the power of the scripts. You can handle this scenario using scripts and a web interface to start/stop the session in an incredibly clean and efficient way. If you are thinking about something even more clean, PPPoE is exactly what you want: individual authenticated tunnels through a lan that end in your router, where you do the link to the internet. You can do all that with linux, without needing an expensive and closed firewall which has limited capability. As for the PPPoE client, i found RASPPPoE to be a great choice. In fact, this scheme is pretty simmilar to a regular dsl connection, so there is nothing scary about it =) Alberto From owner-netdev@oss.sgi.com Tue Feb 26 02:25:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QAPUv09526 for netdev-outgoing; Tue, 26 Feb 2002 02:25:30 -0800 Received: from coruscant.gnumonks.org (mail@coruscant.franken.de [193.174.159.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QAPK909521 for ; Tue, 26 Feb 2002 02:25:22 -0800 Received: from uucp by coruscant.gnumonks.org with local-bsmtp (Exim 3.33 #1) id 16fdrH-0000Ot-00 for netdev@oss.sgi.com; Tue, 26 Feb 2002 10:25:15 +0100 Received: from laforge by sunbeam.gnumonks.org with local (Exim 3.34 #1) id 16fdf1-0000EQ-00; Tue, 26 Feb 2002 10:12:35 +0100 Date: Tue, 26 Feb 2002 10:12:35 +0100 From: Harald Welte To: Sebastian Cc: netdev@oss.sgi.com Subject: Re: RFC iptables target for selectively removing ECN Message-ID: <20020226101235.G23307@sunbeam.de.gnumonks.org> References: <20020225144047.Z23307@sunbeam.de.gnumonks.org> <20020225224721.020ccfe4.sebastian+list02@datenknoten.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20020225224721.020ccfe4.sebastian+list02@datenknoten.de>; from sebastian+list02@datenknoten.de on Mon, Feb 25, 2002 at 10:47:21PM +0100 X-Operating-System: Linux sunbeam.de.gnumonks.org 2.4.17 X-Date: Today is Setting Orange, the 50th day of Chaos in the YOLD 3168 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1407 Lines: 33 On Mon, Feb 25, 2002 at 10:47:21PM +0100, Sebastian wrote: > So this target is doing what is described in section 18.1.13 of RFC 3168. Mh, I should have read the full RFC :(. > You might run into a problem when an upstream router marked the packet > instead of dropping it. By setting the codepoint to 0, you will remove the > congestion indication. This will not be a problem if you only use this target > on outgoing packets and if you don't have a marking router in the inner > network. Otherwise it will be one. Ok. Well, we could restrict the usage of the iptables target to the LOCAL_OUT hook, but this would limit its possibilities. > Since you don't know what people will do with this target and if they really > understand what it does, I fear that it might become a problem. > > Instead, I suggest to only clear the ECE and CWR TCP flags on SYN-packets. I don't need to clear the ECT codepoint in the IP header as well? Is it valid to receive an IP packet which has an ECT codepoint set in the IP header, but no ECE/CWR bits in the TCP headee? > Sebastian -- Live long and prosper - Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/ ============================================================================ GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M+ V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*) From owner-netdev@oss.sgi.com Tue Feb 26 03:45:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QBj5n12440 for netdev-outgoing; Tue, 26 Feb 2002 03:45:05 -0800 Received: from taifun.devconsult.de (taifun.devconsult.de [212.15.193.29]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QBj0912428 for ; Tue, 26 Feb 2002 03:45:01 -0800 Received: from devcon.net (lilly.ipv6.devcon.net [2001:658:210:4242::dead:beef]) by taifun.devconsult.de (8.11.6/8.11.6/af20010919) with ESMTP id g1QAiva25463 for ; Tue, 26 Feb 2002 11:44:57 +0100 Received: (qmail 2402 invoked by uid 0); 26 Feb 2002 10:44:57 -0000 Received: from unknown (HELO cooper.subway.devcon.net) (2001:658:210:4242:201:2ff:fe04:a7fe) by devcon.net with SMTP; 26 Feb 2002 10:44:57 -0000 Received: (from af@localhost) by cooper.subway.devcon.net (8.11.6/8.11.6) id g1QAiu421625; Tue, 26 Feb 2002 11:44:56 +0100 Date: Tue, 26 Feb 2002 11:44:56 +0100 From: Andreas Ferber To: Harald Welte Cc: Sebastian , netdev@oss.sgi.com Subject: Re: RFC iptables target for selectively removing ECN Message-ID: <20020226114456.A21475@devcon.net> References: <20020225144047.Z23307@sunbeam.de.gnumonks.org> <20020225224721.020ccfe4.sebastian+list02@datenknoten.de> <20020226101235.G23307@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020226101235.G23307@sunbeam.de.gnumonks.org>; from laforge@gnumonks.org on Tue, Feb 26, 2002 at 10:12:35AM +0100 Organization: dev/consulting GmbH X-NCC-RegID: de.devcon Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 882 Lines: 19 On Tue, Feb 26, 2002 at 10:12:35AM +0100, Harald Welte wrote: > > I don't need to clear the ECT codepoint in the IP header as well? Is it valid > to receive an IP packet which has an ECT codepoint set in the IP header, but no > ECE/CWR bits in the TCP headee? Yes. The ECN IP header bits are set by intermediate routers which are not required to examine the TCP header to tell if ECN should be used for this flow (e.g. in load-balancing or failover situations, they might not even see the SYN packet, so they have absolutely no way to tell if the connection endpoints are ECN capable). Indeed such a situation will be quite normal once ECN is widely deployed on internet core routers. Andreas -- Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG --------------------------------------------------------- +49 521 1365800 - af@devcon.net - www.devcon.net From owner-netdev@oss.sgi.com Tue Feb 26 05:37:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QDbEG15312 for netdev-outgoing; Tue, 26 Feb 2002 05:37:14 -0800 Received: from mail.et6.tu-harburg.de (pollux.et6.tu-harburg.de [134.28.85.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QDbB915306 for ; Tue, 26 Feb 2002 05:37:11 -0800 Received: from antares (antares.et6.tu-harburg.de [134.28.85.61]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mail.et6.tu-harburg.de (Postfix) with ESMTP id 3AC487F77; Tue, 26 Feb 2002 13:37:04 +0100 (CET) Date: Tue, 26 Feb 2002 13:37:03 +0100 From: Sebastian Zimmermann To: "Harald Welte" Cc: netdev@oss.sgi.com Subject: Re: RFC iptables target for selectively removing ECN Message-Id: <20020226133703.77d42344.sz@mail.et6.tu-harburg.de> In-Reply-To: <20020226101235.G23307@sunbeam.de.gnumonks.org> References: <20020225144047.Z23307@sunbeam.de.gnumonks.org> <20020225224721.020ccfe4.sebastian+list02@datenknoten.de> <20020226101235.G23307@sunbeam.de.gnumonks.org> Organization: FSP 4-06 X-Mailer: Sylpheed version 0.7.0claws (GTK+ 1.2.10; i386-debian-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 Content-Length: 808 Lines: 15 On Tue, 26 Feb 2002 10:12:35 +0100 "Harald Welte" wrote: >> Instead, I suggest to only clear the ECE and CWR TCP flags >> on SYN-packets. > > I don't need to clear the ECT codepoint in the IP header as well? Is > it valid to receive an IP packet which has an ECT codepoint set in the > IP header, but no ECE/CWR bits in the TCP header? The RFC states that SYN packets MUST NOT set ECT. So when the TCP connection is initiated, the ECN-capability is negotiated only by the two TCP flags ECE and CWR. If you clear those, ECN cannot be established. If ECN wasn't established, ECT MUST NOT be set on the following packets - and thus CE won't be set. So if the ECN implementation is conforming to the RFC, your target does not have to touch IP headers at all to disable ECN. Sebastian From owner-netdev@oss.sgi.com Tue Feb 26 07:28:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QFS6D22995 for netdev-outgoing; Tue, 26 Feb 2002 07:28:06 -0800 Received: from sa-usa-sj-po.siliconaccess.com (mail.siliconaccess.com [63.121.43.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QFS2922991 for ; Tue, 26 Feb 2002 07:28:03 -0800 Received: by sa-usa-sj-po.sanjose.siliconaccess.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Feb 2002 06:27:29 -0800 Message-ID: <39487C1D4449D41198960090270D93C0BB4983@sa-can-ott-po.ottawa.siliconaccess.com> From: Jamie Esliger To: "'netdev@oss.sgi.com'" Subject: Linux Question about snooping on ARP cache updates Date: Tue, 26 Feb 2002 06:27:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 922 Lines: 25 First, I'll apologize if you consider this spam. Now, to the point. I have an application that snoops on router table updates using the netlink socket. This is fine for IP routes, but I also need to snoop on updates to the ARP cache. I would like to know if you know of an interface I can use to listen for these updates. I have hunted through the code in net/ipv4 and net/core for awhile, and cannot find anything that sends this information up to an application. Do you know of a solution for this without watching all packets and parsing the ARP replies myself? I am trying "ARP Daemon" support (CONFIG_ARPD) but it is listed as obsolete and experimental, and I'm not sure that I can use this given I have to provide my application to many different customers, some of whom may not like the idea of using an "obsolete and experimental" kernel. Thanks, Jamie Esliger Network Software Engineer From owner-netdev@oss.sgi.com Tue Feb 26 16:16:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1R0GiV20153 for netdev-outgoing; Tue, 26 Feb 2002 16:16:44 -0800 Received: from bliss.commerce.uq.edu.au (IDENT:root@bliss.commerce.uq.edu.au [130.102.196.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1R0Ge920149 for ; Tue, 26 Feb 2002 16:16:40 -0800 Received: (from andy@localhost) by bliss.commerce.uq.edu.au (8.11.6/8.11.6/andy) id g1QNCit28708 for netdev@oss.sgi.com; Wed, 27 Feb 2002 09:12:44 +1000 Date: Wed, 27 Feb 2002 09:12:44 +1000 From: Andy Jones Message-Id: <200202262312.g1QNCit28708@bliss.commerce.uq.edu.au> To: netdev@oss.sgi.com Subject: Quick Question: Does Linux support bridging and firewalling at the same time? Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 817 Lines: 23 Hi I recently mailed Alan Cox asking him the exact same question and he referred me on to you. Hopefully you have a few moments to answer... It is my understanding that the firewalling and bridging code in the Linux kernel is mutually exclusive, though according to guides and HOWTOs etc on the net, it seems to be a metter of some confusion. Could you shed some light on whether it is, or isn't, and/or which patches need to be applied or whether it's simpler to just use some sort of BSD instead... cheers /\ndy ---- Andy Jones, Email: jones@commerce.uq.edu.au Computer Support Officer, Phone: (07) 3365 6652 School of Commerce, Fax: +61 7 3365 6788 University of Queensland. Quote: Kramer: "Pigman baby! PIGMAN!" Email should be easily readable. Proprietary file format attachments aren't. From owner-netdev@oss.sgi.com Tue Feb 26 18:26:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1R2QLb22885 for netdev-outgoing; Tue, 26 Feb 2002 18:26:21 -0800 Received: from comunit.de (comunit.de [195.21.213.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1R2QH922878 for ; Tue, 26 Feb 2002 18:26:17 -0800 Received: (qmail 6650 invoked by uid 517); 27 Feb 2002 01:26:00 -0000 Date: Wed, 27 Feb 2002 02:26:00 +0100 (CET) From: Sven Koch X-X-Sender: haegar@space.comunit.de To: Andy Jones cc: netdev@oss.sgi.com Subject: Re: Quick Question: Does Linux support bridging and firewalling at the same time? In-Reply-To: <200202262312.g1QNCit28708@bliss.commerce.uq.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 699 Lines: 23 On Wed, 27 Feb 2002, Andy Jones wrote: > It is my understanding that the firewalling and bridging code > in the Linux kernel is mutually exclusive, though according > to guides and HOWTOs etc on the net, it seems to be a metter > of some confusion. > > Could you shed some light on whether it is, or isn't, and/or > which patches need to be applied or whether it's simpler to > just use some sort of BSD instead... With a stock kernel, firewalling bridged connections is not possible. With the patch from http://bridge.sourceforge.net/download.html ist is. c'ya sven -- The Internet treats censorship as a routing problem, and routes around it. (John Gilmore on http://www.cygnus.com/~gnu/) From owner-netdev@oss.sgi.com Wed Feb 27 06:07:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1RE7e605191 for netdev-outgoing; Wed, 27 Feb 2002 06:07:40 -0800 Received: from dea.linux-mips.net (a1as06-p164.stg.tli.de [195.252.187.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1RE5n905167 for ; Wed, 27 Feb 2002 06:07:36 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1RBLta13566 for netdev@oss.sgi.com; Wed, 27 Feb 2002 12:21:55 +0100 Received: from globaledgesoft.com (PPP-200-4-12.bng.vsnl.net.in [203.200.4.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1R9l4931529 for ; Wed, 27 Feb 2002 01:47:05 -0800 Received: from globaledgesoft.com [172.16.2.27] by globaledgesoft.com [172.16.2.3] with SMTP (MDaemon.PRO.v5.0.0.R) for ; Wed, 27 Feb 2002 14:14:37 +0530 Message-ID: <3C7C9C25.257C0281@globaledgesoft.com> Date: Wed, 27 Feb 2002 14:13:17 +0530 From: Nagaraj Y S Reply-To: nagaraj@globaledgesoft.com Organization: Global Edge Software Limited X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: why sl_ioctl() called when ioctl on ttyS is done? Content-Type: multipart/alternative; boundary="------------FC7D6BD6F0DA525247D6BADF" X-MDRemoteIP: 172.16.2.27 X-Return-Path: nagaraj@globaledgesoft.com X-MDaemon-Deliver-To: netdev@oss.sgi.com Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2227 Lines: 66 --------------FC7D6BD6F0DA525247D6BADF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, I am trying to trace the series of operation in setting up slip network interface. I tried to insert slip (modified, with 15 as the line disc num) as a insertable module and then did a cutomised slattach for /dev/ttyS1, which calls ioctl with TIOCSETD and with 15 as disc num. But the flow seems to enter sl_iotcl also, which I think will be called from core net device's do_ioctl function ptr only. The calling sequence is this as I observed. my iotcl syscall -> tiocsetd() in tty_io.c -> tty_set_ldisc() -> tty->driver.set_ldisc() Can anybody tell me where is this case the set_ldisc() function defined? Thanks in advance, Nagaraj. [I could trace this with lot of printk's in all the functions of modified slip.c] -- -------------------------------------- God made machine language; all the rest is the work of man. --------------------------------------/usr/games/fortune --------------FC7D6BD6F0DA525247D6BADF Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all,

I am trying to trace the series of operation in setting up slip network interface.

I tried to insert slip (modified, with 15 as the line disc num) as a insertable module and then did a cutomised slattach for /dev/ttyS1, which calls ioctl with TIOCSETD and with 15 as disc num.

But the flow seems to enter sl_iotcl also, which I think will be called from core
net device's do_ioctl function ptr only.

The calling sequence is this as I observed.
my iotcl syscall -> tiocsetd() in tty_io.c -> tty_set_ldisc() -> tty->driver.set_ldisc()
Can anybody tell me where is this case the set_ldisc() function defined?
Thanks in advance,
Nagaraj.

[I could trace this with lot of printk's in all the functions of modified slip.c] 

-- 
--------------------------------------
God made machine language; all the rest is the work of man.
--------------------------------------/usr/games/fortune
  --------------FC7D6BD6F0DA525247D6BADF--