From jagana@us.ibm.com Thu Oct 31 22:51:12 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 31 Oct 2002 22:52:40 -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 gA16onuR024423 for ; Thu, 31 Oct 2002 22:51:11 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e32.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gA16pHRs031762; Fri, 1 Nov 2002 01:51:17 -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 gA16pFpQ028286; Thu, 31 Oct 2002 23:51:16 -0700 From: "Venkata Jagana" Importance: Normal Sensitivity: Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.45 To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Cc: davem@redhat.com, kkumar@beaverton.ibm.com.sgi.com, kuznet@ms2.inr.ac.ru, ajtuomin@tml.hut.fi, lpetande@tml.hut.fi, netdev@oss.sgi.com, linux-kernel@vger.kernel.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 31 Oct 2002 22:51:13 -0800 X-MIMETrack: Serialize by Router on D03NM036/03/M/IBM(Release 5.0.10 |March 22, 2002) at 10/31/2002 11:51:15 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-archive-position: 1057 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 > Registration process should live in user space. I believe even the registration part should belong to kernel and here are the reasons why. The Home Agent needs to consult the Binding Cache, which is stored upon successful completion of Binding updates registration, for tunnelling the packets belonging to the mobile nodes away from home. In addition, as part of the registration process but before caching the binding updates, the Home Agent may need to perform duplicate address detection (DAD), if needed, through ND protocol messages. And also, IPSec is mandated for Home Agent registration and so, Home Agent must use IPSec for responding to Binding updates from Mobile Nodes. Thanks, Venkat ---------------------------------------------------------------- Venkata R Jagana IBM Linux Technology Centre, Beaverton jagana@us.ibm.com Tel: (503) 578 3430 T/L 775-3430 From respuesta@lapromocion.com Fri Nov 1 00:01:45 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Nov 2002 00:01:47 -0800 (PST) Received: from lapromocion.com ([200.68.135.70]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA181TuR025425 for ; Fri, 1 Nov 2002 00:01:44 -0800 Received: from operador.lapromocion.com ([200.68.135.70]) by lapromocion.com ([200.68.135.70]) with SMTP (MDaemon.PRO.v6.0.7.T) for ; Fri, 01 Nov 2002 01:56:12 -0500 Message-Id: <5.1.0.14.0.20021031160459.037fab48@200.68.135.70> X-Sender: webpro@200.68.135.70 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 01 Nov 2002 01:41:00 -0500 To: (Recipient list suppressed) From: OMNI Subject: Buscamos Distribuidores !!! Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_55847915==_" X-MDRemoteIP: 200.68.135.70 X-Return-Path: respuesta@lapromocion.com X-MDaemon-Deliver-To: netdev@oss.sgi.com X-archive-position: 1058 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@lapromocion.com Precedence: bulk X-list: netdev --=====================_55847915==_ Content-Type: text/plain; charset="us-ascii" --=====================_55847915==_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit omnimail.gif
Si usted desea ser eliminado de nuestra lista de correo haga click aquí.
--=====================_55847915==_ Content-Type: text/plain; charset="us-ascii" --=====================_55847915==_-- From yoshfuji@linux-ipv6.org Fri Nov 1 00:48:46 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Nov 2002 00:49:44 -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 gA18mSuR026467 for ; Fri, 1 Nov 2002 00:48:45 -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 gA18mXGR024713; Fri, 1 Nov 2002 17:48:33 +0900 Date: Fri, 01 Nov 2002 17:48:32 +0900 (JST) Message-Id: <20021101.174832.44646503.yoshfuji@linux-ipv6.org> To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com CC: davem@redhat.com, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20021031.164940.672083668.yoshfuji@linux-ipv6.org> 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: 1059 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 (at Thu, 31 Oct 2002 10:24:11 +0200 (EET)), Pekka Savola says: > > set default to 0 (don't use it) for now is ok? > > Sure, ok for me. (I'm assuming we'll be able to change the default at > some point when more knowledge and experience is gained but we're talking > about at least a year or two here, I think). Ok, here's revised one. - sync with linux-2.5.45. - change default value for use_tempaddr sysctl to 0 (don't generate and use temprary addresses by default) Index: Documentation/networking/ip-sysctl.txt =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux25/Documentation/networking/ip-sysctl.txt,v retrieving revision 1.1.1.3 retrieving revision 1.1.1.3.8.2 diff -u -r1.1.1.3 -r1.1.1.3.8.2 --- Documentation/networking/ip-sysctl.txt 30 Oct 2002 09:43:01 -0000 1.1.1.3 +++ Documentation/networking/ip-sysctl.txt 1 Nov 2002 08:29:09 -0000 1.1.1.3.8.2 @@ -611,6 +611,37 @@ 0 to disable any limiting, otherwise the maximal rate in jiffies(1) Default: 100 +use_tempaddr - INTEGER + Preference for Privacy Extensions (RFC3041). + <= 0 : disable Privacy Extensions + == 1 : enable Privacy Extensions, but prefer public + addresses over temporary addresses. + > 1 : enable Privacy Extensions and prefer temporary + addresses over public addresses. + Default: 0 (for most devices) + -1 (for point-to-point devices and loopback devices) + +temp_valid_lft - INTEGER + valid lifetime (in seconds) for temporary addresses. + Default: 604800 (7 days) + +temp_prefered_lft - INTEGER + Preferred lifetime (in seconds) for temorary addresses. + Default: 86400 (1 day) + +max_desync_factor - INTEGER + Maximum value for DESYNC_FACTOR, which is a random value + that ensures that clients don't synchronize with each + other and generage new addresses at exactly the same time. + value is in seconds. + Default: 600 + +regen_max_retry - INTEGER + Number of attempts before give up attempting to generate + valid temporary addresses. + Default: 5 + + IPv6 Update by: Pekka Savola YOSHIFUJI Hideaki / USAGI Project Index: include/linux/rtnetlink.h =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux25/include/linux/rtnetlink.h,v retrieving revision 1.1.1.2 retrieving revision 1.1.1.2.8.1 diff -u -r1.1.1.2 -r1.1.1.2.8.1 --- include/linux/rtnetlink.h 30 Oct 2002 09:43:04 -0000 1.1.1.2 +++ include/linux/rtnetlink.h 1 Nov 2002 08:15:13 -0000 1.1.1.2.8.1 @@ -335,6 +335,7 @@ /* ifa_flags */ #define IFA_F_SECONDARY 0x01 +#define IFA_F_TEMPORARY IFA_F_SECONDARY #define IFA_F_DEPRECATED 0x20 #define IFA_F_TENTATIVE 0x40 Index: include/linux/sysctl.h =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux25/include/linux/sysctl.h,v retrieving revision 1.1.1.3 retrieving revision 1.1.1.3.8.1 diff -u -r1.1.1.3 -r1.1.1.3.8.1 --- include/linux/sysctl.h 30 Oct 2002 09:43:03 -0000 1.1.1.3 +++ include/linux/sysctl.h 1 Nov 2002 08:15:13 -0000 1.1.1.3.8.1 @@ -384,7 +384,12 @@ NET_IPV6_DAD_TRANSMITS=7, NET_IPV6_RTR_SOLICITS=8, NET_IPV6_RTR_SOLICIT_INTERVAL=9, - NET_IPV6_RTR_SOLICIT_DELAY=10 + NET_IPV6_RTR_SOLICIT_DELAY=10, + NET_IPV6_USE_TEMPADDR=11, + NET_IPV6_TEMP_VALID_LFT=12, + NET_IPV6_TEMP_PREFERED_LFT=13, + NET_IPV6_REGEN_MAX_RETRY=14, + NET_IPV6_MAX_DESYNC_FACTOR=15 }; /* /proc/sys/net/ipv6/icmp */ Index: include/net/addrconf.h =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux25/include/net/addrconf.h,v retrieving revision 1.1.1.2 retrieving revision 1.1.1.2.10.1 diff -u -r1.1.1.2 -r1.1.1.2.10.1 --- include/net/addrconf.h 19 Oct 2002 05:51:09 -0000 1.1.1.2 +++ include/net/addrconf.h 1 Nov 2002 08:15:13 -0000 1.1.1.2.10.1 @@ -6,6 +6,11 @@ #define MAX_RTR_SOLICITATIONS 3 #define RTR_SOLICITATION_INTERVAL (4*HZ) +#define TEMP_VALID_LIFETIME (7*86400) +#define TEMP_PREFERRED_LIFETIME (86400) +#define REGEN_MAX_RETRY (5) +#define MAX_DESYNC_FACTOR (600) + #define ADDR_CHECK_FREQUENCY (120*HZ) struct prefix_info { Index: include/net/if_inet6.h =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux25/include/net/if_inet6.h,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.18.1 diff -u -r1.1.1.1 -r1.1.1.1.18.1 --- include/net/if_inet6.h 7 Oct 2002 10:22:46 -0000 1.1.1.1 +++ include/net/if_inet6.h 1 Nov 2002 08:15:13 -0000 1.1.1.1.18.1 @@ -43,6 +43,12 @@ struct inet6_ifaddr *lst_next; /* next addr in addr_lst */ struct inet6_ifaddr *if_next; /* next addr in inet6_dev */ +#ifdef CONFIG_IPV6_PRIVACY + struct inet6_ifaddr *tmp_next; /* next addr in tempaddr_lst */ + struct inet6_ifaddr *ifpub; + int regen_count; +#endif + int dead; }; @@ -86,7 +92,13 @@ int rtr_solicits; int rtr_solicit_interval; int rtr_solicit_delay; - +#ifdef CONFIG_IPV6_PRIVACY + int use_tempaddr; + int temp_valid_lft; + int temp_prefered_lft; + int regen_max_retry; + int max_desync_factor; +#endif void *sysctl; }; @@ -100,6 +112,13 @@ atomic_t refcnt; __u32 if_flags; int dead; + +#ifdef CONFIG_IPV6_PRIVACY + u8 rndid[8]; + u8 entropy[8]; + struct timer_list regen_timer; + struct inet6_ifaddr *tempaddr_list; +#endif struct neigh_parms *nd_parms; struct inet6_dev *next; Index: net/ipv6/Kconfig =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux25/net/ipv6/Kconfig,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.2.3 diff -u -r1.1.1.1 -r1.1.1.1.2.3 --- net/ipv6/Kconfig 31 Oct 2002 04:02:51 -0000 1.1.1.1 +++ net/ipv6/Kconfig 1 Nov 2002 08:36:47 -0000 1.1.1.1.2.3 @@ -1,5 +1,21 @@ # # IPv6 configuration # +config IPV6_PRIVACY + bool "IPv6: Privacy Extensions (RFC 3041) support" + depends on IPV6 + ---help--- + Privacy Extensions for Stateless Address Autoconfiguration in IPv6 + support. With this option, additional periodically-alter + pseudo-random global-scope unicast address(es) will assigned to + your interface(s). + + By default, kernel do not generate temporary addresses. + To use temporary addresses, do + + echo 2 >/proc/sys/net/ipv6/conf/all/use_tempaddr + + See for details. + source "net/ipv6/netfilter/Kconfig" Index: net/ipv6/addrconf.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux25/net/ipv6/addrconf.c,v retrieving revision 1.1.1.4 retrieving revision 1.1.1.4.8.2 diff -u -r1.1.1.4 -r1.1.1.4.8.2 --- net/ipv6/addrconf.c 30 Oct 2002 09:43:18 -0000 1.1.1.4 +++ net/ipv6/addrconf.c 1 Nov 2002 08:29:09 -0000 1.1.1.4.8.2 @@ -28,6 +28,8 @@ * packets. * YOSHIFUJI Hideaki @USAGI : improved accuracy of * address validation timer. + * YOSHIFUJI Hideaki @USAGI : Privacy Extensions (RFC3041) + * support. */ #include @@ -62,6 +64,12 @@ #include #include +#ifdef CONFIG_IPV6_PRIVACY +#include +#include +#include +#endif + #include #define IPV6_MAX_ADDRESSES 16 @@ -83,6 +91,16 @@ int inet6_dev_count; int inet6_ifa_count; +#ifdef CONFIG_IPV6_PRIVACY +static int __ipv6_regen_rndid(struct inet6_dev *idev); +static int __ipv6_try_regen_rndid(struct inet6_dev *idev, struct in6_addr *tmpaddr); +static void ipv6_regen_rndid(unsigned long data); + +static int desync_factor = MAX_DESYNC_FACTOR * HZ; +#endif + +int ipv6_count_addresses(struct inet6_dev *idev); + /* * Configured unicast address hash table */ @@ -119,6 +137,13 @@ MAX_RTR_SOLICITATIONS, /* router solicits */ RTR_SOLICITATION_INTERVAL, /* rtr solicit interval */ MAX_RTR_SOLICITATION_DELAY, /* rtr solicit delay */ +#ifdef CONFIG_IPV6_PRIVACY + .use_tempaddr = 0, + .temp_valid_lft = TEMP_VALID_LIFETIME, + .temp_prefered_lft = TEMP_PREFERRED_LIFETIME, + .regen_max_retry = REGEN_MAX_RETRY, + .max_desync_factor = MAX_DESYNC_FACTOR, +#endif }; static struct ipv6_devconf ipv6_devconf_dflt = @@ -133,6 +158,13 @@ MAX_RTR_SOLICITATIONS, /* router solicits */ RTR_SOLICITATION_INTERVAL, /* rtr solicit interval */ MAX_RTR_SOLICITATION_DELAY, /* rtr solicit delay */ +#ifdef CONFIG_IPV6_PRIVACY + .use_tempaddr = 0, + .temp_valid_lft = TEMP_VALID_LIFETIME, + .temp_prefered_lft = TEMP_PREFERRED_LIFETIME, + .regen_max_retry = REGEN_MAX_RETRY, + .max_desync_factor = MAX_DESYNC_FACTOR, +#endif }; int ipv6_addr_type(struct in6_addr *addr) @@ -272,6 +304,24 @@ /* We refer to the device */ dev_hold(dev); +#ifdef CONFIG_IPV6_PRIVACY + get_random_bytes(ndev->rndid, sizeof(ndev->rndid)); + get_random_bytes(ndev->entropy, sizeof(ndev->entropy)); + init_timer(&ndev->regen_timer); + ndev->regen_timer.function = ipv6_regen_rndid; + ndev->regen_timer.data = (unsigned long) ndev; + if ((dev->flags&IFF_LOOPBACK) || + dev->type == ARPHRD_TUNNEL || + dev->type == ARPHRD_SIT) { + printk(KERN_INFO + "Disabled Privacy Extensions on device %p(%s)\n", + dev, dev->name); + ndev->cnf.use_tempaddr = -1; + } else { + __ipv6_regen_rndid(ndev); + } +#endif + write_lock_bh(&addrconf_lock); dev->ip6_ptr = ndev; /* One reference from device */ @@ -396,6 +446,18 @@ /* Add to inet6_dev unicast addr list. */ ifa->if_next = idev->addr_list; idev->addr_list = ifa; + +#ifdef CONFIG_IPV6_PRIVACY + ifa->regen_count = 0; + if (ifa->flags&IFA_F_TEMPORARY) { + ifa->tmp_next = idev->tempaddr_list; + idev->tempaddr_list = ifa; + in6_ifa_hold(ifa); + } else { + ifa->tmp_next = NULL; + } +#endif + in6_ifa_hold(ifa); write_unlock_bh(&idev->lock); read_unlock(&addrconf_lock); @@ -417,6 +479,15 @@ ifp->dead = 1; +#ifdef CONFIG_IPV6_PRIVACY + spin_lock_bh(&ifp->lock); + if (ifp->ifpub) { + __in6_ifa_put(ifp->ifpub); + ifp->ifpub = NULL; + } + spin_unlock_bh(&ifp->lock); +#endif + write_lock_bh(&addrconf_hash_lock); for (ifap = &inet6_addr_lst[hash]; (ifa=*ifap) != NULL; ifap = &ifa->lst_next) { @@ -430,6 +501,24 @@ write_unlock_bh(&addrconf_hash_lock); write_lock_bh(&idev->lock); +#ifdef CONFIG_IPV6_PRIVACY + if (ifp->flags&IFA_F_TEMPORARY) { + for (ifap = &idev->tempaddr_list; (ifa=*ifap) != NULL; + ifap = &ifa->tmp_next) { + if (ifa == ifp) { + *ifap = ifa->tmp_next; + if (ifp->ifpub) { + __in6_ifa_put(ifp->ifpub); + ifp->ifpub = NULL; + } + __in6_ifa_put(ifp); + ifa->tmp_next = NULL; + break; + } + } + } +#endif + for (ifap = &idev->addr_list; (ifa=*ifap) != NULL; ifap = &ifa->if_next) { if (ifa == ifp) { @@ -450,6 +539,96 @@ in6_ifa_put(ifp); } +#ifdef CONFIG_IPV6_PRIVACY +static int ipv6_create_tempaddr(struct inet6_ifaddr *ifp, struct inet6_ifaddr *ift) +{ + struct inet6_dev *idev; + struct in6_addr addr, *tmpaddr; + unsigned long tmp_prefered_lft, tmp_valid_lft; + int tmp_plen; + int ret = 0; + + if (ift) { + spin_lock_bh(&ift->lock); + memcpy(&addr.s6_addr[8], &ift->addr.s6_addr[8], 8); + spin_unlock_bh(&ift->lock); + tmpaddr = &addr; + } else { + tmpaddr = NULL; + } +retry: + spin_lock_bh(&ifp->lock); + in6_ifa_hold(ifp); + idev = ifp->idev; + in6_dev_hold(idev); + memcpy(addr.s6_addr, ifp->addr.s6_addr, 8); + write_lock(&idev->lock); + if (idev->cnf.use_tempaddr <= 0) { + write_unlock(&idev->lock); + spin_unlock_bh(&ifp->lock); + printk(KERN_INFO + "ipv6_create_tempaddr(): use_tempaddr is disabled.\n"); + in6_dev_put(idev); + in6_ifa_put(ifp); + ret = -1; + goto out; + } + if (ifp->regen_count++ >= idev->cnf.regen_max_retry) { + idev->cnf.use_tempaddr = -1; /*XXX*/ + write_unlock(&idev->lock); + spin_unlock_bh(&ifp->lock); + printk(KERN_WARNING + "ipv6_create_tempaddr(): regeneration time exceeded. disabled temporary address support.\n"); + in6_dev_put(idev); + in6_ifa_put(ifp); + ret = -1; + goto out; + } + if (__ipv6_try_regen_rndid(idev, tmpaddr) < 0) { + write_unlock(&idev->lock); + spin_unlock_bh(&ifp->lock); + printk(KERN_WARNING + "ipv6_create_tempaddr(): regeneration of randomized interface id failed.\n"); + in6_dev_put(idev); + in6_ifa_put(ifp); + ret = -1; + goto out; + } + memcpy(&addr.s6_addr[8], idev->rndid, 8); + tmp_valid_lft = min_t(__u32, + ifp->valid_lft, + idev->cnf.temp_valid_lft); + tmp_prefered_lft = min_t(__u32, + ifp->prefered_lft, + idev->cnf.temp_prefered_lft - desync_factor / HZ); + tmp_plen = ifp->prefix_len; + write_unlock(&idev->lock); + spin_unlock_bh(&ifp->lock); + ift = ipv6_count_addresses(idev) < IPV6_MAX_ADDRESSES ? + ipv6_add_addr(idev, &addr, tmp_plen, + ipv6_addr_type(&addr)&IPV6_ADDR_SCOPE_MASK, IFA_F_TEMPORARY) : 0; + if (!ift) { + in6_dev_put(idev); + in6_ifa_put(ifp); + printk(KERN_INFO + "ipv6_create_tempaddr(): retry temporary address regeneration.\n"); + tmpaddr = &addr; + goto retry; + } + spin_lock_bh(&ift->lock); + ift->ifpub = ifp; + ift->valid_lft = tmp_valid_lft; + ift->prefered_lft = tmp_prefered_lft; + ift->tstamp = ifp->tstamp; + spin_unlock_bh(&ift->lock); + addrconf_dad_start(ift); + in6_ifa_put(ift); + in6_dev_put(idev); +out: + return ret; +} +#endif + /* * Choose an apropriate source address * should do: @@ -458,6 +637,22 @@ * an address of the attached interface * iii) don't use deprecated addresses */ +static int inline ipv6_saddr_pref(const struct inet6_ifaddr *ifp, u8 invpref) +{ + int pref; + pref = ifp->flags&IFA_F_DEPRECATED ? 0 : 2; +#ifdef CONFIG_IPV6_PRIVACY + pref |= (ifp->flags^invpref)&IFA_F_TEMPORARY ? 0 : 1; +#endif + return pref; +} + +#ifdef CONFIG_IPV6_PRIVACY +#define IPV6_GET_SADDR_MAXSCORE(score) ((score) == 3) +#else +#define IPV6_GET_SADDR_MAXSCORE(score) (score) +#endif + int ipv6_get_saddr(struct dst_entry *dst, struct in6_addr *daddr, struct in6_addr *saddr) { @@ -468,6 +663,7 @@ struct inet6_dev *idev; struct rt6_info *rt; int err; + int hiscore = -1, score; rt = (struct rt6_info *) dst; if (rt) @@ -497,17 +693,27 @@ read_lock_bh(&idev->lock); for (ifp=idev->addr_list; ifp; ifp=ifp->if_next) { if (ifp->scope == scope) { - if (!(ifp->flags & (IFA_F_DEPRECATED|IFA_F_TENTATIVE))) { - in6_ifa_hold(ifp); + if (ifp->flags&IFA_F_TENTATIVE) + continue; +#ifdef CONFIG_IPV6_PRIVACY + score = ipv6_saddr_pref(ifp, idev->cnf.use_tempaddr > 1 ? IFA_F_TEMPORARY : 0); +#else + score = ipv6_saddr_pref(ifp, 0); +#endif + if (score <= hiscore) + continue; + + if (match) + in6_ifa_put(match); + match = ifp; + hiscore = score; + in6_ifa_hold(ifp); + + if (IPV6_GET_SADDR_MAXSCORE(score)) { read_unlock_bh(&idev->lock); read_unlock(&addrconf_lock); goto out; } - - if (!match && !(ifp->flags & IFA_F_TENTATIVE)) { - match = ifp; - in6_ifa_hold(ifp); - } } } read_unlock_bh(&idev->lock); @@ -530,16 +736,26 @@ read_lock_bh(&idev->lock); for (ifp=idev->addr_list; ifp; ifp=ifp->if_next) { if (ifp->scope == scope) { - if (!(ifp->flags&(IFA_F_DEPRECATED|IFA_F_TENTATIVE))) { - in6_ifa_hold(ifp); + if (ifp->flags&IFA_F_TENTATIVE) + continue; +#ifdef CONFIG_IPV6_PRIVACY + score = ipv6_saddr_pref(ifp, idev->cnf.use_tempaddr > 1 ? IFA_F_TEMPORARY : 0); +#else + score = ipv6_saddr_pref(ifp, 0); +#endif + if (score <= hiscore) + continue; + + if (match) + in6_ifa_put(match); + match = ifp; + hiscore = score; + in6_ifa_hold(ifp); + + if (IPV6_GET_SADDR_MAXSCORE(score)) { read_unlock_bh(&idev->lock); goto out_unlock_base; } - - if (!match && !(ifp->flags&IFA_F_TENTATIVE)) { - match = ifp; - in6_ifa_hold(ifp); - } } } read_unlock_bh(&idev->lock); @@ -551,19 +767,12 @@ read_unlock(&dev_base_lock); out: - if (ifp == NULL) { - ifp = match; - match = NULL; - } - err = -EADDRNOTAVAIL; - if (ifp) { - ipv6_addr_copy(saddr, &ifp->addr); + if (match) { + ipv6_addr_copy(saddr, &match->addr); err = 0; - in6_ifa_put(ifp); - } - if (match) in6_ifa_put(match); + } return err; } @@ -653,6 +862,21 @@ ifp->flags |= IFA_F_TENTATIVE; spin_unlock_bh(&ifp->lock); in6_ifa_put(ifp); +#ifdef CONFIG_IPV6_PRIVACY + } else if (ifp->flags&IFA_F_TEMPORARY) { + struct inet6_ifaddr *ifpub; + spin_lock_bh(&ifp->lock); + ifpub = ifp->ifpub; + if (ifpub) { + in6_ifa_hold(ifpub); + spin_unlock_bh(&ifp->lock); + ipv6_create_tempaddr(ifpub, ifp); + in6_ifa_put(ifpub); + } else { + spin_unlock_bh(&ifp->lock); + } + ipv6_del_addr(ifp); +#endif } else ipv6_del_addr(ifp); } @@ -718,6 +942,108 @@ return err; } +#ifdef CONFIG_IPV6_PRIVACY +/* (re)generation of randomized interface identifier (RFC 3041 3.2, 3.5) */ +static int __ipv6_regen_rndid(struct inet6_dev *idev) +{ + struct net_device *dev; + u8 eui64[8]; + u8 digest[16]; + struct crypto_tfm *tfm; + struct scatterlist sg[2]; + + sg[0].page = virt_to_page(idev->entropy); + sg[0].offset = ((long) idev->entropy & ~PAGE_MASK); + sg[0].length = 8; + sg[1].page = virt_to_page(eui64); + sg[1].offset = ((long) eui64 & ~PAGE_MASK); + sg[1].length = 8; + + if (!del_timer(&idev->regen_timer)) + in6_dev_hold(idev); + + dev = idev->dev; + + if (ipv6_generate_eui64(eui64, dev)) { + printk(KERN_INFO + "__ipv6_regen_rndid(idev=%p): cannot get EUI64 identifier; use random bytes.\n", + idev); + get_random_bytes(eui64, sizeof(eui64)); + } +regen: + tfm = crypto_alloc_tfm("md5", 0); + if (tfm == NULL) { + if (net_ratelimit()) + printk(KERN_WARNING + "failed to load transform for md5\n"); + in6_dev_put(idev); + return -1; + } + crypto_digest_init(tfm); + crypto_digest_update(tfm, sg, 2); + crypto_digest_final(tfm, digest); + crypto_free_tfm(tfm); + + memcpy(idev->rndid, &digest[0], 8); + idev->rndid[0] &= ~0x02; + memcpy(idev->entropy, &digest[8], 8); + + /* + * : + * check if generated address is not inappropriate + * + * - Reserved subnet anycast (RFC 2526) + * 11111101 11....11 1xxxxxxx + * - ISATAP (draft-ietf-ngtrans-isatap-01.txt) 4.3 + * 00-00-5E-FE-xx-xx-xx-xx + * - value 0 + * - XXX: already assigned to an address on the device + */ + if (idev->rndid[0] == 0xfd && + (idev->rndid[1]&idev->rndid[2]&idev->rndid[3]&idev->rndid[4]&idev->rndid[5]&idev->rndid[6]) && + (idev->rndid[7]&0x80)) + goto regen; + if ((idev->rndid[0]|idev->rndid[1]) == 0) { + if (idev->rndid[2] == 0x5e && idev->rndid[3] == 0xfe) + goto regen; + if ((idev->rndid[2]|idev->rndid[3]|idev->rndid[4]|idev->rndid[5]|idev->rndid[6]|idev->rndid[7]) == 0x00) + goto regen; + } + + if (time_before(idev->regen_timer.expires, jiffies)) { + idev->regen_timer.expires = 0; + printk(KERN_WARNING + "__ipv6_regen_rndid(): too short regeneration interval; timer diabled for %s.\n", + idev->dev->name); + in6_dev_put(idev); + return -1; + } + + add_timer(&idev->regen_timer); + return 0; +} + +static void ipv6_regen_rndid(unsigned long data) +{ + struct inet6_dev *idev = (struct inet6_dev *) data; + + read_lock_bh(&addrconf_lock); + write_lock_bh(&idev->lock); + if (!idev->dead) + __ipv6_regen_rndid(idev); + write_unlock_bh(&idev->lock); + read_unlock_bh(&addrconf_lock); +} + +static int __ipv6_try_regen_rndid(struct inet6_dev *idev, struct in6_addr *tmpaddr) { + int ret = 0; + + if (tmpaddr && memcmp(idev->rndid, &tmpaddr->s6_addr[8], 8) == 0) + ret = __ipv6_regen_rndid(idev); + return ret; +} +#endif + /* * Add prefix route. */ @@ -889,6 +1215,7 @@ struct inet6_ifaddr * ifp; struct in6_addr addr; int plen; + int create = 0; plen = pinfo->prefix_len >> 3; @@ -924,6 +1251,7 @@ return; } + create = 1; addrconf_dad_start(ifp); } @@ -934,6 +1262,9 @@ if (ifp) { int flags; +#ifdef CONFIG_IPV6_PRIVACY + struct inet6_ifaddr *ift; +#endif spin_lock(&ifp->lock); ifp->valid_lft = valid_lft; @@ -946,6 +1277,42 @@ if (!(flags&IFA_F_TENTATIVE)) ipv6_ifa_notify((flags&IFA_F_DEPRECATED) ? 0 : RTM_NEWADDR, ifp); + +#ifdef CONFIG_IPV6_PRIVACY + read_lock_bh(&in6_dev->lock); + /* update all temporary addresses in the list */ + for (ift=in6_dev->tempaddr_list; ift; ift=ift->tmp_next) { + /* + * When adjusting the lifetimes of an existing + * temporary address, only lower the lifetimes. + * Implementations must not increase the + * lifetimes of an existing temporary address + * when processing a Prefix Information Option. + */ + spin_lock(&ift->lock); + flags = ift->flags; + if (ift->valid_lft > valid_lft && + ift->valid_lft - valid_lft > (jiffies - ift->tstamp) / HZ) + ift->valid_lft = valid_lft + (jiffies - ift->tstamp) / HZ; + if (ift->prefered_lft > prefered_lft && + ift->prefered_lft - prefered_lft > (jiffies - ift->tstamp) / HZ) + ift->prefered_lft = prefered_lft + (jiffies - ift->tstamp) / HZ; + spin_unlock(&ift->lock); + if (!(flags&IFA_F_TENTATIVE)) + ipv6_ifa_notify(0, ift); + } + + if (create && in6_dev->cnf.use_tempaddr > 0) { + /* + * When a new public address is created as described in [ADDRCONF], + * also create a new temporary address. + */ + read_unlock_bh(&in6_dev->lock); + ipv6_create_tempaddr(ifp, NULL); + } else { + read_unlock_bh(&in6_dev->lock); + } +#endif in6_ifa_put(ifp); addrconf_verify(0); } @@ -1910,7 +2277,7 @@ static struct addrconf_sysctl_table { struct ctl_table_header *sysctl_header; - ctl_table addrconf_vars[11]; + ctl_table addrconf_vars[16]; ctl_table addrconf_dev[2]; ctl_table addrconf_conf_dir[2]; ctl_table addrconf_proto_dir[2]; @@ -1957,6 +2324,28 @@ &ipv6_devconf.rtr_solicit_delay, sizeof(int), 0644, NULL, &proc_dointvec_jiffies}, +#ifdef CONFIG_IPV6_PRIVACY + {NET_IPV6_USE_TEMPADDR, "use_tempaddr", + &ipv6_devconf.use_tempaddr, sizeof(int), 0644, NULL, + &proc_dointvec}, + + {NET_IPV6_TEMP_VALID_LFT, "temp_valid_lft", + &ipv6_devconf.temp_valid_lft, sizeof(int), 0644, NULL, + &proc_dointvec}, + + {NET_IPV6_TEMP_PREFERED_LFT, "temp_prefered_lft", + &ipv6_devconf.temp_prefered_lft, sizeof(int), 0644, NULL, + &proc_dointvec}, + + {NET_IPV6_REGEN_MAX_RETRY, "regen_max_retry", + &ipv6_devconf.regen_max_retry, sizeof(int), 0644, NULL, + &proc_dointvec}, + + {NET_IPV6_MAX_DESYNC_FACTOR, "max_desync_factor", + &ipv6_devconf.max_desync_factor, sizeof(int), 0644, NULL, + &proc_dointvec}, +#endif + {0}}, {{NET_PROTO_CONF_ALL, "all", NULL, 0, 0555, addrconf_sysctl.addrconf_vars},{0}}, @@ -1975,7 +2364,7 @@ if (t == NULL) return; memcpy(t, &addrconf_sysctl, sizeof(*t)); - for (i=0; iaddrconf_vars)/sizeof(t->addrconf_vars[0])-1; i++) { + for (i=0; t->addrconf_vars[i].data; i++) { t->addrconf_vars[i].data += (char*)p - (char*)&ipv6_devconf; t->addrconf_vars[i].de = NULL; } -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From davem@redhat.com Fri Nov 1 03:05:40 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Nov 2002 03:05:51 -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 gA1B5TuR030161 for ; Fri, 1 Nov 2002 03:05:40 -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 CAA21634; Fri, 1 Nov 2002 02:56:15 -0800 Date: Fri, 01 Nov 2002 02:56:15 -0800 (PST) Message-Id: <20021101.025615.57289488.davem@redhat.com> To: adam@yggdrasil.com Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: Patch?: linux-2.5.45/net - __secpath_destroy made net depend on ipv4 From: "David S. Miller" In-Reply-To: <20021101034500.A484@baldur.yggdrasil.com> References: <20021101034500.A484@baldur.yggdrasil.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: 1062 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: "Adam J. Richter" Date: Fri, 1 Nov 2002 03:45:00 -0800 In linux-2.5.45, the core networking code calls __secpath_destroy via the static inline routine secpath_put in include/net/xfrm.h. Yes, we are fully aware of this. It will be fixed in due time, please use CONFIG_INET=y kernels for the time being. From adam@yggdrasil.com Fri Nov 1 02:44:59 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Nov 2002 02:45:11 -0800 (PST) Received: from freya.yggdrasil.com (h-64-105-136-52.SNVACAID.covad.net [64.105.136.52]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA1AikuR029642 for ; Fri, 1 Nov 2002 02:44:59 -0800 Received: from baldur.yggdrasil.com (baldur.yggdrasil.com [209.249.10.12]) by freya.yggdrasil.com (8.9.3/8.9.3) with ESMTP id CAA01649; Fri, 1 Nov 2002 02:45:14 -0800 Received: (from adam@localhost) by baldur.yggdrasil.com (8.9.3/8.9.3) id DAA00502; Fri, 1 Nov 2002 03:45:00 -0800 Date: Fri, 1 Nov 2002 03:45:00 -0800 From: "Adam J. Richter" To: netdev@oss.sgi.com, linux-net@vger.kernel.org Cc: linux-kernel@vger.kernel.org Subject: Patch?: linux-2.5.45/net - __secpath_destroy made net depend on ipv4 Message-ID: <20021101034500.A484@baldur.yggdrasil.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline User-Agent: Mutt/1.2i X-archive-position: 1060 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: adam@yggdrasil.com Precedence: bulk X-list: netdev --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In linux-2.5.45, the core networking code calls __secpath_destroy via the static inline routine secpath_put in include/net/xfrm.h. However, __secpath destroy is defined in ipv4. So, I believe that compiling networking without ipv4 will result in a kernel that fails to link (haven't actually tried it), and it also causes problems for anyone who has tweaked ipv4 into a loadable module (which is my case; I posted patches long ago and would be happy to post them again if there is interest). Here is a possible patch that creates a secpath_destroy_hook, although I hope that a cleaner and safer solution can be found (safer because hook variables if multiple modules save and restore the old values of the hook variable in some order other than last-in-first-out). I'm littering linux-kernel with this patch also because I think __secpath_destroy comes from ipsec and those maintainers might not be on the netdev and linux-net lists. -- Adam J. Richter __ ______________ 575 Oroville Road adam@yggdrasil.com \ / Milpitas, California 95035 +1 408 309-6081 | g g d r a s i l United States of America "Free Software For The Rest Of Us." --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="secpath.diffs" --- linux-2.5.45/include/net/xfrm.h 2002-10-30 16:42:22.000000000 -0800 +++ linux/include/net/xfrm.h 2002-10-31 02:48:20.000000000 -0800 @@ -338,12 +338,14 @@ } extern void __secpath_destroy(struct sec_path *sp); +extern void secpath_destroy_noop(struct sec_path *sp); +extern void (*secpath_destroy_hook)(struct sec_path *sp); static inline void secpath_put(struct sec_path *sp) { if (sp && atomic_dec_and_test(&sp->refcnt)) - __secpath_destroy(sp); + (*secpath_destroy_hook)(sp); } extern int __xfrm_policy_check(int dir, struct sk_buff *skb); --- linux-2.5.45/net/core/Makefile 2002-10-30 16:43:43.000000000 -0800 +++ linux/net/core/Makefile 2002-10-31 00:31:25.000000000 -0800 @@ -2,6 +2,8 @@ # Makefile for the Linux networking core. # +export-objs := dev.o netfilter.o profile.o skbuff.o + obj-y := sock.o skbuff.o iovec.o datagram.o scm.o ifeq ($(CONFIG_SYSCTL),y) --- linux-2.5.45/net/core/skbuff.c 2002-10-30 16:43:08.000000000 -0800 +++ linux/net/core/skbuff.c 2002-10-31 00:31:25.000000000 -0800 @@ -38,6 +38,7 @@ */ #include +#include #include #include #include @@ -1218,11 +1219,22 @@ } #endif +void +secpath_destroy_noop (struct sec_path *sp) +{ + return; +} +EXPORT_SYMBOL(secpath_destroy_noop); + +void (*secpath_destroy_hook)(struct sec_path *sp) = secpath_destroy_noop; +EXPORT_SYMBOL(secpath_destroy_hook); + void __init skb_init(void) { int i; --- linux-2.5.45/net/ipv4/af_inet.c 2002-10-30 16:41:56.000000000 -0800 +++ linux/net/ipv4/af_inet.c 2002-11-01 03:31:37.000000000 -0800 @@ -105,16 +105,17 @@ #include #include #include #include #include #include #include #include +#include #ifdef CONFIG_IP_MROUTE #include #endif struct linux_mib net_statistics[NR_CPUS * 2]; #ifdef INET_REFCNT_DEBUG atomic_t inet_sock_nr; @@ -1054,16 +1055,18 @@ static int __init inet_init(void) { struct sk_buff *dummy_skb; struct inet_protosw *q; struct list_head *r; printk(KERN_INFO "NET4: Linux TCP/IP 1.0 for NET4.0\n"); + secpath_destroy_hook = __secpath_destroy; + if (sizeof(struct inet_skb_parm) > sizeof(dummy_skb->cb)) { printk(KERN_CRIT "inet_proto_init: panic\n"); return -EINVAL; } tcp_sk_cachep = kmem_cache_create("tcp_sock", sizeof(struct tcp_sock), 0, SLAB_HWCACHE_ALIGN, 0, 0); --n8g4imXOkfNTN/H1-- From davem@redhat.com Fri Nov 1 02:47:27 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Nov 2002 02:48:27 -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 gA1AlEuR029699 for ; Fri, 1 Nov 2002 02:47:27 -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 CAA21592; Fri, 1 Nov 2002 02:37:19 -0800 Date: Fri, 01 Nov 2002 02:37:18 -0800 (PST) Message-Id: <20021101.023718.64663422.davem@redhat.com> To: jagana@us.ibm.com Cc: yoshfuji@wide.ad.jp, kkumar@beaverton.ibm.com.sgi.com, kuznet@ms2.inr.ac.ru, ajtuomin@tml.hut.fi, lpetande@tml.hut.fi, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.45 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: 1061 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: "Venkata Jagana" Date: Thu, 31 Oct 2002 22:51:13 -0800 I believe even the registration part should belong to kernel and here are the reasons why. The Home Agent needs to ... None of the things you've listed make it desirable to put the home agent registration into the kernel. All of the operations you describe could be invoked by the userland home agent daemon using very minimal glue logic in the kernel (invoked, for example, via netlink messages). (Hint: this glue logic could even be useful for other things) Look, it is bad enough we have to put pfkey2 security database into the kernel (and that most IKE daemons duplicate the whole database in the user process as well), so let's not continue with such disasters. Just like a router changes and monitors routes, a home agent daemon would change and monitor mipv6 state. So for the same reason we don't put OSPF routing databases into the kernel, we do not put the home agent registration into the kernel :-) From blueflux@koffein.net Fri Nov 1 11:27:39 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Nov 2002 11:27:43 -0800 (PST) Received: from laptop1.agatha ([195.163.42.242]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA1JRMuR003559 for ; Fri, 1 Nov 2002 11:27:38 -0800 Received: from localhost (blueflux@localhost) by laptop1.agatha (8.11.6/8.11.6) with ESMTP id gA1JMm620538 for ; Fri, 1 Nov 2002 20:22:48 +0100 X-Authentication-Warning: laptop1.agatha: blueflux owned process doing -bs Date: Fri, 1 Nov 2002 20:22:47 +0100 (CET) From: Oskar Andreasson X-X-Sender: blueflux@laptop1.agatha To: netdev@oss.sgi.com Subject: [RFC] Badly documented sysctl? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1063 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: blueflux@koffein.net Precedence: bulk X-list: netdev Hi, I just started checking out the /proc/sys/net/ipv4/route/error_cost and error_burst sysctl's. According to linux/Documentation/filesystems/proc.txt: ---- error_burst and error_cost -------------------------- These parameters are used to limit the warning messages written to the kernel log from the routing code. The higher the error_cost factor is, the fewer messages will be written. Error_burst controls when messages will be dropped. The default settings limit warning messages to one every five seconds. ---- I just spent some time reading the source code in question, and if I am not totally off base... this is totally wrong? I am currently checking linux/net/ipv4/route.c, and if I am right, it limits how many ICMP_DEST_UNREACH we are sending to a specific host, and _possibly_ it will also printk() in the ip_rt_send_redirect() function. I don't know for sure, but I _think_ the default settings will limit ICMP_DEST_UNREACH sending in ip_error() to 5 per second... If anyone would shed some light on this, I would be tremenduously happy! ---- Oskar Andreasson http://www.frozentux.net mailto:blueflux@koffein.net From werner@almesberger.net Fri Nov 1 13:20:41 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Nov 2002 13:20:44 -0800 (PST) Received: from host.almesberger.net (almesberger.net [63.105.73.239] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA1LKfuR009565 for ; Fri, 1 Nov 2002 13:20:41 -0800 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.9.3/8.9.3) with ESMTP id NAA12612 for ; Fri, 1 Nov 2002 13:21:27 -0800 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id gA1LLNJ30636 for netdev@oss.sgi.com; Fri, 1 Nov 2002 18:21:23 -0300 Date: Fri, 1 Nov 2002 18:21:23 -0300 From: Werner Almesberger To: netdev@oss.sgi.com Subject: TCP connection passing, version 3 Message-ID: <20021101182123.A30594@almesberger.net> References: <20021031000249.A20233@almesberger.net> <20021031045909.A15756@almesberger.net> <20021031200017.A21544@almesberger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021031200017.A21544@almesberger.net>; from wa@almesberger.net on Thu, Oct 31, 2002 at 08:00:17PM -0300 X-archive-position: 1064 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 Almost a whole day since the last update ! High time for something new: http://www.almesberger.net/tcpcp/tcpcp-3.tar.gz The main change this time is that restarting the connection is no longer done by setting TCP_ICI, but by setting the new socket option TCP_KICK. This avoids the "need to reconfigure firewall within RTT or performance may suffer" race for applications. So this leaves mainly the difficult parts (OOO recovery and urgent data) to implement/fix. - Werner ----------------------------------- CHANGES ----------------------------------- Version 3 (1-NOV-2002) ---------------------- - moved activation of dormant connection from TCP_ICI/tcpcp_create to new socket option TCP_KICK and API function tcpcp_kick - tcpcp_getici now returns any errors pending in sk->err - API: added tcpcp_set_dst to set the destination address/port - added "install" and "uninstall" make targets - libtcpcp is now a shared library - dumpici: added option -V that prints version information - API: tcpcp_set_cong now sets errno - README.HANDOVER: documented single host case and added TCP_KICK - described not preserving error queue as feature, not bug - minor cleanup here and there -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From jagana@us.ibm.com Fri Nov 1 16:31:42 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Nov 2002 16:31:44 -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 gA20VfuR017566 for ; Fri, 1 Nov 2002 16:31:41 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gA20WNYb108048; Fri, 1 Nov 2002 19:32:24 -0500 Received: from d03nm036.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA20WIXu131224; Fri, 1 Nov 2002 19:32:19 -0500 From: "Venkata Jagana" Importance: Normal Sensitivity: Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.45 To: "David S. Miller" Cc: yoshfuji@wide.ad.jp, kkumar@beaverton.ibm.com.sgi.com, kuznet@ms2.inr.ac.ru, ajtuomin@tml.hut.fi, lpetande@tml.hut.fi, netdev@oss.sgi.com, linux-kernel@vger.kernel.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Fri, 1 Nov 2002 16:32:13 -0800 X-MIMETrack: Serialize by Router on D03NM036/03/M/IBM(Release 5.0.10 |March 22, 2002) at 11/01/2002 05:32:21 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-archive-position: 1065 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 Hello Dave, >Just like a router changes and monitors routes, a home agent daemon >would change and monitor mipv6 state. So for the same reason we don't >put OSPF routing databases into the kernel, we do not put the home >agent registration into the kernel :-) I absolutely understand your concerns about keeping the Home Agent registration in the kernel. However, I still believe that keeping this code in userspace would cause problems for handoffs. (btw, this code will never get executed on a regular host - only routers configured as Home Agents would be running this code as a module). Currently, when a Home Agent receives a registration request during the Mobile Node's handoff mechanism, it needs to respond in a reasonably quick time period so that the sessions on the MN can continue without experiencing delays. Longer delays could be harmful for applications such as VoIP, for which the latencies are quite critical. By moving this registration process to userspace, we have no control over when the home registration would complete, since there are no guarantees when the home agent daemon would run. BTW, according to ongoing discussions at Mobile IP WG, it is believed that even few hundred millisecs of latencies are not acceptable to critical apps, during which time the IP packet transfer is completely stopped. With such latency issues, I still believe that moving the registration to userspace would create issues for the MN. Thanks, Venkat ---------------------------------------------------------------- Venkata R Jagana IBM Linux Technology Centre, Beaverton jagana@us.ibm.com Tel: (503) 578 3430 T/L 775-3430 From kumarkr@us.ibm.com Fri Nov 1 17:17:45 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Nov 2002 17:17:48 -0800 (PST) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA21HiuR018267 for ; Fri, 1 Nov 2002 17:17:45 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gA21HuPi207584; Fri, 1 Nov 2002 20:17:56 -0500 Received: from d03nm801.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA21HpXu023066; Fri, 1 Nov 2002 20:17:52 -0500 Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.45 To: "David S. Miller" Cc: ajtuomin@tml.hut.fi, kkumar@beaverton.ibm.com.sgi.com, kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, lpetande@tml.hut.fi, netdev@oss.sgi.com, "Venkata Jagana" , yoshfuji@wide.ad.jp X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Krishna Kumar" Date: Fri, 1 Nov 2002 17:15:09 -0800 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 5.0.10 |March 22, 2002) at 11/01/2002 06:17:54 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-archive-position: 1066 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kumarkr@us.ibm.com Precedence: bulk X-list: netdev Hi Dave, > None of the things you've listed make it desirable to put the home > agent registration into the kernel. All of the operations you > describe could be invoked by the userland home agent daemon using very > minimal glue logic in the kernel (invoked, for example, via netlink > messages). I had a couple of comments about putting the registration part in userspace. When the HA gets a registration request, it needs to perform the following actions : 1. perform DAD 2. get the list of prefixes supported on the home link of the MN. 3. create a tunnel between the HA and the MN 4. join the solicited node multicast group of the MN's home address. 5. add the MN's home address to the list of proxy neigh cache entry for the HA. 6. Send NA on behalf of the MN 7. add the new location of the MN in the binding cache. 8. and finally send the Binding Registration Success/Failure message. In the above list, the only activities which can be done in userspace are #7 and #8 (that I am aware of). The rest of the items can only be done in the kernel, atleast we need to move the support to kernel. If the HA registration is completely moved to userspace, it would still need these facilities (#1 to #6) in the kernel to perform the actions for registration. So even with netlink we still need the infrastructure in the kernel. We can move the #7 and #8 pieces to userspace, but that is a relatively small code, and is it worth doing that ? Overall I feel that this should still be part of the kernel... Thanks, - KK From yoshfuji@linux-ipv6.org Fri Nov 1 19:00:00 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Nov 2002 19:00:02 -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 gA22xxuR019622 for ; Fri, 1 Nov 2002 18:59:59 -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 gA230JGR029614; Sat, 2 Nov 2002 12:00:20 +0900 Date: Sat, 02 Nov 2002 12:00:19 +0900 (JST) Message-Id: <20021102.120019.45396269.yoshfuji@linux-ipv6.org> To: kumarkr@us.ibm.com Cc: davem@redhat.com, ajtuomin@tml.hut.fi, kkumar@beaverton.ibm.com.sgi.com, kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, lpetande@tml.hut.fi, netdev@oss.sgi.com, jagana@us.ibm.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.45 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: 1067 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 (at Fri, 1 Nov 2002 17:15:09 -0800), "Krishna Kumar" says: > When the HA gets a registration request, it needs to perform the following > actions : > 1. perform DAD > 2. get the list of prefixes supported on the home link of the MN. > 3. create a tunnel between the HA and the MN > 4. join the solicited node multicast group of the MN's home > address. > 5. add the MN's home address to the list of proxy neigh cache entry > for the HA. > 6. Send NA on behalf of the MN > 7. add the new location of the MN in the binding cache. > 8. and finally send the Binding Registration Success/Failure > message. > > In the above list, the only activities which can be done in userspace are > #7 and #8 (that I am aware of). The rest of the items can only be done in > the > kernel, atleast we need to move the support to kernel. If the HA > registration > is completely moved to userspace, it would still need these facilities (#1 > to #6) in the kernel to perform the actions for registration. So even with > netlink > we still need the infrastructure in the kernel. 1: True: we need some interface (and small code) 2: FALSE: you CAN listen icmp6 message via raw socket. 3: FALSE: you CAN create tunnel using raw socket; however, we think this is implemented in kernel. 4,5,6: True: we need some interface to generate proxy ND. (proxy ND is already in kernel.) For 1,4,5,6: "proxy address" on a device would be a solution. --yoshfuji From jgarzik@pobox.com Sat Nov 2 00:23:56 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Nov 2002 00:23:58 -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 gA28NtuR022976 for ; Sat, 2 Nov 2002 00:23:55 -0800 Received: from [66.57.10.0] (helo=pobox.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 187taC-0007BD-00; Sat, 02 Nov 2002 08:24:40 +0000 Message-ID: <3DC38B99.6080703@pobox.com> Date: Sat, 02 Nov 2002 03:23:53 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Krishna Kumar CC: "David S. Miller" , ajtuomin@tml.hut.fi, kkumar@beaverton.ibm.com.sgi.com, kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, lpetande@tml.hut.fi, netdev@oss.sgi.com, Venkata Jagana , yoshfuji@wide.ad.jp Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.45 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1068 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 Krishna Kumar wrote: >Hi Dave, > > > >>None of the things you've listed make it desirable to put the home >>agent registration into the kernel. All of the operations you >>describe could be invoked by the userland home agent daemon using very >>minimal glue logic in the kernel (invoked, for example, via netlink >>messages). >> >> > >I had a couple of comments about putting the registration part in >userspace. >When the HA gets a registration request, it needs to perform the following >actions : > 1. perform DAD > 2. get the list of prefixes supported on the home link of the MN. > 3. create a tunnel between the HA and the MN > 4. join the solicited node multicast group of the MN's home >address. > 5. add the MN's home address to the list of proxy neigh cache entry >for the HA. > 6. Send NA on behalf of the MN > 7. add the new location of the MN in the binding cache. > 8. and finally send the Binding Registration Success/Failure >message. > >In the above list, the only activities which can be done in userspace are >#7 and #8 (that I am aware of). The rest of the items can only be done in >the >kernel, atleast we need to move the support to kernel. If the HA >registration >is completely moved to userspace, it would still need these facilities (#1 >to #6) in the kernel to perform the actions for registration. So even with >netlink >we still need the infrastructure in the kernel. > > Heck no -- the list you sent only further enforces the notion that most of this can be in userspace. Sure, some of the facilities you list are completely in the kernel -- but it is best IMO to control them from userspace. That allows for flexibility when it comes to policy decisions being made (if any) as well as increased cleanliness of kernel code. Jeff From pekkas@netcore.fi Sat Nov 2 00:35:59 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Nov 2002 00:36:00 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA28ZvuR023532 for ; Sat, 2 Nov 2002 00:35:58 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gA28a9d10237; Sat, 2 Nov 2002 10:36:10 +0200 Date: Sat, 2 Nov 2002 10:36:09 +0200 (EET) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: kumarkr@us.ibm.com, , , , , , , , Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.45 In-Reply-To: <20021102.120019.45396269.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 1069 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev I believe there could be more hooks in the kernel to let userspace do certain tasks, for example, sending router solicitations and processing the responses -- sure, this can be done in the userspace but means code duplication. If the code in the kernel could also be called from the userspace, there might be less need for duplication (though this would result in portability issues of course). Similar would appear to be the case some other features listed here. On Sat, 2 Nov 2002, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > In article (at Fri, 1 Nov 2002 17:15:09 -0800), "Krishna Kumar" says: > > > When the HA gets a registration request, it needs to perform the following > > actions : > > 1. perform DAD > > 2. get the list of prefixes supported on the home link of the MN. > > 3. create a tunnel between the HA and the MN > > 4. join the solicited node multicast group of the MN's home > > address. > > 5. add the MN's home address to the list of proxy neigh cache entry > > for the HA. > > 6. Send NA on behalf of the MN > > 7. add the new location of the MN in the binding cache. > > 8. and finally send the Binding Registration Success/Failure > > message. > > > > In the above list, the only activities which can be done in userspace are > > #7 and #8 (that I am aware of). The rest of the items can only be done in > > the > > kernel, atleast we need to move the support to kernel. If the HA > > registration > > is completely moved to userspace, it would still need these facilities (#1 > > to #6) in the kernel to perform the actions for registration. So even with > > netlink > > we still need the infrastructure in the kernel. > > 1: True: we need some interface (and small code) > 2: FALSE: you CAN listen icmp6 message via raw socket. > 3: FALSE: you CAN create tunnel using raw socket; > however, we think this is implemented in kernel. > 4,5,6: True: we need some interface to generate proxy ND. > (proxy ND is already in kernel.) > > For 1,4,5,6: "proxy address" on a device would be a solution. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From davem@redhat.com Sat Nov 2 02:33:45 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Nov 2002 02:33: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 gA2AXiuR025714 for ; Sat, 2 Nov 2002 02:33:45 -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 CAA04961; Sat, 2 Nov 2002 02:24:37 -0800 Date: Sat, 02 Nov 2002 02:24:36 -0800 (PST) Message-Id: <20021102.022436.119507521.davem@redhat.com> To: willy@debian.org Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] update packet & wanpipe ioctl routines From: "David S. Miller" In-Reply-To: <20021031190205.M27461@parcelfarce.linux.theplanet.co.uk> References: <20021031190205.M27461@parcelfarce.linux.theplanet.co.uk> 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: 1070 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 epapu@bb.excite.co.jp Sat Nov 2 07:16:35 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Nov 2002 07:16:41 -0800 (PST) Received: from test01.gvn.ad.jp ([202.220.128.131]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA2FGYuR030592 for ; Sat, 2 Nov 2002 07:16:35 -0800 Message-Id: <200211021516.gA2FGYuR030592@oss.sgi.com> Received: (qmail 29711 invoked from network); 2 Nov 2002 20:00:55 +0900 Received: from unknown (HELO ssss) (219.111.0.41) by localhost.localdomain with SMTP; 2 Nov 2002 20:00:55 +0900 From: =?iso-2022-jp?B?ZXBhcHVAYmIuZXhjaXRlLmNvLmpw?=@oss.sgi.com To: =?iso-2022-jp?B?Nzc3?=@oss.sgi.com Reply-To: epapu@bb.excite.co.jp Date: Sat, 02 Nov 2002 19:59:00 +0900 Subject: =?iso-2022-jp?B?GyRCTCQ+NUJ6OS05cCIoRUU7UiVhITwlazktOXAbKEo=?= Content-Type: text/plain Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-archive-position: 1071 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: =?iso-2022-jp?B?ZXBhcHVAYmIuZXhjaXRlLmNvLmpw?=@oss.sgi.com Precedence: bulk X-list: netdev <‘—MŽÒ> “dŽqƒ[ƒ‹LŽÐ ¡ŒãAL‚ð‚²Šó–]‚µ‚È‚¢•û‚Í‚±‚±‚Ö (•K‚¸–{•¶‚É‚ ‚È‚½‚̃[ƒ‹ƒAƒhƒŒƒX‚Ì‚Ý‚ð‚¨‘‚«‰º‚³‚¢j me464783@members.interq.or.jp ƒ[ƒ‹ƒAƒhƒŒƒX‚ð‚²‹L“ü‚µ‚Ä‚­‚¾‚³‚¢B §104-0061 “Œ‹ž“s’†‰›‹æ‹âÀ8-19-3 ‘æ2ƒEƒCƒ“ƒOƒrƒ‹@3F ƒ[ƒ‹ƒ}ƒKƒWƒ“”­s TEL@03-3544-6222 FAX@03-3544-6218 =============================================================== –â‘褕i‚΂©‚èW‚ß‚Ü‚µ‚½‚Ì‚ÅAÁ‚³‚ê‚é‹°‚ꂪ‚ ‚è‚Ü‚·‚Ì‚Å ‚¨\ž‚Ý‚Í‚¨‘‚ß‚ÉI =============================================================== ¡@‰ïˆõ§ƒƒŠ[ƒ^ƒNƒ‰ƒu@¡ ‚c‚u‚cEƒrƒfƒI2500‰~‚©‚ç ƒnƒCƒNƒIƒŠƒeƒB‰æŽ¿‚ł̔̔„ƒ}ƒjƒAƒbƒN‚ȉf‘œ‚Ì”X ‚Ü‚¸‚̓Jƒ^ƒƒO¿‹‚¨‘Ò‚¿‚µ‚Ä‚¨‚è‚Ü‚·i‹Ç—¯‚ß‚Å‚Ì¿‹‰Â”\j ‚¨ŽèŒ³‚É‚¨“Í‚­••“›‚É‚ÍA‚¨‹q—l‚Ì‚¨–¼‘O‚Ì‚ÝI“–ŽÐ–¼‚͈êØ“ü‚è‚Ü‚¹‚ñB ƒJƒ^ƒƒO‚ð‚¨Œ©‚ÄA‚¨\‚µž‚Ý‚­‚¾‚³‚¢B –³—¿ƒJƒ^ƒƒO http://www.allround.sib.ru/roriclub/ http://magazine.japanesebabies.com/roriclub/ @@@@@@@@@@@@@@@@@@@@@‰ïˆõ§ƒƒŠ[ƒ^ƒNƒ‰ƒu QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ ¡SEXƒtƒŒƒ“ƒh•åW¡ ^Œ•‚ÉSEXƒtƒŒƒ“ƒh‚ð’T‚µ‚Ä‚¢‚él‚¾‚¯W‡I ‘S‘‚Ç‚±‚Å‚à‹ß‚­‚Ìl‚ðƒvƒƒtƒB[ƒ‹•t‚Å‚·‚®Ð‰îB Žá‚¢l‚©‚çn”N‚Ü‚Å‚¢‚Á‚Ï‚¢‚¢‚é‚æ! ƒ_ƒ“ƒi‚É“à‚ÌH‚ðŠy‚µ‚à‚¤I http://www.allround.sib.ru/sex/ http://magazine.japanesebabies.com/sex/ ƒŒƒ‚ƒ“ƒNƒ‰ƒu QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ ¡‚à‚à‚ª‚Í‚¶‚¯‚Ä‚Ô‚Ç‚¤‚ª‚ä‚ê‚é¡ ‚µ‚¶‚Ý‚Æ‚à‚à‚̃Rƒ‰ƒ{ƒŒ[ƒVƒ‡ƒ“ ƒƒŠ[ƒ^ƒrƒfƒIi‚c‚u‚cjê–å ‚¢‚‚܂ʼnc‹Æ‚Å‚«‚é‚©‚í‚©‚è‚Ü‚¹‚ñ ‚²’•¶‚Í‚¨‘‚ß‚ÉI http://www.allround.sib.ru/roridvd/rori/ http://magazine.japanesebabies.com/roridvd/rori/ ì•i—á ­—“`à@–¼ŒÃ‰®’c’n9@­—‚Ì“¹‘ ‚È‚Ç‚È‚Ç132ì•iBD•]”­”„’†I @(^-^)/~ƒƒŠ˜F—˜ƒ€ƒg[ QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ ¡@‚r‚lƒp[ƒgƒi[Љ“ú@¡ ‚r‚lƒp[ƒgƒi[‘¦“úЉîB ‰‡•‚âSMƒNƒ‰ƒu‚Ƃ͈ႢA‚r‚lˆ¤DŽÒ‚¾‚¯‚ªW‚¤‰ïB ‘S‘‚Å‚²Ð‰î‚Å‚«‚Ü‚·B ‚ ‚È‚½‚̃vƒŒƒC‚É‚ ‚킹‚Ä‘¦“úЉîB ƒvƒŒƒC‘ã‹à‚͈êØ‚©‚©‚è‚Ü‚¹‚ñB ”N—î‚Í20ΈÈãB http://www.allround.sib.ru/sm/ http://magazine.japanesebabies.com/sm/ @@@@@@@@@@@@@@@@@@@@@@@@@‚r‚lƒNƒ‰ƒu \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@lŒ`Žt‚ªì‚Á‚½Œ†ì•i@¡ •ø‚«‚µ‚ß‚½‚­‚È‚é‚悤‚È‚¨lŒ`‚³‚ñ‚ªì‚ê‚Ü‚µ‚½B ”š”­“I‘åƒqƒbƒg¤•iI ”‚ɧŒÀ‚ª‚ ‚邽‚ßA‚¨\‚µž‚Ý‚Í‚¨‘‚ß‚ÉI ™‹Ç•”‚Ü‚Å–{•¨‚»‚Á‚­‚è‚ɧ삵‚½‚½‚ßA“X“ª”Ì”„‚Å‚«‚Ü‚¹‚ñB http://www.allround.sib.ru/dachi/dollc/ http://magazine.japanesebabies.com/dachi/dollc/ @@@@@@@@@@@@@@@@@@@@@lŒ`Žt‹{ìƒfƒUƒCƒ“ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@‹t‰‡•ŒðÛ‚­‚ç‚Ô@¡ ‘f“G‚È’j«‚Æ’©‚Ü‚Å“ñlEEEB ‘f“G‚È’j«‚ð¡‚·‚®‹M—‚ÌŒ³‚ÖŒü‚©‚킹‚Ü‚·B ‘S‘ƒlƒbƒgƒ[ƒN‚Å‚·‚®‚ÉЉî‚n‚jB Žá‚¢—«‚à‰“—¶‚µ‚È‚¢‚Å—V‚Ñ‚Ü‚­‚낤I ‚P‰ñŒÀ‚èA’·ŠúA‰½‚Å‚à‚ ‚èB ô—«‚É—D‚µ‚­‚Å‚«‚é’j«ƒXƒ^ƒbƒt‚à“¯Žž•åW’†ô http://www.allround.sib.ru/enjyo/ http://magazine.japanesebabies.com/enjyo/ @@@@@@@@@@@@@@@@@@@@@@@@@‹t‰‡•‰ï \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@ƒ}ƒŠƒtƒ@ƒi‚ÌŽí@¡ ƒ}ƒŠƒtƒ@ƒi‚ª‚½‚Ü‚ç‚È‚­D‚«‚ÈlA‚Ç‚¤‚¼A‚±‚±‚ÖB ‚ ‚Ô‚È‚¢‚­‚·‚è‚Ìî•ñ‚àŽè‚É“ü‚é‚æI uâ‘΂Ɉ«—p‚µ‚È‚¢‚Å‚­‚¾‚³‚¢Bv http://www.allround.sib.ru/mari/ http://magazine.japanesebabies.com/mari/ @@@@@@@@@@@@@@@@@@@@@@@@@X@³’j \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@V‘•ŠJ“XIŒƒˆÀƒZ[ƒ‹@¡ AV.DVDŒƒˆÀƒZ[ƒ‹ ‘¼“X‚Å‚ÍŽè‚É“ü‚ç‚È‚¢‚à‚̂΂©‚µ¥¥¥¥¥¥ ˆÈ‘O‚̂悤‚ÉA‚æ‚낵‚­‚¨Šè‚¢‚µ‚Ü‚·B ‘¼“X‚É•‰‚¯‚¸ŒƒˆÀ—¿‹àI http://www.allround.sib.ru/pink/ http://magazine.japanesebabies.com/pink/ @@@ @@@@@@@@@@@@@@@@@@@@@@@@@”ü­—ƒNƒ‰ƒu \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ From kumarkr@us.ibm.com Sat Nov 2 14:01:58 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Nov 2002 14:02:01 -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 gA2M1wuR003567 for ; Sat, 2 Nov 2002 14:01:58 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gA2M2aQ5039180; Sat, 2 Nov 2002 17:02:36 -0500 Received: from d03nm801.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA2M4efg109726; Sat, 2 Nov 2002 15:04:44 -0700 Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.45 To: Pekka Savola Cc: ajtuomin@tml.hut.fi, davem@redhat.com, kkumar@beaverton.ibm.com.sgi.com, kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, lpetande@tml.hut.fi, netdev@oss.sgi.com, "Venkata Jagana" , YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Krishna Kumar" Date: Sat, 2 Nov 2002 13:13:22 -0800 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 5.0.10 |March 22, 2002) at 11/02/2002 03:02:35 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-2022-jp X-archive-position: 1072 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kumarkr@us.ibm.com Precedence: bulk X-list: netdev I agree with Pekka, hence the response to Jeff's and Yoshifuji's mail is the same - what you are suggestting is feasible but we need more work in the kernel either way. We can do many/most of these things in userspace provided we either duplicate a lot of the code from kernel to user space (leading to maintainability issues), or modularize exisiting kernel routines (eg a different interface to DAD) and provide hooks for the same to user (portability?). To clean up and provide more hooks in the kernel to support common user activities means a major over write, but I agree it is a good idea in the long run. Another concern to think about is whether an integral part of the HA functionality should be kept separate in user space, and whether making the break in the HA to have a user process and kernel component makes sense. Also other things to worry about when integral components are kept in userspace - what happens when signals (KILL) are sent to that process ? We don't want the home agent functionality to stop in that case, even if it is a system admin error. This part is very critical to supporting possibly hundreds of mobile devices in the future. Thanks, - KK Pekka Savola i> cc: Krishna Kumar/Beaverton/IBM@IBMUS, , , , 11/02/2002 12:36 , , AM , , Venkata Jagana/Beaverton/IBM@IBMUS Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.45 I believe there could be more hooks in the kernel to let userspace do certain tasks, for example, sending router solicitations and processing the responses -- sure, this can be done in the userspace but means code duplication. If the code in the kernel could also be called from the userspace, there might be less need for duplication (though this would result in portability issues of course). Similar would appear to be the case some other features listed here. On Sat, 2 Nov 2002, YOSHIFUJI Hideaki / [iso-2022-jp] ! !  From werner@almesberger.net Sat Nov 2 18:22:27 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Nov 2002 18:22:33 -0800 (PST) Received: from host.almesberger.net (almesberger.net [63.105.73.239] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA32MRuR011291 for ; Sat, 2 Nov 2002 18:22:27 -0800 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.9.3/8.9.3) with ESMTP id SAA17248; Sat, 2 Nov 2002 18:23:16 -0800 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id gA32N8R04534; Sat, 2 Nov 2002 23:23:08 -0300 Date: Sat, 2 Nov 2002 23:23:08 -0300 From: Werner Almesberger To: Krishna Kumar Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.45 Message-ID: <20021102232308.A4482@almesberger.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from kumarkr@us.ibm.com on Sat, Nov 02, 2002 at 01:13:22PM -0800 X-archive-position: 1073 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 [ Cc: trimmed ] Krishna Kumar wrote: > userspace - what happens when signals (KILL) are sent to that process ? They die, as they should. > We don't want the home agent functionality to stop in that case, even > if it is a system admin error. So what makes the home agent so much more important than, say, named, pppd, gated, portmap, inetd, sendmail, sshd, etc. ? A much more common admin mistake would be to reboot the wrong box, or to disconnect the wrong cable, and you're powerless against this too. If all else fails, add this to ~root/.bashrc: alias kill='echo "Sorry, you'\''re too dumb for this"; false' :-) - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From yoshfuji@linux-ipv6.org Sat Nov 2 18:54:22 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Nov 2002 18:54:28 -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 gA32sKuR011785 for ; Sat, 2 Nov 2002 18:54:21 -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 gA32sVGR003282; Sun, 3 Nov 2002 11:54:31 +0900 Date: Sun, 03 Nov 2002 11:54:27 +0900 (JST) Message-Id: <20021103.115427.104445233.yoshfuji@linux-ipv6.org> To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org CC: davem@redhat.com, kuznet@ms2.inr.ac.ru, usagi@linux-ipv6.org Subject: [PATCH] IPv6: Functions Clean-up 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: 1074 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 cleans up functions in ipv6 stack: - export route6_me_harder() as ip6_route_harder() and use it from net/ipv6/netfilter/ip6_queue.c. - make ip6_addr_prefix() to generate prefix of given address and prefix length, instead of doing "ipv6_copy_addr() then ipv6_wash_prefix()." Patch is against 2.5.45. Thanks in advance. ------------------------------------------------------------------- Patch-Name: Functions Clean-up Patch-Id: FIX_2_5_45_FUNC_CLEANUP-20021102 Patch-Author: YOSHIFUJI Hideaki / USAGI Project Credit: YOSHIFUJI Hideaki / USAGI Project ------------------------------------------------------------------- Index: include/net/ip6_route.h =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux25/include/net/ip6_route.h,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.16.1 diff -u -r1.1.1.1 -r1.1.1.1.16.1 --- include/net/ip6_route.h 7 Oct 2002 10:22:46 -0000 1.1.1.1 +++ include/net/ip6_route.h 2 Nov 2002 14:50:30 -0000 1.1.1.1.16.1 @@ -30,6 +30,8 @@ extern struct dst_entry * ip6_route_output(struct sock *sk, struct flowi *fl); +extern int ip6_route_harder(struct sk_buff *skb); + extern void ip6_route_init(void); extern void ip6_route_cleanup(void); Index: net/ipv6/ip6_output.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux25/net/ipv6/ip6_output.c,v retrieving revision 1.1.1.3 retrieving revision 1.1.1.3.6.1 diff -u -r1.1.1.3 -r1.1.1.3.6.1 --- net/ipv6/ip6_output.c 30 Oct 2002 09:43:18 -0000 1.1.1.3 +++ net/ipv6/ip6_output.c 2 Nov 2002 14:50:30 -0000 1.1.1.3.6.1 @@ -134,7 +134,7 @@ #ifdef CONFIG_NETFILTER -static int route6_me_harder(struct sk_buff *skb) +int ip6_route_harder(struct sk_buff *skb) { struct ipv6hdr *iph = skb->nh.ipv6h; struct dst_entry *dst; @@ -152,7 +152,7 @@ if (dst->error) { if (net_ratelimit()) - printk(KERN_DEBUG "route6_me_harder: No more route.\n"); + printk(KERN_DEBUG "ip6_route_harder: No more route.\n"); return -EINVAL; } @@ -168,7 +168,7 @@ { #ifdef CONFIG_NETFILTER if (skb->nfcache & NFC_ALTERED){ - if (route6_me_harder(skb) != 0){ + if (ip6_route_harder(skb) != 0){ kfree_skb(skb); return -EINVAL; } Index: net/ipv6/ipv6_syms.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux25/net/ipv6/ipv6_syms.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.16.1 diff -u -r1.1.1.1 -r1.1.1.1.16.1 --- net/ipv6/ipv6_syms.c 7 Oct 2002 10:20:36 -0000 1.1.1.1 +++ net/ipv6/ipv6_syms.c 2 Nov 2002 14:50:30 -0000 1.1.1.1.16.1 @@ -1,4 +1,5 @@ +#include #include #include #include @@ -11,6 +12,9 @@ EXPORT_SYMBOL(register_inet6addr_notifier); EXPORT_SYMBOL(unregister_inet6addr_notifier); EXPORT_SYMBOL(ip6_route_output); +#ifdef CONFIG_NETFILTER +EXPORT_SYMBOL(ip6_route_harder); +#endif EXPORT_SYMBOL(addrconf_lock); EXPORT_SYMBOL(ipv6_setsockopt); EXPORT_SYMBOL(ipv6_getsockopt); Index: net/ipv6/route.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux25/net/ipv6/route.c,v retrieving revision 1.1.1.4 retrieving revision 1.1.1.4.6.1 diff -u -r1.1.1.4 -r1.1.1.4.6.1 --- net/ipv6/route.c 30 Oct 2002 09:43:18 -0000 1.1.1.4 +++ net/ipv6/route.c 2 Nov 2002 14:52:05 -0000 1.1.1.4.6.1 @@ -573,15 +573,17 @@ Remove it only when all the things will work! */ -static void ipv6_wash_prefix(struct in6_addr *pfx, int plen) +static void ipv6_addr_prefix(struct in6_addr *pfx, + const struct in6_addr *addr, int plen) { int b = plen&0x7; - int o = (plen + 7)>>3; + int o = plen>>3; + memcpy(prefix, addr, o); if (o < 16) memset(pfx->s6_addr + o, 0, 16 - o); if (b != 0) - pfx->s6_addr[plen>>3] &= (0xFF<<(8-b)); + pfx->s6_addr[o] = addr->s6_addr[o]&(0xff00 >> b); } static int ipv6_get_mtu(struct net_device *dev) @@ -654,16 +656,16 @@ goto out; } - ipv6_addr_copy(&rt->rt6i_dst.addr, &rtmsg->rtmsg_dst); + ipv6_addr_prefix(&rt->rt6i_dst.addr, + &rtmsg->rtmsg_dst, rtmsg->rtmsg_dst_len); rt->rt6i_dst.plen = rtmsg->rtmsg_dst_len; if (rt->rt6i_dst.plen == 128) rt->u.dst.flags = DST_HOST; - ipv6_wash_prefix(&rt->rt6i_dst.addr, rt->rt6i_dst.plen); #ifdef CONFIG_IPV6_SUBTREES - ipv6_addr_copy(&rt->rt6i_src.addr, &rtmsg->rtmsg_src); + ipv6_addr_prefix(&rt->rt6i_src.addr, + &rtmsg->rtmsg_src, rtmsg->rtmsg_src_len); rt->rt6i_src.plen = rtmsg->rtmsg_src_len; - ipv6_wash_prefix(&rt->rt6i_src.addr, rt->rt6i_src.plen); #endif rt->rt6i_metric = rtmsg->rtmsg_metric; Index: net/ipv6/netfilter/ip6_queue.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux25/net/ipv6/netfilter/ip6_queue.c,v retrieving revision 1.1.1.2 retrieving revision 1.1.1.2.14.1 diff -u -r1.1.1.2 -r1.1.1.2.14.1 --- net/ipv6/netfilter/ip6_queue.c 8 Oct 2002 03:15:20 -0000 1.1.1.2 +++ net/ipv6/netfilter/ip6_queue.c 2 Nov 2002 14:50:30 -0000 1.1.1.2.14.1 @@ -326,45 +326,6 @@ return status; } -/* - * Taken from net/ipv6/ip6_output.c - * - * We should use the one there, but is defined static - * so we put this just here and let the things as - * they are now. - * - * If that one is modified, this one should be modified too. - */ -static int -route6_me_harder(struct sk_buff *skb) -{ - struct ipv6hdr *iph = skb->nh.ipv6h; - struct dst_entry *dst; - struct flowi fl; - - fl.proto = iph->nexthdr; - fl.fl6_dst = &iph->daddr; - fl.fl6_src = &iph->saddr; - fl.oif = skb->sk ? skb->sk->bound_dev_if : 0; - fl.fl6_flowlabel = 0; - fl.uli_u.ports.dport = 0; - fl.uli_u.ports.sport = 0; - - dst = ip6_route_output(skb->sk, &fl); - - if (dst->error) { - if (net_ratelimit()) - printk(KERN_DEBUG "route6_me_harder: No more route.\n"); - return -EINVAL; - } - - /* Drop old route. */ - dst_release(skb->dst); - - skb->dst = dst; - return 0; -} - static int ipq_mangle_ipv6(ipq_verdict_msg_t *v, struct ipq_queue_entry *e) { @@ -410,7 +371,7 @@ struct ipv6hdr *iph = e->skb->nh.ipv6h; if (ipv6_addr_cmp(&iph->daddr, &e->rt_info.daddr) || ipv6_addr_cmp(&iph->saddr, &e->rt_info.saddr)) - return route6_me_harder(e->skb); + return ip6_route_harder(e->skb); } return 0; } From adam@yggdrasil.com Sun Nov 3 00:23:23 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Nov 2002 00:23:26 -0800 (PST) Received: from freya.yggdrasil.com (h-64-105-136-52.SNVACAID.covad.net [64.105.136.52]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA38NNuR015517 for ; Sun, 3 Nov 2002 00:23:23 -0800 Received: from baldur.yggdrasil.com (baldur.yggdrasil.com [209.249.10.12]) by freya.yggdrasil.com (8.9.3/8.9.3) with ESMTP id AAA22642; Sun, 3 Nov 2002 00:24:15 -0800 Received: (from adam@localhost) by baldur.yggdrasil.com (8.9.3/8.9.3) id AAA00948; Sun, 3 Nov 2002 00:24:10 -0800 Date: Sun, 3 Nov 2002 00:24:10 -0800 From: "Adam J. Richter" To: davem@redhat.com, netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Patch: linux-2.5.45/net/core/dev.c netdev_finish_unregister could read freed memory Message-ID: <20021103002410.A513@baldur.yggdrasil.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline User-Agent: Mutt/1.2i X-archive-position: 1075 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: adam@yggdrasil.com Precedence: bulk X-list: netdev --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I just changed a network driver to use net_device.destructor because it now embeds a struct net_device in a larger private data structure (to reduce rarely tested memory allocation error branches). Looking at netdev_finish_unregister, I see that after dev->destructor() has been called, netdev_finish_unregister still atttempts to read dev->features to check for NETIF_F_DYNALLOC. The following patch causes the NETIF_F_DYNALLOC test not to be done if dev->destructor is provided. Alternatively, I'd be willing to make a patch to eliminate NETIF_F_DYNALLOC (replacing it with "dev->destructor = (cast...) kfree;"), as I think reference counting is done regardless of the value of that flag. I don't know why it is checked in net/core/dst.c though. Also, please do not eliminate netdev.destructor. I have a legitimate use for it that I can explain more if necessary. Thanks. -- Adam J. Richter __ ______________ 575 Oroville Road adam@yggdrasil.com \ / Milpitas, California 95035 +1 408 309-6081 | g g d r a s i l United States of America "Free Software For The Rest Of Us." --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dynalloc.diff" --- linux-2.5.45/net/core/dev.c 2002-10-30 16:42:56.000000000 -0800 +++ linux/net/core/dev.c 2002-11-03 00:01:07.000000000 -0800 @@ -2511,7 +2511,7 @@ #endif if (dev->destructor) dev->destructor(dev); - if (dev->features & NETIF_F_DYNALLOC) + else if (dev->features & NETIF_F_DYNALLOC) kfree(dev); return 0; } --bp/iNruPH9dso1Pn-- From kisza@securityaudit.hu Sun Nov 3 03:59:36 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Nov 2002 03:59:43 -0800 (PST) Received: from addu.axelero.hu (mail02.axelero.hu [195.228.240.77]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA3BxZuR018338 for ; Sun, 3 Nov 2002 03:59:36 -0800 Received: from localhost.localdomain (adsl-151-82.adsl-pool.axelero.hu [62.201.82.151]) by mail02.axelero.hu (iPlanet Messaging Server 5.1 HotFix 0.6 (built Apr 26 2002)) with ESMTP id <0H5000E6E1CSOR@mail02.axelero.hu> for netdev@oss.sgi.com; Sun, 03 Nov 2002 13:00:28 +0100 (MET) Date: Sun, 03 Nov 2002 14:00:14 +0100 From: Andras Kis-Szabo Subject: Re: [PATCH] IPv6: Functions Clean-up In-reply-to: <20021103.115427.104445233.yoshfuji@linux-ipv6.org> To: YOSHIFUJI Hideaki / =?UTF-8?Q?=E5=90=89=E8=97=A4=E8=8B=B1?= =?UTF-8?Q?=E6=98=8E?= Cc: linux-kernel@vger.kernel.org, Netdev , Netfilter Devel , "David S. Miller" , kuznet@ms2.inr.ac.ru, usagi@linux-ipv6.org Message-id: <1036328414.1048.3.camel@arwen> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.0.8 Content-type: text/plain Content-transfer-encoding: 7BIT References: <20021103.115427.104445233.yoshfuji@linux-ipv6.org> X-archive-position: 1076 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kisza@securityaudit.hu Precedence: bulk X-list: netdev Hello, > - export route6_me_harder() as ip6_route_harder() and > use it from net/ipv6/netfilter/ip6_queue.c. Opsz! At the extension parser code we got that decision that we should use our own parser in the Netfilter code! (And we should not to trust in the kernel.) This patch removes one function from the Netfilter code and forces the Netfilter to use a similar function from the kernel's one! Regards, kisza -- Andras Kis-Szabo Security Development, Design and Audit -------------------------/ Zorp, NetFilter and IPv6 kisza@SecurityAudit.hu /-------------------------------------------> From pekkas@netcore.fi Sun Nov 3 04:08:15 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Nov 2002 04:08:18 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA3C8EuR019169 for ; Sun, 3 Nov 2002 04:08:14 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gA3C8nK27838; Sun, 3 Nov 2002 14:08:49 +0200 Date: Sun, 3 Nov 2002 14:08:49 +0200 (EET) From: Pekka Savola To: Andras Kis-Szabo cc: YOSHIFUJI Hideaki / =?UTF-8?Q?=E5=90=89=E8=97=A4=E8=8B=B1?= =?UTF-8?Q?=E6=98=8E?= , , Netdev , Netfilter Devel , "David S. Miller" , , Subject: Re: [PATCH] IPv6: Functions Clean-up In-Reply-To: <1036328414.1048.3.camel@arwen> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1077 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev On Sun, 3 Nov 2002, Andras Kis-Szabo wrote: > > - export route6_me_harder() as ip6_route_harder() and > > use it from net/ipv6/netfilter/ip6_queue.c. > Opsz! > At the extension parser code we got that decision that we should use > our own parser in the Netfilter code! (And we should not to trust in the > kernel.) > This patch removes one function from the Netfilter code and forces the > Netfilter to use a similar function from the kernel's one! And why is that a problem? If there is a problem in main kernel code, it should fixed. If the netfilter version is better, the main kernel code should be changed. Are there specific reasons to keep them separate? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From davem@redhat.com Sun Nov 3 04:12:57 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Nov 2002 04:13:01 -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 gA3CCvuR019555 for ; Sun, 3 Nov 2002 04:12:57 -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 EAA20358; Sun, 3 Nov 2002 04:03:38 -0800 Date: Sun, 03 Nov 2002 04:03:38 -0800 (PST) Message-Id: <20021103.040338.98864962.davem@redhat.com> To: kisza@securityaudit.hu Cc: yoshfuji@linux-ipv6.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, kuznet@ms2.inr.ac.ru, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Functions Clean-up From: "David S. Miller" In-Reply-To: <1036328414.1048.3.camel@arwen> References: <20021103.115427.104445233.yoshfuji@linux-ipv6.org> <1036328414.1048.3.camel@arwen> 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: 1078 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: Andras Kis-Szabo Date: Sun, 03 Nov 2002 14:00:14 +0100 (And we should not to trust in the kernel.) If you can't trust the exthdr parser in the kernel, you probably can't trust the kernel to even give you the packets correctly in the first place. So you better just rm -rf netfilter/ while you have the chance :-) From yoshfuji@linux-ipv6.org Sun Nov 3 05:16:04 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Nov 2002 05:16:06 -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 gA3DG2uR025976 for ; Sun, 3 Nov 2002 05:16:03 -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 gA3DGwGR005478; Sun, 3 Nov 2002 22:16:58 +0900 Date: Sun, 03 Nov 2002 22:16:58 +0900 (JST) Message-Id: <20021103.221658.52523847.yoshfuji@linux-ipv6.org> To: kisza@securityaudit.hu Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, davem@redhat.com, kuznet@ms2.inr.ac.ru, usagi@linux-ipv6.org, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPv6: Functions Clean-up From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <1036328414.1048.3.camel@arwen> References: <20021103.115427.104445233.yoshfuji@linux-ipv6.org> <1036328414.1048.3.camel@arwen> 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: 1079 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 <1036328414.1048.3.camel@arwen> (at Sun, 03 Nov 2002 14:00:14 +0100), Andras Kis-Szabo says: > This patch removes one function from the Netfilter code and forces the > Netfilter to use a similar function from the kernel's one! net/ipv6/netfilter/ip6_queue.c says: /* * Taken from net/ipv6/ip6_output.c * We should use the one there, but is defined static * so we put this just here and let the things as * they are now. * * If that one is modified, this one should be modified too. */ So, the reason why the copy of route6_me_harder() lives there is because net/ipv6/ip6_output.c has not been exported it. Is this something to do with parser of extension headers? Parser of extension headers is different thing, isn't it? Yes, since duplication of code is bad unless there're really strong reasons. I believe that there would be a better design for filtering. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@linux-ipv6.org Sun Nov 3 05:19:16 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Nov 2002 05:19:18 -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 gA3DJAuR026337 for ; Sun, 3 Nov 2002 05:19:16 -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 gA3DKAGR005520; Sun, 3 Nov 2002 22:20:10 +0900 Date: Sun, 03 Nov 2002 22:20:10 +0900 (JST) Message-Id: <20021103.222010.31188042.yoshfuji@linux-ipv6.org> To: kisza@securityaudit.hu Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, davem@redhat.com, kuznet@ms2.inr.ac.ru, usagi@linux-ipv6.org, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPv6: Functions Clean-up From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20021103.221658.52523847.yoshfuji@linux-ipv6.org> References: <20021103.115427.104445233.yoshfuji@linux-ipv6.org> <1036328414.1048.3.camel@arwen> <20021103.221658.52523847.yoshfuji@linux-ipv6.org> 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=iso-2022-jp Content-Transfer-Encoding: 7bit X-archive-position: 1080 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 <20021103.221658.52523847.yoshfuji@linux-ipv6.org> (at Sun, 03 Nov 2002 22:16:58 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: > So, the reason why the copy of route6_me_harder() > lives there is because net/ipv6/ip6_output.c has not been ~~~~~~~~~~~~does not > exported it. ~~~~~~~~export --yoshfuji From jmorris@intercode.com.au Sun Nov 3 05:22:43 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Nov 2002 05:22:44 -0800 (PST) Received: from blackbird.intercode.com.au (IDENT:root@blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA3DMeuR026727 for ; Sun, 3 Nov 2002 05:22:41 -0800 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id AAA07546; Mon, 4 Nov 2002 00:22:39 +1100 Date: Mon, 4 Nov 2002 00:22:39 +1100 (EST) From: James Morris To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: kisza@securityaudit.hu, , , , , , Subject: Re: [PATCH] IPv6: Functions Clean-up In-Reply-To: <20021103.221658.52523847.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 1081 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 Sun, 3 Nov 2002, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > So, the reason why the copy of route6_me_harder() > lives there is because net/ipv6/ip6_output.c has not been > exported it. > Yes. It would be much better to use common core networking code. - James -- James Morris From kisza@securityaudit.hu Mon Nov 4 05:01:54 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Nov 2002 05:01:59 -0800 (PST) Received: from addu.axelero.hu (mail02.axelero.hu [195.228.240.77]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA4D1ruR025565 for ; Mon, 4 Nov 2002 05:01:54 -0800 Received: from localhost.localdomain (adsl-151-82.adsl-pool.axelero.hu [62.201.82.151]) by mail02.axelero.hu (iPlanet Messaging Server 5.1 HotFix 0.6 (built Apr 26 2002)) with ESMTP id <0H50004BF5EJ7C@mail02.axelero.hu> for netdev@oss.sgi.com; Sun, 03 Nov 2002 14:27:55 +0100 (MET) Date: Sun, 03 Nov 2002 15:27:42 +0100 From: Andras Kis-Szabo Subject: Re: [PATCH] IPv6: Functions Clean-up In-reply-to: <20021103.221658.52523847.yoshfuji@linux-ipv6.org> To: YOSHIFUJI Hideaki / =?UTF-8?Q?=E5=90=89=E8=97=A4=E8=8B=B1?= =?UTF-8?Q?=E6=98=8E?= Cc: linux-kernel@vger.kernel.org, Netdev , Netfilter Devel , "David S. Miller" , kuznet@ms2.inr.ac.ru, usagi@linux-ipv6.org Message-id: <1036333662.12980.27.camel@arwen> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.0.8 Content-type: text/plain Content-transfer-encoding: 7BIT References: <20021103.115427.104445233.yoshfuji@linux-ipv6.org> <1036328414.1048.3.camel@arwen> <20021103.221658.52523847.yoshfuji@linux-ipv6.org> X-archive-position: 1082 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kisza@securityaudit.hu Precedence: bulk X-list: netdev Hi, > /* > * Taken from net/ipv6/ip6_output.c > * We should use the one there, but is defined static > * so we put this just here and let the things as > * they are now. > * > * If that one is modified, this one should be modified too. > */ > > So, the reason why the copy of route6_me_harder() > lives there is because net/ipv6/ip6_output.c has not been > exported it. Ok, ok! I have not got problems with this any more! :) It is even worse that the route6_me_harder() depends on the CONFIG_NETFILTER option, so this function comes from the Netfilter. In this case it is an unwanted code-duplication :( > Is this something to do with parser of extension headers? > Parser of extension headers is different thing, isn't it? Yes, it is a different thing with different code. Regards, kisza -- Andras Kis-Szabo Security Development, Design and Audit -------------------------/ Zorp, NetFilter and IPv6 kisza@SecurityAudit.hu /-------------------------------------------> From hadi@cyberus.ca Mon Nov 4 05:17:13 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Nov 2002 05:17:18 -0800 (PST) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA4DHCuR026229 for ; Mon, 4 Nov 2002 05:17:13 -0800 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id IAA11724; Mon, 4 Nov 2002 08:18:11 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id gA4DAbO01669; Mon, 4 Nov 2002 08:10:38 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 4 Nov 2002 08:10:37 -0500 (EST) From: jamal To: Cheng Jin cc: "netdev@oss.sgi.com" Subject: Re: Linux SMP on 2.4.18-3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1083 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 Mon, 28 Oct 2002, Cheng Jin wrote: > > The IP network stack in linux is totaly reentrant. You could have a > > packet on _each_ processor in SMP concurently executing the same code. If > > you add anything, you need to take this into account. > > We did add code to the TCP layer, but I don't exactly see anything in the > original code where locking is used. I assume the locks are in the IP > layer and lower? There are a few, but they are irrelevant in your case since you dont touch that code (eg the dst cache lock). As far as TCP is concerned, serialization between SMP processors happens with the socket lock. This lock is also used to sequence packets [Remember TCP has to ensure that packets are sequenced for processing by user process. Also remember that TCP runs in both user and process context]. > The weirdest thing is that we noticed in > update_send_head, tp->packets_out sometimes increases by more than one > even though the code ++ it only once. I guess I am not sure how we could > have screwed it up if the modifications are on the TCP layer. > Anything that you want to serialize access to you should put in the sock struct; then use the sock lock to serialize. cheers, jamal From hadi@cyberus.ca Mon Nov 4 05:21:35 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Nov 2002 05:21:37 -0800 (PST) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA4DLZuR026608 for ; Mon, 4 Nov 2002 05:21:35 -0800 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id IAA12920; Mon, 4 Nov 2002 08:22:09 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id gA4DEY901678; Mon, 4 Nov 2002 08:14:35 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 4 Nov 2002 08:14:34 -0500 (EST) From: jamal To: Andi Kleen cc: Rik van Riel , netdev , Arnaldo Carvalho de Melo Subject: Re: multipath routing doesn't work with netlink In-Reply-To: <20021030073722.A30664@oldwotan.suse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1084 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 Wed, 30 Oct 2002, Andi Kleen wrote: > - real multipath routing. > It is configured by setting multiple nexthops to a single route > (ip route add ... nexthop ... ) > The kernel will do load balancing by route (=srcip/dstip/tos tripple) > The only caveat is of course you have to wait for the cache entry to expire ;-> (or ARPs to fail etc). I have a patch that will force specific cache entries to be deleted via netlink; if theres a fireman/woman with some time in their hand and willing to write something in user space, contact me ;-> cheers, jamal From hadi@cyberus.ca Mon Nov 4 05:40:51 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Nov 2002 05:40:53 -0800 (PST) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA4DeouR027030 for ; Mon, 4 Nov 2002 05:40:51 -0800 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id IAA19545; Mon, 4 Nov 2002 08:41:49 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id gA4DYGw01731; Mon, 4 Nov 2002 08:34:16 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 4 Nov 2002 08:34:16 -0500 (EST) From: jamal To: Oskar Andreasson cc: Subject: Re: [RFC] Badly documented sysctl? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1085 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 You are correct. So fix the doc. cheers, jamal On Fri, 1 Nov 2002, Oskar Andreasson wrote: > Hi, > > I just started checking out the /proc/sys/net/ipv4/route/error_cost and > error_burst sysctl's. According to > linux/Documentation/filesystems/proc.txt: > > ---- > > error_burst and error_cost > -------------------------- > > These parameters are used to limit the warning messages written to the > kernel log from the routing code. The higher the error_cost factor is, > the fewer messages will be written. Error_burst controls when messages > will be dropped. The default settings limit warning messages to one every > five seconds. > > ---- > > I just spent some time reading the source code in question, and if I am > not totally off base... this is totally wrong? I am currently checking > linux/net/ipv4/route.c, and if I am right, it limits how many > ICMP_DEST_UNREACH we are sending to a specific host, and _possibly_ it > will also printk() in the ip_rt_send_redirect() function. I don't know for > sure, but I _think_ the default settings will limit ICMP_DEST_UNREACH > sending in ip_error() to 5 per second... > > If anyone would shed some light on this, I would be tremenduously happy! > > ---- > Oskar Andreasson > http://www.frozentux.net > mailto:blueflux@koffein.net > > From blueflux@koffein.net Mon Nov 4 12:34:49 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Nov 2002 12:34:54 -0800 (PST) Received: from laptop1.agatha ([195.163.42.242]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA4KYluR002772 for ; Mon, 4 Nov 2002 12:34:48 -0800 Received: from localhost (blueflux@localhost) by laptop1.agatha (8.11.6/8.11.6) with ESMTP id gA4KSYH31691; Mon, 4 Nov 2002 21:29:05 +0100 X-Authentication-Warning: laptop1.agatha: blueflux owned process doing -bs Date: Mon, 4 Nov 2002 21:28:34 +0100 (CET) From: Oskar Andreasson X-X-Sender: blueflux@laptop1.agatha To: jamal cc: netdev@oss.sgi.com Subject: [PATCH] Documentation fixes (was: Re: [RFC] Badly documented sysctl?) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463810815-1330789550-1036441714=:31688" X-archive-position: 1086 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: blueflux@koffein.net 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. ---1463810815-1330789550-1036441714=:31688 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Jamal, I have attached two patches for linux/Documentation/filesystems/proc.txt. One is for 2.5.45 kernels, and the other is for 2.4.19 kernels. I actually don't think there is a need for two patches, but I thought I would go with the safe side. This is a first time patch for me, so please forgive me if there's anything wrong with the format etc. Let me know if there is any problems with the patches. On Mon, 4 Nov 2002, jamal wrote: > > You are correct. So fix the doc. > > cheers, > jamal > > > On Fri, 1 Nov 2002, Oskar Andreasson wrote: > > > Hi, > > > > I just started checking out the /proc/sys/net/ipv4/route/error_cost and > > error_burst sysctl's. According to > > linux/Documentation/filesystems/proc.txt: > > > > ---- > > > > error_burst and error_cost > > -------------------------- > > > > These parameters are used to limit the warning messages written to the > > kernel log from the routing code. The higher the error_cost factor is, > > the fewer messages will be written. Error_burst controls when messages > > will be dropped. The default settings limit warning messages to one every > > five seconds. > > > > ---- > > > > I just spent some time reading the source code in question, and if I am > > not totally off base... this is totally wrong? I am currently checking > > linux/net/ipv4/route.c, and if I am right, it limits how many > > ICMP_DEST_UNREACH we are sending to a specific host, and _possibly_ it > > will also printk() in the ip_rt_send_redirect() function. I don't know for > > sure, but I _think_ the default settings will limit ICMP_DEST_UNREACH > > sending in ip_error() to 5 per second... > > > > If anyone would shed some light on this, I would be tremenduously happy! > > > > ---- > > Oskar Andreasson > > http://www.frozentux.net > > mailto:blueflux@koffein.net > > > > > > > -- ---- Oskar Andreasson http://www.frozentux.net http://iptables-tutorial.frozentux.net http://ipsysctl-tutorial.frozentux.net mailto:blueflux@koffein.net ---1463810815-1330789550-1036441714=:31688 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="2.4.19.docs.proc.txt.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="2.4.19.docs.proc.txt.diff" ZGlmZiAtdXIgbGludXgtMi40LjE5L0RvY3VtZW50YXRpb24vZmlsZXN5c3Rl bXMvcHJvYy50eHQgbGludXgtMi40LjE5Lm5ldy9Eb2N1bWVudGF0aW9uL2Zp bGVzeXN0ZW1zL3Byb2MudHh0DQotLS0gbGludXgtMi40LjE5L0RvY3VtZW50 YXRpb24vZmlsZXN5c3RlbXMvcHJvYy50eHQJV2VkIE5vdiAgNyAyMzozOToz NiAyMDAxDQorKysgbGludXgtMi40LjE5Lm5ldy9Eb2N1bWVudGF0aW9uL2Zp bGVzeXN0ZW1zL3Byb2MudHh0CU1vbiBOb3YgIDQgMjA6NDg6NTIgMjAwMg0K QEAgLTE1OTIsMTAgKzE1OTIsMTMgQEANCiBlcnJvcl9idXJzdCBhbmQgZXJy b3JfY29zdA0KIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogDQotVGhl c2UgcGFyYW1ldGVycyAgYXJlIHVzZWQgdG8gbGltaXQgdGhlIHdhcm5pbmcg bWVzc2FnZXMgd3JpdHRlbiB0byB0aGUga2VybmVsDQotbG9nIGZyb20gIHRo ZSAgcm91dGluZyAgY29kZS4gIFRoZSAgaGlnaGVyIHRoZSBlcnJvcl9jb3N0 IGZhY3RvciBpcywgdGhlIGZld2VyDQotbWVzc2FnZXMgd2lsbCAgYmUgd3Jp dHRlbi4gRXJyb3JfYnVyc3QgY29udHJvbHMgd2hlbiBtZXNzYWdlcyB3aWxs IGJlIGRyb3BwZWQuDQotVGhlIGRlZmF1bHQgc2V0dGluZ3MgbGltaXQgd2Fy bmluZyBtZXNzYWdlcyB0byBvbmUgZXZlcnkgZml2ZSBzZWNvbmRzLg0KK1Ro ZXNlICBwYXJhbWV0ZXJzICBhcmUgdXNlZCB0byBsaW1pdCBob3cgbWFueSBJ Q01QIGRlc3RpbmF0aW9uIHVucmVhY2hhYmxlIHRvIA0KK3NlbmQgIGZyb20g IHRoZSAgaG9zdCAgaW4gcXVlc3Rpb24uIEl0IHdpbGwgYWxzbyBwcmludCBz b21lIGVycm9yIG1lc3NhZ2VzIHRvIA0KK2tlcm5lbCAgbG9ncyAgaWYgIHNv bWVvbmUgIGlzICBpZ25vcmluZyAgb3VyICBJQ01QICByZWRpcmVjdHMuIFRo ZSBoaWdoZXIgdGhlIA0KK2Vycm9yX2Nvc3QgIGZhY3RvciAgaXMsICB0aGUg ZmV3ZXIgZGVzdGluYXRpb24gdW5yZWFjaGFibGUgYW5kIGVycm9yIG1lc3Nh Z2VzIA0KK3dpbGwgIGJlICBsZXQgIHRocm91Z2guICBFcnJvcl9idXJzdCAg Y29udHJvbHMgIHdoZW4gIGRlc3RpbmF0aW9uIHVucmVhY2hhYmxlIA0KK21l c3NhZ2VzICBhbmQgIGVycm9yICBtZXNzYWdlcyAgd2lsbCAgYmUgIGRyb3Bw ZWQuIFRoZSBkZWZhdWx0IHNldHRpbmdzIGxpbWl0IA0KK3dhcm5pbmcgbWVz c2FnZXMgdG8gZml2ZSBldmVyeSBzZWNvbmQuDQogDQogZmx1c2gNCiAtLS0t LQ0K ---1463810815-1330789550-1036441714=:31688 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="2.5.45.docs.proc.txt.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="2.5.45.docs.proc.txt.diff" ZGlmZiAtdXIgbGludXgtMi41LjQ1Lm9sZC9Eb2N1bWVudGF0aW9uL2ZpbGVz eXN0ZW1zL3Byb2MudHh0IGxpbnV4LTIuNS40NS9Eb2N1bWVudGF0aW9uL2Zp bGVzeXN0ZW1zL3Byb2MudHh0DQotLS0gbGludXgtMi41LjQ1Lm9sZC9Eb2N1 bWVudGF0aW9uL2ZpbGVzeXN0ZW1zL3Byb2MudHh0CU1vbiBOb3YgIDQgMjE6 MDA6MzQgMjAwMg0KKysrIGxpbnV4LTIuNS40NS9Eb2N1bWVudGF0aW9uL2Zp bGVzeXN0ZW1zL3Byb2MudHh0CU1vbiBOb3YgIDQgMjE6MTA6NDMgMjAwMg0K QEAgLTE0NDUsMTAgKzE0NDUsMTMgQEANCiBlcnJvcl9idXJzdCBhbmQgZXJy b3JfY29zdA0KIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogDQotVGhl c2UgcGFyYW1ldGVycyAgYXJlIHVzZWQgdG8gbGltaXQgdGhlIHdhcm5pbmcg bWVzc2FnZXMgd3JpdHRlbiB0byB0aGUga2VybmVsDQotbG9nIGZyb20gIHRo ZSAgcm91dGluZyAgY29kZS4gIFRoZSAgaGlnaGVyIHRoZSBlcnJvcl9jb3N0 IGZhY3RvciBpcywgdGhlIGZld2VyDQotbWVzc2FnZXMgd2lsbCAgYmUgd3Jp dHRlbi4gRXJyb3JfYnVyc3QgY29udHJvbHMgd2hlbiBtZXNzYWdlcyB3aWxs IGJlIGRyb3BwZWQuDQotVGhlIGRlZmF1bHQgc2V0dGluZ3MgbGltaXQgd2Fy bmluZyBtZXNzYWdlcyB0byBvbmUgZXZlcnkgZml2ZSBzZWNvbmRzLg0KK1Ro ZXNlICBwYXJhbWV0ZXJzICBhcmUgdXNlZCB0byBsaW1pdCBob3cgbWFueSBJ Q01QIGRlc3RpbmF0aW9uIHVucmVhY2hhYmxlIHRvIA0KK3NlbmQgIGZyb20g IHRoZSAgaG9zdCAgaW4gcXVlc3Rpb24uIEl0IHdpbGwgYWxzbyBwcmludCBz b21lIGVycm9yIG1lc3NhZ2VzIHRvIA0KK2tlcm5lbCAgbG9ncyAgaWYgIHNv bWVvbmUgIGlzICBpZ25vcmluZyAgb3VyICBJQ01QICByZWRpcmVjdHMuIFRo ZSBoaWdoZXIgdGhlIA0KK2Vycm9yX2Nvc3QgIGZhY3RvciAgaXMsICB0aGUg ZmV3ZXIgZGVzdGluYXRpb24gdW5yZWFjaGFibGUgYW5kIGVycm9yIG1lc3Nh Z2VzIA0KK3dpbGwgIGJlICBsZXQgIHRocm91Z2guICBFcnJvcl9idXJzdCAg Y29udHJvbHMgIHdoZW4gIGRlc3RpbmF0aW9uIHVucmVhY2hhYmxlIA0KK21l c3NhZ2VzICBhbmQgIGVycm9yICBtZXNzYWdlcyAgd2lsbCAgYmUgIGRyb3Bw ZWQuIFRoZSBkZWZhdWx0IHNldHRpbmdzIGxpbWl0IA0KK3dhcm5pbmcgbWVz c2FnZXMgdG8gZml2ZSBldmVyeSBzZWNvbmQuDQogDQogZmx1c2gNCiAtLS0t LQ0K ---1463810815-1330789550-1036441714=:31688-- From info@ecomputersupport.com Mon Nov 4 17:15:40 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Nov 2002 17:15:45 -0800 (PST) Received: from mail.imaginethatgraphic.com (IDENT:87LckW+p9kz9dL0f5YjRviR1+XIe0B0O@12-225-48-222.client.attbi.com [12.225.48.222]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA51FduR010589 for ; Mon, 4 Nov 2002 17:15:39 -0800 Received: (qmail 7884 invoked from network); 1 Sep 2002 11:18:50 -0000 Received: from unknown (HELO bup) (209.210.10.127) by 12-225-48-222.client.attbi.com with SMTP; 1 Sep 2002 11:18:50 -0000 Message-ID: <001501c28458$0fa2a120$6c0a0a0a@pacstar> From: "E-Computer Support" To: Subject: Free setup until 2003 Date: Mon, 4 Nov 2002 15:06:06 -0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0011_01C28414.205BE1A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-archive-position: 1087 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: info@ecomputersupport.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C28414.205BE1A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0012_01C28414.20D15FC0" ------=_NextPart_001_0012_01C28414.20D15FC0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable E-Computer Support: Hosting Made Easy ---------------------------------------------------------------------------= -------------------- This is a E-Computer Support special membership mailing! Please see the bottom of this mailing for subscription information. ---------------------------------------------------------------------------= ----------------------=20 =20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 E-Computer Support can make it easy to swit= ch hosts for less. Choose secure and reliable shared solutions priced just = right for small and medium business. Hurry, offer ends 1/1/03.=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 Check out our current E-Computer Support of= ferings below.=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 Save $80-$100 when you sign up now for any= E-Computer Support shared hosting solution. We'll do the set-up free. a.. Free Domain Transfers=20 b.. Unlimited Email Accounts=20 c.. Unlimited Traffic=20 d.. Email@Domain.com Accounts=20 e.. Free Hosting Offers=20 f.. Online Control Panel=20 g.. Spam Filtering=20 h.. Check out all available packages, here= =20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20 =20=20=20=20=20=20=20=20 To unsubscribe from these special newsletter mailings reply to this message= with "R" in the subject.=20 ------=_NextPart_001_0012_01C28414.20D15FC0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable E-Computer Support: Hosting Made Easy
 
------------------------------------------------------------------= -----------------------------
This=20 is a E-Computer Support special membership mailing!
Please see the botto= m of=20 this mailing for subscription=20 information.
-----------------------------------------------------------= --------------------------------------=20
3D""=20
3D""
3D""
  
3D""
3D""=20
3D""  
3D""
=
3D""=20
3D""=20
3D""
E-Computer Support can=20 make it easy to switch hosts for less. Choo= se=20 secure and reliable shared solutions priced= just=20 right for small and medium business. Hurry,= =20 offer ends 1/1/03.
3D""
Check out our current E-Computer S= upport=20 offerings below.=20
3D""=20
3D""
= <= /TR>
3D""=20
3D""=
3D""
3D""=20
Save $80-$100 when you sign up now= for=20 any E-Computer Support  shared hosting= =20 solution. We'll do the set-up free.
  • Free Domain Transfers=20
  • Unlimited Email Accounts=20
  • Unlimited Traffic=20
  • Email@Doma= in.com=20 Accounts=20
  • Free Hosting Offers=20
  • Online Control Panel=20
  • Spam Filtering=20
  • Check out all available packages, here=20
= 		3D""=20
 3D""=
3D""=20
3D""
3D""=20
   
 

To unsubscribe from these special newsletter mailings reply to thi= s=20 message with "R" in the subject.

------=_NextPart_001_0012_01C28414.20D15FC0-- ------=_NextPart_000_0011_01C28414.205BE1A0 Content-Type: image/jpeg; name="ecomputersupport.jpg" Content-Transfer-Encoding: base64 Content-Location: http://www.ecomputersupport.com/newsletter/ecomputersupport.jpg /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAPAAA/+4ADkFk b2JlAGTAAAAAAf/bAIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAoKCwoKDBAM DAwMDAwQDA4PEA8ODBMTFBQTExwbGxscHx8fHx8fHx8fHwEHBwcNDA0YEBAY GhURFRofHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8f/8AAEQgAMAB9AwERAAIRAQMRAf/EAG4AAQABBQEBAAAAAAAA AAAAAAAGAgMEBQcBCAEBAAAAAAAAAAAAAAAAAAAAABAAAgIBAwQABQQBBAMA AAAAAQIDBAUAERIhEwYHMUEiMhRRYUIVNHEjMxdDFggRAQAAAAAAAAAAAAAA AAAAAAD/2gAMAwEAAhEDEQA/APqnQNA0HNvOPY+ZwHsTD+ORSU4cbk6E9lp5 q008wnjlWKNF4TwrxdpB8R0/XQSDPecVPF/EbeTzs9afL4rH/lZGjUYKXmSI M6xRu0jqjufp5E7A9ToMXxzL+YXPGcT5JkrWPgr3YYshkqghkVa1SSHu8Ypj Kd3jBXmzrsdjxC9NBbX3J4L/AFcuTazMlaI0iVMEhkaLKf4U6xqGcxz/AMem /wCoGg9x/uDw69kYcdG1qO5PPfqLHLXdNrWKUvbgLfbzRF5fHY/rvoMZPefr 1se2QazYjqfi178UklaVTLVtWRUSaNSOTKLDKjdOm4PwO+gu5b2/47UES1IL N6Z/IF8XljjjK9u9sJJAS33BYiWXjvyPT9wFM/u/13DXydl77mvioTZnlSJn DwJbNGSWILuzqlkcG6foRupB0EuxGXr5WvLPBFPFHFNJBtZieBmMTceaq4BK N8Vb5jQZ2gaBoGgaBoGgiuc9eY7L+WUvKJL9yvkKFSajDFD+M0BinIL8kmgl JO4Hz0GQ3gHi1jHzVcnSjyk9qu9S9krccRuWI5QVfuTRpGfqB/hxA+QGw0Fr C+CwY3Ax+OyZK1ewUFdqUFOx2t/xWjMQhkkREd1SM8U+B2+PI9dBHU9D+L/1 UmPkv325ri4EtBoFlSvhDvShH+yU2B6u3Hdj8x8NBdHpjB1L4zFS7fmyFe/l 8xXhd63be1mYDDYRtoUPb2+wcgR8ydBHfGfQFaz4NUx3lNmxHmFxEGGY13hK 1o610XgYiEIflPFGx57/AEgDod9BJ/8ApvCCM7ZO+bB8iXys2GNcsL4j7LBV EKp22T+JB2Pz0GP/ANG+N/8AqeY8T/sLyYPKySusMf44krJNYW08UUrQsxXu r07nLYE/66DoyghQCSxA2LHbc/udthoPdA0DQNA0DQNA0Fq5JPFUnlrxd+wk bNDBuF5uFJVOR6Dkem+g5T4n7vx9qheyGcvx1pMLSax5JhHpzV8hRsLJEjcY 2eTu115t9QBPw3PXYBKbHtrwyCSWJ55zJDkauHdErys35l5BJXQBQSQ6kdR0 /XQWX9y+FLWpTI9qaTILfaCrFWkecPiv82N0A+h4fmG+P8d9Bkx+1/B5bdOv Bf7yXVpMllEYwx/2gb8FZXO3FrHbYKNun8ttxoNTm/eXitDA5DL1Kt6/Hj2l gkZK0iQizFajpmF5nARW706fDc8dyAdtB0OGTuwpJxZOahuDjZl3G+zD5EaC rQNA0DQNA0DQNA0Fm9VW5SsVGdo1sRvE0iHZlDqV3U/qN+mghue9TYbyGvZj zd2zdsT42bER3iII7CV7DI7sWjjUSScoV2LDYddlHJtwjfkvpq3EtKfBW7Ny 7P5Hh81lprL1l4R4xO2zwKsca8iirsrcgToPMl6ZsxZ/xePD2Jo8bSXPvmsm zQmw0+bRN3SNlKfcrdAmyjb49dBu4fR3h1ezTaq1iGnWGL71IMjJO2E5/gvI zKX3XufXxYB9h++4ZE3qDASeD5bxD824aOXvPkprLtCZksPaS39HGNE4CWMd Cp6dN9BOI0ZI1RnMjKADI23JiB8TxCruf2Ggq0DQNA0DQNA0Fq5Y/GqT2e28 3ZjaTtRjk78FJ4qPmx22Gg5dF7yWfwbIeX0KdLJVMfQa7ZqV7rLPXnV41/Ds o8HON+LsQ/HY8fhtsSEzqewvELGOa6MnABFKlaeJWLSJZePuiEIBzZin1DZe q9R00Hr+xfBUWuzZyntbrx3Ku0oPdrzSrBHKgH3KZXCbj56CtPP/AAx4LM6Z is8VSSOKYq+55zyGKEIB1fuyKUThvyYEDfbQYHhfnzeT+MZHNx0VrNQt3qi1 +8ZFk/CkZOfc7aFRJx324Hb99BFsJ70fK4zwe7Hh4Uk8ztSVTWF7k9QR89nb auOfIR/DZdBPF838SZripla7NQBNoK2+wWQwnjt9+0w7Z4b/AF/T93TQazKe 0PFalmKjFaWW/ZpW79dZA8UKx0iUk78hU9raQcTuu42O46aCun7M8QNSh/YZ ejWyFuGlLJWjnEqK19FMJWTivKJ2bZJCAD0+G+2g2UHmfi1jMthYMnBLk1kk hNZG5N3IArTICPpLRCRe4Ad13HLbcaDc6BoGgaBoLN6GaelYgglNeeWN0inA 3MbspCuB0+09dBzHyT0fDnxlbMlunjcvlcZNireQoUzGtjvyxStYsw94CR17 OyDl05Elm6BQSemMt+Tfli8giEWUylTI3IjSIPbq1PxTCj98spfZW5KV+anc E6C94P6Zl8dv4a3by0d0Yrx+Tx5oErGPmHtCyLCyGV+DAKF48f33+Wg1uM9A /wBf43j8dFka39rhLtS3i8sKhWWWPH2TYrw3f909xQGK/RxA+7YnQTHwrwS1 4341lMPJkEtzZK5eu/krAYljN5zIU7ZlctwLfHkN9BF8J6LfFYzwelHmIXk8 MtSWjZFHi9sSc9kbaweHESfHdtBRS9CwVo3rS34btGCpdx9GrZgdlavkcl/Y ziyVlVmcf8aMnEj7/u2ADJf0xe3o8M8zmthcng5JLUTWJDFkZO5Gwfuxs3YG yfUd2A6nfQax/wD58tNT/GHkUYApYGiG/BJ6YBgyv/k/+Yr1H8f30FXjXifk NH2rPlJMBU/rGyOTnrWBLbSWsLyqs1pUaJqrtZ/Hj5BZyfq34oeagOxaBoGg /9k= ------=_NextPart_000_0011_01C28414.205BE1A0 Content-Type: image/gif; name="spacer.gif" Content-Transfer-Encoding: base64 Content-Location: http://mercury.ientrymail.com/specials/dell/spacer.gif R0lGODlhAQABAPcAAP////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// /////////////////////yH5BAEAAAAALAAAAAABAAEAAAgEAAEEBAA7 ------=_NextPart_000_0011_01C28414.205BE1A0 Content-Type: image/gif; name="hosting.gif" Content-Transfer-Encoding: base64 Content-Location: http://www.ecomputersupport.com/newsletter/hosting.gif R0lGODlhhAATAMQAAOYAJfFwhfzg5OswTvnAyfSQoOgQM+5Qaf////ewu+xA XPOAkukgQPrQ1/7w8vagru9gdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACH5BAQUAP8ALAAAAACEABMAAAX/ICCOZGme aKqubOu+cCzPdG3feK7vfO//wBOEIBoQBq9CIchsmhYIkQKhYCkgAAjWyTUx FjqolCqtigwKM4FYGpgBA+SKoWCw3IZzmoS2l/Z6cih0eWJ8CoIAhCuGUwoG Ag4OAgYDkwhrCJprAJoNmABQAqCKCEtTEAEIowEAnJwjCQgODXkNkpRQl2+Q DggPAAqXCaFRYgSrkgWaZMHDrskOeSlQzFQQCHEIEFAMAUSvRKDLAAJE5iMN AgDLkMQJ6+EjDAgBB1RTB/cKUI8IYCKwDSD3wAEAVV+MRSEgbZ8hEQUPImDA 0MA+Ff0UqOIXpdOCKQ62yPtXzKMrNhIH/wggRvIYOJSOSEBI8ImjCJIiHp4M RkWMS542R3ByNLQZikY9O5I08msnp5ZRSMIqtQwLVKcwjWJ7sNEQzpJCiTjy uVBsUhJFFaTF2NGRKm0BlACQhdWkGHTo0mnK4+CdQU4NUA7YNjYKtqBfEYpJ YPCtGHJpdTJOmTbO0bZU6DX4xGBZAQdEZK0RB4bsKJQS2Tz41VTWatSRbhnA xvisSRGaQWdBwHidqto73SJoIIf2pOBUppagoyfPgAULii8IMC2N5TqKqgyA oBb1lFYiAkw/EyAAIj7Q/XA78Ih5MD9Fpk87AH0atz2W0Th/NIL+AudI6GdZ F4xB4AAwIywDXxwXDDY4QAIEPLBgAQg2aOGFGGao4YYcdughECEAADs= ------=_NextPart_000_0011_01C28414.205BE1A0 Content-Type: image/gif; name="freesetup.gif" Content-Transfer-Encoding: base64 Content-Location: http://www.ecomputersupport.com/newsletter/freesetup.gif R0lGODlhjAEZAMQAADMzM////3Jycr6+vjw8PJmZmWZmZtvb20xMTIyMjKWl pdnZ2VlZWe/v78zMzLOzs3p6euXl5fX19UNDQ8XFxf4BAgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACH5BAUUABUALAAAAACMARkAAAX/YCCOwZIY QKqubOu+cCzPdG3feK7vfO//wCDQkDiQjqODYQIZNJDQqHRKrVqv2Kx2y+16 v+CweEymSgaQicEYVUwSz7J8Tq/b7/i8fp+NJCYKUGkOfIWGh4iJiouJFAQQ Rw8IbIyVlpeYmZp3CwgPIxETFJukpaanqJYUExEiAgmpsXIoKwYBtCkEsCIF LYS9LISyw8RYEAIBEQASxc1cKAXRBZ/Q0QwAu70Q0gWt2tytXwvO5IsRBBEK tuXsVChI7yMICLwAwiS992EKAO3+fAbUBfpHcEQ8Egdv9QuQD0lDKg4cxAHl YNyIXl4W6CvIEZ8BBOE6+kso4mADAsgY/9pzuFKKAwIMru0KAIGAAZtPWEAx sO7WOm030Ykc6gDBwqHtqkUjpDRmuG/S6m2LegQBJJoAWj0AME7ZQIxReBr8 CSDQyatIC0pIkTYpiwIKVRCAW0+nSrskUIqIIJEmgxEMUoLd2VOsyjgQ/rYt yHYxOZIKRTSAULbeRpWXSSQAYECfAQYRHTAgO9awYZ/1Lh513K4x62KQTQK4 +hBfSykFCHCOc5Mnz2xHfa87bXjw4NflXCOXFXs1Z8ssMx9psPnqadtSiJNO vTz56u6ompN4jjm6lAgFhG0WkYBeSeDZC5MNB8E9+GbK75sSP4IAAangqDRV NCEF0AAAKQng3oYAXAXA4FcNQiEAAU8sQF4vZlmlH37fbbgJf64A8AQwK/zi yxG9xETAACPUhAIDcXSSnwgD+MfTaPXwNE+BHqYyY4/6NRAREnxZdIWQPGKk EZDE/Mjkk2QcB6WPHU5p5RdSXlmKk1p2eYUDdHm5ZZVilmkmh0KkqeaabLbp 5ptwxinnnCyEAAA7 ------=_NextPart_000_0011_01C28414.205BE1A0 Content-Type: image/gif; name="orderonline.gif" Content-Transfer-Encoding: base64 Content-Location: http://www.ecomputersupport.com/newsletter/orderonline.gif R0lGODlhBQEtANUAAGZmZpmZmfDw8L29vaSkpNbW1ubm5kBAQHp6erS0tEpK SlZWVoWFhczMzPHx8dvb2/Pz8/Ly8jo6Ompqan5+fuzs7Ofn58PDw6ioqJyc nEtLS5ubm+np6fT09O3t7dDQ0Ovr6zQ0NOXl5TMzM////+/v7wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAAFAS0AAAb/ wFFpSCwaj8ikcslsOp/QqNQoqFqvWOx0y+0Whd6weEwum8/oMRhaYAAQjWWA YJ6XCoEBmhBI+/+AaGtPCiMAByMFSoZmjAMjfVKKSwCDgZeYmUuWTI8MJQmQ iwCNpFwApkqVmqytrJxyI3oljHwJdAEAoaQGuQh6eAkIRQOoAQYltgCRjHh6 c7kJQwSodEQEIwp01ADWCcurJbnLJQMBcQQbruvsU7BKAbJDjJWQj2+MCCMM C4mPI2sKjFjAYMSwSvxGxHEkasSBAAcOJDNUyVqJggcYYEM1gk62eEKwBYhH 4FGfEROqtFvJEsm7JPFm0VMoTh6jA6RM3isSs8Qh/59CejI8SWpVOEZEZs4D YBLonQEJ4vXB2WBEBgcCWmpt+RJJT1pFwQglBbBsHlFEehoNajNnw7BAy6YC 6xRs01UDDijo1weAthAfIGTdSnhd1yPY6Ag8KLYt3QIDDDRNK29tTT1D6VqW PGlpXUN3hVSSLCoeAg0OBBde/SqKwAUD9NEJJ7IqqQUHDOiDjHZIqGMHFjgd W+6t04IDEn9Z0AC5J4EADBQC2ktU1REUInAYzLo7oMNHQCINZwBRP1IJEBks HolIvQPSVhFvqrRAoYHIKAOwD1CBokp6CRGKQWghgkEEIHDn3YJngHcEZ0lI ZgSESzQQmRgDxLHEALMMcf8hEQV0NkQ/FohQgYIMpiiGgyoGYsBAJXhQAoot 1igFizamUUwfDmCV449R4AhkGgL4OOSRiyC5jkpKNvmFk60wCaWSQk4pBo1W 5lhllplkYQWX6/gH5lZVRNABBD1+OWYr3azJkpdYunkJNXLWaecSBkjwwJ18 9knCG30GWicJ0kkj6KFckkBCehcg6iiUipKAgAIdPmrpj5GSQIAECOx56act ZkrCAwBI0I2IoKZKmKiKPuBGWbDGKuustNZq66245qrrrrz26uuvwAYr7Ais Fmvsscgmq+yyzDbr7LPQRivttNRWa+212Gar7bbcduvtt+CGK+645JZr7rno pqs37rrstuvuu/DGK++89NZr77345qvvvvz26++/AAcs8MAEF2zwwQgnrPDC DDfs8MMQRyzxxMwGAQA7 ------=_NextPart_000_0011_01C28414.205BE1A0 Content-Type: image/gif; name="savenow.gif" Content-Transfer-Encoding: base64 Content-Location: http://www.ecomputersupport.com/newsletter/savenow.gif R0lGODlhhwAtANUAACoqKubm5oaGhuYAJczMzOswTpMYK/b29vFwhWZmZvew u9gEJt7e3ugQM729ve5Qae/v70wsMfSQoKurq/rQ1/zg5Do6OmEmL+kgQOxA XKenp/OAknNzc/////7w8khISJmZmdfX1/nAyfagru9gd+ACJUIvMnQgLsXF xVtbWzMzM7W1tc8HJ2ZmZnt7e54UK0VFRYyMjN8CJtYFJmshMXsfLVEqMUox MZ4VK/4BAgAAAAAAAAAAAAAAAAAAAAAAACH5BAUUADkALAAAAACHAC0AAAb/ QIhwSCwaj8ikcslsOp9OFXRKrVqvWIg0y+16v8gteEwuR83otFqsbruz7Ld8 3ozT7/ihPc+X7/uAaX+BhGODhYhch4mMVYuNkGeRk1aPlJdFlpibmpuXnZ6T oKGNDKOkiQ4fagGtrq+wsbKztLW2sl0CCWQaNiq/wMHCw8TFxsfIxjYgrlcp GmAMNjY4CwPX2Nna29zd3t/g3Asv0wQMAVUhFuhfNjUl4fHy8/TiJzYh51Qc HB1fvdbqCRxIUJsNAfnYOVkBI4A/LxcMFJxIcZ4BGygSOkFhYUWHh11MsJCX oQC2Ahm+leRWAAM2DCnjNdA2MxwLFQ7MKVSy4oOL/48gFcmkIKLDhgEkKiht MELENQoPMFQoiuBkBwUUOqTcoLRCgwpHEXR4MEDCCGxGaw5IC66EihUZdx5h 4MKCBqBB4cTbQGEAgqMeCjTQSqLDAAwdGphF6gFbhg4uKWwY7NIDCQUKBhSV MKAC2WsFRFgGLZoEuLcOQsgVEoCAhgQqEoTA2yGZbWDxHlOIiUFC0QyDHyDI LELEhhGGrz2+Zny55g0IKqwdQWGw2msPKlBwOSD7dm8qAIg/lgAh7fPo06dX IS90BxINPCB4nFKEb9PFN0B3nLx5/w2IPUBBAe/1RZMEFXCnWILg5cQABAeo J+GEFALFXjgbmKaACMsNlv8SAlnNpMBZGDil3H8EmlSBadpx5oFx2iR11DUy nuYghBXmqKOF8UjgAV9RXYVcSoiZWJhvnJ3I3FEtejDTkAMooFU2IoygVpXX dYOTOTju6OWEJswQDwkbxJQBgDENkAF3SGWYTQMmDSDYAA3oVxNM1+CZTZrK xXPTjRF+KSh6EVVk6KHbXATooIziNYEJMiAqaUUyROBCTug0qmkHB9hAQ6ST hlrPAveskFoAgW466AHSmGCAmKLG6g0LF9kwgQNxparqlwdAEAAIvtwm7LDE JmODCyvApVqXuwraKwMhEODAtNRWa+212Gar7bbccpvRg7o2y6uvIURLwLno pqs97rrstuvuu/C6u2y44o7rCgP45qvvvvz26++/AAfcbzP01svrAb2ikgTC BRvMKMMQRyzxxBRXbPHFFjcbBAA7 ------=_NextPart_000_0011_01C28414.205BE1A0 Content-Type: image/gif; name="bottomcurve.gif" Content-Transfer-Encoding: base64 Content-Location: http://www.ecomputersupport.com/newsletter/bottomcurve.gif R0lGODlhYgILAMQAADMzM////2ZmZtXV1Z+fn3t7ezs7O+bm5rS0tEJCQvf3 915eXo2Njd3d3WpqaqWlpcDAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACH5BAQUAP8ALAAAAABiAgsAAAXMIKAEZGme aKqubOu+cCzPdG3feK7vfO//wKBwSGwpAIBGcclsOp/QqHRKrVqvuwFA8MB6 v+CweEwum8+uh4DhQLvf8Lh8Tq8D1w3Dwc7v+/+AgYI6AwZKAgWDiouMjY6P UgoOAiQHCV2QmZqbnJ2OBAl7JBAGCJ6nqKmqq1MKBAYQJxAJBaKst7i5ursl DQUJsSgHAgALBLa8ycrLzHMKA2pbyCgDDMRI2Nna29zd3t/g4eLj5OXm5+jp 6uvs7e7v8PHy8/T19vRrAyghADs= ------=_NextPart_000_0011_01C28414.205BE1A0-- From gmail11jp@yahoo.co.jp Mon Nov 4 18:10:43 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Nov 2002 18:10:49 -0800 (PST) Received: from ooo.no (fb171157.ot.FreeBit.NE.JP [61.203.171.157]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA527juR013804 for ; Mon, 4 Nov 2002 18:09:28 -0800 Received: from 5-A ([192.168.0.3]) by ooo.no (8.9.3+3.2W/3.7W) with SMTP id LAA17487; Tue, 5 Nov 2002 11:06:13 +0900 Message-Id: <200211050206.LAA17487@ooo.no> From: =?iso-2022-jp?B?Z21haWwxMWpw?= To: =?iso-2022-jp?B?MTEwMg==?=@ooo.no Reply-To: gmail11jp@yahoo.co.jp Date: Tue, 05 Nov 2002 11:04:08 +0900 Subject: =?iso-2022-jp?B?GyRCTCQ+NUJ6OS05cCIoRUU7UiVhITwlazktOXAbKEo=?= Content-Type: text/plain Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-archive-position: 1088 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gmail11jp@yahoo.co.jp Precedence: bulk X-list: netdev <‘—MŽÒ> “dŽqƒ[ƒ‹LŽÐ ¡ŒãAL‚ð‚²Šó–]‚µ‚È‚¢•û‚Í‚±‚±‚Ö (•K‚¸–{•¶‚É‚ ‚È‚½‚̃[ƒ‹ƒAƒhƒŒƒX‚Ì‚Ý‚ð‚¨‘‚«‰º‚³‚¢j king@reset.jp ƒ[ƒ‹ƒAƒhƒŒƒX‚ð‚²‹L“ü‚µ‚Ä‚­‚¾‚³‚¢B §104-0061 “Œ‹ž“s’†‰›‹æ‹âÀ8-19-3 ‘æ2ƒEƒCƒ“ƒOƒrƒ‹@3F ƒ[ƒ‹ƒ}ƒKƒWƒ“”­s TEL@03-3544-6222 FAX@03-3544-6218 =============================================================== –â‘褕i‚΂©‚èW‚ß‚Ü‚µ‚½‚Ì‚ÅAÁ‚³‚ê‚é‹°‚ꂪ‚ ‚è‚Ü‚·‚Ì‚Å ‚¨\ž‚Ý‚Í‚¨‘‚ß‚ÉIã‚©‚燂ɃNƒŠƒbƒN‚µ‚Ä‚Ý‚Ä‚ËI =============================================================== ¡@‰ïˆõ§ƒƒŠ[ƒ^ƒNƒ‰ƒu@¡ ‚c‚u‚cEƒrƒfƒI2500‰~‚©‚ç ƒnƒCƒNƒIƒŠƒeƒB‰æŽ¿‚ł̔̔„ƒ}ƒjƒAƒbƒN‚ȉf‘œ‚Ì”X ‚Ü‚¸‚̓Jƒ^ƒƒO¿‹‚¨‘Ò‚¿‚µ‚Ä‚¨‚è‚Ü‚·i‹Ç—¯‚ß‚Å‚Ì¿‹‰Â”\j ‚¨ŽèŒ³‚É‚¨“Í‚­••“›‚É‚ÍA‚¨‹q—l‚Ì‚¨–¼‘O‚Ì‚ÝI“–ŽÐ–¼‚͈êØ“ü‚è‚Ü‚¹‚ñB ƒJƒ^ƒƒO‚ð‚¨Œ©‚ÄA‚¨\‚µž‚Ý‚­‚¾‚³‚¢B –³—¿ƒJƒ^ƒƒO http://fetish.elitecities.com/apple/roriclub/ @«@@@@«@@@@«@@@@«@ http://www.hostingfree.com/datti/roriclub/ @«@@@@«@@@@«@@@@«@ http://www.yentown.net/bbschat-town/sefle/roriclub/ @«@@@@«@@@@«@@@@«@ http://kinyu.www2.dotnetplayground.com/roriclub/ @«@@@@«@@@@«@@@@«@ http://adult.csx.jp/~pool/roriclub/ @«@@@@«@@@@«@@@@«@ http://www.redrival.com/jouhou/roriclub/ @«@@@@«@@@@«@@@@«@ http://www.anzwers.net/hot/hanny/roriclub/ @@@@@@@@@@@@@@@@@@@@@‰ïˆõ§ƒƒŠ[ƒ^ƒNƒ‰ƒu QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ ¡SEXƒtƒŒƒ“ƒh•åW¡ ^Œ•‚ÉSEXƒtƒŒƒ“ƒh‚ð’T‚µ‚Ä‚¢‚él‚¾‚¯W‡I ‘S‘‚Ç‚±‚Å‚à‹ß‚­‚Ìl‚ðƒvƒƒtƒB[ƒ‹•t‚Å‚·‚®Ð‰îB Žá‚¢l‚©‚çn”N‚Ü‚Å‚¢‚Á‚Ï‚¢‚¢‚é‚æ! ƒ_ƒ“ƒi‚É“à‚ÌH‚ðŠy‚µ‚à‚¤I http://web2001.kakiko.com/tuuwa/ @«@@@@«@@@@«@@@@«@ http://www.hostingfree.com/datti/sex/ @«@@@@«@@@@«@@@@«@ http://www.yentown.net/bbschat-town/sefle/sex/ @«@@@@«@@@@«@@@@«@ http://kinyu.www2.dotnetplayground.com/sex/ @«@@@@«@@@@«@@@@«@ http://adult.csx.jp/~pool/sex/ @«@@@@«@@@@«@@@@«@ http://www.redrival.com/jouhou/sex/ @«@@@@«@@@@«@@@@«@ http://www.anzwers.net/hot/hanny/sex/ ƒŒƒ‚ƒ“ƒNƒ‰ƒu QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ ¡‚à‚à‚ª‚Í‚¶‚¯‚Ä‚Ô‚Ç‚¤‚ª‚ä‚ê‚é¡ ‚µ‚¶‚Ý‚Æ‚à‚à‚̃Rƒ‰ƒ{ƒŒ[ƒVƒ‡ƒ“ ƒƒŠ[ƒ^ƒrƒfƒIi‚c‚u‚cjê–å ‚¢‚‚܂ʼnc‹Æ‚Å‚«‚é‚©‚í‚©‚è‚Ü‚¹‚ñ ‚²’•¶‚Í‚¨‘‚ß‚ÉI http://fetish.elitecities.com/apple/roridvd/rori @«@@@@«@@@@«@@@@«@ http://japan.pinkserver.com/mania/ @«@@@@«@@@@«@@@@«@ http://hiyoko18.japanesebabies.com/ @«@@@@«@@@@«@@@@«@ http://freehp.kakiko.com/magazine/ @«@@@@«@@@@«@@@@«@ http://free.memberz.net/member/speed/ @«@@@@«@@@@«@@@@«@ http://muvc.net/hiyoko18/ ì•i—á ­—“`à@–¼ŒÃ‰®’c’n9@­—‚Ì“¹‘ ‚È‚Ç‚È‚Ç132ì•iBD•]”­”„’†I @(^-^)/~ƒƒŠ˜F—˜ƒ€ƒg[ QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ ¡@‚r‚lƒp[ƒgƒi[Љ“ú@¡ ‚r‚lƒp[ƒgƒi[‘¦“úЉîB ‰‡•‚âSMƒNƒ‰ƒu‚Ƃ͈ႢA‚r‚lˆ¤DŽÒ‚¾‚¯‚ªW‚¤‰ïB ‘S‘‚Å‚²Ð‰î‚Å‚«‚Ü‚·B ‚ ‚È‚½‚̃vƒŒƒC‚É‚ ‚킹‚Ä‘¦“úЉîB ƒvƒŒƒC‘ã‹à‚͈êØ‚©‚©‚è‚Ü‚¹‚ñB ”N—î‚Í20ΈÈãB http://fetish.elitecities.com/apple/sm/ @«@@@@«@@@@«@@@@«@ http://www.hostingfree.com/datti/sm/ @«@@@@«@@@@«@@@@«@ http://www.yentown.net/bbschat-town/sefle/sm/ @«@@@@«@@@@«@@@@«@ http://kinyu.www2.dotnetplayground.com/sm/ @«@@@@«@@@@«@@@@«@ http://adult.csx.jp/~pool/sm/ @«@@@@«@@@@«@@@@«@ http://www.redrival.com/jouhou/sm/ @«@@@@«@@@@«@@@@«@ http://www.anzwers.net/hot/hanny/sm/ @@@@@@@@@@@@@@@@@@@@@@@@@‚r‚lƒNƒ‰ƒu \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@lŒ`Žt‚ªì‚Á‚½Œ†ì•i@¡ •ø‚«‚µ‚ß‚½‚­‚È‚é‚悤‚È‚¨lŒ`‚³‚ñ‚ªì‚ê‚Ü‚µ‚½B ”š”­“I‘åƒqƒbƒg¤•iI ”‚ɧŒÀ‚ª‚ ‚邽‚ßA‚¨\‚µž‚Ý‚Í‚¨‘‚ß‚ÉI ™‹Ç•”‚Ü‚Å–{•¨‚»‚Á‚­‚è‚ɧ삵‚½‚½‚ßA“X“ª”Ì”„‚Å‚«‚Ü‚¹‚ñB http://fetish.elitecities.com/apple/dachi/dollc/ @«@@@@«@@@@«@@@@«@ http://www.hostingfree.com/datti/dachi/dollc/ @«@@@@«@@@@«@@@@«@ http://www.yentown.net/bbschat-town/sefle/dachi/dollc/ @«@@@@«@@@@«@@@@«@ http://kinyu.www2.dotnetplayground.com/dachi/dollc/ @«@@@@«@@@@«@@@@«@ http://adult.csx.jp/~pool/dachi/dollc/ @«@@@@«@@@@«@@@@«@ http://www.redrival.com/jouhou/dachi/dollc/ @«@@@@«@@@@«@@@@«@ http://www.anzwers.net/hot/hanny/dachi/dollc/ @@@@@@@@@@@@@@@@@@@@@lŒ`Žt‹{ìƒfƒUƒCƒ“ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@‹t‰‡•ŒðÛ‚­‚ç‚Ô@¡ ‘f“G‚È’j«‚Æ’©‚Ü‚Å“ñlEEEB ‘f“G‚È’j«‚ð¡‚·‚®‹M—‚ÌŒ³‚ÖŒü‚©‚킹‚Ü‚·B ‘S‘ƒlƒbƒgƒ[ƒN‚Å‚·‚®‚ÉЉî‚n‚jB Žá‚¢—«‚à‰“—¶‚µ‚È‚¢‚Å—V‚Ñ‚Ü‚­‚낤I ‚P‰ñŒÀ‚èA’·ŠúA‰½‚Å‚à‚ ‚èB ô—«‚É—D‚µ‚­‚Å‚«‚é’j«ƒXƒ^ƒbƒt‚à“¯Žž•åW’†ô http://redrival.net/tuuwa/ @«@@@@«@@@@«@@@@«@ http://www.hostingfree.com/datti/enjyo/ @«@@@@«@@@@«@@@@«@ http://www.yentown.net/bbschat-town/sefle/enjyo/ @«@@@@«@@@@«@@@@«@ http://kinyu.www2.dotnetplayground.com/enjyo/ @«@@@@«@@@@«@@@@«@ http://adult.csx.jp/~pool/enjyo/ @«@@@@«@@@@«@@@@«@ http://www.redrival.com/jouhou/enjyo/ @«@@@@«@@@@«@@@@«@ http://www.anzwers.net/hot/hanny/enjyo/ @@@@@@@@@@@@@@@@@@@@@@@@@‹t‰‡•‰ï \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@ƒ}ƒŠƒtƒ@ƒi‚ÌŽí@¡ ƒ}ƒŠƒtƒ@ƒi‚ª‚½‚Ü‚ç‚È‚­D‚«‚ÈlA‚Ç‚¤‚¼A‚±‚±‚ÖB ‚ ‚Ô‚È‚¢‚­‚·‚è‚Ìî•ñ‚àŽè‚É“ü‚é‚æI uâ‘΂Ɉ«—p‚µ‚È‚¢‚Å‚­‚¾‚³‚¢Bv http://fetish.elitecities.com/apple/mari/ @«@@@@«@@@@«@@@@«@ http://www.hostingfree.com/datti/mari/ @«@@@@«@@@@«@@@@«@ http://www.yentown.net/bbschat-town/sefle/mari/ @«@@@@«@@@@«@@@@«@ http://kinyu.www2.dotnetplayground.com/mari/ @«@@@@«@@@@«@@@@«@ http://adult.csx.jp/~pool/mari/ @«@@@@«@@@@«@@@@«@ http://www.redrival.com/jouhou/mari/ @«@@@@«@@@@«@@@@«@ http://www.anzwers.net/hot/hanny/mari/ @@@@@@@@@@@@@@@@@@@@@@@@@X@³’j \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@V‘•ŠJ“XIŒƒˆÀƒZ[ƒ‹@¡ AV.DVDŒƒˆÀƒZ[ƒ‹ ‘¼“X‚Å‚ÍŽè‚É“ü‚ç‚È‚¢‚à‚̂΂©‚µ¥¥¥¥¥¥ ˆÈ‘O‚̂悤‚ÉA‚æ‚낵‚­‚¨Šè‚¢‚µ‚Ü‚·B ‘¼“X‚É•‰‚¯‚¸ŒƒˆÀ—¿‹àI http://fetish.elitecities.com/apple/pink @«@@@@«@@@@«@@@@«@ http://www.hostingfree.com/datti/pink/ @«@@@@«@@@@«@@@@«@ http://www.yentown.net/bbschat-town/sefle/pink/ @«@@@@«@@@@«@@@@«@ http://kinyu.www2.dotnetplayground.com/pink/ @«@@@@«@@@@«@@@@«@ http://adult.csx.jp/~pool/pink/ @«@@@@«@@@@«@@@@«@ http://www.redrival.com/jouhou/pink/ @«@@@@«@@@@«@@@@«@ http://www.anzwers.net/hot/hanny/pink/ @@@@@@@@@@@@@@@@@@@@@@@@@”ü­—ƒNƒ‰ƒu \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ From niv@us.ibm.com Tue Nov 5 14:37:16 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Nov 2002 14:37:18 -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 gA5MbFuR002790 for ; Tue, 5 Nov 2002 14:37:16 -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 gA5McLC3030426; Tue, 5 Nov 2002 17:38:21 -0500 Received: from us.ibm.com (dyn9-47-18-188.beaverton.ibm.com [9.47.18.188]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA5McJlI133872; Tue, 5 Nov 2002 15:38:20 -0700 Message-ID: <3DC84747.67C80B24@us.ibm.com> Date: Tue, 05 Nov 2002 14:33:43 -0800 From: Nivedita Singhvi X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com, linux-net@vger.kernel.org, lksctp-developers@lists.sourceforge.net Subject: Re: sctp snmp mib stats in /proc/net/snmp References: <20021029.091823.121274899.davem@redhat.com> <3DBEC628.75396DA@us.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1089 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 Nivedita Singhvi wrote: > > "David S. Miller" wrote: > > Where will sctp_statistics be defined? If it will be in net/sctp/*.c, > > then you will need to ifdef this ipv4 procfs code on CONFIG_IP_SCTP > > Rats, yes, it is in net/sctp/protocol.c. I'll move it under the ifdef > and make up a complete patch with the dependent code for review > purposes and repost. Thanks for the catch! My apologies for the latency in getting back on this (critical interrupts from other directions).. We're considering a modification to the original proposal, which was to display SCTP SNMP stats in /proc/net/snmp along with the other AF_INET protocols currently being displayed. We're now considering simply displaying the sctp stats structures (snmp and other extended) under the /proc/net/sctp/ subdirectory. This is due to several reasons - one is that the CONFIG_IP_SCTP def isnt enough. SCTP can also be compiled as a module, and may or may not be loaded. We cant make assumptions in net/ipv4/proc.c about whether the sctp_statistics structure is available or not.. Note #if defined (CONFIG_IP_SCTP) || defined (CONFIG_IP_SCTP_MODULE) isnt enough. A clean way to do this would be to have an af_inet top level registration process and have the sctp module register when loaded, as is typical elsewhere. We really dont want to do this at this point, and introduce too many dependencies on directories outside of net/sctp at this time. Secondly, the SCTP MIB is still being formed, and we're probably going to need additions/changes to the spec. In the interim, (or possibly, permanently) we're going to need extended sctp stats which arent in the spec, much like the current linux mib struct which defines a set of extended TCP counters. It would be easier to manage this under the sctp subdirectory altogether. i.e. We diplay the SCTP SNMP and other extended stats as /proc/net/sctp/snmp and /proc/net/sctp/sctp_mib or some such name (which would be somewhat dynamic short term). This would also solve unnecessary duplication for AF_INET6 for us. Any issues, thoughts, suggestions? thanks, Nivedita From davem@redhat.com Tue Nov 5 14:40:38 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Nov 2002 14:40:42 -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 gA5MebuR003853 for ; Tue, 5 Nov 2002 14:40:37 -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 PAA20217; Tue, 5 Nov 2002 15:34:20 -0800 Date: Tue, 05 Nov 2002 15:34:20 -0800 (PST) Message-Id: <20021105.153420.133769117.davem@redhat.com> To: niv@us.ibm.com Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org, lksctp-developers@lists.sourceforge.net Subject: Re: sctp snmp mib stats in /proc/net/snmp From: "David S. Miller" In-Reply-To: <3DC84747.67C80B24@us.ibm.com> References: <20021029.091823.121274899.davem@redhat.com> <3DBEC628.75396DA@us.ibm.com> <3DC84747.67C80B24@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: 1090 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: Nivedita Singhvi Date: Tue, 05 Nov 2002 14:33:43 -0800 It would be easier to manage this under the sctp subdirectory altogether. i.e. We diplay the SCTP SNMP and other extended stats as /proc/net/sctp/snmp and /proc/net/sctp/sctp_mib or some such name (which would be somewhat dynamic short term). This would also solve unnecessary duplication for AF_INET6 for us. I'm fine with this. From greearb@candelatech.com Tue Nov 5 21:58:08 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Nov 2002 21:58:13 -0800 (PST) Received: from grok.yi.org (IDENT:jvejKeVtCk/o1mfq9kDNMCDjKorO5VvJ@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA65w7uR019079 for ; Tue, 5 Nov 2002 21:58:08 -0800 Received: from candelatech.com (IDENT:Ej1b0H0M2+iZ6Fm/3xK7ja+UhtVDFbUz@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id gA65xBq15117 for ; Tue, 5 Nov 2002 22:59:11 -0700 Message-ID: <3DC8AFAF.5070803@candelatech.com> Date: Tue, 05 Nov 2002 21:59:11 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'netdev@oss.sgi.com'" Subject: [PATCH] Send-to-Self patch, against 2.4.20-rc1 Content-Type: multipart/mixed; boundary="------------000507000602040501040901" X-archive-position: 1091 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 This is a multi-part message in MIME format. --------------000507000602040501040901 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Here is the send-to-self patch again. Dave, earlier you had asked to have the same changes applied to ipv6 as ipv4. Turns out, nothing needs to be done to ipv4, so I imagine nothing needs to be done to ipv6 either.... So, are you more interested in the patch now? If not, please tell me what theoretical action on my part would make the patch more palatable! If you just don't like it, let me know so I quit wasting my time. I have cobbled this patch together somewhat manually, trying to break out other network changes in my tree, so it may take a bit of pushing to get it to apply. Thanks, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear --------------000507000602040501040901 Content-Type: text/plain; name="sts_pub_2.4.19.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sts_pub_2.4.19.patch" --- linux-2.4.19/net/core/dev.c Tue Oct 22 22:50:05 2002 +++ linux-2.4.19.p4/net/core/dev.c Tue Oct 22 20:50:01 2002 @@ -2153,7 +2183,25 @@ notifier_call_chain(&netdev_chain, NETDEV_CHANGENAME, dev); return 0; + case SIOCSACCEPTLOCALADDRS: + if (ifr->ifr_flags) { + dev->priv_flags |= IFF_ACCEPT_LOCAL_ADDRS; + } + else { + dev->priv_flags &= ~IFF_ACCEPT_LOCAL_ADDRS; + } + return 0; + + case SIOCGACCEPTLOCALADDRS: + if (dev->priv_flags & IFF_ACCEPT_LOCAL_ADDRS) { + ifr->ifr_flags = 1; + } + else { + ifr->ifr_flags = 0; + } + return 0; + /* * Unknown or private ioctl */ @@ -2249,7 +2307,8 @@ case SIOCGIFMAP: case SIOCGIFINDEX: case SIOCGIFTXQLEN: + case SIOCGACCEPTLOCALADDRS: dev_load(ifr.ifr_name); read_lock(&dev_base_lock); ret = dev_ifsioc(&ifr, cmd); --- linux-2.4.19/include/linux/if.h Thu Nov 22 11:47:07 2001 +++ linux-2.4.19.p4/include/linux/if.h Tue Oct 22 20:54:58 2002 @@ -47,7 +47,13 @@ /* Private (from user) interface flags (netdevice->priv_flags). */ #define IFF_802_1Q_VLAN 0x1 /* 802.1Q VLAN device. */ +#define IFF_PKTGEN_RCV 0x2 /* Registered to receive & consume Pktgen skbs */ +#define IFF_ACCEPT_LOCAL_ADDRS 0x4 /** Accept pkts even if they come from a local + * address. This lets use send pkts to ourselves + * over external interfaces (when used in conjunction + * with SO_BINDTODEVICE + */ /* * Device mapping structure. I'd just gone off and designed a --- linux-2.4.19.p3/include/linux/sockios.h Wed Nov 7 14:39:36 2001 +++ linux-2.4.19.p4/include/linux/sockios.h Tue Nov 5 21:38:41 2002 @@ -65,6 +65,8 @@ #define SIOCDIFADDR 0x8936 /* delete PA address */ #define SIOCSIFHWBROADCAST 0x8937 /* set hardware broadcast addr */ #define SIOCGIFCOUNT 0x8938 /* get number of devices */ +#define SIOCGIFWEIGHT 0x8939 /* get weight of device, in stones */ +#define SIOCSIFWEIGHT 0x893a /* set weight of device, in stones */ #define SIOCGIFBR 0x8940 /* Bridging support */ #define SIOCSIFBR 0x8941 /* Set bridging options */ @@ -114,6 +116,16 @@ #define SIOCBONDINFOQUERY 0x8994 /* rtn info about bond state */ #define SIOCBONDCHANGEACTIVE 0x8995 /* update to a new active slave */ + +/* Ben's little hack land */ +#define SIOCSACCEPTLOCALADDRS 0x89a0 /* Allow interfaces to accept pkts from + * local interfaces...use with SO_BINDTODEVICE + */ +#define SIOCGACCEPTLOCALADDRS 0x89a1 /* Allow interfaces to accept pkts from + * local interfaces...use with SO_BINDTODEVICE + */ + + /* Device private ioctl calls */ /* --- linux-2.4.19.p3/net/ipv4/arp.c Tue Nov 5 21:33:43 2002 +++ linux-2.4.19.p4/net/ipv4/arp.c Tue Nov 5 21:38:41 2002 @@ -1,4 +1,4 @@ -/* linux/net/inet/arp.c +/* linux/net/inet/arp.c -*-linux-c-*- * * Version: $Id: arp.c,v 1.99 2001/08/30 22:55:42 davem Exp $ * @@ -351,12 +351,22 @@ int flag = 0; /*unsigned long now; */ - if (ip_route_output(&rt, sip, tip, 0, 0) < 0) + if (ip_route_output(&rt, sip, tip, 0, 0) < 0) return 1; - if (rt->u.dst.dev != dev) { - NET_INC_STATS_BH(ArpFilter); - flag = 1; - } + + if (rt->u.dst.dev != dev) { + if ((dev->priv_flags & IFF_ACCEPT_LOCAL_ADDRS) && + (rt->u.dst.dev == &loopback_dev)) { + /* OK, we'll let this special case slide, so that we can arp from one + * local interface to another. This seems to work, but could use some + * review. --Ben + */ + } + else { + NET_INC_STATS_BH(ArpFilter); + flag = 1; + } + } ip_rt_put(rt); return flag; } --- linux-2.4.19.p3/net/ipv4/fib_frontend.c Fri Aug 2 17:39:46 2002 +++ linux-2.4.19.p4/net/ipv4/fib_frontend.c Tue Nov 5 21:38:41 2002 @@ -233,8 +233,17 @@ if (fib_lookup(&key, &res)) goto last_resort; - if (res.type != RTN_UNICAST) - goto e_inval_res; + + if (res.type != RTN_UNICAST) { + if ((res.type == RTN_LOCAL) && + (dev->priv_flags & IFF_ACCEPT_LOCAL_ADDRS)) { + /* All is OK */ + } + else { + goto e_inval_res; + } + } + *spec_dst = FIB_RES_PREFSRC(res); fib_combine_itag(itag, &res); #ifdef CONFIG_IP_ROUTE_MULTIPATH --- linux-2.4.19.p3/net/ipv4/tcp_ipv4.c Tue Nov 5 21:33:46 2002 +++ linux-2.4.19.p4/net/ipv4/tcp_ipv4.c Tue Nov 5 21:38:41 2002 @@ -1394,7 +1394,7 @@ #define want_cookie 0 /* Argh, why doesn't gcc optimize this :( */ #endif - /* Never answer to SYNs send to broadcast or multicast */ + /* Never answer to SYNs sent to broadcast or multicast */ if (((struct rtable *)skb->dst)->rt_flags & (RTCF_BROADCAST|RTCF_MULTICAST)) goto drop; --------------000507000602040501040901-- From greearb@candelatech.com Tue Nov 5 22:35:06 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Nov 2002 22:35:08 -0800 (PST) Received: from grok.yi.org (IDENT:HsW/cOfoSTDWbdFUOyjXHgW89OePZATo@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA66Z5uR019706 for ; Tue, 5 Nov 2002 22:35:06 -0800 Received: from candelatech.com (IDENT:tEJUnmQtfWa1rwF68FqKsHF0lcCXe+NC@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id gA66aBq19588; Tue, 5 Nov 2002 23:36:11 -0700 Message-ID: <3DC8B85B.5050805@candelatech.com> Date: Tue, 05 Nov 2002 22:36:11 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'netdev@oss.sgi.com'" , Jeff Garzik Subject: NAPI-ized tulip patch against 2.4.20-rc1 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1092 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 Here is a patch that makes Tulip support NAPI. The vast bulk of these changes come from Robert Olsson's ftp site, I just pieced them together. It works good on my 4-port Tulip NICs, better than the default driver at least (no, I never tried the old HW-Mitigation option). This patch will also make use of Robert's skb-recycle patch if it's been applied, but through #ifdef magic, it should also work w/out that.... Enjoy, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From greearb@candelatech.com Tue Nov 5 22:41:18 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Nov 2002 22:41:26 -0800 (PST) Received: from grok.yi.org (IDENT:tilL5fUzXI+4umqo59YlygV8K1IXsNtq@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA66fGuR020103 for ; Tue, 5 Nov 2002 22:41:16 -0800 Received: from candelatech.com (IDENT:h4HPSp4RTWZ6B4Syj5aKA7HbTLCC6T6L@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id gA66gNq20359; Tue, 5 Nov 2002 23:42:23 -0700 Message-ID: <3DC8B9CF.6050500@candelatech.com> Date: Tue, 05 Nov 2002 22:42:23 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'netdev@oss.sgi.com'" CC: Jeff Garzik Subject: Re: NAPI-ized tulip patch against 2.4.20-rc1 References: <3DC8B85B.5050805@candelatech.com> Content-Type: multipart/mixed; boundary="------------020408050605010005000705" X-archive-position: 1093 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 This is a multi-part message in MIME format. --------------020408050605010005000705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ben Greear wrote: > Here is a patch that makes Tulip support NAPI. The vast bulk of these Blech...I actually attached it this time... -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear --------------020408050605010005000705 Content-Type: text/plain; name="tulip_2.4.19.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tulip_2.4.19.patch" --- linux-2.4.19.p3/drivers/net/tulip/interrupt.c Wed Oct 9 00:23:43 2002 +++ linux-2.4.19.p4/drivers/net/tulip/interrupt.c Tue Oct 22 23:19:53 2002 @@ -1,4 +1,4 @@ -/* +/* -*-linux-c-*- drivers/net/tulip/interrupt.c Maintained by Jeff Garzik @@ -23,9 +23,14 @@ int tulip_rx_copybreak; unsigned int tulip_max_interrupt_work; -#ifdef CONFIG_NET_HW_FLOWCONTROL +#ifdef CONFIG_NET_SKB_RECYCLING +int tulip_recycle(struct sk_buff *skb); +#endif +#ifdef USE_MITIGATION #define MIT_SIZE 15 +#define MIT_TABLE 15 /* We use 0 or max */ + unsigned int mit_table[MIT_SIZE+1] = { /* CRS11 21143 hardware Mitigation Control Interrupt @@ -99,16 +104,28 @@ return refilled; } +void oom_timer(unsigned long data) +{ + struct net_device *dev = (struct net_device *)data; + netif_rx_schedule(dev); +} + -static int tulip_rx(struct net_device *dev) +int tulip_poll(struct net_device *dev, int *budget) { struct tulip_private *tp = (struct tulip_private *)dev->priv; int entry = tp->cur_rx % RX_RING_SIZE; - int rx_work_limit = tp->dirty_rx + RX_RING_SIZE - tp->cur_rx; + int rx_work_limit = *budget; int received = 0; -#ifdef CONFIG_NET_HW_FLOWCONTROL - int drop = 0, mit_sel = 0; +#ifdef EXTRA_STATS + tp->stats_poll_starts++; +#endif + + if (rx_work_limit > dev->quota) + rx_work_limit = dev->quota; + +#ifdef USE_MITIGATION /* that one buffer is needed for mit activation; or might be a bug in the ring buffer code; check later -- JHS*/ @@ -118,177 +135,266 @@ if (tulip_debug > 4) printk(KERN_DEBUG " In tulip_rx(), entry %d %8.8x.\n", entry, - tp->rx_ring[entry].status); - /* If we own the next entry, it is a new packet. Send it up. */ - while ( ! (tp->rx_ring[entry].status & cpu_to_le32(DescOwned))) { - s32 status = le32_to_cpu(tp->rx_ring[entry].status); - - if (tulip_debug > 5) - printk(KERN_DEBUG "%s: In tulip_rx(), entry %d %8.8x.\n", - dev->name, entry, status); - if (--rx_work_limit < 0) - break; - if ((status & 0x38008300) != 0x0300) { - if ((status & 0x38000300) != 0x0300) { - /* Ingore earlier buffers. */ - if ((status & 0xffff) != 0x7fff) { - if (tulip_debug > 1) - printk(KERN_WARNING "%s: Oversized Ethernet frame " - "spanned multiple buffers, status %8.8x!\n", - dev->name, status); - tp->stats.rx_length_errors++; - } - } else if (status & RxDescFatalErr) { + tp->rx_ring[entry].status); + + + do { + /* Acknowledge current RX interrupt sources. */ + outl((RxIntr | RxNoBuf), dev->base_addr + CSR5); + + + /* If we own the next entry, it is a new packet. Send it up. */ + while ( ! (tp->rx_ring[entry].status & cpu_to_le32(DescOwned))) { + s32 status = le32_to_cpu(tp->rx_ring[entry].status); + + + if (tp->dirty_rx + RX_RING_SIZE == tp->cur_rx) + break; + + if (tulip_debug > 5) + printk(KERN_DEBUG "%s: In tulip_rx(), entry %d %8.8x.\n", + dev->name, entry, status); + if (--rx_work_limit < 0) + goto not_done; + + if ((status & 0x38008300) != 0x0300) { + if ((status & 0x38000300) != 0x0300) { + /* Ignore earlier buffers. */ + if ((status & 0xffff) != 0x7fff) { + if (tulip_debug > 1) + printk(KERN_WARNING "%s: Oversized Ethernet frame " + "spanned multiple buffers, status %8.8x!\n", + dev->name, status); + tp->stats.rx_length_errors++; + } + } else if (status & RxDescFatalErr) { /* There was a fatal error. */ - if (tulip_debug > 2) - printk(KERN_DEBUG "%s: Receive error, Rx status %8.8x.\n", - dev->name, status); - tp->stats.rx_errors++; /* end of a packet.*/ - if (status & 0x0890) tp->stats.rx_length_errors++; - if (status & 0x0004) tp->stats.rx_frame_errors++; - if (status & 0x0002) tp->stats.rx_crc_errors++; - if (status & 0x0001) tp->stats.rx_fifo_errors++; - } - } else { - /* Omit the four octet CRC from the length. */ - short pkt_len = ((status >> 16) & 0x7ff) - 4; - struct sk_buff *skb; + if (tulip_debug > 2) + printk(KERN_DEBUG "%s: Receive error, Rx status %8.8x.\n", + dev->name, status); + tp->stats.rx_errors++; /* end of a packet.*/ + if (status & 0x0890) tp->stats.rx_length_errors++; + if (status & 0x0004) tp->stats.rx_frame_errors++; + if (status & 0x0002) tp->stats.rx_crc_errors++; + if (status & 0x0001) tp->stats.rx_fifo_errors++; + } + } else { + /* Omit the four octet CRC from the length. */ + short pkt_len = ((status >> 16) & 0x7ff) - 4; + struct sk_buff *skb = NULL; #ifndef final_version - if (pkt_len > 1518) { - printk(KERN_WARNING "%s: Bogus packet size of %d (%#x).\n", - dev->name, pkt_len, pkt_len); - pkt_len = 1518; - tp->stats.rx_length_errors++; - } + if (pkt_len > 1518) { + printk(KERN_WARNING "%s: Bogus packet size of %d (%#x).\n", + dev->name, pkt_len, pkt_len); + pkt_len = 1518; + tp->stats.rx_length_errors++; + } #endif -#ifdef CONFIG_NET_HW_FLOWCONTROL - drop = atomic_read(&netdev_dropping); - if (drop) - goto throttle; -#endif - /* Check if the packet is long enough to accept without copying - to a minimally-sized skbuff. */ - if (pkt_len < tulip_rx_copybreak - && (skb = dev_alloc_skb(pkt_len + 2)) != NULL) { - skb->dev = dev; - skb_reserve(skb, 2); /* 16 byte align the IP header */ - pci_dma_sync_single(tp->pdev, - tp->rx_buffers[entry].mapping, - pkt_len, PCI_DMA_FROMDEVICE); + /* Check if the packet is long enough to accept without copying + to a minimally-sized skbuff. */ +#ifdef CONFIG_NET_SKB_RECYCLING + if (pkt_len < tulip_rx_copybreak) { + /* Allocate an skb from our private queue if possible */ + skb = skb_dequeue(&(tp->tulip_recycle[smp_processor_id()].list)); + if (skb) { + skb_headerinit(skb, NULL, 0); /* clean state */ + + skb->data = skb->head; + skb->tail = skb->head; + skb->len = 0; + } + } +#endif + if ((pkt_len < tulip_rx_copybreak) + && ((skb != NULL) + || ((skb = dev_alloc_skb(pkt_len + 2)) != NULL))) { + skb->dev = dev; + skb_reserve(skb, 2); /* 16 byte align the IP header */ + pci_dma_sync_single(tp->pdev, + tp->rx_buffers[entry].mapping, + pkt_len, PCI_DMA_FROMDEVICE); #if ! defined(__alpha__) - eth_copy_and_sum(skb, tp->rx_buffers[entry].skb->tail, - pkt_len, 0); - skb_put(skb, pkt_len); + eth_copy_and_sum(skb, tp->rx_buffers[entry].skb->tail, + pkt_len, 0); + skb_put(skb, pkt_len); #else - memcpy(skb_put(skb, pkt_len), - tp->rx_buffers[entry].skb->tail, - pkt_len); -#endif - } else { /* Pass up the skb already on the Rx ring. */ - char *temp = skb_put(skb = tp->rx_buffers[entry].skb, - pkt_len); + memcpy(skb_put(skb, pkt_len), + tp->rx_buffers[entry].skb->tail, + pkt_len); +#endif +#ifdef CONFIG_NET_SKB_RECYCLING + skb->tag = smp_processor_id(); + tp->cnt[skb->tag]++; + skb->recycle_dev = dev; + skb->recycle_dev->skb_recycle = tulip_recycle; +#endif + } else { /* Pass up the skb already on the Rx ring. */ + char *temp = skb_put(skb = tp->rx_buffers[entry].skb, + pkt_len); #ifndef final_version - if (tp->rx_buffers[entry].mapping != - le32_to_cpu(tp->rx_ring[entry].buffer1)) { - printk(KERN_ERR "%s: Internal fault: The skbuff addresses " - "do not match in tulip_rx: %08x vs. %08x %p / %p.\n", - dev->name, - le32_to_cpu(tp->rx_ring[entry].buffer1), - tp->rx_buffers[entry].mapping, - skb->head, temp); - } + if (tp->rx_buffers[entry].mapping != + le32_to_cpu(tp->rx_ring[entry].buffer1)) { + printk(KERN_ERR "%s: Internal fault: The skbuff addresses " + "do not match in tulip_rx: %08x vs. %08x %p / %p.\n", + dev->name, + le32_to_cpu(tp->rx_ring[entry].buffer1), + tp->rx_buffers[entry].mapping, + skb->head, temp); + } #endif - pci_unmap_single(tp->pdev, tp->rx_buffers[entry].mapping, - PKT_BUF_SZ, PCI_DMA_FROMDEVICE); + pci_unmap_single(tp->pdev, tp->rx_buffers[entry].mapping, + PKT_BUF_SZ, PCI_DMA_FROMDEVICE); - tp->rx_buffers[entry].skb = NULL; - tp->rx_buffers[entry].mapping = 0; - } - skb->protocol = eth_type_trans(skb, dev); -#ifdef CONFIG_NET_HW_FLOWCONTROL - mit_sel = -#endif - netif_rx(skb); - -#ifdef CONFIG_NET_HW_FLOWCONTROL - switch (mit_sel) { - case NET_RX_SUCCESS: - case NET_RX_CN_LOW: - case NET_RX_CN_MOD: - break; - - case NET_RX_CN_HIGH: - rx_work_limit -= NET_RX_CN_HIGH; /* additional*/ - break; - case NET_RX_DROP: - rx_work_limit = -1; - break; - default: - printk("unknown feedback return code %d\n", mit_sel); - break; - } + tp->rx_buffers[entry].skb = NULL; + tp->rx_buffers[entry].mapping = 0; + } + skb->protocol = eth_type_trans(skb, dev); - drop = atomic_read(&netdev_dropping); - if (drop) { -throttle: - rx_work_limit = -1; - mit_sel = NET_RX_DROP; - - if (tp->fc_bit) { - long ioaddr = dev->base_addr; - - /* disable Rx & RxNoBuf ints. */ - outl(tulip_tbl[tp->chip_id].valid_intrs&RX_A_NBF_STOP, ioaddr + CSR7); - set_bit(tp->fc_bit, &netdev_fc_xoff); - } - } + netif_receive_skb(skb); + + dev->last_rx = jiffies; + tp->stats.rx_packets++; + tp->stats.rx_bytes += pkt_len; + } + received++; +#ifdef EXTRA_STATS + tp->stats_poll_pkts++; +#ifdef USE_MITIGATION + if(tp->mit_on) tp->stats_poll_pkts_mit++; +#endif #endif - dev->last_rx = jiffies; - tp->stats.rx_packets++; - tp->stats.rx_bytes += pkt_len; + entry = (++tp->cur_rx) % RX_RING_SIZE; + if (tp->cur_rx - tp->dirty_rx > RX_RING_SIZE/4) + tulip_refill_rx(dev); + } - received++; - entry = (++tp->cur_rx) % RX_RING_SIZE; - } -#ifdef CONFIG_NET_HW_FLOWCONTROL + + /* New ack strategy... irq does not ack Rx any longer + hopefully this helps */ + + /* Really bad things can happen here... If new packet arrives + * and an irq arrives (tx or just due to occasionally unset + * mask), it will be acked by irq handler, but new thread + * is not scheduled. It is major hole in design. + * No idea how to fix this if "playing with fire" will fail + * tomorrow (night 011029). If it will not fail, we won + * finally: amount of IO did not increase at all. */ + } while ((inl(dev->base_addr + CSR5) & RxIntr)); + +/* done: */ + +#ifdef USE_MITIGATION /* We use this simplistic scheme for IM. It's proven by real life installations. We can have IM enabled - continuesly but this would cause unnecessary latency. - Unfortunely we can't use all the NET_RX_* feedback here. - This would turn on IM for devices that is not contributing - to backlog congestion with unnecessary latency. + continuesly but this would cause unnecessary latency. + Unfortunely we can't use all the NET_RX_* feedback here. + This would turn on IM for devices that is not contributing + to backlog congestion with unnecessary latency. We monitor the the device RX-ring and have: HW Interrupt Mitigation either ON or OFF. - ON: More then 1 pkt received (per intr.) OR we are dropping + ON: More then 1 pkt received (per intr.) OR we are dropping OFF: Only 1 pkt received - + Note. We only use min and max (0, 15) settings from mit_table */ if( tp->flags & HAS_INTR_MITIGATION) { - if((received > 1 || mit_sel == NET_RX_DROP) - && tp->mit_sel != 15 ) { - tp->mit_sel = 15; - tp->mit_change = 1; /* Force IM change */ + if( received > 1 ) { + if( ! tp->mit_on ) { + tp->mit_on = 1; + outl(mit_table[MIT_TABLE], dev->base_addr + CSR11); + } } - if((received <= 1 && mit_sel != NET_RX_DROP) && tp->mit_sel != 0 ) { - tp->mit_sel = 0; - tp->mit_change = 1; /* Force IM change */ + else { + if( tp->mit_on ) { + tp->mit_on = 0; + outl(0, dev->base_addr + CSR11); + } } } - return RX_RING_SIZE+1; /* maxrx+1 */ -#else - return received; #endif + + dev->quota -= received; + *budget -= received; + + tulip_refill_rx(dev); + + /* If RX ring is not full we are out of memory. */ + if (tp->rx_buffers[tp->dirty_rx % RX_RING_SIZE].skb == NULL) goto oom; + +#ifdef EXTRA_STATS + if((inl(dev->base_addr + CSR5) & RxIntr)) tp->stats_poll_exit_done_rx_pending++; + tp->stats_poll_exit_done++; +#endif + + /* Remove us from polling list and enable RX intr. */ + + netif_rx_complete(dev); + outl(tulip_tbl[tp->chip_id].valid_intrs, dev->base_addr+CSR7); + + /* The last op happens after poll completion. Which means the following: + * 1. it can race with disabling irqs in irq handler + * 2. it can race with dise/enabling irqs in other poll threads + * 3. if an irq raised after beginning loop, it will be immediately + * triggered here. + * + * Summarizing: the logic results in some redundant irqs both + * due to races in masking and due to too late acking of already + * processed irqs. But it must not result in losing events. + */ + + return 0; + +not_done: + if (!received) { +#ifdef EXTRA_STATS + tp->stats_poll_zero_rx++; +#endif + /* received = dev->quota; Why existed? --Ben */ /* Not to happen */ + } + else { + dev->quota -= received; + *budget -= received; + } + + if (tp->cur_rx - tp->dirty_rx > RX_RING_SIZE/2 || + tp->rx_buffers[tp->dirty_rx % RX_RING_SIZE].skb == NULL) + tulip_refill_rx(dev); + + if (tp->rx_buffers[tp->dirty_rx % RX_RING_SIZE].skb == NULL) goto oom; + +#ifdef EXTRA_STATS + tp->stats_poll_exit_not_done++; +#endif + return 1; + + +oom: /* Executed with RX ints disabled */ + printk("ERROR: tulip: Hit OOM trying to refill rx buffer.\n"); + + /* Start timer, stop polling, but do not enable rx interrupts. */ + mod_timer(&tp->oom_timer, jiffies+1); + + /* Think: timer_pending() was an explicit signature of bug. + * Timer can be pending now but fired and completed + * before we did netif_rx_complete(). See? We would lose it. */ + + /* remove ourselves from the polling list */ + netif_rx_complete(dev); + +#ifdef EXTRA_STATS + tp->stats_poll_exit_oom++; +#endif + return 0; } static inline void phy_interrupt (struct net_device *dev) @@ -319,7 +425,6 @@ struct tulip_private *tp = (struct tulip_private *)dev->priv; long ioaddr = dev->base_addr; int csr5; - int entry; int missed; int rx = 0; int tx = 0; @@ -327,6 +432,7 @@ int maxrx = RX_RING_SIZE; int maxtx = TX_RING_SIZE; int maxoi = TX_RING_SIZE; + int rxd = 0; unsigned int work_count = tulip_max_interrupt_work; /* Let's see whether the interrupt really is for us */ @@ -341,21 +447,32 @@ tp->nir++; do { - /* Acknowledge all of the current interrupt sources ASAP. */ - outl(csr5 & 0x0001ffff, ioaddr + CSR5); +#ifdef EXTRA_STATS + if(!rxd) + record_interrupt_cause(dev, csr5); + else + record_interrupt_cause(dev, csr5& 0x0001ff3f); +#endif + if (!rxd && (csr5 & (RxIntr | RxNoBuf))) { + rxd++; + /* Mask RX intrs and add the device to poll list. */ + outl(tulip_tbl[tp->chip_id].valid_intrs&~RxPollInt, ioaddr + CSR7); + netif_rx_schedule(dev); + + if (!(csr5&~(AbnormalIntr|NormalIntr|RxPollInt|TPLnkPass))) + break; + } + + /* Acknowledge the interrupt sources we handle here ASAP + the poll function does Rx and RxNoBuf acking */ + + outl(csr5 & 0x0001ff3f, ioaddr + CSR5); + if (tulip_debug > 4) printk(KERN_DEBUG "%s: interrupt csr5=%#8.8x new csr5=%#8.8x.\n", - dev->name, csr5, inl(dev->base_addr + CSR5)); - - if (csr5 & (RxIntr | RxNoBuf)) { -#ifdef CONFIG_NET_HW_FLOWCONTROL - if ((!tp->fc_bit) || - (!test_bit(tp->fc_bit, &netdev_fc_xoff))) -#endif - rx += tulip_rx(dev); - tulip_refill_rx(dev); - } + dev->name, csr5, inl(dev->base_addr + CSR5)); + if (csr5 & (TxNoBuf | TxDied | TxIntr | TimerInt)) { unsigned int dirty_tx; @@ -457,15 +574,8 @@ } if (csr5 & RxDied) { /* Missed a Rx frame. */ tp->stats.rx_missed_errors += inl(ioaddr + CSR8) & 0xffff; -#ifdef CONFIG_NET_HW_FLOWCONTROL - if (tp->fc_bit && !test_bit(tp->fc_bit, &netdev_fc_xoff)) { - tp->stats.rx_errors++; - tulip_start_rxtx(tp); - } -#else tp->stats.rx_errors++; tulip_start_rxtx(tp); -#endif } /* * NB: t21142_lnk_change() does a del_timer_sync(), so be careful if this @@ -499,10 +609,6 @@ if (tulip_debug > 2) printk(KERN_ERR "%s: Re-enabling interrupts, %8.8x.\n", dev->name, csr5); -#ifdef CONFIG_NET_HW_FLOWCONTROL - if (tp->fc_bit && (test_bit(tp->fc_bit, &netdev_fc_xoff))) - if (net_ratelimit()) printk("BUG!! enabling interupt when FC off (timerintr.) \n"); -#endif outl(tulip_tbl[tp->chip_id].valid_intrs, ioaddr + CSR7); tp->ttimer = 0; oi++; @@ -515,11 +621,8 @@ /* Acknowledge all interrupt sources. */ outl(0x8001ffff, ioaddr + CSR5); if (tp->flags & HAS_INTR_MITIGATION) { -#ifdef CONFIG_NET_HW_FLOWCONTROL - if(tp->mit_change) { - outl(mit_table[tp->mit_sel], ioaddr + CSR11); - tp->mit_change = 0; - } +#ifdef USE_MITIGATION + outl(mit_table[MIT_TABLE], ioaddr + CSR11); #else /* Josip Loncaric at ICASE did extensive experimentation to develop a good interrupt mitigation setting.*/ @@ -532,10 +635,8 @@ } else { /* Mask all interrupting sources, set timer to re-enable. */ -#ifndef CONFIG_NET_HW_FLOWCONTROL outl(((~csr5) & 0x0001ebef) | AbnormalIntr | TimerInt, ioaddr + CSR7); outl(0x0012, ioaddr + CSR11); -#endif } break; } @@ -545,30 +646,18 @@ break; csr5 = inl(ioaddr + CSR5); - } while ((csr5 & (NormalIntr|AbnormalIntr)) != 0); - - tulip_refill_rx(dev); - - /* check if the card is in suspend mode */ - entry = tp->dirty_rx % RX_RING_SIZE; - if (tp->rx_buffers[entry].skb == NULL) { - if (tulip_debug > 1) - printk(KERN_WARNING "%s: in rx suspend mode: (%lu) (tp->cur_rx = %u, ttimer = %d, rx = %d) go/stay in suspend mode\n", dev->name, tp->nir, tp->cur_rx, tp->ttimer, rx); - if (tp->chip_id == LC82C168) { - outl(0x00, ioaddr + CSR7); - mod_timer(&tp->timer, RUN_AT(HZ/50)); - } else { - if (tp->ttimer == 0 || (inl(ioaddr + CSR11) & 0xffff) == 0) { - if (tulip_debug > 1) - printk(KERN_WARNING "%s: in rx suspend mode: (%lu) set timer\n", dev->name, tp->nir); - outl(tulip_tbl[tp->chip_id].valid_intrs | TimerInt, - ioaddr + CSR7); - outl(TimerInt, ioaddr + CSR5); - outl(12, ioaddr + CSR11); - tp->ttimer = 1; - } - } - } + if (rxd) + csr5 &= ~RxPollInt; + } while ((csr5 & (TxNoBuf | + TxDied | + TxIntr | + TimerInt | + /* Abnormal intr. */ + RxDied | + TxFIFOUnderflow | + TxJabber | + TPLnkFail | + SytemError )) != 0); if ((missed = inl(ioaddr + CSR8) & 0x1ffff)) { tp->stats.rx_dropped += missed & 0x10000 ? 0x10000 : missed; --- linux-2.4.19.p3/drivers/net/tulip/tulip_core.c Wed Oct 9 00:23:43 2002 +++ linux-2.4.19.p4/drivers/net/tulip/tulip_core.c Tue Oct 22 23:20:37 2002 @@ -1,4 +1,4 @@ -/* tulip_core.c: A DEC 21x4x-family ethernet driver for Linux. */ +/* -*-linux-c-*- tulip_core.c: A DEC 21x4x-family ethernet driver for Linux. */ /* Maintained by Jeff Garzik @@ -14,10 +14,6 @@ */ -#define DRV_NAME "tulip" -#define DRV_VERSION "0.9.15-pre12" -#define DRV_RELDATE "Aug 9, 2002" - #include #include #include "tulip.h" @@ -44,7 +40,7 @@ /* Maximum events (Rx packets, etc.) to handle at each interrupt. */ static unsigned int max_interrupt_work = 25; -#define MAX_UNITS 8 +#define MAX_UNITS 16 /* Used to pass the full-duplex flag, etc. */ static int full_duplex[MAX_UNITS]; static int options[MAX_UNITS]; @@ -105,6 +101,19 @@ /* Time in jiffies before concluding the transmitter is hung. */ #define TX_TIMEOUT (4*HZ) +#ifdef CONFIG_NET_SKB_RECYCLING +/* This is the maximum number of skbs per CPU that the driver will + * keep in it's recycle buffer list (per driver instance, ie per port). + * Each skb will cost you a little + * less than 2k, so if you have little memory and make this huge, bad + * things will happen. For 256MB machines running at very high speeds, + * 1024 or 2048 may be better. There seems to be no gain at higher + * values, at least on 100Mbps nics. + */ +static int skb_hotlist = 300; + +MODULE_PARM(skb_hotlist, "i"); +#endif MODULE_AUTHOR("The Linux Kernel Team"); MODULE_DESCRIPTION("Digital 21*4* Tulip ethernet driver"); @@ -493,29 +502,16 @@ to an alternate media type. */ tp->timer.expires = RUN_AT(next_tick); add_timer(&tp->timer); -} - -#ifdef CONFIG_NET_HW_FLOWCONTROL -/* Enable receiver */ -void tulip_xon(struct net_device *dev) -{ - struct tulip_private *tp = (struct tulip_private *)dev->priv; - - clear_bit(tp->fc_bit, &netdev_fc_xoff); - if (netif_running(dev)){ - tulip_refill_rx(dev); - outl(tulip_tbl[tp->chip_id].valid_intrs, dev->base_addr+CSR7); - } + init_timer(&tp->oom_timer); + tp->oom_timer.data = (unsigned long)dev; + tp->oom_timer.function = oom_timer; } -#endif + static int tulip_open(struct net_device *dev) { -#ifdef CONFIG_NET_HW_FLOWCONTROL - struct tulip_private *tp = (struct tulip_private *)dev->priv; -#endif int retval; MOD_INC_USE_COUNT; @@ -524,14 +520,23 @@ return retval; } - tulip_init_ring (dev); +#ifdef CONFIG_NET_SKB_RECYCLING + { + int i; + struct tulip_private *adapter = dev->priv; + for (i=0; itulip_recycle[i].list); + } + } +#endif + tulip_init_ring (dev); + tulip_up (dev); -#ifdef CONFIG_NET_HW_FLOWCONTROL - tp->fc_bit = netdev_register_fc(dev, tulip_xon); -#endif - +#ifdef EXTRA_STATS + tulip_open_misc(dev); +#endif netif_start_queue (dev); return 0; @@ -639,10 +644,7 @@ #endif /* Stop and restart the chip's Tx processes . */ -#ifdef CONFIG_NET_HW_FLOWCONTROL - if (tp->fc_bit && test_bit(tp->fc_bit,&netdev_fc_xoff)) - printk("BUG tx_timeout restarting rx when fc on\n"); -#endif + tulip_restart_rxtx(tp); /* Trigger an immediate transmit demand. */ outl(0, ioaddr + CSR1); @@ -718,6 +720,16 @@ spin_lock_irqsave(&tp->lock, eflags); + /* See if we can free slots on the output ring. In real life + examples we have seen between 2-10% of the slots cleared here */ + +#ifdef NOT_NOW +#ifdef EXTRA_STATS + tp->stats_tx_xmit_refilled += +#endif + tx_ring_free(dev); +#endif + /* Calculate the next Tx descriptor entry. */ entry = tp->cur_tx % TX_RING_SIZE; @@ -801,6 +813,7 @@ unsigned long flags; del_timer_sync (&tp->timer); + del_timer_sync (&tp->oom_timer); spin_lock_irqsave (&tp->lock, flags); @@ -844,15 +857,31 @@ netif_stop_queue (dev); -#ifdef CONFIG_NET_HW_FLOWCONTROL - if (tp->fc_bit) { - int bit = tp->fc_bit; - tp->fc_bit = 0; - netdev_unregister_fc(bit); - } +#ifdef tEXTRA_STATS + tulip_close_misc(dev); #endif tulip_down (dev); + /* Schedule while outstanding skb's exists */ + +#ifdef CONFIG_NET_SKB_RECYCLING + for (i=0; icnt[i]) { + current->state = TASK_INTERRUPTIBLE; + schedule_timeout(1); + } + } + + for (i=0; itulip_recycle[i].list; + while ((skb=skb_dequeue(list))!=NULL) { + skb->recycle_dev = NULL; + kfree_skb(skb); + } + } +#endif + if (tulip_debug > 1) printk (KERN_DEBUG "%s: Shutting down ethercard, status was %2.2x.\n", dev->name, inl (ioaddr + CSR5)); @@ -1716,6 +1745,8 @@ dev->hard_start_xmit = tulip_start_xmit; dev->tx_timeout = tulip_tx_timeout; dev->watchdog_timeo = TX_TIMEOUT; + dev->poll = tulip_poll; + dev->weight = 64; dev->stop = tulip_close; dev->get_stats = tulip_get_stats; dev->do_ioctl = private_ioctl; @@ -1810,6 +1841,9 @@ /* put the chip in snooze mode until opened */ tulip_set_power_state (tp, 0, 1); +#ifdef EXTRA_STATS + tulip_init_one_misc(dev); +#endif return 0; err_out_free_ring: @@ -1875,6 +1909,10 @@ if (!dev) return; +#ifdef EXTRA_STATS + tulip_remove_one_misc(dev); +#endif + tp = dev->priv; pci_free_consistent (pdev, sizeof (struct tulip_rx_desc) * RX_RING_SIZE + @@ -1894,6 +1932,36 @@ } + + +#ifdef CONFIG_NET_SKB_RECYCLING + +int tulip_recycle(struct sk_buff *skb) +{ + struct tulip_private *adapter = skb->recycle_dev->priv; + + /* Store for right CPU. For this we use skb->tag */ + struct sk_buff_head *list = &adapter->tulip_recycle[skb->tag].list; + + /* + decrease our outstanding skb's: + 1) either we store in the list OR + 2) we ignore so gets to kfree + */ + + adapter->cnt[smp_processor_id()]--; + + if (skb_queue_len(list) <= skb_hotlist) { + + /* LIFO queue for cache friendliness */ + skb_queue_head(list, skb); + return 1; + } + return 0; +} +#endif + + static struct pci_driver tulip_driver = { name: DRV_NAME, id_table: tulip_pci_tbl, --- linux-2.4.19.p3/drivers/net/tulip/tulip.h Tue Oct 15 14:38:31 2002 +++ linux-2.4.19.p4/drivers/net/tulip/tulip.h Tue Oct 22 21:06:10 2002 @@ -16,6 +16,11 @@ #ifndef __NET_TULIP_H__ #define __NET_TULIP_H__ +#define DRV_NAME "tulip" +#define DRV_VERSION "1.1.1-NAPI" +#define DRV_RELDATE "Feb 16, 2002" + + #include #include #include @@ -26,7 +31,12 @@ #include #include +#ifdef CONFIG_PROC_FS +#include +#endif +/* #define EXTRA_STATS 1 */ +#undef USE_MITIGATION /* undefine, or define to various debugging levels (>4 == obscene levels) */ #define TULIP_DEBUG 1 @@ -126,6 +136,7 @@ CFDD_Snooze = (1 << 30), }; +#define RxPollInt (RxIntr|RxNoBuf|RxDied|RxJabber) /* The bits in the CSR5 status registers, mostly interrupt sources. */ enum status_bits { @@ -261,8 +272,8 @@ Making the Tx ring too large decreases the effectiveness of channel bonding and packet priority. There are no ill effects from too-large receive rings. */ -#define TX_RING_SIZE 16 -#define RX_RING_SIZE 32 +#define TX_RING_SIZE 128 +#define RX_RING_SIZE 1024 #define MEDIA_MASK 31 @@ -351,8 +362,45 @@ int chip_id; int revision; int flags; + int mit_on; struct net_device_stats stats; +#ifdef EXTRA_STATS + unsigned long stats_tx_xmit_refilled; /* Pkts xmit-filled */ + unsigned long stats_tx_irq_refilled; /* Pktss irq-filled*/ + unsigned long stats_poll_starts; + unsigned long stats_poll_pkts; +#ifdef USE_MITIGATION + unsigned long stats_poll_pkts_mit; +#endif + unsigned long stats_poll_exit_done; + unsigned long stats_poll_exit_not_done; + unsigned long stats_poll_exit_oom; + unsigned long stats_poll_exit_done_rx_pending; + unsigned long stats_poll_zero_rx; +#ifdef CONFIG_PROC_FS + struct proc_dir_entry *proc_ent; + char proc_ent_name[32]; +#endif + /*Tulip interrupts causes */ + unsigned long stats_intr_normal; + unsigned long stats_intr_abnormal; + unsigned long stats_intr_timer; + + unsigned long stats_intr_rx; + unsigned long stats_intr_rx_nobuf; + unsigned long stats_intr_rx_died; + unsigned long stats_intr_rx_jabber; + + unsigned long stats_intr_tx; + unsigned long stats_intr_tx_died; + unsigned long stats_intr_tx_nobuf; + unsigned long rx_small_skb_failure; + unsigned long stats_intr_TPLnkPass; + unsigned long open_time; /* jiffies for last open */ + +#endif /* EXTRA_STATS */ struct timer_list timer; /* Media selection timer. */ + struct timer_list oom_timer; /* Out of memory timer. */ u32 mc_filter[2]; spinlock_t lock; spinlock_t mii_lock; @@ -391,6 +439,15 @@ unsigned long base_addr; int csr12_shadow; int pad0; /* Used for 8-byte alignment */ + +#ifdef CONFIG_NET_SKB_RECYCLING + unsigned int cnt[NR_CPUS]; + + union { + struct sk_buff_head list; + char pad[SMP_CACHE_BYTES]; + } tulip_recycle[NR_CPUS]; +#endif }; @@ -424,6 +481,7 @@ extern unsigned int tulip_max_interrupt_work; extern int tulip_rx_copybreak; void tulip_interrupt(int irq, void *dev_instance, struct pt_regs *regs); +int tulip_poll(struct net_device *dev, int *budget); int tulip_refill_rx(struct net_device *dev); /* media.c */ @@ -448,11 +506,22 @@ extern const char * const medianame[]; extern const char tulip_media_cap[]; extern struct tulip_chip_table tulip_tbl[]; +void oom_timer(unsigned long data); extern u8 t21040_csr13[]; extern u16 t21041_csr13[]; extern u16 t21041_csr14[]; extern u16 t21041_csr15[]; +/* tulip_misc.c */ +#ifdef EXTRA_STATS +void tulip_init_one_misc(struct net_device *dev); +void tulip_remove_one_misc (struct net_device *dev); +void tulip_open_misc(struct net_device *dev); +void tulip_close_misc(struct net_device *dev); +void ave_get(unsigned long arg); +void record_interrupt_cause( struct net_device *dev, int csr5); +#endif + #ifndef USE_IO_OPS #undef inb #undef inw @@ -498,3 +567,6 @@ } #endif /* __NET_TULIP_H__ */ + + + --------------020408050605010005000705-- From greearb@candelatech.com Wed Nov 6 00:51:59 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Nov 2002 00:52:06 -0800 (PST) Received: from grok.yi.org (IDENT:NMdjdFsLSryWrrQDKgkx7xSdqjFo3pdI@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA68pwuR022613 for ; Wed, 6 Nov 2002 00:51:59 -0800 Received: from candelatech.com (IDENT:3AdIFUq5kasZAOnCkM6+kbblyH+G4lI9@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id gA68r5q25244; Wed, 6 Nov 2002 01:53:05 -0700 Message-ID: <3DC8D871.9080106@candelatech.com> Date: Wed, 06 Nov 2002 00:53:05 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'netdev@oss.sgi.com'" , VLAN Mailing List Subject: PATCH: Fix up VLAN memory leaks Content-Type: multipart/mixed; boundary="------------070703050708000806070400" X-archive-position: 1094 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 This is a multi-part message in MIME format. --------------070703050708000806070400 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The first patch makes VLAN code quieter w/regard to the /var/log/messages output. The second fixes what I believe are two memory/resource leaks. I ran a perl script that created and destroyed thousands of VLANs...and my box is still standing, so I think the changes are good... Please look them over for sanity though, I may be mis-understanding some of Dave's changes... Patches are against 2.4.20-rc1 Thanks, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear --------------070703050708000806070400 Content-Type: text/plain; name="vlan1.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="vlan1.patch" --- /home/greear/kernel/2.4/linux-2.4.19/net/8021q/vlan_dev.c Tue Nov 5 21:32:42 2002 +++ vlan_dev.c Wed Nov 6 00:18:59 2002 @@ -738,7 +738,7 @@ while (dmi) { dev_mc_delete(dev, dmi->dmi_addr, dmi->dmi_addrlen, 0); - printk(KERN_INFO "%s: del %.2x:%.2x:%.2x:%.2x:%.2x:%.2x mcast address from vlan interface\n", + printk(KERN_DEBUG "%s: del %.2x:%.2x:%.2x:%.2x:%.2x:%.2x mcast address from vlan interface\n", dev->name, dmi->dmi_addr[0], dmi->dmi_addr[1], @@ -820,7 +820,7 @@ for (dmi = vlan_dev->mc_list; dmi != NULL; dmi = dmi->next) { if (vlan_should_add_mc(dmi, VLAN_DEV_INFO(vlan_dev)->old_mc_list)) { dev_mc_add(real_dev, dmi->dmi_addr, dmi->dmi_addrlen, 0); - printk(KERN_INFO "%s: add %.2x:%.2x:%.2x:%.2x:%.2x:%.2x mcast address to master interface\n", + printk(KERN_DEBUG "%s: add %.2x:%.2x:%.2x:%.2x:%.2x:%.2x mcast address to master interface\n", vlan_dev->name, dmi->dmi_addr[0], dmi->dmi_addr[1], @@ -838,7 +838,7 @@ * delete it from the real list on the underlying device. */ dev_mc_delete(real_dev, dmi->dmi_addr, dmi->dmi_addrlen, 0); - printk(KERN_INFO "%s: del %.2x:%.2x:%.2x:%.2x:%.2x:%.2x mcast address from master interface\n", + printk(KERN_DEBUG "%s: del %.2x:%.2x:%.2x:%.2x:%.2x:%.2x mcast address from master interface\n", vlan_dev->name, dmi->dmi_addr[0], dmi->dmi_addr[1], --------------070703050708000806070400 Content-Type: text/plain; name="vlan2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="vlan2.patch" --- /home/greear/kernel/2.4/linux-2.4.19/net/8021q/vlan.c Tue Nov 5 21:32:41 2002 +++ vlan.c Wed Nov 6 00:32:50 2002 @@ -45,7 +45,7 @@ static char vlan_fullname[] = "802.1Q VLAN Support"; static unsigned int vlan_version = 1; -static unsigned int vlan_release = 7; +static unsigned int vlan_release = 8; static char vlan_copyright[] = "Ben Greear "; static char vlan_buggyright[] = "David S. Miller "; @@ -256,6 +256,10 @@ __grp_unhash(grp); spin_unlock_bh(&vlan_group_lock); + /* Free the group, after we have removed it from the hash. */ + kfree(grp); + grp = NULL; + ret = 1; } @@ -625,7 +629,7 @@ ret = unregister_vlan_dev(dev, VLAN_DEV_INFO(vlandev)->vlan_id); - + dev_put(vlandev); unregister_netdevice(vlandev); /* Group was destroyed? */ --------------070703050708000806070400-- From helgehaf@aitel.hist.no Wed Nov 6 05:27:54 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Nov 2002 05:28:04 -0800 (PST) Received: from hermine.idb.hist.no (hermine.idb.hist.no [158.38.50.15]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA6DRruR000579 for ; Wed, 6 Nov 2002 05:27:54 -0800 Received: (qmail 4286 invoked by uid 0); 6 Nov 2002 13:28:59 -0000 Received: from unknown (HELO aitel.hist.no) (158.38.51.80) by hermine.idb.hist.no with SMTP; 6 Nov 2002 13:28:59 -0000 Message-ID: <3DC9192E.62600E21@aitel.hist.no> Date: Wed, 06 Nov 2002 14:29:18 +0100 From: Helge Hafting X-Mailer: Mozilla 4.76 [no] (X11; U; Linux 2.5.46 i686) X-Accept-Language: no, en, en MIME-Version: 1.0 To: Andrew Morton CC: linux-kernel@vger.kernel.org, davem@redhat.com, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi, netdev@oss.sgi.com Subject: Re: 2.5.46-mm1 3 uninitialized timers during boot, ipv6 related? References: <3DC8D423.DAD2BF1A@digeo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1095 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: helgehaf@aitel.hist.no Precedence: bulk X-list: netdev I see these aren't dangerous, but I guess they're there for someone to see. So here they are. Seems they have something to do with ipv6. VFS: Mounted root (ext2 filesystem) readonly. Mounted devfs on /dev Freeing unused kernel memory: 308k freed Adding 502700k swap on /dev/ide/host0/bus0/target0/lun0/part5. Priority:-1 extents:1 NTFS volume version 1.2. Uninitialised timer! This is just a warning. Your computer is OK function=0xc02b53dc, data=0xc1293aec Call Trace: [] check_timer_failed+0x40/0x4c [] igmp6_timer_handler+0x0/0x50 [] del_timer+0x15/0x74 [] igmp6_join_group+0x8a/0x104 [] igmp6_group_added+0xb0/0xbc [] fl_create+0x1b9/0x1f8 [] ipv6_dev_mc_inc+0x281/0x294 [] addrconf_join_solict+0x3a/0x44 [] addrconf_dad_start+0x13/0x12c [] addrconf_add_linklocal+0x28/0x40 [] addrconf_dev_config+0x99/0xa4 [] addrconf_notify+0x52/0xc0 [] notifier_call_chain+0x1e/0x38 [] dev_open+0xa2/0xac [] dev_change_flags+0x51/0x104 [] devinet_ioctl+0x2bc/0x598 [] inet_ioctl+0x7b/0xb8 [] packet_ioctl+0x173/0x190 [] sock_ioctl+0x1ef/0x218 [] sys_ioctl+0x21d/0x274 [] syscall_call+0x7/0xb Uninitialised timer! This is just a warning. Your computer is OK function=0xc02b53dc, data=0xc1293a1c Call Trace: [] check_timer_failed+0x40/0x4c [] igmp6_timer_handler+0x0/0x50 [] del_timer+0x15/0x74 [] igmp6_join_group+0x8a/0x104 [] igmp6_group_added+0xb0/0xbc [] fl_create+0x1b9/0x1f8 [] ipv6_dev_mc_inc+0x281/0x294 [] addrconf_join_solict+0x3a/0x44 [] addrconf_dad_start+0x13/0x12c [] addrconf_add_linklocal+0x28/0x40 [] addrconf_dev_config+0x99/0xa4 [] addrconf_notify+0x52/0xc0 [] notifier_call_chain+0x1e/0x38 [] dev_open+0xa2/0xac [] dev_change_flags+0x51/0x104 [] devinet_ioctl+0x2bc/0x598 [] inet_ioctl+0x7b/0xb8 [] sock_ioctl+0x1ef/0x218 [] sys_ioctl+0x21d/0x274 [] syscall_call+0x7/0xb Uninitialised timer! This is just a warning. Your computer is OK function=0xc02b53dc, data=0xc1293b54 Call Trace: [] check_timer_failed+0x40/0x4c [] igmp6_timer_handler+0x0/0x50 [] del_timer+0x15/0x74 [] igmp6_join_group+0x8a/0x104 [] igmp6_group_added+0xb0/0xbc [] fl_create+0x1b9/0x1f8 [] ipv6_dev_mc_inc+0x281/0x294 [] addrconf_join_solict+0x3a/0x44 [] addrconf_dad_start+0x13/0x12c [] addrconf_add_linklocal+0x28/0x40 [] addrconf_dev_config+0x99/0xa4 [] addrconf_notify+0x52/0xc0 [] notifier_call_chain+0x1e/0x38 [] dev_open+0xa2/0xac [] dev_change_flags+0x51/0x104 [] devinet_ioctl+0x2bc/0x598 [] inet_ioctl+0x7b/0xb8 [] sock_ioctl+0x1ef/0x218 [] sys_ioctl+0x21d/0x274 [] syscall_call+0x7/0xb eth0: no IPv6 routers present From Andrew.Morton@digeo.com Wed Nov 6 08:56:38 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Nov 2002 08:56:42 -0800 (PST) Received: from packet.digeo.com (packet.digeo.com [12.110.80.53]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA6GubuR013404 for ; Wed, 6 Nov 2002 08:56:38 -0800 Received: from digeo-nav01.digeo.com (digeo-nav01.digeo.com [192.168.1.233]) by packet.digeo.com (8.9.3+Sun/8.9.3) with SMTP id IAA15792 for ; Wed, 6 Nov 2002 08:57:40 -0800 (PST) Received: from schumi.digeo.com ([192.168.1.205]) by digeo-nav01.digeo.com (NAVGW 2.5.2.12) with SMTP id M2002110608593111616 ; Wed, 06 Nov 2002 08:59:31 -0800 Received: from pao-ex01.pao.digeo.com ([172.17.144.34]) by schumi.digeo.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 08:57:39 -0800 Received: from digeo.com ([172.17.144.18]) by pao-ex01.pao.digeo.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 6 Nov 2002 08:57:38 -0800 Message-ID: <3DC94A01.1ADC918E@digeo.com> Date: Wed, 06 Nov 2002 08:57:37 -0800 From: Andrew Morton X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.5.45 i686) X-Accept-Language: en MIME-Version: 1.0 To: Helge Hafting CC: linux-kernel@vger.kernel.org, davem@redhat.com, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi, netdev@oss.sgi.com Subject: Re: 2.5.46-mm1 3 uninitialized timers during boot, ipv6 related? References: <3DC8D423.DAD2BF1A@digeo.com> <3DC9192E.62600E21@aitel.hist.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2002 16:57:38.0413 (UTC) FILETIME=[9CAFB1D0:01C285B5] X-archive-position: 1096 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@digeo.com Precedence: bulk X-list: netdev Helge Hafting wrote: > > I see these aren't dangerous, but I guess they're there for > someone to see. So here they are. > Seems they have something to do with ipv6. > Dave has a bunch of additional fixes for net/*. Expect them to emerge from kernel.org real soon. From Robert.Olsson@data.slu.se Wed Nov 6 09:25:58 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Nov 2002 09:26:00 -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 gA6HPvuR014476 for ; Wed, 6 Nov 2002 09:25:58 -0800 Received: (from robert@localhost) by robur.slu.se (8.9.3/8.9.3) id SAA24669; Wed, 6 Nov 2002 18:34:42 +0100 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15817.21170.173913.829498@robur.slu.se> Date: Wed, 6 Nov 2002 18:34:42 +0100 To: Ben Greear Cc: "'netdev@oss.sgi.com'" , Jeff Garzik Subject: NAPI-ized tulip patch against 2.4.20-rc1 In-Reply-To: <3DC8B85B.5050805@candelatech.com> References: <3DC8B85B.5050805@candelatech.com> X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 1097 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 Ben Greear writes: > Here is a patch that makes Tulip support NAPI. The vast bulk of these > changes come from Robert Olsson's ftp site, I just pieced them together. > > It works good on my 4-port Tulip NICs, better than the default > driver at least (no, I never tried the old HW-Mitigation option). > > This patch will also make use of Robert's skb-recycle patch if it's > been applied, but through #ifdef magic, it should also work w/out > that.... Hello! Well skb recycling is "research" and should be used to challange to vm/slab people to start with... And I guess you will get objections about the extra stats as well. I see you increased the RX-ring to 1024 pkts. Did you really see any improvement with this? Also I would be interested if you have any numbers for recycling patch? Jamal and I spent some days after OLS to test and tune but it wasn't to promising at that time but it's reworked now. Cheers. --ro From greearb@candelatech.com Wed Nov 6 09:48:44 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Nov 2002 09:48:46 -0800 (PST) Received: from grok.yi.org (IDENT:Z/1ax39g5GA6S6rAkVsVUelvZbaFHMOx@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA6HmguR016030 for ; Wed, 6 Nov 2002 09:48:43 -0800 Received: from candelatech.com (IDENT:H6/rIuzIWeAFfBwnGuzK5ifzSnHHszMP@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id gA6Hncq19254; Wed, 6 Nov 2002 10:49:38 -0700 Message-ID: <3DC95631.6030001@candelatech.com> Date: Wed, 06 Nov 2002 09:49:37 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Olsson CC: "'netdev@oss.sgi.com'" , Jeff Garzik Subject: Re: NAPI-ized tulip patch against 2.4.20-rc1 References: <3DC8B85B.5050805@candelatech.com> <15817.21170.173913.829498@robur.slu.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1098 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 Robert Olsson wrote: > Ben Greear writes: > > Here is a patch that makes Tulip support NAPI. The vast bulk of these > > changes come from Robert Olsson's ftp site, I just pieced them together. > > > > It works good on my 4-port Tulip NICs, better than the default > > driver at least (no, I never tried the old HW-Mitigation option). > > > > This patch will also make use of Robert's skb-recycle patch if it's > > been applied, but through #ifdef magic, it should also work w/out > > that.... > > Hello! > > Well skb recycling is "research" and should be used to challange to vm/slab > people to start with... And I guess you will get objections about the extra > stats as well. The stats stuff is #ifdef'd out, as is the skb-recycling stuff. > > I see you increased the RX-ring to 1024 pkts. > Did you really see any improvement with this? It helped drop fewer packets when running 4 ports at 92Mbps+ However, the difference between that and 512 is not large. I would really like to make that size adjustable at module load time and/or runtime, but I'm not sure how easy that would be. Imagine being able to crank up your receive buffers when running at very high speeds (and/or when you start dropping packets). At lower speeds, shrink things down and free up resources.... > Also I would be interested if you have any numbers for recycling patch? I still need to do some comparisons with that being the only difference. I do know that it does not appear to hurt anything, but it's also possible that it doesn't really help. Since under normal circumstances there are enough buffers to be allocated with GFP_ATOMIC, I believe that it will take long statistical runs to determine if this really helps. I do like very much the fact that it actually gives me something deterministic to tune though, so I'll keep it for that reason if nothing else. > Jamal and I spent some days after OLS to test and tune but it wasn't to > promising at that time but it's reworked now. Were you testing SMP or uni-processor? I've been doing the tulip testing on a single processor P-IV system. 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 Wed Nov 6 10:29:58 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Nov 2002 10:29:59 -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 gA6ITvuR018421 for ; Wed, 6 Nov 2002 10:29:57 -0800 Received: from localhost (becker@localhost) by beohost.scyld.com (8.11.6/8.11.6) with ESMTP id gA6IV9205471; Wed, 6 Nov 2002 13:31:10 -0500 Date: Wed, 6 Nov 2002 13:31:09 -0500 (EST) From: Donald Becker To: Ben Greear cc: Robert Olsson , "'netdev@oss.sgi.com'" , Jeff Garzik Subject: Re: NAPI-ized tulip patch against 2.4.20-rc1 In-Reply-To: <3DC95631.6030001@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1099 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 Wed, 6 Nov 2002, Ben Greear wrote: > > I see you increased the RX-ring to 1024 pkts. > > Did you really see any improvement with this? > > It helped drop fewer packets when running 4 ports at 92Mbps+ > However, the difference between that and 512 is not large. Using 512 Rx buffers at 100Mbps seem like a pretty silly default. > I would really like to make that size adjustable at module load > time and/or runtime, but I'm not sure how easy that would be. It's trivial for many (but not all) drivers. I've been considering doing that with my driver release. There is no longer a CPU cycle cost issue with ring-wrapping on an arbitrary ring size. > Imagine being able to crank up your receive buffers when running at > very high speeds (and/or when you start dropping packets). At lower speeds, > shrink things down and free up resources.... Being that dynamic involves writing code and extensive testing with all of the different chips. The trivial case is a module option that sets a variable replacing RX_RING_SIZE / TX_RING_SIZE.. The passed-in value shouldn't be used directly: - many drivers have upper and lower bounds - the size can only be changed when the rings are initialized, which occurs when the interface starts. - users thinking "if 32 is good, 32000 is better" > > Also I would be interested if you have any numbers for recycling patch? interest++ -- 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 Wed Nov 6 10:43:16 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Nov 2002 10:43:18 -0800 (PST) Received: from grok.yi.org (IDENT:aTrRtNxpAGPVRGaQAZ0vF3eQyutljygR@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA6IhFuR018834 for ; Wed, 6 Nov 2002 10:43:16 -0800 Received: from candelatech.com (IDENT:YvH0tRQYR+CmjPCmYYyBZ2JdHZ77clnk@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id gA6IiHq19812; Wed, 6 Nov 2002 11:44:17 -0700 Message-ID: <3DC96301.7070602@candelatech.com> Date: Wed, 06 Nov 2002 10:44:17 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Donald Becker CC: "'netdev@oss.sgi.com'" Subject: Re: NAPI-ized tulip patch against 2.4.20-rc1 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1100 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: > On Wed, 6 Nov 2002, Ben Greear wrote: > > >>> I see you increased the RX-ring to 1024 pkts. >>> Did you really see any improvement with this? >> >>It helped drop fewer packets when running 4 ports at 92Mbps+ >>However, the difference between that and 512 is not large. > > > Using 512 Rx buffers at 100Mbps seem like a pretty silly default. I'm open to suggestions. However, I am running 4 or 8 ports simultaneously, on a single processor machine, so w/out large receive buffers, I drop packets horribly. If there is some magic number you think will be better than others, I'll be happy to try it and report results... > The trivial case is a module option that sets a variable replacing > RX_RING_SIZE / TX_RING_SIZE.. > The passed-in value shouldn't be used directly: > - many drivers have upper and lower bounds > - the size can only be changed when the rings are initialized, > which occurs when the interface starts. So, adjusting the ring size would require stopping and starting the NIC? Is that a full bounce (including auto-negotiation)? > - users thinking "if 32 is good, 32000 is better" The sad truth is, most NICs/drivers do not perform at high speeds w/out hacking them in various ways. Where to lay the blame (VM, shitty hardware, etc) is debatable, but it doesn't change the results. I do know that 1024 is better than 32 for high speeds on muliple ports, on my NICs. Thanks, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From Robert.Olsson@data.slu.se Wed Nov 6 11:37:58 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Nov 2002 11:38:00 -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 gA6JbvuR029303 for ; Wed, 6 Nov 2002 11:37:57 -0800 Received: (from robert@localhost) by robur.slu.se (8.9.3/8.9.3) id UAA27156; Wed, 6 Nov 2002 20:47:02 +0100 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15817.29109.859144.565330@robur.slu.se> Date: Wed, 6 Nov 2002 20:47:01 +0100 To: Ben Greear Cc: Robert Olsson , "'netdev@oss.sgi.com'" , Jeff Garzik Subject: Re: NAPI-ized tulip patch against 2.4.20-rc1 In-Reply-To: <3DC95631.6030001@candelatech.com> References: <3DC8B85B.5050805@candelatech.com> <15817.21170.173913.829498@robur.slu.se> <3DC95631.6030001@candelatech.com> X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 1101 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 Ben Greear writes: > > I see you increased the RX-ring to 1024 pkts. > > Did you really see any improvement with this? > > It helped drop fewer packets when running 4 ports at 92Mbps+ > However, the difference between that and 512 is not large. > I would really like to make that size adjustable at module load > time and/or runtime, but I'm not sure how easy that would be. > > Imagine being able to crank up your receive buffers when running at > very high speeds (and/or when you start dropping packets). At lower speeds, > shrink things down and free up resources.... I still doubt ;-) With e1000 I played with various settings for RX-buffers rather recently when the 82544 increased the number of available buffers from 256 to 4096. And I guess my test looks a bit like yours... Injecting an "overload" of packets. I found was 256 buffers was the optimum. Approximative of course. > Were you testing SMP or uni-processor? I've been doing the tulip testing > on a single processor P-IV system. We tested both at that time but it's rewritten now... And as you saw for SMP with recycle it is easy to feed the recycled skb back to CPU were it was created/processed. So kfree/skb_headerinit "should" cause less cache bouncing. Still we need to pollute one cache line to find the CPU "owner". I posted some of numbers here time ago but it would be nice to verify with CPU's performance counters. Cheers. --ro From becker@scyld.com Wed Nov 6 12:46:34 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Nov 2002 12:46:37 -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 gA6KkXuR030673 for ; Wed, 6 Nov 2002 12:46:33 -0800 Received: from localhost (becker@localhost) by beohost.scyld.com (8.11.6/8.11.6) with ESMTP id gA6Klkh05876; Wed, 6 Nov 2002 15:47:46 -0500 Date: Wed, 6 Nov 2002 15:47:43 -0500 (EST) From: Donald Becker To: Ben Greear cc: "'netdev@oss.sgi.com'" Subject: Re: NAPI-ized tulip patch against 2.4.20-rc1 In-Reply-To: <3DC96301.7070602@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1102 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 Wed, 6 Nov 2002, Ben Greear wrote: > > The trivial case is a module option that sets a variable replacing > > RX_RING_SIZE / TX_RING_SIZE.. > > The passed-in value shouldn't be used directly: > > - many drivers have upper and lower bounds > > - the size can only be changed when the rings are initialized, > > which occurs when the interface starts. > > So, adjusting the ring size would require stopping and starting the > NIC? Is that a full bounce (including auto-negotiation)? Most chips do not require bouncing the link when the interface is cycled down/up. That's not to say that some drivers don't reset the link -- it's easier for the driver writer to write the code that way, and doing the link reset can mask other problems. > > - users thinking "if 32 is good, 32000 is better" > > The sad truth is, most NICs/drivers do not perform at high > speeds w/out hacking them in various ways. Where to lay the > blame (VM, shitty hardware, etc) is debatable, but it doesn't > change the results. I do know that 1024 is better than 32 for > high speeds on muliple ports, on my NICs. I can see that changing the parameters is a quick, ad hoc solution. This list should focus on identifying the problems, rather than just patching in work-arounds. -- 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 Wed Nov 6 13:30:01 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Nov 2002 13:30:20 -0800 (PST) Received: from grok.yi.org (IDENT:dxvN2mzXVUsaDPTbA8GDsEAG90xrsa9m@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA6LU0uR032736 for ; Wed, 6 Nov 2002 13:30:01 -0800 Received: from candelatech.com (IDENT:69m0tBtLJ7DRx1RirhMeKzoFtkQ2UxsB@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id gA6LUuq21282; Wed, 6 Nov 2002 14:30:57 -0700 Message-ID: <3DC98A10.5030407@candelatech.com> Date: Wed, 06 Nov 2002 13:30:56 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Olsson CC: "'netdev@oss.sgi.com'" Subject: Re: NAPI-ized tulip patch against 2.4.20-rc1 References: <3DC8B85B.5050805@candelatech.com> <15817.21170.173913.829498@robur.slu.se> <3DC95631.6030001@candelatech.com> <15817.29109.859144.565330@robur.slu.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1103 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 Robert Olsson wrote: > Ben Greear writes: > I still doubt ;-) > > With e1000 I played with various settings for RX-buffers rather recently > when the 82544 increased the number of available buffers from 256 to 4096. > > And I guess my test looks a bit like yours... Injecting an "overload" of > packets. I found was 256 buffers was the optimum. Approximative of course. It's possible that it is a particular issue with my NICs (Old Phobos 4-port). Phobos folks said the bridge chipset has errata that make it un-suitable for high speeds. And something about a memory divide-by-four error. It may be that the extra buffers help hide the hardware defects in some manner. I was, for instance, seeing cases where packets just dissappeared...and no error counters were being bumped. With the latest kernel drivers, the 570tx NIC seems to have trouble autonegotiating full-duplex again, so I have not been testing with it lately (I think it uses the same bridge chipset anyway.) I will try changing around those numbers again now that I have a baseline to work from. > And as you saw for SMP with recycle it is easy to feed the recycled skb > back to CPU were it was created/processed. Yes, I can see how that would be useful on SMP, so there may be less gain for single-proc systems. I actually am pretty fuzzy on cache-line optimizations and the like... Thanks, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From bleckey@tpg.com.au Wed Nov 6 14:15:21 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Nov 2002 14:15:23 -0800 (PST) Received: from mail2.tpgi.com.au (mail.tpgi.com.au [203.12.160.58]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA6MFKuR001533 for ; Wed, 6 Nov 2002 14:15:21 -0800 Received: from tpg.com.au (wolf.tpgi.com.au [203.58.27.182]) (authenticated (0 bits)) by mail2.tpgi.com.au (8.11.6/8.11.6) with ESMTP id gA6MGTC30182 for ; Thu, 7 Nov 2002 09:16:29 +1100 Message-ID: <3DC8EAE1.80001@tpg.com.au> Date: Wed, 06 Nov 2002 21:11:45 +1100 From: Bill Leckey User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Net device queries. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1104 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bleckey@tpg.com.au Precedence: bulk X-list: netdev I've been coding an ethernet driver for some new hardware we're developing and while it's working, there are a few issues I'm still unsure of. I couldn't find any archives for this list, so I'm suspecting I'm going to cover a lot of 'old ground'. Firstly some background. With these cards I can have up to 25 point to point connections (to the same destination machine, or 25 destination machines). I have almost total control of what goes out on the wire, so I've chosen a minimal header that contains the type (passed in to hard_header) and a 16 bit field that contains misc other information. So, 32 bits, plus the data. The hardware provides things like length, and CRC checking. Currently I'm setting dev->hard_header_len to 4. The part that concerns me is what I set dev->type, dev->addr_len and dev->flags to. We don't technically have a hardware address so I set dev->addr_len to 0. I set dev->type to ARPHRD_VOID, simply because I'm not sure what the consequences of setting it to anything else are. I set dev->flags to IFF_POINTOPOINT | IFF_NOARP This appears to all work correctly, however both ifconfig and tcpdump aren't really happy. TCPDUMP doesn't know what to do with the ARPHRD_VOID and drops to 'raw' mode, so it still does what I need, even if it prints an annoying message for each packet. ifconfig isn't sure what to do about the HWaddr. For instance, this is the ifconfig for one of the links: hssl0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:192.168.2.1 P-t-P:192.168.2.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 RX packets:3509748 errors:459 dropped:0 overruns:0 frame:363 TX packets:3013210 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:368907445 (351.8 Mb) TX bytes:266074976 (253.7 Mb) Any thoughts, comments or otherwise on what I've done, or what I /should/ be doing would be appreciated as I'm still not fully across how the networking stuff works. Bill -- Bill Leckey - Senior Software Design Engineer TPG Research and Development Ph: +61 2 62851711 Fax: +61 2 62853939 From jenil68@21cn.com Wed Nov 6 21:50:52 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Nov 2002 21:50:54 -0800 (PST) Received: from 21cn.com ([211.102.32.161]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA75onuS007434 for ; Wed, 6 Nov 2002 21:50:51 -0800 Message-Id: <200211070550.gA75onuS007434@oss.sgi.com> From: "jenil68@21cn.com" To: netdev@oss.sgi.com Content-Type: text/html;charset="GB2312" Reply-To: jenil68@21cn.com Date: Thu, 7 Nov 2002 13:55:45 +0800 X-Priority: 2 X-Mailer: FoxMail 3.11 Release [cn] X-archive-position: 1105 Subject: (no subject) X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jenil68@21cn.com Precedence: bulk X-list: netdev >ÄúºÃ£¡ > >´òÈÅÄú¶þ·ÖÖÓµÄʱ¼ä£¡ÈçÓÐÎó·¢Çëɾ³ý£¬Ð»Ð»£¡ > >ÎÒ¹«Ë¾ÓÐÏêϸµÄ¾ÆµêÔ¤¶©ÏµÍ³Æ½Ì¨¼°È«¹ú¿Í»§×ÊÁÏ£¬ÈçÓÐÐèÇóÕßÇëÓëÎÒ¹«Ë¾ÁªÏµ£¡ÁªÏµµç»°£º020-38795779 > >ºÎС½ã£¬Óʼþ: > >лл£¡ > >Hi > > From zjp@iscas.ac.cn Wed Nov 6 22:18:51 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Nov 2002 22:18:55 -0800 (PST) Received: from mail.iscas.ac.cn ([159.226.5.56]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA76InuR008357 for ; Wed, 6 Nov 2002 22:18:50 -0800 Received: (qmail 7388 invoked by uid 104); 7 Nov 2002 06:20:19 -0000 Received: from zjp@iscas.ac.cn by mail.iscas.ac.cn by uid 0 with qmail-scanner-1.14 (hbedv: 6.15.0.1. hbedv: operating system: Linux (glibc). hbedv: product version: 2.0.4. hbedv: engine version: 6.15.0.1. hbedv: packlib version: 2.0.0.8 (supports 19 formats). hbedv: vdf version: 6.15.0.7 (66928 recognized forms). hbedv: . hbedv: product: AntiVir Workstation. hbedv: key file: hbedv.key. hbedv: registered user: irene, 123. hbedv: serial number: 1001020203. hbedv: key expires: 31 May 2003. hbedv: run mode: PRIVATE. hbedv: . hbedv: product: AntiVir MailGate. hbedv: key file: hbedv.key. hbedv: registered user: irene, 123. hbedv: serial number: 1001020203. hbedv: key expires: 31 May 2003. hbedv: run mode: PRIVATE. hbedv: . hbedv: product: AntiVir (command line scanner). hbedv: key file: hbedv.key. hbedv: registered user: irene, 123. hbedv: serial number: 1001020203. hbedv: key expires: 31 May 2003. hbedv: run mode: PRIVATE. Clear:. Processed in 0.216501 secs); 07 Nov 2002 06:20:19 -0000 Received: from unknown (HELO zhengjp) (zjp@192.168.6.108) by mail.iscas.ac.cn with SMTP; 7 Nov 2002 06:20:19 -0000 Message-ID: <005a01c28625$f63a6810$6c06a8c0@zhengjp> From: "Zheng Jianping" To: Subject: how ipv6 support multicast routing Date: Thu, 7 Nov 2002 14:21:52 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 635 X-archive-position: 1106 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zjp@iscas.ac.cn Precedence: bulk X-list: netdev Hi, We are developing IPv6 multicast routing protocol --PIM-SM. To support IPv6 multicast packet forwarding, Linux kernel need to be modified. I am coding the file 'ip6_mroute.c' which is derived from 'ipmr.c' in ipv4. My question is how to modify the IPv6 code in the kernl to make 'ip6_mroute.c' works, i.e how to modify the files such as 'ip6/ip6_ouput.c', 'ip6/route.c' , etc. I try to refrence to IPv4 code but it seems that the routing mechanism of IPv6 is something different from IPv4. So I get confused. Could you give me some suggestion? Thanks in advance! Best Regards, Zheng [[HTML alternate version deleted]] From pekkas@netcore.fi Wed Nov 6 22:44:47 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Nov 2002 22:44:53 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA76ikuR010701 for ; Wed, 6 Nov 2002 22:44:46 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gA76jis08545; Thu, 7 Nov 2002 08:45:45 +0200 Date: Thu, 7 Nov 2002 08:45:43 +0200 (EET) From: Pekka Savola To: Zheng Jianping cc: netdev@oss.sgi.com Subject: Re: how ipv6 support multicast routing In-Reply-To: <005a01c28625$f63a6810$6c06a8c0@zhengjp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1107 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev On Thu, 7 Nov 2002, Zheng Jianping wrote: > We are developing IPv6 multicast routing protocol --PIM-SM. To support IPv6 multicast packet forwarding, Linux kernel need to be modified. I am coding the file 'ip6_mroute.c' which is derived from 'ipmr.c' in ipv4. > > My question is how to modify the IPv6 code in the kernl to make 'ip6_mroute.c' works, i.e how to modify the files such as 'ip6/ip6_ouput.c', 'ip6/route.c' , etc. > > I try to refrence to IPv4 code but it seems that the routing mechanism of IPv6 is something different from IPv4. So I get confused. have you looked at ip6_input.c/ip6_output.c already? There's an (obsolete) ip6_mc_input function there, perhaps it might get you started. I recall usagi have made some minor modifications to it too, but I doubt it works. (I'd like to see PIM-SM work myself too.) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From greearb@candelatech.com Wed Nov 6 23:07:03 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Nov 2002 23:07:12 -0800 (PST) Received: from grok.yi.org (IDENT:iblmgvn3y86ncU0n9pzgbaiSamzP3MZj@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7770uR011227 for ; Wed, 6 Nov 2002 23:07:01 -0800 Received: from candelatech.com (IDENT:fv6s6/JS6mWC59mV8QHYOTDWHJxRdmRd@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id gA7782q12398; Thu, 7 Nov 2002 00:08:03 -0700 Message-ID: <3DCA1152.7040002@candelatech.com> Date: Wed, 06 Nov 2002 23:08:02 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Donald Becker CC: "'netdev@oss.sgi.com'" Subject: Re: NAPI-ized tulip patch against 2.4.20-rc1 References: Content-Type: multipart/mixed; boundary="------------080602000200060108030909" X-archive-position: 1108 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 This is a multi-part message in MIME format. --------------080602000200060108030909 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Here's an update of the tulip-NAPI and skb-recycle patches. I made some changes to get it to compile and work when the RECYCLE define in skbuff.h was not enabled. I also got some test runs in. Nothing really conclusive. Test setup: Phobos 4-port NIC in each P-IV 1.8Ghz machine 32/33 PCI bus. Kernel 2.4.20-rc1 + my patches. NICs connected to each other over CX cables. Sending 4k 1514 byte packets per second, send + receive. (48Mbps or so) RX ring size is 1024 for all of these tests. No significant errors reported by the driver. I don't know where these dropped packets go..no counter seems to be catching them. I sent 1 million packets (or very close to that) on every interface (received the same, mostly) Without SKB-Recycle: dropped 339 out of 1Million, repeated test twice, numbers very similar. When packets do drop, they drop on all interfaces in bursts of 10-150, generally. Latency was about .3ms With SKB-Recycle (300 pkt hot-list) dropped 230, 500, and 180 in consecutive runs. They also drop in bursts. The middle run may be bad luck...don't know. Latency was about .3ms While typing, I ran a longer test. Dropped about 1600 out of 4 million. So, I think I can't draw too much from any of this. The bottleneck and/or problem seems to lie elsewhere. I will work on testing various rx-buffer sizes tomorrow... Enjoy, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear --------------080602000200060108030909 Content-Type: text/plain; name="napi_tune_2.4.19.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="napi_tune_2.4.19.patch" --- linux-2.4.19.p3/include/linux/skbuff.h Fri Aug 2 17:39:46 2002 +++ linux-2.4.19.p4/include/linux/skbuff.h Wed Nov 6 22:21:52 2002 @@ -14,6 +14,8 @@ #ifndef _LINUX_SKBUFF_H #define _LINUX_SKBUFF_H +#define CONFIG_NET_SKB_RECYCLING + #include #include #include @@ -25,6 +27,7 @@ #include #include #include +#include /* PACKET_HOST */ #define HAVE_ALLOC_SKB /* For the drivers to know */ #define HAVE_ALIGNABLE_SKB /* Ditto 8) */ @@ -194,6 +197,11 @@ unsigned char *end; /* End pointer */ void (*destructor)(struct sk_buff *); /* Destruct function */ +#ifdef CONFIG_NET_SKB_RECYCLING + struct net_device *recycle_dev; /* Device we arrived on */ + int tag; /* Device private tag. */ +#endif + #ifdef CONFIG_NETFILTER /* Can be used for communication between hooks. */ unsigned long nfmark; @@ -1109,6 +1117,45 @@ #endif } + +/* + * Slab constructor for a skb head. + */ +static inline void skb_headerinit(void *p, kmem_cache_t *cache, + unsigned long flags) +{ + struct sk_buff *skb = p; + + skb->next = NULL; + skb->prev = NULL; + skb->list = NULL; + skb->sk = NULL; + skb->stamp.tv_sec=0; /* No idea about time */ + skb->dev = NULL; + skb->dst = NULL; + memset(skb->cb, 0, sizeof(skb->cb)); + skb->pkt_type = PACKET_HOST; /* Default type */ + skb->ip_summed = 0; + skb->priority = 0; + skb->security = 0; /* By default packets are insecure */ + skb->destructor = NULL; + +#ifdef CONFIG_NET_SKB_RECYCLING + skb->recycle_dev = 0; +#endif + +#ifdef CONFIG_NETFILTER + skb->nfmark = skb->nfcache = 0; + skb->nfct = NULL; +#ifdef CONFIG_NETFILTER_DEBUG + skb->nf_debug = 0; +#endif +#endif +#ifdef CONFIG_NET_SCHED + skb->tc_index = 0; +#endif +} + #define skb_queue_walk(queue, skb) \ for (skb = (queue)->next; \ (skb != (struct sk_buff *)(queue)); \ --- linux-2.4.19.p3/net/core/skbuff.c Fri Aug 2 17:39:46 2002 +++ linux-2.4.19.p4/net/core/skbuff.c Tue Nov 5 22:02:57 2002 @@ -217,40 +217,6 @@ } -/* - * Slab constructor for a skb head. - */ -static inline void skb_headerinit(void *p, kmem_cache_t *cache, - unsigned long flags) -{ - struct sk_buff *skb = p; - - skb->next = NULL; - skb->prev = NULL; - skb->list = NULL; - skb->sk = NULL; - skb->stamp.tv_sec=0; /* No idea about time */ - skb->dev = NULL; - skb->dst = NULL; - memset(skb->cb, 0, sizeof(skb->cb)); - skb->pkt_type = PACKET_HOST; /* Default type */ - skb->ip_summed = 0; - skb->priority = 0; - skb->security = 0; /* By default packets are insecure */ - skb->destructor = NULL; - -#ifdef CONFIG_NETFILTER - skb->nfmark = skb->nfcache = 0; - skb->nfct = NULL; -#ifdef CONFIG_NETFILTER_DEBUG - skb->nf_debug = 0; -#endif -#endif -#ifdef CONFIG_NET_SCHED - skb->tc_index = 0; -#endif -} - static void skb_drop_fraglist(struct sk_buff *skb) { struct sk_buff *list = skb_shinfo(skb)->frag_list; @@ -326,8 +292,15 @@ #ifdef CONFIG_NETFILTER nf_conntrack_put(skb->nfct); #endif - skb_headerinit(skb, NULL, 0); /* clean state */ - kfree_skbmem(skb); + +#ifdef CONFIG_NET_SKB_RECYCLING + if(skb->recycle_dev && skb->recycle_dev->skb_recycle ) { + if(skb->recycle_dev->skb_recycle(skb)) return; + } +#endif + + skb_headerinit(skb, NULL, 0); /* clean state */ + kfree_skbmem(skb); } /** @@ -384,6 +357,9 @@ C(tail); C(end); n->destructor = NULL; +#ifdef CONFIG_NET_SKB_RECYCLING + skb->recycle_dev = 0; +#endif #ifdef CONFIG_NETFILTER C(nfmark); C(nfcache); @@ -428,6 +404,9 @@ new->pkt_type=old->pkt_type; new->stamp=old->stamp; new->destructor = NULL; +#ifdef CONFIG_NET_SKB_RECYCLING + new->recycle_dev = 0; +#endif new->security=old->security; #ifdef CONFIG_NETFILTER new->nfmark=old->nfmark; --- linux-2.4.19.p3/Documentation/networking/skb_recycling.txt Wed Dec 31 16:00:00 1969 +++ linux-2.4.19.p4/Documentation/networking/skb_recycling.txt Tue Nov 5 22:02:57 2002 @@ -0,0 +1,186 @@ + +skb reuse. +----------- + +Q: Why? +A: With skb recycling one has the option of recycling the skb with the + driver that allocated it in the first place. This decreases the need + to malloc memory for each packet, and also should help keep from + invalidating the cache so often. This all leads to higher performance + networking, and also provides better ways to tune a system to your high + performance needs. + +Q: Slab does the job already. +A: Yes and RC uses slab for object coloring etc but can have some advances + of having a closer loop. Also there are some upcoming hardware that needs + this skb handling. + +Q: With this memory will be allocated in "private" that kernel cannot use? +A: Yes true. But do deal with a new driver method is added. "mem_reclaim" + this can be called from anyone (kernel) to ask the driver to give back + allocated memory. The amount of memory kept by the driver can be made + run-time adjustable easily, and it can also be specified at module load + time. + +Q: Isn't the same job to be done now at the driver instead of at kfree? +A: No by knowing that the same skb is returned the driver/allocator can do + a minimal refresh of the skb header and avoid the relatively costly + alloc and free of the "data" part. Just a minimal "refresh" is needed + the when driver gets it's old skb back. The skb was good before... + Also this can be used to re-route an skb to initialized in CPU where + is was created. With SMP the TX interrupt can come in any CPU and this + causes cache bouncing. Eventually we can reduce this be marking + the skb where is was created and at the recycler put it back on that + list. Not slab uses per-CPU lists but just put the skb back on the + "current" slab. + +Q: SMP and L2 cache locality? +A: Driver can have "per-CPU" recycling and stores recycled skb's in LIFO + this should result in L2 cache friendliness. Tests to be done... + +Q: Compatibility? Does it break "old" drivers? +A: No, because old drivers do not mark any recycler callback. Alloc and + kfree runs as usual. + +Q: The skb's are added lot of states as the they travel through the IP + stack. How is this handled? +A: Well we wait util the "states" are properly handled we have no hurry + to recycle the skb and clearing of the states has to be done anyway. + +Q: Is it proven in "real life" yet? +A: No. It's research and under development + It works for me. --Ben + + +1) Implementation + + +* Kernel part. + + + +* Driver part. + + +Recycling callback and skb buffers in e1000 +=========================================== +In the private driver field: + + +#ifdef CONFIG_NET_SKB_RECYCLING + unsigned int cnt[NR_CPUS]; + + union { + struct sk_buff_head list; + char pad[SMP_CACHE_BYTES]; + } e1000_recycle[NR_CPUS]; + +#endif + + +The main recycler +================= + + +int skb_hotlist = 300; + +int e1000_recycle(struct sk_buff *skb) +{ + + /* Note! skb->skb_recycle CANNOT be NULL here */ + struct e1000_adapter *adapter = skb->recycle_dev->priv; + + /* Store for right CPU. For this we use skb->tag */ + struct sk_buff_head *list = &adapter->e1000_recycle[skb->tag].list; + + /* + decrease our outstanding skb's: + 1) either we store in the list OR + 2) we ignore so gets to kfree + */ + + adapter->cnt[smp_processor_id()]--; + + if (skb_queue_len(list) <= skb_hotlist) { + + /* LIFO queue for cache friendliness */ + + skb_queue_head(list, skb); + return 1; + } + return 0; +} + + +At open: +======== + + for (i=0; ie1000_recycle[i].list); + } + +At close: +========= + + /* Schedule while outstanding skb's exists */ + + for (i=0; icnt[i]) { + current->state = TASK_INTERRUPTIBLE; + schedule_timeout(1); + } + } + + for (i=0; ie1000_recycle[i].list; + while ((skb=skb_dequeue(list))!=NULL) { + skb->recycle_dev = NULL; + kfree_skb(skb); + } + + } + + +When allocting RX buffers: +========================== + + skb = skb_dequeue(list); /* Try recycler list */ + + if(skb) { + skb_headerinit(skb, NULL, 0); /* clean state */ + + /* NOTE. e1000 uses not dev_alloc_skb */ + + skb->data = skb->head; + skb->tail = skb->head; + skb->len = 0; + adapter->RC_hit++; + } + else adapter->RC_miss++; + + if(!skb) + + skb = alloc_skb(adapter->rx_buffer_len + reserve_len, GFP_ATOMIC); + + if(!skb) { + /* Better luck next round */ + break; + } + + adapter->cnt[smp_processor_id()]++; + skb->tag = smp_processor_id(); + skb->recycle_dev = netdev; + skb->recycle_dev->skb_recycle = e1000_recycle; + + +And to well behaved kernel citizen +================================== +void e1000_mem_reclaim(struct net_device *dev) +{ +/* Someone (kernel probably) is asking us to reduce memory usage */ + + /* If we use RC we purge private buffers etc.*/ + /* TODO: */ + +} --------------080602000200060108030909 Content-Type: text/plain; name="tulip_2.4.19.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tulip_2.4.19.patch" --- linux-2.4.19.p3/drivers/net/tulip/interrupt.c Tue Nov 5 21:33:22 2002 +++ linux-2.4.19.p4/drivers/net/tulip/interrupt.c Tue Nov 5 22:08:45 2002 @@ -1,4 +1,4 @@ -/* +/* -*-linux-c-*- drivers/net/tulip/interrupt.c Maintained by Jeff Garzik @@ -23,9 +23,14 @@ int tulip_rx_copybreak; unsigned int tulip_max_interrupt_work; -#ifdef CONFIG_NET_HW_FLOWCONTROL +#ifdef CONFIG_NET_SKB_RECYCLING +int tulip_recycle(struct sk_buff *skb); +#endif +#ifdef USE_MITIGATION #define MIT_SIZE 15 +#define MIT_TABLE 15 /* We use 0 or max */ + unsigned int mit_table[MIT_SIZE+1] = { /* CRS11 21143 hardware Mitigation Control Interrupt @@ -99,16 +104,28 @@ return refilled; } +void oom_timer(unsigned long data) +{ + struct net_device *dev = (struct net_device *)data; + netif_rx_schedule(dev); +} + -static int tulip_rx(struct net_device *dev) +int tulip_poll(struct net_device *dev, int *budget) { struct tulip_private *tp = (struct tulip_private *)dev->priv; int entry = tp->cur_rx % RX_RING_SIZE; - int rx_work_limit = tp->dirty_rx + RX_RING_SIZE - tp->cur_rx; + int rx_work_limit = *budget; int received = 0; -#ifdef CONFIG_NET_HW_FLOWCONTROL - int drop = 0, mit_sel = 0; +#ifdef EXTRA_STATS + tp->stats_poll_starts++; +#endif + + if (rx_work_limit > dev->quota) + rx_work_limit = dev->quota; + +#ifdef USE_MITIGATION /* that one buffer is needed for mit activation; or might be a bug in the ring buffer code; check later -- JHS*/ @@ -118,177 +135,266 @@ if (tulip_debug > 4) printk(KERN_DEBUG " In tulip_rx(), entry %d %8.8x.\n", entry, - tp->rx_ring[entry].status); - /* If we own the next entry, it is a new packet. Send it up. */ - while ( ! (tp->rx_ring[entry].status & cpu_to_le32(DescOwned))) { - s32 status = le32_to_cpu(tp->rx_ring[entry].status); - - if (tulip_debug > 5) - printk(KERN_DEBUG "%s: In tulip_rx(), entry %d %8.8x.\n", - dev->name, entry, status); - if (--rx_work_limit < 0) - break; - if ((status & 0x38008300) != 0x0300) { - if ((status & 0x38000300) != 0x0300) { - /* Ingore earlier buffers. */ - if ((status & 0xffff) != 0x7fff) { - if (tulip_debug > 1) - printk(KERN_WARNING "%s: Oversized Ethernet frame " - "spanned multiple buffers, status %8.8x!\n", - dev->name, status); - tp->stats.rx_length_errors++; - } - } else if (status & RxDescFatalErr) { + tp->rx_ring[entry].status); + + + do { + /* Acknowledge current RX interrupt sources. */ + outl((RxIntr | RxNoBuf), dev->base_addr + CSR5); + + + /* If we own the next entry, it is a new packet. Send it up. */ + while ( ! (tp->rx_ring[entry].status & cpu_to_le32(DescOwned))) { + s32 status = le32_to_cpu(tp->rx_ring[entry].status); + + + if (tp->dirty_rx + RX_RING_SIZE == tp->cur_rx) + break; + + if (tulip_debug > 5) + printk(KERN_DEBUG "%s: In tulip_rx(), entry %d %8.8x.\n", + dev->name, entry, status); + if (--rx_work_limit < 0) + goto not_done; + + if ((status & 0x38008300) != 0x0300) { + if ((status & 0x38000300) != 0x0300) { + /* Ignore earlier buffers. */ + if ((status & 0xffff) != 0x7fff) { + if (tulip_debug > 1) + printk(KERN_WARNING "%s: Oversized Ethernet frame " + "spanned multiple buffers, status %8.8x!\n", + dev->name, status); + tp->stats.rx_length_errors++; + } + } else if (status & RxDescFatalErr) { /* There was a fatal error. */ - if (tulip_debug > 2) - printk(KERN_DEBUG "%s: Receive error, Rx status %8.8x.\n", - dev->name, status); - tp->stats.rx_errors++; /* end of a packet.*/ - if (status & 0x0890) tp->stats.rx_length_errors++; - if (status & 0x0004) tp->stats.rx_frame_errors++; - if (status & 0x0002) tp->stats.rx_crc_errors++; - if (status & 0x0001) tp->stats.rx_fifo_errors++; - } - } else { - /* Omit the four octet CRC from the length. */ - short pkt_len = ((status >> 16) & 0x7ff) - 4; - struct sk_buff *skb; + if (tulip_debug > 2) + printk(KERN_DEBUG "%s: Receive error, Rx status %8.8x.\n", + dev->name, status); + tp->stats.rx_errors++; /* end of a packet.*/ + if (status & 0x0890) tp->stats.rx_length_errors++; + if (status & 0x0004) tp->stats.rx_frame_errors++; + if (status & 0x0002) tp->stats.rx_crc_errors++; + if (status & 0x0001) tp->stats.rx_fifo_errors++; + } + } else { + /* Omit the four octet CRC from the length. */ + short pkt_len = ((status >> 16) & 0x7ff) - 4; + struct sk_buff *skb = NULL; #ifndef final_version - if (pkt_len > 1518) { - printk(KERN_WARNING "%s: Bogus packet size of %d (%#x).\n", - dev->name, pkt_len, pkt_len); - pkt_len = 1518; - tp->stats.rx_length_errors++; - } + if (pkt_len > 1518) { + printk(KERN_WARNING "%s: Bogus packet size of %d (%#x).\n", + dev->name, pkt_len, pkt_len); + pkt_len = 1518; + tp->stats.rx_length_errors++; + } #endif -#ifdef CONFIG_NET_HW_FLOWCONTROL - drop = atomic_read(&netdev_dropping); - if (drop) - goto throttle; -#endif - /* Check if the packet is long enough to accept without copying - to a minimally-sized skbuff. */ - if (pkt_len < tulip_rx_copybreak - && (skb = dev_alloc_skb(pkt_len + 2)) != NULL) { - skb->dev = dev; - skb_reserve(skb, 2); /* 16 byte align the IP header */ - pci_dma_sync_single(tp->pdev, - tp->rx_buffers[entry].mapping, - pkt_len, PCI_DMA_FROMDEVICE); + /* Check if the packet is long enough to accept without copying + to a minimally-sized skbuff. */ +#ifdef CONFIG_NET_SKB_RECYCLING + if (pkt_len < tulip_rx_copybreak) { + /* Allocate an skb from our private queue if possible */ + skb = skb_dequeue(&(tp->tulip_recycle[smp_processor_id()].list)); + if (skb) { + skb_headerinit(skb, NULL, 0); /* clean state */ + + skb->data = skb->head; + skb->tail = skb->head; + skb->len = 0; + } + } +#endif + if ((pkt_len < tulip_rx_copybreak) + && ((skb != NULL) + || ((skb = dev_alloc_skb(pkt_len + 2)) != NULL))) { + skb->dev = dev; + skb_reserve(skb, 2); /* 16 byte align the IP header */ + pci_dma_sync_single(tp->pdev, + tp->rx_buffers[entry].mapping, + pkt_len, PCI_DMA_FROMDEVICE); #if ! defined(__alpha__) - eth_copy_and_sum(skb, tp->rx_buffers[entry].skb->tail, - pkt_len, 0); - skb_put(skb, pkt_len); + eth_copy_and_sum(skb, tp->rx_buffers[entry].skb->tail, + pkt_len, 0); + skb_put(skb, pkt_len); #else - memcpy(skb_put(skb, pkt_len), - tp->rx_buffers[entry].skb->tail, - pkt_len); -#endif - } else { /* Pass up the skb already on the Rx ring. */ - char *temp = skb_put(skb = tp->rx_buffers[entry].skb, - pkt_len); + memcpy(skb_put(skb, pkt_len), + tp->rx_buffers[entry].skb->tail, + pkt_len); +#endif +#ifdef CONFIG_NET_SKB_RECYCLING + skb->tag = smp_processor_id(); + tp->cnt[skb->tag]++; + skb->recycle_dev = dev; + skb->recycle_dev->skb_recycle = tulip_recycle; +#endif + } else { /* Pass up the skb already on the Rx ring. */ + char *temp = skb_put(skb = tp->rx_buffers[entry].skb, + pkt_len); #ifndef final_version - if (tp->rx_buffers[entry].mapping != - le32_to_cpu(tp->rx_ring[entry].buffer1)) { - printk(KERN_ERR "%s: Internal fault: The skbuff addresses " - "do not match in tulip_rx: %08x vs. %08x %p / %p.\n", - dev->name, - le32_to_cpu(tp->rx_ring[entry].buffer1), - tp->rx_buffers[entry].mapping, - skb->head, temp); - } + if (tp->rx_buffers[entry].mapping != + le32_to_cpu(tp->rx_ring[entry].buffer1)) { + printk(KERN_ERR "%s: Internal fault: The skbuff addresses " + "do not match in tulip_rx: %08x vs. %08x %p / %p.\n", + dev->name, + le32_to_cpu(tp->rx_ring[entry].buffer1), + tp->rx_buffers[entry].mapping, + skb->head, temp); + } #endif - pci_unmap_single(tp->pdev, tp->rx_buffers[entry].mapping, - PKT_BUF_SZ, PCI_DMA_FROMDEVICE); + pci_unmap_single(tp->pdev, tp->rx_buffers[entry].mapping, + PKT_BUF_SZ, PCI_DMA_FROMDEVICE); - tp->rx_buffers[entry].skb = NULL; - tp->rx_buffers[entry].mapping = 0; - } - skb->protocol = eth_type_trans(skb, dev); -#ifdef CONFIG_NET_HW_FLOWCONTROL - mit_sel = -#endif - netif_rx(skb); - -#ifdef CONFIG_NET_HW_FLOWCONTROL - switch (mit_sel) { - case NET_RX_SUCCESS: - case NET_RX_CN_LOW: - case NET_RX_CN_MOD: - break; - - case NET_RX_CN_HIGH: - rx_work_limit -= NET_RX_CN_HIGH; /* additional*/ - break; - case NET_RX_DROP: - rx_work_limit = -1; - break; - default: - printk("unknown feedback return code %d\n", mit_sel); - break; - } + tp->rx_buffers[entry].skb = NULL; + tp->rx_buffers[entry].mapping = 0; + } + skb->protocol = eth_type_trans(skb, dev); - drop = atomic_read(&netdev_dropping); - if (drop) { -throttle: - rx_work_limit = -1; - mit_sel = NET_RX_DROP; - - if (tp->fc_bit) { - long ioaddr = dev->base_addr; - - /* disable Rx & RxNoBuf ints. */ - outl(tulip_tbl[tp->chip_id].valid_intrs&RX_A_NBF_STOP, ioaddr + CSR7); - set_bit(tp->fc_bit, &netdev_fc_xoff); - } - } + netif_receive_skb(skb); + + dev->last_rx = jiffies; + tp->stats.rx_packets++; + tp->stats.rx_bytes += pkt_len; + } + received++; +#ifdef EXTRA_STATS + tp->stats_poll_pkts++; +#ifdef USE_MITIGATION + if(tp->mit_on) tp->stats_poll_pkts_mit++; +#endif #endif - dev->last_rx = jiffies; - tp->stats.rx_packets++; - tp->stats.rx_bytes += pkt_len; + entry = (++tp->cur_rx) % RX_RING_SIZE; + if (tp->cur_rx - tp->dirty_rx > RX_RING_SIZE/4) + tulip_refill_rx(dev); + } - received++; - entry = (++tp->cur_rx) % RX_RING_SIZE; - } -#ifdef CONFIG_NET_HW_FLOWCONTROL + + /* New ack strategy... irq does not ack Rx any longer + hopefully this helps */ + + /* Really bad things can happen here... If new packet arrives + * and an irq arrives (tx or just due to occasionally unset + * mask), it will be acked by irq handler, but new thread + * is not scheduled. It is major hole in design. + * No idea how to fix this if "playing with fire" will fail + * tomorrow (night 011029). If it will not fail, we won + * finally: amount of IO did not increase at all. */ + } while ((inl(dev->base_addr + CSR5) & RxIntr)); + +/* done: */ + +#ifdef USE_MITIGATION /* We use this simplistic scheme for IM. It's proven by real life installations. We can have IM enabled - continuesly but this would cause unnecessary latency. - Unfortunely we can't use all the NET_RX_* feedback here. - This would turn on IM for devices that is not contributing - to backlog congestion with unnecessary latency. + continuesly but this would cause unnecessary latency. + Unfortunely we can't use all the NET_RX_* feedback here. + This would turn on IM for devices that is not contributing + to backlog congestion with unnecessary latency. We monitor the the device RX-ring and have: HW Interrupt Mitigation either ON or OFF. - ON: More then 1 pkt received (per intr.) OR we are dropping + ON: More then 1 pkt received (per intr.) OR we are dropping OFF: Only 1 pkt received - + Note. We only use min and max (0, 15) settings from mit_table */ if( tp->flags & HAS_INTR_MITIGATION) { - if((received > 1 || mit_sel == NET_RX_DROP) - && tp->mit_sel != 15 ) { - tp->mit_sel = 15; - tp->mit_change = 1; /* Force IM change */ + if( received > 1 ) { + if( ! tp->mit_on ) { + tp->mit_on = 1; + outl(mit_table[MIT_TABLE], dev->base_addr + CSR11); + } } - if((received <= 1 && mit_sel != NET_RX_DROP) && tp->mit_sel != 0 ) { - tp->mit_sel = 0; - tp->mit_change = 1; /* Force IM change */ + else { + if( tp->mit_on ) { + tp->mit_on = 0; + outl(0, dev->base_addr + CSR11); + } } } - return RX_RING_SIZE+1; /* maxrx+1 */ -#else - return received; #endif + + dev->quota -= received; + *budget -= received; + + tulip_refill_rx(dev); + + /* If RX ring is not full we are out of memory. */ + if (tp->rx_buffers[tp->dirty_rx % RX_RING_SIZE].skb == NULL) goto oom; + +#ifdef EXTRA_STATS + if((inl(dev->base_addr + CSR5) & RxIntr)) tp->stats_poll_exit_done_rx_pending++; + tp->stats_poll_exit_done++; +#endif + + /* Remove us from polling list and enable RX intr. */ + + netif_rx_complete(dev); + outl(tulip_tbl[tp->chip_id].valid_intrs, dev->base_addr+CSR7); + + /* The last op happens after poll completion. Which means the following: + * 1. it can race with disabling irqs in irq handler + * 2. it can race with dise/enabling irqs in other poll threads + * 3. if an irq raised after beginning loop, it will be immediately + * triggered here. + * + * Summarizing: the logic results in some redundant irqs both + * due to races in masking and due to too late acking of already + * processed irqs. But it must not result in losing events. + */ + + return 0; + +not_done: + if (!received) { +#ifdef EXTRA_STATS + tp->stats_poll_zero_rx++; +#endif + /* received = dev->quota; Why existed? --Ben */ /* Not to happen */ + } + else { + dev->quota -= received; + *budget -= received; + } + + if (tp->cur_rx - tp->dirty_rx > RX_RING_SIZE/2 || + tp->rx_buffers[tp->dirty_rx % RX_RING_SIZE].skb == NULL) + tulip_refill_rx(dev); + + if (tp->rx_buffers[tp->dirty_rx % RX_RING_SIZE].skb == NULL) goto oom; + +#ifdef EXTRA_STATS + tp->stats_poll_exit_not_done++; +#endif + return 1; + + +oom: /* Executed with RX ints disabled */ + printk("ERROR: tulip: Hit OOM trying to refill rx buffer.\n"); + + /* Start timer, stop polling, but do not enable rx interrupts. */ + mod_timer(&tp->oom_timer, jiffies+1); + + /* Think: timer_pending() was an explicit signature of bug. + * Timer can be pending now but fired and completed + * before we did netif_rx_complete(). See? We would lose it. */ + + /* remove ourselves from the polling list */ + netif_rx_complete(dev); + +#ifdef EXTRA_STATS + tp->stats_poll_exit_oom++; +#endif + return 0; } static inline void phy_interrupt (struct net_device *dev) @@ -319,7 +425,6 @@ struct tulip_private *tp = (struct tulip_private *)dev->priv; long ioaddr = dev->base_addr; int csr5; - int entry; int missed; int rx = 0; int tx = 0; @@ -327,6 +432,7 @@ int maxrx = RX_RING_SIZE; int maxtx = TX_RING_SIZE; int maxoi = TX_RING_SIZE; + int rxd = 0; unsigned int work_count = tulip_max_interrupt_work; /* Let's see whether the interrupt really is for us */ @@ -341,21 +447,32 @@ tp->nir++; do { - /* Acknowledge all of the current interrupt sources ASAP. */ - outl(csr5 & 0x0001ffff, ioaddr + CSR5); +#ifdef EXTRA_STATS + if(!rxd) + record_interrupt_cause(dev, csr5); + else + record_interrupt_cause(dev, csr5& 0x0001ff3f); +#endif + if (!rxd && (csr5 & (RxIntr | RxNoBuf))) { + rxd++; + /* Mask RX intrs and add the device to poll list. */ + outl(tulip_tbl[tp->chip_id].valid_intrs&~RxPollInt, ioaddr + CSR7); + netif_rx_schedule(dev); + + if (!(csr5&~(AbnormalIntr|NormalIntr|RxPollInt|TPLnkPass))) + break; + } + + /* Acknowledge the interrupt sources we handle here ASAP + the poll function does Rx and RxNoBuf acking */ + + outl(csr5 & 0x0001ff3f, ioaddr + CSR5); + if (tulip_debug > 4) printk(KERN_DEBUG "%s: interrupt csr5=%#8.8x new csr5=%#8.8x.\n", - dev->name, csr5, inl(dev->base_addr + CSR5)); - - if (csr5 & (RxIntr | RxNoBuf)) { -#ifdef CONFIG_NET_HW_FLOWCONTROL - if ((!tp->fc_bit) || - (!test_bit(tp->fc_bit, &netdev_fc_xoff))) -#endif - rx += tulip_rx(dev); - tulip_refill_rx(dev); - } + dev->name, csr5, inl(dev->base_addr + CSR5)); + if (csr5 & (TxNoBuf | TxDied | TxIntr | TimerInt)) { unsigned int dirty_tx; @@ -457,15 +574,8 @@ } if (csr5 & RxDied) { /* Missed a Rx frame. */ tp->stats.rx_missed_errors += inl(ioaddr + CSR8) & 0xffff; -#ifdef CONFIG_NET_HW_FLOWCONTROL - if (tp->fc_bit && !test_bit(tp->fc_bit, &netdev_fc_xoff)) { - tp->stats.rx_errors++; - tulip_start_rxtx(tp); - } -#else tp->stats.rx_errors++; tulip_start_rxtx(tp); -#endif } /* * NB: t21142_lnk_change() does a del_timer_sync(), so be careful if this @@ -499,10 +609,6 @@ if (tulip_debug > 2) printk(KERN_ERR "%s: Re-enabling interrupts, %8.8x.\n", dev->name, csr5); -#ifdef CONFIG_NET_HW_FLOWCONTROL - if (tp->fc_bit && (test_bit(tp->fc_bit, &netdev_fc_xoff))) - if (net_ratelimit()) printk("BUG!! enabling interupt when FC off (timerintr.) \n"); -#endif outl(tulip_tbl[tp->chip_id].valid_intrs, ioaddr + CSR7); tp->ttimer = 0; oi++; @@ -515,11 +621,8 @@ /* Acknowledge all interrupt sources. */ outl(0x8001ffff, ioaddr + CSR5); if (tp->flags & HAS_INTR_MITIGATION) { -#ifdef CONFIG_NET_HW_FLOWCONTROL - if(tp->mit_change) { - outl(mit_table[tp->mit_sel], ioaddr + CSR11); - tp->mit_change = 0; - } +#ifdef USE_MITIGATION + outl(mit_table[MIT_TABLE], ioaddr + CSR11); #else /* Josip Loncaric at ICASE did extensive experimentation to develop a good interrupt mitigation setting.*/ @@ -532,10 +635,8 @@ } else { /* Mask all interrupting sources, set timer to re-enable. */ -#ifndef CONFIG_NET_HW_FLOWCONTROL outl(((~csr5) & 0x0001ebef) | AbnormalIntr | TimerInt, ioaddr + CSR7); outl(0x0012, ioaddr + CSR11); -#endif } break; } @@ -545,30 +646,18 @@ break; csr5 = inl(ioaddr + CSR5); - } while ((csr5 & (NormalIntr|AbnormalIntr)) != 0); - - tulip_refill_rx(dev); - - /* check if the card is in suspend mode */ - entry = tp->dirty_rx % RX_RING_SIZE; - if (tp->rx_buffers[entry].skb == NULL) { - if (tulip_debug > 1) - printk(KERN_WARNING "%s: in rx suspend mode: (%lu) (tp->cur_rx = %u, ttimer = %d, rx = %d) go/stay in suspend mode\n", dev->name, tp->nir, tp->cur_rx, tp->ttimer, rx); - if (tp->chip_id == LC82C168) { - outl(0x00, ioaddr + CSR7); - mod_timer(&tp->timer, RUN_AT(HZ/50)); - } else { - if (tp->ttimer == 0 || (inl(ioaddr + CSR11) & 0xffff) == 0) { - if (tulip_debug > 1) - printk(KERN_WARNING "%s: in rx suspend mode: (%lu) set timer\n", dev->name, tp->nir); - outl(tulip_tbl[tp->chip_id].valid_intrs | TimerInt, - ioaddr + CSR7); - outl(TimerInt, ioaddr + CSR5); - outl(12, ioaddr + CSR11); - tp->ttimer = 1; - } - } - } + if (rxd) + csr5 &= ~RxPollInt; + } while ((csr5 & (TxNoBuf | + TxDied | + TxIntr | + TimerInt | + /* Abnormal intr. */ + RxDied | + TxFIFOUnderflow | + TxJabber | + TPLnkFail | + SytemError )) != 0); if ((missed = inl(ioaddr + CSR8) & 0x1ffff)) { tp->stats.rx_dropped += missed & 0x10000 ? 0x10000 : missed; --- linux-2.4.19.p3/drivers/net/tulip/tulip_core.c Tue Nov 5 21:33:22 2002 +++ linux-2.4.19.p4/drivers/net/tulip/tulip_core.c Wed Nov 6 22:03:03 2002 @@ -1,4 +1,4 @@ -/* tulip_core.c: A DEC 21x4x-family ethernet driver for Linux. */ +/* -*-linux-c-*- tulip_core.c: A DEC 21x4x-family ethernet driver for Linux. */ /* Maintained by Jeff Garzik @@ -14,10 +14,6 @@ */ -#define DRV_NAME "tulip" -#define DRV_VERSION "0.9.15-pre12" -#define DRV_RELDATE "Aug 9, 2002" - #include #include #include "tulip.h" @@ -44,7 +40,7 @@ /* Maximum events (Rx packets, etc.) to handle at each interrupt. */ static unsigned int max_interrupt_work = 25; -#define MAX_UNITS 8 +#define MAX_UNITS 16 /* Used to pass the full-duplex flag, etc. */ static int full_duplex[MAX_UNITS]; static int options[MAX_UNITS]; @@ -105,6 +101,18 @@ /* Time in jiffies before concluding the transmitter is hung. */ #define TX_TIMEOUT (4*HZ) +/* Only used for SKB_RECYCLE, can't get it to #ifdef out on RH 7.3 */ +/* This is the maximum number of skbs per CPU that the driver will + * keep in it's recycle buffer list (per driver instance, ie per port). + * Each skb will cost you a little + * less than 2k, so if you have little memory and make this huge, bad + * things will happen. For 256MB machines running at very high speeds, + * 1024 or 2048 may be better. There seems to be no gain at higher + * values, at least on 100Mbps nics. + */ +static int skb_hotlist = 300; +MODULE_PARM(skb_hotlist, "i"); + MODULE_AUTHOR("The Linux Kernel Team"); MODULE_DESCRIPTION("Digital 21*4* Tulip ethernet driver"); @@ -494,29 +502,16 @@ to an alternate media type. */ tp->timer.expires = RUN_AT(next_tick); add_timer(&tp->timer); -} - -#ifdef CONFIG_NET_HW_FLOWCONTROL -/* Enable receiver */ -void tulip_xon(struct net_device *dev) -{ - struct tulip_private *tp = (struct tulip_private *)dev->priv; - clear_bit(tp->fc_bit, &netdev_fc_xoff); - if (netif_running(dev)){ - - tulip_refill_rx(dev); - outl(tulip_tbl[tp->chip_id].valid_intrs, dev->base_addr+CSR7); - } + init_timer(&tp->oom_timer); + tp->oom_timer.data = (unsigned long)dev; + tp->oom_timer.function = oom_timer; } -#endif + static int tulip_open(struct net_device *dev) { -#ifdef CONFIG_NET_HW_FLOWCONTROL - struct tulip_private *tp = (struct tulip_private *)dev->priv; -#endif int retval; MOD_INC_USE_COUNT; @@ -525,14 +520,23 @@ return retval; } - tulip_init_ring (dev); +#ifdef CONFIG_NET_SKB_RECYCLING + { + int i; + struct tulip_private *adapter = dev->priv; + for (i=0; itulip_recycle[i].list); + } + } +#endif + tulip_init_ring (dev); + tulip_up (dev); -#ifdef CONFIG_NET_HW_FLOWCONTROL - tp->fc_bit = netdev_register_fc(dev, tulip_xon); -#endif - +#ifdef EXTRA_STATS + tulip_open_misc(dev); +#endif netif_start_queue (dev); return 0; @@ -640,10 +644,7 @@ #endif /* Stop and restart the chip's Tx processes . */ -#ifdef CONFIG_NET_HW_FLOWCONTROL - if (tp->fc_bit && test_bit(tp->fc_bit,&netdev_fc_xoff)) - printk("BUG tx_timeout restarting rx when fc on\n"); -#endif + tulip_restart_rxtx(tp); /* Trigger an immediate transmit demand. */ outl(0, ioaddr + CSR1); @@ -719,6 +720,16 @@ spin_lock_irqsave(&tp->lock, eflags); + /* See if we can free slots on the output ring. In real life + examples we have seen between 2-10% of the slots cleared here */ + +#ifdef NOT_NOW +#ifdef EXTRA_STATS + tp->stats_tx_xmit_refilled += +#endif + tx_ring_free(dev); +#endif + /* Calculate the next Tx descriptor entry. */ entry = tp->cur_tx % TX_RING_SIZE; @@ -802,6 +813,7 @@ unsigned long flags; del_timer_sync (&tp->timer); + del_timer_sync (&tp->oom_timer); spin_lock_irqsave (&tp->lock, flags); @@ -845,15 +857,31 @@ netif_stop_queue (dev); -#ifdef CONFIG_NET_HW_FLOWCONTROL - if (tp->fc_bit) { - int bit = tp->fc_bit; - tp->fc_bit = 0; - netdev_unregister_fc(bit); - } +#ifdef tEXTRA_STATS + tulip_close_misc(dev); #endif tulip_down (dev); + /* Schedule while outstanding skb's exists */ + +#ifdef CONFIG_NET_SKB_RECYCLING + for (i=0; icnt[i]) { + current->state = TASK_INTERRUPTIBLE; + schedule_timeout(1); + } + } + + for (i=0; itulip_recycle[i].list; + while ((skb=skb_dequeue(list))!=NULL) { + skb->recycle_dev = NULL; + kfree_skb(skb); + } + } +#endif + if (tulip_debug > 1) printk (KERN_DEBUG "%s: Shutting down ethercard, status was %2.2x.\n", dev->name, inl (ioaddr + CSR5)); @@ -1717,6 +1745,8 @@ dev->hard_start_xmit = tulip_start_xmit; dev->tx_timeout = tulip_tx_timeout; dev->watchdog_timeo = TX_TIMEOUT; + dev->poll = tulip_poll; + dev->weight = 64; dev->stop = tulip_close; dev->get_stats = tulip_get_stats; dev->do_ioctl = private_ioctl; @@ -1811,6 +1841,9 @@ /* put the chip in snooze mode until opened */ tulip_set_power_state (tp, 0, 1); +#ifdef EXTRA_STATS + tulip_init_one_misc(dev); +#endif return 0; err_out_free_ring: @@ -1876,6 +1909,10 @@ if (!dev) return; +#ifdef EXTRA_STATS + tulip_remove_one_misc(dev); +#endif + tp = dev->priv; pci_free_consistent (pdev, sizeof (struct tulip_rx_desc) * RX_RING_SIZE + @@ -1895,6 +1932,36 @@ } + + +#ifdef CONFIG_NET_SKB_RECYCLING + +int tulip_recycle(struct sk_buff *skb) +{ + struct tulip_private *adapter = skb->recycle_dev->priv; + + /* Store for right CPU. For this we use skb->tag */ + struct sk_buff_head *list = &adapter->tulip_recycle[skb->tag].list; + + /* + decrease our outstanding skb's: + 1) either we store in the list OR + 2) we ignore so gets to kfree + */ + + adapter->cnt[smp_processor_id()]--; + + if (skb_queue_len(list) <= skb_hotlist) { + + /* LIFO queue for cache friendliness */ + skb_queue_head(list, skb); + return 1; + } + return 0; +} +#endif + + static struct pci_driver tulip_driver = { name: DRV_NAME, id_table: tulip_pci_tbl, --- linux-2.4.19.p3/drivers/net/tulip/tulip.h Tue Nov 5 21:33:22 2002 +++ linux-2.4.19.p4/drivers/net/tulip/tulip.h Wed Nov 6 22:28:21 2002 @@ -16,6 +16,11 @@ #ifndef __NET_TULIP_H__ #define __NET_TULIP_H__ +#define DRV_NAME "tulip" +#define DRV_VERSION "1.1.1-NAPI" +#define DRV_RELDATE "Feb 16, 2002" + + #include #include #include @@ -26,7 +31,12 @@ #include #include +#ifdef CONFIG_PROC_FS +#include +#endif +/* #define EXTRA_STATS 1 */ +#undef USE_MITIGATION /* undefine, or define to various debugging levels (>4 == obscene levels) */ #define TULIP_DEBUG 1 @@ -126,6 +136,7 @@ CFDD_Snooze = (1 << 30), }; +#define RxPollInt (RxIntr|RxNoBuf|RxDied|RxJabber) /* The bits in the CSR5 status registers, mostly interrupt sources. */ enum status_bits { @@ -261,8 +272,8 @@ Making the Tx ring too large decreases the effectiveness of channel bonding and packet priority. There are no ill effects from too-large receive rings. */ -#define TX_RING_SIZE 16 -#define RX_RING_SIZE 32 +#define TX_RING_SIZE 128 +#define RX_RING_SIZE 1024 #define MEDIA_MASK 31 @@ -351,8 +362,45 @@ int chip_id; int revision; int flags; + int mit_on; struct net_device_stats stats; +#ifdef EXTRA_STATS + unsigned long stats_tx_xmit_refilled; /* Pkts xmit-filled */ + unsigned long stats_tx_irq_refilled; /* Pktss irq-filled*/ + unsigned long stats_poll_starts; + unsigned long stats_poll_pkts; +#ifdef USE_MITIGATION + unsigned long stats_poll_pkts_mit; +#endif + unsigned long stats_poll_exit_done; + unsigned long stats_poll_exit_not_done; + unsigned long stats_poll_exit_oom; + unsigned long stats_poll_exit_done_rx_pending; + unsigned long stats_poll_zero_rx; +#ifdef CONFIG_PROC_FS + struct proc_dir_entry *proc_ent; + char proc_ent_name[32]; +#endif + /*Tulip interrupts causes */ + unsigned long stats_intr_normal; + unsigned long stats_intr_abnormal; + unsigned long stats_intr_timer; + + unsigned long stats_intr_rx; + unsigned long stats_intr_rx_nobuf; + unsigned long stats_intr_rx_died; + unsigned long stats_intr_rx_jabber; + + unsigned long stats_intr_tx; + unsigned long stats_intr_tx_died; + unsigned long stats_intr_tx_nobuf; + unsigned long rx_small_skb_failure; + unsigned long stats_intr_TPLnkPass; + unsigned long open_time; /* jiffies for last open */ + +#endif /* EXTRA_STATS */ struct timer_list timer; /* Media selection timer. */ + struct timer_list oom_timer; /* Out of memory timer. */ u32 mc_filter[2]; spinlock_t lock; spinlock_t mii_lock; @@ -391,6 +439,15 @@ unsigned long base_addr; int csr12_shadow; int pad0; /* Used for 8-byte alignment */ + +#ifdef CONFIG_NET_SKB_RECYCLING + unsigned int cnt[NR_CPUS]; + + union { + struct sk_buff_head list; + char pad[SMP_CACHE_BYTES]; + } tulip_recycle[NR_CPUS]; +#endif }; @@ -424,6 +481,7 @@ extern unsigned int tulip_max_interrupt_work; extern int tulip_rx_copybreak; void tulip_interrupt(int irq, void *dev_instance, struct pt_regs *regs); +int tulip_poll(struct net_device *dev, int *budget); int tulip_refill_rx(struct net_device *dev); /* media.c */ @@ -448,11 +506,22 @@ extern const char * const medianame[]; extern const char tulip_media_cap[]; extern struct tulip_chip_table tulip_tbl[]; +void oom_timer(unsigned long data); extern u8 t21040_csr13[]; extern u16 t21041_csr13[]; extern u16 t21041_csr14[]; extern u16 t21041_csr15[]; +/* tulip_misc.c */ +#ifdef EXTRA_STATS +void tulip_init_one_misc(struct net_device *dev); +void tulip_remove_one_misc (struct net_device *dev); +void tulip_open_misc(struct net_device *dev); +void tulip_close_misc(struct net_device *dev); +void ave_get(unsigned long arg); +void record_interrupt_cause( struct net_device *dev, int csr5); +#endif + #ifndef USE_IO_OPS #undef inb #undef inw @@ -498,3 +567,6 @@ } #endif /* __NET_TULIP_H__ */ + + + --------------080602000200060108030909-- From zjp@iscas.ac.cn Wed Nov 6 23:31:17 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Nov 2002 23:31:22 -0800 (PST) Received: from mail.iscas.ac.cn ([159.226.5.56]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA77VFuR011763 for ; Wed, 6 Nov 2002 23:31:16 -0800 Received: (qmail 9299 invoked by uid 104); 7 Nov 2002 07:32:50 -0000 Received: from zjp@iscas.ac.cn by mail.iscas.ac.cn by uid 0 with qmail-scanner-1.14 (hbedv: 6.15.0.1. hbedv: operating system: Linux (glibc). hbedv: product version: 2.0.4. hbedv: engine version: 6.15.0.1. hbedv: packlib version: 2.0.0.8 (supports 19 formats). hbedv: vdf version: 6.15.0.7 (66928 recognized forms). hbedv: . hbedv: product: AntiVir Workstation. hbedv: key file: hbedv.key. hbedv: registered user: irene, 123. hbedv: serial number: 1001020203. hbedv: key expires: 31 May 2003. hbedv: run mode: PRIVATE. hbedv: . hbedv: product: AntiVir MailGate. hbedv: key file: hbedv.key. hbedv: registered user: irene, 123. hbedv: serial number: 1001020203. hbedv: key expires: 31 May 2003. hbedv: run mode: PRIVATE. hbedv: . hbedv: product: AntiVir (command line scanner). hbedv: key file: hbedv.key. hbedv: registered user: irene, 123. hbedv: serial number: 1001020203. hbedv: key expires: 31 May 2003. hbedv: run mode: PRIVATE. Clear:. Processed in 0.214038 secs); 07 Nov 2002 07:32:50 -0000 Received: from unknown (HELO zhengjp) (zjp@192.168.6.108) by mail.iscas.ac.cn with SMTP; 7 Nov 2002 07:32:50 -0000 Message-ID: <007601c28630$176125b0$6c06a8c0@zhengjp> From: "Zheng Jianping" To: "Pekka Savola" Cc: References: Subject: Re: how ipv6 support multicast routing Date: Thu, 7 Nov 2002 15:34:22 +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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-archive-position: 1109 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zjp@iscas.ac.cn Precedence: bulk X-list: netdev ----- Original Message ----- From: "Pekka Savola" To: "Zheng Jianping" Cc: Sent: Thursday, November 07, 2002 2:45 PM Subject: Re: how ipv6 support multicast routing > have you looked at ip6_input.c/ip6_output.c already? There's an > (obsolete) ip6_mc_input function there, perhaps it might get you started. > I recall usagi have made some minor modifications to it too, but I doubt > it works. Yes, I've looked at these files and did find ip6_mc_input function. I add the following code to ip6_mc_input #ifdef (CONFIG_IP6_MROUTE) int addr_type; addr_type = ipv6_addr_type(&hdr->daddr); if (!(addr_type & (IPV6_ADDR_LOOPBACK | IPV6_ADDR_LINKLOCAL))) { ip6_mr_input(skb); /*defined in my 'ip6_mroute.c'*/ } #endif But I don't knwo how to modify the functions in net/ip6/route.c, such as ip6_route_input ip6_route_output and the funciton in net/ip6/ip6_output.c ip6_output > (I'd like to see PIM-SM work myself too.) Is there somebody else doing the work of IPv6 multicast forwarding in Linux? Thanks, Zheng From buytenh@gnu.org Thu Nov 7 01:30:58 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Nov 2002 01:31:02 -0800 (PST) Received: from fencepost.gnu.org (fencepost.gnu.org [199.232.76.164]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA79UvuR012989 for ; Thu, 7 Nov 2002 01:30:57 -0800 Received: from buytenh by fencepost.gnu.org with local (Exim 4.10) id 189j1E-0008BX-00 for netdev@oss.sgi.com; Thu, 07 Nov 2002 04:32:08 -0500 Date: Thu, 7 Nov 2002 04:32:08 -0500 To: netdev@oss.sgi.com Subject: [PATCH,RFC] explicit connection confirmation Message-ID: <20021107093207.GA30666@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: Lennert Buytenhek X-archive-position: 1110 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@gnu.org Precedence: bulk X-list: netdev (please CC on replies, I am not on this list) Hi, This patch gives userland the ability to decide whether to react with an incoming TCP SYN with a SYN-ACK or a RST. It was hacked up after Linux Kongress 2001 and has been sitting on my patch pile since april this year or something. The basic idea is this: - Put the listening TCP socket in TCP_CONFIRM_CONNECT mode. - Sockets returned from accept() on this socket after this will be sockets in the SYN_RECV state instead of the ESTABLISHED state (unless syncookies had to be used). By writing to the socket, you cause a SYN-ACK to be sent, and by immediately closing the socket you cause a RST to be sent. There are two issues left, AFAICS: - SYN_RECV sockets currently don't time out for some reason - it deadlocks instantly on SMP It's against 2.4.18. Could someone have a look at it please? I unfortunately haven't had any time at all lately, so I would be really happy if someone else could take this over. (Well, I can dream, can't I?) cheers, Lennert --- linux-2.4.18-11umpr/include/linux/tcp.h.orig Thu Nov 22 20:47:11 2001 +++ linux-2.4.18-11umpr/include/linux/tcp.h Thu Apr 18 19:33:19 2002 @@ -127,6 +127,7 @@ #define TCP_WINDOW_CLAMP 10 /* Bound advertised window */ #define TCP_INFO 11 /* Information about this connection. */ #define TCP_QUICKACK 12 /* Block/reenable quick acks */ +#define TCP_CONFIRM_CONNECT 13 /* Let user control connection acceptance */ #define TCPI_OPT_TIMESTAMPS 1 #define TCPI_OPT_SACK 2 --- linux-2.4.18-11umpr/include/net/sock.h.orig Fri Dec 21 18:42:04 2001 +++ linux-2.4.18-11umpr/include/net/sock.h Thu Apr 18 19:37:52 2002 @@ -302,6 +302,7 @@ __u8 reordering; /* Packet reordering metric. */ __u8 queue_shrunk; /* Write queue has been shrunk recently.*/ __u8 defer_accept; /* User waits for some data after accept() */ + __u8 confirm_connect;/* User wants control over conn. acceptance */ /* RTT measurement */ __u8 backoff; /* backoff */ @@ -411,6 +412,11 @@ struct open_request *accept_queue; struct open_request *accept_queue_tail; + /* Our corresponding open_request if this socket is unconfirmed + * (i.e. if we haven't sent SYN-ACK or RST yet) + */ + struct open_request *unconfirmed_openreq; + int write_pending; /* A write to socket waits to start. */ unsigned int keepalive_time; /* time before keep alive takes place */ --- linux-2.4.18-11umpr/include/net/tcp.h.orig Thu Nov 22 20:47:22 2001 +++ linux-2.4.18-11umpr/include/net/tcp.h Fri Apr 19 10:42:51 2002 @@ -505,7 +505,8 @@ sack_ok : 1, wscale_ok : 1, ecn_ok : 1, - acked : 1; + acked : 1, + unconfirmed : 1; /* The following two fields can be easily recomputed I think -AK */ __u32 window_clamp; /* window clamp at creation time */ __u32 rcv_wnd; /* rcv_wnd offered first time */ @@ -533,6 +534,17 @@ tcp_openreq_fastfree(req); } +static inline int tcp_is_unconfirmed(struct tcp_opt *tp) +{ + struct open_request *req; + + req = tp->unconfirmed_openreq; + if (req != NULL && req->unconfirmed) + return 1; + + return 0; +} + #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) #define TCP_INET_FAMILY(fam) ((fam) == AF_INET) #else @@ -1661,6 +1673,7 @@ req->acked = 0; req->ecn_ok = 0; req->rmt_port = skb->h.th->source; + req->unconfirmed = 0; } #define TCP_MEM_QUANTUM ((int)PAGE_SIZE) --- linux-2.4.18-11umpr/net/ipv4/tcp.c.orig Fri Dec 21 18:42:05 2001 +++ linux-2.4.18-11umpr/net/ipv4/tcp.c Fri Apr 19 20:50:29 2002 @@ -204,6 +204,7 @@ * Andi Kleen : Make poll agree with SIGIO * Salvatore Sanfilippo : Support SO_LINGER with linger == 1 and * lingertime == 0 (RFC 793 ABORT Call) + * Lennert Buytenhek : Explicit connection confirmation * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License @@ -366,6 +367,15 @@ return sk->tp_pinfo.af_tcp.accept_queue ? (POLLIN | POLLRDNORM) : 0; } +static void tcp_confirm(struct sock *sk) +{ + struct tcp_opt *tp = &(sk->tp_pinfo.af_tcp); + struct open_request *req = tp->unconfirmed_openreq; + + req->unconfirmed = 0; + req->class->rtx_syn_ack(sk, req, NULL); +} + /* * Wait for a TCP event. * @@ -650,6 +660,9 @@ struct task_struct *tsk = current; DECLARE_WAITQUEUE(wait, tsk); + if (tcp_is_unconfirmed(tp)) + tcp_confirm(sk); + while((1 << sk->state) & ~(TCPF_ESTABLISHED | TCPF_CLOSE_WAIT)) { if(sk->err) return sock_error(sk); @@ -1814,7 +1827,7 @@ void tcp_close(struct sock *sk, long timeout) { struct sk_buff *skb; - int data_was_unread = 0; + int should_send_rst = 0; lock_sock(sk); sk->shutdown = SHUTDOWN_MASK; @@ -1834,12 +1847,19 @@ */ while((skb=__skb_dequeue(&sk->receive_queue))!=NULL) { u32 len = TCP_SKB_CB(skb)->end_seq - TCP_SKB_CB(skb)->seq - skb->h.th->fin; - data_was_unread += len; + should_send_rst += len; __kfree_skb(skb); } tcp_mem_reclaim(sk); + if (sk->tp_pinfo.af_tcp.unconfirmed_openreq != NULL) { + if (tcp_is_unconfirmed(&(sk->tp_pinfo.af_tcp))) + should_send_rst = 1; + tcp_openreq_free(sk->tp_pinfo.af_tcp.unconfirmed_openreq); + sk->tp_pinfo.af_tcp.unconfirmed_openreq = NULL; + } + /* As outlined in draft-ietf-tcpimpl-prob-03.txt, section * 3.10, we send a RST here because data was lost. To * witness the awful effects of the old behavior of always @@ -1849,7 +1869,7 @@ * the FTP client, wheee... Note: timeout is always zero * in such a case. */ - if(data_was_unread != 0) { + if(should_send_rst) { /* Unread data was tossed, zap the connection. */ NET_INC_STATS_USER(TCPAbortOnClose); tcp_set_state(sk, TCP_CLOSE); @@ -2026,6 +2046,11 @@ #endif } + if (tp->unconfirmed_openreq) { + tcp_openreq_free(tp->unconfirmed_openreq); + tp->unconfirmed_openreq = NULL; + } + sk->shutdown = 0; sk->done = 0; tp->srtt = 0; @@ -2139,8 +2164,10 @@ newsk = req->sk; tcp_acceptq_removed(sk); - tcp_openreq_fastfree(req); - BUG_TRAP(newsk->state != TCP_SYN_RECV); + if (newsk->tp_pinfo.af_tcp.unconfirmed_openreq == NULL) + tcp_openreq_fastfree(req); + BUG_TRAP(newsk->tp_pinfo.af_tcp.unconfirmed_openreq || + newsk->state != TCP_SYN_RECV); release_sock(sk); return newsk; @@ -2305,6 +2332,10 @@ } break; + case TCP_CONFIRM_CONNECT: + tp->confirm_connect = !!val; + break; + default: err = -ENOPROTOOPT; break; @@ -2429,6 +2460,9 @@ case TCP_QUICKACK: val = !tp->ack.pingpong; break; + case TCP_CONFIRM_CONNECT: + val = tp->confirm_connect || tcp_is_unconfirmed(tp); + break; default: return -ENOPROTOOPT; }; --- linux-2.4.18-11umpr/net/ipv4/tcp_input.c.orig Mon Feb 25 20:38:14 2002 +++ linux-2.4.18-11umpr/net/ipv4/tcp_input.c Fri Apr 19 10:52:27 2002 @@ -3749,6 +3749,11 @@ switch(sk->state) { case TCP_SYN_RECV: if (acceptable) { + if (tp->unconfirmed_openreq != NULL) { + tcp_openreq_free(tp->unconfirmed_openreq); + tp->unconfirmed_openreq = NULL; + } + tp->copied_seq = tp->rcv_nxt; mb(); tcp_set_state(sk, TCP_ESTABLISHED); --- linux-2.4.18-11umpr/net/ipv4/tcp_minisocks.c.orig Mon Oct 1 18:19:57 2001 +++ linux-2.4.18-11umpr/net/ipv4/tcp_minisocks.c Fri Apr 19 10:24:22 2002 @@ -696,6 +696,7 @@ tcp_init_wl(newtp, req->snt_isn, req->rcv_isn); newtp->retransmits = 0; + newtp->confirm_connect = 0; newtp->backoff = 0; newtp->srtt = 0; newtp->mdev = TCP_TIMEOUT_INIT; @@ -839,7 +840,8 @@ * Enforce "SYN-ACK" according to figure 8, figure 6 * of RFC793, fixed by RFC1122. */ - req->class->rtx_syn_ack(sk, req, NULL); + if (!req->unconfirmed) + req->class->rtx_syn_ack(sk, req, NULL); return NULL; } @@ -864,7 +866,7 @@ if (paws_reject || !tcp_in_window(TCP_SKB_CB(skb)->seq, TCP_SKB_CB(skb)->end_seq, req->rcv_isn+1, req->rcv_isn+1+req->rcv_wnd)) { /* Out of window: send ACK and drop. */ - if (!(flg & TCP_FLAG_RST)) + if (!req->unconfirmed && !(flg & TCP_FLAG_RST)) req->class->send_ack(skb, req); if (paws_reject) NET_INC_STATS_BH(PAWSEstabRejected); @@ -907,6 +909,12 @@ return NULL; } + /* @@@ If we are in SYN_RECV and haven't confirmed/rejected + * the connection yet, this ACK is acking a never-sent packet. + */ + if (tcp_is_unconfirmed(tp)) + return NULL; + /* OK, ACK is valid, create big socket and * feed this segment to it. It will repeat all * the tests. THIS SEGMENT MUST MOVE SOCKET TO --- linux-2.4.18-11umpr/net/ipv4/tcp_ipv4.c.orig Mon Feb 25 20:38:14 2002 +++ linux-2.4.18-11umpr/net/ipv4/tcp_ipv4.c Fri Apr 19 18:56:45 2002 @@ -1270,12 +1270,14 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb) { + struct tcp_opt *master_tp = &(sk->tp_pinfo.af_tcp); struct tcp_opt tp; struct open_request *req; __u32 saddr = skb->nh.iph->saddr; __u32 daddr = skb->nh.iph->daddr; __u32 isn = TCP_SKB_CB(skb)->when; struct dst_entry *dst = NULL; + int dont_confirm = 0; #ifdef CONFIG_SYN_COOKIES int want_cookie = 0; #else @@ -1312,6 +1314,9 @@ if (req == NULL) goto drop; + if (!want_cookie && master_tp->confirm_connect) + dont_confirm = 1; + tcp_clear_options(&tp); tp.mss_clamp = 536; tp.user_mss = sk->tp_pinfo.af_tcp.user_mss; @@ -1396,11 +1401,31 @@ } req->snt_isn = isn; - if (tcp_v4_send_synack(sk, req, dst)) + if (!dont_confirm && tcp_v4_send_synack(sk, req, dst)) goto drop_and_free; if (want_cookie) { tcp_openreq_free(req); + } else if (dont_confirm) { + struct sock *child; + __u8 rcv_wscale; + + req->window_clamp = dst?dst->window:0; + tcp_select_initial_window(tcp_full_space(sk), req->mss, + &req->rcv_wnd, &req->window_clamp, + 0, &rcv_wscale); + req->rcv_wscale = rcv_wscale; + + child = tcp_v4_syn_recv_sock(sk, skb, req, NULL); + if (child != NULL) { + req->unconfirmed = 1; + child->tp_pinfo.af_tcp.unconfirmed_openreq = req; + tcp_acceptq_queue(sk, req, child); + sk->data_ready(sk, 0); + sock_put(child); + } else { + tcp_openreq_free(req); + } } else { tcp_v4_synq_add(sk, req); } --- linux-2.4.18-11umpr/net/ipv4/tcp_timer.c.orig Mon Oct 1 18:19:57 2001 +++ linux-2.4.18-11umpr/net/ipv4/tcp_timer.c Thu Apr 18 19:49:06 2002 @@ -512,7 +512,8 @@ if ((long)(now - req->expires) >= 0) { if ((req->retrans < thresh || (req->acked && req->retrans < max_retries)) - && !req->class->rtx_syn_ack(sk, req, NULL)) { + && (req->unconfirmed || + !req->class->rtx_syn_ack(sk, req, NULL))) { unsigned long timeo; if (req->retrans++ == 0) --- linux-2.4.18-11umpr/net/ipv4/af_inet.c.orig Fri Dec 21 18:42:05 2001 +++ linux-2.4.18-11umpr/net/ipv4/af_inet.c Wed Apr 17 20:45:06 2002 @@ -693,7 +693,7 @@ lock_sock(sk2); - BUG_TRAP((1<state)&(TCPF_ESTABLISHED|TCPF_CLOSE_WAIT|TCPF_CLOSE)); + BUG_TRAP((1<state)&(TCPF_SYN_RECV|TCPF_ESTABLISHED|TCPF_CLOSE_WAIT|TCPF_CLOSE)); sock_graft(sk2, newsock); From ahu@outpost.ds9a.nl Thu Nov 7 04:04:14 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Nov 2002 04:04:19 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7C43uR019536 for ; Thu, 7 Nov 2002 04:04:03 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 9F31E3FC4; Thu, 7 Nov 2002 12:27:33 +0100 (CET) Date: Thu, 7 Nov 2002 12:27:33 +0100 From: bert hubert To: Lennert Buytenhek Cc: netdev@oss.sgi.com Subject: Re: [PATCH,RFC] explicit connection confirmation Message-ID: <20021107112733.GA24283@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Lennert Buytenhek , netdev@oss.sgi.com References: <20021107093207.GA30666@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021107093207.GA30666@gnu.org> User-Agent: Mutt/1.3.28i X-archive-position: 1111 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev On Thu, Nov 07, 2002 at 04:32:08AM -0500, Lennert Buytenhek wrote: > - Sockets returned from accept() on this socket after this will be > sockets in the SYN_RECV state instead of the ESTABLISHED state > (unless syncookies had to be used). By writing to the socket, > you cause a SYN-ACK to be sent, and by immediately closing the > socket you cause a RST to be sent. And reading, like a webserver would do? I think this approach smells, btw - doesn't this mean that processes will now be woken up on receiving a SYN instead of after completion of the handshake? Would make a synflood all the more interesting.. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From buytenh@gnu.org Thu Nov 7 04:08:52 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Nov 2002 04:08:54 -0800 (PST) Received: from fencepost.gnu.org (fencepost.gnu.org [199.232.76.164]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7C8muR019987 for ; Thu, 7 Nov 2002 04:08:50 -0800 Received: from buytenh by fencepost.gnu.org with local (Exim 4.10) id 189lTw-0002yv-00; Thu, 07 Nov 2002 07:09:56 -0500 Date: Thu, 7 Nov 2002 07:09:56 -0500 To: bert hubert , netdev@oss.sgi.com Subject: Re: [PATCH,RFC] explicit connection confirmation Message-ID: <20021107120956.GA10832@gnu.org> References: <20021107093207.GA30666@gnu.org> <20021107112733.GA24283@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021107112733.GA24283@outpost.ds9a.nl> User-Agent: Mutt/1.3.28i From: Lennert Buytenhek X-archive-position: 1112 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@gnu.org Precedence: bulk X-list: netdev On Thu, Nov 07, 2002 at 12:27:33PM +0100, bert hubert wrote: > > - Sockets returned from accept() on this socket after this will be > > sockets in the SYN_RECV state instead of the ESTABLISHED state > > (unless syncookies had to be used). By writing to the socket, > > you cause a SYN-ACK to be sent, and by immediately closing the > > socket you cause a RST to be sent. > > And reading, like a webserver would do? Will do nothing, but this can easily be changed. I remind you of the fact that this option has to be explicitly enabled on a listening socket, so that apps have to be adapted to use the new interface anyway. > I think this approach smells, btw - doesn't this mean that processes > will now be woken up on receiving a SYN instead of after completion > of the handshake? Yes, it does mean this. You are free to suggest alternatives. > Would make a synflood all the more interesting.. In case of a synflood, the TCP stack will fall back to sending syncookies as it normally does. cheers, Lennert From hadi@cyberus.ca Thu Nov 7 04:55:20 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Nov 2002 04:55:26 -0800 (PST) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7CtJuR020637 for ; Thu, 7 Nov 2002 04:55:20 -0800 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id HAA06728; Thu, 7 Nov 2002 07:56:30 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id gA7Cmo511304; Thu, 7 Nov 2002 07:48:50 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Thu, 7 Nov 2002 07:48:49 -0500 (EST) From: jamal To: Robert Olsson cc: Ben Greear , "'netdev@oss.sgi.com'" , Jeff Garzik Subject: Re: NAPI-ized tulip patch against 2.4.20-rc1 In-Reply-To: <15817.21170.173913.829498@robur.slu.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1113 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 Wed, 6 Nov 2002, Robert Olsson wrote: > > Well skb recycling is "research" and should be used to challange to vm/slab > people to start with... And I guess you will get objections about the extra > stats as well. It's ok for syncing with current kernel driver i suppose. The patch that should be considered for merging really is: http://www.cyberus.ca/~hadi/patches/tulip-2419-napi-nifd.gz which looks suspiciouly similar to his patch if you remove the experimental stuff. > > I see you increased the RX-ring to 1024 pkts. > Did you really see any improvement with this? > > Also I would be interested if you have any numbers for recycling patch? > > Jamal and I spent some days after OLS to test and tune but it wasn't to > promising at that time but it's reworked now. > I think the numbers we saw were upto 20% increase with uniprocessor (AMD 1Gig) and about 5% increase with dual SMP(PII-450s). In the case of SMP, we concluded that the slab was screwing us. In any case, this WIP ... cheers, jamal From hadi@cyberus.ca Thu Nov 7 05:03:36 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Nov 2002 05:03:40 -0800 (PST) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7D3ZuR021073 for ; Thu, 7 Nov 2002 05:03:35 -0800 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id IAA08782; Thu, 7 Nov 2002 08:04:47 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id gA7CvBq11327; Thu, 7 Nov 2002 07:57:11 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Thu, 7 Nov 2002 07:57:11 -0500 (EST) From: jamal To: Donald Becker cc: Ben Greear , "'netdev@oss.sgi.com'" Subject: Re: NAPI-ized tulip patch against 2.4.20-rc1 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1114 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 Wed, 6 Nov 2002, Donald Becker wrote: > I can see that changing the parameters is a quick, ad hoc solution. > This list should focus on identifying the problems, rather than just > patching in work-arounds. > Well said. Tuning the receive ring is still a mystery; what i have noticed is that depending on the number of NICs on the system, the most optimal value varies. Typically, extremely large or small values are bad. cheers, jamal From hadi@cyberus.ca Thu Nov 7 05:31:05 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Nov 2002 05:31:09 -0800 (PST) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7DV5uR022592 for ; Thu, 7 Nov 2002 05:31:05 -0800 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id IAA16949; Thu, 7 Nov 2002 08:32:17 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id gA7DOfl11414; Thu, 7 Nov 2002 08:24:41 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Thu, 7 Nov 2002 08:24:41 -0500 (EST) From: jamal To: Ben Greear cc: Donald Becker , "'netdev@oss.sgi.com'" Subject: Re: NAPI-ized tulip patch against 2.4.20-rc1 In-Reply-To: <3DCA1152.7040002@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1115 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 Wed, 6 Nov 2002, Ben Greear wrote: > > Here's an update of the tulip-NAPI and skb-recycle patches. I made some > changes to get it to compile and work when the RECYCLE define in skbuff.h > was not enabled. > > I also got some test runs in. Nothing really conclusive. > > Test setup: Phobos 4-port NIC in each P-IV 1.8Ghz machine 32/33 PCI bus. > Kernel 2.4.20-rc1 + my patches. NICs connected to each other over CX cables. > Sending 4k 1514 byte packets per second, send + receive. (48Mbps or so) > RX ring size is 1024 for all of these tests. No significant errors reported > by the driver. I don't know where these dropped packets go..no counter > seems to be catching them. > > I sent 1 million packets (or very close to that) on every interface (received > the same, mostly) > > Without SKB-Recycle: > dropped 339 out of 1Million, repeated test twice, numbers very similar. > When packets do drop, they drop on all interfaces in bursts of 10-150, generally. > Latency was about .3ms > > With SKB-Recycle (300 pkt hot-list) > dropped 230, 500, and 180 in consecutive runs. They also drop in bursts. > The middle run may be bad luck...don't know. > Latency was about .3ms > While typing, I ran a longer test. Dropped about 1600 out of 4 million. > Trash the machines harder. Try using smaller packets; cheers, jamal From hadi@cyberus.ca Thu Nov 7 05:42:56 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Nov 2002 05:42:57 -0800 (PST) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7DgtuR025183 for ; Thu, 7 Nov 2002 05:42:56 -0800 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id IAA21065; Thu, 7 Nov 2002 08:44:04 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id gA7DaSZ11461; Thu, 7 Nov 2002 08:36:28 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Thu, 7 Nov 2002 08:36:28 -0500 (EST) From: jamal To: Lennert Buytenhek cc: bert hubert , Subject: Re: [PATCH,RFC] explicit connection confirmation In-Reply-To: <20021107120956.GA10832@gnu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1116 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 Could you not have used netfilter for this? You have the app sending controls to add netfilter policies and delete them when not needed. cheers, jamal From jacky@jackyhsiao.idv.tw Thu Nov 7 06:02:58 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Nov 2002 06:03:05 -0800 (PST) Received: from dns.jackyhsiao.idv.tw (IDENT:AcZZT7MPfND07Ymfixa87KGWvU0Cy8LL@dns.jackyhsiao.idv.tw [61.64.89.65]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7E2uuR025730 for ; Thu, 7 Nov 2002 06:02:57 -0800 Received: from jackynotebook ([192.168.1.2]) by dns.jackyhsiao.idv.tw (8.11.6/8.11.6) with SMTP id gA7E4Vx03746 for ; Thu, 7 Nov 2002 22:04:31 +0800 From: "Jacky Hsiao" To: Subject: test Date: Thu, 7 Nov 2002 21:54:43 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="big5" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id gA7E2uuR025730 X-archive-position: 1117 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jacky@jackyhsiao.idv.tw Precedence: bulk X-list: netdev From ahu@outpost.ds9a.nl Thu Nov 7 06:17:38 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Nov 2002 06:17:39 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7EHRuR026247 for ; Thu, 7 Nov 2002 06:17:27 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 2AA5844E2; Thu, 7 Nov 2002 14:49:18 +0100 (CET) Date: Thu, 7 Nov 2002 14:49:18 +0100 From: bert hubert To: Lennert Buytenhek Cc: netdev@oss.sgi.com Subject: Re: [PATCH,RFC] explicit connection confirmation Message-ID: <20021107134918.GA28329@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Lennert Buytenhek , netdev@oss.sgi.com References: <20021107093207.GA30666@gnu.org> <20021107112733.GA24283@outpost.ds9a.nl> <20021107120956.GA10832@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021107120956.GA10832@gnu.org> User-Agent: Mutt/1.3.28i X-archive-position: 1118 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev On Thu, Nov 07, 2002 at 07:09:56AM -0500, Lennert Buytenhek wrote: > > I think this approach smells, btw - doesn't this mean that processes > > will now be woken up on receiving a SYN instead of after completion > > of the handshake? > > Yes, it does mean this. You are free to suggest alternatives. I like having this ability - I dislike offering it to an unsuspecting userspace. > > Would make a synflood all the more interesting.. > > In case of a synflood, the TCP stack will fall back to sending > syncookies as it normally does. Yes, but in your setup, a spoofable SYN packet will spawn a process for many daemons, unless they are modified to first try to read/write to the socket (which might block!) before forking/pthread_create()ing. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From buytenh@gnu.org Thu Nov 7 06:28:53 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Nov 2002 06:28:55 -0800 (PST) Received: from fencepost.gnu.org (fencepost.gnu.org [199.232.76.164]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7ESpuR027120 for ; Thu, 7 Nov 2002 06:28:52 -0800 Received: from buytenh by fencepost.gnu.org with local (Exim 4.10) id 189nfW-0006Yd-00; Thu, 07 Nov 2002 09:30:02 -0500 Date: Thu, 7 Nov 2002 09:30:02 -0500 To: bert hubert , netdev@oss.sgi.com Subject: Re: [PATCH,RFC] explicit connection confirmation Message-ID: <20021107143002.GA23858@gnu.org> References: <20021107093207.GA30666@gnu.org> <20021107112733.GA24283@outpost.ds9a.nl> <20021107120956.GA10832@gnu.org> <20021107134918.GA28329@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021107134918.GA28329@outpost.ds9a.nl> User-Agent: Mutt/1.3.28i From: Lennert Buytenhek X-archive-position: 1119 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@gnu.org Precedence: bulk X-list: netdev On Thu, Nov 07, 2002 at 02:49:18PM +0100, bert hubert wrote: > > > I think this approach smells, btw - doesn't this mean that processes > > > will now be woken up on receiving a SYN instead of after completion > > > of the handshake? > > > > Yes, it does mean this. You are free to suggest alternatives. > > I like having this ability - I dislike offering it to an unsuspecting > userspace. Userspace needs to turn on the option first, so your 'unsuspecting' does not apply. > > > Would make a synflood all the more interesting.. > > > > In case of a synflood, the TCP stack will fall back to sending > > syncookies as it normally does. > > Yes, but in your setup, a spoofable SYN packet will spawn a process for many > daemons, unless they are modified to first try to read/write to the socket > (which might block!) before forking/pthread_create()ing. Again, if the app decides to turn on TCP_CONFIRM_CONNECT, then it's up to the app to deal with it properly. There are very good reasons for not turning on TCP_CONFIRM_CONNECT by default, which is why it is not on by default, and why grafting a setsockopt onto every daemon there is out there is definitely not a good idea. cheers, Lennert From buytenh@gnu.org Thu Nov 7 07:26:47 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Nov 2002 07:26:49 -0800 (PST) Received: from fencepost.gnu.org (fencepost.gnu.org [199.232.76.164]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7FQkuR029786 for ; Thu, 7 Nov 2002 07:26:47 -0800 Received: from buytenh by fencepost.gnu.org with local (Exim 4.10) id 189oZa-00006r-00; Thu, 07 Nov 2002 10:27:58 -0500 Date: Thu, 7 Nov 2002 10:27:58 -0500 To: jamal , Marc Boucher Cc: bert hubert , netdev@oss.sgi.com Subject: Re: [PATCH,RFC] explicit connection confirmation Message-ID: <20021107152758.GB23858@gnu.org> References: <20021107120956.GA10832@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: Lennert Buytenhek X-archive-position: 1120 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@gnu.org Precedence: bulk X-list: netdev Hi, netfilter, yeah, sure, 'could have', but please. 'Make it a netfilter module' is generally what people say when they are confronted with a feature they don't like. There was a thread about this in private mail round April this year, in which some good points were raised. - From the kernel point of view, doing it in netfilter would require more state tracking and access to the socket hashes and would be uglier. - From the application writer's point of view, doing it via a socket option is much more intuitive, since this flag is really a socket property, than doing it via some extra API which would make it way too difficult/complex to use in existing apps. It's worth noting that selective TCP connection acceptance was also intended to be implemented as a socket option by the original BSD developers. See http://www.kohala.com/start/vanj.94jun27.txt (link thanks to Marc Boucher). From the accept(2) man page on Red Hat Linux (again thanks to Marc Boucher): For certain protocols which require an explicit confirmation, such as DECNet, accept can be thought of as merely dequeuing the next connec- tion request and not implying confirmation. Confirmation can be implied by a normal read or write on the new file descriptor, and rejection can be implied by closing the new socket. Currently only DEC- Net has these semantics on Linux. cheers, Lennert On Thu, Nov 07, 2002 at 08:36:28AM -0500, jamal wrote: > Could you not have used netfilter for this? You have the app > sending controls to add netfilter policies and delete them when not > needed. > > cheers, > jamal > > > From ahu@outpost.ds9a.nl Thu Nov 7 09:04:13 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Nov 2002 09:04:19 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7H42uR031699 for ; Thu, 7 Nov 2002 09:04:03 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 5D3554106; Thu, 7 Nov 2002 17:24:24 +0100 (CET) Date: Thu, 7 Nov 2002 17:24:24 +0100 From: bert hubert To: Lennert Buytenhek Cc: netdev@oss.sgi.com Subject: Re: [PATCH,RFC] explicit connection confirmation Message-ID: <20021107162424.GA31447@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Lennert Buytenhek , netdev@oss.sgi.com References: <20021107093207.GA30666@gnu.org> <20021107112733.GA24283@outpost.ds9a.nl> <20021107120956.GA10832@gnu.org> <20021107134918.GA28329@outpost.ds9a.nl> <20021107143002.GA23858@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021107143002.GA23858@gnu.org> User-Agent: Mutt/1.3.28i X-archive-position: 1121 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev On Thu, Nov 07, 2002 at 09:30:02AM -0500, Lennert Buytenhek wrote: > > I like having this ability - I dislike offering it to an unsuspecting > > userspace. > > Userspace needs to turn on the option first, so your 'unsuspecting' > does not apply. Ah ok, I thought 'TCP_CONFIRM_CONNECT' was a TCP connection state like SYN_RECV. > Again, if the app decides to turn on TCP_CONFIRM_CONNECT, then it's > up to the app to deal with it properly. There are very good reasons > for not turning on TCP_CONFIRM_CONNECT by default, which is why it > is not on by default, and why grafting a setsockopt onto every daemon > there is out there is definitely not a good idea. Exactly. Ok, cool. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From blueflux@koffein.net Thu Nov 7 09:07:17 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Nov 2002 09:07:20 -0800 (PST) Received: from laptop1.agatha ([195.163.42.242]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7H7EuR032095 for ; Thu, 7 Nov 2002 09:07:16 -0800 Received: from localhost (blueflux@localhost) by laptop1.agatha (8.11.6/8.11.6) with ESMTP id gA7H0Zh05009; Thu, 7 Nov 2002 18:01:21 +0100 X-Authentication-Warning: laptop1.agatha: blueflux owned process doing -bs Date: Thu, 7 Nov 2002 18:00:35 +0100 (CET) From: Oskar Andreasson X-X-Sender: blueflux@laptop1.agatha To: "David S. Miller" , "Alexey N. Kuznetsov" cc: netdev@oss.sgi.com Subject: [PATCH] proc.txt document fix of error_burst and error_cost Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463810815-1804465649-1036688435=:5001" X-archive-position: 1122 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: blueflux@koffein.net 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. ---1463810815-1804465649-1036688435=:5001 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Jamal asked me to direct this patch to you both. In short, the patch fixes some bad documentation of the error_burst and error_cost sysctl's in Documentation/filesystems/proc.txt. I have tried to retain the old style of the document as much as possible, as well as choice of words. 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? -- ---- Oskar Andreasson http://www.frozentux.net http://iptables-tutorial.frozentux.net http://ipsysctl-tutorial.frozentux.net mailto:blueflux@koffein.net ---1463810815-1804465649-1036688435=:5001 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="2.4.19.docs.fs.proc.txt-2.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="2.4.19.docs.fs.proc.txt-2.patch" ZGlmZiAtdXIgbGludXgtMi40LjE5L0RvY3VtZW50YXRpb24vZmlsZXN5c3Rl bXMvcHJvYy50eHQgbGludXgtMi40LjE5Lm5ldy9Eb2N1bWVudGF0aW9uL2Zp bGVzeXN0ZW1zL3Byb2MudHh0DQotLS0gbGludXgtMi40LjE5L0RvY3VtZW50 YXRpb24vZmlsZXN5c3RlbXMvcHJvYy50eHQJV2VkIE5vdiAgNyAyMzozOToz NiAyMDAxDQorKysgbGludXgtMi40LjE5Lm5ldy9Eb2N1bWVudGF0aW9uL2Zp bGVzeXN0ZW1zL3Byb2MudHh0CVRodSBOb3YgIDcgMTc6Mzk6MjMgMjAwMg0K QEAgLTE1OTIsMTAgKzE1OTIsMTQgQEANCiBlcnJvcl9idXJzdCBhbmQgZXJy b3JfY29zdA0KIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogDQotVGhl c2UgcGFyYW1ldGVycyAgYXJlIHVzZWQgdG8gbGltaXQgdGhlIHdhcm5pbmcg bWVzc2FnZXMgd3JpdHRlbiB0byB0aGUga2VybmVsDQotbG9nIGZyb20gIHRo ZSAgcm91dGluZyAgY29kZS4gIFRoZSAgaGlnaGVyIHRoZSBlcnJvcl9jb3N0 IGZhY3RvciBpcywgdGhlIGZld2VyDQotbWVzc2FnZXMgd2lsbCAgYmUgd3Jp dHRlbi4gRXJyb3JfYnVyc3QgY29udHJvbHMgd2hlbiBtZXNzYWdlcyB3aWxs IGJlIGRyb3BwZWQuDQotVGhlIGRlZmF1bHQgc2V0dGluZ3MgbGltaXQgd2Fy bmluZyBtZXNzYWdlcyB0byBvbmUgZXZlcnkgZml2ZSBzZWNvbmRzLg0KK1Ro ZXNlICBwYXJhbWV0ZXJzICBhcmUgdXNlZCB0byBsaW1pdCBob3cgbWFueSBJ Q01QIGRlc3RpbmF0aW9uIHVucmVhY2hhYmxlIHRvIA0KK3NlbmQgIGZyb20g IHRoZSAgaG9zdCAgaW4gcXVlc3Rpb24uIElDTVAgZGVzdGluYXRpb24gdW5y ZWFjaGFibGUgbWVzc2FnZXMgYXJlIA0KK3NlbnQgIHdoZW4gIHdlIGNhbiBu b3QgcmVhY2ggdGhlIG5leHQgaG9wLCB3aGlsZSB0cnlpbmcgdG8gdHJhbnNt aXQgYSBwYWNrZXQuIA0KK0l0ICB3aWxsIGFsc28gcHJpbnQgc29tZSBlcnJv ciBtZXNzYWdlcyB0byBrZXJuZWwgbG9ncyBpZiBzb21lb25lIGlzIGlnbm9y aW5nIA0KK291ciAgIElDTVAgIHJlZGlyZWN0cy4gIFRoZSAgaGlnaGVyICB0 aGUgIGVycm9yX2Nvc3QgIGZhY3RvciAgaXMsICB0aGUgIGZld2VyIA0KK2Rl c3RpbmF0aW9uICB1bnJlYWNoYWJsZSAgYW5kIGVycm9yIG1lc3NhZ2VzIHdp bGwgYmUgbGV0IHRocm91Z2guIEVycm9yX2J1cnN0IA0KK2NvbnRyb2xzICB3 aGVuICBkZXN0aW5hdGlvbiAgdW5yZWFjaGFibGUgIG1lc3NhZ2VzIGFuZCBl cnJvciBtZXNzYWdlcyB3aWxsIGJlDQorZHJvcHBlZC4gVGhlIGRlZmF1bHQg c2V0dGluZ3MgbGltaXQgd2FybmluZyBtZXNzYWdlcyB0byBmaXZlIGV2ZXJ5 IHNlY29uZC4NCiANCiBmbHVzaA0KIC0tLS0tDQo= ---1463810815-1804465649-1036688435=:5001-- From greear@candelatech.com Thu Nov 7 10:16:10 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Nov 2002 10:16:12 -0800 (PST) Received: from grok.yi.org (IDENT:WpDytG4qB919wwqm5kSz1ZYW+5tRalzi@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7IG9uR007681 for ; Thu, 7 Nov 2002 10:16:10 -0800 Received: from localhost (greear@localhost) by grok.yi.org (8.11.6/8.11.2) with ESMTP id gA7IGpM32163; Thu, 7 Nov 2002 10:16:52 -0800 X-Authentication-Warning: grok.yi.org: greear owned process doing -bs Date: Thu, 7 Nov 2002 10:16:51 -0800 (PST) From: greear@candelatech.com X-X-Sender: greear@grok.yi.org To: jamal cc: Ben Greear , Donald Becker , "'netdev@oss.sgi.com'" Subject: Re: NAPI-ized tulip patch against 2.4.20-rc1 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1123 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greear@candelatech.com Precedence: bulk X-list: netdev On Thu, 7 Nov 2002, jamal wrote: > Trash the machines harder. Try using smaller packets; They are already dropping packets, I thought I'd try to get a slower run to work cleanly before trying something faster. Precision is more important to me than absolute throughput at this point. Initial run with 256 sized rx-ring (and skb-recycle) shows better performance (than with 1024 rx-ring) Sent 6-mil packets (same setup as before), dropped 750 or so. One NIC has dropped 2000 in one direction and 1325 in the other though... An over-night run with 1024 rx-ring passed 152mil packets, dropped 75k or so. Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From kennyus5@consultant.com Thu Nov 7 11:38:27 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Nov 2002 11:38:29 -0800 (PST) Received: from consultant.com ([208.227.137.26]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7JcHuR011269 for ; Thu, 7 Nov 2002 11:38:21 -0800 Message-Id: <200211071938.gA7JcHuR011269@oss.sgi.com> From: "Eseimoku K.Anderson(Chief)" To: Subject: Seeking Your Partnership Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 7 Nov 2002 20:43:11 +0100 Content-Transfer-Encoding: 8bit X-archive-position: 1124 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kennyus5@consultant.com Precedence: bulk X-list: netdev Dear Partner to be, First, I must apologise to you for using this medium to communicate to you about this project and It is my great pleasure in writing you this letter on behalf of my colleagues and myself. I am a highly placed official of Government of Nigeria and also a founding member of the ruling party in Power now,the Peoples Democratic Party(PDP). DESCRIPTION OF PROJECT:My committee - The Niger Delta Development Corporation(NDDC)-which is in charge of managing and supervising the disbursement of oil sales revenues for the Nigerian government which covers payment to foreign and local contractors,who had executed contracts for our country.The revenues under our control runs into several hundred of millions of dollars and using my position as Executive Director in charge of projects,I and other colleagues in the NDDC are currently in need of a foreign partner with whose bank account we shall transfer the sum of Forty Nine Million Five Hundred Thosand United States Dollars($49.5m). To do this, we will need your cooperation as a foreigner who could front to receive the fund on our behalf. SOURCE OF FUND: The amount represents a percentage of the total contract value executed on behalf of my ministry by a foreign contracting firm which we over-invoiced. Though the actual contract value has been paid to the original contractor, leaving a balance to the tune of the amount aforementioned, which we have in principle secured approval to remit by telegraphic transfer (T.T) to any bank account, you will provide. PROCEDURE: Since the present government of Nigeria is determined to pay every foreign contractor all debts owed so as to maintain good relationship with foreign governments and non-governmental financial agencies,however,by virtue of our position as civil servants and members of the NDDC, we cannot acquire this funds in our name. This is because as top civil servants, we are not allowed by law of the land to own or operate bank accounts outside our country for now. We have decided to include our bills for approval with the cooperation of some officials from the relevant government establishments. We are seeking your assistance in providing a good company's account or any other offshore bank account into which we can remit this money by acting as our main partner and trustee or acting as a sub contractor. This will involve the swapping of account; changing of beneficiary name;and other forms of documentation. I have the authority of my partners to propose that should you be willing to assist us in the transaction, your share of the sum will be 10% of the U$49.5million,80% for us while the balance will be set aside for refund of all expenses incurred during the process of the transaction. The transaction, although discrete, is legitimate and there is no risk or legal disadvantages either to ourselves or yourself now or in the future as we have put in place perfect mchineries that will ensure a hitch free transfer into your account upon acceptance. The transfer will be effected to your account within ten-fourteen (10-14) working days as soon as we reach an agreement and you furnish me with a suitable bank account and company name and address with all your contact numbers including fax number. Expecting your response and thank you for your cooperation. Sincerely, Anderson K. Eseimoku From Robert.Olsson@data.slu.se Thu Nov 7 13:17:03 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Nov 2002 13:17: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 gA7LH1uR015066 for ; Thu, 7 Nov 2002 13:17:02 -0800 Received: (from robert@localhost) by robur.slu.se (8.9.3/8.9.3) id WAA19214; Thu, 7 Nov 2002 22:26:04 +0100 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15818.55916.259489.688198@robur.slu.se> Date: Thu, 7 Nov 2002 22:26:04 +0100 To: greear@candelatech.com Cc: jamal , Ben Greear , Donald Becker , "'netdev@oss.sgi.com'" Subject: Re: NAPI-ized tulip patch against 2.4.20-rc1 In-Reply-To: References: X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 1125 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 greear@candelatech.com writes: > On Thu, 7 Nov 2002, jamal wrote: > > Trash the machines harder. Try using smaller packets; > > They are already dropping packets, I thought I'd try to get a slower run > to work cleanly before trying something faster. Precision is more > important to me than absolute throughput at this point. If you need excessive buffering this gives latency and jitter which is considered bad for network protocols and worse for test equipment. > Initial run with 256 sized rx-ring (and skb-recycle) shows better > performance (than with 1024 rx-ring) Packet size? Expect eventual effects when there is very high pressure on the packet memory system. Cheers. --ro From greearb@candelatech.com Thu Nov 7 13:24:54 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Nov 2002 13:24:56 -0800 (PST) Received: from grok.yi.org (IDENT:fCqcQqjfxyN8SCl1EaT0+J0B2Qd+x7cy@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7LOruR015528 for ; Thu, 7 Nov 2002 13:24:54 -0800 Received: from candelatech.com (IDENT:wvQ0mA7lzns8nGu5wZ9/Uw1rms6k/OOK@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id gA7LPsq23616; Thu, 7 Nov 2002 14:25:54 -0700 Message-ID: <3DCADA62.7000601@candelatech.com> Date: Thu, 07 Nov 2002 13:25:54 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Olsson CC: "'netdev@oss.sgi.com'" Subject: Re: NAPI-ized tulip patch against 2.4.20-rc1 References: <15818.55916.259489.688198@robur.slu.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1126 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 Robert Olsson wrote: > greear@candelatech.com writes: > > On Thu, 7 Nov 2002, jamal wrote: > > > Trash the machines harder. Try using smaller packets; > > > > They are already dropping packets, I thought I'd try to get a slower run > > to work cleanly before trying something faster. Precision is more > > important to me than absolute throughput at this point. > > > If you need excessive buffering this gives latency and jitter which is > considered bad for network protocols and worse for test equipment. It depends on the goals of the test, but I agree in principle :) > > > Initial run with 256 sized rx-ring (and skb-recycle) shows better > > performance (than with 1024 rx-ring) > > Packet size? Expect eventual effects when there is very high pressure on > the packet memory system. Packet size has been 1514 for all my recent tests. For an extended 256 rx-ring run (4kpps send + rcv, 1514 byte packet, 4 ports), I see about 9k dropped packets per 55 million sent & received. Ben > > > Cheers. > --ro > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From greearb@candelatech.com Thu Nov 7 15:28:43 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Nov 2002 15:28:48 -0800 (PST) Received: from grok.yi.org (IDENT:B/jTuNsKBNVIoLuh7HxedqL8+3QwgS0l@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7NSguR005336 for ; Thu, 7 Nov 2002 15:28:43 -0800 Received: from candelatech.com (IDENT:bwoTwTGHc4VhIrsRlJhjF76vq322EEkY@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id gA7NTkq10081; Thu, 7 Nov 2002 16:29:46 -0700 Message-ID: <3DCAF76A.9080409@candelatech.com> Date: Thu, 07 Nov 2002 15:29:46 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Donald Becker CC: "'netdev@oss.sgi.com'" Subject: Re: NAPI-ized tulip patch against 2.4.20-rc1 References: <3DCA1152.7040002@candelatech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1127 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 Ben Greear wrote: > > Here's an update of the tulip-NAPI and skb-recycle patches. I made some > changes to get it to compile and work when the RECYCLE define in skbuff.h > was not enabled. > > I also got some test runs in. Nothing really conclusive. > > Test setup: Phobos 4-port NIC in each P-IV 1.8Ghz machine 32/33 PCI bus. > Kernel 2.4.20-rc1 + my patches. NICs connected to each other over CX > cables. > Sending 4k 1514 byte packets per second, send + receive. (48Mbps or so) > RX ring size is 1024 for all of these tests. No significant errors > reported > by the driver. I don't know where these dropped packets go..no counter > seems to be catching them. I changed to use smaller packets 757 bytes long, and to send/receive twice as many (8kpps). Still running at 50Mbps or so. rx-ring is 256, still using skb-recycling with 300 skb hotlist. Out of 57 million sent, dropped about 24k packets. I also see about 3k of Rx-Drops on each interface. No other significant errors reported by the driver.... Any ideas for what to try next? What about upping the skb-hotlist to 1024 or so? Maybe also pre-load it with buffers to make it less likely we'll run low? (Rx-Drops means it could not allocate a buffer, right?) Enjoy, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From seong@etri.re.kr Fri Nov 8 01:07:36 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Nov 2002 01:07:42 -0800 (PST) Received: from cms1.etri.re.kr (cms1.etri.re.kr [129.254.16.11]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA897ZuR022733 for ; Fri, 8 Nov 2002 01:07:36 -0800 Received: from seong (seong1.etri.re.kr [129.254.171.33]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VZPSQKRX; Fri, 8 Nov 2002 18:01:29 +0900 Message-ID: <010101c28706$b1767840$21abfe81@seong> From: "Seong Moon" To: Subject: IPv6 development plan ? Date: Fri, 8 Nov 2002 18:10:23 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-archive-position: 1128 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: seong@etri.re.kr Precedence: bulk X-list: netdev Hi theres! I know that the kernel.org and the usagi have developed the IPv6 functionality seperately. The usagi says that the their product has applied the kernel.org partially. Why does not the original kernel apply the entire usagi patch ? And I want to know the master plan of development of IPv6 including IPv6 routing functions. Could I know the schedule or plan ? I read the Linux IPv6 HOWTO written by Peter Bieringer. He said that 2.6.x kernel series will contain a true and up-to-date IPv6 implementation. Approximately When can I use 2.6.x kernel ? TIA From ahu@outpost.ds9a.nl Fri Nov 8 02:00:52 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Nov 2002 02:00:57 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA8A0fuR023508 for ; Fri, 8 Nov 2002 02:00:42 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id E122545BE; Fri, 8 Nov 2002 10:22:05 +0100 (CET) Date: Fri, 8 Nov 2002 10:22:05 +0100 From: bert hubert To: Seong Moon Cc: netdev@oss.sgi.com Subject: Re: IPv6 development plan ? Message-ID: <20021108092205.GA16291@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Seong Moon , netdev@oss.sgi.com References: <010101c28706$b1767840$21abfe81@seong> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <010101c28706$b1767840$21abfe81@seong> User-Agent: Mutt/1.3.28i X-archive-position: 1129 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev On Fri, Nov 08, 2002 at 06:10:23PM +0900, Seong Moon wrote: > The usagi says that the their product has applied the kernel.org partially. > Why does not the original kernel apply the entire usagi patch ? Things take time. The kernel people have been accepting USAGI patches at a steady rate. DaveM and Alexey have been reworking routing quite a lot, USAGI does not apply cleanly to that. > And I want to know the master plan of development of IPv6 including IPv6 > routing functions. Could I know the schedule or plan ? "When the time is right". > He said that 2.6.x kernel series will contain a true and up-to-date IPv6 > implementation. > Approximately When can I use 2.6.x kernel ? I use it now, but you may not want to do that for mission critical systems. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From hadi@cyberus.ca Fri Nov 8 03:28:23 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Nov 2002 03:28:27 -0800 (PST) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA8BSMuR026085 for ; Fri, 8 Nov 2002 03:28:22 -0800 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id GAA14521; Fri, 8 Nov 2002 06:29:37 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id gA8BM0T14755; Fri, 8 Nov 2002 06:22:00 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Fri, 8 Nov 2002 06:22:00 -0500 (EST) From: jamal To: Lennert Buytenhek cc: Marc Boucher , bert hubert , Subject: Re: [PATCH,RFC] explicit connection confirmation In-Reply-To: <20021107152758.GB23858@gnu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1130 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 Thu, 7 Nov 2002, Lennert Buytenhek wrote: > Hi, > > netfilter, yeah, sure, 'could have', but please. apology if i sounded like one of those adolescent netfilter dangerous fools who show up with "mama, look what i can do with a packet now that ive read netfilter docs" > > 'Make it a netfilter module' is generally what people say when > they are confronted with a feature they don't like. My angle was to avoid being intrusive to the tcp code. you might get a fish sent to you in .nl in an armani suit;-> > > There was a thread about this in private mail round April this year, > in which some good points were raised. > There are some good points; however, whats the app for this feature? cheers, jamal From hadi@cyberus.ca Fri Nov 8 03:37:26 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Nov 2002 03:37:28 -0800 (PST) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA8BbPuR026505 for ; Fri, 8 Nov 2002 03:37:26 -0800 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id GAA16496; Fri, 8 Nov 2002 06:38:37 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id gA8BUrF14778; Fri, 8 Nov 2002 06:31:01 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Fri, 8 Nov 2002 06:30:53 -0500 (EST) From: jamal To: Ben Greear cc: Donald Becker , "'netdev@oss.sgi.com'" Subject: Re: NAPI-ized tulip patch against 2.4.20-rc1 In-Reply-To: <3DCAF76A.9080409@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1131 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 Thu, 7 Nov 2002, Ben Greear wrote: > Any ideas for what to try next? What about upping the skb-hotlist to > 1024 or so? Maybe also pre-load it with buffers to make it less likely we'll > run low? (Rx-Drops means it could not allocate a buffer, right?) > You seem to be using that patch of yours where you route to yourself? Well, since you are up for it: - try with two ports only; eth0->eth1 and vary then vary RX ring {32, 64,128,256,512,1024} - send at least 1 minute worth of data at wire rate a) small packets 64 bytes b) repeat with MTU sized packets Repeat above with eth0->eth1, eth2->eth3 also try where machine is a router and you have a source/sink host cheers, jamal From ahu@outpost.ds9a.nl Fri Nov 8 03:50:51 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Nov 2002 03:50:52 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA8BoouR026941 for ; Fri, 8 Nov 2002 03:50:50 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 87A884600; Fri, 8 Nov 2002 12:52:05 +0100 (CET) Date: Fri, 8 Nov 2002 12:52:05 +0100 From: bert hubert To: jamal Cc: Lennert Buytenhek , Marc Boucher , netdev@oss.sgi.com Subject: Re: [PATCH,RFC] explicit connection confirmation Message-ID: <20021108115205.GA20549@outpost.ds9a.nl> Mail-Followup-To: bert hubert , jamal , Lennert Buytenhek , Marc Boucher , netdev@oss.sgi.com References: <20021107152758.GB23858@gnu.org> 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: 1132 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev On Fri, Nov 08, 2002 at 06:22:00AM -0500, jamal wrote: > > There was a thread about this in private mail round April this year, > > in which some good points were raised. > > There are some good points; however, whats the app for this feature? This came up a long time ago on bugtraq in a discussion how to easily prevent certain IP addresses from DoSsing your TCP daemon. Right now, userspace is always forced to complete the threeway handshake, and can only then close the socket. Even rather small amounts of SYN packets can thus easily saturate a server which has decided to handle only 100 connections AND has decided to ignore a certain IP address. Some inetd superservers contain code to ratelimit IP addresses which sadly is not as effective from userspace as it could be with the ability to RST a connection immediately. It also allows userspace to simulate that a service isn't even there, without root capabilities. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From marc@mbsi.ca Fri Nov 8 03:55:13 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Nov 2002 03:55:14 -0800 (PST) Received: from valve.mbsi.ca (valve.mbsi.ca [198.168.101.14]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA8BtCuR027440 for ; Fri, 8 Nov 2002 03:55:12 -0800 Received: from endlich.mbsi.ca (endlich.mbsi.ca [198.168.101.5]) by valve.mbsi.ca with ESMTP id gA8Bu47G008018 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Fri, 8 Nov 2002 06:56:05 -0500 Received: from endlich.mbsi.ca (endlich.mbsi.ca [127.0.0.1]) by endlich.mbsi.ca with ESMTP id gA8Bu4R8009946 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 8 Nov 2002 06:56:04 -0500 Received: (from marc@localhost) by endlich.mbsi.ca (8.12.5/8.12.5/Submit) id gA8Bu3TH009945; Fri, 8 Nov 2002 06:56:03 -0500 Date: Fri, 8 Nov 2002 06:56:03 -0500 From: Marc Boucher To: bert hubert , jamal , Lennert Buytenhek , netdev@oss.sgi.com Subject: Re: [PATCH,RFC] explicit connection confirmation Message-ID: <20021108115603.GA9925@endlich.mbsi.ca> References: <20021107152758.GB23858@gnu.org> <20021108115205.GA20549@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021108115205.GA20549@outpost.ds9a.nl> User-Agent: Mutt/1.5.1i X-archive-position: 1133 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: marc@mbsi.ca Precedence: bulk X-list: netdev it would also be useful for transparent proxying. presently all connections diverted to a proxy are immediately accepted, regardless of whether the second connection (proxy->real destination) succeeds or not. On Fri, Nov 08, 2002 at 12:52:05PM +0100, bert hubert wrote: > On Fri, Nov 08, 2002 at 06:22:00AM -0500, jamal wrote: > > > > There was a thread about this in private mail round April this year, > > > in which some good points were raised. > > > > There are some good points; however, whats the app for this feature? > > This came up a long time ago on bugtraq in a discussion how to easily > prevent certain IP addresses from DoSsing your TCP daemon. Right now, > userspace is always forced to complete the threeway handshake, and can only > then close the socket. > > Even rather small amounts of SYN packets can thus easily saturate a server > which has decided to handle only 100 connections AND has decided to ignore a > certain IP address. Some inetd superservers contain code to ratelimit IP > addresses which sadly is not as effective from userspace as it could be with > the ability to RST a connection immediately. > > It also allows userspace to simulate that a service isn't even there, > without root capabilities. > > Regards, > > bert > > -- > http://www.PowerDNS.com Versatile DNS Software & Services > http://lartc.org Linux Advanced Routing & Traffic Control HOWTO > From greearb@candelatech.com Fri Nov 8 09:39:28 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Nov 2002 09:39:34 -0800 (PST) Received: from grok.yi.org (IDENT:qDcNCOXau/OOcj1rDHQNI5fiqUxsYjy1@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA8HdQuR013112 for ; Fri, 8 Nov 2002 09:39:27 -0800 Received: from candelatech.com (IDENT:2kog9cWpV8Q35pBoKq8qHnlkilnaJtaM@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id gA8HeAq28186; Fri, 8 Nov 2002 10:40:10 -0700 Message-ID: <3DCBF6FA.6040505@candelatech.com> Date: Fri, 08 Nov 2002 09:40:10 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jamal CC: Donald Becker , "'netdev@oss.sgi.com'" Subject: Re: NAPI-ized tulip patch against 2.4.20-rc1 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1134 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 jamal wrote: > > On Thu, 7 Nov 2002, Ben Greear wrote: > > >>Any ideas for what to try next? What about upping the skb-hotlist to >>1024 or so? Maybe also pre-load it with buffers to make it less likely we'll >>run low? (Rx-Drops means it could not allocate a buffer, right?) >> > > > You seem to be using that patch of yours where you route to yourself? I'm using pktgen for this to take as much of the stack out of the question as possible, and I'm using two machines for these latest tests. > Well, since you are up for it: > - try with two ports only; eth0->eth1 and vary then vary RX ring > {32, 64,128,256,512,1024} > - send at least 1 minute worth of data at wire rate Unfortunately, it seems I need 15 or 30 minutes to make an accurate judgement. For one reason or another, I drop bursts of packets every 2-5 minutes. > a) small packets 64 bytes > b) repeat with MTU sized packets I'll try some of those variations today. From more tweaking, it appears that a good skb_hotlist is around 1k, a good ring size is 512 (1024 is not much better, still dropping packets in small bursts), weight of 32 or 64 is good. It also seems that the max_work_at_interrupt setting in the tulip driver is irrelevant when using NAPI (weight trumps it)... I increased it above weight, it helped slightly I think. Found some more bugs in my skb-recycle patch, I had forgotten to use it for filling the ring. If anyone is interested in an updated patch, let me know. Otherwise, I'll save the bits :) With settings like these, I ran 294 million pkts, dropped about 90k (up to 150k on one interface). Had about 30k dropped packets, don't know where the other 60k went. > > Repeat above with eth0->eth1, eth2->eth3 > > also try where machine is a router and you have a source/sink host I'm trying to keep the stacks out of it for now...but can do that test later... > > cheers, > jamal Thanks for the suggestions! Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From buytenh@gnu.org Fri Nov 8 10:26:53 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Nov 2002 10:26:55 -0800 (PST) Received: from fencepost.gnu.org (fencepost.gnu.org [199.232.76.164]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA8IQquR014241 for ; Fri, 8 Nov 2002 10:26:53 -0800 Received: from buytenh by fencepost.gnu.org with local (Exim 4.10) id 18ADrP-0007mT-00; Fri, 08 Nov 2002 13:28:03 -0500 Date: Fri, 8 Nov 2002 13:28:03 -0500 To: jamal Cc: Marc Boucher , bert hubert , netdev@oss.sgi.com Subject: Re: [PATCH,RFC] explicit connection confirmation Message-ID: <20021108182803.GA27346@gnu.org> References: <20021107152758.GB23858@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: Lennert Buytenhek X-archive-position: 1135 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@gnu.org Precedence: bulk X-list: netdev On Fri, Nov 08, 2002 at 06:22:00AM -0500, jamal wrote: > > netfilter, yeah, sure, 'could have', but please. > > apology if i sounded like one of those adolescent netfilter dangerous > fools who show up with "mama, look what i can do with a packet now that > ive read netfilter docs" No, you don't sound such, sorry for reacting the way i did. > > 'Make it a netfilter module' is generally what people say when > > they are confronted with a feature they don't like. > > My angle was to avoid being intrusive to the tcp code. > you might get a fish sent to you in .nl in an armani suit;-> Sorry but I don't like fish nor armani suits :-) > > There was a thread about this in private mail round April this year, > > in which some good points were raised. > > There are some good points; however, whats the app for this feature? My specific application is a proxy application that replaces the in-kernel IP masquerading functionality, using a wildcard REDIRECT rule plus SO_ORIGINAL_DST. The main reason I'm doing it in userspace is because downstream bandwidth limiting becomes a whole lot easier this way than doing it in-kernel -- it would need complicated state tracking and nonobvious window field manipulations if done there. The applications that Bert and Marc named sound sane too. There's just a whole lot of things this thing can be used for. cheers, Lennert From chengjin@cs.caltech.edu Fri Nov 8 14:57:43 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Nov 2002 14:57:47 -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 gA8MvguR020516 for ; Fri, 8 Nov 2002 14:57:43 -0800 Received: from fast2.cs.caltech.edu (fast2.cs.caltech.edu [131.215.45.55]) by swordfish.cs.caltech.edu (Postfix) with ESMTP id 532F2DF215 for ; Fri, 8 Nov 2002 14:59:01 -0800 (PST) Received: from localhost (chengjin@localhost) by fast2.cs.caltech.edu (8.11.6/8.9.3) with ESMTP id gA8Mx1J27321 for ; Fri, 8 Nov 2002 14:59:01 -0800 X-Authentication-Warning: fast2.cs.caltech.edu: chengjin owned process doing -bs Date: Fri, 8 Nov 2002 14:59:01 -0800 (PST) From: Cheng Jin To: Subject: ifconfig TX/RX errors Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1136 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 Hi, all What does a large number of RX/TX errors from ifconfig output generally mean? Does it also include drop/overruns/frame errors? Is it an indication of bad packet on the link layer, which probably means faulty hardware? I am assuming any kind of buffer overflow statistics are kept under drop or overruns? Thanks a lot, Cheng Lab # 626 395 8820 From krkumar@us.ibm.com Fri Nov 8 15:02:16 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Nov 2002 15:02:18 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA8N2GuR021074 for ; Fri, 8 Nov 2002 15:02:16 -0800 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e34.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gA8N3Xb4053924; Fri, 8 Nov 2002 18:03:33 -0500 Received: from gateway1.beaverton.ibm.com (gateway1.beaverton.ibm.com [138.95.180.2]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA8N2Gv1042460; Fri, 8 Nov 2002 16:02:16 -0700 Received: from eng2.beaverton.ibm.com (eng2.beaverton.ibm.com [9.47.57.17]) by gateway1.beaverton.ibm.com (8.11.6/8.11.6) with ESMTP id gA8MwEV03425; Fri, 8 Nov 2002 14:58:14 -0800 Received: (from kkumar@localhost) by eng2.beaverton.ibm.com (8.10.0.Beta10/8.8.5/token.aware-1.2) id gA8N2Fv16472; Fri, 8 Nov 2002 15:02:15 -0800 (PST) From: Krishna Kumar Message-Id: <200211082302.gA8N2Fv16472@eng2.beaverton.ibm.com> Subject: [PATCH] memory leak in ndisc_router_discovery To: kuznet@ms2.inr.ac.ru, davem@redhat.com Date: Fri, 8 Nov 2002 15:02:15 -0800 (PST) Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1137 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: krkumar@us.ibm.com Precedence: bulk X-list: netdev Hi Alexey & Dave, There is a bug in router advertisement handling code, where the reference (and memory) to the inet6_dev pointer can get leaked. Following is the patch to fix it (patch against 2.5.46) : thanks, - KK diff -ruN linux.org/net/ipv6/ndisc.c linux/net/ipv6/ndisc.c --- linux.org/net/ipv6/ndisc.c Fri Nov 7 10:02:11 2002 +++ linux/net/ipv6/ndisc.c Fri Nov 8 14:37:27 2002 @@ -871,6 +871,7 @@ } if (!ndisc_parse_options(opt, optlen, &ndopts)) { + in6_dev_put(in6_dev); if (net_ratelimit()) ND_PRINTK2(KERN_WARNING "ICMP6 RA: invalid ND option, ignored.\n"); From becker@scyld.com Fri Nov 8 17:20:01 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Nov 2002 17:20:05 -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 gA91K0uR030104 for ; Fri, 8 Nov 2002 17:20:00 -0800 Received: from localhost (becker@localhost) by beohost.scyld.com (8.11.6/8.11.6) with ESMTP id gA91LQE22907; Fri, 8 Nov 2002 20:21:27 -0500 Date: Fri, 8 Nov 2002 20:21:26 -0500 (EST) From: Donald Becker To: Cheng Jin cc: netdev@oss.sgi.com Subject: Re: ifconfig TX/RX errors In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1138 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, 8 Nov 2002, Cheng Jin wrote: > What does a large number of RX/TX errors from ifconfig output generally > mean? Does it also include drop/overruns/frame errors? The 'ifconfig' program doesn't have a defined behavior. It reads /proc/net/dev and sums some of the available error counts. You should read /proc/net/dev directly to find out what is going wrong. The 'ifconfig' and 'netstat' programs follow the interface of their BSD predecessors. BSD wasn't sophisticated about errors: it kept only very basic statistics. Thus the tools only presented those numbers. [[ That's not to say I think 'ifconfig' should be changed: there is no compelling reason to break compatibility. It's been 20 years since anyone thought that trailers were a good idea, but it doesn't hurt to ignore the flag. ]] > Is it an indication of bad packet on the link layer, which probably means > faulty hardware? I am assuming any kind of buffer overflow statistics are > kept under drop or overruns? Check for kernel messages as well. -- 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 Nov 8 17:31:43 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Nov 2002 17:31:45 -0800 (PST) Received: from grok.yi.org (IDENT:hZNjWA0NSpyioBTvbWDHrxglgFnF0hy7@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA91VguR030936 for ; Fri, 8 Nov 2002 17:31:42 -0800 Received: from candelatech.com (IDENT:MEVdL+0qWknwWGQTcKjA+SvB6Do4QpeR@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id gA91X1q22687 for ; Fri, 8 Nov 2002 18:33:01 -0700 Message-ID: <3DCC65CD.6060009@candelatech.com> Date: Fri, 08 Nov 2002 17:33:01 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'netdev@oss.sgi.com'" Subject: NAPI question Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1139 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 In dev.c, there is this code. Please see my question by the ### marks. static void net_rx_action(struct softirq_action *h) { int this_cpu = smp_processor_id(); struct softnet_data *queue = &softnet_data[this_cpu]; unsigned long start_time = jiffies; int budget = netdev_max_backlog; br_read_lock(BR_NETPROTO_LOCK); local_irq_disable(); while (!list_empty(&queue->poll_list)) { struct net_device *dev; if (budget <= 0 || jiffies - start_time > 1) goto softnet_break; local_irq_enable(); dev = list_entry(queue->poll_list.next, struct net_device, poll_list); if (dev->quota <= 0 || dev->poll(dev, &budget)) { local_irq_disable(); list_del(&dev->poll_list); list_add_tail(&dev->poll_list, &queue->poll_list); ### How can quota ever get negative? In other words, why not just set it to dev->weight ### always? Or, if the dev didn't use up all it's quota from the last round, why not ### increase it up to a max of 2 x weight or something like that? if (dev->quota < 0) dev->quota += dev->weight; else dev->quota = dev->weight; } else { dev_put(dev); local_irq_disable(); } } -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From hadi@cyberus.ca Fri Nov 8 17:57:02 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Nov 2002 17:57:06 -0800 (PST) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA91v2uR032657 for ; Fri, 8 Nov 2002 17:57:02 -0800 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id UAA00116; Fri, 8 Nov 2002 20:58:19 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id gA91ohr16668; Fri, 8 Nov 2002 20:50:43 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Fri, 8 Nov 2002 20:50:43 -0500 (EST) From: jamal To: Ben Greear cc: "'netdev@oss.sgi.com'" Subject: Re: NAPI question In-Reply-To: <3DCC65CD.6060009@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1140 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 is basic Deficit Round Robin (DRR) algorithm, you cant just set things arbitrarily, i am afraid ;-> Search for George Varghese's paper if you want to know more. cheers, jamal On Fri, 8 Nov 2002, Ben Greear wrote: > ### How can quota ever get negative? In other words, why not just > set it to dev->weight always? Or, if the dev didn't use up all it's > quota from the last round, why not > ### increase it up to a max of 2 x weight or something like that? > > if (dev->quota < 0) > dev->quota += dev->weight; > else > dev->quota = dev->weight; > } else { > dev_put(dev); > local_irq_disable(); > } > } > > > -- > Ben Greear > President of Candela Technologies Inc http://www.candelatech.com > ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear > > > From hadi@cyberus.ca Fri Nov 8 18:06:27 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Nov 2002 18:06:29 -0800 (PST) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA926QuR000643 for ; Fri, 8 Nov 2002 18:06:27 -0800 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id VAA02519; Fri, 8 Nov 2002 21:07:45 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id gA9208T16683; Fri, 8 Nov 2002 21:00:09 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Fri, 8 Nov 2002 21:00:08 -0500 (EST) From: jamal To: Donald Becker cc: Cheng Jin , Subject: Re: ifconfig TX/RX errors In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1141 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 Fri, 8 Nov 2002, Donald Becker wrote: > On Fri, 8 Nov 2002, Cheng Jin wrote: > > > What does a large number of RX/TX errors from ifconfig output generally > > mean? Does it also include drop/overruns/frame errors? > > The 'ifconfig' program doesn't have a defined behavior. It reads > /proc/net/dev and sums some of the available error counts. You should > read /proc/net/dev directly to find out what is going wrong. > Actually, unbelievable as it may sound, the ifconfig data matches SNMP stats as defined in RFC1213 interfaces table; same with things like netstat -s in the tcp data etc cheers, jamal From greearb@candelatech.com Fri Nov 8 20:22:13 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Nov 2002 20:22:16 -0800 (PST) Received: from grok.yi.org (IDENT:/tdKB6z5e6cR5kzyDYXcfGw/RvxlzyLM@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA94MCuR002738 for ; Fri, 8 Nov 2002 20:22:13 -0800 Received: from candelatech.com (IDENT:rz1ekvxYXDw1YIoR7G2i9rYhNhfEreYo@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id gA94NUq13828 for ; Fri, 8 Nov 2002 21:23:31 -0700 Message-ID: <3DCC8DC2.4020204@candelatech.com> Date: Fri, 08 Nov 2002 20:23:30 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'netdev@oss.sgi.com'" Subject: NAPI: dev.c change to net_rx_action algorithm. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1142 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 tried making this change to dev.c in the net_rx_action method. So far, I have passed about 25 million packets and only dropped about 1.5k. This is with 4 interfaces tx + rx 8kpps (757 byte packets). rx-ring size is 1024, weight is 24, skb-hotlist is 2048. This is the best results so far, but it may be that this code change does not fare so well in other cases.... Comments? /* if (dev->quota <= 0 || dev->poll(dev, &budget)) { local_irq_disable(); list_del(&dev->poll_list); list_add_tail(&dev->poll_list, &queue->poll_list); if (dev->quota < 0) dev->quota += dev->weight; else dev->quota = dev->weight; } else { dev_put(dev); local_irq_disable(); } */ /* This scheme should allow devices to build up 2x their weight in quota * credit. Heavy users will only get their normal quota. This should * help let bursty traffic get higher priority. --Ben */ if (dev->poll(dev, &budget)) { /* More to do, put these guys back on the poll list */ local_irq_disable(); list_del(&dev->poll_list); list_add_tail(&dev->poll_list, &queue->poll_list); dev->quota = dev->weight; } else { /* These guys are done, they come off of the poll list */ if (dev->quota >= dev->weight) { dev->quota = (dev->weight << 1); /* max quota of 2x weight */ } else { dev->quota += dev->weight; } dev_put(dev); local_irq_disable(); } -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From hadi@cyberus.ca Fri Nov 8 20:38:22 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Nov 2002 20:38:25 -0800 (PST) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA94cLuR003167 for ; Fri, 8 Nov 2002 20:38:22 -0800 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id XAA04038; Fri, 8 Nov 2002 23:39:40 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id gA94W3V17011; Fri, 8 Nov 2002 23:32:03 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Fri, 8 Nov 2002 23:32:02 -0500 (EST) From: jamal To: Ben Greear cc: "'netdev@oss.sgi.com'" Subject: Re: NAPI: dev.c change to net_rx_action algorithm. In-Reply-To: <3DCC8DC2.4020204@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1143 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 The only thing i can think of is that if it was legal to flog people youd be on my list. And i would hope you dont enjoy it. Why do you like to put band-aids to things? Find the real cause of why you may be having problems then cure it; putting arbitrary hacks just because you can is rather against the basic principles of engineering. cheers, jamal On Fri, 8 Nov 2002, Ben Greear wrote: > I tried making this change to dev.c in the net_rx_action method. > > So far, I have passed about 25 million packets and only dropped > about 1.5k. This is with 4 interfaces tx + rx 8kpps (757 byte packets). > > rx-ring size is 1024, weight is 24, skb-hotlist is 2048. This is > the best results so far, but it may be that this code change does > not fare so well in other cases.... > > Comments? > > > /* > if (dev->quota <= 0 || dev->poll(dev, &budget)) { > local_irq_disable(); > list_del(&dev->poll_list); > list_add_tail(&dev->poll_list, &queue->poll_list); > if (dev->quota < 0) > dev->quota += dev->weight; > else > dev->quota = dev->weight; > } else { > dev_put(dev); > local_irq_disable(); > } > */ > > /* This scheme should allow devices to build up 2x their weight in quota > * credit. Heavy users will only get their normal quota. This should > * help let bursty traffic get higher priority. --Ben > */ > if (dev->poll(dev, &budget)) { > /* More to do, put these guys back on the poll list */ > local_irq_disable(); > list_del(&dev->poll_list); > list_add_tail(&dev->poll_list, &queue->poll_list); > dev->quota = dev->weight; > } > else { > /* These guys are done, they come off of the poll list */ > if (dev->quota >= dev->weight) { > dev->quota = (dev->weight << 1); /* max quota of 2x weight */ > } > else { > dev->quota += dev->weight; > } > dev_put(dev); > local_irq_disable(); > } > > -- > Ben Greear > President of Candela Technologies Inc http://www.candelatech.com > ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear > > > From greearb@candelatech.com Fri Nov 8 20:54:16 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Nov 2002 20:54:17 -0800 (PST) Received: from grok.yi.org (IDENT:7W/7ejmEwCivASok9lmb95Nx6WoWMr8k@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA94sFuR003671 for ; Fri, 8 Nov 2002 20:54:15 -0800 Received: from candelatech.com (IDENT:fnyS8FF6x2CHKNRNY4QSThBcPGsjcijS@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id gA94tHq17798; Fri, 8 Nov 2002 21:55:17 -0700 Message-ID: <3DCC9535.3050506@candelatech.com> Date: Fri, 08 Nov 2002 20:55:17 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jamal CC: "'netdev@oss.sgi.com'" Subject: Re: NAPI: dev.c change to net_rx_action algorithm. References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1144 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 jamal wrote: > > The only thing i can think of is that if it was legal to flog people > youd be on my list. And i would hope you dont enjoy it. > Why do you like to put band-aids to things? > Find the real cause of why you may be having problems then cure it; > putting arbitrary hacks just because you can is rather against > the basic principles of engineering. > > cheers, > jamal I'm looking for the real cause. The current code does not work as I want it to. So, I'm changing things. I would love to try out any patch you might feel like contributing. From what I can tell, the old code punishes interfaces who are running slower at any given time. My change, I believe, will allow slower interfaces to gather a bit more quota so that when they are hit with a burst of traffic, they can spend a little extra time to clear their buffers. I would also welcome any argument as to why my code is worse than the existing code. And theoretical papers be damned, I see better results with the change below. Why is that? Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From hadi@cyberus.ca Fri Nov 8 21:04:28 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Nov 2002 21:04:30 -0800 (PST) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA954SuR004135 for ; Fri, 8 Nov 2002 21:04:28 -0800 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id AAA09670; Sat, 9 Nov 2002 00:05:47 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id gA94w9917056; Fri, 8 Nov 2002 23:58:09 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Fri, 8 Nov 2002 23:58:07 -0500 (EST) From: jamal To: Ben Greear cc: "'netdev@oss.sgi.com'" Subject: Re: NAPI: dev.c change to net_rx_action algorithm. In-Reply-To: <3DCC9535.3050506@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1145 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 Fri, 8 Nov 2002, Ben Greear wrote: > I'm looking for the real cause. No you are not. You are looking for something that will give you some quick fix given your current setup. > The current code does not work > as I want it to. So, I'm changing things. I would love to try > out any patch you might feel like contributing. Be systematic about and prove where things are wrong. I even made some suggestions to you a while back. > > From what I can tell, the old code punishes interfaces who are > running slower at any given time. You are totaly wrong. Go and read the paper on DRR. > My change, I believe, will > allow slower interfaces to gather a bit more quota so that when > they are hit with a burst of traffic, they can spend a little > extra time to clear their buffers. > > I would also welcome any argument as to why my code is worse > than the existing code. And theoretical papers be damned, > You havent proved anything up to this point other than handwaving. So i dont think you should be damning anything. > I see better results with the change below. Why is that? > You tell me. cheers, jamal From greearb@candelatech.com Fri Nov 8 21:29:20 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Nov 2002 21:29:22 -0800 (PST) Received: from grok.yi.org (IDENT:TZUQ3TXRNrgmJOeGv6STR2O0jyu8gUrD@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA95TJuR004609 for ; Fri, 8 Nov 2002 21:29:19 -0800 Received: from candelatech.com (IDENT:CzrqmrOPcC/BXNu8LuLx05958/elKpJR@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id gA95Ubq22189; Fri, 8 Nov 2002 22:30:37 -0700 Message-ID: <3DCC9D7D.6020005@candelatech.com> Date: Fri, 08 Nov 2002 21:30:37 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jamal CC: "'netdev@oss.sgi.com'" Subject: Re: NAPI: dev.c change to net_rx_action algorithm. References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1146 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 jamal wrote: > > On Fri, 8 Nov 2002, Ben Greear wrote: >>I'm looking for the real cause. > No you are not. You are looking for something that will give you some > quick fix given your current setup. Guilty, and as soon as I get this particular config optomized, I will move on to the next scenario. If the next scenario is better by some other hack, then I will figure out how to reconcile the two, or make the algorithms dynamic if I have to. > Be systematic about and prove where things are wrong. I even made some > suggestions to you a while back. Things are wrong: I can't tx and rx 8kpps (50Mbps) on 4 ports simultaneously. I have fiddled with every magic static constant I could find, so now I'm fidling with algoritms. Primary culprit is rx-drop, which means the NIC is not getting serviced in time, if I understand correctly. I have 1024 rx-ring, which most agree is too large already, and yet it fills before I can empty it. Btw, and you'll love this one, if I change the priority of the irq thread to -18, things get even better ;) >> From what I can tell, the old code punishes interfaces who are >>running slower at any given time. > > > You are totaly wrong. Go and read the paper on DRR. I read the code. It's likely I'm confused, but here is how I interpret it. # If we are out of quota, refill quota but do not poll. # Why shouldn't we poll here? We wouldn't be in this list # If there was nothing to poll, eh? # If we have quota, poll, but only refill quota if we still have # more work to do. Busy devices have more work to do. Slow ones # will not. So, slow devices will have < dev->weight quota much of # the time. If the formerly slow device suddenly gets a large burst of # traffic, it's first poll will likely be for a quota smaller than # dev->weight. Why would this be good? # If we have quota, but do not not have more work to do after polling, # then pop out of the queue. Note quota is not refilled in this case, # again punishing devices that are running slower. if (dev->quota <= 0 || dev->poll(dev, &budget)) { local_irq_disable(); list_del(&dev->poll_list); list_add_tail(&dev->poll_list, &queue->poll_list); if (dev->quota < 0) dev->quota += dev->weight; else dev->quota = dev->weight; } else { dev_put(dev); local_irq_disable(); } >>I see better results with the change below. Why is that? >> > > > You tell me. I think my algorithm is better, at least for this case. It may be worse for others, though I'm not sure why it would be. The one thing you can be certain of is that I'll let you know if I figure it out :) Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From ekointernationalbank@37.com Sat Nov 9 03:59:00 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Nov 2002 03:59:02 -0800 (PST) Received: from mail14.bigmailbox.com (mail14.bigmailbox.com [209.132.220.45]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA9Bx0uR010301 for ; Sat, 9 Nov 2002 03:59:00 -0800 Received: (from www@localhost) by mail14.bigmailbox.com (8.11.6/8.10.0) id gA9Bxjm15929; Sat, 9 Nov 2002 03:59:45 -0800 Date: Sat, 9 Nov 2002 03:59:45 -0800 Message-Id: <200211091159.gA9Bxjm15929@mail14.bigmailbox.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [216.139.164.205] From: "mike obi" To: ekointernationalbank@37.com X-archive-position: 1147 Subject: (no subject) X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ekointernationalbank@37.com Precedence: bulk X-list: netdev STRICTLY CONFIDENTIAL From the Desk of: Dr. Mike Obi EKO INTERNATIONAL BANK PLC, NIGERIA . ATTN: MANAGING DIRECTOR/CEO, Sir, Permit me to introduce myself to you. My name is Mr Mike Obi, Manager with Eko international bank Plc, Lagos-Nigeria. I came to know about you in my private search for a reliable person/company to handle a confidential transaction on behalf of my Colleagues and myself.As a matter of fact, I got your information from the Nigerian Chamber of Commerce and Industry/Nigerian Export Promotion Council. Proposition A German Mr. Wolfgang Schinister, 66 years of age and a prosperous oil merchant had in our Bank the sum of US$35.5m in a domiciliary account. He named his wife, Mrs. Helga Schinister as the next of kin. Unfortunately, two of them were killed in the recent plane crash involving concord AF4590 in Gonesse, France. Efforts had been made by the management of my Bank through the German Embassy in Lagos to contact any of the deceased children but to no avail, as we were made to understand that the couple had no children. Given the skeletal information available to the Bank, it has so far been impossible to reach any of the relatives. The option left for the Bank management is to declare the deceased account dormant and revert the funds to trading on behalf of and in the interest of the Bank. In Nigeria, and almost all other parts of African continent,when Banks acquire funds such as that of Mr.Wolfgang Schinister,they are required by law to donate 30% of the funds on acquisation to The Trust Fund For Arms And Amunitions. Arms and amunitions purchased with funds from the Trust Fund are used to further enhance the course of war in Africa and invariably turbulence of some sort in the world in general. It is therefore in order to avoid/avert and discourage this negative development that my Colleagues and I now seek your assistance to have you stand as a distant relative to Mr. and Mrs. Wolfgang Schinister, so that the funds would be released to you. All documents and proofs to enable you get the funds will be carefully packaged once we receive your consent on this proposal. May I assured you that this Transaction is 100% safe and risk-free, as we have taken care of all necessary modalities to ensure a hitch-free transaction. I have the authority of my partners involved in this transaction to propose that should you be willing to assist us in the transaction your share would be 20% of the US$35.5 million, 70% for us and 10% for taxation and other miscellaneous expenses that may be incured in this transaction. I have reposed my confidence in you and hope that you will not disappoint me. Best Regards. Dr. Mike Obi ------------------------------------------------------------ http://Game.37.com/ <--- Free Games http://newJoke.com/ <--- J O K E S ! ! ! --------------------------------------------------------------------- Express yourself with a super cool email address from BigMailBox.com. Hundreds of choices. It's free! http://www.bigmailbox.com --------------------------------------------------------------------- From hadi@cyberus.ca Sat Nov 9 06:47:35 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Nov 2002 06:47:40 -0800 (PST) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA9ElYuR018755 for ; Sat, 9 Nov 2002 06:47:35 -0800 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id JAA17920; Sat, 9 Nov 2002 09:48:55 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id gA9EfA217930; Sat, 9 Nov 2002 09:41:17 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sat, 9 Nov 2002 09:41:09 -0500 (EST) From: jamal To: Ben Greear cc: "'netdev@oss.sgi.com'" Subject: Re: NAPI: dev.c change to net_rx_action algorithm. In-Reply-To: <3DCC9D7D.6020005@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1148 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 Fri, 8 Nov 2002, Ben Greear wrote: > Btw, and you'll love this one, if I change the priority of the irq thread > to -18, things get even better ;) ;-> Ok, go ahead and hack the scheduler now. All, i am saying is that you should stop wildly pointing fingers at a million things and diagnose what the issue is then come up with a fix; So far, you have not. It was the rx ring then it is napi/DRR and now it is the scheduler; and before you find the real cause please stop posting code like a lunatic. cheers, jamal From paolo.pumilia@acm.org Sun Nov 10 05:05:56 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Nov 2002 05:06:01 -0800 (PST) Received: from wigner.cstc.lan (root@[212.171.70.245]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAAD5ruR004128 for ; Sun, 10 Nov 2002 05:05:55 -0800 Received: from wigner.cstc.lan (pol@localhost [127.0.0.1]) by wigner.cstc.lan (8.12.6/8.12.6/Debian-5) with ESMTP id gAAD0KcG014999; Sun, 10 Nov 2002 14:00:20 +0100 Received: (from pol@localhost) by wigner.cstc.lan (8.12.6/8.12.6/Debian-5) id gAAD0JgV014995; Sun, 10 Nov 2002 14:00:19 +0100 Date: Sun, 10 Nov 2002 14:00:19 +0100 From: Paolo Pumilia To: netdev@oss.sgi.com Subject: ioport.h fixed in 2.2.22 Message-ID: <20021110130019.GA14897@wigner.cstc.lan> Reply-To: paolo.pumilia@inwind.it Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline User-Agent: Mutt/1.4i X-Operating-System: Linux wigner 2.4.17 X-archive-position: 1149 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: paolo.pumilia@acm.org Precedence: bulk X-list: netdev --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In order to compile 3.1.28 pcmcia modules (package pcmcia-cs-3.1.28), commenting out lines referring to compatibility to kernel 2.4 in file: include/linux/ioport.h, in kernel-source 2.2.22 has been required, Here enclosed is my fixed file. Being just a newbie, i hope it has been the right action to take. Thank you -- Paolo Pumilia AICA- OpenSource workgroup AICA OpenSource WorkGroup Coordinator Website: http//www.linfe.it/AICA-OpenSource --jI8keyz6grp/JLjh Content-Type: text/x-chdr; charset=us-ascii Content-Disposition: attachment; filename="v2.2.22-fixed-ioport.h" /* file: /home/src/kernel-source-2.2.22/include/linux/ioport.h * modified in order to allow pcmcia modules compilation * Paolo Pumilia, nov 10, 2002 - paolo.pumilia@acm.org */ /* * portio.h Definitions of routines for detecting, reserving and * allocating system resources. * * Version: 0.01 8/30/93 * * Author: Donald Becker (becker@super.org) */ #ifndef _LINUX_PORTIO_H #define _LINUX_PORTIO_H #define HAVE_PORTRESERVE /* * Call check_region() before probing for your hardware. * Once you have found you hardware, register it with request_region(). * If you unload the driver, use release_region to free ports. */ extern void reserve_setup(char *str, int *ints); extern int check_region(unsigned long from, unsigned long extent); extern void request_region(unsigned long from, unsigned long extent,const char *name); extern void release_region(unsigned long from, unsigned long extent); extern int get_ioport_list(char *); #ifdef __sparc__ extern unsigned long occupy_region(unsigned long base, unsigned long end, unsigned long num, unsigned int align, const char *name); #endif #define HAVE_AUTOIRQ extern void autoirq_setup(int waittime); extern int autoirq_report(int waittime); /* * for compatibility with 2.4 */ /* commented out, in order to allow pcmcia modules compilation * Paolo Pumilia, nov 10, 2002 - paolo.pumilia@acm.org * * extern inline int check_mem_region(unsigned long from, unsigned long extent) * { * return 0; * } * * extern inline void request_mem_region(unsigned long from, unsigned long extent,const char *name) * { * } * * extern inline void release_mem_region(unsigned long from, unsigned long extent) * { * } */ #endif /* _LINUX_PORTIO_H */ --jI8keyz6grp/JLjh-- From paolo.pumilia@acm.org Sun Nov 10 05:07:54 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Nov 2002 05:07:56 -0800 (PST) Received: from wigner.cstc.lan (root@[212.171.70.245]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAAD7quR004337 for ; Sun, 10 Nov 2002 05:07:53 -0800 Received: from wigner.cstc.lan (pol@localhost [127.0.0.1]) by wigner.cstc.lan (8.12.6/8.12.6/Debian-5) with ESMTP id gAAD7NcG015114; Sun, 10 Nov 2002 14:07:23 +0100 Received: (from pol@localhost) by wigner.cstc.lan (8.12.6/8.12.6/Debian-5) id gAAD7Nof015110; Sun, 10 Nov 2002 14:07:23 +0100 Date: Sun, 10 Nov 2002 14:07:23 +0100 From: Paolo Pumilia To: linux-laptop@vger.kernel.org, linux-config@vger.kernel.org, netdev@oss.sgi.com Subject: ioport.h fixed in 2.2.22 Message-ID: <20021110130723.GA15090@wigner.cstc.lan> Reply-To: paolo.pumilia@inwind.it Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline User-Agent: Mutt/1.4i X-Operating-System: Linux wigner 2.4.17 X-archive-position: 1150 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: paolo.pumilia@acm.org Precedence: bulk X-list: netdev --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In order to compile 3.1.28 pcmcia modules (package pcmcia-cs-3.1.28), commenting out lines referring to compatibility to kernel 2.4 in file: include/linux/ioport.h, in kernel-source 2.2.22 has been required, Here enclosed is my fixed file. Being just a newbie, i hope it has been the right action to take. Thank you -- Paolo Pumilia AICA- OpenSource workgroup AICA OpenSource WorkGroup Coordinator Website: http//www.linfe.it/AICA-OpenSource --oyUTqETQ0mS9luUI Content-Type: text/x-chdr; charset=us-ascii Content-Disposition: attachment; filename="v2.2.22-fixed-ioport.h" /* file: /home/src/kernel-source-2.2.22/include/linux/ioport.h * modified in order to allow pcmcia modules compilation * Paolo Pumilia, nov 10, 2002 - paolo.pumilia@acm.org */ /* * portio.h Definitions of routines for detecting, reserving and * allocating system resources. * * Version: 0.01 8/30/93 * * Author: Donald Becker (becker@super.org) */ #ifndef _LINUX_PORTIO_H #define _LINUX_PORTIO_H #define HAVE_PORTRESERVE /* * Call check_region() before probing for your hardware. * Once you have found you hardware, register it with request_region(). * If you unload the driver, use release_region to free ports. */ extern void reserve_setup(char *str, int *ints); extern int check_region(unsigned long from, unsigned long extent); extern void request_region(unsigned long from, unsigned long extent,const char *name); extern void release_region(unsigned long from, unsigned long extent); extern int get_ioport_list(char *); #ifdef __sparc__ extern unsigned long occupy_region(unsigned long base, unsigned long end, unsigned long num, unsigned int align, const char *name); #endif #define HAVE_AUTOIRQ extern void autoirq_setup(int waittime); extern int autoirq_report(int waittime); /* * for compatibility with 2.4 */ /* commented out, in order to allow pcmcia modules compilation * Paolo Pumilia, nov 10, 2002 - paolo.pumilia@acm.org * * extern inline int check_mem_region(unsigned long from, unsigned long extent) * { * return 0; * } * * extern inline void request_mem_region(unsigned long from, unsigned long extent,const char *name) * { * } * * extern inline void release_mem_region(unsigned long from, unsigned long extent) * { * } */ #endif /* _LINUX_PORTIO_H */ --oyUTqETQ0mS9luUI-- From bleckey@tpg.com.au Sun Nov 10 19:34:09 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Nov 2002 19:34:13 -0800 (PST) Received: from mail3.tpgi.com.au (mail.tpgi.com.au [203.12.160.59]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAB3Y8uR014595 for ; Sun, 10 Nov 2002 19:34:08 -0800 Received: from tpg.com.au (wolf.tpgi.com.au [203.58.27.182]) (authenticated (0 bits)) by mail3.tpgi.com.au (8.11.6/8.11.6) with ESMTP id gAB3ZZ517441 for ; Mon, 11 Nov 2002 14:35:35 +1100 Message-ID: <3DCE7B81.4070604@tpg.com.au> Date: Mon, 11 Nov 2002 02:30:09 +1100 From: Bill Leckey User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Net device queries. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1151 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bleckey@tpg.com.au Precedence: bulk X-list: netdev I've been coding an ethernet driver for some new hardware we're developing and while it's working, there are a few issues I'm still unsure of. I couldn't find any archives for this list, so I'm suspecting I'm going to cover a lot of 'old ground'. Most of my info for coding ethernet drivers comes out of Rubini and Corbet's LInux Device Drivers, and what I've gleaned from kernel sources Firstly some background. With these cards I can have up to 25 point to point connections (to the same destination machine, or 25 destination machines). I have almost total control of what goes out on the wire, so I've chosen a minimal header that contains the type (passed in to hard_header) and a 16 bit field that contains misc other information. So, 32 bits, plus the data. The hardware provides things like length, and CRC checking. Currently I'm setting dev->hard_header_len to 4. The part that concerns me is what I set dev->type, dev->addr_len and dev->flags to. We don't technically have a hardware address so I set dev->addr_len to 0. I set dev->type to ARPHRD_VOID, simply because I'm not sure what the consequences of setting it to anything else are. I set dev->flags to IFF_POINTOPOINT | IFF_NOARP This appears to all work correctly, however both ifconfig and tcpdump aren't really happy. TCPDUMP doesn't know what to do with the ARPHRD_VOID and drops to 'raw' mode, so it still does what I need, even if it prints an annoying message for each packet. ifconfig isn't sure what to do about the HWaddr. For instance, this is the ifconfig for one of the links: hssl0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:192.168.2.1 P-t-P:192.168.2.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 RX packets:3509748 errors:459 dropped:0 overruns:0 frame:363 TX packets:3013210 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:368907445 (351.8 Mb) TX bytes:266074976 (253.7 Mb) Any thoughts, comments or otherwise on what I've done, or what I /should/ be doing would be appreciated as I'm still not fully across how the networking stuff works. Bill -- Bill Leckey - Senior Software Design Engineer TPG Research and Development Ph: +61 2 62851711 Fax: +61 2 62853939 . From greearb@candelatech.com Sun Nov 10 19:46:11 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Nov 2002 19:46:14 -0800 (PST) Received: from grok.yi.org (dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAB3kAuR015038 for ; Sun, 10 Nov 2002 19:46:10 -0800 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id gAB3lVq07335; Sun, 10 Nov 2002 20:47:31 -0700 Message-ID: <3DCF2853.4000908@candelatech.com> Date: Sun, 10 Nov 2002 19:47:31 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Leckey CC: netdev@oss.sgi.com Subject: Re: Net device queries. References: <3DCE7B81.4070604@tpg.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1152 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 Bill Leckey wrote: > I've been coding an ethernet driver for some new hardware we're > developing and while it's working, there are a few issues I'm still > unsure of. I couldn't find any archives for this list, so I'm > suspecting I'm going to cover a lot of 'old ground'. Most of my info > for coding ethernet drivers comes out of Rubini and Corbet's LInux > Device Drivers, and what I've gleaned from kernel sources > > Firstly some background. With these cards I can have up to 25 point to > point connections (to the same destination machine, or 25 destination > machines). I have almost total control of what goes out on the wire, so > I've chosen a minimal header that contains the type (passed in to > hard_header) and a 16 bit field that contains misc other information. > So, 32 bits, plus the data. The hardware provides things like length, > and CRC checking. > > Currently I'm setting dev->hard_header_len to 4. > > The part that concerns me is what I set dev->type, dev->addr_len and > dev->flags to. > > We don't technically have a hardware address so I set dev->addr_len to 0. If you want to look like ethernet, it seems you would want at least a fake MAC. To me, it also sounds like you may want up to 25 net_devices, since you have that many logical point-to-point connections. (Similar to the way VLAN works) > > I set dev->type to ARPHRD_VOID, simply because I'm not sure what the > consequences of setting it to anything else are. Maybe you could get a serial number out of your device and then hash it into MAC addresses? The user can always change these with ifconfig or 'ip' after your device initializes anyway... -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From ahu@outpost.ds9a.nl Mon Nov 11 02:30:39 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Nov 2002 02:30:45 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gABAUSuR028481 for ; Mon, 11 Nov 2002 02:30:29 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id C17C544D3; Mon, 11 Nov 2002 11:01:09 +0100 (CET) Date: Mon, 11 Nov 2002 11:01:09 +0100 From: bert hubert To: kuznet@ms2.inr.ac.ru Cc: davem@redhat.com, gem@asplinux.ru, netdev@oss.sgi.com Subject: Re: off by one error in 3des cbc keying Message-ID: <20021111100109.GB18677@outpost.ds9a.nl> Mail-Followup-To: bert hubert , kuznet@ms2.inr.ac.ru, davem@redhat.com, gem@asplinux.ru, netdev@oss.sgi.com References: <20021110111507.GA31188@outpost.ds9a.nl> <200211110151.EAA26095@sex.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211110151.EAA26095@sex.inr.ac.ru> User-Agent: Mutt/1.3.28i X-archive-position: 1153 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev [alexey's nameserver is off, cc to netdev@oss.sgi.com, perhaps he sees it there] On Mon, Nov 11, 2002 at 04:51:36AM +0300, kuznet@ms2.inr.ac.ru wrote: > Yes, connect() is broken... The patch is enclosed. Alternatively, you > could allow connections to remote isakmp ports via policy. Ok, with careful tuning, it will work now. But not for the general case. If a policy is setup that only applies to ICMP, IKE converges and works (as it works over UDP). I wonder, is 'incoming bypass' implemented yet? If there is an incoming policy, racoon does not see any traffic. Key refreshing/updating doesn't appear to work either, after they key has expired, all bets are off. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From ahu@outpost.ds9a.nl Mon Nov 11 03:39:46 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Nov 2002 03:39:48 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gABBdjuR030809 for ; Mon, 11 Nov 2002 03:39:45 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id EEEAD4071; Mon, 11 Nov 2002 12:41:13 +0100 (CET) Date: Mon, 11 Nov 2002 12:41:13 +0100 From: bert hubert To: kuznet@ms2.inr.ac.ru, davem@redhat.com, gem@asplinux.ru, netdev@oss.sgi.com Subject: Re: off by one error in 3des cbc keying Message-ID: <20021111114113.GA21179@outpost.ds9a.nl> Mail-Followup-To: bert hubert , kuznet@ms2.inr.ac.ru, davem@redhat.com, gem@asplinux.ru, netdev@oss.sgi.com References: <20021110111507.GA31188@outpost.ds9a.nl> <200211110151.EAA26095@sex.inr.ac.ru> <20021111100109.GB18677@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021111100109.GB18677@outpost.ds9a.nl> User-Agent: Mutt/1.3.28i X-archive-position: 1154 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev On Mon, Nov 11, 2002 at 11:01:09AM +0100, bert hubert wrote: > Ok, with careful tuning, it will work now. But not for the general case. http://lartc.org/howto/lartc.ipsec.automatic.keying.html <- how to get this to work -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From kuznet@ms2.inr.ac.ru Mon Nov 11 09:18:14 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Nov 2002 09:18:16 -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 gABHICuR008346 for ; Mon, 11 Nov 2002 09:18:13 -0800 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id UAA27829; Mon, 11 Nov 2002 20:18:55 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200211111718.UAA27829@sex.inr.ac.ru> Subject: Re: off by one error in 3des cbc keying To: ahu@ds9a.nl (bert hubert) Date: Mon, 11 Nov 2002 20:18:55 +0300 (MSK) Cc: davem@redhat.com, gem@asplinux.ru, netdev@oss.sgi.com In-Reply-To: <20021111100109.GB18677@outpost.ds9a.nl> from "bert hubert" at Nov 11, 2 11:01:09 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 1155 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! > [alexey's nameserver is off, cc to netdev@oss.sgi.com, perhaps he sees it > there] Unlikely. I think while our network is down list exploders just drop mails unlike normal mail agents. :-) > I wonder, is 'incoming bypass' implemented yet? It is. But your example shows that something is wrong there. Fix will follow later. > Key refreshing/updating doesn't appear to work either, after they key has > expired, all bets are off. What does happen in logs/setkey -D? Actually, before sending previous large patch dealing with expire timers I got it to the point where keys are refreshed nicely at _one_ side, another required reboot and the test was not accomplished. Alexey From ahu@outpost.ds9a.nl Mon Nov 11 12:30:36 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Nov 2002 12:30:40 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gABKUPuR011017 for ; Mon, 11 Nov 2002 12:30:25 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id B75804103; Mon, 11 Nov 2002 21:03:21 +0100 (CET) Date: Mon, 11 Nov 2002 21:03:21 +0100 From: bert hubert To: kuznet@ms2.inr.ac.ru Cc: davem@redhat.com, gem@asplinux.ru, netdev@oss.sgi.com Subject: Re: off by one error in 3des cbc keying Message-ID: <20021111200321.GA30957@outpost.ds9a.nl> Mail-Followup-To: bert hubert , kuznet@ms2.inr.ac.ru, davem@redhat.com, gem@asplinux.ru, netdev@oss.sgi.com References: <20021111100109.GB18677@outpost.ds9a.nl> <200211111718.UAA27829@sex.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211111718.UAA27829@sex.inr.ac.ru> User-Agent: Mutt/1.3.28i X-archive-position: 1156 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev On Mon, Nov 11, 2002 at 08:18:55PM +0300, kuznet@ms2.inr.ac.ru wrote: > Unlikely. I think while our network is down list exploders just > drop mails unlike normal mail agents. :-) Yeah - I had this vague idea maybe you read this list from another address :-) > > I wonder, is 'incoming bypass' implemented yet? > > It is. But your example shows that something is wrong there. Fix will follow > later. Ok, let me know if I can test. The IPSEC pages on lartc now have had over 3000 real visits, by the way. This is a lot. > What does happen in logs/setkey -D? Actually, before sending previous > large patch dealing with expire timers I got it to the point where keys Communications work, then *something* expires after 30 seconds, and then there is 10 minute where everything works. Then things break down, and after a while, renegotiation succeeds. Racoon configuration identical to the previous one. Logs of setup: 20:40:12: INFO: main.c:170:main(): @(#)racoon 20001216 20001216 sakane@kame.net 20:40:12: INFO: main.c:171:main(): @(#)This product linked OpenSSL 0.9.6c 21 dec 2001 (http://www.openssl.org/) 20:40:12: INFO: isakmp.c:1365:isakmp_open(): 127.0.0.1[500] used as isakmp port (fd=7) 20:40:12: INFO: isakmp.c:1365:isakmp_open(): 10.0.0.216[500] used as isakmp port (fd=8) 20:40:12: ERROR: isakmp.c:1357:isakmp_open(): failed to bind (Address already in use). 20:40:12: ERROR: isakmp.c:1357:isakmp_open(): failed to bind (Address already in use). Tried to connect to 10.0.0.11: 20:41:06: INFO: isakmp.c:1689:isakmp_post_acquire(): IPsec-SA request for 10.0.0.11 queued due to no phase1 found. 20:41:06: INFO: isakmp.c:794:isakmp_ph1begin_i(): initiate new phase 1 negotiation: 10.0.0.216[500]<=>10.0.0.11[500] 20:41:06: INFO: isakmp.c:799:isakmp_ph1begin_i(): begin Aggressive mode. 20:41:07: INFO: vendorid.c:128:check_vendorid(): received Vendor ID: KAME/racoon 20:41:07: NOTIFY: oakley.c:2037:oakley_skeyid(): couldn't find the proper pskey, try to get one by the peer's address. 20:41:07: INFO: isakmp.c:2417:log_ph1established(): ISAKMP-SA established 10.0.0.216[500]-10.0.0.11[500] spi:7f7352a7dbd917ba:087da64152cda86a 20:41:07: INFO: isakmp.c:938:isakmp_ph2begin_i(): initiate new phase 2 negotiation: 10.0.0.216[0]<=>10.0.0.11[0] 20:41:07: INFO: pfkey.c:1106:pk_recvupdate(): IPsec-SA established: ESP/Transport 10.0.0.11->10.0.0.216 spi=137313584(0x82f3d30) 20:41:07: INFO: pfkey.c:1318:pk_recvadd(): IPsec-SA established: ESP/Transport 10.0.0.216->10.0.0.11 spi=98734594(0x5e29202) After thirty seconds: 20:41:36: INFO: pfkey.c:1364:pk_recvexpire(): IPsec-SA expired: ESP/Transport 10.0.0.216->10.0.0.11 After a few minutes, lifetime is 10 minutes: 20:49:07: INFO: pfkey.c:1364:pk_recvexpire(): IPsec-SA expired: ESP/Transport 10.0.0.11->10.0.0.216 spi=137313584(0x82f3d30) 20:49:07: INFO: isakmp.c:938:isakmp_ph2begin_i(): initiate new phase 2 negotiation: 10.0.0.216[0]<=>10.0.0.11[0] 20:49:07: INFO: pfkey.c:1364:pk_recvexpire(): IPsec-SA expired: ESP/Transport 10.0.0.216->10.0.0.11 spi=98734594(0x5e29202) 20:49:07: INFO: pfkey.c:1106:pk_recvupdate(): IPsec-SA established: ESP/Transport 10.0.0.11->10.0.0.216 spi=137313584(0x82f3d30) 20:49:07: ERROR: pfkey.c:206:pfkey_handler(): pfkey ADD failed: File exists Period of silence: 20:51:07: INFO: pfkey.c:1364:pk_recvexpire(): IPsec-SA expired: ESP/Transport 10.0.0.216->10.0.0.11 spi=98734594(0x5e29202) 20:51:07: INFO: isakmp.c:938:isakmp_ph2begin_i(): initiate new phase 2 negotiation: 10.0.0.216[0]<=>10.0.0.11[0] 20:51:07: INFO: isakmp.c:1521:isakmp_ph1expire(): ISAKMP-SA expired 10.0.0.216[500]-10.0.0.11[500] spi:7f7352a7dbd917ba:087da64152cda86a 20:51:07: ERROR: isakmp.c:1741:isakmp_post_getspi(): the negotiation is stopped, because there is no suitable ISAKMP-SA. 20:51:07: ERROR: pfkey.c:894:pk_recvgetspi(): failed to start post getspi. 20:51:08: INFO: isakmp.c:1521:isakmp_ph1expire(): ISAKMP-SA expired 10.0.0.216[500]-10.0.0.11[500] spi:7f7352a7dbd917ba:087da64152cda86a 20:51:09: INFO: isakmp.c:1569:isakmp_ph1delete(): ISAKMP-SA deleted 10.0.0.216[500]-10.0.0.11[500] spi:7f7352a7dbd917ba:087da64152cda86a 20:51:36: INFO: isakmp.c:1689:isakmp_post_acquire(): IPsec-SA request for 10.0.0.11 queued due to no phase1 found. 20:51:36: INFO: isakmp.c:794:isakmp_ph1begin_i(): initiate new phase 1 negotiation: 10.0.0.216[500]<=>10.0.0.11[500] 20:51:36: INFO: isakmp.c:799:isakmp_ph1begin_i(): begin Aggressive mode. 20:51:37: INFO: vendorid.c:128:check_vendorid(): received Vendor ID: KAME/racoon 20:51:37: NOTIFY: oakley.c:2037:oakley_skeyid(): couldn't find the proper pskey, try to get one by the peer's address. 20:51:37: INFO: isakmp.c:2417:log_ph1established(): ISAKMP-SA established 10.0.0.216[500]-10.0.0.11[500] spi:48e6122ec72e2b47:55ea41d31553b4c2 20:51:37: INFO: isakmp.c:938:isakmp_ph2begin_i(): initiate new phase 2 negotiation: 10.0.0.216[0]<=>10.0.0.11[0] 20:51:37: INFO: pfkey.c:1106:pk_recvupdate(): IPsec-SA established: ESP/Transport 10.0.0.11->10.0.0.216 spi=137313584(0x82f3d30) 20:51:37: INFO: pfkey.c:1318:pk_recvadd(): IPsec-SA established: ESP/Transport 10.0.0.216->10.0.0.11 spi=98734594(0x5e29202) 20:52:06: INFO: pfkey.c:1364:pk_recvexpire(): IPsec-SA expired: ESP/Transport 10.0.0.216->10.0.0.11 Communications now work again. In the meantime on the responding site, 10.0.0.11: 20:51:36: INFO: pfkey.c:1106:pk_recvupdate(): IPsec-SA established: ESP/Transport 10.0.0.216->10.0.0.11 spi=98734594(0x5e29202) 20:51:36: INFO: pfkey.c:1318:pk_recvadd(): IPsec-SA established: ESP/Transport 10.0.0.11->10.0.0.216 spi=137313584(0x82f3d30) 20:59:36: INFO: pfkey.c:1364:pk_recvexpire(): IPsec-SA expired: ESP/Transport 10.0.0.216->10.0.0.11 spi=98734594(0x5e29202) 20:59:36: INFO: pfkey.c:1364:pk_recvexpire(): IPsec-SA expired: ESP/Transport 10.0.0.11->10.0.0.216 spi=137313584(0x82f3d30) 20:59:36: INFO: isakmp.c:1045:isakmp_ph2begin_r(): respond new phase 2 negotiation: 10.0.0.11[0]<=>10.0.0.216[0] 20:59:37: INFO: pfkey.c:1106:pk_recvupdate(): IPsec-SA established: ESP/Transport 10.0.0.216->10.0.0.11 spi=98734594(0x5e29202) 20:59:37: ERROR: pfkey.c:206:pfkey_handler(): pfkey ADD failed: File exists setkey -DP with working communications prints the following two real entries (on 10.0.0.11): 10.0.0.216[any] 10.0.0.11[any] tcp esp/transport//require created:Nov 11 20:40:56 2002 lastused:Nov 11 20:41:25 2002 lifetime:0(s) validtime:0(s) spid=2296 seq=5 pid=1061 refcnt=21 10.0.0.11[any] 10.0.0.216[any] tcp esp/transport//require created:Nov 11 20:40:56 2002 lastused:Nov 11 20:41:25 2002 lifetime:0(s) validtime:0(s) spid=2289 seq=4 pid=1061 refcnt=3 And the following apparently bogus ones: 0.0.0.0/0[any] 0.0.0.0/0[any] any in none created:Nov 11 20:40:58 2002 lastused: lifetime:0(s) validtime:0(s) spid=2323 seq=3 pid=1061 refcnt=2 0.0.0.0/0[any] 0.0.0.0/0[any] any in none created:Nov 11 20:40:58 2002 lastused: lifetime:0(s) validtime:0(s) spid=2307 seq=2 pid=1061 refcnt=2 0.0.0.0/0[any] 0.0.0.0/0[any] any out none created:Nov 11 20:40:58 2002 lastused:Nov 11 20:41:06 2002 lifetime:0(s) validtime:0(s) spid=2332 seq=1 pid=1061 refcnt=2 0.0.0.0/0[any] 0.0.0.0/0[any] any out none created:Nov 11 20:40:58 2002 lastused: lifetime:0(s) validtime:0(s) spid=2316 seq=0 pid=1061 refcnt=2 Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From kuznet@ms2.inr.ac.ru Mon Nov 11 13:34:51 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Nov 2002 13:34:53 -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 gABLYnuR014203 for ; Mon, 11 Nov 2002 13:34:50 -0800 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id AAA28650; Tue, 12 Nov 2002 00:35:38 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200211112135.AAA28650@sex.inr.ac.ru> Subject: Re: off by one error in 3des cbc keying To: ahu@ds9a.nl (bert hubert) Date: Tue, 12 Nov 2002 00:35:38 +0300 (MSK) Cc: davem@redhat.com, gem@asplinux.ru, netdev@oss.sgi.com In-Reply-To: <20021111200321.GA30957@outpost.ds9a.nl> from "bert hubert" at Nov 11, 2 09:03:21 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 1157 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! > Communications work, then *something* expires after 30 seconds, It is harmless, it is original request expired. However, this implies a bug, original request must be replaced while installing negotiated SA. It would be good if you made setkey -D before the entry expired and started "setkey -x >& pfkey.log &" to collect pfkey traffic. > After a few minutes, lifetime is 10 minutes: > 20:49:07: INFO: pfkey.c:1364:pk_recvexpire(): IPsec-SA expired: > ESP/Transport 10.0.0.11->10.0.0.216 spi=137313584(0x82f3d30) That's soft expire notification, now keys should be updated now... > 20:49:07: ERROR: pfkey.c:206:pfkey_handler(): pfkey ADD failed: > File exists Wow! I see. This is an explanation. racoon uses ADD instead of UPDATE... It should not. Oh, well, but Maxim confirmed hour ago that it works. This is puzzle. :-) OK, I have to dig in racoon to understand what the hell it expects. If you prepare "setkey -x >& pfkey.log &" it will make the things much easier to track. Please, remember, at the moment I do not have capabilities to make any experiments here. Probably, this is for good (stimulates imagination :-)), but I really need to have full information to debug and not to imagine too far. :-) > 20:51:07: INFO: pfkey.c:1364:pk_recvexpire(): IPsec-SA expired: > ESP/Transport 10.0.0.216->10.0.0.11 spi=98734594(0x5e29202) And this is hard expire. The further is mess, apparently because racoon is out of sync with kernel. > And the following apparently bogus ones: No, these are racoon's own ones. Do not worry about them. They are not used for any packets but racoon's ones. Alexey From ahu@outpost.ds9a.nl Mon Nov 11 13:49:53 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Nov 2002 13:50:00 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gABLnpuR015894 for ; Mon, 11 Nov 2002 13:49:52 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 62C7C4496; Mon, 11 Nov 2002 22:51:22 +0100 (CET) Date: Mon, 11 Nov 2002 22:51:22 +0100 From: bert hubert To: kuznet@ms2.inr.ac.ru Cc: davem@redhat.com, gem@asplinux.ru, netdev@oss.sgi.com Subject: Re: off by one error in 3des cbc keying Message-ID: <20021111215122.GA563@outpost.ds9a.nl> Mail-Followup-To: bert hubert , kuznet@ms2.inr.ac.ru, davem@redhat.com, gem@asplinux.ru, netdev@oss.sgi.com References: <20021111200321.GA30957@outpost.ds9a.nl> <200211112135.AAA28650@sex.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211112135.AAA28650@sex.inr.ac.ru> User-Agent: Mutt/1.3.28i X-archive-position: 1158 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev On Tue, Nov 12, 2002 at 12:35:38AM +0300, kuznet@ms2.inr.ac.ru wrote: > It would be good if you made setkey -D before the entry expired > and started "setkey -x >& pfkey.log &" to collect pfkey traffic. Before the 30 second entry expired: 10.0.0.216 10.0.0.11 esp mode=transport spi=57115683(0x03678423) reqid=0(0x00000000) E: 3des-cbc cc8e8e4f 91d41b7b ea6cbb3c 24a465cb a08b33aa c8ec1274 A: hmac-sha1 f454ab03 3a803ca4 05239de3 100ce68f d283f10a seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Nov 11 22:42:38 2002 current: Nov 11 22:43:05 2002 diff: 27(s) hard: 600(s) soft: 480(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=2 pid=8126 refcnt=0 10.0.0.216 10.0.0.11 esp mode=transport spi=0(0x00000000) reqid=0(0x00000000) seq=0x00000000 replay=0 flags=0x00000000 state=larval created: Nov 11 22:42:37 2002 current: Nov 11 22:43:05 2002 diff: 28(s) hard: 30(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=1 pid=8126 refcnt=0 10.0.0.11 10.0.0.216 esp mode=transport spi=222275495(0x0d3fa7a7) reqid=0(0x00000000) E: 3des-cbc f5fbb657 9b12bea6 b7d2eeda 587a0961 8a94ff6e d7b79a28 A: hmac-sha1 20c2a282 1909e8ab 1e4690c1 1ee6cb40 c6b24190 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Nov 11 22:42:38 2002 current: Nov 11 22:43:05 2002 diff: 27(s) hard: 600(s) soft: 480(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=0 pid=8126 refcnt=0 The middle one disappears after 30 seconds. Log: 22:42:37: INFO: isakmp.c:1689:isakmp_post_acquire(): IPsec-SA request for 10.0.0.11 queued due to no phase1 found. 22:42:37: INFO: isakmp.c:794:isakmp_ph1begin_i(): initiate new phase 1 negotiation: 10.0.0.216[500]<=>10.0.0.11[500] 22:42:37: INFO: isakmp.c:799:isakmp_ph1begin_i(): begin Aggressive mode. 22:42:38: INFO: vendorid.c:128:check_vendorid(): received Vendor ID: KAME/racoon 22:42:38: NOTIFY: oakley.c:2037:oakley_skeyid(): couldn't find the proper pskey, try to get one by the peer's address. 22:42:38: INFO: isakmp.c:2417:log_ph1established(): ISAKMP-SA established 10.0.0.216[500]-10.0.0.11[500] spi:50397abe512587b4:7fbfed906953a464 22:42:38: INFO: isakmp.c:938:isakmp_ph2begin_i(): initiate new phase 2 negotiation: 10.0.0.216[0]<=>10.0.0.11[0] 22:42:38: INFO: pfkey.c:1106:pk_recvupdate(): IPsec-SA established: ESP/Transport 10.0.0.11->10.0.0.216 spi=222275495(0xd3fa7a7) 22:42:38: INFO: pfkey.c:1318:pk_recvadd(): IPsec-SA established: ESP/Transport 10.0.0.216->10.0.0.11 spi=57115683(0x3678423) 22:43:07: INFO: pfkey.c:1364:pk_recvexpire(): IPsec-SA expired: ESP/Transport 10.0.0.216->10.0.0.11 pfkey.log: 22:42:37.809959 sadb_msg{ version=2 type=6 errno=0 satype=3 len=47 reserved=0 seq=14 pid=0 sadb_ext{ len=3 type=5 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a0000d8 } sadb_ext{ len=3 type=6 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a00000b } sadb_ext{ len=2 type=18 } sadb_x_policy{ type=2 dir=2 id=81 } sadb_ext{ len=37 type=13 } sadb_prop{ replay=32 sadb_comb{ auth=2 encrypt=1 flags=0x0000 reserved=0x00000000 auth_minbits=128 auth_maxbits=128 encrypt_minbits=64 encrypt_maxbits=64 soft_alloc=0 hard_alloc=0 soft_bytes=0 hard_bytes=0 soft_alloc=72000 hard_alloc=86400 soft_bytes=25200 hard_bytes=28800 } sadb_comb{ auth=3 encrypt=1 flags=0x0000 reserved=0x00000000 auth_minbits=160 auth_maxbits=160 encrypt_minbits=64 encrypt_maxbits=64 soft_alloc=0 hard_alloc=0 soft_bytes=0 hard_bytes=0 soft_alloc=72000 hard_alloc=86400 soft_bytes=25200 hard_bytes=28800 } sadb_comb{ auth=2 encrypt=2 flags=0x0000 reserved=0x00000000 auth_minbits=128 auth_maxbits=128 encrypt_minbits=192 encrypt_maxbits=192 soft_alloc=0 hard_alloc=0 soft_bytes=0 hard_bytes=0 soft_alloc=72000 hard_alloc=86400 soft_bytes=25200 hard_bytes=28800 } sadb_comb{ auth=3 encrypt=2 flags=0x0000 reserved=0x00000000 auth_minbits=160 auth_maxbits=160 encrypt_minbits=192 encrypt_maxbits=192 soft_alloc=0 hard_alloc=0 soft_bytes=0 hard_bytes=0 soft_alloc=72000 hard_alloc=86400 soft_bytes=25200 hard_bytes=28800 } } 22:42:38.078871 sadb_msg{ version=2 type=1 errno=0 satype=3 len=10 reserved=0 seq=14 pid=8107 sadb_ext{ len=2 type=19 } sadb_x_sa2{ mode=1 reqid=0 reserved1=0 reserved2=0 sequence=0 } sadb_ext{ len=3 type=5 } sadb_address{ proto=255 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a00000b } sadb_ext{ len=3 type=6 } sadb_address{ proto=255 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a0000d8 } 22:42:38.079002 sadb_msg{ version=2 type=1 errno=0 satype=3 len=24 reserved=0 seq=14 pid=8107 sadb_ext{ len=2 type=1 } sadb_sa{ spi=222275495 replay=0 state=0 auth=0 encrypt=0 flags=0x00000000 } sadb_ext{ len=4 type=3 } sadb_lifetime{ alloc=0, bytes=0 addtime=30, usetime=0 } sadb_ext{ len=4 type=4 } sadb_lifetime{ alloc=0, bytes=0 addtime=0, usetime=0 } sadb_ext{ len=4 type=2 } sadb_lifetime{ alloc=0, bytes=0 addtime=1037050958, usetime=0 } sadb_ext{ len=3 type=5 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a00000b } sadb_ext{ len=3 type=6 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a0000d8 } sadb_ext{ len=2 type=19 } sadb_x_sa2{ mode=1 reqid=0 reserved1=0 reserved2=0 sequence=0 } 22:42:38.079056 sadb_msg{ version=2 type=10 errno=0 satype=0 len=2 reserved=0 seq=0 pid=8107 22:42:38.079073 sadb_msg{ version=2 type=10 errno=0 satype=3 len=24 reserved=0 seq=1 pid=8107 sadb_ext{ len=2 type=1 } sadb_sa{ spi=0 replay=0 state=0 auth=0 encrypt=0 flags=0x00000000 } sadb_ext{ len=4 type=3 } sadb_lifetime{ alloc=0, bytes=0 addtime=30, usetime=0 } sadb_ext{ len=4 type=4 } sadb_lifetime{ alloc=0, bytes=0 addtime=0, usetime=0 } sadb_ext{ len=4 type=2 } sadb_lifetime{ alloc=0, bytes=0 addtime=1037050957, usetime=0 } sadb_ext{ len=3 type=5 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a0000d8 } sadb_ext{ len=3 type=6 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a00000b } sadb_ext{ len=2 type=19 } sadb_x_sa2{ mode=1 reqid=0 reserved1=0 reserved2=0 sequence=0 } 22:42:38.079122 sadb_msg{ version=2 type=10 errno=0 satype=3 len=24 reserved=0 seq=0 pid=8107 sadb_ext{ len=2 type=1 } sadb_sa{ spi=222275495 replay=0 state=0 auth=0 encrypt=0 flags=0x00000000 } sadb_ext{ len=4 type=3 } sadb_lifetime{ alloc=0, bytes=0 addtime=30, usetime=0 } sadb_ext{ len=4 type=4 } sadb_lifetime{ alloc=0, bytes=0 addtime=0, usetime=0 } sadb_ext{ len=4 type=2 } sadb_lifetime{ alloc=0, bytes=0 addtime=1037050958, usetime=0 } sadb_ext{ len=3 type=5 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a00000b } sadb_ext{ len=3 type=6 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a0000d8 } sadb_ext{ len=2 type=19 } sadb_x_sa2{ mode=1 reqid=0 reserved1=0 reserved2=0 sequence=0 } 22:42:38.144461 sadb_msg{ version=2 type=2 errno=0 satype=3 len=28 reserved=0 seq=14 pid=8107 sadb_ext{ len=2 type=1 } sadb_sa{ spi=222275495 replay=4 state=0 auth=3 encrypt=2 flags=0x00000000 } sadb_ext{ len=2 type=19 } sadb_x_sa2{ mode=1 reqid=0 reserved1=0 reserved2=0 sequence=0 } sadb_ext{ len=3 type=5 } sadb_address{ proto=255 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a00000b } sadb_ext{ len=3 type=6 } sadb_address{ proto=255 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a0000d8 } sadb_ext{ len=4 type=9 } sadb_key{ bits=192 reserved=0 key= f5fbb657 9b12bea6 b7d2eeda 587a0961 8a94ff6e d7b79a28 } sadb_ext{ len=4 type=8 } sadb_key{ bits=160 reserved=0 key= 20c2a282 1909e8ab 1e4690c1 1ee6cb40 c6b24190 } sadb_ext{ len=4 type=3 } sadb_lifetime{ alloc=0, bytes=0 addtime=600, usetime=0 } sadb_ext{ len=4 type=4 } sadb_lifetime{ alloc=0, bytes=0 addtime=480, usetime=0 } 22:42:38.144673 sadb_msg{ version=2 type=2 errno=0 satype=3 len=27 reserved=0 seq=14 pid=8107 sadb_ext{ len=2 type=1 } sadb_sa{ spi=222275495 replay=4 state=1 auth=3 encrypt=2 flags=0x00000000 } sadb_ext{ len=4 type=3 } sadb_lifetime{ alloc=0, bytes=0 addtime=600, usetime=0 } sadb_ext{ len=4 type=4 } sadb_lifetime{ alloc=0, bytes=0 addtime=480, usetime=0 } sadb_ext{ len=4 type=2 } sadb_lifetime{ alloc=0, bytes=0 addtime=1037050958, usetime=0 } sadb_ext{ len=3 type=5 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a00000b } sadb_ext{ len=3 type=6 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a0000d8 } sadb_ext{ len=3 type=7 } sadb_address{ proto=255 prefixlen=0 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 00000000 } sadb_ext{ len=2 type=19 } sadb_x_sa2{ mode=1 reqid=0 reserved1=0 reserved2=0 sequence=0 } 22:42:38.144729 sadb_msg{ version=2 type=2 errno=0 satype=3 len=27 reserved=0 seq=14 pid=8107 sadb_ext{ len=2 type=1 } sadb_sa{ spi=222275495 replay=4 state=1 auth=3 encrypt=2 flags=0x00000000 } sadb_ext{ len=4 type=3 } sadb_lifetime{ alloc=0, bytes=0 addtime=600, usetime=0 } sadb_ext{ len=4 type=4 } sadb_lifetime{ alloc=0, bytes=0 addtime=480, usetime=0 } sadb_ext{ len=4 type=2 } sadb_lifetime{ alloc=0, bytes=0 addtime=1037050958, usetime=0 } sadb_ext{ len=3 type=5 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a00000b } sadb_ext{ len=3 type=6 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a0000d8 } sadb_ext{ len=3 type=7 } sadb_address{ proto=255 prefixlen=0 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 00000000 } sadb_ext{ len=2 type=19 } sadb_x_sa2{ mode=1 reqid=0 reserved1=0 reserved2=0 sequence=0 } 22:42:38.144836 sadb_msg{ version=2 type=3 errno=0 satype=3 len=28 reserved=0 seq=14 pid=8107 sadb_ext{ len=2 type=1 } sadb_sa{ spi=57115683 replay=4 state=0 auth=3 encrypt=2 flags=0x00000000 } sadb_ext{ len=2 type=19 } sadb_x_sa2{ mode=1 reqid=0 reserved1=0 reserved2=0 sequence=0 } sadb_ext{ len=3 type=5 } sadb_address{ proto=255 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a0000d8 } sadb_ext{ len=3 type=6 } sadb_address{ proto=255 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a00000b } sadb_ext{ len=4 type=9 } sadb_key{ bits=192 reserved=0 key= cc8e8e4f 91d41b7b ea6cbb3c 24a465cb a08b33aa c8ec1274 } sadb_ext{ len=4 type=8 } sadb_key{ bits=160 reserved=0 key= f454ab03 3a803ca4 05239de3 100ce68f d283f10a } sadb_ext{ len=4 type=3 } sadb_lifetime{ alloc=0, bytes=0 addtime=600, usetime=0 } sadb_ext{ len=4 type=4 } sadb_lifetime{ alloc=0, bytes=0 addtime=480, usetime=0 } 22:42:38.144909 sadb_msg{ version=2 type=3 errno=0 satype=3 len=27 reserved=0 seq=14 pid=8107 sadb_ext{ len=2 type=1 } sadb_sa{ spi=57115683 replay=4 state=1 auth=3 encrypt=2 flags=0x00000000 } sadb_ext{ len=4 type=3 } sadb_lifetime{ alloc=0, bytes=0 addtime=600, usetime=0 } sadb_ext{ len=4 type=4 } sadb_lifetime{ alloc=0, bytes=0 addtime=480, usetime=0 } sadb_ext{ len=4 type=2 } sadb_lifetime{ alloc=0, bytes=0 addtime=1037050958, usetime=0 } sadb_ext{ len=3 type=5 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a0000d8 } sadb_ext{ len=3 type=6 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a00000b } sadb_ext{ len=3 type=7 } sadb_address{ proto=255 prefixlen=0 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 00000000 } sadb_ext{ len=2 type=19 } sadb_x_sa2{ mode=1 reqid=0 reserved1=0 reserved2=0 sequence=0 } 22:42:38.145008 sadb_msg{ version=2 type=3 errno=0 satype=3 len=27 reserved=0 seq=14 pid=8107 sadb_ext{ len=2 type=1 } sadb_sa{ spi=57115683 replay=4 state=1 auth=3 encrypt=2 flags=0x00000000 } sadb_ext{ len=4 type=3 } sadb_lifetime{ alloc=0, bytes=0 addtime=600, usetime=0 } sadb_ext{ len=4 type=4 } sadb_lifetime{ alloc=0, bytes=0 addtime=480, usetime=0 } sadb_ext{ len=4 type=2 } sadb_lifetime{ alloc=0, bytes=0 addtime=1037050958, usetime=0 } sadb_ext{ len=3 type=5 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a0000d8 } sadb_ext{ len=3 type=6 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a00000b } sadb_ext{ len=3 type=7 } sadb_address{ proto=255 prefixlen=0 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 00000000 } sadb_ext{ len=2 type=19 } sadb_x_sa2{ mode=1 reqid=0 reserved1=0 reserved2=0 sequence=0 } 22:42:39.661881 sadb_msg{ version=2 type=10 errno=0 satype=0 len=2 reserved=0 seq=0 pid=8112 22:42:39.661992 sadb_msg{ version=2 type=10 errno=0 satype=3 len=35 reserved=0 seq=2 pid=8112 sadb_ext{ len=2 type=1 } sadb_sa{ spi=57115683 replay=4 state=1 auth=3 encrypt=2 flags=0x00000000 } sadb_ext{ len=4 type=3 } sadb_lifetime{ alloc=0, bytes=0 addtime=600, usetime=0 } sadb_ext{ len=4 type=4 } sadb_lifetime{ alloc=0, bytes=0 addtime=480, usetime=0 } sadb_ext{ len=4 type=2 } sadb_lifetime{ alloc=0, bytes=0 addtime=1037050958, usetime=0 } sadb_ext{ len=3 type=5 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a0000d8 } sadb_ext{ len=3 type=6 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a00000b } sadb_ext{ len=3 type=7 } sadb_address{ proto=255 prefixlen=0 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 00000000 } sadb_ext{ len=4 type=8 } sadb_key{ bits=160 reserved=0 key= f454ab03 3a803ca4 05239de3 100ce68f d283f10a } sadb_ext{ len=4 type=9 } sadb_key{ bits=192 reserved=0 key= cc8e8e4f 91d41b7b ea6cbb3c 24a465cb a08b33aa c8ec1274 } sadb_ext{ len=2 type=19 } sadb_x_sa2{ mode=1 reqid=0 reserved1=0 reserved2=0 sequence=0 } 22:42:39.662090 sadb_msg{ version=2 type=10 errno=0 satype=3 len=24 reserved=0 seq=1 pid=8112 sadb_ext{ len=2 type=1 } sadb_sa{ spi=0 replay=0 state=0 auth=0 encrypt=0 flags=0x00000000 } sadb_ext{ len=4 type=3 } sadb_lifetime{ alloc=0, bytes=0 addtime=30, usetime=0 } sadb_ext{ len=4 type=4 } sadb_lifetime{ alloc=0, bytes=0 addtime=0, usetime=0 } sadb_ext{ len=4 type=2 } sadb_lifetime{ alloc=0, bytes=0 addtime=1037050957, usetime=0 } sadb_ext{ len=3 type=5 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a0000d8 } sadb_ext{ len=3 type=6 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a00000b } sadb_ext{ len=2 type=19 } sadb_x_sa2{ mode=1 reqid=0 reserved1=0 reserved2=0 sequence=0 } 22:42:39.662139 sadb_msg{ version=2 type=10 errno=0 satype=3 len=35 reserved=0 seq=0 pid=8112 sadb_ext{ len=2 type=1 } sadb_sa{ spi=222275495 replay=4 state=1 auth=3 encrypt=2 flags=0x00000000 } sadb_ext{ len=4 type=3 } sadb_lifetime{ alloc=0, bytes=0 addtime=600, usetime=0 } sadb_ext{ len=4 type=4 } sadb_lifetime{ alloc=0, bytes=0 addtime=480, usetime=0 } sadb_ext{ len=4 type=2 } sadb_lifetime{ alloc=0, bytes=0 addtime=1037050958, usetime=0 } sadb_ext{ len=3 type=5 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a00000b } sadb_ext{ len=3 type=6 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a0000d8 } sadb_ext{ len=3 type=7 } sadb_address{ proto=255 prefixlen=0 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 00000000 } sadb_ext{ len=4 type=8 } sadb_key{ bits=160 reserved=0 key= 20c2a282 1909e8ab 1e4690c1 1ee6cb40 c6b24190 } sadb_ext{ len=4 type=9 } sadb_key{ bits=192 reserved=0 key= f5fbb657 9b12bea6 b7d2eeda 587a0961 8a94ff6e d7b79a28 } sadb_ext{ len=2 type=19 } sadb_x_sa2{ mode=1 reqid=0 reserved1=0 reserved2=0 sequence=0 } 22:43:05.077434 sadb_msg{ version=2 type=10 errno=0 satype=0 len=2 reserved=0 seq=0 pid=8126 22:43:05.077549 sadb_msg{ version=2 type=10 errno=0 satype=3 len=35 reserved=0 seq=2 pid=8126 sadb_ext{ len=2 type=1 } sadb_sa{ spi=57115683 replay=4 state=1 auth=3 encrypt=2 flags=0x00000000 } sadb_ext{ len=4 type=3 } sadb_lifetime{ alloc=0, bytes=0 addtime=600, usetime=0 } sadb_ext{ len=4 type=4 } sadb_lifetime{ alloc=0, bytes=0 addtime=480, usetime=0 } sadb_ext{ len=4 type=2 } sadb_lifetime{ alloc=0, bytes=0 addtime=1037050958, usetime=0 } sadb_ext{ len=3 type=5 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a0000d8 } sadb_ext{ len=3 type=6 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a00000b } sadb_ext{ len=3 type=7 } sadb_address{ proto=255 prefixlen=0 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 00000000 } sadb_ext{ len=4 type=8 } sadb_key{ bits=160 reserved=0 key= f454ab03 3a803ca4 05239de3 100ce68f d283f10a } sadb_ext{ len=4 type=9 } sadb_key{ bits=192 reserved=0 key= cc8e8e4f 91d41b7b ea6cbb3c 24a465cb a08b33aa c8ec1274 } sadb_ext{ len=2 type=19 } sadb_x_sa2{ mode=1 reqid=0 reserved1=0 reserved2=0 sequence=0 } 22:43:05.077646 sadb_msg{ version=2 type=10 errno=0 satype=3 len=24 reserved=0 seq=1 pid=8126 sadb_ext{ len=2 type=1 } sadb_sa{ spi=0 replay=0 state=0 auth=0 encrypt=0 flags=0x00000000 } sadb_ext{ len=4 type=3 } sadb_lifetime{ alloc=0, bytes=0 addtime=30, usetime=0 } sadb_ext{ len=4 type=4 } sadb_lifetime{ alloc=0, bytes=0 addtime=0, usetime=0 } sadb_ext{ len=4 type=2 } sadb_lifetime{ alloc=0, bytes=0 addtime=1037050957, usetime=0 } sadb_ext{ len=3 type=5 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a0000d8 } sadb_ext{ len=3 type=6 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a00000b } sadb_ext{ len=2 type=19 } sadb_x_sa2{ mode=1 reqid=0 reserved1=0 reserved2=0 sequence=0 } 22:43:05.077694 sadb_msg{ version=2 type=10 errno=0 satype=3 len=35 reserved=0 seq=0 pid=8126 sadb_ext{ len=2 type=1 } sadb_sa{ spi=222275495 replay=4 state=1 auth=3 encrypt=2 flags=0x00000000 } sadb_ext{ len=4 type=3 } sadb_lifetime{ alloc=0, bytes=0 addtime=600, usetime=0 } sadb_ext{ len=4 type=4 } sadb_lifetime{ alloc=0, bytes=0 addtime=480, usetime=0 } sadb_ext{ len=4 type=2 } sadb_lifetime{ alloc=0, bytes=0 addtime=1037050958, usetime=0 } sadb_ext{ len=3 type=5 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a00000b } sadb_ext{ len=3 type=6 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a0000d8 } sadb_ext{ len=3 type=7 } sadb_address{ proto=255 prefixlen=0 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 00000000 } sadb_ext{ len=4 type=8 } sadb_key{ bits=160 reserved=0 key= 20c2a282 1909e8ab 1e4690c1 1ee6cb40 c6b24190 } sadb_ext{ len=4 type=9 } sadb_key{ bits=192 reserved=0 key= f5fbb657 9b12bea6 b7d2eeda 587a0961 8a94ff6e d7b79a28 } sadb_ext{ len=2 type=19 } sadb_x_sa2{ mode=1 reqid=0 reserved1=0 reserved2=0 sequence=0 } 22:43:07.781122 sadb_msg{ version=2 type=8 errno=0 satype=3 len=20 reserved=0 seq=0 pid=0 sadb_ext{ len=2 type=1 } sadb_sa{ spi=0 replay=0 state=3 auth=0 encrypt=0 flags=0x00000000 } sadb_ext{ len=4 type=3 } sadb_lifetime{ alloc=0, bytes=0 addtime=30, usetime=0 } sadb_ext{ len=4 type=2 } sadb_lifetime{ alloc=0, bytes=0 addtime=1037050957, usetime=0 } sadb_ext{ len=3 type=5 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a0000d8 } sadb_ext{ len=3 type=6 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a00000b } sadb_ext{ len=2 type=19 } sadb_x_sa2{ mode=1 reqid=0 reserved1=0 reserved2=0 sequence=0 } 22:43:11.444772 sadb_msg{ version=2 type=10 errno=0 satype=0 len=2 reserved=0 seq=0 pid=8130 22:43:11.444967 sadb_msg{ version=2 type=10 errno=0 satype=3 len=35 reserved=0 seq=1 pid=8130 sadb_ext{ len=2 type=1 } sadb_sa{ spi=57115683 replay=4 state=1 auth=3 encrypt=2 flags=0x00000000 } sadb_ext{ len=4 type=3 } sadb_lifetime{ alloc=0, bytes=0 addtime=600, usetime=0 } sadb_ext{ len=4 type=4 } sadb_lifetime{ alloc=0, bytes=0 addtime=480, usetime=0 } sadb_ext{ len=4 type=2 } sadb_lifetime{ alloc=0, bytes=0 addtime=1037050958, usetime=0 } sadb_ext{ len=3 type=5 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a0000d8 } sadb_ext{ len=3 type=6 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a00000b } sadb_ext{ len=3 type=7 } sadb_address{ proto=255 prefixlen=0 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 00000000 } sadb_ext{ len=4 type=8 } sadb_key{ bits=160 reserved=0 key= f454ab03 3a803ca4 05239de3 100ce68f d283f10a } sadb_ext{ len=4 type=9 } sadb_key{ bits=192 reserved=0 key= cc8e8e4f 91d41b7b ea6cbb3c 24a465cb a08b33aa c8ec1274 } sadb_ext{ len=2 type=19 } sadb_x_sa2{ mode=1 reqid=0 reserved1=0 reserved2=0 sequence=0 } 22:43:11.445063 sadb_msg{ version=2 type=10 errno=0 satype=3 len=35 reserved=0 seq=0 pid=8130 sadb_ext{ len=2 type=1 } sadb_sa{ spi=222275495 replay=4 state=1 auth=3 encrypt=2 flags=0x00000000 } sadb_ext{ len=4 type=3 } sadb_lifetime{ alloc=0, bytes=0 addtime=600, usetime=0 } sadb_ext{ len=4 type=4 } sadb_lifetime{ alloc=0, bytes=0 addtime=480, usetime=0 } sadb_ext{ len=4 type=2 } sadb_lifetime{ alloc=0, bytes=0 addtime=1037050958, usetime=0 } sadb_ext{ len=3 type=5 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a00000b } sadb_ext{ len=3 type=6 } sadb_address{ proto=0 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 0a0000d8 } sadb_ext{ len=3 type=7 } sadb_address{ proto=255 prefixlen=0 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 00000000 } sadb_ext{ len=4 type=8 } sadb_key{ bits=160 reserved=0 key= 20c2a282 1909e8ab 1e4690c1 1ee6cb40 c6b24190 } sadb_ext{ len=4 type=9 } sadb_key{ bits=192 reserved=0 key= f5fbb657 9b12bea6 b7d2eeda 587a0961 8a94ff6e d7b79a28 } sadb_ext{ len=2 type=19 } sadb_x_sa2{ mode=1 reqid=0 reserved1=0 reserved2=0 sequence=0 } > If you prepare "setkey -x >& pfkey.log &" it will make the things > much easier to track. Please, remember, at the moment I do not have > capabilities to make any experiments here. Probably, this is for good > (stimulates imagination :-)), but I really need to have full information > to debug and not to imagine too far. :-) I can give you access to my computers if you want? I have three available here. I hope this helps. Full setup on both sides: On 10.0.0.216: #!/home/ahu/download/kametools/setkey/setkey -f flush; spdflush; spdadd 10.0.0.216 10.0.0.11 tcp -P out ipsec esp/transport//require; spdadd 10.0.0.11 10.0.0.216 tcp -P in ipsec esp/transport//require; On 10.0.0.11: #!./setkey -f flush; spdflush; spdadd 10.0.0.11 10.0.0.216 tcp -P out ipsec esp/transport//require; spdadd 10.0.0.216 10.0.0.11 tcp -P in ipsec esp/transport//require; racoon.conf, identical on both (verified): path pre_shared_key "./psk.txt" ; remote anonymous { exchange_mode aggressive,main; doi ipsec_doi; situation identity_only; my_identifier address; nonce_size 16; lifetime time 10 min; # sec,min,hour initial_contact on; support_mip6 on; proposal_check obey; # obey, strict or claim proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key ; dh_group 2 ; } } sainfo anonymous { pfs_group 1; lifetime time 10 min; encryption_algorithm 3des ; authentication_algorithm hmac_sha1; compression_algorithm deflate ; } Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From swaters@amicus.com Mon Nov 11 20:36:16 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Nov 2002 20:36:20 -0800 (PST) Received: from mail.luy.info (dsl-64-130-108-165.telocity.com [64.130.108.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAC4aFuR024350 for ; Mon, 11 Nov 2002 20:36:15 -0800 Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.luy.info (Postfix) with ESMTP id A84212272F; Mon, 11 Nov 2002 22:37:42 -0600 (CST) Subject: [Fwd: Re: macmace transmit timeout] From: Stephen Waters To: netdev@oss.sgi.com Cc: Ben Stanley Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-lPHg0K8L+jGol/37CcXo" X-Mailer: Ximian Evolution 1.0.8 Date: 11 Nov 2002 22:37:42 -0600 Message-Id: <1037075862.3036.21.camel@arrakeen> Mime-Version: 1.0 X-archive-position: 1159 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: swaters@amicus.com Precedence: bulk X-list: netdev --=-lPHg0K8L+jGol/37CcXo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ben, I'm forwarding this to netdev in hopes someone there might have a clue... -s Ben Stanley wrote: >=20 > Kernel version: >=20 > Linux version 2.4.20-pre4 (kato@hiryu) (gcc version 2.95.4 20010319 > (prerelease/franzo/20010623)) #1 2002=C7=AF 8=B7=EE 20=C6=FC =B2=D0=CD=CB= =C6=FC 12:25:37 JST > it was built by Etsushi Kato, so it's the file > MachKernel-2.4.20-pre4-020820=20 > from his ftp site. >=20 > This message has been in the kernel ever since I started using the > nubus-pmac port about 2 years ago. >=20 > Network setup: >=20 > -------------------------------------------------------------- > | | | | > 192.168.1.2 192.168.12 192.168.1.13 192.168.1.1 > nfs and x server mp3 player (6100/66) xterminal firewall > dragon kangaeru komodo ipcop > xxx.xxx.xxx.xxx > | > outside world -------- >=20 >=20 > There's lots of traffic on the network when the x terminal is in use. > The network uses hubs, not switches. >=20 > kernel startup detects the network controller as: > Nov 12 10:58:40 kangaeru kernel: eth0: MACE at 08:00:07:37:04:95, chip > revision 0x0940 >=20 > The problem hasn't happened today, and I didn't notice it happen while > it was playing all day yesterday. It's quite intermittent. However, > yesterday's logs are full of the message: >=20 > Nov 11 17:30:35 kangaeru kernel: macmace: transmit timeout - resetting > Nov 11 18:01:35 kangaeru kernel: macmace: transmit timeout - resetting > Nov 11 18:21:07 kangaeru kernel: macmace: transmit timeout - resetting > Nov 11 18:22:57 kangaeru kernel: macmace: transmit timeout - resetting > Nov 11 18:27:41 kangaeru kernel: macmace: transmit timeout - resetting >=20 > So maybe there is no association after all. I'm not sure. >=20 > Ben. >=20 > On Tue, 2002-11-12 at 01:54, Stephen Waters wrote: > >=20 > > kernel version? your network setup? > >=20 > > On Sat, 2002-11-09 at 19:55, Ben Stanley wrote: > > > > > > I use my 6100/66 as a network mp3 player, and periodically it stops f= or > > > about 30 seconds, for no apparent reason. checked the logs, and at > > > about the time of the silence, I see this message: > > > > > > Nov 10 12:29:37 kangaeru kernel: macmace: transmit timeout - resetting > > > > > > what's going on? --=-lPHg0K8L+jGol/37CcXo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA90IWWvSyJ32tBS68RAgL6AKCtFc+0Y28Ew5/0o5BGZ7jCZwzr5wCg3br4 55bituQxOVyOB/o1V6RMwF8= =VLGN -----END PGP SIGNATURE----- --=-lPHg0K8L+jGol/37CcXo-- From iss1000@vsnl.net Tue Nov 12 04:42:25 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Nov 2002 04:42:30 -0800 (PST) Received: from smtp01.vsnl.net (smtp01.vsnl.net [203.197.12.7]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACCgMuR014855 for ; Tue, 12 Nov 2002 04:42:24 -0800 Received: from patricia ([203.197.12.7]) by smtp01.vsnl.net (Netscape Messaging Server 4.15) with SMTP id H5GRD101.U5V for ; Tue, 12 Nov 2002 18:13:49 +0530 Received: from ([203.197.55.150]) by smtp01 (InterScan E-Mail VirusWall Unix); Tue, 12 Nov 2002 18:13:49 +0530 (IST) Message-ID: <027a01c28a49$23b7f7e0$2b01a8c0@eth.net> From: "Tarun Chopra" To: Subject: Hi Date: Tue, 12 Nov 2002 12:31:28 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 1425 X-archive-position: 1160 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: iss1000@vsnl.net Precedence: bulk X-list: netdev Hello !! It is my pleasure to introduce India Software Solution, a service providing company for Web Designing and Web Development. We also undertake annual maintainance contract ( AMC ). I have a clientele spread over the United States and Europe . I have been designing, developing and maintaining their sites since their inception. I would like to put forward my services for your site's Redesigning and maintainance. If you are currently have a website which needs some modification's or updates then please consider my service for the same. I know it's really difficult & risky to entrust maintainence of a site which has been running continously as there are chances that the site's image will be seriously hampered if it's not up & running in the specified time and manner, but I can gurantee with a backing of an experienced and highly skilled Design and Development team who have been in the field for not less than five years. If you have any questions please feel free to contact me on either of the following email-id or IM's. We can even give you a call if required, as per the time favourable to you. Let me know your phone number. Email -: iss1000@vsnl.net Yahoo Messenger -: tarunchopra_in@yahoo.com MSN -: tarunchopra@hotmail.com ICQ Number -: 95017045 Looking forward to long term relationship. Thanking You, Tarun Chopra (www.indiasoftwaresolution.com) [[HTML alternate version deleted]] From kuznet@ms2.inr.ac.ru Tue Nov 12 05:55:51 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Nov 2002 05:55: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 gACDtnuR016399 for ; Tue, 12 Nov 2002 05:55:51 -0800 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id QAA00322; Tue, 12 Nov 2002 16:55:57 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200211121355.QAA00322@sex.inr.ac.ru> Subject: Re: off by one error in 3des cbc keying To: ahu@ds9a.nl (bert hubert) Date: Tue, 12 Nov 2002 16:55:57 +0300 (MSK) Cc: davem@redhat.com, gem@asplinux.ru, netdev@oss.sgi.com In-Reply-To: <20021111200321.GA30957@outpost.ds9a.nl> from "bert hubert" at Nov 11, 2 09:03:21 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 1161 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! > > It is. But your example shows that something is wrong there. Fix will follow > > later. > > Ok, let me know if I can test. Enclosed. Comments for Dave: 1. udp.c: silly bug, local input policy did not work on udp sockets. 2. ah.c,esp.c: even sillier bug: 0 was used as tunnels protocol. Funny enough, it worked between linuxes. :-) By Another fix for wrongly formatted ICV for ESP will follow tonight after test for interoperability with freebsd. The problem with expiration remains unsolved. I still cannot reproduce this and cannot find a situation when kernel can create two larvals with one identity. :-( Searching. Alexey ===== net/ipv4/ah.c 1.6 vs edited ===== --- 1.6/net/ipv4/ah.c Fri Nov 8 11:34:37 2002 +++ edited/net/ipv4/ah.c Tue Nov 12 02:43:59 2002 @@ -189,7 +189,7 @@ top_iph->saddr = x->props.saddr.xfrm4_addr; top_iph->daddr = x->id.daddr.xfrm4_addr; ah = (struct ip_auth_hdr*)(top_iph+1); - ah->nexthdr = IPPROTO_IP; + ah->nexthdr = IPPROTO_IPIP; } else { memcpy(&tmp_iph, skb->data, iph->ihl*4); top_iph = (struct iphdr*)skb_push(skb, x->props.header_len); ===== net/ipv4/esp.c 1.4 vs edited ===== --- 1.4/net/ipv4/esp.c Fri Nov 8 11:34:37 2002 +++ edited/net/ipv4/esp.c Tue Nov 12 02:43:59 2002 @@ -370,7 +370,7 @@ if (x->props.mode) { top_iph = (struct iphdr*)skb_push(skb, x->props.header_len); esph = (struct ip_esp_hdr*)(top_iph+1); - *(u8*)(trailer->tail - 1) = IPPROTO_IP; + *(u8*)(trailer->tail - 1) = IPPROTO_IPIP; top_iph->ihl = 5; top_iph->version = 4; top_iph->tos = iph->tos; /* DS disclosed */ ===== net/ipv4/udp.c 1.27 vs edited ===== --- 1.27/net/ipv4/udp.c Tue Nov 12 02:37:12 2002 +++ edited/net/ipv4/udp.c Tue Nov 12 16:30:49 2002 @@ -944,7 +944,7 @@ /* * Charge it to the socket, dropping if the queue is full. */ - if (!xfrm_policy_check(NULL, XFRM_POLICY_IN, skb)) { + if (!xfrm_policy_check(sk, XFRM_POLICY_IN, skb)) { kfree_skb(skb); return -1; } ===== net/ipv4/xfrm_input.c 1.3 vs edited ===== --- 1.3/net/ipv4/xfrm_input.c Fri Nov 8 11:34:37 2002 +++ edited/net/ipv4/xfrm_input.c Tue Nov 12 02:43:59 2002 @@ -91,7 +91,7 @@ iph = skb->nh.iph; if (x->props.mode) { - if (iph->protocol != IPPROTO_IP) + if (iph->protocol != IPPROTO_IPIP) goto drop; skb->nh.raw = skb->data; iph = skb->nh.iph; From blueflux@koffein.net Tue Nov 12 07:02:18 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Nov 2002 07:02:21 -0800 (PST) Received: from laptop1.agatha ([195.163.42.242]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACF2GuR020436 for ; Tue, 12 Nov 2002 07:02:18 -0800 Received: from localhost (blueflux@localhost) by laptop1.agatha (8.11.6/8.11.6) with ESMTP id gACEvUJ18970; Tue, 12 Nov 2002 15:57:31 +0100 X-Authentication-Warning: laptop1.agatha: blueflux owned process doing -bs Date: Tue, 12 Nov 2002 15:57:29 +0100 (CET) From: Oskar Andreasson X-X-Sender: blueflux@laptop1.agatha To: "Alexey N. Kuznetsov" , "David S. Miller" cc: netdev@oss.sgi.com Subject: [patches] documentation of sysctl's Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463810815-694467300-1037113049=:18963" X-archive-position: 1162 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: blueflux@koffein.net 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. ---1463810815-694467300-1037113049=:18963 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi everyone, Second round for one of these patches, and first for the other. I apparently made a few mistakes in the original patches. Many thanks to Jamal for pointing them out, and for helping me out with the patches in all aspects. ----- Patch 1. The first patch for ip-sysctl.txt changes the description of the tcp_syncookies ipsysctl. I originally based my own texts rather heavily on these paragraphs, and got tons of response to that part from all over. I don't want to start a flamewar over this, since I have seen the previous threads on this topic:). If you want to drop the patch, do so, but please tell me why in such case? Michael Babcock originally pointed this problem out to me, and since then it seems that Alan Cox and Jamal also thinks that the current text is bad. ---- Patch 2. The second patch fixes the documentation for the /proc/sys/net/ipv4/route/error_cost and error_burst in linux/Documentation/filesystems/proc.txt. This is the second round for this patch, a huge thanks to Jamal for pointing out what was originally bad, and what should be fixed. I can't see any problems in applying this patch. ---- Does anyone have any objections or problems with these patches? Please let me know. ---- Oskar Andreasson http://www.frozentux.net http://iptables-tutorial.frozentux.net http://ipsysctl-tutorial.frozentux.net mailto:blueflux@koffein.net ---1463810815-694467300-1037113049=:18963 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="2.4.19.docs.net.ip-sysctl.txt-2.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="2.4.19.docs.net.ip-sysctl.txt-2.patch" ZGlmZiAtdXIgbGludXgtMi40LjE5L0RvY3VtZW50YXRpb24vbmV0d29ya2lu Zy9pcC1zeXNjdGwudHh0IGxpbnV4LTIuNC4xOS5uZXcvRG9jdW1lbnRhdGlv bi9uZXR3b3JraW5nL2lwLXN5c2N0bC50eHQNCi0tLSBsaW51eC0yLjQuMTkv RG9jdW1lbnRhdGlvbi9uZXR3b3JraW5nL2lwLXN5c2N0bC50eHQJU2F0IEF1 ZyAgMyAwMjozOTo0MiAyMDAyDQorKysgbGludXgtMi40LjE5Lm5ldy9Eb2N1 bWVudGF0aW9uL25ldHdvcmtpbmcvaXAtc3lzY3RsLnR4dAlTdW4gTm92IDEw IDE4OjEzOjI2IDIwMDINCkBAIC0xNjIsNyArMTYyLDcgQEANCiAJb3ZlcmZs b3dzLiBUaGlzIGlzIHRvIHByZXZlbnQgYWdhaW5zdCB0aGUgY29tbW9uICdz eW4gZmxvb2QgYXR0YWNrJw0KIAlEZWZhdWx0OiBGQUxTRQ0KIA0KLQlOb3Rl LCB0aGF0IHN5bmNvb2tpZXMgaXMgZmFsbGJhY2sgZmFjaWxpdHkuDQorCU5v dGUsIHRoYXQgc3luY29va2llcyBpcyBhIGZhbGxiYWNrIGZhY2lsaXR5Lg0K IAlJdCBNVVNUIE5PVCBiZSB1c2VkIHRvIGhlbHAgaGlnaGx5IGxvYWRlZCBz ZXJ2ZXJzIHRvIHN0YW5kDQogCWFnYWluc3QgbGVnYWwgY29ubmVjdGlvbiBy YXRlLiBJZiB5b3Ugc2VlIHN5bmZsb29kIHdhcm5pbmdzDQogCWluIHlvdXIg bG9ncywgYnV0IGludmVzdGlnYXRpb24Jc2hvd3MgdGhhdCB0aGV5IG9jY3Vy DQpAQCAtMTcwLDEyICsxNzAsMTggQEANCiAJYW5vdGhlciBwYXJhbWV0ZXJz IHVudGlsIHRoaXMgd2FybmluZyBkaXNhcHBlYXIuDQogCVNlZTogdGNwX21h eF9zeW5fYmFja2xvZywgdGNwX3N5bmFja19yZXRyaWVzLCB0Y3BfYWJvcnRf b25fb3ZlcmZsb3cuDQogDQotCXN5bmNvb2tpZXMgc2VyaW91c2x5IHZpb2xh dGUgVENQIHByb3RvY29sLCBkbyBub3QgYWxsb3cNCi0JdG8gdXNlIFRDUCBl eHRlbnNpb25zLCBjYW4gcmVzdWx0IGluIHNlcmlvdXMgZGVncmFkYXRpb24N Ci0Jb2Ygc29tZSBzZXJ2aWNlcyAoZi5lLiBTTVRQIHJlbGF5aW5nKSwgdmlz aWJsZSBub3QgYnkgeW91LA0KLQlidXQgeW91ciBjbGllbnRzIGFuZCByZWxh eXMsIGNvbnRhY3RpbmcgeW91LiBXaGlsZSB5b3Ugc2VlDQotCXN5bmZsb29k IHdhcm5pbmdzIGluIGxvZ3Mgbm90IGJlaW5nIHJlYWxseSBmbG9vZGVkLCB5 b3VyIHNlcnZlcg0KLQlpcyBzZXJpb3VzbHkgbWlzY29uZmlndXJlZC4NCisJ VGhlIHRjcF9zeW5jb29raWVzIG9wdGlvbiBtZWFucyB0aGF0IHdoZW4gdGhl IG1hY2hpbmUgaGFzIG1vcmUgdGhhbiANCisJdGNwX21heF9zeW5fYmFja2xv ZyBTWU4gcGFja2V0cyBpbiB0aGUgcXVldWUsIGl0IHdpbGwgcmV2ZXJ0IHRv IA0KKwlzZW5kaW5nIG91dCBTWU4gY29va2llcy4gdGNwX3N5bmNvb2tpZXMg ZGVwZW5kcyBvbiBhIHNwZWNpZmljYWxseSANCisJZ3JhZnRlZCBUQ1AgU2Vx dWVuY2UgbnVtYmVyLCB3aGljaCB0aGUgU1lOIGZsb29kZXIgbXVzdCBndWVz cyB0aGUgDQorCWNvcnJlY3QgbnVtYmVyIG9mLCB1bmxlc3MgaGUgaXMgYWN0 dWFsbHkgcmVjZWl2aW5nIHRoZSBTWU4vQUNLIHRvDQorCWhpbXNlbGYuIA0K Kw0KKwlXaGVuIFNZTiBjb29raWVzIGFyZSB1c2VkLCBhbGwgbmV3bHkgb3Bl bmVkIGNvbm5lY3Rpb25zIHdpbGwgYmUgdW5hYmxlDQorCXRvIHVzZSBhbnkg YWR2YW5jZWQgZmVhdHVyZXMgbGlrZSBFQ04sIFNBQ0sgb3IgVGltZXN0YW1w cy4gVGhpcyBtYXkgDQorCXJlc3VsdCBpbiBzZXJpb3VzIGRlZ3JhZGF0aW9u IG9mIHNvbWUgc2VydmljZXMsIGFuZCBpZiB5b3Ugc2VlIA0KKwlzeW5mbG9v ZCB3YXJuaW5ncyBpbiB5b3VyIGxvZ3MsIGJ1dCB5b3UgYXJlIG5vdCBiZWlu ZyBmbG9vZGVkLCB5b3VyIA0KKwlzZXJ2ZXIgbWF5IGJlIG1pc2NvbmZpZ3Vy ZWQuDQogDQogdGNwX3N0ZHVyZyAtIEJPT0xFQU4NCiAJVXNlIHRoZSBIb3N0 IHJlcXVpcmVtZW50cyBpbnRlcnByZXRhdGlvbiBvZiB0aGUgVENQIHVyZyBw b2ludGVyIGZpZWxkLg0K ---1463810815-694467300-1037113049=:18963 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="2.4.19.docs.fs.proc.txt-3.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="2.4.19.docs.fs.proc.txt-3.patch" ZGlmZiAtdXIgbGludXgtMi40LjE5L0RvY3VtZW50YXRpb24vZmlsZXN5c3Rl bXMvcHJvYy50eHQgbGludXgtMi40LjE5Lm5ldy9Eb2N1bWVudGF0aW9uL2Zp bGVzeXN0ZW1zL3Byb2MudHh0DQotLS0gbGludXgtMi40LjE5L0RvY3VtZW50 YXRpb24vZmlsZXN5c3RlbXMvcHJvYy50eHQJV2VkIE5vdiAgNyAyMzozOToz NiAyMDAxDQorKysgbGludXgtMi40LjE5Lm5ldy9Eb2N1bWVudGF0aW9uL2Zp bGVzeXN0ZW1zL3Byb2MudHh0CVN1biBOb3YgMTAgMTM6MDk6MjUgMjAwMg0K QEAgLTE1OTIsMTAgKzE1OTIsMzIgQEANCiBlcnJvcl9idXJzdCBhbmQgZXJy b3JfY29zdA0KIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogDQotVGhl c2UgcGFyYW1ldGVycyAgYXJlIHVzZWQgdG8gbGltaXQgdGhlIHdhcm5pbmcg bWVzc2FnZXMgd3JpdHRlbiB0byB0aGUga2VybmVsDQotbG9nIGZyb20gIHRo ZSAgcm91dGluZyAgY29kZS4gIFRoZSAgaGlnaGVyIHRoZSBlcnJvcl9jb3N0 IGZhY3RvciBpcywgdGhlIGZld2VyDQotbWVzc2FnZXMgd2lsbCAgYmUgd3Jp dHRlbi4gRXJyb3JfYnVyc3QgY29udHJvbHMgd2hlbiBtZXNzYWdlcyB3aWxs IGJlIGRyb3BwZWQuDQotVGhlIGRlZmF1bHQgc2V0dGluZ3MgbGltaXQgd2Fy bmluZyBtZXNzYWdlcyB0byBvbmUgZXZlcnkgZml2ZSBzZWNvbmRzLg0KK1Ro ZXNlICBwYXJhbWV0ZXJzICBhcmUgdXNlZCB0byBsaW1pdCBob3cgbWFueSBJ Q01QIGRlc3RpbmF0aW9uIHVucmVhY2hhYmxlIHRvIA0KK3NlbmQgIGZyb20g IHRoZSAgaG9zdCAgaW4gcXVlc3Rpb24uIElDTVAgZGVzdGluYXRpb24gdW5y ZWFjaGFibGUgbWVzc2FnZXMgYXJlDQorc2VudCB0aHJvdWdoIHRoZSBjb2Rl IGNvbnRyb2xsZWQgYnkgdGhlc2UgcGFyYW1ldGVycyBpbiB0aHJlZSBldmVu dHM6DQorDQorMS4gV2UgY2FuIG5vdCByZWFjaCB0aGUgbmV4dGhvcC4NCisy LiBXZSBoYXZlIG5vIHJvdXRlIHNldCB1cCBmb3IgdGhlIG5ldHdvcmsgc2Vn bWVudCBvciBob3N0Lg0KKzMuIFdlIGhhdmUgYSByb3V0aW5nIHJ1bGUgb3Ig cm91dGUgc2V0IHRvIHVucmVhY2hhYmxlLCB0aHJvdyBvciBwcm9oaWJpdC4N CisNCitUaGUgIG5ldHdvcmtpbmcgY29kZSBpbiBxdWVzdGlvbiB0aGVuIHNl bmRzIG91dCBJQ01QIGRlc3RpbmF0aW9uIHVucmVhY2hhYmxlcw0KK3dpdGgg dGhyZWUgZGlmZmVyZW50IGNvZGVzIGlmIG5lY2Vzc2FyeToNCisNCisxLiBJ Q01QICBob3N0ICB1bnJlYWNoYWJsZSBpbiBjYXNlIHRoZSBob3N0IHNob3Vs ZCBiZSBkaXJlY3RseSBjb25uZWN0ZWQgdG8gYSANCisgICBuZXR3b3JrICB3 ZSAgYXJlICBwYXJ0ICBvZiwgb3IgaWYgdGhlIGhvc3Qgd2FzIHNldCB0byB1 bnJlYWNoYWJsZSBvciB0aHJvdw0KKyAgIHRocm91Z2ggYSBydWxlIG9yIHJv dXRlLg0KKzIuIElDTVAgIG5ldHdvcmsgIHVucmVhY2hhYmxlICBpZiAgd2Ug ZG8gbm90IGtub3cgaG93IHRvIHJlYWNoIHRoZSBuZXR3b3JrIGluIA0KKyAg IHF1ZXN0aW9uLCAgb3IgIGlmICB0aGUgIG5ldHdvcmsgIHdhcyBzZXQgdG8g dW5yZWFjaGFibGUgb3IgdGhyb3cgdGhyb3VnaCBhIA0KKyAgIHJ1bGUgb3Ig cm91dGUuDQorMy4gSUNNUCAgY29tbXVuaWNhdGlvbiBhZG1pbmlzdHJhdGl2 ZWx5IHByb2hpYml0ZWQgYnkgZmlsdGVyaW5nIGlzIHNlbnQgaWYgd2UgDQor ICAgaGF2ZSBhIHJ1bGUgb3Igcm91dGUgc2V0IHRvIHByb2hpYml0Lg0KKw0K K0l0ICB3aWxsIGFsc28gcHJpbnQgc29tZSBlcnJvciBtZXNzYWdlcyB0byBr ZXJuZWwgbG9ncyBpZiBzb21lb25lIGlzIGlnbm9yaW5nIA0KK291ciAgIElD TVAgIHJlZGlyZWN0cy4gIFRoZSAgaGlnaGVyICB0aGUgIGVycm9yX2Nvc3Qg IGZhY3RvciAgaXMsICB0aGUgIGZld2VyIA0KK2Rlc3RpbmF0aW9uICB1bnJl YWNoYWJsZSAgYW5kIGVycm9yIG1lc3NhZ2VzIHdpbGwgYmUgbGV0IHRocm91 Z2guIEVycm9yX2J1cnN0IA0KK2NvbnRyb2xzICB3aGVuICBkZXN0aW5hdGlv biAgdW5yZWFjaGFibGUgIG1lc3NhZ2VzIGFuZCBlcnJvciBtZXNzYWdlcyB3 aWxsIGJlDQorZHJvcHBlZC4gVGhlIGRlZmF1bHQgc2V0dGluZ3MgbGltaXQg d2FybmluZyBtZXNzYWdlcyBhbmQgbG9nIG1lc3NhZ2VzIHRvIGZpdmUNCitl dmVyeSBzZWNvbmQuDQogDQogZmx1c2gNCiAtLS0tLQ0K ---1463810815-694467300-1037113049=:18963-- From Robert.Olsson@data.slu.se Tue Nov 12 07:06:09 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Nov 2002 07:06:11 -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 gACF68uR020864 for ; Tue, 12 Nov 2002 07:06:08 -0800 Received: (from robert@localhost) by robur.slu.se (8.9.3/8.9.3) id QAA27304; Tue, 12 Nov 2002 16:15:34 +0100 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15825.6934.241737.714418@robur.slu.se> Date: Tue, 12 Nov 2002 16:15:34 +0100 To: jamal Cc: "'netdev@oss.sgi.com'" Subject: packet forward tests w. 2.5.46 X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 1163 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 Hello! Here are some the of the packet forwarding tests we did before. Now moved to recent 2.5.46 w. XEON 1.8 GHz, SeverWorks, e1000 dual-port w. 82546. and 4.4.12-k1 from kernel tree. 10 Mpkts at rate of 817 kpps (64 bytes pkts) injected into eth0 and forwarded to eth1. TX-OK on eth1 gives the throughput. Vanlilla NAPI ============= netstat -i eth0 1500 0 4488490 7703683 7703683 5511514 22 0 0 0 BRU eth1 1500 0 22 0 0 0 4488490 0 0 0 BRU irq's 24: 47 IO-APIC-level eth0 25: 39744 IO-APIC-level eth1 softnet_stat 00447d48 00000000 00003af5 00000000 00000000 00000000 00000000 00000000 00000000 Vanilla kernel (w. NAPI) has now a very decent performance of 367 kpps. Vanilla above plus exerimental skb-recycling. ============================================= robur.slu.se:/pub/Linux/net-development/skb_recycling/ recycle14.pat and e1000-RC-021112.pat eth0 1500 0 5635546 6762949 6762949 4364460 26 0 0 0 BRU eth1 1500 0 26 0 0 0 5635550 0 0 0 BRU 24: 56 IO-APIC-level eth0 25: 68406 IO-APIC-level eth1 0055fdfc 00000000 00004a44 00000000 00000000 00000000 00000000 00000000 00000000 We improve to 460 kpps which is about 25% increase in packet budget. Vanilla without NAPI and RC. ============================ eth0 1500 0 7512826 5116105 5116105 2487178 9 0 0 0 BRU eth1 1500 0 11 0 0 0 305 0 0 0 BRU 24: 11803 IO-APIC-level eth0 25: 68 IO-APIC-level eth1 0072a447 0072a1cb 00000002 00000001 00000000 00000000 00000000 00000000 00000000 0 pps :-) Enabling link-flowcontol would proably have helped. But there are equipment around that misses it... SMP next... Cheers. --ro PS! Note interface counters RX-ERR, RX-DRP get screwed up in this tests. But RX-OK+ RX-OVR counts the RX-pkts. From kuznet@ms2.inr.ac.ru Tue Nov 12 07:28:21 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Nov 2002 07:28:24 -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 gACFSKuR021510 for ; Tue, 12 Nov 2002 07:28:21 -0800 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id SAA00584; Tue, 12 Nov 2002 18:29:06 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200211121529.SAA00584@sex.inr.ac.ru> Subject: Re: off by one error in 3des cbc keying To: ahu@ds9a.nl (bert hubert) Date: Tue, 12 Nov 2002 18:29:06 +0300 (MSK) Cc: davem@redhat.com, gem@asplinux.ru, netdev@oss.sgi.com In-Reply-To: <20021112151638.GA18488@outpost.ds9a.nl> from "bert hubert" at Nov 12, 2 04:16:38 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 1164 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! > > The problem with expiration remains unsolved. I still cannot reproduce this > > and cannot find a situation when kernel can create two larvals with one > > identity. :-( Searching. > > Sure you saw that? I only saw the one larval in the output I sent you, Sure, unless my sick cisco router corrupts mails. But I hope it is not so malicious. :-) Joke aparts, of course, I did not see this, it exists for short time, you see one of them already grown to mature. 10.0.0.216 10.0.0.11 esp mode=transport spi=57115683(0x03678423) reqid=0(0x00000000) E: 3des-cbc cc8e8e4f 91d41b7b ea6cbb3c 24a465cb a08b33aa c8ec1274 A: hmac-sha1 f454ab03 3a803ca4 05239de3 100ce68f d283f10a seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Nov 11 22:42:38 2002 current: Nov 11 22:43:05 2002 diff: 27(s) hard: 600(s) soft: 480(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=2 pid=8126 refcnt=0 10.0.0.216 10.0.0.11 esp mode=transport spi=0(0x00000000) reqid=0(0x00000000) seq=0x00000000 replay=0 flags=0x00000000 state=larval created: Nov 11 22:42:37 2002 current: Nov 11 22:43:05 2002 diff: 28(s) hard: 30(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=1 pid=8126 refcnt=0 This MUST NOT happen. The first one was larval while for a second before line: 22:42:38: INFO: pfkey.c:1106:pk_recvupdate(): IPsec-SA established: ESP/Transport 10.0.0.11->10.0.0.216 spi=222275495(0xd3fa7a7) Essentially, seeing this you see a bug in kernel. Alexey From ahu@outpost.ds9a.nl Tue Nov 12 07:57:14 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Nov 2002 07:57:15 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACFv3uR022487 for ; Tue, 12 Nov 2002 07:57:03 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 7829A4523; Tue, 12 Nov 2002 16:16:38 +0100 (CET) Date: Tue, 12 Nov 2002 16:16:38 +0100 From: bert hubert To: kuznet@ms2.inr.ac.ru Cc: davem@redhat.com, gem@asplinux.ru, netdev@oss.sgi.com Subject: Re: off by one error in 3des cbc keying Message-ID: <20021112151638.GA18488@outpost.ds9a.nl> Mail-Followup-To: bert hubert , kuznet@ms2.inr.ac.ru, davem@redhat.com, gem@asplinux.ru, netdev@oss.sgi.com References: <20021111200321.GA30957@outpost.ds9a.nl> <200211121355.QAA00322@sex.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211121355.QAA00322@sex.inr.ac.ru> User-Agent: Mutt/1.3.28i X-archive-position: 1165 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev On Tue, Nov 12, 2002 at 04:55:57PM +0300, kuznet@ms2.inr.ac.ru wrote: > 1. udp.c: silly bug, local input policy did not work on udp sockets. > 2. ah.c,esp.c: even sillier bug: 0 was used as tunnels protocol. Funny enough, > it worked between linuxes. :-) By Thanks, will test tonight. Very very sadly, user mode linux does not compile for me in 2.5.47 and furthermore does not appear to be aware of the crypto subsystem. I added this patch to the larc IPSEC pages. > The problem with expiration remains unsolved. I still cannot reproduce this > and cannot find a situation when kernel can create two larvals with one > identity. :-( Searching. Sure you saw that? I only saw the one larval in the output I sent you, with everything set to zero. But perhaps I'm missing something. I'll have all my computers together again tonight. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From ahu@outpost.ds9a.nl Tue Nov 12 11:05:22 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Nov 2002 11:05:29 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACJ5LuR003225 for ; Tue, 12 Nov 2002 11:05:22 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id E260F4523; Tue, 12 Nov 2002 20:06:55 +0100 (CET) Date: Tue, 12 Nov 2002 20:06:55 +0100 From: bert hubert To: kuznet@ms2.inr.ac.ru Cc: davem@redhat.com, gem@asplinux.ru, netdev@oss.sgi.com Subject: Re: off by one error in 3des cbc keying Message-ID: <20021112190655.GB26647@outpost.ds9a.nl> Mail-Followup-To: bert hubert , kuznet@ms2.inr.ac.ru, davem@redhat.com, gem@asplinux.ru, netdev@oss.sgi.com References: <20021112151638.GA18488@outpost.ds9a.nl> <200211121529.SAA00584@sex.inr.ac.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline In-Reply-To: <200211121529.SAA00584@sex.inr.ac.ru> User-Agent: Mutt/1.3.28i X-archive-position: 1166 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Nov 12, 2002 at 06:29:06PM +0300, kuznet@ms2.inr.ac.ru wrote: > Hello! > > > > The problem with expiration remains unsolved. I still cannot reproduce this > > > and cannot find a situation when kernel can create two larvals with one > > > identity. :-( Searching. > > > > Sure you saw that? I only saw the one larval in the output I sent you, > > Sure, unless my sick cisco router corrupts mails. But I hope it is not > so malicious. :-) > > Joke aparts, of course, I did not see this, it exists for short time, > you see one of them already grown to mature. I've made a movie, the output of: while true; do date ; sudo download/kametools/setkey/setkey -D ; done > logs Please find it attached. This corresponds to: 20:01:43: INFO: isakmp.c:1689:isakmp_post_acquire(): IPsec-SA request for 10.0.0.11 queued due to no phase1 found. 20:01:43: INFO: isakmp.c:794:isakmp_ph1begin_i(): initiate new phase 1 negotiation: 10.0.0.216[500]<=>10.0.0.11[500] 20:01:43: INFO: isakmp.c:799:isakmp_ph1begin_i(): begin Aggressive mode. 20:01:43: INFO: vendorid.c:128:check_vendorid(): received Vendor ID: KAME/racoon 20:01:43: NOTIFY: oakley.c:2037:oakley_skeyid(): couldn't find the proper pskey, try to get one by the peer's address. 20:01:43: INFO: isakmp.c:2417:log_ph1established(): ISAKMP-SA established 10.0.0.216[500]-10.0.0.11[500] spi:abf1baea48b9c16d:e422bce8c6b9f015 20:01:44: INFO: isakmp.c:938:isakmp_ph2begin_i(): initiate new phase 2 negotiation: 10.0.0.216[0]<=>10.0.0.11[0] 20:01:44: INFO: pfkey.c:1106:pk_recvupdate(): IPsec-SA established: ESP/Transport 10.0.0.11->10.0.0.216 spi=251701380(0xf00a884) 20:01:44: INFO: pfkey.c:1318:pk_recvadd(): IPsec-SA established: ESP/Transport 10.0.0.216->10.0.0.11 spi=43499516(0x297bffc) 20:02:13: INFO: pfkey.c:1364:pk_recvexpire(): IPsec-SA expired: ESP/Transport 10.0.0.216->10.0.0.11 Note how it changes very nearly atomically. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO --5mCyUwZo2JvN/JJP Content-Type: application/octet-stream Content-Disposition: attachment; filename="logs.bz2" Content-Transfer-Encoding: base64 QlpoOTFBWSZTWSuLNdMAJFl/gAQwIABAY3/yLgEMAL/n/2BgE559SVIofADw Ad0nrQGQayEiQkKSKCg0qhECgCSChVDKVJ6n5v9VKBQAAAAABwf/qqmbVAAA AAAAGA0ZDQYQDQDTQABU9+qqAANAAAAAAJqlAEmhGiRpqP1PUxJkehGIFKSp +pMp6p6n6mUbUxPRHqaNB6g9NJ2EhrVFK9KCrKgq0A9KDEqa0HdBVzSpaUGF VoqhwJSWyqGiUl0gr8wVpIJ4oKsoKuaENFUNFUOBVDFVXjD5QxGIyiyiwRgj M6vWqmSrIYoLihYCsIq7ELmqo/pAdwK8kH0lSwE2BJ7QK+xVR1KqNVKJX1BW BS3kU1lS/ySKcFRuEneR1yMiMSGSGBGCMZ2lVhGlS1VFxFT9z+QhexIp+oK6 oOAV6grSpS7BWAV+oKyBX8wV5BWkCvIKyg9wV5FHwqo5EcIjmodKhw7UdKVc Qz1gvAKslVgSYpWEpZFWVEwVYz9qD0BWgK3BXkFfYFdArwCvzoPkCtwV+6A9 4FeYFf2oJSlQlNKaaVWIiIi2AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABE8WZ56dOLNoAAAAAA AAAAAAAAAAAAAAAAJ554gAAAAAAAAAAAAAAAASlKUAAAAAAAAJSlKAAAAAAA AAAAAAAAAAmmiIAAAAAAAACIiIAAAAAAAAAAAAAAN73ve973ve97+BVDwKoe ZVDRUq6EU8ArJBG6TGUvKDmI7Nw2jIZIbEb1RaEa6gqh5lIpxVUYSksgPqCu QVoQY1gVrArKDYSpL50EX6JFV7fL338+fPHudAAAEADGAA1bYU6lS9KVLKDa g0QE3lVclVGhRN0MQmUociCr7VQVbBIem3o8wK2CQ/0Eh6yCn3lS17zMzWdS pZOQVj8CRTckU273bjoFdArjrMzNhzzy1G++ZmaK/EFZOOOGo44zMzQb77tR vvmZmkgppKlqCtAV5BXcqXvUFX6VBVrQcyKfjArJUvnK6BTaWSWdby5cOW/L uu8AAAAAgAABytksutavallsl9ksktkqWSKdj6UFXnzmZmryCsnrSxgK1BWj SJXJIp48eG0St2IWU0BX/IK76zMzamkqWOeeGo23zMzQfYFZQVcccPYFbOKX OZmZaypZHgFYVagOPHjbKDeZmYHqqoyoNUlJyCsoKuaDAlVqSKe8lsnG22yD bbXLOuoAAAAQAONlllznN3vC2WWyXFslkxbEU+oK71zMwi96CrHPPLkFagrj fMzNN929BoCt98zM9ZUuNuG++ZmbbbNtszMwFcQKwFbgrUFfvBWgK3BXkFfg CvNttknZbbZMSySbW22Tp1xvxzrbPUACAAAEAAAOUstd99tYDvvMzNgVvm7b bMzNttnIK8grjjMzNwVxnDbbMzNttrM1lS+YK30zMz5ArtCNgV2EnsCTFksn WW22TWta106Z6dQAAIAEADnvLJLM4zMY2ktt8UshjGM0orjjizNVUW++ZmeQ VrUDjjjMzNVSnHGZmfAK1BVxxxmZmtccZmZ2CuOOMzM1gVqCt98zM9AVxArw CvYFeoK6BXYK9Sslm9ttkxLZJw6Y4tuPHiAAgAABAAADOc4xjGc4xjHZaK6l S4BXHDbjjTTTTTTbZtttppppppgK22ba7aaaaaadArfd4BX1BXp111pppppp oCtQVyCtQV6Ar2BXqCtaCrUFXQK38dd8evnr1899999gAIAEADtW22Tfe85a K1777zNdNNOOG+++ZmbbNQVtm2Zmb/AK44a1xxxmZmq33aLbbMzNFyCvIK9r bbJq7W22TDnjWu3rXPmABAAACAAAAu9tksMYxjRb77tbwCslS6BXPOZmarnn lqvmCuOMzM1XYK555bLjjMzNFvvu1dgrLjjMzNKUtAVtArfNNtvT09PHjvvs AAQAMYADOc3hLJLPWg3gVyu+8zM0XXXTV6grLjjMzNPcFZagrHPPKUtU6BWo K35zMzYcbcNRvvmZmg1gVvvo1V1KljwCvcFaPQFd95mZqPUFdArQFbAreBWy qXjxxvzz6+PIAIAAAQAAHfffffbl2Csp8ArAVp4zMzSagrFcccNRyCueczM1 HHHDUe4K44zMzVoCsp4BXPPLafIFYrwCueszM1HkFdddNp2CsVuCueczM0BW qvIKydQK9wV/CoV9oCsAVhVDCqHZFWlBVpIUyg0KTKDEk0oMkrSA/pArTWBW sAwqspVYRkCYSJ81VLwSKdEimtBV/uA/yQcFUP+pVaKofEqhiE6iirAVrKlt ArAV++oKv6wK/tQfiIXmg1gV+whfxoNhQnyELQQv4UFX1BX5Ar/2BXuCv+AV gK6AexCeFVHmqo9hVD8aqPIqh5Kqu4qh6FUOwKobSoveVQ8SqHtKoc1VGypV 8gV7QK9gV9wV7gr5UFXcCvcFeAV8wV/OkScAr6wK3BXQK/iCvvArcFeAVxAr 9qCr/ECtQV7Ar3gV1QVfhSJPcFfmCvIK+QK9gVtAroFdijZCfgSksFVhVDCq V96gq/IFfoCvigq/AFfgCugV6ArgFfFBV+sCvlQVbArzAr4BX+xC5BXuCvoC tAV4BXkFbAr8qCrWgq6oKuAV2Ctqgq1pEm9BlBV9qgqygq1pEnECvnQeaCr6 ArxKl4BX4wK9AV7Ar4BWxEX1oKvYFe4KwFelBHuqo0VQ+8KocSqHcqo6BVDa qj+yqHzKoYVSvpQfFBVzAetBV/WA6oKuKCragq+1BV94FbwRzKobKodoqh3l UMKrzKriVQ8SqHrCqHMqhukotCqHIqh1lUNFUMJSXuKoeoKoe9VRzKodZVDt FUMFUOBVbFSr4oKuIDmgq/lQVZQRgqhhVDBVDEqXoVQ7iqHpSqwqhkCfJVRo KobKocyqH1KociqGiqHYVQ6AV3lUOBCZEJZQZArIVWlBkUVhVDgSkvIlJd5V DZU1gV/oQvnAr4qCr5kinNVV4hVDrKoeBKS/8XckU4UJArizXTA= --5mCyUwZo2JvN/JJP-- From davem@redhat.com Tue Nov 12 14:37:21 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Nov 2002 14:37:27 -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 gACMbLuR018718 for ; Tue, 12 Nov 2002 14:37:21 -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 OAA28254; Tue, 12 Nov 2002 14:36:36 -0800 Date: Tue, 12 Nov 2002 14:36:36 -0800 (PST) Message-Id: <20021112.143636.55033627.davem@redhat.com> To: kuznet@ms2.inr.ac.ru Cc: ahu@ds9a.nl, gem@asplinux.ru, netdev@oss.sgi.com Subject: Re: off by one error in 3des cbc keying From: "David S. Miller" In-Reply-To: <200211121355.QAA00322@sex.inr.ac.ru> References: <20021111200321.GA30957@outpost.ds9a.nl> <200211121355.QAA00322@sex.inr.ac.ru> 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: 1167 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: kuznet@ms2.inr.ac.ru Date: Tue, 12 Nov 2002 16:55:57 +0300 (MSK) Comments for Dave: 1. udp.c: silly bug, local input policy did not work on udp sockets. 2. ah.c,esp.c: even sillier bug: 0 was used as tunnels protocol. Funny enough, it worked between linuxes. :-) By Applied, thanks. Another fix for wrongly formatted ICV for ESP will follow tonight after test for interoperability with freebsd. The problem with expiration remains unsolved. I still cannot reproduce this and cannot find a situation when kernel can create two larvals with one identity. :-( Searching. Ok, I continue with xfrm_user. Damn I must finish this crap :) From kuznet@ms2.inr.ac.ru Tue Nov 12 17:03:43 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Nov 2002 17:03:46 -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 gAD13guR022703 for ; Tue, 12 Nov 2002 17:03:42 -0800 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id EAA09992; Wed, 13 Nov 2002 04:04:15 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200211130104.EAA09992@sex.inr.ac.ru> Subject: Re: off by one error in 3des cbc keying To: davem@redhat.com (David S. Miller) Date: Wed, 13 Nov 2002 04:04:15 +0300 (MSK) Cc: ahu@ds9a.nl, gem@asplinux.ru, netdev@oss.sgi.com In-Reply-To: <20021112.143636.55033627.davem@redhat.com> from "David S. Miller" at Nov 12, 2 02:36:36 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 1168 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! > Applied, thanks. > > Another fix for wrongly formatted ICV for ESP will follow > tonight after test for interoperability with freebsd. So, this piece is by Maxim. Bert, beware, it is required to talk to another stacks but breaks communication with linuxes before this patch. For log: authentication signature for MD5/SHA was not truncated to conform RFC. Side note: well, my fault, but damn common sense requires not to break nice good MD5 digest to some absolutely unmotivated length. Alexey ===== net/ipv4/esp.c 1.4 vs edited ===== --- 1.4/net/ipv4/esp.c Fri Nov 8 11:34:37 2002 +++ edited/net/ipv4/esp.c Wed Nov 13 03:00:52 2002 @@ -190,11 +190,10 @@ struct crypto_tfm *tfm = esp->auth.tfm; char *digest = esp->auth.work_digest; - memset(auth_data, 0, esp->auth.authlen); crypto_hmac_init(tfm, esp->auth.key, &esp->auth.key_len); skb_digest_walk(skb, tfm, offset, len); crypto_hmac_final(tfm, esp->auth.key, &esp->auth.key_len, digest); - memcpy(auth_data, digest, crypto_tfm_alg_digestsize(tfm)); + memcpy(auth_data, digest, esp->auth.authlen); } /* Check that skb data bits are writable. If they are not, copy data @@ -463,16 +462,16 @@ /* If integrity check is required, do this. */ if (esp->auth.authlen) { - int icvsize = crypto_tfm_alg_digestsize(esp->auth.tfm); - u8 sum[icvsize]; - u8 sum1[icvsize]; + u8 sum[esp->auth.authlen]; + u8 sum1[esp->auth.authlen]; esp->auth.digest(esp, skb, 0, skb->len-esp->auth.authlen, sum); - if (skb_copy_bits(skb, skb->len-esp->auth.authlen, sum1, icvsize)) + if (skb_copy_bits(skb, skb->len-esp->auth.authlen, sum1, + esp->auth.authlen)) BUG(); - if (unlikely(memcmp(sum, sum1, icvsize))) { + if (unlikely(memcmp(sum, sum1, esp->auth.authlen))) { x->stats.integrity_failed++; goto out; } @@ -605,14 +604,20 @@ memset(esp, 0, sizeof(*esp)); if (x->aalg) { + int digestsize; + esp->auth.key = x->aalg->alg_key; esp->auth.key_len = (x->aalg->alg_key_len+7)/8; esp->auth.tfm = crypto_alloc_tfm(x->aalg->alg_name, 0); if (esp->auth.tfm == NULL) goto error; esp->auth.digest = esp_hmac_digest; - esp->auth.authlen = crypto_tfm_alg_digestsize(esp->auth.tfm); - esp->auth.work_digest = kmalloc(esp->auth.authlen, GFP_KERNEL); + digestsize = crypto_tfm_alg_digestsize(esp->auth.tfm); + /* XXX RFC2403 and RFC 2404 truncate auth to 96 bit */ + esp->auth.authlen = 12; + if (esp->auth.authlen > digestsize) /* XXX */ + BUG(); + esp->auth.work_digest = kmalloc(digestsize, GFP_KERNEL); if (!esp->auth.work_digest) goto error; } From kuznet@ms2.inr.ac.ru Tue Nov 12 17:08:41 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Nov 2002 17:08:42 -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 gAD18duR023118 for ; Tue, 12 Nov 2002 17:08:40 -0800 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id EAA10034; Wed, 13 Nov 2002 04:09:26 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200211130109.EAA10034@sex.inr.ac.ru> Subject: Re: off by one error in 3des cbc keying To: davem@redhat.com (David S. Miller) Date: Wed, 13 Nov 2002 04:09:26 +0300 (MSK) Cc: ahu@ds9a.nl, gem@asplinux.ru, netdev@oss.sgi.com In-Reply-To: <20021112.143636.55033627.davem@redhat.com> from "David S. Miller" at Nov 12, 2 02:36:36 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 1169 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! > The problem with expiration remains unsolved. Patch #2. Bert, this is supposed to fix the first strange phenomenon in your experiment. But I still do not know what will happen after that. Please, check. Dave, do not take this patch. It is a bit ugly and I would like to finish with Bert's problem, which may require sequence of incremental fixes to the same place. Alexey ===== include/net/xfrm.h 1.5 vs edited ===== --- 1.5/include/net/xfrm.h Tue Nov 12 02:37:12 2002 +++ edited/include/net/xfrm.h Wed Nov 13 03:38:20 2002 @@ -473,7 +473,7 @@ 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); -struct xfrm_state * xfrm_find_acq(u8 mode, u16 reqid, u8 proto, u32 daddr, u32 saddr); +struct xfrm_state * xfrm_find_acq(u8 mode, u16 reqid, u8 proto, u32 daddr, u32 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); ===== net/ipv4/xfrm_state.c 1.6 vs edited ===== --- 1.6/net/ipv4/xfrm_state.c Tue Nov 12 02:37:12 2002 +++ edited/net/ipv4/xfrm_state.c Wed Nov 13 03:38:26 2002 @@ -386,7 +386,7 @@ } struct xfrm_state * -xfrm_find_acq(u8 mode, u16 reqid, u8 proto, u32 daddr, u32 saddr) +xfrm_find_acq(u8 mode, u16 reqid, u8 proto, u32 daddr, u32 saddr, int create) { struct xfrm_state *x, *x0; unsigned h = ntohl(daddr); @@ -411,7 +411,7 @@ } if (x0) { atomic_inc(&x0->refcnt); - } else if ((x0 = xfrm_state_alloc()) != NULL) { + } else if (create && (x0 = xfrm_state_alloc()) != NULL) { x0->sel.daddr.xfrm4_addr = daddr; x0->sel.daddr.xfrm4_mask = ~0; x0->sel.saddr.xfrm4_addr = saddr; ===== net/key/af_key.c 1.7 vs edited ===== --- 1.7/net/key/af_key.c Tue Nov 12 02:37:12 2002 +++ edited/net/key/af_key.c Wed Nov 13 03:48:17 2002 @@ -528,8 +528,7 @@ switch (((struct sockaddr *)(addr + 1))->sa_family) { case AF_INET: - x = xfrm_state_lookup( - ((struct sockaddr_in*)(addr + 1))->sin_addr.s_addr, + x = xfrm_state_lookup(((struct sockaddr_in*)(addr + 1))->sin_addr.s_addr, sa->sadb_sa_spi, proto); break; case AF_INET6: @@ -1043,7 +1042,7 @@ daddr = (struct sockaddr_in*)(addr + 1); x = xfrm_find_acq(mode, reqid, proto, daddr->sin_addr.s_addr, - saddr->sin_addr.s_addr); + saddr->sin_addr.s_addr, 1); if (x == NULL) return -ENOENT; @@ -1122,7 +1121,17 @@ /* XXX there is race condition */ x1 = pfkey_xfrm_state_lookup(hdr, ext_hdrs); - if (x1 && hdr->sadb_msg_type == SADB_ADD) { + 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; + } + } + + if (x1 && x1->id.spi && hdr->sadb_msg_type == SADB_ADD) { x->km.state = XFRM_STATE_DEAD; xfrm_state_put(x); xfrm_state_put(x1); @@ -1131,7 +1140,7 @@ xfrm_state_insert(x); - if (x1 && hdr->sadb_msg_type != SADB_ADD) { + if (x1) { xfrm_state_delete(x1); xfrm_state_put(x1); } From consultas@stopcar.com.ar Tue Nov 12 19:39:37 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Nov 2002 19:39:39 -0800 (PST) Received: from stopcar.com.ar (ADSL215-200.advancedsl.com.ar [200.51.215.200]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAD3dZuR027711 for ; Tue, 12 Nov 2002 19:39:36 -0800 Message-Id: <200211130339.gAD3dZuR027711@oss.sgi.com> From: STOPCAR To: netdev@oss.sgi.com Subject: Cada 5 minutos es Robado un Vehiculo Date: 13 Nov 2002 00:43:27 -0300 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-archive-position: 1170 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: consultas@stopcar.com.ar Precedence: bulk X-list: netdev ¿Con qué cree Ud. Que debe contar una empresa recuperadora de vehículos robados? En los tiempos que corren han proliferado los emprendimientos de empresas, pero pocos reúnen los requisitos mínimos e indispensables para un normal y eficaz rendimiento. Por ello STOPCAR S.A., es líder de este segmento, basado en un crecimiento sostenido a través de los años, que nos permite contar, entre otras cosas, con: 52000 abonados Cobertura las 24 hs. Los 365 días del año. Frecuencias y licencias propias. Red de Agentes y Representantes en todo el país. Fabricación Nacional (dispositivo fabricado en nuestro laboratorio de análisis técnico, con mejoras permanentes de alta tecnología). Cobertura Nacional. A través de nuestra extensa red de antenas y transmisores dispuestos en todo el país. (UNICA FRECUENCIA NACIONAL) Homologación: Nuestros dispositivos se encuentran homologados por el Centro de Experimentación y Seguridad Vial Argentina S.A. (C.E.S.V.I.) Flota de Recupero. Contamos con 45 vehículos de rastreo, personal idóneo y preparado especialmente para sus tareas y dos unidades aéreas de localización. Empresa Nacional. Mas de 250 familias forman nuestras líneas de tareas en una Empresa Nacional de permanente reinversión. 98% de recuperos efectivos. Eficiencia y Confiabilidad. (Convenios con las principales Compañías de Seguros) Sin embargo nos preguntamos una y otra vez si con esto alcanza... Y la respuesta es contundente: NO. Nuestro posicionamiento nos compromete aun más y nos hace crecer día a día. Ahora Ud. Es quién debe preguntarse: ¿A quién confiarle su seguridad? STOPCAR S.A. abre sus puertas para que nos vea trabajar y reconozca nuestra labor. No se deje engañar; la confiabilidad, la experiencia, los verdaderos resultados, no se declaman, se logran con trabajo a través del tiempo. Por ello cuando tenga que elegir, COMPARE, VERIFIQUE, CALIFIQUE, Y LUEGO DECIDA. ¿Si le roban su vehículo, desearía que se lo recuperen de inmediato? ¿Considera Usted importante conocer costos reales? La respuesta y solución a estos interrogantes la tiene STOPCAR S.A. SOLICITE ASESORAMIENTO SIN CARGO AL 4489-9000 o vía Email STOPCAR S.A. Brinda servicios, responder a sus preguntas es uno de ellos. Consulte también como tener STOPCAR en comodato. STOPCAR S.A., seguridad garantizada. Este mail no es considerado SPAM ya que es la unica vez que lo recibira y podra ser eliminado de nuestras listas solicitandolo enviando un mail con el asunto "R E M O V E R " Gracias por leer el mail y disculpe las molestias. From Eric.Lemoine@sun.com Tue Nov 12 22:51:31 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Nov 2002 22:51:35 -0800 (PST) Received: from s3.smtp.oleane.net (s3.smtp.oleane.net [195.25.12.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAD6pTuR005479 for ; Tue, 12 Nov 2002 22:51:30 -0800 Received: from gbl-dhcp-198-204.europe.research.sun.com ([194.2.198.204]) by s3.smtp.oleane.net with ESMTP id gAD6r4Mq085496; Wed, 13 Nov 2002 07:53:04 +0100 (CET) Received: from eric by (null) with local (MasqMail 0.1.16) id 18BrOa-09G-00; Wed, 13 Nov 2002 07:53:04 +0100 Date: Wed, 13 Nov 2002 07:53:04 +0100 From: Eric Lemoine To: Jon Fraser Cc: netdev@oss.sgi.com Subject: Re: [Question] SMP for Linux Message-ID: <20021113065304.GC402@udine> References: <15793.3958.926796.634263@robur.slu.se> <001701c27ba0$6ff02c70$3701020a@CONCORDIA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001701c27ba0$6ff02c70$3701020a@CONCORDIA> User-Agent: Mutt/1.3.28i X-Warning: return path set from From: address X-archive-position: 1171 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Eric.Lemoine@ens-lyon.fr Precedence: bulk X-list: netdev > > > I'll repeat the same tests on Monday with 82543 based cards. > > > I would expect similar results. > > > Oh, I used top and vmstat to collect cpu percentages, > > interrupts/second, > > > > Hmm top and vmstat doesn't give you time spent in > > irq/softirq's except for > > softirq's run via ksoftird? > > Right. You guys sure about this? vmstat uses stats gathered by the kernel in the structure variable kstat (of type struct kernel_stat). Here follows the func that updates this variable, it seems that time spent in irq/softirq is accounted, isn't it? void update_process_times(int user_tick) { struct task_struct *p = current; int cpu = smp_processor_id(), system = user_tick ^ 1; update_one_process(p, user_tick, system, cpu); if (p->pid) { if (--p->counter <= 0) { p->counter = 0; p->need_resched = 1; } if (p->nice > 0) kstat.per_cpu_nice[cpu] += user_tick; else kstat.per_cpu_user[cpu] += user_tick; kstat.per_cpu_system[cpu] += system; } else if (local_bh_count(cpu) || local_irq_count(cpu) > 1) kstat.per_cpu_system[cpu] += system; } PS: I agree this has nothing to do with netdev discussions but I just want to make sure... Thx. -- Eric From davem@redhat.com Wed Nov 13 00:45:48 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Nov 2002 00:45: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 gAD8jmuR008294 for ; Wed, 13 Nov 2002 00:45:48 -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 AAA29307; Wed, 13 Nov 2002 00:45:03 -0800 Date: Wed, 13 Nov 2002 00:45:02 -0800 (PST) Message-Id: <20021113.004502.22547554.davem@redhat.com> To: kuznet@ms2.inr.ac.ru Cc: ahu@ds9a.nl, gem@asplinux.ru, netdev@oss.sgi.com Subject: Re: off by one error in 3des cbc keying From: "David S. Miller" In-Reply-To: <200211130104.EAA09992@sex.inr.ac.ru> References: <20021112.143636.55033627.davem@redhat.com> <200211130104.EAA09992@sex.inr.ac.ru> 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: 1172 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: kuznet@ms2.inr.ac.ru Date: Wed, 13 Nov 2002 04:04:15 +0300 (MSK) For log: authentication signature for MD5/SHA was not truncated to conform RFC. Applied, thanks. Side note: well, my fault, but damn common sense requires not to break nice good MD5 digest to some absolutely unmotivated length. Yes, seems really stupid. From ahu@outpost.ds9a.nl Wed Nov 13 00:53:41 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Nov 2002 00:53:43 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAD8rfuR009372 for ; Wed, 13 Nov 2002 00:53:41 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 17C3E4017; Wed, 13 Nov 2002 09:55:18 +0100 (CET) Date: Wed, 13 Nov 2002 09:55:17 +0100 From: bert hubert To: kuznet@ms2.inr.ac.ru Cc: "David S. Miller" , gem@asplinux.ru, netdev@oss.sgi.com Subject: automatic keying works! Re: off by one error in 3des cbc keying Message-ID: <20021113085517.GA9134@outpost.ds9a.nl> Mail-Followup-To: bert hubert , kuznet@ms2.inr.ac.ru, "David S. Miller" , gem@asplinux.ru, netdev@oss.sgi.com References: <20021112.143636.55033627.davem@redhat.com> <200211130109.EAA10034@sex.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211130109.EAA10034@sex.inr.ac.ru> User-Agent: Mutt/1.3.28i X-archive-position: 1173 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev On Wed, Nov 13, 2002 at 04:09:26AM +0300, kuznet@ms2.inr.ac.ru wrote: > Hello! > > > The problem with expiration remains unsolved. > > Patch #2. Bert, this is supposed to fix the first strange phenomenon > in your experiment. But I still do not know what will happen after that. > Please, check. Resolves strange larvals, thanks. Patch #1 works fine but changes nothing for linux-linux IPSEC, if both have the patch. Scenario I see now: Initial setup is wonderful, 10.0.0.11 and 10.0.0.216 setup SAs. At the soft expiration, both ends renegotiate and UPDATE their *incoming* SA, using pk_sendupdate which calls pfkey_send_update in libipsec. The outgoing SA however is updated using pk_sendadd which calls pfkey_send_add, which Linux hates because there is already an SA there. I changed it to call pfkey_sendupdate and then everything works as intended. You spotted this problem earlier, by the way. This brings us to the point that everything I try works. Key rollover is now completely seamless. My patch to racoon is really ugly as it now also uses UPDATE to add the initial outbound SA, I can improve it if you want? Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From info@presentatiestunter.nl Wed Nov 13 06:36:48 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Nov 2002 06:36:51 -0800 (PST) Received: from relay5.zonnet.nl ([62.58.50.102]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gADEaluR025645 for ; Wed, 13 Nov 2002 06:36:47 -0800 Message-Id: <200211131436.gADEaluR025645@oss.sgi.com> Received: from 192 ([62.59.71.102]) by relay5.zonnet.nl (Netscape Messaging Server 4.15 ntr033 Mar 14 2002 21:29:48) with SMTP id H5IRBP00.QWF; Wed, 13 Nov 2002 15:38:14 +0100 From: "Laptops en Beamers." To: Klanten Subject: Laptops en Beamers. Nu ook Verhuur en Lease. Date: Tue, 12 Nov 2002 13:21:26 +0100 X-Mailer: Arclab MailList Controller MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="DB07400E-17D6-4369-8882-4E53EE4AF74E" Content-Transfer-Encoding: quoted-printable X-archive-position: 1174 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: info@presentatiestunter.nl Precedence: bulk X-list: netdev This is a multi-part message in MIME format --DB07400E-17D6-4369-8882-4E53EE4AF74E Content-Type: multipart/related; charset=iso-8859-1; Boundary="3789B7E9-F9B9-4757-A1CA-D101ED5BBEE6" --3789B7E9-F9B9-4757-A1CA-D101ED5BBEE6 Content-Type: multipart/alternative; charset=iso-8859-1; Boundary="D783F1D6-79D3-4154-BEA4-09B609176FF8" --D783F1D6-79D3-4154-BEA4-09B609176FF8 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message in MIME/MHTML format. --D783F1D6-79D3-4154-BEA4-09B609176FF8 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Geachte heer/mevrouw,

Hierbij ontvangt u als eerste onze SUPER-aanbiedingen.
Nieuwe = en=20 refurbished LAPTOPS & SYSTEMEN & BEAMERS.

Met vriendelijke groet,

Uw TOPLAPS-team.

Indien u onze aanbiedingen niet langer wilt ontvangen o= f =0D zonder uw toestemming in onze database bent opgenomen (waarvoor onze excuses) klikt u hier.
LET OP: Alleen het emailadres waarmee u mail verzendt (uw afzend emailadres) wordt verwijderd uit onze database.

>>> = laptops & beamers --- TOPLAPS Superaanbiedingen --- laptops & beamers <<<

LAPTOP prijstopper 1
(uit de lease verkregen)

Toshiba 440cdx

  • Intel Pentium 133 Mhz
  • 32 Mb geheugen
  • 1,3 Gb harddisk
  • cdrom speler
  • floppydrive
  • adapter
  • infrarood
  • 56k modem & 10Mb netwerk
  • geluidskaart & ge=EFntegreerde boxen
  • li-ion accu
  • 12,1 inch scherm
  • touchpad muis
  • GRATIS MOOIE DRAAGTAS
  • GRATIS EXTRA SCROLL MUIS
  • 60 dagen garantie. Geheel compleet
    • Nu slechts =80 499,=3D
    of ... betaal =80 18,=3D per maand ! Bestel direct! Klik hier.<= /TD>     		Uw eigen laptop al voor
    =80 1,=3D = per dag !!!

    Na maandbetaling
    is laptop / beamer / systeem u= w =0D eigendom!

    Al onze produkten worden voor slechts
    =80 25,=3D door h= eel Nederland bezorgd.

    Voor info en bestellen kunt u ook bellen
    033-2860777

    Alle koopprijzen zijn excl. BTW, leasebedragen zijn uiteraard incl= . =0D BTW.

    nu ook VERHUUR van LAPTOPS &a= mp; BEAMERS !

    		LAPTOP prijstopper 2
    (Uit de lease = verkregen)

    Compaq Armada 1700

  • Intel Pentium II 266 Mhz
  • 32 Mb geheugen
  • 4,3 gig hdd
  • cdrom speler
  • floppydrive
  • adapter
  • USB & infrarood
  • intern modem
  • geluidskaart & ge=EFntegreerde boxen
  • li-ion accu
  • 12,1 inch TFT inch scherm
  • touchpad muis
  • GRATIS MOOIE DRAAGTAS
  • GRATIS EXTRA SCROLL MUIS
  • 60 dagen garantie. Geheel compleet
    • Nu slechts =80 699,=3D
    of ... betaal =80 22,=3D per maand ! Bestel direct! Klik hier.<= /TD>
    BEAMER prijstopper 1
    (GLOEDNIEUW - LICHTGEWICHT)

    BenQ DS 550

  • Resolutie SVGA (800x600)
  • Lichtopbrengst 1200 ANSI Lumen
  • Contrastverhouding 450:1
  • Digital Keystone correctie
  • Beeldgrootte 23" tot 300"
  • Zoomverhouding 1:1.3
  • 16,7 miljoen kleuren
  • 150 Watt lamp
  • 1500 branduren
  • avbox; dus geschikt als thuisbioscoop
  • met afstandbediening
  • gratis mooie draagtas
  • Zeer stil
  • lichtgewicht van slechts 2,3 kilo
  • 3 jaar garantie. Geheel compleet
    • Nu slechts =80 1899,=3D
    of ... betaal =80 50,=3D per maand ! Bestel direct! Klik hier.<= /TD>     		LAPTOP prijstopper 3
    (ex-demo laptop)

    Dell Latitude

  • Intel Pentium III 500 Mhz
  • 128 Mb geheugen
  • 6,0 Gb harddisk
  • cdrom speler
  • floppydrive
  • adapter
  • USB & infrarood
  • PCMCIA 56k modem
  • geluidskaart & ge=EFntegreerde boxen
  • li-ion accu
  • maarliefst 13,3 TFT inch scherm
  • trackpoint muis
  • GRATIS MOOIE DRAAGTAS
  • GRATIS EXTRA SCROLL MUIS
  • 6 maanden garantie. Geheel compleet
    • Slechts =80 999,=3D
    of ... betaal =80 30,=3D per maand ! Bestel direct! Klik hier.<= /TD>     		BEAMER prijstopper 2(GLOEDNIEUW - LICHTGEWICHT)

    Mitsubishi XL1U

  • Resolutie XGA (1024x768)
  • Lichtopbrengst 1200 ANSI Lumen
  • Contrastverhouding 350:1
  • Digital Keystone correctie
  • Beeldgrootte 23" tot 300"
  • Zoomverhouding 1:1.3
  • 16,7 miljoen kleuren
  • 150 Watt lamp; 2000 branduren
  • geschikt voor videobeelden
  • met afstandbediening
  • gratis mooie draagtas
  • met o.a. IRIS functie en sRGB functie
  • Zeer stil
  • lichtgewicht van slechts 2,9 kilo
  • 3 jaar garantie. Geheel compleet
    • Nu slechts =80 2250,=3D
    of ... betaal =80 57,=3D per maand ! Bestel direct! Klik hier.<= /TD>
    LAPTOP prijstopper 4
    (GLOEDNIEUW)

    Tulip Topline 501

  • Intel Pentium IV 2,4 Ghz
  • 512 Mb geheugen
  • 40 Gb harddisk
  • dvdspeler en cdbrander
  • floppydrive
  • adapter
  • 2 x USB & infrarood
  • intern 56k modem & wireless lan
  • 3D geluidskaart & ge=EFntegreerde boxen
  • li-ion accu
  • maarlieft 14,1 inch TFT scherm
  • touchpad muis
  • Windows XP licentie + installatie
  • GRATIS MOOIE DRAAGTAS
  • GRATIS EXTRA SCROLLMUIS
  • 1 jaar garantie. Super compleet
    • NU OF NOOIT: =80 1.999,=3D
    of ... betaal =80 52,=3D per maand ! Bestel direct! Klik hier.<= /TD>     		LAPTOP prijstopper 5 (GLOEDNIEUW)

    Acer Aspire 1302 XC

  • AMD Athlon XP 1600+
  • 256 Mb geheugen
  • 20 Gb harddisk
  • dvdspeler + cdbrander
  • floppydrive
  • adapter
  • USB & infrarood
  • intern 56k modem & 10/100 netwerkaart
  • geluidskaart & ge=EFntegreerde boxen
  • li-ion accu
  • maarliefst 14,1 TFT inch scherm
  • trackpoint muis
  • Windows XP licentie + installatie
  • GRATIS MOOIE DRAAGTAS
  • GRATIS EXTRA SCROLL MUIS
  • 2 jaar garantie. Geheel compleet
    • Nu slechts =80 1399,=3D
    of ... betaal =80 38,=3D per maand ! Bestel direct! Klik hier.<= /TD>     		LAPTOP prijstopper 6
    (GLOEDNIEUW)

    Acer Aspire 1406 LC

  • Intel Pentium IV 2,5 Ghz
  • 512 Mb geheugen
  • 30 Gb harddisk
  • dvdspeler + cdbrander
  • floppydrive
  • adapter
  • USB & infrarood
  • intern 56k modem & 10/100 netwerkaart
  • geluidskaart & ge=EFntegreerde boxen
  • li-ion accu
  • maarliefst 15 TFT inch scherm
  • trackpoint muis
  • Windows XP licentie + installatie
  • GRATIS MOOIE DRAAGTAS
  • GRATIS EXTRA SCROLL MUIS
  • 2 jaar garantie. SUPER compleet
    • LET OP: =80 2.199,=3D
    of ... betaal =80 56,=3D per maand ! Bestel direct! Klik hier.

    Indien u onze aanbiedingen niet langer wilt ontvangen of zonder uw toestemming in o= nze database bent opgenomen (waarvoor onze excuses) klikt u hier.
    LET OP: Alleen het emailadres waarmee u mail verzendt (uw afzend emailadres) wordt verwijderd uit onze database.

    --D783F1D6-79D3-4154-BEA4-09B609176FF8-- --3789B7E9-F9B9-4757-A1CA-D101ED5BBEE6-- --DB07400E-17D6-4369-8882-4E53EE4AF74E-- From becker@scyld.com Wed Nov 13 08:43:54 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Nov 2002 08:43:56 -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 gADGhruR030206 for ; Wed, 13 Nov 2002 08:43:54 -0800 Received: from localhost (becker@localhost) by beohost.scyld.com (8.11.6/8.11.6) with ESMTP id gADGj2F05802; Wed, 13 Nov 2002 11:45:02 -0500 Date: Wed, 13 Nov 2002 11:45:02 -0500 (EST) From: Donald Becker To: jamal cc: netdev@oss.sgi.com Subject: Re: ifconfig TX/RX errors In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1175 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, 8 Nov 2002, jamal wrote: > On Fri, 8 Nov 2002, Donald Becker wrote: > > On Fri, 8 Nov 2002, Cheng Jin wrote: > > > > > What does a large number of RX/TX errors from ifconfig output generally > > > mean? Does it also include drop/overruns/frame errors? > > > > The 'ifconfig' program doesn't have a defined behavior. It reads > > /proc/net/dev and sums some of the available error counts. You should > > read /proc/net/dev directly to find out what is going wrong. > > > > Actually, unbelievable as it may sound, the ifconfig data > matches SNMP stats as defined in RFC1213 interfaces table; > same with things like netstat -s in the tcp data etc Are you certain about that Jamal? This is /proc/net/dev numbers covering the network interface device layer, not the protocol layers, The numbers Linux 'ifconfig' reports are similar, but not the same as the very limited counts that the old BSDs used. When I wrote the /proc/net/dev statistics count output, I unwisely summarized some of the independent fields the drivers recorded to fit into an 79 column output(1). I should have output all of the statistics, and let user-level programs summarize as they saw fit. Even today there is no way to get out the individual numbers. (1) That effort at human readability was discarded when new fields were added, making the output incompatible with earlier versions of ifconfig. So now the output is longer than a line, but it still doesn't break out the important error counts. -- 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 tgr@reeler.org Wed Nov 13 11:52:03 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Nov 2002 11:52:07 -0800 (PST) Received: from rei.rakuen (dclient217-162-68-63.hispeed.ch [217.162.68.63]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gADJq1uR005897 for ; Wed, 13 Nov 2002 11:52:03 -0800 Received: by reeler.org id 18C3Zu-0005wy-00 for ; Wed, 13 Nov 2002 20:53:34 +0100 Date: Wed, 13 Nov 2002 20:53:34 +0100 From: Thomas Graf To: netdev@oss.sgi.com Subject: leak in netlink_dump()? Message-ID: <20021113195334.GM27787@reeler.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Encryption: "Encrypted with ROT13 using key 42" X-archive-position: 1176 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgr@reeler.org Precedence: bulk X-list: netdev Hello! Used Kernel: 2.4.18 (same for 2.4.19pre6) I think I've found a memory leak in netlink_dump (af_netlink.c): the netlink callback (sk->protinfo.af_netlink->cb) is allocated in the calling funtion netlink_dump_start and is not freed after the call to netlink_dump. ... netlink_dump.len = cb->dump(skb, cb); len = cb->dump(skb, cb); if (len > 0) { spin_unlock(&sk->protinfo.af_netlink->cb_lock); skb_queue_tail(&sk->receive_queue, skb); sk->data_ready(sk, len); /* * Isn't a netlink_destroy_callback(cb) missing here? */ return 0; } ... netlink_destroy_callback(cb); /* cb gets freed here */ sock_put(sk); return 0; } The only other call to netlink_destroy_callback is in netlink_release which is called from sock_release which is called if the socket gets closed. From my point of view, this is a memory leak, but I'm new to kernel code and I might be telling shit. -- Thomas GRAF From ahu@outpost.ds9a.nl Wed Nov 13 14:01:34 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Nov 2002 14:01:36 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gADM1XuR012783 for ; Wed, 13 Nov 2002 14:01:33 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id EFD673FDD; Wed, 13 Nov 2002 23:03:11 +0100 (CET) Date: Wed, 13 Nov 2002 23:03:11 +0100 From: bert hubert To: kuznet@ms2.inr.ac.ru Cc: davem@redhat.com, gem@asplinux.ru, netdev@oss.sgi.com Subject: Re: automatic keying works! Re: off by one error in 3des cbc keying Message-ID: <20021113220311.GA29358@outpost.ds9a.nl> Mail-Followup-To: bert hubert , kuznet@ms2.inr.ac.ru, davem@redhat.com, gem@asplinux.ru, netdev@oss.sgi.com References: <20021113085517.GA9134@outpost.ds9a.nl> <200211132046.XAA12943@sex.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211132046.XAA12943@sex.inr.ac.ru> User-Agent: Mutt/1.3.28i X-archive-position: 1177 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev On Wed, Nov 13, 2002 at 11:46:40PM +0300, kuznet@ms2.inr.ac.ru wrote: > We traced all this today. It was not true reason of bad behaviour, > real mistake was in absolutely different place. The patch (not incremental > wrt patch of yesterday, so backout that one). Done. http://ds9a.nl/ipsec now contains patches: [TXT] 01-bypass-connect.diff 11-Nov-2002 08:59 16k [TXT] 02-udp-bypass.diff 12-Nov-2002 15:14 2k [TXT] 03-interop-breaks-compat.diff 13-Nov-2002 08:25 3k [TXT] 04-larval-2.diff 13-Nov-2002 21:53 5k When applied together, it now *really* works as intended :-) > No, really. The trace showed another problem: one of them looks like > a bug in racoon namely, after SA internal to IKE expires racoon > does not initiate new connection to peer when some real kernel I now see a proper soft expire, new SAs being setup, old SAs in state 'dying', and traffic flowing nicely. Even with soft expire and no traffic, I see a new SA being negotiated. Until the old SAs die, I see linux sending with the old SPI, is that right? Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From kuznet@ms2.inr.ac.ru Wed Nov 13 14:34:58 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Nov 2002 14:35:00 -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 gADMYvuR016228 for ; Wed, 13 Nov 2002 14:34:57 -0800 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id BAA13386; Thu, 14 Nov 2002 01:35:39 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200211132235.BAA13386@sex.inr.ac.ru> Subject: Re: automatic keying works! Re: off by one error in 3des cbc keying To: ahu@ds9a.nl (bert hubert) Date: Thu, 14 Nov 2002 01:35:39 +0300 (MSK) Cc: davem@redhat.com, gem@asplinux.ru, netdev@oss.sgi.com In-Reply-To: <20021113220311.GA29358@outpost.ds9a.nl> from "bert hubert" at Nov 13, 2 11:03:11 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 1178 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! > I now see a proper soft expire, new SAs being setup, old SAs in state 'dying', > and traffic flowing nicely. Even with soft expire and no traffic, I see a > new SA being negotiated. Wait for a while and you will see message sort of: Nov 13 20:48:59 mops [291/0/0] racoon: INFO: isakmp.c:1521:isakmp_ph1expire(): ISAKMP-SA expired 192.168.1.202[500]-192.168.1.106[500] spi:c9549e2b4f33f8a3:655bf176d4531765 Note word "ISAKMP", this SA has nothing to do with IPsec, it is to protect exchange between IKE's. An IPsec SA soft-expires follows this. Then new IPsec SA will _not_ be negotiated! So, old SA will be used until final hard expire, and the next packet will trigger all the renegotiation from the very beginning introducing a small gap in service and losing one or more packets. Nov 13 20:45:59 mops [291/0/0] racoon: INFO: pfkey.c:1364:pk_recvexpire(): IPsec-SA expired: AH/Transport 192.168.1.106->192.168.1.202 spi=21148383(0x142b2df) Nov 13 20:45:59 mops [291/0/0] racoon: INFO: isakmp.c:1569:isakmp_ph1delete(): ISAKMP-SA deleted 192.168.1.202[500]-192.168.1.106[500] spi:a5eb75bdffbc0e6b:6b829e67c9bcfb3c Nov 13 20:45:59 mops [291/0/0] racoon: INFO: pfkey.c:1364:pk_recvexpire(): IPsec-SA expired: AH/Transport 192.168.1.202->192.168.1.106 spi=218761938(0xd0a0ad2) Nov 13 20:45:59 mops [291/0/0] racoon: INFO: isakmp.c:1689:isakmp_post_acquire(): IPsec-SA request for 192.168.1.106 queued due to no phase1 found. Apparently, racoon must reconnect to peer not waiting for timeout when it sees that this SA was used recently enough. It does not. Well, it is bug but not serious. > Until the old SAs die, I see linux sending with the old SPI, is that right? No, really. We prefer new one, when reselection is requested. We can enforce reselection when some SA becomes close to death (dying), and, probably, we will do. Well, KAME _always_ prefers old SA which results in real loss of packets under freebsd. It is _disgusting_, so we considered this as a bug in freebsd and forgot that linux can behave in the same way when doing tcp, rather not ping. :-) :-) Alexey From srompf@isg.de Wed Nov 13 15:18:39 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Nov 2002 15:18:45 -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 gADNISuR017351 for ; Wed, 13 Nov 2002 15:18:29 -0800 Received: from isg.de (B19c3.pppool.de [213.7.25.195]) by mail.isg.de (Postfix) with ESMTP id 18701E44B88; Wed, 13 Nov 2002 23:46:36 +0100 (CET) Message-ID: <3DD2D204.C9B7FA2D@isg.de> Date: Wed, 13 Nov 2002 23:28:20 +0100 From: Stefan Rompf X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.20-rc1-lw i686) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Patch: Backport of link state notification to 2.4.20rc1 Content-Type: multipart/mixed; boundary="------------FAD95F720EB083095E631054" X-archive-position: 1179 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 This is a multi-part message in MIME format. --------------FAD95F720EB083095E631054 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, having the link state notification stuff in 2.4 is still a major goal for me. I've taken the 2.5 implementation Jamal and I have worked out, removed the semantic changes towards RFC2863 and replaced the workqueue with a combination of timer and kevent. Different to my previous 2.4.18 version this patch needs neither its own kernel thread nor does it touch the in kernel IFF_RUNNING flag anymore, so it is quite non-intrusive: Drivers that implement netif_carrier_on()/netif_carrier_off() will use the notifications, the rest won't be harmed. Even though David and Alexey seem to be busy with ipsec stuff, I don't want to wait any longer to post the patch for public review. I've done succesful tests with a hacked starfire (trivial three-liner, coming the next days) and vlan driver. I was not able to check SMP compatibility. I know of other people on this list who want to have this feature in 2.4, too. Please be so kind and test the patch on your machines. If no objections arise, I'm going to submit this for 2.4 inclusion. Cheers, Stefan --------------FAD95F720EB083095E631054 Content-Type: text/plain; charset=us-ascii; name="patch-linkwatch-2.4.20rc1" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-linkwatch-2.4.20rc1" diff -uNr linux-2.4.20rc1/Documentation/Configure.help linux/Documentation/Configure.help --- linux-2.4.20rc1/Documentation/Configure.help 2002-11-05 00:31:35.000000000 +0100 +++ linux/Documentation/Configure.help 2002-11-13 22:32:46.000000000 +0100 @@ -26011,6 +26011,18 @@ would like kernel messages to be formatted into GDB $O packets so that GDB prints them as program output, say 'Y'. +Device link state notification +CONFIG_LINKWATCH + When this option is enabled, the kernel will forward changes in the + operative ("RUNNING") state of an interface via the netlink socket. + This is most useful when running linux as a router. + + Note that currently not many drivers support this, compliant ones + can be found by watching the the RUNNING flag in ifconfig output + that should follow operative state. + + If unsure, say 'N'. + 802.1Q VLAN Support CONFIG_VLAN_8021Q Select this and you will be able to create 802.1Q VLAN interfaces on your diff -uNr linux-2.4.20rc1/include/linux/netdevice.h linux/include/linux/netdevice.h --- linux-2.4.20rc1/include/linux/netdevice.h 2002-11-05 00:31:42.000000000 +0100 +++ linux/include/linux/netdevice.h 2002-11-13 22:32:46.000000000 +0100 @@ -207,7 +207,8 @@ __LINK_STATE_PRESENT, __LINK_STATE_SCHED, __LINK_STATE_NOCARRIER, - __LINK_STATE_RX_SCHED + __LINK_STATE_RX_SCHED, + __LINK_STATE_LINKWATCH_PENDING }; @@ -630,6 +631,10 @@ * who is responsible for serialization of these calls. */ +#ifdef CONFIG_LINKWATCH +extern void linkwatch_fire_event(struct net_device *dev); +#endif + static inline int netif_carrier_ok(struct net_device *dev) { return !test_bit(__LINK_STATE_NOCARRIER, &dev->state); @@ -639,14 +644,24 @@ static inline void netif_carrier_on(struct net_device *dev) { +#ifdef CONFIG_LINKWATCH + if (test_and_clear_bit(__LINK_STATE_NOCARRIER, &dev->state)) + linkwatch_fire_event(dev); +#else clear_bit(__LINK_STATE_NOCARRIER, &dev->state); +#endif if (netif_running(dev)) __netdev_watchdog_up(dev); } static inline void netif_carrier_off(struct net_device *dev) { +#ifdef CONFIG_LINKWATCH + if (!test_and_set_bit(__LINK_STATE_NOCARRIER, &dev->state)) + linkwatch_fire_event(dev); +#else set_bit(__LINK_STATE_NOCARRIER, &dev->state); +#endif } /* Hot-plugging. */ diff -uNr linux-2.4.20rc1/net/Config.in linux/net/Config.in --- linux-2.4.20rc1/net/Config.in 2002-08-03 02:39:46.000000000 +0200 +++ linux/net/Config.in 2002-11-13 22:32:46.000000000 +0100 @@ -48,6 +48,7 @@ bool ' Per-VC IP filter kludge' CONFIG_ATM_BR2684_IPFILTER fi fi + bool 'Device link state notification (EXPERIMENTAL)' CONFIG_LINKWATCH fi tristate '802.1Q VLAN Support' CONFIG_VLAN_8021Q diff -uNr linux-2.4.20rc1/net/core/Makefile linux/net/core/Makefile --- linux-2.4.20rc1/net/core/Makefile 2002-08-03 02:39:46.000000000 +0200 +++ linux/net/core/Makefile 2002-11-13 22:33:32.000000000 +0100 @@ -31,4 +31,6 @@ # Ugly. I wish all wireless drivers were moved in drivers/net/wireless obj-$(CONFIG_NET_PCMCIA_RADIO) += wireless.o +obj-$(CONFIG_LINKWATCH) += link_watch.o + include $(TOPDIR)/Rules.make diff -uNr linux-2.4.20rc1/net/core/dev.c linux/net/core/dev.c --- linux-2.4.20rc1/net/core/dev.c 2002-11-05 00:31:42.000000000 +0100 +++ linux/net/core/dev.c 2002-11-13 22:32:46.000000000 +0100 @@ -194,6 +194,12 @@ #endif +#ifdef CONFIG_LINKWATCH +extern void linkwatch_init(void); +extern void linkwatch_run_queue(void); +#endif + + /****************************************************************************************** Protocol management and registration routines @@ -2628,6 +2634,18 @@ /* Rebroadcast unregister notification */ notifier_call_chain(&netdev_chain, NETDEV_UNREGISTER, dev); } + +#ifdef CONFIG_LINKWATCH + if (test_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state)) { + /* We must not have linkwatch events pending + * on unregister. If this happens, we simply + * run the queue unscheduled, resulting in a + * noop for this device + */ + linkwatch_run_queue(); + } +#endif + current->state = TASK_INTERRUPTIBLE; schedule_timeout(HZ/4); current->state = TASK_RUNNING; @@ -2675,6 +2693,10 @@ dv_init(); #endif /* CONFIG_NET_DIVERT */ +#ifdef CONFIG_LINKWATCH + linkwatch_init(); +#endif + /* * Initialise the packet receive queues. */ diff -uNr linux-2.4.20rc1/net/core/link_watch.c linux/net/core/link_watch.c --- linux-2.4.20rc1/net/core/link_watch.c 1970-01-01 01:00:00.000000000 +0100 +++ linux/net/core/link_watch.c 2002-11-13 22:36:44.000000000 +0100 @@ -0,0 +1,149 @@ +/* + * Linux network device link state notifaction + * + * Author: + * Stefan Rompf + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + + +enum lw_bits { + LW_RUNNING = 0, + LW_SE_USED +}; + +static unsigned long linkwatch_flags = 0; +static unsigned long linkwatch_nextevent = 0; + +static void linkwatch_event(void *dummy); +static void linkwatch_timer(unsigned long dummy); + +static struct tq_struct linkwatch_tq; +static struct timer_list linkwatch_ti; + +static LIST_HEAD(lweventlist); +static spinlock_t lweventlist_lock = SPIN_LOCK_UNLOCKED; + +struct lw_event { + struct list_head list; + struct net_device *dev; +}; + +/* Avoid kmalloc() for most systems */ +static struct lw_event singleevent; + +/* Must be called with the rtnl semaphore held */ +void linkwatch_run_queue(void) { + LIST_HEAD(head); + struct list_head *n, *next; + + spin_lock_irq(&lweventlist_lock); + list_splice_init(&lweventlist, &head); + spin_unlock_irq(&lweventlist_lock); + + list_for_each_safe(n, next, &head) { + struct lw_event *event = list_entry(n, struct lw_event, list); + struct net_device *dev = event->dev; + + if (event == &singleevent) { + clear_bit(LW_SE_USED, &linkwatch_flags); + } else { + kfree(event); + } + + /* We are about to handle this device, + * so new events can be accepted + */ + clear_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state); + + if (dev->flags & IFF_UP) { + netdev_state_change(dev); + } + + dev_put(dev); + } +} + + +static void linkwatch_event(void *dummy) +{ + /* Limit the number of linkwatch events to one + * per second so that a runaway driver does not + * cause a storm of messages on the netlink + * socket + */ + linkwatch_nextevent = jiffies + HZ; + clear_bit(LW_RUNNING, &linkwatch_flags); + + rtnl_lock(); + linkwatch_run_queue(); + rtnl_unlock(); +} + + +static void linkwatch_timer(unsigned long dummy) { + (void)schedule_task(&linkwatch_tq); +} + + +void linkwatch_fire_event(struct net_device *dev) +{ + if (!test_and_set_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state)) { + unsigned long flags; + struct lw_event *event; + + if (test_and_set_bit(LW_SE_USED, &linkwatch_flags)) { + event = kmalloc(sizeof(struct lw_event), GFP_ATOMIC); + + if (unlikely(event == NULL)) { + clear_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state); + return; + } + } else { + event = &singleevent; + } + + dev_hold(dev); + event->dev = dev; + + spin_lock_irqsave(&lweventlist_lock, flags); + list_add_tail(&event->list, &lweventlist); + spin_unlock_irqrestore(&lweventlist_lock, flags); + + if (!test_and_set_bit(LW_RUNNING, &linkwatch_flags)) { + unsigned long thisevent = jiffies; + + if (thisevent >= linkwatch_nextevent) { + (void)schedule_task(&linkwatch_tq); + } else { + linkwatch_ti.expires = linkwatch_nextevent; + add_timer(&linkwatch_ti); + } + } + } +} + + +void __init linkwatch_init(void) { + linkwatch_ti.function = linkwatch_timer; + init_timer(&linkwatch_ti); + INIT_TQUEUE(&linkwatch_tq, linkwatch_event, NULL); +} + diff -uNr linux-2.4.20rc1/net/netsyms.c linux/net/netsyms.c --- linux-2.4.20rc1/net/netsyms.c 2002-11-05 00:31:42.000000000 +0100 +++ linux/net/netsyms.c 2002-11-13 22:33:32.000000000 +0100 @@ -591,6 +591,10 @@ EXPORT_SYMBOL(softnet_data); +#ifdef CONFIG_LINKWATCH +EXPORT_SYMBOL(linkwatch_fire_event); +#endif + #if defined(CONFIG_NET_RADIO) || defined(CONFIG_NET_PCMCIA_RADIO) #include EXPORT_SYMBOL(wireless_send_event); --------------FAD95F720EB083095E631054-- From Dearhamn@nu.ac.za Wed Nov 13 23:41:02 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Nov 2002 23:41:05 -0800 (PST) Received: from Raven.und.ac.za (Raven.und.ac.za [146.230.128.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAE7exuR025492 for ; Wed, 13 Nov 2002 23:41:01 -0800 Received: from smtp.nu.ac.za (nusmtp.nu.ac.za [146.230.128.63]) by Raven.und.ac.za (Switch-2.1.3/Switch-2.1.0) with ESMTP id gAE7gcn12810 for ; Thu, 14 Nov 2002 09:42:38 +0200 (SAT) Received: from Routing-Domain-MTA by smtp.nu.ac.za with Novell_GroupWise; Thu, 14 Nov 2002 09:42:35 +0200 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Date: Thu, 14 Nov 2002 09:42:27 +0200 From: "Nicholas Dearham" To: Subject: unresolved symbol main_table and local_table Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 1180 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Dearhamn@nu.ac.za Precedence: bulk X-list: netdev Hi there, I'm new to writing Linux kernel modules for an Ipaq. When I compile my module everything is fine, but when I install it onto the Ipaq I get unresolved symbol main_table and unresolved symbol local_table. How do I overcome these. The Linux code seems to already define these pointers, so I don't need anything extra in my code (at least I think!). I'm using Linux 2.4.28-rmk3 for both my Ipaq and my i686. I, however, am using the "Familiar" distribution for the Ipaq and a Toolchain cross-compiler (arm-Linux-gcc) to build the modules required. I read on "The Linux-kernel mailing list FAQ" section 8, that one must use -02 compiler extension to ensure the code gets inline'd and I'm doing this, but still get the error! Any help will be greatly appreciated, Thanks, Nic D. From Dearhamn@nu.ac.za Wed Nov 13 23:46:59 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Nov 2002 23:47:00 -0800 (PST) Received: from Raven.und.ac.za (Raven.und.ac.za [146.230.128.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAE7ktuR026485 for ; Wed, 13 Nov 2002 23:46:57 -0800 Received: from smtp.nu.ac.za (nusmtp.nu.ac.za [146.230.128.63]) by Raven.und.ac.za (Switch-2.1.3/Switch-2.1.0) with ESMTP id gAE7mYn13332 for ; Thu, 14 Nov 2002 09:48:34 +0200 (SAT) Received: from Routing-Domain-MTA by smtp.nu.ac.za with Novell_GroupWise; Thu, 14 Nov 2002 09:48:31 +0200 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Date: Thu, 14 Nov 2002 09:48:21 +0200 From: "Nicholas Dearham" To: "<" Subject: RE: unresolved symbol main_table and local_table Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 1181 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Dearhamn@nu.ac.za Precedence: bulk X-list: netdev Sorry I see I made a tying error. The Linux kernel version is 2.4.18-rmk3 and not "2.4.28-rmk3" as indicated in the mail. Thanks again, Cheers, Nic D. From zjp@iscas.ac.cn Thu Nov 14 00:31:49 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Nov 2002 00:31:53 -0800 (PST) Received: from mail.iscas.ac.cn ([159.226.5.56]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAE8VluR028064 for ; Thu, 14 Nov 2002 00:31:48 -0800 Received: (qmail 4781 invoked by uid 104); 14 Nov 2002 08:33:50 -0000 Received: from zjp@iscas.ac.cn by mail.iscas.ac.cn by uid 0 with qmail-scanner-1.14 (hbedv: 6.15.0.1. hbedv: operating system: Linux (glibc). hbedv: product version: 2.0.4. hbedv: engine version: 6.15.0.1. hbedv: packlib version: 2.0.0.8 (supports 19 formats). hbedv: vdf version: 6.15.0.7 (66928 recognized forms). hbedv: . hbedv: product: AntiVir Workstation. hbedv: key file: hbedv.key. hbedv: registered user: irene, 123. hbedv: serial number: 1001020203. hbedv: key expires: 31 May 2003. hbedv: run mode: PRIVATE. hbedv: . hbedv: product: AntiVir MailGate. hbedv: key file: hbedv.key. hbedv: registered user: irene, 123. hbedv: serial number: 1001020203. hbedv: key expires: 31 May 2003. hbedv: run mode: PRIVATE. hbedv: . hbedv: product: AntiVir (command line scanner). hbedv: key file: hbedv.key. hbedv: registered user: irene, 123. hbedv: serial number: 1001020203. hbedv: key expires: 31 May 2003. hbedv: run mode: PRIVATE. Clear:. Processed in 0.214169 secs); 14 Nov 2002 08:33:50 -0000 Received: from unknown (HELO zhengjp) (zjp@192.168.6.108) by mail.iscas.ac.cn with SMTP; 14 Nov 2002 08:33:50 -0000 Message-ID: <001801c28bb8$cd749c50$6c06a8c0@zhengjp> From: "Zheng Jianping" To: Subject: why cannot unload ipv6 module ? Date: Thu, 14 Nov 2002 16:35:35 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 175 X-archive-position: 1182 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zjp@iscas.ac.cn Precedence: bulk X-list: netdev Hi, I complie IPv6 as module and install it. But when I try to unload it, I failed. How can I make IPv6 module unload? Thanks, Zheng [[HTML alternate version deleted]] From yoshfuji@linux-ipv6.org Thu Nov 14 00:58:57 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Nov 2002 00:59:01 -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 gAE8wuuR028770 for ; Thu, 14 Nov 2002 00:58:56 -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 gAE914GR002857 for ; Thu, 14 Nov 2002 18:01:04 +0900 Date: Thu, 14 Nov 2002 18:01:04 +0900 (JST) Message-Id: <20021114.180104.77076139.yoshfuji@linux-ipv6.org> To: netdev@oss.sgi.com Subject: Re: why cannot unload ipv6 module ? From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <001801c28bb8$cd749c50$6c06a8c0@zhengjp> References: <001801c28bb8$cd749c50$6c06a8c0@zhengjp> 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: 1183 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 <001801c28bb8$cd749c50$6c06a8c0@zhengjp> (at Thu, 14 Nov 2002 16:35:35 +0800), "Zheng Jianping" says: > I complie IPv6 as module and install it. But when I try to unload it, I failed. > How can I make IPv6 module unload? unloading ipv6 module is not supported. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From zjp@iscas.ac.cn Thu Nov 14 03:32:10 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Nov 2002 03:32:14 -0800 (PST) Received: from mail.iscas.ac.cn ([159.226.5.56]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAEBW8uR008107 for ; Thu, 14 Nov 2002 03:32:09 -0800 Received: (qmail 8846 invoked by uid 104); 14 Nov 2002 11:34:12 -0000 Received: from zjp@iscas.ac.cn by mail.iscas.ac.cn by uid 0 with qmail-scanner-1.14 (hbedv: 6.15.0.1. hbedv: operating system: Linux (glibc). hbedv: product version: 2.0.4. hbedv: engine version: 6.15.0.1. hbedv: packlib version: 2.0.0.8 (supports 19 formats). hbedv: vdf version: 6.15.0.7 (66928 recognized forms). hbedv: . hbedv: product: AntiVir Workstation. hbedv: key file: hbedv.key. hbedv: registered user: irene, 123. hbedv: serial number: 1001020203. hbedv: key expires: 31 May 2003. hbedv: run mode: PRIVATE. hbedv: . hbedv: product: AntiVir MailGate. hbedv: key file: hbedv.key. hbedv: registered user: irene, 123. hbedv: serial number: 1001020203. hbedv: key expires: 31 May 2003. hbedv: run mode: PRIVATE. hbedv: . hbedv: product: AntiVir (command line scanner). hbedv: key file: hbedv.key. hbedv: registered user: irene, 123. hbedv: serial number: 1001020203. hbedv: key expires: 31 May 2003. hbedv: run mode: PRIVATE. Clear:. Processed in 0.217996 secs); 14 Nov 2002 11:34:12 -0000 Received: from unknown (HELO zhengjp) (zjp@192.168.6.108) by mail.iscas.ac.cn with SMTP; 14 Nov 2002 11:34:11 -0000 Message-ID: <000e01c28bd1$ffdaf2c0$6c06a8c0@zhengjp> From: "Zheng Jianping" To: Cc: References: <001801c28bb8$cd749c50$6c06a8c0@zhengjp> <20021114.180104.77076139.yoshfuji@linux-ipv6.org> Subject: Re: why cannot unload ipv6 module ? Date: Thu, 14 Nov 2002 19:35:57 +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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-archive-position: 1184 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zjp@iscas.ac.cn Precedence: bulk X-list: netdev > > I complie IPv6 as module and install it. But when I try to unload it, I failed. > > How can I make IPv6 module unload? > > unloading ipv6 module is not supported. > Can I modify the IPv6 source code to make unloading supported? If yes, how to modify it? Zheng From ahu@outpost.ds9a.nl Thu Nov 14 03:41:29 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Nov 2002 03:41:31 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAEBfSuR008509 for ; Thu, 14 Nov 2002 03:41:29 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 72DCF4508; Thu, 14 Nov 2002 12:43:10 +0100 (CET) Date: Thu, 14 Nov 2002 12:43:10 +0100 From: bert hubert To: Stefan Rompf Cc: netdev@oss.sgi.com Subject: Re: Patch: Backport of link state notification to 2.4.20rc1 Message-ID: <20021114114310.GA9977@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Stefan Rompf , netdev@oss.sgi.com References: <3DD2D204.C9B7FA2D@isg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DD2D204.C9B7FA2D@isg.de> User-Agent: Mutt/1.3.28i X-archive-position: 1185 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev On Wed, Nov 13, 2002 at 11:28:20PM +0100, Stefan Rompf wrote: > Hi, > > having the link state notification stuff in 2.4 is still a major goal > for me. I've taken the 2.5 implementation Jamal and I have worked out, > removed the semantic changes towards RFC2863 and replaced the workqueue > with a combination of timer and kevent. By the way, is the 2.5 implementation going in? Would sure be lovely. -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From davem@redhat.com Thu Nov 14 08:51:57 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Nov 2002 08:52:03 -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 gAEGpvuR032636 for ; Thu, 14 Nov 2002 08:51:57 -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 IAA22571; Thu, 14 Nov 2002 08:51:10 -0800 Date: Thu, 14 Nov 2002 08:51:09 -0800 (PST) Message-Id: <20021114.085109.06389530.davem@redhat.com> To: kuznet@ms2.inr.ac.ru Cc: ahu@ds9a.nl, gem@asplinux.ru, netdev@oss.sgi.com Subject: Re: automatic keying works! Re: off by one error in 3des cbc keying From: "David S. Miller" In-Reply-To: <200211132046.XAA12943@sex.inr.ac.ru> References: <20021113085517.GA9134@outpost.ds9a.nl> <200211132046.XAA12943@sex.inr.ac.ru> 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: 1186 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: kuznet@ms2.inr.ac.ru Date: Wed, 13 Nov 2002 23:46:40 +0300 (MSK) Log message for Dave: - xfrm_state.c: never return mature SAs on getspi. - af_key.c: do not forget to delete dummy super-larvals when they are resolved - af_key.c: wow! specially for this case I added gfp argument to xfrm_alloc_policy() and forgot to use it really. Applied, thanks. From pb@bieringer.de Thu Nov 14 11:52:59 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Nov 2002 11:53:05 -0800 (PST) Received: from smtp2.aerasec.de (gromit.aerasec.de [195.226.187.57]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAEJqwuR001968 for ; Thu, 14 Nov 2002 11:52:59 -0800 Received: from localhost (localhost [127.0.0.1]) by smtp2.aerasec.de (Postfix) with SMTP id C288913864 for ; Thu, 14 Nov 2002 20:54:36 +0100 (CET) X-AV-Checked: Thu Nov 14 20:54:36 2002 smtp2.aerasec.de Received: from [192.168.1.2] (p50805423.dip.t-dialin.net [80.128.84.35]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by smtp2.aerasec.de (Postfix) with ESMTP id A42B013863 for ; Thu, 14 Nov 2002 20:54:35 +0100 (CET) Date: Thu, 14 Nov 2002 20:54:07 +0100 From: Peter Bieringer To: netdev@oss.sgi.com Subject: Re: why cannot unload ipv6 module ? Message-ID: <18430000.1037303647@localhost> In-Reply-To: <000e01c28bd1$ffdaf2c0$6c06a8c0@zhengjp> References: <001801c28bb8$cd749c50$6c06a8c0@zhengjp> <20021114.180104.77076139.yoshfuji@linux-ipv6.org> <000e01c28bd1$ffdaf2c0$6c06a8c0@zhengjp> X-Mailer: Mulberry/3.0.0a5 (Linux/x86) X-URL: http://www.bieringer.de/pb/ X-OS: Linux MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========1825439384==========" X-archive-position: 1187 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pb@bieringer.de Precedence: bulk X-list: netdev --==========1825439384========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline --On Thursday, November 14, 2002 07:35:57 PM +0800 Zheng Jianping wrote: > >> > I complie IPv6 as module and install it. But when I try to >> > unload it, I > failed. >> > How can I make IPv6 module unload? >> >> unloading ipv6 module is not supported. >> > Can I modify the IPv6 source code to make unloading supported? > If yes, how to modify it? A little bit offtopic: does anyone know the state about the work on the ipv*4* module? There was some rumour some months ago. Would be nice if some day in the future an IPv6-only Linux box would be possible. Peter --- Dr. Peter Bieringer mailto: pb at bieringer dot de http://www.bieringer.de/pb/ Key 0x958F422D : B501 24F4 9418 23E2 C0F3 F833 7B57 AA7B 958F 422D --==========1825439384========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE90/9te1eqe5WPQi0RAk+yAKDBU9xqItqXk9NMJachzbTvWGEp3ACg61Kq ON9EdhVXbHzuvP1RaSpFvTE= =1fDb -----END PGP SIGNATURE----- --==========1825439384==========-- From yoshfuji@linux-ipv6.org Thu Nov 14 14:46:25 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Nov 2002 14:46:30 -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 gAEMkOuR005900 for ; Thu, 14 Nov 2002 14:46:24 -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 gAEMmPGR007340; Fri, 15 Nov 2002 07:48:29 +0900 Date: Fri, 15 Nov 2002 07:48:25 +0900 (JST) Message-Id: <20021115.074825.16291557.yoshfuji@linux-ipv6.org> To: zjp@iscas.ac.cn Cc: netdev@oss.sgi.com Subject: Re: why cannot unload ipv6 module ? From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <000e01c28bd1$ffdaf2c0$6c06a8c0@zhengjp> References: <001801c28bb8$cd749c50$6c06a8c0@zhengjp> <20021114.180104.77076139.yoshfuji@linux-ipv6.org> <000e01c28bd1$ffdaf2c0$6c06a8c0@zhengjp> 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: 1188 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 <000e01c28bd1$ffdaf2c0$6c06a8c0@zhengjp> (at Thu, 14 Nov 2002 19:35:57 +0800), "Zheng Jianping" says: > > > I complie IPv6 as module and install it. But when I try to unload it, I > failed. > > > How can I make IPv6 module unload? > > > > unloading ipv6 module is not supported. > > > Can I modify the IPv6 source code to make unloading supported? You could. > If yes, how to modify it? In fact, you can unload if you pass "unloading=1" when loading. But, rmmod ipv6 does not work properly and we cannot insmod ipv6 again. We've fixed this (and code is in our (USAGI Project 's) tree), but kernel panics if we unloaded ipv6 module when *any* ipv6 sockets exist. BTW, Don't you think that if we knew all, we've done it? :-) -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From werner@almesberger.net Thu Nov 14 20:33:13 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Nov 2002 20:33:17 -0800 (PST) Received: from host.almesberger.net (almesberger.net [63.105.73.239] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAF4XDuR013477 for ; Thu, 14 Nov 2002 20:33:13 -0800 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.9.3/8.9.3) with ESMTP id UAA16797 for ; Thu, 14 Nov 2002 20:34:59 -0800 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id gAF4Yqq11681 for netdev@oss.sgi.com; Fri, 15 Nov 2002 01:34:52 -0300 Date: Fri, 15 Nov 2002 01:34:52 -0300 From: Werner Almesberger To: netdev@oss.sgi.com Subject: TCP connection passing, version 4 Message-ID: <20021115013452.A11669@almesberger.net> References: <20021031000249.A20233@almesberger.net> <20021031045909.A15756@almesberger.net> <20021031200017.A21544@almesberger.net> <20021101182123.A30594@almesberger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021101182123.A30594@almesberger.net>; from wa@almesberger.net on Fri, Nov 01, 2002 at 06:21:23PM -0300 X-archive-position: 1189 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 A minor update: http://www.almesberger.net/tcpcp/tcpcp-4.tar.gz The main changes are that TCP_KICK has turned into the slightly more general TCP_CP_FN option, and that I've written down a few thoughts on "real" checkpointing in doc/README.CHECKPOINTING The funny thing is that, when I started writing, I suspected that checkpointing wouldn't really be possible, but then I realized how it might actually work (okay, with a few hacks, but ... ;-) The patch is now relative to 2.5.47. - Werner ----------------------------------- CHANGES ----------------------------------- Version 4 (15-NOV-2002) ----------------------- - upgraded to the 2.5.47 kernel - added doc/README.CHECKPOINTING with a few reflections on how tcpcp could be abused for "real" checkpointing, where the previous connection owner suddenly dies - renamed TCP_KICK to TCP_CP_FN, and added a sub-function code in optval - renamed tcpcp_kick to tcpcp_activate -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From srompf@isg.de Fri Nov 15 05:18:59 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Nov 2002 05:19:05 -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 gAFDIwuR004705 for ; Fri, 15 Nov 2002 05:18:59 -0800 Received: from isg.de (dialin-145-254-193-199.arcor-ip.net [145.254.193.199]) by mail.isg.de (Postfix) with ESMTP id EC3FAE51872; Fri, 15 Nov 2002 14:20:36 +0100 (CET) Message-ID: <3DD4F4A6.351D79F0@isg.de> Date: Fri, 15 Nov 2002 14:20:38 +0100 From: Stefan Rompf X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.20-rc1-lw i686) X-Accept-Language: en MIME-Version: 1.0 To: bert hubert Cc: netdev@oss.sgi.com Subject: Re: Patch: Backport of link state notification to 2.4.20rc1 References: <3DD2D204.C9B7FA2D@isg.de> <20021114114310.GA9977@outpost.ds9a.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1190 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 Hi, bert hubert wrote: > By the way, is the 2.5 implementation going in? Would sure be lovely. it should be somewhere in David's inbox waiting for his evaluation. Stefan From jon@rockwelldatacorp.com Fri Nov 15 07:48:58 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Nov 2002 07:49:05 -0800 (PST) Received: from rockwelldatacorp.com (108.Red-80-33-216.pooles.rima-tde.net [80.33.216.108]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFFmtuR012317 for ; Fri, 15 Nov 2002 07:48:56 -0800 Message-Id: <200211151548.gAFFmtuR012317@oss.sgi.com> From: "Jon F Federhenn" To: Subject: SAP specialists required for Europe. Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Date: Fri, 15 Nov 2002 16:50:10 +0100 Reply-To: "Jon F Federhenn" X-archive-position: 1191 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jon@rockwelldatacorp.com Precedence: bulk X-list: netdev Hello I have a couple of contacts who are in Germany and Switzerland who are both looking for SAP people for some new projects. They need people in various areas and they do not need to be German speakers or have permits for CH. The companies will look at people as long as they have good experience in an area of SAP. I also know a few German speakers looking for permanent work in Europe and hence if anyone knows of any positions I will forward them on the details. Please drop me a mail if of interest. Kind regards Jon From mcr@sandelman.ottawa.on.ca Fri Nov 15 10:47:14 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Nov 2002 10:47:18 -0800 (PST) Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFIl9uR021115 for ; Fri, 15 Nov 2002 10:47:14 -0800 Received: from sandelman.ottawa.on.ca (dnssec-workshop.sandelman.ca. [12.108.253.22]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id gAFImmc03688 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Fri, 15 Nov 2002 13:48:56 -0500 (EST) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gAFHcIvK006230 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Fri, 15 Nov 2002 12:38:19 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gAFHcDwX006227 for ; Fri, 15 Nov 2002 12:38:18 -0500 Message-Id: <200211151738.gAFHcDwX006227@sandelman.ottawa.on.ca> To: netdev@oss.sgi.com Subject: looking for help with scanning of IPv6 interfaces Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 15 Nov 2002 12:38:12 -0500 From: Michael Richardson X-archive-position: 1192 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcr@sandelman.ottawa.on.ca Precedence: bulk X-list: netdev -----BEGIN PGP SIGNED MESSAGE----- 1) Awhile ago there was a flame war about using SIOCGIFCONF/SIOCGLIFCONF to get lists of interfaces. This was suggested as being a bad way. 2) bind 9.3snapshot is able to get a list of IPv4 addresses with SIOCGIFCONF, 3) it is not able to get IPv6 addresses with SIOCGLIFCONF. Marc Andrews, sitting next to me, asked if I knew what the offical magic was. Can someone point me that officially blessed way to do this? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPdUxAoqHRg3pndX9AQEp3QQAzdLmpHCTKpQB2i6GKLC/jMts/YxiPpuS M7gf6xW9Ofoycq5QG28RUSwtkw3BR7sWuGFYBHXstjYau7dyInftCdpdvLA6q3xJ lOakb35mQBqYBS3yyHjEJX0sUo6S1J5ApkPinnGDaQlpJEQaju/AVAJtun8VovUz TkbL+BO53zc= =kG1L -----END PGP SIGNATURE----- From ak@suse.de Fri Nov 15 10:59:10 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Nov 2002 10:59:11 -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 gAFIx9uR022265 for ; Fri, 15 Nov 2002 10:59:09 -0800 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 08403144A7; Fri, 15 Nov 2002 20:00:52 +0100 (MET) Date: Fri, 15 Nov 2002 20:00:51 +0100 From: Andi Kleen To: Michael Richardson Cc: netdev@oss.sgi.com Subject: Re: looking for help with scanning of IPv6 interfaces Message-ID: <20021115200051.A14677@wotan.suse.de> References: <200211151738.gAFHcDwX006227@sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211151738.gAFHcDwX006227@sandelman.ottawa.on.ca> User-Agent: Mutt/1.3.22.1i X-archive-position: 1193 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 Fri, Nov 15, 2002 at 12:38:12PM -0500, Michael Richardson wrote: > 1) Awhile ago there was a flame war about using SIOCGIFCONF/SIOCGLIFCONF > to get lists of interfaces. This was suggested as being a bad way. > > 2) bind 9.3snapshot is able to get a list of IPv4 addresses with SIOCGIFCONF, > > 3) it is not able to get IPv6 addresses with SIOCGLIFCONF. > > Marc Andrews, sitting next to me, asked if I knew what the offical magic > was. Can someone point me that officially blessed way to do this? Physical devices are read using /proc/net/dev If you want IPv6 addresses you can read and parse /proc/net/if_inet6 That is the old fashioned way. The new fashioned one is to query them using rtnetlink. You use a RTM_GETADDR NLM_F_REQUEST query with wildcard (NLM_F_ROOT) to get a full list. See the netlink,rtnetlink, libnetlink manpages and iproute2 as an example. It is easier when you use libnetlink. -Andi From jgarzik@pobox.com Fri Nov 15 10:59:40 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Nov 2002 10:59:41 -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 gAFIxduR022479 for ; Fri, 15 Nov 2002 10:59:39 -0800 Received: from nat-pool-rdu.redhat.com ([66.187.233.200] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 18CliV-0002NT-00; Fri, 15 Nov 2002 19:01:23 +0000 Message-ID: <3DD54482.802@pobox.com> Date: Fri, 15 Nov 2002 14:01:22 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021018 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: davem@redhat.com, kuznet@ms2.inr.ac.ru Subject: qdisc_restart locking bug? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1194 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 When qdisc_restart() is called from qdisc_run(), dev->queue_lock is obtained via spin_lock_bh(). When dev->hard_start_xmit() is called from qdisc_restart(), dev->queue_lock is dropped, and then re-acquired using only spin_lock(). So, doesn't qdisc_restart need s/spin_lock/spin_lock_bh/ for dev->queue_lock? When looking at the dev_queue_xmit -> qdisc_run -> qdisc_restart call path, it seems so to me. Jeff From kuznet@ms2.inr.ac.ru Fri Nov 15 13:40:53 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Nov 2002 13:41:00 -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 gAFLepuR029208 for ; Fri, 15 Nov 2002 13:40:52 -0800 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id AAA26706; Sat, 16 Nov 2002 00:41:25 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200211152141.AAA26706@sex.inr.ac.ru> Subject: Re: qdisc_restart locking bug? To: jgarzik@pobox.com (Jeff Garzik) Date: Sat, 16 Nov 2002 00:41:25 +0300 (MSK) Cc: netdev@oss.sgi.com, davem@redhat.com In-Reply-To: <3DD54482.802@pobox.com> from "Jeff Garzik" at Nov 15, 2 02:01:22 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 1195 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! > When dev->hard_start_xmit() is called from qdisc_restart(), > dev->queue_lock is dropped, Using spin_unlock(). softirqs are not enabled. > and then re-acquired using only spin_lock(). Yes. > So, doesn't qdisc_restart need s/spin_lock/spin_lock_bh/ for > dev->queue_lock? It need not. Alexey From becker@scyld.com Fri Nov 15 14:46:00 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Nov 2002 14:46:02 -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 gAFMk0uR032729 for ; Fri, 15 Nov 2002 14:46:00 -0800 Received: from localhost (becker@localhost) by beohost.scyld.com (8.11.6/8.11.6) with ESMTP id gAFMku216967; Fri, 15 Nov 2002 17:46:56 -0500 Date: Fri, 15 Nov 2002 17:46:55 -0500 (EST) From: Donald Becker To: Andi Kleen cc: Michael Richardson , Subject: Re: looking for help with scanning of IPv6 interfaces In-Reply-To: <20021115200051.A14677@wotan.suse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1196 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, 15 Nov 2002, Andi Kleen wrote: > On Fri, Nov 15, 2002 at 12:38:12PM -0500, Michael Richardson wrote: > > 1) Awhile ago there was a flame war about using SIOCGIFCONF/SIOCGLIFCONF > > to get lists of interfaces. This was suggested as being a bad way. ... > > Marc Andrews, sitting next to me, asked if I knew what the offical magic > > was. Can someone point me that officially blessed way to do this? Here is a comment and our standard snippet of code to do this: ________________ char linebuf[400]; /* Max possible line is 192 chars. */ FILE *fp; int ifnum; /* Yes, the only list of physical network interfaces is /proc/net/dev. * Through 2.4.19, there is no other way to get 'dev_base' from the * kernel. The ioctl(..SIOCGIFCONF..) call comes closes, but only * returns a value for interfaces once assigned a protocol address. */ fp = fopen("/proc/net/dev", "r"); if (fp == NULL) { fprintf(stderr, "Failed to open /proc/net/dev.\n"); return 0; } /* The format of /proc/net/dev is "%6s:%8lu ..." */ ifnum = 0; while (fgets(linebuf, sizeof linebuf, fp) && (ifnum < max_numifs)) { struct ifreq ifr, ifrq_index, ifrq_hwaddr; char *p, *ifname; int flags; /* This is approximately sscanf(linebuf, "%s:", ifnamebuf). */ p = index(linebuf, ':'); if (!p) continue; *p = 0; /* Skip leading space. */ for (ifname = linebuf; isspace(*ifname); ifname++) ; strncpy(ifr.ifr_name, ifname, sizeof ifr.ifr_name); /* Get the interface flags */ if (ioctl(sockfd, SIOCGIFFLAGS, &ifr)) { fprintf(stderr, "Failed to get information about network " "interface %s.\n SIOCGIFFLAGS: %s\n", ifname, strerror(errno)); continue; } if (ifr.ifr_flags & IFF_LOOPBACK) continue; flags = ifr.ifr_flags; strncpy(ifrq_index.ifr_name, ifname, sizeof ifr.ifr_name); strncpy(ifrq_hwaddr.ifr_name, ifname, sizeof ifr.ifr_name); if (ioctl(sockfd, SIOCGIFINDEX, &ifrq_index) < 0 || ioctl(sockfd, SIOCGIFHWADDR, &ifrq_hwaddr) < 0 ) { fprintf(stderr, "Failed to get address information for network " "interface %s: %s\n", ifname, strerror(errno)); } ________________ > Physical devices are read using /proc/net/dev ... > That is the old fashioned way. > > The new fashioned one is to query them using rtnetlink. You use a RTM_GETADDR > NLM_F_REQUEST query with wildcard (NLM_F_ROOT) to get a full list. > See the netlink,rtnetlink, libnetlink manpages and iproute2 as an example. > It is easier when you use libnetlink. Do you have a snippet of code? What kernel version does this start working? Of course for code that needs to work with already deployed systems, you need to have code for the old method around anyway... -- 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 ak@suse.de Fri Nov 15 14:50:18 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Nov 2002 14:50:20 -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 gAFMoHuR001555 for ; Fri, 15 Nov 2002 14:50:17 -0800 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 0C465144D7; Fri, 15 Nov 2002 23:52:01 +0100 (MET) Date: Fri, 15 Nov 2002 23:52:00 +0100 From: Andi Kleen To: Donald Becker Cc: Andi Kleen , Michael Richardson , netdev@oss.sgi.com Subject: Re: looking for help with scanning of IPv6 interfaces Message-ID: <20021115235200.B8265@wotan.suse.de> References: <20021115200051.A14677@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i X-archive-position: 1197 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 > > Physical devices are read using /proc/net/dev > ... > > That is the old fashioned way. > > > > The new fashioned one is to query them using rtnetlink. You use a RTM_GETADDR > > NLM_F_REQUEST query with wildcard (NLM_F_ROOT) to get a full list. > > See the netlink,rtnetlink, libnetlink manpages and iproute2 as an example. > > It is easier when you use libnetlink. > > Do you have a snippet of code? Check iproute2 or zebra source. iproute2 has a libnetlink which is quite useful. I also wrote some manpages (netlink(3),netlink(7),rtnetlink(7) etc, but admittedly they are not very good) > What kernel version does this start working? Somewhere in Linux 2.1. > > Of course for code that needs to work with already deployed systems, you > need to have code for the old method around anyway... Only when you still want to support 2.0. Ok some people do not enable netlink in their kernel configuration, but many modern distributions require it for booting now (because the network init scripts use iproute2), so this shouldn't be a big issue anymore. -Andi From niv@us.ibm.com Fri Nov 15 16:44:09 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Nov 2002 16:44:14 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAG0i8uR005754 for ; Fri, 15 Nov 2002 16:44:08 -0800 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gAG0jqsr023592 for ; Fri, 15 Nov 2002 19:45:52 -0500 Received: from us.ibm.com (dyn9-47-18-188.beaverton.ibm.com [9.47.18.188]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gAG0jodK277948; Fri, 15 Nov 2002 17:45:50 -0700 Message-ID: <3DD5952E.CD88DD67@us.ibm.com> Date: Fri, 15 Nov 2002 16:45:34 -0800 From: Nivedita Singhvi X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: mjbligh@us.ibm.com Subject: Re: Bugzilla bug tracking database for 2.5 now available. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1198 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 Bouncing this to netdev, since not all of us read lkml, and quite a few people here who might want to use the bug database are still in the dark about it.. Am including Martin's original post on the OSDL Linux 2.5 Bug Tracker below, and if you want to follow the resultant thread, see: http://marc.theaimsgroup.com/?l=linux-kernel&m=103723818421551&w=2 thanks, Nivedita > The bugzilla database we proposed earlier is now available for > use, hosted by OSDL. > > http://bugme.osdl.org > > Feel free to go ahead and create yourself an account, and log > bugs in there. This is only for 2.5 bugs currently, and the main > intent is to help us drive 2.5 into a timely and stable 2.6 (or 3.0). > > Please let me or the supplied mailto URLs know of any problems you > encounter, but please be patient with any inital teething problems > and don't tell slashdot just yet ;-) Apologies for this not being > ready quite at Halloween ... and there's not much data in there > right now, but we'll keep feeding it over the coming few days, > including importing Thomas Molina's list of bugs. > > The categories probably need some more work, they'll evolve as > bugs get logged. The reason I own huge numbers of subsystems is > not just because I'm a derranged megalomaniac, it's more to do > with the fact that I don't have other people available with > accounts created to own them. Brave volunteers who've created an > account would be most welcome, ideally the code maintainers for > those subsystems, but other people familiar with those areas would > be a great substitute. ;-) > > M. From razakgreg@fastermail.com Sat Nov 16 05:59:47 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Nov 2002 05:59:50 -0800 (PST) Received: from ws4.hk5.outblaze.com (202-77-181-85.outblaze.com [202.77.181.85]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAGDxkuR029787 for ; Sat, 16 Nov 2002 05:59:47 -0800 Received: (qmail 22979 invoked by uid 1001); 16 Nov 2002 14:01:37 -0000 Message-ID: <20021116140137.22978.qmail@fastermail.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [216.139.174.13] by ws4.hk5.outblaze.com with http for razakgreg@fastermail.com; Sat, 16 Nov 2002 22:01:37 +0800 From: "Greg Razak" To: netdev@oss.sgi.com Date: Sat, 16 Nov 2002 22:01:37 +0800 Subject: GOD`S WORK X-Originating-Ip: 216.139.174.13 X-Originating-Server: ws4.hk5.outblaze.com X-archive-position: 1199 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: razakgreg@fastermail.com Precedence: bulk X-list: netdev ATTENTION: INVESTMENT PROPOSAL. Dear Sir, I hope this mail will reach you in the best of health and business conditions and receive the most desired attention from you even as we have not any previous correspondence before. I am constrained by insufficient information about you to express in full the main objectives of this proposal. However, kindly reach me immediately for more information, should you agree to its content. My colleagues and I would like to solicit you kindness in assisting us in transfering some fund from our country to yours for safe keeping. The total amount of fund is $36million (US dollars). I am a Principal Accountant to the Nigerian Ministry of Aviation, and the Chairman to the Federal Tenders Board in charge of contract award comittee in Nigeria. Basically, you would be required to norminate a suitable bank account that will convinently accomodate the total fund. Account could be a fresh or an already existing one, and could be individual or corporate account. On completion of the transaction, you shall have a benefit of 30% of the fund for your envisaged efforts and assistance rendered 10% shall be used to settle any expenses both you and I shall incure on the course of this transaction . Information of this proposal will be sent to you as soon as your response is recieved. Please send me e-mail for more details on how to commence the whole transaction. I will need your private phone and fax numbers for easy communication. This proposal is strictly confidential, free from any form of risk and does not depend on any particular feild of trade to prosecute. It however requires your adequate participation and support to enable it's accomplishment on schedule. Thanks in anticipation and God bless. Best regards, Mr.RAZAK GREG. -- _______________________________________________ Get your free email from http://www.fastermail.com Powered by Outblaze From consultas@stopcar.com.ar Sat Nov 16 15:47:21 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Nov 2002 15:47:28 -0800 (PST) Received: from stopcar.com.ar (ADSL215-117.advancedsl.com.ar [200.51.215.117]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAGNlJuR006664 for ; Sat, 16 Nov 2002 15:47:20 -0800 Message-Id: <200211162347.gAGNlJuR006664@oss.sgi.com> From: STOPCAR To: netdev@oss.sgi.com Subject: Cada 5 minutos es Robado un Vehiculo Date: 16 Nov 2002 20:50:50 -0300 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-archive-position: 1200 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: consultas@stopcar.com.ar Precedence: bulk X-list: netdev ¿Con qué cree Ud. Que debe contar una empresa recuperadora de vehículos robados? En los tiempos que corren han proliferado los emprendimientos de empresas, pero pocos reúnen los requisitos mínimos e indispensables para un normal y eficaz rendimiento. Por ello STOPCAR S.A., es líder de este segmento, basado en un crecimiento sostenido a través de los años, que nos permite contar, entre otras cosas, con: 52000 abonados Cobertura las 24 hs. Los 365 días del año. Frecuencias y licencias propias. Red de Agentes y Representantes en todo el país. Fabricación Nacional (dispositivo fabricado en nuestro laboratorio de análisis técnico, con mejoras permanentes de alta tecnología). Cobertura Nacional. A través de nuestra extensa red de antenas y transmisores dispuestos en todo el país. (UNICA FRECUENCIA NACIONAL) Homologación: Nuestros dispositivos se encuentran homologados por el Centro de Experimentación y Seguridad Vial Argentina S.A. (C.E.S.V.I.) Flota de Recupero. Contamos con 45 vehículos de rastreo, personal idóneo y preparado especialmente para sus tareas y dos unidades aéreas de localización. Empresa Nacional. Mas de 250 familias forman nuestras líneas de tareas en una Empresa Nacional de permanente reinversión. 98% de recuperos efectivos. Eficiencia y Confiabilidad. (Convenios con las principales Compañías de Seguros) Sin embargo nos preguntamos una y otra vez si con esto alcanza... Y la respuesta es contundente: NO. Nuestro posicionamiento nos compromete aun más y nos hace crecer día a día. Ahora Ud. Es quién debe preguntarse: ¿A quién confiarle su seguridad? STOPCAR S.A. abre sus puertas para que nos vea trabajar y reconozca nuestra labor. No se deje engañar; la confiabilidad, la experiencia, los verdaderos resultados, no se declaman, se logran con trabajo a través del tiempo. Por ello cuando tenga que elegir, COMPARE, VERIFIQUE, CALIFIQUE, Y LUEGO DECIDA. ¿Si le roban su vehículo, desearía que se lo recuperen de inmediato? ¿Considera Usted importante conocer costos reales? La respuesta y solución a estos interrogantes la tiene STOPCAR S.A. SOLICITE ASESORAMIENTO SIN CARGO AL 4489-9000 o vía Email STOPCAR S.A. Brinda servicios, responder a sus preguntas es uno de ellos. Consulte también como tener STOPCAR en comodato. STOPCAR S.A., seguridad garantizada. Este mail no es considerado SPAM ya que es la unica vez que lo recibira y podra ser eliminado de nuestras listas solicitandolo enviando un mail con el asunto "R E M O V E R " Gracias por leer el mail y disculpe las molestias. From tedlee@ece.skku.ac.kr Mon Nov 18 00:50:20 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Nov 2002 00:50:27 -0800 (PST) Received: from ece.skku.ac.kr ([61.72.106.33]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAI8oJuR000726 for ; Mon, 18 Nov 2002 00:50:20 -0800 Received: from tedlee (rc4000.skku.ac.kr [203.252.53.136]) by ece.skku.ac.kr (8.12.0/8.12.0) with ESMTP id gAI99sN3016904 for ; Mon, 18 Nov 2002 18:09:54 +0900 (KST) From: "Taekeun Lee" To: Subject: Question.. Traffic Shaping in Linux Date: Mon, 18 Nov 2002 17:52:27 +0900 Message-ID: <000001c28edf$d2634ed0$0105a8c0@tedlee> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 688 X-archive-position: 1201 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tedlee@ece.skku.ac.kr Precedence: bulk X-list: netdev Hello, My name is Taekeun Lee.. I'm a graduate student in Sungkyunkwan Univ. in Korea.. This e-mail address(netdev@oss.sgi.com) is introduced by Alan Cox.. My Question is Traffic shaping in linux.. Existed traffic shaper in Linux kernel module is possible low bandwidth limitation.. ( < 1Mbps ) And, High bandwidth limitation can use CBQ kernel facilities.. But, My router is working with RSVP Daemon, RSVP Daemon controls packets by CBQ mechanism.. So, I can't use CBQ facility for traffic shaping.. I want to traffic shaping in Linux without CBQ mechanism.. Can U suggest a solution to this problem? I'm sorry, my poor english.. [[HTML alternate version deleted]] From aries@illusion.snu.ac.kr Mon Nov 18 05:26:53 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Nov 2002 05:26:57 -0800 (PST) Received: from odin.snu.ac.kr (odin.snu.ac.kr [147.46.112.163]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAIDQquR009051 for ; Mon, 18 Nov 2002 05:26:52 -0800 Received: from localhost (aries@localhost) by odin.snu.ac.kr (8.11.6+Sun/8.11.6) with ESMTP id gAIDOnR16204 for ; Mon, 18 Nov 2002 22:24:52 +0900 (KST) Date: Mon, 18 Nov 2002 22:24:49 +0900 (KST) From: Hyunjung Park X-Sender: aries@odin To: netdev@oss.sgi.com Subject: help Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1202 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: aries@illusion.snu.ac.kr Precedence: bulk X-list: netdev From aries@illusion.snu.ac.kr Mon Nov 18 05:33:20 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Nov 2002 05:33:21 -0800 (PST) Received: from odin.snu.ac.kr (odin.snu.ac.kr [147.46.112.163]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAIDXIuR009453 for ; Mon, 18 Nov 2002 05:33:19 -0800 Received: from localhost (aries@localhost) by odin.snu.ac.kr (8.11.6+Sun/8.11.6) with ESMTP id gAIDVJj16227 for ; Mon, 18 Nov 2002 22:31:19 +0900 (KST) Date: Mon, 18 Nov 2002 22:31:19 +0900 (KST) From: Hyunjung Park X-Sender: aries@odin To: netdev@oss.sgi.com Subject: help (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1203 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: aries@illusion.snu.ac.kr Precedence: bulk X-list: netdev help From ahu@outpost.ds9a.nl Mon Nov 18 11:54:19 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Nov 2002 11:54:22 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAIJsIuR025340 for ; Mon, 18 Nov 2002 11:54:19 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 079FD450F; Mon, 18 Nov 2002 20:56:19 +0100 (CET) Date: Mon, 18 Nov 2002 20:56:19 +0100 From: bert hubert To: kuznet@ms2.inr.ac.ru Cc: davem@redhat.com, gem@asplinux.ru, netdev@oss.sgi.com Subject: Re: automatic keying works! Re: off by one error in 3des cbc keying Message-ID: <20021118195618.GA22603@outpost.ds9a.nl> Mail-Followup-To: bert hubert , kuznet@ms2.inr.ac.ru, davem@redhat.com, gem@asplinux.ru, netdev@oss.sgi.com References: <20021113220311.GA29358@outpost.ds9a.nl> <200211132235.BAA13386@sex.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211132235.BAA13386@sex.inr.ac.ru> User-Agent: Mutt/1.3.28i X-archive-position: 1204 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev On Thu, Nov 14, 2002 at 01:35:39AM +0300, kuznet@ms2.inr.ac.ru wrote: > > I now see a proper soft expire, new SAs being setup, old SAs in state 'dying', > > and traffic flowing nicely. Even with soft expire and no traffic, I see a > > new SA being negotiated. > > Wait for a while and you will see message sort of: > > Nov 13 20:48:59 mops [291/0/0] racoon: INFO: isakmp.c:1521:isakmp_ph1expire(): > ISAKMP-SA expired 192.168.1.202[500]-192.168.1.106[500] spi:c9549e2b4f33f8a3:655bf176d4531765 Did IPSEC die in 2.5.48? I can't get automatic keying to work, it only says this once every two minutes: 2002-11-18 20:54:15: DEBUG: pfkey.c:191:pfkey_handler(): get pfkey EXPIRE message 2002-11-18 20:54:15: INFO: pfkey.c:1364:pk_recvexpire(): IPsec-SA expired: ESP/Transport 10.0.0.216->10.0.0.11 2002-11-18 20:54:15: DEBUG: pfkey.c:1376:pk_recvexpire(): no such a SA found: ESP/Transport 10.0.0.216->10.0.0.11 I did turn on CONFIG_XFRM_USER, does it conflict with PF_KEY? Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From kuznet@ms2.inr.ac.ru Mon Nov 18 12:04:24 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Nov 2002 12:04: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 gAIK4NuR025858 for ; Mon, 18 Nov 2002 12:04:23 -0800 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id XAA12908; Mon, 18 Nov 2002 23:04:47 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200211182004.XAA12908@sex.inr.ac.ru> Subject: Re: automatic keying works! Re: off by one error in 3des cbc keying To: ahu@ds9a.nl (bert hubert) Date: Mon, 18 Nov 2002 23:04:47 +0300 (MSK) Cc: davem@redhat.com, gem@asplinux.ru, netdev@oss.sgi.com In-Reply-To: <20021118195618.GA22603@outpost.ds9a.nl> from "bert hubert" at Nov 18, 2 08:56:19 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 1205 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! > I did turn on CONFIG_XFRM_USER, does it conflict with PF_KEY? Yes, their interaction is still... mmm... not polished. Build both xfrm_user and af_key as modules and load only one for now. Alexey From davem@redhat.com Mon Nov 18 12:09:24 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Nov 2002 12:09:26 -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 gAIK9OuR026261 for ; Mon, 18 Nov 2002 12:09:24 -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 MAA25893; Mon, 18 Nov 2002 12:08:16 -0800 Date: Mon, 18 Nov 2002 12:08:16 -0800 (PST) Message-Id: <20021118.120816.45559196.davem@redhat.com> To: ahu@ds9a.nl Cc: kuznet@ms2.inr.ac.ru, gem@asplinux.ru, netdev@oss.sgi.com Subject: Re: automatic keying works! Re: off by one error in 3des cbc keying From: "David S. Miller" In-Reply-To: <20021118195618.GA22603@outpost.ds9a.nl> References: <20021113220311.GA29358@outpost.ds9a.nl> <200211132235.BAA13386@sex.inr.ac.ru> <20021118195618.GA22603@outpost.ds9a.nl> 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: 1206 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: bert hubert Date: Mon, 18 Nov 2002 20:56:19 +0100 I did turn on CONFIG_XFRM_USER, does it conflict with PF_KEY? No. From davem@redhat.com Mon Nov 18 12:11:54 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Nov 2002 12:11:56 -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 gAIKBsuR026630 for ; Mon, 18 Nov 2002 12:11:54 -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 MAA25907; Mon, 18 Nov 2002 12:10:48 -0800 Date: Mon, 18 Nov 2002 12:10:47 -0800 (PST) Message-Id: <20021118.121047.99725598.davem@redhat.com> To: kuznet@ms2.inr.ac.ru Cc: ahu@ds9a.nl, gem@asplinux.ru, netdev@oss.sgi.com Subject: Re: automatic keying works! Re: off by one error in 3des cbc keying From: "David S. Miller" In-Reply-To: <200211182004.XAA12908@sex.inr.ac.ru> References: <20021118195618.GA22603@outpost.ds9a.nl> <200211182004.XAA12908@sex.inr.ac.ru> 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: 1207 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: kuznet@ms2.inr.ac.ru Date: Mon, 18 Nov 2002 23:04:47 +0300 (MSK) > I did turn on CONFIG_XFRM_USER, does it conflict with PF_KEY? Yes, their interaction is still... mmm... not polished. Build both xfrm_user and af_key as modules and load only one for now. You added xfrm netlink support to libipsec? If not, the only thing which should get in the way is that there are two key managers registered but that should "just work" :) From kuznet@ms2.inr.ac.ru Mon Nov 18 12:19:56 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Nov 2002 12:19: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 gAIKJtuR027045 for ; Mon, 18 Nov 2002 12:19:55 -0800 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id XAA22559; Mon, 18 Nov 2002 23:20:13 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200211182020.XAA22559@sex.inr.ac.ru> Subject: Re: automatic keying works! Re: off by one error in 3des cbc keying To: davem@redhat.com (David S. Miller) Date: Mon, 18 Nov 2002 23:20:13 +0300 (MSK) Cc: ahu@ds9a.nl, gem@asplinux.ru, netdev@oss.sgi.com In-Reply-To: <20021118.121047.99725598.davem@redhat.com> from "David S. Miller" at Nov 18, 2 12:10:47 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 1208 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 not, the only thing which should get in the way is that there > are two key managers registered but that should "just work" :) At the moment km_acquire stops after the first manager accepts the acquisition. Both of them always accept, so that guy how stands first in the list, wins, another sees nothing. Alexey From davem@redhat.com Mon Nov 18 12:24:12 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Nov 2002 12:24:15 -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 gAIKOCuR027433 for ; Mon, 18 Nov 2002 12:24:12 -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 MAA25980; Mon, 18 Nov 2002 12:23:07 -0800 Date: Mon, 18 Nov 2002 12:23:07 -0800 (PST) Message-Id: <20021118.122307.31019623.davem@redhat.com> To: kuznet@ms2.inr.ac.ru Cc: ahu@ds9a.nl, gem@asplinux.ru, netdev@oss.sgi.com Subject: Re: automatic keying works! Re: off by one error in 3des cbc keying From: "David S. Miller" In-Reply-To: <200211182020.XAA22559@sex.inr.ac.ru> References: <20021118.121047.99725598.davem@redhat.com> <200211182020.XAA22559@sex.inr.ac.ru> 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: 1209 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: kuznet@ms2.inr.ac.ru Date: Mon, 18 Nov 2002 23:20:13 +0300 (MSK) At the moment km_acquire stops after the first manager accepts the acquisition. Both of them always accept, so that guy how stands first in the list, wins, another sees nothing. Crap, indeed. It should just keep sending to all key managers, right? From kuznet@ms2.inr.ac.ru Mon Nov 18 12:31:49 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Nov 2002 12:31: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 gAIKVmuR027861 for ; Mon, 18 Nov 2002 12:31:48 -0800 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id XAA22666; Mon, 18 Nov 2002 23:32:12 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200211182032.XAA22666@sex.inr.ac.ru> Subject: Re: automatic keying works! Re: off by one error in 3des cbc keying To: davem@redhat.com (David S. Miller) Date: Mon, 18 Nov 2002 23:32:12 +0300 (MSK) Cc: ahu@ds9a.nl, gem@asplinux.ru, netdev@oss.sgi.com In-Reply-To: <20021118.122307.31019623.davem@redhat.com> from "David S. Miller" at Nov 18, 2 12:23:07 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 1210 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! > It should just keep sending to all key managers, right? Just now no choice. I repaired af_key to return error when nobody is registered to get acquires. (the patch is enclosed. NOT TESTED!) If you can do the same with xfrm_user, we can be more clever. Bert, could you help woth testing? The patch adds timeing out policies. To test this it is necessary to configure racoon on one end as "passive", in this case it should update policy on demand and delete them in time. Alexey ===== include/net/xfrm.h 1.9 vs edited ===== --- 1.9/include/net/xfrm.h Thu Nov 14 20:30:23 2002 +++ edited/include/net/xfrm.h Sat Nov 16 12:29:57 2002 @@ -195,6 +195,7 @@ /* This lock only affects elements except for entry. */ rwlock_t lock; atomic_t refcnt; + struct timer_list timer; u32 priority; u32 index; ===== net/netsyms.c 1.37 vs edited ===== --- 1.37/net/netsyms.c Mon Nov 11 12:03:55 2002 +++ edited/net/netsyms.c Sat Nov 16 10:29:42 2002 @@ -283,6 +283,7 @@ EXPORT_SYMBOL(dlci_ioctl_hook); #endif +EXPORT_SYMBOL(km_waitq); EXPORT_SYMBOL(xfrm_cfg_sem); EXPORT_SYMBOL(xfrm_policy_alloc); EXPORT_SYMBOL(__xfrm_policy_destroy); ===== net/ipv4/xfrm_policy.c 1.10 vs edited ===== --- 1.10/net/ipv4/xfrm_policy.c Mon Nov 11 12:03:55 2002 +++ edited/net/ipv4/xfrm_policy.c Sat Nov 16 12:34:33 2002 @@ -204,6 +204,50 @@ __MOD_DEC_USE_COUNT(type->owner); } +static inline unsigned long make_jiffies(long secs) +{ + if (secs >= (MAX_SCHEDULE_TIMEOUT-1)/HZ) + return MAX_SCHEDULE_TIMEOUT-1; + else + return secs*HZ; +} + +static void xfrm_policy_timer(unsigned long data) +{ + struct xfrm_policy *xp = (struct xfrm_policy*)data; + unsigned long now = (unsigned long)xtime.tv_sec; + long next = LONG_MAX; + + if (xp->dead) + goto out; + + if (xp->lft.hard_add_expires_seconds) { + long tmo = xp->lft.hard_add_expires_seconds + + xp->curlft.add_time - now; + if (tmo <= 0) + goto expired; + if (tmo < next) + next = tmo; + } + if (next != LONG_MAX && + !mod_timer(&xp->timer, jiffies + make_jiffies(next))) + atomic_inc(&xp->refcnt); + +out: + xfrm_pol_put(xp); + return; + +expired: + xfrm_pol_put(xp); + + /* Not 100% correct. id can be recycled in theory */ + xp = xfrm_policy_byid(0, xp->index, 1); + if (xp) { + xfrm_policy_kill(xp); + xfrm_pol_put(xp); + } +} + /* Allocate xfrm_policy. Not used here, it is supposed to be used by pfkeyv2 * SPD calls. @@ -219,6 +263,9 @@ memset(policy, 0, sizeof(struct xfrm_policy)); atomic_set(&policy->refcnt, 1); policy->lock = RW_LOCK_UNLOCKED; + init_timer(&policy->timer); + policy->timer.data = (unsigned long)policy; + policy->timer.function = xfrm_policy_timer; } return policy; } @@ -233,6 +280,9 @@ if (policy->bundles) BUG(); + if (del_timer(&policy->timer)) + BUG(); + kfree(policy); } @@ -255,6 +305,9 @@ dst_free(dst); } + if (del_timer(&policy->timer)) + atomic_dec(&policy->refcnt); + out: write_unlock_bh(&policy->lock); } @@ -302,6 +355,9 @@ policy->index = pol ? pol->index : xfrm_gen_index(dir); policy->curlft.add_time = (unsigned long)xtime.tv_sec; policy->curlft.use_time = 0; + if (policy->lft.hard_add_expires_seconds && + !mod_timer(&policy->timer, jiffies + HZ)) + atomic_inc(&policy->refcnt); write_unlock_bh(&xfrm_policy_lock); if (pol) { @@ -380,7 +436,7 @@ int count = 0; int error = 0; - read_lock(&xfrm_policy_lock); + read_lock_bh(&xfrm_policy_lock); for (dir = 0; dir < 2*XFRM_POLICY_MAX; dir++) { for (xp = xfrm_policy_list[dir]; xp; xp = xp->next) count++; @@ -400,7 +456,7 @@ } out: - read_unlock(&xfrm_policy_lock); + read_unlock_bh(&xfrm_policy_lock); return error; } @@ -411,7 +467,7 @@ { struct xfrm_policy *pol; - read_lock(&xfrm_policy_lock); + read_lock_bh(&xfrm_policy_lock); for (pol = xfrm_policy_list[dir]; pol; pol = pol->next) { struct xfrm_selector *sel = &pol->selector; @@ -420,7 +476,7 @@ break; } } - read_unlock(&xfrm_policy_lock); + read_unlock_bh(&xfrm_policy_lock); return pol; } @@ -428,14 +484,14 @@ { struct xfrm_policy *pol; - read_lock(&xfrm_policy_lock); + read_lock_bh(&xfrm_policy_lock); if ((pol = sk->policy[dir]) != NULL) { if (xfrm4_selector_match(&pol->selector, fl)) atomic_inc(&pol->refcnt); else pol = NULL; } - read_unlock(&xfrm_policy_lock); + read_unlock_bh(&xfrm_policy_lock); return pol; } @@ -727,8 +783,7 @@ return 0; } - if (!policy->curlft.use_time) - policy->curlft.use_time = (unsigned long)xtime.tv_sec; + policy->curlft.use_time = (unsigned long)xtime.tv_sec; switch (policy->action) { case XFRM_POLICY_BLOCK: @@ -936,8 +991,7 @@ if (!pol) return 1; - if (!pol->curlft.use_time) - pol->curlft.use_time = (unsigned long)xtime.tv_sec; + pol->curlft.use_time = (unsigned long)xtime.tv_sec; if (pol->action == XFRM_POLICY_ALLOW) { if (pol->xfrm_nr != 0) { ===== net/ipv4/xfrm_state.c 1.7 vs edited ===== --- 1.7/net/ipv4/xfrm_state.c Thu Nov 14 19:52:45 2002 +++ edited/net/ipv4/xfrm_state.c Sat Nov 16 12:34:32 2002 @@ -28,7 +28,7 @@ static void __xfrm_state_delete(struct xfrm_state *x); -unsigned long make_jiffies(long secs) +static inline unsigned long make_jiffies(long secs) { if (secs >= (MAX_SCHEDULE_TIMEOUT-1)/HZ) return MAX_SCHEDULE_TIMEOUT-1; @@ -92,7 +92,14 @@ goto out; expired: - km_expired(x); + if (x->km.state == XFRM_STATE_ACQ && x->id.spi == 0) { + x->km.state = XFRM_STATE_EXPIRED; + wake_up(&km_waitq); + next = 2; + goto resched; + } + if (x->id.spi != 0) + km_expired(x); __xfrm_state_delete(x); out: @@ -298,11 +305,13 @@ 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 : -ENOMEM; + *err = acquire_in_progress ? -EAGAIN : + (error ? -ESRCH : -ENOMEM); return x; } @@ -612,6 +621,7 @@ list_for_each_entry(km, &xfrm_km_list, list) km->notify(x, 1); read_unlock(&xfrm_km_lock); + wake_up(&km_waitq); } int km_query(struct xfrm_state *x, struct xfrm_tmpl *t, struct xfrm_policy *pol) ===== net/key/af_key.c 1.9 vs edited ===== --- 1.9/net/key/af_key.c Thu Nov 14 19:52:45 2002 +++ edited/net/key/af_key.c Sat Nov 16 11:41:37 2002 @@ -196,9 +196,11 @@ return 0; } -static void pfkey_broadcast_one(struct sk_buff *skb, struct sk_buff **skb2, - int allocation, struct sock *sk) +static int pfkey_broadcast_one(struct sk_buff *skb, struct sk_buff **skb2, + int allocation, struct sock *sk) { + int err = -ENOBUFS; + sock_hold(sk); if (*skb2 == NULL) { if (atomic_read(&skb->users) != 1) { @@ -215,9 +217,11 @@ skb_queue_tail(&sk->receive_queue, *skb2); sk->data_ready(sk, (*skb2)->len); *skb2 = NULL; + err = 0; } } sock_put(sk); + return err; } /* Send SKB to all pfkey sockets matching selected criteria. */ @@ -225,21 +229,23 @@ #define BROADCAST_ONE 1 #define BROADCAST_REGISTERED 2 #define BROADCAST_PROMISC_ONLY 4 -static void pfkey_broadcast(struct sk_buff *skb, int allocation, - int broadcast_flags, struct sock *one_sk) +static int pfkey_broadcast(struct sk_buff *skb, int allocation, + int broadcast_flags, struct sock *one_sk) { struct sock *sk; struct sk_buff *skb2 = NULL; + int err = -ESRCH; /* XXX Do we need something like netlink_overrun? I think * XXX PF_KEY socket apps will not mind current behavior. */ if (!skb) - return; + return -ENOMEM; pfkey_lock_table(); for (sk = pfkey_table; sk; sk = sk->next) { struct pfkey_opt *pfk = pfkey_sk(sk); + int err2; /* Yes, it means that if you are meant to receive this * pfkey message you receive it twice as promiscuous @@ -261,16 +267,22 @@ continue; } - pfkey_broadcast_one(skb, &skb2, allocation, sk); + err2 = pfkey_broadcast_one(skb, &skb2, allocation, sk); + + /* Error is cleare after succecful sending to at least one + * registered KM */ + if ((broadcast_flags & BROADCAST_REGISTERED) && err) + err = err2; } pfkey_unlock_table(); if (one_sk != NULL) - pfkey_broadcast_one(skb, &skb2, allocation, one_sk); + err = pfkey_broadcast_one(skb, &skb2, allocation, one_sk); if (skb2) kfree_skb(skb2); kfree_skb(skb); + return err; } static inline void pfkey_hdr_dup(struct sadb_msg *new, struct sadb_msg *orig) @@ -1101,8 +1113,12 @@ if (x == NULL) return 0; - if (x->km.state == XFRM_STATE_ACQ) - xfrm_state_delete(x); + spin_lock_bh(&x->lock); + if (x->km.state == XFRM_STATE_ACQ) { + x->km.state = XFRM_STATE_ERROR; + wake_up(&km_waitq); + } + spin_unlock_bh(&x->lock); xfrm_state_put(x); return 0; } @@ -1783,14 +1799,10 @@ struct sk_buff *out_skb; struct sadb_msg *out_hdr; - if (!ext_hdrs[SADB_X_EXT_POLICY-1]) + if ((pol = ext_hdrs[SADB_X_EXT_POLICY-1]) == NULL) return -EINVAL; - pol = ext_hdrs[SADB_X_EXT_POLICY-1]; - if (!pol->sadb_x_policy_dir || pol->sadb_x_policy_dir >= IPSEC_DIR_MAX) - return -EINVAL; - - xp = xfrm_policy_byid(pol->sadb_x_policy_dir-1, pol->sadb_x_policy_id, + xp = xfrm_policy_byid(0, pol->sadb_x_policy_id, hdr->sadb_msg_type == SADB_X_SPDDELETE2); if (xp == NULL) return -ENOENT; @@ -2142,9 +2154,7 @@ else if (x->id.proto == IPPROTO_ESP) dump_esp_combs(skb, t); - pfkey_broadcast(skb, GFP_ATOMIC, BROADCAST_REGISTERED, NULL); - - return 0; + return pfkey_broadcast(skb, GFP_ATOMIC, BROADCAST_REGISTERED, NULL); } static struct xfrm_policy *pfkey_compile_policy(int opt, u8 *data, int len, int *dir) From ahu@outpost.ds9a.nl Mon Nov 18 12:50:05 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Nov 2002 12:50:07 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAIKnsuR028834 for ; Mon, 18 Nov 2002 12:49:55 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id D4A483FC4; Mon, 18 Nov 2002 21:22:29 +0100 (CET) Date: Mon, 18 Nov 2002 21:22:29 +0100 From: bert hubert To: "David S. Miller" Cc: kuznet@ms2.inr.ac.ru, gem@asplinux.ru, netdev@oss.sgi.com Subject: Re: automatic keying works! Re: off by one error in 3des cbc keying Message-ID: <20021118202229.GA22818@outpost.ds9a.nl> Mail-Followup-To: bert hubert , "David S. Miller" , kuznet@ms2.inr.ac.ru, gem@asplinux.ru, netdev@oss.sgi.com References: <20021118195618.GA22603@outpost.ds9a.nl> <200211182004.XAA12908@sex.inr.ac.ru> <20021118.121047.99725598.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021118.121047.99725598.davem@redhat.com> User-Agent: Mutt/1.3.28i X-archive-position: 1211 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev On Mon, Nov 18, 2002 at 12:10:47PM -0800, David S. Miller wrote: > Yes, their interaction is still... mmm... not polished. I love the way you say this :-) > Build both xfrm_user and af_key as modules and load only one for now. > > You added xfrm netlink support to libipsec? > > If not, the only thing which should get in the way is that there > are two key managers registered but that should "just work" :) It does not, Alexey is right. Without CONFIG_XFRM_USER, racoon works again. Would you perhaps want to explain what CONFIG_XFRM_USER is going to be like? Netlink instead of PFKEY, but other notable things? Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From ahu@outpost.ds9a.nl Mon Nov 18 13:23:16 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Nov 2002 13:23:18 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAILNFuR030444 for ; Mon, 18 Nov 2002 13:23:15 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 04AF444E0; Mon, 18 Nov 2002 22:25:16 +0100 (CET) Date: Mon, 18 Nov 2002 22:25:15 +0100 From: bert hubert To: kuznet@ms2.inr.ac.ru Cc: "David S. Miller" , gem@asplinux.ru, netdev@oss.sgi.com Subject: Re: automatic keying works! Re: off by one error in 3des cbc keying Message-ID: <20021118212515.GB23680@outpost.ds9a.nl> Mail-Followup-To: bert hubert , kuznet@ms2.inr.ac.ru, "David S. Miller" , gem@asplinux.ru, netdev@oss.sgi.com References: <20021118.122307.31019623.davem@redhat.com> <200211182032.XAA22666@sex.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211182032.XAA22666@sex.inr.ac.ru> User-Agent: Mutt/1.3.28i X-archive-position: 1212 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev On Mon, Nov 18, 2002 at 11:32:12PM +0300, kuznet@ms2.inr.ac.ru wrote: > Bert, could you help woth testing? The patch adds timeing out policies. > To test this it is necessary to configure racoon on one end as "passive", > in this case it should update policy on demand and delete them in time. Works. This also needs 'generate_policy on;', by the way. Racoon does not however log if a policy times out. It normally does not because the remote racoon keeps renewing the SA, which also renews the SP. If the remote recoon is STOPped, the passive side nicely times out the SP, although it does not tell the user this. Wonderful stuff, I'm starting to like racoon a bit better. 2002-11-18 22:18:15: INFO: isakmp.c:890:isakmp_ph1begin_r(): respond new phase 1 negotiation: 10.0.0.11[500]<=>10.0.0.216[500] 2002-11-18 22:18:15: INFO: isakmp.c:895:isakmp_ph1begin_r(): begin Aggressive mode. 2002-11-18 22:18:16: INFO: isakmp.c:2417:log_ph1established(): ISAKMP-SA established 10.0.0.11[500]-10.0.0.216[500] spi:d65a99e9df6d6eea:4e21da098172dfda 2002-11-18 22:18:16: INFO: isakmp.c:1045:isakmp_ph2begin_r(): respond new phase 2 negotiation: 10.0.0.11[0]<=>10.0.0.216[0] 2002-11-18 22:18:16: INFO: isakmp_quick.c:2014:get_proposal_r(): no policy found, try to generate the policy : 10.0.0.216/32[0] 10.0.0.11/32[0] proto=any dir=in2002-11-18 22:18:16: INFO: pfkey.c:1106:pk_recvupdate(): IPsec-SA established: ESP/Transport 10.0.0.216->10.0.0.11 spi=230551900(0xdbdf15c) 2002-11-18 22:18:16: INFO: pfkey.c:1318:pk_recvadd(): IPsec-SA established: ESP/Transport 10.0.0.11->10.0.0.216 spi=264801187(0xfc88ba3) 2002-11-18 22:19:52: INFO: pfkey.c:1364:pk_recvexpire(): IPsec-SA expired: ESP/Transport 10.0.0.216->10.0.0.11 spi=230551900(0xdbdf15c) 2002-11-18 22:19:52: INFO: pfkey.c:1364:pk_recvexpire(): IPsec-SA expired: ESP/Transport 10.0.0.11->10.0.0.216 spi=264801187(0xfc88ba3) 2002-11-18 22:19:52: INFO: isakmp.c:1045:isakmp_ph2begin_r(): respond new phase 2 negotiation: 10.0.0.11[0]<=>10.0.0.216[0] 2002-11-18 22:19:52: INFO: isakmp_quick.c:2014:get_proposal_r(): no policy found, try to generate the policy : 10.0.0.216/32[0] 10.0.0.11/32[0] proto=any dir=in2002-11-18 22:19:52: INFO: pfkey.c:1106:pk_recvupdate(): IPsec-SA established: ESP/Transport 10.0.0.216->10.0.0.11 spi=127223206(0x79545a6) 2002-11-18 22:19:52: INFO: pfkey.c:1318:pk_recvadd(): IPsec-SA established: ESP/Transport 10.0.0.11->10.0.0.216 spi=140990312(0x8675768) 2002-11-18 22:20:16: INFO: pfkey.c:1364:pk_recvexpire(): IPsec-SA expired: ESP/Transport 10.0.0.216->10.0.0.11 spi=230551900(0xdbdf15c) 2002-11-18 22:20:16: INFO: pfkey.c:1364:pk_recvexpire(): IPsec-SA expired: ESP/Transport 10.0.0.11->10.0.0.216 spi=264801187(0xfc88ba3) -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From davem@redhat.com Mon Nov 18 15:18:14 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Nov 2002 15:18:19 -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 gAINIEuR001570 for ; Mon, 18 Nov 2002 15:18:14 -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 PAA26641; Mon, 18 Nov 2002 15:17:04 -0800 Date: Mon, 18 Nov 2002 15:17:03 -0800 (PST) Message-Id: <20021118.151703.22349880.davem@redhat.com> To: kuznet@ms2.inr.ac.ru Cc: ahu@ds9a.nl, gem@asplinux.ru, netdev@oss.sgi.com Subject: Re: automatic keying works! Re: off by one error in 3des cbc keying From: "David S. Miller" In-Reply-To: <200211182032.XAA22666@sex.inr.ac.ru> References: <20021118.122307.31019623.davem@redhat.com> <200211182032.XAA22666@sex.inr.ac.ru> 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: 1213 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: kuznet@ms2.inr.ac.ru Date: Mon, 18 Nov 2002 23:32:12 +0300 (MSK) I repaired af_key to return error when nobody is registered to get acquires. (the patch is enclosed. NOT TESTED!) If you can do the same with xfrm_user, we can be more clever. I applied this patch since Bert tested it :-) I will take care of xfrm_user's acquire handling right now. From hadi@cyberus.ca Mon Nov 18 18:17:46 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Nov 2002 18:17:52 -0800 (PST) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAJ2HjuR004377 for ; Mon, 18 Nov 2002 18:17:46 -0800 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id VAA28380; Mon, 18 Nov 2002 21:19:47 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id gAJ2C1b14898; Mon, 18 Nov 2002 21:12:02 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 18 Nov 2002 21:12:01 -0500 (EST) From: jamal To: Donald Becker cc: Subject: Re: ifconfig TX/RX errors In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1214 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 Wed, 13 Nov 2002, Donald Becker wrote: > Are you certain about that Jamal? This is /proc/net/dev numbers > covering the network interface device layer, not the protocol layers, > The numbers Linux 'ifconfig' reports are similar, but not the same as > the very limited counts that the old BSDs used. > Heres output of ifconfig ------------------------------ eth0 Link encap:Ethernet HWaddr 00:02:B3:2B:CD:A4 inet addr:10.0.0.10 Bcast:10.0.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:87445 errors:0 dropped:0 overruns:0 frame:0 TX packets:29162 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:5 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:7137 errors:0 dropped:0 overruns:0 frame:0 TX packets:7137 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 ----------------------------- I start ucd snmpd and walk .1.3.6.1.2.1.2 which is the ifentry section of the interfaces table. ------------- interfaces.ifNumber.0 = 2 interfaces.ifTable.ifEntry.ifIndex.1 = 1 interfaces.ifTable.ifEntry.ifIndex.2 = 2 interfaces.ifTable.ifEntry.ifDescr.1 = lo0 interfaces.ifTable.ifEntry.ifDescr.2 = eth0 interfaces.ifTable.ifEntry.ifType.1 = softwareLoopback(24) interfaces.ifTable.ifEntry.ifType.2 = ethernetCsmacd(6) interfaces.ifTable.ifEntry.ifMtu.1 = 16436 interfaces.ifTable.ifEntry.ifMtu.2 = 1500 interfaces.ifTable.ifEntry.ifSpeed.1 = Gauge: 10000000 interfaces.ifTable.ifEntry.ifSpeed.2 = Gauge: 10000000 interfaces.ifTable.ifEntry.ifPhysAddress.1 = interfaces.ifTable.ifEntry.ifPhysAddress.2 = 0:2:b3:2b:cd:a4 interfaces.ifTable.ifEntry.ifAdminStatus.1 = up(1) interfaces.ifTable.ifEntry.ifAdminStatus.2 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.1 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.2 = up(1) interfaces.ifTable.ifEntry.ifInOctets.1 = 637875 interfaces.ifTable.ifEntry.ifInOctets.2 = 28723267 interfaces.ifTable.ifEntry.ifInUcastPkts.1 = 7176 interfaces.ifTable.ifEntry.ifInUcastPkts.2 = 87445 interfaces.ifTable.ifEntry.ifInErrors.1 = 0 interfaces.ifTable.ifEntry.ifInErrors.2 = 0 interfaces.ifTable.ifEntry.ifOutOctets.1 = 638861 interfaces.ifTable.ifEntry.ifOutOctets.2 = 2506626 interfaces.ifTable.ifEntry.ifOutUcastPkts.1 = 7188 interfaces.ifTable.ifEntry.ifOutUcastPkts.2 = 29162 interfaces.ifTable.ifEntry.ifOutDiscards.1 = 0 interfaces.ifTable.ifEntry.ifOutDiscards.2 = 0 interfaces.ifTable.ifEntry.ifOutErrors.1 = 0 interfaces.ifTable.ifEntry.ifOutErrors.2 = 0 interfaces.ifTable.ifEntry.ifOutQLen.1 = Gauge: 0 interfaces.ifTable.ifEntry.ifOutQLen.2 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpecific.1 = OID: .ccitt.nullOID interfaces.ifTable.ifEntry.ifSpecific.2 = OID: .ccitt.nullOID --------------------- Although i dont have the ifOutErrors for example with any values, my observation is they match the ifconfig or netstat or ip outputs. Cross referencing with the RFC seems to match the semantics as well. Actually i believe ucd snmp reads the proc/net/dev output but i havent looked at the code. So maybe when you added those entries back then they were already being used for snmp by the BSDs? > When I wrote the /proc/net/dev statistics count output, I unwisely > summarized some of the independent fields the drivers recorded to fit > into an 79 column output(1). I should have output all of the > statistics, and let user-level programs summarize as they saw fit. > Even today there is no way to get out the individual numbers. > if you dont care about readability, probably a hex output would go a long way. eg /proc/net/softnet_stat does this to fit things > (1) That effort at human readability was discarded when new fields > were added, making the output incompatible with earlier versions of > ifconfig. So now the output is longer than a line, but it still > doesn't break out the important error counts. I am not well versed with the history; are there any stats that you would like to see that are missing? cheers, jamal From hadi@cyberus.ca Mon Nov 18 18:28:33 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Nov 2002 18:28:35 -0800 (PST) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAJ2SXuR004806 for ; Mon, 18 Nov 2002 18:28:33 -0800 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id VAA01798; Mon, 18 Nov 2002 21:30:34 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id gAJ2MnO14953; Mon, 18 Nov 2002 21:22:49 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 18 Nov 2002 21:22:48 -0500 (EST) From: jamal To: Thomas Graf cc: Subject: Re: leak in netlink_dump()? In-Reply-To: <20021113195334.GM27787@reeler.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1215 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 Wed, 13 Nov 2002, Thomas Graf wrote: > Hello! > > Used Kernel: 2.4.18 (same for 2.4.19pre6) > > I think I've found a memory leak in netlink_dump (af_netlink.c): > > the netlink callback (sk->protinfo.af_netlink->cb) is allocated > in the calling funtion netlink_dump_start and is not freed > after the call to netlink_dump. > It shouldnt be. The callback is only destroyed when the dump is complete i.e nothing to dump anymore (skb->len == 0) > From my point of view, this is a memory leak, but I'm new to > kernel code and I might be telling shit. Look carefully at places where netlink_dump is being invoked from and youll get it. cheers, jamal From hadi@cyberus.ca Mon Nov 18 18:37:01 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Nov 2002 18:37:02 -0800 (PST) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAJ2b0uR005222 for ; Mon, 18 Nov 2002 18:37:00 -0800 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id VAA04368; Mon, 18 Nov 2002 21:39:02 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id gAJ2VHM14979; Mon, 18 Nov 2002 21:31:18 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 18 Nov 2002 21:31:17 -0500 (EST) From: jamal To: Andi Kleen cc: Donald Becker , Michael Richardson , Subject: Re: looking for help with scanning of IPv6 interfaces In-Reply-To: <20021115235200.B8265@wotan.suse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1216 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 You forgot the draft, Andi. Although doesnt document every little detail (someone should) -- it goes a long way to describe the architecture and concepts behind netlink. A not final version: ftp://oa.znyx.com/pub/jamal/draft-ietf-forces-netlink-04.txt cheers, jamal On Fri, 15 Nov 2002, Andi Kleen wrote: > > > Physical devices are read using /proc/net/dev > > ... > > > That is the old fashioned way. > > > > > > The new fashioned one is to query them using rtnetlink. You use a RTM_GETADDR > > > NLM_F_REQUEST query with wildcard (NLM_F_ROOT) to get a full list. > > > See the netlink,rtnetlink, libnetlink manpages and iproute2 as an example. > > > It is easier when you use libnetlink. > > > > Do you have a snippet of code? > > Check iproute2 or zebra source. iproute2 has a libnetlink which is quite useful. > > I also wrote some manpages (netlink(3),netlink(7),rtnetlink(7) etc, but > admittedly they are not very good) > > > What kernel version does this start working? > > Somewhere in Linux 2.1. > > > > Of course for code that needs to work with already deployed systems, you > > need to have code for the old method around anyway... > > Only when you still want to support 2.0. Ok some people do not enable > netlink in their kernel configuration, but many modern distributions > require it for booting now (because the network init scripts use iproute2), > so this shouldn't be a big issue anymore. > > -Andi > > From hadi@cyberus.ca Mon Nov 18 18:49:34 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Nov 2002 18:49:36 -0800 (PST) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAJ2nXuR005655 for ; Mon, 18 Nov 2002 18:49:34 -0800 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id VAA08215; Mon, 18 Nov 2002 21:51:27 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id gAJ2hgl15107; Mon, 18 Nov 2002 21:43:43 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 18 Nov 2002 21:43:27 -0500 (EST) From: jamal To: Taekeun Lee cc: Subject: Re: Question.. Traffic Shaping in Linux In-Reply-To: <000001c28edf$d2634ed0$0105a8c0@tedlee> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1217 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 If i understood you correctly, you already have the router working with RSVP Daemon, RSVP control packets configuring CBQ mechanism.. Is this correct? So why cant you use other qdiscs using the same mechanism? What interface are you using right now to setup things? I take ut you are using the RSVP* classifiers as well? cheers, jamal On Mon, 18 Nov 2002, Taekeun Lee wrote: > Hello, My name is Taekeun Lee.. > > I'm a graduate student in Sungkyunkwan Univ. in Korea.. > > This e-mail address(netdev@oss.sgi.com) is introduced by Alan Cox.. > > My Question is Traffic shaping in linux.. > > Existed traffic shaper in Linux kernel module is possible low bandwidth > limitation.. ( < 1Mbps ) > > And, High bandwidth limitation can use CBQ kernel facilities.. > > But, My router is working with RSVP Daemon, RSVP Daemon controls packets > by CBQ mechanism.. > > So, I can't use CBQ facility for traffic shaping.. > > > > I want to traffic shaping in Linux without CBQ mechanism.. > > > > Can U suggest a solution to this problem? > > > > I'm sorry, my poor english.. > > > > [[HTML alternate version deleted]] > > From dmail2222jp@yahoo.co.jp Tue Nov 19 08:39:42 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Nov 2002 08:39:48 -0800 (PST) Received: from yoohoo (pl1196.nas927.o-tokyo.nttpc.ne.jp [61.197.110.172]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAJGdfuR019010 for ; Tue, 19 Nov 2002 08:39:42 -0800 Received: from ws1ifxrj2z4yhav ([192.168.0.2]) by yoohoo (8.9.3+3.2W/3.7W) with SMTP id UAA29543; Tue, 19 Nov 2002 20:48:02 +0900 Message-Id: <200211191148.UAA29543@yoohoo> From: =?iso-2022-jp?B?ZG1haWwyMjIyanA=?= To: =?iso-2022-jp?B?MDE5?=@yoohoo.sgi.com Reply-To: dmail2222jp@yahoo.co.jp Date: Tue, 19 Nov 2002 20:46:18 +0900 Subject: =?iso-2022-jp?B?GyRCTCQ+NUJ6OS05cCIoRUU7UiVhITwlazktOXAbKEo=?= Content-Type: text/plain MIME-Version: 1.0 X-MIME-Autoconverted: from 8bit to base64 by yoohoo id UAA29543 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id gAJGdfuR019010 X-archive-position: 1218 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dmail2222jp@yahoo.co.jp Precedence: bulk X-list: netdev <‘—MŽÒ> “dŽqƒ[ƒ‹LŽÐ ¡ŒãAL‚ð‚²Šó–]‚µ‚È‚¢•û‚Í‚±‚±‚Ö (•K‚¸–{•¶‚É‚ ‚È‚½‚̃[ƒ‹ƒAƒhƒŒƒX‚Ì‚Ý‚ð‚¨‘‚«‰º‚³‚¢j fmail3333jp@yahoo.co.jp ƒ[ƒ‹ƒAƒhƒŒƒX‚ð‚²‹L“ü‚µ‚Ä‚­‚¾‚³‚¢B §104-0061 “Œ‹ž“s’†‰›‹æ‹âÀ8-19-3 ‘æ2ƒEƒCƒ“ƒOƒrƒ‹@3F ƒ[ƒ‹ƒ}ƒKƒWƒ“”­s TEL@03-3544-6222 FAX@03-3544-6218 =============================================================== –â‘褕i‚΂©‚èW‚ß‚Ü‚µ‚½‚Ì‚ÅAÁ‚³‚ê‚é‹°‚ꂪ‚ ‚è‚Ü‚·‚Ì‚Å ‚¨\ž‚Ý‚Í‚¨‘‚ß‚ÉI ================================================================= ™\\\™\\\™\\\™\\\™\\\™\\\™\\\™\\\™ — ƒrƒfƒI”Ì”„E“ÁŽêƒ_ƒbƒ`ƒƒCƒtE‚r‚lƒNƒ‰ƒu @@ ‚`‚u’j—D•åWE‰‡•ŒðÛE‚r‚d‚wƒtƒŒƒ“ƒhEƒAƒ_ƒ‹ƒgƒOƒbƒY‚È‚Ç š@ƒAƒ_ƒ‹ƒgŠÖ˜A‚Ìî•ñ–žÚ@š @@‚¨\ž‚ÝE‚²’•¶E¤•iÚד™‚Í@ @@@@@‰º‹L‚t‚q‚k‚ðƒNƒŠƒbƒN‚µ‚Ä‚²——‰º‚³‚¢B «@@@@«@@@@«@ @@@http://www.ss-koukoku.com/ ™\\\™\\\™\\\™\\\™\\\™\\\™\\\™\\\™ @@@@@@@@ŠJ‰^ƒOƒbƒYE‹É”éî•ñŽ @@@@–h”ƃOƒbƒYE‹à–ׂ¯î•ñEƒ_ƒCƒGƒbƒgH•i‚È‚Ç@ @@@@@@@@š@‚»‚Ì‘¼î•ñ–žÚ@š @@‚¨\ž‚ÝE‚²’•¶E¤•iÚד™‚Í@ @@@@@‰º‹L‚t‚q‚k‚ðƒNƒŠƒbƒN‚µ‚Ä‚²——‰º‚³‚¢B «@@@@«@@@@«@ http://neturl.nu/koukoku/ «@@@@«@@@@«@ http://urlto.net/koukoku/ «@@@@«@@@@«@ http://book-i.net/koukoku/ «@@@@«@@@@«@ http://koukoku.19zo.net «@@@@«@@@@« http://beam.to/koukoku ™\\\™\\\™\\\™\\\™\\\™\\\™\\\™\\\™ From seong@etri.re.kr Tue Nov 19 18:46:12 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Nov 2002 18:46:17 -0800 (PST) Received: from cms1.etri.re.kr ([129.254.16.11]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAK2kBuR027373 for ; Tue, 19 Nov 2002 18:46:12 -0800 Received: from seong (seong1.etri.re.kr [129.254.171.33]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VZPTKC5R; Wed, 20 Nov 2002 11:38:08 +0900 Message-ID: <005201c2903f$37e88580$21abfe81@seong> From: "Seong Moon" To: Subject: dev->hard_header ? Date: Wed, 20 Nov 2002 11:46:20 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-archive-position: 1219 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: seong@etri.re.kr Precedence: bulk X-list: netdev In Layer 3 Protocols(eg. IP, IPv6, ...), they calls dev_queue_xmit() to send their data. Before calling dev_queue_xmit(), does the layer 3 protocols always call dev->hard_header ? Actually, I'm not sure when dev->hard_header is called. I think dev->hard_start_xmit can include the part of dev->hard_header. Why did the developer seperate the header building and sending frame fucntion ? thanks in advance. From greearb@candelatech.com Tue Nov 19 21:04:01 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Nov 2002 21:04:06 -0800 (PST) Received: from grok.yi.org (IDENT:4eCnTCAQ4rEM29ytu0YphiDO1mFq6ywg@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAK540uR029365 for ; Tue, 19 Nov 2002 21:04:00 -0800 Received: from candelatech.com (IDENT:TDf8Q0/o/TXIg7/KBFTAvxk3KhQu6F9s@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id gAK561524816; Tue, 19 Nov 2002 21:06:01 -0800 Message-ID: <3DDB1839.4020909@candelatech.com> Date: Tue, 19 Nov 2002 21:06:01 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Seong Moon CC: netdev@oss.sgi.com Subject: Re: dev->hard_header ? References: <005201c2903f$37e88580$21abfe81@seong> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1220 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 Seong Moon wrote: > In Layer 3 Protocols(eg. IP, IPv6, ...), > they calls dev_queue_xmit() to send their data. > > Before calling dev_queue_xmit(), > does the layer 3 protocols always call dev->hard_header ? > > Actually, I'm not sure when dev->hard_header is called. > > I think dev->hard_start_xmit can include the part of dev->hard_header. > Why did the developer seperate the header building and sending frame > fucntion ? It's not always called, this way user-space (or other parts of the kernel) can build the headers if desired. This at least works for ethernet and VLAN interfaces. Ben > > thanks in advance. > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From bahareh@itc.ir Wed Nov 20 00:32:54 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Nov 2002 00:32:59 -0800 (PST) Received: from mail.itc.ir (IDENT:root@[195.146.59.32]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAK8WnuR032464 for ; Wed, 20 Nov 2002 00:32:51 -0800 Received: from bahareh ([195.146.59.36]) by mail.itc.ir (8.9.3/8.8.7) with ESMTP id MAA25033 for ; Wed, 20 Nov 2002 12:00:35 +0330 From: "bahareh" To: Subject: problem with source compiling Date: Wed, 20 Nov 2002 12:06:52 +0330 Message-ID: <000501c2906f$f99b7680$243b92c3@bahar.itc> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 527 X-archive-position: 1221 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bahareh@itc.ir Precedence: bulk X-list: netdev hi every body i run linux on sparc platform and i use redhat6.2 for that . i now this is very old version i can not find any new rpms for sparc and i have to compile sourses i did it but i had a new problem new sourser need to gcc pakege to compiling and i tried to install gcc packages but i can not install non of gcc packeges(old version and new version) (i must tell taht i upgrated new kernel and rpm3 to rpm4 ) i will be happy if you help me for this thanks a lot. b .abedini [[HTML alternate version deleted]] From billcu@citynet.net Wed Nov 20 07:30:32 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Nov 2002 07:30:36 -0800 (PST) Received: from tx2.wvinternetservices.com (tx2.wvinternetservices.com [66.118.65.7]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAKFUWuR009494 for ; Wed, 20 Nov 2002 07:30:32 -0800 Received: from a (63-144-68-117.citynet.net [63.144.68.117]) by tx2.wvinternetservices.com (8.12.6/8.12.6=Outbound) with SMTP id gAKFU1Gf014497 for ; Wed, 20 Nov 2002 10:30:02 -0500 Message-ID: <001701c290a9$cd049ea0$7544903f@a> From: "Bill Cunningham" To: Subject: kern mod versioning Date: Wed, 20 Nov 2002 10:30:47 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-archive-position: 1222 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: billcu@citynet.net Precedence: bulk X-list: netdev I've been trying to learn how to build modules, Modules I guess being drivers and I can't get around the kern versioning. I know I can compile it out of the kernel but isn't there a simpler way around it, like disabling it in the module source? BTW I use kern 2.2 From cmail8888jp@yahoo.co.jp Wed Nov 20 13:58:00 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Nov 2002 13:58:05 -0800 (PST) Received: from pool (tky95-f219.alpha-net.ne.jp [210.229.95.219]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAKLuxuR021106 for ; Wed, 20 Nov 2002 13:57:49 -0800 Received: from D ([192.168.0.2]) by pool (8.9.3+3.2W/3.7W) with SMTP id GAA13786; Thu, 21 Nov 2002 06:59:35 +0900 Message-Id: <200211202159.GAA13786@pool> From: =?iso-2022-jp?B?ZG1haWw4ODg4anA=?= To: =?iso-2022-jp?B?MDAwMw==?=@pool.sgi.com Reply-To: cmail8888jp@yahoo.co.jp Date: Thu, 21 Nov 2002 06:57:11 +0900 Subject: =?iso-2022-jp?B?GyRCTCQ+NUJ6OS05cCIoRUU7UiVhITwlazktOXAbKEo=?= Content-Type: text/plain Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-archive-position: 1223 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cmail8888jp@yahoo.co.jp Precedence: bulk X-list: netdev <‘—MŽÒ> “dŽqƒ[ƒ‹LŽÐ ¡ŒãAL‚ð‚²Šó–]‚µ‚È‚¢•û‚Í‚±‚±‚Ö (•K‚¸–{•¶‚É‚ ‚È‚½‚̃[ƒ‹ƒAƒhƒŒƒX‚Ì‚Ý‚ð‚¨‘‚«‰º‚³‚¢j fmail3333jp@yahoo.co.jp ƒ[ƒ‹ƒAƒhƒŒƒX‚ð‚²‹L“ü‚µ‚Ä‚­‚¾‚³‚¢B §104-0061 “Œ‹ž“s’†‰›‹æ‹âÀ8-19-3 ‘æ2ƒEƒCƒ“ƒOƒrƒ‹@3F ƒ[ƒ‹ƒ}ƒKƒWƒ“”­s TEL@03-3544-6222 FAX@03-3544-6218 =============================================================== –â‘褕i‚΂©‚èW‚ß‚Ü‚µ‚½‚Ì‚ÅAÁ‚³‚ê‚é‹°‚ꂪ‚ ‚è‚Ü‚·‚Ì‚Å ‚¨\ž‚Ý‚Í‚¨‘‚ß‚ÉI ================================================================= ™\\\™\\\™\\\™\\\™\\\™\\\™\\\™\\\™ — ƒrƒfƒI”Ì”„E“ÁŽêƒ_ƒbƒ`ƒƒCƒtE‚r‚lƒNƒ‰ƒu @@ ‚`‚u’j—D•åWE‰‡•ŒðÛE‚r‚d‚wƒtƒŒƒ“ƒhEƒAƒ_ƒ‹ƒgƒOƒbƒY‚È‚Ç š@ƒAƒ_ƒ‹ƒgŠÖ˜A‚Ìî•ñ–žÚ@š @@‚¨\ž‚ÝE‚²’•¶E¤•iÚד™‚Í@ @@@@@‰º‹L‚t‚q‚k‚ðƒNƒŠƒbƒN‚µ‚Ä‚²——‰º‚³‚¢B «@@@@«@@@@«@ @@@http://www.ss-koukoku.com/ ™\\\™\\\™\\\™\\\™\\\™\\\™\\\™\\\™ @@@@@@@@ŠJ‰^ƒOƒbƒYE‹É”éî•ñŽ @@@@–h”ƃOƒbƒYE‹à–ׂ¯î•ñEƒ_ƒCƒGƒbƒgH•i‚È‚Ç@ @@@@@@@@š@‚»‚Ì‘¼î•ñ–žÚ@š @@‚¨\ž‚ÝE‚²’•¶E¤•iÚד™‚Í@ @@@@@‰º‹L‚t‚q‚k‚ðƒNƒŠƒbƒN‚µ‚Ä‚²——‰º‚³‚¢B «@@@@«@@@@«@ http://neturl.nu/koukoku/ «@@@@«@@@@«@ http://urlto.net/koukoku/ «@@@@«@@@@«@ http://book-i.net/koukoku/ «@@@@«@@@@«@ http://koukoku.19zo.net «@@@@«@@@@« http://beam.to/koukoku ™\\\™\\\™\\\™\\\™\\\™\\\™\\\™\\\™ From jabiru_croc@yahoo.com Wed Nov 20 14:54:13 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Nov 2002 14:54:17 -0800 (PST) Received: from web40003.mail.yahoo.com (web40003.mail.yahoo.com [66.218.78.21]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAKMsDuR022799 for ; Wed, 20 Nov 2002 14:54:13 -0800 Message-ID: <20021120225618.28279.qmail@web40003.mail.yahoo.com> Received: from [24.50.169.37] by web40003.mail.yahoo.com via HTTP; Wed, 20 Nov 2002 14:56:18 PST Date: Wed, 20 Nov 2002 14:56:18 -0800 (PST) From: Brad Chapman Subject: Re: kern mod versioning To: Bill Cunningham Cc: netdev@oss.sgi.com In-Reply-To: <001701c290a9$cd049ea0$7544903f@a> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1224 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jabiru_croc@yahoo.com Precedence: bulk X-list: netdev --- Bill Cunningham wrote: > I've been trying to learn how to build modules, Modules I guess being > drivers and I can't get around the kern versioning. I know I can compile it > out of the kernel but isn't there a simpler way around it, like disabling it > in the module source? BTW I use kern 2.2 > CONFIG_MODVERSIONS=n Then run make mrproper after saving your .config and proceed from there. Brad __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com From yoshfuji@linux-ipv6.org Wed Nov 20 22:31:36 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Nov 2002 22:31:38 -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 gAL6VWuR027365 for ; Wed, 20 Nov 2002 22:31:35 -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 gAL6W3GR018264; Thu, 21 Nov 2002 15:32:03 +0900 Date: Thu, 21 Nov 2002 01:32:03 -0500 (EST) Message-Id: <20021121.013203.100868154.yoshfuji@linux-ipv6.org> To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com CC: davem@redhat.com, kuznet@ms2.inr.ac.ru.ee.t.u-tokyo.ac.jp, usagi@linux-ipv6.org Subject: [PATCH] IPv6: Fix BUG When Received Unknown Protocol Organization: USAGI Project Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= 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) Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1225 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 Hi, Since 2.5.43, kernel panics by executing BUG() when received unknown protocol in IPv6 packet. This is because ip6_input_finish() try to kfree_skb() while icmpv6_param_prob() has already kfree_skb()'ed the skb. Thanks. Patch-Name: Fix BUG When Received Unknown Protocol Patch-Author: YOSHIFUJI Hideaki / USAGI Project Index: net/ipv6/ip6_input.c =================================================================== RCS file: /cvsroot/usagi/usagi/kernel/linux25/net/ipv6/ip6_input.c,v retrieving revision 1.1.1.3 retrieving revision 1.2 diff -u -r1.1.1.3 -r1.2 --- net/ipv6/ip6_input.c 31 Oct 2002 03:58:27 -0000 1.1.1.3 +++ net/ipv6/ip6_input.c 21 Nov 2002 05:30:59 -0000 1.2 @@ -182,9 +182,10 @@ if (!raw_sk) { IP6_INC_STATS_BH(Ip6InUnknownProtos); icmpv6_param_prob(skb, ICMPV6_UNK_NEXTHDR, nhoff); - } else + } else { IP6_INC_STATS_BH(Ip6InDelivers); - kfree_skb(skb); + kfree_skb(skb); + } } return 0; -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From Robert.Olsson@data.slu.se Thu Nov 21 04:30:30 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Nov 2002 04:30:34 -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 gALCUSuR001366 for ; Thu, 21 Nov 2002 04:30:29 -0800 Received: (from robert@localhost) by robur.slu.se (8.9.3/8.9.3) id NAA01941; Thu, 21 Nov 2002 13:40:34 +0100 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15836.54338.135589.998015@robur.slu.se> Date: Thu, 21 Nov 2002 13:40:34 +0100 To: netdev@oss.sgi.com Cc: Robert.Olsson@data.slu.se Subject: I/O operations X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 1226 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 While hacking with e1000... For e1000 reading the interrupt control (ICR) register also acks it. I guess the idea is to save I/O operations which are very slow in comparison to CPU speed. So reading and acking is done atomically in just one operation. And it should be possible to extend this to even disable interrupts (if ICR nonzero) in the same operation? At least for NAPI "type" drivers this seems useful... 1) H/W generates interrupt which "indicates" work. 2) Driver Reads/Acks/Disables-IRQ in one I/O operation and schedules work for softirq. Any chips capable of this already? Cheers. --ro From ODAFENG1@REDIFFMAIL.COM Thu Nov 21 07:10:14 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Nov 2002 07:10:17 -0800 (PST) Received: from REDIFFMAIL.COM (80-247-136-29.reverse.newskies.net [80.247.136.29]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gALFA7uR004509 for ; Thu, 21 Nov 2002 07:10:12 -0800 Message-Id: <200211211510.gALFA7uR004509@oss.sgi.com> From: "DR JOEL ODILI" To: Subject: APPEAL FOR URGENT ASSISTANCE/INVESTMENT Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Date: Thu, 21 Nov 2002 07:12:26 -0800 Reply-To: "DR JOEL ODILI" X-archive-position: 1227 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ODAFENG1@REDIFFMAIL.COM Precedence: bulk X-list: netdev URGENT BUSINESS PROPOSAL This letter may come to you as a surprise since it is coming from someone you have not met before. However, we decided to contact you based on satisfactory information we had about your businessperson as regard business information concerning your country and the safety of our funds in a steady economy such as that of your country compared to our country Nigeria Africa. I am a civil adviser currently working with the monitoring committee overseeing the winding up of the petroleum trust fund (PTF).Myself and my close and trusted colleagues need your assistance in the transfer of US$35 million into any reliable Account you may nominate overseas. This fund was generated from over-invoicing of contracts executed by the PTF under the administration of the past military government. These were discovered while we were reviewing the PTF accounts. From our discoveries, these contracts have been executed and the contractors in question were all paid. The difference of US$35,000,000 being the over-invoiced amount is the funds, we want your corporate entity to help us receive. What we want from you is a good and reliable company or personal Account into which we shall transfer this fund. Details should include the following: 1. Name of Bank 2. Address of Bank with Fax & Tel. No. 3. Account Number 4. Beneficiary/Signatory to Account (Account Name) Upon the Successful crediting of your Account.The fund will be shared as follows: 1. 20% for you and your assistance 2. 75% for myself & my Colleagues 3. 5% for contingency expenses Please after your first reply through e-mail,I will want us to continue further communication by fax and telephone for confidential purpose. We wish to assure you that your involvement should you decide to assist us, will be well protected, and also, this business, proposal is 100% risk free as we have put a whole lot into it. Thank you for your anticipated cooperation while we look forward to a mutually benefiting business relationship with you. Please when replying to my e-mail kindly include your telephone, fax number and mobile telephone numbers preferably extremely private numbers where we can reach you any time of the day. Please be aware that a high level of confidentiality and trust is required in this business. Best Regards, Dr GREG ADAMS From davem@redhat.com Thu Nov 21 21:57:19 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Nov 2002 21:57:23 -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 gAM5vIuR021387 for ; Thu, 21 Nov 2002 21:57:18 -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 VAA10366; Thu, 21 Nov 2002 21:56:28 -0800 Date: Thu, 21 Nov 2002 21:56:28 -0800 (PST) Message-Id: <20021121.215628.133829160.davem@redhat.com> To: yoshfuji@linux-ipv6.org Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru.ee.t.u-tokyo.ac.jp, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix BUG When Received Unknown Protocol From: "David S. Miller" In-Reply-To: <20021121.013203.100868154.yoshfuji@linux-ipv6.org> References: <20021121.013203.100868154.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=iso-2022-jp Content-Transfer-Encoding: 7bit X-archive-position: 1228 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: YOSHIFUJI Hideaki / $B5HF#1QL@(B Date: Thu, 21 Nov 2002 01:32:03 -0500 (EST) Since 2.5.43, kernel panics by executing BUG() when received unknown protocol in IPv6 packet. This is because ip6_input_finish() try to kfree_skb() while icmpv6_param_prob() has already kfree_skb()'ed the skb. Patch applied, thanks. From davem@redhat.com Fri Nov 22 19:51:53 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Nov 2002 19:51:55 -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 gAN3pquR017354 for ; Fri, 22 Nov 2002 19:51: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 MAA25968; Mon, 18 Nov 2002 12:22:42 -0800 Date: Mon, 18 Nov 2002 12:22:41 -0800 (PST) Message-Id: <20021118.122241.93782164.davem@redhat.com> To: ahu@ds9a.nl Cc: kuznet@ms2.inr.ac.ru, gem@asplinux.ru, netdev@oss.sgi.com Subject: Re: automatic keying works! Re: off by one error in 3des cbc keying From: "David S. Miller" In-Reply-To: <20021118202229.GA22818@outpost.ds9a.nl> References: <200211182004.XAA12908@sex.inr.ac.ru> <20021118.121047.99725598.davem@redhat.com> <20021118202229.GA22818@outpost.ds9a.nl> 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: 1229 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: bert hubert Date: Mon, 18 Nov 2002 21:22:29 +0100 Would you perhaps want to explain what CONFIG_XFRM_USER is going to be like? Netlink instead of PFKEY, but other notable things? What you see in the code is what it will be like :-) The only really mentionable thing is that when we notice that PFKEY side has shit semantics, we will make netlink side saner :) The only immediate difference is that with table dump operations netlink queues where PFKEY does not. From sales@rosscomputermaintenance.com Sat Nov 23 20:22:33 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Nov 2002 20:22:36 -0800 (PST) Received: from email.wickedlyfast.net ([208.31.0.26]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAO4MRuR005366 for ; Sat, 23 Nov 2002 20:22:27 -0800 Received: from ROSS [68.34.144.102] by email.wickedlyfast.net (SMTPD32-7.05) id AC425C80242; Sat, 23 Nov 2002 21:41:06 -0500 Message-ID: <009e01c29363$9c1bace0$66902244@ROSS> Reply-To: "David Ross" From: "David Ross" To: "David Ross" Subject: Please support your local Lee's Summit businesses Date: Sat, 23 Nov 2002 20:41:35 -0600 Organization: Ross Computer Maintenance MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0098_01C29330.B7655560" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-archive-position: 1230 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sales@rosscomputermaintenance.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. ------=_NextPart_000_0098_01C29330.B7655560 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0099_01C29330.B7655560" ------=_NextPart_001_0099_01C29330.B7655560 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable It is the intention of this series of e-mails to introduce you to = the small businesses of Lee's Summit. Each week three or four Lee=92s = Summit businesses will be showcased. This week we are featuring VIP = Baskets, The Auto Clinic, and Ross Computer Maintenance. Please feel = free to contact any of these businesses directly or by replying to this = e-mail. Thank you! =20 David Ross 816-694-6628 =20 =20 VIP Baskets =20 Giving gifts increases your opportunity for repeat business = and helps build long term relationships. Sending VIP Gift Baskets this = holiday season and for special occasions year round will show your = customers how much you appreciate them. Our impressive surprise packages = are full of great tasting goodies that will make them remember you long = after the last bite has been enjoyed. Shopping has never been so easy! = We deliver, ship and take MasterCard and VISA. Call Jewel Dyer at VIP = Baskets (816)525-4695.=20 =20 -------------------------------------------------------------------------= -------------------------------------------------- =20 =20 -------------------------------------------------------------------------= -------------------------------------------- =20 Ross Computer Maintenance LLC 816-694-6628 =20 =20 Ross Computer Maintenance is proud to announce the creation of our new = website which is located at www.rosscomputermaintenance.com Our = website is built and hosted by American Data Design 877-422-8140.=20 =20 In my 12 years of working with computers I've noticed a lot of = frustration and lost productivity could be reduced if there was a = regular maintenance plan in place. With this in mind I built my company = around building relationships with my customers to help them achieve = peak performance from their computers and all their computing goals. We = only do one thing and that is work with computers, but we offer a well = rounded selection of services to accomplish this.=20 =20 Please come by our website and see how Ross Computer Maintenance can = help you with your computing needs and how American Data Design can help = build and host your website! =20 =20 -------------------------------------------------------------------------= --------------------------------------------- =20 As a responsible e-mailer we allow you the opportunity to be removed = from this mailing list. If you don't live in the Kansas City metro area = or just want to be deleted from the mailing list, just reply to this = e-mail with Remove in the subject line! If you have any questions or = comments please contact us at 816-694-6628. Thank you! =20 =20 =20 ------=_NextPart_001_0099_01C29330.B7655560 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

        It = is the=20 intention of this series of e-mails to introduce you to the small = businesses of=20 Lee's Summit.  Each week = three or=20 four Lee=92s Summit businesses will be showcased. This week we are = featuring VIP=20 Baskets, The Auto Clinic, and Ross Computer Maintenance. Please feel = free to=20 contact any of these businesses directly or by replying to this = e-mail.  Thank you!

     

    David = Ross

    816-694-6628

     

     

    VIP Baskets

     

               =20 Giving gifts increases your opportunity for repeat business and = helps=20 build long term relationships. Sending VIP Gift Baskets this holiday = season and=20 for special occasions year round will show your customers how much you=20 appreciate them. Our impressive surprise packages are full of great = tasting=20 goodies that will make them remember you long after the last bite has = been=20 enjoyed. Shopping has never been so easy! We deliver, ship and take = MasterCard=20 and VISA. Call Jewel Dyer at VIP Baskets

    (816)525-4695. =

     

    --------------------------------------------------------------------= -------------------------------------------------------

     

     

    --------------------------------------------------------------------= -------------------------------------------------

     

    Ross Computer Maintenance = LLC

    816-694-6628

     

     

    Ross Computer = Maintenance is=20 proud to announce the creation of our new website which is located at=20 www.rosscomputermaintenance.com  =20 Our website is built and hosted by American Data Design = 877-422-8140.=20

     

    In = my 12 years=20 of working with computers I've noticed a lot of frustration and lost=20 productivity could be reduced if there was a regular maintenance plan in = place.=20 With this in mind I built my company around building relationships with = my=20 customers to help them achieve peak performance from their computers and = all=20 their computing goals. We only do one thing and that is work with = computers, but=20 we offer a well rounded selection of services to accomplish this.=20

     

    Please come by our = website and=20 see how Ross Computer Maintenance can help you with your computing needs = and how=20 American Data Design can help build and host your = website!

     

     

    --------------------------------------------------------------------= --------------------------------------------------

     

    As a responsible = e-mailer we=20 allow you the opportunity to be removed from this mailing list. If you = don't=20 live in the Kansas City metro area or just want to be deleted from the = mailing=20 list, just reply to this e-mail with Remove in the = subject=20 line! If you have any questions or comments please contact us at = 816-694-6628.=20 Thank you!

     

     

     

    ------=_NextPart_001_0099_01C29330.B7655560-- ------=_NextPart_000_0098_01C29330.B7655560 Content-Type: image/jpeg; name="clip_image002.jpg" Content-Transfer-Encoding: base64 Content-ID: <009001c29363$018405b0$66902244@ROSS> /9j/4AAQSkZJRgABAQEAYABgAAD//gAcU29mdHdhcmU6IE1pY3Jvc29mdCBPZmZpY2X/2wBDAAoH BwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8 SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCADiAMgDASIAAhEBAxEB/8QAHAAAAgIDAQEAAAAAAAAAAAAA AAUEBgIDBwEI/8QAPxAAAgEDAwIEBAQDBQYHAAAAAQIDAAQRBRIhMUEGE1FhFCJxgQcykaEVI0JS YrHB0RZTkuHw8SQzQ3KCorL/xAAaAQACAwEBAAAAAAAAAAAAAAAABAECAwUG/8QALBEAAgIBBAEE AQMEAwAAAAAAAAECAxEEEiExQQUTIlEyFGGRI3GBsaHw8f/dAAQAKP/aAAwDAQACEQMRAD8A7NRR RQAUUUUAFFFFABRRRQBX9X8RnT7p7aONWlVlUBgcHIznPtWC63qDFSRAFPJKws2B/wAQpRrtncTe ILmdV3RRzKox1DGJP9Krcn4laXpuozWVzbXLNCxR2G0An7nNI2ztU/j0Qst4R0kS6mxU/EWwVuc/ DsCB/wAdek3pOPjlyf7MSj/EmqWv4i6ftWA2l4rHBVTszhhkf1e9aR+K/h3zAXkuMA8gRIe/b5qc hOMlk1lVZFLci6t8flj/ABCRVBwD5ac//WtZTVGIA1KUDudkecf8NVFfxX8OOTuluFwuFJVDtP8A xVsX8V/DgPN3KTjqY16/8VE7FHxkpiRY7rVLzT7yFRO0y5xMkyAZ6YKlQOf1qx1zL/bPRtd1K1ht bzdKc5DgLk5B4wT2zXTAQRkHINRCTks4DDXZlRRRVyAooooAKKKKACiiigAooooAKKKKACiiigAo orEsFBLEADue1AHtFJ7/AMWaDpufidUgDD+lG3N+gqr3f4taX58kGn2U87xjJMpEan6dc1DaRnKy EVls3ah5x8VajKskwWN0G1W4P8te3SuXXWmHWfxVvLRipzcs7ZGF4XOSPQdSPQGr14a8SNrfi2+t ruFIXuoxcxNGSQQoCMOe+AD+tUm5v10v8X76dvnQ3UsTEDGFZSpP2zn7Uo3PM2b6aSnNSj0OP4ND fy3K2nnJcOjCK8kk3BpHO0bhjCk5454zml/hv8OItX0yy1NtTiAnBzbTRkYZWKyDIYHCqN3bPTim v8csLeVGtYnuXDKyMzFY1Yc7sdT09q58dSvbXUJXjkxiRyI2yUUsecDPGelZaVvDTOtrarFhsv1t +GOrT3BWaXS7SFlBgaOzEhYHj5g3IOCD1PXrxUNPw31u5JF1penFAzIXtbjyXUg4JwQVIB46f60g h8XawqqoaPCjAA3gY9OGqVH4o1xyyeecOQQBJKNny4+X5+OP8aZ3Y7FoaeyT+KJWleE9S8O6lb3W pCFYriFmheKYOrDK56ezCu86Xj+E2eOnkJ/+RXz61zfNp9y11dyzJbQrHCryMRGC6jAz0GBivoLS sHSLPAwDAn/5FaweUYaiqVUtsuyZRRRVxY8oqm694g1ZdU8nS9nlwsQUVlMkuOCQD1AORgc5BqRp fje1nPkX6mCdeGypBB91PI/egopxbxktdFaLa7gu4/Mt5klXoSpzj6+lb6C4UUUUAFFFFABRRRQA o1bxLo+iNsv7+OOXbv8AJB3OR67Rziqnqf4r2sMLNp+nyTHjDTMFH1wMn/Clv4v6WItT0bWkUAOz WcxA65BZc/o1UJkJtZIe8fAP+FZzk0c/Vaidc0olm1P8TvEk8LNbzQ2qgBsRxAnHfk5qu6prmqX1 5bXF1qFzPDINpV5CVB7cdKV2+owsqQBZJbjcVESIWZvasp0u0sZbf4eFDCS4WS5QSqo5/KDnpWeZ MyjC+zvI2uIvOhz3AyDSuByuoqx6kFWB71jbXl/eaf5rXDwgkhViQAY+uCetRre2ZJy0ksjSFgcl gTmp2PspDRWQi9zLL4YvRZeMtEuHbGy7a1c9iJAVH+IqFrSM/wCJ2qyoSPIvZZCV6qAf9cVkbHUI oF1ezaWMwSK7SoPytnjn7GvLyC61HxPe6tZuqPJK1wQwBADHke45x9Ks09mDsem4ra3dIzvprmKz F3p9rHkD+fuj3eWf7Sjpt+xwfbFIBbS3EjSyks7kszN1Jq1w2VzcanHLI0sFoIzG0EMjDI2/lHPQ k9+1bT4ciSQbZpfKDAkGHkLnnkHrj260tFOKwel9ym2xym3jwV2Gx2pnb265rfHHslG0Yx71YJNE DGRbd2WMYC+ahJXnocd6UTRS218YZInyW2oTH+Y+2O9RiTXJ0o36VSioGm5YjRtRJUsMRAgHr8// ACroOp/ixLoV02lw6OkotVWMTNOQGIUZ4C8frXPpZmFneIvysXiUgrgg5b1qLrtxIPEOo7cys166 qq8lmzgAU1VxHk8v6vNyucoeWXxvxr1FXx/CLQj081s4qbY/jDc6jcRafFoQS7uX8uJ1nyqsf6iC vQdT9KqI8DatJarKZbeGRlH/AIeQElfYsvGftUjQ9GutJub2+vrJophGIbba/mAb8h2yPYY55+at VhnGnKytOT6QyvZxc3ryqSyg4Qt1KjgH69/qakLqUkkax30SX0S8ATZ3qP7rj5h+uPatFqkMxk3s T5a5CKQCx+//AHqReWHw+3akmWAJUrkLx0z68HjtTe2OMM8m7L1J2Jky3Dxuk+k30kDcgQXjFee4 WUcH6HFPLTxpd2Eq2+t2rxk9GZQpP0PRvtVb/ickkRjuIVnBUBizNk4zg/XJqTBcqsJitbvbE2S1 rdqGQ8e/FZOpro6lPqmOHydFsdWstRUG2nViRnaeGH2qbXKwlrFINpl0qY4PyZkhbj0PI+xP0p3a a9rllEHdEvrZestu3mqPrj5l+9ZuLR1qdZXb0y80Um0jxNYasyxxyBZmGQuc5+lFVG00+h1RRRQS f//Qvf4k6eL/AMEXr4Jez23SY9UOT+2a44xAkLD8kqgg9q+h7y1S9s57WUZjnjaNvcEYNfPPw0sF gsMv/m27GF/qpx/lVJLKycv1CPEZf4FFhZXMur3kVvBekOuGltEBZAeTknAAP1FeX9hb6RFIIrC8 nJTLPPKgjHIGSsZOcEjq3fpW/UPg7iKFL/WLm3hA+W3itt4JB6j5gCfc1Bl1mytpCljazTRGExM1 24JfkEfKvCgEA45z61VZZ06WnWiTatFLp0LQ3RVFRVdRFkq3fPP3zW9IIpJFZLwySZ5zGVOPua16 Lfya3rLx3KxoJFUlYk2jarAkevQmrxd6VazW8eIEhBcFI41AAHvWFt6rkk12O1aZ2xbFYuxb6K1k LpwJGBddvBOODj1qHY3MFoSEkbcBgsygk/6Uwuba2W5aMNA8O8qrScgD3xWB8PMHWZ4TFGRx5siw Kw9t5BoV25cI2q0Xt/KTSX8G+G83IJEwfmGCeOa2NfzSElsNkbeD0Gc/41on0qa4KR2aQME6rBcJ K7D6K2f2r2eCy8k/M8Nwq4CRAkls9GB5U1Vyx2huNfx+Lz/bkYRXdy4ZdwXPzALj1qK858xpJiWR W3mReMtjoCO9RYoGndUgXyPMOI0bJBxwTk9PU1N1OX4iwtreACOztSVU9WmfHzSH64GB2FCksBGt SnGLfHkQXssl+8skcJAV4csxJIVFIBJ+g70w8ARx3fiy9vryyW48tpJiOm12YgEfTmlF04towRlU klVXA53L1I/YVZ/A4CNfTwqEFzfhCMbSqAkn7Ct1JOLYh6nVKqxR+i+aTpp1AzSSu8KhiFjUghfr nk1tufCtyykRzxyAjgMuDmtyaxp9k7BZBKxGWWLB2D+0x6D27nsDTm2vVuGZFRgyY3jqFPXaT646 jtRBvGXwJJNLkpVx4cmiQiezZlGOQA3NRXs9kZVJAiZBKyZxx257dv1rpBOTUe6ht2iJlt1kzxjA zVlY8mMtPCfaOXy24mjKxKN8a/KYyNrHrz3/AOsVCkDW8qpcjyQc/OwJXp7V0K58I6Rfh5oVe3lb +pD+U/SkT+EdWtyUt72K5RezEqf9KutW4L5HOt9Jrm8pYK+8wVIxJNuiyQpDZ2nvweQa1w3U1rN5 ttO8TdmQ44plfxXNqk0V7BKjJgFlPGcccioNjZNd3UUPJDHLEcnHU/tTddysjnwcXV6N6a2MYvll 08I2RuZBqtxbwrPtIEiRhS2emccZxnt0YUVZbC1Wzs44goUgZIHQH/riilsnq6a3CtRJVFFFBqeV xnx3aJo+saxcXrjF46PYRjJeZyMFQOwB7/QV07xD4ktPD1uhlV57qdtltaQjMkzegHp79BVVbTrq G9i8UeJ1jurxWAS3RSY7GMnkJ/af1Jqk57UZ2QhOOJ9FDg/DzUbvQ7ud7tRrUaLILDaCFTrsJP8A WRggD/Ol3h6y0JbCEXujG/1GRnyHufJjj2nG1h6115NNZZLjWY5i0d2sYRB1VM56+p4+n2qrePvC KqD4m0iNm3IDfQoMMw/3oHqMc+vWllNy+L4NopRXxKxfSzwNayw2Gn2EUEjZW0iO7BGOWPXtT74q BDDLHI1zM6gKoGTknhR9SaWwzfxXR2liKtJC6uQDkMMDB+7KP1pjE0mo3kUkUXkSsixwMMcPIwjD fUbi3/xpeytTlFYOlpbPbjJyfXI20vSvjbg3U90ttEGKvfADLMOqQegHIMhySelMZ7rw/oOtQWcD aazPOsU4mjaS5Un+ouSeOnJ9aYeILCX4W08P6TpFvOpgKRTykAWeBjeeCTwe3OaaWWlrKfjbuOFr uaFY55VQfPtJ6e3p7YrpQgorCOfZOVkt9jyxF4g1fQGu7nQ30u3udTUotvBJDgTF8H5WA4wCc9Ol Kte8Omy+Huo5DcWjsqRXEjZe2fOAjnq0Zb5cnlSeuKvU+j20uwiOMbJUlTK8qy8Ag9jjj6VWtM0S +NzNomrM8tgIH8qRjnzxIWLj+6yEjB9MVMoqSwyK5uuW+HDKJbu0krRRwbX3sjBusa55H+Va7+4E kjJHgwxqVXBGAcc0w1nS5473y3bbOLgRXLgYLSBcq/0dcN9Q1QbhfgIJLYhHmnQqWIwAfb3rlyht swd+M4zjGcemVvVZNttGpIx5wJI64A/510DwhcWMfhe1lXzPjpHeZmDlNjHjnHUccf5VznW2kFsF YDhiRjrnFdFvLjRPC+jWNre3Ukl1HbpiBOTux1wOgBzyaZf4pIprlCzUZsLLcX1gthaxTL5SSThw pBYyup3e5bpk/TrWyx09LyJJdPv5htQBZD/mR15LMfVsc4GKRTXFxbz2t0LSWUqjbHRCVKuBn2B4 HIojuWhhlFnKIbl52lDSRspxtOExjB7DHTjNDnPpo497kniKLcZNatoUdQsxQENHndkA8YPBJIwM n3J7Cvbi9unuPKZ1iigiE1xMgOdvPAU9yVPrgD1IqvXHi5LG9VI0muLQFAzzIQ7fmLlQcZAAH36Z 6VF1jxRe3NxJaSeV8KSoDRkgsGJ2nnthc1dZa5LU02SaysFkg1KS4NstlOs8kinzo2GEUDqc4yOS AOufTriba3lpcmRLeeFmiOHEb7gv39aoGnWVreXM8Ek1yqzIA4jkIBB5GTyDxnjoQaeroKQ3IuoJ sEEmOMIAqnGFHGOBzx759Kq6/cXA1LTKMuzPx1Knw9rEirvkcksAMkAev3qN4Vgiivrd5uGuGIjB 7hQT+5H/ANTS66S91LUIY7qUF95UnPyoM9vbgmpqqboH4dX2blEYBwUC/lIPY9/rmm6Ybatp5a2v 3Ne5y6jwdDoqBpFzc3enRS3SqJeQxTO1sf1D2NFQzrIn1X/EnimPRTHY2kDX+rXIItrOPqf7zH+l R3Nadf8AE80V6dC0GNbvWXUFt3/lWin+uQ/uF6mlWnWMGmmSO2unu9RvHIub9iPNmcdVX+yo9uB6 eg2Q2kss36Fo66fNdavrF2t7rRQtc3ABK26YzsjHYAZ6UotZZrvUjPEjStfGSQ+XIWRox0VhkhWQ gLx+YH2OGGt3VxYab/DLUK0w2zTMgAjQFsKpwQw+YDnnsDwciHNdXeheH7jWrS3j+MvCvkxKrGKC Mty204KgltxHOC2OlZWNJclFFyTbJGnSPY313HfRtCXRfIgUlmYAknAHckj0HaltzqNimoQaoI5I gsG8yOpBCg9TjPAyQR26HFadOtLrX4pb1QssMhYN5rHcrk5+oPUblOCMHtgVDxRq1tdXC6VHEFFs 5+KlbJMkg4246DGBnHU80vCuKk3nL8mqliOxmjXL/S9O1ZNV8O3Eb2c77ntec2smeQOxU9Rjim2g eJdPFxFfXEotoI7mNgJGB2qsqnHHsSftVXM4hXG0SZHyquMY9fpXtlAqYYYVySxKjG36elb4Wcj+ nonbDEO3/wBydrHiaG91OZ9K1OG8QhCqRsoeMc54IyVJAzxkHHY0xOuO0lvJjZG4ZGjDcrlkAZuP lwCT6c/euJ6dIIbqWZ5QpU5Utktn2PXNdC8P/iJcTCLTLgFrliDDNKM+coPKHHRsdD3rZZfIpZON djrkujDU/wAULq1luNNtNOLz2dx5PxElyv8AM2Nglht43AHp0zWq1/FG6Ahe80OS4miB+eO5ULk9 TwPSqhMtzqmq6jew20hSa9mwQAdp3etaLhdQtolddjR9GkjQEKc/lJGRms9z3YRecLIQ3uPxY817 xqddvZZbfR2i86BY2zOCd6PlW6ehcfetLXUd7ZK8sRVt5GSMnI659KWafaXNxHNdhI1jjwHkDABT nuo5/brUW7muJIBZyuYojlmC9JGzjr1xWFsNzz9G2hunKaqS45IE9peatqjWtkN6Q/zHlz8q4GTz +1PRpUkMsouSzzMfMLMSSTnvnknHrWOmXS25KszwNHEwDxHnaRz+nUfTFOtKli1G0iaNs3kAUNGw JyMBdwPp0+9Xy8cGfqkJ12JN5yNvCfjFLHTF0i6eYGG42wkDP8snkH6Hj1wQKba74ng0yC3N6n82 5kb5ViVmiTkHaW4LZAOOn+NcwnljhvS8I/lpJhOSQ4B6+vWtXiPXL3X9Ylubp+fLRQo4AAX0+uSf erKTXYzGiu2UVS8o6RoWvWetixsGgMLiMpNLLGJCzDG3kcfNzwRnPAzmt2r2tjpdubiQLHCuCkig qQSuBgdScEiuO273FtKs0UjIUHBXI5/71d9WvRr8azy36wxWFrFDBC+SZZcfO+B755NTL5L9yLZS 0rTzkkp4gtVMdzYvOjx4WVpEAGzcPlPqeMj05qyTa/aR27FruA5AIUSDnmqWr2KWi2KwnKhZN5mE ZY+wIJY/pjFM/Dum2d55yz2NxNJEpkLRFQGB4y2/5Rjr19TWTi/DMK9fJye5djS2llurfdbuq3N+ DHaJ5ZYZxlunIGMDPbNNtCks9O1W10TVZ1udSmzIU3AiLjIBxgHpwBnH70pubrSPDWnQi0uXuWuh Iizh1JZAuQqsMKq5P5R+Y9ahJqTPqttqT2iOz7SrSSFmQoMKcDADYHPX0pjdsjhica8ycvt5OvUV ijB0DDoQDRVySoeI7OTQNQk8S2UBltJlC6vbIMl0AwJl/vKOvqPpzE8Qa5Lp0ljc6ZG7Wd3DuWez szctMwPCdQFGCTk5yfpV6IBGDVDvrV/CU8+nAumhamSLaRGZBYTnopYcqjNgg9jx6ZznlLKJwnwx boukTancyX127SwuSZJGVopJWwoO4AgA/KAw6EjoCM1X/GF3qNjqt3Ab1predyjAKCY1Y7xGx6Y4 3L36jpVusNXtjbx6dYxSRmFj5oILFGydwfPO7IPqT1pD44urCwkmt5tjtNbZWPJaQShjhjjoACPr xz1pOE5Sm3JP9kbShH21tfJ//9GvJ4hu9BgkGjybJLu3WJ9y5IfnkZ4B75pDJaC2iVnO935JByCe 5zXou4HVVZwxz0YEZFTJrf4ja1qrTrDEJJmjjbbECf6iRgEHj0pdcco3oojZ8ZywQLa3YnG05JyR 3IptGgARshQQQWPQfWvYIAm0hATwMluM01uby1mtSsWyMlQNqx4O4DBJ9R3rKU3k9RTWtMsR6FzJ bKI8MxPVSeprdNA0MUd4UUKGwpwQVI53D056VDjgMzgxTyRSDKjy1BAPuCOK13N3qc9q8V1qEkkZ XDIERQf0FORtSjhnn9VpHqdU/ZawStEMt3ppuZY4gjuzvPKASMt6nvn0GaZ27WEO54bmR5QMIGUx ox92DbsfYZ9RSHTkksoohuMLhc8qwPrU57t3mVgqSoVG4FcYOOcdxSsm8ne0/tSpVW/xjjA8t0t4 bhrvU7lrm9nAKmJ9oXnpnG189MDIx70o8VGxj1WGPT1KxeXlkOfl+Y9OT6VHNwY2LI7KgyQrEAKc YyPeoVzP58/mMuMIEB69qlZfZzKdFLTaziWY4ybYZpY5VxD5yrkMqkhivQj6YJFNdDiSNjdi4MMJ 82GWNiFkVCOOSeeoyRyMZxS8tA07XFuF2DAXYD1x+bFZTXTOyh0BDZyykjcTjk+/FWy0sIy1Wmu1 U3ZHnHjyhxqVpHc2zXUIRo0QIsjZVdoGB154HrVQuTE0vmwP5gJwcA84qbql9LqLWzorAQNjy5Jj IkgB4+XAxjGKz0yzPktvVCQWlKsThkC4bkdMYzU4Qhp3LT5kpc56PbXR7nULK6uFkgVLRBIyNKA7 dOg+hJ+1WPwNaW0+pSRyxieBIA6szuAj7hx15OMn7VVY7S2leUhhJxlTJy3/ALRjvz+1dF8LS2L6 FFBqEsNqIw0YiSNmMoxjcwxwcdwee/aqxcd3J3NXGz9JusSbl1+w1uNB0i/vEPl7RtZAZJmdicdM Nkt6gA1PkstQ07T/AINbyP8Ah0Ue2HyrcyMFHQsxOM/qDUR7uyN2t1Bf28TgKiorEMEC4GQOdwy2 OB6e9emS1g0tfNsb9bVJ/OSSNRGIyegAb5mAJOOOprWxx25TOBXBqXQrm0Ax28ZSznuTboFggEIJ QdmIAwvsDz3NK7XS3sdo1G1ns55HzCrHIznJLfXH2rfJp93dzSmyvbww7gWDDLZI5yc9ePfFP/B+ gzy3jXl3PNNFbsUVZs7XbH5gO4560nFOTwNyajHJc9OVF0+AR7thQEb+uDzRUqin0IhUa+srfUrG ayu4VlgnQpIjdGBqTRUgci8Tpe6TF/AZWYzxOslhcYULNDu/rOMBkJGSeDwe9c4v1uJZUnurku1w Q8koJfcOmT06DoK6n+JPieK4uBoto8Tqh/nsVYNFID0z0Ix14Nc1EKiJzKzK45UAZBOf2pduMGdP QUy1Eml4FN3HFHI6xuZY1YhXK7dw7HHarhompyWnh22tLa2SaN1aS8dmKsdz42nrkYVecYFVm1ZP jD50RmJA8sBSRn0x9Ks9lPbwjzpRAsoOVG0gKPcqc/b9amTwh6FVdsk32vCNCxH+UwG7zPmIUHC8 4/bBrzYImZGAYISM8jLZ4we3erKFtfgWkkMUCyZyFjMYZuCxy3Ttx69uoqq3JPJY/IGJUphhj785 +tLxkpPk6Cstk8QS/wAmYuxEjeVEFzhTI3JU+4H+NQnk2FsjnJGBW5Z1UZZt3GcFiTj/AFrS0ct5 cCWceXbxgbgo/KM8D2/71ouRW1VaSxyS5l9GBlYJHsmYKxAfcCFU56c96yntgkrqz7hGTzjBIB7H uOKYtEtnawxkOszKXePcCqjHysQRnOO3uPpS1ESUqJYmURqUG0klhnr7VZPk5+trjs92Ucc/yepJ ZxlX8tkIHEhYk59fSsY5WufNkYYckn3NYNGbmEJEeUOC3cHPcVhBDItxLEzbZY1wCM4JxUtZF/ep ol/Sf1/4b4wkr7JVDjpgnkD2qedMjFsW8mUAqCshkOwDPXBwc8f8qi2KbrgLKoW4BACOQMe/PGaa MY3cRrNulIJLLlyABzjt+59qzeUz0MJ03wc4tYf8kHazxxwRDaBlXJIUdc00trRmjjgcCBRDIC8m CqsVYHDrnIIx96beHtFuNS0hTBY2mwSOpnm+YsT29tuKbaVo5TVXgmht7ovOsLsISiKu3Lcf1de/ r0q2WlyeZtpjG2SOdqyfmLNJKMITGgSNVAAB4xlj9PcnNWLwjeSxailskrLJcMFKhVYsM5BG5W75 BAHRuMEZqT4w8N6hpMTyLBbxWDzFYhbgkkk8FuODjgAVYPDXhPUdH1DTb24hgmJBSVCuGjRgCOvB KnuO3FSovIs7bG0m8pDK+uNSs7ZDNcT2yO4jVlBLMx9B8oH6EVIsdPOpNELqW6kj2jO6UsXPXLYw B24HrS3xJeS3estGr5itW8qID/eEfMfsKeLf2ukaebdX8y7EY3IOdpI4z6dRVFhyeekMtNRWO2Rb myS/1y10pMfDWimWQKAAW6dB0wOPvVrVQihQAABwBSPwvCnw1xcl980krLIT2I/709retcZ+zCb5 x9HtFFFalArXKzRxM6RtKyqSEUgFj6c1sooA4T410LxJFfvqurQRoL2T5RbvvCtjhCcdcDHvikL2 MkCbZ0kAVfnwCSCRke1fQmsaXHq2nvaSMVyQyOOqsDkGuM38U9nc3VpczJazvuV1lBMYbGDtB457 N2z2NLTWH+w3o5Oqe+PZUkfewLS5IYfKY8YOfUf6VPt5PKeIrtBD5ZioYLg+/apdjo13dbY4lLAE 72YAhRnvntx249K3XOiyWxaWREFvwGeLIAYnpzn/ABq1jT4HNJqXS3u6ZOs7svZXVuG3F8SBTglm DEZ54zgg88EZqFqFtMtyro4Mbgoyqgwhx+ZcdBnqO1ZaYIZ5XjDswdDEzCMkAe3PXgD71YLnSWgS FBHZWxkILTXl0kjkk9FjXPJ+lYLHgjVvdbuplhP/AGVGy0S51G8W1DmME8yIDIcZ7AdfTk/emUlv a6dOJktndrdjHEblApZ/6nZQTnGQAAcZqdqM8ekxyWtrfMbiZysxty0eFBOcMcZHbpj0pfL5dzbw srCLZkMNpI3ce+TwAf8AtU5b4GKYrcr738V5ZFv70PEsUkwLyEvIeig56cdT3J+g9a2JN5cj3E5V /MAO9FDGTjGcjg9OajNYJd3MPlkvDHuEx3Ac54wOtSWtIIpQsW2Ec5dTgA+9W4SMdRqK9Xa9NH8X 5FckJub+WWzJWEqHKtxtOQP0yazt7eZJVeSPaNwy2chu1MN13BdNFbj4kglGjA/MMcgg8jgdakh1 WfaFZTIhJVhgyLjt6MB29Rx6USl9DFfptTqdU3l/ZHWwuJZ1u0t5GjMJwyoSCTx1H1NbH0yV4FIi ffJkFRG5YD7Crv8Ah5epb21xaSTRxqCHSRiFDKQQSM+hH71cV1G1lcA3LbRzu6H9utXSTSyxSu/9 KnTGOVkpfgvVYdG0R7Cco85kZhEAdzcDj9qZaO1xZOl5e2kpmld5XRiAS7nqc4AwOMe1SvFV9atY QQxFJGlYl32/Mqqcn3HPFM/DtokOmRu0YWecGQkAZQHoM/TFVw5S2p9Cs5ZTm12E+o3FzGoWwCoG BDSqz4x0OAMZ+9KL3WL+KFpJFmV8bYw0bIGOeBnj/OrfyFGBn74qmeJbltR1ZbKD/wBFhGhH+8I5 P/xH7mptTSzkpU030RdH0a41ECIPEcLumnDbirN1wP7WftTZdNjj1KGwsvMWE/PM4YncBweftj60 zs4Y9I0trS1CmSNASTwC54H70aFCy7nBLxIgiSQ/+oQSWb6EmiNSSSfYSsbba6GkFvDbReXBGsaZ zhRjmttFFMi4UUUUAFFFFAHlKNc0C11e2IMcazBgwkMYYkjsab0VDSawyU2nlHJCZmVorgCAZO1S xDqAOmOmfestkLWy+UEuCnIku/mCH1+bCfsTVo8baVg/xdRv2osTRlSwBycNj78mqlNNcfDS25W1 gjuWULIS0jKwxkKTgAH0pCUXCR0IyVkT/9Lye0iW4nkjv5czpukNvaMVLeg4xn3wPrUMalBauLi4 nEbRncFEeGWTPAHDDOcc8detMYi1rbNZRvDYvEmZJZgPOuA3IIYghRj3FVB7vz5syp8sbMYlJJBb PLEnqfSkIp8M6CaztXkmu0t3uvb+eXdIgDmSQtt5HC+3GKiu/mZbdtQOO2MDGBgevatM0srgqXLH aAqkAEcj0rxZWCqN/wAkYJZgATnPb3qe+jtU1bKNlzz/AKPY7lI5xAscmCM/y2OeatVva2beGv58 NrD8252lZhNgNzjGQBj6Um0aBZke4uZ5bXDDylgi8xycevb361ZdPNxIJo4hHcOx+a5vo+cFccb1 z2AwAamTRw4QcbpTSxzwV27iiTUHn3M0m8nZMRHtB/pOOScHFagztLFFAc7iCq7gQpz3Bx+q/WvG 86AsjTuwUkFgxIJ/u5qK1w77gZCEj/mbA565/c+9RhnpHBQrWX3/AMlq0qWKz1O2KllM0TR5ErLj ndxgEg7s9vTpTq91KMQIst3eEBgVFxAVDA+h4PT1qiJeyRywv5zo0TAq6sARg84GOvGOtXO5NlM0 V3Z6pcK5GQ8xLsB16KCc1TDwkzl6mpRkpryTUtTqEfxJE6nhQfMjKsoOemcj/PFN7fULm3t1ha6j QoMMfNjXIxx3IB+gFILGCa1jjnTw/dTXAxIsnlu3zEZP9WM8ntjNbtXkvBaLPeWtvbTzKAPNVS6j 0IByD9M1KyuUIvEntZPudZv7jzBaXDMVGETftY/Xp+oyKgWuoppN6JZjGCu5S0zEfVwe3JPPak6R ysrSTWUV1CmMOswV1bBBORggD71vsCXTzrfVrS0mkYhP5bTHaOuPWqNvd2W2pR6LH597dF7CyvIp pb0EoCEZY0H9WVJ+ueM/WrjbQ/DWsMAbd5aBc+uBiknhe1mFu17cTi4MgAicJtyvc49z/hVgp6tc ZYjY1nCPaKKK1MwooooAKKKKACiiigDXLGk0bRyIrowwVYZBrmviLRv4TqzeVAshn3SRuCFKL9Tx xwMeldNqt+Nvg49F8654kDbYH2k4Y9c+2AaytipRNapOMijz2ulzxq11DPe3L7YzHGfLCyeigZZj Su98G6hHKyJJufgtEQCEB6BipIB57gUxsbq3thujuJFMyjaA5aSVenB/Nwe1bZrZbXTvIvrlnmZt 62UMkkiqfVjuwOfrSUZNcDrhHOcFOVGszItxbNKF4BVsqp+o4H61tsbCS+zKIzDYowLStwOB0GRj NWhFV42t5S1vbhcs2OGIB/Kg5I+vpR5dsirdW8EjCPCrLJGilmz68BOO3NGc5Y5+pajhImxQX81r 5dlHa2VoOGbYApwf6mbDMfpmodg9pZNcNqEK3kTAGIRfyYvlbJI28tyRU6KOC5jL6hdXF7MOTFbK WAAHcsOB9B34qDJH/D7xJLS0Gn3DZwHVVKpj8wY/MeccYxVm8rIn2+RB4itWh1gSG0FrbzIJNiAg be+3P/Wc1AeS0l2hY8EYRmHBIzVj8R2EuoLbPbzXN9dEkOFRmBB5ypI56Yx0pXa6LLO7W0gtrUAc yTyZ2nvkKCQas5YQxXCLlCyU3x4FaFGIyxIHLH1NWxHu7zSYC++JEjWLey5KfNhcYxyRj14qbbaN 4f0a2iM8U9/dtkrKgZFIz2zx+2a88i2a+SW0Xypw2QtxHhVGOu5iSTnH9NDC66ux/BEyJLCeBfK1 C6l3yABYIot+T2HJOO3T71D1CVIrtpbSO9t3hGI1DkyZJ5UYwQKYm6n+VLnXcttIaK2Ulc+2dox9 c0mV4WvHWaS5YxkMslvhssRgZO3J/XAqjwhZcvkwS2h8tY4be5ZQxGLqQqmT+bjqfvTSPT52228d vpVzJysbQoZHRce68fY1GtrSS4laaTR7i9iIaIyzThcDuTyMfbmr34V0+G10xbmOMRm5AbaCSEUc ADPtU1w3MrZPasi+LU9Y0+O0U2Ja3UBWURmMKoGCSTn69vpVhsdUttQyISwdfzIwwRUl5I4lzI6o CcZY4qs67CdFvItRsEKySvh1HKscHg+gOc/UU3zBZzwKcTfXJaqK1QSieCOUdHUNxW2tTMKKKKAC iiigAooooA8qveNYbqfQXjtIlclhuYjJQeorVqnie4W+S00e3ivG3bXO/v32jvjv78VDubvxM0E8 UsEjK6MpKRABevHckkY+bpntWUpppo1hBpplUvNO/glpbS6e0dzb3A3LLvxlu4Oeh+lbAQsAu4LN r29VSI44vnWPJwcDo7D1bp+9Ro49cgtP4U9nG9vO5lQs48yIrxxwNxxx3JA+1RrG6heJFkuJ/LdC wijdYS49+xpKaWcoejnGGbLOy+AmjF0z3E07Fls7iRZGZgD/AExjHt170yuL6eKQ+dfrbSQL/Lgh AJjGePlXIXj7+1QGntYo9iWIt1IyZjM8hVc9uAtS4tRghAWz01JDj5XYec47ZA4UfYGjPOSWuDdZ 3tzaWJazjgsgAVW7uF8tpMYwfm+cg89AOlL7q6QTWu1LnVZLiQGby43CbgPRjuYdug4ofWZEd1mh zPMnzmXAKHHqVwOnYVjZ3MSyLOXEhZcjy1MgxjtkgfotVzgnb5JjXuumNYBpM+nwkDCKYoE6ZwQW BPpjBry/S4upIU1NvLjMLBY7KBVZhuUnnpkHHQGoSXl1ez/EWKTkklV4RWIz6dQPapdhqtxazvJd XRTHyA5EzA/+0ADP1qzlwV28jlhqfw0UdpaCzijVh8RKSHjU88u/OM8/LSSSNLe8ih1Oae6Egdoz b43z9AcuAWIwfb61ncavOLpJZ5bgEtgGaQuVU+kaYVePrWyHxPZadcmBbW6YyDcZk2gEZ5yqBSPv QpZZG1om3t9KtkYxp6WtuFEYDHbIw7cuC1I47m7RLiWO4S2tw5DRxzFztxwPXPGfrTbUL1GtWuxc pFFIMxtcW67mAPYH81RtTluobC2t5Q8olUOjRWoVWB6N1Kjj1/Sq5bXJKSRHhtrdlkura4uZVCKX W4wqIAcfnzwST781do/D+tW6GK0vIY4CTiIEgLkdemSc5OM46VXNF+DjmNvqWoAQBkkaJckTnn5X Y4XHI+X78U9u/wATdBtGZQtzOVUnESBu+PX70xXGKWWxexybxFcG+DwhLcQ7NV1GW4AGAA5OTnOS Tg/b96keK7mW20mK3hdWkZ137xk7FyScdunWlVx+JcMdp5qaHqRc5IVosfKOrfQVnoNh/tFcxeI7 ldvm5Hlt+ZQGGBgdB8vfsenetXj8YmfKe6Ra9Oh+H022gzny4lXpjoKk0UVslhGD5PaKKKkAoooo A8pR4mnng0aUW4XfN/L3McBQQcmm9JvE9lLe6TiKTY0UiyEdmA6g+3NVn+LwWh+SyavCulWtppdt dKgaaSIfOcnavoM8gU+pN4Yu4ptIhhVShiXGCQcjPWsPFGo6xptnFLpNolwxfD7wTtHbjI496rFp RJkm5HniiwspdNkvJysUltiVJc9Cpzj3zjFc9hgaLbZRWYmVHPlF2yir12Ejngkn1+bB9Kso8O67 rMry6tdyiEruWFjhQcegbr25A6n6VP8ACvwNhos2pT7YmDHzCwGY+B8o+p5x71lKO+XRvGWyPeT/ 03Xh3SJtRjcQoYpoTllucKJAemAnIx/pkVC1S8uPD+opp1zcBrgRgvIIYyMEn5sleBx+X96uuhxy XWr3mteUYLecFFVsEsRgbhjthfU5/wAedRw3nj7xLNdxoVgdyAFY4yoAAOf6QCM8cnIFKutJcDas bfIwsNZvrmJfg7m5xM4VJ3QFVPZdvcdzjGK2CW9WdYry5iAmcIZzbRKm88DJHzDnkHir/Zadp+g2 bSv5EWPmkmYKoBPp6D2pe19B4luTbW9gZrZR812do2hgcFf05HoemDQ6kl2R72X0J5dF8SpKu1Em dgQzyRxyLjPqfm6diTz3qHqJusi0l2xXEYXzRdWoeLJIAOTnucD/ADqy6ZqN1F4WuJfllntd0cZL ZBOBgE8dCcH6VH06Kw02yi1XUopJZr1ldmaMv5ZC/m9uBnNDrT6YK1rtFXgSW/umsY47VbgjDj4J FbbtzlcL+nemRtteUB5LN57cMQI7tFZivACghcgdTk8+1WubR9M1G2SW3WNQ3zxywHAJPf5cZ7fp UW01G40eZbDWJMxhcx3jNw3sx/z/AF9Seyl2w97PSK1cWWuK9vaiz2WjZ/8ADhflBzgjoQBg5Hf2 pdqmiSefGk0k8ZYcWZuUjbB6YAHQYxkdfTPFdUdm8otGAx25Xnr6VybVRHqOuRNOgvLy6YqGLNHL AA4Cr/ZAySRxnr3qs6lFcEwtcmarzQLuDTWsJS6xz5kcXZO9VBzxxyR3x+1WDwv4IgW3aby1jhlc OGZWLsASADk8cH9SaNTuNVt5LbT7yIT/AA4ZVuDkyMWXH0PHU9xxjrT3TvElrDZJFJbzKIRs3ZU7 8dwM7jkc9KIqO7DCUpbeCU/hexd4XDSq8IwrAjJ9M/2vvSbUbfWPDzte29y88YAAXqNo6Aj79ada f4msdSuXhhSZSr7NzpgbvTjp9ehpuyrIhVgCrDBB71u4RazEw3yT+RG068F9aLLt2t0ZfQ1LqseF o5rO9urSebzGxxz/AGTtqz1aDzHkrNJPg9oooq5UKKKKACsWUMCCAQRgg96yooAqt54em06+F/os bq3IaCNwgYEjPJ47cVgPGM9vcvBfWAj25VS0m1mYDO3HIzjpzz27VbKwaKNzlo1Y+4zWexr8WX3p /kisL48tBYG6l0+7j2k5VgowBjnkjjnjik1/rNhNJI1hBJe214omltpFKr+vUHqeMnA6EYxdpNI0 6Vw72UJYDAIQDj0rS3h3SWcMbGMgEFV52qR0IHQH6VDjNl1KC8FN17xnLe6TJbWsXw0b4iklgkLM QR0jOAB2XJ554HenfhO40XTdGt1W8to7mdEEsZkUMrBQNmO2MYqdN4Q0iYFTC4Uk5QOdp9iO4+tR 5fBOmNGkavKgTOCpAYemCAMYPNQlNcslutrCI/iW+spLuwaTUgbVJCXhgdSWOCMkg5GBnp798VlP 4u0qxsmt9KiaUwooVRGY0jBOFPzYyOe2ScVnN4Lt/LZLe5KbsZMqCQsMY2nPUd/rzUKP8PokdZDc hnViVc5LLxgcnNQ3Yn0CVeOxto+ieV4fksb1gZbtW80jgnI2jp3wBn3qLZapDZIdG1iPydrFYpCS yFcnGWx8pAxyfaoP+wl6LiOT+NTM0aqol3EMADyMdhg9iKwk8EaizSB78SozhlBchUPqFx+o6Gpb kl0CUW+yfp8lvpOuW9lY36S2l0D/ACgQ2GwTnI6E4+/PpVju7SG9t2guEDxsOQaqMfhPU7OVJoLo NcBy3mg4J64Bz2GccetTPgfFKTrObscJzFE4ZWb3L9B6YHt70KTS5RDim+Gb/MvPDr7JN93YswCH PzQrj9/p+npVX1W+ttS8aRLBLZNEqLJbyyEKIpBliWyOSSORx+tOvgPFMglEt24ilQjqpZT+4/TH 3pa/hjW3tyFiRNwEbtuLF19cHke45ByTis5NvpFoxS7Y5tbo654ljljiYQWQKs5QqGbAPfsd3Hfj NPH0mwlmM0lsjv6tzj6elV/yPE1uqrYwIo3D5G2Kq+p4659+fYVtebxYLaUKsLTlWKkRgKuDxx3P 3P0q6kvKKNPwxzb6JptpP58NnEsufz7Bkfet1/eR6fYzXcv5IULEdzjtVc+O8WLBCosY3YNtkkZg u7jg9MgZ9vvWE+iazrNxDJf3TwgMCyxcIAB/ZJ5zU7klhIjbzls2eEbbzbq91J1ZWlfIUvkZPUj0 +9WutFpaQ2UAhhQKo5+vua31eCwisnlntFFFXKhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUVABRRRUgFFFFAH//Z ------=_NextPart_000_0098_01C29330.B7655560 Content-Type: image/jpeg; name="clip_image004.jpg" Content-Transfer-Encoding: base64 Content-ID: <009101c29363$018405b0$66902244@ROSS> /9j/4AAQSkZJRgABAQEAYABgAAD//gAcU29mdHdhcmU6IE1pY3Jvc29mdCBPZmZpY2X/2wBDAAoH BwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8 SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAETAMgDASIAAhEBAxEB/8QAHAAAAQUBAQEAAAAAAAAAAAAA AAMEBQYHAgEI/8QAQBAAAgEDAgQDBQYDBwQCAwAAAQIDAAQRBSEGEjFBE1FhInGBkaEHFDJCscEV UtEjM2KCkuHwFiSiwkNyVLLx/8QAGgEAAgMBAQAAAAAAAAAAAAAAAAQCAwUBBv/EACoRAAMAAgIC AgEEAgIDAAAAAAABAgMRBCESMSJBEwVRYXEjMiTBM4Gh/90ABAAo/9oADAMBAAIRAxEAPwDZqKKK ACiiigAooooAKKKKACiiuWZUUsxAAGSTtigD2onXuJNM4dtRPqE/KW/BEu7ufQVT+KvtPjtpJNP0 HlmmGQ10cFVP+Efm9/T31mFzcz6hctc3U8k0rklpJCSSP+dqhV6HuPw6yryfo0BvtW1ea7aS20mJ bVQTyyBix3/mG30q+8N8SWXE2n/erQlWU8ssTfiRv+d6wWKaUxBcBguQpbcqP+GpXhfXpuH9aW7V isJcLcINw6Hr8RuR61XF1vsv5PGxxO/RvtFcRuskayIwZWGVI7iqT9oHGMWkodLt7gx3DqGnkU4M UfofM1eZT6QrxZ9otloHiWtkq3d6mzAnEcZ9T3PoKgeC/tJvLvVnttelUw3TgW8gQKIm/lOOx8z3 qhSwSyo1/dgR2sxJSJd3iBHsuw9fL98UhNA0PMWKsC+FZTkE5/WqqvT6HOFgnOm2+/2PpaiqF9nP GJ1WD+D6jKTewrmKRiMzIP3H6b+dX2rE9oVuXFOWe0UUV0iFFFFABRRRQAUUUUAFFFFABRRRQB5S U9xDawtNPKkUaDLO7YA+NK1n32weMOHrMxuyx/efbx0/CcVxvSJTPlSRYJeOuGYWw+qxHfGVVmHz Aqucf8R6XqvDYg0/VUfmmHipE2GZADsR1xnFZZG+EBG5PQE5NKFI2DiWM4AyGU4YftVf5GaOXgJQ 3sahOeZmjXlGMADbAp6kaoviMwz0CDYHbGa4heNo+QrhwRjtzCl43t5bpElIWNThiBnfFce6ekNz jxcbiO1RyjLGGHVgoBA6Yz0+Ncy3MJgZFBVj0BOSRjFeSsoZ/DZmAJUjoCKji5eQqo5iSRmoJaZL NiefGlb2m9/+jfNC1eOx+zmw1O4bmEFhGT5swUDHvJ2rGtRvZNY1B7yQDmWVmfIyZnznf/COgFPd Y4inveGtL0C3R4re2QeMxH4m3+m+3x8qjYwvKELFYsgLy78nu9Ksd/Rkvg5cqpx9EncamERZ41UF kBZWUMGU9Rv61GXoiS7ktlJEYwUY7FxjI5h0DYOM12lvLdtb28S8x/DKcgBAZD1J2G1PrjS7G4ka UXbS3EjMWSOP2QexHfl7fDO1RXj9ifHy5OM/KSNt7mexvYbqGRo5UYFXU4II719A6FeT6jodneXM YjmnhV3UDABI9axnhnhpdR1Hx766ji0yzcNcyswVcYyFyehPf0rRrj7TeGbZ/ChlmuQpxmCP2R7i cVOdJexvNT5OT8kSXCiojROJtJ4gjY2F0GdBl4m9l19SPL16VL1ZsXcuXpntFFFBwKKKKACiiigA ooooAKKKKAPKrP2haf8AxHg29UAl4AJlx/hO/wBM1ZqTniS4gkhkHMkilWHmCMGhrZKW5aaPnG2s y4bJ9rGcAinfJGvNFLauzHBIBJyMbdK6v7S90DU7yykwxhkKhW2PL+Vh5gjemK3jyXkkjcyiQYOc 5XyqtSkhhXyM+XwptS/2Fpkt3YQiNg4bYO2MD300lcB1hK4IOzAAdqWMiSjE8oUggMwGSR+9cXcb W04dlDKSCvMuQw91cl/IfzYfxYPxz70JzNySLzqeQjm9rOCR1/aubOCZv7cpypIwAcrkDJpxq8c8 sMbZWRIySGwQQCOnrTeyuFiRoxIE5lGebIB36etFrvZXwcyrGpp+hxOy8pZAUDsML+XAr3mH3cuM ArnmHfekrhzyrACTuAAN9x9etPLWGEwu1xyqQeRvDJY4I6keeaop6Rq4L8Z1oXtpI3uY4yyRLHIH yTjod2PqTgf7V7c3Flb27cksrEDm5RGCsrjzPNnHw28qbRwytdvCVwA5GFjGMA9zTJwPvLM8gcg4 Aj2QDvUpTfYjy8WLIvBLdL0l9f2eyC+vzmSUMu55ASVU48unSubYFVLeGARtnzNOog8cRMC4CnIG cgfE0nLKvLgL7WN1xkZqb9FfDwZor51pL6LH9nRaXjmxdcjAl5yDjP8AZn5jOK3GsT+zULLxxbsg K+HBIWDHfpj962yrI9CnO/8AN2e0UUVMSCiiigAooooA/9DZqKKKACikZbiGGSOOSVEeU8qKzAFj jOB50tQB4SAMnpVci4km1y5uLXh2GOVLdvDlvrgkQq3kqjeQ/IetQf2q69cadptvp1sxQ3hbxGUk HlHb45qR+zF7d+CrbwAAVdxJ/wDbmPX4YrgdkZxhwZc3VnNrNxrLTXVrCTym2RUYDfG2+PeTVMvO E75AHVUmOM5ifBxjyNa9xUccKaofK1k//U1VpJoILOOa5ljhQIpLOwA6Utnty1of42e4Xvoye6h+ 7TtFOhhcfllQq2KatJzkAzFAdssCfoKtfE3E1pqML6ZplubqRh7csiYWJfMZ3z61XIrTw1Uu2CUB Lt+gomm1tmlju89eK0kC314bTw5ORQQRkZJx+gNNYmKSrKCSYznLdR/vTxljXJdXJCgnHnjpSU4Z FV/CAjbbY7Kak22Kw+NK/Elpv2evztyyqrMCpJK7nOK6WSbwi6hIiw2w4Bx8a6ewuvuq3vgMbckq rAZGQdxmvEaR4S0gCJGByllwx2xjPSurTQtOXJH+N5P4/kQiRpAxVx4h2ZmyTmpS4FsLSGC2zzsA SCoPK3Q4I339ajxIba4VvCVypyVIJDD1A7VbLHjr7igEeh2UWwBMRK/tUK3vo1YfjOlO2Q9pbPE+ b2NivY5KikHgimvCtr4jIu4DAkk+7rV70/7QNPuWWO8hktWJwTkOn9cVaba5t50Etu6SL1DREEfS ovK5WnIg6qc/m2/6bKh9nOjSWPEkd7flrRpIGWCKVcGbP6YC5x1rWapXE8NvPwVqc08pjaAiSCQN hlkUArg+eTj41LcE6xJrvClleztzT8pjlPdmUlc/HGfjTGN7lCnIuslu2WCiiirBYKKKKACiiigD yoniLiGy4b01ry8cZwRHGDu58hTnVdVtNG02W/vZBHDEuSSep7AeprC9d1u74m1Q3957CrtBCOiL nb411LYtyM6xT/Ianr2oa5q41S5kaN0YNAik4ix0x5VrfB/FcWv6Zi5kSO8gGJVzgMP5hWKO4XZd zUpo3JBcw+NL4SMwDyFSwUHuR3FSa2ujKw8qoybr0y//AGk6VDrVhDeWV5A11Z82IvFUeIpxnHqM ZqkcJcXX3CV5JHNZyyWkpHjQ8pDKR+Ze2fTvSmpaqbOO6tkgBuBg/wAwRVbcg+RHQ9wag/4lfahc LHDBhDIAEiUsVH6naqWvs9Niytz4LtMvXEv2mafqtrLpVpa3QtrlOSWdkKsQRuqgbg9s/wD9qoar qF1dutnZI5unAVEeNjJy/wAxLb4xTYSzrFmSRV5ASz5/T4UpZBS7OUfNwmGllwG65XOegz61Gm9E fwQ7Sp6TYvZ6da6dCIspNcFsMC3tMxODnr596Rd5LyVo41AQE8oVR0z1Pc075JAQwQi4jQhPZPNz Y2Ujv1yD8Kbfd3WPwYlLzSYBVMkqAc/PPypfbbPR8biYuO257f7saSoqeI/hnByWYjt5D06Ci3Ml 5ExEYaQsFZFH4znbA8/1pyiGS5W3RGn9oCSQqXGf5V899q0nhHhG00kJf3Vuq3mCUjJyIR+7evau ulK7Mb9Qv82VTHpGb3PDHEVp4iLa3kcWSCg5gp/9TUfNcalYafe2ptFZLqII4ZDzJg55hjv619CG eMd8VTftNisbnhSaSRB94V0WGQbMpZsEZ8sZ2qCyJvWirwVUqpdmVhWblZlw2Mg9SdqTMhR8jCnG DsCCKcPycv4eUY75O1Fq6pOrMOZTtnl3G/Wrdtdm9knH4+MtCjWqmBZ4ZQ7EZAVcYOaVtr+aydJb a8dTyFSu4KnOd8fSrrwMbe6sbu3lggkEc/OgKAgBh6+oNSNzwZoFy7SNZPCzHJ8KVgM+7pVbzLem I5Hib8bn0Zvd6jqWphYZ7q5uiXBWMszAt0GFHU9q2ngPQ5tB4WgtrlStxKzTSoTnkLfl+AA+Oa70 DhHRNIWK7tLIC4KA+K7M7DI7Z6fCrBTcrSM/kZpteMLSPaKKKmKHLHCk+lFDDII8xRQB7SU88VrA 888ixRRgs7scBRStZTx/xeup3D6PZufutu5E7jpK47e4H5n3V1LZTmyrFPkyI4w4kl4o1D2WZNPg b+wiO3Mf5yPPy8hVbclQQoxudydgK8kud1WNSzucKo7mnVroqXcTeLetFIcgOUBj5sZwT1rl5Jhd mVjw5uTToaWsYkkLHcA9fOpAZA9K5S0eyc28qhZFwTg5BB6EHuPWnljZtfXsdssix85OZH2VQASS fgKnta2Z2WaeTw12NjPFEUku7eO4iXAKSEgMv8pI7U5t7qAT+JpEBt3vUMcdvDhck/zY6YHqSc9c VC3rtLO0TKVWMkYPc/0qU0vUNN0mK4acmK6K5t5AhYsQPw7dMmqbb9yei/Tv8EqMr7fpEdbD7zcM sgXAbABG2w3p8rgnwpYCka7iZXUjp2B2JzUUlwtyzzD+zEkrYjO5Ax3NSFs0iqI1QKqqSHUhSvf3 VTTa9m3g4i5N/kp/FE5ZW5lsUuniSEx45JWJJIz7OwGCfL30Gwks4JY/u0iF8xllVncrjfIG2/l7 6Z215JE8MIYuDgMWYsctk58sg4qR4fltFv2uZZk8aM5VHQsCTuGGPT60t8k2zZaWOGl6LHw5w9HY qt5PCBcD+7DYJiX9M/p0qwFz0LDPkKr8muog35CTvnl/3pB9fcrzLIgHkEwape6ZmUrt7aLGXJHt Mcn5AVQePL8XF1YaXzFh4puJAp6qNh9c1NLrbMDzsWA7YAFU/Vea54gur45dAgjTbZSO37/Gp418 tksWHytTXoRtLW0j5lcBjnPM4747D45pj92EMirjlUDI7ZFSTWk8HK8kZZnHIoGCF+I/5tXEhR2W MQkkAKAH9piB5Aee9M+Wy3jcJ4ndz3+yJfh3TL6a2udQ0m6MN1C4Cxtjw5h1Kt6+tWjROI4dTkbT 7mM2eoplXtpMg59PPaqdpvFdvwtG9nciRfEcPkYYg48gc0lq/Fuhaysd3FcyW2pQYMUyxlSQDnlP 7HsfSoOG32uhbJlm6bZuwAAAG2K9rP8Ahb7TtMurER61fRQzRkKLgqQkvv8A5T5jpVrbijh9IFnf W7BYm/C5uUAP1p5NMzKly9MlqKaWWpWGox+JY3sFynnDIrj6U7rpEKKKKAKL9ovF7aPafwzT5St9 OBzSKcGJT3HqayWSQW8IOeZ2BwOpJ861b7T+Hxe6dFq1vFzT2p5ZMDJaMn64P6msgcs8z82N9vUD NTnpGTy1TyfL0OtOQiSW4Y8zKoVTseXPWrfbILDh6VZysJkKyEkEZGegboMAHf4VVtKMAuVguZfB hlZQ0nZd/wChP0rTeHLC21HXR/E7azvWFkSjtEjAgON+pHekcsusmjU4dz+HaP/RitSvtOa0hA1C 3kuI5Qq8rgko2c9OwIB/zU1vo5Jme30pLu+jAGZ47SQAjG+BjPXat8gsbO2GLe0hh2/+OML+lc3N /bWYHjyFcnACqWOfcKrmXK1soycfFkyfka7MDi4Z4huGUW/D+pvkAZkg8MD4sRUpJ9nHF19Eq/wy G2IOzS3aEj/TmtX0/Xri/a4ZtEv7eGL8DSpytL7lNSVvdNPnntpbc9hLy5PwBNTXS0SrDN5PyP2Z VB9k+uFVEk+nRBVAADOSD57Luagta0OfQdWbTrpkkYBZA6ghWB9/qMVvdZ79quls1rYavD+KCdYJ hjIMbn9mx/qqFztbNXg8h48il+mZ14hhtll6uCAD3yGO/wBaYxqWcgkhiSc9MmrE9jaLdCM23inG wLMT7hindvw7I7eM9jFboNw1w5QH5nP0pVtI9RcSl8uisLJcoQgcsPjSqLdtardFWMTE4YZwBnqf IVbzpWkpG5e5t8hCeWJHc5x51IvaabNbW0VgviGIYMfLhjkdN+o2xXUkzPzZIhrxRnbzskTSsSSB kAZ3NP7VH0+1DuxacIecFQOVj1XJ3J/SpTVNOjlkWS0tggV+YqUKqWHb037VzZaLcXcO11ZJM2P7 Np8yKM74B6GuNaLIvE/kc388M0HKI2XJDzAkcwbAPwHpTBjFAdikOcKreOMnPlUlc6bcafModJUk b85GFPu86oNnz32rQqQ7uHJyz5BI8h2ruOEyHK5C42JUu9lhvdL8Z3a70yS5yOUTIeYgAbYK/vUN /A7R35Ea4jc7crYwD8anPaUg55iOh7/OnUGq39ugWO7lCA55GIdSfUNkU2nro8dXJbp0yN03gy8b mEl5bRwyKQVYEk+XuNcy8BammVhubOYj8OJSp6+o/epc6zduMtFbN6iIIf8AxwK6XWlYgPbMu+5W TbHxFCaOvk7WmRNhoWt6dcwxi3uYTI4DXNq4YRgn8WUOcD3V9A6fNbPaxxW1144jUKWZ+Zjjuc75 99Ywl2s7gRySBifZBcZ+dPYLu4ilAkvWt8kYDBip+KZxXUCzyzZqKiuG74X+jRSGdJ3QmN3RywJH qe+MUV0uT2tj2+tI7+xns5ubw542jblOCARjY9jXz9rOiT6DrFxp0+SYm9hiMB0/Kfl9c19E1UOP +Gf45pgu7aPmvbQEqB1dO6+/uP8AeupivKxO42vaMbRcuBV0+zmYWvGMMYUAXNvLGcDHTlb/ANTV SRAHGPOrDwfIIuM9IbP/AMzof80bj9cVJroyOPbXIk2ukDboJTMZJN9yOc48uldTgGPJKjG+ScAV xEojh5mdSOoIzjHxqvs9EJfc7PvCXAH5mLbfE0sqW0HtKiR7dQMU3a4ijczShoskBWZD7R6AAdc0 vDLBeRMY5OdclSRkYI6ioptndCqyo7YVsnGelRPFmnNqnDV5apnnKh0A6koQwHzFScTREtySFiGK nLE7jtSpGdqk+0dmvGk0ZlAZDY2osmEEl0SGmCAsPbC9+29OpOGrZJFMt5cSTEgu7AMSCcbZ/DvS 2oWh07U7a0jKLGs5bDdSpkUgD5/Sn2oTRW8sbTTRwggbuwHN7QO3n0+tZ1LRu3yK6qH7IW40ywit VEcUjuzqOaSQkjbPb3V2lvEhLLCoKgb4zTuZFLxhW9gK0pYggYOw69ehqLk1W3t25ZAzoNiVwcbV OYrWxa8tU+2PZLpWRkmiEwHsc3MQxGPkfjTc6bp1zYMjR85LFgXCkoMeXXc9TTdNUtbhOYZRxuW6 jPalIL8QSKfEyUJIjBIGCMEippv1RDtdyNNRtpbOwk0sSnHMnKFbxMHPQevpmqfpnDN9pt0txcQ8 0J8QAkgFmHUFSDg/A1ehcTeD4qQ/d2DHkmWIEE422PXbv1705tbuO/08WsrMXDs6TxuCjEjbP5ly eo696vxyltlPLurhSyoW9nAlvDLdmRY5uYKVYArg47g5704bSNNnH/b6woY9FljA+qsf0qT1qygh McNwmDGTlQQCu+/TIG9R/wD0/LLdLHEjrHKheL8+ATgA/EijxbfTMlwpetbGz8PXiLmKS3lHmsuM /wCrFNZNG1JMk2cjefhgOP8AxzUnNogsNPivpzcLDNsrxAAlup2JBx2qMlv7hWZEuJWiB9kTAMcf HNR+WyFTCXYklzqOnlgktzalhg8uYyRTeW4mnfMs0krHbLMWP1p8mv6mg8GK5ZVY4CgkD5dPpXl9 YIl+9q0jm4CJgxxghnIyc7jA3rqb3plbleO5ZrfAVt914OsgV5TIGk+BYkfTFFTllax2NjBaRDEc Eaxr7gMUVcPStJIcV5XtFBIyXj3hsaTqS6hari1u2JKjoj9SPcevzpppksS3egzwIFSG+hiduUBu dj7XMe4J3HptWraxpcGsabLZTqCHGVJ/K3Y1i63F7oF5PBIpjKuqzxH/AANkEH6g9/dRSdLr6MzJ M4cyr6o2i+tJrp15JQiBcMCT7Q5gT9Bj4mmM8Eun2KPc6msaRABQGWIMc9Mk7bDH1qO414om0azk t7Ha6dcCTryE+nnjes+l1XUNSns21G5luhbgs0bgEx7g5PTOfP4VOMfmtmrHy9GmwSRW0n3e7lnf mlzC7qSAFwRjzPfO/XFeKNDiL/8AeqspIAWScqQQMD4dKqyT3z3KXTTm4kTl5FkUcqqF5WCgbAMR k493al9SsYrWNLuEkrNGCvs7r5gkdd9vjVNTU9oZw4Hd+N1pFzsNLtbeKGRPblVcmQOTzE9T8acz y+FIjY2IINQHCUsiWG8gkiDFeUfkPNj5Ywam7xkkjBVwSrYODnFc8k56Kc2P8eRxveiC4mgRr3Tr 9QrDxRESVyQSyke7YGqF9zN/q0uC891JcsqKO45j3PStGvCr2rxtvnBXyDA5B+dUSO9t9GupNTPt crM+UHU53+tUNbexnBkbnxa9CUuqXVzztPcmZN1QrgAIuw6dtiaZW8RubwQc3Lz5wT7qkrDT0WzV 5R/Z8gDKRg9Pp50xWXTpLmFfHaQiYRxQwEeK7ntzHZV3A5jn0FR/L5txPsZjGpXnfSG1zFLYyGMA Mc7qDg0vD96UBpbS4aHAIPgtlfccYq5jRW01Y5NRu/4ZDK2DHYj8J/xzHLn6CpGTQ9N+7ia2+/3L 8qsVS+kEmDjBwW+O+KvWN67Fq5cN/GHr+9f9MpUmsj+HNbCN544MtHJgHlXO3Ov5d9tjvnFOrWC1 mtfvAa5iuZCGYoUZWY77oACB7s1ZINFe+t4r/Tr57qJhlI9Rj5j7g4w6+X9abnTrKW6ZWsFsr9R7 SsoIdfND0Ye7B8waLVpfEgs2G61SaIy6gXUVaO+R1nZR4NxCp5W2zuCcHGw7Go1r64sIXxG/il+Q uAQFjRRjfoNyflU7fWNzGVUIrQsC3jRtlSB2z2NRv31jac0k/MCcLE6cwXfy770uuRUvVrRO+JNL yh9jHWr0+DY2vikolspwQCGySf3ppYxWs90ouESSL8w6bVxdQBCpls543K45Rkqo9Opx6U0RLpLm MWzicSKzEAZAUdS3dR33pmaVdozMkVK7Q41e20v/AKsgtNKi8OAFAw5iQW6nqT6VxoobVOOrYEBh Ne8/tDPsq3Nt8Fplo8vNqU14wz4cckg9DjIqd+y6y+88VNcNuLS3ZwfJm9n9Ca4u8hQu0v5ZsVFe 0VcOBRRRQB5VO474VGs2pv7bAuYUIcY/vE/qN6uNNtRONNuSNj4LfoaE9Eaici8WUXiLSU4h4STi CznmS48FZmjzlWwMMMHvt9PWqzDYyAzgq4ZmAwzKXC5yObGwON/nVg4bjudU+zlYI5wklnK7EE5z Gct88McZqAsZxZTZngdZA7ZHQ4J3A7EZGR2oV+MjWHDV24n6P//SmbZ3WFFkYBwMEL0Ir1L9Sk9q wLxTZBPMCYz05h6+nehkR42McgcBiGDYBU+o6g1C3t8ti5KxliFyT2/2qzfRodfY5F1NpMbwpeOs 3IF5RkGTIwucbY3zU9a3h4c4VvNVuX5wqKqEggSOTtj03/Ws+n1Ce8naSSTlBABZSABg538yNjV3 431G21ngiynsLgSxx3Sc5C8vKwVsZHbf9qXvEpe0F/8AIzRv+irPx1q7XKyMSyk5MboArDP5QBkf M0x1LWrG8txaWVpexyTkOwbldQOfJ6b42NMkkaF1m8Vy5UhzIoIz2xk79vLFTvB+k2eo3Srez+BZ uWZiGALN2Un3Uq2l7Nbm8SMEeUrX9DHXdbuLmVbeBnij8KMTEEg84G/qO3yqDjzyew2WHQqdwase uaRawX8saO08HjlYfaAZwBtnuRS7cPyWunw3uoaeDayPgFfZKY93QdqjNzPSMXLN29tli0fVeIOI NKS0N3byLMuZSsJLRqvRWPQc/LgDfI3q16rwtbaxfi7upJ1lEBhzC5j5tyQTj3+76VG8EiHTtLig tYRPG48VpY3BwT1LE4JIO2OwX52i01CO7jV16uxwFPNhdypPkCBnfzp6XtbF6VIhLtNY0mzsI9MR biLT4szpIxDToFwFGPzY39+K9glfiePxZrc2tnIgeykkAEwf+YYO3p5irG6BgcHlJ/MOoqq6xPNo uuadc5ke2fxLaGBV2V2AwT55I+AqRW15LTGy3j2ski3MOJPFEV1EuArN1DY8mG/vBpDU9NijRZre MRibLKJGBKjzwO1L8QxXLXEEkiiOTUIJYHxkAOmZI2HxB9cGoC4ufD003bHlCqAoO53GaU5EJvQ9 x8j/ABeTfa6f/Qtey6fEviahdvMR0DEKgOPIbmqfqWqxP4qWJKrLlXbcFlz093nSl0LG/cyvqDI5 GAssbAfQEfWmg0sOD4d3Ax7DnXf65rmOZx+hDk57zdJLR3YuINHv5O8nLCCfU5P0zWgfZHactjqN 6R/eSrEPcq5/96ztyyaetmylZPHLtnyxgfqa2D7O7T7pwbaHGDMzyn1yxx9AKvxrtsXhfJL9kWii iirRkKKKKAPO9MNckMWh3rhSxED4UAkk4O21P+9NdRWRtPn8I4kCllyMjI3H6UHV7M++zCyvtKu7 2zv7NrdL2JZVWTIJIGMbnJ2P0q0alwzaXNklu7cphyIZwMNCvXGe4B86jNJtLa71qbV7OJre4jnO 8k4kVkZCPeoJAPL2wNgKtfO0EJMyyMQN2DDf3DNRpJrRNXU35J9mRy3MNqzlCynBBkJ5Sx880xud VsoZleMyXYKDIckb+8VMfaTpxg1GG+hjYW0ygFTEVCOPpv8ArmqSZOfbqAc+RBqh9PQ7l58tamEW XT+FYbuylv7lIrmbKyABucIpBLFskDAGAN+tIaro99aX11p9nLIVmReSNlx40fOvJyqO+c9MdDS+ iX95b2amBXKo6h8lSrAHmCsNjjNJ6nqLtNNJIjPdSMQ6RKYhMDuOYqc+y3LyqPLJO9Uuq2V4sk9N FbzKfZaM5yVJ7kg7/wBKfWH3q2nMccrw+GMyKi+0QDuMHoQM/KiRYJ4ZjAzK6ZeOORFy8a4G/J0f O2Mb9c17Y20z6xDby+zIHCvGCVYEj1+vpXdbXZ6DJy8ObjPzfyFInMl5LqEgYW6yBYGdstzE/hJ7 nGT8q0WPjTTl0X7vdxrIwTABwRVKvpTcjkZne1tiCy7qpRRnmMY6ZJOMHckVWoS1zKxlkeGFmJQf iZV7A+dcqE+0ZHHw1nrw1vRpfDRtZSF8SWO1kkaZjECoAxysM+RyAQN6uUuniPwY7SRTGJ/F5RkM oPXGO2CcZxjbfash4e1ttJDQtdzrGx2DMGXGemOuMk9CK1DRtULWccySc1uNldRhGI6+vz3prCkp 0hXl4s/Gv/Iuhzqc2oxme/jmFqsStEiSDIbIGGx0J5sAdsZp0bmK8aOCZkGJiqFxgyFdmx8cinaz C4IDIhRjjIYMDt3FJW9nbwM140axBFPICcCNep26AnvVos7lzoiOLpQs+mgbmN5Zz5hUjb9yB8ao 97YyXd9a6U04hhHKDJgHlwmSSO4ABqyXl3LrN/LcxRkwGIHfYrbqc597sMj/AAr60nZWV1dzTSTR hcRyBZ5VGF5kKjAxv+Lf3VTSdZEiaSnC9/bKHqFjHbzFYLlbmEOUWdVIViOuB8aj5osu3JhgCcYz tWpzaRpF1p4jfT4GtYQQbtn8MqSd3z0JNRd1LwoYpbiNbO56Kw8V2YqBgKhXYHYd/U1Nwl9iKw1f +qM45S3soPaOwHck9K+i9PtVsdOt7RBhYIljHuAxVH0Thq21IW2o6eumpbrMrPHJpuZBggleZmbf HcVoFdlaJY8bhvZ7RRRUi4KKKKACuWUOhU9CMGuqKAKDZXej6CNRjMzjUITzXCKQWkwwAZQfZUHn x0B3PlTTTeLSzXWqTQfcNJtR4eBmWe5lYbKJD5Dc46bb4qL1KKOT7QdYjnmkhikVVZowC3ntnvkA D1qB1e+++yrHEvg2cKiO3t1YlUQHr6sepPcmqXbT7NDDx1l6R7qnEN/rV/NNJOFSb2BbzYeJUzsN +mOueud66i4buXlAhuLPU4kjZmW1nHMQo3IBGSMHoNzUWLdmB5T8DtUlEkVm6zgGJ5EMYkU+zBOA GBA+Y8upHSqvyLemM5uHLXrQhq+mXWlXMdk6rKxQTARKSyhjkBtsg+lI2emRvJNJqCTpHEoHKDy8 zkZ7HOy74HmMkVMX8VjPpz6xcavdteX0wMkMa8rK/wCdckkcoXAB8yKlH0K40aza0jiRiAxhmkbD 4Lc25G2TsNq7k1K2jNxcdqvkVa2vI7e45FYxWwTASKBY25fLOScY7nJ7VP3VlfWOlWssd6808sp5 o7kEKq8uVHmW7+Qz6VGTWUa30sEkgfw3PMVBCsw946V7dm4jubaGaYeAXLxlWJBJGD7s0u62x7x6 6IO5njbTlEt3JNly0EOSFQ535t9z5dvfSSqCpPQDtVvj4cTXdPvYLN4BdR4nd5pCoz2wT0yMg74q rRxexg5UjI3qzba2bX6PcS6l+xbU9Mm0ycRTtG5ZFdWjbmUgjPWprhbiq84eQWxjaSCd1ZgHHsqT j4fMVAmNnwJJMgDAHkKldCs7WeSZHsGv41UBo42kBjOdm9hT5d6sne+hnn1ieNRl7NntLUQSAjwF CA+zEnKCT3O5Jpjrv9tZJb3K3HtMCTDGWR2zsrJkFh5j03qI07Xp1Ii1GAWllDGojMr8rbbFpC3K SOmAF3pjqfHdp4/hQQ/ewrZ8QOAqdsxnAOcdGPSmXaS7PHri5KrxSJwwxaFYvDc3dvd3U4ZpBLMs JuHxsPa6KBgbHao+81+9sdKuLu40uRC0sSBXmjCMCDzMhXmBAwNj1qiX8FvYqk1nEtzbXAzHdTKX fPdWzsHHf596jTJLOcMxY9h0A/aqvya+hxcSa+TrZOanxMt7I1tqL/xi1LB0UxCAwnHYjPT1yp8h UfaRy39ykUbGRCQFHKFCr6joNvhUetuGmAdgB3C71OaZEFS4eMcuEEKkHBDMCSR7gPrVLyNjT4/h Da6RrfDccacP2ZiUKrxh8D13qUqN4cYtw5p7Hq0Cn6VJU2lpaMKvZ7RRRXTgUUUUAFFFFAGQcYs1 txvfmPHP91jkXtlg+d/mKr2rFP4nM0ScsUnLIi5zhWUMP1qx8dIP+uJMHBazJPr7S/7VXb2MvaWs +OYBWgbHXmU5H/i4+VJ3pUn/AGbHET0mhtHKYg0pHNykco7Fu39fhTm1dHVrWUnkmwCwPRux+pHx plN7BES7CPOSPzMep/b4VwCRkbHIxVbW+zYl+S0z/9Nne6a9/cwyJNYfdyyxQW1pPzOiZ/AIiAxb qTtuck1ZLkrfX8thd6gYr29uhO1rGQy26hcCPnG3PhRnG2fnVWi1xdPgP8LtjBd3akXN5IQZScbq mNkXv5n4VGpMVIKkgjcEZyDSdNNaR6aOHWXuukvRO6qi8622lq0jlSz4GCPMAdtzuaaIkUk1tzQq 7h1i5GY4btzEjrv393Wu5NXiubG1gezWR4VJkllYhnkJJJyp6bjb0oi1GYSI0cUHMuyr4YIX3CqG tMjPBy0t+h/rCadNcLHE8k0NyoeRvDClYwTy8x7ksBjocdqqM/jALy8zlfZAbOVAPT0qbuZOclX9 osQXIAAYgYAwOgFc3SLKhuQrc2yy4JBxjZv2NcV6ffoajhVMa2QFw86PyS28iPgDlKkbY8q9tJrh JcxtLDlcFkZlLDPpVh1i/fVrpLqS3CyiJEdgxIYqMZ9DjFMOQqMhQMdqYdr6Ksf6ZkdLJkrbEFjJ OeUkncs7dfnTghEGQ+wAyAMnP6V4EJH604sokVmu5QGS3ICK3R5O3wA3PwquqSQ88ClbHq3q6Xan TZYldLxSblZBurEex06Edf8ANUfGMhgwC47dKQlBZmZyWLkkk9Sa8WUgcx9o5wT5muLa9lWOIxvb QrKMMWBwB3qbsmVDaWXJ7SoJJT3Lv7WD7hyioq1t0u7uGKclbfd5iOoRRlvoMfGn2mStPqnjuPal k5yMbAk1KdeXf0Kcy21pGu8OLy8O6ePK3T9KkqZaOnJo1kvlAg/8RT2nl6PMv2e0UUV04FFFFABR RRQBj3HcgHHjKGzmyYkeXtj+lQiSP91uVROYryzJkjCsoIJ9dj9KkONnLfaFekkexZAADr/eGoqC 5jtr+EzjmhQlJl/mDDD/AEOPhSeXtaNjibcjBsYx07HNcNnsa7uYmtriW3k3aFyjHzIOKT3HWufW zXik0KRMXbw+7fhPk3b+lCvk4O3pSeQO+PKnEgDqswAw2zY7MOvz61F6TL8be9bPEl5WI/WniyGF DvyyOM46FVx+p/SkIo1RDdyJzICQin87Y/QdT8q8DmXJbdick+ZqttNjSVU9L0Lq5G5IyPM0ot4E KsRzA5DD+Ze4puU5l9r/AIK9dByjyrrSfRdXc6FbkNC+FfmjYB0b+Zf69qRec4wTvt0paFPvMLWp 3k6wknv3X4/rTEEk9CAOoI3ojrpiqy1/q/Y5hEk0ixxjLv08h60rNcK5WKL+5jGE7Fjndj6k1yc2 tnv/AH06gkA4Kp/U/pTcHG9CW3si26e36OpATvXkADMIzsJNgfXt/wA9a9dxgZrkKxXIyx6KF6k5 2+NSe2iu0mnslYEMWlzyt7LTN4CjocDDP/6j5044eTxdVhBJAVuYkeQGf2pHVYzE8dsxDNaoIpOX YeL1c/M9fSlNJQpJcMoz/wBtIB2GSvKPq1Rnfg3+5k56bx/2bRZxiKygjAwEjUfSl65UAKAOgFdV pI8+FFFFABRRRQAUUUUAYnxs7Rcf3kqqCosxkt0z4jED5j6Gq26/2aqWyQPaJ7nvVp+1S0f/AKkc xZDFEmUdmO4/Y/M1T47lbhcjZxnmXypZz3s2eHSmex5fozCC75si5iBY9w6eww+gP+amLO3XqPKn sbq+kXEbdYJFmB8lPsN9eSmTDG43Gd6rjrpj8ptdHpcHocelPLJGnZrdmKo6gsdvZIOx/b40yCFy AoyTgADqTTl2EcItkYEA5kZfzN/QVG+1pFydPoUmuOeQBUKRqOVEPVR/XzrnmYAMDXMnM/LKNw+z H/F3/rQHAXBFRSWtGjgy6nQ4WY433xXLylu+1IhgR7Jx6V0ykDOflXEuxp2mjouVwwYhhuCOoNP2 SOdBqT4KjaaMbcz9vgetMI42mkWNSAT1J6AeZ9KcJfRxzCNQXtApRl7sM7t7871G02+vZm8i918R vNM8rs7nLMck1zk8v1r25iMExjJ5hgFWHRl7Gkw22KtWmuiO9roVZsrj02qR4fKJdveyqTDp6eOx x+fOIx/qIPuWoxSuMsem+fSpC5lNhotvYBSkl233u4zsQOkan/L7XxqN9rS+xXLT14/ucI5eXErc 3jtgljnL5yD8TkfGrRwvbpe3/wB1b2s+GxUDoPFQn6LVJnkCW7OzBRkFc+YNXz7L42uNTutQdjyz pGVRuqkBsj5nPuqXj6X9Gfy76ejUq9oop8xAooooAKKKKACiiigCm/aJw7Jq2lrfWiF7u0H4F3Lp 3HvHUfGsXmhWdzKh8K4HU9Fb3+Rr6ZrNeNvs5ad5tV0NCZXYvNaD83myevfHft5VCp36G+PlU/Gj M7CblvVtrtTGJ1MLk5AwwwD7s4NJDmHMrbMpKsPI0O7qGhnTJjYgq4IKHPzBzTqa2ikuRfeIBFN/ aOh2Jfuuff8AQ0s3qjXiteuzlR4EKyHaWQEoP5V/m956D51wjgrvsKRnnnWUyXCH2u+NvcO2K5Wd Dgk4zXFPWxiMiXtn/9SqwEuTGDjnGxPQN2/pQDkbjB6EeRpuk0ecA48jTufldVuEO0uz4/K4/qKz mmme2ikntP2cgADPSveYY9nvtSfMcbGl7Z1t4fvLDLnPgg9M92+Hb1rrekX1kSXR3cEWkDW648aQ Dxm7qM/g/rTINg4716zFmJY5JOST3NJM6hye3apzOkIt6e2PYpGuYBbscyR5MJPfzX9x6++mxbI2 NJLKB0Jz1BG2DS1y6vbreRL1blmA6K/Yj0P65FcS0yqsiX2L2EaXN7HDL/cjLzHOPYUZPzxj41xq epi4vZbqQgyyuWKr0XyHy2rmI3EWjyMvKr3z8uWG6xocn5sR/ppvDapE4Zvbk7FugPurspOmxWsj fYrb2rXcgnvNkG6Q9C3v8hWu/ZzpE0FnLqc6lBc48FD/AC/zfTb099VnhDge61iSLUNRUxWJGRvh ph5DyHr8vOtajRIo1jjUKiABVAwAKYiftmXycqb8ZFKKKKtEwooooAKKKKACiiigAooooArPEnAu jcRq0ksP3a8PS5hADH/7dm+NZhrv2ecQaKhMcI1G1Ul/EtweZRjunX5ZrdKKi5Vey7HnvH6PmFJn QMquV81PT5UoGgcgy28beq7dq+iNU4e0fWoymoafDP5MVww9zDcVS9Q+x3TJnZ9O1Ge1J/CkiiRR +h+tVvG16NDHzpfVmVrb2uciaaMdMMoYD9Kc21qjJLb/AH+N1mA5AUZSr52PlVquPsl4hgY+BPZ3 KDpiQqx+BGPrUPLwVxLbOVfR7liD1jUMPmKqqKaGlmwWvZHW+lTGQiaaBo4ziTkkOc/y79z0rubT 9RupGYG3QqgIRp1XlXOAo91LXul60eUSaTfqcAtm2YczY3OwpvBpeo8zK2lX0hxjaF/Z+lcmab3R LzjXb/8Aoz+63IJ53iHYjxAf0oEJBx4ik+mTUjHoGsk4j0XUGyf/AMZ/6VLWHAvFF42U0x7de7Tu E+h3+lT1R1ZMUrtlc8HICtnboAAtOLIrDIUPKsco5JAd9vP4davdn9k2oynmv9ThhJ3IiQyH5nFW nSfs44f01QZYDfSj89yeYf6en0o/G30xfLzMSWk9mV2elajxFdiHSrN5o4QIww2RB6sdgT1860Th v7M7XTpFu9XkS9uF3WJQfCQ+ufxfHb0q7xQxQRiOKNY0HRUXAHwFKVbGNStIzcvJq+l0jwAAAAYA 8q6ooqwWCiiigAooooAKKKKACiiigAooooAKKKKACiiigAryiigAxRiiigAxXtFFABRRRQAUUUUA FFFFABRRRQAUUUUAf//Z ------=_NextPart_000_0098_01C29330.B7655560 Content-Type: image/jpeg; name="clip_image006.jpg" Content-Transfer-Encoding: base64 Content-ID: <009201c29363$018405b0$66902244@ROSS> /9j/4AAQSkZJRgABAQEAYABgAAD//gAcU29mdHdhcmU6IE1pY3Jvc29mdCBPZmZpY2X/2wBDAAoH BwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8 SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAD6AMgDASIAAhEBAxEB/8QAHAAAAgMBAQEBAAAAAAAAAAAA AAYEBQcDAQII/8QAQBAAAgEDAwIEAwUHAwIFBQAAAQIDAAQRBRIhBjETQVFhInGBBxQykaEVI0JS scHRcuHwJGIWM0OC8SVTorLS/8QAGQEAAwEBAQAAAAAAAAAAAAAAAAIDBAEF/8QAIxEAAwACAgIC AwEBAAAAAAAAAAECAxESIQQxE0EiMlFhcf/dAAQAKP/aAAwDAQACEQMRAD8A2aiiigAooooAKKKK APKKoepesNI6USA6pJIpuN3hrHGWLYxn5dxSXqH246dEzLp+kXFxjs0sgjB+gya7pjrHVekalXhI AJJwB61g+o/bJ1NdsRaLa2KHtsj3sPq3H6UrX/U2v6upS+1a8nRu6GUhT9BxXVLZafGtn6iBopF+ yXXH1XpMWc5Yz6c3glmOSyHlT+XH/tp4d1jQszBVUZJJwBSta9kKly+LPmaaO3heaVwkcYLOxOAA OSa42eoWuoRLLbSB1ZQ48sqex+RpA17ra01qF49PvVWGGTIUFcylGBzIp7xHI4HLfKqCLrG30O+n nbUInkWXc5to3XxAy/gWM5UKjdznnPHNLvsdYm0bRRSr0l15pPVKiGKdY71Vy0ByCR6rnuKaqYm0 09M9ooooOBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHlUnVvUcXS3T8+qSR+KyYWOPON7k8DPpV3W M/bZrgm1Gy0SJ8rbqZ5gP5jwo/LJ+tdS2UxxyrRA656vtOsdOsopLCS1vYR4qHxAyFWHI9c8CkmP TJ5CAqHJ8q66gGGn2F2nBClc+4Of71cRdRRi1RbdEhO0Aso5J+dbccY96o9zDixy+DItv01KRunI iXuSxxxUk2uk2CkyM07D+XCjP1qvudUlmZiW3Z8z3qvmmZ8lieKq6iP1RerxwvxRo/2X9Qs/W33B I0it7m3cLGgwAy/ECfU4yKd/tB1k6XZQxu6pHcEqoYblkf8AlYfy4yT9Ky37INjdeG4kYKltZyyM x7KOBn9arOuer5Oq+ppLqNmFlBmO1Q8YXzb5sefyFYKau9s8W2rz8mVt7FeafftKxIkY5LDsR/iv Lq5W/YyhFRz+JVGBmpllqEc8AtL0b4eyt5p8qiahpclk4kQh4m5SRexrRUaXKPR6blJco9Ea2uLn TruK7tZXhnhYMjqcFTW/9AddwdXWHg3G2LU4FHjRDgOP519vUeVYRaTWkgKXiyZ/hMeP717FfnSt ThvtHllimgYMjtg4P+MVCoWtpmPPhm52j9UUUrdGda2vVGmwtKFgvCoDR5wHbHOzPcD9KaakeW00 +z2iiigAooooAKKKKACiiigAooooAKKKKAEf7QOvh0qkdhaReJqdym6MsPgiXONx9fPisI1C+uNS v5bu6neeaQ/FI55NbZ9q3Scus6bHq1hCZLyyVlZQcFoiCT8yD/U1hYHxe9PKN3jKdbLWRPF6aXnP hTHjPbI/2qkil2OVzxV/pqeNpl7BgHKBx6gg/wCCapFUNNggHgCtGVP8WjdmT3LR1STdxXKWTaD7 1caxa20ENosUKxuYFLsufiJ55qiaMyShFbucZPlS2qjpiZucLizrYaneacLk2kxi+9wtby7e7Rtj I/So6EVMudPe0IjkUEYyGU5B9wajeHg5Bz86i5afZm+OpfZ3jJGKtLHUWhBhmUSQPwyH/nBqnDAD ngivRPk4HerRk4mqMvAt73SkCC5tXDQE8knlD6GoDwN4qibdGjH8ZU9vl51caLb4iN7c/wDkRklQ TwzDyqv1C5a8uWkZixJJ55quSE55f0vcJzyX2Xll1aYbi1Cp4AjjW2W4ABa3i3d4x/NjzOT3Ffoi 3kSWCN438RGUFXzncPI1+Th+Vbh9kHU37S0ZtFuJM3FgP3WTktETx+R4+WKxudI8vyMelyRo9FFF KYgooooAKKKKACiiigAooooA/9DZaK43NzDZ20lzcyrFDEpZ5HOAoHcmsW6u+1S91id7PRJHs7Dl TMOJZf8A+R+tdS5PRTHjrI9I0HrbqK3ttLls7WbxLgsBKsTDKIDk5Plnt9awXVZkmumljgMZLEsC 2RTXYsBoMzZyTnJPJJpUu8F2z3862V48wlW+z258ScUdPskaDqFtbzOl1IIldGGTnB+E1VW43XI9 c9jXKZASCD59qn6TF941SFB/FIB+tTTqqUslLqrUv6JvUbbb3w//ALaKv5Cl9JMTd+auddlEupXL jkbzj86oh+LfnnOMUZ3+YvlU1kGGxvo/C+63ieJA3b+ZPcVx1DSXtlE0J8WBvwyL2/8Amoi8oDnn FWOm6m1sTDKPEgfhkPY1WWrXGjUnNrVFKR5MK5SJtAIzjNMeqaQgiN5atutzySf4fY1SzKv3dto3 EHJIGcCs+TG5emZM2LjtM4LLIqbVZgD3ANWEKA6XHMykKJihbPc4B/pVYD61bDJ0W3hXJ3ys5GDg HsP0rOqf2Th9ndtLl8ESbNpbJVc8kAZP9qsOnr3UOj+orHVJLeRIyQHBQgSxHhsZ7/5FXF1e2Sah b27KFMEZLMGIwSCeffkCpHWl5E8djYi7DS2FmsJjaPs7qDge+PP3rW5Wh671JsF/1HpGl2Nte3t7 HDb3TKsUjchiRkdvarCCeK5hWaCVJY3GVdGBDD2Ir8xXurX15aW1pc3LywaerJAh5Ck9/wDHPpXX p/qzXOnLhRpN2wV2AaBxujbn0Pb5jBrG7SejJXjNTs/TlFVuiaomqafDK0kRuNg8ZIjkK2OcZ5xn sasqf2ZGmnpntFFFABRRRQAUV8SKXQqHKE/xDuKqZ5b+2h3STP8AgChgqcyE4H0rjejqWxC+27W7 i3srHRYGZI7otLORxuVcAL8s8/QVkEEgU4wOfPHatl+07R31jRWuzK73FiwWKM7ctx+8GB34wfpW M26qZQJCQueSO9Uh9no+N0lob7eYR9KyPnIMgABHGaVZ5NzkjzNWE0UkluscczGIHIXcduf81WOh RiCK2ZbdJHpZrprRxfJPA881b9Mhf2rG7MF25bkgdhVSWOcCvNp7Dv61nl8a5GOa41yRJv5d7u3f LGq9RlQB3zXV/wAOOc18AEfF6Ult09kstOq2fS3Wxtp8uK7JOG486hiIueBUqKLbgAZPrRLrYY6y NkiS7uZLVrRXKwswLKD3I7Zr6jW/sdJuljIW1vgscgYAltrbhtzzwR3FWFpp8VtbC+1AFY//AE4u zSH/AB6mu+n2w12a8urudIorSLKw5xuzwAo9B3P+9UySkt37LZomZ5X7FVMBwDzjyps0WC1uYFnk dFFv2ViATg5/XOKUoVPjbW7gkHNN/R9jHqWqabbPllm1FFZccbVG88/IVia7MsWlOxzl+zS/Grtq EF/a3Zd901u6tGVB7qDzzjOO1UOtdFdVtPd3kukmd55i6i3kWQqD9c8DgcVrl5pKXniiSWVRKytm J9pUjP8AmuB0zUIp3lg1WQbySElQsq59Of7UizV6FVNPZgN/pWoWCAXdjdWoHcywsoz8yK+LC2Z2 aduETIU47mtv6ofVU6R1C2upone7ZbeIxAgKrEbifpmsr1CGK1228C4SNcDPmfWtXi4eb5v0jf40 vLun6RGsOptS0m4R4ZiwjcMASQc/Pv8A2rWukftR0/W5Esr8i1um4VnICuawyY/EfnXyn4gfTzp6 hbJ5sM5GfrIEEZFe1kf2a9fyJLFoWsTFkc7bW4duzeSMffyP0rXKm00zysmN460z2iiiuCBXN4kk xvRWI7ZGcV0ooAVb3Trq0mHhSMAEFvaykLlS7Zfd8J4wBg+Xp51iHWmhroOuvHArCynzJbsSTuXO Dz58+foRX6I1KC8nieOFgY3XBVSVYf8AupB1vS7TVHNvqdkVDEQwx7ShXHmmfwjvk+fpXd6NOG3L Mft7toTwcjzBqRdTwSwZHMhGAPT3q11/pW1027WOyvnlVsYEkeT7nI8vpS+Y/Ddhndg4zjFWjI2t HpxldLR8BQOK+WwK+2O0ZrmQSaHpI4+ukfBUt2rvZ6fdanfRWFnC0s8zbURe54/xXxjaM1pf2S6H Gv3vqC7wI1VoYGBAKtxuPtwcD61NrSIZdTIp9SdL3+hyxyXSBfGGWVQMxnOMEDgZ8vrXKzsYLG2F 7fjORmKHOC59T7VsN1qts92dNFqZ7aQj70ZpV2lT37/nis+1TpSbWdWuf2ZdKyxcBLh8gewYcYrs ZYxrbO+NmSX5exYP33XtSVEUtLIcKq8Kijz9gBTEnTOoWGlb7ezuJtwYtIiBiq5x2BJ59h9aYulO kn0OWRNQVZLiRDI7Qscqg/gB45yMn1wBVxa2UkN5Jdabb2s1pIxaIQoEkHHP7wfxez4z61jyZ+b2 ieavkZhbxslw3iZVjkfEOc5rR/sntXl1NZTEWNms8ioeBvKov0PxGmPX+lNJ60tlubdzBeq22WQR 4YN6Op7n9aldEdKL09py3MaOb+4QC7YvuBIY8AeQpfkTXRJJqdDZ99Kj44HjPpI6KcevLdqjrqF1 NKscENuzbssRNkFc+w9xXkZfK7nm4PBAUtjPqRnFSWsoQ26Se4JIAw07AY+QIqfSXYvexe6ymk22 Fs3J+KV9oOCQMD+prLNbcmeQ5GPIinDrea7n1SfTbUSw2ipEokcMsZbBOVfzwXP1qh1K0sf2ct3d 3KL4soiZ1QjY23JJxxg+XyNejh8yceNY9HpePnUYuLQlS8saI1JYADJPYDzq0uNF3FnsL21vYwMk pMob8iQTVcikNg8Y7+orqtX2gVKntGydA/ZoNNMWra7Gr3Y+KG2PKwn1b1b9B860ush0TXteNrZX US3txGY1YlZWZSRwQQfLjyrW4n8SJH7blBqE5Oba/h5WdVy3TOlFFFOQCiiigDylDqi5kGpKu4p4 SZQhse5P9qv9V1e20m2Msx3PjKxr+Jqz7qTV49ddZGsEieMYWUSfFt9PlmkdJdFccNvZ/9Gq1tbq VJLm5kDSyORlWycetJtxEY5DntTpNMttbskixlSedxOSaXpYorufwokdieFVOSx9BVFmwxH+nsLN ix49fZTOPhr4RfPFWuo6W+nwxmdHhkkYgROQSoA8/eq7b3pk1S5IeWrXJH1DCZpVjHn3PoKY7DUZ rWSGCKVlt1cMIdxKkgY7ds1E6ZeNri7tJlyskauQMgttYErxz2Jpqh0S13tfWdoZooOWKgEKce/e sOfOprQvFZPv0VWvXst3eRyeCAAv41Qg4x5ntVz0PcA6xIpB2yxk/F/MME/3Ne/f4riZZLWyWZAh BVgec+ePLArvor2a6/b3KKo8RtjBQTncNueeeDistZ1S00FePxW0MXVAuraTSr2zWZis5ilEYBXY RnL5/hGPn6VYW0tjs/aE3/TMQFZ5ZBGjenfAPfivdflZNBulslaa6KAwR+EzfH2zwDnHesssei+p +rNQWTXTc20cIAaS4BLt/pU+fvwKpMy47MS2zSr/AEez1u/kW6uPDjiRfDWKRQWY8kk87uwA+tWF jG1hYWtvDEZRsIClzkkDPnx/QUvW+mdM9L2k1rpsG+9hG15IyHlViP4mPwqfbH0q80u48a7MiXKz xhSuZXCuo9kwAOfz9aVLXo622jpquqy28Q8OAKcje0zgKo+Skkn07D3qTZyHVNGW+tI08UjKq/IJ Hoe+D3FVOstqK2t4dE+7SGNtzQDkzHAynHY4H17Usaf9o2g6hMsF7o8lpO42LJHKApbyXI2kenPb 1p0k/aFaeui6j1q9uLyOyniieK+YwmMjKo2Cex7jA5oP2dxX2nXcclxhpFDQwp+FWxkbv5hn9KYt L6e0YIl7ZoGSQblIlZgcjHmTz5VYnNtc8D4TyMedJMcGqoLyKtqej88XNo8Lsl1DF4iuVdCgypzj A455HnXhhjngYCFFaMEl4lUAH09cVov2ldNvHP8Atey2rFcczjO0bwO5OPMfLke9Z48gMS7XZgF2 sAOAPfHc16UtPs8xvJif4s8sI9W+82traXdxClxcrAnhTFclj3AHtX6TjQRxrGvZQAKxboiw/aPW +kIS22xge8cMcnLcL9eVNbZS9b2aXkrJ3R7RRRQcPKqtZ1230qFgWDTbchPT3PtVoeRSCunSXt/N unLXEb/GsqZVuefeo5sqxzyY8TyZymgl1TTrm7urpxLwy8gBj5cEduaW9Wtk0l4455pLmeVcxxoc 847Y8/WrbW9Vkjv5oYxHHBY2zTz7VJLEHjAPbuKzxr69vJ3vbmZmmkJJLfwgnOBXmR8mR8mzUlkn 8afR8Pfme5aS6S3YDgKFZgp+hFW+nwPeXCxQwxwrGMiSEFWLEfD3z/zypcZHmkkXbwXDZYEdjWhd K2sVtd6WY5FZbm3JdSOSQCSfzOK0XpaO6WmK/Utjf2Ahs71F3SMGiYsGZwOPnj8qoPCkjZSq/ECC AwyKY+rb+6vur5UupVW3tJzHCFwAq559yfWrfojR7a+s7vVr6NGjkJjiWUYGxRkn8/6VsWVY8LbO 48qWJr72UvTOn6hrOrnWFRRHFLumlGAufMflTj+1bS30C3stPZZHkyZlTnaCTkk+VQZoZ9jW4nWG yKgCCJFjU/F6Dvx6+lIUBu472eCO/kt0LuCxlKhtucA4rA2s/wCSY018aW+9mlRdOv8Acn1HT98M cYzJvwPLt8qg21ylrYvcp+OOVXlLMpA+LdxznyPlX30xpl9qXS2u6WLudnieJ1C5yxwcryfPj8qW uk549L1TURdQLM0CqfBdQQSrcnHmRnNd+LU72UXk1T4s2u7aDULOaz+F7dwVkzyrDzFLvV3UB0vR pbfTJCLtkAWRSAsIP8RJ4HB4+Ypm06W3udKgu4VO25RChYAEBxx+hrLdYv7mLqGysruJJbfx5Q7X dssiA7jgqTyuOAMEUyl9bM8JN6RF0YTWVobQM0bo7SSyHJ3sfPmrmI3n3cYU3DMGPhohYqB3J4x+ RNdrNJNRkVY4R4KqVd2JBYeg4zj0q40zSFTUIJZFVoxISNqnOSCAPyNCe60abaS2UfT2oS6XdSxo DvmQskXYMyjP5kZH5VXdZdNwXezXtMj/AOh1L4pAAAYJvPI9GwQR/N860HU47Fboyx2ytdKRmRe3 v8ziqnSdY00az+wG8GS2vLRpsKQVDgnK+3wjP0p9cK0mR22uaRU/ZLr94s0ug3TeIixF4VPBj2th h7jkflWnTKLhChUq45GaRukejpNE62v5zl7QQbraQ/xB25B9xj+lPrfCyqrFe/GM5/xWhJVPZlyN ctyQbiyjv7CXTr5A0U6EH0+nv51jOo9PXumXt3auyk2qEs7sQPD3ZDfM54Fba/hxRKpLA7hk99p/ xS51xoI1bSzdQg+PbkF1X/1FU5Cn680Q3jZK4VrTKT7KrRJtU13VgpwHS1iJOcKoyR/+taVSF0Fd 2PT/AEVaJNIGurhmnkiQ5YFj5+nAFPME8dxAk0RyjjIPtVUDTR1ooorpw88qWdcvf2JfNKIQFuQG Eg4ww4P9qZqpeqtMj1PRpUddxj+MAfr+lSy41knTKYmla36Mk6oS4eG9upnZCyEopQktk9iRwODn 6Cl2cKgVVY4dgFx61qM8UWoaJcW8sYiiKsnxDcwGMDGKzaSAQbrK8tiJbc+HIrAghh2Pr2wawYb2 tNej0/IfJporpPDVJGGWKYx8RIJP+/FP/TdtbWH3rWDEmyxsYkhAZiWZxlgfQ7gB9aQzHEkrZVAV YBQ2SSM/i9+5rULDR7nVbSdgBb292wEcqRhS+w/iI55ySR/pqzTbWjK+pYq6d09cdTajLezvJHCG Z55MFgSDkqme54IJ8qt9Uv5YWNrYxLDYQqkcClc8ZDBi3f4hj6cd60Ow0aysLCC0tSFSJAoUnJ+v vSld6B40JMTMJhbCMQsOFAGBnzGQBUa53XBr/hXxKwzTeT0ddbS3TR4QfDWXeWCqDyxHIB88ZFY1 qKuutXUch8N1mIJ7bQTmtdvNYsb/AEuC3RXjkjcRlWjyDJjHBHyrMep4zadVpJuCmeCOQs3ZW27T +oNL4WPJj3NrTJ5qmoTX9GH7NIrW61DVNOfVvu8moWbQx4BLMc5J79xjt5jNL/TjSRdRSxAje6Om ZRwBleT9Ksel9aOi6rbySXtilvHPHPII48s6kYPI7EAnj1zXO1thd/aLqMaXJnBeeQSqoXeMZHHb GDW6/wBGSx/ujbukmD9K6cAclbZB9VGD/Svi00yC4N4Z4HlAuGUFWwQO/wDeufRErN05EJJDK6SS qzt3J3mr22QRRSsB3Yscef8AzFLMqtbFtuaehdvdL0y2mWEXMsTOMbFAJH5cjuK+RpBtrV/C1NRF AArKzEiM+hwTg8100Ro7rUbzUppgUBLKXwBGP/ivq3srUymSUeGkccjQxFFjLIVwx4OGBJU5PIPn T/Djb3oPkpdbIUelSxxnw7q3ZCg2kE4GWH64qkvdKtNA1yLUbplZoxHGQmBHGpcHPYfU+9N3S4Wa 0mLEMofbt2jafRh68YpJ+0m4DLdxAgBmUFcfiAZRULxqEtfbLY7q6csaej5rkWM1nJcLNHb3bx2s yuG3Qg/Dz58cUynIDFeHQkjdnkUpfZ4kv/hK1VdquxabIk9ScArTakqTKGKOjLwQylR7/MVqlaRm v9j62K4DsoYNjjgjPrUG51K0sstczwxBh8QkcDH+a4an1BaWNjdXJkVUtlyzNwOe2PrxWZ2N83UN 1NqWpv4MUbEW6mcbmbyPh4yT35JwPSp5KS+ykY21tmiWNjpMoltrdLdo5A2QhG7Ock+ueRUvTfF0 64ayl+KFjmKTyNZ03TmtpMdXs5PBniG63R8AAAZCgnG7gc5znnNMGm6/da/09bTzp4VzDlZwBjMi nBPt2zTY7mvRy4aH6ioel3TXdkjSf+Yow/uaKsQJtfDqHRlYZBGCPWvuoWo6nDpcImninaPnc0UT SBB6nHOKAFJLOe3u3gjwXjdlQM2BuHIY+XbH50mdQ6T94v54onL6rEviyMZNwlU91PoR69/LFW/V vVumXurRDTb797t2rLGco44OQfIg5BB9Kq5rS517qWG1iDF3A8UuQGKY5YkeR7VDFhiMjdPp/RoU 5bW19HbpTpj9tXEInjY28e13LYIz5AMPX/etcjtYooFijQKqqFAA4AHbio+k6bDpdlHBEoAVRkgY z71OLAdyKpMKfRO7dM//0tNvNPlXe8AJLAjGSSp9R6/Kqlb57dmgvAMy8GVUIGO20k9jUiZ4otOE zuWvN5ExaUrKp89vkAO48iBU2W3tNVgykv75FBJwBJGcfxD19j2riWq2U31piVqn/wBMIWKyHgF8 RGNied2Rk4x6flWd9cNGbyyJgYv4LIQwOCQxIwfP8X9Ke+prPUemWttTRnubWBwkqsxKsp4+Q8jj HB9aVNa1WC9jeWxXcsyZZGUEwk98H14pM1t2n/C0KODWxdsGkgtJZoNPWaSRAq8F9gz+LHOPIeX6 110ax1YdQwSJGLRixLSy4VVQ/iznywe1WXTd00ep7/DD4TLJgYYA8/pTSkkF9qM0UdowExJwwGM4 5x5ADg1ky5mvx0W8fx1klXscPs/DJ0swMm4NdykMeCef+fnTVDua0IIJJBAAPJpN+z6MW/TUyZyg vZgBnPpj9R+tT57TWP23b31vcmOxEqmSMSnLIFxgqeBzz/wVTG06X/DPlT5P/pFspW027uYNTt2N tMxJQqshJGMcAfhx51P1PWYZ9sWmfvHbKsQpO0Hmokuqa5bXoMmWRiGQtabwgLPkbl9FVR82ryPX 7uKJWTRosFzuPgNHtO0ZY59z88e9aNdExi0S0Sy0iGJAm1V4ZeQw8j+VZT9oEsckCybs3Ekzbeey gE9vnin+z6kubx5oHsVhiW2lkWQE4IVgoGPLnP5Vl3XzyPcWkEJ+MwFTkgBS5x/QVny7dykX8fpt mp9HKI+nNMAAWQwhnUsR8J5/xUTqLVLVNQW1huAkkx2sN23ce+B6/L5Ut6j1xY6bdLaadGb5oAIy 4cxRRgLtGScjHGT2HeqjStPXW411SOdJr03zxm5lLGMqF3HanfHPHnwTSq8nxvkNMSq2xh1XRjrW mS2kkhjLKNjgkBWHIz6jIrr03EtzayyR26HYwViY0k5x6nByPnzmrODTVu7uKGY/fIYId/jDAikc nHxc4JGDxUjT9Lh0iS5mglKNdsu5o8BeOAqjPB5zn+1TmHkrTXQ15Ep0gvobe03eCoKSKSIyx4Y9 2GMj6Ul6v1Oen4prOxEZmLFgAM7SeST758q79edZhbtbTTWRrhEKzTJg7T6DHn7+VIulWEuq6zaw SZAnuEV3bJOCwycnuaaI4ZHoz1kSnX2fobR45YtItFnAE3gqZcDA3kc/rRU0DAAHYUVvIHtL/VvT 1vr+m7JpbiJogShgjV2JOPIg+g7Y+dMFFAGAdWdF6romn2upXUNpvuJFV0h3blbaeCSTnPse+K7a R1VN03fJcxSvdf8AThbiK5QjJHO1X5xz2p9+0BdU17Tl0nStLvjLHcrI1wUCKoXPKkkZ71h141yr tb3MzK0e4Oihh8WfMHjypXO3srGTimv6forpjrHS+qLQSWMpSYD47eXh0/yPcVdMxJ5XBORxzkf3 r8s6dc3UU6PaXj280beJE6ttYHHl74/OtR6R+2SOQfc+qEEeOFvETg/61HY+4/IU5PpmnzW8M/Fx CkiFSuWGT8gaW+ptKuILEJYXBjkvriO2VYiUPhkktznlyC5yT3PbPNXlpqlpfz4t3L/uVl2kYLRt +Fh5EZB+VQOrNRs9LOjXN5OIo01BTlsnjw5M8fWh+jq3vSFPUNftoej9f0+//dkSvb2sTtxjgBFB 5O3k9qyl5Nj5gfGfPdg08dSW+ja3b3d/aSA34vLhlR1aPxoy+QQSMZHPBxntSH+6JHwt7Vmt7YXN T7Wiw0a5A1i1csUBcK5UgHae/PyzTTcpa3N7K8lzus1BMWSEOCO5weSPTzpPtpI7CeK7ESzGNwWh lOQy++O3FXmodV2UyqNM6etLQrjdLKvisT/27uAPpUviVvZq8fOsc6Zp3RDwjpoNB/5bXEmARg5z /sKvoWiM5PjReIhIEbSFeCB5UtdBvPP0hDPcSK0kk0jgqFAxnA4XgdhUDqS+tLa+mVrpY5wiAISC x444qbp466BT8jY5lJwWIAlU5wrMWAGP+6pEaSFyZEOCMlVVSSfes/fVbSG3aaGa5yEyI1znd9Ki QdXX0pYWktzKQgkChjjaffz5qk+Q39A/HfrZoOpPLB07Is4AY/D8K7RjPpWH9TXQ1LqG8eOVRHCV iUZJBbsP70zdQ9Y3cMlrZhLm4WfcXEpIK+mB596zSC8kS+ZowxBfeckls/Mc+flTSnb5Al8a0x+g 6U1GUWscVlutihmUGdBI54zKc4OO2M9u1TptOl6esG3vPDbmXxgEnEkiOVI3EjtkenvUno7rOyx9 z1a8jhuIISiyyMI1kU85U4wCRgnzJqt6h+0Gya5On6WWls4ySzSxhlcgdl8wM4H1NTvFka6GnKt9 jdoXV+njRDDdTi3SziDTySuvxMWIC4PLEqM/l50n9Q9c3Opym10/fbWgwGkX4ZHX0H8o/X3rOV3X EqqqMRHk4bgZ86nw3BjdUvkZWI4kDkbh7itPGpnSMtWm3oss3VtG0yYMJYAkYwTjPbuK7QamEcSJ M9q64ORlhuz+IehrrYNBc/8ATq4ZJMK7RsAQM5/i860DpHSembEwQ3ekvc6mTuWUxmdHGfxKR8Kg ZGc4IqUrbEY1dG9R/wDiTRhcOpE0LeHKwUhXbHcf84oq/RVRQqqAB5AYorUujh90UUV0CLe3D2tp JPHbyXLouVij/E58gM8D61+fvtA0zUNK1iWS+aA3N+TeSLBk+AzE/CCe/bv51+gb61e7tWgju5rV mx+9g2hxz5ZBH6Vj/VHRVzqHUNxdC7e4tI1A8QytI+ew3ZzzkNnGMDbxXG9LY0rb0ZWkZZWUHLAZ IHbFdsSQwqT8JyWQHB9Mn+lM110hfW5MdpBHKA4JdGILKe4Ocfliqa9sLmxxHMFhR1KocBtwByeR 2Oa5Ny+tg4pEjRuqNU0C4gl0++kjaMEBGJdNrEFhtPGCQDxU+/1vV9ejtJrn4o9PyELbiGy+c4Y9 +w+QqosbqO2t/CW2jaYOSZiDnB9PTH/BXd7yRxtDlUCbVDcjHufOuVX0cTaeywTXbhIJLcr40bnc qEnCsTyfrX2Dpj6NLe3ka217llCxF2EoxkEqBtXnjO76VUFdirIJBkZwQcAGuDrvLyMfjbkeg/3q UKU9sest1PGvRyjld5GLn2CjtmpEjiO1aTcFwQpwwz39O9D2a2628juil8lgAQwGARnyxzVrJ0jr kdp9+m0q+mtIwZJEmtzCAAMk5znHyOeKdJN7FXrs0/7N2iXpOCMLIS5aUtJ3JJ5HlxwMUnfabMlr 1AsxijInhAO4ZbKng58uCK0Xo3R7zTNFiivVVZlxlFUgKMdhkknA4z7VR9XdK3mt3NvJBp9tcmPx EaSdzhVYLtYAEZK4PHyrOusm2X3pdGcW3U97a20JaR1Mb7g4XIYY7N6jmviHWU+9zSffDEoy0ZgU YYk5IAPv/emrSvswluNOm++uy3Ido02OSsRU48hhjnvVPrXQd5pTNcPbtPagAeJF8JLE4VQrHJOc dh51ZPE3pHOeRdlPd6tLqupQhrjwlihISQIfhbGTwvJ54qnVBGTFMNjYOQpyw47Grxem7uO6mgnu E08pEHH3wmAuSPwLuGSc5HbHFSbbpK4c2s8sd7a2U6hZZGgJZXJwu3gbgxxjHbPNOuMroSqq32UM ccaMy/eVIQYCsCVPFfCQId7Mx2qQOOdxI7fpUy9hmsbqazHir4DhZDJHsZSByCKkyaPfJbb0CsJC kwCggBWGFY57Z/KqJpkmnsrJfjkbETKWYFY2JGRiiDa7qZQI1kJBCrlsY8qtLLSL28upGENyWjA3 tIrMVXsMgZwPftTdo/2d3kkkMFzZkTSMwldmAVF8gAOSe5/KkdpHVDYo2WkXtws0tmrzG3UM4VCS qeRyPQnBFbJ0h0taxRwanaaxcPPFiNxESIycDcrxvkg+vI8jxTGvTtjDY21nbxLFFbxNCAoxlGXB /XB+Yq0VQo9T5n1ptI50fdFFFdAKKKKAPKiahaC6sZoVADOMgj+buKl0Vxra0dT0xEjkLw+Gtw6s Ocbypx8xUG80abUzb29wNRnsxKZ5mZ/EBKrhVTzwScn/AE1b6pbG11d1IQREh0DHk57/AC5zXOEt Z3fiGzdonGDJbszEH3UeX515jbx3o2/tOzNeqtHt4bPT7tbZoJpriWC7mO7cZEI5I7AkZNUMZt4l Zmt7eWPdgFmO76YNOP2jalaG6WyiiULG5kmJBUmTGOfpiq7QPs91bV57K5uovu9hOPEJVl8QJ6YP YnyJ9c1pm212ZbnvSP/Tz2edrlWAQQxg5SJc4HPf50wWHS6XPRGpa/crdJJCwW18o5OQM9ueSR38 qu+pfsxudNtnvdI8WeEfis3YNMo/7Sv4vl3+dMd9oS2v2YLpl01yZYbZSdjMAJM5C4xjG44rK2kO kyoGkHVdJmsIdKt/2dPCtxZPLKVmVAqoWTIxnjOGI/EKt9R1X9u6faWtjqVjZoZ1+9rdy7X2LztZ SBnJUdj9asNWsE0+bSRaqtijO8SmXmMP4e4ZU8AHYQe2c571yhuhqsDyT2lqsMDmOd95MJIOPgI/ H/QedI+mU6a2X0jM4Msc1uV5IETklh+fNV0+vwWEBkaWSQk/AkRy0jegA5NZvd6rNo1w8ei3d1DC 7lhvRVHfsvqKlaX19qlrMBfN95jB7PwQPPBXBFS029o6qlo0KzWRbIGS9u4JGByNgUKzHcWG9QTz mqGS9TUtbWObVmkstNkB3y5Tdc+SjavJUc/Wqe465gtUm+59PWyXErllla6MgYfwt2zn2qw6d6u0 ex0SK0MklnLFgSN4YZ5XPLP7knOSaGmnsZaY4Pv2ACFJGGSsj4Y59eRUe6Se7jjWeG3naJ1lUylk RHU5B47kflUizvDd2Xi2qOyMpKySOMk47nFcJZGSCFjstZWABaRBJJnHPA86lt/0bX+EJtFvvvja lGLSW5mAWcSEGORBwAMoSuPrnz8sVCaTP0vqcuuQR2sNhOmy6toDxAMjDJn8QzkkADgnA8qaYYJZ 0ZZRdSRuMsZm2j5be+K8ntJAqxQT21kgwA7IHYH0UH4R296ZZH6ONL2Q7+1ttQto5Nkd1Kc+FcLl WjBHOHXBx/WmHSbEWsAkLO7uPxOxJA74yagC2NzfIvj+MpweOyjPJ/tTAOBWjx4b/JksjWtI9ooo raRCiiigAooooAKKKKAKPqW1E9nHJsLbH+LaATgj/OKW2aAoGUTl4iCPDOGBHscGn1kV1KsMgjBB 86U7mCe3u5bdSriNsoXUNhSOMjv9aweVGnzRrwX1xZQ2XTuny65Jrmo3a3LlsQQygKE4/EQcfF39 hV6ot7W7V0h1MhyASrvIh+Yy2K+oRevCyPBt7lXhKnJz6PXQ22piPcs6g8Y8WAKR89pwagqb9jNJ Mlx21qLgulhIsik5klVsfQkiqbqe6iXTFibUo4jJcxKVUJ2DgnPJOAAT9Ks7ma4tbRrvUGt1t41B ZfC3sx9iTism6m6gfX51Kx+FbxsQiAbR38wKryJ/62aBa3Vz1LqNrd2kMkunWDtJDNdnBu5NpQMA q/gG48+Z8q96rsxHoED5ZYY8B4o+CWx/nNZrp+s6vp20Wl9KsRbiESNtY+mAa1bTY4NV0SGzvrcB 2hEjxgOyIx9GbkkZ+hqi1SaJVprozKa3Gq2SyJGUMLmNfiyMgc81XzadKlkJTjeCQwBzkVpOjdBv aXNxFPI0tgJDJbqFIY5PIb8h/tUvVejrC4kwJVtRIMCPIxnPYc1NY7n16JJP6Mit4PvLrEvLk4x5 n5e9W1n0xqU7LPE0a24cAzvKihR8ick+1M2kdGXWkdQQtcQfeLRmwxiYn4SCMHt2OKbopNN0mUW2 nW5upC5Bjij3mI+7jhR8zXW3srK32VOidPRafHHcG4uyYmADSqsUbDHkCN5GflV6qzuqiwjWEEnd JIhBx7A8n610im1O4tlkuLaG1cElo428QgeXxnAB9eKiywhrmOTUL7A5MdrESAxAzkn8Tnj2HtUm 1sut6O6RQrPLJJfNJKASS0mViHsPwj681xSS0DvcpDJMVGfvM5JH/tz/AGFfSTL93C2tiQW5WN1C gD+ZvT9TXy6yyxqsz+KwOWKrgd/Spd76GS/pZaEWmMtwy7QcKue/r/irio9jbC1tljzk9yfepFet jnjCRkp7Z7RRRVBQooooAKKKKACiiigAqi162l3i4iXII2uR5c+dXleMoZSCAQe4NTyQrnTGinL2 KdvG9vIykBgwyvJUE/qP6V49ha+L4rQTxM3cx3DAdvQHH6VdXek7stBgg90btSb1LJfaODbW/wB5 kmu+IYdglAOecZzxj8q894qh6NStULHWWri7vFtIJbmOG3Ux7WmJ3jOSWGeT6e1K0syq2G2qB5E4 4rQNN6CleWC+1RRdkgvJZqQhDHyLEgEDzxTXZWMFurW1voCW0B5cbIxk4/8Ay/OurpE3tsT/ALPO lIb4HW7xHZYZFNmqsAGZe7HPkDgD609z3PUEjlLeyso1B/HLektj5BP71ymvLOziW2eCWGMDCqbd 9ij6YAry3u7a5YrbK7xx4+NYlK5x5ZOT+VOra+jigm51IIpmntVO34wsLynPt2/pSJ1XdSz6itvA 6vJvUOXhaMqQwwAM05XeqW8dqxSS6R41J+C2f4jjjsuO9IN1a3VpfxNdsWlMm8sTksAfxHHvS3T1 rQelsmtreoeH4RCxREbSsYAAH0ppSS+NvFBYQwQRhB+/fAXt3CDv9SKobDSRcaeLyW5SHexCKycN 7+3NMWlRG1sogzGaIcoUYgKP9Iqa23thLZzlgAEX3q9a5uY1PxgZAOe+wfCD7ntXO2toI5pZ7eze S4f8V1cMST9T5ey4FSL64l+Lw1fJPwExlwPpwK+Esp55CI7iWVmHxOOCflnhR9KNNvoqta2zncQv KRLJ4sgj52KxSMt7/wA314qXpdlezStJdpEsRIIQIPhx6E8k+9WGn6RHaIC+XbcWwSSAfXnuferK tWLx9d0SvLtaR7RRRWwgFFFFABRRRQAUUUUAFFFFABRRRQAVzMcbOHZFLAYyRyB6V0ooA4fdowMA FR6KSBXybOM9nkT/AEuRUiiucV/Du2f/1NeW2C9pZPmSK8azjc5fLf6sGpAopXKZ3kyO1nG4xllH /acUta/0wLq9juYXcvsCYPJOCfP05yflTaK8xzSvFDXo7yZBs9KitLSK3V3Kxpt74zXQ6bbsclT+ eal0UfHH8DkyMmn2qdoFY+rDJ/WpAUKAFAAHkK98qKZJL0K22e0UUUwBRRRQAUUUUAFFFFAH/9k= ------=_NextPart_000_0098_01C29330.B7655560 Content-Type: image/jpeg; name="clip_image008.jpg" Content-Transfer-Encoding: base64 Content-ID: <009301c29363$018405b0$66902244@ROSS> /9j/4AAQSkZJRgABAQEAYABgAAD//gAcU29mdHdhcmU6IE1pY3Jvc29mdCBPZmZpY2X/2wBDAAoH BwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8 SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCANmAl0DASIAAhEBAxEB/8QAHAABAAICAwEAAAAAAAAAAAAA AAUGBAcBAgMI/8QAZxAAAQMDAQMEBwwWBggFBAIDAQIDBAAFEQYSITEHE0FRFBUWYXGB0SIyNlNV kZOUlaGx0xcYIzU3QlJUVldmcnN0kqKksrPB0uMzNGKDo+EIJEZ1goTCwyVDRGTwRWOF8SalOGXi /8QAGwEBAAIDAQEAAAAAAAAAAAAAAAECAwQFBgf/xABHEQACAQICBQgIAwYEBgMBAQAAAQIDEQQh BRIxQVEGExRSYXGBkRUiMqGxwdHwFjNTFzRCcuHxI1SS0iQ1Q2KisgeCwuIl/90ABAAo/9oADAMB AAIRAxEAPwC58oXKF3B9r/8Awvs/s3nP/Uc1sbGz/ZVnO371Uz5YT7lv0/8Al0/0hP8AZ/8A5n/t VY4MHSFm0BYrnc9NQJKpESOla0wWlrUtTQUVEqxngd+avCEqklGKu2G7Fc+WE+5b9P8A5dPlhPuW /T/5dTPb7k6+w+P7mx/LTt9ydfYfH9zY/lrb9HYv9NldePEhvlhPuW/T/wCXT5YT7lv0/wDl1M9v uTr7D4/ubH8tO33J19h8f3Nj+Wno7F/psa8eJDfLCfct+n/y6fLCfct+n/y6me33J19h8f3Nj+Wn b7k6+w+P7mx/LT0di/02NePEhvlhPuW/T/5dPlhPuW/T/wCXUz2+5OvsPj+5sfy07fcnX2Hx/c2P 5aejsX+mxrx4kN8sJ9y36f8Ay6fLCfct+n/y6me33J19h8f3Nj+Wnb7k6+w+P7mx/LT0di/02NeP EhvlhPuW/T/5dPlhPuW/T/5dTPb7k6+w+P7mx/LTt9ydfYfH9zY/lp6Oxf6bGvHiQ3ywn3Lfp/8A Lp8sJ9y36f8Ay6me33J19h8f3Nj+Wnb7k6+w+P7mx/LT0di/02NePEhvlhPuW/T/AOXT5YT7lv0/ +XUz2+5OvsPj+5sfy07fcnX2Hx/c2P5aejsX+mxrx4kN8sJ9y36f/Lp8sJ9y36f/AC6me33J19h8 f3Nj+Wnb7k6+w+P7mx/LT0di/wBNjXjxIb5YT7lv0/8Al0+WE+5b9P8A5dTPb7k6+w+P7mx/LTt9 ydfYfH9zY/lp6Oxf6bGvHiQ3ywn3Lfp/8unywn3Lfp/8upnt9ydfYfH9zY/lp2+5OvsPj+5sfy09 HYv9NjXjxIb5YT7lv0/+XT5YT7lv0/8Al1M9vuTr7D4/ubH8tO33J19h8f3Nj+Wno7F/psa8eJDf LCfct+n/AMunywn3Lfp/8upnt9ydfYfH9zY/lp2+5OvsPj+5sfy09HYv9NjXjxIb5YT7lv0/+XT5 YT7lv0/+XUz2+5OvsPj+5sfy07fcnX2Hx/c2P5aejsX+mxrx4kN8sJ9y36f/AC6fLCfct+n/AMup nt9ydfYfH9zY/lp2+5OvsPj+5sfy09HYv9NjXjxIb5YT7lv0/wDl0+WE+5b9P/l1M9vuTr7D4/ub H8tO33J19h8f3Nj+Wno7F/psa8eJDfLCfct+n/y6fLCfct+n/wAupnt9ydfYfH9zY/lp2+5OvsPj +5sfy09HYv8ATY148SG+WE+5b9P/AJdPlhPuW/T/AOXUz2+5OvsPj+5sfy07fcnX2Hx/c2P5aejs X+mxrx4kN8sJ9y36f/Lp8sJ9y36f/LqZ7fcnX2Hx/c2P5advuTr7D4/ubH8tPR2L/TY148SG+WE+ 5b9P/l0+WE+5b9P/AJdTPb7k6+w+P7mx/LTt9ydfYfH9zY/lp6Oxf6bGvHiQ3ywn3Lfp/wDLp8sJ 9y36f/LqZ7fcnX2Hx/c2P5advuTr7D4/ubH8tPR2L/TY148SG+WE+5b9P/l0+WE+5b9P/l1M9vuT r7D4/ubH8tO33J19h8f3Nj+Wno7F/psa8eJDfLCfct+n/wAunywn3Lfp/wDLqZ7fcnX2Hx/c2P5a dvuTr7D4/ubH8tPR2L/TY148SG+WE+5b9P8A5dPlhPuW/T/5dTPb7k6+w+P7mx/LTt9ydfYfH9zY /lp6Oxf6bGvHiQ3ywn3Lfp/8unywn3Lfp/8ALqZ7fcnX2Hx/c2P5advuTr7D4/ubH8tPR2L/AE2N ePEhvlhPuW/T/wCXT5YT7lv0/wDl1M9vuTr7D4/ubH8tO33J19h8f3Nj+Wno7F/psa8eJDfLCfct +n/y6fLCfct+n/y6me33J19h8f3Nj+Wnb7k6+w+P7mx/LT0di/02NePEhvlhPuW/T/5dPlhPuW/T /wCXUz2+5OvsPj+5sfy07fcnX2Hx/c2P5aejsX+mxrx4kN8sJ9y36f8Ay6fLCfct+n/y6me33J19 h8f3Nj+Wnb7k6+w+P7mx/LT0di/02NePEhvlhPuW/T/5dPlhPuW/T/5dTPb7k6+w+P7mx/LTt9yd fYfH9zY/lp6Oxf6bGvHiQ3ywn3Lfp/8ALp8sJ9y36f8Ay6me33J19h8f3Nj+Wnb7k6+w+P7mx/LT 0di/02NePEhvlhPuW/T/AOXT5YT7lv0/+XUz2+5OvsPj+5sfy07fcnX2Hx/c2P5aejsX+mxrx4kN 8sJ9y36f/Lp8sJ9y36f/AC6me33J19h8f3Nj+Wnb7k6+w+P7mx/LT0di/wBNjXjxIb5YT7lv0/8A l0+WE+5b9P8A5dTPb7k6+w+P7mx/LTt9ydfYfH9zY/lp6Oxf6bGvHiQ3ywn3Lfp/8unywn3Lfp/8 upnt9ydfYfH9zY/lp2+5OvsPj+5sfy09HYv9NjXjxIb5YT7lv0/+XT5YT7lv0/8Al1M9vuTr7D4/ ubH8tO33J19h8f3Nj+Wno7F/psa8eJDfLCfct+n/AMutmaQ1D3VaYiXvsXsXsnb+Y85t7OytSfPY GfO54dNaf5Z4FnjQtOS7Pa4sBuY084QxHQ0VAhop2tniRtH1zWx+SL6GNo/vv2y60mmnZlimf6Qn +z//ADP/AGqmb79CLTP4GJ+wNQ3+kJ/s/wD8z/2qmb79CLTP4GJ+wNbujv3un3lZ+yyiUpSvfGof /9Cu0pSvphpClKUApSlAKUpQClKUApSlAKUpQClKUApSlAKUpQClKUApSlAKUpQClKUApSlAKUpQ ClKUApSlAKUpQClKUApSlAKUpQClKUApSlAKUpQClKUApSlAKUpQClKUApSlAKUpQClKUApSlAKU pQClKUBI8sfoc0X+Jr/UZrYnJF9DG0f337Zda75Y/Q5ov8TX+ozWxOSL6GNo/vv2y6+cVvzJd7Nx bCmf6Qn+z/8AzP8A2qmb79CLTP4GJ+wNQ3+kJ/s//wAz/wBqpm+/Qi0z+BifsDWzo797p95E/ZZR KUpXvjUFKUoBSlKA/9Gu1Hqv1sQopVJ3g4PmFeSvW6yuw7c66DhWNlPhNUbia9hpLSc8LUUKaTe+ /wDc14QUldl/jS2JjXOx3NtGcZwR8NetVjS8rYkORlHcsbSfCKs9dHBYjpNCNTfv7yklZ2FeUmUz Ea519ewjOM4J+CvWorUnzpV9+Kti6sqNCVSO1IRV3Y9RfrYSAJO8/wD21eSpAHIyK163/So++FbB R5xPgrS0ZjamLjJzSVuBacVF5HNeMqZHhNhyQ5sJJwDgnf4q9qhdUfO9v8J+6tzGVpUKEqkdqKxV 3Yy0X22uLShEnKlHAGwrj61Z9UGF/XWPwifhq/DhWrozGVMXCUppKz3EziovIwF3y2trUhcnCknB GwryV17f2v66/wANXkqtTIE1Ux5SYj5BWcENnfXj2unDeYcj2JXkrky0vjU36i8n9TJzceJa+39r +uv8NXkp2/tf11/hq8lUzhXq1DlPI22ozrietKCRWOOm8XJ2jFPwf1J5uJbu39r+uv8ADV5KzWH2 pLKXWVbSFcDgj4ao/a6d9ZSPYleSrdZm1tWtpDiFIUBvSoYIrq6OxuIxE3GrGyS4P5sxzilsM6sW TdIUNWy/ISlX1IyT6w4VD3y9rQtUSKrZI3LWOPgFV4BS1YAKlE8BvJrBjNM83Pm6Cu+O4tGnvZaj qmDn+ikH/hHlr1Y1HbnvPLW0c4AcTx9bNV5ux3JxAWmKoA/VKCT6xNY8mDKhnEhhaO+RuPj4VpvS ekKa15wy7U0W1IPYXttxDqAttaVpPBSTkGu1USDcH7e8Fsq3fTIPBVXODManRkvNHjxHUa7WB0hD Fq2yS3fQxSg4mRSlK6RQV4ypjEJsOSHNhJOM4J+CvaobU/zvR9/WrjK0qFCVSO1Foq7sZHb+1/XX +GryU7f2v66/w1eSqYAVEBIJJ4AVkdrp31lI9iV5K85HTOLl7ME/B/Uzc3Etfb+1/XX+GryV7M3a 3yP6OW3xxhR2SfXqndrp31lI9iV5K8FJUhRSoEEcQRwq3prFQf8AiQVvFfMjm47mbDpVX0/dXG30 w3llTatyM/SmrRXocJioYqlzkTFKLi7GE/eIEZ5TTz+ytPEbCj8Arz7f2v66/wANXkquX357veEV hNR3nyQyytwjiEJJx61efqaZxKqyhGKdm1se7xM3NxsXDt/a/rr/AA1eSnb+1/XX+GryVVO1076y kexK8lO1076ykexK8lR6Xxv6a8n9SObjxLX2/tf11/hq8lSDa0utpWg5SoZBqidrp31lI9iV5Ku0 JKkwmUqBBCACCOFdTR2Mr4lyVWNrW3NfEpOKWw85V0hwnA3Ie2FEZxsk/AK8O39r+uv8NXkqF1R8 8EfeVENtOPL2Gm1OK6kjJrn4jS+Ip15U4RTs7bH9S6pq1y49v7X9df4avJXKb9bFKCRKGT1oUB8F VPtdO+spHsSvJXk6y6wrZeaW2o78LSQaxPTOLjnKCt3P6k83HiX9p5p5G204hxPWlQIrtVDhTXoL 4dZWR1joUO/V3iSUS4yH2+CxnHVXawGkI4uLytJbjFOOqetcOOJabU4s7KUjJPVXNRGpJfMQOZSc KdOPF01tYquqFGVR7iIq7se3b+1/XX+GryVntOofaS62raQoZB6617Vp0xK5yIuOo+abOR4DXI0d pSeJq83USWWVv7l5wUVdE3SlK75iMSTdYUN3mpD2wvGcbKj8ApFukKY7zUd7bXjONkj4RVc1L89P 7sfvrtpj55n8Ga4ENJ1pY3mGla7W+/xMzglG5a1qShBWo4CRkmo/t/a/rr/DV5KzJX9Ud+8PwVQK yaT0hVwk4xgk7rf/AHIhBSWZc+39r+uv8NXkp2/tf11/hq8lVJEKW6gLbivLSeCktkg127XTvrKR 7EryVz/S+Nf8C8n9S3Nx4lubvdtdWEJlpBP1QKR65FZjbiHUBba0rSeCknINUB1h5hQS80tsneAt JHw172+4PW98LbUdgnzaOhQrLQ05LX1a8bd27wIdLLIvVK6tOJeaQ6g5SsAg12r0xhFKUoBSlKAk eWP0OaL/ABNf6jNbE5IvoY2j++/bLrXfLH6HNF/ia/1Ga2JyRfQxtH99+2XXzit+ZLvZuLYUz/SE /wBn/wDmf+1UzffoRaZ/AxP2BqG/0hP9n/8Amf8AtVM336EWmfwMT9ga2dHfvdPvIn7LKJSlK98a gpSlAKUrhSghJUo4CRkmobSV2Ct6plbTrUVJ3JG0rw9H/wA79RUWCuVHkPJzhlOfD/8ABXSbJMuY 6+r6dW7wdFWjT8UN2kFad72Se+OHwV42jT9I4ucnss/ojZb1EkVWK+qNKbeTxQoGr624l1tLiTlK hkGqHMjmLMdZP0iiB4Ks+m5fPwOZUfNMnHi6K29CVnCpKhLv8Vt++wrVW8//0q7UVqT50q+/FStR WpPnSr78V77SP7pU7jVh7SKk3/So++FbBR5xPgrXzf8ASo++FbBR5xPgrlaA9ifgWq7Uc1C6o+d7 f4T91TVQuqPne3+E/dXT0n+5z+95Wn7SK3C/rrH4RPw1fhwqgwv66x+ET8NX4cK5+gfyp9/yLVdo rhz+jV4DXNcOf0avAa70/ZZjW016v+kV4TVu0386U/fH4aqK/wCkV4TVu0386U/fH4a8joP96fc/ ijPV2ErWJdJXYdvddHnsYT4TWXULqhZTBbR9UuvSY+q6WGnNbbfHIxQV5IqpJUSSck8at1itaIsZ L60gvODOT9KOqqownbkNo+qUB79bAQNlCQOgVwtB0IylKrJZrJGSq9xzXVxtDzam3EhSFDBB6a7U r1DSaszAUm7wOwJqm0/0at6PBWVpuWWZxYJ8w6OHfrM1U2ObYcxvyRmoOAsonsKHQsV4tx6JpG0N l/c/7my/WgXylKV7U1hUNqf53o+/qZqG1P8AO9H39c/Sf7pP73l6ftIrMT+ttffj4av44Vr1pzmn kOYzskHHXVg7rP8A2P8Ai/5VxNE42hh6clVla74P5GSpFt5FiqA1Sw3zLT+yA5tbOesV07rf/Y/4 v+VRFwub9xcCncJSnzqE8BWfSWkcNWw7pwd2+x5eYhBp3Z4xSUymiOIWKv44VTrFAXLnJcKTzTRy o9/qq41n0HTlGhKT2N5Far9Ypd9+e73hFZ2lf6y/94PhrBvvz3e8Iryt9yetq1LZShRWMHbBPwGu JQrQoY51J7E5fMyyTcbIvNKqndTO9Kj/AJKvLTupnelR/wAlXlr0HprCcX5GHm5FrpVai6kmPymm lNMBK1AHCTn4astb2GxdPExcqexFZRcdpVNUfPBH3leenPnsn70/BXpqj54I+8rFsspmJcEuvr2E BJGcE/BXlVKMNJuUnZazM79guteUqO1KjradSFJI6eisPt/a/rr/AA1eSsSfqWOlpSIm04sjcsjC R6++vS18bhFTetNNcLpmFRlcrLiObdWjOdlRFWnTCyq3KSeCVnFVQkqJJOSeNXHT8ZUe2J2xhTh2 sd6vPaDi3iW1ssZauwk6p2oJXZNyUkHKGhsjw9NWqdIEWG68fpU7vDVDUpTjhUd6lHJ8Nbmna+Ua K35v5EUlvMnsFZtpm79kL2cfvr0ssrsS5NqJwlR2VeA1Zm4A7RiIRglvf4eNUwgoWQdykmudiaEs BWpzjwT8VtLRevFmw6Vh2qV2Zb2nc5UBsq8IrMr2cJqcVKOxmsVHUvz0/ux++u2mPnmfwZrrqX56 f3Y/fXbTHzzP4M14+l/zT/7M2ZewWeV/VHfvD8FUCr/K/qjv3h+CqBWfT35sO4ilsLrY/nPH8B+E 1n1VYOo+wobcfsTb2B57nMZ3+Csjut/9j/i/5V1KWlMHGnGLnmktz+hjdOVyXujDci3PJcSCAkqB 6iOmqNUrcdQPzmiyhsMtq88Ack+PqqOjsOSX0stJKlqOABXA0lXp4uuuZV93eZoLVjmXGxqKrOxn qI981n15RY6YsVthJyEJxnrr1r2VKLhTjF7kjVFKUrIBSlKAkeWP0OaL/E1/qM1sTki+hjaP779s utd8sfoc0X+Jr/UZrYnJF9DG0f337ZdfOK35ku9m4thTP9IT/Z//AJn/ALVTN9+hFpn8DE/YGob/ AEhP9n/+Z/7VTN9+hFpn8DE/YGtnR373T7yJ+yyiUpSvfGoKUpQCozUErsa2KSk+adOwPB01J1Ut SSufuHMg+ZZGPH01y9LV+ZwzS2yy+vuMlNXkRKACtIUrZSTvPVVwavlqaaS2mTgJAA+Zq8lVJqM/ IzzLLjmOOwknHrV6drp31lI9iV5K8zgsViMMm6UL37GZpRUtpl32RElTEvxXdvaThfmSN48IpYJf Y1ySknCHfMnw9FYZt81KSpUN8AbyS2d3vV4pUUqCgcEHIrEsRUp4lV5Kzvf6ktXjY2HUVqT50q+/ FZsCSJcJp4cVJ3949NY9+QV2h7HRg+/XscdaeEm48LmvD2kU1v8ApU+EVsFHnE+CteA4INX6G+iT EbdQchSRXI0BJWnHfkXq7Uf/067ULqk/6g2P/ufuqaqv6qeTzTLOfNZKiO9XutKySwc/D4mtT9og YX9dY/CJ+Gr8OFUS2I27lHT/AGxV7rS0Cv8ABk+35E1dorhz+jV4DXNcOf0avAa7s/ZZjW016v8A pFeE1btN/OlP3x+Gqiv+kV4TVu0386U/fH4a8joP96fc/ijPV2ErUJqlBMJpXUupusG8xjKtjqEj KkjaHir0WkKbqYWcVw+GZig7SRTY6giS0o8AsH36v6TlII6RWvOFXKyXBE2GlBUOdbGFD99cXQVa KcqT2vNF6q3klSlFKCUlSiABvJNeo2GEgNVLHNMIzvJJxUDBSVTmAPqxWTep4nzipBy2jzKe/wB+ vXTsUv3EOEeZaGSe/Xipy6VpG8Nl15L+xs+zAt9KUr2prCobU/zvR9/UzUNqf53o+/rn6T/dJ/e8 vT9pFWbQXHEoTjKjgZqWVpielBUFsLI+lCjk+uKjIn9ba+/Hw1fxwrgaLwFHFU5Ope6ZlnNxeRr1 1pxhxTbqChadxBqRs8e2ynQ3LU4Hc+ZG1hKu911NX61iWwZDSfmzY6PphVS3g9RFalai8BibTipL t3r6lr68cjYLLLcdsNtICEDgAK71FWK5dmxuacV82bGD3x11K17WhUhVpqcNjNZqzsyl3357veEV xarX2zcWjnua2BnOznPv1zffnu94RWdpX+sv/eD4a8bh6MK2PcKium5fM2ZNqN0encl/77/C/wA6 dyX/AL7/AAv86sVK9J6JwXU97+pg5yXEgY+mOYkNvdmbWwoHHNYz79T1KVt0MNSw8XGkrJ9/zKtt 7Sqao+eCPvKiG2nHl7DTanFdSRk1L6o+eCPvK89OfPZP3p+CvH1aKraQlTbteTNm9oXMLtdO+spH sSvJXZu1XB1YQmG8CfqkFI9c1eqV11oGlfOb9xj51ldtum1pWl2cQAN4aBz65qxAYGBwpQnAya7G GwtLDQ1aaMbbbzIDVErZabipPnjtK8FQMEsia0qQvZaSrKjgn4K9LrK7LuLrn0oOynwCvFqJJeRt tR3XE8MoQSK8ZiMRKti3Vir2eXcjZStGxbu39r+uv8NXkqrXNUdye65GXttrO0Dgjw8a69rp31lI 9iV5K6uQpbSCtyM8hI4qU2QKyYzF4jFQSqQtbsZEYqOwmNLy9l5yKo7ljaT4as1UGHIVFltvJ4oV mr6haXG0rScpUMg13tC1+cw+o9sfhuMNRWkVLUvz0/ux++u2mPnmfwZrrqX56f3Y/fXbTHzzP4M1 x6X/ADT/AOzMsvYLPK/qjv3h+CqBV/lf1R37w/BVArPp782HcRS2EpF0/LmRkPtuMhK+AUo5+CsS bb5MBwJkN4z51Q3g1bLH854/gPwmsibDbnRVMODceB6Qeutiehqc6ClS9q1+8qqjvmUmGIqpATMU 4lo/TN4yKuVvhQ4rIVESCFj+kzkq8dUqTHciyFsOjCkHHhqX07c+Ye7DdV8zcPmCfpVf51paJxFO lW5upFXex70+Baom1ctNKUr2BrilKUApSlASPLH6HNF/ia/1Ga2JyRfQxtH99+2XWu+WP0OaL/E1 /qM1sTki+hjaP779suvnFb8yXezcWwpn+kJ/s/8A8z/2qmb79CLTP4GJ+wNQ3+kJ/s//AMz/ANqp m+/Qi0z+BifsDWzo797p95E/ZZRKUpXvjUFKUoDzkvpjRnHlcEJJqguOKddU4o5Uokmr3NhonRyw 4taUkgnYIBNRvctB9NkflJ8lcHSmDxOKqR1PZXbvM0JRij005G5i2hwjzTx2vF0VK11bbS02ltAw lIwK7V2aNJUqcaa3IxN3dwQFAg7weNUOfHMWc6yfpVbvB0VfKj51ki3B/nnVOJVjB2CBn3q5ulMD PFQi6e1fAvTko7SN0tL3OxVHh5tP76n3mkvsraWPMrBBqPiWCLCkpfadf2k9BUMH3qk62MFRqQwy pVlsy8PvIrJrWuihzoTkGUplwcPOnoUOuu0K5yreTzDnmSclChkGrrJiMTG+bkNJcT3+I8B6Kh3t KsKILElxvrCgFeSuHV0TiaFTXwz99mZlUi1mYCtUT1JICGEk9IScj1zUU8+7IdU68srWriTU/wBy X/vv8L/OsyLpuEwQpzafUPq/O58HlqktH6RxDSrPLtf0GvCOwwNN25Zd7NcThCRhGek9dWWgASAA AAOAFK9LhcNHDUlTiYJO7uf/1K7XDn9GrwGuaEbQIPTX0qSumjTRrxf9Irwmrdpv50p++Pw15nS8 EknnZG/+0nyVIwYTcCOGGlKUkEnKiM1wNGaPr4au51LWtb3oyVJqSyMilKV6ExFVvlmXHcVKYSVM qOVAfSnyVENPOMOBxpZQtPAg1sHjUZK0/Akq29hTKjxLZxnxcK83i9DS1+cw7t2fRmeNRWtIhW9T 3BCAlQZcI+mUk5PrEVizbxNnApdc2Wz9IgYFSp0mM7pu78F/nXqzpWOk5fkOOb9wSAny1rSwmlKq 1Jt27WvkydaC2FcjxnZbyWmUFSj1dFXS2W9Fuihsb1netXWa9o0OPDb2I7SUDpxxPhNe1djR+jY4 X1pO8n7u4xTnrClKV1SgqG1P870ff1M1jT4DVxZDTylpSDnzBANamNpSrYeVOG1louzuUmJ/W2vv x8NX8cKiG9Mwm3ErS6/lJyMqHkqXrU0VhKuGpyjU3stOSk8hVSv9s7Ekc+0n5k4ej6U1ba8pMZuW wpl0ZSr3qz4/BrFUtXethEJarKPClrhSkPo+lO8dYq8sPoksIebOUrGRUV3LQfTZH5SfJUhAgN29 ktNOOKQTnCyDj1hWpovDYnDXhU9l9u8mbi80VS+/Pd7wisaJOkwVKVGc2CoYPmQfhq1S7BEmSVPu OPBSuISoY+CvHuWg+myPyk+SuZPReMVaVSnlm9/Eyc5G1mQvb+6fXX+GnyU7f3T66/w0+SpruWg+ myPyk+SnctB9NkflJ8lW6DpTrv8A1MjWhwIXt/dPrr/DT5Ks9pfdk25p55W0tQ3nAHwVhdy0H02R +UnyVJxIqIcZLDZUUo4FXGulo7D4ylUbryurcblJuLWRWtUfPBH3leenPnsn70/BU/Pssa4vB15b qVAY8wQB8FdYViiwJAfacdUoDGFEY+CtaOjq6x3P5at7lnNatiSpSleiMIrBvMrsS2uLHnlDZT4T WdWHcLYzckoS844kIOQEED4RWtio1JUZRpbWWjZPMo4BJx0mr1bY3YtvZaxghOT4TWE1pmC06lwO PK2TnClDB96peuborATwzlKptZapLW2CvGWwJMRxk8FpIr2pXZnBTi4vYyidnc14tBQtSFDBScGr bp2X2RbubUcqZOPF0VzJ07CkyFvKW8lSzkhJAHwV7W+zsW51TjLjp2hghZBHwV5/R2AxOFr6ztqv LaZZyjJEBqX56f3Y/fXbTHzzP4M1NzrJGuEjnnVupVjGEEAfBXMGyRre+XmVuqURjCyCPgpDR1eO O5921bthzTjYy5X9Ud+8PwVQK2E4gONqQc4UMHFRHctB9NkflJ8lZdK4GtiZxdPciITUVmZVj+c8 fwH4TWfXlFjIhxkMNlRSjgVca9a7NKLjTjF7kjG9pDahtnZUfslpPzVobwPpk1VAcHIrYlRDumYL rqnNt5G0c7KVDA96uFpHRU61XnaO17fqZYVElZntZbiJ8MbR+at+ZX3+o1I1HQbJHt7/ADzLr2cY IURgj1qka7OG53mkq3tGJ2vkKUpWwQKUpQEjyx+hzRf4mv8AUZrYnJF9DG0f337Zda75Y/Q5ov8A E1/qM1sTki+hjaP779suvnFb8yXezcWwpn+kJ/s//wAz/wBqpm+/Qi0z+BifsDUN/pCf7P8A/M/9 qpm+/Qi0z+BifsDWzo797p95E/ZZRKUpXvjUFKUoBSlKAUpSgFKUoBSlKAUpSgFKUoBSlKAUpSgF KUoD/9Wu0pSvphpClKUApSlAKUpQClKUApSlAKUpQClKUApSlAKUpQClKUApSlAKUpQClKUApSlA KUpQClKUApSlAKUpQClKUApSlAKUpQClKUApSlAKUpQEjyx+hzRf4mv9RmtickX0MbR/fftl1rvl j9Dmi/xNf6jNbE5IvoY2j++/bLr5xW/Ml3s3FsKZ/pCf7P8A/M/9qpm+/Qi0z+BifsDUN/pCf7P/ APM/9qouByzxY2nrfZ5mkmZzcGO20FOygQooQE7WyWzg8fXq+FrKjWjUavYSV1YwaVI/Jjsf2voH syPiqfJjsf2voHsyPiq9H6ep9RmHmnxI6lSPyY7H9r6B7Mj4qnyY7H9r6B7Mj4qnp6n1GOafEjqV KM8rtokPIYY5OYTrrighCEOIUpSicAABneSalu7Cd9piR7XV8RT09T6jHNPiVWlWruwnfaYke11f EU7sJ32mJHtdXxFPT1PqMc0+JVaVau7Cd9piR7XV8RTuwnfaYke11fEU9PU+oxzT4lVpVq7sJ32m JHtdXxFO7Cd9piR7XV8RT09T6jHNPiVWlWruwnfaYke11fEU7sJ32mJHtdXxFPT1PqMc0+JVaVau 7Cd9piR7XV8RTuwnfaYke11fEU9PU+oxzT4lVpVq7sJ32mJHtdXxFO7Cd9piR7XV8RT09T6jHNPi VWlWruwnfaYke11fEU7sJ32mJHtdXxFPT1PqMc0+JVaVau7Cd9piR7XV8RTuwnfaYke11fEU9PU+ oxzT4lVpVq7sJ32mJHtdXxFO7Cd9piR7XV8RT09T6jHNPiVWlWruwnfaYke11fEU7sJ32mJHtdXx FPT1PqMc0+J//9au0q1d2E77TEj2ur4indhO+0xI9rq+Ir1fp6n1GYOafEqtKtXdhO+0xI9rq+Ip 3YTvtMSPa6viKenqXUY5p8Sq0q1d2E77TEj2ur4indhO+0xI9rq+Ip6ep9RjmnxKrSrV3YTvtMSP a6viKd2E77TEj2ur4inp6n1GOafEqtKtXdhO+0xI9rq+Ip3YzftMv+11fEU9PUuoxzTKrSrV3Yzv tMyPa6viKd2M77TMj2ur4inp6l1GOaZVaVau7Cd9piR7XV8RTuwnfaYke11fEU9PU+oxzT4lVpVq 7sJ32mJHtdXxFO7Cd9piR7XV8RT09S6jHNPiVWlWruwnfaYke11fEU7sJ32mJHtdXxFPT1LqMc0+ JVaVau7Cd9piR7XV8RTuwnfaYke11fEU9PU+oxzT4lVpVq7sJ32mJHtdXxFO7Cd9piR7XV8RT09T 6jHNPiVWlWruwnfaYke11fEU7sJ32mJHtdXxFPT1PqMc0+JVaVau7Cd9piR7XV8RTuwnfaYke11f EU9PU+oxzT4lVpVq7sJ32mJHtdXxFO7Cd9piR7XV8RT09T6jHNPiVWlWruwnfaYke11fEU7sJ32m JHtdXxFPT1PqMc0+JVaVau7Cd9piR7XV8RTuwnfaYke11fEU9PU+oxzT4lVpVq7sJ32mJHtdXxFO 7Cd9piR7XV8RT09T6jHNPiVWlWruwnfaYke11fEU7sJ32mJHtdXxFPT1PqMc0+JVaVau7Cd9piR7 XV8RTuwnfaYke11fEU9PU+oxzT4lVpVq7sJ32mJHtdXxFO7Cd9piR7XV8RT09T6jHNPiVWlSj3K7 aI7y2H+TmE062opWhbiApKgcEEFncRXT5Mdj+19A9mR8VT09T6jHNPiR1Kkfkx2P7X0D2ZHxVPkx 2P7X0D2ZHxVPT1PqMc0+JHUqR+THY/tfQPZkfFU+THY/tfQPZkfFU9PU+oxzT4jlj9Dmi/xNf6jN bE5IvoY2j++/bLrS2vtfI1s3bG2rQm2t29LiUoS/zgIVsYAGynAGx79bp5IvoY2j++/bLry85a0n LiZ0TOodIWLVXY/buD2V2Ntc181WjZ2sZ86oZ86OPVUN8iLQnqF+lv8A8dXOlUBTPkRaE9Qv0t/+ OnyItCeoX6W//HVzpQFM+RFoT1C/S3/46fIi0J6hfpb/APHVzpQFRiclmi4E1iZGs3Nvx3EutL7K eOypJyDgrwd46at1KUApSlAKUpQClKUApSuKA5pXFKA5pXGaZpcHNK4zSgOaV12t/RUVI1Vp+K8t iRfLay82rZW2uW2FJPUQTuNAS9KqEvlT0dDU6hd3S441nKWWnFhRHQlQTsnw5x36iG+W3Trqkobt 91cWogJSllskk8MDnKtqsmzNjUqknlHceBahaRvy5CtzaZEZLDZPfWVHZHfxXmvVes5aeai6XhW5 w7+emTw83jq2WwDnv5xWtPE0Ye1NLxROrLgXquAaoYu3KL0o0z4NmRn4a81q17OO2/qC32opGA3B h88lffJdOQfBWrLSuBjtqr3/AELKlPgbArjaB6CPCK14uwXucdu6a0uzjidyDB2Yicd9KQcnv10O kns+i7UxPQe2B3D1qwS03gF/G34P52J5mR//19x7YHX61RStW6aQopXqC1pUk4KTMbyD4M1TDoDT rquclxn5kg71yJElxTjh61EEAnxVIp0xYEoCRY7eQBjJioJ9fFednyiwkfZTfuM6oPeZauVPRKVl BvYJBx5mO6R64TvrqrlT0moFMSZImvn+jjx4jpccPUnKQM+EivFOnrIhQUmzW8KTvBEVAI8eKkMY 4bq158paVvVpPxl/QsqHaYC+UORIRsW3SF5dkcQmY2mMjHT5sk4PiroNY6sJI7hcbvVZr+GpMnfv xu4b6xVXS3pJSqdGBG4gvJBHv1hensZPOlRVu5v4NEOFOOUpGInWeqhw0L//AGzWP1a7p5QLhGz2 20ddWVnzggqRLBHfII2ayUXOCtQbbmRlKUdyUvJJJ9eskDPf66haexlPOrSVu5r4tkqnTl7LMNPK lplsBFycm2t/pjzIjgWB0HzIUMHw12+Ston1a/RXv4Kyt3UN1YD9is8p5b0i0wnnVnKluR0KUT1k kVnjylp29ek/CX9A6HaTbWsNMvhHN6gtpLmNlJloCjngME5z3ql9qqQrTNgUkpNjt2CMHEVAPwVH DQGnWlc7EjPQ5A3okR5LiXGz1pJJAPirPDlFhJe0mveVdF7jZO0B365rXHck+OOr9Tb/AP8A2J4f k13RYL3BO3a9aXZtxW5ZnbMtJHeSoDB79bcdN4B/xteD+VyvMyNiZ34rmtftu6+gZ5m8Wq67XFc6 Kpko7wDZwR4a79tuUXoTpk+KR5azx0pgpbKq96+KI5qfAvtKoqdX6wjpDT+kY0xxO5T8a5JbbX30 pWNoeOvX5JSEJIf0pqNK0jzexCC0gjjhW1vHfrbhXoz9mafiiurLgXWla8Y5atMOvIbcj3FhKlYL jjCdlHfOFE+sM1Mw+UzR86SGGr2wlR4F5K2U/lLSB79Z9VlbFqpUfCvtpubpat90hS1pG0pLEhLh A6yAaztrwVAO1K4zTNAc0rgmmaA5pXFKA5pXFc0ApSlAKUpQClKUBUZfJZoufNfmSbNzj8hxTri+ ynhtKUck4C8Dea8vkRaE9Qv0t/8Ajq50oCmfIi0J6hfpb/8AHT5EWhPUL9Lf/jq50oCmfIi0J6hf pb/8dPkRaE9Qv0t/+OrnSgKZ8iLQnqF+lv8A8dWa0WiBYbWzbLYxzERja5tvbUrZyoqO9RJ4k9NZ tKAUpSgFKUoBSlKAVxXNcHf04oDgqA6fWrnIqhXXUOqZOq7rZLOu2MR4SWQp99panUhxGcpAOyoj fgEAbh368VWzVUlJZna0kqjq8+IsNqO53sOJ3p344eCtHEaQw2Hk41JpNbs7mSNOUldGw8gUyOut c9yb546t1MR1dsT5K6q0RbZeO20y5XfY/o+zpq181njs4xjO7PgFaL0/glsbfcv6luZkXqdfbPbH UtXC6wojik7SUSJCGyR14JqFl8pmjYUhTDt9ZUtOMlltbqd/UpCSD69REPRum4LRbZs0VSSc/Nkc 6fEV5OO9XuNNWEZ/8Et3tRvyVglykwq2Qk/JfNluYfEyTyraKJGLyTn/ANo//BXmrlMhKJ7H09qG UyfOPswPMODoUMqBwe+BWWy22w0hpltDaEABCUICQkDgABwrvgZrVqcpV/06fmyVQ4sihrTVRORo VRSeBVdWknxjG40VqzWMlJaY0lHhuK86/KuKXG0HrUlA2j1bu9UqCR057x31xWtLlJiLZU4rz+pb mYkOuVr+anmnrlZrYnjz0KMt1fgw4dnHf47q6dh61493AP8A+KZqbyM7jmuSMVqVNPY9u6kl4L5p luZitxALsl/nYTdNZ3NaEb2+wUIiEde0U52vHwryXoSzyzt3Z+43d0bkOzpi1qQn6kYI3dNWOla8 tM4+TvzrXdl8CypxW4rQ5O9JgEG05/5h3+KpBnSun47CWkWaEUoGBtsJWfGVAk+MmpWlYJ6RxlT2 6sn/APZ/UnVXA6sstR2kssNpbbQMJQkYCR1AV341xStNybd2Sc5pmuKVBJzTx1xSlwc5pxrilAK4 ddQw0p15QQ2kZUojcBWJc7rHtbHOOnaWfONJI2lf5VRLneZl0cPPL2G+hlPnR3++a9DojQNfSHr+ zDj9Dm4zSNPDertlw+pZZ2so7S9mGz2SCP6QqKQD4MZPvVHPyNWTE/1SchpR2gGYykjxEDPv1Xcj q3HjW2tJ33t3b1f6vzPY+y357a2t3HgK97T0PgsBFOFJSa3yzf08ji08TVxknGc2uxH/0MOTbbhH KTKhSGS6rCedbUkqPezxrl60XKOnaet8ptJISCtlQBJ4DeKsN+1L27uUSKYnMdjSxv5za2t+OGBi rrqaBJuFubZjNc6tMhtZG0BuB3nfXWliJU1G6tc89TwcKmvqtuxqaTb5sFIXLhvx0qOAXmlIyfHX siy3k7LjVsm9CkqQwvxEECrryljFuhDo51XwVYhIlxbFGXBhdmPc0jDXOBvdjjk7qq8U9RSssy0c DHnZQu8ka3N91FaVIRMbcGU+ZRLZKdrv5wCfXqaturIcsBuSOxXOGVHKD4+jx1Ha3lz5UuKZ9uEF YbUEpDwd2hnjkcKrFczEaCwWMp3cFGT3xy/oSsdWwtTVjK6XE2sCFJCgQQRkYPGla/tOopdsUGyS 9H3ZbUSdkf2eqrzBnM3GKmSwTsK68ZHePfr57pXQlfR0vXzi9jXwfBnocJjqeJXq5PgZFM1xSuGb 5z46ZrilLg5zSuKUuDmvKTFjTGSxLjtPtnihxAUD4jXpSrRm4u6yZBDS9G6bnICHrPFSkHOWUc0r 10YNYfyOtJ+pQ4/XDv8AFVlpW5HSWMh7NWXm/qRqx4FdToqJFSW7VeL1a2OPMQpyko2ulRBzvPh6 K9k23VcZIZha1kIYQMIEiE0+4PCs4Kt9TlKzx0zj4/8AU87P4oq6cXuIPsPWwOe7faxwCrUyM+sa 9O3PKAyedciaekoRvUywp5txwdSVK3A987qmKVsU+UGOhtafel8rEOlBkZ3a6s+wX/8Atmv4a5Tr y8RlFV10XcWWlDCDBfRLVtd9IxsjGd9SdN2a3I8pa/8AFTj4X+rKuhEwmuU+wNZ7asXOzk/0aZ0J aS51lOxtcN3Hrr0+Ston1aI8MR/+CsggHx1hyrNapzodmWyJJcA2Qt5hKzjqyRWzT5S0/wCOm/B/ UrzHaSsXXGlZcdD7WobelK+AdfS0rjjelWCPGKmmn2n2kOsuJcbcSFIWg5Cgd4II4iqT3MWDGO0d tx+KI8lR7nJ9pZx1bhtSQpaio7LziQD3gFYHg4VtR5R4R7Yy8k/mV5hmydoZxTIrXJ0o/wBGrdTD wXE+Sg03c4yg9B1jfESE+cMt8SW+o5QoAHdnwcazx07gZO2s13ojmZGxtoddM1raZcNcaft0maL1 brs002p1zsuHzKkBIJ8xzZAOe/V7skxy42OBOeSlLkmM28sIBABUkE4z0b66dDEU68NelK6McouO 0z6UpWcqKUpQClKUApSlAKUpQClKUApSlAK4rmuKgGvY/wBEzVH3kT9manKhI30TNUfeRP2Zqbr5 7p39/n4f+qN6l7CFKVzXFMgrykyWYcdUh9ew2jzysE46OivWozUvzgleBP6wrawlFVq8KUtjaRjq zcKcpLcdmNQWqQVBE5obPHnMo/WxmvbttbfVCL7Mny1rOuK+gz5G4a/q1JJeH9DzUdOVd8UbXQoO IC0KCkkZCgcg0O7jWqfDvNerEqRGJMd9xkq4ltZTn1q1XyL4V/8Ax/8A6My07xp+/wDoRa5DjExb jLq23As4WhRBHjrLj6kvUUkouT6s+mK2/wBbNdihBJJQkknO8CuOaa9KR+SK7MtA3Wck/A9JHljh HFRnh/evoe41lfwN0/h1soP7qkGOUG5JcSX48dxA4pQCknwHJx61Q6o7Kv8AywPBurr2Iz9QfXNa tTk5F5asfKxf8T6Jqq9Si13W+VizDlHGd9pPtgfw1lM8odvW2DIhSW17/Mt7Kx65I+Cqb2E11q9e nYTXWr160pcllbKHv+pk9Mcn5ZesvB/1NgN61sS0BSpK2yRvSppWR6wxWRH1TY5JIRcWhjjzgKP1 gK1qYKPpVqB7+DXXsD/7v5v+da0uSk90X5oekNASWVdp9z/2m3mJMeU0HY7yHmycbSDtD1xXritN mC5nzK0kd/NZDb11ZSlLVxeQlIwAl9YAFalTkriVsv7vqY+f0XN+pil4qSNuY6aYrVbF1v0de2i6 PE44KdKx6ysis2Pq7ULBO3zUjPAOJG78kitSfJvGxWSJ/wCFm/8ADrxfibH6M1g3W6MWqLzjyiFq yG0gZ2jVMOub2knMKNnpw2s/9VRt01DJuckuyGltI3bLYUSB4j01kwOgp9IXS8oLbt8jHicPieav htWT/mj55s7S5b02Qp99wrWo5z1d4V41jdnND6VXvV3TKZVjzeCegivplLEYaKUISSS2LYePraI0 jFuc6T+PwPaticmmOwJvD+lT8Fa6C0E4StJPeNSNtv1ztLS24EosJcOVYQlWT4wavWSqwcYM1aCn hqqnVi0u44APdAB/7v8A662nqadJt9vadiuc2tUhtBOyDlJO8b61Dzy+yBICsubW3tEDz2c5xwqT l6ovM9oNSZpcQlQWE82geaByDuFVr0JTcbbi+GxUaMZ33lu5SsG3wwOPPK6O9U68zcntPR0WmQ3H k82jC3BkAY39B+CtXXG/XS7tpRPk8+htWUAoSnZPiArKRrPUDTSWm55CUAADmm+A8VYnhp83GOV0 Z1jKfPTk72a8T//RytXs3piTH7cymZDikHm1NDGBnfnzI/fVerNuV3uF2WhyfI55SAQk7KU4HiAq PU82gZLid3Ua7cJxpwtNo8xOhVrTbpQk0+9nes61XR60yuea3pO5ad3mh1ZwcVFGWwBnaJPUBXXs 5o/Sr9asGIrYStTdKo04s26GiNIqSlCm0/BfE2zClszYrchlYWlY6DnB6RXturW9m1VJtPOITFdk R1jIbK9kA9Y3Gss68vC3VFmBHS3nclzaJ9fIz61fMcVoKuq8o4da0dzPYUaNbmlKtqxe/wBaPyZf hv4U/wDnCteva0v7qFJSxFaUfp0DePBlRHvVHyL1qCUE85c3E7PDYVsfq4pT5OY2e2Niz6NG3OVo rxNpVwpSUpJUQAOJJ3CtUGZelcbpI9sLNYrkeS84XHXOcWeKlqJJ9etqHJXFPN/D+o57RidpYpeC ZtCRqKzRkbTtyj4HQhe2fWTk1i92dgz/AF7I7zK/JWuEwVfTLCT3hmuRAGd7mR97W1HkpUtmn5oy LG6Bj7WIb7otf/n5l9f17ZmXAlIkPpxnabbAHg80RUcrlGTtEJte0M7iX8f9NVbsJv6pfriuOwWs 5yv1xW1Hktxh7/oPS3J+P8Un4P8AoWOTyiyFN4i29tped5cWVjHgAFYEjXN6e2S06yxjoQ2DteHa zUWILQOcr9eu/YjHpf5xrap8m1FewviPxDoSm1qQb8Pq2ZXdffzu7PPiaR5Kv2mJD0qwR35DhcdX tFSlHJO81rlDDSPpAfDWY1PmMNJaZlPttp86hDqkgeIGpxHJiVamoRaj4HNx/KbB1lq0aNrb8kbP pWs+2ty9UJXsyvLXg8+9JXzkh1bq8Y2lqJOPCa0Y8i5PbW/8f6nHenY7qfv/AKGz3XmmGy486htA 4qWoADx1wxKjSgTHkNPbPHm1hWPWrVu7oFW7RHnJm/pRw8da2kOS8MFg513V1muy3DtZlw+lnXrK moWv2/0LRSucd+uK8U0d0UpSoIIvU4//AIrdfxN39U1ZdK+hKz/iDH7NNVvU/oWuv4m7+qasmlfQ jZ/xBj9mmvd8m/3Wf83yRrV9qJalKV6M1xSlKAUpSgFKUoBSlKAUpSgFKUoBXFc1xUMGvo30TNUf eRP2ZqbqEjfRM1R95E/Zmpyvnunf+YT8P/VG9S9hHFQeotX2rTbakyniuUW9tqMlJyveR57GBvHS f3Vha61f3NQEMxAhc6Sklsk/0Q+qI6e90ZBzwwdLPSHpLy35DqnXXFFS1qOSSemuhobQPS4qvXdo buL/AKFalTVdkX2fytz3kBEC3MxTg7SnXC74MYCcY7+agJOvdSzIy48i4hTa/PJ5lsZ356E1XcVK 6f0zdtTzTFtUbnigAuOFQShoE4yon4BknBwDivbU9F4Ggk400rb9r83c15SclZnn2/uPp/5ifJTt /cfT/wAxPkq9ReQ6/OSEJl3O3NMZ82tpTi1jd0JKUg9HSK9J3IXd23Ept92hSEbOVKkBbSgeoABW RjG/Nb/SI8TV6PQ6i8ig9v7j6f8AmJ8lO39x9P8AzE+SpnUnJxqHTEXsyU0zJiDG2/FWVpbJ4bQI BHhxjeN9VSrqpfYyejUOovIku39x9P8AzE+Snb+4+n/mJ8lZ+itK92F8VbOzew8Mqd5zmuc4EDGM jr66vvyBful/Qf5lVlXUXZsdGodReRrPt/cfT/zE+Snb+4+n/mJ8ldL7bBZb7MtYe54RHlN85s7O 1g4zjJxUjovS3dhfDa+zOxMMqd5zmuc4EbsbQ6+urOpZXvkOjUOovIwe39x9P/MT5Kdv7j6f+Yny Vsw8gp341L+g/wAytSvt8zIcaKtotqKdrGM4NVjWUtjCw1DqLyM7t/cfT/zE+Snb+4+n/mJ8lWq0 8kOoLzaYtyjTLahmU2HEJcdcCgD14QfhrL+Qdqb6+tXsrnxdRz8eI6PQ6i8ildv7j9cfmJ8lcdvr j9cfmJ8lXb5B2pvr61eyufF0+Qdqf6+tXsrnxdOfjxI6NQ6i8ik9vrj9cfmJ8lc9vrl9cfmJ8ld9 Sael6XvC7XOcZceQlKiplRKcEZHEA+9TTunZ+p7qm228N86pJUVOK2UpSOknf5avzrte46Lh+ovI 6dvrl9cn8hPkoL/cvrj8xPkq6jkP1Mf/AF1q9lc+Lp8g7U319avZXPi6o68XvI6LQ6i8kUrt9cfr j8xPkp2/uPp/5ifJV1+Qdqb6+tXsrnxdDyH6mAz2davZnPi6c+uJPRqHUXkUdV6nKOS4knr5tPkr g3iYpOC4keBtI/dXF2tM2x3J233BksyGjhST0joI6weusOjjCW1JmzH1PZy7jOF6npIKZByOtINd +39y9PSf+AVHV3ZaW+8hltOVuKCEjhkngKtsWWSKVIQqO80n35/EzV364uHzT58SQK6dt5u1tF3a P9pKT8Iq7N8iWp3EJUZdrQSMlKnl5HeOEEV3+Qfqf6+tXsznxdYnOm9paD5tWhkuzL4FH7czM520 exJ8ld+31x+uPzE+Srr8g/U/19avZnPi6gNWaAuujorEi4yYTqX1lCQwtRIIGd+UjdVoVIJ2iylS nCp7av35kT2/uXp/5ifJTt/cvrj8xPkr005p2Zqi8ItcFbLby0qUFPEhOAN+8An3quPyD9T/AF9a vZnPi6u6urk2Y+jUNuovI//S1z2/uPp/5ifJTt9cfT/zE+Sul6tMixXiTa5S21vRl7C1NElJOM7s gHp6qwa6ym3ncxdGodReRI9vrj9cfmJ8lO31x9P/ADE+SsFhpT77bKCApxQSCeGScVsP5B+p/r61 ezOfF1EqurtZHRaHUXkUrt/cvrj8xPkp2/uX1x+YnyVn6r0ZctHSI7NxejOqkJKkGOtSgMHG/KR1 100ppG4awmvRLe7HaWy3zijIUpIIzjdgHrpzmV7k9FodReRh9v7j6f8AmJ8lO39x9P8AzE+Srr8g /U/19avZnPi6itQ8l2otOW1Vwf7GlMtn5p2KtSi2PqiCkbqrz6f8RHRqHUXkV/t/cfT/AMxPkp2/ uPp/5ifJWA00p55DSMbS1BIz1k4rYY5ENTEZ7OtXszn8FS6urtZPRqHUXkUvt/cfT/zE+Snb+4+n /mJ8le2p9NTNKXUW6c6w68Ww5lhSikA5xvIG/dXnp2wS9TXhq1wlsoedClBTyilIAGTnAJ96p5zK 9x0ah1F5HXt/cfT/AMxPkp2/uPp/5ifJV1PIfqYf+utXsrnxdUi+WeRYLxItctba345AWpokpOQD uJAPT1VCq62xjo1DqLyO3b+4+n/mJ8lO39x9P/MT5K8LbbJt4nNQbfHXIkOnCG09Pj4Ad87qvLXI lqhxpC1SrY2VAEoU8vKe8cIIz4CaOrq7WOjUOovIpvb64+n/AJifJWda9bX20u7caUgpUoFbbjSS leOg7s48BFWf5B+p/r61ezOfF0+Qfqf6+tXsznxdYasqVaDp1M0+JaFGlCWtGKTPKJyvXFDhMy2R nkFPmQypTRBz0k7W7vYq5ae11aNQuNxmlrYmOA/6u4gk5AycKG4jjxwd3CtW6t0VctGuRUXF+K6Z QUUdjqUcbOM52kjrFV4HBz09FcXE8n8BXh/hx1XxX02GzGrJbT6X6M9HXXFa80Frx64SEWi8OtbZ QAxIUSFOKB86o8CccDu4dJNbDr55j8BVwNbmqu34o2oyUldEZqf0LXX8Td/VNWTSvoRs/wCIMfs0 1W9T+ha6/ibv6pqyaV9CNn/EGP2aa9Zyb/dZ/wA3yNevtRLUpSvRmuKUpQClKUApSlAKUpQClKUA pSlAK4rmuKhg19G+iZqj7yJ+zNTdQkb6JmqPvIn7M121hM7A0jcn9jbywW8Z+r8z/wBVeC0vT5zS jhx1V5pG7TygaTv91evV7lXB4bJdWdlvIIQkbgncANwAHDfUdxrgePx1zX1CEI04qEVZI1SW0vY+ 6PUcS0dk9jdkqUOd2NvZwkq4ZGeHXX01a7XDs1uZgQWEMsMJ2UJSPf75PGtF8jURmTroOOo2lR4r jjRyRsqylOe/uUfXr6AAwMVqYh+tYqyp6r5RrJpRSoz61yZ4SCIrIyRnOCpXBI4dZ3ggEVBae5ab VdJxjXWGbSlWObdLpdQTnGCQkbPHiRjjkiqlq3k81neNV3KezbVyGXpCi0tUpvJRnzO5S8gYxgVD nkp1tg/+C/pTP8dWjClq5vMH0YgpUkKBCkkZBznNaF5WdIx9P3pFwhBpqJcCSlhtJHNrAG1u4YOc 7sccYrculIMi26WtcGW3zciPFQ24naCtlQABGRuqo8tjDStHMPqbSXG5aQhZSMpBSrIB6M4HrCsd JtVLIFI5FfRwv8Sc/WTW/K0HyK+jhf4k5+smt+VOI9sHzBrn0c3n8cc+GrFyLejpX4m58KaruufR zevxxz4asXIt6OlfibnwprYl+V4Em/a+SZuOz5OfTVfCa+tq+SZvzwk/hVfCaxYfayEfQejdT6ei aMtMeRfbay63FQlbbktsKSccCCdxqy2+92u7LcTbrnEmFsArEd5LhT4cE4r5RPCtrchHzyvH4Fr4 VVFSiorWuLG5HHENNqccWlCEAqUpRwABxJNRPdfpn7I7V7db8tZN+9D1y/FHf1DXylVKdLXuEi4c qk6JcdcSJMGUzKZLTYDjLgWkkJ37xurN5GRnXg/FXP3VQqvvIz6PB+KufuramtWnYk3/AIxwqAve uNOaeliJdLohh8p2ubDa1kDvhIOPHU/XyheXnJF6mvPOLccU+vKlqKid56TWrSpqbsyEfSll1lp/ UTimrVc2pDqeLZSpC8dYSoAkd/GKm6+f+Rr0eo/FnP3V9AVFSChKyIZ8+csIA1+/j0hr4Ko1Xnli 9H7/AOAa+CqNW7S9hFhVi5PQDr2zgjI7JG7xGq7Vj5PfR9Z/xkfAatL2WD6YAwN1Ys+7W61JQu4z 40NCzhCpDyWwo9QyRmsvGRXz7yxDGvXd+f8AV2/gNc+lDXdrkG6u7DTH2RWr2635a1xyz3y03Sz2 5u3XOHMUiQpS0x5CHCkbPEgHNaipWzGgou9ybF45HvogMfgHfgr6Fr565HfogMfgHfgr6FrFX9sh nzPyjfRAvH4f/pFVqrLyjfRAvH4f/pFVqtyHsokybb89In4ZH6wr60r5Ltvz0ifhkfrCvrStbEbi Gf/T6cvHzztH4Fz4RXhyF+iK4/ig/XFe/Lx887R+Bc/WFeHIV6Irj+KD9cVuf9Ek3hWJc4DFztsm DITlqQ2W14JG4jrBBr1kuczGdextc2gq2c4zgZqL0xqKHqqxtXOGlaEqJSttYOULHEZ6fCK0+0g+ cJlrfsuqFWuSPmkaSEHhvGRg7ieIwePTX1R0Vqnla0o85cIupWXk822WmX21k58+NnZAT3znJraq TkVmqz1oxZJoTlp9HKB/7Nv4VVickW/lDhfg3f1DWVy0+jlH4m38KqxeSL6IcP8ABu/qGs8fyvAk +h8Zr5s5TPoh3f8ACJ/UTX0pXzXymfRDu/4RP6iaw4f2iET/ACHtNuarmLW2lSm4ZKFEZKTtJG7q 3Eit6cK0dyGeiif+JH9dNbxqtb2wzCnXq12tSBcblEh84CUCQ+lvaxxxk7+I9esTuw0x9kVq9ut+ WvnPVsyTL1VczKkOyFNynW0KdWVFKAs4SM8AOqoeskcPdXuLGzuWm7Wy7SLQq3XCLMDSXQsx3kub OSjGcHdwrWNKVtQjqx1STuw+7GeQ8wstuNqCkrTuII4Gt+6WvSL9YI0tK1KcCQ2+VpwecAG13t/H d1+t8/1trkkmNrsEuGkK22JHOKJ4EKSAMfkn3q8zynwyqYRVEs4v3Gak7SsWnU/oWuv4m7+qasml fQjZ/wAQY/Zpqt6n9C11/E3f1TVk0r6EbP8AiDH7NNc/k5+6z/m+RFfaiWpSlejMApSlAKUpQClK UApSlAKUpQClKUAriua4qGDX0b6JmqPvIn7M1l3+39tbBOghvnFusqDaSrZysDKd/wB8BWJG+iZq j7yJ+zNTgzkYOPFXgdMTdPScprdqv3I3aXsHzSrIODxHGuKndaWVNi1NKispIjqIdZyDjZVvwCc5 wcjPeqCr6dRrRrU41IbGrmq1Z2Nhcifo3e/EXP1kVvo1oXkT9G734i5+sit9VrV/bKs4TwpndXzB rb0b3r8ddx+Uag+irLDtq9xY+uxx6v31r/lq9A7f463+qqrJocg6Isp4/wCpNb/+EVW+Wr0EN/jr f6qqx08qiQKJyK+jhf4k5+smt+V8t6SvjmntTQrih3m0IcCXidrBbO5WQk5O7fjrAr6fjSWJcduR HdS8y6kLbWg5CgeBBq+IT1rhnzzyk6auts1VPuEiKsw5b6nWn0AlB2iSEk9Cu8ffqxckOmb5B1Iu 6TLZIixex1t7b6NglR2SMJVgkd8DFbpxSodZuOqB0V8kzf6/J/Cq+E19RalvKbBp2bdCgrMdoqSk DOVHcM7xuyRnfwr5ZdcU66txWMrUVHHDJrJhltYR1ra3IR88rx+Bb+FVapra3IR88rx+Ba+FVZa/ sMlm17/6Hrl+KO/qGvlKvq2/eh65fijv6hr5SrFh95CFX3kZ9Hg/FXP3VQqvvIz6PB+KufurNV9h ks3/AF8n3lpxi9TmXm1NuIkLCkqTgjeeg76+sM54VHTNPWS4yDInWeBKeIALj0ZC1EDhvIzWnSqa jIRpDkbwNeIOR/VnN3rV9ACsWDarda0KRboEaGhZypMdlLYUes4ArKqKk9eVwz585YvR+/8AgGvg qjVeeWE51+/+Aa+CqNW9S9hEirHye+j6z/jI+A1XKsfJ6D3e2c9HZI+A1aXssH0znAr5+5Y9+vXc bz2O18Br6BBBFYM+yWq6LQu4WuHMUgYSqQwlwp8GQcVz6U9R3IPlGlfUnchpn7HbV7Sb8la45ZrL abVZ7cu32uHDW5IUFKjx0tlQ2eBKQK2o11J2sTcrXI79EBj8A78FfQtfPfI99EBj8A78FfQdYa/t kM+aOUb6IF4/D/8ASKrVfVMnTNgmSFyJVktz7zhytx2KhSlHvkjJrxOkNM49Dlq9pN/w1eOISSVh c+Zbb89In4ZH6wr60r5XfQhrV7jbaUoQmeUpSkYCQHNwAr6nqMQ72YZpfl4+edo/AufrCvDkL9EV x/FB+uKyOXffdLR+Bc+EV4che7UVx/FB+uKt/wBEG5p/zuk/gVfAa0lyP6q7WXs2aZIe7Gm4DDez tJS9nj1jI3dXXW7bh87pP4JXwGvk+LJehyW5MZ1bLzSgpDiDgpI6QapRjrRkgj//1NtXG3xLrEVE nR0SGFYJQsZ3g5BHUffrLHCoLR+oI+ptNxbgytS17Ibf2kbJ5wAbXDdx37t2+p2jyyBoLlp9HKPx Nv4VVi8kX0Q4f4N39Q1lctPo5T+Jt/CqsXki+iHD/Bu/qGt6P5PgW3H0RXzXymfRDu/4RP6ia+k8 gca+a+Uz6IV33/8AmJ/UTWDD+0Qix8hnoon/AIkf101vKtGchhA1RPz0wjj8tNbyByKrW9thnyrq X0U3b8de/XNRtfT9w0Tpm5pcTKsUJXPK2luIaDbhVnOdtOFbz36jfkU6J9Rf0p7+Os0cRFK1hc+c qVsLla0tZdMP2xFnhdjCQl0ufNVrzgpx54nrPCte1sQkpK6JFbY5I4XN2WbN5za598N7OzjGwM58 e171anSCo4AJ8ArfukbMzY9ORI7TbiHHEB18OZ2ucUkZB6scMd6vN8pq/N4Pm1tk7eCM1FXlc9tT +ha6/ibv6pqyaV9CNn/EGP2aarep/QtdfxN39U1ZNK+hGz/iDH7NNc3k3+6z/m+RFfaiWpSlejMA pSlAKUpQClKUApSlAKUpQClKUAriua4qGDX0b6JmqPvIn7M1N1CRvomao+8ifszU3Xz3Tv8AzCfh /wCqN2l7CIbVWmIuqbcGXdlp9v8AoX8E7BJG1uyM5AxvrSN7ssywXJcCajC070rHnXE9Cgf/AJwN fQ+Kw7nZrdeY3Y9xiNyEDzu0N6PARvHDoNbOiNOTwP8Ahzzh713fQTpqXeaFsl/uenZqplpk9jSF IKCvYSvzJ3kYUCOIFT3yVdbD/wCtn2qz/BVgunJE0oFdouK0HG5qUMgnPHbSBjd0YPhqCm8mN7gR HJT0qAUNjJ2HFk9X1Hfr21DTGj8Q0lNXe57fga0ouKuyqzpsi5TnpstznH31lbisAZUd5OBuFeFS /czO9NY/KPkrnuZnemsflHyV29SXA0+mYfroz4PKRq62wmYUS783HjoDbaOxmjspHAZKSaxr1rjU eoYIhXW5dkRwsLCOZbR5ocDlKQek149zM701j8o+SuO5md6ax+UfJVeZzvqjplDroiBuOanrNrjU lgh9h2y6LYY2ioILSFgE8cbQOPFXj3MzvTWPyj5KdzM701j8o+SpdNvah0zD9dEt8lXW3q3+is/w U+Srrb1b/RWf4Kie5md6ax+UfJXHczO9NY/KPkqOY/7R0yh10eF6v101FNEy7S1SngnYClJACR1A AADxCo+pfuZnemsflHyVz3MzvTGPyj5KlU5LJIdMw/XRD1K2HU950y465Z5nYynkhKzzSF5A4eeB 6+iu3czO9NY/KPkp3MzvTWPyj5KOm2rNDpmH66JSRyn6xlR3I7142mnUFC09jMjIIwRuTVUqX7mZ 3prH5R8lc9zM701j8o+SoVJx2IdMw/XRD1mWq73Cx3BE+2SlxpCMgLTvyOog7iO8azO5md6ax+Uf JTuZnemsflHyVZ05Pah0zD9dEsOVXWw/+t58MVn+Cufkra29Wv0Vn+CojuYnDi4x+UfJTuYnemMf lHyVTmV1SOmYfrol/kra29Wv0Vn+Ch5VdbH/AOtforP8FRHczO9NY/KPkrqrTktHnn4yfCsj91Vd OC2pe4zRqwk7L4MjpUuROlOSpbqn33VFTjqzlSj3zXlUp3PyBxkxfyz5K4TYZK/OOsq8G2f+mp1o 7LmVZrh35fEjK7sPLjvofbOHG1BSCQDgg5BxUj3OTyfMqax4SPhFenczNx/SMflHyVZJy2GGdelT 9qSJb5KutR/9a/RWf4K5+Strb1a/RWf4KhjpqeFYCmSOva/yrqqwSkDKnGgB0nb/AIaxuEFtXuLx nCWxom/kra29Wv0Vn+Coq+6xv2pWWmbxP7JbZUVoTzLaMEjGfMpGa8U6fkKGUyI3jWfJXZOm5ihl L0cjvKPkqVGnut7g5KKu/gzjTeopml7wi6QkMuPIQpAS8klOCMHgQffq4/Jw1N9Y2r2Fz4yqh3Mz fTY/5R8lO5md6ax+UfJUukp52uYZYmjH2pFv+Thqb6xtXsLnxlDy4anx/UrV7C58ZVQ7mZ3prH5R 8lO5md6ax+UfJUdHXVK9Lw/XRgOTnHLmq4FKA6p4vEAHZ2s5684z36v3ycNTfWNq9hc+Mqo9zM70 1j8o+SnczO9NY/KPkq0qOttRPTMP10ZGrNZ3HWL8Z64sxm1RklKBHSpIIPXlR6q6aU1fcNHzX5dv ajurfb5tQfQogDOd2CN+6vLuZnemsflHyVx3MzvTWPyj5KnmnbVtkOmYfrotj/LXqV9hxpUK1gLS UkpacyM/8da88BqY7mZ3prH5R8lcdzM701j8o+SkaLjsQ6Zh+ujL0pre66OMgW5EZ1EkDbbkNlSc jgRskHpPTVk+ThqbH9RtXsTnxlVHuZnemsflHyU7mZ3prH5R8lVdBN3aI6Zh+ujjU2ppuq7qLjPa YbeDYbwwlQTgZxxJ6689PX+Xpq8NXSEhpb7SVJSl4EpIIIOcEHp669e5md6ax+UfJTuZnemsflHy Vbmna1siemYfro//1Y48uGpz/wCitXsLnxlUi+XiRf7zJustDSHpKgpaWgQkYAG7JJ6Kye5md6ax +UfJTuZnemsflHyV1I0dV5I1+mYfroxLReJ9huTdxtr/ADMlsEJXsBWARgjBBHA1eRy36mA/qVq9 ic+MqodzM701j8o+SnczO9NY/KPkpKjrZtDpmH66Lf8AJw1P9Y2r2Fz4ynycNTfWNq9ic+MqodzM 701j8o+SpG18n13u6XFR34aeaIB5xahxz1JPVWCvGlQpupUyS3svDEUZy1Yu7PDVutrlrJcVdxYi tGKFBHY6VJztYznKj1VXwNrcMk9AFXtjkjvKngH58BDZUNopUtRA7w2R8Iq4Wbk5sFpUHnELnvAD fJAKM4wSEYwBv6c43b642I0/gKEPUlrPgr/E21Sk9xX+T/Qrzbou96jKZLRBjML2kOJWFAhZGRjh gA8c+DOyhgcK53DhXFfPtIaQq46tzlTwXBG1GKirIjNT+ha6/ibv6pqyaV9CNn/EGP2aarep/Qtd fxN39U1ZNK+hGz/iDH7NNeq5N/us/wCb5GtX2olqUpXozAKUpQClKUApSlAKUpQClKUApSlAK4rm uKhg19G+iZqj7yJ+zNTdQkb6JeqPvIn7M1OV8+06v+Pn4f8Aqjdpewjilc1xXEMoqM1LusEvPUnH 5QqTrhaEOoKHEJWk8UqGQa2MLWVGtGo1ezuY6sOcpuHE1VXdpl19wNstrcWeCUAknxCtpgAAAAAA YFc5Ne3fLPLKl7zgLQa3zNadqrlj+oSvYVeSvdnTt3ebDiISwD9WUpPrEg1sTJpk1rvlniberSXm /wChlWg6W+b9xqRcllBKS55oHBGDXXstj6o+sakDoy+vSlZiJbSpRO2p1OAPEc+9WQOT67E4L8RP hWr+Guw+UqS2xX33noo8mNDqK168r9jj/tZCqmtA7gojwV1M9vHmUKJ7+BVkY5OpR3yZzLZzuDaC rd48VJNcntrCBz0qUtXSUlKR4gQfhrUqcprbJLwRk9C6ApuzvK3a/lYpBngcG8/8X+VOzz6VuP8A aq+M6BszTgWtUl5I+lW4AFesAffrPj6WscYqLdtaJVx5zLn6xOK058qJrLWb8EX6FoCPs0G/F/OR rNU5WfMIA8JomS+4sIQ2ConAABOTW1BZLSDkWyJn8AnyVmJbbQkJQhKQOAA4VrS5UVt1/Mh09ExV oYZeJqxq06gkOhDdulJyM+aaKU+uoVkjS+psf1M56i435a2ZgdVK1Zcpsa9j97+pjvg17OGp+Kua 8Y0bqB1sKWqOyT9ItQJHrAj36zkaAkrbBduxQsjzQS0SAfDtD4KutK1KuncdU/j+/G4VWMXeFOEe 6EfoU9nk9a2/9aurzyANyUI2T65J+Coa9abbtErZTzjjC/OLX8G6tk1iXK3MXSKph9O/ilYG9J6x WbR2mJU8Up4r1ovJ5Lz8DFisVjZUXCjUcXutl8DV/YrP1HvmuwZbGMITu71Z1xt0i2SSw+k54pVj codYrEr6rQp4acFUpRVnsaSPE4jSGPm3CtVk7bnJj3qdPXSlbZzru9xSlKEClKUJuOAxXRTLSvPI Sc13pVZRjJWkrmSnWqUpa1OTi+KdjyMZknznrE11VCaPndpPgr3qSslpdu0oJ2FBhJ+aLScYHUO/ WhiaWDo05VakUklc61DTGlJSUIV5Nvi2/jc6WbScm6NKX2Wplkbkr2QoE9WNoEVnP6FuTOyIlwbd B89zqCnHg89V0ixmocdLDKAlCRwAxnv+GvbPRXzHEaexHPuWHerHcuz4+89bSq1HTUa6jN77xi7v yNbP6T1Gy5sttIeTjzyHEAe/g1jPWDUbDfOLguqHUjZWfWTk1tGmatDlJjorOXvf1MylhXbWw9P/ AEpGn3lzYrnNSY62XMZ2XEFJx4K6JnOA4UlJ8eK3EUg8QD4qxFWa1LUVKtsQqUcklhOT71bcOVFd e1ctGnomStUwq8DVXZ//ANr36GeOhv8AO/yrZsjTNkkpCXLayAPSxsfq4rAe0FZHnNpBksDHnW3N 35wJ9+tqHKmfWa8EWWD0DL2sO14v/cUMT2tnzSFZ72K5TNZUd+0PCPJVwkcncIoAjTX21Z3lwJWP eA+Go5/k8nhfzCZGWjrc2kn1gDW9T5Ttr214oq9CaBq5Jyj4v53ILstj6s/kmnZbA/8AMP5JqVd0 Bd0IJS5FcUBnYS4QT3t4ArAf0nfIzXOOW5eBjchaVn1kkmtuPKPW2OP34lPwtoeWUa8vFx+iPMPt KGecT4zis5FtuDjaVogyFJUMgpaUQR61Qj8STEIEiO41tcA4gpz69bdtRPaiFj0hH6orHjeUtXDx i1BO/azQ0hyWoYaEZQqtp9xrRSVIUULSUqBwUqGCPCKAHh75rateT0SNJIL8dp3HDbQFY9etWHLS N/XpPzOG9BvdM//WiM941btED5nMP9pG716nu1Vt9T4vsKfJXqxFjxQRHjtMhXHm0BOfWrzek+U9 DG4SdBQabtwttNLC6KnQrRqOSaR60pSvDHfFKVzjdSwIvU/oWuv4m7+qasmlfQjZ/wAQY/Zpqt6n 9C11/E3f1TVk0r6ErN+IMfs017nk3+6z/m+Rq19qJalKV6Q1xSlKAUpSgFKUoBSlKAUpSgFKUoBX BFc0oClXTR18Go59+sl4ituTEthUKTGJbXsJ2RtLB2hjeRgcd1YjjevIGyZFmtd1C8+ZgSyxzfh5 0b89GOqtgVxjjvrUr4LDYht1aab47H5rMupyWxmvuzdaH/YYj/8AKs14r1VIi5TcNL32MWv6d0Re cZax55W2D5pI3nIHCtjgAUrRloPANexbub+dyyrTNafJE0p6qZ/5d3+GsmHrXTU4rDN4jp2MZ54l rj1bYGfFV6lQYs2OuPMjtSGXPPtuoCkq3g7wdx3gVH9yOmfsdtRz/wCyb8la8uT2CexyXin8vmW5 5kbGkR5jCX4r7b7SvOuNKCknwEbq9DgHGa85fJno2bKVIesTKVqAB5lxbSd27clCgB4hWJ8jZgeZ RqnUqE8AkTxuH5Nac+TMb+pV81/X5FlX4oz8U6aj1cncqKOcter7y0/wKpq0ykbPT5ggb+G/NdHN Pa1gthEO92u5KUSVqnQ1s7PUBzZIPjxWtU5N14+xNPzRZVokpTFRDdr5QQ4kudzakAjaSlUhJIzv AODjw4rwXc9VxVFybot8RkefXFmtvuY/stjerf4K1JaBx62RT8V82i3Owe8nqb6qU7lBiWsINxsV 8hJcyEKkQw2FEcQNpQzSJym6ZkoUp2Q/EIOAl5kkq7/mNoevWvLQ+PhtpP4llOPEttcVFxtT2GWl tTN5hEu42EKkJSo54DZJyD3sVKHdjeDnfurRnQqQ9qLRa9xSucY41xWEkUpSoApSlAKUpQGNcLfG uUctSGgojehR+lPXVHu2n5dsUVc2t9gb+eSnA8YyceE1sGuHG0OoKHEhSDxSoAg13tFacxOj5asc 4b19OBz8XgKWJV3k+Jqogg4NKvNx0pCl7S4x7GcO/wAyMpJ8HR4vWqvy9LXSKgrDQkJAySyrOPEd /vV9GwXKDA4pJKerJ7n9dh5mvo3EUbu11xRDUodyiN+RxyKV3E01dHPaadmKUrkJKlBKQVKJ3JA4 0bSzYSbyRximD1E1NQ9KXKUlK1BEdJPB0kKx4APhxVkt2mLfAIW4jsh4bwtwbge8ny5rz+N5RYDD JpS1pcFf47DpUNGYiq7tWXEr1l0w9PLcmThuKreOlTg73eq6x2GokdEdhGw0gYSMk49evTGKV840 ppjEaRneo7RWxbl9X2np8JgqeGjaO3iKUpXGN0UpSgFKUoBXOa4rnGeFSQKUwfAOs1FSdT2GIlwv XmEC1nbQmQlShjiNkHJPexWaFCrP2Yti6RK0qpS+U3TMZAU0+/LJOClhk5T3ztbI9+uYHKFEuiVq t1jvkwN42ux4gcAzwzhW6t+GiMfJXVJ/ArzkVvLZTxVBJl6zlkJjaQTHS7/Rvy56MIB4KWhI2vCB vr07V8oh+m0z+VI8lbEdA497YpeK+TK87BEzjfjIB79cYOdwz4KiG9Ma4mOLXL1JAtqQAENwYheS rrJK8EdHh71ZHyOA6NuRqvUS3VDzZbmBCCenCQk7IzwHRW3T5N1pL15pebKutHcSFYsu5QLeUibO jRSvOzzzqUbWOOMnfXmnkxtbh2bhd75c458/GlziW1noJCQDuO/jUhA5PtI20LDFgiL5zGeyEl/h 1c5nHirahyZgn69VvuXzv8ivP8EVlzlA0q0tSFXZJUkkHZZcUCR1EJwfFXCNe2GQoNW9cq4yVecj RIjinFdeAQOA3nfwFXZjTGn4zyH2LFbWnW1BSFtxG0qSRwIIG41J4z01uR5P4GO+T8V8kVdaR//X sCL5fZ+Ta9G3NYRuX2aURDv4bO2TtdPDh467mXrYnZTojA6Cbqzu8OK2DsjINNkdVciOhsAlbm/e /qZXVkUB/TGubtGdgXCdY4kWQgocdituuuAEcAFYG/hx4E431dbTANstMOBzgc7FYQzthOztbKQM 4yccOusuua6VKjTox1aUVFdhjcm9opSlZSBSlKAUpSgFKUoBSlKAUpSgFKUoBSlKAUpSgFKUoBSl KAUpSgFKUoBSlKAUpSgIiZpTT09bzkqx2511/POOKjI21E8TtYznv5zUJ8ijRYPzl/Snv46uVcVK lJbGCnq5M7I00GrXJudoTtbS+wpyxzh/tbe0OjoxXgrQt+jr5u261ltRxvCZcRuS4D0+bJGe9u3V d6YrDUpU6v5kVLvSfxJUmikt6R1YwsujV7EpSQSlp61oShZxwJSrI8IrGVF5QYQ5523WS5J4cxDk Lac8O055nHv1f8UxWtLR2DltpR8rfAtzkuJr3s3W2d+h/wD+1ZrqnUk1t1MebpK+MupOHCxE59pJ 6cLSfNDvgVsQpzXGyK156FwEv+nbub+tiyrTNbHlC0ohRSbopJSSCFR3QQfyayIetdNTVKDV4jpK Rk88S1+uBmr5Jhx5jC48pht9lwYW26gKSodRB3Go3uP0yBjuetftJv8AhrTlycwj2SkvL6FufkRk aXGmsh+LIakNEkBxpYUkkcd43V7e/XM3k70jPcS49ZGEKQMDscqYHjDZANYb3JvDcdUprUWoo7Z8 6y1cDsIHUNoE48JNalTk1+nU819Cyr9hljjgUxvqPc5PJMZActmrr03IHBcxxMlGOnzBA39/NeSt O62gtARL7bLotSskzoimdgY6C2Tnxjx1rT5N4j+GcX5/Qsq8STUAsFKgCDuKTWL2pto/+nxvG0ny VhdquUToXpn15G73q7KkatjyC3I0oHWW/PvxZzatoAbylCtlR8BwaxehdI0U9R+Uv7Bzpy9ozE2u 3JUFCDGBG8EMp8lZXgFV1WqLm+UtQNG31x9agEiTH7Hb8azkDx16hGv5zv8Aq9jttrbSnJM6Vz22 c9HNcPGPHWNaH0jXV5rzZKlThsJ0bxXPg3moVdr5RVIKUO6ZSSMBSefyO/vBrsnQ2pJaW03LW7/N ZBdbiw0Mr74DgOfGR4q2I8m8U360orxf0HPxJjG7dv8ABXCiEpKlEBKRkkncB11h/I2YI36q1Mf/ AMgP4a7Dkr0m4kKmxJM9/wCnkSZbpccPWrZUBnxVsQ5NO/8AiVPJfUq663IwZOrtOxGS65eoakg4 w08HFfkpyferC+SLpMnHbX9Hd/hq4t6L0u0hKE6etmEjA2ojaj4yRk1mQLHaLWtTlvtcOItY2VKY jobKh1HZArdjycwiXrSk34L5Mo674FFTrSNJTztstF5ujHDn4cFSkZ6Rk4316i4axUkKa0OtTZ3o K7k0lRB6wRkHvdFbC2BnNNkVtQ0JgIL2L97fysRz0jXqEcoE9zZZsVttaUpyVTpfPBZ6hzW8eMeO spOltaTE87K1RCtznDmYUEPN469pwhWe9V5xTFbUdHYOOylHyv8AG5V1JPeUcaI1I6Q3L1u8uOo4 cDFvbaWU9OysE7J7+K9UcmNndOLpOu13aHnWp01SkoP1QCdnfVzxStmnRp0vy4qPckvgirk2U48l GiiR/wCC/pT38dTcPSmnoC2XI1jt7TrGObcTGRtpI4HaxnPfzmpauazOUntZUUpSoApSlAKUpQCl KUApSlAKUpQClKUB/9Dc1KUoBSlKAUpSgFKUoBSlKAUpSgFKUoBSlKAUpSgFKUoBSlKAUpSgFKUo BUTcdTWq13Ju2yXJCpjrXPIZjxHn1FGcbWG0q3ZqWqmSvozwf9yOftaAme6u3fW139xpfxVO6u3f W139xpfxVdVXGUFEB3p+pHkrjtjL9N/NHkrzj5R4RO2rLyX1M/MSO/dXbvra7+40v4qndXbvra7+ 40v4qunbGX6b+aPJTtjL9N/NHkp+JMJ1ZeS+o5iR37q7d9bXf3Gl/FU7q7d9bXf3Gl/FV07Yy/Tf zR5KdsZfpv5o8lPxJhOrLyX1HMSO/dXbvra7+40v4qndXbvra7+40v4qunbGX6b+aPJTtjL9N/NH kp+JMJ1ZeS+o5iR37q7d9bXf3Gl/FU7q7d9bXf3Gl/FV07Yy/TfzR5KdsZfpv5o8lPxJhOrLyX1H MSO/dXbvra7+40v4qndXbvra7+40v4qunbGX6b+aPJTtjL9N/NHkp+JMJ1ZeS+o5iR37q7d9bXf3 Gl/FU7q7d9bXf3Gl/FV07Yy/TfzR5KdsZfpv5o8lPxJhOrLyX1HMSO/dXbvra7+40v4qndVbfra7 +4sv4qunbGX6b+aPJTtjL9N/NHkp+JMJ1ZeS+o5iR27qrb9a3f3Gl/FUOqrcf/TXf3Gl/FV17Yy/ TfzR5KdsZfpv5o8lPxHhOrLyX1HMSO3dVbvra7+40v4qh1Vbvra7+4sv4quvbGX6b+aPJTtjL9N/ NHkqPxHhOrLyX1HMSO/dVbvra7+40v4qndVbvra7+40v4qunbGX6b+aPJTtjL9N/NHkqfxHhOrLy X1HMSO/dXbvra7+40v4qndXbvra7+40v4qunbGX6b+aPJTtjL9N/NHkp+JMJ1ZeS+o5iR37q7d9b Xf3Gl/FU7q7d9bXf3Gl/FV07Yy/TfzR5KdsZfpv5o8lPxJhOrLyX1HMSO/dXbvra7+40v4qndXbv ra7+40v4qunbGX6b+aPJTtjL9N/NHkp+JMJ1ZeS+o5iR37q7d9bXf3Gl/FU7q7d9bXf3Gl/FV07Y y/TfzR5KdsZfpv5o8lPxJhOrLyX1HMSO/dXbvra7+40v4qndXbvra7+40v4qunbGX6b+aPJTtjL9 N/NHkp+JMJ1ZeS+o5iR37q7d9bXf3Gl/FU7q7d9bXf3Gl/FV07Yy/TfzR5KdsZfpv5o8lPxJhOrL yX1HMSO/dXbvra7+40v4qndXbvra7+40v4qunbGX6b+aPJTtjL9N/NHkp+JMJ1ZeS+o5iR37q7d9 bXf3Gl/FV72nUNsvb0pmC66p2GpKX23o7jKmyoZAIWkHeBWMm4yyoDnen6keSojSHo81p+Mxv2Vd LA6RpY7W5tNWtttv8WUnTcNpc6UpXRMYpSlAKUpQClKUApSlAKUpQClKUB//0dzUpSgFKUoBSlKA UpSgFKUoBSlKAUpSgFKUoBSlKAUpSgFKUoBVMlfRng/7kc/a1c6pkr6M8H/cjn7WgM5fn1eGuK5X 59XhrivkctrOmKUpVQKUpQClKUApSlAKUpQClKUApSlAKUpQClKUApSlAKUpQClKUApSlAKUpQCl KUApSlAKUpQHKfPjw1g6Q9HmtPxmN+yrOT58eGsHSHo81p+Mxv2Vex5M7Kvh8zVxG4udKUr1prCl KUApSlAKUpQClKUApSlAKUpQClKUApSlAf/S3NSlKAUpSgFKUoBSlKAUpSgFKUoBSlKAUpSgFKUo BVMlfRng/wC5HP2tXOqZK+jPB/3I5+1oDOX59XhriuV+fV4a4r5HLazpilKVUAkAZJwBWtdT8qTj ElyHYmmzsEpVJdG1k/2R+8+tV5v8ObPskqJb3W2pDyNhK3CQADx4A9FUDTfJrOhaiQ5eGo78NpO0 FIXtIWroGDg+uK9doCloqnSqYrHNSlH2YPf4b77Eu8wVnUyUCAZ5StVNPJWu4IeSk5La47YSrw7I B9Y1snRusmdUxVpcbSxMZ/pGwchQ+qT3u9WPylR4StIuuPobDjSkhhRG8K6h4qovJeHu65JaCtgM q5zHDG7jXexGH0fpbQ1THUqCpShfZbd3JJ37tpr3nSqKLd7m6KUqg8oete1jarPbXB2U4nDzg/8A KB6B3z71eE0bo2vpHEKhRWb2vclxZuzkoK7MPW3KLIiTewLBISlTR+bSAhKwT9SMgjx1LcnN7vN9 iy5N0l8+hCwhv5mhOD0+dArTzzLzKhzyFIUsBQ2hgkHga3VybQuxNIMLIO0+oueI8K+gco9G4HRm h406ME5Npa1lrPe3fbuNGlUnUq7ciH5RdXXWx3KNEtUvmMt7TnzNCsnO7zwNU/5I2rPVX9Ha/hrc 0qzWqc9z0y2Q5LuMbbzCVqx4SKw5dj0zBiuSpNntjbLSSpajFb3D1q4+jtN6Ko4enQng1OayvaLb firmepSqSldSsal+SNqz1V/R2v4asehdV6kvuo0Rpk/nYyUKU4nmW0+DeEg1Ubk93TahDVqtzEZD i+bYZYaSgY6zgbz01uLSul4mmbcGm0hclYBeexvUeod6u/yjnozBYHU6PCNWoskoxvHtulu+Jr0l UlOylkicpSlfJzonR11thpbrqwhtAypSjuArV+ouVWUp9yPYm0NNDd2S4naUo9aQdwHhBqc5VLm5 D083EaVsmW5srx9SN+Kq3JhYIt0ub0yY0l5EUDYbUMgqPSR3q99oTRmCw+jZaVx0NdL2Y7ttvG74 5GpWqS1lThvMKLymaojyEuPTG5KBxbcYQAfGkA+/W09LamjantnZLSeadQdl1onJSfJWByiQYsnS Up55pBcYAU0vG9J7xqiclc1cfU6owPmJDSgR4N4rYxWGwOl9ETx2HoKlOnuVrNLbsSTyfC5S86VR RbumXLlG1JPsEGKLbI5h95w5VsJV5kD+0DWvvkjas9Vf0dr+Gt0zLXb7iUmdAjSijckvMpXs+DIr FVpvTyElSrJbUpSMkmK3uHrVzNF6a0VhcLGjWwinNbW1F3z7VczVKVSUrxlY1B8kbVnqr+jtfw1J 6c1rqq66ghwl3LbbddAWOYaHmen6WorV9zg3W89i2a3RY8ZpWwgx2EoU8rrJA4dVbI0Po1nT0JMq ShK7g8nKlEZ5oH6Ufvr1emKmi8Fo5VKmFhGpNPVjqxuu15bvjkasVUlPVUi1OutsMreeWENoBUpS jgAVq/UPKrKW8tixNoaaGR2Q6naWo9aQdwHhB8VZvKtfyzHasrCyFO/NHsH6XoHjrB5LtNMTFu3i Y0l1LSthhKhkbXSfFXA0VovB4HRr0ppCGvf2YvZ2d9+3K2djPVqSc+bgRUDlP1JFkBcp9qa1wLbj SU+sUgb/AF62vYb7E1Da0TohIB3LQeKFdINVDlagx1WiNN2EpkJd2NrAypOOGawOSGS52TPi5PNl CV47+cfvrNpTB4HSGhvSeGpKlJbUtm225Jdt7IrGU6dVQbumbInTo1thOzJboaZaTtKUa1Xe+VW6 SXlN2dCIbAPmXFoC3D6+UjwYPhr05VL+ZNwbszCzzUfzT2DxWeA8QqW5L9NMNW/t3JaSt90kMFQz sJHSO+apgdHYLRWjFpHH09ecvZi9mezs2Zu6dluLVKkpz5uBXrTypX2JIHbFTc5hRG0C2lCkj+yU gD1wa2zbbjGu1vanRF7bLqcg9I7x79a25XIUdqXBmNoSh50KS5gAFeMYJqV5JJLjlllx1ElLTwKe 9kb/AIKjTmBwWK0VDSmFpqm3tS2bbdiye9JXK05ThV5uTuX6lKV8+N05T58eGsHSHo81p+Mxv2VZ yfPjw1g6Q9HmtPxmN+yr2PJnZV8PmauI3FzpSletNYUpSgFKUoBSlKAUpSgFKUoBSlKAUpSgFKUo BSlKAUpSgP/T3NSlKAUpSgFKUoBSlKAUpSgFKUoBSlKAVTJX0Z4P+5HP2tXOqZK+jPB/3I5+1oDO X59XhriuV+fV4a4r5HLazpilKVUCofVl1cs2m5c1hYQ8hIDZIzhRPVWDeuUCw2SQuK+4+9IbVsra ZZOU+NWAfEan4Mxq4QWZjG1zbyAtO1xwa6ccLXwcqWJxNF6jd7PJStnbNbH3FNZNuKeZoC6X+6X5 5s3We48lJwPMgJT1kJGBmtvaFsVptdnTJtskTFSQCuRjBPex0Y6qqHKxboUa4RJTCENyJAVzoSAN rH0x7/fqQ5KpbjNjuSnFEsMK2wOrzOTX0LTkunaCp18L/hwbXqKyTu7WyW57Nz4GlBOFfVlmTeud Yt6dhGNGUFXB9PmB0Nj6o/uFUnQ2kHtRTjdrntKiIXtHa4vq8nXVTuk565XJ+XIdU4t1ZO0rq6Kl o2vNSw4rcaNcUtMtp2UITGaAA/Jrp0tAYnA6O6PgJRVSftSd0/Cyfhw27Sk60Zz9bYjz1fIM7Vs3 YA2Q7zTYHDA3Ct32WKIVlhxh/wCWyke9XzwJDokiTt/NQvb2iB57Oc1t/k4vV5vkSXIukrn0IUEN /M0Jxu3+dArm8scBVWj6Ti0oU8ntu27JWy+ZahNc63xLrWr+VPUhW6ixRlkJRhcgjpPQmti3W4N2 q1yZzpwhhsq8J6PfrRNtiyNU6oQ24Spct7acV1DOT71cPkfgKbqT0hX9iksu+23wXxNjEz1Y6q2s v3JdpsRoZvclHzV8bLGehHSfHWwHXUMMrdcVsoQkqUeoCuI8duLGbjsp2W20hKQOgCsDUbM2Rp+Y xb2+ckuNlLadoDJPfO6vO4vFy0rpHna0rKUks3ko3+SMlOHNwsRnyRtJ+q36O7/DXvC1zpu4zGoc S4l1907KEcw4MnwlOK1X8jnVnqV+kNfxVYdEaHvds1I1NucHmGWkkhXOoV5ro4E16vG6C5P0MNOp SxWtJJtLXg7vdklc11WrN21fcya5U7U9OsLUthJV2IvaWAPpTuz4qo+h9Xt6WlPCSwt6M+Btc3ja SR0jOM+vW2bvqexWZXMXOe02tYwWsFasd9KQSB4ar6tAaT1G23c4CpDDLw2h2MrYSrv7K0nHgGKp ovSlGlovoek6UuafsySdnvtfLO+atctVp609aDzRUta6/Go4yYEGO4xECgpanSNpZ6sDIA8dePJi ypzWDSwMpbaWT3t1eOubVaLFOYtdrSpS2kbT7ri9pSieAPQN3UBVn5JbSpDUq6uJwF/Mm89ON5Ne kx1TB4Pk7J4aLjCask9r1t771n3GvacqyUtpsmqLynakNutqbVGWRIljzZHFKP8AOrw64llpbqzh KElRPUBWgb1Of1Pqh11GVGQ6ENDqTnArx3JDRscTi3iavsUs/Hd5bTbxFTUhltZaOS7TYmTFXqSj LUc7LIPSvr8VbYrBslras1ojQGRgNIAJ6z0n16zVZ2DjjiuNprSUtJ46VZv1dkexbvqWoU9SFt5o PWM9Vx1XOeJyEuFtPeA3VuLR0AW3S0FjGFFsLVuxknfWj5iT2+fSsYPZSs5++r6FiAJhsBPANpx6 1ey5aS5nB4bDQ9n6JJfE18P61WUma95XpgEaBCB3qWpw+ADH76xuSVnm+2c4jzLaAnPv/uqA5RLs m66pdS0oKajDmkkdJHH3/gq/6Rszlp0I4FpIfktqdUD0ZG4et8NZ8ZFYHk7Rwk8pVHH3vWflsHt4 juNS3GQu63x98kqVIfOOvBO73q+gLVDTb7TFiJGAy0lPjxv9+tBWBKVX+ClfAvpznw19DqUEJKlH AAyT1Vq8upuMsPh47Em/gkMLnKUmam5W5gdvUSID/QMlR/4j/lU7ySxi3YZUgj+lfwPEP8617qi4 m+aolSGvNpW5sNY6QNwrdGlrUbLp2JCV/SJRtOffHefJWXlC1gNA0ME/adrruzfvYh6+IcuH9iXp SlfMTeOU+fHhrB0h6PNafjMb9lWcnz48NYOkPR5rT8Zjfsq9jyZ2VfD5mriNxc6UpXrTWFKUoBSl KAUpSgFKUoBSlKAUpSgFKUoBSlKAUpSgFKUoBSlKAUpSgP/U3NSlKAUpSgFKUoBSlKAUpSgFUyV9 GeD/ALkc/a1c6pkr6M8H/cjn7WgM5fn1eGuK5X59XhrivkctrOmKUpVQaz5StISX5JvdvZU6CnEh CBkjH02OrHGq1Y+UG92CAILCYz7KT5gPoJKB1Agjd4a3jWDIsVnlvKfk2qE+6rzy3I6FKPjIr2uC 5T0eiRwmkKHORjse/LZ/e+w1p0G5a8HZmkEov2uL1tYXKkKwCrGENJ7+NyRW5tPaejWKxotoCXgQ eeKhkOE8dx6Kk2I7EVlLMZltlpO5KG0hKR4AK9K0dM8oamkYxo0oc3SjsS7NnDZuS2E0qGo9Zu7I zuZsHqHbvajfkqv65tdjtmlJb7NpgMuqAQ2tEZAUCT0EDdVzrxlwok9nmZkVmS3nOw82Fpz14Nc3 A6Sq0MTCrVnJxi02rvOxlcE1kjTXJtamLpqQ9lR2pDDLRUpDqApOTw3GtyRIMSA0WocVmM2TkoZb CBnwCvOHarbb1qXBt8WKpYwosspQSO/gVl1tad0zLSmJdWN1GySV+HuMdGlzasyicq9zMaxsQEHC pTmVYP0oqH5JLVzkyXdFp3NJ5ps46TxrZMy1W64qSqdAjSlIGEl5lKyB3siu8SDDgNFqHFZjNk5K WWwgZ8Arbjp2nS0M9HUoNSe18c8/dkJUnKopt5I96UpXlTOKUpQGtOVHTMmQ63eobKnUpRsSAgZK QOCvBVXsuvr1YrYbfF7HW0M7CnUFSm89W8D1wa3nUe7p+yPuqeds8BxxRypa4yCSesnFe2wPKehH BxwmOoc5GOzw2XT4fA1qlBuWvB2Zpix6cu+sbop9XOFta9p+Wsbu/g9J7wrd1tt8e1W9mFFRstMp 2R3++ayEpShIQhISlIwABgAVzXK03p6tpWUU1qwjsivnxZalRVPPays8oNzNs0nJKDhx/DScHB38 TWvOTO1dn6nTIWnLcNPOHI+m4CtwzIEK4NpbmxGJKEnIS82FgHrwa6w7Zb7eVGDBjRdvz3MtJRnw 4FbOC07TweiamCpwevO95bs8vgKlJzmnfJGVSlK8qZzTfKHpWTa7s7dI7SlQpCtorSNzazxB6vDW KOUfUKbOm2pcYSEo2A+EHnceHOOHerdxAIIIyDxFR6NP2Vt4PN2eAh1J2gtMZAUD15xXu8PyroTw 8KePw6qShseXvuvPjwNWVB6zlB2uas0RoeVeZjdyuLS24KVbY29xePe73frcJQkt83gbOMY71dqV 57S+mcRpSvztTJLYlu/rxZlpUlTWW00Zq/TU3TN5U+2hYiOObcd9I3A8dnvEV6XHlF1BdLZ2vcWy 0lQ2VuNIIW4OonJG/vAVu1xtDzam3UJWhQwpKhkEd8Vhx7FZ4jyX41qhMOp86tuOhKh4wK9LT5XY epTg8bh1OpDY8vPNZe/iYZYdqTcHa5rvk/0LIVKavN1ZU003hTDKxgrPQojoHw1tKlK8rpXSlfSe Idet3JbkjPSpKmrIUpSuUZDlPnx4awdIejzWn4zG/ZVnJ8+PDWDpD0ea0/GY37KvY8mdlXw+Zq4j cXOlKV601hSlKAUpSgFKUoBSlKAUpSgFKUoBSlKAUpSgFKUoBSlKAUpSgFKUoBSlKAUpSgP/1dzU pSgFKUoBSlKAVTJX0Z4P+5HP2tXOqZK+jPB/3I5+1oDOX59XhriuV+fV4a4r5HLazpilKVUClKUA pSlAKUpQClKUApSlAKUpQClKUApSlAKUpQClKUApSlAKUpQClKUApSlAKUpQClKUBynz48NYOkPR 5rT8Zjfsqzk+fHhrB0h6PNafjMb9lXseTOyr4fM1cRuLnSlK9aawpSlAKUpQClKUApSlAKUpQClK UApSlAKUpQClaXvt9vDOoLi01dpqG0S3UpQmQsBICzgAZ3CsDuhvnqzP9sr8td+Gg6koqWuszFzq N70rRHdDfPVmf7ZX5ad0N89WZ/tlflq3oGp10Rzq4G96VojuhvnqzP8AbK/LTuhvnqzP9sr8tPQN Troc6uBvelaI7ob56sz/AGyvy07ob56sz/bK/LT0DU66HOrgb3pWiO6G+erM/wBsr8tO6G+erM/2 yvy09A1Ouhzq4G96VojuhvnqzP8AbK/LTuhvnqzP9sr8tPQNTroc6uBvelaI7ob56sz/AGyvy07o b56sz/bK/LT0DU66HOrgb3pWiO6G+erM/wBsr8tO6G+erM/2yvy09A1Ouhzq4H//1tzUrRHdDfPV mf7ZX5ad0N89WZ/tlflr0PoGp10YedXA3vVN1HYNTuaxi6g065adpqCYqkXAuYOV7RICB4Omtdd0 N89WZ/tlflp3Q3z1Zn+2V+WnoGp10OdXAv8A2NymekaN/Ik07G5TPSNGfkSaoHdDfPVmf7ZX5ad0 N89WZ/tlflrF+Glxj5FufL/2NymekaM/Ik07G5TPSNGfkSaoHdDfPVmf7ZX5ad0N89WZ/tlflqPw 0uMfIc+X/sblM9I0Z+RJp2NymekaM/Ik1QO6G+erM/2yvy07ob56sz/bK/LT8NLjHyHPl/7G5TPS NGfkSadjcpnpGjPyJNUDuhvnqzP9sr8tO6G+erM/2yvy0/DS4x8hz5f+xuUz0jRn5EmnY3KZ6Roz 8iTVA7ob56sz/bK/LTuhvnqzP9sr8tPw0uMfIc+X/sblM9I0Z+RJp2NymekaM/Ik1QO6G+erM/2y vy07ob56sz/bK/LT8NLjHyHPl/7G5TPSNGfkSadjcpnpGjPyJNUDuhvnqzP9sr8tO6G+erM/2yvy 0/DS4x8hz5f+xuUz0jRn5EmnY3KZ6Roz8iTUnoGVImaXbelSHX3C6sFbqypWM9Zqy1w62DpUqkqb isnbYZFJtXKP2NymekaM/Ik07G5TPSNGfkSavFKxcxS6q8kTrPiUfsblM9I0Z+RJp2NymekaM/Ik 1eKU5il1V5Iaz4lH7G5TPSNGfkSadjcpnpGjPyJNXilOYpdVeSGs+JR+xuUz0jRn5EmnY3KZ6Roz 8iTV4pTmKXVXkhrPiUfsblM9I0Z+RJp2NymekaM/Ik1eKU5il1V5Iaz4lH7G5TPSNGfkSadjcpnp GjPyJNXilOYpdVeSGs+JR+xuUz0jRn5EmnY3KZ6Roz8iTV4pTmKXVXkhrPiUfsblM9I0Z+RJp2Ny mekaM/Ik1eKU5il1V5Iaz4lH7G5TPSNGfkSadjcpnpGjPyJNXilOYpdVeSGs+JR+xuUz0jRn5Emn Y3KZ6Roz8iTV4pTmKXVXkhrPiUfsblM9I0Z+RJrM0bYL7a7ne7nfnLeqRdHGl7MErKE7CSn6cZHR 0mrZSrxpwh7KsLtilKVcgUpSgFKUoBSlKAUpSgFKUoBSlKAUpSgFKUoDRGovRLdPxx79c1HVI6i9 Et0/HHv1zUdX0ej+XHuRpvaKUpWUgUpSgFKkbDaHL3dmoaMhBO04sDzqRxP7vHVq1BoW32uySJsV +Ut1kA7LikkEZAPBI665WJ0vhMNiYYWpL15Wt45K5kjTlJNoolKUrqmMUpWZarXJvE5MOIE84oE5 WcAAdJrHVqwpQdSo7JbWTtMOlTOo7G3YJDETsgvvKb23FAYSMncAPFUNVcPXp4ikqtN3i9hMouLs xSlKzFRSlKAUpSgP/9eu0pSvphpClWHT2kZN8aMpb6I8RJIKzvUcccDy1g2yDBl3wRZUnseJtKy4 pxKSAOG87q0PSOHvUUZXdP2rZ27O/sLarsnxIylS+o4Fqt85DNqlqlN7GVLLiVjPUCkVEVs0K0a9 KNWKaTzzyYkrOwpSlZiopSlAKUpQClKUBt7k59CTX4Vfw1aqqvJz6Emvwq/hq1V8/wAd+9VO9m3H 2UKUpWmWFKVS9Ua8lWuZIt1jsy7pLioC5K1OBtpgE7sk8T3t1OwlK5dKVA6Y1P2/RIYkwHbdcIig mTFcUFbJPApUNygeuvCfre2xdVwtOMFMqZIWQ6EOf0Ax07jv726m+xW+Vyy0qD1XqJem7W3JYg9n SHnkstR+dDZWpR+qINY9lveqZ1xSxddH9q4xSSZHbNp7B6BspGd9FmS8iyUrgnAyapMnX9yeeluW HSki7W+EsoelplIayoee2EEErx3qXFi70qHY1Ta39Md0QdUiEGy4orGFJxxBHX0Yquo5RLkyI8+5 6RlwbLJUAicZKFqSD51SmwMpB8Pr032G65eqVwlSVpCkkFKhkEdIqFY1Fz+sJOnuxdnmIqZHP85n aycY2cbvDmm+w3XJulKUApSlAKUpQClKUApSoS4ajFt1NbrO/Fw1cUr5uTt7g4n6Qpx09eab7DtJ ulYN5ujNltEq5SN7cdsrIzjaxwHjrtaZj9wtMWZJi9iuvtBxTO3t7Gd+M4GfWoDMpXB4VDaZ1F3R MTnOxex+w5rkXHObe3sY81wGM54UHaTVKxbi/LjQHnoMPs2ShOW4/OhvnD1bR3CvZhbjkdtbzXNO KQCtva2tg43jPTjroD0pXVathtSsZ2RnFRGlNQd0+n2Lt2L2Lzyljmuc28bKiOOB1dVB2kzSlKAU pSgFKUoBSlKA0RqL0S3T8ce/XNR1SOovRLdPxx79c1HV9Ho/lx7kab2ilKVlIFKVO6RshvV5QlxO YzGHHu/1Dxn3s1rYvE08LQlXqbIq/wB95KTbsi16Yhs6Y0w9eJiQHnkc5g7js/Sp8J/f3qyLPLcv mh5in1bbykvBXh3kfCK979dtLuqNtu8jaLKgotgO4Bxu3o7xr3025p9cZ+PYlZaCtp1PzTiRj6fw dFfLK9apKi8XWpTVRzjPWcfVUVsSfjw4G9FKLUUzVVvimZco8UAnnXUoPgJ31cuUCNbrfCiR4sKM w64sqUptpKVYA6wM9PvVG6Stx7tS0sZ7ELiju6R5n99Zms48u8avZtzDS1bLSQCBuwd5V4Bn3q9f isSqmmaacrQpwcnnln9pmCMbQk/AznLdb4HJ6JTkCMqSqODzimkleVHrxndn3q9+T523u28oYhlM pgYdkKbSNraJOArOTwrrygvJiafiwUHZ23BgD6lI/wAxXpoFkQtMvTVJ/pFqX4QkY/ca83Xcqug5 Vpt61Spln22t3ZMypWqRiuBH6omwdQXJNmgxB2f2RsLkrbSNyQc+a448lZ0iDpbR8RsTYolvuj6d sOLVjpAO5I9bx1XtFPpd1hzrysrdSsgnpUd/lrvyhMye6FK1tqLS20pZONx6x4c11eh/8bT0Xzko 04x1nZ2cn38Fw3WK611KoTM+xWXUlhVc7PHTGdSglIQjYBxxSpI3Z749eonk/tcedPlOS47b6GkA BLqApOSeo+CrDZGFae0Q67NHNrKFOFKugnzoPvV4cn6ExrBKnLAAW4pZP9lI/wD3XPnjK0NG4mlT m5RU1GDvnt2X7l7ydVSlFtZnKhpODqMwFwW35UheCAyktNdSccB4geNdb7YtM2iULrNaKWlbkxGh gLX1gZG7vbh69V3STarnrJMhw7ZSpbyien/5msnlElqkX1qInJDLYGyPqjv8lbscFVjpSGFjWnbU vN39y4bvAjWTjKVibvNrslz0kq5w4DcUhvnG1IaDahw3HZ4+/ULo/Sce5x1XK5ZMZJIQ3tbIVjiS eqpzVCk2vQrURO7aShoAev8Aurvb0uP8nOxBG26Y5ThPEnPmh4eNaNDF4mno1Rp1GlUq6qk3mo9/ 3vLaqlOKa3HjGuWjbhcO1TVsZyvKEu9jJSlR7yh5oeHdVc1FYounb9HUQtyA4oL2PPHAO9O/jXho 61yJ1/ZWltXNR1bbisbhjgPDUzr99E29wrc0QpacBWOgqO4etXWo01gtK9Eo1JSg4Nzu727ex7DG 3r022i2pn26Dpzs9MQsQ+b2+ZS2lJwejZG7O+q1pxi13/UU6a3bWUw0NpShlxlOM9JwN2d1Zmu3e wtLsxEeZ5xSU7uoCumgWhC03JnKT55Sl56wkf5V5+hR5nRNTFQbU6stVZ7r/AByeZlbbnGB//9Cx 2Rm1zNV3WKq3Q1NNkc0nmEkDG443VV59lU9rB21x2wgLfISEjASnr9avfSE7Y1ghxSv6wVp9ff8A uq+Lt8a23adqCQQAGgB3gBv8ZNbuJxdTRONqQi23OnHVX/dlH+pVRVSLtxK7q9i2W2FGtMG3xezJ GE84GU7YHDOcZyTWQ3ZdP6StaJV3ZTLkLGMKQF5PUlJ3bus1WYd1Nz1pHnSiAlb4wDwSOAHwVddX 3Zi1hhcqxtXFlWcOO4wg9W9JrDiaWKw88Po5OUtZOUrSScnwu3sXAlasm5cCPn2ix6j065crTFRG daSSnZQG+HEKA3eOtdVsN/UE2FZFuM6S7DivoV5ttwAJyMZKQndx6cVr07zXoOTqxEaVSNV+qper eSk0uDab2GKrZpcTilKV6UwClKUBt7k59CTX4Vfw1aqqvJz6Emvwq/hq1V8/x371U72bcfZRqjUm uNYW/lOj2aFHzCUtKUx+YB59J4q2sZ3d41tauaVprKNiz23Fa/1tpu6RDcb5Y57CBKbQiXElNkoX gjCkqG8HvVsCtf6s0rfoz9xuempEdaLilPZcKQ2pW0oEYUgp3571RvRaO0mtL6ll3STJs94tot9y iNpUtCHdtDqDuC0noB6qiLzZ7dZdUaXYtsNuMhcxxa9gb1qKTkk8SfDUrpTTdwt82Ver5LZkXSal KFiOkpaaQOCU53nwmsq+WOVcr9ZZ7LjSWre8px0LJCiCMeZwPhxV/wCJMxvOLRi6x0zctRyLUIU9 MJqJI515wH5oBjHmBgjPhqK5idonUtpjpvtzukG6ulhxu5PB5SF4yFJVgEeCpvVOnZd1eh3O0y2o t0t6iphTySptwHiheN+D1isO3ae1BcL1Fu2q5VuUuDnsaNbkL5vaP06ivfnvCqx2lpbCy3DaFuk7 HnuZVjw4NVrkzQkaChZA2l7Zc3cVbRzU+wm6quUpMwQjbikCOG9vnc9O3ndjwVUBpXWVj7MgaZud rFrlOKcSJqF87GKvPBGzuPjqOPaiSsr2xyZXhtBw0L0pOBw2ecGRV91s218jq5J2RsJh+Zz0YG6u 8fRUFrRi9NOOrcQ6g84/jClOHeV4681BK0nra5wmLFeLxazZmiA49HbX2S+hPBKgfMjO7OPfqWr3 j3fCxKlmpW4/G5btNKUrTNsUskqMVvOfvRVdg/RhuX+62/16uTTSGGUMtpCUNpCUgdAHCqZdrBq1 nWb9+085Zil+KlhSLgp3Iwc5AQP31Zv1795WKtC3d8UXGS6WYzroGShBV6wrW+ntF23W9lOotQuS Zk+apamXOyFoEVIJCQgJOBjHTmrXZE6yXJcRqQWIxFNkAW/ntvPf292KhGdMa0sPZNu05dLWq1Pr K2+zkOF6NtcQjZ3EdWapbMm+Rgxbm7O5O5KLzqVy2twZq4r84AqdebQrgCDnaI3ZGT3qrTr2k7bd rPN0LGubJVMQ09OSl4R3QeLai4d56cAVeJnJ8+zpeFAtNxT2wgyuzEvSkZQ+7xO2BnAPezise6aV 1pqFMR+73O1Nuw5KHW4sNLiWVYO9SlKBUTjOAABVl7V+1fIq/Za7/mY9ysTGouViXBmuvdhdrEKe YacKA+NogJURg435xmvSwQGNJcoFws1qU63bFW4ShFU6paUObWMjaJPRVjj2CW1r6Tf1OM9ivQUx 0oCjthQVnJGMY8dcDT0o68dvqlsmI5AEbY2jt7W1nOMYxjv1CyStwfzLOzb8Pl/U1hCkWrUbb13v 2mNW3ic+4ssyYjCy1HSCdlLRSsDd4ONS13m3iZyVNi4Nz40tm4ttNOTmy28pAcGytQPTg8e9VgZ0 1rPTqpELTNytLlsecU42i4oc5yMVHeElG4jp31k3XRtxl6PZs6bqqbMTJbfdkzXFebIWFHGM4G7c OFTG2XDL4oiW1+JMad0nZ9MpeVbYykPScGQ8t1a1OqHSSoneSSd2Kj+UO3vStNmdFH+t2t1Mxk4y coOSB4s1aRuArq62l5pTaxlKwUkHpBqJX3COW0pOppjeqU6dtEfzbF1cRLfA6GEALIPVvwKi+UC5 Ik6sh6fmQLxOtbcbsh+HaWypT5JwkLwQdgY6+qpvRmi5WnblLkzZLT6Eo7HgJQVEtMbZVhWRxyQN 3VWVqXTVyl3WLftPzmYt1ioLezJSVMvtnileN48I/wAwdsuG36fILf5ffvKxo11Vv1a1DsendR2u yyWV8+xco6w004BkLSVFWCcYOT1V46R0XatTpvjt7D8thF3fDMbn1obbVnevCSMqOcb6t1jtOp13 U3TUt0jlaGy2zBtqnExxnitW1vUrw8K9tIWCXp+Pcm5bjKzLuDslHNKJwlWMA5A37qnv4fMbvH5M pEd19PJXqq2uPuPNW2Q/FjlxW0oNpxgZ71Z8mKjVN9sWl57jvatq0ImSGG3CgSDuSkKIwcA76kU6 KuQ0xqW18/F567S3nmFbatlKV4xteZyDu6AayLppS7pVabrYpkVi726MIy0yQpTD6MAFKsbxvGQQ KjtfZ8H8w1m7dvxXyM3T+lEaVRcGYM1xVsewqPCcyoRjg7Wyokkg8cVQI15lWjkZtjcNUpDs6aqN txE5eSlTiidgZHmiAQPDV/0/aL+09Mn6hujb8uUgIRFiFYjMJH1IVvJPSSM9FRULQD6uT5jTs2ah mZHdLzMqNlQbc2ypKhkDPHeN1P6fH6Eq1vH5P5lOAiWZ2NO0lo3WMC4tuoLq34rhblIyNtLgKlcR k7gN9SeuYjKNWSJ+rrDdLxYkxQYioSlFEQjG3thKk4zx2ieGOON1has2vLm9HjXy826LBYWlbjlq 51EiTs/SqJwEg8Ts+DhWVdrTq+Ne3rjpu6Q3WZSEpdhXUuqaaUn6ZvZ3jPSNw6d/Qe4hbzjk5ftz unlt2q+Lu0Np9QZ51CkuRkbtlo7RycdB3d6rZVd0np2XZjPn3SSzIud0eD0kx0FLSMDASgHeQB0n easVSyEKUpUEilKUBojUXolun449+uajqkdReiW6fjj365qOr6PR/Lj3I03tFKUrKQKs9g1g3YLa qKzbA48slSni9jJ6N2zwHVmqxStTF4KhjKfN143je9rtfBotGTi7o9HnnJDy3nVlbjiipSjxJNTG mdSHTjz7nYvZAeSARzmxjGe8euoOlWxOFo4qi6FWN4vds2dwUmncmmdSOxdSu3mMwlHPLJWypW0C CckZwPXqZmco8qQppLMEMNJWFOgO5UsA8AcDA69xqmUrTraGwFecalSndpWWb2eefe8yyqTV89pO 6m1MrUbrCuxex0MpICec28k9OcDvVl6f1w/ZIAhLhoktIJKCF7BGTk53HNVelWnonBVMNHCyp3gt iu8vG9/eRzktbWvmTN61HIut6bubSDFW0EhsBe1s47+Bnfnoqfi8pkhtgJlW1Dzg4rQ6UA+LB+Gq PSqV9C6PxFOFKpTTUFZZtNLhdO/vJVSad7k3f9Uzr+Qh4JZjoOUso4eEnpP/AMxWZE1l2Hpw2du3 7y2pHPc918TjZ7/XVYpWSWisHKlCjzfqwd0ldZ8cnn4kc5K+tfMmtNagTp6U7IMPslTiAkfNNjZ6 +g96seddzPvxujjOAXQvmtvO4HhnHe6qjaVmWBw6rTr6vryVm7vZ55eBGs7au4sWpdWK1DHYYEPs ZDSiSOd29r3hXlp/Vc2wZabSl+MpWVNLOMHvHo9+oKlYlovBrC9E5tc3wz+O33kucm9a+ZdpfKXK cYKYlubYcP063Ocx4Bgb6qAmyOzhNU4VvhznNpW/Ks5314UphNF4PBxlChTST27Xfxd2JTlLay8f JLeMUtrtiedKMFxL2BnHHGyfWzUe1rMsadVaW4GFKQUl7nuk8Ts7P76q9K1qegNG01aFK2altltW zf7thbnZ8TIgy1QZzMpKdotLCsZxnHRU/qLWr19hJiIi9it7WV4d29vqHAVWKVu1cBhq1eGIqRvO Ox55eGwopNJpbzkEpIUkkEbwR0VcbbyjTIkVLMyGmWpAAS4HNgkd/ccn1qptKrjdHYXHRUcTDWts 2r3qzEZOLuj/0emoNXzr8nmChMeMDnmkHJPhPT71QFKV9Ew2Fo4WmqVGOrFbjUlJyd2KUpWwVFKU oDb3Jz6Emvwq/hq1VVeTn0JNfhV/DVqr5/jv3qp3s24+yhSlK0ywqPn6gstreDNxu8GG6RkIkSUN qI68EipCtfXK2wLpyvMsXCFHmNC3E83IaS4nOeOCDUb0vvY2Hkm/vbYs41lpYnA1LaCT/wC+a/ir Mm3y0W1Da591hREPDLan5CEBY72TvrDGjdLA5GmrQCP/AGLX8NVrWkGHK1rpaHJiMPRitaSy42FI Ixw2TuqeCGxNllGstLE4GpbQT+PNfxVKuSo7UUynH2kMBO2XVLAQE9eeGKhZOjtIJjOKf09aGmgk 7a+xG0bI6TtADHhqiadcT8j7VcaG6t21R1uIgqUoqGxjeATxGahuyb4K5KV2u12Ngd2elfsltHt5 r+KsqBfrNdXVNW67QZriRlSI8lDhA6yEk1WtF6U05K0da35Gn7W885HBW45DbUpR6ySN9WWBYbNa nVO260wYTihhS48ZDZI6iUgVZqzaZSL1kmeD2rdNR3lsv6htbTiDhSFzW0qSeogndXLGq9OSn0MR 9QWt51w7KG25jalKPUADvql6DsNmus7UTtxtMGa4m4qCVSI6HCBv3AqBq6MaU05FfQ/H0/a2XWzt IcbhtpUk9YIG6oWxN9hZ77dpLUpSgFKpEi46l1NqO42ux3ZiyRrWpKHHzGTIddWRnGyo4Ce/xrJt EjVlovzdpvbvbmJIbUtq5MxOaLSh9K4E+ZA6umizDyLdSte2PlJtsG3y16ovTaHhcHmWU81lQQk7 vMtpzjvkeOrgNQ2lViN8RNQu3Jb5wvoBUAnp3AZ8WM07SbZ2JKlYTt2gs2c3dx/ZhBnny7sK85jO cYzw72apl/5TLZb9SWaK1c0ohPp52Uex1klCk+Y+lzvPVvpvsRuubApVCc5R7enlEas3bJKYfM82 UCOvKn1EbIzs54eLfvqVsF4nzdY6it8mRtxoKmgwjYSNgKTk7wMnx0WY4lopVZe5RtIR7t2rdvsd MkL2CMKKArqKwNkevuqypUFJCkkEEZBHTTdcdhzSqTq+df16tstkst67VJmtvKcd7Fbf86ARuV5R WLeImu9N2t+8nWjFyRDTzrkWRbG2UuJHEbSTkHHVTddk2zsbApVbfviZKNOyk3U20XFaFCMY3OmT tJzze1jzH31ZF+1ppzTLrbN4ujUZ1wZS2EqWrHWQkEgd80eW0qnfYTlKqmndSKverLq1GntyrY3H YcjFsJIBVna3gZ6OB4Yr1kco2kIt2NrevsdMkL2CMKKEq6isDZHfyd3TQks1KjbzqC06ft3bC6zm 40YkBKzlW0TwCQMk+IV5WDVVj1Q047Zri3KDRwtISpCk+FKgDjv4xQEvSlKAUpSgFKUoBSlKA0Rq L0S3T8ce/XNR1SOovRLdPxx79c1HV9Ho/lx7kab2ilKVlIFKUoBStlOaHs5szClJTFdCUKfkKcVu AGVbicDPrCoaXbdO3RyNbNNtc5KcV81kLU5htI4kg7jnvD4a87h+UeExGcIysr3dso23t3tnu39h ldKSV2U6lbEd0/o2x81FurxckOb9pxxYPrI3JHh9eoXWOlmbKG5kFSjFeUUlKjnmzxGD0jHwVkwm n8Lia0aSjKOt7LkrKVuDJdGSVyq0rYln0hZ5Ol2ZM1oNvuNFan1OKGwDvzjIG4V3t2ntG3iO5HgL W662kBToWsLH9rB3H1sVrT5T4OOu9SbUXZtRul23vs4b+wKjJpZ7TXFKmFack90psiFBTgXjbxu2 eO161W12waNshaiXRwuSHN4U4teT+RuA8NbuL03hsM4xSlOUldKKu7cd2RVU5O+6xrqrLYNH9urW 5Pcn9jIQojHM7eQBvPEVk6z0rEs7Lc+3qUlhxWwppR2tk4yCDxx4azO5y0xdD9s5MTbllgLC+cWN 6uG7ON2a0sVpinWw1Gphqji6kkl6qb7U02ku/PsLxpNTsyjqASsgHIBxnrrrV60hpe23SwrlTIod eWtQbUXFJAxu6D115S7fpK0xHYildsLmkbKUhSwNs9GU+ZAHUTmtj0/h3Xnh4QnKUXZ2V/G97JLe 3YqqTa1txSqVsFrSunbFbkSb+6pxbuAd6wlJ44ARv8Z96vK76Y0/LsK7pZX0spbTtZLpKFd47W8H /wCYrHDlHhJ1IxUZ6snZS1fVb7/6E8zKxQ6UqTsFldvtzREQrYRjacXjzqa7tevTw9KVWo7RWbMS V8iMpWxzY9FQZbdslHnJZwPNuOZJPDJThI96q7rHTTNhktORFqLD+dlCjkpI6M9Irj4PT2GxVZUV GUXJXWsrKS4rMySpSSuVqlbJXomzGxtLWlMZ3YSp2QpxXmR0nBOKQNMaSvEBxNuUtxaPMF8LWFBX Xg4HvYrU/FWC1NfVnqp2b1cl3u9s/PsLKhLI1tSpi2adfuV9XbEKwGlEOOfUpBq3SLBou3ON26Y4 UylpAC1Or2sngTjzI8Yrfxmm8NhaqpWlOTV7RV7Li+wpGnJ3K7pzSJv8N2Uqb2MhtWz/AEW3ndx4 iq88gNvLbSraCVEBWMZrarcBGmNJTG0uc4EpWoL4E53D4a1QTk5PTWtoTSFXH1K9VyvTUrRySy8r 8NpapBQiuJxSlK9GYT//0q7SlK+mGkbe5OfQk1+FX8NWqqryc+hJr8Kv4atVfP8AHfvVTvZtx9lG qNSaH1hcOU6PeYUjEJK0qTI58DmEjinZznf3hW1q5pWmso6pZ5u4rWuoNPWrUvKuzCu8XslgW8rC OcUjeD1pINbKqKOnoitTJ1AXHuyksFgI2hsbPgxnPjqLesn97GHsaXZ8URNv5MdHWuezOhWfmpDC tttfZLytk+ArIqH5QbVCvWsNNW+4s8/GeWsLRtKTnd1gg1sOoq46eiXO8W+6POPJet6ippKFAJVn 6rIz6xFTtauHsdjXutOSSzQ7aLpp224ehnnHIa3nFokIG8jerIPgIqcF4td65JJcm1R2orKYikKj NpCQyoDenAq9EZGDVYj6AtMQ3dMaRMZYu4PPx0rRsJJ6UDZyD4SarJNxlHiWTSafArmk+TDRtz0r bpsyz87IfYCnF9kvDaPgC8VctP6RsWlg8LLB7FD+Oc+arXtY4eeJqBY5MGYrCGI+r9VsstjCG27k EpSOoAI3VLWLSXaOYqT3RX247SdnmrhN51A74GBvrI3duxjSaSTKNpLRGnNT3LUEm827sp1q4KSh XPOIwPAlQq6Wjk60nYbi3cLZauYkt52HOyHVYz3lKIrAVyYw0zZUqJqTUUAynS643EnBpBUe8EV7 xNAdiS2pHdfql/m1BXNvXLaQrHQRs7xVY5JLsRZ7X4lupSlAURdl05rm7y50V25Wi7294x3n4jwY eIx042hsnr3GvKIvUWj9R220Tb6b5b7ipbbYkIAkMkbwSrJKx1k+sKmb1oG03i59tWpE+1XAjC5V tkFlxwdStxB8OM16WPQ9sss43FUidc7gUlAmXGQXnUJ+pB3ADxZoshLMh+TCFGTBvUoMo5565voc XsjKkg7hnq31BwEhvkz1g0gbLbcuSlCRwSOoDorYdisETT0aQxEceWmRIXIUXVAkKVxAwBurytml 7da4U6EjnX2J7y3nkvEHJXxAwBuo9mXC3wLppO/bf4kLdXEJ5HnFKWkDtQkZJ6ebFRDXz00B+LK/ ZipVrkrsjcdyI5cLu/BIUGoT0vbYYz0oQRjI6M5qRuOh7dcYFti9mXCI5bEhMeTFfDbwAGME4xvH HdUt3bfan8Siyjq9/wAjAV9GBv8A3Uf16iA9Ij3nlBeikh9DLZQR182atNy0dEuNzhXPthcosyIg N89GkbBeSOhe45G7vVmQtOwoN2uVybU6t25lPPIcIKBsjAwMdXWTVLerbv8Ae7llKzv3e630Ne2G 3ayf0IxGiNaO7UPx8q5/n8kEbys8NrrPeq96LYfi6Rt0eRNjTltNbHPxXOcbWASBsq6cDA8VQ7nJ dZS64hm4XiNAdXtuWxiaUxV54goxnB6s+tVvjRmYcZuNGaS0y0kIQhIwEgcBWRu9+0pbYUHW9s7c coWm4XZ02DtsyDz8J7mnU4SDuVg4qF1Npbueu0B6+3m93rTT7gbfalTlq5lzPmVLxgKTnwYPXwrZ MuwRJt/gXpxx4SICXEtJSobBCxg5GM+sRWRdrVEvdrkW2cjbjyEFCwOI7479V2JW3fUs834FV1il tGoNHpZCQ2m4AICeAGwcY71NENsu6l1VJfSg3ATubWVAbSWtkbA8Bx71SrejYSI9mZXMmvdpXAuO pxaNpWBgBWEjIA3bsV53vQ1uvNzFzbm3G1zijm3JFtk8yt1PUrcc02N+Py+hW3y91/qVZhpm16j1 4bMlDbiYSHAlrACXdhROAOG/f46xdOW/WT2g48eEzo82mRHyrnw/tKBHmivG7a6/BV5sOjLTpyXK kQA8VS20oeS6sLCiM5UTjJUSSSSTUW7yXWVTrqWLheIkB5ZW7bY80oirz54FGM4PSAfBioSyt97/ AKlr53+9iIUafnP2DS3YWorM7fLaVKiBb3Ox5SAcEJ+mOEgbwMjHRxrN09cpzeuEM6n04zAvcuMt DU6JIKmpLaDnGxtHG7flW/wVY7xo+0Xi2xYKkOwxCIMR6G5zTkcjd5hXR4815WHRcCxT13Azbhc5 ykc2JVxkl5xCOOyk4AAz3qtf1m+/3lWvVS+9pYqUpUEilKUApSlAKUpQGiNReiW6fjj365qOqR1F 6Jbp+OPfrmo6vo9H8uPcjTe0UpSspArMtMbsy7xI+ztBx5II72d/vVh1J6duEa1XtidLQ4ttnJw2 ATkggcSOutXGOosNUdNXlZ2XbbIlbS58o85TNuiwEKwH1lSwD0J4DwZPvVHcmiWzcZqiBzgaSE9e CTn4BURq2/M3+5NPxkOoabaCAHAAc5JJ3E9dYFmu8iyXFEyPgkbloPBaekV5ujoit6B6HFWm1d99 72fwM86i5y+5Fwvc/Sar3IbuFonPzAvYUpJOFEbhgbY3cMbqxdU6gi3G3M2WPBmRnkOowmS2EkDB A6SekVm93thdUiW9aHTNQncvmkKKTjgFk5x38eKolm8SdW6vgB5AbZbc2kNA5CQPNHJ6TurnYTC1 qbVevSnFUYt3lO6TS/hXDy+t5zWeq9vYWTWQchaMTHYBKMttrIHBI/zAqB5N4bq7rImAENNtbBPQ SSD+736sGpdUN2W6MQ5EZMmI8yS8jAJ3nHTuPA7jUPO19DYt/YtigKjEg4UpCUJbz0hKcgnj1eOt PA0tIVNF9EpUfzXfXurWe2+++X0LT1FNXew91WOLqfWVxefWrsaKUoUlJwVqAwRnq3GvOK9phvUL duttgMh4uFta3lkpSBxUAoqzw6hUFpfVCrDMdU+2p9iRguYPmgesZ41YDr6ysTQ9EtK0l0kyHubQ lwjxHzW/rNbuLwekadSdGMJTpqCULS1Y5K15JNXd87eGwopQkrvJ3O/KI9zpt1tb886vawPWH769 teOphaYjQkeZ21pSB3kjf+6oC8alt1y1LAuSW5IYjgbaVJTtZBJGBtY6umvPV2pYuoHoojtvoZZB 2g4kA5J34wT0CrYLRmIhUwUJQajTUpS/md8u/YTKpG8nctbbqrHyeJcT5h3scY6CFK/fvrW8GJMn zEtQmnHn87Q2BvHfJ6PCas2pdXQbtZW7fCZkNlK0lRcSkDAHeJqtW24yLVPbmRlAONngeBHSDXT0 Lg8VQwdapKFqs5Sdn7r9hjqST1UtiNgDVbUfZteqbbzLmyNo7KXW1DHEgZ97NYWqNM2ldkVerSA0 AAvCCdhaSegHhx6PWrurXVgntIVdLMpx1PQWkOgeAqI+CofUusjeI3YMOOY8QEZ2j5peOG4bgO9v rjaPwGOp4unKjSlSV/X9a8Hxss3n3u3vMrlCzu7/ABKvVu0dpaJdWHbhcSpTDSsBtJxtYG8kjf61 VGrPpPVybAhyNKZW7HWraBbxtJPgPH169TpuOMlg5LB318tmTtvs+JrU9XWWtsJqwSdOv31MS02E ncVLffVtFGOkA7Xwiums3OztVW23I37BSVDwnPwV2Z19ZYksiJaVsx1glxaG0JWpXRuBx481Du6k tzus0XotSTHSBhBSnbyE44Zx79eXw+CxfTJ4l0ZK1N6utLWblszd9vYbEpR1Gk9pO8o01TFviwW1 EB1RUsDpA4V6aBaELTcmaoblqUvxJH+VVTVt/Zv9wbejocQ023sgOAA8cngTUk1q63xtI9qWWJAk lrYKilIRk8Txz71ZZ6LxC0RQwcYO8pJz7Fe7v7hrxdW98kSnJ5sPOXKUf6RboGenHGqdckybhqN9 CkqL7r5TjpG+sjTOo3NPTFL5vnWHcBxGcHwjv1ZX9e2VMpMqLaldkKOHH3GkBYT3iDk+uK2pUsdg tI16tKjrqolZ3WVlsf33FE4yhZuxn63eMPSbcbPmnClB8Q31rCrRq/VEXUCYzcRt9CGiSoOgDJPg Jqr10+TuDqYTARjVVpNtteP0K1pJyyFKUrvmEUpSgNvcnPoSa/Cr+GrVVV5OfQk1+FX8NWqvn+O/ eqnezbj7KP/T3NStZ6i5UrhZeUFnT7VsadibaEOKVtc6oq6U78AeI1suizWsHk7HNYN5u8WxWp+5 TNvmWE5KUAFSu8B0ms6qPrW629zUVnsk+4RYkYL7LkmQ6ltJCfOpyrrNQ+BPaWu0XWNe7WxcYhVz L6dpIWMKHeI6DUPeddW+03FVuYgXO7S2wC8zbIpeLIPDa3gCofk/u0JF7vVghzWJUdp4yYq2HUuJ 2F8RkHoPRXZ+DqrSt+uM+y2mNe4Nyc55xnsgMPtrAx55W4p728+Cpe57iFvW8sGn9WW3UaHxFTIj yYxw/ElNFp5o99J/cTUKnlOjPOOiLpbU0xDTimy7Gt4cQSDg4IXXOm77Zr3qGS87Z5lo1AIwS8zM SpClt/2d+FAHpwDUDo+96pg22UzatHds4wmvESO2bTOTtbxsqGab/AbvH5F50/qPt+Hj2lu9s5rG 64xeZ28/U7zmpSTKYhRnJMp5DLLSSpbizhKQOkmo6wXC83CO6u82LtO4lWEN9lof2x15SN1QvKIn smJarc4SI8y4NtvY6U5zg0e5d3vC4nmrlQtfmnmLNfpMBJ+eDNvJj46VbRIOB4KtVuuMO7QWp0CQ iRGeGUOIO4ivdLTaGg0lCUthOyEAbgOrFVDUz8Pk80fMk2ZlEQuvZG0VLShazgq2STw44FQ3YlJs uVK0k7quzWyN2ytnKTd512R5tUeW26qM8fpkhstgJz0b91Wi7SrnqLVNjhw7rMtsW425Tz/YzhSo DcfM9AV0bWKtZ/fmVui7PXmGze49nUVmVIbU6kBO4JTxJNcM3htxua69FlRW4SiFLkNbIcAGdpHW O/WvndICLyl2qMNQ353MVx3nXZxUvzJHmckedPSKy1NSb5ZdWx5F1uDSY8tRbUzIKVJSEg7AznCT 0iqt2jfsfudiVnK3avhcnLXr2Pd2efiafvxYUtKUPKhYQ4CcbSTtb0jiT0Vaq1XDjybFyf2N6Ld7 ktUyVHKg7JJCEk4KE4xhPerpqbV9vmatm2q8asnWCBA2UtotyVpdfWRkkrSlWAM8Ks8nb73fUiN2 r/e82vUffLzGsFpeuctDq2WQCpLQBUcnG7JA9+tcWTX6ITF6iQL45fYsKGZESTLbUHUqzjYWVJBV vOc471eepdO3uPoNy8v6luE6RJbQuZGfWFRylRB+Zox5gjdvB6O/VZXSuWVr2NrtPJejofSDsrQF gHjgjNU248p8W186qZpbUzTLS9gvKt4S2TnAworHHoq22752RfwKP1RVY5UvQPI/Ds/tE1Zr1rdp EPWsZ1i1f28ndi9zt+t/mCrnp8Lmm/BnaO+rFVB5RdVC0O2y0qu6rOxOCjJmttlbjbaRwQACQSTj ON1V22aytNnv0Bqx6yuV9jy3g1Ji3MOLUkHgtC1ITjB4jp8VQsyNiubgqMuV+i2u5263vtvKduLh baKAClJAz5rJ+DNUm1Wq+6ztr2pE6ouUB91xfYEZh3YjIQlRCecRg7eSN9emtGLs/dNIRzKbj3Jb ykOSGU7SUK2MKUkHHfIzUZ5eHvJe/wAfcbFpVCtjU/TGum7Ib3cbnCnwlujtg9zq21o6QrAwMdFQ dltN+1BpWbd39XXiM7FefERDEjCPMqJ+adK9+7GRgCl1t7L+TsN9vvZc2bMuHYcqIx2HKf7Kc2Oc Za2kNbs5Wc+ZHfrMrXrN/uFxiaHmLlOoXOexJCFbAdwhWdoDcRkZxwrlmHctdXi7vq1DdLXBt0lU SK1b3uZ2lpA2lLODtb+ipaabXC/y+pCaaT7vff6F1uVw7Wx0Pdhype04lvYitbahk42iM8BxJrMq jaidv9q0Vb0XC4g3FM5ht2REWpHOpLgG/hxTjI4caxNdXSNHvzca+axfsdu5kKZYtaliS4vO9Syl B2U9AHT4qfX5XJ+nzNiUrV+jr9Oej6mt4m3Z6LEjB6G7dBsykhSVbyriQcAg9VYKIOofkbs6wVq6 7C4R44ebZDwLBQk8Fo+nURnJJPHeN1RdeGXz+g7Pv7zNvUrWes7+92XZTdbrc7JYJkQOuTLaCF8+ RkIUsAlIx0AHPiyLBoVyMtiQbfq9zUEFWyppElQXIj5znbVuVvwcBSRjFWs8yL7C2UpSoJFKUoDR GovRLdPxx79c1HVI6i9Et0/HHv1zUdX0ej+XHuRpvaKUpWUgUpSgFKUoBUpp68JsVz7NVF7IIQUp Tzmxgnpzg/8Aw1F0rDXoU8RSlSqK8Xk93wJTs7knf7yq+3Rc0s8yCkJDe1tYwOvAqMpSpo0oUaca dNWilZdyDbbuxSlKykClKUApSlAKUpQCldkIU4tKEjKlHAHfqf1FpZOn4cd5U7nlvn+j5rZxu378 nrrWqYujSrQozl6072Wedtvd4llFtNrcV6lKVslRSpZWnJzNmVdZISwwcc2FHzTmeGB0Dw1l6f0o b3b5E1cwxm2CR/Rbe1gZPSK0KmksJTpOrKa1U9W6u8+GVy6hJtK20r1K7LASsgHIBwD111rfKClK UApSlAKUpQG3uTn0JNfhV/DVqqq8nPoSa/Cr+GrVXz/HfvVTvZtx9lGK5bLe9ObnOwYzktoYbfU0 kuIHeVjIrKpStMsKqFt0m1c7xdLvqW0RX3X3diM1Kbbe5tpPDrAzx66t9Kb7jdY//9S43XSPavUV ovOl7TGZLLhbmMxkNshbSuJxuBI9evBu36r0fc5psdpj3y1zXi8mP2UmO7HWeO9W4g+v4KvlKAp9 mtV9ueo+6O/Q2LapphTEaE08HVpB4laxuPexUTYntb6ajSIDOiOzm1SnHUPdtWW9oKVkeZOcVsal Pv5gg7BddQXF11N50z2nQlOUL7PbkbZ6sJG6vTVFgTqOzLhB7mH0qDjDwGebcScg+CpilHmFkUhN 45RmGewl6UhSpCRsC4IuKEMqP1fNkbWOsVwnQEhzSUuFJnoXd5j4luSgDsc6DlIxx2Rwq8UoCjC4 8o8xhNtGn4dufPmV3UzUONgDipLWCcnoz46knLPcTrq2XIpL0aPBcZdkEpBKzj6UdfeGKs9Km+d/ vgQ1lYqGoYF7Z1na75arYm4tNMrYeb7IS0UBRHmvNccdQri22K5R4ep23Y2yqe+tccbaTtgpwOnd v68VcKVVq6t3+/Mnff7yyKNK07dnNE2G3IiZlQ3mFPt84nzAScnfnB8Vd51u1JpzUky7aftrN4iX LZMiGuSGHG1gYCkqVux3qu1Ks3m39/eRCVlYqDFs1LqW33NGo+atseawWY9vaUh0sn6tTgG8+A47 1V67W/lBuulVabds0VAjpSkzUy0HspKSMBKN2yTuyVHoNbQpVWrlrnhCbU1BjtLGFoaSlQ6iBUFr 60zr1pV6FbmOekKdaUEbaU5AWCd5IHAVZKVZu7uRH1dhVdV2S7PS7ffbDzK7lbdoCO+rZQ+hQwpO eg9RO6vKHJ1te7kwJtqZ09b2iTIT2U3KckjHnRgYSOs7j1GrfSoBr2FE1tpaPIsNnssWdEU6tUOe ZaWxGSsk4W2RlWyT0VJXCxXp+6aVfeWJzkBxSpskbCBkpxkJ3bs9Qq4Upw8PcHnf72lXuNnnv8oN turTG1DYhvNOO7aRsqVwGM596vHS1juVt0VLt0uNzcpxyQpDe2k5CidneDjfVupUNXVuxrzdwsnf x91jX9t0xeI9s0Yy7D2XLW8pUsc6g82MKHXv4jhmvVULVOk71c3LFZGbzAub3ZAR2WlhcdwgBWdr zwPHd/8Au90qW7tvj8/7EJWSX3kUm7WPUtw0hDjT3W59zE5p97mthtDaA4DspzjISPGe/XnOgals Gtbhe7PYmr2zc2m0kGYhhccoGMZUN6Tx3dPv3qlO773E/fvua+tmntTovuop10YYWbtAAQY7g2EO AFIbG0do4GPNEAZJrMOn7p8iHtD2L/4j2BzPMc4nz/VtZ2ffq60qGla33v8AqFtv97voU+W1q+0s Wx21xGbpFbhIYlWpx1DStsADbS4QR3iCcdQ35GLpDTM5nU0jUMqxwtOtqiiM3bojiF7R2torWUAJ 7wxv6+/eqVa+dyLZWFKUqCRSlKA0RqL0S3T8ce/XNR1SOovRLdPxx79c1HV9Ho/lx7kab2l10Zpm DdbTJlzoweVtlDILikjcP7JHSfero7ZtOvtNWi0uCZdHHAlcjK9lsDepW7zJG7A48eNSjijY+TJC RhLshsDwlw5P5pPrVAcn8hljUoS6QC6ypCCT9NkH4Aa8QquKq08VpCNWWrCT1Yp5erld9m+ysnvu bHqxUY22/MkpUHRtgkot1wZky5G4uOhRARnHHChu6dwJqM1RpYWy6RmreVONTjhlCjvSrI3Z6t43 /wD7q13C7aravqoMK2R3I6lDm31tr2QnrUoKwMf/AAVFvXW4nWtsiXxENBjrVsdjqJBKxgE5JPHG M441hwOLxtOSrKet6kpNOprXyumo2WrnuW4tOMbNW9x5yLFprS8VoXsPTpTw842SAnrIAI3dG87+ jprF1ZpeHChMXS07fY75SOaJKsZGQRnfv79ZmsLHdLvqllDEdxTK20pS7snYQN+cngOndULdLKzp m/QW3JyJKQtDjgCNkoAV0jJ6O/W7o+rKbpVlinKrKLlKG1NcLLKNvMrNWutXJEu3pmy6ftKJ2oi4 +87uEdtRGD1DBGSOk5xR7TljvtjcuOn0ux3WAdplxROSN5ByTg44YOKzNf22fcW4T8FhySykEEMg qIJxg4HRu416WqOdKaLkvTwG339pQbUd+0RhKfez69c+GMryw1HFRrt1pztq39W181q8Et5fVSlq 2y4kFoewQ7zIlKnsF1plICRtlPmjnqI6vfqXtln0fNu8m2sxn5DreVlanFBAGQClJCgTjv58Nd9L HtVoaZcT5lbnOOJJPT51Pvisfk3jgCfcHDuGEZ6uk/CKtj8TXqLGYmNWSUZKEUpNK+Sf3vKwSSir bTzZseloF+7VSTJnSHl4SkHCGhxAJBBJx/8AoVHaj07Eg6niwIIUG5OySgqzsZVggE96snR6VXTW ciev6Tbd8ZOB8JrOjntrymuuDJREBxv3DZGz8JrZliMRhMVV1qspalK8rvLWeyy2LwDUZRdlvsjv fLLpGxrjKlRnwVE/MWXFEr75ydwHeI8dcX7S+mrc0zcHFPRY43FhpRUp08RjaJx3/wB1YF+Ubxyg sxArKGnENgZ6BvV++vXlGkKeuMK3tnOwjOO+o4/cKw4aniufwtKVed5Qcp+tu3bfK+0tLV9bLYd7 1p+wuaU7cW2O7FOyFpClklWSBggk+9WNbNNWyBZE3rUCnFNrAKI6MjOeGcb8+MVJa3cTbtLwbag+ eKRjPEJH+dTFwulwa0/Fm2KM3L2kpygoKzs46Akg1rQx2N6HRjGbtUnLNys9VbFru9r55+Q1Y62a 2IrT9isN7sD9xsTTsVyNkrbcUTnAyQck9G8YNYmmNLRpsJd2u7im4TeSEg428cSTxx4N9S90vOrG bAqXMhwGGXklCknaS4gHdwKuPe3nvV7iO9cOTZpmAkuOc0naQg71YO8eGtjpmLp4ZU3VtGdTV1tb WcVvWtZZ8GyNWLkst3cYtot+lL5OQbW0/FeirDmyskhwA99R/dXnrAM3XVUa2vTG4rDLeXHHFhIG d/T04xXroGwTYcp24TWHI42NhCHE7JPWcHf0V3sMOBf9RXS4S2kyebc2Wm1gFOO+Dx8dYZ1oYfG1 qyqynGlGyd9ZqUstr279uwK7ha1rs8GYeiE3Jm0ojuzHl4T2Qh0qST3ylQHrCsCdYbVZdVsRJKH5 UR9IKW0nzQUTgAkEbqs9gl3F25ust2Bq1W9OSo80UqWroxwB9Y1DukXXlMSgnKIx4H+yPLU4fFYi NatGVSWrGm2/X1nfdZrKL7ExKK1dm/gSms5lqg2huBKiuOlaTzCEkgIIGAScj99QSrBa4mhRcpMb MxxAKFlahgk7t2ccK516xMl39lPY7wYAQ0h3YOySrqPDprN1+8Iljg25G7JyQOoDd++r4CE6VLBY ejN3qNzlZvYs7dz3rjtLSs5NtbER9m0rb2LP26v7i0sY2kspJGR0ZxvyeoYrKiWXS+p4r6LO0/Ck sjI5xROerIJIx4MGs/Ucd+8aNiKtjZfSkJUUNjJIxjcBxrx0Xa3bFBl3W5oMYKTuS5uISOsdFUnj q1TCTxjryVbXtGCeW21nHflxKxik4xSyK3pmxon6kMGc0VtshRdSCRnHfFTlwtujrVeBGfZfeW6U pDDS1FLWeknaB98+CvfQuH5V1u604SpeBu6ONV2zpVedbIcWNoKfLivAP/groV6tbEYvETlVlGFK Cuou15Wv97ytlGOSvd5GZrHTcK2Sona4FsSjsc0pRIB68nfUjK0/p3TVvZcusSXOW5uU43kJQerc QAPCSa6atYfvurGLXFfaacaaylTiykZ49AJzWdHuuqrRJRBnWs3JG4B+OlXvqxj1wK054jGSwmHj z15autKOvqSaex63Z93LNRU3kVzUtv063DZm2aYkKcxmNzhWQOvfkp8dVmrryg2+3RexX47KI8l3 O22gAZHWQOnPTVKr1WhKvPYGFTWlK985bdvHf37zDVVpWNvcnPoSa/Cr+GrVVV5OfQk1+FX8NWqv L4796qd7M0fZRDTNX6fgXtqyyro01PexsMqB6eGTjA8ZqZqhXvkqg3vWbWonLi62kKStyMlsHbUn hhWd3rGr5wrTXs57Sz29hzWqb3bNKXLlSuKNVuRUMIhNFnsiWWBtZ34IUnO6trVr9u0227crN2bu VvizUIgNFKZDKXAk54gKBxRL1vMn+F+HxRIaW03oOBMcuGlxDdkNIKVrjT1P7IPQRtqArytGubnq FwiBpdbkJtxbUqUuYlCWyCRuBTle7qG6rLEs1qtLT3a22Q4XOJ832Mwlva8OyBmq7ydpCdGP4HGT IJ/KNHv7EV4dp0tWqLTZtGNTmLY6whyQtpiCy4XluubR3AnrO/vV6Rtb3SNMjt6l0s/ZY8pYbZki WiQjbPAL2QNjPfqkTIhc0RY5r0iZGhRLk6qTIhq2XGUlRG2Dg4x11nTLfpNxUNhOutR31yS8gNQm Lo3IKjnIKkkYAHfxUrN/fYN332n/1bpP11cEagm2O06ZeucuKEq8zJS2gpPElShhPeG/Ne0PlAhO 6WlXqbCkQ3IbhZeiHClh3OAlJ3Zz0cKx9NJA5RdSbt4QyMnjwqpy2nVWzUkltC3ERL02+6hAyShO CTjvVEdiv95pfMPbs3/Jsy9T6kulyXZY9305Is6nZ7TkdSn0vJcTnpKfOK/smpW2XF203jW9wZi9 lrjvNr5kL2NoBG/fg/BWJrPVdjvKrBHtk1ia45OadPMq2uaTn6bHnT0YO+pfSzSXtV6waWMpXIbS R3iipSdpW7f/AMk5b+z4slLlqxiBpVi+tx+f7IS3zTAXgqUvGE5wek9VTralqaQpaQhZSCpIOcHq zWrLC29M1LD0k+lfNWCU5JWT50t8Wh39596tnxZ0Scha4cpmQlCyhZacCwlQ4g44HvVOTV1v+BXN Oz3EHre7zbXZkNW1QROnPJjMLIB2Co42t/UKi/kT6ceaLs0zZdzUMquTktzniv6oYOBjo3Vna/hS 3rMxPgsl9+2SUSg0kZK0pPmgB0nGa9I/KJpGRbBP7fQm07G0WnHQl1PWNg+az4qqrWf3ll/Us75f f3uO1seuGltMPu6ouDctMMqKZKNpS1tDzu1kDK6ik8oNzjoauF10hMg2V4jZmmQhxaUnzqltDeke Pd36wLzPvGruT25zzC5qPz6XIbSW1Bx1lCgSpQzvzjdgCvbU+tNO3TQjsaBcI0uVPYDLENpYU7tq GACgbxjvipd9vcQksl3lm7pEK1XHsbccLQ/EMlMkObsdA2ce/mvLup/8fulq7D+d8USOd53+kz0Y xu8OTVXU+xprW9gcvMluI0bR2PzzytlAcSBkFR3D166225xLvrTVEuC7z0c21KUugeZXgnJSekd8 dVQ8ll/3e69vkQu3s99v6mQjXeob7YXJ9n0e45DWwo9kruKGsKxv2QU5IHXuzvrjSOrH7RydRJt5 tryANluKG3Q87NUongkbwSevw1J6RQByVQ0pHGCrd69UiUuNcOTPTTzVwdEe1yEKnrgOjnoo80Nr cCUkZzV5KzklxXxZWL1lGXY/gi6Ma4usOQx3S6Ufs0OSsNtyhLRISlZ4BYSAUA9Z6d1Zl81fIhXY WayWR69XIN8640h5LLbSOgqcVuBPQKpVwgaSdYjMjXmpL4qU6hDcGPdESFLJORtII3AdO1j16nYV yg6Y5Rbyi8y24aLky05Ffkr2EKCBhSdo7s9NR/Uv2/e0l7ZrVM2FcRKtj0C6WxsuSIDywd2MgpWN yknrxXq5q3m9BjVPYOcxuf7G533trHv4qtNvN6l1ZqK42giRDbtXYfPt70Ou5JwD04HVmot/VNlV yMItqJ7S5/YnMGIk5dSoZztI4gDGcndVG3ZvsXz/AKE/xW+939S43LWkll2FBs9jdutzlxkylRkv paQ02RxU4rdxOBu31I6evk+7B9m6WGVaJccjaQ4Q42sHgUODcrv44VTb21pqZIsce63GdYbii3JX FurL6WEKGyAUbZPHfnGB4d+Ky9CXW6d0cqxr1G3qa3x4iXBPQ2kc0vONgqBO0SN+SSd1ZLZtd/3/ AHKJ+qn3E5yhS7hC0ZOftq3W3UhO24yMrbbyNtSe+E5NVOHpHQd6hc9pK7Jbvimy4xLRcXOyAvpU tBVkZPHzI41ctY3qfp6zJukKMiQ0w8gy0lBUoM580UgEbxx37qqeovkVXqzu3B2RaUPKQp1DkRxL ckrI4lCcKUrPQoHwVjvZN/3MnBf2OLjdNVxdfafivWhM15qIsK5qalDb6ilIW4AobtnfxGTndU/c NZ3Jd2lW7Temnr0qCoIlOmWiO2hRGQlJVnaPX1VWrbPfg33RcnUkoR31W6QlbspYQSTjZCifpiMc d+e/Xm7LhX2+3wao1lMswhSSw1b2JyYyFsgZBKTvXtZ6N/vVdrd3/Exx3vu+Bn6j1pcLpye3ORbr O+xLZU5FntqkpQqEQN6gfpxwxjB31TZdqnRoFmtCNBLiw50pC3GRegrtgoIOATnzH1XVUjZOwkcn Wt2bcwtiKl9amG17WQ2UjYPmt+8DO/rq33z+u6G/Gk/sTULb36vvJby/1Frs0Fi2WaJDjRBDaaaA EcOFfNdJTtHjgk76zqUqW7u4SsrClKVBIpSlAaI1F6Jbp+OPfrmo6pHUXolun449+uajq+j0fyo9 yNN7SSn3+6XKG3ElyecYbIKEBtKQCBgcAOg1HJUpCgpJKVA5BBwQa4pSlRpUoalOKiuCVkG29pNp 1jqBMfmBcnNjZ2clCSrH32M57+c1DuOuPOqddcU44s7SlqOST1k10pVKOFw9C7pQUb7bJK/kS5N7 WTbWsdQMsBhFyXsAYBUhKlflEZ9+od152Q6p15xTjizlS1nJJ75rpSlHC4eg26UFFvbZJX8g5N5N krA1NerYxzESetDY4JUlKwnwbQOPFWNcLrPurwdnSlvqHAKOAnwAbhw6Kw6VEMJh4VHVhTipPekr +e0azta5JL1BdHLWLWqV/qgATzYQkbhvG/GffriHf7pb4LkKLK5phzO0kNpOcjB3kZqOpUdDw2rq c3G172srX49/btGs+Jn2y93GzqcVAkcyXcbZ2EqzjhxB665g325W2S9JiSebde/pFbCVZ6ekGo+l TPCYeetrU09a18lnbZfjbdcjWfEzGbtOj3I3Jp/EpSiouFKTvPHcRikq7TptwTPkP85JSUkLKQME cN2MVh0q3R6Otr6iva17K9uHd2C7M653q4XhSFT5HPFsYT5hKcesBXe23+62lKkQZq2kK4oICk+s QQKjqVV4TDulzLprU4WVvLYTrO97mbcbxcbssLny1vbPBJwEjwJG4V6W2/XSzpWmBMU0le8pwFDP XgggVHUqXhcPKlzLgtThZW8tg1ne9yaTrC/pW4sXFZLnnsoSfWyN3irAg3SdbZRkw5CmXTxIwQfC DuNYlKrHBYaMZRjTilLarLPv4hyk9rJo6w1AZIkG5L20p2R5hOzj73GM9/FYJu043I3ISFJllW0X EgJyfAN1YdKQwWFp31KcVdWyS2cO7sDlJ7WS0vVF5nKZVJmc4WF7bfzJAAV14A3+Osa53ifeHUOT 5HPKQnZSdhKcDxAVhUqaeDw1Jp06cU1sskrX22DlJ7WSFuv10tIKYMxbSTxRuUn1jkUuV+ul3ATO mrdSngjclPhwMDPfqPpTomHVXnubjr8bK/ntGs7WuSMO/wBzt8JyFFk82w5naTzaTnPHeRmvG3XO ZapPZEJ7mncbO1shW7xg1iUqei0GpLUVpbcln38fEi7MiVPlTJqpj7ylSFHaLg8yc97HCpRrWeoW WktpuSilIwCttCj4yRk1B0qtXBYatFRqU4yS2XSdu4lSkne57Spcia+p+U8t51XFS1ZNeNKVsxio q0VZEN3NvcnPoSa/Cr+GrVVV5OfQk1+FX8NWqvAY796qd7NqPsoUpStMsK8EwoiJi5iIrKZLiQlb wbAWpI4Aq4kV70oDgjIweFeMeHFhsliLGZYaJJKGkBKSTxOB1170oDwYhRI0YxmIrLTBzlptsJSc 8dw3b6xoNhs1reU9brRBhuqGFLjxkNqI6iQBUhSgPBuHFZkuyWozLb72OcdS2ApeOGTxNGYMSMXi xFZaL6tp0obCecPWrHE+GvelARzWnbGwCGbNAbBcDpCIyBlY4K3Dj369Ho6ILUuXb7cy5LdG2pKN lsvqA3bSse+azaUB/9bYOlbXcEyp98vMRuJPuCkjsZDgc5ltPBJUNxPTUnZrMzZm5KWSkmTIU+sJ bCEgnoAHg8ZzUlSp7gKjHtN2GRMM16yW52UVBRfXFQVk9e0RnNSdKgCsBix2iLOVPj2qEzLXkqkN x0JcOeOVAZrPpQGLOtkC6Mhm4wY8xoHaCJDSXEg9eCDRu129laltQYyFKbDSillIJQOCTu4Dq4Vl UoDyjxo8SOiNGYbZZQMIbbQEpSOoAbhXjEtVut4dEKBFjB87ToZZSjnD1qwN/jrLpQEfBsFltj5k W+0QYjyhguMRkNqI6sgZr2nW2BdGAxcYUeY0DtBuQ0lxOevBBrKpQHlGix4UdEaJHajsNjCGmkBK UjvAbhWJ3P2UOyHe08DnJSSl9fYyMug8Qo480PDUhSgMSXa7dPiJhzIEaTGTjZZeZStAxwwkjG6u 8K3wrbHEeBDYiMg55thsITnrwBisilAKjGtNWFmaJrVktzcoL2w+mKgL2uvaxnPfqTpQGLOtdvuY bFwgRpYaVtID7KXNg9YyNxrzk2O0TZjcyXaoUiS1jYfdjoUtODkYURkYNZ1KAxFWm2rEkLt8VQmY 7Jyyk89gYG3u81u669HIMN1TCnIrKzGOWCpsHmjjGU9W7dur3pQClKUApSlAKUpQGiNReiW6fjj3 65qOqR1F6Jbp+OPfrmo6vo9H8uPcjTe0UpSspApSlAKUpQCsmNbZ81BXEhSJCEnBU00pQB6twrGq /wDJk/5iexngULA8OR+6uVpfHTwGEliIRva2Xe7F4R1pJMoOCDgg56qyZFsuERoPSYMllsnG240p Iz4SKsdhsHZuspKVozHhPqUvduJB8yP3+KpO/vDUuq41ibURFjqJeKTxON/rcPXrTr6aUMVzMFeM Y603wVsku1/MuqeTb7ijxYEybtdiRH5Gz57mmyvHhxXWTEkw3A3KjusLIzsuoKTjwGtj6j1K3pVt i22yKzzgTtbKgdhCfAMZJ8Nesd5rWWknHJcdCHkhQykedWOBTneK0Y8oMVGMMTVoatGbsnfPPY7f f1tzKvq3zNZxokmY5zcWO6+sDOy0gqOPAK5chympIjORnkPkgBpSCFHPDdxq68msP5tNlkedw0k4 8Z/dWBb1m78opeA2kJeUr/hSCB+6t6emJRxGJgorVpRvfi7XsU5v1U+LK1KgTYWz2XEfj7XnedbK M+DNY9XHlIlc5eGIwVuZayR1EnyYqnV0tHYmeKwkK9RWclexWpFRlZHZKVLWEISVKUcAAZJNZMi1 3GI1zsmBJYbzjbcZUkZ8JFX+ww4eltMG8SGtqStvbJI81v4JHV368LPr+PM59q+JZjtkeYKG1qCg eII31w56dxVRzqYShr04Ozd83x1VbcZFTjZaztc15WYzZ7nIaS6xbZbrauC0MKUD4wKlbauzs6rW 4iPInRUrJjtMNbRUejKTg7quTN9v826pRDsTjUBJAWqWgtrx0kZOPEM1n0lpivhnalTVrazc5KPg ltv/AGIjTTvd+Rq5aFtrKHElCknBSoYINZCLZPdjdktwZK2ACedS0opwO/jFW/lKZjpkQ3UoSH1p IWoDeQOGasEQxbNopozkBbSGAVox58no8ZrBW5QyjhMPXp07yqu2r8bfIsqPruNzWDVsuD8cyGYM lxkAkuIaUU7uO/GKxa2jpLVEm/S5LLkVllllILfN5yB1Hr8WKouqkMt6lmpYSEpDhyBwz01uaP0p XxGMqYTEU1GUUnk77dz7SsqaUNZMiKUpXfMIpSlAKUpQClKUBtfQktuFott5xKlJ59Ywkb+NTfdF E9Kf/JHlqtaWGdAN/jCvhr2Ca8FjUnianezYTaSLD3QRPSnvyR5a57fRfS3vWHlqvhPertitXVRO sye7exfS3vWHlrnt3G9Le9YeWoMCuwG6o1URrMzoGrrfcXZLbLMlJjL2F7aUjJ73mqzu3Mf0t31h 5aoulkf6xdVdco/BVhA71RqonWZM9uY/pbvrDy07cx/S3fWHlqHxTZqdVDWZMduY/wBQ76w8tc9u I/1DvrDy1D4rnFNVDWZL9t2PS3fWHlp23Y+od9YeWonG/hXIFNVDWZK9t4/1DnrDy1z22Y9Ld9Ye WorFAnfUaqF2SvbVj6hz1h5a57asfUOesPLUXs0xSyJuz//X2z20Y+oc9YeWnbVj6hz1h5ajAnfX ITV7Ipdkl20Y+oc9YeWnbRj6hz1h5ajdnvVzs9QpZC7JHtoz9Q56w8tO2jP1DnrDy1HbNMUshdkl 2zZ+oc9YeWnbNn6hz1h5ajtmmN1LIXZI9s2fqHPWHlp2zZ+oc9YeWo7FNmlkLske2bP1DnrDy1x2 zZ+oc9YeWo/FCN9LIXZI9s2fqHPWHlrjtoz9Q56w8tR2zTZxSyF2SPbRn6hz1h5a47asfUOesPLU ds1wU0shdkl21Y+oc9YeWnbZj6hz1h5ajCmuNnfSyF2Sfbdj0t31h5a47cR8f0bvrDy1FlO+uhTS yF2S3bqMP/Ld9YeWvaLcWZjpbbQ4CE5yoDy1AlPerOswxMWf/tn4RUNIJu5N0pSqlzRGovRLdPxx 79c1HVI6i9Et0/HHv1zUdX0ej+XHuRpvaKUpWUgUpSgFKUoBVs5O5HNagWyTueZI8YIPlqp1sHSG j5MKazdpUhrZ5vaaQ2SSdofTZA6D0Zrz/KPEYeno+pTrSs5J2XF/djJTTclYm7tIY0xap05vHPyX StOfplq4esBnxVRdG3BEfVLbslf9OFIK1H6Y8Pf+GvTW9+F2ugjx3NqLGylJHBSuk/u8VVmtPROh n6NnDEe3VWb3rLJeHDwMlWp6+W4v+sdKXS6XkTILaXkOICVArCdgjd0nh4KkX+Z0do0xnHUqkOIU lIH0y1ccd4ZqkRtXX+IwGWbkvYTw20pWfXUCajps+XcXy/MkOPuHpWc47wHQO8Kx09C4+qqVDF1I ulTaaUb3lbZe+Xl/UnnYpuSWZsfRDBGkFqjkc+8XCCehW8DPrCvDRmmZNqmvS7hsIkKSQhoKCiEk 7ycdeKpFsv10s6VpgS1MpWcqTshQz14IOK9o+qb3Gfefanr514grUtCVk44cQcDvCsOI0FpGTxMa VSOrVd87327HlkvO/YRGpC0brYdtWSuy9TTXOhLmwPAnd+6oau7ji3nFOOKKlrOVE9JrpXsKFJUa MaS2RSXkYZPWk2bSusV3UWi2U23ZWtQQsJ2sZxuIyenw9VQTWhY0OxOzb1KcjPpSVBLaklKeoHdv Oeo1WrbfbpaApMCYtlKuKcBSfDggjNcXK93O7kdnTFvBPBO5KR4hgV5fC6H0jhXzFKso0tbWuk9f u4ffgZucg0nJZovHJ0wwLVKfZCDILhSVK44xuB71ZVlg6odvPZd5lKRHaBCGkOABfVuTuI8O+tdW 66z7S8XYMlbKlDBxgg+EHcazTq6/KlJkm4rLiUlI8wnZAP8AZxjx4rXxmgMbVr150pQaqb5JuS7F lku33CNWKik9xLa1Wq4avZhfSpCGx/xHJ+GpjlDe7HscSGk7lr4fej/OqM/eZ8m5JuTz4VKTghzY SOHDdjHvVzc71cbwpCp8jni2MJ8wlOPWArfp6GrRrYRtrVoxzWecrbstnkHVV5PiXbk6jiPaZc1Y wFr4/wBlI/8A3VCnvqlXCQ+o5LjhVnx1lxdRXaFbzAjS+bjqBBQG0njx34zUZW5o/R9Whi8RiarT 5xq1r5JccikppwUUKUpXbMQpSlAKUpQClKUBs7Se/QTf4wr4ayQK8NIjOg2/xhXw1lhIrwWNf/E1 O9mfcjqE12ArsE12Cc1qXJsdQmuQK74rkDfS4IDSyfMXBX1UtdTwFQ2kwFQJS+uY78NToFCWdQmu dmu2z01zilxY6gVyBvrts1yEjqpcHXHGgFdwM9GK5A3VFxY6YrnFdtmucUuDqBXOzXbZxx3U2d1C TrimN/Cu4Ga5xS4OmK5Arvs1ziouD//Q2Xs1ziu+KAbqtcodNndmmzXfZrnFCTzxXOzXcDvUwaA8 9mmDXoE76YpcHns1xs167NcbNLg89muCndXps0Ipcg8inpxXXZr22a6lNLg8iK6lNeuzXUp71Lg8 Sms20jEtX4M/CKxiKy7WMSlfefvFGwtpLUpSqlzSd+tVxc1Dclot8pSFS3SlSWVEEbZ3jdWB2nun qbL9gV5K21J/rT336vhryrmvl/iaT5tUY5ZbXuMvQ4vO5qrtPdPU2X7AryU7T3T1Nl+wK8lbVpUf tDxX6EfNjoUeJqrtPdPU2X7AryU7T3T1Nl+wK8lbVpT9oeK/Qj5sdCjxNVdp7p6my/YFeSnae6ep sv2BXkratKftDxX6EfNjoUeJqrtPdPU2X7AryVlqTqZbHY6hdVMlOzzZ5wpx1Y4YrZVKxy5f15tO WHi7drJ6GlvNVdp7p6my/YFeSnae6epsv2BXkratKyftDxX6EfNkdCjxNVdp7p6my/YFeSnae6ep sv2BXkratKftDxX6EfNjoUeJqrtPdPU2X7AryU7T3T1Nl+wK8lbVpT9oeK/Qj5sdCjxNVdp7p6my /YFeSnae6epsv2BXkratKftDxX6EfNjoUeJqrtPdPU2X7AryU7T3T1Nl+wK8lbVpT9oeK/Qj5sdC jxNVdp7p6my/YFeSnae6epsv2BXkratKftDxX6EfNjoUeJqrtPdPU2X7AryU7T3T1Nl+wK8lbVpT 9oeK/Qj5sdCjxNVdp7p6my/YFeSnae6epsv2BXkratKftDxX6EfNjoUeJqrtPdPU2X7AryU7T3T1 Nl+wK8lbVpT9oeK/Qj5sdCjxNVdp7p6my/YFeSnae6epsv2BXkratKftDxX6EfNjoUeJqrtPdPU2 X7AryU7T3T1Nl+wK8lbVpT9oeK/Qj5sdCjxNVdp7p6my/YFeSnae6epsv2BXkratKftDxX6EfNjo UeJhaVjvR9ENtPsraXz6jsrSUnj1GsoJqRIzZh9/WCE10aeLli4LESVnPO3eYJR1XqnGK5Ca7Abq 7BNZLlTqE12xuJNc4rlQ8wrwUuLFf0UecsbquuY9+tVhCd1VzQO/Tiz/AO8f/WqzAUuWsdAPDXbF dsVyBUXIOuK5ArtitZ6qmari6hdXGkyG2UL+YIQ8gJKcDGUZweniM1aKvvIba2I2Vg5rnGa1KjWm tIz4W+svpH/lqio2T40JB9+sxrlTu7L47PtkRTf1DQW0r11FXwVfm29jRXXttRs7G+uwFUGJysQ3 HSJloeYbA3Fp8Oq9YhPw1Jw+UrTclSg6uVDA4GQznP5BVUOnNbiVUi95a8VgXC+2m1PtsTp7TDjn nUqJ3d8486O+cVjxNYacmtqW1eYiEjpfXzHvLxUBq+12u9JFxjuCRtICC+w6FI3HdvGR0mq2s/WJ vf2WW6Hc7fcHC3CnxZTg3lLD6XCPySaysEHeN/grSTumWlp+YyFE9IICvJXqzDv1ubDNvu0hhnjz bL7jY9ZO6rWg9jIvNbjdGOiucVqZnVetYTqQuQmShv8A8tbTagrwkAKPr1nR+VG7RitVxsrC0/Sh orZx4Srapzb3NDX4otOqdWp0yY4VC7J57OcO7GyB4jnj3qxInKZp2QspeVKiADO28zkHvDYKj71V y98osO7WtDfa55t8LypsvAoA++wCT/w1Xe2tokDMiAULVx2EpI9fcauqbtnEq5q91L3G4Yeo7HPD fY12iLU7uQ2XQlav+A4V71SewU+eBz3xWjBFscg7LUstK6iSkeuoVkQ4E+IFqs96cbSviY7qkA+E pO/1qq4x7V3ospS7Gf/R2niucZNapY1TrSApBMhqY0gYCHW04PhOEqPr1IMcqNxjtAXKwhR2t7jS 1NJA7wUFZ9esmo3sZj1rbUbGxXGKqkPlN05JKg8uVECQDtPM7QV4NgqPvCp2FqCy3BTSYl0iOrdH mGg8A4f+A+a96ocJLaiVKL3mcU02a9Ckg4IxXGKoWPPZ6K4Ir1x4q4xQHkRurgivTG+uCKA8yN1d CO9XsRXUihFjxKayraMSVfeH4RXiQayLf/Tq+9/fQkkaUpQkr0n+tPffq+GvKvWT/Wnvv1fDXlXy ev8Amy738TpR2IUpSsJIpSlAKUpQClKUApSlAKUpQClKUApSlAKUpQClKUApSlAKUpQClKUApSlA KUpQClKUBnj5zj7+sQCsxHzoH39YwFfUNG/udL+VHOqe2zgJrkJ6xXbZxiu2K3iljrs1w4PmSz/Z NemK6vjDDn3p+CgZWuT/AH6bX+OP/rVaME76rPJ6kjTix1y3T79TFyv1ps69i4TmmXPS96ljv7IB OO/iiVxKy2mfjornGBVQl6+Q8hSLJbJEtwkgPPDYa8I6T4Ds14Nsapvm0qVdkw2/PcxETs7ukA5z 66jUNqO1loxlPYvkW+TNiQk5kyWmerbWAT4B01Vb/coly2FRFLUEKKVKUkpBPeB31htabhNEqc51 9R4l1XHwgbj467z2G48ZptpCUJTuCUjAFUU03ZIyOk4q7ZGBs5JXsq6sDFcBsFR2kD8omvWuKyGI w126K+ol2KlXfUlNYxsNvWojmlA97aHw7qlsVxwqU2thDV9pAnTUUkhMhYPQNoH3sV1Y06tiU29z 2Q2sKALeP31YMU2Eg52RnrxVucnxI1I8DqOG+gSANwIx1HFdq5qhY6niN58Fcc0MncnB+pGK70xQ ERfY7Kba68plsKGAk7IPE441UwKuOoT/AODO+FPwiqdnNb2H9k1a/tHYcaEbxWTa0ocukVC0hSVO JBSRkEZrYTkKyx45dlRIbaAcAlpI/dWDE41UJqGq23wLU8O6kHK9igM3OexnYludXmjtAevmstvU U1IAcQ05jiooIUfWP7qnnDpx1xtIg5Cgdrm1pBSegAZGferNjWPSsgjAwVEAJcdUgk9Qzx8WaxVM UoK9SlJeBMKTfszRWVXiBKViXbsD6pJCifXAx69dNixPpCudejngEFJPrnzVWxOjrVPgvyosbmY7 KiFOmQrawMZISUkdO7J9aoh/QrjjYet01Dra/OhwYwO+R0+KrOtShbXvG/32kJTlstI//9KJt7cu A5izagU0onb5ll3AP3wBwfGKnGdX6zglXOmJPz0utABPg2dj99VKVp66wj81huEHOCgbWR17qwW5 MhgbDTzrYzwSsp96tuKVRXjJM1NZx2xsbWs/KDLuF0iwJGn3mi+sILqHCoA9J2dnh08dwq7kb94r SOm9VzrZc+ylwlXIobIS2FBspJ3bWQgk9I8dXmPyp2ZRaamw5sVxXn/MJUhvx52iP+GsU6bTtYyw mrXZdCDXXG/eahomtdMzStLN4jo2Bkl/aZHiKwAfFUuw+xLYS/GebeaXvS40oKSrwEbqxNNbTKmn sOxTxrqRXciup3//AKqCTzOQK94Iw+r73yV5GvaF/TH73yUBnUpSgK9J/rT336vhryr1k/1p779X w15V8nr/AJsu9/E6UdiFKUrCSKUpQClR2oLobLYpdxS3zimUZSk8CSQBnvZNaXkar1BJfW8u8TEq WckNvKQkeAJIAr2XJ7khi9N0ZV4TUIp2zvm+5GvWxEaVkzfNK0F3R331auHtpflp3R331auHtpfl r0n7MsX/AJiPkzX6dHgb9pWgu6O++rVw9tL8tO6O++rVw9tL8tP2ZYv/ADEfJjp0eBv2lVPk5m3K fp1Ttwecf+bKDTjiipRTuzknjvzVsr5vpHBSwOLqYWUk3BtXWzI3ac9eKkKUpWiXFKUoBSlKAUpS gFKUoBSlRV91LbNOsJcnunbXvQ02Npa/AP3nFbOGwtfF1VRoQcpPYlmyG0ldkrSouw6hg6jhqlQe cAQrZWhwAKSe/gkVKVXEYerhqsqNaLjKOTT2oRkpK6FKUrASKUpQClKUBIt/Okff14ADFe7XzpH3 9eO6vp+jn/wdL+VHPqe0xiu6U5zgZ6aqt8ut+ZnOQ4hhRmtkFD+FOuDv4OE+LB8NQciE/cFbVzuM qZk55tTmy2D1pSnAHirfKFwuWp7NasB+YlxxW5LbHzRSj1bt2fCRUI9rOfOy1brKpptRA5+YvHme nKBvB8ZFRO1a7btZLDKvpgMbZ8IG815dv4angywh15RIAKUYB/f71WUZNZIo5R3sxLSxOlMusi5y mYiHV4ZZXsA5O/axx8dSUaywIygUR0lQ3hS/NH3+FeMF6abAhmEhKlc84sqKEeZO1jiRnh368lWm 5yirsu57KVDBS2Dg+EbhRRuvWZaTcX6qJV2VEiHZefbaIGdkqAPrca7J1ZaYuyUuuulJBBaQcjfv xnFRzOm7e0cuc46cbwpWB72KzWLfCjgc1GbSU7wdnJHjO+ocafayYzqLgYjmqJ06Qo262lSCo+aW Cv4MYrGvkG9SmYr3ZfMqKAFo5wpwd/QN1TkaZFVJS2JDRWTgJCwTnwV3vQ+ZNGqqerNaqsZdRypt ydyjdr7+yraRMU4ernif1q5J1MDniB0Yb31YsUxWbnXvSNbm1uK8bpfmhsm3hR6+aUfgNBqCeyn/ AFm2q8QUj4QasPRTHepzi3xQ1HubIBGq0FXzSGpI/subX7hXt3UQd3zKQO/sp8tTJAIwRnvGvBUC Is7S4rKj1lsGmtDq+8asuJhp1BbCnJkFJ6i2r9wr3autvdGUy2h9+rZ+HFHLRb3PPRGx96Nn4K8V aftqhgMFPfC1fvNP8PtHr9hmty4zysNSGnD1JWDXrUOdMQVcHXx4FDyV5dyyEq2mZjjZ69nJ+EVF qfEm8+BmagGbK90YKfhFU3hxqeutrmRoC3F3J15tJGUKJwd/hqB8NbdFJRydzXq3bzRmWjfeInfd T8NX24o2JUCU+SYbEgF5OyVAcMEjp6vHWu4kkw5jMgI5zmlhWznGcHhmrVF5QmELV2Tbnmh0c2sL +HFc3GxqrERqwjdJG1QlDmnFvO5aWJFgu0duU+/EdlOrZWtU5DLTqkpcO1kDcDs8QOIxXiINokyL Q8i0IKpYkKVzDi0BxLaVAABJ3EnByOrGN9QSLtpCctol0xFnO0FJx65UCPWqTYsunJ3zWNKUsJPn kPIxnxAUljqMNqkvD+oVKpLevN/Q8kWu3dubgiaJkWLEiCTzSFgrQohB2crHRtEdBr2j2OQqQG4t 4kIbW2w6gHaH9KoDBCVjhnx1hSYs23z1OJlymHlDHPNPKSXE9G/O8bhu71SxRqKRDjHtqUKaG4ON IKhggj6XjkDifHW5XqU4QjKpJWey+f1NajLXnKMYtNeHvPRVn1FCQ4XLhFWhO0FFyQvAAGSTtgge vVb1e+xLtMWU20gKLhQcEKxgHIBHEf5VYFztROQzDdjR5BKMKL6SNpJTs71JcAzjv5qu6thJt9ki spIzz5UrZzjJB4ZJ3dFaalQdem4NX7Le+xsNSUJXv4kTpnHbBz8EfhFWVTSVNlJAIPWKrOmN9wc3 /wDlH4RVprar+2YqPsn/0/By1QnQAYrff2Rs59arfpK76ZtNtNuRcI8V9Ci4+H1qbG0eorwDuCRu PRVcrHft0STlTkdtSj9NgAnx8asnuZVrejasWXGuDPPwpDUpo7ucZWFp9cbq7mtNP6dguJSA2tGD 9KrP61X3REV9qA+69cJkoFYbQh94rS2EgcBwHnveFQ7biVcs5FesP+mP3vkrwJ3V7Qj82V97Vbkm dSlKkFek/wBae+/V8NeVesn+tPffq+GvKvk9f82Xe/idKOxClKVhJFKUoDq42h1tTbiErQsFKkqG QQeIIqEl6J01NdDjtpZSoDGGSpoesggeOp2lbmGx2Kwjvh6sofytr4MrKMZbVc1Ryh2Ox2FmGzbY XMvvFSlq51avMjAHEniSfWrB0Bp6Jfrs+J7POxmGsqRtFOVE7t4IPQa55SJ3ZmrHWgcpitpaHh4n 3yat/JdA7H065LUMKlOkg/2U7vhzX2vSOOxWjOSVOc6snWmo+s29a8vW23vkro5epGeJ1Usl8jMk 8nGmX2S23DdjqP8A5jT6ioflEj3qxWuSywNupWp+c6lJyULdThXeOEg+sauddVrQ02pxxQShAKlK PAAcTXymlyl02lzcMTN37W3n2vM6DoUn/CjrHjMxI6I8dpLTTYwlCBgAV6VobUl+lX67uynXVFsK IZbzuQnowKyLlrS93OI3EXLUywhsIKGiUlzdglR4nPVw71ez/Ztjp83J11eWc7p+r3Z+s/I1umwT atkjcsq8WyC7zMu4xI7mM7Dr6UHHgJrJZfakspeYdQ62sZStCgpKh3iK+c62Zo25rsfJ9MuL2SlD iuYSTuJ3AAf8WffrDpzkGtH4anOhWc5ylGNmrXb4Zv55E0sW5zs1ZF5kXO3xZCI8mdGZeXjYbcdS lSs7hgE5NZVaAiszNQ31DZWpyRLdypZ4795PirfjLfNMobyTsJAya4PKjk7S0HKjTjV15yTbVrW7 V2PPyMtCu6reWSDrzTDSnXnENtoGVLWoAJHfJrziToc9suQ5TMlCTgqZcCwD1ZFax5Tr4qVdEWlp Z5mMApwA7lLPkH76leSu3LYgS7k4opQ8oISCd2E8T65PrVs4nkmsJoKOkq9S05WtG3HYuN7Z+4jp F63NpGwKx5c+FASlc2WxGSs4SXnAgE97Nat1Zr+fOmORLVIXFiNqxzjZ2VuY6c8QO8KpRJUSSSSd 5JruaL/+N8RXpRq4yrqX/hSu/F3ST8GY6mNjF2irm/e6OxerVv8AbSPLUghaHEBbagtKhkKScgiv nKtsx4d3tXJkGYaH3Jq0ZCEAqWgKPAAdQrV09yJw+jXQjTxHrVJavrJJW3u/Z8xRxUqjd1sLO9fb PHeUy/doTTiDhSFyEJUk98E1qDXN1RdtTyHGXUusNYbbUlWUkDpHhqAcQ4hxSHUqSsHCgoYIPfrr X0Tk7yPw+hK8sRCo5yatmkrcbGpWxMqkdW1jafJ5MtFp08TKukJl+Q4VqQuQhKgOAyCeqryy+zJZ S8w6h1pYylaFBSVDvEV86tNOPupaZbW44o4ShCSST3gK3XoezSbLp1tiXlLzii4psnzmejw18/5c 6Aw+ClLHOvepUlfVaWzs7FkjZwlZu0EskWKlKV8wOgKUpQClKUBIt/Okff1jg17A7NnB/t1ibe6v peAdsJS/lRpSV5Mquq0znLogQ3W2hsDaUoZPi3VW5Vtfec5ldzW8pRBUgjAHfxmrBqye7DuCCiGt 7LWSoHAT4Tiq2LosXNhU8CMQCWgFeZVn6rfj4K6kZNRujWai5WZJxbBEiDacQl5R+rGQPEa9zLjM bUdlCtpA3oQ0QB48YrCnSZU8JSxMbiMJUUFZcA2ldQ358VZENksokIW4XFJZOVqzlVHdq9yVttY8 LLMQzawFKSFKKilClgFW88Kz46Z0pG2FstJPABBUoePOPeqItkNl62RZLiSVoayjfgDeas1tH+rJ qvcW35kRMuaba8IThdffIztkJSAD4PJXtb7dHkAuPth5e1xc818NZ0vCXVEbvM1xav6Inv1Ls7BX R6vRlsRXDCbSl8J+Z+ZHHx7qrt/t17lIiu9mhtYbAUnnCPNZP1IxVv6OHr1GXc+ZbqIycZKxk1VK m7lJVaL76pE/3665EbUbA8w/t461JV+tVhzvpk1m52Rr82iv/wD8n/8AnNVyJmomR5uIlz/hz8Bq fpmnOdiGp2sr6rxfQfnaPEws/vrum+3FsZetKz4EqT8INTtc5HVTXXVJ1XxK+rVKknCrcU+F3/8A 5ru3qqMR80jupP8AZIPkqc6aHB3HeKa0Or7yNWXEh+6mCCPmUj8lPlr2RqK2rGVOrb7ykH91Zq40 Zzz8dtXhSDXQwIJ3dhx/Yk+SovDgTaXEjrld7XKhlkyCpKlJyAFJ3Z37yk/BUGGY0l4JjqLaCeLj qfhOyKsk22wUs7QitpO0AClOOJrAXaWV8GgR4KxylJS9RtI26FWEI/4lNS7zDkWmIwztmeFK+pSW T8Dp+CsaLanZqgGMkZ482tX6oNSQs0fI2kJArsu0tbJbbWQlR2igL3Ejpx4/fqvO1U/a9yMqnhWm 5UV4NojJ9idg451aTnh8zcT+skV4M2Z507bRYSRvyZLaD76s1IqtLQcCS4Qo8AV76zo8a7W8kszn mwQU7IUSMHvHdmnOVbZtPwIXQ9X2Gn3/ANCIbl3yO6WWbjKUojGG3i5u8RNdpA1GhHOSH7mhJ+mU VpFZDttlvO847JdcX1uHa+GstDM5lkp5uG6kpI2VxW/XyADnx1TWds4q5LhhGsnJPwf0K+Zdyz89 J3tlflrlyTMfQG35T7yUnIDjilfCalozN0Yd22nSn+ylSkD80ivWdIlyW0NvwG3HNo5cXIdV1Y3F R7/rjhWWNZQd1BffgUlhsNLZUfl/UwrG1KclrEV8MrDZOSkKBGRu31ONs31vJVIiu9W2CPgArowz NtcUvmMy+pR2ebZaSkgcc7QTno4V3bvMg/0lplp+9SVfuFZucdX1kjUrUYUJaqlftzRyh+9pcO3A ZcT/AGHAn4SadtJjbmy7aHwOttW38ArhzUMZo4ciy0n+02B++u7eoLcvi8pB/tIP7gaWfVMd11jh y+MNEc7FmNDrW0Bj36vGipTEy0uPx3VLCX1IxvAB2UE7vW31TE3y2qOBJGe+hQ+EVctKTGn7YstO BxHPEFSSCAcDdWKpktljJDN7T//U2cVb6yIBy+r7394qNLu/ox15rMtS9qSoHjsH4RWJPMyuNkS1 KUrKYivSf6099+r4a8q9ZP8AWnvv1fDXlXyev+bLvfxOlHYhSlKwkilKUAro88iOw4+6cIbSVqPU AMmu9VjlCuJt+k30pVhcpQZTjqO8+8CPHXT0Tgnj8fSwq/ikl4b/AHFZSUYuT3Gn5sly4XF+Sve5 IdKyB1k1vixwBbLJDhDiy0lJ75xv9+tN6MtoumqYbKhlttXOr8Cd/wAOBW86+jf/ACVjVztDAw2R Ws/HJeST8zQwUW3KbFVrX9z7W6VkBKsOSSGU+Pj7wI8dWWtU8qV1Em8MW5tWUxEbSx/bVv8AgAry vIzR3TtM0k16sPWfhs99jbxE9Sm2VexWOXqC5IhRAASNpa1cEJ6Sa27ZNEWSzNpPYqJUgYJfkJCy CN4KQdyfFv79QnJZajHtki5uJ81JVsI+9T/nn1qvldrltylxVfHzwVCo40oZO2Ws99+NnlbZka2E oR1NeSzZpq66a1FeNVS8219JefUedWghsDPHa4EY6qz9fFNotlr04wvKGG+ccP1SuAJ98+OtrVo3 Ws3s/Vk90HKUOc2nwJ3fur0nJfTGI5QaQg6sFGnh43SXWfqp58FexSvTjSi5J5ssnJXaQ7KlXVxG eaHNNk9BO8/urY86W3AgvzHfOMoKz38dFQWgIKYWkopA80+C6o4454e9isPlLuYhab7ESfmkxYTj +yN59/FeOx+tp7lS6W2Lnq//AFjt9yb8TPRtSoaz7zVL7r10ua3D5t6S709KlH/Ot3M2dUPSZtUQ hLgiqbSeGVFP7zWruT62dsdUsrUnLcYF1XVno9/4K2+9dbdHlCK/PjNSFYw0t5KVnPDcTmvRcvtI 1OnUMJh1fmrTaSvnuv2JL3mDBx9qpI0AUuQpmy80OcZc8024ndkHgRW1NM8oNnmNtQZDKLY4AEoS AAye8CPO+A+vU1ftJWnUKSqUxsSMYTIa3LHh6/HWptU6Ze0xPRHckNvodTttqTuVjON6eiutDGaG 5aUo4etrU60U2lw4tbpLvSfC20o4VMM9aOaNvytM2Wfck3ORAbdkpwQsqODjhkZwfGKlQMDAqh8l t0lSrfIgvqUtqMRzSlb9kH6Wr5XybTuGxWCxksFiajnzeSu21barJ7Mt2436M4zjrpWuUvlQuPYu n24aSQuU5vx9SnefhFVDk3t3Zup0vqTtIioKyeoncP3135S7kZmpDFSrLcRARjP03E1aeS+2GNY3 ZywQqUvdn6kbq+n1f/8AE5GKOydVe+efuiaU/wDFxKW5fIu9KUr4qdMUpSgFKUoBSlKA8NSy34Wk g7GeLLhkJTtBIVxPfBFVMamuZeEZBjlSTgqW2do7uO4ge9Vg1wCdDpVs5SiW2pXeAPGqFHfSu+KS g7QIyCDkcK+naOSeDpfyo0JtqTJkyJElsc4UlbeQMbgoZ4HcarFytcoLS4QHG1nYCSjJb8Azv8NT 0SShS1pyAraIANYPY63GdtTinG15OwtSlHO/hkkAeKt6yayMbeeZFoTNt3MwpLRQ2p4OJSV7WO8A OFWcuOBUgtICtpJ287sJwcmou4lSLTEWpGyoKTtJzncD0VmuST2POU2QFcwSk8fDV7WSRXicWgHt BF77A+E1liNdX40pMWUhtLjISxvIKF53kkDy1FadfcdsDQWc7KSlO7oB3VINXtLLjEVIUXFOhJQA CSOndVb2LbSSdC0JShw5WltIUeOTjea8IcEvvx5POlIYUTsbOdrPj3VwZC3XHysnc4UpBGMDorLt p+Ynw1LCPW2wHYRf5ySp5Ljm2kFONgdQ3mvG7keYqOk6tagSXGH0OKUl9SdyPpRjgdw6aybnJQ6G loOUrTtDwVR+2Zl+UzFBrhSgkFRIAG8k9FcpbWrBGzj74Vi3GDcpB2IjUYshOVc4+d58ARw71ZLG C56JlMOBJQ8hQVwIO41jv3iFHeLTritsK2cJbUrf1ZAIrtGt05EdK31sc6pO4jI2c/fY98CsG6Wm e7LQ7DWwEJbGApxIUV4wVcMVZJFbsyheoJWUlxxJxkhTCxgdfCs5K0rSFJIKTwIqqAuNyW1SZcZK 20lCwXhhWazbdMjxXFDs+LzSj5wOg48FGkE3fNE9mmd9YzM6PIUUsvIWRvISoHFJM1mIyp59eygc Tiq2LXMmvN+SxFb5x91DaetRxVfd1gyFYYiqcHSVLCcetmoR65TJsrnV83tHckKVuQOocBV1TlwK OpFFol3+1uNBtMsFW0DjYV1+CofnYL7kgOqbyVHYCknfkbifW4d+oxUKZIcLuwgJUMK2VDfXquC+ lwuNloKUN6VEAeHNXVHWRTn9Vk6mVGZtURIcaQQMKTtAbPHor2t0xh9DrwJ2WxvOP/nVVXS7JSC2 ptpwbXNnCiQT1ZArMts0W0yY8iPltwjnRtqCmx4Nnv8ASRWJ0rO5mVa6tYkezUv6jQloZQtgYBBG /JH7qw7RJdbdeW9xS0CQU42fNAGsdU6P2zZnW5A2GUBIS5xyCTxyeuvB1x195bz4Q5tnftAnG/oG /FUcLjnLFuakRUxVBUlja80SA6k9J79eMOXHefGVhIGTlW4VXoYLCnFOht1KskAgkp8HSeisi3R5 MdznYToHEb/DnBH7vgq/NplOeLWgNqAUghQPAivPmQpwHHDvVDLlvwUF53sRpSzvUhBSVHrOOPHp rIZviQErXsqbzs84gLwT+Tiqyii8Z5XsWNeAgAV5571eciS2y1zji0oQOKlHGKjHdQ29CCpLxcI+ lSk5Pr4FUjaKzM7jOpK8Vclq4KgASeHTVUe1G8+v+gUG/qEuBBH/ABDefe8fGsF2e/IUpLm0ttR/ olOlSBjBB3nf46tdcSej1eq/Ita5VncVh16CojjtrRUlbNRwLRGdbYQy4yTzmIxGdrcDkDcRuHA5 GN4xvqlW+SxGWnsmI24lQ2SpPmSnxgivSZcHLPFb7EAehIWQlWcLTnJwrB8O8bvBnFHaUcmVlTnR naSNgxdYRpO2hQQw80CXG1LJ2cb+OBvGDkDOMVN6O1DDu1wUyw+l1zscuEobUkEZSMjPh660UL7s ghuO2kFJSr5mgjBGyejduJHjq/8AIu8JGppa0NhKUwlZxgbytHQOvHvVCgkVdRyyN0UpSrFD/9XY sn+tPffq+GvKvWT/AFp779Xw15V8nr/my738TpR2IUpSsJIpSlAK1byq3F1y6xbdgpaZb5z75Sv8 gPfraVY0q3QZykKmQo8kt+cLzSV7PgyN1ei5N6Xo6Ix6xdWnr2TSztZvf8V4mKtB1IOKZR+TDT70 Zp28yW9jn0bDAUMEo4lXgO7HgrYNKVpaY0pV0rjZ4uqrOW7glkl994pU1Tjqo6uOJaaW6vzqElSs dQ31oC4SX7ze3n8FTsp87Ke+TuFfQBAUCCAQeII41E2/Slitcsy4dubbf6FqUpZT4NonHir0fJXl JhdB0q8p03KpK2ra1sr7c7rPgmY8RRlVSSZl2eAi12iLCRwZbCfCcbzWZSleLqVJVZupN3bd33s2 IpRSSA41893ViRHuklqUlSXkuK2wob85r6EqNuunbResG4wG3lJ4L3pX4NpODjvZr2fJDlNS0FUq KvByjO2y11a/Gye3ijXxFF1Y2TNIMXy7xWUsx7rNZaT51DchaUjwAGsR592S8p591brqzlS1qKlK PWSa3bG0NpmK8HW7S0pQ6HVqcT6yiRXd7RWm35QkrtDAWMbkZQjd/YBCfer3Uf8A5E0PTqOVPDyV 99opt9vre+/gafQ6rVmyv8mdsci2CVcQ382kkhrI4hI3e/mtZzzIVPfMrb58uK5znM7Wc785r6GQ hDSEttoShCRhKUjAAqOumnLPeTtXC3tPL3fNMFKzjgNoYOO9mvNaH5cU8LpDEYrFUm1VaeVrxSyS ztdW7UZ54VumoJ7DSLF7u8VlLMe6TWWk+dQ3IWlI8ABriHBuV9nlEdp6XIcOVq3qO/pUT8JrcLWg tLsupcTaklSTkBbrih4wVEHx1NxYkaEzzMSO1HbBzsNICU58ArtYv/5FwNKMngMM9d75JR89Vtvz RijgpvKUsiJ0np1GnLQmOVBb7h23ljgVdQ7wqVnS0QYL8tYJSy2VkDpwK966uNoeaU06hK0LGFJU MgivlFTGSxOM6TivW1pXl255ryyR0YwUI6sT5+xJvV4IQCt+W7u8JNb4tMFNstUaEngy2E5xxrEt ml7JZ5CpEC3ttOq+nKlKI8G0TjxVLV6nlbyop6alTpYeLjThxtdvwbWS2Zmth8O6bcpPNiqprDW7 em1CJHYEiYtO1hRwhsdGek+Dd4atdQGoNGWrUchEiXzzTyRslxhQBUOgHINcPQNTRlPGqWk4uVNJ 5LjuvsdvvYZ6uvqvU2kXonWk3Ukt+LNisoU2nbStkEDHUQSfhq51HWaw26wxuYt7GwD59ZOVLPfN SNYdM4jBYjGzqYGnqU9y+e+1+BFKM4xtN3YpSlckyilKUBH615w6EcS0MqU8BjPHjWrhi3MoUjm2 nAjA2yBndwrZevnWmdAKU8t5COyEjLKgFcT71aJmL598qa5zY6OcVk+OvpujssJTf/ajQqXcmizW m5yXJS0NLcwSTjiPHuqU51xloJW6lCE8M4GKpCJDLUUJchtOOE/0hUrd4gcUjTGkAhUNhZ45Xkn3 jW8nZFC2zbgzNioTImspKTlIOyMHxCseNMaZiSEKuDJC0H5ntg53f/N1VNSkOvlYOzk5xjIFWW0R mbnEcDzaELQoAKjoDZIx04G+m+4SyZkWa9QYVrbYXKCVYJUC2TsknvCsaZfYiprTrACthYUoqQcL xwO87vBurtKaFmbD8VbyPNpSoFfEZ79Rrup5/PbnlhIONnPRUsZFkb1cy4pZ7EkuKWon5m0P4jXu zqibHThqyy3UnfvbUk+8DWJDuUWawg88Ao7yhbuCD48Vk9iMq81sK3/2ifhNTtGRDXB9+4y+yDYZ DbxcKiVZxg46dkZqUdush2M0hUIx1No2B81bx3jvUK9hDQODWfCK6qhIVuLKfyP8qWzuTfKxXUT7 lDWqU/PBS2QlTKXEnaSenZGU+PiKmG72l5vLLqE99Rz72RXMiwx5CdlaCATwBIHrDFefcwgjzK1p 8CzS5B0kXi4tsf6rJZU6pQCdlnJ3+Eke9WMvWVzYcUxKabKk+ZUN438Ojd61eytMPJcSpElZ2DkB Y2h8NYytLzeyVPdlNBat+dilwQTk9lSjmE3vO/5ovf8AnV7u3x+chDC4bLqW8FCUhYKcDHQc8KnE Wq7tDzMto43cDWF3NSFS+yXdhRKtopTjBoQ89p5Wh2czMDoj80kg7RVtJ2vDuJO/vVn3SQ9Mi805 zaQk7XmS4c+EbFZyGpJ89sDwivYMLxvCSfBUkFFaXzDmFJJ6wONZPOsKG0cpx3h5auIYV9M2muhg sOb1x0nwpFWUmtjKtJ7SpthuQEBp/GVYO4pIHrfBXq8UJeXGC1PgedVsqUcd/dmrIbTBVuEdod8J wfeFdBp+37RXzSio9POK8tTrSve41Y8CsOhuPhwpkNp2txUFAZ9YV6trVMCnwy+/k4Uo5UVe/vqy qsUBxGypCyk9BWoivZi0xI6AhtKkp6s1F2TZFZuqEPKjCBAda2GgHSGlJBV/lv31HqamJXs8w9v6 QDir6IjI6z/xVz2M0DuJHjqAUjsaQASXkJ8K1CvZ9q3twYwjOhMxSsOLKjjv572auJjNq4rB8Jrk RGtkDCCKWGRRJTz8VXNl1t8LHFo5Hg4cal4sB16OhfZvMZyrmlN7Wz1ZO7Jx3qsfYcUcW2/WrlMZ hPBDY8ApYXRFXRMmfbkQ0lfmMHnEqHmiOsVELs8oJa7FhFtSUYdUpwHnD18T+6reGmwfMqFdg2nr HrCjjcvGo4tNPYUcxLog4MFzxDPwV2ajSlvJbkMSW2ifNqbbJUB3hV32AOGN9c7h0px4arzUTO8Z Was2UOc2+w64mIZK44UAlLuSo7uPAdNdQ1JkwdlTBLhVnKs52ccMY68b89FX/ZSR54VyMZ4g1bVN d1JPazXL8JYB7HacwkE5UkpJHj6e8K2FyGsvI1ROW4jZHYRA2gdrz6OHe/yr0IBPCrTyfJAvr5H1 qr9ZNLEJmxKUpUElek/1p779Xw15V6yf6099+r4a8q+T1/zZd7+J0o7EKUpWEk//1rtdW5DtomNx CoSVx1pZKVbJ2yk7OD0HON9av7Q8o/p1w90h/HW2qV4PQ/KGtomEoU6UJ6zv68W7d2aN2pRVR3ba 7jUvaHlH9OuHukP46doeUf064e6Q/jrbVK7f47xf+Wo/6H/uMXRI9Z+ZqXtDyj+nXD3SH8dO0PKP 6dcPdIfx1tqlPx3i/wDLUf8AQ/8AcOiR6z8zUvaHlH9OuHukP46doeUf064e6Q/jrbVKfjvF/wCW o/6H/uHRI9Z+ZqXtDyj+nXD3SH8dO0PKP6dcPdIfx1tqlPx3i/8ALUf9D/3Dokes/M1L2h5R/Trh 7pD+OnaHlH9OuHukP4621Sn47xf+Wo/6H/uHRI9Z+ZqXtDyj+nXD3SH8dO0PKP6dcPdIfx1tqlPx 3i/8tR/0P/cOiR6z8zUvaHlH9OuHukP46doeUf064e6Q/jrbVKfjvF/5aj/of+4dEj1n5mpe0PKP 6dcPdIfx07Q8o/p1w90h/HW2qU/HeL/y1H/Q/wDcOiR6z8zUvaHlH9OuHukP46doeUf064e6Q/jr bVKfjvF/5aj/AKH/ALh0SPWfmal7Q8o/p1w90h/HTtDyj+nXD3SH8dbapT8d4v8Ay1H/AEP/AHDo kes/M1L2h5R/Trh7pD+OnaHlH9OuHukP4621Sn47xf8AlqP+h/7h0SPWfmal7Q8o/p1w90h/HVp0 PbtTwpUtV/XJU2pCQ1z0oOjOTnHmjirjStLSHK7E4/DTw06FKKlvjFprO+T1mWhh4wlrJsUpSvHm yKUpQHS/Wp+86V7Ejx0SFl4KKF7OCAe/uqiP8ls585FpLRznLUhA97JHvVti2f1IeE1mV9P0d+50 v5Uc+fts0c7yQ3hZOww6nP1TjSj+sK6J5H719S4nvYa+MrelK3rIrc0T8hu9DfhZJ/Bj/uVkReTD VUIKTGUpKVHJGGjn111u6lLIXZpR3k01JKbDcxh15Oc4S8yn95rxPJJdCoEW13d0GS0c1vGlSQaW b5L7ohKQLK3lJztKkDf4RtYqRRofUSQkCIlKU8EIW2APANrFbYpQGrxou+ZGYROP/ut7/fr0GkL0 OFvI/vkfxVsylAazOkr76n/4yPLXHclfvU8+J5v+Ktm0oDWR0ffT/wCiI/vW/LXQ6Mv5/wDSq9mR 5a2hSgNVnRN/6IR9mb8tcdxV+zvt49mb8tbVpQGqToq/53W4+J5v+Kuh0XqPot6h/ft/xVtmlAaj Oi9UZ3W//Hb/AIq47itT+puf79v+Ktu0oDUI0VqfptY8b7f8VcnRGpTvNrGe9Ib/AIq27ShFjUY0 TqMY/wDDCe92Q3/FXqNFX7ptZ9nb/ira9KEmqO4m/k/OzH9815a7dxWoPU4eyt/xVtWlAar7jNRf WKfZUfxVyNGahH/09PsyPLW06UIsasGjtQepv+M3/FXI0dfsfO/H983/ABVtKlLixq/uNvv1h/jI /irnuNvv1h/io/irZ9Km4saw7jb36n/4yPLXI0ZevU8ezI8tbOpS5NjWPcbehwt/+Mj+Kncbe8Y7 B/xkfxVs6lQDV50Xez/6H/GR5antH6euNpurr8uNzSFMFAVtpVv2knoPeNXKlAKUpQEM/AlLkOKS 1kKWSDtDrrz7XS/Svzh5anaV56fJ7Czk5OUs+1fQzqvJEF2ul+lfnDy07XS/Svzh5anaVX8N4TrS 819Bz8iC7XS/Svzh5adrpfpX5w8tTtKfhvCdaXmvoOfkQXa6X6V+cPLTtdL9K/OHlqdpT8N4TrS8 19Bz8j//19k9rpfpX5w8tO10v0r84eWp2lec/DeE60vNfQz8/Igu10v0r84eWna6X6V+cPLU7Sn4 bwnWl5r6Dn5EF2ul+lfnDy07XS/Svzh5anaU/DeE60vNfQc/Igu10v0r84eWna6X6V+cPLU7Sn4b wnWl5r6Dn5EF2ul+lfnDy07XS/Svzh5anaU/DeE60vNfQc/Igu10v0r84eWna6X6V+cPLU7Sn4bw nWl5r6Dn5EF2ul+lfnDy07XS/Svzh5anaU/DeE60vNfQc/Igu10v0r84eWna6X6V+cPLU7Sn4bwn Wl5r6Dn5EF2ul+lfnDy07XS/Svzh5anaU/DeE60vNfQc/Igu10v0r84eWna6X6V+cPLU7Sn4bwnW l5r6Dn5EF2ul+lfnDy07XS/Svzh5anaU/DeE60vNfQc/Igu10v0r84eWna6X6V+cPLU7Sn4bwnWl 5r6Dn5EF2ul+lfnDy07XS/Svzh5anaU/DeE60vNfQc/IxoDS2YoQ4nZVk7s1k0pXeoUo0acacdiV jC3d3FKUrKQKUpQClKUApSlAKUpQClKUApSlAKUpQClKUApSlAKUpQClKUApSlAKUpQClKUApSlA KUpQClKUApSlAKUpQEff57tq07c7iwlCnYkR19CVglJUlBUM4xuyK0f8nrVXqfaPYXfjK3Tqxl2T o+9MMNLdddt76ENoSVKWotqAAA4knorTnJJoyX3VSe6PTT3YnYS9jthBPN7e2jGNtONrG138ZoDZ PJnq64az07IuNxZjNOtS1MpTHSpKdkIQr6YnflRqg6h5atSWnUdztrEG1qZiS3WUKcacKilKyBnC xv3VuWBbLfamFMW6DGhNKVtqbjtJbSVYAzhIG/AHrVhP6T03Jfcff09a3XnVFa3HIbalLUTkkkje TQGlvk9aq9T7R7C78ZW39B6gl6o0fCvE5tluRILm0llJCBsrUkYBJPADpr37jNK/Y1aPaLX8NScO FEt0VEWDFZix0Z2WmWwhCcnJwBuG8k0BD64vsrTOj594hNsuSIwQUJeBKDlaUnIBB4E9Nae+T1qr 1PtHsLvxlb6lw4twirizYzMmO5jbaeQFoVg5GQdx3gGovuM0r9jVo9otfw0Bqex8tupbnf7dAeg2 pLUqU0ysoacCglSgDjLnHfW8qiGdJaajvIeZ09amnW1BSFohNhSVDeCCBuIqXoDWPKbylXnRd+jQ LbGgutPRQ8oyG1qUCVKG7ZUN3mRVN+T1qr1PtHsLvxlbwn2CzXV5L1ytEGa6lOylciMhxQHHAKgd 281i9xmlfsatHtFr+GgP/9Cx8lvKBdtbvXJFzjw2RES2UdjIUnO1tZztKP1IrYdYNvstptBcNstc OEXcbZjMJb28cM7IGeJ9es6gNBPcu+qW3loEC0YSogZZd6/wldPk9aq9T7R7C78ZW5zo7SyiSdNW gk7yTBa/hrjuM0r9jVo9otfw0B7aauT150zbbnJS2h6XGQ6tLYISCoZOMknHjqG5SNVTtH6ZRc7e 1HdeVJQ1syEqUnBCj0EHO7rq0sR2YsduPGZbZZbSEobbSEpSBwAA3AV5TrdBukcR7hCjzGQoK5uQ 0lxOevBBGd9AaI+T1qr1PtHsLvxlTmjOV/UOotWwLRMh21tiStSVqZacChhJO4lZHR1VsruM0r9j Vo9otfw17RdL6egyUSYditsd9s5Q6zEbQpPRuIGRQEpWo9f8q9+0rq2RaIMS3OMNIQpKn21lXmkg neFgdPVW3KjJum7DcpKpM6yW6U+oAKdfioWo44byM0BpL5PWqvU+0ewu/GVsvkx1lcdaWeZMuTMV pxiRzSRHSpII2Qd+0o799TfcZpX7GrR7Ra/hrPt9qt1paU1bbfFhNrVtKRHZS2FHrISBvoBdZS4N omzGgkuR463EhQ3EpSSM97dWivk9aq9T7R7C78ZW/XG0PNLadQlba0lKkKGQoHiCOkVEdxmlfsat HtFr+GgNM/J61V6n2j2F34yt9RHVSIbDywApxtKiBwyRmovuM0r9jVo9otfw1MJSlCQhCQlKRgAD AAoCj8qGt7nomFb37axEdVJcWhYkoUoAAAjGyodda5+T1qr1PtHsLvxlb0uFotl2QhFyt0Salsko EllLgSTxxtA4rB7jNK/Y1aPaLX8NAULk65Ur5q7VItdwi29pksLc2mG1hWRjHFZHT1Vteo2Dp2x2 yR2Rb7Nb4j2CnnGIqG1YPEZAzUlQGltV8smorFqm42uLCti2Yr5bQp1pwqIHXhYHvVEfJ61V6n2j 2F34yt1ydK6dmSFyJVgtj7zh2luOw21KUeskjJry7jNK/Y1aPaLX8NAQXJhrW5a1tk2VcmIrS47w bQIyFJBBTnftKNW64yFxLbKkthJWyytxIVwJAJGa62+0220trbttviwkLO0tMZlLYUeshIGayVoQ 62ptxKVoUCFJUMgg8QRQGgfk9aq9T7R7C78ZT5PWqvU+0ewu/GVubuM0r9jVo9otfw07jNK/Y1aP aLX8NAdtJXeRftK266ykNoflMha0tAhIOTwySffqP5Q9TTdJaVcusBph19LqEBL6SU4J37gQffqx xoseFHRGisNsMNjCGmkBKUjqAG4V0m2+Fc45jT4bEtgkEtPthxJI4HBGKA0P8nrVXqfaPYXfjK94 PLnqeTcI8dcC0hLrqUKKWXM4JA9Mrb/cZpX7GrR7Ra/hrsjR+mG1pWjTlpSpJylSYLYIPX52gJit ccqHKJd9FT4DFtjQnUyWlLWZKFqIIIG7ZUK2PWBcLHaLstC7laoU1TYwhUmOhwpHUNoHFAaO+T1q r1PtHsLvxlWbk+5Vb7qzVbNpnxLe2wtpayphtYVlIyN5WR71bA7jNK/Y1aPaLX8NZELTlitskSYF lt8R8AgOsRUIUAeO8DNASVaZ1hyw6h0/qy4WmJDtq2IrgQhTrThURgHeQsDp6q3NUVK0vp6bJXJl 2G2yH3DlbrsRtalHvkjJoDSnyetVep9o9hd+MrYvJfri562h3B65MRGlRXEJQIyFJBBBJztKPVVh 7jNK/Y1aPaLX8NZ1vtFstKVottuiQkuEFYjMJbCiOGdkDNAe0p1TER55IBU22pQB4ZAzWhfk9aq9 T7R7C78ZW/1JStJSpIUlQwQRkEVDdxmlfsatHtFr+GgNM/J61V6n2j2F34ytyaNvUnUWkrfd5iGk PykFS0tAhIIURuBJPR1127jNK/Y1aPaLX8NSkWJGgxkRocdqOw2MIaaQEJSO8BuFAQGv9RzNK6Sk XeC2w4+0tCUpfSSnzSgDuBB6eutSfJ61V6n2j2F34yt8TYMO5RlRp0RiUwogqafbC0nHDcd1RvcZ pX7GrR7Ra/hoDTsfl21Q7JabVAtIC1hJwy70n8JW/Khk6O0ulQUnTdpBByCILW782pmgNd8qPKBd tEyLc3bI8N4S0OKX2ShasbJTjGyoddUP5PWqvU+0ewu/GVvK4WS03dSFXO1w5pbBCDJjoc2c8cbQ OOFYfcZpX7GrR7Ra/hoDXmgeVm/ap1dFtE6Jbm2HkuFSmG1hY2UFQwSsjiOqtu1GQ9NWG3SUyoNk t0V9GQl1iKhCxkYOCBnhUnQGnNbcr2oNN6vn2iHDtrjEZSQhTzThWcoSreQsDieqoL5PWqvU+0ew u/GVuyXpjT8+SuVMsVtkvuefdeiNrWrdjeSMndXj3GaV+xq0e0Wv4aArfJbru6a3auS7mxEZMRTY R2MhSc7W1nO0o/Uir44oobUocQCaxLfZ7XaA4LZbYkIO42xGYS3t44Z2QM8T69ZhAIwRkGgNAfJ6 1V6n2j2F34ynyetVep9o9hd+Mrc3cZpX7GrR7Ra/hp3GaV+xq0e0Wv4aA8tD32VqXR8C8TW2W35I WVpZBCBhakjAJJ4AdNdNeagl6X0fNvEFtlyRHLYSl5JKDtLSk5AIPAnpqciQ4sCKiLCjMxmG87DT KAhCcnJwBuG8muJkKJcYq4s6KzKjrxtNPNhaFYORkHcd4BoDQ3yetVep9o9hd+MrlPLzqkqA7AtG 8+ku/GVuXuM0r9jVo9otfw07jdLfY1aPaLX8NAeGu7/L0vo6beILbLkiPzewl5JKDtOJScgEHgo9 Nag+T1qr1PtHsLvxlb5mQolwirizorMqOvG2082FoVg5GQdx3gGtP8sejN9n7mdNen8/2tg/g9na 2E/fYz36A2PoW/StT6Og3ma2y3Ik85tpZBCBsuKSMAkngkdNWCqlyXQpVv5O7XFmxnoshvndtp5s oWnLqyMg7xuIPjq20BhXm4dqLHPufNc92HGcf5va2dvYSVYzg4zjjiqZoLlT7t749bO03YPNRlP8 52VzmcKSnGNgfVcc9FWbWXoIv3+7ZH7NVaZ5BvRxM/3a5+0boC88rnC0/wB9/wBFa2rZPK5wtP8A ff8ARWtq4uK/Of3uPpmgf+XU/H/2YpSla52hSlKAUpSgFKUoBSlKAUpSgP/RqtKUrzp9mFKUoBSl KAUpSgFKUoBSlKAUpSgFKUoBSlKAUpSgFKUoBSlKAUpSgFKUoBSlKAUpSgFKUoBSlKAUpSgFKUoB SlKAUpSgFKUoBSlKAUpSgFKUoBSlKAUpSgLLye+jeB4HP2aqu/KFyhdwZt47V9n9m85/6jmtjY2f 7Ks52veqkcnvo3geBz9mqvT/AEhPPaf8En/tV1cF+W+8+f8AKb98j/KvizZukdQ91WmId77F7F7K 2/mPObezsrUnz2BnzueHTU1VM5IvoY2j++/bLq51unmSPv8AAduunbnbmFIS7LiOsIUskJClIKRn Gd2TWv8Akz5Mr1ozUb9yuMqA605EUwEx3FqVtFaFfTJG7CTWzHnmozDj77qGmmkla3FqCUoSBkkk 8AB01hwNQWW6vli3XiBNdSnbLceShxQTkDOEk7skb+/QFI5XOFp/vv8AorW1bJ5XOFp/vv8AorW1 cXFfnP73H0zQP/Lqfj/7MVlxrTcpjXOxbfKfbzjbaZUoZ8IFYlXa1xL3M0TGTZFPJdTKWV80+Gjs 468jNac5aqub2LxDoQTTSu7XexFRlQJsEpEyI/HK/O882UZ8Gax6udybucDSUuNqOQVyHnkKiNPP B1wEeeVnJwMbvX66xblp+0Q3Wrew7NeuMoNlhOUhtG1jz5xnrO7oxVY1L7TDSx8ZL1s83ms00rXd +Cv7mValXXuPtqX+wFNXwyM7HZaYn+r7XXjGdnoz7+Kw7ZpRoszXriic8Ysgxyxb2wtwqH02/o8V TzsSVpLDuLd+G7bcq1Knl2KHOvse32iS8Q9/SIktFLkcjzwVuAJ3dHgqV7kIEoriQ2L21JAOw/Ki 7LCyPFlIPRmjqxW0tPH0YW1rq6vs2LtKZXKUqWoJSkqUTgADJJqyxrLZI9gYud2fmpW46tstR9nJ IPEbQ3Y6fDUtZrTbrRrBttD0h5p6MXYyhs5wUnO14uqjqpXKVdIU4RlZNtX3ZO23MonA4Nc7CtgL 2Tsk4BxuzXvcOxOznewee7H2vMc9jb8eN1WW/wDaruQtPNdmc5sq5na2ccfNbX7sVZztbLabFTEa jprVfrO3dlcqr8d+Mvm5DLjS8A7LiSk4PA765THfWyt9DLimmyAtwJJSnwnoq83e3WOffY8adKlo lyWW0t8ylOw35ndtZ3nPeqBTalR7Ld9qU+DFfS2W0Lw2vfxUOmqKrdGvSx8akE2rN23Pe7ZFfpVx kaXs1uZSmeq7hRbClTWmAqMgkbs8T3qqLiUocUlCw4kHAWAQFDr31eM1LYbNDFU693C9u4//0qrS rLGstjiQobl6mSkPzhttpjhOy0g8Cva/dXjC09FduE3si4o7AgjacfYworBO4J6MmvM84sz6102l m87LseedsuOeRAUqwS7RZ5Vqfn2STK/1XHPMywnawTgKBTuribYosbUMO3IceLUhLZUSRtDaG/G6 imnkTHGU3lmnnk1wt9UQFKs8HTlufn3dqTJeZZt+9KxgkjO/O7eceCvGZYrfKgNT7E/IW0Xww43K AC0qPA5TuxTnI3sVWNpa2rnuztlmrrMr1KtarHppiaLS/cZvZ+dgvJQnmUr6iPPd6se1aciuzbnH ukhxkW9OVLawc4O/cRUc5G1yOnUtVyzyz2PNPK6K5Sp+62i0iyN3W0Pyi3zvNONytnaB6CNndUVb 2Yj8xCJ0oxWOK3AgqPgAHTVlJNXM1OvGcHNJ5dmeXYYtKtidPWW5WqVLtRurZjp2w5LbTzTmOIBT 01jQLPZBp5u7XSRMTtOqb5uPskq8GRuqvOIw9OpWbs7p2tbO5XK9UR33WlutsuLbb3rWlJIT4T0V ZXdJxVXhpuPMWLeuP2SXXACtKOkbt2ayWWrOnTN4ctD8lSChKVokhO0N/EY3Yo6qtkUlpCnZaibv bc8ru2faUylZlpiNz7rGiOlSUOuBKik7wO9U73OWuXdharc/MW8yVGS8tIKAkfUJAyTVpTUXZmer iqdKWrLhfwKtSrg7pOFJjvCBGvUd9pBWFTowS25jiAQNx8NYcWzWWLb4si9ypSHJu9pEYJw2nhtK 2v3VVVYsxLH0ZK6vfhbPiVulWKBpduZd5TCJZfhxU7anYqedU4OgJA6ayLhpeKbY/Mt0e7RlRhtL buLATtp60kDHiqXUiiXj6CmoX229+wrTsd+OEF5lxvbG0nbSRtDrGeNeVWxVkiyZ9uiSZkxZkxNp ordB2V9CRked71RUKztKt9xlzFOJEQ82hKCBtOE4AORwopomGMg43fZ73Ze8iKVcGtJQosdkXCPe pL7yAsmBG2m2weAJI3nwVA320LstyVFUorSUhbalJKSUnhkdBoqkW7ImjjaNaepB5/EnNHCEzabr OmW5ib2MgLSh1CT4gSDiu/dpZfsNgeuj4uu2iZLUOyXmS9GRJbbbClMrxhY6jkH4K6nWdlI9B0D1 0fF1hkrzeV/E5FSk6mJq3pOdmtkrWyW66PKwvQb5rZpfauOxHWk/6tspUgYHVgD3qypWrbLGlvMd x8BXNOKRteYGcHGf6Oo/RK0u6yacSgNpVtkIHBIPRUuqVoN+7OR5FrktuqeUlbq1qCNrO87l8M96 okkpWabyGJjTjiNWcJSSisot5Zvbmr+88ZzNl1JpiVdINuRbpULz6GwAkjq3AA+HFdbA9brbo125 y7RGnrTI2MOoTnBx0lJr11fO7SQjY7ZbBDhvjJf2trnh044+uTmlguEe2aDekyoDU5sSscy7jBzj fvB+Co2wutjasYvWlhE0m4ymtVa2duF75eeRjd2ll+w2B66Pi6xtPrh3jWyXDbmG4zu0RGKQpCcJ 4YwB71ZPdpZfsNgeuj4usXR7yJGtm3m2UsoWVqDaeCRg7quo2TdrZcTZ5nm6FWSpOD1Xm5X+bM+T q6yxpTzHcfAVzS1I2vMDODj0uoa/X633aM21EsUa3KQvaK2tnKhjhuSKmpmsLM1NfbXpGC4pDikl ZKMqIPHzlQF+vUK7lnsOzsW7m87XNY834cJFIRzT1feWweHtOMnRa7XO/u1n8CMjxn5bwZjMuPOH ghtJUo+IVmdz969R5/tZfkrDjyX4jwejPOMuDgttRSoeMVZn7zdBoqNIFylh5U1aS4H1bRGyN2c5 xWWbkth0cRUrQlFQtZu2d+0rkiBMiAGTEfYBOyC42U7+rfWPVmVBVcLban5c+Y8qZKKFhx7aCe+M 9Nejum7W/eE2a3PzFy0OHnnXEpLaUDJ3ADJOMDvmo5xbzGsbCKtPar3sslbJlVpVyVpGDLQ6zBj3 tiShJKXJsbZZcI6MgZGejNU4gg4IwRVozUthnoYmnXvqbjNasl2faS6za5jjahlK0R1kEd4gV4So UuEsIlxXo6lDIS62UEjx1eH4txk2izpg39i3Zj45pyYpkrOegDjWBqRbkSzNWW43FNwuaXwskKKu ZSRw2iMnPV36xqo27GjSx851FHJ3bVle6S38Cn12ShSyQlJUQCTgZ3DjVodsmm7fJRbbjPm9nkDn HGUJ5lpRG4HO8473vVm2W3wbU3f4NwVIW4yyQ4pjZwW9xBTn6beOO6rOqrXRlnpCmoa0U3stla6b SuvMpFc8anLfE06tsGXIuL77rhS1GhtDbSM7toqGCTu3CpqHY4Fl1fbDtzCzJSHGUOICXG17ty/8 ql1Esi9XHQp3TTuk2srXsU5MWSsOlEd1QZGXSEE7Hh6vHXjVrehw5L+oHYUmc02wgqUhSwkOK2jk KA4p6q8U2ew22JFVe5U0yZbYdS3ESnDaDwKirjnvVCqIRxsbZp3yySz2XK1SrVF0lEN8ehyZyjE7 DMpmQ2MZR0Eg+PdWPPtFmdsLt0s78w9juht1uUE5IPAjZ/fTnIkrHUXJRV87Z2yz2FdpSlZTeLLy e+jeB4HP2aqtXKloK663Nr7WSIbPYfO852StSc7WxjGyk/Umqrye+jeB4HP2aq29cLzarRzfbO5w 4PO55vsl9Le3jGcbRGcZHr11cF+W+8+f8pv3yP8AKviyM0LYZWmNHQbNNcZckRuc21MklB2nFKGC QDwUOirBXhDmxbhFRKhSWZUdzOw6y4FoVg4OCNx3gjxV71unmSF1l6CL9/u2R+zVWmeQb0cTP92u ftG63NrL0EX7/dsj9mqtM8g3o4mf7tc/aN0BeeVzhaf77/orW1bJ5XOFp/vv+itbVxcV+c/vcfTN A/8ALqfj/wCzFTT8+KvSEWAl3MluStxSNk7kkbjnhULStVq51alNTcW9zuKsV4vbB1JEuUFfPJjo a6CnJSBkbx4qrtKOKbTInRjUkpS3Jrz2/Au8i7WyVIVOTq+7R2l5WYSQ5tpP1KVZ2R3qjLVNgGRJ fN+uNrkqd20vqy8HUdAWE4JV4d3eqt0qipJK1zVjgIRg4qT/APH6Z+Ny7TdXxmbpbH0SF3NcXbD8 rmQyXUq6AN3Dv9NdHbjbWy5ITrK8vt4ymK3ziXO8NsnZ3eCqZSo5mO4otGUYpKLat3Z534ZbXssT U24xn9LwYaXiqS086txJByATuOeBqWbv1sRqG2SlSDzDMIMurDavMK2SOGMnxVT6Vbm1a33mZpYK nKLi2/4v/Lb/AEMm4NxmprqIkrspnPmXebKNrxHeKl5su3TdKwWezS3Mh7Q7HLSjt5PHa4Cq/Spc b27DNKipal27xd75Z5Wzy3+BZp93gPathT239qO0GttewrdgDO7GaP3eAuBe2g9lUuSFsgJUNtOe vG7x1WaVHNrIwLBU0oq7ysvJ3LvabvbrcG3Y2q5rDASnagvxi6RjikK86M9YAqp3WUzNukmSw1zT TrhUlGMYBNYlKRgk7lqOEhRqOom233fJK/jdloTIsN5t8AXK4OQH4TYZUkMqcDyBwwRwPhryg3Wz NzLjDUy7Gtk5IQlSSVKb2TkKIOc98VXKU1FnmR0KNnHWdnsV9md8suPG5ZXpVms9mlw7ZPduEibh K3eZLSUJBzjB3k1n9sdOTJ8C7ybg608whCXIoYUckbs7Q3Yql0qObXHMpLARltm753eV3dW4W2Jb Ej//08m1vwJj2pXn3FmE6lJK0J3gFe44Pr1gv3K22e2tQbTKXPUqQmQ68potp8zwSAd9QTE6TFjy GGXNluSkJdTsg7QByOPDxVj15hU8+zL3H1WOBWu3JvVyy7klnlt7mW5x3S0q6C9u3KQ2sqDq4XME qK+OAvhjNYse+x3nb5IkrLS5zeGkEFWTnhuG6q3SnNq1rllgYJWcm9iV7ZJO9ll2b7vtJlM+KNIK gc7/AKyZQc2Nk+dxxzwrjS8+JbbyiRMJQjYUlLoRt80ojcrHTioelW1VZriZnhoOE4bpXv4l+7f2 xuNPTJ1NKuT0popRtMLbaR3tnrPWN1Vp6fGXpKNBS7mQiQpakbJ3A8DnhUNSqqkkYKOAp0ndN7U9 25W3JIuCNRW5uRCQta3I6oPY0goSQpsnpGeOK8i/p+22K4woVzclvyUjZWWFIB38MHp75qqUpza4 j0fTVrSaWXDOzur5fAz7JJaiXqJIfXsNNuBSlYJwPFUnb78xb9USZm04qLIK0qU0dlQSfph3xVdp VnBN5merhoVW3LerFvlXCAww8tOsLvO2kkNx2+cbOT9UpRwR14FY7cmx3m1wmrncHID8Ic2TzKnA 6jOd2OB8NVilVVNLeYVgYpZSd+OV+HC3uLTbL7a4Nzmx4/ZMK3ykBCHWVnnGyPp+vf1Vxcp8Nq3u oRqq6XR1wYQ2NttCfv8AbJyPBVXpTm1e46DT19e73X2O9uLab8mievF2Ycdtb0J4qXFZSFYBTsqB 4b6yNT3yDMYYatiiAtfPyMJKcOHo38cVWaVPNrLsLxwdNODz9W/v4/Iuq75CurLD69TT7O8hAQ6w hLi0KI6U7JGM1Wr1Kal3BS2JUyS0kBKXJi9pavIO9UfSkaai7oihg4UJXi33ZZe6/m2WCx3OHD0/ eIsh7YektbLSdknaPhAwPHVfpSrKKTb4menRjCUpL+J391ia0lcIts1AzKmO80ykKBVslWN3UBmo 2e6h64SXWztIW6pSTjiCTiselNVa2sFRiqrq72kvK/1LbCvlvuemHLRe5HNOsb4r6kKXg9A3A/8A 6rvYpunnNLu2m8XByPtP7fzJCiSBjG/ZIqn0qjpJ3NSWj6bTUZNJvWytk+zLeXHtbyf+rk/8g/F1 i2uVY7NrBp+LNcXb0JPzZxBJyR1BIPvVWKU5vi2SsD6soyqSkmms2t/gXV+FoGRIceXe5wU4sqIC DjJOfS6i73D0qxB27Pc5UmTtDzDqSBjp+kHw1XqUVO38TJp4J05J87J23Nq3wFS706MrSUeClzMh EtTikbJ3JKcA54VEUrI1c2501Npvc7lkj3aCi12ZlT+HIsouOjYV5lPXw3+KuGL+xB1jIuTZW7Fd WoEoylRSrdkZ6RxquUqnNr77TW6FSete7vdebuXF+4W5hDjqdY3iWkg7EZvnELz0ZWrd4d1U8kk5 JyTXFKmMNUyUMOqKdne/G3ySJq+3CNMhWpuO7trjx9hwbJGyrPf/AHV7y7pDuthjrlPBF1hKCEko JL7fQCQMZHf/AH1XqU1EVWFglFJv1XdPv2ruZbZT2mbxPTeJdyfiurwp+GGFKKlAfSrG4A46aRr/ AALhdLy5OfXCauDPNtrLZc2AMAZA7wqpUqvNK1rmLoENXV1nsstmSunll2Lbculuu9ubsLVuZ1C5 aVNrWHlNxCoyN+5QUN6d2BxpctQ2ly+WSWxLfeZieZdU6klwYI3kniTx3VS6VHNK9yno2lrud3nf hv27r+by7i0mdaohvqGLj2Qma1lpXMrRlRVkpwR0dZrhb9gv0WG5PuTttkxWUsLTzCnUupTwIxwP hqr0qebXEydCis1Jp8cr7LcLe4t41HbnLpJUlTjMRu2KhxucBKlHG7OOGaiYc+K1pS4wVu4kPPNK bRsneAd+/hUNSpVNL3e4tHBU4qyvu/8AHP8AuKUpWQ3Sy8nvo3geBz9mqvT/AEhPPaf8En/tV58n vo3geBz9mqvT/SE89p/wSf8AtV1cF+W+8+f8pv3yP8q+LLpyRfQxtH99+2XVzqmckX0MbR/fftl1 c63TzIpUff57tq07c7iwlCnYkR19CVglJUlBUM4xuyK1/wAmfKbetZ6jfttxiwGmm4inwqO2tKto LQn6ZR3YUaAyeVzhaf77/orW1bJ5XOFp/vv+itbVxcV+c/vcfTNA/wDLqfj/AOzFKUrXO0TA0zPV e2bUlTKnX0BxtwKOwUkZznGceKvEWKXt3BK1NN9rh82KyQCc4AG7eSeFWWJKQNJJvYWBKiRlQBjH EqGyfCEk1xqmQy1YkyWCNu9qQ8sAcEpQMg/8RzWvzkr28PvwOJHGV3VVPt1fFPP/AMc0cW6wpmaj YauLdtbQmIlwNMkoDm44OOk9J6K8YunkP6fnMIdgLdampBmbY5tCNnf5vHDJHjqSQR3b25JIBVbw lOTjJKDgVEOxJNu0dcYslBadRPQFp2gfpc9G6qXbe3h8TWjUqSlFKdr6ll4u7Ia8WSVZXWkvrZdb eRttPML2kLHeNdbVZ5V4eWiOWm0NJ2nXnl7KGx1k1J30k6XsOT/5bn61NI2uHclzOfiic+02ksxC /wAzzmTvO13v31m1moNv7zOl0mccK6knmm1e3B2vtS99l3GNcdMyrfA7ORLhTYwXsLciPc4EHqO4 VkRtGTpEWNJVOt8duUkFrn3ykqJ+lAxvPD16sN1iPxdETGZECDBcS4g9jxjlaU5wCs5OSeuoO+KU IenRk4EVBG/p2qxxnKWSe/5GpRxdetFKMl7TV7XySvxsR7mnJzSLgVltK7eRzzWTtEE4BG7BHjrG btT7loduZW2hhtwNgKJ2lqPQN1WiZPRC5QX0Pn/V5SQw8OtKkgfDio7VgbtqIlhYUFJiJK3VDgpa t597FWjOTsuP2/vtM9HFVpyhB/xJS8LZ+/4kPbLZJu0wRowRtYKlKWrZShI4knqFZlx01Kt8LsxE uFNYSrYWuG9zgbPRtbhiudLLmou3/h7sVL6m1JDUk+ZeB+k8J8IqxXq3sIszky72KLapjWzzPY7y cPnO8bCTjGPCamc2pJE4jFVKWJjC6s7ZZXz7G0/FXtvIKPpGa6w04/Nt8JbwCm2ZUjYcWDwwMdNe EPTFymTJUQJbZei4LqXVYwM4znhjp8FXSZ2wujrc20WWyXOK6hPzZ5pJcQcYIXlQ4VGCW/Lk39x9 cNbiYaUFUInm927AJ9asaqyzNOnj8RJN3V+G9O6Wa8d5XZ2nnocN2WibDltMuBtZjOFeCRnqAxXe 32aWldulgRVdlulLLT+SFY6VDHna9tKLRJkSbO8oBq4NFAJ6Fjek1IPSEHWtugMKBYgKQwjHSRxP r5rI5ST1fv7ubdSvWjKVJu7Sbvbdb6+4i2tPzbncZoBiRW46zzzqlc2w2c8Aax5+n58CezDKUPrk AFlbCtpDoPSDVi7GXd4l4tMNaezezueSypQSXE8MDO6vGE2dN321JutwC1oB22FK2kxMjA3gkfBV VN/08DHHGVE3Zq6WUbZv1b38/DdtMB3R05Daw3Nt78htJUuI1JCnk44+Zx0eGoAgg4Iwa2OW75Ck qlpsum47DeVpnlASnHQchW1v8Fa8fWXZLjh2cqUSdjhx6KtSm5PMz4DE1K2trNNZbPhl/cn+4a5Z SlUqAhxxIUy2t/ZU9uzhII31HwNPzp7z7eG4yIxw87JXsIbPUTVsu9gnz77DnsusmMw20XVKdSnm AACcg79/GvSJc2rsLoxbY1vlSVyudbZmIyl5OMZGcDNY+dla/wBo0Y6Qr83rJp5K+Xs57/Dj37D/ 1Iufp2XADKw/FlMPr2Evxndtva6icbqkGtGvMTmWp9xtrRU6AWVyCFqTniBjp6Kkbs7dIsJmLPt9 mtwdkoV2PGTh1WD57CSRjv1HXwk67Tk/+e38IrysZyk0rn0uniMRVSWsllJ3Wd7W8N+4zdQ2d64X pNrtsW1IQ0CrbigJLaRu+aq66hbjpmZb4fZiJESbHB2VuRHecCD1HcMVOoKJF/1FbQ+hl+Z5lkrO ApQOcZ79Y6LXJ01YLmLsW2XJiA2zH5wKUog52sA8KrGTikr8PEx0K9Skow1l/DlbOV7Xe3df3ZkZ K0tKhQey5MyE0koC20KdIW4D9SMb6yBoe5lWx2TCDpbDjbReIW6MZ8yMZNcavJ7JgDP/AKRHwVMS Cfki23edzLWO95ira0rXvx9xkeJxHNqSkrtSezhbIgJelJ8O3LmLeiOczjnmW3gpxnP1Q4D167Rt JzH4zTz82BCLwy03KkbC1jrAway7W4ew9SFRKgEAkE8fN1YZJnXRLEuz2Wy3OOtpKS4+0kuNkDeF ZUOFRKckUq4zEU3qtrbt2LYnbN23+4o6LDcXLubUI+JQOCkkYA689Xfqeb04LdYLq6+uDM2WwG3m FhwIVneM4yDWQxcVP6okMTZFvbeeimOhyKSGkqxuTk+tXRixzrJpm8onlDbi0DDSXAo4z57dSU20 r9gq4qpLVjKSj7OXG7zt2L+5S6VlSbdLiR48h9rYakp2mlbQO0PEd3jrFrYvc7kZRkrxdyxWqPAt tjN7nRUzHFu83GYcPmMjiVDp8FdjeLRd4Uhm4W6Hb30p2o78NkoG19SoDOc12tTSL7p7tMh9tqaw 8XY6HF7IdyN4Hfrr3JrtkV6XqFXYiEpIZabdQXHV9GMZGOusD1bvWef3sORKVHnJc7Jqd8s87brL euOXG5iwdMSpkJMx2ZBgsuHDapj/ADfOeDca94VieturIMK4NsvIccSQQQtt1J6R1jw1LWmxNrsk OXbrNHucleS69Ik4QyrPBTeQCMVmXdONZWE/McbKR8w/o8g79nvVDqPWt3mCeOnKpOmnlaXC6sux t+dr8CvuRY4sN7dDDW21NSltWwMoG0dwPQKxdLW1m6X1hmQ4wGgoKUh1ezzg+pHWe9We56HL/wDj 6f1jUdpX0T2/8MKur6svvcjajKXR6zTz/wD5RK3azyrxenY8Rq0MMxUkrfiEIZQnP05+qGKirlpu Zbmmn+djSo7qtlMiM5to2uonFS0BntnEvVojvIRMek840hatnnACcgHrrlyC9p/TbkG5KbRKlyW1 NxwsKUkA71HBxVFJxsr8DDTrzpNU1JZNLVtm00ry29/ZkRVz0zJtEZT0uZCSoEbLIdJcWD0hOOHk rDtdqlXeV2PGCAQNpa3FbKUJ6yeqpHWZJ1G7+DR8FNJW2Hc5z7clkSVoZKmYxe5rnldW10VdSepr M2o16kcHz03na+zZ7172dJ2lpUSAuczNgTmWiA4Yj+3zeek7hXeHpGZLgMTjNgRmH87CpD2xvzjH DjVokQn4ekroy9bINuOxlDDK9t3ZzxWrJzVcuyj3L2IZOPNnH/FVI1JSyT3mpRxlaslGMl7Vr2Ty 1b7nbyIe522TaJzkOUkBxHSk5Ch1jvVIaWhMSLkqVMbC4kNsvOhQyDjgD469dZ77y0T9atfBWbCm jTOlm3DEjyJFyWTzchJUnm09JHhq7k3T7WbNSvUnhI29qdlll3+65G6pgtRri3JitBuLNaS80lIw E5G9I8BrIb0TcVoZUqXAa7IQlTIdfKS4SPOpGN58tZkuaNT6UdX2NHjSLYvaDcdGwjmzxwMmsy7a fuF2dtT8VxpTTURrnQpwJ5kcdog78HvdVUU2kot2NXpVSnCNOUlFq6beexZeasV6BpW5T1Skp5ph URYQ8l5ezs56c4xgcc/DXlctPTbauP5pmU3J3MvRV84hZ6geurYoi/t6jTb32wXnGUIWpQAdI3Yz 38YrDQU6ag2uDc1ITITPElxtKgotI4ZOOk0VSV/l4Ewx1dy3Xy9W2fsp38GRitE3JKVIEmCuUlO0 YaZALw/4cY9+sNuLIGm5LxjxA2h9KVLWg8+lXUD0DrqwsabnR9S9unZDAtqXjI7M55OypOc445z0 VhyX25Olbs+0MNu3ALT4CSRRTb332fEtDFTm0tZSV45pbG3mvvPiY7OiZ7rUdxU63siUhKmQ6+Ul eegDG8+WsiyaYQ6xdkTnIjUiM2pCQ87s80r6s/2e/XF8Urs6wDJwIrWN/DfUoY7ky/6niRwFvvMY bRtAFR3ddQ5ytt4+5mKpiK7p3lO11fZa1pJfB5lbhaXlzohmIlQ2o4eUyp113ZSkgcc44HIA8NZQ 0NdOfUw5IhNOf+Slb+DI3ZygYyR4cUkocZ0C20sFKk3RSVJz0hFZ8lau6/Tg2jgRouN9XcpXyZmn iMRd6slb1t3V8d5XbfY5txlPMNhtoR8l915YShoDcSo163PT0q2xUyxIiTIxVsF6I7ziUK6j1VZL LJC379bmGYL012UVtMzE5Q9hRyPCOivG+OXaFYpDE62WW2IkFI5lhOy67gg5ASSN3fqOclrW7iOm 1niFDJLLLe00rtb/ACyyzI5jRU95mM6qdb2EykJUyHnykrJ+lAxvPD16yLHphLjd3bnriNSIzakJ Dzuzzavqz/ZweNdb6pXP6eG0cCI0Rv4b6l1MOTNSanhsAKfejbLaCoAqOE9dVcpW28fczFUxFd07 yna6vsta0kvg8yhOI5t1aNpKtlRG0k5B7471dKzHLVOZhLmOMbLDbxYUvaG5Y4jGc1h1sppndjKM lk7ilKVJcsvJ76N4Hgc/ZqrddaU5PfRvA8Dn7NVWrlS17ddEG19rI8N7sznec7JQpWNnYxjZUPqj XVwX5b7z5/ym/fI/yr4s2DSq/oW/StT6Og3ma2y3Ik85tpZBCBsuKSMAkngkdNWCt08yQusvQRfv 92yP2aq0zyDejiZ/u1z9o3W9rnAautql259S0tS2FsLUggKCVJKTjOd+DVZ0jyZWXRl1cuVulT3X XGCwUyHEKTslSVfSpG/KRQERyucLT/ff9Fa2rZPK5wtP99/0VrauLivzn97j6ZoH/l1Px/8AZilK VrnaFKUoBSlKAUpSgFKUoCSstyh2yQqRJtqZricFnadKA2odOBx6Nx6qw5kp2dLdlPq2nHVFSj3z XjSq2V7mJUoqbqb39+HgKUpVjKKUpQClKUApSlAKUpQEhebp23n9lczzPzNCNna2vOjGc4FR9KVC SSsikIRpxUI7EKUpUlxSlKA//9Wq0pSvOn2YUpSgFKUoBSlKAUpSgFKUoBSlKAUpSgFKUoBSlKAU pSgFSF3unbV6O5zPNczHQzja2s7PTwFR9KixRwi5KT2okI107Hssy3cztdlKQrnNrGzsnPDG+o+l KWsIwjFtrfm/h8hSlKkuKUpQClKUApSlAKUpQClKUApSlAWXk99G8DwOfs1V6f6QnntP+CT/ANqv Pk99G8DwOfs1VsTWOgrVrcw+2ciYz2Ht832MtKc7WznO0k/Uiurgvy33nz/lN++R/lXxZh8kX0Mb R/fftl1c6jNOWGLpixRrNCcecjxtrYU8QVnaUVHJAA4qPRUnW6eZIjVjzsbR96fYdW061b31ocQo pUhQbUQQRwIPTWnOSTWcvuqk90epXuxOwl7HbCceb29tGMbasbWNrv4zW6r/AAHbrp2525hSEuy4 jrCFLJCQpSCkZxndk1o/5AuqvVC0ezO/F0Bu1tVh1KwH2zbrs0yooDidh9KFYBIzvwcY96op+Tyf Rn3GH3tNtPNKKFtuKYSpCgcEEHgRWNyZ6RuGjNOyLdcXozrrstTyVR1KUnZKEJ+mA35SaoOoeRXU l21Hc7kxOtaWZct15CXHXAoJUskZwg799VcU9qMsa1SKtGTS7zYfZ/Jx9d6Y9kj1Jw7Tpe4xUSoN utMqOvOy6yy0tCsHBwQMHeCK0x8gXVXqhaPZnfi62/oPT8vS+j4VnnOMuSI5c2lMqJQdpalDBIB4 EdFNSPAnpFbrvzZky7Rpi3xVyptutMaO3jbdeYbQhOTgZJGBvIFRfZ/Jx9d6Y9kj1m64sUrU2j59 nhOMtyJIQEKeJCBhaVHJAJ4A9Fae+QLqr1QtHszvxdNSPAdIrdd+bNrsyeT2Q8hll/TTrriglCEL jlSlHcAAOJNS/c5YvUW3+1UeStP2PkS1LbL/AG6e9OtSmospp5YQ64VFKVAnGW+O6t5U1I8B0it1 35srs9rRFqeSzcm7DCdUnaSiQGW1EcMgKxu3GsXs/k4+u9MeyR6rvKbya3nWl+jT7bJgtNMxQyoS HFpUSFKO7ZSd3mhVN+QLqr1QtHszvxdNSPAdIrdd+bNwW+Noy7lwWxixzS1jbEZDLmxnhnZzjgfW rO7nLF6i2/2qjyVTuS3k/u2iHrku5yIbwlpbCOxlqVjZ2s52kj6oVsOmpHgOkVuu/NlUM7k5SSDK 0wCNxBcj1x2fycfXemPZI9aue5CNUuPLWJ9owpRIy871/g66fIF1V6oWj2Z34umpHgOkVuu/Nm6m LHpuVHbkRrVa3mXEhSHG47akqB4EEDBFeU626TtccSLhCs8NkqCeckNNNpz1ZIAzur301bXrNpm2 2ySptb0SMhpamySklIwcZAOPFUNykaVnaw0yi2W92O08mSh3akKUlOAFDoBOd/VTUjwHSK3Xfmzn s/k4+u9MeyR69ormgZ0lEaGvTsh9w4Q0yWFqV07gN5rUvyBdVeqFo9md+Lqc0ZyQah07q2Bd5ky2 uMRlqUtLLrhUcpI3AoA6eumpHgOkVuu/Nm0u5yxeotv9qo8lRk06EtslUacdPRX0gFTT/MIUM8Nx 31Za1Hr/AJKL9qrVsi7wZdubYdQhKUvuLCvMpAO4II6OumpHgOkVuu/Nlw7P5OPrvTHskes+3wNI 3ZpTttiWWa2hWypcdtpwJPUSnO+tOfIF1V6oWj2Z34utl8mOjbjouzzIdyeiuuPyOdSY6lKAGyBv 2kjfupqR4DpFbrvzZYXLBp5lpbrtotqG0JKlLVGbASBxJONwqH7P5OPrvTHskerDdYq51omw2ikO SI620lR3AqSQM97fWivkC6q9ULR7M78XTUjwHSK3XfmzanZ/Jx9d6Y9kj1Mp09YFpC0Wa3KSoZBE Zsgj1q0l8gXVXqhaPZnfi631EaVHhsMrIKm20pJHDIGKakeA6RW6782Q9whaPtKELuUayQkuEhBk ttNhRHHG1jNYPZ/Jx9d6Y9kj1g8qGiLnraFb2La/EaVGcWtZkrUkEEADGyk9Va5+QLqr1QtHszvx dNSPAdIrdd+bNuQRoa5yOx7eNPy3sFXNscw4rA4nA31Jdzli9Rbf7VR5K11ydclt80jqkXS4Sre6 yGFt7LDiyrJxjigDo662vTUjwHSK3XfmysSXtAQ5C48p3TjDzZ2VtuqYSpJ6iDvFeXZ/Jx9d6Y9k j1QtV8jeor7qm43SLNtiGZT5cQl11wKAPXhBHv1EfIF1V6oWj2Z34umpHgOkVuu/Nm47fB0hdm1u W2LZZqEHZWqM204EnqJTnFZK9P6fabU45Z7ahCQSpSozYAA4knFVzkw0VctFWybFuT8V1ch4OIMZ alAAJxv2kirdcY65dtlRmykLeZW2kq4AkEDNNSPAdIrdd+bP/9a9dn8nH13pj2SPTs/k4+u9MeyR 61X8gXVXqhaPZnfi6fIF1V6oWj2Z34uq6keBm6RW6782bpjWXTU2OiTFtlqfYcGUOtMNqSodYIGD XSba9K2yOZM+BaIjAIBdfZabSCeAyRiu2krRIsOlbdapS21vxWQhamiSknJ4ZAPvVH8oemZurdKu WqA6w0+p1Cwp9RCcA794BPvU1I8B0it135s8+z+Tj670x7JHrsiZydOLShEnTKlKOEpSuOST1Vqn 5AuqvVC0ezO/F17weQzU8a4R5C59pKWnUrUEvOZwCD6XTUjwHSK3Xfmzc/c5YvUW3+1UeSsG4R9F 2laEXJmxQlODKEyUstlQ6xtYzVgrXHKhyd3fWs+A/bZMJpMZpSFiStaSSSDu2UmmpHgOkVuu/Nk3 2fycfXemPZI9ZELuFuUkRoHc9LfIJDTHMLUQOO4b61H8gXVXqhaPZnfi6s3J9yVX3Seq2btPl29x hDS0FLDiyrKhgbigD36akeA6RW6782bI7nLF6i2/2qjyVFSndAwpK40tzTkd9s4W06WEKSe+DvFW etM6w5HtQ6g1ZcLtEmW1DEpwLQl11wKAwBvAQR0ddNSPAdIrdd+bL12fycfXemPZI9Z1vh6PuyVr tsayTUtkBZjNsuBJPDOznFad+QLqr1QtHszvxdbF5L9D3PRMO4M3J+I6qU4hSDGWpQAAIOdpI66a keA6RW6782WhWnrAhJUqzW5KUjJJjNgAetUN2fycfXemPZI9WaU0p+I8ykgKcbUkE8MkYrQvyBdV eqFo9md+LpqR4DpFbrvzZtTs/k4+u9MeyR6lItm0zOjIkw7bapDDgyh1phtaVDvEDBrS/wAgXVXq haPZnfi63Jo2yydO6St9omLaW/FQUrU0SUklRO4kA9PVTUjwHSK3XfmztNtWlrbGVJnW+0RWEkBT r7LSEjPDeRio3s/k4+u9MeyR699f6cmaq0lItEFxht91aFJU+ohPmVAneAT0dVak+QLqr1QtHszv xdNSPAdIrdd+bNqpncnKlBKZWmCScAByPvqZ7nLF6i2/2qjyVpWPyE6oaktOKn2khCwo4ed6D+Dr flNSPAdIrdd+bK/cI2jLQpCbmxYoRcBKBJSy3tY442sZ41h9n8nH13pj2SPUPyo8n921tItzlskQ 2REQ4lfZK1pztFOMbKT1VQ/kC6q9ULR7M78XTUjwHSK3XfmzbcM6EuMlMWCdPSn15KWmOYWs4GTg DfwqT7nLF6i2/wBqo8la00DyTX7S2rot3nS7c4wylwKSw4srO0gpGAUAcT11t2mpHgOkVuu/NlZl uaCgSVxZi9Oxn2/PtPFhC07s7wd43V49n8nH13pj2SPVI1tyQ6g1Jq+fd4cy2tsSVJKEvOuBYwhK d4CCOI66gvkC6q9ULR7M78XTUjwHSK3XfmzcNviaOu4cNsj2SaGsbZjIZc2M8M7OccD61Zh05YQM my24Af8AtUeSqpyW6EumiGrki5vxHjLU2UdjLUrGztZztJH1Qq+OJK21JHEgimpHgOkVuu/NlV7P 5OPrvTHskenZ/Jx9d6Y9kj1qv5AuqvVC0ezO/F0+QLqr1QtHszvxdNSPAdIrdd+bN0RLRpifFRKh W60yWHM7DrLDa0KwcHBAwd4NcTLTpe3RVyp1utMWOjG068y0hCcnAySMDeQK8dD2KVprR8CzzXGX H4wWFqZJKDlalDBIB4EdFdNeafl6o0fNs8FxluRILZSp5RCBsrSo5IBPAHopqR4DpFbrvzZi9n8n H13pj2SPTs/k4+u9MeyR61X8gXVXqhaPZnfi65TyDapCgez7RuPpzvxdNSPAdIrdd+bN1uQdP2NB uLkW225LPGSpttoIzu89uxnOPHWrOWPWe+z9zOpfT+f7WzvweztbCvvsZ79bG13YJeqNHTbPBcZb kSOb2FPKIQNlxKjkgE8EnorUHyBdVeqFo9md+LqUkthjlOU3eTubT5Lpsq4cndrlTZL0qQ5zu268 4VrVh1YGSd53ADxVbar+hbDK0xo6DZprjLkiNzm2pkkoO04pQwSAeCh0VYKkqKUpQClKUApSlAKU pQClK4O8UBqi/wDK3eXb6/bNHWLtl2KSHXVMOPFWDjISgggZ6TnPeqxcnvKIjWLb0SZFEO6RQC60 M7KxwJSDvG/iDw3bzWtYF5uvI/qm6MzLMqWxNV8yWpwthwAkpUlWCDuVvGMjvV66An3CXyzOy5kI wn5iXVvRykgoChtDIO/q40hnZbbr3iplfv8AcWzXPKPqKyavFh09bI89YZStSCw464VEZ3BChuxj orM0Nq/W18vq4modOdrogYUsPdhPNZWCMDK1EdJ3VRLk7qybyuXqRpaItc9oloLUhPzNAwM+b8yM gbs9Zq26A1/qB/UzulNWsgT0hWw7sJQraG/CgnzJGOBHV00p5pPj9+4TybMCbyh8pzM59qPo7nGk OFKF9rJJ2gDuOQqsvQnKRqzU+q+1M+0w2WWUqMktsOIW0RwB2lnBzuwRVp5SNUHS2kn5LC9mW/8A MY+/eFHirxD38V58mWmE6d0qyt5B7OnAPyVK45PBPi8tIb77viJ7rby4Vr3XnKa7py5osdkt3bC6 uAHZUFKSjO8DZTvUSOgEVsKtU8oeiNSp1QjV+lHC5KSkbbSSnbQQnGUhW5QI6OOeg1V7VwJWx8TA Y5YdVWiaz3V6X7FhvHZCkxnWFjrI2yQrHVu8NbfiyWZsVqUwsLaeQFoUOkHhWj/kp3aO4zbNfaUj zWUhKtmRE5t3q29hYKSePAJ8NXLXmtWrJyfxJenFIZE8BEVbaAkNIxk4HAEDd3qs3aNyqV5WNiUr UETkZE6xpu8q+T1X95HZCXg4CgOcRnI2ie/tDr71ZWg9W3G+6Nv9su7xfl26O4nnlHKlpKVAZ6yC Dvo8k+KJWduDNq0rVfIL6Hbn+Of9IqM0u2HeXe+tqyAtL6TjvkVZx9bV7L+643N8GXaRr0J5RGNI sQd5G09IWv8As5wlI8W8nxVha513dNM6ps9qhR4jjM4pDinkKKhlezuwoDh3jWtHtB2tfK0rS5kS +w1+aLm2nnMlO1x2cce9UvytwVwdS6agwHVJW0yhthxeCQQvAJ3YPrVWP8D4vzG+S4I3iN4Fc1o7 lA0F3LWZnVDF9uMi7JeRzrzzg3qI4pwAR65qd1dru5weS21TWHS1cLo2lJeRuKN3miOo03N8HYlJ 3XabUpXzdIa0hbbQi7WbWdwVqVsBwnmnEpWv6YA7AI8JURW0oky8685Lmn4N2btk5xBS+/ggK2dy htA5QD0kZo8k3wIW1LiX+lfOOqdPaY0ta4s2y6sVLvqVgrEaQlxIPSQUDKd/WaumsdR31fJDarhH kPtuS0oEuQ0cKCSOscM0fst9tvMLakbaqL1HfGtOWGVdnmVvIjI2ubQQCo9Aya0Pb7ToqY1DfsOr ptpvfOAk3E82lP1RC0JwD1ZVvrYXKlptqfoJFwnTnJMu2MhSHWgEoeJwMkb/AHjUSyjcRd3YtmjN ROap04zd3Y6Y5eUrDaVFWyAd2/p96p6tXcjGlIESytajbdkGXJSptaFKTzYAPQMZ9+to1eSsysHd FD15yoxNIvi3Q43Z9zWP6PawlvPDON5PeHr1Uvku64tRblX3SaWoJOCrsV5jazwwtZI96vLQ0dm7 cs12lTkJcdYW4tsL34VnAI8FbjusRidaZUWS2lxl1pSVpUMgjFY1dQUuOZfJyceBGWjVcHUGmHL1 a1bQQ0pRbcG9CwM7KhULyZa1uWs4U965MRWlRnQhAjoUkEEdO0o1SeSFxTMbVMJGSwhpRHhAI+Cv bkhuJtOjtSXAJ2jHXtgd8JOKvdLWe61/eQk3G2+9j//X3NVAt2vLpL5U5WlXI8QQmQrZcShXOnAB 3nax71U3RmiHOUhuTqbUF5mh5TpSzzCwCgjvkHAHQBiumiIcy38tsiJPmKmSGkOJU+vzy/M7ie/i rRXrpPg/gG/VbRdbfry6S+VOVpVyPEEJkK2XEoVzpwnO87WPeq/1oWTbpt25cLhBhT3YCnlKS4+z 58N7I2gD0HHTXOobEeS/W1ofsVxlrTMUOdTIWCV+aAIUUgAg56qrHNQXEma9aVtxvmlUblH05M1B Fi85qNm1WhCh2Y26rmwsHp284J6gd1asn9qNFa0tx0XqF6YlSkpkEOhY3qHmdpKQlQPVvpHOSRD2 XR9GUrSvLIqV3aWAwnC1JKMNrAyUqKhvqO5QNIO6ENuv1uvVweub7uHn33AVFeOIOM47xzUJ5XfG w32XC5vulaK1pox+3aUjazkXyfJvai2txxawEp2t4CMDKcZ68VtrRlxkXXSFsnSlbb7rAK1fVEbs +9VrZPsIvs7T31Lc3rNpu4XKOltb0ZhTiEuAlJIHTgj4a1JB5WeUW5x+yLfpePMZzs85HgSHE56s heK2hrv0DXn8UX8FaV0Pyr9xlhNr7SdmZdU5znZXN8cbsbB6uuqra7l2vVT7WX3QvKtKvl8Nh1Db kQZ6iQ2W0qQNofSqQokg+PxVsytF6PZvOvuUprVjtvMSEwraLiUnY8zwSFHzx68VcOUPSa77dIb9 41SzbrAnzLkdxwMna6wVZSpR7/Dv1Z3sr7Si2vgbEpXz7YZEHS/KnCt+lL29Ntsl1DT+V5Ssk4IJ ACVY6CB46z+UqNJm8r1vhxJKoz0hpppLqeKNokZFEr6tt5PG+42hrzUMvS+k5N2gtsuPslASl5JK TlQG8Ag9PXXtou9ydR6Tg3aYhpt+SlRWlkEJGFEbgST0ddULWGh7Vorkxu7VuckuqkuNKcckLCic KGAMAADfVOjaid1Fp/T2goEpMVtxWzLeXkAqKyQnvjp7+6izulm7ol5RTfafRdK1/qzQsCHyWyrN bGtnsRHPpUfPOLTvJJ6ziqpO1IuZyERI6HNqS86mCQDvOFZx+Tiqt7bbre/+oS2X3/I3XStMaLvj 2nOTbU0GSQ3LtTi0hJ6FLGyPDvHv1Icn2l7mrkqf7WzxbJ9zWpwSSkkhA3AZGCnODv34zmpe/sS9 5C3X4v3G16V856l0xpfTlganRNXCZqJKwpSYslLiCvPmsFI2k461EZxVl1MxM1VyLWu/PqU/Og/N FuHepSQopJPiAJ8FNzfBkpZpcTc9K1jqTWgd5F2bi25/rNwZTF3bjt+dX8CjVi5MrGLDoaAypAS9 IT2Q7uwSVbxnwJwKm2b7Ct8l2lspSlQSKUpQClKUApSlAKUpQClKUApSlAKUpQClKUApSlAabvHK HrDQmrJjF9jm525wq7DBShkFOcghaUb8A4IOayuS+x3e66ona3vUUxuygrsdCklO1tEHaAO/ZAGA emttUpHLvEszT1815rTQeqZKb1HN0tLqldiEoSykjORhaUcQNxBzXTQsK7615Ql64nwTChNg8wN+ FnZ2QEk42gBnJ4Z97clKR9USzv2mn+Vlw3PXumrIre1tpWoZ47S8H3k1t5CQhCUjgBgV2pRZRsHm 7itQaym6y0PrNy/xlzbjY3fNKZW8tbLYOMpIyQjfwOMe+K2/So33RO6zNB6i5SblyjW3udtml/mr ywo7LhfUMHiPMjZ471HoNWnUPJ1cZHJVb7UyOeuVuAd5sKztE+eSP3eCtp0qWlayITzTNQRuWQ2+ xptEqwz039pAYSzzYCCvgCQTtDwbPez01I8m2ibjb9N3aTdGzHm3htSQ0oYUhJBxnqOTw6K2dSjz vfawsrW2I0LoPWA5OZFxsV6tFwVJdfCmm2WwVKURgDBI47sEZzmsvk+emyuWa4SbhDVDkPsuuKYX 55GSkgHv1u+lSnZpvhYPY0jSGrbj3Ics6b9cYkhUJSAUKaQCV+ZwcZIBwe/XblKntXTWGkZ7CVpa kJacQFgBQBc6cZrdtKiPq6vYw9rfE17y1fQ+V+Mt/vqBvWlpupORuxKtzKn5MJlLiWk8VpI3gDpP ercFKjc1xafkTfZ2GjIWvNGtW+PCc5PGZF4TstLY7BZAUrgd+CrPe2amuU+BMe5PISrLZXbZCDnO yoLbKUFAI3FSUZA35z79bZpUyzREfVZ833SXp65aKVH0xpKQ06wUuTp7yAoN4G8BZUTvJ4bvBV/h 3W+ReSK0ydO26JdUoZ5uVGeZU6SnpwlKhnvjfW0aVLeTXELd2HzhfrrozUVvDFn0lMi6ifKU7MYb LQV0hKAo7u9sg9+tkSdP3aPyIrtDzC1zkRd7KfNKG/ON3UK2PSoecWuIW1Pgat5GtWwX7U1pgMSU zYyVrWtSU83jPXnOfFW0qUqW75lYq2RpbWendQ6M1qvWOno6pUd0lbqUoK9jPngoDfs9+sW4cs18 1LBVaLJp8tTJKSgrbcL6iCN+ykJGPHmt50qqWWq9hdvO62mudBaLk6S0VcXLhgTprK1uIBzzY2Tg eHrqvckFu7baP1Jb9rZMhewD1EpOK3PSrPO996sQskl23NHaO1o7yaNydNais84uh0qY5hAJWT1Z IyD0EZpoqVPn8tjsy5Q1w35DTi+Yc88hJTuB6t1bxpRPNSe0hrJpGm7L/wD5Cz/A5+oK55afRTpz 77/rFbjpRO2r/wBpdvNvif/Q8eV5l9nV9rn3iJIl2BCEhSGyQM/TDIxgnw1WdUSbXLk2a4WLTbto szTiW0yHmghT6s5JJydrAHHJr6SpSPq27Hcl/KxpnlScQ7rzS7iFBSFpSpJHSCoVI8vHzltX43+6 tq0puS7bkLJ37LGtOU36ELH3kf8AdVm5OvQDaPwH7zVlpU329rItlFcCA136Brz+KL+CqzyH+gNX 4258ArYtKhZX7SzzSXAVoflCQ3A5UOztW2+VOsi0AMpaJAKdngkgp3g7yM1vilRbNMXyaPnd6TDP KPp+6xLCqx2lbrSY4caDRdSkjKyB4Rvyc9Zqy6rAVy82XIBGGjv8JrcdKsna3YyrzTXFWKRywfQ5 n/fN/riteHREd/kggagtbGxc4ylSXHE+fcSFEEZ7wAIHe79b6pVbZOxa+xFX0NqRnWOkGZC1BT4R zMpJ+rA3nxjfWnLLapaOUePpBwf6nEuZkBsgnzIGf1cV9F0q1/X1itvU1T585RoU2JygTbNCGGr4 plakfVHO7h3xV85ULNcmOTRi3WdtxbUTm0yG2QSVNpGOA3kZwTWx6VS3qapa/r6x83uS9PXDQrsH TukpCrk20hyfPdQFpZCRlSkrKiU5wd3mc56a2ryZNxrtyVRYKylxCm3WXU9WVK3HxEVe6hdVSdQx bOXNMwo82ftgBp9QCdnpO9Sd/jq0nk095CWy240FZ7Nc7hquJoWWs9iw563FpxwG7aP5Kd3hr6WS lKEhKQAlIwAOgVrrk40TebbeZ+ptTbAuc3IS0lYWUAnJJIyOgAAE7q2NU/wpPbvI2ybWwUpSoJFK UoBSlKAUpSgFKUoBSlKAUpSgFKUoBSlKAUpSgFKUoBSlKAUpSgFKUoDo64llpbqyQhCSpRAJ3DvC sS03m33y3puFtkB+MskBeypO8HB3KAPGs0gEYPCtVxbn3IwNZWfziozhdiJyc7Lu5OPGahvb3E22 d5sKy6itOomnnbVMElLDhbcIQpOyodGFAVhu6304xNXDcuOHkSBGUAw4Uh08E7QTjPjqiaTbTyfX ybCfKuak2pM4bR4uJHm/XNd4+nXZXJBKnFsm4SXDcwo7jtA5B/JqXZZ7l9bfJkLPLjs8v7Gxr1fr Xp2CJt2lCNHKwgLKFK80eG5IJr0m3eBbrUu6S5KWobaAtTuCRsngcDfWttQrRyhixWlpRU2uAua6 EE+e2cIB8dYy7ovUOitM6dypT0uWGJI6dlo+ayO/ips81vv/AEF1k91v6/A2VatS2i9SnotvlF15 hKVuIUytBSFcD5oDjXZOo7Su/qsKZg7ZIb5wsbCvO9ecY6euqrckN6c5T7ZNSA1FucUxXFZwNtAy M+Kqk0FtX+Jr5RXsSruuOrq5k+ZTx6Miis2vvfZB3Sf3uv8AU22/e7dGu8e0OyMTZKCtpkIUSUji cgYHjNRmutRNaa0vKlql9jSFpKIy+bK/mnR0EevuqH00Be+UW+XsjaahBMKOeI3b1EeHdU7rf0FX b8WVWOf5d+z79xaPt2KW/qiFqPkcuCWp65cyPDSJZWlYIWSOJUBnxVMWvlC0nZLNbYFwvLTUkR0B SEoW5sHHBRSCEnw1hz/oEH/dyPhFTemLJb43J3HhIitcy9E2nRsD5oSneT1msk8nP74lIZxh4/Is rEqPKiolMPNusLTtJcQoFJHXmq0/ynaLjzzBcvzHPJVsEpQtSAfvwnZ8eaoDdwlw+Q15EdS/NTFx vMqwUoKyMA9HVVjt03U8awNWtjkwYVBLQSW+20fZcBHEjZ6eNGs2TuVzYTb7LrAkNuoWypO0HEqB SR156qq0nlS0TFmLiO35rnEK2SUMuLTn75KSk+HNQlhtcm08n12g6sD9jgFxRRzclDi2mlb9lKk5 He4eKujWpI7uljZLDoW9yYpjlDZlxkMMLRjzxcUSO/w31Vu1ws9psJu4Q3rf2wZkNuxS2XA82dpJ TjORjjXS1XaDe7e3Ptz/AD8Z3OwvYUnPiIBqicmylnkplJWNnY7JSE5zsjfuqX5K/of2/wD4vhqz WbXcRuTJGVrGyN225ykT8JtpLchXMr+ZrxuGNnf4sioHkx1pH1Bb1w5NzXKuocW4tK21DCM7sHGz jvCvDQhBl6zIOR2arh95XhpKU9B5IbhJjkh1syCkjiDmq3snJ8EyzV2kuNiy3XlG0hZZyoM69tIk I3KQ22tzZPUShJAPeNT0GfEucRuXBktyY7gyhxpQUDVZ5NrVBi6GhLaaaWua3zklzZyXlHOdrrqs 2l5VguOtrdblBESM2XmW0bktKI3gdVTL1Lp7r+4hetZot9z5RNI2e4GBOvbLcgHCkIQtwJPUSkED xmsjU8hmXoq4yIzqHmXIqlIcbUFJUMcQRUVyc2eAnk+ioLLbvZ7RXJUQCXSrOc9ddFWy0Wbk+vNt s1xMxhlDu0C+lwsqP0nmRux1Gq1VaMk+BNN3kmuJiQmLRI5HYLV9lOxYBYRzjrIyob92PMq+CrQ/ fLNYbfb0ypvNMSAlqMtaFHb8zuzgbt3ScVRbl9AaN+Ab/WrvyhRGp9k0jEeG027JaSoHpGwKyS9u S7UY4eyu5+4s7PKTo5+59rm79HMgq2BlKggnvLI2T69d9ax7FJhQhfZr8VpMtCmVMgkqczuB8yrd 63hqP5TrfETydy0ojtpERKVMYSPmZB3Y6qitcrU5ozTS1qKlKkRiSek4FV4d6+Jd7PBl9ul3t1kg qm3OY1Fjo4rcVjPeA4k94VH2HW2m9TPLZtF1bkOoGS2UKbVjrAUASPBVbvzDV25WbLb5oDkaNFW+ hlW9Kl9Bx3qsF/sljfvFsvNwmiBLiO4YdDyGudJ+kO0PNDvCizs3v/sQ+CP/0dzVGXvUVn05EEq7 z2ojZOE7WSpR7yRknxCpOtfQmGbryyz3JgS6bbDR2MhW8IJO9QHXvptdhsVy1WHVVi1O0tyzXFuU Gz5tIBSpPfKVAHHfxXW/atsGmEoN5ubUUuedRhS1nv7KQTjv4rHk2Sxsayi3tc0RLm42WUMh5CBJ HfSRlRHequ6EYZuWtNTXiYlDs1iSGGlLGVNIwdw6s0WbGwtti1RZNTMKes9xalpQcKSMpUnwpUAR 61Y83W2m7c7NamXVthcDHZCVoUCkkZAG7zR7yc1W9SstWnlR09OgpSy/cCtmUEDBeTu3q68V5aat kSTyv6knPMocejBsNFSc7BKRkjqNFnbx9weV/D3lmtuvdK3aJIlw71HLMUZeU7tNbA68LAOKWPXm l9RzTCtV2bfkAFQbU2tsqHTjaAz4qql2s9vmct9uMiI04DDLqgpIIUoZwSOkiszlAZbRq/SEpKAl /tgG+cG47J6M9VTHO3b9bEPK64fS5sClKVBIpSlAKUpQClKUApSlAKUpQClKUApSlAKUpQClKUAp SlAKUpQClKUApSlAKUpQClKUApSlAKUpQClKUAqjat0HL1Bqy3XWNKZait7AmtLUoF0IVtJwAN/j Iq80pvT4Dc0UflD0HJ1eq3LgSGYy4yih4rUpJU0cZAwD39xq4sxGmYCIaUjmkthvZ6MYxXvSm6w3 3KRoTQszS1yuMqdKakh0huLsKUS20CTg5Axx4DNeWneTx+z68n312QyuG4VGIyhSstlRycgjA8Rq +UosmmNzRWNe6Yl6psKYtukNxprLocZdcUUgHeDvAJG49VeE7RSpHJyNMtONJkIZSEOknZDgOdrP Hr31bqVFsmuJN80+BVNM6XuOm9EKtceUz21UlSjIyVI509OSMkeEVmos90uGjV2m+TWnp77BbekN J8yVHpAAT8AqepUy9a995CytYoMfSurHNCTdMXGRaFDscMw3WS4CQD/5mR1DoFW22W92Fp6PbnFI LrUcNEpJ2c4x1cKkaUed77wsrW3ffyKZY9CFnQ0jTd6Uy6H3XFlTCiQnaVlJBIG8VixrJykWyELT CvNlfhoGw3MktOiShHgHmSQOGc+Gr7SjzYKYvk6jdxMjT6JripEhfPOTHE5K3c52iM8O9WO1Y+UK Zb02i43izRIXN82uTCZcXIWnGMYVhIyOJHCr3SgWRU9DaTl6b0y/ZLi6w+2p1zYU0onKFdeQMH16 i7VpXW2nEOWmz3a0m0LcKm3ZLKzIYB47KR5k475rYFKPN3BTtEaMm6ZbvDM2YiUme/tocCiVkEYJ VuAB8Ga8tKaVv9kblWWe7bJVidLhQUBwSPNdBBGzj16u1KfSw/uUCFpjW+mGXLbpu6WmRbCSWRck OB2OD0J2NxA7/rVM6Z0YzY4E1E2SbhMuRKpkhSdnbJGMAdAqzUoCgRdLa107HdtWnLranLWtRLRn oc56MDxCdnccdGaloWjRa9Ey7FFkB6TKQsuSHvM844rio4zgevVppUNXTT3hZO5TJejrjI5M2dMo ejCYhtKCsqVzeQc8dnPvV7ah0pPu0bT7Ud2Ok2x9Dj3OKUAoJTg7OAc+PFW2lWvnftuQlZW7LEHr KyydQ6Wm2qItpD0hGEqdJCR4cAn3qjNQ6Sn3bTtnt0d6Ml2A4yt1TilBJCAM4wD1dOKt9Kj+j8iX n98Ssaq0m/eJMO7WqamDd7eSWHVp2kLB4oUOo9dYEbS+pL1fIdy1dMtpatytuPEtqXNhS/qlFe/d 1VdqUWQeZCzIuoV6nhyIk+O3Z0IUJMdSRzi1dBB2T+sKjNQ6UuLt+a1JpuaxFujbfNONyklTMhHU rG8Y6xVtpQFPs2l7y/qNGotUzIb0yO2W40aClQZaB4qyreSa8rjpK927UT9+0jOhsvTABLhz0KLL h6FAo3g1daU7gf/Sutm0jdXtRI1JqmfGkz2UFEaNDQQwwDxIKt5J79Zdk03Mtusb5eXnWFR7jsc0 lCiVpwADtAjHrE1ZqUBV5GmZr3KLE1Gl1gRGYqmVIKjzhUc8BjGN/XXbVOm5l8u9imRnWEN22YH3 Q4ogqSOhOAcnw4qzUosrdn1uOPb/AGFKUoBSlKAUpSgFKUoBSlKAUpSgFKUoBSlKAUpSgFKUoBSl KAUpSgFKUoBSlKAUpSgFKUoBSlKAUpSgFKUoBSlKAUpSgFKUoBSlKAUpSgFKUoBSlKAUpSgFKUoB SlKAUpSgFKUoBSlKAUpSgFKUoBSlKAUpSgFKUoBSlKA//9Pc1KUoBSlKAUpSgFKUoBSlKAUpSgFK UoBSlKAUpSgFKUoD/9k= ------=_NextPart_000_0098_01C29330.B7655560 Content-Type: image/gif; name="clip_image009.gif" Content-Transfer-Encoding: base64 Content-ID: <009401c29363$018405b0$66902244@ROSS> R0lGODlhFwFdAHcAMSH/C01TT0ZGSUNFOS4wDQAAAAFzUkdCAK7OHOkAIf8LTVNPRkZJQ0U5LjAX AAAAC21zT1BNU09GRklDRTkuMEI8pPUAIf8LTVNPRkZJQ0U5LjAVAAAACXBIWXMAAA7DAAAOwwHH b6hkACwAAAAAFwFdAIf//////8z//5n//2b//zP//wD/zP//zMz/zJn/zGb/zDP/zAD/mf//mcz/ mZn/mWb/mTP/mQD/Zv//Zsz/Zpn/Zmb/ZjP/ZgD/M///M8z/M5n/M2b/MzP/MwD/AP//AMz/AJn/ AGb/ADP/AADM///M/8zM/5nM/2bM/zPM/wDMzP/MzMzMzJnMzGbMzDPMzADMmf/MmczMmZnMmWbM mTPMmQDMZv/MZszMZpnMZmbMZjPMZgDMM//MM8zMM5nMM2bMMzPMMwDMAP/MAMzMAJnMAGbMADPM AACZ//+Z/8yZ/5mZ/2aZ/zOZ/wCZzP+ZzMyZzJmZzGaZzDOZzACZmf+ZmcyZmZmZmWaZmTOZmQCZ Zv+ZZsyZZpmZZmaZZjOZZgCZM/+ZM8yZM5mZM2aZMzOZMwCZAP+ZAMyZAJmZAGaZADOZAABm//9m /8xm/5lm/2Zm/zNm/wBmzP9mzMxmzJlmzGZmzDNmzABmmf9mmcxmmZlmmWZmmTNmmQBmZv9mZsxm ZplmZmZmZjNmZgBmM/9mM8xmM5lmM2ZmMzNmMwBmAP9mAMxmAJlmAGZmADNmAAAz//8z/8wz/5kz /2Yz/zMz/wAzzP8zzMwzzJkzzGYzzDMzzAAzmf8zmcwzmZkzmWYzmTMzmQAzZv8zZswzZpkzZmYz ZjMzZgAzM/8zM8wzM5kzM2YzMzMzMwAzAP8zAMwzAJkzAGYzADMzAAAA//8A/8wA/5kA/2YA/zMA /wAAzP8AzMwAzJkAzGYAzDMAzAAAmf8AmcwAmZkAmWYAmTMAmQAAZv8AZswAZpkAZmYAZjMAZgAA M/8AM8wAM5kAM2YAMzMAMwAAAP8AAMwAAJkAAGYAADMAAAD/////MwBmzDMAmf//zAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI/wABCBxIsKDBgwgTKlzI sKHDhxAjSpxIsaLFiwOtsNrIsaPHjyBDihxJsqTJkyhTqlzJsqXLlyatLLRyLZDNmzhz6tzJs6fP n0CDCh1KNNC1a8+SKl3KtKnTp1CjSp1KtarVpdCuyVRIE6PXr2DDHkT0DJjZs2jTql3Ltq3bt3Dj yp2b1trWhF3F6t3L1yFZuoADCx5MWK7dmdf6Kl68+G/hx5AjS0Z7mGtixpgze3U8ubPnz20r472s ubTph5xBq14tWTTCvKdjyzaYmrXt23RdH4Q9u/fFFcAj1m7LqThuwsWNH1+r2yDvgYE4rpjJ8S6A FRun+95L86hWiMPTcv9yUtAJp+VpnahQsZb8QDzA5Kw/71m9E+bWd5MeuML794T9eWddd9ptFxYr 3iF4lxVWFDhWWW25d9B9q+EhB31ouSceCQNxKAcw7sHnmQoAsKdWcwU9d51/rFgmIEEEGhhWd4EY FKCDtEHY3kDmFSchhaB5qJaGaMkhEJBmGQmAiJ2RaGJd+Tm3n0ABvoiQUVbyh6OMF9HUoo1HbUlQ ePG9J95AGHom0IdqKXcWeU+i5WaTJeKHGJg1HVUjQghiGSWXYRn1ZUE3EgRcgeFxwuGSaymJZGdC xkXeo7Y5aadleEYXpn6sBJhfg69FFwiohGq3gkZ7ZnQTqTZaIeqoYlL/6SoroxLaIIKdnjodcN01 2OAKozIoUHhKxpnWomkCw4kc9l24lnLjqXBfcY4mdxYnltCXHIcqWGsWtsmehYd60oYrJ7lsWnri nzBOuaJWvR7Up6eGbmoogv79N1CY2B01aL/5pppRvlkShCWLBXZHsEwE63lqsMPqiBaJAFD6JgAk pCkhQWyixeF5i5IAzKIFiWwWeSZvzHGSAiXLCcUEdbsjQRmrC+WdhB7F8DWD8sevzvVe42CVN+Fr XZj40kqld0X7G3RNNxUMQNI24Su0QBpZXR0A0SW9ka8MbjUcJ2jS5R4JTjBLccdmfXz2feQKhLa0 FwOQ5HpyrydzmQCk/0n2kXIwK3eyFEsrOMZ1rotz0DJhiaOg71pX6NI8O4grQXpW7rPm0AEtkKBD O925vu9e3XnPmw/N6thy0+VoegIxOXKJFYe75pAYp0UipUpi+HffcgoUp3tI/m6sWSi2i6dMNBbU Z+RBJ+x56vuKPnqU+Gr3fIq1Uo46AM2fftDkCLGeuFwcWsytx8KzdTvsJp+1u1q91x2uexhyGP9Z xV462vICudzArkYv6n2OZ/LSl3dCh0Ap/UeACvHTQazHtQbmzHTlk9i32icXJcnOfmdBlvsAwLaT 5W5iFaNfy+R3vuCR0Cx4ONJaOHgzTF1wK44TH/QMOLWajM9BFHyXwP82tycsseJXVzpKEjEIOTzF KmJtoiFc3HOh5CQnRCE84QxfCD/dpTAt9VOW8KyYnBh+EX9rsRll2DUwAAqxelspIOUKpKeG1LFd PpxgA6uUoO4NBIIpslcFv/euJwLAfPt7C8wU0rH0teV9GdKiWeYHxhUCw4wLMRGR1KLGsySvjTf8 oxLBZy85FrJ6Q0TIHQeYSoFYD2D5OqIoCUlKJlowegoxn93Qlze9+VIFJGCSI0dYQhBJEhiULJIl lVSiX+oNbSZMJAuPB4xPYs1dcoyXUVJlSvKtUiHfrGUrARDEh23EP9q7JR4L1MQLGjI8i/ogWsaV LoHMZZhbLCbKvMj/u2XKcIr2TGMLPcnGa7oxgJWbXjcFub2FhDN8FxwnlbBUxFEaJIcHJCT5HtSo f87sPGiMCz7VAsmLJTKZ/LPk3yyGO+BxcqDIKygpD1rBPPVsoRgEpCjvEs4AETJeDm0gRgtCwXbi MiGJGghb/mYyDz7rgyNNS0mjyU8VunR2LMUDhpRUzL9R05ozDeUAp7fDOV7Pnai8KFkPeDUv8WmP 4RSnwdRpVqRqsG4Wo+IGv9jFLLIUGFM15kn5mtKrhtSF2pIiy2BaTZmqyJQ9FGRZT+m9AvWrZ3H1 qYOAqtlA6kuC/MneXDW61oKQSVFH8p17hudRExI2quyj1D5R2M+r/zLVb/qLJBdhOJCvOhaba+0O 6nC6WX+FzWiYy6Nn4aWRojItbAez7HMZJDWjEsRousoRcQiSNgll7Fhyk4OFVgvevxKvOCKaLQtr qzEeiVdCsvudE/AwLozByX+vAS7p3si4o47VP/mJ6zUJlkqFxRJHsExQlKy7OaZplzgki1m4XjYh tcD2WgZxbVUryShlGiSYbYpwy4zk28XBKBBbclWKUWwoWNmoa7Ra8ROBxREWjw/GtGJj1r4WKjbS mMemvSv91EMCw7llXMAsV6PM45bxkODJFBpPCZklz/EwWTxELnIxMwRMtJ1HyvjVD6DGzBcyoefM twGrisjMZouYGf/NcAaNmt3V5jpL5M1xznNrfmvnPlMEz3oONGHm7OdCg0fIgk70oPls6EYvBNCK jjRc5nyoSlv60pjOtKY3zelOe/rToA51pVkBjWAc49SoTrWqV83qVrv61bCOtaxnTetUX0MP0nKC rnet61o27NfADrawh03sYhv72MhOtrKXzexmOxvYyHALeURN7WqH2sDPzra2t83tbnv7KLjmta5V 8CGVOZpy3063utfNbm6zq9znxlO7503vettbagOBd7yfdu9++/vfzX63MffdYIAb/OAIXxhC9E3w 0n07JNw+4qGwne5gHYzeHVG3wM19bj52m12nyvYQPf7w5GLc5N7/3njD0Z1yFzUbwe3GbL1l/m2V r5zk25bpxZU913nnKuQzR/nHFz7whuNc29YRVbssXpPmGve4Cj7xxYPldBZRfec8C1vVmbvzqweM QYKCOou0XnWat/wgDCf40bN9lypJN2EZjVJz/wTZ61gtSgDrlANprvflwj20xtXPLTVOdI47eu3P bvtGbEzKLRklVv2hO+ks29DgiNKy0pM5LWv6xBjxZ7RCd3fhV+7woUcQg9BRfM+iM6BZXVdfNDEV rsBuwV7RXubStQ6CLMv4/uTK7rAffLptbnTCjwb1XZOevgL0euViR5ZLG9qp8DXyWVHwlkZ9/MDa bnWbLEj4NR/9/82N/+IFjhWPR9sPcsE5zn7Fyq37Ehi+5io97nNOSmY3vUHSvm/EO1v3HJEv7OQd 6JdczScmlVZa19R3BrERmCN/2IdBNGF/vPd9+Sd6aFd0akd+azeAggRU79J89ndErnIwOWZ5rqQn LgYdmLV6EVh/PgOBqQJ/KRh+GWh4jeZ/AVdwAjg6y+eAo9N8qwd9dhccWcNNKAYc0sGCyZUwROh+ 2xeD18WANEhOwyd+xXeFLNeDbCVZeKR++NY5TxQdACJ8mzdUEyiFo3GBOYeFG6iFpYdOPlhaBtZ8 pQUsYUhR4wNICeJ45ndNFJgiPsOGSOeG/aduXvdrVGc1CiZ2Av/iiE9He7GkdVhHda7SiNTlH4k4 XZdIgpeoJ1CndVkXNuRXEPwXbzqYcKq4iqW4MjhoaKnIirI4i/9niKhIi7iYi214g6QXi7r4i8AI YLbYccFYjMYIbMSndkWxjMzYjM74jNAYjdKoE7FyiqR3jdhIZtaYjdzYjbKxjd4YjuKoGOA4juZ4 jhhRjui4juzoEKeINmnDLCJmjvAobru2SBcRj4fTjrORdiSwZajlFeQWOK8YG3BhEWgjH1cFWPzY jxpoLiyEEWkyZgdJEUBCHi7UkLHBcH+VRRexVYBCTRkZEfujayOpkaXBcH6jZHXDEPGoMvvDTO61 jwjxj/vYXR//FjhyMI/cdS46SZA5SZOAwyyWcC1OUI9HOSGBw5PxyJNDWZD/WJDYyHAcFpVHOZEe lTZWZS4o4zIS8iTLUiR741pj+S0y2ZMtuTJmKSeL4iwWVlJHWSSwk1rigY8ltCy9ZZR7dY5UKR7y mG+65TtssZNsQTdsQTx0QTYiKUb7x2X3aElLtVtRtJDQ5BYX5lpXZlUW8zvmqJIR0lrksWXxwTYQ +Shu2TaSGRfkliFsY24QaRYB5RZxoihIQiJS1ZHIVDynCVjfxT9pQiJbdpbiyHDShBaW0EJGoi3p kZASkiaRomEpJSerqZcZIp02aXiv+Te6M5tIsknItEsbxDbA/5Qe4AWeyNSakGkkh7mOaVeWsEOe J8OVJOM7sZkkWnkWlhCThGWbHiOfCOEWJKZMw7M/isI2lckyLgSf36JrrZkmzJKZZMNh7PiOm5ma G2Re9WkkuBkfrGWg5glYoqmBrfUyuZaU3UlYk9IWRtKa+hmTG7qbjWIsJLOhkkYYG9Nr9kVSedVa x3KioqkczBJJExknXBWZpuhh5YEWrQWc67mQ66FM3clSgvks9BGkhRVeP5mlWrqlXNqlXvqlYAqm HgKSkAmbx8OZ0lKUPRpbHmaTT7af5kk2SMJMuqamSnqkV6qWjCmeGHKUTxZhE3miUapb3ZVbheWm IyWV43iX2f8yl7ijHH76m2wjj74zHxg2kfrZnW55lMZiEK8Znxj2oUhiCQ+qa4sSPLUpmYZ5N2NJ NqrVqv+IQiiJMZ+qLG2JWE1mobH6magaSeIZonxDELXaoufyFnF5qXcKXp8amgD6obPaIdk5o7rV mztCKWWqTJmKQkMqbRnWZHOKogvZJpMap/XJkNQ6l+HKP08mVc/KIy5zlnESYTBKYSMKmOciRSma RWyTby4zj4t5N5E0PMCaJJEUsMYJrXWJp9fSP2nZrowUOH0aFnOzb0girR6JkOqhEPDolA77EJPZ sSNqCSJLnyBraG9Zste6IShbaBhiCYrakF7mJtiSlCs7GwEBAQA7 ------=_NextPart_000_0098_01C29330.B7655560 Content-Type: image/jpeg; name="clip_image011.jpg" Content-Transfer-Encoding: base64 Content-ID: <009501c29363$018405b0$66902244@ROSS> /9j/4AAQSkZJRgABAQEAYABgAAD//gAcU29mdHdhcmU6IE1pY3Jvc29mdCBPZmZpY2X/2wBDAAoH BwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8 SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABQAFADASIAAhEBAxEB/8QAGgAAAgMBAQAAAAAAAAAAAAAA AAUDBgcEAv/EADIQAAEDAgQEBAMJAQAAAAAAAAEAAgMEEQUGEiETMUFRFCJxsSMyoQcVM0JSYYHC 0ZH/xAAWAQEBAQAAAAAAAAAAAAAAAAAAAQL/xAAXEQEBAQEAAAAAAAAAAAAAAAAAARFB/90ABAAo /9oADAMBAAIRAxEAPwDZkIVOzjjlXQ1zKSlqXQDg8R2i1yb2AQXBCyptViOICNlS+WZkoYA4yuuC 51txyWqRt0RtaOgsiPSEIRQhCEAhCEAsyzxKDmGcbG0bGnl036+q0xZPmOYy47Vv1ag6UgWPK23V Er3l2NjatkkmzfENudPINF+6bzZ7r52l9LHAxhJ06mkm3/UggkZDSuqGRtYdDyCBYnoLpZhchdSN B7IzrRct45imKw1ZkkhL4i3RqYQBfvZMHYhjrHWFFQyju2oI9wq/ko2jrd9nOaCFb4SGCzSQPVZa iClxCvkeG1FFFEOpbOHfRNFzFgc7Vqdf1XSrFCEIVHiV4ihfIeTWklY1JKZJTK4khzi8l38rWMdl EOA18hNrU7/ZZJIY+ECARJo06WtNvVEr3LePB5bkHyWu3luVwYWbU4HYphiXlwhx2s5zRt6Jdhp+ GR+6Iu+UaiKmpKyaZ2hge0E2unjsyYVDO2F9Q5r3C4PCdayR5Ue6GiqH9HyBv0VkZWsLA0sFgLch dQdVPOyojjmieHxv3aeVwmaVRVDXvZbqUw8TBe3Gjve1tQ59kjSVCikqaeIhsk8bCReznAL22Rj/ AJHB3oVQmzhUeHyzVEC7n6WAXtckhZXUPcdXxXjkLa/39Fof2g1XBwqmgDrOlmuNx+UHv6qiU8Zf FJLI0EBwDTpHuESo8Wdw8Fp2k/O8m56pfhrwdrdV15kkDY6OLfyxareqX4T5pefI3RONLypTNmwJ 7XD55jy6WC7zh9WDYOY4d+SX5al0Ze2O5lcmAqZNP4r1B2U1MYAC83f7Ko1s7PvmpbJEJRHVOe2/ 5T3Cs9PP8aziST3KqVWx0uM1haAbzutcoqXNUwnrKESASNkpQSHdd1Zsqzulj3J0iOwHaxCqWZQR iGHtPMUjfcq0ZPuGEH9B9wqJ805amzB4cxVgg4Id5XM1B17f4qjUYFHgVZDSYrPqjnu5pp2WJPKx 5LT1BUUVJVlpqaWGYt+XiRh1vS6GKTiGVsu4lT8eXxETtIa2XjadI6c9klh+z3EoNVTh8zaqHUQx r/I8jvvsfotQjoqSJwdHSwsI5FsYBU6Eil4PhOKUeGNhnw+TXrJLdbD/AGTWPCaotGqngaexf/gT 9CGEn3ZXA/hwbfpkI/qlkWWcSZVSSufDZ8heNL99+m7VbkIYp+MZXxGvrYZ4xTFscHDLZJHAhwN9 rDknOEYdU0UuufhAcPTpjcSL3Hcck3Qhj//Z ------=_NextPart_000_0098_01C29330.B7655560 Content-Type: image/gif; name="clip_image013.gif" Content-Transfer-Encoding: base64 Content-ID: <009601c29363$018405b0$66902244@ROSS> R0lGODlhiQBHAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAACJ AEYAh4GBgQURAgohABMjChgpEwwuABMxAhU0CBo0Bh83FRs7Ag4uKhQ6sxc3xhNJwBhN0wVcyBtV 4DMsHTY0KCFCCixQDDFRFzJeBi5AIjRILDRWWTtSgjNNty5TqjdXpDtesSVZ2SlZwCxe5DtiEzhk uS5hzDBq2SVt7jVw6jqC8UE7LEhIOVdRRFdaakFcl0BkH052E0duJkhlRE9lokdot1ZwolRzu195 s0BnxlBszkN420t7zFV72UF26lWHG1mCSluFkVqIzkWC+1eI4laL80qQ812V4lmY9WRfUWppXWVo bnV1bHF5hmB9wGB46mWLZn+DhH2HnXWbiGSCpnWPv3ObqGyIxGSK2W2K0WmW23eZ2XCL5mGM/2WO 7mWW6nqW6maY+XumynKg/XKi6n2o+4B8bo6Fe5SNhIuSlYyUhJyWjJeam5SYroadzoSc5J2mlZSp vYek2ZKo1Yey1Z6y24Km5I6r4Ims7I+x+4W0/Zi16Je9+ZHH/6Wdlaymm6SnqKWrtbStpq6urK6z t7u0rKKxzq21wqu837W83bi9wri8+brGrqbD6qTH/bfH5LjN8anU/7rX5Lff/8O6s8m8v8LL08/L wM3NzNrN08rQ09rSyNTa39XczN/d3cDK5MfT6tDc7tjf5Mrm+93n9eTbxu/f0+jc4uLj2fDs2fn7 3fTm5uTp7vfq8evr4O7s7OXu+evy+/v09fD++/P+8f//+f///wECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwj/AAEIFFiroMGDCFkVdFWLocOGEBkWHEix osWLGDNq3MixI8eDrkKKFGkqVCtTnVx1atVpZcuXMFOGrOWxps2bOHEudGVqFapQMV9igrmp06VM Ly8ZvcRUaSdZNHNKnUrV406RQF2heskT1VaWpkqiQkkKEydKZi0lMnQJkyuFVePKjduQlV1WtFC5 muWKFq1UtWLNSuU1r11TpUqRWqzJ0qVAhASxbcVwruXLNcPiVYgQ1qpXm0BtsmQoUCJAglCzeWPG jBo1bGILeuNHaWXMuHNXDGXqrqtNlyoJgiMITZTjZqRAWcJESYsWSpQsSUMdNpvIbAQtShlVt3fM nXrj/3UFJ8qMDRtooHfhwoYbO3eqzJh/Y4aWR48OPcqESPgaQYlw992AloWFCi2uwFKIFV9s4UQO NGyBQwc0eJEHGRjywEMOHOSABx52NKIIIpcY8l+AncBSUXcEtuhRKZywcqAslWiRRyN77JEHJGTo EAIIOgzBBRlgeMEDAwzQkEMQeyiiCCiDQAGFGWwYkogniVSi5ZZccunJJV8CZ9SYSpVJ5plmpokm msC1mcklbsIJ55ttgtllJV8yJVAnmJjilSyR2MCDF2CIwQcfeRARgQgggNADD4VyEUEDSDLppCeA rLGGIZV0sgossLzySqijjgqLLKdCBRVCrLbq6quwHv+kai2qzirLrbSiGuqupxZ0CQB8dqLXLKtQ EUIJIJhghA4p9GCCCY2WUIITYnCBwgNI8pCHFTZUqSkci3jy2SuykHtqqqjSKmtBq8Ya66q2qhuv vPTCm6u855KrLywGXYKKJZzohUoqeiR7wgmNRhBBowyDgAIRRODgwMQOoBABAy4c8seJm4yL6sfq ItRuyCS76+rIr9obb7r8yhLLrS+DWqq+/f6LiVcHMmICCgc/e8LCDT8AJBE9PGD0xELfcAgba7CR yCahnItru/YaRPW6WLMrcslad311yC1rHTZUp+qL6qirXlILJZbgnMojPOiAwtx0n/Asww8ojIII Rzv/YMIRdjzix4mZkNvq1yhbnfXJh2/ttdaz1tLyrPy2LDOp5aYtiyWWlOJVKqJ4oYMQJ/RANwop pIBCwiAsGsEDIpzg9xH3GfJGlZkkKO+8iVfd9e++h3z115Cr+zK9lSOf+b691qL2JZRw4ictq9Sx Q+pCCNFDDzoQIcTqezcsghhkSFwCDXskwoYfiVzyqcuyPNIED0o/nnjJI/feuOPxjh0LrcdT1eQk dzmz+aoWpYheKfwEizvwAHvZ04EETecwEViwUTgAAx6y4CMPuKESa3gDIC4RNajIgQM0KAQNHGAF xnWAB/lbHMlUxqrgDa9eklvVqV62vHKBKm21MMUk/zThOVPAYg9BKEIRhJCCIWSBCBM0XQ/AQAYe kMAGWdiDJPLQAxto4RJNa1+KavEIBrRQcjfgwCfU9YhP8KsWkWBAHBT3O3rVcV33s9Ub3wg/+N1L gJIrlQ/fqDZXEIISpVBFSPQQhCMoUQhkyEMeRNcDIqCgB3yQBBlsYAc8MEIUe/CCFaxwiTeoAUCd eEUtbtCBVRjkEVZ4RC0OQQMGdKADh9BDBzxwy8XdD2sxtGPkcOi/HE4uVGf7oa8AsLZJkCIx5GHC EaY5zTHkAQxE014PjPAFI3iBDF/Qwh328IUrXAERTNNOKD7DABvYsRafaKcrXkGDDoRCCx3QQyjw B/9M4b2LjpJT1x7lFUDK6QpzpoLKr2iBCUIQsRSuMMQUjmCEaRJhmkvMnvZ2gIIdDMFIO7jCFr7g hi9UghBr+AMlCpeJDrShIHKQQxzisAordMATj9gEPkFhBQbMQobB4987EedPst0reb26Vdl4tcxa cGISlngmLThRhSPU4QheyKoXjDCEIXRhq1nIQh3qkIc7jFMOe5ADFQyxsT88bRWP6IAcaNWEG9Rz FbfMKwM88AkaeGB/KKvaL4saUKMaVlUBPCoBkWk2fv2qFqgIBCWeiQpOwKELRCoUGbJAhjHUAUNZ CMIos2CHOtghDnJowxQ2wARNvYEtoQBFB7BwEJv/1qID7kQIbhWXxxpuLXI0BK5ACxvQypFNqT5M qPOY6YpADLEUnbCsFTDkhTCEoQpVAIJ2gaCB7nr3uytYwAJWIIgwktAV9cQVKNp5WxqoygqekO0c +RlY+gI2oAAcbv9yhate5atsmVtuQQRBCEugpBOGsIId5jAHKTzhBzF4wQUqQAEKVKACBjBAAQqQ YQMIoAACSMAb3vAfEsoCERTKzy6DUAs6mPERNWDAITbRzjioElb1/S0/ixc5/1Iuh0D+oahE1atf MZMQgTCwsCpRgylIoQoPjoGUR/CCGMDgBVTGsgVGYIEuUxkDaiAxKk9Fy1tqQQuGKEgcbkkDT8CU /1ugwOEw7evbw/7PsMcj6NSIey5kykyhBLGEZM3SiUU8QQY+SHSiYcBoGPig0YyW8pSpPAIMRIHE f6jEJnTnWzx2+r4zlDPYiseu4yb2XLTysb5M5ViCcMIPaMEEKTghBUQr2tGPhnSjI/yCXr+AwgNg AqYTkYlV3GrPKyMsj9/5ON46e7jGJe5xw+ZjXZnNcEauRSf8MAmzVPYNI5CyrqXs6153uQIWqEAG KHAAAQQgCYOTTMeSJ9xkB7Vxway3tJf9Y8T2F35LLVWrmYmKNQxReqR4w5YvwPALjGAEE6ZwhSc+ 8QMMYAAECIAMBreG9oViagUVNb+T7Wl/tux/+v81KlJzZVyApzqQACaXLIwMAFYEYtA3ewMGLKyA iRtAAR0+gAEOIHSiH4DDCcg4BgKhKUFswhRycCOtDqGIPUbdDfDi3Sw/UV/BLjvVbqB22A9hBzm4 4RD+PWofeVg2Io9quQQJBLc1YZZFYEABPc/whjc8dKMbPegWD0AGmL6pSoTCBnNFFQfcaUItWIEG zY5cCA5RasLu146IB6AV5jrbmN4gB5N7GQ9Z9jEhZw4WmRhILSzRhyT7y+4CEADGZX/xovtd73xH gIcxQOL/dMrxUKEl42tBg31qbRSy7K/UGcD1WoDCjcKF9iNAYVjnd0CVbqAtLOxpEBqgHeCfeET/ tEE1/V2VCu7M7ETr0dKJRKwgAO4OwMUHsAACJOAA9yd6honO4QzD3wwohUptcAO0QgNy0AG08giQ RwN6EFe0tHgFYQeLZ4AICAs8QAM0wAGgUEYFcQgMsE+wwAG6ZFc8wEdQwQNyQEtQEVf3knm3cggc YEsdMAqwUEY2IIPid3ozp3qu4AfcFj2WkAQBMISyZ38JkGFHmH99h38eNoQBsATl5Vad0AY2IAuj 4F4MwC9aQHkd8Aly4H21MAsMAAqv0AFxJgv1VAuj1IEIaIa1YAMkIEuHoAVgWAtUQHlQ8TKbQCHG VgtfqCpl+AhQIVs2AAug8AEf4Ie3JBpm5Hbk/0JzANCDrWcJmHAJSgB/9jcACaCJCSAAHYYAoAiK TSgAGSAdkZFST/OFtYAFnEeGHSAL66WGkFcQZmgFWmAQbWAF68UQUGGGZhgKNHADc1V8MiYr1MYA ibeKBmgHbfABtCU5PXWGbdCFNuUJt9IBN3A2upJ6qkcIfQBrlWgGAWB/+tdhGSaKBtCJRCgDasA5 lEAJ5eUHhrAJicAB28cv3ncItMWCLrhesoBL6tIGWiAHw1cLY+h9biAHZwYK7nSAL4SH8oJ4HdAr dZVadrBPuEIhuCIHY3iDp7JeWmAuaAOJtYAJauAHhNAWayAABGCOHMZhFACK7hZ7GABvm8AKpv+A CZwTCNnBFig2h7SCeMVXC3FAgB2QfI/wV2OoLgYoBwRIK7K1CohHArTglFhAebWwCp4wjW/HL1ZA W8JIKx9oNcdlRqlmU3jFeIrgAXaAUKhHEQikBut3FhMwAJ7oiR1GAR5mfyyQBGVgCK0wC6gAPZTQ FpbgB2/wNC11A83neO6lhm2wClloQu7kfSvYAZnwCCSgLlrgTlpQAy30CDYwkYfgCKvCAMk3S7kF CvY4Ctd3bEBGfDRQNhQiW1gAFWt2CCJ5KpAYia9RYJpACSwQABr2Yfc3kzXpB5yQF67ACZZQYGyj k37wByPUMewFFW3AAG6GhofgCZtJK1jQQlr/MAP5YVNx5kWPcICutGay5AkdMEcO+AhVMIvxM5vH hoLu+XKWUwsSqAWIUE+g4AkMQAfg6QGewCujwo1RUQt+YAbOxTniOABEF3uaiAFL0DaQVYmcAD2W wDbPKQiSoWmhMAtyIEsfKQe9YgdwBZGIkHxOGQegIAdQ4QpacANYYDheSDY0VRCgUKNboEomdIYF EQolegh9lGq4Mo0pJguHoIv8QoXXxpsEQROyEAhmwG2cowbwJ38rYAZpUBuukArR1RQ62aGEgGSD kAiLkAlQozv2tjv+VHJkyWO4UnLHxVvjdy8CdWxTk1w+xI2qpwlnAGts0wextwJpwAlhuhKt/8AU lUh3lqAJiQCiAEJsobBOUnNs42cro8dfyAabtQJkWQebx1Qr/xZkpIdqlRMzQrYrOwiXnPAaUCVo ZaAGlyCYcLKhnIAJOsmrG5oIk9o+m9CmoAIqxaV2OXRqhXVn9HasYVMLbtAGZoei//MKbiAobWBc MVMLoJEJX5IJUfNy05Yu5OqqpQKoBGEKanAGksU2nnMKGtoWQ1GJANOhghAIg1AJcBIKCVKsirVD /aV21Kan/lYvLyNbwchKZggLN9gGVNABHACkqgIKdpAHh0B2WMAGmWCsuuJHUtNnpCKlFcEKazCo UMU2HEqJu3oJptCowCoIfxCi+/oZrvAxLP/TRnEWbemCfEDKL8iXs9W3n6qiCHLFowyQizcFUy4F cKFwB1InOY9ABVGQIuQaMy7XZ8vzlitCCGfQelA1CZSwCGjBCdLDCdFVCX2ABrNhCPmqaVBzqf0q Oa55SwxQgscVTzfYAah5KjbAAXpbgk3AAFBRS3HGkaOgLgeYmnlVhcfWAVi3KoEzS1mgELTQCEwg COEqNdv6sckFKr3JTJfgGpDBOZHKq5qgCc7VB0nQl0mgBElgBmiwBmmqJWwKClFzKh/AAZSnBR6Q eC5jB7XZUrQ1mpQnB707jaFQRiTAdcH4cqPZh4eQV4gwXMUlC2TAL3sAAVdgCrTAU1OrVNX/q6oH ZTboOhCocAZnUGBgawmTgGR9YAZJsALyOwH0qwIEMAErwAIssATTYSWdcrvOdys0JqO9QgUy1os2 EAodEEvxhY0H+An45AFxEE/JN7hyJQdYcEs3KHMD1Ct7oBCMAAEQsAOfogVQsAkAW3rGVHqd+7kA IAuCYAZ94L6tkQRIML8SkMMToAI8nL9J8Lpn0HSSQUKgYgf1JIOUVzmjmYAdMJB5pbcL7IEeOAUu ZVe58jJJYgPcEgeuYFsCBDKnYgcMEcIQIMaugAVmsAksE74EREDXVr4D4Qp9UAZ0bMMsoAITkMM6 rALyuwJIUAZpcJKEALaaYAggWgmg4AoH/2gDM2ZT0IfA/OKeMXWUsgIKHlBP21dPdlBYsvVS7TKa PxQLj6AId+oGkVAL2YuV3pu5LMy5+WIqLsxMmPDD+qsCeiwB9Su/fVkG7Dq6vJoWf8AWqQTK1vea krNebXArbmCgB5h4+miIe1WZt9SHqHKAeuCpuoSHrjmbbYQqj2AHsOhm1EMGTJAINbvGxpXOpvcK cGy+ZbAEN3zLfCy/SOCXrXdIlLhAKHEJa/FWNCpXh0ACevtycbXJssAGzIeGuLRmhVgLvER5o0lb sMmRXHent3Sx9fQJKJaFklMI47QKnbAHdRAFf/AU6azCnDtknpsRsKAGZgDPSKC/LIAE9f+8BDLs XHQnPVthFMEKJ6tgbAx7S3GQi4V1CAl8K44HlaO5wMemxafilNSXPEQNxlYYuLglh2GpK4jQBgLZ BlVi0h9jtVhbOevcznvyGq3x0jZtBl3rtZQoLH7yqwCiaaDwKcqkOKmSVIUFMgb1R8vKpyvXPKU2 NZOzCpvACUWRIKmKKpvbsf8FC7HMoOib1q7Res4VnTqtEvwMCO2DFD9tLjaL0mxMb+mMpOhSrntN rqaKVCzTcugivuqcqmhDLu3sVK/h0mcgl5ABtjBiCl1hCpcACJxdCZxQ16Kiwle7wqytcqSKZ31E 2sezQ6iWqjkEvh9rTMptTFir0i68Nt//KHcoCba8ukB64SebnSUkdLvX/UOuDUA223LMjaorB77I FWQr/NySs7nKjdJ9RkAdqy+13ZyTkGScw6tbMRYqgQnAyilKod6uTN0nDT9WGwuqiqo8VN2lvakV Lr77HdiO/eCs1t2B0Vz53AmnICwtwQmGYAiEoK9QY9frDeGiHeOjfbXoXOMnR3pizdqxbayqOtaM ZdYG8TQA4ycHNqkM/uIJBdsdXr03HuFsh9rLnSpRPuHItcYszKqtXXqau90rnRHOoxLhgQoueyWX UNyf4cqunKzrjeFIKnozTno2C+cbPm3Oqiv73cptDOTFCuAbcQlo4wqrEAqbwKbD+gqf/9HK6tzh iw2wKVznPB6+6LzYYt3ora3cHzvW1vaqGXEJyoQqnxEKQ2Yu7O3Y/p3hYS3jpC2ueY3dqy7lrp7d J+2vpe7jQG4qZj0Qng4ygTTqte7jjt2xYr3fww7bk46qqf7gs97o/d3sLoO1FL7pX97pd61UUers wA4LWs7kMc65jY3qdP7sdy7dem7smc7lwd52spDrAnEJB8UuAQey767p2I7n5O7hJ52sjc7os/7t zX7vB0XWAc8rsUwRlSDYAedD6F7q0d7jy37u3P7gjf3tKL3wpw7ke/7hLPwKnuARlYAImRDy3nol lXAIeGLmX+IJeGInnpDyK5/ymYAnMimf8mBS8zSv8i6P8zbP8jM/8/wR8zm/8zrvCUAv9D2P80CP J/1h8gIREAA7 ------=_NextPart_000_0098_01C29330.B7655560 Content-Type: image/jpeg; name="clip_image015.jpg" Content-Transfer-Encoding: base64 Content-ID: <009701c29363$018405b0$66902244@ROSS> /9j/4AAQSkZJRgABAQEAYABgAAD//gAcU29mdHdhcmU6IE1pY3Jvc29mdCBPZmZpY2X/2wBDAAgG BgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgy PC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjL/wAARCAB4AGQDASIAAhEBAxEB/8QAGwAAAgMBAQEAAAAAAAAAAAAA BAUAAgMGAQf/xAA2EAABBAIABAMFBgUFAAAAAAABAAIDEQQhBRIxQRMiUQYUcYGxMkJhcpGhI1Ji wfAVJJLR4f/EABsBAAIDAQEBAAAAAAAAAAAAAAIDAQQFAAYH/8QAKREAAgIBAwMDBAMBAAAAAAAA AAECAxEEEiETMVEFQZEGIjJhgaGx0f/dAAQAKP/aAAwDAQACEQMRAD8A+QRM8Voe7zOJokolsDR2 VsRl47fxCJZCdL6nnBmTmYthH8q0EF/dRjITa3ZjkqNxWnMXjGB+6tRja+ymQxza1EGti1G8X1BU 3FB6hQ4wb0Ca+B/Svfd96CjeDv5Ez4DymhR6XVrpPZLO9m+GOyRx3hZzQ4s5CG34fLeh6g90C+Ag rF8B5a9P2QXQjdBwk2s+HgZC1xeR3lZfsNLlTTf6RkNZIAWNYXNEZo+jgDutAA/isRk+wUb4nDhu e/lYedskjiC//l/nSkhlhOyd1ve9oZ0Xm+CQtFHGN8vljo3sM4zNw7N4pLPgcPdiYrg3w4oi7+UW Tvrd/KlEMxh5VFYjRCKS5+Wd1WZYUf8Atma7I6KLppY4EZ93jsdkzgh6WFzkKslyeRwfgETHBZql vFASaARkWMRXl2lSngQ2DMxTrS3GKO+kfHjmhpEtxvUJUrQcZFJxB2VHYutC06OMPRUOMa6WoVp2 1iN+MfRDyQiqIT2TG9QhJccCyBtMjNMgQywjfVCPjANUnMsbgTaBliNk0rEZBxkBNZ5VES2I8vRR HkPJ5w6InGj191NIIjQNIThzR7tH8E6xowaCqzZ0+5pBALBpMYoLI0qwMTOGLoKVSyeAFHJnFjih 2RAxgAioYdjWkayAC9bI0qNl+B8IZFRxvLZGu3qqPxgCRVH07hBcb4lLi4UsschaDIWx0NkBC8A4 zkZEcMOU0zPkDn+INFrQS3fzB+SwavqKiU5bsqMXjPsbmp9Auo00dRKSw3jHOQ2WA+iDlh0dJtkS Nbmtxg0uLhzWOgQ00YNg+vVb2j1teogp1vMfJgWVuLwznsiCiSAl8sRF62n07ALCUzjzH8Fr1yEd gFrDyqIpjRyqJu4LINw3cEY/pTvFboFI+HGoY/yp9jOAY3SVYFL8hpjs8tlNIGjQHVK4CKvr0NLp oOHtJjAkcXOj8ShHdN/wH9Flai1Q7ja45LwR9BW1tlyNw8GWYtBDWkNBNEk6H1CLhw4mRtmdO7wy Cebwisc3CGdC3HErmDxA7Tb5gO30WXKyMnz2LEY47nzj2yyouGxYuLHjjIlfQMRcduPwTfg3BJG5 M2RjRmWGINhY3mot5QG/Pdpjxr2IZmcSxs45j35OI/n8KQDke4bq+3b1THhbm8K4W2KWN7pW0CGs +0aXmfqTCprq0dO7P5YT/jseg01sbqZK6b4fZv8AvkVsxZRxHJmnpr2/wg0G6rZ/ssp2UNdv3RrX txsZpyDySyOc5xdRt5vX6BAOyoZ+YRPa8gAuDTdL0/pUFRp4VPCaS4/fuYOprlKUpxT2+RZkjZSj Jb5inOSRZSnJOyvSVGZLgDbpqigIAUVg7IHw8jwIz/SnmMfKFz+A4eAz8qcYz9D9EM1wMl3HmM4c oXccJ4zjwcOxpJHNOQx/uzmXsxOcCT8tr5/jvoAXtdDg8TGPjCHww9ji4va4kg+mrr17LG19HUil jPI6mzaztcfMwDLLC6VjoYS2KIO3dDaviZcDhHI33ZmQ5jC5vQVzHm+dUuai4pj+F4YhaGuLuccg AI7D5fJFs4hh0LhIFAFjWACvQHqFiy0sl7Mt9U6GbNwxzyNfjvjHM57SbLnfdIWE2Tw5otngue06 a9w5TzG9/DaTHiWNoeFoEHmDAKHYf51QGbmsnc3kaQKIJIAGyey6vSNvHJDt4Le1cGLm+AyOWqt/ K2iWuHTYXL42GcRp5nhzuUNFCgG7NfVMZXne/wCwQE0lA7WpRo4xak+69wZ62zpupP7X7AmS/wAx SnIddlHZLxTt7Smd/ZblceDNfJUXSizD9KJ+CcC3Af8AwI/yptBLygbSLAf/AAI79ExikNrpIdNc j+CcHl3tMIpjoWucinLa2j4skULO1WnWK7HQxTkVtEDIOtpEzJ7ArcZOtm1WlSMUhx7zbT5lm6c7 8yWDJHqs3ZIKhUnOYbJP13aBmlJullJkAC72g5ck7op8K8CnLJ//0FORKSSAdpbM87s7VpZTZJOk FLKC7S+lwieaUTVr/KohmvPL1UTdoWBdgyn3eM3qq+aNjlB6Hog+DY7MmJ5k8Y8oaQ5jA6ifimgw sdrZLGbzRGnGgKB+Xf8AZLlZFPBdlVnsesnHY3e/kt2TgDVqjMKIOiAZltjIIeKBIK0djY8EQdlO y2G6aQ1tfRA7It4EOthDMsAizV9LRDcsAH4pc2XhlygTT0Ggs+yCT35tLZs3DHRNPjZQdXmBILQf wQ5Xh/Ap1vyG++Nq+yq7LHTY/BCsfw4uF5crATXMGWh8mbFawHHkkLuYhzXNqum1Kw3jD+COmwt+ TfrSHdPZO6QZnBvzLF84vrd6TlBHKIRLPui4X6IOSXZ3ruVucDPkj548aVzD0cBaxHDOIyE8mHLb dkkAEIlKC9xka2zISaUWZY+IlkrXteOotRHlB9N+B9gexhlj5GcTMYIBLnDlb9fj+60y/Zg48L3n irnAXVbLq9NqKL5RD6h9RlJJ2e/hf8Ltv2vj9f4cwZSDp8+tDzf+rx+Q5zC2R8xbdkF1i/1UUX1J dkSoJ9yDJAO+a/y0r+9AdA76KKIyHTDwQZf5vqre9XrzfooouQPRh4J49/zfooSHDfN8K6qKKQOn HJ748oAb4+QGj7LWv0P3VSZeYn3mcE65gevx2ooowglFFhjMlHO90jnHvr/tRRRDuZOD/9k= ------=_NextPart_000_0098_01C29330.B7655560-- From srompf@isg.de Sun Nov 24 05:09:50 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Nov 2002 05:09:53 -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 gAOD9muR016048 for ; Sun, 24 Nov 2002 05:09:49 -0800 Received: from isg.de (dialin-145-254-193-136.arcor-ip.net [145.254.193.136]) by mail.isg.de (Postfix) with ESMTP id 96D84E7AC0C; Sun, 24 Nov 2002 14:12:03 +0100 (CET) Message-ID: <3DE0CA4C.730699FC@isg.de> Date: Sun, 24 Nov 2002 13:47:08 +0100 From: Stefan Rompf X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.20-rc2-lw-apic i686) X-Accept-Language: en MIME-Version: 1.0 To: jgarzik@pobox.com Cc: netdev@oss.sgi.com Subject: Re: Patch: link state detection for 8139too against 2.4.20rc2 / 2.5 References: <3DA96BCC.B2589AC0@isg.de> Content-Type: multipart/mixed; boundary="------------E38573049F6802A399D73CEF" X-archive-position: 1231 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 This is a multi-part message in MIME format. --------------E38573049F6802A399D73CEF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, > > Uhmmm, you don't need to poll with the rtl8139. There is a link change > > interrupt. Here is the recently added from rtl8139.c > > ok, I'll try this next time I have access to the card. ...that was some days ago. I've seen that Jeff is enhancing the MII interface library, so I used the functions provided there. Patch is against 2.4.20rc2 and 2.5 with some offset. Please apply if it looks good. Cheers, Stefan --------------E38573049F6802A399D73CEF Content-Type: text/plain; charset=us-ascii; name="patch-ls-8139too" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-ls-8139too" --- linux/drivers/net/8139too.c.old 2002-11-19 00:32:04.000000000 +0100 +++ linux/drivers/net/8139too.c 2002-11-21 22:32:39.000000000 +0100 @@ -1335,18 +1335,7 @@ struct rtl8139_private *tp = dev->priv; if (tp->phys[0] >= 0) { - u16 mii_lpa = mdio_read(dev, tp->phys[0], MII_LPA); - if (mii_lpa == 0xffff) - ; /* Not there */ - else if ((mii_lpa & LPA_100FULL) == LPA_100FULL - || (mii_lpa & 0x00C0) == LPA_10FULL) - tp->mii.full_duplex = 1; - - printk (KERN_INFO"%s: Setting %s%s-duplex based on" - " auto-negotiated partner ability %4.4x.\n", - dev->name, mii_lpa == 0 ? "" : - (mii_lpa & 0x0180) ? "100mbps " : "10mbps ", - tp->mii.full_duplex ? "full" : "half", mii_lpa); + mii_check_media(&tp->mii, 1, 1); } } @@ -1994,18 +1983,7 @@ if ((status & RxUnderrun) && link_changed && (tp->drv_flags & HAS_LNK_CHNG)) { - /* Really link-change on new chips. */ - int lpar = RTL_R16 (NWayLPAR); - int duplex = (lpar & LPA_100FULL) || (lpar & 0x01C0) == 0x0040 - || tp->mii.force_media; - if (tp->mii.full_duplex != duplex) { - tp->mii.full_duplex = duplex; -#if 0 - RTL_W8 (Cfg9346, Cfg9346_Unlock); - RTL_W8 (Config1, tp->mii.full_duplex ? 0x60 : 0x20); - RTL_W8 (Cfg9346, Cfg9346_Lock); -#endif - } + rtl_check_media(dev); status &= ~RxUnderrun; } --------------E38573049F6802A399D73CEF-- From gavekort@mobil-varehuset.com Sun Nov 24 12:23:04 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Nov 2002 12:23:08 -0800 (PST) Received: from oss.sgi.com (4o9qpe.cm.chello.no [62.179.188.60]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAOKN3uR019556 for ; Sun, 24 Nov 2002 12:23:03 -0800 Message-Id: <200211242023.gAOKN3uR019556@oss.sgi.com> From: "gavekort@mobil-varehuset.com" Date: sø, 24 nov 2002 21:23:35 To: netdev@oss.sgi.com Subject: Gratulerer med gavekort MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-archive-position: 1232 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gavekort@mobil-varehuset.com Precedence: bulk X-list: netdev Hei Lisa Knudsen lisa_kn@hotmail.com vil gjerne tipse deg om Mobilvarehuset.no, http://www.mobilvarehuset.no Varehuset med mobilpriser for folk i farten! Registrer deg som medlem idag og motta et gavekort på opp til kr. 350,- Ukens supertilbud for våre medlemmer er: Nokia 7650 for kun kr 2490,-. SONY ERICSSON T68i for kun kr. 2990,- Nokia 7210 for kun kr. 2690,- MOTOROLA T720 for kun kr. 1990,- Siemens C55 for kun kr. 890,- Nokia 3510 for kun kr. 790,- Nokia 3410 for kun Kr. 390,- Registrer deg på www.mobilvarehuset.no med en gang! Lisa From gavekort@mobil-varehuset.com Sun Nov 24 17:00:39 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Nov 2002 17:00:48 -0800 (PST) Received: from oss.sgi.com (4o9qpe.cm.chello.no [62.179.188.60]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAP10buR022964 for ; Sun, 24 Nov 2002 17:00:38 -0800 Message-Id: <200211250100.gAP10buR022964@oss.sgi.com> From: "gavekort@mobil-varehuset.com" Date: ma, 25 nov 2002 02:01:10 To: netdev@oss.sgi.com Subject: Gratulerer med gavekort MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-archive-position: 1233 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gavekort@mobil-varehuset.com Precedence: bulk X-list: netdev Hei Lisa Knudsen lisa_kn@hotmail.com vil gjerne tipse deg om Mobilvarehuset.no, http://www.mobilvarehuset.no Varehuset med mobilpriser for folk i farten! Registrer deg som medlem idag og motta et gavekort på opp til kr. 350,- Ukens supertilbud for våre medlemmer er: Nokia 7650 for kun kr 2490,-. SONY ERICSSON T68i for kun kr. 2990,- Nokia 7210 for kun kr. 2690,- MOTOROLA T720 for kun kr. 1990,- Siemens C55 for kun kr. 890,- Nokia 3510 for kun kr. 790,- Nokia 3410 for kun Kr. 390,- Registrer deg på www.mobilvarehuset.no med en gang! Lisa From jgarzik@pobox.com Sun Nov 24 22:32:35 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Nov 2002 22:32:38 -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 gAP6WYuR027901 for ; Sun, 24 Nov 2002 22:32:34 -0800 Received: from rdu74-162-040.nc.rr.com ([24.74.162.40] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 18GCph-0006cm-00; Mon, 25 Nov 2002 06:35:01 +0000 Message-ID: <3DE1C468.1060806@pobox.com> Date: Mon, 25 Nov 2002 01:34:16 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021018 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: "David S. Miller" Subject: [PATCH] tg3 shutdown sequence update Content-Type: multipart/mixed; boundary="------------040304080808010802090102" X-archive-position: 1234 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 This is a multi-part message in MIME format. --------------040304080808010802090102 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This patch is only for testing and comment, _not_ for applying. (testers requested) The attached patch updates the tg3 net driver shutdown sequence to be a bit more correct WRT the documented sequence. Detailed changes: * bail out of tg3_stop_block ASAP if block is already disabled * use standard tg3_stop_block to disable RX MAC mode. this adds polling of the the enable bit to the standard code. * just in case, shut down DMA completion between send data completion shutdown and send DB completion shutdown * use standard tg3_stop_block to disable TX MAC mode. * don't bother to disable MAC_MODE_TDE_ENABLE bit manually, TX MAC mode disable does it for us. * add PCI posting flush for flow-through queues Does this look ok WRT errata and hardware seen in the field? One potential concern is that the error handling if tg3_stop_block fails runs through all the blocks unconditionally, and then returns an error. It does not bail early if some of the stop-block calls fail. Comments? Jeff --------------040304080808010802090102 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" --- drivers/net/tg3.c.~1~ Tue Nov 19 15:30:41 2002 +++ drivers/net/tg3.c Tue Nov 19 15:31:34 2002 @@ -2367,6 +2367,7 @@ unsigned int i; u32 len, entry, base_flags, mss; int would_hit_hwbug; + unsigned long flags; len = (skb->len - skb->data_len); @@ -2389,12 +2390,12 @@ * So we really do need to disable interrupts when taking * tx_lock here. */ - spin_lock_irq(&tp->tx_lock); + spin_lock_irqsave(&tp->tx_lock, flags); /* This is a hard error, log it. */ if (unlikely(TX_BUFFS_AVAIL(tp) <= (skb_shinfo(skb)->nr_frags + 1))) { netif_stop_queue(dev); - spin_unlock_irq(&tp->tx_lock); + spin_unlock_irqrestore(&tp->tx_lock, flags); printk(KERN_ERR PFX "%s: BUG! Tx Ring full when queue awake!\n", dev->name); return 1; @@ -2535,7 +2536,7 @@ netif_stop_queue(dev); out_unlock: - spin_unlock_irq(&tp->tx_lock); + spin_unlock_irqrestore(&tp->tx_lock, flags); dev->trans_start = jiffies; @@ -2547,6 +2548,7 @@ struct tg3 *tp = dev->priv; dma_addr_t mapping; u32 len, entry, base_flags, mss; + unsigned long flags; len = (skb->len - skb->data_len); @@ -2569,12 +2571,12 @@ * So we really do need to disable interrupts when taking * tx_lock here. */ - spin_lock_irq(&tp->tx_lock); + spin_lock_irqsave(&tp->tx_lock, flags); /* This is a hard error, log it. */ if (unlikely(TX_BUFFS_AVAIL(tp) <= (skb_shinfo(skb)->nr_frags + 1))) { netif_stop_queue(dev); - spin_unlock_irq(&tp->tx_lock); + spin_unlock_irqrestore(&tp->tx_lock, flags); printk(KERN_ERR PFX "%s: BUG! Tx Ring full when queue awake!\n", dev->name); return 1; @@ -2665,7 +2667,7 @@ if (TX_BUFFS_AVAIL(tp) <= (MAX_SKB_FRAGS + 1)) netif_stop_queue(dev); - spin_unlock_irq(&tp->tx_lock); + spin_unlock_irqrestore(&tp->tx_lock, flags); dev->trans_start = jiffies; --------------040304080808010802090102-- From davem@redhat.com Sun Nov 24 22:37:25 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Nov 2002 22:37: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 gAP6bPuR028287 for ; Sun, 24 Nov 2002 22:37:25 -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 WAA19937; Sun, 24 Nov 2002 22:38:50 -0800 Date: Sun, 24 Nov 2002 22:38:50 -0800 (PST) Message-Id: <20021124.223850.79068557.davem@redhat.com> To: jgarzik@pobox.com Cc: netdev@oss.sgi.com Subject: Re: [PATCH] tg3 shutdown sequence update From: "David S. Miller" In-Reply-To: <3DE1C468.1060806@pobox.com> References: <3DE1C468.1060806@pobox.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: 1235 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 Jeff you're posting the "spin_lock_irqsave(tx_lock)" patch not the one you intended... From jgarzik@pobox.com Sun Nov 24 22:39:14 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Nov 2002 22:39:15 -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 gAP6dDuR028656 for ; Sun, 24 Nov 2002 22:39:13 -0800 Received: from rdu74-162-040.nc.rr.com ([24.74.162.40] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 18GCw9-0006ey-00; Mon, 25 Nov 2002 06:41:41 +0000 Message-ID: <3DE1C5F9.70907@pobox.com> Date: Mon, 25 Nov 2002 01:40:57 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021018 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: "David S. Miller" Subject: Re: [PATCH] tg3 shutdown sequence update References: <3DE1C468.1060806@pobox.com> In-Reply-To: <3DE1C468.1060806@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1236 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 Doh! Wrong patch posted... sorry folks... From cmail9999jp@yahoo.co.jp Mon Nov 25 22:33:48 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Nov 2002 22:33:52 -0800 (PST) Received: from bob.no (fb173248.ot.FreeBit.NE.JP [61.203.173.248]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAQ6XSuR018548 for ; Mon, 25 Nov 2002 22:33:41 -0800 Received: from C ([192.168.0.2]) by bob (8.9.3+3.2W/3.7W) with SMTP id PAA13407; Tue, 26 Nov 2002 15:37:09 +0900 Message-Id: <200211260637.PAA13407@bob> From: =?iso-2022-jp?B?Y21haWw5OTk5?= To: =?iso-2022-jp?B?YzAz?=@bob.sgi.com Reply-To: cmail9999jp@yahoo.co.jp Date: Tue, 26 Nov 2002 15:35:01 +0900 Subject: =?iso-2022-jp?B?GyRCTCQ+NUJ6OS05cCIoRUU7UiVhITwlazktOXAbKEo=?= Content-Type: text/plain Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-archive-position: 1237 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cmail9999jp@yahoo.co.jp Precedence: bulk X-list: netdev <‘—MŽÒ> “dŽqƒ[ƒ‹LŽÐ ¡ŒãAL‚ð‚²Šó–]‚µ‚È‚¢•û‚Í‚±‚±‚Ö (•K‚¸–{•¶‚É‚ ‚È‚½‚̃[ƒ‹ƒAƒhƒŒƒX‚Ì‚Ý‚ð‚¨‘‚«‰º‚³‚¢j me463886@members.interq.or.jp ƒ[ƒ‹ƒAƒhƒŒƒX‚ð‚²‹L“ü‚µ‚Ä‚­‚¾‚³‚¢B §104-0061 “Œ‹ž“s’†‰›‹æ‹âÀ8-19-3 ‘æ2ƒEƒCƒ“ƒOƒrƒ‹@3F ƒ[ƒ‹ƒ}ƒKƒWƒ“”­s TEL@03-3544-6222 FAX@03-3544-6218 =============================================================== –â‘褕i‚΂©‚èW‚ß‚Ü‚µ‚½‚Ì‚ÅAÁ‚³‚ê‚é‹°‚ꂪ‚ ‚è‚Ü‚·‚Ì‚Å ‚¨\ž‚Ý‚Í‚¨‘‚ß‚ÉI ================================================================= ™\\\™\\\™\\\™\\\™\\\™\\\™\\\™\\\™ — ƒrƒfƒI”Ì”„EƒƒŠƒrƒfƒIE“ÁŽêƒ_ƒbƒ`ƒƒCƒtE‚r‚lƒNƒ‰ƒu @@ ‚`‚u’j—D•åWE‰‡•ŒðÛE‚r‚d‚wƒtƒŒƒ“ƒhEƒAƒ_ƒ‹ƒgƒOƒbƒY‚È‚Ç š@ƒAƒ_ƒ‹ƒgŠÖ˜A‚Ìî•ñ–žÚ@š @@‚¨\ž‚ÝE‚²’•¶E¤•iÚד™‚Í@ @@@@@‰º‹L‚t‚q‚k‚ðƒNƒŠƒbƒN‚µ‚Ä‚²——‰º‚³‚¢B «@@@@«@@@@«@ @@@http://changeboy.kir.jp/ ™\\\™\\\™\\\™\\\™\\\™\\\™\\\™\\\™ @@@@@@@@ŠJ‰^ƒOƒbƒYE‹É”éî•ñŽ @@@@–h”ƃOƒbƒYE‹à–ׂ¯î•ñEƒ_ƒCƒGƒbƒgH•i‚È‚Ç@ @@@@@@@@š@‚»‚Ì‘¼î•ñ–žÚ@š @@‚¨\ž‚ÝE‚²’•¶E¤•iÚד™‚Í@ @@@@@‰º‹L‚t‚q‚k‚ðƒNƒŠƒbƒN‚µ‚Ä‚²——‰º‚³‚¢B «@@@@«@@@@«@ http://changeboy.kir.jp/index2.html ™\\\™\\\™\\\™\\\™\\\™\\\™\\\™\\\™ From zjp@iscas.ac.cn Tue Nov 26 00:23:41 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Nov 2002 00:23:45 -0800 (PST) Received: from mail.iscas.ac.cn ([159.226.5.56]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAQ8NcuR021906 for ; Tue, 26 Nov 2002 00:23:40 -0800 Received: (qmail 12880 invoked by uid 104); 26 Nov 2002 08:26:13 -0000 Received: from zjp@iscas.ac.cn by mail.iscas.ac.cn by uid 0 with qmail-scanner-1.14 (hbedv: 6.15.0.1. hbedv: operating system: Linux (glibc). hbedv: product version: 2.0.4. hbedv: engine version: 6.15.0.1. hbedv: packlib version: 2.0.0.8 (supports 19 formats). hbedv: vdf version: 6.15.0.7 (66928 recognized forms). hbedv: . hbedv: product: AntiVir Workstation. hbedv: key file: hbedv.key. hbedv: registered user: irene, 123. hbedv: serial number: 1001020203. hbedv: key expires: 31 May 2003. hbedv: run mode: PRIVATE. hbedv: . hbedv: product: AntiVir MailGate. hbedv: key file: hbedv.key. hbedv: registered user: irene, 123. hbedv: serial number: 1001020203. hbedv: key expires: 31 May 2003. hbedv: run mode: PRIVATE. hbedv: . hbedv: product: AntiVir (command line scanner). hbedv: key file: hbedv.key. hbedv: registered user: irene, 123. hbedv: serial number: 1001020203. hbedv: key expires: 31 May 2003. hbedv: run mode: PRIVATE. Clear:. Processed in 0.215566 secs); 26 Nov 2002 08:26:13 -0000 Received: from unknown (HELO zhengjp) (zjp@192.168.6.108) by mail.iscas.ac.cn with SMTP; 26 Nov 2002 08:26:13 -0000 Message-ID: <003201c29525$cd933360$6c06a8c0@zhengjp> From: "Zheng Jianping" To: Subject: How to get IPv6 interface? Date: Tue, 26 Nov 2002 16:28:31 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 199 X-archive-position: 1238 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zjp@iscas.ac.cn Precedence: bulk X-list: netdev Hi, My linux kernel is 2.4.7.10, how to get the information of all IPv6 interfaces, including the interfaces index, flags,name and address,etc ? Thanks, Zheng [[HTML alternate version deleted]] From srompf@isg.de Tue Nov 26 01:20:27 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Nov 2002 01:20:34 -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 gAQ9KQuR022703 for ; Tue, 26 Nov 2002 01:20:26 -0800 Received: from barkeeper.isg.de (barkeeper.is-asp.com [192.168.5.46]) by mail.isg.de (Postfix) with ESMTP id 30A81E821EE; Tue, 26 Nov 2002 10:22:54 +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 KAA00945; Tue, 26 Nov 2002 10:22:54 +0100 Message-ID: <3DE33D6D.25B9C9B4@isg.de> Date: Tue, 26 Nov 2002 10:22:53 +0100 From: Stefan Rompf X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.20rc1-sr i686) X-Accept-Language: en MIME-Version: 1.0 To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: Patch resubmission: RFC2863 operstatus for 2.5.49 Content-Type: multipart/mixed; boundary="------------BF3F091FE7191BF1D86D3A26" X-archive-position: 1239 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 This is a multi-part message in MIME format. --------------BF3F091FE7191BF1D86D3A26 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi David, I've updated my RFC2863 operstatus and userspace forwarding patch to 2.5.49. As discussion on netdev seems to be complete, I need some comment from your side. Stefan --------------BF3F091FE7191BF1D86D3A26 Content-Type: text/plain; charset=us-ascii; name="patch-rfc2863-2.5.49" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-rfc2863-2.5.49" diff -uprNX dontdiff linux-2.5.49/include/linux/netdevice.h linux-2.5.49-lw/include/linux/netdevice.h --- linux-2.5.49/include/linux/netdevice.h 2002-11-22 22:41:08.000000000 +0100 +++ linux-2.5.49-lw/include/linux/netdevice.h 2002-11-25 22:52:29.000000000 +0100 @@ -204,10 +204,23 @@ enum netdev_state_t { __LINK_STATE_XOFF=0, __LINK_STATE_START, - __LINK_STATE_PRESENT, + __LINK_STATE_PRESENT_OBSOLETE, __LINK_STATE_SCHED, - __LINK_STATE_NOCARRIER, - __LINK_STATE_RX_SCHED + __LINK_STATE_NOCARRIER_OBSOLETE, + __LINK_STATE_RX_SCHED, + __LINK_STATE_LINKWATCH_PENDING +}; + + +/* Device operative state as per RFC2863 */ +enum netdev_operstate_t { + NETDEV_OPER_UP = 1, + NETDEV_OPER_DOWN, /* Obsoletes LINK_STATE_NOCARRIER */ + NETDEV_OPER_TESTING, + NETDEV_OPER_UNKNOWN, + NETDEV_OPER_DORMANT, + NETDEV_OPER_NOTPRESENT, /* Obsoletes !LINK_STATE_PRESENT */ + NETDEV_OPER_LOWERDOWN }; @@ -308,6 +321,10 @@ struct net_device * which this device is member of. */ + /* Operative state, access semaphore */ + rwlock_t operstate_lock; + unsigned char operstate; + /* Interface address info. */ unsigned char broadcast[MAX_ADDR_LEN]; /* hw bcast add */ unsigned char dev_addr[MAX_ADDR_LEN]; /* hw address */ @@ -631,34 +648,76 @@ static inline void dev_put(struct net_de * who is responsible for serialization of these calls. */ +#ifdef CONFIG_LINKWATCH +extern void linkwatch_fire_event(struct net_device *dev); +#endif + +static inline unsigned char netif_set_operstate(struct net_device *dev, unsigned char newstate) +{ + unsigned long flags; + unsigned char oldstate; + + write_lock_irqsave(&dev->operstate_lock, flags); + oldstate = dev->operstate; + dev->operstate = newstate; + write_unlock_irqrestore(&dev->operstate_lock, flags); + +#ifdef CONFIG_LINKWATCH + if (oldstate != newstate) linkwatch_fire_event(dev); +#endif + + return oldstate; +} + +static inline unsigned char netif_get_operstate(struct net_device *dev) +{ + unsigned long flags; + unsigned char state; + + read_lock_irqsave(&dev->operstate_lock, flags); + state = dev->operstate; + read_unlock_irqrestore(&dev->operstate_lock, flags); + + return state; +} + static inline int netif_carrier_ok(struct net_device *dev) { - return !test_bit(__LINK_STATE_NOCARRIER, &dev->state); + return netif_get_operstate(dev) != NETDEV_OPER_UP; +} + +static inline int netif_operstate_to_iff_running(struct net_device *dev) +{ + unsigned char state = netif_get_operstate(dev); + + return((1 << state) & + (1 << NETDEV_OPER_UP | 1 << NETDEV_OPER_UNKNOWN)); } extern void __netdev_watchdog_up(struct net_device *dev); + static inline void netif_carrier_on(struct net_device *dev) { - clear_bit(__LINK_STATE_NOCARRIER, &dev->state); + netif_set_operstate(dev, NETDEV_OPER_UP); if (netif_running(dev)) __netdev_watchdog_up(dev); } static inline void netif_carrier_off(struct net_device *dev) { - set_bit(__LINK_STATE_NOCARRIER, &dev->state); + netif_set_operstate(dev, NETDEV_OPER_DOWN); } /* Hot-plugging. */ static inline int netif_device_present(struct net_device *dev) { - return test_bit(__LINK_STATE_PRESENT, &dev->state); + return netif_get_operstate(dev) != NETDEV_OPER_NOTPRESENT; } static inline void netif_device_detach(struct net_device *dev) { - if (test_and_clear_bit(__LINK_STATE_PRESENT, &dev->state) && + if (netif_set_operstate(dev, NETDEV_OPER_NOTPRESENT) != NETDEV_OPER_NOTPRESENT && netif_running(dev)) { netif_stop_queue(dev); } @@ -666,7 +725,7 @@ static inline void netif_device_detach(s static inline void netif_device_attach(struct net_device *dev) { - if (!test_and_set_bit(__LINK_STATE_PRESENT, &dev->state) && + if (netif_set_operstate(dev, NETDEV_OPER_UNKNOWN) == NETDEV_OPER_NOTPRESENT && netif_running(dev)) { netif_wake_queue(dev); __netdev_watchdog_up(dev); diff -uprNX dontdiff linux-2.5.49/net/Kconfig linux-2.5.49-lw/net/Kconfig --- linux-2.5.49/net/Kconfig 2002-11-22 22:40:16.000000000 +0100 +++ linux-2.5.49-lw/net/Kconfig 2002-11-25 22:58:39.000000000 +0100 @@ -265,6 +265,20 @@ config ATM_MPOA config VLAN_8021Q tristate "802.1Q VLAN Support" +config LINKWATCH + bool "Device link state notification (EXPERIMENTAL)" + depends on EXPERIMENTAL + help + When this option is enabled, the kernel will forward changes in the + operative ("RUNNING") state of an interface via the netlink socket. + This is most useful when running linux as a router. + + Note that currently not many drivers support this, compliant ones + can be found by watching the the RUNNING flag in ifconfig output + that should follow operative state. + + If unsure, say 'N'. + config LLC tristate "ANSI/IEEE 802.2 - aka LLC (IPX, Appletalk, Token Ring)" help diff -uprNX dontdiff linux-2.5.49/net/core/Makefile linux-2.5.49-lw/net/core/Makefile --- linux-2.5.49/net/core/Makefile 2002-11-22 22:41:08.000000000 +0100 +++ linux-2.5.49-lw/net/core/Makefile 2002-11-25 22:52:33.000000000 +0100 @@ -22,4 +22,6 @@ obj-$(CONFIG_NET_RADIO) += wireless.o # Ugly. I wish all wireless drivers were moved in drivers/net/wireless obj-$(CONFIG_NET_PCMCIA_RADIO) += wireless.o +obj-$(CONFIG_LINKWATCH) += link_watch.o + include $(TOPDIR)/Rules.make diff -uprNX dontdiff linux-2.5.49/net/core/dev.c linux-2.5.49-lw/net/core/dev.c --- linux-2.5.49/net/core/dev.c 2002-11-22 22:40:43.000000000 +0100 +++ linux-2.5.49-lw/net/core/dev.c 2002-11-25 22:52:33.000000000 +0100 @@ -199,7 +199,6 @@ int netdev_fastroute; int netdev_fastroute_obstacles; #endif - /******************************************************************************* Protocol management and registration routines @@ -262,6 +261,9 @@ void dev_add_pack(struct packet_type *pt br_write_unlock_bh(BR_NETPROTO_LOCK); } +#ifdef CONFIG_LINKWATCH +void linkwatch_run_queue(void); +#endif /** * dev_remove_pack - remove packet handler @@ -2018,7 +2020,7 @@ static int dev_ifsioc(struct ifreq *ifr, IFF_RUNNING)) | (dev->gflags & (IFF_PROMISC | IFF_ALLMULTI)); - if (netif_running(dev) && netif_carrier_ok(dev)) + if (netif_running(dev) && netif_operstate_to_iff_running(dev)) ifr->ifr_flags |= IFF_RUNNING; return 0; @@ -2433,6 +2435,10 @@ int register_netdevice(struct net_device goto out; #endif /* CONFIG_NET_DIVERT */ + /* Initial operstate */ + dev->operstate_lock = RW_LOCK_UNLOCKED; + dev->operstate = NETDEV_OPER_UNKNOWN; + dev->iflink = -1; /* Init, if this function is available */ @@ -2458,13 +2464,6 @@ int register_netdevice(struct net_device if (!dev->rebuild_header) dev->rebuild_header = default_rebuild_header; - /* - * Default initial state at registry is that the - * device is present. - */ - - set_bit(__LINK_STATE_PRESENT, &dev->state); - dev->next = NULL; dev_init_scheduler(dev); write_lock_bh(&dev_base_lock); @@ -2642,6 +2641,17 @@ int unregister_netdevice(struct net_devi /* Rebroadcast unregister notification */ notifier_call_chain(&netdev_chain, NETDEV_UNREGISTER, dev); + +#ifdef CONFIG_LINKWATCH + if (test_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state)) { + /* We must not have linkwatch events pending + * on unregister. If this happens, we simply + * run the queue unscheduled, resulting in a + * noop for this device + */ + linkwatch_run_queue(); + } +#endif } current->state = TASK_INTERRUPTIBLE; schedule_timeout(HZ / 4); @@ -2736,6 +2746,8 @@ static int __init net_dev_init(void) #ifdef CONFIG_NET_FASTROUTE dev->fastpath_lock = RW_LOCK_UNLOCKED; #endif + dev->operstate_lock = RW_LOCK_UNLOCKED; + dev->operstate = NETDEV_OPER_UNKNOWN; dev->xmit_lock_owner = -1; dev->iflink = -1; dev_hold(dev); @@ -2768,7 +2780,6 @@ static int __init net_dev_init(void) if (!dev->rebuild_header) dev->rebuild_header = default_rebuild_header; dev_init_scheduler(dev); - set_bit(__LINK_STATE_PRESENT, &dev->state); } } @@ -2849,3 +2860,5 @@ static int net_run_sbin_hotplug(struct n return call_usermodehelper(argv [0], argv, envp); } #endif + + diff -uprNX dontdiff linux-2.5.49/net/core/link_watch.c linux-2.5.49-lw/net/core/link_watch.c --- linux-2.5.49/net/core/link_watch.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.5.49-lw/net/core/link_watch.c 2002-11-25 22:52:33.000000000 +0100 @@ -0,0 +1,134 @@ +/* + * Linux network device link state notifaction + * + * Author: + * Stefan Rompf + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + + +enum lw_bits { + LW_RUNNING = 0, + LW_SE_USED +}; + +static unsigned long linkwatch_flags = 0; +static unsigned long linkwatch_nextevent = 0; + +static void linkwatch_event(void *dummy); +static DECLARE_WORK(linkwatch_work, linkwatch_event, NULL); + +static LIST_HEAD(lweventlist); +static spinlock_t lweventlist_lock = SPIN_LOCK_UNLOCKED; + +struct lw_event { + struct list_head list; + struct net_device *dev; +}; + +/* Avoid kmalloc() for most systems */ +struct lw_event singleevent; + +/* Must be called with the rtnl semaphore held */ +void linkwatch_run_queue(void) { + LIST_HEAD(head); + struct list_head *n, *next; + + spin_lock_irq(&lweventlist_lock); + list_splice_init(&lweventlist, &head); + spin_unlock_irq(&lweventlist_lock); + + list_for_each_safe(n, next, &head) { + struct lw_event *event = list_entry(n, struct lw_event, list); + struct net_device *dev = event->dev; + + if (event == &singleevent) { + clear_bit(LW_SE_USED, &linkwatch_flags); + } else { + kfree(event); + } + + /* We are about to handle this device, + * so new events can be accepted + */ + clear_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state); + + if (dev->flags & IFF_UP) { + netdev_state_change(dev); + } + + dev_put(dev); + } +} + + +static void linkwatch_event(void *dummy) +{ + /* Limit the number of linkwatch events to one + * per second so that a runaway driver does not + * cause a storm of messages on the netlink + * socket + */ + linkwatch_nextevent = jiffies + HZ; + clear_bit(LW_RUNNING, &linkwatch_flags); + + rtnl_lock(); + linkwatch_run_queue(); + rtnl_unlock(); +} + + +void linkwatch_fire_event(struct net_device *dev) +{ + if (!test_and_set_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state)) { + unsigned long flags; + struct lw_event *event; + + if (test_and_set_bit(LW_SE_USED, &linkwatch_flags)) { + event = kmalloc(sizeof(struct lw_event), GFP_ATOMIC); + + if (unlikely(event == NULL)) { + clear_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state); + return; + } + } else { + event = &singleevent; + } + + dev_hold(dev); + event->dev = dev; + + spin_lock_irqsave(&lweventlist_lock, flags); + list_add_tail(&event->list, &lweventlist); + spin_unlock_irqrestore(&lweventlist_lock, flags); + + if (!test_and_set_bit(LW_RUNNING, &linkwatch_flags)) { + unsigned long thisevent = jiffies; + + if (thisevent >= linkwatch_nextevent) { + schedule_work(&linkwatch_work); + } else { + schedule_delayed_work(&linkwatch_work, linkwatch_nextevent - thisevent); + } + } + } +} + diff -uprNX dontdiff linux-2.5.49/net/core/rtnetlink.c linux-2.5.49-lw/net/core/rtnetlink.c --- linux-2.5.49/net/core/rtnetlink.c 2002-11-22 22:41:13.000000000 +0100 +++ linux-2.5.49-lw/net/core/rtnetlink.c 2002-11-25 22:52:33.000000000 +0100 @@ -165,7 +165,7 @@ static int rtnetlink_fill_ifinfo(struct r->ifi_flags = dev->flags; r->ifi_change = change; - if (!netif_running(dev) || !netif_carrier_ok(dev)) + if (!netif_running(dev) || !netif_operstate_to_iff_running(dev)) r->ifi_flags &= ~IFF_RUNNING; else r->ifi_flags |= IFF_RUNNING; diff -uprNX dontdiff linux-2.5.49/net/netsyms.c linux-2.5.49-lw/net/netsyms.c --- linux-2.5.49/net/netsyms.c 2002-11-22 22:40:39.000000000 +0100 +++ linux-2.5.49-lw/net/netsyms.c 2002-11-25 22:52:33.000000000 +0100 @@ -632,4 +632,8 @@ extern void wireless_send_event(struct n EXPORT_SYMBOL(wireless_send_event); #endif /* CONFIG_NET_RADIO || CONFIG_NET_PCMCIA_RADIO */ +#ifdef CONFIG_LINKWATCH +EXPORT_SYMBOL(linkwatch_fire_event); +#endif + #endif /* CONFIG_NET */ --------------BF3F091FE7191BF1D86D3A26-- From Robert.Olsson@data.slu.se Tue Nov 26 01:42:27 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Nov 2002 01:42:32 -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 gAQ9gPuR023150 for ; Tue, 26 Nov 2002 01:42:26 -0800 Received: (from robert@localhost) by robur.slu.se (8.9.3/8.9.3) id KAA12983; Tue, 26 Nov 2002 10:52:40 +0100 From: Robert Olsson MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Qbhptji31K" Content-Transfer-Encoding: 7bit Message-ID: <15843.17510.701380.783409@robur.slu.se> Date: Tue, 26 Nov 2002 10:52:38 +0100 To: netdev@oss.sgi.com cc: Robert.Olsson@data.slu.se Subject: pktgen update for testers X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 1240 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 --Qbhptji31K Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Hello! Here is an update for pktgen w. threaded design so far it's only tested on x86 platforms so testers for other platforms are very welcome. Short instructions and a script in pktgen.txt Two gzipped files are included which are replacements for (kernel 2.5.X) linux/Documentation/networking/pktgen.txt --Qbhptji31K Content-Type: application/octet-stream Content-Disposition: attachment; filename="pktgen.txt.gz" Content-Transfer-Encoding: base64 H4sICMg14z0AA3BrdGdlbi50eHQAxVhrb9s4Fv08/BU3SoE2QKrYnmYX9U4W SJO0G3TzQJxOgym6HlqibU1kUSNSeczjv8+5pCjbSZwEgx2MEtgWxXt57pOH OsqK7PV/Tj6fn9BYV2Sniv6bFfUNlTK5VJYmqlCVtHg002mdq5g6vW6v1xWv /+QlRDemg0KOckV7J8fvDz8Mjw/Oh6cfzz8cHJPVlOhZmeGhLFIa1VmeUnlp ASPWpDLgqygr6FJVhcoFEQGZNC24I/dNmaGyUmNVVSqNMd/geaOGsjEVSqV4 IEQvpvfOtAIWZsXELZrgrtJ5mJ9USlplYjosTKkSyz6arYlvtspKJ1uFslt+ 4lY5SWyVP/Dg0n+nwwsG7K57c5SdXgjxLVxzYyvpVyF1I2clzDFJlZWWosYR ZhrRK6MUjVSurzdgxxvIpZkNE+FFg9i1LqBUXWWJd2mqjM0KaTNd0NHu3qYb PDwlmaaVMgbKtmM6qwv2spmqPO9TFG/NV2YTDi2lWhmSee5wYrG6hECS1yl7 0cBYfMe0mxtNgkUilUw1RcbKykb07/sO8N6LaMAzjFNhCBj9GogBbj3+K+M0 fjLKKU6kbbTNXfnl4mtEdLHza3ez+J3dkTWxk2yXVdVYJgrpQgD3z9jpgncn sCOiZCqLiQrRxxDcNUH4B6oNCHvJhTHIcNp6sXm9lLKSM4W1IPs+VnETeycB 1Lku1NBcjqgbuXGMGufMop6NkOR6jEQsM3gZv5yToa2pylWqOl5VDWsMQCNz Bh/fubp2XqwkCiGzZlkchg5N9ouit53umyggacrfPYB1/GxZbFzJiaHtKGR0 kLjOsBRKyGTGMvRt4pkzVdxdN9F1YanX4StqPTC33uszPpmLdNOlNG5+UZVu 6+jhiy3mKkZv03XIJazG0NRNmWdJZvPbJ5QYq8uSu8QS6qyc0HZA3KJGymZj aJU5TSRXglGVRd2NlL1WyKLGlidWhHGsmgpZaKNgQHrHZSlc2u3E/NeduwzF u1jUTSE/sdardwefd88O1uh8imY5z1rcXKnqluRkwlqyK7W2cQ/EcIbmsAQk XANOUvRjTHpASt4Eqd72mwW5gfL9DhOyWT1bMufw9E4ETJU8sn7QhNCzplcw SRf57QYZXVdogQ+rey6wVUpg3Uwm1On0l//nQUKrfSRKcyzPUNOAWKUB1iRD X1zwzeB+W4EOQ9fqJYqhcj0L7VXXkyn64PlUPZE3LxvPvnRQkC3XU/TfW127 8rzGBk3eivse+tuB+SjdATbO5YS+FMjbr1Ebc0luGAWZcgeHat5sp/IK/aQC nL0a2yrs4FlPVZqsVB8ZMzjbG54d79M6ynXgIwiQsDPVSNPQKLDSFpJtY/MJ pe46PN0fnLPSTfq0HxZ4liSmt6JwVxDl3804LXupTsthKLy3zSbBWkIylrqy DH6TDsf0HbXT5c0mB7l4AlRym+RtuF1WOIUuC+IVSFCzq5HImwfEQudaElss ygesaPrWX2FFaIlPwLlrCu9LfPeNH5QjzXwpK34Cv4FUMxdfTL426X97YUrb 5MFektoSqLSiP0vjF/j8+trWCGlrpmKdWp4IxbwZMHvFRjbOJnXljeK9mTdk 5nb2WjfU1FM9+oQw3hqrZtAKyg5WNwpMTIhxXSTeL+yHVxv0q7M11wm2XbTC Oreeljmq+aILlvni9MP+wfd+1M/Y+ZH5oh+n32iMXa6k6Mw969PJx370o5uN U8IXil54oYh2KIro67/uZMEDqhpNbs44E78vwW4xO4Q+ZHOUyxpZdJ1OirlP jNvJ8KEaQgwuA5Jl2NWg2T/VYAfYFFqPQvyzcmQQjLi7yZ89ITwP300dUQ9T 0eiquohi0GG3+M7qM0yn0XCmZvqKdei8XTISTXpXajb0Y0Mwz6hZtV2W8XDA 904/tSJA3oi4xxE9INR7XKi3IHSEwgJkcO+RQsqBEOuxzaqfPXkL8iiuoX8+ XH7Ovt9r8la5Us5wpLnK0hq51ljbOCJMW/BntNKNbJoQ988AngSLu5T8HwuD Dfnz/72l8WFgDb3+u2/7b9/3373p97bnU5pNt+O5tjPuWN1YhvsI0N7fD3Sd zrOZatJzpVObg3dIzLoo+PAZx8TD6H98gkDTjFp7mlNokNiHddH/tyeKXd/h Bkfz6r1GK8T508pLJm9XsrASHEe7VxpI6pd8qlwH/ci5K2Cg84xajPG3uoAW tXWf1NZdrc1VlhhoB4t5C7pK6lq5K2U+l/MSYaQX07G2ao12w5sHNtx1L35l gUIRiAk3MkjBap4MvqYcLb7TlyTxyZ1PVzyZSxERmmidUpYq6WbwSwaJs8qk IOHNQyFvXVxsmVk5lOMxiKG95RbJdXx+8dq9Aajq0u2J+Bgh61LW1B6zPSxc geglejaTRfMKYnlD0yV/IXg7z7+QypPwmimo7j/wSk24TBWcvUKc+6a/er6Y B00sd2Bxv9HBuMPwJuRRDK+Fq0rRNgGRqlE9wcbGbwAEDsRCLB07xBLXR9GF JiFArYbhzkFqb8QCwRQLFM8/aIibWGBNWB7cW8yJtUBkB4c/HPjfLTUWC9RY LPBescB7xQLvFSIs1i4UYLWQGvuC1egcuZKVN1dVRog/ADNIOxNVFQAA --Qbhptji31K Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit linux/net/core/pktgen.c --Qbhptji31K Content-Type: application/octet-stream Content-Disposition: attachment; filename="pktgen.c.gz" Content-Transfer-Encoding: base64 H4sICOcx4z0AA3BrdGdlbi5jAMRbe1cbx5L/23yKvtyzscTqAZgQx4BjDNhh DZjDI8mJb3ZOa6YldRjNTKZnQEpOPu79Hvur6p6HpBHG2c1Zjg2j6a5HV1XX q1v9DdHd6IY6yqddH09rYgP/xFGczFI9Gmdie3Nzq0O/t8VgJq7igUoz8TE0 Jo7EfsofezF/fKMz08vznlGvCcVjP7dJYmQoxW2k71VqdDYTMgo+B3X9oAJt xnWoeCgOR6n28zDLUxmKa1+ryFeGUB0Ggc50HOG1zLNxnJpXlsJhqKZqJj7k v0cqM/G9EPt3/PxmYrZ7Okp70u+luVvFWxWJ96lSMhX7I/47eOODWxXKTPnj nh9P3Mz/UpERZ//+txH7v+KxF0pp3gQykz0TFmKhmTdjbUSSxqNUTgQeh8Aq TDzMHmSq9sQszgUIiJRWm6V6kGdK6Iwk1I9TQjCJAz2c0bscfKQiGyuRqXRi SB704f3FrXivIkUiucwHofbFmfbBkyJwCer00oxVQEoliHfEw7XjQbyLgViS 8PaE0hhPBUs8jgh+uyDjcHZEnIqWzIjzVMQJwbXB7kyQiErQnl0+q0ZkcRyK IeDCWAY6GjE+qOAhTu/EA0hCQMqPo6EeQbEZGE2kfwd19awElcUA6elJEqqJ imgOViYFGzPJKA9VT4hLCTEr8IExLC3OsyTPBGEJ1D0W0BGnl+9FSwNBammI kUzaHRHlE1g3rdWR7pAKxMNYkUAIQRaL3CgxgfVpMCGuP7w1JItfc5Pxggwo izhSzHRyl41gS4AwPKgjk8kwBNtMeyh99dwU/KX4qy3ggi2PwQwJbDB75QbJ 7npnC8ZGA6cTWNm9VfLhxYee2Nza3Nre7DWMCXUP3iZxqnjW9tY2zzo/PBIy CFJlwPMsicVQT1XAU3a2vhHdbhozMixgxGqCwDe3N19sbmHsWN6rc8c9CLGY zN3AWUjDvGtfhrQ0iBwUMd30aBYodbuGDCHI0zeYAc57ERO+1qNIDzW2C0Sm umw9zjitAbgtj/9HcXRPvgtKy8apksxSjG1Mb2jhQg2BCf4jC2dioIQchIpn pzIyE51V7onMANap4Iag3Ur/pR5hahlGfKv4OnkiSjvDxw5jmwQBz8t3d+gB 1hA/YEdEI9hdmkemAj/koWpDkABJTBJzYZihvsOKddSfyCnsudBZhxRoOvOc 3x5fdpM4JXumDTiIsdkMdq6veDhQBpbHFKzBQ7gVAqOywuwlUQ/iiSjdFDOV Ys5vOaSosZyZeJDhHeuDWa3JAx4uoiWN6T0UgC1zL8OcZDckr4HNkYKRUQVy GUK0Ymu7O5jBI7q9qiNaED7NyJNY1zGRI3g8u387dd6JL6BwI7y6TE+wYDlJ arIOSvWmEHkAKxhDnwGciJ8ZEaRxkpBDuiMRwuriFE64fDEXyMgBRrApI1qW M+2ncdeQZwva7OJ04Ror2qcfj27OKmMieStpNIQ5woJLy/lq3hwcjm73iQGL pl+pCB6qtjVByof9KY8+sPJDJSPMyBOIL2JP7dNeIcuBs2bd68i3DpWAaEth 2x5WeA42+SWDEG/r1mjXBe9WIiJrRP9xIDaFi1JSrA+lyRKZjdetZmW1Ztqd lYtmBIXp0D7yn9vdM8cG1mJotPDoHBF4NoeYjAKzDE3sZlpG2UTs+shOjFCZ zwEaPgL7AC6vorG1WVDZghUSYg7wMe1e62tpRsmXKf07E2V/DBX04eD8PqJh 38aMPkM4Z8tuTyUZML0S4h35Y+fQoJw+KFJ0gBs+izPOBwag0x1bf0fCZlcH td7bGIafCXQo70hrjg+VjjgqCfbMCErQgD+mF7SRuzDbXfuqZ/n6AourIgUt dLv3dW8KF4+A8y3wnOW+jsW5xIYJRSukTxP+8OZ3nUykDglTb5C2HTL6D+Ct 7R3IIbL5zET+CjvDdlSIGJFz1Q+pzqwBRupBDHMYLAdTpJA9K08ljmM/pzSC N1PfpSIkUquDXjbNGMMYTst5QLKXQoM3nL88ILgpux858rwDgJKQ3dHlLSUC TlOsYIqpMA4fLzh3yazL65X5Ic/wx8q/M7xUoo6oENEmtLmLKXSihx7yOc4R eZ+a0sLhLHRonQZR26SskbcXaZoTR+aooFO96b7GVstSJFkPY03aN2ztzAX7 pm7BIptzPJnkEQIxuyLhQDmaF9PWE/h4bPtSQsbG4oKgsfuPsD3IWY8lSuuC RQszjvMwoB0HJEa7yJwq2jKUkUUU8fr47FnBELfWjAkd2I0tciSNhcLezoSz EUrnVEEijmz0J2Wt15axXqyjBxvGs4QJ+dYtlPHfmpn0aRp0M0IAIQUklMn7 GXssm9f0UMMgZhiww05hnSHXhUsq2TwcuAWowpCpyYIVN1AsQ4siXe8VZpeQ kJFQlZZaA4xiWg34mRTSuIizSpB1A6O0RJgEgQrJEZuxFdeIWNeBkjZxgTFJ w9IkbNaB6fS3/k8/9c0k8SRSq4gKNsy7+anL9pPmCVYzIiMdUL1RWAMnzSDU W/B6/bV/ItKEOQSxzzl+38xMb/x66TUSVdU44GqChpE7lUYqbBoh7skEG8ew aYLGgVAOmt7f25jwRbiwq0zWTAVZF1x9w0iCnNVvXCjEHsVNAzqmnLBxpFBW IyVfN70m1z9r1A1iadpMRTcSQFTNh8OmEbhoa6TN6NSKxTwGlWYYxmOjtuGL ZJo0I2182zg3Dxpf04bxhmy1tTFKAaxjzifzUJwcpPFQW3uujUgz6VOCzFnp PBAP6SxOzPJ7HS+/CyZy+WVu/VvDbH2/u4PXoo/SOvbwcX7P0hxS/5QZxqQ4 pCTDjmLm2j8DBS+hxA8nV9enHy8EIoYtme+3e9s7r1DJc8ZvGxsZXByFIlcG IKbgE0orype5ghn1/hWtM50C7+V77/jk7e37lmzDpxFvDQMYYSCKPoO8yhLV NEFI4KqGgu7zBx1k4+d1LGeHN97b26MPJzfX3vnhT+LFdjl0euldHJ6feNc/ 01tCf2zD1DCUqOQ1aNQQvfNOL6+vjryri2NkZ62t/f1N8AWg08vudeqLK1t2 LYIcX9/UQLZKkGPkBY0gqJtKMgSybUGoPqyRWQQpyRDIiwqkRmYOBBXoHJUd C4LXK6lgbI7K1xXIKirXJzceyFC/gkF2Lcg1B64ZUeoirxRrz/AjWgCTFFU5 I+AAeVprwRAS1GFpu5EEqmtL4htLYo7G6aWl8DkSQFJQEDUSNz9dn/58Ui38 pSVx4zoQwujfObVJSwlU1udd3l5/38o6Qrfn26Z/6O7rSCF7PRDZnsgO9N6f daiPl01AgDrAbD1sYYRAHRLA2t1hk0aXITaa8Y13c3J1fnpxeHNSM+Pa8PXN x8uCXM1kr+GgKM+dx3V1eyHqk7eLyUiZG2afnB+f/FDNdnZ6ZRNGqgARBJhb Xs5ZTLlvDYNwOSmH/lYpG5PoyL76yqtNaC/D5VEdkuHcqwVIIn86FJzldrtF XWkz26BohcTIiLhanmPRJcetrK67GoutrPvazWm39+YBHTPLoAWXC8DE5q2x VdtYhYktx6klkk50VDRwqQNCHbGiOVb3sR9u3p9cYGu/Pz0Sm9OB+hb/vv66 7oMvrz4eecenV4Xfh/deQ46T+5nrnVJyL/5YK/j1xyg49ZBaGJ9ebP+yVw6U D1a2YJDaChM57RCXkXiANDVswLW2g9h2jal+pRza9b6o1178bJQwPNntP6NC xZWkGKb4SCJx9VjR7Crh++Wz5+UvtnnHmD3LbTmETIuY9bBaj7b6nlvDgTi5 +d77+ezkYq+OiafL6ZdMj4Yp0V1gRiejAvbYua3T+XY4hbzIKH9hIbs7trLc m4O9iMvqE9ZC5egymImHMrVg36Og5p4oW8+Deg7DAVBGtQImLcNmU48SHIiv Ds2vHHjRsqW6egkcyWycmmLBJ/zJlj5ZOmNLrnq+HccUaZ63ZZc5I79Rs7GU imxs0bI1l1Lnw6GqWltLnJBD9bCayFlCga/sSVL/xnIGlqY8v8OqkFHRRTR1 tAv4y84WkV/SumXM6m/tGVlHKE3mxXc1ZoibH6XhEW7v0fK/QxgVK342xMcU G2QoNR1sFGKkdbATM6gxvhO2w8FCvVMqWVuFrEK60LrlvgcnuLaHraaSToF6 HHyXbY1iBIQgM7aYeg/WNFhmxu3dJ87WQag8ZMSLwgXDHnht8Ekk6NImmMTt 0hlSkKfcOXH7T0U9QY6Mq3grgUdktkEZwoi7SnQ0iICy5fwet7Hd8UOSUFfa nZVQyf0oRsdJsQ94EwzUkFqJktteRTfeVEbXexTjO24jQTURHcHpIR97PtA5 TuEztja3Sb6Uc1Mbw7mUR5E6lrilRgKs89bhs4tqN4IMUXiUy3nn6Xpv1mtp pw57fsGebihDOgy1p7HGSYvMqXGLcvQKsOHg8T9VBcIvezZth0yU2Opt9170 durwFZicfimYSf2/Qo3BnkRtIfDCGUMbQUyqKE6qXOhk7UNP3HENS/vUNf3S AS2lBrYpWRxu8cHDODYuxprHgqyhYzBaMbPLpaZBWtIpjruqg7KVsHLKsGr6 JbDBKrp0tvYUyGWqDZB10K1dkQeJ5xS8Yrl8TgYHvEC2DrtyuY/DOjNuXO4T IFcstw65qB1m1nfRay4PoBNP2o02k+PmcpyPxg2yZtJ/FUf5kEfU9lRBfWf6 n3Zr6ej8DMf63IzFyJynXsFdPBzCby3FbswoZPDIDLKWpoFgaQDqoAGnklVD INmErkxAGxf0UozHn7Z2asvlHPWPahJ+Nqebmx38fsm/j17S72++pd9vX/Cb t525+fXnH5UYkqtFToD6vNwifPmkicYjvxemv7Sv62//rJaxZNCJDNiO8Jfu cbDfGo+Fq2GoTx7ZexaYa9PVumWzddh2/6evt7bn5cUnAtTtE1TumCUfbaug l5uAKgccXXPnUQuVj2eZPYp+KGeoq1VLdV12OZGaTkDKo54HWzB9JkfbsNiK tLuoB4v7L1V6w6nt55D1F5fgyj9bOEMYI/fIyyFC8UOkbKWwApQqxw1uYIii kqXVQXa2enV1m0X73FCs7yLlzNWcihzOSGXunGlDxHhgnNQwhNK7o7g6PkHa xgcrnHgRfnc6ZU9iPpv3klzH8p5uf9Eh7MjT0RC1VcwdefuXbwIhvxHuhOtJ OEvmqjyck7rMFRtjPthOi2OfzyrMYs0aBMDWKlpRXEOto19RNYsn8uqSd7oO QPfdXAsiiHvtp4AvWxL12QOdesg70pnY4M+KKiBs7IVuwzhIa90G6+6S0djj 6yWfTfiLXQ+Dv0f6WtZ0TZTcGWxFjFox1HrxsqLLs4S4btju+HehcDu0bS5S Ax/ZfXZf8f6Y9yvLzZWau9nafmkzQdYyXZQrvdSXSH4Oc6MDJAFTp8Pm9x7d ldTpb0z6R/Ucy/S5pRcXI2QiSUqu1h6q37tj6Xr8fgbgd1qFgUspWQN8qGx7 V3xcrYJ19tjUyuBOF2JKx+b0esg3QXp1/8AB0fZEXUmd6MA9+Ule880PUmce OxiP7mZAz/zBGkfRE7s6Of/4w4nYqjrEp9zf3yT7odNdYU3S82d+qIyXqJR6 CasH88cGJ8a2+axX4ANn6jnS8Yc9nsXeHUoyab4NZU94fBnR5kYRFJB3f4jF 7k53QJfl8OOK9Y67hTHKQyjYjgsA89UnIFImep7Z/iY+T1/uCnsc63J7vl+y Vu9103nN6Q8khr67TfsA96AmrukQi7PzD2d0QVIcjVOMHskkx9t93+eHNzLM evDhfG33nbsMQiWxVkFfBjKB2vt0SXGCnCbg3l5x1RJbBNtYm55Ni2E5I0Wo +oM0fjCqH+pB3wqYjk0nMhv3NRZUfOj5vXE2CZcuWW99++1OZ+Fe85GcDFId jBTmTcA2/PGZHMR88jWzd4ZCcUXgRlwpuOt7LrntSTm8BwnK6drs7pC8UW0F +kWLPk07/HLW4cKWDszbYq1yP9w8Qo7Wmop9sdkW34nuVLwS0725GQOaMStn zDBjNj8DmxlzkFwF+LNVM39Uz62BeE2Qfyz58YcxeRCM7wvZNF78YMI+o101 IVg14c+15afyIYgbaBLDEMnrA1B9jCcpupiymiWSyH8eiOAxnoofCOh1I/vB 4kAF62QXtBeE7bbMwYFT9vIKUpXlaSRaLSj9v8WsLb4Sra0w3N/ffdFuEyBr mfh/JbpkRG08N7GAjasewz9txixLvLKO1Z43ncCBYE/Q3WcuzAKFkMpHEM6d 0O4qvAe5iv7GRv3G70QjPlY9PLcv3C5xXeV7L4vhBFuYRc3OufCN7OZ+bodY mAmZd3bffQ3gnNrjfbrft1nxP2Ftt3h2203kNnrxbn66kxF54j/XGhax0Ipc vYz8i5aRLyyjtomfwn/TEnK7hCYOEXXgjFquBd5x+dNAmjmzdKuZJGAt2qtt TgbG+44FWaiS4M7uWu786JUj1RF4/I8wzAWD4DkAn/f23b+i9U7Dbo0s+g5x 0J47RnELzDiTe2yFuztzaySHyWtcEn+5yD6HBepCwAehQrujC9Latmhl6o81 XUBOc6RyrnwrbgPa72WYPOF73VVsdTuEjmaZ+Hfu1mQfKcmwRSV7PKRvPrTJ sb1s0/F4g4Cf0Y7GkOWzCiSljKxzaS8ZQSEjyrSkQXHJqUKcpnqAElP6Pn+1 A6FI87UN6vJJrNIGrpS/TbDCykcqu+Izlnt1lKfnpnUf66BuPo4DZ2uY7jKd VruzlPa0CyavSz5UEvuoj86pm2xvaSO/pevgdDmfLpvoOLDdczr3oSY7SXaR q7VH2K+zXbOIxarhfs70AUcj8TCQs9ZX2MvLIi+8mB39f1nX7d+2rnzVugq7 GcTx082mic+n203eZDd/iY+L/xUfkeNjRTAI9HC4IhbIjmgeGDSxUmoAOVm3 +jRoF7Fq7j6XO/QtuOLSzn0P7NMv4I6u+9G3leBQ3HWvvXKyIcfkuYoxGcHl hR5VZy3HJxWYG/y7YxGD43zYEQ6M+7kdWPRwiE8b8IkkoUdw883ZRuQsnS8l wWUfoUdVzmxbBIAXBb8b7N86wsLbBq5NxUMV2YcN7IaOILsQGySo9t7aEgF3 keT/lEjDIpbkIzaW5UMNI+4z0pls2fFmt+Kk9SgZt5S/mZS9a+8VrQi77eZm 2Is3SzPm+LVNEzfTNlhazQ0VOnRs6NYsrN8OySD4LLJKChvu4kvNsptbpfYj yubAvWvVkTyGgnmtw+PFX2Ottkq7Qo97KgUyZAXUZYRO+RbUxoJSC3VW+Phz oYYcogtDx4pZUGl9JnVt6lNh2ovTa4zy7EZ9FHKhh9WUVkmqGYK+ZpV6xf2R JxFcrayLi1Iada1gikd66dQM3d3ssuGE4v9ckVELX39Ho+mcr+OLpPyCLp37 8RUiMx85M0ZAwvG4kUAFB6X79GAv6AxmBegyoKYgSm2IvUWMxV2AhuFADfKR fVsKvOrJ1q/wYdL15emFd/bx6IN3e0F/To4f3ZWloorvvRyIi9uzs735aGm/ rODVOq2LOBcaqg6g6KsuYW3ebY6VhbcHSKWfle+ou/qqaQd3XC+7jp/8tVf7 jk/hQeLEMNoireixKOjnYCnSVxVZz36nZmkWv+5wE1f0dOxnoZtjqfGbjvv+ +UTOBtyR/pPtrvyCiu1aUv1UfCOMv330P+19+1MbR5foz+KvaFOFI4F42Y43 HxjvEhtjKjZQGG92v8Q1JaQBZq3X1QzY7H7cv33Po9/TPZoRXifZe1UJlmb6 eU736dPnuWQzLjHh9ZU+IjSc/SPNmk8C5+ze1oM5nPkajwr+ZOm/4HrHOmo4 F397soW6wpZkB+RKx1thaOx4s2q1YrNqtXQLrdbVpJigGgi+A1vYyulKftnG PrtieSVf7iqGD67VUICrwrzhS1sxOjgOfPGSZ8LdU8n1gzf7H9+d+z0J0aJa Aije9I5Z03TWJp6Nu4banTrtQDMEL5R7QEl4GJz2NhGgg5M3pDRh/QNpAqCh naWW5JmpgftKtMeYzxLvyYbllQiW+F2VjDUvS0JxOptJFKuVgrB61O9N0Sut /Wr/NDk+OE/2X78/Ou50ysI7rr9+cHpw9t6FmSqByJb90qG62pHOTqLd1sc5 ihoYoxLJjwjjhBbVxfHJ+4P3pZVkcIvieMYuI5ZwzI1aDQXwm2CcDYlkGupv VGt9+xOBhjwMep9R9kDGd4hN6vURPOiPpmoJ4+G+LLuq4iw6NG4NQBSKBlsD Ht1rzmdpuKWWlKviPnSlXB/HKCgakw8mULQdsZKjVEvI3UR1CbjS1nNJQwNW 6i1FH1E7j5evd/ODyu4Nc7H7TRX1qr6VmJU9les5q1SHSl4Jl2Lp7WpHz1V+ pNlnr/SEDUH9xyiT2zOSDqshIBXwBuCARAPphyJ+U0A0hSHJd6QnLksjbVtv wBo+scy58QlJJ1tsbStnhX65tPn1b7sZ+7HVFu230pioWbIIZ5kocEo8DM0Z yefEhKh1Fcaj7pZNzK1xQKvWL920XULdF3TT4aFKMzMciFA2kDwqXgls/cav pTlbzUHLlrveE/QY0E9k8/6T3tf5A5emWjtiGfcj6pvbGROdTLwQz+GftTVJ Avz6K1tP/o1OTa/X/m/ZJ9guqD75Ufwz9rMsoP2d5Y5Nk6PDkuZl32ZEyujN HRGAvcmI6KllxMhLz7JMNA/MOrAfcIkayLY66QaeOki3uqvTrByINePKBcGX Gp6HY45Ij+SyfjOkDTp3Wk6bZewk6uBVFfE00oXIH0U8FrbzYUhLWJqO5aoY RnSwG8tfsWYv2iGwUS/Goa5WN7b/XaN+jCtlrX5sz8um/TQBm+2u2agf47RZ qx/bx7NpP03mYzuG1iQrQA/sI1p9yXt8WZRbx3iIWHwFh/lximnXkPDEpD4u NBfTHDAQbDQ1QSkMBUmSL7scnIWCOaHHzbpsb73nWE9XzBZ4khlcUXck6UDZ yDq5WikFKDs/KdWnHBlNnp/d5Hqo+gH6uKgfNcgr9WfRH+6yCyDvmolqpoYV HIYVkP40AW1LjWOWbfCYnpaNqM1z13S65rEhW7d5mVIX3ku3n/kT0EbbO2Lr 68pXYYy17QfyoDHTkUdXzXnoTvyZBJ7JrgJPoT95ibPXPxvvbX3qhBiHM3qr rydeLUvRHK15BKuDN3QLLwnSqEjdtqdinbnv+yXnssKSw2LWy4YJXiNssWhM myB9K1FqgLcPeecoc0pcRrNLPtCpC8ueQn0QaqjUo3ssLPbH1iiAjerEjVvl XPX91n+ff8kwVlO7z9xbvweXxh9+X/5hx/wY2z9m9o/C+iGs73v0vXUB5Ooz XqmlrJUe0vV6AEw9vrin6yb+MkKQzL48uuoa2E5Jb3ZVAx9UnIFNxIOph/t6 FZoz2JICKXzIX/GCBuhr/0kRhy23+2iI8cPWDx3x+DHgULyAX3/7QYoHeC6r KADf1T9hp/TFOlQh8Au5gzSq7sNoyMgwdjZOUOq22G5QIsM/MUi/8V4wSz0B 2Hn7wKx8fBlZ/Q/SqlZKf+epQR20ddkXnsWbxsx7+znc3257QxgTm3y33FYp PKPaSxLCDxW+sGoKznoZ50pJLfXiQPNUsjvaCnBxdr3HoWPIFs6wBBGlLy/E dicoSfsyY+iRHE1QQJlCnjctvdiOjv91/50U7i210CdRStbg+AFsSzOp8qHj rWtCgncdw6pkTouy+tLosuEwveoNw+NCWythSxwzJA1kgWVAQCEwegPA5Czj AIpouE+STi2HZ5pQGqw0FiNBDUx02xs5Vpcjt2TfwKq2RukIeJ82ax633IZw Ap5Ql8uVukfSg7I/LZYvwR5Bz5NYCPRmAjHLVdktf+7tsfDaIpVhlPAVFyxu Fmti+1OZVHlQKC66wiHF/uVdfVSzn5T+xV80K3l3hSwfqSGxvrOS76wT/8WQ lqSiuHCuU67km0su23LGZVuZos/xEpy3AeGPiW4Exl69biz4tmg0TH5g7z5b e7K19hOymC1FkuSzcB9c6JF1kbNnUmXNHawA3VGLcSNvh1meXw0nq7ldRdEA 3ie/7Dgi4r2Vm+WI2NemBCqiw72n7PGQaUmH/+LItOXctZBpVfi+yLQ69pHp CuurkIkGh9eTWdG/4YCkGN6GotuUVVYS1/9L8PydNu0ftjz+R/Y5nUrfFfF+ RWVKIyESnz8V5MnzWdp4sqR6+s6r3FN81ZkoFfSwzLXDUw7t6Wz6fbFqTRS6 ji9wusaW7Js7wPbY9TvipTV1HQap1rY2xVkPW91Tsy0IFTy84GCDSBEhrFiq pT90z4UpqDW6WpC2yjckhLJmBR2U/1bgwurdw4k9j2a4kaq8Pylu5Ohq40aW XwA3UHOxM8rqNoAUNYEFNkzv658UKUrJ32jD0MX0226YOjul9zW2U+i+23in /GmRovTsjXbKQkh5+E4JIsUYCtQ877XdzB+KkbIZj8XvVADDZMhYGSyHrIEa AALf/lGsD4twarB4VHAPdabOdKUUp+ZUHYuOP+DyFjYtwc3IHdTZfW7VZvvP VZ+6MuA6W9Dp21t5zrv6KHGMaf5IlDgDaYYSt2ozlLjq7uYocfr2UOIbKtVE CVqTMCb8gXCoGjd8jfpIsfQlyaSfPukYM/a5MvBLXwBeE5eejPcyLuaecybK +V/a5lfLKpJCjQXA9jf/2LONvUJo9J9oI2ZrAI8eMILHe+L/foMhGKutBYFg GlgYCg8ZA4Ph4YPQRnILrwVZ/wFrYeERqLXwwCEYy7oFgWAaWBgKDxkDg+Hh gzCWf4vD4aGr4SFj0HB44CCMZeKCcDANLAyHh4yB4fDwQRjLycXh8ND18JAx aDg0HUS8hxCLgrbWUkcqbtit5vfx/m0vG5K6nMbSBS5slk4xwsEjyu0xXkdW CN91dn4fo2l8pakGfmr48pmjHTPUyml3hTkmusKQCfquy5jlQt/lc9cS1v+4 rJb/toqlI6DsoXmizczR04Z8NQrmxD/+IcrvKvg74J6cyNT1+Tjf+2Mhtq40 JpfJI++0CJvnV8WZwJtPYa7a2k3UaHn0j+ZsKcnylp1etuIgqVgxCN/+9C7Q Ho0vPEf1MZVUrGzMMTNOesVkXB5F3csJtmUbbJtA3DXIRXYpTTjinXm2FUr+ yklxy4at8eHb17rKqxKKWcu+NjERa/zG+vU77CCUx/11dxCOfqEdhKZ0sR0E jTbeQdjeAjuIpJvhHeQYO0XbqdpBva/hM8HsmVbZ9EgJXSu3h5SB1t4QKE0N OJ81kKQ6+jl/Ut9qQ2g1219yQ+jRN90Q2q0usCFUo002hG6vyYbIq44Uozec 2452lHB8gKqOlDkbQulSYxvC1mnW2RBaO1r2D21yQjj6N39S33RD/GVPCD36 hTZE5IRQjTbeEE1PiLzqhDDqwbntVG2IhU4IpSut3BANTgitBA04TDc4IaQg Won32RT/liXlZPnvT9TN8DEZDpKBSvHRarkvV0fO8co9BcXTiHfVVFlK3hXP AyirvzF5KgtKsuUq5zbstS1bJVB7u1QVriHzhh/oVbLKjjsA+cePxQjG4sNA rKGn+q3yVCdUQml2ocFK8EN60HCB1ir7zzzfVb+gSyi0LqQDDS4Ip519u503 NdqBCmvKQcdvrGc3dlmjsV6ksT2ov6Prj9bWdFVpBU6lLVs5G6+4tGCtVy+t uYQOrVBh195MxWvM1YM5Uy0X1chytnw0rq/RP6Puui6fAdV8Iu3epnrWh+z3 vN5+lz3tljFjbfjcxYqsw4D5f2N/yyn///1dvb9bdvLQyBaPL6Y6W1yl9KTs Mpi6xaQwRvxAX+jFnn6dDrN+VqAne1psVBECMg99FAoFYDI4d8j7URfBDDtV w/R2kEtjnjs0ZsKUJr1N2Nc5RGrUp0xy1GeOXLnBeJytXX8gAcJewRHFaaFu JWhvZEekDN8NpsHglXJ2gRnFBvkKG8iU3yK0sRGWVYdl1FYKB3MkKAjrfo4n Ir/pX5tok+L3ZWA3l6UjFALI9/AL+G0uEHF33jppEPpKwzEYVLIou1zKqKMl r8tKt00ZNdJdHEUQ/x47f3B2dnJGtk/DAREGDBurUuvAvdcHYSWWNRoMnisD bB3LEFUikCmoOjJCsf6SF33Bzh9u3cqoDWccoGNHBIOMmATd5qWBs0ywndnp 9mT6DlXIJoMVsUXKIZpy4diwq/hapYp6MI51fWhvBQKrfFBxQpYdGDWc4KM/ eobMEhbzolf8PvbiVxR1IleYWsf75cgV1kLRCdkjAS2+VcDsucfWgp7kXdy3 u7Y7+bOtT3NJlikgiZw6GcyLuT7oQc/uzc3g9eDXgIN3M/du1es3cTUWpmPi vfmC4vg4fxeX7dAw/nJ+23OA6Tlpl4VRxd5K3tWGuze+j3Qw3NRSy4oE3bbJ YI3TmAKgFuHByKP0eCKPT8vbn6KkqlXqx9t1IyIUbiyEKn7PhJ//U9pS4p2H 5y5x68y89c3MK6elYPxANi7DXIqJqOq/jDG6plkWUV52yiiswNEsHcnqGB9W iSsKtCunnINoqXOenB28f33wr3RD52hgFN+sQKp5vv/hl+To+BxW18fT86Of 3x2QNLV/nVLocMrBclO03/5986cOpzk/nU2mvSuZAxnWoemLsgi1FgKDP48y EKqgUGbRwiv2IVbZQU4wbiq9EBTKHSDZWe4KNajS5vY2v4w1LSmQZCBs/oFO ZJd3CGbAsJK9YBkJPDMTDLKOaRp1GHTRG2Kfd3DzB+7OyUas9z3u+tPD5PTs 5FXy+ujMJj8URMsNoU5fxymu1ZsLeLQrrPfOjz3rOzNzIeSTnMEtCauHBkc7 H0UMQVao/UhI6UmpNiW6UvOREcWrBBMyBpP/uDL5IK13q+cgM+xAzsYoRadv O6P8kBy9oS8KwuFzrEn/mlU6PiFCU9GcLLrlL8NgmhUn55B5H5hUYC5OT5wW dPyZL6CTmWyPFt7xsZUiInARTpJpZRoNvmo4STQwW1IryuG26ty21TQKsec2 kZcX0FJL3qIU72DfcZxsLZjvR92MHP8Rrug3DPyImhGfuC3zxtxk7efTUC4c Ey7QK+1ec1pK6KnDyuGvgi+OfEmzwhmpKxE37ETVb5oIpR4Gg3jy2T0L9qF1 o3rSyVY0mn2a3YrPr2H2nJsxJsn2Q+dxug55j5uiYsCasclnDnc8J3SX/abT xnp4vMD2OsIE3uLkF04G/CXFjIWc3W/ImYKvZpObqaAhcY7b8eRLd6mFmeJz LA+XfRjiIJ1R6bPz43dUeAOL4OVGxW6jgdNypVBsxwfnQHOSV2/3jw8P9l+/ PttxXxyeHB0fJq9Pfj32XgQefTzFwG04masxxl1F6oDR3Ymx0YvSq3N8dnB4 9AE4qJ0yXS7hn+UNtAQ4lzMtex2bzzqqj0/Oj978O4zy+EBRsP08n/QzZL2s FUkZHXs6g3s5U4mdm17WA978hnIZVeUVEuHlQOntGeUopR1TkjdqMDfhZkqi +larV0xGGdD2tG8LwCdSJnvZx2wNUWkNFyzFgiMWqBgPze6bqK2HIn2MIXhx RymOrHiymvxRTZtJoqPOjNi/gY2lwBigwcDYkRJj10TBoq8KlUwppKqRp4xJ d1Hfsn92+vbsdXJw/vbgLNZtIQDMKeyKGXQtHtL3I2gAkzSwXI2G0gn3KtEN W3ow+TJu3NuSwnc2Bnw7WDY0UmOV11QrQtq5mNoEJPtQRBYvd64eijKL56yH pofj3tBa3pQVlRY1Jk0FXvq6d8uJGpkmZWMWAWGuVHjLrNRmjqb9017/c1o4 qS6dFF+0p7Lxf6T9ompb2aw1sVbztFrIuszuxAQzSmI06K74j5scRyqIDGWF TMoOhCqoaCvt+bI6Jsr2zRtbREjh4Ze3rWA7Nw2kiEonrrD5Bo3zwqqc+LfQ cRLw5qo0y+B8oMJybsbtRRWQXqyxuJVHU6uOQLNQkERBdrOOvRn+kCG19HM7 IpYtBw5agG7tll+Q/NESIUu7P7yylm1gY55KpZMPgwUlxFtVOB0xqcgULydW +as9PbutgKWI3T9XRtrcI0VLHT15zE7WaYi/YYE0D1xB5rVJAK5jM6s+ISW3 nz4pqIB+kMnvohaS9yV1V2NHFr/ePPN9e+8cjbMi6w1xV0gRH8uM8o3oNqry 23ftOytiLtQyBLWx7A6hhneOU8GEX9GPrSBDFZU4kI5TSa4BxVZgCDNgdgBZ 495YpbvM/bMe32HWxzanqKdERtVnfQszRFEOAzIF4ABlOnWzpdSSxXRI+d1d ZswuerMZXObafGGHEl4TqITSzatLPZWT6TBf7tHkVsv5E+yr9r1FE1XKBZSJ 85hkPmcDJDspaC7acMHs550SZ3QFwE+HvTsJLvoOHdeCmQUuN0M3AkKm3dLg c2Dm7+nBRIlT24Edr7N3lXrxS/KZgKNa01NBw642NrEOwF5M9hfsp5YOXH18 rsa07T8J9jVOU7S+IKF/u3IOSi8Qgk7cOurPB/JWiFzbq75NO2dV9UND6Hg0 91egtXAvo05Q8C4ml8QuDieTKTIywD1ub8Fw095seAdLHm6P5CJMlw3knSaX ZmiryMcjZUFcY1W4N0HDcMbBiG5mvf7dhlXY5TRLAHqJEA4BRpOvUh0kIyiP seR0Blzq4oWrDBPWzc0NTHqF3hAI7PV/akmuEibIpPJCmkZhAphda8snuUsU i+2uKJ5Yz4CQwKCnuZ2IDx/2ORUvtO5bAwABgMVGuqzLAVCjx4xPEsRSj1Gq jGwpwIsEQT9udWFR4P8KAigWGkzKVFoOD6VmMLBO2yPXslMtgdXFka2Uak0p uW7dK/sYVegFjIM/WD8ws8nUUTpvo/T0lvOfmonr10+8125tB6Q8F6ixDq16 One7YIQ5jlwV7T6+9HLxn+lssrFRXMM2wNvWHV218ILLF3RYC9uckbB4Qv9u bGzE7biEGvQ23EDU+ENiJgXxr//0hj/28lf4UCjYtMas2IdXwHxdzFA0N393 0NkoT+K+qme2STSzzFMrBx8ueCAiqO1R+0yvJ3z+Mnza+w+hPpR21czyKgZk CqgP0bFJV0zGcM3Fg4KkItDlzZBVwFgIRRMuo+nlBUfey+95k7N2O8uoXC+2 mModbAdt1Lw046GBrHoDMZW9FeujrCucMXD2JW7UfB/lMVNDfw7lBFf+kxHS DF5vR3g8jIDP35z1xoPJCDn/67Q3SGc5nhiT2UCeIyx7QKGYezFAQRgusKNT tAjeHKSY0+nja/kLTqfpBKkz3O/X95FLl49L0q/RZJAgly07rxYol0As2eiR xbyoR19tCo765tcpHBok7c4nNzO4KHuyh4r4dC/ZCMxfRdzVKOBsxW+cXBnB burmx1OfEV5DUJrOWIPjYCU26Fos1hzD85Fz6ylf5tCNIFbXmWfgHviyJDNK dGruWJvqU/t+OR8CAf6Z0634o/vtx0/A77QBJI+Bzr95U3X5v77+bZuSQAdX ALdfQttvz6gD7OHlS/FTR/WDD7EKPZzX61bjXp/avW4/X6jbvzXu9Ynd65Nn C/X6U+Netz81af+fVPvqZUSeaVEWlGlmYxb/V5EXN2Di9yEvFWkx1aeavMTS vhqo+E8akxdXqNSIvHjyKIu8uONuSl7qxKeMQ2A+eVGpjpuRlx9rr33V/jeg Ls8ad/otiMvTxr1+C+LypHGvzYjLdh3i4ixyO3b+i4AsMhy8OkIPqtMLlwbs ykHb7SiNsOOVrwcFph0nn4IbeN/vP0pRWnYEZTM26dZYog1q6C/jkdhbkSaj Yl+yNYoPuAqLKsrTi4AYuikWa1D1iAh8DhZVrJ31wCBDWIyHpmqERWimCos4 dB+LFtyCWKyS+DfDYhtuGnhCFpProcVdKK0DAOUF3LhHX6NlMDZH/KgPmPpG EF+ZUV19wkjG4a3jlYlQiP82w1hRnpxW3rANno1APIihR4UbrEy3tTlwV5+g fui6mIyHbdfstAaaBjXQNPjWaKqxPb8rmgb/82ga1EVTUPtuE8V5ediaosNE umyOj+CgbOLoJNWKR/yjz1qkWnMUhy0b1lCaZaE2CtGW34xrCLEI+i3zCscp 0kqhLWU8+WfyniD/wmHC5lFJNr19FrIVRROGrjYhnqP/8zvgrBLSuAxWzU9i NS2ujSE1HAnXA3RrhH93WYKKHlXsRD3lEEHKzoJLZlhQTc4dDb2fXl2XrA2h DRpHbzic9DFFRTuGvefPEIXPu+LwzWmyf37y/ugVe3eh68rnC8ZcpWf6KB1N ZneOI6JlWwdtoMIund2mbfjeRdZc2mSKM35Owj1tM4jyv6NTKSFkRx14hxuF odkR2OT0Jr+W7T2j8U6vLctfCbkOlyy4oHTasouQLyBiwqqrEFRVmcv4WraP 0wEKmnvjO6VfY/klZUMdiC/X6Vh8SX+YpawxQ5FoRl6hs2xyk9sKtsssHQ7y sBrNl2IaLRi5PaJNE8Cra98AJJDM4pArLrqp16EC/HmyBX9+2sW5HQAK1gAv +BdYwWvCC/kkyqZeeCAyK1RabZo+owWDxm6EH+BqWJDKtD4P8twKmWhzRnxY pChwZKYoD4lLqiGuCfQgQ+u6/fN9+KWWxKaq1L9O+59Z24HFYBPQkxwznJNd MRbKrodQ5Mdd+fMWkIWymj3xTD0qCizx9In+PcmlzRf9nM4mxaQ/wTJHp6dn J+cnyIXTwFD6TRgg0Pi2KZqDUS2VrFf04alKYAI/lDvo/hkusAIAGKh8ZdCY kRaJDTkq31FvDXi8B9k0uewBP9wHSLXbbM/fwa2ItI9BRqrOzxfO7JOEPCB6 4yLh7g7O3yanwPLownAp3pj1vtBxSkQCmiPnzGeqxMC23uUOABhk2rwnTvdf /XJwnrw9+XC+65uFy8yIL6LqHZt42HTZJSASgB1SlOqDFcm/yrzo9bgrX2cB K7pYp6uddptCe8AXXKnE0P0UOOul+o27fine7/9b8uGXn5M3Z/uHH0j7pgbl vFFaO7VPXvLYV0/3Dw8S5HfkOR+a+LpflI58QxS81+xRQ96uMmqQVC6bvrdU bxIKvSs4u+mvOvfwR97Gg+2Xg7Pjg3ddscXd4gDzazSgxjF2ePnnv2WfNmR9 /KdGSUdSV1ma2RTiKSySqacr/lnBSeyICIzW90R1+2oITNTW6hfHHpL6dTLJ zZeKjmeJWjeZRqDEG2qFOUuoDIfF/ksUT4vtwIxRgbL0YgMDjBsVGxVucQnc TfFEM6JUKdRajXbW98y4osCYNyQaCdpS4CppVy+imkuyeugNF2wFog0oai1p BlazVeGr8IveaEr8EpopdKVbxP+5SdGNYHwzuuAc8mM4QUnXP0JlMbCKZGpx cQcs12SGvCIeiNBcfk0hfL6gRQAxZJSnTTtFoJEAbDdfXXJ1HaHucFBcXcM9 /Srrl4+iYfv0l/PDg+Pk/f4hMc5+AyWrlzY1iQ9ynHZQduuU2ChuMSZAX19z w69rtVPdTEUrgI4EMGEqa2ETvwiybn4hW8eiLVVgjdj+grabiheaq0pdb3mq +L269hZlEzrfyH5y2ZtFLIeLrwkutzzyOp3NJjP5kk0fpJ+A8eLBmw566CDf D/UwZAdOUscOs33ibFDMbsbBeBxitbC9dAIgysxtFEkuWVWRvdcWkrjTw+T1 wc8fD9u+AUmKw5GjlAPYECtTjh3UkS5o5QBR2g7ICp8Eu57i7WTsGCtwn5Hr IjrxrrIrDDFmbPpBbkxwQyIrcblpN6joJrsLlzyYMhoOBiTJtPuPkBLfwDrK mOBm2l6VVggSolez3vhzKu7gWjq8fMQdYjnnTs9PGIxJT5r9GnNfeu1ked7a Zb+o3jgfZcDPjUbpAD0jh3eyB8nE4M0ts67WH7APGN6yPCC4S6ay92S6B0xk pO4BLkVGtmqB3OocF+bssi0b7QgrDgdmq2mfJx/OT047sa2J1ncY/kI5iybZ ZV7yg49HenMe5Y0Wot8zeU/RAvC9m4nxsNzMVW3pvx3x1S45N3u+/9IdMTa3 ObvRDd/FPJCkGPYeamO5PXsPUUX6u4d/dOwI5uTb/MyyvybOSdqauV7qZTqt A27kEc/tL72s0KHv4pTImTzVgTP8JiVJRVII+hGwXcOtTl2Y0u3H9L0TKm1R HdMZoVrhpggK1N3FX2rXwgnQ8ZtpkV2gp8IwTafJZKyjy/DAuuLt3ze3t2JW 4NnVuDdMpkzn29KYDQYVldRSqBSuFmqyTGfvbXgEpiVRigcfN7vjvypFtbBx be9sRLhvF11jS/Npk13JJeiHfeA3kfVVSPvQNjcA2wMODb2E/X3eop0i93E5 oAwTvrZqSYYd8ttwR+eFJTLUsOX1dh/rUXE32VWMhMJEbTh/H+rpdRolnh71 LIHj7ONxkIiG4vnUC+T0kDhOraVW1ertaKcg5MdyDvy43mPz/llXx1dBB23F EiDV7WJcCM2ZPRaExBzw6LBp1t6hs4m1CHW51SQhx4EJXPHJihbZ0q6YTuHr xRS3kY6f2rK2fE2nG381aO9gCjWa5ToSkoRJxGXebzYe41R3rLlpbrjMJ5VK Gl6MGFMFEcc60jS2bj9VrBgSHXY6m14lg+zW3FIUs1+2WyYXf7sTP4IjoEI3 +PyZdfGhewIbZHdVhwaP+LijFB1FD7jKp08ugPvTao5XZ68QHxMygUbLPFzJ F9wZhqcQP6FPT0xr8yyAlkBYWYzUhWm82338uzbAvx3URgAk8LtorwzwRtOh X9gv/vv+YhMvim38DiPqCME3G25rubskg+KY2WpsrcsFTH9VORdm5cf+3Lq4 5/cHA4EbQ8MHrxYoI9AQtEXuqknYN+o7whJtsrZoJ3X9axoUszmI0KkY4d/Q A2UeFxQKx4N1u2L1gnUTvr7O4WtaUR5QhJhAPiwfeUwg0shszJne4TX3yx3D aQq/9tQpphNeCtOsvL68oJL2ow7dOeQshKH8lYwIFq+6S0Qvt2IuO61h2fAS oc8+Q1YDnGUjZjykrfbPBSo6n5GL8AzpiE43vG1FITb/BlJefuoL+c7RaQjd yMAqsHcuZ2mKel6Smn1LgOmLWSkI14PhxBCpBSYzax2kRRbE4cuQTuF2lIGt y5CZserQDDBpPk/DQen8iHGqeJf3a8iwpcSykQkGDgh4Mge4cmBsBWpza1oP pdjf0dTKVqELWy0Cy2eeWqwf88zO4mrZ904OlsbgsgfRciIlhC7fSZKNh9k4 TRIHxV9H2bzYNbGQUI59hu/yjsJANPUhgodO5I6sTzpzS9Wv/UGX87JDvo7y pE8fFT/IVTJCRwzfkL/xcW4c5vC9ZbZkk2VCjzVsdiIMFGX/Wb7N4P8yag96 L8J5e3GT362j5y2u3i8pRx0a9mZX6UzQdZjY5hxFcii+Oz95fbIjxNH4Fv0R iEm/SAtMUfCld4fCdmSii+tMVdhUq0uP9AUxSxQodxP5KeJPcgx8CGxaLmu0 tD+wqufF6aP1pQ8yv3G7/VGpbeP8r+ttKsYu3AdvBWjuEulkj+GCHEpPd4Dx jzZUD0ubm17AwnlyBqQALAQxwoaWRFijAd8vMYavM2L50c726PSwSzgB5Obo 6t1HUeso7REHPrlkwezyOL3FCHdScLmsZbD+yqV7tXZH7XjWto4stLywbQM1 aIsVZ25w5Hu1XTgiGIuJ5GWA44Jh3uX6oQHUZ4mDVESiXRCoqwORtQLnuwN/ P8pzOIRBy0Qx5o7vl1rhCBeVwTR0+xEgNUQMS61hd8s1rOeionzhMUkE3wQ0 o5I2xnRnQzT7mHymBNnmPqDsy8iSdm3N3AhQY6c8lmyzFXqO4nhCedttSk4Q hndxkw0HsBfH6ResbFGdct+t1mdkb1wjOXxrtrz9GE0VfBtCNhh0MO/3ZThv 7rMq+8j4h4INGJCYYl306vf63FAx1f21YxulGyiurxPaLqABiv+gDdC64uTk vaJS9nL1Zq7GM0A45VLVG8SXUnig0V+hxCd6ZTix9hwIrb/EINd5RwrQMB1O NibuJrm4VnH58NSnZ9pGcc5yN1EMr3uzAW8W5h3svrvC3iFyFyXoOD3MsGzH QxuakyRHx29OhEbgW2heYMN8WdboccHId08ffGpzSDMSrdz5r0ipbbc6Xav9 NrWucm2vUoyAqGLE9fVd+p6pyeIkXLOWkrdeB5YWo4YQuaD4CUqZFwTAYiTK LBrmH2PLhkPAXlpUhaafcUAHPBjTMUV4xejmt3LtckhutwanIHv8WPhSIYdk kSegWYxy/dPdJLIBsOFttRarDijFtjdss1WppOAiFufOS9gnM+66rn1IBXMh oqUlEBD2ayW+xNH1hk/XeyFjyLOqHYMEvO8BpaSYNtL+Vl7TrjD8+3U6S5di +nWVkGYy+5zOFr1ay8G5Cvf+9IYvSvAFxdzZFZDFpMBLECkH6LJRjqbvxouB LZADxbSD+ZOUdNCDi+MY9rKTvQOg8TPFLkbelPGci/RrP50W4sPR4S9H7951 8QvqNEjnDt/PD87oGDDz09QXg1E9NkL87Ir+yN2kb240HRiXLkgRne3AN/Ae VX0w/Wx8a7UoC3Zj6jGoN+rln9ty6HDy1yhJ+po6BXHijhhollKYEiii9oY1 TZu8VMKFiMz77IrirMjgnBy29dXpR1reuAxgTeQo0Jl8gVNLNtUV2x/fiRcv cOV4oWvy0ZRkBHB1mcySDNhH3NZYrjRPlILRMJQ4WA8U8wd11bmVwGhWBstd 2Rku2YAyVl9FSDJfshRAEB4d75+TvWL5tdQVRS0MQlUoC4iNFSgzzQb2+oKf xqFVl4uKAJUthLAnDhdXaGaPg54gDLpO+yzAD+bSCObYCAjUkoTwzI0mpAFr l/VfFp5HF85elhRekm74L9oggPn46PiQbWGUcc1hKg9dpEuwDIlBWV/H1dQb 3ymzmpiXDfp1WQLvkCN+lT+UNPRRdNzmuniUPEwc56+pGGafaafAlO6EnAww 8oUYYQhhIGETcQVHv6wwQS1ADtfvbCZyYO1SLV4gOZNPL9esE1kyG5pNLxV+ GaDH5uhsyyf66CzvSjhF2X2o5cbza4WG5iY99sHJRj7+Uw3sBYQIpcbw8CSY /oy3A5KAUktdkWYIZTG40SRMtozyDT5YeAlRgDmy8bdkRugHszyd5HBpWOaw WCggucmjq05mstO0QFikBa97FSxLDEAwNwzXn/ZTWDp4I5yhXWnO8ZLT2QgD aKTARszQ4qsq9Ws8JCKtCW/YRNlKIgKVOCJOCVuR9pCEOs0ZK4k4wY02xsTV bc9SLMTbVVRZN11TmmGE13Uo9UrO+mgk1kYLobIWqhRuqhkfvrXaJ3l7o/Z9 ADXrhlnIjRp9SK2Fq9qIJwnRyVIiLKudSlHlDmnKxprtGVH3yAqOxkc+27WO EudWJ2KhB2S6LM8KQaeCiYZZUx8jwyjvVesb3RysmcVVl2om1j1jfzDIOY+F 6KH/DmwTvHHIyW+IJd8+RKZOw4O0Wi1VGW5WqJB7s1t5alTjxpFBTa9kL00C Hir7kF4u07GgPt5azSHjEBzbOuyID/9efllGDhKSd8npxw9v22b5hEJ7lifC Xr/mDupakFRgWD0sGUDeWiEShzBbleKFVYGUoCZo92Ml3PuG+zBTsopfMUGN Egp+0QlUSFmDEQ1FjmKK3lAoPZ/MbdJmU+yq3D5vjo5fdzq+cJIsKJbY9+rz iER/7aDTJqKIPYfZwSpiEPkomx8SmDJyvT94X8cvXaZszOzUnuWBRdzevBgA ewKdCf/+7uA4MHbPBX9O2bFycwmEbcps4TVHdlQ/k0GwOCvxoGCGxkXhFqXA FVuj9KPhYgGXBustBgiiCERbX7fY1xdlzTLjNXlgbpCnNknI8FVK6bAxpuYs mMRDtvlUthnu1Y4wtCf+Rv3mmPQMYzlGWrUD/mCdWBkV82ZuGdVOqRBm/pQm 9e750xVPQ/k+1SU701r75XFabK7km5Qp00n/ps3qwltFMzQ6B0pWyeHG05o4 reBNCTAXIdrqQ5oQcpCIlYilz1OfUIxw8uUlwwYRyvhngLb1HDWYMbPqR1ZD TSDS741RtS0dS1Y4EeRlLqh35snUEL4NaDyzSAOaCsig4WFvQGARMqEk6hzh WXAJm2qUQ9uvRw/nVESnT7QSQDHoaoedaCJTKrMvmJsvaJ0Ty3URXqVWKiTJ aWCkhMqEOCXe4j7KKKvT1+aV5fjt03jOWWxbXrv5DquyJ/smQeqdbWdeQo9h fwuVea0e0zs3Wac9NG20Uy5Wsr/xYF/KyCqnKTd1BLicrBAljItA2TaiYmi8 RCLcgIs957Yp97gkBhecnwoTAI6hNRpsr4923vMWX9Tm2We7/SUXNf6KDJur 0T3STVirc3s3GqazOmO5vSuZPXl9cPg9T0D9KGwFGZ6gzEPA4WO6iJkfNJVG xX31NSPCNFoTlVxiEecS5Yxs+T670rnbzxP/s/B/nBUkGJc3LyXHJm0PqXpK 60IxCUUNJkEJCSwFy5xTtKg4RRk11afnAqdmET81+bQMCYznb6Si8lRUbkLO yVhUn4hKu+eeikXFaejco41hY4yql+0slT3mZ7RVV+4oJuRJSO3YFfp1weGn hHj17uT4IHnzQfxDfT16d2B+fTg6fLuPIcZecKwDH4lu7x3JBJIcFleq1Hvw uu1YCT23bGkHm8bm5t7pG8m6cg9bu5rIZOmc2V6WW1z2Ebokd6HMzE5G3PLc j7UvU6Yt5SnUhKWkYLk+NgOYmWkRlXZZ3tV2f6Zd28zVyQEsR5ORxeZeZpnb Bo9O1/B5UdBU2L47HahZ70lXbtVGVGxkvIvKWgivp1/3z1BnAyfX7E5G9Jee VT3tVqUZvq6R8WaUXjdC5yttAMq0Q39Bk4IsX+/pNLSB9JvfPwWsHiaKdfbH AxWhoryZeHDh/ePIx+wZc5JbTEyIxO8SOc38Li/Ybj/ET+nxNjFNdyuFDNTZ oi6AqJjvaULnKQk78FwlV0gt7WTDCbnYZBQte+KjCfkN0mh+o6D0ZBtRylqi TMbKiUW0W2iEU7mb3MwwneZ1NkZRXJpztmhUciHpxkVMLSprN22c5x92pDex z25MH2/PRfEI9pwMnzC96gPeXF7BVh1zpUo2wW04wip4DTXg6WpwDfYIFuNg veHJY/xyQs5z4rHivSfTPAobfeCrQ4PM1K5gd6WoomTaRUpDk0KZ05CzbdJM lk3020SlMm+rAbi5za2pynQ5zCtu7dJR/EIcn6FNwgdBv1XuHPL+vLi5/O3p 1qddpXN7BAWSCTlFYCMdinJkvL2i0iloB9bSZx7eIFnJtN1HCbuhax1Vd8uX YggYrwjfMydJ4PZSsOATqNTN1DiVR0MFhK1RtCmK6opCCE2mpMzT1B0ddo08 XI/Kv4i7nFtopdf3w45AUb73Xahtq5lSVeZYRCEZFWeIUSlA7dAFQXciCis4 Xp9Zu4A9omkfII0L7oSb8UJ7ofmxVT6IXFrmHUO4R00FSWfRDVzWooNGHjjw Rj7FNdo2axQH+v7k9cd3B8n+x/O3J2ft5bPJBYahOhkCZzEWL2b0c2NCP/8l K/KNm5uNPEXyLyu+Pvjw6uzo9Pzo5Li9fEoW3OIwHadwJqFH62QytAqf7p+9 bxtxPmzXLPCWNAKRd5ZaIVRikF7cXHkv3h29Ojj+cNBePjx9h4/x89/Krkoq WyUBAA== --Qbhptji31K Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Includes old work from pg3, pg4 and work from Alexey, Ben, and collegue Jens plus others. FYI. We used the precessor pg4 injecting 5 Gbit/s as background load for tests GIGE switches... This should do better. Bug fixes are more appreciated than feature updates yet... Cheers. --ro --Qbhptji31K-- From davem@redhat.com Tue Nov 26 02:14:30 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Nov 2002 02:14:33 -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 gAQAEUuR025253 for ; Tue, 26 Nov 2002 02:14:30 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id CAA03035; Tue, 26 Nov 2002 02:15:46 -0800 Date: Tue, 26 Nov 2002 02:15:46 -0800 (PST) Message-Id: <20021126.021546.91313706.davem@redhat.com> To: srompf@isg.de Cc: netdev@oss.sgi.com Subject: Re: Patch resubmission: RFC2863 operstatus for 2.5.49 From: "David S. Miller" In-Reply-To: <3DE33D6D.25B9C9B4@isg.de> References: <3DE33D6D.25B9C9B4@isg.de> 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: 1241 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 locking below achieves nothing. + read_lock_irqsave(&dev->operstate_lock, flags); + state = dev->operstate; + read_unlock_irqrestore(&dev->operstate_lock, flags); In fact, the other side, locking when setting this value, can be done with a simple spinlock. Probably something else in the device struct can be reused. I also don't think this should be conditional, either we want it or we don't. From srompf@isg.de Tue Nov 26 07:34:07 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Nov 2002 07:34:12 -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 gAQFY6uR031603 for ; Tue, 26 Nov 2002 07:34:07 -0800 Received: from barkeeper.isg.de (barkeeper.is-asp.com [192.168.5.46]) by mail.isg.de (Postfix) with ESMTP id 0DAD4CBB030; Tue, 26 Nov 2002 16:36:36 +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 QAA07571; Tue, 26 Nov 2002 16:36:35 +0100 Message-ID: <3DE39503.4A24DCB2@isg.de> Date: Tue, 26 Nov 2002 16:36:35 +0100 From: Stefan Rompf X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.20rc1-sr i686) X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: Patch resubmission: RFC2863 operstatus for 2.5.49 References: <3DE33D6D.25B9C9B4@isg.de> <20021126.021546.91313706.davem@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1242 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 Hi, > This locking below achieves nothing. Ok, so I was too cautious by locking read access to a one byte structure. I'll change that and read additional documentation on SMP ;-) > Probably something else in > the device struct can be reused. Right now, I don't see which. There are other spinlocks available in the net_device structure, but they are used by the queuing code and we should not give up the semantic that netif_set_operstate() can be called from everywhere. One global spinlock may be acceptable for this special case. > I also don't think this should be conditional, either we want > it or we don't. The conditional stuff is inspired from my first 2.4 version, but I'm happy to remove it. Btw, can you also have a look the 2.4 backport of my link state notification feature (posting available under http://marc.theaimsgroup.com/?l=linux-netdev&m=103722967214290&w=2, just one typo fixed in Configure.help since then). Is this stuff acceptable for 2.4? Cheers, Stefan From pb@bieringer.de Tue Nov 26 11:06:09 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Nov 2002 11:06:12 -0800 (PST) Received: from smtp2.aerasec.de (gromit.aerasec.de [195.226.187.57]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAQJ68uR001528 for ; Tue, 26 Nov 2002 11:06:08 -0800 Received: from localhost (localhost [127.0.0.1]) by smtp2.aerasec.de (Postfix) with SMTP id 2562E13861; Tue, 26 Nov 2002 20:08:42 +0100 (CET) X-AV-Checked: Tue Nov 26 20:08:42 2002 smtp2.aerasec.de Received: from [192.168.1.2] (pD950FCED.dip.t-dialin.net [217.80.252.237]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by smtp2.aerasec.de (Postfix) with ESMTP id B799713860; Tue, 26 Nov 2002 20:08:39 +0100 (CET) Date: Tue, 26 Nov 2002 20:08:36 +0100 From: Peter Bieringer To: netdev@oss.sgi.com Cc: Zheng Jianping Subject: Re: How to get IPv6 interface? Message-ID: <55380000.1038337716@worker.muc.bieringer.de> In-Reply-To: <003201c29525$cd933360$6c06a8c0@zhengjp> References: <003201c29525$cd933360$6c06a8c0@zhengjp> X-Mailer: Mulberry/3.0.0a5 (Linux/x86) X-URL: http://www.bieringer.de/pb/ X-OS: Linux MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========903190887==========" X-archive-position: 1243 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pb@bieringer.de Precedence: bulk X-list: netdev --==========903190887========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline --On Tuesday, November 26, 2002 04:28:31 PM +0800 Zheng Jianping wrote: > My linux kernel is 2.4.7.10, how to get the information of all IPv6 > interfaces, including the interfaces index, flags,name and > address,etc ? Userspace: ip -6 addr Peter --- Dr. Peter Bieringer mailto: pb at bieringer dot de http://www.bieringer.de/pb/ Key 0x958F422D : B501 24F4 9418 23E2 C0F3 F833 7B57 AA7B 958F 422D --==========903190887========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE948a2e1eqe5WPQi0RAn3eAJ98CB5Dk1YrxJ1NyZSk/k8tKrelJQCfaQZ+ xalwM92/OLMAt4Gjq2GSVY8= =bXez -----END PGP SIGNATURE----- --==========903190887==========-- From jgarzik@pobox.com Tue Nov 26 15:39:49 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Nov 2002 15:39:55 -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 gAQNdluR004394 for ; Tue, 26 Nov 2002 15:39:48 -0800 Received: from rdu74-162-040.nc.rr.com ([24.74.162.40] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 18GpLS-0005jc-00; Tue, 26 Nov 2002 23:42:23 +0000 Message-ID: <3DE406AE.2000908@pobox.com> Date: Tue, 26 Nov 2002 18:41:34 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021018 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com, "David S. Miller" CC: Alexey Kuznetsov Subject: [PATCH] tg3 locking update (with NAPI overtones) Content-Type: multipart/mixed; boundary="------------060406020603000809040809" X-archive-position: 1244 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 This is a multi-part message in MIME format. --------------060406020603000809040809 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The attached patch is based on tg3.c as found in 2.4.20-rc3 or the latest Linus 2.5.x kernel, and originates from two motivations: * When net drivers move TX completion from interrupt to dev->poll(), this allows the rethinking of some traditional locking, namely eliminating a lock in dev->start_xmit() that most drivers implement these days. * Specific to the tg3 implementation, spin-lock-irq is held during NIC hardware halt and re-initialization (and a few other operations). In general a goal is to change this; the driver may wind up holding interrupts disabled for longer than prudence dictates. The attached patch does not address this issue directly, but it does begin to lay the groundwork for my upcoming solution :) I mention "NAPI" in the subject because other NAPI drivers may wish to re-examine their locking as well, and this patch could serve as a basis for discussion. Overall, I believe the attached patch (after testing/debugging/review) will make the tg3 driver faster due to less locking in dev->start_xmit, and more friendly system interaction because interrupts are being disabled->enabled less frequently by this driver. Here is a function-by-function description of changes, which gives one a better idea of the locking changes that may be a found in a driver: all functions: s/spin_lock_irq/spin_lock_irqsave/ to be more conservative and "obviously safe" all functions: locking ordering now reversed: dev->xmit_lock obtained before tp->lock. tg3_set_power_state: Do not call tg3_halt(), the one case where this code path is hit, the caller has already called tg3_halt() tg3_poll: hold dev->xmit_lock when checking for TX work, and running TX completion cycle. tp->tx_lock GC'd. tg3_tx_timeout: net stack already holds dev->xmit_lock. tx_lock GC'd. tg3_{4gbug}_start_xmit: net stack already holds dev->xmit_lock, no other locks needed (whee!), so: tp->lock GC'd. tg3_change_mtu: get dev->xmit_lock instead of tp->tx_lock. wrap locking in netif_start_queue ... netif_wake_queue. tg3_timer: get xmit_lock instead of tx_lock. wrap NIC reset in netif_start_queue ... netif_wake_queue. tg3_open: no need for tx locking, just move netif_start_queue down to the bottom of the function. tg3_close: s/tp->tx_lock/dev->xmit_lock/ tg3_get_regs: likewise tg3_ethtool_ioctl: likewise, plus netif_{start,wake}_queue wrap around NIC reset tg3_vlan_rx_register: remove TX lock tg3_vlan_rx_kill_vid: remove TX lock tg3_suspend: s/tp->tx_lock/dev->xmit_lock/, netif_{start,wake}_queue wrap tg3_resume: likewise Th-th-th-th-that's all, folks! Questions/comments/flames requested. --------------060406020603000809040809 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" diff -Nru a/drivers/net/tg3.c b/drivers/net/tg3.c --- a/drivers/net/tg3.c Tue Nov 26 18:05:17 2002 +++ b/drivers/net/tg3.c Tue Nov 26 18:05:17 2002 @@ -63,7 +63,7 @@ #define DRV_MODULE_NAME "tg3" #define PFX DRV_MODULE_NAME ": " -#define DRV_MODULE_VERSION "1.2" +#define DRV_MODULE_VERSION "1.2txlock" #define DRV_MODULE_RELDATE "Nov 14, 2002" #define TG3_DEF_MAC_MODE 0 @@ -416,7 +416,6 @@ } static int tg3_setup_phy(struct tg3 *); -static int tg3_halt(struct tg3 *); static int tg3_set_power_state(struct tg3 *tp, int state) { @@ -487,8 +486,6 @@ tg3_setup_phy(tp); } - tg3_halt(tp); - pci_read_config_word(tp->pdev, pm + PCI_PM_PMC, &power_caps); if (tp->tg3_flags & TG3_FLAG_WOL_ENABLE) { @@ -2073,8 +2070,14 @@ struct tg3 *tp = netdev->priv; struct tg3_hw_status *sblk = tp->hw_status; int done; + unsigned long flags; - spin_lock_irq(&tp->lock); + spin_lock(&tp->dev->xmit_lock); + if (sblk->idx[0].tx_consumer != tp->tx_cons) + tg3_tx(tp); + spin_unlock(&tp->dev->xmit_lock); + + spin_lock_irqsave(&tp->lock, flags); if (!(tp->tg3_flags & (TG3_FLAG_USE_LINKCHG_REG | @@ -2086,12 +2089,6 @@ } } - if (sblk->idx[0].tx_consumer != tp->tx_cons) { - spin_lock(&tp->tx_lock); - tg3_tx(tp); - spin_unlock(&tp->tx_lock); - } - done = 1; if (sblk->idx[0].rx_producer != tp->rx_rcb_ptr) { int orig_budget = *budget; @@ -2114,7 +2111,7 @@ tg3_unmask_ints(tp); } - spin_unlock_irq(&tp->lock); + spin_unlock_irqrestore(&tp->lock, flags); return (done ? 0 : 1); } @@ -2175,23 +2172,23 @@ static void tg3_init_rings(struct tg3 *); static int tg3_init_hw(struct tg3 *); +static int tg3_halt(struct tg3 *tp); static void tg3_tx_timeout(struct net_device *dev) { struct tg3 *tp = dev->priv; + unsigned long flags; printk(KERN_ERR PFX "%s: transmit timed out, resetting\n", dev->name); - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + spin_lock_irqsave(&tp->lock, flags); tg3_halt(tp); tg3_init_rings(tp); tg3_init_hw(tp); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + spin_unlock_irqrestore(&tp->lock, flags); netif_wake_queue(dev); } @@ -2371,35 +2368,12 @@ unsigned int i; u32 len, entry, base_flags, mss; int would_hit_hwbug; - unsigned long flags; len = (skb->len - skb->data_len); - /* No BH disabling for tx_lock here. We are running in BH disabled - * context and TX reclaim runs via tp->poll inside of a software - * interrupt. Rejoice! - * - * Actually, things are not so simple. If we are to take a hw - * IRQ here, we can deadlock, consider: - * - * CPU1 CPU2 - * tg3_start_xmit - * take tp->tx_lock - * tg3_timer - * take tp->lock - * tg3_interrupt - * spin on tp->lock - * spin on tp->tx_lock - * - * So we really do need to disable interrupts when taking - * tx_lock here. - */ - spin_lock_irqsave(&tp->tx_lock, flags); - /* This is a hard error, log it. */ if (unlikely(TX_BUFFS_AVAIL(tp) <= (skb_shinfo(skb)->nr_frags + 1))) { netif_stop_queue(dev); - spin_unlock_irqrestore(&tp->tx_lock, flags); printk(KERN_ERR PFX "%s: BUG! Tx Ring full when queue awake!\n", dev->name); return 1; @@ -2551,8 +2525,6 @@ netif_stop_queue(dev); out_unlock: - spin_unlock_irqrestore(&tp->tx_lock, flags); - dev->trans_start = jiffies; return 0; @@ -2563,35 +2535,12 @@ struct tg3 *tp = dev->priv; dma_addr_t mapping; u32 len, entry, base_flags, mss; - unsigned long flags; len = (skb->len - skb->data_len); - /* No BH disabling for tx_lock here. We are running in BH disabled - * context and TX reclaim runs via tp->poll inside of a software - * interrupt. Rejoice! - * - * Actually, things are not so simple. If we are to take a hw - * IRQ here, we can deadlock, consider: - * - * CPU1 CPU2 - * tg3_start_xmit - * take tp->tx_lock - * tg3_timer - * take tp->lock - * tg3_interrupt - * spin on tp->lock - * spin on tp->tx_lock - * - * So we really do need to disable interrupts when taking - * tx_lock here. - */ - spin_lock_irqsave(&tp->tx_lock, flags); - /* This is a hard error, log it. */ if (unlikely(TX_BUFFS_AVAIL(tp) <= (skb_shinfo(skb)->nr_frags + 1))) { netif_stop_queue(dev); - spin_unlock_irqrestore(&tp->tx_lock, flags); printk(KERN_ERR PFX "%s: BUG! Tx Ring full when queue awake!\n", dev->name); return 1; @@ -2697,8 +2646,6 @@ if (TX_BUFFS_AVAIL(tp) <= (MAX_SKB_FRAGS + 1)) netif_stop_queue(dev); - spin_unlock_irqrestore(&tp->tx_lock, flags); - dev->trans_start = jiffies; return 0; @@ -2707,6 +2654,7 @@ static int tg3_change_mtu(struct net_device *dev, int new_mtu) { struct tg3 *tp = dev->priv; + unsigned long flags; if (new_mtu < TG3_MIN_MTU || new_mtu > TG3_MAX_MTU) return -EINVAL; @@ -2719,8 +2667,9 @@ return 0; } - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + netif_stop_queue(tp->dev); + spin_lock_bh(&tp->dev->xmit_lock); + spin_lock_irqsave(&tp->lock, flags); tg3_halt(tp); @@ -2734,8 +2683,10 @@ tg3_init_rings(tp); tg3_init_hw(tp); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + spin_unlock_irqrestore(&tp->lock, flags); + spin_unlock_bh(&tp->dev->xmit_lock); + + netif_wake_queue(tp->dev); return 0; } @@ -4500,9 +4451,10 @@ static void tg3_timer(unsigned long __opaque) { struct tg3 *tp = (struct tg3 *) __opaque; + unsigned long flags; - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + spin_lock(&tp->dev->xmit_lock); + spin_lock_irqsave(&tp->lock, flags); /* All of this garbage is because when using non-tagged * IRQ status the mailbox/status_block protocol the chip @@ -4517,9 +4469,11 @@ } if (!(tr32(WDMAC_MODE) & WDMAC_MODE_ENABLE)) { + netif_stop_queue(tp->dev); tg3_halt(tp); tg3_init_rings(tp); tg3_init_hw(tp); + netif_wake_queue(tp->dev); } /* This part only runs once per second. */ @@ -4582,8 +4536,8 @@ tp->asf_counter = tp->asf_multiplier; } - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + spin_unlock_irqrestore(&tp->lock, flags); + spin_unlock(&tp->dev->xmit_lock); tp->timer.expires = jiffies + tp->timer_offset; add_timer(&tp->timer); @@ -4593,15 +4547,14 @@ { struct tg3 *tp = dev->priv; int err; + unsigned long flags; - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + spin_lock_irqsave(&tp->lock, flags); tg3_disable_ints(tp); tp->tg3_flags &= ~TG3_FLAG_INIT_COMPLETE; - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + spin_unlock_irqrestore(&tp->lock, flags); /* If you move this call, make sure TG3_FLAG_HOST_TXDS in * tp->tg3_flags is accurate at that new place. @@ -4618,8 +4571,7 @@ return err; } - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + spin_lock_irqsave(&tp->lock, flags); tg3_init_rings(tp); @@ -4641,8 +4593,7 @@ tp->tg3_flags |= TG3_FLAG_INIT_COMPLETE; } - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + spin_unlock_irqrestore(&tp->lock, flags); if (err) { free_irq(dev->irq, dev); @@ -4650,15 +4601,13 @@ return err; } - netif_start_queue(dev); - - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + spin_lock_irqsave(&tp->lock, flags); tg3_enable_ints(tp); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + spin_unlock_irqrestore(&tp->lock, flags); + + netif_start_queue(dev); return 0; } @@ -4913,13 +4862,14 @@ static int tg3_close(struct net_device *dev) { struct tg3 *tp = dev->priv; + unsigned long flags; netif_stop_queue(dev); del_timer_sync(&tp->timer); - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + spin_lock_bh(&tp->dev->xmit_lock); + spin_lock_irqsave(&tp->lock, flags); #if 0 tg3_dump_state(tp); #endif @@ -4933,8 +4883,8 @@ TG3_FLAG_GOT_SERDES_FLOWCTL); netif_carrier_off(tp->dev); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + spin_unlock_irqrestore(&tp->lock, flags); + spin_unlock_bh(&tp->dev->xmit_lock); free_irq(dev->irq, dev); @@ -5143,6 +5093,7 @@ static u8 *tg3_get_regs(struct tg3 *tp) { + unsigned long flags; u8 *orig_p = kmalloc(TG3_REGDUMP_LEN, GFP_KERNEL); u8 *p; int i; @@ -5152,8 +5103,8 @@ memset(orig_p, 0, TG3_REGDUMP_LEN); - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + spin_lock_bh(&tp->dev->xmit_lock); + spin_lock_irqsave(&tp->lock, flags); #define __GET_REG32(reg) (*((u32 *)(p))++ = tr32(reg)) #define GET_REG32_LOOP(base,len) \ @@ -5202,8 +5153,8 @@ #undef GET_REG32_LOOP #undef GET_REG32_1 - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + spin_unlock_irqrestore(&tp->lock, flags); + spin_unlock_bh(&tp->dev->xmit_lock); return orig_p; } @@ -5213,6 +5164,7 @@ struct tg3 *tp = dev->priv; struct pci_dev *pci_dev = tp->pdev; u32 ethcmd; + unsigned long flags; if (copy_from_user (ðcmd, useraddr, sizeof (ethcmd))) return -EFAULT; @@ -5300,8 +5252,7 @@ return -EINVAL; } - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + spin_lock_irqsave(&tp->lock, flags); tp->link_config.autoneg = cmd.autoneg; if (cmd.autoneg == AUTONEG_ENABLE) { @@ -5314,8 +5265,7 @@ } tg3_setup_phy(tp); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + spin_unlock_irqrestore(&tp->lock, flags); return 0; } @@ -5453,8 +5403,9 @@ (ering.tx_pending > TG3_TX_RING_SIZE - 1)) return -EINVAL; - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + netif_stop_queue(tp->dev); + spin_lock_bh(&tp->dev->xmit_lock); + spin_lock_irqsave(&tp->lock, flags); tp->rx_pending = ering.rx_pending; #if TG3_MINI_RING_WORKS @@ -5466,9 +5417,9 @@ tg3_halt(tp); tg3_init_rings(tp); tg3_init_hw(tp); + spin_unlock_irqrestore(&tp->lock, flags); + spin_unlock_bh(&tp->dev->xmit_lock); netif_wake_queue(tp->dev); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); return 0; } @@ -5491,8 +5442,9 @@ if (copy_from_user(&epause, useraddr, sizeof(epause))) return -EFAULT; - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + netif_stop_queue(tp->dev); + spin_lock_bh(&tp->dev->xmit_lock); + spin_lock_irqsave(&tp->lock, flags); if (epause.autoneg) tp->tg3_flags |= TG3_FLAG_PAUSE_AUTONEG; else @@ -5508,8 +5460,9 @@ tg3_halt(tp); tg3_init_rings(tp); tg3_init_hw(tp); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + spin_unlock_irqrestore(&tp->lock, flags); + spin_unlock_bh(&tp->dev->xmit_lock); + netif_wake_queue(tp->dev); return 0; } @@ -5644,29 +5597,27 @@ static void tg3_vlan_rx_register(struct net_device *dev, struct vlan_group *grp) { struct tg3 *tp = dev->priv; + unsigned long flags; - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + spin_lock_irqsave(&tp->lock, flags); tp->vlgrp = grp; /* Update RX_MODE_KEEP_VLAN_TAG bit in RX_MODE register. */ __tg3_set_rx_mode(dev); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + spin_unlock_irqrestore(&tp->lock, flags); } static void tg3_vlan_rx_kill_vid(struct net_device *dev, unsigned short vid) { struct tg3 *tp = dev->priv; + unsigned long flags; - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + spin_lock_irqsave(&tp->lock, flags); if (tp->vlgrp) tp->vlgrp->vlan_devices[vid] = NULL; - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + spin_unlock_irqrestore(&tp->lock, flags); } #endif @@ -6852,7 +6803,6 @@ tp->grc_mode |= GRC_MODE_BSWAP_NONFRM_DATA; #endif spin_lock_init(&tp->lock); - spin_lock_init(&tp->tx_lock); spin_lock_init(&tp->indirect_lock); tp->regs = (unsigned long) ioremap(tg3reg_base, tg3reg_len); @@ -6994,36 +6944,37 @@ struct net_device *dev = pci_get_drvdata(pdev); struct tg3 *tp = dev->priv; int err; + unsigned long flags; if (!netif_running(dev)) return 0; - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + spin_lock_irqsave(&tp->lock, flags); tg3_disable_ints(tp); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + spin_unlock_irqrestore(&tp->lock, flags); netif_device_detach(dev); - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + spin_lock_bh(&dev->xmit_lock); + spin_lock_irqsave(&tp->lock, flags); tg3_halt(tp); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + spin_unlock_irqrestore(&tp->lock, flags); + spin_unlock_bh(&dev->xmit_lock); err = tg3_set_power_state(tp, state); if (err) { - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + spin_lock_bh(&dev->xmit_lock); + spin_lock_irqsave(&tp->lock, flags); tg3_init_rings(tp); tg3_init_hw(tp); + tg3_enable_ints(tp); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + spin_unlock_irqrestore(&tp->lock, flags); + spin_unlock_bh(&dev->xmit_lock); netif_device_attach(dev); + netif_wake_queue(dev); } return err; @@ -7034,6 +6985,7 @@ struct net_device *dev = pci_get_drvdata(pdev); struct tg3 *tp = dev->priv; int err; + unsigned long flags; if (!netif_running(dev)) return 0; @@ -7042,17 +6994,18 @@ if (err) return err; - netif_device_attach(dev); - - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + spin_lock_bh(&tp->dev->xmit_lock); + spin_lock_irqsave(&tp->lock, flags); tg3_init_rings(tp); tg3_init_hw(tp); tg3_enable_ints(tp); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + spin_unlock_irqrestore(&tp->lock, flags); + spin_unlock_bh(&tp->dev->xmit_lock); + + netif_device_attach(dev); + netif_wake_queue(dev); return 0; } diff -Nru a/drivers/net/tg3.h b/drivers/net/tg3.h --- a/drivers/net/tg3.h Tue Nov 26 18:05:17 2002 +++ b/drivers/net/tg3.h Tue Nov 26 18:05:17 2002 @@ -1733,15 +1733,17 @@ * lock: Held during all operations except TX packet * processing. * - * tx_lock: Held during tg3_start_xmit{,_4gbug} and tg3_tx + * dev->xmit_lock: Held in tg3_tx, and by upper layer during + * tg3_start_xmit{,_4gbug}, plus assorted driver areas + * that happen to relate to the TX engine. * * If you want to shut up all asynchronous processing you must - * acquire both locks, 'lock' taken before 'tx_lock'. IRQs must - * be disabled to take 'lock' but only softirq disabling is - * necessary for acquisition of 'tx_lock'. + * acquire both locks, 'xmit_lock' taken before 'lock'. xmit_lock + * is often acquired by the upper layers, so pay attention. IRQs must + * be disabled to take 'lock' but only softirq/BH disabling is + * necessary for acquisition of 'xmit_lock'. */ spinlock_t lock; - spinlock_t tx_lock; u32 tx_prod; u32 tx_cons; --------------060406020603000809040809-- From davem@redhat.com Tue Nov 26 15:50:30 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Nov 2002 15:50:32 -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 gAQNoUuR004856 for ; Tue, 26 Nov 2002 15:50:30 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id PAA16343; Tue, 26 Nov 2002 15:51:44 -0800 Date: Tue, 26 Nov 2002 15:51:44 -0800 (PST) Message-Id: <20021126.155144.43008660.davem@redhat.com> To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH] tg3 locking update (with NAPI overtones) From: "David S. Miller" In-Reply-To: <3DE406AE.2000908@pobox.com> References: <3DE406AE.2000908@pobox.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: 1245 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 Looks good to me on first glance, testing will confirm further :-) Probably, to kill the long delays with locks held, we just need to add a PHY config semaphore. Interrupts that want to try and program the PHY just do a down_trylock() on that semaphore and defer their work if it cannot be acquired. From jgarzik@pobox.com Tue Nov 26 15:56:34 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Nov 2002 15:56:35 -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 gAQNuWuR005267 for ; Tue, 26 Nov 2002 15:56:33 -0800 Received: from rdu74-162-040.nc.rr.com ([24.74.162.40] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 18Gpbg-00061L-00; Tue, 26 Nov 2002 23:59:08 +0000 Message-ID: <3DE40A9C.8070109@pobox.com> Date: Tue, 26 Nov 2002 18:58:20 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021018 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: "David S. Miller" Subject: [PATCH] tg3 PXE-related fix Content-Type: multipart/mixed; boundary="------------090203060400040805000308" X-archive-position: 1246 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 This is a multi-part message in MIME format. --------------090203060400040805000308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks to Manish Lachwani for isolating the area for this fix, which will get checked in soon after some more testing. Fix originated from the Broadcom driver, via Manish's kind help. Posted mainly in case other netdev'izens with BCM5704 A0 chips are running into this. Patch against 2.4.20-rc[34]'s tg3.c, a.k.a. version 1.2. --------------090203060400040805000308 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" diff -Nru a/drivers/net/tg3.c b/drivers/net/tg3.c --- a/drivers/net/tg3.c Mon Nov 25 18:53:36 2002 +++ b/drivers/net/tg3.c Mon Nov 25 18:53:36 2002 @@ -6182,6 +6182,13 @@ if ((pci_state_reg & PCISTATE_BUS_32BIT) != 0) tp->tg3_flags |= TG3_FLAG_PCI_32BIT; + /* Chip-specific fixup from Broadcom driver */ + if ((tp->pci_chip_rev_id == CHIPREV_ID_5704_A0) && + (!(pci_state_reg & PCISTATE_RETRY_SAME_DMA))) { + pci_state_reg |= PCISTATE_RETRY_SAME_DMA; + pci_write_config_dword(tp->pdev, TG3PCI_PCISTATE, pci_state_reg); + } + /* Force the chip into D0. */ err = tg3_set_power_state(tp, 0); if (err) --------------090203060400040805000308-- From jgarzik@pobox.com Tue Nov 26 18:15:04 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Nov 2002 18:15:08 -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 gAR2F3uR007330 for ; Tue, 26 Nov 2002 18:15:04 -0800 Received: from rdu74-162-040.nc.rr.com ([24.74.162.40] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 18GqSn-0006aD-00; Wed, 27 Nov 2002 00:54:01 +0000 Message-ID: <3DE41779.9030804@pobox.com> Date: Tue, 26 Nov 2002 19:53:13 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021018 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH] tg3 locking update (with NAPI overtones) References: <3DE406AE.2000908@pobox.com> <20021126.155144.43008660.davem@redhat.com> In-Reply-To: <3DE406AE.2000908@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1247 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 David S. Miller wrote: > Looks good to me on first glance, testing will confirm > further :-) yeppers :) > Probably, to kill the long delays with locks held, we just > need to add a PHY config semaphore. Interrupts that want to > try and program the PHY just do a down_trylock() on that semaphore > and defer their work if it cannot be acquired. I was thinking along similar lines, and you just gave me an idea as well :) Hopefully I can present a patch later on tonight showing these ideas. For now, just responding to the above, I think there are further needs: even if you acquire that semaphore, you can still wind up a full tg3_halt + tg3_init_hw in interrupt context, which means you could be there a while. MAC/firmware init can be expensive, even ignoring the phy init. Also consider the general argument that once you are resetting the MAC or phy, you aren't really doing useful RX/TX work; you can concentrate on making the slow path simple and safe while knowing that the fast path is idle. So... I prefer to simply always defer MAC/phy reset if in interrupt context. This allows us to sleep as long as we want during phy and MAC init. If the manual says "poll each block max of 2ms", we can do it easily with yield() in a loop or schedule_timeout(), the way God intended drivers to sleep :) Jeff From greearb@candelatech.com Tue Nov 26 23:39:27 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Nov 2002 23:39:31 -0800 (PST) Received: from grok.yi.org (IDENT:C/dRSTgei0613NQ9JaCVIYiMKfQnynhQ@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAR7dQuR010826 for ; Tue, 26 Nov 2002 23:39:26 -0800 Received: from candelatech.com (IDENT:VMl+6f22DQRRSRTeU8zPsp3AEQFMzJ7O@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id gAR7exq22653; Tue, 26 Nov 2002 23:40:59 -0800 Message-ID: <3DE4770B.3020701@candelatech.com> Date: Tue, 26 Nov 2002 23:40:59 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: netdev@oss.sgi.com Subject: Re: [PATCH] tg3 locking update (with NAPI overtones) References: <3DE406AE.2000908@pobox.com> <20021126.155144.43008660.davem@redhat.com> <3DE41779.9030804@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1248 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 Just out of curiosity, have any of you been able to reproduce any IRQ warnings under heavy loads with the tg3? If I start up all ports of a 4-port tulip nic and also start the tg3 (all running high speed), then I see a steady stream of complaints from the tg3.... At least one other person has seen the same and has emailed me about it... -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From Robert.Olsson@data.slu.se Wed Nov 27 10:10:04 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Nov 2002 10:10: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 gARIA2uR004769 for ; Wed, 27 Nov 2002 10:10:03 -0800 Received: (from robert@localhost) by robur.slu.se (8.9.3/8.9.3) id TAA11091; Wed, 27 Nov 2002 19:20:10 +0100 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15845.3290.483532.218491@robur.slu.se> Date: Wed, 27 Nov 2002 19:20:10 +0100 To: jamal Cc: Subject: Aggregated TX performance X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 1249 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 We discussed this. Below is a recent experiment... Aggregated TX performance test 2.5.47 SMP w. 2 x E1000 82546 (dual) 4.4.12-k1 + NAPI fixes for e1000 sent to lkml. SuperMicro 370 DL3 2x PIII @ 933 MHz. Setup. (w. pktgen) CPU0 transmitted on eth0 and eth1. CPU1 transmitted on eth2. 1) "Vanilla" setup no affinity and "full" kmalloc/kfree for each packet. 2) As 1. irq affinity were set so interrupt go to resp. CPU. 3) As 2. and pktgen used it's clone_skb behavior. In practice no kmalloc's and kfree just doing a decrement. Results in kpps. Setup 1 2 3 =============================== eth0 182 220 466 eth1 182 220 466 eth2 314 429 791 --- --- ---- Total 678 869 1723 Cheers. --ro From uol@uol.com.br Wed Nov 27 12:22:24 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Nov 2002 12:22:28 -0800 (PST) Received: from www3.infolink.com.br (pop.infolink.com.br [200.187.64.7]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gARKMMuR015008 for ; Wed, 27 Nov 2002 12:22:23 -0800 Received: from uol.com.br (unverified [200.196.48.4]) by www3.infolink.com.br (Vircom SMTPRS 5.1.202) with ESMTP id for ; Wed, 27 Nov 2002 18:24:49 -0200 Message-ID: From: "Universo Online" To: netdev@oss.sgi.com Subject: Assine UOL! Reply-To: "Universo Online" Date: 27 Nov 2002 17:24:51 -0300 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-archive-position: 1250 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: uol@uol.com.br Precedence: bulk X-list: netdev Assine UOL! Assine já o maior provedor da América Latina! O UOL têm planos super acessíveis para você e toda a sua família, a preços imbatíveis! Sem dúvida o melhor presente de natal que você podia esperar. Assine já! http://gasset.uol.com.br/pl_cad/deonde?cod_promo=0DM&origem_assinatura=Z PS: Clicando agora neste link você pode experimentar o UOL por um mês SEM PAGAR NADA!!! http://gasset.uol.com.br/pl_cad/deonde?cod_promo=0DM&origem_assinatura=Z -------------------------------------------------------- Isso não é SPAM. Você está recebendo essa mensagem por ter se cadastrado em um ou mais Boletins do UOL. From uol@uol.com.br Wed Nov 27 13:00:41 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Nov 2002 13:00:43 -0800 (PST) Received: from www3.infolink.com.br (pop.infolink.com.br [200.187.64.7]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gARL0cuS015645 for ; Wed, 27 Nov 2002 13:00:40 -0800 Received: from uol.com.br (unverified [200.196.48.4]) by www3.infolink.com.br (Vircom SMTPRS 5.1.202) with ESMTP id for ; Wed, 27 Nov 2002 19:03:08 -0200 Message-ID: From: "Universo Online" To: netdev@oss.sgi.com Subject: Assine UOL! Reply-To: "Universo Online" Date: 27 Nov 2002 18:03:10 -0300 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-archive-position: 1251 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: uol@uol.com.br Precedence: bulk X-list: netdev Assine UOL! Assine já o maior provedor da América Latina! O UOL têm planos super acessíveis para você e toda a sua família, a preços imbatíveis! Sem dúvida o melhor presente de natal que você podia esperar. Assine já! http://gasset.uol.com.br/pl_cad/deonde?cod_promo=0DM&origem_assinatura=Z PS: Clicando agora neste link você pode experimentar o UOL por um mês SEM PAGAR NADA!!! http://gasset.uol.com.br/pl_cad/deonde?cod_promo=0DM&origem_assinatura=Z -------------------------------------------------------- Isso não é SPAM. Você está recebendo essa mensagem por ter se cadastrado em um ou mais Boletins do UOL. From cobranca@uol.com.br Wed Nov 27 14:07:19 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Nov 2002 14:07:24 -0800 (PST) Received: from www3.infolink.com.br (pop.infolink.com.br [200.187.64.7]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gARM7HuR017430 for ; Wed, 27 Nov 2002 14:07:18 -0800 Received: from uol.com.br (unverified [200.196.48.4]) by www3.infolink.com.br (Vircom SMTPRS 5.1.202) with ESMTP id for ; Wed, 27 Nov 2002 20:09:43 -0200 Message-ID: From: "Universo Online" To: netdev@oss.sgi.com Subject: Assine UOL! Reply-To: "Universo Online" Date: 27 Nov 2002 19:09:46 -0300 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-archive-position: 1252 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cobranca@uol.com.br Precedence: bulk X-list: netdev Assine UOL! Assine já o maior provedor da América Latina! O UOL têm planos super acessíveis para você e toda a sua família, a preços imbatíveis! Sem dúvida o melhor presente de natal que você podia esperar. Assine já! http://gasset.uol.com.br/pl_cad/deonde?cod_promo=0DM&origem_assinatura=Z PS: Clicando agora neste link você pode experimentar o UOL por um mês SEM PAGAR NADA!!! http://gasset.uol.com.br/pl_cad/deonde?cod_promo=0DM&origem_assinatura=Z -------------------------------------------------------- Isso não é SPAM. Você está recebendo essa mensagem por ter se cadastrado em um ou mais Boletins do UOL. From cobranca@uol.com.br Wed Nov 27 14:15:01 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Nov 2002 14:15:03 -0800 (PST) Received: from silva5.uol.com.br (silva5.uol.com.br [200.221.4.52]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gARMF0uR017891 for ; Wed, 27 Nov 2002 14:15:01 -0800 Received: from uol.com.br ([200.196.48.4]) by silva5.uol.com.br (8.9.1/8.9.1) with ESMTP id UAA16050 for ; Wed, 27 Nov 2002 20:20:45 -0200 (BRST) Message-Id: <200211272220.UAA16050@silva5.uol.com.br> From: "Universo Online" To: netdev@oss.sgi.com Subject: Assine UOL! Reply-To: "Universo Online" Date: 27 Nov 2002 19:17:33 -0300 MIME-Version: 1.0 Content-Type: text/plain X-MIME-Autoconverted: from 8bit to quoted-printable by silva5.uol.com.br id UAA16050 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gARMF0uR017891 X-archive-position: 1253 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cobranca@uol.com.br Precedence: bulk X-list: netdev Assine UOL! Assine já o maior provedor da América Latina! O UOL têm planos super acessíveis para você e toda a sua família, a preços imbatíveis! Sem dúvida o melhor presente de natal que você podia esperar. Assine já! http://gasset.uol.com.br/pl_cad/deonde?cod_promo=0DM&origem_assinatura=Z PS: Clicando agora neste link você pode experimentar o UOL por um mês SEM PAGAR NADA!!! http://gasset.uol.com.br/pl_cad/deonde?cod_promo=0DM&origem_assinatura=Z -------------------------------------------------------- Isso não é SPAM. Você está recebendo essa mensagem por ter se cadastrado em um ou mais Boletins do UOL. From cobranca@uol.com.br Wed Nov 27 14:17:14 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Nov 2002 14:17:16 -0800 (PST) Received: from silva5.uol.com.br (silva5.uol.com.br [200.221.4.52]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gARMHDuR018286 for ; Wed, 27 Nov 2002 14:17:14 -0800 Received: from uol.com.br ([200.196.48.4]) by silva5.uol.com.br (8.9.1/8.9.1) with ESMTP id UAA17981 for ; Wed, 27 Nov 2002 20:22:52 -0200 (BRST) Message-Id: <200211272222.UAA17981@silva5.uol.com.br> From: "Universo Online" To: netdev@oss.sgi.com Subject: Assine UOL! Reply-To: "Universo Online" Date: 27 Nov 2002 19:19:44 -0300 MIME-Version: 1.0 Content-Type: text/plain X-MIME-Autoconverted: from 8bit to quoted-printable by silva5.uol.com.br id UAA17981 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gARMHDuR018286 X-archive-position: 1254 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cobranca@uol.com.br Precedence: bulk X-list: netdev Assine UOL! Assine já o maior provedor da América Latina! O UOL têm planos super acessíveis para você e toda a sua família, a preços imbatíveis! Sem dúvida o melhor presente de natal que você podia esperar. Assine já! http://gasset.uol.com.br/pl_cad/deonde?cod_promo=0DM&origem_assinatura=Z PS: Clicando agora neste link você pode experimentar o UOL por um mês SEM PAGAR NADA!!! http://gasset.uol.com.br/pl_cad/deonde?cod_promo=0DM&origem_assinatura=Z -------------------------------------------------------- Isso não é SPAM. Você está recebendo essa mensagem por ter se cadastrado em um ou mais Boletins do UOL. From jgarzik@pobox.com Wed Nov 27 16:10:11 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Nov 2002 16:10:16 -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 gAS0A9uR019939 for ; Wed, 27 Nov 2002 16:10:10 -0800 Received: from rdu74-162-040.nc.rr.com ([24.74.162.40] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 18GD30-0006hB-00; Mon, 25 Nov 2002 06:48:46 +0000 Message-ID: <3DE1C7A1.7000701@pobox.com> Date: Mon, 25 Nov 2002 01:48:01 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021018 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: "David S. Miller" Subject: [PATCH] tg3 shutdown sequence update (try 2) References: <3DE1C468.1060806@pobox.com> In-Reply-To: <3DE1C468.1060806@pobox.com> Content-Type: multipart/mixed; boundary="------------030408030209010408020802" X-archive-position: 1255 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 This is a multi-part message in MIME format. --------------030408030209010408020802 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Re-sending correct patch :) --------------030408030209010408020802 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" ===== drivers/net/tg3.c 1.41 vs 1.43 ===== --- 1.41/drivers/net/tg3.c Wed Nov 20 00:49:23 2002 +++ 1.43/drivers/net/tg3.c Mon Nov 25 01:10:05 2002 @@ -3088,6 +3088,9 @@ u32 val; val = tr32(ofs); + if ((val & enable_bit) == 0) + return 0; + val &= ~enable_bit; tw32(ofs, val); tr32(ofs); @@ -3112,16 +3115,12 @@ /* tp->lock is held. */ static int tg3_abort_hw(struct tg3 *tp) { - int i, err; + int err; tg3_disable_ints(tp); - tp->rx_mode &= ~RX_MODE_ENABLE; - tw32(MAC_RX_MODE, tp->rx_mode); - tr32(MAC_RX_MODE); - udelay(10); - - err = tg3_stop_block(tp, RCVBDI_MODE, RCVBDI_MODE_ENABLE); + err = tg3_stop_block(tp, MAC_RX_MODE, RX_MODE_ENABLE); + err |= tg3_stop_block(tp, RCVBDI_MODE, RCVBDI_MODE_ENABLE); err |= tg3_stop_block(tp, RCVLPC_MODE, RCVLPC_MODE_ENABLE); err |= tg3_stop_block(tp, RCVLSC_MODE, RCVLSC_MODE_ENABLE); err |= tg3_stop_block(tp, RCVDBDI_MODE, RCVDBDI_MODE_ENABLE); @@ -3133,40 +3132,21 @@ err |= tg3_stop_block(tp, SNDDATAI_MODE, SNDDATAI_MODE_ENABLE); err |= tg3_stop_block(tp, RDMAC_MODE, RDMAC_MODE_ENABLE); err |= tg3_stop_block(tp, SNDDATAC_MODE, SNDDATAC_MODE_ENABLE); + err |= tg3_stop_block(tp, DMAC_MODE, DMAC_MODE_ENABLE); err |= tg3_stop_block(tp, SNDBDC_MODE, SNDBDC_MODE_ENABLE); - if (err) - goto out; - - tp->mac_mode &= ~MAC_MODE_TDE_ENABLE; - tw32(MAC_MODE, tp->mac_mode); - tr32(MAC_MODE); - udelay(40); - - tp->tx_mode &= ~TX_MODE_ENABLE; - tw32(MAC_TX_MODE, tp->tx_mode); - tr32(MAC_TX_MODE); + err |= tg3_stop_block(tp, MAC_TX_MODE, TX_MODE_ENABLE); - for (i = 0; i < MAX_WAIT_CNT; i++) { - udelay(100); - if (!(tr32(MAC_TX_MODE) & TX_MODE_ENABLE)) - break; - } - if (i >= MAX_WAIT_CNT) { - printk(KERN_ERR PFX "tg3_abort_hw timed out for %s, " - "TX_MODE_ENABLE will not clear MAC_TX_MODE=%08x\n", - tp->dev->name, tr32(MAC_TX_MODE)); - return -ENODEV; - } - - err = tg3_stop_block(tp, HOSTCC_MODE, HOSTCC_MODE_ENABLE); + err |= tg3_stop_block(tp, HOSTCC_MODE, HOSTCC_MODE_ENABLE); err |= tg3_stop_block(tp, WDMAC_MODE, WDMAC_MODE_ENABLE); err |= tg3_stop_block(tp, MBFREE_MODE, MBFREE_MODE_ENABLE); tw32(FTQ_RESET, 0xffffffff); tw32(FTQ_RESET, 0x00000000); + tr32(FTQ_RESET); err |= tg3_stop_block(tp, BUFMGR_MODE, BUFMGR_MODE_ENABLE); err |= tg3_stop_block(tp, MEMARB_MODE, MEMARB_MODE_ENABLE); + if (err) goto out; --------------030408030209010408020802-- From zjp@iscas.ac.cn Wed Nov 27 16:53:54 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Nov 2002 16:54:00 -0800 (PST) Received: from mail.iscas.ac.cn ([159.226.5.56]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAS0rquR020833 for ; Wed, 27 Nov 2002 16:53:53 -0800 Received: (qmail 20180 invoked by uid 104); 28 Nov 2002 00:56:35 -0000 Received: from zjp@iscas.ac.cn by mail.iscas.ac.cn by uid 0 with qmail-scanner-1.14 (hbedv: 6.15.0.1. hbedv: operating system: Linux (glibc). hbedv: product version: 2.0.4. hbedv: engine version: 6.15.0.1. hbedv: packlib version: 2.0.0.8 (supports 19 formats). hbedv: vdf version: 6.15.0.7 (66928 recognized forms). hbedv: . hbedv: product: AntiVir Workstation. hbedv: key file: hbedv.key. hbedv: registered user: irene, 123. hbedv: serial number: 1001020203. hbedv: key expires: 31 May 2003. hbedv: run mode: PRIVATE. hbedv: . hbedv: product: AntiVir MailGate. hbedv: key file: hbedv.key. hbedv: registered user: irene, 123. hbedv: serial number: 1001020203. hbedv: key expires: 31 May 2003. hbedv: run mode: PRIVATE. hbedv: . hbedv: product: AntiVir (command line scanner). hbedv: key file: hbedv.key. hbedv: registered user: irene, 123. hbedv: serial number: 1001020203. hbedv: key expires: 31 May 2003. hbedv: run mode: PRIVATE. Clear:. Processed in 0.214184 secs); 28 Nov 2002 00:56:35 -0000 Received: from unknown (HELO zhengjp) (zjp@192.168.6.108) by mail.iscas.ac.cn with SMTP; 28 Nov 2002 00:56:35 -0000 Message-ID: <004c01c29679$52812600$6c06a8c0@zhengjp> From: "Zheng Jianping" To: "Peter Bieringer" Cc: References: <003201c29525$cd933360$6c06a8c0@zhengjp> <55380000.1038337716@worker.muc.bieringer.de> Subject: Re: How to get IPv6 interface? Date: Thu, 28 Nov 2002 08:58:53 +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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-archive-position: 1256 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zjp@iscas.ac.cn Precedence: bulk X-list: netdev ----- Original Message ----- From: "Peter Bieringer" To: Cc: "Zheng Jianping" Sent: Wednesday, November 27, 2002 3:08 AM Subject: Re: How to get IPv6 interface? --On Tuesday, November 26, 2002 04:28:31 PM +0800 Zheng Jianping wrote: >> My linux kernel is 2.4.7.10, how to get the information of all IPv6 >> interfaces, including the interfaces index, flags,name and >> address,etc ? >Userspace: ip -6 addr Peter, I'm writing an IPv6 application, so which function can get the IPv6 inteface information? And how to call it? Thanks, Zheng From Perry.Blackmore@dsto.defence.gov.au Wed Nov 27 18:15:26 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Nov 2002 18:15:29 -0800 (PST) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAS2FOuR022150 for ; Wed, 27 Nov 2002 18:15:25 -0800 Received: from dsto-ms2.dsto.defence.gov.au (dsto-ms2.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au (8.10.1/8.10.1) with ESMTP id gAS2GAe12037 for ; Thu, 28 Nov 2002 12:46:10 +1030 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by dsto-ms2.dsto.defence.gov.au (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Thu, 28 Nov 2002 12:47:51 +1030 Received: from salex001.dsto.defence.gov.au (salex001.dsto.defence.gov.au [131.185.2.9]) by muttley.dsto.defence.gov.au (8.9.3/8.9.3/8.9.3.LMD.990513) with ESMTP id MAA17470 for ; Thu, 28 Nov 2002 12:43:31 +1030 (CST) Received: from fhpex002.dsto.defence.gov.au ([144.97.171.1]) by salex001.dsto.defence.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XR5ZD4SQ; Thu, 28 Nov 2002 12:43:34 +1030 Received: by fhpex002.dsto.defence.gov.au with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Nov 2002 13:13:25 +1100 Message-ID: <378C31E229CFD411B48B009027EE73C0013A6E21@fhpex002.dsto.defence.gov.au> From: "Blackmore, Perry" To: "'netdev@oss.sgi.com'" Subject: RFC 3095 Date: Thu, 28 Nov 2002 13:13:17 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 1257 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Perry.Blackmore@dsto.defence.gov.au Precedence: bulk X-list: netdev Guys, Alan Cox has referred you to me. Are you aware if RFC 3095 (Robust Header Compression) has been implemented by anyone on the Linux platform? Cheers, > Perry Blackmore > > Dr Perry A Blackmore > Senior Defence Scientist > DSTO > > +61 2 625 66141 (Phone) > +61 2 625 66130 (FAX) > > perry.blackmore@dsto.defence.gov.au > > DSTO Fern Hill > Department of Defence > CANBERRA ACT 2600 > Australia > > From jgarzik@pobox.com Wed Nov 27 18:46:35 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Nov 2002 18:46: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 gAS2kYuR022700 for ; Wed, 27 Nov 2002 18:46:34 -0800 Received: from rdu74-162-040.nc.rr.com ([24.74.162.40] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 18HEjo-0004jD-00; Thu, 28 Nov 2002 02:49:12 +0000 Message-ID: <3DE583F6.6040502@pobox.com> Date: Wed, 27 Nov 2002 21:48:22 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021018 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Greear CC: netdev@oss.sgi.com Subject: Re: [PATCH] tg3 locking update (with NAPI overtones) References: <3DE406AE.2000908@pobox.com> <20021126.155144.43008660.davem@redhat.com> <3DE41779.9030804@pobox.com> <3DE4770B.3020701@candelatech.com> In-Reply-To: <3DE406AE.2000908@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1258 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: > Just out of curiosity, have any of you been able to reproduce > any IRQ warnings under heavy loads with the tg3? If I start > up all ports of a 4-port tulip nic and also start the tg3 > (all running high speed), then I see a steady stream of > complaints from the tg3.... Can you be more specific? :) Is it "poll already scheduled"? Also: is the tg3 sharing interrupts with any other device? From jgarzik@pobox.com Wed Nov 27 20:56:50 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Nov 2002 20:56:54 -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 gAS4umuR024518 for ; Wed, 27 Nov 2002 20:56:49 -0800 Received: from rdu74-162-040.nc.rr.com ([24.74.162.40] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 18HGlt-0005dQ-00; Thu, 28 Nov 2002 04:59:29 +0000 Message-ID: <3DE5A27E.50207@pobox.com> Date: Wed, 27 Nov 2002 23:58:38 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021018 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stefan Rompf CC: netdev@oss.sgi.com Subject: Re: Patch: link state detection for 8139too against 2.4.20rc2 / 2.5 References: <3DA96BCC.B2589AC0@isg.de> <3DE0CA4C.730699FC@isg.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1259 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 Stefan Rompf wrote: > Hi, > > > >>Uhmmm, you don't need to poll with the rtl8139. There is a link change > >>interrupt. Here is the recently added from rtl8139.c > > > >ok, I'll try this next time I have access to the card. > > > ...that was some days ago. I've seen that Jeff is enhancing the MII > interface library, so I used the functions provided there. Patch is > against 2.4.20rc2 and 2.5 with some offset. Please apply if it looks > good. > > Cheers, Stefan > > > ------------------------------------------------------------------------ > > --- linux/drivers/net/8139too.c.old 2002-11-19 00:32:04.000000000 +0100 > +++ linux/drivers/net/8139too.c 2002-11-21 22:32:39.000000000 +0100 > @@ -1335,18 +1335,7 @@ > struct rtl8139_private *tp = dev->priv; > > if (tp->phys[0] >= 0) { > - u16 mii_lpa = mdio_read(dev, tp->phys[0], MII_LPA); > - if (mii_lpa == 0xffff) > - ; /* Not there */ > - else if ((mii_lpa & LPA_100FULL) == LPA_100FULL > - || (mii_lpa & 0x00C0) == LPA_10FULL) > - tp->mii.full_duplex = 1; > - > - printk (KERN_INFO"%s: Setting %s%s-duplex based on" > - " auto-negotiated partner ability %4.4x.\n", > - dev->name, mii_lpa == 0 ? "" : > - (mii_lpa & 0x0180) ? "100mbps " : "10mbps ", > - tp->mii.full_duplex ? "full" : "half", mii_lpa); > + mii_check_media(&tp->mii, 1, 1); close -- you don't want to unconditionally "initialize" the media (mii_check_media second arg). You can also kibbitz from 8139cp.c in 2.4.20-rc4 / 2.5. because the phy code is gonna be pretty darned similar. Eventually the phy code needs to move to a common 8139lib.c, because both old-8139 line and 8139C+ support external MII phys as well as the normal on-chip phy found in most 8139s. Jeff From sqhilp@attbi.com Wed Nov 27 23:06:32 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Nov 2002 23:06:37 -0800 (PST) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAS76VuR026702 for ; Wed, 27 Nov 2002 23:06:32 -0800 Message-Id: <200211280706.gAS76VuR026702@oss.sgi.com> Date: Thu, 28 Nov 2002 07:09:07 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium. Received: from mail.attbi.com (12-245-32-37.client.attbi.com[12.245.32.37]) by sccrmhc03.attbi.com (sccrmhc03) with SMTP id <2002112807090300300jmu2ce>; Thu, 28 Nov 2002 07:09:04 +0000 FROM: Steve Philp Subject: Geographic names are treated X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Outlook Express 5.00.2314.1300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0033_01FC6A60.A0E070C0" Content-Transfer-Encoding: 7bit X-archive-position: 1260 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sqhilp@attbi.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. ------=_NextPart_000_0033_01FC6A60.A0E070C0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit If the name begins with a prefix followed by a space or hyphen, consider the prefix and the following word as a single unit. Arabic and Roman numbers are considered separate units. Ordinal numbers are treated is if they were written 2, 4, and 9. Units that contain Arabic or Roman numbers precede units expressed in words. ------=_NextPart_000_0033_01FC6A60.A0E070C0 Content-Type: application/octet-stream; name="unit.pif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="unit.pif" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFt IGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEH AFHFBTAAAAAA1cMAAOAADgELAQI3AEgAAABKAAAAAgAAQEwAAAAQAAAAYAAA AABAAAAQAAAAAgAAAQAAAAAAAAAEAAAAAAAAAO13AQAABAAAoR8BAAIAAAAA ABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAACQAADYDAAAAKAAAEAt AAAAAAAAAAAAAAAAAAAAAAAAANAAALgEAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAAuEcAAAAQAAAASAAAAAQAAAAAAAAA AAAAAAAAACAAAGAuYnNzAAAAAFgAAAAAYAAAAAAAAAAAAAAAAAAAAAAAAAAA AACAAADALnJkYXRhAABAAAAAAHAAAAACAAAATAAAAAAAAAAAAAAAAAAAQAAA QC5kYXRhAAAAZAIAAACAAAAABAAAAE4AAAAAAAAAAAAAAAAAAEAAAMAuaWRh dGEAANgMAAAAkAAAAA4AAABSAAAAAAAAAAAAAAAAAABAAABALnJzcmMAAABA LQAAAKAAAAAuAAAAYAAAAAAAAAAAAAAAAAAAQAAAQC5yZWxvYwAA7acAAADQ AAAAfgAAAI4AAAAAAAAAAAAAAAAAAEAAAMIAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL7IHsHAMAAFNW V2gEAQAAjYX8/v//UGj0AQAAi0UIUP8V2JRAAGgEAQAAjYX4/f//UGj3AQAA i0UIUP8V2JRAAGgEAQAAjYX0/P//UGj1AQAAi0UIUP8V2JRAAI2F8Pz//1CN hfz+//9QaAEAAID/FdySQACFwA+F+gAAAMeF7Pz//wQAAACNhez8//9QjYXk /P//UI2F6Pz//1BqAI2F+P3//1CLhfD8//9Q/xXgkkAAhcAPhSgAAACDvej8 //8ED4UbAAAAi4Xk/P//iw0AgEAAO8EPhwIAAACLwaMAgEAAx4Xs/P//BAAA AI2F7Pz//1CNheT8//9QjYXo/P//UGoAjYX0/P//UIuF8Pz//1D/FeCSQACF wA+FWAAAAIO96Pz//wQPhUsAAACDveT8//8AD4Q+AAAAi4Xk/P//PTQXAAAP ggUAAAC4NBcAAImF5Pz//4uF5Pz//40EgI0EgI0EgMHgA6MEgEAA/xUsk0AA owiAQADpAAAAAF9eW8nDVYvsU1ZXi0UIOUUMD4ILAAAAi0UMK0UI6Q8AAAC4 /////ytFCItNDI1ECAHpAAAAAF9eW8nDVYvsg+w0U1ZXx0X0AAAAAMdF4AAA AADHRfAAAAAAx0X4AAAAAItFDIlFzOmxAwAA/xXokkAAagD/FTyTQABQ6AT+ //+DxARoEGBAAP8VxJRAAIM9DIBAAAAPhZ0AAABqAP8VOJNAAGgUgEAA/xU0 k0AAowyAQABoIIBAAKEMgEAAUP8VMJNAAIlF7GgwgEAAoQyAQABQ/xUwk0AA owxgQABoQIBAAKEMgEAAUP8VMJNAAIlF/GhMgEAAoQyAQABQ/xUwk0AAoxhg QABoXIBAAKEMgEAAUP8VMJNAAKMEYEAAaHCAQAChDIBAAFD/FTCTQACjAGBA AOkAAAAAgz3wgUAAAA+EIgAAAIN9/AAPhBMAAACh6IFAAFD/VfyjEIBAAOkA AAAA6TwAAACDfewAD4QoAAAAagGLRQhQoeiBQABQ/1XshcAPhQwAAAAzwOli AwAA6QAAAADpCgAAALgBAAAA6U4DAAC4AQAAAOlEAwAAgz3wgUAAAA+EMQAA AIM9GGBAAAAPhB8AAACLRRBQoRCAQABQ/xUYYEAAuAEAAADpEAMAAOkAAAAA 6VcAAACDPQxgQAAAD4RKAAAAjUX4UI1F8FCNReBQjUX0UP8VDGBAAItF9FD/ FbyUQACFwA+EHQAAAGoBagCLRfRQ/xXUlEAAuAEAAADpuQIAAOkAAAAA6QAA AADpkAIAAOmLAgAAgz3wgUAAAA+EBQAAAOl5AgAAjUXkUP8VxJRAAItF5CsF EGBAAIlF2IN92AAPhBQAAAAPjQ4AAACLRdiLyAPAK8H32IlF2ItF6CsFFGBA AIlF3IN93AAPhBQAAAAPjQ4AAACLRdyLyAPAK8H32IlF3ItF2ANF3DsFAIBA AA+GIQAAAGoAagBqEItFCFD/FcCUQACLReSLTeijEGBAAIkNFGBAADPA6fsB AACDPQSAQAAAD4QhAAAA/xUsk0AAUKEIgEAAUOjx/P//g8QIOwUEgEAAD4Je AAAAgz0EYEAAAA+ECAAAAGoB/xUEYEAAi0UUUItFEFCLRQxQi0UIUOiZOgAA iUXUgz0EYEAAAA+ECAAAAGoA/xUEYEAAg33UAA+FEgAAAGgQYEAA/xXElEAA M8DpbwEAALgBAAAA6WUBAACBfRBA8QAAD4UKAAAAuAEAAADpTgEAAOkvAQAA 6SoBAACDPfCBQAAAD4QsAAAAaHyAQAChDIBAAFD/FTCTQACJRdCDfdAAD4QJ AAAAoRCAQABQ/1XQ6S0AAACDPQBgQAAAD4QPAAAAi0UIUP8VAGBAAOkAAAAA agBqAP8VyJRAAFD/FdSUQADpvwAAAOm6AAAAg33MEA+HHwAAAA+EqgAAAIN9 zAEPhDX8//+DfcwCD4Rs////6ZEAAACBfcwAAQAAD4cVAAAAD4R+AAAAg33M FA+ESv3//+lvAAAAgX3MEgEAAA+HCwAAAA+EEf///+lXAAAAgX3MAIAAAA+H SgAAAA+EY/7//4FtzAACAACDfcwHD4czAAAAi0XMM8mKiEYWQAD/JI0yFkAA yBNAAMMTQADDE0AAwxNAAFMWQAAAAQQEAgQEA+kAAAAAi0UUUItFEFCLRQxQ i0UIUOj7OAAA6QAAAABfXlvJwhAAVYvsg+wQU1ZXx0X4EQ4AAMdF/CU7QACL RQyJRfDpcgAAAMcFQGBAAAEAAACNRfxQjUX4UGoBi0UIUGoA/xU8k0AAUOi+ JwAAg8QUi0UIUP8VsJRAAIlF9ItF9FD/FbyUQACFwA+ECgAAAItF9FD/FbSU QABqAYtFCFD/FbiUQAC4AQAAAOkjAAAA6RcAAADpEgAAAIF98BABAAAPhIH/ ///pAAAAADPA6QAAAABfXlvJwhAAVYvsU1ZXi0UIUOi0JgAAg8QE6QAAAABf XlvJwgQAzMzMzMzMzMzMzFWL7IPsEFNWV8dF/P////+NRfRQaBkAAgBqAItF DFCLRQhQ/xXYkkAAiUX4g334AA+FOQAAAItFGFCLRRRQjUXwUGoAi0UQUItF 9FD/FeCSQACJRfiDffgAD4ULAAAAi0XwiUX86QAAAADpAAAAAItF/OkAAAAA X15bycNVi+yD7BBTVlfHRfz/////jUX0UI1F8FBqAGgGAAIAagBqAGoAi0UM UItFCFD/FdCSQACJRfiDffgAD4U9AAAAi0UcUItFGFCLRRRQagCLRRBQi0Xw UP8V1JJAAIlF+IN9+AAPhQ8AAAC4AQAAAOkRAAAA6QAAAADpAAAAADPA6QAA AABfXlvJw1WL7IPsCFNWV4tFGIlF+I1F+FCLRRRQi0UMUItFCFCLRRxQ6NP+ //+DxBSJRfyDffwAD4ZCAAAAg338AQ+EFAAAAIN9/AcPhAoAAACDffwCD4UV AAAAi0X4iUX86XQAAADpXQAAAOkKAAAA6WAAAADpDwAAAOkKAAAA6UwAAADp AAAAAItFEFDoKDMAAIPEBDtFGA+CCwAAAItFGIlF/OkPAAAAi0UQUOgIMwAA g8QEiUX8i0UQUItFFFDo7zIAAIPECItF/OkPAAAA6bT////pr////+np//// X15bycNVi+yB7AwBAABTVlfHhfT+//8EAQAAjYX0/v//UI2F+P7//1CLRQxQ i0UIUItFFFDo5/3//4PEFIlF/IN9/AAPhnkAAACDffwED4QKAAAAg338BQ+F VgAAAIuF+P7//4mF9P7//4N9/AUPhSgAAACLhfT+///B6BAl//8AAA+3wIuN 9P7//4Hh//8AAMHhEAvBiYX0/v//i4X0/v//iUX86TsAAADpJAAAAOkKAAAA 6ScAAADpDwAAAOkKAAAA6RMAAADpAAAAAItFEIlF/ItF/OkPAAAA6e3////p 6P///+np////X15bycNVi+yD7ARTVleLRRBQ6NoxAACDxARQi0UQUGoBi0UM UItFCFCLRRRQ6IH9//+DxBiJRfyLRfzpAAAAAF9eW8nDVYvsg+wEU1ZXagSN RRBQagSLRQxQi0UIUItFFFDoTP3//4PEGIlF/ItF/OkAAAAAX15bycNVi+yD 7BBTVlfHRfz/////jUX0UGgZAAIAagCLRQhQi0UMUP8V2JJAAIlF+IN9+AAP hQoAAAC4AQAAAOkCAAAAM8DpAAAAAF9eW8nDzFWL7IHsSAIAAFNWV4tFCIsA iYXw/f//aAQBAACNhfj+//9QaPQBAACLhfD9//9Q/xXYlEAAaAQBAACNhfT9 //9QaPUBAACLhfD9//9Q/xXYlEAAaAEAAIBqAI2F9P3//1CNhfj+//9Q6Of9 //+DxBCLTQiJQQhoBAEAAI2F9P3//1Bo9gEAAIuF8P3//1D/FdiUQABoAQAA gGoAjYX0/f//UI2F+P7//1Dopv3//4PEEItNCIlBDGgEAQAAjYX0/f//UGj4 AQAAi4Xw/f//UP8V2JRAAGgBAACAagCNhfT9//9QjYX4/v//UOhl/f//g8QQ i00IiUEUaAQBAACNhfT9//9QaPcBAACLhfD9//9Q/xXYlEAAaAEAAIBqAI2F 9P3//1CNhfj+//9Q6CT9//+DxBCLTQiJQRBoBAEAAI2F9P3//1Bo+QEAAIuF 8P3//1D/FdiUQABoAQAAgGoyjYW4/f//UGiMgEAAjYX0/f//UI2F+P7//1Do +Pv//4PEGMeF7P3//wAAAADpBgAAAP+F7P3//4O97P3//wQPjVgAAADHRfwA AAAAi4Xs/f//D76EBbj9//+D+FkPhQcAAADHRfwBAAAAi4Xs/f//D76EBbj9 //+D+E4PhQcAAADHRfwCAAAAikX8i43s/f//i1UIiEQRGOmV////aAQBAACN hfT9//9QaPoBAACLhfD9//9Q/xXYlEAAaAEAAIBqAI2F9P3//1CNhfj+//9Q 6CL8//+DxBCLTQiJQRzpAAAAAF9eW8nDVYvsgexMAgAAU1ZXi0UIiwCJhfD9 //9oBAEAAI2F+P7//1Bo9AEAAIuF8P3//1D/FdiUQACLRQiLQAiJhbT9//9o BAEAAI2F9P3//1Bo9QEAAIuF8P3//1D/FdiUQABoAQAAgItFCItACFCNhfT9 //9QjYX4/v//UOi7/P//g8QQaAQBAACNhfT9//9QaPYBAACLhfD9//9Q/xXY lEAAaAEAAICLRQiLQAxQjYX0/f//UI2F+P7//1Doe/z//4PEEGgEAQAAjYX0 /f//UGj4AQAAi4Xw/f//UP8V2JRAAGgBAACAi0UIi0AUUI2F9P3//1CNhfj+ //9Q6Dv8//+DxBBoBAEAAI2F9P3//1Bo9wEAAIuF8P3//1D/FdiUQABoAQAA gItFCItAEFCNhfT9//9QjYX4/v//UOj7+///g8QQx4Xs/f//AAAAAOkGAAAA /4Xs/f//g73s/f//BA+NXgAAAIuF7P3//4tNCA++RAgYiUX8g338AA+FDgAA AIuF7P3//8aEBbj9//8tg338AQ+FDgAAAIuF7P3//8aEBbj9//9Zg338Ag+F DgAAAIuF7P3//8aEBbj9//9O6Y////+Lhez9///GhAW4/f//AGgEAQAAjYX0 /f//UGj5AQAAi4Xw/f//UP8V2JRAAGgBAACAjYW4/f//UI2F9P3//1CNhfj+ //9Q6O36//+DxBBoBAEAAI2F9P3//1Bo+gEAAIuF8P3//1D/FdiUQABoAQAA gItFCItAHFCNhfT9//9QjYX4/v//UOjt+v//g8QQ6QAAAABfXlvJw8zMVYvs g+wIU1ZXiU34agBqAGoAagCLRfiDwBRQ/xWslEAAx0X8AAAAAOkDAAAA/0X8 g338BA+NLgAAAGoAagBqAGoAi0X8weAEA0X4g8AkUP8VrJRAAItF/ItN/ItV +GaJREpk6cX///+LRfjHQHQAAAAAi0X4i0B0i034iUFwi0X4x0B4AAAAAItF +MdAfAAAAACLRfjHgIAAAAAAAAAAi0X4x0AEAQAAAItF+MdACAEAAACLRfjH QAwAAAAAi0X4x0AQAAAAAItF+MeAhAAAAAAAAACLRfjHgIgAAAAAAAAA6QAA AACLRfhfXlvJw1WL7IPsBFNWV4lN/ItF/IN4eAAPhCgAAACLRfyLQHhQ/xVE k0AAUP8VSJNAAItF/ItAeFD/FUSTQABQ/xVAk0AAi0X8g3h8AA+EKAAAAItF /ItAfFD/FUSTQABQ/xVIk0AAi0X8i0B8UP8VRJNAAFD/FUCTQACLRfyDuIAA AAAAD4QQAAAAi0X8i4CAAAAAUP8VpJRAAItF/IuAiAAAAFD/FbyUQACFwA+E EAAAAItF/IuAiAAAAFD/FaiUQACLRfzHQHgAAAAAi0X8x0B8AAAAAItF/MeA gAAAAAAAAACLRfzHgIQAAAAAAAAAi0X8x4CIAAAAAAAAAOkAAAAAX15bycNV i+yB7CABAABTVleJjeD+//+LRQiLjeD+//+JAYtFDIuN4P7//4mBhAAAAIuF 4P7//4O4gAAAAAAPhAUAAADpdgAAAP8VlJRAAIuN4P7//4mBgAAAAMdF/OoL AADHRfi4CwAA6QYAAAD/Rfz/RfiBffztCwAAD40+AAAAamSNRZRQi0X8UItF CFD/FdiUQACFwA+OHQAAAI1FlFCLRfhQagCLheD+//+LgIAAAABQ/xWYlEAA 6a////+LheD+//+DeHgAD4VjAQAAi0UIUIuN4P7//+hlAQAAhcAPhEUBAABq D/8VnJRAAImF6P7//4qF6P7//4hFiouF6P7//8HoEIhFiIuF6P7//4hliWiW AAAAjYXw/v//UGjwCwAAi0UIUP8V2JRAAI2F5P7//1CNRZBQjUWMUGiYgEAA jYXw/v//UOhXKQAAg8QUikWMiIXu/v//ikWQiIXt/v//ioXk/v//iIXs/v// i0WIUIuF7P7//1CLjeD+///oZAQAAGoAi0UIUGoAi4Xg/v//i4CEAAAAUIuF 4P7//4tAUIuN4P7//ytBKFCLheD+//+LQEyLjeD+//8rQSRQi4Xg/v//i0Ao UIuF4P7//4tAJFBoAAAAQGikgEAAaLiAQABqAP8V3JRAAIuN4P7//4mBiAAA AGoGi4Xg/v//i0AgUIuF4P7//4tAHFBqAGoAagCLRQxQ/xWglEAAuAEAAADp FgAAAOkHAAAAM8DpCgAAALgBAAAA6QAAAABfXlvJwggAVYvsg+w8U1ZXiU3E aMILAACLRQhQ6IcdAACDxAiLTcSJQXhowwsAAItFCFDocB0AAIPECItNxIlB fItFxIN4eAAPhC8AAACLRcSLQHhQ6IgfAACDxASLTcSJQRyLRcSLQHhQ6Ikf AACDxASLTcSJQSDpAAAAAGoyjUXIUGjvCwAAi0UIUP8V2JRAAItFxIPAWFCL RcSDwFRQi0XEg8BIUItFxIPARFCLRcSDwDhQi0XEg8A0UItFxIPAKFCLRcSD wCRQaMyAQACNRchQ6JAnAACDxCiLRcSDeHwAD4TWAAAAi0XEi0B8UOjuHgAA g8QEi03EiUFwi0XEi0B8UOjvHgAAg8QEuQMAAAAr0vfxi03EiUF0M8CLTcQr QXD32ItNxClBNDPAi03EK0Fw99iLTcQpQUQzwItNxCtBdPfYi03EKUFIM8CL TcQrQXT32ItNxClBWMdF/AAAAADpAwAAAP9F/IN9/AQPjUUAAACLRfzB4ASL TcSLRAgki03EA0Fwi038weEEi1XEiUQRLItF/MHgBItNxItECCiLTcQDQXSL TfzB4QSLVcSJRBEw6a7////pAAAAAItFxIN4eAAPhBcAAACLRcSDeHwAD4QK AAAAuAEAAADpAgAAADPA6QAAAABfXlvJwgQAVYvsg+wEU1ZXiU38i0X8g3h4 AA+FDAAAADPA6RkAAADpFAAAAItF/ItAeFDowR0AAIPEBOkAAAAAX15bycNV i+yD7ARTVleJTfyLRfyDeHgAD4UMAAAAM8DpGQAAAOkUAAAAi0X8i0B4UOiZ HQAAg8QE6QAAAABfXlvJw1WL7IPsCFNWV4lN+ItFCFCLTfjokAAAAItF+IN4 DAAPhC4AAADHRfwAAAAA6QMAAAD/RfyDffwED40VAAAAi0X8UItFCFCLTfjo 0AEAAOne////i0X4g3gQAA+EPAAAAItF+IuAiAAAAFD/FbyUQACFwA+EJAAA AGoBagCLRfiLgIgAAABQ/xXUlEAAi0X4i4CIAAAAUP8VkJRAAOkAAAAAX15b ycIEAFWL7IPsBFNWV4lN/GoDi0UIUP8VDJNAAItF/IN4eAAPhGcAAABqAItF /ItAeFCLRfyLQHhQ6MAcAACDxARQi0X8i0B4UOiaHAAAg8QEUGoAagBqAItF /ItAeFDohBwAAIPEBFCLRfyLQHhQ6F4cAACDxARQi0X8i0AYUItF/ItAFFCL RQhQ/xUUk0AA6QAAAABfXlvJwgQAVYvsg+wQU1ZXiU3wi0Xwg3h4AA+EuQAA AItF8ItAeFDoPxsAAIPEBIlF9ItF8ItAeFDoTBsAAIPEBIlF/MdF+AAAAADp AwAAAP9F+ItF/DlF+A+NegAAAItF+ItN9DPSilSBAjPAikUKO9APhVwAAACL RfiLTfQz0opUgQEzwIpFCTvQD4VDAAAAi0X4i030M9KKFIEzwIpFCDvQD4Ur AAAAikUMi034i1X0iASKikUNi034i1X0iESKAYpFDotN+ItV9IhEigLpBQAA AOl3////6QAAAABfXlvJwggAVYvsg+wIU1ZXiU34agOLRQhQ/xUMk0AAi0X4 g3h8AA+EjgAAAIN9DAAPjIQAAACDfQwED416AAAAi0UMi034D79EQWSJRfxq AItF+ItAfFCLRfiLQHxQ6CgbAACDxARQi0X4i0B8UOgCGwAAg8QEUGoAi0X4 i0B0D69F/FBqAItF+ItAdFCLRfiLQHBQi0UMweAEi034i0QIKFCLRQzB4ASL TfiLRAgkUItFCFD/FRSTQADpAAAAAF9eW8nCCABVi+yD7AhTVleJTfjHRfwA AAAA6QMAAAD/RfyDffwED40wAAAAi0UIi00MUVCLRfzB4AQDRfiDwCRQ/xWM lEAAhcAPhAgAAACLRfzpDwAAAOnD////uP/////pAAAAAF9eW8nCCABVi+yD 7AhTVldqAGrri0UIUP8ViJRAAGiMAAAA6J4iAACDxASJRfiDffgAD4QQAAAA i0346PD1//+JRfzpBwAAAMdF/AAAAACLRfxQauuLRQhQ/xWIlEAAg338AA+E AAAAAItFCFBqAP8VPJNAAFCLTfzoo/f//7gBAAAA6QAAAABfXlvJwggAVYvs g+wMU1ZXauuLRQhQ/xWElEAAiUX8g338AA+EJQAAAItF/IlF9ItF9IlF+IN9 +AAPhA8AAABqAYtN+OhfBQAA6QAAAABqAGrri0UIUP8ViJRAALgBAAAA6QAA AABfXlvJwgQAVYvsg+xIU1ZXauuLRQhQ/xWElEAAiUX8jUW8UItFCFD/FWCU QACJRbiDffwAD4QRAAAAi0W4UItN/OiQ+///6QAAAACNRbxQi0UIUP8VaJRA ADPA6QAAAABfXlvJwgQAVYvsg+wQU1ZXauuLRQhQ/xWElEAAiUX4g334AA+F PgAAAItFFCX//wAAweAQi00QgeH//wAAC8FQi0UYUIN9DAEbwIPg/gUDAgAA UItFCFD/FQSUQAC4AQAAAOm7AAAAi0X4g3gMAA+EpAAAAItFEIlF8ItFFIlF 9ItF8ItN9FFQi0346MP9//+JRfyDffz/D4R7AAAAi0X8i034iUFsaAgEAACL RfyLTfgPv0RBZFCLRfiLgIAAAABQ/xVklEAAjUXwUItFCFD/FQCUQABqAItF CFBqAItF9FCLRfBQagCLRfiLgIAAAABQ/xX8k0AAaAAEAACLRfyLTfgPv0RB ZFCLRfiLgIAAAABQ/xVklEAAuAEAAADpAAAAAF9eW8nCFABVi+yB7JgCAABT Vldq64tFCFD/FYSUQACJRfiDffgAD4U0AAAAi0UQUItFFCX//wAAweAQi00M geH//wAAC8FQaBEBAACLRQhQ/xUElEAAuAEAAADpDQEAAItF+ItAbIlF/IF9 DLgLAAAPjHUAAACBfQy7CwAAD49oAAAAi0UMLbgLAACLTfyLVfhmiURKZItF CFD/FRSUQACJRfSLRfxQi0X0UItN+Oi/+///i0X0UItFCFD/FRCUQABqAItF CFD/FbCUQABQaGgEAACLRQhQ/xWwlEAAUP8VsJRAAFD/FQyUQACLRfiDeAQA D4VrAAAAi0X4g3gIAA+EXgAAAItF+MdACAAAAABo9AEAAI2FaP3//1Bo8gsA AItF+IsAUP8V2JRAAGiWAAAAjYVc////UGjxCwAAi0X4iwBQ/xXYlEAAakCN hVz///9QjYVo/f//UItFCFD/FQiUQAC4AQAAAOkAAAAAX15bycIQAFWL7IPs BFNWV4tFDIlF/OmmAAAAi0UUUItFCFDoAvz//4XAD4QHAAAAM8DpBQAAALj/ ////6eMAAACLRQhQ6M78//8zwOnTAAAAi0UQUItFFMHoECX//wAAD7/AUA+/ RRRQagCLRQhQ6AT9//8zwOmpAAAAi0UQwegQJf//AAAPt8BQi0UUUItFECX/ /wAAUItFCFDo+v3//zPA6X0AAACLRQhQ6AL8//8zwOltAAAA6U0AAADpSAAA AIN9/A8Phx8AAAAPhHD///+DffwBD4RA////g338Ag+Ewv///+kfAAAAgX38 EQEAAA+EhP///4F9/AECAAAPhE3////pAAAAAItFFFCLRRBQi0UMUItFCFD/ FQSUQADpAAAAAF9eW8nCEABVi+yD7ARTVldq64tFCFD/FYSUQACJRfyDffwA D4QTAAAAi0X8i4CIAAAA6QwAAADpBwAAADPA6QAAAABfXlvJw1WL7IPsBFNW V2rri0UIUP8VhJRAAIlF/IN9/AAPhFsAAACLRfyDuIgAAAAAD4RGAAAAg30M AbgAAAAAg9D/g+AFUItF/IuAiAAAAFD/FRiUQACLRQyLTfyJQRBqAWoAi0UI UP8V1JRAAItFCFD/FZCUQADpAAAAAOkAAAAA6QAAAABfXlvJw1WL7IPsBFNW V2rri0UIUP8VhJRAAIlF/IN9/AAPhCYAAACLRQyLTfyJQQxqAWoAi0UIUP8V 1JRAAItFCFD/FZCUQADpAAAAAOkAAAAAX15bycPMzMzMzMzMzMzMzMzMzFWL 7IPsBFNWV4lN/ItN/Oja8P//9kUIAQ+EDAAAAItF/FDodRwAAIPEBItF/OkA AAAAX15bycIEAMzMzMzMzMxVi+yB7KQAAABTVlfHRfwAAAAAaJYAAACNhVz/ //9QaMoNAACLRQhQ/xXYlEAAhcAPhG0AAACNhVz///9Q/xU0k0AAiUX4g334 AA+ETgAAAGiWAAAAjYVc////UGjLDQAAi0UIUP8V2JRAAI2FXP///1CLRfhQ /xUwk0AAiUX0g330AA+EBgAAAP9V9IlF/ItF+FD/FUyTQADpAAAAAOkAAAAA i0X86QAAAABfXlvJw1WL7IHspAAAAFNWV8dF/AAAAABolgAAAI2FXP///1Bo yg0AAItFCFD/FdiUQACFwA+EagAAAI2FXP///1D/FTSTQACJRfiDffgAD4RL AAAAaJYAAACNhVz///9QaMwNAACLRQhQ/xXYlEAAjYVc////UItF+FD/FTCT QACJRfSDffQAD4QDAAAA/1X0i0X4UP8VTJNAAOkAAAAA6QAAAADpAAAAAF9e W8nDVYvsgewcBQAAU1ZXjYXw+v//iYX8/v//x0X8AAQAAItFFCX//wAAUItF DFD/FRyUQACJhfT+//+LRRCJhez6////RRBo+gAAAI2FAP///1CLhez6//9Q i0UMUP8V2JRAAI2FAP///1DomxoAAIPEBImF8P7//4tFEImF6Pr///9FEGj6 AAAAjYUA////UIuF6Pr//1CLRQxQ/xXYlEAA/43w/v//i4X8/v//xgAAx4X4 /v//AAQAAOkGAAAA/43w/v//g338AA+OXAAAAIO98P7//wAPjk8AAACLRRCJ heT6////RRCLhfj+//9Qi4X8/v//UIuF5Pr//1CLRQxQ/xXYlEAAiYX4/v// M8Arhfj+///32ClF/IuF+P7//wGF/P7//+mU////i4X0/v//UI2F8Pr//1CN hQD///9Qi0UIUP8V8JNAAOkAAAAAX15bycNVi+yB7NgAAABTVleLRQhQ/xWw lEAAiYUs////agCLhSz///9Q/xU0lEAAiYUo////i0UQiYUw////i4Uw//// i0AEiUXoi4Uw////iwCJRdyLhTD///9QauuLRQhQ/xWIlEAAaDgOAACLRQhQ /xUglEAAiUXYauuLRdhQ/xWElEAAiUXoi03o6J/y//+JRfyLTejo0vL//4mF NP///41F7FCLRdhQ/xUwlEAAjUXsUItFCFD/FSyUQACNRfRQi0UIUP8VLJRA AItF9CtF7JkrwsH4AYtN7APIiU3ki0X4K0XwmSvCwfgBi03wA8iJTeBqBYuF NP///1CLRfxQi03gi4U0////mSvCwfgBK8hRi03ki0X8mSvCwfgBK8hRagCL RdhQ/xWglEAAi0XcUOgh/P//g8QEhcAPhCcAAABqAGg3DgAAi0UIUP8VIJRA AFD/FRiUQACLRejHQAQBAAAA6SIAAABqAGg2DgAAi0UIUP8VIJRAAFD/FRiU QACLRejHQAQAAAAAagGLRdhQ6CL7//+DxAhqAWoAi0XYUP8V1JRAAGg0DgAA i0UIUP8VIJRAAIlF2GoAagBoSwEAAItF2FD/FQyUQABolgAAAI2FPP///1Bo 0g0AAItF3FD/FdiUQACNhTz///9QagBoQwEAAItF2FD/FQyUQABolgAAAI2F PP///1Bo0w0AAItF3FD/FdiUQACNhTz///9QagBoQwEAAItF2FD/FQyUQABq AIuFMP///4tADFBoTgEAAItF2FD/FQyUQACLhTD///+DeAwAD44cAAAAi4Uw ////uTwAAACLQAiZ9/mJhTj////pDwAAAIuFMP///4tACImFOP///2gyDgAA i0UIUP8VIJRAAIlF2IuFOP///1BoOIFAAI2FPP///1DoFBcAAIPEDI2FPP// /1CLRdhQ/xUolEAAamNqAGhlBAAAaDMOAACLRQhQ/xUglEAAUP8VDJRAAGgw DgAAi0UIUP8VIJRAAIlF2GoAagBoSwEAAItF2FD/FQyUQADHhTj////ODQAA 6QYAAAD/hTj///+BvTj////SDQAAD41UAAAAaJYAAACNhTz///9Qi4U4//// UItF3FD/FdiUQABqLI2FPP///1DoZhYAAIPECIlF1ItF1MYAAI2FPP///1Bq AGhDAQAAi0XYUP8VDJRAAOmW////i4Uw////g3gUAA+MEAAAAIuFMP///4N4 FAQPjA0AAACLhTD////HQBQAAAAAagCLhTD///+LQBRQaE4BAACLRdhQ/xUM lEAAx4U4////AAAAAOkGAAAA/4U4////g704////BA+NJQAAAIuFOP///4uN MP///2YPvkQIGIuNOP///4tV6GaJREpk6cj///+LhTD///+LQBxQaDkOAACL RQhQ/xUklEAAgz1AYEAAAbgAAAAAg9D/g+AFUGg5DgAAi0UIUP8VIJRAAFD/ FRiUQABqAItFCFBobQQAAIuFLP///1D/FQyUQABqBIuFLP///1D/FYSUQACj 6IBAAIM96IBAAAAPhJMAAABoYj1AAGoEi4Us////UP8ViJRAAIO9KP///wAP hG0AAABolgAAAI2FPP///1BorA0AAItF3FD/FdiUQACNhTz///9Q6M0UAACD xASFwA+ENgAAAGoAagBoAAgAAIuFKP///1D/FZiUQACNhTz///9QaEIOAABq AIuFKP///1D/FZiUQADpAAAAAOkAAAAA6QAAAAC4AQAAAOkAAAAAX15bycIM AFWL7IPsdFNWV2rri0UIUP8VhJRAAIlFkItFDIlFjOk2AQAAgX0UAAMAAA+E CgAAAIN9FAEPhRwAAABqAItFCFBoaAQAAItFCFD/FbCUQABQ/xUMlEAA6SoB AACDfRQBD4XqAAAAagBqAGhHAQAAi0UQUP8VDJRAAIlFlGpkjUWcUGgyDgAA i0UIUP8VIJRAAFD/FTiUQACNRZxQ6OkTAACDxASJRZiDfZQAD45kAAAAg32Y Yw+OBwAAAMdFmGMAAACLRZhQaDyBQACNRZxQ6MITAACDxAyNRZxQaDIOAACL RQhQ/xUglEAAUP8VKJRAAGpjagBoZQQAAGgzDgAAi0UIUP8VIJRAAFD/FQyU QADpHwAAAGpjagBoZQQAAGgzDgAAi0UIUP8VIJRAAFD/FQyUQABqAItFCFBo aAQAAItFCFD/FbCUQABQ/xUMlEAA6TEAAADpLAAAAIF9jDAOAAAPhL3+//+B fYwyDgAAD4Sw/v//gX2MNA4AAA+E2/7//+kAAAAAi0UQUItFFCX//wAAweAQ i00MgeH//wAAC8FQaBEBAACLRQhQ/xUElEAAuAEAAADpAAAAAF9eW8nCEABV i+yD7HhTVlehIGBAAIlF9Gg4DgAAi0UIUP8VIJRAAIlF+MdF/AAAAABq64tF +FD/FYSUQACJRfxqAGoAaEcBAABoNA4AAItFCFD/FSCUQABQ/xUMlEAAoyxg QABqZI1FjFBoMg4AAItFCFD/FSCUQABQ/xU4lEAAjUWMUOhHEgAAg8QEoyhg QACDPSxgQAAAD44TAAAAoShgQADB4AKNBECNBICjKGBAAIM9KGBAAAAPjQoA AADHBShgQAAAAAAAgT0oYEAANBcAAA+OCgAAAMcFKGBAADQXAABqAGoAaEcB AABoMA4AAItFCFD/FSCUQABQ/xUMlEAAiUWIi0WIozRgQABqZI1FjFCLRYgF zg0AAFCLRfRQ/xXYlEAAaiyNRYxQ6KYRAACDxAhAiUXwi0XwUOiiEQAAg8QE ozBgQACDffwAD4Q2AAAAx0WIAAAAAOkDAAAA/0WIg32IBA+NGAAAAItFiItN /IpEQWSLTYiIgThgQADp2////+kAAAAAaDkOAACLRQhQ/xVAlEAAozxgQABo IGBAAOgt4v//g8QEaECBQABqAGoaaP//AAD/FTyUQACLRfRQ6Fj1//+DxATp AAAAAF9eW8nDVYvsgewQAQAAU1ZXoSBgQACJRfyLRQyJhfT+///pBwEAAGgE AQAAjYX4/v//UGjNDQAAi0X8UP8V2JRAAGjwgEAAagyNhfj+//9Qi0UUi0AM UP8VRJRAAOnUAQAAaAQBAACNhfj+//9QaM0NAACLRfxQ/xXYlEAAaPCAQABq Co2F+P7//1CLRRBQ/xVElEAA6ZwBAADHRRQgYEAAi0UUUItFEFCLRQhQ6Jr2 ///phgEAAItFEMHoECX//wAAD7fAUItFFFCLRRAl//8AAFCLRQhQ6J37//8z wOlaAQAAi0UUi0AIiYXw/v//6RYAAACLRQhQ6Dz9//+DxATpGgAAAOkVAAAA gb3w/v//Nv///w+E2v///+kAAAAA6RIBAADpDQEAAOkIAQAAg630/v//ToG9 9P7//8MAAAAPh/EAAACLhfT+//8zyYqIkjxAAP8kjXo8QAADPEAARztAAII7 QAC6O0AA1ztAAEQ8QAAABQUFBQEFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUF BQUFBQUFBQUFBQUFBQUCBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUF BQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUF BQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUF BQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQMEM8DpAAAAAF9eW8nDVYvs g+wIU1ZXoSBgQACJRfyLRQyJRfjpMwAAAIF9EEIOAAAPhRcAAABqZGjADQAA i0X8UItFCFDoe/P//4PEEOkcAAAA6RcAAADpEgAAAIF9+BIBAAAPhMD////p AAAAAItFFFCLRRBQi0UMUItFCFCh6IBAAFD/FUiUQADpAAAAAF9eW8nCEABV i+yD7ChTVlfHRdgDAAAAx0XcNC1AAItFCIlF6MdF4AAAAADHReQEAAAAx0Xs AAAAAMdF8AAAAABqBf8VCJNAAIlF9MdF+AAAAADHRfxIgUAAjUXYUP8VTJRA AKEElEAAiUXcx0X8WIFAAGoE/xUIk0AAiUX0jUXYUP8VTJRAALgBAAAA6QAA AABfXlvJw1WL7IHs/AAAAFNWV4N9EAAPhQcAAAAzwOmzAgAAi0UQjQSAweAD UGpC/xVUk0AAUP8VUJNAAImFBP///4O9BP///wAPhQcAAAAzwOmAAgAAi0UI oyBgQABoIGBAAOgE3P//g8QEamSNRZxQaK0NAACLRQhQ/xXYlEAAx4Vw//// KAAAAMeFdP///40AAACLRQyJhXj///+LRQiJhXz////HRYBkAAAAjUWciUWE i0UQiUWIg30QAQ+ODAAAAMdFjAEAAADpBwAAAMdFjAAAAACLhQT///+JRZCL hQT///+JhQj////HRZgAAAAA6RIAAAD/RZiDhQj///8og0UUBINFGASLRZg5 RRAPjvoAAABqZI2FDP///1CLRZgFrg0AAFCLRQhQ/xXYlEAAjYUM////UOhZ DAAAg8QEhcAPhFcAAACNhQz///9Q6EIMAACDxARAUGpC/xVUk0AAUP8VUJNA AIuNCP///4lBFIuFCP///4N4FAAPhBkAAACNhQz///9Qi4UI////i0AUUOj5 CwAAg8QI6Q0AAACLhQj////HQBQAAAAAi4UI////xwAoAAAAi4UI////x0AE CAAAAItFCIuNCP///4lBCItFFDPJZosIi4UI////iUgMi4UI////x0AQAAAA AItFGIsAi40I////iUEYi4UI////x0AcAAAAAOno/v//jYVw////UP8V7JJA AMcFJGBAAAAAAADHRZgAAAAAi4UE////iYUI////6QoAAAD/RZiDhQj///8o i0WYOUUQD45QAAAAi4UI////g3gUAA+EOwAAAIuFCP///4tAFFD/FUSTQABQ /xVIk0AAi4UI////i0AUUP8VRJNAAFD/FUCTQACLhQj////HQBQAAAAA6Zr/ //+LhQT///9Q/xVEk0AAUP8VSJNAAIuFBP///1D/FUSTQABQ/xVAk0AAuAEA AADpAAAAAF9eW8nDzFWL7IPsFFNWV8dF+AAAAADHRfwAAAAAx0XwAAAAAMdF 9AAAAABqAotFDFCLRQhQ/xVok0AAiUX4g334AA+EkAAAAItF+FCLRQhQ/xVk k0AAiUXsi0X4UItFCFD/FSCTQACJRfyDffwAD4RfAAAAi0X8UP8VXJNAAIlF 8IN98AAPhDkAAACLRexQagL/FVSTQABQ/xVQk0AAiUX0g330AA+EFAAAAItF 7FCLRfBQi0X0UOg0CgAAg8QM6QAAAACLRfxQ/xVYk0AA6QAAAADpAAAAAItF 9OkAAAAAX15bycNVi+yD7AxTVleDfQwAD4RsAAAAi0UMUOhrAQAAg8QEiUX0 i0UMUOgwAQAAg8QEiUX4i0UMUOg3AQAAg8QEiUX8agOLRQhQ/xUMk0AAagCL RQxQi0X0UItF/FBqAGoAagCLRfxQi0X4UItFFFCLRRBQi0UIUP8VFJNAAOkA AAAA6QAAAABfXlvJw1WL7FNWV4tFCFDorgAAAIPEBANFCOkAAAAAX15bycNV i+yD7AhTVleLRQhmi0AOZolF/ItFCFDogQAAAIPEBIP4JA+CDgAAAItFCItA IIlF+OkHAAAAx0X4AAAAAIN9+AAPhSoAAACLRfwl//8AAIP4EA+NEgAAALgB AAAAik380+CJRfjpBwAAAMdF+AAAAACLRfjpAAAAAF9eW8nDVYvsU1ZXi0UI UOhy////g8QEweAC6QAAAABfXlvJw1WL7FNWV4tFCIsA6QAAAABfXlvJw1WL 7FNWV4tFCItABOkAAAAAX15bycNVi+xTVleLRQiLQAjpAAAAAF9eW8nDVYvs g+wQU1ZXi0UIZotADmaJRfiLRQhQ6KL///+DxASD+CQPgg4AAACLRQiLQCCJ RfTpBwAAAMdF9AAAAACDffQAD4UqAAAAi0X4Jf//AACD+BAPjRIAAAC4AQAA AIpN+NPgiUX06QcAAADHRfQAAAAAi0X0weACiUX8i0UIiUXwi0UIUOg1//// g8QEi038A8gDTfCLwekAAAAAX15bycNVi+yD7ChTVldqIItFCFD/FXSTQACJ RdyDfdz/D4UHAAAAM8DpmgEAAGoOjUXgUItF3FD/FXCTQACD+A4PhBEAAACL RdxQ/xVsk0AAM8DpcAEAAItF4CX//wAAM8lmiw1sgUAAO8EPhBEAAACLRdxQ /xVsk0AAM8DpRgEAAItF4oPoDolF2ItF2FBqAv8VVJNAAFD/FVCTQACJRfiD ffgAD4URAAAAi0XcUP8VbJNAADPA6QwBAADHRfQAAAAAg33YAA+GlwAAAItF 2D0AgAAAD4IFAAAAuACAAABmiUXwi0XwJf//AABQi0X0A0X4UItF3FD/FXCT QACLTfCB4f//AAA7wQ+EMwAAAItF3FD/FWyTQACLRfhQ/xVEk0AAUP8VSJNA AItF+FD/FUSTQABQ/xVAk0AAM8DphgAAADPAi03wgeH//wAAK8H32ClF2ItF 8CX//wAAAUX06V////+LRdxQ/xVsk0AAi0X4UOis/f//g8QEiUX8g338DA+C EAAAAA+GMwAAAIN9/BAPgykAAACLRfhQ/xVEk0AAUP8VSJNAAItF+FD/FUST QABQ/xVAk0AAM8DpCAAAAItF+OkAAAAAX15bycNVi+yD7ExTVleLRQhQ6NkF AACDxASFwA+ECgAAAIN9DAAPhQcAAAAzwOnXAAAAagBogAAAAGoCagBqA2gA AADAi0UIUP8VYJNAAIlFyI191It1DLkLAAAA86WNRdRQ6NT8//+DxASLTegD yANN1IlNzMdF0AAAAACDfcgAD4R0AAAAZqFwgUAAZolFtItFzIPADsHoAolF tmbHRbwAAGaLRbxmiUW6i0XMg8AOK0XoiUW+agCNRcRQag6NRbRQi0XIUP8V fJNAAGoAjUXEUItFzFCLRQxQi0XIUP8VfJNAAItFyFD/FXiTQADHRdABAAAA 6QcAAADHRdAAAAAAi0XQ6QAAAABfXlvJw1WL7IPsVFNWV4N9CAAPhQcAAAAz wOkuAwAAjUW4UGoYi0UIUP8V+JJAAIXAD4UHAAAAM8DpDwMAAIN9DAAPhQsA AABqD/8VCJNAAIlFDItFyCX//wAAM8lmi03KD6/BZolFrItFrCX//wAAg/gB D48LAAAAZsdFrAEA6T4AAACLRawl//8AAIP4BA+PCwAAAGbHRawEAOkiAAAA i0WsJf//AACD+AgPjwsAAABmx0WsCADpBgAAAGbHRawYAMdF1CgAAACLRbyJ RdiLRcCJRdxmx0XgAQBmi0WsZolF4sdF5AAAAADHRegAAAAAx0XsAAAAAMdF 8AAAAADHRfQAAAAAx0X4AAAAAI1F1FDoHPv//4PEBItN1APIiU2wagD/FRSU QACJRbRqAItFDFCLRbRQ/xUAk0AAiUUMi0W0UP8VBJNAAItFsFBqQv8VVJNA AFD/FVCTQACJRfyDffwAD4UtAAAAagGLRQxQi0W0UP8VAJNAAItFtFD/FQST QACLRbRQagD/FRCUQAAzwOm3AQAAi0X8iUXQjXXUi33QuQoAAADzpWoAi0XQ UGoAi0XcJf//AABQagCLRQhQi0W0UP8V9JJAAI191It10LkKAAAA86WDfegA D4UfAAAAi0W8i02sgeH//wAAD6/Bg8Afg+DgwegDD69FwIlF6I1F1FDoKfr/ /4PEBItN6APIA03UiU2wi0X8UP8VRJNAAFD/FUiTQABqAItFsFCLRfxQ/xVE k0AAUP8VhJNAAFD/FVCTQACJRfyDffwAD4UtAAAAagGLRQxQi0W0UP8VAJNA AItFtFD/FQSTQACLRbRQagD/FRCUQAAzwOnNAAAAi0X8iUXQagCLRdBQi0X8 UOj9+f//g8QEUItF3CX//wAAUGoAi0UIUItFtFD/FfSSQACFwA+FWAAAAP8V gJNAAIlFsItF/FD/FUSTQABQ/xVIk0AAi0X8UP8VRJNAAFD/FUCTQABqAYtF DFCLRbRQ/xUAk0AAi0W0UP8VBJNAAItFtFBqAP8VEJRAADPA6TsAAACNfdSL ddC5CgAAAPOlagGLRQxQi0W0UP8VAJNAAItFtFD/FQSTQACLRbRQagD/FRCU QACLRfzpAAAAAF9eW8nDVYvsgewYBAAAU1ZXx4X0+///AAAAAI2FAPz//4mF +Pv//2oMi0UIUP8VGJNAAImF6Pv//+nvAAAAZseF/Pv//wADZseF/vv//wAB jYUA/P//UGgAAQAAagCLRQhQ/xUQk0AAhcAPhQUAAADpDgEAAI2F/Pv//1D/ FfySQACJhfT7//+DvfT7//8AD4UFAAAA6ekAAADHhfD7//8AAAAA6QYAAAD/ hfD7//+BvfD7//8AAQAAD41aAAAAi4Xw+///ioSFAvz//4iF7Pv//4uF8Pv/ /4qEhQH8//+Ihe37//+LhfD7//+KhIUA/P//iIXu+///xoXv+///AIuF7Pv/ /4uN8Pv//4uV+Pv//4kEiumQ////6WUAAADpYAAAAOlbAAAA6VYAAACDrej7 //8Ig73o+///GA+HQgAAAIuF6Pv//zPJiojbS0AA/ySNx0tAAK9KQACPS0AA j0tAAI9LQACUS0AAAAQEBAQEBAQBBAQEBAQEBAIEBAQEBAQEA4uF9Pv//+kA AAAAX15bycP/JeiTQAD/JeSTQAD/JeCTQAD/JdyTQAD/JdiTQAD/JdSTQAD/ JdCTQAD/JcyTQAD/JciTQAD/JcSTQABkoQAAAABVi+wTw9Yr/2Zj24vBkJj8 C8T5+fgDxviQ1hPD1vmYC8D81ivE+UD4+Phd6A0AAADWM8XpCAAAADExSBPD wyvHPSguewjo8P///+hkAAAA+egMAAAAI8VA6QkAAAAxFzPEE8GQw0hI6PP/ ///B6A8r0mZj/+gNAAAAG8PW6QoAAAAxNfkLwzPA/MP4+YPsBKGUkEAAiQQk 6AkAAAD86QkAAAAxNfwTx5jDC8Yzwejy////wwVxVHsIZGehAACD7ASJBCQr wGSJIIEYU1j7OIA+InUNRusKPCB2BkaAPiB3+oA+AHQLgD4gdwZGgD4AdfXH RagAAAAAjYV8////UP8VJJNAAPZFqAG4CgAAAHQED7dFrFBWagBqAP8VPJNA AFDo4gAAAFD/FbiTQADrI4tF7IsAiwCJReD/dexQ6CsAAACDxAjDi2Xo/3Xg /xXAk0AAg8QEx0X8/////4tF8F9kowAAAABeW4vlXcPM/yW8k0AA/yWwk0AA aAAAAwBoAAABAOgLAAAAg8QIw8P/JZiTQAD/JZyTQADMzE1QUi5ETEwAU0NS U0FWRQBQd2RDaGFuZ2VQYXNzd29yZEEAi0QkCItMJAQ7wSvBwzPAi0wkBIA5 MHwXihGA+jl/EGvACg++0kGNRALQgDkwfenDg+wEjUQkAGoAUP90JBBqYf8V UJRAAIPEBMNkoQAAAABVi+xq/2g0cEAAaNJNQABQi00QZIklAAAAAItFCIPs KKPogUAAU1ZXiWXox0X8AAAAAItF4A++AYP4IH8TdFeFwHRWuP////+JRfzp rQAAAIP4QX8OdHqD+C10OoP4L3Q16+CD+Ex/CXRGg/hDdDPr0oP4UHREg/hT dE2D+GF0UYP4Y3Qdg/hsdCaD+HB0K4P4c3Q0661B65xqAOi1BQAA61H/FVSU QABQ6KcFAADrQ8cFBIJAAAEAAABBgDkgdPpR6F8FAADrK2oA6M0DAADrIkGA OSB0+lHoqQUAAOsU/3Xs/xWMk0AAw4tl6GoA6O3+//+DxATHRfz/////i03w X2SJDQAAAABeW4vlXcIQAFWL7IPsCIM98IFAAAAPhTgBAACDPfSBQAAAD4Ur AQAAi0UMg/gQD4TqAAAAPQCAAAAPhP0AAACDPfiBQAAAD4UHAQAAg/ggdwx0 UIP4GHQ06fYAAAA9AAEAAHRRPQQBAAB0Sj0AAgAAdFc9AQIAAHQ8PQQCAAB0 NT0HAgAAdC7pxwAAAIN9EAAPhL0AAABqAP8VWJRAAOmwAAAAagD/FViUQAC4 AQAAAOmwAAAAagBqAGoQ/3UI/xXAlEAA6YoAAACNRfhQ/xXElEAAi0X4KwVQ YEAAdAR9AvfYi038Kw1UYEAAdAR9AvfZA8g7DRSCQAB2WGoAagBqEP91CP8V wJRAAItV+ItN/IkVUGBAAIkNVGBAAOs1/3UI6MQEAACDxASFwHUmaFBgQAD/ FcSUQAAzwOspoQCCQACFwHQH/3UI/9DrGbgBAAAA6xL/dRT/dRD/dQz/dQj/ FQSUQACL5V3CEABVi+xWV4t1DIP+DHcdD4QuAQAAg/4BD4ScAAAAg/4CD4Tt AAAA6eUBAACD/lN3FA+ESwEAAIP+Dw+ECgEAAOnMAQAAgf4AAQAAdxQPhGkB AACD/nsPhCYBAADpsAEAAIH+BAEAAA+ETwEAAIH+EgEAAA+EXgEAAIH+EwEA AA+EdwEAAIH+AAIAAA+CgAEAAIH+AQIAAA+GHwEAAIH+BAIAAA+EEwEAAIH+ BwIAAA+EBwEAAOlXAQAAaMiBQAD/FTyTQACjCIJAAIXAdCFo1IFAAFD/FTCT QACjDIJAAIXAdAxqAP91CP/QoxCCQABoUGBAAP8VxJRAAIM98IFAAAAPhQoB AABqAP8VWJRAAOn9AAAAgz0IgkAAAHQZiw0MgkAAhcl0D6EQgkAAhcB0BlD/ dQj/0WoA/xVclEAA6c4AAAAzwOnWAAAAgz30gUAAAHQV/3UU/3UQVv91CP8V BJRAAOm4AAAAgz3wgUAAAA+FnAAAAGoA/xVYlEAA6Y8AAACDPfCBQAAAD4SC AAAA/3UI/xWwlEAAi/iF/3QXV/8VvJRAAIXAdAz/dRRXVlf/FcCUQAC4AQAA AOtkgz30gUAAAHRM/3UU/3UQVv91CP8VBJRAAOtJgz3wgUAAAHUxi0UQPUDw AAB0Dj1Q8AAAdAc9QPEAAHUZM8DrJIM99IFAAAB0BDPA6xdqAP8VKJNAAP91 FP91EFb/dQjo1L7//19eXcIQAOnxAwAAVYvsg+xgoeiBQABTVlcz9mpkUIl1 uP8VHJRAAGoEiUW0x0XEJIJAAIl1wP8VCJNAAIlFvIl1rKHogUAAi30IiUWw iXWox0WgKwAAAMdFpMZQQAA7/nQxjUXwUFf/FXSUQACLRfiLTfyJReiJTeTH RewAAABSxwXwgUAAAQAAAMdF8DyCQADrW2oAizVwlEAA/9ZqAYlF6P/WvggA AABoRIJAAGgkgkAAiUXkx0XsAAAAlsdF8ESCQAD/FWyUQACL2IXbdBlT/xW8 lEAAhcB0DlP/FbSUQAAzwOmkAAAA6Bj///+NRaBQ/xVMlEAAZoXAdCxqAKHo gUAAUGoAV/915P916GoAagD/dez/dfBoJIJAAFb/FdyUQACj7IFAAIM97IFA AAB0U4M98IFAAAB1DKHsgUAAUP8VtJRAAGoAjUXIagCLNdCUQABqAFD/1oXA dCiLPfiTQACLHcyUQACNRchQ/9eNRchQ/9NqAI1FyGoAagBQ/9aFwHXk6BAD AACLRdBfXluL5V3DVv90JAjojvn//4PEBIvwhfZ0Flb/FbyUQACFwHQLVuhT /v//g8QE6wW4/////17DoeiBQABQ6HXC//+FwLgAAAAAdBxqAGh0FkAA/3Qk DGjTBwAA/zXogUAA/xV4lEAAw1b/dCQI6C35//+DxASL8IX2dAtW/xW8lEAA hcB1CP8VVJRAAIvwVugEAAAAM8Bew1Zo4E1AAP8VNJNAAIvwhfZ0JmjwTUAA Vv8VMJNAAIXAdA9qAGoA/3QkEGjoTUAA/9BW/xVMk0AAXsIEAIPsHIM9+IFA AABTVlcPheEAAACDPfSBQAAAD4XUAAAAgz0AgkAAAA+EtgAAAIs1LJNAAP/W i/iLHRiCQACF23QXV6EcgkAAUOhx+P//g8QIO8MPgosAAAChIIJAAIP4/3QR V1DoVfj//4PECD3IAAAAcnqLfCQsagONRCQQaBMBAABoEwEAAIsdfJRAAMcF +IFAAAEAAABXUP/TjUQkDGoDaBMBAABoEwEAAFdQ/9NqAGoAaACAAABX/xUM lEAAo/SBQACFwMcF+IFAAAAAAAB1CGoA/xVYlEAA/9ajIIJAAOsKxwX0gUAA AQAAAKH0gUAA6wIzwF9eW4PEHMNVi+yD7ERWV/8VkJNAAIvwigA8InUdiz2A lEAAVv/Xi/CKAITAdAQ8InXxgD4idRdG6xSLPYCUQAA8IHYKVv/XgDggi/B3 9oA+AHQPgD4gdwpW/9eAOACL8HXxx0XoAAAAAI1FvFD/FSSTQAD2RegBuAoA AAB0BA+3RexQVmoAagD/FTyTQABQ6H73//9Qi/D/FYiTQACLxl9ei+Vdw1WL 7IPsDIM9/IFAAAB0BeiKAAAAjUX8UGgMcEAAaAEAAID/FdySQACFwHVujUX0 jU34x0X0BAAAAFBRagBqAGiMgUAA/3X8/xXgkkAAhcB1QIN9+AB0OmikgUAA /xU0k0AAo/yBQACFwHQmaLSBQABQ/xUwk0AAowCCQACFwHQMagHozPb//4PE BOsF6A0AAAD/dfz/FcySQACL5V3DVqH8gUAAhcB0LlD/FUyTQADHBfyBQAAA AAAAgz0AgkAAAHQUxwUAgkAAAAAAAGoA6ID2//+DxARewwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP////90TUAAi01AAENvbnRyb2wgUGFuZWxcRGVz a3RvcAAAAFNjcmVlblNhdmVfRGF0YQD/////Mk9AADxPQAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAA AAAAAAAAAABXTDMyRExMLkRMTABJbml0V2lsZGxpZmUAAAAAR2V0U2F2ZXJX aW5kb3dzAEluaXRQcmV2aWV3AERpc3BsYXlQcmV2aWV3AABTdXNwZW5kQW5p bWF0aW9uAAAAAERvV2FrZVVwAAAAAENsb3NlUHJldmlldwAAAAAtLS0tAAAA AAAAAAAlaSAlaSAlaQAAAABNb25pdG9yV2luZG93Q2xhc3MAAE1vbml0b3JX aW5kb3dDbGFzcwAAJWkgJWkgJWkgJWkgJWkgJWkgJWkgJWkAAAAAAAAAAAAA AAAAOA4AABwMAAAvDgAAHQwAADAOAAAdDAAAMQ4AAB4MAAAyDgAAHgwAADMO AAAeDAAANQ4AAB4MAAA0DgAAHgwAADkOAAAhDAAAJWkAACVpAABXaW5kb3dz AE1vbml0b3JDbGFzcwAAAABNb25pdG9yV2luZG93Q2xhc3MAAEJNAABCTQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAU2NyZWVuU2F2ZVVzZVBhc3N3b3Jk AAAAUEFTU1dPUkQuQ1BMAAAAAFZlcmlmeVNjcmVlblNhdmVQd2QASU1NMzIu RExMAAAASW1tQXNzb2NpYXRlQ29udGV4dAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAP////9XaW5k b3dzU2NyZWVuU2F2ZXJDbGFzcwBQcmV2aWV3AFNjcmVlbiBTYXZlcgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAICRAADQoSA3/////1CVAACYkwAACJEA ALPCHzf/////spcAACCTAADgkQAAzaEgN/////9mmwAA+JMAANyQAABywj41 /////yKcAAD0kgAAtJAAAM2hIDf/////kJwAAMySAADYkQAA0KEgN/////+s nAAA8JMAANCQAADNoSA3/////8qcAADokgAAAAAAAAAAAAAA2EAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAIKcAABwnAAAXpwAAE6cAABAnAAALJwA AAAAAAARAACAuJwAAAAAAADOmwAA2psAAOibAAC+mwAArJsAAJqbAACGmwAA +JsAAHKbAAASnAAAAAAAAMSWAABclwAAbpcAAPaVAAAGlgAAGJYAACiWAAA4 lgAATJYAAFqWAABqlgAAepYAAIiWAACWlgAApJYAALSWAAAulwAA1JYAAOaW AAD2lgAAAJcAAAqXAAAUlwAAIpcAADyXAABMlwAAkpcAAHaXAACglwAAAAAA ANSVAADolQAAxpUAALaVAACmlQAAlpUAAIqVAAB8lQAAdJUAAGaVAABelQAA RpUAAD6VAAA0lQAAKpUAACKVAAASlQAAApUAAPiUAADulAAA5JQAAAAAAACe nAAAAAAAAOSaAAAwmQAAQpkAAFSZAABmmQAAdJkAAISZAACQmQAAmJkAAKaZ AACymQAAwJkAANKZAADkmQAA9pkAAAaaAAAWmgAAKJoAAD6aAABUmgAAYJoA AHKaAACEmgAAnJoAALKaAAC+mgAAEpkAACCZAAAGmQAABpsAABSbAAAomwAA OJsAAEqbAABamwAA9JgAAOKYAADWmAAAxpgAALSYAACmmAAAmJgAAHaYAABo mAAAWJgAAE6YAABCmAAALJgAACCYAAAUmAAABJgAAPSXAADglwAA0JoAAPia AADOlwAAwJcAAIaYAAAAAAAARBbov30W6L/qFei/0RTov6oZ6L80Fei/AAAA AP6D6b/9juu/AAAAADkU8r+NFPK/pSHyv+4v8r/0L/K/E0nyv5Yo8r/VIPK/ aRTyv+8W8r8AAAAAIgv4v613978ILfm/OGr3v6ht97/Qdve/0v/3vxZ39789 bve/+W33vxtu97/N4Pi/1233v7RI979DL/m/SC/5v9t697+f+vm/Kgr4v7u1 +b/kdPe/unT3v23g97/Rb/e/a1H4vwUJ+r/41Pi/NNv5v9rF+L8AAAAAVTDE f3VIw3/vHcN/9R3Df1Rzxn/7HcN/zR3Df0Aew38kV8N/lAXEfwgHxH+BFcN/ iu3Ef5I8w3/RO8N/H+7Ef9cbw38eHMN/IgfFfxw8w3/6WsN/AAAAAGYWzn8A AAAAaVf1v8FE9b+6UPW/zVv1vy5B9b82WPW/kCD1v50k9b+YIPW/+Vn1v/xO 9b9tF/W/1Bv1v3JQ9b9TT/W/Rxv1vwQY9b/3WPW/kBn1v8QR9b/AWPW/YkP1 v2kS9b/1UfW/ii31v78k9b8rGPW/xi31v3wY9b8YWfW/9lL1v8VP9b/VL/W/ DVj1vz5J9b+nVfW/TVb1v11U9b/nJPW/vCH1v2BE9b9STPW/axX1v/ck9b/P JPW/1FP1v3Ek9b+7JPW/qRv1v6VO9b8IV/W/7h71v7FR9b8zR/W/PVf1v3Ah 9b+MVfW/cVz1vwAAAAApBHN0cmNweQAALQRzdHJsZW4AACQEc3NjYW5mAABP AD8/MkBZQVBBWElAWgAAUAA/PzNAWUFYUEFYQFoAAKwDYXRvaQAAMgRzdHJy Y2hyACEEc3ByaW50ZgCtA2F0b2wAAAYEbWVtY3B5AABNU1ZDUlQyMC5kbGwA ADwCX2V4aXQAyAFfWGNwdEZpbHRlcgC4A2V4aXQAAN4BX19wX19hY21kbG4A cAJfaW5pdHRlcm0A0QFfX2dldG1haW5hcmdzAAoCX2FkanVzdF9mZGl2AADg AV9fcF9fY29tbW9kZQAA4wFfX3BfX2Ztb2RlAAAzAl9leGNlcHRfaGFuZGxl cjMAACECX2NvbnRyb2xmcAAAMAFHZXRUaWNrQ291bnQAAAMBR2V0UHJvY0Fk ZHJlc3MAAHgBTG9hZExpYnJhcnlBAAD9AVNldExhc3RFcnJvcgAA6wBHZXRN b2R1bGVIYW5kbGVBAABHAUdsb2JhbEZyZWUAAEoBR2xvYmFsSGFuZGxlAABR AUdsb2JhbFVubG9jawAAjQBGcmVlTGlicmFyeQBLAUdsb2JhbExvY2sAAEAB R2xvYmFsQWxsb2MAjwBGcmVlUmVzb3VyY2UAAIsBTG9ja1Jlc291cmNlAAB9 AUxvYWRSZXNvdXJjZQAAFwJTaXplb2ZSZXNvdXJjZQAAfgBGaW5kUmVzb3Vy Y2VBAF8CX2xjbG9zZQBjAl9scmVhZAAAYgJfbG9wZW4AABYAQ2xvc2VIYW5k bGUATwJXcml0ZUZpbGUAKwBDcmVhdGVGaWxlQQDhAEdldExhc3RFcnJvcgAA TQFHbG9iYWxSZUFsbG9jABQBR2V0U3RhcnR1cEluZm9BABgCU2xlZXAAJgJV bmhhbmRsZWRFeGNlcHRpb25GaWx0ZXIAAGIARXhpdFByb2Nlc3MAnwBHZXRD b21tYW5kTGluZUEAS0VSTkVMMzIuZGxsAAB3AUxvYWRTdHJpbmdBAEgBSW52 YWxpZGF0ZVJlY3QAAOgAR2V0RGVza3RvcFdpbmRvdwAA5QBHZXRDdXJzb3JQ b3MAAKMBUG9zdE1lc3NhZ2VBAABcAUlzV2luZG93AACtAEVuZERpYWxvZwDi AVNldEZvcmVncm91bmRXaW5kb3cAFQFHZXRQYXJlbnQA8wFTZXRSZWN0AIYA RGVzdHJveVdpbmRvdwCFAERlc3Ryb3lNZW51AAcCU2V0V2luZG93UG9zAABS AENyZWF0ZVdpbmRvd0V4QQAgAUdldFN5c0NvbG9yAAQAQXBwZW5kTWVudUEA UQBDcmVhdGVQb3B1cE1lbnUANwJVcGRhdGVXaW5kb3cAAKgBUHRJblJlY3QA AAQCU2V0V2luZG93TG9uZ0EAADABR2V0V2luZG93TG9uZ0EAAK8ARW5kUGFp bnQAAAkAQmVnaW5QYWludAAALQBDaGVja01lbnVJdGVtACYCVHJhY2tQb3B1 cE1lbnUAADMAQ2xpZW50VG9TY3JlZW4AAH0ARGVmV2luZG93UHJvY0EAAIgB TWVzc2FnZUJveEEAxgFTZW5kTWVzc2FnZUEAALkBUmVsZWFzZURDAOYAR2V0 REMAFgJTaG93V2luZG93AABrAUxvYWRJY29uQQDrAEdldERsZ0l0ZW0AACwA Q2hlY2tEbGdCdXR0b24AAAoCU2V0V2luZG93VGV4dEEAAL8BU2NyZWVuVG9D bGllbnQAADMBR2V0V2luZG93UmVjdAAiAUdldFN5c3RlbU1lbnUANQFHZXRX aW5kb3dUZXh0QQAAzAFTZW5kTm90aWZ5TWVzc2FnZUEAAFgBSXNEbGdCdXR0 b25DaGVja2VkAABDAldpbkhlbHBBAAARAENhbGxXaW5kb3dQcm9jQQCrAVJl Z2lzdGVyQ2xhc3NBAAAcAlN5c3RlbVBhcmFtZXRlcnNJbmZvQQDxAEdldEZv cmVncm91bmRXaW5kb3cA2AFTZXRDdXJzb3IApQFQb3N0UXVpdE1lc3NhZ2UA jABEaXNwYXRjaE1lc3NhZ2VBAAAsAlRyYW5zbGF0ZU1lc3NhZ2UAAA0BR2V0 TWVzc2FnZUEAxgBGaW5kV2luZG93QQAjAUdldFN5c3RlbU1ldHJpY3MAANwA R2V0Q2xpZW50UmVjdACKAERpYWxvZ0JveFBhcmFtQQChAVBlZWtNZXNzYWdl QQAAHgBDaGFyTmV4dEEAVVNFUjMyLmRsbAAASgFTZXRESUJpdHNUb0Rldmlj ZQBfAVNldFN0cmV0Y2hCbHRNb2RlAO4AR2V0U3RvY2tPYmplY3QAACkBUmVh bGl6ZVBhbGV0dGUAAD0BU2VsZWN0UGFsZXR0ZQC7AEdldERJQml0cwDeAEdl dE9iamVjdEEAADUAQ3JlYXRlUGFsZXR0ZQDwAEdldFN5c3RlbVBhbGV0dGVF bnRyaWVzALwAR2V0RGV2aWNlQ2FwcwBHREkzMi5kbGwA4QBSZWdRdWVyeVZh bHVlRXhBAADYAFJlZ09wZW5LZXlBANkAUmVnT3BlbktleUV4QQDsAFJlZ1Nl dFZhbHVlRXhBAADGAFJlZ0NyZWF0ZUtleUV4QQDCAFJlZ0Nsb3NlS2V5AEFE VkFQSTMyLmRsbAAAUgBTaGVsbEFib3V0QQBTSEVMTDMyLmRsbAA2AFByb3Bl cnR5U2hlZXRBAABDT01DVEwzMi5kbGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAFDFBTAAAAAAAAAGAAIAAABAAACAAwAAAGAAAIAFAAAAgAAA gAYAAACgAACADgAAAOgAAIAQAAAAAAEAgAAAAABQxQUwAAAAAAAAAgDCCwAA GAEAgMMLAAAwAQCAAAAAAFDFBTAAAAAAAAACAAEAAABIAQCAAgAAAGABAIAA AAAAUMUFMAAAAAAAAAIA0wcAAHgBAIARDgAAkAEAgAAAAABQxQUwAAAAAAAA BwABAAAAqAEAgCAAAADAAQCAvwAAANgBAIDAAAAA8AEAgNsAAAAIAgCA3QAA ACACAIDeAAAAOAIAgAAAAABQxQUwAAAAAAAAAQBkAAAAUAIAgAAAAABQxQUw AAAAAAAAAQABAAAAaAIAgAAAAABQxQUwAAAAAAAAAQAJBAAAgAIAAAAAAABQ xQUwAAAAAAAAAQAJBAAAkAIAAAAAAABQxQUwAAAAAAAAAQAJBAAAoAIAAAAA AABQxQUwAAAAAAAAAQAJBAAAsAIAAAAAAABQxQUwAAAAAAAAAQAJBAAAwAIA AAAAAABQxQUwAAAAAAAAAQAJBAAA0AIAAAAAAABQxQUwAAAAAAAAAQAJBAAA 4AIAAAAAAABQxQUwAAAAAAAAAQAJBAAA8AIAAAAAAABQxQUwAAAAAAAAAQAJ BAAAAAMAAAAAAABQxQUwAAAAAAAAAQAJBAAAEAMAAAAAAABQxQUwAAAAAAAA AQAJBAAAIAMAAAAAAABQxQUwAAAAAAAAAQAJBAAAMAMAAAAAAABQxQUwAAAA AAAAAQAJBAAAQAMAAAAAAABQxQUwAAAAAAAAAQAJBAAAUAMAAAAAAABQxQUw AAAAAAAAAQAJBAAAYAMAADCxAAAMCwAAAAAAAAAAAAA8vAAACAwAAAAAAAAA AAAAvKYAAOgCAAAAAAAAAAAAAKSpAAAoAQAAAAAAAAAAAAAssAAAAgEAAAAA AAAAAAAA8KoAADoFAAAAAAAAAAAAAETIAAA2AAAAAAAAAAAAAAD4ywAASAEA AAAAAAAAAAAAfMsAAHoAAAAAAAAAAAAAAJDKAADsAAAAAAAAAAAAAAB8yAAA UgAAAAAAAAAAAAAA0MgAADoBAAAAAAAAAAAAAAzKAACCAAAAAAAAAAAAAADM qgAAIgAAAAAAAAAAAAAAcKMAAEwDAAAAAAAAAAAAAEyJNAAAAFYAUwBfAFYA RQBSAFMASQBPAE4AXwBJAE4ARgBPAAAAAAC9BO/+AAABACgABAA2AQAAKAAE ADYBAAA/AAAAAAAAAAQABAACAAAAAAAAAAAAAAAAAAAAqgIAAAEAUwB0AHIA aQBuAGcARgBpAGwAZQBJAG4AZgBvAAAAhgIAAAEAMAA0ADAAOQAwADQARQA0 AAAATAAWAAEAQwBvAG0AcABhAG4AeQBOAGEAbQBlAAAAAABNAGkAYwByAG8A cwBvAGYAdAAgAEMAbwByAHAAbwByAGEAdABpAG8AbgAAAGIAHQABAEYAaQBs AGUARABlAHMAYwByAGkAcAB0AGkAbwBuAAAAAABNAGkAYwByAG8AcwBvAGYA dAAgAFAAbAB1AHMAIQAgAFMAYwByAGUAZQBuACAAUwBhAHYAZQByAAAAAAAy AAkAAQBGAGkAbABlAFYAZQByAHMAaQBvAG4AAAAAADQALgA0ADAALgAzADEA MAAAAAAAMAAIAAEASQBuAHQAZQByAG4AYQBsAE4AYQBtAGUAAABXAEwAMwAy AFMAQwBSAAAAdgApAAEATABlAGcAYQBsAEMAbwBwAHkAcgBpAGcAaAB0AAAA QwBvAHAAeQByAGkAZwBoAHQAqQAgAFMAbwBjAGgAYQAgAEMAbwBtAHAAdQB0 AGkAbgBnACwAIABJAG4AYwAuACAAMQA5ADkAMwAtADUALgAAAAAAQAAMAAEA TwByAGkAZwBpAG4AYQBsAEYAaQBsAGUAbgBhAG0AZQAAAFcATAAzADIAUwBD AFIALgBTAEMAUgAAAGoAJQABAFAAcgBvAGQAdQBjAHQATgBhAG0AZQAAAAAA TQBpAGMAcgBvAHMAbwBmAHQArgAgACAAUABsAHUAcwAhACAAIABmAG8AcgAg ACAAVwBpAG4AZABvAHcAcwCuACAAIAA5ADUAAAAAADYACQABAFAAcgBvAGQA dQBjAHQAVgBlAHIAcwBpAG8AbgAAADQALgA0ADAALgAzADEAMAAAAAAARAAA AAEAVgBhAHIARgBpAGwAZQBJAG4AZgBvAAAAAAAkAAQAAABUAHIAYQBuAHMA bABhAHQAaQBvAG4AAAAAAAkE5AQoAAAAIAAAAEAAAAABAAQAAAAAAAACAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDA wACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AAAAB3AHh4ePj4eH gAdwAAAAAHgHAAAAAAAAAABwDwAAAAB4d4d3d3f3d3d4jw8AAAAAd4iIiIiI iIiIiIh3AAAAAAd3d3d3d3d3d3d3cAAAAAAAAAAAAAAAAAAAAAAAAA+IiIiI iIiIiIiIiIiIiIAPd3d3d3d3d3d3d3d3p3eAD3d3d3d3d3d3d3d3erp3gA93 d3d3d3d3d3d3d3end4APd3d3d3d3d3d3d3d3d3eAD3f///////////////93 gA93jgAAAAiACIAAAADvd4APd44AAACIgAiIAAAA73eAD3eO4AAA//AP/wAA Du93gA93ju7u7oiIiIju7u7vd4APd4d3d37oiIiO7u7u73eAD3eP///+7u7u 7u7u7u93gA93ju/+7u7u53d3d3d/d4APd47u7u7u7u///////3eAD3eO7u7u 7u7u/+///u93gA93ju7u7u7u7u7u//7vd4APd4d3fgAAAAAADu7u73eAD3eP //7uAAAHDu7u7u93gA93j//u7gAABw7u7u7vd4APd4/+7u7gAADu7u7u73eA D3eO7u7u7u7u7u7u7u93gA93iIiIiIiIiIiIiIiPd4APd3d3d3d3d3d3d3d3 d3eAD3d3d3d3d3d3d3d3d3d3gA////////////////////AAAAAAAAAAAAAA AAAAAAAA+AAAH/AAAA/wAAAP8AAAD/gAAB8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAo AAAAEAAAACAAAAABAAQAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA gAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAA AP8A/wD//wAA////AACAAAAAAAgAAHeHd3d4dwAAAAAAAAAAAId3d3d3d3hw h3d3d3d3g3CHd3d3d3d3cIeAAAAAAA5wh4ZmeIdmbnCHd3foju7ucIeO7u53 d3dwh47u7u7n7nCHd3YAAG7ucId37gAG7u5wh4iIiIiIh3CHd3d3d3d3cAiI iIiIiIiAwAMAAMADgAAAAAAAAACAAAAAAAAAAIAAAAAAAAAAwAAAAIAAAAD/ AAAAAAAAAP8AAAAAAAAA/wAAAAAAAADSAAAAAQACACAgEAABAAQA6AIAAAEA EBAQAAEABAAoAQAAAgAAAMAAyJAAAAAADAAAAAAA7QDcAAAAAABTAGUAdAAg AGYAcgBvAG0AIABzAHQAcgBpAG4AZwAgAHQAYQBiAGwAZQAAAAgATQBTACAA UwBhAG4AcwAgAFMAZQByAGkAZgAAAAAAAlAAAAAADQAIABoBKwA2Dv//ggBZ AG8AdQAgAGMAYQBuACAAZABpAHMAcABsAGEAeQAgAHQAaABlACAAcwBjAHIA ZQBlAG4AIABzAGEAdgBlAHIAIABpAG0AbQBlAGQAaQBhAHQAZQBsAHkALAAg AG8AcgAgAHAAcgBlAHYAZQBuAHQAIABpAHQAIABmAHIAbwBtAAoAYQBwAHAA ZQBhAHIAaQBuAGcAIABhAHQAIABhAGwAbAAsACAAYgB5ACAAbQBvAHYAaQBu AGcAIAB0AGgAZQAgAG0AbwB1AHMAZQAgAHAAbwBpAG4AdABlAHIAIAB0AG8A IABhACAAYwBvAHIAbgBlAHIAIABvAG4AIAAKAHQAaABlACAAcwBjAHIAZQBl AG4ALgAgACAAQwBsAGkAYwBrACAAdABoAGUAIABjAG8AcgBuAGUAcgBzACAA eQBvAHUAIAB3AGEAbgB0ACAAdABvACAAdQBzAGUALgAAAAAAAAAAAAJQAAAA AA0ADQAaASsANw7//4IAVABoAGUAIABzAHkAcwB0AGUAbQAgAGEAZwBlAG4A dAAgAG0AdQBzAHQAIABiAGUAIABhAGMAdABpAHYAZQAgAGkAbgAgAG8AcgBk AGUAcgAgAGYAbwByACAAeQBvAHUAIAB0AG8AIABkAGkAcwBwAGwAYQB5ACAA CgB0AGgAZQAgAHMAYwByAGUAZQBuACAAcwBhAHYAZQByACAAaQBtAG0AZQBk AGkAYQB0AGUAbAB5ACAAYgB5ACAAbQBvAHYAaQBuAGcAIAB0AGgAZQAgAG0A bwB1AHMAZQAgAAoAcABvAGkAbgB0AGUAcgAgAHQAbwAgAGEAIABjAG8AcgBu AGUAcgAgAG8AbgAgAHQAaABlACAAcwBjAHIAZQBlAG4ALgAAAAAABwAAUAAA AAAHAJoA3wAvAC4O//+AAE8AcAB0AGkAbwBuAHMAIABmAG8AcgAgAGQAaQBz AG0AaQBzAHMAaQBuAGcAIAB0AGgAZQAgAHMAYwByAGUAZQBuACAAcwBhAHYA ZQByAAAAAAAAAAJQAAAAAA0AqQA6AAwALw7//4IAJgBNAG8AdQBzAGUAIABz AGUAbgBzAGkAdABpAHYAaQB0AHkAAAAAAAAAAgAhUAAAAABKAKcAlABIADAO //+FAAAAAAAAAAIAAlAAAAAADQC4ABAADAAxDv//ggAmAFcAYQBpAHQAAAAA AAAAgVAAAAAAIAC4ABkADAAyDv//gQAAAAAAAAA2AABQAAAAADkAuAALACQA Mw5tAHMAYwB0AGwAcwBfAHUAcABkAG8AdwBuADMAMgAAAEcAZQBuAGUAcgBp AGMAMQAAAAAAAAACACFQAAAAAEoAuAAyACQANA7//4UAAAAAAAAAAAACUAAA AACCALkAXwALADUO//+CAGIAZQBmAG8AcgBlACAAcgBlAHEAdQBpAHIAaQBu AGcAIABhACAAcABhAHMAcwB3AG8AcgBkAAAAAAAAAABQAAAAADgALQAUABQA OA5NAG8AbgBpAHQAbwByAEMAbABhAHMAcwAAAE0ATwBOAEkAVABPAFIAAAAA AAAAAwABUAAAAAAHAMoAQQAPADkO//+AAE0AdQB0AGUAIABTAG8AdQBuAGQA AAAAAAAAwADIkAAAAAADAAAAAAC6AF8AAAAAAEQAaQBhAGwAbwBnAAAACABN AFMAIABTAGEAbgBzACAAUwBlAHIAaQBmAAAAAAABAAFQAAAAAIIABgAyAA4A AQD//4AATwBLAAAAAAAAAAAAAVAAAAAAggAXADIADgACAP//gABDAGEAbgBj AGUAbAAAAAAAAAAAAAJQAAAAABsAMQBmAB4A/////4IATwBuAGwAeQAgAHUA cwBlAGQAIAB0AG8AIABjAGEAbABsACAAcAByAG8AcAAgAHMAaABlAGUAdAAg AC0AIABuAGUAdgBlAHIAIABkAGkAcwBwAGwAYQB5AGUAZAAAAAAAAAAoAAAA uAAAAKoAAAABAAQAAgAAAKQKAADODgAAxA4AAAAAAAAAAAAAAAAAAAAAgAAA gAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A /wD//wAA////ALi7AAAlu22IJrsAACS7Ao9sdwGLJbsAACS7Ao9sdwGLJbsA ACS7Ao9sdwGLJbsAACS7AY9t/wGLJbsAACW7bYgmuwAAOLsBjwL/QncBiAKA OLsAADi7AY8C/0J3AYgCgDi7AAA4uwGPAv9CdwGIAoA4uwAAOLsBjwL/QncB iAKAOLsAADi7AY8C/0J3AYgCgDi7AAA4uwGHAndEiAELOLsAADi7AYcCd0SI AQs4uwAAN7tMADW7AAA1u06IAQs0uwAANLsB+E+IAQszuwAAM7sC/013A4gB CzK7AAAyuwL/NHcBDwP/A3cB+AqICXcDiAELMbsAADG7Av81dwAECq8DdwH3 CXcBhwp3A4gBCzC7AAAxuwL/NXcABAqvA3cB9wl3AYcLdwGIAoAwuwAAMLsB hwJ3NYgEAAOIC3cNiAELMLsAADC7AYcCd1SIAQswuwAAAri1AAGwAAABuLaI AQgAAAL/togAAAP/AXeyeAKIAAAB/wT3r3gBeAOIAAAD/7F3A4cBhwAAAf8E 97B3A4gAAAP/sXcDhwGHAAAB/wT3sHcDiAAAA/+xdwOHAYcAAAH/BPewdwOI AAAD/7F3A4cBhwAAAf8E97B3A4gAAAP/sXcDhwGHAAAB/wT3sHcDiAAAA/+x dwOHAYcAAAH/BPcJd5z/C3cDiAAAA/8LdwKIM2ZQiBZmAfcKdwOHAYcAAAH/ BPcJdwKAmWYB9wt3A4gAAAP/C3cCgJlmAfcKdwOHAYcAAAH/BPcJdwKAmWYB 9wt3A4gAAAP/C3cCgJlmAfcKdwOHAYcAAAH/BPcJdwKAmWYB9wt3A4gAAAP/ C3cCgJlmAfcKdwOHAYcAAAH/BPcJdwKAmWYB9wt3A4gAAAP/C3cCgJlmAfcK dwOHAYcAAAH/BPcJdwKAmWYB9wt3A4gAAAP/C3cCgJlmAfcKdwOHAYcAAAH/ BPcJdwKAmWYB9wt3A4gAAAP/C3cCgJlmAfcKdwOHAYcAAAH/BPcJdwKAmWYB 9wt3A4gAAAP/C3cCgJlmAfcKdwOHAYcAAAH/BPcJdwKAmWYB9wt3A4gAAAP/ C3cCgJlmAfcKdwOHAYcAAAH/BPcJdwKAmWYB9wt3A4gAAAP/C3cCgJlmAfcK dwOHAYcAAAH/BPcJdwKAmWYB9wt3A4gAAAP/C3cCgJlmAfcKdwOHAYcAAAH/ BPcJdwKAmGYCjwt3A4gAAAP/C3cCgJhmAo8KdwOHAYcAAAH/BPcJdwKAmGYC jwt3A4gAAAP/C3cCgJhmAo8KdwOHAYcAAAH/BPcJdwKAmGYCjwt3A4gAAAP/ C3cCgJhmAo8KdwOHAYcAAAH/BPcJdwKAmGYCjwt3A4gAAAP/C3cCgJhmAo8K dwOHAYcAAAH/BPcJdwKAmGYCjwt3A4gAAAP/C3cCgJhmAo8KdwOHAYcAAAH/ BPcJdwKAmGYCjwt3A4gAAAP/C3cCgJhmAo8KdwOHAYcAAAH/BPcJdwKAmGYC jwt3A4gAAAP/C3cCgChmAYZvZgKPCncDhwGHAAAB/wT3CXcCgJhmAo8LdwOI AAAD/wt3AoCYZgKPCncDhwGHAAAB/wT3CXcCgJhmAo8LdwOIAAAD/wt3AoCY ZgKPCncDhwGHAAAB/wT3CXcCgJhmAo8LdwOIAAAD/wt3AoCYZgKPCncDhwGH AAAB/wT3CXcCgJhmAo8LdwOIAAAD/wt3AoCYZgKPCncDhwGHAAAB/wT3CXcC gJhmAo8LdwOIAAAD/wt3AoCYZgKPCncDhwGHAAAB/wT3CXcCgJhmAo8LdwOI AAAD/wt3AoCYZgKPCncDhwGHAAAB/wT3CXcCgJhmAo8LdwOIAAAD/wt3AoCY ZgKPCncDhwGHAAAB/wT3CXcCgJhmAo8LdwOIAAAD/wt3AoCYZgKPCncDhwGH AAAB/wT3CXcCgJhmAo8LdwOIAAAD/wt3AoCYZgKPCncDhwGHAAAB/wT3CXcC gJhmAo8LdwOIAAAD/wt3AoCYZgKPCncDhwGHAAAB/wT3CXcCgJhmAo8LdwOI AAAD/wt3AoCYZgKPCncDhwGHAAAB/wT3CXcCgJhmAo8LdwOIAAAD/wt3AoCY ZgKPCncDhwGHAAAB/wT3CXcCgJhmAo8LdwOIAAAD/wt3AoCYZgKPCncDhwGH AAAB/wT3CXcCgJhmAo8LdwOIAAAD/wt3AoCYZgKPCncDhwGHAAAB/wT3CXcC gJhmAo8LdwOIAAAD/wt3AoCYZgKPCncDhwGHAAAB/wT3CXcCgJhmAo8LdwOI AAAD/wt3AoCYZgKPCncDhwGHAAAB/wT3CXcCgJhmAo8LdwOIAAAD/wt3AoCY ZgKPCncDhwGHAAAB/wT3CXcCgJhmAo8LdwOIAAAD/wt3AoCYZgKPCncDhwGH AAAB/wT3CXcCgJhmAo8LdwOIAAAD/wt3AoCYZgKPCncDhwGHAAAB/wT3CXcC gJhmAo8LdwOIAAAD/wt3AoCYZgKPCncDhwGHAAAB/wT3CXcCgJhmAo8LdwOI AAAD/wt3AoCYZgKPCncDhwGHAAAB/wT3CXcCgJhmAo8LdwOIAAAD/wt3AoCY ZgKPCncDhwGHAAAB/wT3CXcCgJhmAo8LdwOIAAAD/wt3AoCYZgKPCncDhwGH AAAB/wT3CXcCgJhmAo8LdwOIAAAD/wt3AoCYZgKPCncDhwGHAAAB/wT3CXcC gJhmAo8LdwOIAAAD/wt3AoCYZgKPCncDhwGHAAAB/wT3CXcCgJhmAo8LdwOI AAAD/wt3AoCYZgKPCncDhwGHAAAB/wT3CXcCgJhmAo8LdwOIAAAD/wt3AoCY ZgKPCncDhwGHAAAB/wT3CXcCgJhmAo8LdwOIAAAD/wt3AoCYZgKPCncDhwGH AAAB/wT3CXcCgJhmAo8LdwOIAAAD/wt3AoCYZgKPCncDhwGHAAAB/wT3CXcC gJhmAo8LdwOIAAAD/wt3AoCZZgH3CncDhwGHAAAB/wT3CXcCgJlmAfcLdwOI AAAD/wt3AoCZZgH3CncDhwGHAAAB/wT3CXcCgJlmAfcLdwOIAAAD/wt3AoCZ ZgH3CncDhwGHAAAB/wT3CXcCgJlmAfcLdwOIAAAD/wt3AoCZZgH3CncDhwGH AAAB/wT3CXcCgJlmAfcLdwOIAAAD/wt3AoCZZgH3CncDhwGHAAAB/wT3CXcC gJlmAfcLdwOIAAAD/wt3AoCZZgH3CncDhwGHAAAB/wT3CXcCgJlmAfcLdwOI AAAD/wt3AoCZZgH3CncDhwGHAAAB/wT3CXcCgJlmAfcLdwOIAAAD/wt3AoCZ ZgH3CncDhwGHAAAB/wT3CXcCgJlmAfcLdwOIAAAD/wt3AoCZZgH3CncDhwGH AAAB/wT3CXcCgJlmAfcLdwOIAAAD/wt3AoCZZgH3CncDhwGHAAAB/wT3CXcB gJkAAo8LdwOIAAAD/wt3m4gB9wp3A4cBhwAAAf8E97B3A4gAAAP/sXcDhwGH AAAB/wT3sHcDiAAAA/+xdwOHAYcAAAH/BPewdwOIAAAD/7F3A4cBhwAAAf8E 97B3A4gAAAP/sXcDhwGHAAAB/wT3sHcDiAAAA/+xdwOHAYcAAAH/BPewdwOI AAAD/7N/AogAAAT/sn8CiAAAt/8BjwAAAb+2/wG/AAAAASgAAAAaAAAASAAA AAEACAAAAAAA4AcAAM4OAADEDgAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAA gAAAAIAAgACAgAAAwMDAAJeAVQDIuZ0AQICAAEBAAAD/gAAAgEAAAP8AQAAA QIAAgP//AID/AAD//4AA/4CAAIAA/wBAgP8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAADj3M4ApKCgAICAgAAAAP8AAP8AAAD/ /wD/AAAA/wD/AP//AAD///8A+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PgA AAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD4AAAG//j4+Pj4+Pj4+Pj4+Pj4 +Pj4+Pj4+PgA+AAABv8HBwcHBwcHBwcHBwcHBwcHBwcHBwf4APgAAAb/BwcH BwcHBwcHBwcHBwcHBwcHBwcH+AD4AAAG/wcHBwcHBwcHBwcHBwcHBwcHBwcH B/gA+AAABv8HBwcHBwcHBwcHBwcHBwcHBwcHBwf4APgAAAb/BwcHBwcHBwcH BwcHBwcHBwcHBwcH+AD4AAAG/wcHBwcHBwcHBwcHBwcHBwcHBwcHB/gA+AAA Bv8HBwcHBwcHBwcHBwcHBwcHBwcHBwf4APgAAAb/BwcHBwcHBwcHBwcHBwcH BwcHBwcH+AD4AAAG/wcHBwcHBwcHBwcHBwcHBwcHBwcHB/gA+AAABv8HBwcH BwcHBwcHBwcHBwcHBwcHBwf4APgAAAb/BwcHBwcHBwcHBwcHBwcHBwcHBwcH +AD4AAAG/wcHBwcHBwcHBwcHBwcHBwcHBwcHB/gA+AAABv8HBwcHBwcHBwcH BwcHBwcHBwcHBwf4APgAAAb/BwcHBwcHBwcHBwcHBwcHBwcHBwcH+AD4AAAG /wcHBwcHBwcHBwcHBwcHBwcHBwcHB/gA+AAABv8HBwcHBwcHBwcHBwcHBwcH BwcHBwf4APgAAAb/BwcHBwcHBwcHBwcHBwcHBwcHBwcH+AD4AAAG/wcHBwcH BwcHBwcHBwcHBwcHBwcHB/gA+AAABv8HBwcHBwcHBwcHBwcHBwcHBwcHBwf4 APgAAAb//////////////////////////////wD4AAAGBgYGBgYGBgYGBgYG BgYGBgYGBgYGBgYG+AAA+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PgAAAYA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD4AAAG//j4+Pj4+Pj4+Pj4+Pj4+Pj4 +Pj4+PgA+AAABv8HBwcHBwcHBwcHBwcHBwcHBwcHBwf4APgAAAb/BwcHBwcH BwcHBwcHBwcHBwcHBwcH+AD4AAAG/wcHBwcHBwcHBwcHBwcHBwcHBwcHB/gA +AAABv8HBwcHBwcHBwcHBwcHBwcHBwcHBwf4APgAAAb/BwcHBwcHBwcHBwcH BwcHBwcHBwcH+AD4AAAG/wcHBwcHBwcHBwcHBwcHBwcHBwcHB/gA+AAABv8H BwcHBwcHBwcHBwcHBwcHBwcHBwf4APgAAAb/BwcHBwcHBwcHAAcHBwcHBwcH BwcH+AD4AAAG/wcHBwcHBwcHAAAABwcHBwcHBwcHB/gA+AAABv8HBwcHBwcH AAAAAAAHBwcHBwcHBwf4APgAAAb/BwcHBwcHBwAABwAAAAcHBwcHBwcH+AD4 AAAG/wcHBwcHBwcABwcHAAAABwcHBwcHB/gA+AAABv8HBwcHBwcHBwcHBwcA AAcHBwcHBwf4APgAAAb/BwcHBwcHBwcHBwcHBwAHBwcHBwcH+AD4AAAG/wcH BwcHBwcHBwcHBwcHBwcHBwcHB/gA+AAABv8HBwcHBwcHBwcHBwcHBwcHBwcH Bwf4APgAAAb/BwcHBwcHBwcHBwcHBwcHBwcHBwcH+AD4AAAG/wcHBwcHBwcH BwcHBwcHBwcHBwcHB/gA+AAABv8HBwcHBwcHBwcHBwcHBwcHBwcHBwf4APgA AAb//////////////////////////////wD4AAAGBgYGBgYGBgYGBgYGBgYG BgYGBgYGBgYG+AAA+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PgAAPgAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAGAAD4//j4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4 +PgABgAA+P8HBwcHBwcHBwcHBwcHBwcHBwcHBwf4AAYAAPj/BwcHBwcHBwcH BwcHBwcHBwcHBwcH+AAGAAD4/wcHBwcHBwcHBwcHBwcHBwcHBwcHB/gABgAA +P8HBwcHBwcHBwcHBwcHBwcHBwcHBwf4AAYAAPj/BwcHBwcHBwcHBwcHBwcH BwcHBwcH+AAGAAD4/wcHBwcHBwcHBwcHBwcHBwcHBwcHB/gABgAA+P8HBwcH BwcHBwcHBwcHBwcHBwcHBwf4AAYAAPj/BwcHBwcHBwcBAQEHBwcHBwcHBwcH +AAGAAD4/wcHBwcHBwcBAQEBAQcHBwcHBwcHB/gABgAA+P8HBwcHBwcHAQEB AQEHBwcHBwcHBwf4AAYAAPj/BwcHBwcHBwEBAQEBBwcHBwcHBwcH+AAGAAD4 /wcHBwcHBwcHAQEBBwcHBwcHBwcHB/gABgAA+P8HBwcHBwcHBwcHBwcHBwcH BwcHBwf4AAYAAPj/BwcHBwcHBwcHBwcHBwcHBwcHBwcH+AAGAAD4/wcHBwcH BwcHBwcHBwcHBwcHBwcHB/gABgAA+P8HBwcHBwcHBwcHBwcHBwcHBwcHBwf4 AAYAAPj/BwcHBwcHBwcHBwcHBwcHBwcHBwcH+AAGAAD4/wcHBwcHBwcHBwcH BwcHBwcHBwcHB/gABgAA+P8HBwcHBwcHBwcHBwcHBwcHBwcHBwf4AAYAAPj/ /////////////////////////////wAGAAD4BgYGBgYGBgYGBgYGBgYGBgYG BgYGBgYGBgAAAAALAFcAaQBsAGQAbABpAGYAZQAgADMAMgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG ACYAQQBiAG8AdQB0AAwAUwBjAHIAZQBlAG4AIABTAGEAdgBlAHIABwBHAGUA bgBlAHIAYQBsAAAAAAABADIAEgBQAGwAdQBzACEAIABTAGMAcgBlAGUAbgAg AFMAYQB2AGUAcgAyAFAAbwByAHQAaQBvAG4AcwAgAEMAbwBwAHkAcgBpAGcA aAB0ACAAqQAgADEAOQA5ADMALQA1ACAAUwBvAGMAaABhACAAQwBvAG0AcAB1 AHQAaQBuAGcALAAgAEkAbgBjAC4ACgAAAAAAAAAAAAAAAAAAAAgAUwBhAGcA ZQAuAEQATABMABMAUwB5AHMAdABlAG0AXwBBAGcAZQBuAHQAXwBEAGUAdABl AGMAdAAUAFMAYwByAGUAZQBuAF8AUwBhAHYAZQByAF8AQwBoAGEAbgBnAGUA ZAAJAFAAbAB1AHMAIQAuAEgATABQAAYASABpAGcAaAAsADAACgBOAG8AcgBt AGEAbAAsADIAMAAwAAAABwBMAG8AdwAsADQAMAAwABwASQBnAG4AbwByAGUA IABtAG8AdQBzAGUAIABtAG8AdgBlAG0AZQBuAHQALAA5ADkAOQA5ADkAOQAH AHMAZQBjAG8AbgBkAHMABwBtAGkAbgB1AHQAZQBzAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAACQAyADUANQAgADIANQA1ACAAMAAHAFcAYQByAG4AaQBu AGcAVgBZAG8AdQAgAG0AdQBzAHQAIABoAGEAdgBlACAAdABoAGUAIABTAHkA cwB0AGUAbQAgAEEAZwBlAG4AdAAgAGwAbwBhAGQAZQBkACAAaQBuACAAbwBy AGQAZQByACAAZgBvAHIAIAB0AGgAZQAgAG0AbwB1AHMAZQAgAGgAbwB0ACAA YwBvAHIAbgBlAHIAcwAgAHQAbwAgAGIAZQAgAGEAYwB0AGkAdgBlAC4AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcA RABlAGYAYQB1AGwAdAADAE4AbwB3AAUATgBlAHYAZQByAAAAAAAeADEANgAg ADEANwAgACAAMQA2ADgAIAAxADcAIAAgADEANgA4ACAAMQAyADkAIAAgADEA NgAgADEAMgA5AAAAAAAAAAAAAAA3AFMAbwBmAHQAdwBhAHIAZQBcAE0AaQBj AHIAbwBzAG8AZgB0AFwAVwBpAG4AZABvAHcAcwBcAEMAdQByAHIAZQBuAHQA VgBlAHIAcwBpAG8AbgBcAFMAYwByAGUAZQBuACAAUwBhAHYAZQByAHMADgBQ AGEAcwBzAHcAbwByAGQAIABEAGUAbABhAHkAFABQAGEAcwBzAHcAbwByAGQA IABEAGUAbABhAHkAIABJAG4AZABlAHgADwBNAG8AdQBzAGUAIABUAGgAcgBl AHMAaABvAGwAZAAVAE0AbwB1AHMAZQAgAFQAaAByAGUAcwBoAG8AbABkACAA SQBuAGQAZQB4AA0ATQBvAHUAcwBlACAAQwBvAHIAbgBlAHIAcwAKAE0AdQB0 AGUAIABTAG8AdQBuAGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAD0AAAA IzA+MFkwcjCvMNAw3zAUMWkxbzF0Meox8jEAMgYyDDIbMiAyJjIrMjAyNTI8 MkQySTJQMlUyWjJfMmYybjJzMnoyfzKEMokykDKVMpoynzKmMqsytjLMMtUy 9DIrMzgzSDNPM2kzhjOQM6YzyjPgM+kzEzRANFY0YTRnNHQ0gTSHNJY0ojSx NM803jTtNPM0KzU3NTw1QzVVNWQ1dTWENYs1JzYuNjI2NjY6Nj42QjaHNpg2 sjbFNtI25DbwNnU3njf7NyQ4uDoROy87cDuxO/I7MzxGPPQ8Vj2APcA9AD5A Pg4/Tj+dP9E/AAAAIAAAkAAAAJAwlzCkMKswxTDMMNkw4DAAMRAxKDG3Mf0x IjJWMpUyqTJFM0ozUjOEMzY0czSANpw2rDbQNkQ3RjjhOC05ajmrOcE58Dkw OlY6ZzqTOrY69zphO287kTuyO9s7EjxcPH08iTyZPKA8pzzoPAU9Hz1IPmk+ qj7nPv4+CD8xP1U/Xz/qP/8/AAAAMAAAGAEAACcwODBVMJowrzDXMOgwAjFI MXcxtTEbMl4yfjKTMswy2zLqMhQzIjMwM5IztzO+M94z5TMLNBo0MDRLNGM0 fjSWNLE0+zQKNSo1QjVJNVg1bjWwNeI1LzaPNpU2sTa4NtA23zbkNuo29jYF Ny03Wjd1N6o35DfrNw04JTgsOF84fjiFOJ04pDjBOMg43TjkOEQ5Yzl1OYs5 pjmtObI5xznOOd855TnxOf85BToSOhw6LDpIOk86WjpzOpY6zDrlOuo67zr8 Ogs7MjteO2M7eTuZO547sTu9O288djx6PH48gjyGPIo8jjxsPdQ92z3+PSg+ OT5DPkg+Uj5aPmc+pT6sPs4+0z7wPqE/0T/YPwAAAEAAABABAACMMJIw5DDr MPswAjEhMSgxNTE8MYExnDGtMcQx3THkMRQydzKlMmg0jDSfNLc0yTTlNOw0 AzVMNWc1cTV4NYI1iTW8Ne819jUANgc2ZTajNuM2+zYFN083cDdJOFw4aTh1 OHw4mTijOK846jhBOUg5WDlfOWY5gzmNOZk50jngOe059Dn+OQU6FTofOis6 TzpZOmU6oDrVOu86vDvDO8c7yzvPO9M71zsGPAw8EjwYPB48JDwqPDA8Njw8 PEw8UTxvPHg8fTyDPIk8kTyXPJ48pTy0PLk8xjzMPN885zzsPPo8Rj1hPW49 kz20Pbo91D3aPUU+WT5ePnQ+9z4FPzc/az94P5w/9T8AUAAA/AAAAAIwGzAq MDMwQjBQMGEwbTBzMIkwjzCYMLwwfzGFMYoxkzGaMZ8xrzG0MboxwDHPMdox 4zHsMf4xEDIjMi4yPTJIMlgyZTJ1MoIylTKdMsIy0TL2MgczEzMcMyczPjNN M2YzcTN7M44zkzOkM6oztzPCM9gz5DP9MwQ0CTQPNBg0IDQnNDQ0QzRJNI40 qTS/NM401DTvNPk0CzURNRw1IzU0NT01SjVaNWc1dDV+NYg1njXONdQ1ADYF Ng02GzYiNio2MzZMNlo2dzaqNsU21DboNvk2BDcgNyk3ODc+N0M3TDdTN1g3 djeAN4s3kTebN6Q3AAAAcAAAEAAAAAQwCDA4MDwwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAALUliaQjoEQAAAA1CZWkI6RIAAAAxEz0MamkIJWNr aQjDHSVtaQj56Or////oDwAAAKlNcWkI6RAAAAAxF4PoMxVSdWkIwwUYdmkI G8bo6////+gEcgAAEsG8OFYcYCKy7jhqeuE3c/pzGnji1RvJyhs2jn5XorLX XKmQpkxXHbYqCuJ+K3zebppgBaawNOP+Q/tCXqUWC3IZycefH7eGMpTR8E9v R40qidKhQQbfYqJ9BR3Jx2LgMgGZjnvRJ0QSZyy9aufXOQpcds0TWfs7UsCh gHnAMT16pit9MteRmDI6dlpGsqcAAiPROUZu3gbuQtbfu2/9iygYIfXKP2NW l805hf6Xp1hDhF2FZvyBv9JytHJXdcaLeutDYRJh8h17WiBBDtoNCrpQMMiP SokWIsnJv3VjbnPdvjCsdrhSaGcvSF0u+ynDziOAj2Nh39rSDASRFWjGV4nk Adju5TTDsi76owmAq6PFbVBXTYMSAmFv5EOAxUrBrnIoqqbOnhfgXhw8fsKI LeCmipMT5DwXAs+pTNh8HiGHAwgCk/H9vvku3HNF/S69KiCwsfR79G2OdfAy c2od4/tuPcmu6/guUv6iviLvVXSBbjcqJu0B98Ln01dtptg1D7vA9aSG46xB tBV2jpONqsbFT/3DjkrtolJWh/60iPIvpmfHJjkJ7kyky0TrMaJCysj3yr2T iR6C53fH3u2iGa+Ow1+Wd/FXdnwekU74gFIsK+/9kxpde2JddHS+WtijisUH dp5PhB/SoIJcLkTeFBK4f8ogvQWiAjMT1NBn/XR/55KjxrJBdlrAvx8O/mBc ahEGFFqNOcqvs2MTPgDGxGMLrXU2BoRRB4eOp+7mTv9V611up97IVocdNIpe 05z0BUAzXWKIcPjPXt7uzlT+8iq3RCDss+fMfi9Ckn7T/1oKMEbrgp7APLrp rnWuZvGqCoo2buNNwmDC888kuTk8VXlbJ8vWPkD7p8h+fI7nJAD5zF4+1r/6 46JRSmr6S4ywTUJ2kjs7REan9jxEbow4Pcov9jUiKggqQlHld06OTHPFrA/z 1hNPB1aJ2sttyPHQQcGRiM9XF3adYr0s/vHUXZ9LVSEc7gDMTmSpkm7UV7t1 KkJMb0pulwLKHOs7bDuvPb1B6la5HHFNJpHeTq4oUx4rhklLBbcEGRhIlT6X v2xKASU/ZXMqITjGid57LPcaSnCd5nucHDP9j86w281bPtBkbU8SX+9Q5yld qM4DmsI9xyiXLAiXGH+DKYw+tPbUMHdV16QwP3e7BNZPUaumUnxh/az7/2Ea wv3SoB4QPgx1jnj7KfsE5r96VgvO+YohwPNMbIbhsiaj6CDSe8KP1FpQcfDK l97tavjIPusMvfMhxpywr0SibMK7/afFyRpb0u9ulJYv7sJ2dhgGThaHFy/Z 7Pq7X3bwYtmoab6Iqq+vcj4bdiuBAfLyKM0lsl2CIWw8P21p55FAghZNdVNq eWq8fSJWUJ/2OZTo/g4tmslqP3OTtr02Pyn0FA/uvtohU635QHYjk7ZZvUhc vH9ylEoSUXjXp4YGVFdPqnqE2nixO/frhmb9et97p0vK60Fcp1juPMbfQp4d bDKsftQWqrJLk3h1MLHEeFM3ej7rHJbHzjtc375llcJEM8wep7zHJNUz0EYL nSC7IyYbzpAKwHoaW3rNdvy/pJb3agGG0CZidnMHXi5fQBKW8p3oIzFNX3Wf qyaxGCaCUmLpKdqZlYNDw86WyjDWWHuXy421QUVCV2myBq6V5OadwttBlKyq jFoTlbWfJU0SCreE7gs5CYgDuyHpSilF1LiO7mryeCRxPDPWlF5klrLh3uIM 3CD/782dAcbQ9Hliv50i7lVYHF+kJWQ2upxdEsC1Bn4+4DjPss1IpuNEQQLq DerOCIg4P5WVrBamadvkx9YkyBFQBrqLckx+GASYkX/u0a77MflYTbAtH3PB E62yg3iuVEnVj0xt1mZKYTBUA84Lm+8SAXqxJ5N8cow+h6dhrI6eDiXqIaKS Rxw0EmIZmiYC7/eE7/xkAbaOH3+SAMaz1/6v7MocHyQm7waejW26ayEc3FXN SAEJHUX66LLSFrgedOuzqsdkWdNokyWK47xevjNn4hAhAUDm85KjLlqawZNX 2TuKmky+dgSzfRpmmtphdnzbGymhl1W9ctqyeLWEu4QJAmqFr3rGZ/4J1fQd 7fPp5FCaVtmMNlEbHVITcNh+1X+ZyYDNqTGDx3sCNSABqbnX7TGsZIxWJGic Iva7mM4YuhFegKKPcZtTQ9mCcWx+Ar/Ak2xAfWZ1eiK5Ly3aQ0HOmIE+9WSt QCIKlLBIKRqFycm3ZWC1KVyKanLEceaBOt2jFUdDW8sGW3virSUO/qeGq+Wi cHwzXFUx+2y7EeUUsqGKi5vY0IACmYL0HVBjvlBKOnXAtCkauuxi+QRK+63U rqqh/duFGVKJQFo8mUH4ulRaSO+eYsa6QxHDUeSod85KH807rubooydCJnDQ sHHPnfsaYCD4lTUPsnrMHSXznbppVV82+aWN6bJpS7f+1BonOBzwwMVONVZS loibfkz9d4o8X+02Qfm3AswrLAyRRKUHC18gFuy4zyJKZh9k7730v94jBIb9 qHKWmOsmrglWL8XJjHqh3LTcmShjmvnTW4P1yDqhJnce0br1i31HVbrCfPYP f0ZTSXdomCPZ5wKdJWNLY7OuSzEMokRFzgCSD74vbX8mJqMnJ0WEKyBuKK0W o0Py+EV5gbmCfWm0PwOv+sXcur7iKrknYpAgIhyprkKopV7IJghvZbJveqer dDScihgOs3DZeH/S02Ky1slM8HUYae/hwkGhqr0Km5422PcHpp4MCy91dKrm sn57iAwn+gutIksQu4likAowKwfBo8LELoRkLeeY/v1CRgZ37H5KYoa3pjdr M1/khg02nUBjur9YjBZSbfTNTlJdMdMIwmpBq8oETVC4b6gudn4wDDe0Ks7n Nis8fFYfojwwNIwNh6HYMCYO7eIijgq49gMa8Xp43V78Z5fzonkpc53s29Sp jqBuLbLaK++66Q+bscXRNrVtqV6xcioSTMSX6v8rEX98Y5UmOWLlBO7prh+F 03+/Y8mSBg03YXlPeTlOknswzO8s70DuI7Ay81Z62xhXIn52VWhKVfe4W+8Z dW5loy6LX7XuY8w93EIEdkCWyjMOEjxzR1arTtqyPdmHNTgbGtIUBSuGqS9s pjrdnH6sdlGlW62Di7IVB5KpwYHuCpgdx7D2YOb/1nYn+ijp41ey3bq5TOm8 GkJoyt3QIWWCAoAq2KRRiv6O8goyZis+h+eklUWYnva73qZktiDn1b8KSOJu zIBmzb5Twp83Zyoe8itJVHSF1Y6GardS1ZaOk1oP6nLBW0d4LmmvcRi6fZcD gEP3fLsm4ixwYUxQDf7GbFPt8dQPJ6B02BLVrgT5nhK6Ovy5xDd0JiwaehRl TqpHTg9j5M50P16f8ohPzWW34oESDYy6AxbmY0KR4JEJXQlli/m3BObwHT+v 9gcQdsLvSPqf1AXf2sW6WgCx8w6PlqgXyYNlTEbwOmK+W/dC1zMnSiK72Qre Z5QCN28qbRw6Vgqc416EBi31knq3Ds4bEmppIDsQdvJ12eLq30RLRZj7Km7I 5Bb5na1fUlYlPl+UiwrIW0d13261Ek2PocRFiYLhXeMr9oSdIMM2F8XyJTFm f+vPntZ1+k0GpK8QZyYmthWXfm3QT6271hkHZG6TR6htXypmtxAjnBLzyV21 SGgRy+cSSilnYYKC3A50n9bQf8G7ucUy36RmurCkD95Q6CeZMaGQJkqzSmJp s7Ef6SC98opG9XZYcR9z2N5mbhzL6t4dIkh2byJQQoLGPmYWemuSYlq83/RP VPJr6Ksnx1hnbYhcpMZaZ13x9ZYRRcrL65pJ3LCm1AQsH4uRUK445ZOtpxJn TrcdoALAuvVeIlBmrIxq2oaUaVjXUc69pmtS9Sr5NxoCQIyQZyHQ4D7xX9ma mlKCZnmjo0/hHYQtU9wYStn1naYH2i49WPHjXshYJaFn2dnUvIMSR5X92x4h vzyjq0H9MrC7ZjIwlqIlP79nWP0pdLePLEwmDv0S7zlw7op+XUjqtQ+ZEuP1 Zl/QmIp6aJPCPMhXtWLMnUqmDbASqjmBoQZMNBFWwvW9BrtgCeXTCy52NfLV BYodoeLmixb/DKGDdo6b8XO4RYWfZ/4tap1JdevbZm+yGt9znm0GMYKygdrG GUlHIuzU8U9HfoXblH4upkuCH+/V/C8ZSj3NCsrAoabEz8+SLzSD22L7QSoj 6BWVVGjMIjjcZ14ji+eP3SClSlvG1+wBZEquZCYTmoYgmqWAsgapeumsPuUW Z4mKfkdv+sr5Uowi7B5frSB5Kw6ERsOSwLeHScWOj5as70LA9678qjCiXxTA /TGBN26oKNtf4a7r7UG/oX5P2ROKkVC/Kaf+0429qBTcC3k9Hvk+N4FY4dsa +YoUTm2xXSOse5aPt22rAx5Te1LHSc6PkoMqdsNGpvbJbJcKw8qj3p+pziKl 0PNIIBMvDuLU9PqkV7zLVuQqsv+ioGgdXt4MB6wQfnIWst1rmYZ+fdx8UfJ3 fnZyFPHmZ+v6fvY1XN9Jy5yms60OAlbc+77WTYdF3987VkUeTaa5izExrJ3u ajT1o3m7AViiKP6Q+4cdTsri0uNyVzEDMpnDdBvJoXIKwWpGx0HZoyoj/9we tinVD+EG3kZ6R8MW+ZU/cSC/vHpJrnomX9joWTVnv25YbEzRRjGw9r1ZCBwz P1zL8qRJjL5l4rY36IuUoWJrUyaFAXqWtSZs5SaGYhqayLl2UOZCh+PABhsL me/pe5f+bvpAGRG2NObz4Lu5nVZwBRNGKYmaVpd23IhRJGxR/udYfKJqq7Ai LjtQNCKgzF7MNX8R+rXufA8sugFuPk5IKjAomxlupo4BqFBsk3bmNH5tc1bP 42xWpnsyhKKtoU7b0yqBuuCe8IZMz/X34ugsztC+GN1dXd4LcGpvor8ZOyC6 22CJtMXBqufBjjfb91bag9AJfuoEywHrV4AqxF8XHgC+p+zHFQRTbmmBMsXo +o72O8HDcL0sSe8ApaJlEWPK/jsXWy4HwCbE3wSPhJmCbo4g/8pDDbmjJVYs gtDupd4yjrBbT9ly11LrP5ZI6OVORvhPRYAd++7xbjRiSz7pLAUbppq9MX42 +u9jzmRIwL4Qd2Ycqaw9c+cTu0IYBQA/mGpsE5urWalNg+gThygZesyCwfos OwwNFqbCIrHQ+xSvN4ERBeRtYMqKzJIX/WHw1GJItTqjx+aJyR8KAWDDtWya bCq/cduAM95tcm3ITev3Ik/V13OOxlx5xObTMIpWUFrDGrTR8HMFLl3yTxhu Ua82I0o1jRwGRZZwwhnAUXYsTop6dJQ8QwT6vDIYqEHhncL+eo65G8BCJgjV rw8ZfkvQ8Brx4/+se11TgiAy1c+goTUNX1zOZtV/p4LPtO1OWdnevxOTEpba HYvyfoLu7/Px/G0oCJVGqMVuYqJoIj7j2eAal4MZnmBFUtLjVwsuhivEdTWX e6Z66qNi8b9u/6xsSvXtOGtWZD6kMiHnUg8snhv6w+tZpydlRdqct4mBkrLS qxxjqDVIMQmWMfcZ7ivhUiBmo4ukILVPh22/vV4WDEeaT3M/6Z9FLDIEwiG6 5aCKummX5vCHRIxpUJjkfujbQOvCgjYeZaRvUkr3FT4t5eGyzGpaZsMUH8LA WuuRvSjF+XEWrhWvJDYyyiDqvAWQqOt2QtpGmS/CI1iuc/6N9TlZKCLF4Ors /hJ9yaIy82BwT7EFLY1s9OEJrlOnKfaIU232v6y2VZxMd1Anvk7hL2b9u88Q gn9EIrJgrRi6RgiLir6SkvMHTczSIz3Jvo1QfXAU3252gQTgwrFXCN4GYZfl kMKLxjy+jxK1JY0O8A8A78BYvsbkC4gF382bTkknORxWiEN2zovz2jaKqyhH cCwKvUlGG56SvwK7aSnOPJfh2s6xNRahJHdGH4UbrxZGUK9Z7a8WGhNWmpj9 b67vvm9lhr6Z0EgrqtmV02aHyb8bCosXqZmiFQjw9v3GHjNkn5JFkTjWzR9V Oqjwr447fDGOygt4zxLl0GgJTY7+4nLo+1/h/3Cc55lSFEj82+E66srgFtom AzMTBptZVd6/zwOudHDHH3mChrLmjbzSZ65xIavkkXX2zWC11KwcvTodq5v7 0Mt2v2VCFb1UAEg/eC/sBypy6Syrr0KjmkqevZIVagdAxb84vo6y6i+BUuGz AWqO/KXCe2Lyn1/t6353Q+pK+rCNUFgJVp3bcYruWbhM38lsQKYoM/OA2vrz IVNTaM544HSGqDwkJSIwbV68vh+r4eDIhiFkgJwHOfpKP0biCoCmkqAW3vvC lQSNyH4DdN85E5z2ZMFYpNdtI2rgtarqc+RdRk1pK4/xQqSO2sKY9ci3Vs1C pi7iwbJNLRs1AVUwUj62sI/2PApzrG9MHOHKn4ejDzuxVorhzR9OHlVDv44O QZa6HOlSPYN8yJpurKry6synLUEZF3u7xy7x6hXJ/L/I/dPioJJQ6r/96/1z hcMar+Y/HGA+vDsezrelX6qtj5gG1oxdNGMj/ZuOiXtqk7BbT5eXjGINQKJK jjBv+kGf3HHAARU+cDLJKXXohArrRjum5bvjouAardUthSBC1O4enYnQanLL wpDBQc3KKr4dRJaFgDnismX2ba5UrZUQeeC+yug3UWyZnoUTYBZKkW9M1g2Q AvnTtk4TEDTk6vHIvV/xzGByb+lJnuKWW7x3vwTu2GDKKQ4GAC3bYb56Dd71 C7Ru7RJCsuRuSoqPWqYW2Jse0dGCKi7DTrXUk9EtvqwG8hl18hQD9ogP7Q5f DdYfjYlU3iL+IgQmftPKkXbhhTbt6ok9QhF1xj4MropcmM5Hlg8nN5BpyA5b biQVYI3K231ImfK692vmd5N1aiQJisJB9aEipMLa8yt0y5qY9T4ukweUzOfx Vbl4TgDOwsXwZnMrRgB3mY/ecYMg7JT4oZUmV1T3TOCLzlrDrB1VFX2JyzZ3 4kmhJ7vQVaea1qom9jgu3JK10ZIluM9NSijg1hI8361SjAKmbAGzP+qBy23m qrcgM41sqihAy3nIaiRbgHCupeLviLZ7KfQ2WufZXBCeRmOfdbZhbjsQXsrN lRqr20+LgkldkFj8wtVfgKx2nXGZKw2qgOjHI/Kn6qC8LTGbPpiimqwsv48S jJ8Wen12D55K0YY49ip5umEP1yJh5u0zauMoeJLrGvJcaszHsMrRdj6x5JDx TkyB9n7PcUBAAN6qZDdB3/sV8pONpGJ8GIANgA+AMD7jPnpXarJ2cAxMpWzC iFgi1Uc+s8IB7JMTEPzMcnzpDeUz0TS6fAPnh6B1saWw5qca21EiGlRdfwkw 2nthCoZKDsT5BYM4Rz5muSWHwbO3MKOeAKl6qf9rRjLly7kowxLOl0p4Whdz Bs3KDTwnRoE4/gu+jLJs2Om2/IMyF52GW27j35zJIo/2YQ8fARLJx69XFBH5 dGorsZbIlIzWvQDdob1UdAt305VyIy1d8rwnu3QF0T8aVXbo5ov112jAjAEh gKmz7IG2wUJEDfPDNXRe9PoIb/PzyrqWmpHoIngOOvliThJq3XJrstrMzLJC IBwo0NveSlaKYb+XJquVK37oiDyPoR07f0Ig6qwgvzkQHF4UNSk82WpFm1TS R3J9mh9ONQHYaoMVxpjtbHpy91sKnzLQVO59KgVm9iRzmELOB68ucdCaxvKR 1VBMskH3wm9eRSBQUa+azUa6i80yQP9eHr5Yiq1w4s3D6Dw5ok15B+22MOul p8ai9gy7yOaDbpaohDZuivsA95NqbQCCD0BtWqq/TY99L6uWIAbYcZl90Nuo 4daqRZOfhQkzWOH7JTS5LZ/qijHtlvVy67tRlM1RKTcnzRootbIZLh9JApaK nQoUH0EFP938FoXMJk78XeyF/9iAKnRyvRk+ViPNzIXPKJw68FkdmXLkPAx4 yDOu0yjJbE0KR0DNlUMrXsS5LjYeNv9EQrtkK7dr0/Eg1xP5Nws3I7potXwW hOuoV3dCHj5Y9oSaAzlAHpo1CVKhTDZ0Sv56Cu3rdO6gOo0B4eclV9zRXjTW 15ef0DzQdMsTCd+X/03qvzCTT7oatCnQIOUVkn61ypoKOkmRph4w+C3uI8Lj I1oCENKtS+m7vgxUtxgKfpU5uqNmmnXU1LJ02UiRlBnt7ynjO3JMKtLyypep 2tuM7puheO13SYCNXop+ls00jpiKz5868qKamvot9KrpzNTrarH7ZjKTsLck TMXlX0LQCOGOuB6GBQpS4jzPOn1P5cWa9JwKTuy0fRSp624o+1ibZlv/X/Fh rZgC08Ii+5QiUrvA5IQSIKgjLOpsXdy2Je5176SKBpUEK+Q1cwiuSyeKw1k8 HH0hlcYSj7inA9/+RQkxl2gmfqE61HgzIZWK9YZ1bQfpFDmFGaLyS9PNZ1hQ bxavwmDBCX4yoFL2Hc7YWN8AV5pFCYG0v76eO+tvFYUqK/yMiydsfQRe0y2M K293zeL/S1wOUMMxZxHSppljC6p1y2cvtziVDvEitjUbgVJskrYnntngYNK7 CfmlSGhUys8TvjazyETPecL53r7l6vq4Rn/dddgxp60aylkj+qiqUEBXDxcv VFaRUtTuAUeZu0gsoF9auG8vSklo7nsgbdrlrgot6rV3Qmoh3Ofk/ES689W/ vbsqdRLYTW4ItaQoKsPYba0UbBFnSkKTPhyODx+tsAX2omRaTkfJ1y6dz05K G99daYVY8VKEJRIeCpw4c5QWnF1p70Uy+bH6x/NDPB1s6/RH6BcmFa0Hz8Ue n4fKR0VDwd8vnIJcKoNKTUucIEO7s6VVQ11puMG5TiTjz7MvBjrWpKL/KrUq D9sFZQWqGD/+u7UW92KJ1P0uEhu5kwlRfp/lX5vS8o/Al2MzDYo3pEPmYAcp 794xwpXFS2BqrTDCWdo/8uwdGl0a3WE/CKn9nUWOGTViLkELabi7KErdgL9F Xf+sUmPg8n6BQydIDL3U+F/NDuoulEZekLp7uQXvRp11y9Ey6juvv8RiY4H0 uQAAmfbXEVhlfB6OykVqQ2r0S2YY+FJVpPGut5khmiLMpCKIWmM9Wc+03cGR s8YdREdbIO5vcpBhOZKKwhkagKwqzzuyf8O64Fp7T8uVWm7Eniauu3mzIyiA /s2Cf09qXbEmUna6Es1tp1gGupw6thughKsenmJRH7h4EGLZSS/wuAYlNnLf J4Frvhh+IIqEZAwcDTZU1gjIRlsTItcabf04glbjEvryb/KeRzMoEoFHZFap WYEiS4dGvoOradJbByFtIhmKIsV5PEAe6fLbKQO7XLOVJZauZ9WbtMFG2jPT BKadJcTLGe6BoZL5Wrt4vUsdh80rgSVf88R7ofconp3ShnA9evr6z9iuo8y9 Ox8zu2bJjRs3VgcsRV1h9JqPXqDHA8XXUq0/aaY3qC7R2uOL1iyF4TgnV3Mz HeBs6hpfbNaGhQ5KnP3W/uKtBVoFWI+d+5gC6srUS+5JrlKK7ntZIXn09RJT EzQ2+DLXOh+nb6GSDEvyzPZpUszguhopYHDBuD2RrpveZVa1gp4abPeoQeVc EtKfRqHSkDCCYmUTu+bkBhwyiu4sG0Osa2rtUg6+WK7XspmegJ79aPdrZ2pq EmtUu6LhBlU+VilYz8CC9qb7FTQRguJeU5TgUErTtEimNM6B6gCNu16suIDi s/K9hlZD4scYNp9+s4pT6aZgE24U90nihB72HmxXKwqQCX8mljDF0uGFZshd 5F1sSz9gmToluisTLUoeqa8Isq+qVLLJ6/RUBl7s6BPZ3hVSzzSvBpPYoifA KV/hZ0suv8ETJga7AS8wZfVv/xm+WhVp5pu8Qt+Ce7nRTuQngdMeXrVpA4lr UmF1vMueK+46yNm+vtDfY8PmlmMVIb9QHiRaoVKWMEZCplXlls6a2iGgWl4O 1oouQpCuzXVcxzBqfkMxMg0rEjnZkJl6C28T+m6OBE3ttF7J+iy+7ose7NeB Oyv1SZIYm9xklzyiQdvaQajiHjTA26ktBWbOUJCWRVuGzJ1iQSW+gvTZ5XkX QtZMGEOGnrQBMrUcvT57ovaajdgW94ca6O9SKeGufZrSmudIgtVxKvzGa6zu FvYGLeqIZvfWWgykthAeR85PWAqAScAPR0QSuCKDxOq+OOfwXaNALSYGhtKb VIAzqKezyYoceDG2h6RfvLAME96bptz8gxwk1gAKLmJqkjVjE2qqqrwvIwLq sSu6jpkyMt+FE58ZG1zmQ8kVYv6r3SrILRyCUoegDusFaULRU8f9134y5K+/ E9x+QQS2oJPeZJiV52uVZ7+yncGgshpd0XEAQwmwfueeN3n5uFEVW0PsC2Y3 UoBbvaZiqyfCn4jYvFR1abCB1WC8jyPYmlkyFM7F3Tg5q5cWFrhEoc1v2044 KsUwCtcLqnXmm9ZziRNLPqBt/LQNV02gjZGrggIqMqvYO7h6Tv0w1vF4mpYv XxemyfzbU+umFEZLY+lkUKqrvs9kfDDOpj22xDi00sox+v4pnC5/gNmbJhfm FIKoWr56YTd+O+iwLwYHGHhPQV9xTo0oeDoW1jO1gdiLYXsa0zulKQ4acWMz T0WYv2tnwvguz1+VSdpuaJNAEDPS3udpomcUFUNFPk5WrdsjcbqngyFy/EFt LOYxVtV0rKfxl+N+G2e4veq4FTZ0h372bcOH7oegxMP7EZ3BcDkyApCASwqK lCy86N1X0oegtnLdME5P/xqXq8p6wHnEkfkczjM61spDa5o41aCCQZQlV8Tu 1fyl2n3YnIGjbuu2UFIJOQ5qsJugIEx5a7bfNi/l1bmKiH070W8IEg9Gcg+I ooS3x/5mvUmyy0bz3ZuzwJmUinOZiogNmCB1/pK6oLAH/z19jhzMwTo0r9pg 3IPXqlwX+ce2Q5fqHa/d7otQ6Z2XWTtLnwoV5DQtwRwFv3stBL+6q/UeLIqa Fk2SFQEiy2CxIt7fuEsSvkN3qV0jtYaOkJAMISDMlTzt6d6JDqWPi/p19Tch I5qsRCQLN2YYAiIYwJqxWmraBj+2vqTebIdL/LXOFeJOUllcFxZ5lbtp5KAZ zb3y2ippBBCJ836jClPYbD6zxzUKwq8NFP59O8LXEAH9yuf9PnxUqa8+7RBJ +3O/m3ImLXqgPNHdj3ZOoskS/IuEKsA5xP1KrlCLwqKzGFE4eFmVGvhKhUQL ylmZFaUGHKQIMwhosazgWeUowtbHKuzVsftQyXORaDp6JYaq/zbeKuFU7pBL s2AXprEEAvyDLjORe5H6z/PdcO010pKDaFp6I35iupLf5jEZsvLzzdtd3OHS +LORc77BFjwZMufWCmD5hWRb46ZMjKfeygBJ54HMYSTD0xsapo7+aSK4VT8u 8kqf+gmZ3v7MGjeSso0jWkRbqDu8a7kU0m/S2eMLx84FqwPCNII1hkpvxFLs XGD+L0PqWUOh6h7DFVJSVDEBcDDmwQrThUxXZzbwAgelZNlo+qGSW4cfKTOk bV0h3sIelzn/wTWyVNacDomQCmalbqjjGmMfWjcmtbCUUhQOif6WMlLKeJrs JXNcL8z91m020jA2Ooo0bJZc75dixn4IalLYGULqwlIGrZwb8tB+0b06gBUg Nmo2nTPE/0LBDqsuJMCYih4S8fSIbMKqMuWLnuUixvoHUgtXAqTezv+Nb76W 3UC08mHhdijhQgkhwov3pDuQuxljzd6WDgJtSh1CG/XDG7sH26tOjWYe/TxF bk0j/8MqkVj4DzjTVeISHhXLDIenmryrwJ6bKGgiiN8ilEU/4JH0ZuNOeFAm YbXWBkbjZv4Kgy81ZmTT8sNeJUCAWw/iytJTqiZPJPnxoFlzcb2NBp7Lnfsy xLHw1t7/iHVne60wI6EnSt/MntJvKsT+hZexy3u8VbaaS8KAcKmnTm4+TDn2 HCSW84JSSu+rsSTovs1WHb++znbCY50o63R/OG03GsxYGNys0kFSPEMdv4hn sDrtkpNMR/xyvVX1LeY03m9KJpJSVnFAjU1sp/q+BVxScoIn2waBYOSj1wRl fLA0nvGwY66m/OJrGLm0chGfufGiEM8cWT8a9DKs+6p1gkXcUkLYxhZnKdLi qTyIT5kmsSjpKmnVorULNNyr42V3Pr2S69dxpiLTVrrSAwBRl03QBv4vjj5Q 70K096PjQDKJHJJ3iaop2GT6xeWIs33j8nQF6d5NrUThyFgxGpKUwTUqoUI4 mXbD9cWCIguyb9jFV1o2/1OsfLFOfGS8KW4Uh8E5eLEfaXWE3Yade8Xe7+mP 3mwvV5bkGcBgqzmrFYBtcBpjpBuGtqBUGrzWrZa5zObi5p0kbIP9n6uc4wCe gZHDEw0Pc1YwoePGbht0nrX25WtrbsZWidk3IxQzyPvOaRJKmJeq3ijxcpIV javu9y/H2mI+T06gmFYCvWqaXuFsI6hLxpH+3UA6cjsi415a/J4qxf4n1w8p t1q50lY+MXz7kT42WGYYUOpXM+qqHlVmtqATjBVmkjjlqUUqzfYt5Dh7gfbW FRHjINKMNf4LsMAXevoO43pk/J8yz+J1wlsoX8rE1scG3jJVuBqQFIbC+f01 Zl4xjIjAcUfyAq90nC1PiueU2zyzaUYN5JUg9rzGYhoTlLIeAe37oga4nKz+ +6zZSm5PxjTN23hevP28QhMAiCZmL7dXmGhGggs5drmxiwVJ9dhZV492Iil+ 4PFDqr6jSCJvdvDFDHsBG6iVGfE+Mth/i8kfr9myBMl2frJCa1QZvcg2vxXl PO6RWs7IaKgKmtf6vN2+n+PX4a8PihhWkvYXH25Fnacd24E6jmCReoJH5MM2 PKWM05BJtKz1SeeB7SSDmNZIr1IhYPKuViEh6hq0I4TtoPy5WW04De03H+jp y1e5A4Mn1tRgj25gagnwW087Bi2sC7hYewU3MykXHV+u3paW/EWnWdB3jfHx yFRC66bNCLY7QrFCeo6vE6nMH8Q5YAkWnMi3RyV8PZLoGpFk4nKLJF46+sFt 0WsoWxrqZg4OBw/Dveogehqqyq76X7WTE84OsCJkii1Jw+IC+nFYxELARgQi fjVJQKyK5koKAqCyq+7nkhffL22ewllKyKSSphoGg9TswPzG8zRXsuFyj+n7 PV/WPc8KMQfuymVja8luquWS4gwZIxziuQRbHGLdNx5MnpMBtldvE+IoiQ7I 8eUYtrpBUpxjnU3xvoPcrW7HQT/FzVustoydQQtO8psAkmt63iZNG6/a+PNQ sotDzLb3LhY5bBwNTUJfHcODXVfZmdYYJgq3yXKiVqU+lTlQfkV9zPLxYhBj WVwLj5cGKWwzzSGazPDqTomTIfKvG6WJB7LsrRMcD9GS3jLKEeE9DniNiL1O KqYOkNl5eUdNFRb1GCi7f5YEngIqM5UbiFaXbiyUdXL5n7gtZ09qJChi+WPn /XqUVlvuVPRqtUhy5mFGzI3V81W1pE5MiUVfYnO8cyAXjWot8eVQZ4C53fFt LduMRhyBsTX+dpv46WCy6Gb99AG6wl1iaUkwochfQwyaDu/OPdzh+l5MSwZ6 RnJfZnH2kKTBuU4F5dhlENDlGIRe85xiJ+RWVJfk6Tvak1TlIGV2md+luF3T LIMLiKdgzHeFlYqR7Le4IP/mN3yBXgaAziZxhmTM9jYxtt8yink1A+yfsz1f 1G+f/J7bf3Hz/XgRlxHT3Q0urh8a5cZsOIrDgdxC990VCydDY/oUcShPHAsF IuyFpA7rfVeV7pHEhnXGuVd8vSLu+tCv/nj+28mgip/y2GhRaBO/zkq5FnK9 2APQksDAadt9Z7LOOcF7hqLT/GUsJbbGtp8GwqHvzoaSpyP+dA4gs6XBD9oK LC86gsvruut6JK58nigDZNgG9gV/X1J4l9CTVio6Ot19xBpTmrKLs8Trjlwl 4gJJnV1GatUdXImsPVAwn4Ot7zRHJjq66vlBmTaCGb7rmvHpJSaULchOCvyW W0jSw6oTAJhROV5dDYibhS+xsSZ66Hjs+dLuoyJh88uW37aW2ZBlj9cQygmy xzECvQWe+rJ++pV2qeJ8wgwmUoO+1s5qwD2tViNKLyfxgEkOnS5O7vrbesbn 7SOylyFpPZLWJYoE6raytmkeF2LbkO6AP2NOaKLQLp8RK/1PCzce1GAstUp4 JhbJMNv4S+OXRWUAbVAwNwk/omFC4p+LiJSogv+QKlzhfauEmywes15dNLsc SYOhWeP/OUnCx4JCHnoDmxz96sheLlmHMgNCTIycuItuHRcbvqcOVcNR6wl3 yVvKGkfVazvE0zxSPMMS27j1ZsrP8oeia1EdQiq+9N0fJWA6cg9BlhR0/gWY o7Qe9nhjIkO32ZMeJB9ifUqXOvF30RpupvV5Y7JB0uHaWBfcHF1O9AbuplUw UrRGZ6gIhcQTJTIbCyD6mOJ1toJDgxov7yqpvgnEo0BWL5QqJ9UT54jXlv6Y vXZlZHLxkgoGI75DSsya1i25HQCh4zrutvlmJ7oPRYgylcdm8ucFc45UDH8h 32bTFgGUWHLTWiUxhFTu6D0Ot2aiyepTIVKl1FVXQpqy1vVv9zXUUobkfK4v rg53Ae7ufY4rz5cDwmBmdbGZ6ncoBeavfwutbUxG/uPeyKyofbZeUCTvEljq pdsojSDKL/ibJsJCZ3Eu+Qs2pKFEOtc1XarN3DtHBvOvTkhKKqqahV+sLRKQ Yo+iWE26M+NXh91E/YVKyC8O8bbGkZrviuAwvm4nb4mVY1maJlFJ0/r9pv9l kf9jsUsBlhlv67bhu1ha40P/KMqDqGF+RZYKSrntO3LQmPMZqtRUl1g7fb/7 uLamDYJFdnG5KLaQ4mG6cXlnsLe2O/XwoAxDXj88auacAofgXjpXIe6wPj1D KJrPkdc7s0abuqLx064zbwBw+cStPbKufvFtE0T2GIDwei/Zz17cVlHyf+OZ jpHsUcMqVA1ObgplooBjhRapMUil/ikjFi+mEodtMSJuE2kLWs70vjax/P59 rLHD2exif9GE8z2R47bwwfwIFk83ygiv2SJo+dMVBCpTup0usOIsE/PajInq Ds3bn6BhvuLcCooEidanX62bz0Q4cd7zKd367av+XOiVf1rjfrgOt24ZMiSs 1Y6kVPOyXLd0EOYR1VE7PYgcGqVGknNKVk/vubSNL3BR5qSNKgKfn/hSmWEX L0DrlRYL53pfGI/XXjoEgCp9Gw+Gd93Kd35maj4apvMK9gtjc28klVLY0gEP FVlTfF7TEPba6jzN5VfyHz8BK/HCZtYbSZWcZMb61Y4o9+bVIpNHy6iGJuIX j43+EVF/78RBa7buDGQSATxd5QgQq8v14oOT97sHglK3gN7kSNc734p/I9QD a/I7PWVOzqOBOliihqpH3HtlLZbYLh0bdLD9gnqx6ODuLVlR1NEUFuzKm30I AhEs1qmbxp8OTQRs5nvVfqke0j/y2L7yDreIpteBdyTGgBawImMtJPPg/52a V5Lkya2bCmnB+3eUBjilot/d01m2uZ6kdvZ1zc8fKeTCR/Dp2jn9E2XegSab d0XVlw7XmgQoG3KY1vW9fxSCl4kLR2Znk3pfGhO5UROf9BR3USr2CaHzwtv8 QX+xGkoduQ+eiCIaKM061jceL7eh87kRgifEi9bLzYSHl8ehAzXAzQDCsNDq YP3sum7MnzA1c57xHacl4yk5WN7jWbR3RlIVJ+JSY/Vi+l7iannKo73PIYCW DRb8JcbFgjPzAClaSbEYiLy8cl+IQvRuOP9/dM3+VVNckVBCzwC3Yd4yN5WJ 6bu+3G0LTZ3I73RLZ47V+65g9T+xK8ruJBF+HDxY2u6ZQWe7suhtduBwrt3s dIm48AymOtSfAs0ljqFy0Jn6wbffyjhyg/FO4+RH9CLtXpdgvRY10aaWo1QP rgrE2PKUmhH2Awe9xMls01E22DRKfr9ghvxqLkGK6xMP/W4P6mworN/xQoGi t7faHsZhx85Mb0O5tBs2ws6aHD6GsZilxcoOQe1rkJtjKAoP6qAbIsAffNme 9P3wCCRlToIeEGB6j/cGl+Ig/CEaO6alG9H9oH7I//Nqj/J7ky2NJQbXinBH bjavyPdCRDvmaUx828s62SEmyKA+Sy7DFA5TOS1qIm+vCPLST3Xj33sPouWg 4UtEJ3bWADoikaO50A5E8OAV5y2mC5Z9aJJ8L+50sKg/Ro8xNvm5mrtM8xJe rHPOcyzfFIbDIRFOY+/hXtcVvxBFGm8WrMkxpd2vHXoVMexl1OgtNUWKk9Pq y52OOlhDlir/L98HqWjCmT6a3HBuSupu9vEjPxRoLvM6hY4GLy56d8mzYv75 L6Lcg6uHt6TOMr7Ct9qq1Hplo+g4D68Yq73VLNJR1CaW785bXL7DHDnFMTYm 1p55ntaEu9AuVEF27s2uhQaImDPnbRS3vvH5yG03VtB0cUAiOvMi2y4mG5AM YP5Ma8cjJQJVFb3OT7z3d8xRphZEo7s5s5U0TjmMfWIzTlTJqSdJIiivM4m0 TL9XofiPdhcIXWzuNYFO9Utdz8aRXzwCiBSPRm81HvWzC0QQujrWnhxo4nSJ 2dneA2pjt5nH9L2yr8KAoH1S6Moj/uLb44HPf+C61JcHUTSTPo5oPmpmT3+h wqDXWTM6uxR7GGCiQM/PC6e7wf+OPaL46v5l30F5dyqt91Wh/m3GQZHIdRVx YU9OEl2EAv3Es79HxIaAZkxMvG3Q8Wo2uJyjOnuKWJw3bxV/sq7YDirIfCeR tGNGH/8Bmeb+guK5UyR/eqYIzmverLepGUmEcCcp8rd8bz0KmT/ysPp0K3Wp cvpMoKsiwp40IkXE8XrccoX6WvBus8ImF7IvEJ/UUmifYu90VJ0lreYvS9vk 7kqTJrVikatRAUZPxBfaJh6M2gY/r2W5FoRpt6Hb2GvOdYKkwvVr3Ybp68VC JEBPS2e6GArJ/ObtU/5yqaaENa5IUdbZ4/ykZjIiisM3kJur3d8PeqHZa0Vm TpbaZ8MFcUTKAsMVDKpEEDAhjqug3QOJf/n/v7OnG+CdiFL7A2ds7nGyQ2XM oWbjzPkZT2+lV1KGTHrSiO8dQR7pssZSQTvTUVE6K0NzBLaVuiaUY4Vuqmml qtahcP2YAHqm6Xgl8xfWjQGJxrKD+pOPXxNfow7+fmtKVVEL28fOTfJs8Onm 6GFQaopOGVbL13Cp64BpPlCCuSnss2yGMC8LGTj6rYtL1GK5t1xULSm45GNA A7dDs8lrKp6EMaY638P/p7Q0jgyGIcJM6xeG6tDAcmtcQbVLN1Da8Bl2BUw8 NOKQlMMl2G3Vb6hUqpVX4xxJyTMwc6za/GdTclJGPgv/gppEmgMHU/+qrA1Y rqB036JKS4huC6qZ9qoQ/rEAjFOCIe0IXEVa90fKNchmek8rFebu31X7A4p6 aQnUCfEsihpdT8NOsRb9qlLssCvsVG5iyntJKAHoUo9ApVh2j71R0rBOHCsr kIOFoTn95h/pqIm6Dm5ZF2in+g6vZROrTBk/lkQmTv5UB4VuicMuUrb8Iq2S sWfmh25XXIYxdtzWVTqhBRkGctattUaszgSFAyyVORID0z8ko/q0QtMs6+un ct2BcF4z75S/vh4ShiFSi+IS1suuHbdwD3CHdvYKdoHEPOVPu3PP4Ep+Pdtm a6OVwTWNix7t8ofpGmF+a24PdjJPQWAe2Y84Z9ZGlgY+GBAyqE3fa/Wwy1qm PDcgZ5sVHyeFNi4T6+nKFllvJUFD4YKGqLlMRRfQhzpFzJb6nstiZERtw3rd QerpQ2aWdAIl9w0Lob4wsR4a0xAnIl2qHEIAoQ6Ogg6uirz4u2NFcC9CMnGS 2uu24Y6qMIrGMAfGwu00jOWczlX6At0Yscky37+AHHCBy/U/mngPdDL2mhpt 2CvFrmdRGU7n2MVNdBJuku9sN15R07DPWNA5htbtZ0gEVBvPOv5Tw9IWc3nH 1MXiKTW6GjjH9Pr2uGj2GPFSlJZOQ+4NTt2PIZkUZgnlCBFcS8Ye9/X+kqTb N9ZodKOSprOpgWRV4uraQZ5qdDFUX0LuYluJRS7r0i//9rGdlxK5Azk/4b0k d15FoiZAyBuCovkxv/Db7Ffyf51+8Wn/8g6TTAEWreE6DZoJlDsRC2x1+xvs CpEhaASO6RIW3LWhXvgXF1mNOA+TA1l23fE6z/UIcN5C3Rf6PB8GG2NZ3ddD haN8LIYXfybHOEPgxESyiws6uVGhyyXwkOPdLcnFAlIp3rkWKcdK+WVoz4cA aurn6nFeu7HezovQhGXdV4kqU9JVDYkm18K0cMeGLVuQclD9fRqn241lSm9o liwU79ldayiKJzSufoQmHvYJLUIGE8oAl8pQPb3Menregkir2WiidB76mZmV MQbfAkj0SeZC0s/+YMTorqNRxj0BvHqZignXSk7n0O53llVu11avfcavT6p4 hFiqvrR0n7h4qWKhFVql/jd44JzSwAKZbpahj5JU1cZMjOqCjuB1A44p0vUh yYpz5SMJBaXhkuJPdNJPIvcV7Ze+biticKVqtQgYS7UNbwA7sfdpwzPGOqoh WfIZDXpU/OFTIxHSdqFST+bWUVh+BSaE0evVOk5hiIz9DOys2z9TaD/VRl4W nP2gjZGYFcrtu8in5l16xl0n8xWoRvq7WibsmsEIIo0Gd/bqtp6oJ75HFUo2 3sL2oI/Fhg4VxOHaDBK5f4tTQz1DpTKRcWqIngvHeoGGGQInc6hhrqeX1nMC O5mSp6M7lzpFouAA5ush5Zts29RXrZWSnaLwiOnjpOZuXsr4qJa/ZkmF0D6D QTCy5qquqar5M05YCiP4kL7LHVziG4wC9S9tm5KMoAA9Fxo9GteLc4L/Hh/H tj0GDuCiATzvMGsWZQbrXUvwO04ukeT6xFTlT8s6YGJJE0xegmhcW8e8kzY4 IMMCotCTVPwoPEpNFPgj6l7tAky6a9uLoV+6QEPtgo3mkY2Q3E6O/4a2vnwj PHlhsfai7sgr5Ulh5xle0IC23eIqXEhPAT4VTBGqjbMDZsedXQGhCvDtKjGu 9yM2n5aw/CIyq6+xe6UZkqrrMFvWCn2OP193fP5JwiVaiasjMxo2pxLz6rwW OGnSR4HF0iaFwsuCZ2dw1/GBraq37uUGxiIra/OP5w1x5SBtAYdF+b9ybQP5 F0YLWRlEGsdmFnYpuMsltV+vefboHHXnfpVxap1ZqtszbWFdPE4Jl9sE7/6E PTIw60KvsViugptC6MYjqRWDoBZaPq5cA0pEekaLKEBEkiEoH+7DI4THA2U5 5rgrAJVHmd4BLXeFMVDSwuBd23xcbqDDiWn4sJ92djaGY/JZHXrnvlSByiEX /33MtnQkbOecyIyult0NjyQyu6YqEOdSyJZ3WnfsF4WyJUAVJ5Taj3YP0449 7cd6phKVLDOHOzK7xh3/T0DiC9+/FTJaFKfSYfLK/p94VI4tzjPZ+0NkQZ72 brT45XdoooYllmgj6XcnOS7ecqfLbZgFiPko9DIDEpWOSkozfhvGyfyql0wl 1j7d6at1iKbqqnFbtSTeODrkRZ1hC8uFuphZMNLRBniyxWT2EgisxUSNRT/D fKusIWeVlH4FRV1K+/lQYe2k1/6Vwofto6rCZr2MGVmwS36ojOJbARonA0XB RgsSNqOGzxksf84sePzdLGGxb/lP6uKciAqfVx9V7x+ZBWabG/uv+SLvagTH P4EsPQNKoxFGKvRxFeG05Wd1GNHZ1X8ClbN8L2/O0+nYNRKB/UVpqniMjIDr i5Queson/9wDajIcEmv5Ts7mZs/KoFCM3HPdvH1qq/wFL06yZWNh6JaEaWDS Q8xeTnm5FyFxoM6G06OmImhyTzpaX3ka3fWb1xcy793VNiYuTIbgo+ewleVP XvxAO8SHIxwPAPoul/36KoKyMplFSk4fVCvu20BdxpOXv4NOFM9xjHsG2gJo /R9ckXma+D/Z7/Gla/fFLmSm4XbZaeBjlt5mZG761TIHknMhQXJKtlNvhPW5 XoZPexYpSZnLEvNdMtqUBgo4FyYVoXEI0yBY4O6Xaz1D1CA2gY0Z7EnFIxge 5e1ddfwOl9Z1KBMzcKuJM2k0AepKNjQPUOx3o1lTZ7pcxSh6bgd+iyx+5XNM f3dvPeXhYTbPQa1xmUeCIKOz0aQQ7Toh9piVuiFe3FEE1EGUq9CqCvaBBwUJ w9/8Uzq+14jrTvtCZXbusMyh6ZpepWaHNsrdrzju6lZDEdJNx8HNLHtxghlN W+EgzZKGmEBoxdvaObG+ly/sqdAiFbxeL23SxxPAOQ8/BMAkAmcL7O6Ir2JF fwN/hl3YqnEdjKQrUlyZKvw2/yPG4Htzbg+kz1t0Kq+1/maGVUhf4qM7mT5F nGyvnkYK9zZ0tlI02pJZLsS0ipSFTCYjmSlG94JfHufpS9pSVlpT3+BKMjyv lC5BFHNsMf20Rh807aLwUF3e6rtdWuoiILbfj1Cv2dhKbvomG4+6VOy2Wac0 P8CArt6TWGRozPzPBiJPcWGsydHFImCq6qGmxtE8x3xtFby0vpDQ6SBrMVzm Fb/w3185uQ5HZKD6F5lhdv5H06o2w3ye5mvApM0FfsbTPAePUmlgDzoDCfrX rTmU0bebo4ES5T421SubcpGbprtffnkQKbd+nh5j61qNt+JWL6Ybn/Gbzoj2 RxtDNVNbvEbCe2iYf14Z4re6fWxO17A0N71iWdHd1MOAYD9KRfbQN4LXGPj2 rk64Yp8viWhm7UDqNTk6ck1fFS332vjjnVNBu2zBIz6uERCy65J8KMSFZyii h1Bh/gGHs/s8JNfDZZ6cguE/wY3Lon3PZcy2z1q374LaHQF/FIpiNctZm5ZJ 3m7b4ggMSDG2Zas4HP67Gqf3Yiz/a2kn2iian+3ANhyslVbcmNMukT8lK0ts RZJZxu7SkMAKt1tp8PKAaLnGf23hD8BG2g7jpYz6TiucRmWM5GLTinH6R3m3 2kfe2ZeCTSKdOEpi7rahJmMQS9Sq3u6ckjZPztuvaD66ozZkttWd//RohynO Yi3yuhSzs1KBulRfVo5NPnJtTAr9k+8J6j4XEmI+Na5cwe6P19QiZlCVm8Kg dkSO1paIqeATRj7M7oDNtZqWL28R8J4ma7nWtBrvcb6PmxeLudRa1CaNyU2N RhIId7nrKMD4yv2jZSb3NKo/2r8j3up9u6p2YkR+PsoN8ll7re6VsHzY3woo llpCdEhlLiq/VTTziimpzOYjvBNXh7dOLqnrHBoyehXmEVFz4te+ofadqSr6 2W3WwRQ8nE0VKlFOe9CzX9R6R8caORCy+p46w4dYsdpblzqmyVzzVNacPa5N oT5Q2Bqe9b0CW/2otgMeN815zjiiYoa89emI2fmbuDwPCcaYmtUH0YQP4g/P hF6BXw0n+xj59nWZGjUXqtQlA9cE5BHWHtsQl5bC4olBjk131xLf04DWXD5O qoylouQ5Aq4VWjlkFtFj96JK2Fp67zeKmqWl8Etb9AyXaG35bsm18jUGMa9m jjak9pkNDU4SQJIeYXAPlnewQ2Lh1UYKSDO6qmYZksUBaSwIWodmQcADGVpQ Qi6JP7qfQtQFj2obY351xpZTQDNT88urs6TeKKrYgKpRnu8N+9ayJCX8pHQI zRCE+YHEBpBhmwWN835rnjza9WDFebBKMN2qNGuhpB7bBZ8IF6UqX4LHtIxF yyZCs7pBNVKeg5rdIr2EnkhXCF6vztBQhsZSxGfcpMI+8ekOFBNA9AkAMqgS kFGlz/6wDpoVOFSle3C2KWns2Y6zIqZmb1C71oMtZKLz42mqQfGZFagHK8ja otdd2SiUvkbXimhxl6yHDruVIwNN2l0wbB3zBH9VCBQEq6wmKNjsKTE/DiLe e6U+9LDDMMSKdzaAxZPFuRw2zq9XV8dr/zNZ2q5a57KMpmdpSjpP5XzRUz3P okB3ZHZBTP3EhbvrG2ze3/pRkTapS/zRxqHz2p45xAZ6Jne8LZaxZbJfTwpi bQqZJe0c/1yHIdySgbMD7nudtd9mAsOm9bHIE/vLZc6iAQqmXi9nFrESMOLE xJ3qUhLu1ba2iebOfIB8favrVjyU9ZrN6hZybGniklJaMD6xrR8NQBTSMRXp xncEjMMe47RQhfqQn9aoNZvdX+Jn2AsZnG6udlyGnWaCMnPawAkbsaj7mB5A Xn4C9hKNhnv+V0z3gkhLN7T8sFAXLQhS3jkB1Kjrbg9mLplVAnG9CcVSxBeq lBaDBR+QMekEfUv+g1+Hgez+S/39NxaSch8ILfM89mK/bC/mN6/9Jth6oXVd tEpql0o3SrQHtE0kIeSD/TsrKjo/exWU4C8R/bmhL5B3odojbQH3/UAoB8uS DO5hGxXanZYSLN+yFOlbUeyfFNHiPvNX8FbxPVGxKmkfTQVUxq7lr9TG2pU1 IRXB8b0vLLoezAc5tsNNKpE9MeUkPL7pW/Ol5uVsi7xXdNn+HtF/Z+oM3X9m q50jCwTyAs6Lf9B6FWWDxW/d/J/QjgYHOMGfyv8NZ+DkMseEJHHRY1RbomFr hTNfv9Dr3H7QwGOwlcY6eXhtNnzXhPumUaDe2OGWVdR2sYuTiE0iINEZtBpT 5inV1cya8NjeEXl7nlpsml/4k40LnpuqxyWC+ZndqedSva/FBx2uO8j9jDHt XYMfrj2JbWunqX0OR6Bvyxeqmbe31LNkR8e1OefZx/6X06qOeJewzZCpVggp tjjn61bm47plmdUWiFZhYhKQ3l40YwO95ZS/b8i/+OIBqFs8DJAAmgp9y/Za ZhwEqsXlLQ86Do+KKwP0RQ7Aird9b4x54vf/Am0q1i01TyR8X0nOpsoVZ4G9 6wYXOAymNS5J/W25vX4Eerv1AmDgVt/pxee23RuJ5cMVJupqDYzkl4feXUXW UNnmfF1zFTKipyk4sX2+NurC7EhKOb0VpTI07v6x0YcarHxFlQbl+dKgjzKu JlTKypVi0b4f3U3SB4L1DcQhwkeJnchW8iIodZogBrYjqFsGw9XTmmL7D+TY rnw+V3edIJfeZZcMRYhUwxpgrkAYEuzO/MxgsNjKQjDXTMTfPiI5mXi2Vh+R PCKJ7xhentQ2vE5TcVGFiKZAQieE/v0QpRlKKX228eBlYnxe3z5rDRGpoaIp ztuM+kFopZNe0GQfYlraNUaT3N07vx5ID5r3r+qzeXuuKdzBoiNLbWzisItc nZpsXl6MpRL4blPrR/hXytYoVKsE/ynCe0Y9a+KSuzqPf38SKtTvT4ce5U5a 3Zw6yQKHjdnrwiJO3pu+SFAqlEs6+xw9qbEZl05tflj8KA/3R57mpcQfEt4D xwxboHZvWQ6CVvt/ayKamXAqGbeSlQDOE1FrW9/dYfmbPu6OkzJGMXbJhXue krsGcBQREh7rkoFtYElCB0LHUTfENcDnfD4A8Fa2EGL8RAI9DcpqRu8BkTQL KibJopkJqh6o5KmEHumIZrQSJnMT3Ro+9rJaqTgh2ZmN9DVpIx5xjvdPK8/0 a5/WsLqIosYQ5Bfzx4oCdJk8ufUHVko0RTX+gQEKO0CylXaEYiNyqFDc6GPX Ucrqfv8xiDtTEubxm10yXzU6c2D+BpHDTz/lPOB9LausN1RQUqrhOv4gdXRT LuPgiOnmmEGZ6JsZwV4cN771RpKsU/CJdpFkuU8opBui82zTajyYbXrm/YNy oh/jm3WX52qVYGrEnLqzYWA920KhD0i6uN0XljpC/ZJ0LPFrubYvSmkAqKak bz+iHtQZXli+urdSqIuTjZ1AwkR8/SUD9qa6XN3aQ5J6qCS1CEB+Kw7yayD4 UrZrwRvCilyMJ5kie0oPKaP+j8pvS4boLl7+1nSlXQcaX2fe83Ltksiq+2QG YRFiQI95mTYbwMNv/iMJI4RGKuU0hYGRmchqU277Wghatj/Fq5zve64IUzcj S25qOp6npxLj0+Hy2jKX2R/lUyMSFB5GgvIV6b2LI1eJsr6fupcwduDjqlFt CuIu6XCFGBrfu0a8NnOFylBl3kmd/vpDDHNYwnxQkhh7lCBEJIAeA7+LVrck J0dMd/hujH1VStBSyJdRwTZ5LDvgfoYwcu9AfxVgf166QvVSv0p/rB05ZP1j VuQYOPc9WnfO3eRwKjspq4bN+Jf6VzKLrgUPXJu8dnIJSZ8uwLNK/0d4NTgK 8ZPMxQBIqpXLAUZ4UpvkRI+fChCPjGUQbGU50f4567M4bjgyUMjhMv0VJ0Ny daNainf0SaNfFWZYeh3+wStDFev+/88LqTiCF8D8Y/786jqPcuOWL5eZKYl6 VU4kJI6Z3kaP7u4fAJ2WIjc6Ec1xGoUzrvRCoNgqjtmMvmfjUCrxXY7dEzCE 0nahkHbm88YFmnFFxkV/Ok1KAkNOykChsWTtVcXMsx6yKREB+6cyQNqsqrzp CH9yxPV4JlOJSqRKZFlF+c8OlwKM0Q2ZrvGyNdr6V0DwcbL34f8yzocJQ9WV xGFJxHcdaeu90H5ZYsmcX/TH9s4fFlG4Qv+Fxy/0Sj2mLqmXx+SxK+GNjrxo ljJurcYx39BN8m9gkR6Fk7ksJwakGFWAIGP3ZW82mG1apceUCXD0QthEZa9F 0x/EQcpvidZQnSablTLvU1UhqxeelVwQnMbO/X91TxkOu0qWTEpzX1lH8+HH 6mB7vqRK2BQPpHXmIeXhLWzgIsNxDQxNoCNNMSKGAalxIKoOLcWY/+EUPAgz 5WAt9BgeJaPL1GJaLJBF6MFpYlAEcXfaeqpKrf+NycA9EU2Z6OXuRpmO2r7s kSM8P9ACI7h2Xh066YiHtKvpl93UMgxzKR2mouURhAO7xvvHR3JlDwD4dbho 2upy6fh0zavTHEt1rtnYmfcr5G3rGaVfwslihLuD2Rv3bmaJ1jwonrTyl7LG pn7BciArrbk0qWXim8CqYhNpWKUFBxX2is4JWg5qlug/0dN0ert0rflyDcJu bMNT1X2demMyMpbQyFpSFzeaJHp2/B/YjXwGuGA45gHf9D384QT7yQaL8HCd p0fWBNEuT3NHP9r/Q+ZPuqm6l291/82SbHGFlHUWA2aKKW+WWIPLKCto8qoJ xtDyZk6DEF0QoRsar686y0S4WIj9oghL3/g+LiPrj+KYgYrkZ967PV7UM6El POJ10e2otnKjdudNIIOAaphPVgMMNJLiBh33foiNi5qB8vuyX8R0UnbGF4Zw sOeBkNGqZeFELd/P/gKOsm3KelTBePJWLEg52YbmHsT7RIutenek5FPbIcuY Lqu8OALKpO7vriAJToKM9q2RUnRuczg6ryZIrusGxXo6Tm9nydII4ZKWd7fv 6u7ADd55D61BwxnmljytLJv7Kv4uQtexmbEVQnSyEANCUZVH4VVFBIq2MCLn sMP8QSsQmT/ll+mPvBGxxgpXesePxQOeH1lHKXdPCOaDdQNNRIlt7uh3PzFW QXimUYdUj/c1yn7h9JILLmpcNsbzjsmWCRpGSjd3uqzjsBZAN6kHH2WxXqRc Jg43yOeXuSNccuTZISYehz6a833nZoKk9HYVrHCuBy+itzS4G2b9d4VSZnxc IvyjDOp7UK497jrnotyqxaRK7nl6VxQGXs0nRDJZrAR3jwLJ0X07x/Y7AhZl 33Tn/j1H9O6/UX8moqIer+jBy04G5uYTAfBdBrcKcesVpK/evCcPs+qYIZZJ 3Z1z/0yyLoLvy4r0jO4AfApdQsgHu83zLj+POFXodtfSdgZmMOqePBbgPXIk RFYx6pQxljdtTia7c2+wOK9W2dHz4T44lWo04yF6SVBRP5SqzAIVOQV+aI5z qVO3BqOY6K+SeFuRRxxKTlNuYRXpEM0Hbi6MozFCwAq4hkevRaBn+HfynwA+ PICmP+/v2Xap2eoEW1bbLd6ttI2Zl5Um5pBeUh37wFqsSb+FfcCSouy5Inr+ V8+WQjTLf2vnXE2mpIQy8CteOR6BG6WqcL9dc+npgsMnlnqs0evKPjzkUyix zRKjzNL6MQoxxdc0EwayWcm2OK8YjXdixo4NeH4SiDEknXJ/SUGVuRVa+9G7 Uu3nnS5sQkHRXzPcyuSATXMmQ6tCuGlOnrmUN/mnfvxXSNXjE4JS9XqzrNH6 J056xrHQWCo8ansWpuQkWvYxyMYY+JZR/6KehI8MtWYrNkFb8Gvqku/a2VqS MXwq43QnfG5YoedkdtbOobbPQF2sCAbqnOCiUWcONdwUIwosbAfz0Mi1OD8S oTslqNcK81albbqQmVJO6KoYj0TqEBn22dZD+ROn+hFljsv323OhJpfLQLhG 4vey1tsO3L1aR87wM39U8xJsXO/ym8uuFfBKodnQNFTiItzG3sTztBEeHUKX tsN887MxSKWyi306b4D1puPvXmKd2RxFUUb6u9KtCZ59fL0tRUY/Cp1rtIp7 1lAR1X8mQgcXzw76gxtHn12QVl+QZiLJQdJkXVMiuLFa9IbBChqCA3mv+8bD H9q0MbwqMUXAAryxmiliL19KIfV7TVpPJJLQTMT/ULMnMY9q/1YFDh2lXzDR Jqul9dUcP7x5Ea3BMUhYtT6UEX4KTXzhcyB2H1LSwJiuJ6JBmld/KvZR7oVH ksk8HrTZMIEQfO5fL/GHcqX4dHFgBXDXZhsuzREdquKOg8YpKOJ8LY4cJSbt iao2ZIl6kY214HdFldkmZmvdEvGYm1feBeN6VjdyBsBWPHexEK5Orpm3Oq8J 1emfLpk0ueWTH25C4/X307so5ZNRc10AS8Z8FxF1UqE2dpwu8IVDjIVh/m0t E+J4C1a+7MlRVQ99h37eEyrlqmotek0oqSp8/Y1yoZky1M/SNkJlCFRKGrdO /Yn995HS9qazKPmSPde432ExZ7qh85cSnAWTfRJECc6QMf0ui8P9O64M9uJ+ 4v6u6hG4EwBPZX8icYa72D3TruLQbANeEzdtyG3tUoMOXQvdQX/7vhso1kGq 418+j5o3ZnnT6qAy5JL7srqh1dxKbo+xG2Y0f+EmhGW4KboswS4Ju3UhGSND tlKgTfDyFtVOYj6VNH3KJ61St1Cy4VzAfRxQoUIc/WT5keNXf8nWDFbuxEUa QVPedrqUuFC4fPAuxWvB8nmtnWVjPxCSJ2jUnpiAgEcEcgVWS2FEE8fOtuaN uvBquicTZzaMYmJ+8kF/a2BUZ/PCTTYBRk0Cyo7vbvGeMApPLb+p8zspcUNW 8s6uALUQ/p3UUdtGDnIt7b+et8jvJaDhuYYclvXiFhZ91q4BY5pd2VumNh2b lAe+Qi7Fh0mOZ5F/Zm9ElLfl9WGOdIktejVh80ZIoyFyck3Vj7jfnXpXccZ5 P7w6MiwlKH6Jf4JgIRm6JitMx2WVzQz+MMfqSOkZnrYFi8e99XKhThl/KLq7 mIOO7lO6YviSODx+Bww6/QHqZh5tnvLyxawwozukmWsNuwRdg2JC237uIq/g YopAu5MOSXQqvY/EDp4vjJdyPpDkqducOQ9e7LIOGEIm+oOx9ABKGZ3JD2VF 7sSYB9pxfQCkt7LHFQZ0HTIUeXL3ptFrpuEvRJJL1A000cb/dTDnR2LWktji VKT00S5GKbrxtNAWIzq7WoPxHFtDYg0KMtD4lP0m5EAHrNgWv1bobGcYKvYW Qtyh74mALLtkPCQqUIUokF2WRgUcnx70njHoXmACvwnaKjIhamNu3Y6toygB ZbYw+A2CrUxvMD7GD1q8Da6ubJrrvs4qdCHf7TMukIgfTV6qMPIPLN46IYZH OpRDZQ5vedjytmOvFMF9EJpTQXs26PBe2XLr9b5dwHgCl08IDdqpgNILZ22C OfJ9BUt6WfP74XgnUm5sDjswjs/qnxNzSyyXInfc6oFmPIrpUxfSs0c+P52J G/RCvvsiycbvZaZLdugT4lNHzlBNY9D2B9mGiCeCcltXlbpHxWS6wAMN8R+5 9nLUYbiur21HoNmTWmajQdkYq2mNKoyluwosB2pmHXnqxjNjZh4SprHqnKfk 23QtgaKRmz3ta2QSekXUh0qEkWQyeiIR9ZDN9spPFqO/qzlIgkTK7mrqxPfw aW6DJ7YrLBItksmCw/C9qiJGWp/Y1A9iNjrkQ9WYgToL7nYM43sT8gDCDJ4J ANEa8SG+5u+AmN5dUHQ05HRIdSrqFWUUnE5NEa4TDs0cjzofncLGwvCkUgU+ SJ7XpDCDVuEmOZGLLgYyNU5aMNyD2l3ALKa1IB5QXO8hfokU93Y6Gqc2nshJ SeLykZoL78B81pBvs7j/l7EFMYzIfEO+utR9pOYJQl8dJKxpOtZ7gu3B9dtm WojAdtnGQlFAymEKug2kthl0jcYvG6AfqcvW+CK1EtYYXz/eIY2EjpJPtJjd zWbWFzMRMhGh+MJxaeLK5pVKwkB/goL75UYcUFMUWs/Zn7bKB2a+dPMITt77 +E5dxTEG0wPzgCS5g96oLzbdI20Ulr0mdWrFYnN3Vb2/iow1g+b+raHSEPoj BnxogxqV3U8XFk16vQWjUJp9ftP+BfO/xnlVHJbnqWJeiIETxlxcZ9VCFtyy 9sV23odazd1R1Gem/cXYzO7bCSg1KQMKq+0dI052UwKgwExecuZ8RWtSOz8u PvdzT+0ab8NSaaGF1CFjh9kzVX0QFL3QEezaZ+f2s/FeLsI02B2uVl2lPtXM aY5ej109g+XyvwBKFry/HuyWNB4NycdEWnHWcUoBg5wwRW3V+TKIIGV7xT+b WqcuvhzsY92Ckp8DuVkBvwY65zTgdD6Qwuv/CB0N+KI64FAfkvdld7LULuUi 79GGISG4VwbEZfjp+ms1ObwdqXoKzop2rYBh1iW3FBxiEudNGT2Qppa1v0KR WH2vk8kx+oVzapAFcQLyeke2PJ1r3pWQS58u4ICIgyTv5/2ex3FfX2JxNjJu Ch/wbAWuRwxp+jorFU6mjbH9X8CHXjHB6XHU7EAUJv0xmhznas6qjglMrYvt 4KQd6h32jx7WD7J4ZUdkwPb4pOdS8zaCgEdKa+IfwFuZxwsjPdNnHR7XyKZ/ 0bKH5As2ofFNVnNM5H8O481R+9Yl1KCSRCtNbjkcIfBlyEtUey/n1RwBYC6T wPnKjUIz3ndrK40GA6TefCBQhzguVpbLDUzya7beyZj4BHOfBX74CrOeWeA9 y/5Pyq+K2jJNKR1nI0Ku5kMOA2f9jaPaUXZq1iUdrddq6/X36S28sqTVqgt9 8hHFZB6cIN/6WGUNLaDEwcnn/Wruq7852u9B6eSeJDUCdIU1cFU1JIorR8R3 EDpO+TFCoJ1NZ46zUgGjhlTiaXK3pmNLgu6eKq1ZmjM9VRDiLZBRuNv3KYd0 HgVzT79Hwhol/CVcEiDnBMnejtKr6D32nSRS/tcZ6uG01lMiG3a3pn50jr99 tBWuXGUyf1NOMtYkkubF11DXvoz19jWDu8rPqn6uXiWkWrS55KMDluaCKj2O NjfnFzqNFVR9HisZYsXh5lICcQRVeuXsgLJihd8Ms1nfILPsu6EgGLW7gaVf k+jZ0ab6qIqgyJHnOycgx/+c6F62A6j7s3AY02X6WLKoxFEOLqtByt0YqcL/ AswikhOBtSyWbbCGPzMqBerfmbubnDZ1flHBiONS8dNS4wJlDzyt9Hny/E3v kemrdyO57qTfnh9DXj4TRyeawjeSZ3eMRv4982uaLGDCsSpIblIhQKo+i45w Xf5n5pnvcZXG/ZuOHwXGww6cP2xGaRmIG1XDboebIzd6eMeAzZRVlB8qvRL+ gP27jC0ApXHLtfyZAFjiMYF76/Ua56cm5nkEiLB7QbhtZw46Y8q0N985xRpL Kf1O8so09o4fbeR2HsaJiFtwLvbyDfJWn1J28U6rLSJnR1BzXYmD8demdrJY kL2pc6geUAWL+hkQjHbBmVJNSd90myYohGpVVJ0Aq66XYilqP5a0oFclXUsZ bt6sMjNSE1Nl1HZ4omQwO1mIXCKivLq74wEyL7qnZiTDFIeHteI+GpFmSFMq 2lyGbsfoOh1Hj/WfifTwH+p/L/a6IKHqR01qK2E8WgqWA1jH53D7yTHKVY5+ lxe2lC43vJPwkfV0/SELvE2h6sbeGkZ6UJQnrwrM/m6UxVqBXv62Y+RdUl7A Gi5YpsOKUoaIZk22ccJHVjmeQVDmejx0r9Y25v1H6wJ3TqC6c19z+xQFviDi 6enBnmG0dFTy4cpyiYm19XND8v5a+UunGmh1LEysR3GWEmZSwk0IzHpcVPUW 3Fb4pUbRVp45I/9qy0JxiOu2PmvAt0JqKkNyMr+9Gzb8/gfG7Nyjp+0yxhR2 +CtZZx5qjxYF9B6NcycHhJOjFtUIjpb/oVSUL4uCrqi0xoYjFnodxck4b6Zx cRfnsg+2VBULCk0xHCW7lujh0UWOjmQ7OT21bBSLc8Npkj57jimkbqZEMxFz Hozgmem3FVXPVzdI5AcpLwbQ7P/QBPO8do7u4YJlQCpi4Zrf6pysjLZ0HpOG 0B1sPYE4TMA7QdRpMmRT8kqlcdCCCvsnCRtGRreI4/eNTBW+LnLUQ6kY/neg hmBfL3OnbpUy8oqPRP0ZHNZnAoTemLLfQlb6kBl8qYyWs4z9UJCeICHh5/fo 9IZc9Wly1KjsLtJqHa9MrMam1q+btsPQwL65wgA/MnSpNr9HZiZ5Rz7KoOLk 6eEZ4ZVZdj7yE2CPmPLfMKlINIwz7bt64pSHcz73p1QPCVik9r06iDZi71bP sRJ1ima6aSbVbHTNX8eqjkf0YRKEK0ffLoV1vwzadc6zARY5UiwCw6sjiKLy J7zHPdE6W+Jl4yYB9SGXZ9qlbta0mwrqY1d29ogC6DX3mDUvcZGq53734CS1 /k+pB+xODmHleayMribk0OKJ3QeQVrDjNuW2Lyae8tHELdnpcy4sqsTvSq/l DiWtHkJ5+DjqFX4FrosryQ+C0CoTRD9qg3or6ir5QsfGmfyPIhFzSvqo0A6L HQ9vlp2kNgc7DULuiDG+g7hy5DZW3C6HGpamXr/JQUdK9dirmFXQcqqr/l40 WJLt25YneWZji2IutAx+jnGSuBjKj2YP+a/EPS4aK6i4igoUxQdhMOz9R093 NB5hKFzOpFUgU3o1XzJQH5vZAybfvkQFgwh7c1TxOXF1sAoldQ1ntJSOKLOv XG6LHzlU9mr6J5KRcVvC+MkMIUqQXjA8SHQkdfZ8xEY+JuIYyQe3fFhEdJFy 7UsB8k9OHVUrJlc+wPj/+0uABZLIPSOr0Ceniu2+tVYza1nHchoWbqj/ynMj waQWobk5TS6V0k6WWDveFNHnQ0p0pPaBZVn3+mM1mnlRyzR0I4knmZt97j4I wGbEoa5ZyHNjQlgw4FHWHVm6TGHDxbiMRs+zMkTO0znu1cm0tvNeiz9yum/t wZDDh9ofJsxCnYOS19TZjT6eB5SDjLGaJgMDdsD9VCKrD6ioeqTXlOZLUlrN ckQWzuFjC577QJTWRlLAcC9b+0PR/u9aLVI7SUAXK4Iq3Moag6YDWj5Kztkc JqLCowuoahmedr9YvR38kE1d2ivcIbESMt7qgfVTCfhMyGJ2zYCS124+81bn iIkPAk9H42ioLtNTFS0UwDDnsT8vxgmURRt72UX6V07Bw4TWN7K7uYypbSaD TdiFnkJh+tOnXEPTfnzOptp4vBU2C12LoqLMdxFqtTQK+tZs4lMJImjrW1tu 6R3/eutXpxYhZBn2mNs1Dt1B6inNrzkDIDmp4n+CIj680luatldTc+DmjVKr KwauYpBrreD/d2aa6YMZH1a5uc+9q/5UQPuWgxoBZtk7zQfsuO1KMk/+pH0y uvI0S77uYQ0V72xQYrapdJuWEcsfqEQaSIri3wavxd2Ywjr4v9Gb2I2db0dj E3mWY/JlkJoOEaoQ6r+vzT2W4aEiDbU4Lpc96Cn00PJNYcRNkvYZJb5hxMxh bLMQjkJozhIfh0camvxZcVGQ3xbPtpSwydzXDMTRwec71vuGuChqt3fmjn4m yV995zZrs8KHOZLlDCJ+BmQdkhhbawHLyNeH2hXVXqsZqh06hn4Q5eDQ4piC 8Esl4/IqV/UtAya/ZOJYxNhH9KyVmotTtFEHwAeUx9Hn7jyUv49L2fJmMeNu nowSJDWi4bbaYCbuyoqAX6IufzspT+Qzz5le6dbCPcgFvqHqFeAbtMoErWYz 0fjWEptCX/5yo85Pp7oBJtaM/9p2sbL1TwYMmobFXIpQP81igRyq6fWDvI8/ /ZiWbNI5xeRBe1WGuyOKbs3X869YZNL+4s2+GENQD/saj+Z9J7U40NFBnwQt 6mr79TPrHuissmFNM57Ls87q6HQwhk/2uyvacZjur/3RSq4+uefZnDbelMns x6muzupoXd0a/6w3Qh0xrU+Hi5kqmoACsUzv8/bbMhOOAAVpVlzsJYd1KyVF r4CWS7H6QAp01LSOeX5CU60+6z5DgjS3t1usZsmSLFJSQM71hioH6jxnATay C0WV7HhDCnuJ26qgxzF+PHbtiRBggb6PM9uHYVTXtvrVQILvWIDqpFniinNa /lrJxrSD6M2VeSJaJ08L1M8Gx64liPZY0U84FJo61nzCuzpxO2I6tL0upTp9 8QYEtuahvY4yJ+3QiV9S+A7E26qmE6X/n+mwPJ4Ih6VqknR93XjxgfL3PtvT FQHYaioOrWGmdQuiXCbkPttICYVFoyWmUKCUNYoHJprSYc/aL1sl3R6F0QPA pprOPgmohTgT7J1gvFVxGB9JjpdAo/d1iyCGB5CtRcb/Wqu9TkqaqjloNEw5 obXQ57XQYQF+mvXyo7u4xSDCn8rluRQ50/rzX6yWSAwxGNNn7B62ZWgNl4vu zaZozAJsn6EcNoJbCnIb3aYbXfSnJuAEbu+kvU5KGz2jXaKvgnZrR3m52Ou/ qGXZlmcptlWolkh1fsTj6t1l/hwlq0mLpMMQQaQoqBrHeGGJdBs5krsZRw4y kAvrc+kMo+boOQ7p0fL7+S6Gn+5ieCT7KxPT4xbXb+dBtA/xCly0EpMpQxbe LgcBhN+pGOSGUxCvGpLsMwGeG3ARtO/60aZQ6DiF4cy/nSXwrrg/Al/3xRMQ tLHpiY4uwIlhKKqaQKarcqIdf+QBGWhF9TvX+XEGPqOkwKH8tFoR7o2T0Cse ju2YVAYKVF/pGSq9Yi8qUOjzBl3jBs/22F1mHAnOKwFBMJklRJp0aSqBUzUa dosxFXyD+0U2kYxSCFgsU3kf1WIkzGl+hYEqYrN32H7ofT8sgqRb+Hr+yf14 2XS8OxDVoB05rs5j4WzEYbfY+TZbvpvcf1jfwqrrn5zhVI/r2CCU4R+K9cYv OZExjj7/M6uajANaFfF6Gt2ncopV5Vj1U2wkeRhMXH/5jsCB4osz+E6GYmmQ 1fFbafzsPrwqX2IzYEXB7eEo+NmkhAu5EQefpakSUpSPswxAQrkbJiOLWuoP BRn1Vxw+jyhhnHqncT9xdDJ3mT3d9ZJnX9CfcnhD+csuQiOHk5dVYzaY4zpk Fzd21SbRkfxwCezaaWmDjKmklEZ6QrhZPQGSAelddcRhcc7dc5hTU655Mnb+ tVSUPDEkbTDvVZSWIqPR74IEB4kR7iJQ5QGDinzai34tZ+blERFYGbf1++PR j2jlYrQNfVAofonenYymQJy1R3h0oK7xz6bI9vVMrBk/sXPt0EiZrWHSqkED JBgZoFxKGqDABgLrMhq52qOKBsyA5AxPeGhJn6t4Z0gE6CEO6ohd8HSXe6BN 9W1uRcImH5nkrXq/6LXzkRwKGjXZJ69WNd/QV+Fvsnm4FpCLb9fvgVJwx3KD cFEWK6BKFOOTWov3PazKouBN1oj/bU0hKZ6I8/x6qJ3rfA+aBb5OXAhrYBVs l2mZtIgfWFGCJJd41nPPVr2BBjE51N5mM9kUj+jcqqHgkZdW/QZ/v7Hsvuk4 tS1OP1d+EVIV8XTEJTyvlY51w5XBzTvsVgxVIVujzhfNNif8CHtZgYo5/Q+R 9s9Fyz1rSEFy7F2jKIXtfod2gu7WpgLwiwUQi1WyD+5nUgDIyykNhttH/7Ry Yj1aLYmIMWlKob4Pu5kYq9Im6Rh+sHzE/xKlwqbTRZejUKoJtrB80kVECm+G b/cPmrVR2M5LzVfTUaCK8vufE3JyBmu7HZf9CkddvR7ht2ZSTRxbKIaL2Ao2 ymREK8/aUoaJjD1wPJ+ypT4l2YffIRFnlQEFl/ufCZYt2kaOr3BhRYp5GtvM 1hsvKO/+PgP1/ZlWgGhtW83r2BVi+Ux2VMDGbJTosMp2pxrf6x2LYVcuk0pH Or1f0Mbg1/HqfTTZIGVrTQX84GsUqg8PZw9aqX/G1f0xCxRalXB80f2H4oj4 N0iqAxJYCkuojEm+G/E+0tFWAtA2KXv5qHPXR6gbbqlP80XFT/g4aWdIRijY CatM0qWV6Iqbxk2Ep6Ri/O3Fna8PZYsbiWYutyknQSAHj2DZBlPPGDVOsRPR CXiXuvmfR1K96Dr7dmdShM2dc/I5JouDvufMbCnYFbraMa+sTB503tSX9Ej1 WRGKNkoD+NOjTmaYNoFpszYSUvl2aWtzKa5rBOVk6NeGLPpYb3KgBs7OKf5N mvioVsUm+5qAa4VLauJlAl9KbGefLV5CJiY6vaMZ0p+SbkF2Yf1pcmCbszX9 AjYCx7fN5YOd7EKHYtcO/ikcspE3BdTbJejMpQvLHWQZEzorp3p2Fbmkyr+D YStp6VqXiN8T84bFpg/k6ED+0IXfygXV8gYPaf+qYuvnTmzpb/Z+AMIi4oWe 8UshX+IkxBYIRUON7Azpcr4RT1/b6tkaMGwiqR0uCfYsKF0RAAiWo2IN93RN vePrXcHkMrDC/Yi1iTYk1tdkYj+ttSnhi6+E5nVmWFClpAKy4BLK7oH8veW6 Yi1gk9ROmnuv0+3OgIbKapaRhsODTdIOAgMlu6OPXik+PhYlQZwFwgZ0tprw 7wI4At4lzcl5tTVSpzuKC0OS1qrOsRqISiWlpff7lH9DwW427sY3RyJPLiFd 8Vh0y7J4ISbmkeTKUgyKtp5/kHxDEY4sJhtMbU4ukWqRBaADkivxfiqmVALW 87earBSE+e7E+j9Unf5xr8nVmSqQA8hcuhTA96s0LBWQSUPeZnfpinxVkGLK LlcLP8bnJcr/6pK5kdXhAaYQoKziS1VfaQ1cSAhAAqaPNBOeWJZNKuci//c1 4by+t1bOnIyqjTmOASxb6yc2b9jggCjTlAFWQ1LCElcYoxYIxgMHBYXuARW3 rhXRdhYO6T7leYGXIBn5kSIx7luLbNQHanZVzM5sZZGNWx+zFFF1f5ZcZS/c TUHpTkGvjeaxslNU148XJ/P8zfKivsFXqcG2VqQgfJ/mfGx8lBbxqoV/5MbL XlYWhwlanpO7yrD/m5VslcL3uIGhOQ77wyU+qYqluOQOuBKqZTkK/k5QieJO /UHpYKfOz5WZnBOVXCwDjCXIBd/XbAnQ/hMH53uaARY0NhUH/gEJAaOnIza/ TyxBQeowKj6vaqSFbVysqP9ByESTQ9Y1IAjZ5M9L6sJZeB6fA2V6eqN8IW1N Y0jSDWdquopNa3tAlJg/6IGJwISb2rAoj93b44fwW4uwCU0XuAnH0bYj31Ot WHcbplEilsJL70DcjK72l66at93tdVnP2Bj40qH1v/Tb/x3+B27P518CS8QZ qifnUqrSpFyYfg1iRgV5oiCGI/viRx21s+sRj1aHD/xRERLF3skWP4amEjuV MyI1Ru4LSgdiQVrSHleQsK0VrGBSQrYiDSrz765XxKJGerGx92oIUIB0ABxK XSDB0n9YkmdfbXwqjm8zypKqxHOGk6ATnK/cgIfCXE2A6gH0h+rOhLNyo0ui Lnz0vhMhk7Yw3iHaaLeu6ku7XuOvZyPylQeh2q3UccXYvC30+H254PMOcecY +eviIJKP9E2UKe8oavAOfG+uB5PAKBGLpt8GtWpWDMhSRHGOi+d0o+kLeUWi zCsaQo4pPhtlcwaYyQ0Q4ccZOipgAMdjngLvuDYXyPFMEYLTjC2tAzQktl92 JF6f4CRp1x83aiu9zx1T09cnvGzGOPSnwN3LytjVA3jTj0GA7ZicIOqi0Goa BVrGGx8TIiIpzH41Q4XauFy+Nu4iesH9mAaCh7PaI8q/iNLmjTpM9dM+P/iG huKjJbd/5i2XBvpzF/1wOSgHNXzA6hd12MIhmHlMCKg8/BXlw4Mvw6o9Pbm7 1iDxUnk4TXBrTxrgj3pstHtIWHIVWi905wDPgThqhqv6Rr2Kx0nERyMihx3X fuXAjm0JlnVqDGPTZXRZGPVa4huYRqe4iTHdJsn7PcGKjgS7sb6EbqjVjOWy +2nfi+Y3Ia0b4835fPFk1zLyaLU6bNbbaVFz3iTLVsqbjqbI9WtP7rZ05/Pf /of38+Yr5aCy18gvGJwQJhw3DhCnuHki400AfGgPB4h5khqW6Bh+pKMGLJWP tjPNVg1t7RnzNQvPmnwrsAURdCSTDxtkDztj4TBfb6nOCKCNd06tXhdo5TSg d93OQ2H72aY+5HWWDnpYNP5UhJq7LKmCl0N0f7luScvdIXIo7+HpCbKhhqyi kkhssMcmHK7ho5OrHqhWqQlntJozWJnRDUZLpWbEzN1qioqOvXUp7owm3+yk 4Xypl6Ya+cBjouruV1K5VRTrEDrFvxss2RhxERCcZhdW30gKhU5t+8fsM7Vk UTyrXQ047nL5LO38cyrniwE+Knimezs3XUAP7udIasihQmFSO1GLXPNRjAaI f7DYVkLYitZGwm59Z/YzKwA86rK5EbpRmjxREZw4arWaVj5Tl3/N9bu35LmL oU4+srgi07202FGJ3aQ7o+Z0yrwBVXXcOQdy0inCoM5TkSrVf3DioHYygezu 7FL6q63p4KFqk/2sUzzh4izPGuTeCh4PkQ4cJ2qgFFA2cw0o9x8WeqalKJ54 UzOCSI4DtRSlO9/CDSPdoNoBjkybXSkiP0cbxtdDOaxXUncCPEFHeKZxeRFt fI2s0Ha5trt5nn9WfdcS7kOcwpebw6U7hAdJz4hZcmiYJgYMg1nq25RUiXS1 ZHwCsI8Epq6h9S6d8az+i9lniPv9Ti/4fSPQ1hPolNg8tDPbVGrAwUAZDspB 9B7Ulaa19KZsV+HNfBvy+hu+9c3IdBr4g9wUGHqvbxo2PwcZ48kHVrlxOm4D GzdyUeohnhdzPajgHSywiqsxr2xPU+096FTm4sJIAr8+XzJt7kMvX5NTCx07 djXawRWMg2RkjHEFb/MhrXGd5XH/ybgenOJmstMOUxKeFhz9hyCuiY1WkS++ ViCO92YsmraTkTmlkqnDr74jeLTQWwu76gej1OSOTMUWgOeqOk+ryiJ5XepZ /uLgGq2b/WAkJueDHM39sRly+sLPBBvFldMS8iBwB+Q+GwkE5vIJMutNDlBy 4zhcVIk7EgAnIpjH/T7mgI8tvFQvH8o111ik5nxd76dKTRdxtFxiSVBKLRpe fl7Ot3VFmjZhf0f0ZZcwi2i962puruvWid5rZPboSDiW7BXTjwHMb8U2jlKr K0TuvFszTrF58OPOcb6Nq45hWqq7Wum93hGX3sfcJpLngMuMHEJp0hQ/AqE5 8qD+Wr8+9Up3CuV8Prz/nhNf4I3bjhyiho4Y2k9GANM11xjk/Y1IFqMvEz5n 2jhJ3jIqVhoMPWjCuSkHmkkyggHjMq8ou1Kr5182zrnuEPxrhkPmTD0FCZ7a ejnDBns0kUJwwlLbYGZbe3Ce/QIjjSW+lLDsXBG8Uu/S1gUPn/XeNscbm+wL ECKMrm43cbdK5likIq5hpWppGKgfU6PRlFfCmqbRXtjbgNrL5stV3Pwy/c1S 5JzyKqQ59y90w5JCW23jdHg/8mDY3++NjDYMrUAeH7Muq3DNtEwK/7mmBu9o kSsLS1soVBv7MEzU1ipNyj4oMlPcLJ+ybkuU8WZVsaqrQc50f0mkXgpC4hm4 VR2xQHkBn/xlIwOOdRY9Nm5M9MFsCr6bkZImPp/9XsSGogtmgLHITor0hK6G 60wmsw4y5rd57P60KrxXoi1k96t+JJOlIR0rnI/UxMO7iW/Q0VcHq8ozzdHy 5jrQD6EV/xRmvvEiQErmVxDt7EvRj+J8yzIMnFX3GZBcmxy58DUI06vcE8R0 LgbuYAI5FhGpVjfXQTkmmF47QUu4JHkyRUB08/xOlKCNXboHKUCoMMdbyhpn VpnYK2TkitR8AiRyejQpE2Ml+e5rSu9acHB745KKJeKahwoekKfG9Zi8jpjF x1Emj+Ndyr8U42S2Da5GvzxtsaxWNX+gQ3p6vgyz6tWSh1fFhUr97asyhonX +Sucns/Xoog2/uJMQTO/KQmIi2jGYbgw0lLodUGvFGA/XzWE4+wA9qyxBPwI T1qsf5YqqHqbdvXAcFNEmdlzVBs6OEQ/ByxP+9t8f7VpGZJlAx+DJacV0EQu UoSz4w7Rn9gaoFAxK3hgon8W/595I78+RFdm3tB8LWPHCRZU84eNxpnj7EvG slZA4p8rqeKbqQq56rL3oxttrqM2NienKheIo0LZPLtj017BPybTgZ4tKKr7 4gGav+7y8sB6S7fxLfH2Dwii6QjWTec/w/TnTxj2CBtfO1l665Bx16V5UuM3 WgK6IK0X0gltG8TVCCHjgb8hHghcLythjjB3mIMQRqJ4OTN/0Q0HfcJJkA0/ BbTYz2KygmBxy0gLY7c+vmWt9kN4U9HrKCJ54ABvNknFKkKqhmTdm4OOrS+e nETDyrEwa+G8+w20mNGA0759c+APMEjIZELSwk61Es5IhuPbUmeH1XoBLM+T 6PXBzrKVzfQKaJuaNNu76w8wkIiLaopy7vruK1RBFzMMCgNw77UKe7VTHCpl 9xzQQ9Bi9gsjc7fGmFes0AJSlidiJucJ1CEY+GUBIL0HSUhiollNNwRTfRC4 KtLCiwqTnQAf0BmaGbpgyn7U9iVr4r7ufQhnZWQNKkieJBD89zXdL8AxmBPC fFvo5vNeMuHdmbK5qqeEu/FmLLX3IcG+9xSd6gzZN4FZhIeLbV97mlgSUK4X pMqoAdMazYJg6fSwBLvtkhNf5ofV+eGt7/L0U0N/s0kWw1Uk6Th2O+1icCUM gg5uN2gAl0w2O4zZoCmkwUAxwxaKPI8K13ql7SttAKCgPV8y+jdJRWDB+DAz yWZj7Q+EPu3uOPgTxMHgOfgdIHNuCDPALXR1bggTwovBqSF5bggtXHpuCA0U fG4IwcBy6BEAAAAFIwBvCOkSAAAAMTkNGARvCB1hBW8Iw7gnB28IQOjq//// 6HYAAABI6AwAAACLw+kNAAAAMT6YC8M9ahNvCMOLxyV8FW8ISCPGDwLX6AwA AAAzwukQAAAAMTX4cjm4fyJvCMMNRCNvCB0DJW8I6Oj////oDAAAAIvA6RAA AAAxGkgbxjVfLG8IwwUaLm8IBW4vbwjo6P///+kYAAAAG8P5ZGf/NgAAi8Rk Z6MAADPAgSgYOO84+SPFi0QkCIvguQAAAABkjwFZ6AAAAAALxYsMJFiB6WRz QwH4ul1B7ziB8gpBrDkD0TP/gcdiWO84gffjRO84E8Bo+vnpOFvoDwAAABVZ Sm8I6Q0AAAAxD4PgeRvFwyUAUG8IK8QxGovDBVz66TiT6AwAAAAbwOkNAAAA MTuDwCo1c1xvCMMbwIvE6O7///9P6AwAAAADxekNAAAAMReDyCojxsOpMWlv CDPHi8IFBAAAAJLoDAAAADPF6Q0AAAAxNYPoQyUMdG8IwwPFqRd2bwjB+G8z wEgDx3gF6YX////oDwAAALhdfW8I6QoAAAAxF4PIYxPDw4vFC8boDwAAABUP B28I6Q0AAAAxO5grxRPBw6lMDm8ILRwPbwjo6////2HoDwAAABUVE28I6RAA AAAxO4P4cqktF28Iwy1oGG8IG8LD//////8AAP////8AAP////8AAP////// /////////wAA////////AAD/////AAD//////////wAAAAD///////////// /////wAA//////////8AAP///////wAA/////wAA//////////8AAP////8A AP//////////AAAAAP//AAD/////AAD//////////wAA/////wAA//////// AAD//wAA//////////////////////////8AAP//AAD/////AAD//wAA//// //////8AAP////8AAP//AAAAAP////////////////////////////////// //////////////////////////////////////////////////////////// /////////////////////////////////////////wAA/////////////wAA /////wAA//////////8AAP////8AAP///////w== ------=_NextPart_000_0033_01FC6A60.A0E070C0-- From pb@bieringer.de Thu Nov 28 00:17:34 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Nov 2002 00:17:40 -0800 (PST) Received: from smtp2.aerasec.de (gromit.aerasec.de [195.226.187.57]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAS8HXuR028137 for ; Thu, 28 Nov 2002 00:17:34 -0800 Received: from localhost (localhost [127.0.0.1]) by smtp2.aerasec.de (Postfix) with SMTP id 8AD2113861 for ; Thu, 28 Nov 2002 09:20:14 +0100 (CET) X-AV-Checked: Thu Nov 28 09:20:14 2002 smtp2.aerasec.de Received: from p50804AEF.dip.t-dialin.net (p50804AEF.dip.t-dialin.net [80.128.74.239]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by smtp2.aerasec.de (Postfix) with ESMTP id E5FA813860 for ; Thu, 28 Nov 2002 09:20:12 +0100 (CET) Date: Thu, 28 Nov 2002 09:20:04 +0100 From: Peter Bieringer To: netdev@oss.sgi.com Subject: Re: How to get IPv6 interface? Message-ID: <8120000.1038471604@gate.muc.bieringer.de> In-Reply-To: <004c01c29679$52812600$6c06a8c0@zhengjp> References: <003201c29525$cd933360$6c06a8c0@zhengjp> <55380000.1038337716@worker.muc.bieringer.de> <004c01c29679$52812600$6c06a8c0@zhengjp> X-Mailer: Mulberry/3.0.0b9 (Linux/x86) X-URL: http://www.bieringer.de/pb/ X-OS: Linux MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========1815729384==========" X-archive-position: 1261 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pb@bieringer.de Precedence: bulk X-list: netdev --==========1815729384========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline --On Thursday, November 28, 2002 08:58:53 AM +0800 Zheng Jianping wrote: > I'm writing an IPv6 application, so which function can get the IPv6 > inteface information? And how to call it? Sorry, I'm not really an IPv6 programmer, hopefully others can help you. BTW: if someone has some written information about using the APIs, would be nice if can be contributed to the HowTo. Thanks, Peter --- Dr. Peter Bieringer mailto: pb at bieringer dot de http://www.bieringer.de/pb/ Key 0x958F422D : B501 24F4 9418 23E2 C0F3 F833 7B57 AA7B 958F 422D --==========1815729384========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE95dG7e1eqe5WPQi0RAr0jAKCfxfmVeJ3e2Sy5MW29BzFsafelgACg4bY7 CTd+2zI5z0HrA1i8l9xFY7A= =qeql -----END PGP SIGNATURE----- --==========1815729384==========-- From Robert.Olsson@data.slu.se Thu Nov 28 02:02:37 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Nov 2002 02:02:40 -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 gASA2auR029422 for ; Thu, 28 Nov 2002 02:02:37 -0800 Received: (from robert@localhost) by robur.slu.se (8.9.3/8.9.3) id LAA26021; Thu, 28 Nov 2002 11:12:52 +0100 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15845.60452.201159.295984@robur.slu.se> Date: Thu, 28 Nov 2002 11:12:52 +0100 To: Jeff Garzik Cc: netdev@oss.sgi.com, "David S. Miller" , Alexey Kuznetsov Subject: [PATCH] tg3 locking update (with NAPI overtones) In-Reply-To: <3DE406AE.2000908@pobox.com> References: <3DE406AE.2000908@pobox.com> X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 1262 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 Jeff Garzik writes: > * When net drivers move TX completion from interrupt to dev->poll(), > this allows the rethinking of some traditional locking, namely > eliminating a lock in dev->start_xmit() that most drivers implement > these days. Yes. > > tg3_tx_timeout: net stack already holds dev->xmit_lock. tx_lock GC'd. For tx_timout and other timer/async work there may exist a scheduled poll to which we have to sync. Something like this could be done. Ideas comes from dev->close. /* * Synchronize and disable poll */ while (test_and_set_bit(__LINK_STATE_RX_SCHED, &dev->state)) { current->state = TASK_INTERRUPTIBLE; schedule_timeout(1); } . . /* Enable */ clear_bit(__LINK_STATE_RX_SCHED, &dev->state); Cheers. --ro From ahu@outpost.ds9a.nl Thu Nov 28 03:10:58 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Nov 2002 03:11:01 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gASBAvuR006567 for ; Thu, 28 Nov 2002 03:10:58 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 4A0554628; Thu, 28 Nov 2002 12:13:39 +0100 (CET) Date: Thu, 28 Nov 2002 12:13:39 +0100 From: bert hubert To: "Blackmore, Perry" Cc: "'netdev@oss.sgi.com'" Subject: Re: RFC 3095 Message-ID: <20021128111339.GA30530@outpost.ds9a.nl> Mail-Followup-To: bert hubert , "Blackmore, Perry" , "'netdev@oss.sgi.com'" References: <378C31E229CFD411B48B009027EE73C0013A6E21@fhpex002.dsto.defence.gov.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <378C31E229CFD411B48B009027EE73C0013A6E21@fhpex002.dsto.defence.gov.au> User-Agent: Mutt/1.3.28i X-archive-position: 1263 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev On Thu, Nov 28, 2002 at 01:13:17PM +1100, Blackmore, Perry wrote: > Guys, > > Alan Cox has referred you to me. > > Are you aware if RFC 3095 (Robust Header Compression) has been implemented > by anyone on the Linux platform? Haven't heard of it and probably would have. Looks interesting though, even if the RFC is very longwinded. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From ahu@outpost.ds9a.nl Thu Nov 28 03:56:06 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Nov 2002 03:56:08 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gASBttuR007242 for ; Thu, 28 Nov 2002 03:55:55 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 7CEBE4628; Thu, 28 Nov 2002 12:16:00 +0100 (CET) Date: Thu, 28 Nov 2002 12:16:00 +0100 From: bert hubert To: netdev@oss.sgi.com Subject: Re: How to get IPv6 interface? Message-ID: <20021128111600.GA30967@outpost.ds9a.nl> Mail-Followup-To: bert hubert , netdev@oss.sgi.com References: <003201c29525$cd933360$6c06a8c0@zhengjp> <55380000.1038337716@worker.muc.bieringer.de> <004c01c29679$52812600$6c06a8c0@zhengjp> <8120000.1038471604@gate.muc.bieringer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8120000.1038471604@gate.muc.bieringer.de> User-Agent: Mutt/1.3.28i X-archive-position: 1264 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev On Thu, Nov 28, 2002 at 09:20:04AM +0100, Peter Bieringer wrote: > > > --On Thursday, November 28, 2002 08:58:53 AM +0800 Zheng Jianping > wrote: > > > I'm writing an IPv6 application, so which function can get the IPv6 > > inteface information? And how to call it? > > Sorry, I'm not really an IPv6 programmer, hopefully others can help > you. The best way is probably to look at the 'ip' sources which use netlink to query the kernel. > BTW: if someone has some written information about using the APIs, > would be nice if can be contributed to the HowTo. indeed. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From yoshfuji@linux-ipv6.org Thu Nov 28 04:10:23 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Nov 2002 04:10:27 -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 gASCAMuR008146 for ; Thu, 28 Nov 2002 04:10:23 -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 gASCDbGR000884; Thu, 28 Nov 2002 21:13:41 +0900 Date: Thu, 28 Nov 2002 21:13:37 +0900 (JST) Message-Id: <20021128.211337.92231995.yoshfuji@linux-ipv6.org> To: ahu@ds9a.nl Cc: netdev@oss.sgi.com Subject: Re: How to get IPv6 interface? From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20021128111600.GA30967@outpost.ds9a.nl> References: <004c01c29679$52812600$6c06a8c0@zhengjp> <8120000.1038471604@gate.muc.bieringer.de> <20021128111600.GA30967@outpost.ds9a.nl> 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: 1265 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 <20021128111600.GA30967@outpost.ds9a.nl> (at Thu, 28 Nov 2002 12:16:00 +0100), bert hubert says: > > > I'm writing an IPv6 application, so which function can get the IPv6 > > > inteface information? And how to call it? > > > > Sorry, I'm not really an IPv6 programmer, hopefully others can help > > you. > > The best way is probably to look at the 'ip' sources which use netlink to > query the kernel. You may want to use getifaddrs() in USAGI libinet6. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From zjp@iscas.ac.cn Thu Nov 28 20:08:10 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Nov 2002 20:08:13 -0800 (PST) Received: from mail.iscas.ac.cn ([159.226.5.56]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAT486uR008416 for ; Thu, 28 Nov 2002 20:08:09 -0800 Received: (qmail 16452 invoked by uid 104); 29 Nov 2002 04:10:56 -0000 Received: from zjp@iscas.ac.cn by mail.iscas.ac.cn by uid 0 with qmail-scanner-1.14 (hbedv: 6.15.0.1. hbedv: operating system: Linux (glibc). hbedv: product version: 2.0.4. hbedv: engine version: 6.15.0.1. hbedv: packlib version: 2.0.0.8 (supports 19 formats). hbedv: vdf version: 6.15.0.7 (66928 recognized forms). hbedv: . hbedv: product: AntiVir Workstation. hbedv: key file: hbedv.key. hbedv: registered user: irene, 123. hbedv: serial number: 1001020203. hbedv: key expires: 31 May 2003. hbedv: run mode: PRIVATE. hbedv: . hbedv: product: AntiVir MailGate. hbedv: key file: hbedv.key. hbedv: registered user: irene, 123. hbedv: serial number: 1001020203. hbedv: key expires: 31 May 2003. hbedv: run mode: PRIVATE. hbedv: . hbedv: product: AntiVir (command line scanner). hbedv: key file: hbedv.key. hbedv: registered user: irene, 123. hbedv: serial number: 1001020203. hbedv: key expires: 31 May 2003. hbedv: run mode: PRIVATE. Clear:. Processed in 0.21465 secs); 29 Nov 2002 04:10:56 -0000 Received: from unknown (HELO zhengjp) (zjp@192.168.6.108) by mail.iscas.ac.cn with SMTP; 29 Nov 2002 04:10:55 -0000 Message-ID: <000d01c2975d$a2ad3c10$6c06a8c0@zhengjp> From: "Zheng Jianping" To: Cc: "Pedro Roque" , Subject: How to get the IPv6 address of next hop towards destination? Date: Fri, 29 Nov 2002 12:13: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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-archive-position: 1266 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zjp@iscas.ac.cn Precedence: bulk X-list: netdev Hi, I'm modifying the Linux kernel (2.4.7.10) to support IPv6 multicast forwarding. As required by IPv6 multicast routing protocol, the IPv6 address of next hop towards destination is needed. So how can I get this information? Calling struct dst_entry * ip6_route_output(struct sock *sk, struct flowi *fl) can get dst_entry which has a member struct neighbour *neighbour; But I don't know which member in 'struct neighbor' stores the IPv6 address. It seems that u8 primary_key[0]; is responsible for it. Is it right? Thanks, Zheng Jianping ---------------------------------------------------------------------------- --------------------------- Multimedia Communication & Network Engneering Research Center Institue of Software, Chiese Academy of Sciences Email: zjp@iscas.ac.cn Tel: 6255,5523 From yoshfuji@linux-ipv6.org Thu Nov 28 20:13:37 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Nov 2002 20:13: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 gAT4DauR008820 for ; Thu, 28 Nov 2002 20:13:37 -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 gAT4GuGR005243; Fri, 29 Nov 2002 13:16:56 +0900 Date: Fri, 29 Nov 2002 13:16:56 +0900 (JST) Message-Id: <20021129.131656.766932499.yoshfuji@linux-ipv6.org> To: zjp@iscas.ac.cn Cc: netdev@oss.sgi.com, roque@di.fc.ul.pt, kuznet@ms2.inr.ac.ru Subject: Re: How to get the IPv6 address of next hop towards destination? From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <000d01c2975d$a2ad3c10$6c06a8c0@zhengjp> References: <000d01c2975d$a2ad3c10$6c06a8c0@zhengjp> 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 XEmacs 21.4.6 (Common Lisp) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1267 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 <000d01c2975d$a2ad3c10$6c06a8c0@zhengjp> (at Fri, 29 Nov 2002 12:13:13 +0800), "Zheng Jianping" says: > It seems that > u8 primary_key[0]; > is responsible for it. > > Is it right? yes. --yoshfuji From hadi@cyberus.ca Fri Nov 29 05:01:57 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Nov 2002 05:02:03 -0800 (PST) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gATD1vuR025030 for ; Fri, 29 Nov 2002 05:01:57 -0800 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id IAA29852; Fri, 29 Nov 2002 08:04:44 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id gATCuph05026; Fri, 29 Nov 2002 07:56:51 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Fri, 29 Nov 2002 07:56:51 -0500 (EST) From: jamal To: Stefan Rompf cc: , Subject: Re: Patch resubmission: RFC2863 operstatus for 2.5.49 In-Reply-To: <3DE33D6D.25B9C9B4@isg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1268 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 Tue, 26 Nov 2002, Stefan Rompf wrote: > Hi David, > > I've updated my RFC2863 operstatus and userspace forwarding patch to > 2.5.49. As discussion on netdev seems to be complete, I need some > comment from your side. > Stefan, Just thought of something, it may be a little tricky but valuable and i am not quiet sure if it should part of your patch: We probably need to flush the qdiscs software queues; maybe even the DMA ring i.e simulate admin down followed by admin up. Thoughts? cheers, jamal From maxiu@maxiu.com Fri Nov 29 05:14:45 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Nov 2002 05:14:48 -0800 (PST) Received: from maxiu.best.net.pl (maxiu.hstl6.put.poznan.pl [150.254.144.143]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gATDEeuR025598 for ; Fri, 29 Nov 2002 05:14:44 -0800 Received: (qmail 13070 invoked by uid 543); 29 Nov 2002 13:17:31 -0000 Date: Fri, 29 Nov 2002 14:17:30 +0100 From: Marcin =?iso-8859-2?Q?Kami=F1ski?= To: netdev@oss.sgi.com Subject: IN6_PKTINFO Message-ID: <20021129141730.A12882@maxiu.best.net.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline User-Agent: Mutt/1.3.23i X-archive-position: 1269 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: maxiu@maxiu.com Precedence: bulk X-list: netdev Hello I'm programmer in PSNC (www.man.poznan.pl) and I'm trying to write function which receives UDP packet by IPv6 network and determines on what address does it arrive. I wrote program which works on IPv4, and then changed it to IPv6, but now it is not working. On all boxes I've tested, situation was the same: msg.msg_control hasn't got any headers when receiving IPv6 packets and msg.msg_controllen = 0. Program is based on informations in RFC2292 and manual pages for setsockopt(2) and ipv6(7). This is test program: #include #include #include #include #define FATAL(s) { perror(s); exit(1); } int main() { int s; struct sockaddr_in6 sin6; struct msghdr msg; struct cmsghdr *c; struct in6_pktinfo *pktinfo; char buf[1024]; int a, i; char host_src[46]; s = socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDP); if(s < 0) FATAL("socket"); sin6.sin6_family = AF_INET6; sin6.sin6_port = htons(7000); sin6.sin6_addr = in6addr_any; if(bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) < 0) FATAL("bind"); a = 1; if(setsockopt(s, SOL_IPV6, IPV6_PKTINFO, &a, sizeof(int)) < 0) FATAL("setsockopt"); i = sizeof(int); if(getsockopt(s, IPPROTO_IPV6, IPV6_PKTINFO, &a, &i) < 0) FATAL("getsockopt"); printf("a = %d\n", a); for(;;) { memset(&msg, 0, sizeof(struct msghdr)); msg.msg_control = buf; msg.msg_controllen = 1024; if((a = recvmsg(s, &msg, MSG_PEEK)) < 0) FATAL("recvmsg"); printf("Packet msg %d len", a); fflush(stdout); printf("[%d]\n", msg.msg_controllen); // if(msg.msg_controllen) { for(c = CMSG_FIRSTHDR(&msg) ; c; c = CMSG_NXTHDR(&msg, c)) { printf("%d %d\n", c -> cmsg_level, c -> cmsg_type); if(c -> cmsg_level == IPPROTO_IPV6 && c -> cmsg_type == IPV6_PKTINFO) { pktinfo = (struct in6_pktinfo *) CMSG_DATA(c); inet_ntop(AF_INET6, pktinfo -> ipi6_addr, host_src, 46); // printf(" from %s ", pktinfo -> ipi_spec_dst); printf(" to %s ", host_src); break; } } // } if((a = recv(s, buf, 1024, 0)) < 0) FATAL("recv"); printf(", data %d len[", a); fflush(stdout); for(i = 0; i < a; i++) printf("%c", buf[i]); printf("]"); fflush(stdout); printf("\n"); } } Have You got any ideas what is wrong? With regards Marcin Kaminski -- - Marcin Kaminski ------------------------------------ maxiu - --- software developer ---------------------- 6net project --- ----- network administrator ----------- Best Group admin ----- ------- mail:maxiu@maxiu.com ------ http://maxiu.com --------- From hadi@cyberus.ca Fri Nov 29 05:30:32 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Nov 2002 05:30:37 -0800 (PST) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gATDUVuR026441 for ; Fri, 29 Nov 2002 05:30:31 -0800 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id IAA08111; Fri, 29 Nov 2002 08:33:16 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id gATDPL405116; Fri, 29 Nov 2002 08:25:22 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Fri, 29 Nov 2002 08:25:21 -0500 (EST) From: jamal To: "Blackmore, Perry" cc: "'netdev@oss.sgi.com'" , Subject: Re: RFC 3095 In-Reply-To: <378C31E229CFD411B48B009027EE73C0013A6E21@fhpex002.dsto.defence.gov.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1270 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 The only code i have seen was on the EPIC compression targeted for ROHC; this was a while back and i am not sure how successful the integration of EPIC with ROHC (i follow progress scantily on rohc) Richard, maybe you could comment? Take a look at http://www.roke.co.uk/networks/epic/ cheers, jamal On Thu, 28 Nov 2002, Blackmore, Perry wrote: > Guys, > > Alan Cox has referred you to me. > > Are you aware if RFC 3095 (Robust Header Compression) has been implemented by anyone on the Linux platform? > > Cheers, > > > Perry Blackmore > > > > Dr Perry A Blackmore > > Senior Defence Scientist > > DSTO > > > > +61 2 625 66141 (Phone) > > +61 2 625 66130 (FAX) > > > > perry.blackmore@dsto.defence.gov.au > > > > DSTO Fern Hill > > Department of Defence > > CANBERRA ACT 2600 > > Australia > > > > > > From richard.price@roke.co.uk Fri Nov 29 06:43:43 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Nov 2002 06:43:47 -0800 (PST) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gATEhfuR000451 for ; Fri, 29 Nov 2002 06:43:43 -0800 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Nov 2002 14:45:58 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F14F@rsys002a.roke.co.uk> From: "Price, Richard" To: "'jamal'" , "Blackmore, Perry" Cc: "'netdev@oss.sgi.com'" Subject: RE: RFC 3095 Date: Fri, 29 Nov 2002 14:45:57 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" X-archive-position: 1271 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: richard.price@roke.co.uk Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, The code published at http://www.roke.co.uk/networks/epic/ runs on Linux, although it's just a proof-of-concept and not suitable for performance testing or deployment. More recently we've developed a commercial speed-optimised version of EPIC compatible with the ROHC (RFC 3095) framework. This software also runs on the Linux platform and a demo is available on request. I hope that the above info is of some use - please let me know if you have any further questions on ROHC or EPIC. Regards, Richard Price --------------------------------------- Richard Price Internet Applications & Mobility Roke Manor Research Ltd. Old Salisbury Lane Romsey, Hants SO51 0ZN, UK. Telephone: +44 1794 833681 E-mail: richard.price@roke.co.uk --------------------------------------- > -----Original Message----- > From: jamal [mailto:hadi@cyberus.ca] > Sent: Friday, November 29, 2002 1:25 PM > To: Blackmore, Perry > Cc: 'netdev@oss.sgi.com'; Price, Richard > Subject: Re: RFC 3095 > > > > > The only code i have seen was on the EPIC compression targeted for > ROHC; this was a while back and i am not sure how successful the > integration of EPIC with ROHC (i follow progress scantily on rohc) > > Richard, maybe you could comment? > > Take a look at http://www.roke.co.uk/networks/epic/ > > cheers, > jamal > > On Thu, 28 Nov 2002, Blackmore, Perry wrote: > > > Guys, > > > > Alan Cox has referred you to me. > > > > Are you aware if RFC 3095 (Robust Header Compression) has > been implemented by anyone on the Linux platform? > > > > Cheers, > > > > > Perry Blackmore > > > > > > Dr Perry A Blackmore > > > Senior Defence Scientist > > > DSTO > > > > > > +61 2 625 66141 (Phone) > > > +61 2 625 66130 (FAX) > > > > > > perry.blackmore@dsto.defence.gov.au > > > > > > DSTO Fern Hill > > > Department of Defence > > > CANBERRA ACT 2600 > > > Australia > > > > > > > > > > > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, Berkshire. RG12 8FZ The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- From dufresne@mediafusion.com Fri Nov 29 08:01:55 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Nov 2002 08:02:00 -0800 (PST) Received: from mediafusion.com (mailmf.vdl2.ca [199.84.183.26]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gATG1suR005920 for ; Fri, 29 Nov 2002 08:01:55 -0800 Received: from [192.168.10.123] (199.84.183.4) by mediafusion.com with ESMTP (Eudora Internet Mail Server 3.1.1) for ; Fri, 29 Nov 2002 11:04:43 -0500 User-Agent: Microsoft-Entourage/10.0.0.1309 Date: Fri, 29 Nov 2002 11:04:41 -0500 Subject: Can inet_create return -EPROTONOSUPPORT From: David Dufresne To: netdev Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gATG1suR005920 X-archive-position: 1272 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dufresne@mediafusion.com Precedence: bulk X-list: netdev Hi, In inet_create, after the lookup for the requested type/protocol pair, there's a test to see if protocol == 0. Why? Because when protocol == 0, answer == NULL. Correct me if I'm wrong, please. ;-) -- David Dufresne, Sys. admin. Médiafusion Inc. 700, rue Wellington Bureau 1200 Montreal (Quebec) H3C 1T4 Tel.(514) 599-5721 Fax.(514) 599-5724 From mailmagajp@yahoo.co.jp Fri Nov 29 10:05:12 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Nov 2002 10:05:19 -0800 (PST) Received: from banna (fb169193.ot.FreeBit.NE.JP [61.203.169.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gATI4quR007651 for ; Fri, 29 Nov 2002 10:05:04 -0800 Received: from C ([192.168.0.2]) by banna (8.9.3+3.2W/3.7W) with SMTP id DAA16307; Sat, 30 Nov 2002 03:07:04 +0900 Message-Id: <200211291807.DAA16307@banna> From: =?iso-2022-jp?B?bWFpbG1hZ2FqcA==?= To: =?iso-2022-jp?B?cW9xbw==?=@banna.sgi.com Reply-To: mailmagajp@yahoo.co.jp Date: Sat, 30 Nov 2002 03:07:07 +0900 Subject: =?iso-2022-jp?B?GyRCTCQ+NUJ6OS05cCIoRUU7UiVhITwlazktOXA8UhsoSg==?= Content-Type: text/plain Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-archive-position: 1273 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mailmagajp@yahoo.co.jp Precedence: bulk X-list: netdev <‘—MŽÒ> “dŽqƒ[ƒ‹LŽÐ ¡ŒãAL‚ð‚²Šó–]‚µ‚È‚¢•û‚Í‚±‚±‚Ö (•K‚¸–{•¶‚É‚ ‚È‚½‚̃[ƒ‹ƒAƒhƒŒƒX‚Ì‚Ý‚ð‚¨‘‚«‰º‚³‚¢j airorijp@yahoo.co.jp ƒ[ƒ‹ƒAƒhƒŒƒX‚ð‚²‹L“ü‚µ‚Ä‚­‚¾‚³‚¢B §104-0061 “Œ‹ž“s’†‰›‹æ‹âÀ8-19-3 ‘æ2ƒEƒCƒ“ƒOƒrƒ‹@3F ƒ[ƒ‹ƒ}ƒKƒWƒ“”­s TEL@03-3544-6222 FAX@03-3544-6218 =============================================================== –â‘褕i‚΂©‚èW‚ß‚Ü‚µ‚½‚Ì‚ÅAÁ‚³‚ê‚é‹°‚ꂪ‚ ‚è‚Ü‚·‚Ì‚Å ‚¨\ž‚Ý‚Í‚¨‘‚ß‚ÉI ================================================================= ™\\\™\\\™\\\™\\\™\\\™\\\™\\\™\\\™ — ƒrƒfƒI”Ì”„EƒƒŠƒrƒfƒIE“ÁŽêƒ_ƒbƒ`ƒƒCƒtE‚r‚lƒNƒ‰ƒu @@ ‚`‚u’j—D•åWE‰‡•ŒðÛE‚r‚d‚wƒtƒŒƒ“ƒhEƒAƒ_ƒ‹ƒgƒOƒbƒY‚È‚Ç š@ƒAƒ_ƒ‹ƒgŠÖ˜A‚Ìî•ñ–žÚ@š @@‚¨\ž‚ÝE‚²’•¶E¤•iÚד™‚Í@ @@@@@‰º‹L‚t‚q‚k‚ðƒNƒŠƒbƒN‚µ‚Ä‚²——‰º‚³‚¢B «@@@@«@@@@«@ @@@http://www.ss-koukoku.com/ ™\\\™\\\™\\\™\\\™\\\™\\\™\\\™\\\™ @@@@@@@@ŠJ‰^ƒOƒbƒYE‹É”éî•ñŽ @@@@–h”ƃOƒbƒYE‹à–ׂ¯î•ñEƒ_ƒCƒGƒbƒgH•i‚È‚Ç@ @@@@@@@@š@‚»‚Ì‘¼î•ñ–žÚ@š @@‚¨\ž‚ÝE‚²’•¶E¤•iÚד™‚Í@ @@@@@‰º‹L‚t‚q‚k‚ðƒNƒŠƒbƒN‚µ‚Ä‚²——‰º‚³‚¢B «@@@@«@@@@«@ http://www.pp-koukoku.com/ ™\\\™\\\™\\\™\\\™\\\™\\\™\\\™\\\™ From david-b@pacbell.net Sat Nov 30 13:04:41 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Nov 2002 13:04:45 -0800 (PST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAUL4fuR021848 for ; Sat, 30 Nov 2002 13:04:41 -0800 Received: from pacbell.net ([67.118.246.138]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with ESMTP id <0H6E001SHQOLU7@mta5.snfc21.pbi.net> for netdev@oss.sgi.com; Sat, 30 Nov 2002 13:07:35 -0800 (PST) Date: Sat, 30 Nov 2002 13:09:30 -0800 From: David Brownell Subject: 2.5.50 BUG_TRAP on !dev->deadbeaf, and oopses To: netdev@oss.sgi.com Message-id: <3DE9290A.7070502@pacbell.net> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en, fr User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513 X-archive-position: 1274 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david-b@pacbell.net Precedence: bulk X-list: netdev Since sometime before 2.5.4x kernels, many of the usb networking drivers running on 2.5 tend to trigger trouble like this (full text appended) when they unplug. The drivers in question didn't change how they talked to the network stack; the stack started to complain, and oopses started: KERNEL: assertion (!dev->deadbeaf) failed at net/core/dev.c(2544) I think there's another bug, beyond the obvious speling erorz. Namely, that "deadbeaf" is only set after that BUG_TRAP, or on one error path. The assertion prevents hotpluggable network drivers from unregistering when the hardware goes away ... which is a regression. For now I'm just commenting out that broken assertion, but I wonder if a better fix wouldn't be a "no deadbeaf" diet for the kernel. But there might be more problems than that. The next message I got (at least in this 2.5.50 oops) was unregister_netdevice: device /dfd74058 never was registered That's odd because we know for a fact that the earlier call to register_netdev() returned. Something got deeply confused, and likely that caused the oops. I remember seeing similar failures with the 'pegasus' driver, with the "deadbeaf" problem and an oops, but I don't remember whether those oopses were at all like this one (or gave that "never registered" message). Since there have been 2.5 kernels, using essentially identical drivers, that don't trigger any of those problems, I'm wondering what's up.. I'm suspecting the networking code caused all of these, now that the sysfs-related bugs in usbcore (which caused different unplug problems) seem to be mostly gone. Suggestions? - Dave Here's the full trace, pretty typical of what I've seen when unplugging those network devices: KERNEL: assertion (!dev->deadbeaf) failed at net/core/dev.c(2544) unregister_netdevice: device /dfd74058 never was registered eip: c0107bf0 ------------[ cut here ]------------ kernel BUG at include/asm/spinlock.h:123! invalid operand: 0000 CPU: 0 EIP: 0060:[] Tainted: G S EFLAGS: 00010086 EIP is at __down+0x5f/0x1c0 eax: 0000000e ebx: dfd74034 ecx: 00000000 edx: 0000ac2c esi: dfd74034 edi: dfd7402c ebp: 00000286 esp: db5dde38 ds: 0068 es: 0068 ss: 0068 Process khubd (pid: 913, threadinfo=db5dc000 task=d64eb940) Stack: c027b05c c0107bf0 d64eb940 00000000 d64eb940 c011bec0 00000000 00000000 dfd74058 dfd74058 dfa5c504 dfd74034 e08897e0 dfd7402c db5dde84 c010807b dfd74034 00000000 00000000 c6f7e000 e08897a8 e088991e 00000077 e0854302 Call Trace: [] __down+0x0/0x1c0 [] default_wake_function+0x0/0x40 [] +0x0/0x18 [usbnet] [] __down_failed+0xb/0x14 [] .text.lock.usbnet+0x9b/0xd3 [usbnet] [] +0x36/0x2d8 [usbnet] [] +0x36/0x1174 [usbcore] [] usbnet_driver+0x0/0xc0 [usbnet] [] usbnet_driver+0x0/0xc0 [usbnet] [] usb_device_remove+0xc8/0x140 [usbcore] [] usbnet_driver+0x18/0xc0 [usbnet] [] detach+0x42/0x50 [] usb_bus_type+0x0/0x120 [usbcore] [] usb_bus_type+0x34/0x120 [usbcore] [] device_detach+0x10/0x20 [] usbnet_driver+0x18/0xc0 [usbnet] [] bus_remove_device+0x5a/0xb0 [] device_del+0x78/0xa0 [] device_unregister+0xb/0x16 [] usb_disconnect+0x95/0xf0 [usbcore] [] usb_hub_port_connect_change+0xa0/0x2c0 [usbcore] [] usb_hub_events+0x1eb/0x420 [usbcore] [] +0x1ec0/0x3d20 [usbcore] [] usb_hub_thread+0x35/0x100 [usbcore] [] ret_from_fork+0x5/0x14 [] default_wake_function+0x0/0x40 [] khubd_wait+0x8/0x10 [usbcore] [] khubd_wait+0x8/0x10 [usbcore] [] usb_hub_thread+0x0/0x100 [usbcore] [] kernel_thread_helper+0x5/0xc Code: 0f 0b 7b 00 44 af 27 c0 59 5b 8d b4 26 00 00 00 00 f0 fe 4e <6>note: khubd[913] exited with preempt_count 1 Note that killing khubd() like that meant that no usb device connects or disconnects can be processed again without rebooting.