From kuznet@ms2.inr.ac.ru Wed Jan 1 17:33:51 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jan 2003 17:33:55 -0800 (PST) Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h021Xn3v012401 for ; Wed, 1 Jan 2003 17:33:50 -0800 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id EAA32608; Thu, 2 Jan 2003 04:38:46 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200301020138.EAA32608@sex.inr.ac.ru> Subject: Re: snd_cwnd drawn and quartered To: wa@almesberger.NET (Werner Almesberger) Date: Thu, 2 Jan 2003 04:38:46 +0300 (MSK) Cc: netdev@oss.sgi.com In-Reply-To: <20021224225040.A22201@almesberger.net> from "Werner Almesberger" at Dec 25, 2 05:15:00 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 1433 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Hello! > if (decr && tp->snd_cwnd > tp->snd_ssthresh/2) > tp->snd_cwnd -= decr; > > Unfortunately, snd_ssthresh has already been halved at this > point, so the test actually does nothing. It does the thing which it is supposed to do: prevents reducing cwnd below 1/4 of original one. This was proposed in one of rete-halving related drafts with title sort of "...boundary checks...", I forgot exact title, can find it if you are curious. > if (decr && tp->snd_cwnd > tp->snd_ssthresh) Maybe this is even correct, but I do not see why it can be essential. cwnd falls too low not due to decrementing due to rate-halving, but due to draining out in_flight when we are not able to keep pipe full. Please, show. Alexey From werner@almesberger.net Wed Jan 1 22:03:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jan 2003 22:03:57 -0800 (PST) Received: from host.almesberger.net (IDENT:SHRRRDIx5HxixFvsKBmDyk0gN0WIRyQm@almesberger.net [63.105.73.239] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0263p3v016008 for ; Wed, 1 Jan 2003 22:03:52 -0800 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.9.3/8.9.3) with ESMTP id WAA16499; Wed, 1 Jan 2003 22:09:07 -0800 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id h0268wT29925; Thu, 2 Jan 2003 03:08:58 -0300 Date: Thu, 2 Jan 2003 03:08:58 -0300 From: Werner Almesberger To: kuznet@ms2.inr.ac.ru Cc: netdev@oss.sgi.com, chengjin@cs.caltech.edu Subject: Re: snd_cwnd drawn and quartered Message-ID: <20030102030858.E1363@almesberger.net> References: <20021224225040.A22201@almesberger.net> <200301020138.EAA32608@sex.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200301020138.EAA32608@sex.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Thu, Jan 02, 2003 at 04:38:46AM +0300 X-archive-position: 1434 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wa@almesberger.net Precedence: bulk X-list: netdev kuznet@ms2.inr.ac.ru wrote: > It does the thing which it is supposed to do: prevents reducing cwnd below > 1/4 of original one. Okay, this it does. I guess the only case where this would make a difference is if your network duplicates packets. > This was proposed in one of rete-halving related drafts > with title sort of "...boundary checks...", I forgot exact title, can find > it if you are curious. I searched around but didn't spot anything. A pointer would be welcome, thanks ! > Maybe this is even correct, but I do not see why it can be essential. > cwnd falls too low not due to decrementing due to rate-halving, > but due to draining out in_flight when we are not able to keep pipe full. Yes, but rate-halving is what causes in-flight to drop in the first place (assuming we have enough fresh data to send, of course), no ? > Please, show. I've put graphs of a simulation run (with and without the change) at http://www.almesberger.net/misc/half.eps http://www.almesberger.net/misc/quarter.eps Y-axis is in segments, x-axis is in some arbitrary time unit, RTT is one initial cwnd (100 packets), path is asymmetric with zero-delay and loss-less backward channel. (While unusual, this shouldn't actually affect what TCP does in recovery.) Losses happen right before the packet hits the receiver. I've also asked Cheng if he can send you a copy of his simulator. Thanks, - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From werner@almesberger.net Thu Jan 2 00:25:58 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jan 2003 00:26:05 -0800 (PST) Received: from host.almesberger.net (IDENT:e5/zUTK8+gw0dZKKWaqibyHg0efwYLIB@almesberger.net [63.105.73.239] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h028Pv3v017441 for ; Thu, 2 Jan 2003 00:25:57 -0800 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.9.3/8.9.3) with ESMTP id AAA17020; Thu, 2 Jan 2003 00:31:10 -0800 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id h028V2P30778; Thu, 2 Jan 2003 05:31:02 -0300 Date: Thu, 2 Jan 2003 05:31:02 -0300 From: Werner Almesberger To: kuznet@ms2.inr.ac.ru Cc: netdev@oss.sgi.com, chengjin@cs.caltech.edu Subject: Re: snd_cwnd drawn and quartered Message-ID: <20030102053102.A30750@almesberger.net> References: <20021224225040.A22201@almesberger.net> <200301020138.EAA32608@sex.inr.ac.ru> <20030102030858.E1363@almesberger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030102030858.E1363@almesberger.net>; from wa@almesberger.net on Thu, Jan 02, 2003 at 03:08:58AM -0300 X-archive-position: 1435 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wa@almesberger.net Precedence: bulk X-list: netdev I wrote: > Okay, this it does. I guess the only case where this would make a > difference is if your network duplicates packets. ... and, of course, when losing retransmitted segments, oops. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From sp@scali.com Thu Jan 2 04:59:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jan 2003 04:59:20 -0800 (PST) Received: from elin.scali.no (IDENT:root@elin.scali.no [62.70.89.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h02CxC3v027337 for ; Thu, 2 Jan 2003 04:59:14 -0800 Received: from sp-laptop.isdn.scali.no (sp-laptop.isdn.scali.no [192.168.1.67]) by elin.scali.no (8.12.3/8.12.3) with ESMTP id h02D4KZL018857; Thu, 2 Jan 2003 14:04:20 +0100 Date: Thu, 2 Jan 2003 14:06:41 +0100 (CET) From: Steffen Persvold X-X-Sender: sp@sp-laptop.isdn.scali.no To: linux-kernel@vger.kernel.org, cc: netdev@oss.sgi.com Subject: One-way Gigabit Ethernet TCP performance with Jumbo frames In-Reply-To: <3E142D85.71FFA06C@digeo.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463794943-2128730964-1041512801=:18738" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-archive-position: 1436 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sp@scali.com Precedence: bulk X-list: netdev 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. ---1463794943-2128730964-1041512801=:18738 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi all, Lately I've been testing out two Gigabit Ethernet adapters on Pentium 4 Xeon platforms; onboard Intel 82544GC (e1000 driver) and onboard Broadcom BCM5701 (tg3 driver), and I'm experiencing some wierd behaviour on one-way tests (ping-ping). The machines I'm testing is connected back to back (i.e no switch) and are fairly fast systems (Dual Xeon 2.4 GHz, 1GB memory) configured to use Jumbo frames (9000 bytes). With ping-pong traffic (the attached program run with -bo, or NetPipe default) the bandwidth performance is close to wire speed (123 MByte/sec) and the ping-pong/2 latency is ~30us with both GbE devices. But, when running a one-way test (where one machine only sends, and the other only receives, i.e ping-ping) there is a serious dip in the performance curve at ~768 bytes and the bandwidth levels out at approx 60 MByte/sec (about half of peak) regadless of application and GbE device. However, if the benchmark applications are started at 2048 bytes (and not 0 which is default), or the MTU is set to standard 1500 bytes, there is no such "dip" in the performance curve. Is there a new "silly window" syndrome going on here ? Both applications use TCP_NODELAY. I'll appreciate any feedback, and I'm happy to assist in the debugging process testing out patches etc. PS Attached you'll find a yet another "bandwidth" program which measures TCP performance i three ways; ping-ping (one-way), ping-pong, and exchange (two way). Should compile fine with gcc -O2, and you must start a server process (-Ts) on one machine and a client process (-Tc -s ) on the other machine. DS Best regards, -- Steffen Persvold | Scali AS mailto:sp@scali.com | http://www.scali.com Tel: (+47) 2262 8950 | Olaf Helsets vei 6 Fax: (+47) 2262 8951 | N0621 Oslo, NORWAY ---1463794943-2128730964-1041512801=:18738 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="bandwidth.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="bandwidth.c" I2RlZmluZSBNT0RVTEUgICAgIkJBTkRXSURUSCINCiNkZWZpbmUgTU9EVUxF X0lEICJAKCMpJElkOiBiYW5kd2lkdGguYyx2IDEuNyAyMDAyLzEyLzI2IDEz OjUxOjQ0IHNwIEV4cCAkIg0KDQovKiBDb3B5cmlnaHQgTm90aWNlIC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCi8vDQovLyBiYW5kd2lkdGguYzogcG9pbnQtdG8tcG9pbnQg cGVyZm9ybWFuY2UgYmVuY2htYXJrDQovLw0KLy8gQ29weXJpZ2h0IChDKSAy MDAxICBTY2FsaSBBUyAgIA0KLy8NCi8vIFRoaXMgcHJvZ3JhbSBpcyBmcmVl IHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9k aWZ5DQovLyBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFs IFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQ0KLy8gdGhlIEZyZWUg U29mdHdhcmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiBvZiB0aGUg TGljZW5zZSwgb3INCi8vIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZl cnNpb24uDQovLw0KLy8gVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGlu IHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsDQovLyBidXQgV0lU SE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3 YXJyYW50eSBvZg0KLy8gTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9S IEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQ0KLy8gR05VIEdlbmVy YWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4NCi8vDQovLyBZ b3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2Vu ZXJhbCBQdWJsaWMgTGljZW5zZQ0KLy8gYWxvbmcgd2l0aCB0aGlzIHByb2dy YW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUNCi8vIEZv dW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBC b3N0b24sIE1BICAwMjExMS0xMzA3ICBVU0ENCi8vIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KKi8NCg0KLyogTW9kdWxlIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQovLyANCi8vICRSQ1NmaWxlOiBiYW5kd2lkdGguYyx2 ICQNCi8vIA0KLy8gQ1JFQVRFRA0KLy8gICBBdXRob3I6IGhvYiAoSGFrb24g T3JkaW5nIEJ1Z2dlKQ0KLy8gICBEYXRlOiAgIDIwMDEvMDIvMjggMTY6Mjg6 NDENCi8vIA0KLy8gTEFTVCBDSEFOR0VEDQovLyAgICRBdXRob3I6IHNwICQN Ci8vICAgJERhdGU6IDIwMDIvMTIvMjYgMTM6NTE6NDQgJA0KLy8gDQovLyBE RVNDUklQVElPTg0KLy8gICBUaGlzIHByb2dyYW0gc2VydmVzIHRoZSBwdXJw b3NlIG9mIGFzc2Vzc2luZyBwb2ludC10by1wb2ludCBwZXJmb3JtYW5jZQ0K LyAgICBvZiBhbiBEQVQgaW1wbGVtZW50YXRpb24uDQovLyAgIA0KLy8gV0FS TklORw0KLy8gICBTY2FsaSBjb25zaWRlcnMgdGhpcyBwcm9ncmFtIG5vdCB0 byBiZSB0aGUgKmJlc3QqIHByb2dyYW0gZm9yIG1lYXN1cmluZw0KLy8gICBw ZXJmb3JtYW5jZSwgYnV0IGl0IGlzIGluY2x1ZGVkIGZvciBpdHMgc2ltcGxp Y2l0eS4gU2NhbGkgY29uc2lkZXJzDQovLyAgIGNvbGxlY3RpdmUgb3BlcmF0 aW9ucyB0byBiZSBtb3JlIHZhbHVhYmxlIGluIGFzc2VzaW5nIGEgY2x1c3Rl cnMnDQovLyAgIHBlcmZvcm1hbmNlLCBoZW5jZSwgdXNlIFBhbGxhcyBQTUIg b3IgbXBwdGVzdCBpbnN0ZWFkLg0KLy8gICANCi8vICAgDQovLyAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKi8NCg0KLyogRGVwZW5kZW5jaWVzIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSovDQoNCiNpbmNsdWRlIDxzdGRpby5oPg0KI2luY2x1 ZGUgPHN0ZGxpYi5oPg0KI2luY2x1ZGUgPHN0cmluZy5oPg0KI2luY2x1ZGUg PHVuaXN0ZC5oPg0KI2luY2x1ZGUgPHNpZ25hbC5oPg0KI2luY2x1ZGUgPGFz c2VydC5oPg0KI2luY2x1ZGUgPGVycm5vLmg+DQojaW5jbHVkZSA8bmV0ZGIu aD4NCiNpbmNsdWRlIDxuZXRpbmV0L2luLmg+DQojaW5jbHVkZSA8bmV0aW5l dC90Y3AuaD4NCiNpbmNsdWRlIDxhcnBhL2luZXQuaD4NCiNpbmNsdWRlIDxz eXMvdGltZS5oPg0KI2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4NCiNpbmNsdWRl IDxzeXMvdGltZS5oPg0KDQovKiBDb25zdGFudHMgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKi8NCg0KI2RlZmluZSBQT1JUIDEyMzANCg0KI2RlZmluZSBET19QSU5H X1BJTkcgMQ0KI2RlZmluZSBET19QSU5HX1BPTkcgMg0KI2RlZmluZSBET19F WENIQU5HRSAgNA0KDQojaWZuZGVmIE1JTg0KI2RlZmluZSBNSU4oYSxiKSAo KGEpIDwgKGIpID8gKGEpIDogKGIpKQ0KI2VuZGlmDQoNCi8qIFR5cGVkZWZz IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0qLw0KDQp0eXBlZGVmIHZvaWQgKCpiZW5j aF9yb3V0X3QpKGludCwgY2hhciAqLCBjaGFyICosIGludCk7DQp0eXBlZGVm IHN0cnVjdCB7DQogICAgICBiZW5jaF9yb3V0X3QgYmVuY2g7DQogICAgICBj aGFyICptbmVtOw0KICAgICAgaW50IHNjYWxlOw0KICAgICAgaW50IG1hc2s7 DQp9IGJlbmNoX2Rlc2NfdDsNCg0KLyogR2xvYmFscyAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSovDQoNCnN0YXRpYyBpbnQgbWU9LTE7DQpzdGF0aWMgaW50IHRv dWNoX3R4X2luaXRpYWxseT0xOw0Kc3RhdGljIGludCB0b3VjaF90eF9hbHdh eXM9MDsNCnN0YXRpYyBpbnQgdG91Y2hfcng9MDsNCnN0YXRpYyBpbnQgYWxp Z249MDsNCnN0YXRpYyBpbnQgYmVuY2hfbWFzaz0wOw0Kc3RhdGljIGludCBt c2dfbWluPTEsIG1zZ19tYXg9MTYqMTAyNCoxMDI0Ow0Kc3RhdGljIGRvdWJs ZSB0Z29hbD0wLjEsIHRyZXM7DQpzdGF0aWMgaW50IGJ1ZnN6ID0gMjYyMTQ0 Ow0Kc3RhdGljIGludCBzb2NrZmQgPSAtMTsNCnN0YXRpYyBjb25zdCBpbnQg bWluX2l0ZXI9MjsNCg0KLyogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSovDQoNCnN0YXRpYyB2b2lkDQpid19leGl0KGludCBleGl0X2NvZGUpDQp7 DQogICBpZiAoc29ja2ZkID49IDApDQogICAgICBjbG9zZShzb2NrZmQpOw0K ICAgZXhpdChleGl0X2NvZGUpOw0KfQ0KDQovKiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKi8NCg0Kc3RhdGljIHZvaWQNCmJ3X3NlbmQodm9pZCAq YnVmLCBpbnQgbGVuKQ0Kew0KICAgaW50IHN0czsNCiAgIHN0cyA9IHNlbmQo c29ja2ZkLCBidWYsIGxlbiwgTVNHX05PU0lHTkFMKTsNCiAgIGlmIChzdHMg IT0gbGVuKQ0KICAgICAgYndfZXhpdCgxKTsNCn0NCg0Kc3RhdGljIHZvaWQN CmJ3X3JlY3Yodm9pZCAqYnVmLCBpbnQgbGVuKQ0Kew0KICAgaW50IHN0czsN CiAgIHN0cyA9IHJlY3Yoc29ja2ZkLCBidWYsIGxlbiwgTVNHX1dBSVRBTEwp Ow0KICAgaWYgKHN0cyAhPSBsZW4pDQogICAgICBid19leGl0KDEpOw0KfQ0K DQpzdGF0aWMgdm9pZA0KYndfc2VuZHJlY3Yodm9pZCAqYnVmMSwgdm9pZCAq YnVmMiwgaW50IGxlbikNCnsNCiAgIGNoYXIgKl9idWYxID0gKGNoYXIgKili dWYxOw0KICAgY2hhciAqX2J1ZjIgPSAoY2hhciAqKWJ1ZjI7DQoNCiAgIHdo aWxlIChsZW4gPiAwKSB7DQogICAgICBpbnQgbCA9IE1JTihidWZzei8yLCBs ZW4pOw0KICAgICAgYndfc2VuZChidWYxLCBsKTsNCiAgICAgIGJ3X3JlY3Yo YnVmMiwgbCk7DQogICAgICBsZW4gLT0gbDsNCiAgICAgIF9idWYxICs9IGw7 DQogICAgICBfYnVmMiArPSBsOw0KICAgfQ0KfQ0KDQovKiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKi8NCg0Kc3RhdGljIGRvdWJsZQ0KYndfd3Rp bWUodm9pZCkNCnsNCiAgIHN0cnVjdCB0aW1ldmFsIHRwOw0KDQogICBnZXR0 aW1lb2ZkYXkoJnRwLCBOVUxMKTsNCg0KICAgcmV0dXJuICgoZG91YmxlKSB0 cC50dl9zZWMgKyAoZG91YmxlKSB0cC50dl91c2VjICogMWUtNik7DQp9DQoN Ci8qIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0qLw0KDQpzdGF0aWMg dm9pZA0KcGluZ19waW5nKGludCBpdGVyLCBjaGFyICpidWYsIGNoYXIgKnNw YXJlLCBpbnQgbGVuKSB7DQogICBpbnQgaTsNCg0KICAgZm9yIChpPTA7IGkg PCBpdGVyOyBpKyspIHsNCiAgICAgIGlmIChtZSA9PSAwKSB7DQogICAgICAg ICBpZiAodG91Y2hfdHhfYWx3YXlzKSBtZW1zZXQoYnVmLCAwLCBsZW4pOw0K CSBid19zZW5kKGJ1ZiwgbGVuKTsNCiAgICAgIH0gZWxzZSB7DQoJIGJ3X3Jl Y3YoYnVmLCBsZW4pOw0KCSBpZiAodG91Y2hfcngpIG1lbWNtcChidWYsIGJ1 ZiwgbGVuKTsNCiAgICAgIH0NCiAgIH0NCn0NCg0Kc3RhdGljIHZvaWQNCnBp bmdfcG9uZyhpbnQgaXRlciwgY2hhciAqYnVmLCBjaGFyICpzcGFyZSwgaW50 IGxlbikgew0KICAgaW50IGk7DQoNCiAgIGZvciAoaT0wOyBpIDwgaXRlcjsg aSsrKSB7DQogICAgICBpZiAobWUgPT0gMCkgew0KICAgICAgICAgaWYgKHRv dWNoX3R4X2Fsd2F5cykgbWVtc2V0KGJ1ZiwgMCwgbGVuKTsNCgkgYndfc2Vu ZChidWYsIGxlbik7DQoJIGJ3X3JlY3YoYnVmLCBsZW4pOw0KCSBpZiAodG91 Y2hfcngpIG1lbWNtcChidWYsIGJ1ZiwgbGVuKTsNCiAgICAgIH0gZWxzZSB7 DQoJIGJ3X3JlY3YoYnVmLCBsZW4pOw0KCSBpZiAodG91Y2hfcngpIG1lbWNt cChidWYsIGJ1ZiwgbGVuKTsNCiAgICAgICAgIGlmICh0b3VjaF90eF9hbHdh eXMpIG1lbXNldChidWYsIDAsIGxlbik7DQoJIGJ3X3NlbmQoYnVmLCBsZW4p Ow0KICAgICAgfQ0KICAgfQ0KfQ0KDQpzdGF0aWMgdm9pZA0KZXhjaGFuZ2Uo aW50IGl0ZXIsIGNoYXIgKmJ1ZjEsIGNoYXIgKmJ1ZjIsIGludCBsZW4pIHsN CiAgIGludCBpOw0KDQogICBmb3IgKGk9MDsgaSA8IGl0ZXI7IGkrKykgew0K ICAgICAgaWYgKHRvdWNoX3R4X2Fsd2F5cykgbWVtc2V0KGJ1ZjEsIDAsIGxl bik7DQogICAgICBid19zZW5kcmVjdihidWYxLCBidWYyLCBsZW4pOw0KICAg ICAgaWYgKHRvdWNoX3J4KSBtZW1jbXAoYnVmMiwgYnVmMiwgbGVuKTsNCiAg IH0NCn0NCg0Kc3RhdGljIGJlbmNoX2Rlc2NfdCBiZW5jaFtdID0geyANCiAg IHsgcGluZ19waW5nLCAicGluZy1waW5nIiwgICAgICAgICAgICAgIDEsIERP X1BJTkdfUElORyB9LA0KICAgeyBwaW5nX3BvbmcsICJwaW5nLXBvbmciLCAg ICAgICAgICAgICAgMiwgRE9fUElOR19QT05HIH0sDQogICB7IGV4Y2hhbmdl LCAgImV4Y2hhbmdlIiwgICAgICAgICAgICAgICAyLCBET19FWENIQU5HRSAg fSwNCiAgIHsgTlVMTCwgICAgICAibm9uZSIsICAgICAgMCB9LA0KfTsNCg0K LyogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSovDQoNCnN0YXRpYyB2 b2lkDQpwcmludF9oZWFkZXIoY2hhciAqc3RyKSB7DQogICBpbnQgaTsNCiAg IA0KICAgaWYgKG1lID09IDApIHsNCiAgICAgIHByaW50ZigiQmVuY2htYXJr ICVzXG4iLCBzdHIpOw0KICAgICAgZm9yIChpPTA7IGkgPCBzdHJsZW4oc3Ry KStzdHJsZW4oIkJlbmNobWFyayAiKTsgKytpKSBwcmludGYoIj0iKTsNCiAg ICAgIHByaW50ZigiXG4iKTsNCg0KICAgICAgcHJpbnRmKCIlMTRzICUxNHMg JTE0cyAlMTRzICUxNHNcbiIsDQoJICAgICAibGVuZ2h0IiwgIml0ZXJhdGlv bnMiLCAiZWxhcHNlZCB0aW1lIiwgInRyYW5zZmVyIHJhdGUiLCAibGF0ZW5j eSIpOw0KICAgICAgcHJpbnRmKCIlMTRzICUxNHMgJTE0cyAlMTRzICUxNHNc biIsDQoJICAgICAiKGJ5dGVzKSIsICIoY291bnQpIiwgIihzZWNvbmRzKSIs ICIoTWJ5dGVzL3MpIiwgIih1c2VjKSIpOw0KICAgICAgcHJpbnRmKCItLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLVxuIik7DQogICB9DQp9DQoNCnN0 YXRpYyB2b2lkDQptZWFzdXJlKGJlbmNoX3JvdXRfdCByb3V0LCBpbnQgc2Nh bGUsIGludCBzeikgew0KICAgaW50IGksIGl0ZXIgPSAwOw0KICAgc3RhdGlj IGludCBwcmV2X2l0ZXIgPSAwOw0KICAgc3RhdGljIGJlbmNoX3JvdXRfdCBw cmV2X3JvdXQgPSBOVUxMOw0KICAgY2hhciAgICAgICAgICAgICAgICpwMSA9 IChjaGFyICopKGFsaWduID8gdmFsbG9jIDogbWFsbG9jKShzeiksDQoJCSAg ICAgICpwMiA9IChjaGFyICopKGFsaWduID8gdmFsbG9jIDogbWFsbG9jKShz eik7DQogICBkb3VibGUgICAgICAgICAgICAgIHQsIHRtaW4sIHM7DQogICAN CiAgIGlmICh0b3VjaF90eF9pbml0aWFsbHkpIG1lbXNldChwMSwgMCwgc3op Ow0KDQogICAvKg0KICAgICogT25seSBzcGVuZCB0aW1lIGNhbGN1bGF0aW5n IGEgbmV3IGl0ZXJhdGlvbiBjb3VudCBpZg0KICAgICogICAgMSkgd2UgaGF2 ZSBhIG5ldyB0ZXN0IGZ1bmN0aW9uDQogICAgKiAgICAgICBvcg0KICAgICog ICAgMikgd2UgYXJlIG5vdCBkb3duIHRvIG1pbl9pdGVyIG51bWJlciBvZiBp dGVyYXRpb25zIHlldA0KICAgICovDQoNCiAgIGlmIChwcmV2X3JvdXQgIT0g cm91dCB8fCBwcmV2X2l0ZXIgPiBtaW5faXRlcikgew0KICAgICAgLyogRmly c3QsIHF1aWNrIGV2YWx1YXRpb24gdG8gZmluZCB0aGUgY29ycmVjdCBubyBv ZiBpdGVyYXRpb25zICovDQogICAgICBmb3IgKGl0ZXI9MTsgMTsgaXRlcis9 IGl0ZXIpIHsNCgkgdG1pbiA9IDk5OTkuOw0KCSBmb3IgKGk9MDsgaSA8IDM7 ICsraSkgeyAvKiBtaW5pbXVtIG9mIDMgdGltZXMgc2VlbXMgZ29vZCAqLw0K CSAgICByb3V0KDEsIHAxLCBwMiwgc3opOw0KCSAgICB0ID0gYndfd3RpbWUo KTsNCgkgICAgcm91dChpdGVyLCBwMSwgcDIsIHN6KTsNCgkgICAgdCA9IGJ3 X3d0aW1lKCkgLSB0Ow0KDQoJICAgIGJ3X3NlbmRyZWN2KCZ0LCAmcywgc2l6 ZW9mKGRvdWJsZSkpOw0KCSAgICB0ID0gKHQgKyBzKSAvIDI7DQoJICAgIHRt aW4gPSAgKHQgPCB0bWluKSA/IHQgOiB0bWluOw0KCSB9DQoJIA0KCSBpZiAo dG1pbiA+IDEwLjAqdHJlcykgYnJlYWs7DQogICAgICB9DQogICAgICAvKiBj b21wdXRlIGVzdGltYXRlZCBubyBpdGVyYXRpb25zIHRvIHJlYWNoIHRnb2Fs ICovDQogICAgICBpdGVyID0gaXRlciAqICh0Z29hbCAvIHRtaW4pOw0KICAg fQ0KICAgaWYgKGl0ZXIgPCBtaW5faXRlcikgaXRlciA9IG1pbl9pdGVyOyAv KiBhdCBsZWFzdCBtaW5faXRlciBpdGVyYXRpb25zICovDQoNCiAgIC8qIG1l YXN1cmUgd2l0aCBvbmUgZHJ5IHJ1biBmaXJzdCB0byBnZXQgdGhpbmdzIHNl dHRsZWQgaW4gY2FjaGUgKi8NCiAgIHJvdXQoMSwgcDEsIHAyLCBzeik7DQog ICB0ID0gYndfd3RpbWUoKTsNCiAgIHJvdXQoaXRlciwgcDEsIHAyLCBzeik7 DQogICB0ID0gYndfd3RpbWUoKSAtIHQ7DQogICANCiAgIGJ3X3NlbmRyZWN2 KCZ0LCAmcywgc2l6ZW9mKGRvdWJsZSkpOw0KICAgdCA9ICh0ICsgcykgLyAy Ow0KDQogICBpZiAodCA8PSAwLjApIHQgPSB0cmVzOyAgLyogYXZvaWQgY3Jh c2ggLi4uICovDQoNCiAgIGlmIChtZSA9PSAwKSB7DQogICAgICBwcmludGYo IiUxNGQgJTE0ZCAlMTQuM2YgJTE0LjFmICUxNC4xZlxuIiwNCgkgICAgIHN6 LCBpdGVyLCB0LA0KCSAgICAgc3oqKGRvdWJsZSlpdGVyKihkb3VibGUpc2Nh bGUqMWUtNi90LA0KCSAgICAgdCoxZTYvKGRvdWJsZSlpdGVyLyhkb3VibGUp c2NhbGUpOw0KICAgfQ0KICAgDQogICBmcmVlKHAyKTsNCiAgIGZyZWUocDEp Ow0KICAgcHJldl9pdGVyID0gaXRlcjsNCiAgIHByZXZfcm91dCA9IHJvdXQ7 DQp9DQoNCnN0YXRpYyB2b2lkDQpkb191c2FnZSh2b2lkKQ0Kew0KICAgcHJp bnRmKCJVc2FnZTogc29ja19iYW5kd2lkdGggLVQgPHN8Yz4gWy1zIHNlcnZl cl0gWy1iIGl8b3x4XSBbLWhdIFstbSBtaW5dIFstTSBtYXhdIFstdCB0Z29h bF0gWy1WXSBbLXogbWFza11cbiIpOw0KfQ0KDQpzdGF0aWMgdm9pZA0KZG9f aGVscCh2b2lkKQ0Kew0KICAgZG9fdXNhZ2UoKTsNCiAgIHByaW50ZigNCiAg ICAgICIgICAgIC1UIDxjfHM+ICAgICA6IFJ1biBhcyBDbGllbnQgb3IgU2Vy dmVyLlxuIg0KICAgICAgIiAgICAgLWggICAgICAgICAgIDogUHJpbnRzIHRo aXMgbWVzc2FnZS5cbiINCiAgICAgICIgICAgIFxuIg0KICAgICAgIiAgICAg VGhlc2UgcGFyYW1ldGVycyBhcmUgb25seSB2YWxpZCBvbiB0aGUgY2xpZW50 IDpcbiINCiAgICAgICIgICAgIFxuIg0KICAgICAgIiAgICAgLXMgPHNlcnZl cj4gIDogU2VydmVyIHRvIGNvbm5lY3QgdG8uIERlZmF1bHQgbG9jYWxob3N0 LlxuIg0KICAgICAgIiAgICAgLWEgICAgICAgICAgIDogRm9yY2UgcGFnZS1h bGlnbmVkIGJ1ZmZlciBhbGxvY2F0aW9uLiBEZWZhdWx0IG9mZi5cbiINCiAg ICAgICIgICAgIC1iIDxpfG98eD4gICA6IEJlbmNobWFyayB0byBydW4sIHBJ bmctcEluZywgcGluZy1wT25nLCBvciBlWGNoYW5nZS5cbiINCiAgICAgICIg ICAgICAgICAgICAgICAgICAgIERlZmF1bHQgYWxsLlxuIg0KICAgICAgIiAg ICAgLW0gPGludD4gICAgIDogTWluaW11bSBtZXNzYWdlIGxlbmd0aC4gRGVm YXVsdCAwLlxuIg0KICAgICAgIiAgICAgLU0gPGludD4gICAgIDogTWF4aW11 bSBtZXNzYWdlIGxlbmd0aC4gRGVmYXVsdCAxNk0uXG4iDQogICAgICAiICAg ICAtdCA8ZmxvYXQ+ICAgOiBTcGVjaWZpZXMgdGhlIGdvYWwgZm9yIHRoZSBl bGFwc2VkIHRpbWUgdXNlZCBwZXIgdGVzdC5cbiINCiAgICAgICIgICAgICAg ICAgICAgICAgICAgIERlZmF1bHQgJS4xZlxuIg0KICAgICAgIiAgICAgLVYg ICAgICAgICAgIDogUHJpbnRzIHZlcnNpb24uXG4iDQogICAgICAiICAgICAt eiA8bWFzaz4gICAgOiBCdWZmZXIgaW5pdGlhbGl6YXRpb24vdG91Y2guIERl ZmF1bHQgMS5cbiINCiAgICAgICIgICAgICAgICBtYXNrJjEgICA6IEluaXRp YWwgaW5pdGlhbGl6YXRpb24gb2Ygc2VuZCBidWZmZXIuXG4iDQogICAgICAi ICAgICAgICAgbWFzayYyICAgOiBJbml0aWFsaXphdGlvbiBvZiBzZW5kIGJ1 ZmZlciBiZWZvcmUgZXZlcnkgc2VuZC5cbiINCiAgICAgICIgICAgICAgICBt YXNrJjQgICA6IFJlYWQgcmVjZWl2ZSBidWZmZXIgYWZ0ZXIgbWVzc2FnZSBo YXMgYmVlbiByZWNlaXZlZC5cbiIsDQogICAgICB0Z29hbCk7DQp9DQoNCi8q IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0qLw0KDQpzdGF0aWMgaW50 DQpid19pbml0KGludCBhcmdjLCBjaGFyICoqYXJndikNCnsNCiAgIGV4dGVy biBjaGFyICpvcHRhcmc7DQogICBpbnQgb25lID0gMTsNCiAgIGludCBjOw0K ICAgY2hhciAqc2VydmVyX25hbWUgPSAibG9jYWxob3N0IjsNCg0KICAgd2hp bGUgKChjID0gZ2V0b3B0KGFyZ2MsIGFyZ3YsICJUOnM6aGFiOm06TTp0OlZ6 OiIpKSAhPSBFT0YpIHsNCiAgICAgIHN3aXRjaCAoYykgew0KCSBjYXNlICdU JzoNCgkgICAgc3dpdGNoICgqb3B0YXJnKSB7DQoJICAgICAgIGNhc2UgJ2Mn Og0KCQkgIG1lID0gMDsNCgkJICBicmVhazsNCgkgICAgICAgY2FzZSAncyc6 DQoJCSAgbWUgPSAxOw0KCQkgIGJyZWFrOw0KCSAgICAgICBkZWZhdWx0Og0K CQkgIGRvX3VzYWdlKCk7DQoJCSAgYndfZXhpdCgzKTsNCgkgICAgfQ0KCSAg ICBicmVhazsNCgkgICAgDQoJIGNhc2UgJ3MnOg0KCSAgICBpZiAobWUgIT0g MCkgew0KCSAgICAgICBkb191c2FnZSgpOw0KCSAgICAgICBid19leGl0KDMp Ow0KCSAgICB9DQoJICAgIHNlcnZlcl9uYW1lID0gb3B0YXJnOw0KCSAgICBi cmVhazsNCg0KCSBjYXNlICdoJzoNCgkgICAgZG9faGVscCgpOw0KCSAgICBi d19leGl0KDApOw0KCSAgICBicmVhazsNCg0KCSBjYXNlICdhJzoNCgkgICAg aWYgKG1lICE9IDApIHsNCgkgICAgICAgZG9fdXNhZ2UoKTsNCgkgICAgICAg YndfZXhpdCgzKTsNCgkgICAgfQ0KCSAgICBhbGlnbiA9IDE7DQoJICAgIGJy ZWFrOw0KCSAgICANCgkgY2FzZSAnYic6DQoJICAgIGlmIChtZSAhPSAwKSB7 DQoJICAgICAgIGRvX3VzYWdlKCk7DQoJICAgICAgIGJ3X2V4aXQoMyk7DQoJ ICAgIH0NCgkgICAgc3dpdGNoICgqb3B0YXJnKSB7DQoJICAgICAgIGNhc2Ug J2knOg0KCQkgIGJlbmNoX21hc2t8PSBET19QSU5HX1BJTkc7DQoJCSAgYnJl YWs7DQoJCSAgDQoJICAgICAgIGNhc2UgJ28nOg0KCQkgIGJlbmNoX21hc2t8 PSBET19QSU5HX1BPTkc7DQoJCSAgYnJlYWs7DQoJCSAgDQoJICAgICAgIGNh c2UgJ3gnOg0KCQkgIGJlbmNoX21hc2t8PSBET19FWENIQU5HRTsNCgkJICBi cmVhazsNCgkJICANCgkgICAgICAgY2FzZSAnPyc6DQoJCSAgZG9fdXNhZ2Uo KTsNCgkJICBid19leGl0KDMpOw0KCQkgIGJyZWFrOw0KCSAgICB9DQoJICAg IGJyZWFrOw0KDQoJIGNhc2UgJ20nOg0KCSAgICBpZiAobWUgIT0gMCkgew0K CSAgICAgICBkb191c2FnZSgpOw0KCSAgICAgICBid19leGl0KDMpOw0KCSAg ICB9DQoJICAgIG1zZ19taW4gPSBhdG9pKG9wdGFyZyk7DQoJICAgIGJyZWFr Ow0KCSAgICANCgkgY2FzZSAnTSc6DQoJICAgIGlmIChtZSAhPSAwKSB7DQoJ ICAgICAgIGRvX3VzYWdlKCk7DQoJICAgICAgIGJ3X2V4aXQoMyk7DQoJICAg IH0NCgkgICAgbXNnX21heCA9IGF0b2kob3B0YXJnKTsNCgkgICAgYnJlYWs7 DQoJICAgIA0KCSBjYXNlICd0JzoNCgkgICAgaWYgKG1lICE9IDApIHsNCgkg ICAgICAgZG9fdXNhZ2UoKTsNCgkgICAgICAgYndfZXhpdCgzKTsNCgkgICAg fQ0KCSAgICB0Z29hbCA9IGF0b2Yob3B0YXJnKTsNCgkgICAgYnJlYWs7DQoN CgkgY2FzZSAnVic6DQoJICAgIGlmIChtZSAhPSAwKSB7DQoJICAgICAgIGRv X3VzYWdlKCk7DQoJICAgICAgIGJ3X2V4aXQoMyk7DQoJICAgIH0NCgkgICAg cHJpbnRmKCIlc1xuIiwgTU9EVUxFX0lEKTsNCgkgICAgYnJlYWs7DQoNCgkg Y2FzZSAneic6DQoJICAgIGlmIChtZSAhPSAwKSB7DQoJICAgICAgIGRvX3Vz YWdlKCk7DQoJICAgICAgIGJ3X2V4aXQoMyk7DQoJICAgIH0NCgkgICAgdG91 Y2hfdHhfaW5pdGlhbGx5ID0gYXRvaShvcHRhcmcpICYgMTsNCgkgICAgdG91 Y2hfdHhfYWx3YXlzICAgID0gYXRvaShvcHRhcmcpICYgMjsNCgkgICAgdG91 Y2hfcnggICAgICAgICAgID0gYXRvaShvcHRhcmcpICYgNDsNCgkgICAgYnJl YWs7DQoNCgkgZGVmYXVsdDoNCgkgICAgZG9fdXNhZ2UoKTsNCgkgICAgYndf ZXhpdCgyKTsNCiAgICAgIH0NCiAgIH0NCg0KICAgaWYgKG1lIDwgMCkgew0K ICAgICAgZG9fdXNhZ2UoKTsNCiAgICAgIGJ3X2V4aXQoMik7DQogICB9DQoN CiAgIGlmIChtc2dfbWluIDwgMSkNCiAgICAgIG1zZ19taW4gPSAxOw0KDQog ICBzb2NrZmQgPSBzb2NrZXQoQUZfSU5FVCwgU09DS19TVFJFQU0sIDApOw0K ICAgaWYgKHNvY2tmZCA8IDApDQogICAgICBid19leGl0KDIpOw0KICAgICAg DQogICBpZiAobWUgPT0gMCkgew0KICAgICAgc3RydWN0IGhvc3RlbnQgKmhl bnQ7DQogICAgICBzdHJ1Y3Qgc29ja2FkZHJfaW4gc2luOw0KICAgDQogICAg ICBoZW50ID0gZ2V0aG9zdGJ5bmFtZShzZXJ2ZXJfbmFtZSk7DQogICAgICBp ZiAoaGVudCA9PSBOVUxMKSB7DQoJIHByaW50ZigiZ2V0aG9zdGJ5bmFtZSBl cnJvcjogJXMiLCBoc3RyZXJyb3IoaF9lcnJubykpOw0KCSBid19leGl0KGhf ZXJybm8pOw0KICAgICAgfQ0KICAgICAgbWVtY3B5KCZzaW4uc2luX2FkZHIs IGhlbnQtPmhfYWRkcl9saXN0WzBdLCBoZW50LT5oX2xlbmd0aCk7DQogICAg ICBzaW4uc2luX2ZhbWlseSA9IEFGX0lORVQ7DQogICAgICBzaW4uc2luX3Bv cnQgPSBodG9ucyhQT1JUKTsNCg0KICAgICAgaWYgKGNvbm5lY3Qoc29ja2Zk LCAoc3RydWN0IHNvY2thZGRyICopJnNpbiwgc2l6ZW9mKHN0cnVjdCBzb2Nr YWRkcl9pbikpIDwgMCkgew0KCSBwcmludGYoImNvbm5lY3QgZmFpbGVkLCBl cnJubyA9ICVzIiwgc3RyZXJyb3IoZXJybm8pKTsNCgkgYndfZXhpdChlcnJu byk7DQogICAgICB9DQogICB9IGVsc2Ugew0KICAgICAgaW50IG5ld2ZkOw0K ICAgICAgc3RydWN0IHNvY2thZGRyX2luIHNpbjsNCiAgICAgIHN0cnVjdCBz b2NrYWRkcl9pbiBwZWVyYWRkcjsNCiAgICAgIGludCBwZWVyYWRkcl9sZW4g PSBzaXplb2YocGVlcmFkZHIpOw0KICAgICAgDQogICAgICBpZiAoc2V0c29j a29wdChzb2NrZmQsIFNPTF9TT0NLRVQsIFNPX1JFVVNFQUREUiwgJm9uZSwg c2l6ZW9mKG9uZSkpIDwgMCkNCgkgcHJpbnRmKCJzZXRzb2Nrb3B0IFNPX1JF VVNFQUREUiBmYWlsZXMhLCBlcnJubyA9ICVzXG4iLCBzdHJlcnJvcihlcnJu bykpOw0KDQogICAgICBzaW4uc2luX3BvcnQgICAgICAgID0gaHRvbnMoUE9S VCk7DQogICAgICBzaW4uc2luX2ZhbWlseSAgICAgID0gQUZfSU5FVDsNCiAg ICAgIHNpbi5zaW5fYWRkci5zX2FkZHIgPSBJTkFERFJfQU5ZOw0KDQogICAg ICBpZiAoYmluZChzb2NrZmQsIChzdHJ1Y3Qgc29ja2FkZHIgKikgJnNpbiwg c2l6ZW9mKHN0cnVjdCBzb2NrYWRkcl9pbikpIDwgMCkgew0KCSBwcmludGYo ImJpbmQgZmFpbGVkLCBlcnJubyA9ICVzIiwgc3RyZXJyb3IoZXJybm8pKTsN CgkgYndfZXhpdChlcnJubyk7DQogICAgICB9DQoNCiAgICAgIGlmIChsaXN0 ZW4oc29ja2ZkLCA1KSA8IDApIHsNCgkgcHJpbnRmKCJsaXN0ZW4gZmFpbGVk LCBlcnJubyA9ICVzIiwgc3RyZXJyb3IoZXJybm8pKTsNCgkgYndfZXhpdChl cnJubyk7DQogICAgICB9DQoNCiAgICAgIGlmICgobmV3ZmQgPSBhY2NlcHQo c29ja2ZkLCAoc3RydWN0IHNvY2thZGRyICopICZwZWVyYWRkciwgJnBlZXJh ZGRyX2xlbikpIDwgMCkgew0KCSBwcmludGYoImxpc3RlbiBmYWlsZWQsIGVy cm5vID0gJXMiLCBzdHJlcnJvcihlcnJubykpOw0KCSBid19leGl0KGVycm5v KTsNCiAgICAgIH0NCg0KICAgICAgY2xvc2Uoc29ja2ZkKTsNCg0KICAgICAg c29ja2ZkID0gbmV3ZmQ7DQogICB9DQoNCiAgIHsNCiAgICAgIGNoYXIgKmVu dnN0cmluZyA9IE5VTEw7DQoNCiAgICAgIGVudnN0cmluZyA9IGdldGVudigi QlVGU1oiKTsNCiAgICAgIGlmIChlbnZzdHJpbmcpDQogICAgICAgICBidWZz eiA9IHN0cnRvbChlbnZzdHJpbmcsIE5VTEwsIDApOw0KDQogICAgICBpZiAo YnVmc3ogPiAwKSB7DQogICAgICAgICBpZiAoc2V0c29ja29wdChzb2NrZmQs IFNPTF9TT0NLRVQsIFNPX1NOREJVRiwgJmJ1ZnN6LCBzaXplb2YoYnVmc3op KSA8IDApDQoJICAgIHByaW50Zigic2V0c29ja29wdCBTT19TTkRCVUYgZmFp bGVkISBlcnJubyA9ICVzXG4iLCBzdHJlcnJvcihlcnJubykpOw0KDQogICAg ICAgICBpZiAoc2V0c29ja29wdChzb2NrZmQsIFNPTF9TT0NLRVQsIFNPX1JD VkJVRiwgJmJ1ZnN6LCBzaXplb2YoYnVmc3opKSA8IDApDQoJICAgIHByaW50 Zigic2V0c29ja29wdCBTT19SQ1ZCVUYgZmFpbGVkISBlcnJubyA9ICVzIiwg c3RyZXJyb3IoZXJybm8pKTsNCiAgICAgIH0NCg0KICAgICAgZW52c3RyaW5n ID0gZ2V0ZW52KCJOT0RFTEFZIik7DQogICAgICBpZiAoZW52c3RyaW5nKQ0K ICAgICAgICAgb25lID0gc3RydG9sKGVudnN0cmluZywgTlVMTCwgMCkgJiAx Ow0KICAgICAgDQogICAgICBpZiAoc2V0c29ja29wdChzb2NrZmQsIFNPTF9U Q1AsIFRDUF9OT0RFTEFZLCAmb25lLCBzaXplb2Yob25lKSkgPCAwKQ0KCSBw cmludGYoInNldHNvY2tvcHQgVENQX05PREVMQVkgZmFpbGVkISBlcnJubyA9 ICVzIiwgc3RyZXJyb3IoZXJybm8pKTsNCiAgIH0NCg0KICAgcmV0dXJuIDA7 DQp9DQoNCi8qIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0qLw0KLyog LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSovDQoNCmludCBtYWluKGlu dCBhcmdjLCBjaGFyICoqYXJndikNCnsNCiAgIGludCBqLCBpbmMsIHN6Ow0K ICAgZG91YmxlIHQxLCB0MiwgYmVzdF90cmVzOw0KICAgDQogICBpZiAoYndf aW5pdChhcmdjLCBhcmd2KSAhPSAwKQ0KICAgICAgYndfZXhpdCgzKTsNCiAN CiAgIC8qIGZpbmQgY2xvY2sgcmVzb2x1dGlvbiAqLw0KICAgZm9yIChqPTAs IGJlc3RfdHJlcz0xZTY7IGo8MTA7ICsraikgew0KICAgICAgZm9yICh0MT1i d193dGltZSgpOyAodDI9Yndfd3RpbWUoKSkgPT0gdDE7KTsNCiAgICAgIHQy ID0gdDIgLSB0MTsNCiAgICAgIA0KICAgICAgYndfc2VuZHJlY3YoJnQyLCAm dHJlcywgc2l6ZW9mKGRvdWJsZSkpOw0KICAgICAgdHJlcyA9ICh0cmVzICsg dDIpIC8gMjsNCiAgICAgIGlmICh0cmVzIDwgYmVzdF90cmVzKSBiZXN0X3Ry ZXM9dHJlczsNCiAgIH0NCiAgIHRyZXMgPSBiZXN0X3RyZXM7DQoNCiAgIGlm IChtZSA9PSAwKSB7DQogICAgICBpbnQgaW50YVsxNl07DQogICAgICBpbnRh WzBdID0gdG91Y2hfdHhfaW5pdGlhbGx5Ow0KICAgICAgaW50YVsxXSA9IHRv dWNoX3R4X2Fsd2F5czsNCiAgICAgIGludGFbMl0gPSB0b3VjaF9yeDsNCiAg ICAgIGludGFbM10gPSBhbGlnbjsNCiAgICAgIGludGFbNF0gPSBiZW5jaF9t YXNrOw0KICAgICAgaW50YVs1XSA9IG1zZ19taW47DQogICAgICBpbnRhWzZd ID0gbXNnX21heDsNCiAgICAgIGJ3X3NlbmQoaW50YSwgNyAqIHNpemVvZihp bnQpKTsNCiAgICAgIGJ3X3NlbmQoJnRnb2FsLCBzaXplb2YoZG91YmxlKSk7 DQogICB9IGVsc2Ugew0KICAgICAgaW50IGludGFbMTZdOw0KICAgICAgYndf cmVjdihpbnRhLCA3ICogc2l6ZW9mKGludCkpOw0KICAgICAgYndfcmVjdigm dGdvYWwsIHNpemVvZihkb3VibGUpKTsNCiAgICAgIHRvdWNoX3R4X2luaXRp YWxseSA9IGludGFbMF07DQogICAgICB0b3VjaF90eF9hbHdheXMgPSBpbnRh WzFdOw0KICAgICAgdG91Y2hfcnggPSBpbnRhWzJdOw0KICAgICAgYWxpZ24g PSBpbnRhWzNdOw0KICAgICAgYmVuY2hfbWFzayA9IGludGFbNF07DQogICAg ICBtc2dfbWluID0gaW50YVs1XTsNCiAgICAgIG1zZ19tYXggPSBpbnRhWzZd Ow0KICAgfQ0KICANCiAgIC8qIGlmIG5vIGJlbmNobWFya3MgaGF2ZSBiZWVu IHNwZWNpZmllZCwgd2UgZGVmYXVsdCB0byBhbGwgKi8NCiAgIGlmICghYmVu Y2hfbWFzaykgYmVuY2hfbWFzayA9IERPX1BJTkdfUElOR3xET19QSU5HX1BP Tkd8RE9fRVhDSEFOR0U7DQoNCiAgIGlmIChtZSA9PSAwKQ0KICAgICAgcHJp bnRmKCJSZXNvbHV0aW9uICh1c2VjKTogJWZcbiIsIHRyZXMqMWU2KTsNCiAg IA0KICAgZm9yIChqPTA7IGJlbmNoW2pdLmJlbmNoOyArK2opIHsNCg0KICAg ICAgaWYgKCEoYmVuY2hfbWFzayAmIGJlbmNoW2pdLm1hc2spKSBjb250aW51 ZTsNCgkgIA0KICAgICAgcHJpbnRfaGVhZGVyKGJlbmNoW2pdLm1uZW0pOw0K ICAgICAgaW5jID0gbXNnX21pbiA+PiAyOw0KICAgICAgZm9yIChzej1tc2df bWluOyBzeiA8PSBtc2dfbWF4OyBzeis9aW5jKSB7DQoJIGlmIChzeiA8IDQp IHsNCgkgICAgaW5jID0gMTsNCgkgfSBlbHNlIHsNCgkgICAgaWYgKCEoc3og JiBpbmMpKSBpbmMrPWluYzsgLyogR290IHRoaXM/ICovDQoJIH0NCg0KCSBt ZWFzdXJlKGJlbmNoW2pdLmJlbmNoLCBiZW5jaFtqXS5zY2FsZSwgc3opOw0K ICAgICAgfQ0KICAgICAgaWYgKG1lID09IDApIHByaW50ZigiXG5cbiIpOw0K ICAgfQ0KDQogICBid19leGl0KDApOw0KDQogICByZXR1cm4gMDsNCn0NCg== ---1463794943-2128730964-1041512801=:18738-- From ramarayaluv@yahoo.com Thu Jan 2 08:50:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jan 2003 08:50:31 -0800 (PST) Received: from web10906.mail.yahoo.com (web10906.mail.yahoo.com [216.136.131.42]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h02GoO3v001659 for ; Thu, 2 Jan 2003 08:50:25 -0800 Message-ID: <20030102165540.27518.qmail@web10906.mail.yahoo.com> Received: from [202.142.82.10] by web10906.mail.yahoo.com via HTTP; Thu, 02 Jan 2003 08:55:40 PST Date: Thu, 2 Jan 2003 08:55:40 -0800 (PST) From: ramarayalu vattikuti Subject: Need u r help To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1437 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ramarayaluv@yahoo.com Precedence: bulk X-list: netdev Hi, This is RamaRayalu Vattikuti . Now i am doing my M.Tech project work on device drivers. operating system is linux. my project : 1.with PCI-DPM card we can provide the communication between two processing elements in a parallel processing system. 2.the same thing can be done with ethernet card also. here i had given this problem to solve. can we develop a virtual device so that it invokes the two devices i mentioned above. if u know any idea please mail me soon. thanks®ards rayalu __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From werner@almesberger.net Thu Jan 2 13:20:58 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jan 2003 13:21:03 -0800 (PST) Received: from host.almesberger.net (IDENT:dUAFFWsuTaX6NIPzm1Ej7DHWANfdFcsx@almesberger.net [63.105.73.239] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h02LKv3v011481 for ; Thu, 2 Jan 2003 13:20:58 -0800 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.9.3/8.9.3) with ESMTP id NAA20568; Thu, 2 Jan 2003 13:26:11 -0800 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id h02LQ6D32728; Thu, 2 Jan 2003 18:26:06 -0300 Date: Thu, 2 Jan 2003 18:26:06 -0300 From: Werner Almesberger To: kuznet@ms2.inr.ac.ru Cc: netdev@oss.sgi.com, chengjin@cs.caltech.edu Subject: Re: snd_cwnd drawn and quartered Message-ID: <20030102182606.A32722@almesberger.net> References: <20021224225040.A22201@almesberger.net> <200301020138.EAA32608@sex.inr.ac.ru> <20030102030858.E1363@almesberger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030102030858.E1363@almesberger.net>; from wa@almesberger.net on Thu, Jan 02, 2003 at 03:08:58AM -0300 X-archive-position: 1438 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wa@almesberger.net Precedence: bulk X-list: netdev I wrote: > I searched around but didn't spot anything. A pointer would be > welcome, thanks ! I think I found it. Is it "The Rate-Halving Algorithm for TCP Congestion Control", section 5.14, "Application of Bounding Paremeters" (sic!) ? http://www.psc.edu/networking/ftp/papers/draft-ratehalving.txt - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From spam_schild@yahoo.com Thu Jan 2 13:38:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jan 2003 13:38:27 -0800 (PST) Received: from web21501.mail.yahoo.com (web21501.mail.yahoo.com [66.163.169.12]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h02LcP3v011934 for ; Thu, 2 Jan 2003 13:38:25 -0800 Message-ID: <20030102214341.72165.qmail@web21501.mail.yahoo.com> Received: from [130.210.69.109] by web21501.mail.yahoo.com via HTTP; Thu, 02 Jan 2003 13:43:41 PST Date: Thu, 2 Jan 2003 13:43:41 -0800 (PST) From: Leonard mckinley Subject: Jumbograms To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1439 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: spam_schild@yahoo.com Precedence: bulk X-list: netdev Do any IPv6 implementations compatible with the Linux kernel support Jumbograms? For example: on a UDP IPv6 socket, this: sendto ( s, buf, 65537, 0, addr, addr_len ) wouldn't fail. Thanks, __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From gxp@buaa.edu.cn Fri Jan 3 00:44:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jan 2003 00:45:01 -0800 (PST) Received: from mail (mail.buaa.edu.cn [202.112.128.55]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h038ip3v018247 for ; Fri, 3 Jan 2003 00:44:52 -0800 Received: from gvpn ([202.112.131.150]) by mail.buaa.edu.cn (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTPA id <0H840030WRP1S9@mail.buaa.edu.cn> for netdev@oss.sgi.com; Fri, 03 Jan 2003 17:00:37 +0800 (CST) Date: Fri, 03 Jan 2003 16:56:28 +0800 From: Gao XiaoPeng Subject: To: "netdev@oss.sgi.com" Message-id: <0H840030YRP1S9@mail.buaa.edu.cn> MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-archive-position: 1440 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gxp@buaa.edu.cn Precedence: bulk X-list: netdev hello, one of my friends wants to discuss a netfilter problem with you! thx! ------------------------------------------------------------- hi, I am a student, I think that skb has all the information that is needed for sending and receiving.So I get the skb pointer at NF_IP_POST_ROUTING, put it in a chain organized by myself (I use a spinlock_t lock to control the access of the chain, I named it mylock), and return NF_STOLEN. I make a tq_timer task to start ip_finish_output2(I export it from kernel),ip_finish_output2 use the skb from my chain.I can make ftp run ok for almost 1 hour, but then the system will carsh with this information: ds:0018 es:0018 ss:0018 process swapper(pid:0, stackpage = c0265000) stack: c01a07ea c173a088 ........... call trace:[] []...... code: 0f 0b 89 7c 24 04 b8 03 00 00 00...... <0>kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing! I want to know why I count run for some time but could not go on for a long time . Does it possible to transmit data by the way and how to do?thanks very much! best regard Chen Wei From zw@netspeed-tech.com Fri Jan 3 02:10:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jan 2003 02:10:52 -0800 (PST) Received: from netspeed-tech.com ([218.104.80.12]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h03AAh3v020984 for ; Fri, 3 Jan 2003 02:10:44 -0800 Received: (qmail 5936 invoked from network); 3 Jan 2003 10:08:17 -0000 Received: from unknown (HELO netspeed-tech.com) (218.2.232.250) by 0 with SMTP; 3 Jan 2003 10:08:17 -0000 Message-ID: <3E1561EF.7040805@netspeed-tech.com> Date: Fri, 03 Jan 2003 18:11:59 +0800 From: ZHAO Wei Reply-To: zhaoway@public1.ptt.js.cn User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030102 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gao XiaoPeng CC: "netdev@oss.sgi.com" Subject: Re: References: <0H840030YRP1S9@mail.buaa.edu.cn> In-Reply-To: <0H840030YRP1S9@mail.buaa.edu.cn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1441 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zw@netspeed-tech.com Precedence: bulk X-list: netdev > I am a student, I think that skb has all the information > that is needed for sending and receiving.So I get the skb > pointer at NF_IP_POST_ROUTING, put it in a chain organized > by myself (I use a spinlock_t lock to control the access of > the chain, I named it mylock), and return NF_STOLEN. > I make a tq_timer task to start ip_finish_output2(I export > it from kernel),ip_finish_output2 use the skb from my chain.I > can make ftp run ok for almost 1 hour, but then the system will > carsh with this information: > > ds:0018 es:0018 ss:0018 > process swapper(pid:0, stackpage = c0265000) > stack: c01a07ea c173a088 ........... > call trace:[] []...... > code: 0f 0b 89 7c 24 04 b8 03 00 00 00...... > <0>kernel panic: Aiee, killing interrupt handler! > In interrupt handler - not syncing! You could try ksymoops to get some more info from the above. You will get a call trace and that will reveal. From Robert.Olsson@data.slu.se Fri Jan 3 05:11:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jan 2003 05:11:53 -0800 (PST) Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h03DBf3v025593 for ; Fri, 3 Jan 2003 05:11:44 -0800 Received: (from robert@localhost) by robur.slu.se (8.9.3/8.9.3) id OAA13667; Fri, 3 Jan 2003 14:25:21 +0100 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15893.36673.476788.286469@robur.slu.se> Date: Fri, 3 Jan 2003 14:25:21 +0100 To: Steffen Persvold Cc: linux-kernel@vger.kernel.org, , netdev@oss.sgi.com Subject: One-way Gigabit Ethernet TCP performance with Jumbo frames In-Reply-To: References: <3E142D85.71FFA06C@digeo.com> X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 1442 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Steffen Persvold writes: > Hi all, > > Lately I've been testing out two Gigabit Ethernet adapters on Pentium 4 > Xeon platforms; onboard Intel 82544GC (e1000 driver) and onboard Broadcom > BCM5701 (tg3 driver), and I'm experiencing some wierd behaviour on > one-way tests (ping-ping). The machines I'm testing is connected back to > back (i.e no switch) and are fairly fast systems (Dual Xeon 2.4 GHz, 1GB > memory) configured to use Jumbo frames (9000 bytes). > But, when running a one-way test (where one machine only sends, and the > other only receives, i.e ping-ping) there is a serious dip in the > performance curve at ~768 bytes and the bandwidth levels out at approx > 60 MByte/sec (about half of peak) regadless of application and GbE device. I've seen similar problems... and most of the times this seems due to incorrect tuned mitigation. Think of what happens if you don't have TX- interrupts enough to clean your TX-ring. Which means your app. can not fill it at full speed -- and as long you have RX traffic it contributes with interrupts so the problem is not visile. If you test IP-forwarding with RX soly on one interface and TX soly on the other and routing between them. You'll see drops at the qdisc in such case. Cheers. --ro From hadi@cyberus.ca Fri Jan 3 13:41:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jan 2003 13:41:32 -0800 (PST) Received: from mx03.cyberus.ca (mx03.cyberus.ca [216.191.240.24]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h03LfR3v020227 for ; Fri, 3 Jan 2003 13:41:28 -0800 Received: from shell.cyberus.ca ([216.191.240.114]) by mx03.cyberus.ca with esmtp (Exim 4.10) id 18UZeS-0009wL-00; Fri, 03 Jan 2003 16:46:48 -0500 Received: from shell.cyberus.ca (localhost.cyberus.ca [127.0.0.1]) by shell.cyberus.ca (8.12.6/8.12.6) with ESMTP id h03Lkekr048637; Fri, 3 Jan 2003 16:46:40 -0500 (EST) (envelope-from hadi@cyberus.ca) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.12.6/8.12.6/Submit) with ESMTP id h03LkeZV048634; Fri, 3 Jan 2003 16:46:40 -0500 (EST) (envelope-from hadi@cyberus.ca) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Fri, 3 Jan 2003 16:46:40 -0500 (EST) From: jamal To: Jeff Garzik , Donald Becker cc: netdev@oss.sgi.com Subject: SIOCADDMULTI for unicast broken Message-ID: <20030103164001.S48623@shell.cyberus.ca> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1640597484-1041630400=:48623" X-archive-position: 1443 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev 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. --0-1640597484-1041630400=:48623 Content-Type: TEXT/PLAIN; charset=US-ASCII Some programs require ability to accept packets destined to certain MAC addresses (in addition to their own). Example Jerome Ettienes vrrpd (http://w3.arobas.net/~jetienne/vrrpd/) The trick is to add unicast addresses via SIOCADDMULTI and accept those packets when they make their way up the stack. I think this used to work, no? Donald, any history/comments behind this? Patch attahced, not very well tested but looks safe. cheers, jamal --0-1640597484-1041630400=:48623 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="eth_type_trans.fix" Content-Transfer-Encoding: BASE64 Content-ID: <20030103164640.K48623@shell.cyberus.ca> Content-Description: Content-Disposition: attachment; filename="eth_type_trans.fix" LS0tIG5ldC9ldGhlcm5ldC9ldGguYwkyMDAzLzAxLzAzIDE4OjIwOjQ5CTEu MQ0KKysrIG5ldC9ldGhlcm5ldC9ldGguYwkyMDAzLzAxLzAzIDE4OjIyOjA1 DQpAQCAtMTQ4LDYgKzE0OCwzMCBAQA0KIAlyZXR1cm4gMDsNCiB9DQogDQor dm9pZCBjaGVja19tY2FzdF9saXN0KHN0cnVjdCBza19idWZmICpza2IsIHN0 cnVjdCBuZXRfZGV2aWNlICpkZXYpDQorew0KKwlzdHJ1Y3QgZGV2X21jX2xp c3QgKmRtaTsNCisJc3RydWN0IGV0aGhkciAqZXRoOw0KKwkJCSAgICAgICAg DQorCWlmIChza2ItPnBrdF90eXBlICE9IFBBQ0tFVF9PVEhFUkhPU1QpDQor CQlyZXR1cm47DQorDQorCWV0aCA9IHNrYi0+bWFjLmV0aGVybmV0Ow0KKw0K KwkvKiBtYXkgbm90IGJlIG5lY2Vzc2FyeSB0byBiaF9sb2NrIC0gZml4IGxh dGVyIC0gSkhTICovDQorCXNwaW5fbG9ja19iaCgmZGV2LT54bWl0X2xvY2sp Ow0KKw0KKwlmb3IgKGRtaSA9IGRldi0+bWNfbGlzdDsgZG1pICE9IE5VTEw7 IGRtaSA9IGRtaS0+bmV4dCkgew0KKwkJaWYgKG1lbWNtcChkbWktPmRtaV9h ZGRyLCBldGgtPmhfZGVzdCwgZGV2LT5hZGRyX2xlbikgPT0gMA0KKwkJICAg ICYmIGRtaS0+ZG1pX2FkZHJsZW4gPT0gZGV2LT5hZGRyX2xlbikgeyANCisJ CQlza2ItPnBrdF90eXBlID0gUEFDS0VUX0hPU1Q7DQorCQkJCWJyZWFrOw0K KwkJfQ0KKwl9DQorDQorCXNwaW5fdW5sb2NrX2JoKCZkZXYtPnhtaXRfbG9j ayk7DQorfQ0KKw0KIA0KIC8qDQogICoJRGV0ZXJtaW5lIHRoZSBwYWNrZXQn cyBwcm90b2NvbCBJRC4gVGhlIHJ1bGUgaGVyZSBpcyB0aGF0IHdlIA0KQEAg LTE4Miw4ICsyMDYsMTQgQEANCiAJIA0KIAllbHNlIGlmKDEgLypkZXYtPmZs YWdzJklGRl9QUk9NSVNDKi8pDQogCXsNCi0JCWlmKG1lbWNtcChldGgtPmhf ZGVzdCxkZXYtPmRldl9hZGRyLCBFVEhfQUxFTikpDQotCQkJc2tiLT5wa3Rf dHlwZT1QQUNLRVRfT1RIRVJIT1NUOw0KKwkJaWYobWVtY21wKGV0aC0+aF9k ZXN0LGRldi0+ZGV2X2FkZHIsIEVUSF9BTEVOKSkgew0KKwkJCXNrYi0+cGt0 X3R5cGUgPSBQQUNLRVRfT1RIRVJIT1NUOw0KKwkJCS8qIHdlIG92ZXJyaWRl IFBBQ0tFVF9PVEhFUkhPU1QgaWYgTUFDIGFwcGVhcnMNCisJCQkgKiBpbiBv dXIgbWNhc3QgbGlzdCBhbGxvd3MgdG8gaGF2ZSBzZXZlcmFsIA0KKwkJCSAq IGFsbG93ZWQgTUFDcyBmb3IgcmVjZWl2ZXMgYWRkZWQgdmlhIA0KKwkJCSAq IFNJT0NBRERNVUxUSSBvbiB0aGUgZGV2aWNlKi8NCisJCQljaGVja19tY2Fz dF9saXN0KHNrYixkZXYpOw0KKwkJfQ0KIAl9DQogCQ0KIAlpZiAobnRvaHMo ZXRoLT5oX3Byb3RvKSA+PSAxNTM2KQ0K --0-1640597484-1041630400=:48623-- From becker@scyld.com Fri Jan 3 16:01:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jan 2003 16:01:27 -0800 (PST) Received: from beohost.scyld.com (dsl093-058-082.blt1.dsl.speakeasy.net [66.93.58.82]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0401K3v025663 for ; Fri, 3 Jan 2003 16:01:21 -0800 Received: from localhost (becker@localhost) by beohost.scyld.com (8.11.6/8.11.6) with ESMTP id h0407CF31101; Fri, 3 Jan 2003 19:07:13 -0500 Date: Fri, 3 Jan 2003 19:07:11 -0500 (EST) From: Donald Becker To: jamal cc: Jeff Garzik , Subject: Re: SIOCADDMULTI for unicast broken In-Reply-To: <20030103164001.S48623@shell.cyberus.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1444 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: becker@scyld.com Precedence: bulk X-list: netdev On Fri, 3 Jan 2003, jamal wrote: > Subject: SIOCADDMULTI for unicast broken > > Some programs require ability to accept packets destined to certain > MAC addresses (in addition to their own). > Example Jerome Ettienes vrrpd (http://w3.arobas.net/~jetienne/vrrpd/) > > The trick is to add unicast addresses via SIOCADDMULTI and accept those > packets when they make their way up the stack. > I think this used to work, no? Donald, any history/comments behind > this? This is a very specialized requirement, so specialized that it should not be added as general-purpose requirement for drivers or the network stack. This capability was supported as a special case for the Tulip driver, and then only for the real 21*4* chips that had the hardware CAM capable of matching up to 16 destination addresses. A few other chips support matching unicast addresses with the multicast filter, but there is the general problem of false-accepts and chip-specific quirks that must be dealt with. Once again: this is a very specialized thing. Of the few people that think they need the capability, most are wrong. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From jgarzik@pobox.com Fri Jan 3 17:13:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jan 2003 17:13:47 -0800 (PST) Received: from www.linux.org.uk (parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h041Dc3v026424 for ; Fri, 3 Jan 2003 17:13:39 -0800 Received: from rdu57-8-131.nc.rr.com ([66.57.8.131] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 18Ucxm-0004P0-00; Sat, 04 Jan 2003 01:18:58 +0000 Message-ID: <3E163648.2040204@pobox.com> Date: Fri, 03 Jan 2003 20:18:00 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jamal CC: Donald Becker , netdev@oss.sgi.com Subject: Re: SIOCADDMULTI for unicast broken References: <20030103164001.S48623@shell.cyberus.ca> In-Reply-To: <20030103164001.S48623@shell.cyberus.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1445 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev jamal wrote: > Some programs require ability to accept packets destined to certain > MAC addresses (in addition to their own). > Example Jerome Ettienes vrrpd (http://w3.arobas.net/~jetienne/vrrpd/) > > The trick is to add unicast addresses via SIOCADDMULTI and accept those > packets when they make their way up the stack. > I think this used to work, no? Donald, any history/comments behind > this? Over and above Donald's comments, from an interface perspective I think this is a bit of a hack, don't you? :) Calling an "add-multi" ioctl should do precisely that... and only that :) From becker@scyld.com Fri Jan 3 17:34:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jan 2003 17:34:04 -0800 (PST) Received: from beohost.scyld.com (dsl093-058-082.blt1.dsl.speakeasy.net [66.93.58.82]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h041Xx3v026953 for ; Fri, 3 Jan 2003 17:34:00 -0800 Received: from localhost (becker@localhost) by beohost.scyld.com (8.11.6/8.11.6) with ESMTP id h041do731671; Fri, 3 Jan 2003 20:39:51 -0500 Date: Fri, 3 Jan 2003 20:39:50 -0500 (EST) From: Donald Becker To: Jeff Garzik cc: jamal , Subject: Re: SIOCADDMULTI for unicast broken In-Reply-To: <3E163648.2040204@pobox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1446 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: becker@scyld.com Precedence: bulk X-list: netdev On Fri, 3 Jan 2003, Jeff Garzik wrote: > jamal wrote: > > Some programs require ability to accept packets destined to certain > > MAC addresses (in addition to their own). > > Example Jerome Ettienes vrrpd (http://w3.arobas.net/~jetienne/vrrpd/) > > > > The trick is to add unicast addresses via SIOCADDMULTI and accept those > > packets when they make their way up the stack. > > I think this used to work, no? Donald, any history/comments behind > > this? > > Over and above Donald's comments, from an interface perspective I think > this is a bit of a hack, don't you? :) Calling an "add-multi" ioctl > should do precisely that... and only that :) Yes, it is totally a hack, not an interface. It was "If you need this capability for a RESEARCH PROJECT, you can buy this specific board and thus not need to modify the kernel or device driver. " You can also find a few people that want to receive specific corrupted packets, change the meaning of LEDs on a NIC, and do many other strange things. But we don't need a defined kernel interface for each one. Improvement is what you can eliminate or simplify, not adding complexity. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From greearb@candelatech.com Fri Jan 3 17:40:47 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jan 2003 17:40:52 -0800 (PST) Received: from grok.yi.org (IDENT:yXyRIH4NbdwN8vP6VUTPvLexykWp7m96@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h041ek3v027358 for ; Fri, 3 Jan 2003 17:40:47 -0800 Received: from candelatech.com (IDENT:V9fzbN+dCw4pPKyFCv0QpPHNpsLj0kmk@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id h041jVl26142; Fri, 3 Jan 2003 17:45:32 -0800 Message-ID: <3E163CBB.30206@candelatech.com> Date: Fri, 03 Jan 2003 17:45:31 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Donald Becker CC: Jeff Garzik , jamal , netdev@oss.sgi.com Subject: Re: SIOCADDMULTI for unicast broken References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1447 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Donald Becker wrote: > It was > "If you need this capability for a RESEARCH PROJECT, you can buy this > specific board and thus not need to modify the kernel or device > driver. " > > You can also find a few people that want to receive specific corrupted > packets, change the meaning of LEDs on a NIC, and do many other strange > things. But we don't need a defined kernel interface for each one. Just out of curiosity, what is the suggested manner for adding such back-door hacks as this? Maybe in a proc file system that the driver implements? It would be neat to see various driver-specific features like this be implemented, and it would be even nicer if they followed at least some general guideline for how to interface with the rest of the world... > > Improvement is what you can eliminate or simplify, not adding complexity. Exposing new features can also be an improvement, though one does not imply the other ;) Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From becker@scyld.com Fri Jan 3 18:12:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jan 2003 18:12:46 -0800 (PST) Received: from beohost.scyld.com (dsl093-058-082.blt1.dsl.speakeasy.net [66.93.58.82]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h042Cd3v028049 for ; Fri, 3 Jan 2003 18:12:40 -0800 Received: from localhost (becker@localhost) by beohost.scyld.com (8.11.6/8.11.6) with ESMTP id h042IP532029; Fri, 3 Jan 2003 21:18:25 -0500 Date: Fri, 3 Jan 2003 21:18:24 -0500 (EST) From: Donald Becker To: Ben Greear cc: Jeff Garzik , jamal , Subject: Re: SIOCADDMULTI for unicast broken In-Reply-To: <3E163CBB.30206@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1448 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: becker@scyld.com Precedence: bulk X-list: netdev On Fri, 3 Jan 2003, Ben Greear wrote: > Donald Becker wrote: > > > It was > > "If you need this capability for a RESEARCH PROJECT, you can buy this > > specific board and thus not need to modify the kernel or device > > driver. " > > > > You can also find a few people that want to receive specific corrupted > > packets, change the meaning of LEDs on a NIC, and do many other strange > > things. But we don't need a defined kernel interface for each one. > > Just out of curiosity, what is the suggested manner for adding such > back-door hacks as this? Maybe in a proc file system that the driver > implements? It would be neat to see various driver-specific features > like this be implemented, and it would be even nicer if they followed > at least some general guideline for how to interface with the rest of > the world... The problems are - The extensions people (very few people) want are completely unpredictable. - Unique features are, well, unique You might think it's Really Very Important to change the LED meanings on your NIC. For instance, if one LED means all Rx traffic and another Rx accepted you can estimate how much traffic is for you. And most NICs provide a way to do this. But no two are the same, and there is no general way to describe the semantics. So it's a capability best ignored. (*) Un * You can access this and many other capabilities through the MII ioctl() interface to vendor specific register, but not as an abstracted, hardware-independent feature. Why an ioctl() and not /proc? Exporting MII registers via /proc is problematic because of Sticky Bits and clear-on-read semantics. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From jgarzik@pobox.com Fri Jan 3 19:08:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jan 2003 19:08:20 -0800 (PST) Received: from www.linux.org.uk (parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0438D3v028730 for ; Fri, 3 Jan 2003 19:08:14 -0800 Received: from rdu57-8-131.nc.rr.com ([66.57.8.131] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 18UdV0-0004fD-00; Sat, 04 Jan 2003 01:53:19 +0000 Message-ID: <3E163E4D.5090007@pobox.com> Date: Fri, 03 Jan 2003 20:52:13 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Greear CC: Donald Becker , jamal , netdev@oss.sgi.com Subject: Re: SIOCADDMULTI for unicast broken References: <3E163CBB.30206@candelatech.com> In-Reply-To: <3E163CBB.30206@candelatech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1449 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Ben Greear wrote: > Donald Becker wrote: > >> It was >> "If you need this capability for a RESEARCH PROJECT, you can buy this >> specific board and thus not need to modify the kernel or device >> driver. " >> >> You can also find a few people that want to receive specific corrupted >> packets, change the meaning of LEDs on a NIC, and do many other strange >> things. But we don't need a defined kernel interface for each one. > > > Just out of curiosity, what is the suggested manner for adding such > back-door hacks as this? SIOCDEVPRIVATE is staying around > Maybe in a proc file system that the driver > implements? No! procfs additions are discouraged. sysfs in 2.5.x if you _must_ do this, but SIOCDEVPRIVATE or just flat out maintaining a kernel patch against a stable kernel tree would be much preferred, I think. > It would be neat to see various driver-specific features > like this be implemented, and it would be even nicer if they followed > at least some general guideline for how to interface with the rest of > the world... Driver-specific features are by definition just that :) If you want a general guideline, you'll also want a header or helper lib quite often to eliminate duplication of code and standardize the interface. Jeff From hadi@cyberus.ca Fri Jan 3 22:07:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jan 2003 22:07:35 -0800 (PST) Received: from mx02.cyberus.ca (mx02.cyberus.ca [216.191.240.26]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0467R3v030087 for ; Fri, 3 Jan 2003 22:07:28 -0800 Received: from shell.cyberus.ca ([216.191.240.114]) by mx02.cyberus.ca with esmtp (Exim 4.10) id 18UffF-000Ij2-00; Fri, 03 Jan 2003 23:12:01 -0500 Received: from shell.cyberus.ca (localhost.cyberus.ca [127.0.0.1]) by shell.cyberus.ca (8.12.6/8.12.6) with ESMTP id h044Brkr049192; Fri, 3 Jan 2003 23:11:53 -0500 (EST) (envelope-from hadi@cyberus.ca) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.12.6/8.12.6/Submit) with ESMTP id h044BjtL049189; Fri, 3 Jan 2003 23:11:46 -0500 (EST) (envelope-from hadi@cyberus.ca) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Fri, 3 Jan 2003 23:11:45 -0500 (EST) From: jamal To: Donald Becker cc: Ben Greear , Jeff Garzik , "" Subject: Re: SIOCADDMULTI for unicast broken In-Reply-To: Message-ID: <20030103224852.L48869@shell.cyberus.ca> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1450 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Too many emails to respond to at once. Q: Is this a hack? A: Yes, indeed it is. wrong API is the main culprit. Q: Is this a feature needed by only a few people? A: No, Absolutely not. RFC2338 is one example that needs such a feature for "aliasing" MAC addresses. RFC2338 is very popular these days for some reason. I would think any schemes that do HA takeover of another host would need such a feature. How common are NICS such as the 21x4x that can be programmed to do perfect hashing and accept multiple MAC addresses in hardware? And if this was a commodity feature - what happens to PACKET_HOST setting? an netdevice can only have one unicast MAC address. SIOCDEVPRIVATE does not seem to be the right place to do this. You still wanna have ability to do proper RFC2338 and related protocols even when the h/ware is incapable. And btw, i didnt even open up the whole can of worms - we also need to respond back with proper MAC addresses to ARPs and packets sourced with specific virtual router IPs. This is a seprate problem. cheers, jamal PS: the hack credit (for using SIOCADDMULTI/DELMULTI) goes to Jerome Ettiene (this is a guy who never responds to email, probably too busy unicycling somewhere, so no point in ccing him) - Except it doesnt work without the patch i posted. On takeover, he sets the original MAC address as a receiving MAC via SIOCADDMULTI and the allocated 00-00-5E-00-01-xx MAC to be the main MAC address. The weakness is when you want to run multiple virtual routers; each one requires its own 00-00-5E-00-01-xx MAC. From becker@scyld.com Fri Jan 3 22:27:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jan 2003 22:27:34 -0800 (PST) Received: from beohost.scyld.com (pool-151-196-173-220.balt.east.verizon.net [151.196.173.220]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h046RU3v030491 for ; Fri, 3 Jan 2003 22:27:31 -0800 Received: from localhost (becker@localhost) by beohost.scyld.com (8.11.6/8.11.6) with ESMTP id h046XBE01620; Sat, 4 Jan 2003 01:33:11 -0500 Date: Sat, 4 Jan 2003 01:33:11 -0500 (EST) From: Donald Becker To: jamal cc: Ben Greear , Jeff Garzik , Subject: Re: SIOCADDMULTI for unicast broken In-Reply-To: <20030103224852.L48869@shell.cyberus.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1451 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: becker@scyld.com Precedence: bulk X-list: netdev On Fri, 3 Jan 2003, jamal wrote: > Too many emails to respond to at once. > > Q: Is this a hack? > A: Yes, indeed it is. wrong API is the main culprit. > > Q: Is this a feature needed by only a few people? > A: No, Absolutely not. RFC2338 is one example that needs The common way of handling this is unsolicited ARP. > How common are NICS such as the 21x4x that can be programmed to do > perfect hashing and accept multiple MAC addresses in hardware? Not very common. I mentioned the 21*4* explicitly because few other common chips implement this feature. The Digital design implemented it because of DECnet, which is long dead. > And if this was a commodity feature - what happens to PACKET_HOST > setting? an netdevice can only have one unicast MAC address. > SIOCDEVPRIVATE does not seem to be the right place to do this. > You still wanna have ability to do proper RFC2338 and related protocols > even when the h/ware is incapable. > And btw, i didnt even open up the whole can of worms - we also need to > respond back with proper MAC addresses to ARPs and packets sourced with > specific virtual router IPs. This is a seprate problem. Yup, a whole can of worms if you want it to be a general feature handled by the kernel... > PS: the hack credit (for using SIOCADDMULTI/DELMULTI) goes to Jerome > Ettiene (this is a guy who never responds to email, probably too busy > unicycling somewhere, so no point in ccing him) - Except it doesnt work > without the patch i posted. This has worked with the Tulip driver for many years. I've pointed it out to a number of people that requested this as a new feature. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From greearb@candelatech.com Fri Jan 3 23:27:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jan 2003 23:27:14 -0800 (PST) Received: from grok.yi.org (IDENT:y/lBUo/G7sVC/fHPgGIFpdnT/LA+YsNt@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h047R73v031116 for ; Fri, 3 Jan 2003 23:27:07 -0800 Received: from candelatech.com (IDENT:GiG52SjgERjL5eJLTbvF9iifiRF9b31f@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id h047WTl28818 for ; Fri, 3 Jan 2003 23:32:29 -0800 Message-ID: <3E168E0C.2040904@candelatech.com> Date: Fri, 03 Jan 2003 23:32:28 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'netdev@oss.sgi.com'" Subject: Anyone used the RAMIX 4-port adapter? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1452 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev RAMIX makes a 4-port 10/100 adapter based on the 82559 chipset. I was wondering if anyone has done any benchmarking on this adapter? -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From jgarzik@pobox.com Fri Jan 3 23:28:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jan 2003 23:28:36 -0800 (PST) Received: from www.linux.org.uk (parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h047SV3v031461 for ; Fri, 3 Jan 2003 23:28:32 -0800 Received: from rdu57-8-131.nc.rr.com ([66.57.8.131] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 18Uioa-00077l-00; Sat, 04 Jan 2003 07:33:52 +0000 Message-ID: <3E168E26.1030006@pobox.com> Date: Sat, 04 Jan 2003 02:32:54 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jamal CC: Donald Becker , Ben Greear , netdev@oss.sgi.com Subject: Re: SIOCADDMULTI for unicast broken References: <20030103224852.L48869@shell.cyberus.ca> In-Reply-To: <20030103224852.L48869@shell.cyberus.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1453 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev I wonder if there are any good uses for more advanced RX filtering that is beginning to appear. I could certainly imagine an interface that was a more generic RX filtering interface, and [just by accident] happened to support existing unicast and multicast rx-mode-related controls. As vendors stuff features onto cards and try to figure out where is the best dividing line between TCP stack acceleration and TCP stack offload, it seems to me that recent cards more often than not have nice RX filtering capabilities. If you look at the world through GigE-colored glasses, the RX filtering picture gets even better. There are some fun SMP implications with flexible enough RX filtering, for example. From haveblue@us.ibm.com Sat Jan 4 07:47:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Jan 2003 07:47:44 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h04FlZ3v006657 for ; Sat, 4 Jan 2003 07:47:36 -0800 Received: from northrelay05.pok.ibm.com (northrelay05.pok.ibm.com [9.56.224.23]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id h04Fqskm047998 for ; Sat, 4 Jan 2003 10:52:54 -0500 Received: from nighthawk.sr71.net (sig-9-65-26-24.mts.ibm.com [9.65.26.24]) by northrelay05.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h04FqqL8041350; Sat, 4 Jan 2003 10:52:52 -0500 Received: from us.ibm.com (dave@nighthawk [127.0.0.1]) by nighthawk.sr71.net (8.12.3/8.12.3/Debian -4) with ESMTP id h04FpF9s002175; Sat, 4 Jan 2003 07:51:15 -0800 Message-ID: <3E1702F2.9000105@us.ibm.com> Date: Sat, 04 Jan 2003 07:51:14 -0800 From: Dave Hansen User-Agent: Mozilla/5.0 (compatible; MSIE5.5; Windows 98; X-Accept-Language: en MIME-Version: 1.0 To: niv@us.ibm.com CC: netdev@oss.sgi.com Subject: Send-Q not being emptied Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1454 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: haveblue@us.ibm.com Precedence: bulk X-list: netdev I'm seeing some strange behavior running Specweb99 with 2.4.19-64GB-SMP on the clients, and 2.5.50 on the server. I'm using Apache/2.0.43. The load is fairly low, ~1000 (this is an 8-way P4). The client program is sitting blocked on a socket read(). It's netstat entry looks like this (I clipped off the PID/Program part): Recv-Q Send-Q Local Address Foreign Address State 0 0 192.168.1.100:35486 192.168.1.1:80 ESTABLISHED The server side's netstat (httpd): 0 120184 192.168.1.1:80 192.168.1.100:35486 ESTABLISHED It will stay like this for several minutes at a time, until the Specweb99 client program usually times out complaining with something like this: Sat Jan 4 10:05:28 2003 HTTPGetReply: got 272144, expected 614400 But, this doesn't always happen to the client, and sometimes it will stay blocking on that socket read() forever. This keeps me from getting any completed benchmark runs because there are always 1 or two of these stragglers. Why isn't the client's read ever completing, even if the server has data in its send queue? I'm sure that the cable is plugged in :) -- Dave Hansen haveblue@us.ibm.com From kunihiro@ipinfusion.com Sat Jan 4 07:58:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Jan 2003 07:58:28 -0800 (PST) Received: from localhost.localdomain (ip-64-139-11-202.dsl.sca.megapath.net [64.139.11.202]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h04FwO3v007126 for ; Sat, 4 Jan 2003 07:58:25 -0800 Received: from localhost.localdomain (vprmatrix [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h04G3jhK001694; Sun, 5 Jan 2003 01:03:45 +0900 Date: Sat, 04 Jan 2003 08:03:45 -0800 Message-ID: <873co8dhr2.wl@ipinfusion.com> From: Kunihiro Ishiguro To: netdev@oss.sgi.com CC: yoshfuji@linux-ipv6.org Subject: IPv6 auth header length calculation patch User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.92 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: multipart/mixed; boundary="Multipart_Sat_Jan__4_08:03:45_2003-1" X-archive-position: 1455 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kunihiro@ipinfusion.com Precedence: bulk X-list: netdev --Multipart_Sat_Jan__4_08:03:45_2003-1 Content-Type: text/plain; charset=US-ASCII This is a USAGI patch to fix IPv6 auth header length calculation. (I'm not USAGI member. I'm working on IPv6 IPsec based on 2.5 code base). RFC2402 2.2 Payload Length : This 8-bit field specifies the length of AH in 32-bit words (4-byte units), minus "2". (All IPv6 extension headers, as per RFC 1883, encode the "Hdr Ext Len" field by first subtracting 1 (64-bit word) from the header length (measured in 64-bit words). AH is an IPv6 extension header. However, since its length is measured in 32-bit words, the "Payload Length" is calculated by subtracting 2 (32 bit words).) In the "standard" case of a 96-bit authentication value Would you mind to apply this to avoid wrong header length calculation? --Multipart_Sat_Jan__4_08:03:45_2003-1 Content-Type: application/octet-stream; type=patch Content-Disposition: attachment; filename="ipv6-auth-hdr-length.diff" Content-Transfer-Encoding: 7bit --- exthdrs.c.orig 2003-01-04 07:59:31.000000000 -0800 +++ exthdrs.c 2003-01-04 07:59:41.000000000 -0800 @@ -402,7 +402,7 @@ if (!pskb_may_pull(skb, (skb->h.raw-skb->data)+8)) goto fail; - len = (skb->h.raw[1]+1)<<2; + len = (skb->h.raw[1]+2)<<2; if (len&7) goto fail; --Multipart_Sat_Jan__4_08:03:45_2003-1-- From yoshfuji@linux-ipv6.org Sat Jan 4 09:00:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Jan 2003 09:00:23 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h04H0G3v007808 for ; Sat, 4 Jan 2003 09:00:17 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian -4) with ESMTP id h04H5kGR006043 for ; Sun, 5 Jan 2003 02:05:46 +0900 Date: Sun, 05 Jan 2003 02:05:45 +0900 (JST) Message-Id: <20030105.020545.34113263.yoshfuji@linux-ipv6.org> To: netdev@oss.sgi.com Subject: Re: IPv6 auth header length calculation patch From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <873co8dhr2.wl@ipinfusion.com> References: <873co8dhr2.wl@ipinfusion.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1456 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <873co8dhr2.wl@ipinfusion.com> (at Sat, 04 Jan 2003 08:03:45 -0800), Kunihiro Ishiguro says: > This is a USAGI patch to fix IPv6 auth header length calculation. > (I'm not USAGI member. I'm working on IPv6 IPsec based on 2.5 code > base). : > Would you mind to apply this to avoid wrong header length calculation? Just a moment please. We'll make a patch for this by ourselves. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From hadi@cyberus.ca Sat Jan 4 09:36:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Jan 2003 09:36:16 -0800 (PST) Received: from mx03.cyberus.ca (mx03.cyberus.ca [216.191.240.24]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h04Ha83v008352 for ; Sat, 4 Jan 2003 09:36:08 -0800 Received: from shell.cyberus.ca ([216.191.240.114]) by mx03.cyberus.ca with esmtp (Exim 4.10) id 18UsIe-000BM8-00; Sat, 04 Jan 2003 12:41:32 -0500 Received: from shell.cyberus.ca (localhost.cyberus.ca [127.0.0.1]) by shell.cyberus.ca (8.12.6/8.12.6) with ESMTP id h04HfOkr053276; Sat, 4 Jan 2003 12:41:24 -0500 (EST) (envelope-from hadi@cyberus.ca) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.12.6/8.12.6/Submit) with ESMTP id h04HfNEt053273; Sat, 4 Jan 2003 12:41:23 -0500 (EST) (envelope-from hadi@cyberus.ca) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sat, 4 Jan 2003 12:41:23 -0500 (EST) From: jamal To: Donald Becker cc: Ben Greear , Jeff Garzik , "" Subject: Re: SIOCADDMULTI for unicast broken In-Reply-To: Message-ID: <20030104122619.R48869@shell.cyberus.ca> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1457 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sat, 4 Jan 2003, Donald Becker wrote: > On Fri, 3 Jan 2003, jamal wrote: > > > Too many emails to respond to at once. > > > > Q: Is this a hack? > > A: Yes, indeed it is. wrong API is the main culprit. > > > > Q: Is this a feature needed by only a few people? > > A: No, Absolutely not. RFC2338 is one example that needs > > The common way of handling this is unsolicited ARP. > unsolicited ARPs on failover are good. You send the arp with one of the allocated MAC addresses as the source. The hosts sending data use that MAC address as the dst MAC. Did i miss something or how do you see the packet making its way up the stack? > > How common are NICS such as the 21x4x that can be programmed to do > > perfect hashing and accept multiple MAC addresses in hardware? > > Not very common. I mentioned the 21*4* explicitly because few other > common chips implement this feature. > The Digital design implemented it because of DECnet, which is long dead. > Side, unrelated question: for h/ware multicast filtered multicast addresses: What is the common practise to handle the corner case where a hardware multicast address is filled up. Take an example of the tulip using perfect hashing when all the 16 entries are exhausted and the host still wants to subscribe to 100 other multicast groups... should we put the nic into promisc multicast? > > And if this was a commodity feature - what happens to PACKET_HOST > > setting? an netdevice can only have one unicast MAC address. > > SIOCDEVPRIVATE does not seem to be the right place to do this. > > You still wanna have ability to do proper RFC2338 and related protocols > > even when the h/ware is incapable. > > And btw, i didnt even open up the whole can of worms - we also need to > > respond back with proper MAC addresses to ARPs and packets sourced with > > specific virtual router IPs. This is a seprate problem. > > Yup, a whole can of worms if you want it to be a general feature handled > by the kernel... > I think hacking the ARP code to do this would be horrible - one way to do it is write a tc module that mungles outgoing ARPs to substitute the src MAC address based on src IP. > > PS: the hack credit (for using SIOCADDMULTI/DELMULTI) goes to Jerome > > Ettiene (this is a guy who never responds to email, probably too busy > > unicycling somewhere, so no point in ccing him) - Except it doesnt work > > without the patch i posted. > > This has worked with the Tulip driver for many years. I've pointed it > out to a number of people that requested this as a new feature. > didnt know that. I guess i was lucky not to have used the tulip when i got bitten by this. So, Donald, other than tulip what other NICs can do this? cheers, jamal From hadi@cyberus.ca Sat Jan 4 09:38:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Jan 2003 09:38:35 -0800 (PST) Received: from mx03.cyberus.ca (mx03.cyberus.ca [216.191.240.24]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h04HcW3v008711 for ; Sat, 4 Jan 2003 09:38:33 -0800 Received: from shell.cyberus.ca ([216.191.240.114]) by mx03.cyberus.ca with esmtp (Exim 4.10) id 18UsKy-000Bd8-00; Sat, 04 Jan 2003 12:43:56 -0500 Received: from shell.cyberus.ca (localhost.cyberus.ca [127.0.0.1]) by shell.cyberus.ca (8.12.6/8.12.6) with ESMTP id h04Hhnkr053282; Sat, 4 Jan 2003 12:43:49 -0500 (EST) (envelope-from hadi@cyberus.ca) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.12.6/8.12.6/Submit) with ESMTP id h04HhnlI053279; Sat, 4 Jan 2003 12:43:49 -0500 (EST) (envelope-from hadi@cyberus.ca) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sat, 4 Jan 2003 12:43:49 -0500 (EST) From: jamal To: Jeff Garzik cc: Donald Becker , Ben Greear , "" Subject: Re: SIOCADDMULTI for unicast broken In-Reply-To: <3E168E26.1030006@pobox.com> Message-ID: <20030104124133.H48869@shell.cyberus.ca> References: <20030103224852.L48869@shell.cyberus.ca> <3E168E26.1030006@pobox.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1458 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sat, 4 Jan 2003, Jeff Garzik wrote: > I wonder if there are any good uses for more advanced RX filtering that > is beginning to appear. I could certainly imagine an interface that was > a more generic RX filtering interface, and [just by accident] happened > to support existing unicast and multicast rx-mode-related controls. > > As vendors stuff features onto cards and try to figure out where is the > best dividing line between TCP stack acceleration and TCP stack offload, > it seems to me that recent cards more often than not have nice RX > filtering capabilities. If you look at the world through GigE-colored > glasses, the RX filtering picture gets even better. There are some fun > SMP implications with flexible enough RX filtering, for example. > Davem had some nifty ideas on this at least for TOE. I think we ought to start looking at that direction. Anyone who is working on this please involve me, i have some ideas (and it would avoid me stressing you when you output code). cheers, jamal From yoshfuji@linux-ipv6.org Sat Jan 4 09:43:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Jan 2003 09:43:45 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h04Hhe3v009105 for ; Sat, 4 Jan 2003 09:43:40 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian -4) with ESMTP id h04HmQGR006267; Sun, 5 Jan 2003 02:48:26 +0900 Date: Sun, 05 Jan 2003 02:48:23 +0900 (JST) Message-Id: <20030105.024823.61168301.yoshfuji@linux-ipv6.org> To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com CC: davem@redhat.com, kuznet@ms2.inr.ac.ru, usagi@linux-ipv6.org Subject: [PATCH] IPv6: Fix Length of Authentication Extension Header From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1459 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Hello! This patch fixes calculation of length of IPv6 Authentication Extension Header. RFC2402: 2.2 Payload Length : This 8-bit field specifies the length of AH in 32-bit words (4-byte units), minus "2". ... This is against linux-2.4.20, 2.5.54. (2.2.x series have similar bug, too.) Thanks in advance. ------------------------------------------------------------------- Patch-Name: Fix Length of Authentication Extension Header Patch-Id: FIX_2_4_20_EXTHDRS_AUTHHDRLEN-20030105 Patch-Author: YOSHIFUJI Hideaki / USAGI Project Credit: Noriaki Takamiya / USAGI Project Reference: RFC2402 ------------------------------------------------------------------- Index: net/ipv6/exthdrs.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/exthdrs.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.46.1 diff -u -r1.1.1.1 -r1.1.1.1.46.1 --- net/ipv6/exthdrs.c 20 Aug 2002 09:47:02 -0000 1.1.1.1 +++ net/ipv6/exthdrs.c 4 Jan 2003 17:19:03 -0000 1.1.1.1.46.1 @@ -402,7 +402,13 @@ if (!pskb_may_pull(skb, (skb->h.raw-skb->data)+8)) goto fail; - len = (skb->h.raw[1]+1)<<2; + /* + * RFC2402 2.2 Payload Length + * The 8-bit field specifies the length of AH in 32-bit words + * (4-byte units), minus "2". + * -- Noriaki Takamiya @USAGI Project + */ + len = (skb->h.raw[1]+2)<<2; if (len&7) goto fail; -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From becker@scyld.com Sat Jan 4 10:18:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Jan 2003 10:18:44 -0800 (PST) Received: from beohost.scyld.com (pool-151-196-171-250.balt.east.verizon.net [151.196.171.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h04IIZ3v009719 for ; Sat, 4 Jan 2003 10:18:37 -0800 Received: from localhost (becker@localhost) by beohost.scyld.com (8.11.6/8.11.6) with ESMTP id h04IORU04274; Sat, 4 Jan 2003 13:24:27 -0500 Date: Sat, 4 Jan 2003 13:24:26 -0500 (EST) From: Donald Becker To: jamal cc: Ben Greear , Jeff Garzik , Subject: Re: SIOCADDMULTI for unicast broken In-Reply-To: <20030104122619.R48869@shell.cyberus.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1460 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: becker@scyld.com Precedence: bulk X-list: netdev On Sat, 4 Jan 2003, jamal wrote: > On Sat, 4 Jan 2003, Donald Becker wrote: > > On Fri, 3 Jan 2003, jamal wrote: > > > Q: Is this a hack? > > > A: Yes, indeed it is. wrong API is the main culprit. I disagree: it's a hack usable by the very few people that need it. Defining an API would add little-used complexity. > > > How common are NICS such as the 21x4x that can be programmed to do > > > perfect hashing and accept multiple MAC addresses in hardware? > > > > Not very common. I mentioned the 21*4* explicitly because few other > > common chips implement this feature. > > The Digital design implemented it because of DECnet, which is long dead. > > Side, unrelated question: > for h/ware multicast filtered multicast addresses: What is the common > practise to handle the corner case where a hardware multicast address > is filled up. This is good example of why an API is a bad idea: there is no general case. The Tulip has 16 filter addresses, but... Oh, not all chips handled by the Tulip driver. Macronix does. Asix doesn't. ADMtek doesn't. PNIC chips do. You need one slot for the broadcast address on a few chip versions with a bug. (I do this unconditionally.) You cannot use the multicast hash filter. "Only in the month after the full moon falls on a Tuesday." > Take an example of the tulip using perfect hashing when > all the 16 entries are exhausted and the host still wants to subscribe > to 100 other multicast groups... should we put the nic into promisc > multicast? Yes. This is the DECnet case. > didnt know that. I guess i was lucky not to have used the tulip when i > got bitten by this. So, Donald, other than tulip what other NICs can do > this? Mostly gigabit Ethernet chips. There are a few FE chips that allow setting the multicast hash address to also filter physical addresses, but imperfect filters result in the same extra cdoe as using promiscuous mode. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From ja@ssi.bg Sat Jan 4 10:29:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Jan 2003 10:29:48 -0800 (PST) Received: from u.domain.uli (ja.mac.ssi.bg [217.79.71.194]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h04ITf3v010135 for ; Sat, 4 Jan 2003 10:29:44 -0800 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.6/8.11.6) with ESMTP id h04Iaco06455; Sat, 4 Jan 2003 20:36:38 +0200 Date: Sat, 4 Jan 2003 20:36:38 +0200 (EET) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: jamal cc: Donald Becker , Ben Greear , Jeff Garzik , Alexandre Cassen , Subject: Re: SIOCADDMULTI for unicast broken In-Reply-To: <20030104122619.R48869@shell.cyberus.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1461 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ja@ssi.bg Precedence: bulk X-list: netdev Hello, On Sat, 4 Jan 2003, jamal wrote: > > > And btw, i didnt even open up the whole can of worms - we also need to > > > respond back with proper MAC addresses to ARPs and packets sourced with > > > specific virtual router IPs. This is a seprate problem. > > > > Yup, a whole can of worms if you want it to be a general feature handled > > by the kernel... > > > > I think hacking the ARP code to do this would be horrible - one way to do > it is write a tc module that mungles outgoing ARPs to substitute the src > MAC address based on src IP. You can do it with arptables (still not sure how) or with arprules+iparp: # send all our requests from VRIP with VMAC ip arp add table output from 1.2.3.4 llsrc 00:00:5E:00:01:10 http://www.ssi.bg/~ja/#iparp But this is not enough for VRRP. For Linux we need a way to bind VRIPs to source VMACs or sort of this. I'm cc-ing to Alexandre Cassen as he is working on VRRP (http://keepalived.sourceforge.net/). I hope he can shed some light on the VRRP needs. > cheers, > jamal Regards -- Julian Anastasov From hadi@cyberus.ca Sat Jan 4 10:50:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Jan 2003 10:50:20 -0800 (PST) Received: from mx03.cyberus.ca (mx03.cyberus.ca [216.191.240.24]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h04IoG3v010626 for ; Sat, 4 Jan 2003 10:50:17 -0800 Received: from shell.cyberus.ca ([216.191.240.114]) by mx03.cyberus.ca with esmtp (Exim 4.10) id 18UtSP-000LH8-00; Sat, 04 Jan 2003 13:55:41 -0500 Received: from shell.cyberus.ca (localhost.cyberus.ca [127.0.0.1]) by shell.cyberus.ca (8.12.6/8.12.6) with ESMTP id h04ItXkr053408; Sat, 4 Jan 2003 13:55:33 -0500 (EST) (envelope-from hadi@cyberus.ca) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.12.6/8.12.6/Submit) with ESMTP id h04ItW9Z053405; Sat, 4 Jan 2003 13:55:32 -0500 (EST) (envelope-from hadi@cyberus.ca) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sat, 4 Jan 2003 13:55:32 -0500 (EST) From: jamal To: Donald Becker cc: Ben Greear , Jeff Garzik , "" Subject: Re: SIOCADDMULTI for unicast broken In-Reply-To: Message-ID: <20030104134308.G48869@shell.cyberus.ca> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1462 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sat, 4 Jan 2003, Donald Becker wrote: > > > On Fri, 3 Jan 2003, jamal wrote: > > > > Q: Is this a hack? > > > > A: Yes, indeed it is. wrong API is the main culprit. > > I disagree: it's a hack usable by the very few people that need it. > Defining an API would add little-used complexity. Somehow i (and people using VRRP or trying to write HSRP like apps) need to have multiple MAC addresses accepted by a single NIC. It is not really a science project reqnmt, rather needed by real-world apps which are becoming more common. The way i see it is:" a) Introduce new API b) reuse an API - considered a hack really c) maintain it as a separate patch; needs to be cleaned a little for optimization (example not all NICS may need this extra per packet check). Which one do you see as being reasonable? You cant say none of the above because people need this feature ;-> You have to present an alternative at least. > > > Side, unrelated question: > > for h/ware multicast filtered multicast addresses: What is the common > > practise to handle the corner case where a hardware multicast address > > is filled up. > > This is good example of why an API is a bad idea: there is no general > case. The Tulip has 16 filter addresses, but... > Oh, not all chips handled by the Tulip driver. Macronix does. Asix > doesn't. ADMtek doesn't. PNIC chips do. ok. > You need one slot for the broadcast address on a few chip versions > with a bug. (I do this unconditionally.) Make sense. > You cannot use the multicast hash filter. Why not? > > "Only in the month after the full moon falls on a Tuesday." > > > Take an example of the tulip using perfect hashing when > > all the 16 entries are exhausted and the host still wants to subscribe > > to 100 other multicast groups... should we put the nic into promisc > > multicast? > > Yes. This is the DECnet case. I dont think this is what we do today in general; does the tulip do this really? > > > didnt know that. I guess i was lucky not to have used the tulip when i > > got bitten by this. So, Donald, other than tulip what other NICs can do > > this? > > Mostly gigabit Ethernet chips. There are a few FE chips that allow > setting the multicast hash address to also filter physical addresses, > but imperfect filters result in the same extra cdoe as using promiscuous > mode. > OK, i guess this explains the imperfect filters; so since Giges are becoming such a commodity item, are you suggesting that since to do VRRP get yourself a Gige card or appropriate FE card? cheers, jamal From hadi@cyberus.ca Sat Jan 4 11:41:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Jan 2003 11:41:30 -0800 (PST) Received: from mx01.cyberus.ca (mx01.cyberus.ca [216.191.240.22]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h04JfL3v011277 for ; Sat, 4 Jan 2003 11:41:21 -0800 Received: from shell.cyberus.ca ([216.191.240.114]) by mx01.cyberus.ca with esmtp (Exim 4.10) id 18Utat-0001sy-00; Sat, 04 Jan 2003 14:04:27 -0500 Received: from shell.cyberus.ca (localhost.cyberus.ca [127.0.0.1]) by shell.cyberus.ca (8.12.6/8.12.6) with ESMTP id h04J4Jkr053430; Sat, 4 Jan 2003 14:04:19 -0500 (EST) (envelope-from hadi@cyberus.ca) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.12.6/8.12.6/Submit) with ESMTP id h04J4HDt053427; Sat, 4 Jan 2003 14:04:19 -0500 (EST) (envelope-from hadi@cyberus.ca) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sat, 4 Jan 2003 14:04:17 -0500 (EST) From: jamal To: Julian Anastasov cc: Donald Becker , Ben Greear , Jeff Garzik , Alexandre Cassen , "" Subject: Re: SIOCADDMULTI for unicast broken In-Reply-To: Message-ID: <20030104135539.C48869@shell.cyberus.ca> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1463 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sat, 4 Jan 2003, Julian Anastasov wrote: > > Hello, > > On Sat, 4 Jan 2003, jamal wrote: > > > > > I think hacking the ARP code to do this would be horrible - one way to do > > it is write a tc module that mungles outgoing ARPs to substitute the src > > MAC address based on src IP. > > You can do it with arptables (still not sure how) or with I havent seen user-space arptables around. > arprules+iparp: > > # send all our requests from VRIP with VMAC > ip arp add table output from 1.2.3.4 llsrc 00:00:5E:00:01:10 > > http://www.ssi.bg/~ja/#iparp I like this concept. This + the patch i posted should resolve the problem of getting multiple VRIDs on a single interface. [Although you could do it in a lot less code, maybe 50%, using some of the tc filter extensions i am working on; also a lot less code than arptables] > > But this is not enough for VRRP. For Linux we need a > way to bind VRIPs to source VMACs or sort of this. I'm cc-ing to Alexandre > Cassen as he is working on VRRP (http://keepalived.sourceforge.net/). > I hope he can shed some light on the VRRP needs. > I guess there is more than one VRRP implementation on Linux; the one i played with is from some crazy Frenchman named Jerome Ettiene;-> With two conecpts being addressed i.e patch like that you have + the patch i posted i dont see any orther reason VRRP to be hindered. cheers, jamal From niv@us.ibm.com Sat Jan 4 17:06:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Jan 2003 17:07:03 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0516t3v013610 for ; Sat, 4 Jan 2003 17:06:55 -0800 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e32.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h051CKn0075876 for ; Sat, 4 Jan 2003 20:12:20 -0500 Received: from us.ibm.com (sig-9-65-27-210.mts.ibm.com [9.65.27.210]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h051CHk4004594; Sat, 4 Jan 2003 18:12:18 -0700 Message-ID: <3E178620.53128BE6@us.ibm.com> Date: Sat, 04 Jan 2003 17:10:56 -0800 From: Nivedita Singhvi Reply-To: niv@us.ibm.com X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave Hansen CC: netdev@oss.sgi.com Subject: Re: Send-Q not being emptied References: <3E1702F2.9000105@us.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1464 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Dave Hansen wrote: > > I'm seeing some strange behavior running Specweb99 with > 2.4.19-64GB-SMP on the clients, and 2.5.50 on the server. I'm using > Apache/2.0.43. The load is fairly low, ~1000 (this is an 8-way P4). > > The client program is sitting blocked on a socket read(). It's > netstat entry looks like this (I clipped off the PID/Program part): > Recv-Q Send-Q Local Address Foreign Address State > 0 0 192.168.1.100:35486 192.168.1.1:80 ESTABLISHED > The server side's netstat (httpd): > 0 120184 192.168.1.1:80 192.168.1.100:35486 ESTABLISHED > It will stay like this for several minutes at a time, until the > Specweb99 client program usually times out complaining with something > like this: > Sat Jan 4 10:05:28 2003 HTTPGetReply: got 272144, expected 614400 > > But, this doesn't always happen to the client, and sometimes it will > stay blocking on that socket read() forever. This keeps me from > getting any completed benchmark runs because there are always 1 or two > of these stragglers. hmmm, send side window was closed and we lost an update? or we had a lot of successive drops and we're backed off and client terminated before we retransmitted? but, why doesnt the client time out in all instances? is the send side always still around in established state? if the sending thread got killed for some reason, the client might have gotten a reset back.. > Why isn't the client's read ever completing, even if the server has > data in its send queue? I'm sure that the cable is plugged in :) you've probably turned off sack etc, right? what are your settings? taking a look at the stats would be useful..also tried pinging just to make sure the interface is still up and not jammed? thanks, Nivedita From ja@ssi.bg Sun Jan 5 03:39:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Jan 2003 03:39:12 -0800 (PST) Received: from u.domain.uli (ja.mac.ssi.bg [217.79.71.194]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h05Bcw3v030057 for ; Sun, 5 Jan 2003 03:39:03 -0800 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.6/8.11.6) with ESMTP id h05BjjA09843; Sun, 5 Jan 2003 13:45:46 +0200 Date: Sun, 5 Jan 2003 13:45:45 +0200 (EET) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: jamal cc: Donald Becker , Ben Greear , Jeff Garzik , Alexandre Cassen , Subject: Re: SIOCADDMULTI for unicast broken In-Reply-To: <20030104135539.C48869@shell.cyberus.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1465 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ja@ssi.bg Precedence: bulk X-list: netdev Hello, On Sat, 4 Jan 2003, jamal wrote: > > You can do it with arptables (still not sure how) or with > > I havent seen user-space arptables around. yes, that is what I mean > > http://www.ssi.bg/~ja/#iparp > > I like this concept. This + the patch i posted should resolve the problem > of getting multiple VRIDs on a single interface. > [Although you could do it in a lot less code, maybe 50%, using > some of the tc filter extensions i am working on; also a lot less code > than arptables] I hope there will be support for altering any bit in the skb->head - skb->end area, even by using negative offsets based on skb->nh.raw - this is needed for eth header manipulations. May be sort of: ... alter andmask 0xFF00 xormask 0x0023 at -4 ... i.e. syntax similar to ipchains TOS and u32 match. As for VRRP I see it in this way. Note that I'm not a VRRP fan, I prefer the ARP methods for takeover, Of course, sometimes they can not work due to the bad non-Linux ARP stack implementations. As Alexandre noted once, the gratuitous ARP should not be slower than VRRP talks. Only that there are bad ARP cache implementations. 1. if remote hosts asks for lladdr of VRIP tc should modify our ARP reply: the SMAC in the eth header (using negative offset) and the SMAC in the ARP header. This is analog to: ip arp add to VRIP llsrc VMAC 2. if our IP stack sends packet with saddr=VRIP that leads to ARP probe sent from our host then we should modify the packet in the same way as (1). This is analog to: ip arp add table output from VRIP llsrc VMAC 3. Replace the src MAC with proper VMAC for all IP packets with saddr=VRIP. This can be a neighbouring code job but difficult to implement there. 4. Not last: NIC should accept traffic for all VMACs (promisc when attached to switched hubs is enough?) and eth_type_trans to maintain list of MAC aliases. I'm not sure that such list/hashtable with MACs should be attached per device - may be VRRP needs to announce one MAC through different interfaces? Also think for the Bridging code which calls eth_type_trans too. 5. Enough from one who don't like VRRP :) > With two conecpts being addressed i.e patch like that you have + > the patch i posted i dont see any orther reason VRRP to be hindered. Not sure, may be the only remaining is (3). > cheers, > jamal Regards -- Julian Anastasov From lpri@xs4all.nl Sun Jan 5 17:01:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Jan 2003 17:01:50 -0800 (PST) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0611d3v009852 for ; Sun, 5 Jan 2003 17:01:41 -0800 Received: from xs4all.nl (a80-126-66-148.adsl.xs4all.nl [80.126.66.148]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id h061769V003666; Mon, 6 Jan 2003 02:07:07 +0100 (CET) Message-ID: <3E18D6BD.7080300@xs4all.nl> Date: Mon, 06 Jan 2003 02:07:09 +0100 From: Len Remmerswaal User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com, submit@bugs.debian.org Subject: Patch in kernel/driver/net/sis900.* to get Sis948 chipset's NIC running Content-Type: multipart/mixed; boundary="------------020902030108040609080000" X-archive-position: 1466 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lpri@xs4all.nl Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------020902030108040609080000 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Package: kernel-source-2.2.20 Version 2.2.20-5 Files: driver/net/sis900.* I have never done any Linux related bug-shooting, so I am not sure wether you guys are the right persons to send this to and if it is in the right form. The docs seem to point in your direction :-). If not so please inform me of the rigth channels. Also I have not quite set up all the rigth e-mail accounts yet, so I would appreciate not to publish my email address, exposing it to spam bots. When firing up Linux (Debian Woody 3.0 rev 0) on my beatiful new Asus P4S8X motherboard (SiS948 chipset), the NIC would not be recognised properly, with an ugly message: "eth0: Error EERPOM read 0xffff". I found no solutions on the debian support mailing list, so I had a peek in the source. Turns out that the driver sis900.c knows up to version 0x90, while the chipset has a version 0x91 (says lspci). I gambled that treating version 0x91 as if it were a version 0x90 might work. It did. This is the response I get now, and it works fine for me: Jan 5 11:32:13 donar kernel: sis900.c: v1.06.09-1 09/28/2001 Jan 5 11:32:13 donar kernel: eth0: SiS 900 PCI Fast Ethernet at 0x9800, IRQ 5, 00:e0:06:09:55:66. Jan 5 11:32:13 donar kernel: eth0: Unknown PHY transceiver found at address 1. Jan 5 11:32:13 donar kernel: eth0: Using transceiver found at address 1 as default Please find the patches to do this attached. I checked the 2.4.18 source: Nothing changed on this detail so things should work here too. I read that I should like test this on 5 different machines and 6 different configurations before submitting. I do not have such resources. Hope this helps anyway. Len Remmerswaal --------------020902030108040609080000 Content-Type: text/plain; name="sis900.c.2_2_10.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sis900.c.2_2_10.patch" --- sis900.c_original Fri Nov 2 17:39:07 2001 +++ sis900.c Mon Jan 6 01:54:32 2003 @@ -18,6 +18,7 @@ preliminary Rev. 1.0 Jan. 18, 1998 http://www.sis.com.tw/support/databook.htm + Rev 1.06.09-1 Jan. 05 2002 Len Remmerswaal update for 948 chipset Rev 1.06.09 Sep. 28 2001 Hui-Fen Hsu (hfhsu@sis.com.tw) update for 630ET & workaround for ICS1893 PHY Rev 1.06.08 Mar. 2 2001 Hui-Fen Hsu (hfhsu@sis.com.tw) some bug fix & 635M/B support Rev 1.06.07 Jan. 8 2001 Lei-Chun Chang added RTL8201 PHY support @@ -55,7 +56,7 @@ #include "sis900.h" static const char *version = -"sis900.c: v1.06.09 09/28/2001\n"; +"sis900.c: v1.06.09-1 09/28/2001\n"; static int max_interrupt_work = 20; static int multicast_filter_limit = 128; @@ -148,7 +149,7 @@ #ifdef MODULE #if LINUX_VERSION_CODE > 0x20115 MODULE_AUTHOR("Jim Huang , Ollie Lho "); -MODULE_DESCRIPTION("SiS 900 PCI Fast Ethernet driver"); +MODULE_DESCRIPTION("SiS 900 PCI Fast Ethernet driver - adapted for Sis948"); MODULE_PARM(multicast_filter_limit, "i"); MODULE_PARM(max_interrupt_work, "i"); MODULE_PARM(debug, "i"); @@ -334,14 +335,14 @@ sis_priv->pci_dev = pci_dev; sis_priv->mac = mac; + /* gambling that version 0x91 will behave as a 0x90 */ pci_read_config_byte(pci_dev, PCI_CLASS_REVISION, &revision); if ( revision == SIS630E_900_REV ) ret = sis630e_get_mac_addr(pci_dev, net_dev); - else if ((revision > 0x81) && (revision <= 0x90)) + else if ((revision > 0x81) && (revision <= 0x91 )) ret = sis635_get_mac_addr(pci_dev, net_dev); else ret = sis900_get_mac_addr(pci_dev, net_dev); - if (ret == 0) { unregister_netdev(net_dev); return NULL; --------------020902030108040609080000 Content-Type: text/plain; name="sis900.h.2_2_10.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sis900.h.2_2_10.patch" --- sis900.h_original Fri Nov 2 17:39:07 2001 +++ sis900.h Tue Dec 31 22:57:17 2002 @@ -10,6 +10,8 @@ * http://www.sis.com.tw/support/databook.htm */ +/* Len R.: Adapted to include sis900 revision ID 0x91 */ + /* MAC operationl registers of SiS 7016 and SiS 900 ehternet controller */ /* The I/O extent, SiS 900 needs 256 bytes of io address */ #define SIS900_TOTAL_SIZE 0x100 @@ -233,11 +235,14 @@ MII_STSSUM_AUTO = 0x0002, MII_STSSUM_SPD = 0x0001 }; +/* Len R.: New revision SIS963_900_REV added (963 is the chip's name) */ + enum sis900_revision_id { SIS630A_900_REV = 0x80, SIS630E_900_REV = 0x81, SIS630S_900_REV = 0x82, SIS630EA1_900_REV = 0x83, SIS630ET_900_REV = 0x84, SIS635A_900_REV = 0x90, - SIS900B_900_REV = 0x03 + SIS900B_900_REV = 0x03, + SIS963_900_REV = 0x91 }; enum sis630_revision_id { --------------020902030108040609080000-- From davem@redhat.com Sun Jan 5 23:01:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Jan 2003 23:01:14 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h067173v014261 for ; Sun, 5 Jan 2003 23:01:08 -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 WAA09672; Sun, 5 Jan 2003 22:58:22 -0800 Date: Sun, 05 Jan 2003 22:58:21 -0800 (PST) Message-Id: <20030105.225821.110535291.davem@redhat.com> To: yoshfuji@linux-ipv6.org Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix Length of Authentication Extension Header From: "David S. Miller" In-Reply-To: <20030105.024823.61168301.yoshfuji@linux-ipv6.org> References: <20030105.024823.61168301.yoshfuji@linux-ipv6.org> X-FalunGong: Information control. 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 X-archive-position: 1467 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Patch applied, thanks. From werner@almesberger.net Mon Jan 6 03:59:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Jan 2003 03:59:26 -0800 (PST) Received: from host.almesberger.net (IDENT:B6kWqRf6Yedp+umcxStkSlSJ+Vg/3wbk@almesberger.net [63.105.73.239] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h06BxH3v021282 for ; Mon, 6 Jan 2003 03:59:17 -0800 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.9.3/8.9.3) with ESMTP id EAA14699 for ; Mon, 6 Jan 2003 04:04:43 -0800 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id h06C4eZ30243 for netdev@oss.sgi.com; Mon, 6 Jan 2003 09:04:40 -0300 Date: Mon, 6 Jan 2003 09:04:39 -0300 From: Werner Almesberger To: netdev@oss.sgi.com Subject: Re: TCP connection passing, version 6 Message-ID: <20030106090439.A27389@almesberger.net> References: <20021221034809.A17934@almesberger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021221034809.A17934@almesberger.net>; from wa@almesberger.net on Sat, Dec 21, 2002 at 03:48:09AM -0300 X-archive-position: 1468 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wa@almesberger.net Precedence: bulk X-list: netdev Another minor update: http://www.almesberger.net/tcpcp/tcpcp-6.tar.gz md5sum 92bfafd1a8fe253b8793b222d8f7f386 This one brings the kernel version (normal and for UML) to 2.5.54, and also gets the testing framework a little step closer to usefulness. - Werner ----------------------------------- CHANGES ----------------------------------- Version 6 (6-JAN-2003) ---------------------- - upgraded to the 2.5.54 kernel for regular build and for UML - README: clarified that connection passing is transparent to the peer - README: clarified that "local adress" means IP address (reported by Patrick Schaaf) - added references to LVS and Cisco's SLB (suggested by Patrick Schaaf) - uml/Makefile: root_fs is now a direct make target - umlrun: run_agent can now also run directly under run_master - umlrun: added client IDs and session disconnect/reconnect -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From hadi@cyberus.ca Mon Jan 6 05:39:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Jan 2003 05:39:29 -0800 (PST) Received: from mx02.cyberus.ca (mx02.cyberus.ca [216.191.240.26]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h06DdK3v023051 for ; Mon, 6 Jan 2003 05:39:21 -0800 Received: from shell.cyberus.ca ([216.191.240.114]) by mx02.cyberus.ca with esmtp (Exim 4.10) id 18VXYh-000MeG-00; Mon, 06 Jan 2003 08:44:51 -0500 Received: from shell.cyberus.ca (localhost.cyberus.ca [127.0.0.1]) by shell.cyberus.ca (8.12.6/8.12.6) with ESMTP id h06Dickr057636; Mon, 6 Jan 2003 08:44:38 -0500 (EST) (envelope-from hadi@cyberus.ca) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.12.6/8.12.6/Submit) with ESMTP id h06DiUM4057633; Mon, 6 Jan 2003 08:44:32 -0500 (EST) (envelope-from hadi@cyberus.ca) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 6 Jan 2003 08:44:30 -0500 (EST) From: jamal To: Julian Anastasov cc: Donald Becker , Ben Greear , Jeff Garzik , Alexandre Cassen , "" Subject: Re: SIOCADDMULTI for unicast broken In-Reply-To: Message-ID: <20030105213057.T55522@shell.cyberus.ca> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1469 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sun, 5 Jan 2003, Julian Anastasov wrote: > > Hello, > > On Sat, 4 Jan 2003, jamal wrote: > > > > You can do it with arptables (still not sure how) or with > > > > I havent seen user-space arptables around. > > yes, that is what I mean > > > > http://www.ssi.bg/~ja/#iparp > > > > I like this concept. This + the patch i posted should resolve the problem > > of getting multiple VRIDs on a single interface. > > [Although you could do it in a lot less code, maybe 50%, using > > some of the tc filter extensions i am working on; also a lot less code > > than arptables] > > I hope there will be support for altering any bit > in the skb->head - skb->end area, even by using negative offsets > based on skb->nh.raw - this is needed for eth header manipulations. > May be sort of: ... alter andmask 0xFF00 xormask 0x0023 at -4 ... > i.e. syntax similar to ipchains TOS and u32 match. I wanted to use u32 as the basis; which means u32 type matching is needed. then use vi/sed type substitution s/OL/V where: O = offset (from skb->data, could be -ve), L = length (cant go beyond head or end), V is a static value configured (its size cant exceed L). V can also be computed off something example the data at offset O. I am trying to keep away from situations where L is larger or smaller than sizeof V so theres no mucking with any of the skb pointers ore reallocing etc. In the next iteration things could change. Note i havent written this but will in the near future (so anyone is welcome to hack on it) I didnt understand your andmask and xormask idea... > > As for VRRP I see it in this way. Note that I'm not a VRRP > fan, I prefer the ARP methods for takeover, Of course, sometimes they > can not work due to the bad non-Linux ARP stack implementations. > As Alexandre noted once, the gratuitous ARP should not be slower > than VRRP talks. Only that there are bad ARP cache implementations. > yes, this is a big problem. But also in some complex multi-vlan switches grat arps are not sufficient. > 1. if remote hosts asks for lladdr of VRIP tc should modify our > ARP reply: the SMAC in the eth header (using negative offset) and the > SMAC in the ARP header. This is analog to: > ip arp add to VRIP llsrc VMAC > I really like the brevity of the above; equivalent for me would be (my longterm plan to move ingress to below IP has finaly found an excuse) tc filter add parent x:y protocol arp prio 10 u32 flowid x:z \ match sip VRIP action edit s/smac/VMAC action edit s/SMAC/VMAC u32 needs to be taught about ARP so it can understand different ARP header bits like sip (shouldnt be that difficult) > > 2. if our IP stack sends packet with saddr=VRIP that leads to ARP > probe sent from our host then we should modify the packet in > the same way as (1). This is analog to: > ip arp add table output from VRIP llsrc VMAC > Dont see the difference between 1) and 2) > 3. Replace the src MAC with proper VMAC for all IP packets with > saddr=VRIP. This can be a neighbouring code job but difficult to > implement there. tc filter add parent x:y protocol ip prio 10 u32 flowid x:z \ match ip src VRIP action edit s/smac/VMAC Did i understand this correctly? > > 4. Not last: NIC should accept traffic for all VMACs (promisc > when attached to switched hubs is enough?) and eth_type_trans to maintain > list of MAC aliases. I'm not sure that such list/hashtable with MACs > should be attached per device - may be VRRP needs to announce one > MAC through different interfaces? Also think for the Bridging > code which calls eth_type_trans too. I plan to move ingress to below IP just before the bridging and tap code; experiments shows this works just fine. So all the filters + edits going there should work fine. Thoughts? cheers, jamal From ja@ssi.bg Mon Jan 6 06:57:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Jan 2003 06:58:02 -0800 (PST) Received: from l.himel.bg (IDENT:root@unamed.infotel.bg [212.39.68.18] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h06Evi3v024418 for ; Mon, 6 Jan 2003 06:57:48 -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 RAA27861; Mon, 6 Jan 2003 17:00:30 +0200 Date: Mon, 6 Jan 2003 17:00:30 +0200 (EET) From: Julian Anastasov X-X-Sender: ja@l To: jamal cc: Donald Becker , Ben Greear , Jeff Garzik , Alexandre Cassen , Subject: Re: SIOCADDMULTI for unicast broken In-Reply-To: <20030105213057.T55522@shell.cyberus.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1470 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ja@ssi.bg Precedence: bulk X-list: netdev Hello, On Mon, 6 Jan 2003, jamal wrote: > > May be sort of: ... alter andmask 0xFF00 xormask 0x0023 at -4 ... > > i.e. syntax similar to ipchains TOS and u32 match. > > I wanted to use u32 as the basis; which means u32 type matching is needed. > then use vi/sed type substitution s/OL/V where: > O = offset (from skb->data, could be -ve), IMO, using skb->nh.raw as basis is preferred. By this way the filters can be used from different places in the net stack. > L = length (cant go beyond head or end), > V is a static value configured (its size cant exceed L). V can also > be computed off something example the data at offset O. I am trying to > keep away from situations where L is larger or smaller than sizeof V > so theres no mucking with any of the skb pointers ore reallocing etc. In Yes, changing skb len is problematic mostly for TCP. As for L and V: I assume they are HEX digits or there will be a way to encode alphanumeric chars? > the next iteration things could change. Note i havent written this but > will in the near future (so anyone is welcome to hack on it) > I didnt understand your andmask and xormask idea... The above example: - goto word at offset -4 - AND the 2 bytes with FF00 - XOR the 2 bytes with 0023 AND+XOR allow any operations for bits: 1) preserving (AND 1 XOR 0) 2) inverting (AND 1 XOR 1) 3) setting (AND 0 XOR 1) 4) clearing (AND 0 XOR 0) > equivalent for me would be (my longterm plan to move ingress to below > IP has finaly found an excuse) > tc filter add parent x:y protocol arp prio 10 u32 flowid x:z \ > match sip VRIP action edit s/smac/VMAC action edit s/SMAC/VMAC > > u32 needs to be taught about ARP so it can understand different > ARP header bits like sip (shouldnt be that difficult) Yes, we can teach u32 to know about ARP offsets, ethhdr offsets... > > ip arp add table output from VRIP llsrc VMAC > > > > Dont see the difference between 1) and 2) No difference for tc, only iparp has this difference because it follows the routing > > 3. Replace the src MAC with proper VMAC for all IP packets with > > saddr=VRIP. This can be a neighbouring code job but difficult to > > implement there. > > tc filter add parent x:y protocol ip prio 10 u32 flowid x:z \ > match ip src VRIP action edit s/smac/VMAC > > Did i understand this correctly? Yes > > MAC through different interfaces? Also think for the Bridging > > code which calls eth_type_trans too. > > I plan to move ingress to below IP just before the bridging and tap > code; experiments shows this works just fine. > So all the filters + edits going there should work fine. Thoughts? I assume just after skb->nh.raw = skb->data; Also, before or after deliver to ptype_all? I see one problem: egress is called after all csum calcs, bad for IP (if tc is going to damage the payload), good for ethhdr, ARP. > cheers, > jamal Regards -- Julian Anastasov From khc@pm.waw.pl Mon Jan 6 07:09:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Jan 2003 07:10:02 -0800 (PST) Received: from hq.pm.waw.pl (hq.pm.waw.pl [195.116.170.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h06F9G3v024907 for ; Mon, 6 Jan 2003 07:09:27 -0800 Received: by hq.pm.waw.pl (Postfix, from userid 10) id 9A31231CA; Mon, 6 Jan 2003 16:14:46 +0100 (CET) Received: by defiant.pm.waw.pl (Postfix, from userid 500) id D1F4B3CBDE; Mon, 6 Jan 2003 16:00:33 +0100 (CET) To: netdev@oss.sgi.com Subject: Re: SIOCADDMULTI for unicast broken References: <3E163CBB.30206@candelatech.com> <3E163E4D.5090007@pobox.com> From: Krzysztof Halasa Date: 06 Jan 2003 16:00:33 +0100 In-Reply-To: <3E163E4D.5090007@pobox.com> Message-ID: Lines: 14 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1471 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: khc@pm.waw.pl Precedence: bulk X-list: netdev Jeff Garzik writes: > No! procfs additions are discouraged. sysfs in 2.5.x if you _must_ > do this, but SIOCDEVPRIVATE or just flat out maintaining a kernel > patch against a stable kernel tree would be much preferred, I think. Still, SIOCDEVPRIVATE should _not_, in my opinion, be used for anything but hacks. For example, we should stop using it for configuring ethernet bridges: net/bridge/br_device.c: if (cmd != SIOCDEVPRIVATE) -- Krzysztof Halasa Network Administrator From hadi@cyberus.ca Mon Jan 6 09:18:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Jan 2003 09:18:12 -0800 (PST) Received: from mx01.cyberus.ca (mx01.cyberus.ca [216.191.240.22]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h06HI43v027759 for ; Mon, 6 Jan 2003 09:18:05 -0800 Received: from shell.cyberus.ca ([216.191.240.114]) by mx01.cyberus.ca with esmtp (Exim 4.10) id 18VayN-000MnW-00; Mon, 06 Jan 2003 12:23:35 -0500 Received: from shell.cyberus.ca (localhost.cyberus.ca [127.0.0.1]) by shell.cyberus.ca (8.12.6/8.12.6) with ESMTP id h06HNMkr058076; Mon, 6 Jan 2003 12:23:22 -0500 (EST) (envelope-from hadi@cyberus.ca) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.12.6/8.12.6/Submit) with ESMTP id h06HNJN8058073; Mon, 6 Jan 2003 12:23:20 -0500 (EST) (envelope-from hadi@cyberus.ca) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 6 Jan 2003 12:23:19 -0500 (EST) From: jamal To: Julian Anastasov cc: Donald Becker , Ben Greear , Jeff Garzik , Alexandre Cassen , "" Subject: Re: SIOCADDMULTI for unicast broken In-Reply-To: Message-ID: <20030106121218.R57730@shell.cyberus.ca> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1472 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Julian, On Mon, 6 Jan 2003, Julian Anastasov wrote: > > Hello, > > On Mon, 6 Jan 2003, jamal wrote: > > > > May be sort of: ... alter andmask 0xFF00 xormask 0x0023 at -4 ... > > > i.e. syntax similar to ipchains TOS and u32 match. > > > > I wanted to use u32 as the basis; which means u32 type matching is needed. > > then use vi/sed type substitution s/OL/V where: > > O = offset (from skb->data, could be -ve), > > IMO, using skb->nh.raw as basis is preferred. By this way > the filters can be used from different places in the net stack. Makes sense, let me think about it more and maybe experiment. "different places in the stack"? I was thinking only ingress or egress. > > > L = length (cant go beyond head or end), > > V is a static value configured (its size cant exceed L). V can also > > be computed off something example the data at offset O. I am trying to > > keep away from situations where L is larger or smaller than sizeof V > > so theres no mucking with any of the skb pointers ore reallocing etc. In > > Yes, changing skb len is problematic mostly for TCP. As > for L and V: I assume they are HEX digits or there will be a way > to encode alphanumeric chars? > We leave that to user space. User space can translate from strings for example into hex. But yes, hex should be the default as is now. > > the next iteration things could change. Note i havent written this but > > will in the near future (so anyone is welcome to hack on it) > > I didnt understand your andmask and xormask idea... > > The above example: > > - goto word at offset -4 > - AND the 2 bytes with FF00 > - XOR the 2 bytes with 0023 > > AND+XOR allow any operations for bits: > > 1) preserving (AND 1 XOR 0) > 2) inverting (AND 1 XOR 1) > 3) setting (AND 0 XOR 1) > 4) clearing (AND 0 XOR 0) > Ok, makes sense and oughta be used. > > u32 needs to be taught about ARP so it can understand different > > ARP header bits like sip (shouldnt be that difficult) > > Yes, we can teach u32 to know about ARP offsets, > ethhdr offsets... ethheaders are i think generic enough to be done first. > > > I plan to move ingress to below IP just before the bridging and tap > > code; experiments shows this works just fine. > > So all the filters + edits going there should work fine. Thoughts? > > I assume just after skb->nh.raw = skb->data; > Also, before or after deliver to ptype_all? yes before ptype_all i.e the first thing. But it could be a programmability thing where you at least allow ptype_all to see things. > > I see one problem: egress is called after all csum calcs, > bad for IP (if tc is going to damage the payload), good for ethhdr, ARP. > well unless you pass options to recalculate csums or make csum an action by itself. I am thinking of "auxillary" actions which could be done by all actions - this could be one of them; logging is another; "change classid" is another. Lets take this discussion offline, i think we have exceeded the topic that started it all and people are hitting "D"s. cheers, jamal From Kazunori.Miyazawa@jp.yokogawa.com Mon Jan 6 19:58:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Jan 2003 19:58:45 -0800 (PST) Received: from zns001-0m9001.yokogawa.co.jp (zns001-0m9001.yokogawa.co.jp [203.174.79.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h073ue3v020665 for ; Mon, 6 Jan 2003 19:58:34 -0800 Received: from zns001-0m9001.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9001.yokogawa.co.jp (8.11.6+Sun/8.11.6) with ESMTP id h0742AP27300 for ; Tue, 7 Jan 2003 13:02:14 +0900 (JST) Received: from EXCHANGE03.jp.ykgw.net (zex001-0m9003.jp.ykgw.net [10.0.10.54]) by zns001-0m9001.yokogawa.co.jp (8.11.6+Sun/8.11.6) with ESMTP id h07423Q27260; Tue, 7 Jan 2003 13:02:03 +0900 (JST) Received: from monza.miyazawa.org ([10.0.68.152]) by EXCHANGE03.jp.ykgw.net with Microsoft SMTPSVC(5.0.2195.5329); Tue, 7 Jan 2003 13:02:03 +0900 Date: Tue, 7 Jan 2003 13:00:50 +0900 From: Kazunori Miyazawa To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Cc: usagi-core@linux-ipv6.org Subject: [PATCH] IPsec Configuration Extension for IPv6 Message-Id: <20030107130050.0903bf59.Kazunori.Miyazawa@jp.yokogawa.com> X-Mailer: Sylpheed version 0.8.8 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jan 2003 04:02:03.0631 (UTC) FILETIME=[8967F7F0:01C2B601] X-archive-position: 1473 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Kazunori.Miyazawa@jp.yokogawa.com Precedence: bulk X-list: netdev A happy new year! This patch is simple extension of PF_KEY to support IPv6; to accept IPv6 IPsec configurations. {SAs, Policies} for both IPv4 and IPv6 are maintained in a single {SA, Policy} database because of its simplicity. At a performance view point, we would get enough performance with separating caches. However this patch does not contain any codes to process the packets in IPv6 stack because we wonder how we should implement it: 1. The building packet codes of datagram (ip_append_data()) is very different from ip6_build_xmit(). And I guess you will change ip6_build_xmit() to ip6_append_data(). 2. How should we implement to process destination option header which is inside of AH and/or ESP? There seems two options. One is to process IPsec on parsing extension headers. The other is to process IPsec as upper layer protocol and we always check the destination option header when we finish to process AH or ESP. We will be glad to hear your preferences, plans or a better way to implementation. This patch is against 2.5.54. Thanks in advance. ------------------------------------------------------------------- Patch-Name: IPsec Configuration Extension for IPv6 Patch-Id: IPSEC_2_5_54_PFKEY_IPV6-20030107 Patch-Author: MIYAZAWA Kazunori / USAGI Project Credit: MIYAZAWA Kazunori / USAGI Project YOSHIFUJI Hideaki / USAGI Project ------------------------------------------------------------------- Index: include/net/xfrm.h =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux25/include/net/xfrm.h,v retrieving revision 1.1.1.4 retrieving revision 1.1.1.4.2.1 diff -u -r1.1.1.4 -r1.1.1.4.2.1 --- include/net/xfrm.h 23 Nov 2002 11:09:21 -0000 1.1.1.4 +++ include/net/xfrm.h 6 Jan 2003 15:40:10 -0000 1.1.1.4.2.1 @@ -4,9 +4,11 @@ #include #include #include +#include #include #include +#include extern struct semaphore xfrm_cfg_sem; @@ -259,6 +261,21 @@ !((fl->fl4_src^sel->saddr.xfrm4_addr)&sel->saddr.xfrm4_mask); } +static inline int +xfrm6_selector_match(struct xfrm_selector *sel, struct flowi *fl) +{ + return memcmp(fl->fl6_dst, + &sel->daddr, + sizeof(struct in6_addr)) && + memcmp(fl->fl6_src, + &sel->saddr, + sizeof(struct in6_addr)) && + !((fl->uli_u.ports.dport^sel->dport)&sel->dport_mask) && + !((fl->uli_u.ports.sport^sel->sport)&sel->sport_mask) && + (fl->proto == sel->proto || !sel->proto) && + (fl->oif == sel->ifindex || !sel->ifindex); +} + /* A struct encoding bundle of transformations to apply to some set of flow. * * dst->child points to the next element of bundle. @@ -276,6 +293,7 @@ struct xfrm_dst *next; struct dst_entry dst; struct rtable rt; + struct rt6_info rt6; } u; }; @@ -315,6 +333,18 @@ __xfrm_policy_check(sk, dir, skb); } +extern int __xfrm6_policy_check(struct sock *, int dir, struct sk_buff *skb); + +static inline int xfrm6_policy_check(struct sock *sk, int dir, struct sk_buff *skb) +{ + if (sk && sk->policy[XFRM_POLICY_IN]) + return __xfrm6_policy_check(sk, dir, skb); + + return !xfrm_policy_list[dir] || + (skb->dst->flags & DST_NOPOLICY) || + __xfrm6_policy_check(sk, dir, skb); +} + extern int __xfrm_route_forward(struct sk_buff *skb); static inline int xfrm_route_forward(struct sk_buff *skb) @@ -353,10 +383,14 @@ extern struct xfrm_state *xfrm_state_alloc(void); extern struct xfrm_state *xfrm_state_find(u32 daddr, u32 saddr, struct flowi *fl, struct xfrm_tmpl *tmpl, struct xfrm_policy *pol, int *err); +extern struct xfrm_state *xfrm6_state_find(struct in6_addr *daddr, struct in6_addr *saddr, + struct flowi *fl, struct xfrm_tmpl *tmpl, + struct xfrm_policy *pol, int *err); extern int xfrm_state_check_expire(struct xfrm_state *x); extern void xfrm_state_insert(struct xfrm_state *x); extern int xfrm_state_check_space(struct xfrm_state *x, struct sk_buff *skb); extern struct xfrm_state *xfrm_state_lookup(u32 daddr, u32 spi, u8 proto); +extern struct xfrm_state *xfrm6_state_lookup(struct in6_addr *daddr, u32 spi, u8 proto); extern struct xfrm_state *xfrm_find_acq_byseq(u32 seq); extern void xfrm_state_delete(struct xfrm_state *x); extern void xfrm_state_flush(u8 proto); @@ -374,7 +408,10 @@ struct xfrm_policy *xfrm_policy_byid(int dir, u32 id, int delete); void xfrm_policy_flush(void); void xfrm_alloc_spi(struct xfrm_state *x, u32 minspi, u32 maxspi); +void xfrm6_alloc_spi(struct xfrm_state *x, u32 minspi, u32 maxspi); struct xfrm_state * xfrm_find_acq(u8 mode, u16 reqid, u8 proto, u32 daddr, u32 saddr, int create); +struct xfrm_state * xfrm6_find_acq(u8 mode, u16 reqid, u8 proto, struct in6_addr *daddr, + struct in6_addr *saddr, int create); extern void xfrm_policy_flush(void); extern void xfrm_policy_kill(struct xfrm_policy *); extern int xfrm_sk_policy_insert(struct sock *sk, int dir, struct xfrm_policy *pol); Index: net/netsyms.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux25/net/netsyms.c,v retrieving revision 1.1.1.8 retrieving revision 1.1.1.8.2.2 diff -u -r1.1.1.8 -r1.1.1.8.2.2 --- net/netsyms.c 10 Dec 2002 07:09:33 -0000 1.1.1.8 +++ net/netsyms.c 7 Jan 2003 02:13:58 -0000 1.1.1.8.2.2 @@ -322,7 +322,10 @@ EXPORT_SYMBOL(xfrm_policy_flush); EXPORT_SYMBOL(xfrm_policy_byid); EXPORT_SYMBOL(xfrm_policy_list); - +EXPORT_SYMBOL(xfrm6_state_find); +EXPORT_SYMBOL(xfrm6_state_lookup); +EXPORT_SYMBOL(xfrm6_find_acq); +EXPORT_SYMBOL(xfrm6_alloc_spi); #if defined (CONFIG_IPV6_MODULE) || defined (CONFIG_IP_SCTP_MODULE) /* inet functions common to v4 and v6 */ Index: net/ipv4/xfrm_state.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux25/net/ipv4/xfrm_state.c,v retrieving revision 1.1.1.4 retrieving revision 1.1.1.4.2.1 diff -u -r1.1.1.4 -r1.1.1.4.2.1 --- net/ipv4/xfrm_state.c 23 Nov 2002 11:09:42 -0000 1.1.1.4 +++ net/ipv4/xfrm_state.c 6 Jan 2003 15:40:11 -0000 1.1.1.4.2.1 @@ -1,6 +1,15 @@ +/* + * + * Changes: + * + * MIYAZAWA Kazunori @USAGI : support IPv6 IPsec + * + */ + #include #include #include +#include /* Each xfrm_state may be linked to two tables: @@ -219,7 +228,8 @@ spin_lock_bh(&xfrm_state_lock); list_for_each_entry(x, xfrm_state_bydst+h, bydst) { - if (daddr == x->id.daddr.xfrm4_addr && + if (x->props.family == AF_INET && + daddr == x->id.daddr.xfrm4_addr && x->props.reqid == tmpl->reqid && (saddr == x->props.saddr.xfrm4_addr || !saddr || !x->props.saddr.xfrm4_addr) && tmpl->mode == x->props.mode && @@ -287,6 +297,7 @@ x->props.saddr.xfrm4_addr = saddr; x->props.mode = tmpl->mode; x->props.reqid = tmpl->reqid; + x->props.family = AF_INET; if (km_query(x, tmpl, pol) == 0) { x->km.state = XFRM_STATE_ACQ; @@ -315,9 +326,130 @@ return x; } +struct xfrm_state * +xfrm6_state_find(struct in6_addr *daddr, struct in6_addr *saddr, struct flowi *fl, struct xfrm_tmpl *tmpl, + struct xfrm_policy *pol, int *err) +{ + unsigned h = ntohl(daddr->s6_addr32[3]); + struct xfrm_state *x = NULL; + int acquire_in_progress = 0; + int error = 0; + struct xfrm_state *best = NULL; + + h = (h ^ (h>>16)) % XFRM_DST_HSIZE; + + spin_lock_bh(&xfrm_state_lock); + list_for_each_entry(x, xfrm_state_bydst+h, bydst) { + if (x->props.family == AF_INET6&& + !memcmp(daddr, &x->id.daddr, sizeof(*daddr)) && + x->props.reqid == tmpl->reqid && + (!memcmp(saddr, &x->props.saddr, sizeof(*saddr))|| ipv6_addr_any(saddr)) && + tmpl->mode == x->props.mode && + tmpl->id.proto == x->id.proto) { + /* Resolution logic: + 1. There is a valid state with matching selector. + Done. + 2. Valid state with inappropriate selector. Skip. + + Entering area of "sysdeps". + + 3. If state is not valid, selector is temporary, + it selects only session which triggered + previous resolution. Key manager will do + something to install a state with proper + selector. + */ + if (x->km.state == XFRM_STATE_VALID) { + if (!xfrm6_selector_match(&x->sel, fl)) + continue; + if (!best || + best->km.dying > x->km.dying || + (best->km.dying == x->km.dying && + best->curlft.add_time < x->curlft.add_time)) + best = x; + } else if (x->km.state == XFRM_STATE_ACQ) { + acquire_in_progress = 1; + } else if (x->km.state == XFRM_STATE_ERROR || + x->km.state == XFRM_STATE_EXPIRED) { + if (xfrm6_selector_match(&x->sel, fl)) + error = 1; + } + } + } + + if (best) { + atomic_inc(&best->refcnt); + spin_unlock_bh(&xfrm_state_lock); + return best; + } + x = NULL; + if (!error && !acquire_in_progress && + ((x = xfrm_state_alloc()) != NULL)) { + /* Initialize temporary selector matching only + * to current session. */ + memcpy(&x->sel.daddr, fl->fl6_dst, sizeof(struct in6_addr)); + memcpy(&x->sel.saddr, fl->fl6_src, sizeof(struct in6_addr)); + x->sel.dport = fl->uli_u.ports.dport; + x->sel.dport_mask = ~0; + x->sel.sport = fl->uli_u.ports.sport; + x->sel.sport_mask = ~0; + x->sel.prefixlen_d = 128; + x->sel.prefixlen_s = 128; + x->sel.proto = fl->proto; + x->sel.ifindex = fl->oif; + x->id = tmpl->id; + if (ipv6_addr_any((struct in6_addr*)&x->id.daddr)) + memcpy(&x->id.daddr, daddr, sizeof(x->sel.daddr)); + memcpy(&x->props.saddr, &tmpl->saddr, sizeof(x->props.saddr)); + if (ipv6_addr_any((struct in6_addr*)&x->props.saddr)) + memcpy(&x->props.saddr, &saddr, sizeof(x->sel.saddr)); + x->props.mode = tmpl->mode; + x->props.reqid = tmpl->reqid; + x->props.family = AF_INET6; + + if (km_query(x, tmpl, pol) == 0) { + x->km.state = XFRM_STATE_ACQ; + list_add_tail(&x->bydst, xfrm_state_bydst+h); + atomic_inc(&x->refcnt); + if (x->id.spi) { + struct in6_addr *addr = (struct in6_addr*)&x->id.daddr; + h = ntohl((addr->s6_addr32[3])^x->id.spi^x->id.proto); + h = (h ^ (h>>10) ^ (h>>20)) % XFRM_DST_HSIZE; + list_add(&x->byspi, xfrm_state_byspi+h); + atomic_inc(&x->refcnt); + } + x->lft.hard_add_expires_seconds = ACQ_EXPIRES; + atomic_inc(&x->refcnt); + mod_timer(&x->timer, ACQ_EXPIRES*HZ); + } else { + x->km.state = XFRM_STATE_DEAD; + xfrm_state_put(x); + x = NULL; + error = 1; + } + } + spin_unlock_bh(&xfrm_state_lock); + if (!x) + *err = acquire_in_progress ? -EAGAIN : + (error ? -ESRCH : -ENOMEM); + return x; +} + void xfrm_state_insert(struct xfrm_state *x) { - unsigned h = ntohl(x->id.daddr.xfrm4_addr); + unsigned h = 0; + switch(x->props.family) { + case AF_INET: + h = ntohl(x->id.daddr.xfrm4_addr); + break; + case AF_INET6: + { + struct in6_addr *addr = (struct in6_addr*)&x->id.daddr; + h = ntohl(addr->s6_addr32[3]); + break; + } + default: + } h = (h ^ (h>>16)) % XFRM_DST_HSIZE; @@ -325,7 +457,18 @@ list_add(&x->bydst, xfrm_state_bydst+h); atomic_inc(&x->refcnt); - h = ntohl(x->id.daddr.xfrm4_addr^x->id.spi^x->id.proto); + switch(x->props.family) { + case AF_INET: + h = ntohl(x->id.daddr.xfrm4_addr^x->id.spi^x->id.proto); + break; + case AF_INET6: + { + struct in6_addr *addr = (struct in6_addr*)&x->id.daddr; + h = ntohl((addr->s6_addr32[3])^x->id.spi^x->id.proto); + break; + } + default: + } h = (h ^ (h>>10) ^ (h>>20)) % XFRM_DST_HSIZE; list_add(&x->byspi, xfrm_state_byspi+h); atomic_inc(&x->refcnt); @@ -382,7 +525,8 @@ spin_lock_bh(&xfrm_state_lock); list_for_each_entry(x, xfrm_state_byspi+h, byspi) { - if (spi == x->id.spi && + if (x->props.family == AF_INET && + spi == x->id.spi && daddr == x->id.daddr.xfrm4_addr && proto == x->id.proto) { atomic_inc(&x->refcnt); @@ -395,6 +539,29 @@ } struct xfrm_state * +xfrm6_state_lookup(struct in6_addr *daddr, u32 spi, u8 proto) +{ + unsigned h = ntohl(daddr->s6_addr32[3]^spi^proto); + struct xfrm_state *x; + + h = (h ^ (h>>10) ^ (h>>20)) % XFRM_DST_HSIZE; + + spin_lock_bh(&xfrm_state_lock); + list_for_each_entry(x, xfrm_state_byspi+h, byspi) { + if (x->props.family == AF_INET6 && + spi == x->id.spi && + proto == x->id.proto && + !memcmp(daddr, &x->id.daddr, sizeof(*daddr))) { + atomic_inc(&x->refcnt); + spin_unlock_bh(&xfrm_state_lock); + return x; + } + } + spin_unlock_bh(&xfrm_state_lock); + return NULL; +} + +struct xfrm_state * xfrm_find_acq(u8 mode, u16 reqid, u8 proto, u32 daddr, u32 saddr, int create) { struct xfrm_state *x, *x0; @@ -405,7 +572,8 @@ spin_lock_bh(&xfrm_state_lock); list_for_each_entry(x, xfrm_state_bydst+h, bydst) { - if (daddr == x->id.daddr.xfrm4_addr && + if (x->props.family == AF_INET && + daddr == x->id.daddr.xfrm4_addr && mode == x->props.mode && proto == x->id.proto && saddr == x->props.saddr.xfrm4_addr && @@ -434,6 +602,58 @@ x0->id.proto = proto; x0->props.mode = mode; x0->props.reqid = reqid; + x0->props.family = AF_INET; + x0->lft.hard_add_expires_seconds = ACQ_EXPIRES; + atomic_inc(&x0->refcnt); + mod_timer(&x0->timer, jiffies + ACQ_EXPIRES*HZ); + atomic_inc(&x0->refcnt); + list_add_tail(&x0->bydst, xfrm_state_bydst+h); + wake_up(&km_waitq); + } + spin_unlock_bh(&xfrm_state_lock); + return x0; +} + +struct xfrm_state * +xfrm6_find_acq(u8 mode, u16 reqid, u8 proto, struct in6_addr *daddr, struct in6_addr *saddr, int create) +{ + struct xfrm_state *x, *x0; + unsigned h = ntohl(daddr->s6_addr32[3]); + + h = (h ^ (h>>16)) % XFRM_DST_HSIZE; + x0 = NULL; + + spin_lock_bh(&xfrm_state_lock); + list_for_each_entry(x, xfrm_state_bydst+h, bydst) { + if (x->props.family == AF_INET6 && + !memcmp(daddr, &x->id.daddr, sizeof(*daddr)) && + mode == x->props.mode && + proto == x->id.proto && + !memcmp(saddr, &x->props.saddr, sizeof(*saddr)) && + reqid == x->props.reqid && + x->km.state == XFRM_STATE_ACQ) { + if (!x0) + x0 = x; + if (x->id.spi) + continue; + x0 = x; + break; + } + } + if (x0) { + atomic_inc(&x0->refcnt); + } else if (create && (x0 = xfrm_state_alloc()) != NULL) { + memcpy(&x0->sel.daddr, daddr, sizeof(x0->sel.daddr)); + memcpy(&x0->sel.saddr, saddr, sizeof(x0->sel.saddr)); + x0->sel.prefixlen_d = 128; + x0->sel.prefixlen_s = 128; + memcpy(&x0->props.saddr, saddr, sizeof(x0->props.saddr)); + x0->km.state = XFRM_STATE_ACQ; + memcpy(&x0->id.daddr, daddr, sizeof(x0->id.daddr)); + x0->id.proto = proto; + x0->props.mode = mode; + x0->props.reqid = reqid; + x0->props.family = AF_INET6; x0->lft.hard_add_expires_seconds = ACQ_EXPIRES; atomic_inc(&x0->refcnt); mod_timer(&x0->timer, jiffies + ACQ_EXPIRES*HZ); @@ -507,6 +727,47 @@ } } +void +xfrm6_alloc_spi(struct xfrm_state *x, u32 minspi, u32 maxspi) +{ + u32 h; + struct xfrm_state *x0; + + if (x->id.spi) + return; + + if (minspi == maxspi) { + x0 = xfrm6_state_lookup((struct in6_addr*)&x->id.daddr, minspi, x->id.proto); + if (x0) { + xfrm_state_put(x0); + return; + } + x->id.spi = minspi; + } else { + u32 spi = 0; + minspi = ntohl(minspi); + maxspi = ntohl(maxspi); + for (h=0; hid.daddr, htonl(spi), x->id.proto); + if (x0 == NULL) + break; + xfrm_state_put(x0); + } + x->id.spi = htonl(spi); + } + if (x->id.spi) { + struct in6_addr *addr = (struct in6_addr*)&x->id.daddr; + spin_lock_bh(&xfrm_state_lock); + h = ntohl((addr->s6_addr32[3])^x->id.spi^x->id.proto); + h = (h ^ (h>>10) ^ (h>>20)) % XFRM_DST_HSIZE; + list_add(&x->byspi, xfrm_state_byspi+h); + atomic_inc(&x->refcnt); + spin_unlock_bh(&xfrm_state_lock); + wake_up(&km_waitq); + } +} + int xfrm_state_walk(u8 proto, int (*func)(struct xfrm_state *, int, void*), void *data) { @@ -591,7 +852,9 @@ int i; for (i=0; isel, fl)) + if (x[i]->props.family == AF_INET && !xfrm4_selector_match(&x[i]->sel, fl)) + return -EINVAL; + if (x[i]->props.family == AF_INET6 && !xfrm6_selector_match(&x[i]->sel, fl)) return -EINVAL; } return 0; Index: net/key/af_key.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux25/net/key/Attic/af_key.c,v retrieving revision 1.1.1.4 retrieving revision 1.1.1.4.2.5 diff -u -r1.1.1.4 -r1.1.1.4.2.5 --- net/key/af_key.c 24 Dec 2002 05:57:49 -0000 1.1.1.4 +++ net/key/af_key.c 6 Jan 2003 16:32:18 -0000 1.1.1.4.2.5 @@ -9,6 +9,11 @@ * Authors: Maxim Giryaev * David S. Miller * Alexey Kuznetsov + * + * Changes: + * MIYAZAWA Kazunori @USAGI, + * YOSHIFUJI Hideaki @USAGI: + * IPv6 Support */ #include @@ -400,7 +405,7 @@ d_addr = (struct sockaddr *)(dst + 1); if (s_addr->sa_family != d_addr->sa_family) return 0; - if (s_addr->sa_family != AF_INET) + if (s_addr->sa_family != AF_INET && s_addr->sa_family != AF_INET6) return 0; return 1; @@ -497,8 +502,8 @@ return (proto ? proto : IPSEC_PROTO_ANY); } -static xfrm_address_t *pfkey_sadb_addr2xfrm_addr(struct sadb_address *addr, - xfrm_address_t *xaddr) +static int pfkey_sadb_addr2xfrm_addr(struct sadb_address *addr, + xfrm_address_t *xaddr) { switch (((struct sockaddr*)(addr + 1))->sa_family) { case AF_INET: @@ -506,16 +511,18 @@ ((struct sockaddr_in*)(addr + 1))->sin_addr.s_addr; if (addr->sadb_address_prefixlen) xaddr->xfrm4_mask = htonl(~0 << (32 - addr->sadb_address_prefixlen)); + return AF_INET; break; case AF_INET6: memcpy(xaddr->a6, &((struct sockaddr_in6*)(addr + 1))->sin6_addr, sizeof(xaddr->a6)); + return AF_INET6; + break; default: - return NULL; } - return xaddr; + return 0; } static struct xfrm_state *pfkey_xfrm_state_lookup(struct sadb_msg *hdr, void **ext_hdrs) @@ -544,7 +551,9 @@ sa->sadb_sa_spi, proto); break; case AF_INET6: - /* XXX handle IPv6 */ + x = xfrm6_state_lookup(&((struct sockaddr_in6*)(addr + 1))->sin6_addr, + sa->sadb_sa_spi, proto); + break; default: x = NULL; break; @@ -672,7 +681,7 @@ struct sadb_msg *hdr; struct sadb_sa *sa; struct sadb_lifetime *lifetime; - struct sadb_address *addr; + struct sadb_address *addr = NULL; struct sadb_key *key; struct sadb_x_sa2 *sa2; int size; @@ -685,14 +694,20 @@ sizeof(struct sadb_lifetime) + ((hsc & 1) ? sizeof(struct sadb_lifetime) : 0) + ((hsc & 2) ? sizeof(struct sadb_lifetime) : 0) + - sizeof(struct sadb_address)*2 + - sizeof(struct sockaddr_in)*2 + /* XXX */ sizeof(struct sadb_x_sa2); - /* XXX identity & sensitivity */ - if (x->sel.saddr.xfrm4_addr != x->props.saddr.xfrm4_addr) - size += sizeof(struct sadb_address) + - sizeof(struct sockaddr_in); /* XXX */ + /* XXX identity & sensitivity */ + if (x->props.family == AF_INET) { + size += (sizeof(struct sadb_address) + sizeof(struct sockaddr_in)) *2; + if (x->sel.saddr.xfrm4_addr != x->props.saddr.xfrm4_addr) + size += sizeof(struct sadb_address) + + sizeof(struct sockaddr_in); + } else if (x->props.family == AF_INET6) { + size += (sizeof(struct sadb_address) + ((sizeof(struct sockaddr_in6) + 7) & ~7)) *2; + if (memcmp(&x->sel.saddr, &x->props.saddr, sizeof(x->sel.saddr))) + size += sizeof(struct sadb_address) + + ((sizeof(struct sockaddr_in6) + 7) & ~7); + } if (add_keys) { if (x->aalg && x->aalg->alg_key_len) { @@ -774,51 +789,98 @@ lifetime->sadb_lifetime_bytes = x->curlft.bytes; lifetime->sadb_lifetime_addtime = x->curlft.add_time; lifetime->sadb_lifetime_usetime = x->curlft.use_time; - /* src address */ - addr = (struct sadb_address*) skb_put(skb, - sizeof(struct sadb_address)+sizeof(struct sockaddr_in)); - addr->sadb_address_len = - (sizeof(struct sadb_address)+sizeof(struct sockaddr_in))/ - sizeof(uint64_t); - addr->sadb_address_exttype = SADB_EXT_ADDRESS_SRC; - /* "if the ports are non-zero, then the sadb_address_proto field, - normally zero, MUST be filled in with the transport - protocol's number." - RFC2367 */ - addr->sadb_address_proto = 0; - addr->sadb_address_prefixlen = 32; /* XXX */ - addr->sadb_address_reserved = 0; - ((struct sockaddr_in*)(addr + 1))->sin_family = AF_INET; - ((struct sockaddr_in*)(addr + 1))->sin_addr.s_addr = - x->props.saddr.xfrm4_addr; - /* dst address */ - addr = (struct sadb_address*) skb_put(skb, - sizeof(struct sadb_address)+sizeof(struct sockaddr_in)); - addr->sadb_address_len = - (sizeof(struct sadb_address)+sizeof(struct sockaddr_in))/ - sizeof(uint64_t); - addr->sadb_address_exttype = SADB_EXT_ADDRESS_DST; - addr->sadb_address_proto = 0; - addr->sadb_address_prefixlen = 32; /* XXX */ - addr->sadb_address_reserved = 0; - ((struct sockaddr_in*)(addr + 1))->sin_family = AF_INET; - ((struct sockaddr_in*)(addr + 1))->sin_addr.s_addr = - x->id.daddr.xfrm4_addr; - if (x->sel.saddr.xfrm4_addr != x->props.saddr.xfrm4_addr) { + if (x->props.family == AF_INET) { + /* src address */ addr = (struct sadb_address*) skb_put(skb, sizeof(struct sadb_address)+sizeof(struct sockaddr_in)); addr->sadb_address_len = (sizeof(struct sadb_address)+sizeof(struct sockaddr_in))/ sizeof(uint64_t); - addr->sadb_address_exttype = SADB_EXT_ADDRESS_PROXY; - addr->sadb_address_proto = pfkey_proto_from_xfrm(x->sel.proto); - addr->sadb_address_prefixlen = x->sel.prefixlen_s; + addr->sadb_address_exttype = SADB_EXT_ADDRESS_SRC; + /* "if the ports are non-zero, then the sadb_address_proto field, + normally zero, MUST be filled in with the transport + protocol's number." - RFC2367 */ + addr->sadb_address_proto = 0; + addr->sadb_address_prefixlen = 32; /* XXX */ addr->sadb_address_reserved = 0; ((struct sockaddr_in*)(addr + 1))->sin_family = AF_INET; ((struct sockaddr_in*)(addr + 1))->sin_addr.s_addr = - x->sel.saddr.xfrm4_addr; - ((struct sockaddr_in*)(addr + 1))->sin_port = - x->sel.sport; + x->props.saddr.xfrm4_addr; + /* dst address */ + addr = (struct sadb_address*) skb_put(skb, + sizeof(struct sadb_address)+sizeof(struct sockaddr_in)); + addr->sadb_address_len = + (sizeof(struct sadb_address)+sizeof(struct sockaddr_in))/ + sizeof(uint64_t); + addr->sadb_address_exttype = SADB_EXT_ADDRESS_DST; + addr->sadb_address_proto = 0; + addr->sadb_address_prefixlen = 32; /* XXX */ + addr->sadb_address_reserved = 0; + ((struct sockaddr_in*)(addr + 1))->sin_family = AF_INET; + ((struct sockaddr_in*)(addr + 1))->sin_addr.s_addr = + x->id.daddr.xfrm4_addr; + + if (x->sel.saddr.xfrm4_addr != x->props.saddr.xfrm4_addr) { + addr = (struct sadb_address*) skb_put(skb, + sizeof(struct sadb_address)+sizeof(struct sockaddr_in)); + addr->sadb_address_len = + (sizeof(struct sadb_address)+sizeof(struct sockaddr_in))/ + sizeof(uint64_t); + addr->sadb_address_exttype = SADB_EXT_ADDRESS_PROXY; + addr->sadb_address_proto = pfkey_proto_from_xfrm(x->sel.proto); + addr->sadb_address_prefixlen = x->sel.prefixlen_s; + addr->sadb_address_reserved = 0; + ((struct sockaddr_in*)(addr + 1))->sin_family = AF_INET; + ((struct sockaddr_in*)(addr + 1))->sin_addr.s_addr = + x->sel.saddr.xfrm4_addr; + ((struct sockaddr_in*)(addr + 1))->sin_port = + x->sel.sport; + } + } else if (x->props.family == AF_INET6) { + /* src address */ + addr = (struct sadb_address*) skb_put(skb, + sizeof(struct sadb_address)+ + ((sizeof(struct sockaddr_in6) + 7) & ~7)); + addr->sadb_address_len = + (sizeof(struct sadb_address)+((sizeof(struct sockaddr_in6) + 7) & ~7))/ + sizeof(uint64_t); + addr->sadb_address_exttype = SADB_EXT_ADDRESS_SRC; + addr->sadb_address_proto = 0; + addr->sadb_address_prefixlen = 128; /* XXX */ + addr->sadb_address_reserved = 0; + ((struct sockaddr_in6*)(addr + 1))->sin6_family = AF_INET6; + memcpy(&((struct sockaddr_in6*)(addr + 1))->sin6_addr, &x->props.saddr, sizeof(struct in6_addr)); + /* dst address */ + addr = (struct sadb_address*) skb_put(skb, + sizeof(struct sadb_address)+ + ((sizeof(struct sockaddr_in6) + 7) & ~7)); + addr->sadb_address_len = + (sizeof(struct sadb_address)+((sizeof(struct sockaddr_in6) + 7) & ~7))/ + sizeof(uint64_t); + addr->sadb_address_exttype = SADB_EXT_ADDRESS_DST; + addr->sadb_address_proto = 0; + addr->sadb_address_prefixlen = 128; /* XXX */ + addr->sadb_address_reserved = 0; + ((struct sockaddr_in6*)(addr + 1))->sin6_family = AF_INET6; + memcpy(&((struct sockaddr_in6*)(addr + 1))->sin6_addr, &x->id.daddr, sizeof(struct in6_addr)); + + if (memcmp(&x->sel.saddr, &x->props.saddr, sizeof(x->sel.saddr))) { + addr = (struct sadb_address*) skb_put(skb, + sizeof(struct sadb_address)+ + ((sizeof(struct sockaddr_in6) + 7) & ~7)); + addr->sadb_address_len = + (sizeof(struct sadb_address)+((sizeof(struct sockaddr_in6) + 7) & ~7))/ + sizeof(uint64_t); + addr->sadb_address_exttype = SADB_EXT_ADDRESS_PROXY; + addr->sadb_address_proto = pfkey_proto_from_xfrm(x->sel.proto); + addr->sadb_address_prefixlen = x->sel.prefixlen_s; + addr->sadb_address_reserved = 0; + ((struct sockaddr_in6*)(addr + 1))->sin6_family = AF_INET6; + ((struct sockaddr_in6*)(addr + 1))->sin6_port = + x->sel.sport; + memcpy(&((struct sockaddr_in6*)(addr + 1))->sin6_addr, &x->sel.saddr, sizeof(struct in6_addr)); + } } /* auth key */ @@ -976,7 +1038,7 @@ } /* x->algo.flags = sa->sadb_sa_flags; */ - pfkey_sadb_addr2xfrm_addr((struct sadb_address *) ext_hdrs[SADB_EXT_ADDRESS_SRC-1], + x->props.family = pfkey_sadb_addr2xfrm_addr((struct sadb_address *) ext_hdrs[SADB_EXT_ADDRESS_SRC-1], &x->props.saddr); pfkey_sadb_addr2xfrm_addr((struct sadb_address *) ext_hdrs[SADB_EXT_ADDRESS_DST-1], &x->id.daddr); @@ -1138,12 +1200,24 @@ /* XXX there is race condition */ x1 = pfkey_xfrm_state_lookup(hdr, ext_hdrs); if (!x1) { - x1 = xfrm_find_acq(x->props.mode, x->props.reqid, x->id.proto, - x->id.daddr.xfrm4_addr, - x->props.saddr.xfrm4_addr, 0); - if (x1 && x1->id.spi != x->id.spi && x1->id.spi) { - xfrm_state_put(x1); - x1 = NULL; + struct sadb_address *addr + = (struct sadb_address *) ext_hdrs[SADB_EXT_ADDRESS_DST-1]; + switch (((struct sockaddr*)(addr + 1))->sa_family) { + case AF_INET: + x1 = xfrm_find_acq(x->props.mode, x->props.reqid, x->id.proto, + x->id.daddr.xfrm4_addr, + x->props.saddr.xfrm4_addr, 0); + if (x1 && x1->id.spi != x->id.spi && x1->id.spi) { + xfrm_state_put(x1); + x1 = NULL; + } + break; + case AF_INET6: + x1 = xfrm6_find_acq(x->props.mode, x->props.reqid, x->id.proto, + (struct in6_addr*)&x->id.daddr, + (struct in6_addr*)&x->props.saddr, 0); + break; + default: } } @@ -1490,16 +1564,23 @@ struct sadb_lifetime *lifetime; struct sadb_x_policy *pol; struct sockaddr_in *sin; + struct sockaddr_in6 *sin6; int i; int size; - size = sizeof(struct sadb_msg) + - sizeof(struct sadb_lifetime) * 3 + - sizeof(struct sadb_address)*2 + - sizeof(struct sockaddr_in)*2 + /* XXX */ - sizeof(struct sadb_x_policy) + - xp->xfrm_nr*(sizeof(struct sadb_x_ipsecrequest) + - sizeof(struct sockaddr_in)*2); + size = sizeof(struct sadb_msg) + sizeof(struct sadb_lifetime) * 3; + + if (xp->family == AF_INET) { + size += (sizeof(struct sadb_address) + sizeof(struct sockaddr_in))*2+ + sizeof(struct sadb_x_policy) + + xp->xfrm_nr*(sizeof(struct sadb_x_ipsecrequest) + + sizeof(struct sockaddr_in)*2); + } else if (xp->family == AF_INET6) { + size += (sizeof(struct sadb_address) + ((sizeof(struct sockaddr_in6)+7)&~7))*2+ + sizeof(struct sadb_x_policy) + + xp->xfrm_nr*(sizeof(struct sadb_x_ipsecrequest) + + ((sizeof(struct sockaddr_in6)+7)&~7)*2); + } skb = alloc_skb(size + 16, GFP_ATOMIC); if (skb == NULL) @@ -1509,37 +1590,70 @@ hdr = (struct sadb_msg *) skb_put(skb, sizeof(struct sadb_msg)); memset(hdr, 0, size); /* XXX do we need this ? */ - /* src address */ - addr = (struct sadb_address*) skb_put(skb, - sizeof(struct sadb_address)+sizeof(struct sockaddr_in)); - addr->sadb_address_len = - (sizeof(struct sadb_address)+sizeof(struct sockaddr_in))/ - sizeof(uint64_t); - addr->sadb_address_exttype = SADB_EXT_ADDRESS_SRC; - addr->sadb_address_proto = pfkey_proto_from_xfrm(xp->selector.proto); - addr->sadb_address_prefixlen = xp->selector.prefixlen_s; - addr->sadb_address_reserved = 0; - /* src address */ - sin = (struct sockaddr_in*)(addr + 1); - sin->sin_family = AF_INET; - sin->sin_addr.s_addr = xp->selector.saddr.xfrm4_addr; - sin->sin_port = xp->selector.sport; - memset(sin->sin_zero, 0, sizeof(sin->sin_zero)); - /* dst address */ - addr = (struct sadb_address*) skb_put(skb, - sizeof(struct sadb_address)+sizeof(struct sockaddr_in)); - addr->sadb_address_len = - (sizeof(struct sadb_address)+sizeof(struct sockaddr_in))/ - sizeof(uint64_t); - addr->sadb_address_exttype = SADB_EXT_ADDRESS_DST; - addr->sadb_address_proto = pfkey_proto_from_xfrm(xp->selector.proto); - addr->sadb_address_prefixlen = xp->selector.prefixlen_d; - addr->sadb_address_reserved = 0; - sin = (struct sockaddr_in*)(addr + 1); - sin->sin_family = AF_INET; - sin->sin_addr.s_addr = xp->selector.daddr.xfrm4_addr; - sin->sin_port = xp->selector.dport; - memset(sin->sin_zero, 0, sizeof(sin->sin_zero)); + if (xp->family == AF_INET) { + /* src address */ + addr = (struct sadb_address*) skb_put(skb, + sizeof(struct sadb_address)+sizeof(struct sockaddr_in)); + addr->sadb_address_len = + (sizeof(struct sadb_address)+sizeof(struct sockaddr_in))/ + sizeof(uint64_t); + /* src address */ + sin = (struct sockaddr_in*)(addr + 1); + sin->sin_family = AF_INET; + sin->sin_addr.s_addr = xp->selector.saddr.xfrm4_addr; + sin->sin_port = xp->selector.sport; + memset(sin->sin_zero, 0, sizeof(sin->sin_zero)); + addr->sadb_address_exttype = SADB_EXT_ADDRESS_SRC; + addr->sadb_address_proto = pfkey_proto_from_xfrm(xp->selector.proto); + addr->sadb_address_prefixlen = xp->selector.prefixlen_s; + addr->sadb_address_reserved = 0; + /* dst address */ + addr = (struct sadb_address*) skb_put(skb, + sizeof(struct sadb_address)+sizeof(struct sockaddr_in)); + addr->sadb_address_len = + (sizeof(struct sadb_address)+sizeof(struct sockaddr_in))/ + sizeof(uint64_t); + addr->sadb_address_exttype = SADB_EXT_ADDRESS_DST; + addr->sadb_address_proto = pfkey_proto_from_xfrm(xp->selector.proto); + addr->sadb_address_prefixlen = xp->selector.prefixlen_d; + addr->sadb_address_reserved = 0; + sin = (struct sockaddr_in*)(addr + 1); + sin->sin_family = AF_INET; + sin->sin_addr.s_addr = xp->selector.daddr.xfrm4_addr; + sin->sin_port = xp->selector.dport; + memset(sin->sin_zero, 0, sizeof(sin->sin_zero)); + } else if (xp->family == AF_INET6) { + /* src address */ + addr = (struct sadb_address*) skb_put(skb, + sizeof(struct sadb_address) + +((sizeof(struct sockaddr_in6) +7) & ~7)); + addr->sadb_address_len = + (sizeof(struct sadb_address)+((sizeof(struct sockaddr_in6) + 7) & ~7))/ + sizeof(uint64_t); + sin6 = (struct sockaddr_in6*)(addr + 1); + sin6->sin6_family = AF_INET6; + sin6->sin6_port = xp->selector.sport; + memcpy(&sin6->sin6_addr, &xp->selector.saddr, sizeof(sin6->sin6_addr)); + addr->sadb_address_exttype = SADB_EXT_ADDRESS_SRC; + addr->sadb_address_proto = pfkey_proto_from_xfrm(xp->selector.proto); + addr->sadb_address_prefixlen = xp->selector.prefixlen_s; + addr->sadb_address_reserved = 0; + /* dst address */ + addr = (struct sadb_address*) skb_put(skb, + sizeof(struct sadb_address) + +((sizeof(struct sockaddr_in6) +7) & ~7)); + addr->sadb_address_len = + (sizeof(struct sadb_address)+((sizeof(struct sockaddr_in6) + 7) & ~7))/ + sizeof(uint64_t); + sin6 = (struct sockaddr_in6*)(addr + 1); + sin6->sin6_family = AF_INET6; + sin6->sin6_port = xp->selector.dport; + memcpy(&sin6->sin6_addr, &xp->selector.daddr, sizeof(sin6->sin6_addr)); + addr->sadb_address_exttype = SADB_EXT_ADDRESS_DST; + addr->sadb_address_proto = pfkey_proto_from_xfrm(xp->selector.proto); + addr->sadb_address_prefixlen = xp->selector.prefixlen_d; + addr->sadb_address_reserved = 0; + } /* hard time */ lifetime = (struct sadb_lifetime *) skb_put(skb, @@ -1591,10 +1705,17 @@ int req_size; req_size = sizeof(struct sadb_x_ipsecrequest); - if (t->mode) - req_size += 2*sizeof(struct sockaddr_in); - else - size -= 2*sizeof(struct sockaddr_in); + if (t->mode) { + if (xp->family == AF_INET) + req_size += 2*sizeof(struct sockaddr_in); + else if (xp->family == AF_INET6) + req_size += 2*((sizeof(struct sockaddr_in6) + 7) & ~7); + } else { + if (xp->family == AF_INET) + size -= 2*sizeof(struct sockaddr_in); + else if (xp->family == AF_INET6) + size -= 2*((sizeof(struct sockaddr_in6) + 7) & ~7); + } rq = (void*)skb_put(skb, req_size); pol->sadb_x_policy_len += req_size/8; rq->sadb_x_ipsecrequest_len = req_size; @@ -1607,16 +1728,27 @@ rq->sadb_x_ipsecrequest_level = IPSEC_LEVEL_USE; rq->sadb_x_ipsecrequest_reqid = t->reqid; if (t->mode) { - sin = (void*)(rq+1); - sin->sin_family = AF_INET; - sin->sin_addr.s_addr = t->saddr.xfrm4_addr; - sin->sin_port = 0; - memset(sin->sin_zero, 0, sizeof(sin->sin_zero)); - sin++; - sin->sin_family = AF_INET; - sin->sin_addr.s_addr = t->id.daddr.xfrm4_addr; - sin->sin_port = 0; - memset(sin->sin_zero, 0, sizeof(sin->sin_zero)); + if (xp->family == AF_INET) { + sin = (void*)(rq+1); + sin->sin_family = AF_INET; + sin->sin_addr.s_addr = t->saddr.xfrm4_addr; + sin->sin_port = 0; + memset(sin->sin_zero, 0, sizeof(sin->sin_zero)); + sin++; + sin->sin_family = AF_INET; + sin->sin_addr.s_addr = t->id.daddr.xfrm4_addr; + sin->sin_port = 0; + memset(sin->sin_zero, 0, sizeof(sin->sin_zero)); + } else if (xp->family == AF_INET6) { + sin6 = (void*)(rq+1); + sin6->sin6_family = AF_INET; + sin6->sin6_port = 0; + memcpy(&sin6->sin6_addr, &t->saddr, sizeof(sin6->sin6_addr)); + sin6++; + sin6->sin6_family = AF_INET6; + sin6->sin6_port = 0; + memcpy(&sin6->sin6_addr, &t->id.daddr, sizeof(sin6->sin6_addr)); + } } } hdr->sadb_msg_len = size / sizeof(uint64_t); @@ -1661,7 +1793,9 @@ xp->selector.sport_mask = ~0; sa = ext_hdrs[SADB_EXT_ADDRESS_DST-1], - pfkey_sadb_addr2xfrm_addr(sa, &xp->selector.daddr); + xp->family = pfkey_sadb_addr2xfrm_addr(sa, &xp->selector.daddr); + if (xp->family != AF_INET && xp->family != AF_INET6) + return -EINVAL; xp->selector.prefixlen_d = sa->sadb_address_prefixlen; /* Amusing, we set this twice. KAME apps appear to set same value @@ -2086,10 +2220,20 @@ struct sadb_address *addr; struct sadb_x_policy *pol; int size; - + int salen, plen; + + if (x->props.family == AF_INET) { + salen = sizeof(struct sockaddr_in); + plen = 32; + } else if (x->props.family == AF_INET6) { + salen = (sizeof(struct sockaddr_in6) + 7) & ~7; + plen = 128; + } else + return -EINVAL; + size = sizeof(struct sadb_msg) + sizeof(struct sadb_address)*2 + - sizeof(struct sockaddr_in)*2 + /* XXX */ + salen*2 + sizeof(struct sadb_x_policy); if (x->id.proto == IPPROTO_AH) @@ -2113,33 +2257,47 @@ /* src address */ addr = (struct sadb_address*) skb_put(skb, - sizeof(struct sadb_address)+sizeof(struct sockaddr_in)); + sizeof(struct sadb_address)+salen); addr->sadb_address_len = - (sizeof(struct sadb_address)+sizeof(struct sockaddr_in))/ + (sizeof(struct sadb_address)+salen)/ sizeof(uint64_t); addr->sadb_address_exttype = SADB_EXT_ADDRESS_SRC; addr->sadb_address_proto = 0; - addr->sadb_address_prefixlen = 32; + addr->sadb_address_prefixlen = plen; addr->sadb_address_reserved = 0; - ((struct sockaddr_in*)(addr + 1))->sin_family = AF_INET; - ((struct sockaddr_in*)(addr + 1))->sin_addr.s_addr = - x->props.saddr.xfrm4_addr; - ((struct sockaddr_in*)(addr + 1))->sin_port = 0; + if (x->props.family == AF_INET) { + ((struct sockaddr_in*)(addr + 1))->sin_family = AF_INET; + ((struct sockaddr_in*)(addr + 1))->sin_addr.s_addr = + x->props.saddr.xfrm4_addr; + ((struct sockaddr_in*)(addr + 1))->sin_port = 0; + } else { + ((struct sockaddr_in6*)(addr + 1))->sin6_family = AF_INET6; + memcpy(&((struct sockaddr_in6*)(addr + 1))->sin6_addr, + x->props.saddr.a6, sizeof(x->props.saddr.a6)); + ((struct sockaddr_in6*)(addr + 1))->sin6_port = 0; + } /* dst address */ addr = (struct sadb_address*) skb_put(skb, - sizeof(struct sadb_address)+sizeof(struct sockaddr_in)); + sizeof(struct sadb_address)+salen); addr->sadb_address_len = - (sizeof(struct sadb_address)+sizeof(struct sockaddr_in))/ + (sizeof(struct sadb_address)+salen)/ sizeof(uint64_t); addr->sadb_address_exttype = SADB_EXT_ADDRESS_DST; addr->sadb_address_proto = 0; - addr->sadb_address_prefixlen = 32; + addr->sadb_address_prefixlen = plen; addr->sadb_address_reserved = 0; - ((struct sockaddr_in*)(addr + 1))->sin_family = AF_INET; - ((struct sockaddr_in*)(addr + 1))->sin_addr.s_addr = - x->id.daddr.xfrm4_addr; - ((struct sockaddr_in*)(addr + 1))->sin_port = 0; + if (x->props.family == AF_INET) { + ((struct sockaddr_in*)(addr + 1))->sin_family = AF_INET; + ((struct sockaddr_in*)(addr + 1))->sin_addr.s_addr = + x->id.daddr.xfrm4_addr; + ((struct sockaddr_in*)(addr + 1))->sin_port = 0; + } else { + ((struct sockaddr_in6*)(addr + 1))->sin6_family = AF_INET6; + memcpy(&((struct sockaddr_in6*)(addr + 1))->sin6_addr, + x->id.daddr.a6, sizeof(x->id.daddr.a6)); + ((struct sockaddr_in6*)(addr + 1))->sin6_port = 0; + } pol = (struct sadb_x_policy *) skb_put(skb, sizeof(struct sadb_x_policy)); pol->sadb_x_policy_len = sizeof(struct sadb_x_policy)/sizeof(uint64_t); --Kazunori Miyazawa (Yokogawa Electric Corporation) From davem@redhat.com Tue Jan 7 01:20:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Jan 2003 01:21:28 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h079Ix3v023996 for ; Tue, 7 Jan 2003 01:20:52 -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 BAA23325; Tue, 7 Jan 2003 01:16:13 -0800 Date: Tue, 07 Jan 2003 01:16:13 -0800 (PST) Message-Id: <20030107.011613.15476380.davem@redhat.com> To: kiran@in.ibm.com Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [patch] Convert sockets_in_use to use per_cpu areas From: "David S. Miller" In-Reply-To: <20021224121852.H23413@in.ibm.com> References: <20021223190847.G23413@in.ibm.com> <20021223.121632.105420794.davem@redhat.com> <20021224121852.H23413@in.ibm.com> X-FalunGong: Information control. 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 X-archive-position: 1474 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Patch applied, thanks. From wichert@wiggy.net Wed Jan 8 05:05:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 05:05:42 -0800 (PST) Received: from mx1.wiggy.net (IDENT:k+6J9cjxCW4CtEemW2e3nIQPeHmWh76A@home.wiggy.net [213.84.101.140]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08D3A3v024605 for ; Wed, 8 Jan 2003 05:05:04 -0800 Received: from wichert by mx1.wiggy.net with local (Exim 3.35 #1 (Debian)) id 18WFww-00071j-00; Wed, 08 Jan 2003 14:08:50 +0100 Date: Wed, 8 Jan 2003 14:08:50 +0100 From: Wichert Akkerman To: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: ipv6 stack seems to forget to send ACKs Message-ID: <20030108130850.GQ22951@wiggy.net> Mail-Followup-To: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 1475 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wichert@wiggy.net Precedence: bulk X-list: netdev Recently a few friends setup an ipv6 icecast server to play with ipv6 and encourage people to use ipv6 more. When using linux this does not work perfectly though: after a certain period (usually a bit over 10 minutes) of listening to the stream traffic suddenly stops and one has to reconnect. A tcpdump of the traffic seems to indicate that the linux client suddenly stops sending ACKs and as a result the server stops sending us data: 13:57:39.812123 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9352713 win 32616 13:57:39.823581 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9352713:9353921(1208) ack 1 win 5712 [class 0x2] 13:57:39.823636 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9353921 win 32616 13:57:39.835144 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9353921:9355129(1208) ack 1 win 5712 [class 0x2] 13:57:39.835197 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9355129 win 32616 13:57:39.844277 2001:968:1::2.8000 > tornado.wiggy.net.33035: P 9355129:9355601(472) ack 1 win 5712 [class 0x2] 13:57:39.844326 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9355601 win 32616 13:57:40.221776 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9355601:9356809(1208) ack 1 win 5712 [class 0x2] 13:57:40.221846 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9356809 win 32616 13:57:40.233558 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9356809:9358017(1208) ack 1 win 5712 [class 0x2] 13:57:40.233613 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9358017 win 32616 13:57:40.245110 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9358017:9359225(1208) ack 1 win 5712 [class 0x2] 13:57:40.245160 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9359225 win 32616 13:57:40.282351 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 13:57:40.284307 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9360433:9360653(220) ack 1 win 5712 13:57:40.297307 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9360653:9361861(1208) ack 1 win 5712 13:57:40.297376 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9359225 win 32616 13:57:40.308222 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9362081:9363289(1208) ack 1 win 5712 [class 0x2] 13:57:40.308271 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9359225 win 32616 13:57:40.310424 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9361861:9362081(220) ack 1 win 5712 13:57:40.310471 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9359225 win 32616 13:57:40.325396 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9363289:9363509(220) ack 1 win 5712 [class 0x2] 13:57:40.325447 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9359225 win 32616 13:57:40.568652 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 13:57:41.121608 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 13:57:42.242095 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 13:57:44.481379 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 13:57:48.963035 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 13:57:53.955118 fe80::250:4ff:fe0b:dd79 > tornado.wiggy.net: icmp6: neighbor sol: who has tornado.wiggy.net 13:57:53.955183 tornado.wiggy.net > fe80::250:4ff:fe0b:dd79: icmp6: neighbor adv: tgt is tornado.wiggy.net 13:57:57.921294 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 13:58:15.841902 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 13:58:28.296672 tornado.wiggy.net.33035 > 2001:968:1::2.8000: F 1:1(0) ack 9359225 win 32616 13:58:28.323604 2001:968:1::2.8000 > tornado.wiggy.net.33035: . ack 2 win 5712 tornado.wiggy.net is my client running Linux 2.4.19 (unpatched, UP machine), and 2001:968:1::2 is the icecast server running Linux 2.4.20-rc2-ac3 (SMP). If you want to test the stream yourself, please stream from http://ipv6.lkml.org:8000/difm . Wichert. -- Wichert Akkerman http://www.wiggy.net/ A random hacker From solt@dns.toxicfilms.tv Wed Jan 8 05:22:51 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 05:23:24 -0800 (PST) Received: from dns.toxicfilms.tv (dns.toxicfilms.tv [150.254.37.24]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08DKr3v025147 for ; Wed, 8 Jan 2003 05:22:49 -0800 Received: by dns.toxicfilms.tv (Postfix, from userid 1000) id E9B278DE4C; Wed, 8 Jan 2003 14:26:27 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by dns.toxicfilms.tv (Postfix) with ESMTP id 73C4B2372B; Wed, 8 Jan 2003 14:26:27 +0100 (CET) Date: Wed, 8 Jan 2003 14:26:27 +0100 (CET) From: Maciej Soltysiak To: Wichert Akkerman Cc: netdev@oss.sgi.com, Subject: Re: ipv6 stack seems to forget to send ACKs In-Reply-To: <20030108130850.GQ22951@wiggy.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1476 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: solt@dns.toxicfilms.tv Precedence: bulk X-list: netdev > tornado.wiggy.net is my client running Linux 2.4.19 (unpatched, UP machine), > and 2001:968:1::2 is the icecast server running Linux 2.4.20-rc2-ac3 (SMP). > If you want to test the stream yourself, please stream from > http://ipv6.lkml.org:8000/difm . Which ipv6 client should i be using ? Regards, Maciej From wichert@wiggy.net Wed Jan 8 05:26:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 05:27:25 -0800 (PST) Received: from mx1.wiggy.net (IDENT:dldUMd2iYMbGEafNXzVJRraEhrx/bE0G@home.wiggy.net [213.84.101.140]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08DOx3v025511 for ; Wed, 8 Jan 2003 05:26:52 -0800 Received: from wichert by mx1.wiggy.net with local (Exim 3.35 #1 (Debian)) id 18WGHo-0007C1-00; Wed, 08 Jan 2003 14:30:24 +0100 Date: Wed, 8 Jan 2003 14:30:24 +0100 From: Wichert Akkerman To: Maciej Soltysiak Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: ipv6 stack seems to forget to send ACKs Message-ID: <20030108133024.GT22951@wiggy.net> Mail-Followup-To: Maciej Soltysiak , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20030108130850.GQ22951@wiggy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-archive-position: 1477 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wichert@wiggy.net Precedence: bulk X-list: netdev Previously Maciej Soltysiak wrote: > Which ipv6 client should i be using ? I am using a patched version of xmms using the patch from http://bugs.debian.org/155955 . (Don't forget to rerun autoconf after applying the patch). If you want I can create an ipv6 enabled xmms.deb for you if you are using Debian. Wichert. -- Wichert Akkerman http://www.wiggy.net/ A random hacker From solt@dns.toxicfilms.tv Wed Jan 8 05:47:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 05:47:56 -0800 (PST) Received: from dns.toxicfilms.tv (dns.toxicfilms.tv [150.254.37.24]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08DjP3v026256 for ; Wed, 8 Jan 2003 05:47:20 -0800 Received: by dns.toxicfilms.tv (Postfix, from userid 1000) id CBB9A8DE4C; Wed, 8 Jan 2003 14:51:06 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by dns.toxicfilms.tv (Postfix) with ESMTP id 2E4512372B; Wed, 8 Jan 2003 14:51:06 +0100 (CET) Date: Wed, 8 Jan 2003 14:51:05 +0100 (CET) From: Maciej Soltysiak To: Wichert Akkerman Cc: netdev@oss.sgi.com, Subject: Re: ipv6 stack seems to forget to send ACKs In-Reply-To: <20030108133024.GT22951@wiggy.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1478 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: solt@dns.toxicfilms.tv Precedence: bulk X-list: netdev > I am using a patched version of xmms using the patch from > http://bugs.debian.org/155955 . (Don't forget to rerun autoconf > after applying the patch). If you want I can create an ipv6 > enabled xmms.deb for you if you are using Debian. Well, i have xmms from deb package, so i would rather use an ip6 enabled deb. If that's not a problem. Maciej From wichert@wiggy.net Wed Jan 8 05:49:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 05:49:49 -0800 (PST) Received: from mx1.wiggy.net (IDENT:xKeC6Wb69AqLTiKE2HOPgYWpToqhJGHB@home.wiggy.net [213.84.101.140]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08DlN3v026275 for ; Wed, 8 Jan 2003 05:49:16 -0800 Received: from wichert by mx1.wiggy.net with local (Exim 3.35 #1 (Debian)) id 18WGdZ-0007NZ-00; Wed, 08 Jan 2003 14:52:53 +0100 Date: Wed, 8 Jan 2003 14:52:53 +0100 From: Wichert Akkerman To: Maciej Soltysiak Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: ipv6 stack seems to forget to send ACKs Message-ID: <20030108135253.GW22951@wiggy.net> Mail-Followup-To: Maciej Soltysiak , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20030108133024.GT22951@wiggy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-archive-position: 1479 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wichert@wiggy.net Precedence: bulk X-list: netdev Previously Maciej Soltysiak wrote: > Well, i have xmms from deb package, so i would rather use an > ip6 enabled deb. If that's not a problem. No problem. Are you running stable, testing or unstable? Wichert. -- Wichert Akkerman http://www.wiggy.net/ A random hacker From solt@dns.toxicfilms.tv Wed Jan 8 05:52:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 05:52:51 -0800 (PST) Received: from dns.toxicfilms.tv (dns.toxicfilms.tv [150.254.37.24]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08DoO3v029933 for ; Wed, 8 Jan 2003 05:52:17 -0800 Received: by dns.toxicfilms.tv (Postfix, from userid 1000) id 790EA8DE4C; Wed, 8 Jan 2003 14:56:04 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by dns.toxicfilms.tv (Postfix) with ESMTP id 54E602372B; Wed, 8 Jan 2003 14:56:04 +0100 (CET) Date: Wed, 8 Jan 2003 14:56:04 +0100 (CET) From: Maciej Soltysiak To: Wichert Akkerman Cc: netdev@oss.sgi.com, Subject: Re: ipv6 stack seems to forget to send ACKs In-Reply-To: <20030108135253.GW22951@wiggy.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1480 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: solt@dns.toxicfilms.tv Precedence: bulk X-list: netdev > No problem. Are you running stable, testing or unstable? stable here. Maciej From wichert@wiggy.net Wed Jan 8 06:05:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 06:06:30 -0800 (PST) Received: from mx1.wiggy.net (IDENT:VNaEOWMTl46wMTX0lhzIltJMsVHKYy26@home.wiggy.net [213.84.101.140]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08E433v032121 for ; Wed, 8 Jan 2003 06:05:56 -0800 Received: from wichert by mx1.wiggy.net with local (Exim 3.35 #1 (Debian)) id 18WGte-0007U3-00; Wed, 08 Jan 2003 15:09:30 +0100 Date: Wed, 8 Jan 2003 15:09:30 +0100 From: Wichert Akkerman To: Maciej Soltysiak Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: ipv6 stack seems to forget to send ACKs Message-ID: <20030108140929.GZ22951@wiggy.net> Mail-Followup-To: Maciej Soltysiak , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20030108135253.GW22951@wiggy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-archive-position: 1481 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wichert@wiggy.net Precedence: bulk X-list: netdev Previously Maciej Soltysiak wrote: > stable here. Packages are at http://www.wiggy.net/tmp/xmms/ now. Wichert. -- Wichert Akkerman http://www.wiggy.net/ A random hacker From solt@dns.toxicfilms.tv Wed Jan 8 06:39:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 06:40:25 -0800 (PST) Received: from dns.toxicfilms.tv (dns.toxicfilms.tv [150.254.37.24]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08Ebj3v001439 for ; Wed, 8 Jan 2003 06:39:48 -0800 Received: by dns.toxicfilms.tv (Postfix, from userid 1000) id 3D95B8E2A7; Wed, 8 Jan 2003 15:43:27 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by dns.toxicfilms.tv (Postfix) with ESMTP id E30292372B; Wed, 8 Jan 2003 15:43:27 +0100 (CET) Date: Wed, 8 Jan 2003 15:43:27 +0100 (CET) From: Maciej Soltysiak To: Wichert Akkerman Cc: netdev@oss.sgi.com, Subject: Re: ipv6 stack seems to forget to send ACKs In-Reply-To: <20030108130850.GQ22951@wiggy.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1482 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: solt@dns.toxicfilms.tv Precedence: bulk X-list: netdev I had no problems listening to the stream, except a gap after about 3mins. tcpdump showed the client closed the connection, and quickly initiated a new one. Since then i had 15mins of nonstop playback and it stopped, similarily to your dump. The tcpdump is similar to yours, except i do not have traffic class info. And rarely sack was used. Is there a ip6 mangling router in your route to the icecast server? I have been listening on an ip6 enabled host behind my ip6 tunnelling router to my MAN. Client: linux-2.4.21-pre1 Router: linux-2.4.20-grsec I have to go now, i will look into that later. Regards, Maciej From wichert@wiggy.net Wed Jan 8 06:48:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 06:48:58 -0800 (PST) Received: from mx1.wiggy.net (IDENT:IWqrO79NoAv2h7Jsdx+1nbr86fjoZnax@home.wiggy.net [213.84.101.140]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08EkW3v001945 for ; Wed, 8 Jan 2003 06:48:26 -0800 Received: from wichert by mx1.wiggy.net with local (Exim 3.35 #1 (Debian)) id 18WHYx-0007oN-00; Wed, 08 Jan 2003 15:52:11 +0100 Date: Wed, 8 Jan 2003 15:52:11 +0100 From: Wichert Akkerman To: Maciej Soltysiak Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: ipv6 stack seems to forget to send ACKs Message-ID: <20030108145211.GD22951@wiggy.net> Mail-Followup-To: Maciej Soltysiak , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20030108130850.GQ22951@wiggy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-archive-position: 1483 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wichert@wiggy.net Precedence: bulk X-list: netdev Previously Maciej Soltysiak wrote: > Is there a ip6 mangling router in your route to the icecast server? Not to my knowledge. traceroute6 shows: traceroute to ipv6.lkml.org (2001:968:1::2) from 3ffe:8280:10:1d0:290:27ff:fe2d:968c, 30 hops max, 16 byte packets 1 thunder.wiggy.net (3ffe:8280:10:1d0:250:4ff:fe0b:dd79) 0.666 ms 0.22 ms 0.199 ms 2 xs4all-29.ipv6.xs4all.nl (3ffe:8280:0:2001::58) 27.568 ms 28.012 ms 30.177 ms 3 26.ge-0-2-0.xr1.pbw.xs4all.net (2001:888:0:3::1) 22.035 ms 19.528 ms 44.644 ms 4 0.ge-0-3-0.xr1.sara.xs4all.net (2001:888:2:1::1) 19.519 ms 19.002 ms 21.974 ms 5 fe-0-0-0.ams-core-01.network6.isp-services.nl (2001:7f8:1::a502:4875:1) 19.978 ms 30.278 ms 20.248 ms 6 2001:968::2 (2001:968::2) 24.246 ms 24.083 ms 22.918 ms 7 2001:968:1::2 (2001:968:1::2) 24.978 ms 23.866 ms 23.661 ms thunder.wiggy.net is my Linux router running 2.4.19-pre5-ac3-freeswan196 currently. The second hop is a normal sit tunnel and all the other hops are native ipv6 using Cisco and Juniper routers as far as I know. If you want I can get a detailed list of the routers and the IOS/JunOS versions they are running. Wichert. -- Wichert Akkerman http://www.wiggy.net/ A random hacker From wichert@wiggy.net Wed Jan 8 06:58:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 06:58:55 -0800 (PST) Received: from mx1.wiggy.net (IDENT:NafriL3WU4GjtJaUmfVQV9TrjDaIY8tW@home.wiggy.net [213.84.101.140]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08EuT3v002620 for ; Wed, 8 Jan 2003 06:58:22 -0800 Received: from wichert by mx1.wiggy.net with local (Exim 3.35 #1 (Debian)) id 18WHiU-0007w6-00; Wed, 08 Jan 2003 16:02:02 +0100 Date: Wed, 8 Jan 2003 16:02:01 +0100 From: Wichert Akkerman To: Maciej Soltysiak , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: ipv6 stack seems to forget to send ACKs Message-ID: <20030108150201.GA30490@wiggy.net> Mail-Followup-To: Maciej Soltysiak , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20030108130850.GQ22951@wiggy.net> <20030108145211.GD22951@wiggy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030108145211.GD22951@wiggy.net> User-Agent: Mutt/1.3.28i X-archive-position: 1484 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wichert@wiggy.net Precedence: bulk X-list: netdev Previously Wichert Akkerman wrote: > traceroute to ipv6.lkml.org (2001:968:1::2) from > 3ffe:8280:10:1d0:290:27ff:fe2d:968c, 30 hops max, 16 byte packets > 1 thunder.wiggy.net (3ffe:8280:10:1d0:250:4ff:fe0b:dd79) 0.666 ms 0.22 ms 0.199 ms > 2 xs4all-29.ipv6.xs4all.nl (3ffe:8280:0:2001::58) 27.568 ms 28.012 ms 30.177 ms > 3 26.ge-0-2-0.xr1.pbw.xs4all.net (2001:888:0:3::1) 22.035 ms 19.528 ms 44.644 ms > 4 0.ge-0-3-0.xr1.sara.xs4all.net (2001:888:2:1::1) 19.519 ms 19.002 ms 21.974 ms > 5 fe-0-0-0.ams-core-01.network6.isp-services.nl (2001:7f8:1::a502:4875:1) 19.978 ms 30.278 ms 20.248 ms > 6 2001:968::2 (2001:968::2) 24.246 ms 24.083 ms 22.918 ms > 7 2001:968:1::2 (2001:968:1::2) 24.978 ms 23.866 ms 23.661 ms > > thunder.wiggy.net is my Linux router running 2.4.19-pre5-ac3-freeswan196 > currently. The second hop is a normal sit tunnel and all the other > hops are native ipv6 using Cisco and Juniper routers as far as I know. Slight correction to that: xs4all-29.ipv6.xs4all.nl is a FreeBSD-4.5 tunnel server. The toher xs4all.net hops are Junipers running JunOS 5.3 or 5.5. Wichert. -- Wichert Akkerman http://www.wiggy.net/ A random hacker From fabbione@fabbione.net Wed Jan 8 07:18:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 07:18:56 -0800 (PST) Received: from trider-g7.fabbione.net (port5.ds1-sby.adsl.cybercity.dk [212.242.169.198]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08FGT3v004050 for ; Wed, 8 Jan 2003 07:18:22 -0800 Received: from trider-g7.ext.fabbione.net (port5.ds1-sby.adsl.cybercity.dk [212.242.169.198]) by trider-g7.fabbione.net (Postfix) with ESMTP id 72E951F; Wed, 8 Jan 2003 16:22:07 +0100 (CET) Date: Wed, 8 Jan 2003 16:22:07 +0100 (CET) From: Fabio Massimo Di Nitto To: Wichert Akkerman Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: ipv6 stack seems to forget to send ACKs In-Reply-To: <20030108130850.GQ22951@wiggy.net> Message-ID: References: <20030108130850.GQ22951@wiggy.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1485 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fabbione@fabbione.net Precedence: bulk X-list: netdev Hi On Wed, 8 Jan 2003, Wichert Akkerman wrote: > tornado.wiggy.net is my client running Linux 2.4.19 (unpatched, UP machine), > and 2001:968:1::2 is the icecast server running Linux 2.4.20-rc2-ac3 (SMP). > If you want to test the stream yourself, please stream from > http://ipv6.lkml.org:8000/difm . > I have no problem to stream from there. kernel-source-2.4.19 here. several tunnels in the middle and different brand of routers... anyway Im farly sure that the xmms patch is not the problem. We have been testing it for more than 6 months now (for inclusion in debian, we are not the upstream) and yes we hit a similar problems with one icecast server but at that time we didn't care too much since it was basically at the first tests round. I will see if i can get it up and running again (it is not under my control) and investigate a bit more into it. Thanks Fabio From solt@dns.toxicfilms.tv Wed Jan 8 08:33:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 08:34:11 -0800 (PST) Received: from dns.toxicfilms.tv (dns.toxicfilms.tv [150.254.37.24]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08GXt3v010693 for ; Wed, 8 Jan 2003 08:33:58 -0800 Received: by dns.toxicfilms.tv (Postfix, from userid 1000) id 0303F8E384; Wed, 8 Jan 2003 17:39:36 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by dns.toxicfilms.tv (Postfix) with ESMTP id 826A723C13; Wed, 8 Jan 2003 17:39:36 +0100 (CET) Date: Wed, 8 Jan 2003 17:39:36 +0100 (CET) From: Maciej Soltysiak To: Wichert Akkerman Cc: netdev@oss.sgi.com, Subject: Re: ipv6 stack seems to forget to send ACKs In-Reply-To: <20030108150201.GA30490@wiggy.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1486 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: solt@dns.toxicfilms.tv Precedence: bulk X-list: netdev > Previously Wichert Akkerman wrote: > > traceroute to ipv6.lkml.org (2001:968:1::2) from > > 3ffe:8280:10:1d0:290:27ff:fe2d:968c, 30 hops max, 16 byte packets > > 1 thunder.wiggy.net (3ffe:8280:10:1d0:250:4ff:fe0b:dd79) 0.666 ms 0.22 ms 0.199 ms > > 2 xs4all-29.ipv6.xs4all.nl (3ffe:8280:0:2001::58) 27.568 ms 28.012 ms 30.177 ms > > 3 26.ge-0-2-0.xr1.pbw.xs4all.net (2001:888:0:3::1) 22.035 ms 19.528 ms 44.644 ms > > 4 0.ge-0-3-0.xr1.sara.xs4all.net (2001:888:2:1::1) 19.519 ms 19.002 ms 21.974 ms > > 5 fe-0-0-0.ams-core-01.network6.isp-services.nl (2001:7f8:1::a502:4875:1) 19.978 ms 30.278 ms 20.248 ms > > 6 2001:968::2 (2001:968::2) 24.246 ms 24.083 ms 22.918 ms > > 7 2001:968:1::2 (2001:968:1::2) 24.978 ms 23.866 ms 23.661 ms > > > > thunder.wiggy.net is my Linux router running 2.4.19-pre5-ac3-freeswan196 > > currently. The second hop is a normal sit tunnel and all the other > > hops are native ipv6 using Cisco and Juniper routers as far as I know. > > Slight correction to that: xs4all-29.ipv6.xs4all.nl is a FreeBSD-4.5 > tunnel server. The toher xs4all.net hops are Junipers running JunOS 5.3 > or 5.5. I had four contiguous listenings: 3 mins 10mins 19mins 13mins When i increased the buffer in xmms i got better uninterrupted timings. And survived data gaps better. I seem to be getting better results than you, i think that it is not an issue of ipv6 implementation but simply the case of time sensitive traffic fighting with other Internet traffic over tunnels through ipv4 networks. I do not know how many tunnels are in my path, i know that hop distance to my tunnel is exactly 1 hop (ipv6 broker and ipv4 provider are the same) If there is immense traffic at one of the routers (total traffic on an interface) stream packets can be simply dropped if there are no queuing disciplines that would take eg. flow control into account. What do you think? btw. what the hell is JunOs ? Regards, Maciej Soltysiak From wichert@wiggy.net Wed Jan 8 08:38:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 08:38:21 -0800 (PST) Received: from mx1.wiggy.net (IDENT:ZVFubOg8X27L01IFb67DfrhekKEyBe7c@home.wiggy.net [213.84.101.140]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08GcC3v011135 for ; Wed, 8 Jan 2003 08:38:14 -0800 Received: from wichert by mx1.wiggy.net with local (Exim 3.35 #1 (Debian)) id 18WJIx-0000UI-00; Wed, 08 Jan 2003 17:43:47 +0100 Date: Wed, 8 Jan 2003 17:43:47 +0100 From: Wichert Akkerman To: Maciej Soltysiak Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: ipv6 stack seems to forget to send ACKs Message-ID: <20030108164347.GK22951@wiggy.net> Mail-Followup-To: Maciej Soltysiak , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20030108150201.GA30490@wiggy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-archive-position: 1487 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wichert@wiggy.net Precedence: bulk X-list: netdev Previously Maciej Soltysiak wrote: > I do not know how many tunnels are in my path, i know that hop distance to > my tunnel is exactly 1 hop (ipv6 broker and ipv4 provider are the same) My tunnel provider is 5 hops away. To my knowledge non of the ipv4 or ipv6 hops in the path are congested and no traffic shaping is done. > If there is immense traffic at one of the routers (total traffic on an > interface) stream packets can be simply dropped if there are no queuing > disciplines that would take eg. flow control into account. I'll ask the ISPs involved to check if this might be happening, but I highly doubt it. > btw. what the hell is JunOs ? Juniper OS, running on Juniper routers. Wichert. -- Wichert Akkerman http://www.wiggy.net/ A random hacker From wichert@wiggy.net Wed Jan 8 08:56:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 08:56:07 -0800 (PST) Received: from mx1.wiggy.net (IDENT:kmQPb0/3RRMpejJol1rIMYa3iR5Ij+ds@home.wiggy.net [213.84.101.140]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08Gu23v012144 for ; Wed, 8 Jan 2003 08:56:03 -0800 Received: from wichert by mx1.wiggy.net with local (Exim 3.35 #1 (Debian)) id 18WJaF-0000c6-00; Wed, 08 Jan 2003 18:01:39 +0100 Date: Wed, 8 Jan 2003 18:01:39 +0100 From: Wichert Akkerman To: linux-kernel@vger.kernel.org Cc: Maciej Soltysiak , netdev@oss.sgi.com Subject: Re: ipv6 stack seems to forget to send ACKs Message-ID: <20030108170139.GL22951@wiggy.net> Mail-Followup-To: linux-kernel@vger.kernel.org, Maciej Soltysiak , netdev@oss.sgi.com References: <20030108150201.GA30490@wiggy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-archive-position: 1488 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wichert@wiggy.net Precedence: bulk X-list: netdev Previously Maciej Soltysiak wrote: > I seem to be getting better results than you, i think that it is not an > issue of ipv6 implementation but simply the case of time sensitive > traffic fighting with other Internet traffic over tunnels through ipv4 > networks. Actually, I don't follow this. How could any kind of traffic shaping result in my client not sending ACKs, which is what the tcpdump seems to indicate? I can understand packets being dropped which would result in retransmits, but that is not the case here. Wichert. (usual I'm-no-network-guru-and-might-be-misreading-things disclaimer here) -- Wichert Akkerman http://www.wiggy.net/ A random hacker From solt@dns.toxicfilms.tv Wed Jan 8 09:38:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 09:38:08 -0800 (PST) Received: from dns.toxicfilms.tv (dns.toxicfilms.tv [150.254.37.24]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08Hc13v013290 for ; Wed, 8 Jan 2003 09:38:02 -0800 Received: by dns.toxicfilms.tv (Postfix, from userid 1000) id 839248E2AF; Wed, 8 Jan 2003 18:43:45 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by dns.toxicfilms.tv (Postfix) with ESMTP id 6B5C023620; Wed, 8 Jan 2003 18:43:45 +0100 (CET) Date: Wed, 8 Jan 2003 18:43:45 +0100 (CET) From: Maciej Soltysiak To: Wichert Akkerman Cc: linux-kernel@vger.kernel.org, Subject: Re: ipv6 stack seems to forget to send ACKs In-Reply-To: <20030108170139.GL22951@wiggy.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1489 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: solt@dns.toxicfilms.tv Precedence: bulk X-list: netdev > Actually, I don't follow this. How could any kind of traffic shaping > result in my client not sending ACKs, which is what the tcpdump > seems to indicate? Well, i think i made a mistake, writing about routers dropping the packets, it's not the case here, you are right. Maciej From fabbione@fabbione.net Wed Jan 8 09:59:58 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 10:00:06 -0800 (PST) Received: from trider-g7.fabbione.net (port5.ds1-sby.adsl.cybercity.dk [212.242.169.198]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08Hxu3v014143 for ; Wed, 8 Jan 2003 09:59:57 -0800 Received: from diapolon.int.fabbione.net (port5.ds1-sby.adsl.cybercity.dk [212.242.169.198]) by trider-g7.fabbione.net (Postfix) with ESMTP id 719971F; Wed, 8 Jan 2003 19:05:36 +0100 (CET) Date: Wed, 8 Jan 2003 19:05:36 +0100 (CET) From: Fabio Massimo Di Nitto To: Wichert Akkerman Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: ipv6 stack seems to forget to send ACKs In-Reply-To: <20030108130850.GQ22951@wiggy.net> Message-ID: References: <20030108130850.GQ22951@wiggy.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1490 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fabbione@fabbione.net Precedence: bulk X-list: netdev I was able to reproduce the problem again. I have been using ethereal to sniff instead of tcpdump and gave out some more info. basically the icecast server at certain time (but i can't predict exactly in which situations) just send a FIN, ACK packet to the client. Basically to close the connection and after a few packets the client of course answer.What is strange that in the meanwhile there are still 3/4 data packets coming from the server to the client. Regarding the network side I noticed the following: an average of 500ms to ping6 the server and 0 pkt loss few seconds before the FIN, ACK (server->client) and for about 6 pkts the average jumped to 2000ms I suspect that this network flap made the server thinking about and decided to close the connection. The full ethereal dump is available at http://www.fabbione.net/ice-xmms-ipv6.dump.bz2 but PLEASE note that it is a 10MB file and Im on a slow adsl line so be "nice". Fabio PS Im afraid/happy that anyway the problem is not related to the kernel version we are running. -- vega:~# apt-get install life Reading Package Lists... Done Building Dependency Tree... Done E: Couldn't find package life From andrew@indranet.co.nz Wed Jan 8 11:47:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 11:47:19 -0800 (PST) Received: from mail.acheron.indranet.co.nz (ns.indranet.co.nz [210.54.239.210]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08JlA3v017310 for ; Wed, 8 Jan 2003 11:47:12 -0800 Received: from localhost.localdomain (enso.acheron.indranet.co.nz [192.168.1.1]) by mail.acheron.indranet.co.nz (8.11.2/8.11.2) with ESMTP id h08Jp5Q22286; Thu, 9 Jan 2003 08:51:06 +1300 Date: Thu, 09 Jan 2003 08:52:19 +1300 From: Andrew McGregor To: Wichert Akkerman , linux-kernel@vger.kernel.org cc: Maciej Soltysiak , netdev@oss.sgi.com Subject: Re: ipv6 stack seems to forget to send ACKs Message-ID: <74190000.1042055539@localhost.localdomain> In-Reply-To: <20030108170139.GL22951@wiggy.net> References: <20030108150201.GA30490@wiggy.net> <20030108170139.GL22951@wiggy.net> X-Mailer: Mulberry/3.0.0b10 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 1491 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andrew@indranet.co.nz Precedence: bulk X-list: netdev Selective ACK is mandatory in IPv6 and uses a somewhat different algorithm, so you shouldn't be seeing nearly as many ACKs as an IPv4 client would do by default. Andrew --On Wednesday, January 08, 2003 18:01:39 +0100 Wichert Akkerman wrote: > Previously Maciej Soltysiak wrote: >> I seem to be getting better results than you, i think that it is not an >> issue of ipv6 implementation but simply the case of time sensitive >> traffic fighting with other Internet traffic over tunnels through ipv4 >> networks. > > Actually, I don't follow this. How could any kind of traffic shaping > result in my client not sending ACKs, which is what the tcpdump > seems to indicate? I can understand packets being dropped which > would result in retransmits, but that is not the case here. > > Wichert. > > (usual I'm-no-network-guru-and-might-be-misreading-things disclaimer here) > > -- > Wichert Akkerman http://www.wiggy.net/ > A random hacker > - > 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 andrew@indranet.co.nz Wed Jan 8 11:54:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 11:54:31 -0800 (PST) Received: from mail.acheron.indranet.co.nz (ns.indranet.co.nz [210.54.239.210]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08JsQ3v017728 for ; Wed, 8 Jan 2003 11:54:28 -0800 Received: from localhost.localdomain (enso.acheron.indranet.co.nz [192.168.1.1]) by mail.acheron.indranet.co.nz (8.11.2/8.11.2) with ESMTP id h08JwcQ22360; Thu, 9 Jan 2003 08:58:39 +1300 Date: Thu, 09 Jan 2003 08:59:53 +1300 From: Andrew McGregor To: Fabio Massimo Di Nitto , Wichert Akkerman cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: ipv6 stack seems to forget to send ACKs Message-ID: <78180000.1042055993@localhost.localdomain> In-Reply-To: References: <20030108130850.GQ22951@wiggy.net> X-Mailer: Mulberry/3.0.0b10 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 1492 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andrew@indranet.co.nz Precedence: bulk X-list: netdev --On Wednesday, January 08, 2003 19:05:36 +0100 Fabio Massimo Di Nitto wrote: > > I was able to reproduce the problem again. I have been using ethereal to > sniff instead of tcpdump and gave out some more info. > > basically the icecast server at certain time (but i can't predict > exactly in which situations) just send a FIN, ACK packet to the client. > Basically to close the connection and after a few packets the client of > course answer.What is strange that in the meanwhile there are still 3/4 > data packets coming from the server to the client. > > Regarding the network side I noticed the following: > > an average of 500ms to ping6 the server and 0 pkt loss > few seconds before the FIN, ACK (server->client) and for about 6 pkts the > average jumped to 2000ms > > I suspect that this network flap made the server thinking about > and decided to close > the connection. Probably on the server's side it got an ICMP Host Unreachable or two as some router updated its tables, and decided to close the connection. The FIN jumped the queue in one/several of the routers in the path, so it got reordered relative to the data. This would imply that the router in question had its route to you back by the time the FIN got there. Wierd, but far from impossible. > > The full ethereal dump is available at > http://www.fabbione.net/ice-xmms-ipv6.dump.bz2 > > but PLEASE note that it is a 10MB file and Im on a slow adsl line so be > "nice". I think you provided enough info to tell what happened. > > Fabio > > PS Im afraid/happy that anyway the problem is not related to the kernel > version we are running. Doesn't look like a kernel problem. Someone's got a dodgy link or a routing problem. Andrew From solt@dns.toxicfilms.tv Wed Jan 8 12:21:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 12:21:33 -0800 (PST) Received: from dns.toxicfilms.tv (dns.toxicfilms.tv [150.254.37.24]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08KLT3v018323 for ; Wed, 8 Jan 2003 12:21:30 -0800 Received: by dns.toxicfilms.tv (Postfix, from userid 1000) id F03928E2AF; Wed, 8 Jan 2003 21:27:02 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by dns.toxicfilms.tv (Postfix) with ESMTP id D9C2123637; Wed, 8 Jan 2003 21:27:02 +0100 (CET) Date: Wed, 8 Jan 2003 21:27:02 +0100 (CET) From: Maciej Soltysiak To: Andrew McGregor Cc: Fabio Massimo Di Nitto , Wichert Akkerman , , Subject: Re: ipv6 stack seems to forget to send ACKs In-Reply-To: <78180000.1042055993@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1493 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: solt@dns.toxicfilms.tv Precedence: bulk X-list: netdev > Probably on the server's side it got an ICMP Host Unreachable or two as > some router updated its tables, and decided to close the connection. Sounds reasonable to me. Could it mean that this router that we are talking about is simply slow or overloaded ? Maciej From fabbione@fabbione.net Wed Jan 8 12:25:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 12:25:28 -0800 (PST) Received: from trider-g7.fabbione.net (port5.ds1-sby.adsl.cybercity.dk [212.242.169.198]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08KPO3v018737 for ; Wed, 8 Jan 2003 12:25:25 -0800 Received: from diapolon.int.fabbione.net (port5.ds1-sby.adsl.cybercity.dk [212.242.169.198]) by trider-g7.fabbione.net (Postfix) with ESMTP id 00F011F; Wed, 8 Jan 2003 21:31:04 +0100 (CET) Date: Wed, 8 Jan 2003 21:31:04 +0100 (CET) From: Fabio Massimo Di Nitto To: Maciej Soltysiak Cc: Andrew McGregor , Wichert Akkerman , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [OT] Re: ipv6 stack seems to forget to send ACKs In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1494 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fabbione@fabbione.net Precedence: bulk X-list: netdev Definitly it is somehow unstable. Difficult to find the reason. Anyway Im sure that there is asimmetric routing between me and ipv6.lkml.org and I could see pkts coming back. It might not have been the case for Wichert Fabio On Wed, 8 Jan 2003, Maciej Soltysiak wrote: > > Probably on the server's side it got an ICMP Host Unreachable or two as > > some router updated its tables, and decided to close the connection. > Sounds reasonable to me. Could it mean that this router that we are > talking about is simply slow or overloaded ? > > Maciej > > > From andrew@indranet.co.nz Wed Jan 8 12:33:51 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 12:33:53 -0800 (PST) Received: from mail.acheron.indranet.co.nz (ns.indranet.co.nz [210.54.239.210]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08KXo3v019156 for ; Wed, 8 Jan 2003 12:33:51 -0800 Received: from localhost.localdomain (enso.acheron.indranet.co.nz [192.168.1.1]) by mail.acheron.indranet.co.nz (8.11.2/8.11.2) with ESMTP id h08Kc0Q22741; Thu, 9 Jan 2003 09:38:00 +1300 Date: Thu, 09 Jan 2003 09:39:15 +1300 From: Andrew McGregor To: Fabio Massimo Di Nitto , Maciej Soltysiak cc: Wichert Akkerman , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [OT] Re: ipv6 stack seems to forget to send ACKs Message-ID: <92200000.1042058355@localhost.localdomain> In-Reply-To: References: X-Mailer: Mulberry/3.0.0b10 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 1495 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andrew@indranet.co.nz Precedence: bulk X-list: netdev Probably not slow and/or overloaded. I'd think it's more likely that it has a routing update problem or an unreliable link. But whatever, this seemed to me to be a classic 'dodgy box in the middle' rather than an end host problem. Andrew --On Wednesday, January 08, 2003 21:31:04 +0100 Fabio Massimo Di Nitto wrote: > > Definitly it is somehow unstable. Difficult to find the reason. > Anyway Im sure that there is asimmetric routing between me and > ipv6.lkml.org and I could see pkts coming back. It might not have been the > case for Wichert > > Fabio > > On Wed, 8 Jan 2003, Maciej Soltysiak wrote: > >> > Probably on the server's side it got an ICMP Host Unreachable or two as >> > some router updated its tables, and decided to close the connection. >> Sounds reasonable to me. Could it mean that this router that we are >> talking about is simply slow or overloaded ? >> >> Maciej >> >> >> > > From wichert@wiggy.net Wed Jan 8 14:38:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 14:38:09 -0800 (PST) Received: from mx1.wiggy.net (IDENT:U4BSqM1KonoPQ7Q/WklqFlJgi89te4wk@home.wiggy.net [213.84.101.140]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08Mc53v021295 for ; Wed, 8 Jan 2003 14:38:06 -0800 Received: from wichert by mx1.wiggy.net with local (Exim 3.35 #1 (Debian)) id 18WOvE-00047s-00; Wed, 08 Jan 2003 23:43:40 +0100 Date: Wed, 8 Jan 2003 23:43:40 +0100 From: Wichert Akkerman To: Andrew McGregor Cc: Fabio Massimo Di Nitto , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: ipv6 stack seems to forget to send ACKs Message-ID: <20030108224339.GO22951@wiggy.net> Mail-Followup-To: Andrew McGregor , Fabio Massimo Di Nitto , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20030108130850.GQ22951@wiggy.net> <78180000.1042055993@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78180000.1042055993@localhost.localdomain> User-Agent: Mutt/1.3.28i X-archive-position: 1496 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wichert@wiggy.net Precedence: bulk X-list: netdev Previously Andrew McGregor wrote: > Probably on the server's side it got an ICMP Host Unreachable or two as > some router updated its tables, and decided to close the connection. The fact that this problem does not seem to occur when using a window XP client seems to contradict the suggestions that it may be a router problem. Wichert. -- Wichert Akkerman http://www.wiggy.net/ A random hacker From sri@us.ibm.com Wed Jan 8 14:58:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 14:58:29 -0800 (PST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08MwO3v022345 for ; Wed, 8 Jan 2003 14:58:25 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id h08N3H9j230860; Wed, 8 Jan 2003 18:03:17 -0500 Received: from dyn9-47-18-98.beaverton.ibm.com (dyn9-47-18-98.beaverton.ibm.com [9.47.18.98]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h08N35Qq127174; Wed, 8 Jan 2003 18:03:10 -0500 Date: Wed, 8 Jan 2003 15:04:53 -0800 (PST) From: Sridhar Samudrala X-X-Sender: To: , cc: , Subject: SCTP path mtu support needs some ip layer support. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1497 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Dave, Alexey, While working on the SCTP path mtu support, i realized that SCTP needs a mechanism to set/unset IP DF bit on a per-message basis(let ip_queue_xmit() know that it is OK to fragment this particular skb). With TCP, when path mtu discovery is on, DF bit is always set and hence this information can be maintained on a per socket basis in the inet_opt. But with SCTP, even when path mtu discovery is on, DF bit may need to be unset and let ip do fragmenation of certain messages which are already fragmented by sctp based on the old pmtu. Even when SCTP realizes that the pmtu is lowered, it cannot re-fragment the already fragmented messages that have TSNs(Transmission Sequence Nos) assigned. These messages may be waiting in the transmitted list and may need to be retransmitted later. I can think of 3 ways to solve this problem. 1. Add a new argument to ip_queue_xmit() to pass the value of DF bit. 2. Use the __unused field in skb to pass the value of DF bit. 3. Let SCTP call its own routine that fills in the ip header with the appropriate value in the DF bit, but this duplicates most of the code in ip_queue_xmit(). Also ip_options_build() needs to be exported. Which option do you prefer? Or can you suggest any better alternative? Thanks Sridhar From davem@redhat.com Wed Jan 8 15:10:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 15:10:11 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08NA53v023752 for ; Wed, 8 Jan 2003 15:10:05 -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 PAA17466; Wed, 8 Jan 2003 15:06:38 -0800 Date: Wed, 08 Jan 2003 15:06:38 -0800 (PST) Message-Id: <20030108.150638.09647984.davem@redhat.com> To: sri@us.ibm.com Cc: kuznet@ms2.inr.ac.ru, jgrimm2@us.ibm.com, netdev@oss.sgi.com Subject: Re: SCTP path mtu support needs some ip layer support. From: "David S. Miller" In-Reply-To: References: X-FalunGong: Information control. 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 X-archive-position: 1498 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: Sridhar Samudrala Date: Wed, 8 Jan 2003 15:04:53 -0800 (PST) 1. Add a new argument to ip_queue_xmit() to pass the value of DF bit. 2. Use the __unused field in skb to pass the value of DF bit. 3. Let SCTP call its own routine that fills in the ip header with the appropriate value in the DF bit, but this duplicates most of the code in ip_queue_xmit(). Also ip_options_build() needs to be exported. Which option do you prefer? Or can you suggest any better alternative? Too bad there's not a 4th option, fix SCTP. This is really broken that the data stream can get into a state where resegmentation cannot be performed. Sigh... I guess the new argument to ip_queue_xmit() is the least intrusive. From jgrimm2@us.ibm.com Wed Jan 8 15:34:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 15:35:01 -0800 (PST) Received: from mg02.austin.ibm.com (mg02.austin.ibm.com [192.35.232.12]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08NYp3v024358 for ; Wed, 8 Jan 2003 15:34:52 -0800 Received: from austin.ibm.com (netmail2.austin.ibm.com [9.3.7.139]) by mg02.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA42664; Wed, 8 Jan 2003 17:41:24 -0600 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.53.247.178]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA24322; Wed, 8 Jan 2003 17:40:26 -0600 Received: from us.ibm.com (touki.austin.ibm.com [9.53.216.243]) by popmail.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) with ESMTP id RAA19886; Wed, 8 Jan 2003 17:40:25 -0600 Message-ID: <3E1CAACB.5D1B82DB@us.ibm.com> Date: Wed, 08 Jan 2003 16:48:43 -0600 From: Jon Grimm X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.5.53 i686) X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: sri@us.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: SCTP path mtu support needs some ip layer support. References: <20030108.150638.09647984.davem@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1499 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgrimm2@us.ibm.com Precedence: bulk X-list: netdev "David S. Miller" wrote: > > From: Sridhar Samudrala > Date: Wed, 8 Jan 2003 15:04:53 -0800 (PST) > > 1. Add a new argument to ip_queue_xmit() to pass the value of DF bit. > 2. Use the __unused field in skb to pass the value of DF bit. > 3. Let SCTP call its own routine that fills in the ip header with the > appropriate value in the DF bit, but this duplicates most of the code > in ip_queue_xmit(). Also ip_options_build() needs to be exported. > > Which option do you prefer? Or can you suggest any better alternative? > > Too bad there's not a 4th option, fix SCTP. This is really broken > that the data stream can get into a state where resegmentation cannot > be performed. > > Sigh... I guess the new argument to ip_queue_xmit() is the least > intrusive. I hate to mention it, but there is at least one other alternative (to complete the picture) that is to chunk up the messages into their smallest fragment and then bundle these chunks up to the MTU allowable packet. This however does each up space in the packet for each chunk header and require more processing at the other end to reassemble the records. IIRC, this is what OpenSS7s SCTP does, while the KAME SCTP manually controls the DF bit as per Sridhar's suggestion. There are tradeoffs in either approach. Best Regards, Jon From davem@redhat.com Wed Jan 8 15:48:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 15:48:49 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08Nmh3v025333 for ; Wed, 8 Jan 2003 15:48:43 -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 PAA17623; Wed, 8 Jan 2003 15:45:17 -0800 Date: Wed, 08 Jan 2003 15:45:16 -0800 (PST) Message-Id: <20030108.154516.123656229.davem@redhat.com> To: jgrimm2@us.ibm.com Cc: sri@us.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: SCTP path mtu support needs some ip layer support. From: "David S. Miller" In-Reply-To: <3E1CAACB.5D1B82DB@us.ibm.com> References: <20030108.150638.09647984.davem@redhat.com> <3E1CAACB.5D1B82DB@us.ibm.com> X-FalunGong: Information control. 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 X-archive-position: 1500 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: Jon Grimm Date: Wed, 08 Jan 2003 16:48:43 -0600 IIRC, this is what OpenSS7s SCTP does, while the KAME SCTP manually controls the DF bit as per Sridhar's suggestion. There are tradeoffs in either approach. Then the decision is currently up to you :-) From niv@us.ibm.com Wed Jan 8 15:52:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 15:52:59 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08Nqu3v025770 for ; Wed, 8 Jan 2003 15:52:57 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id h08Nw2I8159504; Wed, 8 Jan 2003 18:58:02 -0500 Received: from us.ibm.com (dyn9-47-18-188.beaverton.ibm.com [9.47.18.188]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h08NvvQp127126; Wed, 8 Jan 2003 18:57:58 -0500 Message-ID: <3E1CBAB2.78FE168A@us.ibm.com> Date: Wed, 08 Jan 2003 15:56:34 -0800 From: Nivedita Singhvi Reply-To: niv@us.ibm.com X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jon Grimm CC: "David S. Miller" , sri@us.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: SCTP path mtu support needs some ip layer support. References: <20030108.150638.09647984.davem@redhat.com> <3E1CAACB.5D1B82DB@us.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1501 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Jon Grimm wrote: > > "David S. Miller" wrote: > > > > From: Sridhar Samudrala > > Date: Wed, 8 Jan 2003 15:04:53 -0800 (PST) > > Sigh... I guess the new argument to ip_queue_xmit() is the least > > intrusive. > > I hate to mention it, but there is at least one other alternative (to > complete the picture) that is to chunk up the messages into their > smallest fragment and then bundle these chunks up to the MTU allowable > packet. > This however does each up space in the packet for each chunk header and > require more processing at the other end to reassemble the records. > > IIRC, this is what OpenSS7s SCTP does, while the KAME SCTP manually > controls the DF bit as per Sridhar's suggestion. There are tradeoffs > in either approach. Jon, from the performance standpoint, that would be the least preferred approach, right? Also, adding the argument to ip_queue_xmit() would at least be a general solution for other possible protocols, raw apps, etc or features that might want to make use of it.. (heaven forbid ;)).. thanks, Nivedita From fabbione@fabbione.net Wed Jan 8 23:23:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Jan 2003 23:23:47 -0800 (PST) Received: from trider-g7.fabbione.net (port5.ds1-sby.adsl.cybercity.dk [212.242.169.198]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h097Na3v030343 for ; Wed, 8 Jan 2003 23:23:38 -0800 Received: from trider-g7.ext.fabbione.net (port5.ds1-sby.adsl.cybercity.dk [212.242.169.198]) by trider-g7.fabbione.net (Postfix) with ESMTP id 6296A1E; Thu, 9 Jan 2003 08:29:19 +0100 (CET) Date: Thu, 9 Jan 2003 08:29:19 +0100 (CET) From: Fabio Massimo Di Nitto To: Wichert Akkerman Cc: Andrew McGregor , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: ipv6 stack seems to forget to send ACKs In-Reply-To: <20030108224339.GO22951@wiggy.net> Message-ID: References: <20030108130850.GQ22951@wiggy.net> <78180000.1042055993@localhost.localdomain> <20030108224339.GO22951@wiggy.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1502 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fabbione@fabbione.net Precedence: bulk X-list: netdev On Wed, 8 Jan 2003, Wichert Akkerman wrote: > Previously Andrew McGregor wrote: > > Probably on the server's side it got an ICMP Host Unreachable or two as > > some router updated its tables, and decided to close the connection. > > The fact that this problem does not seem to occur when using a window > XP client seems to contradict the suggestions that it may be a router > problem. > > Wichert. > > Is the WinXP client located in the same place where you are? From my side the ISP that is giving me problems is xs26.net at 2 different points. One is flapping and one is the link between them and another ISP (i can't even reach it now) where pkts get seriously delayed (from 100ms to more than 350ms) probably due to a slow link. But what is seriously annoying is that xs26.net keeps announcing a network that it can't reach, fscking the entire routing. Fabio From davem@redhat.com Thu Jan 9 00:17:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Jan 2003 00:18:00 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h098Hp3v031268 for ; Thu, 9 Jan 2003 00:17:52 -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 AAA23262; Thu, 9 Jan 2003 00:14:21 -0800 Date: Thu, 09 Jan 2003 00:14:21 -0800 (PST) Message-Id: <20030109.001421.60144885.davem@redhat.com> To: blueflux@koffein.net Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [PATCH] proc.txt document fix of error_burst and error_cost From: "David S. Miller" In-Reply-To: References: X-FalunGong: Information control. 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 X-archive-position: 1503 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: Oskar Andreasson Date: Thu, 7 Nov 2002 18:00:35 +0100 (CET) The patch should apply against both 2.4.19 and 2.5.45 without problems. Is there anything wrong with it, or may it be included? Suggestions? Patch applied, thanks. From davem@redhat.com Thu Jan 9 00:42:47 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Jan 2003 00:42:50 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h098gk3v031882 for ; Thu, 9 Jan 2003 00:42:46 -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 AAA23320; Thu, 9 Jan 2003 00:39:29 -0800 Date: Thu, 09 Jan 2003 00:39:29 -0800 (PST) Message-Id: <20030109.003929.89643598.davem@redhat.com> To: usagi-core@linux-ipv6.org, Kazunori.Miyazawa@jp.yokogawa.com Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: (usagi-core 11007) [PATCH] IPsec Configuration Extension for IPv6 From: "David S. Miller" In-Reply-To: <20030107130050.0903bf59.Kazunori.Miyazawa@jp.yokogawa.com> References: <20030107130050.0903bf59.Kazunori.Miyazawa@jp.yokogawa.com> X-FalunGong: Information control. 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 X-archive-position: 1504 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: Kazunori Miyazawa Date: Tue, 7 Jan 2003 13:00:50 +0900 This patch is simple extension of PF_KEY to support IPv6; to accept IPv6 IPsec configurations. Ok. Your patch looks OK and probably I will integrate it to my tree tomorrow. However this patch does not contain any codes to process the packets in IPv6 stack because we wonder how we should implement it: 1. The building packet codes of datagram (ip_append_data()) is very different from ip6_build_xmit(). And I guess you will change ip6_build_xmit() to ip6_append_data(). 2. How should we implement to process destination option header which is inside of AH and/or ESP? There seems two options. One is to process IPsec on parsing extension headers. The other is to process IPsec as upper layer protocol and we always check the destination option header when we finish to process AH or ESP. We will be glad to hear your preferences, plans or a better way to implementation. To be honest no concrete plans exist. Alexey is currently offline and I expected to bring him into an ipv6 ipsec discussion as soon as he reappears. I do not know when he will return, however. Because of this, I would suggest to just keep working in area of AH/ESP ipv6-specific packet creation and parsing. Stay clear of routing/dst/input/output interface issues. If you finish the packet handling/building work and Alexey does not return, we can work on design without him. From wichert@wiggy.net Thu Jan 9 01:33:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Jan 2003 01:33:09 -0800 (PST) Received: from mx1.wiggy.net (IDENT:/x8iDuztves3DpBcm3EmnX9FenmeNXlh@home.wiggy.net [213.84.101.140]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h099X13v000565 for ; Thu, 9 Jan 2003 01:33:03 -0800 Received: from wichert by mx1.wiggy.net with local (Exim 3.35 #1 (Debian)) id 18WZ93-00080X-00; Thu, 09 Jan 2003 10:38:37 +0100 Date: Thu, 9 Jan 2003 10:38:36 +0100 From: Wichert Akkerman To: Fabio Massimo Di Nitto Cc: Andrew McGregor , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: ipv6 stack seems to forget to send ACKs Message-ID: <20030109093836.GG22951@wiggy.net> Mail-Followup-To: Fabio Massimo Di Nitto , Andrew McGregor , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20030108130850.GQ22951@wiggy.net> <78180000.1042055993@localhost.localdomain> <20030108224339.GO22951@wiggy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-archive-position: 1505 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wichert@wiggy.net Precedence: bulk X-list: netdev Previously Fabio Massimo Di Nitto wrote: > Is the WinXP client located in the same place where you are? Yes. (Well, not my place but a friend who had both linux and XP did that test). Wichert. -- Wichert Akkerman http://www.wiggy.net/ A random hacker From fabbione@fabbione.net Thu Jan 9 01:37:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Jan 2003 01:37:30 -0800 (PST) Received: from trider-g7.fabbione.net (port5.ds1-sby.adsl.cybercity.dk [212.242.169.198]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h099bP3v001105 for ; Thu, 9 Jan 2003 01:37:26 -0800 Received: from trider-g7.ext.fabbione.net (port5.ds1-sby.adsl.cybercity.dk [212.242.169.198]) by trider-g7.fabbione.net (Postfix) with ESMTP id 8A3DF1E; Thu, 9 Jan 2003 10:43:08 +0100 (CET) Date: Thu, 9 Jan 2003 10:43:08 +0100 (CET) From: Fabio Massimo Di Nitto To: Wichert Akkerman Cc: Andrew McGregor , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: ipv6 stack seems to forget to send ACKs In-Reply-To: <20030109093836.GG22951@wiggy.net> Message-ID: References: <20030108130850.GQ22951@wiggy.net> <78180000.1042055993@localhost.localdomain> <20030108224339.GO22951@wiggy.net> <20030109093836.GG22951@wiggy.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1506 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fabbione@fabbione.net Precedence: bulk X-list: netdev On Thu, 9 Jan 2003, Wichert Akkerman wrote: > Previously Fabio Massimo Di Nitto wrote: > > Is the WinXP client located in the same place where you are? > > Yes. (Well, not my place but a friend who had both linux and XP did > that test). > > Wichert. > > hmmmm strange because now I have forced the route to ipv6.lkml.org via another ISP (bypassing xs26.net) and it is more than 3 hours that xmms is streaming without interruptions. Fabio From wichert@wiggy.net Thu Jan 9 02:35:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Jan 2003 02:35:21 -0800 (PST) Received: from mx1.wiggy.net (IDENT:TRQ41RCGq02eTrmU05mHYx7X1+mzvCRt@home.wiggy.net [213.84.101.140]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h09AZD3v006164 for ; Thu, 9 Jan 2003 02:35:14 -0800 Received: from wichert by mx1.wiggy.net with local (Exim 3.35 #1 (Debian)) id 18Wa7N-0008RK-00; Thu, 09 Jan 2003 11:40:57 +0100 Date: Thu, 9 Jan 2003 11:40:57 +0100 From: Wichert Akkerman To: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: ipv6 stack seems to forget to send ACKs Message-ID: <20030109104057.GM22951@wiggy.net> Mail-Followup-To: netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20030108224339.GO22951@wiggy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-archive-position: 1507 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wichert@wiggy.net Precedence: bulk X-list: netdev Previously Maciej Soltysiak wrote: > What other linux clients support streaming on ip6 ? patched mpg123 maybe? The xmms patch can be adopted to work for mpg123 I suspect, I haven't tried that. > What XP client are you using ? Iirc mediaplayer was used. > Maybe it is a client issue, you say the client stops sending ACKs, maybe > the client code is buggy. I don't think a userspace tool can cause ACKs to stop being send. Wichert. -- Wichert Akkerman http://www.wiggy.net/ A random hacker From solt@dns.toxicfilms.tv Thu Jan 9 03:25:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Jan 2003 03:25:56 -0800 (PST) Received: from dns.toxicfilms.tv (dns.toxicfilms.tv [150.254.37.24]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h09BPb3v008175 for ; Thu, 9 Jan 2003 03:25:38 -0800 Received: by dns.toxicfilms.tv (Postfix, from userid 1000) id 59DB98E2AF; Thu, 9 Jan 2003 11:32:48 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by dns.toxicfilms.tv (Postfix) with ESMTP id 0BEE023637; Thu, 9 Jan 2003 11:32:47 +0100 (CET) Date: Thu, 9 Jan 2003 11:32:47 +0100 (CET) From: Maciej Soltysiak To: Wichert Akkerman Cc: Andrew McGregor , Fabio Massimo Di Nitto , , Subject: Re: ipv6 stack seems to forget to send ACKs In-Reply-To: <20030108224339.GO22951@wiggy.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1508 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: solt@dns.toxicfilms.tv Precedence: bulk X-list: netdev > The fact that this problem does not seem to occur when using a window > XP client seems to contradict the suggestions that it may be a router > problem. What other linux clients support streaming on ip6 ? patched mpg123 maybe? What XP client are you using ? Maybe it is a client issue, you say the client stops sending ACKs, maybe the client code is buggy. > Wichert. Maciej. From R.E.Wolff@BitWizard.nl Thu Jan 9 03:33:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Jan 2003 03:33:26 -0800 (PST) Received: from abraracourcix.bitwizard.nl (users.linvision.com [62.58.92.114]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h09BXJ3v008610 for ; Thu, 9 Jan 2003 03:33:21 -0800 Received: (from wolff@localhost) by abraracourcix.bitwizard.nl (8.11.6/8.11.6/SuSE Linux 0.5) id h09Bcw316435; Thu, 9 Jan 2003 12:38:58 +0100 X-Authentication-Warning: abraracourcix.bitwizard.nl: wolff set sender to R.E.Wolff@BitWizard.nl using -f Date: Thu, 9 Jan 2003 12:38:58 +0100 From: Rogier Wolff To: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: ipv6 stack seems to forget to send ACKs Message-ID: <20030109123857.A15625@bitwizard.nl> References: <20030108130850.GQ22951@wiggy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030108130850.GQ22951@wiggy.net> User-Agent: Mutt/1.3.22.1i Organization: BitWizard.nl X-archive-position: 1509 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: R.E.Wolff@BitWizard.nl Precedence: bulk X-list: netdev On Wed, Jan 08, 2003 at 02:08:50PM +0100, Wichert Akkerman wrote: > > 13:57:39.812123 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9352713 win 32616 > 13:57:39.823581 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9352713:9353921(1208) ack 1 win 5712 [class 0x2] > 13:57:39.823636 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9353921 win 32616 The packet is acked about 50 us after reception. Wicked! > 13:57:39.835144 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9353921:9355129(1208) ack 1 win 5712 [class 0x2] > 13:57:39.835197 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9355129 win 32616 Same here. > 13:57:39.844277 2001:968:1::2.8000 > tornado.wiggy.net.33035: P 9355129:9355601(472) ack 1 win 5712 [class 0x2] > 13:57:39.844326 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9355601 win 32616 > 13:57:40.221776 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9355601:9356809(1208) ack 1 win 5712 [class 0x2] > 13:57:40.221846 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9356809 win 32616 > 13:57:40.233558 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9356809:9358017(1208) ack 1 win 5712 [class 0x2] > 13:57:40.233613 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9358017 win 32616 > 13:57:40.245110 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9358017:9359225(1208) ack 1 win 5712 [class 0x2] > 13:57:40.245160 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9359225 win 32616 same. same. same. > 13:57:40.282351 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 But now: No ack! Funny. > 13:57:40.284307 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9360433:9360653(220) ack 1 win 5712 Another packet, no ack! > 13:57:40.297307 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9360653:9361861(1208) ack 1 win 5712 > 13:57:40.297376 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9359225 win 32616 Another packet, but this time it SACKs the just-recieved packet. It looks as if the two packets inbetween somehow were not recognized as belonging with this connection. > 13:57:40.308222 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9362081:9363289(1208) ack 1 win 5712 [class 0x2] > 13:57:40.308271 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9359225 win 32616 new packet, recognized ok, buffered, and acked! > 13:57:40.310424 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9361861:9362081(220) ack 1 win 5712 > 13:57:40.310471 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9359225 win 32616 > 13:57:40.325396 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9363289:9363509(220) ack 1 win 5712 [class 0x2] > 13:57:40.325447 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9359225 win 32616 Two more packets, and still more hints towards the other machine that we're missing 9359225-9360653 > 13:57:40.568652 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 So, it retransmits the first. but we don't see it as beloging to this connection or something, so it gets ignored. > 13:57:41.121608 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 > 13:57:42.242095 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 > 13:57:44.481379 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 > 13:57:48.963035 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 again, again, again. It looks as if somehow those two packets 9359225:9360433 and 9360433:9360653 get mangled in a way as to invalidate the checksum. This would cause "silent drop" of these packets before they were acked.... Can you check the stats counters, to see if they are indeed dropped? Roger. -- ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * The Worlds Ecosystem is a stable system. Stable systems may experience * * excursions from the stable situation. We are currently in such an * * excursion: The stable situation does not include humans. *************** From andrew@indranet.co.nz Thu Jan 9 03:49:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Jan 2003 03:49:55 -0800 (PST) Received: from mail.acheron.indranet.co.nz (ns.indranet.co.nz [210.54.239.210]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h09Bnp3v009111 for ; Thu, 9 Jan 2003 03:49:53 -0800 Received: from localhost.localdomain (enso.acheron.indranet.co.nz [192.168.1.1]) by mail.acheron.indranet.co.nz (8.11.2/8.11.2) with ESMTP id h09BtOQ32155; Fri, 10 Jan 2003 00:55:24 +1300 Date: Fri, 10 Jan 2003 00:55:22 +1300 From: Andrew McGregor To: Rogier Wolff , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: ipv6 stack seems to forget to send ACKs Message-ID: <27430000.1042113322@localhost.localdomain> In-Reply-To: <20030109123857.A15625@bitwizard.nl> References: <20030108130850.GQ22951@wiggy.net> <20030109123857.A15625@bitwizard.nl> X-Mailer: Mulberry/3.0.0b10 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 1510 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andrew@indranet.co.nz Precedence: bulk X-list: netdev --On Thursday, January 09, 2003 12:38:58 +0100 Rogier Wolff wrote: > On Wed, Jan 08, 2003 at 02:08:50PM +0100, Wichert Akkerman wrote: >> Looked normal and then: > >> 13:57:40.282351 2001:968:1::2.8000 > tornado.wiggy.net.33035: . >> 9359225:9360433(1208) ack 1 win 5712 > > But now: No ack! Funny. Might be SACK deciding not to... >> 13:57:40.284307 2001:968:1::2.8000 > tornado.wiggy.net.33035: . >> 9360433:9360653(220) ack 1 win 5712 > > Another packet, no ack! > >> 13:57:40.297307 2001:968:1::2.8000 > tornado.wiggy.net.33035: . >> 9360653:9361861(1208) ack 1 win 5712 >> 13:57:40.297376 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack >> 9359225 win 32616 > 1 {9360653:9361861} > > > Another packet, but this time it SACKs the just-recieved packet. It looks > as if the two packets inbetween somehow were not recognized as belonging > with this connection. or SACK forgot about them? > Two more packets, and still more hints towards the other machine that > we're missing 9359225-9360653 > >> 13:57:40.568652 2001:968:1::2.8000 > tornado.wiggy.net.33035: . >> 9359225:9360433(1208) ack 1 win 5712 > > So, it retransmits the first. but we don't see it as beloging to > this connection or something, so it gets ignored. or we're waiting for the other one to ACK them both in one go? > It looks as if somehow those two packets 9359225:9360433 and > 9360433:9360653 get mangled in a way as to invalidate the checksum. This > would cause "silent drop" of these packets before they were acked.... Could be data dependant, so there's a pattern in the packet contents that causes this? > Can you check the stats counters, to see if they are indeed dropped? > > Roger. From wichert@wiggy.net Thu Jan 9 07:35:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Jan 2003 07:35:51 -0800 (PST) Received: from mx1.wiggy.net (IDENT:nTZH5u3VMkBuf2rXGtrntcqe2aeHqdhc@home.wiggy.net [213.84.101.140]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h09FZi3v024799 for ; Thu, 9 Jan 2003 07:35:46 -0800 Received: from wichert by mx1.wiggy.net with local (Exim 3.35 #1 (Debian)) id 18WeoC-0001md-00; Thu, 09 Jan 2003 16:41:28 +0100 Date: Thu, 9 Jan 2003 16:41:28 +0100 From: Wichert Akkerman To: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: ipv6 stack seems to forget to send ACKs Message-ID: <20030109154128.GT22951@wiggy.net> Mail-Followup-To: netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20030108130850.GQ22951@wiggy.net> <20030109123857.A15625@bitwizard.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030109123857.A15625@bitwizard.nl> User-Agent: Mutt/1.3.28i X-archive-position: 1511 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wichert@wiggy.net Precedence: bulk X-list: netdev Previously Rogier Wolff wrote: > Can you check the stats counters, to see if they are indeed dropped? If you can tell me to which counter I am looking for and where I can find that, sure. Wichert. -- Wichert Akkerman http://www.wiggy.net/ A random hacker From wichert@wiggy.net Thu Jan 9 07:46:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Jan 2003 07:46:38 -0800 (PST) Received: from mx1.wiggy.net (IDENT:FJZIJTw/3m+6/OClaLEpV6RvvV6o4BZn@home.wiggy.net [213.84.101.140]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h09FkU3v025258 for ; Thu, 9 Jan 2003 07:46:31 -0800 Received: from wichert by mx1.wiggy.net with local (Exim 3.35 #1 (Debian)) id 18Weyc-0001sD-00; Thu, 09 Jan 2003 16:52:14 +0100 Date: Thu, 9 Jan 2003 16:52:14 +0100 From: Wichert Akkerman To: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: ipv6 stack seems to forget to send ACKs Message-ID: <20030109155214.GX22951@wiggy.net> Mail-Followup-To: netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20030108130850.GQ22951@wiggy.net> <20030109123857.A15625@bitwizard.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030109123857.A15625@bitwizard.nl> User-Agent: Mutt/1.3.28i X-archive-position: 1512 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wichert@wiggy.net Precedence: bulk X-list: netdev Previously Rogier Wolff wrote: > Can you check the stats counters, to see if they are indeed dropped? It seems no packets are dropped: Ip: 269716 total packets received 0 forwarded 0 incoming packets discarded 206853 incoming packets delivered 221800 requests sent out 75513 reassemblies required 12713 packets reassembled ok 10798 fragments created Icmp: 0 ICMP messages received 0 input ICMP message failed. ICMP input histogram: 0 ICMP messages sent 0 ICMP messages failed ICMP output histogram: Tcp: 666 active connections openings 0 passive connection openings 0 failed connection attempts 0 connection resets received 2 connections established 58949 segments received 65043 segments send out 0 segments retransmited 18 bad segments received. 82 resets sent TcpExt: ArpFilter: 0 7 TCP sockets finished time wait in fast timer 1091 delayed acks sent 2 delayed acks further delayed because of locked socket 6 packets directly queued to recvmsg prequeue. 6 packets directly received from prequeue 52427 packets header predicted TCPPureAcks: 1259 TCPHPAcks: 10858 TCPRenoRecovery: 0 TCPSackRecovery: 0 TCPSACKReneging: 0 TCPFACKReorder: 0 TCPSACKReorder: 0 TCPRenoReorder: 0 TCPTSReorder: 0 TCPFullUndo: 0 TCPPartialUndo: 0 TCPDSACKUndo: 0 TCPLossUndo: 0 TCPLoss: 0 TCPLostRetransmit: 0 TCPRenoFailures: 0 TCPSackFailures: 0 TCPLossFailures: 0 TCPFastRetrans: 0 TCPForwardRetrans: 0 TCPSlowStartRetrans: 0 TCPTimeouts: 0 TCPRenoRecoveryFail: 0 TCPSackRecoveryFail: 0 TCPSchedulerFailed: 0 TCPRcvCollapsed: 0 TCPDSACKOldSent: 0 TCPDSACKOfoSent: 0 TCPDSACKRecv: 0 TCPDSACKOfoRecv: 0 TCPAbortOnSyn: 0 TCPAbortOnData: 24 TCPAbortOnClose: 67 TCPAbortOnMemory: 0 TCPAbortOnTimeout: 0 TCPAbortOnLinger: 0 TCPAbortFailed: 0 TCPMemoryPressures: 0 Wichert. -- Wichert Akkerman http://www.wiggy.net/ A random hacker From wichert@wiggy.net Thu Jan 9 07:57:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Jan 2003 07:57:42 -0800 (PST) Received: from mx1.wiggy.net (IDENT:hwOCjiQ4gaRUqnRD1vAdleh9fT6BR5c+@home.wiggy.net [213.84.101.140]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h09Fvc3v026432 for ; Thu, 9 Jan 2003 07:57:39 -0800 Received: from wichert by mx1.wiggy.net with local (Exim 3.35 #1 (Debian)) id 18Wf9N-0001xR-00; Thu, 09 Jan 2003 17:03:21 +0100 Date: Thu, 9 Jan 2003 17:03:21 +0100 From: Wichert Akkerman To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com Subject: Re: ipv6 stack seems to forget to send ACKs Message-ID: <20030109160321.GA7510@wiggy.net> Mail-Followup-To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <20030108130850.GQ22951@wiggy.net> <20030109123857.A15625@bitwizard.nl> <20030109155214.GX22951@wiggy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030109155214.GX22951@wiggy.net> User-Agent: Mutt/1.3.28i X-archive-position: 1513 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wichert@wiggy.net Precedence: bulk X-list: netdev Previously Wichert Akkerman wrote: > It seems no packets are dropped: And now for ipv6 statistics from /proc/net/snmp6 (thanks Jamal): Ip6InReceives 27011 Ip6InHdrErrors 0 Ip6InTooBigErrors 0 Ip6InNoRoutes 0 Ip6InAddrErrors 0 Ip6InUnknownProtos 0 Ip6InTruncatedPkts 0 Ip6InDiscards 0 Ip6InDelivers 26885 Ip6OutForwDatagrams 0 Ip6OutRequests 26848 Ip6OutDiscards 0 Ip6OutNoRoutes 0 Ip6ReasmTimeout 0 Ip6ReasmReqds 0 Ip6ReasmOKs 0 Ip6ReasmFails 0 Ip6FragOKs 0 Ip6FragFails 0 Ip6FragCreates 0 Ip6InMcastPkts 40 Ip6OutMcastPkts 0 Icmp6InMsgs 123 Icmp6InErrors 0 Icmp6InDestUnreachs 0 Icmp6InPktTooBigs 0 Icmp6InTimeExcds 0 Icmp6InParmProblems 0 Icmp6InEchos 0 Icmp6InEchoReplies 0 Icmp6InGroupMembQueries 0 Icmp6InGroupMembResponses 0 Icmp6InGroupMembReductions 0 Icmp6InRouterSolicits 0 Icmp6InRouterAdvertisements 40 Icmp6InNeighborSolicits 45 Icmp6InNeighborAdvertisements 38 Icmp6InRedirects 0 Icmp6OutMsgs 86 Icmp6OutDestUnreachs 0 Icmp6OutPktTooBigs 0 Icmp6OutTimeExcds 0 Icmp6OutParmProblems 0 Icmp6OutEchoReplies 0 Icmp6OutRouterSolicits 1 Icmp6OutNeighborSolicits 40 Icmp6OutNeighborAdvertisements 45 Icmp6OutRedirects 0 Icmp6OutGroupMembResponses 0 Icmp6OutGroupMembReductions 0 Udp6InDatagrams 0 Udp6NoPorts 0 Udp6InErrors 0 Udp6OutDatagrams 0 Wichert. -- Wichert Akkerman http://www.wiggy.net/ A random hacker From mika.liljeberg@welho.com Thu Jan 9 14:06:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Jan 2003 14:06:46 -0800 (PST) Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h09M6e3v026629 for ; Thu, 9 Jan 2003 14:06:41 -0800 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.6/8.12.6/Debian-8) with ESMTP id h09MCa4f012785; Fri, 10 Jan 2003 00:12:36 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.6/8.12.6/Debian-8) id h09MCXo4012784; Fri, 10 Jan 2003 00:12:33 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: ipv6 stack seems to forget to send ACKs From: Mika Liljeberg To: Wichert Akkerman Cc: linux-kernel@vger.kernel.org, Maciej Soltysiak , netdev@oss.sgi.com In-Reply-To: <20030108170139.GL22951@wiggy.net> References: <20030108150201.GA30490@wiggy.net> <20030108170139.GL22951@wiggy.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1042150352.4688.15.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 10 Jan 2003 00:12:33 +0200 X-archive-position: 1514 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mika.liljeberg@welho.com Precedence: bulk X-list: netdev Hi Wichert, Looking at your trace it seems that the receiving machine is dropping all packets that do not have traffic class set. Note that all segments received with [class 0x2] get properly acked. The others probably don't get to TCP at all. You might want to check your filters and QoS policies. BR, MikaL On Wed, 2003-01-08 at 19:01, Wichert Akkerman wrote: > Previously Maciej Soltysiak wrote: > > I seem to be getting better results than you, i think that it is not an > > issue of ipv6 implementation but simply the case of time sensitive > > traffic fighting with other Internet traffic over tunnels through ipv4 > > networks. > > Actually, I don't follow this. How could any kind of traffic shaping > result in my client not sending ACKs, which is what the tcpdump > seems to indicate? I can understand packets being dropped which > would result in retransmits, but that is not the case here. > > Wichert. > > (usual I'm-no-network-guru-and-might-be-misreading-things disclaimer here) From wichert@wiggy.net Thu Jan 9 14:16:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Jan 2003 14:16:18 -0800 (PST) Received: from mx1.wiggy.net (IDENT:1FywaVUgJQFC3xiPvs/KKgUM0lJDHNz+@home.wiggy.net [213.84.101.140]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h09MGB3v027044 for ; Thu, 9 Jan 2003 14:16:12 -0800 Received: from wichert by mx1.wiggy.net with local (Exim 3.35 #1 (Debian)) id 18Wl3j-0004Vx-00; Thu, 09 Jan 2003 23:21:55 +0100 Date: Thu, 9 Jan 2003 23:21:55 +0100 From: Wichert Akkerman To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: ipv6 stack seems to forget to send ACKs Message-ID: <20030109222155.GE22951@wiggy.net> Mail-Followup-To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <20030108150201.GA30490@wiggy.net> <20030108170139.GL22951@wiggy.net> <1042150352.4688.15.camel@devil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1042150352.4688.15.camel@devil> User-Agent: Mutt/1.3.28i X-archive-position: 1515 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wichert@wiggy.net Precedence: bulk X-list: netdev Previously Mika Liljeberg wrote: > Looking at your trace it seems that the receiving machine is dropping > all packets that do not have traffic class set. Note that all segments > received with [class 0x2] get properly acked. The others probably don't > get to TCP at all. You might want to check your filters and QoS > policies. I don't have any filters and QoS support isn't even enabled in this kernel. Wichert. -- Wichert Akkerman http://www.wiggy.net/ A random hacker From davidsen@tmr.com Thu Jan 9 14:46:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Jan 2003 14:46:59 -0800 (PST) Received: from gatekeeper.tmr.com (tmr-02.dsl.thebiz.net [216.238.38.204]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h09Mkr3v027581 for ; Thu, 9 Jan 2003 14:46:54 -0800 Received: from localhost (davidsen@localhost) by gatekeeper.tmr.com (8.9.0/8.9.0) with SMTP id RAA30442; Thu, 9 Jan 2003 17:50:08 -0500 Date: Thu, 9 Jan 2003 17:50:07 -0500 (EST) From: Bill Davidsen To: Andrew McGregor cc: Fabio Massimo Di Nitto , Wichert Akkerman , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: ipv6 stack seems to forget to send ACKs In-Reply-To: <78180000.1042055993@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1516 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davidsen@tmr.com Precedence: bulk X-list: netdev On Thu, 9 Jan 2003, Andrew McGregor wrote: > Probably on the server's side it got an ICMP Host Unreachable or two as > some router updated its tables, and decided to close the connection. The > FIN jumped the queue in one/several of the routers in the path, so it got > reordered relative to the data. This would imply that the router in > question had its route to you back by the time the FIN got there. > > Wierd, but far from impossible. Nothing is impossible with routers, including sending ICMP packets using different routing than TCP (and doing odd things with UDP as well). Sometimes ICMP will be sent over a low bandwidth link with hopefully less latency. The phrase "the less traveled way" comes to mind. -- bill davidsen CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. From andrew@indranet.co.nz Thu Jan 9 17:12:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Jan 2003 17:12:34 -0800 (PST) Received: from mail.acheron.indranet.co.nz (ns.indranet.co.nz [210.54.239.210]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0A1CN3v030512 for ; Thu, 9 Jan 2003 17:12:24 -0800 Received: from localhost.localdomain (enso.acheron.indranet.co.nz [192.168.1.1]) by mail.acheron.indranet.co.nz (8.11.2/8.11.2) with ESMTP id h0A1HmQ04817; Fri, 10 Jan 2003 14:17:49 +1300 Date: Fri, 10 Jan 2003 14:17:52 +1300 From: Andrew McGregor To: Wichert Akkerman , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: ipv6 stack seems to forget to send ACKs Message-ID: <1291230000.1042161472@localhost.localdomain> In-Reply-To: <20030109155214.GX22951@wiggy.net> References: <20030108130850.GQ22951@wiggy.net> <20030109123857.A15625@bitwizard.nl> <20030109155214.GX22951@wiggy.net> X-Mailer: Mulberry/3.0.0b10 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 1517 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andrew@indranet.co.nz Precedence: bulk X-list: netdev --On Thursday, January 09, 2003 16:52:14 +0100 Wichert Akkerman wrote: > Previously Rogier Wolff wrote: >> Can you check the stats counters, to see if they are indeed dropped? > > It seems no packets are dropped: > ... > Tcp: > 666 active connections openings > 0 passive connection openings > 0 failed connection attempts > 0 connection resets received > 2 connections established > 58949 segments received > 65043 segments send out > 0 segments retransmited > 18 bad segments received. Is this it? My counters show zero, in vastly more packets. Andrew From yan@intruvert.com Thu Jan 9 17:44:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Jan 2003 17:44:09 -0800 (PST) Received: from ivexs1.intruvert.com (mx2.intruvert.com [65.209.235.21]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0A1i53v030997 for ; Thu, 9 Jan 2003 17:44:06 -0800 Received: by ivexs1.intruvert.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 17:49:48 -0800 Message-ID: From: Yan-Fa Li To: netdev@oss.sgi.com Subject: FYI: Etherleak Date: Thu, 9 Jan 2003 17:49:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 258 X-archive-position: 1518 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yan@intruvert.com Precedence: bulk X-list: netdev An interesting report into frame-padding information leakage violations in ethernet drivers. The authors use linux drivers in their examples. http://www.atstake.com/research/advisories/2003/atstake_etherleak_report.pdf [[HTML alternate version deleted]] From garzik@gtf.org Thu Jan 9 18:02:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Jan 2003 18:02:29 -0800 (PST) Received: from havoc.gtf.org (havoc.daloft.com [64.213.145.173]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0A22Q3v031565 for ; Thu, 9 Jan 2003 18:02:26 -0800 Received: by havoc.gtf.org (Postfix, from userid 500) id 31A9C6641; Thu, 9 Jan 2003 21:08:08 -0500 (EST) Date: Thu, 9 Jan 2003 21:08:08 -0500 From: Jeff Garzik To: Yan-Fa Li Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: FYI: Etherleak Message-ID: <20030110020808.GA18605@gtf.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-archive-position: 1519 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev On Thu, Jan 09, 2003 at 05:49:47PM -0800, Yan-Fa Li wrote: > An interesting report into frame-padding information leakage violations in > ethernet drivers. The authors use linux drivers in their examples. > > http://www.atstake.com/research/advisories/2003/atstake_etherleak_report.pdf Yes. All of those drivers are for ancient and/or obscure hardware except three: rtl8139, epic100, and via-rhine. There are fixes for those (and others) in testing right now, in fact :) From ak@suse.de Thu Jan 9 18:07:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Jan 2003 18:07:02 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0A26x3v031974 for ; Thu, 9 Jan 2003 18:07:00 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 6DF3014E2F; Fri, 10 Jan 2003 03:12:41 +0100 (MET) Date: Fri, 10 Jan 2003 03:12:41 +0100 From: Andi Kleen To: Yan-Fa Li , netdev@oss.sgi.com Subject: Re: FYI: Etherleak Message-ID: <20030110021241.GA32653@wotan.suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-archive-position: 1520 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Thu, Jan 09, 2003 at 05:49:47PM -0800, Yan-Fa Li wrote: > An interesting report into frame-padding information leakage violations in > ethernet drivers. The authors use linux drivers in their examples. > > http://www.atstake.com/research/advisories/2003/atstake_etherleak_report.pdf It's an old bug, it was discussed years ago on l-k. Unfortunately the drivers weren't fixed at that time. -Andi From yan@intruvert.com Thu Jan 9 18:08:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Jan 2003 18:08:54 -0800 (PST) Received: from ivexs1.intruvert.com (mx2.intruvert.com [65.209.235.21]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0A28m3v032319 for ; Thu, 9 Jan 2003 18:08:48 -0800 Received: by ivexs1.intruvert.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 18:14:31 -0800 Message-ID: From: Yan-Fa Li To: "'Andi Kleen'" , Yan-Fa Li , netdev@oss.sgi.com Subject: RE: FYI: Etherleak Date: Thu, 9 Jan 2003 18:14:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 760 X-archive-position: 1521 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yan@intruvert.com Precedence: bulk X-list: netdev thought I'd seen it before. Looks like a way for someone to generate some consulting fees... > -----Original Message----- > From: Andi Kleen [mailto:ak@suse.de] > Sent: Thursday, January 09, 2003 6:13 PM > To: Yan-Fa Li; netdev@oss.sgi.com > Subject: Re: FYI: Etherleak > > > On Thu, Jan 09, 2003 at 05:49:47PM -0800, Yan-Fa Li wrote: > > An interesting report into frame-padding information leakage > > violations in ethernet drivers. The authors use linux drivers in > > their examples. > > > > > http://www.atstake.com/research/advisories/200> 3/atstake_etherleak_repo > > rt.pdf > > It's an old bug, it was discussed years ago on l-k. > > Unfortunately the drivers weren't fixed at that time. > > -Andi > [[HTML alternate version deleted]] From rui.sousa@laposte.net Fri Jan 10 06:28:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Jan 2003 06:28:55 -0800 (PST) Received: from sophia-sousar2.nice.mindspeed.com (cnxt10002.conexant.com [198.62.10.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0AESk3v009959 for ; Fri, 10 Jan 2003 06:28:47 -0800 Received: from localhost (rsousa@localhost) by sophia-sousar2.nice.mindspeed.com (8.11.6/8.11.6) with ESMTP id h0AEYTW08582; Fri, 10 Jan 2003 15:34:30 +0100 X-Authentication-Warning: sophia-sousar2.nice.mindspeed.com: rsousa owned process doing -bs Date: Fri, 10 Jan 2003 15:34:29 +0100 (CET) From: Rui Sousa X-X-Sender: rsousa@sophia-sousar2.nice.mindspeed.com To: Joshua Stewart cc: Linux Kernel Mailing List , Linux network development Subject: Re: Pushing a stray sk_buff to the NIC In-Reply-To: <1042161058.6107.18.camel@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1522 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rui.sousa@laposte.net Precedence: bulk X-list: netdev On Thu, 9 Jan 2003, Joshua Stewart wrote: Hi, > I'm trying to take "hand-built" sk_buffs with little more than some data > and a dev member and push them to the NIC for transmission. I would > like to simply give them to dev_queue_xmit. Does anybody know what > state I should have them in before handing them to dev_queue_xmit? In a driver I wrote I setup (for a newly allocated skb and a 2.4 kernel): some_header = (struct some_header *) skb_push(skb, sizeof(struct some_header)); skb->nh.raw = (unsigned char *) some_header; this_eth_hdr = (struct ethhdr *) skb_push(skb, ETH_HLEN); this_eth_hdr->h_proto = __constant_htons(ETH_P_SOME_HEADER); memcpy(this_eth_hdr->h_source, dev->dev_addr, ETH_ALEN); skb->dev = dev; skb->protocol = __constant_htons(ETH_P_CSM_ENCAPS); dev_queue_xmit(skb); where some_header for you is probably an IP header and dev is the "struct net_device" of the device you are using to send the packet out on the wire. > Should skb->data point to the start of a MAC header or an IP header? MAC > Also, given an IP address in skb->nh.iph->daddr, what's the easiest way > to get the appropriate MAC address? First you need to get the device, then the MAC address is easy. This should be what normal IP routing code does... > J > > Rui > - > 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 paulj@alphyra.ie Fri Jan 10 12:54:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Jan 2003 12:54:17 -0800 (PST) Received: from dunlop.admin.ie.alphyra.com (s0.alphyra.bbnplanet.net [195.16.170.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0AKs53v021112 for ; Fri, 10 Jan 2003 12:54:06 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by dunlop.admin.ie.alphyra.com (8.12.5/8.12.5) with ESMTP id h0AKxMZS016592; Fri, 10 Jan 2003 20:59:23 GMT Date: Fri, 10 Jan 2003 20:59:22 +0000 (GMT) From: Paul Jakma X-X-Sender: paulj@dunlop.admin.ie.alphyra.com To: Fabio Massimo Di Nitto cc: Wichert Akkerman , Andrew McGregor , , Subject: Re: ipv6 stack seems to forget to send ACKs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1523 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: paulj@alphyra.ie Precedence: bulk X-list: netdev On Thu, 9 Jan 2003, Fabio Massimo Di Nitto wrote: > hmmmm strange because now I have forced the route to ipv6.lkml.org > via another ISP (bypassing xs26.net) xs26.net posted to the 6bone list not so long that ago that they have IPv6 routing stability problems. (they're ditching OSPFv3/ospfd and implementing an inhouse IPv6 link-state IGP instead apparently). > Fabio regards, -- Paul Jakma Sys Admin Alphyra paulj@alphyra.ie Warning: /never/ send email to spam@dishone.st or trap@dishone.st From garzik@gtf.org Sat Jan 11 14:02:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 11 Jan 2003 14:02:44 -0800 (PST) Received: from havoc.gtf.org (havoc.daloft.com [64.213.145.173]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0BM2a3v015072 for ; Sat, 11 Jan 2003 14:02:37 -0800 Received: by havoc.gtf.org (Postfix, from userid 500) id BCC4B664F; Sat, 11 Jan 2003 17:08:26 -0500 (EST) Date: Sat, 11 Jan 2003 17:08:26 -0500 From: Jeff Garzik To: netdev@oss.sgi.com, linux-net@vger.kernel.org Cc: davem@redhat.com Subject: NAPI vs. interrupts Message-ID: <20030111220826.GA10085@gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 1524 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev I am seeing some tg3 reports occasionally that show a fair number of interrupts-per-second, even though tg3 is 100% NAPI. It seems to me that as machines get faster, and amount of memory increase [xlat: less waiting for free RAM in all parts of the kernel, and less GFP_ATOMIC alloc failures], the likelihood that a NAPI driver can process 100% of the RX and TX work without having to reqquest subsequent iterations of dev->poll(). NAPI's benefits kick in when there is some amount of system load. However if the box is fast enough to eliminate cases where system load would otherwise exist (interrupt and packet processing overhead), the NAPI "worst case" kicks in, where a NAPI driver _always_ does ack some irqs mask irqs ack some more irqs process events unmask irqs whereas a non-NAPI driver _always_ does ack irqs process events When there is load, the obvious NAPI benefits kick in. However, on super-fast servers, SMP boxes, etc. it seems likely to me that one can receive well in excess of 1,000 interrupts per second, simply because the box is so fast it can run thousands of iterations of the NAPI "worst case", above. The purpose of this email is to solicit suggestions to develop a strategy to fix what I believe is a problem with NAPI. Here are some comments of mine: 1) Can this problem be alleviated entirely without driver changes? For example, would it be reasonable to do pkts-per-second sampling in the net core, and enable software mitigation based on that? 2) Implement hardware mitigation in addition to NAPI. Either the driver does adaptive sampling, or simply hard-locks mitigation settings at something that averages out to N pkts per second. 3) Implement an alternate driver path that follows the classical, non-NAPI interrupt handling path in addition to NAPI, by logic similar to this[warning: off the cuff and not analyzed... i.e. just an idea]: ack irqs call dev->poll() from irq handler [processes events until budget runs out, or available events are all processed] if budget ran out, mask irqs netif_rx_schedule() [this, #3, does not address the irq-per-sec problem directly, but does lessen the effect of "worst case"] Anyway, for tg3 specifically, I am leaning towards the latter part of #2, hard-locking mitigation settings at something tests prove is "reasonable", and in heavy load situations NAPI will kick in as expected, and perform its magic ;-) Comments/feedback requested. Jeff From garzik@gtf.org Sat Jan 11 16:51:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 11 Jan 2003 16:51:51 -0800 (PST) Received: from havoc.gtf.org (havoc.daloft.com [64.213.145.173]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0C0pa3v016556 for ; Sat, 11 Jan 2003 16:51:37 -0800 Received: by havoc.gtf.org (Postfix, from userid 500) id 941016651; Sat, 11 Jan 2003 19:57:27 -0500 (EST) Date: Sat, 11 Jan 2003 19:57:27 -0500 From: Jeff Garzik To: Jean-Daniel Pauget Cc: lkml , netdev@oss.sgi.com, davem@redhat.com Subject: [PATCH] Re: Another holiday, another set of tg3 releases. Message-ID: <20030112005727.GB17545@gtf.org> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-archive-position: 1525 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Jan 12, 2003 at 01:14:03AM +0100, Jean-Daniel Pauget wrote: > > on 2002-12-30, Jeff Garzik wrote : > > > Another holiday, another set of tg3 releases. > > in my seek for unexpected freeze of my box (not yet figured which > hardware is involved exactly) I updated to tg3-1.2a and applied > both tg3-1.2a-00_irqsave and tg3-1.2a-01_mask_rewrite. > as a result, after working a few seconds the network card freezes, and > no ifupdown would permit any recovery. > > on the other hand, with only the first patch tg3-1.2a-00_irqsave, things > seems ok and I'm waiting for my machine to freeze... ...or not. (the freeze > frequency is ~10hours )... Thanks, please do keep us posted. I have attached two patches, with accompanying descriptions, that I have been testing locally on UP and SMP. They are a bit more conservative than tg3-1.2a-01_mask_rewrite while still addressing the same issue. Right now my plan for tg3 version 1.3 (next release) is: tg3-1.2a-00_irqsave tg3-irq-mask-2.patch (attached), and tg3-irq-flush.patch (attached) and maybe the MTU stuff [more on that below] The first patch, 00_irqsave, is a bit too paranoid for DaveM's liking, so even though I will to apply 00_irqsave, that area will get further attention once existing bug reports are resolved. [Note to DaveM -- tg3_timer is not a fast path, so extra paranoia there won't hurt] > though, on your page you mention a fifth patch concerning mtu, as I'm > running with an unusual mtu of 1452 because of internet over internet > encapsulation on my DSL, maybe I'm concerned ? MTU of 1452 should not be a problem. The issue is more of correcting handling of change-MTU condition that rarely happens. Jeff --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tg3-irq-mask-2.patch" # -------------------------------------------- # 03/01/05 jgarzik@redhat.com 1.926.1.2 # [netdrvr tg3] Better interrupt masking # # The bcm570x chips provide a register that disables (masks) or enables # interrupts, and as a side effect, each write to this register regardless # of value clears various PCI and internal interrupt-pending flags. This # register, intr-mbox-0, provides a superset of the function provided # by the mask-pci-int and clear-pci-int bits in the misc-host-ctrl register. # # Furthermore, the documentation clearly implies use of this register, # as an indicator that the host [tg3 driver] is in its interrupt handler. # # The new tg3 logic, taking this knowledge into account, masks-and-clears # irqs using intr-mbox-0 [only] when a hard irq is received, and # unmasks-and-clears irqs at the end of tg3_poll after all NAPI events # have been exhausted. # # The old logic twiddled the misc-host-ctrl irq masking bits separately # from intr-mbox-0 bits, which was not only inconsistent but also # a few additional I/Os that were not needed. # -------------------------------------------- # diff -Nru a/drivers/net/tg3.c b/drivers/net/tg3.c --- a/drivers/net/tg3.c Sat Jan 11 19:42:56 2003 +++ b/drivers/net/tg3.c Sat Jan 11 19:42:56 2003 @@ -217,22 +217,6 @@ tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW); } -static inline void tg3_mask_ints(struct tg3 *tp) -{ - tw32(TG3PCI_MISC_HOST_CTRL, - (tp->misc_host_ctrl | MISC_HOST_CTRL_MASK_PCI_INT)); -} - -static inline void tg3_unmask_ints(struct tg3 *tp) -{ - tw32(TG3PCI_MISC_HOST_CTRL, - (tp->misc_host_ctrl & ~MISC_HOST_CTRL_MASK_PCI_INT)); - if (tp->hw_status->status & SD_STATUS_UPDATED) { - tw32(GRC_LOCAL_CTRL, - tp->grc_local_ctrl | GRC_LCLCTRL_SETINT); - } -} - static void tg3_switch_clocks(struct tg3 *tp) { if (tr32(TG3PCI_CLOCK_CTRL) & CLOCK_CTRL_44MHZ_CORE) { @@ -2052,7 +2036,7 @@ if (done) { netif_rx_complete(netdev); - tg3_unmask_ints(tp); + tg3_enable_ints(tp); } spin_unlock_irq(&tp->lock); @@ -2060,10 +2044,10 @@ return (done ? 0 : 1); } -static __inline__ void tg3_interrupt_main_work(struct net_device *dev, struct tg3 *tp) +static inline unsigned int tg3_has_work(struct net_device *dev, struct tg3 *tp) { struct tg3_hw_status *sblk = tp->hw_status; - int work_exists = 0; + unsigned int work_exists = 0; if (!(tp->tg3_flags & (TG3_FLAG_USE_LINKCHG_REG | @@ -2075,19 +2059,7 @@ sblk->idx[0].rx_producer != tp->rx_rcb_ptr) work_exists = 1; - if (!work_exists) - return; - - if (netif_rx_schedule_prep(dev)) { - /* NOTE: These writes are posted by the readback of - * the mailbox register done by our caller. - */ - tg3_mask_ints(tp); - __netif_rx_schedule(dev); - } else { - printk(KERN_ERR PFX "%s: Error, poll already scheduled\n", - dev->name); - } + return work_exists; } static void tg3_interrupt(int irq, void *dev_id, struct pt_regs *regs) @@ -2102,13 +2074,16 @@ if (sblk->status & SD_STATUS_UPDATED) { tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0x00000001); + tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW); sblk->status &= ~SD_STATUS_UPDATED; - tg3_interrupt_main_work(dev, tp); - - tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, - 0x00000000); - tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW); + if (likely(tg3_has_work(dev, tp))) + netif_rx_schedule(dev); + else { + tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, + 0x00000000); + tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW); + } } spin_unlock_irqrestore(&tp->lock, flags); --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tg3-irq-flush.patch" # -------------------------------------------- # 03/01/05 jgarzik@redhat.com 1.926.1.3 # [netdrvr tg3] flush irq-mask reg write before checking hw status block, # in tg3_enable_ints. # -------------------------------------------- # diff -Nru a/drivers/net/tg3.c b/drivers/net/tg3.c --- a/drivers/net/tg3.c Sat Jan 11 19:43:21 2003 +++ b/drivers/net/tg3.c Sat Jan 11 19:43:21 2003 @@ -209,12 +209,11 @@ tw32(TG3PCI_MISC_HOST_CTRL, (tp->misc_host_ctrl & ~MISC_HOST_CTRL_MASK_PCI_INT)); tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0x00000000); + tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW); - if (tp->hw_status->status & SD_STATUS_UPDATED) { + if (tp->hw_status->status & SD_STATUS_UPDATED) tw32(GRC_LOCAL_CTRL, tp->grc_local_ctrl | GRC_LCLCTRL_SETINT); - } - tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW); } static void tg3_switch_clocks(struct tg3 *tp) --yrj/dFKFPuw6o+aM-- From hadi@cyberus.ca Sat Jan 11 19:35:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 11 Jan 2003 19:35:55 -0800 (PST) Received: from mx01.cyberus.ca (mx01.cyberus.ca [216.191.240.22]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0C3Ze3v018337 for ; Sat, 11 Jan 2003 19:35:41 -0800 Received: from shell.cyberus.ca ([216.191.240.114]) by mx01.cyberus.ca with esmtp (Exim 4.10) id 18XZ0C-000F2a-00; Sat, 11 Jan 2003 22:41:36 -0500 Received: from shell.cyberus.ca (localhost.cyberus.ca [127.0.0.1]) by shell.cyberus.ca (8.12.6/8.12.6) with ESMTP id h0C3fXYO011010; Sat, 11 Jan 2003 22:41:33 -0500 (EST) (envelope-from hadi@cyberus.ca) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.12.6/8.12.6/Submit) with ESMTP id h0C3fWQx011007; Sat, 11 Jan 2003 22:41:33 -0500 (EST) (envelope-from hadi@cyberus.ca) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sat, 11 Jan 2003 22:41:32 -0500 (EST) From: jamal To: Jeff Garzik cc: netdev@oss.sgi.com, "" , "" Subject: Re: NAPI vs. interrupts In-Reply-To: <20030111220826.GA10085@gtf.org> Message-ID: <20030111220310.Y9973@shell.cyberus.ca> References: <20030111220826.GA10085@gtf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1526 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sat, 11 Jan 2003, Jeff Garzik wrote: > I am seeing some tg3 reports occasionally that show a fair number of > interrupts-per-second, even though tg3 is 100% NAPI. > sample data? > It seems to me that as machines get faster, and amount of memory > increase [xlat: less waiting for free RAM in all parts of the kernel, > and less GFP_ATOMIC alloc failures], the likelihood that a NAPI driver > can process 100% of the RX and TX work without having to reqquest > subsequent iterations of dev->poll(). > This is very interesting - I havent come across such a CPU myself. I am just about to unleash a P4 machine (> 2Ghz) so i may see this. > NAPI's benefits kick in when there is some amount of system load. > However if the box is fast enough to eliminate cases where system load > would otherwise exist (interrupt and packet processing overhead), the > NAPI "worst case" kicks in, where a NAPI driver _always_ does > ack some irqs > mask irqs > ack some more irqs > process events > unmask irqs > > whereas a non-NAPI driver _always_ does > ack irqs > process events > I think you may have added one more transaction on NAPI, but thats beside the point. Yes, this is what would happen in the worst case on NAPI. When Manfred first posted his results i was one of the doubting people as to the effect of these extra IOs. Recently i got my hands on a pentium (lucky me!) and i was able to see up to 8% increase on CPU with NAPI vs non-NAPI under conditions of what i would consider typically to be low traffic input (anywhere between 5-8000 packets coming into the system). To describe the problem better, anywhere where the CPU can process the full rate (example the 5000 packets/sec arrivals on the pentium above) the system becomes penalized by the extra IO. Note in the above pentium system, the effect of IO became lower when i switched to MMIO based PCI transactions. Of course when going got tough on the pentium it died without NAPI. > When there is load, the obvious NAPI benefits kick in. However, on > super-fast servers, SMP boxes, etc. it seems likely to me that one can > receive well in excess of 1,000 interrupts per second, simply because > the box is so fast it can run thousands of iterations of the NAPI "worst > case", above. > True but you are better off with NAPI than without it in fast machines. [I dont think youll notice much of CPU cycles disappearing on P3 for example] It's the slow machines that are a problem - and there you make the sacrifice on small loads where you spend the unnecessary CPU but benefit when you go under stress. Lets take a worst case doomsday scenario: Giges max rate: 1.4Mpps; take only 30% of that and you are talking rx interupts at around 500K/sec. Say you have two giges NICs, thats 1M receive interupts/sec. Is there a commodity type h/ware which can handle this? Robert and i have been discussing this very issue for our presentation at nordu/usenix coming up and his arguement is: who gives a shit if you loose some CPU cycles at low rates? He has a point, of course; I have been experimenting with some things which will kick into NAPI at high rates and maintain old scheme but what i can say at this point is that they are experimental and that some of the benefits of NAPI disapear as a result. For the scheme to work, all the NAPI benefits have to be maintained and it has to be very unintrusive. > The purpose of this email is to solicit suggestions to develop a > strategy to fix what I believe is a problem with NAPI. > > Here are some comments of mine: > > 1) Can this problem be alleviated entirely without driver changes? For > example, would it be reasonable to do pkts-per-second sampling in the > net core, and enable software mitigation based on that? > > 2) Implement hardware mitigation in addition to NAPI. Either the driver > does adaptive sampling, or simply hard-locks mitigation settings at > something that averages out to N pkts per second. > > 3) Implement an alternate driver path that follows the classical, > non-NAPI interrupt handling path in addition to NAPI, by logic similar > to this[warning: off the cuff and not analyzed... i.e. just an idea]: > > ack irqs > call dev->poll() from irq handler > [processes events until budget runs out, > or available events are all processed] > if budget ran out, > mask irqs > netif_rx_schedule() > > [this, #3, does not address the irq-per-sec problem directly, but does > lessen the effect of "worst case"] > > Anyway, for tg3 specifically, I am leaning towards the latter part of #2, > hard-locking mitigation settings at something tests prove is > "reasonable", and in heavy load situations NAPI will kick in as > expected, and perform its magic ;-) > Youll run into all sorts of problems with 1 and 3. Example in SMP. I think 2 is the best path for now. If we can collect data that shows this to be an issue we can accelerate getting a patch; i only work on it when i am bored. For now i agree with Roberts philosophy - if we can get the workaround for free while maintaining NAPI benefits, great. The question is do we care about slow machines loosing some cycles? cheers, jamal From vda@port.imtp.ilyichevsk.odessa.ua Mon Jan 13 00:28:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Jan 2003 00:28:26 -0800 (PST) Received: from Port.imtp.ilyichevsk.odessa.ua (169.imtp.Ilyichevsk.Odessa.UA [195.66.192.169] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0D8S23v001578 for ; Mon, 13 Jan 2003 00:28:13 -0800 Received: from there ([172.16.42.177]) by Port.imtp.ilyichevsk.odessa.ua (8.10.2/8.10.2) with SMTP id h0D8Kis26772; Mon, 13 Jan 2003 10:21:24 +0200 Message-Id: <200301130821.h0D8Kis26772@Port.imtp.ilyichevsk.odessa.ua> Content-Type: text/plain; charset="koi8-r" From: Denis Vlasenko Reply-To: vda@port.imtp.ilyichevsk.odessa.ua To: Jean Tourrilhes , alan_mcreynolds@hpl.hp.com, jkaba@sarnoff.com, torgeir@trenger.ro Subject: 2.4.20-pre11: PCI Wavelan card loses connection Date: Mon, 13 Jan 2003 10:20:14 +0200 X-Mailer: KMail [version 1.3.2] Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-archive-position: 1529 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vda@port.imtp.ilyichevsk.odessa.ua Precedence: bulk X-list: netdev Content-Length: 15242 Lines: 357 I bought a PCI wireless card, a DLink-520 (I think, I forgot exactly (it's at home), anyway, lspci dump is below). We (my father and me) made a fairly long helical aerial. We are trying to communicate over ~15 km with a small wireless cell. (~10 hosts, one AP). We can successfully associate with it, signal is weak as expected. But after a short while our eth0 seems to 'fall off the net' and while it looks like we can send packets, we see no incoming data at all. Since I have almost zero wireless experience, I'll be happy if someone with said experience can read further and say what bites us. Typical bcast ping: =================== PING 10.206.173.127 (10.206.173.127): 56 octets data 64 octets from 10.206.173.111: icmp_seq=0 ttl=64 time=0.4 ms 64 octets from 10.206.173.4: icmp_seq=0 ttl=64 time=13.8 ms (DUP!) 64 octets from 10.206.173.6: icmp_seq=0 ttl=255 time=27.2 ms (DUP!) 64 octets from 10.206.173.5: icmp_seq=0 ttl=255 time=50.0 ms (DUP!) 64 octets from 10.206.173.111: icmp_seq=1 ttl=64 time=0.3 ms 64 octets from 10.206.173.4: icmp_seq=1 ttl=64 time=5.5 ms (DUP!) 64 octets from 10.206.173.6: icmp_seq=1 ttl=255 time=20.3 ms (DUP!) 64 octets from 10.206.173.5: icmp_seq=1 ttl=255 time=59.8 ms (DUP!) 64 octets from 10.206.173.3: icmp_seq=1 ttl=64 time=99.5 ms (DUP!) 64 octets from 10.206.173.111: icmp_seq=2 ttl=64 time=0.3 ms 64 octets from 10.206.173.111: icmp_seq=3 ttl=64 time=0.4 ms 64 octets from 10.206.173.111: icmp_seq=4 ttl=64 time=0.3 ms 64 octets from 10.206.173.111: icmp_seq=5 ttl=64 time=0.3 ms 64 octets from 10.206.173.111: icmp_seq=6 ttl=64 time=0.3 ms 64 octets from 10.206.173.111: icmp_seq=7 ttl=64 time=0.3 ms 64 octets from 10.206.173.111: icmp_seq=8 ttl=64 time=0.3 ms 64 octets from 10.206.173.111: icmp_seq=9 ttl=64 time=0.3 ms 64 octets from 10.206.173.111: icmp_seq=10 ttl=64 time=0.3 ms 64 octets from 10.206.173.111: icmp_seq=11 ttl=64 time=0.3 ms 64 octets from 10.206.173.111: icmp_seq=12 ttl=64 time=0.3 ms 64 octets from 10.206.173.111: icmp_seq=13 ttl=64 time=0.3 ms 64 octets from 10.206.173.111: icmp_seq=14 ttl=64 time=0.3 ms 64 octets from 10.206.173.4: icmp_seq=14 ttl=64 time=4.1 ms (DUP!) 64 octets from 10.206.173.6: icmp_seq=14 ttl=255 time=19.3 ms (DUP!) 64 octets from 10.206.173.3: icmp_seq=14 ttl=64 time=73.9 ms (DUP!) 64 octets from 10.206.173.5: icmp_seq=14 ttl=255 time=153.1 ms (DUP!) 64 octets from 10.206.173.111: icmp_seq=15 ttl=64 time=0.3 ms 64 octets from 10.206.173.4: icmp_seq=15 ttl=64 time=4.7 ms (DUP!) 64 octets from 10.206.173.6: icmp_seq=15 ttl=255 time=24.1 ms (DUP!) 64 octets from 10.206.173.3: icmp_seq=15 ttl=64 time=107.8 ms (DUP!) 64 octets from 10.206.173.5: icmp_seq=15 ttl=255 time=149.9 ms (DUP!) 64 octets from 10.206.173.111: icmp_seq=16 ttl=64 time=0.3 ms 64 octets from 10.206.173.4: icmp_seq=16 ttl=64 time=4.1 ms (DUP!) 64 octets from 10.206.173.6: icmp_seq=16 ttl=255 time=22.4 ms (DUP!) 64 octets from 10.206.173.3: icmp_seq=16 ttl=64 time=91.6 ms (DUP!) 64 octets from 10.206.173.5: icmp_seq=16 ttl=255 time=143.1 ms (DUP!) 64 octets from 10.206.173.111: icmp_seq=17 ttl=64 time=0.3 ms 64 octets from 10.206.173.111: icmp_seq=18 ttl=64 time=0.3 ms 64 octets from 10.206.173.111: icmp_seq=19 ttl=64 time=0.3 ms 64 octets from 10.206.173.111: icmp_seq=20 ttl=64 time=0.3 ms 64 octets from 10.206.173.111: icmp_seq=21 ttl=64 time=0.3 ms ....no more replies ever except .111 (i.e. us).... As you see, replies come irregularly. Maybe it is due to big distance and weak signal. But soon icmp replies stop coming at all, no matter how long I ping. Either Tx or Rx does not really happen I think :( I tried to reset (ifconfig down/up) the card every 10 mins and pinging and tcpdumping overnight (automated ;). It helps but not for long. The longest period of replies coming is less than 2 minutes. Usually card 'falls off the net' much sooner (~30 seconds). Looking at syslog I think sometimes card timeouts at Tx and gets reset by network code. Then the cycle repeats. It works for some 30 seconds on average, then go deaf. Here are all kinds of more-or-less relevant information: syslog at modprobe orinoco_pci ============================== kernel: hermes.c: 5 Apr 2002 David Gibson kernel: orinoco.c 0.11b (David Gibson and others) kernel: PCI: Found IRQ 11 for device 00:0f.0 kernel: PCI: Sharing IRQ 11 with 00:07.5 kernel: Detected Orinoco/Prism2 PCI device at 00:0f.0, mem:0xD8000000 to 0xD8000FFF -> 0xd0c66000, irq:11 kernel: Reset done.................................... .................................................. .................................................. .................................................. .................................................. ...........; kernel: Clear Reset................................... .................................................. .................................................. .................................................. .................................................. .................................................. .................................................. .................................................. .................................................. .................................................. .................; kernel: pci_cor : reg = 0x0 - DD5 - DA3 kernel: eth0: Station identity 001f:0006:0001:0003 kernel: eth0: Looks like an Intersil firmware version 1.03 kernel: eth0: Ad-hoc demo mode supported kernel: eth0: IEEE standard IBSS ad-hoc mode supported kernel: eth0: WEP supported, 104-bit key kernel: eth0: MAC address 00:05:5D:FA:1A:DA kernel: eth0: Station name "Prism I" kernel: eth0: ready syslog while I play with ping and iwconfig ========================================== kernel: eth0: Channel out of range (0)! *** LOTS of these. Is this normal? kernel: eth0: Channel out of range (0)! kernel: eth0: Error -110 writing Tx descriptor to BAP *** (110 == ETIMEDOUT) Why? Do I have to worry? last message repeated 5 times kernel: eth0: Channel out of range (0)! kernel: eth0: Channel out of range (0)! last message repeated 3 times kernel: eth0: Channel out of range (0)! kernel: eth0: Channel out of range (0)! kernel: eth0: Channel out of range (0)! kernel: eth0: Channel out of range (0)! kernel: eth0: Error -110 writing Tx descriptor to BAP last message repeated 6 times kernel: eth0: Error -110 writing Tx descriptor to BAP kernel: eth0: Error -110 writing Tx descriptor to BAP kernel: eth0: Error -110 writing Tx descriptor to BAP kernel: eth0: Channel out of range (0)! kernel: eth0: Error -110 writing Tx descriptor to BAP last message repeated 9 times last message repeated 2 times kernel: eth0: Channel out of range (0)! kernel: eth0: Error -110 writing Tx descriptor to BAP last message repeated 8 times last message repeated 5 times kernel: eth0: Error -110 writing Tx descriptor to BAP kernel: eth0: Error -110 writing Tx descriptor to BAP last message repeated 7 times kernel: eth0: Channel out of range (0)! last message repeated 16 times last message repeated 30 times last message repeated 30 times kernel: eth0: Channel out of range (0)! last message repeated 2 times kernel: eth0: Channel out of range (0)! last message repeated 15 times *** _TONS_ of 'eth0: Channel out of range (0)!' snipped *** kernel: eth0: Channel out of range (0)! last message repeated 8 times kernel: eth0: Channel out of range (0)! last message repeated 16 times last message repeated 31 times last message repeated 30 times kernel: eth0: error -5 reading info frame. Frame dropped. *** (5 == EIO) This is probably a mangled packet. okay... kernel: eth0: Channel out of range (0)! kernel: eth0: Error -110 writing Tx descriptor to BAP last message repeated 17 times last message repeated 4 times last message repeated 2 times kernel: NETDEV WATCHDOG: eth0: transmit timed out kernel: eth0: Tx timeout! Resetting card. ALLOCFID=ffff, TXCOMPLFID=ffff, EVSTAT=8000 *** What do these numbers mean? kernel: eth0: Channel out of range (0)! last message repeated 2 times -- MARK -- -- MARK -- kernel: eth0: Channel out of range (0)! last message repeated 2 times kernel: eth0: Error -110 writing Tx descriptor to BAP last message repeated 13 times last message repeated 6 times ifconfig: ========= eth0 Link encap:Ethernet HWaddr 00:05:5D:FA:1A:DA inet addr:10.206.173.111 Bcast:10.206.173.127 Mask:255.255.255.128 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:789 errors:565 dropped:0 overruns:0 frame:436 TX packets:1140 errors:2397 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:72416 (70.7 Kb) TX bytes:640704 (625.6 Kb) Interrupt:11 Base address:0x6000 Memory:d8000000-d8000fff iwconfig after reset (ifconfig eth0 down/up cycle): =================================================== eth0 IEEE 802.11-DS ESSID:"AirNet" Nickname:"Prism I" Mode:Managed Frequency:2.462GHz Access Point: 00:10:E7:F5:82:CC Bit Rate:2Mb/s Tx-Power=15 dBm Sensitivity:1/3 Retry min limit:8 RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality:10/92 Signal level:-89 dBm Noise level:-134 dBm ^^^^^ ^^^^^^^ ^^^^^^^^ Rx invalid nwid:0 Rx invalid crypt:129 Rx invalid frag:0 Tx excessive retries:6 Invalid misc:0 Missed beacon:0 iwconfig when card 'falls off the net': ======================================= eth0 IEEE 802.11-DS ESSID:"AirNet" Nickname:"Prism I" Mode:Managed Frequency:2.427GHz Access Point: 00:10:E7:F5:82:CC Bit Rate:2Mb/s Tx-Power=15 dBm Sensitivity:1/3 Retry min limit:8 RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality:0/92 Signal level:107/153 Noise level:123/153 ^^^^ ^^^^^^^ ^^^^^^^ Rx invalid nwid:0 Rx invalid crypt:122 Rx invalid frag:0 Tx excessive retries:6 Invalid misc:0 Missed beacon:0 What makes me wonder: how come there is no signal *while I am pinging*? AP *has to* retranslate it to the peers, we have to see it too! Maybe there is *no* Tx happening on our side? lspci -vvvxxx: ============== 00:0f.0 Network controller: Harris Semiconductor: Unknown device 3873 (rev 01) Subsystem: D-Link System Inc: Unknown device 3501 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- hw; int err = 0; u16 channel; long freq = 0; orinoco_lock(priv); err = hermes_read_wordrec(hw, USER_BAP, HERMES_RID_CURRENTCHANNEL, &channel); if (err) goto out; if ( (channel < 1) || (channel > NUM_CHANNELS) ) { struct net_device *dev = priv->ndev; printk(KERN_WARNING "%s: Channel out of range (%d)!\n", dev->name, channel); err = -EBUSY; goto out; } freq = channel_frequency[channel-1] * 100000; out: orinoco_unlock(priv); if (err > 0) err = -EBUSY; return err ? err : freq; } ................... static int orinoco_xmit(struct sk_buff *skb, struct net_device *dev) { struct orinoco_private *priv = (struct orinoco_private *)dev->priv; struct net_device_stats *stats = &priv->stats; hermes_t *hw = &priv->hw; int err = 0; ....sanity checks here, we met them.... orinoco_lock(priv); /* Length of the packet body */ /* FIXME: what if the skb is smaller than this? */ len = max_t(int,skb->len - ETH_HLEN, ETH_ZLEN); eh = (struct ethhdr *)skb->data; memset(&desc, 0, sizeof(desc)); desc.tx_control = cpu_to_le16(HERMES_TXCTRL_TX_OK | HERMES_TXCTRL_TX_EX); err = hermes_bap_pwrite(hw, USER_BAP, &desc, sizeof(desc), txfid, 0); if (err) { printk(KERN_ERR "%s: Error %d writing Tx descriptor to BAP\n", dev->name, err); stats->tx_errors++; goto fail; } .................... static void orinoco_tx_timeout(struct net_device *dev) { struct orinoco_private *priv = (struct orinoco_private *)dev->priv; struct net_device_stats *stats = &priv->stats; struct hermes *hw = &priv->hw; int err = 0; printk(KERN_WARNING "%s: Tx timeout! Resetting card. ALLOCFID=%04x, TXCOMPLFID=%04x, EVSTAT=%04x\n", dev->name, hermes_read_regn(hw, ALLOCFID), hermes_read_regn(hw, TXCOMPLFID), hermes_read_regn(hw, EVSTAT)); stats->tx_errors++; .................... -- vda From Robert.Olsson@data.slu.se Mon Jan 13 07:42:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Jan 2003 07:43:07 -0800 (PST) Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0DFgv3v015012 for ; Mon, 13 Jan 2003 07:42:59 -0800 Received: (from robert@localhost) by robur.slu.se (8.9.3/8.9.3) id QAA14979; Mon, 13 Jan 2003 16:57:12 +0100 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15906.57816.361093.607705@robur.slu.se> Date: Mon, 13 Jan 2003 16:57:12 +0100 To: Jeff Garzik Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org, davem@redhat.com Subject: NAPI vs. interrupts In-Reply-To: <20030111220826.GA10085@gtf.org> References: <20030111220826.GA10085@gtf.org> X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 1530 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 3979 Lines: 108 Jeff Garzik writes: > It seems to me that as machines get faster, and amount of memory > increase [xlat: less waiting for free RAM in all parts of the kernel, > and less GFP_ATOMIC alloc failures], the likelihood that a NAPI driver > can process 100% of the RX and TX work without having to reqquest > subsequent iterations of dev->poll(). True. > NAPI's benefits kick in when there is some amount of system load. > However if the box is fast enough to eliminate cases where system load > would otherwise exist (interrupt and packet processing overhead), the > NAPI "worst case" kicks in, where a NAPI driver _always_ does > ack some irqs > mask irqs > ack some more irqs > process events > unmask irqs > Another "worst case" :-) NAPI subsequent iterations of dev->poll at softirq whereas a non-NAPI driver **always** does IRQ ack irqs process events So for this we pay the "insurance fee" of acking and disabling irq's to get dev->poll running. The acking we need non-NAPI as well to see if this irq is for us. And if case NAPI the ack at irq is passed to dev->poll. (Davem patch to e1000). So more or we less we have the cost of one PCI write + PCI sync if MMIO to disable irq's to enable processing at softirq. And another PCI-write to enable irq's. NAPI relays on the fact interrupts is the best way to indicate work and keep latency at an absolute minimum sparse traffic-levels and polling is unbeatable at high loads. And the packet processing at softirq gives good system behavior system manageable and even some hooks to control the balance between irq/softirq and user mode apps. > 1) Can this problem be alleviated entirely without driver changes? For > example, would it be reasonable to do pkts-per-second sampling in the > net core, and enable software mitigation based on that? We played with this some time ago... First I think we should say we need something from the particular device we are dealing with any general measures we risk doing really bad things... i.e adding latencies to wrong devices etc. We tried different forms of averages and EWMA (exponented weighted moving average) but nothing was fast enough to "follow" the burstiness of a device receiving packets. The only usable measure we found was the number of RX packets on the ring. This also has the "advantage" of being adjusted by the CPU load. You have it tulip. > 2) Implement hardware mitigation in addition to NAPI. Either the driver > does adaptive sampling, or simply hard-locks mitigation settings at > something that averages out to N pkts per second. Yes should be doable... But real question do we need it? I'm asking this question myself I was mentally disturbed the interrupts myself and I added mitigation to tulip. And even some other hacks in tulip delaying the exit to "done". Still I'm not sure... > 3) Implement an alternate driver path that follows the classical, > non-NAPI interrupt handling path in addition to NAPI, by logic similar > to this[warning: off the cuff and not analyzed... i.e. just an idea]: > > ack irqs > call dev->poll() from irq handler > [processes events until budget runs out, > or available events are all processed] Well you need some more steps. The central backlog is needed again and you need to schedule the RX softirq to process the backlog's packets. > if budget ran out, > mask irqs > netif_rx_schedule() > > [this, #3, does not address the irq-per-sec problem directly, but does > lessen the effect of "worst case"] No "top" performance would probably be somewhat be less due to irq's. > Anyway, for tg3 specifically, I am leaning towards the latter part of #2, > hard-locking mitigation settings at something tests prove is > "reasonable", and in heavy load situations NAPI will kick in as > expected, and perform its magic ;-) I've planned a test with the recent tg3 stuff for some time... Cheers. --ro From jt@bougret.hpl.hp.com Mon Jan 13 09:18:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Jan 2003 09:18:42 -0800 (PST) Received: from deimos.hpl.hp.com (deimos.hpl.hp.com [192.6.19.190]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0DHIX3v016750 for ; Mon, 13 Jan 2003 09:18:34 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by deimos.hpl.hp.com (8.9.3 (PHNE_24419)/HPL-PA Relay) with ESMTP id JAA25865; Mon, 13 Jan 2003 09:24:35 -0800 (PST) Received: from bougret.hpl.hp.com (mail@bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_25184)/8.9.3 HPLabs Timeshare Server) with ESMTP id JAA12840; Mon, 13 Jan 2003 09:24:35 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 18Y8KB-0005Ko-00; Mon, 13 Jan 2003 09:24:35 -0800 Date: Mon, 13 Jan 2003 09:24:35 -0800 To: Denis Vlasenko Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.4.20-pre11: PCI Wavelan card loses connection Message-ID: <20030113172435.GC20409@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <200301130821.h0D8Kis26772@Port.imtp.ilyichevsk.odessa.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200301130821.h0D8Kis26772@Port.imtp.ilyichevsk.odessa.ua> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 1531 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev Content-Length: 888 Lines: 23 On Mon, Jan 13, 2003 at 10:20:14AM +0200, Denis Vlasenko wrote: > I bought a PCI wireless card, a DLink-520 (I think, I forgot exactly > (it's at home), anyway, lspci dump is below). > > We (my father and me) made a fairly long helical aerial. > We are trying to communicate over ~15 km with a small wireless cell. > (~10 hosts, one AP). > > We can successfully associate with it, signal is weak as expected. > But after a short while our eth0 seems to 'fall off the net' > and while it looks like we can send packets, we see no incoming data > at all. > > Since I have almost zero wireless experience, I'll be happy if someone > with said experience can read further and say what bites us. Personally, I never managed to get this hardware to work at all. And Orinoco is known to have problems with PrismII cards. Please use the HostAP or linux-wlan-ng driver. Good luck... Jean From kuznet@ms2.inr.ac.ru Mon Jan 13 12:42:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Jan 2003 12:42:33 -0800 (PST) Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0DKgO3v001907 for ; Mon, 13 Jan 2003 12:42:26 -0800 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id XAA09194; Mon, 13 Jan 2003 23:48:10 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200301132048.XAA09194@sex.inr.ac.ru> Subject: Re: SCTP path mtu support needs some ip layer support. To: jgrimm2@us.ibm.com (Jon Grimm) Date: Mon, 13 Jan 2003 23:48:10 +0300 (MSK) Cc: davem@redhat.com, sri@us.ibm.com, netdev@oss.sgi.com In-Reply-To: <3E1CCD72.6020100@us.ibm.com> from "Jon Grimm" at Jan 8, 3 07:16:34 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 1532 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 974 Lines: 23 Hello! > Well, I personally like having the flexibility to do either. So, we'll > take you up on your offer to allow control over DF. Beware! To all that I can say, clearing DF on some packets compromises path mtu discovery. If you need to have cleared DF on some packets in a flow, this means in fact, that path mtu discovery is not supported at protocol level at all. So, I would like to ask you to consult SCTP designers. If the thing which you have said is true this means they desinged a crippled protocol. Support of pmtu discovery as described in rfc means possibility of semantic fragmentation to retransmit any data bits. If SCTP is not ablet to do this, then you should not support pmtu discovery at all like most of people make for UDP or to follow UDP pattern, fragmenting frames when their size exceeds mtu. It is not necessary to cripple ip_queue_xmit calling conventions to make this, just add a flag to socket to clear DF on oversized frames. Alexey From ak@suse.de Mon Jan 13 13:01:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Jan 2003 13:01:22 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0DL1F3v002401 for ; Mon, 13 Jan 2003 13:01:16 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 7143C14A71; Mon, 13 Jan 2003 22:07:13 +0100 (MET) Date: Mon, 13 Jan 2003 22:07:08 +0100 From: Andi Kleen To: kuznet@ms2.inr.ac.ru, Jon Grimm Cc: davem@redhat.com, sri@us.ibm.com, netdev@oss.sgi.com Subject: Re: SCTP path mtu support needs some ip layer support. Message-ID: <20030113210708.GA328@wotan.suse.de> References: <3E1CCD72.6020100@us.ibm.com> <200301132048.XAA09194@sex.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200301132048.XAA09194@sex.inr.ac.ru> User-Agent: Mutt/1.4i X-archive-position: 1533 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 1063 Lines: 20 > Support of pmtu discovery as described in rfc means possibility of semantic > fragmentation to retransmit any data bits. If SCTP is not ablet to do this, > then you should not support pmtu discovery at all like most of people make > for UDP or to follow UDP pattern, fragmenting frames when their size exceeds > mtu. It is not necessary to cripple ip_queue_xmit calling conventions > to make this, just add a flag to socket to clear DF on oversized > frames. Some recent incidents have shown that ip fragmentation/defragmention at gigabit speed is rather worthless. The reason is that it has no PAWS and the 16bit ipid can wrap many times in the standard reassembly timeout, leading to lots of misassembled packets on a busy network. Mostly that can be catched by computing the transport layer checksum, but often enough a misassembled packet can slip through. While in SCTP it may work a bit better because it supports stronger checksums (but only optionally afaik) it is still too dangerous. So in short clearing DF is near always a bug these days. -Andi From niv@us.ibm.com Mon Jan 13 13:17:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Jan 2003 13:17:38 -0800 (PST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0DLHY3v002869 for ; Mon, 13 Jan 2003 13:17:35 -0800 Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0DLNXZf213122; Mon, 13 Jan 2003 16:23:33 -0500 Received: from us.ibm.com (dyn9-47-18-188.beaverton.ibm.com [9.47.18.188]) by northrelay01.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0DLNTpo154922; Mon, 13 Jan 2003 16:23:29 -0500 Message-ID: <3E232DF7.4D68D57C@us.ibm.com> Date: Mon, 13 Jan 2003 13:21:59 -0800 From: Nivedita Singhvi Reply-To: niv@us.ibm.com X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Andi Kleen CC: kuznet@ms2.inr.ac.ru, Jon Grimm , davem@redhat.com, sri@us.ibm.com, netdev@oss.sgi.com Subject: Re: SCTP path mtu support needs some ip layer support. References: <3E1CCD72.6020100@us.ibm.com> <200301132048.XAA09194@sex.inr.ac.ru> <20030113210708.GA328@wotan.suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1534 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1338 Lines: 28 > > fragmentation to retransmit any data bits. If SCTP is not ablet to do this, > > then you should not support pmtu discovery at all like most of people make > > for UDP or to follow UDP pattern, fragmenting frames when their size exceeds > > mtu. It is not necessary to cripple ip_queue_xmit calling conventions > > to make this, just add a flag to socket to clear DF on oversized > > frames. > > Some recent incidents have shown that ip fragmentation/defragmention > at gigabit speed is rather worthless. The reason is that it has no PAWS > and the 16bit ipid can wrap many times in the standard reassembly > timeout, leading to lots of misassembled packets on a busy network. > Mostly that can be catched by computing the transport layer > checksum, but often enough a misassembled packet can slip through. > While in SCTP it may work a bit better because it supports stronger > checksums (but only optionally afaik) it is still too dangerous. > So in short clearing DF is near always a bug these days. > > -Andi I'd second that and say that its absolutely a must that SCTP support path MTU as much as possible, and limit the fragmenting to the unresegmentable queued stuff only, which should only happen if the MTU changes, rare enough that it wont be a big deal, and with limited number of segments affected.. thanks, Nivedita From kuznet@ms2.inr.ac.ru Mon Jan 13 13:19:58 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Jan 2003 13:20:02 -0800 (PST) Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0DLJu3v003232 for ; Mon, 13 Jan 2003 13:19:57 -0800 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id AAA09366; Tue, 14 Jan 2003 00:25:44 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200301132125.AAA09366@sex.inr.ac.ru> Subject: Re: SCTP path mtu support needs some ip layer support. To: ak@suse.de (Andi Kleen) Date: Tue, 14 Jan 2003 00:25:44 +0300 (MSK) Cc: jgrimm2@us.ibm.com, davem@redhat.com, sri@us.ibm.com, netdev@oss.sgi.com In-Reply-To: <20030113210708.GA328@wotan.suse.de> from "Andi Kleen" at Jan 13, 3 10:07:08 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 1535 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 298 Lines: 10 Hello! > So in short clearing DF is near always a bug these days. Exactly. And it is exactly why I said that this compromises all the pmtu discvoery and why I would like people consulted SCTP designers before doing this step. I cannot believe that new protocol was designed in this way. Alexey From sri@us.ibm.com Mon Jan 13 14:47:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Jan 2003 14:47:51 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0DMlj3v005707 for ; Mon, 13 Jan 2003 14:47:46 -0800 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0DMrh5c017882; Mon, 13 Jan 2003 17:53:43 -0500 Received: from dyn9-47-18-98.beaverton.ibm.com (dyn9-47-18-98.beaverton.ibm.com [9.47.18.98]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0DMqP2l039408; Mon, 13 Jan 2003 15:52:25 -0700 Date: Mon, 13 Jan 2003 14:54:06 -0800 (PST) From: Sridhar Samudrala X-X-Sender: To: cc: Jon Grimm , , , Subject: Re: SCTP path mtu support needs some ip layer support. In-Reply-To: <200301132048.XAA09194@sex.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1536 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2997 Lines: 65 On Mon, 13 Jan 2003 kuznet@ms2.inr.ac.ru wrote: > Hello! > > > Well, I personally like having the flexibility to do either. So, we'll > > take you up on your offer to allow control over DF. > > Beware! To all that I can say, clearing DF on some packets compromises > path mtu discovery. If you need to have cleared DF on some packets in a flow, > this means in fact, that path mtu discovery is not supported at protocol level > at all. > > So, I would like to ask you to consult SCTP designers. If the thing which > you have said is true this means they desinged a crippled protocol. I guess SCTP desginers have thought of this and explicitly indicate that we should resort to IP fragmentation when it is detected that an already fragmented message exceeds the PMTU. From Sec 6.9 of RFC 2960, Note: Once a message is fragmented it cannot be re-fragmented. Instead if the PMTU has been reduced, then IP fragmentation must be used. Please see Section 7.3 for details of PMTU discovery. From Sec 7.3 of RFC 2960, 4) Since data transmission in SCTP is naturally structured in terms of TSNs rather than bytes (as is the case for TCP), the discussion in Section 6.5 of RFC 1191 applies: When retransmitting an IP datagram to a remote address for which the IP datagram appears too large for the path MTU to that address, the IP datagram SHOULD be retransmitted without the DF bit set, allowing it to possibly be fragmented. Transmissions of new IP datagrams MUST have DF set. > > Support of pmtu discovery as described in rfc means possibility of semantic > fragmentation to retransmit any data bits. If SCTP is not ablet to do this, > then you should not support pmtu discovery at all like most of people make > for UDP or to follow UDP pattern, fragmenting frames when their size exceeds > mtu. It is not necessary to cripple ip_queue_xmit calling conventions > to make this, just add a flag to socket to clear DF on oversized > frames. PMTU discovery is a must for SCTP and moreover DF bit needs to be set only for a few messages which are already fragmented. This may happen only when the PMTU of a route changes which should not happen very frequently. So i don't think not supporting PMTU discovery is a good solution. The chances of running into ip-id wrap-around issues with SCTP should be pretty low as only a few packets on a flow may need to disable DF bits causing ip fragmentation. Are you suggesting that another flag be added to struct inet_opt similar to pmtudisc, that is checked in ip_dont_fragment()? Even with this flag, i think each packet needs to checked if it is oversized. I was planning to add a 2nd argument, ipfragok to ip_queue_xmit() and make the following change in ip_queue_xmit() - if (ip_dont_fragment(sk, &rt->u.dst)) + if (ip_dont_fragment(sk, &rt->u.dst) && !ipfragok) I am not clear on your other alternative of adding a socket flag. Could you please elaborate on it? Thanks Sridhar From kuznet@ms2.inr.ac.ru Mon Jan 13 15:16:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Jan 2003 15:16:28 -0800 (PST) Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0DNGL3v006401 for ; Mon, 13 Jan 2003 15:16:23 -0800 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id CAA09642; Tue, 14 Jan 2003 02:22:12 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200301132322.CAA09642@sex.inr.ac.ru> Subject: Re: SCTP path mtu support needs some ip layer support. To: sri@us.ibm.com (Sridhar Samudrala) Date: Tue, 14 Jan 2003 02:22:12 +0300 (MSK) Cc: jgrimm2@us.ibm.com, davem@redhat.com, sri@us.ibm.com, netdev@oss.sgi.com In-Reply-To: from "Sridhar Samudrala" at Jan 13, 3 02:54:06 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 1537 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 926 Lines: 27 Hello! > I am not clear on your other alternative of adding a socket flag. Could you > please elaborate on it? Not to add any arguments just to help a broken protocol. Simply to behave like UDP, i.e. to fragment all the oversized frames. Probably, even new flag is not required, just check for sk->protocol == IPPROTO_SCTP can be enough. It is almost equivalent, it also send fragmented crap only when mtu decreases. But this variant is _formally_ prohibited with: > fragmented. Transmissions of new IP datagrams MUST have DF set. BTW this MUST is even more ridiculous, you have to change ip_queue_xmit() to do this, we disable pmtu discovery sometimes. > I guess SCTP desginers have thought of this and explicitly indicate that we I am afraid SCTP designers thought with their spinal chrod. :-) Relying on IP fragmentation promotes all the protocol to the status of utter crap. So, long live TCP! :-) Alexey From jgrimm2@us.ibm.com Mon Jan 13 15:29:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Jan 2003 15:29:11 -0800 (PST) Received: from mg01.austin.ibm.com (mg01.austin.ibm.com [192.35.232.18]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0DNT83v006896 for ; Mon, 13 Jan 2003 15:29:08 -0800 Received: from austin.ibm.com (netmail1.austin.ibm.com [9.3.7.138]) (authenticated bits=0) by mg01.austin.ibm.com (8.12.6/8.12.6) with ESMTP id h0DNaD8i012666; Mon, 13 Jan 2003 17:36:13 -0600 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.53.247.178]) by austin.ibm.com (8.12.6/8.12.6) with ESMTP id h0DNZBCv033312; Mon, 13 Jan 2003 17:35:11 -0600 Received: from us.ibm.com (grimm-udp7074232uds.austin.ibm.com [9.41.94.95]) by popmail.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) with ESMTP id RAA19720; Mon, 13 Jan 2003 17:35:10 -0600 Message-ID: <3E234CF4.70309@us.ibm.com> Date: Mon, 13 Jan 2003 17:34:12 -0600 From: Jon Grimm Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kuznet@ms2.inr.ac.ru CC: Andi Kleen , davem@redhat.com, sri@us.ibm.com, netdev@oss.sgi.com Subject: Re: SCTP path mtu support needs some ip layer support. References: <200301132125.AAA09366@sex.inr.ac.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1538 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgrimm2@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1309 Lines: 41 kuznet@ms2.inr.ac.ru wrote: > Hello! > > >>So in short clearing DF is near always a bug these days. > > > Exactly. And it is exactly why I said that this compromises all the pmtu > discvoery and why I would like people consulted SCTP designers before > doing this step. I cannot believe that new protocol was designed in this way. > > Alexey > It is indeed designed this way. http://www.ietf.org/rfc/rfc2960.txt section 7.3 discusses the differences in SCTP PMTU discovery versus RFC 1191. SCTP packets are filled with "chunks". Data records can be broken into multiple chunks. Chunks are then "bundled" into the packet. Once a TSN (Transmission Sequence Number) is assigned to a data fragment (chunk) of a record, it can not be further fragmented. This should be a rare occurance, but can happen when PMTU shrinks. Now, that being said, there is an alternative that I originally alluded to. That is, pre-fragment chunks down to the smallest possible MTU's needs and then bundle the chunks up together to satisfy the current PMTU. If the current PMTU shrinks, bundle in fewer chunks, down to the smallest packet containing a single chunk. There is a little extra processing at each end and each chunk within the packet eats up a chunk header of 4 bytes. Best Regards, Jon From kuznet@ms2.inr.ac.ru Mon Jan 13 16:06:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Jan 2003 16:06:58 -0800 (PST) Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0E06s3v007544 for ; Mon, 13 Jan 2003 16:06:55 -0800 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id DAA09790; Tue, 14 Jan 2003 03:12:37 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200301140012.DAA09790@sex.inr.ac.ru> Subject: Re: snd_cwnd drawn and quartered To: wa@almesberger.net (Werner Almesberger) Date: Tue, 14 Jan 2003 03:12:37 +0300 (MSK) Cc: netdev@oss.sgi.com, chengjin@cs.caltech.edu In-Reply-To: <20030102030858.E1363@almesberger.net> from "Werner Almesberger" at Jan 2, 3 03:08:58 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 1539 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 1174 Lines: 30 Hello! > I searched around but didn't spot anything. A pointer would be > welcome, thanks ! I bring apologies for silence. I see you have already found it. > Yes, but rate-halving is what causes in-flight to drop in the first > place (assuming we have enough fresh data to send, of course), no ? Of course. But draining happens when you received more ACKs than you sent packets. When such pathalogy happens we just have to do something, at least to understand when it happens under normal conditions. Probably, the reason of confusion is that original rh seems to include some bits of "lost-sensitive recovery", so cnwd really is supposed to shrink to cwnd/2 - lost there. See? We do not make this, and the check for 1/4 really look as an alien. > I've put graphs of a simulation run (with and without the change) at > http://www.almesberger.net/misc/half.eps > http://www.almesberger.net/misc/quarter.eps I see. Not quite understand the reason though. :-) You said something about lost retransmissions... How much of retransmits were lost in the simulation? Are you aware that each lost retransmission, if we behaved honestly, would collapse cwnd to 1? :-) Alexey From sri@us.ibm.com Mon Jan 13 16:42:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Jan 2003 16:42:36 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0E0gS3v008061 for ; Mon, 13 Jan 2003 16:42:29 -0800 Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e4.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0E0lsOd073784; Mon, 13 Jan 2003 19:47:54 -0500 Received: from dyn9-47-18-98.beaverton.ibm.com (dyn9-47-18-98.beaverton.ibm.com [9.47.18.98]) by northrelay01.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0E0lopp160548; Mon, 13 Jan 2003 19:47:51 -0500 Date: Mon, 13 Jan 2003 16:49:33 -0800 (PST) From: Sridhar Samudrala X-X-Sender: To: cc: Sridhar Samudrala , , , Subject: Re: SCTP path mtu support needs some ip layer support. In-Reply-To: <200301132322.CAA09642@sex.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1540 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 3487 Lines: 89 On Tue, 14 Jan 2003 kuznet@ms2.inr.ac.ru wrote: > Hello! > > > I am not clear on your other alternative of adding a socket flag. Could you > > please elaborate on it? > > Not to add any arguments just to help a broken protocol. > Simply to behave like UDP, i.e. to fragment all the oversized frames. > Probably, even new flag is not required, just check for > sk->protocol == IPPROTO_SCTP can be enough. > > It is almost equivalent, it also send fragmented crap only when > mtu decreases. But this variant is _formally_ prohibited with: > > > fragmented. Transmissions of new IP datagrams MUST have DF set. > > BTW this MUST is even more ridiculous, you have to change ip_queue_xmit() > to do this, we disable pmtu discovery sometimes. > > > > I guess SCTP desginers have thought of this and explicitly indicate that we > > I am afraid SCTP designers thought with their spinal chrod. :-) > Relying on IP fragmentation promotes all the protocol to the status > of utter crap. So, long live TCP! :-) Any record based protocol that supports path mtu discovery needs to rely on ip fragmentation when pmtu is lowered and a packet needs to be re-fragmented. In fact, both ipv4 and ipv6 path mtu discovery RFCs have a section that talks about other transport protocols that have this behavior. RFC1191 6.5. Issues for other transport protocols Some transport protocols (such as ISO TP4 [3]) are not allowed to repacketize when doing a retransmission. That is, once an attempt is made to transmit a datagram of a certain size, its contents cannot be split into smaller datagrams for retransmission. In such a case, the original datagram should be retransmitted without the DF bit set, allowing it to be fragmented as necessary to reach its destination. Subsequent datagrams, when transmitted for the first time, should be no larger than allowed by the Path MTU, and should have the DF bit set. SCTP falls into the above category of transport protocols and basically needs a mechanism that is mid-way between TCP and UDP. Set DF bit most of the time, and unset DF bit only for messages that need to be refragmented. I can think of another solution which does not add any overhead to TCP. Add a second argument to ip_queue_xmit() to pass the value that will be set to IP_DF bit. TCP calls this routine with htons(IP_DF) as the 2nd argument always. ip_queue_xmit(skb, htons(IP_DF)) SCTP calls this routine with htons(IP_DF) as the 2nd argument most of the time, but with 0 as the 2nd argument when a packet needs to be re-fragmented. --- ip_output.c Mon Jan 13 16:43:10 2003 +++ ip_output.c.new Mon Jan 13 16:43:13 2003 @@ -280,7 +280,7 @@ return ip_finish_output(skb); } -int ip_queue_xmit(struct sk_buff *skb) +int ip_queue_xmit(struct sk_buff *skb, __u16 ip_df) { struct sock *sk = skb->sk; struct inet_opt *inet = inet_sk(sk); @@ -338,7 +338,7 @@ *((__u16 *)iph) = htons((4 << 12) | (5 << 8) | (inet->tos & 0xff)); iph->tot_len = htons(skb->len); if (ip_dont_fragment(sk, &rt->u.dst)) - iph->frag_off = htons(IP_DF); + iph->frag_off = ip_df; else iph->frag_off = 0; iph->ttl = inet->ttl; Is this more agreeable? If not, do you prefer SCTP having its own ip_xmit routine that fills in its own ip header and calls dst->output. Only requirement is that ip_options_build() is exported. Thanks Sridhar From kuznet@ms2.inr.ac.ru Mon Jan 13 16:48:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Jan 2003 16:48:21 -0800 (PST) Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0E0mH3v008525 for ; Mon, 13 Jan 2003 16:48:18 -0800 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id DAA09932; Tue, 14 Jan 2003 03:54:12 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200301140054.DAA09932@sex.inr.ac.ru> Subject: Re: snd_cwnd drawn and quartered To: wa@almesberger.net (Werner Almesberger) Date: Tue, 14 Jan 2003 03:54:12 +0300 (MSK) Cc: netdev@oss.sgi.com, chengjin@cs.caltech.edu In-Reply-To: <20030102030858.E1363@almesberger.net> from "Werner Almesberger" at Jan 2, 3 03:08:58 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 1541 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 527 Lines: 14 Hello! > http://www.almesberger.net/misc/quarter.eps So... recovery is supposed to terminate when snd.una reaches 100 (snd.nxt at beginning of fast retransmit). In this case cwnd would be orig_cwnd/2, as expected. But it did not stop! Hence, something extraordinary happened while recovery, which resulted in the second recovery. But I do not understand why snd_ssthresh was not shrinken too. All this smells like a bug. I do not see from the picture what was this. Can you make a pseudo-tcpdump instead of picture? Alexey From sri@us.ibm.com Mon Jan 13 16:49:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Jan 2003 16:49:25 -0800 (PST) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0E0nM3v008851 for ; Mon, 13 Jan 2003 16:49:22 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0E0tLmd149228; Mon, 13 Jan 2003 19:55:21 -0500 Received: from dyn9-47-18-98.beaverton.ibm.com (dyn9-47-18-98.beaverton.ibm.com [9.47.18.98]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0E0tClb044492; Mon, 13 Jan 2003 19:55:17 -0500 Date: Mon, 13 Jan 2003 16:56:56 -0800 (PST) From: Sridhar Samudrala X-X-Sender: To: Mika Liljeberg cc: Sridhar Samudrala , , Jon Grimm , , Subject: Re: SCTP path mtu support needs some ip layer support. In-Reply-To: <1042498998.2610.8.camel@devil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1542 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 890 Lines: 28 On 14 Jan 2003, Mika Liljeberg wrote: > Hi, > > I know this is not what the SCTP spec recommends with IPv4, but what > prevents you from just fragmenting the IP packets at the source and > setting the DF bit on each fragment (assuming you can't just repackage > the data chunks)? This would be equivalent to the IPv6 behaviour and > would keep PMTUD working perfectly. SCTP does segment the packets based on the current PMTU and sets DF bit to not allowing IP fragmentation. The problem occurs when the PMTU shrinks and there are outstanding segmented packets which need to be retransmitted. We cannot re-segment these packets, but would like IP to fragment them by not setting DF bit. > > With IPv6 you don't have a DF bit to control, so you have only two > options. Either use a maximum chunk size smaller than 1280, or fragment > at the source. > > Regards, > > MikaL > > > From chengjin@cs.caltech.edu Mon Jan 13 17:14:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Jan 2003 17:14:10 -0800 (PST) Received: from swordfish.cs.caltech.edu (swordfish.cs.caltech.edu [131.215.44.124]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0E1E23v009544 for ; Mon, 13 Jan 2003 17:14:03 -0800 Received: from orchestra.cs.caltech.edu (orchestra.cs.caltech.edu [131.215.44.20]) by swordfish.cs.caltech.edu (Postfix) with ESMTP id 18367DF268; Mon, 13 Jan 2003 17:20:07 -0800 (PST) Received: from localhost (chengjin@localhost) by orchestra.cs.caltech.edu (8.11.6/8.9.3) with ESMTP id h0E1K6530661; Mon, 13 Jan 2003 17:20:06 -0800 X-Authentication-Warning: orchestra.cs.caltech.edu: chengjin owned process doing -bs Date: Mon, 13 Jan 2003 17:20:06 -0800 (PST) From: Cheng Jin To: "kuznet@ms2.inr.ac.ru" Cc: Werner Almesberger , "netdev@oss.sgi.com" Subject: Re: snd_cwnd drawn and quartered In-Reply-To: <200301140012.DAA09790@sex.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1543 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chengjin@cs.caltech.edu Precedence: bulk X-list: netdev Content-Length: 1600 Lines: 33 > I see. Not quite understand the reason though. :-) You said something > about lost retransmissions... How much of retransmits were lost > in the simulation? Are you aware that each lost retransmission, > if we behaved honestly, would collapse cwnd to 1? :-) Yes, I am aware of this, and when this happens, cwnd will sit @ 1 until TCP gets out of recovery (1 retransmits per rtt). It's debatable whether cwnd should remain 1 for the rest of the recovery period even if really sever congestion brings cwnd down to 1. For example, if there are 100 pkts to be rexmitted when cwnd gets to 1, it will take at least 100 RTTs to leave recovery. By then, whatever network condition that causes congestion in the first place might be long gone already, but one wouldn't know the true state of the network with such a small cwnd. Maybe cwnd could be clamped at some minimum value (greater than 1) depending on ssthresh? From what I have observed, cwnd gets reduced to 1 mainly because of lost retransmits. I think the tcp_rs can show that. Linux TCP deals with a lost retransmit by reducing retrans_out by one so in_flight ends up becoming one less. In tcp_cwnd_down, cwnd is always clamped at in_flight so if many rexmits are lost (over many RTTs), cwnd gets reduced quite often. However, when cwnd is small, loss retransmits are not reliable signals for the severity of congestion, for example, when cwnd is 10, does losing one pkt mean 10% pkts loss in the network? Again, I am not saying right or wrong about how cwnd changes, but it is something that we could think about. THanks, Cheng From kuznet@ms2.inr.ac.ru Mon Jan 13 17:17:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Jan 2003 17:17:04 -0800 (PST) Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0E1H03v009915 for ; Mon, 13 Jan 2003 17:17:01 -0800 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id EAA10371; Tue, 14 Jan 2003 04:22:52 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200301140122.EAA10371@sex.inr.ac.ru> Subject: Re: SCTP path mtu support needs some ip layer support. To: sri@us.ibm.com (Sridhar Samudrala) Date: Tue, 14 Jan 2003 04:22:52 +0300 (MSK) Cc: sri@us.ibm.com, jgrimm2@us.ibm.com, davem@redhat.com, netdev@oss.sgi.com In-Reply-To: from "Sridhar Samudrala" at Jan 13, 3 04:49:33 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 1544 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 993 Lines: 29 Hello! > Is this more agreeable? I did not disagree with the first one, actually. :-) It was cleaner, to be honest. In any case, after reading mail by Jon Grimm, the things became cleaner. BTW what is "chunk" size in current implementation? Essentially, to make a compromise between usability and sanity, it is enough to make the thing which we make with UDP: to prevent sending bogus fragmented packets when IP_MTUDISC_DO is set by user and set chunk size to a value < min(512,current mtu) in this case, so no fragments will be generated. In that case I will be happy (done all that possible, all the flaws are directed to SCTP designers. :-)) and default behaviour (it is IP_MTUDISC_WANT) still will be rfc compliant. > If not, do you prefer SCTP having its own ip_xmit Hey, only not this. :-) BTW what did you make with IPv6? We even not have any analogue to ip_fragment there at the moment. Do not worry, we have to do this in any case, not depending on SCTP demands. :-) Alexey From kuznet@ms2.inr.ac.ru Mon Jan 13 17:41:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Jan 2003 17:41:02 -0800 (PST) Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0E1ev3v010841 for ; Mon, 13 Jan 2003 17:40:59 -0800 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id EAA10411; Tue, 14 Jan 2003 04:46:49 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200301140146.EAA10411@sex.inr.ac.ru> Subject: Re: snd_cwnd drawn and quartered To: chengjin@cs.caltech.edu (Cheng Jin) Date: Tue, 14 Jan 2003 04:46:49 +0300 (MSK) Cc: wa@almesberger.net, netdev@oss.sgi.com In-Reply-To: from "Cheng Jin" at Jan 13, 3 05:20:06 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 1545 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 1488 Lines: 39 Hello! > Yes, I am aware of this, and when this happens, cwnd will sit @ 1 until > TCP gets out of recovery (1 retransmits per rtt). It's debatable Nothing to debate, really. Following specs lost retransmission must trigger RTO timeout with sunsubsequent slow start starting from 1. We are _more_ liberal when SACKs are on, this really can be argued and I am ready to defend the liberal values. :-) But when we cannot detect loss opf retransmission, we have to return to standard go-back-n behaviour. > pkts to be rexmitted when cwnd gets to 1, it will take at least 100 RTTs to Not a big deal. You have to wait the same 100 RTTs at start of each connection, even though initial slow start _assumes_ that no congestion is present. So, when you experienced real congestion, slow start is really fair. :-) > In tcp_cwnd_down, cwnd is always clamped at in_flight > so if many rexmits are lost (over many RTTs), cwnd gets reduced quite > often. It is (half of) loss-sensitive recovery. Luckily, we are not mad enough to shrink ssthresh as well. But imagine, month ago I had long boring argument with a guy who insisted that ssthresh must be shrinken too, otherwise "cwnd grows too fast". :-) > does losing one pkt mean 10% pkts loss in the network? Not less than 10% of loss. Maybe, more, but you were lucky and your packets percolated through deadly congested router. :-) It is basic assumption of cwnd avoidance: each loss is considered as loss due to congestion. Alexey From chengjin@cs.caltech.edu Mon Jan 13 17:52:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Jan 2003 17:52:11 -0800 (PST) Received: from swordfish.cs.caltech.edu (swordfish.cs.caltech.edu [131.215.44.124]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0E1q53v011283 for ; Mon, 13 Jan 2003 17:52:06 -0800 Received: from orchestra.cs.caltech.edu (orchestra.cs.caltech.edu [131.215.44.20]) by swordfish.cs.caltech.edu (Postfix) with ESMTP id 74501DF260; Mon, 13 Jan 2003 17:58:07 -0800 (PST) Received: from localhost (chengjin@localhost) by orchestra.cs.caltech.edu (8.11.6/8.9.3) with ESMTP id h0E1w7G31488; Mon, 13 Jan 2003 17:58:07 -0800 X-Authentication-Warning: orchestra.cs.caltech.edu: chengjin owned process doing -bs Date: Mon, 13 Jan 2003 17:58:07 -0800 (PST) From: Cheng Jin To: "kuznet@ms2.inr.ac.ru" Cc: "wa@almesberger.net" , "netdev@oss.sgi.com" Subject: Re: snd_cwnd drawn and quartered In-Reply-To: <200301140146.EAA10411@sex.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1546 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chengjin@cs.caltech.edu Precedence: bulk X-list: netdev Content-Length: 1865 Lines: 41 > > Yes, I am aware of this, and when this happens, cwnd will sit @ 1 until > > TCP gets out of recovery (1 retransmits per rtt). It's debatable > > Nothing to debate, really. Following specs lost retransmission must trigger > RTO timeout with sunsubsequent slow start starting from 1. I don't always see time-out+slow-start in this case. I have seen TCP staying in recovery for a very long time with cwnd=1. I think Linux TCP has various detection mechanisms for lost rexmit so time-out doesn't always happen. I think there is lost rexmit detection code at the end of tcp_sacktag_write_queue. > We are _more_ liberal when SACKs are on, this really can be argued > and I am ready to defend the liberal values. :-) But when we cannot > detect loss opf retransmission, we have to return to standard go-back-n > behaviour. Yes, Linux does indeed do more aggressive lost detection than what's in the spec. I am fine with that. > Not a big deal. You have to wait the same 100 RTTs at start of each connection, > even though initial slow start _assumes_ that no congestion is present. > So, when you experienced real congestion, slow start is really fair. :-) I am not sure what you mean here, slow start takes much faster to transmit 100 pkts than 100 RTTs. Maybe there is a misunderstanding here, when cwnd=1 in congestion recovery, it will stay at 1 until it exits recovery unless some packet times out first. > Not less than 10% of loss. Maybe, more, but you were lucky and your > packets percolated through deadly congested router. :-) > It is basic assumption of cwnd avoidance: each loss is considered > as loss due to congestion. Certainly. It's difficult to know what the right cwnd should be when this happens, and a conservative approach may be the best one to take. I am just curious if people can come up with better ways to set cwnd. Cheng From kuznet@ms2.inr.ac.ru Mon Jan 13 18:06:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Jan 2003 18:06:29 -0800 (PST) Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0E26L3v011888 for ; Mon, 13 Jan 2003 18:06:22 -0800 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id FAA10465; Tue, 14 Jan 2003 05:12:11 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200301140212.FAA10465@sex.inr.ac.ru> Subject: Re: snd_cwnd drawn and quartered To: chengjin@cs.caltech.edu (Cheng Jin) Date: Tue, 14 Jan 2003 05:12:11 +0300 (MSK) Cc: wa@almesberger.net, netdev@oss.sgi.com In-Reply-To: from "Cheng Jin" at Jan 13, 3 05:58:07 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 1547 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 671 Lines: 21 Hello! > I am not sure what you mean here, slow start takes much faster to > transmit 100 pkts than 100 RTTs. Maybe there is a misunderstanding here, > when cwnd=1 in congestion recovery, it will stay at 1 until it exits > recovery unless some packet times out first. I see! Seems, you spotted a real problem. I missed this. I feel we should add a trigger stopping such "fast" :-) restransmit when cwnd falls low. Maybe, the same just curious if people can come up with better ways to set cwnd. Come up! :-) Alexey From chengjin@cs.caltech.edu Mon Jan 13 18:13:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Jan 2003 18:13:56 -0800 (PST) Received: from swordfish.cs.caltech.edu (swordfish.cs.caltech.edu [131.215.44.124]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0E2Ds3v012328 for ; Mon, 13 Jan 2003 18:13:54 -0800 Received: from orchestra.cs.caltech.edu (orchestra.cs.caltech.edu [131.215.44.20]) by swordfish.cs.caltech.edu (Postfix) with ESMTP id C7D52DF260; Mon, 13 Jan 2003 18:19:58 -0800 (PST) Received: from localhost (chengjin@localhost) by orchestra.cs.caltech.edu (8.11.6/8.9.3) with ESMTP id h0E2JwV31862; Mon, 13 Jan 2003 18:19:58 -0800 X-Authentication-Warning: orchestra.cs.caltech.edu: chengjin owned process doing -bs Date: Mon, 13 Jan 2003 18:19:58 -0800 (PST) From: Cheng Jin To: "kuznet@ms2.inr.ac.ru" Cc: "wa@almesberger.net" , "netdev@oss.sgi.com" Subject: Re: snd_cwnd drawn and quartered In-Reply-To: <200301140212.FAA10465@sex.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1548 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chengjin@cs.caltech.edu Precedence: bulk X-list: netdev Content-Length: 167 Lines: 8 > Could you, please, prepare a demo pseudo-tcpdump with your simulator? What would you like to see in the demo? Just the straight output from my simulator? Cheng From werner@almesberger.net Mon Jan 13 19:56:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Jan 2003 19:56:17 -0800 (PST) Received: from host.almesberger.net (IDENT:pAa0bRifSlxPimIEMK9raiPefnvEvM5L@almesberger.net [63.105.73.239] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0E3uC3v013724 for ; Mon, 13 Jan 2003 19:56:12 -0800 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.9.3/8.9.3) with ESMTP id UAA02740; Mon, 13 Jan 2003 20:02:08 -0800 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id h0E41vS23098; Tue, 14 Jan 2003 01:01:57 -0300 Date: Tue, 14 Jan 2003 01:01:57 -0300 From: Werner Almesberger To: kuznet@ms2.inr.ac.ru Cc: netdev@oss.sgi.com, chengjin@cs.caltech.edu Subject: Re: snd_cwnd drawn and quartered Message-ID: <20030114010157.M1516@almesberger.net> References: <20030102030858.E1363@almesberger.net> <200301140012.DAA09790@sex.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200301140012.DAA09790@sex.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Tue, Jan 14, 2003 at 03:12:37AM +0300 X-archive-position: 1549 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wa@almesberger.net Precedence: bulk X-list: netdev Content-Length: 5734 Lines: 129 kuznet@ms2.inr.ac.ru wrote: > Of course. But draining happens when you received more ACKs than > you sent packets. When such pathalogy happens we just have to do something, > at least to understand when it happens under normal conditions. Yes, that's a separate problem. There are (at least :-) two problems we're looking at: - cwnd getting too small, probably due to "natural causes", and not recovering properly - cwnd getting reduced too much by the ssthresh/2 test Cheng's been talking about the first one, I'm on the latter. Note that in my case, no retransmissions are lost. There are only some additional losses in the initial cwnd (actually, just one loss would be sufficient), which then extend the recovery period. I went through draft-ratehalving and compared it with what our TCP is doing. It seems that the test is actually about 50% right :-) Below is my analysis of the situation. How do you like the idea of adding another variable ? :-) Here we go: To analyze whether changing tcp_input.c:tcp_cwnd_down from if (decr && tp->snd_cwnd > tp->snd_ssthresh/2) to if (decr && tp->snd_cwnd > tp->snd_ssthresh) yields valid TCP behaviour, I'm comparing the algorithm specification in draft-ratehalving [1] with the implementation of Linux TCP. The goal is to show whether Linux TCP still performs according to draft-ratehalving after the change. [1] http://www.psc.edu/networking/ftp/papers/draft-ratehalving.txt draft-ratehalving generally aims to set cwnd (they call it rhcwnd) to (prior_cwnd-loss)/2 (section 5.14), where "loss" are the packets that have been lost from the RTT sent before we entered recovery, and "prior_cwnd" is the cwnd at the time when we began recovery. This is also explained in section 3.1 of RFC2581. For simplicity, let's assume there is no reordering, no ACK loss, and no jumps in delay. Without NewReno, there are two cases: if the loss is indicated by an "exact" means (ECN, SACK), it reduces cwnd by half the distance by which fack is advanced, plus half the size of any "holes" found via SACK (5.6). At the end of recovery, cwnd should therefore reach (prior_cwnd-loss)/2, as specified above. Still without NewReno, if loss is indicated by a duplicate ACK without SACK, cwnd is reduced by half a segment for each duplicate ACK received (4.7). This way, cwnd will shrink to (prior_cwnd+loss)/2. (No typo - it's "+"). With NewReno, the algorithms are the same, but cwnd stops decrementing at cwnd <= prior_cwnd/2 (5.12). Once we get out of recovery, cwnd gets set to (prior_cwnd-num_retrans)/2, where num_retrans is the number of retransmissions in the "repair interval" (4.13). This is effectively the number of retransmissions we needed to fix the initial loss. I'm not entirely sure how this changes if we lose a retransmission. RFC2581 requires cwnd to be halved twice in this case (4.3). At the end (4.14), draft-ratehalving forces the new cwnd below prior_cwnd/2 (in case we didn't decrement enough, e.g. in the second "old" Reno case). It also sets ssthresh to the new cwnd, but makes sure it (ssthresh) does not drop below prior_cwnd/4 to ensure "that the TCP connection is not unduly harmed by extreme network conditions" (5.14, probably meaning reordering). When entering congestion (tcp_input.c:tcp_fastretrans_alert), Linux TCP sets ssthresh to roughly half cwnd (tcp.h:tcp_recalc_ssthresh). Note that this differs from the requirement of setting ssthresh to half the amount of data in flight. During recovery, cwnd reduction is done by tcp_input.c:tcp_cwnd_down as follows: snd_cwnd is decremented for every second (duplicate) ACK, which corresponds to sections 4.7 and 4.12 of draft-ratehalving, except that snd_cwnd reduction stops at snd_ssthresh/2 (corresponding roughly to prior_cwnd/4) instead of prior_cwnd/2. Additionally, cwnd may be further reduced if there are less than cwnd packets in flight. (This deserves further analysis.) The equivalent to the first part of 4.14 happens in tcp_complete_cwr: cwnd is set to the minimum of cwnd and ssthresh, where the latter is (roughly) prior_cwnd/2. Raising the cut-off point for cwnd reduction to ssthresh would still yield the cwnd decrease described in section 4.7, and the cut-off would occur at the point described in section 4.12. Furthermore, at the end of recovery, snd_cwnd is set up prior_cwnd/2, which is consistent with section 5.14. So far, so good. Unfortunately, there are are two exceptions: a loss outside the cwnd in which the initial loss occurred (i.e. loss of data above high_seq) or the loss of a retransmission is required to cause another halving of cwnd. A loss above high_seq is detected and handled as separate loss after the current loss episode has ended, and there does not need to concern us here. However, loss of a retransmission is handled implicitly, as follows: it extends the recovery interval to at least 2*RTT. This causes the current implementation of tcp_cwnd_down to decrement snd_cwnd to ssthresh/2, yielding the correct result. The most correct solution seems therefore to introduce yet another TCP state variable cwnd_bound that limits how far tcp_cwnd_down can decrement snd_cwnd. Initially, tcp_input.c:tcp_clear_retrans and tcp_input.c:tcp_fastretrans_alert would set cwnd_bound to the reduced snd_ssthresh, limiting snd_cwnd reductions to prior_cwnd/2. If tcp_input.c:tcp_sacktag_write_queue detects loss of a retransmission, it sets cwnd_bound to ssthresh/2, allowing reduction down to prior_cwnd/4. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From kuznet@ms2.inr.ac.ru Mon Jan 13 21:01:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Jan 2003 21:01:51 -0800 (PST) Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0E51i3v014460 for ; Mon, 13 Jan 2003 21:01:45 -0800 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id IAA10741; Tue, 14 Jan 2003 08:07:39 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200301140507.IAA10741@sex.inr.ac.ru> Subject: Re: snd_cwnd drawn and quartered To: chengjin@cs.caltech.edu (Cheng Jin) Date: Tue, 14 Jan 2003 08:07:39 +0300 (MSK) Cc: wa@almesberger.net, netdev@oss.sgi.com In-Reply-To: from "Cheng Jin" at Jan 13, 3 06:19:58 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 1550 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 402 Lines: 14 Hello! > What would you like to see in the demo? Just the straight output from my > simulator? Something which will allow to restore history to demonstrate how it is possible to finish in recovery state with cwnd of 1 and lots of data in flight. I see that this is not impossible, but simply cannot figure out when this madness happens. Format does not matter. seq/(s)ack paires are good. Alexey From werner@almesberger.net Mon Jan 13 21:19:10 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Jan 2003 21:19:15 -0800 (PST) Received: from host.almesberger.net (IDENT:fxijxs6PBkyNyLYVZbK0m97jA/yUYgin@almesberger.net [63.105.73.239] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0E5J93v014910 for ; Mon, 13 Jan 2003 21:19:09 -0800 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.9.3/8.9.3) with ESMTP id VAA03161; Mon, 13 Jan 2003 21:25:16 -0800 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id h0E5P9S23499; Tue, 14 Jan 2003 02:25:09 -0300 Date: Tue, 14 Jan 2003 02:25:09 -0300 From: Werner Almesberger To: kuznet@ms2.inr.ac.ru Cc: netdev@oss.sgi.com, chengjin@cs.caltech.edu Subject: Re: snd_cwnd drawn and quartered Message-ID: <20030114022509.P1516@almesberger.net> References: <20030114010157.M1516@almesberger.net> <200301140502.IAA10733@sex.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200301140502.IAA10733@sex.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Tue, Jan 14, 2003 at 08:02:23AM +0300 X-archive-position: 1551 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wa@almesberger.net Precedence: bulk X-list: netdev Content-Length: 2159 Lines: 50 kuznet@ms2.inr.ac.ru wrote: > Losses in the same window must not result in multiplicative collapse > of cwnd or extension of recovery period. If they do, we are really buggy. Oh, according to NewReno, extending the recovery period is just fine. You just need to stop counting ... And what we have is definitely NewReno-ish, with recovery ending at high_seq. > Which is funny and unexpected, I read the paper only after the implementation > has been mostly finished (based on old Hoe's papers) and just added > some colorful details, sort of this one. :-) That explains why things are so similar but still not quite the same :-)) > It is required to stop all the smartness and to enter RTO timeout, Okay, that makes also the ssthresh/2 fix easier, because it eliminates the one case where the current behaviour is actually right. > I did not get this. This limit is boundary check which you referred to > several sentences above. Not falling under prior_cwnd/2 does not need > a special check, we do not receive more than prior_cnwd ACKs while single > recovery period in any case. Yes yes, we do ... that's what NewReno is all about. Let's say you lose the 0th and the 99th segment (with cwnd = 100). You'll detect the first loss at t = 100, and enter recovery. You leave recovery once snd_nxt (stored in high_seq) at that time has been ack'ed. So this is 100. At time t=199, we find out about the loss of the 99th segment, and retransmit. This gets ack'ed at time t=299. So it's only then when we leave recovery. draft-ratehalving distinguishes the adjustement interval and the repair interval. The latter lasts until we've fixed all losses, while the former should indeed not exceed one RTT. It's this limitation that's missing in Linux. > Huh. We can just shot this silly heuritsics, if it hurts. :-) If you enter RTO upon loss of retransmission, we can, yes. (And we don't even need a new variable ;-) - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From kuznet@ms2.inr.ac.ru Mon Jan 13 22:08:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Jan 2003 22:08:44 -0800 (PST) Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0E68Z3v015593 for ; Mon, 13 Jan 2003 22:08:37 -0800 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id JAA10804; Tue, 14 Jan 2003 09:14:36 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200301140614.JAA10804@sex.inr.ac.ru> Subject: Re: snd_cwnd drawn and quartered To: wa@almesberger.net (Werner Almesberger) Date: Tue, 14 Jan 2003 09:14:36 +0300 (MSK) Cc: netdev@oss.sgi.com, chengjin@cs.caltech.edu In-Reply-To: <20030114022509.P1516@almesberger.net> from "Werner Almesberger" at Jan 14, 3 02:25:09 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 1552 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 1557 Lines: 38 Hello! > > Losses in the same window must not result in multiplicative collapse > > of cwnd or extension of recovery period. If they do, we are really buggy. > > Oh, according to NewReno, extending the recovery period is just fine. Sorry, it is just nonsense in newreno, it is that high_seq makes. Well, and this is surely not fine, losses in several consecutive windows must result in multiplicative reduction of cwnd. > Yes yes, we do ... that's what NewReno is all about. Let's say you > lose the 0th and the 99th segment (with cwnd = 100). You'll detect > the first loss at t = 100, and enter recovery. You leave recovery > once snd_nxt (stored in high_seq) at that time has been ack'ed. So > this is 100. At time t=199, we find out about the loss of the 99th > segment, and retransmit. This gets ack'ed at time t=299. So it's > only then when we leave recovery. I do not understand, what you has just said. You cant discover loss of 99th segment _after_ 100th was happily ACKed. :-) :-) > draft-ratehalving distinguishes the adjustement interval and the > repair interval. The latter lasts until we've fixed all losses, > while the former should indeed not exceed one RTT. It's this > limitation that's missing in Linux. But thit does not matter because it handles opposite case, when cwnd was not reduced enough for one RTT, so rh falls to hold state to decrease cwnd smoothly. It is just an unnecessary complication to my opinion. Did I get this wrong? Picture, Werner! What does happen on picture quarter.eps???? That's question. Alexey From werner@almesberger.net Mon Jan 13 22:31:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Jan 2003 22:31:02 -0800 (PST) Received: from host.almesberger.net (IDENT:22XSBEQfG5vCQqx6pIkHx4hgdlMWQ2Gf@almesberger.net [63.105.73.239] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0E6Ux3v016055 for ; Mon, 13 Jan 2003 22:31:00 -0800 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.9.3/8.9.3) with ESMTP id WAA03478; Mon, 13 Jan 2003 22:37:01 -0800 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id h0E6apC01656; Tue, 14 Jan 2003 03:36:51 -0300 Date: Tue, 14 Jan 2003 03:36:51 -0300 From: Werner Almesberger To: kuznet@ms2.inr.ac.ru Cc: netdev@oss.sgi.com, chengjin@cs.caltech.edu Subject: Re: snd_cwnd drawn and quartered Message-ID: <20030114033651.S1516@almesberger.net> References: <20030114022509.P1516@almesberger.net> <200301140614.JAA10804@sex.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200301140614.JAA10804@sex.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Tue, Jan 14, 2003 at 09:14:36AM +0300 X-archive-position: 1553 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wa@almesberger.net Precedence: bulk X-list: netdev Content-Length: 2829 Lines: 64 kuznet@ms2.inr.ac.ru wrote: > Sorry, it is just nonsense in newreno, it is that high_seq makes. > Well, and this is surely not fine, losses in several consecutive > windows must result in multiplicative reduction of cwnd. This is precisely what NewReno does. If you lose anything within that cwnd, recovery is extended. If you lose something after the cwnd, you'll first finish the old recovery cycle (since snd_una has now passed high_seq), and then enter a new one, with the appropriate reduction of ssthresh and cwnd. > > Yes yes, we do ... that's what NewReno is all about. Let's say you > > lose the 0th and the 99th segment (with cwnd = 100). You'll detect > > the first loss at t = 100, and enter recovery. You leave recovery > > once snd_nxt (stored in high_seq) at that time has been ack'ed. So > > this is 100. At time t=199, we find out about the loss of the 99th > > segment, and retransmit. This gets ack'ed at time t=299. So it's > > only then when we leave recovery. > > I do not understand, what you has just said. You cant discover > loss of 99th segment _after_ 100th was happily ACKed. :-) :-) That would be kind of evil :-) But that's not what I meant. The 100 refers to high_seq, i.e. the segment we need to get ack'ed for leaving recovery. > But thit does not matter because it handles opposite case, when cwnd > was not reduced enough for one RTT, so rh falls to hold state > to decrease cwnd smoothly. It is just an unnecessary complication > to my opinion. Did I get this wrong? Hmm, I think it's like I said. The case of cwnd not getting reduced enough is handled when exiting repair, i.e. section 4.13 and 4.14. Note that those intervals don't have to be explicitly tracked in any way. E.g. the adjustment interval can just be implemented by stopping decrementing cwnd at the new ssthresh. > Picture, Werner! What does happen on picture quarter.eps???? t=0: we have the first loss. At this time, snd_nxt is 100, so we set high_seq accordingly, slash ssthresh, and enter recovery. ~98: we have the last loss within our cwnd (the simulation just stops losing packets at this point. In real life, this transmission should of course be smoother.) 100: we've recovered our initial loss, but snd_una is still below high_seq, because of all the other losses in that cwnd ~200: we recover the last loss, and snd_una finally increases above high_seq, so we leave recovery now. All that is just fine, if I interpret NewReno right. The only problem is that we should have stopped reducing cwnd after the first RTT. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From mika.liljeberg@welho.com Mon Jan 13 22:39:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Jan 2003 22:39:52 -0800 (PST) Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0E6dg3v016495 for ; Mon, 13 Jan 2003 22:39:43 -0800 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h0E6k6xA017906; Tue, 14 Jan 2003 08:46:07 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h0E6k4us017905; Tue, 14 Jan 2003 08:46:04 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: SCTP path mtu support needs some ip layer support. From: Mika Liljeberg To: Sridhar Samudrala Cc: kuznet@ms2.inr.ac.ru, Jon Grimm , davem@redhat.com, netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1042526764.2606.21.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 14 Jan 2003 08:46:04 +0200 X-archive-position: 1554 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mika.liljeberg@welho.com Precedence: bulk X-list: netdev Content-Length: 1083 Lines: 25 On Tue, 2003-01-14 at 02:56, Sridhar Samudrala wrote: > On 14 Jan 2003, Mika Liljeberg wrote: > > > Hi, > > > > I know this is not what the SCTP spec recommends with IPv4, but what > > prevents you from just fragmenting the IP packets at the source and > > setting the DF bit on each fragment (assuming you can't just repackage > > the data chunks)? This would be equivalent to the IPv6 behaviour and > > would keep PMTUD working perfectly. > > SCTP does segment the packets based on the current PMTU and sets DF bit to not > allowing IP fragmentation. The problem occurs when the PMTU shrinks and there > are outstanding segmented packets which need to be retransmitted. We cannot > re-segment these packets, but would like IP to fragment them by not setting > DF bit. Setting DF=0 allows intermediate routers to fragment the packets as well. I was proposing that you allow the IP layer to fragment the packets at source host only, and then set DF=1 on the IP fragments. This should keep PMTUD working nicely, since intermediate routers are not allowed to refragment. MikaL From san19878@rediffmail.com Tue Jan 14 00:53:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Jan 2003 00:53:27 -0800 (PST) Received: from rediffmail.com (webmail10.rediffmail.com [202.54.124.179] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0E8rH3v018786 for ; Tue, 14 Jan 2003 00:53:19 -0800 Received: (qmail 9478 invoked by uid 510); 14 Jan 2003 08:53:06 -0000 Date: 14 Jan 2003 08:53:06 -0000 Message-ID: <20030114085306.9477.qmail@webmail10.rediffmail.com> Received: from unknown (194.175.117.85) by rediffmail.com via HTTP; 14 jan 2003 08:53:06 -0000 MIME-Version: 1.0 From: "santosh kumar" Reply-To: "santosh kumar" To: netdev@oss.sgi.com Subject: IPv6 on MIPS device Content-type: text/plain; format=flowed Content-Disposition: inline X-archive-position: 1556 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: san19878@rediffmail.com Precedence: bulk X-list: netdev Content-Length: 309 Lines: 16 Hi All, I wanna port Linux IPv6 (as a module) onto a MIPS processor based device. I have mipsel-linux-gcc cross compiler. Pls suggest on how to go about this...??? Can i compile only IPv6 code or do i need to compile the entire kernel ??? Thanx in advance. Regds, Santosh ------------------------------- From sri@us.ibm.com Tue Jan 14 10:37:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Jan 2003 10:37:21 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0EIbD3v013655 for ; Tue, 14 Jan 2003 10:37:14 -0800 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e33.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0EIhFoW063292; Tue, 14 Jan 2003 13:43:15 -0500 Received: from dyn9-47-18-98.beaverton.ibm.com (dyn9-47-18-98.beaverton.ibm.com [9.47.18.98]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0EIhD2m091094; Tue, 14 Jan 2003 11:43:14 -0700 Date: Tue, 14 Jan 2003 10:44:54 -0800 (PST) From: Sridhar Samudrala X-X-Sender: To: cc: Sridhar Samudrala , , , Subject: Re: SCTP path mtu support needs some ip layer support. In-Reply-To: <200301140122.EAA10371@sex.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1558 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2506 Lines: 66 On Tue, 14 Jan 2003 kuznet@ms2.inr.ac.ru wrote: > Hello! > > > Is this more agreeable? > > I did not disagree with the first one, actually. :-) > It was cleaner, to be honest. So can i go ahead and add an argument(ipfragok) to ip_queue_xmit()? > > In any case, after reading mail by Jon Grimm, the things > became cleaner. BTW what is "chunk" size in current implementation? The maximum chunksize is set to (pmtu - SCTP+IPheadersizes). > > Essentially, to make a compromise between usability and sanity, > it is enough to make the thing which we make with UDP: to prevent > sending bogus fragmented packets when IP_MTUDISC_DO is set by user > and set chunk size to a value < min(512,current mtu) in this case, > so no fragments will be generated. In that case I will be happy > (done all that possible, all the flaws are directed to SCTP designers. :-)) > and default behaviour (it is IP_MTUDISC_WANT) still will be rfc compliant. You seem to be suggesting the use of lowest possible pmtu as the max. chunk size. This is OK as long as the user messages are of small size. But it adds additional overhead of 16 byte chunk headers for messages that are larger than the chunk size, but lower than the pmtu. So we would like to opt for this solution only if you are totally against adding a new argument to ip_queue_xmit(). Also SCTP uses control chunks(INIT_ACK, COOKIE_ECHO) for association setup which can be larger than pmtu(although rare). The control chunks cannot be fragmented by SCTP, but it is perfectly OK for IP to fragment them. > > > > If not, do you prefer SCTP having its own ip_xmit > > Hey, only not this. :-) > > BTW what did you make with IPv6? We even not have any analogue > to ip_fragment there at the moment. Do not worry, we have to do this > in any case, not depending on SCTP demands. :-) Frankly, i haven't thought of IPV6 in detail. I was under the impression that it is simpler in ipv6 as only source is allowed to do fragmentation and as there is no DF bit, it will automatically fragment any packets larger than the pmtu. But looking at ip6_xmit(), i realize that ICMPV6_PKT_TOOBIG error is generated forcing the transport layer to do the fragmentation. TCP can handle this, but SCTP cannot. So looks like this problem needs to be solved even for ipv6. Is it possible to add an argument to ip6_xmit() to force ip layer to fragment or use any other available interface like ip6_build_xmit() when we want ip to fragment. Thanks Sridhar > > Alexey > > From mika.liljeberg@welho.com Tue Jan 14 12:18:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Jan 2003 12:18:41 -0800 (PST) Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0EKIT3v015473 for ; Tue, 14 Jan 2003 12:18:30 -0800 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h0EKBCxA020966; Tue, 14 Jan 2003 22:11:12 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h0EKB7eW020965; Tue, 14 Jan 2003 22:11:07 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: SCTP path mtu support needs some ip layer support. From: Mika Liljeberg To: Sridhar Samudrala Cc: kuznet@ms2.inr.ac.ru, jgrimm2@us.ibm.com, davem@redhat.com, netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1042575066.2610.26.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 14 Jan 2003 22:11:06 +0200 X-archive-position: 1559 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mika.liljeberg@welho.com Precedence: bulk X-list: netdev Content-Length: 778 Lines: 18 On Tue, 2003-01-14 at 20:44, Sridhar Samudrala wrote: > Frankly, i haven't thought of IPV6 in detail. I was under the impression that > it is simpler in ipv6 as only source is allowed to do fragmentation and as there > is no DF bit, it will automatically fragment any packets larger than the pmtu. > But looking at ip6_xmit(), i realize that ICMPV6_PKT_TOOBIG error is generated > forcing the transport layer to do the fragmentation. TCP can handle this, but > SCTP cannot. IPv6 is simpler, because the specification asserts that every IPv6 capable link must support a MTU of at least 1280 bytes. If you don't generate packets larger than this you don't have to worry about fragmentation. If you want larger data chunks, then you have to solve this for IPv6 as well. MikaL From kuznet@ms2.inr.ac.ru Tue Jan 14 13:10:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Jan 2003 13:10:54 -0800 (PST) Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0ELAl3v016964 for ; Tue, 14 Jan 2003 13:10:48 -0800 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id AAA13616; Wed, 15 Jan 2003 00:16:43 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200301142116.AAA13616@sex.inr.ac.ru> Subject: Re: SCTP path mtu support needs some ip layer support. To: sri@us.ibm.com (Sridhar Samudrala) Date: Wed, 15 Jan 2003 00:16:43 +0300 (MSK) Cc: sri@us.ibm.com, jgrimm2@us.ibm.com, davem@redhat.com, netdev@oss.sgi.com In-Reply-To: from "Sridhar Samudrala" at Jan 14, 3 10:44:54 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 1560 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 1536 Lines: 45 Hello! > So can i go ahead and add an argument(ipfragok) to ip_queue_xmit()? Positive. > > Essentially, to make a compromise between usability and sanity, > > it is enough to make the thing which we make with UDP: to prevent > > sending bogus fragmented packets when IP_MTUDISC_DO is set by user > > and set chunk size to a value < min(512,current mtu) in this case, > > so no fragments will be generated. In that case I will be happy > > (done all that possible, all the flaws are directed to SCTP designers. :-)) > > and default behaviour (it is IP_MTUDISC_WANT) still will be rfc compliant. > > You seem to be suggesting ... Nope. Reread the paragraph and look how UDP in IP_MTUDISC_DO mode works. (The case of IPv6 is especially intersting) Adding similar mode to SCTP is necessary to my opinion. Despite of the fact that nobody will use the option, it is the only sane one. > Also SCTP uses control chunks(INIT_ACK, COOKIE_ECHO) for association setup > which can be larger than pmtu(although rare). The control chunks cannot be > fragmented by SCTP, but it is perfectly OK for IP to fragment them. :-) Funnier and funnier. Oh, god... > is no DF bit, it will automatically fragment any packets Strange expectation. :-) TCP does not make this even in IPv4, when pmtu discovery enabled. SCTP is really born crippled. Face it. And be ready to breed an invalid. :-) > available interface like ip6_build_xmit() when we want ip to fragment. Do not worry. We have to do this in ip6_xmit() for ipsec in any case. Alexey From sri@us.ibm.com Tue Jan 14 14:07:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Jan 2003 14:07:51 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0EM7l3v018767 for ; Tue, 14 Jan 2003 14:07:48 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0EMDokm124558; Tue, 14 Jan 2003 17:13:50 -0500 Received: from dyn9-47-18-98.beaverton.ibm.com (dyn9-47-18-98.beaverton.ibm.com [9.47.18.98]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0EMDkk4165674; Tue, 14 Jan 2003 17:13:46 -0500 Date: Tue, 14 Jan 2003 14:15:27 -0800 (PST) From: Sridhar Samudrala X-X-Sender: To: Mika Liljeberg cc: Sridhar Samudrala , , , , Subject: Re: SCTP path mtu support needs some ip layer support. In-Reply-To: <1042575066.2610.26.camel@devil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1561 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1161 Lines: 27 On 14 Jan 2003, Mika Liljeberg wrote: > On Tue, 2003-01-14 at 20:44, Sridhar Samudrala wrote: > > Frankly, i haven't thought of IPV6 in detail. I was under the impression that > > it is simpler in ipv6 as only source is allowed to do fragmentation and as there > > is no DF bit, it will automatically fragment any packets larger than the pmtu. > > But looking at ip6_xmit(), i realize that ICMPV6_PKT_TOOBIG error is generated > > forcing the transport layer to do the fragmentation. TCP can handle this, but > > SCTP cannot. > > IPv6 is simpler, because the specification asserts that every IPv6 > capable link must support a MTU of at least 1280 bytes. If you don't > generate packets larger than this you don't have to worry about > fragmentation. > > If you want larger data chunks, then you have to solve this for IPv6 as > well. Yes. If we restrict the max. data chunksize to 1280 bytes for ipv6 and 576 bytes for ipv4, we could have avoided ip fragmentation alltogether. But this will add unnecessary overhead of sctp fragmentation/reassembly and additional chunk headers when the real pmtu is much larger and the messages are big. Thanks Sridhar From scott.feldman@intel.com Wed Jan 15 00:00:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Jan 2003 00:00:22 -0800 (PST) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0F80J3v031429 for ; Wed, 15 Jan 2003 00:00:20 -0800 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h0F83rd23720 for ; Wed, 15 Jan 2003 08:03:53 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h0F88Ux12880 for ; Wed, 15 Jan 2003 08:08:30 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003011500081010553 ; Wed, 15 Jan 2003 00:08:10 -0800 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Jan 2003 00:06:28 -0800 Message-ID: From: "Feldman, Scott" To: Jeff Garzik , netdev@oss.sgi.com, linux-net@vger.kernel.org Cc: davem@redhat.com Subject: RE: NAPI vs. interrupts Date: Wed, 15 Jan 2003 00:06:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" X-archive-position: 1563 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev Content-Length: 1475 Lines: 38 > NAPI driver _always_ does > ack some irqs > mask irqs > ack some more irqs > process events > unmask irqs e1000+NAPI is this path. > The purpose of this email is to solicit suggestions to > develop a strategy to fix what I believe is a problem with NAPI. > > Here are some comments of mine: > > 1) Can this problem be alleviated entirely without driver > changes? For example, would it be reasonable to do > pkts-per-second sampling in the net core, and enable software > mitigation based on that? > > 2) Implement hardware mitigation in addition to NAPI. Either > the driver does adaptive sampling, or simply hard-locks > mitigation settings at something that averages out to N pkts > per second. I've tried something similar to this while playing around with e1000 recently. Using ITR (InterruptThrottleRate), dial in a max intr/sec rate of say 4000 intr/sec, and then just call netif_rx_schedule() for each interrupt. Don't mask/unmask interrupts. If already polling, netif_rx_schedule does nothing. The code differences between the NAPI path and non-NAPI path was minimal, so I liked that, and your worst case is gone. If you look at the average size of the Rx packets, you could fine tune ITR to get a pkt/intr rate to balance your quota to try to maximize the amount of time spent polling, but this is too fancy for my taste. Anyway, worst case, 2*4000 PIO writes/sec was the savings, but I can't say I could measure a difference. -scott From scott.feldman@intel.com Wed Jan 15 00:25:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Jan 2003 00:25:48 -0800 (PST) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0F8Pi3v032441 for ; Wed, 15 Jan 2003 00:25:45 -0800 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h0F8QPj22903 for ; Wed, 15 Jan 2003 08:26:25 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h0F8Xt125441 for ; Wed, 15 Jan 2003 08:33:56 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003011500333517697 for ; Wed, 15 Jan 2003 00:33:35 -0800 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Jan 2003 00:31:54 -0800 Message-ID: From: "Feldman, Scott" To: netdev@oss.sgi.com Cc: "Cramer, Jeb J" Subject: Flush Tx skbs after link down Date: Wed, 15 Jan 2003 00:31:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" X-archive-position: 1564 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev Content-Length: 589 Lines: 14 Someone most know the answer to this: What's the proper way to dispose of Tx skbs that are owned by the h/w ("in-flight") when link was lost? Lets say your h/w stops Tx processing when link is lost, but you've got apps waiting for those Tx resources to be returned. h/w isn't giving those resources back until link is up. Bonding doesn't like this. We've tried walking the h/w list, and skb_orphan'ing the skbs, but that only works if the usage count = 1. The other solution is to tear down and rebuild the Tx ring, but that requires a h/w reset to recover. Yuk! Any ideas? -scott From vda@port.imtp.ilyichevsk.odessa.ua Wed Jan 15 00:33:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Jan 2003 00:33:21 -0800 (PST) Received: from Port.imtp.ilyichevsk.odessa.ua (169.imtp.Ilyichevsk.Odessa.UA [195.66.192.169] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0F8XD3v000370 for ; Wed, 15 Jan 2003 00:33:16 -0800 Received: from there ([172.16.42.177]) by Port.imtp.ilyichevsk.odessa.ua (8.10.2/8.10.2) with SMTP id h0F86Ts05193; Wed, 15 Jan 2003 10:06:29 +0200 Message-Id: <200301150806.h0F86Ts05193@Port.imtp.ilyichevsk.odessa.ua> Content-Type: text/plain; charset="koi8-r" From: Denis Vlasenko Reply-To: vda@port.imtp.ilyichevsk.odessa.ua To: jt@hpl.hp.com, Jean Tourrilhes Subject: Re: 2.4.20-pre11: PCI Wavelan card loses connection Date: Wed, 15 Jan 2003 10:06:04 +0200 X-Mailer: KMail [version 1.3.2] Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <200301130821.h0D8Kis26772@Port.imtp.ilyichevsk.odessa.ua> <20030113172435.GC20409@bougret.hpl.hp.com> In-Reply-To: <20030113172435.GC20409@bougret.hpl.hp.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-archive-position: 1565 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vda@port.imtp.ilyichevsk.odessa.ua Precedence: bulk X-list: netdev Content-Length: 1707 Lines: 43 On 13 January 2003 19:24, Jean Tourrilhes wrote: > On Mon, Jan 13, 2003 at 10:20:14AM +0200, Denis Vlasenko wrote: > > I bought a PCI wireless card, a DLink-520 (I think, I forgot > > exactly (it's at home), anyway, lspci dump is below). > > > > We (my father and me) made a fairly long helical aerial. > > We are trying to communicate over ~15 km with a small wireless > > cell. (~10 hosts, one AP). > > > > We can successfully associate with it, signal is weak as expected. > > But after a short while our eth0 seems to 'fall off the net' > > and while it looks like we can send packets, we see no incoming > > data at all. > > > > Since I have almost zero wireless experience, I'll be happy if > > someone with said experience can read further and say what bites > > us. > > Personally, I never managed to get this hardware to work at > all. And Orinoco is known to have problems with PrismII cards. Please > use the HostAP or linux-wlan-ng driver. Count me in. I want to make it work. It's not a Prism II, it says Prism I. It is a D-Link DWL-520 PCI card. Does that matter? By the way, I wouldn't want to admit it, but it works much better under Win98 (ick). It cycles between "Associated: (mac addr)" and "Scanning..." for _several minutes_ before giving up. And ping is working all this time. Under Linux, average time before failure is 20 sec :( I presume card is considering AP to be too weak and try to find a better one. There isn't any. How can I disable this reassociation or lower reassociation threshold? At the very least, how can I see whether it is associated or scanning? Pointers to 802.1b docs? (I am googling in parallel...) Meanwhile will download and look into HostAP. -- vda From srompf@isg.de Wed Jan 15 02:17:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Jan 2003 02:17:13 -0800 (PST) Received: from mail.isg.de (rzfoobar.is-asp.com [217.11.194.155]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FAGu3v005086 for ; Wed, 15 Jan 2003 02:16:57 -0800 Received: from barkeeper.isg.de (barkeeper.is-asp.com [192.168.5.46]) by mail.isg.de (Postfix) with ESMTP id 4E0AFF604DD; Wed, 15 Jan 2003 10:50:33 +0100 (CET) Received: from isg.de (localhost.localdomain [127.0.0.1]) by barkeeper.isg.de (8.9.3/8.9.3) with ESMTP id KAA01041; Wed, 15 Jan 2003 10:50:33 +0100 Message-ID: <3E252EE9.D8CA8EDC@isg.de> Date: Wed, 15 Jan 2003 10:50:33 +0100 From: Stefan Rompf X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.20-rc4-neu i686) X-Accept-Language: en MIME-Version: 1.0 To: "Feldman, Scott" Cc: netdev@oss.sgi.com, "Cramer, Jeb J" Subject: Re: Flush Tx skbs after link down References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1566 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: srompf@isg.de Precedence: bulk X-list: netdev Content-Length: 514 Lines: 13 Hi, > Someone most know the answer to this: What's the proper way to dispose > of Tx skbs that are owned by the h/w ("in-flight") when link was lost? I think this can't be achieved without driver support, simply because pending DMA transfers must be removed before freeing the skbs, and this is specific. So the driver model needs to be extended to have a reset method similiar to the qdiscs. If available, this method is called on link down event by the linkwatch stuff included in recent 2.5 kernels. Stefan From srompf@isg.de Wed Jan 15 02:33:47 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Jan 2003 02:33:49 -0800 (PST) Received: from mail.isg.de (rzfoobar.is-asp.com [217.11.194.155]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FAXa3v006747 for ; Wed, 15 Jan 2003 02:33:36 -0800 Received: from barkeeper.isg.de (barkeeper.is-asp.com [192.168.5.46]) by mail.isg.de (Postfix) with ESMTP id ABDE6F68C82; Wed, 15 Jan 2003 10:57:42 +0100 (CET) Received: from isg.de (localhost.localdomain [127.0.0.1]) by barkeeper.isg.de (8.9.3/8.9.3) with ESMTP id KAA01049; Wed, 15 Jan 2003 10:57:42 +0100 Message-ID: <3E253096.9F9DB6FE@isg.de> Date: Wed, 15 Jan 2003 10:57:42 +0100 From: Stefan Rompf X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.20-rc4-neu i686) X-Accept-Language: en MIME-Version: 1.0 To: "Feldman, Scott" , netdev@oss.sgi.com, "Cramer, Jeb J" Subject: Re: Flush Tx skbs after link down References: <3E252EE9.D8CA8EDC@isg.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1567 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: srompf@isg.de Precedence: bulk X-list: netdev Content-Length: 451 Lines: 12 > I think this can't be achieved without driver support, simply because > pending DMA transfers must be removed before freeing the skbs, and this > is specific. So the driver model needs to be extended to have a reset PS: We also need to avoid that new skbs are enqueued while the link is down without making the critical code path in dev_queue_xmit() much longer. Right now, I don't have any ideas beyond a proof of concept for this part. Stefan From kuznet@ms2.inr.ac.ru Wed Jan 15 09:45:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Jan 2003 09:45:22 -0800 (PST) Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FHjH3v022271 for ; Wed, 15 Jan 2003 09:45:19 -0800 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id UAA15907; Wed, 15 Jan 2003 20:50:50 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200301151750.UAA15907@sex.inr.ac.ru> Subject: Re: snd_cwnd drawn and quartered To: wa@almesberger.net (Werner Almesberger) Date: Wed, 15 Jan 2003 20:50:50 +0300 (MSK) Cc: netdev@oss.sgi.com, chengjin@cs.caltech.edu In-Reply-To: <20030114033651.S1516@almesberger.net> from "Werner Almesberger" at Jan 14, 3 03:36:51 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 1570 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 706 Lines: 24 Hello! > This is precisely what NewReno does. If you lose anything within > that cwnd, recovery is extended. Werner, where did you get this information? In that case recovery will not finish. :-) > 100 refers to high_seq, i.e. the segment we need to get ack'ed > for leaving recovery. I still do not understand. Apparently it is based on assumption of extension of high_seq which must not happen. > 100: we've recovered our initial loss, but snd_una is still > below high_seq, because of all the other losses in that > cwnd This must not happen. I did not mean this in code and cannot see how it can happen. high_seq is set once while single recovery cycle. Something is buggy. Alexey From werner@almesberger.net Wed Jan 15 10:18:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Jan 2003 10:19:00 -0800 (PST) Received: from host.almesberger.net (IDENT:8daMfab0mOGjpqoheUtG3jggCpyBel1r@almesberger.net [63.105.73.239] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FIIv3v030513 for ; Wed, 15 Jan 2003 10:18:57 -0800 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.9.3/8.9.3) with ESMTP id KAA14288; Wed, 15 Jan 2003 10:25:08 -0800 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id h0FIP4r03483; Wed, 15 Jan 2003 15:25:04 -0300 Date: Wed, 15 Jan 2003 15:25:04 -0300 From: Werner Almesberger To: kuznet@ms2.inr.ac.ru Cc: netdev@oss.sgi.com, chengjin@cs.caltech.edu Subject: Re: snd_cwnd drawn and quartered Message-ID: <20030115152504.B1521@almesberger.net> References: <20030114033651.S1516@almesberger.net> <200301151750.UAA15907@sex.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200301151750.UAA15907@sex.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Wed, Jan 15, 2003 at 08:50:50PM +0300 X-archive-position: 1571 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wa@almesberger.net Precedence: bulk X-list: netdev Content-Length: 1417 Lines: 40 kuznet@ms2.inr.ac.ru wrote: >> This is precisely what NewReno does. If you lose anything within >> that cwnd, recovery is extended. > > Werner, where did you get this information? In that case recovery > will not finish. :-) Maybe I used the wrong word. The sequence number we're waiting for (high_seq) doesn't change, of course. But the recovery takes longer than just one RTT, because it takes longer for snd_una to reach high_seq - due to the second loss. And because recovery takes longer than one RTT, we decrement cwnd too much. >> 100: we've recovered our initial loss, but snd_una is still >> below high_seq, because of all the other losses in that >> cwnd > > This must not happen. I did not mean this in code and cannot see > how it can happen. high_seq is set once while single recovery cycle. > Something is buggy. Yes, high_seq is set only once. That's okay. It's snd_una that (correctly) takes more than one RTT to reach high_seq. 1) tcp_enter_loss sets high_seq = snd_nxt. At that time (t = 0), snd_una is 0, snd_nxt is 100. 2) tcp_fastretrans_alert tries to exit recovery only if snd_una reaches high_seq Am I reading this right ? - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From kuznet@ms2.inr.ac.ru Wed Jan 15 10:37:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Jan 2003 10:37:40 -0800 (PST) Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FIbU3v031059 for ; Wed, 15 Jan 2003 10:37:32 -0800 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id VAA16069; Wed, 15 Jan 2003 21:43:29 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200301151843.VAA16069@sex.inr.ac.ru> Subject: Re: snd_cwnd drawn and quartered To: wa@almesberger.net (Werner Almesberger) Date: Wed, 15 Jan 2003 21:43:29 +0300 (MSK) Cc: netdev@oss.sgi.com, chengjin@cs.caltech.edu In-Reply-To: <20030115152504.B1521@almesberger.net> from "Werner Almesberger" at Jan 15, 3 03:25:04 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 1572 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 440 Lines: 17 Hello! > Am I reading this right ? Yes, most likely. Dumb me understood you finally. :-) We receive some amount of dupacks for segments >high_seq, before ACK for retransmitted 99th segment arrives and terminates recovery. You meaned this, right? :-) Yup, this is bug. OK, this case is sorted out. I think that small fix proposed by you is enough for beginning. Ough... another weirdness with cwand drained to 1 still remains. Alexey From werner@almesberger.net Wed Jan 15 11:31:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Jan 2003 11:31:06 -0800 (PST) Received: from host.almesberger.net (IDENT:EOBV1jjmyDw5ekQ7sFf+i+yNw+Xfbyr1@almesberger.net [63.105.73.239] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FJV43v002034 for ; Wed, 15 Jan 2003 11:31:04 -0800 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.9.3/8.9.3) with ESMTP id LAA14657; Wed, 15 Jan 2003 11:37:15 -0800 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id h0FJbBq03892; Wed, 15 Jan 2003 16:37:11 -0300 Date: Wed, 15 Jan 2003 16:37:11 -0300 From: Werner Almesberger To: kuznet@ms2.inr.ac.ru Cc: netdev@oss.sgi.com, chengjin@cs.caltech.edu Subject: Re: snd_cwnd drawn and quartered Message-ID: <20030115163711.C1521@almesberger.net> References: <20030115152504.B1521@almesberger.net> <200301151843.VAA16069@sex.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200301151843.VAA16069@sex.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Wed, Jan 15, 2003 at 09:43:29PM +0300 X-archive-position: 1573 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wa@almesberger.net Precedence: bulk X-list: netdev Content-Length: 727 Lines: 21 kuznet@ms2.inr.ac.ru wrote: > We receive some amount of dupacks for segments >high_seq, before ACK > for retransmitted 99th segment arrives and terminates recovery. You meaned > this, right? :-) Yes, that's it. > Yup, this is bug. OK, this case is sorted out. I think that small fix > proposed by you is enough for beginning. I think, in addition to this fix, you also need to do RTO upon loss of retransmission. Otherwise, my fix would make you halve cwnd only once in this case. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From mika.liljeberg@welho.com Thu Jan 16 04:58:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Jan 2003 04:58:30 -0800 (PST) Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0GCwN3v029126 for ; Thu, 16 Jan 2003 04:58:25 -0800 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h0DN3MxA015658; Tue, 14 Jan 2003 01:03:22 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h0DN3Jwr015657; Tue, 14 Jan 2003 01:03:19 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: SCTP path mtu support needs some ip layer support. From: Mika Liljeberg To: Sridhar Samudrala Cc: kuznet@ms2.inr.ac.ru, Jon Grimm , davem@redhat.com, netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1042498998.2610.8.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 14 Jan 2003 01:03:19 +0200 X-archive-position: 1577 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mika.liljeberg@welho.com Precedence: bulk X-list: netdev Content-Length: 493 Lines: 17 Hi, I know this is not what the SCTP spec recommends with IPv4, but what prevents you from just fragmenting the IP packets at the source and setting the DF bit on each fragment (assuming you can't just repackage the data chunks)? This would be equivalent to the IPv6 behaviour and would keep PMTUD working perfectly. With IPv6 you don't have a DF bit to control, so you have only two options. Either use a maximum chunk size smaller than 1280, or fragment at the source. Regards, MikaL From christopher.leech@intel.com Thu Jan 16 15:48:51 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Jan 2003 15:48:57 -0800 (PST) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0GNmo3v008354 for ; Thu, 16 Jan 2003 15:48:51 -0800 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h0GNnae29529 for ; Thu, 16 Jan 2003 23:49:36 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h0GNoC505567 for ; Thu, 16 Jan 2003 23:50:12 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003011615530928867 for ; Thu, 16 Jan 2003 15:53:09 -0800 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jan 2003 15:55:06 -0800 Message-ID: From: "Leech, Christopher" To: netdev@oss.sgi.com Subject: skb_padto length wrong when nonlinear Date: Thu, 16 Jan 2003 15:54:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-archive-position: 1578 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: christopher.leech@intel.com Precedence: bulk X-list: netdev Content-Length: 1005 Lines: 28 The recently introduced skb_padto calculates the size of an sk_buff as skb->len + skb->data_len. My understanding was that the total length is in fact skb->len, and the linear portion needs to be calculated as skb->len - skb->data_len (as done by skb_headlen). It looks like skb_padto could mistakenly fail to linearize and 0-pad a buffer when (skb->len < len) && (skb->len + skb->data_len >= len). I realize this is an unlikely situation, but for the sake of correctness. - Chris Leech diff -ur linux-2.5/include/linux/skbuff.h b/include/linux/skbuff.h --- linux-2.5/include/linux/skbuff.h 2003-01-13 12:45:20.000000000 -0800 +++ b/include/linux/skbuff.h 2003-01-16 15:02:20.000000000 -0800 @@ -1102,7 +1102,7 @@ static inline struct sk_buff *skb_padto(struct sk_buff *skb, unsigned int len) { - unsigned int size = skb->len + skb->data_len; + unsigned int size = skb->len; if (likely(size >= len)) return skb; return skb_pad(skb, len-size); From ipv6_san@rediffmail.com Thu Jan 16 20:42:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Jan 2003 20:42:42 -0800 (PST) Received: from rediffmail.com (webmail16.rediffmail.com [203.199.83.26] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0H4gX3v012569 for ; Thu, 16 Jan 2003 20:42:35 -0800 Received: (qmail 15095 invoked by uid 510); 17 Jan 2003 04:41:49 -0000 Date: 17 Jan 2003 04:41:49 -0000 Message-ID: <20030117044149.15094.qmail@webmail16.rediffmail.com> Received: from unknown (194.175.117.86) by rediffmail.com via HTTP; 17 jan 2003 04:41:49 -0000 MIME-Version: 1.0 From: "santosh kumar gowda" Reply-To: "santosh kumar gowda" To: netdev@oss.sgi.com Subject: Linux kernel for MIPS device Content-type: text/plain; format=flowed Content-Disposition: inline X-archive-position: 1579 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ipv6_san@rediffmail.com Precedence: bulk X-list: netdev Content-Length: 140 Lines: 7 Hi All, I want to compile the entire Linux Kernel 2.4.20 for MIPS architecture. Can any one suggest me from where to start with...?? -San From garzik@gtf.org Fri Jan 17 08:22:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Jan 2003 08:22:07 -0800 (PST) Received: from havoc.gtf.org (havoc.daloft.com [64.213.145.173]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0HGM33v009123 for ; Fri, 17 Jan 2003 08:22:04 -0800 Received: by havoc.gtf.org (Postfix, from userid 500) id CE6C8664A; Fri, 17 Jan 2003 11:28:18 -0500 (EST) Date: Fri, 17 Jan 2003 11:28:18 -0500 From: Jeff Garzik To: linux-kernel@vger.kernel.org, Florian Lohoff Cc: netdev@oss.sgi.com Subject: Re: eepro100 - 802.1q - mtu size Message-ID: <20030117162818.GA1074@gtf.org> References: <20030117145357.GA1139@paradigm.rfc822.org> <20030117160840.GR12676@stingr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030117160840.GR12676@stingr.net> User-Agent: Mutt/1.3.28i X-archive-position: 1582 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev On Fri, Jan 17, 2003 at 07:08:40PM +0300, Paul P Komkoff Jr wrote: > Replying to Florian Lohoff: > > Why is this patch not integerated yet ? > > Because newer and better e100 driver, which accepts tagged frames and > handles it properly, already in the tree Regardless, people still use eepro100, so I would still like to get eepro100 doing VLAN. The reason why the patch was not accepted is that it changes one magic number to another magic number, and without chipset docs, I had no idea what either magic number really meant. Now that Intel has released chipset docs, this is an excellent time to re-evaluate those eepro100 VLAN changes. I still refuse to accept a "change the magic numbers" patch... any change will need to define a constant that describes the bits we wish to set/clear. Download the e100 documentation from the e1000 sourceforge site: http://sourceforge.net/projects/e1000 ["8255x Developer Manual"] Jeff From ralf@linux-mips.org Fri Jan 17 08:23:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Jan 2003 08:23:07 -0800 (PST) Received: from dea.linux-mips.net (p508B675B.dip.t-dialin.net [80.139.103.91]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0HGN33v009352 for ; Fri, 17 Jan 2003 08:23:04 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id h0HGTGf10182; Fri, 17 Jan 2003 17:29:16 +0100 Date: Fri, 17 Jan 2003 17:29:16 +0100 From: Ralf Baechle To: santosh kumar gowda Cc: netdev@oss.sgi.com Subject: Re: Linux kernel for MIPS device Message-ID: <20030117172916.A10136@linux-mips.org> References: <20030117044217.9814.qmail@webmail18.rediffmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030117044217.9814.qmail@webmail18.rediffmail.com>; from ipv6_san@rediffmail.com on Fri, Jan 17, 2003 at 04:42:17AM -0000 X-archive-position: 1583 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: netdev On Fri, Jan 17, 2003 at 04:42:17AM -0000, santosh kumar gowda wrote: > I want to compile the entire Linux Kernel 2.4.20 > for MIPS architecture. > Can any one suggest me from where to start with...?? Take such questions to linux-mips@linux-mips.org, netdev isn't the place for them ... Ralf From davej@codemonkey.org.uk Fri Jan 17 09:23:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Jan 2003 09:23:34 -0800 (PST) Received: from noodles.internal (noodles.codemonkey.org.uk [213.152.47.19]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0HHNQ3v010354 for ; Fri, 17 Jan 2003 09:23:27 -0800 Received: from noodles.internal (davej@localhost [127.0.0.1]) by noodles.internal (8.12.7/8.12.7/Debian-2) with ESMTP id h0HHRJBN031974; Fri, 17 Jan 2003 17:27:19 GMT Received: (from davej@localhost) by noodles.internal (8.12.7/8.12.7/Debian-2) id h0HHRJVE031972; Fri, 17 Jan 2003 17:27:19 GMT X-Authentication-Warning: noodles.internal: davej set sender to davej@codemonkey.org.uk using -f Date: Fri, 17 Jan 2003 17:27:19 +0000 From: Dave Jones To: Jeff Garzik Cc: linux-kernel@vger.kernel.org, Florian Lohoff , netdev@oss.sgi.com Subject: Re: eepro100 - 802.1q - mtu size Message-ID: <20030117172719.GA31343@codemonkey.org.uk> Mail-Followup-To: Dave Jones , Jeff Garzik , linux-kernel@vger.kernel.org, Florian Lohoff , netdev@oss.sgi.com References: <20030117145357.GA1139@paradigm.rfc822.org> <20030117160840.GR12676@stingr.net> <20030117162818.GA1074@gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030117162818.GA1074@gtf.org> User-Agent: Mutt/1.4i X-archive-position: 1584 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davej@codemonkey.org.uk Precedence: bulk X-list: netdev On Fri, Jan 17, 2003 at 11:28:18AM -0500, Jeff Garzik wrote: > The reason why the patch was not accepted is that it changes one magic > number to another magic number, and without chipset docs, I had no idea > what either magic number really meant. Whilst on the subject of magic numbers in net drivers, did we ever get to the bottom of 2.4's ChangeSet 1.587.9.20 ftp://ftp.kernel.org/pub/linux/kernel/people/davej/patches/2.5/2.5.48/split-dj1/net-cs89x0-media-corrections.diff ? Dave -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs From poup@poupinou.org Fri Jan 17 09:42:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Jan 2003 09:42:30 -0800 (PST) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0HHgN3v011272 for ; Fri, 17 Jan 2003 09:42:25 -0800 Received: from poup by poup.poupinou.org with local (Exim) id 18Zaba-000125-00; Fri, 17 Jan 2003 18:48:34 +0100 Date: Fri, 17 Jan 2003 18:48:34 +0100 To: Jeff Garzik Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: eepro100 - 802.1q - mtu size Message-ID: <20030117174834.GF12522@poup.poupinou.org> References: <20030117145357.GA1139@paradigm.rfc822.org> <20030117160840.GR12676@stingr.net> <20030117162818.GA1074@gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030117162818.GA1074@gtf.org> User-Agent: Mutt/1.4i From: Ducrot Bruno X-archive-position: 1585 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: poup@poupinou.org Precedence: bulk X-list: netdev Hi Jeff, On Fri, Jan 17, 2003 at 11:28:18AM -0500, Jeff Garzik wrote: > On Fri, Jan 17, 2003 at 07:08:40PM +0300, Paul P Komkoff Jr wrote: > > Replying to Florian Lohoff: > > > Why is this patch not integerated yet ? > > > > Because newer and better e100 driver, which accepts tagged frames and > > handles it properly, already in the tree > > Regardless, people still use eepro100, so I would still like to get > eepro100 doing VLAN. > > The reason why the patch was not accepted is that it changes one magic > number to another magic number, and without chipset docs, I had no idea > what either magic number really meant. > > Now that Intel has released chipset docs, this is an excellent time to > re-evaluate those eepro100 VLAN changes. I still refuse to accept a > "change the magic numbers" patch... any change will need to define > a constant that describes the bits we wish to set/clear. > > Download the e100 documentation from the e1000 sourceforge site: > http://sourceforge.net/projects/e1000 > ["8255x Developer Manual"] > > Jeff BTW, it look like i82557_config_cmd is never used... --- linux-2.4/drivers/net/eepro100.c 2003/01/17 17:33:41 1.1 +++ linux-2.4/drivers/net/eepro100.c 2003/01/17 17:34:32 @@ -499,11 +499,13 @@ /* The parameters for a CmdConfigure operation. There are so many options that it would be difficult to document each bit. We mostly use the default or recommended settings. */ +#if 0 static const char i82557_config_cmd[CONFIG_DATA_SIZE] = { 22, 0x08, 0, 0, 0, 0, 0x32, 0x03, 1, /* 1=Use MII 0=Use AUI */ 0, 0x2E, 0, 0x60, 0, 0xf2, 0x48, 0, 0x40, 0xf2, 0x80, /* 0x40=Force full-duplex */ 0x3f, 0x05, }; +#endif static const char i82558_config_cmd[CONFIG_DATA_SIZE] = { 22, 0x08, 0, 1, 0, 0, 0x22, 0x03, 1, /* 1=Use MII 0=Use AUI */ 0, 0x2E, 0, 0x60, 0x08, 0x88, -- Ducrot Bruno http://www.poupinou.org Page profaissionelle http://toto.tu-me-saoules.com Haume page From garzik@gtf.org Fri Jan 17 09:43:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Jan 2003 09:43:16 -0800 (PST) Received: from havoc.gtf.org (havoc.daloft.com [64.213.145.173]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0HHhD3v011553 for ; Fri, 17 Jan 2003 09:43:13 -0800 Received: by havoc.gtf.org (Postfix, from userid 500) id 98A0C664C; Fri, 17 Jan 2003 12:49:28 -0500 (EST) Date: Fri, 17 Jan 2003 12:49:28 -0500 From: Jeff Garzik To: Dave Jones , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Cc: alan@redhat.com, akpm@digeo.com Subject: cs89x0 in 2.5 (was Re: eepro100 - 802.1q - mtu size) Message-ID: <20030117174928.GA8304@gtf.org> References: <20030117145357.GA1139@paradigm.rfc822.org> <20030117160840.GR12676@stingr.net> <20030117162818.GA1074@gtf.org> <20030117172719.GA31343@codemonkey.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030117172719.GA31343@codemonkey.org.uk> User-Agent: Mutt/1.3.28i X-archive-position: 1586 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev On Fri, Jan 17, 2003 at 05:27:19PM +0000, Dave Jones wrote: > On Fri, Jan 17, 2003 at 11:28:18AM -0500, Jeff Garzik wrote: > > > The reason why the patch was not accepted is that it changes one magic > > number to another magic number, and without chipset docs, I had no idea > > what either magic number really meant. > > Whilst on the subject of magic numbers in net drivers, did we ever get > to the bottom of 2.4's ChangeSet 1.587.9.20 > > ftp://ftp.kernel.org/pub/linux/kernel/people/davej/patches/2.5/2.5.48/split-dj1/net-cs89x0-media-corrections.diff IIRC it came from -ac tree without explanation, and I think akpm said it broke stuff. Since it has an alive maintainer (akpm), I would rather let Alan and Andrew fight it out :) Whatever they decide is fine with me for 2.5. Jeff From flo@rfc822.org Fri Jan 17 11:19:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Jan 2003 11:19:41 -0800 (PST) Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0HJJb3v000357 for ; Fri, 17 Jan 2003 11:19:38 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 38ACE25E05; Fri, 17 Jan 2003 20:25:51 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 14BA2B2AB; Fri, 17 Jan 2003 20:25:43 +0100 (CET) Date: Fri, 17 Jan 2003 20:25:43 +0100 From: Florian Lohoff To: Jeff Garzik Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: eepro100 - 802.1q - mtu size Message-ID: <20030117192542.GA2515@paradigm.rfc822.org> References: <20030117145357.GA1139@paradigm.rfc822.org> <20030117160840.GR12676@stingr.net> <20030117162818.GA1074@gtf.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline In-Reply-To: <20030117162818.GA1074@gtf.org> User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication X-archive-position: 1587 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: flo@rfc822.org Precedence: bulk X-list: netdev --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 17, 2003 at 11:28:18AM -0500, Jeff Garzik wrote: > Regardless, people still use eepro100, so I would still like to get > eepro100 doing VLAN. >=20 > The reason why the patch was not accepted is that it changes one magic > number to another magic number, and without chipset docs, I had no idea > what either magic number really meant. I did the basic decoding of the config block - The result from looking at the gdb output is the same except the IP ARP Filter basic address which is now the documentations recommended default value and some mandatory bits which are filled. I also set the LONGRCV option which enables to use VLANs. I tried this patch which is against 2.4.20 with IPv4, IPv6, 802.1q and DHCP so i'd say full feature test ;). I did not try 82557 which might need different initialization as some bits are unused but that problem persists from before this change. --- drivers/net/eepro100.c-vanilla Fri Jan 17 20:18:17 2003 +++ drivers/net/eepro100.c Fri Jan 17 20:19:39 2003 @@ -496,19 +496,66 @@ #endif }; =20 -/* The parameters for a CmdConfigure operation. - There are so many options that it would be difficult to document each b= it. - We mostly use the default or recommended settings. */ -static const char i82557_config_cmd[CONFIG_DATA_SIZE] =3D { - 22, 0x08, 0, 0, 0, 0, 0x32, 0x03, 1, /* 1=3DUse MII 0=3DUse AUI */ - 0, 0x2E, 0, 0x60, 0, - 0xf2, 0x48, 0, 0x40, 0xf2, 0x80, /* 0x40=3DForce full-duplex */ - 0x3f, 0x05, }; +#define i55x_CB1_TXFIFO_LIMIT(x) ((x)<<4) +#define i55x_CB1_RXFIFO_LIMIT(x) ((x)&0xf) + +#define i55x_CB3_MWIENABLE (1<<0) + +#define i55x_CB6_EXTSTATCOUNT (1<<5) +#define i55x_CB6_MANDBITS (1<<1) + +#define i55x_CB7_DISCARDSHORT (1<<0) +#define i55x_CB7_UNDERRUNRETRY(x) ((x)<<1) + +#define i557_CB8_USEMII (1<<0) +#define i558_CB8_MANDBITS i557_CB8_USEMII + +#define i55x_CB10_MANDBITS (3<<1) +#define i55x_CB10_PREAMBLELEN(x) ((x&3)<<4) +#define i55x_CB10_NSAI (1<<3) + +#define i55x_CB12_INTERFRAMESPACE(x) ((x)<<4) + +#define i558_CB15_MANDBITS (1<<3|1<<6) +#define i559_CB16_CRC16 (1<<5) + +#define i558_CB18_MANDBITS (1<<7) +#define i558_CB18_FCTHRESH(x) ((x&7)<<4) +#define i558_CB18_LONGRCV (1<<3) +#define i55x_CB18_PAD (1<<1) + +#define i558_CB19_TXFC (1<<2) +#define i558_CB19_AUTOFDX (1<<7) + +#define i558_CB20_PRIFCLOC (1<<5) +#define i558_CB20_MANDBITS (0x1f) + +#define i558_CB21_MANDBITS (0x05) + static const char i82558_config_cmd[CONFIG_DATA_SIZE] =3D { - 22, 0x08, 0, 1, 0, 0, 0x22, 0x03, 1, /* 1=3DUse MII 0=3DUse AUI */ - 0, 0x2E, 0, 0x60, 0x08, 0x88, - 0x68, 0, 0x40, 0xf2, 0x84, /* Disable FC */ - 0x31, 0x05, }; + CONFIG_DATA_SIZE,=09=09=09=09 + i55x_CB1_TXFIFO_LIMIT(0)|i55x_CB1_RXFIFO_LIMIT(8),=09 + 0,=09=09 + i55x_CB3_MWIENABLE, + 0,=09=09=09 + 0,=09=09=09=09 + i55x_CB6_EXTSTATCOUNT|i55x_CB6_MANDBITS, + i55x_CB7_UNDERRUNRETRY(1)|i55x_CB7_DISCARDSHORT, + i558_CB8_MANDBITS,=09=09=09=09 + 0, + i55x_CB10_MANDBITS|i55x_CB10_NSAI|i55x_CB10_PREAMBLELEN(2), + 0, + i55x_CB12_INTERFRAMESPACE(6), + 0x00, /* cb 13 - ARP Filter IP Address Low */ + 0xf2, /* cb 14 - ARP Filter IP Address High */ + i558_CB15_MANDBITS|i559_CB16_CRC16,=09=09=09 + 0, /* cb 16 - FC Delay - LSB */ + 0x40, /* cb 17 - FC Delay - MSB */ + i558_CB18_MANDBITS|i558_CB18_FCTHRESH(7)|i558_CB18_LONGRCV|i55x_CB18_PAD, + i558_CB19_TXFC|i558_CB19_AUTOFDX,=09=09 + i558_CB20_PRIFCLOC|i558_CB20_MANDBITS, + i558_CB21_MANDBITS, + }; =20 /* PHY media interface chips. */ static const char *phys[] =3D { --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --AhhlLboLdkugWU4S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD4DBQE+KFi2Uaz2rXW+gJcRAo+SAJ9qjM5WAq9RGxrHVsZALQPqn2H90ACWOIYf mB/dbT2H7tITukJnCP9R/w== =Shzu -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- From mauro@deepspace6.net Sat Jan 18 07:03:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 18 Jan 2003 07:03:20 -0800 (PST) Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0IF3G3v016030 for ; Sat, 18 Jan 2003 07:03:18 -0800 Received: from trantor.ferrara.linux.it (151.26.185.94) by smtp1.libero.it (6.7.015) id 3E0C7171008548E4; Sat, 18 Jan 2003 16:09:25 +0100 Received: by trantor.ferrara.linux.it (Postfix, from userid 501) id 0DEFA2CD16; Sat, 18 Jan 2003 09:54:12 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id D95052CD13; Sat, 18 Jan 2003 15:54:12 +0100 (CET) Date: Sat, 18 Jan 2003 15:54:12 +0100 (CET) From: Mauro Tortonesi X-X-Sender: mauro@trantor.ferrara.linux.it To: Deep Space 6 Development Mailing List , USAGI Users Mailing List , Linux Kernel Networking Stack Development Mailing List Subject: IPv6 packet forging Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1589 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mauro@deepspace6.net Precedence: bulk X-list: netdev Content-Length: 540 Lines: 17 hi to everybody, i am writing an IPv6 packet forger for linux. until now, to inject packets on the net i have used link layer sockets, but i'd like to know if there are more portable ways to perform the same task. do you know if there is a BPF port for linux? or can i inject packets using tun/tap driver? -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@deepspace6.net mauro@ferrara.linux.it Deep Space 6 - IPv6 on Linux http://www.deepspace6.net Ferrara Linux Users Group http://www.ferrara.linux.it From yoshfuji@linux-ipv6.org Sat Jan 18 08:02:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 18 Jan 2003 08:02:42 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0IG2c3v016732 for ; Sat, 18 Jan 2003 08:02:40 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian -4) with ESMTP id h0IG98GR032303; Sun, 19 Jan 2003 01:09:08 +0900 Date: Sun, 19 Jan 2003 01:09:08 +0900 (JST) Message-Id: <20030119.010908.127619438.yoshfuji@linux-ipv6.org> To: usagi-users@linux-ipv6.org, mauro@deepspace6.net Cc: ds6-devel@deepspace6.net, netdev@oss.sgi.com Subject: Re: (usagi-users 02099) IPv6 packet forging From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1590 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 343 Lines: 9 In article (at Sat, 18 Jan 2003 15:54:12 +0100 (CET)), Mauro Tortonesi says: > packets on the net i have used link layer sockets, but i'd like to know if > there are more portable ways to perform the same task. do you know if How about libpcap? --yoshfuji From bunk@fs.tum.de Sat Jan 18 09:13:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 18 Jan 2003 09:13:47 -0800 (PST) Received: from hermes.fachschaften.tu-muenchen.de (hermes.fachschaften.tu-muenchen.de [129.187.202.12]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0IHD43v018416 for ; Sat, 18 Jan 2003 09:13:14 -0800 Received: (qmail 28977 invoked from network); 18 Jan 2003 17:19:24 -0000 Received: from mimas.fachschaften.tu-muenchen.de (129.187.202.58) by hermes.fachschaften.tu-muenchen.de with QMQP; 18 Jan 2003 17:19:24 -0000 Date: Sat, 18 Jan 2003 18:19:22 +0100 From: Adrian Bunk To: Pedro Roque Cc: netdev@oss.sgi.com Subject: [2.5 patch] remove an unneeded #if from net/ipv6/af_inet6.c Message-ID: <20030118171921.GJ10647@fs.tum.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 1591 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@fs.tum.de Precedence: bulk X-list: netdev Content-Length: 673 Lines: 25 The patch below removes an unneeded #if from net/ipv6/af_inet6.c: - kernel 2.0 is too ancient to check for - the MODULE_* macros have empty definitions #if !MODULE I've tested the compilation with 2.5.59. Please apply Adrian --- linux-2.5.59-full/net/ipv6/af_inet6.c.old 2003-01-18 18:11:08.000000000 +0100 +++ linux-2.5.59-full/net/ipv6/af_inet6.c 2003-01-18 18:11:38.000000000 +0100 @@ -67,11 +67,9 @@ module for allowing unload */ #endif -#if defined(MODULE) && LINUX_VERSION_CODE > 0x20115 MODULE_AUTHOR("Cast of dozens"); MODULE_DESCRIPTION("IPv6 protocol stack for Linux"); MODULE_PARM(unloadable, "i"); -#endif /* IPv6 procfs goodies... */ From chengjin@cs.caltech.edu Sat Jan 18 22:48:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 18 Jan 2003 22:48:53 -0800 (PST) Received: from swordfish.cs.caltech.edu (swordfish.cs.caltech.edu [131.215.44.124]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0J6mn3v025755 for ; Sat, 18 Jan 2003 22:48:50 -0800 Received: from orchestra.cs.caltech.edu (orchestra.cs.caltech.edu [131.215.44.20]) by swordfish.cs.caltech.edu (Postfix) with ESMTP id DB91CDF263; Sat, 18 Jan 2003 22:55:16 -0800 (PST) Received: from localhost (chengjin@localhost) by orchestra.cs.caltech.edu (8.11.6/8.9.3) with ESMTP id h0J6tGI29202; Sat, 18 Jan 2003 22:55:16 -0800 X-Authentication-Warning: orchestra.cs.caltech.edu: chengjin owned process doing -bs Date: Sat, 18 Jan 2003 22:55:16 -0800 (PST) From: Cheng Jin To: , Cc: "netdev@oss.sgi.com" Subject: example showing how cwnd gets to one In-Reply-To: <20030114010157.M1516@almesberger.net> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-679275476-1114011982-1042958518=:28820" Content-ID: X-archive-position: 1592 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chengjin@cs.caltech.edu Precedence: bulk X-list: netdev Content-Length: 31567 Lines: 535 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. ---679275476-1114011982-1042958518=:28820 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hi Alexey, Sorry about the delay in getting you the example. I wanted to clean up the output/code a little bit. I have attached the tar ball of the source code of the simulator plus an example showing how cwnd goes from 200 to 1. It's under 20% random packet loss. You might laugh because the loss rate is "unrealistically" high, but on long latency paths, this can happen if the bottleneck queue is not very large. If you only care about ack/packets sent, please do a 'grep ">>>" file' on the example file. I have included the TCP recovery state variable to make things clear in the output. maize is the sender, and blue is the receiver in the simulation. tcp_time_stamp in the simulation is kept in rounds/windows of packets i.e., 0 correspondes to the first round where first loss happens, instead of jiffies. Thanks, Cheng Lab # 626 395 8820 ---679275476-1114011982-1042958518=:28820 Content-Type: APPLICATION/X-GZIP; NAME="example.tgz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="example.tgz" H4sIAJJHKj4AA+19a3cct5Wtv5K/oqSMPaQkUlWot2hq4iROJmsyzizbuXPv crKYFtmUekR10+ymLSf2/PYLoF7AAapQIIEusIleK7FYja7X3sDG4+yD8x+X F2fR2fzj7MP11fwTK58wCsMsST4JwyRP0hT/N8rTKML/xf+KUZpH8SdhnkUo SeIkwcejJErRJ0Fo53b4z+16M7sJgk/O382Xb/9nsewrt5xvflzdvF9v4562 +DnH+J+iMHwRXK3W67Prm9Wb0zjcX8+XF/ObYLFcbBazq8U/5hfHx8f7N/Pz +eIH8fjvvvzNX/7wKrg5/+H74/M333+X/+14Pf8+OA2Ooif7m8WH+Wm4/wy/ wACf/ny+Xs8vguv3myAJ8GU2wa/xl7qf/V9HL4Kbzcfvj7+/nd/O60egN1Af iF8E+Irtn1GZ7YfBenb+vrr4+kUQkkfe1H/Mlhf4wO3y/XL14zLAnNjcrp/s 73+Y4Wes/3y1v8Z15XY5O8WXIv9cftxU1323ePvuDD9x/SLxd/Sh8S1e4Vuq XwD5BX3bUVlWv1+vN+9u5ut3pxH52TW5t836bHW7aQHZ0L/weaobp3/hB7ua X1bfJPiZ55ub2XLdFLxkzoKvebOhR282q9N4f//N1W33MPjO6BOE3F3qI9Gi nrCon7+5PnpNXgm+RXLZ4/ZyT/Zfv34d/DoKWjYBVthgQ+LZsB021NjW7UeH LL6R4Lvw5+RvRtCNFOjmltCN9NHN1ehGvegmDLrpILrJVtBVN/SRrKFPjTb0 KvBtVe3HDn6Leipt6FPdhj61wYbUs2E7bFA09KmZhh4p0LXV0CMr6KJedFMG 3WwQ3dSRhh7JGvrMaEOvAt9W1X7s4LeoZ9KGPtNt6DMbbMg8G7bDBkVDn1lp 6F1GN7sPuhmDbj6IbuZIQx+PKJPIxKCwKQYCQRJPELtiUEjFoNAVg8IGG3LP hu2wQSEGhRkxiBXoppbQja2gG/eimzPoFoPoFo6IQSpr6EujDb0KfFtV+7GD 36JeShv6UrehL22wofBs2A4bFA19aaWhdxnd9D7oFgy65SC6pSMNfSZr6KPQ ZksvoB979O229FEobeqjULetj6wQovSE2A4hFI09pokReBMFvLZa+8QKvEkv vCUDL6lLA/hG21mVV7f3ubS9j4y29yr8bVVvj3/X4kfyFj/SbvEjG5Qgb8tz wolIHcyU7SDsUKuf6CGMOITJk3UQIx5iBCCOHGn2C2mzj2w2+07X8V1jQNfw I3nDj7QbfmSFFJEnxdZIoWr5kZmWP1VBbKvlT61AnPZDHLEQx8MQI0da/nJM MKc0bD8yG7evpAnyNLEvD/Lg/Ug7ej8yE74PSYE8KbZGCpU8GIrhf0gQx/eC GLEQJ8MQOxPHH40pJA0CjcxGgSp5Enqe2NcHeShopB0LGpkJBoWkENx+nhST 6YOhiNBMBXFkCeLMCsRZP8Sshy9KhyF2JSo0iqVNf2606VdSwFYt9xRgmv5c 3vTn2k1/boUUgv/Pk2Kypj+30/QLEDvU9CM9iGMeYtbVF4EA3xhAnLvS9Euj /SOz4f4PqZbvGgW6pl8e8x9pB/1HZqL+ISkER6AnxWRNv6HQ/1wFsa2mP7cC cd4PMevzi4phiF0J/4/SMYWksaPIbOyoiidF6XliXR+QPH4UacePIjukgCZB T4rJ9AEZiiFVQWytC3AHiCM9iBMeYtb6h0DEWMJDjFyJIsV9kRGFpEFHyGzQ kbIpKDxP7OuDPOgIaQcdITNBR5AU0FvoSTGdPhgKOipUENvqAhRWIC76IWYd gygahtiVoKOolDb9sdGmX0kBW7XcU4Bp+mN50x9rN/2xFVJAs6EnxXRNf2yn 6RcgdqjpD/UgTnmIWf8gAjFjKYA4dqTpx92MEYWk6UOR2fyhSp7YSiroecLo gzyJKNLOIorMpBGFpIDmRE+K6fTBUC5RJcTudAGKETnBWYgzHmLWbIhA4EAG IHYmn6g0lhSZjSV9QLV85yjQNf3yWFKkHUuKzMSSAlIg6E/0pJiu6TcUS/qQ IC7uAzFi3YYoG4bYlVhSNCbFKJJGHSGzUUdKntjKPOh5wuiDPOoIaUcdITNR R5AU0KDoSTGdPhiKOlJCbCv99B0gHpFcnIU45yFm7YYIBA7kAGJXoo7QmKgj JI06is1GHSl5YsvS7nnS6UMsjzqKtaOOYjukgAZFT4rJ9CE2FHX0kCAekYZ2 AGLWbojKQYhjV6KO0JioIySNOorNRh0peWLL0+55wuiDPOoo1o46is1EHUFS QBejJ8V0+mAn6kiE2FY2qztAPCKNIQtxwUPMehJjEF1QAIhdiTpC0qij2GrU kdO1fNco0DX98qijWDvqKLYSdYSgi9GTYrqm307UkQixQ03/iExVLMQlDzHr SYxB4EAJIHYl6igeE3UUj8l1hFk7opA0K0ZsNiuGinG5O3FuO8e4TmnkWTFi 7awYsZmsGJAU0A/pSTGd0hjKiqGCuLBlfbsDxCMSn7AQkyS5LMasvTGGu12H AGRX8mLE0hXq2O4Ktcv1fPdI0DX/8jXqWHuNOrazRg3tjp4WUwqApVVqwdPq kACMsLdzIEc8yKx/MYYbn0YAZFfWqWPp7pix2e0xH1JN3z0SdAIg3yUz1t4m MzazTyakBTQ9elpMKQCGtstUgeySAGiaGCM+9yFiXYwx3CMPJD+MXdk0M5bG ICV2Y5Bcrum7R4IW/UQehZRoRyEldmgBXY2eFhMKQGIpDkmwrjokAJouxYjP cIVYm2ICFpQikOIqcSUSKZZuo5mY3UbzIdX03SNBJwDyrTTJbWoKgJmtNCEt oLfR02JKATC0m2apANmaAJRWQC4HQGbNiglSgOzKfpp4vDmikDQeKTEbj6Ri Sm7L7e6ZwqmEPCIp0Y5ISsxEJAFaxNDh6GkxpUoYikl6QCDnIxztAyCTR+tA jhUguxKVlIyJSkqkuZASs7mQlEyxZXz0TOFUQp4NKdHOhpSYyYYEaQF9jp4W U6qEmXxIZK18GGRLSTHIhc2DTPfZ7gOZNS4miQJkVzIiJWMiTpMxuTMSaWRS YjQySU0nSx5JT6dnnJTII5MS7cikxEhkkkALaIn0tJhSSsxEJqlBtpQi5S4g qy3wPMh8+sSY9TgmMPoA5NdNXIlMSqSRSYnRyKQHVdN3jwSdAMgjkxLtyKTE SGSSQAtojPS0mFIAzEQmqUHeHQFgnY4JSIISgQS6iSuRSYk0Mik1Gpn0mGq6 gyRo0U/lkUmpdmRSaocWgl/R02I6AUjNRCapQXZIANRJTniQ+SyJMWtAJJWK AxmkSUxdiUxKxuRISsasXifS1evU6Oq1mk6WEid4Oj3jpES+ep1qr16nRlav BVoI7kdPiwmlxMzqtRpkSxk17gKyOmkKDzKfMCtmvYwpDFEAGbNSV1av0zGr 1+mYnBqpdM+H1OieD2o6WQqZ83R6xkmJfNeHVHvXh9TIrg8CLQQfpafFhFJi Zt8HNciROyCrbfE8yHxalJh1RabQFg8ycKWu7PyQSvMlpUbzJT2omr57JOgE QJ4xKdXOmJQayZgk0ELwUXpaTCgAZnImqUHeHQFgXZEp2LwjAomxUldyJqXS yKTUbmTSDtd0B0nQCYA8MinVjkxK7UQmCT5KT4sJBcBSZJIAskMCoM6LwoFM tmtiQWZdkSlYfCJlOZBdiUxKpZFJqd3IJJdr+u6RoBMAeWRSqh2ZlNqJTBIs kp4WEwqApcgkAWSHBECdF4UHmU+MFbOGxwwsGSGQGCt1JTIplUYmZXYjk1yu 6btHghb9TB6ZRG5TTwAyK7QguZs8LbZGC4UAZHYik5wGObwXyOTROpCjYZAz VyKTUmnOpMxoziQlCTJLyXE8CZ5xAiDPmURuU1MAjORMEmgBPYueFlMKgJmc SSQl7CDI1gQgsgJyNAAy60DMkAJkV3ImpdKdOTOjO3MqSWCtpnsScAIg35sz 096bMzOyN6dAC+hZ9LSYUgDM7M75kEDORljQh0BmHYhZrADZlf05U6mjIDPr KFCSwFJOLE+CZ5wAyB0FmbajIDPjKIC0gJ5FT4spBcCQowCpQLYlAMgKyGgA ZNaBmCUKkF1xFGRjHAXZGEdBJnUUZGYdBUo6WcqO5un0jJMSuaMg03YUZGYc BZAW0LPoaTGllBhyFDwkkIv7gcw6ELNUAbIrjoJsTD68TBp1mpmNOlUyxVba A88UTiXkUaeZdtRpZibqFNIC2hE9LaZUCUNRp0qQbWXDuAPII1KecCDzmzEl rLkwAzmvENiMKXMl6hS//xGFpJFJudnIJCVTbJndPVNYlcjlkUm5dmRSbocW 0LPoaTGhSuSGIpOUIDvUFRiRzYQDmU+Nm7AOxAxs2YdAatzclcikbEzOpGxM zqRMusKRm13hUNLJVqSzpxMnJfIVjlx7hSM3s8IBaQHdj54WU0qJpRUOAWRb ibHuAHKiCTKfYzFhvYw5jGMASXZzV1Y48jErHLl0x5/c6I4/aqbYiobzTOFU Qr7jT669409uZMcfgRbQIulpMaVKGNrxRwmyQ12BEY53DmQ+fWLCGh5zuEIF MvHmruz4k0tXr3O7q9cu1/TdI0GHvnz1Otdevc7trF5Di6SnxZQCYGn1WgDZ IQEY4XjnQOaTHias4TEHKU8QyJ+bu7J6nUvz4eVm8+E9pJq+eyTo0Jfnw8u1 8+HlZvLhAVqkgkXS02JCATCUD+8hgRzdC+SUNTzmcF0JguxKPrw8GVNImjMp N5szScWU1FZgvGcKpxLynEm5ds6k3EzOJEgL6KP0tJhSJQzlTFKC7JBfYoQr kgO54EFmXZE5XDICudFzV3Im5dLIpMJqZJLTNX33SNCiX8gjkwrtyKTCDi2g j9LTYkIBKOxEJrkMcqprZQEgs65IUqmGQC5ciUzKpTmTCrM5k5QkyD0JtiEA 8pxJRaQtAGZyJkFaQPejp8WUAmAoZ5IS5N0RANbLSCoVBzLYHKNwJWdSLs2Z VJjNmfSIarqDJOgEQJ4zqdDOmVSYyZkEaQGNjZ4WUwqAoZxJSpAdEgBdmyK/ OUbK2hQLmBcFbI5RuJIzKZc6CgqrjgKna/rukaATALmjoNB2FBRWHAUp9Cx6 WkwpAIYcBbEKZFsCEFsBOR4AmXUgFjAeDILsiqOATOdKBCAxKgBKEtiq6Z4E nAAkcgFItAUgsUIL6DT0tJhSABI7AuAyyCMs6EMgs77BAiYqgSAnrgjAmHx4 hdRRUJh1FCiZYivbiWcKpxJyR0Gh7SgozDgKIC2g09DTYkqVMOQoSFQg28qH l1gBORkAmfUNFjBqGILsiqOgkDoKCrOOAiUJbNV0TwJOAOSOgkLbUVCYcRRA WkCnoafFlAJgyFHwkEAekV5kCGTWN1jAgGAIsiuOgkKa67Qwm+tUSQJbmaw8 CTgBkOc6LbRznRZmcp1CWkCnoafFlAJgKNdpqgLZlgCkVkBOB0BmfYMF3EUb guxKrtNC6hYrzLrFlCSwVdM9CTgBkLvFCm23WGHGLQZokQkmQk+LCQXAkFtM CbJDApDqgRyHHMgZawksQUAwKcuB7IpbDI83RxSSOgpKs44CJVNsZTX2TGFV opQ7CkptR0FpxlEAaSE4DT0tplOJ0pCjIFOBbKsrkFkBORsAmfUNltEwyKUr joJC6igozToKlCSwVdM9CTgBkDsKSm1HQWnGUQBpITgNPS0mFABDjoKHBPKI DLNDILO+wRIpQHbFUVBIHQWlWUeBkgS28pR7EnACIHcUlNqOgtKMowDSQnAa elpMKACGHAW5CmRbApBbATkfAJn1DZaxAmRXHAWl1FFQmnUUKElgq6Z7EnAC IHcUlNqOgtKMowDSQnAaelpMKACGHAVKkB0SgFgT5IgHmfUNliAgmJTlQHbF UVBK958pze4/85Bq+u6RoBMA+f4zpfb+M6WZ/WcgLQSnoafFhAJgaP+ZQgWy LQEorIBcDIDM+gbLTAGyK/vPlFK3WGnWLaYkga2a7knACYDcLVZqu8VKM24x SAvBROhpMaEAGHKLPSSQR+wxMQQyawkscwXIrrjFSqlbrDTrFlOSwNYmRJ4E nADI3WKltlusNOMWg7QQTISeFhMKgCG3WKkC2ZYAlFZALgdAZi2BZaEA2RW3 WCl1i5Vm3WJKEtiq6Z4EnADI3WKltlusNOMWg7QQTISeFhMKgCG32EMCObof yKwlsCwVILviFsPjzRGFxjgKSqmjIArNWgpUfEpspSn0fGK1BMMqFRN8XFdN 8E+sMANaEj0zJpQTwhcTKKNQhbKlrcrIhc2jTM7aizLrMKQ/HYKZ1CJHFEVq LIhCo84CNQ8s1XbPgwoRRgnk5gJ8XF8JjNgLIDfy0HNjq9xQaoEZh8GDwjm8 F87k0RicoY9EwNkVj0Ep9RhEoVGTgZoHljLXeh5UiDBaIPcZ4OP6WmDEaSBw I/Lc2Co3lFpgxmygxtkdLUjUmxTxOCMe54jDGUYUI4izK3YD/JRyMTBqOHhI FX4nicCIgdxzgI/ri4ER14HADehG9NyYWAzMGA/UODskBur9KnicYx5nxOEM o4tjiLMr1gM66SsTA6PmgwdV4XeRCIwYyP0H9E51xcCIA0HgBnQmem5MLAZm TAgoUuFsSwwiKzhHAzjHHM4w0ljA2RUbAp33lYmBUSOCmgi2KrwnAkWEEQO5 F4Heqa4YGHEjCNyALkXPjYnFwIwh4UHhrN6iYhDnhMMZRh0LOLtiSaATvzIx MGpKUBPB0j5GnggVIowYyH0J9E51xcCIM0HgBnQsem5MLAZmzAkIqXC2JQb6 +1qPwRkN4JxyOMMIZAFnV+wJdOJXJgZGDQpqItiq8J4IFBFGDOQeBXqnumJg xKUgcAO6Fz03JhYDM0aFB4WzeuuKQZwzDmcYPyzg7IpVgYxFx5TKpJIRhVYl Q6CLpfTmni4VIp1kRKFcMqJQWzIiO9yAfkfPjWklAzPGCM6xCmdLG+GQC1vA OR7AmTUw0po1iDOuR65IRj6qVDGqlDyYNTIbzKoklSXHvCdVhQgjLD3BrJF+ MGtkJpgVckMwP3puTCsshoJZlThbypt3F5zV+2PwOCc8zgWHM8yPnkCcnQlm jeTBrJHZYNaHVOF3kQiMGPQEs0b6wayRmWBWyA3BAem5Ma0YGApmTVQ42xID /U21x+CcDODMuRkjGLQs4OxMMGskD2aNzAazKolgq8J7IlBEGDHoCWaN9INZ IzPBrIAbRei5sVVuKMXAUDCrEmeHxEC9bwaPc8rhTB6NwRkGLacQZ2eCWSM0 qpQ8yikyG+WkpIul7FueLhUijGT0RDlF+lFOkZkoJ8gNwSjpuTGtZBiKclLi 7FDXINbEOeNx5kyPEYxmyyDOzkQ5RfIop8hslNNDqvC7SARGDHqinCL9KKfI TJQT5IZglPTcmFYMDEU5PSSc1Tl3B3HmTI8RjGYTcHYmyonMCMjEoLQqBgIR Qk+ELYlB2SMGpb4YlFa4IRglPTemFYPSjBikKpxtiUFqBed0AGfO9BjBODUB 59IZMZAHsyKzwaxKItiq8J4IFJFODFBPMCvSD2ZFdrghGCU9NyYVA2QomFWJ s0NiEGninPM4c6ZH6vZkcc4BzsiZYNZIvsMCMrrDwoOq8LtIBEYMevZYIHeq KwZG9lgQuCEYJT03phUDQ7ssZCqcbYlBZgXnbABnzvSIYGyZgLMruyzQiV+Z GJjdZkFJBFsV3hOBIsKIQc82C0h/mwVkZpsFyA3BAum5Ma0YGNpm4SHhHN4P Z87OiGBsmYCzK9sskLHoiFJI7llAZj0LKrrEtvIterpQRBjJ6PEsIH3PAjLj WYDcgOZGz42JJcOQZyFX4Wxrl7bcCs75AM6cUZEunQ3i7IxnAXdSxpSSZ2ZF ZjOzKuliKxGXpwtFhJGMnsysSD8zKzKTmRVyA1ogPTcmlgxDmVkfEM7xiL05 hnDm7IwIhiMLODuTmRXFo0rJg1mR2WBWJV1s5V7xdKGIMJLRE8yK9INZkZlg VsgNaJT03JhYMgwFsypxtpWy7w44j0jazuFc8DhzpkcEg5YLiLMzwaxIHsyK zAazPqQKv4tEYMSgJ5gV6QezIjPBrIAbJbRAem5MLAaGglmVODskBiPy9HI4 lxzOJWdnRDBOrYQ4OxPMiuTBrLHZYNaHVOF3kQidGMQ9wayxfjBrbIcb0ALp uTGtGMSGglkLFc62xKCwgnMxgDNnZyQ1axDn2JlgViQPZo3NBrMqiWCrwnsi UEQYMegJZo31g1ljM8GskBvQAum5MbEYGApmVeLskBiMyJrL4kxXnBicOTtj DOLUSGEeZ2eCWdGoBNxoVJRTLI9yis1GOSlJZSsRlycVRYQRlp4op1g/yik2 E+UEuQHtlJ4bEwuLoSinUoWzrX0+Sis4lwM4c9bIOFbh7EyUUyzPzBqbzcyq JIKtCu+JQBFhxKAnM2usn5k1NpOZFXID2ik9NyYWA0OZWR8SziMy8A7hzFkj 40SFszOZWWN5MGtsNphVSQRb+RY9ESgijBj0BLPG+sGssZlgVsgNaKf03JhY DAwFsypxdkgMRuTW5XCOeJw5aySpWRzOEcTZmWDWWJ6AOzabgPshVfhdJAIj Bj0JuGP9BNyxmQTckBuCUdJzY1oxMJSAW4mzQ2IwIrcuhzPiceZMjzFIp0gK 8zg7k4A7lnsWYrOehYdU4XeRCIwY9HgWYn3PQmzGswC5IVggPTemFQMzngW6 9j6IsyUxIBc2jzM5ay/OnJ0xLlU4O+NZiOWehdioZ0FNBEsV3hOhQoQRgx7P QqzvWYiNeBYEbgjmRs+NacXAjGfhQeGszq07iDNnVExCFc7OeBbwWHRMKXkw a2I0mFVNF0uJuDxdKkQ6yUh6glkT/WDWxEgwq8ANwQLpuTGpZCRmgllJtPQw zpYys5ILW8A5GsCZszOSmjWIc+JMMGs8Kpg1HhXMmoSjSsmjnBKjUU5K6iFL GVo89SpEGPnpiXJK9KOcEiNRTpAb9HV7cmyRHEr9MRPmNAJoSykc7wJ0pAl0 zAFNSzNIw4C2GCLtTKBTIg90SowGOj2sOr+TVGAUoSfUKdEPdUqMhDqJ7IDW S8+OqSXBTLDTCKQdkoRQE+kEIM05KROQcIuU5pF2JtwpGZW7L0lGlUpHlZJn +0iNZvsYQT5LJhxPvhqTToTSnnwfaagtQqkldkCbpmfHxCKUmsn4MQJpS27+ OyCN1Hm+eKQzgDTnukxgBEUKkE6dyfmRyJdJUrPLJA+p0u8mFRhJ6FkoSfUX SlIzCyUCO6BZ07Njakmws1QiQdohSVAneOGRzgHSnPcyhYticO/a1JnFkmTU YkkyarEklWf+SI1m/hhBK1tRG55WFSaMvPTk/kj1c3+kRnJ/iOyA9k/Pjqnl xUz2jxFI2wrlvQPSajMnj3QJkObcnCmc4IR55lNn8n+k8pXx1OrKuNuVfiep wEhCz9p4qr82nlpaG4cmUM+OqSXB1uK4gPQOSQLn6UyhwR9mm0+dWRxP5Yvj qeXF8V2u9E5SgZGEnsXxVH9xPLW0OA6toJ4dU0uCrcVxAWmHJEHt8ueQJiM+ DmnO2ZlCmz9MM5w6sziejlocT0ctjqdy92Bq1j2oppWteH9PqwoTRl56/IOp vn8wNeMfFNgBzaWeHVPLiyEHoRppd/wgaIRVlEM6AkhzXtEUrGYRXvBIO+Mh TOWRUJnlSCiXK/1OUqGThKwnEirTj4TKLLEDmkc9OyaWhMxWJJTLSGtacQSk OS9oWiqQzpyJhErlkVCZ5UgoSIWo9FTYliT0REJl+pFQmaVIKGjo9OyYWhJs RUIJ1l2HJCHSRBoBpDl7JqldHNIRRNqZSKh0VCQUmSGQCUdsVziEpsEdS89u EoYRjrhHOGJ94YitsCMKPTu2yw6lcMR2hENE2qEugqZ/JgUmTvJsDNIgdCGF vn5clxwRjkwe9prZDXt1utLvJBUYSegJe830w14zO2GvUeTZsV12KCXBUtir iPQOSULEIQ1CF1Lo68+cCXvN5GGvmd2w152u9E5SgZGEnrDXTD/sNbMT9hpB G6Znx9SSYCns1WWko/KeSHOWyixVIe1M2GsmD3vN7Ia9ilRwJ+vPblKBkYSe sNdMP+w1sxP2GkHrpGfH1JJgKexVRNohSdB02acg8UrE2SCzHCANE69kzoS9 ZqPCXjP53kiZ0b2RRhAm84TZlnD07I6U6e+OlBnZHUlkBzRYenZMLRyG9kd6 UEhr+ucFpDmzZAbj1ASkndkhKZN7HDK7HgeRCu7kb9lNKjCS0ONxyPQ9Dpkd j0MEDZaeHVNLgiGPA1IibUsSkBWk0RDSnFkyg3FqAtLOeBwyucchN+txUFPB VqX3VKgw6SQh7/E45Poeh9wSO6Ap0rNjYknIDXkcHhTS2T2R5gyOpHYNIp07 43HI8lGlCrlwILvCIRDGlg3fE6bChBEO1CMcSF84kB12QOukZ8fUwoEsCYeA tK3sv3dAekTiFQ7pFCDN2SBJ7eKQhtl/cV1yRTjkHofcrMfhQVX6naQCIwk9 Hodc3+OQm/E4COwQrJOeHRNLgiGPw4NCekSylEGkORtkDkOXBaSd8Tjko/ZB zaNRpeSRULnZSCg1rWx5Lj2tKkwYeemJhMr1I6FyM5FQAjsEg6Vnx8TyYigS So20rQxNd0B6ROIVDmmw30jEmSVzGPMGE8LnzkRCkU6jTBJyu5LgcqXfSSow kpD3SEKuLwm5FXYgwWDp2TGxJOR2JMFppEckXhlCGnFmyTxTIZ07IwnysNfc bNirkgqhLTelp0KFCSMJPWGvuX7Ya24m7FVgBzRYenZMLQmGwl6VSLskCZEm 0mDbKMSZJXMYzQb3CMmdCXvN5WGvudmw1wdV6XeSCowk9IS95vphr7mZsFeB HdBg6dkxtSRYCnsVkHZJEkJNpAuANGeWLGBQAtwjJHcm7BWPTMeUkmd7Lcxm e1U3DbY8l54wFSadcBQ92V6LSFs4CjPZXgV2QIOlZ8fEwlEYyvYaK5G21UWI rSAdDyHNmSVJ7RpEunAm22suD3stzIa9qqlgq9J7KlSYMJLQE/Za6Ie9FmbC XgV2QIOlZ8fUkmAo7PUhIR2OSLwyiDRnlixgNJuAtDNhr7k87LUwG/aqpoKt HDyeChUmjCT0hL0W+mGvhZmwV4Ed0GDp2TG1JBgKe02USNuShMQK0skQ0pxZ soARaALSzoS9FvLU3oXZ1N5qKtiq9J4KFSaMJPSk9i70U3sXZlJ7C+yA1knP jqklwVBqbzXSDknCiCxbHNJgV3LE2SALGIEGt40tnEntXchTexdmU3s/qEq/ k1RgJKEntXehn9q7MJPaW2AHtE56dkwtCYZSe6dKpG1JQmoF6XQIac4GWcAI NAFpZ1J7F3JDW2HW0Kamgq1K76lQYcJIQo+hrdA3tBVmDG0CO6Dd0bNjakkw ZGh7UEiPyLI1iDRnXSxgLl4BaWcMbcWo1N6F3ONQmPU4qAljK1mXJ0yFCSMc PR6HQt/jUJjxOAjsgKZIz46phcOQxyFTIm0rj2tmBelsCGnO4FjA0GUBaWc8 DrizMqaUPNtraTbbq5owtpJ1ecJUmHTCUfZkey1DbeEo7bAjFqyTnh3TCkdp KNvrg0J6RHrGIaRjzgZZwLy+EOnSmWyvxahsr4U87LU0G/aqJgzyhNmWcPSE vZb6Ya+lmbBXgR2CwdKzY2LhMBT2qkbaVmq/OyA9Iokji3QWAqQ5s2QJApxJ aR5pZ8JeC3nYa2k27PVBVfqdpAIjCT1hr6V+2GtpJuxVYIdgnfTsmFgSDIW9 qpF2SBJGJF7kkI4A0pwNsgTRbKQ0j7QzYa/lqGyvpTwSqjQbCaUmjK38jZ4w FSaMcPREQpX6kVClmUgogR2CwdKzY2LhMBQJpUbaoS7CiPSMHNIIIM2ZJUsQ 80ZK80g7EwlVyiOhSrORUA+q0u8kFRhJ6ImEKvUjoUozkVACOwSDpWfHxJJg KBLqQSE9Ij3jINKcWbLMVEg7EwlVylN7l2ZTe6upYCtZl6dChQkjCT2pvUv9 1N6lmdTeAjsEg6Vnx8SSYCi1d65E2pYk5FaQzoeQ5sySZa5C2pnU3mUyqtSY SCj8pmXyYjYOSkWq0pYHx3OqgqQlgDwIqi8ECvXpyp1ogZS0yDwttGiRmxAV 1CMq+c9Hd8vnJ+AcbhHn/J44R2qcw4EpRj7OjcQWDk8xjgtXuC/O42RgTKkx +9OhcIw8oVAagovCZtn8TllD9blnMPLOc08CSUsBjKxUfFAIV81zlfzgn9gh R+7JsVVyKASIUGY7QBu06IwEGsmBLkdYOzmcwe7ofLxcmZgZvW5DgMaE36JQ Gn6LFceuaEC6GAyx8HQREWE0Q55NCoUwm9QIzbhTNik1NwrPjW1yQykZd8sl pY/z9vsGfTiP8OZwOIPtbUE8HZzwjKcZm44Qg0i6WI7C1K4YuFvhd5IIjBjI o6dQCKOnRojBnaKn1NwoPTccmsAijNkOzu6IwQi/DYcz2MUQxMgBoybpIvA4 jzNqbkMMxiQMQZE0YQgKM7uSAeliMNLO00VEhJEMeXQVCmF01QjJuFN0lZIb Sei5sU1uKCXjbrFV+ji70zUY4cfhcAa7HHIxdPSKHM4pxHncZlXbkIwxe9+h qGfKKbcqGQJdDIZdeLqIiDCSIY++QiGMvhohGXeKvlJzI/Lc2CY3lJJxt9gr fZzd6RrcF+eEwxlaOMFe6WRx2hXJKMeUQqOWydGoZXIkl597Rf9qM6/YfoTG o2Jepz494qOvPZakB3libJMYKumxpTwQZoMbrt4P5mLEBimDg9J0EObQWeVB 0iwjqLSrA85W993kQacDpVwHSm0dKO0QI/bEcEkHSks6AGF2Rwd0gxvgelY2 BDPMK+aQDsSj1jniUWOLOJVpSnyv/CP6nDKYNNlzSkSkJUAsXz6PtVfPYzuL 50niieGQpsSW1s4FmA3utnFPmHWHkDBgLh+E2d1ZrXjUQkicyxdCCrsLIZAu zoRq7yZdmIUQ+VYbKIRbbYxYCLnTVhtqbqSeGw4pBmHMdnB2p2dwX5wLDme4 hXsOcY5ckYxEmrsQhaVdMdjdCu8kERgx6JmQCvVnpEJLU1KZ58Y2uaEUA1tz Uu7iPCI/5SDOJYdzrMJ5XGLjbYiBNKo2udeeGPo8cCYGezd50BIgkW+IkcD9 MJRKkNxpOww1MXJPjG0SQyEEyd32wtCH2R0d0PXqxzzMSTgIc+KuDkjXE5LE rg64W913kgedDsi92Ym2NTux48xOCk8Ml3TAkjFbgNkdHQg1YQZJw5JoEObY XR2QpnZK7pXE/CFX953kQacDco9dom2xSyw57EpPDJd0wJbBDsLsjA7kuiFp IHdXggZhRu7qgDRmNbHsXXC2uu8mDzodkHsXEm3vQmLHu5CGnhgu6YAl74IA szs6oBtGFgKY40GYI2d1IEWjSkk3ukjtriIIbHHGlr+bbGkJkMpXEVLtVYTU zipCCi2QnhhTqkVqaRVBgNmdToFm+hW4c3qSDMGcCEHH7qiFdDU5tbuK4HB1 30kedDogX0VItVcRUjurCCm0QHpiTKoDllYRBJjd0QHN6LG0ADCngzAX7urA qP2LUrkrIQqtBqIKdHEmNctu0qULRI3kWxjh49qBqJGlrgQ0OHpuTBqIihmz HZzd6RncF2fer5ioegbjNkrfhmTIk2REkV0x2N0K7yQRGDGIesQg0hcDS9yA 9kXPjWnFwNKedg7jrBl0LODMWxFTFc6JK2KQSeeRMsvzSJAHzuTm3E0etATI 5PNImfY8UmZpHglaFz0xphSCzNY8EoTZHR3QDDomdhIO5mIQZsGS7o4OSKNR M7tZjhyu7jvJg04H5FmOMu0sR5mdLEcptC16YkyqA5ayHAkwu6MDmkHHKUiQ mJSDMKfu6oB0ciizG43qcHXfSR50OiCPRs20o1EzS9Go0LboiTGpDtiKRoUw O6MDmWbQcQqSGqbhIMyCCdEZHcilqYsyu5m03a3uu8mDTgfkiYsy7bxFmZ20 RSm0LXpiTKoDlrIWCTC7owOa4cQpSEqSRoMwCyZEd3RAun10HtnVAXer+07y oCOAfKk4114pzi0tFEPboifGlDqQ21onhjC7owO5JswgKUmKBmEWTIju6IA0 a1Fu2XfmbnXfSR50BJD7znJt31lux3eWQUOiJ8akOmDJdybA7I4O6NpKQFKS NB6EWbAXuqMD+ahS0v0488KqWghsCT1btqMW8j0Qcu0tEHI7OyBk0LboiTGp WljaAEGA2Z1OgW7wGEhdkiZDMMfuRpfmo3aCLqRzTCiKrRoSIF1yZ7bt2026 MIaEuMeQEOsbEmI73ECeGw4pBmHMY8M5vifOvAsxU+GcuSIZxahNOYtRtudi 1GCl6PHDZXblB1LPmQxcu0k9Rn7kqVjxcX35sZOMNYs9N7bJDaX8WMrGKuDs zJZtNInufQamvO+xAAPTEOJcuiI/ZSgTgzK0O3Plbn3fSR60BCjleTLKUFcJ SkvESDwxtkkMhRCUlpJkCDA7owOpbngb1Pt8CGZyP67qgHzrzii3Oyhwtr7v JhGYQYHcCYGP6w8K7HghstRzwyEtIIzZDs67Iwa897EEOMPMWNF29useIwbS pNsoKuyKwe5WeCeJwIiBfEEbH9cXA0tL2pnnxja5oRQDW2vaEGd3xEA34BkO ADkDJMlFNjgTGG1nv+4xYtCTS7W0KwbuVvidJAIjBnJvHD6uLwZ23HFZ7rmx TW4oxcCSPU7A2R0xuGfUc8a5ICOYMxfOBkbOpN8uxwQ4xWE4qlQ0qlQ8qlQ2 qpR05TsK7bq8BRo7E465mzRuGYCBlUpZFGpLWRRakrLCc2Ob3FBIGWHMdnB2 JlY31U3wBbosWTSEcwwN/c5IWRyNEqlIui4SRXYN4ZAumTNxertJl04yepKH R/rJwyNLycOz0nPDJcmwlTwc4uxQ1yC835RnhgZxht5/hyRj1FgkGhOrG0fS BLRRG4VrSVhg45F7Um1JWORRuJF+FG5kKQo3Dz03nBIWS1G4As6FKzgnutOn IcA5HsQZ2kMdEhb5GgtKra6xuFvhd5MI3RoLkucjx8e111iQnYzkeeS54ZAY EMZsB2d3xOCeuQIyzvkZQesNzCwTFa6IARo1MYXG+AZjJE1jFSG7+1wIpHJm gXY3SdWNMnqEJdIXlsiWsCDPjW1yQzXKsCYsEGdnFu+Te3o6s3QIZyQEabgj LKMWydEYE3kcS32DCNkNERZI5czuurtJKmbE0hMijPRDhJGdEOE89txwSFgI Y7aDc+IMzrrTlCAncsZ5RFEIOhAwZAK5EiIcx9KEVlFsN1uuwxV+J4nQjTJi ebrcKNbOlxvFdhLm5onnxja5oRplxJYy5go4OyMG8X3j5/IhnBE0iTokBqMW yWPpPtwI2XWVCHRxJsHybtKFGT/0uEqQvqsE2QnFzVPPDYckgzBmOzg70zW4 N86clRQB9xCCVlLkzPJ3LF/+jkO7YrC7Fd5JInRiEMvTUNGH0hSD2NLYMvPc 2CY3VGIQW8pEJeDsjhjorkbBcSJnJUUgzEGYNESxK2KQjLIFJmhUKXmQbRLb nZiCpHImcns3SdVNTCXyTOsRmYHXnJhK7GRaz3PPjW1yQzUxlVjKtC7g7Izh L9adgAQdCBI1OoAzDKZ2SFiko4woSeyKgbsVfieJwIhB0iMGib4YJHa4AW2e nhvTikFiSQwgzs6IAdLNXgZi3vJoEGcY8+aOGKTS+KUoye2KgbMVfjeJwIiB PN8tPq4vBnby3ebQmum5Ma0YWMp3K+DsjhjoOmtAnFqOBnGGzhqHxECe5COx u3+rwxV+J4nAiIE8mDVKtINZ8U+scKMIPTecEgNLwawCzu6Ige46Uwhwjgdx FuLU3BEDeTBrYjdJoMMVfieJwIhBT5LARD9JYGInMqmAdkrPjWnFwFJkkoCz O2KguTZE6g6HczKEc+TuYnQq90+ndp0NDlf4nSRCJwZpj7Mh1Xc2pHacDQW0 QHpuTCoGqSVng4CzO2KQauJcAJzTQZyFCDR3xEC+gJzajSZyuMLvJBEYMeiJ Jkr1o4lSO9FEBbRAem5MKwaWookEnN0Rg0QT5xzgnA3iLHhT3BED+V4Sqd0F ZIcr/E4SgRGDngXkVH8BObWzgFxAc6PnxrRiYGkBWcDZHTHQTHRCM26xOOeD OGfOikEmjyZK7S4gO1zhd5IIjBj0LCCn+gvIqaUFZGhu9NyYVgxsLSBDnN0R A6SJcwpwLgZxTt0VA/kCcmZ5zcDdCr+TROjEIOtZM8j01wwyS2sGzhoSd5Mb KjHIbK0ZQJzdEQPNraESYC7MB82FEdwayiExGLUZUFbIJcPyZBKgS+rMTmK7 SRdGMnomkzL9yaTM0mRS7rnhlGTYmkxy1p6KNC2ICbAgFoMWxMhdn3IuHz/k drccdbjC7yQROjHIe7YczfW3HM3tZMoqCs8Nl8Qgt7TlKMTZHTGINC2ICbAg FoMWxMhdn3IuzZMa5XaTVrhb4XeTCIwY9CStyPWTVuR2klYUpeeGU2JgKWkF xNkhMdC0ICbAglgMWhAjd33KudyNkNvdzc3hCr+TRGDEoGc3t1x/N7fczm5u Zei54ZQYWNrNDeLskBhoWhATYEEsBi2I0UQWxDFi0JM0G1lNmu1whd9JIrQM QD2b7iD9TXeQpU13yshzwyExQLY23YE4OyQGuhZEKPq8BTFViX7qjBhI3Qgo ju2KgbsVfieJwIiB3JqGj+uLgR1rWok8N7bJDaUYWLKmQZx3SAx4CyLYdlWc DsxcEYNC7kYoQqvTRDtc4Z0kQjdNVMi306GLm5rTRIUlbsSeG9vkhmqaqLC0 nQ7E2SEx0HWdwBFgNoSzkJvEHS2QpjZFcWJ3YOBufd9FHjDjAvnyMT6uPy6w s3xcJp4a7igBIcxWYN4hJeD9h7lqLjB3RgrkWy7HqV0p2N367iQRGC2Qrx7j 4/paYGn1OPXc2CY3lGJga/XYWW9qpOs/hMM/3n9YquYCC2fEQO44K+w6zhyu 8DtJBGaOqMdxVug7zgo7jrPSWTfibnJDOUdkyXEGcXZHDHTDh6Hml0MwCxkL 3ZGCckypUr5HTmnXlSY0CoUnyzbkouzxpJX6nrTS0rgS+hU9MyYUi9KSI01A 2ZlOgWZEWQySnZM4yn6UhSRWzohFGcsnkTK7k0jOVvZdpAEzhZT1TCFl+lNI mR1mQKeiZ8aUE0iZJRlw1o96X5Q5yyF9bgblHKJcOiIDSZjJRwN2bcm7W9ld pAEzGugxJZf6puTS0qoy9Ch6Zkw5GrC1qOysE1Vzt4sY7HZRoiGUhSyG7shA MaZUJE9oVNrdUVMgS+7JshWx6NlPs9TfT7O0sp8mxcgzwxmxsLObpoiyM10C zdgCcgEO5XgIZSFllTNiEcnjj8LQ5tSRw5V9F2nQTR2FclMCfTOaU0ehlQ4C CqF70TNjwqmj0I4lQUTZGRnQjCqIwT4YZTKEsmA8cUcGpJFHGCe7MuBsZd9F GjAyIF9IpnjoyoAlZkDfomfGlDJgZyFZRNkZGdBMZx6DHTDKdAhlIbbMGRlA UhnI7YqAs1V9F0kgR7+VgL7A07hPAO4UdhorOQGtip4TA5wgvoj7t/9xT/sf xT8f3a39hzCTHUeHYTbY/jdmERXO8V1xJk/T4Qz2swCBAokC53Gpqe6Nc68C 5K0ASFMWNQJwpwxl+iwwWNk9C0REpPBvoZX3wE8MvDPNvMd54mY+luas3nIz n3kWPM5m3gP/OJp5j/PUzbw0G3V0r/yj+jRIPQ220s5H8vSj5ALcnE4U1zqQ 9Mb43Cn7aKJkBsw64pkxyIzUhBAkfUKQ3lUIBJyRCmeTQpCOwzm5M86IxTke tAEiBc7RdnBWC0EijfK5V39fnwUma7tngYBIf3+/t52/U3/fA+8Y8M408x7n qZv5gX3tu0JSl9iWtSD2VHmcWuCBfxxa4HGeWgvMr+TqswB5FjzOZt4D/zia eY/zxM18Kk39s+VmPvIseJzNvAf+cTTzHuepm/lkTKHh5d7tiEFiMP2H54qI iGS5d2sLuh57rwceZxf0IBujB5kDM/2JyVhfTxUBEWfHBh74R6IFHueptcCB mf7Eh3g90mbeA/84mnmP88TNfC7d62XLzbwP8XqkzbwH/nE08x7nqZt5NKaQ ef+uPlV8iNcj1QIP/OPQAo/z1FowkMm/LVRIp3+2verrIwQe76qvx/5x6IHH eWI9KEMHuv0Gd4b2LBARcbfb74F/HM28x3nqZj4aUygeUyhXF0pDB9aPY7+8 9DhVxQP/OFTF4zyxqqTRCFVJIwdCRuPEU+VxaoEH/nFogcd5ai0YMy5ADiwy x95g/ki1wAP/OLTA4zyxFsThmEIjopLSWJpldMsr0ch7Ex/tSrTH/nGIhsd5 ctEYM4BwIdMo8vbExzmA8MA/Ei3wOE+sBYk07dCWm3m/vPRIm3kP/ONo5j3O Ezfz6Zh5onTMInM6ZjIpdWD1AfnJyUeqKh74x6EqHuepVcWFwYM3tjzSZt4D /ziaeY/z1M28Ax4D5I0tj7SZ98A/jmbe4zxxM5+NmSPKxkz/ZCNSX6Q5ml5V Ij8x+ThVxQP/OFTF4zy1quQO7F4f+cSIj7SZ98A/jmbe4zx1M+/Aim/krYmP tJn3wD+OZt7jPHUzP8Y6kMuTmqbbFQMfHbAlK1naEOAoerJ//ub66DV5M+QC 5MrH3RVrsUh7jWbpXZiRKpmRemboMKM0oRZpn1qUd1ULiHNUqHA2mQK7HIdz elecydN0OCOAc8biTB98AOco3w7OaiEozKc81WeBydruWSAg0j8o6G3n7zQo 8MA7BrwzzbzHeepmXrq52f1SR+jTwGSYmKeBgEjX3xdTR/T36O+UOsJj7xj2 zjT1Huepm3p5lqB7Te3o08BkqJingYCIZGpnW5M3Hnvf1Huc3Wjqi+knb0ym ivIkEABxdu7G4/4oGnkP88Rt/JjNatIydmB6x2SiKE8VARCXZ3c89I9CDDzM 04pBFmYjCkXmXVvaTDEZ7OuZIgDi7KjA4/4ohMDDPLEQROYtW9okMBnp60kg AOJsG+9xfxRtvId56jbegdl9H5/7ONt4j/ujaOM9zBO38Ujaxm954t5H5z7a iXsP/aNo5z3ME7fzY/bzyntMueVWxcAHdW1JDEq5J7eEntyyloqsVyrKuxAj UxIj88QYTwwUmZCKrEcqUHRXqRBgzhQwG4zfR9E4mLM7w5yxMEcA5pSDOVPA nG4HZqUKlHIVQFGtAtFWWGCwsnsWiIC08KNIqgLkApwKoKhWgbxPBdCdiJEr iZF7YmgQIzGhAnmfCiR3VQEB5lgBs0kVSMbBnN8Z5piFOQQwxxzMsQJmtB2Y lSoQRVgGvvj2269eBQS85Sr4sLqZ09cfLJbB5t2cwPXj6ub9k63wwWS193wQ APnkLp/N+fXZzfr43Z1+PPIT4tebJcknYZjkSZri/0Z5GkX4v/STxgj/O89I sSTPclwe5Xn8SRDavKnmc4txuAmCT87fzZdv/2ex7CtX15T1Nu5pi5+Xw6R6 uf/yGWbze9pSvMRkOX4XvJvPiK5cLq7mAS2gOMOvFsvzq9uLefD5enOxWB2/ e80fulq8Acd+Wr/c/HQ9X5PD3fGn7+c3y/kVpevTfXJj74iibXCzRm6QNGfk V8ENbgo25M5+dTG/XCznwdnZbYz2bs8Wy02MzjbM8TU+Lh69LXDh83ezm/32 4Le//a+zr7/989l/fvF/9/Yi9Bfxiz9+tbcX/oXe1tViefsxQMfJcVQcxQHu Zr2Z4VrN3hL+2W9/c/bNF7/9jy9/d0b/P6Cf8GMYkf/is3zzH78J8Df/ehG8 +SmYBaQs7s6t8BPjT9+pvv7y26+/+Oqb+lSIOVXdQn1YbDa4/WU+wqn+9Odv vg24Dz5Vwpxqsa7abeEjnOrbL/7wmz9++w1/qrw+1RdXV8Fm9jZ4s8B6JDkV ONeX/+fLr9nnI+cqwvpcX5K+LP+IlzezD3P5bXFnoZ8D2Vv8Wbzw4SDA8Alw 0YP5x/P59SZ4Spr7xflTLLzrDa5AweoyeDr/uMGUfkqKVl9j8i2WV+RGMSuD N/NLrNcHlL64N/c9FpD23+hw/5/7zaXwg9/eLIMDSujDA1L0iJYJPg/Ck/1f 9qWnn13iq9/p7IicPerOTh4Uk2KNPj9dR/h/cfBv5Jmqx4PPtPlxPl/2XJb5 dyy5BXI4OKIlg9en9Nf1n/Q2FC0R16atNzeL62tMkwvS2yAquH7/5uz8Dfni 9hxfbUzb1p2x+hV7nn/ut3ePL7fCjdJiObsKfpjdrMmZm+/a5z1hDxVB3d84 AQV/xCp1wp15vfhwe4XBXS1l5y6aSnGyv0cxv7lZ/DC7OiG/rP8dkA4H+dkv J+NeYc/7W2GWa7887s2RM+DXtle113W/CN94c6Tu8J2wf+POYPt30+vDz7FX n/af+3vNl3XXCpf+hYyETroLtc3GujpVgQ+tbrDGLZZvu2Jv8I/OVpeX3eVx p67948PF/Afuj7MPs4/tAVwSg8P+eUYhb/9edddhuqHdk9WdzRNwz9Ux9n00 XVruJZE+r3Dg7Hy5EQ/ihuLDdfPOi701fWjmZTV94u6Xbb+4PXQpeYKmfy68 9uaKKva9VCjr8G9B+3d2hgca68XbJSYwqRaEfc17XyzPLq9IF+IAUPPZ5lrS Jm2uj14zkOH2iBxpAAue0z85uBQtlZEHrVvcH1aLi6pR+ml5ftbclOLBFpfB AbnpGvvgs8+C5s8KaNL29jx2zY7D9mTNB5xBdYKu3ePe5ik8z3Pwq1/uNgp6 vJ96/Hdu8xrD478UH8vI+C9CSRInIT4exfi4H/9t46PTZ/oTbZRwp5hMH69w m/RT0/tY3ZDGpOp9jD6j9rjwdrnAh2E5otLjxo/NXEc1eGzbVNDWMqOFP65/ j5sa3BgeBgfk/5k2MUCHozucdY+p66itr+fni0vcTF/MNrOu06Tz+sj4iDwj vtP6BMEZnWY7q/pQRNXWi3/M634fGbPX/9zMFlf1P6t5Oaa7xPRfn52/wWL9 S1CfFBeqeqC0L0G6j4vlYrPA3UdygE7e0ZLBFa5Gm3cBK0WbYLn6EbfdIf3d +e3NDVmE+mFxs7nFv1+sV+fvblbL1e267YoKb4G+wbdXqzdMF1os00g5OU3V rzgN6aTb2abuZYgliN6TCcjTcFT3txfKy9vlOTkyEsT29VCJvrjFN0IOzAVt Jj2zzfWLAB4n3WN8HPdv9xrcn5HpWFy0/ZtMvrJ/k9lZKvUU/UU1w3naTm6S f9Xzr+RtyEixPn9zEmC+XONat7k8eDqSrN3nr8unhyfd73/96QU/i0z/ZiaR yd/sHPKnF/gM5Kl5FKuT4K5AVaw6B/MnfRPNn4eE8S+f4cF1cLA4rV4wrtr1 aCJYfM4eIgOO4PnzxeH+HhlM4BeAmVxfDFcR3ANZkNPtkV5TgL9tuie4iZBM 8hwSvJ4/bwZ3e3vzq/U86P0tnYqpf0Owan5RHamxOmmuvsADcvA0+PaS6gTN Gydz5OSlNpB//PTjCzqs7F7tHn1Muoj4gr2t+g9S+BCzYO8XzOL2vJ9e8HP7 +G8wuY+PgNn97np7e80lyI9aGrJU+euSWwoARGoWBuij1QsD5N/tugD5o10W oH80c+3Vc8M3xx/Ap+sONOfsjjQn7o7gpzlurgDvky5BNDfarkGQA+wSxKcX zApEh1j3XbMAQasMs/5A/r7kTiQ8H7kD/khzG91R5l6YB61viPlxe1dMqfrW uiPM/XUHmZukVbJ9R2S1pGoYVsLd4++Y025W3C//umSXVgBFmoUWGfhVa4pP WJXpDvTheMeGD4/9aIP//YfZ1dXq/KBtmkk73Wg2baFJ+0L+wK1NrePkCNFx fKRry+o/iKhTha2KkYbpNDiQNOCH9YXJOVeXYonDZ/QOSAeBNClPmrPVzV/z +GQtcf5hhXuAm1VAz4i1KyAFDz4lE9Yb3JlZznHv5OKQqeXqi+7NPy42B0cR +fcvdKT8sumM0eXOM9yQn5GF7Xq4vs9r39nF/M0tmbOhnQ6+qGTUy0jj97zE Nq8Lt16VYL589qvFJelsyW+jElSGH6DAq6a7dPXTk5qWtfwA6WH+fJ40wtN/ 1hGtOfNiKJTfLeg6ca2Y8Iu6FZZ9V7X7+3u/wjewuCS9tIojLBkrNlLeQsbA W//vP//3E6rLZCXpCv/49rp5NTwLWCrW1/n5Z4b1mOjNRfFPqNqBKlFLZnP0 +XPaZryn9bueBD0lfdTn9UTZm/PV9U8HpMCLoK4Az5sfvwh6WXzY1b7vmuLV a8Onry5Xzd/udY9S3cswt3pfYf02SOQOIcGnlfbWh1lxrS5OUee6QTWW+A7q 2axqPl9W6fCQ74fmjiQVBRQ5IPUBi8X67Ppm9YarZ7Q6MWODttQZblFqwKrj 57OrM+YcN0t5n/T6+qTlyAHzeJQJ9XN99Zc//YmCfl03mFXXrWlSyVfVGOW6 4wRTmxmpwMXq/mPw9naGRW0zx23d+vacBNlc3l5hKf5IppLJMAAXorfF91WD 10EUHOL+0x54RIatVZeQfzWvu7/po4m/5srXZyK3MVSUVDcMP6EofpiL1YeD w+DTIArDRgLgbz/7DCMRfH4qfIHv6eVL+pPe70mD8PIlRLwr8pz59+vXASI3 RyGr8NsTKwpLS76xYb55Be+l6l0s6X8ublZ0IaOqRVStZNxrW4LvGtLQZpQ2 V3Ut6tqqpsjpqbRpqlUcNE3kKGkOmNbh6GiA2qA/0LV3bW0mNUM+20yHsYSS N+3AtWfc2juljHuL+C0TrlNu30j1lVTkZ3QATopctw0SreFUqGhzwBTBj0Bb zHrifLM62auegR11s/fcDOnP383P37P3A6/dzETQKzaLmtyVqQgcsgumzMol uQZ53bT0hXwanR1rV2Nx5pqKhQNcr8jbqRd9uxHmd0yXoFKT5/WbedHdrtba J75h2kWek6mUxezN1Rxr7wX5W8EF+RlpiMjNSphI4xYtgKJQwMh6E1k+3G85 1R7qWaKgtLmYn980KwHMWhZmTES4Lxw/pb/4DH+5R3/6+vUpLcmud9AvmoWO +se4wYWjo5eoZ2Wj+clRdbETIOn843aywh5+FbTjQjof1Yzx6pEQba2avjQ/ jhNGa/wYDIy/GNmXPsJp8GGxPABXkK6PYUyekz6a7DS11J0C7ZN2L0iRD7Ob 91X1IkNMdnJsX/x6dM2r77kJK2gG7uwUWMWQuqDQF5PcGoce/90rcrZmSIn/ yfWwhvv7YJqJNvlHR/gcn4fV/M2bm/nsfTvV84RtINp+eztvVMfdVDpBzrcn Lf7zKTPPRM69x47xqRbtqd/H3uAbqWSVzmRU2ro4rE5bayYWTaqb93rtVaMJ pkjo1fgpCgaQPXFZFPNZVnF1boTG1GjdR099qBrks/U5fq43q9nNBTdfLC2h q0fsJHDbzWCWPGoq0lm8qrllJmzq9Vo2UGKv6S/i8p8HNW3rX5PGd09SkTfN zG0z8cfOr1XDv6aLNPzrSPhp/UCibDO/Im+iec7R9bOqUPTkolgvZBKNlYV2 fHRqbXWVsfVWUnHpYYHMIq/2QAUWSvTX4a4SE5xoNR53RcX1eqtz230Uq1N3 L30V28it9VXwMXf2Cy1U92avZzebq5+C68XV5fyGhiuKPShmKfL3f/riD2e/ ++LbL6qFhL09EpPJf1uHKLKlcKFCcopvmm9RKPmWkIqcvwjlTRN5us3s7dmP Nwv8cmgDw6z17fcUGdU61dFwZJEVyPTl1eztaTM1QFsdMYak/hYjuLo5u2wU nR4jf52dr26p2Id1EFLRrFiwCzrfNVdvapt80uH8zTVcB2p+2A3ZQLDKYd1z Y5vRahTI3bLY2LZnrEI2mwuBJo+en7wn0j7wcJ7cqf/xRNq8VQsfDURc52Sf rEp1r/qEzr9UUJE+ZffNiwrCZn6PBCNefSBKwY4Zmp7OwHpa23hXK2jSgk2w 72HQtdvSZbbq+73KP1cXOA2qiv2/B13Jn2WnPxSbYTJ4b44x/e/6MG0wAzrX c6f7+t8hBWCvsUdgYX/cqgf7Jk+k3Pmm/Y6ncjVrWd0zU7VeC72Ew6ZTyXOe 4wi5y3rcNj7QS2zMZc0S15pLCrzqRljr8/cX7ZqbMOaSDKnYhS9+aax/wLU/ iqhMfyQQKmzbypDaGvDdkcHehXiVwT5GRzH+h/2cpl8Mjk6qutRblaoqfVjN jTY3JxuSjO8WDXJa1j+Ssgh2kaRM6u0kMb2kqgvwy8Co52GwuJ7CIi+3W9Mk d0en37qA6h7pZ4Sf+Sfps8v6G5cz/Pv6RmZX8xtxdkAoIe1sVJ2LSmqbRX4K ynD8TNcLWZ9d3JLuBllaZWMsTk/5sx5KpxHEx+BwFb5uusEB6ctaGtrq3xPt gejfUt3wda/w559pJR8cnfFTR1VXQz7y7f8RnRHkZharV9FPVnZ4SPGv59Dr zjnbQxGjyrvZ8c3mbL7G5Uhw5AAdP+CClGFXq+XbgKyGkCM0UO7rb78N6lXW gw+EZCF5AR/q0XQbpY2LB0/Il7Sf8IFMQXZfvH4dxIcnlVPkA/HokFWu+c0N 1pbFMiAl8E3SztZe+5vn+B5OuvlN/Ety9DTIXxb0X8+DCP9rOf+x+h25kQ9k wF93VMgNHjEnYK88e7M+oFc/rH7L3C7xTODbRQGFrDnt6+qhSUEybRufgF6T 8PsANY+7XnxYXM1umqnt1TKgReh1f6mflx4Rn5cexld7mVT/JE+c8E/cXTJo /kkcH/U7YA/VfZnaIML/mn7/ul7pIBaRw05d6d/Mj2tDCb13co5qLMBFLNW/ ox1zprvLXe3zoas1L7P684h7MoxNO0VYX4SZha98OMKTM/bI+t4Z9PCbXq5w 0zn/YUGCPz/MZ+vbm/kxoCNG5/PP4xMGnk1j96x/cVHFjW5WuMWkDG1PUAOJ T4DYE1C/KPkliTAiQD8TfsUg1yKBD7Xv8gX7aIdND1l8L5Vf6Ze7NCFkeQ3f X99SSD3DFAjVvV06qzxHtT9P69JvcNf8Yuji1dRafQevWXtsO8qt7o35RtmO tpcnXdxlE7Q70HjiV31G48HoEB93Rrp7o/2+z/omRpjQgEYg+AabRtxWZ2/U ooGj1g/8hI0jrB7E8y9uc30oc17Wb3m/ecxay/B1etdPyaO8qMzK7T21z1kf IJacsBVI/v0xz1LNoxz2rsKcX81nS1zwozCtE0i+7r1jSR9L6GaxkzvNLAx5 i/y8THWEeXKa5IZg1nb5wcwYM9XB3QYIruJieqVxzpIw3yZKlcTkdWGxJ3td /G/1NT8qA+MwMB8xckTYP5EA3oRI9qoU//72WhnlWNRO2zPFQfDKURcEfNL3 iGLIs7gaCpjWjvfaloV1i5229/VPcTQGTvWK6ZdizX6LGfzDvI0s2+OCy5oR GZjeYKZPcAe2jreWl2n7t0MzOD3zM+T8zdnvBcM+89pUsy/VpcHMaRVnskdd Ha09/fJmjlXy/ZsXwY9zuqo9/zBfbp5UOslGqze1gQpf+PGy/pw0xeoIOLgS 3I7iu1gXOiaWNI2kYWlC0NtWWbbGDlk1yBNxmX3E8Fmx0H6v8XQ93zzOyt6G chzczA/rMcx6zUbHjPUT9XYFmoEWiTkko7Shrkjd2aEzNC0ZmZf1/HlXjaXh QwTjzzqvjmQk16umtOj8B8zOM+KoIjfcZ3KtqmEdrj8+PKEdI+L60JmImIPD yxu1EUe+jtAqIR4ZEVbj/5BwVBC9vGnGoy8C8pu6vwEfmvQ69mQ1g3sArlqw 37yq8gM2AaX4TtpohjqrHD0o4y69+Z63x4yx2ffHHx7zBqs2UeMtCjAJr3G/ mhvva6OkE+fdVCio1JJoXsnzc6+f/+5VcDM/uh8GfSBIZzt0Z+5ki3Y902VN 3a8CbMDsfR0uXzcVbNGqW6S5GN+7mLfoVvFale0NZmp87W0oVKXB3TihPkG9 IvVZJ/HNCn+zWPXZgdgRki8bHbb9QIE1UkSqWXaWQNJi7XQ0ZwxoA8zax26l bdFM573gXsFA6BcfAlB1ccRKzdS3DpbnzdT4KCFoxg+Smb0GkaMjlkKfd91F ZmWSmXbvqSHVlDq5k65adMfuWhcEXJnLNAMgDFZdT0K2Wg/+lOVAd9yQ0QSe dKzPROIwkXtLelwl+KF/fEcSiw1V08+FWvpP/vpMO9H6L3p7n8IPuMFnfylx mgf2aOtV0kEUe994U4vYuPS6JgzcEhtvUne0RlRH5ixVtRI6fpu6vg0/y/Pn NZH5qJc7EhnXzsX63fziYfG4/8qVBZYMOqomt35X6ljAqntH6E5C3If6wHzJ MS3WPpibGWi3wG1wT8p/94oTmFZ3Og731m1efdg1rX2VeIutwh5owOUrO+zk 4+169nZ+cI6HTpuAJADE72P2Yd4E71/WT7zeXOCe1ountPSr4NN18F1wdFPb Z3ClwY3H35pmuLqZp3WM9NPWUjJ7s7habH4iz/Dpp9RXNKMGU1KKTlBE1d0R gfgwWywPquxdb89f1Df2DP/xA72zPc5F1XWu9vhoKjqCrv7BT4ztt+iTt1K9 ospA3xv6xH9BuEW92VW+adJrJrd4ftK15gfnuLF8O9/gogf0Kcjdv3h68+op 7gE9OQ2+/PPvCWDrHxeb83fBwXndKaoedb6su2/ns/U8+Nebf31VjQNqvxK+ k83q9uoAnxuf9cVnuPiLsOmeENKQExzW2FavrfquDanew0Sf3V5tqvPCgr9U 1MOnXywvniNyu+QRhDPix67i52eb1YI85Q/fVb/5G/mWNV/BAs+jv3E25raf xhqWqiEA7ZO1h2snmsaHmtIaclI7Pc0S/aLNCF559etsN7WJTe/8jbf5s4pO TUVuD1f8IoefIf4LTLnuC+JK61yo+K3RH2o+cPW47+fz68XyLdHU8/dkaoss Ht2Qqfo1+atuT3Qf9uU+6JIy6wBifpEm7nD4AgI8xKFDFsdoFR1ziy9boQyJ PNLcGtRAzkx404OdwOFbW5yAw4O9pmM+7qYacTUH6wFA/TJ+qVA8bt3qlcWW v0ma4IOa5BL2Nulh/jaxxMMvmntgD/L3wJXvDL+L6vbol4wjj8k2Ut/uUdIc rj12TJFqMaLNwR12mfi7HktEnpF7srY8AIA93L5b5qDwbukVKM6kFIuz5Br0 npjkKgFdUO8jVE9LMUBB/AWVgeMmS9JpkJ00xzqnQHXZpmgTQ0OfqDuGu6J0 xZX83US4tuxhyjXOrPq716+j9mvWXAd/yawtMDfTTFDUIRb1wS4mMWGepp3z 4W5dDO2tT9LNOFYHZkxeCeHhax3hb7laBujuq166pvRrql/I8IYLhWtLRLJa i5iD+80Ig34TCyfkg0YpR2pjZrUm3y4UkLTFUc2WgPB0TjOGYV0JLm6vSWek zvrL8KZ+droUwB+qh8cRlyekImRH0Yvj4+NqsNDfSgq0brfCGGpb8VfsVhot jF0fin4tQbXNPtJcRu92ubvu5lboq67y61DGjdEumV5FNNKInKzNUNtk7Ql+ nK2r6WASKUTEMgireCTJNM9ndf/vs64LSfjTTFMLczxt+cEJf/JITGqs9kfk Xb8I6o5EfUnaeyDXa5f36L1qdV763vt8hjuleBhxU7mPz1c3+IGuV3hgQjoV q+D94vw9+eeMvjdS9+s+xvf6HSjpPTRzIqw2USlhhrq920E0U3zgm8N6yW/s PdAo/YsfZsvzeRVvc0Da5YCkrcMEoV2cV/9Vx3VpnPX5c3l/Cd/dPo1bx08Q wOwSjDOfwn9Ik5JVI0Tyk3ZiuE3XI26GRCZH6WZIvIGnm2Rv1wWq4YI2ESs/ 1ECLUlVpfiMeQqPBV/iyjkKoBbH7V7Ws3/8KWvg/vQDM2AcP3pZsDjF8GQPt y6oc+0i0w1096gXbZI0/XxXgLr0zsrB4FLER7VUCF1yoe5jn3fPVUA/lceFm 2dsdlciQjNtRiZ+X667AFqoHm4PP+bIuglsQgm3w4+LqigSzvZ0vSaOD31lb RHmWhgHVgjwerHLCxUVRdORhy9RhEgvSA6lPUx+qv+CQWAgQtKeXdEHBCeU9 3lD2bT0gaarpnjgygb8Ag4C9JtajjbmQl69nbfe4asbfd3We9jT142o0enti a9qI7JpE5FB1nzWRuXVtwm0WNQk2CTQrTV6su4rVlda5k9Y6AmpW9cZPe954 g7XQgDdvrx78SJgl8OIJbb3owKUuAjpbi+akQ4ytnE577Ain9otQvFq4+s7B NpZ0Cy2sED37pHGSwT9+t0x7N9moJpxG9xlqGVmuNu9IO/tudn09X1IOzZp2 ttmuQ0eZad+pf5hHe/3c9mIK3apPF9Dp4eDrb/9cJ59p46nlKVyGuoeiwlVb XdX3RUquaV+MzGfh+jK/WQd4NPRNlfqkCwjT1/Wqixl2Gl95M2taPWlbwioE sI7gbOZ/9va42VdxJNGKXRXgLZ+0rX2XwiCasaACEydX8gUYWXOWc/51Xs1n PxBwm5TPTCTdHd4c++qqd9eFzYG313m3+hzFzCACX61tp1pvavUW2LPAANbm DPKA1b09eub6PHKj0fAZ2PfAnAYs0/DPwZWG7ZF8T79PL37GnbquSYItUssh 5tXcpWnqOEJTVbKTKLXE1o0+T+lg8Tk3sdNOUQniw7oWm3fYF1K61yXSrYNK WDLVN/akrV7dMWkg6eycJqPmLE3k1+vNihgMuOPVcIqN9IPXGAg1/QW+RmbS yfhL5N8hE4zaJBRu3OXNSdqbaV9ce2TotTF5apmXxhxt0qo1wZD8uQdfV+uV 5Nslmjl6aEvDKmITTinoN1psZsSps/Wb//zn7P2c7ORm8xqK/f/CNA/p/n9p EsVZllT7/6V+/4dtfH7/xz99+c3p119+8bv//PKYOnOOcZ2px0LBb//9i6/+ 8OU3wV/r9ev/8+XX3/zxz18FDWuCD++vZ2TFtinAbNFXhXiuj8+bf7wLLtHx 9dX+/m+JUeGb06P/nuFR7tHb/f3j//r3P3/1/15hRVrgfio58Xp/v/rVqzpI bH28ag4dr17tiedmrry/T85DFnPPL4Lj45OAIHx+GRzh29zbC4K/kwZ2SdqL fzmgz394Elysgvn5u1V9vpdP/+Vflk/J0eX878HP9e/e/mNxHRyVweu6UPWf o7+fzzbN7+oX9PdjfMnjt//Y36cPQ27l1/T0zQWdaUmY12btGor6H0Xk33ma 40qfxVlK9n9JQ+Tr/zY+ozd8o5uA0gbiZcUZ7Z1Am4Hgy2f7wTOaEObwJbFU HuLewPnNao3VG1ek2dV6hesdKUL2diEzcz9dz49oT5ns9HIcfDOnK02kxNPb 5XJOesKzm5+eBterBRnmBeerD9ezm8V6tTzeZ3MokUt+fPHTYXDwz7bBCoIq 2odcZHV58PEwOCO+T/yPxjDaUxKf5uwnUvInSckDEk2Er/MZOdlp8NlZVwiU PCOOXHyifyP/eoX/dRL8cthtfUnej4O3/Fq85amJ7D/+4z/+4z/+4z/+4z/+ 4z/+4z/+4z/+4z/+4z/+4z/+4z/+4z/08/8BmI3htABABgA= ---679275476-1114011982-1042958518=:28820-- From Robert.Olsson@data.slu.se Mon Jan 20 03:39:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Jan 2003 03:39:18 -0800 (PST) Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0KBdC3v020184 for ; Mon, 20 Jan 2003 03:39:14 -0800 Received: (from robert@localhost) by robur.slu.se (8.9.3/8.9.3) id MAA05061; Mon, 20 Jan 2003 12:53:20 +0100 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15915.58160.182541.806936@robur.slu.se> Date: Mon, 20 Jan 2003 12:53:20 +0100 To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Cc: usagi-users@linux-ipv6.org, mauro@deepspace6.net, ds6-devel@deepspace6.net, netdev@oss.sgi.com Subject: Re: (usagi-users 02099) IPv6 packet forging In-Reply-To: <20030119.010908.127619438.yoshfuji@linux-ipv6.org> References: <20030119.010908.127619438.yoshfuji@linux-ipv6.org> X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 1594 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= writes: > In article (at Sat, 18 Jan 2003 15:54:12 +0100 (CET)), Mauro Tortonesi says: > > > packets on the net i have used link layer sockets, but i'd like to know if > > there are more portable ways to perform the same task. do you know if > > How about libpcap? > > --yoshfuji > FYI. pktgen has been added some basic ipv6 send support. Not easy portable since it's Linux module. Anyway it should have some merits due to it's ability to generate very high loads. ftp://robur.slu.se:/pub/Linux/net-development/pktgen-testing/ (Haven't got much of response from any testers sofar) It brings up the question of any support for address ipv6 conversion functions in kernel? ipv4 has at least in_aton. (net/utils.c) pktgen uses scan_ip6, fmt_ip taken from dietlibc to get some minimal inet_pton, inet_ntop functionality. Cheers. --ro From bcrl@redhat.com Mon Jan 20 13:11:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Jan 2003 13:11:41 -0800 (PST) Received: from touchme.toronto.redhat.com (to-velocet.redhat.com [216.138.202.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0KLBP3v005446 for ; Mon, 20 Jan 2003 13:11:27 -0800 Received: from toomuch.toronto.redhat.com (toomuch.toronto.redhat.com [172.16.14.22]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 173E8800086; Mon, 20 Jan 2003 16:17:56 -0500 (EST) Received: (from bcrl@localhost) by toomuch.toronto.redhat.com (8.11.6/8.11.6) id h0KLHuT06611; Mon, 20 Jan 2003 16:17:56 -0500 Date: Mon, 20 Jan 2003 16:17:55 -0500 From: Benjamin LaHaise To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [patch/bk] remove scm_cookie parameter to send/recvmsg Message-ID: <20030120161755.B23890@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-archive-position: 1595 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bcrl@redhat.com Precedence: bulk X-list: netdev Hey Dave, please do a bk pull kernel.bkbits.net:/bcrl/net-2.5 The changeset removes the struct scm_cookie * from the esnd/recvmsg ops, as well as removing the struct from the sock_iocb. This helps speed up tcp_bw in LMbench by elimnating the excess memset and credentials setup and teardown. Cheers, -ben This will update the following files: arch/ia64/ia32/sys_ia32.c | 5 +- arch/parisc/kernel/sys_parisc32.c | 6 ++- arch/ppc64/kernel/sys_ppc32.c | 6 ++- arch/s390x/kernel/linux32.c | 11 +++-- arch/sparc64/kernel/sys_sparc32.c | 5 +- arch/x86_64/ia32/socket32.c | 5 +- drivers/net/pppoe.c | 7 ++- fs/smbfs/sock.c | 72 ++---------------------------------- include/linux/net.h | 15 +++---- include/net/bluetooth/bluetooth.h | 2 - include/net/inet_common.h | 4 +- include/net/sock.h | 9 +--- net/appletalk/ddp.c | 4 +- net/atm/common.c | 4 +- net/atm/common.h | 4 +- net/ax25/af_ax25.c | 5 +- net/bluetooth/af_bluetooth.c | 2 - net/bluetooth/bnep/core.c | 29 +------------- net/bluetooth/hci_sock.c | 5 +- net/bluetooth/l2cap.c | 2 - net/bluetooth/rfcomm/core.c | 31 +-------------- net/bluetooth/rfcomm/sock.c | 5 +- net/bluetooth/sco.c | 2 - net/core/sock.c | 4 +- net/decnet/af_decnet.c | 4 +- net/econet/af_econet.c | 5 +- net/ipv4/af_inet.c | 4 +- net/ipx/af_ipx.c | 4 +- net/irda/af_irda.c | 22 +++++------ net/key/af_key.c | 5 +- net/llc/af_llc.c | 7 +-- net/netlink/af_netlink.c | 29 +++++++++++--- net/netrom/af_netrom.c | 5 +- net/packet/af_packet.c | 8 +--- net/rose/af_rose.c | 5 +- net/socket.c | 27 +++---------- net/unix/af_unix.c | 74 ++++++++++++++++++++++++++------------ net/wanrouter/af_wanpipe.c | 5 +- net/x25/af_x25.c | 4 +- 39 files changed, 178 insertions(+), 274 deletions(-) through these ChangeSets: (03/01/20 1.946.1.1) Remove struct scm_cookie * from socket send/recvmsg() ops. Credentials are only used by af_unix and af_netlink anyways, so by only using them in those paths we eliminate overhead from all other network protocols' fastpaths. through these patches: # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.946 -> 1.946.1.1 # net/llc/af_llc.c 1.32 -> 1.33 # net/bluetooth/rfcomm/core.c 1.8 -> 1.9 # arch/x86_64/ia32/socket32.c 1.3 -> 1.4 # net/ipv4/af_inet.c 1.37 -> 1.38 # net/ipx/af_ipx.c 1.22 -> 1.23 # net/bluetooth/af_bluetooth.c 1.11 -> 1.12 # net/bluetooth/sco.c 1.8 -> 1.9 # net/key/af_key.c 1.12 -> 1.13 # net/irda/af_irda.c 1.35 -> 1.36 # arch/parisc/kernel/sys_parisc32.c 1.5 -> 1.6 # net/socket.c 1.41 -> 1.42 # fs/smbfs/sock.c 1.13 -> 1.14 # include/linux/net.h 1.7 -> 1.8 # include/net/bluetooth/bluetooth.h 1.10 -> 1.11 # net/econet/af_econet.c 1.12 -> 1.13 # net/netrom/af_netrom.c 1.21 -> 1.22 # net/rose/af_rose.c 1.18 -> 1.19 # net/netlink/af_netlink.c 1.15 -> 1.16 # net/decnet/af_decnet.c 1.20 -> 1.21 # net/bluetooth/hci_sock.c 1.14 -> 1.15 # arch/ia64/ia32/sys_ia32.c 1.36 -> 1.37 # net/unix/af_unix.c 1.34 -> 1.35 # arch/sparc64/kernel/sys_sparc32.c 1.59 -> 1.60 # drivers/net/pppoe.c 1.20 -> 1.21 # net/bluetooth/rfcomm/sock.c 1.9 -> 1.10 # net/packet/af_packet.c 1.18 -> 1.19 # net/bluetooth/bnep/core.c 1.9 -> 1.10 # net/bluetooth/l2cap.c 1.13 -> 1.14 # arch/ppc64/kernel/sys_ppc32.c 1.44 -> 1.45 # arch/s390x/kernel/linux32.c 1.33 -> 1.34 # include/net/sock.h 1.29 -> 1.30 # net/core/sock.c 1.14 -> 1.15 # include/net/inet_common.h 1.4 -> 1.5 # net/atm/common.h 1.2 -> 1.3 # net/ax25/af_ax25.c 1.17 -> 1.18 # net/x25/af_x25.c 1.21 -> 1.22 # net/wanrouter/af_wanpipe.c 1.13 -> 1.14 # net/appletalk/ddp.c 1.16 -> 1.17 # net/atm/common.c 1.11 -> 1.12 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/01/16 ink@jurassic.park.msu.ru 1.944.1.1 # [PATCH] alpha PCI setup update # # Until now, we were configuring all PCI resources from scratch. # This patch allows to use unchanged PCI setup on platforms # where the firmware does it reasonably well (titan and marvel). # # [The patch to setup-bus.c that removes "FIXME" from here (ie makes # pci_assign_unassigned_resources to match its name) exists at least # for two months, but I've yet to convince Linus that it does the # right thing...] # # Ivan. # -------------------------------------------- # 03/01/16 ink@jurassic.park.msu.ru 1.944.1.2 # [PATCH] alpha_remap_area_pages # From Jeff.Wiedemeier@hp.com: # # Add arch/alpha/mm/remap.c (__alpha_remap_area_pages). # -------------------------------------------- # 03/01/16 ink@jurassic.park.msu.ru 1.944.1.3 # [PATCH] alpha titan update # From Jeff.Wiedemeier@hp.com: # # Update titan system support include AlphaServer DS25, AGP, # enhanced machine check handling. # -------------------------------------------- # 03/01/16 torvalds@home.transmeta.com 1.947 # Merge http://linux-voyager.bkbits.net/eisa-sysfs-2.5 # into home.transmeta.com:/home/torvalds/v2.5/linux # -------------------------------------------- # 03/01/16 rth@kanga.twiddle.net 1.944.1.4 # [ALPHA] Use direct calls to titan_ioremap/unmap when building # a titan specific kernel. # -------------------------------------------- # 03/01/16 ink@jurassic.park.msu.ru 1.944.1.5 # [PATCH] alpha irq proc update # From Jeff.Wiedemeier@hp.com: # # - Only create smp_affinity /proc nodes if a set_affinity handler # is provided. # - Limit the number of irq nodes that will be created in /proc # to avoid overfilling the /proc inode space. # -------------------------------------------- # 03/01/16 ink@jurassic.park.msu.ru 1.944.1.6 # [PATCH] alpha smp callin # From Jeff.Wiedemeier@hp.com: # # Add platform-specific callin for SMP. # -------------------------------------------- # 03/01/16 ak@muc.de 1.948 # [PATCH] x86_64 update # # x86-64 updates for 2.5.58. Changes only x86-64 specific files. # # - Rewrote module allocation. Lots of bugs fixed. Module loading # should work now again. # - Kconfig help fixes from Randy Dunlap # - Makefile cleanups from Pavel Machek and Sam Ravnborg # - Assembly cleanups from Pavel # - defconfig update # - Better strlen_user/strnlen_user # - Merge with i386: new ptrace commands, 32bit vsyscall signal trampolines # new deactivate_mm, add asm/bug.h # - Make sure initramfs is freed after booting (thanks to Kai for the hint) # - User per cpu data for profile counters (Ravikiran Thirumalai) # - 32bit compat_* updates from Stephen Rothwell # - Fix race in context switch. The exception handler for bogus segment # loads in __switch_to needs to keep interrupts disabled, otherwise an # interrupt can deadlock on scheduler locks. Also make sure they don't # printk or set oops_in_progress during printk because printk does a # wake_up too. # - Disable 64bit GS base changes for processes. I cannot get it to work # reliably. # - Clear IOPL on kernel entry # -------------------------------------------- # 03/01/16 hch@sgi.com 1.949 # [PATCH] remove MOD_IN_USE # # Another left-over from ancient module code, it was supposed to return # non-zero if the module has a use count, but currently it always # evaluates to 0. # # There are a few users of different types: # (1) ioctl that perform a while(MOD_IN_USE) MOD_DEC_USE_COUNT loop. # Just rip them out, we now have forced module unloading. # (2) printk's that moan if the use-count in not zero in the exitfunc. # Just rip them out, this can't happen. # (3) if(MOD_IN_USE) MOD_DEC_USE_COUNT constructs in ->close of a few # serial drivers. Just remove the conditional, we did a # MOD_INC_USE_COUNT in ->open. # (4) This one is interesting: drivers/sbus/char/display7seg.c uses # the module use count to track openers. Replace this with an # atomic_t. # # In addition remove tons of stale comments in network driver that aren't # understandable for anyone who doesn't know ancient Linux module semantics. # -------------------------------------------- # 03/01/16 mbligh@aracnet.com 1.950 # [PATCH] (1/3) Minimal NUMA scheduler # # Patch from Martin J. Bligh # # This adds a small hook to the find_busiest_queue routine to allow us to # specify a mask of which CPUs to search over. In the NUMA case, it will # only balance inside the node (much cheaper to search, and stops tasks # from bouncing across nodes, which is very costly). The cpus_to_balance # routine is conditionally defined to ensure no impact to non-NUMA machines. # # This is a tiny NUMA scheduler, but it needs the assistance of the second # and third patches in order to spread tasks across nodes. # -------------------------------------------- # 03/01/16 mbligh@aracnet.com 1.951 # [PATCH] (2/3) Initial load balancing # # Patch from Michael Hohnbaum # # This adds a hook, sched_balance_exec(), to the exec code, to make it # place the exec'ed task on the least loaded queue. We have less state # to move at exec time than fork time, so this is the cheapest point # to cross-node migrate. Experience in Dynix/PTX and testing on Linux # has confirmed that this is the cheapest time to move tasks between nodes. # # It also macro-wraps changes to nr_running, to allow us to keep track of # per-node nr_running as well. Again, no impact on non-NUMA machines. # -------------------------------------------- # 03/01/16 mbligh@aracnet.com 1.952 # [PATCH] (3/3) NUMA rebalancer # # Patch from Erich Focht # # This adds a hook to rebalance globally across nodes every NODE_BALANCE_RATE # iterations of the rebalancer. This allows us to easily tune on an architecture # specific basis how often we wish to rebalance - machines with higher NUMA # ratios (more expensive off-node access) will want to do this less often. # It's currently set to 100 for NUMA-Q and 10 for other machines. If the # imbalance between nodes is > 125%, we'll rebalance them. The hook for this # is added to the NUMA definition of cpus_to_balance, so again, no impact # on non-NUMA machines. # -------------------------------------------- # 03/01/16 rth@kanga.twiddle.net 1.944.1.7 # [ALPHA] AGP infrastructure for AGP implemented in Alpha corelogic # (Titan / Marvel), Kconfig and headers. # # From Jeff Wiedemeier. # -------------------------------------------- # 03/01/16 rth@kanga.twiddle.net 1.944.1.8 # [ALPHA] Marvel (AlphaServer ES47, ES80, GS1280) support. # From Jeff.Wiedemeier@hp.com. # -------------------------------------------- # 03/01/16 rth@kanga.twiddle.net 1.944.1.9 # [ALPHA] Fixups to Marvel and Titan for incomplete merging # of AGP and SRMCONS patches. # -------------------------------------------- # 03/01/16 rth@kanga.twiddle.net 1.944.1.10 # [ALPHA] Formatting cleanup, warning removal, move declarations # to header files where they belong. # -------------------------------------------- # 03/01/16 rth@kanga.twiddle.net 1.944.1.11 # [ALPHA] Correct io.h exports and inlining for marvel and titan. # -------------------------------------------- # 03/01/16 rth@kanga.twiddle.net 1.953 # Merge kanga.twiddle.net:/home/rth/linux/linus-2.5 # into kanga.twiddle.net:/home/rth/linux/axp-2.5 # -------------------------------------------- # 03/01/16 Jeff.Wiedemeier@hp.com 1.954 # [PATCH] Fix marvel irq count computation. # # Found a buglet in the marvel code -- doesn't change the number of IRQS # just the logic to get there.. This applies on top of the other marvel # code. # # /jeff # -------------------------------------------- # 03/01/16 torvalds@home.transmeta.com 1.955 # Merge bk://bk.arm.linux.org.uk # into home.transmeta.com:/home/torvalds/v2.5/linux # -------------------------------------------- # 03/01/16 torvalds@penguin.transmeta.com 1.956 # Linux v2.5.59 # -------------------------------------------- # 03/01/20 bcrl@redhat.com 1.946.1.1 # Remove struct scm_cookie * from socket send/recvmsg() ops. Credentials # are only used by af_unix and af_netlink anyways, so by only using them # in those paths we eliminate overhead from all other network protocols' # fastpaths. # -------------------------------------------- # diff -Nru a/arch/ia64/ia32/sys_ia32.c b/arch/ia64/ia32/sys_ia32.c --- a/arch/ia64/ia32/sys_ia32.c Mon Jan 20 16:00:08 2003 +++ b/arch/ia64/ia32/sys_ia32.c Mon Jan 20 16:00:08 2003 @@ -1649,20 +1649,21 @@ /* XXX This code needs massive updating... -DaveM */ lock_kernel(); { + struct scm_cookie scm; struct sock_iocb *si; struct kiocb iocb; init_sync_kiocb(&iocb, NULL); si = kiocb_to_siocb(&iocb); si->sock = sock; - si->scm = &si->async_scm; + si->scm = &scm; si->msg = &msg_sys; si->size = total_len; si->flags = flags; memset(si->scm, 0, sizeof(*si->scm)); err = sock->ops->recvmsg(&iocb, sock, &msg_sys, total_len, - flags, si->scm); + flags); if (-EIOCBQUEUED == err) err = wait_on_sync_kiocb(&iocb); diff -Nru a/arch/parisc/kernel/sys_parisc32.c b/arch/parisc/kernel/sys_parisc32.c --- a/arch/parisc/kernel/sys_parisc32.c Mon Jan 20 16:00:07 2003 +++ b/arch/parisc/kernel/sys_parisc32.c Mon Jan 20 16:00:07 2003 @@ -1600,21 +1600,23 @@ if (sock != NULL) { struct sock_iocb *si; struct kiocb iocb; + struct scm_cookie scm; if (sock->file->f_flags & O_NONBLOCK) user_flags |= MSG_DONTWAIT; + memset(&scm, 0, sizeof(scm)); init_sync_kiocb(&iocb, NULL); si = kiocb_to_siocb(&iocb); si->sock = sock; - si->scm = &si->async_scm; + si->scm = &scm; si->msg = &kern_msg; si->size = total_len; si->flags = user_flags; memset(si->scm, 0, sizeof(*si->scm)); err = sock->ops->recvmsg(&iocb, sock, &kern_msg, total_len, - user_flags, si->scm); + user_flags); if (-EIOCBQUEUED == err) err = wait_on_sync_kiocb(&iocb); diff -Nru a/arch/ppc64/kernel/sys_ppc32.c b/arch/ppc64/kernel/sys_ppc32.c --- a/arch/ppc64/kernel/sys_ppc32.c Mon Jan 20 16:00:08 2003 +++ b/arch/ppc64/kernel/sys_ppc32.c Mon Jan 20 16:00:08 2003 @@ -2833,21 +2833,23 @@ if (sock != NULL) { struct sock_iocb *si; struct kiocb iocb; + struct scm_cookie scm; if (sock->file->f_flags & O_NONBLOCK) user_flags |= MSG_DONTWAIT; + memset(&scm, 0, sizeof(scm)); init_sync_kiocb(&iocb, NULL); si = kiocb_to_siocb(&iocb); si->sock = sock; - si->scm = &si->async_scm; + si->scm = &scm; si->msg = &kern_msg; si->size = total_len; si->flags = user_flags; memset(si->scm, 0, sizeof(*si->scm)); err = sock->ops->recvmsg(&iocb, sock, &kern_msg, total_len, - user_flags, si->scm); + user_flags); if (-EIOCBQUEUED == err) err = wait_on_sync_kiocb(&iocb); diff -Nru a/arch/s390x/kernel/linux32.c b/arch/s390x/kernel/linux32.c --- a/arch/s390x/kernel/linux32.c Mon Jan 20 16:00:08 2003 +++ b/arch/s390x/kernel/linux32.c Mon Jan 20 16:00:08 2003 @@ -2390,24 +2390,25 @@ { struct sock_iocb *si; struct kiocb iocb; + struct scm_cookie scm; init_sync_kiocb(&iocb, NULL); si = kiocb_to_siocb(&iocb); si->sock = sock; - si->scm = &si->async_scm; + si->scm = &scm; si->msg = msg; si->size = size; si->flags = flags; memset(si->scm, 0, sizeof(*si->scm)); - size = sock->ops->recvmsg(&iocb, sock, msg, size, flags, si->scm); - if (size >= 0) - scm_recv32(sock, msg, si->scm, flags, cmsg_ptr); - + size = sock->ops->recvmsg(&iocb, sock, msg, size, flags); if (-EIOCBQUEUED == size) size = wait_on_sync_kiocb(&iocb); + + if (size >= 0) + scm_recv32(sock, msg, si->scm, flags, cmsg_ptr); return size; } diff -Nru a/arch/sparc64/kernel/sys_sparc32.c b/arch/sparc64/kernel/sys_sparc32.c --- a/arch/sparc64/kernel/sys_sparc32.c Mon Jan 20 16:00:08 2003 +++ b/arch/sparc64/kernel/sys_sparc32.c Mon Jan 20 16:00:08 2003 @@ -2421,6 +2421,7 @@ if (sock != NULL) { struct sock_iocb *si; struct kiocb iocb; + struct scm_cookie scm; if (sock->file->f_flags & O_NONBLOCK) user_flags |= MSG_DONTWAIT; @@ -2428,14 +2429,14 @@ init_sync_kiocb(&iocb, NULL); si = kiocb_to_siocb(&iocb); si->sock = sock; - si->scm = &si->async_scm; + si->scm = &scm; si->msg = &kern_msg; si->size = total_len; si->flags = user_flags; memset(si->scm, 0, sizeof(*si->scm)); err = sock->ops->recvmsg(&iocb, sock, &kern_msg, total_len, - user_flags, si->scm); + user_flags); if (-EIOCBQUEUED == err) err = wait_on_sync_kiocb(&iocb); diff -Nru a/arch/x86_64/ia32/socket32.c b/arch/x86_64/ia32/socket32.c --- a/arch/x86_64/ia32/socket32.c Mon Jan 20 16:00:07 2003 +++ b/arch/x86_64/ia32/socket32.c Mon Jan 20 16:00:07 2003 @@ -442,6 +442,7 @@ if (sock != NULL) { struct sock_iocb *si; struct kiocb iocb; + struct scm_cookie scm; if (sock->file->f_flags & O_NONBLOCK) user_flags |= MSG_DONTWAIT; @@ -449,14 +450,14 @@ init_sync_kiocb(&iocb, NULL); si = kiocb_to_siocb(&iocb); si->sock = sock; - si->scm = &si->async_scm; + si->scm = &scm; si->msg = &kern_msg; si->size = total_len; si->flags = user_flags; memset(si->scm, 0, sizeof(*si->scm)); err = sock->ops->recvmsg(&iocb, sock, &kern_msg, total_len, - user_flags, si->scm); + user_flags); if (-EIOCBQUEUED == err) err = wait_on_sync_kiocb(&iocb); diff -Nru a/drivers/net/pppoe.c b/drivers/net/pppoe.c --- a/drivers/net/pppoe.c Mon Jan 20 16:00:08 2003 +++ b/drivers/net/pppoe.c Mon Jan 20 16:00:08 2003 @@ -777,7 +777,7 @@ int pppoe_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *m, - int total_len, struct scm_cookie *scm) + int total_len) { struct sk_buff *skb = NULL; struct sock *sk = sock->sk; @@ -937,7 +937,8 @@ struct ppp_channel_ops pppoe_chan_ops = { pppoe_xmit , NULL }; -int pppoe_rcvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *m, int total_len, int flags, struct scm_cookie *scm) +int pppoe_recvmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *m, int total_len, int flags) { struct sock *sk = sock->sk; struct sk_buff *skb = NULL; @@ -1089,7 +1090,7 @@ .setsockopt = sock_no_setsockopt, .getsockopt = sock_no_getsockopt, .sendmsg = pppoe_sendmsg, - .recvmsg = pppoe_rcvmsg, + .recvmsg = pppoe_recvmsg, .mmap = sock_no_mmap }; diff -Nru a/fs/smbfs/sock.c b/fs/smbfs/sock.c --- a/fs/smbfs/sock.c Mon Jan 20 16:00:07 2003 +++ b/fs/smbfs/sock.c Mon Jan 20 16:00:07 2003 @@ -41,8 +41,6 @@ { struct iovec iov; struct msghdr msg; - struct kiocb iocb; - struct sock_iocb *si; mm_segment_t fs; fs = get_fs(); @@ -58,21 +56,7 @@ iov.iov_base = ubuf; iov.iov_len = size; - init_sync_kiocb(&iocb, NULL); - si = kiocb_to_siocb(&iocb); - si->sock = socket; - si->scm = &si->async_scm; - si->msg = &msg; - si->size = size; - si->flags = flags; - - memset(si->scm, 0, sizeof(*si->scm)); - - size = socket->ops->recvmsg(&iocb, socket, &msg, size, flags, si->scm); - if (size >= 0) - scm_recv(socket, &msg, si->scm, flags); - if (-EIOCBQUEUED == size) - size = wait_on_sync_kiocb(&iocb); + size = sock_recvmsg(socket, &msg, size, flags); set_fs(fs); return size; @@ -299,8 +283,6 @@ unsigned int flags; struct iovec iov; struct msghdr msg; - struct kiocb iocb; - struct sock_iocb *si; mm_segment_t fs; int rlen = smb_len(server->header) - server->smb_read + 4; int result = -EIO; @@ -327,21 +309,7 @@ if (rlen > PAGE_SIZE) rlen = PAGE_SIZE; - init_sync_kiocb(&iocb, NULL); - si = kiocb_to_siocb(&iocb); - si->sock = sock; - si->scm = &si->async_scm; - si->msg = &msg; - si->size = rlen; - si->flags = flags; - - memset(si->scm, 0, sizeof(*si->scm)); - - result = sock->ops->recvmsg(&iocb, sock, &msg, rlen, flags, si->scm); - if (result >= 0) - scm_recv(sock, &msg, si->scm, flags); - if (-EIOCBQUEUED == result) - result = wait_on_sync_kiocb(&iocb); + result = sock_recvmsg(sock, &msg, rlen, flags); set_fs(fs); @@ -370,8 +338,6 @@ unsigned int flags; struct iovec iov[4]; struct msghdr msg; - struct kiocb iocb; - struct sock_iocb *si; mm_segment_t fs; int rlen; int result = -EIO; @@ -398,21 +364,7 @@ if (req->rq_rlen < rlen) rlen = req->rq_rlen; - init_sync_kiocb(&iocb, NULL); - si = kiocb_to_siocb(&iocb); - si->sock = sock; - si->scm = &si->async_scm; - si->msg = &msg; - si->size = rlen; - si->flags = flags; - - memset(si->scm, 0, sizeof(*si->scm)); - - result = sock->ops->recvmsg(&iocb, sock, &msg, rlen, flags, si->scm); - if (result >= 0) - scm_recv(sock, &msg, si->scm, flags); - if (-EIOCBQUEUED == result) - result = wait_on_sync_kiocb(&iocb); + result = sock_recvmsg(sock, &msg, rlen, flags); set_fs(fs); @@ -440,8 +392,6 @@ mm_segment_t fs; struct smb_sb_info *server = req->rq_server; struct socket *sock; - struct kiocb iocb; - struct sock_iocb *si; struct msghdr msg; int slen = req->rq_slen - req->rq_bytes_sent; int result = -EIO; @@ -465,23 +415,9 @@ if (req->rq_bytes_sent) smb_move_iov(&msg, iov, req->rq_bytes_sent); - init_sync_kiocb(&iocb, NULL); - si = kiocb_to_siocb(&iocb); - si->scm = &si->async_scm; - si->sock = sock; - si->msg = &msg; - si->size = slen; - fs = get_fs(); set_fs(get_ds()); - result = scm_send(sock, &msg, si->scm); - if (result >= 0) { - result = sock->ops->sendmsg(&iocb, sock, &msg, slen, si->scm); - if (-EIOCBQUEUED != result) - scm_destroy(si->scm); - } - if (-EIOCBQUEUED == result) - result = wait_on_sync_kiocb(&iocb); + result = sock_sendmsg(sock, &msg, slen); set_fs(fs); if (result >= 0) { diff -Nru a/include/linux/net.h b/include/linux/net.h --- a/include/linux/net.h Mon Jan 20 16:00:07 2003 +++ b/include/linux/net.h Mon Jan 20 16:00:07 2003 @@ -78,7 +78,6 @@ unsigned char passcred; }; -struct scm_cookie; struct vm_area_struct; struct page; struct kiocb; @@ -106,11 +105,9 @@ int (*getsockopt) (struct socket *sock, int level, int optname, char *optval, int *optlen); int (*sendmsg) (struct kiocb *iocb, struct socket *sock, - struct msghdr *m, int total_len, - struct scm_cookie *scm); + struct msghdr *m, int total_len); int (*recvmsg) (struct kiocb *iocb, struct socket *sock, - struct msghdr *m, int total_len, int flags, - struct scm_cookie *scm); + struct msghdr *m, int total_len, int flags); int (*mmap) (struct file *file, struct socket *sock, struct vm_area_struct * vma); ssize_t (*sendpage) (struct socket *sock, struct page *page, int offset, size_t size, int flags); }; @@ -202,10 +199,10 @@ char *optval, int optlen), (sock, level, optname, optval, optlen)) \ SOCKCALL_WRAP(name, getsockopt, (struct socket *sock, int level, int optname, \ char *optval, int *optlen), (sock, level, optname, optval, optlen)) \ -SOCKCALL_WRAP(name, sendmsg, (struct kiocb *iocb, struct socket *sock, struct msghdr *m, int len, struct scm_cookie *scm), \ - (iocb, sock, m, len, scm)) \ -SOCKCALL_WRAP(name, recvmsg, (struct kiocb *iocb, struct socket *sock, struct msghdr *m, int len, int flags, struct scm_cookie *scm), \ - (iocb, sock, m, len, flags, scm)) \ +SOCKCALL_WRAP(name, sendmsg, (struct kiocb *iocb, struct socket *sock, struct msghdr *m, int len), \ + (iocb, sock, m, len)) \ +SOCKCALL_WRAP(name, recvmsg, (struct kiocb *iocb, struct socket *sock, struct msghdr *m, int len, int flags), \ + (iocb, sock, m, len, flags)) \ SOCKCALL_WRAP(name, mmap, (struct file *file, struct socket *sock, struct vm_area_struct *vma), \ (file, sock, vma)) \ \ diff -Nru a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h --- a/include/net/bluetooth/bluetooth.h Mon Jan 20 16:00:07 2003 +++ b/include/net/bluetooth/bluetooth.h Mon Jan 20 16:00:07 2003 @@ -128,7 +128,7 @@ struct sock *bt_sock_alloc(struct socket *sock, int proto, int pi_size, int prio); void bt_sock_link(struct bt_sock_list *l, struct sock *s); void bt_sock_unlink(struct bt_sock_list *l, struct sock *s); -int bt_sock_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int len, int flags, struct scm_cookie *scm); +int bt_sock_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int len, int flags); uint bt_sock_poll(struct file * file, struct socket *sock, poll_table *wait); int bt_sock_w4_connect(struct sock *sk, int flags); diff -Nru a/include/net/inet_common.h b/include/net/inet_common.h --- a/include/net/inet_common.h Mon Jan 20 16:00:08 2003 +++ b/include/net/inet_common.h Mon Jan 20 16:00:08 2003 @@ -23,11 +23,11 @@ extern int inet_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *ubuf, - int size, int flags, struct scm_cookie *scm); + int size, int flags); extern int inet_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, - int size, struct scm_cookie *scm); + int size); extern int inet_shutdown(struct socket *sock, int how); extern unsigned int inet_poll(struct file * file, struct socket *sock, struct poll_table_struct *wait); extern int inet_setsockopt(struct socket *sock, int level, diff -Nru a/include/net/sock.h b/include/net/sock.h --- a/include/net/sock.h Mon Jan 20 16:00:08 2003 +++ b/include/net/sock.h Mon Jan 20 16:00:08 2003 @@ -51,7 +51,6 @@ #include #include -#include /* * This structure really needs to be cleaned up. @@ -305,9 +304,9 @@ int size; struct socket *sock; struct sock *sk; + struct scm_cookie *scm; struct msghdr *msg, async_msg; struct iovec async_iov; - struct scm_cookie *scm, async_scm; }; static inline struct sock_iocb *kiocb_to_siocb(struct kiocb *iocb) @@ -433,11 +432,9 @@ extern int sock_no_setsockopt(struct socket *, int, int, char *, int); extern int sock_no_sendmsg(struct kiocb *, struct socket *, - struct msghdr *, int, - struct scm_cookie *); + struct msghdr *, int); extern int sock_no_recvmsg(struct kiocb *, struct socket *, - struct msghdr *, int, int, - struct scm_cookie *); + struct msghdr *, int, int); extern int sock_no_mmap(struct file *file, struct socket *sock, struct vm_area_struct *vma); diff -Nru a/net/appletalk/ddp.c b/net/appletalk/ddp.c --- a/net/appletalk/ddp.c Mon Jan 20 16:00:08 2003 +++ b/net/appletalk/ddp.c Mon Jan 20 16:00:08 2003 @@ -1492,7 +1492,7 @@ } static int atalk_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, - int len, struct scm_cookie *scm) + int len) { struct sock *sk = sock->sk; struct atalk_sock *at = at_sk(sk); @@ -1651,7 +1651,7 @@ } static int atalk_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, - int size, int flags, struct scm_cookie *scm) + int size, int flags) { struct sock *sk = sock->sk; struct sockaddr_at *sat = (struct sockaddr_at *)msg->msg_name; diff -Nru a/net/atm/common.c b/net/atm/common.c --- a/net/atm/common.c Mon Jan 20 16:00:08 2003 +++ b/net/atm/common.c Mon Jan 20 16:00:08 2003 @@ -337,7 +337,7 @@ int atm_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *m, - int total_len, int flags, struct scm_cookie *scm) + int total_len, int flags) { DECLARE_WAITQUEUE(wait,current); struct atm_vcc *vcc; @@ -418,7 +418,7 @@ int atm_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *m, - int total_len, struct scm_cookie *scm) + int total_len) { DECLARE_WAITQUEUE(wait,current); struct atm_vcc *vcc; diff -Nru a/net/atm/common.h b/net/atm/common.h --- a/net/atm/common.h Mon Jan 20 16:00:08 2003 +++ b/net/atm/common.h Mon Jan 20 16:00:08 2003 @@ -14,9 +14,9 @@ int atm_release(struct socket *sock); int atm_connect(struct socket *sock,int itf,short vpi,int vci); int atm_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *m, - int total_len, int flags, struct scm_cookie *scm); + int total_len, int flags); int atm_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *m, - int total_len, struct scm_cookie *scm); + int total_len); unsigned int atm_poll(struct file *file,struct socket *sock,poll_table *wait); int atm_ioctl(struct socket *sock,unsigned int cmd,unsigned long arg); int atm_setsockopt(struct socket *sock,int level,int optname,char *optval, diff -Nru a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c --- a/net/ax25/af_ax25.c Mon Jan 20 16:00:08 2003 +++ b/net/ax25/af_ax25.c Mon Jan 20 16:00:08 2003 @@ -1411,8 +1411,7 @@ } static int ax25_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, - struct scm_cookie *scm) + struct msghdr *msg, int len) { struct sockaddr_ax25 *usax = (struct sockaddr_ax25 *)msg->msg_name; struct sock *sk = sock->sk; @@ -1590,7 +1589,7 @@ } static int ax25_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, int flags, struct scm_cookie *scm) + struct msghdr *msg, int size, int flags) { struct sock *sk = sock->sk; struct sk_buff *skb; diff -Nru a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c --- a/net/bluetooth/af_bluetooth.c Mon Jan 20 16:00:07 2003 +++ b/net/bluetooth/af_bluetooth.c Mon Jan 20 16:00:07 2003 @@ -212,7 +212,7 @@ } int bt_sock_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, int flags, struct scm_cookie *scm) + struct msghdr *msg, int len, int flags) { int noblock = flags & MSG_DONTWAIT; struct sock *sk = sock->sk; diff -Nru a/net/bluetooth/bnep/core.c b/net/bluetooth/bnep/core.c --- a/net/bluetooth/bnep/core.c Mon Jan 20 16:00:08 2003 +++ b/net/bluetooth/bnep/core.c Mon Jan 20 16:00:08 2003 @@ -97,26 +97,12 @@ static int bnep_send(struct bnep_session *s, void *data, size_t len) { - struct kiocb iocb; - struct sock_iocb *si; struct socket *sock = s->sock; struct iovec iv = { data, len }; - int err; s->msg.msg_iov = &iv; s->msg.msg_iovlen = 1; - init_sync_kiocb(&iocb, NULL); - si = kiocb_to_siocb(&iocb); - si->scm = NULL; - si->sock = sock; - si->msg = &s->msg; - si->size = len; - - err = sock->ops->sendmsg(&iocb, sock, &s->msg, len, NULL); - if (-EIOCBQUEUED == err) - err = wait_on_sync_kiocb(&iocb); - - return err; + return sock_sendmsg(sock, &s->msg, len); } static int bnep_send_rsp(struct bnep_session *s, u8 ctrl, u16 resp) @@ -442,20 +428,9 @@ /* FIXME: linearize skb */ { - struct kiocb iocb; - struct sock_iocb *si; - s->msg.msg_iov = iv; s->msg.msg_iovlen = il; - init_sync_kiocb(&iocb, NULL); - si = kiocb_to_siocb(&iocb); - si->scm = NULL; - si->sock = sock; - si->msg = &s->msg; - si->size = len; - len = sock->ops->sendmsg(&iocb, sock, &s->msg, len, NULL); - if (-EIOCBQUEUED == len) - len = wait_on_sync_kiocb(&iocb); + len = sock_sendmsg(sock, &s->msg, len); } kfree_skb(skb); diff -Nru a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c --- a/net/bluetooth/hci_sock.c Mon Jan 20 16:00:08 2003 +++ b/net/bluetooth/hci_sock.c Mon Jan 20 16:00:08 2003 @@ -316,7 +316,7 @@ put_cmsg(msg, SOL_HCI, HCI_CMSG_TSTAMP, sizeof(skb->stamp), &skb->stamp); } -static int hci_sock_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int len, int flags, struct scm_cookie *scm) +static int hci_sock_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int len, int flags) { int noblock = flags & MSG_DONTWAIT; struct sock *sk = sock->sk; @@ -352,8 +352,7 @@ return err ? : copied; } -static int hci_sock_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int len, - struct scm_cookie *scm) +static int hci_sock_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int len) { struct sock *sk = sock->sk; struct hci_dev *hdev; diff -Nru a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c --- a/net/bluetooth/l2cap.c Mon Jan 20 16:00:08 2003 +++ b/net/bluetooth/l2cap.c Mon Jan 20 16:00:08 2003 @@ -709,7 +709,7 @@ return err; } -static int l2cap_sock_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int len, struct scm_cookie *scm) +static int l2cap_sock_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int len) { struct sock *sk = sock->sk; int err = 0; diff -Nru a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c --- a/net/bluetooth/rfcomm/core.c Mon Jan 20 16:00:07 2003 +++ b/net/bluetooth/rfcomm/core.c Mon Jan 20 16:00:07 2003 @@ -604,29 +604,17 @@ /* ---- RFCOMM frame sending ---- */ static int rfcomm_send_frame(struct rfcomm_session *s, u8 *data, int len) { - struct kiocb iocb; - struct sock_iocb *si; struct socket *sock = s->sock; struct iovec iv = { data, len }; struct msghdr msg; - int err; BT_DBG("session %p len %d", s, len); memset(&msg, 0, sizeof(msg)); msg.msg_iovlen = 1; msg.msg_iov = &iv; - init_sync_kiocb(&iocb, NULL); - si = kiocb_to_siocb(&iocb); - si->scm = NULL; - si->sock = sock; - si->msg = &msg; - si->size = len; - - err = sock->ops->sendmsg(&iocb, sock, &msg, len, NULL); - if (-EIOCBQUEUED == err) - err = wait_on_sync_kiocb(&iocb); - return err; + + return sock_sendmsg(sock, &msg, len); } static int rfcomm_send_sabm(struct rfcomm_session *s, u8 dlci) @@ -838,13 +826,10 @@ static int rfcomm_send_test(struct rfcomm_session *s, int cr, u8 *pattern, int len) { - struct kiocb iocb; - struct sock_iocb *si; struct socket *sock = s->sock; struct iovec iv[3]; struct msghdr msg; unsigned char hdr[5], crc[1]; - int err; if (len > 125) return -EINVAL; @@ -869,18 +854,8 @@ memset(&msg, 0, sizeof(msg)); msg.msg_iovlen = 3; msg.msg_iov = iv; - init_sync_kiocb(&iocb, NULL); - si = kiocb_to_siocb(&iocb); - si->scm = NULL; - si->sock = sock; - si->msg = &msg; - si->size = 6 + len; - - err = sock->ops->sendmsg(&iocb, sock, &msg, 6 + len, NULL); - if (-EIOCBQUEUED == err) - err = wait_on_sync_kiocb(&iocb); - return err; + return sock_sendmsg(sock, &msg, 6 + len); } static int rfcomm_send_credits(struct rfcomm_session *s, u8 addr, u8 credits) diff -Nru a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c --- a/net/bluetooth/rfcomm/sock.c Mon Jan 20 16:00:08 2003 +++ b/net/bluetooth/rfcomm/sock.c Mon Jan 20 16:00:08 2003 @@ -479,7 +479,7 @@ } static int rfcomm_sock_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, struct scm_cookie *scm) + struct msghdr *msg, int len) { struct sock *sk = sock->sk; struct rfcomm_dlc *d = rfcomm_pi(sk)->dlc; @@ -553,8 +553,7 @@ } static int rfcomm_sock_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, int flags, - struct scm_cookie *scm) + struct msghdr *msg, int size, int flags) { struct sock *sk = sock->sk; int target, err = 0, copied = 0; diff -Nru a/net/bluetooth/sco.c b/net/bluetooth/sco.c --- a/net/bluetooth/sco.c Mon Jan 20 16:00:07 2003 +++ b/net/bluetooth/sco.c Mon Jan 20 16:00:07 2003 @@ -632,7 +632,7 @@ return 0; } -static int sco_sock_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int len, struct scm_cookie *scm) +static int sco_sock_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int len) { struct sock *sk = sock->sk; int err = 0; diff -Nru a/net/core/sock.c b/net/core/sock.c --- a/net/core/sock.c Mon Jan 20 16:00:08 2003 +++ b/net/core/sock.c Mon Jan 20 16:00:08 2003 @@ -960,13 +960,13 @@ } int sock_no_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *m, - int flags, struct scm_cookie *scm) + int flags) { return -EOPNOTSUPP; } int sock_no_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *m, - int len, int flags, struct scm_cookie *scm) + int len, int flags) { return -EOPNOTSUPP; } diff -Nru a/net/decnet/af_decnet.c b/net/decnet/af_decnet.c --- a/net/decnet/af_decnet.c Mon Jan 20 16:00:08 2003 +++ b/net/decnet/af_decnet.c Mon Jan 20 16:00:08 2003 @@ -1718,7 +1718,7 @@ static int dn_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, int flags, struct scm_cookie *scm) + struct msghdr *msg, int size, int flags) { struct sock *sk = sock->sk; struct dn_scp *scp = DN_SK(sk); @@ -1889,7 +1889,7 @@ } static int dn_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, struct scm_cookie *scm) + struct msghdr *msg, int size) { struct sock *sk = sock->sk; struct dn_scp *scp = DN_SK(sk); diff -Nru a/net/econet/af_econet.c b/net/econet/af_econet.c --- a/net/econet/af_econet.c Mon Jan 20 16:00:07 2003 +++ b/net/econet/af_econet.c Mon Jan 20 16:00:07 2003 @@ -126,8 +126,7 @@ */ static int econet_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, int flags, - struct scm_cookie *scm) + struct msghdr *msg, int len, int flags) { struct sock *sk = sock->sk; struct sk_buff *skb; @@ -260,7 +259,7 @@ */ static int econet_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, struct scm_cookie *scm) + struct msghdr *msg, int len) { struct sock *sk = sock->sk; struct sockaddr_ec *saddr=(struct sockaddr_ec *)msg->msg_name; diff -Nru a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c --- a/net/ipv4/af_inet.c Mon Jan 20 16:00:07 2003 +++ b/net/ipv4/af_inet.c Mon Jan 20 16:00:07 2003 @@ -730,7 +730,7 @@ int inet_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, - int size, int flags, struct scm_cookie *scm) + int size, int flags) { struct sock *sk = sock->sk; int addr_len = 0; @@ -745,7 +745,7 @@ int inet_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, - int size, struct scm_cookie *scm) + int size) { struct sock *sk = sock->sk; diff -Nru a/net/ipx/af_ipx.c b/net/ipx/af_ipx.c --- a/net/ipx/af_ipx.c Mon Jan 20 16:00:07 2003 +++ b/net/ipx/af_ipx.c Mon Jan 20 16:00:07 2003 @@ -2010,7 +2010,7 @@ } static int ipx_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, struct scm_cookie *scm) + struct msghdr *msg, int len) { struct sock *sk = sock->sk; struct ipx_opt *ipxs = ipx_sk(sk); @@ -2070,7 +2070,7 @@ static int ipx_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, int flags, struct scm_cookie *scm) + struct msghdr *msg, int size, int flags) { struct sock *sk = sock->sk; struct ipx_opt *ipxs = ipx_sk(sk); diff -Nru a/net/irda/af_irda.c b/net/irda/af_irda.c --- a/net/irda/af_irda.c Mon Jan 20 16:00:07 2003 +++ b/net/irda/af_irda.c Mon Jan 20 16:00:07 2003 @@ -1253,14 +1253,14 @@ } /* - * Function irda_sendmsg (iocb, sock, msg, len, scm) + * Function irda_sendmsg (iocb, sock, msg, len) * * Send message down to TinyTP. This function is used for both STREAM and * SEQPACK services. This is possible since it forces the client to * fragment the message if necessary */ static int irda_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, struct scm_cookie *scm) + struct msghdr *msg, int len) { struct sock *sk = sock->sk; struct irda_sock *self; @@ -1326,14 +1326,13 @@ } /* - * Function irda_recvmsg_dgram (iocb, sock, msg, size, flags, scm) + * Function irda_recvmsg_dgram (iocb, sock, msg, size, flags) * * Try to receive message and copy it to user. The frame is discarded * after being read, regardless of how much the user actually read */ static int irda_recvmsg_dgram(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, int flags, - struct scm_cookie *scm) + struct msghdr *msg, int size, int flags) { struct sock *sk = sock->sk; struct irda_sock *self = irda_sk(sk); @@ -1380,11 +1379,10 @@ } /* - * Function irda_recvmsg_stream (iocb, sock, msg, size, flags, scm) + * Function irda_recvmsg_stream (iocb, sock, msg, size, flags) */ static int irda_recvmsg_stream(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, int flags, - struct scm_cookie *scm) + struct msghdr *msg, int size, int flags) { struct sock *sk = sock->sk; struct irda_sock *self = irda_sk(sk); @@ -1504,14 +1502,14 @@ } /* - * Function irda_sendmsg_dgram (iocb, sock, msg, len, scm) + * Function irda_sendmsg_dgram (iocb, sock, msg, len) * * Send message down to TinyTP for the unreliable sequenced * packet service... * */ static int irda_sendmsg_dgram(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, struct scm_cookie *scm) + struct msghdr *msg, int len) { struct sock *sk = sock->sk; struct irda_sock *self; @@ -1570,14 +1568,14 @@ } /* - * Function irda_sendmsg_ultra (iocb, sock, msg, len, scm) + * Function irda_sendmsg_ultra (iocb, sock, msg, len) * * Send message down to IrLMP for the unreliable Ultra * packet service... */ #ifdef CONFIG_IRDA_ULTRA static int irda_sendmsg_ultra(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, struct scm_cookie *scm) + struct msghdr *msg, int len) { struct sock *sk = sock->sk; struct irda_sock *self; diff -Nru a/net/key/af_key.c b/net/key/af_key.c --- a/net/key/af_key.c Mon Jan 20 16:00:07 2003 +++ b/net/key/af_key.c Mon Jan 20 16:00:07 2003 @@ -2141,8 +2141,7 @@ } static int pfkey_sendmsg(struct kiocb *kiocb, - struct socket *sock, struct msghdr *msg, int len, - struct scm_cookie *scm) + struct socket *sock, struct msghdr *msg, int len) { struct sock *sk = sock->sk; struct sk_buff *skb = NULL; @@ -2185,7 +2184,7 @@ static int pfkey_recvmsg(struct kiocb *kiocb, struct socket *sock, struct msghdr *msg, int len, - int flags, struct scm_cookie *scm) + int flags) { struct sock *sk = sock->sk; struct sk_buff *skb; diff -Nru a/net/llc/af_llc.c b/net/llc/af_llc.c --- a/net/llc/af_llc.c Mon Jan 20 16:00:07 2003 +++ b/net/llc/af_llc.c Mon Jan 20 16:00:07 2003 @@ -672,14 +672,12 @@ * @msg: Various user space related information. * @size: Size of user buffer. * @flags: User specified flags. - * @scm: Unknown. * * Copy received data to the socket user. * Returns non-negative upon success, negative otherwise. */ static int llc_ui_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, int flags, - struct scm_cookie *scm) + struct msghdr *msg, int size, int flags) { struct sock *sk = sock->sk; struct sockaddr_llc *uaddr = (struct sockaddr_llc *)msg->msg_name; @@ -727,13 +725,12 @@ * @sock: Socket to transmit data from. * @msg: Various user related information. * @len: Length of data to transmit. - * @scm: Unknown. * * Transmit data provided by the socket user. * Returns non-negative upon success, negative otherwise. */ static int llc_ui_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, struct scm_cookie *scm) + struct msghdr *msg, int len) { struct sock *sk = sock->sk; struct llc_opt *llc = llc_sk(sk); diff -Nru a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c --- a/net/netlink/af_netlink.c Mon Jan 20 16:00:08 2003 +++ b/net/netlink/af_netlink.c Mon Jan 20 16:00:08 2003 @@ -584,10 +584,10 @@ read_unlock(&nl_table_lock); } -static int netlink_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, - struct scm_cookie *scm) +static int netlink_sendmsg(struct kiocb *kiocb, struct socket *sock, + struct msghdr *msg, int len) { + struct sock_iocb *siocb = kiocb_to_siocb(kiocb); struct sock *sk = sock->sk; struct netlink_opt *nlk = nlk_sk(sk); struct sockaddr_nl *addr=msg->msg_name; @@ -595,10 +595,17 @@ u32 dst_groups; struct sk_buff *skb; int err; + struct scm_cookie scm; if (msg->msg_flags&MSG_OOB) return -EOPNOTSUPP; + if (NULL == siocb->scm) + siocb->scm = &scm; + err = scm_send(sock, msg, siocb->scm); + if (err < 0) + return err; + if (msg->msg_namelen) { if (addr->nl_family != AF_NETLINK) return -EINVAL; @@ -629,7 +636,7 @@ NETLINK_CB(skb).groups = nlk->groups; NETLINK_CB(skb).dst_pid = dst_pid; NETLINK_CB(skb).dst_groups = dst_groups; - memcpy(NETLINK_CREDS(skb), &scm->creds, sizeof(struct ucred)); + memcpy(NETLINK_CREDS(skb), &siocb->scm->creds, sizeof(struct ucred)); /* What can I do? Netlink is asynchronous, so that we will have to save current capabilities to @@ -654,10 +661,12 @@ return err; } -static int netlink_recvmsg(struct kiocb *iocb, struct socket *sock, +static int netlink_recvmsg(struct kiocb *kiocb, struct socket *sock, struct msghdr *msg, int len, - int flags, struct scm_cookie *scm) + int flags) { + struct sock_iocb *siocb = kiocb_to_siocb(kiocb); + struct scm_cookie scm; struct sock *sk = sock->sk; struct netlink_opt *nlk = nlk_sk(sk); int noblock = flags&MSG_DONTWAIT; @@ -693,11 +702,17 @@ msg->msg_namelen = sizeof(*addr); } - scm->creds = *NETLINK_CREDS(skb); + if (NULL == siocb->scm) { + memset(&scm, 0, sizeof(scm)); + siocb->scm = &scm; + } + siocb->scm->creds = *NETLINK_CREDS(skb); skb_free_datagram(sk, skb); if (nlk->cb && atomic_read(&sk->rmem_alloc) <= sk->rcvbuf / 2) netlink_dump(sk); + + scm_recv(sock, msg, siocb->scm, flags); out: if (skb_queue_len(&sk->receive_queue) <= sk->rcvbuf/2) { diff -Nru a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c --- a/net/netrom/af_netrom.c Mon Jan 20 16:00:07 2003 +++ b/net/netrom/af_netrom.c Mon Jan 20 16:00:08 2003 @@ -967,7 +967,7 @@ } static int nr_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, struct scm_cookie *scm) + struct msghdr *msg, int len) { struct sock *sk = sock->sk; nr_cb *nr = nr_sk(sk); @@ -1058,8 +1058,7 @@ } static int nr_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, int flags, - struct scm_cookie *scm) + struct msghdr *msg, int size, int flags) { struct sock *sk = sock->sk; struct sockaddr_ax25 *sax = (struct sockaddr_ax25 *)msg->msg_name; diff -Nru a/net/packet/af_packet.c b/net/packet/af_packet.c --- a/net/packet/af_packet.c Mon Jan 20 16:00:08 2003 +++ b/net/packet/af_packet.c Mon Jan 20 16:00:08 2003 @@ -280,8 +280,7 @@ */ static int packet_sendmsg_spkt(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, - struct scm_cookie *scm) + struct msghdr *msg, int len) { struct sock *sk = sock->sk; struct sockaddr_pkt *saddr=(struct sockaddr_pkt *)msg->msg_name; @@ -658,7 +657,7 @@ static int packet_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, struct scm_cookie *scm) + struct msghdr *msg, int len) { struct sock *sk = sock->sk; struct sockaddr_ll *saddr=(struct sockaddr_ll *)msg->msg_name; @@ -1013,8 +1012,7 @@ */ static int packet_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, - int flags, struct scm_cookie *scm) + struct msghdr *msg, int len, int flags) { struct sock *sk = sock->sk; struct sk_buff *skb; diff -Nru a/net/rose/af_rose.c b/net/rose/af_rose.c --- a/net/rose/af_rose.c Mon Jan 20 16:00:08 2003 +++ b/net/rose/af_rose.c Mon Jan 20 16:00:08 2003 @@ -1026,7 +1026,7 @@ } static int rose_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, struct scm_cookie *scm) + struct msghdr *msg, int len) { struct sock *sk = sock->sk; rose_cb *rose = rose_sk(sk); @@ -1190,8 +1190,7 @@ static int rose_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, int flags, - struct scm_cookie *scm) + struct msghdr *msg, int size, int flags) { struct sock *sk = sock->sk; rose_cb *rose = rose_sk(sk); diff -Nru a/net/socket.c b/net/socket.c --- a/net/socket.c Mon Jan 20 16:00:07 2003 +++ b/net/socket.c Mon Jan 20 16:00:07 2003 @@ -89,7 +89,6 @@ #include #include -#include #include static int sock_no_open(struct inode *irrelevant, struct file *dontcare); @@ -517,23 +516,16 @@ sock->file=NULL; } -static int __sock_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int size) +static inline int __sock_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int size) { struct sock_iocb *si = kiocb_to_siocb(iocb); - int err; - si->scm = &si->async_scm; si->sock = sock; + si->scm = NULL; si->msg = msg; si->size = size; - err = scm_send(sock, msg, si->scm); - if (err >= 0) { - err = sock->ops->sendmsg(iocb, sock, msg, size, si->scm); - if (-EIOCBQUEUED != err) - scm_destroy(si->scm); - } - return err; + return sock->ops->sendmsg(iocb, sock, msg, size); } int sock_sendmsg(struct socket *sock, struct msghdr *msg, int size) @@ -549,24 +541,17 @@ } -int __sock_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int size, int flags) +static inline int __sock_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int size, int flags) { struct sock_iocb *si = kiocb_to_siocb(iocb); si->sock = sock; - si->scm = &si->async_scm; - si->sock = sock; + si->scm = NULL; si->msg = msg; si->size = size; si->flags = flags; - memset(si->scm, 0, sizeof(*si->scm)); - - size = sock->ops->recvmsg(iocb, sock, msg, size, flags, si->scm); - if (size >= 0) - scm_recv(sock, msg, si->scm, flags); - - return size; + return sock->ops->recvmsg(iocb, sock, msg, size, flags); } int sock_recvmsg(struct socket *sock, struct msghdr *msg, int size, int flags) diff -Nru a/net/unix/af_unix.c b/net/unix/af_unix.c --- a/net/unix/af_unix.c Mon Jan 20 16:00:08 2003 +++ b/net/unix/af_unix.c Mon Jan 20 16:00:08 2003 @@ -1180,10 +1180,10 @@ * Send AF_UNIX data. */ -static int unix_dgram_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, - struct scm_cookie *scm) +static int unix_dgram_sendmsg(struct kiocb *kiocb, struct socket *sock, + struct msghdr *msg, int len) { + struct sock_iocb *siocb = kiocb_to_siocb(kiocb); struct sock *sk = sock->sk; struct unix_sock *u = unix_sk(sk); struct sockaddr_un *sunaddr=msg->msg_name; @@ -1193,6 +1193,13 @@ unsigned hash; struct sk_buff *skb; long timeo; + struct scm_cookie scm; + + if (NULL == siocb->scm) + siocb->scm = &scm; + err = scm_send(sock, msg, siocb->scm); + if (err < 0) + return err; err = -EOPNOTSUPP; if (msg->msg_flags&MSG_OOB) @@ -1222,9 +1229,9 @@ if (skb==NULL) goto out; - memcpy(UNIXCREDS(skb), &scm->creds, sizeof(struct ucred)); - if (scm->fp) - unix_attach_fds(scm, skb); + memcpy(UNIXCREDS(skb), &siocb->scm->creds, sizeof(struct ucred)); + if (siocb->scm->fp) + unix_attach_fds(siocb->scm, skb); skb->h.raw = skb->data; err = memcpy_fromiovec(skb_put(skb,len), msg->msg_iov, len); @@ -1300,6 +1307,7 @@ unix_state_runlock(other); other->data_ready(other, len); sock_put(other); + scm_destroy(siocb->scm); return len; out_unlock: @@ -1309,20 +1317,28 @@ out: if (other) sock_put(other); + scm_destroy(siocb->scm); return err; } -static int unix_stream_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, - struct scm_cookie *scm) +static int unix_stream_sendmsg(struct kiocb *kiocb, struct socket *sock, + struct msghdr *msg, int len) { + struct sock_iocb *siocb = kiocb_to_siocb(kiocb); struct sock *sk = sock->sk; unix_socket *other = NULL; struct sockaddr_un *sunaddr=msg->msg_name; int err,size; struct sk_buff *skb; int sent=0; + struct scm_cookie scm; + + if (NULL == siocb->scm) + siocb->scm = &scm; + err = scm_send(sock, msg, siocb->scm); + if (err < 0) + return err; err = -EOPNOTSUPP; if (msg->msg_flags&MSG_OOB) @@ -1376,9 +1392,9 @@ */ size = min_t(int, size, skb_tailroom(skb)); - memcpy(UNIXCREDS(skb), &scm->creds, sizeof(struct ucred)); - if (scm->fp) - unix_attach_fds(scm, skb); + memcpy(UNIXCREDS(skb), &siocb->scm->creds, sizeof(struct ucred)); + if (siocb->scm->fp) + unix_attach_fds(siocb->scm, skb); if ((err = memcpy_fromiovec(skb_put(skb,size), msg->msg_iov, size)) != 0) { kfree_skb(skb); @@ -1396,6 +1412,10 @@ sent+=size; } sock_put(other); + + scm_destroy(siocb->scm); + siocb->scm = NULL; + return sent; pipe_err_free: @@ -1408,6 +1428,8 @@ out_err: if (other) sock_put(other); + scm_destroy(siocb->scm); + siocb->scm = NULL; return sent ? : err; } @@ -1424,8 +1446,9 @@ static int unix_dgram_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int size, - int flags, struct scm_cookie *scm) + int flags) { + struct scm_cookie scm; struct sock *sk = sock->sk; struct unix_sock *u = unix_sk(sk); int noblock = flags & MSG_DONTWAIT; @@ -1456,12 +1479,13 @@ if (err) goto out_free; - scm->creds = *UNIXCREDS(skb); + memset(&scm, 0, sizeof(scm)); + scm.creds = *UNIXCREDS(skb); if (!(flags & MSG_PEEK)) { if (UNIXCB(skb).fp) - unix_detach_fds(scm, skb); + unix_detach_fds(&scm, skb); } else { @@ -1478,10 +1502,12 @@ */ if (UNIXCB(skb).fp) - scm->fp = scm_fp_dup(UNIXCB(skb).fp); + scm.fp = scm_fp_dup(UNIXCB(skb).fp); } err = size; + scm_recv(sock, msg, &scm, flags); + out_free: skb_free_datagram(sk,skb); out: @@ -1527,8 +1553,9 @@ static int unix_stream_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int size, - int flags, struct scm_cookie *scm) + int flags) { + struct scm_cookie scm; struct sock *sk = sock->sk; struct unix_sock *u = unix_sk(sk); struct sockaddr_un *sunaddr=msg->msg_name; @@ -1555,6 +1582,8 @@ * while sleeps in memcpy_tomsg */ + memset(&scm, 0, sizeof(scm)); + down(&u->readsem); do @@ -1593,13 +1622,13 @@ if (check_creds) { /* Never glue messages from different writers */ - if (memcmp(UNIXCREDS(skb), &scm->creds, sizeof(scm->creds)) != 0) { + if (memcmp(UNIXCREDS(skb), &scm.creds, sizeof(scm.creds)) != 0) { skb_queue_head(&sk->receive_queue, skb); break; } } else { /* Copy credentials */ - scm->creds = *UNIXCREDS(skb); + scm.creds = *UNIXCREDS(skb); check_creds = 1; } @@ -1626,7 +1655,7 @@ skb_pull(skb, chunk); if (UNIXCB(skb).fp) - unix_detach_fds(scm, skb); + unix_detach_fds(&scm, skb); /* put the skb back if we didn't use it up.. */ if (skb->len) @@ -1637,7 +1666,7 @@ kfree_skb(skb); - if (scm->fp) + if (scm.fp) break; } else @@ -1645,7 +1674,7 @@ /* It is questionable, see note in unix_dgram_recvmsg. */ if (UNIXCB(skb).fp) - scm->fp = scm_fp_dup(UNIXCB(skb).fp); + scm.fp = scm_fp_dup(UNIXCB(skb).fp); /* put message back and return */ skb_queue_head(&sk->receive_queue, skb); @@ -1654,6 +1683,7 @@ } while (size); up(&u->readsem); + scm_recv(sock, msg, &scm, flags); out: return copied ? : err; } diff -Nru a/net/wanrouter/af_wanpipe.c b/net/wanrouter/af_wanpipe.c --- a/net/wanrouter/af_wanpipe.c Mon Jan 20 16:00:08 2003 +++ b/net/wanrouter/af_wanpipe.c Mon Jan 20 16:00:08 2003 @@ -542,7 +542,7 @@ *===========================================================*/ static int wanpipe_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, struct scm_cookie *scm) + struct msghdr *msg, int len) { wanpipe_opt *wp; struct sock *sk = sock->sk; @@ -1649,8 +1649,7 @@ *===========================================================*/ static int wanpipe_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, int flags, - struct scm_cookie *scm) + struct msghdr *msg, int len, int flags) { struct sock *sk = sock->sk; struct sk_buff *skb; diff -Nru a/net/x25/af_x25.c b/net/x25/af_x25.c --- a/net/x25/af_x25.c Mon Jan 20 16:00:08 2003 +++ b/net/x25/af_x25.c Mon Jan 20 16:00:08 2003 @@ -917,7 +917,7 @@ } static int x25_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, struct scm_cookie *scm) + struct msghdr *msg, int len) { struct sock *sk = sock->sk; struct x25_opt *x25 = x25_sk(sk); @@ -1093,7 +1093,7 @@ static int x25_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int size, - int flags, struct scm_cookie *scm) + int flags) { struct sock *sk = sock->sk; struct x25_opt *x25 = x25_sk(sk); Mail text in /tmp/linus.txt; please check and send using your favourite mailer. From mauro@deepspace6.net Mon Jan 20 18:53:11 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Jan 2003 18:53:17 -0800 (PST) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0L2rA3v010102 for ; Mon, 20 Jan 2003 18:53:11 -0800 Received: from trantor.ferrara.linux.it (151.26.186.32) by smtp2.libero.it (6.7.015) id 3E0C6F6000863B35; Sat, 18 Jan 2003 19:20:30 +0100 Received: by trantor.ferrara.linux.it (Postfix, from userid 501) id 055ED2CCCF; Sat, 18 Jan 2003 13:20:22 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id DDC882A8A8; Sat, 18 Jan 2003 19:20:22 +0100 (CET) Date: Sat, 18 Jan 2003 19:20:22 +0100 (CET) From: Mauro Tortonesi X-X-Sender: mauro@trantor.ferrara.linux.it To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Cc: USAGI Users Mailing List , Deep Space 6 Development Mailing List , Linux Kernel Networking Stack Development Mailing List Subject: Re: (usagi-users 02099) IPv6 packet forging In-Reply-To: <20030119.010908.127619438.yoshfuji@linux-ipv6.org> Message-ID: References: <20030119.010908.127619438.yoshfuji@linux-ipv6.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id h0L2rA3v010102 X-archive-position: 1596 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mauro@deepspace6.net Precedence: bulk X-list: netdev On Sun, 19 Jan 2003, YOSHIFUJI Hideaki / [iso-2022-jp] µÈÆ£±ÑÌÀ wrote: > In article (at Sat, 18 Jan 2003 15:54:12 +0100 (CET)), Mauro Tortonesi says: > > > packets on the net i have used link layer sockets, but i'd like to know if > > there are more portable ways to perform the same task. do you know if > > How about libpcap? isn't libpcap only for capturing packets? -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@deepspace6.net mauro@ferrara.linux.it Deep Space 6 - IPv6 on Linux http://www.deepspace6.net Ferrara Linux Users Group http://www.ferrara.linux.it From davem@redhat.com Mon Jan 20 21:18:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Jan 2003 21:18:29 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0L5IL3v011515 for ; Mon, 20 Jan 2003 21:18: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 VAA18211; Mon, 20 Jan 2003 21:14:16 -0800 Date: Mon, 20 Jan 2003 21:14:16 -0800 (PST) Message-Id: <20030120.211416.98847188.davem@redhat.com> To: bcrl@redhat.com Cc: netdev@oss.sgi.com Subject: Re: [patch/bk] remove scm_cookie parameter to send/recvmsg From: "David S. Miller" In-Reply-To: <20030120161755.B23890@redhat.com> References: <20030120161755.B23890@redhat.com> X-FalunGong: Information control. 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 X-archive-position: 1597 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: Benjamin LaHaise Date: Mon, 20 Jan 2003 16:17:55 -0500 + memset(&scm, 0, sizeof(scm)); init_sync_kiocb(&iocb, NULL); si = kiocb_to_siocb(&iocb); si->sock = sock; - si->scm = &si->async_scm; + si->scm = &scm; si->msg = &kern_msg; si->size = total_len; si->flags = user_flags; memset(si->scm, 0, sizeof(*si->scm)); We're now memset()'ing it twice? :) I think the first memset isn't needed, and this makes the code consistent with the other places this logic is duplicated. Otherwise the patch is fine, please fix this stuff up and resubmit, thanks. From alan@lxorguk.ukuu.org.uk Mon Jan 20 23:09:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Jan 2003 23:09:20 -0800 (PST) Received: from lxorguk.ukuu.org.uk (dhcp34.trinity.linux.conf.au [130.95.169.34]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0L79B3v012970 for ; Mon, 20 Jan 2003 23:09:12 -0800 Received: from dhcp22.swansea.linux.org.uk (dhcp22.swansea.linux.org.uk [127.0.0.1]) by lxorguk.ukuu.org.uk (8.12.6/8.12.5) with ESMTP id h0L2HVFx013187; Tue, 21 Jan 2003 02:18:11 GMT Received: (from alan@localhost) by dhcp22.swansea.linux.org.uk (8.12.6/8.12.6/Submit) id h0L2HTgG013185; Tue, 21 Jan 2003 02:17:29 GMT X-Authentication-Warning: dhcp22.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: cs89x0 in 2.5 (was Re: eepro100 - 802.1q - mtu size) From: Alan To: Jeff Garzik Cc: Dave Jones , Linux Kernel Mailing List , netdev@oss.sgi.com, alan@redhat.com, akpm@digeo.com In-Reply-To: <20030117174928.GA8304@gtf.org> References: <20030117145357.GA1139@paradigm.rfc822.org> <20030117160840.GR12676@stingr.net> <20030117162818.GA1074@gtf.org> <20030117172719.GA31343@codemonkey.org.uk> <20030117174928.GA8304@gtf.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1043115448.13142.6.camel@dhcp22.swansea.linux.org.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 (1.2.1-2) Date: 21 Jan 2003 02:17:28 +0000 X-archive-position: 1598 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev On Fri, 2003-01-17 at 17:49, Jeff Garzik wrote: > > Whilst on the subject of magic numbers in net drivers, did we ever get > > to the bottom of 2.4's ChangeSet 1.587.9.20 > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/davej/patches/2.5/2.5.48/split-dj1/net-cs89x0-media-corrections.diff > > > IIRC it came from -ac tree without explanation, and I think akpm said it > broke stuff. Since it has an alive maintainer (akpm), I would rather > let Alan and Andrew fight it out :) Whatever they decide is fine with > me for 2.5. I've had no reports I remember about it breaking stuff, and several that it fixed stuff. It also seems to match the documentation. Its been in -ac for ages From Hakon.Bugge@scali.com Tue Jan 21 07:39:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Jan 2003 07:39:58 -0800 (PST) Received: from elin.scali.no (IDENT:root@elin.scali.no [62.70.89.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0LFdl3v028500 for ; Tue, 21 Jan 2003 07:39:48 -0800 Received: from pc-15.scali.com (pc-15.office.scali.no [172.16.0.115]) by elin.scali.no (8.12.3/8.12.3) with ESMTP id h0LFkB9N015677; Tue, 21 Jan 2003 16:46:12 +0100 Message-Id: <5.2.0.9.0.20030121173952.02919b30@mail.scali.no> X-Sender: hob@mail.scali.no X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 21 Jan 2003 17:45:10 +0100 To: linux-net@vger.kernel.org, netdev@oss.sgi.com From: =?iso-8859-1?Q?H=E5kon?= Bugge Subject: non-growing tcp window size Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_26722436==_" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-archive-position: 1599 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Hakon.Bugge@scali.com Precedence: bulk X-list: netdev --=====================_26722436==_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To whom it might concern,

We have observed bandwidth problems of TCP when running benchmarks which gradually increase its payload and having (most of its) data flowing unidirectional. The degradation is observed between two dual XEON/E7500 machines, using Gbe and a cross-over cable. The Gbe is eth1 and has an MTU of 9000. eth0 is a FE with an MTU of 1500. The machines is running linux 2.4.20, and the NIC in question is an Intel Corp. 82544GC Gigabit Ethernet Controller (rev 02).

During an attempt to change TCP parameter settings, and also systematically changing socket rx/tx buffer sizes, I discovered that once in a while, the benchmark ran well. The OK run was not deterministic, and had nothing to do with change of the parameter settings. Hence, I let the machine work during the week-end, and took tcpdumps which I saved for the successful run. An analysis of the "OK" run vs. the "BAD" run, discovers a couple of interesting things. The problem is that the advertised window of the receiver does not increase. The second problem, which also affects the "OK" run, is that the ratio of packets sent (from src to dst) and the number of packets received (#advertisements) is 1 for the "BAD" scenario (actually this is probably a consequence of the window being only ~2xMTU size). Surprisingly, it is as large as 0.5 for the "OK" scenario. IMHO, this violates RFC813, which states:

   There are two reasons  for  prompt  acknowledgement.    One  is  to=20
prevent  retransmission.  We will discuss later how to determine whether=20
unnecessary  retransmission  is  occurring.    The  other   reason   one=20
acknowledges  promptly  is  to permit further data to be sent.  However,=20
the previous section makes quite clear that it is not  always  desirable=20
to send a little bit of data, even though the receiver may have room for=20
it.    Therefore,  one  can  state  a  general  rule  that  under normal=20
operation, the receiver of data need not,  and  for  efficiency  reasons=20
should  not,  acknowledge  the data unless either the acknowledgement is=20
intended to produce an increased useable window, is necessary  in  order=20
to  prevent  retransmission  or  is  being  sent  as  part  of a reverse=20
direction segment being sent for some other reason.  We will consider an=20
algorithm to achieve these goals.=20
The two tcpdumps has been analyzed by a simple awk scripts, which gives information for every 1/10 of a second of the runtime:

time: elapsed time relative to the first packet
MB/s: sum of TCP payload (based on TCP sequence numbers) *1e-6 / delta time
avg_len: average packet length (TCP payload) sent
nsent: no of packets sent from src to dst
avg_win: average window size advertised by the src
adv/sent: ratio between #advertisements (sum of prompt acks and piggybacked acks) and #packets sent

The extract of the analysis is enclosed as "ok.txt" and "bad.txt". Also, the information is presented as graphs in "bw_winsiz.png" and "bw_adv-sent.png". In the graphs, the "OK" data uses the bottom x-axis, the "BAD" data uses the upper x-axis (the "BAD" run-time is longer due to the lower bandwidth). Bandwidth uses the left y-axes, whereas the average advertised window size and the ratio of the #advertisements and #packets sent uses the rightmost x-axis.

I do hope this information is useful 4u and that the problem can be fixed. Since I do not read the mailing lists, I would appreciate a note back by email of someone triggers on this.

Cheers, H=E5kon

--
H=E5kon Bugge; VP Product Development; Scali AS;
mailto:hob@scali.no; http://www.scali.com; fax: +47 22 62 89 51;
Voice: +47 22 62 89 50; Cellular (Europe+US): +47 924 84 514;
Visiting Addr: Olaf Helsets vei 6, Bogerud, N-0621 Oslo, Norway;
Mail Addr:  Scali AS, Postboks 150, Oppsal, N-0619  Oslo, Norway;
--=====================_26722436==_ Content-Type: image/png; name="bw_adv-sent.png"; x-mac-type="504E4766"; x-mac-creator="6D646F73" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bw_adv-sent.png" iVBORw0KGgoAAAANSUhEUgAAA6AAAAK4CAMAAABd6WDBAAAAA3NCSVQICAjb 4U/gAAABKVBMVEX///8AAAAAAAD/AAAAwAAAgP/AAP/A/0DAQABA/4AgIMCA AMAAYIAAgAAAgEAAgIAAwGAAwMAA/wAggCAwYIBAQEBAgAAAAICAYACAYBCA YGCAYIAAAMAAAP8AYABAwIBgoMBgwABgwKCAAACAAIBgIIBgYGAA//8gICAg QEAgQIBggCBggGBggICAgECAgICgoKCg0ODAICDAYACAwODAYMDAgADAgGD/ QAD/QECAwP//gGD/gIDAoADAwMDA/8D/AAD/AP//gKD/gP/AwKD/YGD/gAD/ oACA4OCg4OCg/yDAAADAAMCgICCgIP+AIACAICCAQACAQCCAQICAYMCAYP+A gACggP/AYIDAwAD/gED/oED/oGD/oHD/wCD/wMD//wD//4D//8BTi7KnAAAA O3RFWHRTb2Z0d2FyZQBnbnVwbG90IHZlcnNpb24gMy43IHBhdGNobGV2ZWwg MiBvbiBMaW51eCAyLjQuMy0xMrFi8REAACAASURBVHic7Z2LoqIgEEB1yf7/ k/f2UHkMCAo62Dm7t1JxnIoTiGbDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AHAHxhcdxf0EbxK0oxfCClg1/glxhclKgVvWuMsYrdse4n7CNhFpuakftnZc 6wWoGv+EuMJkpcCN3sBrGb177XG/QRuEbfVZ0iK81VJUjX9C3E/MWq/GGHyi 3I3vs2rWNWjU1LVq6OrT6JPKF6nWGxiEaRC36vsXfKLcjLkj05GgY5OwfQta 7Q08QdC6799PCNqkSVrDNwjZj6CNdsbdelnvDfTDVOuLuo8QNJdxqP2RtkRu M6bWbFBr7Go426mXFd/A5qO4td+/NXCzN/BSxuofaWvgJoxjm3didO6qB27Z gtZ8A1uNufgeVXv/gp3xSnG1MLauQG1o18XtZDjbqpdV38BWPcYxOVkjcNPj BtcxNvrgQdC2ca0WqWp8BFVG63rZCARtFB9BtdFo0KU7QduNPjWJ6+8rttql q0V7QZu9gVfTZuyr1VjOHL5FzH5GcZ2QFeNboaq+gUGgap8njV4IAAAAAAAA AAAAAAAAAADIJXbGBgdxATZICVLtVBB58q6nQQFUI9WCVWrdYhdnuuuJxADV SHUxK17mzH3sCkonFyBOVI+x4tnD7kNH0HaXBgO4ATE9xsSy/duwL4QxP0ZQ gCgRPcbEsv3bcIaFxiHyMTAC/BCZ8ghz6wtq5zTGPgZaNanFcXNXaJ2wmitL bK141jvXYnCkaoCSwPsEzbN7XwpLCxr5GEBQLy6CNtpOv4KWb6ZgG97wLYJu xUXQRttBUDHO1nFQBPXiImij7XQnqGzSYSJhYzu6COrFRdBG2+lNUH+fs9Ie qL8vO0aX1NxshbgIWrgigu4InCzrKdKoBS0EQb24CNpoO/oFVQmCenERtNF2 EHQXCOrFRdBG20HQXfSXMcBu+qvu/WUMsJv+qnt/GQPspr/qnszYvPg+HNx7 q1DZBjOLm/gDgL3cS1AT3EqW1BDUBHMRFBpwK0GdRtPRVCyWydmC4jWs3FxQ Wa6yDZ7cxTUYCiv3FlSu6sbeVfX2W4Uljulii7wW+zw2S+ttR8sjnjb8IjcW NNoUrf74q7pL7Hm+oJZ3xpthPYi34jHiHXP4SW4saLSai61hqGF8QnwgLImN U5lDRJ4V3JI7CxptQb17Z52cCfFBgaAJaEHB4daCRvdBnXurYaosqD8jB/ZB webegqZHccMdzrSgjjutBGUUF2xuLqg86hoWqy2o3OrmgZ+wcitBHSnjO4DS WK2klHFLG6dxi4/iLsV2Cgqwci9Bc8/FDY92igdT7AOcXvsZOVzqrh7NACCT mwkKcC/6q+79ZQywm/6qe38ZA+ymv+reX8YAu+mvuveXMcBu+qvu/WUMsJv+ qnt/GQPspr/q3l/GALvpr7rnZ/x48X04uPdba5aldEok+EluLOgjuM3WBUFB CfcV1Gk0HU3z1y1ZUqc8gMMvCZovS7RksW8ICof4IUFjrli7qvOE47O1nlvs EQZ4DMGCB47Cfn5F0MdGW+bspD4igj7k0sGa0ioAe/gVQTdNCZ0MBA0fFKzj rHKIjScCt+JnBN0ydFtQqau7tQ4tKBzjdwRN74MKvVpPtkewjrN6pFuMoHCI HxI0IsvDL7bcbx1CFY7dICjU5ZcEFW3ZajRTpziE2ouCIins5r6C5p5JJI3I rp7FxRSDSiO/+An7ubGguefiOoOj1nHQWPlllbzt4Ccc4M6CAnRPf9W9v4wB dtNfde8vY4Dd9Ffd+8sYYDf9Vff+MgbYTX/Vvb+MAXbTX3XvL2OA3fRX3fvL GGA3/VV3N+PpgzUjuiQskkdm8Sn+AGAvvQv61cCSYoos8dbIRywemo+g0ICb CLrIEAgqaKJcULyGlZsJOg2BIG0ETRRDUKjHbwrq7J1aE+ISp6cs7tOuxZw9 3+kzmfm8vCcE8OImglp++jIJggoLJmGJPc8X1PJu8mb4+8OlwiEorNxAUKuV yhTUu18nprwJ8YGwZPJmOCnvJng+cGNuIOhy47uiVtA0GAgrNxH0a5HbyGQK aq1TWVB/Rh4ICiv3EtSZlSmoXTgtqDACFW4UQaEmPy9owUSBoHKrmweCwspN BI3vgwrVXRqrlZSa3NLTEJ4FERSbiwrpAJTTu6DCTqe7QypEkI52igdT7AOc XvsZOVzqru5OtsIcKm+i8/bGh5r0LiiYQoPc8p8pad7e+OBz6PXrr7r3l3FT zJCoAcICt/xqpz8vK37nJJ6XuKi0/LzIhCWMdCfRX3XvL+OWSD1Ua2GwwC1v NuZtxO+cRN/AW2Skmdmh3n9it8S9E+mvuveXcUOM9RddGC3/fvTBnReZ6h/j Pfan5UUm8ToYobwf6vUqO3MXae07mf6qe38Zt8R8/4mL1ttIebvmmVgJ04Gf UoJi/954i420zP1wcl4fP6gZzGao+RPQ75a4d8IzeNFfde8v46aY5S0OF9gf 0YP4YR/ZB7UiGhOJrwnpI0ropdrPMzY9PzTzR9Wik/GaQaeo/Uq7Zn8WG6uE 1XExfgcmoL/q3l/GLTFDVKBvxXD2dMzaPs5ufu9jSporR3GzG8awVyn0Ut2m anl5rKJmLTw/8cUvt59hb2l20G9P5zDLzTpvmTl/FNCC3hD3M1labgbno9vt sRm3ZtoV1+uuXWWoNP4p9DW9GVKvc34N3DbTOA2l9zqZRavl4y3dfq7aGWum lc9SwttU8iXur7onMn5+sGZEl6TJLnhipAB3VzFWwv649veN/NKWp07gEwU1 3mPv48Jp+4NZ66Qn49zSuR9mlkeD0wguH1/GCeR+pg1zdlZjabXKa7M6v4bf ab9TMycS4VaCfn1YtbT8cJds0IOgTlWRW9F5fCfc0xHHlpy+rVO1qybubcGb Z7zlxn+eSynvyXsu2mbbbVnwCfB10G3brA1YgWxL13zNUsppT4XUrcDu52Di Bb6joIsVgaC5vsSLlQrXTFC/GZHHSYalmq1VbPCroBvSXjejAu0mlrDddvvj n848+8mHLprB+bSZ20lnm7ZVVhPnpuBsafBfNzuiK7SXo1tCeN4R7izoc3Ba 02E4Lmixb60E9RUTD4bYn/sJ/ZZ5Tuuw3YM+RPj54Gdlvkp5fVUz+DMdTcz6 3x3qSn4iea/RmoLwmnqGSvGMM7XxrOVZMwg6OHunnwmnPxzfpw0DPIdgQf6e bxFLRfxOxSv82gsz7iK5tlrKBx3eesTaF18Pf4xz3T102zE7itvrnAsETaHk kZ+W+JknrGFtOzYVn6ddUCuF8YU4IRYPsc3yu7v2lLziUioi6FMuHawprVId qS8mdajWB4m6tC526nQzQaMJe94Z93nO8z7NqD1z8Essm1kDS9sbNj+4wszd HIWI8lR83gFBY4sj8uzBijPa23QmMlJ647Rf1u12Fzd0MhA0fFCwTpDlbuYo 3u6PCd7ntFXSp7vUVC1TVTFip1waxRF2HP2EvOxM8DDyQZP3wZXOscrrslvQ mIQxeXZgN5n2/ejNHPxSIpYlnivHBZW6ulvrtDzM4lflYKy+uO7Ej100MFQe 1jKBnzGrcgXNbu9SMzdzPMZeQWOtZFSeXcgKzu3oDkG/rrgtzsY+qNCrFQ23 13FWj3SLzxJUMqi87gQtw+Kn0Nwdw5jgA8XLIC2oq11MUP9MxQxBt4lubDf1 u7hZK2eSEnTc04Im/BJ8sZdL/WHJz2jI6wSN7lQeie7uw1Uz1Mgt/nvRVgsq tYbdC5qIolBQq/887uriFgm61WjG/fTWCaN5IaqzIeTRqrM1BnUksJnDBsuk 7qPcpbSb0ngX1z+xQC5XRDeC1holsh6uY0+j9ecWX/j3h7dwYx9U7OHad85Y 7PuoiZTxU7pzotjDuC39/Gdj/qUmyzHOI3M8oB3sn5ygMV5Jv6AJH5lkEeMX FcqVUSVIIuSLtZanK8EJo7jWNkZ37ujPS6Y0eMcd3aYxcUTSXWs9DmoHEVdx puzyjpTNOrnyMGxq+bFtVWs/58b5YAsaNPDR0smF5XTQglY9ehqM4n4nIkPF Co7cbtFyx3PlTEEHI+8y7gm0/J0gaPBB8BuC1nUkIugozKy/8SZcJWiLqmNF KwoYLbwOOFUS1N+fTY6dIWg5sRY0si0E/XKuoN+IuUETx02XQzZHBbU7sFFB E92K2wkqm3SYSNhdZxLp4DJBE/W0ziZzz1dI7rM6Xz0Jt+AECcoVCxomllUw M4YmQddhoZqO2AO37sDVnnNxdXBfQTPjBmMz7lKpZZznFAuaHAeKZJZRMDPG tYJ6irinsVccxy0CQb/Igoq1utoW8wy1BoJii90H9iKTLhcZAvpNQVXSQcbX CTq4ZxfU32CuoYlzAwUD7Tl9CVrpVUbQU2n0FVCP2BhLfAevwhYzx4lM4rAM gqZDunRQ3T06yPgyQS2DWuyCvoNnBU6NJh0S1ESKnylogz19BD2VqwQ13l+L bebFTZ3XUC5ofJXlKzEIqoYOMr6yBZ0daiNobgOayCBZu4sFpQVVRwcZX7gP Os+vdGJe5mbFMtuChkUKBV13dRFUDR1kfIqg8nv6vdBW9QsgbG1XKhLLMBHL FlTUwB8jEna5EfRaOsj4QkHn6trOUD2CRna5EfRaOsj4SkE/i+pfoiRrw9+N pwr6TWC4VFg93oLOtwiqhg4yvlhQoVU5Z8OfpemLddYU1CqOoGroIOPrW9CN Aq02/OmjnifowCiuPjrI+GpBW7af6cifDaf6uHUFFQpvNfCJreeCoCk6yPhy QRuOEQ1bukQck+fEAnjLtvVDUDV0kPH1grb0c40tXenTuAWi68oFflXQeJwO qrtHBxkrEPSMTUsdaW/4eOtq99UETX0oxDaIoE3oIOPfEFQcivLOkg9/JDg5 uSlo/EkjqBY6yPgnBPX3N+dFjgLGW77RoK6RI+shqH46yPjugs6/8h6esBRM lfV4TxV0/wuIoCk6yPj+gr7F89tPyVZvzOhyQbNHk/JiIGhIBxm3+7kHiyu7 uGbuvdqjtuF3QL0WdJbaKxJMIqhFB9Xdo4OMzxD02l1Qs/zQtW2poJ97FTN/ lxRBN+N0UN09Osj43oL6PdfZUrEL6573Jw0qhZMIatFBdffoION7C+oJ9HXT alPDsvPDrRbUBLdeMQTVTwcZ31zQsP1cfi47yMofRErvgyJoQAfV3aODjO8u qCOaseaESbmahRdiQdCNOB1Ud48OMr69oF7DaO+HJgpuCjxPxXdVEVQ/HWR8 f0EdZjOllBC0OKRLB9Xdo4OMf0zQVC5bgoo9WQRd6aC6e3SQ8a8JmqCSoIk2 2o+DoBfTQcYIunC6oFuvC4K2poOMEXQBQYtDunRQ3T06yBhBFxC0OKRLB9Xd o4OMEXRFEnBrOYKudFDdPTrIGEFXNgU14XIEXemgunt0kDGCrgj+ucuNUN1j pwQqEbROkEhEjw6qu0cHGZ8gaC9+bgnqnp+LoAEdVHcP/Rk/v38tuYmgZv7v FtghqN09zstHlaDRQPqru4/+jBHUIimosf6GAUEF9Fd3H/0ZI6jFvVvQem8D gp4HglqctQ+KoFrQnzGCWlQaxZUOvYgbQtCr0Z8xglpsCSoWQNAF/dXdR3/G CGqhVtAjryCCJtCfMYJa7BJUHk5C0C7QnzGCWuxrQeWLF9UQNDikswcETaA/ YwS12CNo7PJ/CNoD+jNGUItNQe25y8EUExRG0F7QnzGCWpQIuh7sDHVE0F7Q nzGCWpQLannqlcoQdPt1QdDG6M/4BEG78XOPoKKMCNoL+jNGUIs9gh44Doqg l6M/YwS12CXo/uOgCHo5+jNGUIt9gsqlELQH9GeMoBa1BJW6vUIYBL0c/Rk/ l5tmIGgkDIJejv6MEdQCQQtDeuiv7j76M0ZQCwQtDOmhv7r76M8YQS1OE/Sz GEEvR3/GCGpjxIdigV8WNBZKf3X30Z8xgtogaGFMF/3V3Ud/xghqs+kfgqZC 6a/uPvozRlAbBC2M6aK/uvvozxhBbRC0MKaL/uruoz/j9oJ25GeGf3nVHUE7 QX/GCGqDoIUxXfRXdx/9GSOoTS1BN580gupAf8YIanOqoBkvTA1B6wSRQ3ro r+4++jNGUBsELQvpob+6++jPGEFtqu2DhtfKDcPkC3rsJUTQOPozRlCbSoJK 18oNw+S8MGZzW7kxEFRCf8YIalNHUDP/T28IQa9Hf8YIalNFUDNsC4igOtCf 8dO6bcM9Bd2yjxa0C/RnjKA2dQTN0A9BG2GlML4QJ8TiSkFQm0qCbo4R/aag J9hgSTja23Qmzk3pIAhqU0vQWsdBbyWo1IJVxm4y7fvRmzn4pfSCoDbVBM3Z 0MmC1nwf9ggqdjGr4ws6jsGEWFwtzQXtyU8ELQvpc30X1xd0tFvQkRZUAEFj YRC0Aa6go93FHeniSiBoLA6CNsARdP5zJ5ziC/+U8rRuxeUAKf7qyFrLM+Vp iC1o2HjesAU92rZunjauiu0WtFZ71HcLGgmmS1Dr0IozcXZKx2gs6PZp46pA 0LKYHqoEtY+AOhNnp3SMtoKa7JqoAwQti+mhSlD7/sbHQQ8Jaqy/PjDBg0iJ 44JmRUDQQn7uTKLfakERtCymx+WCxk+/7fxc3KiHh8eI+toHzTiKgqDxYFtn Ep1yLlER6hIKaCxoZ6O4CFoW00N/dffRn3FrQbtqPxG0MKaH/uruoz9jBHVA 0KKYHvqru4/+jJt3cY8GOBcELYrpob+6++jPGEEdELQopof+6u6jP2MEdUDQ opge+qu7j/6MEdQBQYtieuiv7j76M0ZQB22CDhVOxELQOPozRlAHBC2K6aG/ uvvozxhBHXIFPfy0EFQF+jN+evfy0v3cTtDPIgSV0F/dffRnjKAOdxS0VqMf hvTRX9199GeMoA4IWhLSR39199GfMYI6IGhJSB/91d1Hf8YI6nCaoEPmt3wQ tCn6M24saGd+nilofjEEbYb+jBHUAUFLQvror+4++jNGUAcELYrpob+6++jP GEEdELQopof+6u6jP2MEdUDQopge+qu7j/6MEdQBQYtieuiv7j76M34GD6SF u0HQWJS+D7Mg6FkgqMNZgmZfjhRBm6I/YwR1Mc5dtMTB52Xm/1n5IGgz9GeM oC6nCGqGbPMQtCn6M0ZQl+3KXKkFzQyCoE3Rn3FbQbvz8yRB871D0KbozxhB XU4SNHeMCEHboj9jBHXJqMw1nDn/OGjltwJBTwJBXU4TNBMEbYr+jBHUBUEL Yvror+4++jNGUBcELYjpo7+6++jP+Ck8is8pBUGPknk+w1YMBJXRnzGCumgT NHu4NxliQFAZ/RkjqEueoCc+LwRtif6MEdQFQQti+uiv7j76M0ZQFwQtiOmj v7r7qM/YcvAZcjR6f34iaElMH/XVPUB9xscbyRQIehwEbYn6jBHUA0ELYvqo r+4B6jNGUA8ELQnqob66B6jPGEE9ELQkqIf66h6gPmME9UDQkqAe6qt7gPqM EdTjjoI2OfcJQU8BQT0QtCCmj/rqHqA+YwT1yBC0ijPZIGhL1GeMoB4IWhDT R311D1CfMYJ6IGhBTB/11T1AfcYI6oGgmSGln65QX90D1GfcVNAO/cw6JoGg g/zTFeqre4D6jBHUJ6MyI6iRx7LVV/cA9RkjqA+C5sfzY6qv7gHqM0ZQHwTN C0gLegoI6oOgeRHZBz0FBPVB0LyQjOKeAoL6IGh+TB/11T1AfcYI6oOg+TF9 1Ff3APUZI6gPgubH9FFf3QPUZ4ygPjmCnvrEKmwMQWOozxhBfRA0P6aP+uoe oD7jloJ26SeCFsT0UV/dA9RnjKA+CJof00d9dQ9Qn3FDQcUjZfrJqcwIiqAn 0U5Q+VwT/SBofkwf9dU9QH3GzQSNnK2pHwTNj+mjvroHqM+4laCx7zvoB0Hz Y/qor+4B6jOmBfW5qaDVU0bQU2i4D9qnn3mjuGeeSVRhYwgaQ33GLUdxu/Qz Q9BTh7+qbAxBY6jPuOlhlnaxG7Ip6Kmd9zobQ9AY6jNueZilT7YEPXX4q9LG EDSG+owR1CenBd0qUo86G0PQGOozRlCfnH3QE59dlY0haAz1Gbc8zNInOaO4 Zz67St8H/UFBxxfihFXmzIT2gKA+HAfNjhmQrO4RRZJLjjDaKTkTQSHFIGhA p8dvkzRo80sFjSmSWnKE0b4fvZlBKbW0PNWvUzo9fpvkekGjiiSWHEISNGyn EbQ/EDQzZMi2oEJX9jxBR1rQhY7rOIJmhgzZFFRQpJWgTs95thRBv/RcxRE0 M2TIlqCSIq32QZ2xp9H6C8u8+aeTZ5uwpk3YUzBdZy/T4DlZAddanrAlpohr UkW8FtQZLPIKKYYWNIAWNDNkSFpQWZGTRnEjG/lNQTs9Tf4LgmaGDEkKunUo sukg0ejODEqppYWgndfwztMXafGchIgpQWOKnHmYBUFfmM6bUATNjRlQchw0 eNByFJcziVa6vdbJDILmxgwoOJPIPk12c919cC6uxKlfl2wCgubGDCg5F3eM LjmT3xOUFlQjGgRVifqMm+yD9l3F+85eBkEjqM+4yShu12NECJodM0B9dQ9Q n3Gb46Atgp4GgubGDFBf3QPUZ4ygAQiaGzNAfXUPUJ8xggYgaG7MAPXVPUB9 xggagKC5MQPUV/cA9Rm3OdWvaxA0N2aA+uoeoD5jBA1A0NyYAeqre4D6jBE0 AEFzYwaor+4B6jNG0AAEzY0ZoL66B6jPGEEDEDQ3ZoD66h6gPmMEDUDQ3JgB 6qt7gPqMETQAQXNjBqiv7gHqM0bQkL5PJRZB0AjqM0bQkN7zF0DQCOozRtCQ 3vMXQNAI6jNG0JDe8xdo0WtH0DNA0JDe8xdA0AjqM0bQkN7zF0DQCOozRtCQ 3vOXQFAZ9Rm3uS5u33T/BAQQVEZ9xgga0v0TEEBQGfUZI2hI909AAEFlFGc8 vW8RNKDzixLKIKiM4owRVKb3y/rKIKiM4owRVKT7C+PLIKiM4owRVKL/n5aR QVAZpRlPMwjqY6zbG4GgMoozpgWVuWP7iaAxFGeMoBHuOEaEoBEUZzy9DUXQ kO6fgACCyujNeELQXwJBZfRmPA0I+ju0OPkCQZuCoD9Ek5MvELQp02eYqL6g +KmONidfIGhTEPRnaHTyBYIe5PlimfCXfgTd8PMhzvwQWwdB1dHm5AsEPchz sASsKWh80QsE1UeTky8Q9CCbgg6bZ/oh6E3gspsR1Ao6fW4Q9EfgOKiMckGn tKAPScOHcxeCoD8Cgh7jad0iKFQHQY/hCPoUBR0QFHaDoMdAUGgKgh5jS9D3 F7af33PmZRAU4iDoMWhBoSkIeoykoN9mMy3oYxA8fHj3AQj6IyDoMVxBvWFc BIWjIOgxLhIUP38FBD1GY0FjhiLor4Cgh3DPUIgImj7VD0EhAYIeAkGhLQh6 iOOCiifFP4RHDgj6KyDoIRxBn56Kk19KAkEhBYIeAkGhLQh6CASFtiDoIRAU 2oKgh0BQaAuCHsK5lsIBQT0RERRmwrcaQbN5Oo/2CCqe0/cQH9og6M+AoAdI CjohKBwHQQ+QFlQoFoCgkAZBD5AraPx6CvsExc/fAUEPgKDQGgQ9gCOofYXc aeazEEFhLwh6gKigL3JaUPF4ykMsYIOgvwOCHgBBoTUIup+n8xhBoQEIuh8E heYg6H5CQe1ZCAoVQND9ICg0B0H3c1hQUcXYERcLBP0dEHQ/CArNQdD9ICg0 R72g4x/2YyE99YIOEUO3BZUNRdDfoVDQiCLzoiophdmM1mMhPxWCPv1ZCAoV KBM0psjgmlSPUXgcbOQiQZ/C1DpvshfVFRQ/f4giQaOKtJJkFCbCdrpXQUUV o5cnWkHQH2KPoEJXtpEjgqDjfVpQBIVNdggqKHKeoOONurgICpuUCyop0kzQ 0RqVGq0/qdQf/87kKUyt8yZ70TLxsFdxJv49vrgb8SbfmK3M5FDQI8ubvdby hC8xRYbNVffhD9/KI1EqWlB/ntyCZhzkdNnVgsqNMfRIaQsaGax1TKqHMyo1 rqLKpU4GQaE9hYJuHYqs7IoraOxToCdB7b1RBIVNygSNNpSnCBrbRj+CPuzZ Wf7sETRySBV65Nhx0OBBmz6uzjOJigWdZkE/kwgK2xw6k8g+TXZz3X04Y0+q zsUVL0cdEXT2EkGhkGPn4o7RJWfSjaDu1TgRFLZR/22WDDoS9O/B++YFgsI2 CLqXMkFDEBQyQNC9FLagr4bzT5jX38EWNNtPDL0BCLoX+TfLlrmroNNzbjQX QV8L8+RB0B8HQfeSLei6D/ryBUGhBATdyxFBX9MPt5C1VvpsI2M2DEXQO4Gg eykXdJgFfSu6U1Dz/pcCQe8Egu7lkKDDtAg6/7kPZnzFzPw/DoLeCQTdS5Gg bx7W7U5BjfUXofgLM6AZBN2J7Ge2oO5pRd6JRsvJRntaUAS9FQi6kyOCOiLa gs4P1nXDfdCCHi6C9g+C7mRD0EmY57ag75vw/KLBFVQeJUqBoLcCQXdSR9BB 3gfdakJTIOitQNCdNBbUuUiKHcwMTtkQBL0VCLqTckFnWR5uAXHwdpK0ff9t CZpx2U7oCATdyVFBF3PKBDVesxuAoPcCQXdSTVAZBIU3CLqThoJ6Q7rO8VLj Df0GKyNoIxK7/S1B0J0cFHRLHOEb3sHBU7G6IGgjxF2R9iDoPiJ+1hN0ELu4 TnOKoJtUlAlBd9OHoKsqj2G3oMaa825H/doSxK1qaEndzCk7BQ92b64k7sZK 8cXuO9KCIHC4JQTN4SJB7QeTd0qDt5XYjOiWlrTDI0DxcnK1jc8NVxrsB+Ez DfMs3qS4ePvFtR/4+/1ZK21nFX9yiY8CBM2htaBLDLmKLTMzBE182jvVIb7J XNcStsRrYGJLxwQt0SbTKu+UzMNbij85BD3IGYJ6q80n+cmCTkHxeYb8eb08 uK+gO2TKek7LlxryYiLojwganCUf1EApbj1Bg60lKnNGGbgbHgAAEmtJREFU d1AYm7aLiHplCWqNdb9Xz9LGTyJvA3UFDePar8ECguYQE3ResCFo/tDNUtKI 58lP3oOUoMKDUnattBHvG1OMuzvPz/9BjloebvAVqxQ0I1TwliNoDsWC2uY8 dgga+ab2+j47pdfFXhVby9qLUi1outxWa+NHCFeS85y8JzclGuPUJoPsM9q1 +AaELW3HzMhqKz0HBM3hbEFj1zqZnHde6tA+XIeduuFUkOU+qIpWFXNCBYv9 FXOqbWRLnwdWXkWCpmIeFTR4/ju3tDwn51v70e0vIGgO2lrQ6fN+C4JOjlWT PScmaLB48MqdKGi8DczZZJCrIkEH64QwBK3N6YJGr7f52dLnd5lkQV/zrGo+ zZ6tH9y5gg5uOX+x198OFosrDXKoNftYHU4I6iSRq006EcGUo4Lafd70i+aA oBlE/WwnaOyK1cvH8eB2cWeXHtOyeHlkreSUngbhbgiKCbVma7G8RuBQWML6 ObhUhIg/8U3nktjAwXjRUSC5/AKCZnCNoHIJabRyWCr9+/KecwO7LHIu2jAM niKbnpULunsFt3GJBajmz7kbSD+3yGYRNINiQV0jC06QtY+DyqwtzPvXmdye 1fS9aMpk96icleYogy+oVHPOFXTabmUQtAMUCjr5s5oKuoj1+LSlnqDSjk5Q 6cP9LbnLOUQXDdUFzYhVpx+bsYHLBA3edgTNQJOggyeoP/jwsBOagpXWBd6u JoI6gVsJulUEQQt4LsSLvG/XV/7xeDz//loJ6nQCJ++i2F9em3/fzPfOkhl7 0lnFYXpEF63zY4v3rLAVq3iTpTTfQBIELSLupVfEEjRnpRT2uX4y9sbWOW4r GLagQZTJbUET467RD/7zW9DyTZbSfAMpELSM/gUVVppnVBB0owccK3+k9iOo fhDULxsKmlhJmjNFV02PayBoXRC0jCsFjf/iw7KxRzAnV1D/eAaCnreBFAha hk5Bg6L7cFvQ1EDthqAFdblU6FgEBNUMgnpF9+EIGj03AEHP5CFsGEHjlAv6 yFophT5Bt8ZcEbQaCFrGzwgauejugKAnI3w9CUHj5Lj2LtOjoA6pXmyqrqZ7 wJHtIGgUBC1Ct6C1/Eyfoo6gZ4KgRfyGoC9oQU/bQBIELeJCQc/t4SLoeRtI gqBFIGhqgHde7wJBG+qDoIdBUKdkFVKCbqxXVJURNA2CFvE7giZA0BNB0CJU C3rWT4FWF/RQ3UdQ/ZyWcZZqtxY05yJBCFoRBC0BQV+kqyqCVgVBSygX9JG7 VhwE3Y6AoKr5BUH1jBH9mqDt2+gUCFpCtqB2DxdBt4IhaBwELQFBt0HQujwQ NB/Vgurws1TQ4uMyUgAE1Q2CruUuZ+vHgILyCJoEQQtA0AwQtCoIWsAlgn7M Q9Dk9poLepWfCFpCnmrPBoJ2M0a0Q9CDdR9B1YOgc7GryfxRWmeVGoI21QdB j4Kggw4/31zRgiKoahB0QNB2IOhREHRA0HYg6FF0CTo9vd/ORdB0cQRNgaAF FLegvyhoIQiaBkELQND6IGgaBC0gV9CptqD39RNBN0DQAhC0AaUn7wbrDwiq HH2Czg8RdJvDVf/wyYLb8S8UtIfvgy4ZjS8Sy1uDoA1A0IzN2ySre0SRnFV3 s2xwjGwEQRG0IT0JGlPku7SJKeO8PddTp8RJIGgD1Avafi83SbATmqjuUUW+ c1uYMg6eoOHHgDZB11f0NEH79RNBN9ghqNxSjk1MGQdPUOFj4PaCmrsKuuPb L0IQBHUXyS2lZVJFRiuj+fHPCWpuK+iLCi1oY3s6E1RuKW2T6uHs845D5GNg XPjXlmdpscfzxcGtPv6Zv3/RpR8ObuNCpuMBDofY2kCFLHfz+G56reVpX+SW Mj16tBsnpzH2MaCsBV2LPQ63nn+Yx2sXNNqGdtx2fqAFTVPYgkZaygy797O0 oJGPAWWCTlUFNcNb0KihCIqg1qKN4yxVMoqFHUdnsvlmQ64Q9PYt6GEQdF0U U2R71SN0dhy0sqDDAz+TIGiwaPRnbK96hM7OJGogaHwUF0ERNFhmnxubveoB tJyLm2lbfUETR1kQFEGdha4i57SgW+gSdKo8ivvaCY2DoAiqHgT9ac4Q9Do/ B4OguSCoShBUO/cW1KQkxE8E1Y8qQScEPRkE1Q6C/jZHr2q0GR9Bj6FL0LXc 4/g3Wd6nKCBoGgRVjl5BqzSgCLpBa3sQ9CBqBP1++3j+Qmidc+URdAsEVY4a QYdPd6tmC5oWFD9fNLen+TBUCgTNZrsFRdArQFDlKBL081Z+Cx4X9HMWLoKm ubegwbYRNEbGPuhQVdDv11gQNA2CKkeVoFbBo4KabxOKoGkQVDkqBLWvIFlH UDP/R9A4VS7cubkRBD2ECkFfzC9lFUHN8oegae7egnrvMoLG2NJtqiiomfdA Uy0ofr5BUOXcUNCXnGZuQxE0DYIq536CftXcGsVF0DcIqhwlgq5v4qfg/nPl P34uF/ND0ItB0GPcTVBj/X0DySDoOSDoMVQIag/0H29BnWvJI+jFIOgxbiWo mW/Wa23GPMTPk7hWUP9kXASNcYag3+Fb51rVCHoxCHoMHYIGBfcIujSd9rWq EfRiEPQYlwvqn2+2W9Bl+NYlYiKCngSCHuNyQV/UaEH94dsZBL0WBD3GbQRd z493QdBraX1VsjQImktKt6nWPqj0U2ayifh5Fgh6DHWCfkruHsUNQNCLQdBD qBA0LLlPUOmnBhH0Yi4W1H2nETRGmaCPjTVkxJ8CRdCLQdBDnJRx9hgRgt4N BD2EAkG9d/AraCU/EfRqEPQQvykofp4Hgh4CQaEtCHoIBIW2IOghng6PD06J 1FT+ZhLLGgsqUhwc9oKgh3Dyfz7Cec0F9d/AvYLKfsLVcKLCIRAU2nHKpbFT IGgmCPqz0IIeQhLUmflITOVTJuiu8xQQVCcIeojbCIqfSkHQQ1wuaPD+Iei9 QNBDjLZw689bryAo9AuCZoKgcAU3E/Sx/DCKNa+toOEI/D5B8RMEbiqoZeEj MVVAkaCP5BoyCAoCCJpJXFChLIJCJRA0EwSFK0DQTETdIieCISjUAkEziekm naW5R1D8BAkEzQRB4QruKuhi4SMxVYLcxZV/F+AZXyOGeMFNAATNxNdt+txU ElS8YjUAguYiCyqfplki6PfnBjEURIzXAnQoqLOH2ZugZv3JJAyFEATNJBA0 8V37fEHfPzdovrugGAoBCJqJrVtKzrVshqCf/q0xwc9qA3y4raDz3NRdCZ5u 03eQKF427qexH9B+Qoq7C5pqSItwWtC0oI+YoOZ7axn6VZMxIpBB0ExcQadh h6CLjpah8+AQfoIIgmbyDbwM3iaugxER9GOmWR6/72k6IQmCZuILmkAW9Gvm d0ho8RQ/IcXdBPWHcasLmnElY1HQz4DQbKdZZwIkQNA85rDTq/ncuMxbrAU1 g7cfip+wxX0FTX6NpdjQV9ic1nNY+tnhPqhZ90Pf//ATNkHQPNYWdEgOEA1J QdcRovnoJ0ASBM1j2QV93yaLRgW1urRzKwqQ5g6COruWZwiaJiKo8R5z9hBk gKB5vPdB5W9/+nyb8ZSg3tFQgBgImscsaAayoCacxE/Y5MaCDqlLypca+hnF zSk5J2ELKuxusgcKOSBoHjsFXU6PD23ET8gAQfN4Zv8Uui3o+m0VdIR9GM2C ji/ECatMS0GXF+eZ24DagtqnDmEo7KJE0IgiySVHGO2UnAm3UFtB3y/QHkGl 0+MByigQNKZIaskRRvt+9GbapU4RdHMM9+vjJwkzPO3T4/ETdpIvaFSRxJIq 2IKG7XRcUM/C1FSMVdD0V0CHpS/7eN3+yWmeg/3VFfyEfRQLmujKthd0LGlB DwrqnBr/3Orfzi4+Xo/eXdy1Z8seKOymVFBBkZyVD2D1n8eiLm6NFnTmuTGC u/RjH69+7WuA6Gldagg/YS+FgkqKZKy7E2vsabT+gjKPd8HHvxfPfwuPfzbe lMM/mem5ECnxxawRX3udf63nXx7mMx/gAGZ63Y4LCVtiirgmVWR0H4/+vKWQ /XXswp/ltNYMmT5n+A1b+59L2/l5bD5d3B2JAHgUtaCyIm37tstEZKi4oaDT kC3on5WPdTxIOlkeYA8lgiYORbbAFXQUZs4zFAj6Hb/9OPoZxQU4ToGgMUXO ETS2rRqCSoa+j3sWBHtY40FP/IRKHDgOGj6oyyhMyZ8OrQQtiGXsEE96uFCJ /WcSrcNCrQR1B67i5+K2EbSsAUVQaMKBc3Hd09ibjONmgKBwZ1R/myWHFoIu pydkBzADgkILvC+EIujMVBQLQaENCGqtazEVCuoEQFCoBYJa61qUCWq8AE8E hTrcQlD7mn0ICncCQYc5gM18GYU8jB8AQaESCDrMAWwQFHSAoMMcwAZBQQc3 FHS5TskweGe5L+e9T4N/EvxjnWMGW1DpW2Pu7++awE8EhVrcTtDP1UlkFTPm DpMZzHuEyFiXtnWVXOatdwgKbUDQ5YGZ5rbzJejnG2PLb2FbSlq/j23my1Ij KLQBQdee7evPfAV9f61zuUTCYClpzRvmn802CAptuJmg8/W9XL5LYoSLP/o9 zcxralEyYKCLC624maBmbkETKg52w+l5aYw18ZzNDHx0WtCBFhSacS9BXx3Q 5/R9Uu99ymn+ws46N5h4rTU9jJnml2Pt4X4uD//e0HKJ+GAfNPATQaEWtxL0 PcjznD57kmbZr5xVtAw09sR78eNTdl30/fEG38V5nnOHoNCIOwn69mV6Lm3g PDL7aSKXuWZwJt46/gm6jOJ+jf46FhxRmefZdwgKTXB2zl50Kuj7p5Hevk3m uew4Tt89xmmYJ7zO6mfiPSQ0LZe1Hb67p851v1wlAxAUGnGPFvTz22XmK6gz liNOCYM+4Xe2Sy7pF6yKoFCF+wj67tBOc8Pn/nCuN+W0oN9FCAoauZWgf132 +Yc5B++8H+ksIHdRYGi+Y8KqCApVuJGgy5W+3LEcccpvYAcEBZV4wx59Czpf 6ct9UuKUCRZVFRQ/oQ73ENQejd7rRrgfuXtVBIVa3EPQZZBoQFC4FQg6U1NQ dkGhErcR9PMdzuGAG8EJ7ztXPJQEgMOdBP0+l0pNKIKCAu4j6ICgcD9uIuhn F/TzEEHhPtxF0M8XUN4gKNyHGwk6P5U6gh4axEVQqASCrvi/ULZntaM5ADgg 6AqCgjpuIqj9fWsEhftwH0GXZ/KswyMbISsEhTrcRdD45UgAOgZBARRzD0Gt o6AAd+I2guIn3JFbCPo6UR5B4Y7cRFBDCwq35B6CmoEmFG7JPQRdrqUJcC+6 F9S6XhiGwu3oXlBaULgz9xDUDIwSwS25h6D4CTflDoJyGBTui1uz+xSU/U+4 LQgKoJhbCIqfcFcQFEAxCAqgGAQFUEz/guIn3BgEBVAMggIoBkEBFHMDQfET 7guCAigGQQEUg6AAiuleUPyEO4OgAIpBUADFICiAYvoX9OoMABqCoACK6V3Q CUHhznQuqFGzC6rlpdOSh5pEtOSxM5G+BTV6TpXX8tJpyUNNIlry+EVBjaJL +ml56bTkoSYRLXncXdDxhTvL+uGk69Hy0mnJQ00iWvJoL6igyHmM1u0CLWiI ljzUJKIlj+aCioqcxejdf2EfNEBLHmoS0ZJHa0EjipzEd6tBC84oro+WPNQk oiWPfYkY92eHtgW9qJM7N9/B1lXsf77QUg+05KEmES157ErE/2HNTUEFRU5h /N4EW+/65W+BljzUJKIljz2JGP+nqbcElRQ5hdH6cxcA3BVj/X3ZocgpjOsn BMCvYKzbLa5VZFy62AC/gxmyDyNeq8jctiMo/BQm+zDitYpce5AH4CqyDyNe rAg9XIAkFyuyMYYF8OugCAAAAAAAAAAAAAAAAADAOag5PqsmkUHLOVdKXhAV b4yVgIp8TkPNSYBqEhkuu/CFh5JvCKp4Y6x3REU+p6HmNHo1iQzXXfjCRUMO g5I3xmoyVeRzHtdeK0lAQSKXXfjCz0IFSoTwBdVTY9ty7bWSBK5P5LoLXzgo SOGNTkEV1di2XHutpJDr81Cy56chhQ869vlcQRXV2MZce60kBx2Dczqq47Bc z+3qNAYlb4wjqJIaewZ6Lid2fQZvMi4Ad1Iizt2F6PjIsgVVUmNPQc3lxC5P wEFBNkr2/bTkYQmqpMaeg5rLiV2egIOCbJSIoSWPVVAtNfYclLz8ChJwUJCN lndGSR6/ehxUTX/h+gxsNGSj6525Oo9fPZNIyRidosGZNyqy0PJyKMjDSUFB PgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL/AfxnE0CFXWhCAAAAAElF TkSuQmCC --=====================_26722436==_ Content-Type: text/plain; name="bad.txt"; x-mac-type="42494E41"; x-mac-creator="74747874" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bad.txt" IyAgICAgICAgIHRpbWUgICBNQi9zIGF2Z19sZW4gbnNlbnQgYXZnX3dpbiBh ZHYvc2VudAogICAgICAgICAgIDAuMCAgICAxLjMgICAgIDE0NSAgIDkyNCAx Nzg5Ni4wICAgMC4zCiAgICAgICAgICAgMC4xICAgIDguMCAgICAgMTQ0ICA1 NTUxIDE3Nzc1LjAgICAwLjMKICAgICAgICAgICAwLjIgICAxMi45ICAgICAy NzIgIDQ3NDggMTc2ODguMCAgIDAuMwogICAgICAgICAgIDAuMyAgIDEzLjMg ICAgIDI3MiAgNDg4NyAxNzY4OC4wICAgMC4zCiAgICAgICAgICAgMC40ICAg MTUuMyAgICAgMjcyICA1NjE2IDE3Njg4LjAgICAwLjEKICAgICAgICAgICAw LjUgICAxNS4zICAgICAyNzIgIDU2MzIgMTc2ODguMCAgIDAuMQogICAgICAg ICAgIDAuNiAgIDE1LjIgICAgIDI3MiAgNTYwMyAxNzY4OC4wICAgMC4xCiAg ICAgICAgICAgMC43ICAgMTUuMyAgICAgMjcyICA1NjMyIDE3Njg4LjAgICAw LjEKICAgICAgICAgICAwLjggICAxNS4wICAgICAyNzIgIDU1MDkgMTc2ODgu MCAgIDAuMQogICAgICAgICAgIDAuOSAgIDE1LjEgICAgIDI3MiAgNTU2NyAx NzY4OC4wICAgMC4xCiAgICAgICAgICAgMS4wICAgMTUuNCAgICAgMjcyICA1 Njc1IDE3Njg4LjAgICAwLjEKICAgICAgICAgICAxLjEgICAxNS40ICAgICAy NzIgIDU2NDcgMTc2ODguMCAgIDAuMQogICAgICAgICAgIDEuMiAgIDE1LjQg ICAgIDI3MiAgNTY2NyAxNzY4OC4wICAgMC4xCiAgICAgICAgICAgMS4zICAg MTUuMyAgICAgMjcyICA1NjM0IDE3Njg4LjAgICAwLjEKICAgICAgICAgICAx LjQgICAxNS40ICAgICAyNzIgIDU2NjggMTc2ODguMCAgIDAuMQogICAgICAg ICAgIDEuNSAgIDE1LjIgICAgIDI3MiAgNTYwNSAxNzY4OC4wICAgMC4xCiAg ICAgICAgICAgMS42ICAgMTUuMiAgICAgMjcyICA1NTkzIDE3Njg4LjAgICAw LjEKICAgICAgICAgICAxLjcgICAxNS40ICAgICAyNzIgIDU2NDUgMTc2ODgu MCAgIDAuMQogICAgICAgICAgIDEuOCAgIDE1LjQgICAgIDI3MiAgNTY1NSAx NzY4OC4wICAgMC4xCiAgICAgICAgICAgMS45ICAgMTUuMiAgICAgMjcyICA1 NTc2IDE3Njg4LjAgICAwLjEKICAgICAgICAgICAyLjAgICAxOC4xICAgICAz NDAgIDUzMDkgMTc2ODguMCAgIDAuMQogICAgICAgICAgIDIuMSAgIDIwLjMg ICAgIDQwMCAgNTA3OCAxNzY4OC4wICAgMC4yCiAgICAgICAgICAgMi4yICAg MjAuMiAgICAgMzk5ICA1MDU2IDE3Njg4LjAgICAwLjIKICAgICAgICAgICAy LjMgICAyMC4yICAgICA0MTMgIDQ4OTEgMTc2ODguMCAgIDAuMgogICAgICAg ICAgIDIuNCAgIDIxLjUgICAgIDU3OSAgMzcxOCAxNzY4OC4wICAgMC41CiAg ICAgICAgICAgMi41ICAgMjMuNCAgICAgNjU2ICAzNTYwIDE3Njg4LjAgICAw LjUKICAgICAgICAgICAyLjYgICAyMy45ICAgICA2NjQgIDM1OTUgMTc2ODgu MCAgIDAuNQogICAgICAgICAgIDIuNyAgIDI1LjEgICAgIDc4NCAgMzIwNiAx NzY4OC4wICAgMC42CiAgICAgICAgICAgMi44ICAgMjUuNCAgICAgNzg0ICAz MjM3IDE3Njg4LjAgICAwLjcKICAgICAgICAgICAyLjkgICAyNy4xICAgICA4 ODAgIDMwODMgMTc2ODguMCAgIDAuNwogICAgICAgICAgIDMuMCAgIDMyLjcg ICAgMTA0MyAgMzEzNyAxNzY4OC4wICAgMC42CiAgICAgICAgICAgMy4xICAg MzUuMiAgICAxMjk2ICAyNzE2IDE3Njg4LjAgICAwLjcKICAgICAgICAgICAz LjIgICAzNi43ICAgICA5NTkgIDM4MjggMTc2ODguMCAgIDAuNQogICAgICAg ICAgIDMuMyAgIDQyLjcgICAgIDg1MiAgNTAxMiAxNzY4OC4wICAgMC4zCiAg ICAgICAgICAgMy40ICAgNjMuNyAgICAxMTE2ICA1NzA3IDE3Njg4LjAgICAw LjEKICAgICAgICAgICAzLjUgICA3Mi4wICAgIDI3OTIgIDI1NzkgMTc2ODgu MCAgIDAuNAogICAgICAgICAgIDMuNiAgIDY4LjIgICAgMjk1MSAgMjMwOSAx NzY4OC4wICAgMC40CiAgICAgICAgICAgMy43ICAgNTcuNCAgICA4ODAwICAg NjUyIDE3Njg4LjAgICAxLjIKICAgICAgICAgICAzLjggICA1Ny45ICAgIDc3 MDYgICA3NTEgMTc2ODguMCAgIDEuMAogICAgICAgICAgIDMuOSAgIDU4LjMg ICAgNzE2NSAgIDgxNCAxNzY4OC4wICAgMC45CiAgICAgICAgICAgNC4wICAg NTcuOSAgICA3MTQ5ICAgODEwIDE3Njg4LjAgICAwLjkKICAgICAgICAgICA0 LjEgICA1NS45ICAgIDc0NTkgICA3NTAgMTc2ODguMCAgIDAuOQogICAgICAg ICAgIDQuMiAgIDU2LjEgICAgNzQ5NSAgIDc0OSAxNzY4OC4wICAgMC45CiAg ICAgICAgICAgNC4zICAgNTUuNSAgICA3NzM2ICAgNzE3IDE3Njg4LjAgICAw LjkKICAgICAgICAgICA0LjQgICA1NS42ICAgIDgxNTAgICA2ODIgMTc2ODgu MCAgIDEuMAogICAgICAgICAgIDQuNSAgIDU1LjUgICAgODEyNCAgIDY4MyAx NzY4OC4wICAgMS4wCiAgICAgICAgICAgNC42ICAgNTYuMCAgICA4NTQ0ICAg NjU1IDE3Njg4LjAgICAxLjAKICAgICAgICAgICA0LjcgICA1Ni4wICAgIDg1 MjQgICA2NTcgMTc2ODguMCAgIDEuMAogICAgICAgICAgIDQuOCAgIDU0LjIg ICAgODg0MCAgIDYxMyAxNzY4OC4wICAgMS4wCiAgICAgICAgICAgNC45ICAg NTMuOSAgICA4OTIzICAgNjA0IDE3Njg4LjAgICAxLjAKICAgICAgICAgICA1 LjAgICA1NC4wICAgIDg5MDUgICA2MDYgMTc2ODguMCAgIDEuMAogICAgICAg ICAgIDUuMSAgIDU0LjMgICAgODk0OCAgIDYwNyAxNzY4OC4wICAgMS4wCiAg ICAgICAgICAgNS4yICAgNTQuMSAgICA4ODk3ICAgNjA4IDE3Njg4LjAgICAx LjAKICAgICAgICAgICA1LjMgICA1NC4wICAgIDg5NDggICA2MDQgMTc2ODgu MCAgIDEuMAogICAgICAgICAgIDUuNCAgIDUzLjggICAgODkyNyAgIDYwMyAx NzY4OC4wICAgMS4wCiAgICAgICAgICAgNS41ICAgNTQuMiAgICA4OTQ4ICAg NjA2IDE3Njg4LjAgICAxLjAKICAgICAgICAgICA1LjYgICA1NC4zICAgIDg5 NDggICA2MDcgMTc2ODguMCAgIDEuMAogICAgICAgICAgIDUuNyAgIDUyLjYg ICAgODg5MiAgIDU5MiAxNzY4OC4wICAgMS4wCiAgICAgICAgICAgNS44ICAg NTAuMCAgICA4OTQ4ICAgNTU5IDE3Njg4LjAgICAxLjAKICAgICAgICAgICA1 LjkgICA1MS45ICAgIDg5MTAgICA1ODIgMTc2ODguMCAgIDEuMAogICAgICAg ICAgIDYuMCAgIDUxLjEgICAgODg5MSAgIDU3NSAxNzY4OC4wICAgMS4wCiAg ICAgICAgICAgNi4xICAgNTAuOSAgICA4OTM0ICAgNTcwIDE3Njg4LjAgICAx LjAKICAgICAgICAgICA2LjIgICA1MC4wICAgIDg4ODMgICA1NjMgMTc2ODgu MCAgIDEuMAogICAgICAgICAgIDYuMyAgIDUwLjQgICAgODg4NCAgIDU2NyAx NzY4OC4wICAgMS4wCiAgICAgICAgICAgNi40ICAgNTAuMSAgICA4OTEyICAg NTYyIDE3Njg4LjAgICAxLjAKICAgICAgICAgICA2LjUgICA1Mi4xICAgIDg4 ODcgICA1ODYgMTc2ODguMCAgIDEuMAogICAgICAgICAgIDYuNiAgIDUwLjUg ICAgODg3OSAgIDU2OSAxNzY4OC4wICAgMS4wCiAgICAgICAgICAgNi43ICAg NTEuNCAgICA4OTA5ICAgNTc3IDE3Njg4LjAgICAxLjAKICAgICAgICAgICA2 LjggICA1MC43ICAgIDg5MDMgICA1NjkgMTc2ODguMCAgIDEuMAogICAgICAg ICAgIDYuOSAgIDUyLjAgICAgODg4OSAgIDU4NSAxNzY4OC4wICAgMS4wCiAg ICAgICAgICAgNy4wICAgNTAuMSAgICA4ODk3ICAgNTYzIDE3Njg4LjAgICAx LjAKICAgICAgICAgICA3LjEgICA1Mi4yICAgIDg5MTcgICA1ODUgMTc2ODgu MCAgIDEuMAogICAgICAgICAgIDcuMiAgIDUyLjQgICAgODkxNCAgIDU4OCAx NzY4OC4wICAgMS4wCiAgICAgICAgICAgNy4zICAgNTIuMyAgICA4OTM3ICAg NTg1IDE3Njg4LjAgICAxLjAKICAgICAgICAgICA3LjQgICA0OS4yICAgIDg5 MDUgICA1NTIgMTc2ODguMCAgIDEuMAogICAgICAgICAgIDcuNSAgIDUyLjQg ICAgODkxOCAgIDU4NyAxNzY4OC4wICAgMS4wCiAgICAgICAgICAgNy42ICAg NTIuNSAgICA4OTExICAgNTg5IDE3Njg4LjAgICAxLjAKICAgICAgICAgICA3 LjcgICA0Ny43ICAgIDg5MTYgICA1MzUgMTc2ODguMCAgIDEuMAogICAgICAg ICAgIDcuOCAgIDUyLjUgICAgODkzNiAgIDU4OCAxNzY4OC4wICAgMS4wCiAg ICAgICAgICAgNy45ICAgNTIuNCAgICA4OTM0ICAgNTg3IDE3Njg4LjAgICAx LjAKICAgICAgICAgICA4LjAgICA1Mi4yICAgIDg5MjYgICA1ODUgMTc2ODgu MCAgIDEuMAogICAgICAgICAgIDguMSAgIDUyLjMgICAgODkyOSAgIDU4NiAx NzY4OC4wICAgMS4wCiAgICAgICAgICAgOC4yICAgNTIuNyAgICA4OTQxICAg NTg5IDE3Njg4LjAgICAxLjAKICAgICAgICAgICA4LjMgICA0Ni4yICAgIDg5 MjcgICA1MTcgMTc2ODguMCAgIDEuMAogICAgICAgICAgIDguNCAgIDUyLjQg ICAgODkxOCAgIDU4NyAxNzY4OC4wICAgMS4wCiAgICAgICAgICAgOC41ICAg NTIuNCAgICA4OTMzICAgNTg3IDE3Njg4LjAgICAxLjAKICAgICAgICAgICA4 LjYgICA1Mi41ICAgIDg5MzMgICA1ODggMTc2ODguMCAgIDEuMAogICAgICAg ICAgIDguNyAgIDUyLjQgICAgODkzMyAgIDU4NyAxNzY4OC4wICAgMS4wCiAg ICAgICAgICAgOC44ICAgNTIuNCAgICA4OTE4ICAgNTg4IDE3Njg4LjAgICAx LjAKICAgICAgICAgICA4LjkgICA1Mi4zICAgIDg5MzMgICA1ODYgMTc2ODgu MCAgIDEuMAogICAgICAgICAgIDkuMCAgIDQzLjggICAgODkzMCAgIDQ5MCAx NzY4OC4wICAgMS4wCiAgICAgICAgICAgOS4xICAgNTIuMyAgICA4OTQwICAg NTg1IDE3Njg4LjAgICAxLjAKICAgICAgICAgICA5LjIgICA1Mi42ICAgIDg5 NDggICA1ODggMTc2ODguMCAgIDEuMAogICAgICAgICAgIDkuMyAgIDUyLjQg ICAgODkyNSAgIDU4NyAxNzY4OC4wICAgMS4wCiAgICAgICAgICAgOS40ICAg NTIuNSAgICA4OTQwICAgNTg3IDE3Njg4LjAgICAxLjAKICAgICAgICAgICA5 LjUgICA1Mi4yICAgIDg5MjUgICA1ODUgMTc2ODguMCAgIDEuMAogICAgICAg ICAgIDkuNiAgIDUyLjUgICAgODk0MCAgIDU4NyAxNzY4OC4wICAgMS4wCiAg ICAgICAgICAgOS43ICAgNTIuNSAgICA4OTI1ICAgNTg4IDE3Njg4LjAgICAx LjAKICAgICAgICAgICA5LjggICA1Mi41ICAgIDg5NDggICA1ODcgMTc2ODgu MCAgIDEuMAogICAgICAgICAgIDkuOSAgIDUyLjQgICAgODk0MCAgIDU4NiAx NzY4OC4wICAgMS4wCiAgICAgICAgICAxMC4wICAgNTIuNyAgICA4OTQwICAg NTg5IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDEwLjEgICA0MC41ICAgIDg5 MTkgICA0NTQgMTc2ODguMCAgIDEuMAogICAgICAgICAgMTAuMiAgIDUyLjcg ICAgODk0OCAgIDU4OSAxNzY4OC4wICAgMS4wCiAgICAgICAgICAxMC4zICAg NTIuMiAgICA4OTMyICAgNTg0IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDEw LjQgICA1Mi41ICAgIDg5MzMgICA1ODggMTc2ODguMCAgIDEuMAogICAgICAg ICAgMTAuNSAgIDUyLjMgICAgODk0OCAgIDU4NSAxNzY4OC4wICAgMS4wCiAg ICAgICAgICAxMC42ICAgNTIuNSAgICA4OTMzICAgNTg4IDE3Njg4LjAgICAx LjAKICAgICAgICAgIDEwLjcgICA1Mi42ICAgIDg5NDggICA1ODggMTc2ODgu MCAgIDEuMAogICAgICAgICAgMTAuOCAgIDUwLjcgICAgODkzMiAgIDU2OCAx NzY4OC4wICAgMS4wCiAgICAgICAgICAxMC45ICAgNTEuOCAgICA4OTMyICAg NTgwIDE3Njg4LjAgICAxLjAKICAgICAgICAgIDExLjAgICA1Mi4zICAgIDg5 NDggICA1ODUgMTc2ODguMCAgIDEuMAogICAgICAgICAgMTEuMSAgIDUyLjMg ICAgODkzMyAgIDU4NiAxNzY4OC4wICAgMS4wCiAgICAgICAgICAxMS4yICAg NTIuNSAgICA4OTMzICAgNTg4IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDEx LjMgICA1Mi4zICAgIDg5NDggICA1ODUgMTc2ODguMCAgIDEuMAogICAgICAg ICAgMTEuNCAgIDUyLjMgICAgODkzMiAgIDU4NiAxNzY4OC4wICAgMS4wCiAg ICAgICAgICAxMS41ICAgNTIuMyAgICA4OTQ4ICAgNTg1IDE3Njg4LjAgICAx LjAKICAgICAgICAgIDExLjYgICAzNS4yICAgIDg5MjYgICAzOTQgMTc2ODgu MCAgIDEuMAogICAgICAgICAgMTEuNyAgIDUyLjUgICAgODk0OCAgIDU4NyAx NzY4OC4wICAgMS4wCiAgICAgICAgICAxMS44ICAgNTIuNCAgICA4OTMyICAg NTg3IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDExLjkgICA1Mi40ICAgIDg5 NDggICA1ODYgMTc2ODguMCAgIDEuMAogICAgICAgICAgMTIuMCAgIDUyLjcg ICAgODk0OCAgIDU4OSAxNzY4OC4wICAgMS4wCiAgICAgICAgICAxMi4xICAg NTIuMiAgICA4OTMzICAgNTg0IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDEy LjIgICA1Mi44ICAgIDg5NDggICA1OTAgMTc2ODguMCAgIDEuMAogICAgICAg ICAgMTIuMyAgIDUyLjIgICAgODkzMiAgIDU4NCAxNzY4OC4wICAgMS4wCiAg ICAgICAgICAxMi40ICAgNTIuNSAgICA4OTQ4ICAgNTg3IDE3Njg4LjAgICAx LjAKICAgICAgICAgIDEyLjUgICA1Mi4zICAgIDg5NDggICA1ODUgMTc2ODgu MCAgIDEuMAogICAgICAgICAgMTIuNiAgIDUyLjMgICAgODkzMyAgIDU4NiAx NzY4OC4wICAgMS4wCiAgICAgICAgICAxMi43ICAgNTIuMyAgICA4OTQ4ICAg NTg1IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDEyLjggICA1Mi4zICAgIDg5 MzIgICA1ODYgMTc2ODguMCAgIDEuMAogICAgICAgICAgMTIuOSAgIDUyLjQg ICAgODk0OCAgIDU4NiAxNzY4OC4wICAgMS4wCiAgICAgICAgICAxMy4wICAg NTIuMyAgICA4OTMzICAgNTg1IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDEz LjEgICA1Mi4zICAgIDg5NDggICA1ODUgMTc2ODguMCAgIDEuMAogICAgICAg ICAgMTMuMiAgIDUyLjYgICAgODk0OCAgIDU4OCAxNzY4OC4wICAgMS4wCiAg ICAgICAgICAxMy4zICAgNTIuNCAgICA4OTMyICAgNTg3IDE3Njg4LjAgICAx LjAKICAgICAgICAgIDEzLjQgICA1Mi41ICAgIDg5NDggICA1ODcgMTc2ODgu MCAgIDEuMAogICAgICAgICAgMTMuNSAgIDUyLjMgICAgODkzMiAgIDU4NSAx NzY4OC4wICAgMS4wCiAgICAgICAgICAxMy42ICAgNTIuNSAgICA4OTQ4ICAg NTg3IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDEzLjcgICA1Mi40ICAgIDg5 NDggICA1ODYgMTc2ODguMCAgIDEuMAogICAgICAgICAgMTMuOCAgIDI5LjUg ICAgODg2OCAgIDMzMyAxNzY4OC4wICAgMS4wCiAgICAgICAgICAxMy45ICAg NTMuMiAgICA4OTQ4ICAgNTk0IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDE0 LjAgICA1My4zICAgIDg5NDggICA1OTYgMTc2ODguMCAgIDEuMAogICAgICAg ICAgMTQuMSAgIDUzLjEgICAgODk0NyAgIDU5MyAxNzY4OC4wICAgMS4wCiAg ICAgICAgICAxNC4yICAgNTIuNiAgICA4OTQ4ICAgNTg4IDE3Njg4LjAgICAx LjAKICAgICAgICAgIDE0LjMgICA1Mi4zICAgIDg5NDggICA1ODQgMTc2ODgu MCAgIDEuMAogICAgICAgICAgMTQuNCAgIDUyLjUgICAgODkzMyAgIDU4OCAx NzY4OC4wICAgMS4wCiAgICAgICAgICAxNC41ICAgNTIuNSAgICA4OTQ4ICAg NTg3IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDE0LjYgICA1Mi41ICAgIDg5 NDggICA1ODcgMTc2ODguMCAgIDEuMAogICAgICAgICAgMTQuNyAgIDUyLjMg ICAgODk0OCAgIDU4NCAxNzY4OC4wICAgMS4wCiAgICAgICAgICAxNC44ICAg NTIuNSAgICA4OTQ3ICAgNTg3IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDE0 LjkgICA1Mi4zICAgIDg5NDggICA1ODQgMTc2ODguMCAgIDEuMAogICAgICAg ICAgMTUuMCAgIDUyLjUgICAgODk0OCAgIDU4NyAxNzY4OC4wICAgMS4wCiAg ICAgICAgICAxNS4xICAgNTIuMyAgICA4OTMzICAgNTg2IDE3Njg4LjAgICAx LjAKICAgICAgICAgIDE1LjIgICA1Mi40ICAgIDg5NDggICA1ODYgMTc2ODgu MCAgIDEuMAogICAgICAgICAgMTUuMyAgIDUyLjMgICAgODk0OCAgIDU4NSAx NzY4OC4wICAgMS4wCiAgICAgICAgICAxNS40ICAgNTIuNCAgICA4OTQ3ICAg NTg2IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDE1LjUgICA1Mi4yICAgIDg5 NDggICA1ODMgMTc2ODguMCAgIDEuMAogICAgICAgICAgMTUuNiAgIDUyLjUg ICAgODk0OCAgIDU4NyAxNzY4OC4wICAgMS4wCiAgICAgICAgICAxNS43ICAg NTIuMSAgICA4OTMzICAgNTgzIDE3Njg4LjAgICAxLjAKICAgICAgICAgIDE1 LjggICA1MS4yICAgIDg5NDggICA1NzIgMTc2ODguMCAgIDEuMAogICAgICAg ICAgMTUuOSAgIDUxLjUgICAgODk0OCAgIDU3NiAxNzY4OC4wICAgMS4wCiAg ICAgICAgICAxNi4wICAgNTIuMyAgICA4OTQ3ICAgNTg1IDE3Njg4LjAgICAx LjAKICAgICAgICAgIDE2LjEgICA1Mi40ICAgIDg5NDggICA1ODYgMTc2ODgu MCAgIDEuMAogICAgICAgICAgMTYuMiAgIDUyLjcgICAgODk0OCAgIDU4OSAx NzY4OC4wICAgMS4wCiAgICAgICAgICAxNi4zICAgNTIuMyAgICA4OTQ4ICAg NTg1IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDE2LjQgICA1Mi41ICAgIDg5 NDcgICA1ODcgMTc2ODguMCAgIDEuMAogICAgICAgICAgMTYuNSAgIDUyLjUg ICAgODk0OCAgIDU4NyAxNzY4OC4wICAgMS4wCiAgICAgICAgICAxNi42ICAg NTIuNyAgICA4OTQ4ICAgNTg5IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDE2 LjcgICAxNC4zICAgIDg3NjcgICAxNjMgMTc2ODguMCAgIDEuMAojIHRvdCBz ZW50OiAyNDkwNTkgLCB0b3RfcmVjdmQ6IDExODY4MywgdG90X290aGVyczog Mgo= --=====================_26722436==_ Content-Type: image/png; name="bw_winsiz.png"; x-mac-type="504E4766"; x-mac-creator="6D646F73" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bw_winsiz.png" iVBORw0KGgoAAAANSUhEUgAAA6AAAAK4CAMAAABd6WDBAAAAA3NCSVQICAjb 4U/gAAABKVBMVEX///8AAAAAAAD/AAAAwAAAgP/AAP/A/0DAQABA/4AgIMCA AMAAYIAAgAAAgEAAgIAAwGAAwMAA/wAggCAwYIBAQEBAgAAAAICAYACAYBCA YGCAYIAAAMAAAP8AYABAwIBgoMBgwABgwKCAAACAAIBgIIBgYGAA//8gICAg QEAgQIBggCBggGBggICAgECAgICgoKCg0ODAICDAYACAwODAYMDAgADAgGD/ QAD/QECAwP//gGD/gIDAoADAwMDA/8D/AAD/AP//gKD/gP/AwKD/YGD/gAD/ oACA4OCg4OCg/yDAAADAAMCgICCgIP+AIACAICCAQACAQCCAQICAYMCAYP+A gACggP/AYIDAwAD/gED/oED/oGD/oHD/wCD/wMD//wD//4D//8BTi7KnAAAA O3RFWHRTb2Z0d2FyZQBnbnVwbG90IHZlcnNpb24gMy43IHBhdGNobGV2ZWwg MiBvbiBMaW51eCAyLjQuMy0xMrFi8REAACAASURBVHic7Z2LoqsoEgB1OZn/ /+S9eag8GgVtFdqqmXsSFIFOqKBozDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAWGB800Wh35L1S+whfq8wxbJPKXVcTSoUelrfapLR+9t2od8y9V2a/yiX qVmoF7Zi2aeUGr1DOm+YX8oZb1i7jNFju4X+StQu85RPEe2yvSFDsexTSo1G N503bEw+Sh7DL9xz9hnOGO1OGeuUOeEDKlZJaWDaXHCwULU3LPkoeQrTrk0X go76ZXYqqNIbdragem/YswXVH5iWsrXL60HQE47Bww6q9YbFhSgXqviGPVrQ MwamE2bazpnOGvuYxQ46qNobdu4sruYbthR6zhvWLKPq55xXqj7jeMKbMwYP uqWeNYLqvWGnTL3ELqm8YckxuEKZXTCeMTCd+eqdtIvb+iy210EV37BTdhzH 1eTRQs87Q9Am4xmfSAiqXqg3LCmWjaDNc2oHPYPHC6pZNoK2zxlTLx0JetLU k3qh8dFiw3Oj5wp6zhvWMidMip0ynTOVrV5gB7O4QXFqZXsF6b1jSSkqU0Sn xA8AAAAAAAAAAAAAAAAAAArkLuPg7C5AfEFG/gKIsy6NyN2x6XHXRwGsMCZ/ SxMH683cselxVxgDrBF8pbYmoVPz8jwUlJ1cgCEeIMeKhFLV89NokEZQANGK woRW3UM4PE/PERQg3oEdKxJqlaeHueMg1DECmKNCkdmKwsRhwqnhqbXBh4GY XZPKQguzn9pU1cL3FVbarVTJnZXTLFRn64pC17MG+5g1g+cpL848gmamihH0 hMIR9ISttQQNJmk8KwoTh8kIOoprERRBT6ikZUH9dYEVhYnD5EbQTB0IekLh CHrC1jqCjlJirEgcJvOK5wZpBD2hcAQ9YesTBA2tKEwcI5nDGrNrovWaIOgJ WyGoRv1xvL4VhYlrQdATCkfQE7ZWOgbtDQQ9oXAEPWFrBL2tUAQt2QpBL6q/ LSzFAvDBUqe2FAvAB0ud2lIsAB8sdeqdsbg3v6dD+OhlqiyzMlv6BOANgrrk r2SJhqAuWYqgsMHjBQ0GzUBTMVtlqeHC8wTFa6sgqP/o/CVitspSS7MdFNRh qFUQ1H90Q04R5x+qRsetwprAdHFEXrJ9n7t59PZLK48BQ22CoP6jyw5Fiz/x puEaf1ksqOedixZ4T/KjeI78jjl0D4L6j/ldRXE0TDXMJ8QnwprcPJU7RCYq aB4E9R9ddiC6XdAVGEENg6D+49oxaPDoDUzKgsYLSuAY1C4I6j9uz+KmB5zr ggbunCUos7h2QVD/Mb+zWDhOHhFUHnXLwE+rPF7QQMr8AaA0Vysp5cLcLhjc 8rO4c7adgoJVELT0Wtz0bKd4MsU/wRmNn5nTpeHm2RbAI0FQgIax1KktxQLw wVKnthQLwAdLndpSLAAfLHVqS7EAfLDUqS3FAvDBUqe2FAvAB0ud2lIsAB8s derVWP7e/J4O4eMGhdkATuApgv4lf4vFqxT0b4fQe7aBR/AQQYNBM9B0GwSF +3isoOVKIA/cx1MFzVnnHapOicDndLu1NUFpaT3Cqr+JTPvgYTxS0L+NUTE4 SP2rFNT3O7NJchic+Iif8OWRgm72/9TJihE0eZLfJrdgbWjdhRwmtM8zBd0y 9GxBk0V/q2vhuTxU0PVjUGGvVlnQ+Og0yIKfMPNUQTMW/MXZ5sfs8eTfEClf JGi04k9cCvBYQdfmbsRBMzfuHhBU2AY/IeAhgpZeSfQn5F48y426f8G68kki aQTFT/B5iqCl1+IGs57eedBc/mm5d26lpJ5wbjWuknlXmHiMoAA9YqlTW4oF 4IOlTm0pFoAPljq1pVgAPljq1JZiAfhgqVNbigXgg6VObSkWgA+WOrWlWAA+ WOrUpbG8vngLsmvSLIVVVGZLnwC8eaKgPw08KV6ZNdEW5YjZU/MRFDZ4sKCz DImggiaNC4rXVkHQz8NLXJNsUVlBeTYEBRkELRU0ODr1EuKaYE9ZPKZdsgVH vq9vsjiSlSrAAg8W1PMzlkkQVFjxEtb4y2JBPe9e0YL4eLhWOAS1ykMF9Uap QkGjxyXxKkuIT4Q1r2hB0OTdJPFAJzxU0PlP7Eqzgq6DgVZ5sKA/i8JBplBQ bxtlQeMFZSCoVRA0WFQoqJ95XVBhBiqtFEEhB4IGi8oErUhUCCqPumUgqFUe LGj+GFTo7tJcraTUK8z9GtKrIJJsU1ahOfB0niiocNAZHpBK2whnO8WTKf4J zmj8zJwuDTcPk7tw+3O7/LI9ZcNhniiocVyVRUHuX0Jatqds+HHgRbPUqS3F sh835DtEujzI/UtIy7bL7pZ8QNKautzTGpdkcNKDgKVObSmW3Tjvb7ouXh7k /iWkZdtld0t+pyBc44RlpeX8Pvey+yorOyaWOrWlWPbivH+5dZncnyc/gmVi omtc+NQVrHEr4QtrkqcuyBDuq6y9qJY6taVYduN+/0lrlr9i7l8fdPNTIYNr 2s/CfVIXmhKII6xZ/sm7EC5dE5UzfejJ+yqrOyaWOrWlWPbj5rc8We5/Ykej op8lKCFMOLnsRpA+mIT9VC9mJyenpy78hAp2LoIyp1fJRUX+7Aw2nT4HA5JS Jyx1akux7MYNOYl+3WTZW/tk/HW/ecmvDNlJd9csrjgMSkviXUthPzUYsNwU 1JLR359w856t51Hq5yxhNJxOZcx/pgzLsuljgBH0AQQf0dJqNwS9bOrCyyjh dVvvWbDndoehwjRour8p7WWGy+ZRMQjVLS+BMAwuZgWvWlDrtOPvjZJLNc5r ypQhqmbtZbXUqcNY/vviLciuWac4490ER4u5DEvv8HqFsIcVfKz7DxcJ6qLn 0QdPPgavrZGM01jnqftdMB93h8PgLG1obPRqublti5iLjMGEm5tq8/dVpjZk sCvoz6xFS8+0cM0GlYKWm39sm4Sg34gfyf4nvQt6rvAZ7u/bni1oWmYsYzjs ee0OlkUfKf4efaBsdMZjHj3DYXCIX6G5lKh5y37wVMVSVfCepJ8rqx+ob8wL OvuVCFpqXieCRuOJPGEyDF4/G4I+F/eSYMLWV1PfUPn8bDA0htOgwSIv5qDf T4Z4HzOTR8GAtUxee8NgdmROmhcUF+gcti7MIMQr8xhB/xuC0XQYzhL0JqJ+ JJ4PCceAdDwK84a91EW5FRE+HIKKvupEY/7PpHBcDSef5y3nhdOLEtTmwhcm MVL6+IgMTWNxfmI92KRBAQgabeMfnX4Twf5wus3amvyxbu4w+L//Ko+QZ5zX 1ZIuNOUIVoY9LFUk6qXRMKFG+vEgKRLNdfrTz4GAQ5BhCOKcR9hY0PAFiPPk HBNfkGjvWXJReP06FdRr3PhGTIjZP/hmxbu7fioh3KZSUN/vbDVBDcIu7p5R O5ojyo1LQ9oD5VHCz+POEzSzCxnsAUQnMOZF32HUW+aXkTTY//yKGhB7tR5k 0rykODFRuezLuqBZKwoTx/DKGb2/YcLPH6X9kahKUGHQrBhBkyf5bXIL1obW XXyK2OhzwhJ/JzPc31XECfvj8aTVVyKXLIr2AzJyJFoK+aJF6xGm00wH2Sno 6OXIK1Ikzw5864UGpZWsjKCRK3cLmiz6b3VtKWGfSabuK/tRfp5E39B0ABdk FP1zBYLOO8PCqtoRbaV5B9gn6Cg8TxUpk2cXsoLTR0GZoD+/wkO7jWNQYa9W WdD46DTIsntWan2ntbofxSOOt7+raaiLuntc+bAqaMkImlyiuCnoJsdLyBcX sGLSKCTGVJF84jBrgo6FI6joV1ZQf720P5zZRJiBSivN1hZl2T9rvL6bdqQb xfu7WoZOx5HCmsIRNHjyeEFHQZF84jBxKd7+81i6i1sl6Nqg+Z+4xSFBhW2O +Llh5KFutH5e8Eipbio0WiUJJe6lxg2TcqwcNO6Lo01BR38M204cRp7FHb1/ YfaZ//1j8xh0c3bVn8X9JGV3/vv9F5VRsFssjaB6fuYE/d8uXPDMeen9uLnc tDTnooxRNieulDaaV6SbyFWX4LKJfcRFLH05/34HGQIrChOHiWdx5+djvCzJ NAzCQWd4QCpWGW61nAf1C0m28dflKpWqkbbZfR5U+BiOZ0aV0Bs/h6tG0OzG jYyg+SK2R9B5v7Jm8FQWNBrMM1PFSmd3umVdUOVpHY1S1vaXywX1j1BXJMxJ 2b2gk3FjdeIwGUFHYaFepf2yPhWqKGjtJFEmrzfbpCBoXM7qjFkuXzHtCTrW Jw6TG0EzdSDo2hJNQX/lFRaZPW26nK85W9CVCTMrgu5IHEYWNDtII+jaIm1B i2+vsHLIuvL9VSc1fb+gQptK8pUUoHY8LrLWqQMR9iSO4U9RhVNahdfiPo1V QdX9LJ0ryg2Rn6XC0BivGjYF9VryLEF3XX6reC1uLQgqLMorcLi2IkPz00DD 6udH+o3tAUE7x1Ise5De5I2boByrrNDQ7KWBK5o40V4E7RpLsexBGkFXpmGO 11Y2T5S/VyeCbpdhqVNbimUPwoHc0tNPOQYtOh2an0zSElTcT0DQ5rAUyx6E 47j5n76f4WHiejYtQXMHrfPXYRC0ZSzFsgdxBC2dzNlVYdEAOv8R1wjPf+ka QS8fQRVKyBUXYqlTW4plD9Ix6PTvFEHLDkGz+dQEXY5yEbRlLMWyg4wE4k1v T61TyHFIUMkFl+SNPwgQtDksxbKD/EzpeYaWCipmVBLURf9Kmoagd2Aplh1k 3+OVM5HnVTrVnM/nVlKBbQUj6PQXQVvGUiw7yL3HwuhyfqW/lSvX8ukJ6mfO zCKt1I2gl2Eplh2sjKCrq8+p9LvuGkHFkRpBm8NSLDvI95PTxs+CWvOGKgoq LUfQ5rAUyw5W+slps7h5ZeI966QBOcXCraNV2drS5QjaHJZi2cHG3ubJtW79 xBCClhYXYqlTW4plB+dJWFCttBcdzh3H10ogaKa4EEud2lIsO7hTUHEeKrxK fuW2QJkkgg62OrWlWHZwo6DR8ea8wu/FYXJrlzenfX7OKVq+/mog6B1YimUH Nwnq/Tb1yhDpImHTi4NvEnTvq4ag9ViKZQe3CTr8LkgI+2ziVbjXiqDZ8gIs dWpLsezgrl3caXD0Zm3Tr4CGI6gThlAEFbHUqS3FUs99h6Bu/vlN72fpU/+C ixbiIbZS0GywCNowlmKp5x5Bo33Xz9NJ1ShncNlfMqWEoDKWOrWlWOq5bwQd PG8+g6eLD0n9PAMj6EZ5AZY6taVY6rlvjigaP39D5doskPij92kKQW11akux 1HOXoL5rP6Ok8TNcIvzoPYKKWOrUlmKp5zZB477qpCPQQRZtY332SPWooMX5 tgtA0GIsxVLPfYL6ZH+QF0GLywuw1KktxVJPG4KuNANBC8sLsNSpLcVSTyOC 5lERVDouFUtB0PawFEs9pgT1p4WlXAjaI5ZiqQdBgzXXCarzwiOodRA0WIOg 7WEplnqaF1QycGM1gprq1JZiqad7QYXDOgQ11aktxVJP94L6VxctmsUZEbRf LMVSTft+bggaXJ+7IehKsAjaLpZiqaZ3Qd30f7AaQS11akuxVNOXoJKf/hHn YUG3Xg4EvQFLsVTTuaDaIyiCNoilWKrpXVDlY1AEbRBLsVTTvaCFs7jSqReh EgRtEEuxVNO/oNJ6BLXUqS3FUg2CBluWCrr/ZTuseKa4CEud2lIs1dgUVJ5N QtA+sRRLNTYFzdy7CEG7xFIs1ZgUNHf3P4OC5oqx1KktxVKNAUGTiZfw3Ki3 ai1Y5/3dbguCXoilWKoxKKgbJB0RtFssxVKNQUFl1xC0WyzFUksHftYLKsqI oN1iKZZabAqaOQ+6GiyCNoulWGoxKqh8HhRB+8RSLLVYFVTMhKB9YimWWp4j qLTbmxaCoA1iKZZaEDTcdPP1cMHDDhC0Gkux1IKg4aYI2iCWYqkFQcNNEbRB LMVSiy1BNwxE0D6xFEstPQi6OULqCbr9ciDo9ViKpRYEDbZF0BaxFEstCBps i6AtYimWWhA02BZBW8RSLLUgaLAtgraIpVgq6cLP7dMoRdf3NCao1kuPoJZ5 lKDrwSJos1iKpZInCboVrNvOMiDoHViKpRIEDVcjaItYiqWSzgTNNRdBEyx1 akuxVPIkQYV75SaFlAp64HVD0GosxVLJgwSV7pWbFIKgLWIplkqeI6ib/l+t BUFbxFIslTxGUDdsGoigrWIplkoeI2iBWJ0KminIUqe2FEslzxF02z8EvQyv ceMbMSFmfxoPEnRrjug5go4TXjJYt504hlfO6Dc2SPj5dartkScJqnketG9B hZSkSJE8O/Ct9x/HaOEQ53og3zf3D0zgv7OlguYVKZNnF7Gg45gkxOyP4+fn za3YRGkELajleSNoXpEyeXYRCTr6HwIjI+gCgkaFPFVQSZEyeXYRCjr6o/Qo NP3hgjbvpy1Bp21vnyTy8omKlMmzi0DQ6V+YEBr8j/89DPfv39/djdjGJU8y ObLrC2sp2N4drkijrUJ5X5a+XGhJXpEyeXbhC5r5MBCzP43P5ePtD6DbI6jK qLRxJWBQU9cjaJClcvBUF9SbHQ4SYvaH8bl8vAM/EbSkvIhyQXOKlMmzi0XQ YEd7jNYm2Z/Fp0P+9XAmFEELyosoFjSrSJk8uxjjJ2OSELM/is+cyF8f1yps TgKpdPqtS428OroWNG9FYeIwY/RsFBJi9kfhPoL24CeCFpQXsdap81YUJo5R fTnhQwV97+D24WepoAeDeYyguy6/VbwWt5anCvpvAO3DTwQtKC/CUqe2FEsd PUzhvkHQ7fIiLHVqS7HUgaBhIQjaJJZiqaKLk6BvEHS7vAhLndpSLFUgaFQI gjaJpViqQNCoEARtEkuxVIGgUSEI2iSWYqkCQaNCSgU9ekmh93AcBDULgkaF IGiTWIqlCgSNCrlQUL1LRBDULL0JutKpDx8ZDgjaLJZiqaIXPxG0oMAIS53a UixVIGhUBoI2iaVYqkDQqAwEbRJLsVSBoGEZRdsj6OVYiqWGbuaILhK0bHsE vRxLsdSAoHI125kQ9FIsxVIDgsrVbGdC0EuxFEsNCCpXs50JQS/FUiw1IKhc zXYmBL0US7HUgKByNduZEPRSLMVSA4JGZRSdZ0HQy7EUSw0IGhVRdKUCgl6O pVhq6EfQ7U59XFA3/V/QFAS9FEux1ICgUQFF7iHo5ViKpQYErarCy4egl2Ip lgpcP9fiXiFosXlFO8Ib9SBoDZZiqQBBkzJKz7Mg6KVYiqUCU4Ie1marfL2a ELQWS7FUgKC724Kgl2IplgoQdHdbjh/sImgFlmKpAEF3twVBL8VSLBUg6N62 HJ6MGhC0BkuxVNDRaVAE3SwvxlKnthRLBQi6ty0Iei2WYqkAQfe2BUGvxVIs FSDo3rYg6LVYiqWcnuaIEHSzvBhLndpSLOUg6O62NCaoWJalTm0plnIQdHdb EPRaLMVSTn+CrvZpBA2x1KktxVIOgu5ui4Kgqm1FUIsg6O62IOi1WIqlHATd 3RYEvRZLsZSDoLvbgqDXYimWcowJetybUhD0aizFUg6C7gRBr8ZSLOUg6E4Q 9GosxVIOgu6kOUHFn6yw1KktxVLMv/e0I0ELOvVjBZV/ssJSp7YUSzEIur8p TQnq5BlsS53aUizFIOj+prQkqBvkAi11akuxFIOg+5vSkqCMoEZB0P1NaUpQ jkFtgqD7m9KWoMzimgRB9zelMUE5D2qRrk6DFgl6kZ/Ha0LQSizFUgyC7gZB L8ZSLMUg6G6OVoSglViKpRgE3Q2CXoylWErpbI4IQbcKjLHUqS3FUgqC7gdB L8ZSLIW8T50ZE/SqsywIejmWYinjc/EJgu4EQS/GUixFOIu7uAgaYKlTW4ql hF8H+busRyuAoBsFxljq1JZiKYIR9BAIejGWYinjPeNp7RhUvGT8lKYcrkj6 etjB8hIsdWpLsRTizF2oIH/p6pSWaFwtj6AVWIqlEGdtF9fpd/vzKkLQOizF UsbnHe1N0A0/9Q/tTqsIQeuwFEsZ5gT9rbxmBD1cEYLWYSmWMuwJes34qVQR gtZhKZYivm+oLUGvmiPSqAhBF8Y3YsLLc2WDWsCkoP2cB1X/LNklqGxFYUKN 0W9LkJCa+hQ6FPS6AfICWhB0li2vSJE8xwgaMUYLk1xP4fd+IuhdNCDoGIon KVImzzGkOtJxGkE7AEHXyktZ79RjNDL+rChM6CEIOjKC9riHi6Cr5aWsdupx iAQdBUXyCUXG+O8oNP1hgnY5gCLoeoEJa506GBN/f8aKhCbe3NPo/UvzfPjf E3Dfh797W1GLm9ptAPVYluKWvrzihPc3tKIwoUg0ggbHu1Gmx8AIejc3j6CB w5WD57nHoJmp4kcJOn9XCkFv4+5dXD9DYEVhQo9Q0GhiOcn1BJa+gaC30ZSg wbFoWUKPslM5DxLULUMogt5GU4L6ycKEIsnxsFTFcwT1v8yIoLfRkqArihTJ cxSuxfUIvsyIoLfRlKD3XotbxGMEZQRtgyYE7QhLsWzg3VAHQW8DQeuwFMsW jtMs94OgdViKZZP5vUTQ20DQOizFsgmC3g+C1mEplk0Q9H4QtA5LsWyCoPeD oHVYimUTBL0fBK3DUixbLG8lgt4GgtZhKZYtELQBELQOS7FsgaANgKB1WIpl CwRtAAStw1IsWyBoAyBoHZZi2aJfQe34iaCVWIpli17Pslz4yw7ng6B1WIpl CwRtAAStw1IsWyBoAyBoHZZi2QJBGwBB67AUyxYI2gLaM14IagYEbQEErcJS LFsgaAtox4KgZkDQFkDQKizFsgWCtgCCVmEpli0QtAUQtIomY3mdUmq3V/p5 tyM0AIJW0WQsCBrg9E8e3giCVtFkLAjq498S3wAIWkWTsSCoR/CjMgZA0Cqa i+U1oV5yp4L+2m3FTwSto8lYGEEDLI2fCFpJk7GcMHwOHQtqao4IQetoMhYE jTDkJ4LW0WQsCGoYBK2ixVhe5xyEImgLqF90gaCX8zpnmghBG0D/ogsEvRwE NcsJF10g6OWcLSh+3sUZF10g6OW8hlMMRdD7OeGiCwS9HAS1i/5FFwh6OQhq GO7qV0eLsbzmP5owR9QGnAetosVYvoJqG4qgNkHQq/maiaBQBIJeDYJCBQh6 Na/gQQ0EtQmCXs3rnG9tI6hNEPRqGEGhhtTQBjv1bhqMBUGhBgS9GASFGhD0 YhAUakDQi0FQqAFBL+YVPSqBoEZB0Gt5JU904Fp5oyDotSAoVIGg14KgUAWC XguCQhUIei0IClUg6LWcJCiTuFZB0GtBUKgCQa8FQaEKBL0WBIUqEPRSXsIz DZgjsgqCXgqCQh0Ieikv8elxENQqCHopCAp1IOhlRLciQlAoAEEvhREU6kDQ S0FQqANBLwVBoQ4EvRQEhToQ9FIQFOpA0Es5W1D8tAaCXgqCQh0IeiknCcoe rlkQ9FIQFOroWNDxH/5zoeHNxfLKPD8IgpqlUtAxa0VhQo9x/jM9pJUgKHRO naCBCHsSeozC86SS1gR9ZRPHQFCzVAkaiLAnoccoJNJxGkGhc3YdgwZ7lzUJ PQRBR0ZQBDXHUUHHqoQeqaAju7j4aY89gnpHlaNv63ZCj3H05p5G75+U6x// a4JXNnEM93v80ysS2mB6a/+39OVNMQQrChN6xDNQwfFunKsZGEGhkkMjaM3g edIu7q/szFQxgkLnHDkGHasTeoSCjuHCJFcryIIeNxVBzXJA0LE+oUfZqRwE hc7p9TxoOC7nBun2BX35T3aDoGbp9kqiossJmxZ0lhNBIUu/1+KW0IGg0c04 94GgZun42ywFtBaLKOi/x8+f/eCnXRD0SiJBE3YWi6B2QdArSQTVOQZFULsg 6JV4P27mDZpfQQ8YiqB2QdArkWdxvwkEBQEEvZI1QX9PE09f0sIA537vIoLa A0GvJBU0SIoubgrqPv+9QVB7IOiVrAo6zAekwTVGW4K66X8EtQiCXsn6ruou QZ33D0HtgaBXsjERFJwPDa8zyp8kZQQ1DYJeyYqgvom+oL/HlUIdfhoGQS9k 60xKMmjOZ0o3Z4neIKhFEkMb69SHaCyWIkEH8Rh0awh9g6AWQdDrOCBo5Kj/ 3E1L/lR/MA3aAEGvo0TQ+TGavX3Fxs5PENQ0CHodpQJJgoYnYbwcbk4gqEUQ 9DoOCYSgzwRBr2O/QOGUbvBNGDckk75wFtsXRquDoNdx7K1NT8AsJ05f3xEU O0+m5NpLZRD0Og4KOki7uIulf4e+smYatdcFQXVpLJYzBHVz4u8z03th1ymv ajvnK3myryZ5u4rtNy6XHqLXX52k0GRBY536EI3Fcoagg7KgwfiQTQQdVDpt G65NpqXlTYb4iThg5c4Ub1UXb7L+ggqvcHykX7u91KAg7Oz2AY116kM0Fsvx j1yxL/4WfC4kKtjLzefI9/Z47RFBKwU7KqjWgqX0+HY1lYImr9D6a4ig13Fc 0Ii/D6/vQyRotjL503t6Yk/QfT6tCPr598pfOYKgxTQWi7agf9EMQrIDVtaK PYLGvX5F0G1BpO8HpGuTFm4I6s1xf7Yu8GktqPA1kII6LmhSvx/7RGOd+hCN xaIs6N9ynbxQx7agr2RBJTs2WStraoNU6M4Wfk9BvSM82j7pA0KjxO1y4vev sU59iMZi0RX0b/mmtl9Hol24Nupt86O/ZmUEzW8/xN03LmN1OBQ+JPy1S2Gv lUE7X51UaMmQKpW+HvLGCJpp0MasU0BjnfoQjcWiKuj7kHO614lfR+xBUmmg sGzMyy/Lb31WwVJBVxesZPdatGv74wuWUFdfkA1BgwVzMK+N7QMa69SHaCwW TUH//Hud+HXMXfklv8GvUFBvwTK+BAuStYPXwYZhWOlcQ7xgt6DDK/3UKd9+ ELPfLuiw3C8DQVtAUdDv+OmEO2L8annNb3+8+uV39t9PN01rqgRdahoynct/ PCLo8O3NJbdVO1L/6mdKWJhUaL2g0Y/bZesPaKxTH6Kx2bXzjAAADrRJREFU WPQE/d48waVzRMP81vr92av95X1wv/zk4F/k8Er+Sp30FaWFdghr5fxJ50wy rF6Gsa7QSr1FaJQhFJabBpKzTzTWqQ/RWCz6gsrVfMWLZwK/Xf/1yzEPpN9P 8qjz+x/osaBRrmpB13KvZJ/32dc213yNLyk9+3mU1j3RWKc+RGOxqL29v7sP yX56vzb6HSj9/aWfNfFU0rKf6zU1cEZq+3WCbg42CNolbcWiPYDmBQ33F1+h oMk5h3Abf0uv3fcKul3SqyjXThD0JNqK5SpBoxMpvpJJN37FmyzLwzwIekrp 2wUi6GVcImh62Jk5N+61SdqB9FJZQVfWDDcJeoqfZ5deUvVCW536GG3Fon0I mh9BxQXJXqv8ZEqHgsptX91BQ1DNqhfa6tTHaCuWFgXNbtOeoOduf2fpJVUv tNWpj9FWLA0JWrrN/BRBTyy9pOqFtjr1MdqKRevt3fJzRbZCQaODUgRF0HNo K5bLBFUhGEEzTd8elMtjrvM5szmC9kVbsfQraO4CAQQ9HwS9DHuC5sfWqQQE Vap6oa1OfYy2YlF6e+dfGbxM0PytyBD0dBD0MvoS1GdlIkhX0P0vEYL2SFux 9Cno6nXqCHo6Lq60rU59jLZi0Xl7l9/RZgSNN0fQzmgrFmVBr/MTQRH0HNqK xaKga7cDuFTQo5NMJYUjqDZtxWJQ0PWYqn4pBkFlEPQyVN7eOw5BV0DQs0HQ y1he6b8DzIUYE7RyjzjTEgTtirZimV/pv7VcxdwuaMGNghD0MAh6GdMrrePn /YK+YQQ9GwS9jN8rreQnggotOcsgBD2HtmL5vtKm/HyKoOeOz6sg6FXo+omg UksQtC+aiuXzQqv52YigqyCoAgh6Fe8XWs9Pk4IeEQBBO6SpWF6qfvYgaF2H RlARBL2Kl6qfCCrVhaB90VQsL1U/EVSq61xB7/ATQa/iT/ft7cHPyh5dd8gq 1oWgfdFQLH/Kb2/zgpb9PG2wxbGX6OAs8HbhCKqOcizHrnF/mKBvrhxBEbRD dGM5eAyJoJu5ETRXtQeC5kDQWhBUq2oPBM1wxM/6A7ItEFSqDEH7QjOWwydJ HjiC1oGg+ao9EFQGQc8GQfNVeyCoyHE/Vd9eg34i6ErVHggqcfwqIATd4uAr hKD90ZSgCq1YsCjowZfo4KWCm4UjaD1zW8c3K+uPonAZLYJugqDZqj1WO3Ug wp6EKnOxo/c3yKBVE4JeAYJmq/ZY69SBCHsSqoxhFUIlWrVqfA8FQTdpWNBz j3A3a/ZZ6dSBCHsSqozRZ8CQjtMNCar85iKotPXTBQ2yBFYUJjQZhyEepJ8j qDMn6PFrrRA0zBJYUZhQJLD/9+cxgjp7gr45+BodPI+6VXg/gnpHlaNvynZC j+Qw1xtQvVwz/zvC36Gtv7wUyphwn//scfA1eqm+yEnhuu9hXc3/WPryqhdL hsCKwoQeQWuDD4Mgl05ljc0Ruel/azCC5mr22Z7FnZ/XDJ6nnGiZPysyU8Xt CKrr5/zPFgiaq9mnYBb3lwh2dYsS2kQzUCcJ2tgAancEPQiChoIGMzRlCW2i sh8i6GcOFz8TEHSUEhunPrPyaBAWnlZhVNB/duJnCoKOQmqsSigzl3rqtbgN CoqfAggaTfTefi3uJirVtucn46cIgnaHUUHxU+RsQe/xM7nvJoJGIGgnIGh3 IOiTQNDu0IhFxU9ud3IBCNodCPokdF/luHAEPYFmBFUoYwFBZRC0OxRiUflR TwbQS0DQ3mhBUPVffUDQHAjaGy0IOnAIehWnGnTqFNQaCLqKxi8+IOg1IGhv HI9F44bVqm8tl+HmQdDe+O+/Iz+K/ftl7IO8VI9e+B7LCgjaG+M/RQG6J+zU drg7Fu0ZXO6lkEX/J5LjChhB9WkhFu5GdBns4vZGA7Fojp6/++HiZwYE7Y0G YtES9DM7hJ+rIGhvNBCLkqDf8ZNZ3FUQtDfuj0Vt/GT/9mYQ9ATuj0Vx/Byw 804Q9ATujkVxhgg/bwZBT+DuWHQEZfxsAQQ9gbtjURHUzf/BjSDoCdwdi46f jJ8tgKAncGcsSteefd3EzttB0BO4O5bjbynjZysg6AncHYvCW8r18Y1w6i3J 1kDQ89CbI4K7QdATuDkWrbMs+NkCCKrP3YKqlMJNTtoAQfWxIahKKXAUBNUH QUENBNXHgqD42Qh3CRpXjKBqIKglEFSfe2NhD9cUCKoPgoIaCKoPgoIaCKqP AUHxsxUQVB8EBRVOvy32auVhEkG1QFBTMILqc2ssHILaAkH16V9Q/GwGBNUH QUGN2wSNrvVDUCUQFFRA0HNAUFABQU9B6Zab8HgQ9BQYQEEHBD0FBAUdEPQU EBR0QFB11K4MQ1BA0FNgjgiUQNAzQFBQAkG1eSn9UAA33IQBQXV5DT87NX6X BUEBQXX5CKoyOcRvPsAHBNVERdCfm/xqEgwIqovGGZbf7w06fncQBgTVQ/E3 e//Z6ebn8GgQVJHXd5KoHhc8c47f7YUfCKrFa5egv5HSN5Q5IlhAUC1ev9Of VYJO00G+oYyfsICgGkyzt7W7t9MO7eD56Bg7YQFBNdh5emWaEPJnbDm7Aj4I qsG+Gdzv+Om++7TOWwgwgaAavNXcMXvrln3c6bQKfkIAgh7lyPlPN10x5L6H nlwgDxEIqsD+859uHjqXy4cAFhBUgQMXKIQnQJnAhQgEPc7ur3+66DmnPyEG QQ9y5PvZLk3gJwQg6EEO3D3BpUn8hBAEPcjeb68Ih5scgUICgh6kXtDp+vjU RvyEGAQ9wK5ToPPtEtARtulU0PGNmPDynFa795pVD6DetUMYCpvUCeqtzitS Is9BRr81QSLJdAav5V+toNL18QBZqgT1VMsrUiTPMUb/cYwWJrn0WQTdmsMN zp1MX/R03NEESqkR1B8Y/cfChD5+Hek4fYGgW18BXW6PMD38hk7GTyhj5y5u YEVhQh+vjvGqEdSfGNrav13s9AbPKYWfUMAhQUdBkXxCHW//ebx2F9cnn83f v/0NnM4bTwG2OSLo6I9h2wlNvLmn0fuX5vnwP11er/ef37887v0v4LvQKTcH LOM+nWzpyxte+E9mKwoTiozh8zFelmRS5eXN4q7h3x4+vvMQQBH7R9CawVPZ lTFMZKaKzxL0NRQKOix7tNypD/axW9DgALAooUco6CgsPKHSmdf8d/McaDqL C1DFXkF9KwoTeoxS4hpB6768Eu7Y4idU48IOV3ma5abzoKOQSqu4X1CMhKPs FDS0ojChRjSldeW1uFWX9iEoHMaVC7rn8ttzrsUtAkHBABWCdoZ6LLXfLsNP OA6CVsEACteCoDWwhwsXg6A11AiKn6AAgtaAoHAxCFoBO7hwNQhaAYLC1SBo BQgKV/MgQYPr21/SmjmHsNb5iyX7gituuakm6PBEQUUfswu+T9y/V+r9JPhi SvjXW8U3V0AJBN1a4P7JOd8jbLrtdHC/Ie+XyeYFDKGgAoJuLHh/ncC5n6Dz LfliO+P7JvBr9qDDQwR9iWRXyGvdctvp6d62s5kxA4aCBg8RdJriWXFx8EfQ SEznP4889W1ND00BDvEMQd/7oJ9DSP+g0k2zP0vi9/3Yec1779b5az+FBXu1 c/nhMSh+ggqPEPQjzOunn/t56LxpoCnxcdJb8x4wv1mnNd5tp+MZImZxQZ8n CPqR5fUdON00errZx8+TYZ6rHZY1n1y/Afc3tvq3nY5miLzK8BM0SL6CbFLQ z/Gn86Z4Xr+Dxs/0rPOOKufsw3fN19ZJttey1isZGeFMHjKCvl7h7KucEKZ9 7mg5wMwDBP3snr6Cc5Uu3EkV52CZ6YEGeISg3+NIaYonvDZInPYBuJEnCDof aQtTPOHVteK0D8B9hJ3QqqDTx5AwxRMmMBPawrigtbfKBGgL44K+mc5hAvQH ggI0jH1BXy+OKaFbEBSgYR4gKLOy0C9PEBQ/oVvMC8oACj2DoAANg6AADfMA QfET+sW6oAyg0DUICtAwCArQMAgK0DDGBcVP6BsEBWgY24J+buZ3d0MA9mNd UO78BV1jXFDHvfmga4wLOt9NE6BL7Arq3S8MQ6FX7ArKCAoGMC4ox6DQN8YF xU/oG9OCchoUese2oBx/QucgKEDDGBcUP6FvEBSgZYIujKAAbYGgAA1jWFD8 hP5BUICGQVCAhkFQgIaxLCh+QvcgKEDDIChAwyAoQMPYFRQ/wQAICtAwCArQ MAgK0DCGBb27BQDHQVCAhjEr6AtBwQBWBXUtHIK28Ho20IYGmtBvG4wK6pq4 VL6F17OBNjTQhH7bYFNQ18Yt/Vp4PRtoQwNN6LcN/Qs6vgkXeT+cdCstvJ4N tKGBJvTbhnJBBRFaYPT+zjCCzjTQhgaa0G8bigUVRbifMXr8wTHoRANtaKAJ /bahVNCMCLfza08ytjOL+6OBNjTQhG7b4IJfF9oWtLmd3GlgT9p19/HnmxZe rAba0EATem1D9PuZm4IKItzM+PuTtKuFhtKGVprQaRtc9AvUW4JKItzM6P0L VwB0jvP+fdkhws2My2cHgDGc93eDVkUY551vAHO4ofRsYasiTKN+a+0C0MCV ni1sVYRWT/8AqFB6trBZEdoc2AEuplkRNma3AJ4BIgAAAAAAAAAAAAAAAAAA 3E0LZ25baMObu9vQwMtw91vh1X13U9qghWufWmjDpwU3N6GBb0Ld/VZ4b8Hd TWmDFq4ebqEN3/pbkKOJJtzVFG/IvLspjdDSXZTuH79ubUFLb8GNQ2j0pIme eSMt3UXp/vELQaPH+1rQVM+8kYbuonS/nwh6/4FfKGgbPfNO2riL0v3zdbd3 zPkGbnc2Ybj/rQgEvb9n3k4Td1Fq4D0ouCPc6U0IHm5txP2vQiM9835auItS O29BEx9TLbwVTRyD3t8zG6CFuyi18xYg6O1tWARtoGc2wP3vSEtvAYLe3gbO g0Y0sB/Rzlvw8OO/FtrAlUQxd0/bNTFBM7Xk5uobeBHubUNQewsvBwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAQDn/B4vl715W9/02AAAAAElFTkSuQmCC --=====================_26722436==_ Content-Type: text/plain; name="ok.txt"; x-mac-type="42494E41"; x-mac-creator="74747874" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ok.txt" IyAgICAgICAgIHRpbWUgICBNQi9zIGF2Z19sZW4gbnNlbnQgYXZnX3dpbiBh ZHYvc2VudAogICAgICAgICAgIDAuMCAgICAxLjQgICAgIDE0NCAgIDk2MSAx Nzg5Ni4wICAgMC4zCiAgICAgICAgICAgMC4xICAgIDguMSAgICAgMTQ0ICA1 NjIwIDE3ODk2LjAgICAwLjEKICAgICAgICAgICAwLjIgICAxNC4yICAgICAy NzEgIDUyMzUgMTc4OTYuMCAgIDAuMwogICAgICAgICAgIDAuMyAgIDE0LjAg ICAgIDI3MiAgNTE1NiAxNzg5Ni4wICAgMC4zCiAgICAgICAgICAgMC40ICAg MTQuMSAgICAgMjcyICA1MTc4IDE3ODk2LjAgICAwLjIKICAgICAgICAgICAw LjUgICAxNC4wICAgICAyNzIgIDUxNDUgMTc4OTYuMCAgIDAuMwogICAgICAg ICAgIDAuNiAgIDE0LjEgICAgIDI3MiAgNTE5MSAxNzg5Ni4wICAgMC4yCiAg ICAgICAgICAgMC43ICAgMTQuMCAgICAgMjcyICA1MTMxIDE3ODk2LjAgICAw LjMKICAgICAgICAgICAwLjggICAxMy45ICAgICAyNzIgIDUxMDkgMTc4OTYu MCAgIDAuMgogICAgICAgICAgIDAuOSAgIDE0LjAgICAgIDI3MiAgNTE1OCAx Nzg5Ni4wICAgMC4yCiAgICAgICAgICAgMS4wICAgMTQuMiAgICAgMjcyICA1 MjA0IDE3ODk2LjAgICAwLjIKICAgICAgICAgICAxLjEgICAxNS4xICAgICAy NzIgIDU1MzIgMjA3NDMuMiAgIDAuMQogICAgICAgICAgIDEuMiAgIDE1LjMg ICAgIDI3MiAgNTYzMyAyMTc2MC4wICAgMC4xCiAgICAgICAgICAgMS4zICAg MTUuMiAgICAgMjcyICA1NTc1IDIxNzYwLjAgICAwLjEKICAgICAgICAgICAx LjQgICAxNS4zICAgICAyNzIgIDU2MzggMjE3NjAuMCAgIDAuMQogICAgICAg ICAgIDEuNSAgIDE1LjIgICAgIDI3MiAgNTYwNiAyMTc2MC4wICAgMC4xCiAg ICAgICAgICAgMS42ICAgMTUuMiAgICAgMjcyICA1NTk5IDIxNzYwLjAgICAw LjEKICAgICAgICAgICAxLjcgICAxNS40ICAgICAyNzIgIDU2NTQgMjE3NjAu MCAgIDAuMQogICAgICAgICAgIDEuOCAgIDE1LjMgICAgIDI3MiAgNTYxOCAy MTc2MC4wICAgMC4xCiAgICAgICAgICAgMS45ICAgMTUuMyAgICAgMjc2ICA1 NTM3IDIxNzYwLjAgICAwLjEKICAgICAgICAgICAyLjAgICAyMC4wICAgICA0 MDAgIDQ5ODggMjE3NjAuMCAgIDAuMgogICAgICAgICAgIDIuMSAgIDE5Ljgg ICAgIDM5OSAgNDk1NiAyMTc2MC4wICAgMC4yCiAgICAgICAgICAgMi4yICAg MjAuMCAgICAgNDI5ICA0NjY5IDIyMzgzLjcgICAwLjMKICAgICAgICAgICAy LjMgICAyMC45ICAgICA1MjggIDM5NTcgMjMyMzIuMCAgIDAuNQogICAgICAg ICAgIDIuNCAgIDIxLjAgICAgIDUyOCAgMzk3OCAyMzIzMi4wICAgMC41CiAg ICAgICAgICAgMi41ICAgMjMuOCAgICAgNjQ2ICAzNjczIDIzMjMyLjAgICAw LjYKICAgICAgICAgICAyLjYgICAyNC4wICAgICA2NTYgIDM2NjQgMjMyMzIu MCAgIDAuNQogICAgICAgICAgIDIuNyAgIDIyLjcgICAgIDc0MSAgMzA2NSAy MzIzMi4wICAgMC42CiAgICAgICAgICAgMi44ICAgMjUuMCAgICAgNzg0ICAz MTkxIDIzMjMyLjAgICAwLjcKICAgICAgICAgICAyLjkgICAyNS4zICAgICA4 MDMgIDMxNDQgMjMyMzIuMCAgIDAuNgogICAgICAgICAgIDMuMCAgIDMyLjQg ICAgMTA0MCAgMzExNyAyMzIzMi4wICAgMC42CiAgICAgICAgICAgMy4xICAg MzMuOSAgICAxMTY1ICAyOTEyIDIzMjMyLjAgICAwLjcKICAgICAgICAgICAz LjIgICAzNS4xICAgIDEyOTYgIDI3MDcgMjMyMzIuMCAgIDAuNwogICAgICAg ICAgIDMuMyAgIDM5LjYgICAgIDg3NiAgNDUxNiAyNTYzNy42ICAgMC4zCiAg ICAgICAgICAgMy40ICAgNTIuMCAgICAxMDQyICA0OTg1IDI2Mzg0LjAgICAw LjMKICAgICAgICAgICAzLjUgICA1Ni4zICAgIDExMzUgIDQ5NjAgMjYzODQu MCAgIDAuMwogICAgICAgICAgIDMuNiAgIDc4LjYgICAgMTY0OCAgNDc2OCAy NjM4NC4wICAgMC4zCiAgICAgICAgICAgMy43ICAgODMuNiAgICAxNzY4ICA0 NzMxIDMzODExLjIgICAwLjQKICAgICAgICAgICAzLjggICA5OS4xICAgIDIx NjUgIDQ1NzYgNDkzNTEuNCAgIDAuNAogICAgICAgICAgIDMuOSAgMTIxLjkg ICAgNTQzMiAgMjI0NCA1MDQzMi4wICAgMC41CiAgICAgICAgICAgNC4wICAx MjMuNyAgICA4NjE3ICAxNDM1IDUwNDMyLjAgICAwLjYKICAgICAgICAgICA0 LjEgIDEyMS40ICAgIDg0OTkgIDE0MjggNTA0MzIuMCAgIDAuNgogICAgICAg ICAgIDQuMiAgMTE3LjUgICAgODI2NyAgMTQyMSA1MDQzMi4wICAgMC41CiAg ICAgICAgICAgNC4zICAxMTYuMyAgICA4MTU1ICAxNDI2IDUwNDMyLjAgICAw LjUKICAgICAgICAgICA0LjQgIDEyMy40ICAgIDg5MDkgIDEzODUgNTA0MzIu MCAgIDAuNQogICAgICAgICAgIDQuNSAgMTIyLjUgICAgODg5NSAgMTM3NyA1 MDQzMi4wICAgMC41CiAgICAgICAgICAgNC42ICAxMjIuNSAgICA4ODk1ICAx Mzc3IDUwNDMyLjAgICAwLjUKICAgICAgICAgICA0LjcgIDEyMy44ICAgIDg5 NDggIDEzODMgNTA0MzIuMCAgIDAuNQogICAgICAgICAgIDQuOCAgMTIyLjIg ICAgODk0MSAgMTM2NyA1MDQzMi4wICAgMC41CiAgICAgICAgICAgNC45ICAx MjMuOCAgICA4OTQ4ICAxMzgzIDUwNDMyLjAgICAwLjUKICAgICAgICAgICA1 LjAgIDEyMy43ICAgIDg5NDggIDEzODIgNTA0MzIuMCAgIDAuNQogICAgICAg ICAgIDUuMSAgMTIxLjcgICAgODkyNSAgMTM2MyA1MDQzMi4wICAgMC41CiAg ICAgICAgICAgNS4yICAxMjMuOCAgICA4OTQ4ICAxMzgzIDUwNDMyLjAgICAw LjUKICAgICAgICAgICA1LjMgIDEyMS4wICAgIDg5MjkgIDEzNTUgNTA0MzIu MCAgIDAuNQogICAgICAgICAgIDUuNCAgMTIzLjggICAgODk0OCAgMTM4MyA1 MDQzMi4wICAgMC41CiAgICAgICAgICAgNS41ICAxMjAuNCAgICA4OTI1ICAx MzQ5IDUwNDMyLjAgICAwLjUKICAgICAgICAgICA1LjYgIDExOC4yICAgIDg5 MDkgIDEzMjcgNTA0MzIuMCAgIDAuNQogICAgICAgICAgIDUuNyAgMTEzLjUg ICAgODkxMyAgMTI3MyA1MDQzMi4wICAgMC41CiAgICAgICAgICAgNS44ICAx MTQuNyAgICA4OTI3ICAxMjg1IDUwNDMyLjAgICAwLjUKICAgICAgICAgICA1 LjkgIDExMi45ICAgIDg4ODYgIDEyNzEgNTA0MzIuMCAgIDAuNQogICAgICAg ICAgIDYuMCAgMTEzLjMgICAgODg4OCAgMTI3NSA1MDQzMi4wICAgMC41CiAg ICAgICAgICAgNi4xICAxMTUuNSAgICA4OTM4ICAxMjkyIDUwNDMyLjAgICAw LjUKICAgICAgICAgICA2LjIgIDExOC40ICAgIDg4ODYgIDEzMzIgNTA0MzIu MCAgIDAuNQogICAgICAgICAgIDYuMyAgMTE0LjIgICAgODkwMSAgMTI4MyA1 MDQzMi4wICAgMC41CiAgICAgICAgICAgNi40ICAgNzIuMiAgICA4ODk5ICAg ODExIDUwNDMyLjAgICAwLjUKICAgICAgICAgICA2LjUgIDExMy41ICAgIDg5 MzggIDEyNzAgNTA0MzIuMCAgIDAuNQogICAgICAgICAgIDYuNiAgMTE5Ljcg ICAgODkwOSAgMTM0NCA1MDQzMi4wICAgMC41CiAgICAgICAgICAgNi43ICAx MjEuNSAgICA4OTI2ICAxMzYxIDUwNDMyLjAgICAwLjUKICAgICAgICAgICA2 LjggIDEwOS44ICAgIDg5MzAgIDEyMjkgNTA0MzIuMCAgIDAuNQogICAgICAg ICAgIDYuOSAgIDgyLjQgICAgODkwMyAgIDkyNiA1MDQzMi4wICAgMC41CiAg ICAgICAgICAgNy4wICAxMjEuOCAgICA4OTQwICAxMzYyIDUwNDMyLjAgICAw LjUKICAgICAgICAgICA3LjEgIDEwNy42ICAgIDg5MjggIDEyMDUgNTA0MzIu MCAgIDAuNQogICAgICAgICAgIDcuMiAgMTIyLjIgICAgODkyOSAgMTM2OSA1 MDQzMi4wICAgMC41CiAgICAgICAgICAgNy4zICAxMjIuMCAgICA4OTI5ICAx MzY2IDUwNDMyLjAgICAwLjUKICAgICAgICAgICA3LjQgIDEwMi4xICAgIDg5 MzYgIDExNDIgNTA0MzIuMCAgIDAuNQogICAgICAgICAgIDcuNSAgMTIyLjEg ICAgODkzNSAgMTM2NiA1MDQzMi4wICAgMC41CiAgICAgICAgICAgNy42ICAx MjIuMCAgICA4OTM1ICAxMzY1IDUwNDMyLjAgICAwLjUKICAgICAgICAgICA3 LjcgIDExNi43ICAgIDg5MzggIDEzMDYgNTA0MzIuMCAgIDAuNQogICAgICAg ICAgIDcuOCAgMTIyLjYgICAgODk0MSAgMTM3MSA1MDQzMi4wICAgMC41CiAg ICAgICAgICAgNy45ICAgOTIuOCAgICA4OTI3ICAxMDQwIDUwNDMyLjAgICAw LjUKICAgICAgICAgICA4LjAgIDEyMi4yICAgIDg5NDEgIDEzNjcgNTA0MzIu MCAgIDAuNQogICAgICAgICAgIDguMSAgMTIyLjcgICAgODk0MSAgMTM3MiA1 MDQzMi4wICAgMC41CiAgICAgICAgICAgOC4yICAxMjAuMCAgICA4OTM1ICAx MzQzIDUwNDMyLjAgICAwLjUKICAgICAgICAgICA4LjMgIDEyMi41ICAgIDg5 NDEgIDEzNzAgNTA0MzIuMCAgIDAuNQogICAgICAgICAgIDguNCAgMTIyLjkg ICAgODkzNSAgMTM3NSA1MDQzMi4wICAgMC41CiAgICAgICAgICAgOC41ICAg ODIuNCAgICA4OTI5ICAgOTIzIDUwNDMyLjAgICAwLjUKICAgICAgICAgICA4 LjYgIDEyMy4yICAgIDg5NDEgIDEzNzggNTA0MzIuMCAgIDAuNQogICAgICAg ICAgIDguNyAgMTIyLjEgICAgODk0MSAgMTM2NiA1MDQzMi4wICAgMC41CiAg ICAgICAgICAgOC44ICAxMjIuOSAgICA4OTQxICAxMzc0IDUwNDMyLjAgICAw LjUKICAgICAgICAgICA4LjkgIDEyMi4wICAgIDg5NDEgIDEzNjQgNTA0MzIu MCAgIDAuNQogICAgICAgICAgIDkuMCAgMTIzLjMgICAgODk0MSAgMTM3OSA1 MDQzMi4wICAgMC41CiAgICAgICAgICAgOS4xICAxMjIuNiAgICA4OTQxICAx MzcxIDUwNDMyLjAgICAwLjUKICAgICAgICAgICA5LjIgIDEyMy4xICAgIDg5 NDEgIDEzNzcgNTA0MzIuMCAgIDAuNQogICAgICAgICAgIDkuMyAgMTIzLjIg ICAgODk0MSAgMTM3OCA1MDQzMi4wICAgMC41CiAgICAgICAgICAgOS40ICAx MjEuOCAgICA4OTQ2ICAxMzYxIDUwNDMyLjAgICAwLjUKICAgICAgICAgICA5 LjUgICA3MC4zICAgIDg5MTcgICA3ODggNTA0MzIuMCAgIDAuNQogICAgICAg ICAgIDkuNiAgMTIyLjkgICAgODk0NyAgMTM3NCA1MDQzMi4wICAgMC41CiAg ICAgICAgICAgOS43ICAxMjMuMiAgICA4OTQ4ICAxMzc3IDUwNDMyLjAgICAw LjUKICAgICAgICAgICA5LjggIDEyMi41ICAgIDg5NDEgIDEzNzAgNTA0MzIu MCAgIDAuNQogICAgICAgICAgIDkuOSAgMTIyLjkgICAgODk0NyAgMTM3MyA1 MDQzMi4wICAgMC41CiAgICAgICAgICAxMC4wICAxMjIuNSAgICA4OTQxICAx MzcwIDUwNDMyLjAgICAwLjUKICAgICAgICAgIDEwLjEgIDEyMy41ICAgIDg5 NDggIDEzODAgNTA0MzIuMCAgIDAuNQogICAgICAgICAgMTAuMiAgMTIzLjIg ICAgODk0NyAgMTM3NyA1MDQzMi4wICAgMC41CiAgICAgICAgICAxMC4zICAx MjIuNSAgICA4OTQxICAxMzcwIDUwNDMyLjAgICAwLjUKICAgICAgICAgIDEw LjQgIDEyMy4zICAgIDg5NDcgIDEzNzggNTA0MzIuMCAgIDAuNQogICAgICAg ICAgMTAuNSAgMTIzLjMgICAgODk0OCAgMTM3OCA1MDQzMi4wICAgMC41CiAg ICAgICAgICAxMC42ICAxMjMuMiAgICA4OTQ3ICAxMzc3IDUwNDMyLjAgICAw LjUKICAgICAgICAgIDEwLjcgICA4Ni42ICAgIDg5NDUgICA5NjggNTA0MzIu MCAgIDAuNQogICAgICAgICAgMTAuOCAgICAwLjAgICAgICAgMCAgICAgMyA1 MDQzMi4wICAgMC4zCiMgdG90IHNlbnQ6IDI3MTYzMCAsIHRvdF9yZWN2ZDog MTAwNjQzLCB0b3Rfb3RoZXJzOiAwCg== --=====================_26722436==_-- From Hakon.Bugge@scali.com Tue Jan 21 07:43:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Jan 2003 07:43:14 -0800 (PST) Received: from elin.scali.no (IDENT:root@elin.scali.no [62.70.89.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0LFh43v028935 for ; Tue, 21 Jan 2003 07:43:05 -0800 Received: from pc-15.scali.com (pc-15.office.scali.no [172.16.0.115]) by elin.scali.no (8.12.3/8.12.3) with ESMTP id h0LFnY9N017935; Tue, 21 Jan 2003 16:49:35 +0100 Message-Id: <5.2.0.9.0.20030121174648.029028c0@mail.scali.no> X-Sender: hob@mail.scali.no X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 21 Jan 2003 17:48:32 +0100 To: linux-net@vger.kernel.org, netdev@oss.sgi.com From: =?iso-8859-1?Q?H=E5kon?= Bugge Subject: non-growing tcp window size Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_26925641==_" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-archive-position: 1600 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Hakon.Bugge@scali.com Precedence: bulk X-list: netdev --=====================_26925641==_ Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable To whom it might concern, We have observed bandwidth problems of TCP when running benchmarks which=20 gradually increase its payload and having (most of its) data flowing=20 unidirectional. The degradation is observed between two dual XEON/E7500=20 machines, using Gbe and a cross-over cable. The Gbe is eth1 and has an MTU= =20 of 9000. eth0 is a FE with an MTU of 1500. The machines is running linux=20 2.4.20, and the NIC in question is an Intel Corp. 82544GC Gigabit Ethernet= =20 Controller (rev 02). During an attempt to change TCP parameter settings, and also systematically= =20 changing socket rx/tx buffer sizes, I discovered that once in a while, the= =20 benchmark ran well. The OK run was not deterministic, and had nothing to do= =20 with change of the parameter settings. Hence, I let the machine work during= =20 the week-end, and took tcpdumps which I saved for the successful run. An=20 analysis of the "OK" run vs. the "BAD" run, discovers a couple of=20 interesting things. The problem is that the advertised window of the=20 receiver does not increase. The second problem, which also affects the "OK"= =20 run, is that the ratio of packets sent (from src to dst) and the number of= =20 packets received (#advertisements) is 1 for the "BAD" scenario (actually=20 this is probably a consequence of the window being only ~2xMTU size).=20 Surprisingly, it is as large as 0.5 for the "OK" scenario. IMHO, this=20 violates RFC813, which states: There are two reasons for prompt acknowledgement. One is to prevent retransmission. We will discuss later how to determine whether unnecessary retransmission is occurring. The other reason one acknowledges promptly is to permit further data to be sent. However, the previous section makes quite clear that it is not always desirable to send a little bit of data, even though the receiver may have room for it. Therefore, one can state a general rule that under normal operation, the receiver of data need not, and for efficiency reasons should not, acknowledge the data unless either the acknowledgement is intended to produce an increased useable window, is necessary in order to prevent retransmission or is being sent as part of a reverse direction segment being sent for some other reason. We will consider an algorithm to achieve these goals. The two tcpdumps has been analyzed by a simple awk scripts, which gives=20 information for every 1/10 of a second of the runtime: time: elapsed time relative to the first packet MB/s: sum of TCP payload (based on TCP sequence numbers) *1e-6 / delta time avg_len: average packet length (TCP payload) sent nsent: no of packets sent from src to dst avg_win: average window size advertised by the src adv/sent: ratio between #advertisements (sum of prompt acks and piggybacked= =20 acks) and #packets sent The extract of the analysis is enclosed as "ok.txt" and "bad.txt". Also,=20 the information is presented as graphs in "bw_winsiz.png" and=20 "bw_adv-sent.png". In the graphs, the "OK" data uses the bottom x-axis, the= =20 "BAD" data uses the upper x-axis (the "BAD" run-time is longer due to the= =20 lower bandwidth). Bandwidth uses the left y-axes, whereas the average=20 advertised window size and the ratio of the #advertisements and #packets=20 sent uses the rightmost x-axis. I do hope this information is useful 4u and that the problem can be fixed.= =20 Since I do not read the mailing lists, I would appreciate a note back by=20 email of someone triggers on this. Cheers, H=E5kon -- H=E5kon Bugge; VP Product Development; Scali AS; mailto:hob@scali.no; http://www.scali.com; fax: +47 22 62 89 51; Voice: +47 22 62 89 50; Cellular (Europe+US): +47 924 84 514; Visiting Addr: Olaf Helsets vei 6, Bogerud, N-0621 Oslo, Norway; Mail Addr: Scali AS, Postboks 150, Oppsal, N-0619 Oslo, Norway; --=====================_26925641==_ Content-Type: image/png; name="bw_adv-sent.png"; x-mac-type="504E4766"; x-mac-creator="6D646F73" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bw_adv-sent.png" iVBORw0KGgoAAAANSUhEUgAAA6AAAAK4CAMAAABd6WDBAAAAA3NCSVQICAjb 4U/gAAABKVBMVEX///8AAAAAAAD/AAAAwAAAgP/AAP/A/0DAQABA/4AgIMCA AMAAYIAAgAAAgEAAgIAAwGAAwMAA/wAggCAwYIBAQEBAgAAAAICAYACAYBCA YGCAYIAAAMAAAP8AYABAwIBgoMBgwABgwKCAAACAAIBgIIBgYGAA//8gICAg QEAgQIBggCBggGBggICAgECAgICgoKCg0ODAICDAYACAwODAYMDAgADAgGD/ QAD/QECAwP//gGD/gIDAoADAwMDA/8D/AAD/AP//gKD/gP/AwKD/YGD/gAD/ oACA4OCg4OCg/yDAAADAAMCgICCgIP+AIACAICCAQACAQCCAQICAYMCAYP+A gACggP/AYIDAwAD/gED/oED/oGD/oHD/wCD/wMD//wD//4D//8BTi7KnAAAA O3RFWHRTb2Z0d2FyZQBnbnVwbG90IHZlcnNpb24gMy43IHBhdGNobGV2ZWwg MiBvbiBMaW51eCAyLjQuMy0xMrFi8REAACAASURBVHic7Z2LoqIgEEB1yf7/ k/f2UHkMCAo62Dm7t1JxnIoTiGbDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AHAHxhcdxf0EbxK0oxfCClg1/glxhclKgVvWuMsYrdse4n7CNhFpuakftnZc 6wWoGv+EuMJkpcCN3sBrGb177XG/QRuEbfVZ0iK81VJUjX9C3E/MWq/GGHyi 3I3vs2rWNWjU1LVq6OrT6JPKF6nWGxiEaRC36vsXfKLcjLkj05GgY5OwfQta 7Q08QdC6799PCNqkSVrDNwjZj6CNdsbdelnvDfTDVOuLuo8QNJdxqP2RtkRu M6bWbFBr7Go426mXFd/A5qO4td+/NXCzN/BSxuofaWvgJoxjm3didO6qB27Z gtZ8A1uNufgeVXv/gp3xSnG1MLauQG1o18XtZDjbqpdV38BWPcYxOVkjcNPj BtcxNvrgQdC2ca0WqWp8BFVG63rZCARtFB9BtdFo0KU7QduNPjWJ6+8rttql q0V7QZu9gVfTZuyr1VjOHL5FzH5GcZ2QFeNboaq+gUGgap8njV4IAAAAAAAA AAAAAAAAAADIJXbGBgdxATZICVLtVBB58q6nQQFUI9WCVWrdYhdnuuuJxADV SHUxK17mzH3sCkonFyBOVI+x4tnD7kNH0HaXBgO4ATE9xsSy/duwL4QxP0ZQ gCgRPcbEsv3bcIaFxiHyMTAC/BCZ8ghz6wtq5zTGPgZaNanFcXNXaJ2wmitL bK141jvXYnCkaoCSwPsEzbN7XwpLCxr5GEBQLy6CNtpOv4KWb6ZgG97wLYJu xUXQRttBUDHO1nFQBPXiImij7XQnqGzSYSJhYzu6COrFRdBG2+lNUH+fs9Ie qL8vO0aX1NxshbgIWrgigu4InCzrKdKoBS0EQb24CNpoO/oFVQmCenERtNF2 EHQXCOrFRdBG20HQXfSXMcBu+qvu/WUMsJv+qnt/GQPspr/qnszYvPg+HNx7 q1DZBjOLm/gDgL3cS1AT3EqW1BDUBHMRFBpwK0GdRtPRVCyWydmC4jWs3FxQ Wa6yDZ7cxTUYCiv3FlSu6sbeVfX2W4Uljulii7wW+zw2S+ttR8sjnjb8IjcW NNoUrf74q7pL7Hm+oJZ3xpthPYi34jHiHXP4SW4saLSai61hqGF8QnwgLImN U5lDRJ4V3JI7CxptQb17Z52cCfFBgaAJaEHB4daCRvdBnXurYaosqD8jB/ZB webegqZHccMdzrSgjjutBGUUF2xuLqg86hoWqy2o3OrmgZ+wcitBHSnjO4DS WK2klHFLG6dxi4/iLsV2Cgqwci9Bc8/FDY92igdT7AOcXvsZOVzqrh7NACCT mwkKcC/6q+79ZQywm/6qe38ZA+ymv+reX8YAu+mvuveXMcBu+qvu/WUMsJv+ qnt/GQPspr/q3l/GALvpr7rnZ/x48X04uPdba5aldEok+EluLOgjuM3WBUFB CfcV1Gk0HU3z1y1ZUqc8gMMvCZovS7RksW8ICof4IUFjrli7qvOE47O1nlvs EQZ4DMGCB47Cfn5F0MdGW+bspD4igj7k0sGa0ioAe/gVQTdNCZ0MBA0fFKzj rHKIjScCt+JnBN0ydFtQqau7tQ4tKBzjdwRN74MKvVpPtkewjrN6pFuMoHCI HxI0IsvDL7bcbx1CFY7dICjU5ZcEFW3ZajRTpziE2ouCIins5r6C5p5JJI3I rp7FxRSDSiO/+An7ubGguefiOoOj1nHQWPlllbzt4Ccc4M6CAnRPf9W9v4wB dtNfde8vY4Dd9Ffd+8sYYDf9Vff+MgbYTX/Vvb+MAXbTX3XvL2OA3fRX3fvL GGA3/VV3N+PpgzUjuiQskkdm8Sn+AGAvvQv61cCSYoos8dbIRywemo+g0ICb CLrIEAgqaKJcULyGlZsJOg2BIG0ETRRDUKjHbwrq7J1aE+ISp6cs7tOuxZw9 3+kzmfm8vCcE8OImglp++jIJggoLJmGJPc8X1PJu8mb4+8OlwiEorNxAUKuV yhTUu18nprwJ8YGwZPJmOCnvJng+cGNuIOhy47uiVtA0GAgrNxH0a5HbyGQK aq1TWVB/Rh4ICiv3EtSZlSmoXTgtqDACFW4UQaEmPy9owUSBoHKrmweCwspN BI3vgwrVXRqrlZSa3NLTEJ4FERSbiwrpAJTTu6DCTqe7QypEkI52igdT7AOc XvsZOVzqru5OtsIcKm+i8/bGh5r0LiiYQoPc8p8pad7e+OBz6PXrr7r3l3FT zJCoAcICt/xqpz8vK37nJJ6XuKi0/LzIhCWMdCfRX3XvL+OWSD1Ua2GwwC1v NuZtxO+cRN/AW2Skmdmh3n9it8S9E+mvuveXcUOM9RddGC3/fvTBnReZ6h/j Pfan5UUm8ToYobwf6vUqO3MXae07mf6qe38Zt8R8/4mL1ttIebvmmVgJ04Gf UoJi/954i420zP1wcl4fP6gZzGao+RPQ75a4d8IzeNFfde8v46aY5S0OF9gf 0YP4YR/ZB7UiGhOJrwnpI0ropdrPMzY9PzTzR9Wik/GaQaeo/Uq7Zn8WG6uE 1XExfgcmoL/q3l/GLTFDVKBvxXD2dMzaPs5ufu9jSporR3GzG8awVyn0Ut2m anl5rKJmLTw/8cUvt59hb2l20G9P5zDLzTpvmTl/FNCC3hD3M1labgbno9vt sRm3ZtoV1+uuXWWoNP4p9DW9GVKvc34N3DbTOA2l9zqZRavl4y3dfq7aGWum lc9SwttU8iXur7onMn5+sGZEl6TJLnhipAB3VzFWwv649veN/NKWp07gEwU1 3mPv48Jp+4NZ66Qn49zSuR9mlkeD0wguH1/GCeR+pg1zdlZjabXKa7M6v4bf ab9TMycS4VaCfn1YtbT8cJds0IOgTlWRW9F5fCfc0xHHlpy+rVO1qybubcGb Z7zlxn+eSynvyXsu2mbbbVnwCfB10G3brA1YgWxL13zNUsppT4XUrcDu52Di Bb6joIsVgaC5vsSLlQrXTFC/GZHHSYalmq1VbPCroBvSXjejAu0mlrDddvvj n848+8mHLprB+bSZ20lnm7ZVVhPnpuBsafBfNzuiK7SXo1tCeN4R7izoc3Ba 02E4Lmixb60E9RUTD4bYn/sJ/ZZ5Tuuw3YM+RPj54Gdlvkp5fVUz+DMdTcz6 3x3qSn4iea/RmoLwmnqGSvGMM7XxrOVZMwg6OHunnwmnPxzfpw0DPIdgQf6e bxFLRfxOxSv82gsz7iK5tlrKBx3eesTaF18Pf4xz3T102zE7itvrnAsETaHk kZ+W+JknrGFtOzYVn6ddUCuF8YU4IRYPsc3yu7v2lLziUioi6FMuHawprVId qS8mdajWB4m6tC526nQzQaMJe94Z93nO8z7NqD1z8Essm1kDS9sbNj+4wszd HIWI8lR83gFBY4sj8uzBijPa23QmMlJ647Rf1u12Fzd0MhA0fFCwTpDlbuYo 3u6PCd7ntFXSp7vUVC1TVTFip1waxRF2HP2EvOxM8DDyQZP3wZXOscrrslvQ mIQxeXZgN5n2/ejNHPxSIpYlnivHBZW6ulvrtDzM4lflYKy+uO7Ej100MFQe 1jKBnzGrcgXNbu9SMzdzPMZeQWOtZFSeXcgKzu3oDkG/rrgtzsY+qNCrFQ23 13FWj3SLzxJUMqi87gQtw+Kn0Nwdw5jgA8XLIC2oq11MUP9MxQxBt4lubDf1 u7hZK2eSEnTc04Im/BJ8sZdL/WHJz2jI6wSN7lQeie7uw1Uz1Mgt/nvRVgsq tYbdC5qIolBQq/887uriFgm61WjG/fTWCaN5IaqzIeTRqrM1BnUksJnDBsuk 7qPcpbSb0ngX1z+xQC5XRDeC1holsh6uY0+j9ecWX/j3h7dwYx9U7OHad85Y 7PuoiZTxU7pzotjDuC39/Gdj/qUmyzHOI3M8oB3sn5ygMV5Jv6AJH5lkEeMX FcqVUSVIIuSLtZanK8EJo7jWNkZ37ujPS6Y0eMcd3aYxcUTSXWs9DmoHEVdx puzyjpTNOrnyMGxq+bFtVWs/58b5YAsaNPDR0smF5XTQglY9ehqM4n4nIkPF Co7cbtFyx3PlTEEHI+8y7gm0/J0gaPBB8BuC1nUkIugozKy/8SZcJWiLqmNF KwoYLbwOOFUS1N+fTY6dIWg5sRY0si0E/XKuoN+IuUETx02XQzZHBbU7sFFB E92K2wkqm3SYSNhdZxLp4DJBE/W0ziZzz1dI7rM6Xz0Jt+AECcoVCxomllUw M4YmQddhoZqO2AO37sDVnnNxdXBfQTPjBmMz7lKpZZznFAuaHAeKZJZRMDPG tYJ6irinsVccxy0CQb/Igoq1utoW8wy1BoJii90H9iKTLhcZAvpNQVXSQcbX CTq4ZxfU32CuoYlzAwUD7Tl9CVrpVUbQU2n0FVCP2BhLfAevwhYzx4lM4rAM gqZDunRQ3T06yPgyQS2DWuyCvoNnBU6NJh0S1ESKnylogz19BD2VqwQ13l+L bebFTZ3XUC5ofJXlKzEIqoYOMr6yBZ0daiNobgOayCBZu4sFpQVVRwcZX7gP Os+vdGJe5mbFMtuChkUKBV13dRFUDR1kfIqg8nv6vdBW9QsgbG1XKhLLMBHL FlTUwB8jEna5EfRaOsj4QkHn6trOUD2CRna5EfRaOsj4SkE/i+pfoiRrw9+N pwr6TWC4VFg93oLOtwiqhg4yvlhQoVU5Z8OfpemLddYU1CqOoGroIOPrW9CN Aq02/OmjnifowCiuPjrI+GpBW7af6cifDaf6uHUFFQpvNfCJreeCoCk6yPhy QRuOEQ1bukQck+fEAnjLtvVDUDV0kPH1grb0c40tXenTuAWi68oFflXQeJwO qrtHBxkrEPSMTUsdaW/4eOtq99UETX0oxDaIoE3oIOPfEFQcivLOkg9/JDg5 uSlo/EkjqBY6yPgnBPX3N+dFjgLGW77RoK6RI+shqH46yPjugs6/8h6esBRM lfV4TxV0/wuIoCk6yPj+gr7F89tPyVZvzOhyQbNHk/JiIGhIBxm3+7kHiyu7 uGbuvdqjtuF3QL0WdJbaKxJMIqhFB9Xdo4OMzxD02l1Qs/zQtW2poJ97FTN/ lxRBN+N0UN09Osj43oL6PdfZUrEL6573Jw0qhZMIatFBdffoION7C+oJ9HXT alPDsvPDrRbUBLdeMQTVTwcZ31zQsP1cfi47yMofRErvgyJoQAfV3aODjO8u qCOaseaESbmahRdiQdCNOB1Ud48OMr69oF7DaO+HJgpuCjxPxXdVEVQ/HWR8 f0EdZjOllBC0OKRLB9Xdo4OMf0zQVC5bgoo9WQRd6aC6e3SQ8a8JmqCSoIk2 2o+DoBfTQcYIunC6oFuvC4K2poOMEXQBQYtDunRQ3T06yBhBFxC0OKRLB9Xd o4OMEXRFEnBrOYKudFDdPTrIGEFXNgU14XIEXemgunt0kDGCrgj+ucuNUN1j pwQqEbROkEhEjw6qu0cHGZ8gaC9+bgnqnp+LoAEdVHcP/Rk/v38tuYmgZv7v FtghqN09zstHlaDRQPqru4/+jBHUIimosf6GAUEF9Fd3H/0ZI6jFvVvQem8D gp4HglqctQ+KoFrQnzGCWlQaxZUOvYgbQtCr0Z8xglpsCSoWQNAF/dXdR3/G CGqhVtAjryCCJtCfMYJa7BJUHk5C0C7QnzGCWuxrQeWLF9UQNDikswcETaA/ YwS12CNo7PJ/CNoD+jNGUItNQe25y8EUExRG0F7QnzGCWpQIuh7sDHVE0F7Q nzGCWpQLannqlcoQdPt1QdDG6M/4BEG78XOPoKKMCNoL+jNGUIs9gh44Doqg l6M/YwS12CXo/uOgCHo5+jNGUIt9gsqlELQH9GeMoBa1BJW6vUIYBL0c/Rk/ l5tmIGgkDIJejv6MEdQCQQtDeuiv7j76M0ZQCwQtDOmhv7r76M8YQS1OE/Sz GEEvR3/GCGpjxIdigV8WNBZKf3X30Z8xgtogaGFMF/3V3Ud/xghqs+kfgqZC 6a/uPvozRlAbBC2M6aK/uvvozxhBbRC0MKaL/uruoz/j9oJ25GeGf3nVHUE7 QX/GCGqDoIUxXfRXdx/9GSOoTS1BN580gupAf8YIanOqoBkvTA1B6wSRQ3ro r+4++jNGUBsELQvpob+6++jPGEFtqu2DhtfKDcPkC3rsJUTQOPozRlCbSoJK 18oNw+S8MGZzW7kxEFRCf8YIalNHUDP/T28IQa9Hf8YIalNFUDNsC4igOtCf 8dO6bcM9Bd2yjxa0C/RnjKA2dQTN0A9BG2GlML4QJ8TiSkFQm0qCbo4R/aag J9hgSTja23Qmzk3pIAhqU0vQWsdBbyWo1IJVxm4y7fvRmzn4pfSCoDbVBM3Z 0MmC1nwf9ggqdjGr4ws6jsGEWFwtzQXtyU8ELQvpc30X1xd0tFvQkRZUAEFj YRC0Aa6go93FHeniSiBoLA6CNsARdP5zJ5ziC/+U8rRuxeUAKf7qyFrLM+Vp iC1o2HjesAU92rZunjauiu0WtFZ71HcLGgmmS1Dr0IozcXZKx2gs6PZp46pA 0LKYHqoEtY+AOhNnp3SMtoKa7JqoAwQti+mhSlD7/sbHQQ8Jaqy/PjDBg0iJ 44JmRUDQQn7uTKLfakERtCymx+WCxk+/7fxc3KiHh8eI+toHzTiKgqDxYFtn Ep1yLlER6hIKaCxoZ6O4CFoW00N/dffRn3FrQbtqPxG0MKaH/uruoz9jBHVA 0KKYHvqru4/+jJt3cY8GOBcELYrpob+6++jPGEEdELQopof+6u6jP2MEdUDQ opge+qu7j/6MEdQBQYtieuiv7j76M0ZQB22CDhVOxELQOPozRlAHBC2K6aG/ uvvozxhBHXIFPfy0EFQF+jN+evfy0v3cTtDPIgSV0F/dffRnjKAOdxS0VqMf hvTRX9199GeMoA4IWhLSR39199GfMYI6IGhJSB/91d1Hf8YI6nCaoEPmt3wQ tCn6M24saGd+nilofjEEbYb+jBHUAUFLQvror+4++jNGUAcELYrpob+6++jP GEEdELQopof+6u6jP2MEdUDQopge+qu7j/6MEdQBQYtieuiv7j76M34GD6SF u0HQWJS+D7Mg6FkgqMNZgmZfjhRBm6I/YwR1Mc5dtMTB52Xm/1n5IGgz9GeM oC6nCGqGbPMQtCn6M0ZQl+3KXKkFzQyCoE3Rn3FbQbvz8yRB871D0KbozxhB XU4SNHeMCEHboj9jBHXJqMw1nDn/OGjltwJBTwJBXU4TNBMEbYr+jBHUBUEL Yvror+4++jNGUBcELYjpo7+6++jP+Ck8is8pBUGPknk+w1YMBJXRnzGCumgT NHu4NxliQFAZ/RkjqEueoCc+LwRtif6MEdQFQQti+uiv7j76M0ZQFwQtiOmj v7r7qM/YcvAZcjR6f34iaElMH/XVPUB9xscbyRQIehwEbYn6jBHUA0ELYvqo r+4B6jNGUA8ELQnqob66B6jPGEE9ELQkqIf66h6gPmME9UDQkqAe6qt7gPqM EdTjjoI2OfcJQU8BQT0QtCCmj/rqHqA+YwT1yBC0ijPZIGhL1GeMoB4IWhDT R311D1CfMYJ6IGhBTB/11T1AfcYI6oGgmSGln65QX90D1GfcVNAO/cw6JoGg g/zTFeqre4D6jBHUJ6MyI6iRx7LVV/cA9RkjqA+C5sfzY6qv7gHqM0ZQHwTN C0gLegoI6oOgeRHZBz0FBPVB0LyQjOKeAoL6IGh+TB/11T1AfcYI6oOg+TF9 1Ff3APUZI6gPgubH9FFf3QPUZ4ygPjmCnvrEKmwMQWOozxhBfRA0P6aP+uoe oD7jloJ26SeCFsT0UV/dA9RnjKA+CJof00d9dQ9Qn3FDQcUjZfrJqcwIiqAn 0U5Q+VwT/SBofkwf9dU9QH3GzQSNnK2pHwTNj+mjvroHqM+4laCx7zvoB0Hz Y/qor+4B6jOmBfW5qaDVU0bQU2i4D9qnn3mjuGeeSVRhYwgaQ33GLUdxu/Qz Q9BTh7+qbAxBY6jPuOlhlnaxG7Ip6Kmd9zobQ9AY6jNueZilT7YEPXX4q9LG EDSG+owR1CenBd0qUo86G0PQGOozRlCfnH3QE59dlY0haAz1Gbc8zNInOaO4 Zz67St8H/UFBxxfihFXmzIT2gKA+HAfNjhmQrO4RRZJLjjDaKTkTQSHFIGhA p8dvkzRo80sFjSmSWnKE0b4fvZlBKbW0PNWvUzo9fpvkekGjiiSWHEISNGyn EbQ/EDQzZMi2oEJX9jxBR1rQhY7rOIJmhgzZFFRQpJWgTs95thRBv/RcxRE0 M2TIlqCSIq32QZ2xp9H6C8u8+aeTZ5uwpk3YUzBdZy/T4DlZAddanrAlpohr UkW8FtQZLPIKKYYWNIAWNDNkSFpQWZGTRnEjG/lNQTs9Tf4LgmaGDEkKunUo sukg0ejODEqppYWgndfwztMXafGchIgpQWOKnHmYBUFfmM6bUATNjRlQchw0 eNByFJcziVa6vdbJDILmxgwoOJPIPk12c919cC6uxKlfl2wCgubGDCg5F3eM LjmT3xOUFlQjGgRVifqMm+yD9l3F+85eBkEjqM+4yShu12NECJodM0B9dQ9Q n3Gb46Atgp4GgubGDFBf3QPUZ4ygAQiaGzNAfXUPUJ8xggYgaG7MAPXVPUB9 xggagKC5MQPUV/cA9Rm3OdWvaxA0N2aA+uoeoD5jBA1A0NyYAeqre4D6jBE0 AEFzYwaor+4B6jNG0AAEzY0ZoL66B6jPGEEDEDQ3ZoD66h6gPmMEDUDQ3JgB 6qt7gPqMETQAQXNjBqiv7gHqM0bQkL5PJRZB0AjqM0bQkN7zF0DQCOozRtCQ 3vMXQNAI6jNG0JDe8xdo0WtH0DNA0JDe8xdA0AjqM0bQkN7zF0DQCOozRtCQ 3vOXQFAZ9Rm3uS5u33T/BAQQVEZ9xgga0v0TEEBQGfUZI2hI909AAEFlFGc8 vW8RNKDzixLKIKiM4owRVKb3y/rKIKiM4owRVKT7C+PLIKiM4owRVKL/n5aR QVAZpRlPMwjqY6zbG4GgMoozpgWVuWP7iaAxFGeMoBHuOEaEoBEUZzy9DUXQ kO6fgACCyujNeELQXwJBZfRmPA0I+ju0OPkCQZuCoD9Ek5MvELQp02eYqL6g +KmONidfIGhTEPRnaHTyBYIe5PlimfCXfgTd8PMhzvwQWwdB1dHm5AsEPchz sASsKWh80QsE1UeTky8Q9CCbgg6bZ/oh6E3gspsR1Ao6fW4Q9EfgOKiMckGn tKAPScOHcxeCoD8Cgh7jad0iKFQHQY/hCPoUBR0QFHaDoMdAUGgKgh5jS9D3 F7af33PmZRAU4iDoMWhBoSkIeoykoN9mMy3oYxA8fHj3AQj6IyDoMVxBvWFc BIWjIOgxLhIUP38FBD1GY0FjhiLor4Cgh3DPUIgImj7VD0EhAYIeAkGhLQh6 iOOCiifFP4RHDgj6KyDoIRxBn56Kk19KAkEhBYIeAkGhLQh6CASFtiDoIRAU 2oKgh0BQaAuCHsK5lsIBQT0RERRmwrcaQbN5Oo/2CCqe0/cQH9og6M+AoAdI CjohKBwHQQ+QFlQoFoCgkAZBD5AraPx6CvsExc/fAUEPgKDQGgQ9gCOofYXc aeazEEFhLwh6gKigL3JaUPF4ykMsYIOgvwOCHgBBoTUIup+n8xhBoQEIuh8E heYg6H5CQe1ZCAoVQND9ICg0B0H3c1hQUcXYERcLBP0dEHQ/CArNQdD9ICg0 R72g4x/2YyE99YIOEUO3BZUNRdDfoVDQiCLzoiophdmM1mMhPxWCPv1ZCAoV KBM0psjgmlSPUXgcbOQiQZ/C1DpvshfVFRQ/f4giQaOKtJJkFCbCdrpXQUUV o5cnWkHQH2KPoEJXtpEjgqDjfVpQBIVNdggqKHKeoOONurgICpuUCyop0kzQ 0RqVGq0/qdQf/87kKUyt8yZ70TLxsFdxJv49vrgb8SbfmK3M5FDQI8ubvdby hC8xRYbNVffhD9/KI1EqWlB/ntyCZhzkdNnVgsqNMfRIaQsaGax1TKqHMyo1 rqLKpU4GQaE9hYJuHYqs7IoraOxToCdB7b1RBIVNygSNNpSnCBrbRj+CPuzZ Wf7sETRySBV65Nhx0OBBmz6uzjOJigWdZkE/kwgK2xw6k8g+TXZz3X04Y0+q zsUVL0cdEXT2EkGhkGPn4o7RJWfSjaDu1TgRFLZR/22WDDoS9O/B++YFgsI2 CLqXMkFDEBQyQNC9FLagr4bzT5jX38EWNNtPDL0BCLoX+TfLlrmroNNzbjQX QV8L8+RB0B8HQfeSLei6D/ryBUGhBATdyxFBX9MPt5C1VvpsI2M2DEXQO4Gg eykXdJgFfSu6U1Dz/pcCQe8Egu7lkKDDtAg6/7kPZnzFzPw/DoLeCQTdS5Gg bx7W7U5BjfUXofgLM6AZBN2J7Ge2oO5pRd6JRsvJRntaUAS9FQi6kyOCOiLa gs4P1nXDfdCCHi6C9g+C7mRD0EmY57ag75vw/KLBFVQeJUqBoLcCQXdSR9BB 3gfdakJTIOitQNCdNBbUuUiKHcwMTtkQBL0VCLqTckFnWR5uAXHwdpK0ff9t CZpx2U7oCATdyVFBF3PKBDVesxuAoPcCQXdSTVAZBIU3CLqThoJ6Q7rO8VLj Df0GKyNoIxK7/S1B0J0cFHRLHOEb3sHBU7G6IGgjxF2R9iDoPiJ+1hN0ELu4 TnOKoJtUlAlBd9OHoKsqj2G3oMaa825H/doSxK1qaEndzCk7BQ92b64k7sZK 8cXuO9KCIHC4JQTN4SJB7QeTd0qDt5XYjOiWlrTDI0DxcnK1jc8NVxrsB+Ez DfMs3qS4ePvFtR/4+/1ZK21nFX9yiY8CBM2htaBLDLmKLTMzBE182jvVIb7J XNcStsRrYGJLxwQt0SbTKu+UzMNbij85BD3IGYJ6q80n+cmCTkHxeYb8eb08 uK+gO2TKek7LlxryYiLojwganCUf1EApbj1Bg60lKnNGGbgbHgAAEmtJREFU d1AYm7aLiHplCWqNdb9Xz9LGTyJvA3UFDePar8ECguYQE3ResCFo/tDNUtKI 58lP3oOUoMKDUnattBHvG1OMuzvPz/9BjloebvAVqxQ0I1TwliNoDsWC2uY8 dgga+ab2+j47pdfFXhVby9qLUi1outxWa+NHCFeS85y8JzclGuPUJoPsM9q1 +AaELW3HzMhqKz0HBM3hbEFj1zqZnHde6tA+XIeduuFUkOU+qIpWFXNCBYv9 FXOqbWRLnwdWXkWCpmIeFTR4/ju3tDwn51v70e0vIGgO2lrQ6fN+C4JOjlWT PScmaLB48MqdKGi8DczZZJCrIkEH64QwBK3N6YJGr7f52dLnd5lkQV/zrGo+ zZ6tH9y5gg5uOX+x198OFosrDXKoNftYHU4I6iSRq006EcGUo4Lafd70i+aA oBlE/WwnaOyK1cvH8eB2cWeXHtOyeHlkreSUngbhbgiKCbVma7G8RuBQWML6 ObhUhIg/8U3nktjAwXjRUSC5/AKCZnCNoHIJabRyWCr9+/KecwO7LHIu2jAM niKbnpULunsFt3GJBajmz7kbSD+3yGYRNINiQV0jC06QtY+DyqwtzPvXmdye 1fS9aMpk96icleYogy+oVHPOFXTabmUQtAMUCjr5s5oKuoj1+LSlnqDSjk5Q 6cP9LbnLOUQXDdUFzYhVpx+bsYHLBA3edgTNQJOggyeoP/jwsBOagpXWBd6u JoI6gVsJulUEQQt4LsSLvG/XV/7xeDz//loJ6nQCJ++i2F9em3/fzPfOkhl7 0lnFYXpEF63zY4v3rLAVq3iTpTTfQBIELSLupVfEEjRnpRT2uX4y9sbWOW4r GLagQZTJbUET467RD/7zW9DyTZbSfAMpELSM/gUVVppnVBB0owccK3+k9iOo fhDULxsKmlhJmjNFV02PayBoXRC0jCsFjf/iw7KxRzAnV1D/eAaCnreBFAha hk5Bg6L7cFvQ1EDthqAFdblU6FgEBNUMgnpF9+EIGj03AEHP5CFsGEHjlAv6 yFophT5Bt8ZcEbQaCFrGzwgauejugKAnI3w9CUHj5Lj2LtOjoA6pXmyqrqZ7 wJHtIGgUBC1Ct6C1/Eyfoo6gZ4KgRfyGoC9oQU/bQBIELeJCQc/t4SLoeRtI gqBFIGhqgHde7wJBG+qDoIdBUKdkFVKCbqxXVJURNA2CFvE7giZA0BNB0CJU C3rWT4FWF/RQ3UdQ/ZyWcZZqtxY05yJBCFoRBC0BQV+kqyqCVgVBSygX9JG7 VhwE3Y6AoKr5BUH1jBH9mqDt2+gUCFpCtqB2DxdBt4IhaBwELQFBt0HQujwQ NB/Vgurws1TQ4uMyUgAE1Q2CruUuZ+vHgILyCJoEQQtA0AwQtCoIWsAlgn7M Q9Dk9poLepWfCFpCnmrPBoJ2M0a0Q9CDdR9B1YOgc7GryfxRWmeVGoI21QdB j4Kggw4/31zRgiKoahB0QNB2IOhREHRA0HYg6FF0CTo9vd/ORdB0cQRNgaAF FLegvyhoIQiaBkELQND6IGgaBC0gV9CptqD39RNBN0DQAhC0AaUn7wbrDwiq HH2Czg8RdJvDVf/wyYLb8S8UtIfvgy4ZjS8Sy1uDoA1A0IzN2ySre0SRnFV3 s2xwjGwEQRG0IT0JGlPku7SJKeO8PddTp8RJIGgD1Avafi83SbATmqjuUUW+ c1uYMg6eoOHHgDZB11f0NEH79RNBN9ghqNxSjk1MGQdPUOFj4PaCmrsKuuPb L0IQBHUXyS2lZVJFRiuj+fHPCWpuK+iLCi1oY3s6E1RuKW2T6uHs845D5GNg XPjXlmdpscfzxcGtPv6Zv3/RpR8ObuNCpuMBDofY2kCFLHfz+G56reVpX+SW Mj16tBsnpzH2MaCsBV2LPQ63nn+Yx2sXNNqGdtx2fqAFTVPYgkZaygy797O0 oJGPAWWCTlUFNcNb0KihCIqg1qKN4yxVMoqFHUdnsvlmQ64Q9PYt6GEQdF0U U2R71SN0dhy0sqDDAz+TIGiwaPRnbK96hM7OJGogaHwUF0ERNFhmnxubveoB tJyLm2lbfUETR1kQFEGdha4i57SgW+gSdKo8ivvaCY2DoAiqHgT9ac4Q9Do/ B4OguSCoShBUO/cW1KQkxE8E1Y8qQScEPRkE1Q6C/jZHr2q0GR9Bj6FL0LXc 4/g3Wd6nKCBoGgRVjl5BqzSgCLpBa3sQ9CBqBP1++3j+Qmidc+URdAsEVY4a QYdPd6tmC5oWFD9fNLen+TBUCgTNZrsFRdArQFDlKBL081Z+Cx4X9HMWLoKm ubegwbYRNEbGPuhQVdDv11gQNA2CKkeVoFbBo4KabxOKoGkQVDkqBLWvIFlH UDP/R9A4VS7cubkRBD2ECkFfzC9lFUHN8oegae7egnrvMoLG2NJtqiiomfdA Uy0ofr5BUOXcUNCXnGZuQxE0DYIq536CftXcGsVF0DcIqhwlgq5v4qfg/nPl P34uF/ND0ItB0GPcTVBj/X0DySDoOSDoMVQIag/0H29BnWvJI+jFIOgxbiWo mW/Wa23GPMTPk7hWUP9kXASNcYag3+Fb51rVCHoxCHoMHYIGBfcIujSd9rWq EfRiEPQYlwvqn2+2W9Bl+NYlYiKCngSCHuNyQV/UaEH94dsZBL0WBD3GbQRd z493QdBraX1VsjQImktKt6nWPqj0U2ayifh5Fgh6DHWCfkruHsUNQNCLQdBD qBA0LLlPUOmnBhH0Yi4W1H2nETRGmaCPjTVkxJ8CRdCLQdBDnJRx9hgRgt4N BD2EAkG9d/AraCU/EfRqEPQQvykofp4Hgh4CQaEtCHoIBIW2IOghng6PD06J 1FT+ZhLLGgsqUhwc9oKgh3Dyfz7Cec0F9d/AvYLKfsLVcKLCIRAU2nHKpbFT IGgmCPqz0IIeQhLUmflITOVTJuiu8xQQVCcIeojbCIqfSkHQQ1wuaPD+Iei9 QNBDjLZw689bryAo9AuCZoKgcAU3E/Sx/DCKNa+toOEI/D5B8RMEbiqoZeEj MVVAkaCP5BoyCAoCCJpJXFChLIJCJRA0EwSFK0DQTETdIieCISjUAkEziekm naW5R1D8BAkEzQRB4QruKuhi4SMxVYLcxZV/F+AZXyOGeMFNAATNxNdt+txU ElS8YjUAguYiCyqfplki6PfnBjEURIzXAnQoqLOH2ZugZv3JJAyFEATNJBA0 8V37fEHfPzdovrugGAoBCJqJrVtKzrVshqCf/q0xwc9qA3y4raDz3NRdCZ5u 03eQKF427qexH9B+Qoq7C5pqSItwWtC0oI+YoOZ7axn6VZMxIpBB0ExcQadh h6CLjpah8+AQfoIIgmbyDbwM3iaugxER9GOmWR6/72k6IQmCZuILmkAW9Gvm d0ho8RQ/IcXdBPWHcasLmnElY1HQz4DQbKdZZwIkQNA85rDTq/ncuMxbrAU1 g7cfip+wxX0FTX6NpdjQV9ic1nNY+tnhPqhZ90Pf//ATNkHQPNYWdEgOEA1J QdcRovnoJ0ASBM1j2QV93yaLRgW1urRzKwqQ5g6COruWZwiaJiKo8R5z9hBk gKB5vPdB5W9/+nyb8ZSg3tFQgBgImscsaAayoCacxE/Y5MaCDqlLypca+hnF zSk5J2ELKuxusgcKOSBoHjsFXU6PD23ET8gAQfN4Zv8Uui3o+m0VdIR9GM2C ji/ECatMS0GXF+eZ24DagtqnDmEo7KJE0IgiySVHGO2UnAm3UFtB3y/QHkGl 0+MByigQNKZIaskRRvt+9GbapU4RdHMM9+vjJwkzPO3T4/ETdpIvaFSRxJIq 2IKG7XRcUM/C1FSMVdD0V0CHpS/7eN3+yWmeg/3VFfyEfRQLmujKthd0LGlB DwrqnBr/3Orfzi4+Xo/eXdy1Z8seKOymVFBBkZyVD2D1n8eiLm6NFnTmuTGC u/RjH69+7WuA6Gldagg/YS+FgkqKZKy7E2vsabT+gjKPd8HHvxfPfwuPfzbe lMM/mem5ECnxxawRX3udf63nXx7mMx/gAGZ63Y4LCVtiirgmVWR0H4/+vKWQ /XXswp/ltNYMmT5n+A1b+59L2/l5bD5d3B2JAHgUtaCyIm37tstEZKi4oaDT kC3on5WPdTxIOlkeYA8lgiYORbbAFXQUZs4zFAj6Hb/9OPoZxQU4ToGgMUXO ETS2rRqCSoa+j3sWBHtY40FP/IRKHDgOGj6oyyhMyZ8OrQQtiGXsEE96uFCJ /WcSrcNCrQR1B67i5+K2EbSsAUVQaMKBc3Hd09ibjONmgKBwZ1R/myWHFoIu pydkBzADgkILvC+EIujMVBQLQaENCGqtazEVCuoEQFCoBYJa61qUCWq8AE8E hTrcQlD7mn0ICncCQYc5gM18GYU8jB8AQaESCDrMAWwQFHSAoMMcwAZBQQc3 FHS5TskweGe5L+e9T4N/EvxjnWMGW1DpW2Pu7++awE8EhVrcTtDP1UlkFTPm DpMZzHuEyFiXtnWVXOatdwgKbUDQ5YGZ5rbzJejnG2PLb2FbSlq/j23my1Ij KLQBQdee7evPfAV9f61zuUTCYClpzRvmn802CAptuJmg8/W9XL5LYoSLP/o9 zcxralEyYKCLC624maBmbkETKg52w+l5aYw18ZzNDHx0WtCBFhSacS9BXx3Q 5/R9Uu99ymn+ws46N5h4rTU9jJnml2Pt4X4uD//e0HKJ+GAfNPATQaEWtxL0 PcjznD57kmbZr5xVtAw09sR78eNTdl30/fEG38V5nnOHoNCIOwn69mV6Lm3g PDL7aSKXuWZwJt46/gm6jOJ+jf46FhxRmefZdwgKTXB2zl50Kuj7p5Hevk3m uew4Tt89xmmYJ7zO6mfiPSQ0LZe1Hb67p851v1wlAxAUGnGPFvTz22XmK6gz liNOCYM+4Xe2Sy7pF6yKoFCF+wj67tBOc8Pn/nCuN+W0oN9FCAoauZWgf132 +Yc5B++8H+ksIHdRYGi+Y8KqCApVuJGgy5W+3LEcccpvYAcEBZV4wx59Czpf 6ct9UuKUCRZVFRQ/oQ73ENQejd7rRrgfuXtVBIVa3EPQZZBoQFC4FQg6U1NQ dkGhErcR9PMdzuGAG8EJ7ztXPJQEgMOdBP0+l0pNKIKCAu4j6ICgcD9uIuhn F/TzEEHhPtxF0M8XUN4gKNyHGwk6P5U6gh4axEVQqASCrvi/ULZntaM5ADgg 6AqCgjpuIqj9fWsEhftwH0GXZ/KswyMbISsEhTrcRdD45UgAOgZBARRzD0Gt o6AAd+I2guIn3JFbCPo6UR5B4Y7cRFBDCwq35B6CmoEmFG7JPQRdrqUJcC+6 F9S6XhiGwu3oXlBaULgz9xDUDIwSwS25h6D4CTflDoJyGBTui1uz+xSU/U+4 LQgKoJhbCIqfcFcQFEAxCAqgGAQFUEz/guIn3BgEBVAMggIoBkEBFHMDQfET 7guCAigGQQEUg6AAiuleUPyEO4OgAIpBUADFICiAYvoX9OoMABqCoACK6V3Q CUHhznQuqFGzC6rlpdOSh5pEtOSxM5G+BTV6TpXX8tJpyUNNIlry+EVBjaJL +ml56bTkoSYRLXncXdDxhTvL+uGk69Hy0mnJQ00iWvJoL6igyHmM1u0CLWiI ljzUJKIlj+aCioqcxejdf2EfNEBLHmoS0ZJHa0EjipzEd6tBC84oro+WPNQk oiWPfYkY92eHtgW9qJM7N9/B1lXsf77QUg+05KEmES157ErE/2HNTUEFRU5h /N4EW+/65W+BljzUJKIljz2JGP+nqbcElRQ5hdH6cxcA3BVj/X3ZocgpjOsn BMCvYKzbLa5VZFy62AC/gxmyDyNeq8jctiMo/BQm+zDitYpce5AH4CqyDyNe rAg9XIAkFyuyMYYF8OugCAAAAAAAAAAAAAAAAADAOag5PqsmkUHLOVdKXhAV b4yVgIp8TkPNSYBqEhkuu/CFh5JvCKp4Y6x3REU+p6HmNHo1iQzXXfjCRUMO g5I3xmoyVeRzHtdeK0lAQSKXXfjCz0IFSoTwBdVTY9ty7bWSBK5P5LoLXzgo SOGNTkEV1di2XHutpJDr81Cy56chhQ869vlcQRXV2MZce60kBx2Dczqq47Bc z+3qNAYlb4wjqJIaewZ6Lid2fQZvMi4Ad1Iizt2F6PjIsgVVUmNPQc3lxC5P wEFBNkr2/bTkYQmqpMaeg5rLiV2egIOCbJSIoSWPVVAtNfYclLz8ChJwUJCN lndGSR6/ehxUTX/h+gxsNGSj6525Oo9fPZNIyRidosGZNyqy0PJyKMjDSUFB PgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL/AfxnE0CFXWhCAAAAAElF TkSuQmCC --=====================_26925641==_ Content-Type: text/plain; name="bad.txt"; x-mac-type="42494E41"; x-mac-creator="74747874" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bad.txt" IyAgICAgICAgIHRpbWUgICBNQi9zIGF2Z19sZW4gbnNlbnQgYXZnX3dpbiBh ZHYvc2VudAogICAgICAgICAgIDAuMCAgICAxLjMgICAgIDE0NSAgIDkyNCAx Nzg5Ni4wICAgMC4zCiAgICAgICAgICAgMC4xICAgIDguMCAgICAgMTQ0ICA1 NTUxIDE3Nzc1LjAgICAwLjMKICAgICAgICAgICAwLjIgICAxMi45ICAgICAy NzIgIDQ3NDggMTc2ODguMCAgIDAuMwogICAgICAgICAgIDAuMyAgIDEzLjMg ICAgIDI3MiAgNDg4NyAxNzY4OC4wICAgMC4zCiAgICAgICAgICAgMC40ICAg MTUuMyAgICAgMjcyICA1NjE2IDE3Njg4LjAgICAwLjEKICAgICAgICAgICAw LjUgICAxNS4zICAgICAyNzIgIDU2MzIgMTc2ODguMCAgIDAuMQogICAgICAg ICAgIDAuNiAgIDE1LjIgICAgIDI3MiAgNTYwMyAxNzY4OC4wICAgMC4xCiAg ICAgICAgICAgMC43ICAgMTUuMyAgICAgMjcyICA1NjMyIDE3Njg4LjAgICAw LjEKICAgICAgICAgICAwLjggICAxNS4wICAgICAyNzIgIDU1MDkgMTc2ODgu MCAgIDAuMQogICAgICAgICAgIDAuOSAgIDE1LjEgICAgIDI3MiAgNTU2NyAx NzY4OC4wICAgMC4xCiAgICAgICAgICAgMS4wICAgMTUuNCAgICAgMjcyICA1 Njc1IDE3Njg4LjAgICAwLjEKICAgICAgICAgICAxLjEgICAxNS40ICAgICAy NzIgIDU2NDcgMTc2ODguMCAgIDAuMQogICAgICAgICAgIDEuMiAgIDE1LjQg ICAgIDI3MiAgNTY2NyAxNzY4OC4wICAgMC4xCiAgICAgICAgICAgMS4zICAg MTUuMyAgICAgMjcyICA1NjM0IDE3Njg4LjAgICAwLjEKICAgICAgICAgICAx LjQgICAxNS40ICAgICAyNzIgIDU2NjggMTc2ODguMCAgIDAuMQogICAgICAg ICAgIDEuNSAgIDE1LjIgICAgIDI3MiAgNTYwNSAxNzY4OC4wICAgMC4xCiAg ICAgICAgICAgMS42ICAgMTUuMiAgICAgMjcyICA1NTkzIDE3Njg4LjAgICAw LjEKICAgICAgICAgICAxLjcgICAxNS40ICAgICAyNzIgIDU2NDUgMTc2ODgu MCAgIDAuMQogICAgICAgICAgIDEuOCAgIDE1LjQgICAgIDI3MiAgNTY1NSAx NzY4OC4wICAgMC4xCiAgICAgICAgICAgMS45ICAgMTUuMiAgICAgMjcyICA1 NTc2IDE3Njg4LjAgICAwLjEKICAgICAgICAgICAyLjAgICAxOC4xICAgICAz NDAgIDUzMDkgMTc2ODguMCAgIDAuMQogICAgICAgICAgIDIuMSAgIDIwLjMg ICAgIDQwMCAgNTA3OCAxNzY4OC4wICAgMC4yCiAgICAgICAgICAgMi4yICAg MjAuMiAgICAgMzk5ICA1MDU2IDE3Njg4LjAgICAwLjIKICAgICAgICAgICAy LjMgICAyMC4yICAgICA0MTMgIDQ4OTEgMTc2ODguMCAgIDAuMgogICAgICAg ICAgIDIuNCAgIDIxLjUgICAgIDU3OSAgMzcxOCAxNzY4OC4wICAgMC41CiAg ICAgICAgICAgMi41ICAgMjMuNCAgICAgNjU2ICAzNTYwIDE3Njg4LjAgICAw LjUKICAgICAgICAgICAyLjYgICAyMy45ICAgICA2NjQgIDM1OTUgMTc2ODgu MCAgIDAuNQogICAgICAgICAgIDIuNyAgIDI1LjEgICAgIDc4NCAgMzIwNiAx NzY4OC4wICAgMC42CiAgICAgICAgICAgMi44ICAgMjUuNCAgICAgNzg0ICAz MjM3IDE3Njg4LjAgICAwLjcKICAgICAgICAgICAyLjkgICAyNy4xICAgICA4 ODAgIDMwODMgMTc2ODguMCAgIDAuNwogICAgICAgICAgIDMuMCAgIDMyLjcg ICAgMTA0MyAgMzEzNyAxNzY4OC4wICAgMC42CiAgICAgICAgICAgMy4xICAg MzUuMiAgICAxMjk2ICAyNzE2IDE3Njg4LjAgICAwLjcKICAgICAgICAgICAz LjIgICAzNi43ICAgICA5NTkgIDM4MjggMTc2ODguMCAgIDAuNQogICAgICAg ICAgIDMuMyAgIDQyLjcgICAgIDg1MiAgNTAxMiAxNzY4OC4wICAgMC4zCiAg ICAgICAgICAgMy40ICAgNjMuNyAgICAxMTE2ICA1NzA3IDE3Njg4LjAgICAw LjEKICAgICAgICAgICAzLjUgICA3Mi4wICAgIDI3OTIgIDI1NzkgMTc2ODgu MCAgIDAuNAogICAgICAgICAgIDMuNiAgIDY4LjIgICAgMjk1MSAgMjMwOSAx NzY4OC4wICAgMC40CiAgICAgICAgICAgMy43ICAgNTcuNCAgICA4ODAwICAg NjUyIDE3Njg4LjAgICAxLjIKICAgICAgICAgICAzLjggICA1Ny45ICAgIDc3 MDYgICA3NTEgMTc2ODguMCAgIDEuMAogICAgICAgICAgIDMuOSAgIDU4LjMg ICAgNzE2NSAgIDgxNCAxNzY4OC4wICAgMC45CiAgICAgICAgICAgNC4wICAg NTcuOSAgICA3MTQ5ICAgODEwIDE3Njg4LjAgICAwLjkKICAgICAgICAgICA0 LjEgICA1NS45ICAgIDc0NTkgICA3NTAgMTc2ODguMCAgIDAuOQogICAgICAg ICAgIDQuMiAgIDU2LjEgICAgNzQ5NSAgIDc0OSAxNzY4OC4wICAgMC45CiAg ICAgICAgICAgNC4zICAgNTUuNSAgICA3NzM2ICAgNzE3IDE3Njg4LjAgICAw LjkKICAgICAgICAgICA0LjQgICA1NS42ICAgIDgxNTAgICA2ODIgMTc2ODgu MCAgIDEuMAogICAgICAgICAgIDQuNSAgIDU1LjUgICAgODEyNCAgIDY4MyAx NzY4OC4wICAgMS4wCiAgICAgICAgICAgNC42ICAgNTYuMCAgICA4NTQ0ICAg NjU1IDE3Njg4LjAgICAxLjAKICAgICAgICAgICA0LjcgICA1Ni4wICAgIDg1 MjQgICA2NTcgMTc2ODguMCAgIDEuMAogICAgICAgICAgIDQuOCAgIDU0LjIg ICAgODg0MCAgIDYxMyAxNzY4OC4wICAgMS4wCiAgICAgICAgICAgNC45ICAg NTMuOSAgICA4OTIzICAgNjA0IDE3Njg4LjAgICAxLjAKICAgICAgICAgICA1 LjAgICA1NC4wICAgIDg5MDUgICA2MDYgMTc2ODguMCAgIDEuMAogICAgICAg ICAgIDUuMSAgIDU0LjMgICAgODk0OCAgIDYwNyAxNzY4OC4wICAgMS4wCiAg ICAgICAgICAgNS4yICAgNTQuMSAgICA4ODk3ICAgNjA4IDE3Njg4LjAgICAx LjAKICAgICAgICAgICA1LjMgICA1NC4wICAgIDg5NDggICA2MDQgMTc2ODgu MCAgIDEuMAogICAgICAgICAgIDUuNCAgIDUzLjggICAgODkyNyAgIDYwMyAx NzY4OC4wICAgMS4wCiAgICAgICAgICAgNS41ICAgNTQuMiAgICA4OTQ4ICAg NjA2IDE3Njg4LjAgICAxLjAKICAgICAgICAgICA1LjYgICA1NC4zICAgIDg5 NDggICA2MDcgMTc2ODguMCAgIDEuMAogICAgICAgICAgIDUuNyAgIDUyLjYg ICAgODg5MiAgIDU5MiAxNzY4OC4wICAgMS4wCiAgICAgICAgICAgNS44ICAg NTAuMCAgICA4OTQ4ICAgNTU5IDE3Njg4LjAgICAxLjAKICAgICAgICAgICA1 LjkgICA1MS45ICAgIDg5MTAgICA1ODIgMTc2ODguMCAgIDEuMAogICAgICAg ICAgIDYuMCAgIDUxLjEgICAgODg5MSAgIDU3NSAxNzY4OC4wICAgMS4wCiAg ICAgICAgICAgNi4xICAgNTAuOSAgICA4OTM0ICAgNTcwIDE3Njg4LjAgICAx LjAKICAgICAgICAgICA2LjIgICA1MC4wICAgIDg4ODMgICA1NjMgMTc2ODgu MCAgIDEuMAogICAgICAgICAgIDYuMyAgIDUwLjQgICAgODg4NCAgIDU2NyAx NzY4OC4wICAgMS4wCiAgICAgICAgICAgNi40ICAgNTAuMSAgICA4OTEyICAg NTYyIDE3Njg4LjAgICAxLjAKICAgICAgICAgICA2LjUgICA1Mi4xICAgIDg4 ODcgICA1ODYgMTc2ODguMCAgIDEuMAogICAgICAgICAgIDYuNiAgIDUwLjUg ICAgODg3OSAgIDU2OSAxNzY4OC4wICAgMS4wCiAgICAgICAgICAgNi43ICAg NTEuNCAgICA4OTA5ICAgNTc3IDE3Njg4LjAgICAxLjAKICAgICAgICAgICA2 LjggICA1MC43ICAgIDg5MDMgICA1NjkgMTc2ODguMCAgIDEuMAogICAgICAg ICAgIDYuOSAgIDUyLjAgICAgODg4OSAgIDU4NSAxNzY4OC4wICAgMS4wCiAg ICAgICAgICAgNy4wICAgNTAuMSAgICA4ODk3ICAgNTYzIDE3Njg4LjAgICAx LjAKICAgICAgICAgICA3LjEgICA1Mi4yICAgIDg5MTcgICA1ODUgMTc2ODgu MCAgIDEuMAogICAgICAgICAgIDcuMiAgIDUyLjQgICAgODkxNCAgIDU4OCAx NzY4OC4wICAgMS4wCiAgICAgICAgICAgNy4zICAgNTIuMyAgICA4OTM3ICAg NTg1IDE3Njg4LjAgICAxLjAKICAgICAgICAgICA3LjQgICA0OS4yICAgIDg5 MDUgICA1NTIgMTc2ODguMCAgIDEuMAogICAgICAgICAgIDcuNSAgIDUyLjQg ICAgODkxOCAgIDU4NyAxNzY4OC4wICAgMS4wCiAgICAgICAgICAgNy42ICAg NTIuNSAgICA4OTExICAgNTg5IDE3Njg4LjAgICAxLjAKICAgICAgICAgICA3 LjcgICA0Ny43ICAgIDg5MTYgICA1MzUgMTc2ODguMCAgIDEuMAogICAgICAg ICAgIDcuOCAgIDUyLjUgICAgODkzNiAgIDU4OCAxNzY4OC4wICAgMS4wCiAg ICAgICAgICAgNy45ICAgNTIuNCAgICA4OTM0ICAgNTg3IDE3Njg4LjAgICAx LjAKICAgICAgICAgICA4LjAgICA1Mi4yICAgIDg5MjYgICA1ODUgMTc2ODgu MCAgIDEuMAogICAgICAgICAgIDguMSAgIDUyLjMgICAgODkyOSAgIDU4NiAx NzY4OC4wICAgMS4wCiAgICAgICAgICAgOC4yICAgNTIuNyAgICA4OTQxICAg NTg5IDE3Njg4LjAgICAxLjAKICAgICAgICAgICA4LjMgICA0Ni4yICAgIDg5 MjcgICA1MTcgMTc2ODguMCAgIDEuMAogICAgICAgICAgIDguNCAgIDUyLjQg ICAgODkxOCAgIDU4NyAxNzY4OC4wICAgMS4wCiAgICAgICAgICAgOC41ICAg NTIuNCAgICA4OTMzICAgNTg3IDE3Njg4LjAgICAxLjAKICAgICAgICAgICA4 LjYgICA1Mi41ICAgIDg5MzMgICA1ODggMTc2ODguMCAgIDEuMAogICAgICAg ICAgIDguNyAgIDUyLjQgICAgODkzMyAgIDU4NyAxNzY4OC4wICAgMS4wCiAg ICAgICAgICAgOC44ICAgNTIuNCAgICA4OTE4ICAgNTg4IDE3Njg4LjAgICAx LjAKICAgICAgICAgICA4LjkgICA1Mi4zICAgIDg5MzMgICA1ODYgMTc2ODgu MCAgIDEuMAogICAgICAgICAgIDkuMCAgIDQzLjggICAgODkzMCAgIDQ5MCAx NzY4OC4wICAgMS4wCiAgICAgICAgICAgOS4xICAgNTIuMyAgICA4OTQwICAg NTg1IDE3Njg4LjAgICAxLjAKICAgICAgICAgICA5LjIgICA1Mi42ICAgIDg5 NDggICA1ODggMTc2ODguMCAgIDEuMAogICAgICAgICAgIDkuMyAgIDUyLjQg ICAgODkyNSAgIDU4NyAxNzY4OC4wICAgMS4wCiAgICAgICAgICAgOS40ICAg NTIuNSAgICA4OTQwICAgNTg3IDE3Njg4LjAgICAxLjAKICAgICAgICAgICA5 LjUgICA1Mi4yICAgIDg5MjUgICA1ODUgMTc2ODguMCAgIDEuMAogICAgICAg ICAgIDkuNiAgIDUyLjUgICAgODk0MCAgIDU4NyAxNzY4OC4wICAgMS4wCiAg ICAgICAgICAgOS43ICAgNTIuNSAgICA4OTI1ICAgNTg4IDE3Njg4LjAgICAx LjAKICAgICAgICAgICA5LjggICA1Mi41ICAgIDg5NDggICA1ODcgMTc2ODgu MCAgIDEuMAogICAgICAgICAgIDkuOSAgIDUyLjQgICAgODk0MCAgIDU4NiAx NzY4OC4wICAgMS4wCiAgICAgICAgICAxMC4wICAgNTIuNyAgICA4OTQwICAg NTg5IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDEwLjEgICA0MC41ICAgIDg5 MTkgICA0NTQgMTc2ODguMCAgIDEuMAogICAgICAgICAgMTAuMiAgIDUyLjcg ICAgODk0OCAgIDU4OSAxNzY4OC4wICAgMS4wCiAgICAgICAgICAxMC4zICAg NTIuMiAgICA4OTMyICAgNTg0IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDEw LjQgICA1Mi41ICAgIDg5MzMgICA1ODggMTc2ODguMCAgIDEuMAogICAgICAg ICAgMTAuNSAgIDUyLjMgICAgODk0OCAgIDU4NSAxNzY4OC4wICAgMS4wCiAg ICAgICAgICAxMC42ICAgNTIuNSAgICA4OTMzICAgNTg4IDE3Njg4LjAgICAx LjAKICAgICAgICAgIDEwLjcgICA1Mi42ICAgIDg5NDggICA1ODggMTc2ODgu MCAgIDEuMAogICAgICAgICAgMTAuOCAgIDUwLjcgICAgODkzMiAgIDU2OCAx NzY4OC4wICAgMS4wCiAgICAgICAgICAxMC45ICAgNTEuOCAgICA4OTMyICAg NTgwIDE3Njg4LjAgICAxLjAKICAgICAgICAgIDExLjAgICA1Mi4zICAgIDg5 NDggICA1ODUgMTc2ODguMCAgIDEuMAogICAgICAgICAgMTEuMSAgIDUyLjMg ICAgODkzMyAgIDU4NiAxNzY4OC4wICAgMS4wCiAgICAgICAgICAxMS4yICAg NTIuNSAgICA4OTMzICAgNTg4IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDEx LjMgICA1Mi4zICAgIDg5NDggICA1ODUgMTc2ODguMCAgIDEuMAogICAgICAg ICAgMTEuNCAgIDUyLjMgICAgODkzMiAgIDU4NiAxNzY4OC4wICAgMS4wCiAg ICAgICAgICAxMS41ICAgNTIuMyAgICA4OTQ4ICAgNTg1IDE3Njg4LjAgICAx LjAKICAgICAgICAgIDExLjYgICAzNS4yICAgIDg5MjYgICAzOTQgMTc2ODgu MCAgIDEuMAogICAgICAgICAgMTEuNyAgIDUyLjUgICAgODk0OCAgIDU4NyAx NzY4OC4wICAgMS4wCiAgICAgICAgICAxMS44ICAgNTIuNCAgICA4OTMyICAg NTg3IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDExLjkgICA1Mi40ICAgIDg5 NDggICA1ODYgMTc2ODguMCAgIDEuMAogICAgICAgICAgMTIuMCAgIDUyLjcg ICAgODk0OCAgIDU4OSAxNzY4OC4wICAgMS4wCiAgICAgICAgICAxMi4xICAg NTIuMiAgICA4OTMzICAgNTg0IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDEy LjIgICA1Mi44ICAgIDg5NDggICA1OTAgMTc2ODguMCAgIDEuMAogICAgICAg ICAgMTIuMyAgIDUyLjIgICAgODkzMiAgIDU4NCAxNzY4OC4wICAgMS4wCiAg ICAgICAgICAxMi40ICAgNTIuNSAgICA4OTQ4ICAgNTg3IDE3Njg4LjAgICAx LjAKICAgICAgICAgIDEyLjUgICA1Mi4zICAgIDg5NDggICA1ODUgMTc2ODgu MCAgIDEuMAogICAgICAgICAgMTIuNiAgIDUyLjMgICAgODkzMyAgIDU4NiAx NzY4OC4wICAgMS4wCiAgICAgICAgICAxMi43ICAgNTIuMyAgICA4OTQ4ICAg NTg1IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDEyLjggICA1Mi4zICAgIDg5 MzIgICA1ODYgMTc2ODguMCAgIDEuMAogICAgICAgICAgMTIuOSAgIDUyLjQg ICAgODk0OCAgIDU4NiAxNzY4OC4wICAgMS4wCiAgICAgICAgICAxMy4wICAg NTIuMyAgICA4OTMzICAgNTg1IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDEz LjEgICA1Mi4zICAgIDg5NDggICA1ODUgMTc2ODguMCAgIDEuMAogICAgICAg ICAgMTMuMiAgIDUyLjYgICAgODk0OCAgIDU4OCAxNzY4OC4wICAgMS4wCiAg ICAgICAgICAxMy4zICAgNTIuNCAgICA4OTMyICAgNTg3IDE3Njg4LjAgICAx LjAKICAgICAgICAgIDEzLjQgICA1Mi41ICAgIDg5NDggICA1ODcgMTc2ODgu MCAgIDEuMAogICAgICAgICAgMTMuNSAgIDUyLjMgICAgODkzMiAgIDU4NSAx NzY4OC4wICAgMS4wCiAgICAgICAgICAxMy42ICAgNTIuNSAgICA4OTQ4ICAg NTg3IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDEzLjcgICA1Mi40ICAgIDg5 NDggICA1ODYgMTc2ODguMCAgIDEuMAogICAgICAgICAgMTMuOCAgIDI5LjUg ICAgODg2OCAgIDMzMyAxNzY4OC4wICAgMS4wCiAgICAgICAgICAxMy45ICAg NTMuMiAgICA4OTQ4ICAgNTk0IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDE0 LjAgICA1My4zICAgIDg5NDggICA1OTYgMTc2ODguMCAgIDEuMAogICAgICAg ICAgMTQuMSAgIDUzLjEgICAgODk0NyAgIDU5MyAxNzY4OC4wICAgMS4wCiAg ICAgICAgICAxNC4yICAgNTIuNiAgICA4OTQ4ICAgNTg4IDE3Njg4LjAgICAx LjAKICAgICAgICAgIDE0LjMgICA1Mi4zICAgIDg5NDggICA1ODQgMTc2ODgu MCAgIDEuMAogICAgICAgICAgMTQuNCAgIDUyLjUgICAgODkzMyAgIDU4OCAx NzY4OC4wICAgMS4wCiAgICAgICAgICAxNC41ICAgNTIuNSAgICA4OTQ4ICAg NTg3IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDE0LjYgICA1Mi41ICAgIDg5 NDggICA1ODcgMTc2ODguMCAgIDEuMAogICAgICAgICAgMTQuNyAgIDUyLjMg ICAgODk0OCAgIDU4NCAxNzY4OC4wICAgMS4wCiAgICAgICAgICAxNC44ICAg NTIuNSAgICA4OTQ3ICAgNTg3IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDE0 LjkgICA1Mi4zICAgIDg5NDggICA1ODQgMTc2ODguMCAgIDEuMAogICAgICAg ICAgMTUuMCAgIDUyLjUgICAgODk0OCAgIDU4NyAxNzY4OC4wICAgMS4wCiAg ICAgICAgICAxNS4xICAgNTIuMyAgICA4OTMzICAgNTg2IDE3Njg4LjAgICAx LjAKICAgICAgICAgIDE1LjIgICA1Mi40ICAgIDg5NDggICA1ODYgMTc2ODgu MCAgIDEuMAogICAgICAgICAgMTUuMyAgIDUyLjMgICAgODk0OCAgIDU4NSAx NzY4OC4wICAgMS4wCiAgICAgICAgICAxNS40ICAgNTIuNCAgICA4OTQ3ICAg NTg2IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDE1LjUgICA1Mi4yICAgIDg5 NDggICA1ODMgMTc2ODguMCAgIDEuMAogICAgICAgICAgMTUuNiAgIDUyLjUg ICAgODk0OCAgIDU4NyAxNzY4OC4wICAgMS4wCiAgICAgICAgICAxNS43ICAg NTIuMSAgICA4OTMzICAgNTgzIDE3Njg4LjAgICAxLjAKICAgICAgICAgIDE1 LjggICA1MS4yICAgIDg5NDggICA1NzIgMTc2ODguMCAgIDEuMAogICAgICAg ICAgMTUuOSAgIDUxLjUgICAgODk0OCAgIDU3NiAxNzY4OC4wICAgMS4wCiAg ICAgICAgICAxNi4wICAgNTIuMyAgICA4OTQ3ICAgNTg1IDE3Njg4LjAgICAx LjAKICAgICAgICAgIDE2LjEgICA1Mi40ICAgIDg5NDggICA1ODYgMTc2ODgu MCAgIDEuMAogICAgICAgICAgMTYuMiAgIDUyLjcgICAgODk0OCAgIDU4OSAx NzY4OC4wICAgMS4wCiAgICAgICAgICAxNi4zICAgNTIuMyAgICA4OTQ4ICAg NTg1IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDE2LjQgICA1Mi41ICAgIDg5 NDcgICA1ODcgMTc2ODguMCAgIDEuMAogICAgICAgICAgMTYuNSAgIDUyLjUg ICAgODk0OCAgIDU4NyAxNzY4OC4wICAgMS4wCiAgICAgICAgICAxNi42ICAg NTIuNyAgICA4OTQ4ICAgNTg5IDE3Njg4LjAgICAxLjAKICAgICAgICAgIDE2 LjcgICAxNC4zICAgIDg3NjcgICAxNjMgMTc2ODguMCAgIDEuMAojIHRvdCBz ZW50OiAyNDkwNTkgLCB0b3RfcmVjdmQ6IDExODY4MywgdG90X290aGVyczog Mgo= --=====================_26925641==_ Content-Type: image/png; name="bw_winsiz.png"; x-mac-type="504E4766"; x-mac-creator="6D646F73" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bw_winsiz.png" iVBORw0KGgoAAAANSUhEUgAAA6AAAAK4CAMAAABd6WDBAAAAA3NCSVQICAjb 4U/gAAABKVBMVEX///8AAAAAAAD/AAAAwAAAgP/AAP/A/0DAQABA/4AgIMCA AMAAYIAAgAAAgEAAgIAAwGAAwMAA/wAggCAwYIBAQEBAgAAAAICAYACAYBCA YGCAYIAAAMAAAP8AYABAwIBgoMBgwABgwKCAAACAAIBgIIBgYGAA//8gICAg QEAgQIBggCBggGBggICAgECAgICgoKCg0ODAICDAYACAwODAYMDAgADAgGD/ QAD/QECAwP//gGD/gIDAoADAwMDA/8D/AAD/AP//gKD/gP/AwKD/YGD/gAD/ oACA4OCg4OCg/yDAAADAAMCgICCgIP+AIACAICCAQACAQCCAQICAYMCAYP+A gACggP/AYIDAwAD/gED/oED/oGD/oHD/wCD/wMD//wD//4D//8BTi7KnAAAA O3RFWHRTb2Z0d2FyZQBnbnVwbG90IHZlcnNpb24gMy43IHBhdGNobGV2ZWwg MiBvbiBMaW51eCAyLjQuMy0xMrFi8REAACAASURBVHic7Z2LoqsoEgB1OZn/ /+S9eag8GgVtFdqqmXsSFIFOqKBozDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAWGB800Wh35L1S+whfq8wxbJPKXVcTSoUelrfapLR+9t2od8y9V2a/yiX qVmoF7Zi2aeUGr1DOm+YX8oZb1i7jNFju4X+StQu85RPEe2yvSFDsexTSo1G N503bEw+Sh7DL9xz9hnOGO1OGeuUOeEDKlZJaWDaXHCwULU3LPkoeQrTrk0X go76ZXYqqNIbdragem/YswXVH5iWsrXL60HQE47Bww6q9YbFhSgXqviGPVrQ MwamE2bazpnOGvuYxQ46qNobdu4sruYbthR6zhvWLKPq55xXqj7jeMKbMwYP uqWeNYLqvWGnTL3ELqm8YckxuEKZXTCeMTCd+eqdtIvb+iy210EV37BTdhzH 1eTRQs87Q9Am4xmfSAiqXqg3LCmWjaDNc2oHPYPHC6pZNoK2zxlTLx0JetLU k3qh8dFiw3Oj5wp6zhvWMidMip0ynTOVrV5gB7O4QXFqZXsF6b1jSSkqU0Sn xA8AAAAAAAAAAAAAAAAAAArkLuPg7C5AfEFG/gKIsy6NyN2x6XHXRwGsMCZ/ SxMH683cselxVxgDrBF8pbYmoVPz8jwUlJ1cgCEeIMeKhFLV89NokEZQANGK woRW3UM4PE/PERQg3oEdKxJqlaeHueMg1DECmKNCkdmKwsRhwqnhqbXBh4GY XZPKQguzn9pU1cL3FVbarVTJnZXTLFRn64pC17MG+5g1g+cpL848gmamihH0 hMIR9ISttQQNJmk8KwoTh8kIOoprERRBT6ikZUH9dYEVhYnD5EbQTB0IekLh CHrC1jqCjlJirEgcJvOK5wZpBD2hcAQ9YesTBA2tKEwcI5nDGrNrovWaIOgJ WyGoRv1xvL4VhYlrQdATCkfQE7ZWOgbtDQQ9oXAEPWFrBL2tUAQt2QpBL6q/ LSzFAvDBUqe2FAvAB0ud2lIsAB8sdeqdsbg3v6dD+OhlqiyzMlv6BOANgrrk r2SJhqAuWYqgsMHjBQ0GzUBTMVtlqeHC8wTFa6sgqP/o/CVitspSS7MdFNRh qFUQ1H90Q04R5x+qRsetwprAdHFEXrJ9n7t59PZLK48BQ22CoP6jyw5Fiz/x puEaf1ksqOedixZ4T/KjeI78jjl0D4L6j/ldRXE0TDXMJ8QnwprcPJU7RCYq aB4E9R9ddiC6XdAVGEENg6D+49oxaPDoDUzKgsYLSuAY1C4I6j9uz+KmB5zr ggbunCUos7h2QVD/Mb+zWDhOHhFUHnXLwE+rPF7QQMr8AaA0Vysp5cLcLhjc 8rO4c7adgoJVELT0Wtz0bKd4MsU/wRmNn5nTpeHm2RbAI0FQgIax1KktxQLw wVKnthQLwAdLndpSLAAfLHVqS7EAfLDUqS3FAvDBUqe2FAvAB0ud2lIsAB8s derVWP7e/J4O4eMGhdkATuApgv4lf4vFqxT0b4fQe7aBR/AQQYNBM9B0GwSF +3isoOVKIA/cx1MFzVnnHapOicDndLu1NUFpaT3Cqr+JTPvgYTxS0L+NUTE4 SP2rFNT3O7NJchic+Iif8OWRgm72/9TJihE0eZLfJrdgbWjdhRwmtM8zBd0y 9GxBk0V/q2vhuTxU0PVjUGGvVlnQ+Og0yIKfMPNUQTMW/MXZ5sfs8eTfEClf JGi04k9cCvBYQdfmbsRBMzfuHhBU2AY/IeAhgpZeSfQn5F48y426f8G68kki aQTFT/B5iqCl1+IGs57eedBc/mm5d26lpJ5wbjWuknlXmHiMoAA9YqlTW4oF 4IOlTm0pFoAPljq1pVgAPljq1JZiAfhgqVNbigXgg6VObSkWgA+WOrWlWAA+ WOrUpbG8vngLsmvSLIVVVGZLnwC8eaKgPw08KV6ZNdEW5YjZU/MRFDZ4sKCz DImggiaNC4rXVkHQz8NLXJNsUVlBeTYEBRkELRU0ODr1EuKaYE9ZPKZdsgVH vq9vsjiSlSrAAg8W1PMzlkkQVFjxEtb4y2JBPe9e0YL4eLhWOAS1ykMF9Uap QkGjxyXxKkuIT4Q1r2hB0OTdJPFAJzxU0PlP7Eqzgq6DgVZ5sKA/i8JBplBQ bxtlQeMFZSCoVRA0WFQoqJ95XVBhBiqtFEEhB4IGi8oErUhUCCqPumUgqFUe LGj+GFTo7tJcraTUK8z9GtKrIJJsU1ahOfB0niiocNAZHpBK2whnO8WTKf4J zmj8zJwuDTcPk7tw+3O7/LI9ZcNhniiocVyVRUHuX0Jatqds+HHgRbPUqS3F sh835DtEujzI/UtIy7bL7pZ8QNKautzTGpdkcNKDgKVObSmW3Tjvb7ouXh7k /iWkZdtld0t+pyBc44RlpeX8Pvey+yorOyaWOrWlWPbivH+5dZncnyc/gmVi omtc+NQVrHEr4QtrkqcuyBDuq6y9qJY6taVYduN+/0lrlr9i7l8fdPNTIYNr 2s/CfVIXmhKII6xZ/sm7EC5dE5UzfejJ+yqrOyaWOrWlWPbj5rc8We5/Ykej op8lKCFMOLnsRpA+mIT9VC9mJyenpy78hAp2LoIyp1fJRUX+7Aw2nT4HA5JS Jyx1akux7MYNOYl+3WTZW/tk/HW/ecmvDNlJd9csrjgMSkviXUthPzUYsNwU 1JLR359w856t51Hq5yxhNJxOZcx/pgzLsuljgBH0AQQf0dJqNwS9bOrCyyjh dVvvWbDndoehwjRour8p7WWGy+ZRMQjVLS+BMAwuZgWvWlDrtOPvjZJLNc5r ypQhqmbtZbXUqcNY/vviLciuWac4490ER4u5DEvv8HqFsIcVfKz7DxcJ6qLn 0QdPPgavrZGM01jnqftdMB93h8PgLG1obPRqublti5iLjMGEm5tq8/dVpjZk sCvoz6xFS8+0cM0GlYKWm39sm4Sg34gfyf4nvQt6rvAZ7u/bni1oWmYsYzjs ee0OlkUfKf4efaBsdMZjHj3DYXCIX6G5lKh5y37wVMVSVfCepJ8rqx+ob8wL OvuVCFpqXieCRuOJPGEyDF4/G4I+F/eSYMLWV1PfUPn8bDA0htOgwSIv5qDf T4Z4HzOTR8GAtUxee8NgdmROmhcUF+gcti7MIMQr8xhB/xuC0XQYzhL0JqJ+ JJ4PCceAdDwK84a91EW5FRE+HIKKvupEY/7PpHBcDSef5y3nhdOLEtTmwhcm MVL6+IgMTWNxfmI92KRBAQgabeMfnX4Twf5wus3amvyxbu4w+L//Ko+QZ5zX 1ZIuNOUIVoY9LFUk6qXRMKFG+vEgKRLNdfrTz4GAQ5BhCOKcR9hY0PAFiPPk HBNfkGjvWXJReP06FdRr3PhGTIjZP/hmxbu7fioh3KZSUN/vbDVBDcIu7p5R O5ojyo1LQ9oD5VHCz+POEzSzCxnsAUQnMOZF32HUW+aXkTTY//yKGhB7tR5k 0rykODFRuezLuqBZKwoTx/DKGb2/YcLPH6X9kahKUGHQrBhBkyf5bXIL1obW XXyK2OhzwhJ/JzPc31XECfvj8aTVVyKXLIr2AzJyJFoK+aJF6xGm00wH2Sno 6OXIK1Ikzw5864UGpZWsjKCRK3cLmiz6b3VtKWGfSabuK/tRfp5E39B0ABdk FP1zBYLOO8PCqtoRbaV5B9gn6Cg8TxUpk2cXsoLTR0GZoD+/wkO7jWNQYa9W WdD46DTIsntWan2ntbofxSOOt7+raaiLuntc+bAqaMkImlyiuCnoJsdLyBcX sGLSKCTGVJF84jBrgo6FI6joV1ZQf720P5zZRJiBSivN1hZl2T9rvL6bdqQb xfu7WoZOx5HCmsIRNHjyeEFHQZF84jBxKd7+81i6i1sl6Nqg+Z+4xSFBhW2O +Llh5KFutH5e8Eipbio0WiUJJe6lxg2TcqwcNO6Lo01BR38M204cRp7FHb1/ YfaZ//1j8xh0c3bVn8X9JGV3/vv9F5VRsFssjaB6fuYE/d8uXPDMeen9uLnc tDTnooxRNieulDaaV6SbyFWX4LKJfcRFLH05/34HGQIrChOHiWdx5+djvCzJ NAzCQWd4QCpWGW61nAf1C0m28dflKpWqkbbZfR5U+BiOZ0aV0Bs/h6tG0OzG jYyg+SK2R9B5v7Jm8FQWNBrMM1PFSmd3umVdUOVpHY1S1vaXywX1j1BXJMxJ 2b2gk3FjdeIwGUFHYaFepf2yPhWqKGjtJFEmrzfbpCBoXM7qjFkuXzHtCTrW Jw6TG0EzdSDo2hJNQX/lFRaZPW26nK85W9CVCTMrgu5IHEYWNDtII+jaIm1B i2+vsHLIuvL9VSc1fb+gQptK8pUUoHY8LrLWqQMR9iSO4U9RhVNahdfiPo1V QdX9LJ0ryg2Rn6XC0BivGjYF9VryLEF3XX6reC1uLQgqLMorcLi2IkPz00DD 6udH+o3tAUE7x1Ise5De5I2boByrrNDQ7KWBK5o40V4E7RpLsexBGkFXpmGO 11Y2T5S/VyeCbpdhqVNbimUPwoHc0tNPOQYtOh2an0zSElTcT0DQ5rAUyx6E 47j5n76f4WHiejYtQXMHrfPXYRC0ZSzFsgdxBC2dzNlVYdEAOv8R1wjPf+ka QS8fQRVKyBUXYqlTW4plD9Ix6PTvFEHLDkGz+dQEXY5yEbRlLMWyg4wE4k1v T61TyHFIUMkFl+SNPwgQtDksxbKD/EzpeYaWCipmVBLURf9Kmoagd2Aplh1k 3+OVM5HnVTrVnM/nVlKBbQUj6PQXQVvGUiw7yL3HwuhyfqW/lSvX8ukJ6mfO zCKt1I2gl2Eplh2sjKCrq8+p9LvuGkHFkRpBm8NSLDvI95PTxs+CWvOGKgoq LUfQ5rAUyw5W+slps7h5ZeI966QBOcXCraNV2drS5QjaHJZi2cHG3ubJtW79 xBCClhYXYqlTW4plB+dJWFCttBcdzh3H10ogaKa4EEud2lIsO7hTUHEeKrxK fuW2QJkkgg62OrWlWHZwo6DR8ea8wu/FYXJrlzenfX7OKVq+/mog6B1YimUH Nwnq/Tb1yhDpImHTi4NvEnTvq4ag9ViKZQe3CTr8LkgI+2ziVbjXiqDZ8gIs dWpLsezgrl3caXD0Zm3Tr4CGI6gThlAEFbHUqS3FUs99h6Bu/vlN72fpU/+C ixbiIbZS0GywCNowlmKp5x5Bo33Xz9NJ1ShncNlfMqWEoDKWOrWlWOq5bwQd PG8+g6eLD0n9PAMj6EZ5AZY6taVY6rlvjigaP39D5doskPij92kKQW11akux 1HOXoL5rP6Ok8TNcIvzoPYKKWOrUlmKp5zZB477qpCPQQRZtY332SPWooMX5 tgtA0GIsxVLPfYL6ZH+QF0GLywuw1KktxVJPG4KuNANBC8sLsNSpLcVSTyOC 5lERVDouFUtB0PawFEs9pgT1p4WlXAjaI5ZiqQdBgzXXCarzwiOodRA0WIOg 7WEplnqaF1QycGM1gprq1JZiqad7QYXDOgQ11aktxVJP94L6VxctmsUZEbRf LMVSTft+bggaXJ+7IehKsAjaLpZiqaZ3Qd30f7AaQS11akuxVNOXoJKf/hHn YUG3Xg4EvQFLsVTTuaDaIyiCNoilWKrpXVDlY1AEbRBLsVTTvaCFs7jSqReh EgRtEEuxVNO/oNJ6BLXUqS3FUg2CBluWCrr/ZTuseKa4CEud2lIs1dgUVJ5N QtA+sRRLNTYFzdy7CEG7xFIs1ZgUNHf3P4OC5oqx1KktxVKNAUGTiZfw3Ki3 ai1Y5/3dbguCXoilWKoxKKgbJB0RtFssxVKNQUFl1xC0WyzFUksHftYLKsqI oN1iKZZabAqaOQ+6GiyCNoulWGoxKqh8HhRB+8RSLLVYFVTMhKB9YimWWp4j qLTbmxaCoA1iKZZaEDTcdPP1cMHDDhC0Gkux1IKg4aYI2iCWYqkFQcNNEbRB LMVSiy1BNwxE0D6xFEstPQi6OULqCbr9ciDo9ViKpRYEDbZF0BaxFEstCBps i6AtYimWWhA02BZBW8RSLLUgaLAtgraIpVgq6cLP7dMoRdf3NCao1kuPoJZ5 lKDrwSJos1iKpZInCboVrNvOMiDoHViKpRIEDVcjaItYiqWSzgTNNRdBEyx1 akuxVPIkQYV75SaFlAp64HVD0GosxVLJgwSV7pWbFIKgLWIplkqeI6ib/l+t BUFbxFIslTxGUDdsGoigrWIplkoeI2iBWJ0KminIUqe2FEslzxF02z8EvQyv ceMbMSFmfxoPEnRrjug5go4TXjJYt504hlfO6Dc2SPj5dartkScJqnketG9B hZSkSJE8O/Ct9x/HaOEQ53og3zf3D0zgv7OlguYVKZNnF7Gg45gkxOyP4+fn za3YRGkELajleSNoXpEyeXYRCTr6HwIjI+gCgkaFPFVQSZEyeXYRCjr6o/Qo NP3hgjbvpy1Bp21vnyTy8omKlMmzi0DQ6V+YEBr8j/89DPfv39/djdjGJU8y ObLrC2sp2N4drkijrUJ5X5a+XGhJXpEyeXbhC5r5MBCzP43P5ePtD6DbI6jK qLRxJWBQU9cjaJClcvBUF9SbHQ4SYvaH8bl8vAM/EbSkvIhyQXOKlMmzi0XQ YEd7jNYm2Z/Fp0P+9XAmFEELyosoFjSrSJk8uxjjJ2OSELM/is+cyF8f1yps TgKpdPqtS428OroWNG9FYeIwY/RsFBJi9kfhPoL24CeCFpQXsdap81YUJo5R fTnhQwV97+D24WepoAeDeYyguy6/VbwWt5anCvpvAO3DTwQtKC/CUqe2FEsd PUzhvkHQ7fIiLHVqS7HUgaBhIQjaJJZiqaKLk6BvEHS7vAhLndpSLFUgaFQI gjaJpViqQNCoEARtEkuxVIGgUSEI2iSWYqkCQaNCSgU9ekmh93AcBDULgkaF IGiTWIqlCgSNCrlQUL1LRBDULL0JutKpDx8ZDgjaLJZiqaIXPxG0oMAIS53a UixVIGhUBoI2iaVYqkDQqAwEbRJLsVSBoGEZRdsj6OVYiqWGbuaILhK0bHsE vRxLsdSAoHI125kQ9FIsxVIDgsrVbGdC0EuxFEsNCCpXs50JQS/FUiw1IKhc zXYmBL0US7HUgKByNduZEPRSLMVSA4JGZRSdZ0HQy7EUSw0IGhVRdKUCgl6O pVhq6EfQ7U59XFA3/V/QFAS9FEux1ICgUQFF7iHo5ViKpQYErarCy4egl2Ip lgpcP9fiXiFosXlFO8Ib9SBoDZZiqQBBkzJKz7Mg6KVYiqUCU4Ie1marfL2a ELQWS7FUgKC724Kgl2IplgoQdHdbjh/sImgFlmKpAEF3twVBL8VSLBUg6N62 HJ6MGhC0BkuxVNDRaVAE3SwvxlKnthRLBQi6ty0Iei2WYqkAQfe2BUGvxVIs FSDo3rYg6LVYiqWcnuaIEHSzvBhLndpSLOUg6O62NCaoWJalTm0plnIQdHdb EPRaLMVSTn+CrvZpBA2x1KktxVIOgu5ui4Kgqm1FUIsg6O62IOi1WIqlHATd 3RYEvRZLsZSDoLvbgqDXYimWcowJetybUhD0aizFUg6C7gRBr8ZSLOUg6E4Q 9GosxVIOgu6kOUHFn6yw1KktxVLMv/e0I0ELOvVjBZV/ssJSp7YUSzEIur8p TQnq5BlsS53aUizFIOj+prQkqBvkAi11akuxFIOg+5vSkqCMoEZB0P1NaUpQ jkFtgqD7m9KWoMzimgRB9zelMUE5D2qRrk6DFgl6kZ/Ha0LQSizFUgyC7gZB L8ZSLMUg6G6OVoSglViKpRgE3Q2CXoylWErpbI4IQbcKjLHUqS3FUgqC7gdB L8ZSLIW8T50ZE/SqsywIejmWYinjc/EJgu4EQS/GUixFOIu7uAgaYKlTW4ql hF8H+busRyuAoBsFxljq1JZiKYIR9BAIejGWYinjPeNp7RhUvGT8lKYcrkj6 etjB8hIsdWpLsRTizF2oIH/p6pSWaFwtj6AVWIqlEGdtF9fpd/vzKkLQOizF UsbnHe1N0A0/9Q/tTqsIQeuwFEsZ5gT9rbxmBD1cEYLWYSmWMuwJes34qVQR gtZhKZYivm+oLUGvmiPSqAhBF8Y3YsLLc2WDWsCkoP2cB1X/LNklqGxFYUKN 0W9LkJCa+hQ6FPS6AfICWhB0li2vSJE8xwgaMUYLk1xP4fd+IuhdNCDoGIon KVImzzGkOtJxGkE7AEHXyktZ79RjNDL+rChM6CEIOjKC9riHi6Cr5aWsdupx iAQdBUXyCUXG+O8oNP1hgnY5gCLoeoEJa506GBN/f8aKhCbe3NPo/UvzfPjf E3Dfh797W1GLm9ptAPVYluKWvrzihPc3tKIwoUg0ggbHu1Gmx8AIejc3j6CB w5WD57nHoJmp4kcJOn9XCkFv4+5dXD9DYEVhQo9Q0GhiOcn1BJa+gaC30ZSg wbFoWUKPslM5DxLULUMogt5GU4L6ycKEIsnxsFTFcwT1v8yIoLfRkqArihTJ cxSuxfUIvsyIoLfRlKD3XotbxGMEZQRtgyYE7QhLsWzg3VAHQW8DQeuwFMsW jtMs94OgdViKZZP5vUTQ20DQOizFsgmC3g+C1mEplk0Q9H4QtA5LsWyCoPeD oHVYimUTBL0fBK3DUixbLG8lgt4GgtZhKZYtELQBELQOS7FsgaANgKB1WIpl CwRtAAStw1IsWyBoAyBoHZZi2aJfQe34iaCVWIpli17Pslz4yw7ng6B1WIpl CwRtAAStw1IsWyBoAyBoHZZi2QJBGwBB67AUyxYI2gLaM14IagYEbQEErcJS LFsgaAtox4KgZkDQFkDQKizFsgWCtgCCVmEpli0QtAUQtIomY3mdUmq3V/p5 tyM0AIJW0WQsCBrg9E8e3giCVtFkLAjq498S3wAIWkWTsSCoR/CjMgZA0Cqa i+U1oV5yp4L+2m3FTwSto8lYGEEDLI2fCFpJk7GcMHwOHQtqao4IQetoMhYE jTDkJ4LW0WQsCGoYBK2ixVhe5xyEImgLqF90gaCX8zpnmghBG0D/ogsEvRwE NcsJF10g6OWcLSh+3sUZF10g6OW8hlMMRdD7OeGiCwS9HAS1i/5FFwh6OQhq GO7qV0eLsbzmP5owR9QGnAetosVYvoJqG4qgNkHQq/maiaBQBIJeDYJCBQh6 Na/gQQ0EtQmCXs3rnG9tI6hNEPRqGEGhhtTQBjv1bhqMBUGhBgS9GASFGhD0 YhAUakDQi0FQqAFBL+YVPSqBoEZB0Gt5JU904Fp5oyDotSAoVIGg14KgUAWC XguCQhUIei0IClUg6LWcJCiTuFZB0GtBUKgCQa8FQaEKBL0WBIUqEPRSXsIz DZgjsgqCXgqCQh0Ieikv8elxENQqCHopCAp1IOhlRLciQlAoAEEvhREU6kDQ S0FQqANBLwVBoQ4EvRQEhToQ9FIQFOpA0Es5W1D8tAaCXgqCQh0IeiknCcoe rlkQ9FIQFOroWNDxH/5zoeHNxfLKPD8IgpqlUtAxa0VhQo9x/jM9pJUgKHRO naCBCHsSeozC86SS1gR9ZRPHQFCzVAkaiLAnoccoJNJxGkGhc3YdgwZ7lzUJ PQRBR0ZQBDXHUUHHqoQeqaAju7j4aY89gnpHlaNv63ZCj3H05p5G75+U6x// a4JXNnEM93v80ysS2mB6a/+39OVNMQQrChN6xDNQwfFunKsZGEGhkkMjaM3g edIu7q/szFQxgkLnHDkGHasTeoSCjuHCJFcryIIeNxVBzXJA0LE+oUfZqRwE hc7p9TxoOC7nBun2BX35T3aDoGbp9kqiossJmxZ0lhNBIUu/1+KW0IGg0c04 94GgZun42ywFtBaLKOi/x8+f/eCnXRD0SiJBE3YWi6B2QdArSQTVOQZFULsg 6JV4P27mDZpfQQ8YiqB2QdArkWdxvwkEBQEEvZI1QX9PE09f0sIA537vIoLa A0GvJBU0SIoubgrqPv+9QVB7IOiVrAo6zAekwTVGW4K66X8EtQiCXsn6ruou QZ33D0HtgaBXsjERFJwPDa8zyp8kZQQ1DYJeyYqgvom+oL/HlUIdfhoGQS9k 60xKMmjOZ0o3Z4neIKhFEkMb69SHaCyWIkEH8Rh0awh9g6AWQdDrOCBo5Kj/ 3E1L/lR/MA3aAEGvo0TQ+TGavX3Fxs5PENQ0CHodpQJJgoYnYbwcbk4gqEUQ 9DoOCYSgzwRBr2O/QOGUbvBNGDckk75wFtsXRquDoNdx7K1NT8AsJ05f3xEU O0+m5NpLZRD0Og4KOki7uIulf4e+smYatdcFQXVpLJYzBHVz4u8z03th1ymv ajvnK3myryZ5u4rtNy6XHqLXX52k0GRBY536EI3Fcoagg7KgwfiQTQQdVDpt G65NpqXlTYb4iThg5c4Ub1UXb7L+ggqvcHykX7u91KAg7Oz2AY116kM0Fsvx j1yxL/4WfC4kKtjLzefI9/Z47RFBKwU7KqjWgqX0+HY1lYImr9D6a4ig13Fc 0Ii/D6/vQyRotjL503t6Yk/QfT6tCPr598pfOYKgxTQWi7agf9EMQrIDVtaK PYLGvX5F0G1BpO8HpGuTFm4I6s1xf7Yu8GktqPA1kII6LmhSvx/7RGOd+hCN xaIs6N9ynbxQx7agr2RBJTs2WStraoNU6M4Wfk9BvSM82j7pA0KjxO1y4vev sU59iMZi0RX0b/mmtl9Hol24Nupt86O/ZmUEzW8/xN03LmN1OBQ+JPy1S2Gv lUE7X51UaMmQKpW+HvLGCJpp0MasU0BjnfoQjcWiKuj7kHO614lfR+xBUmmg sGzMyy/Lb31WwVJBVxesZPdatGv74wuWUFdfkA1BgwVzMK+N7QMa69SHaCwW TUH//Hud+HXMXfklv8GvUFBvwTK+BAuStYPXwYZhWOlcQ7xgt6DDK/3UKd9+ ELPfLuiw3C8DQVtAUdDv+OmEO2L8annNb3+8+uV39t9PN01rqgRdahoynct/ PCLo8O3NJbdVO1L/6mdKWJhUaL2g0Y/bZesPaKxTH6Kx2bXzjAAADrRJREFU WPQE/d48waVzRMP81vr92av95X1wv/zk4F/k8Er+Sp30FaWFdghr5fxJ50wy rF6Gsa7QSr1FaJQhFJabBpKzTzTWqQ/RWCz6gsrVfMWLZwK/Xf/1yzEPpN9P 8qjz+x/osaBRrmpB13KvZJ/32dc213yNLyk9+3mU1j3RWKc+RGOxqL29v7sP yX56vzb6HSj9/aWfNfFU0rKf6zU1cEZq+3WCbg42CNolbcWiPYDmBQ33F1+h oMk5h3Abf0uv3fcKul3SqyjXThD0JNqK5SpBoxMpvpJJN37FmyzLwzwIekrp 2wUi6GVcImh62Jk5N+61SdqB9FJZQVfWDDcJeoqfZ5deUvVCW536GG3Fon0I mh9BxQXJXqv8ZEqHgsptX91BQ1DNqhfa6tTHaCuWFgXNbtOeoOduf2fpJVUv tNWpj9FWLA0JWrrN/BRBTyy9pOqFtjr1MdqKRevt3fJzRbZCQaODUgRF0HNo K5bLBFUhGEEzTd8elMtjrvM5szmC9kVbsfQraO4CAQQ9HwS9DHuC5sfWqQQE Vap6oa1OfYy2YlF6e+dfGbxM0PytyBD0dBD0MvoS1GdlIkhX0P0vEYL2SFux 9Cno6nXqCHo6Lq60rU59jLZi0Xl7l9/RZgSNN0fQzmgrFmVBr/MTQRH0HNqK xaKga7cDuFTQo5NMJYUjqDZtxWJQ0PWYqn4pBkFlEPQyVN7eOw5BV0DQs0HQ y1he6b8DzIUYE7RyjzjTEgTtirZimV/pv7VcxdwuaMGNghD0MAh6GdMrrePn /YK+YQQ9GwS9jN8rreQnggotOcsgBD2HtmL5vtKm/HyKoOeOz6sg6FXo+omg UksQtC+aiuXzQqv52YigqyCoAgh6Fe8XWs9Pk4IeEQBBO6SpWF6qfvYgaF2H RlARBL2Kl6qfCCrVhaB90VQsL1U/EVSq61xB7/ATQa/iT/ft7cHPyh5dd8gq 1oWgfdFQLH/Kb2/zgpb9PG2wxbGX6OAs8HbhCKqOcizHrnF/mKBvrhxBEbRD dGM5eAyJoJu5ETRXtQeC5kDQWhBUq2oPBM1wxM/6A7ItEFSqDEH7QjOWwydJ HjiC1oGg+ao9EFQGQc8GQfNVeyCoyHE/Vd9eg34i6ErVHggqcfwqIATd4uAr hKD90ZSgCq1YsCjowZfo4KWCm4UjaD1zW8c3K+uPonAZLYJugqDZqj1WO3Ug wp6EKnOxo/c3yKBVE4JeAYJmq/ZY69SBCHsSqoxhFUIlWrVqfA8FQTdpWNBz j3A3a/ZZ6dSBCHsSqozRZ8CQjtMNCar85iKotPXTBQ2yBFYUJjQZhyEepJ8j qDMn6PFrrRA0zBJYUZhQJLD/9+cxgjp7gr45+BodPI+6VXg/gnpHlaNvynZC j+Qw1xtQvVwz/zvC36Gtv7wUyphwn//scfA1eqm+yEnhuu9hXc3/WPryqhdL hsCKwoQeQWuDD4Mgl05ljc0Ruel/azCC5mr22Z7FnZ/XDJ6nnGiZPysyU8Xt CKrr5/zPFgiaq9mnYBb3lwh2dYsS2kQzUCcJ2tgAancEPQiChoIGMzRlCW2i sh8i6GcOFz8TEHSUEhunPrPyaBAWnlZhVNB/duJnCoKOQmqsSigzl3rqtbgN CoqfAggaTfTefi3uJirVtucn46cIgnaHUUHxU+RsQe/xM7nvJoJGIGgnIGh3 IOiTQNDu0IhFxU9ud3IBCNodCPokdF/luHAEPYFmBFUoYwFBZRC0OxRiUflR TwbQS0DQ3mhBUPVffUDQHAjaGy0IOnAIehWnGnTqFNQaCLqKxi8+IOg1IGhv HI9F44bVqm8tl+HmQdDe+O+/Iz+K/ftl7IO8VI9e+B7LCgjaG+M/RQG6J+zU drg7Fu0ZXO6lkEX/J5LjChhB9WkhFu5GdBns4vZGA7Fojp6/++HiZwYE7Y0G YtES9DM7hJ+rIGhvNBCLkqDf8ZNZ3FUQtDfuj0Vt/GT/9mYQ9ATuj0Vx/Byw 804Q9ATujkVxhgg/bwZBT+DuWHQEZfxsAQQ9gbtjURHUzf/BjSDoCdwdi46f jJ8tgKAncGcsSteefd3EzttB0BO4O5bjbynjZysg6AncHYvCW8r18Y1w6i3J 1kDQ89CbI4K7QdATuDkWrbMs+NkCCKrP3YKqlMJNTtoAQfWxIahKKXAUBNUH QUENBNXHgqD42Qh3CRpXjKBqIKglEFSfe2NhD9cUCKoPgoIaCKoPgoIaCKqP AUHxsxUQVB8EBRVOvy32auVhEkG1QFBTMILqc2ssHILaAkH16V9Q/GwGBNUH QUGN2wSNrvVDUCUQFFRA0HNAUFABQU9B6Zab8HgQ9BQYQEEHBD0FBAUdEPQU EBR0QFB11K4MQ1BA0FNgjgiUQNAzQFBQAkG1eSn9UAA33IQBQXV5DT87NX6X BUEBQXX5CKoyOcRvPsAHBNVERdCfm/xqEgwIqovGGZbf7w06fncQBgTVQ/E3 e//Z6ebn8GgQVJHXd5KoHhc8c47f7YUfCKrFa5egv5HSN5Q5IlhAUC1ev9Of VYJO00G+oYyfsICgGkyzt7W7t9MO7eD56Bg7YQFBNdh5emWaEPJnbDm7Aj4I qsG+Gdzv+Om++7TOWwgwgaAavNXcMXvrln3c6bQKfkIAgh7lyPlPN10x5L6H nlwgDxEIqsD+859uHjqXy4cAFhBUgQMXKIQnQJnAhQgEPc7ur3+66DmnPyEG QQ9y5PvZLk3gJwQg6EEO3D3BpUn8hBAEPcjeb68Ih5scgUICgh6kXtDp+vjU RvyEGAQ9wK5ToPPtEtARtulU0PGNmPDynFa795pVD6DetUMYCpvUCeqtzitS Is9BRr81QSLJdAav5V+toNL18QBZqgT1VMsrUiTPMUb/cYwWJrn0WQTdmsMN zp1MX/R03NEESqkR1B8Y/cfChD5+Hek4fYGgW18BXW6PMD38hk7GTyhj5y5u YEVhQh+vjvGqEdSfGNrav13s9AbPKYWfUMAhQUdBkXxCHW//ebx2F9cnn83f v/0NnM4bTwG2OSLo6I9h2wlNvLmn0fuX5vnwP11er/ef37887v0v4LvQKTcH LOM+nWzpyxte+E9mKwoTiozh8zFelmRS5eXN4q7h3x4+vvMQQBH7R9CawVPZ lTFMZKaKzxL0NRQKOix7tNypD/axW9DgALAooUco6CgsPKHSmdf8d/McaDqL C1DFXkF9KwoTeoxS4hpB6768Eu7Y4idU48IOV3ma5abzoKOQSqu4X1CMhKPs FDS0ojChRjSldeW1uFWX9iEoHMaVC7rn8ttzrsUtAkHBABWCdoZ6LLXfLsNP OA6CVsEACteCoDWwhwsXg6A11AiKn6AAgtaAoHAxCFoBO7hwNQhaAYLC1SBo BQgKV/MgQYPr21/SmjmHsNb5iyX7gituuakm6PBEQUUfswu+T9y/V+r9JPhi SvjXW8U3V0AJBN1a4P7JOd8jbLrtdHC/Ie+XyeYFDKGgAoJuLHh/ncC5n6Dz LfliO+P7JvBr9qDDQwR9iWRXyGvdctvp6d62s5kxA4aCBg8RdJriWXFx8EfQ SEznP4889W1ND00BDvEMQd/7oJ9DSP+g0k2zP0vi9/3Yec1779b5az+FBXu1 c/nhMSh+ggqPEPQjzOunn/t56LxpoCnxcdJb8x4wv1mnNd5tp+MZImZxQZ8n CPqR5fUdON00errZx8+TYZ6rHZY1n1y/Afc3tvq3nY5miLzK8BM0SL6CbFLQ z/Gn86Z4Xr+Dxs/0rPOOKufsw3fN19ZJttey1isZGeFMHjKCvl7h7KucEKZ9 7mg5wMwDBP3snr6Cc5Uu3EkV52CZ6YEGeISg3+NIaYonvDZInPYBuJEnCDof aQtTPOHVteK0D8B9hJ3QqqDTx5AwxRMmMBPawrigtbfKBGgL44K+mc5hAvQH ggI0jH1BXy+OKaFbEBSgYR4gKLOy0C9PEBQ/oVvMC8oACj2DoAANg6AADfMA QfET+sW6oAyg0DUICtAwCArQMAgK0DDGBcVP6BsEBWgY24J+buZ3d0MA9mNd UO78BV1jXFDHvfmga4wLOt9NE6BL7Arq3S8MQ6FX7ArKCAoGMC4ox6DQN8YF xU/oG9OCchoUese2oBx/QucgKEDDGBcUP6FvEBSgZYIujKAAbYGgAA1jWFD8 hP5BUICGQVCAhkFQgIaxLCh+QvcgKEDDIChAwyAoQMPYFRQ/wQAICtAwCArQ MAgK0DCGBb27BQDHQVCAhjEr6AtBwQBWBXUtHIK28Ho20IYGmtBvG4wK6pq4 VL6F17OBNjTQhH7bYFNQ18Yt/Vp4PRtoQwNN6LcN/Qs6vgkXeT+cdCstvJ4N tKGBJvTbhnJBBRFaYPT+zjCCzjTQhgaa0G8bigUVRbifMXr8wTHoRANtaKAJ /bahVNCMCLfza08ytjOL+6OBNjTQhG7b4IJfF9oWtLmd3GlgT9p19/HnmxZe rAba0EATem1D9PuZm4IKItzM+PuTtKuFhtKGVprQaRtc9AvUW4JKItzM6P0L VwB0jvP+fdkhws2My2cHgDGc93eDVkUY551vAHO4ofRsYasiTKN+a+0C0MCV ni1sVYRWT/8AqFB6trBZEdoc2AEuplkRNma3AJ4BIgAAAAAAAAAAAAAAAAAA 3E0LZ25baMObu9vQwMtw91vh1X13U9qghWufWmjDpwU3N6GBb0Ld/VZ4b8Hd TWmDFq4ebqEN3/pbkKOJJtzVFG/IvLspjdDSXZTuH79ubUFLb8GNQ2j0pIme eSMt3UXp/vELQaPH+1rQVM+8kYbuonS/nwh6/4FfKGgbPfNO2riL0v3zdbd3 zPkGbnc2Ybj/rQgEvb9n3k4Td1Fq4D0ouCPc6U0IHm5txP2vQiM9835auItS O29BEx9TLbwVTRyD3t8zG6CFuyi18xYg6O1tWARtoGc2wP3vSEtvAYLe3gbO g0Y0sB/Rzlvw8OO/FtrAlUQxd0/bNTFBM7Xk5uobeBHubUNQewsvBwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAQDn/B4vl715W9/02AAAAAElFTkSuQmCC --=====================_26925641==_ Content-Type: text/plain; name="ok.txt"; x-mac-type="42494E41"; x-mac-creator="74747874" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ok.txt" IyAgICAgICAgIHRpbWUgICBNQi9zIGF2Z19sZW4gbnNlbnQgYXZnX3dpbiBh ZHYvc2VudAogICAgICAgICAgIDAuMCAgICAxLjQgICAgIDE0NCAgIDk2MSAx Nzg5Ni4wICAgMC4zCiAgICAgICAgICAgMC4xICAgIDguMSAgICAgMTQ0ICA1 NjIwIDE3ODk2LjAgICAwLjEKICAgICAgICAgICAwLjIgICAxNC4yICAgICAy NzEgIDUyMzUgMTc4OTYuMCAgIDAuMwogICAgICAgICAgIDAuMyAgIDE0LjAg ICAgIDI3MiAgNTE1NiAxNzg5Ni4wICAgMC4zCiAgICAgICAgICAgMC40ICAg MTQuMSAgICAgMjcyICA1MTc4IDE3ODk2LjAgICAwLjIKICAgICAgICAgICAw LjUgICAxNC4wICAgICAyNzIgIDUxNDUgMTc4OTYuMCAgIDAuMwogICAgICAg ICAgIDAuNiAgIDE0LjEgICAgIDI3MiAgNTE5MSAxNzg5Ni4wICAgMC4yCiAg ICAgICAgICAgMC43ICAgMTQuMCAgICAgMjcyICA1MTMxIDE3ODk2LjAgICAw LjMKICAgICAgICAgICAwLjggICAxMy45ICAgICAyNzIgIDUxMDkgMTc4OTYu MCAgIDAuMgogICAgICAgICAgIDAuOSAgIDE0LjAgICAgIDI3MiAgNTE1OCAx Nzg5Ni4wICAgMC4yCiAgICAgICAgICAgMS4wICAgMTQuMiAgICAgMjcyICA1 MjA0IDE3ODk2LjAgICAwLjIKICAgICAgICAgICAxLjEgICAxNS4xICAgICAy NzIgIDU1MzIgMjA3NDMuMiAgIDAuMQogICAgICAgICAgIDEuMiAgIDE1LjMg ICAgIDI3MiAgNTYzMyAyMTc2MC4wICAgMC4xCiAgICAgICAgICAgMS4zICAg MTUuMiAgICAgMjcyICA1NTc1IDIxNzYwLjAgICAwLjEKICAgICAgICAgICAx LjQgICAxNS4zICAgICAyNzIgIDU2MzggMjE3NjAuMCAgIDAuMQogICAgICAg ICAgIDEuNSAgIDE1LjIgICAgIDI3MiAgNTYwNiAyMTc2MC4wICAgMC4xCiAg ICAgICAgICAgMS42ICAgMTUuMiAgICAgMjcyICA1NTk5IDIxNzYwLjAgICAw LjEKICAgICAgICAgICAxLjcgICAxNS40ICAgICAyNzIgIDU2NTQgMjE3NjAu MCAgIDAuMQogICAgICAgICAgIDEuOCAgIDE1LjMgICAgIDI3MiAgNTYxOCAy MTc2MC4wICAgMC4xCiAgICAgICAgICAgMS45ICAgMTUuMyAgICAgMjc2ICA1 NTM3IDIxNzYwLjAgICAwLjEKICAgICAgICAgICAyLjAgICAyMC4wICAgICA0 MDAgIDQ5ODggMjE3NjAuMCAgIDAuMgogICAgICAgICAgIDIuMSAgIDE5Ljgg ICAgIDM5OSAgNDk1NiAyMTc2MC4wICAgMC4yCiAgICAgICAgICAgMi4yICAg MjAuMCAgICAgNDI5ICA0NjY5IDIyMzgzLjcgICAwLjMKICAgICAgICAgICAy LjMgICAyMC45ICAgICA1MjggIDM5NTcgMjMyMzIuMCAgIDAuNQogICAgICAg ICAgIDIuNCAgIDIxLjAgICAgIDUyOCAgMzk3OCAyMzIzMi4wICAgMC41CiAg ICAgICAgICAgMi41ICAgMjMuOCAgICAgNjQ2ICAzNjczIDIzMjMyLjAgICAw LjYKICAgICAgICAgICAyLjYgICAyNC4wICAgICA2NTYgIDM2NjQgMjMyMzIu MCAgIDAuNQogICAgICAgICAgIDIuNyAgIDIyLjcgICAgIDc0MSAgMzA2NSAy MzIzMi4wICAgMC42CiAgICAgICAgICAgMi44ICAgMjUuMCAgICAgNzg0ICAz MTkxIDIzMjMyLjAgICAwLjcKICAgICAgICAgICAyLjkgICAyNS4zICAgICA4 MDMgIDMxNDQgMjMyMzIuMCAgIDAuNgogICAgICAgICAgIDMuMCAgIDMyLjQg ICAgMTA0MCAgMzExNyAyMzIzMi4wICAgMC42CiAgICAgICAgICAgMy4xICAg MzMuOSAgICAxMTY1ICAyOTEyIDIzMjMyLjAgICAwLjcKICAgICAgICAgICAz LjIgICAzNS4xICAgIDEyOTYgIDI3MDcgMjMyMzIuMCAgIDAuNwogICAgICAg ICAgIDMuMyAgIDM5LjYgICAgIDg3NiAgNDUxNiAyNTYzNy42ICAgMC4zCiAg ICAgICAgICAgMy40ICAgNTIuMCAgICAxMDQyICA0OTg1IDI2Mzg0LjAgICAw LjMKICAgICAgICAgICAzLjUgICA1Ni4zICAgIDExMzUgIDQ5NjAgMjYzODQu MCAgIDAuMwogICAgICAgICAgIDMuNiAgIDc4LjYgICAgMTY0OCAgNDc2OCAy NjM4NC4wICAgMC4zCiAgICAgICAgICAgMy43ICAgODMuNiAgICAxNzY4ICA0 NzMxIDMzODExLjIgICAwLjQKICAgICAgICAgICAzLjggICA5OS4xICAgIDIx NjUgIDQ1NzYgNDkzNTEuNCAgIDAuNAogICAgICAgICAgIDMuOSAgMTIxLjkg ICAgNTQzMiAgMjI0NCA1MDQzMi4wICAgMC41CiAgICAgICAgICAgNC4wICAx MjMuNyAgICA4NjE3ICAxNDM1IDUwNDMyLjAgICAwLjYKICAgICAgICAgICA0 LjEgIDEyMS40ICAgIDg0OTkgIDE0MjggNTA0MzIuMCAgIDAuNgogICAgICAg ICAgIDQuMiAgMTE3LjUgICAgODI2NyAgMTQyMSA1MDQzMi4wICAgMC41CiAg ICAgICAgICAgNC4zICAxMTYuMyAgICA4MTU1ICAxNDI2IDUwNDMyLjAgICAw LjUKICAgICAgICAgICA0LjQgIDEyMy40ICAgIDg5MDkgIDEzODUgNTA0MzIu MCAgIDAuNQogICAgICAgICAgIDQuNSAgMTIyLjUgICAgODg5NSAgMTM3NyA1 MDQzMi4wICAgMC41CiAgICAgICAgICAgNC42ICAxMjIuNSAgICA4ODk1ICAx Mzc3IDUwNDMyLjAgICAwLjUKICAgICAgICAgICA0LjcgIDEyMy44ICAgIDg5 NDggIDEzODMgNTA0MzIuMCAgIDAuNQogICAgICAgICAgIDQuOCAgMTIyLjIg ICAgODk0MSAgMTM2NyA1MDQzMi4wICAgMC41CiAgICAgICAgICAgNC45ICAx MjMuOCAgICA4OTQ4ICAxMzgzIDUwNDMyLjAgICAwLjUKICAgICAgICAgICA1 LjAgIDEyMy43ICAgIDg5NDggIDEzODIgNTA0MzIuMCAgIDAuNQogICAgICAg ICAgIDUuMSAgMTIxLjcgICAgODkyNSAgMTM2MyA1MDQzMi4wICAgMC41CiAg ICAgICAgICAgNS4yICAxMjMuOCAgICA4OTQ4ICAxMzgzIDUwNDMyLjAgICAw LjUKICAgICAgICAgICA1LjMgIDEyMS4wICAgIDg5MjkgIDEzNTUgNTA0MzIu MCAgIDAuNQogICAgICAgICAgIDUuNCAgMTIzLjggICAgODk0OCAgMTM4MyA1 MDQzMi4wICAgMC41CiAgICAgICAgICAgNS41ICAxMjAuNCAgICA4OTI1ICAx MzQ5IDUwNDMyLjAgICAwLjUKICAgICAgICAgICA1LjYgIDExOC4yICAgIDg5 MDkgIDEzMjcgNTA0MzIuMCAgIDAuNQogICAgICAgICAgIDUuNyAgMTEzLjUg ICAgODkxMyAgMTI3MyA1MDQzMi4wICAgMC41CiAgICAgICAgICAgNS44ICAx MTQuNyAgICA4OTI3ICAxMjg1IDUwNDMyLjAgICAwLjUKICAgICAgICAgICA1 LjkgIDExMi45ICAgIDg4ODYgIDEyNzEgNTA0MzIuMCAgIDAuNQogICAgICAg ICAgIDYuMCAgMTEzLjMgICAgODg4OCAgMTI3NSA1MDQzMi4wICAgMC41CiAg ICAgICAgICAgNi4xICAxMTUuNSAgICA4OTM4ICAxMjkyIDUwNDMyLjAgICAw LjUKICAgICAgICAgICA2LjIgIDExOC40ICAgIDg4ODYgIDEzMzIgNTA0MzIu MCAgIDAuNQogICAgICAgICAgIDYuMyAgMTE0LjIgICAgODkwMSAgMTI4MyA1 MDQzMi4wICAgMC41CiAgICAgICAgICAgNi40ICAgNzIuMiAgICA4ODk5ICAg ODExIDUwNDMyLjAgICAwLjUKICAgICAgICAgICA2LjUgIDExMy41ICAgIDg5 MzggIDEyNzAgNTA0MzIuMCAgIDAuNQogICAgICAgICAgIDYuNiAgMTE5Ljcg ICAgODkwOSAgMTM0NCA1MDQzMi4wICAgMC41CiAgICAgICAgICAgNi43ICAx MjEuNSAgICA4OTI2ICAxMzYxIDUwNDMyLjAgICAwLjUKICAgICAgICAgICA2 LjggIDEwOS44ICAgIDg5MzAgIDEyMjkgNTA0MzIuMCAgIDAuNQogICAgICAg ICAgIDYuOSAgIDgyLjQgICAgODkwMyAgIDkyNiA1MDQzMi4wICAgMC41CiAg ICAgICAgICAgNy4wICAxMjEuOCAgICA4OTQwICAxMzYyIDUwNDMyLjAgICAw LjUKICAgICAgICAgICA3LjEgIDEwNy42ICAgIDg5MjggIDEyMDUgNTA0MzIu MCAgIDAuNQogICAgICAgICAgIDcuMiAgMTIyLjIgICAgODkyOSAgMTM2OSA1 MDQzMi4wICAgMC41CiAgICAgICAgICAgNy4zICAxMjIuMCAgICA4OTI5ICAx MzY2IDUwNDMyLjAgICAwLjUKICAgICAgICAgICA3LjQgIDEwMi4xICAgIDg5 MzYgIDExNDIgNTA0MzIuMCAgIDAuNQogICAgICAgICAgIDcuNSAgMTIyLjEg ICAgODkzNSAgMTM2NiA1MDQzMi4wICAgMC41CiAgICAgICAgICAgNy42ICAx MjIuMCAgICA4OTM1ICAxMzY1IDUwNDMyLjAgICAwLjUKICAgICAgICAgICA3 LjcgIDExNi43ICAgIDg5MzggIDEzMDYgNTA0MzIuMCAgIDAuNQogICAgICAg ICAgIDcuOCAgMTIyLjYgICAgODk0MSAgMTM3MSA1MDQzMi4wICAgMC41CiAg ICAgICAgICAgNy45ICAgOTIuOCAgICA4OTI3ICAxMDQwIDUwNDMyLjAgICAw LjUKICAgICAgICAgICA4LjAgIDEyMi4yICAgIDg5NDEgIDEzNjcgNTA0MzIu MCAgIDAuNQogICAgICAgICAgIDguMSAgMTIyLjcgICAgODk0MSAgMTM3MiA1 MDQzMi4wICAgMC41CiAgICAgICAgICAgOC4yICAxMjAuMCAgICA4OTM1ICAx MzQzIDUwNDMyLjAgICAwLjUKICAgICAgICAgICA4LjMgIDEyMi41ICAgIDg5 NDEgIDEzNzAgNTA0MzIuMCAgIDAuNQogICAgICAgICAgIDguNCAgMTIyLjkg ICAgODkzNSAgMTM3NSA1MDQzMi4wICAgMC41CiAgICAgICAgICAgOC41ICAg ODIuNCAgICA4OTI5ICAgOTIzIDUwNDMyLjAgICAwLjUKICAgICAgICAgICA4 LjYgIDEyMy4yICAgIDg5NDEgIDEzNzggNTA0MzIuMCAgIDAuNQogICAgICAg ICAgIDguNyAgMTIyLjEgICAgODk0MSAgMTM2NiA1MDQzMi4wICAgMC41CiAg ICAgICAgICAgOC44ICAxMjIuOSAgICA4OTQxICAxMzc0IDUwNDMyLjAgICAw LjUKICAgICAgICAgICA4LjkgIDEyMi4wICAgIDg5NDEgIDEzNjQgNTA0MzIu MCAgIDAuNQogICAgICAgICAgIDkuMCAgMTIzLjMgICAgODk0MSAgMTM3OSA1 MDQzMi4wICAgMC41CiAgICAgICAgICAgOS4xICAxMjIuNiAgICA4OTQxICAx MzcxIDUwNDMyLjAgICAwLjUKICAgICAgICAgICA5LjIgIDEyMy4xICAgIDg5 NDEgIDEzNzcgNTA0MzIuMCAgIDAuNQogICAgICAgICAgIDkuMyAgMTIzLjIg ICAgODk0MSAgMTM3OCA1MDQzMi4wICAgMC41CiAgICAgICAgICAgOS40ICAx MjEuOCAgICA4OTQ2ICAxMzYxIDUwNDMyLjAgICAwLjUKICAgICAgICAgICA5 LjUgICA3MC4zICAgIDg5MTcgICA3ODggNTA0MzIuMCAgIDAuNQogICAgICAg ICAgIDkuNiAgMTIyLjkgICAgODk0NyAgMTM3NCA1MDQzMi4wICAgMC41CiAg ICAgICAgICAgOS43ICAxMjMuMiAgICA4OTQ4ICAxMzc3IDUwNDMyLjAgICAw LjUKICAgICAgICAgICA5LjggIDEyMi41ICAgIDg5NDEgIDEzNzAgNTA0MzIu MCAgIDAuNQogICAgICAgICAgIDkuOSAgMTIyLjkgICAgODk0NyAgMTM3MyA1 MDQzMi4wICAgMC41CiAgICAgICAgICAxMC4wICAxMjIuNSAgICA4OTQxICAx MzcwIDUwNDMyLjAgICAwLjUKICAgICAgICAgIDEwLjEgIDEyMy41ICAgIDg5 NDggIDEzODAgNTA0MzIuMCAgIDAuNQogICAgICAgICAgMTAuMiAgMTIzLjIg ICAgODk0NyAgMTM3NyA1MDQzMi4wICAgMC41CiAgICAgICAgICAxMC4zICAx MjIuNSAgICA4OTQxICAxMzcwIDUwNDMyLjAgICAwLjUKICAgICAgICAgIDEw LjQgIDEyMy4zICAgIDg5NDcgIDEzNzggNTA0MzIuMCAgIDAuNQogICAgICAg ICAgMTAuNSAgMTIzLjMgICAgODk0OCAgMTM3OCA1MDQzMi4wICAgMC41CiAg ICAgICAgICAxMC42ICAxMjMuMiAgICA4OTQ3ICAxMzc3IDUwNDMyLjAgICAw LjUKICAgICAgICAgIDEwLjcgICA4Ni42ICAgIDg5NDUgICA5NjggNTA0MzIu MCAgIDAuNQogICAgICAgICAgMTAuOCAgICAwLjAgICAgICAgMCAgICAgMyA1 MDQzMi4wICAgMC4zCiMgdG90IHNlbnQ6IDI3MTYzMCAsIHRvdF9yZWN2ZDog MTAwNjQzLCB0b3Rfb3RoZXJzOiAwCg== --=====================_26925641==_-- From jgarzik@pobox.com Tue Jan 21 15:34:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Jan 2003 15:34:09 -0800 (PST) Received: from www.linux.org.uk (parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0LNY13v020831 for ; Tue, 21 Jan 2003 15:34:02 -0800 Received: from rdu57-8-131.nc.rr.com ([66.57.8.131] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 18b80V-0006dU-00; Tue, 21 Jan 2003 23:40:39 +0000 Message-ID: <3E2DDA20.6080003@pobox.com> Date: Tue, 21 Jan 2003 18:39:12 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan CC: Dave Jones , Linux Kernel Mailing List , netdev@oss.sgi.com, akpm@digeo.com Subject: Re: cs89x0 in 2.5 (was Re: eepro100 - 802.1q - mtu size) References: <20030117145357.GA1139@paradigm.rfc822.org> <20030117160840.GR12676@stingr.net> <20030117162818.GA1074@gtf.org> <20030117172719.GA31343@codemonkey.org.uk> <20030117174928.GA8304@gtf.org> <1043115448.13142.6.camel@dhcp22.swansea.linux.org.uk> In-Reply-To: <1043115448.13142.6.camel@dhcp22.swansea.linux.org.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1601 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Alan wrote: > I've had no reports I remember about it breaking stuff, and several that > it fixed stuff. It also seems to match the documentation. Its been in -ac > for ages Andrew wrote: > I've seen no reports either way, and appear to have misplaced the > datasheet. > > May as well run with it. Sounds good. Dave, whatever your preference for patching handling is, is all good. I guess yourself, myself, and akpm are all patch-mongering candidates... Jeff From big@boss.com Tue Jan 21 21:01:47 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Jan 2003 21:01:50 -0800 (PST) Received: from MYCOM ([211.216.115.221]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0M51h3v024365 for ; Tue, 21 Jan 2003 21:01:44 -0800 Message-Id: <200301220501.h0M51h3v024365@oss.sgi.com> From: To: Subject: Re: Document Date: Wed, 22 Jan 2003 14:08:23 +0900 Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CSmtpMsgPart123X456_000_00A994DA" X-archive-position: 1602 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: big@boss.com Precedence: bulk X-list: netdev This is a multipart message in MIME format --CSmtpMsgPart123X456_000_00A994DA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Attached file: --CSmtpMsgPart123X456_000_00A994DA Content-Type: application/octet-stream; name="Movie_0074.mpeg.pif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Movie_0074.mpeg.pif TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFt IGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAAAACOFpjwynf2 o8p39qPKd/ajSWv4o9B39qMiaPyju3f2o5xo5aPHd/ajynf2o8l39qPKd/ej R3f2o6ho5aPHd/ajImj9o9J39qNSaWNoynf2owAAAAAAAAAAUEUAAEwBBABZ /Rw+AAAAAAAAAADgAA8BCwEGAAAAAAAAcAAAAAAAANbLAQAAEAAAAEABAAAA QAAAEAAAAAIAAAQAAAAAAAAABAAAAAAAAAAA4AEAABAAAGZGAQACAAAAAAAQ AAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAAAADiywEAnAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAH7MAQAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAIAA0NjU1MDk1AAAwAQAAEAAAALIAAAAQAAAAAAAAAAAA AAAAAABAAADAMjI2ODQwMwAAMAAAAEABAAAQAAAAwgAAAAAAAAAAAAAAAAAA QAAAwDMzNDY0NzMAAEAAAABwAQAADAAAANIAAAAAAAAAAAAAAAAAAEAAAMAx ODI2MjYyAAAwAAAAsAEAACIAAADeAAAAAAAAAAAAAAAAAABAAADAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AHGdzB4ud6p6TSjUpADN483kA40VGLPSe2RRMvEnwXaS6+DYVCYO2hNX8z/e CUlcCsyESKP0WlLEgSqcQoA1oM9m29MT4kYTwYHQF4P3olUJEoyhtSJ3Qr18 qZtnmIgxL9mUVyHY/wcHUuNDyX33lml2sDnY5bEW9Vn1YrzZtITMIaPyjo04 wOO3s9rGEhrhJg6tu/yKmUW6uBn1XQAx/hK9RpFcqemovse0NhiEgPd7QRHW K/cBHSxzbsCZ2qpuw+tA3LKmEdctpgfWcbsRhd9GUwZtj/OpsqYmy+LLLga+ scDCuwM0XtNM5+rfmkqc+sXUG8USfSP88O+JzKm7xbAskQgfxVVot64UCqne PG+RIkhilIZTmlFtqnPqXCwvXAauV7PRUfV3hD1K2fgOn6O+FY9qAoX8D9Kr ECwssCoCrhdPFOoMFfv0iNEsS0viUHOI6An9lZKSyQQFmalvPGRmsfXxz75/ Rr9EpnoDRl4tBGkjJlnGTYPm+/H8Kk01bUgJ5Qie2YNExzRVG1H54YljjFni 2+5nTaqQvPFlqms/F8GbVw4obQ3icxyzW2T+qJMP+p2waKMVoCexxBUrDafi 4tM5FlXOgZAknd92cDdZ0crY6eQWafFqM7+j/itrMzqKKNu16jficx2g4diA yRip2mwlVfos7KMOeyotZGiukGSkZE6U4kx9Mn1LHzx5pAWSDRBOclooWmNc ValbAi2h04qjgG8f0FpEJmVK55lKuKTWCBA5i9VI/3G16zzYomWciuuqviTY xbjlJctaALOJyvVKIhNoMP1j3BbHJF2TymOuejJoTHqGprf/cJ7k8Qpxdi/s hQuFY7XOfX9RjgIEv8zElPYSRG1kK1n9PEJiL/DPpso84hCWUNS0HYtWZc/m aZzC5l5383+NQA+u4VkK0xeivBaGLFuOYYGxAIeac+h+1k0HlsX36zuMrTN3 x9tqIikrCeYlFqzkSHyzOmsOwyNAI2IDpGYjxaOmu3b7imXedp3q6tp5eyAE wJcAaYQGcVwwj+98JNCLkF7oecU8D0QjPYsor/Lg5GNimcRM9DZD56D9FNnI 3M+e0dYU7fXW3aRYSifvvs5DxX9dZn9W4TF1cnIXKfPi1j8RLrlkAdRY4o/d HoZdWxL6d6rRAkM34WvXPy8TuRPTK3+9Qk39NjLXJszt1uM2epRPksh/mBca rDUelgIIYF1gvwJsggc4xPPvbyi4mHXysHmoBjoUvePE/uqbXrleZt8sO97B 7pp3s20lYEhHuuLy7VLqO55PqTi12zUoll8zJSw9YIV6b4grierXChfL5juG 2jgC+d/+l4BPSfVvU3UaFIm0vDFUYMYrE3RsDqkoT7OMjbc02kCT6EiVhP40 rZVJizbg8FaZercUUFeC8WESqgF/cSYPWP2LSbXyfUW/K6WEZP8LwjliB0Yr 8FL+XyuZsL3OYGcxHMKYi2RzqqO/KgkfjuF5DrP58yos487dvJP7p3zjlfqT lF994y3sqgNttCoWMPpb1KIUmAZOieCRDHSjNDBg9WBGO3B5JTvrX8GC546x Wfoey7p0HlefhIpwjM/SX7n692QWYO2WEAjmn2ovmoIMhQtJN+a0363LyfTq oARfIimKjhKtQWwAvKcVqWpPLrecsemiW1dvfSXFbiYy8R0CMJu6ktExSr48 x7iexVxWtiFXDt3CIZ7cFCLlLNlsNEhSM6TjQxemMkH00mlxCP1y6lvGMCbF ynn6VMdgCuWVKKhlo9Y9uS1bewj8NL2TypRB6+qXRYItc5Uy6kGmVp9AzRIG jlm3SCHEtH4Jo2H3zpjK0PIGVt4NndUR4ZoIpmuomTLZ9bXRDiqPWoDS3QZq fqcRL81G01TV4shTECxE4N3vcTtNefnJEc2r2d//vlJBm2gOgMxG7kIOxVb0 lSNhz+gaf/0QsXYzriH2OY4IoYEiqMZpKOBREwlrp725O6F0BRbU/XzmdRdE gtSJqUhXH8A6CIp0jjTdh7kOvOc8RkA6mHE+8pyZ6AkJUsxSUUCqdltXVGiG BhsHRlICLaowoUKqfVhAv5x2Za9k3dum2IaI0uLu1fq8kRKKV9QBiT/xxXA/ 24YhoiXNN+jr8MuXAcdLfQ5OpAG5sAov8u85dMeEFgVE7ZpQkQigpLiLM5gQ MvtiuduHgYgo6j4m70SaayNQ7AzsENYNkjxtZBrjm7lwv+CI84clHcxHFBZo HANcQY+SGk3GB+KyAlWbEHbTWATPCGA0o/08PilgBk4KrFxInivwTIPEa5J3 ua1L/AqLF9o3aHyIW3GawSTtrf9pKSsdedDHG3ozPB8vQlgPUp8LHYFJd3Vp /W4icJEG8Ei/adFNdUO8vxl7q60LfeSrqFT7TH7kbU3EFxW/2rauRHmLutz/ es9ySGCflj9d8AHNtj0gs/pfQFIjxiykrqkec+e+S2kGtV80zStcytjEaamF z6DPRZbbJ++uqwjyl8p/I9p3u0t+Z3KvB5OXdsNJ18y5CWwskSMN+nROgxTi DrVitFc0D+SMd5wROcQJ3mQ5kFxy5+btdc/AVBKJppq/6MPC0cANKDHxSp4M fMKbANxoEd9AluzAXPy7xlkG6OerIhWNiwYpCcxBeOvugjyx4NbQ6IkL0kcq uMNHeoR8VkRe0VRNCke8wYaatSSL9ovTjSI1+MqOtcm1+TFaaXYApZTdTQfT kQUP/BeZ5yDJgKJdxF2elgLPlWtsfwY+hTPk8eD0naA5WQbXd9PlPNsFvmSo X5zk6kVhbGBNGsX0TwrX36id4rzPfTm+58UEVFfN4RKoT3uW4lIz4fo8r65W W5cJzDvcH+s+vokzIU2BD5igk4pP22tYPO/yE9rGRCq/yJUyt+stmOdVKrs/ L+15EEybyAlAonaMs+34cBvcgREe0yf8Bneg6e2/QQdwi+jtPzVSM7LRFUUo HM0pNzHQ7n9lnXUclpEBPsSx0OJStwkU3KF/uT7kbAIGV3xMNnj7JGJ36dxF wo/lI2cbjpz0O7xf8axRGcpCtmkizS/uEHy4a1Aat1v9OCGZh6kmR/ILx8GQ N0tMvsCLV/+bxYDBVRaJdnNwZ5oIM565bnryhBDGKecTjcwq25Gw+2yyZXvO AXQtArk51P5HYt4oh8ieLpLDEcPlHY+OSf8oNM/2a4oyuqyWC0ljQbpQll9e exOas4IABHus8BjSjX7MI1iuthuYr4DCD54UPOysstVCBchYhswciHVHNe99 wDETYXrEEdOa1RVm5wbW0hWDzpnNE0Qt0JqsOG9/Yx9fEKFLP8YPxo/pr7Jc j/JzTxk6kvC7nrNHuVJQmcLALtXJn0XgFuuKZYKfB/RCnyNy/3PIg+k5qlst TebQiE7ZBXdKNnpp9r04SrWsGjr+AW8UugVmmQbyxgDN/O57pzh4bJkjo4u3 qhPydhFaV8teluRV0IGgGtx233fRbFPx1NO9NunAW3oPtfjrAiDdorwDE7f6 afaao3p4cngP0zJ0Wf9p2m/djPUpUmMm944fQpPvoH282P3LVc19ASvaVTyV eZQJmK409UXl0uNEi6I5fvg4WQdhJVzQCe2VbFMe5UJ9Qg/RCLwOTije2Vg7 3vCMr2cVC5pvvFGw1mhEPTBqewA25ureXeJm1zqWLue3A7nftj8RI+NtA2jF rolkJrXe4yCPqUIfhJlwaEU0n/dpnKUPyyQE/gSby8Y3ciyk5Op9oMs6WkL0 LXTYXz6sH9dv1T9CXPHtX4m8/U55X/lrRBsGEHLYWIk9ONmbwrrp5++QkOI6 0ZYXcBL4KVqKxTRnn0XLi01SbZ6eb/GiXDKhAwsnsNGwuOY5M7DfLQDz1jHg JQyjwewnXkWZRn861yhI4yHSxCc9lb9XzVLMk5L89gLQ0tDEJP40EcY4SS+i qOeHtP8w9eu6ORPsm0bkwpSmN1piB5QUuW6jQeK8aL669NvLGjoo0p3LMNPx Wv0zxLtyDKIRWGF/EW51U4u/d9uIjVbwbeGVvTJEul1wTewMSqPPpPse/qPW xwy+ztbmtFPD+2HgpXZ7KRDDG14C6Fz1OGKjfshbzyTIV2FgdwpNfrEXnOTS Dr+uOxMtdKj8SEulSEVfXAbBZFqChF1mcuHa/4XfNA22o4UoD5ujKkzwGEim ldVtBwEsCD07SOBPH9ZjN5iYjYrmmSNqofUynaqNjCNmgPwvzRjKaVHnUq1l EAwlIrMxs+YxXMZTc3j0XaOhQr7hOEQAH/Q0NK/HpJMss/dPxH9kEQMif6Sd tiuDF21rTZrtD52tTTyqcF/FeDZ5vP4a6o1cd76fjqXeqyuBwbN4BeD0Hwin Ouslm7pfp4uTvhpsaN0iNuOvgkXF+GgKv6ecR4mDygV7k2iqBmPK4paYe8yC i0hsSoX6cNoBG7gCNJvgqIm4lI0fE/T0oIYwj+AqrNffACcLJKT87jcuCwTI GTs+qTeTEYP4TANgKJvEk+i6IsRaH6mJWexXwSdo5EM5CKnQPkTXMaE9hg5V DbWI0wQ6z3udfO9i5UMwDnMuxmrl5bGqwpquN1ADQXUbLhEm9jW5YMPYJOXH TQTfsmagU5m2YKV0WxZTMAYKJal37xSAcISI1eHex91rKgJ0caJDXnTguAON O0jsXF6dMktkZ3szuW6qTx0Jds0YIDsnvsEYDVmkh+UfllSBylEZBAPU69xE cqUPYHgOIUouDGv1UxF88cRdpCnu8tzFJZOUOwVasMTDGYqe7G40H8I/cUOm T+eG5WoArzJVhN1RJlWkyS7BwcidKZILcT6XtSKjbszyfntO+0wJDQFH3ZX+ zt8P9pTKTqiF6UugX7aovkver8i2JGiSUw/70K+IOi9w3Je7+8UIoK360d2n b+QzgVbtUFn5EVoEm9eythMFUXxdMHwi2dYei7WixEhhcjC+LWaGllt22jh8 M6Vrj4uyjlCUVszSKjGC2V/7ph2Z8pu/WhmgesMAvFb8yyxCk8PT8EvFyP7R +uVEabpyNso8q0kSkSqob9DvynyzNmTOoxfoIs7yH3dQansBfOh1FTKabJn+ Uig6xJ0jmCiYbJA9R8ziIL8nbxfjPTEzD+vS5/0snn9HPb7QTDbEWmBxctz5 caFHdbRdzelkITqD5pgkpnFWDBw7xems8kes/7T3+Yt+u86KndtcqzTCpiYR hqLsq0pcTgDCqiKhPJnuujrmx7iGlw+KM+UuIdvrfMXT9VaZy2bZGMclKp5T Ls3ypKIKlh9f+g1r78cNL6EgNqJ2ky3E36yqKKKXcjslLLVa26FoC6ZFg6v1 Fy1BDZm4bW9TumHh8JAMtXjP2oL1lST704yveJEYDMlpHfneWwhF4P1ICLuV URE/px0WllPTfiMgVosevBOQEKdFHUP9AzEg/+QLjwA7k3gkJuTLBaKJ1Inb tDnRrPLTWbrDi7j8F+WtDyOlulwy+3Ixsn7vqoysSRn2nd2NvwXY6ix3W1gh gF1iy+/avOVgwTkGCohyJbUPGjwdsl5rbNSejfLW3+gm97/M/H3i01CET1SO 7UyAW8Y40K6ik87+SnXO/w50pxv8fixnS7YLRvtBq4VZK9K6tlYX+maVDe5Z ZmzK7vASDRPq4ixwaq3inq217JJUjaIx31XT426EUt7QrqmEhfi8U+vXIsnL NCn99FZONtQ/vVev4o3MrKUe0OzPJjLPlorX2YHbwUcj69tLhQUhh2noFOaC NsVjyacnQ6gMyLcOKbNnMGbMnKVY06M0si+1B5Sb5Es0BT2NZ8evLiWu98op qIR/Z4ap76R+KOdwEJTVY67uID8NS66doOpC2BOLkQ8WsETIERViwBwBMtMI sBZlhOpcH+PCsfrcuDE+JoRSjAjF+PFFV3JqTOZCxtfFHfbQLc/uMtSRWEaa Z6nFM49ktTQIg66bU4JA27Pswjjy4LMtaap3jzOQyAryFN34O7kNSlspS8H6 qpPbqHGccoDLHeiM86Uykwufot8IsJAhhU1fx/Iv5mEczhon04VWi2rtZp0R e6l4W9TFBWAJ/+tjhR/yoEFljOLQUoB45orES2ckvZzVl1nOVp6spaS2Btli oW1c9h81TQAvFOqdOj45qs5op1lPvYsV/Z9UQ4DcAfGmNdv8z13uruVrhIjt 3+tndin+LY/uWNF9lZolBCu4Q6Zb4+DT+DOAKzDyYeNiiCVJ5hqiZ7Lv8bLQ 5MIUVlTAkRu/3ZTFOk59tSjcjFhZEnSeSURM6+fZ8lMIlUq5TXvzDHMGJFV8 D39F87hnmmr3QD84n2fbwh4Rc1dxRqcN59441CK7iisQyIQLkviAuZFCqXRf +REirMUA/J5+jWwg0t1k8IYhq+Cba8qa6dQ5xLygAZSKSQXNwB2QMVrSOwXv fWGV6/5yxBNDGAUlCAHh955xePY3hjqOk34gV1XxgXFSB1/S7ZKhCP51LXFR gXw8v9Ra78mJRMEVRRHbfQnzGNqCjnV0mkPYnI1MajgKmrraK8nGFDd6BD84 GgmoWZmHyJvFqKizyh9leEmygji8aHl4S43c4k2QFxfJ/1xDw2jgLIe7fwGp hHLL5xclQjHHVZODxMzfTLAFgn9yAkOyH/ISctrNbIbkz2zMr1XaAM5o29TI gHf3Ls/eMn8/Gi7LGiob/1Jd2G8H+4DEcDitDvrtv3Qcfz3JJJc97hPsy9mW hfoEkhrJyvqYwqcApD0zNpVgnJdb0kmka3NegCWX12EOCM6Jl7ox6ScxdAiF gwPbt6INjMLZJIyEhBbHOK0hJOgQu4LCK0GMaH3G+X7jdSAzU4G3r2DE8+AB zDJe7R6WlzSHV6ON3hi7OuxYgJB9FbwmutoCaxS0hxIadjuv+rpf1bgk1dYT +gXngj0u0bmFcF3XkV7jfaWYGulBcuJsrC0wOw0bytZ4FSyS/2kMLF7RnuA+ zxkG2vrXX4fLz6s6ENbkiG8pJOt/I8S+k96Tp5HYNWJ0hzYRSjV3i/dSGhd9 KV+SbvUh9i/7yFfYQnCcA6d8CEwqxUgrnr9N9wVLqEf5geJwMdzlEoarkvdU RoPaUsAfns6rWEWMOFVsxZgQFp4xBLHIJPnNpnY7SFUwqbtDvHC0K71PrP9Q phXRiPNkTzDr17fa78lwm1dmqySTDEWOpZE+PTVOvZp/zV0L+IvhVJs1IMSq kfqVAKSzN4hQ9/UVdI9B876eHz4RPdUO3pANMqUSLbK7fM67P0txffH/mjqm 9GW3Jn1PDzjlfqHjuoPgi2Z+0ChfI2liil+JcIHX2Ss3jP6RMV9C+vqULcPu ySvQMIH0Z/aN9HbIHvEu0Ycu6pVueamCXzAyNqZ4YGyj8cItrBX7xqaJppZK 6apReHhXzTuYqkqGKojODN6q3ut16pRLp6EFVJUUNffYSuTf32KTkjcUyF+j +UNbBWmu8asHTe2H2YmXWOCnb4cRz6iyXxi9K4cCFbFN/myRaVopkoNcYdmO AKuvNfLDqouUU0lEKwULFoUGGtwJpWd+YIHFueOOa9i+oMWUztMYPWY+dmbg mQ4fMBlYqqXQHlSarrHmjrK0RMbBWPI6YLvS50aJB74omR5vaDJGSOfqTD4F qW1ScCLZK/2ftjXZJa888gsUmvE8jINfnG9v82d8KZFGC+RvVEstxhF3Ochw ICvUPigtEWb0Ytk9enr4EGa+powExBJUWDVnXiFZl4E9SoqGwBWvrTPHI+ui Q0sLG5jYXFG7EJO7vAInGc111UYE0/9JwnNwV3LD5WPMHcq1+zNd5IBz49Nb ENV8sXSplkZbyPicesIiH67XnGsoFyB1zS1rN52lqEsXRZiqKTRuiQjfHYdI CKOUoHMGABTRUKTAtF2oJzdGOrFbRSjP3x/mObV+u6dn41rF0vGNpDpDjMIB dlxFFQR0yA4cGHE5jOt0oioCW+jWNX9EqY3cMjRANjsbGdqZLWvu2n5iV9pZ CBj5l6kUKuw6J1wBtA9guZlTdnwBh1xNi11okiX84peeZgHgeWqiyj8ZSDdd eUZm5VB5zhvDl3aG95EtVwMWUazibov5r5FvI5vL3d0Yk4PE6Evq+pP94naN xdnWC4aSJMXPuMhrAHjSC2uSGK/GVMU855GtQrGHZx1chzhbFyV8BgH0v2+W nCPrFXYHGwxAW/mT/7iBsT1RtQr97dFEBoijbnx7U4nHWRqOmVDXPDHLBgh1 GrJDeX57LCmv0vcbPWIs24kskmlRUYahx4O6/usdJ56bhLUJInAOOrDnh7Z3 okxnUT8L/6Q92yHlTzmjAX3RWf11JhbwRzF4H+hGIdUQNSWdHgRVPCPjpl6L NJHTlDKi7JOTiPIwNoxedihncisXWY+j6k9mTAuAGBj/Uv5VO//TPA6VYsL3 N8DC3RNl9LizXaRI4Hxq+JBxtaAdcXkCnabx9l6heihAs0JMqvCMkvmGDN91 E1hu2+xtRKnWGzPIGL3odhfQilgqjYUKze0XGKMsKfpUNUDpRJq1ztzOXHF5 38IFR7oyaIB7hpdFKlteicmINk9ZzBTU6QwnA5ckwulACem3oGIlvW+VDQgG 8ME/3H9blnyjOmkE8q5yvHJfnv+AHGnd5rhMr6WcVO0cNjrygVdTan2DPBqz cVXkeRVs3UCo9d0yJVOwdNnetYOgt2V+PfO0QQ6nIuDJiglVV4XHzYW8HZkL swWyBDRrmOOZcYVSehnYZUiNkuEDTuRVXT57rbM5/GwkoY/0FbTcubXEHAqu lVNlSRJBWxBYxVigvZE6yCxsn+ln2AxbU9zYGYFCvi9TCLF6ynnZ+/MA4bLa F2+BrokZsczf3ziYRkNKvQtZVwgHGL6ly72YkDvYZCrZDPK62VGvrWO0qR/6 MaKrYXbdsCW7jbdyT+VQbrDUq46yLaldW1nQXwG/CBpv+S+MWAfSU9zlYGKJ ipsbBjai/xeBba3ppxAPCAm1J2gdHTiDMXwN54RRORiMcMmpWicWupao/wMe 570tNBve3yPcGUBH9mRj/xuy87SD54joj0OeeVwwEnnmZ2JTiuaEknjNgkY+ RdBJd0Rxp6S3shh7TYwxCk6E6ufHGqjk/nbPbI2ugV8805dmUjfjToQNSubP 03Uu1EaxaIFuFAeoTdsD09KNuMGx/TuKXg+w4Ae2m86odCj9+V4FzNDy6RLG 7DO05+jRf3uFnaNQ/QTFUaLkc5nkRjX+YyQHOEK4qi1aibf0xdLILVXClZhn 2xGFqmq/TOMwxFt4YdOjmaYlZi5EFDXazPNROyULN5D9FwBgfXChBlH66kk+ HPNWPiPfGVR3FZb/iFDGgutYCT+q9QjjG0iDq1HvsUX049CtkSV3tqoMiMP3 zF1DXlYBMxPsIDQcfoFVCZsZnOwM3q7jmynpiWYTbFX+TqxMwndOAxSoMeBE 42snL0nblwCq/bx9/7GkCjhp9Vle7rYLDrg3rli/cuKuuLKU9yKjqbn2wShB pmU5JT0csPfD32BAG7/Y2vphIZ+aNQPvzKHFwjfUxq43SJS8C5whR+V/Ebcr gc1cqdcQ3jXTn6B0XidtKxeeRhoMr+wQxwda8j1AUstcGYZSKUQyMFcJqRBT g9jRGwWnkTs5f0vMIiu5+MMCf5kZZ4/J9Mc5+8c7XtZI8nSxWRwreE/UHX4f mQr+DAlMS0B/KcNGygPWRLYQnwZsmV4BmU2sHNJpCbN7Ob0qaDz3SKklQur2 5JNpgNlWL+ILsLIJ6gDvhhWu5yore9XvKSwtFpE448drtc8sDTNXjlOuaVfR HqKWLcOaYGiLrMDLitugoKIrfgHHwx7JK3gNnHQLEjMxlij5MZLufAUoSe6b xZribUqzQOqauq8HIJA7d/Rc8Gj9D6MwPHMbtwFCxTMtYOJPPTuzDyP6+NPB CSPMzs4+7/WzG0ZrbsumW05tbGZw6TmSoQDzxV//G7QLUaYFriBGRAz2j6Ab B4jRKFP2d18Ut/elucib651opsFeeJrqOSXJdflGl0xqlLYXzKDGTjP7fgmt 09Jix//ycsiH216A+Huu4eHhsVdD76ubNPTBzH6+0giYH8ZJToGoCnxaYUMh amwVK4NOp+9KyF1KXOSoUsXvBdkTwGO72h0jmGnAY7mAGj69x2sHDc8VK3Co Wq7PkJEVjQajAcqRq2AnVqfQqlEN8x+ak1WY92GdpaagWA1oJda1hyH7DT/H +YJ6kyLkJdFnMvM25HLny+7nNW0vNmd6J3Ed+6LNovEWxbyQ/BzlEb/wNNOg mHKfbEgQC9oJw5mpXz0Pv7LK+XXADLx1JhA4D/Gs20GLeq80C9Bblmsew8Tr lIq/1zvkYoXwU4rNadIuS9Yx62i7SClA9KfpooRO3YdOVVRJc/sstd4g3Wr6 I4tFEM8eOdtYz2ngLPL6nF24B56F2/eD410Ox8KlWmP5ebxjVnsk5JKro/Hv s+mlRLiDgd92tlEedoLxlRMTpD5rInJBAY/CAf6KIJ67RiQm1VEx7QvQWuO9 TgrA40ziHU9SVhcBfMumM4ePT49m92VMVDCDt8HstvMwcq9dARY1Spw6n2pQ jdRqAmFnVPlO71qQ2It4Y7iBaLYGvjE6OnZuCVzvK7AkK9J+9XS5w+bcDBXG CO5zM7GuLX25xI0TMRSRYvcNgFGqAPPQOn6/v9Pz7hQBlT0T1qJTGB++32ZP /WBKKYM/eBMWelgSfv6sJNkkhH5OExsgjBxJ1vUY34yLZWaIpqJK6TPkUu3E WOQ6xM/MvrxRvwOJFueVjDh1PgCJ6FYADllq/z66lnUtIYZjcHPNRY3iCJr5 XNKnK1Rmp4ldK8XZVz2hQXn9Udnf9jtRQwmzjymfapr31rIVhbzhph8zgaBK WqSwUkvtyQn2lGzcwQ2vbBjnfPSq/qvjqNxECc1mWRozPXGsZbF/RRtl4m/i NigWbNgQX+4fcllMN5lH9SEWbpHv8fbJJtKGnptQmx3ZY6xXzKpSHeUd/Bzd F/SpcMlDp4z61+G0GzYpYG2iakuvg4TSQhobMrljW2GiFGT+wD6GEI6Js8si uziJ5mlFDxl+Bj/n/DLrJ804U2I02lsSpzqcEv3FGXMNeUIo67MCefXBjG+Y yhnQCrbY+OE+bMwldHUe2upsmQQ9HtEGtfucCm/sQMtK1DKFmxJlCAFTaSYq R1VKRR7fquQ3BXrG1mg+Shhxibfa+IPjdooQex8mPL8t+u7zcukljy3tiUP+ Y/1dvWoxfOb4lTY0h0JHqrgyKKXK9YXB04I8wSNniCNVLXGvIAuWVpuUF610 o/HDGoYAGv6ZGmMjq+g1CBOG+3awjZtpEVKtGKjXPhWjrw1nuNDG9V0E0dFq ej6OkBZPX/7P9yLVi3WtVBC9k6yYf2OGR5fOCevYRusTGnT4kWbKq9+qDX3s EUewVKziiePFx5bhaLTz/BjXPYbrtSSCC3nxMwrw8oMIvC7atxaCkjwTqNnr rP/SSoITaoGzP33Q8rcnBxmnOKUKOt0MiskfyMLooAzLjb/FIIdnC59+aZvV IfQ38QKFbMLDf/su6NddSQd9OIkYTv3+7yzh4JufduBfOgEFIqpIDxIZMfKZ GawQIteAiDnsWy/dReLWdV021ERGtnDyw7/F0X565xtg6o0kAdWhbl3BL6ZM mqJX0N2zhHUhPZr4pIrXhavDsa0q2rVTKGGUEFj/+9O7+d9i2NvqoqjHzGS4 6FmrPnoybA3ZCGHiurQNM2wxjebxIC42oM29i9tjCYCso0CtJopqxZ7xMkdv 5wWRXCAnVfu8j3dxj5gjbaEreBEuZCewTgAkZR9P7cynZih+ptcvk/Zl2dgK pzsKzJvo2ZUd9QRrTz7RJAF2Pcs4Y1ZM/INpYg2ZO7H6Cd+Ge5YUHn/TCyyr oktMoXQ5YorGhTrxBh1mjFbMBqMl70LVQJo0NrcVPp9OmdV0i2EF5hSkv1QP qORrNyNxJ38UNfn1xTrBKaFtRV8nSw3BLmSW5SrA0kv6e/xzNTr8QJlea7uT 7y6pOkSOhJretBJx8dqzloKh1c+xDuoDPf9s6FxLoBczuPIBx/jSvPTsK7vE KfnYBmsNctZclYIeMYJZdqcDprD51oZ2BC7USwjyIIEiTY/ThYBflAE+P3F/ xSKb+9bwWtnmXpetjGmJcHJhcUboCH6jd06it4j8P+xg+9RnpXixk24pH0yT hO02cW8fFz/EOuJi3m/aQB+MmxVyQTS3sbv0K0l0eP5margUDtLzeRRP9sgy BKbHH5Hb2ZpMWSGttWUZYYSa6gX6EXu8b5kFMH7hLKSQ+ww3c9TLQhlPyuIu k9AFbE+T1Zy4SfCKN/o8GZA6DU6ozZz1gQGBlb/9liF12n/dG9aPFMvtemzc tqI5kzojEHLB+/1wZq296U3J2YiK6LrkDdpk1b6RyU+AQZpw6+dr7KlXk5cp z4pY/AJfvDyYd1qODBT01EzkIEHi8uA4Bqpb+ukiY+sWOrT9oxji4/bGUb7g rBrdFJdfeWkaCWPg/7nRxMYtREh0aXbtujgLWrpQqxKPRxkrYTpHDlCHcnW2 uE0cnLstbvQ1TVOntpEj8U4y5dwCyodIBC07Tbx5KTljrYaYrgSOlr8XH+jw l4aa1E2bObbwZ3ZcQPWdET3+0ZZ1/S/jlVPr4chk1BmK2m+sr3WcrKXR+AAo fFq5UkTI7B9BVx+CpuXrODz7qqzXC8WT+PsCDB25J9glCthjQyJxwMR+bypb BdpGQcYN//V+QkOdmUFTNetY0+NlczPazwwJ17RXWzzhrbzjq+973CboeZ2R atHCUGCR1AYZvZyw+2UBZoOLvrC9GmzmF3kBpz9/tlzZ2eyHFMhdYFYmgyFu /9cf13+11SDFvplk/f7HldYaiekIY7IA13L1isS3ogtjaOs7B+OyICZ5a6UZ mApAapYr6IOZaCt8ZNFHjv5zAsfSKyqRocL5UQT8xfW2o9kTnrTFoccVTT1+ g29gSgAgieo1xRaLDb1qe9ebmxuNFuTazQhYY8py6bOAJX1YHOK4LAoEpHOF iDPznogzFOtZB42kH3+tGfD///TNryPNphKBUbVRtDLCfzQgLjMsgTXHtgJD 9saIBu5dR/HTCtyIpzTilkgMBC/l68vjByJOcSS9s3fumdnQX/W9O1jAM7I/ AX2b53fQhnwXXpdmim2cYEoSQGvzsaKR01YrwVD7MNMbCoyXRm3GofzuKfXY tN4WD5q19NnezF9jmsUgIXwT1Tttun7eMxcN85qB2sGKZDnxiVImJ514o1wr LbQBZ0cX7qYIqCLhOUYhieTSnQjkfqR0bQkdVO1x5UvCJXJMBlYdcyivoj4F HyO/jJDsSXbRD69jYIA10lkK0LobnVXxlHSbceQLwGVD8Kue6AojPTLuUYeD WhC9kZB8adzCXzK/lbF1QO4Vrum/S4p4QEeL4H1UqFNCAxgbQA48XwJyDTKR ke7NMzuMIzLotAuQtyac8nUU8oEyXiLST++ChmJqgoKcRWAImy3iokYBQQ++ S63Oo492EAmf1uDgXmBvCwswPGxaOBa5yLCWpp2XGjUc76MZpDTd+Rn8kEJ4 j3/YhlrLzXsRox8RdmxAunteNqsCr/cupt0sps1t4sXOYEqKwGhCvJj25TBL qP+MTVfQK4Kzqo0VPa1j+66hw/Lgsx3cWrtWl9+qxeuxfoulV11+g/3mMgF5 9ZMXGPHXnQLP+Fl5gEBBt2mBPfwLpLwENK6WehCS+0svOI3MEwYvTsRQy1+e 1s+wSsirtqo/dU9LKWYkCPe+rup3p03x6Y+FlwcWpDqSCcpvDSRsZYX6BQs4 y6ZYygMaHgYVmmNnKalPtBKjPSdtDhZ6PavwOzUUNLflvqlm6ylzlFzWsaEt kJwq0DYJ2hiKZkUpKoQm69x5vPaAHyPNSytoFIqVwOX7q3mUXiFYyijeAM32 x0+bR7vUkCwmoj5HhDTWv69/mjLeLHN3Wv4ZLaqWe4okIz3S9GbYTFQGtOD4 97APsXmSZguuuHcctOpjG9ffHtqxhUVWbJemBM6R3iyLRHG1oRzC8fqINHN2 fb02VpuNxzBgcsu1SzC93qhooH/6uMFb/5orvVAJYDHvyavvyOTJWTRqpWmo khfLa3LewLmp3iFEvnKh58CVh9UjTVoJoDRiERZJ8cDga6WgV0tvyGHddaZV Zezgz37TqMOX7iM0BNA9L78vewG8Q0jVNXwovmfpb2MeMxV1LKaDXmLbL4W4 smYw8QvJw86x3ZMNfvfu8W/EkA+Jp9k0J7xR880LYFLBF+3Fib/Ut87vw3ux D6cJ4drhLab6UV68GczJskuIpmq6tkNcKwHNL8sR37HNrtOKvdl40X0lE4Zx JEe+nYSomELrRk7MFrGspwpcerE7afpZtTZNxORsSPCdFwnS3Lxs4m98PUNK w+ZBo88/PVTZf3av10vqh8xZz7OVGcse9GUtkjdqWyGUENZjBYJJiJSNp/PK nlquSAUcbX8rD4P90b+IPQ5ETa9rR2Dzjmq06nO6bNKSpiq552jXaloA8rw4 O/0k14gwHcJ30lDfxpI+lO6MsootVAx6F+K9lPS1EXjc87SBh6FL1+Ou0BBM hyy6u0Mqb0DhDYoCIWkUJcoarLqZGyeDfppx6EHfULEjNnC0kbCruxpJrHh9 tHHQEpiFrswfQcyBhbyRC4fHYv4/cwZlTrgaQaBgbDUIrkNaCKKYtsECiajS ECZVmsSTPk0DUnsmNNZDIXTaknObQKe3tEBmHKocB79XSWL7TQ7LFIxtz/V2 p8Z9ImrUQtYrjwg+/5aZoKbPuhx4Suu5VLHatlhmCPKQ7XHb1L29XgkHIf3H e+JrwFgjjtYIsp2uf0BoYbFYNlAk4SxnEfcLzhauGQRGNsIpzh2wYVD76DUS X2Ao4eFHI+3yKn3ne8OWLqivdFjnE7l3C/qQkq2NkQCnEM7AAqugnYh3QfBG KXXYGmNeZx+01kERwxldikrpioAUgInnQVFuC/ucAJpGiqe1wvoIJ/F2HL2H tniwE8nQbMIfQxkuE+qzzc2XCP0ZLUmGv1x+oyaNYLmS0PZ26n9iMW4JBEu6 uHFHfZWcHS70HI/mtTITJGT3xFm63MKA/RHmdZO8uJmRnlGlhuqfe4QyeWCR ercpuecnmBrPGlpKoAZPSCTJbyE3Kx8zHK8RBV9O5BsSSRWVsktGXAysAsva 8NxD3PzK6RYTT85X/hlnby7y73k+KZTaaUKbTWkTanksFiteDWKhHvvBrI4x 4WAdXwvAzpaid/VvOv07i0zK2WBS3t+Gnh2hiWE4KbdlS7tb4IfECMmLgkAS 0DCDWnWJf9xBhA4oKYDWLHlONc0qETcWettcuILu7Ihmq5nue14/xRgUoi60 iioQUHGlqwsoGEjOHnLYOG1c657wbKAG4UwCV0JNdpozeJAv9ttn3mmVHfGV 04XfzMjxgTO4IAcP/pBarW2Jt52psuPxHfUFhbiOc5Clfh1fwTnLxEFdV1me x1nMvqgYNxAdyqvkKsaiaAMxUq3003AfgpNHBiHS8o5/ih/jhFJFCaEnuF2o NqE7RXgjfk1enpK1fAEDS3XjzmwDVtleoF2SNTdQyjnATm1qpAGa5WAzqx/T MfYo8Cb8CZAxMFeI09rmPR790j+/BGvYv6C8dRuQ2s9PVwkTu3EW77C9Jno/ eIZPNbPsUqXaCq9cf30ItU9Jrw9ju+z7P2AB/YdW6TmlLYgdGObD3SPZzBab /7kTQ2a471iGx+RVOVhpOyXmWPYQQzFOJ0RkC9TeUaMTpJK4E6PUjdvGJ0gj l31gJnF5ATcrTYSuMupo1ZiTYGnbrj3mld1ZwL3plKx8VSKEFVM1GOLnGmGZ YQTSy+8fPsn8A2ZL98XMt5xVtUVPF8cxa+ssptygWD9GhkhHc+nepQQVqkrC xPKsjoYb4HylF1Gzg7tgM2Tdg/Hy2FR251ziCedPj6r32HybWkxDbssAbLQT FK3ENCXGDzGVch0NG7USrJyCz30wHBlZyFHvjZv+eDB2eGqWfmFNfdHC0TRh pCET7HieVuUW0FPGPdjBf76BlS4FjxnyggpOYzNjkUiWw5DgfIs9ct+fQqYK l5cRzOJUSy+TRHBuxhEBGKoTEtB/u6fjO4fmUPu4BVvChGV0dz0q/zlJWvEV usIWizIYnjqW/jSK+CL8HSbys4B80X4VdPcBbSIBjt3F6YxveJsgws55KqrY cKTqcwvrPJfOY9qfSkzlWMjKf3NQ0oWEQQzN5tipE5t/HZsHxTskBNe5u9uQ Jz6VCi63iVTudzOwUzK0lgJod+tr1zM4/DUfYuCAvlH9lyAJS8+HkoUr2Hne zYtX1LSnaencaxmqxyNGXaowIf5kxzelk0ZCfIdhJffTjiBdr16pDTkGu5KT k4CEr6EvO0b/fGDRtGfF3jtSpI1LvTHFgxB1L0otCjy26IsKRPCbbZetu09m 8FiWhz17Mf6xjMRXXk55/Ow1aWacGIfSShEWStjCWHQD3dlHNV+mYGPrKQH/ XEG44WS6yjYS8Ei04KIRCCIEc4VFVDDtD61c0AX6DB2/rbrpTMsogZrE3KUR WXQvVAzsDubKMZ1LNVUqP2GjrmKu2LwREWFDzALRerR9KJPjfucmcrtOkm9N 1UhavKgGp9Tq/RU40/QWuiaw91I30b8BP3oHD2/TED8Y18DvodcMRPIv7vYO OUvdoPqMTZi6lSZGz1uz6tWKDJn1YOwjub0qKC7ociVj1svayngDA0Pkq+/I RIb8yJMWxP85SOvJujJD7YQeGexRM7ruZgJm+Kiet94DAuXKkuEAkCnFng69 DCU7tn0aCs1LqqNd5V8UjNjKETQKNP9dHZPgfHxWyYuWh43U607DSj5jzAES t2qaLFCMSiLgq5VxgEa8OgnwvR7H6W+y/FHhs86cZa0h5/MZx3Td0QXQ7+gz E+9vnk2PICzXAAibajnLoABgHcmW43lAvwGsLC9hYZPT3LikHXaN5l2ceK6I XxOygMFmiAYhghl/j18EcFL2nhpg/ssGBDQ0tns5N6p1cSFgEsbjKLffF4EZ JI0nEvATU7ktPnTyCAfIWjpCq/WTd/eqbHWeROEBQzWOvR/MqHIiKrhu1dtU yKDZjMHpH4lGTT571bGK+km+rLzTeiyfqQAqOcs8JPGFfHAk66k6kl3KpAtq qbfTtDwbN8njjJG0nr2zXW4NUevCDieNsOJPvBMXeMbnPcMATbc840KcpZm0 SjQbT6hCQO7S5iy0aiMBra88Rzl1YI1kdzcrOdKu66UqEFN2WH//6W6CTtxL 0khOpB0dBiI1TFEYZtzd7dQwUkOVJFk6WD8XxzgoCajJ57eJHj0dO2D2pVdq /Cw9WUNFIozQkbFZHDDy28uSELb32aQ7rLtzszZPU0R1+YiKbuHXyZS27deP +BgeEIErKYfigdl3zw3aqT/vM0GLX6+pdyssXY/JnPhYUYjd30AgDMM8ph2A ZSoCKrsgdwVAvRoIXmppy4o011CSO2PidzqtRKnHutT9bXm75f0/nVXa2z+a 07w8CvBw2ZGpPRvs24e9/6WC8qjFubi/LY5y1eQXelDWbFcs3RE5sGCkl21H t3C1Ra0iBlGnuUq6FXLqVa3v56xa51+UMikh957vU1LpnxZjNRD4OgSyR87p aCDbhFXhOU7V3dSyOYIJ7iTIo9BgZJsBfUwhwMsGTBahtN3xcz4spMDMMkqe nn3M6MypuiAp+c3wOLZvvuEE2PQZR7+ZUL4BXM94KAf+cxwaeIylnhZkVrL4 0IccUvXRkSRRUxOs9fGe1LpTwYW8ly/dxmjVNbYElD4+8VCrHZfWIYszHCDN xsNdVct99p8jWeB4nxWt98+EhgvklxVZlU7DkDj76iO/qiZjHRKRsnaHOPYU Sno9iBV6wBZwXX7Mvw18uPGM9Ql0py1hmjLqBQYQiybFJKGjF7yZ2nm2tpgf gSghOeaBG8xYsTPE+1zkCoXZHWhL0t4XxC0oq5quobafY5q31O9/wtsNZ3K8 cczkNsYdWK7BN1Jo2/NEWuwzq34a90KkQf4xhSAePLByS+AfRbTkrs1h+M+f ap9PPKpsS7AQSBqUEKIO96pbVT6Kh8qvNQcnwJmFRjAZJX66QH3erURDFSP6 tgHtq7GsuqqHoyzD5wWh3GuUBFSFzq95hPiQsn72EmwKGdwYJHOUHjSJz7il E+1VIngVHra/fi8yoFwWqAphOGWPllEGykwvo/Qgo/kXxGz7dLYlKmqriDmk Z3SGKelHU8L5/zAUsFsmxADCPHXBUT+3nObmnIeaFPCvdWIE4RNByP5zv55g fuSS5t2e3ez0zN6gGaqAsn/SQixlZ6CqLOncA55dji8qFqHnduro4d7487Ww d4t47qTJ+kRveV25f0CnByNSkFGwlAedfp9iewXBjlYStHnerPJphseDBMzg xUtr8mG/cT00uR5ScSUlBctiAtKDI5x5a8kY6ND6jURlfCUJM+j6Dg0g2vyr v124ExwglS1KkbVW7X9DvIpIbEW+rjaqX92E/trNDTcbpQrrhwOT5PuwE4BN 2HZVAtj5GOl6aPd4RBDBXt9aMekpwcsozwtMZnuv9e5h/XRpMFYQLKJfADUy wMpHTvaZh2izO/KffSR1iIyfV2/8ymFFStCfDZtzVDTjVO5T7VO+Abr3FB62 2qiPn6mADgaafKS4Ai23AHn9yb1Rk1sktGhBS+UG/sua6i/WLQxvTTeWVhPJ Wc7zuryEhu9eKFI8cor0bDfL248bYOjoTEd0r2Zwd0cGwIakNhEVrgDnCuTp jkM6lmDlbgqMr0W7kIFUa/c53VrKoKGG9F2bCp66sMBk7Dsz/F/jcdqZyD/E KBDvp9E6p1XkRB29dNHvk7Xb+tmqCWFSlYigdzyk5H2E8JRyAtATAh+WUm+Q 08cGoIuvleegLbkWSp0sZIDsCFXe48Fqr5CmOvenyGdPEQvzYXigbUMYWZgv pfSUBjw2TlKBL0tHNVbvSvcOniNhWz412UaXKZK6BpIVn7SpU07JjRoNni9p vUOrtBKbWqaqhp2mbIZ4DRP7p/SnkQfXXL4F7BPB2kFi1eJmEvrSeRa+qiq2 6EGJesl1lufjzxXNGtAN0oSxKRUHmMGEBVXHrhkgYa4slFigZAU8lGmlQK/e t3ExzsxVgskT+pC778W6Pa6myQb/m60kZElXIFcGl2J/QwIoGYckGJ8e+QZw TC4kzp+Zs4ZM9RYIygwHrXkAbhhDXiPw+HZTfg4kpPhrT/U6gI9chm3jur++ 1B0Ct0JC7HK6AYvn3RHxN0HlVZOreMe+wioe5O3mjzOcx+VTa2Jwg1snwuFq DF9iehGH0YV2F77fP9UbsQ+/cLA0Ksonrp5iHa9cfDyuFCGhkWNYiRYI/Wgh +obrTNK6r7eGiIGr1DgAO9b3IwrIoQ9JPJv4E6VBm38n3ugyZn9ZoMyl0ZOw JpYC08WIsg3yUPA2QDYgSuyKvHj2+DcRgUnu2XVU2qHd9q4iL8vowpXn81no aRVQ9jRbWAqKS0/LMeHk6fl7ab1B3MJ7ZjbILS9q/Uv2rvlF5wdGbCSR6aud dMZXlB2XWD5J53L9s2bURgA0HjtyXGEGB8tLlrarhzavvxGdCmuUl5Rpg6r7 2A2Olw00cwvoAIRcri5Z+k/DZULiUVo9cCXw21is5frfhlLDzUUK5pyVwlCf mP+P0DrmBSqpjiycj/HAHL06iUD7BA+Lrzer/KWcHvfEY0XLN57YRRVlwym2 6BvmE/xA+i0gdIC6hnnWcDVNBRbF0yb6xWVUHM0QWbCSksNVi0ypuoJ78bLt j+ksgiaTv0iYH43rdNhEGbU7DI/xIegTDTmBFh+x1s0AQP5SsWaPeMdbMZLu 8NTwsk4p6uKarJ0AVo7Ae1ovDGkTi6fM2br2TPRSSgf4IcsFasULdwO4mU37 EjklA44tIG+WdAuBKZF788CR/UOOTj7L1QdETFVxWNaUdH2sclUrwf6zrcW3 TaujyoCbF+wJZ+72k3fJRi0XznBNJzYAp92lLlVq5mZJfF5ei0uZW+YOSs4k X3yUnN9CLBJG0ZR7vk+EuzZp8rMck61ydvrrY8aWKzI9qSiMDojoRLvLqPw1 Imnx5wVVQNcFZNNo51Biy6XxsCXitOp4Qw4Ot5vrSPaXplkGQH36jahSnCrp m9+j7FJkCbcFP6d8wqho/uBGJjRulEEdj3KBiwTJCnkF5Lox+C3Bqn1zky2B TMDSbCMCiJfQ5ZAuQz9MKlLP8BVyJX9T5ueKjAYoVODZ8pSWxIzji/mmf2dd 8tu5Lwfb7Pa8wLXPqo2jmdB+Z9m6go2cKmpNP4z5N5DUusDouhyBGO399Oan GNUw+Ru8z1w5wfEKEjl7ZzTN4qX1nWgHULx1nan/f7tNpAa21uBms8xKuFgz MQ3bBKFGW/+Ke2ppYNpWh19yfi+87l3wL66ufQol0Qkn6LOSA/Iuh83O1BNf QRG1gDeDLdB34Mv+oFcUeHsR54xu9sbF1LcUKldVyPbaA+TaxaZf6e1Jep1K oPMG0RKDkw7WOZzB4fVbekMmn0AV7cOUbgkJSTfTpu/KQu7pFtV5CUyqysxN 7QVAt5SRKZdu4vsVF15qQlqpXS511NWYS6/7nmEzfdvrsmS24+5JqDuSGEY2 TtVdAgViTkpmlNskve68HHyuT2TazmJlWnvvGkodZP1FHFuOvHLUpLaOtDeV 6bVDdh5AaI4d75kt7YLXU1vYK6bIWMUYeJohz0JZVtOk/RSvh9aKc9Z6SvML aHo3VjxejbW2bgzB+uJAdv3sjLCCkcRQnuf5mP0y+HkVjTxLmqzB/urlx6fK clGwekTW0q5yjLBlVpNzpIHeVHuF9adR53gUr3MogVBCjl2qkqbjMD6/WbcW 0SA4e1b28tUvnGneV552NMcKTWRkjeOCiZ92Cbv/MYBVQvipqqtO5IA5kGc7 vWjqoQfcT0/j5K7efN977mpt2SJ+Zd9eGN5lgZ/i4v1PwzQrV+hry3mLicAe y6GhfPU5NfgcUH3ie99YMEEWak99FEgANZY5X4fhqLOfhuiG4KUYmfIhAPH+ Z2RuY4krj3quKh+Jnmwgo2O7UtvE0oyoF970WwAsFl6pcAYI5Anj05wE/Ri9 f/yhi60T0+GV+Urb8qox3ZQnheD+1aC5Zi9CkFyl+0QIFwV2MHxxlnTBuUTu 1DpnnEuuOzF0lp8f9TcHvaPa8MpgbxH21tkIDBnjBi8zlFcSRPRrSadGW2Sq JDaUuFxcw3xHXJNiKBPUQk6GNK2QwtEdMJ3RBnzXW8S1TtAfezQzaDdQsZEL N9GbVLqRY2AQP1r73/YSyIDulGueLMLm3dFS+uIBwWNToQEUs3iO7CkHzoGD svIBDKQaErWmFGL3/Vymz9uwfVcTrmrggjEMoRpXueFO11J23Sfcf/XtdpsD MpRyaK27C21H1ZRepkCDFXy9XtGtysdbhqf87UmTrsirIhkI9wF4aO3/m746 4XcE07wEsk89DV3oQ/KvjjZibI276TJt9oKkcxSWuQJ1R/fBFKhZ6hbLnF69 vH1fTI6a56rBYLgk3Cd6IksRucWiXOyYNuO09JC9QafBfhK9Z0ASz1/yAn5N 7WQae5JtBi83dlhZ/qRNkAhcR4J3AdspJf6rOOpA64DS+ODSEYkC3r7D8Bl4 RtSQWk1k6iJ45R6JLJTiDMnBTl8u80RErx28HvPz/pASaSuZld/4CNTIm/HZ 8cfvyZvz00M7/nQ/UK5rbjgRDCftOuHSA8LBYhNCtSp3VY6bZFm5kJiKf0aq KiiOurqq1l1/CSJ0wYfD3hcUpMAZDo1CxcZN8ghmYIYCoGn9IIBVTqdsWBn5 hxr9L9WcY8ndVCvFUbidjDu5z1S0AC5f29ui+YfK/vY2at4RVHNWeTbiITzl LePj37ectI6yh3lhyl18pAaZWTsmcAdo1hZ4oH91glGeC6FdzKWKKbPGFWvE nyKjHKMcFTnxQ7Xttxiw2cb2/4jTT8xyrqLElWSWGEPGabD80Nyc1KEY7cdR kgXCBo0FiNu6HBkrQizhl9HTqMYIh+kkAR99ye9Tarmz5JO0tCEhPg0Apanc c3Mt/HFobs2iQOo0dLd29iTwNh8ynZwQ9FlV7yW8bbr/zbTBKc0BvUXiU258 vHKE46b6V4X6kAcXGYGL9HvvpUDqBql7gk/Z+WNCKguGfMHTk7lPplYR67Dy NWwHu15CqD0sfN1svqc8a6aovWko5TT2pZYwldZg2W+nuQaYzqubsmTtkANI WeJ/IaeUiZJ7YWaRt0zpYOnTbX7ErrEQ+FraH7VKjt0gvqTUrXANBjZCOaFS J3SA1Pf8oMFjIWhsJDfT/ybYBSsPnlj1yOskx58IkzqM/obODUvJND/8Exop 9oWQHX6ARq5R+lfyG1TWTuNC3ZqhYEQs3CqTbBruqTrvGLyuz+ULFuvMpwuq BI8xNiurWxCR1C6y0mNGCaf4jJRyZE/X8tjKow9g1cDPKaipgCqhNx7ABS6H CNcnGSVNWurHhAwCElKbZtdzCnG/8+qpjZA2EgJ/fqtay0FqF3/02SY55Xid sNIbCGZpCLjxsWHROsfwRX4zooPU5ZXib8pf2xi8Jus+jy+4Hz/9BpOhMbQb v/jiFrTcfxisxK0FMahRaMQ+m81mjHCHVD32FL6Z6E0JsScqS6XHDb0RRxzv 9r1hW5vzfUzxsoI8M1QGsLy3T//P25reJrTG57xPQmThecKQjosh9c/3o+n1 omdflOZMpBHApOWvNyFXaRBD+q5kuHd43s8K4M3IxloXZvb/eb3sn3a8ZJh+ Stwyp80fpBOrwKTadI9/wCGD0JyISVnRxj+cojpz4ob+ZB4/C3DNmJ5Ukk1/ nDyFNY4CsyRuO722V8xBZgqtWDhFUDLh9LegyXWCSm0I77J1KzK8YWhViq4u mi88yoXuLAytw8Avtdx7ARCvZ4Zg7mBHvTWCN3xa6MLF8T8g+nXHNPPbVvVx KDzrC97MiK5B/PS3PCoMn4tJ6c6Pjn4BJ2ZBUcFv067rJZVO+tAJwTaPxbaP gz+4oDzoNtrkkoMB3r5eAS20MTlof0LVJP+Fx7PHjcTyrCjTp+ZznvFngJ6d 7PgSUS16JdiwUihtcxpuSoihxqUZhZw81F5VbFEqN6rUWEPiD/oWO2o11Gdy wVTcEblkGj+jRTcd3QUs1yIVOYnfNziZ1VGJQ1ZHdP2TIo3fBRTWM/UWN+jX PF/Qd1NpaRpvx3IgdAvl4sZm2smconxQHs+MXuMKuI7l+bSQ9Rq2YmtYbJOn LAUZIiAeH55XMR6MQDbKM6AuY7XLC3es+RkEFcYjLuDVbBdE9wLMtLVlHC3H R5amGs1Sw3fMEE2l494MUPB5C3qFNfMpRBId2Mpvl504W+3LImQnQFCKZwto 0s2GW975A+U+e4CC23iAM47BWZLAsv/GIu2SSLt4LROJWNPCJk4QDrPFK3vr ISD3cApQPyeVPvtrlk6Zvp9uMo1CHtg0vU5nUNOLWVf6jlE9DYm79GZISJ8/ /BY6O0n0h0iZ9hbA5Y2Ogk1P8devzZa6ts3l5anJO3noT7+ywxlmtWnxB+Z8 so5COfxIoAAZIcEnQEzxfQFBqN4Sb5HE70lgyGRgXTHgSaRwIJh2XmaemCzT mqKoRxuGqU1du6kD+5+IFpRMqaYP1DKHey4lp5XqCBjsUdjyqRPPTfwKDnC6 7eup2YSzZdalZrS8f5QveyhtLck3lTjfqCv/1nVXluaVgziCVyc9c7ykxDJj C1hW0s43J0JwgmsQLpz0I4yJ/qDC/pbF+hzfKUy1WvVDYhws5cwGI/0FOZsK o1RkMlo3Bkmq02WagyrWBKfVK7kJ8sale97mU1TUk9+GuY9/8junVbTdIhpr eZPfwWrFnev4DlduBexMd2HaoF5Tm8XijDmCyq0bPDx1dAsS1avmM51Dp1EE WXCJW7GiM8ahlT2Z/xKW6Sc0leNM62xs05+Q2qonqob3dKBoqXA5CL7nAvCh RgtKbWBxgbdqlJN0wYC17Egyc1WxFo3pzUX25ACc5Gp1CYuYyFGcGu9y/f23 5cbPsNAocPCfr0EPbg25CrXe0an6tRUebo1HSONnRDbXqrIcZQsunzPmmrc4 PqB/q5Cdf6F77d474qfIBQJmPWpgxbxG1L3/CD9qNhQW3jaHo8MjIAUZbgo/ uK5ExAB8EkBYoe66HOsBDqFSsrnoyLphpG3Mi0+GZYus6ap3td/xP49WdpaI p/8ivt8p8Jqh0SpcIZE7I4e2iGkqBhoZNs4W6vKkJ1CiavkFuHVHc7iEHGII qk9yCbyYxa3e+FTwf9qifFZpPUFE8niCccbyaTfnsXosNiPzfpQYfb1vFbo4 GytpioOUmZAr58RkdAbofYuVD4l8IUL3QCtkuY12+umAN2hSrAxiq/4IzhH3 z7JcWpntJlWh/QwWsKKFldHIa+iw+UTaklO/brEJIgN1CAq2XX0nuVlGn8At llzTIA0uott1jBj44XcHdBngUc7S2T9QyejrXiyAQq4fuGgnEV18IdqWOsqh CpMhsJxdIx4LbWP7vAkj1913rIR6bUCUlV0SrOtjakm9asrXLywr0uMCT94t JIJNe9DR4IbOqbH7+A551dc1qQqujYcPPlsNy3WbHVv5Ui8OzLvIY2PMes7N BHXjvsjiytHBkYglf6lC+6AfX8pjhNNrHoW5WCEH7oM90jX+1rrleQliWFi7 RVdohVQtPIjFBTZ3izGsJ8wa4CBUANvwHElQZbqkrFgv5Ti8E+f8Neqxus5p 3jR2YkjIQ7kXHhvEjjPkX3lgMrHKxmFVBDPXrX9awdNSxwLaW58gtBNmCsCN kOXohtJ4jnI6Slh+icohl8hEvYtU1IM4X5qooqOpEgLXNkrHbmAhmUxzTcLz 5k32rT8SOu6QJPGRhatVafkCjP8scUPnVZaez+d2tk1AyzoaOeFGA/g72LDl vdNMtdqORWxmW5Bv6u7XryMrscE3LmFVUMm9MKPFOY6Q7Ip04YN+VpFNhUM4 dVMGTLqMDelI20/7tQjouMIkot1TsqgdHkkeCXSL9hqxcQkM5vrj0h7sx0+O hH3toxv42m6bbVJxgXL4h+1RzwHf04Zmi+mRKfRpBuGwrTwx1C6pV1R0hEuL azsjMYGQUweJvL3jlEOzf/rOx6fQWY9y5jqBmSzLs7WtASt/Z6J2IEewq+t7 OpnpElndj9E08ZXTVZYj4ElaYPioF/yP0p4yngqlZdwR+kr4IrKpPx2cEcZK xB/FSB/IbYbq5q7Eud2cHoaZyb15wPgKvADmNc899NkytGxpl4GTEBL3BSrK CyUOF5tG2gKMIMD/jF/YzS6viHj2yXzUJjnrZv4vDfkEf64o3HSnewvh8M6H Qrw8aGCs7BsPISjV3yIlQLy9T7SFvm5K/aSdEcfuWpveTEfOmSh20JooPg32 ONTk/O9TI0vRDPY8zZDE15NyyRaH/SiHlrt3UghUH3wDu633TVyxBt+UyZOR PIPNUv8v+5sSBbjYekKKrtKbK9sC9w0ELsxsqS2mY4JdsgLGGbWQBVgWgvHG LhCVWauYkliVcj1tsD0Jew1/1uQLw0i/XXGSN9GMEEjEJApRugSQ7rY0Tj79 zKj+SeARxvBfcU84aAFMBL/gyVOZHzcb+9HumC+QlF/D6+0HNWr8/VnHNNDZ qB4ZRCzh44I6Ykkqx7iRxI6ds9/BQewGa9tur+TEPmJ5DLEcA0Pi9mS7gQqW r5twipooRcvq4KP6HHxW3yomWqfYghyvyTDiX4lMG6p+mkmLQjRizfuUz7Id EVfIQk1Idma8MJgnvLL9LwHrR2Hw3aVtCOtx2R98yPkx4ztjURTDge/WIrn6 mtIv2f8ZKv2p0mVSZf6VIKNjSZiDMWTqFVGLXNZNnG6Upm/7+F0i/FaxBDkY xvmrRolAEc9W7VFIvzYnf2r/8N5qxFaPX+zpf/Qd3RLdoGtI7ZVVtKkSDHWr MSfeXfPUWUz5hnC85aGKRvfCIHrcT7DWzmpHY5UiVq4BjyzAoLhtrTlyBUy/ q261E/CYR6d7okH8+tFHFKruzcMK7rY5RaSJ7Sa+1R3Va7pQKtE/iP4u9QIo 7V+z1N1TmhXgMSaPeHuzvvDFxA1rCowhnuZhFVqAsYuFESiqBCxgs2qcNkAa YnO+w1ithWI62aIfWrzrdg7gJeXykJXW/6euGMwzUK4/xH1Zs9zGoZKoqjMb VEM0V8nr5DRs4bZgYFQ3lCnFA+UyYWW42SU4m49H6QXA2G8uiw6QxVATaUBX HlzY9ZuEXA16Zu9wr/gX0jn1PPMgzD5kjgRTcW3bam4LYm5NEKZ7c7gp2jlb gguOc3/1jQIN77dlHUh1fc2IpmcpRjnFuQaiMYLuHuqSLpEaUbZwvag94ovS 9DTSaZ+/QttpNoRApKqcqyHT9Y8+fsbdlIynpUftJ4VKs7359a8ZSGw+E7fj u1i+K3UzpXq+nxDH9fdG8r0jYeAEr4FA+zfiFvE+4RCUhrovFzUIiIy4EoQt XaA5iqJ6aKz3Jpuj141bnnvts9G5oU3d8QdfLR/JAaVKakLOmqNnsiyuRaDF k8/FICAJz35YDbMFF8piCafBFvEeygFT2uUUQwMkwJl4f0S+vRXMu5dliHLc AHp0yC17X/7/E7jje7q/74lJEfICQ1poSz9lTp2cz2EbtzCMuwRIE4LvgE1B 8VuTqLzBpuNXSMYN49RSiJCu7N2Y38WLO24q8bKd5WAzzPGPsE598VxEpzkT j54vF76E83V/485GyJLQUD2o5Q14wmYZLZRfSNv3MfjnCyPmYKz5fyRQLJsq 2kSUCzKOdlSvG9gLeDWn2QeQhBdZnDmvZwBDkDXklEdlKJZ8Yma3xyhmjCt+ rpuFJslmrkUfjqsR6KoiPOF8iRdHJYbp1iMclrwbdGPFfU8+nfqVLoH5poXg Ru1X/H71+SO25mGj242J3uYfCJKksNQLhvD/Co7x4l0f5s0GkD9r6H9eFkbS Sh5dd7DKlgBIRD4kSVbJhxQs+Ehif3WHP2Ik+R2xCnM4Tke2Ft4zh0WhVUOi dd9J8K6dgF3Rlf547YIN98t+F27We04T5jeIeWsgfI7/CvwdF+aowYhVdGGD 6edk2myc6iWJOVra4yXEhQtV9jA15SYPWntzpq1mOg3yB8sUCsVXwQqziCjz 7LWAMTpzoYT2vW8Dz7n2l6iRELmTHLwCNcFSL/0nMnilDjfKnHwWfCinAK3H xLHlt9K38kBiTe+2f1DGvmG2uTKAQaVuACveGZ4+EtO40RiafDKSicdeRGEM 52I29UWeaPjc3tXHw7iIg6g+OyAAotKWV7PnzBJf+dB2hDC+TxNz3IaG7NY3 TfiiW4D9vovqvCXAn4e71UmrN6GVdPr/x2v6BvE3m0wMN5F7asnyn9iaE5xd 7Cjkfv1S1SEiz19Ijw7StLSG6RL7yCXy2WJO/thoiTqmpYMex/Uxy1zvutSi dhqjDsE7TMik1saUsdjQf4xRpnDxta/Q/YSyN63L8SBno7yZVjNU3hXznVsX RGgb29zmvkHPeZQyYo/Fz8kUdx0Ewk7tE+wHp5AXk5bh5tnbq/wiBl7/jHPX 3co3YtuLK44BKi8E+Zog1kWLRtVJXZIqY41CrWhTEAKIlvkqEReoW1sXGd0R 1rAdyi7cCGEqMgkaWI7xatSIy2W8muEHLMW1mSVXse7DZ8s0tmtIs6boo9+q SUvD9itptGizVchmuhji0SdB9zpEWiH41VL9WcV5iJRUGcQQey6MEIYPrJbi u/coL69SImlLqM+Rt+Hq4hb7jQhD0hCIN3EPnBebTva3EFFJoghDV9VYYWZK CZW46RROgFcMOWCQXdgrcSuEzXirVnvaI0ADmgsEmLzIr/0GDHQY4/CX14Xj AGVfl7/uwnmadc3m5mBkTZ5G9udtx+VahVAk+uSzqFiqPzekHycdTub/fIfE TgTXEtzzQ4BDJQvBYGE3qjt2vAoEXUplNsLuObg7MOBLqJC3NVsKZRjFwtnL JLu7j6VcHhtUxvypoFFaJKf4mIDRMeLo6X98FMUnhLR/NV9Jk6n2ZXMbgqC+ +Wj0PlVdNU/bnu85LIZeIeL9FwfMsLxDt76jTjGfJo+YjdH7+7KLOJbE0ODl DkkkM4ZGEYFllpoCmgtDQNREw2pfxdvm4rZlqU6q5cZMEiVajFtqueTq+bY+ UmbpVoTL2cRrbLJDgnw+oXevcaTF0Y5IiuYdadh3V2wQKEZk9WF+PYBWiaag wHyBjhkaBjhB7lBzaHwoL7hjuPW4JbV6Iz/bSjmkO6GFJVnfaaJW1WPTMbL6 FBzgCTrh7ocUumI7/TItB9qrUy8FqkD8rjEcsad+Mv96MQgWDi4LmL9DGxwz n7XaSCz+ZTFngB7JaaaS1XNfdOkIznnSGEUL0QfAxehmpNIAXaeAmF0l+dLg cEtnqCWT2QmiP4ls1arh9bEFryO3r9zta7UDVSH9Nt+Gn8dvKsOlnOQDQ1yk UoLMSZZiu00TBAmL/lhgbeAs282KfrNzkVm5NqjokWhHchabF6/oXO2Yhs7c rNZj42gJpDYyAD2Jedf/cXBZfuAQBjldVyX6F2TEi7HypTX4l+NSMKSVxX00 zaXRzp4L/DxByFJe6hsQo3tZHpfrJ4SQ9omv0AQCU/SbwqZX1OACbiYmr06v fVEU05BMvhXW1t699VvhrC+6iGc5KJiMyCbU0BL/s+1NZigAvGqKqdWwTgGT R4plJWSCMcmtwW4WGkin+Tsxm4IjCJE8jYcRsqApPkjuvMeXq1mcVm9YXYZ0 SZuQRssLs9x8aReNf6KiZFwqQU0n4BvB4tS8CRUDGlGImuhucnufXJKyQ2/J rJNIwAFpCs9s6rno66Th8IyitRPgsP+a50ESez4E06HbVUsP+qIzkLblNpmZ q8mLqQxoaDyepF5X/wWJVOIh9ruJEf2WAGa4q938Ik4/oUhuCGiV6szMNXgX zev9e6BzaidAM4qbKENYrbuV2kpyivCGFFTJiwtnKEq+7uGy5TxUK04XsQFO xMWw8ORsOXugWyBeV7lrvQQWhw4+2tYoT3ZR8LkIgv42tpfhdKYD50HcbLfp WLPeppdZc+FlAX99lrVFyGPsODBWQRfqdSAVA1jERHJJLp5kcuFqYBYHwwRX 9q/nBfSi934kxgi3QwdgHpWpnFwOXi44VIiz/PR1fb2SzAN++c0nsysuxs9Y CLX/rc9GzTwdu2dfgET+4cpjSCDF1n8sAmMvaSWzJN8+xh1aFmSYyO/CaTVz exnmt7ONNJCaS6IBvMgAs8oDbGSbuAWtJwqysoYYeX0Bxr2HyvOPg8edwhuf gAClvDYeyRl0c4Fki9lQh9xby31BiqAHNRAPhdUu0mrlDwGd2ihRqV88MEcm UCgPS6+G/1j3ph36zPI8BFziWiH9DtVvjpFKU/sEmEnOoSIL+ItqX05Bhdbz 87P9unnEdP1HIz8fJDrTuPHpzrOln3R3Y5HrGucbcaH31G6g7NeIdyRYAErg hp+sCY32rfsT/N+ppOOSK29b9xBGQ2FIuMcbqLCo4UGvm6gSjKaMGD0kZpF5 PEtA/D1vTBx8RZ9e1y+chxvCUzAHuLAsLmcD7Xbbj1qZWLLLKYDDBhqws2DL MjSCRsVY3Pn4Pz7glTHB+b5pstSdLG3vmWPAGmZbE3BvsEELC4rIVKSoV0bm 0ImFjA2V/E53gHojOwPiuOFU5FNmL2s8CwqSYeZq2ObMHBS6c3NzYPY/BAhe imHL8dqIhBGr0b0ChbuPjw3SLx/ewWuUIXmEbW315tXaJN8IkdxrVk3XX4u0 L1tflJTgOEZYoephaxoRfp+WD6IfCO5LHCP3hB9zoXkwxp6WjBqCh4Xc3bCk VBSxUpwGtS8D0JRISfIzOC/UQshZqb/2EcDZmNBhkk5Dqo/yoPp7GZYpuGGY Uo/Hh8yN9AiWbW12vx6f614rJde3csZ6J4lM09TQL8FH/S8lCnTyUUFZBdFz WtMgNzYLsb6FOfnDL3LvbsRtzW122ILDa0gJc/aGtir2fix/yKRIsMfLzSNJ P6crgHTu0i++bHw8yJVYO2WopHjaOKmGmm0YywjXqfrD4HBQs6m8RrO1cWwh eAB6I+38kSVXcctWtDiOyXaQ7X0WGdd4nlgONe/rp7oLuk2hEqLuI//Kly4b kRyRTwPNuRwJLG+pNeptB1q5AnE3GTFpRYi3VzEeiAB/qqO2uUdiw6eIj7VJ 7grYlGscePivp3+Zmpe9guxgBuPd+YpoloqI0NwZiTkvbRYZ3ycHU9QLnlTu tt381iihkItwMx1mRWlO0KTqBjl3JUMkHjHZ04qyXQsuZynGeNKPpyDqbvky ytrj7aJo9ej4I2KYMpG+QEqU0ru8wQShXW69siibcxGTZa5yNRi6BHsk9aHU cr09ESPUL8L9ux80eTY38lXRw26lXlHVsgDjTb9EHSRmBwO7uB5M1hEERzED GF/HBVWceo4oMdNz1xmKbh9GC/mTT+DKkwPPij9fNRW3MkZyxKGpDDL89ob2 spH0RVrns+F2/pbwfPD0zbBZ/229nCYV7j2dV44r3uU4OvoqFpCHivxX1N+0 gyW/HwcgDS0U6q3Y/ejz8AT1K7R6805+J84yW1+j2ANIz5KHR6w21Wq6eT7E 873KnJoh5N9TjlsYDA689YHL2QIFz+X8eIGaqn3apcFnYezixy9P9rw0kukz pu4SSLJgDmcinryXm70O2Wk3pDG2h244tZmVC86+oWcpLYRFOsbJdrIMTmeB TBNaP5FxkT4OA4u0RHkyWdi9ADtUSdpMcf6a+je/FnUkHPzeobL26yMOFIkD ETf4ddS7rklsPyBtDTuuJ41/7l6BvN/l2/BcujVGP0+8QfGZF44FBcvTvczc sbRkZO0v/9HYYwDBZgc46OSbOpl+YkoERFI2k89q5BnCwCA/uHx/hk/Gd7ht cg9vT96iZGDPZnDh/WaNsB2fUADZYxUJ1o7+JlqEGO+Gyg04DPPNAmwyWRKX MN3nnjPkW1w7EOAvJsEmnFHppvFKlA6T+1hrt27Isk5LBwpqXGrPT68EZ1va QgP63NmmHdPhmfWc0jXue8NrOJI4DWdRxXK2SAJsXDl24X9+GXSrSbn6csr4 bN+bhZMsqTeOLV/yoO+ZE6vw2UjW8tsntapX2mGjgb40QItGM9QG5kZRx1VY QO8AD3ZksRCVvpRMLJW8YgFqd3MVwd8wXx8Fd4InnjjVhKa4GDR9kusVNw7c ox34/FjnBdIoXS7HgzxMNmLEVPZotDHAjXPUF+OPk1sV/hNTTCqkY6J6NREF bdWf/SxIoU1CIDWQg9oZqZo7QHQJWpUJZE/ReN0dhOVjHAaWB6nEfmI1F+zX Iu/IRIoIfnrd8PUv224BX7KsFqdPAvJ+cIRfcgs0q9ex7FDHxxpuIZQQrGzI YByPHEchIa8/nTq7ddIqrEMTLERgqBJcjttouexey51iQsiCGsB2H7CarErv per7jwasFzXkOeNhN990MexeEv/FDJqPM8Czb+75u8t2rN4dv1dxVYeUUJD3 zLbBZH73zmNWz6SFuM8K4hWZaT0MmeAJrp1jCbC0BF0ziVyVV2EUbk8aifRg cW5uiJPCIKcgZXu/fGA+2YXPmLJ/JZBsF08V1m93jbm3vaZls1cVdtBhBWvs 6DTnOTj5KxZCU1MHyvWNiEyR7pRRzScfeTNEHRUA8EgYhSf9VsSk+5XPB7Xc cgm5pCxdDjquasLvPdB572M8EeniJp6kPxpqt+ZZdeuK7LV1mGC4jsMS/aI0 OwLLlcyfgNZEb6NgasWTbSDfZmPSNcA7ExKwHFWDKNAyHoxZmJzz5NytZfkJ i3UGBwbfnyB2SjARxAlLwyMaFqua0lYFU5yN6xDnECeMhuC+H0uq2TRGTdVM Cu8FJ/HQMIEAfWYlxq8bdr/T0mnavmDGiBELvR1f24liyYrFzLnHqH7iOlxR NM4TgQ9BFEvpLv2xOuLxsy8cQQ0zrL3i3VkmnTuDcoMZu8Uf+e1QGtBJkgIo YzIbqR27rujRgO2mdubu+IlTXP9CyJHRRzBxAMs5ipJyVwgHxMzyXypk/bf5 Sz0Y7mb/B61irD0k1np2sNlcaRBnN4bYuRsKao1AJZAIrkNnAONhBXXqQZ0r F4BrW1DNJfMa/+VkFcPku0zjB55r3PDoF48AknZAka43H9BUkSOOhUSC8UrA I+YCrHUApT6TXfMBh/kP0LzyIcj7YbpVDkO7CMcS0PRYolQZhO1FVHYuC3Uc llvgUznFIeforfVVzKbGoZAh+VYN97pFZvtgaOskJZjheoE+xuBtMjqT7hTC MgEVQ+Smen+RSHIb5ddT/oVUNXYCP42HX+s43r95n73j841DJuozYTZDzfsc Dls5jfAzlxsOP/0tXYvnQ47IKnrFE5hNavARID8PtVK6qhzQFmZwR8a4u1ZY njLhCJdMAG+LmNYaCOP7jDXeUXgC6D2Ecjkv4iwll1nEBMGXSPgTWPP78Kkz TCipzyFrG/CKaOlBwVuSLJ0mPq4+zHxhOhkSI8XaSqlCJncGwg4E0K1d4RCx fwFsLryt1CfRNRWiLiSusKK8+7B4o3xx+0L1qkjYZ5iq/+kVxzOYU+wIo3bC vMDejybAnqGL2721PlShxYvqlrS6wsQtDzKOlNSzfwqY+2w82M63rJCBVVlm GbKY1vuU9k0UlffflxhamAeZUlK7oDROZ3xR/9FoizR82sSFgO9Rlz4eXgy9 ueGXHsmFvwDXjSE4x5BnK2Mcarpix/ZBNGPH+3JGVC4ru64OeQJu7tSoz7pg Jxcbesu1rKi3E3EJwhwdXm38jDEf9SqNyGQMJL6u9TtpSznj+uyafRKuM019 5HkNmmhTp4TcXqEzVVahx6wALCjXYG1jBu7r5IkLv/yLjerlyMhgkAxMF2yR z328X8TPaf/WEQjSFx6tB2FFGPtUuZ4mNBl26cdiUG/4UeKWrZnjBSdEWui7 fdwOp1lhChcZWWbEIamKXKcCqLm4LLMOn5v8n9SNQWQA7UxZElCbxjGboeep pbSoQa8xR+2Ps24WSE2mZiS4uHgo3cVJdEVaOXAhm2AyhC3lfX9TtHdyZ/ZJ NUXJoHvllr5wyjTgEssmnFF4QqcuyMsMck9cuCidAU+LgRHtHNkiGbQYBc2S M1asDuGO+sKGs6sbhV7N9zzT6KzAgp0DFGnPt+CUBptCUHgP1ZFbJ9blL2pH hWGGKib2MymnIANgYpHYXsvTUBtj/1wzh3ycIMSkbVepkxTV7CExZxp/6xkl oyUzYszLDtcCZsTUvq+yoRvxADe6vahAWUKhCsTLnTdR2Z3OtWlWJCYFUxtL 931xO2VS10ph6PFEZqoXCmyM9ugsyo8XR54sugZlIj9YxiE+mIxrghkxSLVQ a8jclotQ8ZMadusjAEx0wrOe7ywa1qlSdEer1AYkdyWGJ9A5zV8CycbiUdvw GqKRu9saXVrClrs+4lpzXHqIwYAcQopXypTkzPdJZdwB9CaO+YnOMrM5tpqM 3Wk+MZREfxg+F1jhhF9aQMxVT22HVNB4vXYEKugPHHc8E9VWk2YZSjgmQfLr Gj1nVVgDu4Hym4MooawtFEQNIJP7rWiGKAMOjLjgiTRtwoUp2jA8Jg6ArvY1 1BctFe7FKiWE23ayOzzoxBVOnH9n9JWMqaXVwTx1MSlNHbIQeNW2xUs6b8ao 6xbENBMEm6aRmGoLR1t4D7noVFOorLIxMf5VRxbp0dGRdFpA4g23eChQXAco Vin6PFUqoIpcdZRyoJFqpxgatk+JB1q0xlbPv0p3GHd3UQBmMybMu7T2H42v LsRPOR+ZqDEyp/lKIBXcDBwAK4A3t47RidG0yth4MdG23K6DZ5osUqFQmfHb jX2tZf0yQ7sPkxn1yPvH11bn8st+GzB98Bvx29IgjhFeamUV/ub666kgfEvp fIM74mDoDKHVRJcpphwW7NjQnqBMJd2dQKowgqUig5uGOfKFc+dFfiucQtg+ qRf0Cd9xQwJU6XY0E3nubYcK/eE3FeYvZxG91q5CJETjbIp2aGus4USrC7FY jNQ98oj6o/Xy7m5cAnB46yyl8y/GRdsz8Dp6u5n6aJ5vd5ZZvznYQFTVYt6K rHYsvAxXiBExOfQ73CuFmfA+MveHSxwkBq3UEMvTpaaIZ4B1oeUbe8+Db9Lp Ty0B+WDdN7oM/ymrvQ9UECZIkCsPwlxoMev8BVMBZq6IZR6dt3Hehs7ioyG3 7KM8jtx1Z9W3OB4CiH3oLb0z+RJzZ0RSPvvMz5QWFvj6bqikKQuF1KA6D9Qd O5+FHho8A2FpGrbjfe5J2uuRRJ4VFWCY1E0A7x0YmX/2G/iZ+vknEDNB0apj tLTCS47853g49tivZLDV3AYROOndD/rH00sjayMiv1mOkCroxZ1z+jQn4fld kggrdAs6dmTxDNdAJKQn2yDmfTZD9GcLcSOXeqLBuT9k3k19eTK/13C3MX18 NLfhSi3i6Kk9uNqGcg2F0MCERndmc3ZT7Ky33K4n26OwXacNmj0rFP79k9Zd VZUF5xyj6yssFnh7mGlW2ErSSdKtEqQ508rEvfVwlQaSqiFM2I3w3FFT1721 Re6tplUjNMigmIxxhgShu4RzMLYWiYOST2sL/bmCLr/xU/ERQuARkj+WH997 4+B768NQEfpeHdcgydNIzoQqqE30Nsg6GngFcKCe7kEm0hy5wj0kyNyT8AMu OtJukEP21Gu7BCbG5pkUtZv1wOae0uuNbBPjnm1kakb6+oTTwUxaUlS+UEc8 Wdx5Jj0E3LXa/ZOvegJXxeOzaAv6vWN5YiU+bKltoKTp4aa8sJRSpzcZuxoI cmsrzTCrecBYRmmqBak41ZwJqovJDDMMPg/I/jqB3FvP2aCBOfjyjtaDSoqV S3GSdilX4mA+drbYZ2aB3JyQycH6HO/OCYarSbrOLkv0rNnZSSMDmuBfW9ix S9CscaVbxP1TM+f7oiCtkXsUvriIMOwqQYyKQU5gJfxBwFbE5UXHkahxbBwj g7apwMBLV99b50OwqjBMCmkVQZwk1cH9sCkhdt8imlo2Xv7Korg93MJkJ75/ c7iXhWvQz0r2NoFrEPY/mZ6eNhaua63NsUmUHKbx8ED4A0EBBFh96pg5wzif JTUaul8sbPiPCUutnLrSNWOsGEToBimm80Act5kumbVKPHuuMDCuohkQpH4P fBBfV2yEG4KuELnEF1XniijdoqMfrTfBPKf77n8z3LknlBtt0KB0SjSGTJ9A NDC3BTJ9Sy/4hDiKiBwGduXKdZ+1XaXaeiS1MPzr27N9sIWTuPhuMOcAXUPx Y9hBHI7FfzNPWkOpOwbo1voyian74kwu1uEjLIbflrFcG4SsVwHAPwTAgtVK 4pGUns3vyd26ZbGbXjM5ix9N24SL0WZwLVUNlVMpLTQ/LQMwJtEilmCdJw2r 2ZV4fZvfbp+2MrXq2wJptsKlOnlt/67hU3YWCiS3ZlWgZc3auYq8OSYRteNS 5oihhs8o85KbR2rhzGc+HqtqTQocahyYxXEnkkOWeTxP2Zpze8d7+PNefDk+ YkdbMJ1AJ76OGyjJnQvbJRHqFi+nlS/xi2Gd910/iq+GGf+d9YpwuCcW7ztr TClCoW7r8cpLDsSc9DD5L6I2j5w2T2ivfj+4IbER5F+FHXHJrHA8rOr8zjuz CImeUo7KiMA9CwX6W20COthhhq6+sg2jEVbj3vuvkCW13RUaFp/BX60g5zNm kw6Ew7xHo5x7U9XQBJrzS1aPhYslp6b8uFp2eExF5JCCChKsoQnoG993yENF Lo32GcXqGkr9S0YPpNdUgaOGdut4UBqPfJ8D0fsmz8xVr25CYspkX2Szw9CR dryCQAbeTaeeK8T6LLi1VDGNXfBt4AtJRTkIBv+T2s4esAN0j2BK9sbdaNMO wYEpd84rskwV7ti5qHZSvLSR0pmmMXSiUVZOGM+nAPcVs8QrSQahbnnSqapP lPyw87j7PkVTbQw5d82xB0cUszrHEZVahLRo7fYoNu35MIvkjmhgf+VL/vFk gbmTMkM41/cLV0PSitnhshZciWj/Pa7ZJ5GYSDsh3mkfq8A3R5a22vaD+8Z8 r/5las+FeqIKwfC+CwNtxWlifnvSk3MB8hNx9eGmEEWmzj5vG8CCNrNycKS7 C+btgle+jV8T08dMr0eGHSlDgZkL7HKg53U8vP8i+nsbjLz3b3G930d3RKr5 98nWbwmFl42WNkpFdbCZKdk4Iopzyrj5+DmRxwcK8g7QKUFUuLGpdkSogs7u Unyc7m/PEbYD1DwhV0/Q5aaWhcsH8ED0/6tVFR36HAW/rOynYYXB+ZW2m8ws AIM3WDkT6kTI6TEtEM1Ee2rHLqB832nMksotzsLIi/+EU+w2ZTh694X0S9r0 ci6vg8ZP7Ueg83uhGy2fmyCIe7fIcH1k/PTiqpi0mB62kPWuCKW6wfchlos4 OxF1mITdk/ykpxxQTFW00Nyf7EmSLsd1OF/VwZOlpQP+bJ3OzbyKJLA9H9M7 FN/gyzsTkfQzs3Q47zQzQInypndBwqH4ygz/1V+olX+cTw9S8rpujzPf+lZ8 Ju8k1Ns55ory8DlnMgOCsUDEDD1p7rE5WLoTFOXC/NL8QJgndJK7mxdE4KoI K/8176JbtZycrvAiVU57WMNT9i5JDS1JW3/Oh1Ks87dXnYG412G/lVO85CuM UN5bnqs8pSeU6EnMu22vwHozi3/LcmJhucHLPCadikOJfMrdoTaPnVJWrwxj Zj+iMwiwS5OYJyZKzqZZHxnQUXtXBrEq3Snb5mI2uZ9b/KAqwrdJkuBHIwyB Fe1o7PXaFq7BaDtGNo2xcwgwVd0jjGmvj+77JMAZ3Ab9YYT+1TvhTjJgm5RL yvQ/DlOGS49jOzWdBXOAnicmXVzSLvuBK7Hz5CA66axfw8X9Mf6egc6eUKhh nyFLSE0AGJVcDhhycrNjfbVZ5PGvoN+b2Nu+3HyogWdFSNDSuie4gLG54nZw 9TU9we4D1FWniqPy/Xcr5/wj7Gt652MgXY/yjPy7yXvEmq9A5GNP9x1Cc17C PdKAPJowA0hUPMPCfz27rb3k7V76lmHYqDNDkyB6V9gGPik/vDX7eC58Dldg ihIz3Nru3J+MSayeuDKdya/XVlGMxhunjHPbuxdt438sGHJNFQtvtJEajMVF S7kP0z7tKvM8V5nSqKUVLstgdgN+RNWiRtD2S/GayfLMtpcijabRrwBvmimw AHW4djiOeSN7y+5Fv6+dFqeNcym3D979o6HL7TDxlpSaA4pZy4NIcOBOV4ox PI0WlQfeT2+M6+hSfAhZWDty3TnESWRjpMBdJskpak0ZbOby6izQG9qq4pwo 8mwCgAC84XhZWRckLnBJ486cSjviaFtI3not0uw2KJNjybTyjgRhN7wT7M4Q nJ7q1A7EqZ4R3nASljB4xuidW6RVEjkSC+C4lBwbAnfQ9J6/hvSg2fj2Au3O jo6byiYlOLcT46BOx3MxQAOrfbcqXA6mRogE7VMBVMlloX+BiahAYaDqZieu cRboFUS07oPijMPrAA5hMpFY4UGaWEElY36+uFfZ3Cb5BBeb1KSnjE5QO/Gk hTi2V4SwFy2hOQfWeHQoSQg3Q0sFThOC7+1iakGbVqJ6i4neGJ+/XIqSLOgc qBlqaJW2j89H+1vw1mIpmE0PdvC5Xy2wmsxKQPfF/F4kqAO8QjKti6vbxs3t addHoDLwJrnhfcWkTkYTGoY3RQZA5LQXYrtv8FaddqrcihcV+K6Q0TBHn47Z mXOBEUCkRG4AwyLChfhHwgr9OlmxMG2/aQSlJov1VdOALhzUVGXgPTkDfp/h 2iKFKv1S0r1XqLJ77lDdgCl/LCrbiqe5rQCZQQ1zLYyM5l6vklNfM113trNX bIKtYqQTAgbzucSquVR6H7Ws9UYpGGO5E4+myCqPk7K6YCdnDlQooVGk6hwA cYJqBfOwhorf25mPtjZ+cw2Q1WUD1brDe1WvBjkwi6zuOydwxbKExOEXtbQs bJK5HoERoF8VfhEgHWPVP8oTusMaXNiLw2lb16xfSw/hXLJtniU8PtPKx+vM UY8c61QAu1mQsEXr6t9BUTqP7GRtdFerv5GGuX5sp5Hq+0YobLlbOqkUMw/A gCfYxcOSYp9sUzteTiVWw49BfPa8ZF6EndhfiwH6Z/GtynaO6M0QNgv5E+tS W0rR2oANyJjn+S9PfYgPkLf/yJT5OoFaw4yqKe7eshMK/8vqHnM+7l+Kivrl N9n5h44e9eJDq0VyLXRnLkgPIKDqc6gXd1xGxDjjg3vxtpZOyRd4OT/syVMf If3GVpv0Nhyb8U+1I7EHqK8eMswp9hzALMMQtObpiSABkwkbTl42oXTscyMb Z7cqzfe+6CCLiA/h52exZG6newiMjLtnYQCb4iNm1HruNTSKTBdNByv/EPkH mfXw6Cou6Qh0njqlVavy8jobhjKK85+8vgSAm+z9xeP0itXXXRylCM3lytaS EJWQwrLxDhz/xHW+d6VZzdHWc8mVr7YZO0t2UUDVE3edDN+wJ3LK09xM/pwC svEmBf5mdC/pcMgyiMo1sSwnnWEZMvW0YCgfPi3/mxSrduSrgKHWiTtPQtma 3gqKWnUtndpRCxDTdb+Bymq1dQVdWR7O1hplT3sml7OOpnpM5ucHQduKCJ94 OEyLLnvuhrldXCfl3PaqGV/3u+FE8Pl4oQNaI5xndOVPoi0MfMM09jsO/4kJ EyS2Aipb6H3YQf/jc2kFHoQlS4nd0uk2WFFKp8JayweZkLk4E/WmXET3aNuN WI7ltxI6ZFEXFhDfFJ3re1gE/mEt0MkQrAOU2e3gVrg03fLOirenIJLe/g+/ BKLWcU+hrIgiZxsVMwKLTh7Sk8a/0mMOtfPrkA6iqIyNuo4Bxc0MXQuN4ZJr khrF/PuCUrPBYJQJej9VxVRdqCIeRyEVV2/fbtwbarBqHyZtaI2pVk8oDG80 BJIg+/EuMOico3YkC3Jq/D1dFOs6pGKfvd7+UtTnqiJZHP5Uj/kqTAq4NUCp kdibpIBOE64TYDc/axSrFnPfTbPuN6mqR1MfL4+uAd45o/MHuWgHKHXg0Npw GVTx9YSkqDmL9WMtlF3Dq8KPiO1bzHAS1X5D+ATrESRr2kPpQlBf7bT9w55x mwcyi7jevHk2HJowbQ9qjGH120Jm/x0enRhSBJGOjmCkJWTob0XUF+a3WEXc Xw7aDkL38rCXazCg+tep+o6YpqhPSTSLtmHQiDiZNdCFcGWwRt+2aPTvBJ+J RILt0GK14ij1T0s+6cLQYiYXyEDGb2pIL1ICnewoHfCV4nEKMRhZz1UaMwtO C3527OX0eNLptcmHcKqhbLIRvyqNy+AC1SbJHfHdsPuJGnPTyv4gDcWyABcb dUphMEhbnsrVNMx4Yv6CnQhq+Di/Bs5gtgUBJXn6NxarncUSEijsGX4NJMVC gKpHdPj5+cJv5RkjUV8bhIPcwygS5Pz34B1l7rrNsUFSEC0CTvVh4yce7X5q OXv0qQewjXE3ROINIR5MpSD9yqdvn/bmOqAIqjuWpXKFsOdvGIsJjMkcFrrm b45udJDYgQMem0W05WKJ6HmOwguyzQbIQFEQrggHWjxkQ/CgLTtQIYRtPiW1 toK9xCkw8cfNgYlaDAOiPehv2lmCxwWj02bmbjXIdfWquUGSOcUSMeTQUTZ3 aBwlpHmb779UgD1Z6pKeaWgUyu8M2wY5/rf4ae+xMfHovPiHJP8MZaGoCRwU JjaIOsxKRfLXgd8p1sp0TX3AYZ8CY/cSJd+M5bkEhTUvdF0dfuERwtald6Tp 5+w80oxpiY7pfVd6VUfjJSatR23rbo0B91ZYVA6CnDLiDYcjt1UcH3Vd16Qa R3z8z2UPUd1AbjwY4pmRKoQEF/zi8B1A8F0JGhqlcoY6XvGTyATeUjTic3I5 dXaJjanmWxpJLVO77w/Dqu9HCOrQ7D8mMy+7YXBkCAtxmCwCU0gtyNCPkAed 3cxRrKfiq4kcsJpZiL61CUC5aaLfRCYVOUKGaVkW4BoV6vWqwYmlP4pm/n7o QN1l5+8x4kdfoiJmqqiu/sQRNeHtk1xwnr9BUi1YhKwEo7VZuSicx+oZ9BUf Biq4YbLnDRQg1cjqKMhGwhb7qkOVY20ktEChJTK6Zkrqxb0Ill1DDs98fjZG RZBe2LsxbCyB9cqWEt6GB3ZPGmPsZC4EdUFm8hr5jEhalxXFq6DFF54GU4kK KCBGTkVvIFRqmmbPrfdAzU+h2MlNLMqnxqnkmP7R7VWZTlvCmxmTZYCh0Pes ELF3lXoSTtJvE5KwSHxM4AQpiSAs5AgksgaDkTHpxs2iR/S8jt9x5Lfs17Kl wfDeLbQEASt/7oZ+Ze7LE4pyH80OGqL/FOcGhHTxYMQtnOEgG+safP6+/X5P JXH+Sc/PZwPAojLssA81IvA/RoRKG7lJifmNbreYrXJNHREhftjWh6Dr/CfF slH5Kc3xjQNZhQYZEdy09K80DSgp8+O4IddCCFOk+i5t6Hs9I6OzznmNBKuw rS0o4Drw+jeQT6rupQ2km9itCEEHWPlBByJj8Xf2jsQ9KmqQvYpThBvripsc HI3BaOMNBiMMcqyce3mVUFGCfs3W+uZy7Z+zSinjhSe1Rei/EtJUMv8MbpYj vrzhgnFLnP0t7JcNCXXh2rJxRUw9SNyDpJy5gltVkiYWBzVPbhIqY3IPmCIQ TvzKHEIkkxT+9Fh2yoU/KjWKS96irWQJZYVy+Uh4kF9GJF2M46e+Wx6iO8DI ZbT6QvyS/EWpZjAiJccfA5xfreRqvnboVivXXTWp1K+wTPoxy6w/oz1xXu3/ A2Zr1iFL2AENcchWFYVb4WFgcmNr8zkMiVi8kDbazN9tnnPLh00+Ho/ik//1 ErMfj+gR8fC3ltJ/FmYAFFATusgts1TAXcJHfLD/cIjqBCxmN/6p1upXsdgg yKtaMwE5v1P1st7sshBOoVhPLNgeNqzzIjFBcKMlG4ycloQnQ79fNGUze0O6 ABu6STt34d4UVfEQo7ahrPbP7vstxpL6CoRoq6+xIuXO+4fJX5GomGInXpJ4 Oh95kXiiGePFKiC3Vxi7y/zZz+tx/bgf1aqumO5T2KdAOu7xXkvklOYgyqCx +DrUTzBbBp9wseyroSORCsmDS8PqAiQfurvo0bfso17InWjRYu98hjoXviiq HpcU9gxPTpVCGuFiB0SCaBIBo+EubU1IZfxUeJHzAqNrOSweIDAsB6fygu4r 4ST8FnUm4dkKqpKtzloq/HucSBnXeN6XKAQhrhtMdx8/Cp5T+UrBURB1DH/Z vcO9nMzwbjqZ/L0pfnDAzn5fB1MIc3gNT1lRQbNFraUCVW4CW2RM1eiwypk8 guK60xHySO+8Lkyvk+pJWRtfZPN3EL7ZeTkPbfDMccqq1KGOgEI70bW7RkrT pnDlAvJI18ywEcHFsBqjfpEuH32KdGUJ0sLXA0sHJZB3iXkFc2u2SYOJCdhi Xu4GN4sALN29PQzNFWy9rFm6+hXEyVdURkJQ0D+UTcFOLXoIabzoTfnhqdoZ ZgW1PIp7sg5+sknOBCyLdjEG7vYCcgCy/YShGLRWcq9mlhYbS5IybGhNj932 2tbeUNAs+fVSgq3VN0ryVKfCnVSYSKGcQL+4268edXSXoktKpN3otKjGRbW3 mFLSa0/GtywCMCF4tY+n6Nl57EgRNZHw9cOyPFeVuSr5sj/MOnyUYts26w2g f4gYbZH9le152qk4loOSVadPYHK5ebbD6ypFhk4m3vlNnDRGSn0ine3Zazqa XNSGFL5B5PhKdn6Su+bxT52TbnWj9ctAm3hV6Fl0rDah+HZ1xUUSGgiyiQAS GzrMNCXKXAa8ohpNOPRgG3oQZJ0ohZADH6xQfdpYFbab2GROLa4Lro4PLtlO iyBIGdg4Jc81sC9FSNAcqCFSugC0NTNVGtr43sH43MpVV7/DA6GW99x0NXih QIDhwpSlamiSw+OQ8eY16CVfxHJI1fGNjzuSUlp/5GOiEd/BBmf5Xu+V6m8Z 1catdE62ten50wxH0P5CnlzTDYaZ3aGwunW5SAiz1Pr4CFfw5Iisc6P/SBtb AsOpQ9kdzRCd430cXeNlu/BChavMiJzULYP8GEhGk67mURXTrbE+vSk0aj+O pX54vUvbiQPedpDd37CVz8quzfthBgLlaH5zlhfgi9314csRDbDTzU6OvaWE 6C0OfMYPImOJgZv4GUVuXGzTAJUn4AjmF+cr/xJ1wkHbxmhTSD/8MQqGWItr Y5kNIWiFwasDcwixRlgxiDuScT1pRTuiOXMH6QtaFOXAejazM0ksPXKsei/+ gy/s5IFxazY767LuobFLLSnSUp7gPS2+/WBgdf/JMwW+QBMVi1nZhSZKAQdA FtGH2PENlX8HnSgooDXC5L87K8rvSCaPlYowbY8uSoYlfZVZL/DjohXFhsBb EB4uzAIeDN4qu370Pgm9oXtGQeTjPrGdLPzTKnYM/K+Nm1u+H6LEMerTL01X vN2/WFNxQc5rNcVSwkp99pfiFwHRZEYvI9YCTyTiF22IdRHF1xygZQWKiapO oA7ytZhS71HXOQP1wMJ1YBVRnDwfqSHycZHTF+mGzOg/WaTIeiXOPx8uGx2v qWDOeiNgg6CDCEAjhnxHDDoW8oN6nQhQrdIiZJ2Btv5IH3Q8RQ6K+S2cZ0lK b9WDFBeUAPEfaer3zA57L0cKHC6GLscLU17v6yoyov2LEKJMSe8oO8gczCmh LOf4IOmrK474majWI4duBehhhkO+DUtb+hLPk/o/FbhDtIxAQb+6fCJCwwzB BptJ88zuAEhikcZ190u7HN0fg6W6qO0jKdtEHihCRxTo6oy1A0XTeD/IDlNa BoqAZS8ItX2s6cjIvTysmwx3BMhXGRvbs1JEkw91FWijMwnLsMydv0w1mjQ4 GcscKfLaTF6r73VBzIlFzmdO3D2CELSFywnPDSRGWR5wI7FIfPwFLwnH0FFE e+zhk9zoU7Qtgd818sOqALZX1W0zRDOLvwuf/BFa9TQNsSuJlaiOzCwJXJ6A kvY+K+rgcw8dzF7ZxUcLCuJgTY1eG+VGgR0zS7vtS12JXioBHd5cIiStnIUl E2JMlEfWuNIdCipZXScK0B71UDud2Km/M3tJkYnL1DxsAT1Nx2sxDeJwEEg2 2yoqnzp3egQ7ftiEKOyaf2x5M7uAi/e15WwPg+var4gADpc2gYeivXRwUYwQ t0xr7EegRaUVpQv9UTACrv4lwY99dLrQjUjWdKQP+WpNq/tUdNkwjeIRi0g3 acRHEP1R4pXRRjauWStmc0W41SoopIQQ8gyASdZj8Vu2nDfeWm1XZJcNn2Vy UFP3nJ8hGQ+6sqGK39neoT+wzzCfEp1KCGi3120O7KoOqVDq9XlctFCbZBaX /GESFb1McWA3dGNFexqBWUkEozisO/5pX5/m466pHVmpTMEQCpW418MRaIR+ clC6sHhrQfZdapMv7Kuk+aoJGBrSjYBKHOV3dPfO6m6VeoSNk+AMfRHqAkbx iU9Xm2sOe6L6LbKRAg3wTcfZ3DZLMbhn7xC4yL/QmXSq7L2/bNgApd+waZVk nBJd65aS34n+brA+OVGKBMO8CbTjGA212sm8Ha9zX7xChAq2qN2zjb4ujqcL 0ZKhMTRAMoxj+b1MEgVe5KY1FhriYwu3aTCud3cEVE1ScS94paOXrmzFMRul PWFe12WSZq0SMgrXu3Nnh234rH9ttkghCgK9QJm/dL/eErKbx/qHsPSvqMeR wOnS3MKiZhjHBSJDQH1BnDrRfdR79modUhsZRQVd0mon41sOHTk1eaqEPe3t qBzy+oZoW1dNq6wB+2B7cldmN4IhMU5P7qLeCb7l10qW7kDWMctBUB3aoPBH RLcZotbZHz5v7Zzi7G4pKEichTIhxoeonztI9cv3qzLFN9/l7w1yuDOEMrYR fIu74C9D+Gzwlh4noxLFc0hU7DfUOtlOSB87MKxe5tXpUpbsxR35Qm6AICNG LKtN4I909/wLcCtrKIlqcNAqPBACY0eOtzwCjvI1s+OkQeVxMQ81RcIIJxei fmOC1F2Esj+WfGOl8HeQU2kamEkRdgBFdC3H+tM7rroDH7HZ3o9J2SKNEMQu MsvL30N30QYYZj52T3DJ+3mbzajE/T5s9zF1GQtqTdtIXnTxm1ea0boNx16D tDGPTP9nqGJa2HB90vJeoYn9VN4gvRKyYQ4352M5Wr+gRjGmhwFVenkUILz8 eqp1TI983NmXfa5Hr7PFXJGz5mPhG/HTW1KbrJ8L5psMEsz1V/4wdTd17LyU OOuuEzVQoOMkWGoGjn/IQ/5xQ20s4cR3JVU8K/akkej6JeksQ8LqISSW2EPo KAAiU080g/4vjdFIGcXoTsXEMpdEZPg+i6McqrHK0148xNU9iyOxuz8s3+Bb RPgVFAo3EAESe8G3hGSaCshZrVoWjRsDNrrDRqzuzhVYUKAwkWggU6kADFPX t1ERhwLXoISTgs7pSllPBtaErlECWpiMQrEjGdc67oY+IIR3f0xTOKcY+Q1p eaUTS1bUBwCnRbWun15RB6VjkXe+g3s4ENuA5crezMqGuRG1Rc+T+Jr7eYko 4a6vTLtd9RVIW/3MADwsLU0xoyguNyVS2dCiYzxCZDC01j5wm9OuzrXkwP1E TCKpifczToieEMPooQF/e6G2cOEHXebd4pjxicYs5w03hfXsL7q+hqmpTO/S mMHzaLURB2XBAoavmOg7oRuOH7yXeqgRmAaRT5IJghQJpWKAV3iU/lSMeUtx C3yza09K1eTLTuAXjmqrh73Q8Fozuu5lNra/GkcUbhBQ90UHaV1EN6KdPEdi NvZwol6IEEwMx55W/tTabqSm8Z82WxW8S+GD8wznyOFimuw7KKK/rbhKqQgd tO1JjlIuABBVnEZ6nCWmeGXq1WIzvb4Uzhds2ayjC6JAtBmU+PDi3UTR5NN3 RiZMrWK6RBM0meyeTEGyVxYf589+I28EBfMJo9bW5xU3fnZm3Y42oZMkE5yk PmgIiHWD/Gg1k9/f6kHToHnyd62EjzRRD5vM3tF60SryegxZSj0GzU3rrIcl 8mQVvIFC1yAbpWbsJSlNkdHyAkMpGLwK2rRrwpOOkmAKekVyQMIbsV3UTzxP KhhZkdoigsbCkUv+vj2fs6Wo35gyEzpRJzQdytPrDWOWX/8pW+LGt68mt1YD LOYNVsAnWXbvPWixCNwfzWtF/8/1qFUoX74p6VllkoC4gMbqK3mWO3UFHnFQ 346uSQgrByZXG7Cr7EFqc2AI5WMNtpfTbMgi9XEqOi9n8o86s0igWA+lCKiZ kPRWofiAvTuPuqrMMUUKe1mYVPSV5CkPOg6JdSPRFXCNKf6ZfyR/kYzD6N/8 C8K8E0ETc5DOGdjZgJq+vh15BuPZF+UzN/tnGAd6UiWTD+rxSXbcQQ0Lozwv 6oSpdzI99sdbLrWprBfGTy+fIzwKb7U7Unbzi9tYqbmtZFntDLaFzDitbNRf WnPoTqgY01s81vLwglHjVCsp9gfjOlKBsM0iHT2Gf1rz8SS96sh2m/nIFRS3 78UHWnoLkxvjodimo2NtYI6+qFoFLrhigcgnpmcTs2VAaJqUsKDGkaDMqiM9 3Z5lgFbxchEWx1ypUgWr2DLPgk5+bvxlKhVFFIj6bSmiooNF02te0I0uyoTO JjK9D+jHQ5RQM+FGlIEuXhk9SY0aV8TTZJfzlg6it05314fhsVhCY4EOwVkC K7Ur11jif6kyPoFFYIx66plKw/nxBpt99tFsrJjyRns4rKx/VJersyPwAAur upZXhIxxZbgaDVvtvQQNmc430KCNUtDkYefTzFzzGoV8aftMllf+gFzqIcU2 8dPVaqCmSw3l2KTUBMzYql5gobENEAHgRnXqcNb3MAKfzSc//kzwf4oU6VO0 pC5wwKZGQCHAnFi7ZSxjPLHcqDsmWjJ+oznoxoG6SGCinIMeRFeYCfoQcVDY R0NCfEphG5Owy/uo5uBI+R0o79Aj1wjstejrRmxgim4Qt9CwnuVbmfOdq7xt P04ZCKDb8ptAEV4+W+yXB09UHvn+gvyAQ2K9XPC+FAxXHHGq1amPNvJFEiPp SsTkjx0nOWN2wdh3+J7DEBz/iQRRvqpLZA6KJQHBtM83kVB0F4898wmt1mau wnLjDKt5U6UtdOVGk4ZJj26dmyt/rCNnsAl8QvsRtjYlUBLeDOSDRr3yeu3N obdbl8/blY1AXNPJ//2CSa7nxF9iR9u52RKDDllqdKooIltlOFroiMWb4s9T ENdF92MUw/8qv4mTkd4d31YMdrXzRqiUogwB1cogSd1/9IoukHOSmuq6i87p whsH4e30M+fGXUg6K+hFZSJ1H8ZKnkislKhiGVLtDA/8lcResI0HkC9MadX9 KMZNQeMMv6tmBPq8nu4+FGf+36AJ9BSCDvt2kL4culnohENc0N+QHBlDd9kv p6qDbiT70M4xM0Tma6qtZS/EJhhp2pQVqGKPwMJMyiYfPx4K857FDBnvP4O0 e73i12VAPefHQ3quOWukv31qSKwo5zZi+ogzvJGq7Yih+ywZpwJSjyDBIGmo yPDs8rWymXp3SeOrUZAhqsGeWTiZN29dj18rFW3fX+GPFe1Dq5lRrzJ3TtU+ ul2/VV0PGymw9xJ6Y6sipgwrIlG5IvJo7nq7G5DnRVwgnYrXp5XUI51Hw5Y7 jdCPyp5BiC3HQB1WOwa2N/rSwn2IJRUToHJHTBRJIoKTRCQ9l9PATOfqfguS I05jIFWkB5irFCF0Ss+Izv7AJC3CqD57/oQj6VDjHtSyJzyK+VvLB4JZdRYb 9vQSJWMY2IWoKvRhx9M7XxHo/iz1ZEGN00NJwyxR1KcOspIysxYAKCkPjAUi 1utX9HbZDYriGpzOPiMYoAZjaw2YB7PW5W0UJsZOT21sTcCjM2OwiHnkPquq qHvnT7hL4Nfo3Uyq+KkEDsgLIyuYyNzQJLWL7uq+0/MeqgmENBwkWHz3bVMR ku77+ZqD08wNEC5D+ZxagY5PPcnREa98EHj3iYO2gmq9BN4+l0Jo7/GFeS4H gNm4BDuXiFyPclZMAH7WNJLna7Xt7bVV1L74kZ9K0xTBhhmOWbSWfnHHPYIm tBUB5oUrK37BrMub8gzRwgKyT9koIO9K+4oQa165jmsNF+dcKRB2uPMucjIh unqwCIV6M9JkIgAeQx8MvWYbOSKD0gkHRbog6f3KZpvU9gkB13ZfOPj1bUL4 THIF2UBcYToVSzxuPl4EaywFAlEMKYHoQVxuzKs3r2ceQ5SlLQXPs5EGETZc VlcMLQ6Staf4/LQyrIcrO1HqV3yV1+9Ae9ckpQRMS8dF9hIBESM6dptIntyv TnQUbCwipW9IPrZxqiIh/MrievalHE/CJ49IT/Wl3wjeEp5YVNLEKltpUAWL p51otkCs9D7TpsSvkiEmXhE55pa+tl9CLzOfz1FW7vMvuR91echxo6IJbVlk oUfPI++KOcKxumW16iSeyTklpM1usRghJ3MSk0wdWspKlW/rN2Jt7uxgm+7N XBUknIq09X9ukxD4OnzNbjE0HlNNYXRmYolDUZ1XPjsFPOtTj7FQTXAmXt05 HPYGvelF10tLH7Pdvl8muqDf33eeSGk0anYo7cDDq17WDk1IRcwAzUW6ajFk kMtniMUy+hOptB+3HcVANxD32oTXEPTw4s62xFaFsNX248KobhXlOmgQPtIB 4QS+OZ7V359QgXuK3UTEcHpC8k4FGk7hN6/FpIjLrROC11W5mb2axMRRYXuf 3sQ/LjYgmqIW3SlNH2Ljp4qQsKBNhvhW5xqvdVmmbyi/VVZf59fiI96fa/r+ gbMbJF3H1BMX86orjTJn6yAxFHRkQvOPttTkcjR1+T7s/WC91P8EQwR3gJGm Ab9SsSGb8UAPa5lrlxnR1RdjCGMfNdofyreuVXJtv1vOdLb/HKRE3KyiEVSK lVHRtf9VW73F2H7M2p1gYQ1M5nOzUu4+MvYA2sxwo50qcnqnwtdzs7iw7Y5P Fr8Mj2vOrs7UZ6B8GLHslOrwC6iSEtrxQQeeKC5RfnK9L/sGopT4eoNrz0fe yalEwkndgnChkk0if6+T7ehIN2C30rjP8EMe3d30ICN1YBNtFDl0kbFcT0xB S5zdDkj+iD43igdOrPzSFCHQ7POdS7bbzHEMQMj3h0i/iry/mMbf537ySRR0 1Oo96XVfqrIjShnEa+bkGAwkDiL7D1su8i/RARWV/LOtsDCC2PPFsLtQH6N4 T2ElGYcMm1+0KowF8a1XB/wwute+gOtpJ6qDtiAMeHcqqz4yArpEm1OB/9Bc fLvk+C69isxhA7jdbSGqn8v9U+z+djfEUtdjhb7+pZtwyx1WkNXSPcEAQzbV +7Op5WbQci4QwU+xVzj5iawcnO8y6xHNCXhJJscbTNo2phESa7gnAd4SBSSG ILYFNivbbfFI/o/ZKg1iSe9qDWnax5tZCpliZEeG+r+s1t4IBifk4Ksj5gwB h2OU3YJOx76pkO+qGpug7upJ6wt0ZeENdHnGYzyJQgt9Jaew/lc0FxAuQmis 2CQwOCjw3YSOsbNyOe01BAUeINlR3f637q/Bj/bKq+stvA5K76SQtye8Hfdo X/oOcxlCxt0dRMzcP3Vx6r745OHwkRrt3E7ySGGmRGoje1bZWvB0xlkWCqrG IJ1zd0rn7L8tiL8R+oEBRTU8KVCQQsqmUmlKmaUmbKotR+zrC7yS4CrcL1bl 5IIrvedHZtAsIXlTDLhIbGWHl69PgNflOVdCOUQR5wS76zIpaaSovJ1jLDMi MgWcOhGxucu8YgMQMw2PrplcByZTdhDJIX9nv+yy0zWUuN7ecRT/rKYcDKHr k3MdlVV46r7EFtpU1Nbv6akKTzcte4Hy48fTCgJK+NHXAPsv/JgRZY22na0h inStUxR9Q1lM1zqNETrQC1m5qOnRsD9gFTkyTdu8s8hf14JNgHXs0nNmUqup Sk/5HDYYrK043Jv95yVMb9QLMJKzpBKQLw+fXlsuHXztaGcM1vty4A/CNabt o1mi77T5zPiFGlHjALALZli0K0Ou2L0PxCAwrCtzVx8kNdS+Ggta+8fHODxT x+ocEe41DvBfGfxgQ0EzW0Y1KzBW7klFzSZTG4PviLxpXfWgGtaJmocfP5zm hHkhIFbL4HByu4fr/9yR+geyXGqhz47N5GrnlvyNDpiy1BCA/56GUFKi2JWN IE4gZlkNl5w2YzmbjkX9wKJCB2ZyAcHUBdLZh2NSCZYm5Mr1U1Odevt8GVUV xDy7FxXCQFZ47RLreRbEtOlML+WjCHWL1tkEBA3b6K6yYGyAM7dJtq7U4+RT NOOB3KBkgmB0X1G87PyogLsZ1LIYXBhe240N9+fqDcVDRHwa/BpStgSjaE8P e4K6iaxVYGbhkTJHNBYde/tR18d93TZ7yf5VXPMwXt2PKaRbLUlTO94uFII1 J8HvBXanTJ/Y5y3BU3c7EaVLx/TKd70kgegg+WT+6XU7lebTzxbxd9IyCqse SSpqsHUPXPGgJvJCGirCJKvILOLnbwdlOBfcZxAdtBwMID51aVcxvtuXaOye AYbOqg/kAvBVo7Bjl0obYl4GbL2HtSxCX6CcWKTf9LL2KgASSWbnM2wJFNOF V2Opul5EPyNpHbUepfhUky2v8iQIZgmlGV8PvwtsNWEqsGKGI8tghk65gT2W SnqF91sW+TzkoxPUh/S+gZn47Xgg37xCjJH/fCQQrRNPCbZZ7ZECo6QgNW5V C/VKkTK8KuIFw7+j2T6RKMqLeW+98jVi6Thf3yB8MoOgw5MkQTrugeAImk6m F5y01PV9w2Q66yQJQYo+QmshOqrvrb6Xg8TpoKBo22ToQo0NuVs8q8llnI1X ADANf55/cKa1mOx1Ai3uofyADzU7LXWdTG493Hopfuu1DDcbs9xeqDE2WmMj AVwIRu3aaoSrYllTCbjlYiDJPtlf6k01s/SOYsdZmyVNtGdD0NFQlacA3qrz 9XNcZvwUrh2GLaBjsX02F1oYLi5r2zz5EqG+4n27qiCUDtnQXG7bzcc9JCY3 ntBIbo4AIwjHDe9GW8tSo27xD9pqVd56lbfEIyyw8udRx5UvOelUpU/CbMA9 0AKk8iIdkD7iFFqMytg40p9piirWGPjkaeBkpA3U4vdoDIpEg5LUXzrzsboG 9N95iJRA7Ht/n6817HQJm3C5fN2XOqKkFjpZjMnWQSS5BieHC5Xrs/wLeYLz xYfMpV5y83KRDF2TAWaqK56PfihVk6tw0kPJhy4afEfiO6+YpVMsw34F04vf kARFw8q8dXAddU0O/ay8/3NqiIydJqs92kYZsNh1lg7SMJ5SxwBC3zgGYjsy UfC31ovQb873WYQQf3poG5q2hsFzH5/ralv9yLIQJMtW4jcq0xj6ft6esonI UPZ2QEX8kmmY5KLuXE3szlf5w/9/WTSPR2qwNN87nUjBi1HE4MmT1E7cWb6H bvN3heUj0HZs2KipH+4ZscIg9lZ33THZ2tdJV5xeyJCrmSK1wqeQQqhtOKZn oAYUb9uB0ZphDpuI0BgWJhrXcglKlNAQjQuo5dbPlRZHJd+giQ69a0HKMv6q 7WrOVwp/2d9hMtQWZ6bdFaR7EKbu6oY+HHcMKIoDOuhy4bgKJ3st4kX5MlQ4 XsBfcl04ISWliv8EiG0CXY1gpod3q2xeELs+/YusrCs7g4POgmbCZmT8u4lP ShjS3r2qNLbh2pWYI04B5OGXzAZJfNRTz+3C0JN+fPA1ui0a000DKED0mvBR XQutHwaqrEM2cwhrxXBg7ZNEG2+tf25MOcOedfYjMobKSLaJ5f0GpXyAU2wO nlI4hAP1y5m3rjZW0Y+g5QIHFg0t9OfZfGBsLZJCrxLJFkjezlZey6L7fCad yMp+F8dlkO7+VgWhleNBKcVUhuWQNHDou9XqSmGoAH4apsnzuHEiplR5YorY oai5HxNX9i/BB62EP6gXai0t5D31dMLR2KiPFtppNOFNdpDWF1Ag+Nhunbii eTVQlySazBh3CNNJ3kCA1Um1o5vxFehgBIsjsbutrh+J3pFrdqL3iMQrxrFD uWubkE9a0FVYhWofbp6lMZcT/MGnH/SyHJ5zrPC0SQ6+f5cOBlfyRB635huJ MLBt6kvXpGmfiZbYDDw6C8WUg/9xcAp7BQnwowT3Twwdw6a/6ptj+rAuhsGK nY1cJi2l0yOojgAoQhMPZXNqAWueiv8cYlP7kjBu350z2gFjqNZHdwrqJg77 9QWM0aS6lsAvmmFsEmF3vNL4pdA+4m4ozXcQ7kSgX4egpSvwptWH+U1EImxr Q6XSLZGiQ85V1+7zVxDKATasY/XJSfj7ifqBQqU9u8NtcFKyXii/z+NIWUt5 NyG9E8q2jM9gxXOs3kCQY5qC+TRqgIM3fwI0kV3MbFxcxOTWjs3EBa5Wz+q6 gTeuTNdsnGOIKiGGh0giwK3tSLBrSyxk/SZIwMwQWHnwkxyyJxL0wuhS2/+0 99zIGzqLS03Ttvj5QP1+cFNdvNMY5ZC314nM1qAFO0dFDRvZdzd2Ax53z6H/ P4Q2BzZuw1fS+C0/tT9/9pJgwbVAfcjNJq6wYDgnnjQ1Gq83Qtf5fGlYLWqf szr0zpGlqW35DKiRmshtBa4WZuRbtBN/5idOuZXCIGTXeySjigJPbXO+viys xQTWcQaME5SyWIDBXsCjdEt87GMNRpv0FOEvPcN3pxuHk5VLzR/TVIovb8bo LiYMSLH3qFztKsGxb4SK0c5K5j3eWlgqLymeMb6w/GUVeochV3kPRmoEhUN6 D9oOeJDAPvq/Yx+xUKHBO2x5b6fdAMvFDFApjmfnZFBfYPei+UhhXv9eJsdZ yZfMkx9eSAHWNrYoiK22qYPbQc2EWRM3rVOiuyBWKLsKvbi89TAhsFu7sSbC kdV88GhFIHbv7Wlcq7kKVzEw0+mRlj102xeWJrTmuimkhh/+arh4LS8/0Tm1 Zb0jQSsPnl/hot1ks3ki0dai66jpbbQ7++juWePZGSEU4WGjpBdQ2qolF6Cw o8SSf0MEQAFLiLKlNR0+sUveMMJLGFtU0Rn6oj2XWXB+5xmR6CW1K5X8l1nC XekDUXhY+MceHVmdU3Hhj2cA9WDvyldQOKAUzIE2g1H0HAYb46RcOnIZum2F S//jmJlxs5doKg7DuVfQC/OZd34AfjPkC437jCx81E1doPJAzqo+M5elWOD6 l2Md7iOupgBZlnTjHSENyI0o5IngQzyiU1+ydjTqmh3cCbhqNDvvh7UT8pc9 9PkRnSXWz9vUrgGQBGmqU1YnoKr6qKRkvE7zPtwMcXLqiAMr6FqTv2pBnreV 7N+fS0R5QXUSPiqJXS40fUbrPv9fwF+98hJDwpZ6RW78pzPILANEpzFy79iX YnMLGt9aw6dzoDGFKewqAH895PXVu9kHm8O6DKcgKBk7TBPRE50nfwthWcKz 496kf+UKOd7RBUrLM9xTiNgESMmVYZf4fckYCYHmU+MS+7A8p7GhYiTRQNZD mzD5VnpfZu1Sn8/li306LV5ync3mOfjMXA30+F0FuCAzigDudU3WJlSqFBTB A07I43AzxIg/yTuApxLIim9MVAd4Q89nZDVyYOycLvy9fDA0FAePdA3ee3er LWb3fHNXGZowGeThRawNSSFp/++KyvPMZsaIixQpY4JD4KWKOO0pLLieZqaw J6r3jp98yBn4gpSvY4To0Mm2a35mX+2b6jgMqqFGk2a+Lh9j4+SdE2JKJDPT vC42SYPEyErh2i291yrnwoTXrPzgWD9KsGc+aS6nsNliweGntpVE2KbVVH81 LxzJf2v5W0ive+NikmVqnEuQ1YrbniA9bq/XWSa21nA/TwxBy8QPal6+54RD Gncn6+U6yyZZt4PPWHkZWvGrYcFKJZjbRr+FXlfgmaQoN/JXZ0ki2tftsieW m6irlvomIEkFQSw9VyZ4LdZeil8LIuvUhD6kdrXiznFtHXkWCKG70QsF7d2d luK4DvB1/HJzrfO4RrrOhyHOk4uAZbF7iU0+pO/bOuWTjo2AsmNqtR3OPdsn 8vT6H4gDjz4kgYdoUIStWH9ulNDyi4VQXT7ePI2q2EkXs4BiZJ2hoaJOxLaG Jpr6k+dcSSgptUE5wbUMd7Wf8hR+fIrYSWspFXKXg4q0m7epK/ughIYzlPG+ WtWx5pVN5RNfBRmYJEoVsijy+uNU7UowqK6HIRCUZFWkKbAcfPM0D3M477kH Ki08OW7nrg3CRzU6t+z3bgZ41urI9PuFNKJAMbRceBvTuRg3ojUdptxLPDkW QF5J6o8frEwVKIGcAcdesKc9svdZtm5KZqmxz2rGZrxp+MP8ZzaaNjdUOckp IO0a2WXKgh3lDSlwkFjzZT2aw+eXAMZbDudDs89oKCzUCrsc46KZEd5S88+b X0QGgb+nD3c9h/lWTWo8w9pWHqN3TXGgf5XMA3n+SSRVNWi1CoHiDcm9Gto4 qGw5vda21cAiAVG7VVkgLa36AhR4S5gEoPXscQywiDrUxpZbnxbo736aLm7Q m6LvemrR3NCwI9iwG24MyOc2k45DPlZrjU4jevkiy3vl22OhEAfa0Kc5T3SZ 0LFf9cNvQ2XFZVnwOm+ID8ifwdScNUY06KtElFh6dQg1+e7mxsa6eRHM+Z7U ObNYzlqxELqW0sSmwKClHOUAvOQf68xzYO25rC5g0OMqi/PYVVKE+QCeS0CZ 6RRXyVrI1T27+dNPblPs17qmQea/YrCj59yJU+ekY2PNLX0Wey4QBNIazlfJ 9yAAJCsrQUlRdFXf1fw7s1SeFA+OYCPg+kAZkf6jp3jAuyPakkbrCE2a8D7p oDCGN2dBIgHh/lKGUHEHdqfOcfyI/NtsOU19axKDwNRZBJaoRlGEdBh4lA+k cS3uXs3ger+IpddPaiwN4NW0c04lU8t2J9pWSZNyXAEtYs3XCUmzQGHJqMdG 6IukdayDMCKR/Ll/Odl8P+2nBKWC4b1JZLOr+yVHkt8GS7v3QiaNzq/WnNSx Db1VAHCoXusqbAYPeD0RU8Gc4QV5bYudDcUmwN3zpsVo5qat3OPoazdq+NyK ydnsV0sT+dt7HNBPDhcS0jCi89ZKOho2EjOPmLxfSNtCe24a92R7Fbl8D5/u VWYL+mcNhvpPcdpTpoh5XpFIOQNa5n09mO3qXi6Y2mR+3ACM4udxXioT5VRj ytXbujlVsxuPPtwoP8P1mXRVb72K7a3iI8eCngt9j7Da0v6aRoaoSAJT94Nl vSLkCSb8SYgn8NZT3k+igpUx6n2kYE2cB/gn8FUcqlqIupIPvB78akYY7suK rsg+vRt/9qsc0gTJfqtzY7IDocyhzeaC10VXtlidzuNdb7vs9uyBSZHn6ysA 89MOl/kUz7m419ybhbq3+9ZsOpr4fgLrW9tNG751n4x+pQnk1vNHG+NjL8Jm 0GYTy6m4d3wan591J+EmvdPIGokvWtO2SlvKYBH0Sr0EjKDHquzWp4va2XE1 5EEOYUfu7LiMeVyaKFRAazrwZhT2YOkAACHNmMWq8mgScKSWoCxRtey5NEZt PGY1BjFr27R0iNdHMAFl+P5H8E8gfLGd/dGrxE/OovZB2ZMMmH9c91OHvmTQ npbuYtctUENU4C293kGXfaLseqKx6p7WZGe1Lo9szsqDnMy7PJrFXIKnYJpy rWSIHa30kxYqPhlE7O/u7ONfg0HSPlYQAGpPsT1OZHyaNiCp/+52aS7GeuFH DZnQ9sQA966f4/fsOtlpsnMRnVeRhkj9VrMMz8+743lYyTyu6MMyzQvgN0eK RUK8Wkr0UKDjPd0vWf5qDI3WjanDrKoZqifsImU7+l0xiUsIGWx1g9rbtbt3 l8uQCjTCvTOkfpjUkDRpzxxQlkDjqcF5+qDSyI6rGWbKpugrV/ftg/u+ghaA vPoLGp+LyNuDZJbSDO3RjLYR8rpOWHdDJTxlltu7wL21lHO9ntH3AuiyHO4q OihXGqmz2gQKy9+dyEp2maHk6jmkSbvFVw0VdgdeqtzdpLn6MYIHGk9304hg eqXdYUPy2xthpqT3lluhumDp/RYnOzF2pPTBEvp/fcuvowf3ezJvkBztEO8a cGilkFKJYHikrTSo8k9NqXttlUlxkS2O7/x7yXGSyDYXUhxAMybq+/E+kF/7 phuQs/KARjqxp8xwA05ako3sdqVijhwKJa1upWXE+rG6UMgdE7pyfWoX2fD0 jP2qSDErLYzJ7FzkUlm53TJm5yXJEppFVpUDmNyEck3FkYVvgXy6l6v84ZNd tkG32EzL90WB5aY3ayb1VUznPnr/FUsIksnYlE+ndvHML/ynqfOxqo/ejHAn dtGxfg/63WjENdZuDzpx/n595nxb020wOUf/Um5rJEC7HvPeae1xPLGdMcEJ 41TRnn9UXTSxiNZorIIX7EQnnOzXniJJKWK4Q2+XW+VfLcoih3Ejiy1sTuSY 7enJoWxmuAj5oSBwvZYwa7SP+MequuRCOSo3RBjvE/IhAWECx9CD8abBkdkI Ps7t4v9a4dyteSui2MY2wDbQmwjguxL94ttvf9wJ3mvQvoQTkPWQmn3Vnyg2 pRaUX1ri5ehvlgwCyNXH9lA2S4Pe8POJp2UzMgSd40awxve4uGkiRd8s4yTp YhXsNcJJrG+0rzwdX9YwuIq73wnjJL0cFdFH2DOElfEEomifBtsGeXHJP2p0 xPiilWlmPnFkIDl40X7vWZKeOBTdq1KZbSmEUJkn9NMaT56bmI3suRsVLZIb cEriF0QFQHs4lHFZhgPB9ZdYZzwmitAmJ5SIO84YiHd2Wvye776QJJjYBtNl oVOVOQ4yxBm7fBP1dl/sqQrVa2of94fmb57aBeMt4SqUTYzzWpkO06QFkwfr Z53blRicyPJtLLBJgwuwG9SH2JXJ6wamyRo1GIP+/zL2iCI+Mf72lLEwBus7 6uxRzKkMT2ADtajl+PtA3+DSjs8KP0vSU2hwo3/7G9Sua6AZ8GHnQ1L0qVHu eL5BIs/hhafKWfSNO/Mpjmp3UefYbpHIMDY9RY+/IxYUFdZGk/kHWcvCh6A5 FCycqE7gMBAvDI7wCtRH3Eyx/DbY8MaNmpLHF/vdPd24XtDiVOlequWPmYfb oFtiv0wUqO1p4dxuk70ewjfti2uHCqpiJl9bri+xOiRjQZIS4jRFcPFmy1Qv fAaL6p5SODn3T/3sQ3hRGtEMzUnHC60Kwmv3pzy4ULTUnoAYLCoQGqhYF0S6 ilMBFp6F2i9BY4JMYoeoTrKQPLX0SGQDbsM0wIW5/e7zHnHSceOIHsQ3EWER 7RNWXADJvMYLhNB6oasbnEgHQZYy0H3tqn0Hj3NBDZjJYci6wnjc94A3Rcl8 fCOuQsx1bzfUmo8xGLs0I4OwPOcT5mD9D6VjoBQEwrxrvG4KwICZ/28w7+9E vnYtRzmrIOOAeqLuZvH/CC388lOGZ4E4+syu0YXcBAu7GSj6jUopGXg8vzNE C3jCUm7F1B6dfcvUj6iwxqPiQ3ogC4DPdZQ9DbnPn0RIe0rKbb+IIqSLrP0q lyV9KlwtwJ0KFhKyTPrdrUOCtmjZwp9xGRbJs/PA/AMK7rmtRQqoLcosVQa+ WCPsPt7nIcpZK4v0q3abSfu3bwd4P1XzfsBPY34t4sKVjr57Zq4Xo2Y9h6/S rWe8Xsrr45rLvq5EzNSIQhoDONKor6Mgl/FxxPfgskMeHFJGhZopw8l8aUil 6l/epytJ3QWsJNou3AtpXOv79LNyyTJyfxp9FcLs8DXIx/YgYXtfeM+2Tt2o Dy9oYqf8waQSHdzLBhnwTPFwIOWMY2uTLtFCCBvA7sl97sj0iAR2sprPnJc7 jvmgG/HozbLS+s4y8/1GG7KrdSz3KXeNDKOHJafMEPfMEz9LMSEO1XJAYa/4 tpl8YkJxc9WCni1SM5KrCCKAgPG+1DFyXOydk7JPLpq9+R5egJCBiU/Keftl c+6mCMX9Q242Yfbql4VgowxOzKPh/tDcSjkGGRpW8HPRWVSR72oeX52aMEoj 8zoOg/y/+aLhbLqtAC4KrtblYLgh24ZQMhGn8OtYnEn5ynzdNuCj4PFFxWz4 IvWfXfM9NuHCL5KWap2Ohz+jguy5Fa/a/Y7bQlsxkd+Fmp2xFALLlu6QqMDm n7bQfuxJcTi49M0Wx+1isvtW5BFXmSg7VJ63oD1yBOGZYSgVxhSeXReQ0ckY XK+ELo8f9gDFy02LgwV3FC+deaQL4HrRSqJmvaaLNIPO2G7KgMme0HAFx86s s67zK4wSrdN0QuP/yt7t1/nkpjW+BducfXe6rDJg8hivYkySWsh43ooR14fT OObxbiB6Ij3vxCODDjL/phIxAGVAshbYdAHi1ZKjlxSyTSTEh13Ayjho1JfV pYf46+7eEENXwhJivNiNcfTyxqXNTuj/ROC/qb/q9sUI+iDi0+i2h04UF7/c pPwdXBMfhObPDUaS5Is3AtDZNHVh8kQTzrl/HgzqBszD7N+9p6+4KKzwWq6v 06oXMD32J5nYKhvFiMmAPUbd0Igj2hFR2tW49BFlxdOCPe1eFbOeEkpagPUi wvjFuk/wrTASnBc1pYwDiS9rJA2SbvbWR68LhLWWLCV5GsY4PjBKp5WUofbT lg881+Ng7mmBREAk5xrblMrTcVK6BRE71yPfhKQWw4TqBQEl0zjotKBhlyTo XqCb04CGgzjD985ale4k2NvTwgKyNdYUFKqXt0+SJGY3VVDsKa3fwoFumIea 4kQm2yS8uy4wzm8vKaBgonmkRui1EQpcC4in5FO9eAiGwRCabE2p7GVY1x/1 YbMRdaG61dlcxz79pwkPnDv7ikPgJn2ltbvZmvjMCT/9J0tWspaDfZxwHrNk 6wjZApwc5zyPf2v3fbWJ+L8YcFsy5/jFgTaYZmM2lCgqwDUH846m8sfoAH2J QaTMvAT1W9zj8HBRo4WpPkIKAokFoeKssA3+hgAJtXgp47YK5M+Q5HNpYo2Q Z2EGLiat1cLohk8bvBXTz7Y+8VE4831ylC/Jgob5zmNLHUwAyS+BKn1Z+M8q lVBDUYEvgh3nxP6Eh9CbmT6L1buQikYeAGHALXdtJDL24ddtu+B9U0kI88NT euDrlwQzbYUIL5B5ZI2KEE3ODLsCY1a3LIVqUrxYkRXlBxtHTi85QvJ3Cf7u 2YwFTUdMGk02T3BEmWkJYNkm14gXW9f4hOm4xV/G12vtQ3TpSFiEaitDteJI LeUNxwAmHu0+9AgxaSQjG36N1hcgL0IMIZKeA32qm9jleTHVZTWFBPjtlWYO Ta1F5oZ+hcPhbB1IW+qEaIERsVlGEBBG5+dEdqL6ZdNd7tNmvhel3XbzPfkM qbW5lz9Fb1anzxpFGz/wMLvq2Zf2Ei5Vv7Ze/dOaZnP6x06+opXr26XYSjMj DnSs6YsYkwQACzMogJa/UDKILEQ2JNsuR3/KwfPsoVedsxkrUjVY1r1y/FfM r5eExmyak3XopfI50cXlYkr0fdKNKE7h6TfgWF+XYsTC/DDGT6LNzTBE2eHw znpHE8HrT8/rcqf+FtXzXKCVY6aWl0D74T5+yek2ByZEOtI2DGTlW8U5DZ9G cj0+dzLG5p7goKCuhKRcnFlH2S9O/wqMNYzgrAoZhK3jeGuxlmaDw/xtXbrE Q48jt2hrp7UO4jdfXYgDj/OFFg0l1ZGzYWMATpwK/XRjj+G6uQiuPNsepBMK BThIwq5hNfE1rcqtbKufqb8HBSW6hGHVaTjX9hhWNVaim6WqzOPiSPUMCFXG Uf9jCi8KSgTtPGESYh2XuthVJcNz2g6xopuKje28ovywPAi2RZ338FQuN8xh xwR2YB9buIZa99uxkYSLKTVIm1q+YM60BNa6w2c2RMm+9tg2puBB6qDq2ed1 dk6QaGLL8J/kdQDQLdxSOzlXCoMLlr/cxuu8SIx+c8OikfyyqhplrCRUoS2U d/jOfbSx7AJonbZGR4hfX0nnyffXliV8tmDs8zpwIHACBWyqXP/DZrvqFH02 pedxgHvvpGoXBw/dTpUPB6ef9TkNkLGoTCiW+GKZIRlJauxbbgEWDn+wBEXy mz6eNQUlnKbnkRDNl3LrlS0AoDQtYZis/hkIuRfTlGckj8ohCW4qZAalGYbk 4EB8FQ+YELWgIFrurcQSve39hB2TLhG42TOrYKI2Kuvop+G0A6Vugq2Dc/CP GYFbShZJg0mw0WrRkLtP9NGNNAYmTIUMmAOWDeeA3upRuZE7pkWwWTCyKr7D Q0F6c6TdJStLZDjuJpk7WQBya8NtaOSpalag8FzGWKdL2rp8w9zxhtNqZuAz kO8bujDcLcaZMeIHkxUl53XIEFlefmnFODxwWk3btoX924aS6geKzZAtY8fG HwoTOzPHF+VDSF1ur5G60dV1QFCypPYARFaLhWl+YkaL/+/4yIa7BGm7wNMf U+RQpM18hBVp7KUbNklJPDQ6NYn8Ula8pyoSrBOw+OOkNt6yh5XLUiVp+eoU 9bZCdgjFERCqo/hkw8uQbGhSUqOmA8+FDFpZDKBdy0bmzIGGq7ZMJqA6nhWz rnPy3BaOEQnGPE5sLbCCDYgFQyhlYU/rKfYv2h/Vo+LoKSQWuXGNqJfX1ovo pPqMRin6/b1SESCWDfoHi0uSWj195xirRAZ1RmbgvEmm5a+JXatnEy5z/Nhb YESUNVNW79mIC2FiViQxHQxnOvOGo7pE2SWjQHo+X5rxLkCVo6IE1L2q3KOW D1jRt1n0JcM19JLTztbczhACmZp9xooZ3gNz29vEp+uuoz7CojheJtGTGRmS bOvSN+1DuR9J0e98yFO+e+CaWpuZ7Vygupb1bVksF0LVcLpFzD0YhiaUrz57 pQit/lvCNRwXmPbGIpZKZQZ4zOhzH4hVPE/hT6TZ/PzrFQHSgbVbS60wHwEk DqG3CUaBOQgtd7pz1MqkIVGbhhHc8bg5Ux/y7u3ACPbQL+5cmhWXKTeYN8xY 0vk4f8KcE110zDcFMZk8VHMDDChGNeSHZPE6C7jB447cLuNT9IYgetZfMzr7 b+cq1nO31TG7WvLyIxi0ezz+hDxnuKtPnwIlRn1z6llFQ14I6H/fXyY57998 8/RRG624kaGulbN3gIRN5bO0pRL5yNNbkjduZUGj/AiA3x3iD2bGbe/gjKIQ C+Q/KtM4vBAWuQASoEjcWGNsvDoxK0mI0UlRo+ov8qleshH1KHCzcURwfYLo MstgXQe4mELfIzaUFxLwpDz/RzCIdMFFlEJYpKVszGDQ+76XkgfsVDVJRTRk QQEiruxuMV6Pm6/5IVa9+JgqwFL+I0oGpyhmXP40EN+6pSSAoXPYyh7uonDQ t3mMoP/p7Vu9RKAk2VBF/FBlXNty9gC0eAkczG9ymZk/RNjd6t0TyHeQC1x0 hcLKY1Ve3e0ON+AYKwjWlC+9cyLfMs6ipKrxCVnAI1DGxw5jpP6DPdlOkSgm DN3vho6hBEZn78inLOUBtmHfK8Mzvop0kcuSSqmx/p3uKVaZ9w7qQ7mkTwZc jd8QjF+HkIxhkPgWVu/Ptw+mFp14PnrHKIo0ecRB1Rw8W3JsUTP3ierwV9x8 vBV1OvUziicMzlyGaZYJzF/2MF0hFca/wQ4HjTXqeXygPqQ1ZllFAj7Oe84/ p4BYV7GriH5pZXC5OfLUTHLjuWj6DDU0E5uFCJ0r7ZcsoleuNJg3ul879EIw ziCJzAsMB01th7j3UbSltnVxcX59E2Dn2+Q1flyeZ8mbZFeBI94xMBDFRCKw 0YVOzRDyHgwBW3x38jfGiqzykS5+9oeL/GmmDRKevmZC5wqVUtx1qgbCcHY4 7gcGE3sBuax1GKIlREkTYurWvvIcTYef2ccPx75l8EYYKnpqsR+AZIB14nWM ttmJfvjAU6z/kyOiU0pOxwdO8/oCjTgF+k1+sdBjwm8AiXCuJgPsMEM9PaNW NneLGP2p1JRDKUn4oGzTmh7j6jz07URHbvZQ+LnwHJQEFnuzSdVpml6S1pe7 XgPDQvRX4SIhjQIoomRdBguxzdVrYtyIp0I69v34kvaZBKboRq8UkdcgCBrL 2KxvGHhtgU0MYq5/3dnyyI5ndhjROYCmlRuJ6qGE1r1n1Lu0xagexmzvvqcZ yAo2pHckLBfON4wuBzRj5iHY6mQ6nwYCrBq/VSGzFQu5atM6XqsZN0T/XEV8 1FU7ERwpnBIjEF238cvnXZl2JmHJwxV9bx1ghf4kLEF7dERiimbRKKoiZppN OGMvkc6+cnk60hDoJ5TvfphT0AEMR8K9EvY6OgSgTVPZuEyjoWwQRCIMKCfs msejCsS6rihRaJqwfoRhSoAIlBSHEbqxX0G6s0kxenZg6f3uQJFu0Mk3E44u Uwq2/i1p99Lk5CimbR5mF0MCkm3Gyu/0q9o91P5BLBvKxROjrfRPgo9+LHre FJ3u/2zGxXM33nBgFDUUk/+QLRBM3tKmfDA5Zgo0x309WSHQG1MRI3rsT6M9 jlmjhdG2lcd6NJQYO5CHxynHK5YGrQfDQdqKR91GsWBlqHMUFoZ23ui017yJ O3znMKXrPv4wpf5tYoVgIdAqyVqMC69h1GaI+XWANf5ZzPskAtTKQcyr8CWj VPgrbEx34SjeBC5m+ziRFfbFWs12ihJX9RxbHoBRvihg57GnOnMUAUAYfjGk IiTpVze+vtJTzRZji2+w26S0zH653mSRr08z/p79kM+A/cRcix1Q6DbQHFti N2Ox+6gGFD2tTqzdNe1EjQhPVuadAV5wCmsMX0JR8NERp6U9CPLjrkW9AbCZ BxluktWL33tm3pDcocH7VZbroLtATC67sSorq6cgIKapmOFJnc3/tjn+r9Ep Ofx0TMQpt91Cvnj6EmmMj7NcxkXCzRM4Qeh25u8GH+ZSyILk+qxB3UHP+avS 4WrLLkUN3N8dWIDxBvQg4k9RxQ4jaD+CZcMoFkcooP+fS7GplpRTNPXegU4O voDbIEzstjaMH1zFdh/DD4db/LhscQu7DJ/31Afxq505tPvhFVldTNH3PB6S dFgPghhPrMpSw7SaHxFEsso9MCshNbkQ4IbR0SRomo+HFK0SRdToz0+yIY5t qeo9cX0pjI34vGFOGXMmvz/9j1+IxEv5dokUslVj/ECxgTvMnv57fxXdT7C8 6FuHOQu4HhTqaMZ5fwYqK+wdp0ydCFE1j+7opghnipbuBB94g7LAawEt3zfH JYFTIa058uTng8shG/iFMJsoBEuEVyf2cMKBcZH7N2gIbjHITBmeOgZBOUFg eepWuGFlqbBPWipeGNYUMhD9pTpcZaN7WoklVlderTRjTtXjjBD1tbz6b6fW AbJRGblwaUUzU087lOzlBuNARbkxkd8zAFBLlW5rD7l1SnOf1G9IBAq+58Us 1uI0Oa1ifwXwZ6fssm2FJBBBxIxL8cNVRlW2TGf4yFrpUPRf7VNLSdlajiGh /sVG7BP0srMCZWFXYhFbRVYLnrnCspGhg7iHDev/+/nrLSAmJPfLZ/80SkHA +CYvhxOpbGg3/uDtmhM3gRwBEsSvoG/Dp7B5Fi2R6NpTPYwgF5ZQq+OMrZqk ry84oC7irqp0j74Hrh9+og4nVj7TvUTFXUDGI4jnHdKq2Srbc/Ae6b5I7eiF M27+NFxaYElF+XZXlZAP5E5H5obrt7mOMbAjrgzUWPDbrB1MjWrTcNesOWXw OE0s0fmOLa1gK8PZkLauX9Tzhza4klkiq+yK+nYODRXY37J10oqclfQEGh18 DPfF5c3brok2MVa9n0LjNJ5EYx9xtCOTqGOdB6I9b8jpIfV1lK2IyXUzf4Ob pgmcnjEM58/O3w3HirR0xBlEyvZMlJr9Zvu0WzBkmsYLj/aZDBK3OT2dAUBl 7re08JZxoN2bnBqGgf6CkYBOjbhGkgUwHZeI15EHuAlYg3GqpO7oUqvIKUB1 y22So5epdri7ieqcOxaIqBlbGPDU/z0FDjPTx211KeLGJZVtcExBd0EqLG1U PIgVsHX92NqBGXwDL8Ij+/MVMT5sc/2lbKcOkBWsxG01z2w+MpJvBPrxUSOa xBPSL7ZI78XW0kxsvrqPanqDXFemPFXzq2lEY7OQWiiwZ+XaVVp92zvxt18n AC+VgeyGr4RIsVGCFNYCXxGnH+6exsBdJ2OrceMjUKGNWFkQ6M3+ciyQtcI1 HS94ptn8VAoameN3LG1bIznxEh0q6D7AENZXTQH5fwyrtHxv4fDlry0WdUMP idohuOrmSNhbwzrMAmcxN95JulducceDUpXXG4F9yHkxB+SaaQRduOgAvHEn 5ZRS8XLKchNHicX6+mYrr8QH85r+QHTg1j67MyVu8bX3Ih1Pl6HvCdWqfkPV aY/6IxKW77Nx1r7r6yMuKLAvcGFAbD1MYwp6mOGrziQpH1SDx2yQHUj+cIKA F5qI56mS7VfQxusXoDE9U+vXXr1EKVIWKylMPnP8rBlvRuOPws5iIWOLrmwp 4A4PSXUgECqCJmK4FSoQPfuhxrorMwE09L3bkcUlxpwlf+RPETjm0k6qCvuc L8beAGHB8cULpONIQxw0eVRXgzv+NZTU8smzCO6h7IczmSIvCGmp33c6hXkU Gs5tYvShRxC/+INau7IGk5TQPgZpdl4PdLA+23bvoXf4/a7HWjB0hUDbl/0k GdxwnOIoZ6GIqAy67aTjVzeLkMlLahiX9f2f/5OKLeigEvbkVNnRew0IuMuz StxvdcJIuXiXWwHa1zdIuXOkElKXTVaXeSa5DYMjfGTBRRIw28B87+Z32b8h Z4SEViIu4mqvHh2EG8H5OoeedkJh0e7CG/JlynEZ0aiKoZkN9b3Zw/LRopbT lBr0FMtM7tXUBixZOcUruz2dti3Ngwairi9v9MLnzrEoYalk5w6nsD1nNJVS hSXbFy6FpI6ukPNQ4bLzx7r5SJRk/SGOHAP/KaLC+sHLZrwVVTc+BSMDWgc+ 8HID5bMAc4jfsdQ6hoERHGdl9pzu1dKtctbNLR4qaDeOWCgZIEzlE1ASVJ78 XhFalYrfxs6KYTLXDwT9Q2Qyz64+XMLvGVtOzlitzc5hCmL5xbRDi7XGrwDr v2kA+EUODFLmUIAE77RXXW5S+bd8k9TUAR4OPLmx5GjpUY/8rYS83VfecoNn yaOemGczzftPpnTdcaHvMwUfPG8irL1tUGE1D4CJiyKB/WbqjHbpzGoib2Sh oviTmEKtksTx75s6qQst71C1EOwRb04JdZZhozNmZCPj+SK1sVsGws5v295v 986sdcnfZSe8KhDceZj5KYvAXVnQCyqi3iksk6ukT/5Fb7p/mPpIZfUoSilV p03xb/B0AcNYc6LxXkzCiQqP53i8oVUiBQqWee5/1ChtyFkh4Xa+hHuliKvk 5G89/JeKQ6mX75K/9iC6xD+DRHOrLe4PNWUtjSeQx1A4tn7VAu86fXp+fTHJ QDt5PYIFvbHlq6ScM4+m8T0c/JkDOiFBjIYIAnIYBtFz1GBPBZfGv07YGCSN ga/fsGfSqyzwRl/WcChlHG4AuQSe3/kJ0fHEAihuml4Cg07K2MxvQ94tCSgs bUPgAnL7hM5bOcok2xRfUw8njW46gVF4Ac2xDGJmzv1VoIjiY3sNMlBSXYXd Kp4rCbllZpwGDJ2srrzsFbmsS1juCY6+W7FEjE3qd3K8mwMLJlk4DGkK/6t1 6L6YIXh5MMtKsiQF/ArGjUEvyFmvq2cim0dX/uwth7Iz1YWFVZkOszaa1ujZ +4hGgibaCcc4IC9u9mTLBl/I8zwc4S7Rmrcw0fEkOv7mTQQ7LnD3QMYJ67rY WDMki/vLoa9hfDr7QgBUkGjToK/q9jJzMpLbfrtXW2khZxocBxPeLgZvvyYF 6soAKepNnml6ICCWD3259ytPHKU3nuUvwgbwJa81295My/a8osDZnRQAHsef rGhK4br8wZTezoSa0YVCKDR1BGNnb7FR57Y0w/j8Ajja45PJUiW9KswUmW9d 55q2N/VjWXDiigvqMj6b7DDQ3feIn8OsaMrrXe4zaWkSmqiMtryv4FgJjecx WYwJoEuLcWgTSycYWJrf+wQ6pt5AWvQrucST396zjGhB8Nmr6TDjzaMQgh5/ q4i5WcAEDUngVrFlcYZUL3NZWPsNEB4OsabKbQVXFlDwf83ji5KrTffj8Nn9 NFKmA3AwUlfMU4hEG+eWoRUMyB8JMT7ES9h95igz8nVo04hR+iyy4FQ+oyZw p55Gik48JjeZEGYHzqyeCETI8zoRAHO2f0RK8lwU3quzYdQtLrPj3cgzeyCC NzCbHtLZt9U7WrQiSL8ane7OROnfmt+wFIdRSzyr90JKp3hZoC2zq14GpIUf 6zI7WmC/2mvP66SqZX3ksvoaCZjgoz6hflZidCTTofLHtMHVUfrjkfRxJiA5 8houB3s+CWn8/SI2X1gvcIBzcSHwVrXEh53561BqxwC4gDzhw17JcTsI2r2m aZGMG40eFJlo3a7FPooWb4iMvSMpgGUWPrB53jSS1KcW8I0nPT4gJm19cBpn lMuxtZSUkeC35deHhh6XaSRQjxecweQZbD4Wb/t65QIjZcTRTCNoyKOikzkN XrnDA/G5cegPHHTUzehoc8kOXqajwG0rpPzKTB3W+4F2uaiGjUu/SrmIy5On F2brPvhGz2Kb1qNbZ0Uy/1ItSzjIFUL3hZJhffSERa/PBma0x2UQdVt1eA5D r9vfXg4f0x6N7JERHTr+dVO09g0OGC/TozlzvM2iynWxPb9g4wnX3E5bAICd 8DVq9whiKSJK0vv50a+pRG4GbuFpYlnkLu/Ip9ysoY/A4GkCttlsKC5o1D65 vXxZ7BLE5Es+BTZlz1hPzuzRmuvuY9KoUaTFeCDWn8OmBhKkt/pFKC9gZE9n GAebPPNQ2xHXzR/CwgJoYZFUtXai0cFQRi0eIWtQiqlNWARGIANaQLWOSGja TUGYluvYxE6yevE7v7SobTZXopPk5rHbmKWMTOd9vCtYTQU4Frlm/0/qwJGg 9FbLSMrdSwL1fkZpE9YOcs6rlLScC4pX6jOJ1G4DGIckKEZC8w2MQ2uMqro1 BCDK6G4Bjvusq/P407RWTdV35PeeZQMUQntrGkqvOQJgOj5oRvVhNtIVx2HN W7A/U6cP8B/FR5GNdGSR/TJFcsPSVBoTLrQlyCWgUAsx7YiDfInh2xvnL5rW THACP5QcALj1p2LXOCQ3jYk70ou6aA3sPMM6SvsjeNU6vPC+X11Mzxkctd0u gUht1gkf2KetdiKUi0xtqorEer01nAubLbuVAKGxOIZdbvwX0InnfJKkV5Dv BkIKkU63urd0X3VQqRu/l57UUv6S0MBT4kwkygZ3mya/5xWo4eFK+QSJVO3j Vqv3M7cIFBSlTeytFq2gR9ZSZkCSfLoqbhOWi2J3I71mUuyL187jsW2HIQmz ZstZ/o7kGaT6vwNBiBDq2k8j7SQaD9aH7s4t2/0BeRlY+Ww7kx+sf9cmfszd mnRZS7okeTXqqUj1dtogD4Lv81ILFMNBfkhNVaOFuMKoBfN1k0HIIJb/dZKy u4TZJOGL6BokG6iAKBwCIRNfcNpCasWftXLWCFzkXOwZyEMY+mnwg84JO4wJ e782SdO2LEDoYjNirYLTKcodVVSIQfttUDNUV2IpAoYTz/JjKKQVkWdcarAt Xkfr2htftNO8F61Twu7z7kFtbUjSkdafKyZRHVbcsNW5PIHzfXuXdibJALR0 bGN9k5GT2fqeFAWvEDvzjdl4SSJftJF5uF2/bixsJ6OiBmGNA5ncuPKol03T uLeMg5l/Qb4kjaRkWKM4DJSy4E3byQeWkYs7TtGvNVn/SXmaRwJAsLWvlNPL KPhOS1FydwcKosupX34y/c+/d0hplJApFgKRnd+ewaDymwWEOU7m0ObCSBRY ijrcAGnS6fR6CK+txZjQqDr67e4sYFNxPCVHsDejrBEG8DjhFdGOX7BlYh9z exWsUwkT6sRayOY1heOmlB3E4OMfNB9+j/WBppLhx5rlHAGqCLU/oFiJsvdb f2jjh59m9hWiYIScGdYQm4JiYaBW2zVE+Uky3rYefIvhMCvQswN7RLfPa617 IgydbophWKIEhvGxKBR0ioBHXZhac4mTTlowLWjxnizJ1Ud+N1YYvM7sjr74 wdxbZpDf3UJGGxVYHAOrJvOXVd+hhTTxl3adM90xLBb8okvO3u1gL0/ms0js VPMk8XSYhqOay0jQt1zDoPOJZwKGMcMAMrvJXd6wfhQSvVXUvhQRj5RRYG0S ocYSacBJp+pKWVR0VvwWiI8kU0T0JMWdgXCZJR+0iApV5jYZ7FCdF/f1iC8K sm4ZwXRRe71CHpEvbSFcntUrv3cZfvYFw34vDT8ioMj4gZhCBkw0eAKJBRhT +OeUm6ym4mccvomaKphYyeswR+oXDoYhzhiMXUgYnop5w6K0yu5E5bXzwP3t 2KXBUKYiJkeNpIQcSiavoedLOGyz6qRC3LWx2EANIn83vNOKckH6CC2AJeUH R5uhMDAB04DvdPtunrBmHqjJp0IJFUTKlvpX/xCU7HjB4ATG5Cx02xNd0uEV JAGB4llbPhUN5EGd5bn8imle1Betjo7b3zUU7nHco2Z4v2Q45MS50QhMn4rQ H3Pdbp5QR3u5sc+5LUbvZFRJPdzeWBcoVsqyLU9o3e35p6oYg1L/36pgKtLy UpGGw7tqKPnzlAbUkuOjoyi7SxdyauEOACgnGKjWSfOUrARSAddYV2mVOVUo 2S/YVRf69UWQPVmBDMsNEuNgl4WWAIe8LmjTgZi9cMZFY6Fb98a42+KlRI31 vFq3KUYdjzaCHvr1poHoXBj3DLbvRu/esM6CIShc//6xQHlERwdy2/4uljt5 IcdydEyhyJ0RYk7fkRTLI5hzMrSawS/OZHQFwl3gIKe4q+ZcHadsvEOQ1Kwd cqdNYz6nEwxvQWt4wTz3TPs2Aysb31XT+Z1Nd0VL8DsDqNHoi7bn4AYjCi3L wr7oL/pfSEgvqMRYtwRptx7/AL3LMas3CvBNsGgKeqZ33sfscVWcm8/6e6ts sWxBJ2qEc1ZsQ8rzxLyJtC2wNA3DmPtIGYJHpQhvk7C2YWQs8sIEg3R1aW8k aBXmtJSpBEpAyuznHE+9VuyUM3It8KYfbxdrkY+roQL+Sr1lTRsWVoPkamm1 ONcxOeBH8rSYuGM8gQD7nhwbRfLAwIcHoelOpdRlmbiiUsjnupRbMLfm06SZ k+4iRpvycOvw6OJS1PlHfqzoYkqOfkdp32Y1FaZM7wXWQ7EJvwsAZhW/rqlz Im960S3iPA1Y4IhkeASJU6DqRqBoP2syPg2cD4dXIl/5voYtSkSfjnfKWtIr mqH81AYSa6bZUTjJBF6auYdRK1ouWII8YZ6h1rqNFIx4Hhc9A+gMxj43Otgg IYEVVTzPJRE8AEFfXPeoF3W+4gApDB8EiDu/thCzYFa/E+YOfIpd/lAO3sPS wTKncjX5TAY5xKxhUBJ1sJvtdK7n+1IzP7XvixsjOLPzHdXwoIrwaINtY85+ Q0/YeyY+xxLgNAdf3+MLqqteiKpJWY7Tq6MZZYRD2wabFk3wAobq7WKI4xlA nrj8GV3Hxg/yb+21OW8czERO4KICmc2bxbTuviWy9Iw/518utAb2pDqiZh6X cgZISpuSCGQrodN6ODzYICp/lBwouaL6+M7+CRoJA1RUZfM2WohAJyAIgyFj JsbMbW0Urod2qvwIeYmidjrxJL6x4rPhQfxNEwuP6AzxDapdMPzQ238/aCXa 0CGojNR6IPjRUn/RmGosK8syD/pBK/XpbrRDgb3Je2h7lTIHhtlBd4Gs1I8l Dt37YyE914IcJmngMiwCk3MGLXHoA85DkoL1YyDE6lGuti//hXWTV0n22AZD LdIeg0zWi754kqd3bC/M+EjOV4r06zMkJTlUE7gfFL40RCEJoKYW6YpTn6BL gxBRW0+mp16RbWH0wZ2SGSfhmgKhet6svHFOlSacU3558sflHWf5yuaExTd+ ExVCCJ+F00EOHehpKQxLwh32tAd78koafltnL2F6f2qxeDpgByqovgC6QdFF MQd10de2bMC3l7feRH1wxowDlUBslRbyA7aYiF+xxdx/l7So8IN/0hZijVa7 wKgUQmRYJi1JwGS9/mn/cqS6+eETUAeKS527ePTjYKFm8Dbbrh58yk0Hy23Y UDz7xVpjC84Sy6+Fd2DH19jPtLg4PHOvbYSYCueDXieeAlrUc3yiaKpF4Iby 2Itpff2KWqhCqcGWXTwO/j/75dA86AnUoZwsE75uR5ZsPruJxAz1Obb9+EKB wwjDDKyG2WDOt6rJZ+vEyGS0D0zDOjeQnv7OwwJKubDY8BHt3H8GjTHBwzeT PAQsUlITAsMBf89ZzRdEyMtsRXpUokYfVxh8Isd9qaC/ZpNX4/R3ssA9bM5x Jqo+VNpWmTfDJ3UQ0+rXLKH4sE1kgJSn9x55WpigB95mKdYrfmzmk8zMQuFq nCYeQy5IUXTwnK2MEH3eyNqnxfe563LXPzOd9MeIljXvH4NF6j7kGqesYR7D N+mGQGekdgv/uqYMm1kTup8lBB9gyCQp8tvrR7yZ+ncd0lmpRENBlUTK35ii cjCev4pNQFOf4f+gHGo2iE2vgqoronVj3jXwbIKAADuV54BeB95R163PCO1I 7NaS/W+DFzvyRurXt/qwFxQeQV67fZ2R8dMbXEOXdNCJrqRePu7jBNdbJ4pB jdxAVymJOXK0KD6TEn17eazEi2EIBEWY3609+UTXtrqvWMgklekn/1/wRl4Y aSzPjxKfqrEF+adGf/N8nvuDVxX/tke1xxoSuIdJ/YfP6VvDALmBfQmzOW3u eKTOYH3g/bL/h8VXr6UxBChVE2B/WoeCNyL+BJyxTA7MUiybsJxTTlpwpqj8 9H0hZjcGwvLkAdgdlZzET2fZS401Lg73zB0iSfUhMZgWUhllvfx48BnbRh1r I2eaA4NOePOFelPFBYv8WK9UsPLkvGhgJPwYKNpvhYBHjhNLNAquel8hyDNa FzUX5vlRuz+E/b9ngly4M/R1y0idy2B+k3sFYoN27c+xVV2Nk5XbAJ4Nu6GR Zrmpo0FwVRO4IG82A41nxd6LoE4gSUfPSGIgoU2lnGV79lHM0zhQ+oJ1g0oT AF7CE9MmtbttQ+tUsRaKP8/bVPW//GhUCuFcAZiFzayC9H6PQtjPGm/w/WO9 TkskfRuejmi+UnBWq8wJJzhABLXNpO5k2aS7cs1ZVappRwI8WIBMTptPPrh6 rDG0TuByqFvNdSkpStZnxte1F0P1S923Rott+cIC2sVMV+FOtircVLP21/+R 1mPJmBL6B8wtHc/QfvoFlVnu+mdOnzglWyS056QwiT9DMLY/3SmyUGKs/GDo AgAAAOgA6AAAAABeK8lYdALNILlRGQAAi8H4cwLNIIPGM41EgWfoAgAAAOiA MAZGWusB6dQJSX/pZ+MCzSAUydnJwHw5AYNrPBG+iwzYF9leMyQle5kpU5g3 joy/29hYT9swz+zvdBPEzdwpciMRYRlOotvc0LbzAgEMG1CaT7GynCm+E5Wl kJLEgIpL7n18CmOsGfbx6GI0OO/jb1NZ7pqNwRL38Gl3n9Pkw6vhIED4HHZg mw4WtUTq3M8iZsgzKinBb8LNzIeuvbE0ck0wXzdRn9qyoXTdsqA7d15ZSIYe kotDZUqYUFGpZ1CW4w+LhmhNahXjPJNynYBGIyZwf3ocKY8ljIiT/+R+5HH8 aVBKgpyPYmUUYWpElbZm9Q/+irGwKLqp6rxe3dobsqG0JMqA0uBGxcpnXlFI PIazuvA+yTsjJi0sVXbGxwAmWJRdrckwwic87XQSJicXyogA15pzh8sOMVCQ QuQYA2Ab2Nvj+HQir+1473WG2kStlAiNJfkQFu/Q24K4UUfnDBUUlteO0Aeu tvz7gR+dt/6tmZciwdGqX+Ugpk8pJKYK6TS2fjE0JohBwGiroKnWDQwLCRTl wdeTo9irz+XOI6BZ1jtXT2Jc1jhyi+Ps9ztAIGpuPMOolwciKDBACgyLZjoW NRVe7uKG7/cMQdsgGqZkbIfTLMDjqpnBarFwvB7uPVlykOlUP54WrH8PCU0M x2wcoL2ZmAyGts3B99eb4RKxrPTO7dKnxMhEKBcQUGhXNRHOuqmZY6kdCtio 1a9SPFiw4LWNa7w8qrA7X1B4U0gqTWY22XoWjlk1MwYMXqS+77exvp7seYoZ en1r06ribGD8dExP+KEMrMDmAvHfkRP8/YjaLGtxhYrQbWftrIStnr/2mZ3Y u2BwN23oSNHKHi37WC8ICbwWFKS8vOZ0UaJBHKWfnOM6VVm0eCcgwDjEZc1e KlmX4LukpSDy+M7+i/Oqxd915sgIFjdYITWQPTpRDiR2x+179vHm/yB4GweG 4UvCYiOOHk9kkJelmI5ilw6wJdz65em9/xFLJR4oZxlxEwNWJyk/6MdZyftJ zPLdPcKt92iht0aGElFDRNLr6zMHbA3VLz8u4fsVkdLNvDcp2NAVwdfRU9g1 IzLqij3f0E4nH1R0Q4Hpu7sCguiEqI4RYVMFpINkHXr1b/T5H+7Ok/nr7HpD RLeyRpSWdpYWP6ZiZJsIm2/h5Jj0gRniEg07uAQEMYgOIFpqLXM7SZYpcHZY RHYfXEzMvBTihIRHyqQ/iRP/lGHPAlwqRW/saTtggi9ZXKCCr6WuKenpydvR vcF1all2OT2EDTMIW17ohUt+S8fth+Pw++mHDmGcd3Tpr2eRZKBuapGWN/r3 DDmBeMhKh5iTqJz/O4Vx8Jhr4Ybdh4eYgzKLCVUikcB3WnWfDdVxTkdOUNCJ QEVQM66tqMO6qaynKlVUXzpBMDO+0by71sGoxyolOCMyPSg/3tHM79rZxP82 BTgzBiEgK/bd7OUH48nXt1IZ1gRbVMrsIKu4YO35e9/il3UC4gsIQfL44gCw d9gq+eXDJ1ooKhJkJUryAoIJmRmRl/np9Fsc3FnU/jniuDpT2cahe1yfMiUk piwoP9/uyqzTstANu+XFOFMq6l0basLkYttCmOyjkLluQ3Btdvj0PIuqrZiv x4ZSf0pJ4KKOkMrPc8VnSnTPEEpgSMvUcWGR91diHN6WBJB9kEibyh6R7E1/ lSNYk+yfgwuXiepWSEcPOmRoxC23mUfIhlmwXLxRQq9Er8gg6H3Jt6Z0o1+R VFEZwCkqVW11Xx1TvrKZUHlXc39+aSBMkBxl62MBX1YdVjMY2fUSk2gKc/la k7KmBwj5RBMSXcKitIepupEu79znQrmWpQHIh3aYayGKz1QYynXu5rbB+SVf nODN25KmoUa/wgI+KjOWXk7LJDu19nH/98aAeRBLnDbCxs/KV5+WfuCWxMDP w76Dc3K6b5USHhBOld2Sy/ezj9dcYY0oONi6vl8xaDmjvc2aEgYH6gK3ZSFe JY9VV1kAzaZ9CkKcspbEBocir4db4uX22xrTeA+4SE5SIdgXh21Qv2iCQV4B U8PJ0snmAghcMB8UD8PjLkjbfjIN2mfql3VWpw4oBvMdWRHr+Y1F7tPhk89Q xRI5RljSs4PDVQKBctXDhbv3xWrApXYwQ7lgbwD5CVVG3cym3AJmKWc+wSmK TPAMFhUQjqeV/BoRIBmyj79lFTjZiOLtBPJd8qla5NnSjAj7Y7Rq56oMakZd LhsuxArgfrK3LOpi8GrFj1zuuqWbCIp79yYHorCHfrgEbxwf0NISORlniMJZ 1aqbCkjFzo/0JzZ28O7Y+AVqMFM89XegtRzCUGPAu2G0TnBHvM6DXYpj0y1g MFKmKvdjPs939Gq3NrZ/r1SN+0Y57uJ5ay17P51btFw86JnhNmguSWQaiGcl HL0pySwIcrY3cP/lhbIZ7PTwwyIBIB838WarsxBnA+Lur+XAa6iPpzxTgfQa KWzWGZIhsE1Vbbyl42CGlqRmqK7cbJqVOGHMHM9NcO9VBC2F1hUVXtBDERxf MAsJOt6xFNj5XF5UfnPNHkGFcYQV4f4H42Jxm9vAzz52yvO+svVE1fKeOkuQ 2hsaLmqvPCtNBquai9pCAl1fo5iZ0kNbzrkrcEhc8R4djXw0+lELXjO72fuf CQ7eo1pPJM6JP1w9KfAGzt0bGbLrpeajJR/neU0qqsQ5ngoiLmv0uyGO/jUq yLpzJcVpYw0ScLmuI6OvHHL07J2Kp9CVI375EmGAFILEYJotHXtJokOqHF5l Zb93vVJL7VepZCxPm2sjSbj+xCWauL0nUSTmKh4h4BigTVSRdbFMASM5nk1v fJmjVGliuwudbc287HlC6Y0upWh2yjv90ufQaakfG+wqMfOkPTGMDhyykygR z4xJt8xeMAoR3vETkYUrc0hI/xDBP1C8ZfTOuuseYSsIY6Olm4FRqW//4hQV Tkgq+JZ14r7wD4yd+VoGCRCP9AO00cRBgGT7zscKvjsEv3uLsJACZsWA0DMG gdcg7S4BpkQuUQAnqmXLh9mT80n5Up+iPpFx3+8nAEuV0LHdRcefnmNa/q7z Ej5DNkAjY4CVwUE7m0thPSex6z1u6Qc/CTwvVPa0OyBEqmYu9HRQ+coLOhBW SZxZRuqhDPRK9JeZ1LuPim9KoTQVZFvoEtdlVhCrnEtNDnGs+SawDQU/m1ku 2EkukzjJu5idN+yPEGsC9AgHTabBNakKWs2Bql7BoFeVhhtuMAz7eLDz4tm1 iaBr5gqg8o02b76vXk8hfMgIZM3GWL5QNuDITelkWmTMgyKzcWxpV4Rn3MW9 356Pu9SudkLueauD2rB0BbPVggOQaacijUY3gHyleltugWlRQ1sp0f6uD9rF fAHlEFrH0rZeN3haOvhOOT80WqK9sDLIm/FR4x4CMCgmD+SNJMuwicntC6iW l2e8ODbiTk6L73Ixguuj1vwyeUGSPQw3MhUkjwOyzcho6IddDV/uBtr+B4hp 82SWsdaLbyf/EVTIblL2Kp22yytrRLZZleHLMlICjHQHa5byycqbv1dF9CFK +4lu3pYjqA89bu8leDtyzUCuErd9eypVRaiczh9KAVAiBL9Sk48IiVACRuwC I7BLNV8AylM6OQpjGWgdZariaCiEfaWCtc88nWZoQDoHz/LwY99l9UzUBt0s NVR4CKIz7U5/j56I5Au/zaDplfGydvB781a8IbEv+Xhjet2yyEl3ukPVjsha M16f0AaK7DfovaS2+K5nn52QOexJDkJahoU/8aq87qO9+KqSZfZ2+LjKwKzF L6YgXTdQ4CES/mhwiPbyWUsr+aM8aYe0idS4YVb2RpM7vw0s7Cn44ix+QC/A Z84m+Pf9jxFOXr+K5zcGylVJcIiCou/70wMv/qdUQyikqgnEYD039u+a5J2h ag6WdKu76DGzmJK2UV9K7c/1FP4C6s1SG0DpG9Qj5lHTjv3YC5hV4PfDL8rW XuCXLwnnTTNBBhpx3jHNFTf4fP5bNQU67zRU6UD1DyPCEjDyLqUP9VtNAvap WQQvYaF981uGq6cCl8rmx/v5AoZIjbw0BtM/kBEp89DiS3Uy/ZBS+vVqb9nR uHjS4M7fOLWH3qrGiwzysJHB8tdUdazOgI7Lak0bP3YMF7SKu1K6zXIsliFy TMkZsupLxX4MxKKYk2LJcYhXsrFB3i1W+xy8oYzHNljz0fb+t6fXAay4DGJ1 oha+pUxYxiXsITxoWMFpTvBFlTJAzd9Jjw+ybZ6WY7Qq2flI+0zTJpmHMO+2 Nn+D1DHg9Wwfdd6S8izl+6NAdeJlGPTZ6aoaWhrpWWyE44vN/4yvYojuS3nt fSu3zRXQuDlGz7Fn+ZIrE7XNmA8hzoofgFLhrXEAaEQNZzmTzrxwHkOjfEbx NlLF4geO7i3ZSRh5zATYESyFlVrtmK40xPcEp9pw5Z32ZsgRTGnlO0IRCMWt WG9zdCj14BhF2vdarH3DQ+aWauwz3E2UatGabVMU+y1dUIyxl6K+1Paq3FXv SMzOyzZy1GC4CdgRUi9SwJT2h8KT/BJ4uqmOhtcxXgbk0/ALUzLK79g3a+QS q1kPn2aszeVVtpSr7s0xE/nzXuaOutIaS8KDqmQSiL9X7wTuvRwCW/HB+btC z6aqxgPjkUrLIjxpplhUCogiNPdl6rm71H7Y9GDYtmjYfC1QWiJRVhXIlldA vhUQYlOaNj5BazwChQjyrkfxMoDOCYHOKiQwTFOrnzhg0MHi5LPY03Gn7NBi 1HnkCuNMslw6GLHSaSUC7gAfBe5H2QZ2fyKhLomOBGkZIeKzjpNsEd8Kjta1 WdH/aDYoRhee2Xya6MTHwC/fPBYreShJnaMJdbGsArkEQUkojjQ8mX/UCmRs H8gRe9UgfktEkznTyWTa2P4m2mbNmC1YrCCAVwPuXL20LhQpDd09B2HiGcjh /Ivose75l6/NgAYYaFPIKpBmLNX/UeI1ZG2YjU9EijhLt3uTV2KU4moxD6Jv 1lw9+2C53TKp3OUXkuw9hIqo9SmspupBfAYGO78Ip70bbdwxIF8bySLEMwUh GYYrZFkfkq4xUEbmU7mu6Cbb4+Iy7b246IussLHLdhGk5NxvR2rBqu3Qq9iQ iGv+tW3fzxhBBdMiU+SJJ8rve62V0pNe2ZiCiL7Ga2nx9KzTpBmvURZuYeSP NvDgfZAeXgoQxLVApg11KUoh4U7/2XLu+heZaqBKGiIjz46RWJuloZUQ7xdd yVP4ieJVR6gsMhWu7KalO5M8a2IWdpA4TGJEHBeb5/PjnQ+EqZPDe+onbAAn 3Lo9cFon61L60S93sOb9Yl3qcpUrc3CaZbTiYV7LflpRdPIp/uDiQ9ptbylv BDVgtkswvI8zXCwXV/0fljZp7paAQlTJiBMidAJeX10WSL8W6+EKGC4RkTiK 39ZnZE/X5cgalMhW0tPIos/UT6QB747ej5to8YcbMNrc/ifcaPRNE5j9aNY6 wKICS8UughBOcQqG2NedhAFwBcE02BbbZcGE4hAVqSuXryKFc+U+kVehyKmI e98+DQgAenMbdJHvmGpYWBk9krfFHWWX4JIp5wFx1z4WsImkMhycO3/U6ljG WnAAfLPKOSNUrW7WHmCiCoG18o+yykgy1GhXdG0u6vkrAZlywcYBKYmco0+G NnTZ2KqzED9LwyHy7D7AActtwhQ5fp+5tO9oQeUH2tqSxYK70DnDwwrB76gy u9Wo4ifibeTe3bQdI18yRX8Ju4tDz/9p7Xmp7d9Mg+NrpCB428Eav/P11Jqd W06nhj5suykl0ZeLvQNUYPn8Pa13j6xaGzGHEVpZ6/hvzQ+F0xIwr4fMk0/o CiyqlF1JpPQ311igKujqnGJRWlkr7vu3HNccn9Q57fvjgmR4NfgRr1pH77F9 5V0eMGCBYxPjXYrdMauqHPiDILKRL495kSjSXzmkgcOk0fPUNnfcW7slGwFd ++UELkiepLkipXv4U5vWC6V8+jZWXaB+dcTeeBaEbZEBHwcvVxTIvVMtgq86 Rnd49XBCwbu73mBxAa+sCwvifbR7O3SCyBDWXffR6SLwBrUt1EIXaAUuyxTV Qf3bhiJbwJOlsLFW7kX7TSlfneepKXnNuwhmywpWzosX/E+eCf8PmvJSlXaP caZz0SYqSKtFM70td5yzgbLZwfIg3RkcyytAFfCH6PSicCpBSxWV7LBxiyls QBC5klfm3y8LLHhqdJp1DDiPcbQUeTFQTwoGq8FqIxtkOFT9S4Y9/+QJDxKv WhopX+esSp2X7uSfBHMl6x4IFYzr1am60r8DnEsxEthruGd1bRiob7X/tK29 TSm7RfoBBVRmeJ4aqmvGq05UAPQp/pBYFnn0VYIdhOYHQQuJ83UnYxq5R/8n VTEgd8E5Fg0fYY2S+2bDy02R483BlZydW5cMTtEjaXm0cfxYq3qVw0gmfHwd BIUVDK8f0SKAIizsWwhjLpcDJYXycxRD5JwmvFp2BQX7HtiWRzq8ZKvU6FVM 5rr2lHlqaQXD7ky6NE242PHOBliJ/+FokxZ5yvwxwm95i9QJ0yJVhU3tSM0I J4u6RlhO5tlDquVi/E3UBFjphr4CeOAfO12FyXTIOQocccOtrEv51dD2/0G6 6JGvG53Gr6PpYzsryAOrPTh1tMCHyZCRSv41GjiVKJZmATghgv+umscc/Xvl AYjgbxaQ2b4OXMSHUkGFKNxyE2t98LX+jHZTd3fX/WNoFjbv1bYTAx6gY1b4 Tsyw+kxxOFf6vHY3lZJggRpNi/CiupDsbxPmLT5Z73ZpuWuovaSslYNHHrJ6 oF1uK0qI6j4Lrn/pvqBYNbnYgZt5KnsvqTiicKRMONFWZxYVt5IGgyRNu+6M TG5nFbwPZjVzEGWIAx/L9pWxtAxYFc/00ztr/7NrRsh1eRRNI3mplPJ3U23q 8otRzGhfPBMGwSzfpWRi/XK7UagDPY1IL0j7BfLfryvgcQlk4IzYB/wWY+6a X1EjoSoRXUGgT8FZ4JeQ66a8JwAOsP6XV7k53Uw9qY3CeDc7ZnSdwy16RXl1 jBOkEySDke2dABuUUulKmGjg0vNODVWTZH7r+LgFlkR0L2YCcLiQpQAkcma0 RZTc5PGPxvPPKcMHWdwKFK8E0N4Nyd2MWJ8Y64C3CtvNmb4lf1drbuXdNvtY D3xwf0mRORagLFHMZsLaq3ZbnB+4lU2wYKxNjm0B4u/0JSQ46nzqVdOGehNh sIRCqqVsQ57OhB+dxoqNzcVZFYAg3XzDdHsz89jqj3pw0QZ2nDE2TLkO31Kt ETTsDQ59fv8v8FJaWqfOKB9Dv+siaYEZE4aIx7D3luUDoj8WASOeJEnpPTde h5Frtq5obTmUJeWnLIq8e6jIxOTx+R52Yj87L4MnKRqKns50jVA1fOuFBBxz XAZ8kZt+3gQxeoIfdEKbCQScjbjbx2591EDuEHuzJtciWNKHxCBZplo+iv0C /djQpDAAku1H/NodayawIsT0PES1Rorq03XLKDXhhR5GHdRmbtnvfH0TLnh+ uycTOkgfWetk6fG0YrDa41orIxCZez3iJhMgOXtyCcGpucdS8BgJeTenKEEV FmpCuzE6+pfpz1+cZZS5RLB+tLcM3RHe6TNd47xu6h8UMLqx3l45iBFdq/Wp 8ZGn9wqcqldB4VJL9lBW3hCYRTIsfjwsGMuhbGSNN94gMLVYlcShGI0xD5BN HFqEannvTwpmLElY71tvHhrLNkch5gOp+M+idKfMRgis8EGgbzY+TK3m05k4 B7vxuYlTuA/zJ7xrm4Jn2m9QYcKm0biAwnqDM5AP+Hmhk5bpObP+PJw+jHeQ O4m8iyehiPR2L3leT6bZn729bq/mxwK4mRZ12FMupThu8tFVOMzo3NszhPdj PvCKQ9cZt0jt7XbuHubldW/K2EunqClw6Am6sTHQSjX3jTsfXgYoqITMg8X2 o1ZmR9SDI6WfI2rU55LlGBlHdB2PCnKgKwsObzz4+mHDJ4/Cf8qF4x3KakKj OvtGUs4HJXABdLcUNTH9NaKdpkQp5EpMtUN8HMjkM00q/4LmVpiBFSFn2SK1 V8lWEMPgvmThZagKp3TXF0Qn/Axzk0j86DqSEo5bf6kLx+YzF7JjH0Mve4lc xGIgyVs85QYdvhbYoTIl76LTDUnM4+ddmVV9kIJ7G4mTqsKREzB9/ytNsBRi F9SOatjfGCJd4Z7TNjVb7iO24lyuohiw5DbaB9I75B+bYWAYeArcyzzFxGiZ Wyl93maSfxLK5oUHEBxJn0DTeQO/uJuH29mR6FFQS4uadaQlAaCdfeYLxk0W FpeUSzqz1gSN32mSSqJzBq2puKyWX8DffAyJuvkEh2ikRxaWrfdtZeM3bM1v slzuPYyMOO+y9yanzqNSMGY2j0CcKImojIplNPylQEcc0v9PKqwifiUrQbsr jHMQ1XWlbOjx7hHPtgokq6PJfnqh1hCZfOReoaKWst/oJLejY/2ssxsRj+JN nOxYgMepdlOHM0KTa8V9bI/qcN36Y+WjO9r44QFJivPN0cue4kYUCI5UQH+2 PVfgTykQacsx7WhIqlBsCIrRaoAA676DDCH31PAcLDO8w2qm1Pwdph1lIsVw 94WZI0gELImnB9NDAlrUL4+ONfJl4gRL1FKvvTSiWBapW/9WXzPGkTmcOIL+ 9QhqewyGBIdAE9EYd031v1quC+R1AesbwPXrAv8g6wG4E8L16x7oagEAAOsC zSDoCAAAAOkIAAAAI8L4QMPBwHQLw0joPgAAAC16Eo9zNPa18kWTvMN8S7RV lRrcICFD5iYzmGu5mYII69jF4lnVhV1+BzIhtDe7veCu5FV+L3pKW+Ef9K/M +HMCDyFg6AYAAACLZCQI6w0z22T/M2SJI/H/A+vo6wG4i8VIM9JkjwJa6wFw YOgGAAAAi2QkCOsaZGf/NgAAZGeJJgAAnIEMJAABAACd+HPczSBkZ48GAABY YesBuOgAAAAA+XICzSAtGwShEOgLAAAA/CvG6QgAAABAM8P5I8XDSLizhH8e izwkWIHvZRRBAOsC/yBozJm3NlqB8giK9jYL5HUB6/kD17ggWSUXi9iB6xNZ JRfrA//r/0ALxTPJgfGCvKha+XICzSD4A8LoCgAAAA01OwcA6QgAAAAbxsMF uaCHBhXEZ5kY+WvJezEKwcEH+IPRFYHCBAAAAOsBZvXrA//r/xvE6AoAAACL xukJAAAAg+BhA8WQwyvBuFderBQr2IHDVl6sFPlyAs0gkAvEuA0rnz4DyOsB uEArwEgDw3mm6wFwHQ6K6DBh6wG4Jbb02XfDyi/Hy0ccW5yFRqf/i5HdJf38 PGR5fzDfB7tv07rc/9SP945RI1kasI1dL7+wMMhYJeH+BCo5cizFkTtIdwbW jIKRF/oaRDiuGU6kio5i4E3+0Er5CK1jeYWH8U2vgR+Xt/QtNFDa8OgAAAAA gSwkNwIAAP9kJAQA+ekl5P//AAAAH5+EEB7MAQAAAAAAAAAAAD7MAQAuzAEA JswBAAAAAAAAAAAAS8wBADbMAQAAAAAAAAAAAAAAAAAAAAAAAAAAAFbMAQAA AAAAacwBAAAAAABWzAEAAAAAAGnMAQAAAAAAa2VybmVsMzIuZGxsAHVzZXIz Mi5kbGwAAABHZXRNb2R1bGVIYW5kbGVBAAAATWVzc2FnZUJveEEAAAAAAAAA AAAAAAAIAAAAAAC8zQEA4s0BAPnNAQA8zgEAV84BAHzOAQCRzgEADs8BAAAA AAAAAAAAGF8BAAAAAAAAAAAAALABAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAA AHX24pt1erVAx+EHbN00mdp1m4ZYgw623qwqBLMoD62m1C4yFWFoRfhas/kU CViQd+Fd22k707O2ixRCJwEgsz8KmpyvNuVKyOtGCO+aXQ8CXBq/LDF8o+VT JIWaO9M3Req9+TvRU/ROtoTUtvmhBh8R4gHvOIPvvRVrS5msV9uUI/rGGUPu tcPGiMhYLiCyLyVCim6MU3hDjH43eb068/9CtMQsM9IWSHjYVvYgJ6g0HThB TMzR5ICkPuVLNgPT7QAAAAAAAAAAAAAAAAJtpJ0AAAAAAAAAAAAAAAAAAAAA AAAAAEB+aFgD5cybOXTr2LJn0KJGjyFEixk0a9iyZs6ePn8BBQwaN3HlhfVN EZm20wvw7inuRSH5OXEZqt0U755qF2h2LEpFHoK++lRUj7fXFPDMKfsBNv53 FAS2kguv/VYWb2B/OkAYkaS7WBefscQC8NE//FUh5jlQDrrHAan7TF4BQH5o WAPFu/NQGI743gixxi/hRmTqOXAnlJNmi+xMEHMle3JeHYDs91YXiqzbCbeC J69lCMc5Uh620RKn8VBeAUFpeVgclb7+SgeCt9xHtdA04FNli1pmKPjXFLzx TF4hQ2V2UlGGo/VNEYWskg+x0WbtRCHlOVkEvNsAp/taUSFMajpOHpDs6Uwa y7mSFKnRMupMSYF9UQmt1QGr7BJfYmlpe0VRhKD3GRaZvdMMoM0v4VU3q3tR DbfAA+7sSxFvbGJ9FwWNpegZBJm31RWxz2ePaCr/fFMZscYf7v1WGmJuLHxW GImp/xhUv7DbFPDkL+NEZON4R0u61wOgvlMQZWxqc1IVy8GRaxGKq90J8M8v 6Ekwq3tRS7mSFqHtTRZjaWk6QRiXuegZHYW+1wSkyynhAESjZCzd2L7oiKEY WaIt/wsFAAAJCQgICgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP// --CSmtpMsgPart123X456_000_00A994DA-- From hadi@cyberus.ca Wed Jan 22 03:41:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Jan 2003 03:41:10 -0800 (PST) Received: from mx02.cyberus.ca (mx02.cyberus.ca [216.191.240.26]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0MBf13v007419 for ; Wed, 22 Jan 2003 03:41:02 -0800 Received: from shell.cyberus.ca ([216.191.240.114]) by mx02.cyberus.ca with esmtp (Exim 4.10) id 18bJM6-0002jo-00; Wed, 22 Jan 2003 06:47:42 -0500 Received: from shell.cyberus.ca (localhost.cyberus.ca [127.0.0.1]) by shell.cyberus.ca (8.12.6/8.12.6) with ESMTP id h0MBlZYO041444; Wed, 22 Jan 2003 06:47:36 -0500 (EST) (envelope-from hadi@cyberus.ca) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.12.6/8.12.6/Submit) with ESMTP id h0MBlZkC041441; Wed, 22 Jan 2003 06:47:35 -0500 (EST) (envelope-from hadi@cyberus.ca) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Wed, 22 Jan 2003 06:47:35 -0500 (EST) From: jamal To: netdev@oss.sgi.com cc: linux-kernel@vger.kernel.org Subject: ok, which wise guy did this? Message-ID: <20030122064047.D41405@shell.cyberus.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1603 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev I just booted my spanking new P4 HT PC last night using 2.5.58 and to my dissapointment the enumeration of the ethx devices is reversed. I have 5 ethernet ports on this; eth0-4 on 2.4.x are now listed as eth4-0. This is rude. I immediately pointed a finger at monsieur J Garzik (thinking ethernet, PCI enumeration hmm) but he has denied any responsibility ;-> ;-> He thinks it may be the sysfs people. Can anyone give justification for this? Regardless of justification can we have some form of backward compatibility flag? cheers, jamal From cw@f00f.org Wed Jan 22 04:07:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Jan 2003 04:07:25 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0MC7H3v008441 for ; Wed, 22 Jan 2003 04:07:18 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 8926E1843B79; Wed, 22 Jan 2003 04:13:58 -0800 (PST) Date: Wed, 22 Jan 2003 04:13:58 -0800 From: Chris Wedgwood To: jamal Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: ok, which wise guy did this? Message-ID: <20030122121358.GA12877@f00f.org> References: <20030122064047.D41405@shell.cyberus.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030122064047.D41405@shell.cyberus.ca> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 1604 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: netdev On Wed, Jan 22, 2003 at 06:47:35AM -0500, jamal wrote: > Can anyone give justification for this? different bioses enumerate devices differently? > Regardless of justification can we have some form of backward > compatibility flag? can you check if the bios is enumerating the devices the same way the kernel presents them? --cw From Padraig@Linux.ie Wed Jan 22 04:12:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Jan 2003 04:12:36 -0800 (PST) Received: from corvil.com. (k100-145.bas1.dbn.dublin.eircom.net [159.134.100.145]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0MCCU3v008864 for ; Wed, 22 Jan 2003 04:12:32 -0800 Received: from Linux.ie (pixelbeat.local.corvil.com [172.18.1.170]) by corvil.com. (8.12.5/8.12.5) with ESMTP id h0MCIwPU021733; Wed, 22 Jan 2003 12:19:02 GMT (envelope-from Padraig@Linux.ie) Message-ID: <3E2E8B76.5000805@Linux.ie> Date: Wed, 22 Jan 2003 12:15:50 +0000 From: Padraig@Linux.ie User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021203 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jamal CC: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: ok, which wise guy did this? References: <20030122064047.D41405@shell.cyberus.ca> In-Reply-To: <20030122064047.D41405@shell.cyberus.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by corvil.com. id h0MCIwPU021733 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h0MCCU3v008864 X-archive-position: 1605 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Padraig@Linux.ie Precedence: bulk X-list: netdev jamal wrote: > I just booted my spanking new P4 HT PC last night using 2.5.58 > and to my dissapointment the enumeration of the ethx devices is > reversed. I have 5 ethernet ports on this; eth0-4 on 2.4.x are now listed > as eth4-0. This is rude. If you depend on the order then you must explicitly name the devices like you want. I've done something like this in the past. ip link set dev eth0 name interface-1 ip link set dev eth1 name interface-2 I guess you could use a temp name and keep the eth[0-4] naming if you prefer. Pádraig. From Larry.Sendlosky@storigen.com Wed Jan 22 08:13:10 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Jan 2003 08:13:17 -0800 (PST) Received: from xchangeserver2.storigen.com ([65.193.106.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0MGD83v018078 for ; Wed, 22 Jan 2003 08:13:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ok, which wise guy did this? Date: Wed, 22 Jan 2003 11:19:45 -0500 Message-ID: <7BFCE5F1EF28D64198522688F5449D5AC6336E@xchangeserver2.storigen.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ok, which wise guy did this? Thread-Index: AcLCDDLSXi3v4rgfTpGS9YrgNUfL8wAJaQAg From: "Larry Sendlosky" To: "jamal" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h0MGD83v018078 X-archive-position: 1606 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Larry.Sendlosky@storigen.com Precedence: bulk X-list: netdev Didn't the same thing happen in the 2.2 -> 2.4 transition? I believe it was for all PCI devices. And I thought there was a boot arg something like pci=reverse. Does it still exist? larry -----Original Message----- From: jamal [mailto:hadi@cyberus.ca] Sent: Wednesday, January 22, 2003 6:48 AM To: netdev@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: ok, which wise guy did this? I just booted my spanking new P4 HT PC last night using 2.5.58 and to my dissapointment the enumeration of the ethx devices is reversed. I have 5 ethernet ports on this; eth0-4 on 2.4.x are now listed as eth4-0. This is rude. I immediately pointed a finger at monsieur J Garzik (thinking ethernet, PCI enumeration hmm) but he has denied any responsibility ;-> ;-> He thinks it may be the sysfs people. Can anyone give justification for this? Regardless of justification can we have some form of backward compatibility flag? cheers, jamal From cfriesen@nortelnetworks.com Wed Jan 22 14:05:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Jan 2003 14:05:40 -0800 (PST) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0MM5V3v021528 for ; Wed, 22 Jan 2003 14:05:32 -0800 Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0MMC7M23405 for ; Wed, 22 Jan 2003 17:12:07 -0500 (EST) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DNPCVWPY; Wed, 22 Jan 2003 17:12:08 -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 ZV975T4M; Wed, 22 Jan 2003 17:12:08 -0500 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 130B42D957 for ; Wed, 22 Jan 2003 17:12:07 -0500 (EST) Message-ID: <3E2F1736.500@nortelnetworks.com> Date: Wed, 22 Jan 2003 17:12:06 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: question about bridging/tunneling Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1607 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev I would like to take two physically separated networks and bridge them with some kind of tunnel over a third network. What I suspect will be the tricky bit is that the two networks are both on the same subnet. The topology will be something like this: tunnel box 1 192.168.1.0/24 --- 47.129.x.x (part of it) | | (network) | | 192.168.1.0/24 --- 47.129.x.y (rest of it) tunnel box 2 How would I go about doing this with a linux box at each end? Security isn't really a concern now, quick and dirty is fine. I was hoping for some way to make the two tunnel boxes and the tunnel itself act like an invisible bridge, without needing any 192 addresses. The key thing here is that I can't change the routing on the other machines, so the tunnel boxes are going to have to proxy arp for the machines on the other end of the tunnel. Any pointers on how to do this or where to look for docs? 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 adam@adammil.net Wed Jan 22 20:54:58 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Jan 2003 20:55:03 -0800 (PST) Received: from adammil.net (24-165-27-14.san.rr.com [24.165.27.14]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0N4sv3v027446 for ; Wed, 22 Jan 2003 20:54:58 -0800 Received: (qmail 21452 invoked from network); 23 Jan 2003 05:01:41 -0000 Received: from unknown (HELO mail.adammil.net) (24.165.31.14) by 24-165-27-14.san.rr.com with SMTP; 23 Jan 2003 05:01:41 -0000 Received: by mail.adammil.net (sSMTP sendmail emulation); Wed, 22 Jan 2003 21:01:41 -0800 From: adam@adammil.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15919.30517.330774.275812@adam.adammil.net> Date: Wed, 22 Jan 2003 21:01:41 -0800 To: davem@redhat.com Subject: PROBLEM: failed assertions in 2.4.48 ipv4 code (tcp.c,af_inet.c) Reply-To: adam@adammil.net X-archive-position: 1608 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: adam@adammil.net Precedence: bulk X-list: netdev When I run rsyncd on my local machine and attempt to sync a directory, I get an assertion in the kernel. rsyncd has failed several times in the same way, but this is the first time I've captured the output. There are two failed assertions. One in tcp.c and the other in af_inet.c. I haven't been able to try this on a 2.5.59 kernel, because devfs doesn't seem to work properly under it on my system (that's another story). Unfortunately, I don't have a System.map file anymore, so ksymoops isn't going to report anything extra. I hope the following information helps in some way... * /proc/version: Linux version 2.5.58 (root@adam.adammil.net) (gcc version 3.2.1 20021207 (Gentoo Linux 3.2.1-20021207)) #1 SMP Mon Jan 20 22:05:30 PST 2003 * the error output Unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: 00000000 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0060:[<00000000>] Not tainted EFLAGS: 00010216 eax: 00000100 ebx: cb346860 ecx: 0882d830 edx: c2ed3e20 esi: 00008001 edi: c2103f80 ebp: c1ef6080 esp: c2103f00 ds: 007b es: 007b ss: 0068 Process rsync (pid: 30224, threadinfo=c2102000 task=c94fad00) Stack: c01fc629 c2ed3e20 00000100 00000000 c015f1d5 cb346860 00000004 c016043f cb346860 00000004 c2103f2c 00008000 00008001 cc823000 c2103f80 c016064d c2103f80 00000004 00008001 00000000 00000000 00000004 c1ef6080 00008000 Call Trace: [] [] [] [] [] [] [] Code: Bad EIP value. KERNEL: assertion (newsk->state != TCP_SYN_RECV) failed at net/ipv4/tcp.c(2274) KERNEL: assertion ((1 << sk2->state) & (TCPF_ESTABLISHED | TCPF_CLOSE_WAIT | TCPF_CLOSE)) failed at net/ipv4/af_inet.c(689) KERNEL: assertion (newsk->state != TCP_SYN_RECV) failed at net/ipv4/tcp.c(2274) KERNEL: assertion ((1 << sk2->state) & (TCPF_ESTABLISHED | TCPF_CLOSE_WAIT | TCPF_CLOSE)) failed at net/ipv4/af_inet.c(689) * ver_linux output Linux adam.adammil.net 2.5.58 #1 SMP Mon Jan 20 22:05:30 PST 2003 i686 AMD Athlon(TM) MP 1600+ AuthenticAMD GNU/Linux Gnu C 3.2.1 Gnu make 3.80 util-linux 2.11y mount 2.11y module-init-tools 0.9.9-pre e2fsprogs 1.32 xfsprogs 2.3.6 Linux C Library 2.3.1 Dynamic linker (ldd) 2.3.1 Procps 2.0.10 Net-tools 1.60 Kbd 1.06 Sh-utils 2.0.15 Modules Loaded usbcore snd_pcm_oss snd_mixer_oss snd_emu10k1 snd_pcm snd_timer snd_rawmidi snd_ac97_codec snd_util_mem snd_hwdep snd * /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 6 model name : AMD Athlon(TM) MP 1600+ stepping : 2 cpu MHz : 1399.658 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow bogomips : 2744.32 processor : 1 vendor_id : AuthenticAMD cpu family : 6 model : 6 model name : AMD Athlon(TM) MP 1600+ stepping : 2 cpu MHz : 1399.658 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow bogomips : 2793.47 * /proc/modules usbcore 76724 1 - Live 0xd091e000 snd_pcm_oss 39428 0 - Live 0xd08f7000 snd_mixer_oss 13568 2 snd_pcm_oss, Live 0xd0889000 snd_emu10k1 51780 1 - Live 0xd087b000 snd_pcm 65344 2 snd_pcm_oss,snd_emu10k1, Live 0xd0894000 snd_timer 12672 1 snd_pcm, Live 0xd0876000 snd_rawmidi 15296 1 snd_emu10k1, Live 0xd0871000 snd_ac97_codec 32580 1 snd_emu10k1, Live 0xd0857000 snd_util_mem 1664 1 snd_emu10k1, Live 0xd0853000 snd_hwdep 3904 1 snd_emu10k1, Live 0xd0855000 snd 34628 9 snd_pcm_oss,snd_mixer_oss,snd_emu10k1,snd_pcm,snd_timer,snd_rawmidi,snd_ac97_codec,snd_util_mem,snd_hwdep, Live 0xd0860000 * /proc/ioports 0000-001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 0376-0376 : ide1 03c0-03df : vga+ 03f6-03f6 : ide0 0cf8-0cff : PCI conf1 c000-cfff : PCI Bus #02 c000-c0ff : Lite-On Communicatio LNE100TX c000-c0ff : tulip c400-c407 : Creative Labs SB Live! MIDI/Game P c800-c81f : Creative Labs SB Live! EMU10k1 c800-c81f : EMU10K1 d800-d80f : Advanced Micro Devic AMD-768 [Opus] IDE d800-d807 : ide0 d808-d80f : ide1 e800-e803 : Advanced Micro Devic AMD-760 MP [IGD4-2P] * /proc/iomem 00000000-0009fbff : System RAM 0009fc00-0009ffff : reserved 000a0000-000bffff : Video RAM area 000c0000-000c7fff : Video ROM 000f0000-000fffff : System ROM 00100000-0ffebfff : System RAM 00100000-002c28a1 : Kernel code 002c28a2-0032b707 : Kernel data 0ffec000-0ffeefff : ACPI Tables 0ffef000-0fffefff : reserved 0ffff000-0fffffff : ACPI Non-volatile Storage eb800000-ec7fffff : PCI Bus #02 eb800000-eb8000ff : Lite-On Communicatio LNE100TX eb800000-eb8000ff : tulip ec800000-ec8000ff : NEC Corporation USB 2.0 ed000000-ed000fff : NEC Corporation USB (#2) ed800000-ed800fff : NEC Corporation USB ee000000-ef5fffff : PCI Bus #01 ee000000-eeffffff : nVidia Corporation NV20 [GeForce3 Ti500 ef600000-ef6fffff : PCI Bus #02 ef700000-f77fffff : PCI Bus #01 ef800000-ef87ffff : nVidia Corporation NV20 [GeForce3 Ti500 f0000000-f3ffffff : nVidia Corporation NV20 [GeForce3 Ti500 f7800000-f7800fff : Advanced Micro Devic AMD-760 MP [IGD4-2P] f8000000-fbffffff : Advanced Micro Devic AMD-760 MP [IGD4-2P] fec00000-fec00fff : reserved fee00000-fee00fff : reserved ffff0000-ffffffff : reserved * lspci -vvv 00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] System Controller (rev 11) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] AGP Bridge (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- FastB2B- 00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ISA (rev 04) Subsystem: Asustek Computer, Inc. A7M-D Mainboard Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- FastB2B- 01:05.0 VGA compatible controller: nVidia Corporation NV20 [GeForce3 Ti500] (rev a3) (prog-if 00 [VGA]) Subsystem: LeadTek Research Inc.: Unknown device 2863 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- 02:06.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07) Subsystem: Creative Labs SBLive! Player 5.1 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- [disabled] [size=256K] * i have no /proc/scsi From ipv6_san@rediffmail.com Wed Jan 22 21:54:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Jan 2003 21:54:55 -0800 (PST) Received: from rediffmail.com (webmail29.rediffmail.com [203.199.83.39] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0N5sm3v028088 for ; Wed, 22 Jan 2003 21:54:49 -0800 Received: (qmail 14201 invoked by uid 510); 23 Jan 2003 06:09:19 -0000 Date: 23 Jan 2003 06:09:19 -0000 Message-ID: <20030123060919.14200.qmail@webmail29.rediffmail.com> Received: from unknown (194.175.117.86) by rediffmail.com via HTTP; 23 jan 2003 06:09:19 -0000 MIME-Version: 1.0 From: "santosh kumar gowda" Reply-To: "santosh kumar gowda" To: netdev@oss.sgi.com Cc: usagi-users@linux-ipv6.org Subject: Use of Anycast address..??? Content-type: text/plain; format=flowed Content-Disposition: inline X-archive-position: 1609 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ipv6_san@rediffmail.com Precedence: bulk X-list: netdev Hi, I'm new to IPv6. Can someone tell, where Anycast addresses come in handy ??? Regards, San ----------------------- From ipv6_san@rediffmail.com Wed Jan 22 22:12:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Jan 2003 22:13:00 -0800 (PST) Received: from rediffmail.com (webmail32.rediffmail.com [203.199.83.32] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0N6Co3v029014 for ; Wed, 22 Jan 2003 22:12:54 -0800 Received: (qmail 26633 invoked by uid 510); 23 Jan 2003 06:27:39 -0000 Date: 23 Jan 2003 06:27:39 -0000 Message-ID: <20030123062739.26632.qmail@webmail32.rediffmail.com> Received: from unknown (194.175.117.86) by rediffmail.com via HTTP; 23 jan 2003 06:27:39 -0000 MIME-Version: 1.0 From: "santosh kumar gowda" Reply-To: "santosh kumar gowda" To: netdev@oss.sgi.com Cc: usagi-users@linux-ipv6.org Subject: Packet generation for testing usagi IPv6 Content-type: text/plain; format=flowed Content-Disposition: inline X-archive-position: 1610 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ipv6_san@rediffmail.com Precedence: bulk X-list: netdev Hi, I have 2 Linux box(in a network) compiled with Usagi kernel-24, i would like to test IPv6 functionality. Is there a way to generate different IP packets at one end and capturing them at the other end ( b/w two machines) ??? thanx in advance. Regards, -Santosh ----------------------------- From big@boss.com Thu Jan 23 23:29:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Jan 2003 23:29:36 -0800 (PST) Received: from CSW ([218.88.34.143]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0O7TM3v014212 for ; Thu, 23 Jan 2003 23:29:24 -0800 Message-Id: <200301240729.h0O7TM3v014212@oss.sgi.com> From: To: Subject: Re: Document Date: Fri, 24 Jan 2003 15:36:07 +0800 Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CSmtpMsgPart123X456_000_003BEB3B" X-archive-position: 1611 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: big@boss.com Precedence: bulk X-list: netdev This is a multipart message in MIME format --CSmtpMsgPart123X456_000_003BEB3B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Attached file: --CSmtpMsgPart123X456_000_003BEB3B Content-Type: application/octet-stream; name="Document003.pif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Document003.pif TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFt IGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAAAACOFpjwynf2 o8p39qPKd/ajSWv4o9B39qMiaPyju3f2o5xo5aPHd/ajynf2o8l39qPKd/ej R3f2o6ho5aPHd/ajImj9o9J39qNSaWNoynf2owAAAAAAAAAAUEUAAEwBBABZ /Rw+AAAAAAAAAADgAA8BCwEGAAAAAAAAcAAAAAAAANbLAQAAEAAAAEABAAAA QAAAEAAAAAIAAAQAAAAAAAAABAAAAAAAAAAA4AEAABAAAGZGAQACAAAAAAAQ AAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAAAADiywEAnAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAH7MAQAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAIAA0NjU1MDk1AAAwAQAAEAAAALIAAAAQAAAAAAAAAAAA AAAAAABAAADAMjI2ODQwMwAAMAAAAEABAAAQAAAAwgAAAAAAAAAAAAAAAAAA QAAAwDMzNDY0NzMAAEAAAABwAQAADAAAANIAAAAAAAAAAAAAAAAAAEAAAMAx ODI2MjYyAAAwAAAAsAEAACIAAADeAAAAAAAAAAAAAAAAAABAAADAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AHGdzB4ud6p6TSjUpADN483kA40VGLPSe2RRMvEnwXaS6+DYVCYO2hNX8z/e CUlcCsyESKP0WlLEgSqcQoA1oM9m29MT4kYTwYHQF4P3olUJEoyhtSJ3Qr18 qZtnmIgxL9mUVyHY/wcHUuNDyX33lml2sDnY5bEW9Vn1YrzZtITMIaPyjo04 wOO3s9rGEhrhJg6tu/yKmUW6uBn1XQAx/hK9RpFcqemovse0NhiEgPd7QRHW K/cBHSxzbsCZ2qpuw+tA3LKmEdctpgfWcbsRhd9GUwZtj/OpsqYmy+LLLga+ scDCuwM0XtNM5+rfmkqc+sXUG8USfSP88O+JzKm7xbAskQgfxVVot64UCqne PG+RIkhilIZTmlFtqnPqXCwvXAauV7PRUfV3hD1K2fgOn6O+FY9qAoX8D9Kr ECwssCoCrhdPFOoMFfv0iNEsS0viUHOI6An9lZKSyQQFmalvPGRmsfXxz75/ Rr9EpnoDRl4tBGkjJlnGTYPm+/H8Kk01bUgJ5Qie2YNExzRVG1H54YljjFni 2+5nTaqQvPFlqms/F8GbVw4obQ3icxyzW2T+qJMP+p2waKMVoCexxBUrDafi 4tM5FlXOgZAknd92cDdZ0crY6eQWafFqM7+j/itrMzqKKNu16jficx2g4diA yRip2mwlVfos7KMOeyotZGiukGSkZE6U4kx9Mn1LHzx5pAWSDRBOclooWmNc ValbAi2h04qjgG8f0FpEJmVK55lKuKTWCBA5i9VI/3G16zzYomWciuuqviTY xbjlJctaALOJyvVKIhNoMP1j3BbHJF2TymOuejJoTHqGprf/cJ7k8Qpxdi/s hQuFY7XOfX9RjgIEv8zElPYSRG1kK1n9PEJiL/DPpso84hCWUNS0HYtWZc/m aZzC5l5383+NQA+u4VkK0xeivBaGLFuOYYGxAIeac+h+1k0HlsX36zuMrTN3 x9tqIikrCeYlFqzkSHyzOmsOwyNAI2IDpGYjxaOmu3b7imXedp3q6tp5eyAE wJcAaYQGcVwwj+98JNCLkF7oecU8D0QjPYsor/Lg5GNimcRM9DZD56D9FNnI 3M+e0dYU7fXW3aRYSifvvs5DxX9dZn9W4TF1cnIXKfPi1j8RLrlkAdRY4o/d HoZdWxL6d6rRAkM34WvXPy8TuRPTK3+9Qk39NjLXJszt1uM2epRPksh/mBca rDUelgIIYF1gvwJsggc4xPPvbyi4mHXysHmoBjoUvePE/uqbXrleZt8sO97B 7pp3s20lYEhHuuLy7VLqO55PqTi12zUoll8zJSw9YIV6b4grierXChfL5juG 2jgC+d/+l4BPSfVvU3UaFIm0vDFUYMYrE3RsDqkoT7OMjbc02kCT6EiVhP40 rZVJizbg8FaZercUUFeC8WESqgF/cSYPWP2LSbXyfUW/K6WEZP8LwjliB0Yr 8FL+XyuZsL3OYGcxHMKYi2RzqqO/KgkfjuF5DrP58yos487dvJP7p3zjlfqT lF994y3sqgNttCoWMPpb1KIUmAZOieCRDHSjNDBg9WBGO3B5JTvrX8GC546x Wfoey7p0HlefhIpwjM/SX7n692QWYO2WEAjmn2ovmoIMhQtJN+a0363LyfTq oARfIimKjhKtQWwAvKcVqWpPLrecsemiW1dvfSXFbiYy8R0CMJu6ktExSr48 x7iexVxWtiFXDt3CIZ7cFCLlLNlsNEhSM6TjQxemMkH00mlxCP1y6lvGMCbF ynn6VMdgCuWVKKhlo9Y9uS1bewj8NL2TypRB6+qXRYItc5Uy6kGmVp9AzRIG jlm3SCHEtH4Jo2H3zpjK0PIGVt4NndUR4ZoIpmuomTLZ9bXRDiqPWoDS3QZq fqcRL81G01TV4shTECxE4N3vcTtNefnJEc2r2d//vlJBm2gOgMxG7kIOxVb0 lSNhz+gaf/0QsXYzriH2OY4IoYEiqMZpKOBREwlrp725O6F0BRbU/XzmdRdE gtSJqUhXH8A6CIp0jjTdh7kOvOc8RkA6mHE+8pyZ6AkJUsxSUUCqdltXVGiG BhsHRlICLaowoUKqfVhAv5x2Za9k3dum2IaI0uLu1fq8kRKKV9QBiT/xxXA/ 24YhoiXNN+jr8MuXAcdLfQ5OpAG5sAov8u85dMeEFgVE7ZpQkQigpLiLM5gQ MvtiuduHgYgo6j4m70SaayNQ7AzsENYNkjxtZBrjm7lwv+CI84clHcxHFBZo HANcQY+SGk3GB+KyAlWbEHbTWATPCGA0o/08PilgBk4KrFxInivwTIPEa5J3 ua1L/AqLF9o3aHyIW3GawSTtrf9pKSsdedDHG3ozPB8vQlgPUp8LHYFJd3Vp /W4icJEG8Ei/adFNdUO8vxl7q60LfeSrqFT7TH7kbU3EFxW/2rauRHmLutz/ es9ySGCflj9d8AHNtj0gs/pfQFIjxiykrqkec+e+S2kGtV80zStcytjEaamF z6DPRZbbJ++uqwjyl8p/I9p3u0t+Z3KvB5OXdsNJ18y5CWwskSMN+nROgxTi DrVitFc0D+SMd5wROcQJ3mQ5kFxy5+btdc/AVBKJppq/6MPC0cANKDHxSp4M fMKbANxoEd9AluzAXPy7xlkG6OerIhWNiwYpCcxBeOvugjyx4NbQ6IkL0kcq uMNHeoR8VkRe0VRNCke8wYaatSSL9ovTjSI1+MqOtcm1+TFaaXYApZTdTQfT kQUP/BeZ5yDJgKJdxF2elgLPlWtsfwY+hTPk8eD0naA5WQbXd9PlPNsFvmSo X5zk6kVhbGBNGsX0TwrX36id4rzPfTm+58UEVFfN4RKoT3uW4lIz4fo8r65W W5cJzDvcH+s+vokzIU2BD5igk4pP22tYPO/yE9rGRCq/yJUyt+stmOdVKrs/ L+15EEybyAlAonaMs+34cBvcgREe0yf8Bneg6e2/QQdwi+jtPzVSM7LRFUUo HM0pNzHQ7n9lnXUclpEBPsSx0OJStwkU3KF/uT7kbAIGV3xMNnj7JGJ36dxF wo/lI2cbjpz0O7xf8axRGcpCtmkizS/uEHy4a1Aat1v9OCGZh6kmR/ILx8GQ N0tMvsCLV/+bxYDBVRaJdnNwZ5oIM565bnryhBDGKecTjcwq25Gw+2yyZXvO AXQtArk51P5HYt4oh8ieLpLDEcPlHY+OSf8oNM/2a4oyuqyWC0ljQbpQll9e exOas4IABHus8BjSjX7MI1iuthuYr4DCD54UPOysstVCBchYhswciHVHNe99 wDETYXrEEdOa1RVm5wbW0hWDzpnNE0Qt0JqsOG9/Yx9fEKFLP8YPxo/pr7Jc j/JzTxk6kvC7nrNHuVJQmcLALtXJn0XgFuuKZYKfB/RCnyNy/3PIg+k5qlst TebQiE7ZBXdKNnpp9r04SrWsGjr+AW8UugVmmQbyxgDN/O57pzh4bJkjo4u3 qhPydhFaV8teluRV0IGgGtx233fRbFPx1NO9NunAW3oPtfjrAiDdorwDE7f6 afaao3p4cngP0zJ0Wf9p2m/djPUpUmMm944fQpPvoH282P3LVc19ASvaVTyV eZQJmK409UXl0uNEi6I5fvg4WQdhJVzQCe2VbFMe5UJ9Qg/RCLwOTije2Vg7 3vCMr2cVC5pvvFGw1mhEPTBqewA25ureXeJm1zqWLue3A7nftj8RI+NtA2jF rolkJrXe4yCPqUIfhJlwaEU0n/dpnKUPyyQE/gSby8Y3ciyk5Op9oMs6WkL0 LXTYXz6sH9dv1T9CXPHtX4m8/U55X/lrRBsGEHLYWIk9ONmbwrrp5++QkOI6 0ZYXcBL4KVqKxTRnn0XLi01SbZ6eb/GiXDKhAwsnsNGwuOY5M7DfLQDz1jHg JQyjwewnXkWZRn861yhI4yHSxCc9lb9XzVLMk5L89gLQ0tDEJP40EcY4SS+i qOeHtP8w9eu6ORPsm0bkwpSmN1piB5QUuW6jQeK8aL669NvLGjoo0p3LMNPx Wv0zxLtyDKIRWGF/EW51U4u/d9uIjVbwbeGVvTJEul1wTewMSqPPpPse/qPW xwy+ztbmtFPD+2HgpXZ7KRDDG14C6Fz1OGKjfshbzyTIV2FgdwpNfrEXnOTS Dr+uOxMtdKj8SEulSEVfXAbBZFqChF1mcuHa/4XfNA22o4UoD5ujKkzwGEim ldVtBwEsCD07SOBPH9ZjN5iYjYrmmSNqofUynaqNjCNmgPwvzRjKaVHnUq1l EAwlIrMxs+YxXMZTc3j0XaOhQr7hOEQAH/Q0NK/HpJMss/dPxH9kEQMif6Sd tiuDF21rTZrtD52tTTyqcF/FeDZ5vP4a6o1cd76fjqXeqyuBwbN4BeD0Hwin Ouslm7pfp4uTvhpsaN0iNuOvgkXF+GgKv6ecR4mDygV7k2iqBmPK4paYe8yC i0hsSoX6cNoBG7gCNJvgqIm4lI0fE/T0oIYwj+AqrNffACcLJKT87jcuCwTI GTs+qTeTEYP4TANgKJvEk+i6IsRaH6mJWexXwSdo5EM5CKnQPkTXMaE9hg5V DbWI0wQ6z3udfO9i5UMwDnMuxmrl5bGqwpquN1ADQXUbLhEm9jW5YMPYJOXH TQTfsmagU5m2YKV0WxZTMAYKJal37xSAcISI1eHex91rKgJ0caJDXnTguAON O0jsXF6dMktkZ3szuW6qTx0Jds0YIDsnvsEYDVmkh+UfllSBylEZBAPU69xE cqUPYHgOIUouDGv1UxF88cRdpCnu8tzFJZOUOwVasMTDGYqe7G40H8I/cUOm T+eG5WoArzJVhN1RJlWkyS7BwcidKZILcT6XtSKjbszyfntO+0wJDQFH3ZX+ zt8P9pTKTqiF6UugX7aovkver8i2JGiSUw/70K+IOi9w3Je7+8UIoK360d2n b+QzgVbtUFn5EVoEm9eythMFUXxdMHwi2dYei7WixEhhcjC+LWaGllt22jh8 M6Vrj4uyjlCUVszSKjGC2V/7ph2Z8pu/WhmgesMAvFb8yyxCk8PT8EvFyP7R +uVEabpyNso8q0kSkSqob9DvynyzNmTOoxfoIs7yH3dQansBfOh1FTKabJn+ Uig6xJ0jmCiYbJA9R8ziIL8nbxfjPTEzD+vS5/0snn9HPb7QTDbEWmBxctz5 caFHdbRdzelkITqD5pgkpnFWDBw7xems8kes/7T3+Yt+u86KndtcqzTCpiYR hqLsq0pcTgDCqiKhPJnuujrmx7iGlw+KM+UuIdvrfMXT9VaZy2bZGMclKp5T Ls3ypKIKlh9f+g1r78cNL6EgNqJ2ky3E36yqKKKXcjslLLVa26FoC6ZFg6v1 Fy1BDZm4bW9TumHh8JAMtXjP2oL1lST704yveJEYDMlpHfneWwhF4P1ICLuV URE/px0WllPTfiMgVosevBOQEKdFHUP9AzEg/+QLjwA7k3gkJuTLBaKJ1Inb tDnRrPLTWbrDi7j8F+WtDyOlulwy+3Ixsn7vqoysSRn2nd2NvwXY6ix3W1gh gF1iy+/avOVgwTkGCohyJbUPGjwdsl5rbNSejfLW3+gm97/M/H3i01CET1SO 7UyAW8Y40K6ik87+SnXO/w50pxv8fixnS7YLRvtBq4VZK9K6tlYX+maVDe5Z ZmzK7vASDRPq4ixwaq3inq217JJUjaIx31XT426EUt7QrqmEhfi8U+vXIsnL NCn99FZONtQ/vVev4o3MrKUe0OzPJjLPlorX2YHbwUcj69tLhQUhh2noFOaC NsVjyacnQ6gMyLcOKbNnMGbMnKVY06M0si+1B5Sb5Es0BT2NZ8evLiWu98op qIR/Z4ap76R+KOdwEJTVY67uID8NS66doOpC2BOLkQ8WsETIERViwBwBMtMI sBZlhOpcH+PCsfrcuDE+JoRSjAjF+PFFV3JqTOZCxtfFHfbQLc/uMtSRWEaa Z6nFM49ktTQIg66bU4JA27Pswjjy4LMtaap3jzOQyAryFN34O7kNSlspS8H6 qpPbqHGccoDLHeiM86Uykwufot8IsJAhhU1fx/Iv5mEczhon04VWi2rtZp0R e6l4W9TFBWAJ/+tjhR/yoEFljOLQUoB45orES2ckvZzVl1nOVp6spaS2Btli oW1c9h81TQAvFOqdOj45qs5op1lPvYsV/Z9UQ4DcAfGmNdv8z13uruVrhIjt 3+tndin+LY/uWNF9lZolBCu4Q6Zb4+DT+DOAKzDyYeNiiCVJ5hqiZ7Lv8bLQ 5MIUVlTAkRu/3ZTFOk59tSjcjFhZEnSeSURM6+fZ8lMIlUq5TXvzDHMGJFV8 D39F87hnmmr3QD84n2fbwh4Rc1dxRqcN59441CK7iisQyIQLkviAuZFCqXRf +REirMUA/J5+jWwg0t1k8IYhq+Cba8qa6dQ5xLygAZSKSQXNwB2QMVrSOwXv fWGV6/5yxBNDGAUlCAHh955xePY3hjqOk34gV1XxgXFSB1/S7ZKhCP51LXFR gXw8v9Ra78mJRMEVRRHbfQnzGNqCjnV0mkPYnI1MajgKmrraK8nGFDd6BD84 GgmoWZmHyJvFqKizyh9leEmygji8aHl4S43c4k2QFxfJ/1xDw2jgLIe7fwGp hHLL5xclQjHHVZODxMzfTLAFgn9yAkOyH/ISctrNbIbkz2zMr1XaAM5o29TI gHf3Ls/eMn8/Gi7LGiob/1Jd2G8H+4DEcDitDvrtv3Qcfz3JJJc97hPsy9mW hfoEkhrJyvqYwqcApD0zNpVgnJdb0kmka3NegCWX12EOCM6Jl7ox6ScxdAiF gwPbt6INjMLZJIyEhBbHOK0hJOgQu4LCK0GMaH3G+X7jdSAzU4G3r2DE8+AB zDJe7R6WlzSHV6ON3hi7OuxYgJB9FbwmutoCaxS0hxIadjuv+rpf1bgk1dYT +gXngj0u0bmFcF3XkV7jfaWYGulBcuJsrC0wOw0bytZ4FSyS/2kMLF7RnuA+ zxkG2vrXX4fLz6s6ENbkiG8pJOt/I8S+k96Tp5HYNWJ0hzYRSjV3i/dSGhd9 KV+SbvUh9i/7yFfYQnCcA6d8CEwqxUgrnr9N9wVLqEf5geJwMdzlEoarkvdU RoPaUsAfns6rWEWMOFVsxZgQFp4xBLHIJPnNpnY7SFUwqbtDvHC0K71PrP9Q phXRiPNkTzDr17fa78lwm1dmqySTDEWOpZE+PTVOvZp/zV0L+IvhVJs1IMSq kfqVAKSzN4hQ9/UVdI9B876eHz4RPdUO3pANMqUSLbK7fM67P0txffH/mjqm 9GW3Jn1PDzjlfqHjuoPgi2Z+0ChfI2liil+JcIHX2Ss3jP6RMV9C+vqULcPu ySvQMIH0Z/aN9HbIHvEu0Ycu6pVueamCXzAyNqZ4YGyj8cItrBX7xqaJppZK 6apReHhXzTuYqkqGKojODN6q3ut16pRLp6EFVJUUNffYSuTf32KTkjcUyF+j +UNbBWmu8asHTe2H2YmXWOCnb4cRz6iyXxi9K4cCFbFN/myRaVopkoNcYdmO AKuvNfLDqouUU0lEKwULFoUGGtwJpWd+YIHFueOOa9i+oMWUztMYPWY+dmbg mQ4fMBlYqqXQHlSarrHmjrK0RMbBWPI6YLvS50aJB74omR5vaDJGSOfqTD4F qW1ScCLZK/2ftjXZJa888gsUmvE8jINfnG9v82d8KZFGC+RvVEstxhF3Ochw ICvUPigtEWb0Ytk9enr4EGa+powExBJUWDVnXiFZl4E9SoqGwBWvrTPHI+ui Q0sLG5jYXFG7EJO7vAInGc111UYE0/9JwnNwV3LD5WPMHcq1+zNd5IBz49Nb ENV8sXSplkZbyPicesIiH67XnGsoFyB1zS1rN52lqEsXRZiqKTRuiQjfHYdI CKOUoHMGABTRUKTAtF2oJzdGOrFbRSjP3x/mObV+u6dn41rF0vGNpDpDjMIB dlxFFQR0yA4cGHE5jOt0oioCW+jWNX9EqY3cMjRANjsbGdqZLWvu2n5iV9pZ CBj5l6kUKuw6J1wBtA9guZlTdnwBh1xNi11okiX84peeZgHgeWqiyj8ZSDdd eUZm5VB5zhvDl3aG95EtVwMWUazibov5r5FvI5vL3d0Yk4PE6Evq+pP94naN xdnWC4aSJMXPuMhrAHjSC2uSGK/GVMU855GtQrGHZx1chzhbFyV8BgH0v2+W nCPrFXYHGwxAW/mT/7iBsT1RtQr97dFEBoijbnx7U4nHWRqOmVDXPDHLBgh1 GrJDeX57LCmv0vcbPWIs24kskmlRUYahx4O6/usdJ56bhLUJInAOOrDnh7Z3 okxnUT8L/6Q92yHlTzmjAX3RWf11JhbwRzF4H+hGIdUQNSWdHgRVPCPjpl6L NJHTlDKi7JOTiPIwNoxedihncisXWY+j6k9mTAuAGBj/Uv5VO//TPA6VYsL3 N8DC3RNl9LizXaRI4Hxq+JBxtaAdcXkCnabx9l6heihAs0JMqvCMkvmGDN91 E1hu2+xtRKnWGzPIGL3odhfQilgqjYUKze0XGKMsKfpUNUDpRJq1ztzOXHF5 38IFR7oyaIB7hpdFKlteicmINk9ZzBTU6QwnA5ckwulACem3oGIlvW+VDQgG 8ME/3H9blnyjOmkE8q5yvHJfnv+AHGnd5rhMr6WcVO0cNjrygVdTan2DPBqz cVXkeRVs3UCo9d0yJVOwdNnetYOgt2V+PfO0QQ6nIuDJiglVV4XHzYW8HZkL swWyBDRrmOOZcYVSehnYZUiNkuEDTuRVXT57rbM5/GwkoY/0FbTcubXEHAqu lVNlSRJBWxBYxVigvZE6yCxsn+ln2AxbU9zYGYFCvi9TCLF6ynnZ+/MA4bLa F2+BrokZsczf3ziYRkNKvQtZVwgHGL6ly72YkDvYZCrZDPK62VGvrWO0qR/6 MaKrYXbdsCW7jbdyT+VQbrDUq46yLaldW1nQXwG/CBpv+S+MWAfSU9zlYGKJ ipsbBjai/xeBba3ppxAPCAm1J2gdHTiDMXwN54RRORiMcMmpWicWupao/wMe 570tNBve3yPcGUBH9mRj/xuy87SD54joj0OeeVwwEnnmZ2JTiuaEknjNgkY+ RdBJd0Rxp6S3shh7TYwxCk6E6ufHGqjk/nbPbI2ugV8805dmUjfjToQNSubP 03Uu1EaxaIFuFAeoTdsD09KNuMGx/TuKXg+w4Ae2m86odCj9+V4FzNDy6RLG 7DO05+jRf3uFnaNQ/QTFUaLkc5nkRjX+YyQHOEK4qi1aibf0xdLILVXClZhn 2xGFqmq/TOMwxFt4YdOjmaYlZi5EFDXazPNROyULN5D9FwBgfXChBlH66kk+ HPNWPiPfGVR3FZb/iFDGgutYCT+q9QjjG0iDq1HvsUX049CtkSV3tqoMiMP3 zF1DXlYBMxPsIDQcfoFVCZsZnOwM3q7jmynpiWYTbFX+TqxMwndOAxSoMeBE 42snL0nblwCq/bx9/7GkCjhp9Vle7rYLDrg3rli/cuKuuLKU9yKjqbn2wShB pmU5JT0csPfD32BAG7/Y2vphIZ+aNQPvzKHFwjfUxq43SJS8C5whR+V/Ebcr gc1cqdcQ3jXTn6B0XidtKxeeRhoMr+wQxwda8j1AUstcGYZSKUQyMFcJqRBT g9jRGwWnkTs5f0vMIiu5+MMCf5kZZ4/J9Mc5+8c7XtZI8nSxWRwreE/UHX4f mQr+DAlMS0B/KcNGygPWRLYQnwZsmV4BmU2sHNJpCbN7Ob0qaDz3SKklQur2 5JNpgNlWL+ILsLIJ6gDvhhWu5yore9XvKSwtFpE448drtc8sDTNXjlOuaVfR HqKWLcOaYGiLrMDLitugoKIrfgHHwx7JK3gNnHQLEjMxlij5MZLufAUoSe6b xZribUqzQOqauq8HIJA7d/Rc8Gj9D6MwPHMbtwFCxTMtYOJPPTuzDyP6+NPB CSPMzs4+7/WzG0ZrbsumW05tbGZw6TmSoQDzxV//G7QLUaYFriBGRAz2j6Ab B4jRKFP2d18Ut/elucib651opsFeeJrqOSXJdflGl0xqlLYXzKDGTjP7fgmt 09Jix//ycsiH216A+Huu4eHhsVdD76ubNPTBzH6+0giYH8ZJToGoCnxaYUMh amwVK4NOp+9KyF1KXOSoUsXvBdkTwGO72h0jmGnAY7mAGj69x2sHDc8VK3Co Wq7PkJEVjQajAcqRq2AnVqfQqlEN8x+ak1WY92GdpaagWA1oJda1hyH7DT/H +YJ6kyLkJdFnMvM25HLny+7nNW0vNmd6J3Ed+6LNovEWxbyQ/BzlEb/wNNOg mHKfbEgQC9oJw5mpXz0Pv7LK+XXADLx1JhA4D/Gs20GLeq80C9Bblmsew8Tr lIq/1zvkYoXwU4rNadIuS9Yx62i7SClA9KfpooRO3YdOVVRJc/sstd4g3Wr6 I4tFEM8eOdtYz2ngLPL6nF24B56F2/eD410Ox8KlWmP5ebxjVnsk5JKro/Hv s+mlRLiDgd92tlEedoLxlRMTpD5rInJBAY/CAf6KIJ67RiQm1VEx7QvQWuO9 TgrA40ziHU9SVhcBfMumM4ePT49m92VMVDCDt8HstvMwcq9dARY1Spw6n2pQ jdRqAmFnVPlO71qQ2It4Y7iBaLYGvjE6OnZuCVzvK7AkK9J+9XS5w+bcDBXG CO5zM7GuLX25xI0TMRSRYvcNgFGqAPPQOn6/v9Pz7hQBlT0T1qJTGB++32ZP /WBKKYM/eBMWelgSfv6sJNkkhH5OExsgjBxJ1vUY34yLZWaIpqJK6TPkUu3E WOQ6xM/MvrxRvwOJFueVjDh1PgCJ6FYADllq/z66lnUtIYZjcHPNRY3iCJr5 XNKnK1Rmp4ldK8XZVz2hQXn9Udnf9jtRQwmzjymfapr31rIVhbzhph8zgaBK WqSwUkvtyQn2lGzcwQ2vbBjnfPSq/qvjqNxECc1mWRozPXGsZbF/RRtl4m/i NigWbNgQX+4fcllMN5lH9SEWbpHv8fbJJtKGnptQmx3ZY6xXzKpSHeUd/Bzd F/SpcMlDp4z61+G0GzYpYG2iakuvg4TSQhobMrljW2GiFGT+wD6GEI6Js8si uziJ5mlFDxl+Bj/n/DLrJ804U2I02lsSpzqcEv3FGXMNeUIo67MCefXBjG+Y yhnQCrbY+OE+bMwldHUe2upsmQQ9HtEGtfucCm/sQMtK1DKFmxJlCAFTaSYq R1VKRR7fquQ3BXrG1mg+Shhxibfa+IPjdooQex8mPL8t+u7zcukljy3tiUP+ Y/1dvWoxfOb4lTY0h0JHqrgyKKXK9YXB04I8wSNniCNVLXGvIAuWVpuUF610 o/HDGoYAGv6ZGmMjq+g1CBOG+3awjZtpEVKtGKjXPhWjrw1nuNDG9V0E0dFq ej6OkBZPX/7P9yLVi3WtVBC9k6yYf2OGR5fOCevYRusTGnT4kWbKq9+qDX3s EUewVKziiePFx5bhaLTz/BjXPYbrtSSCC3nxMwrw8oMIvC7atxaCkjwTqNnr rP/SSoITaoGzP33Q8rcnBxmnOKUKOt0MiskfyMLooAzLjb/FIIdnC59+aZvV IfQ38QKFbMLDf/su6NddSQd9OIkYTv3+7yzh4JufduBfOgEFIqpIDxIZMfKZ GawQIteAiDnsWy/dReLWdV021ERGtnDyw7/F0X565xtg6o0kAdWhbl3BL6ZM mqJX0N2zhHUhPZr4pIrXhavDsa0q2rVTKGGUEFj/+9O7+d9i2NvqoqjHzGS4 6FmrPnoybA3ZCGHiurQNM2wxjebxIC42oM29i9tjCYCso0CtJopqxZ7xMkdv 5wWRXCAnVfu8j3dxj5gjbaEreBEuZCewTgAkZR9P7cynZih+ptcvk/Zl2dgK pzsKzJvo2ZUd9QRrTz7RJAF2Pcs4Y1ZM/INpYg2ZO7H6Cd+Ge5YUHn/TCyyr oktMoXQ5YorGhTrxBh1mjFbMBqMl70LVQJo0NrcVPp9OmdV0i2EF5hSkv1QP qORrNyNxJ38UNfn1xTrBKaFtRV8nSw3BLmSW5SrA0kv6e/xzNTr8QJlea7uT 7y6pOkSOhJretBJx8dqzloKh1c+xDuoDPf9s6FxLoBczuPIBx/jSvPTsK7vE KfnYBmsNctZclYIeMYJZdqcDprD51oZ2BC7USwjyIIEiTY/ThYBflAE+P3F/ xSKb+9bwWtnmXpetjGmJcHJhcUboCH6jd06it4j8P+xg+9RnpXixk24pH0yT hO02cW8fFz/EOuJi3m/aQB+MmxVyQTS3sbv0K0l0eP5margUDtLzeRRP9sgy BKbHH5Hb2ZpMWSGttWUZYYSa6gX6EXu8b5kFMH7hLKSQ+ww3c9TLQhlPyuIu k9AFbE+T1Zy4SfCKN/o8GZA6DU6ozZz1gQGBlb/9liF12n/dG9aPFMvtemzc tqI5kzojEHLB+/1wZq296U3J2YiK6LrkDdpk1b6RyU+AQZpw6+dr7KlXk5cp z4pY/AJfvDyYd1qODBT01EzkIEHi8uA4Bqpb+ukiY+sWOrT9oxji4/bGUb7g rBrdFJdfeWkaCWPg/7nRxMYtREh0aXbtujgLWrpQqxKPRxkrYTpHDlCHcnW2 uE0cnLstbvQ1TVOntpEj8U4y5dwCyodIBC07Tbx5KTljrYaYrgSOlr8XH+jw l4aa1E2bObbwZ3ZcQPWdET3+0ZZ1/S/jlVPr4chk1BmK2m+sr3WcrKXR+AAo fFq5UkTI7B9BVx+CpuXrODz7qqzXC8WT+PsCDB25J9glCthjQyJxwMR+bypb BdpGQcYN//V+QkOdmUFTNetY0+NlczPazwwJ17RXWzzhrbzjq+973CboeZ2R atHCUGCR1AYZvZyw+2UBZoOLvrC9GmzmF3kBpz9/tlzZ2eyHFMhdYFYmgyFu /9cf13+11SDFvplk/f7HldYaiekIY7IA13L1isS3ogtjaOs7B+OyICZ5a6UZ mApAapYr6IOZaCt8ZNFHjv5zAsfSKyqRocL5UQT8xfW2o9kTnrTFoccVTT1+ g29gSgAgieo1xRaLDb1qe9ebmxuNFuTazQhYY8py6bOAJX1YHOK4LAoEpHOF iDPznogzFOtZB42kH3+tGfD///TNryPNphKBUbVRtDLCfzQgLjMsgTXHtgJD 9saIBu5dR/HTCtyIpzTilkgMBC/l68vjByJOcSS9s3fumdnQX/W9O1jAM7I/ AX2b53fQhnwXXpdmim2cYEoSQGvzsaKR01YrwVD7MNMbCoyXRm3GofzuKfXY tN4WD5q19NnezF9jmsUgIXwT1Tttun7eMxcN85qB2sGKZDnxiVImJ514o1wr LbQBZ0cX7qYIqCLhOUYhieTSnQjkfqR0bQkdVO1x5UvCJXJMBlYdcyivoj4F HyO/jJDsSXbRD69jYIA10lkK0LobnVXxlHSbceQLwGVD8Kue6AojPTLuUYeD WhC9kZB8adzCXzK/lbF1QO4Vrum/S4p4QEeL4H1UqFNCAxgbQA48XwJyDTKR ke7NMzuMIzLotAuQtyac8nUU8oEyXiLST++ChmJqgoKcRWAImy3iokYBQQ++ S63Oo492EAmf1uDgXmBvCwswPGxaOBa5yLCWpp2XGjUc76MZpDTd+Rn8kEJ4 j3/YhlrLzXsRox8RdmxAunteNqsCr/cupt0sps1t4sXOYEqKwGhCvJj25TBL qP+MTVfQK4Kzqo0VPa1j+66hw/Lgsx3cWrtWl9+qxeuxfoulV11+g/3mMgF5 9ZMXGPHXnQLP+Fl5gEBBt2mBPfwLpLwENK6WehCS+0svOI3MEwYvTsRQy1+e 1s+wSsirtqo/dU9LKWYkCPe+rup3p03x6Y+FlwcWpDqSCcpvDSRsZYX6BQs4 y6ZYygMaHgYVmmNnKalPtBKjPSdtDhZ6PavwOzUUNLflvqlm6ylzlFzWsaEt kJwq0DYJ2hiKZkUpKoQm69x5vPaAHyPNSytoFIqVwOX7q3mUXiFYyijeAM32 x0+bR7vUkCwmoj5HhDTWv69/mjLeLHN3Wv4ZLaqWe4okIz3S9GbYTFQGtOD4 97APsXmSZguuuHcctOpjG9ffHtqxhUVWbJemBM6R3iyLRHG1oRzC8fqINHN2 fb02VpuNxzBgcsu1SzC93qhooH/6uMFb/5orvVAJYDHvyavvyOTJWTRqpWmo khfLa3LewLmp3iFEvnKh58CVh9UjTVoJoDRiERZJ8cDga6WgV0tvyGHddaZV Zezgz37TqMOX7iM0BNA9L78vewG8Q0jVNXwovmfpb2MeMxV1LKaDXmLbL4W4 smYw8QvJw86x3ZMNfvfu8W/EkA+Jp9k0J7xR880LYFLBF+3Fib/Ut87vw3ux D6cJ4drhLab6UV68GczJskuIpmq6tkNcKwHNL8sR37HNrtOKvdl40X0lE4Zx JEe+nYSomELrRk7MFrGspwpcerE7afpZtTZNxORsSPCdFwnS3Lxs4m98PUNK w+ZBo88/PVTZf3av10vqh8xZz7OVGcse9GUtkjdqWyGUENZjBYJJiJSNp/PK nlquSAUcbX8rD4P90b+IPQ5ETa9rR2Dzjmq06nO6bNKSpiq552jXaloA8rw4 O/0k14gwHcJ30lDfxpI+lO6MsootVAx6F+K9lPS1EXjc87SBh6FL1+Ou0BBM hyy6u0Mqb0DhDYoCIWkUJcoarLqZGyeDfppx6EHfULEjNnC0kbCruxpJrHh9 tHHQEpiFrswfQcyBhbyRC4fHYv4/cwZlTrgaQaBgbDUIrkNaCKKYtsECiajS ECZVmsSTPk0DUnsmNNZDIXTaknObQKe3tEBmHKocB79XSWL7TQ7LFIxtz/V2 p8Z9ImrUQtYrjwg+/5aZoKbPuhx4Suu5VLHatlhmCPKQ7XHb1L29XgkHIf3H e+JrwFgjjtYIsp2uf0BoYbFYNlAk4SxnEfcLzhauGQRGNsIpzh2wYVD76DUS X2Ao4eFHI+3yKn3ne8OWLqivdFjnE7l3C/qQkq2NkQCnEM7AAqugnYh3QfBG KXXYGmNeZx+01kERwxldikrpioAUgInnQVFuC/ucAJpGiqe1wvoIJ/F2HL2H tniwE8nQbMIfQxkuE+qzzc2XCP0ZLUmGv1x+oyaNYLmS0PZ26n9iMW4JBEu6 uHFHfZWcHS70HI/mtTITJGT3xFm63MKA/RHmdZO8uJmRnlGlhuqfe4QyeWCR ercpuecnmBrPGlpKoAZPSCTJbyE3Kx8zHK8RBV9O5BsSSRWVsktGXAysAsva 8NxD3PzK6RYTT85X/hlnby7y73k+KZTaaUKbTWkTanksFiteDWKhHvvBrI4x 4WAdXwvAzpaid/VvOv07i0zK2WBS3t+Gnh2hiWE4KbdlS7tb4IfECMmLgkAS 0DCDWnWJf9xBhA4oKYDWLHlONc0qETcWettcuILu7Ihmq5nue14/xRgUoi60 iioQUHGlqwsoGEjOHnLYOG1c657wbKAG4UwCV0JNdpozeJAv9ttn3mmVHfGV 04XfzMjxgTO4IAcP/pBarW2Jt52psuPxHfUFhbiOc5Clfh1fwTnLxEFdV1me x1nMvqgYNxAdyqvkKsaiaAMxUq3003AfgpNHBiHS8o5/ih/jhFJFCaEnuF2o NqE7RXgjfk1enpK1fAEDS3XjzmwDVtleoF2SNTdQyjnATm1qpAGa5WAzqx/T MfYo8Cb8CZAxMFeI09rmPR790j+/BGvYv6C8dRuQ2s9PVwkTu3EW77C9Jno/ eIZPNbPsUqXaCq9cf30ItU9Jrw9ju+z7P2AB/YdW6TmlLYgdGObD3SPZzBab /7kTQ2a471iGx+RVOVhpOyXmWPYQQzFOJ0RkC9TeUaMTpJK4E6PUjdvGJ0gj l31gJnF5ATcrTYSuMupo1ZiTYGnbrj3mld1ZwL3plKx8VSKEFVM1GOLnGmGZ YQTSy+8fPsn8A2ZL98XMt5xVtUVPF8cxa+ssptygWD9GhkhHc+nepQQVqkrC xPKsjoYb4HylF1Gzg7tgM2Tdg/Hy2FR251ziCedPj6r32HybWkxDbssAbLQT FK3ENCXGDzGVch0NG7USrJyCz30wHBlZyFHvjZv+eDB2eGqWfmFNfdHC0TRh pCET7HieVuUW0FPGPdjBf76BlS4FjxnyggpOYzNjkUiWw5DgfIs9ct+fQqYK l5cRzOJUSy+TRHBuxhEBGKoTEtB/u6fjO4fmUPu4BVvChGV0dz0q/zlJWvEV usIWizIYnjqW/jSK+CL8HSbys4B80X4VdPcBbSIBjt3F6YxveJsgws55KqrY cKTqcwvrPJfOY9qfSkzlWMjKf3NQ0oWEQQzN5tipE5t/HZsHxTskBNe5u9uQ Jz6VCi63iVTudzOwUzK0lgJod+tr1zM4/DUfYuCAvlH9lyAJS8+HkoUr2Hne zYtX1LSnaencaxmqxyNGXaowIf5kxzelk0ZCfIdhJffTjiBdr16pDTkGu5KT k4CEr6EvO0b/fGDRtGfF3jtSpI1LvTHFgxB1L0otCjy26IsKRPCbbZetu09m 8FiWhz17Mf6xjMRXXk55/Ow1aWacGIfSShEWStjCWHQD3dlHNV+mYGPrKQH/ XEG44WS6yjYS8Ei04KIRCCIEc4VFVDDtD61c0AX6DB2/rbrpTMsogZrE3KUR WXQvVAzsDubKMZ1LNVUqP2GjrmKu2LwREWFDzALRerR9KJPjfucmcrtOkm9N 1UhavKgGp9Tq/RU40/QWuiaw91I30b8BP3oHD2/TED8Y18DvodcMRPIv7vYO OUvdoPqMTZi6lSZGz1uz6tWKDJn1YOwjub0qKC7ociVj1svayngDA0Pkq+/I RIb8yJMWxP85SOvJujJD7YQeGexRM7ruZgJm+Kiet94DAuXKkuEAkCnFng69 DCU7tn0aCs1LqqNd5V8UjNjKETQKNP9dHZPgfHxWyYuWh43U607DSj5jzAES t2qaLFCMSiLgq5VxgEa8OgnwvR7H6W+y/FHhs86cZa0h5/MZx3Td0QXQ7+gz E+9vnk2PICzXAAibajnLoABgHcmW43lAvwGsLC9hYZPT3LikHXaN5l2ceK6I XxOygMFmiAYhghl/j18EcFL2nhpg/ssGBDQ0tns5N6p1cSFgEsbjKLffF4EZ JI0nEvATU7ktPnTyCAfIWjpCq/WTd/eqbHWeROEBQzWOvR/MqHIiKrhu1dtU yKDZjMHpH4lGTT571bGK+km+rLzTeiyfqQAqOcs8JPGFfHAk66k6kl3KpAtq qbfTtDwbN8njjJG0nr2zXW4NUevCDieNsOJPvBMXeMbnPcMATbc840KcpZm0 SjQbT6hCQO7S5iy0aiMBra88Rzl1YI1kdzcrOdKu66UqEFN2WH//6W6CTtxL 0khOpB0dBiI1TFEYZtzd7dQwUkOVJFk6WD8XxzgoCajJ57eJHj0dO2D2pVdq /Cw9WUNFIozQkbFZHDDy28uSELb32aQ7rLtzszZPU0R1+YiKbuHXyZS27deP +BgeEIErKYfigdl3zw3aqT/vM0GLX6+pdyssXY/JnPhYUYjd30AgDMM8ph2A ZSoCKrsgdwVAvRoIXmppy4o011CSO2PidzqtRKnHutT9bXm75f0/nVXa2z+a 07w8CvBw2ZGpPRvs24e9/6WC8qjFubi/LY5y1eQXelDWbFcs3RE5sGCkl21H t3C1Ra0iBlGnuUq6FXLqVa3v56xa51+UMikh957vU1LpnxZjNRD4OgSyR87p aCDbhFXhOU7V3dSyOYIJ7iTIo9BgZJsBfUwhwMsGTBahtN3xcz4spMDMMkqe nn3M6MypuiAp+c3wOLZvvuEE2PQZR7+ZUL4BXM94KAf+cxwaeIylnhZkVrL4 0IccUvXRkSRRUxOs9fGe1LpTwYW8ly/dxmjVNbYElD4+8VCrHZfWIYszHCDN xsNdVct99p8jWeB4nxWt98+EhgvklxVZlU7DkDj76iO/qiZjHRKRsnaHOPYU Sno9iBV6wBZwXX7Mvw18uPGM9Ql0py1hmjLqBQYQiybFJKGjF7yZ2nm2tpgf gSghOeaBG8xYsTPE+1zkCoXZHWhL0t4XxC0oq5quobafY5q31O9/wtsNZ3K8 cczkNsYdWK7BN1Jo2/NEWuwzq34a90KkQf4xhSAePLByS+AfRbTkrs1h+M+f ap9PPKpsS7AQSBqUEKIO96pbVT6Kh8qvNQcnwJmFRjAZJX66QH3erURDFSP6 tgHtq7GsuqqHoyzD5wWh3GuUBFSFzq95hPiQsn72EmwKGdwYJHOUHjSJz7il E+1VIngVHra/fi8yoFwWqAphOGWPllEGykwvo/Qgo/kXxGz7dLYlKmqriDmk Z3SGKelHU8L5/zAUsFsmxADCPHXBUT+3nObmnIeaFPCvdWIE4RNByP5zv55g fuSS5t2e3ez0zN6gGaqAsn/SQixlZ6CqLOncA55dji8qFqHnduro4d7487Ww d4t47qTJ+kRveV25f0CnByNSkFGwlAedfp9iewXBjlYStHnerPJphseDBMzg xUtr8mG/cT00uR5ScSUlBctiAtKDI5x5a8kY6ND6jURlfCUJM+j6Dg0g2vyr v124ExwglS1KkbVW7X9DvIpIbEW+rjaqX92E/trNDTcbpQrrhwOT5PuwE4BN 2HZVAtj5GOl6aPd4RBDBXt9aMekpwcsozwtMZnuv9e5h/XRpMFYQLKJfADUy wMpHTvaZh2izO/KffSR1iIyfV2/8ymFFStCfDZtzVDTjVO5T7VO+Abr3FB62 2qiPn6mADgaafKS4Ai23AHn9yb1Rk1sktGhBS+UG/sua6i/WLQxvTTeWVhPJ Wc7zuryEhu9eKFI8cor0bDfL248bYOjoTEd0r2Zwd0cGwIakNhEVrgDnCuTp jkM6lmDlbgqMr0W7kIFUa/c53VrKoKGG9F2bCp66sMBk7Dsz/F/jcdqZyD/E KBDvp9E6p1XkRB29dNHvk7Xb+tmqCWFSlYigdzyk5H2E8JRyAtATAh+WUm+Q 08cGoIuvleegLbkWSp0sZIDsCFXe48Fqr5CmOvenyGdPEQvzYXigbUMYWZgv pfSUBjw2TlKBL0tHNVbvSvcOniNhWz412UaXKZK6BpIVn7SpU07JjRoNni9p vUOrtBKbWqaqhp2mbIZ4DRP7p/SnkQfXXL4F7BPB2kFi1eJmEvrSeRa+qiq2 6EGJesl1lufjzxXNGtAN0oSxKRUHmMGEBVXHrhkgYa4slFigZAU8lGmlQK/e t3ExzsxVgskT+pC778W6Pa6myQb/m60kZElXIFcGl2J/QwIoGYckGJ8e+QZw TC4kzp+Zs4ZM9RYIygwHrXkAbhhDXiPw+HZTfg4kpPhrT/U6gI9chm3jur++ 1B0Ct0JC7HK6AYvn3RHxN0HlVZOreMe+wioe5O3mjzOcx+VTa2Jwg1snwuFq DF9iehGH0YV2F77fP9UbsQ+/cLA0Ksonrp5iHa9cfDyuFCGhkWNYiRYI/Wgh +obrTNK6r7eGiIGr1DgAO9b3IwrIoQ9JPJv4E6VBm38n3ugyZn9ZoMyl0ZOw JpYC08WIsg3yUPA2QDYgSuyKvHj2+DcRgUnu2XVU2qHd9q4iL8vowpXn81no aRVQ9jRbWAqKS0/LMeHk6fl7ab1B3MJ7ZjbILS9q/Uv2rvlF5wdGbCSR6aud dMZXlB2XWD5J53L9s2bURgA0HjtyXGEGB8tLlrarhzavvxGdCmuUl5Rpg6r7 2A2Olw00cwvoAIRcri5Z+k/DZULiUVo9cCXw21is5frfhlLDzUUK5pyVwlCf mP+P0DrmBSqpjiycj/HAHL06iUD7BA+Lrzer/KWcHvfEY0XLN57YRRVlwym2 6BvmE/xA+i0gdIC6hnnWcDVNBRbF0yb6xWVUHM0QWbCSksNVi0ypuoJ78bLt j+ksgiaTv0iYH43rdNhEGbU7DI/xIegTDTmBFh+x1s0AQP5SsWaPeMdbMZLu 8NTwsk4p6uKarJ0AVo7Ae1ovDGkTi6fM2br2TPRSSgf4IcsFasULdwO4mU37 EjklA44tIG+WdAuBKZF788CR/UOOTj7L1QdETFVxWNaUdH2sclUrwf6zrcW3 TaujyoCbF+wJZ+72k3fJRi0XznBNJzYAp92lLlVq5mZJfF5ei0uZW+YOSs4k X3yUnN9CLBJG0ZR7vk+EuzZp8rMck61ydvrrY8aWKzI9qSiMDojoRLvLqPw1 Imnx5wVVQNcFZNNo51Biy6XxsCXitOp4Qw4Ot5vrSPaXplkGQH36jahSnCrp m9+j7FJkCbcFP6d8wqho/uBGJjRulEEdj3KBiwTJCnkF5Lox+C3Bqn1zky2B TMDSbCMCiJfQ5ZAuQz9MKlLP8BVyJX9T5ueKjAYoVODZ8pSWxIzji/mmf2dd 8tu5Lwfb7Pa8wLXPqo2jmdB+Z9m6go2cKmpNP4z5N5DUusDouhyBGO399Oan GNUw+Ru8z1w5wfEKEjl7ZzTN4qX1nWgHULx1nan/f7tNpAa21uBms8xKuFgz MQ3bBKFGW/+Ke2ppYNpWh19yfi+87l3wL66ufQol0Qkn6LOSA/Iuh83O1BNf QRG1gDeDLdB34Mv+oFcUeHsR54xu9sbF1LcUKldVyPbaA+TaxaZf6e1Jep1K oPMG0RKDkw7WOZzB4fVbekMmn0AV7cOUbgkJSTfTpu/KQu7pFtV5CUyqysxN 7QVAt5SRKZdu4vsVF15qQlqpXS511NWYS6/7nmEzfdvrsmS24+5JqDuSGEY2 TtVdAgViTkpmlNskve68HHyuT2TazmJlWnvvGkodZP1FHFuOvHLUpLaOtDeV 6bVDdh5AaI4d75kt7YLXU1vYK6bIWMUYeJohz0JZVtOk/RSvh9aKc9Z6SvML aHo3VjxejbW2bgzB+uJAdv3sjLCCkcRQnuf5mP0y+HkVjTxLmqzB/urlx6fK clGwekTW0q5yjLBlVpNzpIHeVHuF9adR53gUr3MogVBCjl2qkqbjMD6/WbcW 0SA4e1b28tUvnGneV552NMcKTWRkjeOCiZ92Cbv/MYBVQvipqqtO5IA5kGc7 vWjqoQfcT0/j5K7efN977mpt2SJ+Zd9eGN5lgZ/i4v1PwzQrV+hry3mLicAe y6GhfPU5NfgcUH3ie99YMEEWak99FEgANZY5X4fhqLOfhuiG4KUYmfIhAPH+ Z2RuY4krj3quKh+Jnmwgo2O7UtvE0oyoF970WwAsFl6pcAYI5Anj05wE/Ri9 f/yhi60T0+GV+Urb8qox3ZQnheD+1aC5Zi9CkFyl+0QIFwV2MHxxlnTBuUTu 1DpnnEuuOzF0lp8f9TcHvaPa8MpgbxH21tkIDBnjBi8zlFcSRPRrSadGW2Sq JDaUuFxcw3xHXJNiKBPUQk6GNK2QwtEdMJ3RBnzXW8S1TtAfezQzaDdQsZEL N9GbVLqRY2AQP1r73/YSyIDulGueLMLm3dFS+uIBwWNToQEUs3iO7CkHzoGD svIBDKQaErWmFGL3/Vymz9uwfVcTrmrggjEMoRpXueFO11J23Sfcf/XtdpsD MpRyaK27C21H1ZRepkCDFXy9XtGtysdbhqf87UmTrsirIhkI9wF4aO3/m746 4XcE07wEsk89DV3oQ/KvjjZibI276TJt9oKkcxSWuQJ1R/fBFKhZ6hbLnF69 vH1fTI6a56rBYLgk3Cd6IksRucWiXOyYNuO09JC9QafBfhK9Z0ASz1/yAn5N 7WQae5JtBi83dlhZ/qRNkAhcR4J3AdspJf6rOOpA64DS+ODSEYkC3r7D8Bl4 RtSQWk1k6iJ45R6JLJTiDMnBTl8u80RErx28HvPz/pASaSuZld/4CNTIm/HZ 8cfvyZvz00M7/nQ/UK5rbjgRDCftOuHSA8LBYhNCtSp3VY6bZFm5kJiKf0aq KiiOurqq1l1/CSJ0wYfD3hcUpMAZDo1CxcZN8ghmYIYCoGn9IIBVTqdsWBn5 hxr9L9WcY8ndVCvFUbidjDu5z1S0AC5f29ui+YfK/vY2at4RVHNWeTbiITzl LePj37ectI6yh3lhyl18pAaZWTsmcAdo1hZ4oH91glGeC6FdzKWKKbPGFWvE nyKjHKMcFTnxQ7Xttxiw2cb2/4jTT8xyrqLElWSWGEPGabD80Nyc1KEY7cdR kgXCBo0FiNu6HBkrQizhl9HTqMYIh+kkAR99ye9Tarmz5JO0tCEhPg0Apanc c3Mt/HFobs2iQOo0dLd29iTwNh8ynZwQ9FlV7yW8bbr/zbTBKc0BvUXiU258 vHKE46b6V4X6kAcXGYGL9HvvpUDqBql7gk/Z+WNCKguGfMHTk7lPplYR67Dy NWwHu15CqD0sfN1svqc8a6aovWko5TT2pZYwldZg2W+nuQaYzqubsmTtkANI WeJ/IaeUiZJ7YWaRt0zpYOnTbX7ErrEQ+FraH7VKjt0gvqTUrXANBjZCOaFS J3SA1Pf8oMFjIWhsJDfT/ybYBSsPnlj1yOskx58IkzqM/obODUvJND/8Exop 9oWQHX6ARq5R+lfyG1TWTuNC3ZqhYEQs3CqTbBruqTrvGLyuz+ULFuvMpwuq BI8xNiurWxCR1C6y0mNGCaf4jJRyZE/X8tjKow9g1cDPKaipgCqhNx7ABS6H CNcnGSVNWurHhAwCElKbZtdzCnG/8+qpjZA2EgJ/fqtay0FqF3/02SY55Xid sNIbCGZpCLjxsWHROsfwRX4zooPU5ZXib8pf2xi8Jus+jy+4Hz/9BpOhMbQb v/jiFrTcfxisxK0FMahRaMQ+m81mjHCHVD32FL6Z6E0JsScqS6XHDb0RRxzv 9r1hW5vzfUzxsoI8M1QGsLy3T//P25reJrTG57xPQmThecKQjosh9c/3o+n1 omdflOZMpBHApOWvNyFXaRBD+q5kuHd43s8K4M3IxloXZvb/eb3sn3a8ZJh+ Stwyp80fpBOrwKTadI9/wCGD0JyISVnRxj+cojpz4ob+ZB4/C3DNmJ5Ukk1/ nDyFNY4CsyRuO722V8xBZgqtWDhFUDLh9LegyXWCSm0I77J1KzK8YWhViq4u mi88yoXuLAytw8Avtdx7ARCvZ4Zg7mBHvTWCN3xa6MLF8T8g+nXHNPPbVvVx KDzrC97MiK5B/PS3PCoMn4tJ6c6Pjn4BJ2ZBUcFv067rJZVO+tAJwTaPxbaP gz+4oDzoNtrkkoMB3r5eAS20MTlof0LVJP+Fx7PHjcTyrCjTp+ZznvFngJ6d 7PgSUS16JdiwUihtcxpuSoihxqUZhZw81F5VbFEqN6rUWEPiD/oWO2o11Gdy wVTcEblkGj+jRTcd3QUs1yIVOYnfNziZ1VGJQ1ZHdP2TIo3fBRTWM/UWN+jX PF/Qd1NpaRpvx3IgdAvl4sZm2smconxQHs+MXuMKuI7l+bSQ9Rq2YmtYbJOn LAUZIiAeH55XMR6MQDbKM6AuY7XLC3es+RkEFcYjLuDVbBdE9wLMtLVlHC3H R5amGs1Sw3fMEE2l494MUPB5C3qFNfMpRBId2Mpvl504W+3LImQnQFCKZwto 0s2GW975A+U+e4CC23iAM47BWZLAsv/GIu2SSLt4LROJWNPCJk4QDrPFK3vr ISD3cApQPyeVPvtrlk6Zvp9uMo1CHtg0vU5nUNOLWVf6jlE9DYm79GZISJ8/ /BY6O0n0h0iZ9hbA5Y2Ogk1P8devzZa6ts3l5anJO3noT7+ywxlmtWnxB+Z8 so5COfxIoAAZIcEnQEzxfQFBqN4Sb5HE70lgyGRgXTHgSaRwIJh2XmaemCzT mqKoRxuGqU1du6kD+5+IFpRMqaYP1DKHey4lp5XqCBjsUdjyqRPPTfwKDnC6 7eup2YSzZdalZrS8f5QveyhtLck3lTjfqCv/1nVXluaVgziCVyc9c7ykxDJj C1hW0s43J0JwgmsQLpz0I4yJ/qDC/pbF+hzfKUy1WvVDYhws5cwGI/0FOZsK o1RkMlo3Bkmq02WagyrWBKfVK7kJ8sale97mU1TUk9+GuY9/8junVbTdIhpr eZPfwWrFnev4DlduBexMd2HaoF5Tm8XijDmCyq0bPDx1dAsS1avmM51Dp1EE WXCJW7GiM8ahlT2Z/xKW6Sc0leNM62xs05+Q2qonqob3dKBoqXA5CL7nAvCh RgtKbWBxgbdqlJN0wYC17Egyc1WxFo3pzUX25ACc5Gp1CYuYyFGcGu9y/f23 5cbPsNAocPCfr0EPbg25CrXe0an6tRUebo1HSONnRDbXqrIcZQsunzPmmrc4 PqB/q5Cdf6F77d474qfIBQJmPWpgxbxG1L3/CD9qNhQW3jaHo8MjIAUZbgo/ uK5ExAB8EkBYoe66HOsBDqFSsrnoyLphpG3Mi0+GZYus6ap3td/xP49WdpaI p/8ivt8p8Jqh0SpcIZE7I4e2iGkqBhoZNs4W6vKkJ1CiavkFuHVHc7iEHGII qk9yCbyYxa3e+FTwf9qifFZpPUFE8niCccbyaTfnsXosNiPzfpQYfb1vFbo4 GytpioOUmZAr58RkdAbofYuVD4l8IUL3QCtkuY12+umAN2hSrAxiq/4IzhH3 z7JcWpntJlWh/QwWsKKFldHIa+iw+UTaklO/brEJIgN1CAq2XX0nuVlGn8At llzTIA0uott1jBj44XcHdBngUc7S2T9QyejrXiyAQq4fuGgnEV18IdqWOsqh CpMhsJxdIx4LbWP7vAkj1913rIR6bUCUlV0SrOtjakm9asrXLywr0uMCT94t JIJNe9DR4IbOqbH7+A551dc1qQqujYcPPlsNy3WbHVv5Ui8OzLvIY2PMes7N BHXjvsjiytHBkYglf6lC+6AfX8pjhNNrHoW5WCEH7oM90jX+1rrleQliWFi7 RVdohVQtPIjFBTZ3izGsJ8wa4CBUANvwHElQZbqkrFgv5Ti8E+f8Neqxus5p 3jR2YkjIQ7kXHhvEjjPkX3lgMrHKxmFVBDPXrX9awdNSxwLaW58gtBNmCsCN kOXohtJ4jnI6Slh+icohl8hEvYtU1IM4X5qooqOpEgLXNkrHbmAhmUxzTcLz 5k32rT8SOu6QJPGRhatVafkCjP8scUPnVZaez+d2tk1AyzoaOeFGA/g72LDl vdNMtdqORWxmW5Bv6u7XryMrscE3LmFVUMm9MKPFOY6Q7Ip04YN+VpFNhUM4 dVMGTLqMDelI20/7tQjouMIkot1TsqgdHkkeCXSL9hqxcQkM5vrj0h7sx0+O hH3toxv42m6bbVJxgXL4h+1RzwHf04Zmi+mRKfRpBuGwrTwx1C6pV1R0hEuL azsjMYGQUweJvL3jlEOzf/rOx6fQWY9y5jqBmSzLs7WtASt/Z6J2IEewq+t7 OpnpElndj9E08ZXTVZYj4ElaYPioF/yP0p4yngqlZdwR+kr4IrKpPx2cEcZK xB/FSB/IbYbq5q7Eud2cHoaZyb15wPgKvADmNc899NkytGxpl4GTEBL3BSrK CyUOF5tG2gKMIMD/jF/YzS6viHj2yXzUJjnrZv4vDfkEf64o3HSnewvh8M6H Qrw8aGCs7BsPISjV3yIlQLy9T7SFvm5K/aSdEcfuWpveTEfOmSh20JooPg32 ONTk/O9TI0vRDPY8zZDE15NyyRaH/SiHlrt3UghUH3wDu633TVyxBt+UyZOR PIPNUv8v+5sSBbjYekKKrtKbK9sC9w0ELsxsqS2mY4JdsgLGGbWQBVgWgvHG LhCVWauYkliVcj1tsD0Jew1/1uQLw0i/XXGSN9GMEEjEJApRugSQ7rY0Tj79 zKj+SeARxvBfcU84aAFMBL/gyVOZHzcb+9HumC+QlF/D6+0HNWr8/VnHNNDZ qB4ZRCzh44I6Ykkqx7iRxI6ds9/BQewGa9tur+TEPmJ5DLEcA0Pi9mS7gQqW r5twipooRcvq4KP6HHxW3yomWqfYghyvyTDiX4lMG6p+mkmLQjRizfuUz7Id EVfIQk1Idma8MJgnvLL9LwHrR2Hw3aVtCOtx2R98yPkx4ztjURTDge/WIrn6 mtIv2f8ZKv2p0mVSZf6VIKNjSZiDMWTqFVGLXNZNnG6Upm/7+F0i/FaxBDkY xvmrRolAEc9W7VFIvzYnf2r/8N5qxFaPX+zpf/Qd3RLdoGtI7ZVVtKkSDHWr MSfeXfPUWUz5hnC85aGKRvfCIHrcT7DWzmpHY5UiVq4BjyzAoLhtrTlyBUy/ q261E/CYR6d7okH8+tFHFKruzcMK7rY5RaSJ7Sa+1R3Va7pQKtE/iP4u9QIo 7V+z1N1TmhXgMSaPeHuzvvDFxA1rCowhnuZhFVqAsYuFESiqBCxgs2qcNkAa YnO+w1ithWI62aIfWrzrdg7gJeXykJXW/6euGMwzUK4/xH1Zs9zGoZKoqjMb VEM0V8nr5DRs4bZgYFQ3lCnFA+UyYWW42SU4m49H6QXA2G8uiw6QxVATaUBX HlzY9ZuEXA16Zu9wr/gX0jn1PPMgzD5kjgRTcW3bam4LYm5NEKZ7c7gp2jlb gguOc3/1jQIN77dlHUh1fc2IpmcpRjnFuQaiMYLuHuqSLpEaUbZwvag94ovS 9DTSaZ+/QttpNoRApKqcqyHT9Y8+fsbdlIynpUftJ4VKs7359a8ZSGw+E7fj u1i+K3UzpXq+nxDH9fdG8r0jYeAEr4FA+zfiFvE+4RCUhrovFzUIiIy4EoQt XaA5iqJ6aKz3Jpuj141bnnvts9G5oU3d8QdfLR/JAaVKakLOmqNnsiyuRaDF k8/FICAJz35YDbMFF8piCafBFvEeygFT2uUUQwMkwJl4f0S+vRXMu5dliHLc AHp0yC17X/7/E7jje7q/74lJEfICQ1poSz9lTp2cz2EbtzCMuwRIE4LvgE1B 8VuTqLzBpuNXSMYN49RSiJCu7N2Y38WLO24q8bKd5WAzzPGPsE598VxEpzkT j54vF76E83V/485GyJLQUD2o5Q14wmYZLZRfSNv3MfjnCyPmYKz5fyRQLJsq 2kSUCzKOdlSvG9gLeDWn2QeQhBdZnDmvZwBDkDXklEdlKJZ8Yma3xyhmjCt+ rpuFJslmrkUfjqsR6KoiPOF8iRdHJYbp1iMclrwbdGPFfU8+nfqVLoH5poXg Ru1X/H71+SO25mGj242J3uYfCJKksNQLhvD/Co7x4l0f5s0GkD9r6H9eFkbS Sh5dd7DKlgBIRD4kSVbJhxQs+Ehif3WHP2Ik+R2xCnM4Tke2Ft4zh0WhVUOi dd9J8K6dgF3Rlf547YIN98t+F27We04T5jeIeWsgfI7/CvwdF+aowYhVdGGD 6edk2myc6iWJOVra4yXEhQtV9jA15SYPWntzpq1mOg3yB8sUCsVXwQqziCjz 7LWAMTpzoYT2vW8Dz7n2l6iRELmTHLwCNcFSL/0nMnilDjfKnHwWfCinAK3H xLHlt9K38kBiTe+2f1DGvmG2uTKAQaVuACveGZ4+EtO40RiafDKSicdeRGEM 52I29UWeaPjc3tXHw7iIg6g+OyAAotKWV7PnzBJf+dB2hDC+TxNz3IaG7NY3 TfiiW4D9vovqvCXAn4e71UmrN6GVdPr/x2v6BvE3m0wMN5F7asnyn9iaE5xd 7Cjkfv1S1SEiz19Ijw7StLSG6RL7yCXy2WJO/thoiTqmpYMex/Uxy1zvutSi dhqjDsE7TMik1saUsdjQf4xRpnDxta/Q/YSyN63L8SBno7yZVjNU3hXznVsX RGgb29zmvkHPeZQyYo/Fz8kUdx0Ewk7tE+wHp5AXk5bh5tnbq/wiBl7/jHPX 3co3YtuLK44BKi8E+Zog1kWLRtVJXZIqY41CrWhTEAKIlvkqEReoW1sXGd0R 1rAdyi7cCGEqMgkaWI7xatSIy2W8muEHLMW1mSVXse7DZ8s0tmtIs6boo9+q SUvD9itptGizVchmuhji0SdB9zpEWiH41VL9WcV5iJRUGcQQey6MEIYPrJbi u/coL69SImlLqM+Rt+Hq4hb7jQhD0hCIN3EPnBebTva3EFFJoghDV9VYYWZK CZW46RROgFcMOWCQXdgrcSuEzXirVnvaI0ADmgsEmLzIr/0GDHQY4/CX14Xj AGVfl7/uwnmadc3m5mBkTZ5G9udtx+VahVAk+uSzqFiqPzekHycdTub/fIfE TgTXEtzzQ4BDJQvBYGE3qjt2vAoEXUplNsLuObg7MOBLqJC3NVsKZRjFwtnL JLu7j6VcHhtUxvypoFFaJKf4mIDRMeLo6X98FMUnhLR/NV9Jk6n2ZXMbgqC+ +Wj0PlVdNU/bnu85LIZeIeL9FwfMsLxDt76jTjGfJo+YjdH7+7KLOJbE0ODl DkkkM4ZGEYFllpoCmgtDQNREw2pfxdvm4rZlqU6q5cZMEiVajFtqueTq+bY+ UmbpVoTL2cRrbLJDgnw+oXevcaTF0Y5IiuYdadh3V2wQKEZk9WF+PYBWiaag wHyBjhkaBjhB7lBzaHwoL7hjuPW4JbV6Iz/bSjmkO6GFJVnfaaJW1WPTMbL6 FBzgCTrh7ocUumI7/TItB9qrUy8FqkD8rjEcsad+Mv96MQgWDi4LmL9DGxwz n7XaSCz+ZTFngB7JaaaS1XNfdOkIznnSGEUL0QfAxehmpNIAXaeAmF0l+dLg cEtnqCWT2QmiP4ls1arh9bEFryO3r9zta7UDVSH9Nt+Gn8dvKsOlnOQDQ1yk UoLMSZZiu00TBAmL/lhgbeAs282KfrNzkVm5NqjokWhHchabF6/oXO2Yhs7c rNZj42gJpDYyAD2Jedf/cXBZfuAQBjldVyX6F2TEi7HypTX4l+NSMKSVxX00 zaXRzp4L/DxByFJe6hsQo3tZHpfrJ4SQ9omv0AQCU/SbwqZX1OACbiYmr06v fVEU05BMvhXW1t699VvhrC+6iGc5KJiMyCbU0BL/s+1NZigAvGqKqdWwTgGT R4plJWSCMcmtwW4WGkin+Tsxm4IjCJE8jYcRsqApPkjuvMeXq1mcVm9YXYZ0 SZuQRssLs9x8aReNf6KiZFwqQU0n4BvB4tS8CRUDGlGImuhucnufXJKyQ2/J rJNIwAFpCs9s6rno66Th8IyitRPgsP+a50ESez4E06HbVUsP+qIzkLblNpmZ q8mLqQxoaDyepF5X/wWJVOIh9ruJEf2WAGa4q938Ik4/oUhuCGiV6szMNXgX zev9e6BzaidAM4qbKENYrbuV2kpyivCGFFTJiwtnKEq+7uGy5TxUK04XsQFO xMWw8ORsOXugWyBeV7lrvQQWhw4+2tYoT3ZR8LkIgv42tpfhdKYD50HcbLfp WLPeppdZc+FlAX99lrVFyGPsODBWQRfqdSAVA1jERHJJLp5kcuFqYBYHwwRX 9q/nBfSi934kxgi3QwdgHpWpnFwOXi44VIiz/PR1fb2SzAN++c0nsysuxs9Y CLX/rc9GzTwdu2dfgET+4cpjSCDF1n8sAmMvaSWzJN8+xh1aFmSYyO/CaTVz exnmt7ONNJCaS6IBvMgAs8oDbGSbuAWtJwqysoYYeX0Bxr2HyvOPg8edwhuf gAClvDYeyRl0c4Fki9lQh9xby31BiqAHNRAPhdUu0mrlDwGd2ihRqV88MEcm UCgPS6+G/1j3ph36zPI8BFziWiH9DtVvjpFKU/sEmEnOoSIL+ItqX05Bhdbz 87P9unnEdP1HIz8fJDrTuPHpzrOln3R3Y5HrGucbcaH31G6g7NeIdyRYAErg hp+sCY32rfsT/N+ppOOSK29b9xBGQ2FIuMcbqLCo4UGvm6gSjKaMGD0kZpF5 PEtA/D1vTBx8RZ9e1y+chxvCUzAHuLAsLmcD7Xbbj1qZWLLLKYDDBhqws2DL MjSCRsVY3Pn4Pz7glTHB+b5pstSdLG3vmWPAGmZbE3BvsEELC4rIVKSoV0bm 0ImFjA2V/E53gHojOwPiuOFU5FNmL2s8CwqSYeZq2ObMHBS6c3NzYPY/BAhe imHL8dqIhBGr0b0ChbuPjw3SLx/ewWuUIXmEbW315tXaJN8IkdxrVk3XX4u0 L1tflJTgOEZYoephaxoRfp+WD6IfCO5LHCP3hB9zoXkwxp6WjBqCh4Xc3bCk VBSxUpwGtS8D0JRISfIzOC/UQshZqb/2EcDZmNBhkk5Dqo/yoPp7GZYpuGGY Uo/Hh8yN9AiWbW12vx6f614rJde3csZ6J4lM09TQL8FH/S8lCnTyUUFZBdFz WtMgNzYLsb6FOfnDL3LvbsRtzW122ILDa0gJc/aGtir2fix/yKRIsMfLzSNJ P6crgHTu0i++bHw8yJVYO2WopHjaOKmGmm0YywjXqfrD4HBQs6m8RrO1cWwh eAB6I+38kSVXcctWtDiOyXaQ7X0WGdd4nlgONe/rp7oLuk2hEqLuI//Kly4b kRyRTwPNuRwJLG+pNeptB1q5AnE3GTFpRYi3VzEeiAB/qqO2uUdiw6eIj7VJ 7grYlGscePivp3+Zmpe9guxgBuPd+YpoloqI0NwZiTkvbRYZ3ycHU9QLnlTu tt381iihkItwMx1mRWlO0KTqBjl3JUMkHjHZ04qyXQsuZynGeNKPpyDqbvky ytrj7aJo9ej4I2KYMpG+QEqU0ru8wQShXW69siibcxGTZa5yNRi6BHsk9aHU cr09ESPUL8L9ux80eTY38lXRw26lXlHVsgDjTb9EHSRmBwO7uB5M1hEERzED GF/HBVWceo4oMdNz1xmKbh9GC/mTT+DKkwPPij9fNRW3MkZyxKGpDDL89ob2 spH0RVrns+F2/pbwfPD0zbBZ/229nCYV7j2dV44r3uU4OvoqFpCHivxX1N+0 gyW/HwcgDS0U6q3Y/ejz8AT1K7R6805+J84yW1+j2ANIz5KHR6w21Wq6eT7E 873KnJoh5N9TjlsYDA689YHL2QIFz+X8eIGaqn3apcFnYezixy9P9rw0kukz pu4SSLJgDmcinryXm70O2Wk3pDG2h244tZmVC86+oWcpLYRFOsbJdrIMTmeB TBNaP5FxkT4OA4u0RHkyWdi9ADtUSdpMcf6a+je/FnUkHPzeobL26yMOFIkD ETf4ddS7rklsPyBtDTuuJ41/7l6BvN/l2/BcujVGP0+8QfGZF44FBcvTvczc sbRkZO0v/9HYYwDBZgc46OSbOpl+YkoERFI2k89q5BnCwCA/uHx/hk/Gd7ht cg9vT96iZGDPZnDh/WaNsB2fUADZYxUJ1o7+JlqEGO+Gyg04DPPNAmwyWRKX MN3nnjPkW1w7EOAvJsEmnFHppvFKlA6T+1hrt27Isk5LBwpqXGrPT68EZ1va QgP63NmmHdPhmfWc0jXue8NrOJI4DWdRxXK2SAJsXDl24X9+GXSrSbn6csr4 bN+bhZMsqTeOLV/yoO+ZE6vw2UjW8tsntapX2mGjgb40QItGM9QG5kZRx1VY QO8AD3ZksRCVvpRMLJW8YgFqd3MVwd8wXx8Fd4InnjjVhKa4GDR9kusVNw7c ox34/FjnBdIoXS7HgzxMNmLEVPZotDHAjXPUF+OPk1sV/hNTTCqkY6J6NREF bdWf/SxIoU1CIDWQg9oZqZo7QHQJWpUJZE/ReN0dhOVjHAaWB6nEfmI1F+zX Iu/IRIoIfnrd8PUv224BX7KsFqdPAvJ+cIRfcgs0q9ex7FDHxxpuIZQQrGzI YByPHEchIa8/nTq7ddIqrEMTLERgqBJcjttouexey51iQsiCGsB2H7CarErv per7jwasFzXkOeNhN990MexeEv/FDJqPM8Czb+75u8t2rN4dv1dxVYeUUJD3 zLbBZH73zmNWz6SFuM8K4hWZaT0MmeAJrp1jCbC0BF0ziVyVV2EUbk8aifRg cW5uiJPCIKcgZXu/fGA+2YXPmLJ/JZBsF08V1m93jbm3vaZls1cVdtBhBWvs 6DTnOTj5KxZCU1MHyvWNiEyR7pRRzScfeTNEHRUA8EgYhSf9VsSk+5XPB7Xc cgm5pCxdDjquasLvPdB572M8EeniJp6kPxpqt+ZZdeuK7LV1mGC4jsMS/aI0 OwLLlcyfgNZEb6NgasWTbSDfZmPSNcA7ExKwHFWDKNAyHoxZmJzz5NytZfkJ i3UGBwbfnyB2SjARxAlLwyMaFqua0lYFU5yN6xDnECeMhuC+H0uq2TRGTdVM Cu8FJ/HQMIEAfWYlxq8bdr/T0mnavmDGiBELvR1f24liyYrFzLnHqH7iOlxR NM4TgQ9BFEvpLv2xOuLxsy8cQQ0zrL3i3VkmnTuDcoMZu8Uf+e1QGtBJkgIo YzIbqR27rujRgO2mdubu+IlTXP9CyJHRRzBxAMs5ipJyVwgHxMzyXypk/bf5 Sz0Y7mb/B61irD0k1np2sNlcaRBnN4bYuRsKao1AJZAIrkNnAONhBXXqQZ0r F4BrW1DNJfMa/+VkFcPku0zjB55r3PDoF48AknZAka43H9BUkSOOhUSC8UrA I+YCrHUApT6TXfMBh/kP0LzyIcj7YbpVDkO7CMcS0PRYolQZhO1FVHYuC3Uc llvgUznFIeforfVVzKbGoZAh+VYN97pFZvtgaOskJZjheoE+xuBtMjqT7hTC MgEVQ+Smen+RSHIb5ddT/oVUNXYCP42HX+s43r95n73j841DJuozYTZDzfsc Dls5jfAzlxsOP/0tXYvnQ47IKnrFE5hNavARID8PtVK6qhzQFmZwR8a4u1ZY njLhCJdMAG+LmNYaCOP7jDXeUXgC6D2Ecjkv4iwll1nEBMGXSPgTWPP78Kkz TCipzyFrG/CKaOlBwVuSLJ0mPq4+zHxhOhkSI8XaSqlCJncGwg4E0K1d4RCx fwFsLryt1CfRNRWiLiSusKK8+7B4o3xx+0L1qkjYZ5iq/+kVxzOYU+wIo3bC vMDejybAnqGL2721PlShxYvqlrS6wsQtDzKOlNSzfwqY+2w82M63rJCBVVlm GbKY1vuU9k0UlffflxhamAeZUlK7oDROZ3xR/9FoizR82sSFgO9Rlz4eXgy9 ueGXHsmFvwDXjSE4x5BnK2Mcarpix/ZBNGPH+3JGVC4ru64OeQJu7tSoz7pg Jxcbesu1rKi3E3EJwhwdXm38jDEf9SqNyGQMJL6u9TtpSznj+uyafRKuM019 5HkNmmhTp4TcXqEzVVahx6wALCjXYG1jBu7r5IkLv/yLjerlyMhgkAxMF2yR z328X8TPaf/WEQjSFx6tB2FFGPtUuZ4mNBl26cdiUG/4UeKWrZnjBSdEWui7 fdwOp1lhChcZWWbEIamKXKcCqLm4LLMOn5v8n9SNQWQA7UxZElCbxjGboeep pbSoQa8xR+2Ps24WSE2mZiS4uHgo3cVJdEVaOXAhm2AyhC3lfX9TtHdyZ/ZJ NUXJoHvllr5wyjTgEssmnFF4QqcuyMsMck9cuCidAU+LgRHtHNkiGbQYBc2S M1asDuGO+sKGs6sbhV7N9zzT6KzAgp0DFGnPt+CUBptCUHgP1ZFbJ9blL2pH hWGGKib2MymnIANgYpHYXsvTUBtj/1wzh3ycIMSkbVepkxTV7CExZxp/6xkl oyUzYszLDtcCZsTUvq+yoRvxADe6vahAWUKhCsTLnTdR2Z3OtWlWJCYFUxtL 931xO2VS10ph6PFEZqoXCmyM9ugsyo8XR54sugZlIj9YxiE+mIxrghkxSLVQ a8jclotQ8ZMadusjAEx0wrOe7ywa1qlSdEer1AYkdyWGJ9A5zV8CycbiUdvw GqKRu9saXVrClrs+4lpzXHqIwYAcQopXypTkzPdJZdwB9CaO+YnOMrM5tpqM 3Wk+MZREfxg+F1jhhF9aQMxVT22HVNB4vXYEKugPHHc8E9VWk2YZSjgmQfLr Gj1nVVgDu4Hym4MooawtFEQNIJP7rWiGKAMOjLjgiTRtwoUp2jA8Jg6ArvY1 1BctFe7FKiWE23ayOzzoxBVOnH9n9JWMqaXVwTx1MSlNHbIQeNW2xUs6b8ao 6xbENBMEm6aRmGoLR1t4D7noVFOorLIxMf5VRxbp0dGRdFpA4g23eChQXAco Vin6PFUqoIpcdZRyoJFqpxgatk+JB1q0xlbPv0p3GHd3UQBmMybMu7T2H42v LsRPOR+ZqDEyp/lKIBXcDBwAK4A3t47RidG0yth4MdG23K6DZ5osUqFQmfHb jX2tZf0yQ7sPkxn1yPvH11bn8st+GzB98Bvx29IgjhFeamUV/ub666kgfEvp fIM74mDoDKHVRJcpphwW7NjQnqBMJd2dQKowgqUig5uGOfKFc+dFfiucQtg+ qRf0Cd9xQwJU6XY0E3nubYcK/eE3FeYvZxG91q5CJETjbIp2aGus4USrC7FY jNQ98oj6o/Xy7m5cAnB46yyl8y/GRdsz8Dp6u5n6aJ5vd5ZZvznYQFTVYt6K rHYsvAxXiBExOfQ73CuFmfA+MveHSxwkBq3UEMvTpaaIZ4B1oeUbe8+Db9Lp Ty0B+WDdN7oM/ymrvQ9UECZIkCsPwlxoMev8BVMBZq6IZR6dt3Hehs7ioyG3 7KM8jtx1Z9W3OB4CiH3oLb0z+RJzZ0RSPvvMz5QWFvj6bqikKQuF1KA6D9Qd O5+FHho8A2FpGrbjfe5J2uuRRJ4VFWCY1E0A7x0YmX/2G/iZ+vknEDNB0apj tLTCS47853g49tivZLDV3AYROOndD/rH00sjayMiv1mOkCroxZ1z+jQn4fld kggrdAs6dmTxDNdAJKQn2yDmfTZD9GcLcSOXeqLBuT9k3k19eTK/13C3MX18 NLfhSi3i6Kk9uNqGcg2F0MCERndmc3ZT7Ky33K4n26OwXacNmj0rFP79k9Zd VZUF5xyj6yssFnh7mGlW2ErSSdKtEqQ508rEvfVwlQaSqiFM2I3w3FFT1721 Re6tplUjNMigmIxxhgShu4RzMLYWiYOST2sL/bmCLr/xU/ERQuARkj+WH997 4+B768NQEfpeHdcgydNIzoQqqE30Nsg6GngFcKCe7kEm0hy5wj0kyNyT8AMu OtJukEP21Gu7BCbG5pkUtZv1wOae0uuNbBPjnm1kakb6+oTTwUxaUlS+UEc8 Wdx5Jj0E3LXa/ZOvegJXxeOzaAv6vWN5YiU+bKltoKTp4aa8sJRSpzcZuxoI cmsrzTCrecBYRmmqBak41ZwJqovJDDMMPg/I/jqB3FvP2aCBOfjyjtaDSoqV S3GSdilX4mA+drbYZ2aB3JyQycH6HO/OCYarSbrOLkv0rNnZSSMDmuBfW9ix S9CscaVbxP1TM+f7oiCtkXsUvriIMOwqQYyKQU5gJfxBwFbE5UXHkahxbBwj g7apwMBLV99b50OwqjBMCmkVQZwk1cH9sCkhdt8imlo2Xv7Korg93MJkJ75/ c7iXhWvQz0r2NoFrEPY/mZ6eNhaua63NsUmUHKbx8ED4A0EBBFh96pg5wzif JTUaul8sbPiPCUutnLrSNWOsGEToBimm80Act5kumbVKPHuuMDCuohkQpH4P fBBfV2yEG4KuELnEF1XniijdoqMfrTfBPKf77n8z3LknlBtt0KB0SjSGTJ9A NDC3BTJ9Sy/4hDiKiBwGduXKdZ+1XaXaeiS1MPzr27N9sIWTuPhuMOcAXUPx Y9hBHI7FfzNPWkOpOwbo1voyian74kwu1uEjLIbflrFcG4SsVwHAPwTAgtVK 4pGUns3vyd26ZbGbXjM5ix9N24SL0WZwLVUNlVMpLTQ/LQMwJtEilmCdJw2r 2ZV4fZvfbp+2MrXq2wJptsKlOnlt/67hU3YWCiS3ZlWgZc3auYq8OSYRteNS 5oihhs8o85KbR2rhzGc+HqtqTQocahyYxXEnkkOWeTxP2Zpze8d7+PNefDk+ YkdbMJ1AJ76OGyjJnQvbJRHqFi+nlS/xi2Gd910/iq+GGf+d9YpwuCcW7ztr TClCoW7r8cpLDsSc9DD5L6I2j5w2T2ivfj+4IbER5F+FHXHJrHA8rOr8zjuz CImeUo7KiMA9CwX6W20COthhhq6+sg2jEVbj3vuvkCW13RUaFp/BX60g5zNm kw6Ew7xHo5x7U9XQBJrzS1aPhYslp6b8uFp2eExF5JCCChKsoQnoG993yENF Lo32GcXqGkr9S0YPpNdUgaOGdut4UBqPfJ8D0fsmz8xVr25CYspkX2Szw9CR dryCQAbeTaeeK8T6LLi1VDGNXfBt4AtJRTkIBv+T2s4esAN0j2BK9sbdaNMO wYEpd84rskwV7ti5qHZSvLSR0pmmMXSiUVZOGM+nAPcVs8QrSQahbnnSqapP lPyw87j7PkVTbQw5d82xB0cUszrHEZVahLRo7fYoNu35MIvkjmhgf+VL/vFk gbmTMkM41/cLV0PSitnhshZciWj/Pa7ZJ5GYSDsh3mkfq8A3R5a22vaD+8Z8 r/5las+FeqIKwfC+CwNtxWlifnvSk3MB8hNx9eGmEEWmzj5vG8CCNrNycKS7 C+btgle+jV8T08dMr0eGHSlDgZkL7HKg53U8vP8i+nsbjLz3b3G930d3RKr5 98nWbwmFl42WNkpFdbCZKdk4Iopzyrj5+DmRxwcK8g7QKUFUuLGpdkSogs7u Unyc7m/PEbYD1DwhV0/Q5aaWhcsH8ED0/6tVFR36HAW/rOynYYXB+ZW2m8ws AIM3WDkT6kTI6TEtEM1Ee2rHLqB832nMksotzsLIi/+EU+w2ZTh694X0S9r0 ci6vg8ZP7Ueg83uhGy2fmyCIe7fIcH1k/PTiqpi0mB62kPWuCKW6wfchlos4 OxF1mITdk/ykpxxQTFW00Nyf7EmSLsd1OF/VwZOlpQP+bJ3OzbyKJLA9H9M7 FN/gyzsTkfQzs3Q47zQzQInypndBwqH4ygz/1V+olX+cTw9S8rpujzPf+lZ8 Ju8k1Ns55ory8DlnMgOCsUDEDD1p7rE5WLoTFOXC/NL8QJgndJK7mxdE4KoI K/8176JbtZycrvAiVU57WMNT9i5JDS1JW3/Oh1Ks87dXnYG412G/lVO85CuM UN5bnqs8pSeU6EnMu22vwHozi3/LcmJhucHLPCadikOJfMrdoTaPnVJWrwxj Zj+iMwiwS5OYJyZKzqZZHxnQUXtXBrEq3Snb5mI2uZ9b/KAqwrdJkuBHIwyB Fe1o7PXaFq7BaDtGNo2xcwgwVd0jjGmvj+77JMAZ3Ab9YYT+1TvhTjJgm5RL yvQ/DlOGS49jOzWdBXOAnicmXVzSLvuBK7Hz5CA66axfw8X9Mf6egc6eUKhh nyFLSE0AGJVcDhhycrNjfbVZ5PGvoN+b2Nu+3HyogWdFSNDSuie4gLG54nZw 9TU9we4D1FWniqPy/Xcr5/wj7Gt652MgXY/yjPy7yXvEmq9A5GNP9x1Cc17C PdKAPJowA0hUPMPCfz27rb3k7V76lmHYqDNDkyB6V9gGPik/vDX7eC58Dldg ihIz3Nru3J+MSayeuDKdya/XVlGMxhunjHPbuxdt438sGHJNFQtvtJEajMVF S7kP0z7tKvM8V5nSqKUVLstgdgN+RNWiRtD2S/GayfLMtpcijabRrwBvmimw AHW4djiOeSN7y+5Fv6+dFqeNcym3D979o6HL7TDxlpSaA4pZy4NIcOBOV4ox PI0WlQfeT2+M6+hSfAhZWDty3TnESWRjpMBdJskpak0ZbOby6izQG9qq4pwo 8mwCgAC84XhZWRckLnBJ486cSjviaFtI3not0uw2KJNjybTyjgRhN7wT7M4Q nJ7q1A7EqZ4R3nASljB4xuidW6RVEjkSC+C4lBwbAnfQ9J6/hvSg2fj2Au3O jo6byiYlOLcT46BOx3MxQAOrfbcqXA6mRogE7VMBVMlloX+BiahAYaDqZieu cRboFUS07oPijMPrAA5hMpFY4UGaWEElY36+uFfZ3Cb5BBeb1KSnjE5QO/Gk hTi2V4SwFy2hOQfWeHQoSQg3Q0sFThOC7+1iakGbVqJ6i4neGJ+/XIqSLOgc qBlqaJW2j89H+1vw1mIpmE0PdvC5Xy2wmsxKQPfF/F4kqAO8QjKti6vbxs3t addHoDLwJrnhfcWkTkYTGoY3RQZA5LQXYrtv8FaddqrcihcV+K6Q0TBHn47Z mXOBEUCkRG4AwyLChfhHwgr9OlmxMG2/aQSlJov1VdOALhzUVGXgPTkDfp/h 2iKFKv1S0r1XqLJ77lDdgCl/LCrbiqe5rQCZQQ1zLYyM5l6vklNfM113trNX bIKtYqQTAgbzucSquVR6H7Ws9UYpGGO5E4+myCqPk7K6YCdnDlQooVGk6hwA cYJqBfOwhorf25mPtjZ+cw2Q1WUD1brDe1WvBjkwi6zuOydwxbKExOEXtbQs bJK5HoERoF8VfhEgHWPVP8oTusMaXNiLw2lb16xfSw/hXLJtniU8PtPKx+vM UY8c61QAu1mQsEXr6t9BUTqP7GRtdFerv5GGuX5sp5Hq+0YobLlbOqkUMw/A gCfYxcOSYp9sUzteTiVWw49BfPa8ZF6EndhfiwH6Z/GtynaO6M0QNgv5E+tS W0rR2oANyJjn+S9PfYgPkLf/yJT5OoFaw4yqKe7eshMK/8vqHnM+7l+Kivrl N9n5h44e9eJDq0VyLXRnLkgPIKDqc6gXd1xGxDjjg3vxtpZOyRd4OT/syVMf If3GVpv0Nhyb8U+1I7EHqK8eMswp9hzALMMQtObpiSABkwkbTl42oXTscyMb Z7cqzfe+6CCLiA/h52exZG6newiMjLtnYQCb4iNm1HruNTSKTBdNByv/EPkH mfXw6Cou6Qh0njqlVavy8jobhjKK85+8vgSAm+z9xeP0itXXXRylCM3lytaS EJWQwrLxDhz/xHW+d6VZzdHWc8mVr7YZO0t2UUDVE3edDN+wJ3LK09xM/pwC svEmBf5mdC/pcMgyiMo1sSwnnWEZMvW0YCgfPi3/mxSrduSrgKHWiTtPQtma 3gqKWnUtndpRCxDTdb+Bymq1dQVdWR7O1hplT3sml7OOpnpM5ucHQduKCJ94 OEyLLnvuhrldXCfl3PaqGV/3u+FE8Pl4oQNaI5xndOVPoi0MfMM09jsO/4kJ EyS2Aipb6H3YQf/jc2kFHoQlS4nd0uk2WFFKp8JayweZkLk4E/WmXET3aNuN WI7ltxI6ZFEXFhDfFJ3re1gE/mEt0MkQrAOU2e3gVrg03fLOirenIJLe/g+/ BKLWcU+hrIgiZxsVMwKLTh7Sk8a/0mMOtfPrkA6iqIyNuo4Bxc0MXQuN4ZJr khrF/PuCUrPBYJQJej9VxVRdqCIeRyEVV2/fbtwbarBqHyZtaI2pVk8oDG80 BJIg+/EuMOico3YkC3Jq/D1dFOs6pGKfvd7+UtTnqiJZHP5Uj/kqTAq4NUCp kdibpIBOE64TYDc/axSrFnPfTbPuN6mqR1MfL4+uAd45o/MHuWgHKHXg0Npw GVTx9YSkqDmL9WMtlF3Dq8KPiO1bzHAS1X5D+ATrESRr2kPpQlBf7bT9w55x mwcyi7jevHk2HJowbQ9qjGH120Jm/x0enRhSBJGOjmCkJWTob0XUF+a3WEXc Xw7aDkL38rCXazCg+tep+o6YpqhPSTSLtmHQiDiZNdCFcGWwRt+2aPTvBJ+J RILt0GK14ij1T0s+6cLQYiYXyEDGb2pIL1ICnewoHfCV4nEKMRhZz1UaMwtO C3527OX0eNLptcmHcKqhbLIRvyqNy+AC1SbJHfHdsPuJGnPTyv4gDcWyABcb dUphMEhbnsrVNMx4Yv6CnQhq+Di/Bs5gtgUBJXn6NxarncUSEijsGX4NJMVC gKpHdPj5+cJv5RkjUV8bhIPcwygS5Pz34B1l7rrNsUFSEC0CTvVh4yce7X5q OXv0qQewjXE3ROINIR5MpSD9yqdvn/bmOqAIqjuWpXKFsOdvGIsJjMkcFrrm b45udJDYgQMem0W05WKJ6HmOwguyzQbIQFEQrggHWjxkQ/CgLTtQIYRtPiW1 toK9xCkw8cfNgYlaDAOiPehv2lmCxwWj02bmbjXIdfWquUGSOcUSMeTQUTZ3 aBwlpHmb779UgD1Z6pKeaWgUyu8M2wY5/rf4ae+xMfHovPiHJP8MZaGoCRwU JjaIOsxKRfLXgd8p1sp0TX3AYZ8CY/cSJd+M5bkEhTUvdF0dfuERwtald6Tp 5+w80oxpiY7pfVd6VUfjJSatR23rbo0B91ZYVA6CnDLiDYcjt1UcH3Vd16Qa R3z8z2UPUd1AbjwY4pmRKoQEF/zi8B1A8F0JGhqlcoY6XvGTyATeUjTic3I5 dXaJjanmWxpJLVO77w/Dqu9HCOrQ7D8mMy+7YXBkCAtxmCwCU0gtyNCPkAed 3cxRrKfiq4kcsJpZiL61CUC5aaLfRCYVOUKGaVkW4BoV6vWqwYmlP4pm/n7o QN1l5+8x4kdfoiJmqqiu/sQRNeHtk1xwnr9BUi1YhKwEo7VZuSicx+oZ9BUf Biq4YbLnDRQg1cjqKMhGwhb7qkOVY20ktEChJTK6Zkrqxb0Ill1DDs98fjZG RZBe2LsxbCyB9cqWEt6GB3ZPGmPsZC4EdUFm8hr5jEhalxXFq6DFF54GU4kK KCBGTkVvIFRqmmbPrfdAzU+h2MlNLMqnxqnkmP7R7VWZTlvCmxmTZYCh0Pes ELF3lXoSTtJvE5KwSHxM4AQpiSAs5AgksgaDkTHpxs2iR/S8jt9x5Lfs17Kl wfDeLbQEASt/7oZ+Ze7LE4pyH80OGqL/FOcGhHTxYMQtnOEgG+safP6+/X5P JXH+Sc/PZwPAojLssA81IvA/RoRKG7lJifmNbreYrXJNHREhftjWh6Dr/CfF slH5Kc3xjQNZhQYZEdy09K80DSgp8+O4IddCCFOk+i5t6Hs9I6OzznmNBKuw rS0o4Drw+jeQT6rupQ2km9itCEEHWPlBByJj8Xf2jsQ9KmqQvYpThBvripsc HI3BaOMNBiMMcqyce3mVUFGCfs3W+uZy7Z+zSinjhSe1Rei/EtJUMv8MbpYj vrzhgnFLnP0t7JcNCXXh2rJxRUw9SNyDpJy5gltVkiYWBzVPbhIqY3IPmCIQ TvzKHEIkkxT+9Fh2yoU/KjWKS96irWQJZYVy+Uh4kF9GJF2M46e+Wx6iO8DI ZbT6QvyS/EWpZjAiJccfA5xfreRqvnboVivXXTWp1K+wTPoxy6w/oz1xXu3/ A2Zr1iFL2AENcchWFYVb4WFgcmNr8zkMiVi8kDbazN9tnnPLh00+Ho/ik//1 ErMfj+gR8fC3ltJ/FmYAFFATusgts1TAXcJHfLD/cIjqBCxmN/6p1upXsdgg yKtaMwE5v1P1st7sshBOoVhPLNgeNqzzIjFBcKMlG4ycloQnQ79fNGUze0O6 ABu6STt34d4UVfEQo7ahrPbP7vstxpL6CoRoq6+xIuXO+4fJX5GomGInXpJ4 Oh95kXiiGePFKiC3Vxi7y/zZz+tx/bgf1aqumO5T2KdAOu7xXkvklOYgyqCx +DrUTzBbBp9wseyroSORCsmDS8PqAiQfurvo0bfso17InWjRYu98hjoXviiq HpcU9gxPTpVCGuFiB0SCaBIBo+EubU1IZfxUeJHzAqNrOSweIDAsB6fygu4r 4ST8FnUm4dkKqpKtzloq/HucSBnXeN6XKAQhrhtMdx8/Cp5T+UrBURB1DH/Z vcO9nMzwbjqZ/L0pfnDAzn5fB1MIc3gNT1lRQbNFraUCVW4CW2RM1eiwypk8 guK60xHySO+8Lkyvk+pJWRtfZPN3EL7ZeTkPbfDMccqq1KGOgEI70bW7RkrT pnDlAvJI18ywEcHFsBqjfpEuH32KdGUJ0sLXA0sHJZB3iXkFc2u2SYOJCdhi Xu4GN4sALN29PQzNFWy9rFm6+hXEyVdURkJQ0D+UTcFOLXoIabzoTfnhqdoZ ZgW1PIp7sg5+sknOBCyLdjEG7vYCcgCy/YShGLRWcq9mlhYbS5IybGhNj932 2tbeUNAs+fVSgq3VN0ryVKfCnVSYSKGcQL+4268edXSXoktKpN3otKjGRbW3 mFLSa0/GtywCMCF4tY+n6Nl57EgRNZHw9cOyPFeVuSr5sj/MOnyUYts26w2g f4gYbZH9le152qk4loOSVadPYHK5ebbD6ypFhk4m3vlNnDRGSn0ine3Zazqa XNSGFL5B5PhKdn6Su+bxT52TbnWj9ctAm3hV6Fl0rDah+HZ1xUUSGgiyiQAS GzrMNCXKXAa8ohpNOPRgG3oQZJ0ohZADH6xQfdpYFbab2GROLa4Lro4PLtlO iyBIGdg4Jc81sC9FSNAcqCFSugC0NTNVGtr43sH43MpVV7/DA6GW99x0NXih QIDhwpSlamiSw+OQ8eY16CVfxHJI1fGNjzuSUlp/5GOiEd/BBmf5Xu+V6m8Z 1catdE62ten50wxH0P5CnlzTDYaZ3aGwunW5SAiz1Pr4CFfw5Iisc6P/SBtb AsOpQ9kdzRCd430cXeNlu/BChavMiJzULYP8GEhGk67mURXTrbE+vSk0aj+O pX54vUvbiQPedpDd37CVz8quzfthBgLlaH5zlhfgi9314csRDbDTzU6OvaWE 6C0OfMYPImOJgZv4GUVuXGzTAJUn4AjmF+cr/xJ1wkHbxmhTSD/8MQqGWItr Y5kNIWiFwasDcwixRlgxiDuScT1pRTuiOXMH6QtaFOXAejazM0ksPXKsei/+ gy/s5IFxazY767LuobFLLSnSUp7gPS2+/WBgdf/JMwW+QBMVi1nZhSZKAQdA FtGH2PENlX8HnSgooDXC5L87K8rvSCaPlYowbY8uSoYlfZVZL/DjohXFhsBb EB4uzAIeDN4qu370Pgm9oXtGQeTjPrGdLPzTKnYM/K+Nm1u+H6LEMerTL01X vN2/WFNxQc5rNcVSwkp99pfiFwHRZEYvI9YCTyTiF22IdRHF1xygZQWKiapO oA7ytZhS71HXOQP1wMJ1YBVRnDwfqSHycZHTF+mGzOg/WaTIeiXOPx8uGx2v qWDOeiNgg6CDCEAjhnxHDDoW8oN6nQhQrdIiZJ2Btv5IH3Q8RQ6K+S2cZ0lK b9WDFBeUAPEfaer3zA57L0cKHC6GLscLU17v6yoyov2LEKJMSe8oO8gczCmh LOf4IOmrK474majWI4duBehhhkO+DUtb+hLPk/o/FbhDtIxAQb+6fCJCwwzB BptJ88zuAEhikcZ190u7HN0fg6W6qO0jKdtEHihCRxTo6oy1A0XTeD/IDlNa BoqAZS8ItX2s6cjIvTysmwx3BMhXGRvbs1JEkw91FWijMwnLsMydv0w1mjQ4 GcscKfLaTF6r73VBzIlFzmdO3D2CELSFywnPDSRGWR5wI7FIfPwFLwnH0FFE e+zhk9zoU7Qtgd818sOqALZX1W0zRDOLvwuf/BFa9TQNsSuJlaiOzCwJXJ6A kvY+K+rgcw8dzF7ZxUcLCuJgTY1eG+VGgR0zS7vtS12JXioBHd5cIiStnIUl E2JMlEfWuNIdCipZXScK0B71UDud2Km/M3tJkYnL1DxsAT1Nx2sxDeJwEEg2 2yoqnzp3egQ7ftiEKOyaf2x5M7uAi/e15WwPg+var4gADpc2gYeivXRwUYwQ t0xr7EegRaUVpQv9UTACrv4lwY99dLrQjUjWdKQP+WpNq/tUdNkwjeIRi0g3 acRHEP1R4pXRRjauWStmc0W41SoopIQQ8gyASdZj8Vu2nDfeWm1XZJcNn2Vy UFP3nJ8hGQ+6sqGK39neoT+wzzCfEp1KCGi3120O7KoOqVDq9XlctFCbZBaX /GESFb1McWA3dGNFexqBWUkEozisO/5pX5/m466pHVmpTMEQCpW418MRaIR+ clC6sHhrQfZdapMv7Kuk+aoJGBrSjYBKHOV3dPfO6m6VeoSNk+AMfRHqAkbx iU9Xm2sOe6L6LbKRAg3wTcfZ3DZLMbhn7xC4yL/QmXSq7L2/bNgApd+waZVk nBJd65aS34n+brA+OVGKBMO8CbTjGA212sm8Ha9zX7xChAq2qN2zjb4ujqcL 0ZKhMTRAMoxj+b1MEgVe5KY1FhriYwu3aTCud3cEVE1ScS94paOXrmzFMRul PWFe12WSZq0SMgrXu3Nnh234rH9ttkghCgK9QJm/dL/eErKbx/qHsPSvqMeR wOnS3MKiZhjHBSJDQH1BnDrRfdR79modUhsZRQVd0mon41sOHTk1eaqEPe3t qBzy+oZoW1dNq6wB+2B7cldmN4IhMU5P7qLeCb7l10qW7kDWMctBUB3aoPBH RLcZotbZHz5v7Zzi7G4pKEichTIhxoeonztI9cv3qzLFN9/l7w1yuDOEMrYR fIu74C9D+Gzwlh4noxLFc0hU7DfUOtlOSB87MKxe5tXpUpbsxR35Qm6AICNG LKtN4I909/wLcCtrKIlqcNAqPBACY0eOtzwCjvI1s+OkQeVxMQ81RcIIJxei fmOC1F2Esj+WfGOl8HeQU2kamEkRdgBFdC3H+tM7rroDH7HZ3o9J2SKNEMQu MsvL30N30QYYZj52T3DJ+3mbzajE/T5s9zF1GQtqTdtIXnTxm1ea0boNx16D tDGPTP9nqGJa2HB90vJeoYn9VN4gvRKyYQ4352M5Wr+gRjGmhwFVenkUILz8 eqp1TI983NmXfa5Hr7PFXJGz5mPhG/HTW1KbrJ8L5psMEsz1V/4wdTd17LyU OOuuEzVQoOMkWGoGjn/IQ/5xQ20s4cR3JVU8K/akkej6JeksQ8LqISSW2EPo KAAiU080g/4vjdFIGcXoTsXEMpdEZPg+i6McqrHK0148xNU9iyOxuz8s3+Bb RPgVFAo3EAESe8G3hGSaCshZrVoWjRsDNrrDRqzuzhVYUKAwkWggU6kADFPX t1ERhwLXoISTgs7pSllPBtaErlECWpiMQrEjGdc67oY+IIR3f0xTOKcY+Q1p eaUTS1bUBwCnRbWun15RB6VjkXe+g3s4ENuA5crezMqGuRG1Rc+T+Jr7eYko 4a6vTLtd9RVIW/3MADwsLU0xoyguNyVS2dCiYzxCZDC01j5wm9OuzrXkwP1E TCKpifczToieEMPooQF/e6G2cOEHXebd4pjxicYs5w03hfXsL7q+hqmpTO/S mMHzaLURB2XBAoavmOg7oRuOH7yXeqgRmAaRT5IJghQJpWKAV3iU/lSMeUtx C3yza09K1eTLTuAXjmqrh73Q8Fozuu5lNra/GkcUbhBQ90UHaV1EN6KdPEdi NvZwol6IEEwMx55W/tTabqSm8Z82WxW8S+GD8wznyOFimuw7KKK/rbhKqQgd tO1JjlIuABBVnEZ6nCWmeGXq1WIzvb4Uzhds2ayjC6JAtBmU+PDi3UTR5NN3 RiZMrWK6RBM0meyeTEGyVxYf589+I28EBfMJo9bW5xU3fnZm3Y42oZMkE5yk PmgIiHWD/Gg1k9/f6kHToHnyd62EjzRRD5vM3tF60SryegxZSj0GzU3rrIcl 8mQVvIFC1yAbpWbsJSlNkdHyAkMpGLwK2rRrwpOOkmAKekVyQMIbsV3UTzxP KhhZkdoigsbCkUv+vj2fs6Wo35gyEzpRJzQdytPrDWOWX/8pW+LGt68mt1YD LOYNVsAnWXbvPWixCNwfzWtF/8/1qFUoX74p6VllkoC4gMbqK3mWO3UFHnFQ 346uSQgrByZXG7Cr7EFqc2AI5WMNtpfTbMgi9XEqOi9n8o86s0igWA+lCKiZ kPRWofiAvTuPuqrMMUUKe1mYVPSV5CkPOg6JdSPRFXCNKf6ZfyR/kYzD6N/8 C8K8E0ETc5DOGdjZgJq+vh15BuPZF+UzN/tnGAd6UiWTD+rxSXbcQQ0Lozwv 6oSpdzI99sdbLrWprBfGTy+fIzwKb7U7Unbzi9tYqbmtZFntDLaFzDitbNRf WnPoTqgY01s81vLwglHjVCsp9gfjOlKBsM0iHT2Gf1rz8SS96sh2m/nIFRS3 78UHWnoLkxvjodimo2NtYI6+qFoFLrhigcgnpmcTs2VAaJqUsKDGkaDMqiM9 3Z5lgFbxchEWx1ypUgWr2DLPgk5+bvxlKhVFFIj6bSmiooNF02te0I0uyoTO JjK9D+jHQ5RQM+FGlIEuXhk9SY0aV8TTZJfzlg6it05314fhsVhCY4EOwVkC K7Ur11jif6kyPoFFYIx66plKw/nxBpt99tFsrJjyRns4rKx/VJersyPwAAur upZXhIxxZbgaDVvtvQQNmc430KCNUtDkYefTzFzzGoV8aftMllf+gFzqIcU2 8dPVaqCmSw3l2KTUBMzYql5gobENEAHgRnXqcNb3MAKfzSc//kzwf4oU6VO0 pC5wwKZGQCHAnFi7ZSxjPLHcqDsmWjJ+oznoxoG6SGCinIMeRFeYCfoQcVDY R0NCfEphG5Owy/uo5uBI+R0o79Aj1wjstejrRmxgim4Qt9CwnuVbmfOdq7xt P04ZCKDb8ptAEV4+W+yXB09UHvn+gvyAQ2K9XPC+FAxXHHGq1amPNvJFEiPp SsTkjx0nOWN2wdh3+J7DEBz/iQRRvqpLZA6KJQHBtM83kVB0F4898wmt1mau wnLjDKt5U6UtdOVGk4ZJj26dmyt/rCNnsAl8QvsRtjYlUBLeDOSDRr3yeu3N obdbl8/blY1AXNPJ//2CSa7nxF9iR9u52RKDDllqdKooIltlOFroiMWb4s9T ENdF92MUw/8qv4mTkd4d31YMdrXzRqiUogwB1cogSd1/9IoukHOSmuq6i87p whsH4e30M+fGXUg6K+hFZSJ1H8ZKnkislKhiGVLtDA/8lcResI0HkC9MadX9 KMZNQeMMv6tmBPq8nu4+FGf+36AJ9BSCDvt2kL4culnohENc0N+QHBlDd9kv p6qDbiT70M4xM0Tma6qtZS/EJhhp2pQVqGKPwMJMyiYfPx4K857FDBnvP4O0 e73i12VAPefHQ3quOWukv31qSKwo5zZi+ogzvJGq7Yih+ywZpwJSjyDBIGmo yPDs8rWymXp3SeOrUZAhqsGeWTiZN29dj18rFW3fX+GPFe1Dq5lRrzJ3TtU+ ul2/VV0PGymw9xJ6Y6sipgwrIlG5IvJo7nq7G5DnRVwgnYrXp5XUI51Hw5Y7 jdCPyp5BiC3HQB1WOwa2N/rSwn2IJRUToHJHTBRJIoKTRCQ9l9PATOfqfguS I05jIFWkB5irFCF0Ss+Izv7AJC3CqD57/oQj6VDjHtSyJzyK+VvLB4JZdRYb 9vQSJWMY2IWoKvRhx9M7XxHo/iz1ZEGN00NJwyxR1KcOspIysxYAKCkPjAUi 1utX9HbZDYriGpzOPiMYoAZjaw2YB7PW5W0UJsZOT21sTcCjM2OwiHnkPquq qHvnT7hL4Nfo3Uyq+KkEDsgLIyuYyNzQJLWL7uq+0/MeqgmENBwkWHz3bVMR ku77+ZqD08wNEC5D+ZxagY5PPcnREa98EHj3iYO2gmq9BN4+l0Jo7/GFeS4H gNm4BDuXiFyPclZMAH7WNJLna7Xt7bVV1L74kZ9K0xTBhhmOWbSWfnHHPYIm tBUB5oUrK37BrMub8gzRwgKyT9koIO9K+4oQa165jmsNF+dcKRB2uPMucjIh unqwCIV6M9JkIgAeQx8MvWYbOSKD0gkHRbog6f3KZpvU9gkB13ZfOPj1bUL4 THIF2UBcYToVSzxuPl4EaywFAlEMKYHoQVxuzKs3r2ceQ5SlLQXPs5EGETZc VlcMLQ6Staf4/LQyrIcrO1HqV3yV1+9Ae9ckpQRMS8dF9hIBESM6dptIntyv TnQUbCwipW9IPrZxqiIh/MrievalHE/CJ49IT/Wl3wjeEp5YVNLEKltpUAWL p51otkCs9D7TpsSvkiEmXhE55pa+tl9CLzOfz1FW7vMvuR91echxo6IJbVlk oUfPI++KOcKxumW16iSeyTklpM1usRghJ3MSk0wdWspKlW/rN2Jt7uxgm+7N XBUknIq09X9ukxD4OnzNbjE0HlNNYXRmYolDUZ1XPjsFPOtTj7FQTXAmXt05 HPYGvelF10tLH7Pdvl8muqDf33eeSGk0anYo7cDDq17WDk1IRcwAzUW6ajFk kMtniMUy+hOptB+3HcVANxD32oTXEPTw4s62xFaFsNX248KobhXlOmgQPtIB 4QS+OZ7V359QgXuK3UTEcHpC8k4FGk7hN6/FpIjLrROC11W5mb2axMRRYXuf 3sQ/LjYgmqIW3SlNH2Ljp4qQsKBNhvhW5xqvdVmmbyi/VVZf59fiI96fa/r+ gbMbJF3H1BMX86orjTJn6yAxFHRkQvOPttTkcjR1+T7s/WC91P8EQwR3gJGm Ab9SsSGb8UAPa5lrlxnR1RdjCGMfNdofyreuVXJtv1vOdLb/HKRE3KyiEVSK lVHRtf9VW73F2H7M2p1gYQ1M5nOzUu4+MvYA2sxwo50qcnqnwtdzs7iw7Y5P Fr8Mj2vOrs7UZ6B8GLHslOrwC6iSEtrxQQeeKC5RfnK9L/sGopT4eoNrz0fe yalEwkndgnChkk0if6+T7ehIN2C30rjP8EMe3d30ICN1YBNtFDl0kbFcT0xB S5zdDkj+iD43igdOrPzSFCHQ7POdS7bbzHEMQMj3h0i/iry/mMbf537ySRR0 1Oo96XVfqrIjShnEa+bkGAwkDiL7D1su8i/RARWV/LOtsDCC2PPFsLtQH6N4 T2ElGYcMm1+0KowF8a1XB/wwute+gOtpJ6qDtiAMeHcqqz4yArpEm1OB/9Bc fLvk+C69isxhA7jdbSGqn8v9U+z+djfEUtdjhb7+pZtwyx1WkNXSPcEAQzbV +7Op5WbQci4QwU+xVzj5iawcnO8y6xHNCXhJJscbTNo2phESa7gnAd4SBSSG ILYFNivbbfFI/o/ZKg1iSe9qDWnax5tZCpliZEeG+r+s1t4IBifk4Ksj5gwB h2OU3YJOx76pkO+qGpug7upJ6wt0ZeENdHnGYzyJQgt9Jaew/lc0FxAuQmis 2CQwOCjw3YSOsbNyOe01BAUeINlR3f637q/Bj/bKq+stvA5K76SQtye8Hfdo X/oOcxlCxt0dRMzcP3Vx6r745OHwkRrt3E7ySGGmRGoje1bZWvB0xlkWCqrG IJ1zd0rn7L8tiL8R+oEBRTU8KVCQQsqmUmlKmaUmbKotR+zrC7yS4CrcL1bl 5IIrvedHZtAsIXlTDLhIbGWHl69PgNflOVdCOUQR5wS76zIpaaSovJ1jLDMi MgWcOhGxucu8YgMQMw2PrplcByZTdhDJIX9nv+yy0zWUuN7ecRT/rKYcDKHr k3MdlVV46r7EFtpU1Nbv6akKTzcte4Hy48fTCgJK+NHXAPsv/JgRZY22na0h inStUxR9Q1lM1zqNETrQC1m5qOnRsD9gFTkyTdu8s8hf14JNgHXs0nNmUqup Sk/5HDYYrK043Jv95yVMb9QLMJKzpBKQLw+fXlsuHXztaGcM1vty4A/CNabt o1mi77T5zPiFGlHjALALZli0K0Ou2L0PxCAwrCtzVx8kNdS+Ggta+8fHODxT x+ocEe41DvBfGfxgQ0EzW0Y1KzBW7klFzSZTG4PviLxpXfWgGtaJmocfP5zm hHkhIFbL4HByu4fr/9yR+geyXGqhz47N5GrnlvyNDpiy1BCA/56GUFKi2JWN IE4gZlkNl5w2YzmbjkX9wKJCB2ZyAcHUBdLZh2NSCZYm5Mr1U1Odevt8GVUV xDy7FxXCQFZ47RLreRbEtOlML+WjCHWL1tkEBA3b6K6yYGyAM7dJtq7U4+RT NOOB3KBkgmB0X1G87PyogLsZ1LIYXBhe240N9+fqDcVDRHwa/BpStgSjaE8P e4K6iaxVYGbhkTJHNBYde/tR18d93TZ7yf5VXPMwXt2PKaRbLUlTO94uFII1 J8HvBXanTJ/Y5y3BU3c7EaVLx/TKd70kgegg+WT+6XU7lebTzxbxd9IyCqse SSpqsHUPXPGgJvJCGirCJKvILOLnbwdlOBfcZxAdtBwMID51aVcxvtuXaOye AYbOqg/kAvBVo7Bjl0obYl4GbL2HtSxCX6CcWKTf9LL2KgASSWbnM2wJFNOF V2Opul5EPyNpHbUepfhUky2v8iQIZgmlGV8PvwtsNWEqsGKGI8tghk65gT2W SnqF91sW+TzkoxPUh/S+gZn47Xgg37xCjJH/fCQQrRNPCbZZ7ZECo6QgNW5V C/VKkTK8KuIFw7+j2T6RKMqLeW+98jVi6Thf3yB8MoOgw5MkQTrugeAImk6m F5y01PV9w2Q66yQJQYo+QmshOqrvrb6Xg8TpoKBo22ToQo0NuVs8q8llnI1X ADANf55/cKa1mOx1Ai3uofyADzU7LXWdTG493Hopfuu1DDcbs9xeqDE2WmMj AVwIRu3aaoSrYllTCbjlYiDJPtlf6k01s/SOYsdZmyVNtGdD0NFQlacA3qrz 9XNcZvwUrh2GLaBjsX02F1oYLi5r2zz5EqG+4n27qiCUDtnQXG7bzcc9JCY3 ntBIbo4AIwjHDe9GW8tSo27xD9pqVd56lbfEIyyw8udRx5UvOelUpU/CbMA9 0AKk8iIdkD7iFFqMytg40p9piirWGPjkaeBkpA3U4vdoDIpEg5LUXzrzsboG 9N95iJRA7Ht/n6817HQJm3C5fN2XOqKkFjpZjMnWQSS5BieHC5Xrs/wLeYLz xYfMpV5y83KRDF2TAWaqK56PfihVk6tw0kPJhy4afEfiO6+YpVMsw34F04vf kARFw8q8dXAddU0O/ay8/3NqiIydJqs92kYZsNh1lg7SMJ5SxwBC3zgGYjsy UfC31ovQb873WYQQf3poG5q2hsFzH5/ralv9yLIQJMtW4jcq0xj6ft6esonI UPZ2QEX8kmmY5KLuXE3szlf5w/9/WTSPR2qwNN87nUjBi1HE4MmT1E7cWb6H bvN3heUj0HZs2KipH+4ZscIg9lZ33THZ2tdJV5xeyJCrmSK1wqeQQqhtOKZn oAYUb9uB0ZphDpuI0BgWJhrXcglKlNAQjQuo5dbPlRZHJd+giQ69a0HKMv6q 7WrOVwp/2d9hMtQWZ6bdFaR7EKbu6oY+HHcMKIoDOuhy4bgKJ3st4kX5MlQ4 XsBfcl04ISWliv8EiG0CXY1gpod3q2xeELs+/YusrCs7g4POgmbCZmT8u4lP ShjS3r2qNLbh2pWYI04B5OGXzAZJfNRTz+3C0JN+fPA1ui0a000DKED0mvBR XQutHwaqrEM2cwhrxXBg7ZNEG2+tf25MOcOedfYjMobKSLaJ5f0GpXyAU2wO nlI4hAP1y5m3rjZW0Y+g5QIHFg0t9OfZfGBsLZJCrxLJFkjezlZey6L7fCad yMp+F8dlkO7+VgWhleNBKcVUhuWQNHDou9XqSmGoAH4apsnzuHEiplR5YorY oai5HxNX9i/BB62EP6gXai0t5D31dMLR2KiPFtppNOFNdpDWF1Ag+Nhunbii eTVQlySazBh3CNNJ3kCA1Um1o5vxFehgBIsjsbutrh+J3pFrdqL3iMQrxrFD uWubkE9a0FVYhWofbp6lMZcT/MGnH/SyHJ5zrPC0SQ6+f5cOBlfyRB635huJ MLBt6kvXpGmfiZbYDDw6C8WUg/9xcAp7BQnwowT3Twwdw6a/6ptj+rAuhsGK nY1cJi2l0yOojgAoQhMPZXNqAWueiv8cYlP7kjBu350z2gFjqNZHdwrqJg77 9QWM0aS6lsAvmmFsEmF3vNL4pdA+4m4ozXcQ7kSgX4egpSvwptWH+U1EImxr Q6XSLZGiQ85V1+7zVxDKATasY/XJSfj7ifqBQqU9u8NtcFKyXii/z+NIWUt5 NyG9E8q2jM9gxXOs3kCQY5qC+TRqgIM3fwI0kV3MbFxcxOTWjs3EBa5Wz+q6 gTeuTNdsnGOIKiGGh0giwK3tSLBrSyxk/SZIwMwQWHnwkxyyJxL0wuhS2/+0 99zIGzqLS03Ttvj5QP1+cFNdvNMY5ZC314nM1qAFO0dFDRvZdzd2Ax53z6H/ P4Q2BzZuw1fS+C0/tT9/9pJgwbVAfcjNJq6wYDgnnjQ1Gq83Qtf5fGlYLWqf szr0zpGlqW35DKiRmshtBa4WZuRbtBN/5idOuZXCIGTXeySjigJPbXO+viys xQTWcQaME5SyWIDBXsCjdEt87GMNRpv0FOEvPcN3pxuHk5VLzR/TVIovb8bo LiYMSLH3qFztKsGxb4SK0c5K5j3eWlgqLymeMb6w/GUVeochV3kPRmoEhUN6 D9oOeJDAPvq/Yx+xUKHBO2x5b6fdAMvFDFApjmfnZFBfYPei+UhhXv9eJsdZ yZfMkx9eSAHWNrYoiK22qYPbQc2EWRM3rVOiuyBWKLsKvbi89TAhsFu7sSbC kdV88GhFIHbv7Wlcq7kKVzEw0+mRlj102xeWJrTmuimkhh/+arh4LS8/0Tm1 Zb0jQSsPnl/hot1ks3ki0dai66jpbbQ7++juWePZGSEU4WGjpBdQ2qolF6Cw o8SSf0MEQAFLiLKlNR0+sUveMMJLGFtU0Rn6oj2XWXB+5xmR6CW1K5X8l1nC XekDUXhY+MceHVmdU3Hhj2cA9WDvyldQOKAUzIE2g1H0HAYb46RcOnIZum2F S//jmJlxs5doKg7DuVfQC/OZd34AfjPkC437jCx81E1doPJAzqo+M5elWOD6 l2Md7iOupgBZlnTjHSENyI0o5IngQzyiU1+ydjTqmh3cCbhqNDvvh7UT8pc9 9PkRnSXWz9vUrgGQBGmqU1YnoKr6qKRkvE7zPtwMcXLqiAMr6FqTv2pBnreV 7N+fS0R5QXUSPiqJXS40fUbrPv9fwF+98hJDwpZ6RW78pzPILANEpzFy79iX YnMLGt9aw6dzoDGFKewqAH895PXVu9kHm8O6DKcgKBk7TBPRE50nfwthWcKz 496kf+UKOd7RBUrLM9xTiNgESMmVYZf4fckYCYHmU+MS+7A8p7GhYiTRQNZD mzD5VnpfZu1Sn8/li306LV5ync3mOfjMXA30+F0FuCAzigDudU3WJlSqFBTB A07I43AzxIg/yTuApxLIim9MVAd4Q89nZDVyYOycLvy9fDA0FAePdA3ee3er LWb3fHNXGZowGeThRawNSSFp/++KyvPMZsaIixQpY4JD4KWKOO0pLLieZqaw J6r3jp98yBn4gpSvY4To0Mm2a35mX+2b6jgMqqFGk2a+Lh9j4+SdE2JKJDPT vC42SYPEyErh2i291yrnwoTXrPzgWD9KsGc+aS6nsNliweGntpVE2KbVVH81 LxzJf2v5W0ive+NikmVqnEuQ1YrbniA9bq/XWSa21nA/TwxBy8QPal6+54RD Gncn6+U6yyZZt4PPWHkZWvGrYcFKJZjbRr+FXlfgmaQoN/JXZ0ki2tftsieW m6irlvomIEkFQSw9VyZ4LdZeil8LIuvUhD6kdrXiznFtHXkWCKG70QsF7d2d luK4DvB1/HJzrfO4RrrOhyHOk4uAZbF7iU0+pO/bOuWTjo2AsmNqtR3OPdsn 8vT6H4gDjz4kgYdoUIStWH9ulNDyi4VQXT7ePI2q2EkXs4BiZJ2hoaJOxLaG Jpr6k+dcSSgptUE5wbUMd7Wf8hR+fIrYSWspFXKXg4q0m7epK/ughIYzlPG+ WtWx5pVN5RNfBRmYJEoVsijy+uNU7UowqK6HIRCUZFWkKbAcfPM0D3M477kH Ki08OW7nrg3CRzU6t+z3bgZ41urI9PuFNKJAMbRceBvTuRg3ojUdptxLPDkW QF5J6o8frEwVKIGcAcdesKc9svdZtm5KZqmxz2rGZrxp+MP8ZzaaNjdUOckp IO0a2WXKgh3lDSlwkFjzZT2aw+eXAMZbDudDs89oKCzUCrsc46KZEd5S88+b X0QGgb+nD3c9h/lWTWo8w9pWHqN3TXGgf5XMA3n+SSRVNWi1CoHiDcm9Gto4 qGw5vda21cAiAVG7VVkgLa36AhR4S5gEoPXscQywiDrUxpZbnxbo736aLm7Q m6LvemrR3NCwI9iwG24MyOc2k45DPlZrjU4jevkiy3vl22OhEAfa0Kc5T3SZ 0LFf9cNvQ2XFZVnwOm+ID8ifwdScNUY06KtElFh6dQg1+e7mxsa6eRHM+Z7U ObNYzlqxELqW0sSmwKClHOUAvOQf68xzYO25rC5g0OMqi/PYVVKE+QCeS0CZ 6RRXyVrI1T27+dNPblPs17qmQea/YrCj59yJU+ekY2PNLX0Wey4QBNIazlfJ 9yAAJCsrQUlRdFXf1fw7s1SeFA+OYCPg+kAZkf6jp3jAuyPakkbrCE2a8D7p oDCGN2dBIgHh/lKGUHEHdqfOcfyI/NtsOU19axKDwNRZBJaoRlGEdBh4lA+k cS3uXs3ger+IpddPaiwN4NW0c04lU8t2J9pWSZNyXAEtYs3XCUmzQGHJqMdG 6IukdayDMCKR/Ll/Odl8P+2nBKWC4b1JZLOr+yVHkt8GS7v3QiaNzq/WnNSx Db1VAHCoXusqbAYPeD0RU8Gc4QV5bYudDcUmwN3zpsVo5qat3OPoazdq+NyK ydnsV0sT+dt7HNBPDhcS0jCi89ZKOho2EjOPmLxfSNtCe24a92R7Fbl8D5/u VWYL+mcNhvpPcdpTpoh5XpFIOQNa5n09mO3qXi6Y2mR+3ACM4udxXioT5VRj ytXbujlVsxuPPtwoP8P1mXRVb72K7a3iI8eCngt9j7Da0v6aRoaoSAJT94Nl vSLkCSb8SYgn8NZT3k+igpUx6n2kYE2cB/gn8FUcqlqIupIPvB78akYY7suK rsg+vRt/9qsc0gTJfqtzY7IDocyhzeaC10VXtlidzuNdb7vs9uyBSZHn6ysA 89MOl/kUz7m419ybhbq3+9ZsOpr4fgLrW9tNG751n4x+pQnk1vNHG+NjL8Jm 0GYTy6m4d3wan591J+EmvdPIGokvWtO2SlvKYBH0Sr0EjKDHquzWp4va2XE1 5EEOYUfu7LiMeVyaKFRAazrwZhT2YOkAACHNmMWq8mgScKSWoCxRtey5NEZt PGY1BjFr27R0iNdHMAFl+P5H8E8gfLGd/dGrxE/OovZB2ZMMmH9c91OHvmTQ npbuYtctUENU4C293kGXfaLseqKx6p7WZGe1Lo9szsqDnMy7PJrFXIKnYJpy rWSIHa30kxYqPhlE7O/u7ONfg0HSPlYQAGpPsT1OZHyaNiCp/+52aS7GeuFH DZnQ9sQA966f4/fsOtlpsnMRnVeRhkj9VrMMz8+743lYyTyu6MMyzQvgN0eK RUK8Wkr0UKDjPd0vWf5qDI3WjanDrKoZqifsImU7+l0xiUsIGWx1g9rbtbt3 l8uQCjTCvTOkfpjUkDRpzxxQlkDjqcF5+qDSyI6rGWbKpugrV/ftg/u+ghaA vPoLGp+LyNuDZJbSDO3RjLYR8rpOWHdDJTxlltu7wL21lHO9ntH3AuiyHO4q OihXGqmz2gQKy9+dyEp2maHk6jmkSbvFVw0VdgdeqtzdpLn6MYIHGk9304hg eqXdYUPy2xthpqT3lluhumDp/RYnOzF2pPTBEvp/fcuvowf3ezJvkBztEO8a cGilkFKJYHikrTSo8k9NqXttlUlxkS2O7/x7yXGSyDYXUhxAMybq+/E+kF/7 phuQs/KARjqxp8xwA05ako3sdqVijhwKJa1upWXE+rG6UMgdE7pyfWoX2fD0 jP2qSDErLYzJ7FzkUlm53TJm5yXJEppFVpUDmNyEck3FkYVvgXy6l6v84ZNd tkG32EzL90WB5aY3ayb1VUznPnr/FUsIksnYlE+ndvHML/ynqfOxqo/ejHAn dtGxfg/63WjENdZuDzpx/n595nxb020wOUf/Um5rJEC7HvPeae1xPLGdMcEJ 41TRnn9UXTSxiNZorIIX7EQnnOzXniJJKWK4Q2+XW+VfLcoih3Ejiy1sTuSY 7enJoWxmuAj5oSBwvZYwa7SP+MequuRCOSo3RBjvE/IhAWECx9CD8abBkdkI Ps7t4v9a4dyteSui2MY2wDbQmwjguxL94ttvf9wJ3mvQvoQTkPWQmn3Vnyg2 pRaUX1ri5ehvlgwCyNXH9lA2S4Pe8POJp2UzMgSd40awxve4uGkiRd8s4yTp YhXsNcJJrG+0rzwdX9YwuIq73wnjJL0cFdFH2DOElfEEomifBtsGeXHJP2p0 xPiilWlmPnFkIDl40X7vWZKeOBTdq1KZbSmEUJkn9NMaT56bmI3suRsVLZIb cEriF0QFQHs4lHFZhgPB9ZdYZzwmitAmJ5SIO84YiHd2Wvye776QJJjYBtNl oVOVOQ4yxBm7fBP1dl/sqQrVa2of94fmb57aBeMt4SqUTYzzWpkO06QFkwfr Z53blRicyPJtLLBJgwuwG9SH2JXJ6wamyRo1GIP+/zL2iCI+Mf72lLEwBus7 6uxRzKkMT2ADtajl+PtA3+DSjs8KP0vSU2hwo3/7G9Sua6AZ8GHnQ1L0qVHu eL5BIs/hhafKWfSNO/Mpjmp3UefYbpHIMDY9RY+/IxYUFdZGk/kHWcvCh6A5 FCycqE7gMBAvDI7wCtRH3Eyx/DbY8MaNmpLHF/vdPd24XtDiVOlequWPmYfb oFtiv0wUqO1p4dxuk70ewjfti2uHCqpiJl9bri+xOiRjQZIS4jRFcPFmy1Qv fAaL6p5SODn3T/3sQ3hRGtEMzUnHC60Kwmv3pzy4ULTUnoAYLCoQGqhYF0S6 ilMBFp6F2i9BY4JMYoeoTrKQPLX0SGQDbsM0wIW5/e7zHnHSceOIHsQ3EWER 7RNWXADJvMYLhNB6oasbnEgHQZYy0H3tqn0Hj3NBDZjJYci6wnjc94A3Rcl8 fCOuQsx1bzfUmo8xGLs0I4OwPOcT5mD9D6VjoBQEwrxrvG4KwICZ/28w7+9E vnYtRzmrIOOAeqLuZvH/CC388lOGZ4E4+syu0YXcBAu7GSj6jUopGXg8vzNE C3jCUm7F1B6dfcvUj6iwxqPiQ3ogC4DPdZQ9DbnPn0RIe0rKbb+IIqSLrP0q lyV9KlwtwJ0KFhKyTPrdrUOCtmjZwp9xGRbJs/PA/AMK7rmtRQqoLcosVQa+ WCPsPt7nIcpZK4v0q3abSfu3bwd4P1XzfsBPY34t4sKVjr57Zq4Xo2Y9h6/S rWe8Xsrr45rLvq5EzNSIQhoDONKor6Mgl/FxxPfgskMeHFJGhZopw8l8aUil 6l/epytJ3QWsJNou3AtpXOv79LNyyTJyfxp9FcLs8DXIx/YgYXtfeM+2Tt2o Dy9oYqf8waQSHdzLBhnwTPFwIOWMY2uTLtFCCBvA7sl97sj0iAR2sprPnJc7 jvmgG/HozbLS+s4y8/1GG7KrdSz3KXeNDKOHJafMEPfMEz9LMSEO1XJAYa/4 tpl8YkJxc9WCni1SM5KrCCKAgPG+1DFyXOydk7JPLpq9+R5egJCBiU/Keftl c+6mCMX9Q242Yfbql4VgowxOzKPh/tDcSjkGGRpW8HPRWVSR72oeX52aMEoj 8zoOg/y/+aLhbLqtAC4KrtblYLgh24ZQMhGn8OtYnEn5ynzdNuCj4PFFxWz4 IvWfXfM9NuHCL5KWap2Ohz+jguy5Fa/a/Y7bQlsxkd+Fmp2xFALLlu6QqMDm n7bQfuxJcTi49M0Wx+1isvtW5BFXmSg7VJ63oD1yBOGZYSgVxhSeXReQ0ckY XK+ELo8f9gDFy02LgwV3FC+deaQL4HrRSqJmvaaLNIPO2G7KgMme0HAFx86s s67zK4wSrdN0QuP/yt7t1/nkpjW+BducfXe6rDJg8hivYkySWsh43ooR14fT OObxbiB6Ij3vxCODDjL/phIxAGVAshbYdAHi1ZKjlxSyTSTEh13Ayjho1JfV pYf46+7eEENXwhJivNiNcfTyxqXNTuj/ROC/qb/q9sUI+iDi0+i2h04UF7/c pPwdXBMfhObPDUaS5Is3AtDZNHVh8kQTzrl/HgzqBszD7N+9p6+4KKzwWq6v 06oXMD32J5nYKhvFiMmAPUbd0Igj2hFR2tW49BFlxdOCPe1eFbOeEkpagPUi wvjFuk/wrTASnBc1pYwDiS9rJA2SbvbWR68LhLWWLCV5GsY4PjBKp5WUofbT lg881+Ng7mmBREAk5xrblMrTcVK6BRE71yPfhKQWw4TqBQEl0zjotKBhlyTo XqCb04CGgzjD985ale4k2NvTwgKyNdYUFKqXt0+SJGY3VVDsKa3fwoFumIea 4kQm2yS8uy4wzm8vKaBgonmkRui1EQpcC4in5FO9eAiGwRCabE2p7GVY1x/1 YbMRdaG61dlcxz79pwkPnDv7ikPgJn2ltbvZmvjMCT/9J0tWspaDfZxwHrNk 6wjZApwc5zyPf2v3fbWJ+L8YcFsy5/jFgTaYZmM2lCgqwDUH846m8sfoAH2J QaTMvAT1W9zj8HBRo4WpPkIKAokFoeKssA3+hgAJtXgp47YK5M+Q5HNpYo2Q Z2EGLiat1cLohk8bvBXTz7Y+8VE4831ylC/Jgob5zmNLHUwAyS+BKn1Z+M8q lVBDUYEvgh3nxP6Eh9CbmT6L1buQikYeAGHALXdtJDL24ddtu+B9U0kI88NT euDrlwQzbYUIL5B5ZI2KEE3ODLsCY1a3LIVqUrxYkRXlBxtHTi85QvJ3Cf7u 2YwFTUdMGk02T3BEmWkJYNkm14gXW9f4hOm4xV/G12vtQ3TpSFiEaitDteJI LeUNxwAmHu0+9AgxaSQjG36N1hcgL0IMIZKeA32qm9jleTHVZTWFBPjtlWYO Ta1F5oZ+hcPhbB1IW+qEaIERsVlGEBBG5+dEdqL6ZdNd7tNmvhel3XbzPfkM qbW5lz9Fb1anzxpFGz/wMLvq2Zf2Ei5Vv7Ze/dOaZnP6x06+opXr26XYSjMj DnSs6YsYkwQACzMogJa/UDKILEQ2JNsuR3/KwfPsoVedsxkrUjVY1r1y/FfM r5eExmyak3XopfI50cXlYkr0fdKNKE7h6TfgWF+XYsTC/DDGT6LNzTBE2eHw znpHE8HrT8/rcqf+FtXzXKCVY6aWl0D74T5+yek2ByZEOtI2DGTlW8U5DZ9G cj0+dzLG5p7goKCuhKRcnFlH2S9O/wqMNYzgrAoZhK3jeGuxlmaDw/xtXbrE Q48jt2hrp7UO4jdfXYgDj/OFFg0l1ZGzYWMATpwK/XRjj+G6uQiuPNsepBMK BThIwq5hNfE1rcqtbKufqb8HBSW6hGHVaTjX9hhWNVaim6WqzOPiSPUMCFXG Uf9jCi8KSgTtPGESYh2XuthVJcNz2g6xopuKje28ovywPAi2RZ338FQuN8xh xwR2YB9buIZa99uxkYSLKTVIm1q+YM60BNa6w2c2RMm+9tg2puBB6qDq2ed1 dk6QaGLL8J/kdQDQLdxSOzlXCoMLlr/cxuu8SIx+c8OikfyyqhplrCRUoS2U d/jOfbSx7AJonbZGR4hfX0nnyffXliV8tmDs8zpwIHACBWyqXP/DZrvqFH02 pedxgHvvpGoXBw/dTpUPB6ef9TkNkLGoTCiW+GKZIRlJauxbbgEWDn+wBEXy mz6eNQUlnKbnkRDNl3LrlS0AoDQtYZis/hkIuRfTlGckj8ohCW4qZAalGYbk 4EB8FQ+YELWgIFrurcQSve39hB2TLhG42TOrYKI2Kuvop+G0A6Vugq2Dc/CP GYFbShZJg0mw0WrRkLtP9NGNNAYmTIUMmAOWDeeA3upRuZE7pkWwWTCyKr7D Q0F6c6TdJStLZDjuJpk7WQBya8NtaOSpalag8FzGWKdL2rp8w9zxhtNqZuAz kO8bujDcLcaZMeIHkxUl53XIEFlefmnFODxwWk3btoX924aS6geKzZAtY8fG HwoTOzPHF+VDSF1ur5G60dV1QFCypPYARFaLhWl+YkaL/+/4yIa7BGm7wNMf U+RQpM18hBVp7KUbNklJPDQ6NYn8Ula8pyoSrBOw+OOkNt6yh5XLUiVp+eoU 9bZCdgjFERCqo/hkw8uQbGhSUqOmA8+FDFpZDKBdy0bmzIGGq7ZMJqA6nhWz rnPy3BaOEQnGPE5sLbCCDYgFQyhlYU/rKfYv2h/Vo+LoKSQWuXGNqJfX1ovo pPqMRin6/b1SESCWDfoHi0uSWj195xirRAZ1RmbgvEmm5a+JXatnEy5z/Nhb YESUNVNW79mIC2FiViQxHQxnOvOGo7pE2SWjQHo+X5rxLkCVo6IE1L2q3KOW D1jRt1n0JcM19JLTztbczhACmZp9xooZ3gNz29vEp+uuoz7CojheJtGTGRmS bOvSN+1DuR9J0e98yFO+e+CaWpuZ7Vygupb1bVksF0LVcLpFzD0YhiaUrz57 pQit/lvCNRwXmPbGIpZKZQZ4zOhzH4hVPE/hT6TZ/PzrFQHSgbVbS60wHwEk DqG3CUaBOQgtd7pz1MqkIVGbhhHc8bg5Ux/y7u3ACPbQL+5cmhWXKTeYN8xY 0vk4f8KcE110zDcFMZk8VHMDDChGNeSHZPE6C7jB447cLuNT9IYgetZfMzr7 b+cq1nO31TG7WvLyIxi0ezz+hDxnuKtPnwIlRn1z6llFQ14I6H/fXyY57998 8/RRG624kaGulbN3gIRN5bO0pRL5yNNbkjduZUGj/AiA3x3iD2bGbe/gjKIQ C+Q/KtM4vBAWuQASoEjcWGNsvDoxK0mI0UlRo+ov8qleshH1KHCzcURwfYLo MstgXQe4mELfIzaUFxLwpDz/RzCIdMFFlEJYpKVszGDQ+76XkgfsVDVJRTRk QQEiruxuMV6Pm6/5IVa9+JgqwFL+I0oGpyhmXP40EN+6pSSAoXPYyh7uonDQ t3mMoP/p7Vu9RKAk2VBF/FBlXNty9gC0eAkczG9ymZk/RNjd6t0TyHeQC1x0 hcLKY1Ve3e0ON+AYKwjWlC+9cyLfMs6ipKrxCVnAI1DGxw5jpP6DPdlOkSgm DN3vho6hBEZn78inLOUBtmHfK8Mzvop0kcuSSqmx/p3uKVaZ9w7qQ7mkTwZc jd8QjF+HkIxhkPgWVu/Ptw+mFp14PnrHKIo0ecRB1Rw8W3JsUTP3ierwV9x8 vBV1OvUziicMzlyGaZYJzF/2MF0hFca/wQ4HjTXqeXygPqQ1ZllFAj7Oe84/ p4BYV7GriH5pZXC5OfLUTHLjuWj6DDU0E5uFCJ0r7ZcsoleuNJg3ul879EIw ziCJzAsMB01th7j3UbSltnVxcX59E2Dn2+Q1flyeZ8mbZFeBI94xMBDFRCKw 0YVOzRDyHgwBW3x38jfGiqzykS5+9oeL/GmmDRKevmZC5wqVUtx1qgbCcHY4 7gcGE3sBuax1GKIlREkTYurWvvIcTYef2ccPx75l8EYYKnpqsR+AZIB14nWM ttmJfvjAU6z/kyOiU0pOxwdO8/oCjTgF+k1+sdBjwm8AiXCuJgPsMEM9PaNW NneLGP2p1JRDKUn4oGzTmh7j6jz07URHbvZQ+LnwHJQEFnuzSdVpml6S1pe7 XgPDQvRX4SIhjQIoomRdBguxzdVrYtyIp0I69v34kvaZBKboRq8UkdcgCBrL 2KxvGHhtgU0MYq5/3dnyyI5ndhjROYCmlRuJ6qGE1r1n1Lu0xagexmzvvqcZ yAo2pHckLBfON4wuBzRj5iHY6mQ6nwYCrBq/VSGzFQu5atM6XqsZN0T/XEV8 1FU7ERwpnBIjEF238cvnXZl2JmHJwxV9bx1ghf4kLEF7dERiimbRKKoiZppN OGMvkc6+cnk60hDoJ5TvfphT0AEMR8K9EvY6OgSgTVPZuEyjoWwQRCIMKCfs msejCsS6rihRaJqwfoRhSoAIlBSHEbqxX0G6s0kxenZg6f3uQJFu0Mk3E44u Uwq2/i1p99Lk5CimbR5mF0MCkm3Gyu/0q9o91P5BLBvKxROjrfRPgo9+LHre FJ3u/2zGxXM33nBgFDUUk/+QLRBM3tKmfDA5Zgo0x309WSHQG1MRI3rsT6M9 jlmjhdG2lcd6NJQYO5CHxynHK5YGrQfDQdqKR91GsWBlqHMUFoZ23ui017yJ O3znMKXrPv4wpf5tYoVgIdAqyVqMC69h1GaI+XWANf5ZzPskAtTKQcyr8CWj VPgrbEx34SjeBC5m+ziRFfbFWs12ihJX9RxbHoBRvihg57GnOnMUAUAYfjGk IiTpVze+vtJTzRZji2+w26S0zH653mSRr08z/p79kM+A/cRcix1Q6DbQHFti N2Ox+6gGFD2tTqzdNe1EjQhPVuadAV5wCmsMX0JR8NERp6U9CPLjrkW9AbCZ BxluktWL33tm3pDcocH7VZbroLtATC67sSorq6cgIKapmOFJnc3/tjn+r9Ep Ofx0TMQpt91Cvnj6EmmMj7NcxkXCzRM4Qeh25u8GH+ZSyILk+qxB3UHP+avS 4WrLLkUN3N8dWIDxBvQg4k9RxQ4jaD+CZcMoFkcooP+fS7GplpRTNPXegU4O voDbIEzstjaMH1zFdh/DD4db/LhscQu7DJ/31Afxq505tPvhFVldTNH3PB6S dFgPghhPrMpSw7SaHxFEsso9MCshNbkQ4IbR0SRomo+HFK0SRdToz0+yIY5t qeo9cX0pjI34vGFOGXMmvz/9j1+IxEv5dokUslVj/ECxgTvMnv57fxXdT7C8 6FuHOQu4HhTqaMZ5fwYqK+wdp0ydCFE1j+7opghnipbuBB94g7LAawEt3zfH JYFTIa058uTng8shG/iFMJsoBEuEVyf2cMKBcZH7N2gIbjHITBmeOgZBOUFg eepWuGFlqbBPWipeGNYUMhD9pTpcZaN7WoklVlderTRjTtXjjBD1tbz6b6fW AbJRGblwaUUzU087lOzlBuNARbkxkd8zAFBLlW5rD7l1SnOf1G9IBAq+58Us 1uI0Oa1ifwXwZ6fssm2FJBBBxIxL8cNVRlW2TGf4yFrpUPRf7VNLSdlajiGh /sVG7BP0srMCZWFXYhFbRVYLnrnCspGhg7iHDev/+/nrLSAmJPfLZ/80SkHA +CYvhxOpbGg3/uDtmhM3gRwBEsSvoG/Dp7B5Fi2R6NpTPYwgF5ZQq+OMrZqk ry84oC7irqp0j74Hrh9+og4nVj7TvUTFXUDGI4jnHdKq2Srbc/Ae6b5I7eiF M27+NFxaYElF+XZXlZAP5E5H5obrt7mOMbAjrgzUWPDbrB1MjWrTcNesOWXw OE0s0fmOLa1gK8PZkLauX9Tzhza4klkiq+yK+nYODRXY37J10oqclfQEGh18 DPfF5c3brok2MVa9n0LjNJ5EYx9xtCOTqGOdB6I9b8jpIfV1lK2IyXUzf4Ob pgmcnjEM58/O3w3HirR0xBlEyvZMlJr9Zvu0WzBkmsYLj/aZDBK3OT2dAUBl 7re08JZxoN2bnBqGgf6CkYBOjbhGkgUwHZeI15EHuAlYg3GqpO7oUqvIKUB1 y22So5epdri7ieqcOxaIqBlbGPDU/z0FDjPTx211KeLGJZVtcExBd0EqLG1U PIgVsHX92NqBGXwDL8Ij+/MVMT5sc/2lbKcOkBWsxG01z2w+MpJvBPrxUSOa xBPSL7ZI78XW0kxsvrqPanqDXFemPFXzq2lEY7OQWiiwZ+XaVVp92zvxt18n AC+VgeyGr4RIsVGCFNYCXxGnH+6exsBdJ2OrceMjUKGNWFkQ6M3+ciyQtcI1 HS94ptn8VAoameN3LG1bIznxEh0q6D7AENZXTQH5fwyrtHxv4fDlry0WdUMP idohuOrmSNhbwzrMAmcxN95JulducceDUpXXG4F9yHkxB+SaaQRduOgAvHEn 5ZRS8XLKchNHicX6+mYrr8QH85r+QHTg1j67MyVu8bX3Ih1Pl6HvCdWqfkPV aY/6IxKW77Nx1r7r6yMuKLAvcGFAbD1MYwp6mOGrziQpH1SDx2yQHUj+cIKA F5qI56mS7VfQxusXoDE9U+vXXr1EKVIWKylMPnP8rBlvRuOPws5iIWOLrmwp 4A4PSXUgECqCJmK4FSoQPfuhxrorMwE09L3bkcUlxpwlf+RPETjm0k6qCvuc L8beAGHB8cULpONIQxw0eVRXgzv+NZTU8smzCO6h7IczmSIvCGmp33c6hXkU Gs5tYvShRxC/+INau7IGk5TQPgZpdl4PdLA+23bvoXf4/a7HWjB0hUDbl/0k GdxwnOIoZ6GIqAy67aTjVzeLkMlLahiX9f2f/5OKLeigEvbkVNnRew0IuMuz StxvdcJIuXiXWwHa1zdIuXOkElKXTVaXeSa5DYMjfGTBRRIw28B87+Z32b8h Z4SEViIu4mqvHh2EG8H5OoeedkJh0e7CG/JlynEZ0aiKoZkN9b3Zw/LRopbT lBr0FMtM7tXUBixZOcUruz2dti3Ngwairi9v9MLnzrEoYalk5w6nsD1nNJVS hSXbFy6FpI6ukPNQ4bLzx7r5SJRk/SGOHAP/KaLC+sHLZrwVVTc+BSMDWgc+ 8HID5bMAc4jfsdQ6hoERHGdl9pzu1dKtctbNLR4qaDeOWCgZIEzlE1ASVJ78 XhFalYrfxs6KYTLXDwT9Q2Qyz64+XMLvGVtOzlitzc5hCmL5xbRDi7XGrwDr v2kA+EUODFLmUIAE77RXXW5S+bd8k9TUAR4OPLmx5GjpUY/8rYS83VfecoNn yaOemGczzftPpnTdcaHvMwUfPG8irL1tUGE1D4CJiyKB/WbqjHbpzGoib2Sh oviTmEKtksTx75s6qQst71C1EOwRb04JdZZhozNmZCPj+SK1sVsGws5v295v 986sdcnfZSe8KhDceZj5KYvAXVnQCyqi3iksk6ukT/5Fb7p/mPpIZfUoSilV p03xb/B0AcNYc6LxXkzCiQqP53i8oVUiBQqWee5/1ChtyFkh4Xa+hHuliKvk 5G89/JeKQ6mX75K/9iC6xD+DRHOrLe4PNWUtjSeQx1A4tn7VAu86fXp+fTHJ QDt5PYIFvbHlq6ScM4+m8T0c/JkDOiFBjIYIAnIYBtFz1GBPBZfGv07YGCSN ga/fsGfSqyzwRl/WcChlHG4AuQSe3/kJ0fHEAihuml4Cg07K2MxvQ94tCSgs bUPgAnL7hM5bOcok2xRfUw8njW46gVF4Ac2xDGJmzv1VoIjiY3sNMlBSXYXd Kp4rCbllZpwGDJ2srrzsFbmsS1juCY6+W7FEjE3qd3K8mwMLJlk4DGkK/6t1 6L6YIXh5MMtKsiQF/ArGjUEvyFmvq2cim0dX/uwth7Iz1YWFVZkOszaa1ujZ +4hGgibaCcc4IC9u9mTLBl/I8zwc4S7Rmrcw0fEkOv7mTQQ7LnD3QMYJ67rY WDMki/vLoa9hfDr7QgBUkGjToK/q9jJzMpLbfrtXW2khZxocBxPeLgZvvyYF 6soAKepNnml6ICCWD3259ytPHKU3nuUvwgbwJa81295My/a8osDZnRQAHsef rGhK4br8wZTezoSa0YVCKDR1BGNnb7FR57Y0w/j8Ajja45PJUiW9KswUmW9d 55q2N/VjWXDiigvqMj6b7DDQ3feIn8OsaMrrXe4zaWkSmqiMtryv4FgJjecx WYwJoEuLcWgTSycYWJrf+wQ6pt5AWvQrucST396zjGhB8Nmr6TDjzaMQgh5/ q4i5WcAEDUngVrFlcYZUL3NZWPsNEB4OsabKbQVXFlDwf83ji5KrTffj8Nn9 NFKmA3AwUlfMU4hEG+eWoRUMyB8JMT7ES9h95igz8nVo04hR+iyy4FQ+oyZw p55Gik48JjeZEGYHzqyeCETI8zoRAHO2f0RK8lwU3quzYdQtLrPj3cgzeyCC NzCbHtLZt9U7WrQiSL8ane7OROnfmt+wFIdRSzyr90JKp3hZoC2zq14GpIUf 6zI7WmC/2mvP66SqZX3ksvoaCZjgoz6hflZidCTTofLHtMHVUfrjkfRxJiA5 8houB3s+CWn8/SI2X1gvcIBzcSHwVrXEh53561BqxwC4gDzhw17JcTsI2r2m aZGMG40eFJlo3a7FPooWb4iMvSMpgGUWPrB53jSS1KcW8I0nPT4gJm19cBpn lMuxtZSUkeC35deHhh6XaSRQjxecweQZbD4Wb/t65QIjZcTRTCNoyKOikzkN XrnDA/G5cegPHHTUzehoc8kOXqajwG0rpPzKTB3W+4F2uaiGjUu/SrmIy5On F2brPvhGz2Kb1qNbZ0Uy/1ItSzjIFUL3hZJhffSERa/PBma0x2UQdVt1eA5D r9vfXg4f0x6N7JERHTr+dVO09g0OGC/TozlzvM2iynWxPb9g4wnX3E5bAICd 8DVq9whiKSJK0vv50a+pRG4GbuFpYlnkLu/Ip9ysoY/A4GkCttlsKC5o1D65 vXxZ7BLE5Es+BTZlz1hPzuzRmuvuY9KoUaTFeCDWn8OmBhKkt/pFKC9gZE9n GAebPPNQ2xHXzR/CwgJoYZFUtXai0cFQRi0eIWtQiqlNWARGIANaQLWOSGja TUGYluvYxE6yevE7v7SobTZXopPk5rHbmKWMTOd9vCtYTQU4Frlm/0/qwJGg 9FbLSMrdSwL1fkZpE9YOcs6rlLScC4pX6jOJ1G4DGIckKEZC8w2MQ2uMqro1 BCDK6G4Bjvusq/P407RWTdV35PeeZQMUQntrGkqvOQJgOj5oRvVhNtIVx2HN W7A/U6cP8B/FR5GNdGSR/TJFcsPSVBoTLrQlyCWgUAsx7YiDfInh2xvnL5rW THACP5QcALj1p2LXOCQ3jYk70ou6aA3sPMM6SvsjeNU6vPC+X11Mzxkctd0u gUht1gkf2KetdiKUi0xtqorEer01nAubLbuVAKGxOIZdbvwX0InnfJKkV5Dv BkIKkU63urd0X3VQqRu/l57UUv6S0MBT4kwkygZ3mya/5xWo4eFK+QSJVO3j Vqv3M7cIFBSlTeytFq2gR9ZSZkCSfLoqbhOWi2J3I71mUuyL187jsW2HIQmz ZstZ/o7kGaT6vwNBiBDq2k8j7SQaD9aH7s4t2/0BeRlY+Ww7kx+sf9cmfszd mnRZS7okeTXqqUj1dtogD4Lv81ILFMNBfkhNVaOFuMKoBfN1k0HIIJb/dZKy u4TZJOGL6BokG6iAKBwCIRNfcNpCasWftXLWCFzkXOwZyEMY+mnwg84JO4wJ e782SdO2LEDoYjNirYLTKcodVVSIQfttUDNUV2IpAoYTz/JjKKQVkWdcarAt Xkfr2htftNO8F61Twu7z7kFtbUjSkdafKyZRHVbcsNW5PIHzfXuXdibJALR0 bGN9k5GT2fqeFAWvEDvzjdl4SSJftJF5uF2/bixsJ6OiBmGNA5ncuPKol03T uLeMg5l/Qb4kjaRkWKM4DJSy4E3byQeWkYs7TtGvNVn/SXmaRwJAsLWvlNPL KPhOS1FydwcKosupX34y/c+/d0hplJApFgKRnd+ewaDymwWEOU7m0ObCSBRY ijrcAGnS6fR6CK+txZjQqDr67e4sYFNxPCVHsDejrBEG8DjhFdGOX7BlYh9z exWsUwkT6sRayOY1heOmlB3E4OMfNB9+j/WBppLhx5rlHAGqCLU/oFiJsvdb f2jjh59m9hWiYIScGdYQm4JiYaBW2zVE+Uky3rYefIvhMCvQswN7RLfPa617 IgydbophWKIEhvGxKBR0ioBHXZhac4mTTlowLWjxnizJ1Ud+N1YYvM7sjr74 wdxbZpDf3UJGGxVYHAOrJvOXVd+hhTTxl3adM90xLBb8okvO3u1gL0/ms0js VPMk8XSYhqOay0jQt1zDoPOJZwKGMcMAMrvJXd6wfhQSvVXUvhQRj5RRYG0S ocYSacBJp+pKWVR0VvwWiI8kU0T0JMWdgXCZJR+0iApV5jYZ7FCdF/f1iC8K sm4ZwXRRe71CHpEvbSFcntUrv3cZfvYFw34vDT8ioMj4gZhCBkw0eAKJBRhT +OeUm6ym4mccvomaKphYyeswR+oXDoYhzhiMXUgYnop5w6K0yu5E5bXzwP3t 2KXBUKYiJkeNpIQcSiavoedLOGyz6qRC3LWx2EANIn83vNOKckH6CC2AJeUH R5uhMDAB04DvdPtunrBmHqjJp0IJFUTKlvpX/xCU7HjB4ATG5Cx02xNd0uEV JAGB4llbPhUN5EGd5bn8imle1Betjo7b3zUU7nHco2Z4v2Q45MS50QhMn4rQ H3Pdbp5QR3u5sc+5LUbvZFRJPdzeWBcoVsqyLU9o3e35p6oYg1L/36pgKtLy UpGGw7tqKPnzlAbUkuOjoyi7SxdyauEOACgnGKjWSfOUrARSAddYV2mVOVUo 2S/YVRf69UWQPVmBDMsNEuNgl4WWAIe8LmjTgZi9cMZFY6Fb98a42+KlRI31 vFq3KUYdjzaCHvr1poHoXBj3DLbvRu/esM6CIShc//6xQHlERwdy2/4uljt5 IcdydEyhyJ0RYk7fkRTLI5hzMrSawS/OZHQFwl3gIKe4q+ZcHadsvEOQ1Kwd cqdNYz6nEwxvQWt4wTz3TPs2Aysb31XT+Z1Nd0VL8DsDqNHoi7bn4AYjCi3L wr7oL/pfSEgvqMRYtwRptx7/AL3LMas3CvBNsGgKeqZ33sfscVWcm8/6e6ts sWxBJ2qEc1ZsQ8rzxLyJtC2wNA3DmPtIGYJHpQhvk7C2YWQs8sIEg3R1aW8k aBXmtJSpBEpAyuznHE+9VuyUM3It8KYfbxdrkY+roQL+Sr1lTRsWVoPkamm1 ONcxOeBH8rSYuGM8gQD7nhwbRfLAwIcHoelOpdRlmbiiUsjnupRbMLfm06SZ k+4iRpvycOvw6OJS1PlHfqzoYkqOfkdp32Y1FaZM7wXWQ7EJvwsAZhW/rqlz Im960S3iPA1Y4IhkeASJU6DqRqBoP2syPg2cD4dXIl/5voYtSkSfjnfKWtIr mqH81AYSa6bZUTjJBF6auYdRK1ouWII8YZ6h1rqNFIx4Hhc9A+gMxj43Otgg IYEVVTzPJRE8AEFfXPeoF3W+4gApDB8EiDu/thCzYFa/E+YOfIpd/lAO3sPS wTKncjX5TAY5xKxhUBJ1sJvtdK7n+1IzP7XvixsjOLPzHdXwoIrwaINtY85+ Q0/YeyY+xxLgNAdf3+MLqqteiKpJWY7Tq6MZZYRD2wabFk3wAobq7WKI4xlA nrj8GV3Hxg/yb+21OW8czERO4KICmc2bxbTuviWy9Iw/518utAb2pDqiZh6X cgZISpuSCGQrodN6ODzYICp/lBwouaL6+M7+CRoJA1RUZfM2WohAJyAIgyFj JsbMbW0Urod2qvwIeYmidjrxJL6x4rPhQfxNEwuP6AzxDapdMPzQ238/aCXa 0CGojNR6IPjRUn/RmGosK8syD/pBK/XpbrRDgb3Je2h7lTIHhtlBd4Gs1I8l Dt37YyE914IcJmngMiwCk3MGLXHoA85DkoL1YyDE6lGuti//hXWTV0n22AZD LdIeg0zWi754kqd3bC/M+EjOV4r06zMkJTlUE7gfFL40RCEJoKYW6YpTn6BL gxBRW0+mp16RbWH0wZ2SGSfhmgKhet6svHFOlSacU3558sflHWf5yuaExTd+ ExVCCJ+F00EOHehpKQxLwh32tAd78koafltnL2F6f2qxeDpgByqovgC6QdFF MQd10de2bMC3l7feRH1wxowDlUBslRbyA7aYiF+xxdx/l7So8IN/0hZijVa7 wKgUQmRYJi1JwGS9/mn/cqS6+eETUAeKS527ePTjYKFm8Dbbrh58yk0Hy23Y UDz7xVpjC84Sy6+Fd2DH19jPtLg4PHOvbYSYCueDXieeAlrUc3yiaKpF4Iby 2Itpff2KWqhCqcGWXTwO/j/75dA86AnUoZwsE75uR5ZsPruJxAz1Obb9+EKB wwjDDKyG2WDOt6rJZ+vEyGS0D0zDOjeQnv7OwwJKubDY8BHt3H8GjTHBwzeT PAQsUlITAsMBf89ZzRdEyMtsRXpUokYfVxh8Isd9qaC/ZpNX4/R3ssA9bM5x Jqo+VNpWmTfDJ3UQ0+rXLKH4sE1kgJSn9x55WpigB95mKdYrfmzmk8zMQuFq nCYeQy5IUXTwnK2MEH3eyNqnxfe563LXPzOd9MeIljXvH4NF6j7kGqesYR7D N+mGQGekdgv/uqYMm1kTup8lBB9gyCQp8tvrR7yZ+ncd0lmpRENBlUTK35ii cjCev4pNQFOf4f+gHGo2iE2vgqoronVj3jXwbIKAADuV54BeB95R163PCO1I 7NaS/W+DFzvyRurXt/qwFxQeQV67fZ2R8dMbXEOXdNCJrqRePu7jBNdbJ4pB jdxAVymJOXK0KD6TEn17eazEi2EIBEWY3609+UTXtrqvWMgklekn/1/wRl4Y aSzPjxKfqrEF+adGf/N8nvuDVxX/tke1xxoSuIdJ/YfP6VvDALmBfQmzOW3u eKTOYH3g/bL/h8VXr6UxBChVE2B/WoeCNyL+BJyxTA7MUiybsJxTTlpwpqj8 9H0hZjcGwvLkAdgdlZzET2fZS401Lg73zB0iSfUhMZgWUhllvfx48BnbRh1r I2eaA4NOePOFelPFBYv8WK9UsPLkvGhgJPwYKNpvhYBHjhNLNAquel8hyDNa FzUX5vlRuz+E/b9ngly4M/R1y0idy2B+k3sFYoN27c+xVV2Nk5XbAJ4Nu6GR Zrmpo0FwVRO4IG82A41nxd6LoE4gSUfPSGIgoU2lnGV79lHM0zhQ+oJ1g0oT AF7CE9MmtbttQ+tUsRaKP8/bVPW//GhUCuFcAZiFzayC9H6PQtjPGm/w/WO9 TkskfRuejmi+UnBWq8wJJzhABLXNpO5k2aS7cs1ZVappRwI8WIBMTptPPrh6 rDG0TuByqFvNdSkpStZnxte1F0P1S923Rott+cIC2sVMV+FOtircVLP21/+R 1mPJmBL6B8wtHc/QfvoFlVnu+mdOnzglWyS056QwiT9DMLY/3SmyUGKs/GDo AgAAAOgA6AAAAABeK8lYdALNILlRGQAAi8H4cwLNIIPGM41EgWfoAgAAAOiA MAZGWusB6dQJSX/pZ+MCzSAUydnJwHw5AYNrPBG+iwzYF9leMyQle5kpU5g3 joy/29hYT9swz+zvdBPEzdwpciMRYRlOotvc0LbzAgEMG1CaT7GynCm+E5Wl kJLEgIpL7n18CmOsGfbx6GI0OO/jb1NZ7pqNwRL38Gl3n9Pkw6vhIED4HHZg mw4WtUTq3M8iZsgzKinBb8LNzIeuvbE0ck0wXzdRn9qyoXTdsqA7d15ZSIYe kotDZUqYUFGpZ1CW4w+LhmhNahXjPJNynYBGIyZwf3ocKY8ljIiT/+R+5HH8 aVBKgpyPYmUUYWpElbZm9Q/+irGwKLqp6rxe3dobsqG0JMqA0uBGxcpnXlFI PIazuvA+yTsjJi0sVXbGxwAmWJRdrckwwic87XQSJicXyogA15pzh8sOMVCQ QuQYA2Ab2Nvj+HQir+1473WG2kStlAiNJfkQFu/Q24K4UUfnDBUUlteO0Aeu tvz7gR+dt/6tmZciwdGqX+Ugpk8pJKYK6TS2fjE0JohBwGiroKnWDQwLCRTl wdeTo9irz+XOI6BZ1jtXT2Jc1jhyi+Ps9ztAIGpuPMOolwciKDBACgyLZjoW NRVe7uKG7/cMQdsgGqZkbIfTLMDjqpnBarFwvB7uPVlykOlUP54WrH8PCU0M x2wcoL2ZmAyGts3B99eb4RKxrPTO7dKnxMhEKBcQUGhXNRHOuqmZY6kdCtio 1a9SPFiw4LWNa7w8qrA7X1B4U0gqTWY22XoWjlk1MwYMXqS+77exvp7seYoZ en1r06ribGD8dExP+KEMrMDmAvHfkRP8/YjaLGtxhYrQbWftrIStnr/2mZ3Y u2BwN23oSNHKHi37WC8ICbwWFKS8vOZ0UaJBHKWfnOM6VVm0eCcgwDjEZc1e KlmX4LukpSDy+M7+i/Oqxd915sgIFjdYITWQPTpRDiR2x+179vHm/yB4GweG 4UvCYiOOHk9kkJelmI5ilw6wJdz65em9/xFLJR4oZxlxEwNWJyk/6MdZyftJ zPLdPcKt92iht0aGElFDRNLr6zMHbA3VLz8u4fsVkdLNvDcp2NAVwdfRU9g1 IzLqij3f0E4nH1R0Q4Hpu7sCguiEqI4RYVMFpINkHXr1b/T5H+7Ok/nr7HpD RLeyRpSWdpYWP6ZiZJsIm2/h5Jj0gRniEg07uAQEMYgOIFpqLXM7SZYpcHZY RHYfXEzMvBTihIRHyqQ/iRP/lGHPAlwqRW/saTtggi9ZXKCCr6WuKenpydvR vcF1all2OT2EDTMIW17ohUt+S8fth+Pw++mHDmGcd3Tpr2eRZKBuapGWN/r3 DDmBeMhKh5iTqJz/O4Vx8Jhr4Ybdh4eYgzKLCVUikcB3WnWfDdVxTkdOUNCJ QEVQM66tqMO6qaynKlVUXzpBMDO+0by71sGoxyolOCMyPSg/3tHM79rZxP82 BTgzBiEgK/bd7OUH48nXt1IZ1gRbVMrsIKu4YO35e9/il3UC4gsIQfL44gCw d9gq+eXDJ1ooKhJkJUryAoIJmRmRl/np9Fsc3FnU/jniuDpT2cahe1yfMiUk piwoP9/uyqzTstANu+XFOFMq6l0basLkYttCmOyjkLluQ3Btdvj0PIuqrZiv x4ZSf0pJ4KKOkMrPc8VnSnTPEEpgSMvUcWGR91diHN6WBJB9kEibyh6R7E1/ lSNYk+yfgwuXiepWSEcPOmRoxC23mUfIhlmwXLxRQq9Er8gg6H3Jt6Z0o1+R VFEZwCkqVW11Xx1TvrKZUHlXc39+aSBMkBxl62MBX1YdVjMY2fUSk2gKc/la k7KmBwj5RBMSXcKitIepupEu79znQrmWpQHIh3aYayGKz1QYynXu5rbB+SVf nODN25KmoUa/wgI+KjOWXk7LJDu19nH/98aAeRBLnDbCxs/KV5+WfuCWxMDP w76Dc3K6b5USHhBOld2Sy/ezj9dcYY0oONi6vl8xaDmjvc2aEgYH6gK3ZSFe JY9VV1kAzaZ9CkKcspbEBocir4db4uX22xrTeA+4SE5SIdgXh21Qv2iCQV4B U8PJ0snmAghcMB8UD8PjLkjbfjIN2mfql3VWpw4oBvMdWRHr+Y1F7tPhk89Q xRI5RljSs4PDVQKBctXDhbv3xWrApXYwQ7lgbwD5CVVG3cym3AJmKWc+wSmK TPAMFhUQjqeV/BoRIBmyj79lFTjZiOLtBPJd8qla5NnSjAj7Y7Rq56oMakZd LhsuxArgfrK3LOpi8GrFj1zuuqWbCIp79yYHorCHfrgEbxwf0NISORlniMJZ 1aqbCkjFzo/0JzZ28O7Y+AVqMFM89XegtRzCUGPAu2G0TnBHvM6DXYpj0y1g MFKmKvdjPs939Gq3NrZ/r1SN+0Y57uJ5ay17P51btFw86JnhNmguSWQaiGcl HL0pySwIcrY3cP/lhbIZ7PTwwyIBIB838WarsxBnA+Lur+XAa6iPpzxTgfQa KWzWGZIhsE1Vbbyl42CGlqRmqK7cbJqVOGHMHM9NcO9VBC2F1hUVXtBDERxf MAsJOt6xFNj5XF5UfnPNHkGFcYQV4f4H42Jxm9vAzz52yvO+svVE1fKeOkuQ 2hsaLmqvPCtNBquai9pCAl1fo5iZ0kNbzrkrcEhc8R4djXw0+lELXjO72fuf CQ7eo1pPJM6JP1w9KfAGzt0bGbLrpeajJR/neU0qqsQ5ngoiLmv0uyGO/jUq yLpzJcVpYw0ScLmuI6OvHHL07J2Kp9CVI375EmGAFILEYJotHXtJokOqHF5l Zb93vVJL7VepZCxPm2sjSbj+xCWauL0nUSTmKh4h4BigTVSRdbFMASM5nk1v fJmjVGliuwudbc287HlC6Y0upWh2yjv90ufQaakfG+wqMfOkPTGMDhyykygR z4xJt8xeMAoR3vETkYUrc0hI/xDBP1C8ZfTOuuseYSsIY6Olm4FRqW//4hQV Tkgq+JZ14r7wD4yd+VoGCRCP9AO00cRBgGT7zscKvjsEv3uLsJACZsWA0DMG gdcg7S4BpkQuUQAnqmXLh9mT80n5Up+iPpFx3+8nAEuV0LHdRcefnmNa/q7z Ej5DNkAjY4CVwUE7m0thPSex6z1u6Qc/CTwvVPa0OyBEqmYu9HRQ+coLOhBW SZxZRuqhDPRK9JeZ1LuPim9KoTQVZFvoEtdlVhCrnEtNDnGs+SawDQU/m1ku 2EkukzjJu5idN+yPEGsC9AgHTabBNakKWs2Bql7BoFeVhhtuMAz7eLDz4tm1 iaBr5gqg8o02b76vXk8hfMgIZM3GWL5QNuDITelkWmTMgyKzcWxpV4Rn3MW9 356Pu9SudkLueauD2rB0BbPVggOQaacijUY3gHyleltugWlRQ1sp0f6uD9rF fAHlEFrH0rZeN3haOvhOOT80WqK9sDLIm/FR4x4CMCgmD+SNJMuwicntC6iW l2e8ODbiTk6L73Ixguuj1vwyeUGSPQw3MhUkjwOyzcho6IddDV/uBtr+B4hp 82SWsdaLbyf/EVTIblL2Kp22yytrRLZZleHLMlICjHQHa5byycqbv1dF9CFK +4lu3pYjqA89bu8leDtyzUCuErd9eypVRaiczh9KAVAiBL9Sk48IiVACRuwC I7BLNV8AylM6OQpjGWgdZariaCiEfaWCtc88nWZoQDoHz/LwY99l9UzUBt0s NVR4CKIz7U5/j56I5Au/zaDplfGydvB781a8IbEv+Xhjet2yyEl3ukPVjsha M16f0AaK7DfovaS2+K5nn52QOexJDkJahoU/8aq87qO9+KqSZfZ2+LjKwKzF L6YgXTdQ4CES/mhwiPbyWUsr+aM8aYe0idS4YVb2RpM7vw0s7Cn44ix+QC/A Z84m+Pf9jxFOXr+K5zcGylVJcIiCou/70wMv/qdUQyikqgnEYD039u+a5J2h ag6WdKu76DGzmJK2UV9K7c/1FP4C6s1SG0DpG9Qj5lHTjv3YC5hV4PfDL8rW XuCXLwnnTTNBBhpx3jHNFTf4fP5bNQU67zRU6UD1DyPCEjDyLqUP9VtNAvap WQQvYaF981uGq6cCl8rmx/v5AoZIjbw0BtM/kBEp89DiS3Uy/ZBS+vVqb9nR uHjS4M7fOLWH3qrGiwzysJHB8tdUdazOgI7Lak0bP3YMF7SKu1K6zXIsliFy TMkZsupLxX4MxKKYk2LJcYhXsrFB3i1W+xy8oYzHNljz0fb+t6fXAay4DGJ1 oha+pUxYxiXsITxoWMFpTvBFlTJAzd9Jjw+ybZ6WY7Qq2flI+0zTJpmHMO+2 Nn+D1DHg9Wwfdd6S8izl+6NAdeJlGPTZ6aoaWhrpWWyE44vN/4yvYojuS3nt fSu3zRXQuDlGz7Fn+ZIrE7XNmA8hzoofgFLhrXEAaEQNZzmTzrxwHkOjfEbx NlLF4geO7i3ZSRh5zATYESyFlVrtmK40xPcEp9pw5Z32ZsgRTGnlO0IRCMWt WG9zdCj14BhF2vdarH3DQ+aWauwz3E2UatGabVMU+y1dUIyxl6K+1Paq3FXv SMzOyzZy1GC4CdgRUi9SwJT2h8KT/BJ4uqmOhtcxXgbk0/ALUzLK79g3a+QS q1kPn2aszeVVtpSr7s0xE/nzXuaOutIaS8KDqmQSiL9X7wTuvRwCW/HB+btC z6aqxgPjkUrLIjxpplhUCogiNPdl6rm71H7Y9GDYtmjYfC1QWiJRVhXIlldA vhUQYlOaNj5BazwChQjyrkfxMoDOCYHOKiQwTFOrnzhg0MHi5LPY03Gn7NBi 1HnkCuNMslw6GLHSaSUC7gAfBe5H2QZ2fyKhLomOBGkZIeKzjpNsEd8Kjta1 WdH/aDYoRhee2Xya6MTHwC/fPBYreShJnaMJdbGsArkEQUkojjQ8mX/UCmRs H8gRe9UgfktEkznTyWTa2P4m2mbNmC1YrCCAVwPuXL20LhQpDd09B2HiGcjh /Ivose75l6/NgAYYaFPIKpBmLNX/UeI1ZG2YjU9EijhLt3uTV2KU4moxD6Jv 1lw9+2C53TKp3OUXkuw9hIqo9SmspupBfAYGO78Ip70bbdwxIF8bySLEMwUh GYYrZFkfkq4xUEbmU7mu6Cbb4+Iy7b246IussLHLdhGk5NxvR2rBqu3Qq9iQ iGv+tW3fzxhBBdMiU+SJJ8rve62V0pNe2ZiCiL7Ga2nx9KzTpBmvURZuYeSP NvDgfZAeXgoQxLVApg11KUoh4U7/2XLu+heZaqBKGiIjz46RWJuloZUQ7xdd yVP4ieJVR6gsMhWu7KalO5M8a2IWdpA4TGJEHBeb5/PjnQ+EqZPDe+onbAAn 3Lo9cFon61L60S93sOb9Yl3qcpUrc3CaZbTiYV7LflpRdPIp/uDiQ9ptbylv BDVgtkswvI8zXCwXV/0fljZp7paAQlTJiBMidAJeX10WSL8W6+EKGC4RkTiK 39ZnZE/X5cgalMhW0tPIos/UT6QB747ej5to8YcbMNrc/ifcaPRNE5j9aNY6 wKICS8UughBOcQqG2NedhAFwBcE02BbbZcGE4hAVqSuXryKFc+U+kVehyKmI e98+DQgAenMbdJHvmGpYWBk9krfFHWWX4JIp5wFx1z4WsImkMhycO3/U6ljG WnAAfLPKOSNUrW7WHmCiCoG18o+yykgy1GhXdG0u6vkrAZlywcYBKYmco0+G NnTZ2KqzED9LwyHy7D7AActtwhQ5fp+5tO9oQeUH2tqSxYK70DnDwwrB76gy u9Wo4ifibeTe3bQdI18yRX8Ju4tDz/9p7Xmp7d9Mg+NrpCB428Eav/P11Jqd W06nhj5suykl0ZeLvQNUYPn8Pa13j6xaGzGHEVpZ6/hvzQ+F0xIwr4fMk0/o CiyqlF1JpPQ311igKujqnGJRWlkr7vu3HNccn9Q57fvjgmR4NfgRr1pH77F9 5V0eMGCBYxPjXYrdMauqHPiDILKRL495kSjSXzmkgcOk0fPUNnfcW7slGwFd ++UELkiepLkipXv4U5vWC6V8+jZWXaB+dcTeeBaEbZEBHwcvVxTIvVMtgq86 Rnd49XBCwbu73mBxAa+sCwvifbR7O3SCyBDWXffR6SLwBrUt1EIXaAUuyxTV Qf3bhiJbwJOlsLFW7kX7TSlfneepKXnNuwhmywpWzosX/E+eCf8PmvJSlXaP caZz0SYqSKtFM70td5yzgbLZwfIg3RkcyytAFfCH6PSicCpBSxWV7LBxiyls QBC5klfm3y8LLHhqdJp1DDiPcbQUeTFQTwoGq8FqIxtkOFT9S4Y9/+QJDxKv WhopX+esSp2X7uSfBHMl6x4IFYzr1am60r8DnEsxEthruGd1bRiob7X/tK29 TSm7RfoBBVRmeJ4aqmvGq05UAPQp/pBYFnn0VYIdhOYHQQuJ83UnYxq5R/8n VTEgd8E5Fg0fYY2S+2bDy02R483BlZydW5cMTtEjaXm0cfxYq3qVw0gmfHwd BIUVDK8f0SKAIizsWwhjLpcDJYXycxRD5JwmvFp2BQX7HtiWRzq8ZKvU6FVM 5rr2lHlqaQXD7ky6NE242PHOBliJ/+FokxZ5yvwxwm95i9QJ0yJVhU3tSM0I J4u6RlhO5tlDquVi/E3UBFjphr4CeOAfO12FyXTIOQocccOtrEv51dD2/0G6 6JGvG53Gr6PpYzsryAOrPTh1tMCHyZCRSv41GjiVKJZmATghgv+umscc/Xvl AYjgbxaQ2b4OXMSHUkGFKNxyE2t98LX+jHZTd3fX/WNoFjbv1bYTAx6gY1b4 Tsyw+kxxOFf6vHY3lZJggRpNi/CiupDsbxPmLT5Z73ZpuWuovaSslYNHHrJ6 oF1uK0qI6j4Lrn/pvqBYNbnYgZt5KnsvqTiicKRMONFWZxYVt5IGgyRNu+6M TG5nFbwPZjVzEGWIAx/L9pWxtAxYFc/00ztr/7NrRsh1eRRNI3mplPJ3U23q 8otRzGhfPBMGwSzfpWRi/XK7UagDPY1IL0j7BfLfryvgcQlk4IzYB/wWY+6a X1EjoSoRXUGgT8FZ4JeQ66a8JwAOsP6XV7k53Uw9qY3CeDc7ZnSdwy16RXl1 jBOkEySDke2dABuUUulKmGjg0vNODVWTZH7r+LgFlkR0L2YCcLiQpQAkcma0 RZTc5PGPxvPPKcMHWdwKFK8E0N4Nyd2MWJ8Y64C3CtvNmb4lf1drbuXdNvtY D3xwf0mRORagLFHMZsLaq3ZbnB+4lU2wYKxNjm0B4u/0JSQ46nzqVdOGehNh sIRCqqVsQ57OhB+dxoqNzcVZFYAg3XzDdHsz89jqj3pw0QZ2nDE2TLkO31Kt ETTsDQ59fv8v8FJaWqfOKB9Dv+siaYEZE4aIx7D3luUDoj8WASOeJEnpPTde h5Frtq5obTmUJeWnLIq8e6jIxOTx+R52Yj87L4MnKRqKns50jVA1fOuFBBxz XAZ8kZt+3gQxeoIfdEKbCQScjbjbx2591EDuEHuzJtciWNKHxCBZplo+iv0C /djQpDAAku1H/NodayawIsT0PES1Rorq03XLKDXhhR5GHdRmbtnvfH0TLnh+ uycTOkgfWetk6fG0YrDa41orIxCZez3iJhMgOXtyCcGpucdS8BgJeTenKEEV FmpCuzE6+pfpz1+cZZS5RLB+tLcM3RHe6TNd47xu6h8UMLqx3l45iBFdq/Wp 8ZGn9wqcqldB4VJL9lBW3hCYRTIsfjwsGMuhbGSNN94gMLVYlcShGI0xD5BN HFqEannvTwpmLElY71tvHhrLNkch5gOp+M+idKfMRgis8EGgbzY+TK3m05k4 B7vxuYlTuA/zJ7xrm4Jn2m9QYcKm0biAwnqDM5AP+Hmhk5bpObP+PJw+jHeQ O4m8iyehiPR2L3leT6bZn729bq/mxwK4mRZ12FMupThu8tFVOMzo3NszhPdj PvCKQ9cZt0jt7XbuHubldW/K2EunqClw6Am6sTHQSjX3jTsfXgYoqITMg8X2 o1ZmR9SDI6WfI2rU55LlGBlHdB2PCnKgKwsObzz4+mHDJ4/Cf8qF4x3KakKj OvtGUs4HJXABdLcUNTH9NaKdpkQp5EpMtUN8HMjkM00q/4LmVpiBFSFn2SK1 V8lWEMPgvmThZagKp3TXF0Qn/Axzk0j86DqSEo5bf6kLx+YzF7JjH0Mve4lc xGIgyVs85QYdvhbYoTIl76LTDUnM4+ddmVV9kIJ7G4mTqsKREzB9/ytNsBRi F9SOatjfGCJd4Z7TNjVb7iO24lyuohiw5DbaB9I75B+bYWAYeArcyzzFxGiZ Wyl93maSfxLK5oUHEBxJn0DTeQO/uJuH29mR6FFQS4uadaQlAaCdfeYLxk0W FpeUSzqz1gSN32mSSqJzBq2puKyWX8DffAyJuvkEh2ikRxaWrfdtZeM3bM1v slzuPYyMOO+y9yanzqNSMGY2j0CcKImojIplNPylQEcc0v9PKqwifiUrQbsr jHMQ1XWlbOjx7hHPtgokq6PJfnqh1hCZfOReoaKWst/oJLejY/2ssxsRj+JN nOxYgMepdlOHM0KTa8V9bI/qcN36Y+WjO9r44QFJivPN0cue4kYUCI5UQH+2 PVfgTykQacsx7WhIqlBsCIrRaoAA676DDCH31PAcLDO8w2qm1Pwdph1lIsVw 94WZI0gELImnB9NDAlrUL4+ONfJl4gRL1FKvvTSiWBapW/9WXzPGkTmcOIL+ 9QhqewyGBIdAE9EYd031v1quC+R1AesbwPXrAv8g6wG4E8L16x7oagEAAOsC zSDoCAAAAOkIAAAAI8L4QMPBwHQLw0joPgAAAC16Eo9zNPa18kWTvMN8S7RV lRrcICFD5iYzmGu5mYII69jF4lnVhV1+BzIhtDe7veCu5FV+L3pKW+Ef9K/M +HMCDyFg6AYAAACLZCQI6w0z22T/M2SJI/H/A+vo6wG4i8VIM9JkjwJa6wFw YOgGAAAAi2QkCOsaZGf/NgAAZGeJJgAAnIEMJAABAACd+HPczSBkZ48GAABY YesBuOgAAAAA+XICzSAtGwShEOgLAAAA/CvG6QgAAABAM8P5I8XDSLizhH8e izwkWIHvZRRBAOsC/yBozJm3NlqB8giK9jYL5HUB6/kD17ggWSUXi9iB6xNZ JRfrA//r/0ALxTPJgfGCvKha+XICzSD4A8LoCgAAAA01OwcA6QgAAAAbxsMF uaCHBhXEZ5kY+WvJezEKwcEH+IPRFYHCBAAAAOsBZvXrA//r/xvE6AoAAACL xukJAAAAg+BhA8WQwyvBuFderBQr2IHDVl6sFPlyAs0gkAvEuA0rnz4DyOsB uEArwEgDw3mm6wFwHQ6K6DBh6wG4Jbb02XfDyi/Hy0ccW5yFRqf/i5HdJf38 PGR5fzDfB7tv07rc/9SP945RI1kasI1dL7+wMMhYJeH+BCo5cizFkTtIdwbW jIKRF/oaRDiuGU6kio5i4E3+0Er5CK1jeYWH8U2vgR+Xt/QtNFDa8OgAAAAA gSwkNwIAAP9kJAQA+ekl5P//AAAAH5+EEB7MAQAAAAAAAAAAAD7MAQAuzAEA JswBAAAAAAAAAAAAS8wBADbMAQAAAAAAAAAAAAAAAAAAAAAAAAAAAFbMAQAA AAAAacwBAAAAAABWzAEAAAAAAGnMAQAAAAAAa2VybmVsMzIuZGxsAHVzZXIz Mi5kbGwAAABHZXRNb2R1bGVIYW5kbGVBAAAATWVzc2FnZUJveEEAAAAAAAAA AAAAAAAIAAAAAAC8zQEA4s0BAPnNAQA8zgEAV84BAHzOAQCRzgEADs8BAAAA AAAAAAAAGF8BAAAAAAAAAAAAALABAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAA AHX24pt1erVAx+EHbN00mdp1m4ZYgw623qwqBLMoD62m1C4yFWFoRfhas/kU CViQd+Fd22k707O2ixRCJwEgsz8KmpyvNuVKyOtGCO+aXQ8CXBq/LDF8o+VT JIWaO9M3Req9+TvRU/ROtoTUtvmhBh8R4gHvOIPvvRVrS5msV9uUI/rGGUPu tcPGiMhYLiCyLyVCim6MU3hDjH43eb068/9CtMQsM9IWSHjYVvYgJ6g0HThB TMzR5ICkPuVLNgPT7QAAAAAAAAAAAAAAAAJtpJ0AAAAAAAAAAAAAAAAAAAAA AAAAAEB+aFgD5cybOXTr2LJn0KJGjyFEixk0a9iyZs6ePn8BBQwaN3HlhfVN EZm20wvw7inuRSH5OXEZqt0U755qF2h2LEpFHoK++lRUj7fXFPDMKfsBNv53 FAS2kguv/VYWb2B/OkAYkaS7WBefscQC8NE//FUh5jlQDrrHAan7TF4BQH5o WAPFu/NQGI743gixxi/hRmTqOXAnlJNmi+xMEHMle3JeHYDs91YXiqzbCbeC J69lCMc5Uh620RKn8VBeAUFpeVgclb7+SgeCt9xHtdA04FNli1pmKPjXFLzx TF4hQ2V2UlGGo/VNEYWskg+x0WbtRCHlOVkEvNsAp/taUSFMajpOHpDs6Uwa y7mSFKnRMupMSYF9UQmt1QGr7BJfYmlpe0VRhKD3GRaZvdMMoM0v4VU3q3tR DbfAA+7sSxFvbGJ9FwWNpegZBJm31RWxz2ePaCr/fFMZscYf7v1WGmJuLHxW GImp/xhUv7DbFPDkL+NEZON4R0u61wOgvlMQZWxqc1IVy8GRaxGKq90J8M8v 6Ekwq3tRS7mSFqHtTRZjaWk6QRiXuegZHYW+1wSkyynhAESjZCzd2L7oiKEY WaIt/wsFAAAJCQgICgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP// --CSmtpMsgPart123X456_000_003BEB3B-- From vnuorval@morphine.tml.hut.fi Fri Jan 24 00:31:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Jan 2003 00:31:36 -0800 (PST) Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0O8VU3v016002 for ; Fri, 24 Jan 2003 00:31:32 -0800 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id KAA10801 for ; Fri, 24 Jan 2003 10:38:19 +0200 X-Authentication-Warning: tml-gw.tml.hut.fi: smap set sender to using -f Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma010788; Fri, 24 Jan 03 10:38:08 +0200 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id h0O8c8Pi004526; Fri, 24 Jan 2003 10:38:08 +0200 (EET) Received: from tml.hut.fi (localhost [127.0.0.1]) by morphine.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id h0O8c8F5009952; Fri, 24 Jan 2003 10:38:08 +0200 (EET) Received: from localhost (vnuorval@localhost) by tml.hut.fi (8.12.2+Sun/8.12.2/Submit) with ESMTP id h0O8c7N8009949; Fri, 24 Jan 2003 10:38:07 +0200 (EET) Date: Fri, 24 Jan 2003 10:38:06 +0200 (EET) From: Ville Nuorvala To: linux-kernel@vger.kernel.org, cc: davem@redhat.com, Subject: [PATCH] IPv6: fixes to proxy Neighbor discovery Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1612 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@morphine.tml.hut.fi Precedence: bulk X-list: netdev Hello! This patch contains some fixes to proxy Neighbor Discovery. 1) Source address fixed in neigbor advertisements: RFC 2461 4.4. Neighbor Advertisement Message Format " Source Address An address assigned to the interface from which the advertisement is sent." This also applies to proxy Neighbor Adverisements. 2) Proxy protects against Duplicate Address Detection: RFC 2461 7.2.3. Receipt of Neighbor Solicitations " A valid Neighbor Solicitation that does not meet any the following requirements MUST be silently discarded: - The Target Address is a "valid" unicast or anycast address assigned to the receiving interface [ADDRCONF], - The Target Address is a unicast address for which the node is offering proxy service, or - The Target Address is a "tentative" address on which Duplicate Address Detection is being performed [ADDRCONF]. If the Target Address is tentative, the Neighbor Solicitation should be processed as described in [ADDRCONF]. Otherwise, the following description applies. If the Source Address is not the unspecified address and, on link layers that have addresses, the solicitation includes a Source Link-Layer Address option, then the recipient SHOULD create or update the Neighbor Cache entry for the IP Source Address of the solicitation." .... " If the Source Address is the unspecified address the node MUST NOT create or update the Neighbor Cache entry. After any updates to the Neighbor Cache, the node sends a Neighbor Advertisement response as described in the next section." This clearly means the proxy should protect the address against DAD. Below are patches against both the 2.4 and 2.5 bk trees. Thanks, Ville ===== net/ipv6/ndisc.c 1.16 vs edited ===== --- 1.16/net/ipv6/ndisc.c Sat Dec 21 09:43:20 2002 +++ edited/net/ipv6/ndisc.c Fri Jan 24 10:14:33 2003 @@ -23,6 +23,7 @@ * and moved to net/core. * Pekka Savola : RFC2461 validation * YOSHIFUJI Hideaki @USAGI : Verify ND options properly + * Ville Nuorvala : RFC2461 fixes to proxy ND */ /* Set to 3 to get tracing... */ @@ -370,8 +371,9 @@ */ void ndisc_send_na(struct net_device *dev, struct neighbour *neigh, - struct in6_addr *daddr, struct in6_addr *solicited_addr, - int router, int solicited, int override, int inc_opt) + struct in6_addr *daddr, struct in6_addr *saddr, + struct in6_addr *solicited_addr, int router, + int solicited, int override, int inc_opt) { struct sock *sk = ndisc_socket->sk; struct nd_msg *msg; @@ -401,7 +403,7 @@ return; } - ip6_nd_hdr(sk, skb, dev, solicited_addr, daddr, IPPROTO_ICMPV6, len); + ip6_nd_hdr(sk, skb, dev, saddr, daddr, IPPROTO_ICMPV6, len); msg = (struct nd_msg *) skb_put(skb, len); @@ -421,7 +423,7 @@ ndisc_fill_option(msg->opt, ND_OPT_TARGET_LL_ADDR, dev->dev_addr, dev->addr_len); /* checksum */ - msg->icmph.icmp6_cksum = csum_ipv6_magic(solicited_addr, daddr, len, + msg->icmph.icmp6_cksum = csum_ipv6_magic(saddr, daddr, len, IPPROTO_ICMPV6, csum_partial((__u8 *) msg, len, 0)); @@ -669,8 +671,8 @@ struct in6_addr maddr; ipv6_addr_all_nodes(&maddr); - ndisc_send_na(dev, NULL, &maddr, &ifp->addr, - ifp->idev->cnf.forwarding, 0, + ndisc_send_na(dev, NULL, &maddr, &ifp->addr, + &ifp->addr, ifp->idev->cnf.forwarding, 0, ipv6_addr_type(&ifp->addr)&IPV6_ADDR_ANYCAST ? 0 : 1, 1); in6_ifa_put(ifp); @@ -693,7 +695,8 @@ neigh = neigh_event_ns(&nd_tbl, lladdr, saddr, dev); if (neigh || !dev->hard_header) { - ndisc_send_na(dev, neigh, saddr, &ifp->addr, + ndisc_send_na(dev, neigh, saddr, + &ifp->addr, &ifp->addr, ifp->idev->cnf.forwarding, 1, ipv6_addr_type(&ifp->addr)&IPV6_ADDR_ANYCAST ? 0 : 1, 1); @@ -707,7 +710,8 @@ int addr_type = ipv6_addr_type(saddr); if (in6_dev && in6_dev->cnf.forwarding && - (addr_type & IPV6_ADDR_UNICAST) && + (addr_type & IPV6_ADDR_UNICAST || + addr_type == IPV6_ADDR_ANY) && pneigh_lookup(&nd_tbl, &msg->target, dev, 0)) { int inc = ipv6_addr_type(daddr)&IPV6_ADDR_MULTICAST; @@ -715,17 +719,38 @@ skb->pkt_type == PACKET_HOST || inc == 0 || in6_dev->nd_parms->proxy_delay == 0) { + struct in6_addr na_saddr; + if (inc) nd_tbl.stats.rcv_probes_mcast++; else nd_tbl.stats.rcv_probes_ucast++; - - neigh = neigh_event_ns(&nd_tbl, lladdr, saddr, dev); - if (neigh) { - ndisc_send_na(dev, neigh, saddr, &msg->target, - 0, 1, 0, 1); - neigh_release(neigh); + /* + * RFC2461 4.4: + * The souce address is always an address assigned to the interface, + * this also applies to proxies + */ + if (ipv6_get_lladdr(dev, &na_saddr)) { + in6_dev_put(in6_dev); + return; + } + if (addr_type & IPV6_ADDR_UNICAST) { + neigh = neigh_event_ns(&nd_tbl, lladdr, saddr, dev); + + if (neigh) { + ndisc_send_na(dev, neigh, saddr, + &na_saddr, &msg->target, + 0, 1, 0, 1); + neigh_release(neigh); + } + } else { + /* the proxy should also protect against DAD */ + struct in6_addr maddr; + ipv6_addr_all_nodes(&maddr); + ndisc_send_na(dev, NULL, &maddr, + &na_saddr, &msg->target, + 0, 0, 0, 1); } } else { struct sk_buff *n = skb_clone(skb, GFP_ATOMIC); ===== net/ipv6/ndisc.c 1.21 vs edited ===== --- 1.21/net/ipv6/ndisc.c Sat Dec 21 09:14:32 2002 +++ edited/net/ipv6/ndisc.c Fri Jan 24 10:17:18 2003 @@ -23,6 +23,7 @@ * and moved to net/core. * Pekka Savola : RFC2461 validation * YOSHIFUJI Hideaki @USAGI : Verify ND options properly + * Ville Nuorvala : RFC2461 fixes to proxy ND */ /* Set to 3 to get tracing... */ @@ -375,8 +376,9 @@ */ static void ndisc_send_na(struct net_device *dev, struct neighbour *neigh, - struct in6_addr *daddr, struct in6_addr *solicited_addr, - int router, int solicited, int override, int inc_opt) + struct in6_addr *daddr, struct in6_addr *saddr, + struct in6_addr *solicited_addr, int router, + int solicited, int override, int inc_opt) { struct sock *sk = ndisc_socket->sk; struct nd_msg *msg; @@ -406,7 +408,7 @@ return; } - ip6_nd_hdr(sk, skb, dev, solicited_addr, daddr, IPPROTO_ICMPV6, len); + ip6_nd_hdr(sk, skb, dev, saddr, daddr, IPPROTO_ICMPV6, len); msg = (struct nd_msg *) skb_put(skb, len); @@ -426,7 +428,7 @@ ndisc_fill_option(msg->opt, ND_OPT_TARGET_LL_ADDR, dev->dev_addr, dev->addr_len); /* checksum */ - msg->icmph.icmp6_cksum = csum_ipv6_magic(solicited_addr, daddr, len, + msg->icmph.icmp6_cksum = csum_ipv6_magic(saddr, daddr, len, IPPROTO_ICMPV6, csum_partial((__u8 *) msg, len, 0)); @@ -674,8 +676,8 @@ struct in6_addr maddr; ipv6_addr_all_nodes(&maddr); - ndisc_send_na(dev, NULL, &maddr, &ifp->addr, - ifp->idev->cnf.forwarding, 0, + ndisc_send_na(dev, NULL, &maddr, &ifp->addr, + &ifp->addr, ifp->idev->cnf.forwarding, 0, ipv6_addr_type(&ifp->addr)&IPV6_ADDR_ANYCAST ? 0 : 1, 1); in6_ifa_put(ifp); @@ -698,7 +700,8 @@ neigh = neigh_event_ns(&nd_tbl, lladdr, saddr, dev); if (neigh || !dev->hard_header) { - ndisc_send_na(dev, neigh, saddr, &ifp->addr, + ndisc_send_na(dev, neigh, saddr, + &ifp->addr, &ifp->addr, ifp->idev->cnf.forwarding, 1, ipv6_addr_type(&ifp->addr)&IPV6_ADDR_ANYCAST ? 0 : 1, 1); @@ -712,7 +715,8 @@ int addr_type = ipv6_addr_type(saddr); if (in6_dev && in6_dev->cnf.forwarding && - (addr_type & IPV6_ADDR_UNICAST) && + (addr_type & IPV6_ADDR_UNICAST || + addr_type == IPV6_ADDR_ANY) && pneigh_lookup(&nd_tbl, &msg->target, dev, 0)) { int inc = ipv6_addr_type(daddr)&IPV6_ADDR_MULTICAST; @@ -720,17 +724,38 @@ skb->pkt_type == PACKET_HOST || inc == 0 || in6_dev->nd_parms->proxy_delay == 0) { + struct in6_addr na_saddr; + if (inc) nd_tbl.stats.rcv_probes_mcast++; else nd_tbl.stats.rcv_probes_ucast++; - - neigh = neigh_event_ns(&nd_tbl, lladdr, saddr, dev); - if (neigh) { - ndisc_send_na(dev, neigh, saddr, &msg->target, - 0, 1, 0, 1); - neigh_release(neigh); + /* + * RFC2461 4.4: + * The souce address is always an address assigned to the interface, + * this also applies to proxies + */ + if (ipv6_get_lladdr(dev, &na_saddr)) { + in6_dev_put(in6_dev); + return; + } + if (addr_type & IPV6_ADDR_UNICAST) { + neigh = neigh_event_ns(&nd_tbl, lladdr, saddr, dev); + + if (neigh) { + ndisc_send_na(dev, neigh, saddr, + &na_saddr, &msg->target, + 0, 1, 0, 1); + neigh_release(neigh); + } + } else { + /* the proxy should also protect against DAD */ + struct in6_addr maddr; + ipv6_addr_all_nodes(&maddr); + ndisc_send_na(dev, NULL, &maddr, + &na_saddr, &msg->target, + 0, 0, 0, 1); } } else { struct sk_buff *n = skb_clone(skb, GFP_ATOMIC); -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tml.hut.fi, phone: +358 (0)9 451 5257 From disneyatino@hotmail.com Sat Jan 25 03:58:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 25 Jan 2003 03:58:59 -0800 (PST) Received: from bsd.mzt.megared.net.mx (mzt.megared.net.mx [200.52.220.19]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0PBwm3v029104 for ; Sat, 25 Jan 2003 03:58:49 -0800 Received: from 7 ([10.32.220.201]) by bsd.mzt.megared.net.mx (8.11.6/8.11.6) with ESMTP id h0PAl9R00713 for ; Sat, 25 Jan 2003 03:47:10 -0700 (MST) Message-ID: <413847-22003162513711840@7> From: "Brenda Valdez" To: netdev@oss.sgi.com Subject: =?US-ASCII?Q?La_mejor_herencia_para_sus_ni=F1os...?= Date: Sat, 25 Jan 2003 05:07:13 -0800 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-length: 100 X-archive-position: 1613 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: disneylatino9@hotmail.com Precedence: bulk X-list: netdev El ingles es para siempre=A1=A1=A1 "El Ingles es para siempre" [[HTML alternate version deleted]] From markzzzsmith@ozemail.com.au Sun Jan 26 04:14:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 26 Jan 2003 04:14:28 -0800 (PST) Received: from mail.nosense.org (1Cust64.tnt4.adl1.da.uu.net [63.34.231.64]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0QCEH3v017028 for ; Sun, 26 Jan 2003 04:14:18 -0800 Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 675623B2E4; Sun, 26 Jan 2003 22:51:09 +1030 (CST) Subject: [PATCH][RFT] 802.3x / ETHTOOL Pause frame support for natsemi 83816 From: Mark Smith To: thockin@hockin.org Cc: netdev@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 26 Jan 2003 22:51:09 +1030 Message-Id: <1043583669.1774.22.camel@dupy> Mime-Version: 1.0 X-archive-position: 1614 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: markzzzsmith@ozemail.com.au Precedence: bulk X-list: netdev Hi Tim, * I've put together the following patch to enable 802.3x ethernet pause frame support, including the ethtool pause options, on the natsemi 83816 based network cards. I've tested it on my 83815 based Netgear FA312 card, which does have all the required registers, but according to page 69 of the NS83815.pdf document, the pause feature is not supported. I added the check for 83816 chips just as the final step before posting it. I haven't done any kernel level programming before, so I'd appreciate any suggestions or improvements I can make to it. The patch is against natsemi.c version 1.0.17. Thanks, Mark. --- natsemi.orig/natsemi.c Sun Jan 26 20:53:06 2003 +++ natsemi.ethpause/natsemi.c Sun Jan 26 21:32:30 2003 @@ -133,6 +133,11 @@ * comments update (Manfred) * do the right thing on a phy-reset (Manfred and Tim) + version 1.0.17+ETHPAUSE: (Mark Smith, markzzzsmith at yahoo.com.au) + * enable processing of 802.3x multicast pause frames + on the 83816 + * add support for ethtool [gs]pause options + TODO: * big endian support with CFG:BEM instead of cpu_to_le32 * support for an external PHY @@ -171,8 +176,8 @@ #include #define DRV_NAME "natsemi" -#define DRV_VERSION "1.07+LK1.0.17" -#define DRV_RELDATE "Sep 27, 2002" +#define DRV_VERSION "1.07+LK1.0.17+ETHPAUSE" +#define DRV_RELDATE "Jan 19, 2003" /* Updated to recommendations in pci-skeleton v2.03. */ @@ -449,6 +454,7 @@ CfgAnegEnable = 0x2000, CfgAneg100 = 0x4000, CfgAnegFull = 0x8000, + CfgPauseAdvert = 0x00010000, CfgAnegDone = 0x8000000, CfgFullDuplex = 0x20000000, CfgSpeed100 = 0x40000000, @@ -569,6 +575,17 @@ WakeOptsSummary = 0x7ff }; +enum PauseCmd_bits { + PauseCounter = 0x0000ffff, + PauseManLoadEnable = 0x00010000, + PauseNegotiated = 0x00200000, + PauseFrameRxed = 0x00400000, + PauseActive = 0x00800000, + PauseOnDestAddr = 0x20000000, + PauseOnMultiCast = 0x40000000, + PauseEnable = 0x80000000 +}; + enum RxFilterAddr_bits { RFCRAddressMask = 0x3ff, AcceptMulticast = 0x00200000, @@ -586,6 +603,10 @@ StatsStrobe = 0x8, }; +enum AnegAdv_bits { + AnegAdvPause = 0x400 +}; + enum MIntrCtrl_bits { MICRIntEn = 0x2, }; @@ -714,6 +735,7 @@ static int netdev_close(struct net_device *dev); static int netdev_get_regs(struct net_device *dev, u8 *buf); static int netdev_get_eeprom(struct net_device *dev, u8 *buf); +static int netdev_reautoneg_link(struct net_device *dev); static int __devinit natsemi_probe1 (struct pci_dev *pdev, @@ -1284,13 +1306,13 @@ * ECRETRY=1 * ATP=1 */ - np->tx_config = TxAutoPad | TxCollRetry | TxMxdma_256 | (0x1002); + np->tx_config = TxAutoPad | TxCollRetry | TxMxdma_256 | (0x1002); writel(np->tx_config, ioaddr + TxConfig); /* DRTH 0x10: start copying to memory if 128 bytes are in the fifo * MXDMA 0: up to 256 byte bursts */ - np->rx_config = RxMxdma_256 | 0x20; + np->rx_config = RxMxdma_256 | 0x20; writel(np->rx_config, ioaddr + RxConfig); /* Disable PME: @@ -1306,6 +1328,11 @@ dev->name, readl(ioaddr + WOLCmd)); } + /* Switch on 802.3x multicast pause frame processing. + * Tx will not actually pause unless pause capability + * is autonegotiated or manually switched on. */ + writel(PauseOnMultiCast,ioaddr + PauseCmd); + check_link(dev); __set_rx_mode(dev); @@ -2041,6 +2068,7 @@ return 0; } /* set wake-on-lan */ + case ETHTOOL_SWOL: { struct ethtool_wolinfo wol; int r; @@ -2098,16 +2126,7 @@ } /* restart autonegotiation */ case ETHTOOL_NWAY_RST: { - int tmp; - int r = -EINVAL; - /* if autoneg is off, it's an error */ - tmp = mdio_read(dev, 1, MII_BMCR); - if (tmp & BMCR_ANENABLE) { - tmp |= (BMCR_ANRESTART); - mdio_write(dev, 1, MII_BMCR, tmp); - r = 0; - } - return r; + return netdev_reautoneg_link(dev); } /* get link status */ case ETHTOOL_GLINK: { @@ -2151,6 +2170,83 @@ return 0; } + case ETHTOOL_GPAUSEPARAM: { + struct ethtool_pauseparam epause = { ETHTOOL_GPAUSEPARAM }; + long ioaddr = dev->base_addr; + + /* Only supported on the 83816, 83815 has all the registers + * required, but according to pg 69 of DP83815.pdf, + * "The DP83815 does not support this feature." + * Sounds like a hardware bug to me :-( + * Wish I had a 83816 based card to test that my pause + * code actually does what I think it does. + */ + if (np->srr < SRR_DP83816_A4) + return -EINVAL; + + spin_lock_irq(&np->lock); + + epause.autoneg = + (readl(ioaddr + AnegAdv) & AnegAdvPause) != 0; + + if (epause.autoneg) + epause.tx_pause = + (readl(ioaddr + PauseCmd) & PauseNegotiated)\ + != 0; + else + epause.tx_pause = + (readl(ioaddr + PauseCmd) & PauseEnable) != 0; + + /* NS8381[56] has no rx pause */ + spin_unlock_irq(&np->lock); + + if (copy_to_user(useraddr, &epause, sizeof(epause))) + return -EFAULT; + + return 0; + + } + + case ETHTOOL_SPAUSEPARAM: { + struct ethtool_pauseparam epause; + long ioaddr = dev->base_addr; + u32 tmp; + + /* 83816 and later only */ + if (np->srr < SRR_DP83816_A4) + return -EINVAL; + + if (copy_from_user(&epause, useraddr, sizeof(epause))) + return -EFAULT; + + if (epause.rx_pause) + return -EINVAL; + + spin_lock_irq(&np->lock); + + if (epause.autoneg) { + tmp = readl(ioaddr + AnegAdv) | AnegAdvPause; + writel(tmp, ioaddr + AnegAdv); + } else { + tmp = readl(ioaddr + AnegAdv) & ~AnegAdvPause; + writel(tmp, ioaddr + AnegAdv); + } + + if (epause.tx_pause) { + tmp = readl(ioaddr + PauseCmd) | PauseEnable; + writel(tmp, ioaddr + PauseCmd); + } else { + tmp = readl(ioaddr + PauseCmd) & ~PauseEnable; + writel(tmp, ioaddr + PauseCmd); + } + + netdev_reautoneg_link(dev); + + spin_unlock_irq(&np->lock); + + return 0; + } + } return -EOPNOTSUPP; @@ -2437,6 +2533,21 @@ ebuf[i] = SWAP_BITS(ebuf[i]); } return 0; +} + +static int netdev_reautoneg_link(struct net_device *dev) +{ + int tmp; + int r = -EINVAL; + + /* if autoneg is off, it's an error */ + tmp = mdio_read(dev, 1, MII_BMCR); + if (tmp & BMCR_ANENABLE) { + tmp |= (BMCR_ANRESTART); + mdio_write(dev, 1, MII_BMCR, tmp); + r = 0; + } + return r; } static int netdev_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) From pp@evil.netppl.fi Mon Jan 27 12:19:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Jan 2003 12:19:52 -0800 (PST) Received: from evil.netppl.fi (evil.netppl.fi [195.242.209.201]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0RKJi3v026281 for ; Mon, 27 Jan 2003 12:19:45 -0800 Received: (from pp@localhost) by evil.netppl.fi (8.11.6/8.11.6) id h0RKLj307150; Mon, 27 Jan 2003 22:21:45 +0200 Date: Mon, 27 Jan 2003 22:21:45 +0200 From: Pekka Pietikainen To: Brian Tierney Cc: netdev@oss.sgi.com Subject: Re: paper Message-ID: <20030127202145.GA3049@netppl.fi> References: <7BD96DBF-3225-11D7-9775-000A956767EC@lbl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <7BD96DBF-3225-11D7-9775-000A956767EC@lbl.gov> User-Agent: Mutt/1.4i X-archive-position: 1615 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pp@netppl.fi Precedence: bulk X-list: netdev On Mon, Jan 27, 2003 at 10:31:00AM -0800, Brian Tierney wrote: > > Hi Pekka > > I thought you might find this paper interesting. Please forward to the > appropriate Linux TCP folks. > Thanks. > > http://www-didc.lbl.gov/papers/PFDL.tierney.pdf Hi It was certainly an interesting read. I'll Cc: this reply netdev@oss.sgi.com, which has relevant people on it. One idea that might help in pinpointing the problem is using oprofile to see where all that CPU is going (http://oprofile.sourceforge.net) when the bug occurs. What it does is lets you profile applications/the kernel quite transparently and see where all your CPU is going when the errors start happening. Even if it's not useful in finding this problem, it's certainly a very cool tool you should look at ;) To find out the problem, they'll of course need a description of the environment (kernel versions, network between them, tcpdump logs etc.) I do remember seeing a similar problem on local GigE too when the zerocopy patches first came out. That did get fixed (or maybe just made impossible to trigger on GigE). Can't remember the details, what happened was that the cwnd and ssthresh dropped when there was an error and never recovered (resulting in something like a 80 -> 50-60MB/s performance drop, which lasted until the route cache was flushed). An evil hack to try is /sbin/ip route add 192.168.9.2 ssthresh dev eth0 , which might make it "work" (but it's not the right solution, it just makes the tcp stack very rude in finding the proper speed to send after an error :) ) -- Pekka Pietikainen From bltierney@lbl.gov Mon Jan 27 13:03:51 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Jan 2003 13:03:59 -0800 (PST) Received: from postal2.lbl.gov (postal2.lbl.gov [131.243.248.26]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0RL3o3v027228 for ; Mon, 27 Jan 2003 13:03:51 -0800 Received: from postal2.lbl.gov (localhost [127.0.0.1]) by postal2.lbl.gov (8.11.2/8.11.2) with ESMTP id h0RLArh01216 for ; Mon, 27 Jan 2003 13:10:53 -0800 (PST) Received: from lbl.gov (btnote.dhcp.lbl.gov [131.243.2.223]) by postal2.lbl.gov (8.11.2/8.11.2) with ESMTP id h0RLApx01201; Mon, 27 Jan 2003 13:10:51 -0800 (PST) Date: Mon, 27 Jan 2003 13:10:46 -0800 Subject: Re: paper Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Brian Tierney , Jason Lee To: netdev@oss.sgi.com From: Brian Tierney In-Reply-To: <20030127202145.GA3049@netppl.fi> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-archive-position: 1616 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bltierney@lbl.gov Precedence: bulk X-list: netdev The bug is quite easy to replicate, of you have access to the right type of network. You need a path with a RTT > 150 ms, capable of at least 500 Mbps throughput. Then set both the send and receive buffer to 20 MB, and watch what happens. I might be able to provide access to such a network if necessary. I'll check out oprofile and see what I find. Hopefully folks will read the paper to see how the combination of web100 and NetLogger make a great TCP analysis tool. Cheers. On Monday, January 27, 2003, at 12:21 PM, Pekka Pietikainen wrote: > On Mon, Jan 27, 2003 at 10:31:00AM -0800, Brian Tierney wrote: >> >> Hi Pekka >> >> I thought you might find this paper interesting. Please forward to the >> appropriate Linux TCP folks. >> Thanks. >> >> http://www-didc.lbl.gov/papers/PFDL.tierney.pdf > Hi > > It was certainly an interesting read. I'll Cc: this reply > netdev@oss.sgi.com, which has relevant people on it. One idea that > might help in pinpointing the problem is using oprofile to see where > all that > CPU is going (http://oprofile.sourceforge.net) when the bug occurs. > What it does is lets you profile applications/the kernel quite > transparently > and see where all your CPU is going when the errors start happening. > Even if it's not useful in finding this problem, it's certainly a very > cool tool you should look at ;) > > To find out the problem, they'll of course need a description of the > environment (kernel versions, network between them, tcpdump logs etc.) > > I do remember seeing a similar problem on local GigE too when the > zerocopy > patches first came out. That did get fixed (or maybe just made > impossible > to trigger on GigE). Can't remember the details, what happened was > that the > cwnd and ssthresh dropped when there was an error and never recovered > (resulting in something like a 80 -> 50-60MB/s performance drop, which > lasted until the route cache was flushed). > > An evil hack to try is > /sbin/ip route add 192.168.9.2 ssthresh dev eth0 , > which might make it "work" (but it's not the right solution, it just > makes the tcp stack very rude in finding the proper speed to send > after an error :) ) > > -- > Pekka Pietikainen > > > > ------------------------------------------------------------------------ ------------------- Brian L. Tierney, Lawrence Berkeley National Laboratory (LBNL) 1 Cyclotron Rd. MS: 50B-2239, Berkeley, CA 94720 tel: 510-486-7381 fax: 510-495-2998 efax: 240-332-4065 bltierney@lbl.gov http://www-didc.lbl.gov/~tierney ------------------------------------------------------------------------ ------------------ From ak@suse.de Mon Jan 27 13:12:47 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Jan 2003 13:12:49 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0RLCj3v027687 for ; Mon, 27 Jan 2003 13:12:46 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id A1D49146FE; Mon, 27 Jan 2003 22:19:44 +0100 (MET) Date: Mon, 27 Jan 2003 22:19:44 +0100 From: Andi Kleen To: Brian Tierney Cc: netdev@oss.sgi.com, Jason Lee Subject: Re: paper Message-ID: <20030127211944.GA16922@wotan.suse.de> References: <20030127202145.GA3049@netppl.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-archive-position: 1617 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev > I'll check out oprofile and see what I find. You don't even need oprofile. Just boot the kernel with profile=2 Then before you reproduce the problem clear the profile counters with echo > /proc/profile Afterwards read the profile data with /usr/sbin/readprofile This only works for non modular code, if the problem should be in some modular driver it won't find it. -Andi From bltierney@lbl.gov Mon Jan 27 13:13:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Jan 2003 13:13:19 -0800 (PST) Received: from postal2.lbl.gov (postal2.lbl.gov [131.243.248.26]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0RLDH3v027897 for ; Mon, 27 Jan 2003 13:13:17 -0800 Received: from postal2.lbl.gov (localhost [127.0.0.1]) by postal2.lbl.gov (8.11.2/8.11.2) with ESMTP id h0RLKJh01869 for ; Mon, 27 Jan 2003 13:20:19 -0800 (PST) Received: from lbl.gov (btnote.dhcp.lbl.gov [131.243.2.223]) by postal2.lbl.gov (8.11.2/8.11.2) with ESMTP id h0RLKIx01863; Mon, 27 Jan 2003 13:20:18 -0800 (PST) Date: Mon, 27 Jan 2003 13:20:15 -0800 Subject: question on routine tcp_moderate_cwnd Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Brian Tierney To: netdev@oss.sgi.com From: Brian Tierney Content-Transfer-Encoding: 7bit Message-Id: <20A6B72E-323D-11D7-9775-000A956767EC@lbl.gov> X-Mailer: Apple Mail (2.551) X-archive-position: 1618 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bltierney@lbl.gov Precedence: bulk X-list: netdev Hi all: Can someone explain what situation the routine tcp_moderate_cwnd is supposed to address? Im finding that this code seems to be preventing TCP for achieving anything close to the available bandwidth on large BDP networks. Thanks. ---------------- /* CWND moderation, preventing bursts due to too big ACKs * in dubious situations. */ static __inline__ void tcp_moderate_cwnd(struct tcp_opt *tp) { u32 t = tcp_packets_in_flight(tp) + tcp_max_burst(tp); if (t < tp->snd_cwnd) { tp->snd_cwnd = t; WEB100_VAR_INC(tp, OtherReductions); } tp->snd_cwnd_stamp = tcp_time_stamp; } ------------------------------------------------------------------------ ------------------- Brian L. Tierney, Lawrence Berkeley National Laboratory (LBNL) 1 Cyclotron Rd. MS: 50B-2239, Berkeley, CA 94720 tel: 510-486-7381 fax: 510-495-2998 efax: 240-332-4065 bltierney@lbl.gov http://www-didc.lbl.gov/~tierney ------------------------------------------------------------------------ ------------------ From weixl@caltech.edu Mon Jan 27 14:30:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Jan 2003 14:30:43 -0800 (PST) Received: from chamber.cco.caltech.edu (chamber.its.caltech.edu [131.215.48.55]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0RMUI3v003850 for ; Mon, 27 Jan 2003 14:30:19 -0800 Received: from weixl (sonata.caltech.edu [131.215.220.1]) by chamber.cco.caltech.edu (8.12.3/8.12.3) with ESMTP id h0RMbKA0002617; Mon, 27 Jan 2003 14:37:21 -0800 (PST) Message-ID: <001501c2c654$a395ef20$f5f2010a@weixl> From: "Xiaoliang \(David\) Wei" To: , "Brian Tierney" Cc: "Brian Tierney" References: <20A6B72E-323D-11D7-9775-000A956767EC@lbl.gov> Subject: Re: question on routine tcp_moderate_cwnd Date: Mon, 27 Jan 2003 14:37:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-archive-position: 1619 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: weixl@caltech.edu Precedence: bulk X-list: netdev Hi Brian, Here's my understanding (maybe not very correct): When Linux tries to exit fast_recovery / loss_recovery and go back to normal state, tcp_moderate_cwnd is applied to make sure that the cwnd would not increase too fast from the current packet rate (packet_in_flight). This is NOT effective during normal SlowStart/CongestionAvoid states and not necessarily hurt the performance. If this function is deleted, there may be a burst when Linux exit recovery. -David Xiaoliang (David) Wei Graduate Student in CS@Caltech http://www.cs.caltech.edu/~weixl ==================================================== ----- Original Message ----- From: "Brian Tierney" To: Cc: "Brian Tierney" Sent: Monday, January 27, 2003 1:20 PM Subject: question on routine tcp_moderate_cwnd > Hi all: > > Can someone explain what situation the routine tcp_moderate_cwnd is > supposed to address? > > Im finding that this code seems to be preventing TCP for achieving > anything close to the available bandwidth on large BDP networks. > > Thanks. > > ---------------- > > /* CWND moderation, preventing bursts due to too big ACKs > * in dubious situations. > */ > static __inline__ void tcp_moderate_cwnd(struct tcp_opt *tp) > { > u32 t = tcp_packets_in_flight(tp) + tcp_max_burst(tp); > if (t < tp->snd_cwnd) { > tp->snd_cwnd = t; > WEB100_VAR_INC(tp, OtherReductions); > } > tp->snd_cwnd_stamp = tcp_time_stamp; > } > > > > ------------------------------------------------------------------------ > ------------------- > Brian L. Tierney, Lawrence Berkeley National Laboratory (LBNL) > 1 Cyclotron Rd. MS: 50B-2239, Berkeley, CA 94720 > tel: 510-486-7381 fax: 510-495-2998 efax: 240-332-4065 > bltierney@lbl.gov http://www-didc.lbl.gov/~tierney > ------------------------------------------------------------------------ > ------------------ > > > From linux-netdev@gmane.org Wed Jan 29 14:35:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Jan 2003 14:35:11 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0TMZ33v022186 for ; Wed, 29 Jan 2003 14:35:05 -0800 Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18e0se-00015b-00 for ; Wed, 29 Jan 2003 23:40:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: netdev@oss.sgi.com Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18dm9u-00024M-00 for ; Wed, 29 Jan 2003 07:57:18 +0100 From: "Justin Edwards" Subject: Win98 connecting to Samba Date: Wed, 29 Jan 2003 17:59:55 +1000 Lines: 58 Message-ID: X-Complaints-To: usenet@main.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-archive-position: 1620 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: justin@cview.com.au Precedence: bulk X-list: netdev I've been trying to connect my windows 98 pc to my linux machine with no luck. I have 2 machines with the following details: Win98 192.168.1.1 Linux 192.168.1.2 I can ping both addresses from either end and can connect to both the linux and win98 machines from the linux pc using the smbclient command. The linux machine is sharing its homes directory. I can see the Linux machine name in my Network Neighborhood I am using the same names between linux and win98 and have set the smb.conf to use encryption. testparm appears ok. I have added my users using the smbpasswd command When I try net view from my W98 machine I see the computer: \\linux \\win98 If I try to "net view \\linux" I get the following nasty message: "Error 53: The computer name specified in the network path cannot be located. Make sure you are specifying the computer name correctly, or try again later when the remote computer is available." If I click on Spanky from Network Neighborhood I see: \\spanky not accessible. The computer or sharename could not be found. Make sure you typed it correctly, and try again. My smb.conf file is as follows [global] workgroup = server server string = linux server encrypt passwords = yes smb passwd fie = /etc/samba/smbpasswd [homes] comment = homes directory browseable = yes writable = yes I would be grateful for any help you could provide me. Regards Justin Edwards Justin@cview.com.au From jbooth@ccbill.com Wed Jan 29 17:44:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Jan 2003 17:45:03 -0800 (PST) Received: from corpmail.cwie.net (corpmail.cwie.net [63.214.164.17]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0U1iu3v024342 for ; Wed, 29 Jan 2003 17:44:56 -0800 Received: (qmail 24758 invoked by uid 507); 30 Jan 2003 01:52:04 -0000 Received: from jbooth@ccbill.com by corpmail.cwie.net by uid 510 with CWIE-scanner-1.15 (sweep: 2.10/3.64. spamassassin: 2.43. Clear:. Processed in 0.547154 secs); 30 Jan 2003 01:52:04 -0000 X-CWIE-Scanner-Mail-From: jbooth@ccbill.com via corpmail.cwie.net X-CWIE-Scanner-Rcpt-To: andrewm@uow.edu.au,linux-kernel@vger.kernel.org,netdev@oss.sgi.com X-CWIE-Scanner: 1.15 (Clear:. Processed in 0.547154 secs) Received: from unknown (HELO hwsys200225) (64.38.194.14) by corpmail.cwie.net with SMTP; 30 Jan 2003 01:52:04 -0000 From: "Justin Booth" To: "'Linux kernel mailing list'" Cc: "'Netdev mailing list'" , "'Andrew Morton'" Subject: High number of "carriers" Date: Wed, 29 Jan 2003 18:52:06 -0700 Message-ID: <001701c2c802$315a3380$6450000a@hwsys200225> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-archive-position: 1621 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbooth@ccbill.com Precedence: bulk X-list: netdev Hello, I have a problem with multiple machines that I have that have dual onboard nic's on them that come up as "3Com Corporation 3c982 Dual Port Server Cyclone" nics. The carrier counter seems to increase quite quickly at about 1354 carriers per 3030906 bytes. I was transferring a 13 gig backup when I noticed the carriers. I seem to be transferring at a rate of 1.7 Mb/sec. The 6506 that I am plugged into is reporting no errors or anything wrong with the lines at all. Mii-tool reports that it's running 100Mbit FD. Any help would be greatly appreciated, Thanks, Justin Booth System Information --------------- The kernel version is 2.4.20 with compiled in drivers , no kernel modules loaded, using the 3c59x driver. Eth0 is the only link that is live. mii-tool outputs: eth0: 100 Mbit, full duplex, link ok product info: vendor 00:10:5a, model 0 rev 0 basic mode: 100 Mbit, full duplex basic status: link ok capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control eth1: no link product info: vendor 00:10:5a, model 0 rev 0 basic mode: autonegotiation enabled basic status: no link capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control lspci -vx reports: 00:0f.0 Ethernet controller: 3Com Corporation 3c982 Dual Port Server Cyclone (rev 78) Subsystem: Tyan Computer: Unknown device 2462 Flags: bus master, medium devsel, latency 80, IRQ 18 I/O ports at 1c00 [size=128] Memory at f4003000 (32-bit, non-prefetchable) [size=128] Expansion ROM at [disabled] [size=128K] Capabilities: [dc] Power Management version 2 00: b7 10 05 98 17 00 10 02 78 00 00 02 10 50 00 00 10: 01 1c 00 00 00 30 00 f4 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 62 24 30: 00 00 00 00 dc 00 00 00 00 00 00 00 05 01 0a 0a 00:10.0 Ethernet controller: 3Com Corporation 3c982 Dual Port Server Cyclone (rev 78) Subsystem: Tyan Computer: Unknown device 2462 Flags: bus master, medium devsel, latency 80, IRQ 19 I/O ports at 1c80 [size=128] Memory at f4003400 (32-bit, non-prefetchable) [size=128] Expansion ROM at [disabled] [size=128K] Capabilities: [dc] Power Management version 2 00: b7 10 05 98 17 00 10 02 78 00 00 02 10 50 00 00 10: 81 1c 00 00 00 34 00 f4 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 62 24 30: 00 00 00 00 dc 00 00 00 00 00 00 00 03 01 0a 0a ifconfig eth0: eth0 Link encap:Ethernet HWaddr 00:E0:81:03:E2:D5 inet addr:xx.xx.xx.xx Bcast:xx.xx.xx.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:972257412 errors:0 dropped:0 overruns:0 frame:0 TX packets:360108756 errors:0 dropped:0 overruns:0 carrier:68929308 collisions:0 txqueuelen:100 RX bytes:776134149 (740.1 Mb) TX bytes:1464990605 (1397.1 Mb) Interrupt:18 Base address:0x1c00 From greearb@candelatech.com Wed Jan 29 18:18:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Jan 2003 18:18:21 -0800 (PST) Received: from grok.yi.org (IDENT:OKHg4k7pHfmh4T7QR3KXX/qjRXcVgEW+@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0U2IC3v025077 for ; Wed, 29 Jan 2003 18:18:13 -0800 Received: from candelatech.com (IDENT:IKtTI6naYrbQmlQEfm2c9Ty/cwL98QJ8@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id h0U2PT415857 for ; Wed, 29 Jan 2003 18:25:30 -0800 Message-ID: <3E388D19.4000004@candelatech.com> Date: Wed, 29 Jan 2003 18:25:29 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'netdev@oss.sgi.com'" Subject: Why was the /proc info removed from e1000 ? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1622 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev I just noticed in the latest changelog that the /proc support was removed from the e1000 driver? I always found this usefull...any reason why it was deleted? -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From dubaicvmarketing@dcvm.com Thu Jan 30 03:45:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Jan 2003 03:45:46 -0800 (PST) Received: from oss.sgi.com ([213.132.35.74]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UBjZ3v004970 for ; Thu, 30 Jan 2003 03:45:37 -0800 From: "DCVM.com DUBAI" Date: Thu, 30 Jan 2003 15:52:36 To: netdev@oss.sgi.com Subject: EXCELLENT CAREER OPPORTUNITIES IN DUBAI MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_MEFUFTOABC" Content-Transfer-Encoding: 7bit Message-ID: PM20003:52:36 PM X-archive-position: 1623 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dubaicvmarketing@dcvm.com Precedence: bulk X-list: netdev This is an HTML email message. If you see this, your mail client does not support HTML messages. ------=_NextPart_MEFUFTOABC Content-Type: text/html;charset="iso-8859-1" Content-Transfer-Encoding: 7bit

------=_NextPart_MEFUFTOABC-- From markzzzsmith@ozemail.com.au Thu Jan 30 05:48:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Jan 2003 05:48:44 -0800 (PST) Received: from mail.nosense.org (1Cust253.tnt4.adl1.da.uu.net [63.34.231.253]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UDmV3v007928 for ; Thu, 30 Jan 2003 05:48:34 -0800 Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 68BAF3B2F5; Fri, 31 Jan 2003 00:25:19 +1030 (CST) Subject: [PATCH] 802.3x / ETHTOOL Pause frame support for natsemi.c (netgear fa311/fa312 + ns83816) From: Mark Smith To: Mark Smith Cc: thockin@hockin.org, netdev@oss.sgi.com In-Reply-To: <1043583669.1774.22.camel@dupy> References: <1043583669.1774.22.camel@dupy> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 31 Jan 2003 00:25:19 +1030 Message-Id: <1043934941.848.21.camel@dupy> Mime-Version: 1.0 X-archive-position: 1624 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: markzzzsmith@ozemail.com.au Precedence: bulk X-list: netdev Hi Tim, All, Isn't it always the way ? Downloaded the new version of the natsemi NS83815.pdf file (dated Sep 2002), and the message about the 83815 (used on the Netgear Fa311 / Fa312 cards) not supporting ethernet pause frames has disappeared. Looks like a bug in the old doco rather than the hardware. Here is the updated patch, with the check for the NS83816 chip removed. It applies to natsemi.c version 1.0.17, which is contained in both versions 2.4.20 and 2.5.56 of the linux kernel. I'm hoping other people can help me test it, I'd appreciate bug reports, suggestions and other constructive criticism. I've put the patch here http://www.nosense.org/natsemi.c.ethpause.1.1.diff just in case attaching it to my last email was a bit rude (I didn't think a 5 KB email was too big, my appologies if it was). Thanks, Mark. On Sun, 2003-01-26 at 22:51, Mark Smith wrote: > Hi Tim, * > > I've put together the following patch to enable 802.3x ethernet pause > frame support, including the ethtool pause options, on the natsemi 83816 > based network cards. > > I've tested it on my 83815 based Netgear FA312 card, which does have all > the required registers, but according to page 69 of the NS83815.pdf > document, the pause feature is not supported. I added the check for > 83816 chips just as the final step before posting it. > > I haven't done any kernel level programming before, so I'd appreciate > any suggestions or improvements I can make to it. > > The patch is against natsemi.c version 1.0.17. > > Thanks, > Mark. > From scott.feldman@intel.com Thu Jan 30 08:19:10 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Jan 2003 08:19:14 -0800 (PST) Received: from hermes.py.intel.com (hermes.py.intel.com [146.152.216.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UGJ93v012568 for ; Thu, 30 Jan 2003 08:19:10 -0800 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h0UGMid11085 for ; Thu, 30 Jan 2003 16:22:44 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.py.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h0UGPDJ27100 for ; Thu, 30 Jan 2003 16:25:14 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003013008241419253 ; Thu, 30 Jan 2003 08:24:14 -0800 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Jan 2003 08:26:17 -0800 Message-ID: From: "Feldman, Scott" To: Ben Greear , netdev@oss.sgi.com Subject: RE: Why was the /proc info removed from e1000 ? Date: Thu, 30 Jan 2003 08:26:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" X-archive-position: 1625 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev > I just noticed in the latest changelog that the /proc > support was removed from the e1000 driver? I always > found this usefull...any reason why it was deleted? Because the information that was exported to /proc is available through standard interfaces such as ethtool, pciutils, etc. ethtool -i eth associates eth with PCI bus:dev.func, so you should be able to find what you need starting there. Also note that ethtool -S support was added for netdev stats. If you find something missing, let's talk about an alternative. -scott From linux-netdev@gmane.org Thu Jan 30 08:24:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Jan 2003 08:24:06 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UGO23v013482 for ; Thu, 30 Jan 2003 08:24:04 -0800 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18eHZB-00078q-00 for ; Thu, 30 Jan 2003 17:29:29 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: netdev@oss.sgi.com Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18eHZ8-00078D-00 for ; Thu, 30 Jan 2003 17:29:26 +0100 From: Jason Lunz Subject: Re: Why was the /proc info removed from e1000 ? Date: Thu, 30 Jan 2003 16:29:25 +0000 (UTC) Organization: PBR Streetgang Lines: 10 Message-ID: References: <3E388D19.4000004@candelatech.com> X-Complaints-To: usenet@main.gmane.org User-Agent: slrn/0.9.7.4 (Linux) X-archive-position: 1626 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lunz@falooley.org Precedence: bulk X-list: netdev greearb@candelatech.com said: > I just noticed in the latest changelog that the /proc support was > removed from the e1000 driver? I always found this usefull...any > reason why it was deleted? shortly lower in the changelog, you'll see that the same stats are now availble using the standard ethtool interface. I don't know whether you need a new ethtool to make sense of the e1000 stats struct. Jason From greearb@candelatech.com Thu Jan 30 08:43:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Jan 2003 08:43:57 -0800 (PST) Received: from grok.yi.org (IDENT:tWpqhlVOVsfTmAzK4Xe87kPnMDlCfHSs@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UGhs3v015463 for ; Thu, 30 Jan 2003 08:43:55 -0800 Received: from candelatech.com (IDENT:TOO9tz1f6yRNRbaP986dw7kblbYw1hny@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id h0UGp6422314; Thu, 30 Jan 2003 08:51:06 -0800 Message-ID: <3E3957FA.6050500@candelatech.com> Date: Thu, 30 Jan 2003 08:51:06 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jason Lunz CC: netdev@oss.sgi.com Subject: Re: Why was the /proc info removed from e1000 ? References: <3E388D19.4000004@candelatech.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1627 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Jason Lunz wrote: > greearb@candelatech.com said: > >>I just noticed in the latest changelog that the /proc support was >>removed from the e1000 driver? I always found this usefull...any >>reason why it was deleted? > > > shortly lower in the changelog, you'll see that the same stats are now > availble using the standard ethtool interface. I don't know whether you > need a new ethtool to make sense of the e1000 stats struct. > > Jason It was nice to not have to have to dredge up the latest ethtool binary in order to see the pretty stats. However, I am glad to see more stuff supported by the ethtool interface. Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From jmorris@intercode.com.au Thu Jan 30 14:38:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Jan 2003 14:38:26 -0800 (PST) Received: from blackbird.intercode.com.au (blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UMcG3v021050 for ; Thu, 30 Jan 2003 14:38:18 -0800 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id JAA31494; Fri, 31 Jan 2003 09:42:25 +1100 Date: Fri, 31 Jan 2003 09:42:24 +1100 (EST) From: James Morris To: "David S. Miller" , cc: netdev@oss.sgi.com, Subject: [PATCH] LSM networking: introduction (0/8) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1628 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@intercode.com.au Precedence: bulk X-list: netdev Following this email will be the LSM (Linux Security Modules) networking code split up into eight patches for submission to the mainline kernel. Since the last submission of these patches, improvements have been made to the LSM code based on feedback from maintainers and the community. The LSM hooks are now implemented as static inlines in the main kernel, and may be compiled out, while the LSM networking code is now generally configurable via CONFIG_SECURITY_NETWORK. This work was done by Stephen Smalley. The configuration exceptions are the two Netlink hooks and the ip_decode_options() hook, which always need to be present as they implement default capabilities logic. The rest of the hooks disappear when not enabled. Cumulative summary: include/linux/ip.h | 1 include/linux/netdevice.h | 4 include/linux/security.h | 807 +++++++++++++++++++++++++++++++++++++++++- include/linux/skbuff.h | 3 include/linux/tcp.h | 11 include/net/sock.h | 16 include/net/tcp.h | 26 + net/core/datagram.c | 5 net/core/dev.c | 3 net/core/rtnetlink.c | 3 net/core/skbuff.c | 16 net/core/sock.c | 6 net/ipv4/ah.c | 2 net/ipv4/ip_fragment.c | 7 net/ipv4/ip_gre.c | 3 net/ipv4/ip_options.c | 5 net/ipv4/ip_output.c | 3 net/ipv4/ipip.c | 4 net/ipv4/ipmr.c | 4 net/ipv4/netfilter/ip_queue.c | 3 net/ipv4/syncookies.c | 3 net/ipv4/tcp_ipv4.c | 8 net/ipv4/tcp_minisocks.c | 6 net/netlink/af_netlink.c | 8 net/socket.c | 72 +++ net/unix/af_unix.c | 16 security/Kconfig | 9 security/capability.c | 30 + security/dummy.c | 267 +++++++++++++ 29 files changed, 1334 insertions(+), 17 deletions(-) (Note that more information on LSM can be found at http://lsm.immunix.org/). - James -- James Morris From jmorris@intercode.com.au Thu Jan 30 14:42:47 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Jan 2003 14:42:54 -0800 (PST) Received: from blackbird.intercode.com.au (blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UMgi3v021479 for ; Thu, 30 Jan 2003 14:42:46 -0800 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id JAA31553; Fri, 31 Jan 2003 09:46:56 +1100 Date: Fri, 31 Jan 2003 09:46:56 +1100 (EST) From: James Morris To: "David S. Miller" , cc: netdev@oss.sgi.com, Subject: [PATCH] LSM networking: kconfig (1/8) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1629 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@intercode.com.au Precedence: bulk X-list: netdev Kconfig | 9 +++++++++ 1 files changed, 9 insertions(+) diff -urN -X dontdiff linux-2.5.59.w0/security/Kconfig linux-2.5.59.w1/security/Kconfig --- linux-2.5.59.w0/security/Kconfig Tue Dec 24 23:31:09 2002 +++ linux-2.5.59.w1/security/Kconfig Thu Jan 30 21:18:42 2003 @@ -15,6 +15,15 @@ If you are unsure how to answer this question, answer N. +config SECURITY_NETWORK + bool "Socket and Networking Security Hooks" + depends on SECURITY + help + This enables the socket and networking security hooks. + If enabled, a security module can use these hooks to + implement socket and networking access controls. + If you are unsure how to answer this question, answer N. + config SECURITY_CAPABILITIES tristate "Default Linux Capabilities" depends on SECURITY!=n From jmorris@intercode.com.au Thu Jan 30 14:47:47 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Jan 2003 14:47:54 -0800 (PST) Received: from blackbird.intercode.com.au (blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UMlh3v021963 for ; Thu, 30 Jan 2003 14:47:45 -0800 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id JAA31629; Fri, 31 Jan 2003 09:51:54 +1100 Date: Fri, 31 Jan 2003 09:51:54 +1100 (EST) From: James Morris To: "David S. Miller" , cc: netdev@oss.sgi.com, Subject: [PATCH] LSM networking: netdev hooks for 2.5.59 (2/8) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1630 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@intercode.com.au Precedence: bulk X-list: netdev include/linux/netdevice.h | 4 ++++ include/linux/security.h | 38 +++++++++++++++++++++++++++++++++++--- net/core/dev.c | 3 +++ security/dummy.c | 12 ++++++++++++ 4 files changed, 54 insertions(+), 3 deletions(-) diff -urN -X dontdiff linux-2.5.59.w0/include/linux/netdevice.h linux-2.5.59.w1/include/linux/netdevice.h --- linux-2.5.59.w0/include/linux/netdevice.h Fri Jan 17 19:46:08 2003 +++ linux-2.5.59.w1/include/linux/netdevice.h Thu Jan 30 21:23:47 2003 @@ -442,6 +442,10 @@ /* generic object representation */ struct kobject kobj; + +#ifdef CONFIG_SECURITY_NETWORK + void *security; +#endif }; diff -urN -X dontdiff linux-2.5.59.w0/include/linux/security.h linux-2.5.59.w1/include/linux/security.h --- linux-2.5.59.w0/include/linux/security.h Thu Jan 16 22:51:34 2003 +++ linux-2.5.59.w1/include/linux/security.h Thu Jan 30 21:26:28 2003 @@ -63,9 +63,6 @@ /* setfsuid or setfsgid, id0 == fsuid or fsgid */ #define LSM_SETID_FS 8 - -#ifdef CONFIG_SECURITY - /* forward declares to avoid warnings */ struct sk_buff; struct net_device; @@ -73,6 +70,9 @@ struct sched_param; struct swap_info_struct; + +#ifdef CONFIG_SECURITY + /** * struct security_operations - main security structure * @@ -586,6 +586,19 @@ * is being reparented to the init task. * @p contains the task_struct for the kernel thread. * + * Security hooks for network devices. + * @netdev_unregister: + * Update the module's state when a network device is unregistered, + * deallocating the dev->security field if it was previously allocated. + * @dev contains the network device + * + * These are the hooks for network device operations. Since it would be quite + * invasive to provide hooks in every location where a network device might be + * probed or initialized, there are no separate hooks for allocation or + * initialization. Security modules can allocate and initialize the + * dev->security field on the first access to the device, but should be careful + * to use nonblocking allocation. + * * Security hooks affecting all System V IPC operations. * * @ipc_permission: @@ -952,6 +965,10 @@ struct security_operations *ops); int (*unregister_security) (const char *name, struct security_operations *ops); + +#ifdef CONFIG_SECURITY_NETWORK + void (*netdev_unregister) (struct net_device * dev); +#endif /* CONFIG_SECURITY_NETWORK */ }; /* global variables */ @@ -2106,5 +2123,20 @@ #endif /* CONFIG_SECURITY */ +#ifdef CONFIG_SECURITY_NETWORK + +static inline void security_netdev_unregister(struct net_device * dev) +{ + security_ops->netdev_unregister(dev); +} + +#else /* CONFIG_SECURITY_NETWORK */ + +static inline void security_netdev_unregister(struct net_device * dev) +{ +} + +#endif /* CONFIG_SECURITY_NETWORK */ + #endif /* ! __LINUX_SECURITY_H */ diff -urN -X dontdiff linux-2.5.59.w0/net/core/dev.c linux-2.5.59.w1/net/core/dev.c --- linux-2.5.59.w0/net/core/dev.c Fri Jan 17 19:46:08 2003 +++ linux-2.5.59.w1/net/core/dev.c Thu Jan 30 21:23:47 2003 @@ -107,6 +107,7 @@ #include #include #include +#include #if defined(CONFIG_NET_RADIO) || defined(CONFIG_NET_PCMCIA_RADIO) #include /* Note : will define WIRELESS_EXT */ #include @@ -2680,6 +2681,8 @@ free_divert_blk(dev); #endif + security_netdev_unregister(dev); + if (dev->features & NETIF_F_DYNALLOC) { #ifdef NET_REFCNT_DEBUG if (atomic_read(&dev->refcnt) != 1) diff -urN -X dontdiff linux-2.5.59.w0/security/dummy.c linux-2.5.59.w1/security/dummy.c --- linux-2.5.59.w0/security/dummy.c Thu Jan 16 22:51:35 2003 +++ linux-2.5.59.w1/security/dummy.c Thu Jan 30 21:23:47 2003 @@ -597,6 +597,15 @@ return 0; } +#ifdef CONFIG_SECURITY_NETWORK + +static void dummy_netdev_unregister (struct net_device *dev) +{ + return; +} + +#endif /* CONFIG_SECURITY_NETWORK */ + static int dummy_register_security (const char *name, struct security_operations *ops) { return -EINVAL; @@ -725,5 +734,8 @@ set_to_dummy_if_null(ops, sem_semop); set_to_dummy_if_null(ops, register_security); set_to_dummy_if_null(ops, unregister_security); +#ifdef CONFIG_SECURITY_NETWORK + set_to_dummy_if_null(ops, netdev_unregister); +#endif /* CONFIG_SECURITY_NETWORK */ } From jmorris@intercode.com.au Thu Jan 30 14:52:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Jan 2003 14:52:36 -0800 (PST) Received: from blackbird.intercode.com.au (blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UMqO3v022423 for ; Thu, 30 Jan 2003 14:52:25 -0800 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id JAA31661; Fri, 31 Jan 2003 09:56:34 +1100 Date: Fri, 31 Jan 2003 09:56:34 +1100 (EST) From: James Morris To: "David S. Miller" , cc: netdev@oss.sgi.com, Subject: [PATCH] LSM networking: skb hooks for 2.5.59 (3/8) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1631 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@intercode.com.au Precedence: bulk X-list: netdev include/linux/security.h | 119 +++++++++++++++++++++++++++++++++++++++++++++++ include/linux/skbuff.h | 3 + include/net/sock.h | 2 net/core/datagram.c | 5 + net/core/skbuff.c | 16 ++++++ security/dummy.c | 39 +++++++++++++++ 6 files changed, 183 insertions(+), 1 deletion(-) diff -urN -X dontdiff linux-2.5.59.w0/include/linux/security.h linux-2.5.59.w1/include/linux/security.h --- linux-2.5.59.w0/include/linux/security.h Thu Jan 30 21:29:06 2003 +++ linux-2.5.59.w1/include/linux/security.h Thu Jan 30 21:29:32 2003 @@ -64,6 +64,7 @@ #define LSM_SETID_FS 8 /* forward declares to avoid warnings */ +struct sock; struct sk_buff; struct net_device; struct nfsctl_arg; @@ -586,6 +587,50 @@ * is being reparented to the init task. * @p contains the task_struct for the kernel thread. * + * Lifecycle hooks for network buffers. + * + * @skb_alloc_security: + * This hook is called by the &sk_buff allocator when a new buffer is + * being allocated. An LSM module may allocate and assign a new security + * blob for the &sk_buff via this hook. + * @skb contains the buffer being allocated. + * @gfp_mask contains the kernel allocation gfp_mask value. + * Return 0 if successful, or -ENOMEM on out of memory condition. + * @skb_clone: + * This hook is called when an &sk_buff is being cloned, and may be used, + * for example, to increment a reference count on the associated security + * blob. The security blob in the @newskb will not have been allocated. + * @newskb contains the newly cloned buffer. + * @oldskb contains the buffer being cloned. + * Returns 0 on success -ENOMEM on failure. + * @skb_copy: + * This hook is called when an &sk_buff header is being copied, which + * occurs during the skb_copy() and pskb_copy() functions in + * + * @newskb contains the newly copied buffer. + * @oldskb contains the buffer being copied. + * @skb_set_owner_w: + * This hook is called when the ownership of an &sk_buff is being assigned + * to a sending socket. Typically, this would be used to copy security + * attributes from the sending socket to the &sk_buff. + * @skb contains the buffer being owned. + * @sk contains sock to which ownership is being assigned. + * @skb_recv_datagram: + * This hook is called when a process is receiving a datagram + * message. At this point, there is an association between the + * current process, the socket, and the skb. + * @skb contains the buffer being returned. + * @sk is the receiving sock. + * @flags contains operational flags. + * @skb_free_security: + * This hook is called when an &sk_buff is being destroyed, and should be + * used to free any associated security blob. + * @skb contains the buffer being destroyed. + * + * These are the lifecycle hooks for network buffers. They are used to help + * manage the lifecycle of security blobs for &sk_buff structures, and are not + * intended to be used for access decisions. + * * Security hooks for network devices. * @netdev_unregister: * Update the module's state when a network device is unregistered, @@ -967,6 +1012,16 @@ struct security_operations *ops); #ifdef CONFIG_SECURITY_NETWORK + int (*skb_alloc_security) (struct sk_buff * skb, int gfp_mask); + int (*skb_clone) (struct sk_buff * newskb, + const struct sk_buff * oldskb); + void (*skb_copy) (struct sk_buff * newskb, + const struct sk_buff * oldskb); + void (*skb_set_owner_w) (struct sk_buff * skb, struct sock * sk); + void (*skb_recv_datagram) (struct sk_buff * skb, struct sock * sk, + unsigned flags); + void (*skb_free_security) (struct sk_buff * skb); + void (*netdev_unregister) (struct net_device * dev); #endif /* CONFIG_SECURITY_NETWORK */ }; @@ -2125,6 +2180,40 @@ #ifdef CONFIG_SECURITY_NETWORK +static inline int security_skb_alloc(struct sk_buff * skb, int gfp_mask) +{ + return security_ops->skb_alloc_security(skb, gfp_mask); +} + +static inline int security_skb_clone(struct sk_buff * newskb, + const struct sk_buff * oldskb) +{ + return security_ops->skb_clone(newskb, oldskb); +} + +static inline void security_skb_copy(struct sk_buff * newskb, + const struct sk_buff * oldskb) +{ + security_ops->skb_copy(newskb, oldskb); +} + +static inline void security_skb_set_owner_w (struct sk_buff * skb, + struct sock * sk) +{ + security_ops->skb_set_owner_w (skb, sk); +} + +static inline void security_skb_recv_datagram(struct sk_buff * skb, + struct sock * sk, unsigned flags) +{ + security_ops->skb_recv_datagram(skb, sk, flags); +} + +static inline void security_skb_free(struct sk_buff * skb) +{ + security_ops->skb_free_security(skb); +} + static inline void security_netdev_unregister(struct net_device * dev) { security_ops->netdev_unregister(dev); @@ -2132,6 +2221,36 @@ #else /* CONFIG_SECURITY_NETWORK */ +static inline int security_skb_alloc(struct sk_buff * skb, int gfp_mask) +{ + return 0; +} + +static inline int security_skb_clone(struct sk_buff * newskb, + const struct sk_buff * oldskb) +{ + return 0; +} + +static inline void security_skb_copy(struct sk_buff * newskb, + const struct sk_buff * oldskb) +{ +} + +static inline void security_skb_set_owner_w (struct sk_buff * skb, + struct sock * sk) +{ +} + +static inline void security_skb_recv_datagram(struct sk_buff * skb, + struct sock * sk, unsigned flags) +{ +} + +static inline void security_skb_free(struct sk_buff * skb) +{ +} + static inline void security_netdev_unregister(struct net_device * dev) { } diff -urN -X dontdiff linux-2.5.59.w0/include/linux/skbuff.h linux-2.5.59.w1/include/linux/skbuff.h --- linux-2.5.59.w0/include/linux/skbuff.h Thu Jan 16 22:51:34 2003 +++ linux-2.5.59.w1/include/linux/skbuff.h Thu Jan 30 21:29:32 2003 @@ -261,6 +261,9 @@ #ifdef CONFIG_NET_SCHED __u32 tc_index; /* traffic control index */ #endif +#ifdef CONFIG_SECURITY_NETWORK + void *lsm_security; /* replaces the above security field */ +#endif }; #define SK_WMEM_MAX 65535 diff -urN -X dontdiff linux-2.5.59.w0/include/net/sock.h linux-2.5.59.w1/include/net/sock.h --- linux-2.5.59.w0/include/net/sock.h Mon Nov 18 23:56:19 2002 +++ linux-2.5.59.w1/include/net/sock.h Thu Jan 30 21:29:33 2003 @@ -44,6 +44,7 @@ #include #include /* struct sk_buff */ +#include #ifdef CONFIG_FILTER #include @@ -700,6 +701,7 @@ sock_hold(sk); skb->sk = sk; skb->destructor = sock_wfree; + security_skb_set_owner_w(skb, sk); atomic_add(skb->truesize, &sk->wmem_alloc); } diff -urN -X dontdiff linux-2.5.59.w0/net/core/datagram.c linux-2.5.59.w1/net/core/datagram.c --- linux-2.5.59.w0/net/core/datagram.c Sun Aug 11 12:20:40 2002 +++ linux-2.5.59.w1/net/core/datagram.c Thu Jan 30 21:29:33 2003 @@ -47,6 +47,7 @@ #include #include #include +#include #include #include @@ -176,8 +177,10 @@ } else skb = skb_dequeue(&sk->receive_queue); - if (skb) + if (skb) { + security_skb_recv_datagram(skb, sk, flags); return skb; + } /* User doesn't want to wait */ error = -EAGAIN; diff -urN -X dontdiff linux-2.5.59.w0/net/core/skbuff.c linux-2.5.59.w1/net/core/skbuff.c --- linux-2.5.59.w0/net/core/skbuff.c Thu Jan 16 22:51:35 2003 +++ linux-2.5.59.w1/net/core/skbuff.c Thu Jan 30 21:29:33 2003 @@ -53,6 +53,7 @@ #include #include #include +#include #include #include @@ -195,6 +196,11 @@ if (!data) goto nodata; + if (security_skb_alloc(skb, gfp_mask)) { + kfree(data); + goto nodata; + } + /* XXX: does not include slab overhead */ skb->truesize = size + sizeof(struct sk_buff); @@ -257,6 +263,9 @@ #ifdef CONFIG_NET_SCHED skb->tc_index = 0; #endif +#ifdef CONFIG_SECURITY_NETWORK + skb->lsm_security = NULL; +#endif } static void skb_drop_fraglist(struct sk_buff *skb) @@ -339,6 +348,7 @@ nf_bridge_put(skb->nf_bridge); #endif #endif + security_skb_free(skb); skb_headerinit(skb, NULL, 0); /* clean state */ kfree_skbmem(skb); } @@ -366,6 +376,11 @@ if (!n) return NULL; } + + if (security_skb_clone(n, skb)) { + skb_head_to_pool(n); + return NULL; + } #define C(x) n->x = skb->x @@ -470,6 +485,7 @@ #ifdef CONFIG_NET_SCHED new->tc_index = old->tc_index; #endif + security_skb_copy(new, old); } /** diff -urN -X dontdiff linux-2.5.59.w0/security/dummy.c linux-2.5.59.w1/security/dummy.c --- linux-2.5.59.w0/security/dummy.c Thu Jan 30 21:29:06 2003 +++ linux-2.5.59.w1/security/dummy.c Thu Jan 30 21:29:33 2003 @@ -599,6 +599,39 @@ #ifdef CONFIG_SECURITY_NETWORK +static int dummy_skb_alloc_security (struct sk_buff *skb, int gfp_mask) +{ + return 0; +} + +static int dummy_skb_clone (struct sk_buff *newskb, + const struct sk_buff *oldskb) +{ + return 0; +} + +static void dummy_skb_copy (struct sk_buff *newskb, + const struct sk_buff *oldskb) +{ + return; +} + +static void dummy_skb_set_owner_w (struct sk_buff *skb, struct sock *sk) +{ + return; +} + +static void dummy_skb_recv_datagram (struct sk_buff *skb, struct sock *sk, + unsigned flags) +{ + return; +} + +static void dummy_skb_free_security (struct sk_buff *skb) +{ + return; +} + static void dummy_netdev_unregister (struct net_device *dev) { return; @@ -735,6 +768,12 @@ set_to_dummy_if_null(ops, register_security); set_to_dummy_if_null(ops, unregister_security); #ifdef CONFIG_SECURITY_NETWORK + set_to_dummy_if_null(ops, skb_alloc_security); + set_to_dummy_if_null(ops, skb_clone); + set_to_dummy_if_null(ops, skb_copy); + set_to_dummy_if_null(ops, skb_set_owner_w); + set_to_dummy_if_null(ops, skb_recv_datagram); + set_to_dummy_if_null(ops, skb_free_security); set_to_dummy_if_null(ops, netdev_unregister); #endif /* CONFIG_SECURITY_NETWORK */ } From jmorris@intercode.com.au Thu Jan 30 14:57:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Jan 2003 14:57:38 -0800 (PST) Received: from blackbird.intercode.com.au (blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UMvP3v022897 for ; Thu, 30 Jan 2003 14:57:26 -0800 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id KAA31692; Fri, 31 Jan 2003 10:01:34 +1100 Date: Fri, 31 Jan 2003 10:01:34 +1100 (EST) From: James Morris To: "David S. Miller" , cc: netdev@oss.sgi.com, Subject: [PATCH] LSM networking: socket hooks for 2.5.59 (4/8) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1632 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@intercode.com.au Precedence: bulk X-list: netdev include/linux/security.h | 346 +++++++++++++++++++++++++++++++++++++++++++++++ include/net/sock.h | 14 + net/core/sock.c | 6 net/ipv4/tcp_ipv4.c | 4 net/socket.c | 72 +++++++++ security/dummy.c | 111 ++++++++++++++- 6 files changed, 549 insertions(+), 4 deletions(-) diff -urN -X dontdiff linux-2.5.59.w0/include/linux/security.h linux-2.5.59.w1/include/linux/security.h --- linux-2.5.59.w0/include/linux/security.h Thu Jan 30 21:31:15 2003 +++ linux-2.5.59.w1/include/linux/security.h Thu Jan 30 21:31:32 2003 @@ -65,6 +65,9 @@ /* forward declares to avoid warnings */ struct sock; +struct socket; +struct sockaddr; +struct msghdr; struct sk_buff; struct net_device; struct nfsctl_arg; @@ -587,6 +590,126 @@ * is being reparented to the init task. * @p contains the task_struct for the kernel thread. * + * Security hooks for socket operations. + * + * @socket_create: + * Check permissions prior to creating a new socket. + * @family contains the requested protocol family. + * @type contains the requested communications type. + * @protocol contains the requested protocol. + * Return 0 if permission is granted. + * @socket_post_create: + * This hook allows a module to update or allocate a per-socket security + * structure. Note that the security field was not added directly to the + * socket structure, but rather, the socket security information is stored + * in the associated inode. Typically, the inode alloc_security hook will + * allocate and and attach security information to + * sock->inode->i_security. This hook may be used to update the + * sock->inode->i_security field with additional information that wasn't + * available when the inode was allocated. + * @sock contains the newly created socket structure. + * @family contains the requested protocol family. + * @type contains the requested communications type. + * @protocol contains the requested protocol. + * @socket_bind: + * Check permission before socket protocol layer bind operation is + * performed and the socket @sock is bound to the address specified in the + * @address parameter. + * @sock contains the socket structure. + * @address contains the address to bind to. + * @addrlen contains the length of address. + * Return 0 if permission is granted. + * @socket_connect: + * Check permission before socket protocol layer connect operation + * attempts to connect socket @sock to a remote address, @address. + * @sock contains the socket structure. + * @address contains the address of remote endpoint. + * @addrlen contains the length of address. + * Return 0 if permission is granted. + * @socket_listen: + * Check permission before socket protocol layer listen operation. + * @sock contains the socket structure. + * @backlog contains the maximum length for the pending connection queue. + * Return 0 if permission is granted. + * @socket_accept: + * Check permission before accepting a new connection. Note that the new + * socket, @newsock, has been created and some information copied to it, + * but the accept operation has not actually been performed. + * @sock contains the listening socket structure. + * @newsock contains the newly created server socket for connection. + * Return 0 if permission is granted. + * @socket_post_accept: + * This hook allows a security module to copy security + * information into the newly created socket's inode. + * @sock contains the listening socket structure. + * @newsock contains the newly created server socket for connection. + * @socket_sendmsg: + * Check permission before transmitting a message to another socket. + * @sock contains the socket structure. + * @msg contains the message to be transmitted. + * @size contains the size of message. + * Return 0 if permission is granted. + * @socket_recvmsg: + * Check permission before receiving a message from a socket. + * @sock contains the socket structure. + * @msg contains the message structure. + * @size contains the size of message structure. + * @flags contains the operational flags. + * Return 0 if permission is granted. + * @socket_getsockname: + * Check permission before the local address (name) of the socket object + * @sock is retrieved. + * @sock contains the socket structure. + * Return 0 if permission is granted. + * @socket_getpeername: + * Check permission before the remote address (name) of a socket object + * @sock is retrieved. + * @sock contains the socket structure. + * Return 0 if permission is granted. + * @socket_getsockopt: + * Check permissions before retrieving the options associated with socket + * @sock. + * @sock contains the socket structure. + * @level contains the protocol level to retrieve option from. + * @optname contains the name of option to retrieve. + * Return 0 if permission is granted. + * @socket_setsockopt: + * Check permissions before setting the options associated with socket + * @sock. + * @sock contains the socket structure. + * @level contains the protocol level to set options for. + * @optname contains the name of the option to set. + * Return 0 if permission is granted. + * @socket_shutdown: + * Checks permission before all or part of a connection on the socket + * @sock is shut down. + * @sock contains the socket structure. + * @how contains the flag indicating how future sends and receives are handled. + * Return 0 if permission is granted. + * @socket_sock_alloc_security: + * @sk contains the sock structure. + * @gfp_mask contains the kernel allocation gfp_mask value. + * Allocate and attach a security structure to @sk->security. The + * security field is initialized to NULL when the sock structure is + * allocated. + * Return 0 if operation was successful. + * @socket_sock_free_security: + * @sk contains the sock structure. + * Deallocate and clear the sk->security field. + * @socket_sock_rcv_skb: + * Check permissions on incoming network packets. This hook is distinct + * from the network input hooks of ip_security_ops since it is the first + * time that the incoming sk_buff @skb has been associated with a + * particular socket, @sk. Security modules should not try to dereference + * @sk->socket if the socket is in a time wait state + * (@sk->state == TCP_TIME_WAIT), since the @sk refers to a tcp_tw_bucket + * structure in that case. Also, even if the socket is not in this state, + * @sk->socket may be NULL, e.g. a newly created server socket for a + * connection that has not yet been accepted by a process. + * @sk contains the sock (not socket) associated with the incoming sk_buff. + * @skb contains the incoming network data. + * Return 0 if permission is granted. + * * Lifecycle hooks for network buffers. * * @skb_alloc_security: @@ -1012,6 +1135,30 @@ struct security_operations *ops); #ifdef CONFIG_SECURITY_NETWORK + int (*socket_create) (int family, int type, int protocol); + void (*socket_post_create) (struct socket * sock, int family, + int type, int protocol); + int (*socket_bind) (struct socket * sock, + struct sockaddr * address, int addrlen); + int (*socket_connect) (struct socket * sock, + struct sockaddr * address, int addrlen); + int (*socket_listen) (struct socket * sock, int backlog); + int (*socket_accept) (struct socket * sock, struct socket * newsock); + void (*socket_post_accept) (struct socket * sock, + struct socket * newsock); + int (*socket_sendmsg) (struct socket * sock, + struct msghdr * msg, int size); + int (*socket_recvmsg) (struct socket * sock, + struct msghdr * msg, int size, int flags); + int (*socket_getsockname) (struct socket * sock); + int (*socket_getpeername) (struct socket * sock); + int (*socket_getsockopt) (struct socket * sock, int level, int optname); + int (*socket_setsockopt) (struct socket * sock, int level, int optname); + int (*socket_shutdown) (struct socket * sock, int how); + int (*socket_sock_alloc_security) (struct sock * sk, int gfp_mask); + void (*socket_sock_free_security) (struct sock * sk); + int (*socket_sock_rcv_skb) (struct sock * sk, struct sk_buff * skb); + int (*skb_alloc_security) (struct sk_buff * skb, int gfp_mask); int (*skb_clone) (struct sk_buff * newskb, const struct sk_buff * oldskb); @@ -2180,6 +2327,107 @@ #ifdef CONFIG_SECURITY_NETWORK +static inline int security_socket_create (int family, int type, int protocol) +{ + return security_ops->socket_create(family, type, protocol); +} + +static inline void security_socket_post_create(struct socket * sock, + int family, + int type, + int protocol) +{ + security_ops->socket_post_create(sock, family, type, protocol); +} + +static inline int security_socket_bind(struct socket * sock, + struct sockaddr * address, + int addrlen) +{ + return security_ops->socket_bind(sock, address, addrlen); +} + +static inline int security_socket_connect(struct socket * sock, + struct sockaddr * address, + int addrlen) +{ + return security_ops->socket_connect(sock, address, addrlen); +} + +static inline int security_socket_listen(struct socket * sock, int backlog) +{ + return security_ops->socket_listen(sock, backlog); +} + +static inline int security_socket_accept(struct socket * sock, + struct socket * newsock) +{ + return security_ops->socket_accept(sock, newsock); +} + +static inline void security_socket_post_accept(struct socket * sock, + struct socket * newsock) +{ + security_ops->socket_post_accept(sock, newsock); +} + +static inline int security_socket_sendmsg(struct socket * sock, + struct msghdr * msg, int size) +{ + return security_ops->socket_sendmsg(sock, msg, size); +} + +static inline int security_socket_recvmsg(struct socket * sock, + struct msghdr * msg, int size, + int flags) +{ + return security_ops->socket_recvmsg(sock, msg, size, flags); +} + +static inline int security_socket_getsockname(struct socket * sock) +{ + return security_ops->socket_getsockname(sock); +} + +static inline int security_socket_getpeername(struct socket * sock) +{ + return security_ops->socket_getpeername(sock); +} + +static inline int security_socket_getsockopt(struct socket * sock, + int level, int optname) +{ + return security_ops->socket_getsockopt(sock, level, optname); +} + +static inline int security_socket_setsockopt(struct socket * sock, + int level, int optname) +{ + return security_ops->socket_setsockopt(sock, level, optname); +} + +static inline int security_socket_shutdown(struct socket * sock, int how) +{ + return security_ops->socket_shutdown(sock, how); +} + +static inline int security_sock_alloc(struct sock * sk, + int gfp_mask) +{ + return security_ops->socket_sock_alloc_security(sk, gfp_mask); +} + +static inline void security_sock_free(struct sock * sk) +{ + security_ops->socket_sock_free_security(sk); +} + +static inline int security_sock_rcv_skb (struct sock * sk, + struct sk_buff * skb) +{ + return security_ops->socket_sock_rcv_skb (sk, skb); +} + static inline int security_skb_alloc(struct sk_buff * skb, int gfp_mask) { return security_ops->skb_alloc_security(skb, gfp_mask); @@ -2221,6 +2469,104 @@ #else /* CONFIG_SECURITY_NETWORK */ +static inline int security_socket_create (int family, int type, int protocol) +{ + return 0; +} + +static inline void security_socket_post_create(struct socket * sock, + int family, + int type, + int protocol) +{ +} + +static inline int security_socket_bind(struct socket * sock, + struct sockaddr * address, + int addrlen) +{ + return 0; +} + +static inline int security_socket_connect(struct socket * sock, + struct sockaddr * address, + int addrlen) +{ + return 0; +} + +static inline int security_socket_listen(struct socket * sock, int backlog) +{ + return 0; +} + +static inline int security_socket_accept(struct socket * sock, + struct socket * newsock) +{ + return 0; +} + +static inline void security_socket_post_accept(struct socket * sock, + struct socket * newsock) +{ +} + +static inline int security_socket_sendmsg(struct socket * sock, + struct msghdr * msg, int size) +{ + return 0; +} + +static inline int security_socket_recvmsg(struct socket * sock, + struct msghdr * msg, int size, + int flags) +{ + return 0; +} + +static inline int security_socket_getsockname(struct socket * sock) +{ + return 0; +} + +static inline int security_socket_getpeername(struct socket * sock) +{ + return 0; +} + +static inline int security_socket_getsockopt(struct socket * sock, + int level, int optname) +{ + return 0; +} + +static inline int security_socket_setsockopt(struct socket * sock, + int level, int optname) +{ + return 0; +} + +static inline int security_socket_shutdown(struct socket * sock, int how) +{ + return 0; +} + +static inline int security_sock_alloc(struct sock * sk, + int gfp_mask) +{ + return 0; +} + +static inline void security_sock_free(struct sock * sk) +{ +} + +static inline int security_sock_rcv_skb (struct sock * sk, + struct sk_buff * skb) +{ + return 0; +} + static inline int security_skb_alloc(struct sk_buff * skb, int gfp_mask) { return 0; diff -urN -X dontdiff linux-2.5.59.w0/include/net/sock.h linux-2.5.59.w1/include/net/sock.h --- linux-2.5.59.w0/include/net/sock.h Thu Jan 30 21:31:15 2003 +++ linux-2.5.59.w1/include/net/sock.h Thu Jan 30 21:31:32 2003 @@ -197,7 +197,12 @@ /* RPC layer private data */ void *user_data; - + +#ifdef CONFIG_SECURITY_NETWORK + /* LSM security field */ + void *security; +#endif + /* Callbacks */ void (*state_change)(struct sock *sk); void (*data_ready)(struct sock *sk,int bytes); @@ -714,15 +719,20 @@ static inline int sock_queue_rcv_skb(struct sock *sk, struct sk_buff *skb) { + int err = 0; + /* Cast skb->rcvbuf to unsigned... It's pointless, but reduces number of warnings when compiling with -W --ANK */ if (atomic_read(&sk->rmem_alloc) + skb->truesize >= (unsigned)sk->rcvbuf) return -ENOMEM; + err = security_sock_rcv_skb(sk, skb); + if (err) + return err; + #ifdef CONFIG_FILTER if (sk->filter) { - int err = 0; struct sk_filter *filter; /* It would be deadlock, if sock_queue_rcv_skb is used diff -urN -X dontdiff linux-2.5.59.w0/net/core/sock.c linux-2.5.59.w1/net/core/sock.c --- linux-2.5.59.w0/net/core/sock.c Sat Oct 19 19:57:49 2002 +++ linux-2.5.59.w1/net/core/sock.c Thu Jan 30 21:31:32 2003 @@ -109,6 +109,7 @@ #include #include #include +#include #include #include @@ -600,6 +601,10 @@ sk->family = family; sock_lock_init(sk); } + if (security_sock_alloc(sk, priority)) { + kmem_cache_free(slab, sk); + return NULL; + } sk->slab = slab; } @@ -626,6 +631,7 @@ if (atomic_read(&sk->omem_alloc)) printk(KERN_DEBUG "sk_free: optmem leakage (%d bytes) detected.\n", atomic_read(&sk->omem_alloc)); + security_sock_free(sk); kmem_cache_free(sk->slab, sk); } diff -urN -X dontdiff linux-2.5.59.w0/net/ipv4/tcp_ipv4.c linux-2.5.59.w1/net/ipv4/tcp_ipv4.c --- linux-2.5.59.w0/net/ipv4/tcp_ipv4.c Thu Jan 16 22:51:35 2003 +++ linux-2.5.59.w1/net/ipv4/tcp_ipv4.c Thu Jan 30 21:31:32 2003 @@ -71,6 +71,7 @@ #include #include #include +#include extern int sysctl_ip_dynaddr; extern int sysctl_ip_default_ttl; @@ -1798,6 +1799,9 @@ goto no_tcp_socket; process: + if (security_sock_rcv_skb(sk, skb)) + goto discard_and_relse; + if (sk->state == TCP_TIME_WAIT) goto do_time_wait; diff -urN -X dontdiff linux-2.5.59.w0/net/socket.c linux-2.5.59.w1/net/socket.c --- linux-2.5.59.w0/net/socket.c Thu Jan 9 16:08:27 2003 +++ linux-2.5.59.w1/net/socket.c Thu Jan 30 21:31:32 2003 @@ -77,6 +77,7 @@ #include #include #include +#include #if defined(CONFIG_KMOD) && defined(CONFIG_NET) #include @@ -527,6 +528,10 @@ si->msg = msg; si->size = size; + err = security_socket_sendmsg(sock, msg, size); + if (err) + return err; + err = scm_send(sock, msg, si->scm); if (err >= 0) { err = sock->ops->sendmsg(iocb, sock, msg, size, si->scm); @@ -551,6 +556,7 @@ int __sock_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int size, int flags) { + int err; struct sock_iocb *si = kiocb_to_siocb(iocb); si->sock = sock; @@ -560,6 +566,10 @@ si->size = size; si->flags = flags; + err = security_socket_recvmsg(sock, msg, size, flags); + if (err) + return err; + memset(si->scm, 0, sizeof(*si->scm)); size = sock->ops->recvmsg(iocb, sock, msg, size, flags, si->scm); @@ -963,6 +973,7 @@ int sock_create(int family, int type, int protocol, struct socket **res) { int i; + int err; struct socket *sock; /* @@ -986,6 +997,10 @@ } family = PF_PACKET; } + + err = security_socket_create(family, type, protocol); + if (err) + return err; #if defined(CONFIG_KMOD) && defined(CONFIG_NET) /* Attempt to load a protocol module if the find failed. @@ -1031,6 +1046,7 @@ } *res = sock; + security_socket_post_create(sock, family, type, protocol); out: net_family_read_unlock(); @@ -1141,8 +1157,14 @@ if((sock = sockfd_lookup(fd,&err))!=NULL) { - if((err=move_addr_to_kernel(umyaddr,addrlen,address))>=0) + if((err=move_addr_to_kernel(umyaddr,addrlen,address))>=0) { + err = security_socket_bind(sock, (struct sockaddr *)address, addrlen); + if (err) { + sockfd_put(sock); + return err; + } err = sock->ops->bind(sock, (struct sockaddr *)address, addrlen); + } sockfd_put(sock); } return err; @@ -1163,6 +1185,13 @@ if ((sock = sockfd_lookup(fd, &err)) != NULL) { if ((unsigned) backlog > SOMAXCONN) backlog = SOMAXCONN; + + err = security_socket_listen(sock, backlog); + if (err) { + sockfd_put(sock); + return err; + } + err=sock->ops->listen(sock, backlog); sockfd_put(sock); } @@ -1199,6 +1228,10 @@ newsock->type = sock->type; newsock->ops = sock->ops; + err = security_socket_accept(sock, newsock); + if (err) + goto out_release; + err = sock->ops->accept(sock, newsock, sock->file->f_flags); if (err < 0) goto out_release; @@ -1218,6 +1251,8 @@ if ((err = sock_map_fd(newsock)) < 0) goto out_release; + security_socket_post_accept(sock, newsock); + out_put: sockfd_put(sock); out: @@ -1253,6 +1288,11 @@ err = move_addr_to_kernel(uservaddr, addrlen, address); if (err < 0) goto out_put; + + err = security_socket_connect(sock, (struct sockaddr *)address, addrlen); + if (err) + goto out_put; + err = sock->ops->connect(sock, (struct sockaddr *) address, addrlen, sock->file->f_flags); out_put: @@ -1275,6 +1315,11 @@ sock = sockfd_lookup(fd, &err); if (!sock) goto out; + + err = security_socket_getsockname(sock); + if (err) + goto out_put; + err = sock->ops->getname(sock, (struct sockaddr *)address, &len, 0); if (err) goto out_put; @@ -1299,6 +1344,12 @@ if ((sock = sockfd_lookup(fd, &err))!=NULL) { + err = security_socket_getpeername(sock); + if (err) { + sockfd_put(sock); + return err; + } + err = sock->ops->getname(sock, (struct sockaddr *)address, &len, 1); if (!err) err=move_addr_to_user(address,len, usockaddr, usockaddr_len); @@ -1427,6 +1478,12 @@ if ((sock = sockfd_lookup(fd, &err))!=NULL) { + err = security_socket_setsockopt(sock,level,optname); + if (err) { + sockfd_put(sock); + return err; + } + if (level == SOL_SOCKET) err=sock_setsockopt(sock,level,optname,optval,optlen); else @@ -1448,6 +1505,13 @@ if ((sock = sockfd_lookup(fd, &err))!=NULL) { + err = security_socket_getsockopt(sock, level, + optname); + if (err) { + sockfd_put(sock); + return err; + } + if (level == SOL_SOCKET) err=sock_getsockopt(sock,level,optname,optval,optlen); else @@ -1469,6 +1533,12 @@ if ((sock = sockfd_lookup(fd, &err))!=NULL) { + err = security_socket_shutdown(sock, how); + if (err) { + sockfd_put(sock); + return err; + } + err=sock->ops->shutdown(sock, how); sockfd_put(sock); } diff -urN -X dontdiff linux-2.5.59.w0/security/dummy.c linux-2.5.59.w1/security/dummy.c --- linux-2.5.59.w0/security/dummy.c Thu Jan 30 21:31:15 2003 +++ linux-2.5.59.w1/security/dummy.c Thu Jan 30 21:31:32 2003 @@ -20,7 +20,7 @@ #include #include #include - +#include static int dummy_ptrace (struct task_struct *parent, struct task_struct *child) { @@ -599,6 +599,98 @@ #ifdef CONFIG_SECURITY_NETWORK +static int dummy_socket_create (int family, int type, int protocol) +{ + return 0; +} + +static void dummy_socket_post_create (struct socket *sock, int family, int type, + int protocol) +{ + return; +} + +static int dummy_socket_bind (struct socket *sock, struct sockaddr *address, + int addrlen) +{ + return 0; +} + +static int dummy_socket_connect (struct socket *sock, struct sockaddr *address, + int addrlen) +{ + return 0; +} + +static int dummy_socket_listen (struct socket *sock, int backlog) +{ + return 0; +} + +static int dummy_socket_accept (struct socket *sock, struct socket *newsock) +{ + return 0; +} + +static void dummy_socket_post_accept (struct socket *sock, + struct socket *newsock) +{ + return; +} + +static int dummy_socket_sendmsg (struct socket *sock, struct msghdr *msg, + int size) +{ + return 0; +} + +static int dummy_socket_recvmsg (struct socket *sock, struct msghdr *msg, + int size, int flags) +{ + return 0; +} + +static int dummy_socket_getsockname (struct socket *sock) +{ + return 0; +} + +static int dummy_socket_getpeername (struct socket *sock) +{ + return 0; +} + +static int dummy_socket_setsockopt (struct socket *sock, int level, int optname) +{ + return 0; +} + +static int dummy_socket_getsockopt (struct socket *sock, int level, int optname) +{ + return 0; +} + +static int dummy_socket_shutdown (struct socket *sock, int how) +{ + return 0; +} + +static int dummy_socket_sock_alloc_security(struct sock *sk, int gfp_mask) +{ + sk->security = NULL; + return 0; +} + +static void dummy_socket_sock_free_security(struct sock *sk) +{ + return; +} + +static int dummy_socket_sock_rcv_skb (struct sock *sk, struct sk_buff *skb) +{ + return 0; +} + static int dummy_skb_alloc_security (struct sk_buff *skb, int gfp_mask) { return 0; @@ -768,6 +860,23 @@ set_to_dummy_if_null(ops, register_security); set_to_dummy_if_null(ops, unregister_security); #ifdef CONFIG_SECURITY_NETWORK + set_to_dummy_if_null(ops, socket_create); + set_to_dummy_if_null(ops, socket_post_create); + set_to_dummy_if_null(ops, socket_bind); + set_to_dummy_if_null(ops, socket_connect); + set_to_dummy_if_null(ops, socket_listen); + set_to_dummy_if_null(ops, socket_accept); + set_to_dummy_if_null(ops, socket_post_accept); + set_to_dummy_if_null(ops, socket_sendmsg); + set_to_dummy_if_null(ops, socket_recvmsg); + set_to_dummy_if_null(ops, socket_getsockname); + set_to_dummy_if_null(ops, socket_getpeername); + set_to_dummy_if_null(ops, socket_setsockopt); + set_to_dummy_if_null(ops, socket_getsockopt); + set_to_dummy_if_null(ops, socket_shutdown); + set_to_dummy_if_null(ops, socket_sock_alloc_security); + set_to_dummy_if_null(ops, socket_sock_free_security); + set_to_dummy_if_null(ops, socket_sock_rcv_skb); set_to_dummy_if_null(ops, skb_alloc_security); set_to_dummy_if_null(ops, skb_clone); set_to_dummy_if_null(ops, skb_copy); From jmorris@intercode.com.au Thu Jan 30 15:02:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Jan 2003 15:02:11 -0800 (PST) Received: from blackbird.intercode.com.au (blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UN1w3v023322 for ; Thu, 30 Jan 2003 15:02:00 -0800 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id KAA31719; Fri, 31 Jan 2003 10:06:09 +1100 Date: Fri, 31 Jan 2003 10:06:09 +1100 (EST) From: James Morris To: "David S. Miller" , cc: netdev@oss.sgi.com, Subject: [PATCH] LSM networking: ipv4 hooks for 2.5.59 (5/8) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1633 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@intercode.com.au Precedence: bulk X-list: netdev include/linux/ip.h | 1 include/linux/security.h | 108 ++++++++++++++++++++++++++++++++++++++++++++++- net/ipv4/ah.c | 2 net/ipv4/ip_fragment.c | 7 ++- net/ipv4/ip_gre.c | 3 + net/ipv4/ip_options.c | 5 ++ net/ipv4/ip_output.c | 3 + net/ipv4/ipip.c | 4 + net/ipv4/ipmr.c | 4 + security/capability.c | 13 +++++ security/dummy.c | 36 +++++++++++++++ 11 files changed, 183 insertions(+), 3 deletions(-) diff -urN -X dontdiff linux-2.5.59.w0/include/linux/ip.h linux-2.5.59.w1/include/linux/ip.h --- linux-2.5.59.w0/include/linux/ip.h Thu Oct 31 16:01:08 2002 +++ linux-2.5.59.w1/include/linux/ip.h Thu Jan 30 21:33:32 2003 @@ -58,6 +58,7 @@ #define IPOPT_SEC (2 |IPOPT_CONTROL|IPOPT_COPY) #define IPOPT_LSRR (3 |IPOPT_CONTROL|IPOPT_COPY) #define IPOPT_TIMESTAMP (4 |IPOPT_MEASUREMENT) +#define IPOPT_CIPSO (6 |IPOPT_CONTROL|IPOPT_COPY) #define IPOPT_RR (7 |IPOPT_CONTROL) #define IPOPT_SID (8 |IPOPT_CONTROL|IPOPT_COPY) #define IPOPT_SSRR (9 |IPOPT_CONTROL|IPOPT_COPY) diff -urN -X dontdiff linux-2.5.59.w0/include/linux/security.h linux-2.5.59.w1/include/linux/security.h --- linux-2.5.59.w0/include/linux/security.h Thu Jan 30 21:33:15 2003 +++ linux-2.5.59.w1/include/linux/security.h Thu Jan 30 21:33:32 2003 @@ -38,6 +38,9 @@ * as the default capabilities functions */ extern int cap_capable (struct task_struct *tsk, int cap); +struct sk_buff; +extern int cap_ip_decode_options (struct sk_buff *skb, const char *optptr, + unsigned char **pp_ptr); extern int cap_ptrace (struct task_struct *parent, struct task_struct *child); extern int cap_capget (struct task_struct *target, kernel_cap_t *effective, kernel_cap_t *inheritable, kernel_cap_t *permitted); extern int cap_capset_check (struct task_struct *target, kernel_cap_t *effective, kernel_cap_t *inheritable, kernel_cap_t *permitted); @@ -68,7 +71,6 @@ struct socket; struct sockaddr; struct msghdr; -struct sk_buff; struct net_device; struct nfsctl_arg; struct sched_param; @@ -710,6 +712,48 @@ * @skb contains the incoming network data. * Return 0 if permission is granted. * + * IPv4 networking hooks. + * + * @ip_fragment: + * This is called for each fragment generated when an outgoing packet is + * being fragmented, and may be used to copy security attributes from the + * original packet to each fragment. + * @newskb contains the newly created fragment. + * @oldskb contains the original packet being fragmented. + * @ip_defragment: + * This hook is called when an incoming fragment is about to be inserted + * into a reassembly queue. It's purpose is to enable the validation of + * security attributes for each fragment. An LSM module using this hook + * will likely need to maintain its own fragment queue information, handle + * fragment expiration and implement DoS countermeasures. + * @skb contains the incoming fragment. + * Returns 0 on success. + * @ip_encapsulate: + * This hook is called when an IP packet is encapsulated, and may be used + * to update security attributes prior to reprocessing via the local_out + * or forward hooks. + * @skb contains the encapsulated packet. + * @ip_decapsulate: + * This hook is called when a packet is decapsulated, and may be used to + * process security attributes at each level of encapsulation. An example + * of this would be keeping track of nested security associations for an + * incoming packet. + * @skb contains the decapsulated packet. + * @ip_decode_options: + * This hook is used for processing IP security options at the network + * layer when labeled networking (e.g. CIPSO) is implemented. + * For outgoing packets, IP options passed down from the application or + * transport layers may be verified here prior the packet being built. + * For incoming packets, IP options may be verified and their values + * recorded via the &sk_buff security blob for later processing. + * @skb contains the &sk_buff containing IP packet (usually NULL for outgoing). + * @optptr contains the &ip_options structure. + * @pp_ptr contains the parameter problem pointer. + * Returns 0 on success. + * A non-zero return value will cause an ICMP parameter problem message to + * be generated and transmitted to the sender. The @pp_ptr parameter may + * be used to point to the offending option parameter. + * * Lifecycle hooks for network buffers. * * @skb_alloc_security: @@ -987,6 +1031,9 @@ int (*quotactl) (int cmds, int type, int id, struct super_block * sb); int (*quota_on) (struct file * f); + int (*ip_decode_options) (struct sk_buff * skb, + const char *optptr, unsigned char **pp_ptr); + int (*bprm_alloc_security) (struct linux_binprm * bprm); void (*bprm_free_security) (struct linux_binprm * bprm); void (*bprm_compute_creds) (struct linux_binprm * bprm); @@ -1159,6 +1206,12 @@ void (*socket_sock_free_security) (struct sock * sk); int (*socket_sock_rcv_skb) (struct sock * sk, struct sk_buff * skb); + void (*ip_fragment) (struct sk_buff * newskb, + const struct sk_buff * oldskb); + int (*ip_defragment) (struct sk_buff * skb); + void (*ip_encapsulate) (struct sk_buff * skb); + void (*ip_decapsulate) (struct sk_buff * skb); + int (*skb_alloc_security) (struct sk_buff * skb, int gfp_mask); int (*skb_clone) (struct sk_buff * newskb, const struct sk_buff * oldskb); @@ -1222,6 +1275,13 @@ return security_ops->quota_on (file); } +static inline int security_ip_decode_options(struct sk_buff * skb, + const char *optptr, + unsigned char **pp_ptr) +{ + return security_ops->ip_decode_options(skb, optptr, pp_ptr); +} + static inline int security_bprm_alloc (struct linux_binprm *bprm) { return security_ops->bprm_alloc_security (bprm); @@ -1827,6 +1887,13 @@ return 0; } +static inline int security_ip_decode_options(struct sk_buff * skb, + const char *optptr, + unsigned char **pp_ptr) +{ + return cap_ip_decode_options(skb,optptr,pp_ptr); +} + static inline int security_bprm_alloc (struct linux_binprm *bprm) { return 0; @@ -2428,6 +2495,27 @@ return security_ops->socket_sock_rcv_skb (sk, skb); } +static inline void security_ip_fragment(struct sk_buff * newskb, + const struct sk_buff * oldskb) +{ + security_ops->ip_fragment(newskb, oldskb); +} + +static inline int security_ip_defragment(struct sk_buff * skb) +{ + return security_ops->ip_defragment(skb); +} + +static inline void security_ip_encapsulate(struct sk_buff * skb) +{ + security_ops->ip_encapsulate(skb); +} + +static inline void security_ip_decapsulate(struct sk_buff * skb) +{ + security_ops->ip_decapsulate(skb); +} + static inline int security_skb_alloc(struct sk_buff * skb, int gfp_mask) { return security_ops->skb_alloc_security(skb, gfp_mask); @@ -2567,6 +2655,24 @@ return 0; } +static inline void security_ip_fragment(struct sk_buff * newskb, + const struct sk_buff * oldskb) +{ +} + +static inline int security_ip_defragment(struct sk_buff * skb) +{ + return 0; +} + +static inline void security_ip_encapsulate(struct sk_buff * skb) +{ +} + +static inline void security_ip_decapsulate(struct sk_buff * skb) +{ +} + static inline int security_skb_alloc(struct sk_buff * skb, int gfp_mask) { return 0; diff -urN -X dontdiff linux-2.5.59.w0/net/ipv4/ah.c linux-2.5.59.w1/net/ipv4/ah.c --- linux-2.5.59.w0/net/ipv4/ah.c Sat Jan 11 10:47:20 2003 +++ linux-2.5.59.w1/net/ipv4/ah.c Thu Jan 30 21:33:32 2003 @@ -52,7 +52,7 @@ switch (*optptr) { case IPOPT_SEC: case 0x85: /* Some "Extended Security" crap. */ - case 0x86: /* Another "Commercial Security" crap. */ + case IPOPT_CIPSO: /* Another "Commercial Security" crap. */ case IPOPT_RA: case 0x80|21: /* RFC1770 */ break; diff -urN -X dontdiff linux-2.5.59.w0/net/ipv4/ip_fragment.c linux-2.5.59.w1/net/ipv4/ip_fragment.c --- linux-2.5.59.w0/net/ipv4/ip_fragment.c Sat Jan 11 10:47:20 2003 +++ linux-2.5.59.w1/net/ipv4/ip_fragment.c Thu Jan 30 21:33:32 2003 @@ -37,6 +37,7 @@ #include #include #include +#include /* NOTE. Logic of IP defragmentation is parallel to corresponding IPv6 * code now. If you change something here, _PLEASE_ update ipv6/reassembly.c @@ -372,7 +373,11 @@ { struct sk_buff *prev, *next; int flags, offset; - int ihl, end; + int ihl, end, ret; + + ret = security_ip_defragment(skb); + if (ret) + goto err; if (qp->last_in & COMPLETE) goto err; diff -urN -X dontdiff linux-2.5.59.w0/net/ipv4/ip_gre.c linux-2.5.59.w1/net/ipv4/ip_gre.c --- linux-2.5.59.w0/net/ipv4/ip_gre.c Tue Nov 12 00:12:06 2002 +++ linux-2.5.59.w1/net/ipv4/ip_gre.c Thu Jan 30 21:33:32 2003 @@ -28,6 +28,7 @@ #include #include #include +#include #include #include @@ -661,6 +662,7 @@ skb->nf_debug = 0; #endif #endif + security_ip_decapsulate(skb); ipgre_ecn_decapsulate(iph, skb); netif_rx(skb); read_unlock(&ipgre_lock); @@ -898,6 +900,7 @@ skb->nf_debug = 0; #endif #endif + security_ip_encapsulate(skb); IPTUNNEL_XMIT(); tunnel->recursion--; diff -urN -X dontdiff linux-2.5.59.w0/net/ipv4/ip_options.c linux-2.5.59.w1/net/ipv4/ip_options.c --- linux-2.5.59.w0/net/ipv4/ip_options.c Tue Sep 24 19:22:50 2002 +++ linux-2.5.59.w1/net/ipv4/ip_options.c Thu Jan 30 21:33:32 2003 @@ -18,6 +18,7 @@ #include #include #include +#include #include #include #include @@ -433,7 +434,11 @@ opt->router_alert = optptr - iph; break; case IPOPT_SEC: + case IPOPT_CIPSO: case IPOPT_SID: + if (security_ip_decode_options(skb, optptr, &pp_ptr)) + goto error; + break; default: if (!skb && !capable(CAP_NET_RAW)) { pp_ptr = optptr; diff -urN -X dontdiff linux-2.5.59.w0/net/ipv4/ip_output.c linux-2.5.59.w1/net/ipv4/ip_output.c --- linux-2.5.59.w0/net/ipv4/ip_output.c Sat Jan 11 10:47:20 2003 +++ linux-2.5.59.w1/net/ipv4/ip_output.c Thu Jan 30 21:33:32 2003 @@ -81,6 +81,7 @@ #include #include #include +#include /* * Shall we try to damage output packets if routing dev changes? @@ -633,6 +634,8 @@ ptr += len; offset += len; + security_ip_fragment(skb2, skb); + /* * Put this fragment into the sending queue. */ diff -urN -X dontdiff linux-2.5.59.w0/net/ipv4/ipip.c linux-2.5.59.w1/net/ipv4/ipip.c --- linux-2.5.59.w0/net/ipv4/ipip.c Tue Nov 12 00:12:07 2002 +++ linux-2.5.59.w1/net/ipv4/ipip.c Thu Jan 30 21:33:32 2003 @@ -108,6 +108,7 @@ #include #include #include +#include #include #include @@ -508,6 +509,7 @@ skb->nf_debug = 0; #endif #endif + security_ip_decapsulate(skb); ipip_ecn_decapsulate(iph, skb); netif_rx(skb); read_unlock(&ipip_lock); @@ -662,6 +664,8 @@ #endif #endif + security_ip_encapsulate(skb); + IPTUNNEL_XMIT(); tunnel->recursion--; return 0; diff -urN -X dontdiff linux-2.5.59.w0/net/ipv4/ipmr.c linux-2.5.59.w1/net/ipv4/ipmr.c --- linux-2.5.59.w0/net/ipv4/ipmr.c Tue Nov 12 00:12:07 2002 +++ linux-2.5.59.w1/net/ipv4/ipmr.c Thu Jan 30 21:33:32 2003 @@ -60,6 +60,7 @@ #include #include #include +#include #if defined(CONFIG_IP_PIMSM_V1) || defined(CONFIG_IP_PIMSM_V2) #define CONFIG_IP_PIMSM 1 @@ -1105,6 +1106,7 @@ nf_conntrack_put(skb->nfct); skb->nfct = NULL; #endif + security_ip_encapsulate(skb); } static inline int ipmr_forward_finish(struct sk_buff *skb) @@ -1461,6 +1463,7 @@ nf_conntrack_put(skb->nfct); skb->nfct = NULL; #endif + security_ip_decapsulate(skb); netif_rx(skb); dev_put(reg_dev); return 0; @@ -1528,6 +1531,7 @@ nf_conntrack_put(skb->nfct); skb->nfct = NULL; #endif + security_ip_decapsulate(skb); netif_rx(skb); dev_put(reg_dev); return 0; diff -urN -X dontdiff linux-2.5.59.w0/security/capability.c linux-2.5.59.w1/security/capability.c --- linux-2.5.59.w0/security/capability.c Tue Dec 10 15:02:03 2002 +++ linux-2.5.59.w1/security/capability.c Thu Jan 30 21:33:32 2003 @@ -266,6 +266,16 @@ return; } +int cap_ip_decode_options (struct sk_buff *skb, const char *optptr, + unsigned char **pp_ptr) +{ + if (!skb && !capable (CAP_NET_RAW)) { + (const unsigned char *) *pp_ptr = optptr; + return -EPERM; + } + return 0; +} + EXPORT_SYMBOL(cap_capable); EXPORT_SYMBOL(cap_ptrace); EXPORT_SYMBOL(cap_capget); @@ -276,6 +286,7 @@ EXPORT_SYMBOL(cap_task_post_setuid); EXPORT_SYMBOL(cap_task_kmod_set_label); EXPORT_SYMBOL(cap_task_reparent_to_init); +EXPORT_SYMBOL(cap_ip_decode_options); #ifdef CONFIG_SECURITY @@ -293,6 +304,8 @@ .task_post_setuid = cap_task_post_setuid, .task_kmod_set_label = cap_task_kmod_set_label, .task_reparent_to_init = cap_task_reparent_to_init, + + .ip_decode_options = cap_ip_decode_options, }; #if defined(CONFIG_SECURITY_CAPABILITIES_MODULE) diff -urN -X dontdiff linux-2.5.59.w0/security/dummy.c linux-2.5.59.w1/security/dummy.c --- linux-2.5.59.w0/security/dummy.c Thu Jan 30 21:33:15 2003 +++ linux-2.5.59.w1/security/dummy.c Thu Jan 30 21:33:32 2003 @@ -597,6 +597,16 @@ return 0; } +static int dummy_ip_decode_options (struct sk_buff *skb, const char *optptr, + unsigned char **pp_ptr) +{ + if (!skb && !capable (CAP_NET_RAW)) { + (const unsigned char *) *pp_ptr = optptr; + return -EPERM; + } + return 0; +} + #ifdef CONFIG_SECURITY_NETWORK static int dummy_socket_create (int family, int type, int protocol) @@ -686,6 +696,27 @@ return; } +static void dummy_ip_fragment (struct sk_buff *newskb, + const struct sk_buff *oldskb) +{ + return; +} + +static int dummy_ip_defragment (struct sk_buff *skb) +{ + return 0; +} + +static void dummy_ip_decapsulate (struct sk_buff *skb) +{ + return; +} + +static void dummy_ip_encapsulate (struct sk_buff *skb) +{ + return; +} + static int dummy_socket_sock_rcv_skb (struct sock *sk, struct sk_buff *skb) { return 0; @@ -859,6 +890,7 @@ set_to_dummy_if_null(ops, sem_semop); set_to_dummy_if_null(ops, register_security); set_to_dummy_if_null(ops, unregister_security); + set_to_dummy_if_null(ops, ip_decode_options); #ifdef CONFIG_SECURITY_NETWORK set_to_dummy_if_null(ops, socket_create); set_to_dummy_if_null(ops, socket_post_create); @@ -877,6 +909,10 @@ set_to_dummy_if_null(ops, socket_sock_alloc_security); set_to_dummy_if_null(ops, socket_sock_free_security); set_to_dummy_if_null(ops, socket_sock_rcv_skb); + set_to_dummy_if_null(ops, ip_fragment); + set_to_dummy_if_null(ops, ip_defragment); + set_to_dummy_if_null(ops, ip_decapsulate); + set_to_dummy_if_null(ops, ip_encapsulate); set_to_dummy_if_null(ops, skb_alloc_security); set_to_dummy_if_null(ops, skb_clone); set_to_dummy_if_null(ops, skb_copy); From jmorris@intercode.com.au Thu Jan 30 15:06:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Jan 2003 15:06:41 -0800 (PST) Received: from blackbird.intercode.com.au (blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UN6U3v023798 for ; Thu, 30 Jan 2003 15:06:31 -0800 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id KAA31747; Fri, 31 Jan 2003 10:10:41 +1100 Date: Fri, 31 Jan 2003 10:10:41 +1100 (EST) From: James Morris To: "David S. Miller" , cc: netdev@oss.sgi.com, Subject: [PATCH] LSM networking: netlink hooks for 2.5.59 (6/8) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1634 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@intercode.com.au Precedence: bulk X-list: netdev include/linux/security.h | 39 +++++++++++++++++++++++++++++++++++++++ net/core/rtnetlink.c | 3 ++- net/ipv4/netfilter/ip_queue.c | 3 ++- net/netlink/af_netlink.c | 8 +++++++- security/capability.c | 17 +++++++++++++++++ security/dummy.c | 18 ++++++++++++++++++ 6 files changed, 85 insertions(+), 3 deletions(-) diff -urN -X dontdiff linux-2.5.59.w0/include/linux/security.h linux-2.5.59.w1/include/linux/security.h --- linux-2.5.59.w0/include/linux/security.h Thu Jan 30 21:36:34 2003 +++ linux-2.5.59.w1/include/linux/security.h Thu Jan 30 21:36:14 2003 @@ -39,6 +39,8 @@ */ extern int cap_capable (struct task_struct *tsk, int cap); struct sk_buff; +extern int cap_netlink_send (struct sk_buff *skb); +extern int cap_netlink_recv (struct sk_buff *skb); extern int cap_ip_decode_options (struct sk_buff *skb, const char *optptr, unsigned char **pp_ptr); extern int cap_ptrace (struct task_struct *parent, struct task_struct *child); @@ -1002,6 +1004,20 @@ * @cap contains the capability . * Return 0 if the capability is granted for @tsk. * + * @netlink_send: + * Save security information for a netlink message so that permission + * checking can be performed when the message is processed. The security + * information can either be saved using the existing eff_cap field of the + * netlink_skb_parms structure or it can be saved using the skbuff + * lsm_security field. + * @skb contains the sk_buff structure for the netlink message. + * Return 0 if the information was successfully saved. + * @netlink_recv: + * Check permission before processing the received netlink message in + * @skb. + * @skb contains the sk_buff structure for the netlink message. + * Return 0 if permission is granted. + * * @register_security: * allow module stacking. * @name contains the name of the security module being stacked. @@ -1031,6 +1047,9 @@ int (*quotactl) (int cmds, int type, int id, struct super_block * sb); int (*quota_on) (struct file * f); + int (*netlink_send) (struct sk_buff * skb); + int (*netlink_recv) (struct sk_buff * skb); + int (*ip_decode_options) (struct sk_buff * skb, const char *optptr, unsigned char **pp_ptr); @@ -1275,6 +1294,16 @@ return security_ops->quota_on (file); } +static inline int security_netlink_send(struct sk_buff * skb) +{ + return security_ops->netlink_send(skb); +} + +static inline int security_netlink_recv(struct sk_buff * skb) +{ + return security_ops->netlink_recv(skb); +} + static inline int security_ip_decode_options(struct sk_buff * skb, const char *optptr, unsigned char **pp_ptr) @@ -1887,6 +1916,16 @@ return 0; } +static inline int security_netlink_send(struct sk_buff * skb) +{ + return cap_netlink_send(skb); +} + +static inline int security_netlink_recv(struct sk_buff * skb) +{ + return cap_netlink_recv(skb); +} + static inline int security_ip_decode_options(struct sk_buff * skb, const char *optptr, unsigned char **pp_ptr) diff -urN -X dontdiff linux-2.5.59.w0/net/core/rtnetlink.c linux-2.5.59.w1/net/core/rtnetlink.c --- linux-2.5.59.w0/net/core/rtnetlink.c Fri Jan 17 19:46:08 2003 +++ linux-2.5.59.w1/net/core/rtnetlink.c Thu Jan 30 21:36:14 2003 @@ -34,6 +34,7 @@ #include #include #include +#include #include #include @@ -363,7 +364,7 @@ sz_idx = type>>2; kind = type&3; - if (kind != 2 && !cap_raised(NETLINK_CB(skb).eff_cap, CAP_NET_ADMIN)) { + if (kind != 2 && security_netlink_recv(skb)) { *errp = -EPERM; return -1; } diff -urN -X dontdiff linux-2.5.59.w0/net/ipv4/netfilter/ip_queue.c linux-2.5.59.w1/net/ipv4/netfilter/ip_queue.c --- linux-2.5.59.w0/net/ipv4/netfilter/ip_queue.c Sun Aug 11 12:20:40 2002 +++ linux-2.5.59.w1/net/ipv4/netfilter/ip_queue.c Thu Jan 30 21:36:14 2003 @@ -26,6 +26,7 @@ #include #include #include +#include #include #include @@ -496,7 +497,7 @@ if (type <= IPQM_BASE) return; - if(!cap_raised(NETLINK_CB(skb).eff_cap, CAP_NET_ADMIN)) + if (security_netlink_recv(skb)) RCV_SKB_FAIL(-EPERM); write_lock_bh(&queue_lock); diff -urN -X dontdiff linux-2.5.59.w0/net/netlink/af_netlink.c linux-2.5.59.w1/net/netlink/af_netlink.c --- linux-2.5.59.w0/net/netlink/af_netlink.c Tue Dec 10 15:02:03 2002 +++ linux-2.5.59.w1/net/netlink/af_netlink.c Thu Jan 30 21:36:14 2003 @@ -42,6 +42,7 @@ #include #include #include +#include #include #include @@ -636,7 +637,12 @@ check them, when this message will be delivered to corresponding kernel module. --ANK (980802) */ - NETLINK_CB(skb).eff_cap = current->cap_effective; + + err = security_netlink_send(skb); + if (err) { + kfree_skb(skb); + goto out; + } err = -EFAULT; if (memcpy_fromiovec(skb_put(skb,len), msg->msg_iov, len)) { diff -urN -X dontdiff linux-2.5.59.w0/security/capability.c linux-2.5.59.w1/security/capability.c --- linux-2.5.59.w0/security/capability.c Thu Jan 30 21:36:34 2003 +++ linux-2.5.59.w1/security/capability.c Thu Jan 30 21:36:14 2003 @@ -28,6 +28,19 @@ return -EPERM; } +int cap_netlink_send (struct sk_buff *skb) +{ + NETLINK_CB (skb).eff_cap = current->cap_effective; + return 0; +} + +int cap_netlink_recv (struct sk_buff *skb) +{ + if (!cap_raised (NETLINK_CB (skb).eff_cap, CAP_NET_ADMIN)) + return -EPERM; + return 0; +} + int cap_ptrace (struct task_struct *parent, struct task_struct *child) { /* Derived from arch/i386/kernel/ptrace.c:sys_ptrace. */ @@ -286,6 +299,8 @@ EXPORT_SYMBOL(cap_task_post_setuid); EXPORT_SYMBOL(cap_task_kmod_set_label); EXPORT_SYMBOL(cap_task_reparent_to_init); +EXPORT_SYMBOL(cap_netlink_send); +EXPORT_SYMBOL(cap_netlink_recv); EXPORT_SYMBOL(cap_ip_decode_options); #ifdef CONFIG_SECURITY @@ -297,6 +312,8 @@ .capset_check = cap_capset_check, .capset_set = cap_capset_set, .capable = cap_capable, + .netlink_send = cap_netlink_send, + .netlink_recv = cap_netlink_recv, .bprm_compute_creds = cap_bprm_compute_creds, .bprm_set_security = cap_bprm_set_security, diff -urN -X dontdiff linux-2.5.59.w0/security/dummy.c linux-2.5.59.w1/security/dummy.c --- linux-2.5.59.w0/security/dummy.c Thu Jan 30 21:36:34 2003 +++ linux-2.5.59.w1/security/dummy.c Thu Jan 30 21:36:14 2003 @@ -85,6 +85,22 @@ return 0; } +static int dummy_netlink_send (struct sk_buff *skb) +{ + if (current->euid == 0) + cap_raise (NETLINK_CB (skb).eff_cap, CAP_NET_ADMIN); + else + NETLINK_CB (skb).eff_cap = 0; + return 0; +} + +static int dummy_netlink_recv (struct sk_buff *skb) +{ + if (!cap_raised (NETLINK_CB (skb).eff_cap, CAP_NET_ADMIN)) + return -EPERM; + return 0; +} + static int dummy_bprm_alloc_security (struct linux_binprm *bprm) { return 0; @@ -890,6 +906,8 @@ set_to_dummy_if_null(ops, sem_semop); set_to_dummy_if_null(ops, register_security); set_to_dummy_if_null(ops, unregister_security); + set_to_dummy_if_null(ops, netlink_send); + set_to_dummy_if_null(ops, netlink_recv); set_to_dummy_if_null(ops, ip_decode_options); #ifdef CONFIG_SECURITY_NETWORK set_to_dummy_if_null(ops, socket_create); From jmorris@intercode.com.au Thu Jan 30 15:12:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Jan 2003 15:13:00 -0800 (PST) Received: from blackbird.intercode.com.au (blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UNCo3v024240 for ; Thu, 30 Jan 2003 15:12:51 -0800 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id KAA31804; Fri, 31 Jan 2003 10:17:01 +1100 Date: Fri, 31 Jan 2003 10:17:01 +1100 (EST) From: James Morris To: "David S. Miller" , cc: netdev@oss.sgi.com, Subject: [PATCH] LSM networking: af_unix hooks for 2.5.59 (7/8) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1635 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@intercode.com.au Precedence: bulk X-list: netdev include/linux/security.h | 54 +++++++++++++++++++++++++++++++++++++++++++++++ net/unix/af_unix.c | 16 +++++++++++++ security/dummy.c | 15 +++++++++++++ 3 files changed, 85 insertions(+) diff -urN -X dontdiff linux-2.5.59.w0/include/linux/security.h linux-2.5.59.w1/include/linux/security.h --- linux-2.5.59.w0/include/linux/security.h Thu Jan 30 21:41:57 2003 +++ linux-2.5.59.w1/include/linux/security.h Thu Jan 30 21:41:38 2003 @@ -1018,6 +1018,29 @@ * @skb contains the sk_buff structure for the netlink message. * Return 0 if permission is granted. * + * @unix_stream_connect: + * Check permissions before establishing a Unix domain stream connection + * between @sock and @other. + * @sock contains the socket structure. + * @other contains the peer socket structure. + * Return 0 if permission is granted. + * @unix_may_send: + * Check permissions before connecting or sending datagrams from @sock to + * @other. + * @sock contains the socket structure. + * @sock contains the peer socket structure. + * Return 0 if permission is granted. + * + * The @unix_stream_connect and @unix_may_send hooks were necessary because + * Linux provides an alternative to the conventional file name space for Unix + * domain sockets. Whereas binding and connecting to sockets in the file name + * space is mediated by the typical file permissions (and caught by the mknod + * and permission hooks in inode_security_ops), binding and connecting to + * sockets in the abstract name space is completely unmediated. Sufficient + * control of Unix domain sockets in the abstract name space isn't possible + * using only the socket layer hooks, since we need to know the actual target + * socket, which is not looked up until we are inside the af_unix code. + * * @register_security: * allow module stacking. * @name contains the name of the security module being stacked. @@ -1201,6 +1224,10 @@ struct security_operations *ops); #ifdef CONFIG_SECURITY_NETWORK + int (*unix_stream_connect) (struct socket * sock, + struct socket * other, struct sock * newsk); + int (*unix_may_send) (struct socket * sock, struct socket * other); + int (*socket_create) (int family, int type, int protocol); void (*socket_post_create) (struct socket * sock, int family, int type, int protocol); @@ -2433,6 +2460,20 @@ #ifdef CONFIG_SECURITY_NETWORK +static inline int security_unix_stream_connect(struct socket * sock, + struct socket * other, + struct sock * newsk) +{ + return security_ops->unix_stream_connect(sock, other, newsk); +} + + +static inline int security_unix_may_send(struct socket * sock, + struct socket * other) +{ + return security_ops->unix_may_send(sock, other); +} + static inline int security_socket_create (int family, int type, int protocol) { return security_ops->socket_create(family, type, protocol); @@ -2596,6 +2637,19 @@ #else /* CONFIG_SECURITY_NETWORK */ +static inline int security_unix_stream_connect(struct socket * sock, + struct socket * other, + struct sock * newsk) +{ + return 0; +} + +static inline int security_unix_may_send(struct socket * sock, + struct socket * other) +{ + return 0; +} + static inline int security_socket_create (int family, int type, int protocol) { return 0; diff -urN -X dontdiff linux-2.5.59.w0/net/unix/af_unix.c linux-2.5.59.w1/net/unix/af_unix.c --- linux-2.5.59.w0/net/unix/af_unix.c Sat Jan 11 10:47:20 2003 +++ linux-2.5.59.w1/net/unix/af_unix.c Thu Jan 30 21:41:38 2003 @@ -115,6 +115,7 @@ #include #include #include +#include int sysctl_unix_max_dgram_qlen = 10; @@ -816,6 +817,11 @@ err = -EPERM; if (!unix_may_send(sk, other)) goto out_unlock; + + err = security_unix_may_send(sk->socket, other->socket); + if (err) + goto out_unlock; + } else { /* * 1003.1g breaking connected state with AF_UNSPEC @@ -981,6 +987,12 @@ goto restart; } + err = security_unix_stream_connect(sock, other->socket, newsk); + if (err) { + unix_state_wunlock(sk); + goto out_unlock; + } + /* The way is open! Fastly set all the necessary fields... */ sock_hold(sk); @@ -1280,6 +1292,10 @@ if (other->shutdown&RCV_SHUTDOWN) goto out_unlock; + err = security_unix_may_send(sk->socket, other->socket); + if (err) + goto out_unlock; + if (unix_peer(other) != sk && skb_queue_len(&other->receive_queue) > other->max_ack_backlog) { if (!timeo) { diff -urN -X dontdiff linux-2.5.59.w0/security/dummy.c linux-2.5.59.w1/security/dummy.c --- linux-2.5.59.w0/security/dummy.c Thu Jan 30 21:41:57 2003 +++ linux-2.5.59.w1/security/dummy.c Thu Jan 30 21:41:38 2003 @@ -625,6 +625,19 @@ #ifdef CONFIG_SECURITY_NETWORK +static int dummy_unix_stream_connect (struct socket *sock, + struct socket *other, + struct sock *newsk) +{ + return 0; +} + +static int dummy_unix_may_send (struct socket *sock, + struct socket *other) +{ + return 0; +} + static int dummy_socket_create (int family, int type, int protocol) { return 0; @@ -910,6 +923,8 @@ set_to_dummy_if_null(ops, netlink_recv); set_to_dummy_if_null(ops, ip_decode_options); #ifdef CONFIG_SECURITY_NETWORK + set_to_dummy_if_null(ops, unix_stream_connect); + set_to_dummy_if_null(ops, unix_may_send); set_to_dummy_if_null(ops, socket_create); set_to_dummy_if_null(ops, socket_post_create); set_to_dummy_if_null(ops, socket_bind); From jmorris@intercode.com.au Thu Jan 30 15:18:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Jan 2003 15:18:10 -0800 (PST) Received: from blackbird.intercode.com.au (blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UNHv3v024684 for ; Thu, 30 Jan 2003 15:17:59 -0800 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id KAA31834; Fri, 31 Jan 2003 10:22:09 +1100 Date: Fri, 31 Jan 2003 10:22:08 +1100 (EST) From: James Morris To: "David S. Miller" , cc: netdev@oss.sgi.com, Subject: [PATCH] LSM networking: tcp hooks for 2.5.59 (8/8) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1636 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@intercode.com.au Precedence: bulk X-list: netdev include/linux/security.h | 103 +++++++++++++++++++++++++++++++++++++++++++++++ include/linux/tcp.h | 11 +++++ include/net/tcp.h | 26 ++++++++++- net/ipv4/syncookies.c | 3 + net/ipv4/tcp_ipv4.c | 4 + net/ipv4/tcp_minisocks.c | 6 ++ security/dummy.c | 36 ++++++++++++++++ 7 files changed, 186 insertions(+), 3 deletions(-) diff -urN -X dontdiff linux-2.5.59.w0/include/linux/security.h linux-2.5.59.w1/include/linux/security.h --- linux-2.5.59.w0/include/linux/security.h Thu Jan 30 21:43:00 2003 +++ linux-2.5.59.w1/include/linux/security.h Thu Jan 30 21:44:11 2003 @@ -77,6 +77,7 @@ struct nfsctl_arg; struct sched_param; struct swap_info_struct; +struct open_request; #ifdef CONFIG_SECURITY @@ -594,6 +595,38 @@ * is being reparented to the init task. * @p contains the task_struct for the kernel thread. * + * Security hooks for TCP networking. + * + * @open_request_alloc_security: + * Allocate the security blob for an open_request structure. The + * req->security field is initialized to NULL when the structure is + * allocated. + * @req Pointer to the open_request structure. + * Return 0 if successful, or -ENOMEM on out of memory condition. + * @open_request_free_security: + * Free the security blob for an open_request structure. + * @req Pointer to the open_request structure. + * @tcp_connection_request: + * A new connection is being requested on a server. This hook allows + * security information to be attached to the new connection request. + * @sk contains the listening sock. + * @skb contains the incoming network packet. + * @req contains the open_request structure. + * @tcp_synack: + * A TCP SYN-ACK packet is being sent out, the second part of the TCP + * three-way handshake for a new connection. + * @sk contains the listening sock. + * @skb contains the outgoing network packet. + * @req contains the open_request structure. + * @tcp_create_openreq_child: + * A new connection is being established on a TCP sock. This hook allows + * the association of security information with the new sock as it is + * being created. + * @sk contains the listening sock. + * @newsk contains the sock associated with the new connection. + * @skb contains the incoming network packet that finalized the connection. + * @req contains the open_request structure. + * * Security hooks for socket operations. * * @socket_create: @@ -1224,6 +1257,16 @@ struct security_operations *ops); #ifdef CONFIG_SECURITY_NETWORK + int (*open_request_alloc_security) (struct open_request * req); + void (*open_request_free_security) (struct open_request * req); + void (*tcp_connection_request) (struct sock * sk, struct sk_buff * skb, + struct open_request * req); + void (*tcp_synack) (struct sock * sk, struct sk_buff * skb, + struct open_request * req); + void (*tcp_create_openreq_child) (struct sock * sk, struct sock * newsk, + struct sk_buff * skb, + struct open_request * req); + int (*unix_stream_connect) (struct socket * sock, struct socket * other, struct sock * newsk); int (*unix_may_send) (struct socket * sock, struct socket * other); @@ -2460,6 +2503,38 @@ #ifdef CONFIG_SECURITY_NETWORK +static inline int security_open_request_alloc (struct open_request * req) +{ + return security_ops->open_request_alloc_security (req); +} + +static inline void security_open_request_free (struct open_request * req) +{ + security_ops->open_request_free_security (req); +} + +static inline void security_tcp_connection_request(struct sock * sk, + struct sk_buff * skb, + struct open_request * req) +{ + security_ops->tcp_connection_request(sk, skb, req); +} + +static inline void security_tcp_synack(struct sock * sk, + struct sk_buff * skb, + struct open_request * req) +{ + security_ops->tcp_synack(sk, skb, req); +} + +static inline void security_tcp_create_openreq_child(struct sock * sk, + struct sock * newsk, + struct sk_buff * skb, + struct open_request * req) +{ + security_ops->tcp_create_openreq_child(sk, newsk, skb, req); +} + static inline int security_unix_stream_connect(struct socket * sock, struct socket * other, struct sock * newsk) @@ -2637,6 +2712,34 @@ #else /* CONFIG_SECURITY_NETWORK */ +static inline int security_open_request_alloc (struct open_request * req) +{ + return 0; +} + +static inline void security_open_request_free (struct open_request * req) +{ +} + +static inline void security_tcp_connection_request(struct sock * sk, + struct sk_buff * skb, + struct open_request * req) +{ +} + +static inline void security_tcp_synack(struct sock * sk, + struct sk_buff * skb, + struct open_request * req) +{ +} + +static inline void security_tcp_create_openreq_child(struct sock * sk, + struct sock * newsk, + struct sk_buff * skb, + struct open_request * req) +{ +} + static inline int security_unix_stream_connect(struct socket * sock, struct socket * other, struct sock * newsk) diff -urN -X dontdiff linux-2.5.59.w0/include/linux/tcp.h linux-2.5.59.w1/include/linux/tcp.h --- linux-2.5.59.w0/include/linux/tcp.h Sat Oct 19 19:57:49 2002 +++ linux-2.5.59.w1/include/linux/tcp.h Thu Jan 30 21:44:11 2003 @@ -382,4 +382,15 @@ #define tcp_sk(__sk) (&((struct tcp_sock *)__sk)->tcp) +static inline void clone_tcp_sk(struct sock *newsk, struct sock *sk) { +#ifdef CONFIG_SECURITY_NETWORK +/* Save/restore the LSM security pointer around the copy */ + void *sptr = newsk->security; + memcpy(newsk, sk, sizeof(struct tcp_sock)); + newsk->security = sptr; +#else + memcpy(newsk, sk, sizeof(struct tcp_sock)); +#endif +} + #endif /* _LINUX_TCP_H */ diff -urN -X dontdiff linux-2.5.59.w0/include/net/tcp.h linux-2.5.59.w1/include/net/tcp.h --- linux-2.5.59.w0/include/net/tcp.h Sat Jan 11 10:47:20 2003 +++ linux-2.5.59.w1/include/net/tcp.h Thu Jan 30 21:44:11 2003 @@ -29,6 +29,7 @@ #include #include #include +#include #include #include #if defined(CONFIG_IPV6) || defined (CONFIG_IPV6_MODULE) @@ -533,13 +534,34 @@ struct tcp_v6_open_req v6_req; #endif } af; +#ifdef CONFIG_SECURITY_NETWORK + /* LSM security field */ + void *security; +#endif }; /* SLAB cache for open requests. */ extern kmem_cache_t *tcp_openreq_cachep; -#define tcp_openreq_alloc() kmem_cache_alloc(tcp_openreq_cachep, SLAB_ATOMIC) -#define tcp_openreq_fastfree(req) kmem_cache_free(tcp_openreq_cachep, req) +static inline struct open_request *tcp_openreq_alloc(void) +{ + struct open_request *req = + kmem_cache_alloc(tcp_openreq_cachep, SLAB_ATOMIC); + + if (req != NULL) { + if (security_open_request_alloc(req)) { + kmem_cache_free(tcp_openreq_cachep, req); + return NULL; + } + } + return req; +} + +static inline void tcp_openreq_fastfree(struct open_request *req) +{ + security_open_request_free(req); + kmem_cache_free(tcp_openreq_cachep, req); +} static inline void tcp_openreq_free(struct open_request *req) { diff -urN -X dontdiff linux-2.5.59.w0/net/ipv4/syncookies.c linux-2.5.59.w1/net/ipv4/syncookies.c --- linux-2.5.59.w0/net/ipv4/syncookies.c Thu Oct 31 16:01:08 2002 +++ linux-2.5.59.w1/net/ipv4/syncookies.c Thu Jan 30 21:44:11 2003 @@ -17,6 +17,7 @@ #include #include #include +#include #include extern int sysctl_tcp_syncookies; @@ -188,6 +189,8 @@ } } + security_tcp_connection_request(sk, skb, req); + /* Try to redo what tcp_v4_send_synack did. */ req->window_clamp = dst_metric(&rt->u.dst, RTAX_WINDOW); tcp_select_initial_window(tcp_full_space(sk), req->mss, diff -urN -X dontdiff linux-2.5.59.w0/net/ipv4/tcp_ipv4.c linux-2.5.59.w1/net/ipv4/tcp_ipv4.c --- linux-2.5.59.w0/net/ipv4/tcp_ipv4.c Thu Jan 30 21:33:15 2003 +++ linux-2.5.59.w1/net/ipv4/tcp_ipv4.c Thu Jan 30 21:44:11 2003 @@ -1334,6 +1334,8 @@ if (skb) { struct tcphdr *th = skb->h.th; + security_tcp_synack(sk, skb, req); + th->check = tcp_v4_check(th, skb->len, req->af.v4_req.loc_addr, req->af.v4_req.rmt_addr, @@ -1550,6 +1552,8 @@ } req->snt_isn = isn; + security_tcp_connection_request(sk, skb, req); + if (tcp_v4_send_synack(sk, req, dst)) goto drop_and_free; diff -urN -X dontdiff linux-2.5.59.w0/net/ipv4/tcp_minisocks.c linux-2.5.59.w1/net/ipv4/tcp_minisocks.c --- linux-2.5.59.w0/net/ipv4/tcp_minisocks.c Thu Jan 9 16:08:27 2003 +++ linux-2.5.59.w1/net/ipv4/tcp_minisocks.c Thu Jan 30 21:44:11 2003 @@ -23,6 +23,7 @@ #include #include #include +#include #include #include #include @@ -654,7 +655,8 @@ struct sk_filter *filter; #endif - memcpy(newsk, sk, sizeof(struct tcp_sock)); + clone_tcp_sk(newsk, sk); + newsk->state = TCP_SYN_RECV; /* SANITY */ @@ -801,6 +803,8 @@ newsk->no_largesend = 1; TCP_INC_STATS_BH(TcpPassiveOpens); + + security_tcp_create_openreq_child(sk, newsk, skb, req); } return newsk; } diff -urN -X dontdiff linux-2.5.59.w0/security/dummy.c linux-2.5.59.w1/security/dummy.c --- linux-2.5.59.w0/security/dummy.c Thu Jan 30 21:43:00 2003 +++ linux-2.5.59.w1/security/dummy.c Thu Jan 30 22:14:55 2003 @@ -21,6 +21,7 @@ #include #include #include +#include static int dummy_ptrace (struct task_struct *parent, struct task_struct *child) { @@ -625,6 +626,36 @@ #ifdef CONFIG_SECURITY_NETWORK +static int dummy_open_request_alloc_security(struct open_request * req) +{ + req->security = NULL; + return 0; +} + +static void dummy_open_request_free_security(struct open_request * req) +{ + return; +} + +static void dummy_tcp_connection_request(struct sock *sk, struct sk_buff * skb, + struct open_request *req) +{ + return; +} + +static void dummy_tcp_synack(struct sock *sk, struct sk_buff * skb, + struct open_request *req) +{ + return; +} + +static void dummy_tcp_create_openreq_child(struct sock *sk, struct sock *newsk, + struct sk_buff *skb, + struct open_request *req) +{ + return; +} + static int dummy_unix_stream_connect (struct socket *sock, struct socket *other, struct sock *newsk) @@ -923,6 +954,11 @@ set_to_dummy_if_null(ops, netlink_recv); set_to_dummy_if_null(ops, ip_decode_options); #ifdef CONFIG_SECURITY_NETWORK + set_to_dummy_if_null(ops, open_request_alloc_security); + set_to_dummy_if_null(ops, open_request_free_security); + set_to_dummy_if_null(ops, tcp_connection_request); + set_to_dummy_if_null(ops, tcp_synack); + set_to_dummy_if_null(ops, tcp_create_openreq_child); set_to_dummy_if_null(ops, unix_stream_connect); set_to_dummy_if_null(ops, unix_may_send); set_to_dummy_if_null(ops, socket_create); From davem@redhat.com Thu Jan 30 15:27:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Jan 2003 15:28:05 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UNRs3v025200 for ; Thu, 30 Jan 2003 15:27:55 -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 PAA22974; Thu, 30 Jan 2003 15:19:47 -0800 Date: Thu, 30 Jan 2003 15:19:47 -0800 (PST) Message-Id: <20030130.151947.48545419.davem@redhat.com> To: jmorris@intercode.com.au Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-security-module@wirex.com Subject: Re: [PATCH] LSM networking: netlink hooks for 2.5.59 (6/8) From: "David S. Miller" In-Reply-To: References: X-FalunGong: Information control. 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 X-archive-position: 1637 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev This one is not acceptable, you're adding a function call to every netlink SKB receive even in the case where security is disabled. Capability testing is a very simple bit test, there is no justification for calling these cap_netlink_{send,recv}() things externally for such a simple operation when security is disabled. It is things like this that make me still totally hate the networking security changes. It is like a virus that is spreading throughout the entire tree. It is a bunch of strange tests that have to be maintained which do external calls to modules that are not even in the source tree so I can't even see how the callbacks are used (no, the fact that there is documentation of the callback doesn't change this issue, and no I'm not going to some site to download a bunch of security modules everytime I need to make changes in these areas). Frankly, while I'm very happy about the fixup of the security overhead, these changes are still way too invasive. This stuff is garbage. From davem@redhat.com Thu Jan 30 15:34:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Jan 2003 15:34:10 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UNY23v025638 for ; Thu, 30 Jan 2003 15:34: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 PAA22988; Thu, 30 Jan 2003 15:25:59 -0800 Date: Thu, 30 Jan 2003 15:25:58 -0800 (PST) Message-Id: <20030130.152558.81554884.davem@redhat.com> To: jmorris@intercode.com.au Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-security-module@wirex.com Subject: Re: [PATCH] LSM networking: tcp hooks for 2.5.59 (8/8) From: "David S. Miller" In-Reply-To: References: X-FalunGong: Information control. 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 X-archive-position: 1638 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev No, no, and no. This stuff will not pass. There is no way in hell we're going to insert this security crap into the actual protocol implementations. I was right in seeing this as a virus that will eventually infect the whole tree. None of these security modules should know jack anything about open requests and other TCP internals. This stuff is totally unmaintainable garbage. And I do not want to hear "well how can we implement xxx which we need for yyy" because it isn't my problem that you can't figure out a clean way to do this stuff. Linus would similarly barf if he was given a patch that added hooks like "security_ext2_foo()". I totally reject this networking security stuff for 2.6.x From jmorris@intercode.com.au Thu Jan 30 16:11:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Jan 2003 16:11:25 -0800 (PST) Received: from blackbird.intercode.com.au (blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0V0BB3v026436 for ; Thu, 30 Jan 2003 16:11:13 -0800 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id LAA32100; Fri, 31 Jan 2003 11:15:22 +1100 Date: Fri, 31 Jan 2003 11:15:22 +1100 (EST) From: James Morris To: "David S. Miller" cc: kuznet@ms2.inr.ac.ru, , Subject: Re: [PATCH] LSM networking: tcp hooks for 2.5.59 (8/8) In-Reply-To: <20030130.152558.81554884.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1639 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@intercode.com.au Precedence: bulk X-list: netdev On Thu, 30 Jan 2003, David S. Miller wrote: > I totally reject this networking security stuff for 2.6.x Ok. Thanks for looking at it. - James -- James Morris From davem@redhat.com Thu Jan 30 16:24:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Jan 2003 16:24:53 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0V0Oi3v026933 for ; Thu, 30 Jan 2003 16:24: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 QAA23084; Thu, 30 Jan 2003 16:16:39 -0800 Date: Thu, 30 Jan 2003 16:16:38 -0800 (PST) Message-Id: <20030130.161638.83467438.davem@redhat.com> To: jmorris@intercode.com.au Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-security-module@wirex.com Subject: Re: [PATCH] LSM networking: tcp hooks for 2.5.59 (8/8) From: "David S. Miller" In-Reply-To: References: <20030130.152558.81554884.davem@redhat.com> X-FalunGong: Information control. 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 X-archive-position: 1640 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: James Morris Date: Fri, 31 Jan 2003 11:15:22 +1100 (EST) On Thu, 30 Jan 2003, David S. Miller wrote: > I totally reject this networking security stuff for 2.6.x Ok. Thanks for looking at it. James, do not take my comments too harshly please. I realize the amount of work that went into these changes and I do appreciate that. The big problem is that the TCP bits had no apparent attempt to abstract things out. What is going to happen, for example, when net protocol FOO makes mini-sockets too? Will we make more security_FOO_*() hooks or will we get smart and abstract this technique somehow? See, if I saw things like: openreq = sock_make_minisock(sizeof(struct openreq)); then the changes would be more acceptable. The net/socket.c stuff looks fine. All the stuff that makes decisions based upon packets is highly questionable. Netfilter can do all of this work, it even has connection tracking infrastructure for TCP connections. I think with the net/socket.c stuff to take care of the user side and some ingenious netfilter hacks for the packet side, you could accomplish everything you need for the security stuff. If you think this is implementable, then I'll happily accept the net/socket.c stuff and even the af_unix hack, with the assumption being that the rest can be handled by netfilter or something similar. Oh yes, I'd also take the netlink capability thing too as long as it was inlined properly for the no-security case. From jagana@us.ibm.com Thu Jan 30 17:00:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Jan 2003 17:00:12 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0V1083v027556 for ; Thu, 30 Jan 2003 17:00:09 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e33.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0V17QE0043708; Thu, 30 Jan 2003 20:07:26 -0500 Received: from d03nm036.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0V16925137316; Thu, 30 Jan 2003 18:06:10 -0700 Subject: [ANNOUNCE] Linux DHCPv6 release available for download To: netdev@oss.sgi.com, linux-net@vger.kernel.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Venkata Jagana Date: Thu, 30 Jan 2003 17:05:56 -0800 X-MIMETrack: Serialize by Router on D03NM036/03/M/IBM(Release 6.0 [IBM]|December 16, 2002) at 01/30/2003 18:06:10 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-archive-position: 1641 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jagana@us.ibm.com Precedence: bulk X-list: netdev The DHCPv6 (DHCP for IPv6) code (ver 0.1) is now available for download at SourceForge: http://www.sourceforge.net/projects/dhcpv6 Linux DHCPv6 project is created to provide IETF standard conformant DHCPv6 protocol implementation for Linux. The current version of the code provides 'partial' Client/Server support for address assignment. Additional messages support is currently under development. The current status of the project, at a high level, is provided below but for further details, please visit the DHCPv6 project page at SourceForge. On behalf of DHCPv6 team, Regards, Venkat ---------------------------------------------------------------- Venkata R Jagana IBM Linux Technology Center Beaverton jagana@us.ibm.com ---------------------------------------------------------------- Current Status: Features implemented and validated IPv6 address Assignment - Server configuration file support - Server lease file support for saving all the client's IPv6 address binding info - Client IPv6 address assignment and temporary IPv6 address assignment support on the same link - Supported Options: Rapid commit, Server Preference, Information Request ClientID, ServerID , IA_NA , IA_TA , IA_ADDR , Status support - Solicit/Request/Advertise/Reply/Infomation-request messages support Features available but not validated: - Renew/Rebind messages - Prefix delegation option support - DNS server option support - Request option support Features under development: - Timer events support T1(renew)/T2(rebind)/expired(address prefered-lifetime reached)/deleted(address valid-lifetime reached) - Release/Decline/Confirm messages support - Client configuration file support - Client lease file support - Merge prefix delegation configuration file and IPv6 address assignment file Features to be addressed: - Unicast/Elapsed time/Authentication/User Class/Vendor Class/Interface-ID option support - Relay agent support. - Reconfig/Relay messages support. From jmorris@intercode.com.au Fri Jan 31 16:05:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 31 Jan 2003 16:05:40 -0800 (PST) Received: from blackbird.intercode.com.au (blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1105R3v001469 for ; Fri, 31 Jan 2003 16:05:29 -0800 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id LAA04585; Sat, 1 Feb 2003 11:12:33 +1100 Date: Sat, 1 Feb 2003 11:12:33 +1100 (EST) From: James Morris To: "David S. Miller" cc: kuznet@ms2.inr.ac.ru, , Subject: Re: [PATCH] LSM networking: tcp hooks for 2.5.59 (8/8) In-Reply-To: <20030130.161638.83467438.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1642 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@intercode.com.au Precedence: bulk X-list: netdev On Thu, 30 Jan 2003, David S. Miller wrote: > If you think this is implementable, then I'll happily accept the > net/socket.c stuff and even the af_unix hack, with the assumption > being that the rest can be handled by netfilter or something similar. > Oh yes, I'd also take the netlink capability thing too as long as it > was inlined properly for the no-security case. Explicitly labeled networking and the SELinux extended sockets API probably can't be supported with just these hooks and Netfilter. However, this subset of the networking hooks will still be very useful in general, and we'll rework the patch accordingly. - James -- James Morris